Cross-Site Scripting (XSS) is a cyber attack in which a hacker inserts malicious code into a web form or url of a web application. This malicious code, written in a scripting language like JavaScript or PHP, can do anything from destroy the page you’re trying to load to steal your passwords or other login credentials.

XSS makes use of an important aspect of the modern internet, which is the fact that most web pages are created while pages are being loaded, sometimes by executing code in the browser itself. This can make it difficult to prevent such attacks.

Check also:

How does an XSS attack work?

Anyone can create a website that contains malicious code. In the case of a cross-site scripting attack, the attacker arranges everything so that his code reaches the victim’s computer when he visits someone else’s website. This is where the “cross” in the name comes from. XSS attacks achieve this without requiring privileged access to a web server to surreptitiously put code on. Instead, attackers take advantage of the way modern websites work.

If someone asked you for a simple and basic explanation of how the web works, you could probably tell them something like this: the person who wants to create a web page writes an HTML document and places it on a web server; When the user wants to access this page, he directs his browser to the server address, the browser downloads and interprets the HTML code, and builds a copy of the user’s web page.

This description is not wrong, but some aspects are outdated (and have been around for over ten years). First, many, if not all, web pages are dynamic today – that is, they don’t display the same static HTML to every visitor, but rather are generated instantly from information in the server’s database when the browser requests access. The page that the browser receives from the server often depends on the information sent with the request – information that sometimes takes the form of parameters in the URL used to access the site. Websites not only consist of HTML and Cascading Style Sheets (CSS) that describe how to display text and graphics, but they also contain executable code written in scripting languages, usually JavaScript.

In an XSS attack, the hacker uses this interaction between the user and the website to execute malicious code on the user’s computer. but how? Consider the following URL:

https://www.google.com/search?q=CSO+online

Enter this into the address bar of your browser and you will see Google search results for “CSO Online”. In fact, the page you’ll see looks exactly the same as if you entered “CSO Online” in your browser’s search bar or on the Google homepage. You will notice, among other things, that this phrase appears in several places on the page, including the search bar in the mountains:

What if, instead of the innocent and successful phrase “CSO online”, this URL contained malicious JavaScript code like this?

https://www.google.com/search?<script>doEvil()</script>

doEvil() does a really bad job here. You might be concerned that Google, instead of displaying “CSO Online” on the page you’re returning from this url, will instead dynamically integrate the bad javascript into the page you’re rendering, and that this script is being executed in your browser, causing a mess . Your concerns will be unfounded, because Google has a very large number of talented IT security professionals among its employees and has implemented remedial measures that we will talk about a little later. However, not every site is very careful and this gives you an idea of ​​how such attacks work.

Ataki XSS

XSS attacks fall into several categories: reflected attacks, DOM-based attacks, and stored attacks. Here’s how they differ:

• Reflex attacks: Also known as weak attacks, malicious JavaScript code is sent from the victim’s browser to Google, then reflected back in an executable form, never stored on Google’s servers. These attacks are often part of a phishing scam, where the malicious link is disguised as something more amusing and sent to the victim via email or SMS.
• DOM-based attacks: This is a type of reflex attack called Document Object Model, which is a standard API that defines how browsers build a web page from basic HTML or JavaScript code. Most DOM attacks are similar to the reflex attack described earlier, with the difference that malicious code is never sent to the server: instead it is passed as a parameter to some JavaScript function that is executed in the browser itself, which means that the mechanisms protecting on the server side are unable to protect the user. If you’re interested in the details, PortSwigger has a more detailed description of how DOM attacks work.
• Stored attacks: otherwise persistent; The attacker uses the interactive features of the website to save malicious code on the web server. In a typical example, the attacker leaves a comment on a blog post that contains malicious JavaScript. The next time someone loads this page, the code will be executed.
• Vulnerability to XSS attack

What makes a website vulnerable to an XSS attack? Hopefully our discussion so far has provided some guidance. If your web application naively takes user input, doesn’t check it for malicious executable code, and uses that data to render a page or perform other operations, it is vulnerable to this type of attack.

And the risks are great. The main aspect of browser security is the so-called same-origin policy, which states that a script executing on one page can access data on the other page only if both sides have the same origin (defined as a combination of URI, hostname, and number port). However, if malicious JavaScript can be run in the browser while the victim is accessing the website, the browser will allow the JavaScript to access data from other websites that share a resource with the vulnerable website. JavaScript can access cookies and other proprietary session information, which is a good recipe for hacking victim’s internet accounts.

