This presentation by Christopher Grayson covers some lessons learned as a security professional that has made his way into software engineering full time.

1. Started In Security
Now I’m Here
Christopher Grayson (OSCE)
Tales from a hacker-turned-code-monkey

2. INTRODUCTION

3. 3
WHOAMI

4. 4
What Are We Talking About?
• A journey from security to software
• Going from software to security seems to be
more common
• No formal development training, so lots of
“learning opportunities”

5. 5
Why Are We Talking About It?
• Differences in perspective yield valuable
lessons
• The security field has a problem w/ only
chatting amongst themselves
• I want my headaches to prevent similar
headaches for my colleagues

6. 6
Agenda
1. My Background
2. Core Security Concepts
3. Lessons Learned
4. Security Regression
5. Conclusion

7. A BIT OF BACKGROUND

8. 8
It All Started With Mega Man X
• Parents in IT and psychology, raised a white-hat
hacker
• Mega Man X was my first teacher
• Starcraft map editor was my first exposure to
coding
• I thought I wanted to be a video game
developer

9. 9
“Professional” Life And Beyond
• Brief stint in development at a marketing
company
• Landed a job as a research scientist on a DARPA
contract
• Got into security through a student org
• Broke into all the things, noticed a sorely
missing capability, left to build it

10. 10
Web Sight High-level Architecture
• Massive, scalable data gathering platform
• Back-end written in Python, front-end in
Angular 2 (yay Typescript)
• Uses Redis, PostgreSQL, RabbitMQ, Celery,
Elasticsearch, Django Rest Framework
• Deployed in EC2, has been deployed on DO
• Used to use Docker

11. SECURITY CONCEPTS

12. 12
Definitions Of Hacking
Give me a set of rules, and I’ll follow those rules and
accomplish something they weren’t meant to allow.
Finding the difference between what something was made to
do and what something can do.
- lavalamp
- xray

13. 13
Principle Of Least Privilege
…in a particular abstraction layer of a computing
environment, every module must be able to access only the
information and resources that are necessary for its
legitimate purpose.
- Wikipedia
• Obvious
• Deceptively difficult
• Halting problem!
• Common causes for violation:
• Scope creep
• Unknown framework functionality
• Definition of hacking

14. 14
OWASP Top 10
• Open Web Application Security Project
• Maintains a list of most common web
vulnerabilities by year
• Rarely changes year-to-year
• Common vulns we may touch on:
• Cross-site Scripting (XSS)
• Cross-site Request Forgery (CSRF)
• SQL Injection (SQLI)

15. <div></div><script>Alert(’Hi’);</script>
15
The Problem Of Injection / Data Confusion
• Many vulnerabilities can be tied to software confusing data for control
characters or packaging
• SQL Injection • Template Injection • Cross-site Scripting
userId = 1;
Expected
userId = 1 or 1=1;
Actual
$sql = “select * from users where userId =
“ . $_GET[“userId”] + “;”;
$result = mysql_query($sql);
Code
select * from users where userId = 1 or
1=1;
Result
user_name = “chris”
Expected
user_name = “{{ 2 + 2 }}”
Actual
template = “Hello there %s” % user_name
r_template = Template(template)
Code
Hello there {{ 2 + 2 }}
Result
user_name = “chris”
Expected
User_name =
“</div><script>Alert(‘Hi’);</script>”
Actual
<div> Hello {{user_name}} </div>
Code
Result

16. 16
Fail Open vs. Fail Closed
• ”Fail closed” refers to a situation in which,
when an error occurs, execution is halted.
• ”Fail open” would instead allow processing to
continue.
• Security professionals love fail closed
• Software developers tend to prefer fail open

17. 17
Complexity vs. Security
• At a theoretical level, complexity and security
have a strong inverse relationship
• Put simply, the more complex something is the
more difficult it is to secure
• Keep It Simple Stupid (KISS) has implications
for both ease of code maintenance and code
security
0
1
2
3
4
5
6
1 2 3 4 5
Complexity Security

18. LESSONS LEARNED

19. 19
Where Does Security Fit?
• Initial architectural discussions
• QA step for sprints/releases/etc.
• Black/grey/white-box testing for software post-
deployment
• Developers should give security veto power
• Security professionals must consider realistic
constraints

20. 20
Security Costs Time
• When in a tight spot, security is commonly one
of the first considerations to fall by the way-
side
• Any improvements to development speed
(enhanced devops, continuous integration)
should be considered security enhancements
• The ultimate cost of security with respect to
development is time

