[Rikku]

Hi Leute,

Bin neu hier und habe bis jetzt mit begeisterung die Info´s und Tutorials gelesen. Werde dies auch in Zukunft weiterhin tun. Deswegen will ich natürlich auch mein Teil dazu beitragen um Anfängern und Umsteigern zu helfen.

Habe hier einen kleinen Artikel über SQL-Injection auf entwickler.com gefunden der für den ein oder anderen ganz interessant sein dürfte.

greetz

Rikku

[Ben]

Wenn Du in der Lage sein solltest selbst Tuts oder so zu schreiben ... dann sprech mich mal an

[Suendesizer]

In Bezug auf SQL-Injection und PHP:

PHP escaped automatisch kritische Metazeichen wie z.B. ein einfaches Anführungszeichen. Damit ist eine SQL-Injection Attacke allerdings nur bedingt ausgeschlossen, denn es gibt auch Möglichkeiten dieses Escaping auszutricksen. Daher ist es empfehlenswert mit den Funktionen htmlspecialchars() und htmlentities() zu arbeiten um eine Bearbeitung von Metazeichen durchzuführen. Dennoch empfiehlt es sich, eigene Ersetzungsmuster zu entwickeln und dann mit preg_replace() diese zu ersetzen. Wie im Artikel bereits erwähnt, darf man sich dabei aber nicht nur auf die Zeichen des ASCII-Zeichensatzes beschränken, sondern sollte auch die Unicode-Bezeichner in das Ersetzungsmuster einbeziehen.

[Jann Hendrik]

ok. Dann lasst uns doch mal an einer Sicherheits-Funktion arbeiten.


ich nutze derzeit:

PHP-Code:

<?php
  function mysql_secure($text)
  {
    $text = htmlspecialchars($text);
    $text = mysql_escape_string($text);

    if(!get_magic_quotes_gpc())
      $text = addslashes($text);      // Ausgabe dann mit  stripslashes()

    RETURN $text;
  }

$pot_unsicher = "abc";
$sicher = mysql_secure($pot_unsicher);

?>

[VolkerK]

Zitat von Suendesizer

PHP escaped automatisch kritische Metazeichen wie z.B. ein einfaches Anführungszeichen.

Nur dann, wenn es so eingestellt ist. Per php.net-Voreinstellung tut es das nicht.

siehe:
http://www.php.net/manual/en/ref.inf...gic-quotes-gpc
http://www.php.net/manual/en/ref.inf...quotes-runtime

[Suendesizer]

Gut, dann ist es ja umso wichtiger einen Algorithmus zu entwickeln, der eine lückenlose Überprüfung und Ersetzung von Metazeichen bietet. Wir könnten ja mal ein paar Ideen Sammeln, aber ich denke auf Hotscripts.org findet man auch schon so was.

[VolkerK]

Hm, verstehe ich mal wieder nicht. mysql_real_escape_string leistet doch genau das. Bei Abstraktionen sollte es etwas entsprechendes geben, z.B. bei pear-db DB_common::quoteSmart().
Noch besser ist es, die sql-Statements von den eigentlichen Nutzdaten zu trennen, wie es z.B. bei der mysqli-Erweiterung über die bind-Methoden geschieht. Aber bei weitem nicht nur dort, gebundene bzw benannte Parmeter sind eigentlich weit verbreitet und würden die eine oder andere sql-injection vermeiden. PDO unterstützt dies ebenso.

Ich bin stark gegen die Vermischung von Eingabe-, Datenhaltungs- und Ausgabeschicht. Jede davon hat ihre Aufgaben und hat genug damit zu tun.
magic_quote_xyz ist eine (Fehl-)Konfiguration der Eingabeschicht.
Die Datenhaltung per mysql stört sich nicht an <> o.ä.; woran es sich stört wird von mysql_escape_string behandelt.
Die Ausgabeschicht braucht nicht bevormundet werden; in ihr kann selbst entschieden werden, wie die Nutzdaten umgewandelt werden müssen.
Eine zentrale in-einem-Rutsch-Funktion mag evtl. der Performance Tribut zollen, eine saubere Trennung ist es aber nicht.

