Едно от предимствата да си специалист по сигурността е работата с многобройни екипи. След одит специалистите по сигурността ще имат възможност да работят с администратори на бази данни и анализатори. За да работи приложението правилно и сигурно, тези екипи се опитват да се справят с уязвимостите в сигурността, които имат обща основа. Диалозите между тези екипи повдигат някои проблеми с реалния IP.
Концепции за прокси и истински IP
Днешните уеб приложения работят на множество сървъри на приложения и системи за бази данни. Представете си два сървъра за приложения, споделящи един и същ изходен код. Заявките от потребителя са готови да бъдат изпълнени от всеки от тези сървъри в зависимост от ситуацията на натоварване. Механизмът за балансиране на натоварването, който обработва HTTP заявки пред сървърите на приложения, решава коя заявка да препрати към кой сървър на приложения. Това поставя голям въпрос за системните администратори на междинен софтуер и разработчиците на софтуер: какъв е истинският IP адрес на потребителя?
Прокситата отговарят за предаването на данни между две системи. Балансиращото натоварване е механизмът, който отговаря за проксито. С други думи, само една система комуникира както с потребителя, така и със сървъра за приложения. По отношение на мрежовия трафик уеб A или уеб B сървърите винаги комуникират с IP адреса на балансиращото натоварване. Същото може да се каже и за потребителите. За професионалистите по сигурността балансьорите на натоварването причиняват сериозни проблеми при базирани на времето атаки с SQL инжектиране. Но на основният фокус тук е IP spoofing.
X-Forwarded-For и IP връзка
Помислете за връзката между X-Forwarded-For, разработчик и междинен софтуер. Например, да кажем, че задачата на разработчика на приложение е да записва всички дейности, като опити за неправилна парола от потребители, с техните IP адреси. Първо, разработчикът ще определи IP адреса на потребителя, когато HTTP заявката бъде изпълнена с възможност, предоставена от езика за програмиране, който използва, и ще се опита да продължи да използва тези данни в приложение.
Тъй като неговият IP адрес ще бъде фиксиран през целия процес на разработка, той винаги ще вижда един и същ адрес по време на тестовете, тъй като обикновено потребителските компютри в корпоративните мрежи работят със статичен IP през MAC адрес. Устройството ще извърши някои тестове за приемане; обаче ще има проблеми с тях. Тестовата единица ще препрати този проблем на разработчика на софтуера.
На този етап разработчикът може да напише контролер в средата за разработка и да види HTTP заявката, предадена на приложението в необработен вид, тъй като всеки има един и същ IP адрес. Това ще доведе до работа с X-Forwarded-For.
Информация за заглавката наречен X-Forwarded-For ще бъде изпратен до сървъра на приложения. На този етап разработчикът на софтуер ще види своя IP адрес, който контролира с ipconfig, а не балансиращото натоварване, което вижда в регистрационните файлове. Много програмисти смятат, че могат да решат този проблем с кодов блок като този:
функцияgetIPaddress() {
$ipKeys = масив(
„HTTP_CLIENT_IP“,
„HTTP_X_FORWARDED_FOR“,
„HTTP_X_ПРОПРАЩАНО“,
„HTTP_X_CLUSTER_CLIENT_IP“,
„HTTP_FORWARDED_FOR“, „HTTP_ПРЕДПРЕДАВАНО“,
„REMOTE_ADDR“
);
за всеки ($ipKeys като $ключ) {
ако (array_key_exists($key, $_SERVER) вярно) {
за всеки (експлодирам(',', $_SERVER[$key]) като $ip) {
$ip = подстригване($ip);
ако (validate_ip($ip)) {
връщане $ip;
}
}
}
}
връщанеисет($_SERVER[„REMOTE_ADDR“])? $_SERVER[„REMOTE_ADDR“]: невярно;
}
Това няма да е достатъчно — разработчикът трябва да провери дали входящата стойност е валиден IP адрес.
Всичко по-горе принадлежеше към частта, управлявана от разработчика. Но за да работи едно приложение правилно и сигурно, екипите – работят заедно на теория, но в реалност, в крайни точки една от друга – опитайте се да се справите с уязвимостите в сигурността, които имат a обща основа. Сега се опитайте да разгледате проблема от гледна точка на лицето, отговорно за конфигурацията на балансиращото натоварване.
Системните администратори може да си помислят, че разработчиците записват информация като X-Forwarded-For, защото на данните в HTTP заявката не може да се вярва. Тези администратори често предават X-Forwarded-For; но те също така предават TCP адреса на източника на системата, която е изпратила заявката, като втора стойност на заглавката. Структурата True-Client-IP е добър пример за това.
Когато съберете всички тези неща заедно, две различни единици следват различни пътища за един и същ проблем, известен като клиентски IP spoofing. Резултатът е критичен проблем, при който никакво IP регистриране и IP базирано оторизиране няма да работят.
Как се открива подправянето на IP на клиента при тестове за проникване?
Повечето тестери за проникване използват Firefox за своите проверки за сигурност. Те конфигурират Firefox с проста добавка, X-Forwarded-For: 127.0.0.1 за всички HTTP заявки. И така, възможността за откриване на такива уязвимости във всички тестове за проникване се увеличава. Извършване на ревизия съгл Контролен списък на OWASP гарантира, че проверявате за такива уязвимости. Въпреки това, за да откриете уязвимостта на X-Forwarded-For, имате нужда от модул в приложението, който показва вашия IP адрес или предприетите действия.
Как да разрешим уязвимостта на X-Forwarded-For
Организациите се нуждаят от задължителен защитен документ за разработка на приложения за всички софтуерни екипи и аутсорсинг компании. Например, ако се нуждаете от потребителски IP адрес, компанията трябва да планира предварително и да направи правило за информацията в заглавката, която ще използва тук. В противен случай различните екипи ще произвеждат различни решения. Ако подобна ситуация не може да бъде разрешена, приложенията за аутсорсинг ще влязат в действие, което затруднява измерването на изходните кодове. Като цяло компаниите не искат да следват такъв път.
Но за да разрешите този проблем, можете да използвате следното правило F5:
когато HTTP_REQUEST {
HTTP:: заглавка премахване на X-Forwarded-За
HTTP:: вмъкване на заглавка X-Forwarded-За [IP:: remote_addr]
}
Това премахва полето X-Forwarded-For в HTTP заявката от външния свят. След това предава заявката, като добавя IP адреса на системата, която е изпратила заявката до нея. По този начин се създава надежден списък за софтуер, който действа според X-Forwarded-For.
За да обобщим, най-голямата цел тук е да се извършат някои проверки на HTTP заявки и да се създаде надеждна среда. Кодовият блок по-горе е добър пример, който можете да използвате за това.
Рамки за киберсигурност и документация за предприятия
Единиците, които изглеждат независими една от друга, всъщност са части от едно цяло. Затова всичко трябва да работи системно. Правилата, определени предварително, трябва да се прилагат между всяка единица. Ако такава работеща система не бъде приета, могат да възникнат много проблеми като уязвимостта X-Forwarded-For. За това всичко трябва да се обмисли предварително и да се използва възможно най-изчерпателна документация.
И всяко звено в тази голяма система трябва да приеме и внедри рамки за киберсигурност. Вашата отправна точка трябва да бъде да проучите и научите логиката на работа на тези рамки.
