CybersecuritySecurity

[Od zera do hakera] #0 – Co to jest protokół HTTP?

Safebit.pl | HTTP

Wstęp

Spróbuj sobie wyobrazić świat bez Facebook’a, Youtube’a, Google’a… Potrafisz to zrobić? Ja też nie. Wszystko to zaczęło się w 1989 roku, kiedy Tim Berners-Lee z CERN-u napisał pierwszą specyfikację protokołu HTTP, dzięki której nastąpił rozwój usług WWW. To właśnie dzięki protokołowi HTTP możemy dzisiaj przeglądać strony internetowe, robić zakupy przez Internet, robić przelewy w banku i wiele, wiele innych. Bez niego nasz świat wyglądałby całkiem inaczej.

Protokół HTTP

HyperText Transfer Protocol (HTTP) to podstawowy protokół komunikacyjny, dzięki któremu mamy dostęp do sieci World Wide Web (WWW) i jest używany przez wszystkie aplikacje webowe. Jest to prosty protokół, który oryginalnie był zaprojektowany do wymiany statycznych i tekstowych zasobów. Zasobem nazywamy tekst lub po prostu jakiś dokument tekstowy. Na stronie http://info.cern.ch/ możesz zobaczyć, jak wyglądała pierwsza strona WWW.

HTTP przeszedł długą drogę i został on wzbogacony o mechanizmy dostosowane do dzisiejszych potrzeb, dzięki czemu możemy dzisiaj przeglądać wideo, słuchać muzyki, a nawet grać w gry. Jest to protokół w modelu klient ↔ serwer, w którym wiele klientów łączy się z serwerem.

Safebit.pl | Protokół HTTP

Schemat działania

Protokół HTTP do działania używa komunikatów, gdzie klient wysyła komunikat żądania, a serwer odpowiada komunikatem odpowiedzi. Ważną rzeczą do odnotowania jest to, że jest to protokół bezstanowy (do wersji 2.0, która wprowadza znaczące zmiany w tym zakresie, jednak wersja 1.1 protokołu jest najbardziej rozpowszechniona w tym momencie), czyli nie ma żadnego łączenia między dwoma lub więcej żądaniami dla tego samego połączenia. Oznacza to, że gdyby nie inne mechanizmy kontrolne takie jak sesje czy cookies, nie moglibyśmy np. robić zakupów online, ponieważ przy każdym żądaniu musielibyśmy się logować.

Safebit.pl | Protokół HTTP

Chociaż sam rdzeń protokołu jest bezstanowy, to mechanizmy takie jak wspomniane sesje czy ciasteczka (cookies) pozwalają na korzystanie z protokołu w sposób bardziej dynamiczny, czyli możemy dodawać do koszyka swoje zakupy czy nie musimy się logować za każdym razem na jakąś stronę w celu uwierzytelnienia.

Żądanie HTTP

Wszystkie komunikaty, czy to żądania, czy odpowiedzi, zawierają w sobie jeden lub więcej nagłówków, każdy w osobnej linijce, zakończony pustą linijką i opcjonalnym ciałem (body) wiadomości. Pierwsza linijka każdego żądania HTTP zawiera 3 elementy, oddzielone spacją:

  • Metoda HTTP – Najbardziej popularną metodą jest metoda GET, która odpowiada za pobranie zasobów z serwera. Metoda GET nie posiada ciała (body) wiadomości, więc żądanie jest zakończone pustą linią
  • Adres URL – Wskazuje on na zasób jakie chcemy pobrać. Adres ten może posiadać dodatkowe parametry
  • Wersja protokołu HTTP – Najbardziej popularną wersją jest w tym momencie wersja 1.1, której domyślnie używają wszystkie przeglądarki. Dostępne są także starsza wersja 1.0 oraz nowsza 2.0

