Яндекс Баунти или ключ за миллион бесплатно⁠⁠

Смотри а то ещё и иск получишь за разглашение вне рамок проекта) (хз, на сколько это мама-ама криминал, но Яндекс, думаю, обидеться)

Вообще красава 👍🏼👍🏼 А Яндекс не перестаёт расстраивать.

Я тут пока писал у меня шрифт в приложении для iOS поменялся сам. Это баг? Кому сообщить?)

Уже не работает, но работает кое-что другое, яндекс самый продуманный, как они думают) а то что показал ТС - не работает, пока ты не переступишь закон.

На хабр, срочно))) раз бабло зажали, пущай разхлебывают

Тс: зайду ка я на Хабр годовалой давности.

О, давно известная бага Яндекса.

Ооооо, дайте денях, о денях не дали, Пикабу помоги

https://m.habr.com/ru/post/476754/

У этого поста уже 5600+ плюсов.
Куча людей поставили плюсики только потому что в прошлом у них был неприятный опыт с яндекс.такси/Яндекс.едой/... Вместо того, чтобы попытаться разобраться в ситуации куча людей направила свои диваны в священный поход против злобного Яндекса. Это печально.

Яндекс с этим ключом может влететь на бОльшие расходы, чем зажал автору.

Откуда возьмутся эти расходы?

Ключ используют все пользователи яндекс еды +- пара сотен тысяч запросов (между яндекс едой и большим яндексом) они даже не заметят.

Можно зайти на любой сайт, где используется геолокация, и найти ключ.

Что уникального конкретно в твоём?

Можешь попробовать заюзать ключик частной компаниии, которой продаёт Яндекс, у тебя не получится.

Еще раз, им нахуй не нужно это минимизировать,  мелких пользователей они не почувствуют, а большие купят.

Об этом баге мне было известно года 3 назад, но почему то фирма отстегивает по 3 ляма в год за свой ключик, а не юзает общий, почему же? Может потому, что большой потребителя будет видно сразу и на него мгновенно подадут в суд? А с открытым ключом даже проще, можно у себя его на апи шифровать, но это уже вкусовщина, тут эникеи на jwt геосервер пересадить пытались.

ну мб потому что не нужно брать пример с яндекса и в открытую выкладывать свой ключ на сайт?

какой клиент теряет средства то будет пояснение?

по вашей логике теряет тут только яндекс. давая типа бесплатный доступ к апи. что является осознанным решением и давно известно. чужой ключ, не являющийся частью приложений яндекса, ты никак не украдешь

Разве такая реализация, по-умолчанию не подразумевает в себе уязвимость, когда дело касается платной услуги

Сама себе возможность использовать данное API уязвимостью не является.

Проблема появляется только когда кто-то необдуманно пустил в открытый доступ свой токен. Это стандартная ситуация для статических токенов.

Именно клиент решает допустимо ли для его продукта использовать токен на стороне браузера или это таки нужно делать на бекенде.

То что для некоторых клиентов данный подход может не подойти - ограничение, а не уязвимость самой API.

На примере яндекса: они решили использовать токен открыто в яндекс.еда, чем создали для себя потенциальный фрод, но их это устраивает.

И в который раз: какое это отношение данная бреш имеет к описанной программе bug bounty? Вы же топик создали о том, что вам коварно не заплатили, а не просто описание уязвимости.

Чел, вот скажи, ты адекватный? Почитай пожалуйста что такое http\https, что такое POST, GET etc. Что такое заголовки в запросе. Как отправка запросов во фронтенде используя fetch, asios.

Ограничения на Ip будут работать ТОЛЬКО в случае запросов с СЕРВЕРА, а не с клиента. Ограничения доменов лишь запретят cors (а именно другой пользователь не сможет сделать запрос ИЗ БРАУЗЕРА с другого домена), пользователю ничего не мешает сделать запрос, передав необходимый реферер со своего СЕРВЕРА\ПРОКСИ.

В двух словах, это не является багом\проблемой, такова техническая реализация.
Недополученной прибыли тут быть не может, потому что компания, под которую зарегистрировано юр. лицо\ип НЕ БУДЕТ использовать чужой апикей в открытом виде, иначе последуют судебные разбирательства.

Вопрос защиты апи кея лежит на клиенте и никак иначе. Они предоставляют сервис, а далее клиент уже решает, как он будет его использовать, как он будет ограничивать доступ для клиентов.

И ещё раз, данный "баг", коим ты его считаешь, никак не является хоть чуть критичным, да и багом то не является.

Слабо себе представляю малый бизнес который сможет заработать на этом, если это не какой-нибудь стартап который хочет продаться крупной конторе, но стартап может просто написать письмо в яндекс и получить демо-ключ.

