Utformning av databaser: Skillnad mellan sidversioner

Från Wiki.linux.se
Hoppa till navigering Hoppa till sök
(Skapade sidan med 'Error Reporting ¶ With PHP security, there are two sides to error reporting. One is beneficial to increasing security, the other is detrimental. A standard attack tactic involves profiling a system by feeding it improper data, and checking for the kinds, and contexts, of the errors which are returned. This allows the system cracker to probe for information about the server, to determine possible weaknesses. For example, if an attacker had gleaned information about a pa...')
 
 
(2 mellanliggande sidversioner av samma användare visas inte)
Rad 1: Rad 1:
Error Reporting ¶
== Felrapportering ==
With PHP security, there are two sides to error reporting. One is beneficial to increasing security, the other is detrimental.
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.


A standard attack tactic involves profiling a system by feeding it improper data, and checking for the kinds, and contexts, of the errors which are returned. This allows the system cracker to probe for information about the server, to determine possible weaknesses. For example, if an attacker had gleaned information about a page based on a prior form submission, they may attempt to override variables, or modify them:
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:
 
Example #1 Attacking Variables with a custom HTML page


=== Exempel #1 Attackerande variabler med en anpassad HTML-sida ===
<pre>
<form method="post" action="attacktarget?username=badfoo&amp;password=badfoo">
<form method="post" action="attacktarget?username=badfoo&amp;password=badfoo">
<input type="hidden" name="username" value="badfoo" />
<input type="hidden" name="username" value="badfoo" />
<input type="hidden" name="password" value="badfoo" />
<input type="hidden" name="password" value="badfoo" />
</form>
</form>
The PHP errors which are normally returned can be quite helpful to a developer who is trying to debug a script, indicating such things as the function or file that failed, the PHP file it failed in, and the line number which the failure occurred in. This is all information that can be exploited. It is not uncommon for a php developer to use show_source(), highlight_string(), or highlight_file() as a debugging measure, but in a live site, this can expose hidden variables, unchecked syntax, and other dangerous information. Especially dangerous is running code from known sources with built-in debugging handlers, or using common debugging techniques. If the attacker can determine what general technique you are using, they may try to brute-force a page, by sending various common debugging strings:
</pre>


Example #2 Exploiting common debugging variables
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 ===
<pre>
<form method="post" action="attacktarget?errors=Y&amp;showerrors=1&amp;debug=1">
<form method="post" action="attacktarget?errors=Y&amp;showerrors=1&amp;debug=1">
<input type="hidden" name="errors" value="Y" />
<input type="hidden" name="errors" value="Y" />
Rad 19: Rad 21:
<input type="hidden" name="debug" value="1" />
<input type="hidden" name="debug" value="1" />
</form>
</form>
Regardless of the method of error handling, the ability to probe a system for errors leads to providing an attacker with more information.
</pre>


For example, the very style of a generic PHP error indicates a system is running PHP. If the attacker was looking at an .html page, and wanted to probe for the back-end (to look for known weaknesses in the system), by feeding it the wrong data they may be able to determine that a system was built with PHP.
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.


A function error can indicate whether a system may be running a specific database engine, or give clues as to how a web page or programmed or designed. This allows for deeper investigation into open database ports, or to look for specific bugs or weaknesses in a web page. By feeding different pieces of bad data, for example, an attacker can determine the order of authentication in a script, (from the line number errors) as well as probe for exploits that may be exploited in different locations in the script.
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.


A filesystem or general PHP error can indicate what permissions the web server has, as well as the structure and organization of files on the web server. Developer written error code can aggravate this problem, leading to easy exploitation of formerly "hidden" information.
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.


There are three major solutions to this issue. The first is to scrutinize all functions, and attempt to compensate for the bulk of the errors. The second is to disable error reporting entirely on the running code. The third is to use PHP's custom error handling functions to create your own error handler. Depending on your security policy, you may find all three to be applicable to your situation.
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.


One way of catching this issue ahead of time is to make use of PHP's own error_reporting(), to help you secure your code and find variable usage that may be dangerous. By testing your code, prior to deployment, with E_ALL, you can quickly find areas where your variables may be open to poisoning or modification in other ways. Once you are ready for deployment, you should either disable error reporting completely by setting error_reporting() to 0, or turn off the error display using the php.ini option display_errors, to insulate your code from probing. If you choose to do the latter, you should also define the path to your log file using the error_log ini directive, and turn log_errors on.
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.


Example #3 Finding dangerous variables with E_ALL
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 ===
<pre>
<?php
<?php
if ($username) {  // Not initialized or checked before usage
if ($username) {  // Inte initialiserad eller kontrollerad innan användning
     $good_login = 1;
     $good_login = 1;
}
}
if ($good_login == 1) { // If above test fails, not initialized or checked before usage
if ($good_login == 1) { // Om ovanstående test misslyckas, inte initialiserad eller kontrollerad innan användning
     readfile ("/highly/sensitive/data/index.html");
     readfile ("/highly/sensitive/data/index.html");
}
}
?>
?>
 
</pre>
= Sidslut =
= Sidslut =
Orginalhemsidan på Engelska :https://www.php.net/manual/en/security.cgi-bin.default.php
Orginalhemsidan på Engelska :https://www.php.net/manual/en/security.database.design.php
<BR>[[PHP]]
<BR>[[PHP]]


Nuvarande version från 1 september 2024 kl. 07.39

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");
}
?>

Sidslut

Orginalhemsidan på Engelska :https://www.php.net/manual/en/security.database.design.php
PHP


Säkerhet
Databassä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.

Hämtad från "https://wiki.linux.se/index.php?title=Utformning_av_databaser&oldid=3859"