Друг по сокету или прослеђено заглавље: ком адресу веровати?

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

Опишите путању пре него што било шта упоредите:

Client -> approved reverse proxy -> application origin

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

Две врсте доказа о адреси

Друг по сокету је чињеница о једној TCP вези: нешто је завршило руковање са те адресе. То није нужно човек, уређај или налог до ког вам је стало, јер VPN или Tor излаз могу законито бити извор који услуга посматра. Ипак, то је једина адреса коју је сам домаћин потврдио, и у томе је цела његова вредност.

Поље прослеђивања су метаподаци о ланцу. X-Forwarded-For, X-Real-IP и стандардизовано поље Forwarded може да напише сваки клијент који достигне крајњу тачку која их враћа, па њихова поузданост у потпуности зависи од тога коме је било дозвољено да их постави.

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

Заглавље никада не преусмерава везу

Уписивање адресе у поље прослеђивања не мења извор TCP везе која стиже на сервер и не мења рутирање нигде на путу. Обично VPN рутирање или изворни NAT доставља саобраћај без икаквог HTTP заглавља. Исто тако, транзитна капија не преписује исправно заштићену HTTPS размену без промене распореда TLS крајње тачке.

Обрнута грешка је исто тако честа: HTTPS не чини заглавље прослеђивања које је дао клијент истинитим. Оно штити пренос лажне тврдње једнако добро као и истините.

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

Именујте прокси коме је дозвољено да тврди

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

NGINX модул за стварну IP адресу јасно показује поделу. set_real_ip_from именује пошиљаоце чија се тврдња рачуна, и real_ip_header каже које поље је носи; прво обавља поверење, друго само каже где да се гледа.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

Сама директива за избор заглавља још увек ништа не утврђује о томе ко је послао вредност.

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

Свесно рукујте ланцима са више скокова

Неколико проксија захтева јасан модел ланца. Не узимајте најлеву или најдесну вредност одвојену зарезима само зато што је тако урадио неки блог пост; откријте који од ваших проксија додаје, који замењује и који чува долазно поље. NGINX, на пример, може да прође кроз листу уназад према свом скупу поверења и заустави се на првој адреси коју не поседује, и то је правило тог производа, а не закон који следи сваки оквир. Читајте документацију сопственог проксија са истим два питања: коју вредност бира и којим пошиљаоцима верује?

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

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

Држите оба запажања у дневнику

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

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