Автозаполнение паролей

Все знают, что включать автозаполнение паролей в браузере – не очень безопасно.

Но я уверен, что ты нет-нет, да и пользуешься этой удобной штукой, правда? Ну а что такого, ведь небезопасность здесь только теоретическая! Ведь для того, чтобы использовать твой предзаполненный пароль в корыстных целях, злоумышленнику нужно как минимум завладеть твоим устройством, а на нем еще и общий пароль установлен... В общем это все ерунда и не стоит волноваться.

Или все-таки нет?

Я и сам включаю автозаполнение, не буду скрывать. Но буду теперь внимательнее смотреть на то, как эта фича реализована в конкретном браузере. Потому что в Firefox, например, пароль автоматически вставляется в соответствующие поля. Не требуя ввода мастер-пароля (как в Safari), или хотя бы клика мышкой (как в Chrome). И не только при логине, а еще и на странице настроек. Ну знаешь, там, где нужно ввести старый пароль, чтобы сменить его на новый.

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

Позволю себе тебя перебить. А как думаешь, что будет, если на этом сайте есть вредоносный JS, внедренный через XSS? А будет вот что – этот JS сможет легко прочитать твой предзаполненный пароль и отправить его к атакующему вместе со всеми другими твоими данными 🙂

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

На bugbounty.ru:

Во-первых, уже доступна регистрация для всех желающих.

И во-вторых, запустилась первая платная программа – Сбермаркет. Выплаты не сильно высокие, но в целом привычные для российских программ.

Помимо нее, также у них открыта бесплатная программа некоммерческого движения "Мой Полк". Насколько я знаю, социально-значимые проекты у них имеют возможность хоститься бесплатно, что достойно уважения. А если бы еще вознаграждали, допустим, мерчем, за критичные баги в них – было бы вообще хорошо. И это наверняка бы сильно повысило количество заинтересованных исследователей.

P.S.: есть инфа, что мерч будет)

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

Например, еще не так давно Safari не умел в CSP Strict-Dynamic, чем можно было иногда воспользоваться при сдаче XSS в багбаунти.

Когда у меня есть сомнения в распространенности какой-то защитной технологии, я всегда иду на caniuse.com.

Из интересного:

- на данный момент никто, кроме IE, не поддерживает
X-Frame-Options: ALLOW FROM, при этом некоторые сайты его по каким-то причинам используют, соответственно, можно залутать немножко денежек, зарепортив им clickjacking;

- Trusted Types поддерживают только Edge, Chrome и Opera, так что этой технологии еще не судьба победить XSS;

- когда-то давно было решено отказаться от встроенных в браузеры санитайзеров (X-XSS-Protection), так как от них было больше головной боли, чем пользы. Но отказались не все. Вот Safari все еще поддерживает этот заголовок, а к чему это может привести – расскажу в другой раз 🙂

Хорошая новость!

Есть подтверждение, что Google VRP до сих пор проводит платежи в несанкционные банки, например, Tinkoff. По крайней мере эта информация актуальна на сегодняшний день, знакомый сегодня получил выплату.

Тинькофф запустил бб на bugbounty.ru:

https://bugbounty.ru/home/programs/tinkoff

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

https://medium.com/@skavans_/how-i-stopped-hunting-on-hackerone-after-years-because-they-stole-my-50k-and-so-should-you-7328b8af30f1

Я же говорил, что зря недооценивают кликджекинг 🙂

https://medium.com/metamask/metamask-awards-bug-bounty-for-clickjacking-vulnerability-9f53618e3c3a

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

Дальше пользователь должен был сделать 3 (или 2?) клика по как будто бы безопасным элементам на сайте, а на самом деле при этом нажимал кнопки прозрачного кошелька. Таким образом он мог, например, непреднамеренно отправить всю свою крипту злоумышленникам.

Ну и ресерчеры получили за этот баг баунти в $120.000 :)

Видео с объяснением и PoC:
https://youtu.be/HnI0w156rtw

Кстати, а вы знали, что у WB тоже есть своя BugBounty программа ?

В скоуп входит:
- Основной сайт
- Портал для продавцов

Почти год назад начал сдавать баги, в течение двух месяцев сдал около 40-50 багов.
Из них 20+ штук все еще на проверке (второй yandex?😁)

Суммы выплат относительно неплохие (если отталкиваться от РФ программ).

Ну и раз такая пьянка – еще self-hosted российские ББ:

СКБ Контур – https://kontur.ru/bugbounty

Мамба – https://corp.mamba.ru/ru/developer/security

JIVO – https://www.jivo.ru/bugbounty/

Ну а вот тут вообще целая куча self-hosted (не только РФ), правда сейчас нужно каждую отдельно проверять – платит или нет.

Плюс вообще не все платные, надо смотреть, есть ли атрибут bounty.

https://raw.githubusercontent.com/projectdiscovery/public-bugbounty-programs/master/chaos-bugbounty-list.json

Есть web-интерфейс:
https://chaos.projectdiscovery.io/

Обязательно вступайте в наш чат, там можно задавать любые вопросы (в рамках тематики канала) и, что самое главное – получать ответы:

💬 https://news.1rj.ru/str/+zlEZJnR5o7kxN2Ey

Я не знаю, актуально ли нам, но на всякий случай скину.

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

Я все пытался найти это видео, в результате подсказали. Тут Frans Rosen рассказывает, как он искал баги с айфона.

Плюс, в комментах к этому посту скинули несколько мобильных аналогов Burp Suite. Мало ли, кому-то будет полезно.

https://youtu.be/oHYC1-CgrRk?t=243

