Я приведу вам пример, чтобы лучше объяснить это.
Но общая идея заключается в том, что символы CRLF интерпретируются серверными языками (такими как, например, PHP), но отбрасываются как пробельные символы HTML, что позволит вам потенциально обходить фильтры на стороне сервера (так как они не блокируют их). ) и быть брошенным в DOM, где он более или менее лишается символа CRLF и выполняет полезную нагрузку.
Пример:
<iframe src="{$user_input}"></iframe>
Давайте представим, что мы берем пользовательский ввод, где можно найти переменную {$user_input}. Возможно, вы знаете, что ввод данных в источник iframe опасен, так как злоумышленник может ввести javascript:alert(0) в качестве ввода и получить предупреждение. Не стесняйтесь попробовать, и вы увидите.
Итак, давайте представим, что разработчик слышит, что кто-то использовал эту уязвимость, чтобы получить XSS на своем веб-сайте. Они решают создать правило, в котором они удаляют javascript: из ввода перед вводом в источник. Сейчас есть 3 возможных способа получить XSS.
Первый - сделать что-то вроде jAvAsCrIpT:alert(0). Это будет работать, если метод замены чувствителен к регистру.
Второй способ - попробовать что-то вроде этого: javajavascript:script:alert(0). Это также будет работать, так как будет просто лишать javascript:, оставляя его как javascript:alert(0).
Третий и последний способ (о котором я могу подумать, по крайней мере, возможно, существует больше методов) - это использование символа CRLF / перевода строки. Вы можете сделать это: java%0a%0dscript:alert(0), который является символом CRLF в кодировке URL (%0a%0d). Это обойдёт его, так как PHP считывает, что он на самом деле не javascript:, тогда как HTML будет читать его как пробел в значении атрибута (src) и игнорировать возврат каретки.