PHP Security Basics

PHP Security Basics John Coggeshall

Welcome!

Welcome to PHP Security Basics

Who am I:

John Coggeshall

Lead, North American Professional Services

PHP 5 Core Contributor

Author: PHP 5 Unleashed

Member of Zend’s Education Advisory Board

May 28, 2009 #

What We’ll Cover Today:

An Introduction to the World of Security

How To Think about Security

Attack Vectors 101

Open Forum for Questions

May 28, 2009 #

Copyright © 2007, Zend Technologies Inc. # 2 Winter, 2007 COMPUTERWORLD Security WASC ComputerWeekly.com In summer 2006, according to a Mitre’s Common Vulnerabilities and Exposures report, SQL Injection vulnerability has become a web application flaw second only to cross-site scripting . Furthermore, some experts argue that this vulnerability is even more significant due to its prevalence in custom web applications created by inexperienced programmers and its direct effect on the database, which is often the most sensitive part of a web application, more critical than the server systems which are typically more exposed. delectix.com

Scope May 28, 2009 #

Security is too large a topic to fully discuss in a 45 minute webinar

In fact, Web Application Security could be one’s life work

The Operating System

The Web Server

The Database Server

The Application

The Protocol

The Browser

The Client Side Language

We are going to stay focused on understanding the Principles of security, with a brief discussion of some common attacks

Lingo

In my discussions I’ll be using a few terms - some are common, some are my own:

Attacker: The bad guy trying to acquire the Principal

Principal: The target of the attacker, be it data or functional change to your application

Attack Vector: An approach used to achieve the compromise of the Principal

Strategic Data: Information used by an attacker to formulate his attack vectors

May 28, 2009 #

Let’s Get Started

Can you describe security?

Security is information

Keeping private information away from others who want it

Getting information from others who want your private information

Information IS power

The power to steal your data

The power to change the behavior of your application

The power to prevent

May 28, 2009 #

The Principal

The Principal is the ultimate goal of the Attacker, and it takes many forms

Examples:

Acquisition of your private data

Credit Card numbers, passwords

Introduction of unintended function

Acquisition of someone else’s data

Further infection of other systems

The Principal is what you must protect

Attackers are interested in a vast array of Principals

May 28, 2009 #

Understand your Principal

Before you can hope to defend anything, you have to understand what you’re defending

What about your application would be appealing to an attacker?

I don’t see many Attackers trying to steal other people’s online dating accounts

I do see a lot of online dating sites concerned about their customer’s financial data being compromised

Not to say that security everywhere isn’t important, but it is a never-ending struggle

Focus on what you think the Principal is

Make sure you can identify other Principals as they become apparent

May 28, 2009 #

Common Principals

Every one has these in common:

Your Visitors

Your Database

Your Server

Every application has its own unique Principals as well

The first step in securing your application is identifying the Principals

The second step is identifying your attack vectors

May 28, 2009 #

Understand the Attack Vectors

Once you’ve identified as many Principals as you can, you now have to defend them

Again, you can’t defend against what you don’t know

Often there are common Attack Vectors useful in attacking many principals

Injection Attacks (SQL, HTTP, HTML, JS, etc., etc., etc.)

Prediction Attacks (Session Fixation, Algorithm Compromising)

Every web application should defend against the usual suspects, and thus the common Principals

But what about your application?

Don’t forget about specific principals and attacks against them

May 28, 2009 #

It is critical to realize that no one step will ensure security… In fact, no combination can ensure it either

There is a best strategy – defense in depth – which means employing a broad range of overlapping security tactics to present a defense to all attack vectors

The concept is to make it so difficult for an attacker to break through all the security measures in place that they are likely to give up and attack a site that is easier to assault

SQL Injection Attacks

SQL (Structured Query Language): involve attacks on a database, by injecting SQL code into a user form that is then submitted

Attack provides attacker with access to data within the database, according to the database user rights, where they could:

Download the entire database contents

Wipe out the entire contents

Corrupt the database structure

Change the data itself

Cause DOS (Denial of Service)

SQL Injection Attacks (continued)

Examples:

$query = "SELECT * FROM table WHERE id = {$_GET['id']}";

http://host/file.php?id=1 %20 AND %20 1=1 (returns entire table)

http://host/file.php?id=1; %20 DELETE %20 FROM %20 table (deletes entire table)

1; ALTER TABLE table CHANGE col1 col1 CHAR(12) (corrupts table)

Corrupt as above; then change data type back (truncates string values)

1; SELECT BENCHMARK(10000000, SHA1(REPEAT(CURDATE(), 10))) (DOS)

$query = “UPDATE users SET password=‘{$_GET[‘newpass’]}’ WHERE user_id = {$userid}”

$_GET[‘newpass’] = “foo’ WHERE user_id=‘admin’ --”; (controls password)

Cross-Site Scripting (XSS)

XSS: Cross-Site Scripting attacks are an injection of HTML, CSS, or script code into a page

JavaScript is especially a threat

Displaying data mis-interpreted by the browser is the primary cause

Example of an attack: Form input

User input details are gathered by probing vulnerable dynamically generated form error messages on a web site

The attacker alters the site’s HTML and inserts malicious code into a link on what looks like the original web site… when the link is clicked by the user, the attacker’s web site handles the request instead of the intended web site

May 28, 2009 #

Session Fixation

User gets a "fixed" session ID

Usually via an specially crafted URL made to look like a real site

Unless specified, PHP will use an assigned session ID as the ID being used

i.e., from cookie or URL

http://www.example.com/?PHPSESSID=123

Basically, you have made an unpredictable value used in secure transactions predictable

May 28, 2009 #

Remember It’s about Information

If you’re not designing applications that help you identify your Principals and how they are attacked, you will fail

Take the extra time to validate your assumptions

You think it’s an integer? Check that

You think that environment variable is A or B? Make sure it’s not C before you use it

LOG LOG LOG LOG LOG LOG LOG LOG ….

And analyze them

Be ready to respond to new threats

May 28, 2009 #

Every piece of information you give the attacker will help him formulate his attack vector

If you were a attacker, what could you derive from the following error message?

Notice: Undefined index: passwd in /usr/local/Zend/apache2/htdocs/includes/usr.inc

Remember, It’s About Information May 28, 2009 #

Thank you! Questions? May 28, 2009 # For additional info on our PHP security classes, please visit: http://www.zend.com/php_security Our next 6-hour online seminar – “Building Security into your PHP Applications” - is being offered on June 26-28, but seats are filling fast! Don’t forget: www.zendcon.com