Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.

Similar presentations


Presentation on theme: "Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP."— Presentation transcript:

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 Secure Coding Fundamentals Richard Lewis Tech Mahindra Ltd 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!


Download ppt "Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP."

Similar presentations


Ads by Google