Czy adresy URL HTTPS są szyfrowane?

1017

Czy wszystkie adresy URL są szyfrowane podczas korzystania z szyfrowania TLS / SSL (HTTPS)? Chciałbym wiedzieć, ponieważ chcę, aby wszystkie dane URL były ukryte podczas korzystania z TLS / SSL (HTTPS).

Jeśli TLS / SSL zapewnia całkowite szyfrowanie adresów URL, nie muszę się martwić ukrywaniem poufnych informacji przed adresami URL.

Daniel Kivatinos
źródło
76
W każdym razie prawdopodobnie złym pomysłem jest umieszczenie poufnych danych w adresie URL. Będzie źle wyświetlany w adresie przeglądarki, pamiętasz? Ludziom się to nie podoba, jeśli hasło jest widoczne dla każdego, kto zerknie na ekran. Dlaczego uważasz, że musisz podać poufne dane w adresie URL?
jalf
43
Adresy URL są również przechowywane w historii przeglądarki i dziennikach serwera - gdybym chciał gdzieś przechowywać moje imię i hasło, nie byłoby ich w tych dwóch miejscach.
Piskvor opuścił budynek
47
Załóżmy na przykład, że odwiedzam https://somewhere_i_trust/ways_to_protest_against_the_government/. Następnie adres URL zawiera poufne dane, a mianowicie sugestię, że rozważam protest przeciwko mojemu rządowi.
Steve Jessop,
42
Zadawałem sobie to pytanie podczas wysyłania żądania HTTP z natywnej (nie opartej na przeglądarce) aplikacji. Domyślam się, że może to zainteresować twórców aplikacji mobilnych. W tym przypadku powyższe komentarze (choć prawdziwe) są nieistotne (brak widocznego adresu URL, brak historii przeglądania), co sprawia, że ​​odpowiedź, moim zdaniem, jest prosta: „Tak, to jest zaszyfrowane”.
DannyA
23
Dla tych, którzy myślą, że kiedy jesteś HTTPS, nikt nie wie, dokąd zmierzasz, przeczytaj najpierw: Nazwa hosta serwera (np. Example.com) nadal będzie wyciekła z powodu SNI . Nie ma to absolutnie nic wspólnego z DNS, a wyciek nastąpi, nawet jeśli nie korzystasz z DNS lub używasz szyfrowanego DNS.
Pacerier

Odpowiedzi:

912

Tak, połączenie SSL odbywa się między warstwą TCP a warstwą HTTP. Klient i serwer najpierw ustanawiają bezpieczne szyfrowane połączenie TCP (za pośrednictwem protokołu SSL / TLS), a następnie klient wyśle ​​żądanie HTTP (GET, POST, DELETE ...) za pośrednictwem tego szyfrowanego połączenia TCP.

Marc Nowakowski
źródło
98
Nadal warto zwrócić uwagę na rzecz wspomnianą przez @Jalfa w komentarzu do samego pytania. Dane URL będą również zapisywane w historii przeglądarki, co może być niepewne długoterminowo.
Michael Ekstrand
20
Nie tylko POBIERZ lub POST. Może to być również DELETE, PUT, HEAD lub TRACE.
4
Tak, może to być problem z bezpieczeństwem w historii przeglądarki. Ale w moim przypadku nie używam przeglądarki (również oryginalny post nie wspominał o przeglądarce). Używanie niestandardowego wywołania https za kulisami w natywnej aplikacji. Jest to proste rozwiązanie, aby upewnić się, że połączenie serwera z aplikacją jest bezpieczne.
zingle-dingle
28
Należy jednak pamiętać, że rozwiązanie DNS adresu URL prawdopodobnie nie jest szyfrowane. Aby ktoś wąchał Twój ruch, prawdopodobnie nadal widział domenę, do której próbujesz uzyskać dostęp.
ChewToy
21
SNI psuje część „hosta” szyfrowania SSL adresów URL. Możesz to przetestować samodzielnie za pomocą wireshark. Istnieje selektor dla SNI, lub możesz po prostu przejrzeć swoje pakiety SSL podczas łączenia się ze zdalnym hostem.
cmouse
653

Ponieważ nikt nie przewidział przechwytywania drutu, oto jeden.
Nazwa serwera (część domeny adresu URL) jest prezentowana w ClientHellopakiecie zwykłym tekstem .

Poniżej przedstawiono żądanie przeglądarki do:
https://i.stack.imgur.com/path/?some=parameters&go=here

