Comments 82
Мне кажется что на многих сайтах имеет место уязвимость, связанная с авторизацией через социальные сети — вероятно многие не фильтруют, например, имена пользователей из соц сетей при их авторизации на различных порталах, которые потом без обработки вставляются в код страницы.
Да, вы правы. Тут один пользователь — chelovekdimka, кажется — подробно описал это и даже снял видео
Из-за рельсов вроде недавно Гитхаб взломали, не? Не с помощью xss конечно, но стоит помнить, что сам не без греха :)
лол взломал то я и ответственно заявляю что rails сам ый секьюрный фреймворк. На эту тему как раз готовлю «разоблачительный» пост а то после бурления говна все всё не так поняли
Апдейт Хабра был плановый, но вчера я очень испугался, когда статья почему-то опубликовалась
Ну апдейт большой очень был — там же не только уязвимости закрывали, но еще и топики пересортировывали.
UFO landed and left these words here
Сейчас все закрыли, но отвечу честно — воспользовался одним из багов, чтобы сделать себе возможность обнулить карму когда-нибудь… На всякий случай :-)
Т.е. я могу обнулить свою карму еще один раз, хотя давно уже делал это :-)
Потому и были, что никому даже в голову не приходило их искать на таком ресурсе!
Я предполагаю, что нет ни единого ресурса, в котором не было бы хоть одной уязвимости. Если же вы автор такого — напишите, пожалуйста, статью, станете в один ряд с автором этого топика.
Конечно, уязвимости есть везде. Но тотальная фильтрация всего ввода и ВСЕГДА контроль клиентских действий на стороне сервера — это то что я делаю на всех сайтах, без исключения.
Первое и главное правило: код на стороне клиента — код в руках врага.
Самое интересное что я находил это, как я его назвал — Вор инвайтов)
Можно было подбирать id недавно выданных инвайтов и отменять их у себя в профиле. Таким образом инвайт возвращался мне, а не тому, кто его отправил :)
Интересно, но какой логикой руководствовался программист, когда делал это? Ведь у каждого инвайта должен быть хозяин — ему то и надо возращать инвайт!
>Для защиты нужно фильтровать кавычки и прочие спецсимволы, которые могут нарушить логику вашего запроса. Также, когда у вас есть число, обязательно явно приводите его к числу.

Никогда не стоит ставить костыли, когда есть принципиальное решение проблемы.
Принципиальное решение — НИКОГДА не использовать конкатенацию запроса и пользовательской переменной. Только prepared statements является решением проблемы, которое невозможно сломать by design.
Я лично еще два года назад несмотря на использование JPA (Java) использовал конкатенацию и не понимал, почему же это плохо. Боже, каким же дубиной я был.
Prepared statements доступно и без ORM. ORM — это уже больше к логической организации данных из БД в памяти приложения, она уместно далеко не всегда.
Не любая база данных поддерживает prepared statements.
Кроме того, бывают (редко, правда) еще и запросы вида
SELECT * FROM Table1 WHERE Id in (<3000 записей>)
три тысячи записей в вебе?
у меня есть ощущение, что вы что-то делаете не так.
Это — кустарная репликация базы, запускаемая по таймеру. 3000 записей бывает только при запуске сервера (т.е. раз в неделю/год в зависимости от воли уборщицы), потому и не оптимизируем.
но, я правильно понимаю, что пользовательского ввода там нет?
Да, пользовательского ввода там нет.

Но когда программист пишет «where id=» + $id, он порой тоже думает, что $id никак не является пользовательским вводом…

Это я к тому, что ваше НИКОГДА является слишком категоричным.
Да, возможно, я был слишком категоричен, но с другой стороны, такую конкатенацию в общем случае использовать нельзя. Ваш случай — скорее исключение и довольно-таки слабо связан с уязвимостями веба (По крайней мере, я не вижу способа все сломать как-либо)
Туда можно sleep() запихнуть.
То есть запрос вида
select data1, data2, data3 from tbl where id=sleep(100) limit 10
подвешивает базу данных на тысячу секунд. Используя конструкцию if, взломщик может вытащить что-нибудь из базы данных, используя отклик «уснуло — не уснуло».
Трудоёмко, но чего только не сделают, чтобы удовлетворить любопытство.
Извините, но в данном конкретном приведенном mayorovp случае такое сделать нельзя. Автоинкрементный id (Насколько я понял) со значением sleep(1000) меня бы насторожил.
И выборка трех тысяч записей не самое быстрое удовольствие, как и последующая их передача (У нас же репликация написана)
Не знаю, как ваша любимая СУБД, а SQL Server Express имеет ограничение на 2048 параметров запроса.
По себе помню, что новичка абстрактное описание раздражает. Может стоит все-таки более предметно?

