Phương pháp Pentest tổng quan phần 1

Chương 21 Phương pháp Pentest Chương này trình bày phương pháp chi tiết từng bước phương pháp tấn công một ứng dụng web, gồm các loại lỗ hổng và kỹ thuật tấn công được trình bày trong các chương trước Tuy rằng phương pháp này không giúp tìm ra tất cả các lỗ hổng ứng dụng nhất định nhưng sẽ đảm bảo được rằng kiểm thử tất cả khu vực cần thiết trên ứng dụng và đảm bảo tìm thấy nhiều vấn đề nhất với tài nguyên hiện có Hình 1 dưới đây minh họa các công việc chính mà phương pháp luận này mô tả Chương.

Chương 21 Phương pháp Pentest

Chương này trình bày phương pháp chi tiết từng bước phương pháptấn công một ứng dụng web, gồm các loại lỗ hổng và kỹ thuật tấn côngđược trình bày trong các chương trước Tuy rằng phương pháp này khônggiúp tìm ra tất cả các lỗ hổng ứng dụng nhất định nhưng sẽ đảm bảo đượcrằng kiểm thử tất cả khu vực cần thiết trên ứng dụng và đảm bảo tìm thấynhiều vấn đề nhất với tài nguyên hiện có

Hình 1 dưới đây minh họa các công việc chính mà phương phápluận này mô tả Chương này sẽ bám sát sơ đồ và chia nhỏ nhiệm vụ liênquan Số thứ tự tương ứng trong sơ đồ là thứ tự các bước trong phươngpháp luận

Phương pháp luận được trình bày dưới dạng một chuỗi các nhiệm

vụ được tổ chức và sắp xếp phụ thuộc lẫn nhau Trong phương pháp, sựphụ thuộc này được nêu trong mô tả nhiệm vụ Tuy nhiên trong thực tế,người kiểm thử sẽ thường xuyên phải đưa ra quyết định về hướng đánhgiá của mình theo các trường hợp cụ thể Ví dụ:

- Thông tin thu thập được tại một thời điểm nào đó có thể khiếnbạn quay lại bước trước đó để hình thành các cuộc tấn công tậptrung hơn Ví dụ: một lỗi kiểm soát truy cập cho phép liệt kêdanh sách người dùng để thực hiện các cuộc tấn công các chứcnăng xác thực

- Việc phát hiện lỗ hổng chính trong chức năng nào đó của ứngdụng giúp bỏ qua một hoặc một vài giai đoạn kiểm tra ở chứcnăng khác Ví dụ: lỗ hổng lộ mã nguồn chương trình cho phép

đánh giá chức năng chính của ứng dụng theo hướng white boxthay vì black box như thường lệ.

- Kết quả kiểm tra ở một chức năng nào đó giúp phát hiện một lỗhổng nhất định ở chức năng khác để chuyển hướng kiểm thử Vídụ: một lỗi chung trong bộ xác thực đầu vào giúp việc tìm cách

bỏ qua các biện pháp phòng thủ của ứng dụng nhanh chóng

Hình 1.0 Các công việc chính của phương pháp luậnQuy trình trong phương pháp luận này giúp cho công việc kiểm thửtránh khỏi các sơ suất không đáng có, nhưng không bắt buộc tuân thủcứng nhắc Các nhiệm vụ được mô tả trong phương pháp luận này phầnlớn là tiêu chuẩn và chính thống, các cuộc tấn công có thể không chỉ cónhư vậy

Hướng dẫn chung

Khi thực hiện kiểm thử ứng dụng web, người kiểm thử cần tuân thủmột số lưu ý chung, có thể áp dụng cho tất cả các khu vực, chức năngkhác nhau và các ký thuật cần thực hiện

Một số ký tự được coi là đặc biệt trong HTTP request và sẽ đượcencode Khi sửa đổi nội dung request, cần sử dụng URL encode các ký tựnày để đảm bảo chúng diễn giải đúng ý nghĩa:

- & được dùng để phân tách các tham số trong chuỗi truy vấn URL

và nội dung message Để chèn một ký tự & cần encode thành

%26

- = được dùng để phân tách tên và giá trị tham số trong chuỗi truyvấn và nội dung message Để chèn một ký tự = cần encodethành %3d

- ? được dùng để đánh dấu bắt đầu chuỗi truy vấn URL Để chèn

ký tự ? cần encode thành %3f

- Khoảng trắng (space) được dùng để đánh dấu kết thúc URLtrong request và cho biết phần cuối của giá trị cookie trongCookie Header Để chèn khoảng trắng cần encode thành %20hoặc +

- + là encode của khoảng trắng nên để chèn ký tự + cần encodethành %2b

- ; được dùng để tách các cookie riêng lẻ trong Cookie header Đểchèn ký tự ; cần encode thành %3b

- # được dùng để đánh dấu các phân đoạn URL Nếu nhập ký tựnày vào URL, nó giúp cắt bớt URL gửi đến máy chủ Để chèn ký