ClientHello SNI Zobacz tę odpowiedź, aby uzyskać więcej informacji na temat pól wersji TLS (są 3 z nich - nie wersje, pola, które zawierają numery wersji!)

Od https://www.ietf.org/rfc/rfc3546.txt :

3.1 Wskazanie nazwy serwera

[TLS] nie zapewnia klientowi mechanizmu informowania serwera o nazwie serwera, z którym się kontaktuje. Może być pożądane, aby klienci dostarczali te informacje, aby ułatwić bezpieczne połączenia z serwerami, które obsługują wiele „wirtualnych” serwerów pod jednym podstawowym adresem sieciowym.

Aby podać nazwę serwera, klienci MOGĄ zawierać rozszerzenie typu „nazwa_serwera” w (rozszerzonym) halo klienta.


W skrócie:

  • FQDN (część domeny URL) MOGĄ być przekazywane w jasny wewnątrz ClientHellopakietu, jeśli jest stosowany rozszerzenie SNI

  • Pozostała część adresu URL ( /path/?some=parameters&go=here) nie ma żadnego interesu, ClientHelloponieważ adres URL żądania jest rzeczą HTTP (OSI Layer 7), dlatego nigdy nie pojawi się w uzgadnianiu TLS (warstwa 4 lub 5). To przyjdzie później w GET /path/?some=parameters&go=here HTTP/1.1żądaniu HTTP, PO ustanowieniu bezpiecznego kanału TLS.


STRESZCZENIE

Nazwa domeny MOŻE być przesyłana w postaci jawnej (jeśli rozszerzenie SNI jest używane w uzgadnianiu TLS), ale adres URL (ścieżka i parametry) jest zawsze szyfrowany.


AKTUALIZACJA MARCA 2019

Dziękujemy carlin.scott za podniesienie tego.

Ładunek w rozszerzeniu SNI można teraz zaszyfrować za pomocą tej propozycji projektu RFC . Ta funkcja istnieje tylko w TLS 1.3 (jako opcja i jej implementacja zależy od obu końców) i nie ma wstecznej kompatybilności z TLS 1.2 i niższymi.

CloudFlare to robi i możesz przeczytać więcej o wewnętrznych elementach tutaj - jeśli kurczak musi przyjść przed jajkiem, gdzie go umieszczasz?

W praktyce oznacza to, że zamiast przesyłać FQDN w postaci zwykłego tekstu (jak pokazuje program przechwytujący Wireshark), jest on teraz szyfrowany.

UWAGA: Dotyczy to bardziej kwestii prywatności niż bezpieczeństwa, ponieważ odwrotne wyszukiwanie DNS MOŻE ujawnić docelowego hosta docelowego.

evilSnobu
źródło
37
Idealna odpowiedź, z pełnym wyjaśnieniem od A do Z. Uwielbiam streszczenie. Zrobiłem mój dzień @evilSnobu
oscaroscar
4
Idealna odpowiedź, głosuj! Nadal rozważ część klienta, ponieważ historia przeglądarki może być nieszczelna. Jednak w przypadku warstwy transportowej parametry adresu URL są szyfrowane.
Jens Kreidler,
2
Być może warto zaktualizować tę odpowiedź, uwzględniając fakt, że TLS 1.3 szyfruje rozszerzenie SNI, a największy CDN właśnie to robi: blog.cloudflare.com/encrypted-sni Oczywiście sniffer pakietów mógłby po prostu wyszukać odwrotny dns dla adresy IP, z którymi się łączysz.
carlin.scott
@evilSnobu, ale nazwa użytkownika: hasło część nazwy użytkownika: hasł[email protected] jest szyfrowana, prawda? Dlatego przesyłanie poufnych danych w adresie URL przy użyciu protokołu https jest bezpieczne.
Maksim Shamihulau
1
Są szyfrowane w sieci (w transporcie), ale jeśli któryś z użytkowników (użytkownik lub serwer) zarejestruje adres URL do zwykłego pliku tekstowego i nie odkaże poświadczeń ... teraz jest inna rozmowa.
evilSnobu,
159

Jak już wskazały inne odpowiedzi , „adresy URL” https są rzeczywiście szyfrowane. Jednak twoje żądanie / odpowiedź DNS podczas rozwiązywania nazwy domeny prawdopodobnie nie jest, i oczywiście, jeśli korzystasz z przeglądarki, twoje adresy URL mogą być również rejestrowane.

