Rate this post

Tất cả các loại ứng dụng (ứng dụng web, máy chủ web, cơ sở dữ liệu, v.v.) sẽ phát sinh lỗi vì nhiều lý do khác nhau. Các nhà phát triển thường bỏ qua việc xử lý các lỗi này hoặc loại bỏ ý tưởng rằng người dùng sẽ cố tình kích hoạt lỗi (ví dụ: gửi một chuỗi trong đó một số nguyên được mong đợi). Khi nhà phát triển chỉ xem xét con đường hạnh phúc, họ quên tất cả những thứ mà người dùng có thể nhập khác mà mã có thể nhận được nhưng không thể xử lý.

Các bài viết liên quan:

Các lỗi đôi khi tăng lên như:

  • stack traces,
  • network timeouts,
  • input mismatch,
  • and memory dumps.

Xử lý lỗi không đúng cách có thể cho phép những kẻ tấn công:

  • Hiểu các API được sử dụng nội bộ.
  • Lập bản đồ các dịch vụ khác nhau tích hợp với nhau bằng cách có được cái nhìn sâu sắc về các hệ thống và khuôn khổ nội bộ được sử dụng, điều này mở ra cánh cửa để tấn công chuỗi.
  • Thu thập các phiên bản và loại ứng dụng đang được sử dụng.
  • Xử lý hệ thống bằng cách buộc hệ thống rơi vào tình trạng bế tắc hoặc một ngoại lệ chưa được khắc phục sẽ gửi tín hiệu hoảng sợ đến động cơ đang chạy nó.
  • Điều khiển bỏ qua trong đó một ngoại lệ nhất định không bị hạn chế bởi logic được đặt xung quanh đường dẫn hạnh phúc.

Mục tiêu kiểm tra

Xác định đầu ra lỗi hiện có.

Phân tích kết quả đầu ra khác nhau được trả về.

Làm thế nào để kiểm tra

Lỗi thường được coi là lành tính vì chúng cung cấp dữ liệu chẩn đoán và thông báo có thể giúp người dùng hiểu rõ vấn đề hoặc để nhà phát triển gỡ lỗi đó.

Bằng cách cố gắng gửi dữ liệu không mong muốn hoặc buộc hệ thống vào các trường hợp và tình huống cạnh nhất định, hệ thống hoặc ứng dụng hầu hết sẽ đưa ra một chút về những gì đang xảy ra trong nội bộ, trừ khi các nhà phát triển tắt tất cả các lỗi có thể xảy ra và trả về một thông báo tùy chỉnh nhất định .

Máy chủ Web

Tất cả các ứng dụng web đều chạy trên một máy chủ web, cho dù đó là một máy chủ tích hợp hay một máy chủ chính thức đầy đủ. Ứng dụng web phải xử lý và phân tích cú pháp các yêu cầu HTTP và vì vậy máy chủ web luôn là một phần của ngăn xếp. Một số máy chủ web nổi tiếng nhất là NGINX, Apache và IIS.

Máy chủ web có thông báo lỗi và định dạng đã biết. Nếu một người không quen với diện mạo của chúng, hãy tìm kiếm chúng trên mạng sẽ cung cấp các ví dụ. Một cách khác là xem tài liệu của họ, hoặc đơn giản là thiết lập một máy chủ cục bộ và phát hiện ra các lỗi bằng cách xem qua các trang mà máy chủ web sử dụng.

Để kích hoạt thông báo lỗi, người kiểm tra phải:

  • Tìm kiếm các tệp và thư mục ngẫu nhiên sẽ không được tìm thấy (404s).
  • Cố gắng yêu cầu các thư mục tồn tại và xem hoạt động của máy chủ (403s, trang trống hoặc danh sách thư mục).
  • Hãy thử gửi một yêu cầu phá vỡ HTTP RFC. Một ví dụ là gửi một đường dẫn rất lớn, phá vỡ định dạng tiêu đề hoặc thay đổi phiên bản HTTP.

Ngay cả khi các lỗi được xử lý ở cấp ứng dụng, việc phá vỡ HTTP RFC có thể khiến máy chủ web tích hợp tự hiển thị vì nó phải xử lý yêu cầu và các nhà phát triển quên ghi đè các lỗi này.

Các ứng dụng

Các ứng dụng dễ bị phát ra nhiều thông báo lỗi nhất, bao gồm: dấu vết ngăn xếp, kết xuất bộ nhớ, ngoại lệ được xử lý sai và lỗi chung. Điều này xảy ra do phần lớn thời gian các ứng dụng được xây dựng tùy chỉnh và các nhà phát triển cần phải quan sát và xử lý tất cả các trường hợp lỗi có thể xảy ra (hoặc có cơ chế bắt lỗi toàn cầu) và những lỗi này có thể xuất hiện từ việc tích hợp với các dịch vụ khác.

Để làm cho một ứng dụng có những lỗi này, người thử nghiệm phải:

  • Xác định các điểm đầu vào có thể mà ứng dụng đang mong đợi dữ liệu.
  • Phân tích kiểu đầu vào dự kiến ​​(chuỗi, số nguyên, JSON, XML, v.v.).
  • Đánh dấu mọi điểm đầu vào dựa trên các bước trước đó để có một kịch bản kiểm tra tập trung hơn.
  • Fuzzing mọi đầu vào với tất cả các lần tiêm có thể không phải là giải pháp tốt nhất trừ khi bạn có thời gian thử nghiệm không giới hạn và ứng dụng có thể xử lý nhiều đầu vào đó.
    • Nếu fuzzing không phải là một tùy chọn, hãy chọn thủ công các đầu vào khả thi có cơ hội cao nhất để phá vỡ một trình phân tích cú pháp nhất định (ví dụ: dấu ngoặc đóng cho nội dung JSON, một văn bản lớn chỉ có một vài ký tự được mong đợi, chèn CLRF với các tham số có thể là được máy chủ phân tích cú pháp và điều khiển xác thực đầu vào, các ký tự đặc biệt không áp dụng cho tên tệp, v.v.).
    • Fuzzing với dữ liệu biệt ngữ nên được chạy cho mọi loại vì đôi khi các trình thông dịch sẽ phá vỡ bên ngoài việc xử lý ngoại lệ của nhà phát triển.
    • Hiểu dịch vụ phản hồi với thông báo lỗi và cố gắng tạo danh sách mờ tinh tế hơn để cung cấp thêm thông tin hoặc chi tiết lỗi từ dịch vụ đó (nó có thể là cơ sở dữ liệu, dịch vụ độc lập, v.v.).
  • Thông báo lỗi đôi khi là điểm yếu chính trong việc lập bản đồ hệ thống, đặc biệt là theo kiến ​​trúc microservice. Nếu các dịch vụ không được đặt đúng cách để xử lý lỗi theo cách chung và thống nhất, thì thông báo lỗi sẽ cho phép người kiểm tra xác định dịch vụ nào xử lý yêu cầu nào và cho phép tấn công tập trung hơn trên mỗi dịch vụ.

Người thử nghiệm cần phải chú ý theo dõi loại phản hồi. Đôi khi lỗi được trả về là thành công với nội dung lỗi, ẩn lỗi trong 302 hoặc đơn giản bằng cách có một cách tùy chỉnh để biểu diễn lỗi đó.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Contact Me on Zalo
Call now