Subdomain-e të përbashkëta, dy hyrje: kush sheh cilat regjistrime?

Klinika A dhe Klinika B ndajnë një bazë kodi, dy subdomain-e dhe një përzierje vizitorësh nga zyra dhe përmes VPN. Ekipet e rrjetit priren t'i konfigurojnë të dyja hyrjet veçmas, dhe kjo është në rregull, për sa kohë aplikacioni nuk e bën këtë. Kontrollet më poshtë i përkasin aplikacionit dhe duhet të sillen njësoj pavarësisht se nga cila derë erdhi kërkesa.

Së pari: emri i host-it emërton vetëm një qiramarrës

Zgjidhni emrin e host-it të kërkuar kundrejt një hartëzimi që mban administratori, dhe refuzoni çdo gjë të panjohur. Përdorni vlerën e host-it të validuar nga framework-u në vend të header-it të papërpunuar, që një Host i falsifikuar të mos mund të injektojë një çelës kërkimi. Një përputhje e suksesshme i thotë kodit cilën konfigurim qiramarrësi dhe cilën markë të ngarkojë. Nuk thotë asgjë nëse thirrësi mund t'i shohë të dhënat e atij qiramarrësi. Mbajeni atë pyetje të dytë në një funksion të veçantë me një hyrje të veçantë.

Një funksion ndihmës i përbashkët që kthen si kontekstin ashtu edhe lejen nga një kërkim i vetëm i emrit të host-it është fillimi i defektit.

Së dyti: pjesëtarësia vjen nga sesioni

Kërkoni pjesëtarësitë aktive të përdoruesit të autentikuar dhe krahasoni ato me qiramarrësin nga kontrolli i parë. Një përdorues që i përket të dyja klinikave mund të ndërrojë, por ndërrimi duhet të jetë një veprim i qartë i regjistruar në kontekstin e kërkesës, jo një përfundim nga URL. Një përdorues që i përket një klinike dhe kërkon tjetrën refuzohet, përfshirë shkarkimet dhe thirrjet API.

Testoni rastin negativ duke redaktuar një identifikues regjistrimi dhe një parametër qiramarrësi. Nëse ndonjë nga ndryshimet kthen të dhëna, shtrirja lexohet nga kërkesa dhe jo nga pjesëtarësia e verifikuar.

Shtrirja e cookie-ve dhe hyrja e vetme vendosin se ku mund të paraqitet një llogari. Ato nuk vendosin se çfarë mund të lexojë ajo llogari.

Së treti: rrjeti nuk provon asgjë për personin

Një portë VPN autentikon një tunel, dhe një listë publike lejimesh autentikon një interval adresash. Asnjëra nuk identifikon një person. NAT grumbullon shumë përdorues në një adresë burimi, dhe një interval zyre bën të njëjtën gjë për të gjithë në ndërtesë. Trajtoni të dyja si fakte transporti dhe mbani autorizimin në aplikacion, ose në një integrim që pohon identitetin në mënyrë eksplicite dhe shqyrtohet si i tillë.

DNS është një fakt i tretë transporti. Një përgjigje private kërkon një rrugë private, dhe një frontend publik kërkon një shteg origjine të mbështetur. Asnjëri prej tyre nuk mban një leje.

Një fjali për në mur: rrjeti vendos se si arrin një kërkesë, dhe aplikacioni vendos se çfarë mund të lexojë.

Së katërti: ekzekutoni matricën në të dyja hyrjet

Përdorni llogari të kontrolluara për të ushtruar A në A, B në B, A në B, një emër host-i të panjohur dhe një llogari të autentikuar pa pjesëtarësi. E katërta dhe e pesta duhet të dështojnë të mbyllura dhe nuk duhet të bien kurrë në një qiramarrës të paracaktuar. Ekzekutoni të njëjtën matricë edhe përmes hyrjes VPN, me një kavanoz sesioni për çdo llogari:

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

Më pas ndryshoni një zë të listës së lejeve dhe ekzekutoni përsëri. Një rezultat që lëviz do të thotë se një kontroll rrjeti po merr një vendim autorizimi.

Përsëritni matricën pas çdo ndryshimi në frontend, sepse një shteg i dytë kodi që anashkalon kontrollin është mënyra më e zakonshme se si ky kufi gërryehet. Rezultati i pritur është i mërzitshëm: çdo hyrje prodhon të njëjtat përgjigje.