Мы — заботимся о безопасности пользователей. Но к сожалению, или к счастью, мы — это совершенно другая команда, которая занимается информационной безопасностью наших проектов и точно так-же как и вы переживает и страдает в войне дистрибуции между компаниями.
Давайте обсудим прямо тут :) Хотя лучше бы в тикете
Судя по вашему репорту, а начинается он так: «Берем любой сервис где существует авторизация через соц. кнопку ищем xss в любой форме»,
Ваш вектор выглядит так:
1) Находим XSS на сервисе, где установлена кнопка авторизации при помощи Mail.Ru
2) Авторизуем пользователя на этом сайте при помощи кнопки авторизации и найденной XSS
3) Крадём куки уязвимого сервиса.
Вопрос, как это аффектит нас или наших пользователей?) Если я не прав, и у вас есть PoC — то велкам в тикет на HackerOne :)
Стараемся Егор)
Разбирал тут недавно твою багу с FB Oauth redirect_uri, и пытался проэксплуатировать пару приложений.
Правильно ли я понимаю, что все популярные прилады уже пофиксились в настройках?
Мы верим в то, что братские народы — это временное явление)
А H1 нам понравился за то, что ребята берут на себя все обязательства перед security researcher-ами касаемые сроков и методов оплаты, принимают баги в удобной для нас и репортеров форме + исповедуют правильную, на наш взгляд, философию.
Я просто сам принимал участие в такого рода программах, и поэтому не хочу заставлять репортеров мучиться с почтовой перепиской, отсылать сканы паспортов, СНИЛС-ы и ждать оплаты по полгода :)
Спасибо за репорт! У нас сейчас вал репортов от братских народов(индусов и китайцев) :) Мы обязательно ответим на ваш репорт в течении 1-2 дней. В будущем, постараемся отвечать в течении нескольких часов.
Если мы не закрыли уязвимость в течении трёх месяцев — да, это ваше право. Но в этом случае награды не будет :( Мы всегда просим учитывать тот факт, что не все уязвимости в рамках большой компании можно закрыть за этот срок. Например, если уязвимость касается взаимодействия десятков подразделений, то срок исправления может доходить и до полугода.
В случае если мы закрыли уязвимость и видим что в её раскрытии нет ничего плохого, то три месяца ждать не имеет смысла. И дальше вы впринципе в любое время можете надавить кнопку «Раскрыть уязвимость» и она опубликуется на hackerone автоматически.
Вы правы. Но программа в первую очередь нацелена на повышение безопасности наших продуктов и пользователей, а социальная инженерия — это уже ближе к безопасности самой компании, её сотрудников и ей заняты совершенно другие люди. То же самое с физической безопасностью.
Да, безусловно, по итогам месяца мы обязательно расскажем об этом, с примерами и историями :)
Более того, по нашим правилам и правилам HackerOne, после того как баг был закрыт, по истечении 2-3 месяцев его можно «открыть в мир», и кто угодно может рассказать о нём, затвитить, зашарить и т.п.
Тохочка, секурити апдейты для стабильных версий никто не отменял ) Так что старая != уязвимая, а == стабильная как минимум.
PFS мы ещё не умеем, действительно, но ИМХО это не та фича ради которой стоит сломя голову бежать обновляться.
У нас не возникало нужды переходить на TLS 1.2, можешь считать что стабильность — это наше всё.
В ближайшее время, безусловно, проапгрейдимся, если новых багов не найдут)
Единая сессия, всегда ведёт к большим проблемам в безопасностью, поэтому что это самый очевидный, самый лёгкий, но самый небезопасный путь. И большинство компаний начинают именно с единой сессии.
Как пример уязвимостей доступных к эсплуатации с единой сессией:
1) XSS на проекте a.domain.com, ведёт к компрометации b.domain.com. Хотя на b.domain.com — багов не было.
2) Кража кук в открытой сети на проекте a.domain.com(который не умеет https) ведёт к компрометации b.domain.com(который умеет и любит HTTPS). Потому что невозможно выставить Secure флаг для авторизационных cookie — a.domain.com работать перестанет.
и т.п.
Судя по вашему репорту, а начинается он так: «Берем любой сервис где существует авторизация через соц. кнопку ищем xss в любой форме»,
Ваш вектор выглядит так:
1) Находим XSS на сервисе, где установлена кнопка авторизации при помощи Mail.Ru
2) Авторизуем пользователя на этом сайте при помощи кнопки авторизации и найденной XSS
3) Крадём куки уязвимого сервиса.
Вопрос, как это аффектит нас или наших пользователей?) Если я не прав, и у вас есть PoC — то велкам в тикет на HackerOne :)
Разбирал тут недавно твою багу с FB Oauth redirect_uri, и пытался проэксплуатировать пару приложений.
Правильно ли я понимаю, что все популярные прилады уже пофиксились в настройках?
А H1 нам понравился за то, что ребята берут на себя все обязательства перед security researcher-ами касаемые сроков и методов оплаты, принимают баги в удобной для нас и репортеров форме + исповедуют правильную, на наш взгляд, философию.
Я просто сам принимал участие в такого рода программах, и поэтому не хочу заставлять репортеров мучиться с почтовой перепиской, отсылать сканы паспортов, СНИЛС-ы и ждать оплаты по полгода :)
В случае если мы закрыли уязвимость и видим что в её раскрытии нет ничего плохого, то три месяца ждать не имеет смысла. И дальше вы впринципе в любое время можете надавить кнопку «Раскрыть уязвимость» и она опубликуется на hackerone автоматически.
У вас сколько полезных репортов в день от них?
Более того, по нашим правилам и правилам HackerOne, после того как баг был закрыт, по истечении 2-3 месяцев его можно «открыть в мир», и кто угодно может рассказать о нём, затвитить, зашарить и т.п.
PFS мы ещё не умеем, действительно, но ИМХО это не та фича ради которой стоит сломя голову бежать обновляться.
В ближайшее время, безусловно, проапгрейдимся, если новых багов не найдут)
В чём же наш позорный недуг?
Как пример уязвимостей доступных к эсплуатации с единой сессией:
1) XSS на проекте a.domain.com, ведёт к компрометации b.domain.com. Хотя на b.domain.com — багов не было.
2) Кража кук в открытой сети на проекте a.domain.com(который не умеет https) ведёт к компрометации b.domain.com(который умеет и любит HTTPS). Потому что невозможно выставить Secure флаг для авторизационных cookie — a.domain.com работать перестанет.
и т.п.
Всё что найдём нашего на других сервисах или в паблике — конечно проверим.