[Ben]

Zitat von VolkerK

Hm, verstehe ich mal wieder nicht. mysql_real_escape_string leistet doch genau das.

Danke. ... ich dachte echt schon, dass ich irgendwie was verpasst habe.

Ich nutze bei meinen Userdaten auch einfach mysql_real_escape_string() und gut ist ... hm.
Aber ich bin nicht wirklich so ein Security-Typ. Habe da sicherlich einige Wissenslücken die nach Material rufen, mit denen sie gesopft werden können

Hehe.

Grüße Ben.

[Suendesizer]

Also ich persönlich bevorzuge es Daten noch vor der Speicherung zu behandeln. Einfach aus dem Grund, dass eine Eingabe zumeist nur einmal geschieht, ein Aufruf der Daten allerdings mehrmals. Gut, eine saubere Trennung der Schichten ist sicherlich von Vorteil, dennoch sollte man meiner Meinung nach in jeder Schicht berücksichtigen, für was die entsprechenden Daten gedacht sind. mysql_real_escape_string() behandelt lediglich Metazeichen, die der Datenbank Schaden zufügen könnten, es gibt allerdings weitere Metazeichen, die in der HTML-Repräsentieung gefährlich werden (Stichpunkt Cross-Site-Scripting). Ein echt gutes Buch das ich letztens gelesen habe ist "Sicherheitsrisiko Internetanwendung" von Sverre Huseby. In PHP gibt es eigentlich relativ wenige Möglichkeiten für Sicherheitslücken, aber sie sind da und sie werden meist dann gefährlich, wenn der Entwickler ihnen keine Beachtung schenkt.

[VolkerK]

dennoch sollte man meiner Meinung nach in jeder Schicht berücksichtigen, für was die entsprechenden Daten gedacht sind.

Ja, aber jede Schicht für sich, nicht schichtübergreifend. Ein jeder kehre vor seiner eigenen Tür.

mysql_real_escape_string() behandelt lediglich Metazeichen, die der Datenbank Schaden zufügen könnten, es gibt allerdings weitere Metazeichen, die in der HTML-Repräsentieung gefährlich werden

Ja, genau. mysql - Datenhaltung - mysql_real_escape. html - Ausgabeschicht - htmlentitites. Das sind zwei unabhängige Dinge, die auch unabhängig voneinander ausgetauscht werden können. Die Behandlung zu mischen oder die Reihenfolge zu ändern, macht die Anwendung starrer und bei größeren Projekten auch die Verteilung von Verantwortung unübersichtlicher und schwieriger.

[Buhmann]

Zitat von Jann Hendrik

ok. Dann lasst uns doch mal an einer Sicherheits-Funktion arbeiten.


ich nutze derzeit:

PHP-Code:

<?php
  function mysql_secure($text)
  {
    $text = htmlspecialchars($text);
    $text = mysql_escape_string($text);

    if(!get_magic_quotes_gpc())
      $text = addslashes($text);      // Ausgabe dann mit  stripslashes()

    RETURN $text;
  }

$pot_unsicher = "abc";
$sicher = mysql_secure($pot_unsicher);

?>

hm ich kenne diese version:

PHP-Code:

<?php

// Quote variable to make safe
function quote_smart($value)
{
   // Stripslashes
   if (get_magic_quotes_gpc()) {
       $value = stripslashes($value);
   }
   // Quote if not integer
   if (!is_numeric($value)) {
       $value = "'" . mysql_real_escape_string($value) . "'";
   }
   return $value;
}
?>

man müsste mal beide versionen testen um herauszufinden, welche nun richtig ist..

lass mich mal dein code kommentieren

Zitat von Jann Hendrik

PHP-Code:

<?php
  function mysql_secure($text)
  {
    //warum schreibst du html code in die datenbank, gehört dies normaler weise nicht in die ausgabe?
    $text = htmlspecialchars($text); 

    //erster escape
   $text = mysql_escape_string($text);

    if(!get_magic_quotes_gpc()){
      $text = addslashes($text);      // wofür setzt du hier noch addslashes wenn du oben schon mysql_escape_string benutzt?   
}
    RETURN $text;
  }

