diff --git a/Articles/Image/ConsoleCookie.png b/Articles/Image/ConsoleCookie.png new file mode 100644 index 0000000..451d7f5 Binary files /dev/null and b/Articles/Image/ConsoleCookie.png differ diff --git a/Articles/Image/XSSCookie.png b/Articles/Image/XSSCookie.png new file mode 100644 index 0000000..55e0a41 Binary files /dev/null and b/Articles/Image/XSSCookie.png differ diff --git a/Articles/Image/XSS_ImageCookie.png b/Articles/Image/XSS_ImageCookie.png new file mode 100644 index 0000000..fee28ae Binary files /dev/null and b/Articles/Image/XSS_ImageCookie.png differ diff --git a/Articles/Image/XSS_Input.png b/Articles/Image/XSS_Input.png new file mode 100644 index 0000000..e0efc1c Binary files /dev/null and b/Articles/Image/XSS_Input.png differ diff --git a/Articles/Image/XSS_Result.png b/Articles/Image/XSS_Result.png new file mode 100644 index 0000000..703802f Binary files /dev/null and b/Articles/Image/XSS_Result.png differ diff --git a/Articles/st28_XSS.md b/Articles/st28_XSS.md new file mode 100644 index 0000000..50fe47a --- /dev/null +++ b/Articles/st28_XSS.md @@ -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 + +Form input was ".$_GET["input"]."

" +?> + +~~~ + +The code assumes that the user will only input text. So if the user +input was `Hello world` the output would be: + +~~~ html + +

Form input was Hello World

+ +~~~ + +However, if the user input contains JavaScript such as +`` the output becomes: + +![XSS Alertbox Input](Image/XSS_Input.png) + +~~~ html + +

Form input was

+ +~~~ + +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 + +~~~ + + +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=``` + +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= +~~~ + +Which displays as [A Nice Safe Link](http://172.18.0.1/reflected_xss_get.php/?forminput=) + +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 + +~~~ + +~~~ + +![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: +> + +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. + +~~~ + +~~~ + +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))