nicht angemeldet
Injection
suitEs sollen direkt in der .htaccess
eventuelle Injections geblockt werden (PHP, MySql).
Wie gehe ich vor?
welche Zeichen müssen gefiltert werden?
< > ' "
RewriteCond %{QUERY_STRING} ......?
RewriteRule .....?
Danke
Phil
-
RewriteCond %{QUERY_STRING} ......?
Hast du schon an Injections per Dateiupload, Cookies, POST oder sonstige Methoden gedacht?
-
Hello,
RewriteCond %{QUERY_STRING} ......?
Hast du schon an Injections per Dateiupload, Cookies, POST oder sonstige Methoden gedacht?Tja, was besonders beliebt ist:
Den Dateinamen, den der Client liefert, dirket in den Namen zu übernehmen,
der auf dem Server angelegt werden soll. Und dann kann man auch meistens eine
PHP- oder soger eine '.htaccess'-Datei hochladen ins aktuelle Script-Verzeichnis.Danach ist der Server offen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Tja, was besonders beliebt ist:
Den Dateinamen, den der Client liefert, dirket in den Namen zu übernehmen,
der auf dem Server angelegt werden soll. Und dann kann man auch meistens eine
PHP- oder soger eine '.htaccess'-Datei hochladen ins aktuelle Script-Verzeichnis.Hallo Tom,
kannst du ein konkretes Beispiel nennen?
Wie lässt sich das verhindern?Danke
Phil
-
kannst du ein konkretes Beispiel nennen?
Annahme, der Dateiname ist folgender:
foo'; DROP TABLE files; SELECT '1$query = "INSERT INTO files (filename) VALUE ('$_FILES['uploadedfile']['name']')";
Natürlich greifen hier automatische Schutzmaßnahmen - z.B. führt mysql_query() nur ein SQL-Statement aus.
-
-
-
-
echo $begrüßung;
Es sollen direkt in der .htaccess
eventuelle Injections geblockt werden (PHP, MySql).deny from all
oder welche Injections meinst du?
Jeder Kontext hat seine eigenen zu beachtenden Zeichen. Wenn du diese vor dem Wechsel in diesen Kontext behandelst, dann wäre das eine deutlich bessere Vorgehensweise als alle möglichen sinnvollen Zeichen gleich von vorn herein auszublenden.
echo "$verabschiedung $name";
-
»» RewriteCond %{QUERY_STRING} ......?
Hast du schon an Injections per Dateiupload, Cookies, POST oder sonstige Methoden gedacht?mit %{QUERY_STRING} könnte man also nur Get blocken?
Gibt es in der htaccess eine Methode POST injections
zu blocken? bis jetzt kenne ich das nur innerhalb von
php (strip_tags(), Magic Quotes etc.).
Wo kann ich mich über Methoden gegen Dateiupload schlauer
machen?Phil
-
bis jetzt kenne ich das nur innerhalb von php (strip_tags(), Magic Quotes etc.).
Weder strip_tags() noch Magic Quotes sind effektive Mittel gegen Angriffe. Zwar ist das besser als nichts, aber trotzdem erst die halbe Miete.
strip_tags ist z.B. ziemlich unsinnig, wenn du SMGL- bzw. HTML- oder XML-Eingaben erlauben willst, tue das oder tue es nicht. Wenn du sie nicht erlauben willst, nutze z.B. htmlspecialchars().
Wo kann ich mich über Methoden gegen Dateiupload schlauer machen?
Mache dich einfach über kontextgerechte Behandlung von Benutzereingaben schlau. Ob es sich um einen Cookie-Wert, einen Dateiupload oder sonstwas handelt ist dabei nebensächlich.
Per .htaccess kannst du dich jedenfalls nicht gegen Injections schützen.
Folge Fox Mulders Grundsatz: Traue niemandem (besonders keinen Benutzereingaben).
-
echo $begrüßung;
Gibt es in der htaccess eine Methode POST injections zu blocken? bis jetzt kenne ich das nur innerhalb von
Injection bedeutet in dem Fall eine ungewollte Einfügung. Nochmal die Frage: Wo genau soll eine Einfügung verhindert werden?
Was soll eine POST-Injection sein? Daten per POST in ein Script einzufügen? Dafür ist es vorgesehen. Wenn du kein POST willst, verhindere das Weiterverarbeiten von POST-Requests. Aber das ist nicht das was du willst. Was _genau_ willst du erreichen?
mit %{QUERY_STRING} könnte man also nur Get blocken?
Wenn du GET-Requests blocken willst, kannst du im Prinzip den Webserver ausschalten. Was _genau_ willst du erreichen?
Wo kann ich mich über Methoden gegen Dateiupload schlauer machen?
Wenn du einen öffentlichen Webserver betreibst, kannst du dich gegen keinerlei Requests schützen, auch nicht solche, die einen Dateiupload darstellen. Die Schutzmaßnahmen gegen unerwünschte Daten sollten für einen konkreten Anwendungsfall betrachtet werden. Was _genau_ willst du erreichen?
echo "$verabschiedung $name";
-
Hello,
Wenn du einen öffentlichen Webserver betreibst, kannst du dich gegen keinerlei Requests schützen, auch nicht solche, die einen Dateiupload darstellen. Die Schutzmaßnahmen gegen unerwünschte Daten sollten für einen konkreten Anwendungsfall betrachtet werden. Was _genau_ willst du erreichen?
http://de3.php.net/manual/en/ini.core.php#ini.sect.file-uploads
Und im Apachen selbst sollte man es auch noch verhindern können, ob man POST, GET, FILEUPLOAD annehmen will, oder nicht. Erkennen kann der das natürlich auch erst, wenn er die Header ausgewertet hat.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
echo $begrüßung;
» Wenn du einen öffentlichen Webserver betreibst, kannst du dich gegen keinerlei Requests schützen, [...]
http://de3.php.net/manual/en/ini.core.php#ini.sect.file-uploads
Und im Apachen selbst sollte man es auch noch verhindern können, ob man POST, GET, FILEUPLOAD annehmen will, oder nicht. Erkennen kann der das natürlich auch erst, wenn er die Header ausgewertet hat.Auch damit schützt man sich nicht gegen die Requests an sich. Es gilt die Weiterverarbeitung von ungewünschten Dingen zu verhindern oder gefahrlos zu gestalten.
echo "$verabschiedung $name";
-
Hello,
» Wenn du einen öffentlichen Webserver betreibst, kannst du dich gegen keinerlei Requests schützen, [...]
http://de3.php.net/manual/en/ini.core.php#ini.sect.file-uploads
Und im Apachen selbst sollte man es auch noch verhindern können, ob man POST, GET, FILEUPLOAD annehmen will, oder nicht. Erkennen kann der das natürlich auch erst, wenn er die Header ausgewertet hat.Auch damit schützt man sich nicht gegen die Requests an sich. Es gilt die Weiterverarbeitung von ungewünschten Dingen zu verhindern oder gefahrlos zu gestalten.
Ja nee, is klar Murat ;-)
Gegen Requests kann man sich (demnächst) nur schützen (lassen), wenn man KiPo auf seiner Seite zeigt.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
wenn man KiPo auf seiner Seite zeigt.
Bei euch in Deutschland wird es schon reichen, wenn der BND sagt, dass Kinderpornographie auf der Seite zu sehen wäre.
-
-
-
-
-
-
Hi,
Es sollen direkt in der .htaccess
eventuelle Injections geblockt werden (PHP, MySql).Wie gehe ich vor?
Gehe so vor:
Lass' den Quatsch.
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak. -
Ich sehe ein, da muss ich anders vorgehen.
Ich wollte eigentlich alle Steuerzeichen filtern,
bzw. als übergebene Variablen nur a-z 0-9 etc.
zulassen um z.B eine sql-injection zu verhindern.Phil
-
echo $begrüßung;
Ich wollte eigentlich alle Steuerzeichen filtern, bzw. als übergebene Variablen nur a-z 0-9 etc. zulassen um z.B eine sql-injection zu verhindern.
Langsam wird es konkret. SQL-Injection verhindert man nicht am Eingang sondern am Ausgang. Denn auch bei der Verarbeitung zwischendrin können Zeichen entstehen, die beim Zusammenstellen eines SQL-Statements zu berücksichtigen sind. Deshalb wendet man die Schutzmaßnahmen erst dann an, wenn sie erforderlich werden.
Das nächste Problem bekommst du bei der Ausgabe in einen HTML-Kontext. Hier sind andere Zeichen zu berücksichtigen als beispielsweise bei SQL-Statements. Und auch hier ist es sinnvoll, erst zum Übergang in den HTML-Kontext die Daten zu behandeln.
Weiter geht es mit den Problemen, wenn weitere Ausgabemedien/-kontexte hinzukommen. All diese Probleme sind keine mehr, wenn du die kontextgerechte Behandlung konsequent berücksichtigst. Du wirst es nicht durchhalten können, dich generell auf die wenigen "guten Zeichen" zu beschränken. Deshalb ist dieser Alles-Böse-Wegfiltern-Ansatz zum Scheitern verurteilt.
echo "$verabschiedung $name";
-
Weiter geht es mit den Problemen, wenn weitere Ausgabemedien/-kontexte hinzukommen. All diese Probleme sind keine mehr, wenn du die kontextgerechte Behandlung konsequent berücksichtigst. Du wirst es nicht durchhalten können, dich generell auf die wenigen "guten Zeichen" zu beschränken. Deshalb ist dieser Alles-Böse-Wegfiltern-Ansatz zum Scheitern verurteilt.
»»
Danke erst mal.noch konkreter:
In einem cms werden alle Anfragen auf ein Auswertungsscript
geleitet:DirectoryIndex /auswertung.php?index.html
RewriteRule ^([a-zA-Z0-9/-]*).html$ /auswertung.php?$1.htmlIn diesem wird das ensprechende Template, ein Modul (z.B Kontent oder
Mailformular) und der zugehörige kontent aus einer MySql DB angefordert.Hier möchte ich gegen alle möglichen Angriffe absichern.
In der .htacccess und/oder in der auswertung.php.Phil
-
Hi,
noch konkreter:
[...]Hier möchte ich gegen alle möglichen Angriffe absichern.
In der .htacccess und/oder in der auswertung.php.Du fragst immer noch so, also ob du noch wenig verstanden hättest.
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak. -
echo $begrüßung;
In diesem [Script] wird das ensprechende Template, ein Modul (z.B Kontent oder Mailformular) und der zugehörige kontent aus einer MySql DB angefordert. Hier möchte ich gegen alle möglichen Angriffe absichern. In der .htacccess und/oder in der auswertung.php.
"Alle möglichen Angriffe" sind nicht verhinderbar. Auch nicht die, an dieser Stelle relevanten. Du denkst noch zu sehr an das Verhindern von Ungewünschtem. Auch in erwünschten Daten können Zeichen enthalten sein, die für einen bestimmten Ausgabekontext eine Sonderbedeutung haben. Konzentriere deine Bemühungen lieber auf das Behandeln gemäß jeweiligem Ausgabekontext. Dabei werden diese Sonderzeichen entschärft, die "guten" und die "bösen". Der Schutz gegen eine Injection ist quasi ein Nebeneffekt der kontextgerechten Behandlung.
echo "$verabschiedung $name";
-
-
-