☰

Htacess Helicon APE falsch positiv 403 Fehler

tag-icon • tag-icon iis .htaccess mod-rewrite
Htacess Helicon APE falsch positiv 403 Fehler

Anstatt web.configfür meine Umschreibregeln zu verwenden, habe ich verwendetHelikon APEzur Emulation der Apache- .htaccessFunktion.

Ich habe eine große universelle .htaccessDatei, die auf dem gesamten Server als Teil einer Funktion angewendet wird, um den Zugriff auf die Weitergabe von Befehlen wie Union, Delete usw. einzuschränken.

Ich stoße jedoch auf ein Problem, bei dem eine Codezeile ein falsches Positiv erzeugt und den Zugriff auf eine ansonsten ordnungsgemäße URL blockiert.

Die fehlgeschlagene URL lautet:http://example.com/union-contracts

Mit dem folgenden Befehl web.configwerden alle fehlenden URLs nach gesendet index.php.

   <httpErrors errorMode="Custom" existingResponse="Replace">
        <remove statusCode="404" subStatusCode="-1" />
        <error statusCode="404" path="/index.php" responseMode="ExecuteURL" />
    </httpErrors>

htaccess-Regel, die 403 zurückgibt

RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC]
RewriteRule . - [F,L]

Letztendlich möchte ich beispielsweise weiterhin die Union blockieren, ich muss nur die Zeile für falsche Positivwerte ändern. Bitte beachten Sie, dass ich auch nicht danach strebe, in meiner Regel -contractsfest codiert zu sein ..htaccess

Ich konnte das Problem in htaccess in XAMPP duplizieren, nachdem ich mich daran erinnert hatte, wie die URL ursprünglich generiert wird.

Wenn auf der Besucherseite der Website auf eine URL zugegriffen wird, generiert der Server einen 404-Fehler. Ich filtere die URL bis auf den letzten Teil heraus und vergleiche die Datenbank mit dieser Zeichenfolge, um zu sehen, ob sie mit einer gespeicherten URL übereinstimmt. Wenn ja, gebe ich diese 404-Fehlermeldung nicht an den Browser weiter. Sie wird nur weitergegeben, wenn die URL nicht gefunden werden kann.

Wenn IIS einen 404-Fehler generiert, lautet die URL:

index.php?404;http://example.com:80/union-contracts

In diesem Format wird es jedoch nicht an den Browser weitergegeben.

Antwort1

Ich habe in Kommentaren meine Besorgnis darüber zum Ausdruck gebracht, dass da „etwas anderes“ vor sich gehen muss, aber egal …

Es ist schwierig, eine Ausnahme für eine Regel zu schreiben, die eigentlich nicht ausgelöst werden sollte (lies: „kann“) - das ist reines Rätselraten. Warum sollte dieAusnahmegeehrt werden?

Diese Regel sollte die gegebene Anfrage bereits aus mehreren „wichtigen“ Gründen vermeiden:

  1. Die Anfrage enthält keine Abfragezeichenfolge.
  2. Der reguläre Ausdruck in der Bedingung (Bedingungsmuster) stimmt mit keinem Teil der URL überein (auch wenn dieser in der Abfragezeichenfolge enthalten war).

In Anbetracht von Nr. 2 oben enthält der reguläre Ausdruck bereits eine ausreichende Ausnahme, um nicht mit der gegebenen Anforderung übereinzustimmen. Wie können wir also „eine weitere“ Ausnahme implementieren?

Sie können dieBedingungsmuster-Um Fälle zu vermeiden, in denen auf das Wort "union" ein Bindestrich ( ) folgt, verwenden Sie einnegativer Vorausblick. Zum Beispiel:

(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union(?!-)|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode)

Das obige trifft also zu Xunion, aber nicht zu Xunion-, wobei Xeine der Zeichenfolgen aus dem erstenWechselGruppe (dh. (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00)).

Oder wenn auf eines dieser Schlüsselwörter ein Bindestrich folgt:

(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode)(?!-)

