Browsed by
Month: October 2015

Metoda PATCH

Metoda PATCH

Zajmiemy się także metodą PATCH. Nie jest ona wprawdzie częścią standardu HTTP, jednak dość dobrze uzupełnia go w kwestii operacji częściowego aktualizowania danych. Przypomnijmy, że metoda PUT służy do zastąpienia danego zasobu, zaś POST do jego wstawienia. W sytuacji, gdy potrzebujemy zaktualizować tylko kilka właściwości rekordu, zastosujemy metodę PATCH.

W treści wiadomości PATCH znajduje się ciąg informacji o tym, jakie pole i w jaki sposób zmienić. Jeżeli wskazywany zasób jeszcze nie istnieje, może on zostać utworzony, jeżeli informacje o zmianach zawierają wszelkie wymagane parametry.

PATCH /resource HTTP/1.1
Host: www.example.com
Content-Type: application/json
If-Match: "a1b2c3d4"

[
  { "op": "replace", "path": "/prop", "value": 42 },
]

Z uwagi na to, że niektóre instrukcje zmiany wartości bazują na poprzedniej wartości danej właściwości (np. dołączenie tekstu) spory problem może stanowić równoczesne wykonywanie tych operacji. Stan po wykonaniu różnych operacji może nie być jednoznacznie określony, więc szczególnie istotne jest korzystanie z zapytań warunkowych.

Kolejną istotną właściwością tego typu operacji jest jej atomowość. Zestaw zmian zdefiniowany w zapytaniu powinien być naniesiony w całości lub w ogóle.

Wyróżniamy dwie możliwości sprawdzenia, czy możliwe jest używanie metody PATCH dla danego zapytania:

  • Użycie metody OPTIONS,
  • Odczytanie nagłówka Accept-Patch w odpowiedzi serwera.

Jak widać w powyższym przykładzie treść wiadomości PATCH powinna mieć specjalny format. Wynika to z charakteru omawianej metody i tego, że obsługuje ona tylko informacje o zmianach. Jeden z możliwych formatów wiadomości jest opisany w standardzie http://tools.ietf.org/html/rfc6902 Wygląda on następująco:

[
  { "op": "test", "path": "/prop", "value": "foo" },
  { "op": "remove", "path": "/prop" },
  { "op": "add", "path": "/prop", "value": [ "foo", "bar" ] },
  { "op": "replace", "path": "/prop", "value": 12 },
  { "op": "move", "from": "/prop", "path": "/prop2" },
  { "op": "copy", "from": "/prop", "path": "/prop2" }
]

Możliwe operatory to:

  • Add
  • Remove
  • Replace
  • Move
  • Copy
  • Test

Są to informacje o zmianach w formacie JSON. Możliwe jest także przesyłanie delt dla zmian w formacie XML http://tools.ietf.org/html/rfc5261, jednak nie będziemy się tym szerzej zajmować.

Istnieje wiele implementacji mechanizmu PATCH. Przykładem implementacji dla .NET jest https://github.com/myquay/JsonPatch

Informacje dodatkowe:

http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/
https://www.mnot.net/blog/2012/09/05/patch

Metoda CONNECT

Metoda CONNECT

Za pomocą tego zapytania można połączyć się do serwera pośredniego w drodze do serwera docelowego. Jest to niezbędne, gdy dwa węzły nie są bezpośrednio ze sobą powiązane (np. istnieje zapora sieciowa). Stwarza to wrażenie bezpośredniego połączenia. Często są one wykorzystywane do tworzenia połączenia pomiędzy adresami, które są połączone poprzez jedno lub wiele proxy. Taka komunikacja może być zabezpieczona za pomocą TLS (metoda szyfrowania połączenia).
Wysyłając zapytanie CONNECT należy tylko przekazać docelowy adres, do którego chcemy się połączyć.

CONNECT example.com:80 HTTP/1.1
 Host: example.com:80

