КАК исправить ошибку checkmarx для очистки полезной нагрузки

У меня есть служба весенней загрузки (2.4.5), которая показывает ошибку checkmarx, что нам нужно очистить полезную нагрузку запроса. Как мы очищаем полезную нагрузку запроса?

 @ApiOperation(value = "Executes new report. The response contains the new job id.")
@PostMapping(value = "/execute")
public ResponseEntity<MyResponse<Object, Void>> execute(
        @RequestBody final MyInput input) {.......}

Я получаю следующее сообщение об ошибке checkmarx для окончательного ввода MyInput @RequestBody:

Метод приложения executeNewReport выполняет SQL-запрос с входными данными в строке 82 файла src\main\java\com\gayathri\controllers\JobController.java. Приложение создает этот SQL-запрос, встраивая в запрос ненадежную строку без надлежащей очистки. Объединенная строка отправляется в базу данных, где она анализируется и выполняется соответствующим образом. Этот очевидный доступ к базе данных, по-видимому, инкапсулирован во внешнем компоненте или API. Таким образом, кажется, что злоумышленник может внедрить произвольные данные в SQL-запрос, изменив пользовательский ввод, который считывается методом execute, в строке 75 файла src\main\java\com\gayathri\controllers\. Джобконтроллер.java. Затем этот ввод проходит через код к внешнему API, а оттуда — к серверу базы данных, по-видимому, без очистки. Это может привести к атаке SQL Injection, основанной на эвристическом анализе.

Я хотел бы продезинфицировать свою полезную нагрузку. Или нет другого варианта, кроме как использовать DTO, а затем преобразовать его в мою базу данных?


spring-boot java sanitization checkmarx secure-coding
person Gayathri    schedule 13.05.2021    source источник
comment
было бы полезно, если бы вы могли показать некоторые фрагменты кода   -  person securecodeninja    schedule 14.05.2021
comment
@RomanCanlas, я добавил фрагмент кода и подробности ошибки галочки   -  person Gayathri    schedule 17.05.2021

Ответы (1)


arrow_upward
0
arrow_downward

Основываясь на описании уязвимости, я предполагаю, что уязвимость, обнаруженная Checkmarx, — это эвристическая инъекция SQL. Было бы неплохо увидеть, где находится приемник (куда распространяется уязвимость), а не только источник (@RequestBody final MyInput input).

Первый подход заключается в использовании параметризации или подготовленных операторов, и вот ссылка на памятку от OWASP, которые могут быть вам полезны

Я думаю, что Checkmarx также обращает внимание на использование функции encodeForSQL, которая потребует от вас использования OWASP Enterprise Security API библиотека

Если вы используете MySQL:

input = ESAPI.encoder().encodeForSQL(new MySQLCodec(), input);

или соответствующим образом измените кодек базы данных

person securecodeninja    schedule 17.05.2021
comment
Благодарность! Я попробую это и приму ваш ответ. Мы используем MongoDB. Таким образом, ввод, наконец, сохраняется в MongoDB. Это отвечает на ваш вопрос о раковине? - person Gayathri; 18.05.2021
comment
да, но encodeForSQL может быть неправильным решением, учитывая, что ваш бэкэнд - это база данных NoSQL. Я не уверен, сможет ли он закодировать его в соответствии с синтаксисом MongoDB, даже если у вас есть кодек MongoDB stackoverflow.com/questions/41618203/ - person securecodeninja; 18.05.2021
comment
вы можете попробовать и добавить инъекционную команду MongoDB только для проверки. посмотреть, кодируется ли ввод - person securecodeninja; 18.05.2021