Phương pháp test security cho web application (Phần 1)

Xin được nói trước, series này hoàn toàn là do mình lược dịch từ chương 20 của cuốn sách The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws, First edition. Link ở đây: http://mdsec.net/wahh/.

I. Tổng quát về phương pháp test bảo mật cho web application.

Đây là phương pháp chi tiết để bạn có thể làm theo khi tấn công một web application. Nó bao gồm tất cả những lỗi và phương pháp tấn công đã được mô tả trong cả cuốn sách (mình sẽ sắp xếp dịch dần). Làm theo phương pháp này có thể không đảm bảo giúp các bạn tìm được hết những lỗ hổng mà web application này có, nhưng nó đem lại cho bạn một cái nhìn tổng quát và tìm được nhiều lỗi nhất có thể với nguồn lực sẵn có.

Sử dụng phương pháp này để tập trung vào công việc, không để bị sót phần nào những tất nhiên cũng đừng quá cứng nhắc chỉ nhất nhất theo nó. Nó chỉ là là cái căn bản theo dạng 1 cái standard để bạn có thể tuân theo thôi, còn security vẫn cần rất nhiều sự sáng tạo, nghĩ xa hơn những thứ ở đây.

Đây là mô hình mô tả phương pháp này:

Như các bạn đã thấy phương pháp này được chia làm 3 phần chính:

1.RECON & ANALYSIS

Recon là viết tắt của từ reconnaissance (trinh sát).
Đây là phần tìm hiểu về web application, tất tần tật từ trong ra ngoài. Sau đó phân tích luồng hoạt động của nó để có thể đưa ra những phương án tấn công phù hợp nhất tùy vào thông tin thu nhận được.

2.FIND VULNERABILITIES

Sử dụng những phương pháp khác nhau, tập trung vào 4 phần chính:

  • Application logic
  • Access handling
  • Input handling
  • Application hosting

3.MISCELLANEOUS CHECKS

Phần này check những thứ còn lại ví dụ như: weak SSL ciphers, infomation leakage, local privacy vulnerabilities…

II. Một số hướng dẫn khi áp dụng phương pháp

1.Luôn nhớ rằng có rất nhiều ký tự có ý nghĩa đặc biệt trong thành phần của HTTP request. Khi bạn sửa data của các HTTP request thì nên encode chúng để đảm bảo rằng chúng sẽ được hiểu đúng cách mà chúng ta mong muốn. Ví dụ:

  • & dùng để nối các param trên URL hoặc message body, được encode là %26
  • = dùng để chia cách cặp key-value ở mỗi param trên URL hoặc message body, được encode là %3d
  • ? dùng để đánh dấu bắt đầu của URL query string, được encode: %3f
  • A space (khoảng trắng) dùng để dánh dấu điểm cuối của URL,.. được encode là %20 hoặc +
  • + vì được dùng encode cho space, nên sẽ được encode là %2b
  • ; dùng để phân chia các cookie ở cookie header, được encode là %3b
  • # đánh dấu fragment ở URL, được encode là %23
  • % được dùng ở đầu các encoding URL, được encode là %25
  • Null byteNew lines (nếu URL-encode sử dụng bảng mã ASCII) sẽ được encode là %00%0a

2. Có rất nhiều lỗ hổng của web application liên quan đến việc gửi rất nhiều request mà đã được thay đổi input string, rồi kiểm tra điểm bất thường trong response, để xác định có lỗ hổng hay không. Nhưng có những trường hợp, dấu hiệu lỗ hỗng đã ở sẵn đó, chưa cần phải sử dụng đến scafted input string (là những data được tạo ra để thăm dò, khai thác lỗi). Nên mỗi khi phát hiện được điều gì đó, ta nên sử dụng input thông thường để double check lại xem web application có hoạt động như thế không.

3. Nhiều web application có lưu trữ lại state (trạng thái) của những request trước đó, nó có thể ảnh hưởng đến kết quả response của những request tiếp theo. Đôi khi bạn nghiên cứu về 1 lỗ hổng đã có dự kiến từ trước, bạn phải tách chúng ra khỏi những state kia và các định rõ nguyên nhân của sự bất thường trong response. Để làm được điều đó, bạn có thể
a) sử dụng 1 phiên làm việc mới, sau đó sử dụng input đúng để đến page bạn xác định lỗi, sau đó mới dùng đến crafted input.
b) thay đổi 1 phần của cookie và cache information.
c) sử dụng Burp Repeater để tách riêng request.

4. Có một vài application có sử dụng load-balancing configuration, do đó request của bạn có thể được sử lý ở nhiều back-end servers khác nhau. Có thể chúng giống nhau hoặc được config khác nhau chút ít nhưng vẫn có ảnh hưởng đến kết quả của bạn. Để tách khỏi việc bị ảnh hưởng này, cần phải test các request được chuẩn bị trước nhiều lần và nối tiếp nhau, sau đó kiểm tra kết quả của mỗi request xem nó đã được xử lý bởi đúng server mình mong muốn hay chưa.

5 1 vote
Article Rating
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments