Előadást letölteni
Az előadás letöltése folymat van. Kérjük, várjon
KiadtaLili Székelyné Megváltozta több, mint 9 éve
1
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)
2
1. Bevezetés
3
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
4
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
5
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
6
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, …
7
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
8
2. Mérési tanulmány
9
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
10
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)
11
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
12
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.
13
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)
14
Mérési eredmények A reprezentatív rálátás miatt többféle helyzetű látogatóra volt szükség Végül a Slahdot news, és Digg honlapjának címlapján gyűjtötték az adatokat. 50.171 egyedi IP, ebből 657 esetben történt módosítás 70%-a kliens oldali proxik (popup blokkolók, …) 46 esetben az internetszolgáltató végzett módosítást 125 cím proxy-ja volt sebezhető a cross-site scripting támadásokra 3 cím érintve volt kliens alalpú malware-kal
15
Mérési eredmények KategóriaIPsIE U A Példák Popup blokkoló 277xZone Alarm (210), CA Personal Firewall (17), Sunbelt Popup Killer (12) Hirdetés blokkoló 188xAd Muncher (99), Privoxy (58), Proxomitron (25) Problem in Transit 30xBlank Page (107), Incomplete Page (7) Tömörítés30xbmi.js (23), Newlines removed (6), Distillation (1) Security or Privacy 17xxBlue Coat (15), The Cloak (1), AnchorFree (1) Ad Injector16xMetroFi (6), FairEagle (5), LokBox (1), Front Porch (1), PerfTech (1), Edge Technologies (1), knects.net (1) Meta Tag Changes 12xxRemoved meta tags (8), Reformatted meta tags (4) Malware3xW32.Arpiframe (2), Adware.LinkMaker (1) Egyéb3xNew background color (1), Mark of the Web (1)
16
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
17
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
18
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
19
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
20
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
21
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”
22
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
23
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…
24
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/? alert(1); A sebezhetőség kihasználása Bank login formja (HTTP, csak a válasz HTTPS) Google keresési formja
25
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
26
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: DE: alert(1); "> [*kikerüli] Böngészők „Same origin policy” : Minden oldal a cloak.com-ról oldalak hozzáférhetnek egymás adataihoz!!!
27
3. Web Tripwires implementációs stratégiák
28
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
29
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
30
Implementációs stratégiák Count 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 ****
31
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, ???)
32
Count Scrips Megszámolja a 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
33
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
34
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á
35
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)
36
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
37
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)
38
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
39
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ó?
40
É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)
41
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%)
42
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
43
Átvitt bájtok TechnikaData Transferred Original226.6 KB Web Tripwire265.8 KB Web Tripwire (tripped)266.0 KB HTTPS230.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
44
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
45
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
46
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.
47
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
48
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 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
49
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: a html mellé a webtripwire.cgi Statikus: 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)
50
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:
Hasonló előadás
© 2024 SlidePlayer.hu Inc.
All rights reserved.