-
27/04/2017
-
29
-
76 bài viết
Dynamic Application Security Testing và công cụ hỗ trợ
Xin chào bà con!
Dạo gần đây, công ty mình bắt nghiên cứu nhiều về việc pentest tự động trên các phần mềm đã chạy production trên internet. Sẵn tiện đang bí ý tưởng viết bài, mình xin phép lấy luôn đề tài này để làm chủ đề bài chuyên môn chia sẻ với bà con.
Việc pentest tự động trên các production có sẵn trong thuật ngữ tiếng anh gọi là Dynamic application security testing hay còn được biết là DAST. DAST là hoạt động kiểm tra trên các chương trình đã chạy để có thể xác định các lỗ hổng bảo mật của chương trình đó. Trong bài viết này, mình sẽ đi sâu tìm hiểu về cách nó hoạt động và cách thức để chọn 1 công cụ hỗ trợ hợp lí nhất.
Trước hết hãy cùng nhau có cái nhìn tổng quát về DAST nhé. Với DAST thì scanner có thể gửi các request với malicious payload để mô phỏng tới application và đánh giá các response được nhận lại dựa trên các dấu hiệu của lỗi bảo mật. Khi scanner chạy qua các testcase bằng việc mô phỏng tấn công đó, mọi lỗi tiềm ẩn đều được lưu lại để xem xét và đánh giá sâu hơn.
Với việc chạy DAST, chúng ta sẽ có những cái nhìn cụ thể hơn về các lỗ hổng trên một chương trình. Thậm chí, chúng ta có thể cho nó chạy trước trên các môi trường test để chắc chắn rằng các lỗ hỗng sẽ được phát hiện trước khi được đưa lên internet.
Vậy DAST hoạt động như thế nào?
Với việc mô phỏng tấn công, DAST scanner phải scan trên các host đang chạy. Đó có thể là 1 trang web hoặc là web app trên internet. Nhưng lời khuyên chân thành cho bà con là nên scan chương trình dưới dạng môi trường test để tránh trường hợp gây tổn hại cho môi trường production, chẳng hạn như chết app...
Một khi đã có 1 host xác định, dựa trên HTML, Scanner sẽ bắt đầu thu thập dự liệu để xác định tất cả các đường dẫn và hành động có thể xảy ra. Sau đó, scanner sẽ chạy các testcase, gửi request đến tất cả các đường dẫn hoặc endpoint để tìm kiếm tín hiệu trên các response để đánh giá xem có phải là lỗ hổng bảo mật hay không. Cuối cùng, Tất cả các lỗ hổng sẽ được lưu lại và hiển thị trên báo cáo. Tùy thuộc vào loại scanner mà bạn đang sử dụng sẽ có các loại báo cáo khác nhau như là html file, pdf file...
Các bạn luôn thấy mình nhắc đến từ scanner. Vậy scanner ở đây là gì. Thì cụ thể scanner ở đây là các công cụ hỗ trợ cho việc chạy DAST. Trong quá trình nghiên cứu, mình đã thử qua các loại công cụ hỗ trợ dưới đây. Nếu các bạn có biết công cụ nào khác thì đừng quên chia sẻ dưới phần bình luận cho mình và mọi người cùng biết nhé.
DAST production và công cụ.
Trên thị trường hiện nay, có rất nhiều công cụ DAST để hỗ trợ cho các phần mềm enterprise. Một vài công cụ là open source hoặc miễn phí. Mình xin chia sẻ những công cụ mình đã từng trải nghiệm, như:
- ZAP: là một mã nguồn mở ra đời từ 10 năm trước. ZAP được dùng phổ biến để quét các lỗ hổng bảo mật một cách tự động. Nó cũng hỗ trợ scan cho app desktop và API tự động.
- Burp Suite: là sản phẩm của Portswigger. Công cụ này hỗ trợ từ manual cho tới auto scan. Ngoài bản phải trả phí thì cũng có bản miễn phí cho cộng đồng và được dùng phổ biến hiện nay.
- Detectify: là DAST khá mới và hiện đại. Nó có thể scan sâu vào trong các chương trình. Và đặc biệt, Detectify có hỗ trợ tính năng đặt lịch quét vô cùng tiện lợi.
- Rapid7: InsightAppSec là giải pháp DAST của Rapid7. Nó hỗ trợ cho cả việc deployment và đặt lịch scan cho wep app. Tuy nhiên công cụ này có điểm hạn chế là không hỗ trợ trong quá trình DEVOPS.
- Veracode: là một nển tảng bảo mật ứng dụng cho doanh nghiệp với việc cung cấp các giải pháp về SAST, IAST, DAST. Đối với các doạnh nghiệp lớn, Veracode là ứng viên sáng giá hàng đầu.
Với việc quá nhiều công cụ như vậy, các bạn có tự hỏi làm sao để chọn công cụ hỗ trợ phù hợp và quét chính xác nhất hay không?
Để có thể chọn được công cụ hỗ trợ tuyệt với nhất thì mình sẽ chia sẻ một vài điểm mà mình chú trọng khi chọn công cụ đó là chú trọng vào trình tự scan như sau tự động, lên lịch hoặc là thủ công.
Muốn lựa chọn công cụ thích hợp, trước tiên bạn phải hiểu được nhu cầu của mình là gì. Khi cần lựa chọn 1 công cụ, mình thường đặt ra các câu hỏi và tự trả lời để tìm ra công cụ phù hợp nhất. Sau đây, mình sẽ chia sẻ một vài câu hỏi mà mình chú trọng khi chọn công cụ đó là chú trọng vào trình tự scan. Các bạn hãy tham khảo nhé!
Có tự động trong quá trình CI/CD hay không?
Rất nhiều ứng dụng ngày nay đang tự động hóa và tích hợp với DevOps pipeline. Với việc tự động hóa quét lỗ hỗng như vậy thì sẽ có rất nhiều lợi ích cho việc phát hiện và vá lỗ hổng.
- Người phát triển phần mềm có thể được thông báo bất kỳ lỗ hổng bảo mật sớm nhất trước khi đưa lên production. Trong một vài trường hợp thì nó có thể phá vỡ quá trình build để chắc chắn rằng việc có người review trước khi relase ứng dụng.
- Thử nghiệm có thể được chạy đối với các dịch vụ và API cơ bản thay vì ứng dụng trực tiếp của khách hàng, dẫn đến việc xác định vấn đề cơ bản nhanh hơn khi phát hiện ra lỗi
- Với các thử nghiệm trên Pull request, các bước thay đổi nhỏ hơn được kiểm tra, cho phép các nhà phát triển nhanh chóng sửa chữa các lỗ hổng trong khi vẫn ở trong context code đang làm việc
Đối với các nhóm chưa sẵn sàng áp dụng tự động hóa bảo mật ứng dụng, họ có thể chọn chạy quét theo lịch trình thường xuyên đối với ứng dụng. Mặc dù có thể đơn giản là thực hiện việc quét lỗ hỗng ở bên ngoài hệ thống nhưng có một số lo ngại với phương pháp kiểm tra bảo mật ứng dụng động này:
- Quét theo lịch trình thường được thực hiện trên môi trường product. VIệc quét trực tiếp trên đó thì sẽ có những hạn chế để tránh ảnh hưởng đến product. Tuy nhiên, cách tiếp cận này khiến ứng dụng dễ bị tấn công bởi một số cuộc tấn công độc hại nhất như DDOS, ...
- Khi một lỗ hổng được tìm thấy, các quy trình nội bộ sẽ làm ảnh hưởng đến quá trình điều tra và fix bug.
- Các ứng dụng có các chương trình tự bảo vệ như là chống lại BOT, rate-limiting sẽ làm cho việc scan trở nên khó hơn và kém hiệu quả hơn.
Nếu như ứng dụng của bạn yêu cầu người dùng đăng nhập, bạn sẽ muốn các công cụ cũng hỗ trọ việc kiểm tra lỗ hỗng trên quá trình đăng nhập. Nếu như bạn sử dụng việc tự động hóa hoặc là lập lịch để thực hiện scan thì mình nghĩ nó sẽ rất khó để quét ra các lỗ hỗng. Nhưng Có 1 điều bạn nên kiểm tra từ công cụ đó là nó có hỗ trợ cho bạn quét các loại authenticated base như là cookie-based, externel token, và bearer token hay không?
Môi trường bạn thực hiện việc scan là ở đâu production hay stagging?
Như đã đề cập ở trên, có nhiều lợi ích khi thực hiện scan trên staging đó là khả năng tìm được bug trước khi đưa lên internet, không bị ảnh hưởng với các rate-limiting, WAF và rút ngắn được thời gian fix lỗi.
Công cụ được chọn có hỗ trợ scan trên REST API và Single page application (SPA) hay không?
Như ngày này, việc microservice đã ngày càng phát triển, đại đa số các ứng dụng đều sử dụng các API để tưởng tác với nhau và với Single page application. Với các SPA nay được xây dựng trên angular hay react đã dần phổ biển. Với việc không có DOM tĩnh, các công cụ thu thập dữ liệu dưới dạng HTML truyền thống không thể xác định các đường dẫn khác nhau để mô phỏng các bước tấn công trên ứng dụng cho nên để kiểm tra các SPA yêu cầu một công cụ hỗ trợ ajax spider, cũng như một công cụ có thể quét các API.
Và điều cuối cùng mình muốn đề cập đó là
Ai sẽ là người sử dụng công cụ đó. Security Analyst or Engineering Teams?
Khi chọn một công cụ, một trong những cân nhắc hàng đầu phải là cá nhân nào sẽ sử dụng công cụ đó. Trong khi việc kiểm tra và sửa chữa các lỗ hổng bảo mật của ứng dụng thường bao gồm một số nhóm phát triển và bảo mật.
Trên đó là một vài điểm mà mình thường hay để ý khi chọn công cụ kiểm thử tự động.
Nếu như bạn có những điểm nào hoặc là công cụ nào hay hỗ trợ cho việc DAST
scan thì cho mình và mn cùng biết với nhá.
Cảm ơn mọi người đã đọc !!!