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.

#Example 1

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?

Workflow of the functionality

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=32423423 request on the page and intercept the request via Burp.
• Send request to the repeater.
• Forward held show_receipt.aspx?id=32423423 request from proxy and intercept receipt_success.aspx request. 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.aspx and cross your fingers.

Messing with workflow of the functionality

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.

show_receipt.aspx.cs

receiptId = GetReceiptIdFromURL(); 
Session["receiptId"] = receiptId; 
if(CurrentUser.Owns(receiptId)) 
{ 
  redirect receipt_success.aspx; 
} 
else 
{
  redirect receipt_error.aspx;
}

receipt_success.aspx.cs

receiptId = Session["receiptId"]; 
return ReadReceipt(receiptId);

receipt_error.aspx.cs

return "Error";

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 atshow_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.

#Example 2

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.

Changing messageId parameter to other user returns error.

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!

Gathering other user information within second-order IDOR via 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.

Last Words

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.