You are on page 1of 53

WEB APPLICATION ATTACKS

BY:
NIKHIL TRIPATHI (12MCMB10)

FLOW OF CONTENTS
INTRODUCTION ACCOUNT HARVESRING DEFENCES AGAINST ACCOUNT HARVESTING SESSION TRACKING DEFENCES AGAINST SESSION TRACKING SQL INJECTION DEFENCES AGAINST SQL INJECTION REFERENCES

INTRODUCTION
Phase 1: Reconnaissance Phase 2: Scanning Phase 3: Gaining access using Application and Operating System Attacks
Stack Based Buffer Overflow Attacks Password Attacks Web Application Attacks deals with security of websites, web

applications, web services. Occurs especially due to flaw in coding.

WEB APPLICATION ATTACKS


Can be conducted even if the Web server uses Secure Sockets Layer (SSL)
SSL used to authenticate the Web server to the browser SSL used to prevent an attacker from intercepting traffic

Web attacks can occur over SSL-encrypted connection


Account harvesting Undermining session tracking SQL Piggybacking

ACCOUNT HARVESTING
Technique used to determine legitimate userIDs and even passwords of a vulnerable application Targets the authentication process when application requests a userID and password Works against applications that have a different error message for users who type in an incorrect userID

Mock Banks error message when a user types an invalid userID

Mock Banks error message when a user types a valid userID, but the wrong password

Account Harvesting Defenses


Make sure that error message is the same when a user types in an incorrect userID or password. Account lock-out can be an option but may result into Denial of Service Attack.

Web Application Session

Tracking
Most Web application generate a session ID to track the users session. Session ID is passed back and forth across the HTTP or HTTPS connection when client browses web pages, enters data into forms, or conducting transactions Session ID allows the Web application to maintain the state of a session with a user

Implementing Session IDs in Web Applications


URL session tracking
Session ID is written directly on browsers location line

Hidden form elements


Hidden Session ID element put into the HTML form Session ID can be seen by user by viewing HTML source code
<INPUT TYPE=HIDDEN NAME=Session VALUE=22343>

Cookies
Most widely used session-tracking method Cookie is an HTTP field that the browser stores on behalf of a Web server, containing info such as user preference and session ID Per-session cookie is stored in browsers memory Persistent cookie is written to the local file system of client

Attacking Session Tracking Mechanisms


Attacker changes his session ID to a value assigned to another user
Application thinks that attacker is the other user

Achilles
A Web proxy Attackers browser configured to send all HTTP and HTTPS data to Achilles Web browser and proxy can run on same or different machines Achilles allows attacker to edit all HTTP/HTTPS fields, persession and persistent cookies, hidden form elements, and URLs. Supports HTTPS connections
-one SSL connection set up between browser and Achilles -Another SSL connection set up between Achilles and Web server

USING COOKIES
Used to refer to the theft of a cookie responsible to authenticate a user to a remote server. Started in 2004 and gained popularity among the hackers like a wildfire. American National agencies faced million dollars losses due to this attack. Falls into the category of the deadliest attacks due to occurrences of huge losses. Can be implemented by first capturing the packets and then analyzing it. Cain & Abel is popular for capturing and APR and Wireshark/Ettercap is popular for analyzing the packets.

HOW IT WORKS?
1. Applicable only if using LANs for accessing the internet. 2. Victim access the internet by accessing the default gateway. 3. Attacker sitting in the same network captures the packet going from victims machine to the default gateway and vice-versa. 4. Now, after capturing, attacker analyze the packets and read the cookies. 5. Next, attacker copies those cookies and set it into his/her browser. 6. Thats it. Now, hell get access to users account.

WORKING(contd.)

SCREENSHOTS FOR SESSION TRACKING

HOW TO PREVENT SESSION TRACKING?


1. If possible, never use any shared network to access your accounts. 2. Otherwise, log out after every few seconds, but it seems impossible. 3. The best way is that web servers should use time stamped cookies but it is still in somewhat, testing phase.

Defending against Web Application Session-Tracking Attacks


Digitally sign or hash session-tracking information Encrypt information in the URL, hidden form element, or cookie Make sure that your session IDs are long enough to prevent accidental collision Apply a timestamp within the session ID variable and encrypt it Allow users to terminate their sessions via a logout button which will invalidate the session ID

SQL Injection/Piggybacking
Attacker may can extend an applications SQL statement to extract or update information that the attacker is not authorized to access Attacker will explore how the Web application interacts with the back-end database by finding a user-supplied input string that will be part of a database query

How does SQL Injection work?


Common vulnerable login query SELECT * FROM users WHERE login = 'victor' AND password = '123' (If it returns something then login!) ASP/MS SQL Server login syntax var sql = "SELECT * FROM users WHERE login = '" + formusr + "' AND password = '" + formpwd + "'";

Injecting through Strings


formusr = ' or 1=1 formpwd = anything Final query would look like this: SELECT * FROM users WHERE username = ' ' or 1=1 AND password = 'anything'

The power of '


It closes the string parameter Everything after is considered part of the SQL command String fields are very common but there are other types of fields: Numeric Dates

If it were numeric?
SELECT * FROM clients WHERE account = 12345678 AND pin = 1111 PHP/MySQL login syntax $sql = "SELECT * FROM clients WHERE " . "account = $formacct AND " . "pin = $formpin";

Injecting Numeric Fields


$formacct = 1 or 1=1 # $formpin = 1111 Final query would look like this: SELECT * FROM clients WHERE account = 1 or 1=1 # AND pin = 1111

Defenses against Piggybacking SQL Commands

Web application must be programmed to carefully filter user-supplied data. Filter input on the client side using Javascript or other techniques. Potentially damaging characters (such as ` ; * % _ ) should be filtered at server side.

REFERENCES
http://www.w3.org/Security/Faq/www-security-faq.html http://www.unixwiz.net/techtips/sql-injection.html (for SQLi) http://www.dvwa.co.uk/ (for vulnerable app) http://w3schools.com http://www.hackforsecurity.net/2013/02/how-to-setup-your-own-lab-forsql.html (for SQLi) http://www.securiteam.com/securityreviews/5DP0N1P76E.html http://www.digizen-security.com (for Achilles)

THANK YOU

You might also like