Czy GET lub POST jest bezpieczniejszy niż drugi?

Porównując HTTP GET z HTTP POST, jakie są różnice z punktu widzenia bezpieczeństwa? Czy jeden z wyborów jest z natury bezpieczniejszy niż drugi? Jeśli tak, to dlaczego?

Zdaję sobie sprawę, że POST nie ujawnia informacji w adresie URL, ale czy jest w tym jakaś rzeczywista wartość, czy to tylko bezpieczeństwo poprzez niejasność? Czy kiedykolwiek istnieje powód, dla którego wolę POST, gdy bezpieczeństwo stanowi problem?

Edycja: w przypadku
HTTPS dane POST są kodowane, ale czy adresy URL mogą być wąchane przez inną firmę? Dodatkowo mam do czynienia z JSP; w przypadku korzystania z JSP lub podobnego środowiska, czy można uczciwie powiedzieć, że najlepszą praktyką jest unikanie umieszczania wrażliwych danych w POST lub GET oraz używanie kodu po stronie serwera do obsługi poufnych informacji?

Jeśli chodzi o bezpieczeństwo, są one z natury takie same. Chociaż prawdą jest, że POST nie ujawnia informacji za pośrednictwem adresu URL, ujawnia tyle samo informacji, co GET w rzeczywistej komunikacji sieciowej między klientem a serwerem. Jeśli potrzebujesz przekazać wrażliwe informacje, pierwszą linią obrony będzie przekazanie ich przy użyciu Bezpiecznego HTTP.

Posty GET lub ciąg zapytania są naprawdę dobre dla informacji wymaganych do dodania zakładki do określonego elementu lub do pomocy w optymalizacji pod kątem wyszukiwarek i indeksowaniu elementów.

POST jest dobry dla standardowych formularzy używanych do przesyłania danych jednorazowych. Nie użyłbym GET do publikowania rzeczywistych formularzy, chyba że w formularzu wyszukiwania, w którym chcesz pozwolić użytkownikowi na zapisanie zapytania w zakładce lub coś w tym stylu.

Żądanie GET jest nieznacznie mniej bezpieczne niż żądanie POST. Żadne z nich samo w sobie nie zapewnia prawdziwego „bezpieczeństwa”; użycie żądań POST nie zwiększy w magiczny sposób twojej witryny przed złośliwymi atakami. Jednak użycie żądań GET może sprawić, że bezpieczna aplikacja nie będzie bezpieczna.

Mantra, że ​​„nie wolno używać żądań GET do wprowadzania zmian”, jest nadal bardzo aktualna, ale ma to niewiele wspólnego ze złośliwym zachowaniem. Formularze logowania są najbardziej wrażliwe na wysyłanie przy użyciu niewłaściwego typu żądania.

Szukaj pająków i akceleratorów internetowych

To jest prawdziwy powód, dla którego powinieneś używać żądań POST do zmiany danych. Pająki wyszukiwania będą podążać za każdym linkiem w Twojej witrynie, ale nie będą przesyłać losowych formularzy, które znajdą.

Akceleratory internetowe są gorsze niż pająki wyszukiwania, ponieważ działają na komputerze klienta i „klikają” wszystkie linki w kontekście zalogowanego użytkownika . Dlatego aplikacja, która korzysta z żądania GET do usuwania rzeczy, nawet jeśli wymaga administratora, chętnie wykona polecenia (nie złośliwego!) Akceleratora internetowego i usunie wszystko, co zobaczy .

Zmieszany atak zastępcy

Mylić atak zastępca (gdzie zastępca jest przeglądarka) jest możliwe, niezależnie od tego, czy używasz GET lub żądania POST .

Na stronach kontrolowanych przez atakujących GET i POST są równie łatwe do przesłania 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 na umieszczanie dowolnych obrazów (pozwalając atakującemu na wstrzyknięcie dowolnego żądania GET), ale zapobiega wszystkim sposoby wstrzykiwania arbitralnego żądania POST, automatycznego lub ręcznego.

Można argumentować, że akceleratory sieciowe są przykładem pomylonego ataku zastępcy, ale to tylko kwestia definicji. W każdym razie złośliwy atakujący nie ma nad tym kontroli, więc nie jest to atak , nawet jeśli zastępca jest zdezorientowany.

Dzienniki proxy

