Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Started In Security Now I'm Here

704 visualizaciones

Publicado el

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

Publicado en: Internet
  • Inicia sesión para ver los comentarios

  • Sé el primero en recomendar esto

Started In Security Now I'm Here

  1. 1. Started In Security Now I’m Here Christopher Grayson (OSCE) Tales from a hacker-turned-code-monkey
  3. 3. 3 WHOAMI
  4. 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. 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. 6 Agenda 1. My Background 2. Core Security Concepts 3. Lessons Learned 4. Security Regression 5. Conclusion
  8. 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. 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. 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
  12. 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. 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. 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. 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. 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. 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
  19. 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. 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. 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. 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. 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. 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. 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. 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
  28. 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. 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. 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. 31. CONCLUSION
  32. 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. 33 Additional Resources • OWASP • • So You Want To Be A Hacker? • • Web Sight • • OWASP Secure SDLC Cheat Sheet •