Kolejne linijki zawierają nagłówki żądania, czyli takie dodatkowe opcje, które określają charakter wiadomości. Na końcu jest jeszcze znak nowej linii (linia numer 10), który oddziela nagłówek i resztę żądania. W tym wypadku nie mamy ciała (body) wiadomości, ponieważ używamy metody GET.

Safebit.pl | Protokół HTTP

Odpowiedź HTTP

Typowa odpowiedź HTTP wygląda następująco:

Safebit.pl | Protokół HTTP

Pierwsza linijka odpowiedzi zawiera 3 elementy, oddzielone spacją:

  • Wersja protokołu HTTP
  • Status odpowiedzi – Numeryczna interpretacja dotycząca danego żądania. Jeżeli wszystko jest w porządku, to serwer zwraca status 200, jeżeli nie może znaleźć danego zasobu, wysyła status 404.
  • Tekstowa interpretacja statusu odpowiedzi – Nie jest ona brana pod uwagę przez najnowsze przeglądarki.

Kolejne linijki zawierają nagłówki odpowiedzi. Następnie jest znak nowej linii (linia numer 15) oraz ciało wiadomości (body message).

Nagłówki HTTP

Nagłówki HTTP pozwalają na wysłanie dodatkowych informacji, zarówno w kontekście żądania jak i odpowiedzi. Nagłówek składa się z nazwy, poprzedzoną znakiem „:” oraz z wartości tego nagłówka. Protokół HTTP wspiera dużą liczbę różnych nagłówków, ale nic nie stoi na przeszkodzie, żeby używać swoich własnych. Niektóre z nich są przeznaczone do specjalnych celów, a jeszcze inne mogą być użyte zarówno w żądaniach jak i w odpowiedziach.

Kilka przykładowych nagłówków żądania:

  • Accept – informuje serwer o typie danych, które serwer może odesłać. Mogą to być dokumenty, obrazki, pliki. Jest to typ MIME.
  • Accept-Encoding – informuje serwer jakiego rodzaju kodowania chce używać klient.
  • Authorization – wysyła dane logowania do serwera.
  • Cookie – wysyła cookies do serwera, które wcześniej nadał.
  • Referer – informuje serwer, z jakiego źródła odwołujemy się do danego zasobu
  • User-Agent – informuje serwer, z jakiej przeglądarki lub innego oprogramowania korzysta klient

Kilka przykładowych nagłówków odpowiedzi:

  • Server – dostarcza informacje na temat web serwera
  • Location – ten nagłówek jest używany w przekierowaniach, jego wartość wskazuje, na jaki zasób powinniśmy być przekierowani.
  • Set-Cookie – ustawia cookies, które jest odsyłane z powrotem do serwera wraz z kolejnymi żądaniami

Metody HTTP

Protokół HTTP posiada zestaw metod dla żądań, które mają na celu wskazanie akcji do wykonania dla danego zasobu. Zgodnie ze specyfikacją (RFC 7231) serwer musi obsługiwać metodę GET oraz OPTIONS. Reszta metod jest opcjonalna. Najczęstszymi metodami wykorzystywanymi do działania web aplikacji to GET oraz POST.

Metoda GET służy do pobierania zasobów. Może ona też być wykorzystana do przesłania parametrów dla danego zasobu jako URL query string (np. www.przyklad.com/strona?parametr1=wartosc1&parametr2=wartosc2). W tej metodzie, pełny adres URL wraz z parametrami jest wyświetlany w przeglądarce, a także jest zapisywany w logach serwera www czy historii przeglądarki. Jest to dosyć istotna kwestia, ponieważ przechowując np. dane logowania w takim adresie, to istnieje ryzyko wycieku tych danych (własnie z logów serwera lub historii przeglądarki).

Metoda POST jest wykorzystywana do wykonywania akcji. Za pomocą tej metody, parametry mogą być wysyłane również za pomocą adresu URL, ale także jako body wiadomości. Wszystkie zapytania z body wiadomości nie są zapisywane w historii przeglądarki czy logach serwera www (ale sam URL i jego parametry już tak). Dlatego też, tę metodę wykorzystuje się do przesyłania danych, np. logowania.

