Exception Handling und Security
01.10.07 - .NET, Grundlagen, Base Framework, WPF, ASP.NET
Beitrag von
Norbert Eder| | Zum Exception Handling habe ich bereits hier, hier und hier berichtet. Was aber bis dato gefehlt hat, war eine Aussage zum Thema Sicherheit bei der Behandlung von Ausnahmen.
Was also hat das Behandeln von Ausnahmen mit Sicherheit zu tun?
In den meisten Fällen wird bei einer Exception der Inhalt der Eigenschaft Message zurückgegeben und in der Hauptanwendung (egal ob Windows Forms, Web, WPF) zur Anzeige gebracht. Dadurch werden jedoch in manchen Fällen Daten zum Vorschein gebracht, die besser im Verborgenen bleiben sollten. Nehmen wir das Beispiel Webanwendung. Gehen wir weiters davon aus, dass diese eine Verbindung zu einer Datenbank benötigt. Nun wird hier im System ein ConnectionString hinterlegt (natürlich gilt es auch diesen abzusichern). Nun kann folgendes Problem auftreten:
Die Anmeldung auf den Datenbank-Server schlägt fehl. Daraufhin wird eine Exception geworfen, welche dann im User-Interface angezeigt wird (entsweder per eigener Fehlerseite oder überhaupt als Exception). Aus dem Message-Text ist nun ersichtlich, dass die Anmeldung scheitterte und mit welchem User die Anmeldung versucht wurde.
Ein potentieller Angreifer hat nun ein leichteres Spiel, da er einen User für die Datenbank definitiv kennt.
Dies ist nur ein einfaches Beispiel. Aus diesem Grunde sollten Exception-Messages niemals direkt an den User weitergegeben werden. Folgende Vorgehensweise ist hier empfohlen:
1. Jede Exception abfangen
2. Exceptions in eine Log-Datei loggen (Bei Webanwendungen sollte die Log-Datei in ein Verzeichnis geschrieben werden, welches nicht über das Web zugänglich ist)
3. Fehlertexte, die an den User gehen sollten unbedingt zuvor angepasst werden. D.h. ein eigener Wortlaut muss deklariert werden.
Schließlich bleibt noch zu erwähnen, dass dem User nicht jeder Fehler sichtbar gemacht werden muss. Mit vielen Fehlern kann der Unser ohnehin nichts anfangen und sie verwirren ihn nur. Ergo immer überlegen, ob die Benachrichtigung im speziellen Fall sinnvoll ist oder nicht.
|
| | |
Frank
01.10.07
| | Richtig. Idealerweise "übersetzt" man den Text der technischen Fehlermeldung in die Sprache des Benutzers.
Aus einer beispielhaften technischen Exception "User DOMAINusername cannot be logged in into database MYDATABASEdatabse" ist dem User die eine Mitteilung dieser Art anzubieten: "Eines der verbundenen Systeme ist nicht verfügbar. Wir arbeiten gerade an der Beseitigung des Problems und bitten um Ihr Verständnis. Bitte versuchen Sie es später nocheinmal."
Natürlich ist die technische Exception ins Log zu übernehmen, am besten mit den umstehenden Variablen und Objekten, während dem User nur das angezeigt wird, was ihn angeht bzw interessiert: "Das Ding geht grad nicht".
|
| | |
Norbert
01.10.07
| | Danke für das Beispiel. Hatte ich kurz überlegt eines dazu zu packen, aber auf meine Leser ist schließlich auch verlass.
Du hast schon recht mit dem was du sagst. Geloggt werden sollte auf jeden Falles (inkl. aller relevanten Informationen). Der User hingegen sollte nur das wirklich Wichtigste sehen. So ist auch zu überlegen, ob er jeden auftretenden Fehler tatsächlich zu Gesicht bekommen muss. Die meisten sind doch irrelevant für ihn.
|
| | |
Kommentar hinzufügen
Bitte das Formular ausfüllen, um Deinen Kommentar hinzuzufügen.