Trong nhiều trường hợp kiểm thử, người kiểm thử cần thực hiện gửicác chuỗi tạo thủ công, theo dõi phàn hồi của ứng dụng để tìm các điểmbất thường từ đó phát hiện lõ hổng bảo mật Trong một số trường hợp,phản hồi của ứng dụng với một request cụ thể chứa dấu hiệu của lỗ hổngbất kể lỗ hổng đã được kích hoạt hay chưa Trong mọi trường hợp khi đầuvào cụ thể dẫn đến hành vi bất thường, cần kiểm tra lại xem việc gửirequest lành tính có gây ra kết quả tương tự hay không Nếu có, không thểkết luận đó là một lỗ hổng bảo mật

Các ứng dụng thường tích lũy trạng thái từ các request trước đó gâyảnh hưởng đến việc phản hồi các request khác Đôi khi, muốn khai thácmột lỗ hổng dự kiến và xác định nguyên nhân của các hành vi bất thườngcần phải loại bỏ ảnh hưởng của các trạng thái tích lũy Để làm được điều

đó, thông thường chỉ cần bắt đầu một phiên làm việc mới, điều hướng đếnđiểm bất thường bằng các request lành tính sau đó khai thác thác lại

Thông thường, có thể lặp lại bước refresh này bằng cách điều chỉnh cácphần của cookie request container và thông tin bộ nhớ đệm ngoài ra, cóthể sử dụng công cụ Burp Repeater để cô lập request, thực hiện điều chỉnh

và gửi lại request nhiều lần

Một số ứng dụng sử dụng cân bằng tải trong đó HTTP request liêntiếp có thể được xử lý bởi các máy chủ khác nhau Các máy chủ này có thể

có những khác biệt nhỏ về nội dung cấu hình ảnh hưởng đến kết quả khaithác Ngoài ra, một số cuộc tấn công thành công dẫn đến thay đổi trạngthái máy chủ chẳng hạn như tạo file mới Để phân biệt các ảnh hưởng,người kiểm thử có thể phải thực hiện gửi liên tiếp request giống hệt nhau,kiểm tra kết quả của từng request cho đến khi nhận được kết quả từ máychủ liên quan

Khi triển khai kiểm thử ứng dụng web, người kiểm thử phải xác địnhchính xác tên máy chủ, URL, các chức năng được sử dụng và các hạn chếđối với đội ngũ kiểm thử Người kiểm thử cũng cần cho chủ sở hữu nhậnthức chính xác các rủi ro liên quan đến việc thực hiện kiểm thử xâm nhập.Khuyên chủ sở hữu sao lưu mọi dữ liệu quan trọng trước khi bắt đầu côngviệc

1 Xác định chức năng ứng dụng

Hình 1.1 Xác định các chức năng ứng dụng1.1 Xác định chức năng hiển thị (Explore Visible Content)

Cấu hình để trình duyệt sử dụng proxy / spidering tool Cả Burp vàWebScarab đều có thể sử dụng để giám sát và phân tích nội dung trangweb đươc chặn bởi pproxy

Có thể cấu hình trình duyệt sử dụng tiện ích mở rộng như IEWatch

để theo dõi và phân tích nội dung HTTP va HTML đang được trình duyệt xửlý

Sử dụng ứng dụng bình thường, truy cập mọi liên kết và URL, hoànthành tất cả các form và các chức năng nhiều bước Thử với JavaScriptđược cho phép và chặn cũng như cookie được cho phép và chặn nhiềuứng dụng có thể xử lý các cấu hình trình duyệt khác nhau, người dùng cóthể truy cập nội dung đường dẫn mã nguồn khác nhau trong ứng dụng

Nếu ứng dụng sử dụng xác thực, có thể yêu cầu chủ sở hữu cungcấp tài khoản hoặc tạo tài khoản, sử dụng tài khoản này để truy cập cácchức năng được bảo vệ

Khi kiểm tra, theo dõi các request và response bị proxy chặn lại đểhiểu dữ liệu nào đang được trao đổi và cách ứng dụng phía client sử dụng

để kiểm soát hành vi ứng dụng phía máy chủ

Kiểm tra lại kiến trúc trang web được tạo bởi các công cụ spider vàxác định các nội dung và chức năng chưa được dùng (kiểm tra) qua Từkiến trúc trang web xác định vị trí chức năng chưa được kiểm tra (ví dụ:trong Burp Spider, kiểm tra Linked From details) Truy cập từng chức năngbằng trình duyệt để spider phân tích cú pháp phản hồi của máy chủ để xácđịnh các thành phần khác Lặp lại bước này cho đến khi không xuất hiệnthành phần chức năng nào khác

Khi đã duyệt web theo cách thủ công và thụ động, người kiểm thử

có thể chủ động thu thập thông tin ứng dụng bằng các công cụ quét vớitừng URL đã biết bước này có thể làm xuất hiện các nội dung bổ sung khithu thập thông tin theo cách thủ công Trước khi thực hiện thu thập thôngtin thủ công, cần xác định các URL có thể phá vỡ phiên ứng dụng, loạichúng khỏi phạm vi kiểm tra

1.2 Consult Public Resources (sử dụng nguồn công khai)

Sử dụng các công cụ tìm kiếm trên internet (như Wayback Machine)

để xác định các nội dung công khai của đối tượng

