Актуально для сервисов где задействован xml процессор. Сущность - амперсанд (&). Но многие забывают про так называемые внешние сущности. Злоумышленник может вписать где-то в коде свою сущность
[<!ENTITY tratra SYSTEM ‘/etc/passwd’>’]
Проблемы:
А. хоть там хранятся и хеши от паролей, но это неприято. Злоумышленник увидит содержимое файла, если ответ достаточно большой
Б. Злоумышленник может запросить содержимое /dev/urandom повалив процесс с парсером xml
В. Чтение локальных файлов
Г. Сканирование хостов
Д. В основном проблема для WebApi XML-образного
Решение:
В xml должна быть отключена обработка внешних сущностей по умолчанию.
См. также: Атака типа XXE Exploit
Проблема:
В веб-сервиса у пользователя имеется id-ик. Пользователь делает от этого айдишника операции. Простая логика не проверяет разрешение на разные операции. Злоумышленник меняя свою куку, или место от куда берётся этот параметр меняет на id-жертвы и работает на сервисе от имени жертвы.
Решение:
Лучше id не использовать, а использовать сессионные данные. Если всё таки id нужен для передачи, то проверять выдачу, добавив логику проверки, что для текущего пользователя операция разрешена. Текущего пользователя брать не из перегоняемого туда-сюда id.
Проблема:
HTTP протоколу без разницы от куда приходят запросы с куками или без кук.
Данная вещь эксплуатируется так: есть форма перевода денег в банковском приложении. Злоумышленник делает картинку <img src=”...”> где в качеств url указан url с таким запросом. Помещает эту картинку на популярном ресурсе, который посещают большое количество человек. Браузер клиента заходя на популярный ресурс, идёт за картинкой на указанный ресурс.
Картинку он не получит, но деньги утекут так как это как бы он инициировал запрос на перевод.
Решение:
А. Использование секретного ключа, или маркера уникального для (пользователя, сессии).
Любой запрос на изменение данных от пользователя должен быть подписан.
1. Клиент получает от первичного действия (которое не является операцией на модификацию) этот секретный ключ.
2. В дальнейших пересылках по http в поле input hidden, или в url запроса вставляется этот ключ.
3. Злоумышленник не знает о таком токене, и не может произвести атаку в этом исполнении
Б. Не выключать защиту от CSRF в веб-браузере.
В. Внести маленькие проблемы злоумышленнику. Запрос на модификацию со стороны пользователя должен носить имя метода POST при общении по HTTP протоколу. Это указано на уроне rfc, но так же это поспособствует то что <img src=”...”> не пройдёт. Требуется со стороны злоумышленника вставлять скрипт, или форму.
Является примером инъекции кода злоумышленника в верстку.
1. Внедрение осуществляется посредством дырок в веб-браузере на стороне клиента.
2. Внедрение осуществляется посредством дырок в веб-сервере, и инициируется кривыми http запросам.
3. Flash опасен XSS-ом. Flash надо защищать как и обычную верску от XSS.
Защита:
1. Требуется экранировать пять символов '"&<> перед отдачей контента пользователю.
2. Если поле title располагается до кодировки и содержит пользовательские данные, то оно должно располагаться после тега meta с описанием кодировки.
Возможна из-за некорректной обработки входных данных, используемых дальше в SQL-запросах.
Защита:
1. Проверка типа параметра. Если параметр должен быть целым числом - значит параметр должен быть целым числом, а не какой-либо строкой.
2. Строковые параметры на уровне формирование SQL запроса брать в кавычки. Сам запрос отфильтровать, произвести замену “ на \”, ‘ на \’, \ на \\
3. Усечение входных параметров