Verständnisfrage

[delta]

Was passiert, wenn jemand ein SQL-Fachforum oder einen entsprechenden Blog betreibt und die die verbotenen Begriffe aus (z.B.) dem Wormprotector, in den Beitragstexten vorkommen die von den Usern geschrieben werden?

[Nordin]

dann wird alles gebloggt *g*

ähnliches problem gab es hier auch mal... dafür gab es den bb-code

[spam] [/spam] 
Alles was da zwischen stand wurde nicht geblockt...

Aber ich sag mal so, jemand der ein "SQL-Fachforum" betreibt sollte in der lage sein seine Datenbank so zu schützen das nichts passiert.

[delta]

dann wird alles gebloggt *g*

Das hatte ich befürchtet.

[Nordin]

warum? hast du ein solches forum?

[delta]

warum? hast du ein solches forum?

Nein - aber ein PC-Forum (läuft allerdings unter Perl und ist von daher nicht betroffen) und ein WebMaster-Forum (das läuft unter PHP).
Ich kann also keinen User zwingen, in seinen Textbeiträgen nun unbedingt BB-Code zu verwenden wenn er einen Beitrag zu SQL schreibt.

[Nordin]

das ist richtig... aaaaber die beiträge werden ja nicht per GET gesendet oder? weil nur was per GET kommt wird derzeit auf SQL-Injection geprüft. Das POST wird auf SPAM geprüft... und achtung, siehe hier:

---------
$sqlState = "SELECT ac.*, a.* FROM articlecontent ac INNER JOIN article a ON ac.articleid=a.id AND
ac.active=a.active AND ac.archive=a.archive AND ac.trash=a.trash AND
ac.language=a.language
WHERE a.id=".$articleId." AND a.language=".$lang." AND a.active=1 AND a.archive=0 AND a.trash=0
AND ac.startdate<NOW() AND ac.enddate>NOW();";
---------

im Post wird es nicht geblockt...

[delta]

Da hab ich dann wiederum ein Verständnisproblem.
Gefahr geht immer nur von einem POST Request aus (damit wird an den Server geschrieben).
Der GET Request liefert Serverdaten an den Client (damit wird vom Server gelesen).

Kann es Aufgabe eines externen Programms (hier: CTXtra) sein, die Schwächen eines PHP-Programms abzufangen das im Rahmen eines GET Requests, unsichere SQL-Abfragen zuläßt?

[Nordin]

Also SQL-Injections kommen so gut wie immer über GET...

Die Aufgabe des CTXtra liegt also darin jedes GET auf diese Injections zu prüfen.
Da fast jeder PHP-Neuling nicht weiß das man Parameter die per GET übergeben werden escapen sollte, übernimmt diese Prüfung erfolgreich der CTXtra.

Das YaBB was z.B. bei dir läuft passt von naturaus schon auf genau diese lücken auf.. siehe:
http://www.everyscript.de/cgi-bin/bot-trap/YaBB.pl?action=register&-1%27+union+select+1,2,concat_ws(0x3a,passwort,email),4,5+from+members+limit+1,1/*

und diese angriff kommt über GET... aber diese prüfung haben leider nicht alle scripte...

[delta]

Da fast jeder PHP-Neuling nicht weiß das man Parameter die per GET übergeben werden escapen sollte, übernimmt diese Prüfung erfolgreich der CTXtra.

Hmmm ...
Du meinst also, PHP-Neulinge schreiben PHP-Programme die dann von CTXtra gesichert werden müssen?

Das YaBB was z.B. bei dir läuft passt von naturaus schon auf genau diese lücken auf.. siehe:
http://www.everyscript.de/cgi-bin/bot-trap/YaBB.pl?action=register&-1%27+union+select+1,2,concat_ws(0x3a,passwort,email),4,5+from+members+limit+1,1/*

und diese angriff kommt über GET... aber diese prüfung haben leider nicht alle scripte...

Hehehe ... 
das ist ein Perl Script (und es wird keine relationale Datenbank verwendet).
Ich hab das Teil mit AccessControl (zusätzlich) geschützt, um Harvestern und Spammern etc. den Zugriff nochmals deutlich zu erschweren und insbesondere um DoS Attacken schon im Ansatz zu ersticken.

[Nordin]

Du meinst also, PHP-Neulinge schreiben PHP-Programme die dann von CTXtra gesichert werden müssen?

Nein ich sage das PHP-Anfänger zu 95% nicht wissen wie sie ihre scripte so schreiben sollen das sie nicht "offen" sind... sprich XSS und SQL-Injection... diese User können wenn sie es möchten den CTXtra nutzen.
Ich sage nicht das ihre Programme mit dem CTXtra geschützt werden müssen!

[marc]

Also SQL-Injections kommen so gut wie immer über GET...

Die Aufgabe des CTXtra liegt also darin jedes GET auf diese Injections zu prüfen.

So gut wie immer aber eben nicht nur. Insbesondere wenn Angreifer erkennen das CTXtra als zusätzliches Schutzsystem verwendet wird, liegt es nahe das gerade dann auch andere Methoden versucht / verwendet werden.

Ist es da nicht Sinnvoller gleich alle Methoden zu prüfen?

Grüße
Marc

[Nordin]

ok dann zum verständniss malö für mich:

Wie würdet ihr eine datenbank noch versuchen anzugreifen?

Ein Beispiel wär nicht schlecht....

[marc]

Mal überlegen (bin kein Experte) aber so auf Anhieb würd ich z.Bsp.: einfach mal jedes Textfeld in dem ich auf einer Webseite irgendwas eingeben kann versuchen. Völlig egal ob das per Get oder Post übermittelt wird.

Ein Hinweiß darauf das es auch per Post geht haben wir z.Bsp.: hier:
http://loseproof.blogspot.com/2007/03/sql-injection-im-secvms-0000013.html

in wie weit die anderen $_SESSION, $_REQUEST, $_COOKIE, etc. davon betroffen sind kann ich so nicht sagen. Da du allerdings geschrieben hast das nur $_GET geprüft wird bringt das Script nichts wenn ein Angriff per $_POST kommt oder hab ich da etwas falsch verstanden?

[Nordin]

aso war das gemeint... verstehe...

Das schwierige ist allerdings das ich nicht weis was der user auf allen seiten in diese inputfelder eingibt... oder für was der webmaster diese felder gedacht hat.
Normal müsste man nur das POST auseinander nehmenn und jeden wert durch mysql_escape_string() jagen... dann das post wieder zusammen bauen und weiterlassen... das wars...

wobei ich dann gleich wieder (wenn ich das post auseinander nehme) auf XSS prüfen kann...

[marc]

Wobei ich genau das (insbesondere bei den vielen Scripten die im Umlauf sind wo selbst ich besser schreibe) als Hilfreich empfinden würde.

Stimmt aber, ohne zu wissen welches Feld was enthalten soll wirds schwierig. Dazu müste man erstmal die Felder erkennen und den Betreiber um eine Zuordnung (E-Mail, Text, Link, etc. ) bitten.

Gibt es eigentlich eine Software die XSS Angriffe, etc. erkennen kann?