Sử dụng các tùy chọn tìm kiếm nâng cao để cải thiện hiệu quả kiểmtra Ví dụ: trên Google, dùng site: để truy xuất tất cả kết quả cho đốitượng, link: truy xuất các trang khác liên kết đến đối tượng Nếu kết quảtìm kiếm không còn xuất hiện đối với ứng dụng hiện tại thì vẫn có thể xemtrong cache của công cụ tìm kiếm nội dung này có thể chứa các liên kếtđến tài nguyên bổ sung chưa bị xóa

Thực hiện tìm kiếm bất kỳ tên, địa chỉ email nào xuất hiện trong nộidung ứng dụng, chẳng hạn như thông tin liên hệ bao gồm cả thông tinkhông hiển thị như HTML comment Ngoài ra, cần tìm kiếm trên các nhóm

và kênh tin tức tìm kiếm bất kỳ chi tiết kỹ thuật nào liên quan đến mụctiêu và cơ sở hạ tầng hỗ trợ của nó được đăng tải trên các diễn đàn

Xem lại các tệp WSDL (Web Service Description Language) để tạodanh sách hàm và các tham số mà ứng dụng có thể sử dụng

1.3 Tìm kiếm các chức năng ẩn (Discover Hidden Content)

Xác định cách ứng dụng xử lý request liên quan đến các mục khôngtồn tại thực hiện một số request thủ công đối với các tài nguyên hợp lệ vàkhông hợp lệ, so sánh các response của máy chủ để xác định khi nào mộtđối tượng không tồn tại

Xác định danh sách các thư mục, file phổ biến và phần mở rộng têntệp phổ biến thêm vào danh sách các tên tồn tại và các tên được suy ra.Xác định quy ước đặt tên của nhà phát triển ví dụ: nếu có các trangAddDocument.jsp và ViewDocument.jsp thì cũng có thể có trangEditDocument.jsp và RemoveDocument.jsp

Kiểm tra code phía client để xác định các manh mối về chức năng

ẩn của máy chủ như HTML comment hay các thành phần form bị vô hiệuhóa

Sử dụng các kỹ thuật tự động hóa được mô tả trong chương 14,thực hiện hàng loạt request với các thư mục, file và phần mở rộng file,theo dõi phản hồi của máy chủ để xác định các thư mục/file tồn tại và cókhả năng truy cập

Thực hiện lặp lại các bước thu thập thông tin này với các chức năngkhác nhau

1.4 Tìm kiếm thành phần mặc định

Chạy Nikto để xác định các nội dung mặc định Sử dụng các tùychọn Nikto để tối đa hóa hiệu quả Ví dụ: sử dụng –root để chỉ định thưmục/khu vực được kiểm tra nội dung mặc định hoặc -404 chỉ định mộtchuooixdaanx đến trang thông báo lỗi File Not Found

Kiểm tra lại kết quả băng phương pháp thủ công, loại bỏ kết quảgiả

Request đến thư mục, chỉ định IP Host header, xác định xem ứngdụng có phản hồi không, nếu có, chạy Nikto với IP này như máy chủ

Request đến thư mục, chỉ định danh sách User-Agent headers nhưwww.useragentstring.com/pages/useragentstring.php

1.5 Liệt kê các chức năng được định danh

Xác định các hàm được truy cập bằng định danh (ví dụ: /admin.jsp?action=editUser hay /main.php?func=A21)

Áp dụng các kỹ thuật trong mục 1.3 đối với từng chức năng riêng lẻ

ví dụ: nếu ứng dụng sử dụng tham số chứa tên hàm Trước tiên, xác địnhhành vi ứng dụng khi tên hàm không hợp lệ và hợp lệ xác định danh sáchtên hàm phổ biến hoặc chu trình thông qua phạm vi cú pháp của các địnhdanh đang sử dụng thử liệt kê các chức năng hợp lệ tự động

Xây dựng kiến trúc ứng dụng dựa trên đường dẫn chức năng thay vìURL Kiểm tra các chức năng, luồng logic và sự phụ thuôc giữa chúng.(xem chương 4)

1.6 Kiểm tra các thông số debug (Test for Debug Parameters)

Chọn các trang/chức năng có khả năng chứa các tham số debug ẩn(chẳng hạn debug = true) Chúng có khả năng xuất hiện trong các chứcnăng chính như đăng nhập, tìm kiếm, tải lên hoặc tải xuống

Sử dụng danh sách tham số gỡ lỗi phổ biến (như debug, test, hide,source) và các giá trị chung (như true, yes, on, 1) Đối với mỗi cặp têntham số/giá trị Gửi từng cặp cho mỗi hàm mục tiêu Đối với POST request,cấp tham số trong cả truy vấn URL và nội dung request Sử dụng các kỹthuật được mô tả trong chương 14 để thực hiện tự động hóa Ví dụ: sửdụng tấn công bomb trong Burp Intruder để kết hợp tất cả các hoán vị củapayload.

Kiểm tra các phản hồi bất thường của ứng dụng để xác định cáctrường hợp mà thông số thêm vào có ảnh hưởng đến quá trình xử lý củaứng dụng

2 Phân tích ứng dụng

Hình 2.2 phân tích ứng dụng2.1 Xác định hàm

Xác định các chức năng cốt lõi của ứng dụng và hoạt động của mỗichức năng khi chúng hoạt động bình thường

