HTTP: GET and POSTThese are two different methods in which HTTP data is passed to scripts
Forms submit information to scripts. 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 and Client Side ScriptingServer 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).
Making the Cookie Kingdom CrumbleCookies 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). SQL InjectionThis 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 ScriptingCross 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 and other Tricks that only Work on IdiotsActiveX, 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.
|
