Техники безопасности и предотвращения уязвимостей в Laravel

Лучшие правила техники безопасности и избежание уязвимостей в Laravel

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

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

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

Итак, как вы можете защитить или укрепить свое веб-приложение Laravel? В этой статье мы рассмотрим некоторые из ключевых мер безопасности, которые вы можете применить в своем проекте.

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

Как избежать межсайтовой подделки запроса (CSRF)

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

По сути, для каждого вызова AJAX Laravel генерирует и интегрирует токен доступа с запросом. Теперь, всякий раз, когда мы формируем указанный запрос, Laravel также сравнивает указанный токен с токеном, сохраненным в текущих сеансах. Если токены запроса совпадают, значит, все в порядке. Если нет, то запрос недействителен и игнорируется.

Разработчикам старой школы, вручную создающим формы, часто необходимо передавать правильные токены CSRF, чтобы запросы доступа не вызывали исключение безопасности. По большей части, вот как это сделать:

<form name = "myform">
{!! csrf_field () !!}
<!-- Other inputs may come here-->
</form>

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

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

Вот пример запроса к базе данных:

SELECT * FROM users WHERE email = 'someone@buddy.works'

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

Теперь, что если вышеуказанный запрос был изменен следующим образом:

SELECT * FROM users WHERE email = 'someone@buddy.works' or 1=1

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

У Laravel есть простой метод решения этой проблемы. Он использует привязку параметров PDO, где вход помещается в кавычки. Таким образом, наш запрос будет выглядеть так:

SELECT * FROM users WHERE email = 'someone@buddy.works or 1=1'

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

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

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

Вот пример необработанного запроса к базе данных, который с высокой вероятностью может быть атакован SQL-инъекцией:

Route::get('a-bad-query-example', function() {
$name = "'Joshua' OR 1=1";
return DB::select(
DB::raw("SELECT * FROM users WHERE name = $name"));
});

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

Route::get('a-good-query-example', function() {
$name = "'Joshua' OR 1=1";
return DB::select(
DB::raw("SELECT * FROM users WHERE name = ?", [$name]));
});

В приведенном выше запросе мы фактически передаем знак вопроса с переменной запроса. Laravel может автоматически заменить знак вопроса на переменную запроса, что устраняет необходимость полагаться на escape-переменные. Это означает, что необработанный запрос к базе данных, как мы передали во втором случае, не очень подвержен атакам SQL.

Использование пакетов безопасности Laravel

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

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

  • Laravel Security – довольно популярный пакет, особенно когда речь идет об устранении уязвимостей XSS.
  • Laravel ACL – Laravel ACL может предлагать специфичные для роли разрешения для механизма аутентификации. Если ваше приложение использует методы контроллера CRUD, Laravel ACL является разумным выбором, который следует использовать.
  • Laravel Security Component (компонент безопасности) – LSC служит одной основной цели: он интегрирует ядро ​​безопасности Symfony в Laravel. После этого он позволяет разработчикам использовать проверку безопасности для конкретной роли, проверять права доступа и отслеживать лазейки, окружающие роли и объекты.

И еще кое-что…

Само собой разумеется, что вы должны делиться конфиденциальной информацией только через HTTPS для дополнительной безопасности. Кроме того, чтобы избежать атак XSS, часто разумно использовать синтаксис двойной скобки в шаблонах блейдов, например:

({{$ variable}})

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

Это в значительной степени подводит итог практики безопасности Laravel, которую нужно иметь в виду. Следует отметить, что при правильной настройке и регулярном обновлении Laravel является надежной средой, которая не страдает от широкого спектра проблем безопасности. Как разработчику Laravel, все, что нужно сделать – это убедиться, что атаки сценариев базы данных должным образом обойдены.


.

  • October 23, 2023