Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Getting to ASVS 2 - Balancing practicality with security

Getting to ASVS 2 - Balancing practicality with security

Ever wanted to know what you have to do to ship an application to a bank and pass an audit on the first try? OWASP’s ASVS level 2 guidelines cover a wide range of security requirements that help you get there. We’ll cover what these are, and how they are put into practice for secure PHP development at MCS.

14648400f902ed43fd7a15a4bce33d85?s=128

Joeri Sebrechts

May 08, 2013
Tweet

Other Decks in Technology

Transcript

  1. GETTING TO ASVS 2 BALANCING PRACTICALITY WITH SECURITY Created by

    at Joeri Sebrechts MCS
  2. SECURITY IS A PROCESS Part of the development process

  3. BEGINNING THE PROCESS 2003: MCS starts development of PHP apps

    2008: first warning signals, some corrections 2009: customers tell us an uncomfortable truth After some digging we figure out a few more
  4. UNCOMFORTABLE TRUTH #1 There is no absolute security

  5. MOST SECURE DATA CENTER IN THE WORLD

  6. DESIGN SPEC: ABSOLUTELY SECURE Biochem-filtered air supply Autonomous water supply

    Self-sufficient for 1 month Withstand 30 MT nuclear blasts Engineered for earthquakes EMP-proof “ designed to withstand attack by all foreseeable weapons ”
  7. BUT... Why? Too expensive, didn't scale “ The Cheyenne Mountain

    Realignment moved NORAD/USNORTHCOM operations to Peterson AFB in 2006 from the Cheyenne Mountain nuclear bunker which was placed on warm standby ”
  8. A non-trivial system is either open to attack or too

    expensive to maintain Complex systems must be assumed to be broken
  9. UNCOMFORTABLE TRUTH #2 - Bruce Schneier “ Attacks always get

    better; they never get worse. ”
  10. SQL INJECTION 1998: first mentioned in Phrack 2001: SANS institute

    paper 2002: documented flaw in Guess site 2004: OWASP top ten #6 2007: sqlmap enables automated attack 2008: automated attack hits 500.000 sites 2010: OWASP top ten #1 2013: 30% of web apps vulnerable
  11. PASSWORD CRACKING 1. MD5 2. Rainbow tables 3. Salting, SHA-1

    4. "Deep Crack" FPGA 5. SHA-2 6. GPU-acceleration 7. Bcrypt instead of SHA 8. ... Hashcat
  12. Attacks only get "better" "Secure web development" is a moving

    target
  13. UNCOMFORTABLE TRUTH #3 Everyone is a target

  14. SURELY NOT MY APP? All apps are a target: E-mail

    addresses (1€/1K) Account credentials Privilege escalation Automated scans Spear fishing Watering hole Just for fun
  15. UNCOMFORTABLE TRUTH #4 Everybody gets hacked

  16. LIKE WHO? LinkedIn: 6 million passwords stolen watering hole attack:

    Microsoft, Facebook, Apple and Twitter State-sponsored corporate espionage: , NMBS: 1.5 million customer records leaked But also bakkerseghers.be and 120 other sites (by one guy) iPhoneDevSDK APT1 DeepPanda
  17. RECAP 1. There is no absolute security 2. Attacks only

    get better 3. Everyone is a target 4. Everyone gets hacked So ... what now?
  18. None
  19. AFTER THE PANIC Sure Sure But But No absolute security

    Reasonable security Attacks get better No excuse for not defending Everyone's a target Be better than the other guy Everyone gets hacked Don't make it too easy Figure out a step-by-step plan
  20. STEP 1: STOP HITTING YOURSELF

  21. Our SQL code was in a bad state f u

    n c t i o n g e t M o d u l e D i r ( $ p _ d b , $ p _ s t r M o d u l e C o d e ) { $ s t r M o d u l e D i r = " " ; $ q r y = " S E L E C T \ n " . " M O D U L E _ D I R E C T O R Y \ n " . " F R O M \ n " . " W E B _ M O D U L E S \ n " . " W H E R E \ n " . " M O D U L E _ I D = ( \ n " . " S E L E C T M O D U L E _ I D \ n " . " F R O M M O D U L E S \ n " . " W H E R E M O D U L E _ C O D E = ' " . $ p _ s t r M o d u l e C o d e . " ' \ n " . " ) " ; $ s t a t e m e n t = o c i p a r s e ( $ p _ d b , $ q r y ) ; o c i e x e c u t e ( $ s t a t e m e n t , O C I _ D E F A U L T ) ; i f ( o c i f e t c h i n t o ( $ s t a t e m e n t , $ r e s u l t , O C I _ A S S O C + O C I _ R E T U R N _ N U L L S ) ) $ s t r M o d u l e D i r = $ r e s u l t [ " M O D U L E _ D I R E C T O R Y " ] ; o c i f r e e s t a t e m e n t ( $ s t a t e m e n t ) ; r e t u r n $ s t r M o d u l e D i r ; }
  22. Centralized DB API, based on Zend_Db f u n c

    t i o n g e t M o d u l e D i r ( $ p _ s t r M o d u l e C o d e ) { $ d b = M C S D B : : G e t Z e n d D B C o n n e c t i o n ( ) ; $ q r y = " S E L E C T \ n " . " M O D U L E _ D I R E C T O R Y \ n " . " F R O M \ n " . " W E B _ M O D U L E S \ n " . " W H E R E \ n " . " M O D U L E _ I D = ( \ n " . " S E L E C T M O D U L E _ I D \ n " . " F R O M M O D U L E S \ n " . " W H E R E M O D U L E _ C O D E = : c o d e \ n " . " ) " ; r e t u r n $ d b - > f e t c h O n e ( $ q r y , a r r a y ( " c o d e " = > $ p _ s t r M o d u l e C o d e ) ) ; }
  23. LIB.CORE.PHP File included at the start of every request Session

    management CSRF protections Escaping / encoding / decoding For example, secure HTML entity encoding URL / path functions f u n c t i o n T o H T M L ( $ p _ s t r V a l u e ) { r e t u r n s t r _ r e p l a c e ( " / " , " & # x 2 F ; " , @ h t m l e n t i t i e s ( $ p _ s t r V a l u e , E N T _ Q U O T E S , " U T F - 8 " ) ) ; }
  24. USED UTF-8 THROUGHOUT Character set conversions are an XSS minefield.

    Always send a charset header i n i _ s e t ( " d e f a u l t _ c h a r s e t " , " U T F - 8 " ) ; Used mbstring functions everywhere m b s t r i n g . f u n c _ o v e r l o a d = 7 Standardized web services (JSON-RPC) Zend_Db: charset => "AL32UTF8" Moved to JS-based UI (single page app)
  25. BARE MINIMUM: OWASP TOP TEN The absolute minimum level of

    security in web development: Understand the issues and how to detect / avoid them. Use development practices that reduce risk: Parameterized queries (or ORM) Use a framework with proper session handling CSRF defenses on every request Always work in UTF-8 Read the , adapt code to match Always use HTTPS Audit existing code (as time permits) OWASP top ten XSS cheat sheet
  26. STEP 2: ADAPT THE QA PROCESS

  27. MCS SECURITY ASSURANCE PROCESS Design reviews with eye on security

    Manual code reviews of all commits (for security) Issues are tracked and solved as bug reports. Standardized reporting Automated code scans at build time (custom tooling)
  28. STEP 3: ASVS 1 Establishing a baseline level of security

  29. OWASP APPLICATION SECURITY VERIFICATION STANDARD Checklist to benchmark the state

    of a codebase, organized into levels (each level adds requirements). Level 1: automated verification Protect against automated attacks Level 2: manual verification Protect against amateur attackers Level 3: design verification Protect against expert attackers Level 4: internal verification Protect human lives
  30. ASVS LEVEL 1 Document libraries and components Check for proper

    authentication at page level Basic session hijacking defenses Editing URL's cannot bypass security Sanitize your inputs Context-appropriate encoding (HTML, CSS, ...) Don't log DB passwords in error messages Disable autocomplete in sensitive fields Specify content type headers ...
  31. ASVS 1 EXAMPLE Chapter 5: input validation

  32. EXAMPLE: POSITIVE INPUT VALIDATION Initial solution: validation library, developers told

    to use it Problem: “V5.2: Verify that a positive validation pattern is defined and applied to all input.” p u b l i c s t a t i c f u n c t i o n n e w T r a n s a c t i o n D o c u m e n t ( $ p _ s t r T r a n s a c t i o n T y p e , $ p _ a r r D e f a u l t s = N U L L ) { / / T O D O : A d d i n p u t v a l i d a t i o n . . . }
  33. SECOND SOLUTION: UNIFIED SERVICES Type and validation rules specified in

    annotations Service layer does type casting and validation Service throws error for invalid type annotations Auto-generated SOAP WSDL Accurate web service documentation "for free" / * * * R e t u r n a t e m p l a t e f o r a n e w t r a n s a c t i o n d o c u m e n t * * @ p a r a m s t r i n g $ t r a n s a c t i o n T y p e * @ I n A r r a y [ " G o o d s I s s u e " , " G o o d s R e c e i p t " , . . . ] * * @ p a r a m D T O _ S t o c k _ T r a n s a c t i o n D o c u m e n t D e f a u l t $ d e f a u l t s * * @ r e t u r n D T O _ S t o c k _ T r a n s a c t i o n D o c u m e n t * / p u b l i c f u n c t i o n n e w T r a n s a c t i o n D o c u m e n t ( $ t r a n s a c t i o n T y p e , $ d e f a u l t s = N U L L ) { . . . }
  34. DEMO Run r p c ( ' p i n

    g ' , ' p i n g O b j e c t ' , [ { k e y : 1 0 } ] , f u n c t i o n ( r e s p o n s e ) { l o g ( r e s p o n s e ) ; } ) ; / * * * @ p a r a m D T O _ P i n g O b j e c t $ m i r r o r * @ r e t u r n D T O _ P i n g O b j e c t * / f u n c t i o n p i n g O b j e c t ( D T O _ P i n g O b j e c t $ m i r r o r = N U L L ) { r e t u r n $ m i r r o r ; } c l a s s D T O _ P i n g O b j e c t e x t e n d s M C S _ D a t a T r a n s f e r O b j e c t { / * * * @ v a r i n t P o s i t i v e i n t e g e r * @ M i n 0 * / p u b l i c $ k e y = 1 ; }
  35. STEP 4: ASVS 2 Achieving "reasonable security" at the enterprise

    level
  36. All of ASVS 1 requirements High-level architecture must be documented

    Strong authentication controls Strong session hijacking defenses Comprehensive server-side access control Verify character set behavior All injection-sensitive code must be audited Proper cryptographic algorithms Comprehensive logging of security events Secure handling of cached data SSL used for all communication ...
  37. DEFENSE IN DEPTH

  38. ON-GOING CHALLENGES Not slacking off on security reviews Strong authentication

    Password strength rules Correct password hashing algorithm Two-factor auth Many clients interacting with DB Logging - too much vs. too little Changing automated tools to match practices Feature requests vs secure architecture Beyond the web code (windows codebase, hosting environment, ...)
  39. USEFUL LINKS OWASP , , , , It's difficult to

    navigate, but it's all there (wiki) Best book on web security (RSS) Insider's view of OWASP community. Weekly recap of relevant security stories. Example implementation of annotated type validation. top ten quick ref cheat sheets ASVS ESAPI Browser Security Handbook The Tangled Web OWASP AppSec Feed Security Now podcast github.com/jsebrech/php-o
  40. QUESTIONS? Thank you for listening! js@mcs.fm joind.in/8570