Вы не могли бы подробнее рассказать, кто выполняет пейлоад из параметров запроса?
Пейлод сначала обрабатывается кодом, который уязвим к prototype pollution. В этот момент происходит собственно prototype pollution, следствием которого является изменение значения некоторых переменных. После этого в определенный момент код использует измененное значение переменных, которое приводит к XSS / RCE /…
В клиентском/серверном коде уже должен быть троян, который достанет строку из location.search и выполнит ее? Тогда непонятно зачем заморачиваться с прототипами, сразу alert можно.
Код, который обрабатывает значение из location.search может не приводить XSS, но приводить к prototype pollution. Если не учитывать prototype pollution в данном случае, то мы пропускаем уязвимость :)
Кстати, nikitastupin, вам тоже нужно платить за себя еще ФСС и ПФ, почему-то про это ни слова.
Все так, но за счет налогового вычета получается что плачу только 6% (по крайней мере в моем случае). Это как раз то о чем ты говоришь во втором абзаце.
1. Правильно ли я понимаю, что если заработать больше 300 тыс. в год, то к 6% также прибавится еще 1 процент?
Не совсем так, 1% это страховые взносы, которые можно вычесть из итогового налога. То есть сначала платишь страховые взносы (1%), а потом можешь платить налога меньше ровно на столько, сколько заплатил страховых взносов.
2. Инвойс подписывавае только исполнитель, то есть собственно самому ИП? Заказчик (Hackerone) ничего не подписывает и печати не ставит никуда?
Все верно, только исполнитель. В этом и прелесть :)
Сперва у меня была такая же цепочка рассуждений как и у тебя и она вполне логична, я даже спрашивал в поддержке как это работает (не помню что ответили). Но на практике оказалось, что деньги за обслуживание действительно не списывались за месяца, когда не было операций зачисления с HackerOne или вывода средств.
Хорошо использовать данный инструмент как дополнительный, но не заменять JSON.
Можешь рассказать, в каких случаях удобнее применять голый JSON? Мне очень интересно это узнать, потому что я с такими случаями не сталкивался и может быть что-то упустил.
Теперь стало намного понятнее
Конкретно эта фраза скорее шутка, потому что схему выше с первого взгляда трудно назвать легкой и понятной :)
Конечно же нет. Рекомендация про WebView направлена на то, чтобы максимально обезопасить пользователя и облегчить ему вход в приложение. Если у него есть сессия в браузере, то эта сессия сразу подхватится, соответственно никаких данных пользователь вводить не будет. В случае с WebView пользователю всегда придется вводить логин и пароль, следовательно повышается вероятность, что пользователь когда-то введет логин и пароль в зловредном приложении.
А зачем? Пользователь не должен (и вряд ли будет) искать глазами и разбираться что перед ним: WebView или Browser Custom Tab. Смысл использования Browser Custom Tab в том, что он безопаснее и может подхватить уже существующую сессию пользователя.
В этом сценарии легитимное приложение не участвует. Зловредное приложение регистрируется как обычный OAuth 2.0 клиент (например, у Google можно легко зарегистрировать свой OAuth 2.0 клиент через веб-интерфейс), может быть даже какое-то время работает в нормальном режиме и не приносит вреда, но при этом оно всегда имеет возможность прочитать логин и пароль пользователя, если тот авторизуется по OAuth 2.0 через WebView (WebView будет поднято в зловредном приложении, но с точки зрения SDK это обычный OAuth 2.0 клиент).
Злоумышленник перехватил code (одновременно с искажением state), и хочет получить access_token.
А в каком случае злоумышленник может перехватить code и исказить state, но при этом не может просто прервать запрос пользователя? Я вижу вариант, когда злоумышленник MitM-ит пользователя, но в этом случае он может и другими способами прервать запрос за access_token.
Т.е., условно говоря, юзер скачал где-то мобильное приложение, притворяющееся настоящим клиентом, запустил его, оно использовало client_id настоящего клиента для получения доступа. Немного напоминает «я бедный африканский хакер» в топике про вирусы под линух, ну да ладно. Но где в этой картине второй, настоящий клиент?
Да, все так. Настоящего клиента может и не быть, суть атаки именно в том, что зловред показывает чужой consent screen, а пользователь из-за невнимательности фишится. Вектор атаки не супер критичный, но все равно я думаю, что лучше его учесть и принять меры защиты.
«This specification is designed for use with HTTP ([RFC2616]). The use of OAuth over any protocol other than HTTP is out of scope.»
Это можно трактовать как «OAuth 2.0 должен использоваться только вместе с HTTP», так и как «OAuth 2.0 разрабатывался для HTTP, любые другие транспорты вы используете на свой страх и риск». Я больше склоняюсь ко второй. При использовании транспортов отличных от HTTP нужно учитывать уязвимости, которые транспорт привнесет вместе с собой, и тщательно проверять на безопасность. Называть получившийся после замены транспорта протокол OAuth-ом или не называть, на мой взгляд, уже холиварный вопрос.
На Android приложение может проверить какой браузер оно открывает и разрешать только браузеры из белого списка. В нашем OAuth 2.0 SDK для клиентов такая функция есть, я не указал ее в статье. На iOS кастомные браузеры все равно используют Safari, поэтому проблем с зловредными браузерами там нет.
В общем же случае, установленный зловредный браузер приводит к более серьезным проблемам, чем доступ к данным пользователя на одном сервисе. Таким браузером можно компрометировать аккаунты пользователя сразу нескольких веб-приложений.
Вообще, если говорить про легитимность приложений, то инструмент, дающий возможность на сервере отделить своих от чужих был бы очень кстати.
Если приложение-клиент использует OAuth 2.0 через приложение-провайдер, то такая проверка возможна. Если же приложение-клиент использует OAuth 2.0 через браузер, то там обычный HTTP запрос и зловред может его подделать, потому что секреты в мобильном приложении безопасно не зашить (их можно проснифать или разреверсить).
Поможет ли Attestation API в данном случае сходу сказать не могу, нужно читать, разбираться и пробовать. Но за ссылку спасибо, посмотрю.
Откуда возьмутся такие устройства, на которых реально нет возможности реализовать SHA-256, но при этом есть возможность запускать свои OAuth-клиенты?
Подобные устройства я не встречал и у меня возник точно такой же вопрос при чтении стандарта. Думаю, что в стандарте не просто так сделали примечание про устройства без поддержки SHA-256, поэтому и пишу про это в статье.
Еще раз подчеркну, что если SHA-256 поддерживается, то нельзя делать даунгрейд до отсутствия преобразования code_verifier. Это указано и в статье, и в RFC 7636.
Бывают атаки, которые намеренно искажают state отправляемый или получаемый легитимным клиентом (не уверен что мобильные, но для веб-клиентов я про такое читал) — делается это как раз для того, чтобы легитимный клиент остановился на этом этапе
Интересно, не знал про подобные атаки. А для чего злоумышленнику останавливать клиента на этом этапе?
Из описания не совсем понятен сценарий атаки, можете пояснить как конкретно это работает?
У пользователя установлены два приложения: легитимное и зловред. Происходит следующее:
Зловред поднимает consent screen легитимного приложения. Для этого зловреду достаточно передать client_id легитимного клиента.
Невнимательный пользователь может разрешить доступ к своим ресурсам и подумать, что дает доступ легитимному приложению (на consent screen ведь иконка и название легитимного приложения), а в действительности он предоставит доступ зловреду.
После этого зловред получит code, обменяет его на access_token и получит доступ к ресурсам пользователя.
А разве использование IPC вместо HTTP не подразумевает автоматически, что это уже вообще не OAuth и не Implicit Grant, а просто какой-то свой простейший RPC-протокол
На мой взгляд, IPC это всего лишь транспорт (способ доставки) access_token, который заменяет HTTP. Протокол OAuth 2.0 показан на примере транспорта HTTP, потому что он наиболее популярен в вебе. Если посмотреть на описание Implicit Grant, то видно, что там не сказано, что транспортом обязательно должен быть HTTP.
То что IPC из коробки может передать client_id и "redirect_uri" и по тому же соединению получить ответ — не делает его хуже HTTP.
При использованием новых транспортов самое главное — учесть все возможные проблемы безопасности, связанные с транспортом. Хороший пример — кейс с использованием postMessage в реализации OAuth 2.0. Подчеркну, что сам по себе postMessage не является плохим транспортом, но необходимо учитывать возможные проблемы безопасности, которые он привносит.
Ответ на первый вопрос. Приложение, которое подняло WebView, может получить доступ ко всем данным WebView, в том числе: логину/паролю, сессионным токенам пользователя. Если приложение легитимное и «доброе», то все хорошо. А вот если WebView поднимет зловред, то он легко может сфишить пользователя. Более подробно про этот и другие аргументы против WebView можно почитать в разделе «Хороший, плохой OAuth 2.0» этой статьи.
По второму вопросу. У приложения может быть серверная часть, но кому-то дешевле оставить взаимодействие с токенами на стороне мобильного приложения. Не нужны сервера для хранения токенов и обработки запросов, не нужна разработка и тестирование серверного кода, не нужно заботиться о безопасности такой инфраструктуры. Это не отменяет тех случаев, когда OAuth 2.0 клиенты получают, используют и хранят access_token на сервере, а не в мобильном приложении. Оба варианта возможны и какой вариант использовать — это по большей части выбор OAuth 2.0 клиента (при условии, что OAuth 2.0 провайдер безопасно реализовал оба варианта на своей стороне).
В этом кейсе бага была в браузере: он должен открывать Custom URI Scheme, но не делает этого. В таком случае нужно поступать как и со всеми багами — исправлять их. Всегда есть риск того, что на более низком уровене (браузер, операционная система, драйвера) будут баги или уязвимости, которые затронут работу приложения.
Другое дело, если найдется браузер, для которого не открыть Custom URI Scheme — ожидаемое поведение, и при этом он будет достаточно популярным. В таком случае нужно задуматься путях решения проблемы или об альтернативах Custom URI Scheme.
В приведенном тобой кейсе человек зарегистрировал за своим приложением схему «http», поэтому нет ничего удивительного, что некоторые браузеры не открывают такое приложение.
В статье же речь идет о кастомной схеме (например, mailrumail), которая браузеру неизвестна.
Я не сталкивался с ситуациями, когда браузеры полностью не поддерживают Custom URI Scheme. Если такие есть, можешь привести пример?
Код, который обрабатывает значение из
location.searchможет не приводить XSS, но приводить к prototype pollution. Если не учитывать prototype pollution в данном случае, то мы пропускаем уязвимость :)Все верно, только исполнитель. В этом и прелесть :)
Можешь рассказать, в каких случаях удобнее применять голый JSON? Мне очень интересно это узнать, потому что я с такими случаями не сталкивался и может быть что-то упустил.
Конкретно эта фраза скорее шутка, потому что схему выше с первого взгляда трудно назвать легкой и понятной :)
А в каком случае злоумышленник может перехватить
codeи исказитьstate, но при этом не может просто прервать запрос пользователя? Я вижу вариант, когда злоумышленник MitM-ит пользователя, но в этом случае он может и другими способами прервать запрос заaccess_token.Да, все так. Настоящего клиента может и не быть, суть атаки именно в том, что зловред показывает чужой consent screen, а пользователь из-за невнимательности фишится. Вектор атаки не супер критичный, но все равно я думаю, что лучше его учесть и принять меры защиты.
Это можно трактовать как «OAuth 2.0 должен использоваться только вместе с HTTP», так и как «OAuth 2.0 разрабатывался для HTTP, любые другие транспорты вы используете на свой страх и риск». Я больше склоняюсь ко второй. При использовании транспортов отличных от HTTP нужно учитывать уязвимости, которые транспорт привнесет вместе с собой, и тщательно проверять на безопасность. Называть получившийся после замены транспорта протокол OAuth-ом или не называть, на мой взгляд, уже холиварный вопрос.
В общем же случае, установленный зловредный браузер приводит к более серьезным проблемам, чем доступ к данным пользователя на одном сервисе. Таким браузером можно компрометировать аккаунты пользователя сразу нескольких веб-приложений.
Если приложение-клиент использует OAuth 2.0 через приложение-провайдер, то такая проверка возможна. Если же приложение-клиент использует OAuth 2.0 через браузер, то там обычный HTTP запрос и зловред может его подделать, потому что секреты в мобильном приложении безопасно не зашить (их можно проснифать или разреверсить).
Поможет ли Attestation API в данном случае сходу сказать не могу, нужно читать, разбираться и пробовать. Но за ссылку спасибо, посмотрю.
Подобные устройства я не встречал и у меня возник точно такой же вопрос при чтении стандарта. Думаю, что в стандарте не просто так сделали примечание про устройства без поддержки SHA-256, поэтому и пишу про это в статье.
Еще раз подчеркну, что если SHA-256 поддерживается, то нельзя делать даунгрейд до отсутствия преобразования
code_verifier. Это указано и в статье, и в RFC 7636.Интересно, не знал про подобные атаки. А для чего злоумышленнику останавливать клиента на этом этапе?
У пользователя установлены два приложения: легитимное и зловред. Происходит следующее:
client_idлегитимного клиента.code, обменяет его наaccess_tokenи получит доступ к ресурсам пользователя.На мой взгляд, IPC это всего лишь транспорт (способ доставки)
access_token, который заменяет HTTP. Протокол OAuth 2.0 показан на примере транспорта HTTP, потому что он наиболее популярен в вебе. Если посмотреть на описание Implicit Grant, то видно, что там не сказано, что транспортом обязательно должен быть HTTP.То что IPC из коробки может передать
client_idи"redirect_uri"и по тому же соединению получить ответ — не делает его хуже HTTP.При использованием новых транспортов самое главное — учесть все возможные проблемы безопасности, связанные с транспортом. Хороший пример — кейс с использованием postMessage в реализации OAuth 2.0. Подчеркну, что сам по себе postMessage не является плохим транспортом, но необходимо учитывать возможные проблемы безопасности, которые он привносит.
По второму вопросу. У приложения может быть серверная часть, но кому-то дешевле оставить взаимодействие с токенами на стороне мобильного приложения. Не нужны сервера для хранения токенов и обработки запросов, не нужна разработка и тестирование серверного кода, не нужно заботиться о безопасности такой инфраструктуры. Это не отменяет тех случаев, когда OAuth 2.0 клиенты получают, используют и хранят
access_tokenна сервере, а не в мобильном приложении. Оба варианта возможны и какой вариант использовать — это по большей части выбор OAuth 2.0 клиента (при условии, что OAuth 2.0 провайдер безопасно реализовал оба варианта на своей стороне).Другое дело, если найдется браузер, для которого не открыть Custom URI Scheme — ожидаемое поведение, и при этом он будет достаточно популярным. В таком случае нужно задуматься путях решения проблемы или об альтернативах Custom URI Scheme.
В статье же речь идет о кастомной схеме (например, mailrumail), которая браузеру неизвестна.
Я не сталкивался с ситуациями, когда браузеры полностью не поддерживают Custom URI Scheme. Если такие есть, можешь привести пример?