1. Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP http://www.owasp.org Secure Coding Fundamentals Richard Lewis Tech Mahindra Ltd. richardl@techmahindra.com 91-022-55532000 June 24th 2006

2. OWASP 2 Session Contents  Secure Code Characteristics  Costs of Insecure Coding  Threats to Code  Secure Coding – General Principles  Secure Coding – C and C++  Secure Coding – ASP.NET  Secure Coding – Java  Summary

3. OWASP 3 Defining Secure Coding  Secure code must have the following properties SECURESECURE eamless ognizant of attacks asy to Understand nobtrusive esilient rror Tolerant

4. OWASP 4 Genesis of a Secure Application Slide taken from Security Engineering for Software, Dimitry Averin “Secure” Application Robust Programming Practices Good design and coding practices Design and implementation of security features. From the Requirements

5. OWASP 5 Cost of Insecure Code  Spot the difference WCHAR wcsAttribute[200]; if ( cchAttribute >= sizeof wcsAttribute) THROW( CException( DB_E_ERRORSINCOMMAND ) ); DecodeURLEscapes( (BYTE *) pszAttribute, cchAttribute, wcsAttribute,web- Server.CodePage()); WCHAR wcsAttribute[200]; if ( cchAttribute >= sizeof wcsAttribute THROW( CException( DB_E_ERRORSINCOMMAND ) ); DecodeURLEscapes( (BYTE *) pszAttribute, cchAttribute, wcsAttribute,web- Server.CodePage()); / sizeof WCHAR) Damages: Network costs = $1.2 billion Affected 360,000 servers Productivity cost = $750 million

6. OWASP 6 Threats to Code  We, the programmers  Bad Inputs (and Outputs)  API Abuse  Environment and Configuration  Time and State

7. OWASP 7 Secure Coding – General Principles  Validate inputs and outputs FLTR principle – Format, Length, Type, Range  Reduce attack surface Running Code Entry Points (UI, ports, files, database, API calls) Reduce Privilege  Operate at least privilege Open files/registry with required access rights Don’t write data in protected portions of the Operating System  Apply Defense-in-depth Use gatekeeper paradigm  Use APIs correctly String functions in C, Java,.NET  Detect attacks and fail securely Phishing attacks  Observe vendor’s recommendations

8. OWASP 8 Secure Coding – C and C++  Ensure that input is bounded – Prevents buffer overflow attacks char buf [64], memcpy(buf, user input, sizeof(user input));  Use variadic functions properly – Prevents format string attacks. printf(string) printf(“%s”,string)  Check for integer overflow  Ensure proper memory management  Free data allocated on the heap/free store  Avoid double free. Zero the pointer after the first free.  Don’t mix new, delete with calloc,free  Don’t store secrets in memory allocated with realloc  Don’t forget the [ ] operator when deleting arrays

9. OWASP 9 Secure Coding – ASP.NET  Don’t hard-code passwords in code or in Web.config / Machine.config Use aspnet_setreg.exe to store encrypted credentials in the registry.  Validate input automatically Use validateRequest=true.  Dynamic SQL Creation "SELECT * FROM items WHERE owner = '" + userName + "' AND itemname = '" + ItemName.Text + "'"; What if "name' OR 'a'='a" is passed for itemname? SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a'; This maps to: SELECT * FROM items;  Strong-name assemblies Use strong name as evidence for running assemblies  Implement custom-error pages Make changes to the customErrors element in the Web.config. Configure to show detailed messages to local users only.  Protect the ViewState Difference between using ViewStateEncryptionMode and SSL  Set the HttpOnly option for cookies Prevents cookie-stealing scripts from reading the cookie

10. OWASP 10 Secure Coding – Java  Avoid using inner classes Compiler translates the class and private variables to package scope access. Make private if required.  Don’t compare classes by name. Use class equality instead. Malicious code could be running with the same name  “Turn off” cloning by implementing clone() and making it final Attacker could instantiate your class without a constructor.  “Turn off” serialisation by implementing writeObject() it and making it final Attacker could instantiate your class without a constructor.  Seal your Java packages Prevents attackers from adding a class to the package  Don’t return references to mutable objects Prevents attackers from changing the internal state of the object.

11. OWASP 11 Thank you!