Modul 8 Hantering av indata
Indata De flesta webbplatser idag tillåter användare att mata in data Utan denna möjlighet hade inte webben varit vad den är idag Tyvärr innebär detta stora säkerhetsrisker Klientdatorn bestämmer vad som händer härnäst i programmet För att klienten inte skall göra felaktiga val behövs kontroller 2
Buggar i hanteringen av indata Kan hjälpa en attackerare att ta sig förbi säkerhetsspärrar Kan ge access till viktiga resurser på servern Kan möjliggöra att felaktig data kan matas in 3
Hantering av indata Vad handlar indata om Att validera indata Hantera felaktig input Autoriseringsproblem Skydda indata på serversidan 4
Editera HTML-filer HTML-kod ägs av klienten, som har full kontroll över den. Editera genom att: 1. Spara webbsidan som en HTML-fil 2. Öppna filen I en texteditor 3. Gör ändringarna du önskar 4. Om action -attributet är relativt; ändra det till full URL 5. Spara filen lokalt 6. Öppna filen i webbläsaren och klicka Submit Se Exempel 1 5
Vad handlar indata om Två olika typer av indata från klienten Användargenererad indata Webbläsaren låter användaren diktera värden Server-genererad indata De verkliga värdena göms i HTML eller i HTTP Användaren skall inte modifiera dessa värden 6
Användargenererad indata <input type="text" name="username"/> <input type="password" name="password"/> <textarea name="address" cols="80" rows="5"> </textarea> 7
Server-genererad indata Parametrar i URL <a href="http://someplace.example/edit.jsp?id=1213"></a> Select-listor <select name="country"> <option value="dk">denmark</option> <option value="se">sweden</option> </select> Check-boxar <input type="radio" name="gender" value="female"/> Female Gömda fält <input type="hidden" name="userid" value="194423"/> HTTP Headers Cookie: CustId=3758936 8
Att lita på användaren Många webbprogrammerare inser inte att: Användaren har full kontroll över sin dator Han kan undersöka och modifiera allt som webbläsaren kan se hidden -fält i formulär Cookies Javascript-kod, även om den ligger i separat fil Modifiering av data är inte ens svårt! Data sänds ofta fram och tillbaka mellan klient och server Det finns ingen client-side security! 9
Titta på denna URL: Variabler i URL http://www.somewhere.example/index.php?foo=1&bar=hello.två variabler skapas $foo med värde 1 $bar med värde Hello I denna kod: if (hasrole($userid, ROLE_ADMINISTRATOR)) $isadmin = 1; if ($isadmin) { # do some stuff requiring admin privileges. } Vad händer med URL: http://www.somewhere.example/adminstuff.php?isadmin=1
Validering av indata Identifiera och validera all indata Kontrollera format och gränsvärden Kontrollera längden Kontrollera eventuella null-bytes Skapa valideringsfunktioner för detta Gör validering för allt som utförs Gör autentiseringsprov samtidigt som kontroll av indata 11
Hantering av felaktig indata Felaktig användargenererad indata Visa upp formuläret igen med ett felmeddelande Felaktig servergenererad indata Tecken på förfalskning Visa kort felmeddelande och notera i loggen Felaktig indata. Incidenten har loggats Gör inte: Validera indata på klienten (Javascript) Ändra indata så att den blir giltig 12
Whitelist och blacklist När man filtrerar data tittar man på tecken eller teckenkombinationer för att ta bort eller ändra dem Filtrering kan göras på två sätt Identifiera det dumma och ta bort det Identifiera det snälla och ta bort resten Första valet är det intuitiva, det andra är det rätta
Authentiseringproblem Authentisering: Att hantera någon access till våra tillgångar Servergenererad indata hanterar väldigt ofta olika tillgångar Modifierad indata kan ge någon access som inte skulle haft det 14
Buggar i authentiseringskod Typiskt HTML-formulär för en online-bank <form action="show-account.asp" method="get"> Account to display: <select name="account"> <option value="1234.56.78901">1234.56.78901</option> <option value="1234.65.43210">1234.65.43210</option> </select> <input type="submit" name="show" value="show Account"/> </form> Förväntar sig ett av de två giltiga kontonummren tillbaka Aug 2000: En norsk tonåring får tillgång till andras konton genom att manipulera indata 15
Skydda servergenererad input Flera sätt att göra detta Skicka inte data till klienten Många gånger kan data lagras på servern Validera formulär och gör autentiseringsprov Använd indirekt åtkomst till data 16
Indirekt åtkomst till data Använd labels istället för riktig data <option value="1">1234.56.78901</option> <option value="2">1234.65.43210</option> Arrayen i exemplet mappade till ett verkligt objekt, men samma namn som objektet Genom att ändra detta till en label kan denna form av attack inte göras 17
Sammanfattning Det finns många sätt att använda sig av för att säkerställa indata Identifiera alla tänkbara källor till indata Inse att allt kan modifieras på klienten Inse att data passerar den osynliga säkerhetsbarriären Fler valideringstest kan behövas Lägg så mycket data på server som möjligt Där är den skyddad 18