Auf der webbasierten Seite ist C # (und allgemeiner ASP.NET) häufig anfällig für Folgendes (Elemente, die von OWASP Top 10 2013 aufgelistet werden) ). Mir ist klar, dass Sie hauptsächlich an Senkenfunktionen interessiert waren, von denen ich einige behandele. Sie haben jedoch gefragt, wie Leute versehentlich gefährlichen C # -Code erstellen. Hoffentlich habe ich hier einen Einblick gegeben.
A1-Injektion
SQL-Injektion
Generieren von Abfragen durch Verkettung von Zeichenfolgen.
var sql = "SELECT * FROM UserAccount WHERE Username = '" + username "'";
SqlCommand command = new SqlCommand(sql , connection);
SqlDataReader reader = command.ExecuteReader();
Dies kann häufig durch parametrisierte Abfragen gelöst werden. Wenn Sie jedoch eine INBedingung verwenden, ist dies derzeit nicht möglich ohne Verkettung von Zeichenfolgen .
LDAP-Injektion
Code wie
searcher.Filter = string.Format("(sAMAccountName={1})", loginName);
kann die Anwendung anfällig machen. Weitere Informationen hier .
OS Command Injection
Dieser Code ist anfällig für die Befehlsinjektion, da an den zweiten Parameter Process.Startzusätzliche Befehle übergeben werden können, wobei das &Zeichen zum Stapeln mehrerer Befehle verwendet wird
string strCmdText= @"/C dir c:\files\" + Request.QueryString["dir"];
ProcessStartInfo info = new ProcessStartInfo("CMD.exe", strCmdText);
Process.Start(info);
z.B foldername && ipconfig
A2-defekte Authentifizierung und Sitzungsverwaltung
Ausloggen
Die standardmäßige SignOut- Methode zur Formularauthentifizierung aktualisiert nichts auf der Serverseite, sodass ein erfasstes Authentifizierungstoken weiterhin verwendet werden kann.
Durch Aufrufen der SignOut-Methode wird nur das Formularauthentifizierungscookie entfernt. Der Webserver speichert keine gültigen und abgelaufenen Authentifizierungstickets für einen späteren Vergleich. Dies macht Ihre Site anfällig für einen Wiederholungsangriff, wenn ein böswilliger Benutzer ein gültiges Formularauthentifizierungscookie erhält.
Sitzungsstatus für die Authentifizierung verwenden
Eine Sicherheitsanfälligkeit bezüglich Sitzungsfixierung kann vorliegen, wenn ein Benutzer den Sitzungsstatus zur Authentifizierung verwendet hat .
A3-Cross-Site-Scripting (XSS)
Response.Write(und die Verknüpfung <%= =>) sind standardmäßig anfällig, es sei denn, der Entwickler hat daran gedacht, die Ausgabe in HTML zu codieren. Die neuere <%:HTML- Verknüpfung codiert standardmäßig, obwohl einige Entwickler diese möglicherweise verwenden, um Werte in JavaScript einzufügen, wo sie von einem Angreifer weiterhin maskiert werden können. Selbst mit dem modernen Razor-Motor ist es schwierig, dies richtig zu machen:
var name = '@Html.Raw(HttpUtility.JavaScriptStringEncode(Model.Name))';
ASP.NET aktiviert standardmäßig die Anforderungsüberprüfung , die alle Eingaben von Cookies, der Abfragezeichenfolge und von POST-Daten blockiert, die möglicherweise schädlich sein könnten (z. B. HTML-Tags). Dies scheint gut mit Eingaben umzugehen, die über die jeweilige App eingehen. Wenn jedoch Inhalte in der Datenbank vorhanden sind, die aus anderen Quellen eingefügt wurden, z. B. aus einer App, die mit anderen Technologien geschrieben wurde, ist es möglich, dass weiterhin schädlicher Skriptcode ausgegeben wird. Eine weitere Schwachstelle besteht darin, dass Daten in einen Attributwert eingefügt werden. z.B
<%
alt = Request.QueryString["alt"];
%>
<img src="http://example.com/foo.jpg" alt="<%=alt %>" />
Dies kann ausgenutzt werden, ohne die Anforderungsvalidierung auszulösen:
Wenn altja
" onload="alert('xss')
dann rendert dies
<img src="http://example.com/foo.jpg" alt="" onload="alert('xss')" />
In alten Versionen von .NET war es für einen Entwickler ein kleines Minenfeld , sicherzustellen, dass seine Ausgabe mit einigen der Standard-Websteuerelemente korrekt codiert wurde.
Leider enthält die Datenbindungssyntax noch keine integrierte Codierungssyntax. Es kommt in der nächsten Version von ASP.NET
zB nicht verletzlich:
<asp:Repeater ID="Repeater1" runat="server">
<ItemTemplate>
<asp:TextBox ID="txtYourField" Text='<%# Bind("YourField") %>'
runat="server"></asp:TextBox>
</ItemTemplate>
</asp:Repeater>
anfällig:
<asp:Repeater ID="Repeater2" runat="server">
<ItemTemplate>
<%# Eval("YourField") %>
</ItemTemplate>
</asp:Repeater>
A4-Unsichere direkte Objektreferenzen
Durch die MVC-Modellbindung können Parameter, die zu POST-Daten hinzugefügt wurden, auf ein Datenmodell abgebildet werden. Dies kann unbeabsichtigt geschehen, da der Entwickler nicht bemerkt hat, dass ein böswilliger Benutzer Parameter auf diese Weise ändern kann. Das BindAttribut kann verwendet werden, um dies zu verhindern .
A5-Sicherheitsfehlkonfiguration
Es gibt viele Konfigurationsoptionen, die die Sicherheit einer Anwendung beeinträchtigen können. Zum Beispiel voran customErrorszu Onoder ermöglicht Spur.
Scanner wie ASafaWeb können diese häufigen Fehlkonfigurationen überprüfen.
A6-sensible Datenexposition
Standard-Hashing
Die Standard-Kennwort-Hashing-Methoden in ASP.NET sind manchmal nicht die besten.
A7-Zugriffskontrolle auf fehlender Funktionsebene
Fehler beim Einschränken des URL-Zugriffs
Im integrierten Pipeline-Modus kann .NET jede Anforderung anzeigen und Handles können jede Anforderung auch für Nicht-.NET-Ressourcen (z .js. B. und Bilder) autorisieren . Wenn die Anwendung jedoch im klassischen Modus ausgeführt wird, sieht .NET nur Anforderungen an Dateien, z. B. weil .aspxandere Dateien möglicherweise versehentlich ungesichert sind. Siehe diese Antwort weitere Einzelheiten zu den Unterschieden.
zB www.example.com/images/private_photograph_user1.jpgist es wahrscheinlicher, dass es in einer Anwendung, die im klassischen Modus ausgeführt wird, anfällig ist, obwohl es Problemumgehungen gibt .
A8-Cross-Site Request Forgery (CSRF)
Obwohl die älteren Webformularanwendungen normalerweise sicherer gegen CSRF sind, da der Angreifer die Werte für den Ansichtsstatus und die Ereignisüberprüfung fälschen muss , können neuere MVC-Anwendungen anfällig sein, sofern der Entwickler keine Anti-Fälschungs-Token manuell implementiert hat . Hinweis Ich sage nicht, dass Webformulare nicht anfällig sind, sondern dass es schwieriger ist, nur einige grundlegende Parameter weiterzugeben. Es gibt jedoch Korrekturen, z. B. die Integration des Benutzerschlüssels in den Wert für den Ansichtsstatus.
Wenn die EnableEventValidation-Eigenschaft auf true festgelegt ist, überprüft ASP.NET, ob ein Steuerelementereignis von der Benutzeroberfläche stammt, die von diesem Steuerelement gerendert wurde. Ein Steuerelement registriert seine Ereignisse während des Renderns und überprüft dann die Ereignisse während der Nach- oder Rückrufbehandlung. Wenn ein Listensteuerelement beispielsweise beim Rendern der Seite die Optionen 1, 2 oder 3 enthält und eine Postback-Anforderung unter Angabe der Option 4 eingeht, löst ASP.NET eine Ausnahme aus. Alle ereignisgesteuerten Steuerelemente in ASP.NET verwenden diese Funktion standardmäßig.
Die Funktion [EnableEventValidation] verringert das Risiko nicht autorisierter oder böswilliger Postback-Anfragen und Rückrufe. Es wird dringend empfohlen, die Ereignisüberprüfung nicht zu deaktivieren.
A10-Unvalidated - Weiterleitungen und Weiterleitungen
Hinzufügen von Code wie
Response.Redirect(Request.QueryString["Url"]);
macht Ihre Website anfällig. Der Angriff kann durch Senden einer Phishing-E-Mail an einen Benutzer mit einem Link ausgelöst werden. Wenn der Benutzer wachsam ist, hat er möglicherweise die Domain der URL vor dem Klicken doppelt überprüft. Da die Domain jedoch mit Ihrer Domain übereinstimmt, der der Benutzer vertraut, klickt er auf den Link, ohne zu wissen, dass die Seite den Benutzer zur Domain des Angreifers umleitet.
Die Validierung sollte am erfolgen, Urlum sicherzustellen, dass es sich entweder um eine relative, zulässige URL oder eine absolute URL zu einer Ihrer eigenen zulässigen Domänen und Seiten handelt. Möglicherweise möchten Sie überprüfen, ob jemand Ihre Benutzer nicht weiterleitet /Logout.aspx. Obwohl ein Angreifer möglicherweise nicht daran gehindert wird, direkt auf ihn zu verlinken http://www.example.com/Logout.aspx, könnte er die Umleitung verwenden, um die URL auszublenden, sodass es für einen Benutzer schwieriger ist, zu verstehen, auf welche Seite zugegriffen wird (http://www.example.com/Redirect.aspx?Url=%2f%4c%6f%67%6f%75%74%2e%61%73%70%78 ).
Andere
Die anderen OWASP-Kategorien sind:
- A9-Verwenden von Komponenten mit bekannten Sicherheitslücken
Ich kann mir keine vorstellen, die spezifisch für C # / ASP.NET sind. Ich werde meine Antwort aktualisieren, wenn mir welche einfallen (wenn Sie der Meinung sind, dass sie für Ihre Frage relevant sind).