Webbsäkerhet och vanliga brister - kunskapsläget bland utvecklare.

Transkript

1 Kandidatarbete I programvaruteknik Webbsäkerhet och vanliga brister - kunskapsläget bland utvecklare. Jane Strandberg Mattias Lyckne Kontaktinformation: Author(s): Jane Strandberg jane.strandberg@gmail.com Mattias Lyckne mattias.lyckne@gmail.com Handledare: Conny Johansson School of Computing Blekinge Institute of Technology SE Karlskrona Sweden Internet : Phone : Fax :

2 Sammanfattning Den här kandidatavhandlingen undersöker utvecklares kunskaper inom webbsäkerhet både när det gäller deras egen syn på sin kunskap men även deras faktiska kunskap om de vanligaste säkerhetshålen och hur man mitigerar dessa. Webbutvecklares kunskaper inom webbsäkerhet blir allt viktigare i takt med att fler och fler applikationer och tjänster blir webbaserade och fler föremål blir uppkopplade mot internet. Vi har genomfört en undersökning bland utvecklare som för närvarande studerar inom området eller redan är ute i arbetslivet för att se hur kunskapsläget ligger till inom de vanligaste säkerhetsbegreppen. Vad vi såg var att resultatet varierar mellan de olika begreppen och många saknar en stor del av den kunskap inom webbsäkerhet som blir allt viktigare att inneha. Keywords webb, säkerhet, webbsäkerhet, sql injections, xss, csrf Abstract This bachelor thesis looks at developers knowledge about web security both regarding their own view on their knowledge and their actual knowledge about vulnerabilities and how you mitigate against them. Web developers knowledge regarding web security are becoming more and more important as more applications and services moves to the web and more and more items become connected to the internet. We are doing this by conducting a survey among developers that are currently studying in the field or are working in the field to get a grip on how the knowledge is regarding the most common security concepts. What we saw was that the result varies between the different concepts and many lack much of the knowledge in web security that is getting increasingly more important to have. Keywords web, security, web security, sql injections, xss, csrf 2

3 Innehåll 1 Introduktion Relevans Mål Bakgrund Säkerhetsbegrepp Risker inom webbsäkerhet Forskningsfrågor Metod Undersökning Litteraturstudien Databaser Nyckelord Kombineradenyckelord Specifikadelar Relevanta träffar Fokus Resultatavlitteraturstudien Vad finns det för lösningsförslag? Analys av undersökningsresultat Utförande Insamladdata Bakgrund och uppfattning Kunskapombegrepp Kunskap om lösningar Analys Brister Diskussion Slutsats Framtidaarbete Glossary AppendixA Website security survey Svar påsurveyn Surveydata-bilder... 62

4 4

5 1 Introduktion I dagens informationssamhälle är det vanligt att vara online hela tiden. Smartphones, surfplattor, datorer, TV-apparater, spelkonsoler, brödrostar osv är eller har potential att vara anslutna till internet. Detta leder till att mer information om varje person blir tillgänglig och sparas. Den lagrade mängden data förväntas bara att fortsätta att växa. En studie utförd av IDC[5] visar att datamängden förväntas att växa från 120 exabyte till exabyte från 2005 till De flesta webbplatser erbjuder, och ibland till och med kräver, att du registrerar dig som användare. Våra egna erfarenheter har gett oss en indikation påattsäkerheten kring detta inte alltid är vad den borde vara, vilket har oroat men även väckt ett intresse. Ett vanligt scenario vi har stött på är att efter en genomförd registrering skickas ett e-postmeddelande ut till en med det anvigna användarnamnet och lösenordet i klartext. Detta kan också inträffa när man vill återställa ett bortglömt lösenord. Det är inte bara en säkerhetsrisk att skicka lösenordet via mail i klartext, det tyder också påattlösenordet lagras i klartext. Något som Dustin har visat prov på[7]. Detta faktum har gjort oss nyfikna att ta reda på varför vi ser dessa brister upprepat dyka upp. Det finns utvecklare bakom dessa sidor som antingen missar eller inte vet om dessa brister. Utvecklare som av en eller annan anledning har gett möjlighet till attacker och informationsläckor. Det blir också lättare för alla att lära sig att skapa webbsidor, antingen genom tutorialer på nätet och instruktionsböcker, eller genom ett brett utbud av fristående kurser på olika skolor. Om säkerheten inte är en stor fråga i dessa forum, kan det då vara en orsak till vi har många fall av webbplatser och system som brister i säkerheten? De flesta människor har en generell definition av säkerhet. Vi vill behålla vår integritet och att stjäla någon annans identitet är ett straffbart brott. Mängden lagrad data ökar konstant med vår nya teknik och IDC[5] har dragit slutsatsen att den data som måste skyddas växer snabbare än vad den digitala världen gör. De uppskattar att endast ungefär hälften av dessa uppgifter faktiskt skyddas på något vis. Då kan man dra slutatsen att den andra hälften sparas oskyddat och görs tillgängligt till de som har eller skapar tillgång till dessa källor. IDC[5] har uppfattningen om att säkerhet är en stor fråga, men att det är en fråga som fortfarande i hög grad är förbisedd. Även fast att tekniken blir bättre. De efterlyser en standardisering bland webbsidor så att privata data inte kan brytas ut, kombineras och därmed äventyras. 1.1 Relevans Precis som det blir lättare att lära sig skapa webbsidor blir det lättare att lära sig hacka dem. Vi ser att både stora och små webbplatser blir mål för attacker. Bland 5

6 nyheterna kan vi finna att Facebook[12], Twitter[8], Adobe[4] och Microsoft[9] har blivit hackade. Likaså har LinkedIn[15], Sony[14] och Yahoo[24] blivit det. Även om lösenord inte läckt kan andra typer av data göra dig sårbar för attacker så som phishing. Nyligen drabbades VPS-webbhotellet Linode av en attack där angriparna kom åt deras databaser och information om användare läckte ut. Enligt Linodes egna blogg[1] var data som kreditkortsnummer och salt krypterade, men lösenord till andra delar av tjänsten var i klartext. System blir mer och mer komplexa och ansluter till varandra i en större utsträckning. Denna komplexitet och utveckling av tekniken i sig gör systemen i allmänhet mer sårbara, något som Bruce Schneier beskriver i sin bok Beyond Fear[17]. 1.2 Mål Målet med denna uppsats är att nå en slutsats kring om det finns brist i kunskapen gällande säkerhetshål hos utvecklare, eller om dessa har en mer eller mindre omfattande kunskap gällande nuvarande vanliga säkerhetshål. Det är ett mål att påvisa om utvecklare är övermodiga gällande sin kunskap om hoten eller om de lever upp till sina påstående och innehar den kunskap de själva tror. Vi hoppas ge ytterligare inblick till hur situationen ser ut med säkerhet på webben idag och framöver samt pålysa de problem vi själva upplever finns. Detta gäller framförallt okunskap från utvecklarens håll samt brist på utbildning inom ämnet. Vi vill förmedla att det finns en brist i kunskap som utbildning kan motverka och riktar oss på så vis mycket till ansvariga inom företags- och utbildningssektorn. Vi bygger detta arbete på tidigare forskning och en egen undersökning bland utvecklare för att få en inblick i hur stor kunskapen är kring vanliga säkerhetshål och bregreppen som omfattar dessa. 6

7 2 Bakgrund 2.1 Säkerhetsbegrepp Det finns flera viktiga begrepp inom säkerhet. Bruce Scheneier tar upp de tre viktigaste: Identifiering (vem du är), autentisering (bevis på vemduär) och tillstånd (du är tillåten att göra detta)[17]. Identifiering. Som identifikation kan man använda till exempel namn och nummer, där nummer är det mest unika då flera personer kan ha samma namn. Detta är också den design som använts i dagens teknik. Ett användarnamn kan också användas som identifierare, förutsatt att det är unikt. Autentisering. Autentisering används tillsammans med identifiering och Schneier ger oss ett exempel där ett användarnamn identifierar dig och ett lösenord autentiserar dig. Schneier skriver om tre sätt du kan autentisera någon på: något han vet, något han har och något han är. Lösenord var ett exempel på något han vet. Scheneier påpekar att det är skört att förlita sig på endast ett av dessa. En del webbsidor som tex Google har en möjlighet till så kallad tvåstegsverifiering, vilket innebär att du autentiserar dig med ditt lösenord (något du vet) och en kod du får till din mobiltelefon (något du har). Tillstånd. Autentisering sker ofta genom så kallade tokens. En token indikerar att du är tillåten att vara där du är och göra det du gör. De är också oftabegränsade i tid, ett visst antal användningar eller endast i vissa områden. Det finns några fler begrepp som är giltiga i webbsäkerhet. Integritet är att säkerställa att informationen är korrekt och oförändrad. Sekretess är att se till att information som skickas inte kan ses av obehöriga användare. Oavvislighet är att säkerställa att transaktionen av information kan spåras så att ingen kan förneka dess förekomst. Tillgänglighet är att se till att informationen alltid är tillgänglig för den som har tillstånd att se den[13]. 2.2 Risker inom webbsäkerhet När man tittar på hoten inom webbsäkerhet är det en bra början att titta på OWASPs senaste topp tio[23]. 1. Injektion (Injection) 2. Trasig autentisering och sessionshantering (Broken Authentication and Session Management) 3. Cross-site Scripting (XSS) 4. Osäkra referenser till objekt (Insecure Direct Object Reference) 5. Felkonfigurering av säkerheten (Security Misconfiguration) 7

8 6. Exponering av känsliga uppgifter (Sensitive Data Exposure) 7. Saknaden av funktionsstyrd accesskontroll (Missing Function Level Access Control) 8. Cross-Site Request Forgery (CSRF) 9. Använda komponenter med kända sårbarheter (Using Components with Known Vulnerabilities) 10. Icke-validerade redirects (Unvalidated Redirects and Forwards) Genom att granska övrig litteratur så har vi fokuserat på de av dessa i Top 10 som omnämns och beskrivs i någon form. Nr 10, icke-validerade redirects föll här bort, då vi bara kunde hitta en beskrvning och omnämning av denna form av attack i just OWASP. Det är viktigt att även nämna att en del av Top 10 även är begrepp som innefattar flera olika attacker som faller under samma kategori. Sessionshantering är en sådan. Nedan följer beskrivingar på de vi har valt att flyta fram. Angripare är hackaren som via säkerhetshålen attackerar en användare (klient) eller en webbplats (server, tjänst). Användaren är den som besöker en webbplats för att utnyttja dess tjänster. SQL injektion (SQL injection) Injekton är att mata in kod till en applikation som interagerar med intepretatorn. Enligt OWASP är det ett vanligt fel i koden och är svårt att upptäcka via tester. Risken är stor eftersom det kan resultera i förlust och förvanskning av data. En vanlig form av injektion är SQL injektion där operationer utförs på en SQL-databas. En angripare kan till exempel dumpa hela databasens innehåll till sig själv[3]. En vanlig orsak till detta beror på att själva databasfrågan (queryn) konstrueras efter input och att input inte valideras eller filtreras.[6] Exempelkod: 1 $query = SELECT FROM u s e r s WHERE i d =. $ POST [ userid ]; 2 $result = mysql query($query); 3 // Display result Om angriparen skickar in 123 or 1 = 1 i $ POST[ userid ]-variablen, kommer sql-queryn bli: 1 SELECT FROM users WHERE id = 123 or 1 = 1 och eftersom 1=1 är sant kommer alla rader i users-tabellen att returneras. Trasig autentisering och sessionshantering (Broken Authentication and Session Management) 8

