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

A7 Fehlerhafte Autorisierung auf Anwendungsebene


Anwendungs- spezifisch	Ausnutzbarkeit EINFACH	Verbreitung SELTEN	Auffindbarkeit DURCHSCHNITTLICH	Auswirkung MITTEL	Anwendungs-/ Geschäftsspezifisch
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.

Mögliche Angriffsszenarien

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.

Wie kann ich 'Fehlerhafte Autorisierung auf Anwendungsebene' verhindern?

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.

Der Prozess zur Rechtevergabe sollte einfach sein. Ebenso dessen Aktualisierung und Prüfung. Verwenden Sie nie hart kodierte Berechtigungsvergaben.
Berechtigungszuweisung sollte standardmäßig keine Rechte zulassen und explizite Rechte für Zugriffe erfordern.
Wenn die Funktion in einem Workflow eingebunden wird, stellen Sie sicher, dass die Rechte während des gesamten Prozesses erhalten bleiben.

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.

JAVA
PHP

Verteidigungs-Option 1 gegen 'Fehlerhafte Autorisierung auf Anwendungsebene':

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)
<security-constraint>

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



<security-constraint>

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



<security-constraint>

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

Referenzen

OWASP

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

Andere

CWE Entry 285 on Improper Access Control (Authorization)

« JAVA2

JAVA »

This section is under construction. Please help OWASP to add missing content!
Comment: Bitte senden Sie uns weitere gute Beispiele mit PHP für diesen Abschnitt.

Verteidigungs-Option 1 gegen 'Fehlerhafte Autorisierung auf Anwendungsebene':

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)
...

 ...
 ...

Verteidigungs-Option 2 gegen 'Fehlerhafte Autorisierung auf Anwendungsebene':

tbd.

Verteidigungs-Option 3 gegen 'Fehlerhafte Autorisierung auf Anwendungsebene':

tbd.

Referenzen

OWASP

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

Andere