Your SlideShare is downloading. ×
0
Database Security for PHP Rohan Faye
Contents <ul><li>Introduction
Designing databases
Connecting to database
Encrypted storage model
SQL injection
Avoiding techniques
Conclusion </li></ul>
Introduction <ul><li>Databases: cardinal components of any web based application
Provides varying dynamic content
Stores sensitive or secreat information
PHP cannot protect your database by itself
“Defense in depth” </li></ul>
Designing databases <ul><li>Create the database
Grant the privileges in order to allow other users to use it
Applications should never connect to the database as its  owner  or a  superuser
Stop intruders from gaining access by assigning limited rights to the database objects </li></ul>
Designing databases <ul><li>Avoid implementing all the log in the web application
Use views, triggers or rules </li><ul><li>Transparency
Automatically handle fields
Provides insight when debugging problems
Ability to trace back transactions </li></ul></ul>
Upcoming SlideShare
Loading in...5
×

Database security for PHP

2,435

Published on

A good PHP application is not the one with nice graphics or pictures, but the one with thorough security. This presentation lets you know some facts and fixes as far as some database security threats to a PHP application are concerned.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,435
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
89
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Transcript of "Database security for PHP"

  1. 1. Database Security for PHP Rohan Faye
  2. 2. Contents <ul><li>Introduction
  3. 3. Designing databases
  4. 4. Connecting to database
  5. 5. Encrypted storage model
  6. 6. SQL injection
  7. 7. Avoiding techniques
  8. 8. Conclusion </li></ul>
  9. 9. Introduction <ul><li>Databases: cardinal components of any web based application
  10. 10. Provides varying dynamic content
  11. 11. Stores sensitive or secreat information
  12. 12. PHP cannot protect your database by itself
  13. 13. “Defense in depth” </li></ul>
  14. 14. Designing databases <ul><li>Create the database
  15. 15. Grant the privileges in order to allow other users to use it
  16. 16. Applications should never connect to the database as its owner or a superuser
  17. 17. Stop intruders from gaining access by assigning limited rights to the database objects </li></ul>
  18. 18. Designing databases <ul><li>Avoid implementing all the log in the web application
  19. 19. Use views, triggers or rules </li><ul><li>Transparency
  20. 20. Automatically handle fields
  21. 21. Provides insight when debugging problems
  22. 22. Ability to trace back transactions </li></ul></ul>
  23. 23. Connecting to database <ul><li>Establish connections over SSL to encrypt client/server communications for increased security
  24. 24. Use SSH to encrypt the network connection between clients and the database server
  25. 25. If either of these is used, for a would-be attacker, it will be: </li><ul><li>Difficult to gain information about your database </li></ul></ul>
  26. 26. Encrypted storage model <ul><li>SSL/SSH </li><ul><li>Protects data travelling from client to server
  27. 27. Does not protect persistent data </li></ul><li>If attacker gains access, sensitive data can be misused
  28. 28. Encrypting the data is a good way to mitigate this threat </li></ul>
  29. 29. Encrypted storage model <ul><li>Create your own encryption package to use it from within your PHP script
  30. 30. PHP assists you with several extensions like Mcrypt and Mhash
  31. 31. Script encrypts the data before inserting it into the database, and decrypts it while retrieving
  32. 32. If raw representation of data is not needed, then can rely upon hashing e.g. crypt() and MD5() </li></ul>
  33. 33. Before moving further... <ul><li>Real world examples of some major incidents due to a security flaw... </li></ul>
  34. 34. Incident 1 <ul><li>Date: November 1, 2005
  35. 35. Attacker: A high school student
  36. 36. Victim: Taiwanese Information Security magazine's site </li></ul>
  37. 37. Incident 2 <ul><li>Date: March 29, 2006
  38. 38. Discovered by: Susam Pal (Security expert)
  39. 39. Victim: Official Indian government tourism site </li></ul>
  40. 40. Incident 3 <ul><li>Date: July 19, 2008
  41. 41. Attacker: m0sted and Amen (Turkish hackers)
  42. 42. Victim: Kaspersky's malaysian website </li></ul>
  43. 43. Incident 4 <ul><li>Date: January 20, 2009
  44. 44. Attacker: Albert Gonzalez and two unnamed Russians
  45. 45. Victim: Heartland Payment Systems </li></ul>
  46. 46. Incident 5 <ul><li>Date: October 10, 2009
  47. 47. Attacker: A turkish crew
  48. 48. Victim: Federal Bureau of Investigation job site </li></ul>
  49. 49. Incident 6 <ul><li>Date: December 4, 2009
  50. 50. Attacker: Unknown
  51. 51. Victim: RockYou! </li></ul>
  52. 52. And many more... <ul><li>All of these incidents comprised a common technique of attack... </li></ul>“ SQL ”
  53. 53. SQL injection <ul><li>A SQL query is: </li><ul><li>Not always a trusted command
  54. 54. Can bypass standard authentication and authorization checks
  55. 55. May allow access to host operating system level commands </li></ul></ul>
  56. 56. Direct SQL Command Injection <ul><li>A technique where an attacker can create or alter existing SQL commands to expose hidden data
  57. 57. Can execute dangerous system level commands on the database host
  58. 58. Accomplished by the application taking user input and combinig it with static parameters to bulid a SQL query </li></ul>
  59. 59. Avoiding techniques <ul><li>Never connect to the databse as a superuser or a database owner
  60. 60. Validate the input – PHP has a wide range of input validating functions
  61. 61. Perl compatible Regular Expressions support
  62. 62. Quote each non-numeric user supplied value passed to the databse using database specific string escape function </li></ul>
  63. 63. Avoiding techniques <ul><li>Do not print out any database specific information by fair means or foul
  64. 64. Take benifit from logging queries either within your script or by the database itself, if it supports logging </li><ul><li>Unable to prevent any harmful attempt
  65. 65. Can be helpful to trace back which application has been circumvented </li></ul></ul>
  66. 66. Conclusion “A good PHP application doesn't mean to be good looking. It simply wants to be safe...”
  67. 67. Thank you <?php $references = array( 'The PHP manual', 'Guide to PHP Security', 'Wikipedia', ); ?>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×