Привремене везе са листе дозвољених IP адреса: шта одобрење заиста пушта

Претварање једног клика у привремено правило заштитног зида је згодно, а истовремено гради систем ауторизације који одлучује ко може да дође до услуге. Он издаје адресу, а не особу, и та разлика је важна у тренутку када две особе деле један NAT. Ограничите обим одобрења, потврдите га свесно и дајте истеку смисао пре него што се веза изгради. Одлука пред вама је где поставити границу, а не да ли она уопште треба да постоји.

Одлучите на које питање одобрење одговара

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

Избор прихватања по адреси за апликацију окренуту корисницима премешта прави проблем ауторизације на друго место, а портал затим наслеђује кривицу за празнину коју никада није затворио.

Ограничите захтев на серверу

Прегледач не сме да бира одредиште, порт или префикс. Портал разрешава услугу из сопствених записа и проверава право тестом на страни сервера, што је исти принцип који OWASP смернице за ауторизацију примењују на сваки захтев. Извођење адресе такође припада заштићеној граници: када обрнути прокси саопшти адресу клијента, прихватите само конфигурисани ланац проксија и његово документовано руковање заглављима. Заглавље прослеђивања које достави посетилац је тврдња о пореклу, а не доказ о њему.

Затим проверите да ли портал и услуга виде исти извор. Подељени тунел, један скок кроз прокси и IPv4 наспрам IPv6 могу да дају два одредишта две различите адресе, па одобрење активирано преко једног пута можда неће покрити следећи захтев.

Прикажите одобрење пре него што га инсталирате

Отварање везе треба да прикаже предложену услугу, запажени извор и трајање и да још ништа не мења. Тај један корак претвара везу из е-поште из радње у предлог и спречава бота за преглед или скенер поште да да приступ само тиме што ће је преузети.

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

Достава токена заслужује исту пажњу као и само правило. Истекла или већ потрошена веза која и даље ствара правило је друга врата постављена са истим кључем.

Адреса је заједничка и док је одобрење на снази

Канцеларијски NAT, NAT оператера и заједнички излаз VPN-а сваки стављају неколико људи иза једне адресе. Прихватање те адресе прихвата све који су иза ње — када је реч о следећој граници услуге —, а да притом ништа не доказује о томе чији је налог који услуга очекује.

Уклањање правила такође није универзално прекидање. Успостављене везе, кеширани токени апликација и дуготрајне сесије могу да надживе правило минутима или много дуже, па изабрани животни век треба да одражава шта услуга ради после прихватања, а не само колико правило постоји.

Тестирајте четири случаја и обе породице адреса

Одобрење вреди онолико колико четири случаја која преживљава: нови дозвољени захтев, неодобрени подносилац захтева, понављање исте везе и исти захтев после истека.

Затим тестирајте сваку породицу одвојено, јер се изворна адреса коју услуга запажа може разликовати међу њима.

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

Користан резултат је привремена, ревидирљива одлука о прихватању под уобичајеном корисничком ауторизацијом, а не трајно отварање које носи име онога који је први кликнуо.