Брендон Штерн (Brandon Sterne), менеджер по проектам, связанным с безопасностью Mozilla, представил (http://blog.mozilla.com/security/2009/06/19/shutting-down-xs.../) новую политику безопасности Firefox, известную под названием Content Security Policy (https://wiki.mozilla.org/Security/CSP) (CSP). Новая политика направлена против эпидемии атак межсайтового скриптинга (XSS), в течение нескольких лет являющихся бичом многих популярных сайтов.Стандартные XSS-атаки иногда используют уязвимости в web-приложениях для того, чтобы запустить в браузере JavaScript с правами доверяемого домена. С CSP браузер будет выполнять только скрипты с доменов, указанных в "белом списке" - всё остальное будет блокироваться. Это даёт администраторам возможность, например, указать свой собственный скрипт-сервер, с которого можно грузить и выполнять скрипты.
С CSP даже JavaScript, встроенный в страничку, по умолчанию не будет больше выполняться. Сайты будут иметь возможнос...URL: http://www.h-online.com/open/Mozilla-s-new-security-policy--...
Новость: http://www.opennet.me/opennews/art.shtml?num=22308
Интересно, что мешает вместе с искусственным контентом и тег внедрить. И каковы отличия надёжных источников от ненадёжных.
>Интересно, что мешает вместе с искусственным контентом и тег внедрить.То что скрипт на СВОЕМ серваке повесить + обойти фильтрацию например, форума, etc намного проще чем хакнуть сервер настолько чтобы на нем поиметь возможность свои хидеры втыкать.XSS - распостраненный тип атак который не требует от хакера иметь какой либо реальный доступ к серваку - достаточно на любом сайте с user-generated контентом как-то надурить фильтр - и вуаля, JS с хаксоровского сервака уже крутится на радость хакеру.Хоть он и не имеет доступа к ФС и конфигу сервака а лишь надул фильтрацию.Взлом серверов с поимением доступа к ФС и конфиге - намного более редкий тип атак.И ничего особо с ним не сделаешь - в этом случае атакер может переколбасить все и вся.
По моему какой-то адский ад. С одной стороны проблем с безопасностью не решает, так как надёжность источника будет подтверждать пользователь. С другой стороны создаёт кучу дополнительный проблем веб-программистом.
Скажем так, это напоминает решение для повышения безопасности квартиры - замуровать дверь и всем лазить строго через окно кухни.
> С одной стороны проблем с безопасностью не решает, так как надёжность источника будет подтверждать пользователь.ты что-то путаешь.
> С другой стороны создаёт кучу дополнительный проблем веб-программистом.
Не пользуйся на сайте и проблем не будет. И "кучи проблем" не вижу.
>ты что-то путаешь.Возможно. Поясни, если не трудно.
>Не пользуйся на сайте и проблем не будет.
Чем не пользоваться? JavaScript? Может лучше сразу интернетом не пользоваться? тогда проблемточно не будет.
>И "кучи проблем" не вижу.
Наверное ты не веб-разработчик?
>>ты что-то путаешь.
>
>Возможно. Поясни, если не трудно.CSP устроена так, что можно ей не пользоваться - все будет работать по старому варианту.
Другими словами, вы можете забыть об этой технологии и у вас не будет никаких ошибок даже после её внедрения.>>Не пользуйся на сайте и проблем не будет.
>
>Чем не пользоваться? JavaScript? Может лучше сразу интернетом не пользоваться? тогда проблемточно
>не будет.Имелось в виду "не пользуйтесь CSP".
Веб-разработчик. Пока проблем не вижу вообще. Приведите хотябы несколько, из увиденной вами кучи?
Например куча сайтов с элементами типа <div onclick=""
>Например куча сайтов с элементами типа <div onclick=""Да, вероятно это станет проблемой. Интересно, будут ли выполняться обработчики событий, выставленные в элементах выполнением доверенного скрипта ?
>в элементах выполнением доверенного скрипта ?Могу предположить что это будет определяться где находится скрипт - на доверяемом сервере или нет.Ну, просто внедренный скрипт - да, можети и не будет работать (с хорошими целями).Кто печется о безопасности своих пользователей - сможет подтянуть гайки.Да, кой-что придется переписать при этом.Пофигисты смогут оставить юзеров on their own как и раньше.Просто ничего вообще не меняя.Единственное что было бы здорово если бы браузер показывал как-то индикацию - пофигист ли вебмастер вон того сайта или же подтянул гайки.
ну обработчики можно внедрять с помощью elemrnt.onclick="...", но вот что делать со старым кодом?
>ну обработчики можно внедрять с помощью elemrnt.onclick="...", но вот что делать со
>старым кодом?Переписывать. Как XSS плодить - так нет проблем, а как писать правильно - так сразу вопросы об унаследованных технологиях.
>>ты что-то путаешь.
>
>Возможно. Поясни, если не трудно.автор сайта указывает, с каких сайтов можно грузить скрипты. Автор сайта, а не пользователь.
>
>>Не пользуйся на сайте и проблем не будет.
>
>Чем не пользоваться? JavaScript? Может лучше сразу интернетом не пользоваться? тогда проблемточно
>не будет.Как раз эта технология позволяет и JavaScript включать по умолчанию, и не бояться, что сайт был взломан. Почти не бояться - кто мешает взломщику положить сво скрипты на тот же сайт и сделать на них ссылку... Но от XSS защищает хорошо.
>
>>И "кучи проблем" не вижу.
>
>Наверное ты не веб-разработчик?КАк раз для веб-разработчика все прелести этой технологии должны быть понятны. Это и кроссайтовые AJAX запросы разрешает, и запрещает XSS одновременно, причём без участия пользователя.
>КАк раз для веб-разработчика все прелести этой технологии должны быть понятны. Это
>и кроссайтовые AJAX запросы разрешает, и запрещает XSS одновременно, причём без
>участия пользователя.Кроссайтовые AJAX запросы вроде как тут не причём. Там ограничение по домену.
>
>>КАк раз для веб-разработчика все прелести этой технологии должны быть понятны. Это
>>и кроссайтовые AJAX запросы разрешает, и запрещает XSS одновременно, причём без
>>участия пользователя.
>
>Кроссайтовые AJAX запросы вроде как тут не причём. Там ограничение по домену.
>При чём. Сейчас одна из плохорешаемых проблем - делать AJAX запросы в чужой домен, браузер такие запросы не пропускает. С новой технологией мы вместе с свйтом будем поддерживать список разрешённых доменов.
Ну вообще то там речь шла не не про домены а про хосты. Впрочем, дай бог, чтобы ты был прав.
>Ну вообще то там речь шла не не про домены а про
>хосты. Впрочем, дай бог, чтобы ты был прав.Мое предложение Вам - матчасть подучить. И заодно на первоисточник хоть краем глаза взглянуть - 99% вопросов, при знании основ, отпадет сходу.
>По моему какой-то адский ад. С одной стороны проблем с безопасностью не
>решает, так как надёжность источника будет подтверждать пользователь. С другой стороны
>создаёт кучу дополнительный проблем веб-программистом.
>Скажем так, это напоминает решение для повышения безопасности квартиры - замуровать дверь
>и всем лазить строго через окно кухни.Наоборот :) Юзеру будет проще отшибать кривые руки %)
al'a из моих фильтров ABPwww.opennet.ru#TD(BGCOLOR=#D9DAC6)
www.opennet.ru#TABLE(fadv)
www.opennet.ru#table(bgcolor=#441144)
>По моему какой-то адский ад. С одной стороны проблем с безопасностью не
>решает, так как надёжность источника будет подтверждать пользователь.Решает - хакерье не сможет просто пропихать свой JS надурив фильтры и т.п..Даже если пропихает, он попросту не выполнится и XSS не удастся.А сейчас если удалось надуть фильтры и как-то воткнуть свой JS - а всем пофиг, что это не вебмастер положил.Посему левый хакиръ может умыкнуть куки с авторизацией и прочая и что-то сделать от вашего лица.Не больно приятно, а?
Ага, офигенно. Как раньше XSS'ами вгоняли <script> так теперь будут вгонять <meta http-equiv="X-Content-Security-Policy" content="allow h4x0r.com" />.Спрвашивается, а где разница?
>Ага, офигенно. Как раньше XSS'ами вгоняли <script> так теперь будут вгонять <meta http-equiv="X-Content-Security-Policy" content="allow h4x0r.com" />.
>
>Спрвашивается, а где разница?Наверно такой тэг через meta просто не будет проходить.
> Наверно такой тэг через meta просто не будет проходить.В спеках сказано что или HTTP-хидер или <meta>. Явно так сказано, даже с примерами.
Так что, прозреваю в сией инициативе нечто с лужицей и газом.
>> Наверно такой тэг через meta просто не будет проходить.
>
>В спеках сказано что или HTTP-хидер или <meta>. Явно так сказано, даже с примерами.
>
>Так что, прозреваю в сией инициативе нечто с лужицей и газом.Есть же ещё проблема запуска файлов с жёсткого диска - охранили файл, хочется его открыть. meta помогает сохранить белые списки, но конечно кривовато.
Хотя с другой стороны, сейчас хакеры стараются зашифровать адреса серверов с реальными скриптами, а новая технология требует в явном виде их указать, это упростит внесение таких серверов в чёрные списки. В общем, идея хорошая и простореализуемая, но требует осмысления. В любом случае какой-то итерфейс для указания доверенных серверов всё равно нужен.
>Так что, прозреваю в сией инициативе нечто с лужицей и газом.Прозреваю тормоза который не понимает что надуть фильтр воткнув свой левый JS - на пару порядков проще чем получить полноценный доступ на запись произвольных файлов на вебсерваке, чтобы переписать HTTP хидер или meta.Страница то может из введенных юзерами данных генериться - на форумах, блогах и прочих динамических сайтах.И лишь стремный фильтр который на все случаи жизни слабать трудно отделяет хакера от успеха XSS.А вот доступ на запись на сервант получить... если хакер это сделает, уже поздно что-то там защищать.Хакер в этом случае может просто рассовать вместо даунлоадов троянцев например, а то и базу умыкнуть, "поадминить" ресурс, etc - куда эффективнее несчастного XSS :)
Если кто не понял разницы - для тупых объясняю: нынче много сайтов где середина паги генерится из введенного контента.Например форумы и прочая.А вот <meta> или http хидеры не генерятся на основе того что там надолбили юзеры.Доступно для средних умов?
Там на много больше в спецификации описано. Например запрет a href="javascript:blablabl();" и a href="#" onclick="blablabl();", любой eval, ин-лайн код в url и еще до кучи всего https://wiki.mozilla.org/Security/CSP/Specмета, кстати, можно заменить на header() и вгоняйте всё-что угодно до потери пульса.
А вообще дырки - зло и лучше знать где они, пусть и путём получения по голове, чем всю жизнь просидеть в зомби.
>Спрвашивается, а где разница?Я думаю что разница - в том что воткнуть XSS надурив фильтр в середину страницы на сайтах типа форумов и блогов - фигня вопрос, достаточно придумать что-то что соберется в валидную конструкцию но пролезет через фильтры.И вуаля - наш JS уже тырит у юзера куки с авторизацией в контексте текущего сайта, вытворяет что-то от лица юзеря и прочее.Красота.XSS во весь рост.
А вот meta - вроде только в начале страницы можно?И тем паче - содержимое этого поля не берется из БД или чего-то еще с содержимым условно-подконтрольным хакеру.Т.е. хакеру мало возможности постить сообщения и надуть фильтр.Надо полноценный доступ к серверу.А если у хакера полноценный доступ на сервер на запись - от него уже ничто не спасет, можно просто пагу с трояном отгружать всем вокруг :)
В общем-то, сказанное верно. Но:> фигня вопрос, достаточно придумать что-то что соберется в валидную конструкцию но пролезет через фильтры
Вопрос фигня, если фильтры фигня, чего быть не должно.
http://framework.korsengineering.com/?Doc_Comments.show&file...
http://us.php.net/manual/en/function.htmlspecialchars.php
http://htmlpurifier.org/Я очень надеюсь, что технологии типа CSP не взрастят идеологию "браузер всё защитит", и послудуюшее игнорирование безопасности со стороны сервера.
>Я очень надеюсь, что технологии типа CSP не взрастят идеологию "браузер всё
>защитит", и послудуюшее игнорирование безопасности со стороны сервера.Эээ... а он вроде обратную взращиват - можно секурити подтянуть.Как раз со стороны сервера указав клиенту - что по мнению сервера безопасно.Если хочется.Если не хочется - оставьте как есть, наплевав на то что xss находят везде и постоянно.Какие проблемы?Вижу как может стать лучше.Хуже не станет, worst case == тому что есть сейчас.
Замечательно, давно пора.
Этот CSP, конечно, сделает атаки XSS труднее, но только на тех браузерах, которые его поддерживают и на тех сайтах, которые его используют.Не нравится мне когда проблемы со скриптами на сервере решаются при помощи браузера. Ну неправильно это, неправильно. XSS лечится грамотной валидацией вводимых данных.
>Этот CSP, конечно, сделает атаки XSS труднее, но только на тех браузерах,
>которые его поддерживают и на тех сайтах, которые его используют.
>
>Не нравится мне когда проблемы со скриптами на сервере решаются при помощи
>браузера. Ну неправильно это, неправильно. XSS лечится грамотной валидацией вводимых данных.
>Есть реализуемые способы, а есть фантастические. Проверка данных - это фантастика.
Какая же фантастика, если все нормальные сайты это в какой-то форме делают? В общем-то, проблема XSS возникает только тогда, когда пользователям разрешают вводить данные в разных хитрых форматах, например ввиде урезанного HTML. Даже для таких случаев существуют весьма компактные программы, которые удаляют ненужное (т.е. все, что может содержать или вызывать скрипты).
>Какая же фантастика, если все нормальные сайты это в какой-то форме делают?
>В общем-то, проблема XSS возникает только тогда, когда пользователям разрешают вводить
>данные в разных хитрых форматах, например ввиде урезанного HTML. Даже для
>таких случаев существуют весьма компактные программы, которые удаляют ненужное (т.е. все,
>что может содержать или вызывать скрипты).Практика программирования показывает, что требовать делать проверки бессмысленно - их не делают всё равно. Надо минимизировать места, где могут появиться ошибки. Вообще любая безопасность лучше обеспечивается внешним контролем.
Фильтровать вводные данные, которые потом будут показываться на сайте, все равно надо обязательно, и не так уж это сложно. Так что, насколько я понимаю, этот CSP будет полезен _только_ в тех случаях, когда сайт проворонил закачанный врагом скрипт. И ради этого надо будет отказаться от встроенного жаваскрипта и простых событий в HTML. И еще делать отдельный поддомен для скриптов. И пихать какие-то теги на страницу или хедеры в заголовок. Ну а если каждый браузер себе такое придумает, отдельно?Если уж хотят делать запрещалку скриптов, то можно намного проще - ввести тег <nosript token="x">. Между тегами с одинаковыми токенами скрипты не исполнять, скриптлеты не разрешать и так далее. Токен генерировать случайно каждый раз. В таком раскладе не нужно будет плодить доменов и раскидывать по ним скрипты. Запрещай что хочешь, прямо на странице. Хочешь - всю страницу. Хочешь - только часть.
Однако такие вещи все равно идея нездоровая, они концентрирую внимания на мелочах. Это "безопасность" на манер антивируса для дырявой системы, в которую постоянно лезут черви, и которая исполняет незнамо что.
>И ради этого надо будет отказаться от
>встроенного жаваскрипта и простых событий в HTML. И еще делать отдельный
>поддомен для скриптов. И пихать какие-то теги на страницу или хедеры
>в заголовок. Ну а если каждый браузер себе такое придумает, отдельно?
>Вы неправильно поняли идею. Точнее, две идеи: 1) автор сайта указывает свои доверенные сайты, 2) в саму HTML страничку больше нельзя тыкать JS ни в каком виде. В результате только взлом сайта - может быть даже потребуется взлом сервера, чтобы добраться до конфигов сервера, - позволит вставлять свои скрипты, а это уже на порядки сложнее чем XSS.
Простые событя в HTML всё равно уходят в прошлое - уже сейчас проще прописывать их с помощью jQuery, не трогая дизайн. Встроенный JavaScript тоже особой ценности не представляет - типичная CMS сейчас собирает все скрипты в один и прицепляет в <script src=...> - то есть никаких дополнительных неудобств не предвидится.
Встроенный javascript и так считается порочной практикой. А уж javascript:-ссылки - абсолютное зло.
>Встроенный javascript и так считается порочной практикой. А уж javascript:-ссылки - абсолютное зловсеми методами надо пользоваться с умом
>поддомен для скриптов. И пихать какие-то теги на страницу или хедеры
>в заголовок.Ну, блин, не нравится - не делайте.А кому не пофиг на безопасность их юзеров - сделают.В итоге на сайтах где вебмастерам не пофиг поиметь юзеров будет труднее.В остальных случаях все будет как сейчас.Это плохо?По-моему нормальное средство для укрепления сайтов vs XSS для тех кому это надо.
>Какая же фантастика, если все нормальные сайты это в какой-то форме делают?Но XSS находят, так?Не понимаю, какие претензии к этой технологии?Хучший случай при ее работе - все остается как сейчас.Лучший - неленивые подтянут у себя секурити.Даже если это и потребует изменения кода.Хуже, определенно, не станет.Лучше (хоть и не для всех) - может.
> XSS лечится грамотной валидацией вводимых данных.Все так.Но почему-то XSS был, есть и будет есть...