Serwery proxy prawdopodobnie będą rejestrować GET-y w całości, bez usuwania ciągu zapytania. Parametry żądania POST nie są zwykle rejestrowane. W obu przypadkach jest mało prawdopodobne, aby pliki cookie były rejestrowane.(przykład)

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

Istnieje jeden wyjątek dla próśb o zalogowanie: zawierają one zwykle hasło użytkownika. Zapisanie tego w dzienniku proxy otwiera wektor ataku, którego nie ma w przypadku testu POST. Jednak logowanie przez zwykły HTTP i tak jest z natury niebezpieczne.

Pamięć podręczna proxy

Buforowe proxy mogą zachować odpowiedzi GET, ale nie odpowiedzi POST. Powiedziawszy to, odpowiedzi GET mogą być niemożliwe do buforowania przy mniejszym wysiłku niż konwersja adresu URL na moduł obsługi POST.

„Referer” HTTP

Jeśli użytkownik miałby przejść do strony internetowej strony trzeciej ze strony wyświetlanej w odpowiedzi na żądanie GET, ta strona strony trzeciej zobaczy wszystkie parametry żądania GET.

Należy do kategorii „ujawnia parametry żądania stronie trzeciej”, której dotkliwość zależy od zawartości tych parametrów. Żądania POST są naturalnie odporne na to, jednak aby wykorzystać żądanie GET, haker musiałby wstawić link do swojej strony internetowej w odpowiedzi serwera.

Historia przeglądarki

Jest to bardzo podobne do argumentu „dzienniki proxy”: żądania GET są przechowywane w historii przeglądarki wraz z ich parametrami. Atakujący może je łatwo uzyskać, jeśli ma fizyczny dostęp do komputera.

Odświeżanie przeglądarki

Przeglądarka ponowi żądanie GET, gdy tylko użytkownik kliknie „odśwież”. Może to zrobić podczas przywracania kart po wyłączeniu. Wszelkie działania (powiedzmy płatność) zostaną więc powtórzone bez ostrzeżenia.

Przeglądarka nie powtórzy żą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 ze złośliwym zachowaniem, a tym samym bezpieczeństwem.

Więc co powinienem zrobić?

• Używaj tylko żądań POST do zmiany danych, głównie ze względów niezwiązanych z bezpieczeństwem.
• Używaj tylko żądań POST dla formularzy logowania; inaczej wprowadzi 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, ograniczyć wstrzykiwanie SQL, wstrzyknięcie skryptu (XSS) , CSRF i wiele innych rzeczy, które mogą być specyficzne dla Twojej platformy (takich jak luka w masowym przypisywaniu w różnych środowiskach: ASP.NET MVC , Ruby on Rails itp.). Nie ma jednej rzeczy, która odróżnia „bezpieczny” (niemożliwy do wykorzystania) od „niezabezpieczony”.

W przypadku HTTPS dane POST są kodowane, ale czy adresy URL mogą być wąchane przez firmę zewnętrzną?

Nie, nie można ich obwąchać. Ale adresy URL będą przechowywane w historii przeglądarki.

Czy uczciwie byłoby powiedzieć, że najlepszą praktyką jest unikanie ewentualnego umieszczania poufnych danych w POST lub GET oraz używanie kodu po stronie serwera do obsługi poufnych informacji zamiast tego?

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

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

HTTP / 1.1 zapewnia nam szereg metod wysyłania zapytania :

• OPCJE
• DOSTAĆ
• GŁOWA
• POCZTA
• POŁOŻYĆ
• USUNĄĆ
• ŚLAD
• POŁĄCZYĆ

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>

O co pyta Twoja przeglądarka? Pytanie to brzmi:

 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 tę 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

ZARÓWNO tych żądań HTTP:

• Nieszyfrowane
• Zawarte w obu przykładach
• Może być ewakuowany i podlegać atakom MITM.
• Łatwo reprodukowane przez osoby trzecie i boty skryptowe.

Wiele przeglądarek nie obsługuje metod HTTP innych niż POST / GET.

Wiele zachowań przeglądarki przechowuje adres strony, ale to nie znaczy, że możesz zignorować którykolwiek z tych innych problemów.

Aby być konkretnym:

Czy jedno jest z natury bezpieczniejsze niż drugie? Zdaję sobie sprawę, że POST nie ujawnia informacji w adresie URL, ale czy jest w tym jakaś rzeczywista wartość, czy to tylko bezpieczeństwo poprzez niejasność? Jaka jest tutaj najlepsza praktyka?

