API8:2019 Инъекции
| Источники угроз/Векторы атак | Недостатки безопасности | Последствия |
|---|---|---|
| Зависит от API : Сложность эксплуатации 3 | Распространенность 2 : Сложность обнаружения 3 | Технические последствия 3 : Зависит от бизнеса |
| Злоумышленник может отправить в API любые данные через любой доступный вектор инъекции (например, прямой ввод, параметры, интегрированные сервисы и так далее), предполагая, что они будут перенаправлены в интерпретатор. | Ошибки, приводящие к инъекциям, очень распространены и присущи SQL, LDAP и NoSQL запросам, командам на операционной системе, XML парсерам и ORM. Подобные ошибки легко обнаруживаются в ходе анализа исходного кода. Злоумышленники могут использовать сканеры и фаззеры. | Инъекции могут привести к разглашению или уничтожению данных, отказу в обслуживании или получению злоумышленником полного контроля на сервером. |
Как определить, является ли API уязвимым?
API уязвим к инъекциям, если:
- Данные, поступившие от пользователя, не валидируются, не фильтруются или не очищаются на стороне API.
- Данные, поступившие от пользователя, конкатенируются или используются в неизменном виде в SQL/NoSQL/LDAP запросах, командах на операционной системе, XML парсерах, ORM (Object Relational Mapping) или ODM (Object Document Mapper).
- Данные поступающие из внешних систем (например, интегрированных систем) не валидируются, не фильтруются или не очищаются на стороне API.
Примеры сценариев атаки
Сценарий #1
Прошивка устройства контроля за детьми предоставляет точку входа /api/CONFIG/restore, которая ожидает запроса с multipart параметром appId. Используя декомпилятор, злоумышленник обнаруживает, что appId передается непосредственно в вызов команды на операционной системе без предварительной очистки:
snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d",
"/mnt/shares/usr/bin/scripts/", appid, 66);
system(cmd);
Следующая команда позволяет злоумышленнику отключить любое устройство с уязвимой прошивкой:
$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)'
Сценарий #2
Рассмотрим приложение с базовым CRUD функционалом для операций с бронированиями. Злоумышленник обнаружил NoSQL инъекцию через параметр bookingId в запросе на удаление бронирования. Запрос выглядит следующим образом: DELETE /api/bookings?bookingId=678.
Сервер API обрабатывает запросы на удаление с помощью следующей функции:
router.delete('/bookings', async function (req, res, next) {
try {
const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId});
res.status(200);
} catch (err) {
res.status(400).json({error: 'Unexpected error occured while processing a request'});
}
});
Злоумышленник перехватывает запрос и изменяет параметр bookingId, как продемонстрировано ниже. В этом случае злоумышленник может удалить бронирование, принадлежащее другому пользователю:
DELETE /api/bookings?bookingId[$ne]=678
Как предотвратить
Для предотвращения инъекций необходимо отделять данные от команд и запросов.
- Валидируйте данные, используя одну доверенную и активно поддерживаемую библиотеку.
- Валидируйте, фильтруйте и очищайте все данные, получаемые от клиентов или интегрированных систем.
- Специальные символы должны быть экранированы, используя синтаксис целевого интерпретатора.
- Отдайте предпочтение безопасному API, предоставляющему параметризированный интерфейс.
- Всегда ограничивайте количество возвращаемых записей, чтобы предотвратить массовую утечку данных в случае инъекции.
- Валидируйте входящие данные с помощью надлежащих фильтров, допуская только подходящие значения каждого из входящих параметров.
- Определите тип данных и строгую модель данных для всех строковых параметров.