9 När denna risken finns är det möjligt för en angripare att få information om användaren och utge sig för att vara denne. Brister som denna kan hittas i saker som hantering av lösenord, timeouts, kom ihåg mig-funktioner med mera. Enligt OWASP är effekten stor eftersom det ger angripare tillgång till att utföra saker som en vanlig användare eller rentav som administratör. Exempel på attacker är cookie poisoning, session fixation och session hijacking. Cookies används för att spara information om en användare och dess session.[3] Vid cookie poisioning så modifieras en cookie-fil för att t.ex ge höjda privilegier till användaren.[6] Vid session fixation så skapar en angripare en session som denne sedan lurar en användare att använda, i syfte att användaren använder samma session som angriparen. [20] Påsåsätt kan angriparen t.ex komma åt kontouppgifter som tillhör användaren.[11] Session hijacking går ut på att en angripare stjäl en cookie eller andra sessionvariablar för att utge sig för att vara användaren. På såsätt kan angriparen komma åt ett konto utan att behöva ange användnamn eller lösenord, för sidan uppfattar det som att användaren redan är inloggad eftersom sessionen är aktiv.[3] Exempel: 1. Webbplatsen skapar ett session-id och skickar med detta i URLen i varje request - Användaren kopierar länken och skickar till en vän, vännen klickar på länken och får påså vis användarens session-id och agerar som användaren. 2. Webbplatsen har inte satt korrekt timeout på sessions. Användaren använder en publik dator och istället för att logga ut stänger ner webbläsaren. En annan användare använder datorn, går till samma sida och är fortfarande inloggad som förra användaren. Cross-site Scripting (XSS) Cross-site scripting (XSS) är när indata från en användare innehåller script som sedan exekveras på webbsidan. Detta uppfattas som en utbredd brist enligt OWASP, men är ganska lätt att upptäcka. Det finns tre typer av XSS: Lagrade, reflekterade och DOM-baserade. Vid en reflekterad attack så måste användaren luras att skicka skadlig kod till sidan själv varpå det sedan visas/körs på sidan. Vid en lagrad attack så sparas den skadliga koden på sidan (t.ex på forum eller liknande). Vid en DOM-attack så luras användaren in på angriparens hemsida som innehåller kod för att se till att skadlig kod körs när användaren sedan går till den faktiska sidan. Ett mer konkret exempel är en script-tagg som inkluderar en 9

10 script-fil från en annan webbsida som skrivs in i en kommentar som postas på webbsidan. När kommentaren renderas och visas för användare kommer scriptet exekveras.[6] XSS används ofta för att t.ex stjäla cookies.[22] Det nämns också attxss inte bara innefattar attacker med JavaScript, men även språk som Java, Flash och ren HTML.[3] Exempelkod, skriven som en kommentar på tex ett blogginlägg: 1 Wow, bra skrivet! <script src= http :// example.com/ badfile. js ></ script> När andra användare sedan går in och läser kommentaren till detta inlägget renderas script-taggen och koden i badfile.js exekveras på klienten (användaren). Osäkra referenser till objekt (Insecure Direct Object Reference) Genom att ändra en parameter som är en referens till ett objekt kan en behörig användare få tillgång till föremål som ligger över användarens åtkomstnivå. Anses vara vanligt enligt OWASP, men lätt att upptäcka och med måttlig inverkan. Exempelkod: 1 $stmt = $db >prepare( SELECT FROM messages WHERE id = : messageid ); 2 $stmt >bindparam( : messsageid, $ GET [ messageid ], PDO:: PARAM INT) ; 3 $stmt >execute () ; 4 5 $result = $stmt >fetchall () ; 6 // display $result Den här koden öppnar upp att visa meddelande med vilket ID som helst, oavsett vem meddelandet tillhör. Användaren kan således visa meddelande med t.ex ID 100 genom att gå till även om det meddelandet inte tillhörde användaren. Felkonfigurering av säkerheten (Security Misconfiguration) Detta kan ske på alla nivåer i applikationen. Genom att inte ta bort saker som standardkonton och lösenord, oanvända sidor och inte skydda filer och kataloger kan en angripare få tillgång till både systemet och funktionalitet och i vissa fall äventyra hela systemet. Annat exempel är att glömma 10

11 ändra till production på webbplatsen och på så vis visa för mycket debuginformation som till exempel hela stack trace vid fel. Exponering av känsliga uppgifter (Sensitive Data Exposure) Om känslig data inte krypteras eller på annat sätt skyddas kan den bli stulen eller avlyssnas. Att använda svaga algoritmer för att till exempel hasha ett lösenord anses också vara en svaghet. Detta är ovanligt men konsekvenserna är allvarliga med tanke på vilken typ av data som kan äventyras. Det kan vara information som kreditkortsnummer, personuppgifter och patientjournaler. Saknaden av funktionsstyrd accesskontroll (Missing Function Level Access Control)] När en autentiserad eller anonym användare kan ändra parametrarna på en begäran för att få tillgång till en funktion som inte är inom deras behörighetsnivå. Detta fel inträffar till exempel när utvecklare glömmer att inkludera kod för att kolla om användaren ska ha tillgång eller inte. En typ av attack är forced browsing. Några exempel är t.ex en adminsida som inte finns länkad någonstans på hemsidan men går att nå av vilken användare som helst bara de anger rätt URL, eller när man kan ändra URLparametrar till att nå filerpå andra platser i filstrukturen som man inte ska kunna nå.[3] Watson tar även upp ett exempel där man ändrar användar-id som parameter i URL en och får därmed tillgång till någon annan användares konto eller uppgifter.[22] Exempel: Nya användare läggs till via sidan och kräver administratör-behörighet. Det sker validering av användaren om den går via den vägen, men utvecklaren glömmer lägga till validering i adduser.php, som ärdenfilensomhåller funktionaliteten för att lägga till en ny användare. Detta innebär att användaren kan gå direkt till och få tillgång till sidan utan att ha rätt behörighet. Cross-Site Request Forgery (CSRF) Angriparen skapar en förfalskad begäran som de sedan lurar en användare att skicka till webbsidan, som påså vis utför något med användarens behörighetsnivå. Det kräver att användaren som omedvetet skickar begäran redan är autentiserad på webbsidan. Till exempel används det för att skicka formulärdata, så att en användare luras att skicka datan till sidan. Datan i sig tolkas som att den kommer 11

12 från en authentiserad användare, när den i själva verket är skapad av en angripare.[6] Skillnaden mellan XSS och CSRF beskrivs av Siddiqui och Verma som att vid XSS så litar användaren på sidan denne besöker, medan i CSRF så litar sidan på den autentiserade användaren.[18] Exempelkod liggandes på angriparens sida: 1 <img src= http :// examplebank.com/sendmoney.php?amount=1000& toaccount=attackersaccount > när användaren besöker denna sida hos angriparen kommer img-taggen göra ett anrop till URLen. Är användaren redan autentiserad och examplebank inte har skydd mot CSRF kommer koden exekveras och en summa på 1000 flyttas från användarens konto till angriparens. Det kräver alltså att användaren är autentiserad på sidan och luras in på angriparens sida. Använda komponenter med kända sårbarheter (Using Components with Known Vulnerabilities) Det är möjligt för en angripare att använda sig av redan kända brister i komponenter för att få sig tillgång till en applikation. Graden av skada kan variera från minimal till stor. Detta blir en större risk när utvecklarna inte ser till att uppdatera komponenterna frekvent. 12

13 3 Forskningsfrågor RQ1. Vilka är de stora säkerhetshålen enligt litteraturen och vilka lösningar finns det för att motverka dessa? RQ2. Hur omfattande är kunskapen gällande både de funna vanliga säkerhetshålen och dess lösningar bland utvecklare? RQ3. Kan man peka ut brister i faktiskt och uppfattad kunskap om de vanliga säkerhetshålen och dess lösningar? Dessa kommer besvaras på följande vis: RQ1. Forskning i litteratur RQ2. Undersökning RQ3. Forskning i litteratur/undersökning 4 Metod 4.1 Undersökning Vi kommer att skapa en mindre undersökning som riktar sig till utvecklare samt studenter för att få en inblick i hur stor kunskapen är kring vanliga säkerhetshål och begreppen som omfattar dessa. Samt så kommer undersökningen att försöka få en inblick i hur stor kunskap de svarande har när det gäller att mitigera en del utav dessa säkerhetshål. Kommer vi kunna se att vissa begrepp är mer kända än andra, att man har kunskap om hålen men inte lösningarna? Kommer vi kunna peka på brister i kunskapen? 13

14 5 Litteraturstudien 5.1 Databaser Inspec/Compendex för relevanta rapporter och undersökningar Rekommenderades av biblioteket och dessa databaser har hjälpt oss att hitta relevanta artiklar baserade på våra nyckelord och gett oss möjlighet att förfina våra sökningar. Alla rapporter är tilldelade nyckelord, både av själva databasen och författarna. Genom att gå igenomsökresultaten har vi haft möjlighet att prova de olika sökorden och på så vis breddat vårt resultat. BTH Summon för att hitta rapporter listade hos Inspec/Compendex Inspec/Compendex ger användbar information om sökord och ett abstrakt för varje rapport, men inte hela texten. För att få hela texten har vi använts BTHs sökmotor Summon. Google för att hitta tidigare attacker Genom relevanta webbsidor som Wired 1,PCWorld 2 och teknikrelaterade nyhetssidor eftersom de ger ny kunskap om säkerhetsfrågor och är en bra portal för att hitta och följa både större och mindre nyheter om sårbarheter och hackade webbplatser. De ger ofta länkar till tidigare relaterade artiklar och bloggar för de berörda företagen. Till exempel den senaste Linode-hacken publicades med en länk till Linodes officiella blogg. OWASP-projektet OWASP-projektet är ett onlineprojekt som fokuserar på webbsäkerhet och har omfattande material om både risker och hanteringen av dessa. Genom detta har vi funnit de vanligaste attackerna och ökat förståelse för några viktiga begrepp. Det har gett oss de sökord vi behövt för att fördjupa vårt sökande, och hitta relevant information om specifika attacker istället för rapporter fokuserade på en mer bred översikt om webbsäkerhet. Nyckelord web, security, threats, risks, vulnerabilities, hacked, development Kombinerade nyckelord web security, web vulnerabilities web application risks web security threats, hacked websites, secure web development, developing secure web, Specifika delar sql injection, cross-site scripting, cross site request forgery, session management, cookie management, Som synes finns det en hel del synonymer att bygga sökningen på, och för ett bredare result har vi kombinerad orden på detsätt vi bedömt varit relevant. Detta har naturligtvis gett oss en hel del material att gå igenom, ofta flera tusentals träffar

15 Relevanta träffar web security, web security risks, web application security, web application risks, web attacks, common web threats/vulnerabilities 5.2 Fokus Vi har fokus på nyare rapporter på grund av det faktum att webbtjänster utvecklas i en snabb takt i och med att webben är långt mer tillgänglig nu med saker som cloud computing, smartphones och andra bärbara enheter. Även om vissa nyckelfrågor rörande säkerhet naturligtvis förmodligen alltid kommer förbli detsamma och utvecklare och angripare alltid kommer tävla mot varandra att hitta nya sätt att arbeta på. Med nyare rapporter menar vi från , men i vissa fall där träffarna har varit färre har vi gått tillbaka ytterligare några år. Många attacker som till exempel SQL-injections har funnits länge och är därför kan äldre rapporter om dessa fortfarande var giltiga. 15