Да и вероятно для того чтобы использовать ключ по максимуму необходим ещё и доступ в какой-нибудь личный кабинет.

ТС говорил о 3-х месяцах, вы используете этот ключ 3 года?

Малый бизнес который тратит время и деньги на вещи не приносящие прибыли обычно быстро закрывается. Так вот, угадывание примерного адреса клиентов зашедших со смартфонов денег не приносит.

Или у вас опять-же есть противоположный опыт?

Хорошо, не будет домыслов. Можно вернуться в мой самый первый коммент к этому посту, где я процитировал ответ поддержки из поста.

В нём они явно говорят, что они в курсе.

а чем платные карты отличаются от бесплатной версии?

Но данная уязвимость не относится к перечисленным в bug bounty программе
#comment_180780534

@moderator может ссылку добавить в пост? Это действительно доказывает, что проблема известная

А я, пройдя по пути автора, не смог подключиться... 403 выдало. Самара, Ростелеком, частный абонент. Аж обидно стало)))

Все верно, всегда можно заявить - ты не первый, так что идинах. О чем собственно и была самая первая отмазка.

я так понимаю, если ты пишешь высоконагруженный сайт с гуглокартой, то можешь воспользоваться данным ключом, и не будешь платить гуглу.

то есть неопасно, просто гугл недополучит прибыли.

почему яндекс использует гуглокарты, если у него есть свои карты - тоже вопрос.

Данными методами можно всего лишь снизить фрод.

К тому же в описании этой проблемы на хабре(в статье годичной давности) писали, что у них для биллинга этой API дополнительно работает система анти-фрода.

Это же очевидно, что статические API токены в публичном доступе дадут другим возможность им пользоваться. Не могут те кто внедряют у себя использование яндекс API этого не знать, т.к. базовые понятия.

Что с эти делать решает уже сам клиент.
У него может быть закрытая система и это будет совершенно не важно.
Может быть использование этого API только с бекенда.

Вот яндексу видимо не важно, что другие могут использовать их ключ, т.к. мало кто сглупит использовать это в коммерческом продукте.

Это не значит, что у них всё сделано правильно. Использование статического API token на стороне браузера явно не лучшее решение.

Но это вообще не относиться к OWASP уязвимостям, к чему эти попытки натянуть сову на глобус?

Перечитал всё с начала, чтобы убедиться, что ничего не упускаю. Новое для них было, что они не ограничили ключ по домену, верно?

Я согласен, что новую информацию вы им дали. Но о проблеме, которая создаётся этим, они знали, согласно переписке, что подтверждается ссылкой на хабр.

Иными словами, эта новая информация не является новым багом, поэтому их решение вполне логично. Ну а поддержка у них хреново отработала в некоторых моментах.

Не надоело? Вам уже только ленивый не объяснял, что фильтрация по referer не гарантирует ничего.
Это для использования в закрытом от юзера окружении, а не когда токен на стороне браузера.

Яндекс даже в доке по данному API указывает, что если используете на бекенде, то указывайте сами требуемый referer. Что помешает другим сделать также?

Это становится похоже на брутфорс.

уже в другой ветке ответили #comment_180841566

Но Security Misconfiguration тоже не подходит, т.к. это о конфигурации окружения, и к тому, что яндекс не прячут свой токен не имеет отношения.

Был прецедент у меня. Жертва Я.Диск, достаточно экзотическая xss, хранимка. Есть оф.ответ что попал в программу, все ок, жди денег, шампанского, женщин и проч. В итоге - зал славы онли. Забил. Больше в программу Яши ни-ни.

Попробую уточнить, Яндекс до этого репорта не знали, что они используют корпоративный ключ в Яндекс еде? Или они не знали значение этого корпоративного ключа?

Мне кажется, что это вряд ли.

Так что было новым для них?

Не хочу ходить по кругу. Ответь плиз на один вопрос - что >>>нового<<< ты сообщил Яндексу об этой проблеме, за что тебе должны дать денег?

Хороший репорт содержит четкое описание проблемы, аккуратную классификацию, POC (proof of concept, рабочий пример эксплуатации уязвимости). Указание сразу четырех больших категорий сразу вызывает серьезные сомнения.

Из указанных категорий, 2 и 5 отпадают сразу, так как токен работает как положено. Если бы скажем API принимал любые случайные токены - тогда да. Но здесь есть честно выписанный токен, дающий доступ туда куда должен.

Security Misconfiguration - может быть, если бы это был результат ошибки. Мне, с моей колокольни, здесь видится решение by design (что уже исключает выплату премии за нахождение). Да, токен лежит в открытом виде. Но так и предполагается, это common practice. Нет ограничений по IP и доменам? Нам это доподлинно неизвестно. Что точно известно - есть ст. 272 УК РФ, что делает нелегальное использование токена рискованным занятием. Ну и стандартные компенсационные меры типа мониторинга использования, черных списков, или даже просто регулярного перевыпуска токена.

