Good Secure Development Practices Presented By: Bil Corry lasso.pro Education Project. It recommends validating all user input, distrusting even your own requests, and taking a layered approach to validation, enforcement of business rules, and authentication. Some specific best practices include implementing positive authentication, principle of least privilege, centralized authorization routines, separating admin and user access, and ensuring error handling fails safely.

1. Good Secure Development Practices Presented By: Bil Corry lasso.pro Education Project

2. The Guide Complements OWASP Top 10

3. 310p Book

4. Free and open source Gnu Free Doc License Many contributors

5. Apps and web services

6. Most platforms Examples are J2EE, ASP.NET, and PHP Comprehensive Download from here: http://www.owasp.org/index.php/Category:OWASP_Guide_Project#tab=Download

7. Validating User Input

8. Input Validation Never trust client input!

9. failure to properly validate input leads to almost all of the major vulnerabilities in applications Validate input

10. Encode output GOLDEN RULE OF CLIENT INPUT “ All client input is hostile until proven otherwise or sanitized.”

11. Distrust Even Your Own Requests! CSRF (cross-site request forgery) and Clickjacking are two examples of where malicious requests appear to be initiated by you, from your browser, using your credentials

12. You can not be trusted!

13. Layered approach Integrity Checks When data passes from trusted boundary to untrusted boundary and returned Example: <input type=”hidden”>

14. Example: payment gateway Methods of integrity checking Checksum

15. HMAC

16. Encryption

17. Digital Signature

18. Layered Approach Validation Performed on every tier, presentation layer checks for HTML issues, persistence layer checks for SQLi, etc.

19. Includes sanitization

20. Layered Approach Business Rules Enforce the context

21. Document and test thoroughly

22. Consider the edge cases

23. Examples: E-trade and Schwab, in their signup process, failed to validate a limit of one bank account per any given user, allowing an attacker to assign the same bank account to tens of thousands of users, resulting in a loss of USD $50,000.00.

24. QVC lost more than USD $412,000.00 when a woman discovered she could purchase items via the QVC website, immediate cancel her order, but still receive the items.

25. An attacker posing as a legitimate eBay buyer was able to purchase a computer, remove expensive components from it, then return it as &quot;destroyed&quot; to the seller, successfully bypassing business policy controls for eBay, Paypal and UPS. Examples from: http://projects.webappsec.org/Insufficient-Process-Validation

26. Data Validation Strategies Accept known good (whitelisting) Parameters should be validated against positive specs: Data type (string, integer, real, etc…)

27. Minimum and maximum length

28. Whether null is allowed

29. Whether the parameter is required or not

30. Numeric range

31. Specific patterns (regular expressions) Reject known bad (blacklisting)

32. Sanitize

33. No validation (when you hate your employer)

34. Authentication

35. Authentication User identity / credential Ties system identity to individual Align with application risk Choose authentication controls based on risk Keep out the bad guys Deny access to attackers of the authentication system

36. Best practices User management process! The stronger the requirement for non-repudiation, the more expensive the process. Align credential with asset values Passwords (low-value)

37. SMS

38. Tokens Re-authenticate on privilege boundaries and high-value transactions

39. Passwords are trivially broken! Any password less than 16 characters in length can be brute forced in less than two weeks

40. Usernames & Passwords Let users choose user names Harder to enumerate

41. Avoid the use of Firstname.Lastname, e-mail address, credit card numbers or customer number, or any semi-public data, such as social security number Password policies (strength, change control, storage)