Serwer proxy, który odbierze to zapytanie, może wykonać kolejne zapytanie CONNECT, łącząc się do kolejnego proxy i tworząc w ten sposób łańcuch połączeń. Po ustanowieniu połączenia, zwracany jest status 200 (OK), zaś status 400 (Bad request) zwracany jest wtedy, gdy serwer nie obsługuje funkcji serwera proxy. Od momentu otrzymania rezultatu o powodzeniu operacji, pośrednie serwery proxy zmieniają tryb pracy na tunelowanie przechodzących wiadomości. W przypadku zamknięcia połączenia w jakimkolwiek serwerze biorącym udział w operacji, cały tunel powinien zostać zamknięty.

Możliwa jest także autoryzacja przy korzystaniu z proxy. Należy do tego celu użyć nagłówka Proxy-Authorization

CONNECT server.example.com:80 HTTP/1.1
 Host: server.example.com:80
 Proxy-Authorization: basic aGVsbG86d29ybGQ=

Istnieje niebezpieczeństwo niepoprawnego działania tunelowanego połączenia, gdy skorzystamy z powszechnie używanych portów do innych celów niż standardowo przyjęte. Dla przykładu, gdy używamy portu 25 standardowo przypisanego obsłudze SMTP, serwer może odrzucać część naszej komunikacji jako spam emailowy. Z uwagi na to serwery proxy powinny używać zdefiniowanego zakresu portów, aby nie powodować tego typu kolizji.

Metoda TRACE

Metoda TRACE

Metoda ta jest używana do zdalnego śledzenia wywołań wszelkich innych metod HTTP. Zapytanie powinno odwzorowywać badaną wiadomość z wyłączeniem pewnych wrażliwych pól (np. autoryzacyjnych).

Odpowiedź powinna:

  • mieć typ: message/http,
  • odesłać z powrotem niezmienione, wszystkie nagłówki zapytania,
  • nie odsyłać treści wiadomości
  • dodać nagłówek diagnostyczny.

Wiadomość ta może zostać wysłana zarówno do adresata, jak i serwerów pośrednich (np. proxy). Z tego też powodu, nie powinny być za jej pośrednictwem przesyłane żadne wrażliwe informacje w nagłówkach zapytania (takiej jak ciasteczka lub dane autoryzacyjne).
TRACE umożliwia prześledzenie ciągu przekazywania zapytania. Używany jest do tego nagłówek Via. Są w nim zapisane dane serwera, który bezpośrednio odesłał odpowiedź w ciągu informacyjnym. Wiele pól w nagłówku Via pokazuje ścieżkę którą przebyła wiadomość. Zazwyczaj przez serwery proxy. Dodatkowo przy każdej nazwie serwera widać wersję protokołu HTTP.

Via: 1.0 fred, 1.1 p.example.net

Użycie nagłówka Max-Forwards pozwala klientowi przez ile serwerów proxy chcemy przesłać wiadomość. Kiedy, liczba serwerów proxy będzie większa, zostanie zwrócony błąd.

Request Response
TRACE / HTTP/1.1
Host:www.apache.org
X-Header: Test
HTTP/1.1 200 OK
Date: Wed, 09 Jun 2010 16:14:49 GMT
Server: Apache/2.2.12 (Unix)
Transfer-Encoding: chunked
Content-Type: message/http
TRACE / HTTP/1.1
Host: http://www.apache.org
X-Header: Test

Cross Site Tracing

Jednym z bardziej wartościowych zasobów dla atakujących podczas pracy ze stronami www są ciasteczka. Często przechowują one wrażliwe dane takie jak identyfikator sesji użytkownika, nazwę jego konta lub informacje uwierzytelniające. Dysponując takimi danymi intruz może próbować podszyć się pod użytkownika naszej strony.