Zach Scrivena
źródło
21
Nagrywanie adresów URL jest ważne, ponieważ istnieją hacki JavaScript, które pozwalają całkowicie niepowiązanej witrynie na sprawdzenie, czy dany adres URL znajduje się w Twojej historii, czy nie. Możesz sprawić, że adres URL stanie się niemożliwy do odczytania, umieszczając w nim długi losowy ciąg znaków, ale jeśli jest to publiczny adres URL, osoba atakująca może stwierdzić, że został odwiedzony, a jeśli ma w nim krótki sekret, wówczas osoba atakująca może użyć siły z rozsądną prędkością.
Steve Jessop,
8
@ SteveJessop, proszę podać link do „hacków Javascript, które pozwalają całkowicie niepowiązanej witrynie na sprawdzenie, czy dany adres URL jest w twojej historii”
Pacerier
6
@Pacerier: hacki data oczywiście, ale co mi chodzi w tym czasie było takie rzeczy jak stackoverflow.com/questions/2394890/... . W 2010 r. Badano te problemy i udoskonalano ataki, ale w tej chwili tak naprawdę nie śledzę ich.
Steve Jessop,
2
@Pacerier: więcej przykładów: webdevwonders.com/… , webdevwonders.com/…
Steve Jessop
1
Możesz używać OpenDNS z jego zaszyfrowaną usługą DNS. Używam go na komputerze Mac, ale okazało się, że wersja systemu Windows nie działa poprawnie. To było jakiś czas temu, więc teraz może działać OK. Dla Linuksa jeszcze nic. opendns.com/about/innovations/dnscrypt
SPRBRN
101

Całe żądanie i odpowiedź są szyfrowane, w tym adres URL.

Pamiętaj, że gdy używasz serwera proxy HTTP, zna on adres (domenę) serwera docelowego, ale nie zna żądanej ścieżki na tym serwerze (tzn. Żądanie i odpowiedź są zawsze szyfrowane).

Peter Štibraný
źródło
1
Cała prośba. Nazwa hosta jest wysyłana w sposób wyraźny. Cała reszta jest szyfrowana.
Sam Sirry,
98

Zgadzam się z poprzednimi odpowiedziami:

Mówiąc wprost:

W przypadku TLS pierwsza część adresu URL ( https://www.example.com/ ) jest nadal widoczna podczas budowania połączenia. Druga część (/ herearemygetparameters / 1/2/3/4) jest chroniona przez TLS.

Istnieje jednak wiele powodów, dla których nie należy umieszczać parametrów w żądaniu GET.

Po pierwsze, jak już wspomniano przez innych: - wyciek przez pasek adresu przeglądarki - wyciek przez historię

Oprócz tego masz przeciek adresu URL przez odsyłacz http: użytkownik widzi witrynę A w TLS, a następnie klika link do witryny B. Jeśli obie strony są w TLS, żądanie do witryny B będzie zawierać pełny adres URL z witryny A w parametr odsyłający żądania. A administrator z witryny B może pobrać go z plików dziennika serwera B.)

Tobiasz
źródło
3
@EJP Nie rozumiesz, co mówi Tobiasz. Mówi, że jeśli klikniesz link w witrynie A, który przeniesie Cię do witryny B, witryna B otrzyma adres URL strony odsyłającej. Na przykład, jeśli jesteś na siteA.com?u=nazwa_użytkownika&pw=123123 , to siteB.com (do którego link znajduje się na stronie siteA.com) otrzyma „ siteA.com?u=nazwa_użytkownika&pw=123123 ” jako odnośnik Adres URL wysyłany do witryny B.com w HTTPS przez przeglądarkę. Jeśli to prawda, to bardzo źle. Czy to prawda Tobiasz?
trusktr
9
@EJP, domena jest widoczna ze względu na SNI, z którego korzystają wszystkie nowoczesne przeglądarki internetowe. Zobacz także ten diagram z EFF pokazujący, że każdy może zobaczyć domenę witryny, którą odwiedzasz. Tu nie chodzi o widoczność przeglądarki. Chodzi o to, co jest widoczne dla podsłuchujących.
Buge
10
@trusktr: Przeglądarki nie powinny wysyłać nagłówka strony odsyłającej ze stron HTTPS. Jest to część specyfikacji HTTP .
Martin Geisler,
8
@MartinGeisler, Słowo kluczowe to „powinno”. Przeglądarki nie dbają zbytnio o „powinien” (w przeciwieństwie do „musi”). Z własnego linku: „zdecydowanie zalecamy, aby użytkownik mógł wybrać, czy pole Odsyłacz ma być wysyłane. Na przykład klient przeglądarki może mieć przełącznik do przeglądania w trybie otwartym / anonimowym, co odpowiednio włącza / wyłącza wysyłanie Referer and From information ” . Ops, czyli dokładnie to, co zrobił Chrome. Z wyjątkiem Chrome wycieka Polecającego, nawet jeśli jesteś w trybie incognito .
Pacerier
48

Dodatek do pomocnej odpowiedzi od Marca Novakowskiego - adres URL jest przechowywany w dziennikach na serwerze (np. W / etc / httpd / logs / ssl_access_log), więc jeśli nie chcesz, aby serwer dłużej przechowywał informacje nie umieszczaj go w adresie URL.

Rhodri Cusack
źródło
34

Tak i nie.

Część adresu serwera NIE jest szyfrowana, ponieważ służy do konfigurowania połączenia.

Może to ulec zmianie w przyszłości w przypadku zaszyfrowanego SNI i DNS, ale od 2018 r. Obie technologie nie są powszechnie używane.

Ścieżka, ciąg zapytania itp. Są szyfrowane.

Uwaga dla żądań GET użytkownik nadal będzie mógł wyciąć i wkleić adres URL poza pasek lokalizacji i prawdopodobnie nie będziesz chciał umieszczać w nim poufnych informacji, które będą widoczne dla każdego, kto patrzy na ekran.

SoapBox
źródło
8
Chciałbym dać +1, ale uważam, że „tak i nie” wprowadza w błąd - należy to zmienić, aby wskazać, że nazwa serwera zostanie rozwiązana za pomocą DNS bez szyfrowania.
Lawrence Dol
7
W moim rozumieniu OP używa słowa URL we właściwym znaczeniu. Myślę, że ta odpowiedź jest bardziej myląca, ponieważ nie robi wyraźnej różnicy między nazwą hosta w adresie URL a nazwą hosta w rozdzielczości DNS.
Guillaume,
4
Adres URL jest szyfrowany. Każdy aspekt transakcji HTTP jest szyfrowany. Nie tylko „wszystko inne”. Kropka. -1.
user207421
4
@EJP ale wyszukiwanie DNS nie wykorzystać to, co jest w pewnym momencie część adresu URL, tak aby osoby nietechnicznym, cały adres URL nie jest szyfrowana. Osoba nietechniczna, która po prostu korzysta z Google.com w celu wyszukiwania rzeczy nietechnicznych, nie wie, gdzie ostatecznie znajdują się dane ani w jaki sposób są przetwarzane. Domena, która jest częścią adresu URL odwiedzanego przez użytkownika, nie jest w 100% zaszyfrowana, ponieważ ja jako atakujący mogę wąchać, którą stronę odwiedza. Tylko ścieżka / adresu URL jest z natury zaszyfrowana dla laika (nie ma znaczenia jak).
trusktr
6
@EJP, @ trusktr, @ Lawrence, @ Guillaume. Wszyscy się mylicie. To nie ma nic wspólnego z DNS. SNI „ wyślij nazwę domeny wirtualnej w ramach negocjacji TLS ”, więc nawet jeśli nie korzystasz z DNS lub jeśli Twój DNS jest zaszyfrowany, sniffer nadal widzi nazwę hosta twoich żądań.
Pacerier
9

Strona trzecia monitorująca ruch może również być w stanie określić odwiedzaną stronę, badając ruch i porównując go z ruchem innego użytkownika podczas odwiedzania witryny. Na przykład, jeśli w witrynie były tylko 2 strony, jedna znacznie większa od drugiej, porównanie wielkości transferu danych powiedziałoby, którą stronę odwiedziłeś. Istnieją sposoby, w jakie można to ukryć przed firmami zewnętrznymi, ale nie są to normalne zachowania serwera lub przeglądarki. Zobacz na przykład ten artykuł SciRate, https://scirate.com/arxiv/1403.0297 .

Zasadniczo inne odpowiedzi są poprawne, praktycznie jednak ten dokument pokazuje, że odwiedzone strony (np. URL) można dość skutecznie określić.

