Arastta 1.6.2 XSS Disclosure

Synopsis: Arastta 1.6.2 xss vulnerability
Product: Arastta eCommerce: Free Shopping Cart
Version: 1.6.2
Researcher: Matt Landers

The xss that I have found is fairly straight forward."--!>GIF89a/*<svg/onload=alert(document.cookie)>*/=alert(document.domain)//;

Replace '' with the server you would like to test.


Peel Shopping Cart 9.0.0 csrf/xss disclosure.

Description: Peel Shopping Cart is prone to various CSRF and XSS vulnerabilities.
The csrf example below opens two tabs. The first tab adds an item to the users cart
and the second tab modifies the attributes of that item showing a Post XSS.

Also the XSS appears to be persistant as long as the modified cart item, remains in the cart.

Here is a link to a poc, obviously replace all hostnames with the host you would like to test.

1 Post XSS + 2 CSRF = FUN!

I seem to be running in to quite a few ‘Post xss’ vulnerabilities lately. I generally try to find a csrf to turn it in to a more valid threat.

A few months ago I was reviewing a popular web based marketplace software and discovered a Post xss when modifying parameters on an in cart item. Yes! I was able to find a csrf that made the Post xss a little more exploitable.

This alone could have been a stopping point, but how do I make sure that there is something in the victims shopping cart to begin with? If the cart is empty our payload will not work. You guessed it! Luckily enough I was able to find another csrf that allowed me to add an item to the victims cart.

The culmination of this was to include both csrf vulnerabilities into the same poc html. The first adds the item to the victims cart and the second modifies the item to insert our xss code. In the poc I had it auto submit both requests opening two separate tabs so that we can see what is happening.

The problem is that the first csrf vulnerability needs to have time to add an item to the cart before the second one tries to modify a parameter on said item to include our payload. For this I used

<form id=”additemcsrf” target=”_blank” form action=”etc etc” and

<form id=”csrftoxss” target=”+blank” form action=”etc etc”

Then to bring them together and add timing so that the item gets added to the cart before we modify it with the second csrf.

window.setTimeout( function () { document.forms.csrftoxss.submit()}, 1000);

This will let the item get added with enough time for the second tab to open and our XSS to pop. Also after the item in carts parameters have been modified the xss will execute every time the victim views their shopping cart until the item is removed.

Luckily I only needed two csrf vulnerabilities to make the xss pop however if needed we could chase all around the site until all of the conditions were met via forged forms.

Public disclosure forthcoming after the allocated time frame has ended.



Using Burp on ActiveX hosts.

When using Burp and you receive a “No response received from remote server.” Check to see if the site requires ActiveX (cheap ip cameras etc). After seeing requiresActiveX=true, the work around was to insert this in to the match & replace.

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36


Symlink Race Conditions

In the 2000s I had found some minor symlink race conditions and wrote short advisories about each one.  For posterity I am posting them again here.  Also to raise the question, is mktemp used so commonly now that tmp symlink type vulnerabilities are no longer an issue?

Keep in mind this was from a while ago, I am hoping that my penmanship and technical skill level have risen since then.


Prismstumbler 0.7.3 File Overwrite

x11amp ver .70 File Overwrite

Flying rev. 6.20 Read any file

Linberto v1.0.2 (Q-Bert clone) File Overwrite