2010-12-12 30 views
9

Có rất nhiều lý do hiệu suất tại sao các ứng dụng không nên chạy trong chế độ gỡ lỗi = "true" (good rundown from Scott Gu), nhưng có bất kỳ vector tấn công nào được tiếp xúc bởi thực tiễn này không? Nó không phải là một câu hỏi về "bạn nên hay không nên bạn", điều đó là rõ ràng, đó là câu hỏi liệu nó có đưa ra bất kỳ lỗ hổng cụ thể nào không.Có rủi ro bảo mật khi chạy các ứng dụng web trong debug = "true" không?

Tôi có khuynh hướng nghĩ rằng khả năng remotely detect it kết hợp với các vấn đề hiệu suất đã biết có thể dẫn đến việc khai thác dựa trên tính khả dụng của dịch vụ nhưng tôi muốn một điều gì đó rõ ràng hơn một chút. Có ai biết về một cuộc tấn công cụ thể có thể được phối hợp với một ứng dụng đang chạy debug = "true" không?

+1

Tại sao không hỏi điều này trên [SecuritySE] (http://security.stackexchange.com/)? – AviD

+0

Điểm tốt, tôi đã không đặt ở đó ban đầu như tôi nghĩ rằng tôi muốn nhận được câu trả lời ở đây. Tôi đã gửi một bản sao qua: http://security.stackexchange.com/questions/1180/is-there-a-security-risk-running-web-apps-in-debug-true –

+0

Tôi đã thấy các chuỗi kết nối ĐẦY ĐỦ (bao gồm cả mật khẩu) tiếp xúc trong quá khứ, nơi ứng dụng đang chạy trong chế độ gỡ lỗi, Lỗi tùy chỉnh bị tắt và kết nối không thành công - trong trường hợp này không phải do sự cố với máy chủ cơ sở dữ liệu, nhưng khi một máy chủ khác hoạt động như máy chủ DNS duy nhất cho máy chủ đã ngừng hoạt động. Kích hoạt chế độ gỡ lỗi làm tăng đáng kể nguy cơ tiết lộ thông tin ứng dụng nội bộ nhạy cảm, nhưng sau đó bạn đã biết điều đó. Tôi thích sự tương tự với các sự cố không phải do một sự kiện gây ra, mà là một chuỗi kết hợp để đưa ra kết quả (thường là bi thảm). – pwdst

Trả lời

5

Tôi đã có một số phản hồi thú vị về câu hỏi này, đặc biệt là trên Security Stack Exchange. Đã có rất nhiều câu trả lời liên quan đến dấu vết ngăn xếp (một vấn đề lỗi tùy chỉnh, không phải là một vấn đề gỡ lỗi) và hiệu suất (không [trực tiếp] một vấn đề bảo mật).

Phản hồi hấp dẫn nhất là hằng số biên dịch có điều kiện (#if DEBUG ...) có thể gây ra hành vi không mong muốn, nhưng điều này lại có nhiều rủi ro về chức năng (mã không mong muốn đang được thực thi trong môi trường trực tiếp). .

Tôi nghi ngờ chế độ gỡ lỗi có thể mở một số lộ trình để khai thác khác dựa trên chi phí hoạt động mà nó đặt trên ứng dụng và khả năng phát hiện từ xa (nguy cơ liên tục dịch vụ). Tôi đã viết các kết luận của tôi như là một phần của OWASP Top 10 for .NET developers part 6: Security Misconfiguration.

Vì vậy, vì mục đích đầy đủ, câu trả lời dường như không có rủi ro bảo mật rõ ràng khi chạy trong chế độ gỡ lỗi, nhưng chắc chắn không phải là ý tưởng hay cho các ứng dụng sản xuất.

3

Điều đó phụ thuộc phần nào vào mã nào được bao quanh bởi DEBUG biên dịch có điều kiện.

Bạn có bất kỳ mã chỉ gỡ lỗi nào có thể bị khai thác không? Nó không phải là không phổ biến để tìm quyền quản trị 'gọi blanche' được đưa ra trong chế độ gỡ lỗi ...

Nếu bạn không có mã gỡ lỗi, thì điều duy nhất tôi có thể nghĩ là có thể xuất bản quá nhiều thông tin lỗi ngăn xếp trong lỗi web báo cáo.

Điểm có phần tranh luận nếu ứng dụng của bạn có ghi nhật ký tốt (mức cấu hình), chẳng hạn như log4Net.

+0

Điểm tốt, mặc dù bạn có thể cho rằng đó là một câu hỏi về lỗ hổng trong logic điều kiện trong ứng dụng hơn là một lỗ hổng trong chế độ gỡ lỗi mỗi lần. Câu hỏi không liên quan đến bất kỳ ứng dụng cụ thể nào, đó là câu hỏi chung về việc liệu gỡ lỗi chỉ là vấn đề về sự hoàn hảo hay vấn đề bảo mật tiềm ẩn. –

+0

@Troy Hunt: Đúng, nhưng chúng đi đôi với nhau. Tôi đoán điều này sẽ tạo thành một phần của bất kỳ đánh giá mã nào ... –

0

Tôi nghĩ bạn nên chuyển tất cả các hoạt động gỡ lỗi sang bảng điều khiển được tạo tùy chỉnh để ngăn các gợi ý gỡ lỗi khiến kẻ tấn công có thể lạm dụng lỗ hổng của ứng dụng của bạn.

Các vấn đề liên quan