Я уже как-то писал свои соображения на тему того, как может выглядеть путь развития программиста. С тех пор прошло больше трех лет, и несмотря на то, что статья не потеряла актуальности я решил ее немного дополнить описанием альтернативной ветки развития, которая тоже про IT, но немного про другое IT. Не то, к которому привык среднестатистический смузихлеб из коворкинга писатель кода руками. Поговорим про путь разработчика в безопасность, а в частности про offensive security. Заварите себе чего-нибудь ядреного и погнали.
Как видите, мы за Вами давненько наблюдаем, мистер Андерсон. Оказывается, Вы живёте двойной жизнью. В одной жизни Вы — Томас Андерсон, программист в одной крупной уважаемой компании. У Вас есть медицинская страховка, Вы платите налоги и ещё — помогаете консьержке выносить мусор. Другая Ваша жизнь — в компьютерах, и тут Вы известны как хакер Нео. Вы виновны практически во всех известных компьютерных преступлениях.
Я также решил много заморочиться и позадавать вопросы разработчикам, которые перешли в безопасность, про их мотивацию к этому шагу. Поэтому по ходу статьи буду приводить цитаты из их ответов. Вот такое вот серьезное исследование вышло 🤣
Зачем это вообще все нужно?
Если у вас нет никаких сомнений в том, чем вы занимаетесь, если писать обработчики для кнопок это то о чем вы мечтали всю жизнь - просто пройдите мимо. Вы не целевая аудитория этой статьи и просто потратите зря ваше ценное время, а могли бы написать очередной onClickListener или обработчик POST запроса ;) Для остальных немного расскажу чем может быть интересна ветка развития в offensive security специалиста, и чем эта область знаний так привлекательна.
Смысл №1: стать лучше как разработчик 💪
Уязвимости в программах появляются не только из-за невнимательности или спешки. Часто это банальная некомпетентность или полное отсутствие фокуса внимания разработчика на аспектах безопасности системы. Строго говоря - его никто не посвящал в эти вопросы. В университете вбивали в мозги алгоритмы, “паскаль” и программирование “на бумажке”. На позиции джуна надо было вообще понять что происходит и вникнуть в туеву хучу вещей касающихся разрабатываемой системы и “структуру предприятия”. Став мидлом он изучал библиотеки, фреймворки и пытался уложиться в дедлайны. Ну а на позиции сеньора уже вроде как и можно бы изучить какие-то аспекты, и что-то вероятно уже изучено, но как-то уже так задолбало это все, что хочется играть в Xbox и пить пиво на конференциях. Конечно это некое усредненное описание ситуации и у всех по-разному, но мой опыт наблюдения за разработчиками приводит меня именно к таким выводам. От этого и будем разматывать данный пункт.
Основная проблема почти любого разработчика - непонимание, как слабость системы может превратиться в атаку. Да, есть банальные вещи типа SQL injection, про которые большинству все понятно, но вот как несколько аномалий системы можно собрать в полноценную атаку на систему, понимают уже не так много разрабочтиков. А получить это понимание можно только на практике. А для этого нужно нечто большее чем читать раздел “security” в ваших любимых фреймворках.
Зато получив такое понимание, вы однозначно становитесь на голову выше тех разрабочтиков, которые об этом не думают. И помимо того, что вы начинаете делать свою работу гораздо более качественно, у вас появляются дополнительные возможности, о которых мы поговорим чуть позже.
Опыт в разработке делает тебя сильнее как ИБшника, опыт ИБшника делает тебя более качественным разработчиком.
Металл куёт металл. Это взаиморелевантный опыт, который делает тебя более ценным специалистом. На некоторых особенных проектах и/или особенных ролях от тех кто в них вовлечён требуется одинаково высокий уровень скилла как в разработке, так и в ИБ. И таких людей рынок в большом количестве предложить не может.
Смысл №2: найти применение всем(!) своим знаниям 🤔
В среде IT-специалистов модно говорить такие слова как “T-shape”. Все его усиленно качают, расширяют кругозор, ну и вообще стараются чтобы от них побыстрее от2.7бались и начали платить больше денег =) Но реальность такова, что ты приходишь на работу, открываешь свою любимую IDE, а там опять надо писать обработчики POST запросов и красить очередную кнопку в очередном очень нужном всем сервисе… Да-да, таковы правила игры. “Экзамен” сдан, ЗП повысили и на приобретенные навыки можно смело забить, потому что применять их негде. И зачем тогда были эти все изучения внутренностей БД и других не связанных с основной работой штук.
И вот тут внезапно появляется история с безопасностью, которая сама по себе является огромной, а многообразие систем, которые могут встретиться на пути - почти неисчерпаемым. Даже несмотря на унификацию к которой так или иначе тяготеют разработчики - каждая система уникальна и содержит свои “скелеты в шкафу”. Имя этим скелетам - компромиссы возникающие на разных этапах разработки. Именно они в конечном итоге приводят к появлению уязвимостей. Выше я писал, что часть проблем безопасности появляется из-за некомпетентности команды. Так вот, слабые разработчики это тоже компромисс. Потому что сильные разрабочтики стоят дорого ;)
Выходит, что offensive security способно неплохо так раскрыть потенциал такого “T-shaped” разработчика подкидывая ему каждый раз задачи, требующие применения очень многих скилов полученных в ходе прокачки “соседних” веток навыков. Back-end разработчикам изучающим серверные уязвимости совершенно точно будет полезно залезть в мобильное приложение и посмотреть дополнительные эндпоинты API, которых может не быть в web версии. Мобильным же разрабочтикам придется постичь нюансы работы серверов и баз данных. Ну а писатели Front-end-а наконец-то осознают, что бывает, когда фильтрация значений осуществляется только на их стороне ;)
Информационная безопасность - это очень инженерная и техническая работа, а разработка в последнее время становится такой значительно меньше.
Последнее десятилетие разработка прошла долгий путь от “работы для ботанов” до “работы для того у кого есть пальцы и глаза”. Хаос упорядочивается. Вырабатываются лучшие практики для большинства задач. Сфера не стоит на месте, постоянно двигается вперёд, общий объём накопленных знаний в ней растёт, но вот потребность в применении аналитического мышления в типовой работе среднего разработчика падает. Нужно больше знать, но вот думать теперь можно меньше. Стало значительно меньше челенджа, личного вызова. То что 10 лет назад было сложной технической задачей, для решения которой требовалось незаурядное умение хорошо продумывать архитектуру, многое писать с чистого листа, сейчас решается подключением библиотеки и одной строчки кода.
Смысл №3: заработать немного денег 💸
Тут недавно придумали такую забаву - ищешь уязвимости в системах крупных компаний, рассказываешь их appsec-ам про них, а тебе платят деньги. Здорово, правда? :D
Ну а если без шуток, то история под названием bugbounty (далее BB) существует уже какое-то продолжительное время и это отличный способ инвестиции своего свободного времени и знаний. Намерено не буду тут приводить ни одну из имеющихся платформ. Раздел не про них, а про суть явления. BB для разработчика это отличный способ расширить кругозор и посмотреть как делать не надо. Или наоборот увидеть какие-то практики, которые потом захочется применить у себя. Поэтому независимо от результата поиска багов вы остаетесь в плюсе. Или по деньгам или по знаниям. А иногда в двойном плюсе когда удается чему-то научиться, да еще и заработать. Почему это классная точка приложения усилий? Да потому что кому как не разработчикам знать как выглядят программы “изнутри”. А это понимание очень сильно помогает именно на BB, которое в 99% случаев является анализом по принципу “черного ящика”. Знание технологий, фреймворков, а также умение быстро работать с документацией к ним, дает неплохой прирост в скорости анализа. Вам не нужно изучать отладочные флаги или структуру директорий того фреймворка на котором вы обычно работаете. Встретили на BB такой же? Круто! Вы уже знаете куда смотреть и что тут может быть не так. А пресловутое “умение разбираться в чужом коде” сразу же ставит вас на одну ступеньку выше типичных скрипт-кидди, кто сидит и пихает кавычку или <svg/onload=alert(1)><svg> в надежде на лучшее.
Выплатами заманивать не стану, они очень разные в российском сегменте. Но если повезло, то за один баг вы можете получить несколько своих месячных зарплат ;)
Чтобы стать багхантером, достаточно уметь запускать пару утилит и тыкать кавычки во все инпуты. Чтобы быть хорошим багхантером, нужно понимать принципы работы приложений, понимать стек технологий, как они взаимодействуют, понимать работу сетей, протоколов, DNS и т.д. Без этих знаний багхантер будет искать только поверхностные проблемы и не сможет понять критичность некоторых своих находок, а значит не сможет увеличить импакт проблемы и получить более высокое вознаграждение. Ведь большинство уязвимостей - это особенности и недостатки языков программирования, фреймворков и библиотек. Опыт разработки как раз дает такие знания, что несомненно послужит важным подспорьем для работы в Bug bounty. Если идти в обратном направлении, когда человек приходит в BB без этих знаний, я почти уверен, что большинство баг хантеров со временем, так или иначе, изучают все вышеописанное, потому что это знания, без которых не обойтись в их специальности.
Смысл №4: побег от рутины 🥳
Безопасность это настолько отличная от разработки область знаний, что некоторые сумасшедшие вроде меня могут воспринимать ее как неплохое хобби =) Это совершенно другое сообщество и другая атмосфера на коференциях. Если не верите, то посетите как-нибудь Positive Hack Days, Offzone или Zero Nights. А потом сравните это с типичной конференцией для разработчиков (тактично умолчу про названия :D). В большинстве случаев, доклады указанных выше конферецний смотрятся потом в записи. Почему? Да потому что есть огромное количество крутых активностей и потребности сидеть на стуле в зале нет никакой. Открывали когда-нибудь замок отмычкой на конфе для разработчиков? А наручники? Или может паяли дополнительные модули для бейджика, который представляет собой плату на контероллере STM32? То-то же!
А может вам нравится разрабатывать инструменты для автоматизации своей работы, но вам разрешают писать только CI/CD пайплайны? =) Тогда вам точно сюда. Хороших, качественных инструментов написанных людьми знакомыми с архитектурой и хорошими практиками кодирования, много не бывает.
В информационной безопасности более крутое сообщество.
Это конечно ИМХО, и многое зависит от обстоятельств, но как будто бы в среднем в ИБ с этим лучше чем в среднем в разработке. Здесь по прежнему всё ещё важно личное мастерство, как в разработке 10 лет назад. Нужны широкие базовые знания, технический кругозор. Случайных людей с улицы сюда не заносит и тут каждый коллега - очень интересный, увлечённый, штучный, специалист, зачастую с уникальными знаниями и опытом, которые он может привнести в свою команду. Людей меньше, все друг друга знают через максимум одно-два рукопожатия. Плюс есть сообщества по интересам, типа чатика андроид гардс у мобильщиков, всякие форумы вроде кодебай для вебщиков. Люди там часто знакомятся и что-то спрашивают, делают вместе, общаются, а потом выясняется что ты собеседуешься у того с кем уже немного заочно знаком. ИБ - это когда ты устраиваешься на работу, и видишь в рабочих чатиках знакомые имена и никнеймы
С чего начать? 🚀
Самый простой способ старта в offsec - начать с той же области знаний, в которой вы занимаетесь разработкой. Пишете фронт на JS - ваши первые найденные баги будут XSS, CSRF, CORS misconfig, CSWSH. Перкладываете json-ы из базы и обратно - SQL injection, SSRF, XXE это то, что вам будет очень понятно почти сразу. Ну а мобильным разработчикам придется посмотреть на экспортированные компоненты и понять какую опасность представляют из себя deeplink-ки без должной обработки.
Короч суть в том, чтобы начать искать уязвимости в привычной для себя среде и не прыгать выше головы. По мере появления опыта можно смотреть соседние области знаний и находить уязвимости уже на границах смежных областей. Например использовать серверные уязвимости, чтобы проэксплуатировать что-то в мобильном приложении.
Остается главный вопрос: а где тренироваться то? И у меня есть на него хороший ответ в виде пары ресурсов, которые помогут сделать первые шаги:
- PortSwigger Academy - замечательный ресурс для того чтобы быстро и безболезненно въехать в web-безопасность. Есть описания уязвимостей, примеры эксплуатации и лабораторные работы разного уровня сложности.
- Hack The Box - тут уклон больше в сервера и в целом в то, что принято называть “пентест”. Задания также разного уровня сложности, и чаще всего направлены на реализацию цепочки эксплуатации от получения начального доступа до выполнения кода на удаленной системе. Очень качественные разборы этих заданий можно найти в журнале “Хакер” у RalfHacker.
Проходить какие-то курсы я бы не рекомендовал. Имея багаж знаний разработчика гораздо проще брать конкретные темы и раскапывать их до требуемого уровня, чем сидеть и слушать очередного лектора вливающего кучу “обязательных” знаний в вашу и без того загруженную голову. Поэтому действуем как обычно в разработке: вижу неведомую херню - гуглю что это и пытаюсь понять. Никакой магии.
А вот дальше можно начать заниматься гораздо более сумрачными вещами вроде бинарного реверса и ковыряния железа. В этих областях тоже очень много интересных и сложных задач, которые способны заставить вас сидеть до 5 утра вглядываясь в столбики hex-чисел в попытках понять что это вообще такое =) Хотя, если душа просит хардкора и в крови есть достаточное количество мидихлорианов, то можно начать путь в инфобез и с этих областей.
Но есть один нюанс… 😵💫
Куда же без нюансов. Основная проблема разработчиков приходящих в безопасность состоит в том, что они слишком сильно уверены, что авторы очередного творения не могли допустить таких глупых ошибок. Ну типа “я же так не делаю” или “да ну, так же никто не пишет!”. Такой образ мышления отстреливает сразу кучу потенциальных векторов атаки и может привести к тому, что баги вообще не будут находиться. С этим конечно же надо планомерно бороться и качать критическое восприятие всего, что попадается на глаза. Увидели, что поле прогоняется через regex для санитизации? Ок, разработчик подумал про безопасность. Но так ли он хорошо умеет в regex? Могут ли тут быть кейсы, которые он не предусмотрел? Встретили двухфакторную аутентификацию? Ок, опять разработчик подумал про безопасность. А есть ли рейт-лимиты? А можно ли их обойти если поставить заголовок X-Forwarded-For: 127.0.0.1? Ну и так далее. Все подвергаем сомнению. Если вы так никогда не писали и вообще кругом молодец, то это не значит, что очередной бедолага из недр очередного кровавого энтерпрайза не написал какую-нибудь херню.
Послесловие
Всем этим великолепием конечно можно заниматься в одиночку, но гораздо веселее делать это в команде единомышленников. Да и развитие так пойдет быстрее. Где искать единомышленников я уже написал - конференции, митапы и прочие подобные ивенты. Также можно поиграть в CTF, а то и вовсе сходить в подвал к безопасникам в своей конторе, принести им чаю (или водки…) и поговорить за жизнь. Они совсем не злые, и точно оценят ваше желание получше разобраться в вопросах инфобеза. А может быть нарекут вас security champion-ом, и кто знает куда вас в итоге приведет эта дорога…
Всем безопасной разработки и профессионального роста!