Magento Security: XSS injections and avoiding vulnerabilities

XSS injections are a real threat, especially when it comes to ecommerce stores. Learn how to deal with vulnerabilities and attacks both head on and using the right tools.

So, here it is, the security audit report with prioritised web application weaknesses that client wanted to verify and question in mind whether someone exploited them or not..?

While there were no specific examples in the report, only target urls with parameter names, type of injection and solution for it, it was close to impossible to find and verify reported issues without having more details to it: attack vector, OS, browser.

Since we already agreed to provide details the next day, assuming security report is complete, we got no other chance than to get our hands dirty.

But how and what is the most efficient way to do this when you know it is there but you still miss some details?

Magento XSS Injections vs. Head-on Approach

Here we are, having 600+ different XSS attack vectors available in our pocket and randomly taking one out of the stack and observing the results…

“Nope, it’s not there, can’t verify!” — I keep on telling myself.

Clearly, this is the first indication that something has to be changed to avoid the pain, either by denying the existence of the issue or by hammering it even harder.

“We want clear results, and we want them NOW!” — is what I am saying.

We want to 100% verify the existence of claimed weakness in the system or deny it by the same amount.

TOOLS — The Ultimate Answer

No human is capable of delivering needed result in the meaningful timeframe through manual labor except when it’s done by the group of people, even then I can hardly justify the time spent for each involved individual taking into account numbers of combinations ( browser version+ attack vector + URL ).

XSSer — Cross Site “Scripter” – It is what it is. It does what it does.

Simple use of automated injection:
xsser -u “http://site.com”

And here I am with all the details needed to reproduce and verify attack vector on IE7:

Everything I missed in the beginning is now here.

No doubt, it still may be a false positive, but all that is left is to open a named web browser and confirm whether it’s true or not. I have used VM that is freely available from Microsoft.

But to my surprise issue was still not reproducible…

Good guy Microsoft and it’s built-in IE XSS filter!

As you can feel that is the last bit in the puzzle and, finally, vulnerability is verified as in the example below:

Depending on the actual payload, it can be also identified within web page source code instead of having alert box.

Now, when exact environment is known I can easily verify rest of the attack vectors from security report, as well, craft complicated attack vectors using XSSer to verify that same inputs are safe from different attacks.

[Scan results/logs. Very important. Those will be very handy if client wants some proof or examples. ]

XSS Injections vs. Tool-less Approach

Opposed to the use of tools above, more serious XSS vulnerability was verified by trial and error approach on the local environment ( MacOS + Chrome ). So, it’s always a good idea to give it a manual try first. Simplicity and performance — they call it.

The seriousness of this attack vector was in its likelihood because it could be reproduced in ANY modern browser and payload could be crafted to such a complexity that it could deface or otherwise take the full control of a website. However, compared to the previous injections which were crafted in the plain text format this one worked only through the use of Base64 encoding.

Detailed Explanation of the XSS Vulnerability

Now here goes a little detailed explanation of why this have happened and what consequences could there be if proper countermeasures are not taken.

Site visitors want to visit product list, scroll and click on a product and we clearly can’t blame them for these actions!

Once on the product detail page, they may use the “< BACK” link which then would lead back to the same exact spot where they had scrolled in the product list.

Solution:

add ‘referrer’ param to the product link
so, http://site.com/product.html becomes http://site.com/product.html?referrer=SomeEncodedUrlWithPreviousPositionParam
in product page, decode ‘referrer’ param and put it as the href value for BACK link.

All good, everyone is happy.

Now just imagine if I share the link to that product page with param ‘referrer’ attached to it. Before you actually begin to imagine, this is how output looks on the level of code:

<a class=”back-to-top-category-link” ”<?php echo $this->getBackUrl() ?>”><?php echo $this->__(‘Back to %s’, $backTo) ?>

Where getBackUrl() is this:

With a more life-like example in mind, if I encode something like this:

http://site.com/product.html?referrer=http://site.com/category.html?p=1#item_6 as Base64, which then would look more like this:

http://site.com/product.html?referrer=PHNjcmlwdD5hbGVydCgxKTs8L3NjcmlwdD4=

Then, once product page is loaded, page source will look like this:

<a class=”back-to-top-category-link” href=”<script>alert(1″>http://site.com/category.html?p=1#item_6″><script>alert(1)Back to Category

Resulting into alert box shown on the page:

And that’s it, you can put pretty much anything instead of alert(1).

“This is it!”

No, it’s not. The very next thing is to obviously run a regression test — make sure application works at least as previously, this can be simplified through automated browser tests, make sure that same attack vectors are not possible as well ensure that other kind of payloads fail.

And that is what makes your countermeasures complete.

General Magento Security and Dealing with XSS Injections

If it’s not reproducible on your local machine it does not mean that issue is not there. Install Virtual Machine having different environments available for manual testing.

Find tools that can automate your manual process. You will save great amount of time at the end of the day. You will be aided with more clues if certain details are missing. But still, don’t forget to verify results manually.

Pay attention to everything that comes from scary internet and check if it does not need to be sanitised. Especially if it goes back in response.

In short, code with security in mind.

Suffering from malicious attacks? Not sure if you’ve set up your eCommerce store securely? You’ve come to the right place! Scandiweb is the most certified Magento agency in the world with more than a hundred experienced coders and more than a decade of experience under its belt. We’re here to help, so if you have any questions – drop us a line at [email protected] or check out our services page.

Elvis Zunde

Magento Security: XSS Injections