Cross-site scripting (XSS) attack – Part 2

In the last post I went through what is Cross-site scripting and Stored XSS attack, a type of cross-site scripting caused by stored javascript in database from user inputs. If you haven’t read it, here is the link.

As frontend developers we are cons…

In the last post I went through what is Cross-site scripting and Stored XSS attack, a type of cross-site scripting caused by stored javascript in database from user inputs. If you haven’t read it, here is the link.

As frontend developers we are constantly adding and releasing new features or fixing bugs as per business requirements, and it’s hard to keep vigilance on the security side of things. It has become a secondary concern and we are far behind the backend and Devops engineers for whom this is a primary and regular part of their thinking in development process. Today security attacks are on the rise and we need to take measures from both server side and client side before its too late.

In this post I will go through another type of XSS attack and how to defend against it.



2. Reflected Cross-site scripting attack

Suppose a webpage has a form page and on submission a HTTP request is made to check if the username exists. If the validation error then displays back the username entered within its error message, the hacker can take advantage of this vulnerability and enter a script into the input field. When the validation error message throws back the the error message with the script, the script gets executed.
Reflected xss

Another instance is when someone search for a search term, say tesla in their favourite search engine https://www.dooble.com/search?q=tesla.

Search result for Tesla

Imagine if the search term tesla displays above the search results from the search term in the URL, a hacker can possibly replace the tesla parameter in the URL with malicious script, and have that script code execute whenever anybody opens that URL in their browser (Most search engines are possibly protected against this). An attacker could email the URL with the malicious code as a link to a victim, or trick a user into visiting with the URL through a form. On clicking the link the user is then taken to the vulnerable web site, which reflects the attack back to the user’s browser. As it came from a “trusted” server, the browser executes the code.

When the injected script is reflected off the web server as above, we call this type of attack a reflected cross-site scripting attack.



Defence #1 – Again… Escape the content received from HTTP requests

The prevention for these type of attacks are again is to escape the HTML by replacing its special characters with their corresponding entities.
Again gif

I mentioned earlier that most modern UI frameworks protects against XSS (make sure you read the security recommendations in the framework’s documentation) and also about the javascript function encodeURI() that encodes strings, (specifically URI’s). This function encodes special characters except ,/?:@&=+$#'.

http://example.com/blog/1?comment=<script>alert(XSS1)</script>
http://example.com/blog/1?comment=%3Cscript%3Ealert(XSS1)%3C/script%3E

You may as well look into the function encodeURIComponent() which encodes strings that is part of a URI.

Note that both the functions does not escape the ' (single quote) character, as it is a valid character for URIs.

The ' character is commonly used as an alternative to "(double quote) for HTML attributes, e.g. href=’MyUrl’, which may introduce vulnerabilities. As it won’t be escaped, input that includes it, will break the syntax resulting in an injection.

If you are constructing HTML from strings, either use " instead of ' for attribute quotes, or add an extra layer of encoding (' can be encoded as %27).

It is also recommended to use npm libraries like xss-filters and DOMPurify which provides filtering of unsafe characters.

const safeUsername = xssFilters.inHTMLData(unsafeUsername);

Note that xss-filters comes with some warnings, read it here.

When using validation on forms, try to use npm packages similar to validator.js to sanitise the string inputs.

In the next post I will be going through the next type of XSS attack, DOM based XSS attack and how to defend against it. Stay tuned!


Print Share Comment Cite Upload Translate
APA
Mariam Reba Alexander | Sciencx (2024-03-28T10:23:27+00:00) » Cross-site scripting (XSS) attack – Part 2. Retrieved from https://www.scien.cx/2021/07/22/cross-site-scripting-xss-attack-part-2/.
MLA
" » Cross-site scripting (XSS) attack – Part 2." Mariam Reba Alexander | Sciencx - Thursday July 22, 2021, https://www.scien.cx/2021/07/22/cross-site-scripting-xss-attack-part-2/
HARVARD
Mariam Reba Alexander | Sciencx Thursday July 22, 2021 » Cross-site scripting (XSS) attack – Part 2., viewed 2024-03-28T10:23:27+00:00,<https://www.scien.cx/2021/07/22/cross-site-scripting-xss-attack-part-2/>
VANCOUVER
Mariam Reba Alexander | Sciencx - » Cross-site scripting (XSS) attack – Part 2. [Internet]. [Accessed 2024-03-28T10:23:27+00:00]. Available from: https://www.scien.cx/2021/07/22/cross-site-scripting-xss-attack-part-2/
CHICAGO
" » Cross-site scripting (XSS) attack – Part 2." Mariam Reba Alexander | Sciencx - Accessed 2024-03-28T10:23:27+00:00. https://www.scien.cx/2021/07/22/cross-site-scripting-xss-attack-part-2/
IEEE
" » Cross-site scripting (XSS) attack – Part 2." Mariam Reba Alexander | Sciencx [Online]. Available: https://www.scien.cx/2021/07/22/cross-site-scripting-xss-attack-part-2/. [Accessed: 2024-03-28T10:23:27+00:00]
rf:citation
» Cross-site scripting (XSS) attack – Part 2 | Mariam Reba Alexander | Sciencx | https://www.scien.cx/2021/07/22/cross-site-scripting-xss-attack-part-2/ | 2024-03-28T10:23:27+00:00
https://github.com/addpipe/simple-recorderjs-demo