Germany/Projekte/Top 10 fuer Entwickler-2013/A7-Fehlerhafte Autorisierung auf Anwendungsebene

Jeder mit Netzwerkzugriff kann Anfragen an die Anwendung senden. Können anonyme Benutzer auf private Seiten zugreifen oder normale Benutzer auf privilegierte Seiten? Ein angemeldeter Benutzer ändert den URL auf eine Seite für privilegierte Benutzer. Erhält er Zugriff?

Anonyme Benutzer könnten auf ungeschützte, private Seiten zugreifen. In Anwendungen wird der Zugriff auf Seiten nicht immer verlässlich abgesichert. Manchmal wird Zugriffsschutz durch Konfiguration realisiert, die ggf. auch fehlerhaft sein kann. Manchmal vergessen die Entwickler auch nur, die notwendige Prüfung zu implementieren. Solche Fehler lassen sich einfach entdecken. Die größte Schwierigkeit besteht darin, herauszufinden, welche angreifbaren Seiten (URLs) existieren. Solche Fehler erlauben es Angreifern, Funktionen zu nutzen, für die sie nicht berechtigt sind. Administrative Funktionen sind ein wesentliches Ziel bei diesem Angriffstyp. Betrachten Sie den Wert der Geschäftsprozesse der betroffenen Funktionen und Daten. Bedenken Sie ebenfalls die Auswirkung auf Ihre Reputation im Falle eines Bekanntwerdens der Schwachstelle.

Szenario 1: Der Angreifer ruft die Zieladressen einfach direkt auf. Die folgenden URLs erfordern eine Anmeldung. Für den Aufruf von “admin_getappInfo” sind darüber hinaus administrative Rechte erforderlich:

http://example.com/app/ getappInfo http://example.com/app/ admin_getappInfo

Erhält ein nicht angemeldeter Benutzer Zugriff, ist dies eine Schwachstelle. Erhält ein angemeldeter, nicht-administrativer Benutzer Zugriff auf “ admin_getappInfo ”, ist dies ebenfalls eine Schwachstelle und könnte dazu führen, dass ein Angreifer auf weitere administrative Seiten Zugriff erhält.

Szenario 2: Eine Anwendung nutzt den Parameter ‘action‘, um spezifische Aufrufe zu ermöglichen. Unterschiedliche “Actions” erfordern dabei unterschiedliche Rollen. Wird dies nicht geprüft, handelt es sich um eine Schwachstelle.

Die Anwendung sollte ein zentrales, möglichst einfach aufgebautes und widerspruchsfreies Modul zur Autorisierung verwenden, das leicht analysierbar ist und von allen Funktionen aufgerufen wird. Häufig werden diese Schutzfunktionen von externen Komponenten bereitgestellt. Hinweis: Viele Anwendungen blenden lediglich die Links zu privilegierten Funktionen aus. Dies ist jedoch kein wirksamer Schutz. Der Zugriff muss ebenfalls in der zentralen Berechtigungsprüfung kontrolliert werden.
 * 1) Der Prozess zur Rechtevergabe sollte einfach sein. Ebenso dessen Aktualisierung und Prüfung. Verwenden Sie nie hart kodierte Berechtigungsvergaben.
 * 2) Berechtigungszuweisung sollte standardmäßig keine Rechte zulassen und explizite Rechte für Zugriffe erfordern.
 * 3) Wenn die Funktion in einem Workflow eingebunden wird, stellen Sie sicher, dass die Rechte während des gesamten Prozesses erhalten bleiben.

= JAVA =

Zugriffssteuerung über den Web-Container (Declarative Access Control)
Die Autorisierung übernimmt der Web-Container. Die Steuerung erfolgt über die Konfigurationsdatei web.xml (Deployment Descriptor). Es ist kein Programmieraufwand notwendig.


 * Konfigurationsdatei 'WEB-INF/web.xml' des Webservers (Auszug):

&lt;security-constraint&gt;
 * &lt;web-resource-collection&gt;
 * &lt;web-resource-name&gt;Restricted Resources&lt;/web-resource-name&gt;
 * &lt;description&gt;Only for Authenticated Users&lt;/description&gt;
 * &lt;!-- Fail-Safe Default: Protect all URLs --&gt;
 * &lt;url-pattern>/*&lt;/url-pattern&gt;
 * &lt;http-method>GET&lt;/http-method&gt;
 * &lt;http-method>POST&lt;/http-method&gt;
 * &lt;/web-resource-collection&gt;
 * &lt;auth-constraint&gt;
 * &lt;role-name&gt;AuthorizedUser&lt;/role-name&gt;
 * &lt;/auth-constraint&gt;

&lt;/security-constraint&gt; &lt;security-constraint&gt;
 * &lt;web-resource-collection&gt;
 * &lt;web-resource-name&gt;MyLogin&lt;/web-resource-name&gt;
 * &lt;description&gt;Access to Login&lt;/description&gt;
 * &lt;url-pattern&gt;/login.jsp&lt;/url-pattern&gt;
 * &lt;http-method>GET&lt;/http-method&gt;
 * &lt;http-method>POST&lt;/http-method&gt;
 * &lt;/web-resource-collection&gt;
 * &lt;!-- No auth-constraint: Public Access! --&gt;

&lt;/security-constraint&gt; &lt;security-constraint&gt;
 * &lt;web-resource-collection&gt;
 * &lt;web-resource-name&gt;Public Resources&lt;/web-resource-name&gt;
 * &lt;description&gt;Some public pages&lt;/description&gt;
 * &lt;url-pattern&gt;/index.jsp&lt;/url-pattern&gt;
 * &lt;url-pattern&gt;/public/*&lt;/url-pattern&gt;
 * &lt;http-method&gt;GET&lt;/http-method&gt;
 * &lt;/web-resource-collection&gt;
 * &lt;!-- No auth-constraint: Public Access! --&gt;

&lt;/security-constraint&gt;


 * OWASP Proactive Controls:  Kapitel über 'Implement Access Controls'
 * OWASP Top 10-2007 on Failure to Restrict URL Access
 * ESAPI Access Control API
 * OWASP Development Guide: Chapter on Authorization
 * OWASP Testing Guide: Testing for Path Traversal
 * OWASP Article on Forced Browsing


 * Codereview-Deployment: Protecting_JSP_Pages
 * Web App Access Control Design

Weitere Anforderungen an den Zugriffsschutz sind in der ASVS requirements area for Access Control (V4) enthalten, deutsche Übersetzung (Ver 1.0): (PDF, Word)


 * CWE Entry 285 on Improper Access Control (Authorization)

= PHP =

Zugriffssteuerung über den Web-Container (Declarative Access Control)
Die Autorisierung übernimmt der Web-Container. Die Steuerung erfolgt über die Konfigurationsdatei .... (Deployment Descriptor). Es ist kein Programmieraufwand notwendig.


 * Konfigurationsdatei '....' des Webservers (Auszug):

...

tbd.

tbd.


 * OWASP Top 10-2007 on Failure to Restrict URL Access
 * ESAPI Access Control API
 * OWASP Development Guide: Chapter on Authorization
 * OWASP Testing Guide: Testing for Path Traversal
 * OWASP Article on Forced Browsing

Weitere Anforderungen an den Zugriffsschutz sind in der ASVS requirements area for Access Control (V4) enthalten, deutsche Übersetzung (Ver 1.0): (PDF, Word)


 * CWE Entry 285 on Improper Access Control (Authorization)