Privatno usmjeravanje odlučuje ko dolazi do servera; OAuth pravila prijenosa odlučuju kako putuje svaka poruka. Preglednik, poslužitelj autorizacije, krajnja točka tokena i poslužitelj resursa mogu svi stajati iza istog VPN-a i ipak razmjenjivati poruke preko različitih dionica. Svaka dionica ima svoj zahtjev za prijenos, a VPN ni jedan od njih ne ublažava. Granica VPN-a i granica protokola dvije su različite crte.

Odluka je lakša ako prestanete pitati je li mreža pouzdana i počnete pitati koja razmjena prelazi koju granicu.

Odlučite po dionici, ne po mreži

Zapišite krajnje točke odvojeno: krajnja točka autorizacije, krajnja točka tokena, URI preusmjeravanja, URL poslužitelja resursa, točka završetka TLS-a i VPN pristupnik. Zatim označite koja strana pokreće svaki zahtjev i kamo ide odgovor.

VPN koji završava na pristupniku šifrira segment do tog pristupnika. Zahtjev se može nastaviti kao obični HTTP iza njega, a ta preostala dionica nije postala HTTPS zato što je raniji segment bio šifriran. Upravo je to nastavljanje dionica do koje je protokolu stalo. Šifriranje prvog skoka ne čini drugi skok sigurnim.

Prijenos nosi i provjeru identiteta usluge. Preglednik provjerava certifikat za URL aplikacije; VPN ne obavlja tu provjeru u ime preglednika i ne čini neprovjerenu krajnju točku prihvatljivom. Certifikat imenuje krajnju točku za koju klijent misli da je zove. Tunel do pristupnika ne preimenuje tu krajnju točku niti je provjerava.

Odgovor autorizacije i URI preusmjeravanja

OAuth najbolja trenutačna sigurnosna praksa zabranjuje prijenos odgovora autorizacije preko nešifriranih veza. To obuhvaća preusmjeravanje koje nosi autorizacijski kod ili tokene natrag klijentu, a ne samo početni zahtjev.

Iste smjernice zabranjuju HTTP URI-jeve preusmjeravanja, osim navedenog slučaja loopbacka za native klijenta. Interno ime hosta ne stvara novo izuzeće, a DNS ime koje se razrješava samo unutar VPN-a i dalje je HTTP URL ako shema tako kaže. Provjerite shemu u registriranom URI-ju, a ne samo ime hosta.

Registrirajte točan HTTPS URI preusmjeravanja kod poslužitelja autorizacije i držite provjeru certifikata uključenom na klijentu. Razvojni prečac koji potiskuje zahtjev za HTTPS stvara tok koji se ponaša drukčije od produkcijske konfiguracije koju bi trebao oponašati.

Krajnja točka tokena i zahtjevi s bearer tokenom

Zahtjev za token nosi vjerodajnice ili kod koji se može zamijeniti za pristup. Slanje preko nezaštićene dionice izlaže materijal kojemu će poslužitelj resursa kasnije vjerovati, čak i ako je okolna mreža privatna. Proxy koji može pročitati zahtjev može pročitati i vjerodajnicu koju on nosi.

Za zahtjeve za resursima s bearer tokenom RFC 6750 smatra TLS obveznim za implementaciju i upotrebu prema toj specifikaciji. Nazivati uredsku podmrežu pouzdanom nije opće protokolno izuzeće koje treba postavljanje s bearer tokenima preko otvorenog teksta.

Upotrijebite dokumentirane sigurne URL-ove krajnjih točaka za obje dionice. Ako biblioteka odbija pozvati HTTP krajnju točku tokena, to odbijanje je specifikacija koja radi, a ne konfiguracijska pogreška koju treba zaobići. Zapišite taj URL u konfiguraciju klijenta umjesto da ga izvodite tijekom izvršavanja.

Gdje TLS završava i što to ostavlja

Ako TLS završava na ovlaštenom frontendu, imenujte taj frontend i pregledajte put od njega do aplikacije. Frontend postaje odgovoran za prosljeđivanje, povjerenje i povjerljivost na preostalom segmentu, a podržana arhitektura usluge trebala bi opisati taj raspored.

VPN drugdje na putu ne rješava te odgovornosti. Također vam ne kaže odgovara li URL aplikacije koji preglednik vidi certifikatu koji frontend predstavlja.

Za interno postavljanje zabilježite točku završetka i identitet koji predstavlja. Frontend koji završava TLS certifikatom za drugo ime stvara upozorenje u pregledniku koje operateri često potiskuju umjesto da ga poprave.

Izuzeće za native loopback je usko

Izuzeće za loopback preusmjeravanje odnosi se na povratni poziv na korisnikovu vlastitom uređaju, gdje klijent i preglednik dijele taj uređaj. Taj raspored pripada povratnom pozivu na jednom uređaju i ne daje pravo posluživanja običnog poslužitelja autorizacije ili API-ja s tokenima preko HTTP-a uredskoj podmreži.

Držite izuzeće ograničeno na tip klijenta i povratni poziv koji opisuje. Njegova primjena na web aplikaciju, zajedničku internu uslugu ili URI preusmjeravanja na drugom hostu mijenja postavljanje, a ne izuzeće.

Testirajte stvarni tok na svakoj granici i usporedite ga s tipom klijenta. Preusmjeravanje koje radi ne govori ništa o tome je li svaka dionica koja je nosila token upotrijebila propisanu zaštitu, a zelena ikona VPN-a ne govori ništa o shemi sljedećeg zahtjeva.

Povezani članci