Хороший репорт содержит четкое описание проблемы, аккуратную классификацию, POC (proof of concept, рабочий пример эксплуатации уязвимости). Указание сразу четырех больших категорий сразу вызывает серьезные сомнения.

Из указанных категорий, 2 и 5 отпадают сразу, так как токен работает как положено. Если бы скажем API принимал любые случайные токены - тогда да. Но здесь есть честно выписанный токен, дающий доступ туда куда должен.

Security Misconfiguration - может быть, если бы это был результат ошибки. Мне, с моей колокольни, здесь видится решение by design (что уже исключает выплату премии за нахождение). Да, токен лежит в открытом виде. Но так и предполагается, это common practice. Нет ограничений по IP и доменам? Нам это доподлинно неизвестно. Что точно известно - есть ст. 272 УК РФ, что делает нелегальное использование токена рискованным занятием. Ну и стандартные компенсационные меры типа мониторинга использования, черных списков, или даже просто регулярного перевыпуска токена.

Всё ещё не вижу, как это противоречит моему комментарию и сказанному поддержкой Яндекса.

имхо, тут скорее или непонимание базы, или просто желание срубить рейтинга за счёт людей, которые не в теме и не хотят разбираться.

>Непонятно только почему автор причисляет найденное к инъекциям.

Жажда наживы.

На странице bug bounty у них описано какие бреши нужно искать в веб-сервисах:

Классификация уязвимости по OWASP Top-10

A01. Инъекции
A02. Межсайтовый скриптинг – A05. Межсайтовая подделка запросов
A06. Ошибки конфигурации веб-окружения – A10. Открытое перенаправление

Непонятно только почему автор причисляет найденное к инъекциям.
OWASP же довольно понятно всё описывает, даже с примерами.

эм, вчера я явно видел в посте ссылку на maps.google.com

то есть, либо пост отредактировали, либо моя болезнь прогрессирует

Так они и говорят, что отсутствие лимитов им известно и не считают это особой проблемой, платить за это не будут

К сожалению использование http referer или ограничения по ip-адресам не решает эту проблему. А так ок.

Жесть. Подобный контент на Пикабу. Если бы можно было дать миллион минусов ТСу я бы их дал. Серьезно? Багу на Пикабу? Не просто багу а плакаться что не дали бабла! Мать его серьезно? Обычная рядовая ситуация и ее на Пикабу? Есть вроде как профильные ресурсы, не?

какие данные? результаты геокодирования? я и так могу зарегать 50 бесплатных ключей и получить эти же данные.

касательно счетов за вызовы апи - попробуйте сделать 10-20 тысяч запросов по этому ключу и вам все станет ясно. Вас просто заблочат и все

Но ведь найденная уязвимость действительно находится в другой категории.. Но диваны уже повернуты

Это действительно не совсем уязвимость относительно багбаунти. Про использование таких ключей есть статьи на Хабре с примерами

Автор конечно странный чувак, типа нашел уязвимость, которая только по его мнению является таковой, и хотя это не затрагивает личные данные и вообще работу сервиса, катит бочку на Яндекс, и в открытый доступ выкладывает (да, он и так в доступе, но все же) на Пикабу, хотя это считается не этично.

Вот только, если почитать условия по первой же ссылке из поста, станет понятно, что нифига это не уязвимость целевая. Яндекс этим конкурсом ищет утечки или способы поломки сервиса. А то, что вы ключ, который итак в открытом виде лежит, сперли. Ну. Его не особо и прятали.

ТС, как пентестер с 15 летним опытом готов абсолютно ответственно заявить, что открытый ключ не имеет ни малейшего отношения к owasp a1

Так это и не баг. Я ещё понимаю, если бы Яндекс багом это не признал, а после пофиксил это дело, но нет, они открыто заявляют, что проблема известна, просто в bug bounty не входит. Более того, Яндекс пошёл навстречу, даже в зал славы добавил (!), а вы выждали три месяца -- и на пикабушечке постик запилили, где какашками их забрасываете. Фу таким быть

А где в своих ответах Яндекс менял позицию? Не совсем понял этого утверждения. По-моему вам сразу сказали, что проблема использования чужих ключей есть, в том числе и ихнего, и они об этом прекрасно знают. Но это специфика запросов на стороне клиента и защититься от этого технически невозможно.

В их же условиях указано, что используется 2010, но в диалоге их сотрудник уточнил, что 2019

хоть это и странно немного, но совершенно не важно.

Top 10 список он на то и топ 10. вы сначала должны классифицировать уязвимость вообще. а они бывают от самых опасных до самых безобидных.

