This was an interesting bug I found recently a Jobportal . So, I thought I should write about it.

I was testing www.target.com and I have noticed that when a user creates job alert on the web application of www.target.com, a URL is provided to the user like this https://*.target.com/account/email_alerts/[token]. If an attacker knows this URL he gains the capability to modify or delete that users job alerts. It was really interesting so I though I should look into this more.

Dissecting The Issue.
---------------------------------------

When you log into your Jora Account you can create alerts from https://subdomain.target.com/account/email_alerts/new. While creating the alert on the web application you would need to put few parameters like Keywords, Location, Job Type etc. After creating the job alert it will be visible on the users own job alerts section.

However the alert would be modifiable with a URL like this https://*.target.com/account/email_alerts/[token]/edit, the alert can also be deleted with this URL like this https://*.target.com/account/email_alerts/[token]/cancel. Interestingly these URLS - specifically the tokens are not bound to users account , meaning these are unique against the whole web application not only rather the users own account.

Which means If someone can gain the URL https://*.target.com/account/email_alerts/[token], they can delete or modify that specific users job alerts or delete job alert of that user. Interestingly I was able to enumerate the endpoint of https://*.target.com/account/email_alerts/[token] , Specifically the token parameter.

Proof of Concept:

Account 1:

• I am logged in from my account from Browser 1 (Chrome) to my target.com Account 1

• My Email address is abcd@example.com.

• I will create a job alert with Keyword target_test.

• My Job alert will be created and I would find all alerts at https://subdomain.target.com/account/email_alerts.

• My job alert would be editable through https://subdomain.target.com/account/email_alerts/[token]/edit and deletable through `https://subdomain.target.com/account/email_alerts/[token]/cancel.

Account 2:

• Now I would go to Browser 2 (Firefox) to my Jora Account 2.

• I am logged into a different account here.

• My email address is bced@example.com .

• Now What I will do - I would take the URL from Account 1 to edit the alert. https://subdomain.target.com/account/email_alerts/[token]/edit

• I would find that I am able to change the alert details.

• I would change the keyword to target_hack from target_test.

• It would be saved.

Account 1:

• Now I would go back to Account 1 at Browser 1 (Chrome)

• I would reload https://subdomain.target.com/account/email_alerts and my job alert is now changed to target_hack.

Account 2:

• Now I would go to Browser 2 (Firefox) to my www.target.com Account 2.

• Now What I will do - I would take the URL from Account 1 to delete the alert. https://subdomain.target.com/account/email_alerts/[token]/cancel

• The alert would be deleted.

Account 1:

• Now I would go back to Account 1 at Browser 1 (Chrome)

• I would reload https://subdomain.target.com/account/email_alerts and my job alert is completely deleted.

Attack Scenario:

• As you have understood this IDOR depends on the token value of https://*.target.com/account/email_alerts/[token].

• So, if the attacker can steal this token - or convinces victim toggle job alert edit URL then the attacker can modify and delete the particular job alert.

• Interestingly I was able to enumerate a particular endpoint https://subdomain.target.com/account/email_alerts/ to enumerate tokens through scanner or fuzzer tools.
  
  I noticed when my to devices were under the same WIFI connection and having logged into Jora account, I was able to enumerate the token endpoint of the other account through Burpsuite.