I am new to information security field. I am searching for XSS vulnerabilities.

In XSS mostly they use <script>alert('XSS')</script> payload for attacking a websites.

In the case of bypassing the XSS filters, they might encode the payload and use the UpperCases <SCriPT>.

In a recent search, I have found a different payload for XSS \";alert('XSS');//. How come this payload can exploit the website?

I am not able to understand this payload. Can anyone explain to me how this works? Are there any other different payloads used for exploiting the websites using XSS? If any please share me the payloads. In what cases the payloads can be used?

closed as too broad by schroeder, Xander, M'vy, Scott Pack, TildalWave Jul 16 '15 at 3:28

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Nitpicking: alert('XSS') is not an attack yet. It is a test to check if a serious attack might be possible. For a complete XSS attack you don't just need a vulnerability but also a way to get that vulnerability to appear in the context of another users web browser and something malicious to do in that context. – Philipp Jul 15 '15 at 14:00
  • Welcome to security.SE. I would suggest that you make your question more specific (it already has a close vote "too broad"). Just asking about a specific payload may be on topic (depends on who you are asking), but asking about any and all possible payloads definitely seems off-topic. – tim Jul 15 '15 at 15:00

By looking at this payload alone, without the rest of the code, it's probably hard to understand it.

Let's say there is JS and PHP code in a website:

var jsvar;
jsvar = "<?php echo $phpvar;?>";

What this code does is it simply assigns a user controlled variable from PHP to the JS variable jsvar. If the PHP variable contains the text test, then the JS variable will become:


If the user would enter just alert() into the PHP variable, the JS variable would become:


...which would not cause XSS because alert() would be just a string.

But if the user/attacker enters \";alert('XSS');//, the JS code would become:

jsvar = "";alert('XSS');//";

Here you can see that the attacker has assigned "" to the jsvar variable, and as the next command, he has entered alert('XSS');. The // on the end is just to comment out the rest of the line. And the \ sign at the beginning of the payload was just to escape the " sign in PHP, so that it is considered just as text in PHP.


It depends on context. Which are of basic 5 types:

  1. HTML context

In the body of an existing HTML tag or at the start and end of the page outside of the tag.

<some_html_tag> user_input </some_html_tag>

In this context you can enter any kind of valid HTML in the user input and it would immediately be rendered by the browser, its an executable context.

Eg: <img src=x onerror=alert(1)>

  1. Attribute Name Context

Inside the opening HTML tag, after tag name or after an attribute value.

<some_html_tag user_input some_attribute_name="some_attribute_value"/>

In this context you can enter an event handler name and JavaScript code following an = symbol and we can have code execution, it can be considered to be an executable context.

Eg: onclick="alert(1)"

  1. Attribute Value Context

Inside the opening HTML tag, after an attribute name separated by an = symbol.

<some_html_tag some_attribute_name="user_input" />
<some_html_tag some_attribute_name='user_input' />
<some_html_tag some_attribute_name=user_input />

There are three variations of this context: - Double quoted attribute - Single quoted attribute - Quote less attribute

Code execution in this context would depend on the type of attribute in which the input appears. There are different types of attributes:

a) Event attributes

These are attributes like onclick, onload etc and the values of these attributes are executed as JavaScript. So anything here is the same as JavaScript context.

b) URL attributes

These are attributes that take URL as a value, for example src attribute of different tags. Entering a JavaScript URL here could lead to JavaScript execution

Eg: javascript:some_javascript()

c) Special URL attributes

These are URL attributes where entering a regular URL can lead to security issues. Some examples are:

<script src="user_input"
<iframe src="user_input"
<frame src="user_input"
<link href="user_input"
<object data="user_input"
<embed src="user_input"
<form action="user_input"
<button formaction="user_input"
<base href="user_input"
<a href="user_input"

Entering just an absolute http or https URL in these cases could affect the security of the website. In some cases if it is possible to upload user controlled data on to the server then even entering relative URLs here would lead to a problem. Some sites might strip off http:// and https:// from the values entered in these attributes to prevent absolute URLs from being entered but there are many ways in which an absolute URL can be specified.

d) META tag attributes

Meta tags like Charset can be influence how the contents of the page are interpreted by the browser. And then there is the http-equiv attribute, it can emulating the behaviour of HTTP response headers. Influencing the values of headers like Content-Type, Set-Cookie etc will have impact on the security of the page.

e) Normal attributes

If the input appears in a normal attribute value then this context must be escaped to lead to code execution. If the attribute is quoted then the corresponding quote must be used to escape the context. In case of unquoted attributes space or backslash should do the job. Once out of this context a new event handler can be added to lead to code execution.


" onclick=alert(1)
' onclick=alert(1)
  1. HTML Comments Context

Inside the comments section of HTML

<!-- some_comment  user_input some_comment -->

This is a non-executable context and it is required to come out this context to execute code. Entering a --> would terminate this context and switch any subsequent text to HTML context.

Eg: --><img src=x onerror=alert(1)>

  1. JavaScript Context

Inside the JavaScript code portions of the page.


This applies to the section enclosed by the SCRIPT tags, in event handler attributes values and in URLs preceding with javascript: .

Inside JavaScript user input could appear in the following contexts:

a) Code context b) Single quoted string context c) Double quoted string context d) Single line comment context e) Multi-line comment context f) Strings being assigned to Executable Sinks

If user input is between SCRIPT tags then, no matter in which of the above contexts it appears you can switch to the HTML context simply by including a closing SCRIPT tag and then insert any HTML.

Eg: </script><img src=x onerror=alert(1)>

Other miscelleneous are VBScript and CSS contexts which aren't much used. But those could be used by context aware scripts (scanners, both static and dynamic) to detect potential XSS (used in Burp Engine).


I would slightly disagree with @pineapplemans answer.

If we use their example code with user input:

<?php $phpvar = $_GET['f']; ?>
var jsvar;
jsvar = "<?php echo $phpvar;?>";

Then the payload \";alert('XSS');// would not execute. This is because the attack string isn't located directly inside the PHP code, so no escape is necessary. Rather, the escape escapes the " which is supposed to close the string, which means the payload will be interpreted as string, not as JavaScript code.

A working payload for this code example would be ";alert('XSS');//, without the \.

Escaping the Escape

My assumption would be that the \";alert('XSS');// payload is meant for situations where " is escaped as \", but \ itself isn't escaped.

Example code would be the code above, with $phpvar = str_replace("\"", "\\\"", $phpvar); inserted.

This would give an attacker jsvar = "\\";alert('XSS');//";, which would execute, as the injected \ escapes the \ which is added to escape the injected ".

  • Yes, thats absolutely true. Thanks for the correction! – stanko Jul 15 '15 at 15:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.