AVOIDING THE OWASP
Top 10 security exploits
Friday, 2 November, 12

ME
Illustrator turned developer
Team Lead at FreshBooks
Lead developer of CakePHP
PHP developer for 7 years
Friday, 2 November, 12

SECURITY
Friday, 2 November, 12

SECURITY CONTINUUM
(
unusable
)
unrestricted
Friday, 2 November, 12

OWASP
Open Web Application Security Project
Friday, 2 November, 12

OWASP TOP 10
Friday, 2 November, 12

1
Friday, 2 November, 12
SQL INJECTION
‘ OR 1=1 ‘--

RISKS
Permits query manipulation, and arbitrary SQL.
Bad guys can re-write your queries.
Friday, 2 November, 12

SQL INJECTION EXAMPLE
$username = $_POST[‘username’];
$password = $_POST[‘password’];
$query = “SELECT * FROM user
WHERE username = ‘$username’
AND password = ‘$password’”;
$user = $db->query($query);
Friday, 2 November, 12

USER INPUT
$username = “root”;
$password = “‘ OR 1 = 1 --”;
Friday, 2 November, 12

FINAL QUERY
$query = “SELECT * FROM user
WHERE username = ‘root’
AND password = ‘‘ OR 1 = 1 --’”;
Friday, 2 November, 12

FINAL QUERY
$query = “SELECT * FROM user
WHERE username = ‘root’
AND password = ‘‘ OR 1 = 1 --’”;
Friday, 2 November, 12

PREVENTION
Use an ORM or Database abstraction layer that
provides escaping. Doctrine, ZendTable, and
CakePHP all do this.
Use PDO and prepared statements.
Never put user data into a query.
Never use regular expressions, magic quotes, or
addslashes()
Friday, 2 November, 12

EXAMPLE (PDO)
$query = “SELECT * FROM user
WHERE username = ?
AND password = ?”;
$stmt = $db->prepare($query);
$stmt->bindValue($username);
$stmt->bindValue($password);
$result = $db->execute();
Friday, 2 November, 12

2
Friday, 2 November, 12
XSS
<script>alert(‘cross site scripting’);</script>

RISKS
Allows bad guys to do things as the person viewing a
page.
Steal identities, passwords, credit cards, hijack pages
and more.
Friday, 2 November, 12

XSS EXAMPLE
<p>
<?php echo $user[‘bio’]; ?>
</p>
Friday, 2 November, 12

XSS EXAMPLE
<p>
<?php echo $user[‘bio’]; ?>
</p>
Friday, 2 November, 12

You may be thinking, I can use regular expressions
to fix this.
Friday, 2 November, 12

NO
Friday, 2 November, 12

PREVENTION
Regular expressions and strip_tags leave you
vulnerable.
The only solution is output encoding.
Friday, 2 November, 12

EXAMPLE
<p>
<?php echo htmlentities(
$user[‘bio’],
ENT_QUOTES,
‘UTF-8’
); ?>
</p>
Friday, 2 November, 12

DANGERS
Manually encoding is error prone, and you will make
a mistake.
Using a template library like Twig that provides auto-
escaping reduces the chances of screwing up.
Encoding is dependent on context.
Friday, 2 November, 12

3 BROKEN AUTHENTICATION
& SESSION MANAGEMENT
Friday, 2 November, 12
/index.php?PHPSESSID=pwned

RISKS
Identity theft.
Firesheep was an excellent example.
Friday, 2 November, 12

