Избавьтесь от сущностей HTML в JSP / JSPX: нет решения проблемы, которая не должна существовать? - PullRequest
Новая
       12

Избавьтесь от сущностей HTML в JSP / JSPX: нет решения проблемы, которая не должна существовать?

13 голосов
/ 04 мая 2011

Мы используем jspx в качестве движка шаблонов. У нас есть дюжина экранов с сотнями выражений el, таких как $ {user.firstName} или "$ {mail.subject}"

И весь этот HTML-код по умолчанию не экранирован. Если с полем <или "будет что-то в поле - экран не получится. Мы всегда можем использовать fn: escapeXml, но делать это во всех местах очень скучно. </p>

1) Есть ли способ сделать escape по умолчанию?

Единственный способ, которым я знаю, - это взломать JSP-компилятор (например, jasper для tomcat). Но это не путь.

2) Почему кому-то может понадобиться неэкранированный HTML в el? Хранение HTML вне шаблона (например, в базе данных) не является хорошей практикой.

3) Я уверен, что шаблонизатор должен обрабатывать его автоматически (как это было сделано в XSLT), почему пользователь должен заботиться об этом? Ручное экранирование (fn: escapeXml) пахнет как ручное экранирование SQL (которое используется вместо JDBC setParam): шаблонный код и хорошее место для sql-инъекций (в нашем случае межсайтовый скриптинг).

Ответы [ 2 ]

11 голосов
/ 04 мая 2011

1) Есть ли способ сделать escape по умолчанию?

Нет в винтажном JSP.Однако преемник Facelets избегает их по умолчанию.Единственный способ отключить экранирование - это использовать <h:outputText value="#{bean.foo}" escape="false" /> вместо #{bean.foo}.

2) Почему кому-то может понадобиться неэкранированный HTML в el?Хранение HTML вне шаблона (например, в базе данных) не очень хорошая практика.

Хранение санитарная обработка HTML, однако, более чем обычно делается.Например, разрешить небольшое подмножество невинных тегов HTML, таких как <p>, <b>, <i> и т. Д., Из которых атрибуты on* уже удалены.

3) Я уверен, что шаблонизатор должен обрабатывать его автоматически (как это делается в XSLT), почему пользователь должен заботиться об этом?Ручное экранирование (fn: escapeXml) пахнет как ручное экранирование SQL (которое используется вместо JDBC setParam): шаблонный код и хорошее место для sql-инъекций (в нашем случае межсайтовый скриптинг).

JSP - древняя технология просмотра.Это не очень гибкий шаблонный движок.

Инъекции SQL обычно следует предотвращать, просто используя PreparedStatement вместо Statement (или используя ORM-фреймворк вместо «raw JDBC», как, например, проблему XSS можно предотвратить, просто используяMVC Framework вместо «raw JSP»).

Что касается вашей конкретной проблемы, вы можете решить ее в основном 4 способами:

  1. BiteОтметьте и замените весь текст EL-in-template, который отображает контролируемый пользователем ввод на fn:escapeXml() или <c:out>, и научите себя и свою команду обращать на это внимание в будущем.Подсказка, у немного приличной IDE, такой как Eclipse, есть поиск и замена во всех файлах на основе регулярных выражений.

  2. Имеет своего рода перехватчик БД, который удаляет вредоносный HTML перед вставкой в ​​БД.При необходимости запустите сценарий БД для очистки существующих данных.Однако это скорее обходной путь, чем реальное решение.

  3. Замените распознаватель JSP EL на собственный, который экранирует весь HTML.Однако это имеет тот недостаток, что вы никогда не сможете отображать простой HTML с помощью EL, когда это действительно необходимо.

  4. Используйте приличную инфраструктуру MVC со встроенным экранированием HTML.Однако это больше, чем просто исправление отдельных выражений EL.

7 голосов
/ 11 января 2013

Да, по умолчанию возможно экранирование всех EL-выражений. Это можно сделать, зарегистрировав пользовательский ELResolver . Посмотрите, например, на этот сайт пример того, как это можно сделать: http://pukkaone.github.com/2011/01/03/jsp-cross-site-scripting-elresolver.html

...