Modul 6 Webbsäkerhet
Serverskript & Säkerhet Webbservrar & serverskript exponerar möjlighet för fjärranvändare att skicka data och köra kod vilket medför risker. Man ska aldrig lita på att alla vill göra rätt för sig Validering av input data Kryptering SQL Injection Felmeddelande XSS (Cross Site Scripting) 2
Men vi har ju en brandvägg! Vi har en brandvägg Vi krypterar all trafik till webbservern med HTTPS Vi uppdaterar all vår programvara automatiskt och ofta Varför är inte våra webbapplikationer säkra? 3
Därför räcker inte detta! 4
Webbserverbuggar Buggar i webbservrarna kan ge obehöriga tillträde till serverfiler, även källkoden på servern Om webbserver-programmerarna kan göra idiotiska misstag kan antagligen webbapplikationsprogrammerarna också göra det 5
Buggar i kod är vanligt Enligt en undersökning från Universitetet i Bergen 2005: Minst 72% av 245 E-myndigheter är sårbara för cross-site-scripting Minst 58% är sårbara för SQL Injection På 53 olika E-myndighetssajter i Europa var 91% sårbara av antingen cross-site-scripting eller SQL Injection http://computersweden.idg.se/2.2683/1.20957 5/ibm-sql-injektioner-popularast 6
Grunderna HTTP Sessioner HTTPS 7
HTTP Hypertext Transfer Protocol (RFC 2616) Sköter hur webbnoder utbyter data Förbindelselös client/server-lösning Klienten alltid initierar 8
Client/server 9
GET vs. POST Använd aldrig GET för känslig data Med GET frågar klienten webbservern efter information Med POST bidrar klienten med information till webbservern POST kan inte köras utan tillstånd från klienten. 10
HTTP Get Request http://tor.ei.hv.se/~will/courses/ira120/webbsakerhet/get.php GET /~will/courses/ira120/webbsakerhet/get.php?txtvalue=test+av +get&btnsubmit=submit HTTP/1.1 Host: tor.ei.hv.se User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q =0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://tor.ei.hv.se/~will/courses/ira120/webbsakerhet/get.p hp?txtvalue=test+av+get&btnsubmit=submit 11
HTTP Response http://tor.ei.hv.se/~will/courses/ira120/webbsakerhet/get.php HTTP/1.x 200 OK Date: Fri, 17 Apr 2009 09:07:52 GMT Server: Apache/2.2.2 (Fedora) X-Powered-By: PHP/5.1.6 Content-Length: 570 Connection: close Content-Type: text/html; charset=iso-8859-1 12
HTTP POST Request http://tor.ei.hv.se/~will/courses/ira120/webbsakerhet/post.php POST /~will/courses/ira120/webbsakerhet/post.php HTTP/1.1 Host: tor.ei.hv.se User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://tor.ei.hv.se/~will/courses/ira120/webbsakerhet/post.ph p Content-Type: application/x-www-form-urlencoded Content-Length: 38 txtvalue=test+av+post&btnsubmit=submit 13
Referrer Header Innehåller hela URL till dokumentet där requesten gjordes Skickas av webbläsare då: Man klickar på en länk En bild finns inkluderad på sidan En applet eller annat objekt finns inkluderat på sidan Dessa kan läcka säkerhetsrelaterad info till tredje part! 14
Att ha hemligheter i URL er Besökta hemsidor kan dyka upp överallt: De finns i webbläsarens historik Problematiskt på delade datorer De finns i loggfiler på proxyservrar De finns på tredje-parts sajter i form av Referrer-headers Skicka aldrig hemligheter i URL s! Använd POST istället för GET när informationen är känslig 15
Cookies: Gör HTTP förbindelseorienterat En liten textfil som sparas på webbklienten Överförs med HTTP headers Skickas av webbservern med response headers Skickas tillbaka till webbservern vid varje request Dock endast från korrekt domän! 16
Exempel på cookies http://tor.ei.hv.se/~will/courses/ira120/webbsakerhet/cookies.php Response header som sätter en cookie Set-Cookie: TimeOfLastView=April+17%2C+2009%2C+11%3A3 8+am; expires=fri, 17-Apr-2009 10:38:13 GMT Set-Cookie: NumberOfVisits=6; expires=fri, 17- Apr-2009 10:38:13 GMT Request header hämtar tillbaka en cookie Cookie: Visited=1; NumberOfVisits=5; TimeOfLastView=April+17%2C+2009%2C+11%3A3 7+am 17
Sessioner: Samla data på servern En påse på server-sidan som sparar information om varje besökande klient Knyts till varje klient med hjälp av ett sessions-id Måste skickas med varje request Cookie-baserad URL-baserad 18
Sessioner 19
Session hijacking En attackerare får access till en annan användares sessions-id Genom gissning eller intelligent trial and error Genom referrer header Sniffa paket Cross-site-scripting (XSS) Attackeraren visar upp det stulna sessions-id för webbservern Webbservern tror att attakeraren är offret 20
Session hijacking: Motmedel Sessions-ID måste hållas hemligt Skall ej kunna gissas, fullständigt slumpmässigt Får ej kunna läcka Ej skickas i URL Skyddas med kryptering (HTTPS) Ej nåbart genom cross-site-scripting 21
Andra motmedel Knyt sessionen till en IP-adress Stoppar ej besökare bakom samma proxy! Knyt sessionen till request-headern Kan enkelt förfalskas av en attackerare Byt sessions-id för varje response Attackeraren kan dock få den första för att sedan blockera offret 22
HTTPS Vanlig HTTP genom en säker tunnel TLS: Transport Layer Security SSL: Secure Socket Layer Hur skapas en säker uppkoppling Klienten tar kontakt med server Klient och server gör handskakning Bestämmer algoritmer för kryptering och hash Klient får och verifierar server-certifikatet Startar krypterad kommunikation Kontrollen skickas tillbaka till HTTP 23
Fördelar med HTTPS Om allt fungerar som det ska, HTTPS: Skyddar mot paketsniffning Skyddar mot Man in the Middle -attacker Även modifiering av data när den överförs Autentiserar webbservern mot klienten Kan även autentisera servern mot klienten Senaste versionerna av TLS och SSL anses säkra, men 24
Nackdelar med HTTPS HTTPS skyddar inte mot: Användare som struntar i varningar från webbläsaren Webbläsare som tillåter användare att strunta i varningarna Användare som faller för billiga trick: mega-bank.com istället för megabank.com En CA som delar ut falska certifikat VeriSign gjorde detta 2001 Webbläsare som har en dålig SSL/TLS-implementation Allt ovanstående har hänt! 25
Summering HTTP är ett enkelt textbaserat client/serverprotokoll Cookies används för att kunna hålla en förbindelse mellan klient och server Sesioner används för att spara data mellan olika requests Använd aldrig GET för känslig data HTTPS löser inte alla problem Och hur bra det är beror på många faktorer 26
Mer information Absolut bästa källan om HTTP är dess RFC2616 http://www.ietf.org/rfc/rfc2616.txt Allt om HTTPS, SSL och TLS finns i Eric Rescorla's bok SSL and TLS: Designing and Building Secure Systems Mer om Man in the Middle mot SSL finns i Peter Burkholder's artikel "SSL Man-in-the- Middle Attacks http://www.sans.org/reading_room/whitepapers/ threats/480.php 27