Thông báo lỗi/ngoại lệ chi tiết có phải là rủi ro bảo mật không?

Question

Tôi hiện đang kiểm tra mọi biến GET và POST với isset() và ném ngoại lệ khi isset() trả về false.

Ví dụ 1:

if(!isset($_GET['some_var'])) 
    throw new Exception('GET variable [some_var] is not set.'); 

$someVar = $_GET['some_var']; 

Ví dụ 2:

if(!isset($_GET['some_num'])) 
    throw new Exception('GET variable [some_num] is not set.'); 

if(!ctype_digit($_GET['some_num'])) 
    throw new Exception('GET variable [some_num] is not a number.'); 

$someNum = $_GET['some_num']; 

Trong ứng dụng sản xuất của tôi, tôi có một ngoại lệ xử lý toàn cầu mà viết ngoại lệ và lỗi vào một tập tin đăng nhập và sau đó đổi hướng đến một trang xin lỗi chung chung.

Đây có phải là phương pháp hay không? Các trường hợp ngoại lệ và thông báo lỗi mô tả như là những rủi ro ở trên có phải là một hacker có thể đọc thông báo ngoại lệ và sau đó sử dụng thông tin đó để thao tác tập lệnh của tôi) không?

Cảm ơn!

Answer 1

"có thể tin tặc có thể đọc thông báo ngoại lệ và sau đó sử dụng thông tin đó để thao tác tập lệnh của tôi không?"

Có thể.

Thông thường, bạn muốn cung cấp lượng thông tin ít nhất có thể cho người dùng cuối trong điều kiện lỗi. Trong trường hợp này, nếu bạn nói với ai đó một biến nhận cụ thể không tồn tại, thì họ có thể thử cung cấp các giá trị ngẫu nhiên cho biến đó để xem ứng dụng hoạt động như thế nào.

Tất nhiên, bạn cũng phải cân bằng điều này theo nhu cầu của người dùng thực. Nếu biến là một biến mà chúng thường có quyền kiểm soát, thì việc trả lời về một vấn đề với giá trị là hoàn toàn có thể chấp nhận được.

CẬP NHẬT

thời gian gần đây Sau khi chạy vào một loạt các API web mà dường như nghĩ rằng ném thông báo lỗi chung chung là con đường để đi Tôi muốn cập nhật này hơi.

Điều quan trọng là API của web cung cấp một lượng thông tin thích hợp trở lại hệ thống tiêu thụ để họ có thể tìm ra điều gì sai và khắc phục.

Trong một trường hợp gần đây cho API xử lý thanh toán, tài liệu của họ đơn giản là sai. Dữ liệu giao dịch thử nghiệm mà họ đã hiển thị luôn được trả về với "Lỗi máy chủ 500" và chúng tôi không có quyền truy đòi nhưng để có được một trong những nhà phát triển của họ trên điện thoại và cẩn thận thực hiện từng phần tử trong XML của họ. Trong số 50 phần tử, chỉ có một phần tử có cùng tên với "tài liệu nhà phát triển" của họ
Trong một tích hợp khác, chúng tôi đã được cung cấp "Lỗi máy chủ 402". - Cái này KHÔNG phải là cổng thanh toán. Mặc dù không bao giờ được tham chiếu trong tài liệu của họ, dường như thông báo đó có nghĩa là một tham số JSON bị thiếu. Ngẫu nhiên, đó là một tham số không được tham chiếu trong tài liệu của họ và một lần nữa yêu cầu thời gian với nhà phát triển của họ để xác định nó.

Trong cả hai trường hợp trên, sẽ rất hữu ích nếu thông báo lỗi đã phản hồi bằng ví dụ về bài đăng tài liệu hợp lệ. Tương tự như cách các lệnh Unix/DOS cũ sẽ trở lại với thông tin trợ giúp khi bạn truyền các tham số xấu. Tôi thực sự không muốn nói chuyện với các lập trình viên khác.Tôi biết thời gian của họ là tốn kém và họ sẽ thay vì làm một cái gì đó khác hơn là trả lời một cuộc gọi hỗ trợ; nhưng quan trọng hơn, nếu tôi làm việc lúc 10 giờ tối và cần một câu trả lời RFN thì đợi cho đến khi một lập trình viên có thể nhận được điện thoại vào ngày hôm sau hiếm khi là một lựa chọn.

Answer 2

Hiển thị lỗi chi tiết cho người dùng có thể là một nguy cơ bảo mật. Vì trong trường hợp này, chúng chỉ được ghi vào tệp nhật ký và dữ liệu duy nhất mà người dùng nhận được là trang chung không tiết lộ gì cả, bạn có thể mô tả như bạn muốn và không tiết lộ gì trừ khi nhật ký bị xâm nhập.

Answer 3

Thông thường nó được coi là không an toàn để in ra thông báo lỗi hệ thống PHP trên máy chủ sản xuất thay vì tự động ghi nhật ký nó.
Mặc dù tôi không thể tìm thấy bất kỳ điều gì nguy hiểm trong trang lời xin lỗi chung chung.

Answer 4

Lỗi ghi và chặn đầu ra là chính xác bạn nên làm gì. Báo cáo lỗi có thể khó chịu ..

Trong OWASP top 10 cho năm 2007 có Information Leakage and Improper Error Handling, tuy nhiên điều này đã bị xóa vào năm 2010. Bằng cách đặt dispaly_errors=On trong php.ini bạn trở nên dễ bị tổn thương CWE-200. Đường dẫn đầy đủ của ứng dụng web của bạn sẽ được tiết lộ cho kẻ tấn công. Để làm cho vấn đề tồi tệ hơn, bằng cách báo cáo lỗi được kích hoạt nó làm cho nó dễ dàng hơn để tìm SQL injection bằng cách tìm các thông báo lỗi sql.

Khi kết hợp này trên PHP/MySQL ứng dụng mà bạn có thể thực hiện một cuộc tấn công rất nghiêm trọng

$vuln_query="select name from user where id=".$_GET[id]; 

Nếu

http://localhost/vuln_query.php?id=1 union select "<?php eval($_GET[e])?>" into outfile "/path/to/web/root/backdoor.php" 

Mà làm cho truy vấn đầy đủ này:

select name from user where id=1 union select "<?php eval($_GET[e])?>" into outfile "/path/to/web/root/backdoor.php" 

tôi sẽ đảm bảo display_errors=Off và tệp đó FILE đặc quyền đã bị thu hồi vào tài khoản người dùng MySQL của ứng dụng web của bạn.