Преместувањето на административниот интерфејс на admin.example.com е вистинско подобрување: ги држи административните колачиња подалеку од јавните страници, им дава на двете апликации одделни кешови и ви овозможува да насочите построга мрежна политика кон едно име на домаќин. Но тоа не е контрола на CSRF и не го прави кодот на јавниот сајт безбеден за оставање отворен пред најавен администратор. Одвојувањето го менува она што прелистувачот го смета за граница, а не она што серверот го проверува, затоа направете ги овие четири проверки пред да кажете дека е готово.

Читајте origin и сајт како два различни збора

Origin е шема, домаќин и порта, па https://www.example.com и https://admin.example.com се различни origin. Сајт во смисла на SameSite е шема плус регистрирана домен, па тие две имиња на домаќин се обично истиот сајт. Таа разлика е целата стапица: атрибутот SameSite нема да ви помогне меѓу сестрински поддомени, бидејќи прелистувачот барањето воопшто не го смета за меѓусајтско. Насочете го административниот интерфејс кон навистина друг регистриран домен, како admin-example.net, и барањето навистина станува меѓусајтско, и токму таму SameSite=Lax или Strict почнува да работи работа на која може да се потпрете.

Тестирајте го во прелистувачот наместо да расудувате за него.

Вчитајте го јавниот сајт, отворете ги алатките за развивачи и погледнете кои колачиња прелистувачот ги прикачува на барање кон административниот домаќин. Ако колачињато нема атрибут Domain, тоа е само за домаќинот и останува на своето име; ако носи Domain=example.com, патува кон секоја сестра, и новиот поддомен не ви даде ништо за тоа колаче.

Одвојте читање на одговорот од испраќање на барањето

Политиката на ист origin го ограничува читањето одговори меѓу origin. Таа не спречува барање да биде испратено и не спречува форма да носи акредитиви што прелистувачот веќе ги има. Едноставно барање, со тип на содржина на форма или обичен GET, се доставува без претходна проверка; потоа CORS одлучува дали скриптата што повикува смее да го чита одговорот. CSRF живее целосно на страната на испраќањето.

Затоа на серверот му треба изречна проверка за операции што го менуваат состојбата. Токен за синхронизација врзан за сесијата, или колаче со двојно испраќање што се споредува на серверот, го покрива случајот; споредбата на Origin или Referer вреди да се додаде како втора порта, но не како единствена, бидејќи не секое барање го носи заглавието и не секој прокси го чува. Упатството на OWASP за спречување CSRF го смета SameSite за еден слој меѓу неколку токму поради оваа причина.

Одлучете што мрежната порта навистина докажува

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

Држете го независно од проверките на ниво на барање. Ако списокот е единственото нешто меѓу напаѓач и крајна точка што менува состојба, една погрешно конфигурирана рута, еден split-tunnel клиент или еден позајмен преносен сметач целосно ја отстранува контролата.

Запишувајте ги и одбивањата надвор од очекуваните опсези. Нивниот налет е најкорисниот сигнал дека некој ја испитува границата што штотуку ја изградивте, а тишината е сигнал дека филтерот воопшто не се достигнува.

Држете ги колачињата, најавувањето и авторизацијата изречни

Опсегот на колачето одлучува најголем дел од резултатот. Колаче на родителскиот домен се испраќа до административниот домаќин, па вметнување скрипта на јавниот сајт може да дејствува со сесијата на администратор; колаче само за домаќинот не може. Преферирајте ја формата само за домаќинот, додадете го атрибутот Secure и користете го префиксот __Host- каде платформата го поддржува, бидејќи тој префикс бара Secure, Path=/ и без атрибут Domain. Читајте го заглавието на одговорот, не теглата со колачиња: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, без атрибут Domain. Прелистувачот фрла __Host- колаче што носи Domain, па колаче што сè уште се гледа на сестрински домаќини е доказ дека префиксот никогаш не бил применет.

Потоа држете ја авторизацијата на серверот, за секое барање, на секоја административна крајна точка, не само при најавување. Барање од дозволена мрежа сè уште мора да биде автентифицирано и авторизирано за операцијата што ја бара; името на домаќинот не е актер. Ако јавната и административната апликација делат тек на најавување или складиште на сесии, запишете ја таа врска, бидејќи тоа е најкраткиот пат од грешка на јавниот сајт до административна акција.

Проверете ја границата повторно по одвојувањето

Извршете ги негативните тестови, не само среќниот пат: форма меѓусајтски без токен мора да биде одбиена, токен од друга сесија мора да биде одбиен и ниту еден GET не смее да ја смени состојбата. Проверете ги атрибутите на колачињата во алатките за развивачи, потврдете дека проверката на Origin се активира на несоодветно барање и пробајте го административниот домаќин од надвор од опсегот на VPN за да го видите филтерот во дејство.

Ништо од ова не отстранува XSS дефект внатре во самата административна апликација. Одделното име на домаќин е граница на изолација на страната на прелистувачот со вистинска вредност и не е замена за спречување небезбедно извршување код или за заштита на барања на страната на серверот. По одвојувањето списокот е пократок отколку што изгледа: различен origin, колачиња само за домаќинот, токен при секоја промена, влезен филтер на кој не му верувате како идентитет и авторизација одлучена за секое барање.

Поврзани статии