Есть ли риск, что в текстовой области будет отображаться необработанный пользовательский ввод? - PullRequest
Новая
       21

Есть ли риск, что в текстовой области будет отображаться необработанный пользовательский ввод?

4 голосов
/ 21 сентября 2011

Я сохраняю две версии пользовательского ввода в следующей последовательности:

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

Есть ли риск загрузки необработанной уценки (которая может содержать небезопасный HTML) в текстовую область?Он никогда не будет отображаться за пределами текстовой области.

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

К вашему сведению: я всегдадезинфицировать SQL независимо от того, что я сохраняю в БД.

Ответы [ 3 ]

3 голосов
/ 21 сентября 2011

Вам не нужно очищать его там, просто позаботьтесь о правильном экранировании специальных символов HTML, таких как <и>.

Например, Stackoverflow позволяет размещать HTML-код в ваших сообщениях, он ничего не удаляет. Это достигается путем кодирования, а не очистки.

1 голос
/ 21 сентября 2011

Зависит от того, как вы «загружаете» его в textarea.Если вы делаете это на стороне сервера с помощью простой конкатенации строк, например, в php, 

$output = '<textarea>' + $markdown + '</textarea>';

... тогда существует абсолютный риск, потому что такая уценка может очень легко закрытьвставлять все, что он хочет.Если вы используете какой-то компонентный каркас (например, ASP.NET), тогда вы должны быть защищены, если вы используете безопасный метод API, такой как MyTextArea.Value = markdown;.

Если выделать это на стороне клиента, это также зависит от того, как вы это делаете.Вы были бы в безопасности, если бы использовали что-то вроде .val() jQuery setter, но могли бы по-прежнему подвергать себя уязвимостям XSS с помощью других подходов.и заполнение textarea.

0 голосов
/ 21 сентября 2011

Вы хотя бы делаете санитарную обработку SQL? Когда вы ВСТАВЛЯЕТЕ или ОБНОВЛЯЕТЕ данные, используете ли вы какой-то тип DAO, который экранирует SQL, или, если вы используете Java, используете Prepared Statement, где вы устанавливаете аргументы?

Вы должны всегда очищать вещи, прежде чем они попадут в БД. В противном случае люди могут добавить шальные 

'); --Malicious procedure here.

.. в запрос.

Существует некоторая угроза безопасности, если оставить незаполненный ввод в текстовом поле; главным образом, если пользователь заражен чем-то, вводящим Javascript, он будет появляться для него каждый раз.

Зачем даже сохранять это? Тогда вы даете своему пользователю совершенно непоследовательное представление о том, что они вводят в то, что отображается? Они не будут совпадать. Лучше всего очистить ввод, чтобы, когда пользователь снова его просматривал, он или она могли ясно видеть , что нарушающий HTML был удален в целях безопасности.

...