Tiến hành kiểm thử bảo mật cho các ứng dụng Web

Các ứng dụng web cho các dịch vụ khác nhau đã nhận được sự tin tưởng của khách hàng qua một thời gian dài. Hàng triệu triệu dữ liệu được tải và chia sẻ giữa các nền tảng khi mọi người cho rằng các giao dịch được giám sát an toàn.

Tuy nhiên, khi các cuộc tấn công trên mạng tiếp tục gây ra sự hoang mang, nguy cơ bảo mật ứng dụng và dữ liệu của chúng ta trong lĩnh vực kỹ thuật số ngày càng tăng. Sự cố nhiều hơn và có nhiều hơn nữa các cuộc tấn công của virus đang làm tăng nhu cầu kiểm tra an ninh mạnh mẽ.

Các doanh nghiệp tham gia vào thế giới kết nối cần phải nhận ra những lý do chính mà thử nghiệm bảo mật là cần thiết cho các ứng dụng web của họ. Các doanh nghiệp này nên thiết kế các kế hoạch kiểm tra an toàn hiện đại, bao gồm ngay khi bắt đầu dự án của họ để đảm bảo trải nghiệm khách hàng an toàn.

Đây là cách bạn có thể bắt đầu.

Tìm kiếm những khuyết điểm tiềm ẩn về bảo mật

Bước đầu tiên là review code cho bất kỳ lỗ hổng có thể có. Có một số khu vực chung cho lỗ hổng an ninh:

• Hidden field: Lỗ hổng này chủ yếu được khai thác cho các trang web thương mại điện tử. Ứng dụng ẩn các trường ẩn trong các trang web và do tiêu chuẩn mã hoá kém, các trường ẩn này thường chứa thông tin bí mật, chẳng hạn như giá sản phẩm.
• Cross-site scripting: Đây là một trong những lỗ hổng phổ biến nhất. Nó cho phép tin tặc ăn cắp session, xóa trang, nhúng nội dung hoặc chuyển hướng người dùng đến các trang web độc hại.
• Thẩm định yêu cầu cross-site: Nhiều developer bỏ qua tầm quan trọng của các token và reauthentication ngẫu nhiên trên trang dữ liệu quan trọng. Nếu không có nó, kẻ tấn công có thể thực hiện hành động bởi người dùng mạo danh, chẳng hạn như thêm hoặc xóa tài khoản hoặc sửa đổi thông tin người dùng.

Thực hiện kiểm tra bảo mật từng bước

Hãy xem xét một kịch bản mà một công ty cần kiểm tra bảo mật để được thực hiện trên các ứng dụng của họ. Họ mong đợi gì từ đội kiểm thử? Dưới đây là một cách tiếp cận từng bước có thể nắm bắt được giải pháp cho yêu cầu.

1. Lập kế hoạch và chiến lược

Xây dựng một kế hoạch và chiến lược phải luôn là bước đầu tiên của kiểm thử bảo mật. Tester phải hiểu mục đích kinh doanh, số người dùng truy cập vào ứng dụng và workflow của ứng dụng... để xác định cách kiểm tra cụ thể cho từng kịch bản.

Trước khi thực hiện bất kỳ dự án nào, tốt nhất nên tổ chức một cuộc họp với developer để hiểu được workflow của ứng dụng. Điều này giúp tester xác định các lỗ hổng logic, chẳng hạn như bỏ qua giấy phép, mà các công cụ tự động không thể xác định được.

Doanh nghiệp nên có một con số ballpark - con số gần đúng số người dùng sẽ truy cập vào ứng dụng. Nắm được số lượng người dùng tối đa giúp tester tạo ra số lượng người dùng ảo để xác định các cuộc tấn công từ chối dịch vụ có thể xảy ra. Ngày nay, những cuộc tấn công này rất dễ dàng khai thác.

2. Thực hiện mô hình mối đe dọa

Mô hình các mối đe dọa cấp cao đối với ứng dụng cho phép kiểm tra đánh giá các rủi ro có thể và các kịch bản liên quan đến nó. Mô hình mối đe dọa xác định các khu vực yếu của ứng dụng, giúp sửa các bài kiểm tra.

Sau khi bản thiết kế hoàn thiện, phần kỹ thuật bắt đầu, nơi các thành phần được xác định để phát triển. Nó có thể là ngôn ngữ mã hóa, nền tảng, công nghệ stack, vv Mỗi thành phần đi kèm với tập hợp các điểm yếu và điểm mạnh của nó, do đó điều quan trọng là xác định các lỗ hổng trước giai đoạn code. Điều này giúp xác định các lựa chọn an toàn hơn và giảm đáng kể chi phí để sửa chúng.

Ví dụ, nếu ứng dụng được phát triển trong .NET, điều quan trọng là phải hiểu được các lỗ hổng có trong các thành phần khác nhau hỗ trợ ứng dụng, chẳng hạn như phiên bản .NET, phiên bản IIS, v.v. Điều này giúp xác định các mối đe dọa về nghiệp vụ và kiến trúc.

3. Chọn công cụ kiểm thử

