Koplietoti apakšdomēni, divas ieejas: kas kuras uzskaites redz?

Klīnika A un Klīnika B koplieto vienu koda bāzi, divus apakšdomēnus un biroja un VPN apmeklētāju sajaukumu. Tīkla komandas mēdz konfigurēt abas ieejas atsevišķi, un tas ir labi, kamēr lietojumprogramma to nedara. Tālāk minētās pārbaudes pieder lietojumprogrammai un tām jāuzvedas vienādi neatkarīgi no tā, kuras durvis pieprasījums izmantoja.

Pirmkārt: resursdatora nosaukums tikai nosauc nomnieku

Atrisiniet pieprasīto resursdatora nosaukumu pret kartējumu, ko uztur administrators, un noraidiet visu nezināmo. Izmantojiet ietvara validēto resursdatora vērtību, nevis neapstrādātu galveni, lai viltots Host nevarētu ievadīt meklēšanas atslēgu. Veiksmīga atbilstība pastāsta kodam, kuru nomnieka konfigurāciju un kuru zīmolu ielādēt. Tā neko nepasaka par to, vai izsaucējs drīkst redzēt šī nomnieka datus. Turiet šo otro jautājumu atsevišķā funkcijā ar atsevišķu ievadi.

Koplietota palīgfunkcija, kas no vienas resursdatora nosaukuma meklēšanas atgriež gan kontekstu, gan atļauju, ir kļūdas sākums.

Otrkārt: dalība nāk no sesijas

Atrodiet autentificētā lietotāja aktīvās dalības un salīdziniet tās ar nomnieku no pirmās pārbaudes. Lietotājs, kas pieder abām klīnikām, drīkst pārslēgties, bet pārslēgšanai jābūt skaidrai darbībai, kas ierakstīta pieprasījuma kontekstā, nevis secinājumam no URL. Lietotājam, kas pieder vienai klīnikai un pieprasa otru, tiek atteikts, tostarp lejupielādēm un API izsaukumiem.

Pārbaudiet negatīvo gadījumu, mainot ieraksta identifikatoru un nomnieka parametru. Ja kāda no izmaiņām atgriež datus, tvērums tiek lasīts no pieprasījuma, nevis no pārbaudītās dalības.

Sīkfailu tvērums un vienotā pieteikšanās nosaka, kur kontu var uzrādīt. Tās nenosaka, ko šis konts drīkst lasīt.

Treškārt: tīkls neko nepierāda par personu

VPN vārteja autentificē tuneli, un publisks atļauto adrešu saraksts autentificē adrešu diapazonu. Neviens no tiem neidentificē personu. NAT saspiež daudzus lietotājus vienā avota adresē, un biroja diapazons dara to pašu visiem ēkā. Uztveriet abus kā transporta faktus un turiet autorizāciju lietojumprogrammā vai integrācijā, kas skaidri apliecina identitāti un tiek attiecīgi pārskatīta.

DNS ir trešais transporta fakts. Privātai atbildei nepieciešams privāts maršruts, un publiskai priekšpusei nepieciešams atbalstīts izcelsmes ceļš. Neviens no tiem nenes atļauju.

Viens teikums pie sienas: tīkls nosaka, kā pieprasījums ierodas, un lietojumprogramma nosaka, ko tas drīkst lasīt.

Ceturtkārt: palaidiet matricu abās ieejās

Izmantojiet kontrolētus kontus, lai pārbaudītu A pie A, B pie B, A pie B, nezināmu resursdatora nosaukumu un autentificētu kontu bez dalībām. Ceturtajam un piektajam jācieš neveiksme slēgti un nekad nav jānokrīt uz noklusējuma nomnieku. Palaidiet to pašu matricu arī caur VPN ieeju, ar vienu sesijas burku katram kontam:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

Pēc tam mainiet vienu atļauto adrešu saraksta ierakstu un palaidiet vēlreiz. Rezultāts, kas pārvietojas, nozīmē, ka tīkla kontrole pieņem autorizācijas lēmumu.

Atkārtojiet matricu pēc jebkuras priekšpuses izmaiņas, jo otrs koda ceļš, kas izlaiž pārbaudi, ir visizplatītākais veids, kā šī robeža erodē. Gaidāmais rezultāts ir garlaicīgs: katra ieeja sniedz tās pašas atbildes.