$pot_unsicher = "abc";
$sicher = mysql_secure($pot_unsicher);

?>

[Jann Hendrik]

@clan: das weiß ich nicht mehr genau, warum ich das so gewählt habe... ich hatte da mal bei einem kleinen Projekt Probleme mit, die ich dadurch habe beheben können.

Da ich nicht der Sicherheitsveranlagte Mensch bin...
Ich dachte mir, dass ich in meinen Projekten meine eigene Funktion ^^ schreibe und diese dem steigenden Wissen anpasse.
Das war auch ein Grund, warum ich das hier mal gepostet habe - um es der Kritik auszusetzen - scheinbar nicht ohne Grund.

Cool fänd ich - wenn ihr das mit den Schichten nochmal erklärt - oder mir sagt, wonach ich suchen soll, weil ich das nicht gepeilt habe, worüber ihr da geredet habt!

Mein Wunsch wäre es, wenn wir hier eine Funktion zusammenbasteln, die der Kritik derer im Forum hier standhält, und man dann nutzen kann, ohne Angst zu haben, dass da jmd. ankommt und in den Daten rumpfuscht!

[Ben]

Ich frage nochmal .. was genau ist denn an mysql_real_escape_string() jetzt schlecht?

[Buhmann]

Bevor Sie eine Anfrage an MySQL absetzten, müssen Sie immer diese Funktion verwenden (mit einigen Ausnahmen), um Ihre Daten sicher zu machen. Falls Sie magic_quotes_gpc aktiviert haben und mit Daten aus Benutzereingaben arbeiten, müssen Sie vorher Ihre Daten mit stripslashes() behandeln. Falls Ihre Daten aus anderen Quellen stammen und Sie magic_quotes_runtime aktiviert haben, müssen Sie ebenfalls Ihre Daten mit stripslashes() behandeln. Falls Sie diesen Rat nicht beherzigen, ist Ihre Anwendung anfällig für SQL Code-Einschleusung. Hier ein Beispiel:

und genau das bewirkt die von mir gepostete funktion.

[VolkerK]

Die Version wurde ja auch nicht kritisiert, Buhmann.
Wenn ich daran Kritik habe, dann die, dass sich diese Funktion eigentlich nicht um die Bevormundung durch magic_quote kümmern sollte, da nirgendwo festgelegt wird, dass $text ein Parameter von aussen -also durch quote_gpc beeinflusst- ist.

@Jann Hendrik: hum...such mal am besten erstmal nach Model,View,Controller (MVC)

[Buhmann]

hm wie wäre es mit dieser version? :

PHP-Code:

<?php
// Quote variable to make safe
function quote_smart($value,$magicfix=false)
{
   // Stripslashes
   if (get_magic_quotes_gpc() AND $magicfix) {
       $value = stripslashes($value);
   }
   // Quote if not integer
   if (!is_numeric($value)) {
       $value = "'" . mysql_real_escape_string($value) . "'";
   }
   return $value;
} 
?>

wenn die variable direkt von $_GET oder $_POST stammt, muss man als zweiten parameter true angeben, sonst wird alles automatisch erledigt.

[VolkerK]

Wenn ich schon Kahlschlagmethode programmieren würde, dann eher

PHP-Code:

<?php 
$post = (get_magic_quotes_gpc()) ? array_map('stripslashes', $_POST) : $_POST;
?>

u.a. auch deshalb, weil ich magic_quotes_gpc für einen Fehler halte.

[Buhmann]

jo, macht wirklich mehr sinn, das ganze aufzuteilen, hast recht

[Jann Hendrik]

Zitat von VolkerK

@Jann Hendrik: hum...such mal am besten erstmal nach Model,View,Controller (MVC)

danke - ich werde suchen - nicht im Moment - aber es stet auf der länger werdenen Liste...