Оптимизация NGINX
Оптимизация веб сервера nginx позволит вам ускорить ваш сайт, сократив время ответа сервера.
Nginx это отличный веб-сервер, который уже давно зарекомендовал себя, как надежное решение даже для больших проектов. Несмотря на то, что nginx отлично работает из коробки, рекомендую проделать некоторые настройки по оптимизации, которые уменьшат время ответа сервера.
Не забывайте, что после внесения изменений необходимо проверять их корректность командой:
А чтобы применить настройки, необходимо перезапустить nginx:
Сжатие GZIP
gzip включает сжатие.
gzip_min_length устанавливает минимальную длину ответов, для которых будет применяться сжатие. По умолчанию 20, но имеет смысл поставить больше, так как постоянное сжатие приведет к повышению нагрузки на процессоры сервера и клиента.
gzip_proxied перечисляет параметры проксированных запросов, для которых будет разрешено сжатие.
gzip_types по умолчанию включено сжатие для ответов типа текст. В данном параметре можно перечислить все необходимые типы ответов.
gzip_disable запрещает для перечисленных параметров заголовка User-Agent сжатие. В данном примере для Internet Explorer 6 сжатие применяться не будет, так как данный браузер не умеет принимать сжатые ответы.
Кэширование
Оптимизация работы соединений
Настроим несколько основных параметров, которые отвечают за количество обрабатываемых соединений и сроки их поддержания.
Оптимизация работы с файлами
sendfile позволяет использовать более совершенный системный вызов, который обеспечивает прямую передачу файла, то есть без системных вызовов read + write.
aio включает использование асинхронного обращения к файлам, что избавит от очередей запросов.
tcp_nopush позволит передавать заголовок ответа и начало файла в одном пакете.
open_file_cache по умолчанию выключена. Задает настройку для кэширования информации о файлах, с которыми работает nginx. По умолчанию выключено.
open_file_cache_valid задает время, через которое веб-сервер будет проверять актуальность данных. По умолчанию 60 секунд.
open_file_cache_min_uses задает минимальное число обращений к файлу, чтобы дескриптор файла оставался открытым в кэше.
open_file_cache_errors включает или выключает кэширование ошибок.
Безопасность
Помимо уменьшения времени отклика веб-сервера, необходимо позаботиться о безопасности. Разберем основные http заголовки, которые могут представлять угрозу.
X-XSS-Protection
Заголовок X-XSS-Protection может предотвратить некоторые XSS-атаки.
Вы можете реализовать защиту XSS, используя три варианта в зависимости от конкретной потребности.
X-Frame-Options
Заголовок X-Frame-Options позволяет снизить уязвимость вашего сайта для clickjacking-атак. Этот заголовок служит инструкцией для браузера не загружать вашу страницу в frame/iframe. Не все браузеры поддерживают этот вариант.
Настроить X-Frame-Options можно тремя способами:
X-Permitted-Cross-Domain-Policies
Аналогично механизму браузеров блокировки стороннего контента Adobe Flash имеет свой. Он регулируется файлами crossdomain.xml сайта, начиная с корневого каталога. Проблема с механизмом в том, что на любом уровне вложенности корневой регулирующий файл (политика безопасности) может быть переопределен. Чтобы избежать таких ситуаций, необходимо задать этот HTTP-заголовок.
Доступно несколько вариантов настройки:
Strict-Transport-Security
Заголовок Strict-Transport-Security запрещает использование незащищенного HTTP соединения на сайте, если есть защищенное HTTPS.
X-Content-Type-Options
Рейтинг наиболее опасных к использованию возможностей браузера возглавляет возможность Internet Explorer «угадывать» тип файла, игнорируя его MIME-тип.
При передаче от сервера к браузеру все файлы имеют тот или иной тип, который прямо указывает на суть содержимого файла. Однако, Internet Explorer имеет встроенный механизм, который позволяет по-содержимому файла переопределить его тип.
Подводя итог
Вот и все, потратив немного своего времени, вы ускорили загрузку вашего сайта для клиентов, а также немного обезопасили его от некоторого вида атак.
Межсайтовый скриптинг и как защитить сайт от XSS атаки
Использование заголовков безопасности является важным звеном в защите сайта и его посетителей от хакерских атак. В прошлой статье про HTTP-авторизацию из рубрики по защите и безопасности я обещал регулярно публиковать записи на эту тему. Сегодня я расскажу про защиту от XSS атаки.
Что такое XSS-атака
Межсайтовый скриптинг (Cross Site Scripting) — это уязвимость, которая позволяет злоумышленнику внедрить вредоносный код (обычно HTML или JavaScript) в содержимое сайта. Вредоносный код выполняется в браузере пользователя, который просматривает зараженную страницу сайта.
Злоумышленники могут эксплуатировать различные уязвимости. Наибольшее распространение получили два типа атаки:
Отражённая XSS-атака
Срабатывает при переходе пользователя по специально подготовленной ссылке, которая отправляет запрос на сайт с уязвимостью. Данная уязвимость обычно является результатом недостаточной фильтрации входящих запросов, что позволяет манипулировать функциями и активировать вредоносные скрипты.
Для распространения вредоносной ссылки могут использоваться различные каналы связи: электронная почта, комментарии на сайте, сообщения в социальных сетях. Анкорные ссылки чаще провоцируют пользователей на клик.
Хранимая XSS-атака
Для успешного выполнения хранимой атаки злоумышленнику достаточно найти уязвимость на сайте и разместить на своём сервере вредоносный скрипт. Затем на сайте размещается тег
© 2010-2021 Копирование запрещено в соответствии с Пользовательским соглашением
Улучшение безопасности сайта Django с помощью заголовков запросов
Это версия статьи для блога, моей презентации который я делал на DjangoCon Europe 2019 10 апреля.
Веб представляет собой развивающуюся платформу с множеством проблем с обратной совместимостью. Новые методы веб-безопасности часто приходят от осознания того, что у старого функционала есть некоторые недостатки. Вместо того, чтобы нарушать работу старых сайтов, изменяя проблемный функционал, есть множество более безопасных вариантов развития. Вы можете улучшить безопасность сайта с помощью модификации заголовков HTTP.
Securityheaders.com — инструмент, созданный консультантом по безопасности Скотт Хелм для сканирование и создания отчета о безопасности на основе заголовков запросов. Он дает любому URL оценку от F до A +, что является хорошим и простым способом оценки состояния безопасности вашего сайте. Хотя, как и в случае любого другого автоматизированного отчета, для его оценки требуется некоторая человеческая интерпретация.
(Я бы также порекомендовал сканер безопасности Mozilla Observatory, но в этой статье я его не использую, потому что он проводит проверку по гораздо большим числом параметров чем просто заголовки запросов.)
Например, Yahoo получает оценку A + на Securityheaders.com:
А Google на момент написания статьи набрал только C:
Это статья о том, как настроить типичное веб-приложение Django для оценки этого сканера. Вы можете легко, защитить своих пользователей и произвести впечатление на своего босса или клиентов!
В этой статье мы рассмотрим 6 заголовков, которые нужно установить, чтобы набрать A+ (на момент написания статьи). Так же, мы рассмотрим бонусный экспериментальный седьмой заголовок …
1. X-XSS-Protection
Межсайтовый скриптинг (Cross-Site Scripting), или XSS, — это метод, который злоумышленники могут использовать для внедрения своего собственного кода на ваш сайт. С помощью этого вида атаки можно например, добавить ложный контент или шпионить за пользователями, чтобы украсть их пароли.
Поскольку XSS является таким распространенным видом уязвимости веб-сайтов, браузеры добавили функции для его обнаружения и предотвращения в некоторых случаях, включенные в их «XSS Auditors». По умолчанию они включены, поэтому блоки скриптов, которые выглядят как атаки XSS, блокируются, но при этом страница продолжает работать.
Настройка заголовка X-XSS-Protection для использования «block mode» обеспечивает дополнительную безопасность. Это настройка указывает браузеру полностью блокировать страницы с обнаруженными атаками XSS, в случае, если они содержат другие проблемные элементы. Например, см. демонстрацию атаки Скотта Хельма, где HTML отправляется в GET-параметре и появляется на странице, которая затем блокируется.
Этот заголовок обеспечивает дополнительную защиту сайта. Даже если ваш веб-сайт защищен от XSS, если он запускает XSS auditor браузера, его все равно следует использовать, чтобы избежать этот тип атаки.
В Django уже встроенный этот параметр, и его легко активировать. Вы так же можете увидите предупреждение security.W007 при запуске команды manage.py check —deploy, если этот параметр не активирован.
ВключениеX-XSS-Protection:
Больше информации смотрите в документации Django, например, предостережения о медиа-файлах.
2. Strict-Transport-Security
HTTP Strict Transport Security, или HSTS, — это способ указать браузеру загружать ваш сайт только по HTTPS. Когда браузер увидит этот заголовок на веб-сайте, он будет отправлять только HTTPS-запросы. Так же в заголовке указывается максимальный срок хранения в секундах, который ограничивает время, в течение которого браузер будет помнить об этом. Это параметр предотвращает перехват HTTP-запросов злоумышленником или посредником AITM для предоставления вредоносного контента в вашем домене.
Вместе с задание заголовка Strict-Transport-Security со значением max-age, вы можете установить еще пару флагов:
В настоящее время некоторые домены верхнего уровня TLD (top—level domain), такие как .app, сами preloaded, что означает, что они поддерживают только HTTPS-сайты.
Опять же, этот заголовок уже встроен в Django. Вы увидите предупреждение security.W004, если не установили максимальный возраст, security.W005 при отсутствие флага includeSubDomains или security.W021 при отсутствие флага preload.
Включение Strict-Transport-Security:
Предупреждение. Этот параметр не совсем тот, который вы можете просто включить не задумывая о последствиях, особенно если у вас используются субдомены! По этому поводу даже говориться в документации Django security.W004:
… небрежное включение HSTS может вызвать серьезные, необратимые проблемы
Если вы преждевременно активируете его, вы заблокируете пользователей, выполняющих обычные HTTP-запросы. Браузер начнет блокировать их, пока вы не удалите этот параметр в заголовке и не истечет максимальное количество секунд.
Поэтому вы должны постепенно увеличивать SECURE_HSTS_SECONDS, проверяя, что ничто не ломается. Делайте это в течение нескольких дней, проверяя обратную связь с вашими пользователями. Начните с чего-то небольшого, например, 30 секунд, и добавляйте до 31536000 секунд (то есть 1 год).
Добавление флагов так же зависит от вашей ситуации. Если его не имеет смысла включать, отключите соответствующее предупреждение с помощью SILENCED_SYSTEM_CHECKS.
Для получения дополнительной информации см. Документацию Django HTTP Strict Transport Security.
3. X-Content-Type-Options
Браузеры пытаются угадать тип содержимого ответов, если сервер, отправляет неправильный ответ браузер пытается распознать его — эта функция, называемая MIME Sniffing. Иногда, если браузер не может угадает правильный тип контента это может приводить к ошибкам. Например, если загруженное пользователем изображение на вашем сайте интерпретируется как HTML, в итоге становиться возможным проведение XSS атаки.
Первоначально у каждого браузера были свои правила определение контента, они были приведены в соответствие со спецификацией WHATWG.
Установка заголовка X-Content-Type-Options на nosniff выключает автоопределение контента MIME Sniffing (в большинстве случаев). Так как хорошо построенный веб-сайт не нуждается в таком функционале, вы всегда должны использовать nosniff.
Этот заголовок также встроен в Django, и вы увидите предупреждение security.W006, если вы его не включили.
Включение X-Content-Type-Options:
Больше информации смотрите больше в документации по Django X-Content-Type-Options.
4. X-Frame-Options
Clickjacking — это метод, при котором злоумышленник обманывает вашего пользователя, заставляя его щелкнуть на что-то на вашем сайте. Обычно это делается путем встраивания вашего сайта в на сайте злоумышленника.
Например, см. пост в блоге Троя Ханта. В нем описывается банковское приложение, прозрачно размещенное в рамке перед кнопкой «Win an iPad». Когда пользователь пытается получить приз, он нажимает кнопку «перевести деньги» на веб-сайте банка.
Существуют различные методы предотвращения clickjacking, но лучше всего добавить параметр X-Frame-Options в заголовке. Это позволит отключить ваш сайт в случае использование его в или только в списке разрешенных доверенных доменов.
Этот заголовок также встроен в Django. Вы увидите предупреждение security.W002, если у вас нет middleware, или security.W019, если у вас значение этого параметра не установлено в DENY.
Включение X-Frame-Options:
Существуют дополнительные параметры для включения определенных доменов в вашего сайта или для отключения защиты для определенных вьюх. Смотрите подробнее в документации по Django Clickjacking Protection.
5. Referrer-Policy
Заголовок Referer сообщает веб-сайту URL-адрес, с которого пришел пользователь. Это отлично подходит для аналитики, так как вы можете узнать, откуда приходят посетители вашего сайта, анализируя это значение.
Но это также ужасно с точки зрения конфиденциальности, так как веб-сайты, на которые вы ссылаетесь, получают URL-адреса пользователей. URL может содержать конфидициальную информацию, например adamj.eu/illuminati-funding или /staff-admin/users/?q=user@example.com. Кроме того, если пользователь посещает сайт HTTP с вашего HTTPS-сайта, AITM может читать эти URL-адреса.
Установка заголовка Referrer-Policy позволяет указать браузеру, когда отправлять Referer.
Предупреждение: слово «referrer» имеет два «r» в середине. Оригинальная спецификация HTTP содержала опечатку с одним «r», и никто не заметил, поэтому заголовок пишется как Referer. Чтобы не повторять эту опечатку, авторы Referrer-Policy были более осторожны, и включили два «r». Хотя на самом деле это создало больше путаницы, чем пользы.
Этот заголовок не встроен в Django, но вы можете добавить его с помощью пакета django-referrer-policy от другого разработчика Джеймса Беннетта. Следуйте инструкции в документации к пакету, чтобы добавить его в middleware и его настройки.
Имейте в виду, что наиболее безопасное значение no-referrer нарушает CSRF Django (см. «Удаление заголовка Referer» в документации CSRF). Возможно вы, не захотите использовать этот параметр.
Я рекомендую использовать same-origin, который отправляет Referer только для запросов в тот же домен. Это не нарушает CSRF и позволяет внутренней аналитике работать без потери значений Referer для других доменов.
6. Content-Security-Policy
Content Security Policy, или CSP, — это политика, которая блокирует некоторый контент. Она помогает остановить XSS, clickjacking и другие виды инъекционных атак.
По умолчанию браузеры позволяют веб-сайтам загружать контент из любого места. Это означает, что если злоумышленник успешно выполнит XSS-атаку на вашем сайте, он сможет встроить код из любого сайта в Интернете. CSP — это набор директив, которые определяют списки разрешенных доменов, с которых браузер может загружать контент. Что позволяет сильно ограничивать такие атаки.
Например, возьмите эту политику из документации MDN:
Здесь есть четыре директивы, разделенные точкой с запятой. Они говорят браузеру:
Сама политика прописывается в заголовке Content-Security-Policy.
Этот параметр не встроен в Django, но его можно установить с помощью пакета django-csp от Mozilla. Следуйте инструкциям по установке и настройке в его документации. Он включает в себя middleware и множество настроек для создания директив политики.
В спецификации CSP есть много разных директив и опций, и django-csp использует 24 параметра настроек. Я бы порекомендовал прочитать документацию в MDN и разобраться в вариантах. Вот несколько рекомендаций.
Новый сайт
Если вы настраиваете совершенно новый сайт без внешних ресурсов, вам будет гораздо легче. Вы должны начать с ограничительного CSP и открывать дополнительные параметры по мере развития сайта.
В начале можно заблокировать загрузку внешних ресурсов всех видов. Затем вы можете настроить свою политику CSP нужным образом.
Вы можете начать с стандартных настроек django-csp, в которых есть только CSP_DEFAULT_SRC = [«‘self’»]. Это блокирует большинство внешних ресурсов.
Или вы можете начать с более строгого CSP, например, рекомендованного Google Strict CSP Page. Это еще больше защитит ваш сайт.
Существующий сайт
CSP сложнее добавить к существующему сайту, и чем больше сайт, тем труднее задача.
Первым шагом является создание исходного CSP. Вы можете использовать одну из приведенных выше ограничительных рекомендаций или сделать более обоснованное предположение с помощью таких инструментов, как CSP Toolkit или CSPIsAwesome.
Затем включите этот параметр в режиме только для отчетов, установив параметры django-csp CSP_REPORT_ONLY и CSP_REPORT_URI. Браузеры ваших пользователей будут проверять, но не применять политику, а затем сообщать вам о нарушениях.
Для активирования режима только для чтения в django-csp, установите CSP_REPORT_ONLY = True и CSP_REPORT_URI URL-адрес веб-хука. Этот URL будет получать отчеты от ваших пользователей в формате JSON.
Вы можете попытаться получать отчеты самостоятельно, но я бы не рекомендовал это делать. Вместо этого используйте сервис, который может обработать все отчеты и представить их вам в удобной панели инструментов. Два из которых я знаю:
Как только вы создадите эту отчетность, вы можете выполнять итерационную настройку CSP до тех пор, пока не увидите больше нарушений. Затем скажите браузерам принудительно включить его, отключив режим только для отчетов. Отчеты будут по-прежнему полезны после этого, когда ваш сайт будет развиваться или подвергается атакам XSS.
7. Дополнительная настройка Feature-Policy
Настройка вышеупомянутых шести заголовков даст вам рейтинг A+ на Securityheaders.com. Это финальный заголовок, так же может помочь вам обеспечить безопасность вашего сайта, но в настоящее время он экспериментальный.
На момент написания статье, этот параметр поддерживается не всеми браузерами. Chrome — как наиболее популярный браузер, реализующий его, но он требует, чтобы у пользователя был включен флаг «экспериментальные веб-функции».
Я бы рекомендовал полностью отключить некоторые раздражающие функции, такие как autoplay, camera, fullscreen, geolocation и microphone (при условии, что ваш сайт их не использует). Это означает, что встраиваемые вами сценарии, например от рекламных партнеров, не будут раздражать ваших пользователей этими функциями.
Поскольку параметр является экспериментальным, если вы его добавите, по чаще обновляйте django-feature-policy. Я регулярно обновляю его, чтобы следить за изменениями в спецификации. Они недавно выпустили версию 2.0.0, так как несколько функций изменилось (см. changelog).
Заключение!
Я надеюсь, что эта статья помогла вам повысить уровень знаний в области веб-безопасности и найти время, чтобы перевести свой веб-сайт на оценку A+!
XSS: атака и защита с точки зрения C# программирования
XSS, или межсайтовый скриптинг, является одной из самых часто встречающихся уязвимостей в веб-приложениях. Она уже долгое время входит в OWASP Top 10 – список самых критичных угроз безопасности веб-приложений. Давайте вместе разберемся, как в вашем браузере может выполниться скрипт, полученный со стороннего сайта, и к чему это может привести (спойлер: например, к краже cookie). Заодно поговорим о том, что необходимо предпринять, чтобы обезопаситься от XSS.
Что такое XSS?
Межсайтовый скриптинг (XSS) — тип атаки на веб-системы: он заключается во внедрении в веб-страницу вредоносного кода, который взаимодействует с веб-сервером злоумышленника. Чаще всего вредоносный код выполняется в браузере пользователя при рендеринге страницы. Реже — от пользователя требуется выполнение дополнительных действий. Получается, что во многих случаях для использования XSS уязвимости злоумышленником пользователю необходимо просто открыть веб-страницу с внедрённым вредоносным кодом. Это одна из причин того, почему на момент написания статьи XSS занимает 7-ое место в OWASP Top 10 — списке самых опасных уязвимостей веб-приложений, сформированном в 2017 году.
При отображении страницы браузер не может отличить обычный текст от HTML разметки. Из-за этого он будет выполнять весь JavaScript код, расположенный в тегах
Теперь проверим, что всё работает. Открываем страницу с пустым значением у параметра xss:
Открываем страницу со значением Not empty ‘xss’ parameter у параметра xss:
Отображение строки работает. А теперь самое интересное! Передадим в параметре xss строку .
В результате при открытии страницы код из параметра будет выполнен, и мы увидим диалоговое окно с текстом, переданным в метод alert:
Вау! JavaScript код, который мы передали через параметр xss, выполнился при отображении страницы. Таким образом я наполовину выполнил первый пункт из определения XSS атаки: на страницу внедрён код, который выполнился при отображении страницы, однако он не нанёс никакого вреда.
Теперь добавим взаимодействие внедрённого кода с веб-сервером злоумышленника. Аналогом веб-сервера в моём примере будет веб-сервис, написанный на C#. Код конечной точки веб-сервиса:
Чтобы обратиться к этому веб-сервису, я передам в параметре xss строку:
При открытии страницы код из параметра будет выполнен, и веб-сервису по адресу https://localhost:44394/AttackerEndPoint будет отправлен GET запрос, где в параметре stolenToken будет передана строка TEST_TOKEN. При получении запроса веб-сервис сохранит значение из параметра stolenToken в файл StolenTokenResult.txt.
Протестируем это поведение. Откроем страницу и увидим, что на ней ничего не отображается, кроме стандартного сообщения Value of the ‘xss’ parameter:.
Однако во вкладке ‘Network’ в инструментах разработчика висит сообщение о том, что веб-сервису по адресу https://localhost:44394/AttackerEndPoint был отправлен запрос:
Теперь проверим, что же содержится в файле StolenTokenResult.txt:
Ок, все работает. Таким образом мы почти выполнили все условия XSS атаки:
на страницу внедряется код через параметр xss в GET запросе;
этот код выполняется при открытии страницы и взаимодействует с веб-сервисом по адресу https://localhost:44394/AttackerEndPoint.
Осталось сделать этот код вредоносным. Из моего небольшого опыта веб-программирования я знаю, что в локальном хранилище браузера иногда хранятся токены для проверки аутентификации пользователя на нескольких сайтах или в нескольких веб-приложениях. Работает это так:
если в локальном хранилище в браузере пользователя имеется необходимый токен, то аутентификация игнорируется и сразу предоставляется доступ к аккаунту пользователя;
если токена в локальном хранилище браузера нет, то вначале пользователь проходит аутентификацию.
Для того чтобы код, выполненный на странице, оказался вредоносным, я решил изменить код страницы. Теперь при её открытии в локальное хранилище браузера сохраняется строка USER_VERY_SECRET_TOKEN по ключу SECRET_TOKEN. Для этого я изменил код страницы:
Осталось передать в GET запросе через параметр xss код, который получит из локального хранилища данные и отправит их на веб-сервис. Для этого я передам в параметре строку:
Вместо символа ‘+’ я использовал его кодированный вариант %2b, потому что в URL для символа ‘+’ отведено специальное назначение.
Проверяем, что все работает так, как я описал. Открываем страницу:
Здесь, как и в прошлый раз, только сообщение Value of the ‘xss’ parameter: посередине страницы. Осталось проверить, что код был выполнен и веб-сервису был отправлен запрос, где значение параметра stolenToken было равно USER_VERY_SECRET_TOKEN:
Если на моем месте был бы обычный пользователь, то он бы не заметил выполнения скрипта при открытии страницы, потому что на странице ничто об этом не сигнализировало.
Теперь убедимся, что веб-сервис получил украденный токен:
Да, получил. В переменной stolenToken находится значение USER_VERY_SECRET_DATA. Ну и, естественно, веб-сервис сохранил его в файл StolenTokenResult.txt. Поздравляю, XSS атака прошла успешно.
В этом примере я сам передал вредоносный код в параметре запроса. В реальной же жизни злоумышленник замаскирует ссылку (например, при помощи программы сокращения ссылок) с вредоносным кодом и отправит ее пользователю на почту (представившись техподдержкой или администрацией сайта) или опубликует её на стороннем сайте. Кликнув на замаскированную ссылку, пользователь откроет веб-страницу и тем самым запустит вредоносный скрипт у себя в браузере, ничего не подозревая об этом. После выполнения скрипта злоумышленник получит токен и, используя его, окажется в аккаунте пользователя. В результате он сможет похитить конфиденциальные данные или выполнить вредоносные действия от имени пользователя.
Разобрав на примере, как может произойти XSS атака, стоит немного углубиться в теорию и познакомиться с типами XSS атак:
отраженные XSS. Вредоносный скрипт внедряется в виде текста на веб-страницу, и выполняется при открытии страницы в браузере пользователя;
хранимые XSS. Похожи на отраженные, только данные с вредоносным скриптом каким-либо образом (например, через поля формы на странице, параметры запроса или SQL инъекцию) сохраняются злоумышленником в хранилище (база данных, файл и т.п.). Потом данные из хранилища без кодирования HTML символов добавляются на страницу, отображаемую пользователю, в результате чего при открытии страницы выполняется вредоносный скрипт. Данный вид атаки особенно опасен тем, что потенциально задевает не одного пользователя, а целую группу. Например, если вредоносный скрипт попадает на страницу новостей на форуме, которую может просматривать любой;
XSS в DOM-Модели. Этот тип атаки отличается тем, что вредоносный скрипт попадает не на веб-страницу, отображаемую пользователю, а внедряется в DOM-модель веб-страницы. Например, вредоносный скрипт добавляется в обработчик события нажатия кнопки на веб-странице и выполняется при нажатии пользователем на эту кнопку.
Учитывая, что эту статью скорее всего читает разработчик, стоит рассказать о способах, которые помогут избежать появления XSS уязвимостей при разработке. Давайте с ними познакомимся.
Способы защиты от XSS уязвимостей при разработке
Так как я являюсь C# разработчиком, то способы защиты от XSS будут рассмотрены для языка C#. Однако это никак не повлияет на информативность, потому что варианты защиты, описанные ниже, подойдут для практически любого языка программирования.
В этом файле на странице отображается результат C# выражения Model.RequestId. Чтобы данный тип файла скомпилировался, C# выражение или блок C# кода должен начинаться с символа ‘@’. Однако этот символ не только позволяет использовать C# вместе с HTML разметкой в одном файле, но и указывает ASP.NET, что если блок кода или выражение возвращают значение, то перед его отображением на странице необходимо в значении кодировать символы HTML в HTML-сущности. HTML-сущности — это части текста («строки»), которые начинаются с символа амперсанда (&) и заканчиваются точкой с запятой (;). Сущности чаще всего используются для представления специальных символов (которые могут быть восприняты как часть HTML-кода) или невидимых символов (таких как неразрывный пробел). Таким образом ASP.NET защищает разработчиков от XSS атак.
Вторым вариантом является кодирование HTML символов в HTML-сущности перед отображением данных на веб-странице «вручную», то есть с использованием специальных функций-кодировщиков. В C# для этого имеются специальные методы:
В результате кодирования HTML символов вредоносный код не выполняется браузером, а просто отображается в виде текста на веб-странице, причем закодированные символы отображаются корректно.
Давайте я продемонстрирую данный способ защиты на примере XSS атаки, проведённой ранее. Вот только одна проблема: в JavaScript я не нашёл функции, которая кодирует HTML символы в HTML-сущности. Зато я нашёл в интернете способ, как быстро и легко написать такую функцию:
При написании этой функции была использована особенность свойства Element.innerHTML. Используем эту функцию на HTML странице из примера XSS атаки:
Здесь мы кодируем значение xss параметра при помощи функции htmlEncode перед отображением на странице.
Теперь откроем эту страницу, передав в параметре xss строку :
Как видите, при кодировании строки со скриптом браузер просто отображает эту строку на странице, а не выполняет скрипт.
Третий вариант защиты – это валидация данных, полученных от пользователя или какого-то другого внешнего источника (HTML запрос, база данных, файл и т.п.). Для этого типа защиты хорошо подходят регулярные выражения. Их можно использовать для отлова данных, содержащих опасные символы или конструкции. При обнаружении подобных данных валидатором приложение просто должно выдать пользователю сообщение об опасных данных и не отправлять их далее на обработку.
О других способах защиты от XSS вы можете прочитать здесь. Как видно из рассмотренного выше примера, даже в простейшей веб-странице с минимальным исходным кодом может иметься XSS уязвимость. Представьте, какие же тогда возможности для XSS открываются в проектах, имеющих десятки тысяч строк кода. Учитывая это, были разработаны автоматизированные инструменты для поиска XSS уязвимостей. С помощью этих утилит сканируется исходный код или точки доступа сайта или веб-приложения и составляется отчёт о найденных уязвимостях.
Автоматизированный поиск XSS уязвимостей
Если при разработке вы не уделяли должного внимания защите от XSS, то не всё ещё потерянно. Для поиска уязвимостей в безопасности сайтов и веб-приложений имеется множество XSS сканеров. Благодаря им вы можете найти большинство известных уязвимостей в своих проектах (и не только в своих, потому что некоторым сканерам не нужны исходники). Имеются как бесплатные, так и платные варианты подобных сканеров. Конечно, вы можете попробовать написать собственные инструменты поиска XSS уязвимостей, но они, скорее всего, будут намного хуже профессиональных платных инструментов.
И все-таки более логичным и дешёвым вариантом является поиск и исправление уязвимостей на ранних стадиях разработки. Значительную помощь в этом оказывают XSS сканеры и статические анализаторы кода. Например, в контексте разработки на языке C# одним из таких статических анализаторов является PVS-Studio. В этом анализаторе недавно появилась новая C# диагностика — V5610, которая как раз ищет потенциальные XSS уязвимости. Также можно использовать оба типа инструментов, потому что каждый из них имеет собственную зону ответственности. Благодаря этому вы обнаружите как существующие уязвимости в проекте, так и уязвимости, которые будут возникать при развитии проекта.
Если вам интересна тема уязвимостей в целом, а также способы их обнаружения с помощью статического анализа, то предлагаю прочитать статью «OWASP, уязвимости и taint анализ в PVS-Studio C#. Смешать, но не взбалтывать».
Заключение
XSS — это необычная и довольно мерзкая уязвимость в веб-безопасности. В данной статье я привёл лишь один простой пример XSS атаки. В реальности же вариантов атак огромное количество. У каждого проекта могут иметься как уникальные, так и известные XSS уязвимости, которыми могут воспользоваться злоумышленники. Если вы хотите найти уязвимости в уже готовом проекте или если у вас нет доступа к исходному коду проекта, то стоит обратить свое внимание на XSS сканеры. Для защиты от появления XSS уязвимостей при разработке стоит применять статические анализаторы кода.
P.S. Если хотите получить немного практики с XSS (в учебных целях), предлагаю попробовать игру про XSS от Google.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Valery Komarov. XSS: attack, defense — and C# programming.