pbhj
źródło
Byłoby to naprawdę możliwe tylko w przypadku bardzo małych witryn, aw takich przypadkach temat / ton / charakter witryny prawdopodobnie nadal byłby mniej więcej taki sam na każdej stronie.
Cameron
5
Z cytatu, który podałem: „Prezentujemy atak analizy ruchu na ponad 6000 stron internetowych obejmujący wdrożenia HTTPS 10 najczęściej używanych, wiodących w branży stron internetowych w takich obszarach, jak opieka zdrowotna, finanse, usługi prawne i streaming wideo. Nasz atak identyfikuje poszczególne strony w ta sama strona z 89% dokładnością [...] ”. Wydaje się, że twój wniosek co do wykonalności jest błędny.
pbhj
2
Dla każdego, kto chce przeczytać więcej na temat tego rodzaju podatności, tego rodzaju ataki są ogólnie nazywane atakami bocznymi .
Dan Bechard 18.04.16
7

Nie zawsze możesz liczyć na prywatność pełnego adresu URL. Na przykład, jak to czasami bywa w sieciach korporacyjnych, dostarczone urządzenia, takie jak komputer firmowy, są skonfigurowane z dodatkowym „zaufanym” certyfikatem głównym, dzięki czemu przeglądarka może spokojnie zaufać inspekcji proxy (man-in-the-middle) ruchu https . Oznacza to, że pełny adres URL jest udostępniany do kontroli. Zazwyczaj jest to zapisywane w dzienniku.

Co więcej, twoje hasła są również ujawnione i prawdopodobnie zarejestrowane, a to kolejny powód, aby używać haseł jednorazowych lub często je zmieniać.

Wreszcie treść żądania i odpowiedzi jest również ujawniana, jeśli nie jest w inny sposób szyfrowana.

Jeden przykład konfiguracji inspekcji opisano tutaj przez Checkpoint . W ten sposób można również skonfigurować „kafejkę internetową” w starym stylu z wykorzystaniem dostarczonych komputerów.

Don Gillis
źródło
6

Link do mojej odpowiedzi na zduplikowane pytanie . Adres URL jest nie tylko dostępny w historii przeglądarek, dzienniki po stronie serwera, ale jest również wysyłany jako nagłówek odsyłacza HTTP, który, jeśli korzystasz z treści stron trzecich, udostępnia adres URL źródłom poza Twoją kontrolą.

JoshBerke
źródło
Pod warunkiem, że Twoje połączenia z osobami trzecimi są również HTTPS, chociaż nie jest to problem, prawda?
Liam,
3
Zostałby zaszyfrowany przy użyciu certyfikatu strony trzeciej, aby mogli zobaczyć adres URL
JoshBerke,
5

Jest teraz 2019, a TLS v1.3 został wydany. Według Cloudflare SNI może być szyfrowany dzięki TLS v1.3. Więc powiedziałem sobie świetnie! zobaczmy, jak to wygląda w pakietach TCP cloudflare.com. Tak więc złapałem pakiet uścisku dłoni „klient cześć” z odpowiedzi serwera cloudflare używającego Google Chrome jako przeglądarki i wireshark jako sniffera pakietów. Nadal mogę odczytać nazwę serwera w postaci zwykłego tekstu w pakiecie hello klienta.

wprowadź opis zdjęcia tutaj

Uważaj więc na to, co możesz przeczytać, ponieważ nadal nie jest to anonimowe połączenie. Oprogramowanie pośrednie między klientem a serwerem może rejestrować każdą domenę żądaną przez klienta.

Wygląda więc na to, że szyfrowanie SNI wymaga dodatkowych implementacji do współpracy z TLSv1.3

W poniższym artykule opisano szyfrowanie SNI zapewnianego przez Cloudflare jako część TLSv1.3. Jednak wszystkie adresy URL HTTPs z cloudflare.com są w postaci zwykłego tekstu w pakiecie TCP w TLS 1.3

