Som du ser är vår webbplats inte anpassad för äldre webbläsare. Vi rekommenderar att du uppgraderar till en nyare webbläsare.
!!

Vi söker en systemadministratör inom Linux-klientinfrastruktur och it-säkerhet till CERT-SE, en central roll i arbetet med att utveckla Sveriges förmåga att förebygga och hantera it-incidenter. Sista ansökningsdag är den 15 augusti.

Uppdaterad | Publicerad

POST ger svarta hål i loggen

Då POST används i en webbapplikation loggas inte indata vilket kan leda till att webbattacker, exempelvis en SQL-injektion, inte lämnar några spår. Artikeln ger förslag på åtgärder för "blinda" webbapplikationer.

Inledning

Det finns två sätt att skicka data från en webbläsare till en webbserver: GET eller POST. Skillnaderna är i huvudsak följande:

  • Vanliga länkar i en sida använder GET.
  • GET skickar parametrarna i HTTP-huvudet medan POST i kroppen av HTTP-anropet.
  • Formulär med indatafält kan använda båda metoderna.
  • GET-parametrarna syns i webbläsarens URL-rad.
  • Det går inte att skapa ett bokmärke från en POST.
  • POST kan hantera en större mängd data. För GET brukar gränsen gå vid 4000 bytes.

Varje GET- och POST-anrop loggas av webbservern men för POST-anrop loggas inte parametrarna, det vill säga själva indata till applikationen. Skälet till att inte lagra POST-anrop i sin helhet är att de kan vara för stora, exempelvis används POST vid filuppladdning.

Problemet med POST

De flesta webbattacker skickar specialkonstruerad indata som i POST-fallet inte loggas. Med andra ord går det inte att avgöra om en attack har skett eller hur den såg ut. Förutom detta uppenbara problem med POST finns flera andra:

  • Bristfällig säkerhet om både GET och POST accepteras. Många applikationer är implementerade så att båda metoderna kan användas för samma anrop. En anledning kan vara att utvecklaren vill erbjuda en flexibel lösning till webbdesignern som då kan välja metod själv. Ur ett säkerhetsperspektiv är det självklart ingen bra lösning, men jag brukade själv implementera servlets på detta sätt när jag var ung och dum. Jag har sett mycket annan kod som gör likadant, så jag är långt ifrån ensam. Java-klassikern brukar vara att doPost- och doGet-metoderna båda anropar doProcess i en HttpServlet-klass. Om båda metoderna kan användas riskerar loggningen att bli godtycklig och kan ändras under applikationens livstid.
  • Angriparen kan utnyttja att båda metoderna fungerar. Genom att alltid använda POST där det går kan angriparen hålla sig under radarn. Det är inga problem att konvertera en GET till en POST i de attackverktyg som finns idag.
  • Falsk trygghet. Vi på Sitic får ofta höra följande: "Vi läser inte loggarna, men sparar dem ifall det händer något". Problemet för en POST-intensiv applikation är att det inte finns något att hämta i loggarna till webbservern. Undersök därför vad som skrivs till webbserverns och applikationens loggar innan en eventuell incident inträffar.

När ska GET respektive POST användas?

Specifikationen från W3C är tydlig:

  • GET ska användas för "säkra" operationer, så som frågeoperationer vilka läser ur databasen. Sökning och navigering är typiska exempel där GET ska användas.
  • POST ska användas för anrop som ändrar tillstånd, exempelvis skrivningar till databasen. Addera vara till varukorg eller uppdatering av adressuppgift är två POST-exempel.

En del applikationen hämtar länkar i förväg då en webbsida besöks, exempelvis för att öka prestandan eller för scanna osedda sidor efter elak kod. Detta är helt enligt specifikationen eftersom länkarna är GET-anrop som inte ska ändra tillstånd. Det kan således vara förödande att till exempel ha en "Radera alla poster"-länk om klienten förladdar länkar. Tänk därför noga igenom vilka anrop som ska vara GET och vilka som ska vara POST, och tillåt aldrig att ett anrop fungerar med båda typerna.

Lösningar

Det finns ofta ingen snabbfix för att logga POST-anrop. De flesta webbservrar, till exempel IIS, Apache eller Tomcat, kan inte konfigureras för att lagra POST-anrop. Detta är en sanning med modifikation, i exempelvis Tomcat kan x-P(...) användas för att logga enstaka POST-parametrar. I Apache kan mod_dumpio användas men denna modul är mest tänkt för felsökning. Kontrollera därför dokumentationen till webbservern eftersom det kan finnas produktspecifika tillägg som skulle kunna lösa problemet.

Vid nyutveckling är möjligheterna att skapa en heltäckande och flexibel loggning av indata som störst. Applikationen bör designas så att alla HTTP-anrop kommer in till en och samma gemensamma punkt i koden. Där kan inte bara loggning jackas in utan även behörighetskontroll, larm över misstänka anrop med mera. Loggning måste vara konfigurerbar så att inte all indata lagras, exempelvis ska inte lösenord loggas och parametrar med mycket data ska kunna exkluderas eller delvis loggas.

Om det inte är möjligt eller önskvärt att göra källkodsändringar i applikationen kan en fristående loggningsmodul implementeras om webbservern stöder detta. Modulen anropas av webbservern före HTTP-anropet kommer till webbapplikationen. I Microsoft IIS skapas en modul genom att implementera "interface":et IHttpModule, vilken kan skrivas i exempelvis C# eller Visual Basic. I Tomcat kan ett "valve" skapas genom att implementera ValveBase, från vilken exempelvis AccessLogValve- och RequestDumperValve-klassen ärver ifrån. Den förstnämnda klassen hanterar access-loggen och den senare loggar ett HTTP-anrop för felsökning.

För den som inte vill skriva någon kod kan en applikationsbrandvägg användas, eller en WAF (Web Application Firewall) som de kallas för i webbsammanhang. En WAF sitter framför webbapplikationen och analyserar trafiken. Om ett potentiellt farligt anrop upptäcks, till exempel en SQL-injektion, returneras en felsida eller omdirigering till webbklienten. HTTP-anropet når alltså aldrig webbapplikationen. Eftersom applikationsbrandväggen analyserar både HTTP-huvud och -kropp kan den ofta logga hela HTTP-anropet inklusive indata i en POST:ning. OWASP har en förteckning över WAF:ar. En del produkter består av såväl hårdvara som mjukvara (en s.k. "appliance"), medan andra är rena mjukvarulösningar. En välkänd öppen källkodsprodukt är mod_security.

Om en applikation har tvivelaktig loggning bör leverantören kontaktas. De kanske har en lösning på problemet, eller om de inte har det kanske de inte ska vara aktuella vid nästa upphandling. Dålig loggning ger sämre säkerhet och det ska inte accepteras.

Har du en bra lösning på loggning av POST-data eller frågor kring artikeln? Hör då gärna av dig till Sitic.

Tor Johnson, Sitic (min e-postadress finns på kontaktsidan)