21. 21
Full-featured == Dangerous
• Know. Your. Frameworks. Inside and out.
• If going from nothing to a full-fledged web app
takes a minimal amount of code, a LOT of
things are happening out of sight
• Architects must know the ins and outs of any
core frameworks they use

22. 22
Full-featured == Dangerous (Django)
from django.contrib.auth.models import User, Group
from rest_framework import viewsets
from tutorial.quickstart.serializers import UserSerializer,
GroupSerializerclass
UserViewSet(viewsets.ModelViewSet):
""”
API endpoint that allows users to be viewed or edited.
""”
queryset = User.objects.all().order_by('-date_joined')
serializer_class = UserSerializerclass
GroupViewSet(viewsets.ModelViewSet):
""”
API endpoint that allows groups to be viewed or edited.
""”
queryset = Group.objects.all()
serializer_class = GroupSerializer
• Does this look familiar?
• Is this what you want?
• Full CRUD access to User instances
• Is there a field on User that
application users should not be
able to modify?
• Indirect Object Reference

23. class WelcomeController < ApplicationController
def index
render params[:id]
end
end
23
Full-featured == Dangerous (Ruby on Rails)
• RoR documented best practice
• Vulnerable to remote code
execution (CVE-2016-2098)
• Pass dictionary as parameter,
dictionary unpacked as keyword
arguments to render method,
supply template keyword
argument, code execution!

24. 24
Single-page Apps == 
• Single page apps (SPAs) immediately protect
against severe vulnerabilities out of the box
• Cross-site request forgery
• Cross-site scripting
• Great separation of responsibilities
• Greatly reduced complexity of back-end
• Vulns in front-end only affect individual users
instead of entire user-base

25. 25
Quick n’ Easy Security Gains
• Security Response Headers
• HTTP Strict Transport Security
• Content Security Policy
• Frame Options
• Content Sniffing
• Cross-site Scripting Protection
• Cookie Flags
• HTTP Only
• Secure
• SSL
• No excuse for no encryption
• Regular Expressions
• Strongest form of input validation
• HTML Entity Encoding
• De-fang all user input from injection
capabilities
• Object-relational Mapping (ORM)
• Let a framework handle database
interaction, avoid injection

26. 26
Quick n’ Dirty Security Gotchas
• Improper Input Validation
• Blacklists are weak – always prefer
whitelists, regexes where possible
• Attackers rely on being able to submit
unexpected data
• User-generated Templates
• Back to the confusion between data
and control
• Authentication Back-end
• LDAP-based auth should not be publicly
exposed
• Automation
• Sensitive operations should only be
invoked manually
• Insufficient Randomness
• Sensitive random values (ie: activation
tokens, forgot password tokens, etc.)
must be securely random
• User Enumeration
• Feels innocuous, but a list of valid users
goes a long way for attackers

27. SECURITY REGRESSION

28. 28
The Problem Of Regression
• Regression testing for codebases is a large
problem with a standardized solution
• Regression with respect to security is an even
larger problem
• Just because a vuln is fixed once does not
mean it remains fixed

29. 29
Unit Testing To Address Regression
• Take the approach used to fix regression issues
in codebases and use it to address security
regression as well
• Integrate into deployment process to ensure
that security holes remain fixed for every
deployment
• Security teams can write unit tests, hand off to
developers, use TDD to improve security

30. 30
Security Regression Testing
• Proper Input Validation
• Presence of Expected Security Headers
• Anti-automation
• Proper Access Control Enforcement
I am currently working on a base framework to provide this
functionality, to be released at QCon NYC (late June 2017)

31. CONCLUSION

32. 32
Takeaways
• Security should be integrated into development efforts from square one
• Security is hard, and expecting developers to know how to do it properly
is a recipe for disaster
• There are many ”easy wins” for securing web apps, many of which have
been enumerated here
• The scope of unit testing can (and should) be expanded to include security
checks as a standardized practice

33. 33
Additional Resources
• OWASP
• https://www.owasp.org/index.php/Main_Page
• So You Want To Be A Hacker?
• https://www.slideshare.net/ChrisGrayson/so-you-want-to-be-a-hacker
• Web Sight
• https://websight.io
• OWASP Secure SDLC Cheat Sheet
• https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet

34. THANK YOU!
CHRIS@WEBSIGHT.IO
@_LAVALAMP