символ crlf что это
CRLF-инъекции и HTTP Response Splitting
Привет, Хабровчане! В преддверии старта занятий в ближайшей группе профессионального курса «Безопасность веб-приложений», мы подготовили для вас еще один полезный перевод.
Что такое CRLF?
Когда браузер отправляет запрос веб-серверу, тот отправляет ответ, который содержит заголовки HTTP-ответа и сам контент сайта, то есть тело ответа. HTTP-заголовки и HTML-ответ (содержимое сайта) разделяются определенной комбинацией специальных символов, а именно возвратом каретки (carriage return) и подачей строки (line feed). Сокращается это как CRLF.
Веб-сервер использует CRLF, чтобы понять, где начинается новый HTTP-заголовок и заканчивается старый. Также CRLF может сообщить веб-приложению или пользователю, что новая строка начинается в файле или в блоке текста. Символы CRLF – это стандартное сообщение HTTP/1.1, поэтому оно используется любым типом веб-сервера, включая Apache, Microsoft IIS и другие.
Что такое CRLF-инъекция?
При CRLF-инъекции злоумышленник вставляет символы возврата каретки и ввода строки в пользовательский ввод, чтобы обмануть сервер, веб-приложение или пользователя, заставив его думать, что один объект завершился, а другой начался. Таким образом, CRLF-последовательности не являются вредоносными символами сами по себе, но могут быть использованы злоумышленниками для разделения HTTP-ответов (HTTP Response Splitting).
CRLF-инъекция в веб-приложениях
Для веб-приложений CRLF-инъекции могут иметь серьезные последствия, которые будут зависеть от того, как приложение работает с данными. Последствия могут варьироваться от раскрытия конфиденциальной информации до выполнения вредоносного кода, что напрямую влияет на уровень безопасности веб-приложения. На самом деле атака типа CRLF-инъекции может нанести серьёзный вред веб-приложению несмотря на то, что она не была включена в список OWASP Top 10. Например, таким образом можно изменять логи в панели администратора, как показано в примере ниже.
Пример CRLF-инъекции в логи
Представьте себе файл с логами в панели администратора с шаблоном выходного потока IP — Время – Путь, как показано ниже:
Если злоумышленник может сделать инъекцию CRLF-символов в HTTP-запрос, он может изменить выходной поток и фальсифицировать логи. Он может изменить ответ веб-приложения на что-нибудь подобное:
Здесь %0d и %0a – закодированные URL символы CR и LF. Таким образом после того, как злоумышленник вставит эти символы, а приложение выведет их, логи будут выглядеть следующим образом:
Таким образом, используя CRLF-инъекции, злоумышленник может подделать записи в логах, чтобы замести следы. Злоумышленник буквально делает hijacking страницы и изменяет ответ. Например, представим сценарий, в котором у злоумышленника есть пароль администратора и выполняется параметр restrictedaction, который может использовать только администратор.
Проблема заключается в том, что если администратор заметит, что неизвестный IP использует параметр restrictedaction, то поймет, что что-то не так. Однако пока это выглядит так, будто команда была выдана localhost (и, потому, вероятно, кем-то, кто имеет доступ к серверу, например, администратором), это не будет выглядеть подозрительно.
Часть запроса, начинающаяся с %0d%0a будет обработана сервером как один параметр. После этого появится еще один & с параметром restrictedaction, который будет воспринят сервером, как еще один параметр. По сути, это будет тот же самый запрос, что и:
HTTP Response Splitting
Описание
Поскольку заголовок HTTP-ответа и его тело разделены символами CRLF, злоумышленник может попытаться внедрить их. Комбинация CRLFCRLF скажет браузеру, что заголовок заканчивается и начинается тело. Значит теперь он может записывать данные в тело ответа туда, где лежит HTML-код. Это может привести к уязвимости межсайтового скриптинга.
Пример HTTP Response Splitting, приводящего к XSS
Представьте, что приложение устанавливает собственный заголовок, например:
Значение заголовка задается с помощью GET-параметра «name». Если нет кодировки URL-адреса и значение просто содержится в заголовке, то злоумышленник может вставить вышеупомянутую комбинацию CRLFCRLF, чтобы сообщить браузеру о начале тела запроса. Так он может вставить данные, например, полезную нагрузку XSS:
Вышеуказанное выведет окно оповещения в контексте атакуемого домена.
Инъекция в HTTP-заголовки
Описание
С помощью CRLF-инъекции, злоумышленник также может вставлять HTTP-заголовки, которые могут быть использованы для обхода механизмов безопасности, таких как XSS-фильтр браузера или политики одинакового источника (same-origin-policy). Так злоумышленник может получить конфиденциальную информацию, такую как CSRF-токены. Он даже может установить файлы cookie, которые могут быть эксплуатированы путем входа жертвы в учетную запись злоумышленника или использования уязвимости межсайтового скриптинга (XSS).
Пример инъекции в HTTP-заголовок для извлечения конфиденциальных данных
Если злоумышленник сможет сделать инъекцию в HTTP-заголовок, который активирует CORS (Cross Origin Resource Sharing), то он сможет использовать javascript для доступа к ресурсам, защищенным SOP (Same Origin Policy), которая запрещает сайтам из разных источников получать доступ друг к другу.
Последствия CRLF-инъекции
Последствия CRLF-инъекции варьируются и могут включать в себя все последствия использования XSS и раскрытия конфиденциальной информации. Таким способом можно деактивировать некоторые ограничения системы безопасности, такие как фильтры XSS и Same Origin Policy в браузерах жертвы, делая их уязвимыми к вредоносным атакам.
Как предотвратить CRLF/HTTP-инъекции заголовков в веб-приложениях
Лучший метод предотвращения – это не использовать ввод данных пользователем непосредственно в заголовок ответа. Если это невозможно, вы всегда должны использовать функцию для кодирования специальных символов CRLF. Еще одна хорошая практика безопасности – это обновление языка программирования до версии, которая не позволяет делать инъекции CR и LF внутри функций, которые устанавливают HTTP-заголовки.
Разница между типами разрыва линии CR LF, LF и CR?
Я хотел бы знать разницу (с примерами, если это возможно) между типами разрыва строки CR LF (Windows), LF (Unix) и CR (Macintosh).
9 ответов
больше информации, как всегда, на Википедия.
CR и LF являются управляющими символами, соответственно закодированными 0x0D (13 десятичных знаков) и 0x0A (10 десятичное).
Они используются для обозначения разрыва строки в текстовом файле. Как вы указали, Windows использует два символа последовательности CR LF; Unix использует только LF, а старый MacOS (pre-OSX MacIntosh) использовал CR.
апокрифическая историческая перспектива:
как отметил Петр, CR = Возврат Каретки и LF = Строки, два выражения имеют свои корни в старых пишущих машинках / TTY. LF переместил бумагу вверх (но сохранил горизонтальное положение идентичным), а CR вернул «каретку» так, чтобы следующий введенный символ был в крайнем левом положении на бумаге (но на той же строке). CR+LF делал и то, и другое, то есть готовился ввести новую строку. С течением времени физическая семантика кодов была неприменима, а поскольку память и дискетное пространство были в цене, некоторые ОС дизайнеры решили использовать только одного из персонажей, они просто не очень хорошо общались друг с другом 😉
большинство современных текстовых редакторов и текстовых приложений предлагают опции / настройки и т. д. это позволяет автоматически обнаруживать соглашение о конце строки файла и отображать его соответствующим образом.
это хорошее резюме, которое я нашел:
поскольку нет ответа, заявляющего только это, кратко резюмировал:
Возврат Каретки (Mac pre-OSX)
Строки (Linux, MAC OSX)
возврат каретки и подача линии (Windows)
Если вы видите код ASCII в странном формате, это просто число 13 и 10 в другом радиксе/базе, обычно база 8 (восьмеричная) или база 16 (шестнадцатеричная).
у Джеффа Этвуда есть недавнее сообщение в блоге об этом:Великий Раскол Новой Линии
последовательность CR+LF была в общем использовании на многих ранних компьютерных системах приняла телетайпная машин, обычно ASR33, как консоль устройства, потому что эта последовательность была требуется разместить эти принтеры на начало новой линии. На этом системы, текст часто регулярно состоящий быть совместимым с этими принтеры, начиная с концепции устройства драйверы, скрывающие такие детали оборудования из приложения еще не было хорошо разработано; приложения должны были говорить прямо на телетайп и следовать конвенциям. разделение из двух функций скрыты факт, что печатающая головка не могла возвращение из крайнего правого начало следующей строки время одного персонажа. Вот почему последовательность всегда отправлялась с CR первый. На самом деле, это часто необходимо чтобы отправить лишние символы (лишние CRs или NULs, которые игнорируются) для дайте печатающей головке время перейти к левое поле. даже после телетайпов были заменены компьютерные терминалы с более высокими скоростями передачи данных, много работая системы по-прежнему поддерживаются автоматически отправка этих символов заполнения, для совместимость с более дешевыми терминалами это потребовало несколько раз символов для прокрутки экрана.
теоретически CR возвращает курсор в первую позицию (слева). LF подает одну строку, перемещая курсор на одну строку вниз. Вот как в старые времена вы управляли принтерами и текстовыми мониторами. Эти символы обычно используются для обозначения конца строк в текстовых файлах. В разных операционных системах используются разные соглашения. Как вы указали, Windows использует комбинацию CR/LF, а pre-OSX Mac использует только CR и так далее.
системы на основе ASCII или a совместимый набор символов, использовать если (Линия подачи, 0x0A, 10 в десятичном) или CR (возврат каретки, 0x0D, 13 в десятичном) индивидуально, или CR следовать LF (CR+LF, 0x0D 0x0A); Эти символы основаны на командах принтера: подача строки указано, что одна строка бумага должна подаваться из принтера, а каретка-возвращаться указано, что принтер перевозка должна возвратиться к началу течения линия.
печальное состояние «разделителей записей» или «линейных Терминаторов» является наследием темных веков вычислений.
теперь мы считаем само собой разумеющимся, что все, что мы хотим представить, является каким-то образом структурированными данными и соответствует различным абстракциям, которые определяют строки, файлы, протоколы, сообщения, разметку, что угодно.
но когда-то это было не совсем так. Применения встроенные характеры управления и прибор-специфическая обработка. Мозг-мертвые системы, которые требовали и CR, и LF просто не имели абстракции для разделителей записей или линейных Терминаторов. CR был необходим для того, чтобы заставить телетайп или видеодисплей вернуться в столбец один, а LF (сегодня, NL, тот же код) был необходим, чтобы заставить его перейти к следующей строке. Я думаю, идея сделать что-то другое, кроме сброса необработанных данных на устройство, была слишком сложной.
Unix и Mac фактически указали абстрагирование для конца линии, представьте себе это. К сожалению, они уточнили разные. (Unix, кхм, пришел первым.) И, естественно, они использовали код управления, который уже был «близок» к S. O. P.
поскольку почти все наше операционное программное обеспечение сегодня является потомком Unix, Mac или MS operating SW, мы застряли с линией, заканчивающейся путаницей.
NL, полученный из EBCDIC NL = x ’15’, который логически сравнивался бы с CRLF x’odoa ascii. это становится очевидным, когда physcally перемещение данных с мейнфреймов на сч. Coloquially (как только тайные люди используют ebcdic) NL был приравнен к CR или LF или CRLF
Разница между типами разрывов строк CR LF, LF и CR?
Я хотел бы знать разницу (с примерами, если это возможно) между типами разрывов строк CR LF (Windows), LF (Unix) и CR (Macintosh).
Это действительно о том, какие байты хранятся в файле. CR это байт-код для возврата каретки (со времен пишущих машинок) и LF аналогично для перевода строки. Это просто относится к байтам, которые размещены как маркеры конца строки.
Они используются, чтобы отметить разрыв строки в текстовом файле. Как вы указали, Windows использует два символа последовательности CR LF; Unix использует только LF, а старый MacOS (до Mac OS Mac OS X) использовал CR.
Апокрифическая историческая перспектива:
Большинство современных текстовых редакторов и текстовых приложений предлагают опции / настройки и т. Д., Которые позволяют автоматически определять соглашение о конце строки в файле и отображать его соответствующим образом.
Это хорошее резюме, которое я нашел:
Поскольку ответа на этот вопрос нет, кратко резюмируем:
Возврат каретки (MAC pre-OSX)
Перевод строки (Linux, MAC OSX)
Возврат каретки и перевод строки (Windows)
Если вы видите ASCII-код в странном формате, это просто числа 13 и 10 с другим основанием / основанием, обычно основание 8 (восьмеричное) или основание 16 (шестнадцатеричное).
У Джеффа Этвуда есть недавняя запись в блоге об этом: Великий Раскол Newline
Последовательность CR + LF широко использовалась во многих ранних компьютерных системах, в которых в качестве консольного устройства использовались машины телетайпа, как правило, ASR33, поскольку эта последовательность требовалась для позиционирования этих принтеров в начале новой строки. В этих системах текст часто составлялся для совместимости с этими принтерами, поскольку концепция драйверов устройств, скрывающих такие аппаратные детали от приложения, еще не была хорошо разработана; приложения должны были напрямую общаться с телетайпом и следовать его соглашениям.Разделение двух функций скрывало тот факт, что печатающая головка не могла вернуться из крайнего правого края в начало следующей строки за один символ. Вот почему последовательность всегда отправлялась сначала с CR. Фактически часто приходилось отправлять дополнительные символы (лишние CR или NUL, которые игнорируются), чтобы дать время печатающей головке переместиться к левому полю. Даже после того, как телетипы были заменены компьютерными терминалами с более высокой скоростью передачи данных, многие операционные системы все еще поддерживали автоматическую отправку этих символов заполнения для совместимости с более дешевыми терминалами, которым для прокрутки дисплея требовалось несколько раз.
Теоретически CR возвращает курсор в первую позицию (слева). LF подает одну строку, перемещая курсор на одну строку вниз. Вот как в старые времена вы управляли принтерами и мониторами в текстовом режиме. Эти символы обычно используются для обозначения конца строк в текстовых файлах. Различные операционные системы использовали разные соглашения. Как вы указали, в Windows используется комбинация CR / LF, в то время как в пред-OSX Mac используется только CR и так далее.
Системы, основанные на ASCII или совместимом наборе символов, используют либо LF (перевод строки, 0x0A, 10 в десятичном виде) или CR (возврат каретки, 0x0D, 13 в десятичном виде) по отдельности, либо CR, за которым следует LF (CR + LF, 0x0D 0x0A); Эти символы основаны на командах принтера: перевод строки указывает, что из принтера должна выводиться одна строка бумаги, а возврат каретки указывает, что каретка принтера должна вернуться в начало текущей строки.
Печальное состояние «разделителей записей» или «разделителей строк» является наследием мрачных эпох компьютеров.
Теперь мы считаем само собой разумеющимся, что все, что мы хотим представить, является в некотором роде структурированными данными и соответствует различным абстракциям, которые определяют строки, файлы, протоколы, сообщения, разметку, что угодно.
Но однажды это было не совсем так. В приложения встроены управляющие символы и обработка для конкретного устройства. Системы с мертвым мозгом, которые требовали как CR, так и LF, просто не имели абстракции для разделителей записей или ограничителей строки. CR был необходим для того, чтобы телетайп или видеодисплей вернулись в первый столбец, а LF (сегодня, NL, тот же код) был необходим, чтобы заставить его перейти к следующей строке. Я предполагаю, что идея сделать что-то кроме сброса необработанных данных на устройство была слишком сложной.
Unix и Mac фактически указали абстракцию для конца строки, представьте это. К сожалению, они указали разные. (Unix, гм, пришел первым.) И, естественно, они использовали управляющий код, который уже был «близок» к SOP
Поскольку почти все наше операционное программное обеспечение сегодня является потомком операционной системы Unix, Mac или MS, мы застряли в неразберихе с окончанием строки.
Этот день мы приближали, как могли — блокнот в Windows 10 стал понимать юниксовый перевод строки
Notepad в windows 10 начал понимать юниксовый перевод строки, а не только формат Windows.
С проблемой «каши» вместо удобочитаемого текста десятилетиями сталкивались те, кто пытался открыть в среде Windows текстовые документы, подготовленные на других операционных системах. Теперь же всё в одночасье изменяется. И это изменение столь же мало, сколь и эпично по своим практическим результатам и идеологическим последствиям. Microsoft вновь пытается играть в кросс-интеграцию и поддержку открытых стандартов.
Долгие годы Windows Блокнот мог нормально отображать только те текстовые документы, которые содержали символы начала новой строки в формате Windows End of Line (EOL) — «возврат каретки» (CR) и «подача на строку» (LF). На деле это приводило к тому, что Notepad не смог правильно отобразить содержимое текстовых файлов, созданных в Unix, Linux и macOS, где в качестве признака конца строки использовался только символ LF.
Обратите внимание, что строка состояния указывает обнаруженный формат EOL текущего открытого файла.
Так же для гибкого управления новой возможностью в разделе реестра [HKEY_CURRENT_USER\Software\Microsoft\Notepad] вводятся два дополнительных ключа:
По накалу страстей спор о способе начала новой строки в электронных документах сравним со спором о пробелах и табуляциях в исходных текстах программ. У этого противостояния «за строку» было много причин, как лежащих в области древних стандартов и традиций, так и берущих свои корни в особенностях конструкции печатных машин и телетайпов. Не меньшую роль сыграло и стремление одних программистов буквально выполнять (интерпретировать) команды и управляющие символы, а других — следовать здравому смыслу.
Что мы можем узнать о проблеме из Википедии
Исторически на механических пишущих машинках был рычаг, который возвращал каретку к левому краю страницы и прокручивал вал, подвигая бумагу вверх на строку. На телетайпах и более поздних алфавитно-цифровых печатающих устройствах (АЦПУ) вместо каретки была головка, в лазерных принтерах она перестала быть материальной, но в термине возврат каретки всё это продолжали называть кареткой, чтобы его не менять. На телетайпах возврат каретки и подачу строки разделили, откуда традиция представления перевода строки как CR+LF перешла и к текстовым файлам.
Системы, основанные на ASCII или совместимом наборе символов, используют или LF (перевод строки, 0x0A), или CR (возврат каретки, 0x0D) по отдельности, или последовательность CR+LF. Эти названия основаны на командах принтера: перевод строки означает, что одна строка на бумаге должна быть перенесена при печати, а возврат каретки означает, что каретка печатающего устройства должна вернуться к началу текущей строки.
Но как известно, стандарты стандартами, а реализации у всех часто выходят разными. И масла в огонь подливает необходимость корректно отображать унаследованные документы, созданные до эпохи юникода. Отсутствие единого общепринятого представления перевода строки в разных операционных системах надолго осложнило обмен текстовыми данными между ними.
Юникод старается примирить эту разницу, уравнивая CR, LF и CR+LF, однако вступает в противоречие с наследуемым им ASCII при трактовке последовательности LF+CR, не предварённой CR: согласно ASCII это один перевод строки, а согласно Юникоду — два.
Русские Блоги
Подробное объяснение CRLF, CR, LF
Долгое время понимание CRLF, CR, LF ограничивалось определением символов новой строки в разных операционных системах. Так называемое знание того, что это такое, нужно знать почему. Только когда вы найдете удовольствие от обучения, вы будете помнить знания более глубоко.
глоссарий
Как все мы знаем, операционная система Windows использует два символа для переноса строк, а именно CRLF; операционные системы Unix / Linux / Mac OS X используют один символ LF для переноса строк, кроме того, операционная система MacIntosh (ранняя операционная система Mac) использует один символ CR Обернуть.
неофициальная история
Согласно историческим записям, в эпоху механических пишущих машинок давным-давно CR и LF выполняли разные функции: LF перемещал печатную бумагу на одну строку вверх, но оставлял текущее горизонтальное положение печати неизменным, а CR изменял «Carriage» (пишущая машинка). Верхняя каретка прокрутки) откатывается назад к крайней левой стороне бумаги для печати, но сохраняет текущую вертикальную позицию печати без изменений, то есть она все еще находится на той же строке.
Когда CR и LF используются в комбинации, бумага для печати будет перемещаться вверх на одну строку, а следующая позиция печатания вернется к крайней левой стороне строки, что является операцией перевода строки, которую мы понимаем сегодня.
С течением времени механические пишущие машинки постепенно уходили со сцены истории: оригинальная бумага стала отображением сегодняшнего дня, а клавиши пишущей машинки превратились в сегодняшнюю клавиатуру. В эпоху операционных систем, ограниченных нехваткой памяти и места на дискете, некоторые разработчики операционных систем решили использовать один символ для представления символа новой строки, например Unix LF и MacIntosh CR. Их намерение состоит в том, чтобы выполнить операции переноса строки, но не было никакого международного стандарта (или других причин, знает призрак), поэтому существует такая разница в символах.
В заключение
Многие современные текстовые редакторы и инструменты командной строки предоставляют дополнительную конфигурацию разрыва строки, которая удобна для пользователей, чтобы изменить форму разрыва строки в соответствии с их собственными пожеланиями, поэтому нам нужно знать только функции CRLF, CR, LF.