Intrångsdetektering i webbapplikationer

Will Robertson med flera på UCSB har forskat på intrångsdetektering (IDS) i webbapplikationer. Deras approach är anomalidetektering, dvs att man övervakar applikationen och söker efter onormalt beteende runtime. På det viset kan man upptäcka attacker.


Anomalidetektering bygger på att man har en komplett modell över korrekt beteende i applikationen. När applikationen körs så kollar man att användarna håller sig inom den modellen. Om de avviker så larmar man (detektering) eller stoppar anropet (prevention).

Att bygga modellen över korrekt beteende
Så hur bygger man en modell över korrekt beteende i en webbapplikation? UCSB-forskarna modellerar både inkommande och utgående HTTP-trafik men tittar inte på applikationskoden, så det är en black box-modellering.

Strängargument modelleras mha tre tekniker:

• Frekvensanalys av tecken. Så de blir språkberoende om strängargumenten är mänskligt språk.
• Sekvensanalys av tecken med HMM-induktion. Sekvensen av tecken modelleras mha Hidden Markov Model Induction som är stokastiska finita tillståndsautomater där övergångar mellan tillstånd och genererade utdata regleras av en statistisk fördelning. På lite mindre grekiska; sekvensen av tecken modelleras som en tillståndsgraf där sannolikheten för ett 'a' på plats 3 finns som utdata ur nod tre.
• Sekvensanalys av ord med n-gram-modeller.

De skapar också dokumentmodeller för (x)html, xml och json. Som ni förstår är det ett rätt omfattande arbete att modellera användande av en webbapplikation :).

Så hur får man testdata att skapa modeller med? Ja, antingen genom att köra sin enorma, kompletta testsvit (som man inte har) eller så skriver man ett NDA-kontrakt och spelar in riktiga användares beteende. UCSB gjorde det senare och byggde en modell utifrån ca 500.000 HTTP-request för en webbapp.

När modellen skapas måste trafiken vara komplett, dvs alla funktioner i webbappen måste användas (annars får man falsklarm) och vara fri från attacker (annars får man en modell som accepterar attacker som normalt beteende). Det är de två stora utmaningarna med att bygga modellen utifrån riktiga användardata.

Det blir extra klurigt pga det faktum att sällan använda funktioner ger låg empiri i modelleringen och är attackerarnas favoriter. Så på de ställen sannolikheten för attack är störst kommer modellen vara som svagast.

Vad händer när applikationen ändras?
En komplex modell som har skapats utifrån en halv miljon request är förstås känslig för ändringar i applikationen. I IDS-världen kallas det concept drift.

Särskilt vanliga ändringar visar sig vara

• Uppsättningen request-parametrar
• Format på och innehåll i parametervärden
• Kopplingar till omgivande resurser (både nya kopplingar och ändringar i befintliga)

Ändringar och dynamiskt uppbyggda webbsajter blir ännu vanligare i och med web 2.0. När webbappen ändrar sig så triggas en ny träningsomgång för att IDS:en ska lära sig det nya korrekta beteendet. Will sa inget om hur en attackerare kan lura webbappen att börja lära sig attackmönster men jag antar att de har tänkt på det.

För att inte få en massa besvikna användare som inte kan använda webbappen för att IDS:en stoppar deras request så kommer man sannolikt använda den här typen av system för detektion, inte prevention.

Koden är GPLv2 och finns att ladda ner på GoogleCode.