Как защитить приложение от хакеров

Невозможно полностью защитить приложение от атак. Постоянно появляются новые технологии и npm-пакеты, выходят обновления для CMS и фреймворков — всё это создают обычные люди, поэтому неизбежны баги и уязвимости. А ещё на пути данных от клиента к серверу и обратно находится большое количество протоколов — они тоже содержат уязвимости и могут быть источниками угроз. Поэтому задача разработчика — предусмотреть «дыры» в безопасности и написать код, устойчивый к большинству атак. Давайте посмотрим, как фронтендеру обезопасить веб-приложение.

Какие бывают атаки

Чтобы понимать, куда направлены атаки, важно знать структуру передачи данных. Задачи по их отправке и получению разделены между клиентом и сервером. Клиент отправляет запрос, а сервер принимает его и возвращает ответ.

👉 Клиент — это любое устройство для работы с сайтом, например, ноутбук или смартфон.

Сервер — специальная программа или мощный компьютер.

Атаки делятся на те, которые направлены на клиентскую часть, и те, которые направлены на серверную. Но это распределение условно, ведь есть атаки, которые направлены и на клиент, и на сервер. А некоторые атаки направлены на сервер, но реализуются на клиенте. Например, взлом базы данных, когда киберпреступник через поля ввода добирается до информации о базе данных.

MITM — группа атак с участием посредника, когда киберпреступник тайно вмешивается в обмен данными, чтобы получить или изменить информацию. К таким атакам относятся XSS-атаки и SQL-инъекции.

XSS-атаки — попытка захвата данных, когда киберпреступник внедряет собственный JavaScript-код в веб-приложение и затем использует в личных целях. Такую атаку используют, чтобы захватить учётные записи, украсть личные данные, выдать себя за пользователей или получить доступ к информации.

SQL-атака — атака на базу данных веб-приложения. При работе с базой разработчики используют SQL-запрос. Когда хакер добавляет к таким запросам вредоносный код, происходит SQL-атака, или SQL-инъекция.

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

DoS и DDoS-атаки — попытка вывести веб-приложение из строя. Такие атаки происходят через настолько большой поток трафика, что веб-приложение не может его обработать и выходит из строя. DoS-атака организовывается с одного источника, а DDoS — с двух и более.

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

Манипуляция URL — изменение URL в адресной строке браузера. Если веб-приложение не защищено, то киберпреступник добирается до приватной информации, например, личных данных или сведений о заказанных товарах. Ещё к этой атаке относится поиск страниц, скрытых от пользователей.

Как оценить безопасность приложения

Оценить безопасность веб-приложения можно с помощью специальных сервисов и программ: OWASP ZAP, Arachni, Burp Suite или других. Они помогают срежиссировать разные атаки и узнать об уязвимостях при разработке или в готовом веб-приложении.

На скриншоте показаны результаты тестирования в Burp Suite — найдено несколько уязвимостей, и в правом нижнем углу описано, как тестировали определённую атаку.

Такие сканеры проверяют приложение на все основные атаки, в том числе XSS, SQL-инъекции, CSRF и загрузку вредоносных файлов. После тестирования вы получаете подробный отчёт об уязвимости веб-приложения — он пригодится при составлении карты задач для повышения безопасности.

Как защитить приложение от атак

Обо всех способах защиты невозможно рассказать в одной статье — их слишком много. Мы коротко разберём основные, а если вы захотите углубиться в тему, вам поможет курс «Протоколы и сети: веб-безопасность».

Защита сайта на CMS

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

Узнать о новых уязвимостях можно на сайте Банка данных угроз безопасности информации. А ещё разработчики популярных CMS сами предупреждают пользователей, например, список уязвимостей для Wordpress есть на сайте.

Как защитить сайт на CMS:

Обновляйте CMS.
Обновляйте темы и плагины.
Используйте как можно меньше плагинов.
Скройте данные входа в админку, изменив стандартный URL входа.
Ограничьте количество попыток входа в админку.
Выберите собственный префикс таблицы. Например, в WordPress по умолчанию задан префикс wp_, а вы можете изменить его на academy_ или keks_. Задавать префикс нужно при установке CMS — в готовом проекте его нельзя менять, иначе вы потеряете доступ к базе данных.

А ещё в документации к CMS иногда есть рекомендации по защите. Например, такие советы есть у 1С-Битрикс и OpenCart — обязательно следуйте им.

Защита со стороны клиента

Защищайте и валидируйте поля ввода. Поля ввода очень уязвимы, ведь злоумышленники могут отправлять через них вредоносный код. Поэтому не разрешайте пользователям вводить символы, которые запускают JavaScript или PHP: слеш, угловые скобки и знак вопроса. Также хорошая практика — не давать отправлять форму, если ни одно поле не заполнено.

Техники валидации форм

Старайтесь валидировать все поля, например, запретите ввод букв в поле для номера телефона. Можно ограничить максимальное количество символов, только учитывайте, что номера телефонов в международном формате бывают длинными, а ещё пользователи из России по-разному вводят номера: кто-то начинает с +7, а кто-то пишет восьмёрку, поэтому длина номера может варьироваться. Для таких случаев разрешите вводить в поле как минимум 20 символов, в том числе плюс, скобки, дефис и пробел.

При валидации важное правило — не создать проблем для пользователя. Здесь есть две стратегии:

«чёрные списки» — запретить для ввода набор символов, а остальные разрешить,
«белые списки» — разрешить только необходимые символы, а остальные запретить.

«Белые списки» безопаснее, но такая степень защиты не всегда подходит. Например, при создании сайта, похожего на StackOverflow, нельзя ограничивать ввод символов, используемых в коде — иначе пользователи не смогут задавать вопросы. Поэтому здесь подойдёт чёрный список.

Создавайте системы с авторизацией. Создавайте разные уровни доступа, чтобы одни пользователи могли только читать страницы, другие — читать и редактировать, а третьи — редактировать код. Такое разделение защищает от SQL-инъекций, кражи cookies и других атак. Главное — не создавать «суперадминистратора» с максимальным количеством прав, иначе при взломе этого пользователя вся информация станет доступна киберпреступнику. Например, владельцу компании не нужны доступы к коду веб-приложения, а техлиду — к бухгалтерским отчётам.

Подключите WAF — брандмауэры веб-приложений. Они защищают сайты, фильтруя входящий поток пользователей, и анализируют HTTP-трафик, блокируя ботов и выявляя аномалии трафика. Чтобы их подключить, обратитесь в хостинговую компанию или установите специальные системы, например, Nemezida WAF.

WAF нельзя использовать как единственный способ защиты: они не защищают от всех атак, так как есть множество способов их переобхода.

Защищайте cookies. Храните в cookies только настройки веб-приложения для конкретного пользователя, например, язык сайта по умолчанию — эти данные не являются конфиденциальными, и при их краже ничего страшного не произойдёт. А вот данные банковских карт, пароли или паспортные данные пользователей в cookies хранить нельзя. Также хороший способ защиты — недолгий срок жизни cookies и ограничение на действие только в рамках домена веб-приложения.

Защищайте файлы при загрузке. Разрешайте пользователям загружать только необходимые типы файлов. Например, при загрузке фото в профиль разрешайте только растровые форматы графики. Для загрузки pdf-файла разрешайте только формат pdf.

Атрибут accept со значением "image/*" разрешит все типы изображений:

<input type="file" accept="image/*">

Атрибут accept со значением "audio/*" и "video/*" разрешит все типы аудио и видео:

<input type="file" accept="audio/*">

<input type="file" accept="video/*">

Можно прописать определённые типы. Разрешим прикреплять только pdf:

<input type="file" accept="pdf">

Другой способ записи:

<input type="file" accept="application/pdf">

Разрешим прикреплять форматы изображений jpg, jpeg, png:

<input type="file" accept=".jpg, .jpeg, .png">

Другой способ записи:

<input type="file" accept="image/jpeg, image/jpeg, image/png">

Популярные типы и расширения файлов есть на сайте HTML Book, а полный список — на сайте IANA.

Пример: защита кода на сервере

Всё это валидация на клиенте, то есть в браузере. Если удалить атрибут accept через инструменты разработчика или поменять тип файла с hacker.exe на hacker.jpg, валидация не сработает. Поэтому такую защиту нужно делать ещё и на сервере.

Устанавливайте максимальный размер файлов, чтобы снизить нагрузку на сервер — это поможет от DoS- и DDoS-атак. Храните загруженные файлы вне корневой директории, например, на поддомене. Тогда загруженный вредоносный файл не навредит основному коду веб-приложения.

Используйте политику безопасности контента — CSP. В ней можно указать, какой код выполнить, а какой — заблокировать. Например, можно запретить выполнение встроенного кода: даже если киберпреступник добавит вредоносный код, то он не выполнится и не навредит. Также можно разрешить выполнение скрипта только из определённой директории, например, assets/scripts. Или можно разрешить выполнение скриптов только с собственного домена.

CSP защищает веб-приложение от вредоносного кода, но она не подходит, если веб-приложению нужно извлекать ресурсы с других сервером или источников. Более мягкая защита — CORS. Он относится к защите серверной части.

Защита со стороны сервера для фронтендера

CORS — протокол для междоменного использования ресурсов. Он построен поверх HTTP и позволяет серверной части указывать браузеру, какие подключённые URL скриптов можно выполнять. Такая защита важна, когда киберпреступнику удалось добавить вредоносный URL:

...
  <script src='https://api-maps.yandex.ru/2.1/?apikey=960272e&lang=ru_RU'></script>
  <script src="js/catalog-scripts.min.js"></script>
  <script src="https://hacker.ru/success.js"></script>
  <script src="js/map.min.js"></script>
</body>

CORS позволяет точно указать, какие скрипты выполнять, а какие нет. Также можно указать разрешённые методы, например, чтобы киберпреступник не смог вместо GET-запроса воспользоваться методом DELETE. Или можно указать исходный источник запроса, чтобы источник хакера не был использован.

В CORS есть заголовки:

Origin — в нём указывается исходный источник запроса, то есть домен, на котором расположены собственные ресурсы, или поддомен.
Access-Control-Request-Headers — здесь указываются заголовки, которые будут отправлены вместе с запросом.
Access-Control-Request-Method — в нём указывается разрешённый для запроса метод HTTP, например, DELETE. Можно указать один или несколько методов.

Посмотрим, как работает CORS. Сначала установим npm-пакет cors:

npm install cors

В файле server.js импортируем cors:

const cors = require("cors");

Укажем белый список источников:

app.use(function(res, next) {
  res.header("Access-Control-Allow-Origin", "https://htmlacademy.ru");
  next();
});

Укажем разрешённые заголовки:

res.header(
  "Access-Control-Allow-Headers",
  "Origin, X-Requested-With, Content-Type, Accept"
);

Укажем разрешённые методы:

res.header(
  "Access-Control-Allow-Methods",
  "GET, POST, PUT, DELETE"
);

Так можно защитить веб-приложение от вредоносных ресурсов, даже если киберпреступник его взломал.

Итоги

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

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

Журнал «Доктайп»