Дељени поддомени, два улаза: ко види које записе?

Клиника A и Клиника B деле једну кодну базу, два поддомена и мешавину посетилаца из канцеларије и преко VPN-а. Мрежни тимови обично одвојено конфигуришу два улаза, и то је у реду, док год апликација то не чини. Провере испод припадају апликацији и морају се понашати једнако без обзира на то кроз која су врата захтев ушао.

Прво: назив хоста именује само закупца

Разрешите тражени назив хоста према мапирању које одржава администратор и одбијте све непознато. Користите проверену вредност хоста из оквира уместо сировог заглавља, да ковани Host не би могао да убаци кључ за претрагу. Успешно подударање каже коду коју конфигурацију закупца и које брендирање да учита. Оно не говори ништа о томе може ли позивалац да види податке тог закупца. Друго питање држите у засебној функцији са засебним улазом.

Заједничка помоћна функција која из једног тражења назива хоста враћа и контекст и дозволу почетак је грешке.

Друго: чланство долази из сесије

Пронађите активна чланства аутентификованог корисника и упоредите их са закупцем из прве провере. Корисник који припада обема клиникама може да се пребацује, али пребацивање мора бити изричита радња забележена у контексту захтева, а не закључак из URL-а. Кориснику који припада једној клиници и тражи другу приступ се одбија, укључујући преузимања и API позиве.

Тестирајте негативан случај тако што ћете изменити идентификатор записа и параметар закупца. Ако било која измена врати податке, опсег се чита из захтева, а не из потврђеног чланства.

Опсег колачића и јединствена пријава одређују где се рачун може представити. Они не одређују шта тај рачун сме да чита.

Треће: мрежа не доказује ништа о особи

VPN пролаз аутентификује тунел, а јавни списак дозвола аутентификује распон адреса. Ниједно не идентификује особу. NAT сабија много корисника у једну изворну адресу, а канцеларијски распон чини исто за све у згради. Третирајте обоје као транспортне чињенице и држите ауторизацију у апликацији или у интеграцији која изричито тврди идентитет и као таква се прегледа.

DNS је трећа транспортна чињеница. Приватан одговор тражи приватну руту, а јавни фронтенд тражи подржану путању до извора. Ниједно од њих не носи дозволу.

Једна реченица за зид: мрежа одлучује како захтев стиже, а апликација одлучује шта сме да чита.

Четврто: покрените матрицу на оба улаза

Користите контролисане рачуне да проверите A на A, B на B, A на B, непознат назив хоста и аутентификован рачун без чланстава. Четврти и пети морају пасти затворено и никада не смеју да се врате на закупца као подразумевано. Покрените исту матрицу и кроз VPN улаз, са једном теглом сесије по рачуну:

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

Затим промените унос на списку дозвола и покрените поново. Резултат који се помери значи да мрежна контрола доноси одлуку о ауторизацији.

Поновите матрицу након сваке промене фронтенда, јер други пут кроз код који прескаче проверу најчешћи је начин на који се ова граница еродира. Очекивани резултат је досадан: сваки улаз даје исте одговоре.