Неочевидное об XSS и HTML-энкодинге

#техническое #xss

Многие знают о том, что перед тем, как получить значение атрибута тега, браузер декодирует HTML-сущности внутри. Скажем, если попытаться прочитать свойство test у такого тега:
<tag test="&amp;">
то мы получим декодированное значение: "&".

На этом построены некоторые обходы простых XSS-фильтров.

Допустим, если нужно внедрить javanoscript-ссылку, а javanoscript: блокируется WAF, то можно попробовать сделать так:
<a href="javanoscript&colon;alert()">
Когда браузер будет читать href этой ссылки, он декодирует значение, и получится как раз javanoscript:alert(). Такая ссылка обойдет фильтр (если он никудышный), но будет рабочей.

Работают не только именованные сущности, но и числовые в разных видах. То есть можно делать атрибуты вида javanoscript:
61 – это "a" в шестнадцатеричной форме, 97 – в десятичной. Их можно комбинировать и ссылка все равно будет рабочей.

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

А вот что для меня оказалось неочевидным.

Часто для предотвращения XSS приложение кодирует инпут в HTML-сущности. Ну, скажем, заменяет вашу кавычку на ". Вы все это видели.

Представим, что на странице есть тег с ивент-хендлером, а внутри него отражается параметр INJ:
<button onclick="someFunction('test', 'INJ')">
и если мы пробуем вставить кавычку в этот параметр – она также кодируется в HTML-сущность, и получается
<button onclick="someFunction('test', '&amp;')">

Выглядит безопасно, не так ли?

Вот только вернитесь назад и прочитайте пару абзацев повыше. Браузер декодирует эти сущности. И на самом деле тут написано:
<button onclick="someFunction('test', ''')">
То есть на самом-то деле у нас тут XSS, так как мы разорвали контекст строки!

Более того. Допустим, разработчики приложения умные и не стали так делать. А решили закодировать эту кавычку в "%27". Тогда, наверное, все пропало, и тег неуязвим?

Я бы не спешил так думать и попробовал передать в параметр саму HTML-сущность:
INJ=&

Продумали ли они такой вариант, или такое значение никак не будет экранировано и мы снова получим XSS в виде
<button onclick="someFunction('test', '&amp;')">
– это вопрос, которым я бы озадачился 🙂

Стоит ли переходить на фуллтайм?

#фуллтайм

В комментариях меня спросили, что в результате оказалось выгоднее по деньгам – моя предыдущая работа разработчиком или fulltime bugbounty? Отвечаю.

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

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

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

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

У меня первый звоночек прозвенел ещё очень давно. Я тогда зарабатывал намного меньше, как-то нашёл 3 бага по $2500 буквально за несколько часов и понял, что это моя зарплата за полгода. С того момента я стал засекать время и вот в результате понял, что для меня баг-хантинг будет выгоднее.

Но самое главное – мне нравилось этим заниматься. И это очень важно! Потому что если вы решите уволиться и заняться этим на фуллтайме – у вас уже не будет фиксированной зарплаты, придется постоянно работать, а это тяжело, если не приносит удовольствия.

Сколько зарабатывают на Bug Bounty

#деньги

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

Согласно ей, к 2019 году:
⁃ на платформе было зарегистрировано более 1 млн исследователей;
⁃ более 9000 из них заработали хотя бы что-то;
⁃ более 200 человек заработали более $100 000;
⁃ 9 человек заработали более $1 млн.

Также я знаю, что сейчас уже есть как минимум 1 человек, который заработал более $2 млн.

Хочется отдельно отметить Сергея Тошина (bagipro) из Москвы, он стал одним из тех, кто смог заработать более $1 млн на H1. Помимо того, что мне просто приятно, что он из России, я хочу отметить его необычный подход к поиску уязвимостей.

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

Что касается меня, мои доходы за 3 года фуллтайм-работы составили:
⁃ $91 тыс за 2019 год;
⁃ $229 тыс за 2020 год;
⁃ $252 тыс за 2021 год.