Aby temu przeciwdziałać wprowadzono opcję httpOnly dla ciasteczek. Powoduje ona, że niemożliwe jest odczytanie wartości ciasteczek z poziomu JavaScript. Jest to zabezpieczenie przed atakami XSS. Jednak w 2003 roku Jeramiah Grossman odkrył jak obejść to zabezpieczenie stosując metodę TRACE. Z uwagi na specyfikę tej metody, a mianowicie fakt, że odsyła ona w swojej treści całą wysłaną wiadomość, można wykonać zapytanie TRACE do serwera aplikacji. Zostaną do niego automatycznie dodane ciasteczka dostępne dla strony, a w rezultacie powrócą one wraz z odpowiedzią, co spowoduje ich ujawnienie osobie atakującej.

function sendTrace () 
{ 
   var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP"); 
   xmlHttp.open("TRACE", "http://foo.bar",false); 
   xmlHttp.send(); 
   xmlDoc=xmlHttp.responseText; 
   alert(xmlDoc); 
}

Z tego powodu w tej chwili zalecane jest wyłączenie tej metody na serwerach produkcyjnych.

Źródła:
http://tools.ietf.org/html/rfc7231
http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
https://www.owasp.org/index.php/Cross_Site_Tracing

Metoda DELETE

Metoda DELETE

Metoda DELETE oznacza żądanie skasowania adresu URL, do którego odwołujemy się w zapytaniu. Nie musi to oznaczać skasowania zasobu (choć może), ale musi się wiązać z dezaktywacją adresu URL do niego prowadzącego. Zasób nie musi być kasowany, gdy jest wskazywany również przez inne adresy.
Metoda DELETE jest najczęściej używana w połączeniu z PUT z uwagi na to, że operują one na unikalnym adresie, który identyfikuje używany przez nas zasób.

Jeżeli operacja kasowania odnośnika powiedzie się, powinien zostać zwrócony rezultat

  • 202 (Accepted), gdy zasób nie został skasowany,
  • 204 (No content), jeżeli został on skasowany i operacja nie zwróciła żadnej wartości,
  • 200 (OK), gdy zasób został skasowany i zwrócono wynik operacji.
Request Response
DELETE /articles/red-shoe HTTP/1.1 
Host: www.example.com
HTTP/1.1 204 No Content
Metoda PUT

Metoda PUT

Metoda PUT służy do zachowania obiektu przekazywanego w treści zapytania pod wskazanym adresem URL.

  • W przypadku gdy pod tym adresem istniał już zasób, powinien on zostać nadpisany. Zwracany jest wtedy rezultat 200 (OK) lub 204 (No Content), gdy nastąpiło nadpisanie pustym zbiorem.
  • Jeżeli zasób nie istniał, to powinien zostać utworzony pod podanym adresem. Zwracany jest wtedy rezultat 201 (Created)
    PUT /article/1234 HTTP/1.1
PUT /article/1234 HTTP/1.1
{ "color": "red" }

Gdy metoda PUT zakończy się powodzeniem, wykonanie metody GET dla tego samego adresu powinno zwrócić dokładnie ten sam obiekt jaki był użyty w PUT. Oczywiście tylko wtedy, gdy zasób ten nie został zmodyfikowany w międzyczasie. Warto też wspomnieć, że metoda PUT jest idempotentna, a więc wielokrotne jej wykonanie powinno przynieść identyczny rezultat.

Format treści zapytania PUT powinien być zgodny z typem wiadomości zwracanej przez metodę GET. W odpowiedzi serwer może wysłać nagłówki walidacyjne takie jak ETag i Last-Modified, jeżeli wartość zasobu jest identyczna z wartością wysłaną. PUT może także modyfikować dodatkowe zasoby poza wskazanym adresem, aby na przykład uaktualnić relacje między zasobami.

Różnice pomiędzy PUT i POST

