lỗ hổng bảo mật - báo cáo veracode - crlf injection

Question

Tôi nhận được báo cáo veracode cho ứng dụng javaEE của mình. Nó có một lỗ hổng ở bất kỳ đăng nhập nào (sử dụng log4j), vì vậy tôi thêm StringEscapeUtils.escapeJava(log) vào tất cả chúng, nhưng veracode giữ báo cáo chúng là lỗi bảo mật.

Đây có phải là giải pháp phù hợp không? Tôi có thể làm gì khác?

Đây là thông tin báo cáo: Title: không đúng Output trung hòa cho Logs

Mô tả: Một cuộc gọi chức năng có thể dẫn đến một cuộc tấn công giả mạo đăng nhập. Việc ghi dữ liệu do người dùng cung cấp không an toàn vào tệp nhật ký cho phép kẻ tấn công giả mạo các mục nhập nhật ký hoặc đưa nội dung độc hại vào tệp nhật ký. Các tệp nhật ký bị hỏng có thể được sử dụng để bao gồm các bài hát của kẻ tấn công hoặc làm cơ chế phân phối cho một cuộc tấn công vào tiện ích xử lý hoặc xem nhật ký. Ví dụ: nếu một quản trị viên web sử dụng tiện ích dựa trên trình duyệt để xem lại nhật ký, có thể xảy ra tấn công tập lệnh chéo trang web.

Đề xuất: Tránh trực tiếp nhúng người dùng nhập vào tệp nhật ký khi có thể. Vệ sinh dữ liệu do người dùng cung cấp được sử dụng để tạo nhật ký mục nhập bằng cách sử dụng cơ chế ghi nhật ký an toàn như OWASP ESAPI Logger, sẽ tự động xóa lợi nhuận và dòng thức ăn không mong muốn và có thể được định cấu hình để sử dụng mã hóa thực thể HTML cho dữ liệu không phải là chữ số . Chỉ viết mã danh sách đen tùy chỉnh khi thật cần thiết. Luôn xác thực đầu vào do người dùng cung cấp để đảm bảo rằng nó phù hợp với định dạng mong muốn, bằng cách sử dụng thói quen xác thực dữ liệu tập trung khi có thể.

Họ khuyên bạn nên sử dụng ESAPI, nhưng nó là một dự án rất lớn vì vậy tôi cần những giải pháp đơn giản nhất, THT là lý do tại sao tôi đã cố gắng với String.escape 'StringEscapeUtils.escapeJava (log)'

Thx ở cao cấp!

Answer 1

Tôi đăng ký nhóm Tư vấn bảo mật ứng dụng Veracode và có thể trả lời chi tiết câu hỏi của bạn. Địa điểm tốt nhất cho cuộc trò chuyện là thông qua Support@veracode.com, vì cuộc thảo luận có thể liên quan đến các chi tiết cụ thể về những phát hiện của bạn mà chúng tôi có thể muốn tránh công khai.

Câu trả lời ngắn gọn là StringEscapeUtils.escapeJava() có hiệu quả trong việc loại bỏ rủi ro CRLF điển hình, nhưng nó không phải là một trong những cơ chế mà hệ thống của chúng tôi tự động nhận ra vì có những tình huống mà nó có thể không đủ.

Hệ thống Veracode có cơ chế đánh dấu những phát hiện này một cách thích hợp để chúng không gây nhầm lẫn.

Vui lòng liên hệ với bộ phận Hỗ trợ Veracode (support@veracode.com) và chúng tôi sẽ có thể nói chi tiết.

Trân trọng, Jim.

Answer 2

Có hai vấn đề được nêu trong báo cáo này.

