2010-12-29 26 views
7

Đây là một câu hỏi hơi chủ quan, nhưng tôi muốn nghe những ưu/nhược điểm để làm điều này. Tôi quản lý một dự án mã nguồn mở được gọi là Quick and Dirty Feed Parser và mục tiêu của dự án là làm cho nó liền mạch nhất có thể để tiêu thụ nguồn cấp dữ liệu RSS và Atom trong .NET.Có phải là thực tiễn có thể chấp nhận để bật UnsafeHeaderParsing theo mặc định không?

Một trong những vấn đề mà tôi gặp phải trong quá trình phát triển dự án là một số nguồn cấp dữ liệu tôi đã sử dụng làm trường hợp kiểm tra (cụ thể là Hacker News RSS feed) sử dụng tiêu đề HTTP được định dạng không đúng và lớp HttpWebRequest trong .NET 1.1 và lên ngay lập tức ném một ngoại lệ "tiêu đề không an toàn" bất cứ khi nào bạn nhận được một trong các tiêu đề này trong yêu cầu GET.

This change was added in order to put a stop to split-response attacks that were raising security issues at the time .NET 1.1 was released.

Vấn đề của tôi là như vậy - tôi có thể bật tùy chọn cấu hình "useUnsafeHeader" theo lập trình, nhưng nó thực hiện trên tất cả HttpWebRequests trong ngữ cảnh của ứng dụng đó. Tôi có người dùng đã phàn nàn về QD Feed Parser không thể tiêu thụ nguồn cấp dữ liệu hợp lệ và vấn đề tiêu đề này là lý do. Ngay bây giờ tôi đã thiết lập thư viện theo cách mà các nhà phát triển sử dụng nó phải bật phân tích cú pháp tiêu đề không an toàn, mặc dù hầu hết họ không biết rằng đây là vấn đề và nó tạo phí hỗ trợ cho tôi . Tôi có thể chỉ đơn giản là phân tích cú pháp nguồn cấp dữ liệu nhanh và không cho phép phân tích cú pháp tiêu đề không an toàn theo mặc định và buộc người dùng bảo mật vô hiệu hóa tính năng này, nhưng tôi không muốn mở những người dùng không biết rõ hơn về các cuộc tấn công bảo mật, hoặc là . Lựa chọn tốt nhất ở đây là gì?

+0

Tôi vừa truy cập trang web dự án và nhận thấy không có trang "Câu hỏi thường gặp" trong trang đầu tiên, mặc dù bạn đã ghi lại vấn đề này trong "Cách sử dụng nâng cao" ở một nơi khác (không rõ ràng). Làm cho tài liệu của bạn có thể dự đoán được và dễ định vị cũng có thể giúp bạn tiết kiệm chi phí hỗ trợ. –

Trả lời

6

"Không an toàn" hơi khắc nghiệt ở đây; Tôi đã đặt tên cho cài đặt này theo cách khác. Vấn đề xuất hiện khi các máy chủ bị xử lý phát ra các tiêu đề không tuân theo chính xác HTTP RFC. Ví dụ RFC nói rằng các ký tự CR phải được theo sau bởi một ký tự LF, vì vậy nếu không có LF, bạn sẽ nhận được một phép toán trừ khi bạn cho phép các tiêu đề "không an toàn".

Trong thực tế, nhiều khách hàng HTTP bỏ qua những vi phạm nhỏ này để nói chuyện với nhiều máy chủ nhất có thể. Đó là lý do tại sao trình duyệt hoặc trình đọc RSS của bạn không bao giờ phàn nàn về các tiêu đề "không an toàn". Ngay cả khi tiêu đề là không có thật, các thư viện máy khách .NET đủ mạnh để bạn không thể, ví dụ, làm hỏng máy chủ của bạn nếu kẻ tấn công ác ý bỏ qua một linefeed. Vì vậy, không có vấn đề an toàn lớn ở đây, trừ khi (ví dụ) bạn làm những điều ngu ngốc với các tên tiêu đề HTTP như phát trực tiếp chúng vào HTML của bạn (điều này có thể cho phép kẻ tấn công tiêm một tấn công XSS vào HTML của bạn). Vì vậy, miễn là bạn xử lý các tiêu đề HTTP như thể chúng không đáng tin cậy như bất kỳ dữ liệu nào do người dùng gửi khác đi vào ứng dụng của bạn (như chuỗi truy vấn, dữ liệu POST, v.v.), thì bạn nên OK cho phép các tiêu đề "không an toàn" trong ứng dụng của bạn.

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