Istnieje kilka podstawowych różnic pomiędzy tymi dwoma metodami:

  • Treść zapytania POST może mieć dowolna formę, którą serwer potrafi zinterpretować, podczas gdy w metodzie PUT treść powinna być taka sama jak treść modyfikowanego zasobu.
  • Metoda PUT jest idempotentna, ponieważ dotyczy tylko zasobu o konkretnym adresie, a POST może tworzyć zasoby pod kolejnymi adresami.
  • PUT zakłada znajomość docelowego adresu zasobu, co jest niemożliwe w przypadku wstawiania rekordu, dla którego zostanie wygenerowany numer id. Natomiast w metodzie POST nie podajemy adresu, gdyż jest on generowany po stworzeniu danego zasobu (patrz przykład poniżej).
Request Response
PUT /articles/red-shoe HTTP/1.1
 { name: "shoe", color: "red" }
HTTP/1.1 201 Created
 Location: /articles/red-shoe
Request Response
POST /articles HTTP/1.1
 { name: "shoe", color: "red" }
HTTP/1.1 201 Created
 Location: /articles/63636

Źródła:
http://tools.ietf.org/html/rfc7231#section-4.3.4

Metoda HEAD

Metoda HEAD

Metoda HEAD działa tak samo jak metoda GET. Nie zwraca ona jednak treści wiadomości, a jedynie nagłówki. Powinny one być identyczne z tymi zwracanymi przez metodę GET o takich samych parametrach.

Jedynym wyjątkiem są nagłówki mówiące o treści wiadomości takie jak: Content-Length, Content-Range, które mogą nie wystąpić w odpowiedzi w metodzie HEAD.

Metoda GET

Request Response
GET /admin HTTP/1.1
Host: www.example.com
HTTP/1.1 200 OK
Date: Mon, 18 Aug 2012 22:44:11 GMT
Content-Type: text/html
Content-Length: 123<html>

</html>

Metoda HEAD

Request Response
HEAD /admin HTTP/1.1
Host: www.example.com
HTTP/1.1 200 OK
Date: Mon, 18 Aug 2012 22:44:11 GMT
Content-Type: text/html

Omawiana metoda być użyta do pozyskiwania informacji na temat zasobu bez jego przesyłania. Na przykład do sprawdzenia poprawności linków, daty ostatniej modyfikacji i tym podobnych informacji, które możemy odczytać z nagłówków. Zapytania HEAD mogą brać udział w cache’owaniu. Mianowicie zapytanie tego typu może skutkować oznaczeniem przechowywanego zasobu jako starego i wymagającego ponownego pobrania, ale nie może go zaktualizować (ponieważ sam zasób nie jest przesyłany).

RyzykO związane z zapytaniami HEAD

Generalnie HEAD nie jest rozpatrywane jako potencjalne źródło zagrożeń. Jednak w źle zaprojektowanych systemach istnieje ryzyko wykorzystania tej metody do obejścia zabezpieczeń związanych z logowaniem do systemu.

Aby pokazać działanie tego obejścia zabezpieczeń, posłużymy się przykładem zasobu, którego pobranie wymaga logowania. W tym przypadku przy próbie dostępu do zasobu następuje przekierowanie do strony z możliwością logowania do systemu. Zakładamy, że strona zapamiętuje informacje o statusie zalogowania w ciasteczkach.

Dla takiego zasobu po wykonaniu zapytania GET, zwracane jest przekierowanie do strony logowania. Jednak w przypadku niepoprawnej implementacji metody HEAD, wysłanie zapytania HEAD na ten sam adres url, spowoduje otrzymanie wyniku pozytywnego i nagłówków uzupełniających pliki ciasteczek. Dzięki temu zapamiętane zostaną informacje uwierzytelniające i kolejne wywołanie GET nie będzie już wymagało logowania. Dlatego należy zawsze pamiętać, żeby wywołanie HEAD zachowywało się identycznie jak w przypadku zapytania GET. Także w przypadku autoryzacji dostępu do zasobów.

