Middleware — это не что-то новое. Мы уже давно используем его в наших приложениях для различных применений, от аутентификации до авторизации и не только.
В этой статье рассмотрим, как вы можете использовать возможности middleware в вашем приложении Laravel, чтобы повысить безопасность ваших приложений. Вы можете добавить в свое приложение бесчисленное множество заголовков, которые делают разные вещи. Давайте погрузимся в несколько различных заголовков безопасности, чтобы увидеть, что они делают и что мне нравится делать в своих приложениях.
Первое, что мы хотим сделать, думая о безопасности в нашем приложении Laravel, это подумать о заголовках, которые мы не хотим раскрывать. Как правило, ваше приложение по умолчанию показывает следующие заголовки:
X-Powered-By — это отобразит технологический стек, на котором работает ваше приложение.
server/Server — это покажет серверную технологию, на которой запущено ваше приложение. Например, apache или nginx.
Первое, что мы хотим здесь сделать, это удалить эти заголовки.
Выглядит следующим образом:
final class RemoveHeaders
{
public function handle(Request $request, Closure $next): Response
{
/**
* @var Response $response
*/
$response = $next($request);
/**
* @var string $header
*/
foreach ((array) config('headers.remove') as $header) {
$response->headers->remove(
key: $header,
);
}
return $response;
}
}
Этот middleware проходит через настроенные заголовки в моем конфигурационном файле и гарантирует, что они удалены из ответа, прежде чем вернуть его пользователю.
Следующее, что я обычно делаю — устанавливаю заголовок Referrer-Policy на значение no-referrer-when-downgrade, когда запрос возвращается к тому же источнику — но не для любых запросов с перекрестным источником. Я делаю это, используя другую часть middleware:
final class SetReferrerPolicy
{
public function handle(Request $request, Closure $next): Response
{
/**
* @var Response $response
*/
$response = $next($request);
$response->headers->set(
key: 'Referrer-Policy',
values: config('headers.referrer-policy),
);
return $response;
}
}
Я разделил эти действия на отдельные классы middleware, чтобы уточнить уровень, который важен для меня в отношении безопасности на каждом маршруте. Я хочу быть более открытым для некоторых маршрутов, в то время как я хочу, чтобы они были немного менее открытыми для других.
Давайте поговорим о заголовке Strict-Transport-Security. Это сообщит клиенту или браузеру о необходимости подключения к нашему приложению по протоколу HTTPS и о том, как долго должно действовать это правило. Этот заголовок помогает защитить пользователей вашего приложения от атак типа "человек посередине". Вы также можете добавить includeSubDomains в этот заголовок, указав браузеру применить эту политику ко всем поддоменам сайта.
final class StrictTransportSecurity
{
public function handle(Request $request, \Closure $next): Response
{
/**
* @var Response $response
*/
$response = $next($request);
$response->headers->set(
key: 'Strict-Transport-Security',
values: config('headers.strict-transport-security'),
);
return $response;
}
}
Следующий заголовок, который мне нравится — это заголовок Content-Security-Policy, один из наиболее часто используемых. Я не создавал специальный middleware для этого, так как у Spatie есть пакет, который вы можете использовать.
Ваш SSL-сертификат может иметь разные уровни прозрачности для ваших пользователей. Этот механизм публичного ведения журнала позволит любому контролировать выдачу сертификата. Это поможет обнаружить и предотвратить такие вещи, как поддельные сертификаты. Он также имеет различные варианты конфигурации:
max-age укажет максимальное время в секундах, в течение которого браузер должен запоминать политику.
enforce укажет, хотите ли вы, чтобы браузер применял политику. Если мы установим значение true, браузер не разрешит SSL-соединения с вашим приложением.
report-uri укажет URL-адрес, по которому браузер должен отправлять любые сообщения о нарушениях политики CT вашего приложения.
Давайте посмотрим на middleware для этого и посмотрим, что мы хотим сделать:
final class CertificateTransparencyPolicy
{
public function handle(Request $request, \Closure $next): Response
{
/**
* @var Response $response
*/
$response = $next($request);
$response->headers->set(
key: 'Expect-CT',
values: config('headers.certificate-transparency'),
);
return $response;
}
}
Как видите, некоторые из этих классов middleware просты. Их сочетание даст вам наилучшую защиту от потенциальных атак.
Последний middleware, которой мы хотим рассмотреть — это заголовок Permissions-Policy. Мы можем использовать этот заголовок, чтобы сообщить браузеру, какие функции и API разрешено использовать браузеру. Это поможет защитить вас от XSS-атаки или клик-джекинга.
final class PermissionsPolicy
{
public function handle(Request $request, \Closure $next): Response
{
/**
* @var Response $response
*/
$response = $next($request);
$response->headers->set(
key: 'Permissions-Policy',
values: config('headers.permissions-policy'),
);
return $response;
}
}
Используя этот middleware, я могу быть конкретным в отношении функций, которые я хочу включить, а это означает, что я могу обеспечить большую безопасность для своего конечного пользователя и себя.
Еще один отличный пакет, который вы можете проверить — это Laravel Security Headers.