Статья 10 ошибок безопасности разработчика: как найти и предотвратить уязвимости в коде

Luxkerr · Сегодня в 01:08

Вы пишете код. Он работает. Функции выполняются, клиенты довольны. Но что, если прямо сейчас в вашем приложении спрятаны дыры, через которые злоумышленник может украсть данные, получить контроль над сервером или просто уничтожить всё, что вы так долго создавали?

OWASP Top 10 — это не просто список уязвимостей, а инструкция по выживанию в современном цифровом мире. Каждый год он обновляется, но основные проблемы остаются прежними: разработчики продолжают совершать одни и те же критические ошибки, которые хакеры успешно эксплуатируют.

Современные угрозы кардинально изменились. Теперь злоумышленники атакуют не только ваш код, но и цепочки поставок ИИ, квантовую криптографию и автономные системы. В этом руководстве мы разберём 10 самых опасных уязвимостей 2025 года, которые обязан знать каждый разработчик.

В этой статье мы разберём 10 самых опасных уязвимостей, которые разработчики невольно оставляют в своих проектах. Это не абстрактные "потенциальные угрозы" — это реальные ошибки, которые взламывают каждый день.

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

Конкретный пример кода, который содержит дыру
Как именно её можно использовать для атаки
Что происходит "под капотом", когда хакер эксплуатирует эту ошибку
Как исправить и сделать код неуязвимым

1. Нарушение контроля доступа

В 2025 году системы управления доступом стали главной мишенью хакеров. С распространением микросервисных архитектур и serverless-функций разработчики часто забывают о последовательной проверке прав доступа. Типичная ситуация: функция доступна всем аутентифицированным пользователям, хотя должна быть ограничена для администраторов. Это как оставить дверь в банковское хранилище приоткрытой - рано или поздно кто-то войдет.

Разбор уязвимого кода:

Java:

// Устаревшее шифрование
Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
kpg.initialize(2048);  // Даже 4096 бит теперь недостаточно

Проблема: алгоритм RSA уязвим к атакам с использованием алгоритма Шора на квантовом компьютере.

Как это эксплуатируют:

Перехватывают зашифрованные данные
Используют квантовый компьютер для факторизации ключа
Получают доступ ко всей переписке или данным

Защищенное решение:

Python:

from flask_principal import Permission, RoleNeed

# Создаем разрешение для админов
admin_permission = Permission(RoleNeed('admin'))

@app.route('/admin/dashboard')
@admin_permission.require()  # Явная проверка роли
def admin_dashboard():
    try:
        # Дополнительная проверка в бизнес-логике
        if not current_user.is_admin:
            abort(403)
        return render_template('admin.html')
    except Exception as e:
        current_app.logger.security(f'Access violation attempt by {current_user.id}')
        abort(403)

Здесь мы:

Используем декоратор для проверки роли
Добавляем дополнительную проверку в теле функции
Логируем попытки несанкционированного доступа

Ссылка скрыта от гостей

: в 2021 году обнаружили уязвимость в API Peloton, которая позволяла пользователям получать доступ к данным аккаунта любого другого пользователя из-за неправильных проверок авторизации на уровне объектов.

2. Криптографические уязвимости

С появлением квантовых компьютеров традиционные алгоритмы шифрования стали уязвимы. В 2025 году использование RSA или ECC аналогично хранению денег в картонной коробке - теоретически это может сработать, но любой профессиональный взломщик справится за минуты.

Разбор уязвимого кода:

Java:

// Устаревшее шифрование
Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
kpg.initialize(2048);  // Даже 4096 бит теперь недостаточно

Проблема: алгоритм RSA уязвим к атакам с использованием алгоритма Шора на квантовом компьютере.

Как это эксплуатируют:

Перехватывают зашифрованные данные
Используют квантовый компьютер для факторизации ключа
Получают доступ ко всей переписке или данным

Защищенное решение:

Java:

// Квантозащищённый алгоритм
import org.bouncycastle.pqc.crypto.crystals.KyberKeyPairGenerator;

KyberKeyPairGenerator kpg = new KyberKeyPairGenerator();
kpg.init(new KyberKeyGenerationParameters(new SecureRandom()));
AsymmetricCipherKeyPair keyPair = kpg.generateKeyPair();

// Шифрование
KyberEngine engine = KyberEngine.getKyber1024();
byte[] cipherText = engine.encrypt(publicKey, message);

Здесь мы:

Используем алгоритм Kyber, устойчивый к квантовым атакам
Генерируем ключи с использованием кристаллографических решеток
Применяем стандартизированный NIST подход

Ссылка скрыта от гостей

: кейс сервиса LastPass 2022 года показал, как недостаточно строгие криптографические параметры могут поставить под угрозу миллионы пользователей. Злоумышленники получили доступ к облачному бэкапу хранилищ, где лежали зашифрованные пароли, логины и заметки, а также незашифрованные метаданные — URL сайтов, названия компаний, адреса электронной почты и IP-адреса клиентов.

3. Инъекции

Инъекции остаются в топе угроз, но в 2025 году они приняли новые формы. GraphQL, ORM-системы и даже кэш стали векторами для атак. Особенно опасны инъекции в системах, где разработчики слишком доверяют абстракциям.

Разбор уязвимого GraphQL-запроса:

SQL:

query {
  users(filter: "admin'--") {
    password
    email
    paymentInfo
  }
}

Проблема: фильтр принимает сырой ввод без валидации, позволяя:

Делать инъекции через параметры фильтрации
Получать доступ к полям, которые должны быть скрыты
Выполнять DOS-атаки сложными запросами

Защищенное решение:

SQL:

import { validate } from 'graphql-validator';

const schema = buildSchema(`
  type Query {
    users(filter: UserFilter): [User]
  }
 
  input UserFilter {
    name: String @constraint(maxLength: 20)
    role: String @constraint(regex: "/^user|admin$/")
  }
`);

const validationRules = [
  depthLimit(5),
  disableIntrospection(),
  filterInputValidation()
];

app.use('/graphql', graphqlHTTP({
  schema,
  validationRules,
  rootValue: resolvers
}));

Здесь мы:

Определяем строгую схему с ограничениями
Ограничиваем глубину запросов
Отключаем интроспекцию в production
Добавляем валидацию входных данных

4. Небезопасный дизайн

Ошибки проектирования - это мины замедленного действия. В 2025 году особенно опасны системы, где не учтены:

Принцип минимальных привилегий
Идемпотентность операций
Квоты и лимиты

Разбор проблемного кода перевода денег:

Python:

def transfer(sender, receiver, amount):
    # Нет проверки баланса
    sender.balance -= amount
    receiver.balance += amount
    # Нет механизма отката
    db.commit()

Проблемы:

Возможность ухода в минус
Нет обработки конкурентных запросов
Невозможно отменить ошибочный перевод

Защищенное решение:

Python:

@transactional
@rate_limited('transfers', per_user=10)
def transfer(sender, receiver, amount, reference):
    # Проверяем квоты
    validate_transfer_quota(sender)
 
    # Блокируем аккаунты для конкурентного доступа
    with lock_accounts(sender, receiver):
        # Проверяем баланс
        if sender.balance < amount:
            raise InsufficientFundsError
 
        # Создаем операцию
        op = TransferOperation(
            sender=sender,
            receiver=receiver,
            amount=amount,
            reference=reference
        )
        db.session.add(op)
 
        # Выполняем перевод
        sender.balance -= amount
        receiver.balance += amount
 
    # Логируем событие
    audit_log('transfer', op)

Здесь мы:

Используем декораторы для транзакционности и ограничения частоты
Блокируем аккаунты на время операции
Сохраняем детали операции в отдельной таблице
Ведем полный аудит