16 6 Resultat av litteraturstudien Webbsäkerhet och attacker har skiftat från servrar till klientsidan. I takt med att serveradministratörer blev bättre på attsäkra sina servrar hittade angripare nya sätt att attackera applikationer på[21]. Choukse et al.[3] uppger också att säkerhet finns på nätverksnivå genom brandväggar, routrar och andra systemintrång. Dessa säkerhetsåtgärder bidrar dock bara med säkerhet för intrång utanför applikationen, medan webbsårbarheter ofta existerar inuti själva applikationen. Choukse et al. skriver att informationen som skickas från programmet oftast ser likadan ut på nätverksnivå, oavsett om den är legitim eller inte. Hela 70% sker nu på applikationsnivå[3]. Vi kan se att webbapplikationer också blir allt vanligare inom företag. Rudman skriver att när användare får teknik i sina vanliga liv känns det naturligt att även ha tekniken på jobbet[16]. Hastigheten i utvecklingen av företagets applikationer har gått så fort att fokus har förflyttats från säkerhet till tillgänglighet. Allt eftersom fler affärer görs online öppnas nya arenor upp för angripare. Rudman påpekar att mängden tillgängliga personuppgifter ökar vilket leder till mer socialt konstruerade attacker så som phishing. Riktad phishing kan vara en större risk än enkla spam-mail eftersom dessa nu med de tillgänliga personuppgifterna kan anpassa sig. Rudman talar i allmänhet om konsekvenserna av hoten. Dataläckage kan leda till att varumärken förlorar både integritet och immaterilla rättigheter. Gollmann skriver att den ökade användningen av komplexa program på webben markant har ökat antalet attacker mot webbplatser [6]. 6.1 Vad finns det för lösningsförslag? I denna delen av studien tar vi upp de förslag som finns för att motverka och mitigera de vanliga säkerhetshålen som finns. SQL Injektion (SQL Injection) När det kommer till SQL-injections föreslås ofta stored procedures som metod, men detta flyttar bara problemet till backend-servern. Förslaget är att istället använda prepared statements, det vill säga SQL-queries som byggs iförväg med placeholders istället för faktiskt data i webbplatskoden. Dessa placeholders byts sedan ut mot input. [6] En annan teknik är att validera inkommande data. Choukse et al.[3] föreslår att man ska kolla datan efter sådant som apostrofer och diverse nyckelord som används för SQL injection, men Gollmann hävdar att där finns problem med att använda denna typ av black list[6]. Gollmann påstår att det är svårt att få listor som täcker allt. Han föreslår dock att man kan encoda speciella tecken, t.ex genom att omvandla dem med HTML encoding. White listing fungerar bra i de fall då det finns tydliga strukturer i inputen som när den ska vara numerisk, eller som kan valideras med t.ex regular expressions.[6]. 16

17 Ser vi till OWASP så föreslås prepared statements, stored procedures och escaping. [2] Trasig autentisering och sessionshantering (Broken Authentication and Session Management) Session hijacking och Session fixation Skapa ett nytt sessions-id efter en lyckad inloggning, så att en användares sessions-id roteras och inte kan fixeras. Spara även undan användarens IP och annan användbar information som kan användas för att verifiera användaren. [3] För att minska risken för att sessionen stjäls ha en så kort session som möjligt, samt se till att sessionen tas bort vid utloggning. [20] OWASP förelår även att sessions-idt ska vara tillräckligt långt att det inte kan gissas eller testas fram, och av samma anledning ska den vara slumpmässig. [19] Cookie poisioning För att undvika att någon stjäl en användares cookie när den skickas så råder Choukse et al.[3] att man ska skicka denna krypterad via HTTPS (SSL). Cookie-filen bör heller inte vara tillgängliga via script så som JavaScript, genom att ange HTTPOnly-flaggan. [20] Cross-site Scripting (XSS) Det finns olika sätt att försvara sig mot XSS. Som med SQL injection såkan man använda sig av black list och white list, det vill säga att man kan ta bort alla definierat otillåtna tecken eller validerar input mot vad som godtas. Det är som nämnt svårt att få dessa att täcka allt. Escapea otillåtna tecken (lägg till en \(backslash) framför) och använd HTML-encoding av tecken (<blir <, >blir &rt;) [6]. Även OWASP föreslår detta. Riktlinjen är att santinera inkommande data från användaren genom att validera, oskadligöra och/eller ta bort delar av den. Kerschbaum [10] föreslår en mer strukturell lösning på problemet. Han delar upp sidorna i två typer: reguljära och inträdesidor och menar sedan på att all tillgång till reguljära sidor ska gå via inträdessidorna. Dessa i sin tur rensar bort all inkommande data från användaren så som URL-parametrar och liknande, så att dessa måste skapas via inträdessidorna. Man behöver då verifiera att HTTP Request till de reguljära sidorna kommer från just inträdessidorna. Gollmann påpekar dock att HTTP Referer inte alltid finns och kan förfalskas så denna metod är inte helt pålitlig[6] vilket Choukse et al[3] även nämner. Osäkra referenser till objekt (Insecure Direct Object Reference) OWASP föreslår här att man ska använda mapping av referenser. Istället för att använda samma nyckel som t.ex kan finnas i databasen så har man ett värde som sedan i koden omvandlas till den önskade nyckeln. Man bör också verifiera att användaren verkligen ska ha tillgång till objektet. [23] 17

18 Felkonfigurering av säkerheten (Security Misconfiguration) OWASP rekommenderar att alla miljöer man arbetar i ska vara identiska och snabba att sätta upp. Det bör dessutom finnas som vana att uppdatera all mjukvara och kodbibliotek för att minska risken för säkerhetshål. Man bör även ha en tydlig arkitetkur på projektet,så att komponenter har en tydlig och säker separering. Detta för att minska risken att felkonfigurering ikomponenterpåverkar övriga icke felaktiga komponenter. Exponering av känsliga uppgifter (Sensitive Data Exposure) OWASP föreslår att man bör hasha och kryptera känslig data, samt inte använda svaga algoritmer så som MD5 och SHA1. Man bör även se till att salta t.ex lösenord, där salta innebär att man skapar en sträng som läggs ihop med datan vid hashning av den. Detta för att undvika användning av så kallade rainbow tables. Man ska heller inte spara data längre än vad det är nödvändigt. Som förslag för själva sidorna som tar emot datan så bör man avaktivera saker som cashing och automatiskt komplettering av formulär (autocomplete). Missing Function Level Access Control Denna del inkluderar forced browsing. Choukse et al. rekommenderar att man undviker att använda vanliga namn för känsliga sidor, så somadmin. Cross-Site Request Forgery (CSRF) Siddiqui och Verma föreslår en rad olika saker för att mitigera CSRF, bland annat användning av random token.[18] Även Gollman[6] föreslår tokens, men beskriver det då somnågot som skapas av något som bara servern och klienten vet. Därför kan det skickas i klartext, eftersom att den bara går att använda det tillfället och valideras av servern när det kommer fram. Gollman föreslår att man kan skicka den både som GET-parameter såväl som en POST-parameter (i så fall i ett dolt fält), men Siddiqui och Verma rekommenderar att man hellre använder POST enbart, då man annars lätt ser alla parametrar i URL en. Gollman tar även upp ett annat exempel där en användare kan råka dela med sig av en länk som inkluderar parametrar och därmed av misstag skapa en säkerhetsrisk själv, i det fallet att tokens är återanvändbara. Ett annat förslag är att se till att hålla livslängden på cookies kort (för att fönstret för en attack ska vara så liten som möjligt).[18] Använda komponenter med kända sårbarheter (Using Components with Known Vulnerabilities) Det är svårt att hålla koll på sårbara komponenter enligt OWASP. Det gäller att hålla koll på vilka versioner man kör och övervaka mailinglistor, publika databaser och andra forum som kan innehålla information om en komponent är sårbar. Utöver det så bör man hålla komponenter uppdaterade. 18

19 7 Analys av undersökningsresultat 7.1 Utförande Undersökningen utformades på ettsådant sätt att den skulle ta kort tid att genomföra i hopp om att fler skulle vara villiga att ta sig tid att genomföra den. Eftersom att vårat syfte med undersökningen även var att ta reda på hur mycket deltagaren kunde om säkerhetshål och lösningar så var stora delar av den utformad som ett test med flera svarsalternativ. Testet består av tre delar: bakgrund och uppfattning, kunskap om hål och kunskap om lösningar. Vid bakgrund och uppfattning så ville vi dels ha reda på vilken typ av utbildning och erfarenhet deltagaren har samt vilken uppfattning deltagaren själv har om sina kunskaper. Delen som berör kunskap av hål utformades med målet att ta reda på omanvändaren hade kunskap om hålen genom att först fråga efter vilka koncept de kunde och sen ställa direkta frågor om dessa för att se om de faktiskt hade den kunskapen. Delen som berör kunskap om lösning på hålen ville vi helt enkelt se om de visste hur man täpper till de säkerhetshål som finns. Antal svarande Undersökningen har 37 svar som datan är framtagen på. Vi estimerar att vi har nått ut till ca 200 personer, vilket har gett oss en svarsfrekvens på ca18%.dettaharviåstakommit genom kontaktnät och forum. Det är via kontaktnät som svarsfrekvensen har varit störst, medan det gjorde ingen märkbar skillnad i antal svar efter publicering i ett forum för webbprogrammering. Där hade över 100 personer dock läst inlägget. Eftersom att vi främst har nått ut via egna kontaktnät nät har vi sett att svarsgruppen består mycket utav nuvarande eller tidigare BTH-studenter inom våran egna åldersgrupp. Men där finns även ca en tredjedel som har angett att det saknar utbildning eller där vi inte kan bedöma på vilket lärosäte den svarande har utbildat sig. Vi kommer därför inte direkt ha möjligheten att peka utifallbristikunskapskullevaraenföljd av avsaknad av säkerhetsutbildning för just BTHs utbildningar inom webb och säkerhet. 7.2 Insamlad data Bakgrund och uppfattning Ålder Majoriteten befann sig i gruppen år (62%), medan det inte fanns någon i de två grupper som är över 51 år (51-60 och 60+). Spridningen på de 3 övriga grupperna var jämn, med 4 i gruppen upp till 20 år, och 5 vardera för grupperna och Figur 10 i Appendix A 19

20 Utbildning Vi fick in fler svar från personer som har utbildning än personer som inte har det. 25 (68%) har utbildning och övriga 12 saknar. Utav de som i sin tur har svarat på vad de har gått för utbildning så är det främst webbutbildningar, datorsäkerhet (kandidat och civilingejörs), datasystemvetenskap och software enginering som vi ser är återkommande. Av de som har angett att de har utbildning (28st, se Brister angående varför detta inte stämmer med ovan antal på 25) så har strax över hälften av dessa (15st) en utbildning på 3år. 2 andra större grupper är utbildning på mindre än ett år (6st) samt utbildning på 4år (3st). Övriga grupper har 1 var. Figur 15 i Appendix A Erfarenhet 26 (70%) av 37 svarade att de har tidigare erfarenhet av webb eller säkerhet utanför skolan. Av dessa 26 så hade 16 angett att de har utbildning, medan 10st hade erfarenhet men utan utbildning bakom (inom ämnena). 11st (30%) saknar alltså tidgare arbetserfarenhet inom ämnena i fråga. Vid frågan om hur mycket erfarenhet deltagarna hade så vardet29som svarade (se Brister). 13 (45%) av dessa 29 hade under ett års erfarenhet, vilket gjorde det till den överlägset största gruppen. Den efterföljs av 1-2 år samt 5-10 år som vardera hade 5st (17%). En enstaka hade över 20 år. Figur 16 i Appendix A Svarsalternativ Antal Procent less than 1 year 13 45% 1 to 2 years 5 17% 3 to 5 years 2 7% 5-10 years 5 17% years 3 10% more than 20 years 1 3% Språkkunskap Nästan alla (33st, 89%) har kunskap om MySQL. Det följs utav PHP(81%), CSS(78%), HTML5(73%), JavaScript(70%) och CSS3(68%). Figur 17 i Appendix A Egen uppfattning om kunskap Många har en hög uppfattning om sina webbprogrammeringskunskaper, då 35% satte en 4a på en5-gradigskala(nybörjare till expert), och 30% satte en 3a. 11% satte en 5a (max) Figur 18 i Appendix A. Medelvärdet för alla svarande är 3,19. När det gäller säkerhet så var spridningen bland svaren jämnare. Det fanns ingen som valde en 5a. 2a och 4a hade vardera 30%, medan 1a och 3a hade 19% och 22% Figur 18 i Appendix A. Medelvärdet hamnade här lägre: 2,62. Kunskap om begrepp Mer än hälften anser sig känna till SQL Injections, XSS, Session hijacking och Buffer overflow. Resterande begrepp (Server-side includes injection, CSRF, Cookie poisoning, Forceful browsing och Session fixation) kände färre än hälften 20

