A Less Known Attack Vector, Second Order IDOR Attacks
Most of you probably familiar within the vulnerability types “IDOR (Insecure Object Direct Reference)” and second order vulnerabilities such as “Second Order SQL Injection.”, still for the ones who are not familiar, OWASP defines IDOR in theory as:
Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.
So if you imagine, there is an endpoint exist such as
https://ozguralp.com/my_cards.jsp?card_id=1231414 on a standard user profile, when you change
card_id parameter sequentially if you get other users card information unauthorizedly, then the endpoint is vulnerable to IDOR attacks.
Now, PortSwigger defines Second-order SQL injection attack as:
Second-order SQL injection arises when user-supplied data is stored by the application and later incorporated into SQL queries in an unsafe way. To detect the vulnerability, it is normally necessary to submit suitable data in one location, and then use some other application function that processes the data in an unsafe way.
So for second-order vulnerabilities, after user sends a malicious request for the attack type, user needs to find a functionality on the application which executes that malicious payload directly rather than the input-sent functionality. You can also get the concept within the Stored XSS vulnerabilities, which is also defined by PortSwigger as second-order XSS, due to the payloads are executed on different pages rather than the exploited request’s response. Within understanding the concept, we can try to find any vulnerability type’s second-order attack vectors. We will focus two different real world examples of Second Order IDOR’s.
One time when I was testing a banking application, I noticed an endpoint which allows users to gather their transaction receipt’s when clicked on the page. The endpoint was like:
https://bankingapp.com/transactions/show_receipt.aspx?id=32423423. When this endpoint was requested, application was redirecting user the a
https://bankingapp.com/transactions/receipt_success.aspx without any additional data or parameters. On this page, the PDF of the receipt was gathered successfully. When the
id parameter was changed on the first request to the other users (or sequentially), now application was redirecting user to the
https://bankingapp.com/transactions/receipt_error.aspx page rather than showing the receipt successfully. From this aspect, it seems secure since we cannot gather the other users receipts, right?
So, what could be happen if we request our receipt first but not follow the redirect to the success page, request other users receipt from repeater and now follow redirect to the success page?
Attack can be conducted via below steps:
- Click the button for
show_receipt.aspx?id=32423423request on the page and intercept the request via Burp.
- Send request to the repeater.
- Forward held
show_receipt.aspx?id=32423423request from proxy and intercept
receipt_success.aspxrequest. Hold it.
- Return to the repeater and change id parameter to other users as
show_receipt.aspx?id=32423424. Do not follow redirection from the repeater.
- Now forward the held
receipt_success.aspxand cross your fingers.
Well it depends on how the application gathers receipt information on
receipt_success.aspx functionality. If it is returning last requested receipt id parameter from current user session, then we may get the other users receipt unauthorizedly. If it is returning last requested receipt id which belongs to current user session, then it would be not vulnerable. In my case, it was returning the last requested receipt id without checking whether it belongs to current session or not, so voila! It was possible to gather all transaction receipts of the bank!
Within a white-box approach to the topic, let’s imagine that these functions have below code lines on the back-end.
receiptId = GetReceiptIdFromURL();
Session["receiptId"] = receiptId;
receiptId = Session["receiptId"];
So, when the attacker requests
receipt_success.aspx endpoint directly, on the back-end receipt id is gathered from the session directly. If the attacker makes a request to the other user’s receipt id before requesting success page, due to application checks the IDOR control only at
show_receipt.aspx page, it is possible to gather other users receipts unauthorizedly. For full remediation, same check also should be applied to the success page too.
One time when I was trying to find IDOR vulnerabilities on an application, I found another second-order vulnerability which was affecting the user logs.
So, when I was trying to gather another users message within changing the message id’s, application was returning Access Denied errors.
However, on the account activity section of the application, while it was returning access denied on
showMessageBody endpoint, nevertheless it was returning the information requested on that functionality via the event/audit logs!
That was a standard user (Email: red<redacted>@synack.com) and do not had any access to the any other user rather than itself. While security controls were configured successfully on the first functionality; on the account activity section, all activity for user was gathered from back-end without checking whether it contains any access errors or not. So it was possible to gather other users information via second-order IDOR vulnerability existing at the audit log feature.
Especially for bug bounty activities, keeping your mind open and checking this kind of less known/controlled vulnerabilities may bring success to you in the future. Instead of just changing the parameters and analyzing the results of the response pages one by one, thinking all application functionality as a whole and making analysis within this aspect may actually double your finding activities.
📝 Read this story later in Journal.
👩💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.