LOOK IN COMMENTS, there are tools!

For those who has no laptop.
Frans Rosen is telling how he used his iPhone to search for bugs.

It was a long time ago but I think it's possbile now too.

Also, if you find some intercepting proxy tool for your smartphone – you'll be able to do almost the same as we're doing using a laptop.

If anybody know some tools like this, please refer them in comments – it would be way helpful for many people.

Непонятное: CSP, SOP, CORS

#техническое #матчасть

У меня тут спрашивают, что из них лучше и полезнее в нашем багбаунти деле. В честь юбилейного 949-го подписчика делаю пост-ответ для новичков.

Самое главное: нужно понимать, что хотя эти аббревиатуры звучат похоже, они вообще про разное, хотя 2 из них все-таки связаны.

Обычно, когда такие вопросы возникают – нужно просто идти в гугл и читать. Но окей, let me google this for you, как говорится.

CSP – Content Security Policy или Политика Безопасности Содержимого

Вкратце: это заголовок ответа сервера, в котором он определяет правила безопасности содержимого на данной странице, которым должен следовать браузер. Туда входят правила из разряда:
- скриптам с каких доменов разрешено исполняться на этой странице (noscript-src);
- каким доменам разрешено встраивать эту страницу в iframe (frame-ancestors);
- разрешено ли использование base-тегов (base-uri).

Подробнее: https://developer.mozilla.org/ru/docs/Web/HTTP/CSP

Когда оно нам нужно: если какая-то атака (обычно XSS или Clickjacking) не работает там, где должна – надо смотреть CSP-заголовок и изучать эти самые правила, чтобы понять, не в них ли причина.

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

Есть классный сервис проверки безопасности CSP от гугла – https://csp-evaluator.withgoogle.com. Тут можно проверить, есть ли шанс обойти CSP или ловить нечего.

SOP – Same Origin Policy или Политика Одного Источника

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

То есть скрипт, находящийся на сайте https://google.com никак не получит данные пользователя с сайта https://yandex.ru. И даже не пройдут запросы с https://yandex.ru на http://yandex.ru, так как все три составных части origin должны быть одинаковыми, чтобы браузер разрешил такой доступ.

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

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

Подробнее: https://developer.mozilla.org/ru/docs/Web/Security/Same-origin_policy

Когда оно нам нужно: только когда мы еще не понимаем этот базовый принцип и пытаемся делать вещи, которые в 2022 году просто невозможны. А так один раз запомнили – и навсегда.

CORS – Cross-Origin Resource Sharing или Межсайтовое Разделение Ресурсов

Вкратце: это механизм, который позволяет легально обойти SOP. Иногда (часто) все-таки нужна возможность отправлять запросы с одного origin на другой. Для этого придумали CORS. Владелец сайта, данные с которого должны быть доступны для других сайтов, должен отправлять вместе с ответом разрешающие заголовки типа
Access-Control-Allow-Origin: https://google.com

В случае выше, запрос с сайта https://google.com сможет получить данные с такого сайта. Ну и там не все так примитивно, конечно.

Подробнее: https://developer.mozilla.org/ru/docs/Web/HTTP/CORS

Когда оно нам нужно: для поиска уязвимостей типа CORS misconfiguration. Иногда (опять же часто) список origin, которым разрешено получать данные с целевого сайта на фиксирован, а, допустим определен с помощью маски.

Например, владелец хочет, чтобы любой домен гугла мог бы прочитать данные с его сайта. И он пишет код, который смотрит на origin, который делает запрос, и если этот origin соответствует *.google.* – разрешает доступ. Периодически бывает, что этот код написан криво и мы можем также запросить эти данные, допустим, с вредоносного домена google.hacker.ru.

Если кто-то изнемогает от желания поддержать канал, но не знает, как – выбирайте 🙂

💳 https://boosty.to/skavans

🪙 ETH, BNB, MATIC
0x1a90F6ABDD2D29bD7A9b8FE099ff8c7dd0961519

🪙 BTC
bc1q9uq96lfekq7ec6slhw72k6kvxntzfk9a4un3vs
🪙 TRX THeRubKK1cNzVRD9JTTQYR7ApK8wCao8Fm
🪙 LTC ltc1q9k2lhuzfg7k482qkcswgqmn0vwsp32suf7yvr3
🪙 BCH bitcoincash:qqypg65vd2cmy54kevdu0ae4jp0229xddycx3xgsg5

интересные предложения "работы" приходят иногда в личку :D

Рамазан @r0hack поделился на своем канале.

Интервью само-по-себе достаточно интересное, советую послушать 🙂

НО, что реально ценного я оттуда вынес – это узнал про платформу code4rena.com.

Если вам интересно попробовать себя в поиске уязвимостей в смарт-контрактах – имхо, это лучший вариант для старта. Объясняю, почему:

1) Эта платформа коллективного аудита смарт-контрактов, туда часто попадают еще слабо (или вообще не) аудированные смарт-контракты. Соответственно, высок шанс найти даже примитивные баги.

2) Платят за дубликаты, что опять же огромный плюс. Суть такая, что есть некий фиксированный баунти-пул, который сначала делится на все баги (согласно их критичности), а в рамках одного бага – на всех, кто его нашел.

3) Никакого KYC в большинстве случаев, а значит, welcome Russian researchers.

4) Доступны более или менее подробные протоколы прошлых аудитов: https://code4rena.com/reports. Это как открытые отчеты на H1 – также очень круто, можно учиться на чужих находках.

Крутое интервью от Егора и Никиты - BugBounty глазами исследователя.

https://music.yandex.ru/album/22592369/track/105695635