Comments 48
Обычно эти символы заменяются последовательностями > и $lt;
Вообще-то, & lt; и & gt;
Двойные кавычки — & quot;
Одинарные — & #039;
P.S. Поставил пробелы после &, иначе не отображался код.
< и > — отличный пример, почему следует использовать markdown
markdown — это расширение подмножества HTML. Там точно так же можно использовать тэги — а значит, нужно точно так же экранировать служебные символы...
При чем тут это вообще? Я говорю о том, что нужно использовать markdown, просто потому что это удобно.
Ну и если уж на то пошло (и если вам так нравится занудство), то markdown — это самостоятельный язык разметки, а ни какое не подмножество html. Он прекрасно конвертируется в word, pdf, rich-text и еще 100500 других форматов документов, без промежуточной компиляции в html. А то, что в нем можно писать теги — это побочный эффект частных реализаций компиляторов/конвертеров в HTML. Спецификация же по конвертированию markdown в HTML называется CommonMark.
Я не говорил, что он является подмножеством HTML (это, конечно же, не так!). Но он является расширением некоторого подмножества HTML. Иными словами, внутри markdown-разметки можно использовать html-тэги.
Кажется, начался язык с вот этого проекта: https://daringfireball.net/projects/markdown/.
И вот что там сказано в докумментации:
For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.
Похоже проблема в понимании того, что есть суть markdown. Изначально:
Markdown is a text-to-HTML conversion tool for web writers.
И да, если рассматривать markdown как конвертер текста в html, то вы правы.
Однако, я смотрю на markdown шире, и мне больше нравится определение из википедии:
Markdown is a lightweight markup language with plain text formatting syntax.
В этом случае тэги и их наличие/отсутствие в тексте вообще не при чем. Для меня это просто текст.
А вместо этого даже конвертеры из markdown в тот же word или pdf эти самые тэги обрабатывают как разметку.
Обработать их он должен. На входе <i>Hello, world!</i>, на выходе — картинка с надписью курсивом.
А с тегом input он что будет делать? А с тегом video?
В некоторых реализациях даже script впихнуть можно.
Но это именно фишка реализаций. Ладно, не будем сильно с ума сходить. Что делать с банальным атрибутом class и тегом style? Я бы с удовольствием посмотрел как анимация css в распечатанном договоре воспроизводится.
Кстати, толковый md2html-преобразователь инпуты, классы и особенно скрипты тоже должен вырезать.
Кстати, толковый md2html-преобразователь инпуты, классы и особенно скрипты тоже должен вырезать.
Самая популярная спека по md2html (CommonMark)
утверждает, что class, id и прочие аттрибуты — это норм. http://spec.commonmark.org/0.27/#example-119
Имхо, экранирование, вырезание тегов и прочее — это уже забота пурифайера, правила которого описываются конечным пользователем отдельно. А конвертер пусть занимается конвертированием.
Но не все браузеры его вразумеют, лучше пользовать '. Весь список.
Вдумайтесь! Функция для защиты от XSS, которая сама по себе подвержена XSS! :-)
И вообще, я на PHP не пишу, но неужели там нет нормального шаблонизатора, как в питониевых фреймворках вроде django? А то обернуть в функцию можно и забыть…
А вообще, мне больше нравится подход ангуляра. На Пикабу я находил xss, позволяющий изменить аттрибут, т.е. экранировались < >, но не ", поле в форме было короткое, но всё же можно было сделать инъекцию вроде
"onmouseover="javascript code goes hereВ ангуляре не нужно делать ровным счётом ничего, он с помощью джаваскриптовой магии предотвратит инъекцию.
Есть в PHP нормальные шаблонизаторы. Например twig по умолчанию экранирует все. Ему нужно в явном виде указать если какую-то сущность не нужно экранировать.
Правда проблему с экранированием атрибутов, описанную в статье, он не решает по понятным причинам. Но атрибуты лучше вообще вырезать или использовать белые списки.
Тот PHP, на котором я хоть что-то писал, это была ещё 5 версия или даже меньше — костыль, это не шаблонизатор, нормальный шаблонизатор защищает от XSS без костылей и позволяет писать код удобно и отделять логику от вывода. Но я могу предположить, что всё сильно изменилось и на PHP можно писать, как и на нормальных языках, потому и спрашиваю.
Для менее квалифицированных и дисциплинированных лучше подобрать готовые шаблонизаторы и фреймворки
Речь не о квалифицированности, можно и на C писать всё с нуля, но никто этого не делает, т.к. скорость разработки важнее. В Google работают очень квалифицированные специалисты, но YouTube сделан на ангуляре, потому что это быстрее и удобнее, чем писать с нуля.
Вы сравниваете код, который «можно написать самому» с кодом, который точно также кто-то написал сам и предоставил в пользование другим. При этом говорите, что второй вид кода для менее квалифицированных и дисциплинированных, и гарантий не дает. Из чего следует, что первый вид качественнее и дает больше гарантий. Чтобы проверить, действительно ли это так, нужно поставить оба варианта в одинаковые условия — а именно открытый доступ для анализа. Иначе это необоснованное утверждение в стиле «так лучше, правда-правда», то есть силы не имеет, и доверять ему нельзя.
Я говорю про ваше утверждение, что фреймворки нужны для менее квалифицированных и дисциплинированных. Это не так. Для их использования есть и другие причины, кроме «если квалификация не позволяет». А также я говорю, что в большинстве случаев квалификация одного будет меньше квалификации многих, соответственно, в самописном коде больше вероятность ошибки или уязвимости. Вы говорите, что это не так, потому я и предложил вам показать ваш самописный код. Не хотите, ну ок, просто вы не подтвердили слова делом. Как к этому относиться, сами решайте, и другие тоже для себя решат.
начав при этом требовать что-то от меня
Я ничего от вас не требовал, а только попросил. Вернее даже спросил. А вы почему-то начали ёрничать.
Лучше — это не синоним «нужны только»
А я и не говорил "нужны только".
Я сказал «для менее квалифицированных и дисциплинированных лучше подобрать»
Из чего следует, что для хорошо квалифицированных и дисциплинированных больше подходит обратный вариант — писать код и шаблонизацию самому. А это не так.
И по поводу наездов. Это вы высказываете необоснованные негативные характеристики по поводу фреймворков и тех, кто ими пользуется. Все эти "навелосипедили", "забабахать", "велосипедов-фреймворков", "взять чужое, если квалификация не позволяет". Почему вы считаете, что вам можно делать наезды?
Ничего подобного не следует, тут не булевая логика
Слово "лучше" это сравнительная степень. Она подразумевает 2 варианта, которые сравниваются. "Что-то" лучше, чем "что-то". Ну ок, будем считать, что "можно написать самому код" не относится к левой части утверждения.
Вам это показалось, потому что вы желаете видеть это в моих словах.
То есть вы отрицаете, что у указанных слов есть всем известный негативный оттенок? Если нет, значит мне не показалось.
Говорится с неодобрением, с ироническим оттенком.
в целом передаёт стереотипное представление о дилетантском подходе к какому-л. занятию.
2. В отношении своего кода никто вам не запрещает говорить что угодно. А вы необосновано употребили слова с негативным смыслом в отношении работы других.
Про код для обучения с таким смыслом не говорят, потому что причины его написания понятны.
Если фреймворки полезны всем — то зачем вы особо отметили малоквалифицированных?
Книга «Безопасность в PHP» (часть 3). Межсайтовый скриптинг (XSS)