Wie konfiguriere ich SSL mit Laravel 5 hinter einem Load Balancer (ssl_termination)?

Question

Ich habe ein Laravel 5-Projekt für AWS EC2-Webinstanzen hinter einem ELB mit SSL-Terminierung implementiert.

Für Dinge wie Assets verwendet Laravel standardmäßig das Schema, das derzeit verwendet wird. Allerdings ist mir aufgefallen, dass der https-Verkehr vom ELB entschlüsselt und über http an die EC2-Knoten weitergeleitet wird. Laravel glaubt nicht, dass er https verwendet und nutzt daher http für Assets. Dies verursacht offensichtlich Probleme.

Von was ich gefunden habe, prüft Laravel für diese Art von Proxy-Setup mit dem Header X_FORWARDED_PROTO. Ich habe jedoch gefunden, dass dieser Header nicht existiert und stattdessen gibt es einen HTTP_X_FORWARDED_PROTO Header. In researching this habe ich festgestellt, dass das Voranstellen von "HTTP_" etwas ist, was PHP tut. Wenn das stimmt, warum überprüft Laravel dann nicht, da es sich um ein reines PHP-Framework handelt?

Ich habe Artikel lesen etwas sagen wie Fideloper's Trusted Proxies zu verwenden, aber es ist unklar, warum Laravel ist standardmäßig nicht für diese Header zu überprüfen.

Wie kann ich Laravel konfigurieren, um HTTP_X_FORWARDED_ * Header zu akzeptieren, oder anders konfigurieren, um zu wissen, dass mein aktuelles Schema https ist?

Answer 1

Laravel überprüft diese nicht standardmäßig, da diese Header trivial in eine Anfrage eingefügt werden können (d. H. Gefälscht) und dies einen theoretischen Angriffsvektor in Ihre Anwendung erzeugt. Ein böswilliger Benutzer kann Laravel denken lassen, dass eine Anfrage nicht sicher ist, was wiederum dazu führen könnte, dass etwas kompromittiert wird.

Als ich in das gleiche Problem lief ein paar Monate mit Laravel zurück 4.2, meine Lösung, die eine individuelle Anfrage Klasse zu erstellen war und sagen Laravel, es zu benutzen ihr

#File: bootstrap/start.php 
//for custom secure behavior -- laravel autoloader doesn't seem here yet? 
require_once realpath(__DIR__) . 'path/to/my/MyCustomRequest.php'; 

Illuminate\Foundation\Application::requestClass('MyCustomRequest'); 

und dann in MyCustomReuqestClass, ich erweitert die Basisanforderungsklasse und Extra ist/ist-nicht sichere Logik

class Request extends \Illuminate\Http\Request 
{ 
    /** 
    * Determine if the request is over HTTPS, or was sent over HTTPS 
    * via the load balancer 
    * 
    * @return bool 
    */ 
    public function secure() 
    {   
     $secure = parent::secure(); 
     //extra custom logic to determine if something is, or is not, secure 
     //... 
     return $secure; 
    }  

    public function isSecure() 
    { 

     return $this->secure(); 
    } 
} 

ich dies tun würde nicht jetzt hinzugefügt. Nachdem ich einige Monate mit dem Framework gearbeitet hatte, wurde mir klar, dass Laravels Anfrageklasse die Symfony-Anfrageklasse als Elternteil hat, was bedeutet, dass eine Laravel-Anfrage das Verhalten eines Symfony-Anfrageobjekts erbt.

Das heißt, Sie können Laravel sagen, welche Proxy-Server mit so etwas wie dieses

Request::setTrustedProxies(array(
    '192.168.1.52' // IP address of your proxy server 
)); 

Dieser Code vertrauen sollte erzählt Laravel die Proxy-Server sollten ihm vertrauen. Danach sollte es die standardmäßigen Header "forward for" übernehmen. Sie können mehr über diese Funktionalität in der Symfony docs lesen.