21 till. Lägst var Session fixation där 6% svarade att de kände till begreppet. Högst antal fanns på SQL Injections som 91% känner till. Därefter kommer XSS som lite drygt 60% känner till. Majoriteten har svarat rätt på begreppför SQL Injections. Alla andra resultat gällande begrepp är sämre än resultatet på huruvidadeär bekanta med begreppen eller inte. Ihopslagna felaktiga svar och blanka svar visar att bara SQL Injections och Cookie poisoning hade antal rätt svar som översteg hälften, och bara SQL injections med god marginal. CSRF utmärker sig då straxöver hälften av de som påstod sig vara bekanta med begreppet svarade fel. Figur 1. Svarsfördelning gällande beskrivning av begrepp, fördelat över rätt, fel och inget svar. Vid jämförelse av kunskap mellan de som har en utbildning och de som inte har så ligger de med utbildningen högre procentuellt än de med utbildning på allt utom SQL injections. Detbästa resultatet är på SQL Injections där 84% med utbildning och 91% utan utbildning svarade rätt. Lägsta resultatet finner vi på Insecure direct object reference med 32% med utbildning och 8% utan utbildning. Även CSRF hamnar på 32% för de med utbildning. Skillnaderna är som minst på CSRF med 32% för de med utbildning och 25% för de utan och SQL Injections med redan nämnda 84% för de med utbildning och 91% för de utan. När det kommer till erfarenhet har vi valt att kolla på de utan erfarenhet, de med mindre än ett år och de med mer än ett års erfarenhet. På SQL injections och XSS ligger alla tre kategorier nära varandra. De två som följs närmast åt är de utan erfarenhet och de med mer än ett års erfarenhet som ligger nära varandra på alla utom CSRF där de med erfarenhet ligger på 43% jämfört med de utan erfarenhet på 20%. De med mindre än ett års erfarenhet utmärker sig och är betydligt bättre än övriga på Forceful browsing och Insecure direct object 21

22 Figur 2. Rätt svar med (blå) och utan (orange) utbildning. Uträknad andel baserar sig på antalrätt svar bland alla som har svarat inom de angiva grupperna (med och utan utbildning). reference, mensnäppet sämre på SQL Injections och Cookie poisoning. XSS och CSRF hamnar de ungefär samma som de två övriga kategorierna. Figur 3. Rätt svar med mindre än 1 års erfarenhet, mer än 1 års efarenhet, samt utan erfarenhet. Andel rätt svar bland alla som har svarat inom de angiva grupperna. 22

23 Kunskap om lösningar Alla frågor har minst 2 rätt alternativ av totalt 5 alternativ. Injection, XSS och sensitive data har 3 rätt svar. Procentvärden för varje person har räknats ut på totalt antal rätt svar mot maxvärdet om man har alla rätt. Vid ett felaktigt svar så har inga avdrag gjorts. Totalt antal rätt som går att ha på dessa frågor är 19. Videngränsdragning på 50% rätt på frågorna så ligger 58% av de svarande under gränsen och resterande 42% ligger alltså över den. Den som svarade bäst hade 17 av 19 rätt svar, och de två sämsta hade 1 av 19. Medelvärdet för alla svarande ligger på 8,06av19rätt (42% rätt). Alla svaren hade även ett Vet ej -alternativ. För frågorna gällande security misconfigurations, insecure direct object reference och forceful browsing såsvarade 50% med detta alterantiv. Endast för sensitive data så var det ingen som tog detta alterantiv. För injection så var det 8%. Resterande frågor hade alla mellan 30 och 40% som svarade att de inte visste hur man löser hålen. Figur 4 När det kommer till de som har svarat med något eller flera andra alternativ som har varit enbart fel så är siffrorna lägre. Security misconfigurations hade 0%. Session hijacking, XSS och forceful browsing hade vardera 3%. För resterande frågor var antalet större, mellan 11 till 15%. Figur 4 Övriga har haft minst 1 rätt. Figur 4. Svarsfördelning gällande lösningar, med vet ej (blå), enbart fel svar (orange) och minst 1 rätt (grå). 23

24 Vi har tagit fram antal som har haft minst 1, 2 och 3 (där det fallet gäller) rätt. Figur 5 Om man enbart ser till det antal som har haft minst 1 rätt så ligger frågorna gällande sensitive data (92%) och injection (81%) bäst till (många som kan minst 1 lösning). Insecure direct object reference samt forceful browsing ligger båda under 50% som har haft minst 1 rätt och ligger därmed sämst till. Övriga frågor har mellan 50 och 67%. Kollar vi på helhetensåstickerfrågan gällande sensitive data ut då hela72% har haft minst 2 rätt, och 44% har haft alla 3 rätt. CSRF samt Forceful browsing är de frågor som har under 10% (respektive 6 och 3%) där de svarande har haft alla 2 rätt. Insecure direct object reference som hade sämst resultat bland minst 1rätt hade 14% som hade alla 2 rätt. Övriga frågor ligger på ca 30-40% för minst 2 rätt. Figur 5. Svarsfördelning vid rätt svar gällande lösningar. Andel räknat på antalrätt svar gentemot alla svarande. Minst 1 rätt (blå), minst 2 rätt (orange) och minst 3 rätt (grå). Vidare så har vi tagit fram antal som har haft 1 rätt, 2 rätt och 3 rätt (där det fallet gäller) för samtliga frågor. Vi kan tydligt se att för frågorna gällande session hijacking, security misconfigurations och sensitive data så är antalen som har alla rätt större (mer än 10) än för resterande frågor (5 och under). Figur 7 Forced access och CSRF låg sämst till, där bara 1 repektive 2 av de svarande hade alla rätt (2 av 2). Figur 7 För de frågor där det finns 3 rätta svar så ser vi att för injection så är det majoriteten av de svarande som bara har haft 1 rätt (15st, 42%). Även vid XSS så är det majoriteten av de som har haft rätt som bara har haft 1 rätt (11st). Bara för sensitive data så var det minst antal som hade endast 1 rätt (7st). Figur 7 24

25 Figur 6. Total fördeling av svar för varje lösningsfråga. Här ser man även vet ej samt felsvar. 7.3 Analys Det är tydligt att den egna uppfattningen om kunskap gällande webbprogrammering är hög (de som svarat 3 eller 4) i de flesta fall, medan den är betydligt mer spridd när det gäller webbsäkerhet. Det går direkt se att ca hälften av de svarande själva upplever att de inte besitter stor kunskap inom webbsäkerhet (RQ2 ). Bland svarande för de som har utbildning inom webbprogrammering är förtroendet högre till deras egna programmeringskunskaper men de har max satt en 3a gällande kunskap inom webbsäkerhet. Detta ger en indikation på attsäkerhet inte får fokus inom denna typen av utbildning. Gällade bekanthet med begrepp kan vi se att för SQL injection såkänner de flesta av de svarande att de skulle kunna beskriva detta säkerhetshål. Nivån är rimlig även för XSS, session hijacking och buffer overflow, mengår under hälften för resterande begrepp. Vi ser alltså attdetråder osäkerhet kring begrepp som CSRF, cookie poisoning och session fixation. Svaren visar oss dock inte om man inte alls känner till begreppet, eller om man känner till det men inte är säker nog på att kunna beskriva det. Oavsett vilket fall så tyderdetpå att kunskapen inte är omfattande för många begrepp (RQ2 ). 25

26 När det gäller beskrivningarna av begrepp så är det endast SQL injection som har ett övergripande bra resultat, med många rätt svar och få blanka eller fel svar. I relation till bekanthet så stämmer den påstådda kunskapen gällande SQL injection väl överens med resultatet (lika många angav att de var bekanta med begreppet som de som svarade rätt på beskrivningen av begreppet), vilket visar att för denna fråga så är kunskapsbristen väldigt liten (RQ3 ) om man ser till själva begreppet. Bryter man ner det i utbildning och icke utbildning så är det bara är SQL injection som har ett bra resultat. Resterande ligger under 60%, där alla utom Cookie poisoning och XSS hamnar under hälften, vilket visar på en kunskapsbrist med eller utan utbildning. Gällande erfarenhet så ligger Cookie poisoning även här över 60% rätt antal svar om man ser till gruppen med erfarenhet över 1år. Utöver det är Cookie poisoning för de utan erfarenhet strax över 50% och Forceful browsing för de med mindre än ett års erfarenhet hamnar över 50%. Resterande är under hälften, vilket visar på en stor kunskapsbrist även här. Insecure direct object reference hamnar lågt oavsett utbildning och erfarenhet. Även CSRF hamnar lågt även om de med ett års erfarenhet svarar något bättre än övriga. Även när de gäller kunskap om lösningar så ligger SQL injection bland de säkerhetshål som mer än 80% har har minst 1 rätt svar på. Det är bara när det gäller 2 frågor (insecure direct object reference och forced access)där mindre än hälften har haft 1 rätt. För dessa två är andelen som har haft 2 rätt väldigt liten. Den fråga som de svarande presterade bäst på varsensitive data, där över 90% hade minst 1 rätt och över 40% hade alla 3 rätt, jämfört med injection där strax över 10% hade alla tre rätt (båda frågorna hade 3 av 5 svar som var korrekta). CSRF och forced access hörde till de frågorna där under 5% svarade med båda rätt, där båda dessa även hade under 50% som hade minst 1 rätt. Vi ser alltså en kunskapsbrist gällande dessa frågor särskilt, vilket vi alltså ocksåsåg gällade beskrivningen av CSRF där de som svarade rätt var den minsta andelen (30%) och de som svarade fel var störst (40%). Vi ser samma koppling till insecure direct object reference där resultatet gällande begreppen var snarlika till CSRF och som ovan nämnt så vardetden fråga som minst antal hade minst 1 rätt på gällande lösningar (under 40%). Om man även kollar de som har svara vet ej så syns samma trend. Insecure direct object reference, CSRF och forced access är de tre där flest antal har svarat med detta alternativ (17, 17 och 14) och förutom för CSRF så överstiger det antalet som har haft minst 1 rätt. 26

27 Dock så skadetnämnas att varken XSS, session hijacking eller security misconfigurations ligger långt efter i antalet, då alla dessa även har ett vet ej - antal på över 10 (av 37). Bara SQL injection och sensitive data har ett lågt eller inget antal (5 och under). Med och utan utbildning För att jämföra hur de som har utbildning svarar mot de som saknar det så tog vi fram hur många som hade minst 1 rätt för båda grupperna. Utifrån detta tog vi fram det procentuella värdet. Med en linjegraf så kan vi se att de utan utbildning ligger lägre i svarsfrekvens än de med utbildning för alla frågor utom för security misconfigurations och sensitive data, där samma andel har haft rätt i båda grupperna. Figur 7 Vi ser även via denna graf att skillnaderna i kunskap är störst för XSS och CSRF när det gäller hur de med och utan utbildning har svarat (en skillnad påca 25%), och att båda grupperna presterade sämst i frågan om insecure direct object reference. De utan utbildning presterade även dåligt gällande CSRF (under 40% med minst 1 rätt svar). Figur 7. Svarsfördelning baserat på utbildning, med eller utan. Procentuellt värde baserar sig på antalrätt av de som har svarat inom repektive grupp. Kollar man på varje individ så syns det att det finns undantag där ett antal med utbildning har fått sämre resultat (totalt antal rätt svar på lösningar), medan det även finns de som utan utbildning eller kort utbildning har svarat med bra resultat. Jämförelse mot erfarenhet Vid jämförelse för de som har haft minst 1 rätt svar gällande de utan erfarenhet, med erfarenhet under 1 år och med erfarenhet 1 år 27

