Chuyển đến nội dung chính
  1. Dự án thực tế/

Kiểm thử xâm nhập ứng dụng web

·2901 từ·14 phút
Nguyễn Hoàng Thanh Phong
Tác giả
Nguyễn Hoàng Thanh Phong
Sinh viên năm cuối ngành An toàn thông tin tại Đại học FPT. Chuyên nghiên cứu khai thác lỗ hổng bảo mật Web, kiến trúc bảo mật AWS và các công cụ tự động hóa
Mục lục

Tổng quan dự án
#

Dự án này trình bày một bài kiểm thử xâm nhập ứng dụng web (Web Application Penetration Test) theo phương pháp black-box, được thực hiện đối với một website doanh nghiệp công khai trên Internet, từ góc nhìn của một tác nhân bên ngoài chưa được xác thực.

Quá trình đánh giá tuân theo OWASP Web Security Testing Guide (WSTG) và tập trung vào reconnaissance, lập bản đồ attack surface, phân tích bảo mật thụ động, kiểm thử chủ động thủ công có kiểm soát, xác thực lỗ hổng, đánh giá rủi ro và lập kế hoạch khắc phục.

Quá trình kiểm thử được thực hiện theo phương pháp có kiểm soát và không gây phá hoại. Hoạt động active scanning tự động được hạn chế do phát hiện các cơ chế chống tự động hóa hoặc có đặc điểm tương tự WAF trong quá trình kiểm thử.

Thông báo về phạm vi sử dụng

Dự án này được thực hiện như một bài đánh giá bảo mật học thuật có sự cho phép. Phiên bản report công khai đã được sanitization nhằm loại bỏ các thông tin có thể xác định target, URL và nội dung screenshot nhạy cảm.


Tóm tắt đánh giá
#

Quá trình đánh giá đã xác định một lỗ hổng nghiêm trọng High đã được xác nhận, cùng với một số điểm yếu liên quan đến cấu hình và bảo mật phía client.

Phát hiện quan trọng nhất là một lỗ hổng Error-Based SQL Injection ảnh hưởng đến một parameter trên trang sản phẩm. Một input được kiểm thử có kiểm soát và không gây phá hoại đã khiến ứng dụng trả về thông tin lỗi từ database, bao gồm phiên bản database backend và một phần cấu trúc câu truy vấn SQL.

Các phát hiện bổ sung bao gồm thiếu một số HTTP security headers, xử lý Content-Type không chính xác đối với một AJAX response, thiếu Subresource Integrity đối với các tài nguyên bên thứ ba, các đường dẫn attachment có thể truy cập công khai, comment phục vụ phát triển còn tồn tại trong resource production, và khuyến nghị thực hiện đánh giá đầy đủ hơn đối với các dependency phía client.

Mức rủi ro bảo mật tổng thể được đánh giá là High, chủ yếu do lỗ hổng SQL Injection đã được xác nhận có thể truy cập thông qua một endpoint công khai mà không yêu cầu xác thực.


Tổng quan đánh giá
#

Thuộc tínhChi tiết
Loại đánh giáBlack-box Web Application Penetration Test
Mức quyền truy cậpNgười dùng bên ngoài chưa xác thực
Môi trường mục tiêuWebsite production công khai
Phương pháp luậnOWASP Web Security Testing Guide
Phương thức kiểm thửPhân tích thụ động + kiểm thử chủ động thủ công có kiểm soát
Trạng thái đánh giáHoàn thành
Rủi ro tổng thểHigh
Số lượng phát hiện9
Mức độ nghiêm trọng cao nhấtHigh

Phạm vi đánh giá bao gồm các chức năng công khai của website, các PHP parameter động, các AJAX-like endpoint, static resource, public attachment, HTTP response header, hành vi HTTPS và source code phía client có thể truy cập công khai.


Mục tiêu
#

