Web Application Exploits and Defenses är en utbildnings- och demonstrationsprogram för vanliga säkerhetshål. Den uppges fungera genom att:
1. Ett antal säkerhetshål i presentationen av en liten applikation som exekveras ovanpå en webbserver finns.
2, Till dessa finns utmaningar som antingen är black box, kräver att du tittar på källkoden.
Det här är ett koncept som jag känner väl till därför att jag för många år sedan utvecklade en liknande men betydligt mer avancerad applikation för detta. Några skillnader mellan dessa är värda att notera:
1. Min fångade alla viktiga säkerhetsproblem som då fanns rörande XSS och allt i övrigt liknande det. Dessutom en del problem möjliga i javascript. Googles lösning inkluderar endast ett mindre urval som dock tycks väl valda.
2. Min tog med alla triviala säkerhetsproblem som trots triviala ändå är väldigt vanliga t.ex. att kataloger är läsbara, namn på filer namnges så att de kan gissa o.s.v. Totalt 20 - 30 st. De flesta av dem är inte aktuella på samma sätt idag. Googles lösning fångar en del av dessa men inte alla jag tycker de borde ha tagit med. Ett av de mest triviala som finns i både och som när jag skrev min kanske 2003 fortfarande var ett inte helt ovanligt problem men som idag bör vara väldigt ovanligt är denna:
"If an attacker knows the structure of your file system, then they can craft a URL that will traverse out of the installation directory to /etc. For example, if Picasa was vulnerable to path traversal (it isn't) and the Picasa servers use a Unix-like system, then the following would retrieve the password file:"
http://www.picasa.com/../../../../../../../etc/passwd
Dels har det här problemet blivit ovanligt därför att lösningarna standardmässigt skyddar sig mycket bättre mot det. Dessutom är det inte längre så på moderna Unix att även om det gick att göra att det skulle ge angriparen något - åtminstone inte just av värde från /etc/passwd. Det finns undantag för det men vanligen används shadow, NIS eller idag ganska ofta hålla dem lagrade i en LDAP-katalog eller jämförbart och detta har varit vanligt åtminstone i mer än 10 år och ganska vanligen även innan det. Det är just tillför att access till /etc/passwd inte ska användarnamn och hashvärden för lösenorden som går att använda. Orsaken är att det funnits så oerhört många angrepp som gjort detta möjligt.
3. Diverse angrepp via kakor. Här tror jag Googles lösning fångat några av de viktigaste som fortfarande är aktuella idag.
4. I min lösning fanns en mycket stor uppsättning av säkerhetsproblem specifika för många system oavsett systemutvecklade, representerade vanliga komponenter eller problem i färdiga produkter fanns. Totalt cirka ett hundratal. Google stödjer ett fåtal.
5. Även DoS fångade min lösning upp en hel del för. Det var ju också ett många säkerhetsområden jag säkerhetsstuderat. Google har stöd för detta.
6. Min lösning hade stöd för SQL-injection men saknade databas. Istället emulerades några enklare sådana. Denna del var inte avancerad på något sätt. Detta stödjer också Google och helt säkert mycket bättre.
Båda lösningar stödjer också mycket mer än diskuterat.
Förklarade text är det stora värdet
En stor skillnad värd att peka på är strukturen för hur det ska användas. Jag utvecklade min medan jag undervisade på Högre utbildning i informationssäkerhet för att demonstrera säkerhetsproblem. Mitt mål var dock att det skulle kunna bli en utbildningsmiljö kanske möjlig att sälja anpassad. Den hade därför ett mycket större fokus på text som fanns med i kursavsnitt.
Varje kursavsnitt förklarade det allmänna problemet. Gav exempel på känsliga programvaror och diskuterade skadorna problemen kunde orsaka. Sist förklarades olika säkerhetslösningar för att korrigera problemen. Även av de typer som innebär att programvaran korrigerades men lika viktigt lösningar som skyddar mot dem utanför lösningen eftersom det ger ett proaktivt säkerhetslager som ger värde om ej upptäcka program finns eller när det är opraktiskt eller dyrt att korrigera säkerhetsproblemen direkt.
Tillsammans med texten fanns övningar att göra med lösningen.
Jarlsberg för mikrobloggar
Själva funktionen lösningarna presenterar är väldigt olika. Jarlsberg Google utvecklade för att köra Web Application Exploits and Defenses på är en liten mikrobloggtjänst.
Min lösning var istället mer av det affärs- och verksamhetssystem till stor delar skrivet i Perl. Det gjorde att många säkerhetsproblem gick att illustrera mer spännande t.ex. olika sätt att extrahera löner.
Googles lösning behöver utvecklas framåt
Sammantaget är lösningen Google gjort väldigt intressant och tror jag kan ha stort värde. Det sätt som den presenterats på tror jag dock begränsar detta väldigt. För att sådant här verkligen ska ge värde gäller det att presentera allmän information som förklarar säkerhetsproblemen och lösningen. När så sker blir det lättare att lära sig problemen så att man inte råkar införa dem själv.
Här blir det istället mer av att endast se vad problemen kan göra och att de kan finnas. Det tillför inte säkerhetsmycket eftersom det är vad som ändå kommer fångas av automatiska säkerhetsskanners och det tillför heller ingen kunskap som hjälper utvecklare att undvika dem. Det finns en mängd liknande problem och det är kunskapen hur de hanteras eller undviks från första början som är viktigt. Kunskapen runt om kring exemplet är vad som ger förutsättningar till det.
Inte heller diskuteras hur man löser problemen när det finns olika alternativa vägar. Har du ett problem i din lösning gäller för väldigt många på webben att det är tidsödande, problematiskt och dyrt att korrigera problem som inte är standardmossiga. Värdet av noga diskutera problemen avseende typisk kod liksom lösningar som kan användas för att kapsla in problemen är därför väldigt viktigt.
Relaterat
Kort information om min mjukvara finns här:
Problemet med att horoskop menar att jag ska delta i tävlingar
Jag har den kvar fast på en hårddisk där ett gammalt OS krashat. Vid tillfälle ska jag montera upp den på min nyare hårddisk så kan jag tar fram den igen. Ska man göra något med den tror jag dock det bästa är att bygga den ovanför Drupal eller liknande så att den större styrkan som finns bättre kan utnyttjas och utvecklas vidare. Just möjligheten där man ser det som ett affärs- och verksamhet gör betydligt fler säkerhetsproblem går att illustrera. Det ger dessutom mycket bättre möjligheter att skapa välgjorda informationsavsnitt i kursboken som presenteras tillsammans med affärssystemet.
Kommentera