Monday, 18 April 2016

Cross Site Scripting and URL redirection ...

Hi Guys,

Almost 2 years back I found a cross site scripting and a Dom based Open Url redirection bugs on a certain web site. Since the issues are still not patched, even after 2 years, I have decided to write a blog on them.

Cross Site Scripting:
As per owasp, "Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it."

While testing, I ended up working on the support page pointing to . After playing around the site, I found that it is vulnerable to the reflected cross site scripting on the following url.

The payload used is a simple   <style/onload=alert(document.location)>

so the execution URL is :<style/onload=alert(document.location)>

Make sure to use a mobile browser or a browser with mobile user agent....

Reproduction Instructions / Proof of Concept

1. Navigate to the vulnerable URL using mobile browser (or change the useragent details to any mobile browser UA and open the vulnerable link) for verification.

2. On the bottom of the page you can observe that a variable pid is displayed as "pid=undefined"

3. So pass a variable pid with any XSS payload through the URL hence executing the XSS payload.


The same website is vulnerable to URL redirection as well.

Open redirection vulnerability:

As per owasp, "Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Unvalidated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would normally not be able to access."

The Vulnerable URL is :

Payload used is :

So the execution URL is :

Reproduction Instructions / Proof of Concept

Make sure to use a mobile browser or a browser with mobile user agent....

1. Navigate to the vulnerable URL using mobile browser (or change the user-agent to any mobile browser UA and open the vulnerable link) for verification.

You will find yourself redirected to as it is a mobile browser.

POC: As this is DOM based redirection, can not disclose the poc without disclosing the target :(

Thanks for reading.. As always suggestions and queries are welcome.

Saturday, 16 April 2016

How I could Delete Instagram Captions and Comments that are not mine,.....

Its been a while since i published my last post. So, here i come with a write up for chaining of multiple issues in Facebook Acquisition - Instagram, that could allowed me to delete entire comments/captions from the Instagram DB.

Instagram Web and mobile Applications
For the first 2 hours or so, I could not find anything as each request is added with a signature and I am lazy enough not to understand/reverse the signature logic. So as usual, i was about the close my Mac and then, saw a request without signature.

request without a signature
Bingo..something to play around. so i started working on the request, trying to find most common bugs, like sqli,xss, csrf etc.. Then to cross verify a csrf issue, I used my browser. But to my surprise, in later requests in browser app, there is no signature at all, but of-course csrf issue is properly protected.

So while testing with both the App and Browser together, I realised that there is an authorisation flaw in the comment deletion action. But it requires certain comment ID values, which are (supposed to be) not available for comments other than your's.. So basically, you can not delete other's comments as you wont be having other's comment IDs (such a nice logic).

request used for deleting comments

So i went back through the 10mb of all my burp logs to find, if the comment ids are leaked somewhere. And bingo, there is an api which shows comment ids of all the comments of a picture.

request that fetches comment ids

So now we have all the elements needed to do some DAMAGE....

url :<phto id>/delete/<comment/description id>/

photo id & owner id: to extract the ids of the target photos/comments, make a GET call to<target username>/

comment/description id : to extract the comment id of the target comment, make a GET call to<photo id>_<owner id>/comments/

Now is the time to Delete some comments.... simply make a POST call with web app cookies to<photo id>/delete/<comment id>/

(but don't forget to add the csrf token into headers) and Done.. we have successfully deleted the target comment.

A better and easy (different way of enumeration of necessary information) to exploit the same bug is given in the below video demonstration.

After playing around the api for some more time, i realised that there is no rate limiting applied on the Delete api. 

So i made a small python script which will make a call to target instagram user account to fetch all the photo ids. Then it will make another request to fetch all the comment ids on each photo id. Then finally it will make requests to delete each comment on each photo, there by deleting all comments and captions ever added on any photo of the target user.

deleting all comments on all photos of target user

Thanks for reading/watching... And as usual, suggestions and queries are always welcome.