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
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
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
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
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
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
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
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
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