Felrapportering

Felrapportering

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

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

Exempel #1 Attackera 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 hjälpsamma för en utvecklare som försöker felsöka ett skript, och de indikerar till exempel vilken funktion eller fil som misslyckades, vilken PHP-fil den misslyckades i och på vilken rad felet inträffade. All denna information kan utnyttjas. Det är inte ovanligt att en PHP-utvecklare använder `show_source()`, `highlight_string()` eller `highlight_file()` som en felsökningsmetod, men på en live-sida kan detta exponera dolda variabler, okontrollerad 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 generell teknik du använder, kan de försöka brutforca en sida genom att skicka olika vanliga felsökningssträngar:

Exempel #2 Utnyttja 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 metod för felhantering leder möjligheten att undersöka ett system för fel till att ge en angripare mer information.

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

Ett funktionsfel kan indikera om ett system kanske kör en specifik databasmotor, eller ge ledtrådar om hur en webbsida är programmerad eller designad. Detta möjliggör en djupare undersökning av öppna databashamnar, eller för att leta efter specifika buggar eller svagheter på en webbsida. Genom att mata in olika felaktiga data, till exempel, kan en angripare avgöra ordningen för autentisering i ett skript (från radnumrens fel) samt undersöka exploateringar som kan utnyttjas på olika platser i skriptet.

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

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

Ett sätt att fånga detta problem i förväg är att använda PHP:s egen `error_reporting()` för att hjälpa dig 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 felskärmen med php.ini-alternativet `display_errors` för att isolera din kod från undersökningar. Om du väljer att göra det senare bör du också definiera sökvägen till din loggfil med `error_log`-ini-direktivet och slå på `log_errors`.

Exempel #3 Hitta farliga variabler med `E_ALL`

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

Felrapportering

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

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

Exempel #1 Attackera 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 hjälpsamma för en utvecklare som försöker felsöka ett skript, och de indikerar till exempel vilken funktion eller fil som misslyckades, vilken PHP-fil den misslyckades i och på vilken rad felet inträffade. All denna information kan utnyttjas. Det är inte ovanligt att en PHP-utvecklare använder `show_source()`, `highlight_string()` eller `highlight_file()` som en felsökningsmetod, men på en live-sida kan detta exponera dolda variabler, okontrollerad 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 generell teknik du använder, kan de försöka brutforca en sida genom att skicka olika vanliga felsökningssträngar:

Exempel #2 Utnyttja 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 metod för felhantering leder möjligheten att undersöka ett system för fel till att ge en angripare mer information.

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

Ett funktionsfel kan indikera om ett system kanske kör en specifik databasmotor, eller ge ledtrådar om hur en webbsida är programmerad eller designad. Detta möjliggör en djupare undersökning av öppna databashamnar, eller för att leta efter specifika buggar eller svagheter på en webbsida. Genom att mata in olika felaktiga data, till exempel, kan en angripare avgöra ordningen för autentisering i ett skript (från radnumrens fel) samt undersöka exploateringar som kan utnyttjas på olika platser i skriptet.

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

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

Ett sätt att fånga detta problem i förväg är att använda PHP:s egen `error_reporting()` för att hjälpa dig 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 felskärmen med php.ini-alternativet `display_errors` för att isolera din kod från undersökningar. Om du väljer att göra det senare bör du också definiera sökvägen till din loggfil med `error_log`-ini-direktivet och slå på `log_errors`.

Exempel #3 Hitta farliga variabler med `E_ALL`

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

Sidslut

Orginalhemsidan på Engelska :https://www.php.net/manual/en/security.errors.php
PHP
Säkerhet

---

Det här är en maskinöversättning av PHP-manualen till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på https://www.linux.se/kontaka-linux-se/

Tack till Datorhjälp som har sponsrat Linux.se med webserver.