28 eller mer så är fördelningen inte lika tydlig. För de med erfarenhet 1 år eller mer så ligger andelen rätt svar strax över de som har erfarenhet under 1 år. För de som saknar erfarenhet så ser vi att för injection, XSS och security misconfigurations så har de bättre svarsandel än de övriga grupperna, men ligger annars under eller tangerar de andra 2 grupperna. Figur 8 Skillnaderna gällande svarsprestation är inte avsevärtmycketstörre gällande specifika frågor, till skillnad från ovan jämförelse gällande utbildning. Det som dock nämnvärt sticker ut är linjen för de som saknar erfarenhet. Här ligger det både över och under de andra två grupperna. Men skillnaderna i de fall de ligger under som för forced access och CSRF är stora (20% skillnad). Den enda punkten där alla tre grupperna har svarat något så när lika är för sensitive data. Figur 8. Svarsfördelning baserat på erfarenhet, med 1 år eller mer, under 1 år eller utan. Procentuellt värde baserar sig på antalrätt av de som har svarat inom repektive grupp. Ser man till indviduell prestation gällande erfarenhet så ser vi ett par undantag till medelvärdena. Den svarande med över 20 års erfarenhet hade endast 2av19rätt. Även andra med mer än 10 års erfarenhet har haft sämre än medelvärdet med 4 respektive 5 rätt (fördelat på 2-3frågor). Figur 22 i Appendix A Vi har även räknat ihop antal års erfarenhet (tagit lägsta siffran i intervallen) med antal års utbildning och sammanställt det. Figur 23 i Appendix A 7.4 Brister Undersökningen kan ha flera brister. Vi har t.ex sett att 3 av 37 personer har fyllt i frågan om hur lång erfarenhet man har trots att de vid frågan innan 28

29 om de har erfarenhet har svarat nej. I dessa fall har vi antagit att de inte har någon erfarenhet, så att bara kombination av ett Ja-svar och antal år räknas som erfarenhet. 2 av 37 har fyllt i att de har utbildning inom något av ämnena men har inte fyllt i vad för utbildning. 3 av 37 har fyllt i att de inte har utbildning men har ändå svaratpåhurlång den var. I detta fall har vi antagit att de inte har någon utbildning bortsett från årsantalet. Brister med själva utformningen är problemet med flervalsfrågor. Vi har gett instruktion på attmanskahoppaöver en fråga om man inte kan den, eller har angett som alternativ Jag vet inte för att minska på risken att gissar på svaret. Dock kan de ha fyllt i ett svar för att de har missat denna instruktion eller gissar ändå. Figur 9 samt Figur 4 Figur 9. Andel blanka svar (blå) mot övriga svar (orange) vilket innefattar både rätt och fel svar. Dock så är det i så fallettstörre problem på delen som berör kunskap om hål där man bara får fylla i ett svar, vilket gör folk mer benägna att svara. Men kollar vi på antal tomma svar på vissa frågor så skulle vi kunna dra slutsatsen att detta inte är sant, då ett stort antal ändå lämnat blanka eller vet ej -svar. Problemet med detta blir att det i analysen ser ut som att fler faktiskt har kunskap om hålen än vad som är sant eftersom att de som har gissat rätt inkluderas. Vi har inte möjlighet att avgöra om det har skett. Utöver detta så var vi tvugna att tänka påhurlång/kort undersökning vi gjorde. Vi var medvetna om att vi kanske skulle få in mindre svar om undersökningen var för lång eftersom att alla inte är villiga att ta sig tiden att fylla i den då, samtidigt 29

30 som det även skulle ge oss mer data än vi hade hunnit med att analysera. Av dessa anledningar så tog vi bort delen med kodexempel som vi hade planerat att ha med, vilket i sin tur leder till att vi inte kan göra bedömningen huruvida de som svarat rätt på mitigeringsfrågorna också har kunskapen om hur man kodar dessa mitigeringar. Det är en sak att ha en uppfattning om vad lösningen är och en annan sak att implementera den. Det vi inte heller kan få fram med undersökningen är om de kan vara så att de i själva verket motverkar många av säkerhetshålen redan idag, men bara inte vet att de säkerhetshål de motverkar har dessa begrepp. Att de inte vet vad ett begrepp innebär och svarar fel på hur man mitigerar det behöver inte per automatik innebära att de lämnar dessa säkerhetshål öppna i de applikationer de bygger. Vi hade kunnat lösa detta genom de kodexempel vi hade tänkt, eller genom att inför frågan hur man mitigerar ett säkerhetshål först förklara vad begreppet innebär. Något mer som kan upplevas som ett problem är att det finns för en del attacker och hål flera olika begrepp, eller begrepp som omfattar flera olika hål. Det är möjligt att vi på grund av detta har missat personer som har kunskap om hål och attacker men inte via de begrepp vi har använt. Detta kan dock leda till diskussionen om att man borde ha en övergripande kunskap om begrepp och det är en kunskapbrist att inte ha det. Figur 10. Åldersfördelning bland de svarande. Efter att ha analyserat resultaten så kan vi också diskutera om våra svarsalternativ har varit utformade på bästa sätt. Exempelvis så fallerdeflestaini åldersgruppen år (Figur 10). Denna grupp kan innefatta både unga studenter som påbörjat sin utbildning och personer som varit ute i arbetslivet i många år. I efterhand så borde i alla fall denna gruppen ha delats upp i två alternativ. 30

31 Något som bör nämnas är att vi i efterhand inser att vi borde haft tydliga gränser för vad som är bra och dåligt resultat uppsatta redan från början, för att lättare kunna analysera resultaten och även kunna dra slutsatser baserat på vad vi faktiskt hade förväntat oss. Det finns ju dock en svårighet i hur man ska komma fram till vad som är rimliga gränser. 31

32 8 Diskussion Varierande kunskapsnivå. Vi såg tydligt att det finns begrepp och säkerhetshål bland de vi tog upp som kunskapen är låg inom, så somcsrf, forceful browsing, insecure direct object refernce och faktiskt även XSS. Samtidigt var kunskapen inom enstaka frågor större, främst för injection och sensitive data. Kunskapsnivån är alltså intelåg för alla frågor utan varierar snarare i viss utsträckning. Detta tillåter oss att dra slutsatsen att det för många frågor finns okunskap, men att nivån på den varierar. Att vi har begrepp som sticker ut där kunskapen är bättre kan bero på att fokus har lagts på dessa, i utbildning och även i litteratur och medier. Framförallt har vi själva sett att SQL injection har varit en av säkerhetshålen som har fått mycket plats i litteraturen vi har studerat. Figur 11. Svarsfördelning för minst 1, 2 och 3 antal rätt i procent Bra grundläggande kunskap - ej bred kunskap. Baserat på resultaten för begrepp och lösningar såkanviianalysenäven se att även om det finns en grundläggande kunskap om många av begreppen så är det ett litet antal som faktiskt kan ange hur man mitigerar säkerhetshål på merän ett sätt. Främst har vi sett att det gäller för CSRF, forced access, XSS och insecure direct object reference. Ett bra exempel är just XSS där ändå ett rimligt antal kunde begreppet (ca hälften) men bara ett fåtal (4 st) hade alla rätt gällande lösningar. Figur 12 Det är viktigt att veta om flera alternativ till lösningar för att mitigera hålen fullständigt (det kan behövas en kombination för att motverka riskerna helt) eller för att välja ut rätt lösning fördenkodmanhar(allalösningar kan nödvändigtvis inte appliceras på enskod-manbehöver veta om flera olika alternativ). Att det finns en brist i denna bredare kunskap kan leda till att hål 32

33 kvarstår i viss utsträckning för att utvecklarna inte har haft rätt kunskap att applicera på sinkod. Säkerhetsrisker med överlag låg kunskap. Ser vi till CSRF så kan vi se en överlag låg nivå både gällande kunskap om begreppet och kunskap om lösningar (Figur 12). En väldigt stor andel hade fel gällande vad begreppet beskriver, och bara hälften hade 1 rätt på lösningarna. Vi kan alltså här peka ut att det råder okunskap kring CSRF, vare sig det är på grund av otydligheter i skillnaderna till XSS eller allmän okunskap. Även insecure direct object reference är ett säkerhetshål som har få rätt svar och många felsvar eller vet ej. När det gäller Forced access & forceful browsing så ser vi att det finns de som har svarat rätt, men en lika stor eller större andel som heller inte vet svaren. För XSS är det lite bättre ställt, i alla fall om man ser till de som har haft 1 rätt eller mer, men vi ser även här både ett större antal som inte vet eller har svarat fel. Det gör oss ännu mer säkra på att okunskap faktiskt råder i en större omfattning. Figur 12. Svarsfördelning över begrepp och lösningar sammantaget. För begrepp: Rätt svar (grön), inget svar (orange) och fel svar (röd). För lösningar: Antal alla rätt (mörk grön), alla rätt -1 (grön), alla rätt -2 (ljus grön), vet ej (orange), fel (röd). Många som svarat vet ej eller inte svarat alls. Vi sågatt det fannsflerasäkerhetshål som de svarande erkände själva att de inte kunde något (Figur 12) om vilket visar på att de svarande i omfattningen av våran undersökning även själva är medvetna om sin egen okunskap. Däremot så kanmanhär diskutera om det gäller själva begreppen enbart där de vet om ett säkerhetshål men inte har ett namn fördet,elleromdeinteharnågon kunskap alls. Men baserat på attvi hade flervalsfrågor i undersökningen där man kan koppla sin kunskap till något svarsalternativ kan vi anta att den erkända okunskapen beror på att de helt enkelt inte vet om detta säkerhetshål alls. Till denna gruppen behöver vi också 33

