.png)
Ich arbeite an einer Symfony 2-Site und versuche, eine ModSecurity-Regel zu erstellen, die mit einer bestimmten Browser-URL übereinstimmt. IE example.com/results
Symfony 2 schreibt intern alle Anfragen an app.php um, indem es Regeln in .htaccess verwendet. Wenn ich also REQUEST_URI in der ModSecurity-Regel überprüfe, wird es auf app.php gesetzt. Ich habe alle anderen Serverparameter ausprobiert, die relevant erscheinen, aber alle sind entweder app.php oder leer.
Gibt es eine Möglichkeit, in einer Konfigurationsdatei eine ModSecurity-Regel zu erstellen, die auf der vom Browser angeforderten URL und nicht auf dem Ergebnis einer internen Umschreibung basiert?
Das gleiche Problem scheint bei CMS wie WordPress aufzutreten: Alles wird in index.php umgeschrieben, daher kann ich keine Möglichkeit finden, Modsec-Regeln auf eine bestimmte Route anzuwenden. (Ich dachte, da WP so weit verbreitet ist, könnte ich vielleicht eine Antwort finden, wenn ich dort nach dem gleichen Problem suche.)
Antwort1
Es sieht so aus, als ob ich die Servervariable
THE_REQUEST
gemäß dieser Antwort verwenden kann:https://stackoverflow.com/a/27968463/160565:
Ich verwende mod_rewrite, um
THE_REQUEST
in eine Umgebungsvariable direkt über den mod_security-Regeln zu kopieren und dann darauf abzugleichen.
Wie erwähnt THE_REQUEST
handelt es sich um eine von mod_rewrite verwendete Apache-Servervariable und nicht um eine mod_security-Variable. Die direkt äquivalente Variable in mod_security ist REQUEST_LINE
, also die erste Zeile der Anfrage. Diese hat die Form einer Zeichenfolge wie:
GET /foo/bar HTTP/1.1
THE_REQUEST
Die Variable (mod_rewrite) ändert sich nicht, wenn die URL neu geschrieben wird, während dies bei REQUEST_URI
(mod_rewrite) der Fall ist.
Ich bin jedoch etwas überrascht, dass die REQUEST_URI
Variable (mod_security) die umgeschriebene URL zurückgibt (vielleicht hat das mit der Reihenfolge der Anweisungen oder der Verwendung von mod_security zu tun).eingebettet?), anstelle der ursprünglich angeforderten URL, es sei denn, Sie verwenden tatsächlich die REQUEST_URI
Variable (mod_rewrite) (indem Sie diese einer Umgebungsvariable zuweisen?) in Ihrer Mod_Security-Regel?
direkt über den Mod_Security-Regeln ...
Die Mod_Security-Regeln sollten wahrscheinlich am Anfang Ihrer Datei stehen, wenn nicht bereits, vor allen Mod_Rewrite-Direktiven. (Obwohl ich nicht sicher bin, ob die Reihenfolge wirklich wichtig ist.)
Beachten Sie, dass die REQUEST_URI
Variable (mod_security) nicht dieselbe ist wie die REQUEST_URI
Variable (mod_rewrite), obwohl sie denselben Namen haben. Insbesondere REQUEST_URI
enthält (mod_security) die Abfragezeichenfolge, während dies bei REQUEST_URI
(mod_rewrite) nicht der Fall ist.
Referenz:
AKTUALISIEREN:
... die
REQUEST_URI
Variable (mod_security) gibt die umgeschriebene URL zurück
Möglicherweise führen Sie die mod_security-Regel zu spät in der Anfrage aus, d. h. in der falschen phase
? Um dieangefordertURL, mit der Sie vergleichen sollten, REQUEST_URI
entwederPhase1 oder 2 (die Anfrage). Spätere Phasen (z. B. 3 bis 5) verarbeiten die Antwort, was erklären könnte, warum Sie die umgeschriebene URL und nicht die angeforderte URL sehen.
Das phase
ist eingestellt in derAktionArgument oder SetDefaultAction
Direktive. Beispiel:
SecDefaultAction "log,pass,phase:2,id:4"
SecRule REQUEST_URI "attack" "phase:1,id:52,t:none,t:urlDecode,t:lowercase,t:normalizePath"
Die fünf Phasen sind:
- Anforderungsheader (REQUEST_HEADERS)
- Anforderungstext (REQUEST_BODY)
- Antwortheader (RESPONSE_HEADERS)
- Antworttext (RESPONSE_BODY)
- Protokollierung (LOGGING)
Ab ModSecurity Version v2.7 gibt es Aliase für einige Phasennummern:
2 - Anfrage
4 - Antwort
5 - ProtokollierungBeispiel:
SecRule REQUEST_HEADERS:User-Agent "Test" "phase:request,log,deny,id:127"
Referenz:
Antwort2
Es sieht so aus, als könnte ich die Servervariable THE_REQUEST gemäß dieser Antwort verwenden:https://stackoverflow.com/a/27968463/160565