Wrz
27

header() to nie zabezpieczenie

autor: p____h  //  ::medium::, Security

Dzisiaj pod lupę postanowiłem zaciągnąć bardzo często używaną funkcję header(). Właściwie nie tyle samą funkcję,  co jej złe wykorzystanie. Oto jak wygląda kod, z którym zetknąłem się już kilka razy:

<?
if( !isset( $_SESSION['session']["authCode"] ) )
	header("Location: login.php");
echo "WTF is wrong with my awesome code?!";
?>

A poniżej słów kilka dlaczego jest on zły.

Wszystko na pierwszy rzut oka wygląda sympatycznie. Na początku sprawdzane jest, czy użytkownik został zalogowany – jeśli nie został, następuje przekierowanie go do formularza w pliku login.php. Zastanówmy się teraz jak działa to przekierowanie… a raczej, czy może działać inaczej niż byśmy tego chcieli. Okazuje się, że niestety tak.

Większość przeglądarek zostało zaprogramowane tak, żeby po otrzymaniu żądania przekierowania na inną stronę, po prostu przenosiły pod wskazany adres. Zobaczmy jednak co się stnie, gdy stronę odpala nie-przeglądarka.

Zaprezentowany powyżej kod wrzuciłem do /header/index.php. Spróbujemy uruchomić go za pomocą programu telnet i netcat.
telnet localhost 80
Ctrl + ]
set localecho
dwukrotnie [enter]
GET  /header/index.php HTTP/1.1
Host: localhost

Podobnie za pomocą netcata:
nc localhost 80
get /header/index.php http 1.1

W obu przypadkach widzimy to, czego teoretycznie widzieć nie powinniśmy. Na szczęście istnieje banalny sposób na „naprawienie” tego kodu. Pierwszy z nich jest oczywiście przerobienie if’a, na if/else. Drugi – zaraz po header() dopisanie die(), które zatrzyma wykonanie dalszego kodu (z poziomu przeglądarki nikt nie powinien się tam dostać).

  

5 komentarzy to “header() to nie zabezpieczenie”

  • a który sposób wg cb jest lepszy, die() czy else?????

  • Nie lubię niepotrzebnych klamerek otaczających duże bloki kodu – die() w tym przypadku wydaje się bardziej rozsądny – ale jak kto woli.

  • Podobnie można odpytać serwer poleceniem „curl” :]

  • Odkryłeś Amerykę… header służy do instruowania klienta, a zabezpieczenia stosuje się po stronie serwera, a nie klienta.

  • Nie przypominam sobie, żebym w którymkolwiek miejscu nazywał ten post odkryciem Ameryki. Czy jeśli Kolumb odkrył Amerykę, to według Ciebie nie powinno się przypominać o jej istnieniu ludziom? A może nie zaznaczajmy tej Ameryki wcale na mapach?

    Post ma charakter informacyjny – to prawda, że nie powinno się stosować zabezpieczeń po stronie klienta, jednak wiele osób o tym zapomina. O powyższym przykładzie tak często głośno się nie mówi (mówiąc szczerze, widzę pełno informacji, o SQL Inj., o XSS, ale o tym, że header() zabezpieczeniem nie jest – już nie). Także przykro mi, ale nie widzę w Twoim komentarzu, żadnego przekazu, oprócz próby zbudowania niepotrzebnej napinki, w którą wciągnąć się nie dam 🙂 Mimo wszystko zachęcam do dalszego czytania i komentowania mojego bloga.

Dodaj komentarz

*

Audio-CAPTCHA