This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Germany/Projekte/Top 10 fuer Entwickler-2013/A4-Unsichere direkte Objektreferenzen"

From OWASP
Jump to: navigation, search
m
m (kleinere Textänderungen (ohne inhaltliche Änderung))
Line 22: Line 22:
 
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Denken Sie an verschiedene Typen von Nutzern, die auf Ihr System zugreifen. Gibt es Nutzer, die nur eingeschränkten Zugriff auf bestimmte Daten Ihres Systems haben sollen?</td>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Denken Sie an verschiedene Typen von Nutzern, die auf Ihr System zugreifen. Gibt es Nutzer, die nur eingeschränkten Zugriff auf bestimmte Daten Ihres Systems haben sollen?</td>
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Der Angreifer ist autorisiert, auf ein Systemobjekt zuzugreifen. Durch einfache Änderung eines Parameters kann er auf Ob- jekte zugreifen, für die er nicht autorisiert ist.</td>
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Der Angreifer ist autorisiert, auf ein Systemobjekt zuzugreifen. Durch einfache Änderung eines Parameters kann er auf Objekte zugreifen, für die er nicht autorisiert ist.</td>
 
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Webanwendungen nutzen oft den internen Namen oder die Kennung eines Objektes, um auf dieses zu verweisen. Anwendungen prüfen dabei nicht immer, ob der Nutzer für den Zugriff auf diese autorisiert ist. Dies führt zu unsicheren direkten Objektreferenzen. Tester können Parameter ändern, um diese Schwachstellen zu entdecken. Code-Analysen zeigen schnell, ob die Autorisierung in geeigneter Weise geprüft wird.</td>
 
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Webanwendungen nutzen oft den internen Namen oder die Kennung eines Objektes, um auf dieses zu verweisen. Anwendungen prüfen dabei nicht immer, ob der Nutzer für den Zugriff auf diese autorisiert ist. Dies führt zu unsicheren direkten Objektreferenzen. Tester können Parameter ändern, um diese Schwachstellen zu entdecken. Code-Analysen zeigen schnell, ob die Autorisierung in geeigneter Weise geprüft wird.</td>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Diese Schwachstelle gefährdet alle Daten, die via Parameter referenziert werden können. Angreifer können auf alle verfügbaren Daten dieser Art zugreifen, außer der Namensraum ist dünn besetzt.</td>
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Diese Schwachstelle gefährdet alle Daten, die via Parameter referenziert werden können. Angreifer können auf alle verfügbaren Daten dieser Art zugreifen, außer der Namensraum ist dünn besetzt.</td>
Line 36: Line 36:
  
 
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=4|year=2010|language=de}}  
 
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=4|year=2010|language=de}}  
Um unsichere direkte Objektreferenzen zu verhindern, muss der Schutz eines jeden Objektes (z.B. Objektnummer, Datei-name), das für Nutzer erreichbar ist, gewährleistet werden:
+
Um unsichere direkte Objektreferenzen zu verhindern, muss der Schutz eines jeden Objektes (z.B. Objektnummer, Dateiname), das für Nutzer erreichbar ist, gewährleistet werden:
 
# <b>Indirekte Objektreferenzen verwenden!</b> Dies verhindert den direkten Angriff auf nicht autorisierte Ressourcen. So sollte eine Auswahlbox mit sechs für den Nutzer verfügbaren Objekten die Ziffern 1 bis 6 als Referenzen enthalten, statt deren echte Datenbankschlüssel. Die Anwendung muss dann diese indirekten Objektreferenzen den echten Datenbankschlüsseln zuordnen. Die OWASP ESAPI enthält Referenzzuordnungen für sequentiellen wie wahlfreien Zugriff, die von Entwicklern zur Vermeidung direkter Referenzen genutzt werden können.
 
# <b>Indirekte Objektreferenzen verwenden!</b> Dies verhindert den direkten Angriff auf nicht autorisierte Ressourcen. So sollte eine Auswahlbox mit sechs für den Nutzer verfügbaren Objekten die Ziffern 1 bis 6 als Referenzen enthalten, statt deren echte Datenbankschlüssel. Die Anwendung muss dann diese indirekten Objektreferenzen den echten Datenbankschlüsseln zuordnen. Die OWASP ESAPI enthält Referenzzuordnungen für sequentiellen wie wahlfreien Zugriff, die von Entwicklern zur Vermeidung direkter Referenzen genutzt werden können.
 
# <b>Zugriffe prüfen!</b> Jeder Abruf direkter Objektreferenzen aus nicht vertrauenswürdigen Quellen muss eine Prüfung der Zugriffsberechtigung beinhalten, um die Autorisierung für das angefragte Objekt sicherzustellen.
 
