programming php

PHP Crlf là gì?

Tôi gặp sự cố khi đọc văn bản từ cơ sở dữ liệu mysql để tạo tập lệnh trình bao. Nhưng tập lệnh xuất hiện với ngắt dòng ở định dạng khác và không thể thực thi đúng cách. Vì vậy, tôi sử dụng tập lệnh của bạn để chuyển đổi văn bản từ cơ sở dữ liệu. VÀ NÓ HOẠT ĐỘNG TỐT. Cảm ơn rất nhiều

CRLF injection là một lỗ hổng cho phép tin tặc độc hại chèn các ký tự xuống dòng [CR] và linefeed [LF] để thay đổi cách thức hoạt động của ứng dụng web hoặc gây nhầm lẫn cho quản trị viên của ứng dụng đó. Có hai cách sử dụng độc hại chính để tiêm CRLF. ngộ độc nhật ký [còn được gọi là chèn nhật ký, tách nhật ký hoặc giả mạo nhật ký] và phân tách phản hồi HTTP

Những kẻ tấn công có thể sử dụng các lần tiêm CRLF để chuyển sang các loại lỗ hổng khác, chủ yếu là cross-site scripting [XSS]. Tiêm CRLF cũng có thể được sử dụng trong các ứng dụng web để tác động đến hành vi của email – điều này được gọi là tiêm email [chèn tiêu đề email]

Mức độ nghiêm trọng.

nghiêm trọng trong các trường hợp hiếm hoi Tỷ lệ.

hiếm khi được phát hiện.

ứng dụng webTác động kỹ thuật. khả năng leo thang thành tập lệnh chéo trangHậu quả xấu nhất. thỏa hiệp toàn bộ hệ thốngSửa nhanh. sử dụng bộ lọc đầu vào của người dùng và mã hóa đầu ra

CRLF là gì?

CR và LF là các ký tự đặc biệt của bảng ASCII [13 và 10]. Chúng cũng thường được gọi là \r\n sau mã thoát của hai ký tự này [\r = CR, \n = LF]

CR và LF được sử dụng [cùng nhau hoặc riêng biệt] để biểu thị kết thúc một dòng [EoL] trong các hệ điều hành và giao thức Internet, bao gồm HTTP. Windows sử dụng kết hợp CRLF, các hệ điều hành như Linux/UNIX và macOS hiện tại chỉ sử dụng LF cho mục đích này và Mac OS cũ chỉ sử dụng CR

ngộ độc log là gì?

Trong một cuộc tấn công đầu độc nhật ký dựa trên tiêm CRLF, một tin tặc độc hại sẽ tiêm các ký tự CRLF vào tệp nhật ký máy chủ web để gây nhầm lẫn cho cả hệ thống phân tích nhật ký tự động và quản trị viên hệ thống đang duyệt nhật ký theo cách thủ công

Định dạng nhật ký máy chủ web

Nhiều máy chủ web, chẳng hạn như Apache, sử dụng Định dạng nhật ký chung NCSA [CLF]. Định dạng của các mục Định dạng nhật ký chung luôn giống nhau

host ident user date request status size

Ví dụ

233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452

Đây là cách bạn sẽ đọc mục này

233.252.0.123 là máy chủ – địa chỉ IP mà từ đó yêu cầu đến
- là danh tính RFC 1413 của khách hàng. Dấu gạch ngang [-] có nghĩa là không có dữ liệu, là giá trị thông thường
- là ID người dùng của người yêu cầu tài liệu. Dấu gạch ngang [-] có nghĩa là không có dữ liệu, là giá trị thông thường [trừ khi có xác thực trong. htaccess]
[11/Oct/2022:11:34:50 +0100] là dấu thời gian khi yêu cầu được nhận, thường ở định dạng strftime. %d/%b/%Y. %H. %M. %S %z

