Web Application Security

A web developer's perspective on the issues and challenges of web

application development

Web Application Security

Web application security is a complex topic, a product of current technology as of current situations.  

Web application security involves the developers who create web applications, the attackers and vulnerabilities they exploit.

This presentation will cover: 

• Web Developer's World• Web Attacker's World• Web Application Attacks•  Recent Attacks

Web Developer's World

 

Web Developer's World

Web developers face many issues on a daily basis:• A web developer is expected to be:

o Developer for Client (JavaScript, Flash, etc) Server (PHP, Coldfusion, Perl, Ruby, etc) Database (SQL, MySQL, etc)

o Designer / Artist Graphics HTML/CSS Flash

Web Developer's World

• Web developers are expected to support:o Legacy platform support

Old browsers (IE 6) Old code Client security configurations

o Bleeding edge configurations Latest browsers Latest plug-ins Latest buzz-word based development priorities

• Security Standards?o No commonly accepted standardso Low priority on secure development

Web Developer's Wold

So many issues require prioritization and simplification. There is not enough time in the day for most web developers to

create an application which fits the customer's needs and is very secure.

The use of frameworks and libraries speeds development but also provides an increased opportunity for an attacker to prepare.

Web Attacker's World

 

Web Attacker's World

Web Attackers have exceptional expertise in web development, often beyond typical web developers.

 The nature of web application languages allow the study of

functionality and aid in exploitation.

Lack of security tools for web applications make exploitation simple and detection difficult.

 If an attacker is patient and motivated enough, they will find a

way to exploit a web application.

Web Attacker's World

There are many kinds of people who attack web pages. They can be divided into groups by goals and methods.

• Malware Distribution:o Goal: Expose client computers to malware.o Methods: JavaScript Injection, XSS, File Upload.

• Data Theft: o Goal: Access data, usually for financial gain.o Methods: SQL Injection, XSS, Compromised Client.

• Hacker:o Goal:"Own" server for other purposes.o Methods: SQL Injection, File Upload.

Web Attacker's World

These groups of attackers can also be grouped by the amount of overall damage their actions have to the web host itself:

• Malware Distribution:o Malware exposure is a temporary embarrassment for

many hosts. • Data Theft: 

o Stolen data has legal ramifications for both the host and thief.

• Hacker:o Completely hacked servers are often ransomed or sold as

well as the data they contain.

Web Application Attacks

 

Attacks: Session Hijacking

When users are logged into web applications, unique sessions are created to hold their temporary data.

A session might contain the user's account information, including credit card account or other sensitive data.

If a session's unique id is exposed, then it could be used to bypass authentication while the session is not expired by the server.

Long session timeouts on a server with session information in the URL make the information vulnerable to exploitation.

Attacks: Session Hijacking

For example:     Very weak session security would allows an attacker to

capture the urls a coffee shop customer is visting.  The attacker then retrieves the session id from the captured traffic and visits the same sites as the user with the captured session id.  The attacker would then be accepted by the sites as the previous user.

To avoid session hijacking:• Never let the session id be written into the URL of the

browser.• Expire sessions as soon as possible.

Attacks: URL Restriction Failure

A web application usually begins when a user requests the default page from a URL, such as a user requesting "http://www.company.com".  Company.com might return "index.php" which starts the user's interaction with the web application.

The flow of the web application, one page linking to another, follows a path determined by the web developer.

Some pages are intended for the user to access, and others are not.  If pages not intended for the user are not properly secured, they can benefit an attacker.

Attacks: URL Restriction Failure

If "index.php" is inteded for a user, but "admin.php" is not, the developer might try to hide this page from unauthorized users.

The developer might do nothing and hope no one stumbles upon the page (security though obscurity).

The developer might decide to hide the page from search engines by adding the page to the "robots.txt" for the site.  But the "robots.txt" is readable by anyone and a enticement for an attacker. 

Attack: URL Restriction Failure

Robots.txt Example:  User-Agent: *Disallow: /admin.phpDisallow: /secretDisallow: /dbadmin.phpDisallow: /upload.php

Attacks: URL Restriction Failure

Web applications can accept and pass information in the URL.

For example: domain.com/adm.php?a=add&u=bob&email=bob%40aol.com

With the example, any user requesting that URL might add the user "bob" with the email address of "bob@aol.com".

 If the web application is based upon a common framework or

tool, the attacker can look at open source code for vulnerabilities which can be exploited via the URL without logging in.

Attacks:Cross Site Request Forgery (CSRF)A CSRF is like a URL Restriction Vulnerability, actions can be

triggered via a URL request.  In a more secure configuration, authentication and a session are required for the URL request to be acted upon.

In CSRF, the attacker targets users who have active sessions on vulnerable web pages and tricks them to make the URL request.

For example:    A bank web page user is logged in while reading an email

asking them to click the following link:  https://bank.com/transfer.php?amnt=4000.00&account=1234

Attacks: Injection Attacks

Any data passed to a server is vulnerable to mainipulation. Manipulated data can allow a server or client to be

compromised.

If an attacker can inject JavaScript or HTML, then client computers viewing the page can be manipulated.

If an attacker can inject SQL, the database server is at risk.

If an attacker can inject server code (php, perl, etc) then the web server itself is at risk.

Attacks: Injection Attacks

To allow a injection attack, specific conditions must exist:• HTML Forms must lack validation on at least the server

side.  Client-side validation is better for user interaction but can be bypassed very easily.

• Variables inserted into server code in SQL statements must also lack validation.

• Web server functions to evaluate variables as code without validation allow server code injections (php, perl, etc).

 To protect from an injection attack, trust no data a user can

supply.  Validate before using any data and white-lists are better than black-lists.

Attacks: XSS Attack

XSS attacks are specifically crafted injection attacks.

A XSS attack allows an attacker to alter the functionality of a web application.

 A XSS attack can:• Redirect a user to a phishing web page.• Hijack a user's account and perform actions such as spread

malware links, send messages or even transfer money.

Attacks: XSS Attack

XSS Attacks can be persistent (stored) and non-persistent (reflected).

A Persistent XSS might be a script automatically executed when a web application user's profile page is shown.  The Persistent XSS script would have been inserted by an attacker in the profile creation process.

A Reflected XSS attack might be in the form of a hyperlink sent in an email to a user.  The hyperlink might take the user to a legitimate site, but the site itself loads a malware script due to extra information in the URL.

Recent Attacks

ONS Brazil Power Grid Operator (http://bit.ly/BrazilPowerHack) Effect: Administrative web page compromised but did not effect

power operations.

Method: 1. Robots.txt exposed locations of internal-use web pages.2. Exposed web pages were vulnerable to injection (login page

username field not validated).3. SQL Injection resulted in data exposure of account

information to control web applications.

Recent Attacks

Forta.com, HouseOfFusion.com(http://bit.ly/GalleonCFHack)

Effect: Total server compromise

Method:1. File upload for forum avatar image, executable CFML code

was uploaded.2. While file is uploaded filename and location are predicted

and repeatedly requested, before server was able to validate and delete the CFML file.

3. On the CFML file access by client, malicious code is copied and downloaded to server.

Recent Attacks

Wordpress 2.8.3 Blogs(http://bit.ly/wordpress283hack)

Effect: Reset of admin account password to unknown value.

Method:1. Attacker browses to         http://domain.com/wp-login.php?action=rp&key[]2. Admin account password is reset to random string with no

confirmation email.

Questions?

 

Additional Resources

OWASP Top 10 http://bit.ly/owaspTop10

Insecure Web Appshttp://bit.ly/insecureWebApps