Web Application Hacking and how to defend against it v3 ... · Web Application Hacking and How to Defend Against it Copyright 2005 Deloitte Touche Tohmatsu Ltd©2003 Firm Name/Legal

©2003 Firm Name/Legal EntityWeb Application Hacking and How to Defend Against it Copyright 2005 Deloitte Touche Tohmatsu Ltd

Web Application Hacking and How to Defend Against itMatthew Hackling, Security Services Group, Client Manager

[email protected] Tel: (03) 9208 6610


Agenda


Agenda

•What is a web application?

•What are web applications used for?

•Why do hackers target web

applications?

•What are common failings of web

application security?

•What can do to secure your web

applications?


What is a web application?


What is a web application?

•A web application typically consists of:

–A web server–e.g. IIS or Apache or SunONE

–An application server–e.g. Websphere, Tomcat

–A database server–e.g. SQL Server or Oracle

–Sometimes middleware–e.g. for Mainframe connectivity

–HTML–E.g. the web pages

–Application Code–E.g java, .Net, perl etc.


What are web applications used for?


What are web applications used for?

•Internet Facing

–online banking (e.g. Netbank)

–online share trading (E.g. Commsec)

–online ordering (E.g. Virginblue.com.au)

•Enterprise Applications

–Inventory management

–human resources (e.g. viewing payslips)

–Timesheets

–E-procurement

–Corporate Intranet


Why do hackers target web applications?


Why do hackers target web applications?

•Platform and Network Security are improving

•That’s where the data is!

•It is easy to get to

–Firewalls often allow connections to the web application from the internet

•Web applications are usually “hand-rolled”

not “shrink-wrapped” and security is usually

implemented in an ad-hoc manner


So what?


So what?

•Denial of Service

•Fraud

–Free airline tickets anyone?

•Exposure of confidential information

–E.g. price lists, salary information


What are common security failings of web applications?



•Input Validation (SQL injection

demonstration)

•Session Management

•Information Leakage

•Broken Authentication mechanism

•Poor Business Logic

•Cross Site Scripting in application

(demonstration)



•Input Validation

–If you let invalid input into your web application unintended consequences can result:

–Denial of Service Conditions

–SQL Injection vulnerabilities

–Bypass of authentication mechanism

–SQL INJECTION DEMONSTRATION

–http://toad/insecure_app/logon.asp



•Session Management

–HTTP is a stateless protocol

–GET, PUT, POST

–A session identifier is required to maintain state

–If your session identifier is predictable or re-issued you can have problems

–EXAMPLE – THE CASE OF THE REISSUED SESSIONID



•Information Leakage

–The more information you give an attacker the more sophisticated their attacks can be

–Browsers like to cache things

–Developers like to use comments

–EXAMPLE – THE CASE OF THE CACHED BANK ACCOUNTS



•Broken Authentication Mechanism

–Your authentication mechanism shouldn’t:

–Allow enumeration of user accounts

–E.g. Display a different error message if you have a correct account name

–Shouldn’t allow you to enter a blank username and password (DOH!)

–Shouldn’t allow you to enter an incorrect password (DOH!)

–Shouldn’t allow you to specify parameters to be used as part of the authentication mechanism!



•Poor Business Logic

–Your application shouldn’t:

–Allow parameter manipulation to access functions that should be restricted

–Allow parameter manipulation to allow you to access other users data

–EXAMPLE THE CASE OF THE WAY BROKEN HR SYSTEM



•Cross Site Scripting

–Your application shouldn’t:

–Allow scripts to be stored in the web application and executed under the context of another user

DEMONSTRATION Cross Site Scripting in an application

http://toad/insecure_app/logon.asp


What can you do to secure your web applications?


What can you do to secure your web applications?

•Known Good Input Validation

•Secure Session Mechanism

•Prevent Caching of browser

•Acceptance Testing

•Alignment with OWASP standards

–http://www.owasp.org


The liability of Deloitte Touche Tohmatsu Ltd, is limited by, and to the extent of, the Accountant's Scheme

under the Professional Standards Act 1994 (NSW).

Commercial in Confidence

This proposal contains commercially sensitive information and methodologies.

Accordingly, any copying or distribution to any person other than the CEO, Chairman

and Board is prohibited without our express written permission.

Documents

Web Application Hacking and how to defend against it v3 ... · Web Application Hacking and How to Defend Against it Copyright 2005 Deloitte Touche Tohmatsu Ltd©2003 Firm Name/Legal