OK. Nein. Das ist der schlechteste Schutz, den ich je gesehen hab^^
- unperformant
- blockiert nur die gegebenen Zeichenketten
- blockiert Zeichenketten, die die gegebenen Zeichenketten enthalten
Ich schlage einfaches escapen vor. oder noch besser die Verwendung von Prepared Statements (siehe z.B. PDO)
Nettes Snippet um PHP Scripte allgemein deutlich sicherer zu machen. Im Grunde genommen nimmt man so (sofern geschickt im Haupt-Script eingebaut) ganz bequem jeglichen Nutzern sämtliche Möglichkeiten XSS- oder SQLi-Attacken durchzuführen.
Note: This language construct is equivalent to die().
Quote:
PHP Manual for die:
This language construct is equivalent to exit().
Jeder Professionelle PHP-Programmierer wird dir von die() abraten.
Bei einem die() ist das Exception, Warning, Error Handling einfach nur grauslich. (Außer man verwendet ein @ vor der ganzen Funktion, was widderum grauslich ist)
Mit einem die() kannst du nicht alle Errors loggen, auffagen usw. und sowas ist eine schöne Information für einen Angreifer wenn er das meiste mitlesen kann.
Quote:
Originally Posted by Aus mehreren PHP Programmierer - Blogs&Forums
It's not a very nice way to present the user with an error message.
Using for instance the mysql_error() call with it, as many people do, exposes information that should never get output in a production environment (see: PHP Security)
You cannot catch the error in any way.
You cannot log the error.
You cannot control whether it should be output to the screen or not. It's okay to do that in a development environment, but certainly not in a production environment.
It prevents you from doing any sort of cleanup. It just ends the script abruptly.
Bei einem exit() kannst du Errors loggen, mit einem Errorcode das script beenden und du gibst nicht so leicht Info an einen Angreifer.
Außerdem steht in meinem Post noch return.
In der Produktion sollte man return und exit bevorzugen als ein Script mit allem drum und dran absterben zu lassen(die)
Aber dies kann zu einer endlosen Diskussion eskalieren, da jeder hier eine andere Meinung haben wird.
Deswegen der Post von:
Quote:
Originally Posted by .Zeraki'
Kommt hier rein :
Zumal gibt es mehrere SQL-Injections als diese in deinem Array.
Nettes Snippet um PHP Scripte allgemein deutlich sicherer zu machen. Im Grunde genommen nimmt man so (sofern geschickt im Haupt-Script eingebaut) ganz bequem jeglichen Nutzern sämtliche Möglichkeiten XSS- oder SQLi-Attacken durchzuführen.
[Release] Anti-Cheat DLL - *Lite* (Anti Injection) 04/11/2013 - Metin2 PServer Guides & Strategies - 30 Replies Heyho, ich habe mir überlegt hier eine Kleinigkeit als einstieg zu releasen!
Dann wollen wir mal schauen, was ich anzubieten habe:
- Eine anti Injection DLL!
Was könnt ihr damit machen?
Ganz einfach, das injecten von Hacks verhindern!
Lite? Gibt es auch eine andere Version?
Die gibt es in der tat, unter Umständen kommt die noch mal dazu.
Anti .dll Injection 01/27/2013 - General Coding - 31 Replies Diese Video zeigt, dass es möglich ist, injizierte .dll ausfindig zu machen.
Anti .dll Injection - YouTube
Anti Injection On Register 03/15/2012 - SRO Private Server - 0 Replies function anti_injection($sql) {
$sql = preg_replace(sql_regcase("/(from|select|inser t|delete|where|'|\"|drop table|show tables|#|\*|--|\\\\)/"),"",$sql);
$sql = trim($sql);
$sql = strip_tags($sql);
$sql = addslashes($sql);
return $sql;
}
$username=anti_injection($_POST);
$password=md5($_POST);
$password2=anti_injection($_POST);