ModSecurity SecRule basierend auf der ursprünglichen Browser-URL, kein internes Umschreiben (index.php, app.php usw.)

ModSecurity SecRule basierend auf der ursprünglichen Browser-URL, kein internes Umschreiben (index.php, app.php usw.)

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_REQUESTgemäß dieser Antwort verwenden kann:https://stackoverflow.com/a/27968463/160565

:

Ich verwende mod_rewrite, um THE_REQUESTin eine Umgebungsvariable direkt über den mod_security-Regeln zu kopieren und dann darauf abzugleichen.

Wie erwähnt THE_REQUESThandelt 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_REQUESTDie 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_URIVariable (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_URIVariable (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_URIVariable (mod_security) nicht dieselbe ist wie die REQUEST_URIVariable (mod_rewrite), obwohl sie denselben Namen haben. Insbesondere REQUEST_URIenthält (mod_security) die Abfragezeichenfolge, während dies bei REQUEST_URI(mod_rewrite) nicht der Fall ist.

Referenz:


AKTUALISIEREN:

... die REQUEST_URIVariable (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_URIentwederPhase1 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 phaseist eingestellt in derAktionArgument oder SetDefaultActionDirektive. 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:

  1. Anforderungsheader (REQUEST_HEADERS)
  2. Anforderungstext (REQUEST_BODY)
  3. Antwortheader (RESPONSE_HEADERS)
  4. Antworttext (RESPONSE_BODY)
  5. Protokollierung (LOGGING)

Ab ModSecurity Version v2.7 gibt es Aliase für einige Phasennummern:

2 - Anfrage
4 - Antwort
5 - Protokollierung

Beispiel:

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

verwandte Informationen