Экранирование html в Java

Как я могу убедиться, что я не побегу что-то дважды?

Я слышал, что его хорошая практика, чтобы избежать значений, как вы получаете их из формы, а также избежать при выходе. Таким образом, у вас есть два шанса что-то поймать.

13
escaping java jsp xss

3 ответов

Я предполагаю, что вы используете JSP.

просто побег во время дисплей только. Там тегов JSTL <c:out> тег идеально подходит. По умолчанию он избегает HTML-объектов. Используйте его для отображения контролируемый пользователем ввод, такой как URL запроса, заголовки запроса и параметры запроса.

Э. Г.

<input type="text" name="foo" value="<c:out value="${param.foo}" />">

экранирование во время ввода не требуется. С XSS не вредит в raw Java код ни в базах данных SQL. С другой стороны, вы также предпочли бы сохранить данные немодифицированными в БД, чтобы вы все еще могли видеть, что пользователь на самом деле введен, так что вы можете при необходимости делать социальные действия на пользователей mailicious.

если вы хотите знать, что, чтобы избежать во время ввода, это будет SQL-инъекций. В таком случае просто используйте PreparedStatement вместо Statement всякий раз, когда вы хотите сохранить любой пользователь-управляемый ввод в базе данных.

Э. Г.

create = connection.prepareStatement("INSERT INTO user (username, password) VALUES (?, MD5(?))");
create.setString(1, username);
create.setString(2, password);
create.executeUpdate();
18

вы должны только HTML-код кодировать, когда вы выводите что-то в браузер. Это предотвращает атаки XSS. Тип экранирования, который выполняется при сборе данных из формы перед вставкой в базу данных, -не кодировка html. Он экранирует специальные символы базы данных (лучше всего использовать параметризованные запросы). Целью этого является предотвращение атак SQL-инъекций. Так что никакого двойного кодирования не происходит.

3

содержимое, безвредное в одном контексте, может быть опасным в другом контексте. Лучший способ избежать инъекционных атак-подготовить контент перед его передачей в другой контекст. В вашем случае html-текст меняет свой контекст, когда он передается в браузер. Сервер не отображает html, но браузер делает это. Поэтому не забудьте передать вредоносный html в браузер и замаскировать его перед отправкой.

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

2