Säker Java med omskrivning och filtrering

En god vän sen en tidigare konferens Martin Johns, Universität Passau, presenterade skydd mot XSS och SQL-injektion genom en preprocessor som skriver om programmet. Allt utvecklat för J2EE-applikationer.

Idén
Forskningsidén utgår från tanken att utvecklaren faktiskt vet att han/hon vill skriva en select-sats eller en eller en HTML-tag utan skript, men att strängbaserad programmering inbjuder till misstag. Det borde helt enkelt vara skillnad på exempelvis nyckelord i SQL och på strängar.

Om vi nu ska skriva om befintlig kod så måste det vara obligatoriskt, inte valfritt. Det räcker som bekant med att man glömmer en XSS-sårbarhet så är man rökt.

Container-klasser och domänspecifika filter
Man vill skapa primitiver eller tokens för måldomänen direkt i språket. Dvs om du utvecklar en databaskoppling så ska nyckelord i SQL betyda något, om du utvecklar en webbtjänst så ska SOAP-elementen betyda något, och om du utvecklar en webbsida så ska HTML-elementen betyda något. Det ska inte bara vara strängar. Det öppnar nämligen upp för manipulation.

Johns och hans projekt utvecklade container-klasser för ett antal känsliga strukturer som ofta hanteras som strängar. Container-klasserna har tokens för måldomänens grammatik. Vid kompilering parse:as strängargument och skrivs om till container-objekt. Dynamiska data i strängarna ändras förstås runtime i container-objekten men filtreras då med filter som definierats för respektive container.

För varje sårbar struktur har de alltså gjort följande:

1. Identifiera tokens i måldomänens grammatik
2. Skapa pojo-API för container-klass
3. Skapa preprocessor som skriver om strängar till containerkod
4. Skapa domänspecifika filter för dynamiska data

I SQL-fallet blir det i princip prepared statements utan att att de har förberetts av databasen. Dynamiska argument till SQL-satsen filtreras innan de konkateneras i container-objektet.

I HTML-fallet så filtreras all utgående, dynamiskt skapad data för XSS.

Overhead och utstående frågor
Deras experiment visar på en 25 %:ig overhead vilket är väldigt mycket. Martin kunde inte svara på varför men var överraskad själv. De ska arbeta vidare och kanske hittar de någon flaskhals.

Jag frågade om hur många buggar deras kodomkrivning och container-objekt introducerade. De var hyfsat trygga med att de inte ändrade funktionaliteten men hade inte gjort någon särskild analys av det. Deras industripartner krävde att de utvärderade tekniken i ett större jsp-baserat projekt vilket gjorde storskalig testning och analys väldigt svårt.

Sen tog vi upp att det finns många befintliga tekniker som löser problemen. Särskilt i fallet SQL-injektion där både korrekt använda prepared/parameterized statements och ORM-ramverk löser problemet. Och samma indatavalidering som Martins filter kör på dynamiska element i SQL-satserna skulle lösa hela problemet. Martin höll med men poängterade att deras mål var att skapa något som löste flera säkerhetsproblem på samma sätt, inte bara SQL-injektion.