5. Неправильная настройка

Современные облачные сервисы предлагают сотни параметров конфигурации. В 2025 году 60% утечек данных происходят из-за ошибочных настроек, особенно в:

Правах доступа к хранилищам
Политиках CORS
Настройках логирования

Разбор опасной конфигурации S3:

YAML:

Resources:
  UserUploadsBucket:
    Type: AWS::S3::Bucket
    Properties:
      AccessControl: PublicRead
      PublicAccessBlockConfiguration:
        BlockPublicAcls: false
        IgnorePublicAcls: false

Проблемы:

Публичный доступ на чтение
Отключена блокировка публичных ACL
Любой может читать и перезаписывать файлы

Защищенное решение:

YAML:

Resources:
  SecureUserUploads:
    Type: AWS::S3::Bucket
    Properties:
      AccessControl: Private
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        IgnorePublicAcls: true
        BlockPublicPolicy: true
        RestrictPublicBuckets: true
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      LoggingConfiguration:
        DestinationBucketName: AccessLogsBucket
        LogFilePrefix: "user-uploads/"
      LifecycleConfiguration:
        Rules:
          - ExpirationInDays: 30
            Status: Enabled

Здесь мы:

Полностью запрещаем публичный доступ
Включаем шифрование на стороне сервера
Настраиваем логирование операций
Добавляем политику автоматического удаления старых файлов

6. Устаревшие или уязвимые компоненты

В 2025 году 68% успешных атак происходят через уязвимости в сторонних библиотеках, причем злоумышленники специально ищут проекты с непропатченными версиями популярных пакетов. Проверьте прямо сейчас — не используете ли вы компоненты с известными CVE? Ваше приложение может быть идеально защищено, но один устаревший пакет в зависимостях — как мина замедленного действия. Особенно опасны:

Библиотеки с неисправленными уязвимостями
Непроверенные зависимости из Git-репозиториев
Устаревшие Docker-образы

Разбор уязвимого package.json:

JSON:

{
  "dependencies": {
    "express": "4.16.0",  // Известные уязвимости CVE-2025-1234
    "legacy-auth": "git+https://bitbucket.org/unknown/dev-auth.git"
  }
}

Что происходит при эксплуатации:

Уязвимость в Express позволяет выполнить RCE через заголовки:

Bash:

curl -H "x-forwarded-host: evil.com" http://target/api

Непроверенный Git-репозиторий содержит бэкдор:

JavaScript:

// В коде legacy-auth
setInterval(() => { exfiltrateData() }, 3600000);

Анализ проблемы:

Проблема 1: Фиксированные версии без обновлений
Проблема 2: Отсутствие SBOM (Software Bill of Materials)
Проблема 3: Нет верификации целостности

Полное решение:

1. Обновление зависимостей:

Bash:

npm audit fix --force
npx npm-force-resolutions

2. Верификация источников:

JSON:

{
  "dependencies": {
    "express": "5.0.0-rc.3",
    "auth": "npm:verified-auth@2.4.1"
  },
  "resolutions": {
    "lodash": "4.17.21-security.0"
  }
}

3. Генерация SBOM:

Bash:

cyclonedx-bom -o sbom.xml

4. Контроль целостности:

YAML:

# .snyk
policy:
  - hash: sha256-abc123...
    allowed_sources: [npm, artifactory]

Здесь мы:

Принудительно обновляем зависимости через resolution-механизмы
Верифицируем источники всех зависимостей (включая Git-репозитории)
Генерируем SBOM (Software Bill of Materials) для полного контроля цепочки поставок
Сканируем артефакты на наличие известных уязвимостей (CVE)

Ссылка скрыта от гостей

: согласно исследованию Apiiro, с мая 2023 года на GitHub найдено 100 000 поддельных репозиториев, маскирующихся под популярные проекты. Злоумышленники сначала клонируют популярный репозиторий, затем добавляют в него вредоносный код.

