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-заголовки.
Committing CRLF line separators to the Git repository #41
Comments
OctaneInteractive commented Dec 6, 2015
Hi, I was attempting to commit the EmailReplyParser library in Git when I got the following error:
You are about to commit CRLF line separators to the Git repository.
It is recommended to set the core.autocrlf Git attribute to input and and avoid line separator issues.
I’ve done a bit of a Google and I can’t find any conclusive advice.
Based on the limited understanding of email that I have, formatting and line endings are crucial, so I’d rather not proceed without some guidance first.
The text was updated successfully, but these errors were encountered:
willdurand commented Dec 6, 2015
Hi! What’s your OS? What do you mean exactly by writing «to commit the EmailReplyParser library in Git»?
OctaneInteractive commented Dec 6, 2015
Hi, I’m using OS X 10.9.5 and PHPStorm 10.0.1
A colleague recommended that I choose «Fix and Commit».
dkisselev commented Dec 6, 2015
tl;dr: Just click Fix and Commit.
There are two ways to represent a line ending in a source code file, CRLF or just LF. Windows tends to default to CRLF, but the rest of the world uses just LF, so Git/Programming standards in general prefer LF. Nearly ever text editor out there (except for notepad.exe) understands LF just fine, so there’s no reason to use CRLF.
Basically PHPStorm is telling you that you’re doing something un-ideal, and suggesting to fix it automatically for you.
Chances are that the file you’re working on was last edited by someone running Windows so it’s in CLRF.
Clicking Fix and Commit will configure Git to just always automatically convert line endings to LF before it commits, and that’s a highly recommended/standard thing to do.
OctaneInteractive commented Dec 6, 2015
I’d downloaded the files straight from here, which suggests the CLRF characters are in the source code.
sandeepyohans commented Apr 11, 2018
@dkisselev Thank you for your answer. I was previously working on Windows PC and then shifted to Mac. So now I know the reason for this error.
Veereshdammur commented Oct 25, 2019
@dkisselev Thank you for an explanation.
majonathany commented Oct 2, 2020
Clicking Fix and Commit will configure Git to just always automatically convert line endings to LF before it commits, and that’s a highly recommended/standard thing to do.
I think the line endings should be left as-is, and Git disregard any differences between the /n and /r/n tokens, this way it abstracts away that from the user and git can produce clearer diffs when developers inspect commits or are solving merge conflicts.
Forcing CRLF line separator in my project
I want to ensure CRLF (Windows style) line separator in my project. I am checking a few alternatives, but not sure which one is the best for this.
Desired Behavior:
If a file is not CRLF, which IntelliJ IDEA shows at the bottom: 
3 Answers 3
I don’t think it is possible to cause the Maven build to fail due to invalid line separators in your project’s files unless someone has created a plugin to do that. However, you can configure a code inspection in Intellij IDEA to fail for that reason. This is how you could provoke such a failure:
JetBrains has an open bug ticket to force compilation failure based on inspection errors, so this approach is not exactly what you were asking for. But in the absence of any Maven-based solution it might be best you can do. See the Code Inspection documentation from JetBrains for more information.
One other possible approach is to look at TeamCity, another JetBrains tool for continuous integration. I haven’t used it, but perhaps it allows you to configure failure when there are inspection errors (though from a quick look at their documentation I couldn’t see how).
Update:
It looks like TeamCity might be worth a look after all. Its documentation on Build Failure Conditions states:
When using code examining tools in your build, like code coverage, duplicates finders, inspections and so on, your build generates various numeric metrics. For these metrics you can specify a threshold which, when exceeded, will fail a build.
1. What is CRLF and LF
CRLF iscarriagereturnline feedabbreviation of. Chinese means carriage return and line feed.
LF is an abbreviation for line feed, meaning Chinese for line feed.
2. Why should we explore CRLF and LF
There are three options when learning git software and installing git to configuring the lien ending conversion.
There are three operations for handling line endings (Windows-style, Unix-style, As-is) that do two operations (Checkout, Commit).
Why are there three kinds of processing line endings (line endings)? A good explanation is given on the Git help page.
If you’re using Git to collaborate with others on GitHub, ensure that Git isproperly configured to handle line endings.
Every time you press return on your keyboard you’re actuallyinserting an invisible character called a_line ending_. Historically, differentoperating systems have handled line endings differently.
When you view changes in a file, Git handles line endings in its own way.Since you’re collaborating on projects with Git and GitHub, Git mightproduce unexpected results if, for example, you’re working on a Windows machine,and your collaborator has made a change in OS X.
The meaning is easy to understand, so I will not translate it. It is important to note that due to historical reasons, various operating systems have adopted different processing methods for dealing with end-of-line characters. While Git and GitHub
3. The difference between the three methods
CRLF means to use the carriage return and line feed two characters at the end of the sentence (that is, we often use «\ r \ n» line feed when programming in Windows)
LF means end of sentence, only use new line.
CR means only use enter.
4. How to convert in Git?
Configure in Git by the following command
Explanation: core.autocrlf is a variable in git that is responsible for processing line endings. You can set three values – true, inout, false.
What is the effect of setting to three values?
If core.autocrlf is set to true, that means that any time you add a file to the git repo that git thinks is a text file, it will turn all CRLF line endings to just LF before it stores it in the commit.。
Set to true, when adding files to the git repository, git will treat them as text files. He will turn crlf into lf. 【2】
If core.autocrlf is set to false, no line-ending conversion is ever performed, so text files are checked in as-is. This usually works ok。【2】
When set to false, line-endings will not be converted. The text file remains the same.
When set to input, add the file git repository stone, git program crlf lf When someone checks the code, it’s still lf. Therefore, under the window operating system, do not use this setting.
This is the explanation given in Reference 2 hope to help everyone.
Yet another way to show how autocrlf works
where x is either CRLF (windows-style) or LF (unix-style) and arrows stand for
Line separators when using composer / GIT
I’ve created sample laravel project using 2 different commands (on Windows 8):
Why is that? Is it have anything in common with GIT? I would like to have in files original separators (the same as in packagist) and not modified
If it has anything in common with Fit, when I run GIT command in cmd I get:
so CLRF isn’t set to true so why line endings are CRLF?
1 Answer 1
I can confirm this is related to GIT.
This means that Git will process all text files and make sure that CRLF is replaced with LF when writing that file to the object database. It will not, however, do the reverse. When you read files back out of the object database and write them into the working directory they will still have LFs to denote the end of line. This setting is generally used on Unix/Linux/OS X to prevent CRLFs from getting written into the repository. The idea being that if you pasted code from a web browser and accidentally got CRLFs into one of your files, Git would make sure they were replaced with LFs when you wrote to the object database.
Since any good windows editor should support both CRLF and LF I see no problem with using LF only.
Difference between dist and source
Run composer show laravel/laravel and you can see
Why dist is LF
The zip archive is downloaded and extracted. No git actions are performed the line feed is obtained as provided in the repo/zip.
Why source is CRLF
* text=auto will make Git handle the files in whatever way it thinks is best. Now you are on Windows and Git thinks it is best to change it to CRLF as this is the default for Windows I think.
