Комментарии 12
В пункте по XSS я почему-то не вижу рекомендации использовать защищенные by desing технологии и без особых причин не формировать HTML-разметку конкатенацией строк или шаблонными строками.
Все так. Защищенные by design технологии мы вынесли в общие рекомендации — это можно везде добавить.
Можно было бы еще добавить, что в разных веб-фреймворках для подобных задач есть специальные методы, которые делают это безопасно. Например, в Spring MVC — класс HtmlUtils, который содержит пачку утилитных функций для работы с HTML.
Можно было бы еще добавить, что в разных веб-фреймворках для подобных задач есть специальные методы, которые делают это безопасно. Например, в Spring MVC — класс HtmlUtils, который содержит пачку утилитных функций для работы с HTML.
В таком случае список "проверенных фреймворков" лучше бы сократить. Например, ASP.NET WebForms к XSS как раз очень уязвим, в отличии от использующих Razor ASP.NET MVC и ASP.NET Core
Признаком кривого дизайна как раз и являются HtmlUtils и подобные им "безопасные" способы работы с HTML.
Про ASP.NET MVC и ASP.NET Core уточнили в тексте, спасибо. Конечно же, мы имели в виду _современные_ фреймворки.
Про HtmlUtils — да, возможно, не самый удачный пример здесь. В тексте статьи только универсальное, либо проверенное на собственном опыте. Поэтому, конечно, не все возможные случаи рассмотрены.
Про HtmlUtils — да, возможно, не самый удачный пример здесь. В тексте статьи только универсальное, либо проверенное на собственном опыте. Поэтому, конечно, не все возможные случаи рассмотрены.
Для большинства браузеров отключить автозаполнение можно атрибутом autocompete="off", например:
Только вот в хроме это же не работает. Там всякие пляски с таймаутами и скрытыми полями начинаются.
Напишите пожалуйста список ip адресов, с которых Вы делаете сканирование, для их блокировки. Это не Ваши?
162.243.129.195
162.243.137.75
162.243.144.8
162.243.144.72
162.243.139.14
162.243.140.191
162.243.145.80
162.243.144.212
185.198.57.144
162.243.136.216
162.243.143.219
185.198.59.123
162.243.129.195
162.243.137.75
162.243.144.8
162.243.144.72
162.243.139.14
162.243.140.191
162.243.145.80
162.243.144.212
185.198.57.144
162.243.136.216
162.243.143.219
185.198.59.123
Мы не совсем поняли, в каком контексте этот вопрос?
Если Вы сканируете другие сайты, то хотел внести Ваши ip адреса в список блокировки своего WAF
Мы сканируем только наших клиентов и только по их предварительному согласию. Все обязательно фиксируется документально.
Весь процесс по шагам описали на нашем сайте.
Весь процесс по шагам описали на нашем сайте.
Наилучшей практикой считается Inline code: разрешите только inline javascript с помощью значения unsafe-inline.
Это весьма плохой совет. Опция не просто так называется «Unsafe».
Внешние скрипты действительно нельзя будет подгрузить, но совершенно ничего не помешает в случае отраженной/хранимой XSS выполнить инлайн вредоносный код.
Если от unsafe-inline отказаться не получается, хорошим компромисом будет использование случайных nonce.
Про SQL-инъекции:
Эта рекомендация не сработает в тех случаях, когда атакующий пользуется прокси, через которую может перехватывать и изменять запросы — в таком случае проверка на клиентской стороне просто не сработает.
Опираться в защите от SQL-инъекций всё же следует на серверной стороне — фильтрация, кодирование опасных символов и другие способы.
На стороне клиента напишите проверку полей с помощью JavaScript.
Эта рекомендация не сработает в тех случаях, когда атакующий пользуется прокси, через которую может перехватывать и изменять запросы — в таком случае проверка на клиентской стороне просто не сработает.
Опираться в защите от SQL-инъекций всё же следует на серверной стороне — фильтрация, кодирование опасных символов и другие способы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Смертные грехи безопасности сайта: что мы узнали из статистики сканера уязвимостей за год