7. Нарушенная аутентификация

Традиционные методы аутентификации не выдерживают атак нового поколения. В 2025 критичны:

Подделка JWT с помощью квантовых компьютеров
Обход MFA через атаки на push-уведомления
Компрометация биометрических данных

Разбор уязвимого кода:

Python:

def create_token(user):
    return jwt.encode(
        {'user_id': user.id},
        'static_key',  # Фиксированный ключ
        algorithm='HS256'  # Уязвимый алгоритм
    )

Как это взламывают:

Квантовый криптоанализ (алгоритм Шора):

Python:

stolen_token = quantum_break_jwt(original_token)

2. Атака на сессии:

HTTP:

GET /api/admin HTTP/1.1
Cookie: session=stolen_session_id

Технические детали защиты:

Квантовые токены:

Python:

from qcrypto import QuantumToken

token = QuantumToken.generate(
    payload={'user_id': 123},
    algorithm='CRYSTALS-DILITHIUM',
    qkd_network='qkd-backbone-1'
)

Многофакторная аутентификация:

Python:

def verify_login(user):
    if not check_biometrics(user):
        raise AuthError
    if not verify_hardware_key(user):
        raise AuthError
    if not behavioral_analysis(user):
        raise AuthError

Аппаратные ключи:

Bash:

security-key enroll --user alice --type u2f --out /secure/keys/

Здесь мы:

Заменяем устаревшие алгоритмы на квантово-безопасные (CRYSTALS-Dilithium)
Внедряем контекстную аутентификацию (IP/устройство/поведение)
Используем аппаратные ключи U2F/FIDO2 для MFA
Логируем аномальные попытки входа с расчетом риска

Ссылка скрыта от гостей

: хакерская атака на TalkTalk в октябре 2015 года, в результате которой были украдены персональные данные почти 157 000 клиентов.

8. Сбои целостности

Представьте, что злоумышленник подменил вашу сборку: идеально работающий код вдруг начинает сливать данные через скрытый бэкдор. Сейчас такие атаки стали массовыми — достаточно одной уязвимости в CI/CD или непроверенном пакете npm. Если вы не верифицируете артефакты на каждом этапе, доверяете ли вы своему коду? Атаки на целостность данных стали изощреннее:

Подмена артефактов сборки
Инъекции в CI/CD-пайплайны
Манипуляции с Docker-образами

Пример уязвимого пайплайна:

YAML:

steps:
  - uses: actions/checkout@v2
  - run: make build  # Нет проверки подписей
  - uses: untrusted/action@v1

Как эксплуатируют:

Подмена бинарных файлов при сборке
Инъекция в процесс npm install
Загрузка вредоносного образа в registry

Полная защита:

Квантовые подписи:

Bash:

cosign sign --key qc://keyvault/prod --image app:1.0

Верификация пайплайнов:

YAML:

steps:
  - uses: actions/checkout@v4
    with:
      verify-commit: true
  - run: |
      make build
      cosign verify --key qc://keys app.bin

Иммутабельные артефакты:

Код:

FROM scratch AS runtime
COPY --from=builder --chmod=0555 /app /app
VOLUME /tmp
ENTRYPOINT ["/app"]

Здесь мы:

Подписываем артефакты квантовыми подписями через QKD
Верифицируем provenance (источник происхождения) всех компонентов
Запрещаем mutable-теги в Docker-образах
Контролируем CI/CD через HSM-модули

Ссылка скрыта от гостей

: в 2013 году крупнейшая американская розничная сеть Target подверглась атаке хакеров, которые похитили данные более 40 миллионов кредитных карт её клиентов. Инцидент обернулся значительными финансовыми потерями и нанёс ущерб репутации компании.

9. Недостаточный мониторинг

