Czy GET lub POST jest bezpieczniejszy niż inne?

Żądanie GET jest nieznacznie mniej bezpieczne niż żądanie POST. Żadne z nich nie oferuje prawdziwego "bezpieczeństwa" sam w sobie; korzystanie z żądań POST nie spowoduje magicznie zabezpieczy Twoją witrynę przed złośliwymi atakami w zauważalnej ilości. Jednak użycie żądań GET może sprawić, że bezpieczna aplikacja nie będzie bezpieczna.

Mantra, którą "nie wolno używać żądań GET do wprowadzania zmian" jest nadal bardzo ważna, ale ma to niewiele wspólnego z złośliwym zachowaniem. Login formularze są najbardziej wrażliwe na wysyłanie przy użyciu niewłaściwego typu żądania.

Pająki wyszukiwania i akceleratory WWW

To jest prawdziwy powód, dla którego powinieneś używać żądań POST do zmiany danych. Pająki wyszukiwania będą śledzić każdy link na twojej stronie, ale nie będą przesyłać losowych formularzy, które znajdą.

Akceleratory sieciowe są gorsze od pająków wyszukiwania, ponieważ działają na maszynie klienta i "klikają" wszystkie linki w kontekście zalogowanego użytkownika. Tak więc, aplikacja, która używa żądania GET do usuwania rzeczy, nawet jeśli wymaga administratora, z przyjemnością będzie przestrzegać poleceń (non-malicious!) web accelerator i Usuń wszystko, co widzi.

Confused deputy attack

A confused deputy attack (gdzie zastępcą jest przeglądarka) jest możliwy niezależnie od tego, czy używasz żądania GET czy POST.

Na kontrolowanych przez atakującego stronach internetowych GET I POST są równie łatwe do złożenia bez interakcji użytkownika .

Jedynym scenariuszem, w którym POST jest nieco mniej podatny, jest to, że wiele stron internetowych, które nie są pod kontrolą atakującego (powiedzmy, forum Osób Trzecich), pozwala osadzać dowolne obrazy( umożliwiając atakującemu wstrzyknięcie dowolnego żądania GET), ale uniemożliwia wszystkie sposoby wstrzykiwania żądania arbiter POST, czy to automatyczne, czy ręczne.

Można by argumentować, że akceleratory www to przykład dezorientującego ataku zastępców, ale to tylko kwestia definicji. Jeśli już, złośliwy napastnik nie ma nad tym kontroli, więc nie jest to atak , nawet jeśli zastępca jest zdezorientowany.

Logi Proxy

Serwery Proxy prawdopodobnie rejestrują adresy URL GET w całości, bez usuwania ciągu zapytania. Parametry żądania POST zwykle nie są rejestrowane. W obu przypadkach logowanie plików cookie jest mało prawdopodobne. (przykład)

To bardzo słaby argument na rzecz postu. Po pierwsze, niezaszyfrowany ruch może być zalogowanym w całości; złośliwy serwer proxy ma już wszystko, czego potrzebuje. Po drugie, parametry żądania mają ograniczone zastosowanie do atakującego: to, czego naprawdę potrzebują, to Pliki cookie, więc jeśli jedyne, co mają, to dzienniki proxy, prawdopodobnie nie będą w stanie zaatakować adresu URL GET lub post.

Jest jeden wyjątek dla żądań logowania: te zazwyczaj zawierają hasło użytkownika. Zapisanie tego w dzienniku proxy otwiera wektor ataku, który jest nieobecny w przypadku posta. Jednakże, logowanie przez zwykły HTTP jest z natury niebezpieczne i tak.

Pamięć podręczna Proxy

Buforujące Serwery Proxy mogą zachować odpowiedzi GET, ale nie posty. Mimo to, odpowiedzi GET mogą być nie buforowalne przy mniejszym wysiłku niż konwersja adresu URL do obsługi poczty.

HTTP "Referer"

Jeśli użytkownik miał przejść do witryny strony trzeciej ze strony obsługiwanej w odpowiedzi na żądanie GET, ta strona internetowa strony trzeciej może zobaczyć wszystkie żądania GET parametry.

Należy do kategorii "ujawnia parametry żądania stronie trzeciej" , której nasilenie zależy od tego, co jest obecne w tych parametrach. Żądania POST są naturalnie odporne na to, jednak aby wykorzystać żądanie GET, haker musiałby wstawić link do własnej strony internetowej w odpowiedzi serwera.