Các mục tiêu chính của quá trình đánh giá bao gồm:

  • Xác định các chức năng của ứng dụng và attack surface được công khai.
  • Kiểm tra các parameter động để tìm điểm yếu trong việc validation input.
  • Đánh giá HTTP security headers và cấu hình HTTPS.
  • Xác định các vấn đề về information disclosure và cấu hình không an toàn.
  • Thực hiện xác thực có kiểm soát đối với các lỗ hổng có khả năng khai thác.
  • Đánh giá tác động bảo mật của các phát hiện.
  • Đưa ra khuyến nghị khắc phục và hướng dẫn retest.

Phương pháp luận
#

Quá trình đánh giá tuân theo OWASP Web Security Testing Guide và được tổ chức theo các hoạt động sau:

  1. Information Gathering và Reconnaissance
  2. Kiểm thử Configuration and Deployment Management
  3. Đánh giá Identity, Authentication, Authorization và Session Management
  4. Kiểm thử Input Validation
  5. Đánh giá Error Handling
  6. Đánh giá Weak Cryptography và HTTPS
  7. Đánh giá Business Logic
  8. Client-Side Testing
  9. AJAX/API-like Endpoint Testing
  10. Reporting và lập kế hoạch khắc phục

Quy trình kiểm thử
#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
Reconnaissance
Attack Surface Mapping
Passive Testing
Manual Active Testing
Vulnerability Validation
Risk Assessment
Remediation Planning
Reporting

Công cụ sử dụng
#

Các công cụ và kỹ thuật sau được sử dụng trong quá trình đánh giá:

  • Burp Suite — HTTP interception, tạo sitemap, phân tích request/response và xác thực thủ công
  • OWASP ZAP — passive proxying, tạo sitemap và lập inventory URL
  • curl — phân tích HTTP response và security header
  • dig — DNS reconnaissance
  • Web Browser / Developer Tools — kiểm thử thủ công ứng dụng và phân tích phía client

Burp Suite và OWASP ZAP chủ yếu được sử dụng cho phân tích thụ động và lập bản đồ attack surface, trong khi việc xác thực chủ động được thực hiện thủ công với tốc độ thấp nhằm giảm thiểu tác động đến hệ thống.


Các phát hiện chính
#

IDPhát hiệnMức độTrạng thái
WEB-01Error-Based SQL InjectionHighConfirmed
WEB-02Thiếu Content Security Policy HeaderMediumConfirmed
WEB-03Thiếu HTTP Strict Transport Security HeaderLowConfirmed
WEB-04Thiếu Referrer-Policy và Permissions-Policy HeaderLowConfirmed
WEB-05AJAX Response dạng JSON được trả về với Content-Type không chính xácLowConfirmed
WEB-06Tài nguyên bên thứ ba được tải mà không có Subresource IntegrityLowConfirmed
WEB-07Xác định các file và đường dẫn attachment có thể truy cập công khaiInformationalConfirmed
WEB-08Comment phục vụ phát triển tồn tại trong HTML/JavaScript productionInformationalConfirmed
WEB-09Yêu cầu đánh giá Client-Side DependencyInformationalObserved

Phát hiện nổi bật
#

WEB-01 — Error-Based SQL Injection
#

Mức độ: High Trạng thái: Confirmed Danh mục: Input Validation OWASP WSTG: WSTG-INPV-05 — Testing for SQL Injection

Mô tả
#

Một parameter trên trang sản phẩm được xác định là tồn tại lỗ hổng Error-Based SQL Injection.

Một input được kiểm thử có kiểm soát và không gây phá hoại đã khiến ứng dụng trả về database error trong HTTP response. Response này làm lộ thông tin database và một phần cấu trúc câu truy vấn SQL phía backend.

Hành vi dễ bị khai thác được xác định tại một public unauthenticated endpoint.

Bằng chứng
#

Lỗ hổng được xác thực bằng cách so sánh một baseline request bình thường với một request đã được sửa đổi bằng input kiểm thử SQL Injection có kiểm soát.

Request đã sửa đổi khiến application response chứa:

  • Thông báo lỗi database.
  • Phiên bản database backend.
  • Một phần cấu trúc câu truy vấn SQL.