34 inkludera de som kanske har en mindre uppfattning om vad begreppet står för men inte är säkra nog på sinaegnakunskaperför att vilja svara på frågorna, och har valt att inte göra det istället. Okunskapen i sig kan sedan bero på att svarande tycker sig inte behöva veta om dessa och andra säkerhetshål, och kanske av den anledningen inte har känt behovet av att lära sig, eller att de helt enkelt inte har fått en medvetenhet kring att dessa finns. Vi anser att utbildning både på högskolan och arbetsplatsen kan hjälpa att skapa medvetenhet och intresse så att utvecklarna själva kan jobba påettsådant sätt att hålen motverkas. Detta i kombination med att de svarande har bedömt sin egen kunskap inom webbsäkerhet överlag lägre än webbprogrammering (Figur 18 i Appendix A visar att utvecklarna inte i någon större utsträckning uppfattar att de besitter mer kunskap än vad de faktiskt har. Utbildning och svar. Vi har även sett att man oavsett om man har utbildning eller inte har svarat med låga antal rätt för samma begrepp, även om de med utbildning i de alla flesta fallen har svarat snäppet men inte markant bättre. För de frågor där skillnaden är större ser vi just de frågor som redan är nämnda som problemfrågor där kunskapen är låg: XSS och CSRF. Våran undersökning visar att man drar ändå nytta av att ha en utbildning för grundläggande kunskap höjs inom frågor där okunskapen verkar vara mer utbredd, men även för övriga frågor. Figur 13. Fördelning med utbildning och utan både för begrepp och lösningar. Erfarenhet och svar. Mer intressant var när vi tog fram kunskap baserat på hur mycket erfarenhet man har. Här är det inte en lika tydlig skillnad som för jämförelsen vid utbildning, utan det finns frågor där man med mycket erfarenhet klarar sig sämre än både de med lite erfarenhet eller ingen alls. Vi hade innan undersökningen förväntat oss att de som hade mer erfarenhet även skulle svara bättre, men vi har alltså istället sett att detta inte genomgående är fallet. Men tar man åter igen CSRF som ett exmpel så har vi sett att det med erfarenhet har svarat överlag mycket bättre än de som helt saknar det. Vi kan alltså inte 34

35 dra slutsatsen att erfarenhet alltid ökar ens kunskap inom webbsäkerhet, men det är i många fall bättre än att inte ha det alls. Figur 14. Fördelning med erfarnehet och utan både för begrepp och lösningar. 35

36 9 Slutsats Grundläggande kunskap för begrepp och lösning finns men varierar sig mellan de olika begreppen. Det är tydligt att det för de allra flesta begrepp saknas mer omfattande kunskap gällande lösningar, då de svarande antingen i majoritet inte har vetat om lösningen alls eller bara haft 1 av 2 eller 3 rätt. Vi kan alltså se att brister inom kunskapen finns, även om det inte var i den omfattning vi förväntade oss gällande samtliga frågor. Det saknas omfattande kunskap om begrepp för alla de begrepp vi tog upp, förutom för injection. Detta visar att injection har i någon form fått större fokus än resterande begrepp, och kunskapen är överlag inte lika stor gällande samtliga vanliga säkerhetshål. En majoritet har också svarat att de har kunskap i MySQL, vilket kan förklara varför just den ligger bättre till än övriga. Ytterligare en bidragande faktor är att den får stor fokus i litteratur. Vi har kunnat se att om man har utbildning såharmansvaratbättre gällande kunskapen än om man saknar utbildning, även om skillnaden inte är så markant. Detta har gett oss en indikation på att man via sin utbildning får en grundläggande men ej omfattande kunskap gällande säkerhetshål. Vi kan se att erfarenhet inte spelar någon nämnvärd roll i ens kunskap, även om det överlag ger något bättre kunskap på deflestaområde än ingen erfarenhet alls. Osäkerheten kring säkerhetshålen och dess lösningar är stor, då vi har sett en stor andel blanka samt vet ej -svar, vilket även frågan gällande ens egen uppfattning om webbsäkerhet gav en indikation på. Slutsatsen vi kan dra här att även om det finns grundläggande kunskap så råder det även osäkerhet kring ens kunskap. Dock kan man se att de verkar medvetna om detta själva då dehar satt längre gällande sin egen uppfattning om vad det kan om webbsäkerhet än om webbprogrammering. Vi har dock svårt att jämföra vårat resultat av undersökningen med andra publikationer då vi inte har hittat några arbeten gällande kunskapsnivån i sig, utan snarare endast gällande själva säkerhetshålen. Sådanna arbeten skulle i sig heller inte direkt vara jämförbara med vårat då det troligtvis inte har genomförts inom samma geografiska område (Sverige) där vi är verksamma och riktar oss främst till. Vårat arbete placerar sig främst i åldersgruppen år med utvecklare både med och utan både erfarnehet och utbildning, där majoriteten är verksamma i södra Sverige. Vårat arbete går att använda för att motivera vidare kunskapstester inom mer specifika områden, både på skolorochföretag, för att få en tydligare bild över hur det ser ut just där. På såsätt kan man arbeta på de punkter som är viktigast, då detmöjligtvis ser olika ut beroende på t.exvad man har för utbildningsbakgrund eller erfarenheter. Vad gäller lösningar så gick litteraturstudien främst ut på att ge oss en kunskapsbakgrund att bygga undersökningen på. Vi har genom den också sammanfattat säkerhetshål och lösningar inte bara via OWASP, men också detvihar hittat i annan litteratur, vilket till stor del har bekräftat validiteten av OWASP s 36

37 Top 10. Till skillnad från andra arbeten så tarvårat upp fler säkerhetshål, dock mer sammanfattande än djupgående. 10 Framtida arbete Vi hade gärna viljat se om olika utbildningar resulterade i olika kunskapsnivåer. Tyvärr så hade vi dels inte data nog för att kunna ta ut detta (bara ett fåtal som hade samma utbildning) och dels så hadeintevåran utformning av undersökningen underlättat i det arbetet eftersom de svarande tilläts att själva skriva in namnet på sin utbildning. Vi märkte snabbt att många hade angett olika namn för samma utbildning eller typ av utbildning. Tyvärr hann vi heller inte granska ingående de svar som var utförligare (då man tilläts att skriva i även egna svar vilket ett fåtal valde att göra). Vi hade i detfalletbehövt granska deras föreslagna lösningar för att sedan bedömma om det var korrekt eller inte, vilket dessutom hade gett oss andra värden för antal rätt och fel svar. Tanken med att tillåtna öppna svar utöver de angivna svaren var att de svarande som hade större och bredare kunskap skulle kunna visa på denna. Vi har inte heller granskat kunskapsnivån i de olika åldersgrupperna, då vi i efterhand insett att den åldersgrupp som är mest dominant borde ha delats upp i 2 alternativ istället för ett enda. Vi har inte avsevärt mycket data gällande övriga grupper för att kunna göra någon relevant bedömning. Vi hade även viljat göra en jämförelse mellan uppfattad kunskapsnivå(frågorna med skala 1-5) och faktiska resultat, men detta hanns inte med. Som nämnt i brister hade vi även viljat haft möjligheten att på enstörre grupp människor granska igenkänningen av kodexempel som relaterade till säkerhetshål, en del som vi för att göra undersökningen mer attraktiv att göra valde att ta bort. Det hade eventuellt kunnat gett oss en större insikt i vilken kunskap de svarande besitter när det gäller själva kodningen av hål och lösningar, jämfört med det vi har i nuläget som tar upp begrepp och endast lösningsförslag. Något som möjligtvis hade kunnat hjälpa oss att förstå resultaten hade varit om vi hade granskat vad de som svarade fel hade valt för alternativ - för att få en uppfattning om vi antingen har varit otydliga i våra svarsalternativ eller om det faktiskt råder missförstånd kring vanliga begrepp (t.ex CSRF ). 37

38 Litteraturförteckning [1] Security incident update. security-incident-update/, April [2] Sql injection prevention cheat sheet. SQL_Injection_Prevention_Cheat_Sheet, April [3] Dharmendra Choukse, Dimitris N Kanellopoulos, and Umesh Kumar Singh. Developing secure web applications. International Journal of Internet Technology and Secured Transactions, 4(2): , [4] Jim Finkle. Trove of adobe user data found on web after breach. us-adobe-cyberattack-idusbre9a61d ?irpc=932, Nov [5] John Gantz and David Reinsel. The digital universe in 2020: Big data, bigger digital shadows, and biggest growth in the far east. Technical report, Technical report, IDC, [6] Dieter Gollmann. Securing web applications. Information Security Technical Report, 13(1):1 9, [7] Michael Jenselius. Dustin sparar kundernas lösenord - i klartext. dustin-sparar-kundernas-losenord---i-klartext, Nov [8] Nishta Kanal. Twitter hacked, nearly 250,000 accounts may have been compromised. twitter-hacked-nearly accounts-may-have-been-compromised/ 7, feb [9] John Kennedy. Microsoft confirms it is the latest tech giant to suffer cyber attacks microsoft-confirms-it-is/, Feb [10] Florian Kerschbaum. Simple cross-site attack prevention. In Security and Privacy in Communications Networks and the Workshops, Secure- Comm Third International Conference on, pages IEEE, [11] Mitja Kolsek. Session fixation vulnerability in web-based applications [12] David Kravets. Face.com app allowed facebook, twitter account hijacking. klik-app-vulnerability/, jun [13] Mohamad Ibrahim Ladan. Web services: security challenges. In Internet Security (WorldCIS), 2011 World Congress on, pages IEEE, [14] Kevin Ooulsen. Sony hit yet again; consumer passwords exposed. http: // Feb [15] Ian Paul. Update: Linkedin confirms account passwords hacked. http: //bit.ly/utj1w7, Jun [16] Riaan J Rudman. Incremental risks in web 2.0 applications. Electronic Library, The, 28(2): , 2010.

39 [17] Bruce Schneier. Beyond fear: Thinking sensibly about security in an uncertain world. Springer, [18] Mohd. Shadab Siddiqui and Deepanker Verma. Cross site request forgery: A common web application weakness IEEE 3rd International Conference on Communication Software and Networks, ICCSN 2011, pages , [19] Raul Siles. Session management cheat sheet. index.php/session_management_cheat_sheet, April [20] CA Vlsaggio and Lorenzo Convertito Blasio. Session management vulnerabilities in today s web. Security & Privacy, IEEE, 8(5):48 56, [21] David Watson. The evolution of web application attacks. Network Security, 2007(11):7 12, [22] David Watson. Web application attacks. Network Security, 2007(10):10 14, [23] Dave Wichers. Owasp top OWASP Foundation, February, [24] Kim Zetter. Report: Half a million yahoo user accounts exposed in breach. Dec

40 11 Glossary exabyte Exabyte är en informationsenhet som motsvarar en miljard gigabyte. phishing Phishing, eller nätfiske, är en olaglig metod att lura till sig kreditkortnummer, lösenord och liknande från personer, oftast via epost där man utgör sig för att vara mottagarens bank eller dylikt och ber de klicka på en länk och logga in, och på så vis få tagianvändarens bankuppgifter. användare Ivårat sammahang är en användare den som besöker webbplatser och utnyttjar dess tjänster. salt Salt innebär att man skapar en sträng som läggs ihop med datan, till exempel ett lösenord, för att göra det svårare att lista ut den riktiga datan. token En token indikerar att du är tillåten att vara där du är och göra det du gör. De är också oftabegränsadeitid,ettvisstantalanvändningar eller endast i vissa områen. interpretatorn En interpretator är en sorts tolk som läser in och exekverar källkoden. stack trace En stack trace visar call stack, dvs historiken för hur exekveringen nått fram till en metod. stored procedures En lagrad procedur, vilket kan förenklas till en sparad funktion i SQL. placeholders Platshållare, används i vårat sammanhang för att hålla en plats åt input. Placeholders byts sen alltså ut mot i kod angiven input. encoding Innebär att förvandla något till kod, i detta fallet kod som sedan tolkas om till ett tecken. escaping Innebär att markera tecken så attdeläses som text och inte t.ex programkod. regular expressions Regular expressions eller reguljära uttryck är en sträng som motsvarar ett sökmönster. Ett sätt att kolla att en sträng följer ett visst mönster, till exempel att kolla om en sträng ser ut som en mailadress. rainbow tables Innehåller ett värde och dess hash, och används för att ta fram lösenord från en given hash. cashing Innebär att temporärt spara senast eller ofta använd data, för att snabbare kunna hämta det på nytt. GET Det vanligaste HTTP-kommandot, vilket innebär att klienten ber servern att skicka en viss fil. POST HTTP-kommando där klienten sänder information till servern. HTTP HTTP står för Hypertext Transfer Protocol och är det protokoll som används för att visa webbsidor. BTH Akronym för Blekinge Tekniska Högskola. 40

41 12 Appendix A 12.1 Website security survey 41

42

43

44

45

46

47 12.2 Svar på surveyn 47

48 Timestamp Age Do you have an education in web development or other relevant subjects? If you have an education: Name your education(s) If you have an education: How long was it? Do you have previous experience in web development? :20: Yes Webbprogrammering 4 years No :29: Yes Webdevelopment 3 years No :39: No Yes :41: Yes itsäk 3 years Yes :26: Yes Bachelor degree in WIP 3 years Yes :18: Yes Software Engineering 3 years Yes :53: No Yes :54: Yes dsv 3 years Yes :58: Yes Computer Science IT Security 3 years No :01: Yes 5 years Yes :04: Yes IT security 3 years Yes :15: Yes systemarkitektursutbildningen 3 years Yes Game programming, but only some :18: Yes courses includes the above. Less than 1 year No :56:06-20 Yes Web programming 1 year Yes :12: Yes Civ.Ing. Datorsäkerhet 3 years No :13: Yes Webb design Less than 1 year Yes :24: Yes Webb, internet och programvaruteknik 3 years Yes :06: Yes Data och systemvetenskap 3 years Yes :17: Yes software enginering 3 years Yes :54: Yes security engeenering 3 years Yes :57: Yes Pågående kandidaturbildning i programmering 2 years No :48: No Yes

49 :17: No Yes :15:58-20 No Less than 1 year Yes :02: No Selfeducated 6 or more years Yes :44:18-20 No No :30: Yes Less than 1 year No :44: No Less than 1 year Yes :19: Yes Bachelor of Computer Science at Blekinge Institute of Technology 3 years Yes :28: Yes Webprogramming 3 years Yes :16:28-20 No No :02: Yes Less than 1 year Yes :19: No Yes :58: No Yes :32: No Yes :54: Yes software engineering 4 years No :49: Yes Software engineering 4 years No

50 If you have experience, how much? What languages/solutions are you familiar with? How would you How would you grade grade your your knowledge of webprogramming? knowledge of web security? less than 1 year less than 1 year 5-10 years PHP, HTML5, CSS, CSS3, MySQL, SQLite, MSSQL, JavaScript, AJAX, jquery, node.js 4 3 PHP, HTML5, CSS, CSS3, MySQL, SQLite, Ruby, JavaScript, AJAX, jquery, node.js, Mongo, 4 2 HTML5, CSS, CSS3, MySQL, MSSQL, ASP, Java,.NET, JavaScript, AJAX, jquery, node.js 4 2 less than 1 year PHP, HTML5, XHTML, CSS, CSS3, MySQL, SQLite, Java, Python to 2 years years PHP, XHTML, CSS, CSS3, MySQL, SQLite, Ruby, JavaScript, AJAX, jquery, node.js 4 3 PHP, HTML5, XHTML, CSS, CSS3, MySQL, SQLite, MSSQL, Python, JavaScript, AJAX, jquery, node.js 5 4 less than 1 year PHP, MySQL, Perl years PHP, HTML5, XHTML, CSS, CSS3, MySQL, SQLite, MSSQL, Java, Python, Ruby,.NET, JavaScript, AJAX, jquery, node.js 4 2 MySQL, Python, C, C++, shellscript 1 3 less than 1 year PHP, CSS, MySQL, SQLite, Java, Python 3 4 less than 1 year PHP, MySQL, Perl, Python, Ruby 1 4 less than 1 year HTML5, MySQL, Java,.NET, JavaScript, AJAX, jquery, node.js, C/C MySQL, Java, Python years PHP, HTML5, CSS, CSS3, MySQL, SQLite, JavaScript, AJAX, jquery, node.js 5 3 PHP, HTML5, CSS, CSS3, MySQL, Java, Python, JavaScript, LESS 3 4 less than 1 year PHP, XHTML, MySQL, MSSQL, Java 3 1 less than 1 year less than 1 year 1 to 2 years 1 to 2 years PHP, HTML5, XHTML, CSS, CSS3, MySQL, SQLite, MSSQL, Java, JavaScript, AJAX, jquery 3 1 PHP, HTML5, XHTML, CSS, CSS3, MySQL, Java, JavaScript, AJAX, jquery 3 3 PHP, HTML5, XHTML, CSS, CSS3, MySQL, SQLite, Java, Python, Ruby, JavaScript, AJAX, jquery, node.js 4 3 PHP, HTML5, XHTML, CSS, MySQL, SQLite, Java, Python, JavaScript, AJAX, jquery, node.js, angular 4 4 PHP, HTML5, CSS, CSS3, MySQL, SQLite, Java, Python, Ruby, JavaScript, AJAX, jquery, node.js years PHP, HTML5, XHTML, CSS, CSS3, MySQL, SQLite, MSSQL, Python,.NET, JavaScript, AJAX, jquery, node.js, Heh, AJAX, jquery, note.js och JavaScript ÄR samma sak damnit.. 5 4

51 3 to 5 years PHP, HTML5, XHTML, CSS, CSS3, MySQL, SQLite, Java,.NET, JavaScript, AJAX, jquery, node.js to 2 years PHP, HTML5, CSS, wordpress 3 2 more than 20 years MSSQL 1 1 PHP, HTML5, CSS, CSS3, MySQL, SQLite, Java,.NET 3 2 PHP, HTML5, CSS3, MySQL, SQLite to 5 years 1 to 2 years less than 1 year PHP, HTML5, XHTML, CSS, CSS3, MySQL, SQLite, MSSQL,.NET, JavaScript, AJAX, jquery, node.js 4 4 HTML5, XHTML, CSS, CSS3, MySQL, MSSQL, Java, Ruby, JavaScript, AJAX, jquery, node.js 4 2 PHP, HTML5, XHTML, CSS, CSS3, MySQL, SQLite, MSSQL, Java, Python, JavaScript, AJAX, jquery, Django 4 2 PHP, HTML5, XHTML, CSS, CSS3, MySQL, JavaScript, AJAX, jquery years less than 1 year years 5-10 years HTML5, XHTML, CSS, CSS3, MSSQL,.NET, JavaScript, AJAX, jquery, node.js 4 2 PHP, HTML5, CSS, CSS3, SQLite, Ruby, JavaScript, AJAX, jquery 3 2 PHP, HTML5, XHTML, CSS, CSS3, MySQL, MSSQL,.NET, JavaScript, AJAX, jquery, node.js 4 3 PHP, HTML5, XHTML, CSS, CSS3, MySQL, SQLite, Ruby, JavaScript, AJAX, jquery 5 4 PHP, CSS, MySQL, Java, Perl, Python, JavaScript 2 4 less than 1 year PHP, CSS, MySQL, Java, Perl, JavaScript 2 4

52 Which of these concepts do you feel familiar with? SQL injection, XSS, Forceful browsing, Buffer overflow SQL injection, Session hijacking, Buffer overflow SQL injection, Server-side includes injection An SQL injection can be describes as... Cookie poisoning is... Adding SQL-code to user input in order to retrieve, change or delete database Modifying a cookie file in order to gain entries elevated access Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding code to cookie file so that it installs malware SQL injection, Cookie poisoning, XSS, CSRF, Forceful browsing, Session hijacking, Session fixation, Server-side includes injection, Buffer overflow SQL injection, XSS, CSRF, Session hijacking SQL injection, XSS, CSRF, Session hijacking, Server-side includes injection, Buffer overflow SQL injection SQL injection, XSS XSS, Forceful browsing, Buffer overflow SQL injection, Cookie poisoning, XSS, CSRF, Session hijacking, Server-side includes injection, Buffer overflow SQL injection, Cookie poisoning, XSS, CSRF, Forceful browsing, Session hijacking, Session fixation, Server-side includes injection, Buffer overflow SQL injection, Cookie poisoning, XSS, CSRF, Forceful browsing, Buffer overflow All of the above Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Opt#2 and Opt#3, but mostly #3. Poisoning doesn't imply usefulness. Modifying a cookie file in order to gain elevated access Modifying a cookie file in order to gain elevated access Modifying a cookie file in order to gain elevated access Modifying a cookie file in order to gain elevated access Modifying a cookie file in order to gain elevated access Modifying a cookie file in order to gain elevated access SQL injection, XSS, Session hijacking, Server-side includes injection, Buffer overflow SQL injection, Cookie poisoning, XSS, Session hijacking, Server-side includes injection, Buffer overflow SQL injection Changing SQL queries in the site to run malicious code Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Modifying a cookie file in order to gain elevated access Modifying a cookie file in order to gain elevated access Adding code to cookie file so that it installs malware Modifying a cookie file in order to gain elevated access Cookie poisoning, Session hijacking Adding SQL-code to user input in order SQL injection, Cookie poisoning, XSS, CSRF, Buffer to retrieve, change or delete database overflow entries SQL injection, Cookie poisoning, XSS, CSRF, Adding SQL-code to user input in order Session hijacking, Session fixation, Server-side to retrieve, change or delete database includes injection, Buffer overflow entries Adding code to cookie file so that it installs malware Modifying a cookie file in order to gain elevated access Modifying a cookie file in order to gain elevated access SQL injection, XSS, Session hijacking, Session fixation, Server-side includes injection Adding SQL-code to user input in order to retrieve, change or delete database entries Adding code to cookie file so that it installs malware SQL injection, Cookie poisoning, XSS, CSRF, Forceful browsing, Session hijacking, Session fixation, Server-side includes injection, Buffer overflow Adding SQL-code to user input in order to retrieve, change or delete database entries The first answer is party true, but is not limited to elevated access. The level of access can be the same but under another identity which is the root threat with cookie poisoning attacks.

53 SQL injection, XSS, CSRF, Forceful browsing, Session hijacking, Server-side includes injection, Buffer overflow SQL injection, XSS, Session hijacking SQL injection SQL injection, Server-side includes injection SQL injection SQL injection, Cookie poisoning, XSS, CSRF, Forceful browsing, Session hijacking, Session fixation, Server-side includes injection, Buffer overflow SQL injection, XSS, Session hijacking, Buffer overflow SQL injection, XSS SQL injection, Cookie poisoning, Session hijacking SQL injection, Server-side includes injection CSRF SQL injection, XSS, CSRF SQL injection, Cookie poisoning, XSS, Session hijacking, Buffer overflow SQL injection, Cookie poisoning, XSS, CSRF, Session hijacking, Server-side includes injection, Buffer overflow SQL injection, Cookie poisoning, XSS, CSRF, Session hijacking, Server-side includes injection, Buffer overflow Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Changing SQL queries in the site to run malicious code Adding SQL-code to user input in order to retrieve, change or delete database entries Adding SQL-code to user input in order to retrieve, change or delete database entries Modifying a cookie file in order to gain elevated access Modifying content of cookies so that it is rendered useless Modifying a cookie file in order to gain elevated access Modifying a cookie file in order to gain elevated access Adding code to cookie file so that it installs malware Modifying a cookie file in order to gain elevated access Adding code to cookie file so that it installs malware Modifying a cookie file in order to gain elevated access Modifying a cookie file in order to gain elevated access Modifying a cookie file in order to gain elevated access

54 XSS-attacks occur when... CSRF-attacks occur when... Insecure direct object reference is when you can... Scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious code is executed at a website by an unsuspecting authorized user Change a parameter to access an object you're not authorized to see Malicious code is executed at a website by a tricked and unsuspecting authorized user Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Change a parameter to access an object you're not authorized to see Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious code is executed at a website by a tricked and unsuspecting authorized user Malicious code is executed at a website by a tricked and unsuspecting authorized user Malicious code is executed at a website by a tricked and unsuspecting authorized user Change a parameter to access an object you're not authorized to see Link directly to an object that is hidden Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Modifying a script file in order to gain elevated access Modifying a script file in order to gain elevated access Modifying a script file in order to gain elevated access Access the private functions of an object as if they were public Access the private functions of an object as if they were public Change a parameter to access an object you're not authorized to see Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Executing forged requests using stolen content (such as session ids) a website trusts. Malicious code is executed at a website by a tricked and unsuspecting authorized user Change a parameter to access an object you're not authorized to see Change a parameter to access an object you're not authorized to see Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious code is executed at a website by a tricked and unsuspecting authorized user Change a parameter to access an object you're not authorized to see No idea. Server side script code is changed to load external malicious resources that installs malware Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious code is executed at a website by a tricked and unsuspecting authorized user Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Change a parameter to access an object you're not authorized to see Access the private functions of an object as if they were public Server side script code is changed to load external malicious resources that installs malware Modifying a script file in order to gain elevated access Change a parameter to access an object you're not authorized to see A script loaded from an external resource gaining additional features not present in the original page. more often than not these do not install malware but track your movement on Much like XSS but CSRF uses the trust the web or try to retrieve your input. between a site has for a users browser. Note sure if this was mentioned in the list above.. Anyway, this is a attack where the attacker gain access to a function or object by modifying data (parameters etc) in order to gain previously hidden functionality or information.

55 Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Server side script code is changed to load external malicious resources that installs malware Malicious code is executed at a website by a tricked and unsuspecting authorized user Malicious code is executed at a website by a tricked and unsuspecting authorized user Modifying a script file in order to gain elevated access Access the private functions of an object as if they were public Link directly to an object that is hidden Malicious code is executed at a website by a tricked and unsuspecting authorized user Server side script code is changed to load external malicious resources that installs malware Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Access the private functions of an object as if they were public Server side script code is changed to load external malicious resources that installs malware Malicious code is executed at a website by a tricked and unsuspecting authorized user Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious scripts are posted on a trusted site that are then viewed by a user and run on a client Malicious code is executed at a website by a tricked and unsuspecting authorized user Modifying a script file in order to gain elevated access - Malicious code is executed at a website by a tricked and unsuspecting authorized user Access the private functions of an object as if they were public Access the private functions of an object as if they were public Link directly to an object that is hidden

56 Forceful browsing is to... How do you prevent injection? How do you prevent session hijacking? Find resources that are not linked on a page but still accessible White list input, Remove all special characters, Only use prepared statements Name sessions, Use random or other types of unpredictable session ID's Force a browser to load another malicous website instead of the intended Remove all special characters Use binary in-memory parameters for all SQL queries Only use SSL Only use SSL Find resources that are not linked on a page but still accessible Only use prepared statements, Sanitize input and output data Only use SSL, Use unpredictable session ID's Find resources that are not linked on a page but still accessible Trick a user to visit a malicious copy of the intended page White list input, Remove all special characters, Only use prepared statements Use unpredictable session ID's White list input, Only use POST, Remove all special characters, Only use prepared statements, Only use SSL, Use shorter session ID's, add Only use saved hardcoded queries browser/ip-info to session Find resources that are not linked on a page but still accessible Find resources that are not linked on a page but still accessible Remove all special characters, Only use prepared statements, Only use saved hardcoded queries White list input, Remove all special characters, Only use prepared statements White list input, Only use prepared statements, Only use saved hardcoded queries Only use SSL, Use unpredictable session ID's Only use SSL, Use unpredictable session ID's Find resources that are not linked on a page but still accessible White list input, Only use prepared statements Use unpredictable session ID's Find resources that are not linked on a page but still accessible Only use prepared statements, Encode all special characters Only use SSL, Bind session to IP, Make session cookies HTTPOnly, Make sure logout button kills sessions and not just removes cookie. Find resources that are not linked on a page but still accessible Remove all special characters Use unpredictable session ID's Force a browser to load another malicous website instead of the intended Only use prepared statements, Only use saved hardcoded queries Remove all special characters, Only use prepared statements Only use SSL, Use unpredictable session ID's Only use SSL, Name sessions, Use unpredictable session ID's Trick a user to visit a malicious copy of the intended page Remove all special characters, Only use prepared statements Name sessions Only use POST Use unpredictable session ID's Find resources that are not linked on a page but still accessible Only use prepared statements Use unpredictable session ID's Force a browser to load another malicous website instead of the intended Only use POST, Remove all special characters, Only use prepared statements Name sessions, Use unpredictable session ID's Find resources that are not linked on a page but still accessible Remove all special characters Only use SSL, Name sessions, Use unpredictable session ID's Find resources that are not linked on a page but still accessible White list input, Only use saved hardcoded queries Only use SSL, Use unpredictable session ID's

57 Find resources that are not linked on a page but still accessible Only use prepared statements Only use SSL Force a browser to load another malicous website instead of the intended White list input, Remove all special characters Trick a user to visit a malicious copy of the intended page Only use prepared statements Only use prepared statements Find resources that are not linked on a page but still accessible Only use prepared statements Only use SSL Only use saved hardcoded queries Find resources that are not linked on a page but still accessible Only use prepared statements Remove all special characters, Only use prepared statements Only use POST, Remove all special characters, Only use prepared statements, Only use SSL, Use unpredictable session ID's Find resources that are not linked on a page but still accessible Only use saved hardcoded queries Only use SSL Trick a user to visit a malicious copy of the intended page - Only use prepared statements White list input, Only use POST, Only use prepared statements White list input, Remove all special characters, Only use prepared statements Only use SSL, Name sessions, Use unpredictable session ID's Only use SSL, Use unpredictable session ID's Find resources that are not linked on a page but still accessible White list input, For SQL use stored_procedures Only use SSL, Use unpredictable session ID's

58 How do you prevent XSS? Whitelist input, Remove all HTML-content, Escape or encode untrusted data How do you prevent insecure direct object reference? Check that user has access to object, Use indirect referencing, by mapping input and resource keys How do you prevent attacks exploting security misconfigurations? Keep all software up-to-date, Turn off unused services Whitelist input Escape or encode untrusted data Make user verify identify again when trying to access a restricted page Check that user has access to object, Use indirect referencing, by mapping input and resource keys Turn off unused services, Keep all software up-todate Keep all software up-to-date Turn off unused services, Turn off error and debug messages, Supress sql errors, Harden configuration for services (i.e. make it harder to determine version numbers) Whitelist input, Remove all HTML-content,, Check that user has access to Escape or encode untrusted data, Only object, Use indirect referencing, by mapping allowed authorized users to send input input and resource keys Remove all HTML-content, Escape or encode untrusted data, Only allowed authorized users to send input Check that user has access to object Turn off unused services, Keep all software up-todate Turn off unused services, Keep all software up-todate Whitelist input, Remove all HTML-content, Escape or encode untrusted data Turn off unused services, Keep all software up-todate Whitelist input, Escape or encode untrusted data Escape or encode untrusted data Escape or encode untrusted data Escape or encode untrusted data Use direct referencing so that you can validate reference and target Check that user has access to object, Make user verify identify again when trying to access a restricted page Check that user has access to object, Make user verify identify again when trying to access a restricted page Turn off unused services, Keep all software up-todate Turn off unused services, Keep all software up-todate, Show more informative error messages so you can find faults in the software easier and fix them Turn off unused services Turn off unused services, Keep all software up-todate Escape or encode untrusted data Check that user has access to object, Use indirect referencing, by mapping input and resource keys Turn off unused services, Keep all software up-todate Remove all HTML-content, Escape or encode untrusted data Check that user has access to object, Make user verify identify again when trying to access a restricted page Turn off unused services, Keep all software up-todate Keep all software up-to-date Escape or encode untrusted data Check that user has access to object Keep all software up-to-date Check that user has access to object, Make Escape or encode untrusted data, Only user verify identify again when trying to access Turn off unused services, Keep all software up-todate, allowed authorized users to send input a restricted page Only use older trusted software Whitelist input, Remove all HTML-content, Escape or encode untrusted data Whitelist input, Escape or encode untrusted data Check that user has access to object, Use indirect referencing, by mapping input and resource keys, Make user verify identify again when trying to access a restricted page Check that user has access to object Turn off unused services, Keep all software up-todate, Definitely do NOT show too much information in error messages to the user since this can help attackers find the security flaws. Turn off unused services, Only use older trusted software, misconfigurations can't be prevented.. You can't prevent misshaps, that's why they are called misshaps. But you can minemize the risk by doing the above and by having audits of the system from an external part and also perform regular securith penetration tests.

59 Escape or encode untrusted data Turn off unused services Keep all software up-to-date Whitelist input, ssl Check that user has access to object, Use indirect referencing, by mapping input and resource keys Turn off unused services, Keep all software up-todate Remove all HTML-content, Escape or encode untrusted data Remove all HTML-content, Escape or encode untrusted data, Turn off unused services, Keep all software up-to-date Only allowed authorized users to send input Use direct referencing so that you can validate reference and target Turn off unused services Whitelist input, Escape or encode untrusted data, Only allowed authorized users to send input Check that user has access to object Turn off unused services, Keep all software up-todate Whitelist input, Remove all HTML-content, Escape or encode untrusted data - Turn off unused services, Keep all software up-todate, Only use older trusted software Whitelist input Make user verify identify again when trying to access a restricted page

60 How do you prevent forced access (missing function level access control)? Authorize by using an external module on all pages, Deny all access by default and verify user How do you prevent CSRF (Crosssite Request Forgery)? How do you handle sensitive data (like passwords, credit card numbers and so on)? Include unique unpredictable tokens in hidden fields Deny all access by default and verify user Include unique unpredictable tokens in hidden fields Include unique unpredictable tokens in hidden fields, Check refferrer path (one cannot change password witout Don't link to sensitive pages, Deny all first going to options menu etc, in access by default and verify user addition to hidden token) Don't link to sensitive pages, Deny all access by default and verify user, Authorize by using an external module on all pages Use a secret cookie, Make user reauthenticate, Include unique unpredictable tokens in hidden fields Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Only use POST-requests, Include unique unpredictable tokens in hidden fields Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Use salts when saving passwords, Don't save any unnecessary sensitive data, Limit the max lenghts of input to match the expected input Hardcode access to all files, Deny all access by default and verify user Include unique unpredictable tokens in hidden fields Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Deny all access by default and verify user Include unique unpredictable tokens in hidden fields Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Deny all access by default and verify user Include unique unpredictable tokens in hidden fields Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Don't link to sensitive pages, Deny all access by default and verify user Only use POST-requests, Make user reauthenticate Don't save any unnecessary sensitive data Don't save any unnecessary sensitive data Deny all access by default and verify user Don't link to sensitive pages, Deny all access by default and verify user Include unique unpredictable tokens in hidden fields Use salts when saving passwords, Don't save any unnecessary sensitive data Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Save all data hashed/encrypted Deny all access by default and verify user Hardcode access to all files, Don't link to sensitive pages, Deny all access by default and verify user Only use GET-requests, Include unique unpredictable tokens in hidden fields Include unique unpredictable tokens in hidden fields Only use POST-requests, Include unique unpredictable tokens in hidden fields Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Save all data hashed/encrypted, Don't save any unnecessary sensitive data, Limit the max lenghts of input to match the expected input Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Use salts when saving passwords, Don't save any unnecessary sensitive data, Limit the max lenghts of input to match the expected input Don't link to sensitive pages, Authorize by using an external module on all pages Make user reauthenticate, Include unique unpredictable tokens in hidden fields Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Hardcode access to all files, Deny all access by default and verify user Make user reauthenticate, Include unique unpredictable tokens in hidden fields, Auth tokens are a good way to do it. Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data, Limit the max lenghts of input to match the expected input, credic card numbers is something you don't touch or save at all, and if you REALLY need to you use a PCI certified vendor because you're required to if you want to be connected with Visa/MasterCard etc.

61 Make user reauthenticate Save all data hashed/encrypted, Don't save any unnecessary sensitive data Use salts when saving passwords, Don't save any unnecessary sensitive data Don't save any unnecessary sensitive data Save all data hashed/encrypted, Use salts when saving passwords Save all data hashed/encrypted Deny all access by default and verify user ssl Don't save any unnecessary sensitive data, Limit the max lenghts of input to match the expected input Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Use salts when saving passwords, Don't save any unnecessary sensitive data Save all data hashed/encrypted, Don't save any unnecessary sensitive data Deny all access by default and verify user Make user reauthenticate Don't save any unnecessary sensitive data Include unique unpredictable tokens in hidden fields Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data, Limit the max lenghts of input to match the expected input Authorize by using an external module on all pages - Include unique unpredictable tokens in hidden fields Use a secret cookie, Make user reauthenticate, Include unique unpredictable tokens in hidden fields Save all data hashed/encrypted, Use salts when saving passwords Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data Deny all access by default and verify user Make user reauthenticate Save all data hashed/encrypted, Use salts when saving passwords, Don't save any unnecessary sensitive data

62 12.3 Surveydata - bilder Figur 15. Graf över hur de svarande var fördelade gällande hur lång utbildning man hade, där de största kategorierna var ingen eller 3 års utbildning. Figur 16. Graf över hur de svarande var fördelade gällande hur lång erfarenhet man hade, där det dominerande var ingen eller under 1 år. 62

63 Figur 17. Graf över fördelningen av tidigare spårkkunskap, där MySQL och PHP var känt av nästan alla svarande. Figur 18. En graf över den egna uppfattningen om kunskap inom de två ämnena (webbprogrammering och webbsäkerhet) på skala1-5(nybörjare-expert). 63