Как защитить веб-приложение: основные советы, инструменты, полезные ссылки

Общедоступные веб-приложения интересны хакерам как ресурсы или инструменты заработка. Спектр применения полученной в результате взлома информации широкий: платное предоставление доступа к ресурсу, использование в бот-сетях и т. д. Личность владельца не важна, так как процесс взлома автоматизирован и поставлен на поток. Стоимость информации пропорциональна известности и влиятельности компании.

Если задаться целью, уязвимость в приложении найдётся. В отчёте о хакерских атаках на сайты за 2016 год эксперты Google сообщили о том, что количество взломанных ресурсов увеличилось на 32% по сравнению с 2015 годом, и это не предел. Помните об этом и отбросьте заблуждения о неприступности своих веб-ресурсов, когда планируете работы по информационной безопасности. Специалисты по кибербезопасности востребованы как никогда.

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

Советы по защите веб-приложения от хакеров

Используйте инструменты для анализа защищенности

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

Ниже приведена подборка бесплатных инструментов.

Приложения и фреймворки

• OpenVAS сканирует узлы сети на наличие уязвимостей и позволяет управлять уязвимостями.
• OWASP Xenotix XSS Exploit Framework сканирует ресурс на возможность эксплуатации XSS-уязвимостей.
• Approof от Positive Technologies проверяет конфигурацию веб-приложения, сканирует на наличие уязвимых компонентов, незащищенных чувствительных данных и вредоносного кода.

Онлайн-сервисы

• SecurityHeaders.io проверяет на наличие и корректность заголовков ответа сервера, отвечающих за безопасность веб-приложения.
• Observatory by Mozilla сканирует ресурс на наличие проблем безопасности. Кроме своих результатов, при выборе соответствующей опции, собирает и добавляет к отчету аналитику со сторонних сервисов анализа защищённости.
• One button scan сканирует на наличие уязвимостей компоненты ресурса: DNS, HTTP-заголовки, SSL, чувствительные данные, используемые сервисы.
• CSP Evaluator проверяет правильность составления политики безопасности содержимого (CSP) и устойчивость к XSS.
• SSL Server Test выполняет анализ SSL-конфигурации веб-сервера.
• ASafaWeb проверяет на наличие распространённых уязвимостей конфигурации сайтов, написанных на ASP.NET.
• Snyk сканирует JavaScript, Ruby и Java-приложения на наличие уязвимостей и, при необходимости, исправляет проблемы безопасности. Интегрируется с GitHub репозиторием для проведения автоматической проверки и оповещает о найденных уязвимостях.

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

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

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

Если автоматической проверки мало, попытайтесь вручную взломать свой ресурс, изменяя значения POST и GET запросов. Здесь может помочь отладочный прокси-сервер (например, Fiddler), так как он перехватывает значения HTTP запросов между браузером и сервером. Уделите отдельное внимание формам — попробуйте обойти валидацию, чтобы внедрить XSS-инъекцию.

Если на сайте есть страницы, которые доступны только после аутентификации, попробуйте выдать себя за другого пользователя. Для этого измените параметры URL (например, ID пользователя) или значения Cookie.

Защитите пользовательские данные с помощью HTTPS

HyperText Transfer Protocol Secure (HTTPS) — расширение HTTP, которое поддерживает шифрование и защищает данные пользователей при передаче в Интернете. HTTPS гарантирует целостность и конфиденциальность взаимодействия с сервером. В марте этого года популярность HTTPS достигла переломного момента, и вскоре его использование станет «нормой», а не исключением, как это было раньше.

Используйте HTTPS, если пользователи передают на сервер личные данные: информацию о кредитной карте, персональные данные и даже адреса посещённых страниц. Если при отправке данных с формы авторизации устанавливаются cookie-файлы, которые потом отправляются при каждом запросе к серверу, злоумышленник может получить их и подделать запрос к серверу. В результате он перехватит сессию пользователя. Чтобы предотвратить это, используйте HTTPS на всех страницах сайта.

Это просто: SSL-сертификат генерируется бесплатно (например, на Let’s Encrypt), для большинства платформ созданы инструменты автоматического получения и установки сертификата. Остаётся только включить на сервере поддержку HTTPS.

Примечательно, что компания Google объявила планы о предоставлении сайтам, использующим защищённое соединение, преимущества в результатах поиска. Это пряник. Кнутом станут предупреждения о небезопасном соединении в браузерах, количество которых будет расти. HTTP уходит в прошлое, поэтому самое время перейти на HTTPS.

Если HTTPS уже настроен, хорошей практикой считается использование HTTP Strict Transport Security (HSTS) — заголовка ответа сервера, который запрещает для домена использование незащищённого соединения.

Обновляйте программное обеспечение

Это жизненно важно для безопасности веб-приложения. Хакеры регулярно обнаруживают и сразу же применяют новые уязвимости операционных систем и другого программного обеспечения: HTTP-серверов или систем управления контентом (CMS).

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

Если ресурс работает на базе движка стороннего производителя (CMS или форума), устанавливайте исправления безопасности сразу после выпуска. Большинство разработчиков информируют об обновлениях через рассылку или RSS-канал с описанием исправленных проблем. WordPress и Umbraco, кроме того, уведомляют о доступных обновлениях при входе в панель управления.

Многие разработчики используют менеджеры пакетов (например, Composer, NPM или RubyGems), чтобы устанавливать зависимые компоненты для приложений. В этих пакетах также обнаруживают уязвимости, поэтому следите за их обновлением. Чтобы автоматически получать уведомления о проблемах безопасности пакетов проекта, используйте инструменты вроде Gemnasium.

Предотвратите SQL-инъекции

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

Рассмотрим запрос:

			SELECT * FROM table WHERE column = 'parameter';
		

Если злоумышленник изменит значение parameter на ' OR '1'='1, запрос примет следующий вид:

			SELECT * FROM table WHERE column = '' OR '1'='1';
		

Так как '1' равен '1', атакующий получит доступ ко всем данным таблицы. Это позволит выполнить произвольный запрос, добавив в конец выражения SQL.

Уязвимость этого запроса легко устранить с помощью параметризации. Например, для приложения, написанного с использованием PHP и MySQLi, он выглядит так:

			$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value');
$stmt->execute(array('value' => $parameter));
		

Предотвратите межсайтовый скриптинг

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

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

Особенно подвержены этому виду атаки современные веб-приложения, где страницы построены из пользовательского контента, интерпретируемого фронтенд-фреймворками вроде Angular и Ember. В эти фреймворки встроена защита от межсайтового скриптинга, но смешанное формирование контента на стороне сервера и клиента создает новые комплексные атаки: внедрение директив Angular или хелперов Ember.

При проверке сосредоточьтесь на пользовательском контенте, чтобы избежать некорректной интерпретации браузером. Это похоже на защиту от SQL-инъекций. При динамической генерации HTML-кода используйте специальные функции для изменения и получения значений атрибутов (например, element.setAttribute и element.textContent), а также шаблонизаторы, которые выполняют экранизацию специальных символов автоматически.

Политика безопасности содержимого (CSP) — ещё один инструмент защиты от XSS-атак. CSP — заголовки сервера, определяющие белый список источников, откуда разрешена загрузка данных для разных типов ресурсов. Например, запрет запуска скриптов со стороннего домена или отключение функции eval(). Благодаря политикам CSP даже при внедрении вредоносного кода в страницу его выполнение становится невозможным. На официальном сайте Mozilla размещено руководство по CSP с примерами конфигураций.

Проверяйте и шифруйте пароли

Храните пароли в виде хэша, причём лучше использовать алгоритмы одностороннего хэширования, например, SHA. В этом случае для авторизации пользователей сравниваются хэшированные значения. Если злоумышленник взломает ресурс и получит хэшированные пароли, ущерб будет снижен за счёт того, что хэш имеет необратимое действие и получить из него исходные данные практически невозможно. Но хэши на популярные пароли легко перебираются по словарю, поэтому используйте также «соль», уникальную для каждого пароля. Тогда взлом большого количества паролей становится ещё медленнее и требует больших вычислительных затрат.

Что касается валидации, установите ограничение на минимальную длину пароля, а также делайте проверку на совпадение с логином, e-mail и адресом сайта.

К счастью, большинство CMS предоставляют инструменты управления политиками безопасности, но для использования «соли» или установки минимальной сложности пароля иногда требуется дополнительная настройка или установка модуля. При использовании .NET стоит применить провайдеры членства, потому что в них заложена встроенная система безопасности с большим количеством настроек и готовыми элементами для аутентификации и изменения пароля.

Контролируйте процесс загрузки файлов

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

Даже если установлено ограничение на тип (например, только изображения), относитесь к загружаемым пользователями файлам с подозрением. Расширение или MIME-тип легко подделать, чтение заголовка или использование функций проверки размера изображения не дают 100% гарантии, в большинство форматов изображений возможно внедрить код PHP, который будет выполнен на сервере.

Чтобы это предотвратить, запретите исполнение загружаемых файлов пользователями. По умолчанию веб-серверы не пытаются выполнить файлы с расширениями изображений, но не стоит полагаться только на расширение. Известны случаи, когда файл image.jpg.php обходил эту проверку.

Способы ограничения доступа:

• переименовывать или изменять расширения файлов при загрузке;
• изменять разрешения, например, на chmod 0666;
• создать файл .htaccess (см. пример ниже), который откроет доступ только к указанным типам файлов.

			deny from all 
<Files ~ "^\w+\.(gif|jpe?g|png)$"> 
    order deny,
    allow allow from all 
 </Files>
		

Более безопасный способ –– запретить прямой доступ к загружаемым файлам, разместив их, например, вне папки корня сайта. Однако в этом случае потребуется создать скрипт (или обработчик HTTP в .NET), чтобы извлекать файлы из закрытой части и выдавать пользователю.

			  <img src="/imageDelivery.php?id=1234" /> 
  <?php
   // imageDelivery.php 
   // Извлекаем из базы данных имя файла изображения по ID ($_GET["id"]) ... 
   // Передаём изображение браузеру 
   Header('Content-Type: image/gif'); 
   readfile('images/'.$fileName); 
   ?>

		

Меры защиты веб-приложений для владельцев собственных серверов:

1. Настройте межсетевой экран, в том числе на блокировку неиспользуемых портов.
2. При наличии доступа к серверу из локальной сети создайте демилитаризованную зону (DMZ), открыв доступ из внешнего мира только к портам 80 и 443.
3. При отсутствии доступа к серверу из локальной сети используйте защищённые методы (SFTP, SSH и др.) для передачи файлов и управления сервером извне.
4. Если возможно, выделите отдельный сервер для баз данных, который не будет напрямую доступен из внешнего мира.
5. Отграничьте физический доступ к серверу.

Следите за сообщениями об ошибках

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

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

Проверяйте входящие данные

Контролируйте данные, полученные с веб-форм, как на стороне клиента, так и на стороне сервера. В браузере проверяются простые ошибки вроде незаполненного обязательного поля или текста, введённого в числовое поле. Эти проверки обходятся, поэтому контроль на стороне сервера обязателен. Отсутствие проверки на стороне сервера приводит к эксплуатации злоумышленником инъекций и других видов атак.

Распределяйте права доступа к файлам

Разрешения файла (file permissions) определяют КТО и ЧТО может с ним делать.

В *nix системах у файлов 3 варианта доступа, которые представляются в виде цифр:

• «Read» (4) — чтение содержимого файла;
• «Write» (2) — изменение содержимого файла;
• «Execute» (1) — выполнение программы или скрипта.

Чтобы установить множественные разрешения, достаточно сложить их числовые значения:

• «Чтение» (4) + «запись» (2) = 6;
• «Чтение» (4) + «запись» (2) + «выполнение» (1) = 7.

При распределении прав пользователи делятся на 3 типа:

• «Owner» (владелец) — создатель файла (изменяем, но может быть только один);
• «Group» (группа) — группа пользователей, которые получают разрешения;
• «Others» (прочие) — остальные пользователи.

Установка владельцу прав доступа на чтение и запись, группе — на чтение, прочим — запрет доступа выглядит так:

Итоговое представление: 640.

Для каталогов аналогично, но флаг «выполнить» значит сделать рабочей директорией.

При установке CMS-разрешения, как правило, устанавливаются корректно с точки зрения безопасности. Однако в Интернете часто советуют решать проблемы прав доступа установкой на все файлы значения 666 или 777. Этот совет помогает решить проблему, но открывает серьёзную уязвимость, потому что всем появляется право изменить (вставить вредоносный код) или удалить файлы на сервере. Распределяйте права доступа к файлам на сервере в соответствии с задачами пользователей.

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

Полезные ссылки для использования в работе

• OWASP Testing Guide.
• Сканирование и анализ веб-сайтов: подборка полезных сервисов.
• Как установить бесплатный SSL-сертификат для своего сайта.
• Правила для паролей бесполезны, никогда не используйте их в своих проектах.
• Основные аспекты безопасности СУБД: что следует знать.
• Уязвимость в MySQL: простой SELECT дает неограниченные права на исполнение.
• Игра от Google, в которой можно отточить свои хакерские навыки.
• Сайт для тренировки основных видов атак веб-приложений.
• Пример отчета о проведении анализа защищённости веб-ресурса.