Pretvaranje jednog klika u privremeno pravilo vatrozida prikladno je i ujedno gradi sustav autorizacije koji odlučuje kome je dopušteno dosegnuti uslugu. Ono izdaje adresu, a ne osobu, i ta razlika postaje važna onog trenutka kada dvije osobe dijele isti NAT. Odredite doseg dopuštenja, potvrdite ga svjesno i dajte isteku smisao prije nego što veza bude izgrađena. Odluka pred vama jest gdje postaviti granicu, a ne treba li ona uopće postojati.

Odredite na koje pitanje dopuštenje odgovara

Pođite od zahtjeva. Ako imenovana osoba mora dosegnuti uslugu, a aplikacija tu osobu već autentificira, autentificirani pristupnik zadržava identitet na mjestu provedbe i uopće ne treba dopuštanje adrese. Ako je cilj agent za izgradnju, administrativni skok-port ili uređaj koji ne može sudjelovati u prijavi korisnika, dopuštenje adrese ograničenog dosega može biti jedina praktična kontrola.

Odabir dopuštanja po adresi za aplikaciju okrenutu korisnicima premješta stvarni problem autorizacije negdje drugdje, a portal tada nasljeđuje krivnju za prazninu koju nikada nije zatvorio.

Ograničite zahtjev na poslužitelju

Preglednik ne smije birati odredište, port ni prefiks. Portal razrješava uslugu iz vlastitih zapisa i provjerava pravo poslužiteljskim testom, što je isto načelo koje OWASP-ove smjernice za autorizaciju primjenjuju na svaki zahtjev. Izvođenje adrese također pripada zaštićenoj granici: kada obrnuti proxy izvijesti adresu klijenta, prihvatite samo konfigurirani lanac proxyja i njegovo dokumentirano rukovanje zaglavljima. Zaglavlje prosljeđivanja koje dostavi posjetitelj tvrdnja je o podrijetlu, a ne dokaz o njemu.

Zatim provjerite vide li portal i usluga isti izvor. Podijeljeni tunel, jedan proxy skok i IPv4 nasuprot IPv6 mogu dvama odredištima dati dvije različite adrese, pa dopuštenje aktivirano jednim putem možda neće pokriti sljedeći zahtjev.

Pokažite dopuštenje prije ugradnje

Otvaranje veze treba prikazati predloženu uslugu, opaženi izvor i trajanje te još ništa ne mijenjati. Taj jedan korak pretvara vezu iz e-pošte iz radnje u prijedlog i sprječava bota za pregled ili skener pošte da dodijeli pristup tek time što će je dohvatiti.

Potvrda treba biti zahtjev koji mijenja stanje uz uobičajene obrane od međusmjeskih napada i podrijetla. Token treba biti jednokratan i atomski se trošiti u trenutku ugrađivanja pravila, a zapis treba zabilježiti vlasnika, uslugu, adresu, identifikator dopuštenja i istek, bez ikakvog bilježenja sirovog tokena.

Dostava tokena zaslužuje istu pažnju kao i samo pravilo. Istekla ili već iskorištena veza koja još proizvodi pravilo druga su vrata opremljena istim ključem.

Adresa je dijeljena i dok dopuštenje traje

Uredski NAT, operaterov NAT i dijeljeni izlaz VPN-a svaki stavlja nekoliko ljudi iza jedne adrese. Dopuštanje te adrese dopušta sve iza nje što se tiče sljedeće granice usluge, a pritom ne dokazuje ništa o tome kome pripada račun koji usluga očekuje.

Uklanjanje pravila također nije univerzalno prekidanje. Uspostavljene veze, predmemorirani tokeni aplikacija i dugotrajne sesije mogu nadživjeti pravilo minutama ili mnogo dulje, pa odabrani rok treba odražavati što usluga radi nakon dopuštanja, a ne samo koliko pravilo postoji.

Testirajte četiri slučaja i obje obitelji adresa

Dopuštenje je dobro koliko i četiri slučaja koja preživljava: novi dopušteni zahtjev, neodobreni podnositelj zahtjeva, ponavljanje iste veze i isti zahtjev nakon isteka.

Zatim testirajte svaku obitelj zasebno, jer se izvorna adresa koju usluga opaža može razlikovati među njima.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

Koristan ishod je privremena odluka o dopuštanju koja se može revidirati i koja stoji pod uobičajenom korisničkom autorizacijom, a ne trajno otvaranje koje nosi ime onoga koji je prvi kliknuo.

Povezani članci