Hier ist eine interessante für Sie.
Ich habe mein benutzerdefiniertes 500.aspx-Setup, das aufgerufen wird, wenn in meiner Anwendung ein Fehler von 500 auftritt. Der 500.aspx sendet mir auch eine E-Mail mit den Fehlerdetails.
Ich habe ein kleines Problem bemerkt.
Wenn Sie einen xss-Angriff auf den 500.aspx selbst versuchen, wird die 500-Seite nicht aufgerufen.
Dies ist offensichtlich eine Art logisches Problem.
Tatsächlich leidet Microsoft selbst unter dem gleichen Problem.
Sehen Sie es hier in Aktion
Wie kann ich das verhindern?
Ed
Wenn Sie auf einer Seite einen xss-Angriff versuchen, wird die benutzerdefinierte Fehlerseite nicht aufgerufen (hier eineandere zufällige Seite auf Microsoft.com mit xss in der Querystring).
Das Verhalten scheint beabsichtigt zu sein, um den Angriff in seinen Spuren zu stoppen. Sogar die Fehlermeldung zeigt dieses Verhalten an:
Die Validierung der Anfrage hat festgestellt, dass a potenziell gefährliche Client-Eingabe Wert, und Verarbeitung der Anfrage wurde abgebrochen .
Die einzige Problemumgehung scheint darin zu bestehen, die Validierung zu deaktivieren oder den Fehler in Ihrem globalen Ereignis Application_Error zu erfassen und zu behandeln.
Nachdem Sie eine Seite definiert haben, die bestimmte (oder nicht spezifische?) Fehler behandeln soll, scheint sie nicht mehr direkt über ihre URL verfügbar zu sein, so wie die Web.Config nicht über den Browser aufgerufen werden kann.
Ich würde einen 500Test.aspx einrichten, der eine Ausnahme auslöst, die einen Fehler von 500 verursacht (und somit den 500.aspx auslöst)
Das könnte funktionieren.
You möchte möglicherweise daran denken, Ihre Fehler im Ereignis Application_Error in Global.asax.cs anstelle der Seite 500.aspx zu behandeln. Sie könnten den E-Mail-Code dort einfügen und dann den Benutzer auf eine Fehlerseite umleiten, nachdem Sie Ihre Fehlerbehandlung durchgeführt haben (so machen wir es, wo ich arbeite).