Как защититься от XSS- и CSRF-атак

Содержание:

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

Как защититься от XSS- и CSRF-атак

Для понятия безопасности веб-сайтов давайте разберем основные параметры. По дефолту политика браузерной безопасности называется SOP. Если расшифровать аббревиатуру, то вы прочтете следующее: Same Origin Policy.

Origin — это источник скрипта. Опытные программисты определяют его тремя понятиями:

  • протокол типа https;
  • хост наподобие mywebsite.com;
  • порт 249, 80.

Программисты отмечают одну особенность. SOP посылает запросы с одного источника на другой. Но ответы прочесть не может, потому что чтение ответов блокируется на уровне браузера.

Но подготовленные хакерами атаки по типу XSS и CSRF могут обходить защиту браузера. Если вы не пропишете сайту скрипты санитизации, то ваш проект может быть взломан путем XSS-атаки. Чаще всего такие атаки происходят дозированно, путем инъекций.

Давайте посмотрим, как это делается.

Межсайтовые скриптинги и как от них защититься

Межсайтовые скриптинги, или JS-инъекции, вы будете встречать часто. Происходят они по следующему типу:

  1. В файл HTML вставляется строка с эксплуатацией компонентов, похожих на html-теги.
  2. Браузер расшифровывает их как работающий код и выполняет все действия, которые они приказывают выполнить.

Рассмотрим такое воздействие на примере прописывания тега <img> с добавлением пустого источника src. Теперь пропишите к этому коду следующий onerror=“alert(‘hacked’). Браузер не будет раздумывать, так как источник пустой, он перейдет к выполнению прописанного кода Onerror. Внутрь последнего можно прописать любой код для взлома компьютера и запустить небезопасного троянского червя.

Программисты борются с такими инъекциями путем использования библиотек React. В Angular и React содержатся коды санитизации, которые предотвращают введение вредоносных инъекций. Но часто начинающие программисты отключают их для того, чтобы запустить inline-скрипт. Во фреймворке React разработчик делает это путем атрибута, который подчеркивает опасность вставки инлайн-скрипта. Вот так он выглядит на картинке:

Как защититься от XSS- и CSRF-атак

Во фреймворке Angular можно провести инъекцию для кода санитизации. Разработчик может выбрать прочтение браузером стилей и экранирование скриптов.

Кроме кода, который отвечает за веб-безопасность в сети сайта, есть такой заголовок — Content Security Policy (CSP) Header. С помощью него задают скрипты с источником, которые исполняются самим на странице сайта.

По умолчанию Content Security Policy включает в себя значение «звездочка». «*» означает, что браузеру позволяется использовать скрипты с любым ориджином. То есть разработчик может запустить даже инлайн-инъекции без ориджина.

Опытные программисты говорят, что подобного вида настройки совсем не отвечают безопасности сети. Новичкам-разработчикам рекомендуют четко прописывать скрипты и источники на сайте. Таким образом, ограниченное количество origin’ов запрещает выполнение мошеннических inline-скриптов. Так как, чтобы выполнились мошеннические скрипты, потребуется прописать код.

Давайте посмотрим, как выглядит код CSP Header:

Как защититься от XSS- и CSRF-атак

Подобного рода настройки обозначают, что картинки будут загружаться с любого источника (*), а другие файлы загружаются с двух ориджинов (например, медиа1 и медиа2 — предпоследняя строчка).

Как защититься от XSS- и CSRF-атак

Скриптам будет позволено запускаться тогда, когда в них заключен только один origin (userscripts.example.com). Например, такой код «default-src ‘self’» разрешает проводить запуск скриптов с текущего origin’а. С поддоменов он уже не сможет запуститься.

С помощью описанного выше заголовка разработчики смогут очень тонко настраивать выполнение скриптов в браузерах на созданном программистами сайте.

Давайте теперь быстро рассмотрим две политики: content-security-policy Header и access-control-allow-origin. Они во многом друг на друга похожи. Например, CSP помогает обойти SOP, а access-control-allow-origin принимает разрешение на CORS. Таким образом, он дает ответы на запросы скриптов с иным ориджином.

Вам уже известно, что политика SOP помогает скриптам с одним origin’ом посылать запросы на другой origin. Но в любом случае безопасность веб-браузеров заблокирует ответ. А с помощью access-control-allow-origin вы сможете получить доступ к данному ответу только в том случае, если на сервере точно прописан origin, имеющий право получать ответы.

Теперь поговорим о другой хакерской атаке. Это CSRF.

Атаки на стороне клиента и как от них защититься

Любимые всеми куки становятся виновниками атаки CSRF. Да, они собирают информацию о пользователях, да, с помощью них можно направлять пользователям различные приглашения и рекламировать продукт. Но куки — это монстр, через которого хакеры проводят свои атаки.

На русском куки, а на английском «cookies» — это фрагмент информации, отправленный сервером клиенту в виде name=value. Браузер хранит их на компьютере пользователя. При определенном запросе компьютер отсылает информацию заново веб-серверу.

Атакующий на своем сайте помещает HTML-страничку, которая представляет собой HTML-форму, похожую на обычный полезный веб-проект example.com. Поскольку браузер автоматически вставляет cookies клиента в HTTP-запрос, то backend не понимает, действительно ли полученный запрос настоящий и заполненный реальным пользователем или это CSRF-атака. Он просто изменяет адрес доставки для пользователя на значение, которое использует хакер.

Программисты советуют быть осторожными и с другим видом CSRF-атаки — XHR API. Если о CSRF-атаке с использованием HTML-форм слышали многие, то о данном способе знают меньше, но он тоже работает. Более подробно об этом вы сможете узнать в нашем IT-блоге от DevEducation.

На картинке вы видите код настоящей атаки CSRF.

Как защититься от XSS- и CSRF-атак

Давайте посмотрим, как защищаются от подобных атак:

  • прописывание токенов, которые вставляются в DOM или отдаются в интерфейсе. Пользователю при изменении запроса браузер должен отправить токен в заголовке или параметре запроса. В этом случае атака не срабатывает;
  • двойное представление куки. В этом случае хакер не сможет изменить куки в браузере, поэтому атака не проходит.

На самом деле защит от хакерских атак много. И с каждым днем они только совершенствуются. Если вам интересна тема веб-безопасности и вообще создания сайтов, пройдите курсы по программированию от DevEducation. Здесь вы получите полезные знания, которые помогут вам найти достойную работу с высокой зарплатой.

Присоединяйся к DevEducation — стань востребованным специалистом и построй карьеру в IT!