OAuth VPN iekšienē: kuri posmi joprojām prasa TLS

Privātā maršrutēšana nosaka, kas sasniedz serveri; OAuth pārsūtīšanas noteikumi nosaka, kā ceļo katrs ziņojums. Pārlūks, autorizācijas serveris, marķiera galapunkts un resursu serveris var visi atrasties aiz viena VPN un tomēr apmainīties ar ziņojumiem pa dažādiem posmiem. Katram posmam ir sava pārsūtīšanas prasība, un VPN nevienu no tām neat slābina. VPN robeža un protokola robeža ir divas dažādas līnijas.

Lēmums ir vieglāks, ja pārtraucat jautāt, vai tīkls ir uzticams, un sākat jautāt, kura apmaiņa šķērso kuru robežu.

Izlemiet pa posmiem, nevis pēc tīkla

Pierakstiet galapunktus atsevišķi: autorizācijas galapunkts, marķiera galapunkts, novirzīšanas URI, resursu servera URL, TLS beigu punkts un VPN vārteja. Pēc tam atzīmējiet, kura puse uzsāk katru pieprasījumu un kurp dodas atbilde.

VPN, kas beidzas pie vārtejas, šifrē segmentu līdz tai vārtejai. Pieprasījums var turpināties kā vienkāršs HTTP aiz tās, un šis atlikušais posms nav kļuvis par HTTPS tāpēc, ka iepriekšējais segments tika šifrēts. Tieši šis turpinājums ir posms, kas protokolam rūp. Pirmā lēciena šifrēšana nepadara otro lēcienu drošu.

Pārsūtīšana nes arī pakalpojuma identitātes pārbaudi. Pārlūks validē lietotnes URL sertifikātu; VPN neveic šo validāciju pārlūka vietā un nepadara nevalidētu galapunktu pieņemamu. Sertifikāts nosauc galapunktu, kuru klients domā, ka izsauc. Tunelis uz vārteju nepārdēvē šo galapunktu un nevalidē to.

Autorizācijas atbilde un novirzīšanas URI

Pašreizējā OAuth labākā drošības prakse aizliedz pārsūtīt autorizācijas atbildes pa nešifrētiem savienojumiem. Tas ietver novirzīšanu, kas nes autorizācijas kodu vai marķierus atpakaļ klientam, nevis tikai sākotnējo pieprasījumu.

Tie paši norādījumi nepieļauj HTTP novirzīšanas URI, izņemot norādīto native klienta loopback gadījumu. Iekšējs resursdatora nosaukums nerada jaunu izņēmumu, un DNS nosaukums, kas atrisinās tikai VPN iekšienē, joprojām ir HTTP URL, ja shēma to saka. Pārbaudiet shēmu reģistrētajā URI, ne tikai resursdatora nosaukumu.

Reģistrējiet precīzu HTTPS novirzīšanas URI autorizācijas serverī un turiet sertifikātu validāciju ieslēgtu klientā. Izstrādes saīsne, kas nomāc HTTPS prasību, rada plūsmu, kas uzvedas citādi nekā ražošanas konfigurācija, kuru tai būtu jāatdarina.

Marķiera galapunkts un pieprasījumi ar nesēja marķieri

Marķiera pieprasījums nes akreditācijas datus vai kodu, ko var apmainīt pret piekļuvi. Tā nosūtīšana pa neaizsargātu posmu atklāj materiālu, kam resursu serveris vēlāk uzticēsies, pat ja apkārtējais tīkls ir privāts. Starpniekserveris, kas var nolasīt pieprasījumu, var nolasīt arī tā nestos akreditācijas datus.

Pieprasījumiem uz resursiem ar nesēja marķieri RFC 6750 uzskata TLS par obligātu ieviest un izmantot šajā specifikācijā. Biroja apakštīkla nosaukšana par uzticamu nav vispārējais protokola izņēmums, kas nepieciešams vienkārša teksta nesēja izvietojumam.

Abiem posmiem izmantojiet dokumentētos drošos galapunktu URL. Ja bibliotēka atsakās izsaukt HTTP marķiera galapunktu, šī atteikšanās ir strādājoša specifikācija, nevis konfigurācijas kļūda, kas jāapiet. Ierakstiet šo URL klienta konfigurācijā, nevis atvasiniet to izpildes laikā.

Kur beidzas TLS un ko tas atstāj

Ja TLS beidzas autorizētā frontendā, nosauciet šo frontendu un pārskatiet ceļu no tā līdz lietotnei. Frontends kļūst atbildīgs par pārsūtīšanu, uzticēšanos un konfidencialitāti atlikušajā segmentā, un pakalpojuma atbalstītajai arhitektūrai būtu jāapraksta šis izvietojums.

VPN citur ceļā šīs atbildības neatrisina. Tas arī nepasaka, vai lietotnes URL, ko redz pārlūks, atbilst sertifikātam, ko uzrāda frontends.

Iekšējam izvietojumam pierakstiet beigu punktu un identitāti, ko tas uzrāda. Frontends, kas beidz TLS ar cita nosaukuma sertifikātu, rada pārlūka brīdinājumu, ko operatori bieži nomāc, nevis izlabo.

Native loopback izņēmums ir šaurs

Loopback novirzīšanas izņēmums attiecas uz atzvanīšanu lietotāja paša ierīcē, kur klients un pārlūks dala šo ierīci. Šis izvietojums pieder vienas ierīces atzvanīšanai, un tas neļauj apkalpot parastu autorizācijas serveri vai marķierus nesošu API pa HTTP biroja apakštīklam.

Turiet izņēmumu ierobežotu ar klienta tipu un atzvanīšanu, ko tas apraksta. Tā piemērošana tīmekļa lietotnei, koplietotam iekšējam pakalpojumam vai novirzīšanas URI citā resursdatorā maina izvietojumu, nevis izņēmumu.

Pārbaudiet faktisko plūsmu katrā robežā un salīdziniet to ar klienta tipu. Strādājoša novirzīšana neko nepasaka par to, vai katrs posms, kas nesa marķieri, izmantoja prasīto aizsardzību, un zaļa VPN ikona neko nepasaka par nākamā pieprasījuma shēmu.