Имеется приложение со связкой Spring Boot, Spring Data. Проанализировал код при помощи Checkmarx. Получил HIGH предупреждение о том, что код подвержен Stored XSS атаке. Проанализировал рекомендацию с сайта
https://www.checkmarx.com/blog/3-ways-prevent-xss/, а также stackoverflow и другие известные источники выяснилось, что необходимо избавиться от html тегов. Пользовался HtmlUtils.htmlEscape и StringEscapeUtils.escapeHtml4, но от ошибки я так и не избавился. Ошибка связана с тем, что вероятный запрос с xss атакой мог сохраниться в БД и при извлечении "не консистентные" данные будут отправлены на UI. Это не в точности мой код, но примерно так:
Set<User> users = repo.getUsers();
Checkmarx ругается именно на метод getUsers. Пробовал предотвратить эту проблему путем:
- Указания кастомного сериализотора для String полей DTO
- Использовал вышеупомянутые методы(HtmlUtils.htmlEscape и StringEscapeUtils.escapeHtml4) при мапинге сущность -> dto.
Но эффекта от этого не было.
На Checkmarx Dashboard в отчете, имеется колонка Best Fix Locations (BFL). В этой колонке указан либо объект, либо метод. Пробовал править именно так, реакции ноль.
При этом, когда у меня были Reflected XSS уязвимости с RequestParam, то удалось побороть только при помощи HtmlUtils.htmlEscape. Странно то, что когда я реализовал Filter Spring Security, который перехватывал запрос и предотвращал XSS атаку, Checkmarx продолжал ругаться и не считал это решением. Хотя я считаю, что вариант с кастомным фильтром является более правильным решением, нежели проверка каждого RequestParam в каждом эндпоинте.
Быть может кто-то уже сталкивался с подобным вопросом, либо натолкнет на правильное решение.
Простой