AVOIDING THE OWASP Top 10
security exploitsFriday, 2 November, 12

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

SECURITYFriday, 2 November, 12

SECURITY CONTINUUM ( unusable )
unrestrictedFriday, 2 November, 12

OWASP Open Web Application Security
ProjectFriday, 2 November, 12

OWASP TOP 10Friday, 2 November,
12

1Friday, 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

2Friday, 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

NOFriday, 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
MANAGEMENTFriday, 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 OBJECTFriday, 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

5Friday, 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
siteFriday, 2 November, 12

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

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

CSRF EXAMPLE Your app Submit
form for evil Evil site Login Accidentally visitFriday, 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

6Friday, 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 CRYPTOGRAPHICFriday, 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 hashingFriday, 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 === $storedHashFriday, 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 === $storedHashFriday, 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 === $storedHashFriday, 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 === $storedHashFriday, 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 URLFriday,
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 TRANSPORTFriday, 2 November,
12 LAYER PROTECTION

SSL/TLSFriday, 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