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.

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?
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