SQL-Injektion - Infoseite gesucht

[syco23]

Hi,

Hier gab es doch mal einen Thread mit diversen Infoseiten bezügl. Sicherheit. Leider habe ich ihn trotz intensivem Suchen nicht gefunden.

Stichwort: Wir gestalte ich eine Seite mit Userinteraktion sicher? Was sind die häufigsten Fehler?

Gruß,
syco23

[matz0r]

Und mit welcher Sprache willst du auf die DB zugreifen? Du lässt die User wohl kaum auf die sql-Kommandozeile los?

Du musst einfach alle SQL-Eingaben, die vom User beeinflusst werden können escapen! In PHP wäre z.B.: http://de.php.net/manual/en/function...ape-string.php dafür zuständig!

[Shurakai]

Original geschrieben von matz0r
Du musst einfach alle SQL-Eingaben, die vom User beeinflusst werden können escapen! In PHP wäre z.B.: http://de.php.net/manual/en/function...ape-string.php dafür zuständig!

Jein, dann wäre immernoch XSS möglich. Auch auf HTML musst du prüfen - und am besten garnicht erst HTML erlauben...

[Abraxax]

dafür gibt es htmlentities() und andere schöne sachen. ;-)

[Shurakai]

Original geschrieben von Abraxax
dafür gibt es htmlentities() und andere schöne sachen. ;-)

So ist es
Ich wollte das ganze nur Ergänzen, denn wer sich IMHO vor ner SQL-Injection schützen will, sollte sich auch vor XSS dementsprechend schützen. Und zu denken man ist mit mysql_real_escape_string sicher, ist wohl leider nicht richtig.

Demnächst gibts irgendwann mal auf www.multimediatreff.de nen paar Folien zum downloaden, die haben letzte Woche dadrüber 8 Stunden lang nen Vortrag gehalten mit Beispielen usw.... vielleicht schaust du da ja irgendwann mal vorbei wenns online ist.


Achja, auf Wikipedia gibts auch einige Infos. Aber das Meiste wurde wohl schon gesagt...

[Abraxax]

Ich wollte das ganze nur Ergänzen, denn wer sich IMHO vor ner SQL-Injection schützen will, sollte sich auch vor XSS dementsprechend schützen

so ist es.

[matz0r]

Original geschrieben von matz0r
Und mit welcher Sprache willst du auf die DB zugreifen? Du lässt die User wohl kaum auf die sql-Kommandozeile los?

Du musst einfach alle SQL-Eingaben, die vom User beeinflusst werden können escapen! In PHP wäre z.B.: http://de.php.net/manual/en/function...ape-string.php dafür zuständig!

Mhhm auch wieder Jein... Im Prinzip hast du recht, aber fällt für mich eigentlich nicht unter SQL-Injection. Da es ja nicht immer prinzipiell für alle User verboten sein muss html Befehle in die Datenbank zu schreiben, bzw sie beim auslesen umzuwandeln.

Aber erwähnenswert ist es, ihr habt scho recht!

[syco23]

Danke für eure Meldungen.

Habe mir das ganze jetzt genauer angesehen.

Wirklich "einfach" scheint nur das Einloggen ohne Passwort zu sein, sofern ein GET-Parameter nicht geprüft wird.

Ein "Vorteil" von PHP ist weiterhin, dass in einem Aufruf von mysql_query() nicht wie in anderen Programmiersprachen 2 SQL-Statements (z.B. ein DELETE-Statement) ausgeführt werden können, sondern jeweils ein seperater Aufruf von mysql_query nötig ist.

Quelle: Wikipedia. Kann ich mich darauf verlassen? Auf anderen Seiten wird das Gegenteil behauptet bzw. als Beispiel aufgeführt.

Über Url-Parameter, die für SELECT-Anweisungen benutzt werden kann man Datenbanken also nicht modifizieren (?)

XSS ist "nur" für die Besucher gefährlich (und natürlich für den Betreiber der seine eigene Seite aufruft)..

Kann man ein Projekt, das folgendes befolgt als sicher bezeichnen

-) Register globals = off
-) vermeidung von eval()
-) admin-bereich mit htaccess gesichert
-) am Anfang jedes Scripts: is_numeric() für alle INT-Parameter, restliche Parameter werden nicht in SQL-Anweisungen übernommen, sondern nur für Fallunterscheidungen verwendet
-) vor INSERT/UPDATE htmlspecialchars(*,ENT_QUOTES) und / oder Variablenpürfung.

[Shurakai]

1.) Das von Wikipedia stimmt so. Es ist nicht möglich, nach einem SELECT einen DELETE mit nur 1 Aufruf von mysql_query() abzusetzen.
Wer behauptet denn was anderes?


2.) Sicher ist immer relativ... Nimm auf jedenfall noch mysql_real_escape_string bei allen Parametern, die NICHT von dir kommen -> alle Parameter von außerhalb sind potenziell verseucht.
Und an sich würde ich nicht beim Speichern / Updaten htmlspecialchars bzw. htmlentities() benutzen (letzteres benutze ich), sondern bei der AUSGABE. Denn sonst hast du den Kram so in der DB stehen, was bei einer späteren Manipulation evtl. weniger sinnvoll ist. Darfst beim ausgeben das natürlich nicht vergessen....