A web application responds to a URL parameter with an ID that points to a sensitive resource; this is an example of which vulnerability?

A web application responds to a URL parameter with an ID that points to a sensitive resource; this is an example of which vulnerability?

• A. XML External Entity Attack
• B. CRLF Injection
• C. Timeout Exploitation
• D. Insecure Direct Object References

Answer: (D)

Direct object references occur when a web application uses a user-supplied identifier to fetch a resource without properly enforcing authorization. In this case, the URL parameter provides an ID that points to a sensitive resource, and the app returns that resource just based on the ID. If there isn’t a strong access-control check in place, a user can alter the ID to access other users’ resources or sensitive data. The weakness is that the object reference itself is trusted to control access, rather than verifying that the requester is authorized to view the specific object. This isn’t an XML External Entity Attack, which relies on exploiting XML parsers and external entities; nor is it CRLF Injection, which targets HTTP headers through newline characters; nor is it Timeout Exploitation, which centers on performance or DoS aspects rather than direct unauthorized access to objects. The correct vulnerability category is insecure direct object references, rooted in inadequate access controls around object identifiers. To fix it, enforce authorization checks on every object retrieval, or use indirect references (opaque tokens) that map to objects only after proper authorization.

Direct object references occur when a web application uses a user-supplied identifier to fetch a resource without properly enforcing authorization. In this case, the URL parameter provides an ID that points to a sensitive resource, and the app returns that resource just based on the ID. If there isn’t a strong access-control check in place, a user can alter the ID to access other users’ resources or sensitive data. The weakness is that the object reference itself is trusted to control access, rather than verifying that the requester is authorized to view the specific object.

This isn’t an XML External Entity Attack, which relies on exploiting XML parsers and external entities; nor is it CRLF Injection, which targets HTTP headers through newline characters; nor is it Timeout Exploitation, which centers on performance or DoS aspects rather than direct unauthorized access to objects. The correct vulnerability category is insecure direct object references, rooted in inadequate access controls around object identifiers. To fix it, enforce authorization checks on every object retrieval, or use indirect references (opaque tokens) that map to objects only after proper authorization.