потом понять, входит ли она в топ 10. потом понять, входит ли эта топ 10 уязвимость в оплачиваемый список. а не сразу сидеть и думать, куда бы впихнуть свою находку из таблички с бабками. про инъекцию в принципе смешно, хоть бы почитали что это такое

В их же условиях указано, что "В качестве классификации уязвимостей для веб-сервисов используется OWASP Top-10 версии 2010 года, для мобильных приложений — OWASP Mobile Top-10.", поэтому мною была попытка классификации уязвимости по этой классификации, ибо условиями не указано иное, но в диалоге их сотрудник уточнил, что мою уязвимость они классифицировали по "OWASP API Security Top 10 2019".

не нужно даже ничего самому классифицировать :)

Они в своей bug bounty ссылаются на конкретные классификаторы уязвимостей из OWASP.

И как именно вы предполагаете защищаться от подобного? Запрос (как уже написали выше) делается из браузера пользователя, т.е. с абсолютно произвольного IP - ограничения нельзя выставить по определению. Делать прокси или ещё какие-либо подобные приседание нет никакого смысла (т.к. "хакер" просто будет лезть к прокси, вместо сервиса и получит точно тот же результат). Подозреваю что со стороны сервиса выставлены лимиты на количество обращений с IP, и в целом этого более чем достаточно.

Вобщем, Яндекс абсолютно правильно поступил, ибо в данном случае это не уязвимость.

> Так geocodeKey используется в JS API на стороне браузера, защитить его от попадания в браузер технически невозможно. Проблема использования этого geocodeKey сторонним сервисами нам уже была известна. В связи с этим, к сожалению, мы не можем присудить за нее вознаграждение.

Имхо вполне корректный ответ. Они сознательно сделали такую реализацию, это не неожиданное использование. Предлагаемые способы решения не сработают.

А может вам пост написать, такой, общепопулистический, на тему багбаунти? Чувствуется, что вы в теме, а послушать интересно было бы. Как в эту сферу деятельности попадают, какие подводные камни, хобби или работа, какие-нибудь забавные случаи и всё такое.

Автор, простите великодушно, но вы не владеете терминологией. Инъекция это конкретный тип атаки, не имеющий ничего общего с описываемой вами проблемой.

Автор, здесь действительно нет значимых проблем безопасности. Ограничивать токен по IP или referer бессмысленно, поскольку список клиентов примерно бесконечен, а в referer пишут все что угодно. Думаю, что на стороне Яндекса стоит монитор используемых доменов, и всё чужое просто вносится в черный список.

Судя по приведенным ссылкам на инъекции, например, вы не совсем понимаете, о чем пишете. Советую внимательно прочитать документы, на которые ссылаетесь, и поискать в сети примеры.

И как же клиенты яндекса пострадали? Жаба задушила, что api оплатили?

Не, ну автор предлагает яндексу невозможный вариант защиты: по ip ограничивать нельзя - оно ж на клиенте работает, по рефереру - ничего не даст, подменить можно. Вариант видится только во введении одноразовых ключей.

ТС пытается отомстить ))

Знаете, это явно не стоит того, как например sql иньекция . Прям вот стоит оно того?

Эм, там помнится надо очень много запросов для того, что бы бабки начали требовать, не помню такого, что бы была необходимость.

Сам помню баловался одно время.

Впрочем, уверен что у вас 100500 возражений будет. 

Спасибо, пост пробежал тезисно. А в чём тогда проблема. Яндекс еда не сделала ограничение?

Кстати, там же запрос с фронтенда идёт, т.е. с устройства пользователя. Т.е. по IP не ограничишь, по домену если, он разве передаётся в запросе к API ? Да и ответ же идёт напрямую пользователю?

Каким образом они это пофиксят когда страницу Еды может открыть любой желающий и в итогде запрос из браузера будет выполняться с произвольного IP адреса (вашего)?

@moderator, да как же вы заебали. «К посту есть вопросы»? Какие нахуй вопросы, если это буквально опровержение всех претензий

А в посте вы предлагаете почему-то

То что у них есть такие фильтры не значит, что их можно бездумно использовать. Они прекрасно будут работать на стороне закрытых систем, а не на стороне юзера.

Просто это не единственное, что требует внимание разработчиков. Видимо есть более приоритетные задачи.

Проверил я спецификацию OWASP версии 2010.

https://owasp.org/www-pdf-archive/OWASP_Top_10_-_2010.pdf

Что должно было измениться? Там также чётко описано что такое "A1 Injection".

A1 Injection - это древнейший тип уязвимостей и он никогда не относился к подобному.

Про IP и Referer вам здесь уже много раз объясняли, что это решение нерабочее от слова "совсем".
Вы или не понимаете как это работает, или просто тролите, раз такое предлагаете.