Phiên bản portfolio công khai cố ý loại bỏ các URL, hostname, IP và thông tin nhạy cảm trong raw request.

Tác động
#

Tùy thuộc vào database privilege và logic của ứng dụng, việc khai thác thành công SQL Injection có thể cho phép:

  • Enumeration metadata của database.
  • Truy cập trái phép vào dữ liệu ứng dụng.
  • Tiếp tục khai thác phía server.
  • Thao tác database nếu tài khoản database có đủ privilege.

Thông tin database error bị tiết lộ cũng cung cấp intelligence hữu ích cho các cuộc tấn công có mục tiêu tiếp theo.

Nguyên nhân gốc
#

Hành vi quan sát được cho thấy input do người dùng kiểm soát đã được xử lý không an toàn bên trong câu lệnh SQL phía backend.

Các thông báo lỗi database chi tiết cũng được trả trực tiếp về client thông qua HTTP response production.

Khuyến nghị
#

  • Sử dụng parameterized queries hoặc prepared statements cho tất cả các thao tác database.
  • Thực hiện validation nghiêm ngặt ở phía server đối với các parameter dạng số.
  • Từ chối các input có kiểu dữ liệu không mong đợi trước khi tương tác với database.
  • Tắt SQL error và PHP error output chi tiết trong môi trường production.
  • Trả về các error response chung cho người dùng.
  • Chỉ ghi thông tin chẩn đoán chi tiết vào server-side log.
  • Kiểm tra các dynamic endpoint khác để tìm các SQL Injection tương tự.

Hướng dẫn Retest
#

Sau khi khắc phục, cần thực hiện lại quá trình xác thực SQL Injection có kiểm soát.

Ứng dụng cần:

  • Xử lý an toàn các input không hợp lệ.
  • Không trả về SQL error.
  • Không tiết lộ thông tin về phiên bản database.
  • Không làm lộ các fragment của SQL query.

Các phát hiện bổ sung
#

WEB-02 — Thiếu Content Security Policy Header
#

Mức độ: Medium Trạng thái: Confirmed

Các HTTP response được kiểm tra không chứa header Content-Security-Policy.

CSP cung cấp một lớp phòng vệ bổ sung ở phía browser bằng cách kiểm soát các origin mà từ đó script, style, image, frame và các resource khác được phép tải.

Khuyến nghị
#

Triển khai Content Security Policy phù hợp và ban đầu xác thực policy ở chế độ report-only trước khi chuyển sang enforcement.

Nếu có thể, hạn chế sử dụng unsafe-inline không cần thiết và chuyển sang sử dụng nonce hoặc hash.


WEB-03 — Thiếu HTTP Strict Transport Security Header
#

Mức độ: Low Trạng thái: Confirmed

HTTP traffic được quan sát thấy chuyển hướng sang HTTPS, tuy nhiên các HTTPS response được kiểm tra không chứa header Strict-Transport-Security.

Khuyến nghị
#

Triển khai HSTS với giá trị max-age phù hợp sau khi xác nhận rằng toàn bộ chức năng ứng dụng và các subdomain cần thiết đều hỗ trợ HTTPS.


WEB-04 — Thiếu Referrer-Policy và Permissions-Policy Header
#

Mức độ: Low Trạng thái: Confirmed

Các response được kiểm tra không chứa:

  • Referrer-Policy
  • Permissions-Policy

Các header này cung cấp thêm khả năng hardening bảo mật phía browser, đồng thời giúp kiểm soát thông tin referrer và quyền truy cập vào các browser capability.

Khuyến nghị
#

Triển khai các policy phù hợp dựa trên yêu cầu chức năng của ứng dụng.


WEB-05 — Content Type không chính xác đối với AJAX Response
#

Mức độ: Low Trạng thái: Confirmed

Một AJAX-like endpoint trả về response body có dạng JSON nhưng khai báo response là text/html.

