Комментарии 30
Ну про остальных не знаю, но вот у ВК с безопасностью проблемы.
Да, защита от XSS есть, CSRF-токены там всякие.
На самом деле, не все так радужно. Много сказано на эту тему, но пока они не будут поощрять за уязвимости, ничего хорошего не выйдет.
Может это только мое мнение, тут не мне судить, так сказать.
Но факт остается в том, что я находил довольно много разных нехороших штук, там, у них под капотом.
Чего стоит только моя XSS в Августе 2012 Хабр (если мне сейчас 17, то сколько было тогда?).
НО(!), у них такая политика. С этим ничего не поделаешь. Мы живем в таком мире, где просто не существует идеальной защиты.
Но почему не предпринимать попытки для ее создания (читай Баг баунти), я не понимаю.
П.с: Кстати, FB меня кинул, с CSRF ;)
Да, защита от XSS есть, CSRF-токены там всякие.
На самом деле, не все так радужно. Много сказано на эту тему, но пока они не будут поощрять за уязвимости, ничего хорошего не выйдет.
Может это только мое мнение, тут не мне судить, так сказать.
Но факт остается в том, что я находил довольно много разных нехороших штук, там, у них под капотом.
Чего стоит только моя XSS в Августе 2012 Хабр (если мне сейчас 17, то сколько было тогда?).
НО(!), у них такая политика. С этим ничего не поделаешь. Мы живем в таком мире, где просто не существует идеальной защиты.
Но почему не предпринимать попытки для ее создания (читай Баг баунти), я не понимаю.
П.с: Кстати, FB меня кинул, с CSRF ;)
А про аутентификацию на web-API расскажете что-нибудь интересное?
Да, конечно.
- При использовании и парсинге XML запросов нужно запретить парсинг сущностей и не допустить XXE уязвимости
- Если используется sha1/sha512/md5 (и т.п.) при генерации токена ключ подставлять справа от конкатенируемых параметров, чтобы не допустить length extension attack
- Использовать https для API. При этом, если используете Web API в мобильном приложении — проверяйте сертификат на корректность (как в браузере, когда выскакивает окошко, если сертификат не валиден). А еще лучше — зашить отпечатки сертификата, чтобы усложнить анализ протокола (т.е. даже при добавлении своего сертификата глобально на телефон, использование приватного ключа при сниффинге трафика ничего не дало). Т.е. только при модификации приложения стало возможным анализировать ваш API (встречается крайне редко, даже у «гигантов» индустрии)
Заголовок
Нажимая на ссылку, я ожидал описание механизмов и средств защиты, архитектуры подсистем информационной безопасности и все такое.
А получил некий сумбурный набор информации об аутентификации в веб-приложениях и парочку примеров о защите от некоторых видов web-атак.
Как защищаются гиганты: о безопасности Google, VK и другихне соответствует содержимому.
Нажимая на ссылку, я ожидал описание механизмов и средств защиты, архитектуры подсистем информационной безопасности и все такое.
А получил некий сумбурный набор информации об аутентификации в веб-приложениях и парочку примеров о защите от некоторых видов web-атак.
Предложите более корректное.
Те компании, про которые я знаю, что рассказать, не разрешают мне этого делать (NDA), про те, о которых мне нечего рассказать — я молчу. Поэтому и не пишу топики с такими заголовками.
Я лишь предложил Вам предложить более корректное название статьи, при чем тут NDA?
def offtop = {
Топик на злобу дня. Начинаю делать веб-приложение для личного сервиса и встал вопрос об авторизации. Несмотря на миниатюрность размеров приложения, хочу сделать его насколько возможно безопасным, так как оно работает с моими реальными финансовыми данными. С фронтами дел почти не имел, посему прошу направить в нужную сторону при поиски инфы. Есть ли какой-то свод алгоритмов, направленных на снижение угроз перебора, xss и пр.?
Гугл конечно молодец, но фильтровать тонны инфы по непрофильной для меня области в рамках личного проекта не улыбается.
}
Топик на злобу дня. Начинаю делать веб-приложение для личного сервиса и встал вопрос об авторизации. Несмотря на миниатюрность размеров приложения, хочу сделать его насколько возможно безопасным, так как оно работает с моими реальными финансовыми данными. С фронтами дел почти не имел, посему прошу направить в нужную сторону при поиски инфы. Есть ли какой-то свод алгоритмов, направленных на снижение угроз перебора, xss и пр.?
Гугл конечно молодец, но фильтровать тонны инфы по непрофильной для меня области в рамках личного проекта не улыбается.
}
На чём пишите то?
Scala + play 2.2
Как сделаете — потом просто пишите в личку, гляну :)
Скалу на пентесте встречал один раз, использовалась только как бэкенд.
Скалу на пентесте встречал один раз, использовалась только как бэкенд.
Спасибо за предложение!
Вообще я хотел бы некое описание потенциальных проблем с рекомендациями по их предотвращению. Насколько понимаю, все типы уязвимостей общие и не зависят от конкретной платформы. Поэтому предполагаю существование некой шпаргалки или свода лучших практик. По сути паттерны безопасности при разработке и администрировании.
Вообще я хотел бы некое описание потенциальных проблем с рекомендациями по их предотвращению. Насколько понимаю, все типы уязвимостей общие и не зависят от конкретной платформы. Поэтому предполагаю существование некой шпаргалки или свода лучших практик. По сути паттерны безопасности при разработке и администрировании.
«когда при полном дампе базы данных ни один пароль всё равно не получится расшифровать, так как будет неизвестна статичная «соль» (которая, например, зашита в коде)»
Посоветуйте где лучше хранить соль и пароли, ведь если «сломают» и уведут дамп, то увести текущие исходники и конфиги (там где хранятся пароли и соль) будет так же не сложно достать.
Посоветуйте где лучше хранить соль и пароли, ведь если «сломают» и уведут дамп, то увести текущие исходники и конфиги (там где хранятся пароли и соль) будет так же не сложно достать.
Не стоит думать что соль удастся спрятать от кражи. Если злоумышленник украл базу, есть большая вероятность что он доберется и до исходников.
Зачем вообще нужна соль? Чтобы, получив базу с захешированными паролями, злоумышленник не смог использовать заранее сгенерированные таблицы хешей.
Однако, если соль статическая и известна злоумышленнику, он может начать перебор атакуя при этом каждый из хешей.
Если соль динамическая и для каждого пароля своя, атаковать перебором нужно будет каждый хеш отдельно.
Подробнее тут.
В общем генерируйте соль для каждого пароля и кладите в базу рядом, либо используйте в качестве соли уникальные данные (тут правда есть нюансы + соль не должна быть короткой).
Зачем вообще нужна соль? Чтобы, получив базу с захешированными паролями, злоумышленник не смог использовать заранее сгенерированные таблицы хешей.
Однако, если соль статическая и известна злоумышленнику, он может начать перебор атакуя при этом каждый из хешей.
Если соль динамическая и для каждого пароля своя, атаковать перебором нужно будет каждый хеш отдельно.
Подробнее тут.
В общем генерируйте соль для каждого пароля и кладите в базу рядом, либо используйте в качестве соли уникальные данные (тут правда есть нюансы + соль не должна быть короткой).
Спасибо за статью, отлично когда такого рода продвинутая и актуальная информация достается так просто!
Что-то не очень понятно насчет сохранения пользовательского контента на отдельном домене:
* если нет cookie, каким образом контен пользователя будет «обезопасен» от неавторизированного доступа? Секретными урл-ками?
* что нужно чтобы проэксплуатировать такую уязвимость как XSS? Нужно чтобы как-то пользователь контент злоумышленника как HTML/JS?
Что-то не очень понятно насчет сохранения пользовательского контента на отдельном домене:
* если нет cookie, каким образом контен пользователя будет «обезопасен» от неавторизированного доступа? Секретными урл-ками?
* что нужно чтобы проэксплуатировать такую уязвимость как XSS? Нужно чтобы как-то пользователь контент злоумышленника как HTML/JS?
Спасибо за отзыв!
Ответ на первый вопрос:
Если контент в итоге должен остаться публичным — то проблем нет, отдавайте просто ссылку на него.
Если нет (например — вложения почты) — то гугл генерит временные токены для доступа («живут» около минуты).
Второй вопрос не понял, о чём речь?
Ответ на первый вопрос:
Если контент в итоге должен остаться публичным — то проблем нет, отдавайте просто ссылку на него.
Если нет (например — вложения почты) — то гугл генерит временные токены для доступа («живут» около минуты).
Второй вопрос не понял, о чём речь?
Про второй вопрос: я пытался представить себе как злоумышленник мог бы воспользоваться такой фичей как upload произвольного контента не в соц. сетях. Могу себе представить что на gmail или vk это можно сделать как-то рассылая ссылки на плохую html страницу пользователям того же gmail или вконтакте, в надежде что они откроют страницу и запустят «злой» javascript под своей авторизацией. А вот на каком-нибудь другом проекте где пользователи не знают о существовании друг друга, добиться того чтобы какой-то другой пользователь открыл плохой контент может быть сложновато.
Временные токены это и есть некоторый аналог cookies, но доступ на одну минуту кажется каким-то маленьким. В принципе наверное можно делать токены в урле на 5-10 минут, их нельзя будет похитить заставив пользоваеля открыть публичную ссылку на этом выделенном для пользовательского контента домене.
Временные токены это и есть некоторый аналог cookies, но доступ на одну минуту кажется каким-то маленьким. В принципе наверное можно делать токены в урле на 5-10 минут, их нельзя будет похитить заставив пользоваеля открыть публичную ссылку на этом выделенном для пользовательского контента домене.
Как лучше всего делать API для авторизации для мобильного/десктопного приложения? Открытие страницы в браузере не самый лучший вариант.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Результаты исследования методов аутентификации и некоторых механизмов защиты от WEB-атак на примере Google, VK и других