SESSION FIXATION EXAMPLE
<?php
session_start();
if (isset($_GET[‘sessionid’]) {
session_id($_GET[‘sessionid’]);
}
Friday, 2 November, 12

SESSION FIXATION EXAMPLE
<?php
session_start();
if (isset($_GET[‘sessionid’]) {
session_id($_GET[‘sessionid’]);
}
Friday, 2 November, 12

PREVENTION
Rotate session identifiers upon login/logout
Set the HttpOnly flag on session cookies.
Use well tested / mature libraries for authentication.
SSL is always a good idea.
Friday, 2 November, 12

4 INSECURE DIRECT OBJECT
Friday, 2 November, 12
REFERENCE

RISKS
Bad guys can access information they shouldn’t
Bad guys can modify data they shouldn’t.
Friday, 2 November, 12

BROKEN PASSWORD UPDATE
<form action=”/user/update” method=”post”>
<input type=”hidden” name=”userid” value=”4654” />
<input type=”text” name=”new_password” />
<button type=”submit”>Save</button>
</form>
Friday, 2 November, 12

PREVENTION
Remember hidden inputs are not really hidden, and
can be changed by users.
Validate access to all things, don’t depend on things
being hidden/invisible.
If you need to refer to the current user, use session
data not form inputs.
Whitelist properties any form can update.
Friday, 2 November, 12

5
Friday, 2 November, 12
CROSS SITE REQUEST
FORGERY
(CSRF)

RISKS
Evil websites can perform actions for users logged
into your site.
Side effects on GET can be performed via images or
CSS files.
Remember the Gmail contact hack.
Friday, 2 November, 12

CSRF EXAMPLE
Your app
Evil site
Friday, 2 November, 12

CSRF EXAMPLE
Your app
Evil site
Login
Friday, 2 November, 12

CSRF EXAMPLE
Your app
Evil site
Login
Accidentally visit
Friday, 2 November, 12

CSRF EXAMPLE
Your app Submit form for evil
Evil site
Login
Accidentally visit
Friday, 2 November, 12

PREVENTION
Add opaque expiring tokens to all forms.
Requests missing tokens or containing invalid tokens
should be rejected.
Friday, 2 November, 12

SAMPLE CSRF VALIDATION
<?php
if (!$this->validCsrfToken($data, ‘csrf’)) {
throw new ForbiddenException();
}
Friday, 2 November, 12

6
Friday, 2 November, 12
SECURITY
MISCONFIGURATION

RISKS
Default settings can be insecure, and intended for
development not production.
Attackers can use misconfigured software to gain
knowledge and access.
Friday, 2 November, 12

PREVENTION
Know the tools you use, and configure them
correctly.
Keep up to date on vulnerabilities in the tools you
use.
Remove/disable any services/features you aren’t using.
Friday, 2 November, 12

7 INSECURE CRYPTOGRAPHIC
Friday, 2 November, 12
STORAGE
md5(‘password’)

RISKS
Weak cryptographic storage can easily be cracked.
Keys can be exposed with encrypted data.
Backups can contain encrypted data & keys.
Compromised passwords can be used to obtain
information on other sites.
Friday, 2 November, 12

BAD PASSWORD HASHING
$password;
md5($password);
sha1($password);
Friday, 2 November, 12

BAD PASSWORD HASHING
$password;
md5($password);
sha1($password);
Friday, 2 November, 12

USE BCRYPT FOR
PASSWORDS
only you can prevent bad hashing
Friday, 2 November, 12

PREVENTION
Use strong hashing/encryption.
Use one way hashing for passwords. Never use
symmetric encryption for passwords.
Don’t collect data if you don’t need it.
Keep keys separate from data.
If you’re using symmetric encryption, be able to
rotate keys easily.
Friday, 2 November, 12

BCRYPT IN PHP
// password hashing (bcrypt)
$hashed = crypt(
$pass,
‘$2a$10$asdkbisloqi.fidsliz.df190.d9f40’);
// compare later
$hashed = crypt($plaintext, $storedHash);
// check for match
$hashed === $storedHash
Friday, 2 November, 12

BCRYPT IN PHP
// password hashing (bcrypt)
$hashed = crypt(
$pass,
‘$2a$10$asdkbisloqi.fidsliz.df190.d9f40’);
// compare later
$hashed = crypt($plaintext, $storedHash);
// check for match
$hashed === $storedHash
Friday, 2 November, 12

BCRYPT IN PHP
// password hashing (bcrypt)
$hashed = crypt(
$pass,
‘$2a$10$asdkbisloqi.fidsliz.df190.d9f40’);
// compare later
$hashed = crypt($plaintext, $storedHash);
// check for match
$hashed === $storedHash
Friday, 2 November, 12

BCRYPT IN PHP
// password hashing (bcrypt)
$hashed = crypt(
$pass,
‘$2a$10$asdkbisloqi.fidsliz.df190.d9f40’);
// compare later
$hashed = crypt($plaintext, $storedHash);
// check for match
$hashed === $storedHash
Friday, 2 November, 12

USE MCRYPT
// encrypt (rijndael)
$value = mcrypt_encrypt(
‘rijndael-256’,
$secretKey, $ccnumber,‘cbc’, $iv
);
// decrypt
$value = mcrypt_decrypt(
‘rijndael-256’,
$secretKey, $encrypted,‘cbc’, $iv
);
Friday, 2 November, 12

8 FAILURE TO RESTRICT URL
Friday, 2 November, 12
ACCESS

RISK
Hidden things can easily be found.
Creative people will eventually find your hidden URLs
Security through obscurity is a terrible idea.
Friday, 2 November, 12

PREVENTION
Check access to all urls both when you generate
links and more importantly when handling requests.
Don’t rely on things staying hidden.
Friday, 2 November, 12

9 INSUFFICIENT TRANSPORT
Friday, 2 November, 12
LAYER PROTECTION

SSL/TLS
Friday, 2 November, 12

10 UNVALIDATED REDIRECTS &
Friday, 2 November, 12
FORWARDS

RISKS
Trusting user input for redirects opens phishing
attacks.
Breach of trust with your users.
Friday, 2 November, 12

PREVENTION
Don’t trust user data when handling redirects.
Friday, 2 November, 12

QUESTIONS?
Friday, 2 November, 12