Comments 82
Мне кажется что на многих сайтах имеет место уязвимость, связанная с авторизацией через социальные сети — вероятно многие не фильтруют, например, имена пользователей из соц сетей при их авторизации на различных порталах, которые потом без обработки вставляются в код страницы.
Отличная статья!
Так вот из за кого я всю ночь не мог почитать Хабр :=)
UFO just landed and posted this here
Не думал, что на хабре будут такие детские уязвимости
Потому и были, что никому даже в голову не приходило их искать на таком ресурсе!
Я предполагаю, что нет ни единого ресурса, в котором не было бы хоть одной уязвимости. Если же вы автор такого — напишите, пожалуйста, статью, станете в один ряд с автором этого топика.
выглядят по детски. а встерчаются везде — тот же гитхаб
Самое интересное что я находил это, как я его назвал — Вор инвайтов)
Можно было подбирать id недавно выданных инвайтов и отменять их у себя в профиле. Таким образом инвайт возвращался мне, а не тому, кто его отправил :)
Можно было подбирать id недавно выданных инвайтов и отменять их у себя в профиле. Таким образом инвайт возвращался мне, а не тому, кто его отправил :)
Трололо негодует, вы сломали их мечту :)
>Для защиты нужно фильтровать кавычки и прочие спецсимволы, которые могут нарушить логику вашего запроса. Также, когда у вас есть число, обязательно явно приводите его к числу.
Никогда не стоит ставить костыли, когда есть принципиальное решение проблемы.
Принципиальное решение — НИКОГДА не использовать конкатенацию запроса и пользовательской переменной. Только prepared statements является решением проблемы, которое невозможно сломать by design.
Никогда не стоит ставить костыли, когда есть принципиальное решение проблемы.
Принципиальное решение — НИКОГДА не использовать конкатенацию запроса и пользовательской переменной. Только prepared statements является решением проблемы, которое невозможно сломать by design.
использовать нормальную ORM
Не любая база данных поддерживает prepared statements.
Кроме того, бывают (редко, правда) еще и запросы вида
SELECT * FROM Table1 WHERE Id in (<3000 записей>)
Кроме того, бывают (редко, правда) еще и запросы вида
SELECT * FROM Table1 WHERE Id in (<3000 записей>)
три тысячи записей в вебе?
у меня есть ощущение, что вы что-то делаете не так.
у меня есть ощущение, что вы что-то делаете не так.
Это — кустарная репликация базы, запускаемая по таймеру. 3000 записей бывает только при запуске сервера (т.е. раз в неделю/год в зависимости от воли уборщицы), потому и не оптимизируем.
но, я правильно понимаю, что пользовательского ввода там нет?
Да, пользовательского ввода там нет.
Но когда программист пишет «where id=» + $id, он порой тоже думает, что $id никак не является пользовательским вводом…
Это я к тому, что ваше НИКОГДА является слишком категоричным.
Но когда программист пишет «where id=» + $id, он порой тоже думает, что $id никак не является пользовательским вводом…
Это я к тому, что ваше НИКОГДА является слишком категоричным.
Да, возможно, я был слишком категоричен, но с другой стороны, такую конкатенацию в общем случае использовать нельзя. Ваш случай — скорее исключение и довольно-таки слабо связан с уязвимостями веба (По крайней мере, я не вижу способа все сломать как-либо)
Туда можно sleep() запихнуть.
То есть запрос вида
Трудоёмко, но чего только не сделают, чтобы удовлетворить любопытство.
То есть запрос вида
select data1, data2, data3 from tbl where id=sleep(100) limit 10Трудоёмко, но чего только не сделают, чтобы удовлетворить любопытство.
для таких запросов можно сделать так (php): stackoverflow.com/a/920523
По себе помню, что новичка абстрактное описание раздражает. Может стоит все-таки более предметно?
При пожелании фильтрации xss привести пример фильтра, от SQL инъекций подсказать использовать placeholders, с перечислением расширений, например, PDO для php. Или хотя бы ссылки на хорошие статьи по теме.
При пожелании фильтрации xss привести пример фильтра, от SQL инъекций подсказать использовать placeholders, с перечислением расширений, например, PDO для php. Или хотя бы ссылки на хорошие статьи по теме.
Спасибо, сейчас занят, но ближе к вечеру допишу
Приводить пример XSS-фильтра — опасная практика, в том же codeigniter он состоит более чем из сотни строк, к тому же, я не уверен на 100%, что он защитит сайт от более-менее серьезного взломщика.
Согласен, ссылок на мат.часть не хватает.
Можно, конечно, поискать в сети, но ведь приятнее, когда всё в одном месте (:
Можно, конечно, поискать в сети, но ведь приятнее, когда всё в одном месте (:
Хорошо, сейчас добавлю
XSS — не единственная беда и в одном месте все возможные баги не соберешь. Вот взять те же рельсы. Казалось бы магия везде, ОРМ, фильтрации по-умолчанию и т.д. Но недавно увидел у знакомого кусок кода вроде этого:
Вроде бы все хорошо, но если вдруг кто-то передаст параметр user_id в форму (мало ли, код увидит или еще что), то можно отправлять комментарии от имени другого пользователя. А нужно было всего лишь сделать мерж в другую сторону:
Вывод — очень много зависит от логики.
Comment.create! { user_id: current_user.id }.merge params[:comment]
Вроде бы все хорошо, но если вдруг кто-то передаст параметр user_id в форму (мало ли, код увидит или еще что), то можно отправлять комментарии от имени другого пользователя. А нужно было всего лишь сделать мерж в другую сторону:
Comment.create! params[:comment].merge({ user_id: current_user.id })
Вывод — очень много зависит от логики.
С обнулением кармы сильно.
хех twitter.com/#!/homakov/status/177839734754770944
у вм так же работает верификация смс
у вм так же работает верификация смс
> Думаете, веб-разработчики стали от этого умнее и предприняли все возможные методы для защиты? Я так не думаю.
Вот для того, чтобы веб-разработчики стали умнее, они должны пройти через путь тех самых скрипт-киддисов :) Сначала киддисы ломают сайты по чужим рецептам, потом им хочется начать писать свои, а для этого нужно очень много всего изучить. Начинают изучать языки программирования, протоколы, какие-то вспомогательные технологии и т.д. Причем нужно изучать, вдаваясь во все подробности, иначе баги не так-то просто будет откопать.
И когда уже есть багаж знаний, они понимают, что лучше создавать, чем ломать :) Но такие люди уже будут создавать сайты, предугадывая большинство вариантов взлома.
Вот для того, чтобы веб-разработчики стали умнее, они должны пройти через путь тех самых скрипт-киддисов :) Сначала киддисы ломают сайты по чужим рецептам, потом им хочется начать писать свои, а для этого нужно очень много всего изучить. Начинают изучать языки программирования, протоколы, какие-то вспомогательные технологии и т.д. Причем нужно изучать, вдаваясь во все подробности, иначе баги не так-то просто будет откопать.
И когда уже есть багаж знаний, они понимают, что лучше создавать, чем ломать :) Но такие люди уже будут создавать сайты, предугадывая большинство вариантов взлома.
Хочу спросить: как при вводе «alert('Bug')» получается диалог с кнопочкой ОК и надписью «XSS»? Или это так специально сделано, чтобы юные пионеры ждали именно «XSS»? :)
сегодня утром еще немножко потестил гитхаб
1 homakov.github.com/ghfollow.html#youfollowme
2. github.com/youfollowme/followers
уже пофикшено.
1 homakov.github.com/ghfollow.html#youfollowme
2. github.com/youfollowme/followers
уже пофикшено.
Еще в качестве совета можно предложить использование HttpOnly для всех cookie (в этом случае их нельзя будет получить через XSS).
Cамый безопасный способ, который я видел — у vk.
Собственно, вся авторизация — на login.vk.com, там хранится мастер-куки, назову его так.
При авторизации на любом сайте или сервисе идет редирект на login.vk.com, где проверяется мастер-куки, и делается редирект на страницу, на которой ставится куки-токен для нужного сайта.
Мастер-куки имеет долгий срок жизни, не зависит от ip или чего-либо еще. Куки-токен при смене IP или чего-либо еще сбрасывается. То есть кража куки-токена через XSS ничего не даст, при этом доступа к мастер-куки нет. Единственное, что может быть — xss на login.vk.com, но ИМХО гораздо проще защитить одну страницу, чем весь сайт.
Собственно, вся авторизация — на login.vk.com, там хранится мастер-куки, назову его так.
При авторизации на любом сайте или сервисе идет редирект на login.vk.com, где проверяется мастер-куки, и делается редирект на страницу, на которой ставится куки-токен для нужного сайта.
Мастер-куки имеет долгий срок жизни, не зависит от ip или чего-либо еще. Куки-токен при смене IP или чего-либо еще сбрасывается. То есть кража куки-токена через XSS ничего не даст, при этом доступа к мастер-куки нет. Единственное, что может быть — xss на login.vk.com, но ИМХО гораздо проще защитить одну страницу, чем весь сайт.
В общем, советы те же, только теперь вам стоит немного потратиться на человека, который за деньги проверит ваш сайт на наличие уязвимостей и сообщит вам результаты.
Хочу предложить Вам в помощь сайт для проверки защиты вашего ресурса — по сути фриланс биржа для людей обладающих умением взлома. От вас требуется разместить проект, указать тип уязвимости и бюджет. Дальше просто — ждать предложения выполнить проект от экспертов взлома. Проект молодой и ждёт своих клиентов!
hackmysite.ru/
Хочу предложить Вам в помощь сайт для проверки защиты вашего ресурса — по сути фриланс биржа для людей обладающих умением взлома. От вас требуется разместить проект, указать тип уязвимости и бюджет. Дальше просто — ждать предложения выполнить проект от экспертов взлома. Проект молодой и ждёт своих клиентов!
hackmysite.ru/
Ну а вот от такого рода «атак» защитится, как мне кажется, не представляется возможным.
Если претендуете на легальность, то добавьте простенький функционал подтверждения прав на сайт (как у гугл или яндекс) — например, чтобы заказчик разместил на корне текстовый файл с вашим кодом.
UFO just landed and posted this here
Не обязательно для XSS использовать JavaScript. Например, если на сайте разрешена публикация картинки, то взломщик в качестве src может указать что-нибудь вроде «mysite.com/logout» или повесить менее безобидный action. При закрузке страницы браузер попытается загрузить данный image и вызовет action внутри сессии пользователя.
Хорошего способа от этого взлома нет: либо убрать полностью GET с сайта, либо производить жесткую валидацию внутренних URL-ей, либо вообще при отправке сервер пытается загрузить header имиджа.
Хорошего способа от этого взлома нет: либо убрать полностью GET с сайта, либо производить жесткую валидацию внутренних URL-ей, либо вообще при отправке сервер пытается загрузить header имиджа.
От 95% XSS неплохо защищает сборка целиком через DOM, ну или только динамических полей. Да и код чище получается.
htmlspecialchars не защищает от XSS с использованием UTF-7, нужно использовать htmlentities — http://stackoverflow.com/questions/3623236/htmlspecialchars-vs-htmlentities-when-concerned-with-xss
Sign up to leave a comment.
Защищаем сайт от атак на примере ХабраХабра