Xác định các cơ chế bảo mật cốt lõi được ứng dụng sử dụng và cáchchúng hoạt động Hiểu các cơ chế xác thực, quản lý phiên và kiểm soáttruy cập và các chức năng hỗ trợ chúng, chẳng hạn đăng ký người dùng vàkhôi phục tài khoản

Xác định các chức năng và hành vi rộng hơn, chẳng hạn chuyểnhướng, liên kết ngoài, thông báo lỗi và các chức năng quản trị, ghi nhật ký.

Xác định các chức năng khác với giao diện GUI tiêu chuẩn, đặt têntham số hoặc cơ chế điều hướng được sử dụng ở những vị trí khác, chọn

để kiểm tra chuyên sâu

2.2 Xác định đầu vào dữ liệu

Xác định tất cả các vị trí người dùng đưa dữ liệu vào quá trình xử lýcủa ứng dụng như URL, tham số truy vấn, POST data, cookie và các HTTPheader khác được ứng dụng xử lý

Kiểm tra các cơ chế mã hóa hoặc truyền dữ liệu tùy chỉnh được ứngdụng sử dụng, ví dụ như định dạng chuỗi truy vấn không chuẩn xem xétcác dữ liệu gửi đi có gồm tên và các giá trị tham số không hoặc phươngtiện biểu diến thay thế có được sử dụng không

Xác ddnhj các kênh ngoài băng tần mà thông qua đó người dùng cóthể kiểm soát dữ liệu của bên thứ 3 khác được đưa vào quá trình xử lý dữliệu của ứng dụng ví dụ: ứng dụng web mail xử lý và hiển thị các messagenhận được qua SMTP

2.3 Xác định công nghệ sử dụng

Xác định các công nghệ khác nhau được sử dụng phía máy khách,chẳng hạn form, scripts, cookie, Java Applets, ActiveX controls, đối tượngFlash

Xác định công nghệ đang sử dụng phía máy chủ, gồm ngôn ngữkịch bản, nền tảng ứng dụng, cách tương tác với các thành phần back-endnhư cơ sở dũ liệu và email hệ thống (nếu có thể)

Kiểm tra các tiêu đề HTTP server được trả về trong các responsese,đồng thời kiểm tra các mã nhận dạng phần mềm khác tồn tại trong các

tiêu đề HTTP tùy chỉnh hoặc comment trong mã nguồn HTML Các khu vựckhác nhau của ứng dụng có thể được xử lý bởi các thành phần backendkhác nhau vì vậy có thể nhận được kết quả khác nhau.

Chạy công cụ Httprint để xác định chính xác máy chủ web

Kiểm tra lại kết quả xác định kiến trúc ứng dụng để xác định cácphần mở rộng tệp, thư mục hoặc URL có thể cung cấp manh mối về côngnghệ đang sử dụng trên máy chủ Kiểm tra session token và cookie Sửdụng Google để tìm kiếm các công nghệ liên quan

Xác định các tập lệnh chứa các chuỗi tham số truy vấn thuộc thànhphần code của bên thứ ba tìm kiếm trên Google bằng cách sử dụng inurl:.Thực hiện đánh giá sơ bộ các trang web này để xác định các nội dung vàchức năng bổ sung không được lên kết rõ ràng trên ứng dụng (nếu có).2.4 Xây dựng kế hoạch khai thác

Cố gắng xác định chắc chắn cấu trúc bên trong và chức năng củaứng dụng phía máy chủ, các cơ chế được sử dụng để thực hiện hoạt độngtương tác với client Ví dụ: một chức năng xuất đơn đặt hàng của kháchhàng có thể đang tương tác với cơ sở dữ liệu

Đối với mỗi chức năng, xác định các loại lỗ hổng phổ biến có liênquan Ví dụ: các chức năng truyền tải file dễ bị tấn công Path traversal,nhắn tin giữa người dùng dễ bị XSS và các chức năng ‘Liên hệ với chúngtôi’ có thể bị chèn STMP Để biết các ví dụ chi tiết hãy xem chương 4

Lập kế hoạch tấn công, ưu tiên các chức năng quan trọng và các lỗhổng tiềm ẩn nghiêm trọng có liên quan Sử dụng kế hoạch khai thác nàycho các bước còn lại của phương pháp luận

3 Kiểm tra kiểm soát phía máy khách

Hình 3.3 kiểm tra kiểm soát phía client3.1 Kiểm tra việc truyền dữ liệu qua client

Xác đinh tất cả trường hợp form ẩn, cookie và các tham số URLđược dùng để truyền dữ liệu

Xác định mục đích mục đích sử dụng của các trường hợp trên tronglogic ứng dụng thông qua ngữ cảnh mà nó xuất hiện cũng như tên và giátrị của nó

Sửa đổi giá trị của các trường theo các cách liên quan đến vai tròcủa nó trong chức năng ứng dụng xác định liệu ứng dụng có xử lý giá trịtùy ý không và thông tin này có thể bị lợi dụng để can thiệp vào logic ứngdụng hay phá vỡ các biện pháp kiểm soát bảo mật nào không

Nếu ứng dụng không truyền dữ liệu dạng rõ ràng từ client, ngườikiểm thử có thể tấn công bằng nhiều cách khác nhau Nếu trường bị làmrối hay encode, hãy giải mã thuật toán trộn/encode đó để thay thế dữ liệucần thiết ngay cả khi dữ liệu được mã hóa an toàn vẫn có thể tấn côngphát lại các dữ liệu đó trong các ngữ cảnh khác để can thiệp logic ứngdụng xem chương 5 để biết thêm các ví dụ

