Danke an alle, die eine Antwort kommentiert oder gepostet haben! Ich habe meine ursprüngliche Frage beibehalten und aktualisiere sie der Vollständigkeit halber.
[Feb 16, 2011 - Update 2] Einige Leute haben darauf hingewiesen - meine Frage hätte lauten müssen: Wenn ich ein standardmäßiges asp.net 4 Formular habe, wenn ich keine serverseitige Validierung habe, welche Arten von Für bösartige Angriffe bin ich anfällig?
Hier ist mein Auszug zu diesem Thema.
Bitte zögern Sie nicht, weiter zu kommentieren ... wenn eines der oben genannten Dinge nicht korrekt ist, lassen Sie es mich bitte wissen. Danke!
[3. Februar 2011 - Update 1] Ich möchte allen für ihre Antworten danken! Vielleicht sollte ich die umgekehrte Frage stellen:
Nehmen Sie ein einfaches asp.net 4.0-Webformular (formview + Datenquelle mit Anforderungsvalidierung aktiviert) an, mit dem angemeldete Benutzer Kommentare auf einer öffentlichen Seite posten können (in sql server db gespeicherte Kommentare) Tabelle) . Welche Art von Datenvalidierung oder -bereinigung sollte ich für die neuen "Kommentare" auf der Serverseite durchführen?
[19. Januar 2011 - Ursprüngliche Frage] Unsere asp.net 4-Website enthält einige Formulare, auf denen Benutzer Daten übermitteln können, und wir verwenden jquery validate auf der Clientseite. Benutzer müssen mit einem gültigen Konto angemeldet sein, um auf diese Formulare zugreifen zu können.
Ich verstehe, dass unsere clientseitigen Validierungsregeln leicht umgangen werden können und Kunden Daten ohne Pflichtfelder etc. posten könnten. Das geht mich nicht besonders an - Benutzer müssen eingeloggt sein und ich betrachte unsere Daten nicht sehr "Sensitiv" noch würde ich sagen, dass unsere Validierung "kritisch" ist. Die Eingabedaten werden mithilfe von SqlParameters in die Datenbank geschrieben (um die SQL-Injection zu verhindern), und wir sind von der Validierung der asp.net-Anfrage abhängig, um potentiell gefährliche HTML-Eingaben zu vermeiden.
Ist es wirklich unsere Zeit wert, die verschiedenen jquery Validierungsregeln auf dem Server neu zu schreiben? Wie könnte ein böswilliger Benutzer unseren Server kompromittieren oder welchen spezifischen Angriffen könnten wir ausgesetzt sein?
Ich entschuldige mich, dass diese Frage auf dieser Website einige Male diskutiert wurde - aber ich muss noch eine Antwort finden, die auf bestimmte Risiken oder Probleme hinweist, wenn die serverseitige Validierung nicht durchgeführt wird. Vielen Dank im Voraus
Hypothetische Situation:
Nehmen wir an, Sie haben ein Postleitzahlfeld. Auf der Clientseite validieren Sie, dass es in einem Muster "00000" oder "00000-0000" sein muss. Da Sie einen Bindestrich zulassen, entscheiden Sie, das Feld als Varchar in der Datenbank zu speichern.
Es kommt also ein böser Benutzer und beschließt, alle Ihre clientseitigen Validierungen zu umgehen und etwas zu übermitteln, das nicht im richtigen Format ist und die Validierung der Anfrage hinter sich hat.
Ok, keine große Sache ..., Sie codieren es, bevor Sie es später dem Benutzer wieder anzeigen.
Aber was machst du sonst noch mit dieser Postleitzahl? Senden Sie es an den Web-Service für eine Art von Lookup? Laden Sie es auf ein GPS-Gerät hoch? Wird es jemals von etwas anderem in der Zukunft interpretiert werden? Enthält Ihr Postleitzahlenfeld jetzt etwas JSON oder etwas anderes Seltsames?
Oder so etwas: Ссылка
Sicherheit ist ein Zuverlässigkeitsattribut, das definiert ist als die Wahrscheinlichkeit, dass das System einem Angriff widersteht , oder die Wahrscheinlichkeit, dass ein Fehler nicht böswillig aktiviert wird
>Um die Sicherheit zu implementieren, müssen Sie eine Bedrohungsanalyse durchführen. Komplexe Computersysteme unterliegen tieferen Analysen (denken Sie an die Ausrüstung eines Kontrollturms eines Flugzeugs), wenn diese kritischer werden und Bedrohungen das wirtschaftliche oder menschliche Leben in Gefahr bringen .
>
Sie können eine eigene Bedrohungsanalyse durchführen, indem Sie sich selbst fragen Was passiert, wenn ein Benutzer die Validierung umgeht? .
Zwei Gruppen von Antworten, anhand von Beispielen:
Gruppe 1 (kritisch)
Gruppe 2 (nicht kritisch)
Im ersten Fall müssen Sie definitiv Ihr Validierungsproblem beheben, weil Sie nach einem Angriff Geld verlieren oder das Vertrauen Ihrer Öffentlichkeit verlieren könnten (denken Sie daran, Facebook-URLs zu schmieden und sogar die Fotos von jemandem zu zeigen wenn Sie nicht miteinander befreundet sind).
Wenn Sie im zweiten Fall sicher sind, dass ein inkonsistentes Feld Ihr Unternehmen oder die Daten nicht gefährdet, vermeiden Sie möglicherweise die Korrektur
Wie können Sie beweisen , dass inkonsistente Daten, die an Ihre Website gesendet werden, nie Auswirkungen auf das System haben sollten, die eine Bedrohung darstellen könnten?
Das ist der Grund, warum Sie weniger Zeit verlieren, Ihre Validierung zu überprüfen, als darüber nachzudenken
Ehrlich gesagt ist es den Nutzern egal, was Sie als "sensible" oder "kritische" Daten ansehen. Diese Kriterien müssen sie selbst entscheiden.
Ich weiß, dass ich, wenn ich ein Nutzer Ihrer Bewerbung war und meine Daten geändert haben, ohne dass ich direkt etwas getan habe, um die Änderung herbeizuführen ... Ich würde mein Konto so schnell wie möglich schließen. Es wäre leicht ersichtlich, dass Ihr System nicht sicher war und keine meiner Daten sicher war.
Denken Sie daran, dass Sie Leute dazu zwingen, sich einzuloggen, damit Sie zumindest ihre Passwörter irgendwo haben. Ob sie leicht zugänglich sind oder nicht, eine Verletzung ist eine Verletzung und ich habe mein Vertrauen verloren.
Also ... während Sie einen Input-Injection-Angriff nicht für wichtig halten, werden Ihre Benutzer und das deshalb die serverseitige Eingabevalidierung trotzdem durchführen.
Ihre Daten sind vielleicht nicht viel wert, das ist für mich in Ordnung.
ABER, Angreifer könnten CSRF Angriffscode "Cross Site Request Forgery" in Ihre Anwendung einfügen; Benutzer Ihrer Site dürfen ihre Daten an anderen Sites kompromittiert haben. Ja, es würde verlangen, dass diese "anderen Seiten" Fehler haben, aber das passiert. Ja, es würde erfordern, dass Benutzer die "Abmelden" -Schaltflächen auf diesen Websites nicht verwenden, aber nicht genug Leute sie verwenden. Denken Sie an all die leckeren Daten, die Ihre Nutzer auf anderen Websites gespeichert haben. Sie würden Ihren Benutzern nichts Schlimmes passieren.
Angreifer können HTML einbringen, das Benutzer dazu auffordert, "Plugins, die für die Anzeige dieses Inhalts erforderlich sind" herunterzuladen und zu installieren - Plug-ins, die Keylogger sind, oder Festplatten nach Kreditkartennummern oder Steuereinreichungen zu durchsuchen. Vielleicht ein Plugin, um Spambots oder Porno-Hosts zu werden. Ihre Nutzer vertrauen darauf, dass Ihre Website Plugins, die Eigentum der Yakuza sind, nicht empfiehlt, oder? Sie fühlen sich möglicherweise nicht freundlich, wenn Ihre Seite empfiehlt, böse Dinge zu installieren.
Je nachdem, welche Arten von Fehlern durch ungültige Daten ausgelöst werden, finden Sie sich möglicherweise als Spambot oder Porno-Host. Es hängt stark davon ab, wie defensiv Sie andere Aspekte Ihrer Anwendung codiert haben. Zu viele Anwendungen vertrauen den Eingabedaten blind.
Und der beste Teil: Ihre Benutzer sind nicht menschlich. Ihre Benutzer sind Browser , die möglicherweise Angriffe ausführen, die von anderen Sites stammen, die sich nicht um eine gute Eingabevalidierung und um die Bereinigung der Ausgabe gekümmert haben. Ihre Benutzer sind Viren oder Würmer, die zufällig oder durch Design auf Sie stoßen. Sie können den Einzelpersonen vertrauen, aber wie weit vertrauen Sie ihren Computern? Ich, nicht sehr weit.
Bitte schreiben Sie Anwendungen so sicher wie Sie können - Sie können eine große Taste auf der Titelseite setzen, um alle Benutzerdaten zu löschen, wenn Sie wollen - aber bitte schreiben Sie nicht absichtlich unsichere Programme.
Das ist eine ausgezeichnete und mutige Frage. Die kurze (und vielleicht mutige) Antwort ist, dass du es nicht tust. Wenn Sie alle Sicherheitslücken kennen und immer noch nicht glauben, dass es notwendig ist, dann haben Sie die Wahl.
Es hängt wirklich davon ab, wer Ihre Benutzer sind, wem die Website (in Bezug auf Intranet oder Internet) ausgesetzt ist und wie einfach es ist, ein Konto zu erhalten. Sie sagen, dass Ihre Daten nicht sensibel sind, Sie aber immer noch Benutzer anmelden müssen. Wie schlimm wäre es, wenn ein nicht autorisierter Benutzer auf das System zugreifen würde, indem er auf den Rechner eines anderen Benutzers springt, während sie woanders waren?
Bedenken Sie, dass die Überprüfung der Anfrage auf böswillige Eingaben niemals hundertprozentig sicher ist, so dass die Sicherheit normalerweise auf mehreren Ebenen mit einer gewissen Redundanz erfolgt.
Allerdings muss es Ihre Wahl sein und Sie tun das Richtige, um die Konsequenzen herauszufinden, die sich daraus ergeben.
Ich glaube, dass Sie sowohl auf der Clientseite als auch auf der Serverseite überprüfen müssen, und hier ist der Grund.
Auf der Clientseite speichern Sie den Benutzer häufig davor, Daten zu übermitteln, die offensichtlich falsch sind. Sie haben kein Pflichtfeld ausgefüllt. Sie haben Buchstaben in ein Feld gesetzt, das nur Zahlen enthalten soll. Sie haben ein Datum in der Zukunft angegeben, wenn nur ein Datum in der Vergangenheit (wie Geburtsdatum) tun wird. Und so weiter. Indem Sie diese Art von Fehlern auf der Clientseite vermeiden, vermeiden Sie Benutzerfrustration und reduzieren auch die Anzahl unnötiger Zugriffe auf Ihren Webserver.
Auf der Serverseite sollten Sie im Allgemeinen alle Prüfungen wiederholen, die Sie auf der Clientseite durchgeführt haben. Wie Sie gesehen haben, können clevere Benutzer die clientseitige Validierung umgehen und ungültige Daten übermitteln. Darüber hinaus gibt es eine Validierung, die auf der Clientseite ineffizient oder unmöglich ist. Manchmal überprüfen Sie, ob der Dateneintrag den Geschäftsregeln entspricht. Sie können es mit vorhandenen Daten in der Datenbank überprüfen. Wenn Sie nur zulassen, dass Benutzer etwas eingeben (insbesondere erforderliche Felder auslassen), funktioniert die Website für sie nicht ordnungsgemäß.
Wer HTTP-POSTs über die Website (mit jQuery-Validierung) auf Ihrem Server ausführt, kann HTTP-POSTs auch auf andere Weise ausführen, die die jQuery-Validierung umgehen. Zum Beispiel könnte ich System.Net.HttpWebRequest verwenden, um einige Daten an Ihren Server mit den entsprechenden Cookies zu senden, die schädlichen Inhalt in die Formularfelder injizieren. Ich müsste die Felder __EVENT_VALIDATION und __VIEWSTATE korrekt einrichten, aber wenn es mir gelingt, würde ich die Validierung umgehen.
Wenn Sie keine serverseitige Datenvalidierung haben, werden die Eingaben tatsächlich nicht validiert. Die jQuery-Validierung ist zwar schön für die Benutzererfahrung, aber keine echte Verteidigungslinie.
Dies ist besonders bei Eingaben wie einem Freiform-Kommentarfeld der Fall. Sie möchten auf jeden Fall sicherstellen, dass das Feld kein HTML oder anderes bösartiges Skript enthält. Als zusätzliche Verteidigungsmaßnahme sollten Sie auch den Kommentarinhalt umgehen, wenn dieser in Ihrer Web-App mit einer Bibliothek wie AntiXss angezeigt wird (siehe Ссылка ).
In Bezug auf die clientseitige vs. serverseitige Validierung ist meine Meinung, dass die clientseitige Validierung nur dafür sorgt, dass das Formular korrekt ausgefüllt wird und ein Benutzer das Formular manipulieren und die in JavaScript durchgeführten Überprüfungen umgehen kann .
Auf der Serverseite können Sie tatsächlich sicherstellen, dass Sie diese Daten tatsächlich speichern und gründlich prüfen und relative Datenbanktabellen überprüfen möchten, um sicherzustellen, dass Ihre Datenbank immer mit allen Datensätzen normalisiert wird, die Sie vom Client erhalten . Ich würde sogar sagen, dass die Server-Seite wichtiger ist als die Client-Seite in Bezug darauf, dem Benutzer nicht anzuzeigen, wonach Sie im Formular suchen und wie Sie die Daten validieren.
Zusammenfassend empfehle ich die Überprüfung auf beiden Seiten, aber wenn ich zwischen den beiden wählen müsste, würde ich eine serverseitige Validierung empfehlen, aber das könnte bedeuten, dass Ihr Server möglicherweise zusätzliche Validierungen durchführt, die Sie möglicherweise nicht validieren konnten die Clientseite
Um Ihre zweite Frage zu beantworten:
Sie müssen eine Whitelist verwenden, um schädliche Eingaben aus den eingehenden Kommentaren herauszuhalten.
Mit der .NET Framework-Anforderungsvalidierung können XSS-Nutzdaten in eingehenden POST-Anforderungen gestoppt werden. Es kann jedoch nicht verhindern, dass anderes bösartiges oder falsches HTML in die Kommentare gelangt (Bild-Tags, Hyperlinks usw.).
Wenn möglich, würde ich die Whitelist-Validierung auf der Serverseite für zulässige Zeichen einrichten. Eine Regex sollte dies gut abdecken. Sie sollten A-Za-z0-9, Whitespace und einige Interpunktionszeichen zulassen. Wenn die Regex nicht übereinstimmt, geben Sie eine Fehlermeldung an den Benutzer zurück und stoppen Sie die Transaktion. In Bezug auf SQL Injection: Ich würde Apostrophen in diesem Fall zulassen (außer Sie mögen schreckliche Grammatik in Ihren Kommentaren), aber setzen Sie Code-Kommentare um Ihre parametrisierten SQL-Abfragen mit dem Effekt von: "Dies ist der einzige Schutz gegen SQL, also seien Sie vorsichtig wenn modifizierend. " Sie sollten auch die Berechtigungen des Datenbankkontos sperren, das vom Webprozess verwendet wird (nur Lese- / Schreibberechtigungen, keine Datenbankbesitzerberechtigungen). Was ich nicht tun würde, ist eine Blacklist-Validierung der Eingabe durchzuführen, da dies sehr zeitaufwendig ist, um korrekt zu arbeiten (siehe RSnakes XSS-Spickzettel unter Ссылка für eine Vorstellung von der Anzahl der Dinge, die Sie nur für XSS verhindern müssten.
Zwischen dem .NET-Framework und Ihrer eigenen Whitelist-Validierung sollten Sie vor HTML-basierten Angriffen wie XSS und CSRF * sicher sein. SQL-Injection wird verhindert, indem parametrisierte Abfragen verwendet werden. Wenn die Kommentardaten andere Elemente berühren, müssen möglicherweise weitere Steuerelemente eingerichtet werden. Diese decken jedoch die Angriffe ab, die für das von Ihnen beschriebene Basisformular für die Datenübermittlung relevant sind.
Ich würde auch nicht versuchen, die Daten überhaupt zu "bereinigen". Es ist sehr schwierig, es richtig zu machen, und die Benutzer hassen es (wie oben erwähnt), wenn ihre Daten ohne ihre Erlaubnis geändert werden. Es ist sicherer und benutzerfreundlicher, um Benutzern eine klare Fehlermeldung zu geben, wenn die Datenvalidierung fehlschlägt. Wenn Sie ihren Kommentar auf der Seite zurückgeben, um sie zu bearbeiten, codieren Sie die Ausgabe in HTML, sodass Sie nicht anfällig für einen Reflected XSS-Angriff sind.
Und wie immer ist OWASP.org ( Ссылка ) eine gute Referenz für alle Dinge, die mit webappsec zusammenhängen. Sehen Sie sich ihre Top Ten und Development Guide Projekte an.
* CSRF ist möglicherweise kein direktes Anliegen von Ihnen, da betrügerische Posts auf Ihrer Website für Sie keine Rolle spielen, aber die Vermeidung von XSS den Nebeneffekt hat, dass CSRF-Payloads, die auf andere Websites abzielen, von Ihrer Website gehostet werden.
>Tags und Links asp.net security validation