#черный_список

Недоволен пока что программой Яндекса. Отправили с другом пару репортов ещё месяц назад – ноль реакции. На повторные письма также ответа нет.

Если вдруг что-то изменится – напишу, а пока в ЧС. Не тратьте время.

Onmouse* XSS PoC

#техническое #советы #PoC

Про то, как я делаю PoC, буду еще писать в дальнейшем. Но с особой тщательностью я прорабатываю сценарии для уязвимостей, которым нужно user interaction.

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

Обычно я использую что-то вроде
{
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100%;
background-color: red;
opacity: 0.5;
}

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

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

Mindmaps

#советы #организация

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

Раньше у меня были проблемы с тем, чтобы не путаться, какие функции я уже исследовал, а какие только предстоит. Особенно когда в голову пришла очередная идея и ты бежишь пробовать ее на старых, уже исследованных компонентах. Тут всегда можно подумать: "Так, а на CSRF я эту функцию уже проверял?".

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

Структура получается примерно такая:

домен ➡️ раздел ➡️ функция ➡️ подфункция ➡️ определенная уязвимость

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

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

https://o1.su/tg_images/1.png

CSS-гаджеты

#техническое #советы

Пару постов назад я писал про мой способ увеличить импакт от XSS, завязанных на событиях мыши – через растягивание уязвимого элемента на максимальную площадь страницы с использованием стилей. Но что если атрибут style блокируется WAF, а уязвимый элемент находится в таком неочевидным месте, что есть шанс получить informative?

Например, какая-нибудь крошечная ссылка в подвале страницы вида
<a href=“INJECTION”>
оказалась уязвима и мы смогли превратить ее в
<a href=“” onclick=alert() a=“”>
но не можем сделать красивый PoC через атрибут style.

В данном случае, я использую так называемые (мной) CSS-гаджеты. Может кто-то ещё их и применяет, но я не слышал.

Суть такая, что можно «набрать» нужный стиль с использованием нативных стилей приложения. Например, неплохо бы добавить уязвимому элементу свойства width: 100% и top: 0.

Открываем инструменты разработчика на уязвимой странице и прочесываем все стили. Это удобно делать в Firefox, там они все собраны в одной вкладке.

Находим, например
.test {
display: block;
color: blue;
width: 100%;
}
и
#someid {
top: 0;
font-family: Tahoma;
}

Теперь можно модифицировать нашу ссылку и привести ее к виду
<a href=“” id=someid class=test onclick=alert() a=“”>

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

И даже если WAF совсем злой, и не получилось совсем выполнить JS, но инъекция в элемент все же есть, можно попробовать провернуть таким образом что-то типа дефейса. Если этот элемент важен для функционирования приложения – можно спрятать его, применив к нему класс со свойством display: none или вроде того.

Не бог весть что, но есть шанс на как минимум Availability Impact: Low.

​​Как все начиналось?

#истории

Со школы ещё я читал Хакер, когда была возможность его купить (он тогда ещё был бумажный, с диском, и стоит космических денег – чуть ли не 1000 рублей). Читал в основном ресерчи по взлому веба, понимал какие-то крохи.

Помню была статья, где на каком-то магазине, достаточно крупном, нашли SQLi прямо в форме логина. Я тогда сел за бабушкин компьютер и попытался воспроизвести все по шагам прямо на этом сайте. Я тогда не знал ничего про responsible disclosure, конечно.

Что самое смешное – бага так и не была закрыта, видимо про это не знал и автор статьи :)

Прошло несколько лет, и нам с коллегами на работе предложили сходить на PhDays за счёт компании. Мы на тот момент уже учились в МИФИ, как раз на факультете Информационной Безопасности. Но оффенсива у нас там практически не было, за каким-то очень маленьким исключением, а работали мы программистами.

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

Доклады я особо не запомнил, вроде было несколько интересных. А вот что я запомнил навсегда – это как парни из Qiwi рассказывали, что запустили баг баунти на H1. На тот момент это для меня было просто каким-то откровением. Что можно взламывать сайты легально и ещё и зарабатывать на этом.

Я шёл домой с твёрдой уверенностью заняться этим. Результаты можете видеть на скрине ниже :)

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

Low-hanging fruit

У меня тут спросили, могу ли я поделиться скриптами для поиска low-hanging fruit. Конечно, таких комментов будет много – поэтому пишу этот пост.

Low-hanging fruit (дословно – низко-висящие фрукты). Так принято называть баги, которые очень легко обнаружить. Я бы их разделил ещё на 2 типа:

1. Баги, которые не имеют толкового импакта. Например: отсутствие какого-нибудь заголовка безопасности, открытый редирект, content spoofing. Такие баги я не ищу и вам не советую.

Во-первых, вам за них никто не заплатит в 99% случаев. Во-вторых – поиск таких «багов» никак вас не развивает. Куда лучше потратить время на изучение хотя бы одной более серьёзной уязвимости и вы уже будете лучше многих других, кто умеет только шаблонно просматривать заголовки без понимания происходящего.

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

2. Нормальные баги с импактом, но которые находятся на супер-видном месте. Например: XSS в форме поиска на главной странице или IDOR в запросе смены пароля.

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

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

Чем глубже запрятана функция, чем она сложнее (и может даже скучнее) – тем меньше людей ее исследовало. Такие функции – ваш шанс найти уязвимость.

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

Рутина

#fulltime #минусы

Рутина – достаточно большая проблема bug bounty на фуллтайме (для меня).

Ну какая-то ее часть воспринимается нормально. Это написание отчётов, общение с компаниями, даже проверка фиксов. Это просто есть, это часть работы, без этого не получить денег. Иногда это даже бывает весело, особенно делать какие-нибудь хитрые PoC.

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

Это рутина двух видов. Либо когда сидишь ковыряешь приложение, и ничего не находится часами. Не за что даже зацепиться. Но это ещё не самое страшное, потому что я так размышляю: чем дольше я ничего не нахожу – тем ближе я к новому багу. Ведь я уже давно этим занимаюсь и всегда что-то да находится новое. Значит и сейчас найдётся (хотя все равно бывает иногда страшновато).

А вот второй вид такой мерзкой рутины – это наоборот, когда есть потенциальная уязвимость и ее надо раскручивать. А она никак не даётся. Ну, например, нужно обойти фильтр или WAF. И ты сидишь часами над ним, и думаешь: может надо остановиться, может его просто не обойти? Но останавливаться не хочется, ведь можно упустить баг (особенно если он потенциально дорогой).

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

Неочевидное об 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 часа в неделю примерно.

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