Để đánh giá một ứng dụng, bắt buộc phải sử dụng các công cụ thích hợp. Mọi công cụ mã nguồn mở và công cụ độc quyền đều có điểm mạnh và điểm yếu, vì vậy các công cụ nên được lựa chọn dựa trên khả năng làm việc tốt nhất cho ứng dụng. Các công cụ mã nguồn mở như Zed Attack Proxy và Nmap cũng cho phép người kiểm tra sửa đổi bằng cách sử dụng các tập lệnh tùy chỉnh.

4. Kiểm thử một cách sáng tạo

Mặc dù bạn thực hiện một số bài kiểm thử bảo mật bằng các công cụ tự động, nhưng tin tặc trở nên thông minh hơn, điều quan trọng là con người phải suy nghĩ bên ngoài hộp kiểm thử của họ. Xác định các lỗ hổng bảo mật hợp lý là điều khác biệt giữa một tester dày dặn và một tester thông thường.

Chẳng hạn, khi nói về kiểm soát truy cập HTTP, cơ chế CORS có khả năng bị tấn công thông tin thấp, nhưng nếu nó được kết hợp với CSRF, nó sẽ có một tác động rất lớn đến ứng dụng. Điều này đã được thực hiện cho một ngân hàng lớn ở châu Âu. Một ví dụ khác là việc tiếp quản tài khoản thông qua các tấn công tiêu đề của máy chủ. Một thay đổi đơn giản tên máy chủ khi yêu cầu một đường link đặt lại mật khẩu có thể gây hại, vì phần còn lại của liên kết sẽ có tên miền của kẻ tấn công và chúng có thể truy cập vào mật khẩu của tài khoản của bạn. Điều này có thể xảy ra khi các nhà phát triển quên giới hạn sử dụng lại các liên kết đặt lại mật khẩu, nhưng một teser thông minh sẽ biết để tìm ra điều đó.

5. Nghĩ về an ninh ở mọi bước

Mặc dù thử nghiệm bảo mật ứng dụng web thủ công có thể hạn chế việc kiểm tra đến một số lượng các thông số rõ ràng, một máy quét tự động có thể đảm bảo rằng mọi tham số được quét cho khoảng trống. Tuy nhiên, tích hợp bảo mật như một quá trình trong suốt vòng đời phát triển phần mềm sẽ đảm bảo rằng ứng dụng này sẽ trơn tru hơn, vì hầu hết các khiếm khuyết đã được giảm nhẹ ở giai đoạn rất sớm.

Kiểm thử bảo mật có thể được tự động khi quá trình phát triển hoàn tất và mã code được xây dựng cho ứng dụng đang được thử nghiệm bằng cách tận dụng Jenkins hoặc bất kỳ khuôn khổ tự động hóa nào và IP và URL có thể được cung cấp động đến các công cụ mã nguồn mở như Zed Attack Proxy hoặc w3af hoặc nhiều các công cụ thương mại khác.

Kết hợp các loại Kiểm thử bảo mật khác nhau

Kiểm tra an ninh ứng dụng tĩnh (SAST) bao gồm kiểm tra nội bộ của ứng dụng, nơi teser hoặc công cụ kiểm tra ứng dụng với quyền truy cập không giới hạn đến mã nguồn hoặc mã nhị phân. Nó có thể được thực hiện cả bằng tay và tự động và kiểm tra các ứng dụng cho các lỗ hổng phức tạp có thể không bị phát hiện.

Thử nghiệm bảo mật ứng dụng động (DAST) thử nghiệm ứng dụng bên ngoài trong khi chạy ở chế độ thử nghiệm hoặc trong môi trường sản xuất. Nó giúp theo dõi nhanh chóng, linh hoạt, và khả năng mở rộng của ứng dụng để tích hợp liền mạch với chiến lược bảo mật của công ty.

Các ứng dụng bảo mật ứng dụng tương tác (IAST) kết hợp SAST và DAST và tập hợp thế mạnh của cả hai phương pháp. Những loại kiểm tra an ninh nào sẽ hữu ích hoàn toàn phụ thuộc vào các yêu cầu và mục tiêu kinh doanh, nhưng áp dụng cả hai phương pháp này hoạt động có hiệu quả để giảm nguy cơ tấn công không gian mạng.

Giữ an toàn cho người dùng của bạn

Cũng như bất kỳ loại thử nghiệm nào, thử nghiệm bảo mật cho các ứng dụng web cần bắt đầu với việc hoạch định chiến lược hoàn chỉnh và đánh giá các rủi ro có thể xảy ra và các cuộc tấn công nhằm xây dựng các bài kiểm tra hiệu quả nhất.

Trong khi tự động hóa kiểm thử bảo mật của bạn có thể giảm bớt nỗ lực và làm cho quá trình nhanh hơn và hiệu quả hơn nhiều, thì phải có một người để hiểu và dự đoán quy trình suy nghĩ của các hacker tiềm năng. Người kiểm thử cần phải sáng tạo trong nỗ lực kiểm tra để giữ an toàn cho người dùng khi sử dụng sản phẩm của họ.

Bài viết tham khảo và dịch từ nguồn: https://www.stickyminds.com/article/conducting-security-testing-web-applications