Metoda POST

Metoda POST

Ta metoda służy do przesyłania żądań wykonania jakiejś akcji w stosunku do konkretnego zasobu (identyfikowanego przez adres URL). Razem z żądaniem transmitowany jest obiekt w ustalonej reprezentacji. Może ona być zastosowana do:

  • przesyłania szczegółowych danych obiektu do serwera (np. uzupełnionych za pośrednictwem formularza),
  • wysłania do serwera akcji, które mają wpływ na zachowanie danych (np. wysłanie wiadomości na grupę dyskusyjną),
  • stworzenia nowego zasobu określonego przez adres,
  • dodania lub zmiany danych dla zdefiniowanego zasobu.

Wynik operacji POST jest sygnalizowany za pomocą statusu, który jest zwracany w odpowiedzi serwera, np. 200 (OK), 201 (Created) lub 304 (Not Modified). Z każdym kodem statusu związane są dodatkowe informacje przenoszone w zdefiniowanych nagłówkach, np. dla odpowiedzi 201 (Created), nagłówek Location powinien zawierać adres nowo utworzonego zasobu. Szerzej w części opisującej statusy odpowiedzi.

Request
POST /foo/bar HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded 

action=addentry&subject=Hello
Response
HTTP/1.1 201 
CreatedDate: …
Content-Length: 0
Location: http://example.com/foo/bar

Operacja POST może być cache’owana tylko, gdy jawnie zostaną ustawione nagłówki odpowiadające za ten mechanizm.

Metoda POST w sposobie działania (nie w swoich zastosowaniach) przypomina metodę GET. Przykład zastosowania mechanizmów POST i GET w tym samym celu – do wysłania zawartości formatki HTML do serwera – może pokazać nam różnice w sposobie tworzenia zapytań w obu metodach.

<form action="http://example.com" method="GET/POST">
   User: <input name="user" type="text" /> 
   Password: <input name="password" type="password" /> 
   <input name="extra" type="hidden" value="value" /> 
   <input type="submit" />
</form>

Kliknięcie przycisku “Wyślij” spowoduje stworzenie następującego zapytania HTTP, zależnie od rodzaju zdefiniowanej metody:

GET
GET /?username=john&password=secret&extra=value HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Accept: application/html
 User-Agent: Mozilla/5.0
POST
POST / HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Content-Length: 49
 Content-Type: application/x-www-form-urlencoded
 Accept: application/html
 User-Agent: Mozilla/5.0

username=john&password=secret&extra=value

Główną różnicę pomiędzy tymi metodami zauważamy w sposobie przekazywania parametrów zapytań. Dla zapytania GET są one zawarte w adresie docelowym (jest to tak zwany Query String), zaś dla zapytania POST wysyłane są one w treści wiadomości w zdefiniowanym (poprzez Content-Type) formacie.

Metoda GET

Metoda GET

Metoda GET jest prawdopodobnie najczęściej używaną metodą w sieci. Służy ona do pobierania zasobu z określonego adresu URL. Może być cache’owana.

Zależnie od nagłówków wysłanych razem z zapytaniem, wyróżniamy warunkowe i częściowe zapytania GET, które zachowują się następująco:

Warunkowe

Rekord lub zasób jest przesyłany tylko, gdy spełniony jest warunek ustawiony za pomocą dowolnego z nagłówków: If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match lub If-Range. Jest ono użyteczne podczas korzystania z mechanizmu cache. Pozwala zmniejszyć ruch sieciowy wtedy, gdy nie ma potrzeby bezwarunkowego odświeżania wartości rekordu.

Częściowe

Gdy ustawiony jest nagłówek Range pobierany jest tylko fragment zasobu. Jest to przydatne do stopniowego pobierania dużych ilości danych. W szczególności, gdy dane te nie są przetwarzane całościowo po stronie klienta. Nie należy jednak nadużywać tego parametru dla zbyt małych zasobów, ponieważ narzut na rozpoczęcie i zakończenie połączenia oraz przesyłanie nagłówków może zmniejszyć zyski z tego mechanizmu.

