Checklist những điều cần làm khi pentest ứng dụng web

Tram Ho

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ó.

OWASP WSTG-INFO-03

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/

OWASP WSTG-INFO-08

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.

OWASP WSTG-SESS-02

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.

OWASP WSTG-CONF-07

Image for post

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

OWASP Security Headers

Image for post

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

Image for post

OWASP WSTG-CRYP-01

Image for post

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

Image for post

OWASP WSTG-CONF-06

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.

OWASP WSTG-CONF-06

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.

OWASP WSTG-CONF-08

Image for post

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 [email protected] sau đó thử đăng nhập bằng mật khẩu sai,tiêp sau đó đăng nhập bằng email [email protected] chưa từng được đăng ký.

Image for post

“Thông báo mật khẩu sai” tức là username đã đúng

Image for post

“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.

OWASP WSTG-IDNT-04

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.

  1. Có phải ai cũng có thể đăng ký không?
  2. 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?
  3. Một người có thể đăng ký nhiều lần hay không?
  4. Người dùng có thể đăng ký với quyền khác không?
  5. Điều gì là yếu tố quyết định việc đăng ký thành công?
  6. Thông tin người dùng có được kiểm tra không?
  7. Thông tin người dùng có dễ làm giả không?
  8. Thông tin người dùng có thể bị thay đổi trong quá trình gửi đi không?
  9. Một admin có thể thay đổi admin khác không hay chỉ tác động tới user?
  10. Môt admin có thể làm nhiều hơn những gì mà họ được phép không?
  11. Admin có thể tự hủy quyền của họ không?
  12. 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-02OWASP 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.

Image for post

Using Burp to Brute Force a Login Page

OWASP WSTG-ATHN-02

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.

OWASP WSTG-ATHN-03

OWASP WSTG-ATHN-09

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

OWASP WSTG-ATHN-07

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.

OWASP WSTG-ATHN-06

OWASP WSTG-ATHN-08

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.

OWASP WSTG-ATHN-09

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

Chia sẻ bài viết ngay

Nguồn bài viết : Viblo