Jest to poprawne, ponieważ oprogramowanie, którego używasz do mówienia HTTP, zwykle przechowuje zmienne żądania jedną metodą, ale żadna inna nie tylko zapobiega przeglądaniu historii przeglądarki lub innego naiwnego ataku 10-latka, który uważa, że ​​rozumie h4x0r1ng lub skrypty sprawdzające sklep z historią. Jeśli masz skrypt, który może sprawdzić twój sklep z historią, równie dobrze możesz mieć taki, który sprawdza ruch sieciowy, więc całe to bezpieczeństwo poprzez niejasność zapewnia tylko niejasność dzieciom ze skryptów i zazdrosnym dziewczynom.

W przypadku protokołu https dane POST są kodowane, ale czy adresy URL mogą być wąchane przez firmę zewnętrzną?

Oto jak działa SSL. Pamiętasz te dwa zapytania, które wysłałem powyżej? Oto jak wyglądają w SSL: (Zmieniłem stronę na https://encrypted.google.com/, ponieważ 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: przekonwertowałem HEX na ASCII, niektóre z nich oczywiście nie powinny być wyświetlane)

Cała rozmowa HTTP jest szyfrowana, jedyną widoczną częścią komunikacji jest warstwa TCP / IP (czyli adres IP i informacje o porcie połączenia).

Więc pozwólcie, że przedstawię tutaj odważne oświadczenie. Twoja witryna nie zapewnia większego bezpieczeństwa w stosunku do jednej metody HTTP niż w innej, hakerzy i nowi użytkownicy na całym świecie wiedzą dokładnie, jak zrobić to, co właśnie tutaj pokazałem. Jeśli chcesz bezpieczeństwa, użyj SSL. Przeglądarki zazwyczaj przechowują historię, RFC2616 9.1.1 zaleca NIE używanie GET do wykonywania akcji, ale myślenie, że POST zapewnia bezpieczeństwo, jest całkowicie błędne.

Jedyną rzeczą, do której POST jest środkiem bezpieczeństwa? Ochrona przed zazdrosnym ex przeglądaniem historii przeglądarki. Otóż ​​to. Reszta świata jest zalogowana na twoje konto, śmiejąc się z ciebie.

Aby dodatkowo zademonstrować, dlaczego POST nie jest bezpieczny, Facebook używa żądań POST w dowolnym miejscu, więc w jaki sposób może istnieć oprogramowanie takie jak FireSheep ?

Pamiętaj, że możesz zostać zaatakowany przez CSRF, nawet jeśli używasz HTTPS, a Twoja strona nie zawiera luk w zabezpieczeniach XSS . Krótko mówiąc, ten scenariusz ataku zakłada, że ​​ofiara (użytkownik Twojej witryny lub usługi) jest już zalogowana i ma odpowiedni plik cookie, a następnie przeglądarka ofiary jest proszona o wykonanie czynności na (prawdopodobnie bezpiecznej) stronie. Jeśli nie masz ochrony przed CSRF, osoba atakująca może nadal wykonywać działania przy użyciu poświadczeń ofiar. Atakujący nie widzi odpowiedzi serwera, ponieważ zostanie on przeniesiony do przeglądarki ofiary, ale uszkodzenie jest zwykle już wyrządzone w tym momencie.

Nie ma żadnych dodatkowych zabezpieczeń.

Dane wpisu 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 drut, może odczytać twoje dane.

Nawet jeśli POSTnie daje to rzeczywistych korzyści bezpieczeństwa w porównaniu GETz formularzami logowania lub innymi formularzami zawierającymi względnie poufne informacje, upewnij się, że używasz POSTjako:

1. Informacje POSTte nie zostaną zapisane w historii użytkownika.
2. Informacje wrażliwe (hasło itp.) Wysłane w formularzu nie będą widoczne później na pasku adresu URL (przy użyciu GETbędą widoczne w historii i pasku adresu).

Również GETma teoretycznego limitu danych. POSTnie.

Aby uzyskać prawdziwe wrażliwe informacje, należy użyć SSL( HTTPS)

Żaden z GET i POST nie jest z natury „bezpieczniejszy” niż drugi, podobnie jak żaden z faksu i telefonu nie jest „bezpieczniejszy” niż drugi. 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ń idempotentnych, podczas gdy POST jest bardziej odpowiedni dla zapytań „akcji”, ale możesz z łatwością strzelić sobie w stopę, jeśli nie rozumiesz architektury bezpieczeństwa dla obsługiwanej aplikacji.

To chyba najlepiej jeśli czytasz Rozdział 9: Metoda Definicje z HTTP / 1.1 RFC , aby uzyskać ogólny pomysł co GET i POST zostały pierwotnie przewidywał ot średnią.

Różnicy między GET i POST nie należy postrzegać w kategoriach bezpieczeństwa, ale raczej w ich intencjach wobec serwera. GET nigdy nie powinien zmieniać danych na serwerze - przynajmniej innych niż w logach - ale POST może tworzyć nowe zasoby.

Ładne serwery proxy nie będą buforować danych POST, ale mogą buforować dane GET z adresu URL, więc można powiedzieć, że POST powinien być bardziej bezpieczny. Ale dane POST byłyby nadal dostępne dla serwerów proxy, które nie działają ładnie.

Jak wspomniano w wielu odpowiedziach, jedynym pewnym zakładem jest SSL.

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

Moja zwykła metodologia wyboru jest następująca:

• POBIERZ elementy, które zostaną później pobrane przez adres URL
  • Np. Wyszukiwanie powinno być GET, aby później można było wykonać search.php? S = XXX
• POST za przedmioty, które zostaną wysłane
  • Jest to stosunkowo niewidoczne w porównaniu z GET i trudniejsze do wysłania, ale dane można nadal przesyłać przez cURL.

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

Żadne z nich w magiczny sposób nie zapewnia bezpieczeństwa na żądanie, jednak GET implikuje pewne skutki uboczne, które na ogół uniemożliwiają jego bezpieczeństwo.

POBIERZ adresy URL pojawiają się w historii przeglądarki i dziennikach serwera WWW. Z tego powodu nigdy nie należy ich używać do formularzy logowania i numerów kart kredytowych.

Jednak samo wysłanie tych danych również nie zapewnia ich bezpieczeństwa. Do tego chcesz SSL. Zarówno GET, jak i POST wysyłają dane w postaci zwykłego tekstu za pośrednictwem drutu, gdy są używane przez HTTP.

Istnieją również inne powody, dla których dane POST - na przykład możliwość przesyłania nieograniczonej ilości danych lub ukrywania parametrów przed przypadkowymi użytkownikami.

Minusem jest to, że użytkownicy nie mogą dodawać do zakładek wyników zapytania wysłanego za pośrednictwem POST. Do tego potrzebujesz GET.

Rozważ tę sytuację: niedbały interfejs API akceptuje żądania GET, takie jak:

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

W niektórych ustawieniach, kiedy zażądasz tego adresu URL i jeśli wystąpi błąd / ostrzeżenie dotyczące żądania, cała linia zostanie zapisana w pliku dziennika. Co gorsza: jeśli zapomnisz wyłączyć komunikaty o błędach na serwerze produkcyjnym, informacje te są wyświetlane w przeglądarce jako zwykły! Teraz rozdałeś wszystkim swój klucz API.

Niestety istnieją prawdziwe API działające w ten sposób.

Nie podoba mi się pomysł posiadania poufnych informacji w dziennikach lub wyświetlania ich w przeglądarce. POST i GET to nie to samo. Używaj każdego z nich, jeśli to konieczne.

1. BEZPIECZEŃSTWO jako bezpieczeństwo danych W TRANZYCIE: bez różnicy między POST a GET.

2. BEZPIECZEŃSTWO jako bezpieczeństwo danych W KOMPUTERZE: POST jest bezpieczniejszy (bez historii adresów URL)

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

Jeśli chcesz zabezpieczyć się przed zapisaną historią przeglądarki, niektórymi rodzajami rejestrowania i osobami przeglądającymi twoje adresy URL, wtedy POST jest bardziej bezpieczny.

Jeśli chcesz zabezpieczyć się przed kimś węszącym twoją aktywność w sieci, nie ma różnicy.

Wiele osób przyjmuje konwencję (do której nawiązuje Ross), że żądania GET tylko pobierają dane i nie modyfikują żadnych danych na serwerze, a żądania POST są używane do wszystkich modyfikacji danych. Podczas gdy jeden z natury nie jest bardziej bezpieczne niż inne, jeśli zrobić śledzić tę konwencję, można zastosować logikę bezpieczeństwa przekrojowego (np tylko osoby z kont można modyfikować dane, więc nieuwierzytelnieni Słupki są odrzucane).

Trudniej jest zmienić żądanie POST (wymaga więcej wysiłku niż edycja ciągu zapytania). Edycja: Innymi słowy, to bezpieczeństwo tylko przez zaciemnienie i tylko tyle.

Nie zamierzam powtarzać wszystkich pozostałych odpowiedzi, ale jest jeszcze jeden aspekt, o którym jeszcze nie wspomniałem - historia znikania danych. Nie wiem, gdzie to znaleźć, ale ...

Zasadniczo chodzi o aplikację internetową, która co kilka nocy w tajemniczy sposób traciła wszystkie swoje dane i nikt nie wiedział dlaczego. Sprawdzanie dzienników później ujawniło, że strona została znaleziona przez google lub innego arbitralnego pająka, który na szczęście POBIERZ (czytaj: GOT) wszystkie linki, które znalazł na stronie - w tym „usuń ten wpis” i „jesteś pewien?” spinki do mankietów.

Właściwie - wspomniano o tym częściowo. Oto historia „nie zmieniaj danych w GET, ale tylko w POST”. Roboty z radością śledzą GET, nigdy POST. Nawet plik robots.txt nie pomaga w walce z źle zachowującymi się robotami.

Powinieneś również pamiętać, że jeśli twoje witryny zawierają link do innych zewnętrznych stron, których nie kontrolujesz za pomocą GET, umieści te dane w nagłówku osoby odwołującej się na zewnętrznych stronach, gdy klikną one linki w Twojej witrynie. Dlatego przesyłanie danych logowania metodami GET ZAWSZE jest dużym problemem. Ponieważ może to ujawnić dane logowania do łatwego dostępu, po prostu sprawdzając dzienniki lub przeglądając Google Analytics (lub podobny).

RFC7231:

„Identyfikatory URI mają być współużytkowane, niezabezpieczone, nawet gdy identyfikują bezpieczne zasoby. Identyfikatory URI są często pokazywane na wyświetlaczach, dodawane do szablonów podczas drukowania strony i przechowywane na różnych niechronionych listach zakładek. Dlatego też nierozsądne jest dołączanie informacje w identyfikatorze URI, które są wrażliwe, identyfikują dane osobowe, lub ryzyko ujawnienia.

Autorzy usług powinni unikać formularzy GET służących do przesyłania poufnych danych, ponieważ dane te zostaną umieszczone w miejscu docelowym żądania. Wiele istniejących serwerów, serwerów proxy i agentów użytkownika rejestruje lub wyświetla cel żądania w miejscach, w których może być widoczny dla osób trzecich. Takie usługi powinny zamiast tego korzystać z przesyłania formularzy POST ”.

RFC wyraźnie stwierdza, że ​​wrażliwych danych nie należy przesyłać za pomocą GET. Z powodu tej uwagi niektórzy implementatorzy mogą nie obsługiwać danych uzyskanych z części zapytania GET z taką samą ostrożnością. Sam 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 mówili, HTTPS zapewnia bezpieczeństwo.

Jednak POST jest nieco bezpieczniejszy niż GET, ponieważ GET można zapisać w historii.

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

GET jest widoczny dla każdego (nawet teraz na twoim ramieniu) i jest zapisywany w pamięci podręcznej, więc jest mniej bezpieczny w korzystaniu z postu, poczta btw bez pewnych procedur kryptograficznych nie jest pewna, dla odrobiny bezpieczeństwa musisz użyć SSL ( https)

Jednym z powodów, dla których test POST jest gorszy ze względu na bezpieczeństwo, jest to, że GET jest domyślnie rejestrowany, parametry i wszystkie dane są prawie uniwersalnie rejestrowane przez serwer.

POST jest odwrotny , prawie ogólnie nie jest rejestrowany , co prowadzi do bardzo trudnej do wykrycia aktywności atakującego.

Nie kupuję argumentu „jest za duży”, to nie jest powód, aby niczego nie rejestrować , przynajmniej 1KB, dałoby długą drogę do zidentyfikowania atakujących pracujących przy słabym punkcie wejścia, dopóki nie wyskoczy, wtedy POST robi podwójna dezinstalacja, umożliwiając każdemu back-doorowi opartemu na HTTP ciche przekazywanie nieograniczonej ilości danych.

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

Więc get jest lepszy w przypadku niezabezpieczonych danych, takich jak ciągi zapytań w Google. Dane uwierzytelniające nigdy nie będą wysyłane za pośrednictwem GET - więc skorzystaj z POST tutaj. Oczywiście cały temat jest nieco bardziej skomplikowany. Jeśli chcesz przeczytać więcej, przeczytaj ten artykuł (w języku niemieckim).

Niedawno opublikowano atak , który pozwala środkowej osobie ujawnić treść skompresowanych żądań HTTPS. Ponieważ nagłówki żądań i adres 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ż wrażliwe, SPDY kompresuje nagłówki żądań, TLS zapewnia również opcjonalną (rzadko używaną) kompresję. W tych scenariuszach łatwiej jest zapobiec atakowi (dostawcy przeglądarek już udostępnili poprawki). Kompresja na poziomie HTTP jest bardziej podstawową funkcją, jest mało prawdopodobne, aby dostawcy ją wyłączyli.

Jest to tylko przykład pokazujący scenariusz, w którym GET jest bezpieczniejszy niż POST, ale nie sądzę, że dobrym pomysłem byłoby wybranie GET zamiast POST z tego powodu ataku. Atak jest dość skomplikowany i wymaga nie trywialnych warunków wstępnych (atakujący musi mieć możliwość kontroli części treści żądania). Lepiej wyłączyć kompresję HTTP w scenariuszach, w których atak byłby szkodliwy.

Oświadczenie: Poniższe punkty dotyczą wyłącznie wywołań interfejsu API, a nie adresów URL witryn.

Bezpieczeństwo w sieci : musisz użyć HTTPS. W tym przypadku GET i POST są równie bezpieczne.

Historia przeglądarki : w przypadku aplikacji typu front-end, takich jak Angular JS, React JS itp. Wywołania API to wywołania AJAX wykonywane przez interfejs. Nie są one częścią historii przeglądarki. Dlatego POST i GET są równie bezpieczne.

Dzienniki po stronie serwera : Za pomocą zestawu zapisu do maskowania danych i formatu dzienników dostępu można ukryć wszystkie lub tylko poufne dane przed adresem URL żądania.

Widoczność danych w konsoli przeglądarki: dla kogoś o złych zamiarach przeglądanie danych POST jest tak samo duże, jak GET.

Dlatego przy odpowiednich praktykach rejestrowania GET API jest tak samo bezpieczny jak POST API. Wszędzie przestrzeganie POST wymusza złe definicje API i należy go unikać.

Poczta jest najbardziej zabezpieczona wraz z zainstalowanym protokołem SSL, ponieważ jest przesyłany w treści wiadomości.

Ale wszystkie te metody są niepewne, ponieważ 7-bitowy protokół, którego używa pod spodem, może zostać zhakowany za pomocą ucieczki. Nawet przez zaporę sieciową aplikacji poziomu 4.

Gniazda też nie są gwarancją ... Mimo że pod pewnymi względami są bardziej bezpieczne.

To jest stary post, ale chciałbym sprzeciwić się niektórym odpowiedziom. Jeśli przesyłasz poufne dane, będziesz chciał używać SSL. Jeśli użyjesz SSL z parametrem GET (np.? Userid = 123), dane te zostaną wysłane w postaci zwykłego tekstu! Jeśli wysyłasz za pomocą testu POST, wartości są umieszczane w zaszyfrowanym ciele wiadomości i dlatego nie są czytelne dla większości ataków MITM.

Duże rozróżnienie polega na tym, gdzie dane są przekazywane. Sensowne jest tylko to, że jeśli dane są umieszczone w adresie URL, NIE MOŻNA go zaszyfrować, w przeciwnym razie nie byłbyś w stanie przekierować na serwer, ponieważ tylko Ty mogłeś odczytać adres URL. Tak działa GET.

Krótko mówiąc, możesz bezpiecznie przesyłać dane w POST 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 z danymi wejściowymi, takimi jak user.name i user.passwd, które powinny obsługiwać nazwę użytkownika i hasło. Jeśli dodamy po prostu? User.name = "my user & user.passwd =" moje hasło ", wówczas żądanie zostanie zaakceptowane przez„ pominięcie strony logowania ”.

Rozwiązaniem tego jest zaimplementowanie filtrów (filtry Java jako e) po stronie serwera i wykrycie, że żadne zapytania łańcuchowe nie są przekazywane jako argumenty GET.