[ https://blog.cloudflare.com/encrypted-sni/][3]

Nicolas Guérinet
źródło
„SNI może być szyfrowany” - to jest kluczowy punkt. Sprawdzanie cloudflare.com/ssl/encrypted-sni za pomocą aktualnej przeglądarki Google Chrome mówi „Twoja przeglądarka nie szyfrowała SNI podczas odwiedzania tej strony”. Tango wymaga dwóch ...
Piskvor opuścił budynek
Najwyraźniej obecny Firefox potrafi ESNI, ale jest domyślnie wyłączony: musisz włączyć network.security.esni.enabled, ustawić network.trr.modena 2 (co obecnie ustawia przelicznik DoH na CloudFlare) i ponownie uruchomić przeglądarkę (sic!); wtedy użyje ESNI - jeśli jest obsługiwany przez infrastrukturę domeny. Szczegółowe informacje można znaleźć na blog.mozilla.org/security/2018/10/18/… .
Piskvor opuścił budynek
3

Tak i nie.

Rzeczywisty adres URL jest szyfrowany, co oznacza, że ​​ktoś nie może podać dokładnej strony w odwiedzanej witrynie. Jednak nagłówek TLS zawiera nazwę hosta serwera, do którego uzyskujesz dostęp (np. Www.quora.com) niezaszyfrowanego. DNS prawie nigdy nie jest szyfrowany, a także wyciek nazwy hosta, do którego masz dostęp. To zapytanie DNS prawie zawsze jest domyślnie skierowane przeciwko serwerom twojego dostawcy usług internetowych, dzięki czemu mogą łatwo zobaczyć nazwę hosta każdej witryny, do której masz dostęp, poprzez wąchanie twoich żądań DNS do innych serwerów DNS lub nagrywanie twoich na własne.

Jeśli jednak zastanawiasz się, czy ktoś może dowiedzieć się, do której witryny korzystasz, to nie wystarczy. HTTPS działa w warstwie OSI 4 i szyfruje wszystkie dane na tym poziomie, ale niższe poziomy są pozostawione sieciom, które je przenoszą. Ktoś nadal może po prostu prześledzić ścieżkę i miejsce docelowe ruchu w warstwie OSI 3. Oznacza to, że ktoś wąchający ruch może znaleźć adres IP i rozszerzenie nazwy domeny witryny, do której miałeś dostęp.

Co gorsza, po raz pierwszy (i kilka kolejnych razy, w zależności od tego, jak / kiedy pamięć podręczna DNS zostanie wyczyszczona) prawdopodobnie wyślesz niezaszyfrowane zapytanie DNS na dowolny serwer DNS, który zażąda adresu IP docelowego adresu URL HTTPS (ponownie przez domyślnie zazwyczaj serwery twojego dostawcy usług internetowych). Każdy, kto ma dostęp do twojego ruchu na ścieżce do twojego serwera DNS, może być w stanie wąchać to zapytanie.

Jeśli szukasz wysokiego standardu prywatności, musisz uzupełnić HTTPS o zaufaną szyfrowaną sieć VPN i / lub szyfrowaną usługę proxy. Możesz także zajrzeć do DNSSEC, aby chronić swoje zapytania DNS. Ta usługa musi być godna zaufania, ponieważ może łatwo wykonać powyższe śledzenie źródeł i miejsc docelowych ruchu.

Himanshu Patel
źródło
2

Chociaż istnieją już dobre odpowiedzi, większość z nich koncentruje się na nawigacji w przeglądarce. Piszę to w 2018 roku i prawdopodobnie ktoś chce wiedzieć o bezpieczeństwie aplikacji mobilnych.

W przypadku aplikacji mobilnych , jeśli kontrolujesz oba końce aplikacji (serwer i aplikacja), o ile korzystasz z HTTPS , jesteś bezpieczny . iOS lub Android zweryfikują certyfikat i złagodzą ewentualne ataki MiM (byłby to jedyny słaby punkt tego wszystkiego). Możesz przesyłać poufne dane za pośrednictwem połączeń HTTPS, które zostaną zaszyfrowane podczas transportu . Tylko Twoja aplikacja i serwer będą znać wszelkie parametry wysyłane przez https.

Jedynym „być może” byłoby to, gdyby klient lub serwer został zainfekowany złośliwym oprogramowaniem, które może zobaczyć dane przed ich opakowaniem w https. Ale jeśli ktoś zostanie zainfekowany tego rodzaju oprogramowaniem, będzie miał dostęp do danych, bez względu na to, czego użyjesz do ich transportu.

Ricardo BRGWeb
źródło
1

Ponadto, jeśli budujesz interfejs ReSTful API, problemy z wyciekami z przeglądarki i odsyłaczem HTTP są w większości łagodzone, ponieważ klient może nie być przeglądarką i nie możesz klikać linków.

W takim przypadku zaleciłbym logowanie oAuth2, aby uzyskać token nośnika. W takim przypadku jedynymi wrażliwymi danymi byłyby początkowe dane uwierzytelniające ... które prawdopodobnie powinny znajdować się w żądaniu przesłanym

Chris Rutledge
źródło