Принцип домино или XSS на крупных сайтах рунета

[nick4fake]

<< для комфортного просмотра ставить 1080p
Мне кажется, с моими 1366*768 это будет не очень комфортно.

<< На странице регистрации нового аккаунта Mail.ru не фильтровались поля 'Имя' и 'Фамилия'
Жесть, крупный же портал, а на таком подскользнулись.

Как долго они исправляли уязвимость?

[chelovekdimka]

Насколько я помню, я написал им вчера ночью, переписывался сегодня и где-то часа 2-3 назад они исправили.

[chelovekdimka]

Забавная штука в том, что для сайта Mail.ru такое имя пользователя не несло никаких последствий.

[Mup4uk]

А если не секрет, как давно Вы обнаружили данную уязвимость? :)

[Ekstazi]

Спасибо, теперь буду знать.

[mipxtx]

А при чем здесь mail.ru? они наоборот дают пользователю максимум — даже такие «экзотические» имена без последствий для других пользователей. Это же бага livejournal, то что они не фильтруют имена.
А вообще самая правильная (но самая трудоемкая) стратегия сохранения пользовательских данных — as is. И квотировать их на выводе.

[johnnythekid]

а как же sql-инъекции?

[VolCh]

Для того, чтобы сохранить данные as is нужно сделать экранирование для SQL и в базе данные будут храниться в том виде, в котором их ввёл пользователь.

[VolCh]

Почему самая трудоемкая? Только SQL экранирование при записи в базу, и html или json при выводе в html или json. Не нужно придумывать фильтр, который будет экранировать и sql, и html, и json, да ещё так, чтобы хоть что-то от вводимой информации осталось.

[mipxtx]

Потому что проще один раз зафильтровать при вводе, чем искать все места, где нужно фильтровать при выводе.
Один разработчик написал интерфейс получения данных из базы. Он данные не фильтрует, потому как мало ли где они будут нужны. Другой разработчик написал универсальный html контейнер, который выводит данные и думает, что все пришедшие к нему данные уже отфильтрованы. теоритически надо писать фильтр прослойку между ними, но третий разработчик видит два компонента и соединяет, потому что один получает данные, а другой выводит. И таких мест может быть очень много. Вот поэтому и появляется соблазн писать в базу уже фильтрованные значения

[mipxtx]