Nếu ứng dụng sử dụng ASP.NET ViewState, kiểm tra xem nó có thểgiả mạo hay không hoặc có chứa thông tin nhạy cảm hay không Tuynhiên, ViewState có thể dùng khác nhau trên các trang khác nhau.

- Sử dụng trình phân tích ViewState trong Burp Suite để kiểm traEnableViewStateMac có được bật hay không, nếu có chứng tỏkhông thể sửa

- Giải mã ViewState, kiểm tra xem có chứa dữ liệu nhạy cảm haykhông

- Sửa đổi một trong số các giá trị tham số rồi mã hóa lạiViewState Nếu ứng dụng chấp nhận giá trị sửa đổi chứng tỏ cóthể coi ViewState như kênh đưa dữ liệu tùy ý vào quá trình xử lýcủa ứng dụng thực hiện kiểm tra tương tự đối với toàn bộ dữliệu của ViewState

3.2 Kiểm soát đầu vào phía client

Xác định các trường hợp client kiểm soát đầu vào như giới hạn độdài, kiểm tra JavaScript xác thực thông tin đầu vào trước khi chúng đượcgửi tới server Các kiểm soát này có thể bypass để request tùy ý đếnserver Ví dụ:

<form action=”order.asp” onsubmit=”return Validate(this)”>

<input maxlength=”3” name=”quantity”>

…

Lần lượt kiểm tra các trường đầu vào bằng cách sử dụng các dữ liệuđầu vào không hợp lệ để xác minh xem chúng có được copy đến serverhay không

Khả năng bỏ qua xác thực phía client chưa hẳn là một lỗ hổng tuynhiên, cần kiểm tra kỹ lưỡng quá trình xác thực đang thực hiện xác định

liệu ứng dụng có đang dựa vào kiểm soát phía client để bảo vệ ứng dụngkhỏi các tấn công từ đầu vào không đúng định dạng hay không Đồng thờikiểm tra xem có bất kỳ lỗ hổng nào được kích hoạt bởi những đầu vào nàyhay không.

Kiểm tra các form HTML để xác định các thành phần bị vô hiệu,chẳng hạn nút gửi màu xám Ví dụ:

<input disabled=”true” name=”product”>

Nếu có, thử gửi dữ liệu đến server cùng các thông số khác củaform Xem xét sự ảnh hưởng của chúng đến quá trình xử lý của server cóthể bị lợi dụng để tấn công Ngoài ra, có thể sử dụng proxy tự động để tựđông vô hiệu hóa các trường, chẳng hạn HTML Modification của BurpProxy

3.3 Kiểm tra phần mở rộng của trình duyệt

- Hiểu hoạt động của ứng dụng phía client:

o Thiết lập proxy chặn bắt luồng dữ liệu giữa client và server.Nếu dữ liệu được encode, sử dụng công cụ decode đượctích hợp sẵn trong Burp hoặc Dser Burp plugin dành chojava

o Xác định các chức năng nhạy cảm, sử dụng các công cụchặn để phát lại request hoặc sửa đổi phản hồi của máychủ

- Decompile the Client

o Xác định applet được client sử dụng tìm các loại file đượcrequest qua proxy: .class, .jar (Java); swf (Flash); xap(Silverlight) Ngoài ra, có thể tìm được các thẻ applet trong

mã nguồn HTML ví dụ:

<applet code=”input.class” id=”TheApplet” codebase=”/scripts/”>

o Sử dụng công cụ thích hợp để dịch ngược mã bytecodethành mã nguồn ví dụ:

C:\>jad.exe input.class

Parsing input.class Generating input.jad

Một số công cụ hỗ trợ dịch ngược các thành phần mở rộng trìnhduyệt khác nhau:

Java: Jad

Flash: SWFScan, Flasm/Flare

Silverlight: NET Reflector

Nếu applet được nén thành JAR/XAP/SWF, cần giải nén bằngWinRar hoặc WinZip trước

o Kiểm tra lại mã nguồn có liên quan để hiểu quá trình xử lýđang thực hiện

o Xác định các hàm công khai có thể được ứng dụng đểencode dữ liệu tùy ý của applet

o Nếu không, sửa mã nguồn applet để vô hiệu hóa các xácthực mà nó thực hiện hoặc để encode đầu vào Sau đó,biên dịch lại thành định dạng file gốc bằng cách sử dụngcác công cụ biên dịch do nhà cung cấp cung cấp.

- Attach a Debugger

o Đối với các ứng dụng phía client lớn, thường khó dịchngược toàn bộ ứng dụng, sửa đổi và đóng gói lại mà khônggặp nhiều lỗi đối với các ứng dụng này, việc đính kèmtrình gỡ lỗi thường nhanh hơn JavaSnoop giúp thực hiệnđối với Java, Silverlight Spy giám sát thời gian chạy củaSilverlight client

o Xác định vị trí các chức năng và giá trị chính mà ứng dụngdùng để quản lý logic nghiệp vụ và đặt breakpoint khi cácchức năng mục tiêu được gọi sửa đổi đối số hoặc giá trị trả

