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