И суммарно, за все время моей работы, мне удалось заработать $588 тыс.

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

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

Если у кого-нибудь есть аккаунт на Medium – большая просьба подписаться на меня
https://medium.com/@skavans_

Я хочу попробовать там монетизировать посты с канала, нужно набрать 100 подписчиков. Пока набралась только половина :)

​​К чему может привести инъекция в jQuery-селектор

#техническое #think_different

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

Небольшое отступление

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

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

Также по поводу тем: я пишу о том, о чем я хочу. Если интересно – я вам рад. Если нет – также всегда можно пройти на выход.

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

Кнопку с донатом я буду постить может быть после каждого поста, либо раз в неделю. Если кого-то это оскорбляет – до свидания.

Сегодня моей дочке исполнился годик и она уже тоже нашла пару уязвимостей!

Нужно ли уметь программировать?

Дисклеймер: говорим про исследование только веб-приложений.

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

1. Recon-уязвимости
Сюда я отнесу все, что не требует непосредственного взаимодействия с приложением. Например, вы можете найти ssh-ключ от сервера компании в коммите на гитхабе. Или, скажем, просканировать порты сервера и найти там какой-то сервис старой версии с публично-известным эксплоитом. Сюда же можно отнести и угон поддомена или открытую для всех админку без пароля на company.com/admin.

Нужно ли тут программирование? Нет.

А что нужно? Тут нужно обладать широким кругозором в computer science, скажем так. То есть понимать, как работает веб, что такое HTTP, порты, DNS, GIT, SSH-ключи и прочее. Неплохо бы также разобраться, как использовать специализированный софт, например сканеры портов и поддоменов.

Может ли программирование оказаться полезным? Да, конечно. Поиск таких уязвимостей можно автоматизировать, например. Для этих целей я бы выбрал какой-то интерпретируемый язык, например python (сам я использую именно его).

2. Логические баги приложения
Например, вы обнаружили, что при покупке какого-то товара на сервер вместе с его ID уходит также и цена, которую вы видите в приложении. И оказалось, что если эту цену передать другую, то и покупка будет совершена по более низкой стоимости.

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

Может быть тут нужно программирование? Ну вообще-то нет.

А что нужно? В первую очередь нужно понимать, как клиент с сервером обменивается данными по HTTP и освоить любой перехватчик HTTP/WebSocket запросов. Признанный лидер тут – Burp Suite. Есть и другие, но когда я их тестировал (давно) – они все уступали.

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

Может ли тут программирование оказаться полезным? Вряд ли. Тут чистая логика и работа с запросами от клиента к серверу.

3. Атаки на клиент
XSS, CSRF, CSS-exfiltration, clickjacking, JS-hijacking, что-то ещё наверняка забыл.

Нужно тут знать программирование? Как минимум немножко знать придётся. Нужно понимать и уметь читать HTML и JS. Для более сложных видов XSS, например DOM-XSS, придётся знать JS достаточно хорошо.

Что ещё нужно? Нужно понимать, как работает браузер. Это самое главное. Понимать, что такое SOP, CORS, CSP. Знать, какие бывают заголовки безопасности и на что они влияют. Как работают cookie и что такое SameSite policy, как ее можно обойти.

4. Атаки на сервер
SQLi и другие инъекции, SSRF, race condition, и все в таком роде.

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

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

Итак, мой топ по нужным навыкам:

1. Не-программирование, а computer science. Как работает веб, браузер, протоколы. Нужно везде.

2. HTML + JS. Для атак на клиент.

3. Python или другой простой интерпретируемый язык. Для автоматизации и понимания концепций серверного программирования.

4. Другие серверные языки. Изучение их специфик и особенностей для поиска сложных уникальных багов.

​​Кратко о налогах

Я уже 5 лет зарегистрирован как ИП с основной деятельностью "Консультационные услуги в сфере IT".

