by Steve Hanna
These are two different methods in which HTTP data is passed to
scripts
Forms submit information to scripts.
GET - Form data is encoded in URL.
POST - Form data is encoded in message body.
This is fairly basic knowledge but it is important to understand how scripts can be exploited. Often it is important to try as many different input combinations as possible to discover vulnerabilities.
Server Side Scripting -
Scripts are processes server side. All execution is the
responsibility of the server. The results
are sent to the client. In most cases it is impossible to view the
actual code that produced the output unless certain exploitation
methods are used.
Examples: ASP, JSP, PHP and Coldfusion
Client Side Scripting - Scripts are processed on the
client side. The browser is responsible for parsing data and
producing output. It is easy to determine
how the script operates and what output will be produced by just
viewing the source of the page.
Examples: Javascript,
VBScript
To exploit either one of these types of web pages it is just a
matter of finding a suitable input that causes the script to behave
in ways that are unexpected. This sounds easier than it actually is,
but often analyzing code can lead to an exploit. Most of the time,
exploits are a result of the web programmers inability to have
foresight about the input that the application will receive. On the
other hand, some exploits are inherent the
the browser software itself (IE mostly) and simple exploits can be
crafted to hurt the client (instead of the normal case of hacking the
server).
Cookies are everywhere. They serve as an authentication byproduct
for many websites. Often, a website will offer a cookie to a user
after they have entered their password. This often serves as a matter
of convenience, but it many cases
(depending on the type of cookie) can present a serious security
risk.
For instance, imagine the situation in which you log
into your favorite bulletin board system. It is your favorite of
course because you are the administrator
and you love the power trip. So you type in your password, you check
the box on your BBS that says " remember me". You do your
normal purging of bad threads, then call it a night. The next day you
go back to the BBS and it asks you to re
authenticate. Weird, you think to yourself, you typed in your
password last night. Before you know it, you look at the publicly
viewable pages and everything has changed, your system was
hacked!
What Happened? This is a true story.
Fortunately, I was on the hacker end and
not the administrator. I discovered a bug inherent in ANY web
applications that use cookies for session to session based
validation. Basically, the problem with this particular BBS software
was that because a user was logged in, they were not forced to type
their password again when they went to preferences. As a result of
that the new password has to be entered twice, without entering the
old password. At this point, some alarm bells should be going off
in your head The simplest way to do this was make a thread on the
forum that contained some very basic HTML. The following HTML is a
basic template of how the original code
worked.
http://www.somesite.com/cgi/ubb/pref?user=admin?pass=0wn3dpass2=0wn3d
Oh,
this code might work, but no one in their right mind would click a
link like this!
Right? Wrong!
Try this <img
src="http://www.somesite.com/cgi/ubb/pref?user=admin?pass=0wn3dpass2=0wn3d"
border ="0" height="0" width="0"&rt;
Now
when any user views this page it will try to change their password.
It will only work for the user specified, which in this case is
really all that matters.
This same tactic was used by me to
exploit thefacebook.com. While it was not the same type of cookie(it
was a session cookie) the password changing tactic was still the
same...it worked like a charm. If HTML is
not enabled, one can send a malicious link to the target, but it
would be wise to encode the data in the link before sending (HEX is
the most basic).
This method is just an extension of fuzzing server and client side
scripting methods. The idea is simple, imagine a request that is
just:
"SELECT address FROM USERNAMES WHERE name =
USERINPUTHERE"
From this point imagine this is some sort of
script that grabs a users address based on the user
name. Well in the case of bad input design, imagine all this
information is stored in one database. It requires minor modification
to completely own the database.
USERINPUTHERE = shanna"";SELECT
* FROM USERNAMES";
"SELECT password FROM USERNAMES WHERE
name = *";"SELECT * FROM USERNAMES";
From
this lines two queries are executed. One dumps the address of the
user name specified, the other dumps all
the records in the USERNAME table. Including password, address, and
whatever sensitive information is stored in
the database.
Although this is a greatly simplified example,
the concepts when applied to larger and more complex databases are
still the same. Including, deleting users, adding users, changing
password, and modifying the database structure.
Cross site scripting is a very general term. In it's most basic
sense it means forcibly inserting html or script into another web
page. When inserted the code runs on what looks like the "real
web server" and can do all kinds of
nasty things.
The general strategy
as is follows,
Look for a script that displays user supplied data in the web page.
Inject a form, or other malicious script to preform the desired task.
Profit.
The simplest example can be found in a site that has some
useless form like:
Please enter your name: HEYHEY
On the next
page: WELCOME, HEYHEY
Wow, really useless. This is an
over simplified piece of garbage, and any
site that might employ such web tactics really isn't worth hacking at
all. The principle is the same though. From this point we could just
inject form data into the web page asking
for a user to re authenticate. Yeah, this
example isn't very clear, but let's take a look at the example used
at thefacebook.com.
thefacebook
CSS.
ActiveX, the most wondrous technology ever invented. While this may or may not be true it surely is a fun way to destroy a client's computer. I'm not going to get into extreme detail about what exactly goes on under the hood here, but basically you create an ActiveX control. This is simply a binary that has some COM interfaces that can be used just about anywhere (programs, web pages, etc.). The basic idea is, create a web page that steals a password, deletes a partition, gives you a million dollars, etc., then embed it in a web page. Send the victim to the web page with the reassurance that if the ActiveX control is run, everything will be safe. Hilarity ensues. This is basically the equivalent of sending someone an email that says DOWNLOAD THIS DOCUMENT.doc .scr. It will only work on your grandma, I assure you.