При пожелании фильтрации xss привести пример фильтра, от SQL инъекций подсказать использовать placeholders, с перечислением расширений, например, PDO для php. Или хотя бы ссылки на хорошие статьи по теме.
Приводить пример XSS-фильтра — опасная практика, в том же codeigniter он состоит более чем из сотни строк, к тому же, я не уверен на 100%, что он защитит сайт от более-менее серьезного взломщика.
Согласен, ссылок на мат.часть не хватает.
Можно, конечно, поискать в сети, но ведь приятнее, когда всё в одном месте (:
XSS — не единственная беда и в одном месте все возможные баги не соберешь. Вот взять те же рельсы. Казалось бы магия везде, ОРМ, фильтрации по-умолчанию и т.д. Но недавно увидел у знакомого кусок кода вроде этого:
Comment.create! { user_id: current_user.id }.merge params[:comment]

Вроде бы все хорошо, но если вдруг кто-то передаст параметр user_id в форму (мало ли, код увидит или еще что), то можно отправлять комментарии от имени другого пользователя. А нужно было всего лишь сделать мерж в другую сторону:
Comment.create! params[:comment].merge({ user_id: current_user.id })

Вывод — очень много зависит от логики.
> Думаете, веб-разработчики стали от этого умнее и предприняли все возможные методы для защиты? Я так не думаю.
Вот для того, чтобы веб-разработчики стали умнее, они должны пройти через путь тех самых скрипт-киддисов :) Сначала киддисы ломают сайты по чужим рецептам, потом им хочется начать писать свои, а для этого нужно очень много всего изучить. Начинают изучать языки программирования, протоколы, какие-то вспомогательные технологии и т.д. Причем нужно изучать, вдаваясь во все подробности, иначе баги не так-то просто будет откопать.
И когда уже есть багаж знаний, они понимают, что лучше создавать, чем ломать :) Но такие люди уже будут создавать сайты, предугадывая большинство вариантов взлома.
Хочу спросить: как при вводе «alert('Bug')» получается диалог с кнопочкой ОК и надписью «XSS»? Или это так специально сделано, чтобы юные пионеры ждали именно «XSS»? :)
По-моему, это лишает наглядности. Я могу подключить Cisco, а сфоткаю Juniper.
Я больше писал для информации для тех, кто, возможно, столкнется и не поймет, а не как претензию.
Если вам не сложно, исправьте пожалуйста.
Упс — не работает, я не заметил, что вы ссылку на чей-то профиль дали :-)
Еще в качестве совета можно предложить использование HttpOnly для всех cookie (в этом случае их нельзя будет получить через XSS).
Cамый безопасный способ, который я видел — у vk.
Собственно, вся авторизация — на login.vk.com, там хранится мастер-куки, назову его так.
При авторизации на любом сайте или сервисе идет редирект на login.vk.com, где проверяется мастер-куки, и делается редирект на страницу, на которой ставится куки-токен для нужного сайта.
Мастер-куки имеет долгий срок жизни, не зависит от ip или чего-либо еще. Куки-токен при смене IP или чего-либо еще сбрасывается. То есть кража куки-токена через XSS ничего не даст, при этом доступа к мастер-куки нет. Единственное, что может быть — xss на login.vk.com, но ИМХО гораздо проще защитить одну страницу, чем весь сайт.
В общем, советы те же, только теперь вам стоит немного потратиться на человека, который за деньги проверит ваш сайт на наличие уязвимостей и сообщит вам результаты.
Хочу предложить Вам в помощь сайт для проверки защиты вашего ресурса — по сути фриланс биржа для людей обладающих умением взлома. От вас требуется разместить проект, указать тип уязвимости и бюджет. Дальше просто — ждать предложения выполнить проект от экспертов взлома. Проект молодой и ждёт своих клиентов!
hackmysite.ru/
Ну а вот от такого рода «атак» защитится, как мне кажется, не представляется возможным.
Если претендуете на легальность, то добавьте простенький функционал подтверждения прав на сайт (как у гугл или яндекс) — например, чтобы заказчик разместил на корне текстовый файл с вашим кодом.
Если бы вы создали проект, то убедилиь что данная функция реализована в первую очередь, называется она верификация или подтверждения прав на сайт, дабы защитить сайты от заказа со стороны конкурентов. Спасибо за интерес к нашему сервису!
И выражаю огромную благодарность хабре за более 200 человек целевой аудитории!
Спасибо, буду теперь активнее искать на хабре уязвимости. Все подробности буду отсылать по указанной почте)
Не обязательно для XSS использовать JavaScript. Например, если на сайте разрешена публикация картинки, то взломщик в качестве src может указать что-нибудь вроде «mysite.com/logout» или повесить менее безобидный action. При закрузке страницы браузер попытается загрузить данный image и вызовет action внутри сессии пользователя.

Хорошего способа от этого взлома нет: либо убрать полностью GET с сайта, либо производить жесткую валидацию внутренних URL-ей, либо вообще при отправке сервер пытается загрузить header имиджа.
Хорошим способом является динамических токен, хранящийся в сессии пользователя и добавляемый во все формы как скрытый параметр.

Если параметра нет — сервер либо игнорирует запрос, либо показывает страницу вида «Вы уверены?»
От 95% XSS неплохо защищает сборка целиком через DOM, ну или только динамических полей. Да и код чище получается.
Only those users with full accounts are able to leave comments. Log in, please.