В H1 можно настроить выплаты прямым банковским переводом через Swift. Пользуюсь именно этим способом, он гораздо выгоднее, чем PayPal.

Для того, чтобы принимать платежи, необходимо пройти валютный контроль в банке. Пока общая сумма поступлений не превышает 3 млн рублей – все элементарно. По крайней мере прогрессивным банкам достаточно примерно такого пакета документов:
- скрин письма о регистрации на H1 (только для первого платежа);
- оферта H1, распечатанная и подписанная (только для первого платежа);
- скрин из личного кабинета с суммой выплаты.

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

За прохождение валютного контроля банк берет небольшую комиссию.

У меня счет в банке Тинькофф, я сравнивал разные банки, неоднократно, и он оказался самым выгодным (пока что). Хотя в нем есть свои бесящие моменты, не без этого.

Моя налоговая система – УСН Доходы. Это значит, что с каждого входящего платежа я должен заплатить 6% налога.

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

Если есть еще вопросы – задавайте в комментах.

Дополню.

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

По поводу комиссии. Для России на H1 доступен единственный способ вывода через Swift – Priority Payment, обычный, неприоритетный, платёж недоступен.

Соотвественно, взимается комиссия. Сам H1 взимает 7 долларов с каждой выплаты. Для меня (H1 -> Tinkoff) промежуточные банки также снимают 20 долларов с каждого платежа. Для других банков эта сумма, вероятно, может отличаться – не знаю.

Итого в моем случае на счёт приходит на 27 долларов меньше с каждой транзакции.

Да, еще важный момент: сумма одной транзакции не может превышать $10000. Если ваш баланс на дату выплаты больше – она произойдёт несколькими транзакциями, с каждой будет удержано $27.

И, соответсвенно, отмечу, что если, вы нашли 1 дешевый баг (за 100 долларов, например), то лучше в настройках выплат H1 ставить ежемесячные выплаты, а не ежедневные. Так вы сможете за месяц скопить сумму побольше и заплатить комиссию один раз со всей этой суммы. При ежедневных маленьких выплатах же придётся платить комиссию с каждой небольшой транзакции.

​​Мой график работы

#fulltime #организация

Согласно отчету H1 за 2020 год:
⁃ 37% ресерчеров тратят на баг-хантинг от 1 до 9 часов в неделю;
⁃ 25% – от 10 до 19 часов;
⁃ 14% – от 20 до 29 часов;
⁃ 8% – 30 до 39 часов;
⁃ и 16% – больше 40 часов.

Когда я еще работал в офисе – я занимался этим бессистемно, по несколько часов в неделю, когда было время и желание. До работы, или после нее. Больше ради интереса, чем надеясь что-то заработать.

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

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

Но после нескольких дней такой работы иногда желание заниматься этим дальше может пропасть на 2-3 недели. У меня такое было еще в офисе, когда сдавали проект и приходилось иногда даже не спать ночами. Потом, бывало, подташнивало от работы весь следующей месяц 🙂

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

Поэтому я решил, что мне нужно искусственно ограничивать себя графиком. Пробовал разные варианты: работать 5 дней по 8 часов (чтобы как в офисе), каждый день по 3 часа без выходных, какие-то еще. Всегда это приводило либо к потере желания, либо к тому, что я не мог стабильно выдерживать этот график неделями и месяцами.

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

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

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

Ну и теперь я еще веду этот канал в свободное время, на это уходит еще 2-3 часа в неделю примерно.

Если кто-то еще хантит фуллтайм – расскажите, какой график у вас, будет интересно)

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

Сегодня мне должна улететь копеечка с H1 на Тинькофф. Напишу, все ли пройдет. В случае чего, будем думать над альтернативами.

Ну что ж, пока все печально. Выплата не ушла, осталась висеть на балансе. Причину не знаю, написал в поддержку – пока без ответа.

Добавил пересказ на русском в 2 словах