2010-06-14 5 views
1

Я хочу включить публикацию комментариев на моей странице, поэтому мне нужно выполнить некоторую кодировку html до того, как сообщение будет отправлено и вставлено в базу данных.Сторона сервера кодирования HTML и сторона клиента

Что является идеальной стороной для этого?
С другой стороны (я работаю с asp.net) или на стороне клиента (javascript)?

ответ

6

Если вы имеете в виду санирование пользовательского ввода, только место, вы можете сделать это безопасно на стороне сервера. Вы не можете быть уверены, что что-то сделано на стороне клиента, слишком легко обойти код на стороне клиента.

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

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

В ASP.Net, если ввод данных, которые вы дезинфицируете, представляет собой строку, которую вы позже собираетесь отображать на странице HTML, и вы хотите убедиться, что она не содержит собственных HTML-тегов, вы можете использовать HttpServerUtility.HtmlEncode для кодирования строки (в основном, поворот < в &lt; и др.).

+0

Итак, если я использую редактор TinyMCE на своей странице, который делает свою собственную кодировку, недостаточно и я должен сделать свою собственную кодировку на стороне сервера? – shivesh

+0

@shivesh: Да, этого недостаточно. Вы не можете доверять, что * любая обработка клиентской стороны была выполнена вообще. Тривиально легко отправить запрос на ваш сервер с незарегистрированными данными, минуя все ваши клиентские вещи, пытаясь взломать ваш сайт. Вы должны рассматривать все входящие данные как подозреваемые.Если данные должны быть закодированы уже, вы можете использовать тот факт, что он не должен указывать на недопустимую активность в соответствующей учетной записи, хотя я немного удивлен (не использую ее), что TinyMCE кодирует вещи перед отправкой их вам. Обычные элементы управления вводами нет. –

+0

Можете ли вы порекомендовать библиотеку для проверки на стороне сервера? Содержание tinymce имеет богатый html, поэтому будет сложно создать что-то, что идеально с нуля. – shivesh

5

Несомненно, определенно серверная сторона. Однако я бы кодировал вход перед выходом в браузер вместо перед входом в базу данных.

Если вы используете ASP.NET MVC, вы можете использовать вспомогательный метод.

<%= Html.Encode("user comment with html in it <script>alert('bad')</script>") %> 

Если вы используете ASP .NET (WebForms или MVC) в рамках NET 4, вы можете использовать новый синтаксис.

<%: "user comment with html in it <script>alert('bad')</script>" %> 
+0

Вы предлагаете мне хранить данные в базе данных, как есть? – shivesh

+0

Да, причина в том, что если вы дезинфицируете входной файл перед его хранением в базе данных, если он подвергся санации неправильно, исходный пользовательский ввод будет потерян, и вы не сможете вернуться и исправить его. Кроме того, скажем, вы, например, хотите вывести комментарий в компонент отчетности, который позволяет и понимает HTML, - здесь вам понадобится неанитированный ввод, но если вы закодируете перед вставкой в ​​базу данных, у вас его не будет. –

+1

Это действительно должен быть принятый ответ. Вы не должны просто слепо доверять тому, что есть в базе данных, и сделать правильное кодирование подозрительных данных на выходе - это самый безопасный способ. – Andy

1

Наверняка вы должны пойти с server side.

Если вы делаете это с клиентской стороны, пользователи могут легко получить шифрование, что вы используете.

Если это серверная сторона. Она должна быть более безопасной.

0

способ сделать это, чтобы сохранить страницы в UTF-8 для любых пользователей могут входить с

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 

в заголовке вывода и сохранить базу данных в кодировке Юникод, а также. Вы никогда не можете быть уверены в том, что пользователи будут вводить.

Каждый стек базы данных также предоставляет средства для предотвращения возможного вредоносного содержимого, например. mysql_real_escape_string Функция MySQL в PHP.

Смежные вопросы