Najpopularniejszy dla metody GET sposób przekazywania parametrów dla żądania to przesyłanie ich w adresie url do danego zasobu.

index.php?lang=pl&param1=2

W podanym przykładzie przekazywane są 2 parametry: lang o wartości ‘pl’ oraz param1 o wartości ‘2’. Ten sposób przesyłania dodatkowych informacji modyfikuje adres url, co umożliwia następujące zachowania:

  • linkowalność do specyficznych zapytań
    (dzięki temu można zdefiniować odnośniki uwzględniające parametry <a href=”showRecord?id=123″>Link</a>),
  • możliwość zapisu zakładek do danego zasobu,
  • uwzględnienie zasobu w mechanizmie cache (w szczególności, gdy parametry mają wpływ na treść odpowiedzi),
  • w przeglądarce umożliwiają zapamiętanie danego zasobu w historii przeglądania.

Niestety ten sposób przesyłania parametrów jest ograniczony przez maksymalną długość adresu URL. Zależy to od klienta lub przeglądarki, lecz można założyć, że nie powinien on mieć więcej niż 2000 znaków, co ogranicza liczbę i złożoność parametrów.

Zapytań typu GET należy używać, gdy:

  • pytamy serwer o pewne informacje,
  • potrzebujemy możliwości identyfikacji zasobów po adresie (w celu zapisania, przesłania tego adresu).

Z kolei nie należy ich używać, gdy:

  • wykonujemy interakcję z serwerem na zasadzie żądania wykonania pewnej akcji,
  • żądamy od serwera wykonania pewnej akcji,
  • wywołanie metody może powodować jakieś akcje (za wyjątkiem akcji niewidocznych dla klienta jak zapis historii zapytań).
Request Response
GET /foo/bar HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Date: …
Content-Type: text/html;charset=utf-8
Content-Length: 12345

<!DOCTYPE …
Metoda OPTIONS

Metoda OPTIONS

To prośba o przesłanie informacji na temat dostępnych metod komunikacji dla danego zasobu. Możliwe jest także zapytanie o dostępne opcje samego serwera, jeżeli adres docelowy jest ustawiony na (*). Jednak z uwagi na to, że dostępne funkcjonalności są ściśle związane z zasobem, pytanie o możliwości serwera jest używane głównie jako ping (sprawdzenie dostępności) do serwera.

W przypadku zapytania o dostępne opcje danego zasobu, otrzymujemy listę dostępnych metod, które możemy wywołać na tym zasobie.

Request Response
OPTIONS /users/12
Host: example.com
HTTP/1.1 200 OK
Allow: HEAD,GET,PUT,DELETE,OPTIONS
Content-Length: 0

Nagłówek Allow w odpowiedzi jest wymagany. Treść dodatkowych nagłówków lub samej wiadomości nie jest określona w specyfikacji HTTP i może zawierać dowolnie więcej informacji.

Obecnie wiele serwerów nie implementuje tej metody. Jest ona jednak nadal wykorzystywana do mechanizmu Preflighted requests, który będzie opisany w kolejnych częściach.

Według najnowszych standardów nie jest zalecane używanie metody OPTIONS ze względów bezpieczeństwa. Pozwala ona na poznanie metod, które można wykonać na zasobie, a tym samym pomaga rozpoznać środowisko ataku potencjalnemu intruzowi.

Zamiast tego do zapytań o możliwości danego zasobu polecane jest użycie nagłówka Link. Pozwala on zdefiniować m.in. jaki zasób opisuje request, który nas interesuje. Szerzej na ten temat w temacie Link header.

Link: </resource.md>; rel="describedby"

https://www.mnot.net/blog/2012/10/29/NO_OPTIONS