Üks turvaspetsialisti eeliseid on paljude meeskondadega töötamine. Pärast auditit on turvaspetsialistidel võimalus teha koostööd andmebaaside administraatorite ja analüütikutega. Et rakendus töötaks korralikult ja turvaliselt, püüavad need meeskonnad tegeleda turvaaukudega, millel on ühine alus. Nende meeskondade vahelised dialoogid tõstatavad mõningaid probleeme tegeliku IP-ga.
Puhverserver ja tegelik IP-kontseptsioonid
Tänapäeva veebirakendused töötavad mitmes rakenduseserveris ja andmebaasisüsteemis. Kujutage ette, et kaks rakendusserverit jagavad sama lähtekoodi. Kasutaja taotlused on olenevalt laadimisolukorrast valmis täitma kumbki neist serveritest. Koormuse tasakaalustamise mehhanism, mis käsitleb HTTP-päringuid rakendusserverite ees, otsustab, milline päring millisele rakenduseserverile edastada. See seab vahevara süsteemiadministraatoritele ja tarkvaraarendajatele suure küsimuse: mis on kasutaja tegelik IP-aadress?
Puhverserverid vastutavad andmete edastamise eest kahe süsteemi vahel. Koormuse tasakaalustaja on puhverserveri eest vastutav mehhanism. Teisisõnu, ainult üks süsteem suhtleb nii kasutaja kui ka rakendusserveriga. Võrguliikluse osas suhtlevad veebi A või veebi B serverid alati koormuse tasakaalustaja IP-aadressiga. Sama võib öelda ka kasutajate kohta. Turvaspetsialistidele põhjustavad koormuse tasakaalustajad ajapõhistes SQL-i süstimisrünnetes tõsiseid probleeme. Kuid siin on põhirõhk IP-võltsimisel.
X-Forwarded-For ja IP-suhe
Mõelge X-Forwarded-Fori, arendaja ja vahevara seostele. Näiteks oletame, et rakenduse arendaja ülesanne on salvestada kõik tegevused, näiteks kasutajate ebaõiged paroolikatsed, oma IP-aadressidega. Alguses määrab arendaja kasutaja IP-aadressi, kui HTTP-päring on täidetud tema kasutatava programmeerimiskeele pakutav võimalus ja proovib jätkata nende andmete kasutamist rakendus.
Kuna selle IP-aadress fikseeritakse kogu arendusprotsessi vältel, näeb see testide ajal alati sama aadressi, kuna üldiselt on ettevõtte võrgud töötavad staatilise IP-ga üle MAC-aadressi. Üksus viib läbi mõned vastuvõtutestid; nendega tuleb aga probleeme. Testimisüksus edastab selle probleemi tarkvaraarendajale.
Selles etapis võib arendaja kirjutada arenduskeskkonda kontrolleri ja näha rakendusele edastatud HTTP-päringut töötlemata kujul, kuna kõigil on sama IP-aadress. Selle tulemuseks on töö X-Forwarded-Foriga.
Päise teave nimega X-Forwarded-For saadetakse rakendusserverisse. Selles etapis näeb tarkvaraarendaja oma IP-aadressi, mida ta juhib ipconfigiga, mitte logides kuvatavat koormuse tasakaalustajat. Paljud programmeerijad arvavad, et nad saavad selle probleemi lahendada sellise koodiplokiga:
funktsioonihanki IP-aadress() {
$ipKeys = massiivi(
„HTTP_CLIENT_IP”,
„HTTP_X_FORWARDED_FOR”,
„HTTP_X_FORWARDED”,
„HTTP_X_CLUSTER_CLIENT_IP”,
„HTTP_FORWARDED_FOR”, „HTTP_FORWARDED”,
„REMOTE_ADDR”
);
igaühele ($ipKeys nagu $key) {
kui (massiivi_võti on olemas($key, $_SERVER) tõsi) {
igaühele (plahvatada (',', $_SERVER[$key]) nagu $ip) {
$ip = trimmi($ip);
kui (validate_ip($ip)) {
tagasi $ip;
}
}
}
}
tagasiisset($_SERVER[„REMOTE_ADDR”])? $_SERVER[„REMOTE_ADDR”]: vale;
}
Sellest ei piisa – arendaja peab kontrollima, kas sissetulev väärtus on kehtiv IP-aadress.
Kõik ülaltoodud kuulus arendaja hallatava osa juurde. Kuid selleks, et rakendus töötaks korralikult ja turvaliselt, töötavad meeskonnad – teoreetiliselt koos, kuid sees reaalsus, äärmuslikes punktides üksteisest – proovige tegeleda turvaaukudega, millel on a ühine alus. Nüüd proovige vaadata probleemi koormuse tasakaalustaja konfigureerimise eest vastutava isiku vaatenurgast.
Süsteemiadministraatorid võivad arvata, et arendajad salvestavad teavet, näiteks X-Forwarded-For, kuna HTTP-päringu andmeid ei saa usaldada. Need administraatorid edastavad sageli X-Forwarded-For; kuid nad edastavad teise päise väärtusena ka päringu saatnud süsteemi TCP lähteaadressi. True-Client-IP struktuur on selle hea näide.
Kui panete kõik need asjad kokku, järgivad kaks erinevat üksust sama probleemi lahendamiseks erinevat teed, mida nimetatakse kliendi IP võltsimiseks. Tulemuseks on kriitiline probleem, kus IP logimine ja IP-põhine autoriseerimine ei tööta.
Kuidas tuvastatakse läbitungimistestides kliendi IP-võltsimist?
Enamik läbitungimistestijaid kasutab turvakontrolliks Firefoxi. Nad konfigureerivad Firefoxi kõigi HTTP-päringute jaoks lihtsa lisandmooduliga X-Forwarded-For: 127.0.0.1. Seega suureneb selliste haavatavuste tuvastamise võimalus kõigis läbitungimistestides. Auditi läbiviimine vastavalt OWASP kontrollnimekiri tagab selliste haavatavuste kontrollimise. X-Forwarded-For haavatavuse tuvastamiseks vajate aga rakenduses moodulit, mis näitab teie IP-aadressi või tehtud toiminguid.
Kuidas lahendada haavatavus X-Forwarded-For
Organisatsioonid vajavad kohustuslikku turvalist rakenduste arendusdokumenti kõikidele tarkvarameeskondadele ja allhankefirmadele. Näiteks kui vajate kasutaja IP-aadressi, peaks ettevõte ette planeerima ja kehtestama siin kasutatava päise teabe reegli. Vastasel juhul toodavad erinevad meeskonnad erinevaid lahendusi. Kui sellist olukorda ei suudeta lahendada, tulevad mängu rakenduste sisseostmine, mis muudab lähtekoodide mõõtmise keeruliseks. Üldjuhul ettevõtted sellist teed minna ei taha.
Kuid selle probleemi lahendamiseks võite kasutada järgmist F5 reeglit:
kui HTTP_REQUEST {
HTTP:: päise eemaldamine X-Forwarded-Sest
HTTP:: päise sisestamine X-Forwarded-Sest [IP:: remote_addr]
}
See eemaldab välismaailmast HTTP päringu välja X-Forwarded-For. Seejärel edastab ta päringu, lisades sellele päringu saatnud süsteemi IP-aadressi. Nii luuakse usaldusväärne loend tarkvarale, mis toimib X-Forwarded-Fori järgi.
Kokkuvõtteks võib öelda, et suurim eesmärk on siin HTTP-päringute kontrollimine ja usaldusväärse keskkonna loomine. Ülaltoodud koodiplokk on hea näide, mida saate selleks kasutada.
Küberturvalisuse raamistikud ja dokumentatsioon ettevõtetele
Üksteisest sõltumatud üksused on tegelikult osad tervikust. Seetõttu peabki kõik süsteemselt toimima. Iga üksuse vahel tuleb kohaldada eelnevalt kindlaks määratud reegleid. Kui sellist töötavat süsteemi vastu ei võeta, võib ilmneda palju probleeme, näiteks haavatavus X-Forwarded-For. Selleks tuleks kõik eelnevalt läbi mõelda ja kasutada võimalikult põhjalikku dokumentatsiooni.
Ja iga üksus selles suures süsteemis peab vastu võtma ja rakendama küberturvalisuse raamistikke. Teie lähtepunkt peaks olema nende raamistike tööloogika uurimine ja õppimine.
