WRITING SECURE CODETIMOTHY BOLTON

A Briefer History of Tim

Lots of experience codingLots of experience writing insecure codeFocus on PCI Compliance w.r.t. Coding

Overview

ConceptsAttacks and MitigationsIncidence HandlingUsing this in your daily life

Concepts

General security expectationsConfidentiality of dataIntegrity of dataAvailability of data

Defense in depthPermission

Concepts

ConfidentialityThink “data leaks”, unprotected directories, access

control exploits.

IntegrityData tampering, Man in the browser attacks

AvailabilityDoS style attacks

Defense In Depth

Layered approaches work wellUse security where it makes sense to use it

Use file system permissions for directoriesUse a WAFUse database access control (GRANT ALL???)

Diagram the moving parts, sensitive data, and see where points of entry exist.

Defense In Depth

Least-privilege principleLayering of Access-control

URL based access-controlFile system & Server permissionsApplication (business logic)Data layerApplication Layer

Attacks and Midichlorians

We will focus on three types of attacksCross Site ScriptingCross Site Request ForgerySQL Injection

There are obviously many more, this is a small introduction.

XSS

Exploits the trust a USER has for a siteA basic attack is going to insert some

JavaScript in the page.

Cross Site Scripting (XSS)

PersistentReflectedDOM

Reflected Example

Coupons, coupons, coupons!Parameters from GET directly generating

content on the page.

Mitigation

Validate user inputEncode output (mvte instead of mvt)Miva does this with some fields already to

mitigate against XSS Persistence attacksUsually this is a case by case basis for how to

properly care for data and user-interaction.

Cross Site Request Forgery (CSRF)

Exploits the trust a SITE has for a browser.All browsers are vulnerable to CSRF attacksYou see these attacks in:

XMLHttpRequestsIframesImage tagsScript tags

CSRF Attacks

DDoSBandwidth ConsumptionComputationally expensive requests

Unauthorized ActionsForm submissionImages with malicious parameters

CSRF Attack Mitigation

Use POST instead of GET for formsMiva is a bit different here..Not bullet-proof by any means

Use Anti-CSRF tokensRegular Session TimeoutsCheck HTTP ReferrerCAPTCHAFlow Control

Anti-CSRF Tokens

It's just a simple 62 step process.Create an element on a form which is

required.This element is unique and not knownMust be present on form submission

CSRF Mitigation Chart

Slight Help Weak Medium Hulk Smash

Using POST *

Timeout *

HTTP

Referrer

* *

CAPTCHA * * * *

Flow Control * *

Anti-CSRF

Tokens

* * * *

Difference Betwixt XSS and CSRF

XSS – Exploits the trust a USER has with a siteCSRF – Exploits the trust a SITE has with a

browser

XSS & CSRF

XSS and CSRF are the “Clinton's” of Security Exploit PartnershipsLook at your inputs, look at your outputs,

look at your logs. See where attacks are coming from.

SQL Injection

MivaScript has parameterization built in.That doesn't always mean people use it.30% of sites in PCI Audits still have exposed

SQL Injection vulnerabilitiesCustom module development, and greater

access to lower level functionality bring this back to the surface.

What is SQL Injection

username=timusername=tim' OR 1=1; –?page=9?page=8+1

What can SQL Injection do?

Changing existing SQL queriesExtract data from the databaseAlter data and structure of databaseControl the host running the database, move

to other hosts on the networkGet webshells on board

SQL Injection Attacks

Non-blind SQL InjectionError messages help clue you in to what is happening

behind the scenes.

Blind SQL InjectionUse a “Yes” or “No” approach.“Yes” or “No” can also be determined via response time

if no visual outputMore difficult for the attacker, as there aren’t error

messages helping them.Testing with Blind SQL Injections:http://target.com/search.php?product=10Triggers our baseline “true” – Showing us product 10http://target.com/search.php?product=10’Triggers the “false” baseline

SQL Injection Attack Scenarios

Putting a webshell on boardhttp://target.com/search.php?query=‘

UNION SELECT “<?php system($_REQUEST[‘cmd’]);?>” INTO OUTFILE ‘/var/www/test/shell.php’ --Getting file contentshttp://target.com/search.php?query=‘

UNION SELECT 1, load_file(/etc/passwd) --Dropping Tableshttp://target.com/search.php?query=‘ ;

DROP TABLE users --

SQL Attack Mitigation

Set up different SQL users with different grants, and use them when performing that type of query.Sometimes using Stored Procedures makes

sense. Monitor SQL outbound connectionsTurn off error messages from SQL

Title

Parameterize your queriesIf you can’t then use mysql_escape_string around user-

generated input

When it makes sense:Only allow “known good” inputReject bad input

This is hard to do consistently:Bill Stinkface lives on 123 Union St.,

Chesapeake Drop, OR.

Incidence Handling

Remember Uncle Scar.. be preparedMonitor and detectContainmentEradicationRestorationWhat was learned?

Incidence Handling

Have a planKnow who owns what projectTalk to those who are affected

Daily Life

Implement Code ReviewsGet a WAF (web application firewall)Security at designDo not use weak hashing algorithmsUse unique salted hashesUse SSL for every page

Daily Life

Before going into production, do some pen testing in QAUse HSTS (HTTP Strict Transport Security)Join the list

https://hstspreload.appspot.com/Cut down your surface area of attack by

hardening your server

Daily Life

Set up a web application testing frameworkRun incidence response scenariosUse Anti-CSRF Tokens for forms

One Page Take Home

The order of operations for user-input and data validationClient side validationWeb Application Firewall (WAF)Anti-CSRF TokensValidation within codeCustomized validation for persistence layer

PRESENTER’S NAME