Как сделать безопасным код сайта на Битрикс: шпаргалка по основным уязвимостям

[juliaaan1]

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

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

Вот давайте по порядку:

• Защита от XSS через два разных способа, которые под капотом ссылаются на одно и то же. Зачем? Достаточно и последнего, через HtmlFilter.

• Пример XSS с одинарными кавычками работает так же, как и с двойными. Можно было разве что упомянуть, что стандарты HTML рекомендуют использовать двойные кавычки, но это вне рамок данной статьи.

• Вы упоминаете про прямые запросы к БД, в то время как в своей же документации говорите, что это "нежелательно". Ну так не учите людей неправильному, global $DB должен быть позабыт как страшный сон.

• Прошу вас, удалите из статьи все прямые запросы к своим таблицам. Особенно к b_user. Люди правда так делают, читая это.

• Зачем в примерах ORM-запросов вы использете DM-классы из Internals? Опять таки, люди посмотрят и будут делать так же.

Половину статьи рекомендую заменить на фразу "не доверяйте пользовательскому вводу, валидируйте его", вторую половину статьи на "все, что выводится на экран из БД, должно быть экранировано". Между этими двумя частями напишите "используйте ORM".

Все, вы восхитительно!

Но вообще, конечно, спасибо, что делаете хоть что-то.

[sabramovskikh]

Статья все же как сделать безопасными данные, а не про методы взлома и починки.

По вашим пунктам:
2. htmlspecialcharsbx по умолчанию имеет флаг ENT_COMPAT, поэтому одинарные он оставим, это сломает вывод

3. Прямые запросы нежелательно, но не значит что их нельзя использовать.

[VYZasorin]

Почему вы считаете, что прямые запросы использовать совсем нельзя? Иногда бывают такие запросы, которые иначе не выполнить. Например, это может быть связано с тем, что у Битрикса при некоторых выборках используется группировка по полю и если вам нужно сложить значения строк, то иначе никак. Тут можно сказать, что просто нужно выбрать другой способ хранения данных, но архитектура - это компромисс. И ничего страшного в том, чтобы редко такие запросы использовать, нет.

В целом понимаю вашу боль, но она связана с низкой компетенцией коллег, а не примерами.