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
Germany/Projekte/Top 10-2013-A4-Unsichere direkte Objektreferenzen
NOTE: THIS IS NOT THE LATEST VERSION. Please visit the OWASP Top 10 project page to find the latest edition.
Anwendungs- spezifisch |
Ausnutzbarkeit EINFACH |
Verbreitung HÄUFIG |
Auffindbarkeit EINFACH |
Auswirkung MITTEL |
Application / Business Specific |
Consider the types of users of your system. Do any users have only partial access to certain types of system data? |
Attacker, who is an authorized system user, simply changes a parameter value that directly refers to a system object to another object the user isn’t authorized for. Is access granted? |
Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws. Code analysis quickly shows whether authorization is properly verified. |
Such flaws can compromise all the data that can be referenced by the parameter. Unless object references are unpredictable, it’s easy for an attacker to access all available data of that type. |
Consider the business value of the exposed data.
Also consider the business impact of public exposure of the vulnerability |
Bin ich durch 'Unsichere direkte Objektreferenzen' verwundbar?
The best way to find out if an application is vulnerable to insecure direct object references is to verify that all object references have appropriate defenses. To achieve this, consider:
Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe. |
Wie kann ich 'Unsichere direkte Objektreferenzen' verhindern?
Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):
|
Mögliche Angriffsszenarien
The application uses unverified data in a SQL call that is accessing account information: String query = "SELECT * FROM accts WHERE account = ?"; PreparedStatement pstmt = connection.prepareStatement(query , … ); pstmt.setString( 1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( ); The attacker simply modifies the ‘acct’ parameter in their browser to send whatever account number they want. If not verified, the attacker can access any user’s account, instead of only the intended customer’s account. http://example.com/app/accountInfo?acct=notmyacct |
Referenzen
OWASP
For additional access control requirements, see the ASVS requirements area for Access Control (V4). Andere
|
![CC-by-sa-3 0-88x31.png](/images/6/64/CC-by-sa-3_0-88x31.png)