Writing secure applications is critical. Whether you're writing code at the SMT level, MivaScript level, server level or anywhere else, it's important to keep security in mind. Come in and learn how to mitigate exploits, initiate exploits, and learn about incidence handling.

1. WRITING SECURE CODE
TIMOTHY BOLTON

2. A Briefer History of Tim
Lots of experience coding
Lots of experience writing insecure code
Focus on PCI Compliance w.r.t. Coding

3. Overview
Concepts
Attacks and Mitigations
Incidence Handling
Using this in your daily life

4. Concepts
General security expectations
Confidentiality of data
Integrity of data
Availability of data
Defense in depth
Permission

5. Concepts
Confidentiality
Think “data leaks”, unprotected directories, access
control exploits.
Integrity
Data tampering, Man in the browser attacks
Availability
DoS style attacks

6. Defense In Depth
Layered approaches work well
Use security where it makes sense to use it
Use file system permissions for directories
Use a WAF
Use database access control (GRANT ALL???)
Diagram the moving parts, sensitive data,
and see where points of entry exist.

7. Defense In Depth
Least-privilege principle
Layering of Access-control
URL based access-control
File system & Server permissions
Application (business logic)
Data layer
Application Layer

8. Attacks and Midichlorians
We will focus on three types of attacks
Cross Site Scripting
Cross Site Request Forgery
SQL Injection
There are obviously many more, this is a
small introduction.

9. XSS
Exploits the trust a USER has for a site
A basic attack is going to insert some
JavaScript in the page.

10. Cross Site Scripting (XSS)
Persistent
Reflected
DOM

11. Reflected Example
Coupons, coupons, coupons!
Parameters from GET directly generating
content on the page.

12. Mitigation
Validate user input
Encode output (mvte instead of mvt)
Miva does this with some fields already to
mitigate against XSS Persistence attacks
Usually this is a case by case basis for how to
properly care for data and user-interaction.

13. Cross Site Request Forgery (CSRF)
Exploits the trust a SITE has for a browser.
All browsers are vulnerable to CSRF attacks
You see these attacks in:
XMLHttpRequests
Iframes
Image tags
Script tags

14. CSRF Attacks
DDoS
Bandwidth Consumption
Computationally expensive requests
Unauthorized Actions
Form submission
Images with malicious parameters

15. CSRF Attack Mitigation
Use POST instead of GET for forms
Miva is a bit different here..
Not bullet-proof by any means
Use Anti-CSRF tokens
Regular Session Timeouts
Check HTTP Referrer
CAPTCHA
Flow Control

16. 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 known
Must be present on form submission

17. CSRF Mitigation Chart
Slight Help Weak Medium Hulk Smash
Using POST *
Timeout *
HTTP
Referrer
* *
CAPTCHA * * * *
Flow Control * *
Anti-CSRF
Tokens
* * * *

18. Difference Betwixt XSS and CSRF
XSS – Exploits the trust a USER has with a site
CSRF – Exploits the trust a SITE has with a
browser

19. XSS & CSRF
XSS and CSRF are the “Clinton's” of Security
Exploit Partnerships
Look at your inputs, look at your outputs,
look at your logs. See where attacks are
coming from.

20. 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 vulnerabilities
Custom module development, and greater
access to lower level functionality bring this
back to the surface.

21. What is SQL Injection
username=tim
username=tim' OR 1=1; –
?page=9
?page=8+1

22. What can SQL Injection do?
Changing existing SQL queries
Extract data from the database
Alter data and structure of database
Control the host running the database, move
to other hosts on the network
Get webshells on board

23. SQL Injection Attacks
Non-blind SQL Injection
Error messages help clue you in to what is happening
behind the scenes.
Blind SQL Injection
Use a “Yes” or “No” approach.
“Yes” or “No” can also be determined via response time
if no visual output
More difficult for the attacker, as there aren’t error
messages helping them.
Testing with Blind SQL Injections:
http://target.com/search.php?product=10
Triggers our baseline “true” – Showing us product 10
http://target.com/search.php?product=10’

24. SQL Injection Attack Scenarios
Putting a webshell on board
http://target.com/search.php?query=‘
UNION SELECT “<?php
system($_REQUEST[‘cmd’]);?>” INTO OUTFILE
‘/var/www/test/shell.php’ --
Getting file contents
http://target.com/search.php?query=‘
UNION SELECT 1, load_file(/etc/passwd) --
Dropping Tables
http://target.com/search.php?query=‘ ;

25. 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 connections
Turn off error messages from SQL

26. Title
Parameterize your queries
If you can’t then use mysql_escape_string around user-
generated input
When it makes sense:
Only allow “known good” input
Reject bad input
This is hard to do consistently:
Bill Stinkface lives on 123 Union St.,
Chesapeake Drop, OR.

27. Incidence Handling
Remember Uncle Scar.. be prepared
Monitor and detect
Containment
Eradication
Restoration
What was learned?

28. Incidence Handling
Have a plan
Know who owns what project
Talk to those who are affected

29. Daily Life
Implement Code Reviews
Get a WAF (web application firewall)
Security at design
Do not use weak hashing algorithms
Use unique salted hashes
Use SSL for every page

30. Daily Life
Before going into production, do some pen
testing in QA
Use HSTS (HTTP Strict Transport Security)
Join the list
https://hstspreload.appspot.com/
Cut down your surface area of attack by
hardening your server

31. Daily Life
Set up a web application testing framework
Run incidence response scenarios
Use Anti-CSRF Tokens for forms

32. One Page Take Home
The order of operations for user-input and
data validation
Client side validation
Web Application Firewall (WAF)
Anti-CSRF Tokens
Validation within code
Customized validation for persistence layer

33. PRESENTER’S NAME