Payloads XSS

In the parlance of malware, a payload is an executable code that performs actions required by the attacker. In the case of an XSS attack, the payload is a script code that the attacker runs to trick the victim’s browser into being executed.

There is a huge list of XSS payload templates in the Payloadbox repository on GitHub. If you’re familiar with JavaScript, reviewing it might give you an idea of ​​how XSS attackers do their dirty work. However, an XSS attack goes beyond cutting and pasting the payload into the URL: the attacker needs to understand the specific functions and vulnerabilities of the web application he wants to exploit to plan the attack. If you want to dig deeper and see some examples of XSS attacks, check out the OWASP XSS website for an in-depth look at the script code that demonstrates an XSS attack.

XSS Protection and Prevention

If you are building or maintaining a web application or interactive website, there are three main techniques you should consider in your design to avoid potential cross-site scripting attacks.

• Sterilization of input data. The obvious answer to prevent malicious code from being passed as input and returned to the user is simply not to accept script code as input. You should definitely filter your input with this in mind, but that’s easier said than done; Small bits of executable code can slip through filters. One way to deal with this problem is to use a whitelist instead of a blacklist approach – for example, instead of trying to write a filter that will block all malicious code being fed into a web form, you have to write your application to accept the data at certain times Formats (phone numbers, email addresses, etc.) only when that’s what you want.
• Escape from the output. This is the solution to the problem on the other hand. If a web application sends user input back to a web page, this data must be filtered to ensure that it does not become executable on that page. If the user enters HTML tags as input, the application must use overridden characters so that these tags appear as text on the results page rather than integrating with the HTML of the page itself.
• Standard Content Security Policy (CSP). CSP takes the “whitelisting” approach outside of text entry into the realm of scripting: a web application should only execute code that the user has specified to be safe. Google has some great resources on implementing CSP.

XSS test

Vulnerability testing for XSS attacks is an important aspect of ensuring the security of a web application. OWASP has resources detailing how applications can be tested to avoid DOM attacks or reverse cross-site scripting. If you are looking for an XSS sheet, OWASP also has a document with XSS attack code for you that can be used to bypass some XSS defense filters; It will prove invaluable in the penetration tests that you can perform on your own systems.

XSS و CSRF

You may hear that CSRF is used in the same context as XSS. It’s short for Cross-Site Request Forgery, an attack – like XSS – that targets a user’s browser. The main difference is that CSRF uses an authenticated session for the user (maybe they are logged into their bank account) while XSS doesn’t need an authenticated session in order to be effective.

Let’s say a user is logged into Twitter and an internet bank at the same time, and click on a Twitter link that looks like this:

http://www.yourbank.com/sendmoney,do?from=you&to=attacker&amount=5000

Depending on the way your bank manages session tokens and the browser you’re using, they can suddenly become much poorer. XSS is a more dangerous attack vector, but it is important to defend against both XSS and CSRF. OWASP has prepared an information sheet on protection measures against CSRF.

Recent and Infamous XSS Attacks

One of the oldest and most famous cross-site scripting attacks occurred in 2005, when enterprising MySpace user Sammy Kamkar realized he could enter JavaScript code into his profile that would automatically authenticate anyone visiting the site – and also copy that code to the profiles of your new friends, Thanks to that, everyone who visits these pages will also be his friend. (The script made sure that each of Kamkar’s new friends made it into the “top eight” – we’re afraid to understand that, you’d have to be there, but believe us, it mattered.) Within 24 hours, he made over a million friends and forced MySpace to shut down the entire site for a short time.

It turns out that the so-called Sami worm is mostly harmless. However, others were more annoying:

• Ebay had XSS vulnerabilities for years that allowed hackers to steal user login credentials

• XSS attackers were able to steal V-Bucks from Fortnite players in 2019.

• Hacking group Magecart attacked British Airways in 2018 with an XSS attack, stealing hundreds of thousands of user identities

And cross-site scripting remains a serious threat today. As of 2021, XSS vulnerabilities have been found in the Zimbra email platform, Wordpress, and the open source IT management platform Nagios. Keep in mind that hackers usually don’t use attack techniques in isolation: cross-site scripting is a component of a recently discovered complex form of the TLS wildcard attack known as ALPACA. To avoid dangerous threats, make sure you close the XSS vulnerabilities.

Source: CSO