Может ли стандартная проверка JSF предотвратить внедрение кода?
В моем проекте Я делаю повторную проверку на уровне представления, а также на уровне постоянства с надеждой повысить безопасность. Поэтому мой вопрос: может ли стандартная проверка JSF предотвратить внедрение кода.
<h:inputText id="name" value="#{bean.customer.name}" required="true" requiredMessage="Validation Error: Value is required." title="Name" >
<f:validateLength maximum="40"/>
</h:inputText>
Здесь я проверяю, является ли поле пустым, и проверяю длину поля. Я знаю, что проверка длины поля усложнит внедрение кода, но иногда вам нужна большая длина поля, например textArea . И если это уязвимо, как я это исправлю? Заранее большое спасибо.
2 ответа
JSF по умолчанию уже предотвращает XSS атаки, избегая пользовательского ввода в компонентах UIInput и UIOutput. Это можно контролировать в h:outputText, установив атрибут escape="false". Вам не нужно беспокоиться об этом.
С другой стороны, JSF не несет ответственности за предотвращение атак SQL-инъекций . Вам нужно обработать это на уровне персистентности. Например, JPA и/или Hibernate при правильном использовании (т. е. не объединять управляемый пользователем ввод в строках SQL/именованных запросов) также по умолчанию уже предотвращают это. В простом ванильном JDBC вам необходимо убедиться, что вы используете PreparedStatement вместо Statement для включения пользовательского ввода в строку SQL. При правильном использовании вам также не нужно беспокоиться об этом на стороне JSF.
Вопросы по теме:
Атаки с внедрением имеют одну общую тему: входные данные преобразуются и интерпретируются как код в определенный момент времени из-за различных недостатков в приложении. Наиболее часто наблюдаемая ошибка — это непроверенная информация, которая неправильно закодирована или экранирована. Наличие или отсутствие кодирования само по себе не защищает приложение от атак — символы, позволяющие преобразовывать код в данные, должны быть закодированы, чтобы их нельзя было распознать как код.
Теперь, с точки зрения JSF, разработчики позаботились о том, чтобы включить защиту от определенных видов атак. Поскольку это инфраструктура уровня представления, защита от XSS-атак (и CSRF-атак, хотя она и не связана с внедрением) присутствует. Механизмы защиты и их безопасное использование подробно рассматриваются на страницах фреймворка Seam Межсайтовый скриптинг и Подделка межсайтовых запросов. Seam использует JSF, поэтому нет большой разницы в защите приложения JSF и приложения Seam от XSS и CSRF; большинство советов на этих страницах должны оставаться в силе в приложении JSF.
Однако, если вам нужно защитить себя от других известных атак с внедрением, особенно с внедрением SQL, вам необходимо изучить функции, предлагаемые вашей структурой сохраняемости (при условии, что вы будете ее использовать). Если вы пишете SQL-запросы вручную и выполняете их непосредственно в своем коде, используйте объекты PreparedStatement, чтобы защитить себя от наиболее распространенных разновидностей SQL-инъекций. Если вы используете JPA, JDO и т.вам нужно подумать о безопасном использовании таких фреймворков — большинство из них создают объекты PreparedStatement по умолчанию, когда к ним передаются запросы, поэтому часто не о чем беспокоиться.
Защита от SQL-инъекций в JPA
Именованные и собственные запросы будут внутренне преобразованы в подготовленный оператор, использующий параметризованные запросы. Это ответственность поставщика JPA. Нужно будет беспокоиться о SQL-запросах, которые создаются перед передачей поставщику. По сути, строки, передаваемые в EntityManager.createQuery() и EntityManager.createNativeQuery(), не должны объединять пользовательский ввод.
PS: Функция защиты от CSRF присутствует в JSF 2, а не в JSF 1.x. Он также присутствует только в некоторых выпусках Seam (начиная с 2.1.2).