Может ли стандартная валидация JSF предотвратить внедрение кода? - PullRequest
Новая
       69

Может ли стандартная валидация JSF предотвратить внедрение кода?

9 голосов
/ 25 августа 2010

В моем проекте я проверяю дубликаты на уровне представления, а также на уровне постоянства с надеждой повысить безопасность. Поэтому мой вопрос: может ли стандартная проверка 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 ]

13 голосов
/ 25 августа 2010

JSF по умолчанию уже предотвращает XSS атаки , избегая ввода, управляемого пользователем, в компонентах UIInput и UIOutput. Это можно контролировать в h:outputText, установив атрибут escape="false". Вам не нужно беспокоиться об этом.

Защита от SQL-инъекций атак , с другой стороны, не входит в обязанности JSF. Вы должны обработать это в постоянном слое. Например, JPA и / или Hibernate, при правильном использовании (то есть не объединяет управляемый пользователем ввод в SQL / именованные строки запроса), также по умолчанию уже предотвращает это. В обычном ванильном JDBC вам нужно убедиться, что вы используете PreparedStatement вместо Statement для включения контролируемого пользователем ввода в строку SQL. При правильном использовании вам также не нужно беспокоиться об этом на стороне JSF.

Похожие вопросы:

8 голосов
/ 25 августа 2010

Инъекционные атаки имеют одну общую тему: входные данные преобразуются и интерпретируются как код, в какой-то момент времени из-за различных недостатков в приложении. Наиболее часто наблюдаемый недостаток заключается в том, что неанализованные данные неправильно кодируются или экранируются. Наличие или отсутствие только одной кодировки не защищает приложение от атак - символы, которые позволяют преобразовывать код в данные, должны быть закодированы, чтобы они не различались как код.

Теперь, с точки зрения 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).

...