SQL MySQL Hochkomma Problem :(

[ice-breaker]

addslashes() hat nur aus Zufall funktioniert weil die meisten Injections damit abgedeckt wurden, nicht mehr und nicht weniger.

@belee: doch, genau so sollst du es machen. Ich verweise mal hierauf, wer keine DB-Klasse oder Prepared Statements nutzt fährt damit immernoch besser als diese ewig langen konkatenierten Querys zu schreiben.

 

[bu1137]

@ice-breaker: Das stimmt so einfach nicht. addslashes() funktioniert.

@Belee: Ist ok so, wobei du beim LIKE statement ev. noch _ und % escapen willst, das wird von mysql_real_escape_string() nicht gemacht.

 

[ice-breaker]

@ice-breaker: Das stimmt so einfach nicht. addslashes() funktioniert.

ja, es funktioniert aus Zufall, wenn man iso-8859-1(5) als Charset nutzt, darüber hinaus ist man Verloren.
Es kann eben aus Prinzip an jeder Datenbank scheitern, wenn noch mehr zu escapen wäre, als die Hochkommata, addslashes für Datenbanken zu nutzen ist einfach grob fahrlässig.

 

[bu1137]

Das hat nichts mit Zufall zu tun, und ist auch bei UTF8 noch funktional, wie du zB. aus bereits gepostetem Link entnehmen kannst.

 

[ice-breaker]

Natürlich hat mit Zufall zu tun.
Addslashes wird genau dann funktionieren, wenn die Datenbank keine weiteren Steuerzeichen oder ähnliches hat, die addslashes natürlich ignoriert.
Was mit UTF-8 noch funktioniert, wie der Link zeigt, kann mit dem nächsten Zeichensatz (das Beispiel) schon wieder schief gehen und es wird sicherlich noch weit mehr Probleme in den vielen vorhandenen Zeichensätzen geben.

 

[Belee]

Interessant.

Ich habe gerade gelesen das man die zu filternde Variable auch durch htmlspecialchars jagen kann, stimmt das? ich kann mir das aber irgendwie nicht vorstellen denn dann wird doch aus & ein
&.

 

[bu1137]

htmlspecialchars() ist nur für die Ausgabe sinnvoll (und notwendig), damit du keine XSS Attacken kriegst, nicht aber zur Filterung von SQL Query Input.

 

[ice-breaker]

Ich habe gerade gelesen das man die zu filternde Variable auch durch htmlspecialchars jagen kann, stimmt das? ich kann mir das aber irgendwie nicht vorstellen denn dann wird doch aus & ein
&.

willkommen in der Welt von PHP, wo jeder alles erzählt aber nur die Hälfte stimmt

http://www.petry-newmedia.de/phpsec.pdf
ich weiß bei weitem nicht mehr was drinne steht aber ich glaube mich zu entsinnen, dass es ein guter Einstieg in die Sicherheitsthematik ist, deshalb verlinke ich es immer, wenn es mir angebracht erscheint.

 

[bu1137]

@ice-breaker: Dann wird dich dieser Schnippsel daraus bestimmt freuen

Das mögen einige der wichtigsten Codeschnippsel sein, doch muss man mehr im Kopf haben. Die Funktion htmlspecialchars() sollte zum Repertoire eines jeden PHP-Programmierers gehören: Mit ihr stellen Sie sicher, dass eingegebener HTML-Code umgewandelt wird und nicht nativ zur Ausgabe gelangt. Ebenfalls gehört addslashes() zu den Funktionen die Sie kennen müssen, um Hochkommata in SQL-Queries zu maskieren. Beides wird dem Leser hier noch begegnen, doch wollte ich es hier schon einmal anmerken.

 

[ice-breaker]

Wie gesagt es ist ein Einstieg, da selbst das PHP-Manual sagt man soll stattdessen die DB spezifischen Funktionen nutzen ist die Sache für mich gegessen.

Gutes Material für PHP-Sicherheit gibt es eben nicht kostenlos, da muss man eben ein paar Euro für das Buch von Stefan Esser oder Mario Heidrich ausgeben, die haben aber auch wenigstens genug Wissen über die Themen als "irgendein dahergelaufener Blogger", der das fünftausendste Mal falsche Ratschläge macht (bezogen auf htmlspecialchars() gegen SQL-Injections).

 

[GreenGene]

Ich muss ice-breaker recht geben, an nahe zu jeder Stelle im php Manual steht, dass man addslashes nicht benutzen sollte, nicht umsonst wurde magic_qoutes mittlerweile wieder entfernt. Außerdem ist es doch generell besser sich die sichere und algemeinere Variante anzugewöhnen als eine, die nur mit bestimmten Charsets funktioniert. Des Weiteren würde ich dir z.B. die mysqli klasse oder etwas vergleichbares sehr empfehlen, da so solche Probleme nicht auftreten können.

http://www.phpbuddy.eu/mysqli-erweiterung-php-5.html ist eine ganze nette Einführung zu diesem Thema, wenn du dir tatsächlich die Arbeit machen möchtest das zu lernen-

 

[Belee]

Hm.. zugegeben, ich bin jetzt etwas verwirrt.

Folgendes Szenario schwirrt mir durch den Kopf.

Ich habe in einer Tabelle viele Namen die ein & beinhalten, also & nicht &

Nun habe ich auch ein Formular auf der Seite mit welchem Mann/Frau nach Namen in der Datenbank
suche kann. Wenn ich doch jetzt aber das Formular was einen Query über ein Script in die DB macht absichere, dann würde doch das & des Users garnicht durch kommen, oder habe ich hier was falsch verstanden?
Weil, ich muss doch Sonderzeichen filtern, und wenn ich ein & filtere dann ist das & doch weg.

 

[Yuuri]

Siehe dein letzter Thread: https://www.computerbase.de/forum/threads/mysql-und-utf-8.908484/#post-10037501

Du verwendest HTML-Entities nur, wenn du HTML anzeigen lassen willst. In der Datenbank haben solche Daten nichts zu suchen. Um diese Sachen sicher in den Query einzupflegen, gibt es eben solche Funktionen wie mysql_real_escape_string, damit keine SQL-Injection durchgeführt werden kann.

 

[ice-breaker]

Nein, wenn du in der Datenbank suchst dann nutzt du immer mysql_real_escape_string() damit dein Query ausgeführt wird, wie du möchtest.
Wenn du nun die Daten, die du aus der Datenbank ausgelesen hast, ausgegeben möchtest, dann musst du diese durch htmlspecialchars() jagen, da ggf. XSS-Angriff ein dem String steckt, der dann erst im Browser ausgeführt.

Es gibt da eine nützliche Regel (aus dem Buch PHP-Sicherheit):
Wenn du Daten an ein Subsystem weitergibst (Datenbank, Ausgabe, Mails, Filesystem ...) dann musst du die Daten für das jeweilige Subsystem sichern, damit es dort keinen Schaden anrichten kann.

Also:
mysql_real_escape_string() für MySQL
htmlspecialchars() für HTML
usw usw usw

 

[Belee]

Aha, jetzt hab ichs. Danke Leute.

Noch eine Kleinigkeit.
Wenn ich z.B. ein Voting mit IP-Sperre über Datenbank laufen habe, sollte man die IP auch absichern? weil das ist ja auch eine User-Eingabe wenn man es so will.
Ich dachte da an sowas:

$ipclient = mysql_real_escape_string($_SERVER['REMOTE_ADDR']);

$ipclient wird dann weiter benutzt.

Oder ist es eher sehr unwahrscheinlich das über eine IP Mist gebaut wird bzw. ist das überhaupt möglich? da ich das halt nicht 100% weiß, dachte ich, ich sichere das ab.

 

[bu1137]

Ich würde, ja. Wie gesagt: Grundsätzlich immer.

Zahlen kannst du statt escapen aber auch einfach via intval()/floatval() oder casting zurechtbiegen, dann brauchts eigentlich kein escaping mehr.

 

[Belee]

@bul

Alles klar, das heisst also, alles was nicht von mir bewusst kommt muss man absichern bzw. escapen.
Besser noch, auch mich absichern ich meine meine Eingaben.

 

[Blutschlumpf]

ich brauche addshlashes nie.
Wofür du das brauchst würde mich mal ernsthaft interessieren.

Ich meinte nicht die Funktion sondern das Escapen an sich.

Beispiel:
echo "Mein Name ist \"John\"\n";

 

[GreenGene]

Was IP-Adressen angeht guck dir doch mal die php Filter an: http://de3.php.net/filter

Das hier ist das Beispiel zu IP-Adressen aus der Dokumentation:

<?php
$ip_a = '127.0.0.1';
$ip_b = '42.42';

if (filter_var($ip_a, FILTER_VALIDATE_IP)) {
    echo "This (ip_a) IP address is considered valid.";
}
if (filter_var($ip_b, FILTER_VALIDATE_IP)) {
    echo "This (ip_b) IP address is considered valid.";
}
?>

Das oben gezeigte Beispiel erzeugt folgende Ausgabe:

This (ip_a) IP address is considered valid.