Utformning av databaser

Felrapportering

Inom PHP-säkerhet finns det två sidor av felrapportering. Den ena är fördelaktig för att öka säkerheten, den andra är skadlig.

En vanlig attacktaktik innebär att profilera ett system genom att mata in felaktiga data och kontrollera vilken typ av felmeddelanden som returneras och i vilket sammanhang de visas. Detta gör att en angripare kan undersöka information om servern och identifiera möjliga svagheter. Till exempel, om en angripare har samlat information om en sida baserat på en tidigare formulärinlämning, kan de försöka åsidosätta eller ändra variabler:

Exempel #1 Attackerande variabler med en anpassad HTML-sida

<form method="post" action="attacktarget?username=badfoo&password=badfoo">
<input type="hidden" name="username" value="badfoo" />
<input type="hidden" name="password" value="badfoo" />
</form>

De PHP-fel som normalt returneras kan vara mycket användbara för en utvecklare som försöker felsöka ett skript, och indikerar saker som funktionen eller filen som misslyckades, PHP-filen där felet inträffade, och radnumret där felet uppstod. All denna information kan utnyttjas av en angripare. Det är inte ovanligt att en PHP-utvecklare använder `show_source()`, `highlight_string()` eller `highlight_file()` som en felsökningsåtgärd, men på en aktiv webbplats kan detta avslöja dolda variabler, obehandlad syntax och annan farlig information. Särskilt farligt är det att köra kod från kända källor med inbyggda felsökningshanterare, eller att använda vanliga felsökningstekniker. Om angriparen kan avgöra vilken allmän teknik du använder, kan de försöka brute-force en sida genom att skicka olika vanliga felsökningssträngar:

Exempel #2 Utnyttjande av vanliga felsökningsvariabler

<form method="post" action="attacktarget?errors=Y&showerrors=1&debug=1">
<input type="hidden" name="errors" value="Y" />
<input type="hidden" name="showerrors" value="1" />
<input type="hidden" name="debug" value="1" />
</form>

Oavsett vilken metod för felhantering som används, leder möjligheten att sondera ett system efter fel till att en angripare får mer information.

Till exempel indikerar själva stilen på ett generiskt PHP-fel att systemet kör PHP. Om angriparen tittade på en .html-sida och ville undersöka back-enden (för att leta efter kända svagheter i systemet) kan de, genom att mata in fel data, avgöra att systemet byggdes med PHP.

Ett funktionsfel kan indikera om ett system kör en specifik databas, eller ge ledtrådar om hur en webbsida är programmerad eller utformad. Detta möjliggör en djupare undersökning av öppna databashamnar eller letande efter specifika buggar eller svagheter på en webbsida. Genom att mata in olika felaktiga data kan en angripare till exempel avgöra autentiseringens ordning i ett skript (från radnummerfel) samt undersöka sårbarheter som kan utnyttjas på olika ställen i skriptet.

Ett filsystem- eller generellt PHP-fel kan indikera vilka behörigheter webbservern har, samt strukturen och organisationen av filer på webbservern. Utvecklarskrivna felkoder kan förvärra detta problem, vilket leder till enkel exploatering av tidigare "dold" information.

Det finns tre stora lösningar på detta problem. Den första är att noggrant granska alla funktioner och försöka kompensera för majoriteten av felen. Den andra är att inaktivera felrapportering helt på den körande koden. Den tredje är att använda PHP:s anpassade felhanteringsfunktioner för att skapa din egen felhanterare. Beroende på din säkerhetspolicy kan du finna att alla tre lösningarna är tillämpliga för din situation.

Ett sätt att upptäcka detta problem i förväg är att använda PHP:s egen `error_reporting()` för att hjälpa dig att säkra din kod och hitta variabelanvändning som kan vara farlig. Genom att testa din kod innan distribution med `E_ALL` kan du snabbt hitta områden där dina variabler kan vara öppna för förgiftning eller modifiering på andra sätt. När du är redo för distribution bör du antingen inaktivera felrapportering helt genom att ställa in `error_reporting()` till 0, eller stänga av felvisning genom att använda php.ini-alternativet `display_errors`, för att skydda din kod från sondering. Om du väljer att göra det senare bör du också definiera sökvägen till din loggfil genom att använda ini-direktivet `error_log`, och slå på `log_errors`.

Exempel #3 Hitta farliga variabler med E_ALL

<?php
if ($username) {  // Inte initialiserad eller kontrollerad innan användning
    $good_login = 1;
}
if ($good_login == 1) { // Om ovanstående test misslyckas, inte initialiserad eller kontrollerad innan användning
    readfile ("/highly/sensitive/data/index.html");
}
?>