Authorization Bypass in eBay Marktplaats

Marktplaats http://www.marktplaats.nl/ is a website owned by eBay that allows users to buy and sell products in addition to posting jobs.

The job management feature got my interest. I added a job and played with the job removal feature.

If you click on the remove link, a request like the one below will be sent

 When I pulled the trigger and tried to tamper the jobid to a jobid of another user that I created, it gave me authorization bypass error :-(

So, I  postponed my tampering and moved towards the next step in the job removal process. The next step was the delete confirmation:

 

When I clicked on the "Delete" button, I tampered the  jobid



 The server responded to me with

It was a 302 status that redirected me to the successful deletion page. We have a vulnerability :-)

This is the normal scenario the app was expecting:

  This is what the attacker can do



Marktplaats fixed the issue and sent me a token of appreciation. I was not rewarded because another researcher has already reported the vulnerability.

Marktplaats bug bounty rules link is on http://statisch.marktplaats.nl/help/responsible_disclosure_policy_en.html

Authorization Bypass in Google Orkut

I was playing with Google Orkut during the bug bounty. Orkut is  a social networking web site owned by Google  at www.Orkut.com

I  was investigating the robots file on www.orkut.com/robots.txt and I found something suspicious. I found a messages page although there  was no link in the web site that directs to such page.

I navigated to the page and it was functional.

I targeted such page because I thought that it was ignored and that it would contain security flaws. I started inspecting the delete message feature:

This was the request sent when deleting a particular message:

 The server reads the id passed in the "msg" parameter and deletes the message. I tried to abuse this feature and put an id of another user that I created.

The message was deleted :-)
 

I was so happy at the beginning before I realized that the message ids are not so predictable. :-(

Sample message id:
U0707254179/SB/0765222224/U0707254179

Sample message id for another user
U0707246461/SB/0765210864/U0707246461

This will make the vulnerability not exploitable. I thought of asking for help from Google to find a solution for this problem. I used the Google search :

site:orkut.com inurl:msg inurl:messages.aspx

It revealed messages ids in the URLs. Although such URLs will lead to 404 pages, they reveal  message ids which can be used by an attacker to  exploit such vulnerability :-).

Those message sections were also vulnerable the same way:
–    Unauthorized movement of messages between folders
–    Unauthorized marking of messages to be read/unread

Google fixed the issue immediately and  acknowledged me in their news feeds:

Google rewarded me and added my name to the rewarded hall of fame list :-)
https://www.google.com.eg/about/appsecurity/hall-of-fame/reward/

Google's bug bounty program is the best. The rules link is on https://www.google.com.eg/about/appsecurity/reward-program/