Analysis and defense of XSS cross-site scripting attacks

01

Introduction to XSS cross-site scripting

Cross-Site Scripting (XSS) is a common computer security vulnerability in web applications, which is caused by insufficient filtering of user input in web applications. Attackers exploit website vulnerabilities to inject malicious script code (usually including HTML code and client-side Javascript script) into web pages. When other users browse these web pages, the malicious code in them is executed, and various attacks such as cookie data theft, session hijacking, and phishing deception may be carried out against the victim.

XSS cross-site scripting attacks do not directly harm the web server, but they spread through the website, attacking a large number of users. Attackers generally send a carefully constructed malicious URL to the victim through messages, emails, or other means. When the victim opens the URL in a web browser, the malicious script runs silently on the victim's computer, as shown in the flowchart:

02

The harm of XSS

1. Phishing, including stealing various user accounts;

2. Stealing user cookies to obtain user privacy information, or using user identities to further operate on the website;

3. Hijacking user (browser) sessions to perform arbitrary operations, such as illegal transfers, forced logging, sending emails, etc.;

4. Forcing pop-up advertising pages,刷流量and so on;

5. Website trojans;

6. Performing malicious operations, such as arbitrarily modifying page information, deleting articles, etc.;

7. Conducting a large number of client-side attacks, such as DDoS attacks;

8. Combining with other vulnerabilities, such as CSRF vulnerabilities, to carry out further malicious activities;

9. Spreading cross-site scripting worms, etc.

03

The principle and cases of XSS

XSS is divided into two major types based on its characteristics and exploitation methods: one is reflective cross-site scripting; the other is persistent cross-site scripting.

1. Reflective XSS

Reflective cross-site scripting is also known as non-persistent, parameter-based cross-site scripting. This type of cross-site scripting is the most common and widely used, mainly used to attach malicious scripts to the parameters of URL addresses, for example:

http://www.test.com/search.php?key=”><script>alert(“XSS”)</script>

http://www.test.com/logout.asp?out=1&ur1=javascript:alert(document.cookie)

The exploitation of reflective XSS is generally through specific methods (such as using email) to lure users to visit a URL containing malicious code. When the victim clicks on these specially designed links, the malicious JavaScript code will be executed directly in the browser of the victim's host. Its characteristic is that it is triggered only when the user clicks, and it is executed only once, non-persistent, hence the name reflective cross-site scripting.

The attack process of reflective XSS is shown in the figure below:

This type of XSS usually appears in places such as the website's search bar, user login page, etc., and is often used to steal client cookies or carry out phishing fraud.

The following is a case of reflective XSS: when malicious JavaScript code is entered in the name submission box of the website, clicking the submit button triggers a reflective XSS attack, as shown in the figure below:

The harm of reflective XSS is often less than that of persistent XSS because the malicious code is exposed in the URL parameters and requires users to click at all times to trigger it. Users with a little security awareness can easily see through the link as being untrusted. As a result, the cost of reflective XSS attacks is much higher than that of persistent XSS.

2. Persistent XSS

Persistent cross-site scripting is also known as stored cross-site scripting and is more threatening than reflective cross-site scripting, and may affect the security of the web server itself.

This type of XSS does not require users to click on a specific URL to execute cross-site scripting. The attacker uploads or stores malicious JavaScript code on a vulnerable server in advance, and as long as the victim browses a page containing this malicious JavaScript code, the malicious code will be executed.

The attack process of persistent XSS is shown in the figure below:

Persistent XSS generally appears in the interactive areas of websites such as message boards, comments, blog logs, etc. Malicious scripts are stored in the client's or server's database, and when other users browse the web page, the site reads the illegal data stored by the malicious user from the database and then displays it on the page, executing malicious code on the browser of the victim's host.

The following is a case of persistent XSS: when the attacker inputs malicious JavaScript code into the message box and submits it, other users will trigger a persistent XSS attack when browsing this page, as shown in the figure:

Persistent XSS does not require users to click on the URL to trigger it, so its harm is greater than that of reflective XSS. Hackers can use it to penetrate websites, plant malware, phishing, and so on...

04

XSS Defense Plan

XSS vulnerabilities are caused by not strictly filtering user submitted data, so the defense principle is to not trust user input data, filter the input, and encode the output.

1. Use XSS Filter

Validly validate the information submitted by users, only accept content with appropriate format within the specified length range, and block or ignore any other data. In addition, it is also necessary to filter and sanitize valid and harmful inputs.

For example:

▻ Specify the type of form data values: age must be int, name must be alphanumeric, etc.

▻ Filter or remove special HTML tags: <script>, <iframe>, etc.

▻ Filter tags of js events: onclick, onerror, onfocus, etc.

2. Use encoding (HTMLEncode)

HTML encoding can play a significant role in preventing XSS attacks. It mainly uses corresponding HTML entities to replace literal characters, ensuring that the browser treats potentially malicious characters as content of the HTML document rather than structure.

The HTML encoding of some common characters that may cause problems is shown in the table below:

3. JavaScript encoding

This principle mainly targets dynamically generated JavaScript code, including script parts and event handling attributes of HTML tags (such as onerror, onload, etc.). There is only one safe situation when inserting data into JavaScript code, which is to encode untrusted data and only place these data in the value part enclosed by quotes, in addition to the above escaping, the following escaping should also be added:

\ is converted to \\

/ is converted to \/

; is converted to；(full-width ;)

4. Http Only cookie

The purpose of many XSS attacks is to obtain users' cookies. Marking important cookies as 'Http Only' will cause the browser to include the cookie field when sending requests to the server, but cookies cannot be accessed in scripts, thus avoiding XSS attacks from using JavaScript's document.cookie to obtain cookies.