Eine Sache der Sicherheit

[pixelsetzer]

Hi, ich bin grade dabei mein BlogSystem Hacker sicher zu machen und hab mir überlegt dafür ganz einfach eine kleine Funktion zu schreiben, die ich dann einfach nur noch überall benutzen muss, wo variablen per GET und POST gebraucht werden.


function anti_hack($var_p) {

$var_s = addslashes(strip_tags(quotemeta(htmlentities($var_p))));
return $var_s;
}


Meine Frage ist jetzt: Reicht das aus? Hat das Performancetechnisch große Nachteile immer alle Funktionen zu verwenden, obwohl man sie evtl. gar nicht bräuchte?

Wie schützt ihr euch?
Dabei geht es hauptsächlich um IDs, die für SQL Abfragen gebraucht werden.
Das lesen im I-net und in Büchern hat mir immer mehr sorgen gemacht als genommen und ne richtige Lösung hab ich nicht wirklich finden können.


MfG

[defabricator]

Also von solchen grobmotorischen Rundumschlägen halte ich ja nicht viel. Im Zweifel macht man mehr kaputt als es wirklichen Schutz bietet. btw: Welche tags soll strip_tags noch entfernen nachdem htmlentities schon alle < > in &lt; bzw &gt; umgewandelt hat?
Wenn es eine sinnvolle Kombination von allen Schutzfunktionen gäbe, hätte sie PHP sicher eingebaut.
Dabei geht es hauptsächlich um IDs, die für SQL Abfragen gebraucht werden.Was kümmern die SQL Datenbank html tags oder entities?
Die Ids sind doch vermutlich Zahlen. Dann ist das einfachste, die Variablen explizit in Zahlen umzuwandeln $query = '...WHERE id='.(int)$id;

[pixelsetzer]

Es geht mir darum, zu verhindern das auf den Weg in die SELECT Abfrage schädlicher Code in mein System kommt.
Aber wie es aussieht würde da sicherheitshalber strip_tags() reichen oder?

Danke aber für den Hinweis mit .(int), das werde ich auch benutzen.

Kann ja auch sein, das ich mich viel zu viel verrückt deswegen mache ;-)

EDIT:

Spielt es eine Rolle, wenn ich .(int) benutze obwohl es in MySQL als Bigint festgelegt ist?

[defabricator]

oh ja, bigint kann ein Problem sein. In diesem Fall
entweder
$query = "...WHERE id='".mysql_real_escape_string($_POST['id'])."'";
oder vorher ctype_digit($_POST['id']) abtesten. Ich würde vermutlich die erste Version verwenden.

Aber wie es aussieht würde da sicherheitshalber strip_tags() reichen oder?Nein, die spezifische Funktion. Wenn Du mysql_query() verwendest also mysql_real_escape_string(). Oder wenn Du mysqli_query verwendest mysqli_real_escape_string usw.
strip_tags ist für xml/html u.ä., nicht für (my)sql.

[pixelsetzer]

Ok, danke für die Beratung ;-)

strip_tags() dachte ich, da es wohl PHP-Tags entfernt und ich in ner Zeitung gelesen hatte das man auch PHP-Code injizieren kann.

Vor allem muss darauf geachtet werden, ob ein Eingabetext unerlaubte HTML-Tags oder PHP-Progammcode enthält. Die eingabe könnte ein schließendes "; enthalten, das den PHP-Interpreter dazu verleitet, nachfolgenden PHP-Code auszuführen.

Aber dem nach müsste man jedes GET und POST duch addslashes() jagen, um sicher zugehen. Das würde dann aber auch fast alle anderen Überprüfungen überflüssig machen und man bräuchte auch kein mysql_real_escape_string().

Oder hab ich den Textteil falsch verstanden?
Genau das verwirrt mich, das es soviel mögliche Funktionen gibt.^^

[defabricator]

Um die Werte sicher für den Gebruach mit mysql_query() zu machen, reicht ausschließlich mysql_real_escape_string(). Damit kannst Du alles, alles in die Datenbank schreiben. Es bleibt kein einiges Zeichen "unbehandelt", das irgendwelchen Schaden in der Abfrage verursachen könnte.
Alles andere hängt davon ab, was Du sonst noch mit den Daten anfangen willst und wo Du sie einbetten willst. Das Problem ist immer, dass Du die Daten in ein anderes "Gerüst" einbettest. Bei der Mysql Abfrage bettest Du die (Benutzer-)Daten in sql ein. Also musst Du dafür sorgen, dass alle sql relevanten Zeichen behandelt werden -> mysql_real_escape_string. Wenn Du die Daten bei der Ausgabe in HTML einbettest, müssen alle Zeichen, die etwas besonderes in HTML darstellen behandelt/maskiert/umgewandelt werden -> htmlentities. Damit wir die "Aussage" der Daten nicht verändert, nur die Art, wie sie im Speicher dargestellt werden. (Anders bei strip_tags; da werden wirklich Daten entfernt/vernichtet.)
Wenn Du weißt, dass die Daten immer als html ausgegeben werden sollen, kannst Du natürlich die Daten schon "vorgefertig" abspeichern.
$sqldaten=mysql_real_escape_string(htmlentities($benutzereingabe));
Ich persönlich bevorzuge, die Anpassung erst bei der Ausgabe vorzunehmen, also wenn ich genau weiß, was mit den Daten passiert. Das ist einfach eine Festlegung der Verantwortlichkeiten. Wie Du das festlegst, ist fast egal, es kommt nur darauf an, dass Du es konsequent festlegt und einhälst.
Aber eben kein Rundumschlag, der dann angeblich für alles und jedes geeignet ist ;)