(AKTUALISIEREN:Die folgenden beiden Vorschläge werden wahrscheinlich nicht funktionieren, da die Anweisungen anscheinend nur verarbeitet werdennachIIS hat die URL bereits umgeschrieben. An diesem Punkt lautet der URL-Pfad einfach /index.php, nicht /union-contracts.)

Oder ändern Sie die Regel RewriteRuleso, dass sie nicht übereinstimmt, wenn der URL-Pfad mit beginnt /union-(obwohl dies möglicherweise eine Hintertür für den XSS-Versuch bietet, den die Regel zu blockieren versucht). Beispiel:

RewriteRule !^/?union- - [F]

(Zumindest unter Apache List das Flag nicht erforderlich, wenn es Fverwendet wird – es ist impliziert.)

Alternativ können Sie eine weitere Regel anlegen beiSpitze, vor Ihren bestehenden Regeln, die eine Ausnahme für die Anforderung einer URL erstellt, die beginnt /union-und keine Abfragezeichenfolge enthält (obwohl dies ein Widerspruch zu sein scheint, wenn man der anderen Regel Glauben schenken darf). Beispiel:

RewriteCond %{QUERY_STRING} ^$
RewriteRule ^/?union- - [L]

Dies kann jedoch dazu führen, dass die Anforderung „abgebrochen“ wird, wenn sich später in der Datei andere Regeln befinden, die die URL irgendwie umschreiben müssen – da diese nicht auftreten.

Ich gehe davon aus, dass Helicon-APE/mod_rewrite in einemverzeichnisähnlichKontext (z. B. .htaccessStilsyntax im Gegensatz zuServerodervirtueller HostKontext)? Dies sollte jedoch die obigen Anweisungen nicht beeinflussen, wie es der Fall ist.

AKTUALISIEREN:Wenn IIS einen 404-Fehler generiert, lautet die URL:

index.php?404;http://example.com:80/union-contracts

Ah ja! Diese URLWillewird vom ursprünglichen Zustand erfasst. Es scheint also, dass die mod_rewrite-Direktiven verarbeitet werdennachdas IIS-"Rewrite" in web.config! Dies macht diese "Sicherheits"-Direktiven etwas überflüssig oder sogar falsch, da sieangeblichdie bei der ersten Anforderung des Clients ausgeführt werden soll. Und....

Ich filtere die URL bis auf den letzten Teil heraus und vergleiche die Datenbank mit dieser Zeichenfolge, um zu sehen, ob sie mit einer gespeicherten URL übereinstimmt.

Da Sie die URL aktiv analysieren und nur den Teil herausfiltern, den Sie benötigen, scheinen diese „Sicherheits“-Prüfungen zumindest für diese „404“-Anfragen ohnehin überflüssig zu sein. (Könnte eine bösartige Abfragezeichenfolge dieser Art tatsächlich eine Sicherheitsbedrohung für jede URL darstellen, je nachdem, welche echten Dateien (d. h. Nicht-404-Anfragen) möglicherweise direkt angefordert werden?)

Die beiden obigen Vorschläge zur Änderung des regulären Ausdrucks in derZustandum Fälle auszuschließen, in denen auf das Schlüsselwort „union“ ein Bindestrich folgt, oderbeliebigSchlüsselwort, würde hier immer noch zutreffen und würde das unmittelbare Problem scheinbar lösen.

Sie können auch alle Prüfungen abbrechen, wenn eine URL des Formulars index.php?404;gefunden wird (d. h. nachdem sie von IIS neu geschrieben wurde). (Ich gehe davon aus, dass alle Ihre mod_rewrite-Direktiven ähnliche „Sicherheits“-Prüfungen sind?)

Fügen Sie beispielsweise Folgendes hinzu zuSpitzedes .htaccessDrehbuchs,Vordie bestehenden Richtlinien:

RewriteCond %{QUERY_STRING} ^404;
RewriteRule ^/?index\.php - [L]

Dies sollte jede weitere Verarbeitung verhindern, wenn eine URL des Formulars /index.php?404;......gefunden wird. (Da Sie die URL in Ihrem Skript ohnehin analysieren.)

verwandte Informationen