Я должен санировать скидку с цены?
Единственное преимущество I видит к максимальной длине пароля, должен был бы устранить риск атаки переполнения буфера, вызванной чрезмерно длинным паролем, но существуют намного лучшие способы обработать ту ситуацию.
3 ответа
Markdown может содержать произвольный HTML; это явно разрешено. Так что вам также следует очистить его или, по крайней мере, очистить результат преобразования его в HTML перед отправкой веб-клиентам.
Я помню, что один из эксплойтов, возможных с SO в первые дни, заключался в том, что вы могли помещать JS-контент в Markdown, и тот, кто редактировал вашу статью, запустит эти сценарии в предварительном просмотре. Я еще не знаю, исправлено ли это.
Я заметил, что вы «дезинфицируете HTML перед сохранением в db» и говорите о xss-safe в следующем предложении. Это два разных аспекта проверки ввода, и вы не должны смешивать их и учитывать оба в своем дизайне:
Вы должны безопасно вставлять любой пользовательский ввод в базу данных, т.е. убедитесь, что ввод правильно экранирован (mysql_real_escape_string, хранится процедуры, библиотеки ORM и т. д.)
Вы должны безопасно выводить в HTML / JS (включая ввод в WMD), удаляя или экранируя любые последовательности, которые могут быть превращены в эксплойты XSS и другие неприятности.
Что касается вопроса, Я согласен с Крисом - поскольку Markdown может включать HTML, его необходимо очистить.
Просто дополнение:
Этот вопрос возник из-за использования WMD