Если у кого-нибудь есть аккаунт на 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 словах

Пока что предлагаю прорабатывать список платформ или отдельных программ, с которыми можно будет работать в случае конца H1 для нас.

Есть Яндекс, само собой. У них вообще своя собственная ББ, без партнёрства с какими-то платформами. Сейчас вот получил инсайд от человека оттуда, что они не собираются прекращать работу.

Есть Mail.Ru. С ними непонятно, какой сейчас канал связи. Написал им просто в техподдержку. Если будет ответ – сообщу. Если у кого-то есть контакты в мейле – будет здорово, если вы сможете их подергать, чтобы узнать.

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

Также нужно узнавать по Китаю. Тоже постараюсь.

Буду держать всех в курсе. Присоединяйтесь, кто хочет, к моим изысканиям)

Ушла выплата. Надеюсь, дойдет.