Как решить эту проблему безопасности XSS на странице JSP

У нас есть очень старый веб-сервер с некоторыми страницами JSP, как показано ниже. Кажется, я проверил версию входного параметра с помощью белого списка [a-zA-Z0-9]*. Но CheckMarx по-прежнему получил предупреждение о подключении XSS: эти ненадежные данные встраиваются прямо в вывод без надлежащей очистки или кодирования, что позволяет злоумышленнику внедрить вредоносный код в вывод. Знаете ли вы, как правильно сделать это на страницах JSP? Он просто использовался для отображения чего-то из ввода параметра.

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<%@page import="com.mytest.util.SecurityService"%>
<html>
<%
    String version = SecurityService.getSafeContent(request.getParameter("version"));
%>

<head>
<title>My Project</title>
</head>
<body>
    <div style="text-align: center">
        <table>
            <tr>
                <td>
                    <div style="text-align: center"><%=version%></div>
                </td>
            </tr>
        </table>
    </div>
</body>
</html>
public class SecurityService{
    public static final String PARAM_INVALID_DATA_POINT = "";
    
    public static String getSafeContent(String content) {
        if(!StringUtils.isEmpty(content) && content.matches("[a-zA-Z0-9]*")) {
            return content;
        }
        return PARAM_INVALID_DATA_POINT;
    }
}

Спасибо,


person Frank    schedule 01.02.2021    source источник


Ответы (2)


Это потому, что вы выполняете проверку вместо дезинфекции. Валидация - это тип потока управления для проверки уязвимых данных (если они недействительны, то... иначе...). Checkmarx SAST выполняет анализ потока данных, но не анализ потока управления.

Хотя сегодня вы можете пометить его как ложноположительный, кто-то может прийти и реорганизовать код и, возможно, непреднамеренно изменить ваше регулярное выражение проверки. Поскольку он помечен как ложноположительный, возможно, нарушенная проверка не будет обнаружена. Это простое регулярное выражение, но подумайте, что могло бы произойти, если бы это было более сложное регулярное выражение в дополнение к другой логике проверки.

Если вы используете что-то вроде кодировщика ESAPI, он берет ваши потенциально уязвимые данные, изменяет их. в продезинфицированную форму, затем возвращает продезинфицированную форму. Это поместит кодировщик ESAPI в поток данных и приведет к удалению результата. Checkmarx SAST ищет дезинфицирующие средства на пути потока данных, и, если дезинфицирующее средство найдено, путь потока данных не считается уязвимым.

Таким образом, у вас будет код вроде:

<%
    String version = ESAPI.encoder().encodeForHTML(request.getParameter("version"));
%>

Существуют и другие параметры кодировщика, вам просто нужно убедиться, что они распознаются в вашей версии Checkmarx SAST.

person NathanL    schedule 05.02.2021
comment
Я думаю, вы правы, спасибо. - person Frank; 26.02.2021

Согласно вашей ситуации, ваш бэкэнд сделал строгое ограничение ввода, так что это не может быть XSS. это предупреждение является ложным срабатыванием, просто игнорируйте.

person TIAOWANG    schedule 02.02.2021