Comments 95
<< для комфортного просмотра ставить 1080p
Мне кажется, с моими 1366*768 это будет не очень комфортно.
<< На странице регистрации нового аккаунта Mail.ru не фильтровались поля 'Имя' и 'Фамилия'
Жесть, крупный же портал, а на таком подскользнулись.
Как долго они исправляли уязвимость?
Мне кажется, с моими 1366*768 это будет не очень комфортно.
<< На странице регистрации нового аккаунта Mail.ru не фильтровались поля 'Имя' и 'Фамилия'
Жесть, крупный же портал, а на таком подскользнулись.
Как долго они исправляли уязвимость?
Насколько я помню, я написал им вчера ночью, переписывался сегодня и где-то часа 2-3 назад они исправили.
Забавная штука в том, что для сайта Mail.ru такое имя пользователя не несло никаких последствий.
А при чем здесь mail.ru? они наоборот дают пользователю максимум — даже такие «экзотические» имена без последствий для других пользователей. Это же бага livejournal, то что они не фильтруют имена.
А вообще самая правильная (но самая трудоемкая) стратегия сохранения пользовательских данных — as is. И квотировать их на выводе.
А вообще самая правильная (но самая трудоемкая) стратегия сохранения пользовательских данных — as is. И квотировать их на выводе.
а как же sql-инъекции?
Почему самая трудоемкая? Только SQL экранирование при записи в базу, и html или json при выводе в html или json. Не нужно придумывать фильтр, который будет экранировать и sql, и html, и json, да ещё так, чтобы хоть что-то от вводимой информации осталось.
Потому что проще один раз зафильтровать при вводе, чем искать все места, где нужно фильтровать при выводе.
Один разработчик написал интерфейс получения данных из базы. Он данные не фильтрует, потому как мало ли где они будут нужны. Другой разработчик написал универсальный html контейнер, который выводит данные и думает, что все пришедшие к нему данные уже отфильтрованы. теоритически надо писать фильтр прослойку между ними, но третий разработчик видит два компонента и соединяет, потому что один получает данные, а другой выводит. И таких мест может быть очень много. Вот поэтому и появляется соблазн писать в базу уже фильтрованные значения
Один разработчик написал интерфейс получения данных из базы. Он данные не фильтрует, потому как мало ли где они будут нужны. Другой разработчик написал универсальный html контейнер, который выводит данные и думает, что все пришедшие к нему данные уже отфильтрованы. теоритически надо писать фильтр прослойку между ними, но третий разработчик видит два компонента и соединяет, потому что один получает данные, а другой выводит. И таких мест может быть очень много. Вот поэтому и появляется соблазн писать в базу уже фильтрованные значения
UFO just landed and posted this here
гигабайты — не смогут конечно, nginx отвалится по post size limit`у
а вообще размеры не плохо бы задавать прямо в базе: varchar даст вставить только сколько нужно. Типы данных, они для этого и нужны :)
а вообще размеры не плохо бы задавать прямо в базе: varchar даст вставить только сколько нужно. Типы данных, они для этого и нужны :)
UFO just landed and posted this here
А как вставить 1024 раза по мегу? Если, например, у юзера есть имя (предположем varchar 50)
те 1024 раза можно создать юзера, но для этого надо уже использовать бота и с другой стороны баррикад буду средства противостояния ботам.
Потом при проектировании бд нужно провести анализ того, что будет в ней хранится, как сделать так, чтоб даже если в бд будут миллионы записей, она бы нормально работала.
Вообще, саме лучшее решение — активное использование мозга.
те 1024 раза можно создать юзера, но для этого надо уже использовать бота и с другой стороны баррикад буду средства противостояния ботам.
Потом при проектировании бд нужно провести анализ того, что будет в ней хранится, как сделать так, чтоб даже если в бд будут миллионы записей, она бы нормально работала.
Вообще, саме лучшее решение — активное использование мозга.
> зафильтровать при вводе
но ведь это уже не
> самая правильная (но самая трудоемкая) стратегия сохранения пользовательских данных — as is
но ведь это уже не
> самая правильная (но самая трудоемкая) стратегия сохранения пользовательских данных — as is
Мне представилась возможность посмотреть это видео ещё до устранения уязвимости.
Действительно epic win :)
Действительно epic win :)
Получается, что XSS был не у mail.ru, а был (и есть) у сайтов, которые доверяют внешним входным данным (в данном случае, логину от mail.ru) и выводят его в сыром виде. Я правильно понял?
У меня иногда складывается впечатление, что программисты mail.ru совершенно незнакомы с XSS-атаками. С момента запуска, их находят пачками на их сервисах…
так это XSS из сайта не касалось, касалось всех остальных, только =)
Ну, во-первых, mail.ru при регистрации неотфильтровало, введенные данные
А, во-вторых, могу ошибаться, но фильтры не стояли в API, из-за чего и срабатывает xss
Так что это еще хуже: ладно бы это только их касалось, а так это подстава для сторонних владельцев сайтов, которые используют API mail.ru
А, во-вторых, могу ошибаться, но фильтры не стояли в API, из-за чего и срабатывает xss
Так что это еще хуже: ладно бы это только их касалось, а так это подстава для сторонних владельцев сайтов, которые используют API mail.ru
Сторонние владельцы сайтов решили, что mail.ru должен экранировать свой вывод, хотя такая функция нигде в документации не упоминается? Fail Сторонние владельцы сайтов доверяют внешним данным? Epic Fail Может ещё авторы telnet должны им экранирование обеспечить?
Я вот даже тому, что сам в БД или файл записал не доверяю
Я вот даже тому, что сам в БД или файл записал не доверяю
«Прозвище лучшего друга — Neo. „
5 баллов.
5 баллов.
Было бы здорово в такой статье разместить и методы защиты от подобных атак.
Вы прям ТС имели ключ ко всем дверям.
Морфеус, перелогинтесь
Ох, как можно было накуралесить с этой XSS, особенно с Яндексом, да в особо грамотных руках.
В данное баге все виноваты. Не проверяют входные данные на всех используемых системах. Получается, что при авторизации с дружественной системы разработчики положились на сознательность сторонних сервисов, что они все уже проверили при регистрации пользователя.
В данное баге все виноваты. Не проверяют входные данные на всех используемых системах. Получается, что при авторизации с дружественной системы разработчики положились на сознательность сторонних сервисов, что они все уже проверили при регистрации пользователя.
Ой, сколько вы денег потеряли…
Не для всех они на первом месте.
не факт, на комментарий А если не секрет, как давно Вы обнаружили данную уязвимость? :), автор так и не ответил =)
Как по-вашему можно было на этом заработать? Просить отправить смс?
Не очень в этом всём разбираюсь, так что вот такой вопрос (не только к автору поста):
Как опасна была такая XSS с точки зрения «exploitable»? Насколько я понял, скрипт мог запуститься, только если жертва зарегистрируется в определенном сервисе, используя заранее зарегистрированный злоумышленником аккаунт в mail.ru. То есть данная XSS должна была быть приправлена нехилой соц-инженерией?
P.S. (Теперь к автору). Надеюсь, что фильтрация ввода у них не только на уровне JS идет?
Как опасна была такая XSS с точки зрения «exploitable»? Насколько я понял, скрипт мог запуститься, только если жертва зарегистрируется в определенном сервисе, используя заранее зарегистрированный злоумышленником аккаунт в mail.ru. То есть данная XSS должна была быть приправлена нехилой соц-инженерией?
P.S. (Теперь к автору). Надеюсь, что фильтрация ввода у них не только на уровне JS идет?
Не знаю, спросите у них сами.
можно было выполнить любые действия от пользователя, который смотрит на это имя\фамилию. То есть писать комменты, голосовать, утянуть кукки пользователя в конце концов.
UFO just landed and posted this here
Можно наугад. Допустим массово запускаем акцию, ждём 1 процента из тех, что попадутся, далее что то с этим делаем.
В любом случае (как и в случае с классическим XSS) надо завести пользователя сервиса на свою страницу. Так что разницы особой нет.
В любом случае (как и в случае с классическим XSS) надо завести пользователя сервиса на свою страницу. Так что разницы особой нет.
Спасибо всем отписавшимся. Теперь понял: очень серьезная уязвимость. Видимо, для высокой безопасности сайтов с критичными данными и возможностями (регистрационная почта, банки) нужно использовать отдельную копию браузера (которая будет использоваться только для таких сайтов). От JS отказываться не хочется.
Уязвимость действительно серьёзная, но вот в крайности впадать не стоит. И если у тебя захотят увести мыло, то вряд ли тебе какой-то «другой» браузер поможет…
Тут дело в том, что активную XSS в интернет-кошелек протолкнуть будет трудно. А пассивную XSS — проще (как уже показано в предыдущем топике о Яндекс.Деньгах того же автора). Таким образом, использование отдельного браузера для строго определенного типа сайтов сможет уберечь от пассивных XSS, так как зараженный сайт и уязвимый сайт будут работать в разных браузерах (и, соответственно, cookie уязвимого сайта не будут доступны для зараженного). Есть, конечно, и такой вариант: пока открыта и еще не закрыта сессия на сайт с критичными данными, не открывать и не держать открытым никакие другие сайты. Однако это не так безопасно, так как у многих людей в браузере навешаны JS-расширения, которым тоже не следует слишком доверять :)
Ох, дядя, какой же ты добрый… Я как представлю сколько можно было с таким сделать, так слюни текут
Да ладно, вот если б я по тихому сообщил об уязвимости, не делал никаких постов, не записывал никаких видео — вот это был бы поступок настоящего альтруиста. ;)
Если бы еще Вам заплатили за спасение интернета 15k$ — можно было-бы вообще не где не писать.
P. S. Когда писал сообщение заметил странность, это баг такой на хабре? Google Chrome
Видео бага: screencast.com/t/hVbjnOfmb
Не могу в Q&A писать, топик создать тоже. Карма маленькая.
P. S. Когда писал сообщение заметил странность, это баг такой на хабре? Google Chrome
Видео бага: screencast.com/t/hVbjnOfmb
Не могу в Q&A писать, топик создать тоже. Карма маленькая.
Данный «баг» достаточно подробно описан:
habrahabr.ru/info/help/qa/ — последний абзац
habrahabr.ru/info/help/karma/
habrahabr.ru/info/help/qa/ — последний абзац
habrahabr.ru/info/help/karma/
Баг не состоял в том, что я не могу создать QA или почему у меня плохая карма и я топики не могу создавать.
Баг в том, что после нажатия на написать при опр-условиях — продолжает идти анимация и блокирует у меня кнопку. Про карму и QA я написал чтобы объяснить написание комментария именно в данном топике.
Баг в том, что после нажатия на написать при опр-условиях — продолжает идти анимация и блокирует у меня кнопку. Про карму и QA я написал чтобы объяснить написание комментария именно в данном топике.
the matrix has you too лучше все-таки было с двумя o написать :)
Ну вот. С видео Ваши статьи стали более наглядными. Думаю, и по голосованию преимущество этой статьи над прошлой будет заметно. Так держать!
А OMG разве не закрылся? Или это был финальный вброс аналитика?
Саппорт Mail.Ru уязвимость закрыл? Надо бы проверить… Вдруг можно их фильтры пройти, закодировав код
С каждой минутой просмотра челюсть моя опускалась все ниже…
По эпичности это сравнимо со сливом исходников из за неправильного экспорта svn, только в масштабах рунета.
Обидно что ТС вряд ли будет вознагражден материально, особенно учитывая возможные последствия от эксплуатации этой уязвимости…
PS: Соблазн использовать уязвимость был? :)
По эпичности это сравнимо со сливом исходников из за неправильного экспорта svn, только в масштабах рунета.
Обидно что ТС вряд ли будет вознагражден материально, особенно учитывая возможные последствия от эксплуатации этой уязвимости…
PS: Соблазн использовать уязвимость был? :)
UFO just landed and posted this here
Ну допустим XSS червяк в случае с хранимой xss на некой блогоплотформе.
Схема работы — автор червя запускает его в своем блоге, все, кто открыли его блог, автоматически запостили в свой блог тот же самый код.
Червь распостраняется по всей платформе, парализуя работу, либо перенаправляя пользователей на другой сайт(как вариант с эксплоитами), и в дополнение похищая персональные данные из профилей (фио, емейл, телефон) и отправляет на сторонний сайт.
Схема работы — автор червя запускает его в своем блоге, все, кто открыли его блог, автоматически запостили в свой блог тот же самый код.
Червь распостраняется по всей платформе, парализуя работу, либо перенаправляя пользователей на другой сайт(как вариант с эксплоитами), и в дополнение похищая персональные данные из профилей (фио, емейл, телефон) и отправляет на сторонний сайт.
Через XSS можно получить доступ к аккаунту пользователя незаметно. А в случае использования техники xss tunnell можно сделать прокси из браузера жертвы и ходить от имени его браузера на сайт в контексте того сайта, где произошла атака:
Демонстрация:
www.youtube.com/watch?v=OZghFrJ4P-g
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
Еще раз поясню. Никакой подобной уязвимости в 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 — нормальную поддержку нормальных плейсхолдеров).
Более того, я считаю, в целях улучшения образовательного уровня сторонних разработчиков mail.ru не должен был запрещать использование тегов в имени. Пусть разработчики сами исправляют то, что накривокодили.
Справедливости ради, ручное экранирование всех выводимых строк — дело муторное, легко сделать ошибку, лучше делать это на уровне шаблонизатора, как в django или на уровне объектов-строк, как в лебедевском Parser, или еще как-то, но автоматически.
Те, кто не хочет использовать «умный» шаблонизатор или маркеры типов строк, а тупо лепит [? php echo $userName ?] или использует mysql_query («INSERT INTO table {$_POST['username']}») вместо плейсхолдеров в запросах — ребята, вы сами себе злобные буратины, с таким подходом у вас всегда будет куча уязвимостей. Иногда мне кажется, что разработчикам PHP надо было встроить htmlspecialchars прямо в оператор echo (а в mysqli и PDO — нормальную поддержку нормальных плейсхолдеров).
Под такой саундтрек как в видео, можно снимать вид из окна и будут смотреть и слушать :)
Довольно позорно для mail.ru, плюс закрыли баг не очень удачно (запрет тегов). В версии которую разворачивают для тестеров всегда должен быть по умолчанию пользователь/аккаунт/итд вида
<button>Hello</button> (интересно как это отоброзит парсер).
Браво уникально честному Человеку-Димке!
Sign up to leave a comment.
Принцип домино или XSS на крупных сайтах рунета