Checklist những điều cần làm khi pentest ứng dụng web
Bài đăng này đã không được cập nhật trong 3 năm
Hi mọi người, trong quá trình làm pentest thì hầu như ai cũng có những danh sách, đề mục mà mình sẽ theo đó để kiểm tra theo pentest checklist đó. Nếu bạn là một người mới bắt đầu thì bạn có thể làm theo danh sách này của mình cho tới khi bạn tự xây cho mình một danh sách của riêng bạn. Những đầu mục ở đây được mình trích xuất từ hướng dẫn kiểm thử của OWASP vì vậy nên mình tin rằng đây là một tài liệu đáng đọc để bạn có thể bắt đầu.
ROBOTS.TXT TRONG PENTEST CHECKLIST
Hãy đọc file robots.txt. Cá nhân mình thì chưa tìm được gì hay ho ở file này bao giờ. Tuy nhiên bạn cũng không nên bỏ qua nó.
SERVER HEADERS
Để ý kĩ những gì được trả về ở Header của response. Những header quan trọng như Server, X-Powered-by hay X-Generator có thể cho bạn biết backend được viết bằng gì, sử dụng loại reverse proxy nào. Bạn có thể sử dụng Burp Suite để xem được rõ những thông tin nào. Câu lệnh wget ngắn gọn này sẽ giúp bạn lưu lại thông tin của header vào file index.html.
wget --save-headers http://www.site.com/
COOKIES
- Một số cookies có thể chứa username và/hoặc password trong một định dạng được encode. Để decode đơn giản khi bạn không biết thì bạn có thể sử dụng "Send to Decoder" của Burp Suite và bấm "Smart Decode". Best Practice thì cookie không được chứa bất kì sensitive data nào (Đúng rồi, username cũng là sensitive data nhé!)
- Nếu bạn nhìn thấy dòng BIG-IP trong cookie, server có thể đang nằm phía sau một load balancer.
- Hãy chắc chắn rằng cookie đang được cài đặt http-only và secure.
HSTS
Kiểm tra nếu server có đặt Strict-Transport-Security (HSTS) . Header này giúp đảm bảo rằng server luôn sử dụng https để có thể tránh được một số kiểu tấn công như ssl strip.
SECURITY HEADERS
Nếu ứng dụng web được công khai trên internet, bạn có thể sử dụng SecurityHeaders.com để nhìn thấy toàn bộ các security headers. Nếu không thì bạn cũng có thể xem thủ công bằng Developer Tools
- X-Frame-Options: SAMEORIGIN
- X-XSS-Protection: 1; mode=block
- X-Content-Type-Options: nosniff
SSL CIPHERS
Nếu ứng dụng web sử dụng HTTPS, kiểm tra bảo mật cho TLS.
- Weak Ciphers: Chạy lệnh sau, để ý bất cứ những ciphers nào không được rate mức A.
nmap --script ssl-enum-ciphers -p 443 www.example.com
KIỂM TRA CÁC HTTP METHODS
Để kiểm tra xem webapp đang hỗ trợ những methods nào, bạn có thể chạy lệnh sau. 99% thì mọi thức đều ổn với các phương thức GET và POST. Không khuyến khích dùng các method khác. Một số method được cho là nguy hiểm ví dụ như TRACE, PUT vàDELETE.
nmap -p 443 --script http-methods www.example.com
KIỂM TRA XEM BẠN CÓ THỂ BYPASS ACCESS CONTROL BẰNG METHOD HEAD HAY KHÔNG
Tìm kiếm một page mà khi bạn truy cập thì bị chuyển hướng 302. Lúc này, sử dụng method HEAD thay thế cho GET. Nếu bạn nhận được response là 200, thì có nghĩa là access control có gì đó không đúng lắm.
KIỂM TRA CHÍNH SÁCH CROSS DOMAIN
Kiểm tra chính sách cross domain bằng cách thêm crossdomain.xml vào cuối page. Nếu bạn nhận được một file XML có đoạn <allow-access-from domain="*" />, đây cũng là một dấu hiệu của việc có gì đó đang toang. Bạn có thể xem thêm OWASP WSTG-CONF-08.
BRUTE FORCE USERNAME
- Ban đầu, điền một (username đúng + password sai), để ý kết quả trả về và thông báo lỗi nếu có. Tiếp sau đó điền một (username sai + password sai). Nếu bạn nhận được một thông báo lỗi khác với thông báo lỗi ở kết quả trả về lúc nãy tức là bạn có thể brute-force để biết danh sách username trong hệ thống. Ví dụ mình đăng ký website etsy.com bằng email desidero44@yahoo.com sau đó thử đăng nhập bằng mật khẩu sai,tiêp sau đó đăng nhập bằng email desidero55@yahoo.com chưa từng được đăng ký.
"Thông báo mật khẩu sai" tức là username đã đúng
"Thông báo email sai" Tức là email không tồn tại
- Nếu có một page có thể truy cập bằng username site.com/users/my_user_name thì bạn có thể kiểm thử bằng cách điền một username khác. Bạn sẽ nhận được báo lỗi 403 forbidden cho user hợp lệ và 404 nếu user đó không tồn tại.
- Kiểm tra chức năng khôi phục mật khẩu cũng có thể có kết quả khác nhau khi username tồn tại hoặc không.
- Một cách khác nữa là timming attack. Phương thức này sẽ đo thời gian phản hồi của server. Nếu username tồn tại thì server sẽ phản hồi lâu hơn.
KIỂM TRA CHỨC NĂNG ĐĂNG KÝ TÀI KHOẢN
Bạn hãy kiểm tra và tự trả lời các câu hỏi sau. Vì mỗi website một khác nhau nên ở đây không có câu trả lời đúng, sai. Bạn cần kiểm tra thật kĩ và tự đánh giá xem như thế nào là đáng kể, như thế nào thì có thể bỏ qua.
- Có phải ai cũng có thể đăng ký không?
- Chức năng đăng ký có cần phê duyệt bởi ai đó không hay chỉ cần đăng ký là được cấp tài khoản?
- Một người có thể đăng ký nhiều lần hay không?
- Người dùng có thể đăng ký với quyền khác không?
- Điều gì là yếu tố quyết định việc đăng ký thành công?
- Thông tin người dùng có được kiểm tra không?
- Thông tin người dùng có dễ làm giả không?
- Thông tin người dùng có thể bị thay đổi trong quá trình gửi đi không?
- Một admin có thể thay đổi admin khác không hay chỉ tác động tới user?
- Môt admin có thể làm nhiều hơn những gì mà họ được phép không?
- Admin có thể tự hủy quyền của họ không?
- Khi một user bị xóa thì những gì thuộc về họ sẽ được xử lý như thế nào? Bị xóa?? Bị chuyển quyền sử dụng??
OWASP WSTG-IDNT-02, OWASP WSTG-IDNT-03
Kiểm tra xác thực
-
Tên đăng nhập và mật khẩu phải được truyền qua những kênh được mã hóa như HTTPS. OWASP WSTG-ATHN-01
-
Tên đăng nhập và mật khẩu phải được gửi qua phương thức POST. Nếu sử dụng phương thức GET thì có thể bị cached lại bởi trình duyệt hoặc bị ghi vào logs.
-
Nếu ứng dụng web có phần đăng nhập, bạn có thể kiểm tra với những tài khoản, mật khẩu mặc định.
Using Burp to Brute Force a Login Page
KIỂM TRA MỘT SỐ CƠ CHẾ KHÓA
- Sau khi tài khoản bị thử mật khẩu nhiều lần không đúng thì tài khoản đó nên được tự động khóa.Tuy nhiên cần để ý vì nếu số lượt thử quá ít, người dùng có thể thấy khó chịu vì bị khóa khi họ nhỡ quên mật khẩu. Nhưng nếu nó quá lớn thì lại có lợi cho hacker. Với mình thì 5 lần thử là hợp lý.
- Sau khi tài khoản của bạn bị khóa, hãy thử đăng nhập ở một máy tính khác và kiểm tra xem nó có còn đang bị khóa không.
- Nếu quá trình khôi phục mật khẩu có gửi email cho bạn thì hãy thử view-source của nó xem có thông tin nào lạ không. Những reset token thì phải là random và không thể đoán được. Nếu chỉ là id người dùng hay bất cứ thứ gì đó dễ đoán thì có vẻ không an toàn cho lắm.
- Đường dẫn khôi phục mật khẩu thì nên có hạn tối đa một ngày sau đó sẽ hết hạn. Trong trường hợp bạn gửi yêu cầu nhiều lần thì chỉ lần cuối cùng là có hiệu lực. Các đường dẫn trước đó nên được vô hiệu hóa bất kể là đã được sử dụng hay chưa.
KIỂM TRA CHÍNH SÁCH ĐẶT VÀ SỬ DỤNG MẬT KHẨU
- Ứng dụng nên đảm bảo rằng không cho phép người dùng đặt các mật khẩu như asdasd hay 123456.
- Nếu ứng dụng có yêu cầu đổi mật khẩu sau một khoảng thời gian nhất định ( ví dụ như các ứng dụng ngân hàng) thì người dùng không nên được sử dụng 3 mật khẩu gần nhất. Bạn có thể kiểm tra phần này bằng cách thử đổi mật khẩu 3 lần, ở lần thứ 4 thì hãy sử dụng lại mật khẩu cũ của bạn.
- Mật khẩu không nên bao gồm tên đăng nhập
KIỂM TRA CHỨC NĂNG ĐĂNG XUẤT
- Sau khi đăng xuất, hãy thử bấm nút "back" xem có gì lạ không. Nếu bạn thấy trang trước khi bạn đăng xuất thì hãy thử bấm vào một link bất kỳ, nếu bạn có thể xem link đó mà không cần xác thực thì có vẻ cơ chế xác thực đang toang, tuy nhiên cần cẩn thận xác định xem đó là trang được cached hay không. Nếu là cached thì đó không phải là một lỗi bảo mật.
- Sau khi đăng xuất thì hãy thử gọi tới một api, truy cập một trang bằng token/cookie cũ. Nếu vẫn truy cập được thì chức năng đăng xuất chỉ đơn giản là xóa cookie và token chứ không bắt buộc nó hết hạn.
KIỂM TRA CHỨC NĂNG KHÔI PHỤC MẬT KHẨU
- Hãy chắc chắn rằng một người dùng chỉ được phép khôi phục mật khẩu của họ.
- Trong quá trình khôi phục mật khẩu, thử capture lại request và kiểm tra xem trong request có gửi lên username, userid hay thứ gì đó định danh người dùng không, nếu có thì bạn hãy thử đổi sang thông tin định danh của người dùng khác. Trong một số trường hợp bạn có thể khôi phục được mật khẩu của người khác theo cách này.
KIỂM TRA LỖI DIRECTORY TRAVERSAL
Nếu bạn tìm thấy một url hoặc một đoạn cookie chứa tên, đường dẫn tới một file nào đó trong hệ thống, hãy thử đổi filename sang tên một file khác xem có đọc được không. Một số url đáng để thử như
http://example.com/getUserProfile.jsp?item=ikki.html http://example.com/index.php?file=content http://example.com/main.cgi?home=index.htm
FILE UPLOAD
- Hãy chắc chắn rằng ứng dụng web chỉ upload được những loại tệp được cho phép.
- Chức năng upload file nên giới hạn dung lượng file có thể tải lên.
- API upload file không nên được gọi đi gọi lại nhiều lần, nên có token để check, tránh trường hợp dẫn tới DDOS qua chức năng upload file.
- Kiểm tra xem bạn có thể chèn mã HTML vào để XSS được không.
- Xem thêm OWAS WSTG-INPL-02
CAPCHA
- Kiểm tra xem web có lưu đáp án của captcha ở client hay không.
- Kiểm tra xem captcha có đổi sau mỗi lần login thất bại không.
- Kiểm tra xem captcha được sinh ra ở server hay client, captcha an toàn là captcha được sinh ra và check hoàn toàn ở phía server.
SQL INJECTION
Thêm một dấu nháy đơn vào một số vị trí id trong url, kiểm tra xem bạn có nhìn thấy lỗi nào không, nếu có thì hãy dùng sqlmap để test kĩ hơn.
Đọc thêm: Hướng dẫn sử dụng SQLMap
Chúc bạn thành công. Bài viết gốc: https://justhackit.net/checklist-nhung-dieu-can-lam-khi-pentest-ung-dung-web-pentest-checklist.hav/ Bài viết tham khảo tại: https://medium.com/@muratkaraoz/web-app-pentest-cheat-sheet-c17394af773
All rights reserved