Historia przeglądarki

Jest to bardzo podobne do argumentu "Proxy logs": żądania GET są zapisywane w historii przeglądarki wraz z ich parametrami. Na atakujący może je łatwo uzyskać, jeśli ma fizyczny dostęp do maszyny.

Akcja odświeżania przeglądarki

Przeglądarka ponownie spróbuje żądania GET, gdy tylko użytkownik naciśnie "odśwież". Może to zrobić podczas przywracania kart po wyłączeniu. Każde działanie (np. płatność) będzie więc powtarzane bez ostrzeżenia.

Przeglądarka nie spróbuje ponownie żądania POST bez ostrzeżenia.

Jest to dobry powód, aby używać tylko żądań POST do zmiany danych, ale nie ma to nic wspólnego z złośliwe zachowanie, a co za tym idzie bezpieczeństwo.

• używaj tylko żądań POST do zmiany danych, głównie ze względów niezwiązanych z bezpieczeństwem.
• użyj tylko żądań POST dla formularzy logowania; robiąc inaczej wprowadza wektory ataku.
• jeśli Twoja witryna wykonuje wrażliwe operacje, naprawdę potrzebujesz kogoś, kto wie, co robi, ponieważ nie można tego ująć w jednej odpowiedzi. Musisz użyć HTTPS, HSTS, CSP, SQL injection, script injection (XSS), CSRF , i miliard innych rzeczy, które mogą być specyficzne dla Twojej platformy (jak Luka w przypisaniu masowym w różnych frameworkach: {86]} ASP.NET MVC, Ruby on Rails , itp.). Nie ma jednej rzeczy, która sprawi, że różnica między " bezpiecznym "(nie do wykorzystania) a"niezabezpieczonym".

Przez HTTPS, dane POST są zakodowane, ale czy adresy URL mogą być wąchane przez stronę trzecią?

Nie, Nie mogą być wąchanym. Ale adresy URL będą przechowywane w historii przeglądarki.

Czy byłoby uczciwie powiedzieć, że najlepszą praktyką jest unikanie ewentualnego umieszczania poufnych danych w poście lub całkowite wykorzystanie kodu po stronie serwera do obsługi poufnych informacji zamiast tego?

Zależy od tego, jak jest wrażliwy, a dokładniej, w jaki sposób. Oczywiście klient to zobaczy. Każdy, kto ma fizyczny dostęp do KOMPUTERA Klienta, zobaczy go. Klient może go sfałszować, wysyłając go z powrotem za Ciebie. Jeśli to ma znaczenie, to tak, zachowaj poufne dane na serwerze i nie pozwól mu odejść.

Nie masz większego bezpieczeństwa, ponieważ zmienne są wysyłane przez HTTP POST niż zmienne wysyłane przez HTTP GET.

HTTP/1.1 udostępnia nam kilka metod wysyłania zapytania :

• opcje
• GET
• HEAD
• POST
• PUT
• Usuń
• ślad
• CONNECT

Załóżmy, że masz następujący dokument HTML za pomocą GET:

<html>
<body>
<form action="http://example.com" method="get">
    User: <input type="text" name="username" /><br/>
    Password: <input type="password" name="password" /><br/>
    <input type="hidden" name="extra" value="lolcatz" />
    <input type="submit"/>
</form>
</body>
</html>

Co robi twoja przeglądarka zapytać? Pyta o to:

 GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Teraz udawajmy, że zmieniliśmy metodę żądania na POST:

 POST / HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Content-Length: 49
 Cache-Control: max-age=0
 Origin: null
 Content-Type: application/x-www-form-urlencoded
 Accept: application/xml,application/xhtml+xml,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

 username=swordfish&password=hunter2&extra=lolcatz

Oba z tych żądań HTTP to:

• nie zaszyfrowane
• zawarte w obu przykładach
• może być nawet rzucany i poddawany atakom MITM.
• łatwo powielane przez osoby trzecie, i skrypt boty.

Wiele przeglądarek przechowuj adres strony, ale nie oznacza to, że możesz zignorować którykolwiek z tych problemów.

Tak konkretnie:

Czy jedno z natury jest bezpieczniejsze od drugiego? Zdaję sobie sprawę, że POST nie ujawnia informacji na URL, ale czy jest w tym jakaś prawdziwa wartość, czy jest to po prostu bezpieczeństwo przez zaciemnienie? Jaka jest najlepsza praktyka?

Jest to poprawne, ponieważ oprogramowanie, którego używasz do mówienia HTTP, Zwykle przechowuje zmienne żądania za pomocą jednej metody, ale nie inny tylko uniemożliwia komuś przeglądanie historii przeglądarki lub innego naiwnego ataku ze strony 10 - latka, który myśli, że rozumie h4x0r1ng lub skrypty, które sprawdzają Twój sklep z historią. Jeśli masz skrypt, który może sprawdzić Twój sklep z historią, równie łatwo możesz mieć taki, który sprawdza ruch w sieci, więc całe to bezpieczeństwo poprzez zaciemnienie zapewnia zaciemnienie tylko dzieciom ze skryptami i zazdrosnym dziewczynom.

Przez https, dane POST są zakodowane, ale może URL być wąchanym przez stronę trzecią?

Oto jak działa SSL. Pamiętasz te dwie prośby, które wysłałem powyżej? Oto jak wyglądają W SSL: (Zmieniłem stronę na https://encrypted.google.com / as example.com nie odpowiada NA SSL).

POST przez SSL

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

GET over SSL

rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv

(Uwaga: zamieniłem HEX NA ASCII, część z nich oczywiście nie powinna być wyświetlana)

Cała rozmowa HTTP jest zaszyfrowana, jedyna widoczna część komunikacja odbywa się na warstwie TCP / IP (czyli informacje o adresie IP i porcie połączenia).

Więc pozwól, że powiem tu odważnie. Twoja strona internetowa nie jest zapewniona większego bezpieczeństwa w stosunku do jednej metody HTTP niż innej, hakerzy i nowicjusze na całym świecie wiedzą dokładnie, jak zrobić to, co właśnie pokazałem tutaj. Jeśli chcesz bezpieczeństwa, użyj SSL. Przeglądarki mają tendencję do przechowywania historii, zaleca się przez RFC2616 9.1.1, aby nie używać GET do wykonywania akcji, ale myśleć, że POST zapewnia ochrona jest bardzo zła.

Aby jeszcze bardziej wykazać, dlaczego POST nie jest bezpieczny, Facebook używa żądań POST wszędzie, więc jak może istnieć oprogramowanie takie jak FireSheep ?

Zauważ, że możesz zostać zaatakowany za pomocą CSRF , nawet jeśli używasz HTTPS i Twoja strona nie zawiera XSS luk. W skrócie, ten scenariusz ataku zakłada, że ofiara (użytkownik Twojej witryny lub usługi) jest już zalogowany i ma odpowiedni plik cookie, a następnie przeglądarka ofiary jest proszona o zrobienie czegoś z Twoją (rzekomo bezpieczną) stroną. Jeśli nie masz ochrony przed CSRF, atakujący może nadal wykonywać działania z poświadczeniami ofiar. Atakujący nie może zobaczyć odpowiedzi serwera, ponieważ zostanie ona przeniesiona do ofiary przeglądarka, ale szkoda jest zwykle już zrobione w tym momencie.

Nie ma dodatkowej ochrony.

Dane Post nie pojawiają się w historii i / lub plikach dziennika, ale jeśli dane powinny być zabezpieczone, potrzebujesz SSL.
W przeciwnym razie każdy, kto wącha przewód, może odczytać twoje dane.

Nawet jeśli POST nie daje realnych korzyści w stosunku do GET, dla formularzy logowania lub innych formularzy ze stosunkowo wrażliwymi informacjami, upewnij się, że używasz POST jako:

1. Informacje POST ed nie zostaną zapisane w historii użytkownika.
2. Informacje Poufne (hasło itp.) wysłane w formularzu nie będą później widoczne w pasku adresu URL (za pomocą GET będzie widoczne w historii i pasku adresu URL).

Również GET ma teoretyczną granicę data. POST nie.

Dla prawdziwych wrażliwych informacji, upewnij się, że używasz SSL (HTTPS)

Żaden z GET I POST nie jest z natury " bezpieczniejszy "od drugiego, podobnie jak żaden z fax i telefon nie jest" bezpieczniejszy " od drugiego. Dostępne są różne metody HTTP, dzięki czemu możesz wybrać tę, która jest najbardziej odpowiednia dla problemu, który próbujesz rozwiązać. GET jest bardziej odpowiedni dla zapytań idempotent , podczas gdy POST jest bardziej odpowiedni dla zapytań "akcji", ale możesz równie łatwo strzelić sobie w stopę przy każdym z nich, jeśli nie rozumiesz Architektura zabezpieczeń utrzymywanej aplikacji.

Najlepiej będzie, jeśli przeczytasz Rozdział 9: definicje metod z HTTP/1.1 RFC, aby uzyskać ogólne wyobrażenie o tym, co GET I POST pierwotnie przewidywały OT.

Różnica między GET I POST nie powinna być postrzegana pod względem bezpieczeństwa, ale raczej w ich zamiarach wobec serwera. GET nigdy nie powinien zmieniać danych na serwerze - przynajmniej innych niż w logach - ale POST może tworzyć nowe zasoby.

Ładne proxy nie buforują danych postów, ale mogą buforować dane z adresu URL, więc można powiedzieć, że POST ma być bezpieczniejszy. Ale dane POST nadal będą dostępne dla proxy, które nie grają ładnie.

Jak wspomniano w wiele odpowiedzi, jedyny pewny zakład jest za pośrednictwem SSL.

Ale upewnij się, że metody GET Nie zatwierdzają żadnych zmian, takich jak usuwanie wierszy bazy danych, itp.

Moja zwykła metodologia wyboru to coś w stylu:

• pobierz dla elementów, które zostaną pobrane później przez URL
  • np. wyszukiwanie powinno być GET, więc możesz to zrobić.php?s = XXX później
• POST dla przedmiotów, które zostaną wysłane
  • jest to stosunkowo niewidoczne, aby uzyskać i trudniejsze do wysłania, ale dane mogą być wysyłane przez cURL.

To nie jest związane z bezpieczeństwem, ale... przeglądarki nie buforują żądań POST .

Żaden z nich nie przyznaje bezpieczeństwa na żądanie, jednak GET implikuje pewne skutki uboczne, które generalnie uniemożliwiają jego bezpieczeństwo.

GET adresy URL pojawiają się w historii przeglądarki i logach serwera www. Z tego powodu nigdy nie powinny być używane do formularzy logowania i numerów kart kredytowych.

Jednak samo opublikowanie tych danych również nie czyni ich bezpiecznymi. Do tego chcesz SSL. Zarówno GET, jak i POST wysyłają dane w postaci zwykłego tekstu przez przewód, gdy są używane przez HTTP.

Są też inne dobre powody, aby publikować dane - na przykład możliwość przesyłania nieograniczonej ilości danych lub ukrywania parametrów przed zwykłymi użytkownikami.

Minusem jest to, że użytkownicy nie mogą dodawać do zakładek wyników zapytania wysyłanego pocztą. Do tego potrzebujesz dostać.

Rozważ tę sytuację: niechlujne API akceptuje żądania GET, takie jak:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

W niektórych ustawieniach, gdy zażądasz tego adresu URL i jeśli wystąpi błąd / ostrzeżenie dotyczące żądania, cała linia zostanie zalogowana w pliku dziennika. Co gorsza: jeśli zapomnisz wyłączyć komunikaty o błędach na serwerze produkcyjnym, ta informacja jest po prostu wyświetlana w przeglądarce! Teraz właśnie oddałeś swój klucz API wszystkim.

Niestety, istnieją prawdziwe API działa to sposób.

Nie podoba mi się pomysł posiadania poufnych informacji w logach lub wyświetlania ich w przeglądarce. POST I GET to nie to samo. W stosownych przypadkach należy użyć każdego z nich.

1. Bezpieczeństwo jako bezpieczeństwo przesyłanych danych: Brak różnicy między POST I GET.

2. Bezpieczeństwo jako bezpieczeństwo danych na komputerze: POST jest bezpieczniejszy (bez historii URL)

Pojęcie bezpieczeństwa jest bez znaczenia, chyba że zdefiniujesz, przed czym chcesz się zabezpieczyć.

Jeśli chcesz zabezpieczyć się przed przechowywaną historią przeglądarki, niektórymi rodzajami logowania i osobami przeglądającymi Twoje adresy URL, POST jest bezpieczniejszy.

Jeśli chcesz być bezpieczny przed kimś, kto wącha Twoją aktywność sieciową, to nie ma różnicy.

Wiele osób przyjmuje konwencję (nawiązującą do Rossa), że żądania GET pobierają tylko Dane i nie modyfikują żadnych danych na serwerze, a żądania POST są używane do wszystkich modyfikacji danych. Chociaż jeden z nich nie jest bardziej bezpieczny od drugiego, jeśli postępujesz zgodnie z tą konwencją, możesz zastosować przekrojową logikę bezpieczeństwa (np. tylko osoby posiadające konta mogą modyfikować dane, więc nieautoryzowane posty są odrzucane).

Trudniej jest zmienić żądanie POST (wymaga to więcej wysiłku niż edycja ciągu zapytania). Edit: innymi słowy, jest to tylko Bezpieczeństwo przez ciemność, a ledwie to.

Nie zamierzam powtarzać wszystkich innych odpowiedzi, ale jest jeden aspekt, o którym jeszcze nie wspomniałem - to historia znikających danych. Nie wiem, gdzie go znaleźć, ale.....

Zasadniczo chodzi o aplikację internetową, która tajemniczo co kilka nocy traciła wszystkie swoje dane i nikt nie wiedział dlaczego. Przeglądanie dzienników później ujawniło, że strona została znaleziona przez google lub innego arbitralnego pająka, który szczęśliwie dostaje (Czytaj: GOT) wszystkie linki, które znalazł na stronie-w tym "usuń ten wpis" i " jesteś pewien?"linki.

Faktycznie-część tego została wymieniona. To jest historia "nie zmieniaj danych na GET, ale tylko na POST". Gąsienice z radością podążą za GET, nigdy nie publikuj. Nawet roboty.txt nie pomaga w walce z niewłaściwymi crawlerami.

Należy również pamiętać, że jeśli Twoje witryny zawierają link do innych zewnętrznych witryn, których nie kontrolujesz, używając GET umieści te dane w nagłówku refeerer na zewnętrznych witrynach, gdy nacisną linki na Twojej witrynie. Tak więc przekazywanie danych logowania za pomocą metod GET jest zawsze dużym problemem. Ponieważ może to ujawnić poświadczenia logowania dla łatwego dostępu, po prostu sprawdzając dzienniki lub patrząc w Google analytics (lub podobne).

RFC7231:

" Uri mają być udostępniane, a nie zabezpieczone, nawet gdy identyfikują zabezpiecz zasoby. URI są często wyświetlane na wyświetlaczach, dodawane do szablonów, gdy strona jest drukowana i przechowywana w różnych niechronione listy zakładek. Nierozsądne jest zatem uwzględnienie informacje zawarte w URI, które są wrażliwe i umożliwiają identyfikację osoby, lub ryzyko ujawnienia.

Autorzy serwisów powinni unikać formularzy GET-based do zgłoszenia danych wrażliwych ponieważ dane te zostaną umieszczone w Prośba-cel. Wiele istniejących serwerów, serwerów proxy i agentów użytkowników loguje lub wyświetla request-target w miejscach, w których może być widoczny dla strony trzecie. Takie usługi powinny korzystać z POST-based formularza przesyłania zamiast tego."

Ten RFC wyraźnie stwierdza, że wrażliwe dane nie powinny być przesyłane za pomocą GET. Z powodu tej uwagi niektórzy implementatorzy mogą nie obsługiwać danych uzyskanych z części zapytania żądania GET z taką samą starannością. I ' m pracuję nad protokołem, który zapewnia integralność danych. Zgodnie z tą specyfikacją nie powinienem gwarantować integralności danych GET (co zrobię, ponieważ nikt nie przestrzega tych specyfikacji)

Jak wcześniej niektórzy ludzie mówili, HTTPS przynosi bezpieczeństwo.

Jednak POST jest nieco bezpieczniejszy niż GET, ponieważ GET może być zapisany w historii.

Ale jeszcze bardziej, niestety, czasami wybór POST lub GET nie zależy od dewelopera. Na przykład hiperłącze jest zawsze wysyłane przez GET (chyba że zostanie przekształcone w Formularz post przy użyciu javascript).

GET jest widoczny dla każdego (nawet ten na ramieniu teraz) i jest zapisany w pamięci podręcznej, więc jest mniej bezpieczny w użyciu post, btw post bez niektórych procedur kryptograficznych nie jest pewien, dla odrobiny bezpieczeństwa musisz użyć SSL (https)

Jednym z powodów POST jest gorszy dla bezpieczeństwa jest to, że GET jest domyślnie rejestrowany, parametry i wszystkie dane są prawie powszechnie rejestrowane przez serwer WWW.

POST jest przeciwieństwem , jest prawie powszechnie niezalogowany , co prowadzi do bardzo trudnej do wykrycia aktywności atakującego.

Nie kupuję argumentu "jest za duży" ,nie ma powodu, aby nie logować cokolwiek, przynajmniej 1KB, przydałoby się ludziom do identyfikacji atakujących pracujących na słaby punkt wejścia, dopóki nie pop, a następnie POST robi podwójną usługę dezasługi, umożliwiając dowolne tylne drzwi oparte na HTTP, aby cicho przekazać nieograniczone ilości danych.

Różnica polega na tym, że GET wysyła dane otwarte i ukryte (w nagłówku http).

Więc get jest lepszy dla niezabezpieczonych danych, takich jak ciągi zapytań w Google. Auth-dane nigdy nie będą wysyłane przez GET-więc użyj POST tutaj. Oczywiście cały temat jest trochę bardziej skomplikowany. Jeśli chcesz przeczytać więcej, przeczytaj Ten artykuł (w języku niemieckim).

Ostatnio został opublikowany Atak , który pozwala man in a middle ujawnić treść żądania skompresowanych żądań HTTPS. Ponieważ nagłówki żądań i URL nie są kompresowane przez HTTP, żądania GET są lepiej zabezpieczone przed tym konkretnym atakiem.

Istnieją tryby, w których żądania GET są również podatne na ataki, SPDY kompresuje nagłówki żądań, TLS zapewnia również opcjonalną (rzadko używaną) kompresję. W tych scenariuszach atak jest łatwiejszy do uniknięcia (dostawcy przeglądarek już dostarczone poprawki). Kompresja na poziomie HTTP jest bardziej podstawową funkcją, jest mało prawdopodobne, aby dostawcy ją wyłączyli.

Jest to tylko przykład, który pokazuje scenariusz, w którym GET jest bezpieczniejszy niż POST, ale nie sądzę, że byłoby dobrym pomysłem, aby wybrać GET over POST z tego powodu ataku. Atak jest dość wyrafinowany i wymaga nietrywialnych warunków wstępnych(atakujący musi być w stanie kontrolować część treści żądania). Lepiej wyłączyć kompresję HTTP w scenariusze, w których atak byłby szkodliwy.

To jest stary post, ale chciałbym sprzeciwić się niektórym odpowiedziom. Jeśli przesyłasz poufne dane, będziesz chciał używać protokołu SSL. Jeśli używasz SSL z parametrem GET (np. ?userid=123), dane zostaną wysłane w postaci zwykłego tekstu! Jeśli wysyłasz za pomocą posta, wartości zostaną umieszczone w zaszyfrowanej treści wiadomości, a zatem nie będą czytelne dla większości ataków MITM.

Duża różnica polega na tym, gdzie dane są przekazywane. Ma sens tylko to, że jeśli dane są umieszczone w adresie URL, nie może być zaszyfrowane w przeciwnym razie nie byłoby w stanie przekierować do serwera, ponieważ tylko można odczytać adres URL. Tak działa GET.

Krótko mówiąc, możesz bezpiecznie przesyłać dane w poście przez SSL, ale nie możesz tego zrobić za pomocą GET, używając SSL lub nie.

Nawet POST akceptuje żądania GET. Załóżmy, że masz formularz mający takie dane jak user.name i użytkownikiem.passwd, mają one obsługiwać nazwę użytkownika i hasło. Jeśli po prostu dodać ?user.name = " my user&user.passwd= "moje hasło", wtedy żądanie zostanie zaakceptowane przez "ominięcie strony logowania".

Rozwiązaniem tego problemu jest zaimplementowanie filtrów (java filters jako e) Po stronie serwera i wykrycie, że zapytania łańcuchowe nie są przekazywane jako argumenty GET.