về nếu cần để bypass

- Test ActiveX controls

o Xác định trình điều khiển ActiveX được ứng dụng sử dụng.tìm các file .cab được request qua proxy hoặc các thẻobject HTML Ví dụ:

thay đổi đường dẫn thực thi của chương trình Xem chương

5 để biết thêm chi tiết

o Có thể đoán mục đích của các phương thức ActiveX dựatrên tên và các tham số truyền cho chúng Sử dụng công

cụ COMRaider để liệt kê các phương thức kiểm tra cáctrường có khả năng dự đoán để thay đổi hành vi của ứngdụng

o Nếu mục đích của trình điều khiển là thu thập hoặc xácminh thông tin nhất định về client, sử dụng công cụFilemon và Regmon để theo dõi các thông tin mà trình điềukhiển thu thập được Thường có thể tạo các mục phù hợptrong system registry và filesystem để sửa các đầu vàođược điều khiển sử dụng và do đó ảnh hưởng đến hành vicủa nó

o Kiểm tra ActiveX control để tìm các lỗ hổng có thể bị khaithác để tấn công người dùng ứng dụng khác Có thể sửaHTML gọi một hàm để chuyển dữ liệu tùy ý đến cácphương thức và theo dõi kết quả Kiểm tra các phươngthức có tên đặc biệt như LauchExe Có thể sử dụngCOMRaider thực hiện một số kiểm tra cơ bản đối vớiActiveX control để xác định các lỗi như tràn bộ đệm

Nếu ứng dụng không triên khai cơ chế đăng ký tài khoản, xác định

cơ chế triên khai cấp tài khoản người dùng

4.2 Kiểm tra chất lượng mật khẩu

Kiểm tra các quy tắc được áp dụng đối với mật khẩu người dùng

Sử dụng chức năng đăng ký hoặc thay đổi mật khẩu, đặt nhiều loạimật khẩu yếu khác nhau để xác định các quy tắc được thực thi trong thực

tế thử với mật khẩu ngắn, chỉ có chữ/số, các mật khẩu trong từ điển vàtên người dùng

Kiểm tra xác thực không đầy đủ Đặt mật khẩu mạnh, thực hiênđăng nhập bằng các biến thể khác nhau của mật khẩu này như thay đổi 1

ký tự, xóa ký tự cuối, xóa ký tự đặc biệt,… nếu thử thành công, cố gắngxác định quá trình xác thực nào đang được thực thi

Sau khi thiết lập các quy tắc chất lượng mật khẩu tối thiểu và mức

độ xác thực mật khẩu, xác định phạm vi giá trị khi tấn công dò mật để cóxác suất thành công cao Xác định tài khoản có thể không tuân theo quyđịnh mật khẩu mạnh

4.3 Kiểm tra khả năng liệt kê tên người dùng

Xác định vị trí người dùng gửi username trong các chức năng, gồmnhập thông tin trên màn hình, form ẩn hoặc cookie Các vị trí phổ biến nhưđăng nhập, đăng ký, thay đổi mật khẩu, đăng xuất, khôi phục tài khoản

Với mỗi vị trí, gửi 2 request, gồm tên người dùng hợp lệ và khônghợp lệ kiểm tra reponse của server đối với từng request gồm mã trạngthái HTTP, chuyển hướng, thông tin hiển thị trên màn hình, các bất thườngtrong mã nguồn HTML, thời gian server phản hồi các thay đổi có thể rấtnhỏ (ví dụ: cùng thông báo lỗi nhưng khác kiểu chữ, dâu chấm/phẩy) Sửdụng chức năng lịch sử intercept của proxy để kiểm tra traffic WeScarab

có chức năng so sánh 2 phản hồi để tìm ra sự khác biệt giữa chúng

Nếu có sự bất thường, lặp lại kiểm tra đối với cặp giá trị khác để xácđịnh sự khác biệt làm cơ sở cho việc liệt kê người dùng tự động.

Kiểm tra nguồn rò rỉ thông tin cho phép liệt kê tên người dùng hợp

lệ ví dụ: chức năng ghi log, danh sách người dùng đăng ký thực tế vàcomment tên/email trong mã nguồn

Xác định các xác thực phụ chấp nhận tên người dùng và kiểm traxem nó có sử dụng để liệt kê tên người dùng hay không Đặc biệt lưu ýđến trang đăng ký cho phép đặc tả tên người dùng

4.4 Kiểm tra khả năng đoán mật khẩu

Xác định vị trí người dùng gửi thông tin đăng nhập hai trường hợpchính thường là đăng nhập và thay mật khẩu chức năng thay đổi mậtkhẩu chỉ thành mục tiêu tấn công nếu có thể dùng bất kỳ username nào

Tại mỗi vị trí, kiểm tra thủ công username hợp lệ nhưng thông tinxác thực không hợp lệ, theo dõi phản hồi của ứng dụng để xác định sự bấtthường sau khoảng 10 lần đăng nhập không thành công, nếu ứng dụngkhông thông báo khóa tài khoản, đăng nhập bằng thông tin xác thực hợp

lệ nếu đăng nhập thành công, chính sách khóa tài khoản có thể khônghiệu lực