Protokół HTTP wspiera także inne metody HTTP. Oto kilka z nich:

  • HEAD – działa podobnie do metody GET, jednak za jego pomocą serwer powinien zwrócić tylko nagłówek odpowiedzi. Żadne inne dane nie powinny być zwracane.
  • TRACE – został on zaprojektowany głównie dla celów diagnostycznych.
  • OPTIONS – nagłówek ten prosi serwer o wykazanie dostępnych metod, które mogą być użyte do dalszej komunikacji
  • PUT – służy do przesyłanie danych na serwer, używając zawartość pliku jako body wiadomości. Jeżeli ta metoda jest włączona, może ona w pewnych przypadkach prowadzić do wgrania dowolnego kodu na serwer.
  • DELETE – służy on do usuwania zasobów

Istnieje jeszcze wiele innych metod, jednak są one rzadziej wykorzystywane.

URL

Uniform Resource Locator (URL) to unikalny identyfikator dla danego zasobu, dzięki któremu, dany zasób może być pobrany. Format większości adresów URL wygląda następująco:

protokół://hostname[:port]/ścieżka/plik[?parametr=wartość]

Niektóre z komponentów adresu URL są opcjonalne. Np. port jest zazwyczaj dołączany, kiedy jest inny dla danej technologi. Np. domyślnym portem dla HTTP jest port 80, dla FTP 21, dla HTTPS 443 itp. Jeżeli nie wskażemy innego portu, będą używane własnie domyślne dla danej technologi. Jeżeli mamy serwer www na porcie 80 to wystarczy, że wpiszemy www.strona.pl i przeglądarka wie już, że domyślnym portem jest port 80. Ale jeżeli serwer działa np. na porcie 8080 no to wtedy musimy już zdefiniować ten port, np. www.strona.pl:8080.

Przykładowym adresem, zgodnie z wyżej wypisanych formatem może być:

https://www.strona.pl/plik.php?parametr1=wartosc1

Kody statusów

Każda odpowiedź HTTP, musi zawierać kod statusu, który jest zawarty w pierwszej linijce odpowiedzi. Kody statusów są podzielone w pięć różnych grup w zależności od rodzaju i pierwszej liczby kodu odpowiedzi.

  • 1xx – Informacyjne
  • 2xx – Zapytanie było poprawne
  • 3xx – Klient jest przekierowywany do innego zaosbu
  • 4xx – Zapytanie zawiera jakiś błąd
  • 5xx – Zapytanie spowodowało błąd serwera

Safebit.pl | HTTP Status

Najczęstszymi statusami, z którymi możemy się zetknąć w codziennej pracy to:

  • 200 OK – mówi nam, że zapytanie było poprawne i otrzymaliśmy zawartość żądanego zasobu
  • 201 Created – jest on zwracany w odpowiedzi na zapytanie PUT, czyli informuje nas, że plik został przesłany i umieszczony na serwerze
  • 301 Moved Permanently – przekierowuje przeglądarkę na inny URL, który jest zdefiniowany w nagłówku Location. Klient w przyszłości powinien używać nowego adresu URL.
  • 302 Found – przekierowuje przeglądarkę na inny URL, który jest zdefiniowany w nagłówku Location. Klient w przyszłości powinien używać starego adresu URL.
  • 304 Not Modified – instruuje przeglądarkę, aby użyła zapisaną kopie danego zasobu, zamiast prosić serwer o ten sam zasób.
  • 400 Bad Request – status ten oznacza, że nasz klient wysłał błędne zapytanie.
  • 401 Unauthorized – informuje on klienta, że serwer wymaga autoryzacji, aby wysłać odpowiedź na dane żądanie.
  • 403 Forbidden – informuje klienta, że nie ma dostępu do żądanego zasobu.
  • 404 Not Found – żądany zasób nie może być znaleziony
  • 500 Internal Server Error – informuje klienta, że na serwerze wystapił jakiś błąd, który uniemożliwia zwrócenie żądanego zasobu