"GET /example.php?id=3 HTTP/1.0" là dòng yêu cầu nhận được từ máy khách và bao gồm phương thức HTTP [

233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452

0], tài nguyên và tham số được yêu cầu [

233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452

1] và giao thức [

233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452

233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452

3 là mã trạng thái HTTP được gửi tới máy khách

233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452

4 là kích thước của đối tượng được trả về tính bằng byte

Một định dạng tiêu chuẩn khác là Định dạng nhật ký kết hợp, tương tự nhưng có thêm một số trường

Ví dụ về ngộ độc nhật ký

Hãy tưởng tượng rằng khách hàng có thể đưa các ký tự CR và LF vào các yêu cầu được gửi tới www. thí dụ. máy chủ web com và nó sẽ gửi yêu cầu sau

//www.example.com/example.php?id=3+HTTP%2F1.0%22+200+452%0D%0A
10.0.23.30+-+admin+%5B01%2FJan%2F2020%3A00%3A00%3A00+%2B0100%5D+%22GET+%2Fadmin.php%3Fuserid%3D12

Yêu cầu chứa một mục nhập nhật ký giả mạo, vì vậy khi nó được ghi lại, tệp nhật ký sẽ bao gồm một dòng bổ sung

________số 8_______

Các ký tự được gạch chân đại diện cho nội dung đã được đưa vào bằng cách tiêm CRLF [

233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452

5 là các ký tự CRLF được mã hóa]

Các công cụ giám sát và quản trị viên phân tích nhật ký này sẽ bị nhầm lẫn bởi mục nhập lạ này – có vẻ như một người dùng quản trị viên được xác thực đã yêu cầu quản trị viên. tài nguyên php một thời gian trong quá khứ xa xôi. Sự nhầm lẫn này có thể cho phép kẻ tấn công đánh lạc hướng quản trị viên và trì hoãn việc phân tích nhật ký với hy vọng thoát khỏi các hành động nguy hiểm khác sẽ xuất hiện trong các mục nhật ký sau này

Phân tách phản hồi HTTP là gì?

Trong một cuộc tấn công phân tách phản hồi HTTP, kẻ tấn công đưa các chuỗi CRLF vào một phản hồi HTTP để sửa đổi cách trình duyệt diễn giải các tiêu đề HTTP và nội dung yêu cầu. Tiêm CRLF có thể được sử dụng để thêm nội dung độc hại vào phần thân yêu cầu hoặc để thêm các tiêu đề HTTP bổ sung

Cách giao thức HTTP sử dụng các ký tự CRLF

Giao thức HTTP sử dụng chuỗi ký tự CRLF theo hai cách

Một chuỗi CRLF duy nhất có nghĩa là một tiêu đề kết thúc và một tiêu đề khác bắt đầu
Chuỗi CRLF kép tách tất cả các tiêu đề khỏi phần thân. Nội dung yêu cầu HTTP chứa dữ liệu do khách hàng gửi, trong khi nội dung phản hồi thường chứa dữ liệu trang web do máy chủ trả về

Tương ứng, có hai cách để kẻ tấn công sửa đổi lưu lượng HTTP

Nếu kẻ tấn công chèn một CRLF vào tiêu đề phản hồi HTTP, họ có thể thêm tiêu đề mới ngay sau dòng mới này. Ví dụ: họ có thể chèn tiêu đề Vị trí để chuyển hướng người dùng đến trang web do kẻ tấn công kiểm soát. Tội phạm mạng có thể sử dụng kỹ thuật này, thường được gọi là tiêm tiêu đề HTTP, để lừa đảo hoặc phá hoại
Nếu kẻ tấn công chèn CRLF kép, chúng có thể chấm dứt sớm các tiêu đề HTTP và đưa nội dung độc hại vào trước nội dung trang web thực tế. Nội dung được đưa vào có thể bao gồm mã JavaScript. Kẻ tấn công thậm chí có thể khiến trình duyệt bỏ qua tất cả nội dung trang web hợp pháp đến từ máy chủ web. Đây là cách phân tách phản hồi HTTP có thể dẫn đến cross-site scripting

Lưu ý rằng những kẻ tấn công cũng có thể đưa các tiêu đề đặc biệt vào proxy độc hại hoặc bộ đệm web, cho phép chúng cung cấp nội dung độc hại cho nhiều người dùng

Ví dụ về phân tách phản hồi HTTP với XSS

Trong ví dụ sau, kẻ tấn công sử dụng phân tách phản hồi HTTP và chèn tiêu đề HTTP để gửi yêu cầu HTTP bổ sung thêm tiêu đề cho phản hồi HTTP, kết thúc sớm tiêu đề và đưa ra lỗ hổng tập lệnh chéo trang được phản ánh

Kẻ tấn công gửi tải trọng sau trong email lừa đảo khuyến khích người dùng nhấp vào liên kết hoặc nút

//www.example.com/example.php?id=%0d%0aContent-Length:%200%0d%0a%0d%0a
HTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a
%3Cscript%3Ealert[1]%3C/script%3E

Tải trọng sử dụng nội xạ CRLF để phân tách phản hồi HTTP như sau

```
233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452
```
6 – bắt đầu một yêu cầu hợp lệ tới một trang có lỗ hổng chèn CRLF
```
233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452
```
7 – tiêu đề phản hồi HTTP giả mạo của
```
233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452
```
8. Điều này khiến trình duyệt web coi phản hồi này là đã kết thúc và bắt đầu phân tích cú pháp phản hồi tiếp theo

233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452

9 – phản hồi mới được đưa vào bắt đầu tại đây với chuỗi CRLF kép theo sau bởi

//www.example.com/example.php?id=3+HTTP%2F1.0%22+200+452%0D%0A
10.0.23.30+-+admin+%5B01%2FJan%2F2020%3A00%3A00%3A00+%2B0100%5D+%22GET+%2Fadmin.php%3Fuserid%3D12

//www.example.com/example.php?id=3+HTTP%2F1.0%22+200+452%0D%0A
10.0.23.30+-+admin+%5B01%2FJan%2F2020%3A00%3A00%3A00+%2B0100%5D+%22GET+%2Fadmin.php%3Fuserid%3D12

1 – một tiêu đề phản hồi HTTP giả mạo khác.

//www.example.com/example.php?id=3+HTTP%2F1.0%22+200+452%0D%0A
10.0.23.30+-+admin+%5B01%2FJan%2F2020%3A00%3A00%3A00+%2B0100%5D+%22GET+%2Fadmin.php%3Fuserid%3D12

2. Điều này là cần thiết để trình duyệt coi dữ liệu này là nội dung HTML

//www.example.com/example.php?id=3+HTTP%2F1.0%22+200+452%0D%0A
10.0.23.30+-+admin+%5B01%2FJan%2F2020%3A00%3A00%3A00+%2B0100%5D+%22GET+%2Fadmin.php%3Fuserid%3D12

3 – một tiêu đề phản hồi HTTP giả mạo khác.

//www.example.com/example.php?id=3+HTTP%2F1.0%22+200+452%0D%0A
10.0.23.30+-+admin+%5B01%2FJan%2F2020%3A00%3A00%3A00+%2B0100%5D+%22GET+%2Fadmin.php%3Fuserid%3D12

4. Điều này hướng dẫn trình duyệt chỉ phân tích cú pháp 25 byte tiếp theo và loại bỏ mọi dữ liệu còn lại dưới dạng rác, khiến trình duyệt bỏ qua nội dung HTTP hợp lệ do máy chủ web gửi

//www.example.com/example.php?id=3+HTTP%2F1.0%22+200+452%0D%0A
10.0.23.30+-+admin+%5B01%2FJan%2F2020%3A00%3A00%3A00+%2B0100%5D+%22GET+%2Fadmin.php%3Fuserid%3D12

5 – một chuỗi CRLF kép báo hiệu rằng các tiêu đề đã kết thúc và phần nội dung phản hồi bắt đầu. Nội dung trang được đưa vào là

//www.example.com/example.php?id=3+HTTP%2F1.0%22+200+452%0D%0A
10.0.23.30+-+admin+%5B01%2FJan%2F2020%3A00%3A00%3A00+%2B0100%5D+%22GET+%2Fadmin.php%3Fuserid%3D12

6, khiến trình duyệt của người dùng hiển thị cảnh báo thay vì ví dụ thực tế. trang php

Hậu quả tiềm ẩn của một cuộc tấn công tiêm CRLF

Tác động của việc tiêm CRLF dường như bị hạn chế, nhưng chúng được đề cập trong danh sách 10 ứng dụng web hàng đầu năm 2021 của OWASP trong A03. 2021-Phần tiêm. Những kẻ tấn công có thể sử dụng kỹ thuật này để leo thang thành các cuộc tấn công độc hại nguy hiểm hơn như kịch bản chéo trang, chiếm quyền điều khiển trang, xóa giao diện người dùng chéo, v.v.

Các lỗ hổng phân tách phản hồi HTTP cho phép kẻ tấn công sửa đổi các tiêu đề HTTP và bỏ qua các cơ chế bảo mật cụ thể, chẳng hạn như bộ lọc XSS, cờ bảo mật cookie và các hạn chế của chính sách cùng nguồn gốc [SOP]. Điều này mở ra cách thực hiện một số loại tấn công trung gian [MITM] và khai thác các lỗ hổng giả mạo yêu cầu chéo trang [CSRF], do đó, có thể dẫn đến tiết lộ thông tin nhạy cảm hoặc hơn thế nữa

Làm cách nào để phát hiện lỗ hổng tiêm CRLF?

Cách tốt nhất để phát hiện các lỗ hổng CRLF injection phụ thuộc vào việc chúng đã biết hay chưa biết

Nếu bạn chỉ sử dụng các ứng dụng web thương mại hoặc nguồn mở và không phát triển các ứng dụng web của riêng mình, thì có thể đủ để xác định phiên bản chính xác của ứng dụng bạn đang sử dụng. Nếu phiên bản được xác định dễ bị tiêm CRLF, bạn có thể cho rằng trang web hoặc ứng dụng của mình dễ bị tấn công. Bạn có thể xác định phiên bản theo cách thủ công hoặc sử dụng công cụ bảo mật phù hợp, chẳng hạn như giải pháp phân tích thành phần phần mềm [SCA]
Nếu bạn phát triển các ứng dụng web của riêng mình hoặc muốn có khả năng tìm thấy các lỗ hổng chèn CRLF chưa biết trước đó [zero-days] trong các ứng dụng đã biết, thì bạn phải có khả năng khai thác thành công lỗ hổng để chắc chắn rằng nó tồn tại. Điều này yêu cầu thực hiện kiểm tra thâm nhập thủ công với sự trợ giúp của các nhà nghiên cứu bảo mật hoặc sử dụng công cụ kiểm tra bảo mật [máy quét] có thể sử dụng tự động hóa để khai thác lỗ hổng web. Ví dụ về các công cụ như vậy là Invicti và Acunetix của Invicti. Chúng tôi khuyên bạn nên sử dụng phương pháp này ngay cả đối với các lỗ hổng đã biết

Làm cách nào để ngăn chặn các lỗ hổng chèn CRLF trong các ứng dụng web?

Nhiều khung công tác web hiện nay ngăn phản hồi HTTP phân tách thông qua tiêm CRLF bằng cách không cho phép các chuỗi CRLF được đưa vào tiêu đề HTTP. Nếu khung của bạn không tự động thực hiện xác thực đầu vào như vậy, bạn có thể sử dụng một trong các phương pháp sau

Thay đổi mã của bạn để bạn không bao giờ sử dụng trực tiếp bất kỳ nội dung nào do người dùng cung cấp trong luồng HTTP. Đây là cách tốt nhất để ngăn chặn không chỉ các lần tiêm CRLF mà cả các lỗ hổng tiêm chích khác, và rất được khuyến khích
Tự động làm sạch đầu vào của người dùng và xóa tất cả các ký tự dòng mới trước khi chuyển nội dung vào tiêu đề HTTP
Mã hóa dữ liệu mà bạn chuyển vào tiêu đề HTTP. Điều này sẽ xáo trộn mã CR và LF nếu kẻ tấn công cố gắng tiêm chúng

Lưu ý rằng bạn không thể ngăn chặn việc đầu độc nhật ký thông qua tiêm CRLF ở cấp ứng dụng đơn giản vì máy chủ web có trách nhiệm ghi nhật ký các yêu cầu ở định dạng an toàn. Tương tự, các công cụ phân tích nhật ký nên phân tích các tệp nhật ký, bao gồm cả những tệp được tạo bởi máy chủ web, theo cách an toàn không cho phép tấn công đầu độc nhật ký hoặc giả mạo nhật ký thành công

Làm cách nào để giảm thiểu các cuộc tấn công tiêm CRLF?

Vì bản thân việc tiêm CRLF không nguy hiểm nhưng có thể mở đường cho các cuộc tấn công khác, bạn nên tập trung chủ yếu vào việc giảm thiểu các cuộc tấn công tiếp theo như vậy, chẳng hạn như tấn công tập lệnh chéo trang và đầu độc bộ đệm web

Để giảm thiểu tạm thời, bạn có thể dựa vào các quy tắc WAF [tường lửa ứng dụng web]. Với các quy tắc như vậy, người dùng sẽ không thể cung cấp đầu vào độc hại cho ứng dụng web của bạn, vì vậy sẽ không có mã độc hại nào thực thi trong trình duyệt của họ. Tuy nhiên, vì tường lửa ứng dụng web không hiểu ngữ cảnh của ứng dụng của bạn, những kẻ tấn công có thể phá vỡ các quy tắc này và không bao giờ được coi là giải pháp lâu dài

Các câu hỏi thường gặp

Thuốc tiêm CRLF là gì?

CRLF injection là một lỗ hổng cho phép tin tặc độc hại chèn các ký tự xuống dòng [CR] và linefeed [LF] để thay đổi cách thức hoạt động của ứng dụng web hoặc gây nhầm lẫn cho quản trị viên của ứng dụng đó. Tiêm CRLF cũng có thể được sử dụng trong các ứng dụng web để tác động đến hành vi của email – đây được gọi là tiêm email hoặc tiêm tiêu đề email

Tìm hiểu về tiêm tiêu đề email

Tiêm CRLF nguy hiểm như thế nào?

Tiêm CRLF được kẻ tấn công sử dụng để đầu độc nhật ký và phân tách phản hồi HTTP. Những kẻ tấn công cũng có thể sử dụng các lần tiêm CRLF để chuyển sang các loại lỗ hổng khác, chủ yếu là cross-site scripting [XSS]

Tìm hiểu thêm về cross-site scripting và hậu quả của nó

Làm thế nào để tránh tiêm CRLF?

Nhiều khung công tác web ngăn phản hồi HTTP phân tách thông qua tiêm CRLF bằng cách không cho phép các chuỗi CRLF được đưa vào tiêu đề HTTP. Nếu khung của bạn không tự động thực hiện xác thực đầu vào như vậy, bạn có thể sử dụng các nguyên tắc mã hóa an toàn chung. lọc đầu vào và thoát đầu ra