Prova gratis Begär offert Kontakta mig
22april
OWASP topp 10 version 2017 lanserat
Vi arbetar ständigt med att förbättra vår plattform för sårbarhetsanalyser. Under 2017 gjorde vi drygt 700 förbättringar i mindre och större skala. Nu har vi just släppt en uppgradering av vår webbapplikationsskanner till OWASP topp 10 version 2017. Vår skanner är därmed en av få som möter version 2017 på alla områden - som går att testa utifrån. Här kommer en djupdykning i vad det innebär. Inom kort släpper vi flera spännande och kraftfulla funktioner.
Av: Stefan Thelberg Ämnen: OWASP top 10, Webbapplikationsskanning

Två av de viktigaste ändringarna i den nya versionen av OWASP topp 10 är följande:

  • A4: XML External Entities (XXE)
  • A8: Insecure Deserialization

Dessa var allmänt kända av hackare men fick inte så mycket uppmärksamhet från utvecklarvärlden. En annan viktig förändring är följande tillägg:

  • A10: Insufficient Logging & Monitoring

Bakgrunden till detta nya område är att en studie visade att det tagit amerikanska företag i genomsnitt 206 dagar för att upptäcka en incident. För att minska denna tid (helst till noll) belyser den nya versionen av OWASP problemet och uppmuntrar utvecklare att ha korrekt loggning och övervakning.

Det finns flera utmaningar relaterade till att upptäcka dessa nya sårbarhetsklasser med hjälp av en webbapplikationsskanner. Hur kan en icke autentiserad skanner detektera om målwebbprogrammet gör korrekt loggning och övervakning? Det korta svaret är att det inte går.

Men misströsta inte då vi har en lösning. Webbapplikationsskannrar är effektiva för att upptäcka XXE och osäkra deserialiseringsrisker. Vår webbapplikationsskanner kunde redan identifiera alla sårbarhetsklasser som finns i den tidigare versionen av OWASP topp 10 (version 2013), så vi förbättrade vår motor för att identifiera de nya sårbarhetstyperna.

XML External Entities är en sårbarhetsklass som är associerad med XML-parsers. När en osäker XML-parser får ett speciellt utformat XML-dokument kan det tvingas att läsa filer från operativsystemet, skapa anslutningar till externa domäner eller till och med utföra godtyckliga operativsystemkommandon. Nya parser-versioner är konfigurerad att vara säkra som standard, men äldre, eller dåligt konfigurerade parsers, påverkas av detta problem med hög allvarlighetsgrad.

Detektering av XML External Entitie utförs med aktiva skanningar. När vår skanningsmotor upptäcker att applikationen tar emot XML-dokument i en av parametrarna börjar den skicka specialtillverkade XML-dokument som försöker läsa operativsystemfiler (t.ex. /etc/passwd) eller utlösa analyseringsfel.

Osäker deserialisering inträffar när en webbapplikation mottar ett serialiserat objekt (som en sträng) och deserialiserar den för att erhålla en objektinstans med samma tillstånd och attribut. Deserialiseringsprocessen kan vara svår eftersom de flesta implementeringar tillåter utvecklarna att deserialisera godtyckliga objekttyper, vilket kan kräva genomförandet av interna metoder för att återställa tillståndet. Denna process leder vanligtvis till sårbarheter för remote code execution som den som påverkade Equifax 2017 och ledde till en omfattande dataläcka.

Att upptäcka osäkra sårbarheter i deserialisering kan vara svårt. Varje programmeringsspråk har flera bibliotek för att utföra objektserialisering. Var och en med sitt serialiseringsprotokoll och specifika sårbarheter. Vår avsökningsmotor skulle kunna försöka skicka alla payloads som krävs för att upptäcka osäkra sårbarheter för deserialisering för alla programmeringsspråk och för varje applikationsingång, men det skulle vara mycket ineffektivt och öka skanningstiden avsevärt. Vi skapade ett annat tillvägagångssätt. Payload skickas bara om vår skanner känner av att applikationen konsumerar  denna typ av data.

Om till exempel vår webbapplikationsskanner upptäcker att en av parametrarna är en Python pickle, skickar skanningsmotorn alla Python pickle payloads till den parametern med målet att upptäcka sårbarheten.

Alla payloads som används för att upptäcka osäker deserialisering är utformade för att vara säkra. De utför endast en tidsfördröjning med hjälp av programmeringsspråkets sleep()-funktion. Detta gör det möjligt för vår motor att upptäcka sårbarheter utan att riskera en denial of service situation-situation och gör det också möjligt för skannern att lyckas även när output för kommandot inte visas i HTTP-svaret, eftersom detekteringen utförs genom mätning av den tid det tar för HTTP-svaret från serven. Om osäker deserialiseringen inträffar kommer kommandot sleep() att köras och svaret kommer att försenas.

About the author
Stefan has worked with IT security his entire career. He founded Stay Secure - the success company within email and web security.

Stefan Thelberg
+46 (0)739-99 33 12
stefan.thelberg@holmsecurity.com