Cookies i sesje

Cookies są kluczową częścią protokołu HTTP, z których korzysta większość aplikacji webowych czy zwykłych stron internetowych. Mechanizm ciasteczek pozwala na przechowywanie informacji między dwoma żądaniami HTTP. Jeżeli klient wyśle 2 razy to samo żądanie bez nagłówka Cookies, to serwer nie ma pojęcia, że to ten sam klient. Opieranie się na np. tylko adresie IP jest nieefektywne, ponieważ w sieciach korporacyjnych, wiele komputerów łączy się z tego samego adresu IP.

Cookies są wysyłane przez serwer za pomocą nagłówka Set-Cookie, np:

Set-Cookie: SessionID=1234

Wtedy przeglądarka automatycznie, niezależnie od aplikacji czy samego użytkownika, dokleja do każdego zapytanie nagłówek w postaci:

Cookie: SessionID=1234

Ciasteczka z reguły zawierają parę klucz = wartość, jednak tak na prawdę można je wysyłać w dowolnej postaci, jednak nie może ono zawierać znaku spacji. Można także nadać kilka ciastek jednocześnie, używając nagłówka Set-Cookie kilka razy. Wtedy przeglądarka również dołączy nam te wszystkie ciasteczka i będą one wysyłane z każdym zapytaniem. Same cookies mogą również posiadać dodatkowe opcje, takie jak:

  • expires – ustawia datę, do kiedy dane ciastko jest ważne. Opcja ta wymusza na przeglądarce zapis tego ciastka na dysku i doklejenia go do każdego zapytania dopóty, dopóki nie zostanie osiągnięta data wygaśnięcia.
  • domain – definiuje, dla jakiej domeny dane ciastko jest ważne.
  • path – definiuje, dla jakiej ścieżki dane ciastko jest ważne.
  • secure – jeżeli ta opcja jest ustawiona, to te ciastko będzie mogło być przesyłane tylko za pomocą protokołu HTTPS
  • HttpOnly – jeżeli ta opcja jest ustawiona, to ciastko nie może być przesyłane bezpośrednio poprzez inny mechanizm niż HTTP (np. JavaScript)
  • SameSite – flaga ta pozwala serwerom wymagać, aby plik cookie nie był wysyłany z żądaniami obejmującymi wiele domen, co zapewnia pewną ochronę przed atakami typu CSRF.

Sesje

Sesje to mechanizm, które używają cookies jako warstwy transportowej. Główny problem z ciasteczkami jest taki, że każdy może je dowolnie zmieniać po stronie klienta. Gdyby mechanizm danej aplikacji polegał na tym, że bierze z cookies nazwę użytkownika i za jego pomocą nas autoryzuje no to można sobie wyobrazić, że zmieniamy nazwę z kamil na admin i zostajemy adminami. Dlatego, żeby uniknąć takich sytuacji używa się sesji.

Plik cookie odesłany z serwera do użytkownika zawiera identyfikator sesji. Gdy użytkownik odsyła ciasteczka z powrotem w kolejnych żądaniach, aplikacja używa tego identyfikatora sesji, aby uzyskać dostęp do informacji przechowywanych lokalnie na serwerze. Informacje te mogą być przechowywane w pliku, bazie danych lub w pamięci. Niektóre mechanizmy sesji również szyfrują dane ze względów bezpieczeństwa.

Backend

Na początku istnienia sieci WWW strony zawierały tylko statyczną zawartość. Taka strona zawierała zwykły dokument HTML oraz czasami jakiś obrazek, który był ładowany bezpośrednio z serwera i dostarczany bezpośrednio do przeglądarki. Dzisiaj również mamy statyczne strony, jednak w dużej mierze zawartość stron jest generowana dynamicznie.

