detecting in-flight page changes with web tripwires
DESCRIPTION
Detecting In-Flight Page Changes with Web Tripwires. Avagy hogyan észleljük weblapokon az „utazás” közben történt változásokat…. - PowerPoint PPT PresentationTRANSCRIPT
Detecting In-Flight Page Changes with Web Tripwires
Avagy hogyan észleljük weblapokon az „utazás” közben történt változásokat…
Source: same titled article by Charles Reis (University of Washington), Steven D. Gribble (University of Washington), Tadayoshi Kohno (University of Washington), Nicholas C. Weaver (International Computer Science Institute)
Kitérő : Tripwire
Linux Adatintegritás ellenőrző Digitális ujjlenyomat a könyvtárakról/fájlokról Adatbázisba kerül Így kiszűrhetőek a nem kívánt változások
Bevezetés: In Flight Changes
HTTP: van lehetőség az oldal módosítására utazás közben
Általános gondolkodás: általában nincs változtatás
EZ TÉVEDÉS A cikk íróinak szerverén 50.000 IP esetén:
1,3%-nál történt változás
Bevezetés: miért vizsgáljuk
Sokféle típusú módosítást észleltek pl Internetszolgáltatók (ISP): reklámok beszúrása Végfelhasználók: reklámok, popup-ok eltávolítása Malware készítők: férgek terjesztése
Ezek közül sok nemkívánatos a felhasználónak vagy a kiadónak Reklámok ki/be: a kiadó bevételei, bosszantja a
felhasználót SŐT: hibák, sebezhetőségek beszúrása sok
biztonságos és hibamentes oldalba
Bevezetés: miért vizsgáljuk, HTTPS
Az esetleges negatív következmények miatt Észlelni, és figyelmeztetni a felhasználót megakadályozni De nem minden változás nem kívánt: céges proxik
a privacy védelme, biztonság növelése miatt HTTPS
Kódolás miatt erős megoldás DE A HTTPS végpontok tudnak változtatni költséges: és megakadályozza az előnyös
változtatásokat: cache, tömörítés, …
Bevezetés: web tripwires Ezért a kiadóknak érdemes alkalmazni a ~
Kliens oldali JavaScript a változások észlelésére Nem 100% észlelés, biztonság DE a gyakorlatban :
Kisebb költségű mint a HTTPS Nem kell a böngészőkön változtatni Sokféle stratégiát támogat
Továbbiakban Mérési tanulmány ~ implementációs stratégiák hatékonyság
Mérések
Elvárás volt: a felhasználók változás nélkül kapják amit a kiadó nekik szánt
Ez nincs mindig így: kérdés mennyire Egy html oldalt terveztek, ami képes figyelni a
változtatásokat Kérdések
Milyen típusú változások milyen gyakran történnek? Van-e ezeknek előre nem látható következményük?
Eredmény: 50000 IP: >1%, sok negatív következmény
Mérések: böngésző kiterjesztések
A kiterjesztések általi változásokat nem figyelték, hiszen azok a felhasználó tudtával tevékenykednek (gyakorlatilag azok nem is a html kódon, hanem a már a böngésző belső reprezentációján dolgoznak)
Mérések: Technológia 1
A használt „web tripwire” egy JavaScript kód Ami az oldal betöltésekor fut le Minden érzékelt változásról riportot küld a
szervernek, és tájékoztatja a felhasználót. Képes megjeleníteni az elvárt és a kapott tartalom
eltéréseit Információt gyűjt a környezetéről
Mérések: Technológia 2
Két megjegyzés Előfordulhattak hamis negatívok (volt változás, de
nem láttuk), ha csak olyan oldalon változtatottak, ami nem tartalmazza a scriptet)
Ez a technológia nem titkosított, úgyhogy a reklámozó ügynök ha akarta eltávolíthatta, befolyásolhatta a scriptet, ám nem valószínű hogy széles körben ilyen beavatkozások történtek volna.
Mérések: realitás A mérési oldalnak valóságszerűek kellet lenni
Html-tagok web-authoring programból, véletlen szöveg és kulcsszavak linkekkel
különböző TLD-s * használata Internetszolgáltatók: beszúrt reklámok NebuAd ennek csak a .com TLD-kre van hatása
A mérés közben felvett új Hátha „white-list”-ra kerül
Tapasztalat A legtöbb változás válogatás nélkül Néhány NebuAd .com specifikus Más NebuAd több TLD-re (ismeretlen minta)
Mérési eredményekKategória IPs I E
U
A
Példák
Popup blokkoló
277 x Zone Alarm (210), CA Personal Firewall (17), Sunbelt Popup Killer (12)
Hirdetés blokkoló
188 x Ad Muncher (99) , Privoxy (58), Proxomitron (25)
Problem in Transit
30 x Blank Page (107), Incomplete Page (7)
Tömörítés 30 x bmi.js (23) , Newlines removed (6), Distillation (1)
Security or Privacy
17 x x Blue Coat (15), The Cloak (1) , AnchorFree (1)
Ad Injector 16 x MetroFi (6), FairEagle (5), LokBox (1), Front Porch (1), PerfTech (1), Edge Technologies (1), knects.net (1)
Meta Tag Changes
12 x x Removed meta tags (8), Reformatted meta tags (4)
Malware 3 x W32.Arpiframe (2), Adware.LinkMaker (1)
Egyéb 3 x New background color (1), Mark of the Web (1)
Mérési eredmények: elemzés
Tehát meglehetősen színes képet láthatunk A internetszolgáltatók, a vállalatok, a felhasználó,
a támadók mind végeznek módosításokat Ezen változások gyakran szemben álnak a
felhasználói és a kiadói célokkal Kiadó: tartalom nyújtása a felhasználóknak, esetleg
egy bevétel forrással a reklámokból Felhasználó: biztonságos tartalom kevés bosszantó
dologgal
Mérés elemzése: Internet szolgáltatók Két fő ok a módosításra
Bevétel generálás reklámokkal Forgalomcsökkentés tömörítéssel
A beszúrt reklámok bosszantják a felhasználókat Partner cégek
reklámok beszúrására (pl 5 ip: NebuAd szerveréről beszúrt kód) Sok közülük állítja: felhasználói szokásokon alapul Privacy sérülése: web-tripwire: látják mi az egyedi reklám, ez
alapján: hol járt a legutóbb a felhasználó Forgalomcsökkentés
Whitespace-k eltávolítása, image-distillation, de hibákat okozhatnak
Mérés elemzése: vállalatok
Okok Forgalom csökkentés Ügyfelek védelme
Megfigyelések Metatagok eltávolítása, hogy a kiadó akarata
ellenére a cache-lés engedélyezve legyen Blue Coat WebFilter: vállalati proxy a
rosszindulatú forgalom ellen
Mérés elemzése: Végfelhasználók 1
Okok (rengeteg ok): Popup / ad blockers Biztonság teljesítmény
A felhasználó által telepített program végzi Popup blokkolók
Érdekes: nem csak popup blokkolok, de tűzfalak is Általában beszúrt JavaScript kód, window.open-re
közbelép
Mérés elemzése: Végfelhasználók 2
Ad blokkolók Egyre népszerűbbek, de a mérési oldal nem
tartalmazott reklámokat, így nem jelent meg De észleltek ad blocking proky-kat a beszúrt JS-ből
Biztonság növelése, hatékonyság AnchorFree Hotspot Shield: Wifi-n védi a felhasználót IE: támadások ellen a mentett fájlba „Mark on web”
komment Anonymization servuces: pl The Cloak Proxy-k amik eltávolítják a cache tiltó metatag-ot és
cache-lik az oldalt
Mérés elemzése: Malware szerzők
Okok Rosszindulatú kódok terjesztése (malware) Bevétel beszúrt reklámokból (adware)
Pl: Adware.LinkMaker (1 kliens volt fertőzött) Változások: kétszer aláhúzott szavak - mouseover: ad
frame W32.Arpiframe féreg (2 kliens esetén)
Lehet hogy a kliens maga nem fertőzött Ez a féreg LAN-on terjed ARP cache mérgezéssel „Man-in-the-middle”
Mérések: nem várt problémák
A fenti változások valamely fél érdekein alapult
De sok közülük súlyos következménnyel járhat: Sérült funkcionalitás sebezhetőségek
Problémák: oldal hibák Kétféle típust figyeltünk meg:
A beszúrt JS a tripwire-val együtt IE verem túlcsordulás okozott Pl: xpopup.js a CA Personal Firewall popup blokkolója Pl: bmi.js tömörítő script Néha megakadályozva a tripwire jelentését Többféle script, egyazon névtér tesz nélkül =>
A CA Personal Firewall által beszúrt kód sok helyen interferál a blogbejegyzések kommentek elküldésével A beszúrt kód megjelent a kommentben…
Sebezhetőségek : Ad blocking Sok beszúrt tartalom sebezhetően hagyta az oldalt
a xss-el szemben (xss: pl egy form-ba JS kódot írva az lefutattható)
Ad blocking sebezhetőségek 2 free, 1 kereskedelmi ad blocker esetén Ezek beszúrják az oldalba JS kommentként az URL-t:
// Original URL: http://www.google.com De ha
http://google.com/?</script><script>alert(1); A sebezhetőség kihasználása
Bank login formja (HTTP, csak a válasz HTTPS) Google keresési formja
Sebezhetőségek: IE
A lementett oldalakba hasonlóan beszúr „Mark on web”
Kevésbé súlyos Csak lemezről való beöltéskor futhat Így nem fér hozzá a szerverhez vagy cookie-khoz
Sebezhetőségek: The Cloak Névtelenség
Lekéri a weblapot a felhasználó nevében Sok tagot eltávolít/átír (ne szivárogjon ki adat)
Akár az összes JS (*)
Két féle xss sebezhetőség Megmagyarázza miért távolított el valamit:
<!-- the-cloak note - deleting possibly dangerous META tag - unknown NAME ’generatorversion’ -->
DE: <meta name="foo--><script>alert(1);</script>"> [*kikerüli] Böngészők „Same origin policy” :
Minden oldal a cloak.com-ról oldalak hozzáférhetnek egymás adataihoz!!!
Motiváció
Láttuk hogy a beszúrt kódoknak sok negatív következménye lehet.
HTTPS egy megoldás, de kizárja Proxy-k általi cache Image distillation (kép „tömörítése”) Biztonsági ellenőrzések vállalati proxy-k által
De kell Kulcs csere CPU overhead a szerveren
Célok Észlelje az „utazás” közben történt változásokat
(kivéve a böngésző bővítmények által történteket) Megakadályozzon bizonyos változásokat
Nehéz kódolás nélkül, de nem mindenhol igény Mind a felhasználó, és a kiadó felé jelezze, és
segítsen megérteni a változás okát Ne zavarja a funkcionalitást és a teljesítményt
Oldal szemantikája Back gomb
Implementációs stratégiákCount Scripts
Check DOM
XHR then Overwrite
XHR then Redirect
XHR on Self
HTTPS
Detects all HTML changes
* * * * *
Prevents changes * *
Displays difference
* * *
Preserves semantics
* * * * *
Renders incrementally
* * * *
Supports back button
* * * *
Tervezés és implementáció
Több stratégia lehetséges Itt JS alapú implementáció Mindegyik azonos megközelítéssel
A szerveren 3 elem van A kért oldal, a tripwire script, és egy „jó változat”
A jó változat cheksum, vagy kódolt string Ha a böngésző megkapja mindhármat
Minden implementációnál: a szerver tudja a tervezett tartalmat Dinamikus oldalak? Más szerver? (cache, ???)
Count Scrips Megszámolja a <script> tagokat A mérések alapján a módosítások 90%-át
észleli A „jó változat” itt a scriptek száma Hátrányok
Ha nem script beszúrás történt nem érzékeli Nem egyszerű megmondani melyik az új script
Előnyök Egyszerű Nem interferál az oldallal
Check DOM Jó lenne a teljes tartalmak összehasonlítása
De egy JS nem fér hozzá a kapott html-hez Csak a DOM-fához document.documentElement.innerHTML
De ez az ábrázolás böngésző/verzió függő A szerveren előre kell az összeshez a „jó változat” Ez a technika a gyakorlatban megvalósíthatatlan Hisz még a felhasználó pontos azonosítása sem biztos Azaz az összes változatott el kéne küldeni
Mi egy cheksum listát használtunk Így lehetetlen a pontos változások megállapítása
XHR
A böngészők belső html reprezentáció ellenőrzése:
Kapja a felhasználó adatként az oldalt: XMLHttpRequest Tripwire is megkapja a teljes oldalt A kérés megkülönböztethetetlen a weboldal kérelmektől A böngésző bővítmények nem nyúlnak hozzá
XHR then Overwrite Működés
Kis indító oldal (tripwire & „jó változat”) Utána lekérni kért oldalt A tripwire érzékeli a változásokat, és a document.write felülírja az
indító oldalt Előny
Megakadályozza a változtatást Nem biztonságos: Az indító oldal felülírható
Hátrány Render: egyszerre lehet csak betölteni Firefox esetén a document.write ütközik a vissza gombbal IE és Safari: document.write bugok (Safari: cookie, IE üres srciptre
fagy)
XHR then Redirect
A document.write hátrányait el kell kerülni A felülírás helyett átirányítjuk a kért lapra
A lap cacheable Így a böngésző az XHR által a cache-be került
változatot tölti be (nem kéri el újra a szervertől) Hátrány
Betöltés Már nincs meg a megelőzési lehetőség Vissza gomb
XHR on Self Működés
Először elküldjük a kért oldalt (Render OK) Majd a kért oldal kéri a külső tripwire scriptet (benne a „jó változat”
string kódolva) A script ezután XHR-el kéri el újra a kért oldalt (mivel a lap
cacheable, így a cache-ből kapja) Hátrány
Nehéz lenne a változásokat megelőzni (a tripwire előtt futó JS…) Előny
A legtöbb célnak megfelel (változások szűrése, különbségek, szemantika, fokozatos betöltés, vissza gomb)
HTTPS A fenti technikák vs https
A célok kissé eltérnek https a felhasználók számára bizalmasság és sértetlenség a szervernek nem ad információt ezek tejlesüléséről
HTTPS erősebb biztonsági garanciákat ad Kódólás (képek és bináris adatok is) visszautasít bármilyen megváltoztatott tartalmat
Biztosítva van a fokozatos betöltés, szemantika Azonban drága A tripwire-k több döntési lehetőségeket adnak
4. Értékelés, hatékonyság
Érdemes-e web tripwire használata?Megfizethető-e a sima HTTP-vel szemben?A HTTPS-hez képest a költségei?Mennyire megbízható?
Értékelés Az összehasonlítás
Latecy (késés) Throughput (áteresztő képesség)
4 változata egy főbb bank honlapjának HTTP Web-tripwire (XHR on Self) Web-tripwire (XHR on Self) ami riportot készít a módosítást HTTPS
3Ghz Xeon, Apache 2, Fedora Core 6 (nincs hardveres SSL gyorsítás)
Latency mérése
Mérési módszer Kis, oldalba ágyazott scriptek start latency: első script lefut end latency: onload esemény (a betöltés végén) Az átvitt bájtok mérése
Firefox, szimulált 2Mbps sávszélesség 50 ms egyirányú link latency
5 mérés (a maximális relatív hiba 3,25%)
Eredmény
start latency Nem nőtt 240 ms SSL-nél a kapcsolódás miatt 840 ms
Betöltési idő Hosszabb a tripwire számításai miatt A riport készítőnél még hosszabb (összes
különbség kiszámítása) Teljes latency
Még így is a HTTPS oldal alatti
Átvitt bájtokTechnika Data Transferred
Original 226.6 KB
Web Tripwire 265.8 KB
Web Tripwire (tripped) 266.0 KB
HTTPS 230.6 KB
A web-tripwire 17,3%-al növelte az átvitt adatmennyiséget Ez a html kód teljes kódolt változata (ami kis %-a az egyéb
beágyazott tartalmaknak) A jövő tripwire-i akár ellenőrizhetik a teljes átvitt tartalmat
Esetleg, csökkenthető az overhead cheksum-okkal
Throughput
Két Feadora Core 6 kliens, 1Gbps hálózat, elhanyagolható latency,
Mindig növelve a terhelést, sessionok számának hosszantartó tetőzésig
A web-tripwire csak 4% visszaesést okozott
HTTPS az SSL kézfogások miatt CPU terhelés
Módosítók kezelése 1 A módosítók
nem feltétlen akarják hogy észleljék a változást hirdetések, beszúrása, rosszindulatú kódok
A végfelhasználó elrejtené a kiadóktól, hogy milyen proxy-kat használ
(ad-blockers) A web-tripwire-k nem érzékelnek mindent
Pl: a teljes oldal cseréje Így ez a technika nem véd azoktól, akik minden
áron rosszindulatú tartalmat akarnak adni
Módosítók kezelése 2 Inkább az a modell
A módosítók meg akarják őrizni a funkcionalitást Közben vezet be változásokat Azaz képes megfigyelni késleltetni és önkényesen
módosítani a csomagokat Azaz a felhasználóban van valami elvárás a tartalomra
Itt a web-tripwire-k hatékony módszer lehet A módosítóknak meg kell találni, és letiltani őket
De a kiadók a kód összekeverésével, több változatával, a „jó változat” reprezentációnak változtatásával védekezhetnek.
Vagy egyéb funkcionalitási JS-ekkel való integrálás.
Módosítók kezelése 3 Azaz kialakulhat egy verseny a kiadók és a
mosósítók között, amelyben a fenti technikák segíthetik a kiadókat
Habár ahol kritikus kérdés az integritás HTTPS-re lehet szükség
Saját tapasztalat 1
A washingtoni egyetem kutatói a tanulmány mellé, egy web-tripwire toolkit-et is készített: http://www.cs.washington.edu/research/security/webtripwires.html
A XHR on Self stratégiát követi A JavaScriptet egy CGI állítja elő. Két mód:
Dinamikus: minden kéréskor CGI előállítja a scriptet (benne kódolva az oldal „jó változat”-a)
Statikus: adott oldalakhoz a CGI-vel előre legenerált JavaScripteket használunk
Saját tapasztalat 2 A letöltött zip tartalmaz minden fájlt. A védendő oldal mellé fel kell másolni a szerverre:
webtripwire.css, webtripwire.gif, webtripwire-submit.cgi
Dinamikus: <script type="text/javascript" src="webtripwire.cgi?page=OLDALNEV"></script>
a html mellé a webtripwire.cgi Statikus:
<script type="text/javascript" src="webtripwire-OLDALNEV.js"></script> Futtasd: ./webtripwire.cgi "page=OLDALNEV.htm" > webtripwire-
OLDALNEV.js Töröld ki a script első két sorát (karakter kódolási direktívát)
A html mellé webtripwire-OLDALNEV.js (script+kódolt változat)
Saját tapasztalat
http://marcy.web.elte.hu/test/webtripwires.htm Próbálkoztam a washingtoni egyetem
példaoldalával, de nem történt változás utazás közben.
Ezért eme oldalhoz a statikus módon legeneráltattam a js-t (benne a kódolt „jó változat”-tal), majd szándékosan változtattam a kódon. Így szimulálva az út közben történt változást, és: