Ny applikationsbrandvägg: ESAPI WAF

ESAPI-gänget har utvecklat en riktigt intressant applikationsbrandvägg -- ESAPI WAF. TIll skilland från modsec som körs på Apache så är ESAPI WAF ett J2EE-filter i din web.xml.

Hur patcha mha EASPI WAF?

Vi går direkt på det intressanta -- hur fixar man säkerhetshål med hjälp av ESAPI WAF? Väl i drift handlar det bara om XML-konfiguration i en policyfil. Jämför det med att behöva branch:a koden, buggfixa, enhetstesta, bygga, systemtesta och driftsätta.

Två konfigurationsexempel ...

Indatavalidering av en request-parameter:

<virtual-patches>

<virtual-patch

id="bugtracker-id 1234"

path="/foo"

variable="request.parameters.bar"

pattern="[0-9a-zA-Z]"

message="detected and stopped attack XYZ"/>

</virtual-patches>

Utdatakodning, t ex sätta HTTPOnly i sina cookies (dock ej sessionscookies eftersom WAFen ligger i applikationslagret) eller lägga till headers (anti-clickjacking med X-FRAME-OPTIONS, UTF-8-kodning etc):

<outbound-rules>

<add-http-only-flag>

<cookie name="*" />

</add-http-only-flag>

<add-header>

...

</add-header>

</outbound-rules>

Hur konfigurera in ESAPI WAF?

Lägg till filter och filtermappning i web.xml (ca 15 rader). Sen en bunt jar:er (ESAPI plus beroenden) och DEBUG-konfiguration för Log4J. Det här kan du göra direkt i den uppackade war:en.

WAF-kritik

WAFar får rätteligen mycket kritik. Om man tror att en WAF ska fixa alla säkerhetsproblem så är man fel ute. Några vanliga invändningar och svar:

• "WAFar ökar attackytan." Felkonfigurerade -- ja. Men det kan man säga om i princip alla säkerhetsfunktioner som är exponerade.
• "WAFar ger kulturproblem i projekten." Ptja, ibland. Det är klart att det blir bråk med arkitekter, projektledare och andra när du drar in en WAF i projektet.
• "WAFar kan inte lösa problem i affärslogiken." Sant. Det är därför vi appsec-människor har jobb.
• "WAFar dyra." ESAPI WAF gratis :).
• "WAFar funkar inte i vårt nät." ESAPI WAF ligger i applikationlagret.