Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
Спасибо! Интересно!
Любопытно, благодарю.
Но у меня смутные сомнения — или я что-то пропустил, или изначальный подход к авторизации порочен.
Возьмем как это сделано в одном нашем проекте — токен авторизации получается методом вызываемым на стороне сервера партнера, который подписывается его секретным ключем. Сайт партнера сам передает данный код в браузер пользователя. Данный токен доступен только в окружении той страницы, и я право не вижу путей его утечки.
Да, у нас несколько другой функционал, и нам не нужно авторизовывать пользователя, это делает за нас партнер отражая это в данных при получении токена, но я не вижу принципиальной разницы. ИД партнера авторизуется закрытой серверной стороной, ИД пользователя через браузер, например куками.
Вроде как стандартная практика, нет?
Я давно не игрался с ВК.АПИ, я зарекся иметь с ними дело после того как они пару раз без предварительных предупреждений поменяли правила, и выкинули меня из клуба, потому что у меня нет приложения. (вроде как наличие приложения это фильтр базовых знаний, а то что приложение удалили по причине изменения правил ведь не должно отражаться на моих способностях, не?).
Но суть не в том. Я помню у них тоже были «секьюрные» методы, на которые они жирно писали, что исполнять их можно только на сервере чтобы не светить свои авторизации в браузер.
Повторюсь, что я могу ошибаться, но не понимаю ЗАЧЕМ? Приложения без браузера и сайта соответственно? Ну так опять таки, им не нужно знать мои авторизации или же они всё равно будут дергать мой АПИ, где всё равно можно делать действия на стороне сервера…
Что я не так понимаю?
Но у меня смутные сомнения — или я что-то пропустил, или изначальный подход к авторизации порочен.
Возьмем как это сделано в одном нашем проекте — токен авторизации получается методом вызываемым на стороне сервера партнера, который подписывается его секретным ключем. Сайт партнера сам передает данный код в браузер пользователя. Данный токен доступен только в окружении той страницы, и я право не вижу путей его утечки.
Да, у нас несколько другой функционал, и нам не нужно авторизовывать пользователя, это делает за нас партнер отражая это в данных при получении токена, но я не вижу принципиальной разницы. ИД партнера авторизуется закрытой серверной стороной, ИД пользователя через браузер, например куками.
Вроде как стандартная практика, нет?
Я давно не игрался с ВК.АПИ, я зарекся иметь с ними дело после того как они пару раз без предварительных предупреждений поменяли правила, и выкинули меня из клуба, потому что у меня нет приложения. (вроде как наличие приложения это фильтр базовых знаний, а то что приложение удалили по причине изменения правил ведь не должно отражаться на моих способностях, не?).
Но суть не в том. Я помню у них тоже были «секьюрные» методы, на которые они жирно писали, что исполнять их можно только на сервере чтобы не светить свои авторизации в браузер.
Повторюсь, что я могу ошибаться, но не понимаю ЗАЧЕМ? Приложения без браузера и сайта соответственно? Ну так опять таки, им не нужно знать мои авторизации или же они всё равно будут дергать мой АПИ, где всё равно можно делать действия на стороне сервера…
Что я не так понимаю?
«Но! Как я уже писал выше, если HTTP Refferer не передать совсем, то мы получим нормальный ответ. Я думаю, так было сделано по двум причинам:» – это сделано потому, что refferer не передается для https сайтов
Вопрос: вы три-четыре раза находили ошибки в исправленных уязвимостях. Вам все три раза оплачивали по $1500? Или только за самую последнюю? Что вообще пишут VK по поводу этих ошибок?
После последнего исправления.
Я так понимаю, эта выплата была сразу за всё :)
Я так понимаю, эта выплата была сразу за всё :)
Это не очень справедливо. По-хорошему за каждую демку должны были заплатить. Тем более уязвимость довольно серьезная.
По-хорошему за каждую демку должны были заплатить.
Согласен
Тем более уязвимость довольно серьезная.
Не согласен. Для полноценной эксплуатации этой уязвимости, надо заранее знать, каким приложениям пользователь дал разрешение на использование своей страницы. Конечно, можно протыкаться по списку самых популярных APP_ID, но не факт, что пользователь подписан на них.
Остается второй вариант — как-то следить за списками пользователей, которые подписаны на других сайтах, парсить и хранить эту информацию, чтобы потом, когда пользователь наконец зайдет на твой фишинговый сайт — произвести эксплуатацию…
Опять же, насколько я понял: личная переписка от этого не вскрывается, доступ к закрытым фоткам/документам не получается, максимум- можно от имени пользователя делать посты на стене пользователя, т.е. как вариант — можно насолить какому-нибудь конкуренту, если ты знаешь, что есть пользователи, которые подписаны на него.
Можно попробовать не собирать предварительно, а на момент входа проверить.
Если знать APP_ID приложения, которое на сайте используется, то можно своим пользователем залогиниться в это приложение, и вызвать метод VK API users.isAppUser, с параметром user_id, полученным из куков. Не знаю, правда, насколько быстро можно провернуть такую проверку.
Если знать APP_ID приложения, которое на сайте используется, то можно своим пользователем залогиниться в это приложение, и вызвать метод VK API users.isAppUser, с параметром user_id, полученным из куков. Не знаю, правда, насколько быстро можно провернуть такую проверку.
А на два мои репорта на Hackerone VK почти месяц не отвечают, до сих пор в статусе «New» — видимо, Ваш баг исправляли)
поле location объекта self можно просто накрыть объектом с полями href, hostname и др. Почему? Всё просто: объект location находится не в самом объекте self, а в его прототипе
Всегда интересно было, откуда у вебхакеров такие знания берутся? Чтобы стало «всё просто», надо код браузера Хром выучить?
Всё просто — хочешь найти пульт от телевизора — думай как пульт, или как минимум как телевизор.
Тщательное изучение исходников это полезно, но не всегда, и не достаточно.
Нужно понимать логику. Логику принятия решений, и тогда не нужно будет знать код.
Веб-разработчик который написал свой MVC-велосипед на полсотни классов, пару лет подерживал, после чего еще год мигрировал всё это на популярный фреймворк — очень быстро освоит любой фреймворк, и ему не нужно будет часто заглядывать в код фреймворка, чтобы понять что и как работает. Он это УЖЕ ДЕЛАЛ.
Помню одна большая контора слизала один в один мой сервис. Просто посмотрели на интерфейс и сделали такой же.
Так я рассказывал их пользователям об особенностях работы их сервиса (на их форуме) потому что мне было прекрасно понятно что и как они сделали. Также как и они половину нетривиальной логики поняли просто по интерфейсу. Часто когда есть опыт, то ты понимаешь почему сделали так а не иначе… Это в интерфейсе, особенно в хорошем делают сначала интерфейс, а потом думают как это реализовывать. В более технических вещах внутренности видны даже просто по описанию. Не все конечно. И при атаке особенно на удаленные вещи всё решает эксперимент. Но предположения берутся из опыта…
Тщательное изучение исходников это полезно, но не всегда, и не достаточно.
Нужно понимать логику. Логику принятия решений, и тогда не нужно будет знать код.
Веб-разработчик который написал свой MVC-велосипед на полсотни классов, пару лет подерживал, после чего еще год мигрировал всё это на популярный фреймворк — очень быстро освоит любой фреймворк, и ему не нужно будет часто заглядывать в код фреймворка, чтобы понять что и как работает. Он это УЖЕ ДЕЛАЛ.
Помню одна большая контора слизала один в один мой сервис. Просто посмотрели на интерфейс и сделали такой же.
Так я рассказывал их пользователям об особенностях работы их сервиса (на их форуме) потому что мне было прекрасно понятно что и как они сделали. Также как и они половину нетривиальной логики поняли просто по интерфейсу. Часто когда есть опыт, то ты понимаешь почему сделали так а не иначе… Это в интерфейсе, особенно в хорошем делают сначала интерфейс, а потом думают как это реализовывать. В более технических вещах внутренности видны даже просто по описанию. Не все конечно. И при атаке особенно на удаленные вещи всё решает эксперимент. Но предположения берутся из опыта…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CSRF-уязвимость VK Open Api, позволяющая получать Access Token’ы сторонних сайтов, использующих авторизацию через VK