Nếu không có tài khoản hợp lệ, cố gắng liệt kê tên người dùng hợp

lệ để thử, theo dõi bất kỳ thông báo khóa tài khoản Tuy nhiên, việc thửnày có thể khóa tài khoản người dùng khác

4.5 Kiểm tra chức năng khôi phục tài khoản

Xác định chức năng cho phép ứng dụng khôi phục tài khoản khiquên thông tin đăng nhập thường là chức năng Quên mật khẩu

Xác định hoạt động của chức năng khôi phục tài khoản bằng cáchthực hiện toàn bộ quy trình khôi phục bằng tài khoản kiểm soát

Nếu chức năng sử dụng thử thách chẳng hạn như câu hỏi bí mật,xác định xem người dùng có thể đặt hoặc chọn thử thách của riêng họtrong khi đăng ký hay không Nếu có, sử dụng danh sách username đã liệtkê/thông dụng để thu thập danh sách các thử thách và xem lại danh sáchnày để xác định tên dễ đoán.

Nếu hàm sử dụng gợi ý mật khẩu, hãy thực hiện thu thập danh sáchcác gợi ý mật khẩu và xác định các mật khẩu dễ đoán

Thực hiện tương tự đối với các trường hợp khôi phục tài khoản đốivới tài khoản đã thực hiện tại chức năng đăng nhập chính để đánh giá lỗhổng đối với các tấn công brute force

Nếu chức năng liên quan đến gửi e-mail cho người dùng để hoàn tấtquá trình khôi phục, tìm điểm yếu cho phép bạn kiểm soát tài khoản củangười dùng khác Xác định xem có thể kiểm soát địa chỉ mà e-mail để gửithông tin khôi phục tài khoản không Nếu thư chứa URL khôi phục duynhất, nhận bằng địa chỉ e-mail hợp lệ và xác định khả năng dự đoán URLcủa người dùng khác Áp dụng phương pháp được mô tả trong bước 5.3 để

dự đoán

4.6 Kiểm tra chức năng “remember me”

Nếu chức năng đăng nhập chính hoặc logic hỗ trợ của nó có chứachức năng “Remember me”, sử dụng chức năng này và xác đinh tác dụngcủa nó Nếu chức năng này cho phép người dùng đăng nhập vào nhữnglần tiếp theo mà không cần nhập bất kỳ thông tin đăng nhập nào, cầnkiểm tra xem chức năng này có chứa lỗ hổng nào không

Kiểm tra chặt chẽ tất cả các cookie được đặt khi chức năng

“rememer” được kích hoạt Tìm kiếm các dữ liệu nhận dạng người dùng cóthể dự đoán

Ngay cả khi dữ liệu lưu trữ được encode/encrypt, kiểm tra các thôngtin xác thực khác để xác định cơ chế và tìm cách decode/decrypt Áp dụngphương pháp được mô tả trong chương 5.2 để xác định các dữ liệu đặcbiệt.

Tùy thuộc kết quả, sửa đổi nội dung cookie theo những cách phùhợp nhằm cố gắng giả dạng thành những người dùng khác của ứng dụng.4.7 Kiểm tra chức năng mạo danh

Nếu ứng dụng chứa bất kỳ chức năng nào cho phép một ngườidùng mạo danh người khác, kiểm tra kỹ chức năng này xác định các lỗhổng cho phép mạo danh người dùng tùy ý mà không cần được ủy quyền

Kiểm tra các dữ liệu do người dùng cung cấp dùng để xác địnhngười dùng truy cập vào hệ thống cố gắng mạo danh người dùng khácđặc biệt là quản trị viên, giúp nâng cao đặc quyền

Nếu thực hiện tấn công mật khẩu tự động (như brute force) lên cáctài khoản người dùng khác cần tìm các tài khoản có thể có nhiều hơn 1mật khẩu hợp lệ hoặc nhiều tài khoản có cùng một mật khẩu bởi quản trịviên có thể dùng mật khẩu này để truy cập ứng dụng với bất kỳ ngườidùng nào

4.8 Kiểm tra tính duy nhất của tên người dùng

Nếu ứng dụng có chức năng tự đăng ký cho phép người dùng điềnusername mong muốn, thử đăng ký hai lần cùng một username với cácmật khẩu khác nhau

Nếu ứng dụng chặn lần đăng ký thứ hai, người kiểm thử có thể khaithác hành vi này để liệt kê các tên người dùng đã đăng ký

Nếu ứng dụng đăng ký cả hai tài khoản, xác định hành vi của ứngdụng khi xảy ra xung đột tên người dùng và mật khẩu Cố gắng thay đổi

mật khẩu của một trong các tài khoản để khớp với mật khẩu của tài khoảnkia Ngoài ra, xác định hành vi ứng dụng khi đăng ký hai tài khoản có tênngười dùng và mật khẩu giống hệt nhau.

Nếu ứng dụng cảnh báo hoặc tạo ra lỗi khi xảy ra xung đột giữa tênngười dùng và mật khẩu, điều này có thể cho phép thực hiện một cuộc tấncông mật khẩu lên tài khoản người dùng khác Nhắm mục tiêu mộtusername được liệt kê hoặc đoán và cố gắng tạo các tài khoản cóusername này và các mật khẩu khác nhau Khi ứng dụng thông báo lỗi đốivới một mật khẩu cụ thể, có thể mật khẩu được đặt trùng với mật khẩucủa tài khoản mục tiêu

