ААА ну ненадо было столько текста я же пьяный;
> кстати предполагаете вы, Егор не говорил что уязвимость в OAuth, описывается уязвимость в OmniAuth
кстати этот егор это я. не буду отвечать на каждый из тезисов просто вкратце распишу свои.
1; Oauth grant_type = code — web based — Очевидно. А любое web based lолжно защищаться от csrf это тоже очевидно. В основоном на редиректах реализации протокола защита должна быть встроена. Иначе ее тупо не будет. Insecure -by-default means insecure уже не раз это показывал )
2. вы опять таки недоконца поняли суть современных авторизационных систем/
есть МАСТЕР аккаунт на сайте pinterest.com есть FB аккаунт. Если бы был только ФБ логин то никаких проблем по логине в хакерский ФБ небыло бы, тк сидеть из под чужого акка не есть проблема. Но сейчас большинство(ну или много) работают по схеме МАСТЕР-СОЦИАЛ КОНЕКШЕНЫ.
Задача хакера — прикрепить свой СОЦ КОНЕКШН к МАСТЕРу на сайте. после прикрепления он заходит через свой ФБ сразу в МАСТЕР юзера.
2. и это не только уязвимость в omniauth. но и в огромном количестве других имплементаций включая самодельные(что и советуется в ОП посте)
КАЖДАЯ деталь web based протокола должна быть продумана с точки зрения web based аттак. Оставлять это на откуп разработчика неправильно. исходя из этого это остается уязвимостью в oauth. пусть и зачастую потенциальной(если сайт не работает по схеме МАСТЕР-СОЦИАЛКИ а работает на основе самих социалок)
так это отлично. response_type = token это очень плохо. reveal токена это худшее то может стать с ресурсом. это хуже xss8 grant_type = code самый лучший вариант и всем рекомендую его использовать
то что он не всеми поддерживатся это фейл, нужно плевать в тех кто не поддерживат. Тьфу вк!
>Статичный на 100% коллбэк — многим известная дыра в OAuth
лол что, какая тут дыра, наоборот отличная защита.
ах, если вы про state то читайте другие мои комменты там даже есть видос, я предпочитаю его использование. csrf token в редирект_ури это прошлый век.
зачем размещать на моем сайте? много кто разрешает размещать картинки или ссылки, но тем не менее что мешает разместиь на funnypictures.com/addr.html и подкинуть «жертве». очень легко.
после проведения атаки производится disconnect from facebook — вообще никаких отпечатков.
>А заключительный шаг обмена кода на access токен вообще не даст вашему приложению ничего, потому что токен максимум что — выдан для чужого приложения, маскирующегося под ваше, а стандарт требует на последнем этапе проверки client'а тоже.
я все знаю. я не получаю access_token -он хранится на сервере. я вообще не трогаю oauth ресурсы жертвы. OAuth Callback Forgery
чтож а как насчет разных параметров(у ya.ru статичный redirect_uri, у вк redirect_uri для получения токена не нужен)
а это вообще зачем?)
grant_type=authorization_code
клево вы затеяли
да, давно пора уже перестать «перестраховываться»
> кстати предполагаете вы, Егор не говорил что уязвимость в OAuth, описывается уязвимость в OmniAuth
кстати этот егор это я. не буду отвечать на каждый из тезисов просто вкратце распишу свои.
1; Oauth grant_type = code — web based — Очевидно. А любое web based lолжно защищаться от csrf это тоже очевидно. В основоном на редиректах реализации протокола защита должна быть встроена. Иначе ее тупо не будет. Insecure -by-default means insecure уже не раз это показывал )
2. вы опять таки недоконца поняли суть современных авторизационных систем/
есть МАСТЕР аккаунт на сайте pinterest.com есть FB аккаунт. Если бы был только ФБ логин то никаких проблем по логине в хакерский ФБ небыло бы, тк сидеть из под чужого акка не есть проблема. Но сейчас большинство(ну или много) работают по схеме МАСТЕР-СОЦИАЛ КОНЕКШЕНЫ.
Задача хакера — прикрепить свой СОЦ КОНЕКШН к МАСТЕРу на сайте. после прикрепления он заходит через свой ФБ сразу в МАСТЕР юзера.
2. и это не только уязвимость в omniauth. но и в огромном количестве других имплементаций включая самодельные(что и советуется в ОП посте)
КАЖДАЯ деталь web based протокола должна быть продумана с точки зрения web based аттак. Оставлять это на откуп разработчика неправильно. исходя из этого это остается уязвимостью в oauth. пусть и зачастую потенциальной(если сайт не работает по схеме МАСТЕР-СОЦИАЛКИ а работает на основе самих социалок)
то что он не всеми поддерживатся это фейл, нужно плевать в тех кто не поддерживат. Тьфу вк!
лол что, какая тут дыра, наоборот отличная защита.
ах, если вы про state то читайте другие мои комменты там даже есть видос, я предпочитаю его использование. csrf token в редирект_ури это прошлый век.
после проведения атаки производится disconnect from facebook — вообще никаких отпечатков.
>А заключительный шаг обмена кода на access токен вообще не даст вашему приложению ничего, потому что токен максимум что — выдан для чужого приложения, маскирующегося под ваше, а стандарт требует на последнем этапе проверки client'а тоже.
я все знаю. я не получаю access_token -он хранится на сервере. я вообще не трогаю oauth ресурсы жертвы. OAuth Callback Forgery
а это вообще зачем?)
grant_type=authorization_code