Thứ nhất, có nhật ký tiêm - sử dụng ký tự dòng mới để tràn vào một dòng nhật ký riêng biệt. StringEscapeUtils.escapeJava tạo ra đầu ra có dấu phân tách dòng và ký tự không phải ASCII được thoát, về nguyên tắc đảm bảo vấn đề này được khắc phục. Veracode không biết rằng, mặc dù - như một máy quét tự động nó không biết đủ về những gì phương pháp đó đang làm để có thể nói chắc chắn, do đó, nó đã báo cáo có thể vẫn còn một lỗ hổng ở đó. Tự nhiên Veracode không thể biết về mọi chức năng thoát trong mã thư viện của bên thứ ba.

Việc ghi nhật ký cũng có thể xảy ra khi bạn đang sử dụng dấu phân cách riêng của mình bên trong dòng nhật ký, ví dụ: Bad thing happened with parameters {0} and {1}. Trong trường hợp này nếu kẻ tấn công có chuỗi " and " trong một trong các tham số, bạn sẽ không thể tạo lại chính xác dữ liệu nào trong tham số nào. Câu trả lời ở đây là bao quanh các tham số với các dấu phân cách không xuất hiện trong đầu ra của hàm thoát - ví dụ đặt dấu ngoặc kép xung quanh mỗi giá trị và sử dụng escapeJava để thoát khỏi bất kỳ ký tự trích dẫn kép nào trong giá trị.

Cuộc tấn công thứ hai xảy ra bên ngoài ứng dụng của bạn, khi một số công cụ đang được sử dụng để xem nhật ký. Nếu công cụ đó có lỗ hổng tiêm thì các siêu ký tự trong dữ liệu nhật ký có thể hoạt động. Ví dụ cổ điển là xem nhật ký trong giao diện web sao chép chúng trực tiếp vào trang mà không cần thoát, dẫn đến HTML injection và do đó cross-site-scripting trong ứng dụng xem nhật ký.

Nếu bạn có thể chắc chắn rằng bạn chỉ đang xem nhật ký trong các công cụ không bị lỗi ngu ngốc như thế này, bạn không cần phải lo lắng về nó.

Nếu không, hãy cố gắng thoát khỏi bất kỳ siêu ký tự nào từ các ngôn ngữ bạn nghĩ có thể bị ảnh hưởng. Thường là < và & cho HTML. Nếu bạn không muốn thoát HTML tất cả dữ liệu nhật ký không phải HTML của mình, một cách khác bạn có thể làm là thay thế các ký tự đó bằng các số tương đương đã thoát như \u003E ở đầu ra của escapeJava.

Một lần nữa, Veracode sẽ không thể tự động làm việc mà bạn đang làm là an toàn nhất ở đó, vì vậy bạn sẽ phải đánh dấu những báo cáo đó là bị bỏ qua/xử lý khi bạn hài lòng với nó.

Answer 3

Sử dụng StringEscapeUtils.escapeHtml (nhật ký) để tránh việc tiêm HTML và có thể giải quyết được sự cố của bạn.

Answer 4

Tôi đã gặp sự cố tương tự và tôi thường bỏ qua lỗi này vì một lý do đơn giản: Trình ghi nhật ký chỉ cho tôi sự kiện nhật ký. Không nên quan tâm đến việc định dạng (phơi bày dữ liệu nhạy cảm là một vấn đề khác).

Giải pháp ở đây là thêm lọc/xử lý thích hợp trong ứng dụng appender ghi sự kiện nhật ký vào tệp nhật ký. Tại bước này, bạn có thể xóa các ký tự đặc biệt (\0, \r - vận chuyển trở lại, \b - backspace, \x1b - thoát và \x7f - xóa) và thay thế \n bằng \n... để không thể chèn dòng nhật ký giả vào nhật ký.

Khi bạn thực hiện việc này, bạn có thể bỏ qua tất cả các lỗi này một cách an toàn.

Ngoài ra, nếu sysadmin sử dụng các công cụ sai để xem các tệp nhật ký (bất kỳ thứ gì thực hiện các chuỗi thoát, \r và backspace), thì nó sẽ được kích hoạt.