Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

nhaack · 11. April 2011 21:28

Hallo zusammen,

ich setze eine CMSMS Installation ein, deren URL Aufbau per eigener Rewriting-Regeln (Apache) an eigene Plugins weiter gegeben wird. Damit ist das System meines Verständnisses nach zunächst einmal "verwundbarer", als wenn ich das nicht tun würde.

In der .htaccess nutze ich folgendes:

Hier klicken, um den Code zum Kopieren zu markieren

[== htaccess ==]

#IF the URI contains a "http:"
RewriteCond %{QUERY_STRING} http\: [OR]
#OR if the URI contains a "["
RewriteCond %{QUERY_STRING} \[ [OR]
#OR if the URI contains a "]"
RewriteCond %{QUERY_STRING} \] [OR]
#OR if the URI contains a "<script>"
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
#OR if the script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
#OR if any script is trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
#OR if the URI contains UNION
RewriteCond %{QUERY_STRING} UNION [OR]
#OR if the URI contains a double slash
RewriteCond %{QUERY_STRING} // [OR]
#OR if the URI contains a *
RewriteCond %{QUERY_STRING} \*
#then deny the request (403)
RewriteRule ^.*$ - [F,L]

In den Plugins selbst nutze mysql_real_escape für alle übergebenen Zeichenketten.

Meine Frage ist:

Der Server wird von einem sehr sicherheitsbewussten Admin betreut, diese Kette würde ich als "secure" bewerten. Aber wenn ich vom Prinzip her Nutzerinput relativ nah an den mysql Queries verwende, schaffe ich damit natürlich ungewollte "Hintertürchen".

Bin ich mit diesen maßnahmen erstmal auf der sicheren Seite und hab' grundsätzlich an alles gedacht oder fehlt mir etwas Wichtiges/Entscheidenes? Sollte ich z.B. noch nach bestimmten mysql Kommandos filtern? Was kann ich selbst in der CMSMS Entwicklung noch beachten, um möglichst keine Lücken zu provozieren?

P.s.: die Plugins nutzen nicht AdoDB (light) sondern setzen direkt mysql ein.

Grüße
Nils

NaN · 12. April 2011 22:11

Hm, da bin ich derzeit genauso ratlos wie Du.
Aber einige Provider können bereits von Haus aus MySQL Befehle herausfiltern.
Weiß nicht wo genau man da ansetzen muss.
Es gab da z.B. mal im .org Forum jemanden, der konnte bestimmte Daten nicht speichern, weil da z.B. das Wort "insert" und irgendwo noch "into" usw. im Text auftauchte.
Das musste dann vom Provider geändert werden.

Ich denke mal, wichtig sind unter Anderem auch noch Anführungszeichen. Damit niemand Deinen MySQL Befehl unterbrechen kann und plötzlich php-Code ausgeführt wird.

Mehr kann ich dazu leider auch nicht sagen.
Ich versuche genau das immer zu vermeiden indem ich die Funktionen des Systems verwende.
Somit ist mein Code zumindest immer genauso sicher wie das CMS.

Andynium · 12. April 2011 10:32

nhaack schrieb:

Sollte ich z.B. noch nach bestimmten mysql Kommandos filtern?

Da fallen wir Befehle wie FILE, GRANT, ALTER, SHOW DATABASE, RELOAD, SHUTDOWN, PROCESS, SUPER ein, die deaktiviert sein sollten.

Ansonsten finden sich hier noch paar interessante Tipps

http://www.greensql.net/publications/my … -practices
http://entwickler.com/itr/news/psecom,i … id,82.html

Andiministrator · 12. April 2011 17:39

Was spricht denn für Dich gegen den Einsatz der AdoDB Funktionen? Die Geschwindigkeit?

nhaack · 12. April 2011 20:50

N'abend zusammen.

Erstmal danke für euer Feedback smile

Ja, warum kein AdoDB? Die Scripte (und Queries) stammen aus einem anderen eigenen Projekt das rein php/mysql basiert ist (und das sind verdammt viele Queries). So gesehen Faulheit bzgl. alles nochmal auf Performancezu prüfen und ggf. überhaupt erstmal umzuschreiben (habe mich mit AdoDB noch garnicht auseinander gesetzt) hat mich nicht wirklich gereizt wink

Es ist kein kritisches Projekt und kein Kundenprojekt, von daher würde ich die genannten Tipps und Lesehinweise nochmal aufgreifen und dann erstmal live gehen wink ... wenn was aufgebrochen wird, werde ich ein Backup nehmen und mir die Logs angucken.

Oder ist AdoDB schon so abgesichert, dass ich es einfacher wäre, das doch nochmal ins Auge zu fassen?

Andynium · 13. April 2011 07:58

nhaack schrieb:

So gesehen Faulheit bzgl. alles nochmal auf Performancezu prüfen und ggf. überhaupt erstmal umzuschreiben (habe mich mit AdoDB noch garnicht auseinander gesetzt) hat mich nicht wirklich gereizt

http://phplens.com/lens/adodb/tute.htm

Andiministrator · 13. April 2011 09:55

AdoDB übernimmt bei richtiger Benutzung die automatische Maskierung von Sonderzeichen & Co. Außerdem kann man sich durch Abfragen wie GetOne() oder GetRow() eine Menge Quelltext sparen ...
Siehe auch: http://adodblite.sourceforge.net/functions.php

Andynium · 13. April 2011 10:06

Bei AdoDB lite hat sich aber auch seit 12/2007 (!) nix mehr getan hat mad , wohingegen die letzte Version von AdoDB full (PHP5) vom 05/2010 datiert.

Möglicherweise gibts mit der lite-Variante und PHP5.3.x Trouble ...

Andiministrator · 13. April 2011 10:11

Kann man die AdoDB Klassen bei CMSms ohne Probleme wechseln?
AdoDB (full) wäre ja sogar noch besser ...

Andynium · 13. April 2011 10:46

Klar doch tongue

http://www.cmsmadesimple.de/forum/viewtopic.php?id=710

nhaack · 14. April 2011 22:08

Mhh... bringt mich ja ins Grübeln ...

das wäre was für einen technischen Refresh ... alles auf adoDB Full umstellen. Ich sehe, dass es bei der Auswahl an möglichen DBs sehr viel mehr Optionen gibt - ich mag das big_smile

Die ganzen Queries umzuschreiben bekommt man auch irgendwie hin ... gibt es bestimmte essentielle Dinge die mit Ado nicht gehen?

Hosting-Ressourcen sind das kleinste Problem big_smile

Grüße
Nils

P.s.: Ich glaube der Beitrag kann in die Bastelstube verschoben werden

Andynium · 14. April 2011 23:37

Auch cachingmäßig geht bei der full mehr

http://phplens.com/adodb/caching.of.recordsets.html
http://www.phpeveryday.com/articles/ADO … t-P22.html

Forum für CMS/made simple

#1 11. April 2011 21:28

Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

#2 12. April 2011 22:11

Re: Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

#3 12. April 2011 10:32

Re: Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

#4 12. April 2011 17:39

Re: Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

#5 12. April 2011 20:50

Re: Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

#6 13. April 2011 07:58

Re: Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

#7 13. April 2011 09:55

Re: Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

#8 13. April 2011 10:06

Re: Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

#9 13. April 2011 10:11

Re: Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

#10 13. April 2011 10:46

Re: Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

#11 14. April 2011 22:08

Re: Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

#12 14. April 2011 23:37

Re: Sanitize Input - Best Practise Ansätze bei der Plugin Entwicklung?

Fußzeile des Forums