10th of February, 2020
What Are The Cross-Site Scripting Attacks And How You Can Prevent Them?

Having over 60 million users, WordPress enjoys lots and lots of popularity and adoration. But at the same time, it draws a great amount of evil eye attention. With more and more WordPress development being carried out on a daily basis, cross-scripting attacks are simply inevitable.

Cross-Site Scripting

Commonly known as XSS, cross-site scripting is nothing but a web security vulnerability that allows an attacker to compromise in regards to the interactions experienced by the end-user with any or every vulnerable application. Technically speaking, every website features some origin policy that segregates one from another. Via cross-site scripting, an attacker can easily masquerade as a victim user. To be more specific, nothing can stop him from carrying out actions that a normal user is able to perform and of course, access their crucial data. The most interesting thing here is being a victim user has its own privileges such as gaining full control over all of the application's functionality and data.

Cross-Site Scripting Attacks: Image 1

It’s working!

In simple words, when someone tries manipulating an unsecured website, a malicious JavaScript is being released as a virus to its end users. As soon as the code executes inside a victim’s browser, the attacker gets the power to compromise their interaction with the mobile application or WordPress website. Now there are three main types of XSS attacks experienced over the years.

Reflected XSS- The malicious script enters via the current HTTP request. As soon as an application receives data in an HTTP request, this leads to vulnerability. For example,

Cross-Site Scripting Attacks: Image 2


<p>Status: All is well.</p>

Which means, an attacker can easily construct an attack like this:

<p>Status: <script>/* Bad stuff here... */</script></p>

In case, if the user visits the URL constructed by the attacker, the attacker’s script automatically executes in the user's browser, in the context of that user's session with the application. If simply put, the script can carry out any action, and retrieve any data, to which the user has access.

Stored XSS- unlike Reflected XSS, the malicious script comes from the website’s database. Via HTTP, the data might be submitted to the application. For instance, comments on a blog posts, users nicknames in a chat room, contact details on a customer order and so more. Here’s a live example - A message board application lets users submit messages, which are displayed to other users:

Cross-Site Scripting Attacks: Image 3

<p>Hello, this is my message!</p>

The application doesn't perform any other processing of the data, so an attacker can easily send a message that attacks other users:

<p><script>/* Bad stuff here... */</script></p>

DOM-based XSS- The dangerous of all, here the vulnerability exists in client-side code rather than server-side code. When an application features some client side javascript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.

<img src="https://upload.wikimedia.org/wikipedia/commons/b/b6/Nurmuhammed2.png" alt="image"/>
var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

If the attacker can control the value of the input field, they can easily construct a malicious value that causes their own script to execute:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

By using XSS, the bad guys can:

My solution

Make sure as a business owner you try creating or building a web application using some kind of security development lifecycle (SDL). Ask your WordPress developer, to keep development and security on the same page. This will surely result in reducing the number of security-related design and coding errors in an application or the severity of any errors the undetected ones. Now one of the basic yet crucial rules is while developing secure applications is to assume that all data received by the application is from an untrusted source. This applies to any data received by the application including data, cookies, emails, files or images and even of those who have logged into their account and authenticated themselves.

Apart from this, client-side validation is not something one should rely upon so in such cases, forcing user input down to a minimal alphanumeric set with server-side processing before being used by your Web application in any way. Several regular expressions to search and replace user input can be used to ensure its non-malicious.<cut /> Now, do you think web applications require to accept rich data to eliminate the risk of XSS? Probably not! There might be times when an application will need to accept special HTML characters like "<" and ">", securely encoding such input can be tricky due to the flexibility and complexity of HTML. All you have to do is just ensure that all your WordPress developers incorporate these additional safety features into their code.

In the end, everything boils down to Web developers to follow a secure development life cycle and web administrators to scan their sites for vulnerabilities and protect them with a Web application firewall to prevent XSS attacks. After all, it's your customers and your reputation that XSS damages.

Rooney Reeves
Rooney Reeves Guest Author

Rooney Reeves is working as a Business Development Executive at – eTatvaSoft, a WordPress Development Company. Know more about the upcoming technologies related news. She always accepts challenges and puts some effort into it. She loves to write and spread her knowledge through writing. Follow her on Twitter.

You may also be interested: