You have just been promoted from a web application developer to a managerial role where you are responsible for the security of the company’s web applications. Happy about the new job, you launch a web application security scan against all websites and find out that all of them have vulnerabilities that need to be fixed.
Being pressed with time and on a limited budget you try to work out which web application vulnerabilities should be fixed and which should be left out, rather than asking your superiors for more time. Sounds familiar, doesn’t it?
And here is where the problems begin. Many people working in the web application security industry think that some technical vulnerabilities are not dangerous so not worth looking into and fixing them. This is a very common misconception; sql injection is more dangerous than a cross-site scripting vulnerability. In this article we will see why this web application security misconception is so common and what such misconception can lead to.
Cross-site scripting, also known as XSS, is a very common web application vulnerability. By exploiting a XSS vulnerability the attacker can inject malicious client-side scripts in a website which is later executed by the victims while browsing the website. There are different cross-site scripting variants, all of which can be used to craft different types of attacks. Read What is cross-site scripting web application vulnerability to learn more about this vulnerability.
Many web application developers think that cross-site scripting is not a dangerous web vulnerability because the victim is the user / visitor of the website rather than the actual web application, the web server or the data stored in the database.
For example if a forum user falls as a victim to a XSS vulnerability, the hacker would only gain access to the forum user’s profile, private messages and forum posts. Therefore we all think that by exploiting a cross-site scripting vulnerability a malicious user can never tamper the web application or steal sensitive data, such as customer details and credit card numbers. That is why in such cases, web application developers prefer to focus and fix web application vulnerabilities which when exploited allow hackers to gain access to server and compromise the website.
What if the victim of the cross-site scripting attack is the forums administrator, as it happened in many cases? In this case, the attackers would gain admin privileges to the forums or any other vulnerable web application.
By combining a cross-site scripting attack with social engineering skills hackers can still penetrate networks, hack web servers and steal sensitive data. That is exactly what happened to the Apache Software Foundation in 2010; an attacker exploited a cross-site scripting vulnerability and worked his or her way up to gain root access to main apache.org shell servers. For more information about this attack, refer to the detailed Apache and JIRA attack documentation.
In the Apache incident mentioned above, the attacker exploited a non-persistent cross-site scripting vulnerability, hence the attacker needed social engineering skills to fully execute the attack. There were other cases in the past where attackers exploited a persistent cross-site scripting attack, which has a much bigger impact and one does not need to have social engineering skills to exploit it. Refer to the cross-site scripting technical documentation for more information about the different XSS variants.
The Apache incident is not the only real life hacking incident where by exploiting a cross-site scripting vulnerability the attackers managed to do a lot of damage. There are several other ones we’ve heard of, but not all have been documented and it is not possible to list them all here.
It is a must to fix all web application vulnerabilities because if exploited, not only the company who owns the web application can sustain damage, but also its customers. And when as such happens, legal issues come into play.
Some people might not be bothered if a particular forum they used has been hacked, even if their forum account was affected. Mostly they reset their password, delete all the hacker’s activity and get back on with life.
But what if the e-banking web application your bank uses is vulnerable to a cross-site scripting attack? If it is, maybe a hacker won’t be able to take the system down but can easily hijack your e-banking session and transfer money out of your account.
As we have just seen a cross-site scripting attack can be used to infiltrate the network of one of the most popular corporations in the world, or to hijack your e-banking session from where hackers can transfer money out of your account.
The aim of this article is not to scare people or show them what an attacker can be up to if he or she exploits a cross-site scripting vulnerability, but to raise awareness about web application security misconceptions.
As a web application developer or security expert you might think that a web application vulnerability on its own might not be enough for a hacker to break into a network or web server. Though it is enough to steal someone’s identity, money and destroy a life. It might also be used in conjunction with other attack methods to break into some of the most secure networks in the world. Seasoned malicious hackers are very smart and most of the time web application developers cannot imagine what they could be up to, so the approach everyone can take is to make sure that every reported web application vulnerability is looked into and fixed.
Download the 15 days trial version of Netsparker to scan all your websites and web applications for vulnerabilities such as XSS and SQL injection. Netsparker will automatically crawl your website and provide you with all the technical details when a vulnerability is detected within minutes. For more information about Netsparker Web Application Security Scanner you can visit the Netsparker product page.