ExamGecko
Question list
Search
Search

Related questions











Question 389 - 312-50v12 discussion

Report
Export

Insecure direct object reference is a type of vulnerability where the application does not verify if the user is authorized to access the internal object via its name or key. Suppose a malicious user Rob tries to get access to the account of a benign user Ned.

Which of the following requests best illustrates an attempt to exploit an insecure direct object reference vulnerability?

A.
"GET /restricted/goldtransfer?to=Rob&from=1 or 1=1' HTTP/1.1Host: westbank.com"
Answers
A.
"GET /restricted/goldtransfer?to=Rob&from=1 or 1=1' HTTP/1.1Host: westbank.com"
B.
"GET /restricted/\r\n\%00account%00Ned%00access HTTP/1.1 Host: westbank.com"
Answers
B.
"GET /restricted/\r\n\%00account%00Ned%00access HTTP/1.1 Host: westbank.com"
C.
"GET /restricted/accounts/?name=Ned HTTP/1.1 Host westbank.com"
Answers
C.
"GET /restricted/accounts/?name=Ned HTTP/1.1 Host westbank.com"
D.
"GET /restricted/ HTTP/1.1 Host: westbank.com
Answers
D.
"GET /restricted/ HTTP/1.1 Host: westbank.com
Suggested answer: C

Explanation:

This question shows a classic example of an IDOR vulnerability. Rob substitutes Ned's name in the "name" parameter and if the developer has not fixed this vulnerability, then Rob will gain access to Ned's account. Below you will find more detailed information about IDOR vulnerability.

Insecure direct object references (IDOR) are a cybersecurity issue that occurs when a web application developer uses an identifier for direct access to an internal implementation object but provides no additional access control and/or authorization checks. For example, an IDOR vulnerability would happen if the URL of a transaction could be changed through client-side user input to show unauthorized data of another transaction.

Most web applications use simple IDs to reference objects. For example, a user in a database will usually be referred to via the user ID. The same user ID is the primary key to the database column containing user information and is generated automatically. The database key generation algorithm is very simple: it usually uses the next available integer. The same database ID generation mechanisms are used for all other types of database records.

The approach described above is legitimate but not recommended because it could enable the attacker to enumerate all users. If it's necessary to maintain this approach, the developer must at least make absolutely sure that more than just a reference is needed to access resources. For example, let's say that the web application displays transaction details using the following URL:

https://www.example.com/transaction.php?id=74656

A malicious hacker could try to substitute the id parameter value 74656 with other similar values, for example:

https://www.example.com/transaction.php?id=74657

The 74657 transaction could be a valid transaction belonging to another user. The malicious hacker should not be authorized to see it. However, if the developer made an error, the attacker would see this transaction and hence we would have an insecure direct object reference vulnerability.

asked 18/09/2024
Timo Fahlenbck
34 questions
User
Your answer:
0 comments
Sorted by

Leave a comment first