XSS Hacking Exposed & Explained
By: magikh0e
'\v/`
(o 0) m0o.
(_) / www.IHackedThisBox.com
Work with the security community, not against it
0x1 T.O.C:
(0) Disclaimer
(0a) Credits
(1) XSS huh?, what the $#% is XSS?
(2) What can YOU do with XSS?
(3) Finding XSS vulnerabilities.
(4) Secure your site against XSS.
(5) Evading XSS detection.
This paper is currently being written.
Last edit Feb 6 2006.
0. (Disclaimer)
=================
IHackedThisBox or any of its members can not be held reliable for what you
do with the information learned in this article.
This article like any other IHTB release is intended to improve security,
not break it.
That being said use this information wisely, and dont be a dumbass.
0a. (Credits)
HUP
That guy from.. wait was he even real? wtf?!!?!
c0vert
1. (XSS huh, what the $#%! is XSS?)
======================================
Cross site scripting (XSS) is a type of computer security vulnerability typically found in
web applications which can be used by an attacker to compromise the same origin policy of
client-side scripting languages. Alot of webservers by default are also vulnerable to xss
attacks.
IE.
Novell Netware
--------------
Multiple extensions: .asp, .jsp, .htm, .html
http://novell_netware/nsn/"<script%20language=vbscript>msgbox%20VULN</script>".bas
Apache
---------
http://apache_host/cgi/example?test=<script>alert('xss')</script>
Note that although cross site scripting is also sometimes
abbreviated "CSS", it has nothing to do with the Cascading Style Sheets technology that is
more commonly called CSS.
The term cross site scripting is not a very accurate description of this class of vulnerability.
In the words of XSS pioneer Marc Slemko:
This issue isn't just about scripting, and there isn't necessarily anything cross site about it.
So why the name? It was coined earlier on when the problem was less understood, and it stuck.
Believe me, we have had more important things to do than think of a better name.
2. (What can YOU do with XSS?)
======================================
To date there are three known types of an XSS vulnerability.
Type 1.
---------
This XSS vulnerability is usually called a DOM-based or local XSS.
Type 1 XSS are issues located on server side scripting.
Type 2.
---------
Type 2 XSS is also called a reflected and/or non-persistent vulnerability. This is one of the most
common types of XSS attacks you will find. These types of XSS attacks are possible when user supplied
data is instantly used by server side scripts to generate a page, based on the users input.
Type 3.
---------
Type 3 XSS is also called second-order, stored, or persistent vulnerabilities. Type 3 can have
the most impact out of an XSS vulnerability. Attacks classified in Type 3 will exist when a
user inputs data provided, to a web app. Next the data is stored persistently on the server in
a database of some sort. This data is later displayed to a user on the web page. Feel the need
to eat someones c00kies?
Wow mom! Look I know about XSS, but what can I do with it? And how do I defend against it?!?!?
3. (Finding vulnerable XSS applications)
==============================================
XSS vulnerabilities are very easy to find and exploit.
Alot of administrators & developers simply ignore XSS.
This is usually for one of two reasons.
1. They do not fully understand the impact of XSS vulnerabilities and simply do not bother.
2. They think XSS is not a big deal..
The first steps to finding XSS vulnerabilities in an application is by examining all error messages closely
given by the server. Many times when you request a file from the server that is not there, the server returns
a page with blah blah filename in quotes stating file not found. Interesting enough lets play around with this.
Basic XSS Examples:
Below is a simple test for XSS vulnerability.
If a message box appears with the words XSS,
b00m the site is vulnerable.
<script>alert("XSS")</script>
Some web servers require the ending "/".
<script>alert('XSS')</script>/
Single quotes sometimes help..
<script>alert('XSS')</script>
Overflow attempt for an XSS attack:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa<script>alert('xss')</script>
Search engines are also a fun place to start out testing for XSS vulnerabilities within your site.
In your journey of XSS hax0ring you will find that quite alot of XSS attacks stem from the search
functions within your site. Always remember, anything that accepts user input has the chance of
being vulnerable to an XSS attack.
Some examples below of search engine XSS attacks:
search.php?query=<script>alert('XSS')</script>
search.php?query="><script>alert('XSS')</script>
search.php?query='><script>alert('XSS')</script>
Well, now that we have learned a few different ways to exploit XSS,
how about we move onto securing your site against XSS.
Away we go.......
4. (Secure your site against XSS).
======================================
4a. Filtering techniques.
4b. Mod-Security.
95% of XSS attacks can be avoidable when the developer uses proper filtering on ANY user supplied data.
Making sure every single element supplied by a user is properly sanitized and filtered can be easy in
small environments. However this can become a tedious task to accomplish, especially in legacy and very
large web applications.
Never fear, we have some help for this as well and it does not involve re-evaulation of all the code.
We have a band-aid for you! ModSecurity, we will cover this more soon.
Well if 95% is avoidable, what about the other 5% ? Good question.
In a non perfect world in which we live, you must accept that a web or any application can be a huge
confusing, tangled puzzle. This much confusion along with code can be a very tedious task to edit and
secure every single line. Not one person can catch every single attack or vulnerability.
Hacker technology is very fast. There is no way to re-evaluate everything as the technology emerges
and new concepts arise. Nothing is a sure thing; well except the author of this paper is handsome,
and sexy! HAH you are paying attention. nothing else to see here.. Read on..
Guidelines to follow for protecting your site against XSS
==========================================================
1.) Filter ALL user input: Filter, filter filter.
The reason XSS attacks are mainly possible is BAD user input filtering!
2.) Use existing scripting language functions.
Alot of scripting languages already have built in functions for filtering input, use them!
PHP functions: htmlentities(), strip_tags(), utf8_decode() can assist in writing filtering logic.
Why re-invent the wheel and write your own function to make sure HTML is encoded properly when
we can use htmlentities()?
3.) Allow only safe content 'content that pertains to your app'
Filter for content you WANT. Its better idea to drop 1 piece of information you want, than to allow
one evil character in.
4.) Use YOUR Brain.
When you are the developer of a web application, you will have a much better understanding of the
applications internals and how the app works. Keep in mind hackers are always out to exploit your app.
Trust nothing, always wear tin foil on your head to stop there evil signals.
<!--fill in the rest with your brain here--->
<!--end fill in your brain--->
Ok all this sounds really great, but as you know that re-evaluating a large code base has many issues
within it's self. Auditing and editing code can be very daunting and time consuming.
Have no fear not apache users.
There is a very nice apache module available called Mod-Security.
quote from modsecurity.org:
" ModSecurity(TM) is an open source intrusion detection and prevention engine for web applications (or a
web application firewall).
Operating as an Apache Web server module or standalone, the purpose of ModSecurity is to increase
web application security, protecting web applications from known and unknown attacks. "
I am not going to go through the whole bit of compiling apache with modules etc etc.
That is another tutorial in its self. So assuming all is ready to rock, below is
some examples of configuring modsecurity to block XSS attacks/attempts.
Although it will allow commonly used HTML tags, this filter works fairly well.
SecFilter "<( |\n)*script"
If you wish to completely stop XSS attacks with some risk of breaking functionality,
use the following filter to block all html and javascript related attacks.
SecFilter "<(.|\n)+>"
Modsecurity also works well in providing quick & dirty SQL injection protection.
SecFilter "delete[[:space:]]+from"
SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"
Again another tutorial, but a nice piece of information in relation to..
5. (Evading XSS detection)
=============================
Well now that we have learned about XSS, what it is and how it works, best of
all and most important is how to defend your site against XSS. Now let's move on...
Now we take a look at some techniques an attacker can use to bypass filtering
measures and different methods of detecting and responding to such attacks.
The best way to stop XSS attacks is with proper input filtering.
Oh yea, these are humans writing these filters. People often get
lazy and errors, or let us call them "un-expected features" sometimes
slip into a piece of code.
In this section we will cover ways to by pass some anti xss security measures.
Scenario 1:
Imagine a site with a developer that has created all of her filters for
standard xss stuff, ", ' <,> so on.
Now let's think of the way a search engine works. You input some data into a textbox,
hit search and then the results are displayed. Here is the interesting part, what if
we search for a file that we know does not exist?
We get a message similar to "This filename was not found."
Hmmm..... clickty click lcik......
So lets try to see how we can trick this.
Note: ModSecurity has been tested to block these.
Bypass basic xss filtering using eval() fromCharCode for the vector.
This is a simple attack to use when any sort of quote is filtered:
';!--<SCRIPT>alert(String.fromCharCode(73,72,84,66))</SCRIPT>=&{}
"non php applications usually do not require the ';"
In this example we use no sort of ", ' so no filterage there.
We also use javascript to print the characters or code we wish
to display/run on the server.
The XSS will then run properly and the search page displays the
message, " !--=&{} was not found..." weeeee (=
Bypass xss filtering using html entities for quotes and an image tag to hold the XSS fun:
<IMG SRC=javascript:alert("IHTB")>
Bypass xss filters using grave accent obfuscation:
<IMG SRC=`javascript:alert("IHTB says, 'm0o'")`>
Bypassing XSS detection by encoding your actual xss attack with UTF-8 encoding
is also another example. If all else fails, you can always try to use long UTF-8
unicode without semicolons. You will find that this works quite often since alot
of people do not know how to pad up to 7 numeric characters, or for the
people who like to decode certain strings. Either way have fun!
--------------------------------------------------------------------------------
___
___ /__/\ ___ _____
/ /\ \ \:\ / /\ / /::\
/ /:/ \__\:\ / /:/ / /:/\:\
/__/::\ ___ / /::\ / /:/ / /:/~/::\
\__\/\:\__ /__/\ /:/\:\ / /::\ /__/:/ /:/\:|
\ \:\/\ \ \:\/:/__\/ /__/:/\:\ \ \:\/:/~/:/
\__\::/ \ \::/ \__\/ \:\ \ \::/ /:/
/__/:/ \ \:\ \ \:\ \ \:\/:/
\__\/ \ \:\ \__\/ \ \::/ D0t
\__\/ \__\/ org
0 nhận xét:
Post a Comment