Sự không nhất quán này có thể dẫn đến hành vi không đồng nhất giữa các browser, proxy và công cụ bảo mật.

Khuyến nghị
#

Trả response bằng JSON content type phù hợp:

1
Content-Type: application/json; charset=UTF-8

Ứng dụng cũng cần đảm bảo rằng HTML được tạo động từ response AJAX được encoding và render an toàn.


WEB-06 — Tài nguyên bên thứ ba không có Subresource Integrity
#

Mức độ: Low Trạng thái: Confirmed

Ứng dụng tải các resource từ các nhà cung cấp bên thứ ba mà không quan sát thấy các Subresource Integrity attribute.

Khuyến nghị
#

Khi phù hợp:

  • Triển khai SRI cho các resource được host bên ngoài.
  • Sử dụng crossorigin khi cần thiết.
  • Hoặc self-host các resource của bên thứ ba.
  • Duy trì quy trình cập nhật dependency có kiểm soát.

WEB-07 — File và đường dẫn Attachment có thể truy cập công khai
#

Mức độ: Informational Trạng thái: Confirmed

Quá trình đánh giá xác định các attachment path có thể truy cập công khai và liên quan đến chức năng của website.

Việc attachment có thể truy cập công khai không phải lúc nào cũng là một lỗ hổng nếu các file này được thiết kế để public. Tuy nhiên, các thư mục công khai cần được review để đảm bảo các file nội bộ, bản nháp, backup hoặc dữ liệu nhạy cảm không bị vô tình expose.

Khuyến nghị
#

  • Review các attachment directory có thể truy cập công khai.
  • Xóa các tài liệu nội bộ, backup, bản nháp hoặc tài liệu đã lỗi thời.
  • Tắt directory listing khi phù hợp.
  • Tránh lưu trữ tài liệu riêng tư bên trong web root.
  • Áp dụng access control phù hợp khi cần thiết.

WEB-08 — Comment phục vụ phát triển trong Production Resource
#

Mức độ: Informational Trạng thái: Confirmed

HTML production chứa các cấu trúc menu được comment-out và các comment mang tính chất phục vụ phát triển.

Mặc dù các comment được quan sát không trực tiếp có khả năng khai thác, các development artifact có thể tiết lộ thông tin về implementation hoặc cung cấp thông tin hữu ích cho quá trình reconnaissance.

Khuyến nghị
#

Xóa các comment phục vụ phát triển và code không sử dụng khỏi production resource.


WEB-09 — Đánh giá Client-Side Dependency
#

Mức độ: Informational Trạng thái: Observed

Passive testing xác định nhiều JavaScript và frontend resource nằm trong client-side attack surface công khai.

Một inventory đầy đủ về dependency và việc đánh giá version không nằm trong evidence được cung cấp. Do đó, vấn đề này được ghi nhận là khuyến nghị đánh giá dependency thay vì một finding về dependency có lỗ hổng đã được xác nhận.

Khuyến nghị
#

  • Xác định chính xác version của các JavaScript và CSS library.
  • Nâng cấp các dependency không còn được hỗ trợ hoặc có lỗ hổng.
  • Loại bỏ các library không được sử dụng.
  • Review custom JavaScript để tìm DOM manipulation không an toàn.
  • Tránh render HTML chưa được sanitize từ AJAX response.

Các quan sát về bảo mật
#

Quá trình đánh giá cũng xác định một số điểm tích cực về bảo mật.

Enforce HTTPS
#

HTTP traffic được quan sát thấy chuyển hướng sang HTTPS.

Các Browser Security Header hiện có
#

Các response được kiểm tra bao gồm:

  • X-Frame-Options: SAMEORIGIN
  • X-Content-Type-Options: nosniff

Chức năng công khai của ứng dụng ở mức hạn chế
#

Không xác định được chức năng authentication, payment, shopping cart hoặc user dashboard công khai trong phạm vi được đánh giá.

Cơ chế lọc request mang tính phòng thủ
#

Đã quan sát thấy cơ chế lọc request chống tự động hóa hoặc có đặc điểm tương tự WAF trong quá trình kiểm thử.


Giới hạn kiểm thử
#

Quá trình đánh giá được thực hiện có chủ đích theo phương pháp có kiểm soát và không gây phá hoại.

Automated active scanning không được sử dụng làm phương thức xác thực chính vì các request bất thường có dấu hiệu có thể kích hoạt cơ chế blocking phòng thủ.

Các hoạt động sau không được thực hiện:

  • Kiểm thử Denial-of-Service
  • Brute force với lưu lượng lớn
  • Credential stuffing
  • Phishing hoặc social engineering
  • Khai thác có tính phá hoại
  • Dump hoặc extraction database
  • Truy cập backend trái phép
  • Automated scanning mang tính aggressive
  • Kiểm thử các third-party infrastructure không thuộc phạm vi

Sau khi xác nhận hành vi SQL Injection, không thực hiện database extraction.

Các giới hạn này có nghĩa rằng kết quả đánh giá đại diện cho phạm vi công khai đã được review và điều kiện kiểm thử đã quan sát, chứ không phải bằng chứng rằng ứng dụng hoàn toàn không tồn tại lỗ hổng.


Mức độ ưu tiên khắc phục
#

Mức ưu tiênFindingsThời gian khuyến nghị
P1WEB-01 — SQL InjectionNgay lập tức / 0–7 ngày
P2WEB-02, WEB-05, WEB-091–4 tuần
P3WEB-03, WEB-04, WEB-061–2 tháng
P4WEB-07, WEB-081–3 tháng

Ưu tiên khắc phục cao nhất là WEB-01 — Error-Based SQL Injection.


Kỹ năng thể hiện
#

Thông qua bài đánh giá này, tôi có cơ hội thực hành và thể hiện các kỹ năng bảo mật sau:

  • Black-box Web Application Penetration Testing
  • Web Reconnaissance
  • Attack Surface Mapping
  • HTTP Request/Response Analysis
  • SQL Injection Validation
  • Security Header Assessment
  • Client-Side Security Review
  • AJAX Endpoint Analysis
  • Information Disclosure Analysis
  • Vulnerability Severity Assessment
  • Evidence Collection
  • Remediation Planning
  • Retest Planning
  • Professional Security Reporting

Bằng chứng
#

Các bằng chứng được lựa chọn từ quá trình đánh giá bao gồm:

  • Burp Suite application sitemap
  • OWASP ZAP sitemap
  • Baseline HTTP request/response
  • SQL Injection validation response
  • HTTP security-header analysis
  • AJAX endpoint response analysis
  • Client-side resource inspection

Các screenshot được hiển thị trên portfolio đã được sanitize để loại bỏ thông tin có thể xác định target và các thông tin nhạy cảm.


Bản báo cáo đầy đủ
#

Bản báo cáo đầy đủ đã được sanitize bao gồm methodology chi tiết, findings, evidence register, technical observations, remediation plan, retest guidance và các evidence hỗ trợ.

Tải xuống Pentest Report →


Kết luận
#

Quá trình đánh giá đã xác định một lỗ hổng High đã được xác nhận, cùng với một số điểm yếu có mức độ thấp hơn liên quan đến cấu hình và bảo mật phía client.

Vấn đề đáng chú ý nhất là lỗ hổng Error-Based SQL Injection đã được xác nhận, ảnh hưởng đến một application parameter công khai. Lỗ hổng cho phép input được kiểm soát kích hoạt database error và làm lộ thông tin về database backend.

Các phát hiện còn lại chủ yếu liên quan đến browser security hardening, xử lý Content-Type, integrity của third-party resource, public file exposure, production artifact và quản lý client-side dependency.

Bài đánh giá này cho thấy tầm quan trọng của việc kết hợp công cụ tự động với manual validation và contextual analysis, đặc biệt trong những trường hợp các cơ chế phòng thủ hạn chế việc automated scanning ở mức độ mạnh.