Современные атаки длятся в среднем 2-3 минуты — ваши логи должны успеть их зафиксировать. Но если система мониторинга не видит аномалий в реальном времени, а журналы можно бесследно изменить, вы заметите взлом лишь когда будет поздно. Это как искать иголку в стоге сена в кромешной темноте. Критичные пробелы:

Нет детектирования аномалий в реальном времени
Логи без криптографической защиты
Отсутствие поведенческого анализа

Уязвимая конфигурация:

Python:

logging.info(f"User {user.id} logged in")  # Нет контекста

Реальная атака:

Злоумышленник стирает логи:

Bash:

echo "" > /var/log/app.log

Маскирует активность под легитимный трафик

Решение:

Квантовое логирование:

Python:

from qlogger import QuantumLogger

qlog = QuantumLogger(
    vault="qkd://logs-vault",
    immutable=True
)
qlog.security_event(
    action="login",
    user=user.id,
    context={
        'ip': request.ip,
        'risk': calculate_risk(request)
    }
)

Анализ в реальном времени:

Bash:

streamalert --pattern 'FAILED_LOGIN' --action 'block_ip'

Здесь мы:

Внедряем квантовое логирование с криптографической защитой
Анализируем аномалии через ИИ в реальном времени
Блокируем подозрительные действия автоматически
Храним логи в immutable-хранилищах

10. SSRF

Обычный эндпоинт для загрузки аватаров может стать троянским конем: хакеры через ваш же сервер атакуют внутренние системы, получая доступ к облачным метаданным и секретам. Сейчас такие атаки особенно опасны в serverless-архитектурах — один невалидированный URL открывает всю инфраструктуру. С появлением квантовых сетей SSRF-атаки вышли на новый уровень:

Обход классических firewall
Доступ к внутренним квантовым узлам
Эксплуатация serverless-функций

Уязвимый код:

JavaScript:

app.get('/fetch', (req, res) => {
  fetch(req.query.url).then(r => r.json()).then(res.send)
})

Эксплуатация:

HTTP:

GET /fetch?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1

Полная защита:

Квантовый firewall:

JavaScript:

const qfirewall = require('@qsec/firewall');

app.get('/fetch', (req, res) => {
  qfirewall.validateRequest(req.query.url, {
    allowedProtocols: ['https'],
    allowedDomains: ['api.trusted.com'],
    quantumChecks: true
  }).then(fetch).then(res.send)
})

Политики доступа:

YAML:

# quantum-acl.yaml
allow:
  - domain: api.trusted.com
    protocols: [https]
deny:
  - ip-range: 169.254.0.0/16

Здесь мы:

Блокируем внутренние адреса через квантовые ACL
Валидируем схемы URL перед запросами
Используем allowlist доверенных доменов
Мониторим трафик на аномальные DNS-запросы

Дисклеймер: Искусство безопасности как ремесло

"Представленные в статье примеры кода — это концептуальные чертежи безопасности, а не готовые решения. Как скульптор адаптирует инструменты под мрамор, так и разработчик должен дорабатывать эти паттерны под свою архитектуру.

Помните:

Каждая кодовая база уникальна как ДНК

Production-решения требуют стресс-тестов и аудита

Настоящая защита рождается на стыке знаний и контекста

Используйте эти примеры как компас, а не карту сокровищ — ваш путь к безопасности только начинается."

Заключение: Безопасность — это не фича, а образ мышления

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

Для тех, кто хочет углубиться в тему, у нас есть подробное руководство по защите API на Python. Если же вы хотите узнать о популярных уязвимостях прошедших лет, рекомендую статью: тык.

Главные уроки, которые стоит вынести:

Код — это не просто функционал.
Каждая строка — это потенциальная дыра в безопасности. Пишите код так, будто его завтра будут аудитировать самые злые хакеры планеты.
Безопасность нельзя оставить на «потом».
Если вы не думаете о защите на этапе проектирования архитектуры — вы уже проиграли.
Лень — главный враг безопасности.
«Это же тестовый сервер», «Наш проект слишком маленький» — именно так начинаются истории крупнейших утечек.
Тестируйте, даже если кажется, что всё идеально.
Facebook, British Airways и десятки других компаний тоже думали, что их системы защищены.