Nếu ứng dụng chấp nhận được sự va chạm username và mật khẩu

mà không có lỗi, hãy đăng nhập bằng thông tin đăng nhập gây xung đột.Xác định điều gì sẽ xảy ra và liệu hành vi của ứng dụng có thể bị lợi dụng

để truy cập trái phép vào tài khoản của người dùng khác hay không

4.9 Kiểm tra khả năng dự đoán thông tin xác thực

Nếu ứng dụng tự động tạo tên người dùng hoặc mật khẩu, lấy cácgiá trị liên tiếp và cố gắng xác đinh quy luật của chúng

Nếu tên người dùng được tạo theo cách có thể dự đoán được, xácđịnh danh sách các tên người dùng hợp lệ có thể có Sử dụng cách này làm

cơ sở để đoán mật khẩu tự động và các cuộc tấn công khác

Nếu mật khẩu được tạo theo cách có thể dự đoán được, xác địnhdanh sách các mật khẩu có thể được cấp cho người dùng ứng dụng khác.Kết quả của bước này có thể được kết hợp với bất kỳ danh sách tên ngườidùng nào để thực hiện một cuộc tấn công đoán mật khẩu

4.10.Kiểm tra truyền thông tin xác thực không an toàn

Xem qua tất cả các chức năng xác thực liên quan đến việc truyềnthông tin đăng nhập, bao gồm đăng nhập chính, đăng ký tài khoản, thayđổi mật khẩu và bất kỳ trang nào cho phép xem hoặc cập nhật thông tin

hồ sơ người dùng Giám sát tất cả lưu lượng đi qua theo cả hai hướng giữamáy khách và máy chủ bằng cách sử dụng proxy

Xác định trường hợp mà thông tin xác thực được truyền theo mộttrong hai hướng Đặt quy tắc chặn trong proxy để gắn cờ các tin nhắnchứa các chuỗi cụ thể

Nếu thông tin đăng nhập từng được truyền trong chuỗi truy vấnURL, chúng có thể bị tiết lộ trong lịch sử trình duyệt, trên màn hình, trongnhật ký máy chủ và trong tiêu đề Referer header khi sử dụng các liên kếtcủa bên thứ ba

Nếu thông tin đăng nhập từng được lưu trữ trong cookie, chúng cóthể dễ bị tiết lộ thông qua các cuộc tấn công XSS hoặc các cuộc tấn côngquyền riêng tư cục bộ

Nếu thông tin xác thực đã từng được truyền từ máy chủ đến máykhách, chúng có thể bị xâm phạm thông qua bất kỳ lỗ hổng nào trongquản lý phiên hoặc kiểm soát truy cập hoặc trong một cuộc tấn công XSS

Nếu thông tin xác thực đã từng được truyền qua một kết nối khôngđược mã hóa, chúng rất dễ bị chặn bắt

Nếu thông tin đăng nhập được gửi bằng HTTPS nhưng bản thânform đăng nhập được tải bằng HTTP, ứng dụng dễ bị tấn công man-in-the-middle để lấy thông tin đăng nhập

4.11.Kiểm tra phân phối không an toàn

Nếu tài khoản được tạo qua một số kênh ngoài băng tần hoặc ứngdụng có chức năng tự đăng ký bỏ trống tất cả thông tin đăng nhập banđầu của người dùng, hãy thiết lập phương tiện phân phối thông tin đăngnhập cho người dùng mới Các phương pháp phổ biến thường là gửi tinnhắn đến e-mail hoặc địa chỉ bưu điện

Nếu ứng dụng tạo URL kích hoạt tài khoản được phân phối ngoàidải, thử đăng ký nhiều tài khoản mới liên tiếp và xác định quy luật trongcác URL bạn nhận được Nếu một xác định được quy luật, hãy cố gắngđoán các URL được gửi đến người dùng gần đây và sắp tới, đồng thời cốgắng sử dụng các URL này để chiếm quyền tài khoản của họ

Thử sử dụng lại một URL kích hoạt nhiều lần và xem liệu ứng dụng

có cho phép điều này hay không Nếu không, khóa tài khoản đích trước khi

sử dụng lại URL và xem liệu URL có còn hoạt động hay không Xác địnhkhả năng đặt lại mật khẩu người dùng khi thực hiện hành động này

4.12.Kiểm tra lưu trữ không an toàn

Nếu chiếm được gái trị băm của mật khẩu người dùng, cần kiểm tracác tài khoản có cùng giá trị băm Cố gắng đăng nhập bằng các mật khẩuphổ biến để có giá trị băm phổ biến nhất

Sử dụng rainbow table để cố gắng khôi phục mật khẩu dạng rõ.4.13.Kiểm tra logic xác thực

4.13.1 Kiểm tra lỗi logic

Đối với mỗi chức năng mà ứng dụng kiểm tra thông tin đăng nhậpcủa người dùng, bao gồm cả chức năng đăng nhập và thay đổi mật khẩu,hãy thực hiện quy trình theo cách thông thường, sử dụng tài khoản hợp lệ.Lưu ý mọi tham số request được gửi đến ứng dụng