Top 10 OWASP for .NET – Summary

OWASP

The Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. Our mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks.

https://www.owasp.org/index.php/Main_Page

OWASP gibt jedes Jahr eine Liste mit den zehn kritischsten Lücken heraus.
Hier ist der Guide “OWASP Top 10 for .NET developers” zu finden. Dasselbe PDF hier auf meinem Blog, sollte er einmal nicht mehr Verfügbar sein.

Basierend auf diesem Guide habe ich eine kleine Zusammenfassung erstellt.
Sie dient als Nachschlagewerk oder als Auffrischung. Ich empfehle aber auf jeden Fall den gesamten Guide zu lesen.

General Application Security
Allgemeines zur Web Application Security.

Passwort Reset

  • Sende niemals das neue Passwort per E-Mail
  • Sende einen Link mit z.B. Guid
  • Link soll nur kurze Zeit gültig sein

Verschlüsselung

  • Passwort in DB verschlüsseln
  • HTTPS für Anmeldung/ Wann immer Username und PW benützt wird

Benutzer schützen

  • Benutzer zu starken PW’s zwingen
  • Kein “Remember me” anbieten
  • AutoComplete ausschalten

A1 – Injection
Es gibt verschiedenste Arten von Injection. Die bekannteste ist die SQL Injection.
Eine SQL Injection erlaubt es dem Angreifer SQL Code auf dem Server auszuführen.

Code Smell:

  • Querystring/Headers/Forms/Cookies werden direkt in SQL Code Eingebunden
  • Keine Request Validation

Gegenmassnahmen:

  • Berechtigungen auf der DB einschränken
  • Mehrere Service Accounts mit verschiedenen Berechtigungen benutzen
  • Auf dem SQL Server keine verketteten SQL Queries in einem String zulassen
  • Stored Procedures mit Parameter verwenden
  • OR-Mapper verwenden

A2 – Cross-Site Scripting (XSS)
Dem Angreifer wird ermöglicht JavaScript (bzw. Html oder CSS) Code im Kontext der Website auszuführen.

Codesmells:

  • Querystring / Forms / Headers / Cookies werden auf der Website ausgegeben oder in der DB gespeichert um später ausgegeben zu werden
  • Ausgeschaltete Request Validation
  • @Html.Raw() wird verwendet

Gegenmassnahmen:

  • AntiXSS Library benützen (Wenn nicht asp.net mvc verwendet wird)
  • Output HTML Encoden (in Asp.net MVC wird defaultmässig jeder Output HTML Encoded (Kann mit Html.Raw() umgangen werden))

A3 – Broken authentication and session management
Wird die authentication oder das Session management nicht richtig gemacht, ist es einfach, für einen Angreifer, eine Session zu übernehmen.

Gegenmassnahmen:

  • Session Id nicht in URL
    Um die Session Id zu speichern sollten Cookies verwendet werden, nicht die URL. So ist es einfacher den Benutzer vor Session Hijacking zu schützen.
  • HTTPOnly Cookies
    Sind Cookies als HTTPOnly markiert, können sie nicht mit JavaScript ausgelesen oder manipuliert werden. Somit sind die Cookies auch von einer allfälligen XSS Lücke geschützt. Asp.net verwendet defaultmässig HTTPOnly für seine Cookies.
  • Framework anstatt selbst programmieren
    Das Asp.Net Framework bietet out of the box funktionen für Authentication.
    Die sind besser getestet und ausgereift als eine eigene Implementierung und sollten daher favorisiert werden. z.B. Asp.net Membership & Role Provider).
  • Session timeout
    Es sollte ein Sessiontimeout gesestzt werden, damit potentiell gehijackte Sessions nicht immer verwendet werden können. Default ist 30 Minuten.
  • Zitat: “If you are using ” SessionStateSection.RegenerateExpiredSessionId to true and you’re running cookieless.” The Session ID is reused. DONT DO THIS”
  • HTTPS
    Benütze mindestens für die Anmeldung eine verschlüsselte Verbindung.
    Somit sind die Logindaten verschlüsselt. Noch besser ist, immer HTTPS zu verwenden, um den Benutzer vor Session Hijacking zu schützen.

