Säkerhet är ett intressant koncept och lockar många till det. Tyvärr är det ett komplext ämne och till och med proffs har fel. Jag har hittat säkerhetshål i Google (CSRF), Facebook (mer CSRF), flera stora onlineåterförsäljare (främst SQL-injektion / XSS), samt tusentals mindre webbplatser, både företag och privata.
Det här är mina rekommendationer:
1) Använd parametriserade frågor
Parameteriserade frågor tvingar de värden som skickas till frågan att behandlas som separata data, så att ingångsvärdena inte kan tolkas som SQL-kod av DBMS. Många kommer att rekommendera att du undkommer dina strängar med mysql_real_escape_string() , men i motsats till vad många tror är det inte en sammanfattande lösning för SQL-injektion. Ta den här frågan till exempel:
SELECT * FROM users WHERE userID = $_GET['userid']
Om $_GET['userid'] är inställd på 1 OR 1=1 , det finns inga specialtecken och det kommer inte att filtreras. Detta resulterar i att alla rader returneras. Eller, ännu värre, tänk om den är inställd på 1 OR is_admin = 1 ?
Parametriserade frågor förhindrar att den här typen av injektion sker.
2) Validera dina indata
Parameteriserade frågor är bra, men ibland kan oväntade värden orsaka problem med din kod. Se till att du validerar att de är inom räckhåll och att de inte tillåter den nuvarande användaren att ändra något de inte borde kunna göra.
Till exempel kan du ha ett formulär för lösenordsändring som skickar en POST-begäran till ett skript som ändrar lösenordet. Om du placerar deras användar-ID som en dold variabel i formuläret kan de ändra det. Skickar id=123 istället för id=321 kan betyda att de ändrar någon annans lösenord. Se till att ALLT är korrekt validerat, vad gäller typ, räckvidd och åtkomst.
3) Använd htmlspecialchars för att undvika visade användarinmatning
Låt oss säga att din användare anger sitt "om mig" som något så här:</div><script>document.alert('hello!');</script><div>
Problemet med detta är att din utdata kommer att innehålla markeringar som användaren angett. Att försöka filtrera detta själv med svarta listor är bara en dålig idé. Använd htmlspecialchars för att filtrera bort strängarna så att HTML-taggar konverteras till HTML-enheter.
4) Använd inte $_REQUEST
Cross-site request forgery (CSRF) attacker fungerar genom att få användaren att klicka på en länk eller besöka en URL som representerar ett skript som utför en åtgärd på en webbplats som de är inloggade på. $_REQUEST variabel är en kombination av $_GET , $_POST och $_COOKIE , vilket innebär att du inte kan se skillnaden mellan en variabel som skickades i en POST-begäran (dvs genom en input taggen i ditt formulär) eller en variabel som angavs i din webbadress som en del av en GET (t.ex. page.php?id=1 ).
Låt oss säga att användaren vill skicka ett privat meddelande till någon. De kan skicka en POST-förfrågan till sendmessage.php , med to , subject och message som parametrar. Låt oss nu föreställa oss att någon skickar en GET-förfrågan istället:
sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!
Om du använder $_POST , kommer du inte att se någon av dessa parametrar, eftersom de är inställda i $_GET istället. Din kod kommer inte att se $_POST['to'] eller någon av de andra variablerna, så det skickar inte meddelandet. Men om du använder $_REQUEST , $_GET och $_POST fastnar, så att en angripare kan ställa in dessa parametrar som en del av URL:en. När användaren besöker den webbadressen skickar de oavsiktligt meddelandet. Den riktigt oroande delen är att användaren inte behöver göra någonting. Om angriparen skapar en skadlig sida kan den innehålla en iframe som pekar på URL:en. Exempel:
<iframe src="http://yoursite.com/sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!">
</iframe>
Detta resulterar i att användaren skickar meddelanden till människor utan att någonsin inse att de gjort något. Av denna anledning bör du undvika $_REQUEST och använd $_POST och $_GET istället.
5) Behandla allt du får som misstänkt (eller till och med skadligt)
Du har ingen aning om vad användaren skickar till dig. Det kan vara legitimt. Det kan vara en attack. Lita aldrig på något som en användare har skickat till dig. Konvertera till korrekta typer, validera indata, använd vitlistor för att filtrera vid behov (undvik svartlistor). Detta inkluderar allt som skickas via $_GET , $_POST , $_COOKIE och $_FILES .
Om du följer dessa riktlinjer har du en rimlig ställning när det gäller säkerhet.