гигабайты — не смогут конечно, nginx отвалится по post size limit`у
а вообще размеры не плохо бы задавать прямо в базе: varchar даст вставить только сколько нужно. Типы данных, они для этого и нужны :)

[mipxtx]

А как вставить 1024 раза по мегу? Если, например, у юзера есть имя (предположем varchar 50)
те 1024 раза можно создать юзера, но для этого надо уже использовать бота и с другой стороны баррикад буду средства противостояния ботам.
Потом при проектировании бд нужно провести анализ того, что будет в ней хранится, как сделать так, чтоб даже если в бд будут миллионы записей, она бы нормально работала.
Вообще, саме лучшее решение — активное использование мозга.

[johnnythekid]

> зафильтровать при вводе

но ведь это уже не

> самая правильная (но самая трудоемкая) стратегия сохранения пользовательских данных — as is

[mipxtx]

Да, я написал, что проще всего зафильтровать, и это самая первая мысль, которая может придти в голову при борьбе с XSS. И написал, почему она может придти в голову, но при кажущейся простоте и изящности — она неправильная. Юзеру плевать на наши проблемы фильтраций XSS

[shaida]

Мне представилась возможность посмотреть это видео ещё до устранения уязвимости.
Действительно epic win :)

[Stdit]

Получается, что XSS был не у mail.ru, а был (и есть) у сайтов, которые доверяют внешним входным данным (в данном случае, логину от mail.ru) и выводят его в сыром виде. Я правильно понял?

[chelovekdimka]

Да, всё так и есть.

[Dr_Logic]

То есть я и сейчас могу создать свой openid провайдер, который будет намеренно эксплуатировать ту же уязвимость, которую ненамеренно эксплуатировал mail.ru? А lj в курсе?

[anton_tereshko]

уже пофиксили

[Grebenshikov]

мне кажется, со стороны mail.ru было бы логичнее фильтровать введенные данные, а не те, которые выводят.

[GreatKoshak]

А чего вы его минусуете?
Т.е. не всем пользователям mail.ru можно использовать свой аккаунт для авторизации?
Если уж добавляете такой API, то будьте добры — следите за ним.

[GreatKoshak]

Ааа, чёрт. Извините, не подумал, когда писал, что речь о банальном XSS идёт.

[eagle250]

Только не «логину от mail.ru», а имени и фамилии пользователя.

[pgkireev]

У меня иногда складывается впечатление, что программисты mail.ru совершенно незнакомы с XSS-атаками. С момента запуска, их находят пачками на их сервисах…

[trijin]

так это XSS из сайта не касалось, касалось всех остальных, только =)

[pgkireev]

Ну, во-первых, mail.ru при регистрации неотфильтровало, введенные данные
А, во-вторых, могу ошибаться, но фильтры не стояли в API, из-за чего и срабатывает xss

Так что это еще хуже: ладно бы это только их касалось, а так это подстава для сторонних владельцев сайтов, которые используют API mail.ru

[VolCh]

Сторонние владельцы сайтов решили, что mail.ru должен экранировать свой вывод, хотя такая функция нигде в документации не упоминается? Fail Сторонние владельцы сайтов доверяют внешним данным? Epic Fail Может ещё авторы telnet должны им экранирование обеспечить?

Я вот даже тому, что сам в БД или файл записал не доверяю

[SLY_G]

«Прозвище лучшего друга — Neo. „
5 баллов.

[TheShock]

Мне больше понравился адрес в Яндексе:

[kirilloid]

У них был какой-то вёб интерфейс. Потом сделали новый на ajax и назвали neo. Вторую версию назвали neo2.
Вы еще не видели, как у них (в Я.почте) корневой объект для namespace-ов называется ;-)

[sompylasar]

mailstatic.yandex.net/neo2/4.12.11/jsx/_bootstrap.js

Daria.nop=function(){},

…

Вы это имели в виду?

[kirilloid]

ага, Daria.

[SLY_G]

Было бы здорово в такой статье разместить и методы защиты от подобных атак.

[tunelix]

плагин к браузеру NoScript

[Stom]

это с точки зрения пользователя, а с точки зрения разработчика — фильтровать вводимые данные и данные из вне

[VolCh]

Зачем фильтровать вводимые данные? Фильтровать нужно вывод и для, например, html одни фильтры, а для json — другие.

[Nimor]

Вы прям ТС имели ключ ко всем дверям.

[vanfukov]

Джим Мориарти?

[undead_ekb]

Морфеус, перелогинтесь

[za121]

Ох, как можно было накуралесить с этой XSS, особенно с Яндексом, да в особо грамотных руках.

В данное баге все виноваты. Не проверяют входные данные на всех используемых системах. Получается, что при авторизации с дружественной системы разработчики положились на сознательность сторонних сервисов, что они все уже проверили при регистрации пользователя.

[z3apa3a]

API mail.ru отдает не HTML, а текстовые данные в JSON. Кодировать данные из плейнтекста в HTML, если они выводятся в HTML, это не прихоть, это необходимость. Помимо угловых скобочек бывают еще и амперсанды и кавычки. А сознательность и доверие тут, в общем-то, непричем.

[Isis]

Ой, сколько вы денег потеряли…

[Nimor]

Не для всех они на первом месте.

[Kind_evil]

не факт, на комментарий А если не секрет, как давно Вы обнаружили данную уязвимость? :), автор так и не ответил =)

[chelovekdimka]

Вчера

[acy]

Как по-вашему можно было на этом заработать? Просить отправить смс?

[Nimor]

Можно было сайты продвигать редиректом, просто ссылки ставить, много как.

[AntonDiaz]

Не очень в этом всём разбираюсь, так что вот такой вопрос (не только к автору поста):
Как опасна была такая XSS с точки зрения «exploitable»? Насколько я понял, скрипт мог запуститься, только если жертва зарегистрируется в определенном сервисе, используя заранее зарегистрированный злоумышленником аккаунт в mail.ru. То есть данная XSS должна была быть приправлена нехилой соц-инженерией?

P.S. (Теперь к автору). Надеюсь, что фильтрация ввода у них не только на уровне JS идет?

[chelovekdimka]

Не знаю, спросите у них сами.

[Zibx]

можно было выполнить любые действия от пользователя, который смотрит на это имя\фамилию. То есть писать комменты, голосовать, утянуть кукки пользователя в конце концов.

[ainu]

Можно наугад. Допустим массово запускаем акцию, ждём 1 процента из тех, что попадутся, далее что то с этим делаем.
В любом случае (как и в случае с классическим XSS) надо завести пользователя сервиса на свою страницу. Так что разницы особой нет.

[ComodoHacker]

Разница есть, тут можно завести пользователя на одну из тысяч чужих хорошо посещаемых страниц.

[AntonDiaz]

Спасибо всем отписавшимся. Теперь понял: очень серьезная уязвимость. Видимо, для высокой безопасности сайтов с критичными данными и возможностями (регистрационная почта, банки) нужно использовать отдельную копию браузера (которая будет использоваться только для таких сайтов). От JS отказываться не хочется.

[Prof]

Уязвимость действительно серьёзная, но вот в крайности впадать не стоит. И если у тебя захотят увести мыло, то вряд ли тебе какой-то «другой» браузер поможет…

[AntonDiaz]

Тут дело в том, что активную XSS в интернет-кошелек протолкнуть будет трудно. А пассивную XSS — проще (как уже показано в предыдущем топике о Яндекс.Деньгах того же автора). Таким образом, использование отдельного браузера для строго определенного типа сайтов сможет уберечь от пассивных XSS, так как зараженный сайт и уязвимый сайт будут работать в разных браузерах (и, соответственно, cookie уязвимого сайта не будут доступны для зараженного). Есть, конечно, и такой вариант: пока открыта и еще не закрыта сессия на сайт с критичными данными, не открывать и не держать открытым никакие другие сайты. Однако это не так безопасно, так как у многих людей в браузере навешаны JS-расширения, которым тоже не следует слишком доверять :)

[nsinreal]

Ох, дядя, какой же ты добрый… Я как представлю сколько можно было с таким сделать, так слюни текут

[chelovekdimka]

Да ладно, вот если б я по тихому сообщил об уязвимости, не делал никаких постов, не записывал никаких видео — вот это был бы поступок настоящего альтруиста. ;)

[Nimor]

Если бы еще Вам заплатили за спасение интернета 15k$ — можно было-бы вообще не где не писать.

P. S. Когда писал сообщение заметил странность, это баг такой на хабре? Google Chrome
Видео бага: screencast.com/t/hVbjnOfmb

Не могу в Q&A писать, топик создать тоже. Карма маленькая.

[flaresun]

Данный «баг» достаточно подробно описан:
habrahabr.ru/info/help/qa/ — последний абзац
habrahabr.ru/info/help/karma/

[Nimor]

Баг не состоял в том, что я не могу создать QA или почему у меня плохая карма и я топики не могу создавать.

Баг в том, что после нажатия на написать при опр-условиях — продолжает идти анимация и блокирует у меня кнопку. Про карму и QA я написал чтобы объяснить написание комментария именно в данном топике.

[flaresun]

Значит прошу прощения, не правильно Вас понял…

[Nimor]

Да меня многие наверно не так поняли. Если можете — сообщите кому надо. Видео есть выше.

[Nostr]

the matrix has you too лучше все-таки было с двумя o написать :)

[chelovekdimka]

да, в видео хорошо видны мои колебания по этому поводу :D

[shanker]

Ну вот. С видео Ваши статьи стали более наглядными. Думаю, и по голосованию преимущество этой статьи над прошлой будет заметно. Так держать!

[chelovekdimka]

Если б по первому посту видео делал, там бы интереснее было: там фильтрация символов стояла, там кодирование в URL, там куки на снифер отсылались :)

[shanker]

В таких видео свои куки будет довольно сложно закрывать. Так что тут палка о двух концах. Я долго видео редактирую перед заливкой на Хабр, закрываю палево всякое. Это занимает львиную долю времени. Где-то 60-70%

[entze]

А OMG разве не закрылся? Или это был финальный вброс аналитика?

[shanker]

Саппорт Mail.Ru уязвимость закрыл? Надо бы проверить… Вдруг можно их фильтры пройти, закодировав код

[YAAP]

Отпишитесь, дабы другие не полезли проверять ;)

[GAmoVeR]

С каждой минутой просмотра челюсть моя опускалась все ниже…
По эпичности это сравнимо со сливом исходников из за неправильного экспорта svn, только в масштабах рунета.

Обидно что ТС вряд ли будет вознагражден материально, особенно учитывая возможные последствия от эксплуатации этой уязвимости…
PS: Соблазн использовать уязвимость был? :)

[turbo_exe]

да, кстати: материальное вознаграждение автора изрядно подняло бы карму mail.ru

[akirsanov]

Ну допустим XSS червяк в случае с хранимой xss на некой блогоплотформе.
Схема работы — автор червя запускает его в своем блоге, все, кто открыли его блог, автоматически запостили в свой блог тот же самый код.
Червь распостраняется по всей платформе, парализуя работу, либо перенаправляя пользователей на другой сайт(как вариант с эксплоитами), и в дополнение похищая персональные данные из профилей (фио, емейл, телефон) и отправляет на сторонний сайт.

[kirilloid]

Рано или поздно это случится =) Правда, надо чтобы сайты поддерживали ваш сайт — openID-провайдер. Если его нет в основном списке, надо ковырять, смотреть, как именно оно работает и кто кому какие данные передаёт

[akirsanov]

надеюсь вопрос риторический.

[akirsanov]

Золотое правило — никогда не доверять данным, пришедшим от пользователя/внешних источников.
Мейл.ру не фильтрует данные пользователя — проёб
Сервисы доверяют данным Мейл.ру — проёб

[shanker]

Через XSS можно получить доступ к аккаунту пользователя незаметно. А в случае использования техники xss tunnell можно сделать прокси из браузера жертвы и ходить от имени его браузера на сайт в контексте того сайта, где произошла атака:

Tunnelling HTTP Traffic Through XSS Channels: XSS Tunnelling is the tunnelling of HTTP traffic through an XSS Channel to use virtually any application that supports HTTP proxies. This paper explains the idea and the real world implementation.

Демонстрация:

www.youtube.com/watch?v=OZghFrJ4P-g

[egorinsk]

Еще раз поясню. Никакой подобной уязвимости в mail.ru не было и нет. Уязвимость — в других сайтах, которые *неправильно* подключили авторизацию через mail.ru. Я не вижу ни одной причины, почему никнейм пользователя не может например содержать слова script, document и cookie. Может, этот никнейм отражает уникальные черты характера пользователя.

Более того, я считаю, в целях улучшения образовательного уровня сторонних разработчиков mail.ru не должен был запрещать использование тегов в имени. Пусть разработчики сами исправляют то, что накривокодили.

Справедливости ради, ручное экранирование всех выводимых строк — дело муторное, легко сделать ошибку, лучше делать это на уровне шаблонизатора, как в django или на уровне объектов-строк, как в лебедевском Parser, или еще как-то, но автоматически.

Те, кто не хочет использовать «умный» шаблонизатор или маркеры типов строк, а тупо лепит [? php echo $userName ?] или использует mysql_query («INSERT INTO table {$_POST['username']}») вместо плейсхолдеров в запросах — ребята, вы сами себе злобные буратины, с таким подходом у вас всегда будет куча уязвимостей. Иногда мне кажется, что разработчикам PHP надо было встроить htmlspecialchars прямо в оператор echo (а в mysqli и PDO — нормальную поддержку нормальных плейсхолдеров).

[kirilloid]

«Я не вижу ни одной причины, почему никнейм пользователя не может например содержать слова script, document и cookie»

[iago]

Под такой саундтрек как в видео, можно снимать вид из окна и будут смотреть и слушать :)

[orcy]

Довольно позорно для mail.ru, плюс закрыли баг не очень удачно (запрет тегов). В версии которую разворачивают для тестеров всегда должен быть по умолчанию пользователь/аккаунт/итд вида
<button>Hello</button> (интересно как это отоброзит парсер).

[orcy]

Невнимательно прочитал: в mail.ru все работало хорошо.

[UpRight]

Браво уникально честному Человеку-Димке!