GETTING TO ASVS 2 BALANCING PRACTICALITY WITH SECURITY Created by at Joeri Sebrechts MCS 

SECURITY IS A PROCESS Part of the development process 

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 

UNCOMFORTABLE TRUTH #1 There is no absolute security 

MOST SECURE DATA CENTER IN THE WORLD 

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 ” 

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 ” 

A non-trivial system is either open to attack or too expensive to maintain Complex systems must be assumed to be broken 

UNCOMFORTABLE TRUTH #2 - Bruce Schneier “ Attacks always get better; they never get worse. ” 

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 

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 

Attacks only get "better" "Secure web development" is a moving target 

UNCOMFORTABLE TRUTH #3 Everyone is a target 

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 

UNCOMFORTABLE TRUTH #4 Everybody gets hacked 

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 

RECAP 1. There is no absolute security 2. Attacks only get better 3. Everyone is a target 4. Everyone gets hacked So ... what now? 

No content

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 

STEP 1: STOP HITTING YOURSELF 

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 ; } 

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 ) ) ; } 

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 " ) ) ; } 

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) 

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 

STEP 2: ADAPT THE QA PROCESS 

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) 

STEP 3: ASVS 1 Establishing a baseline level of security 

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 

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

ASVS 1 EXAMPLE Chapter 5: input validation 

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 . . . } 

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 ) { . . . } 

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 ; } 

STEP 4: ASVS 2 Achieving "reasonable security" at the enterprise level 

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

DEFENSE IN DEPTH 

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, ...) 

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 

QUESTIONS? Thank you for listening! [email protected] joind.in/8570