Очистить / проверить переменную, чтобы избежать атаки межсайтового скриптинга - PullRequest
Новая
       49

Очистить / проверить переменную, чтобы избежать атаки межсайтового скриптинга

0 голосов
/ 07 мая 2020

У меня возникает эта проблема при сканировании безопасности CheckMarx:

Метод exec в строке 69 из web\src\main\java\abc\web\actions\HomeAction.java получает пользовательский ввод для элемента CNF_KEY_COSN. Затем значение этого элемента проходит через код без должной очистки или проверки и в конечном итоге отображается пользователю в методе logException в строке 905 из web\src\main\java\gov\abc\external\info\ServiceHelper.java. Это может включить атаку Cross-Site-Scripting .

Строка 69 из HomeAction.java: 

String cosn = (String) request.getParameter(CNF_KEY_CON);

Строка 905 в ServiceHelper.java просто регистрирует ошибку: 

private static void logException(InfoServiceException exception, String message) {
    String newMessage = message + ": " + exception.getMessageForLogging();
    try {
        log.error(newMessage, exception);
    } catch (Exception e) {
        // fallback to console
        System.out.println("error logging exception ->");
        e.printStackTrace(System.out);
        System.out.println("exception ->");
        System.out.print(newMessage);
        if (exception != null) exception.printStackTrace(System.out);
    }
}

Изменен другой блок кода в HomeAction.java на: 

if(cosn!= null && cosn.matches("[0-9a-zA-Z_]+")) {
  ...
}

Но это не помогло . Как мне проверить / дезинфицировать / закодировать Строка 69 . Любая помощь приветствуется.

Спасибо

Ответы [ 3 ]

0 голосов
/ 14 мая 2020

Checkmarx определяет набор дезинфицирующих средств, которые вы можете проверить в системе.

На основе фрагментов исходного кода; я предполагаю, что; i) вы добавляете cosn к сообщению ii) приложение по своей природе является веб-приложением (с учетом request.getParameter) iii) сообщение отображается на консоли или регистрируется в файле.

Вы можете рассмотреть возможность использования Google Guava или Apache Commons Test, чтобы html избежать ввода. 

import com.google.common.html.HtmlEscapers;

public void testGuavaHtmlEscapers(){
    String badInput = "<script> alert me! <script>";
    String escapedLocation = HtmlEscapers.htmlEscaper().escape(badInput);
    System.out.println("<h1> Location: " + escapedLocation + "<h1>");
}

import static org.apache.commons.text.StringEscapeUtils.escapeHtml4;

public void testHtmlEscapers(){
    String badInput = "<script> alert me! <script>";
    System.out.println(escapeHtml4(badInput));
}

Я бы также подумал, есть ли конфиденциальная информация, которую я должен замаскировать, например, используя String.replace. 

public void testReplace(){
    String email = "some-email@domail.com";
    String masked = email.replaceAll("(?<=.).(?=[^@]*?.@)", "*");
    System.out.println(masked);
}

Выше 3 метода очистки будут работать аналогично.

0 голосов
/ 18 мая 2020

Вероятно, это ложное срабатывание (технически "не может быть использовано" в Checkmarx) в отношении XSS, в зависимости от того, как вы обрабатываете и отображаете журналы. Если журналы когда-либо отображаются в браузере как html, он может быть уязвим для слепого XSS с точки зрения этого приложения, но это будет уязвимость в любом компоненте, отображающем журналы как html, а не в приведенном выше коде.

Вопреки другим ответам, вы не должны кодировать здесь сообщение. Какую бы технологию вы ни использовали для ведения журнала, конечно, необходимо будет правильно кодировать его для собственного использования (например, если оно хранится как JSON, данные должны быть закодированы JSON), но это не имеет ничего общего с XSS или с этой проблемой вообще.

Это просто необработанные данные, и вы можете хранить сырые данные как есть. Если вы закодируете его здесь, вам будет трудно отобразить его другим способом. Например, если вы применяете кодировку html, вы можете отображать ее только в html (или вам нужно декодировать, что сведет на нет любой эффект). В этом нет смысла. XSS возникнет, если вы отобразите эти журналы в браузере - и в этом случае все, что будет отображаться, должно быть правильно закодировано, но здесь дело обстоит не так. Убедитесь, что каким бы способом вы ни хранили журналы, это хранилище журналов ** применяет * необходимую кодировку. Если это текстовый файл, вы, вероятно, захотите удалить новые строки, чтобы фальшивые строки не могли быть добавлены в журнал. Если это json, вы захотите кодировать в json и так далее. Но это особенность вашего журнала, а не приведенный выше код.

0 голосов
/ 08 мая 2020

Вы можете дезинфицировать строки для XSS-атак, используя Jsoup , для этого есть метод clean(). Вы бы сделали что-то вроде этого для дезинфекции ввода: 

String sanitizedInput = Jsoup.clean(originalInput, "", Whitelist.none(), new OutputSettings().prettyPrint(false));
...