Digital Armour: Adding Security to Software Development

1. Digital Armour: Adding Security to Software Development Terry Labach IST Information Security Services

2. "Amateurs produce amateur security, which costs more in dollars, time, liberty, and dignity while giving us less -- or even no -- security." - Bruce Schneier

3. Introduction • Secure Application Development • what is it? • why should you care? • rules of thumb • Examples • Questions

4. Goals of Secure Application Development • first, that the actual development process is secure: it aims to prevent unsafe code from being created, inserted, misused, or deployed • second, that the application created is secure: it does not expose user data or allow unauthorized access to computer systems

5. Features of Secure Application Development • combines fundamental good development practices with security knowledge • principles applicable across development methodologies, technologies, languages, platforms

6. Why care about secure development? We have duties outlined by the University and the government • Policy 8 • Information Security Policy for University of Waterloo • FIPPA • Freedom of Information and Protection of Privacy Act

7. Why care about secure development? • professional responsibility • Our code should work as intended • Robust enough to deal with unforeseen situations

8. Why isn’t secure development practised? • developers don’t realize importance • not sure what is required • no training • no mentorship • “shoot from the hip” approach to coding • experienced coders and co-ops alike • no mandate from management

9. What causes security flaws in applications? • Development • coding errors • process errors • incomplete testing • failure to account for known threats • failure to build robustness to account for unknown threats

10. What causes security flaws in applications? • Deployment • process errors • configuration errors

11. What are typical security flaws? • Many enumerations of flaws • Researchers at Fortify have suggested a taxonomy of software security errors.

12. Taxonomy 1-4 • Input Validation and Representation • API Abuse • Security Features • Time and State

13. Taxonomy 5-8 • Errors • Code Quality • Encapsulation • Environment

14. Secure Development Process • No magic bullet to prevent security flaws… "The 'code' which he suggests is however very contrary to the line of development here, and much more in the American tradition of solving one's difficulties by means of much equipment rather than by thought." - Alan Turing, criticizing a proposed computer design.

15. Secure Development Process • …but following simple rules of thumb can be quite effective at preventing errors, including security errors.

16. Development basics • maintain separate environments for • development • testing • production • repositories

17. Development basics • review code • test code

18. Testing “The system's security must, of course, be tested for invulnerability from frontal attack - but must also be tested for invulnerability from flank or rear attack.” - Boris Beizer

19. Testing • automatic testing • unit testing • regression testing • edge cases (boundaries) • fuzz testing • vulnerability testing (IST)

20. Coding basics • validate input • validate output • validate on server, not client • permission, not exclusion • limit error messages to client • check return values • handle anomalous behaviour (exceptions)

21. Design basics • protect data • in transit (network, http, email) • in place (files, database) • limit user access • passwords • CAS • layer defenses

22. Infrastructure basics • use APIs and libraries rather than rolling your own • know your software and deployment environments

23. Examples • code and configuration snippets • demonstrate techniques to improve security • although using particular languages, most techniques are applicable to many different languages

24. Examples: .NET and SQL • programs often create SQL queries by concatenating text, including user input string query = "SELECT * FROM items WHERE itemname = '“ + ItemName.Text + "'"; • a user may be able to craft an entry that includes SQL code and allows access to the database

25. Examples: .NET and SQL • for input "name' OR 'a'='a“, the generated SQL is SELECT * FROM items WHERE itemname = 'name' OR 'a'='a'; • this has the result of returning the entire items table

26. Examples: .NET and SQL • to avoid this, use a parameter to the SQL statement using (SqlConnectionconn = new SqlConnection(connString)) { string query = "SELECT * FROM items WHERE itemname = @Iname"; SqlCommandcmd = new SqlCommand(query, conn); cmd.Parameters.AddWithValue("@Iname", Request.QueryString["Iname"]); conn.Open(); ... }

27. Examples: java • random number generation • Random • sequence determined by initial seed • SecureRandom • cryptographically strong random number generator

28. Examples: java SecureRandom random = new SecureRandom(); byte bytes[] = new byte[20]; random.nextBytes(bytes); • don’t bypass internal seeding with non-random value (e.g. time) • occasionally create new instance

29. Examples: php • securing cookies used for session management • session.cookie_lifetime • lifetime of the cookie in seconds • session.cookie_secure • should cookies be sent over secure connections • session.cookie_httponly • limit to the HTTP protocol

30. Examples: php • set configuration in php.ini session.cookie_lifetime = 7200 session.cookie_secure = 1 session.cookie_httponly = 1

31. Examples: php • php can read HTTP GET values using the $_GET variable • could allow malicious input • removing dangerous input not trivial

32. Examples: php • filter_input (from php 5.2) • provides many filtering types • to apply filter to $_GET[‘my_string’] <?php $my_string = filter_input(INPUT_GET, ‘my_string’, FILTER_SANITIZE_STRING); ?>

33. Examples: HTTP • GET and POST used to transfer user requests • GET • query passed as part of URL • can be cached, stored in browser history • GET should not be used to transmit sensitive data

34. Examples: HTTP • POST • data passed in body of the HTTP request • encrypted when using SSL connections

35. Examples: ruby • filename validation with regular expression • /^[\w\.\-\+]+$/ • Meant to allow only alphanumeric, ., +, -. • ^ and $ match the beginning and end of line

36. Examples: ruby • flaw • However, the above will allow the filenamefile.txt%0A<script>alert('hello')</script> • $ matches at %0A (URL-encoded line break) • Should use \A and \z to match entire string • /\A[\w\.\-\+]+\z

37. Conclusions “Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail.” - Bruce Schneier

38. Conclusions • secure software development is not necessarily an onerous thing • it does require awareness and discipline • common sense development practices and a concern with correct operation of the program will prevent many security problems

39. Resources • HP Fortify Taxonomy: Software Security Errors • Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors • CSIS: 20 Critical Security Controls Version 4.0

40. Resources • OWASP Top Ten Project • OWASP Prevention Cheat Sheet Series • 2011 CWE/SANS Top 25 Most Dangerous Software Errors • IST Information Security Services

41. Questions? • Terry Labach