Dynamiczny kontent jest generowany przez skrypty lub program uruchomiony na serwerze. Skrypty te same w sobie przypominają programy komputerowe. Mają dane wejściowe, na których wykonują odpowiednie akcje i zwracają odpowiedź do użytkownika.

Kiedy użytkownik, za pomocą swojej przeglądarki, wyślę żądanie po jakiś dynamiczny zasób, zwykle nie wysyła prostego żądania, tylko zawiera w sobie dodatkowe parametry. Dzięki tym parametrom, serwer przygotowuje dynamiczną odpowiedź dla każdego użytkownika.

Aplikacja może także wykorzystywać nagłówki protokołu HTTP jako dodatkowe opcje. Np. nagłówek User-Agent może być używany do wyświetlania odpowiedniej strony w zależności od tego, z jakiej przeglądarki korzystamy (desktopowa czy mobilna). Web aplikacje mogą wykorzystywać jedną z wielu technologi serwerowych takich jak:

  • Języki skryptowe takie jak PHP, Python, VBScript, Perl
  • Platformy aplikacyjne takie jak ASP.NET, Java
  • Web serwery takie jak Apache, Nginx, IIS
  • Bazy danych takie jak MySQL, MSSQL, Oracle
  • Bazy NoSQL takie jak MongoDB, Redis

Frontend

Frontend witryny jest tym, co widzisz i co robisz w przeglądarce. Określany również jako client-side (po stronie klienta), obejmuje wszystko, czego użytkownik bezpośrednio doświadcza: od tekstu i kolorów po przyciski, obrazy i menu nawigacyjne. Można do tego zaliczyć zarówno formę graficzną jak i technologie po stronie klienta, takie jak np. HTML, CSS, JavaScript.

SOP

SOP (Same-Origin Policy) to mechanizm bezpieczeństwa przeglądarki internetowej, którego celem jest zapobieganie wzajemnemu atakowaniu stron internetowych.

SOP ogranicza dostęp skryptów z jednego źródła do danych z innego źródła. Źródło (Origin) składa się ze schematu URI, domeny i numeru portu. Na przykład rozważ następujący adres URL:

http://safebit.pl/przyklad/przyklad.html

Używany jest tutaj schemat http, domena safebit.pl i numeru portu 80 (nie widać go w tym przykładzie, ponieważ jest to domyślny port). Poniższa tabela pokazuje, w jaki sposób zastosowane zostaną zasady tego samego źródła, jeśli strona z wyżej podanego adresu URL spróbuje uzyskać dostęp do innych źródeł:

URL Przyznano dostęp?
http://safebit.pl/przyklad/ Tak: taki sam schemat, domena i port
http://safebit.pl/przyklad/ Tak: taki sam schemat, domena i port
https://safebit.pl/przyklad/ Nie, inny schemat i port (443)
http://en.safebit.pl/przyklad/ Nie: inna domena
http://www.safebit.pl/przyklad/ Nie: inna domena
http://safebit.pl:8080/przyklad/ Nie: inny port *

*Internet Explorer zezwoli na ten dostęp, ponieważ IE nie bierze pod uwagę numeru portu podczas stosowania mechanizmu SOP.

Dlaczego jest to ważny i potrzebny mechanizm?

Gdy przeglądarka wysyła żądanie HTTP z jednego źródła do drugiego, wszelkie pliki cookie, w tym pliki cookie sesji uwierzytelniania, istotne dla drugiej domeny, są również wysyłane jako część żądania. Oznacza to, że odpowiedź zostanie wygenerowana w sesji użytkownika i będzie zawierać wszelkie istotne dane charakterystyczne dla użytkownika. Bez mechanizmu SOP, jeśli odwiedziłbyś / odwiedziłabyś złośliwą stronę internetową, byłby ona w stanie odczytać twoje wiadomości e-mail z Gmaila, prywatne wiadomości z Facebooka itp.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *