#blog

#books
Кусочек из моей новой книги. Напоминаю, что сейчас можно оформить предзаказ на данную книгу, по цене 899 ₽. На релизе цена будет 1299 ₽.
Содержание книги: https://vk.ru/@hacker_timcore-soderzhanie-knigi-myshlenie-hakera Введение. Анатомия нестандартного мышления
- Почему создатель строит, а мы разбираем: разница паттернов
В мире информационных технологий существует негласная линия фронта, невидимая для обычного пользователя. По одну сторону баррикад находятся создатели - разработчики, архитекторы, DevOps-инженеры. По другую - исследователи безопасности, баг-хантеры, пентестеры и, конечно же, злоумышленники. Чтобы понять, как работает мышление хакера, необходимо сначала препарировать мышление создателя. Это два фундаментально разных когнитивных паттерна, два противоположных способа смотреть на одну и ту же систему.
Создатель живет в мире созидания, ограниченном жесткими рамками. Его паттерн мышления формируется под давлением дедлайнов, спринтов, требований бизнеса и технического задания. Разработчик - это строитель. Когда он пишет код, его главная задача - заставить систему работать. Он мыслит так называемым сценарием «Happy Path» (счастливый путь).
Что такое Happy Path? Это идеальный сценарий использования приложения, при котором пользователь делает ровно то, что от него ожидается. Пользователь открывает форму авторизации, вводит правильный логин, вводит правильный пароль, нажимает кнопку «Войти» и получает доступ к своему профилю. Разработчик пишет код, который элегантно обрабатывает эту цепочку событий. Он тратит часы на то, чтобы кнопка красиво подсвечивалась при наведении, чтобы база данных быстро возвращала токен сессии, чтобы архитектура микросервисов выдержала нагрузку в пятницу вечером. Если тесты проходят и фича работает - задача закрыта, тикет в Jira переведен в статус «Done». Разработчик строит прямую, светлую дорогу от точки А к точке Б.
Но мышление хакера начинается ровно там, где заканчивается Happy Path.
Мы не ходим по светлым дорогам, которые для нас заботливо заасфальтировали программисты. Разрушитель смотрит на ту же самую форму авторизации, но видит не интерфейс, а набор потенциальных точек отказа. Наш мозг автоматически генерирует вопросы, которые разработчику просто не приходят в голову из-за профдеформации.
«А что, если в поле для логина я вставлю не email, а массив из 10 000 спецсимволов?»«А что, если я отправлю POST-запрос, но изменю тип контента с application/json на application/xml и закину туда внешнюю сущность (XXE)?»«А что, если я вообще пропущу этап авторизации и напрямую обращусь к эндпоинту /api/v1/admin/dashboard, просто подменив ID пользователя в куках?»
Разница паттернов заключается в том, что создатель мыслит позитивными ограничениями (система должна делать X), а хакер мыслит негативными возможностями (что произойдет, если я заставлю систему сделать Y, о чем в документации ни слова).
Главная иллюзия, в которой живут создатели - это вера в то, что пользовательский интерфейс (UI) контролирует поведение пользователя. Разработчик делает поле ввода возраста, ставит там ограничение от 18 до 99 лет и искренне верит, что никто не сможет ввести туда отрицательное число. Он думает, что выпадающий список (dropdown) с тремя ролями («User», «Manager», «Guest») гарантирует, что никто не выберет роль «Admin», ведь её просто нет на экране!
Это и есть архитектурная слепота. Хакер знает: интерфейс - это ложь. Это просто вежливое предложение системы общаться по её правилам. И мы эти правила не принимаем.
В этот момент на сцену выходит главный инструмент любого баг-хантера - прокси-сервер для перехвата трафика, такой как Burp Suite. Когда вы запускаете Burp, графический интерфейс приложения перестает иметь значение. Вы опускаетесь на уровень транспортного протокола HTTP. Вы видите сырую реальность - голый текст запросов и ответов. И именно здесь кроется магия разрушения.
Рассмотрим классический пример разницы паттернов на реальной бизнес-логике. Представьте интернет-магазин.Паттерн создателя выстраивает цепочку:
1. Пользователь кладет товар в корзину (ID товара: 42, цена: 1000 руб.).
2. Переходит на страницу оплаты.
3. Оплачивает 1000 руб.
4. Получает товар.
Хакер, вооружившись Burp Suite, перехватывает запрос на этапе добавления в корзину. Он видит следующий JSON:
{ "item_id": 42, "quantity": 1, "price": 1000}
Разработчик добавил поле price в запрос, потому что так было удобнее передавать данные между микросервисами фронтенда и бэкенда. Он доверяет этому запросу, ведь фронтенд находится под его контролем. Но хакер находится между фронтендом и бэкендом. Он меняет запрос «на лету»:
{ "item_id": 42, "quantity": -10, "price": 1000}
Или, что еще веселее:
{ "item_id": 42, "quantity": 1, "price": -50000}
Что сделает бэкенд? Если разработчик не реализовал жесткую проверку целостности данных на стороне сервера (а он часто этого не делает, потому что «мы же уже проверили это на клиенте!»), сервер примет этот запрос. И вот баланс хакера пополняется на 50 000 рублей из-за банального Parameter Tampering. Создатель не мог этого предвидеть, потому что его паттерн созидания не включает в себя концепцию злонамеренного абсурда. Зачем нормальному клиенту покупать минус десять айфонов? Нормальному - незачем. Но мы здесь не для того, чтобы быть нормальными.
Быть хакером - значит постоянно задавать системе вопросы, к которым она не готова. Разработчики мыслят объектами, классами и архитектурными паттернами. Они используют мощные фреймворки (Spring, Django, React), которые берут на себя защиту от базовых атак вроде классических SQL-инъекций или XSS. Современный интернет стал намного безопаснее, чем десять лет назад. Но фреймворк не спасет от логических дыр. Фреймворк не знает, кто имеет право переводить деньги на конкретный счет - это знает только бизнес-логика, которую писал уставший мидл в пятницу вечером под кофеином.
Создатель строит стены, опираясь на чертежи. Хакер не пытается пробить эту стену головой. Он внимательно изучает её, находит вентиляционную шахту, понимает, что замок на ней повешен задом наперед, и пролезает внутрь, попутно перехватив управление климат-контролем всего здания.
Чтобы научиться ломать, вам придется убить в себе пользователя. Вы больше не нажимаете кнопки, чтобы получить результат. Вы нажимаете кнопки, чтобы посмотреть, как система обрабатывает ошибки. Ошибка - это ваш лучший друг. Stack Trace (трассировка стека), вывалившийся на экран из-за некорректного ввода - это карта сокровищ, показывающая, как устроены внутренности приложения.
Ваш мозг должен стать машиной по генерации краевых случаев (edge cases). Вы должны смотреть на любую технологию, от веб-сайта до умной микроволновки, и задавать один и тот же вопрос: «Как мне заставить это работать не так, как задумывал создатель?». В этом заключается истинная анатомия нестандартного мышления. Мы не просто ищем баги. Мы ищем разницу между тем, как система должна работать в идеальном мире разработчика, и тем, как она работает на самом деле в суровой реальности HTTP-запросов. И поверьте, эта разница есть всегда.