Php security common 2011

2,105 views

Published on

My PHP Security talk from the COMMON conference 2011

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,105
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
56
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Php security common 2011

  1. 1. PHP and Web-Based Security<br />Kevin Schroeder<br />Zend Technologies<br />
  2. 2. About Kevin<br /> Past: Programming/Sys Admin<br /> Current: Technology Evangelist/Author/Composer<br /> @kpschrade<br />
  3. 3. Obligatory Plug<br />Mike will be talking about<br />OOP tomorrow at 8:00<br />Room 101A<br />
  4. 4. The key themes for this year’s ZendCon are:<br />Cloud Computing<br />Mobile and User Experience<br />Enterprise and Professional PHP<br />
  5. 5. Disclaimer<br />Do not use anything you learn here for nefarious purposes<br />But if you do, I want to hear about it <br />
  6. 6. Why be concerned about security?<br /><ul><li>Your job/reputation depends on it
  7. 7. You may provide access to your own private data
  8. 8. You may provide access to others private data
  9. 9. You may allow someone to impersonate another (identity theft)
  10. 10. You may take the blame for another person’s attack (remote code injection)
  11. 11. You may be prone to service attacks</li></li></ul><li>Why’s the web so dangerous?<br /><ul><li>It’s open
  12. 12. Lots of bad code out there
  13. 13. There are lots of bad people out there
  14. 14. Many servers set up by inexperienced sys admins
  15. 15. Or someone simply forgot to filter a variable
  16. 16. Many people think they are immune/not a target
  17. 17. Security not taken seriously
  18. 18. Insufficient time or resources to take security into consideration
  19. 19. Stored information not considered important enough to secure</li></li></ul><li>What are the rules?<br /><ul><li>Always use multiple methods of security
  20. 20. Validating a login is not enough
  21. 21. The principle of least privileges
  22. 22. Initialize all variables
  23. 23. Cast variables when appropriate
  24. 24. Don’t store sensitive data in the web tree
  25. 25. Filter all data
  26. 26. Don’t rely on hidden form variables.</li></li></ul><li>What are the rules?<br /><ul><li>And last, but not least. No matter how much they cry. No matter how much they beg…</li></ul>Never, ever, trust your users.<br />
  27. 27. What are the rules?<br />Validate Input<br />Filter Output<br />
  28. 28. Basic types of attacks<br /><ul><li>SQL Injection
  29. 29. Cross Site Scripting (XSS)
  30. 30. Cross Site Request Forgery (XSRF)
  31. 31. File Inclusion
  32. 32. Information Dissemination
  33. 33. Command Injection
  34. 34. Remote Code Injection
  35. 35. Session Hijacking
  36. 36. Session Fixation
  37. 37. Cookie Forging</li></li></ul><li>SQL Injection<br />Injects arbitrary code into SQL statements<br />
  38. 38. SQL Injection<br />Injects arbitrary code into SQL statements<br />
  39. 39. SQL Injection<br /><ul><li>Cast to (int) whenever possible
  40. 40. Use prepared statements if possible
  41. 41. If prepared statements are not available escape everything using database-specific escaping functions
  42. 42. Validate data (ctype_*, preg_*, Zend_Filter_*)
  43. 43. Only give your database user the permissions it needs.</li></li></ul><li>Cross Site Scripting (XSS)<br />Makes your browser execute code from a trusted site<br />
  44. 44. Cross Site Scripting (XSS) – Non Persistent<br />Exploits user’s trust in the site<br />Bad guy identifies a vulnerable website and sends you a link with the <br /> vulnerability in the URL<br />You click on that link<br />Your browser executes bad guy’s code<br />
  45. 45. Cross Site Scripting (XSS) - Persistent<br />Exploits user’s trust in the site<br />Bad guy posts code on a website<br />You request the page on the website<br />Your browser executes bad guy’s code<br />
  46. 46. Cross Site Scripting (XSS)<br /><ul><li>Always escape user data (htmlentities, htmlspecialchars, strip_tags)
  47. 47. Use Zend_Form for handling forms
  48. 48. Employ a whitelist for places where HTML input is required (!)
  49. 49. Use ctype_digit and ctype_alnum for simple fields like names or phone numbers
  50. 50. Don’t limit validation to Javascript</li></li></ul><li>Cross Site Request Forgery (XSRF)<br />Exploits the site’s trust in the user<br />You log on to a vulnerable web site and establish trust<br />You visit a bad web site<br />Bad website tells your browser to submit a page to<br /> vulnerable web site<br />
  51. 51. Cross Site Request Forgery (XSRF)<br /><ul><li>Use a site that relies on a user’s identity
  52. 52. Exploit the website’s trust in that user
  53. 53. Trick the user’s browser into sending HTTP requests
  54. 54. Cause the user’s browser to execute an action or retrieve data on your behalf on that site</li></li></ul><li>Cross Site Request Forgery (XSRF)<br /><ul><li>Use tokens that expire during sensitive operations
  55. 55. Use Zend_Form and Zend_Form_Element_Hash
  56. 56. Force session timeouts</li></li></ul><li>File Inclusion<br />Includes files in the request that were not intended<br />
  57. 57. File Inclusion<br /><ul><li>Google – inurl:page=home.php
  58. 58. Don’t use dynamically included files
  59. 59. If you must dynamically include files, validate them</li></li></ul><li>Information Dissemination<br />Giving the user more information than they should ever have<br />
  60. 60. Information Dissemination<br /><ul><li>Turn off display_errors
  61. 61. Don’t have a public phpinfo page (Google search – inurl:phpinfo.php)</li></li></ul><li>Command Injection<br />Used to execute arbitrary programs or inject arbitrary data on your server<br />
  62. 62. Command Injection<br /><ul><li>Don’t use exec, system, popen, shell_exec, etc. in your program
  63. 63. If you need to use those functions use hard coded values. Do not trust a variable or anything defined in another file
  64. 64. If you need to have user input always use escapeshellargs and escapeshellcmd</li></li></ul><li>Remote Code Injection<br />Runs an attacker’s PHP code on your system<br />
  65. 65. Remote Code Injection<br /><ul><li>Never use unchecked/unfiltered data in require|include(|_once)
  66. 66. Set allow_url_include to false
  67. 67. If you must make remote requests always filter any user provided data
  68. 68. Use eval() judiciously</li></li></ul><li>Session Hijacking<br />An attacker takes over control of a user session<br /><ul><li>Often used in conjunction with XSS
  69. 69. Attacker retrieves a user’s session ID and uses it as their own
  70. 70. Can be used in conjunction with document.cookie</li></li></ul><li>Session Hijacking<br /><ul><li>Use htmlentities, htmlspecialchars or strip_tags to disable JavaScript or image-based attacks
  71. 71. Use session_regenerate_id(true)
  72. 72. Validate a session against an IP address
  73. 73. Note that this should be used to generate an alert, not restrict a user’s access</li></li></ul><li>Session Fixation<br />Sets a user session ID to the same as an attacker’s session ID<br />
  74. 74. Session Fixation<br /><ul><li>Difficult to guard against
  75. 75. Use session_regenerate_id(true)
  76. 76. before logging in
  77. 77. periodically in a user’s session
  78. 78. if the domain in the HTTP_REFERER doesn’t match the current domain
  79. 79. None of these are foolproof, but they limit the ability of an attacker to fixate a session
  80. 80. Disable the use of the session ID in the URL
  81. 81. Still able to change the session ID using JavaScript, though</li></li></ul><li>Cookie Forging<br />Forging cookie data used to determine permissions or access<br />
  82. 82. Cookie Forging<br /><ul><li>Don’t use cookies to determine access/authentication
  83. 83. Use the session handler
  84. 84. If you must use cookies, encrypt contents with a server-side key</li></li></ul><li>Miscellaneous good ideas<br /><ul><li>Turn display_errors off
  85. 85. Do not use register_globals
  86. 86. Keep as much code and data out of the public code tree (htdocs/wwwroot) as possible
  87. 87. Use a whitelist approach when dealing with HTML
  88. 88. Don’t have predictable resource locations
  89. 89. i.e http://mysite/phpinfo.php</li></li></ul><li>What about buffer overflows and such<br /><ul><li>Very few of those weaknesses occur in PHP
  90. 90. When they do they are usually in extension interfaces or the extensions themselves, not PHP
  91. 91. Disable all unused streams, extensions, filters, etc.</li></li></ul><li>Follow us!<br />Zend Technologies<br />http://twitter.com/zend<br />http://twitter.com/kpschrade (me!)<br />
  92. 92. Get more information and examples at eschrade.com…<br />

×