A4 – Insecure direct object reference
Mit dem manuellen verändern von Parametern kann der Angreifer auf Informationen zugreifen auf die er eigentlich keinen Zugriff haben sollte.

Codesmells:
Primary-Key wird von der Website bzw. vom User (z.B. QueryString) entgegengenommen um Daten zu holen oder zu manipulieren.

Beispiel:
Die Service Methode “GetCustomer” wird benützt um die Daten eines Kunden zu holen. Als Parameter wird ein Integer, die Id, mitgegeben.
Nun kann GetCustomer auch von Hand mit einer anderen Id aufgerufen werden und der Angreifer erhält Daten, die er nicht sehen sollte.

Gegenmassnahmen:

  • Indirekte Referenzen oder Guid’s
  • Authentifizierung
  • Autorisierung

A5 – Cross-Site Request Forgery (CSRF)
Benutzer logt sich auf der Seite ein.
Navigiert auf eine andere völlig unabhängige Seite.
Die unabhängige Seite macht einen Request auf die erste Seite.
Der Request wiederum scheint vom Benutzer zu kommen, da das Session & Authentication Cookie mitgeschickt wird.

Code smells:
Es handelt sich hierbei um eine “Schwachstelle” in der Spezifikation von HTTP und HTTPS. Deswegen gibt es keinen Code Smell.

Gegenmassnahmen:
Ein Random Wert wird in der Session gespeichert und als hidden Field zum Client geschickt. Stimmt dieser Wert beim Postback nicht, stammt der Request nicht von der Ursprungsseite.

In Asp.net MVC:

<% using(Html.Form("UserProfile", "SubmitUpdate")) { %>
    <%= Html.AntiForgeryToken() %>
    <!-- rest of form goes here -->
<% } %>
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc
}


A6 – Security Misconfiguration

Eine falsche Konfiguration verrät unnötig Details über die Applikation, das Framework oder den Webserver.

Gegenmassnahmen:

  • Custom errors ausschalten
     <customErrors mode="on" /> 

    Nun wird aber immer noch ein “internal server error” (500) zurückgegeben
    Asp.Net mvc: error.cshtml in shared folder
    Asp.net:

    <customErrors mode="On" redirectMode="ResponseRewrite"
    defaultRedirect="~/Error.aspx" /> 
  • Tracing ausschalten
    Disable trace.asx

    <trace enabled="true" localOnly="true" />
  • Debug Compilation
    <compilation debug=”false”>
  • Web.config Sections verschlüsseln
    Um die Konfiguration vor Veränderung zu schützen, können Sections verschlüsselt werden: How to
  • Versions Informationen verstecken
    Server Microsoft-IIS/7.5
    X-AspNetMvc-Version 3.0
    X-AspNet-Version 4.0.303319
    X-Powered-By ASP.NET
    How to
  • Header setzen um Clickjacking zu verhindern
    X-Frame-Options header
    https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

A7 – Insecure Cryptographic Storage
Eine Verschlüsselung bringt nichts wenn sie nicht sicher ist.
Dazu Verweise ich auf einen entsprechenden Artikel.
http://www.troyhunt.com/2011/06/owasp-top-10-for-net-developers-part-7.html

A8 – Failure to Restrict URL Access
Die Applikation setzt auf “Security through obscurity” und nicht auf Authentication und Authorization um den Zugriff auf Seiten zu kontrollieren. Das dass schlecht ist braucht keine weitere Erklärung.

Gegenmassnahmen

A10 – Unvalidated Redirects and Forwards
Der Angreifer kann die Applikation missbrauchen um Benutzer auf eine andere Seite umzuleiten.

Code smells:
Redirects auf Basis von User Inputs (QueryString, Form).

var url = Request.QueryString["Url"];
LogRedirect(url);
Response.Redirect(url);

Gegenmassnahmen:

  • Whitlist mit erlaubten Urls
  • Urls in Datenbank speichern und Redirect über Id/Guid

Leave a Reply

Your email address will not be published. Required fields are marked *