Teil des Query-String auf Typ prüfen

[Joe User]

Moin,

ich möchte gern Teile des Query-String auf deren Typ prüfen und bei falschem Typ einen Redirect senden. Kennt Jemand von Euch ein passendes Modul für Apache 2.2? mod_rewrite kann es AFAIR leider nicht.

Beispiel:

Code: Select all

http://domain.tld/?param1=0815&param2=text

Wenn param1 nicht vom Typ Integer ist, sende Redirect http://domain2.tld/

Gruss,
Joe User

[Joe User]

Wenn mod_sec nicht so ressourcenhungrig wäre, würde ich es mir ansehen ;)
Die App soll den "falschen" Query-String gar nicht erst zu sehen bekommen, da der betroffene Server bereits mehr als voll ausgelastet ist und durch den Filter entlastet werden soll.

[Joe User]

Als Notlösung werde ich das auch machen, trotzdem bleibt die Frage nach einem entsprechenden ressourcenschonendem Modul für diesen Zweck. Wäre praktisch, wenn es soetwas gäbe.

[dotme]

ich möchte gern Teile des Query-String auf deren Typ prüfen und bei falschem Typ einen Redirect senden. Kennt Jemand von Euch ein passendes Modul für Apache 2.2? mod_rewrite kann es AFAIR leider nicht.

Sowas kann man schon mit mod_rewrite machen, da es ja ein Schweizer Armeemesser ist. :-D
Ob man das dann allerdings für mehr als einen Parameter oder komplexere Tests (als auf int) machen will, sei dahingestellt.

Bei mir scheint folgendes zu funktionieren

Code: Select all

RewriteEngine on

RewriteCond %{QUERY_STRING} "(?:^|&)int=([^&]*)(?:&|$)"
RewriteCond %1 "!^[\d]*$"
RewriteRule test.html http://domain2.tld/ [R=302]

Hier wird per Rückwärtsreferenze der Wert geprüft und in der ersten RewriteRule habe ich den Parameternamen mal verankert, damit er nicht mit ähnlichen lautenden (FOOint) Parametern Probleme hat.

[Joe User]

Interessant, werde ich nächste Woche mal testen, danke!

[hornox]

Gibt es bei der mod_rewrite Lösung keine Sicherheitslücke sobald jemand auf die Idee kommt den Parameter zwei mal zu übergeben? Also http://domain.tld/?int=0815&int=evil
Der Reguläre Ausdruck findet die Zahl, beim Skript landet der String :(

[dotme]

Hehe, guter Einwand. :twisted:
Als Sicherheitsfeature sehe ich die Lösung auch nicht. Ansonsten hängt es natürlich von der Applikation ab wie die mit wiederholten Parametern umgeht - POST-Parameter mal ganz aussen vor gelassen.

[Joe User]

Die Sicherheit wird von der App bereits ausreichend sichergestellt, also jeglicher Input auf Gültigkeit geprüft. Die GETs werden allerdings erst sehr spät geprüft/verarbeitet und die App kann vorerst auch nicht umgeschrieben werden.
Es geht mir lediglich um die weitere Entlastung des Systems, da die App leider etwas ressourcenhungrig ist und nicht unnötig durch "falsche" GETs belastet werden soll.

[daemotron]

Auf die Schnelle würde ich jetzt versuchen, Lighty mit mod_magnet und einem hübschen Lua-Skript als Reverse Proxy davor zu klemmen. Als Ideengeber ein paar Links:

http://www.whmcr.com/2009/06/lighttpd-m ... od_magnet/
http://nordisch.org/2007/2/4/how-to-use-cleanurl-lua
http://nordisch.org/cleanurl-v5.lua

Kurze Begründung: ich halte es nicht für so arg sinnvoll, den Apachen diese Aufgabe mit übernehmen zu lassen. OK, mit mod_rewrite hindert man ihn daran, ein PHP-Skript auszuführen, aber mod_rewrite ist nicht gerade das, was man im Allgemeinen unter "schnell und schlank" versteht... (nicht so schlimm wie mod_sec, aber immer noch... na ja.) Lighty den Request im Vorfeld verwerfen zu lassen ist vermutlich die "billigste" Lösung. Einen Haken hat die Sache aber: mod_proxy von Lighty ist qualitativ nicht auf dem höchsten Niveau. Für die meisten Webapps geht's; sobald aber HTTP Header Auth oder WebDAV ins Spiel kommen, wird's kritisch. Andere Kandidaten wie Nginx oder Pound bieten leider nicht so flexible Filtermöglichkeiten.

Eine Alternative wäre noch Varnish - mit Inline C Code kann man's da auch so richtig krachen lassen :D

[Joe User]

Es handelt sich um eine "Embedded"-Kiste mit gerade mal 128MB RAM, nur noch 230kB freiem Plattenplatz und per Policy vorgeschriebener Software, da bleibt nicht viel Spielraum für die üblichen Lösungen ;)

Immerhin werden die Apps nächstes Jahr in C reimplementiert, so dass wieder mehr Luft entsteht. Bis dahin muss mod_rewrite (wird ohnehin bereits verwendet) oder eine schlankere Alternative herhalten.