Apache 2.4 – o jeden slash od otwartego przekierowania
Napisał: Patryk Krawaczyński
20/08/2017 w Bezpieczeństwo Brak komentarzy. (artykuł nr 634, ilość słów: 379)
Bardzo często zdarza się, że dla lepszych wyników SEO stosuje się przekierowanie 301 z subdomeny www na “czystą” domenę np. z www.openredirect.pl na openredirect.pl. W serwerze Apache jednym z sposobów na uzyskanie tego efektu jest wykorzystanie dyrektywy Redirect pochodzącej z modułu alias:
<VirtualHost *:80>
ServerName www.openredirect.pl
Redirect 301 / http://openredirect.pl
</VirtualHost>
I rzeczywiście, jeśli odpytamy o taki adres otrzymamy przekierowanie 301:
agresor@darkstar~$ curl -v -XGET http://www.openredirect.pl * Trying 1.2.3.4... * Connected to www.openredirect.pl (1.2.3.4) port 80 (#0) > GET / HTTP/1.1 > Host: www.openredirect.pl > User-Agent: curl/7.43.0 > Accept: */* > < HTTP/1.1 301 Moved Permanently < Date: Wed, 16 Aug 2017 14:24:39 GMT < Server: Apache < Location: http://openredirect.pl < Content-Length: 232 < Content-Type: text/html; charset=iso-8859-1 < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="http://openredirect.pl">here</a>.</p> </body></html> * Connection #0 to host www.openredirect.pl left intact
Jednak diabeł jak zawsze tkwi w szczegółach. Jedną z wad Apache jest jego różne podejście do końcowego slasha. Dlatego w dokumentacji modułu alias należy szczególną uwagę zwrócić na zdanie: “Additional path information beyond the matched URL-path will be appended to the target URL.” Dlaczego? Ponieważ wystarczy teraz wywołać odpowiednio spreparowany adres URL, aby wykazać że nasz serwer stał się podatny na otwarte przekierowanie (ang. open redirect), które może zostać wykorzystane np. do phishingu:
agresor@darkstar~$ curl -v -XGET http://www.openredirect.pl/.nfsec.pl * Trying 1.2.3.4... * Connected to openredirect.pl (1.2.3.4) port 80 (#0) > GET /.nfsec.pl HTTP/1.1 > Host: openredirect.pl > User-Agent: curl/7.43.0 > Accept: */* > < HTTP/1.1 301 Moved Permanently < Date: Wed, 16 Aug 2017 14:15:58 GMT < Server: Apache < Location: http://openredirect.pl.nfsec.pl < Content-Length: 234 < Content-Type: text/html; charset=iso-8859-1 < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="http://openredirect.pl.nfsec.pl">here</a>.</p> </body></html> * Connection #0 to host www.openredirect.pl left intact
Co się właśnie stało? Przecież spodziewaliśmy się adresu: http://openredirect.pl/.nfsec.pl. Otóż błąd został popełniony w linii:
Redirect 301 / http://openredirect.pl
A dokumentacja modułu wyraźnie mówi, że wszystkie dodatkowe elementy ścieżki wykraczające poza dopasowany adres URL zostaną dołączone do docelowego adresu URL. Dlatego adres openredirect.pl + .nfsec.pl = openredirect.pl.nfsec.pl. Apache w tej sytuacji niestety sam nie doda znaku slash “/” oddzielającego wartości przekierowania od treści użytkownika i należy zadbać o to samemu:
<VirtualHost *:80>
ServerName www.openredirect.pl
Redirect 301 / http://openredirect.pl/
</VirtualHost>
Więcej informacji: URL Redirection to Untrusted Site (Open Redirect)
K a t e g o r i e : Bezpieczeństwo
T a g i : 301, apache, httpd, open, phishing, redirect, unvalidated