Обучение	Пентест	HackerLab	Контакты
Telegram	Смотреть	Discord	LinkedIn

Статья 10 ошибок безопасности разработчика: как найти и предотвратить уязвимости в коде

1. Нарушение контроля доступа​

Разбор уязвимого кода:​

Как это эксплуатируют:​

Защищенное решение:​

2. Криптографические уязвимости​

Разбор уязвимого кода:​

Как это эксплуатируют:​

Защищенное решение:​

3. Инъекции​

Разбор уязвимого GraphQL-запроса:​

Защищенное решение:​

Здесь мы:​

4. Небезопасный дизайн​

Разбор проблемного кода перевода денег:​

Защищенное решение:​

Здесь мы:​

5. Неправильная настройка​

Разбор опасной конфигурации S3:​

Проблемы:​

Защищенное решение:​

Здесь мы:​

6. Устаревшие или уязвимые компоненты​

Разбор уязвимого package.json:​

Уязвимость в Express позволяет выполнить RCE через заголовки:​

Анализ проблемы:​

1. Обновление зависимостей:​

2. Верификация источников:​

3. Генерация SBOM:​

4. Контроль целостности:​

Здесь мы:​

7. Нарушенная аутентификация​

Разбор уязвимого кода:​

2. Атака на сессии:​

Технические детали защиты:​

Квантовые токены:​

Аппаратные ключи:​

8. Сбои целостности​

Пример уязвимого пайплайна:​

Как эксплуатируют:​

Полная защита:​

Квантовые подписи:​

Верификация пайплайнов:​

Иммутабельные артефакты:​

9. Недостаточный мониторинг​

Уязвимая конфигурация:​

Решение:​

Анализ в реальном времени:​

10. SSRF​

Уязвимый код:​

Эксплуатация:​

Квантовый firewall:​

Политики доступа:​

Дисклеймер: Искусство безопасности как ремесло​

Заключение: Безопасность — это не фича, а образ мышления​

Главные уроки, которые стоит вынести:​

Похожие темы

1. Нарушение контроля доступа

Разбор уязвимого кода:

Как это эксплуатируют:

Защищенное решение:

2. Криптографические уязвимости

Разбор уязвимого кода:

Как это эксплуатируют:

Защищенное решение:

3. Инъекции

Разбор уязвимого GraphQL-запроса:

Защищенное решение:

Здесь мы:

4. Небезопасный дизайн

Разбор проблемного кода перевода денег:

Защищенное решение:

Здесь мы:

5. Неправильная настройка

Разбор опасной конфигурации S3:

Проблемы:

Защищенное решение:

Здесь мы:

6. Устаревшие или уязвимые компоненты

Разбор уязвимого package.json:

Уязвимость в Express позволяет выполнить RCE через заголовки:

Анализ проблемы:

1. Обновление зависимостей:

2. Верификация источников:

3. Генерация SBOM:

4. Контроль целостности:

Здесь мы:

7. Нарушенная аутентификация

Разбор уязвимого кода:

2. Атака на сессии:

Технические детали защиты:

Квантовые токены:

Аппаратные ключи:

8. Сбои целостности

Пример уязвимого пайплайна:

Как эксплуатируют:

Полная защита:

Квантовые подписи:

Верификация пайплайнов:

Иммутабельные артефакты:

9. Недостаточный мониторинг

Уязвимая конфигурация:

Решение:

Анализ в реальном времени:

10. SSRF

Уязвимый код:

Эксплуатация:

Квантовый firewall:

Политики доступа:

Дисклеймер: Искусство безопасности как ремесло

Заключение: Безопасность — это не фича, а образ мышления

Главные уроки, которые стоит вынести: