Laravel Security 101: никогда не доверяйте своим пользователям

Параметризированные запросы

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

В Laravel мы обычно пишем наши запросы следующим образом:

$name = $request->query(‘name');
$user = DB::table('users')->where('name', $name)->get();

Ключевым компонентом здесь является метод where(), где второй параметр ($name) поступает непосредственно из пользовательского ввода. Laravel автоматически включает этот второй параметр как параметризованный запрос, который предотвращает внедрение SQL, передавая его непосредственно в базу данных.Это одна из замечательных особенностей Laravel, которая затрудняет непреднамеренное создание уязвимых запросов.

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

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

Рассмотрите этот код:

public function store(Request $request)
{
    $data = $request->validate([
        'game' => ['required'],
        'date' => ['required'],
    ])
 
    DB::statement("UPDATE game_user SET turns += event_increment WHERE game_id = {$data['game']}");
}

Когда разработчик писал этот код, он ожидал, что $data['game'] будет целым числом, когда оно будет введено в запрос (и они прочитали это необработанное целочисленное сравнение быстрее!).Да, через браузер пропустили, но они посчитали, что это скрытое поле и никто его не заметит! Но это все еще поле ввода, и хакер может изменять его сколько угодно...

Как я упоминал ранее, Laravel включает параметризацию, встроенную в конструктор запросов, и мы можем легко использовать ее при построении запросов вручную.Вместо того чтобы напрямую вводить переменные в строку запроса, замените их знаком вопроса (?) и включите их в качестве второго параметра в вызов метода. База данных понимает, что вопросительный знак является заполнителем, и знает, как безопасно заменить параметры в запросе при его выполнении.

В этом случае мы можем сделать что-то вроде этого:

DB::statement("UPDATE game_user SET turns += event_increment WHERE game_id = ?", [$data['game']]);

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

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

Если вы хотите глубже изучить параметризованные запросы, я написал о них на странице Laravel Security in Depth, и я бы рекомендовал проверить официальную базу данных Laravel и документацию Eloquent.

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

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

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

42 && user_id = (SELECT id FROM users WHERE email = '[email protected]' LIMIT 1)

Отправив это в приложение, вы получите следующий SQL-запрос:

DB::statement("UPDATE game_user SET turns += event_increment WHERE game_id = 42 && user_id = (SELECT id FROM users WHERE email = `[email protected]` LIMIT 1)");

Немного почистил:

UPDATE game_user
SET turns += event_increment
WHERE game_id = 42
  AND user_id = (
    SELECT id
    FROM users
    WHERE email = '[email protected]'
    LIMIT 1
  )

И все.Мои ходы будут увеличиваться, но никто другой. Очень просто, и все из-за отсутствия проверки и параметризации запросов.

Это тривиальный пример, но вы можете сделать МНОГОЕ с помощью SQL Injection. Существует множество приемов для извлечения информации, в том числе когда страница не возвращает никакой видимой обратной связи (или сообщений об ошибках!).Если вы хотите узнать больше, в октябре мы углубились в SQL Injection в Laravel Security in Depth, включая преднамеренно уязвимое веб-приложение, где вы можете проводить свои собственные SQLi-атаки. Посмотрите здесь.

Экранирование выходных данных

К этому моменту вы, вероятно, хотите, чтобы я поторопился и закончил, чтобы вы могли вернуться и убедиться, что все ваши проверки достаточно явны, а ваши запросы правильно параметризованы, поэтому я не буду вас задерживать надолго. (Я знаю, что каждый раз, когда я пишу об этом, у меня возникают ужасные воспоминания об ужасно уязвимом коде, который я написал в прошлом!)

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

Эти вещи здесь:

{!! $variable !!}

Пожалуйста, просто не используйте их.

Вы должны помнить о том, что вы выводите на страницу.Рассмотрим наш ввод ранее, с именем и фамилией для пользователя.

Что, если пользователь указал это как свое имя:

Stephen <script src="https://evilhacker.dev/evil.js"></script>

А затем мы сделали это на странице:

{{ $user->first_name }}

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

Но что, если бы наш код выглядел так:

// Controller
$links = $pages
    ->map(fn ($page) => "<a href=\"{$page->url}\">{$user->first_name}</a>")
    ->join(', ', ' and ');
 
return view('pages', ['links' => $links])

// Template
<div>
    {!! $links !!}
</div>

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

Итак, как мы это делаем?

1. We have the e($value) function, which does the actual escaping of output when you use the {{ $value }} tags. You can call it anywhere.
2. If you wrap something inside the Illuminate\Support\HtmlString class, it will bypass escaping.

// Controller
$links = $pages
    ->map(fn ($page) => "<a href=\"{$page->url}\">".e($user->first_name)."</a>")
    ->join(', ', ' and ');
 
return view('pages', ['links' => new HtmlString($links)])

// Template
<div>
    {{ $links }}
</div>