# <b>Zugriffe prüfen!</b> Jeder Abruf direkter Objektreferenzen aus nicht vertrauenswürdigen Quellen muss eine Prüfung der Zugriffsberechtigung beinhalten, um die Autorisierung für das angefragte Objekt sicherzustellen.

Revision as of 13:33, 11 April 2013

← Top_10_fuer_Entwickler/A3_Fehler in Authentifizierung und Session-Management
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

Top_10_fuer_Entwickler/A5_Cross-Site Request Forgery (CSRF) →

Seite in Bearbeitung (BAUSTELLE!!)

A4 Unsichere direkte Objektreferenzen

Bedrohungsquellen
Angriffsvektoren
Schwachstellen
Technische Auswirkung
Auswirkung auf das Unternehmen
______ Ausnutzbarkeit
EINFACH
Verbreitung
HÄUFIG
Auffindbarkeit
EINFACH
Auswirkung
MITTEL
Application / Business Specific
Denken Sie an verschiedene Typen von Nutzern, die auf Ihr System zugreifen. Gibt es Nutzer, die nur eingeschränkten Zugriff auf bestimmte Daten Ihres Systems haben sollen? Der Angreifer ist autorisiert, auf ein Systemobjekt zuzugreifen. Durch einfache Änderung eines Parameters kann er auf Objekte zugreifen, für die er nicht autorisiert ist. Webanwendungen nutzen oft den internen Namen oder die Kennung eines Objektes, um auf dieses zu verweisen. Anwendungen prüfen dabei nicht immer, ob der Nutzer für den Zugriff auf diese autorisiert ist. Dies führt zu unsicheren direkten Objektreferenzen. Tester können Parameter ändern, um diese Schwachstellen zu entdecken. Code-Analysen zeigen schnell, ob die Autorisierung in geeigneter Weise geprüft wird. Diese Schwachstelle gefährdet alle Daten, die via Parameter referenziert werden können. Angreifer können auf alle verfügbaren Daten dieser Art zugreifen, außer der Namensraum ist dünn besetzt. Prüfen Sie sorgfältig den geschäftlichen Wert ungeschützt verfügbarer Daten. Berücksichtigen Sie auch die geschäftlichen Auswirkungen, die mit der Veröffentlichung der Schwachstelle verbunden sein können.
Mögliche Angriffsszenarien

Die Anwendung nutzt ungeprüfte Daten in einem SQL-Aufruf, der Account-Informationen abfragt:

String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(query , ... );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery();

Ein Angreifer ändert den Parameter ‘acct’ im Browser, um beliebige Zugangsnummern abzufragen. Wenn keine Prüfung erfolgt, können Angreifer nicht nur auf ihren eigenen, sondern auf jeden gewünschten Account Zugriff erhalten.

http://example.com/app/accountInfo?acct=notmyacct
Wie kann ich 'Unsichere direkte Objektreferenzen' verhindern?

Um unsichere direkte Objektreferenzen zu verhindern, muss der Schutz eines jeden Objektes (z.B. Objektnummer, Dateiname), das für Nutzer erreichbar ist, gewährleistet werden:

  1. Indirekte Objektreferenzen verwenden! Dies verhindert den direkten Angriff auf nicht autorisierte Ressourcen. So sollte eine Auswahlbox mit sechs für den Nutzer verfügbaren Objekten die Ziffern 1 bis 6 als Referenzen enthalten, statt deren echte Datenbankschlüssel. Die Anwendung muss dann diese indirekten Objektreferenzen den echten Datenbankschlüsseln zuordnen. Die OWASP ESAPI enthält Referenzzuordnungen für sequentiellen wie wahlfreien Zugriff, die von Entwicklern zur Vermeidung direkter Referenzen genutzt werden können.
  2. Zugriffe prüfen! Jeder Abruf direkter Objektreferenzen aus nicht vertrauenswürdigen Quellen muss eine Prüfung der Zugriffsberechtigung beinhalten, um die Autorisierung für das angefragte Objekt sicherzustellen.
Verteidigungs-Option 1 gegen 'Unsichere direkte Objektreferenzen':

tbd Text

Verteidigungs-Option 2 gegen 'Unsichere direkte Objektreferenzen':

tbd Text

Verteidigungs-Option 3 gegen 'Unsichere direkte Objektreferenzen':

tbd Text

Auswirkung(en) auf den Benutzer

(ganze Breite) Text

Referenzen


← Top_10_fuer_Entwickler/A3_Fehler in Authentifizierung und Session-Management
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

Top_10_fuer_Entwickler/A5_Cross-Site Request Forgery (CSRF) →

© 2002-2013 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png