Downloaded 125 times
Uploaded byChris Tankersley
PHP Security Tips
This document summarizes a presentation on PHP security given to the NWO-PUG group. The presentation covers the most common web application attacks like injection, cross-site scripting, insecure authentication, and how to prevent them following secure coding principles. It discusses the OWASP Top 10 security risks and how to avoid each one through input validation, output encoding, authorization checking, secure session handling and encryption. The presentation emphasizes defense in depth and that attackers may combine different vulnerabilities.
PHP Security Tips
- 1. PHP SecurityE-mail: chris@ctankersley.comTwitter:@dragonmantankIdenti.ca: dragonmantankSeptember 20, 2011NWO-PUG 1
- 2. Who are youand why are you in my house?Chris TankersleyDoing PHP for 8 YearsLots of projects no one uses, and a few that some doTL;DR https://github.com/dragonmantankNWO-PUG 2September 20, 2011
- 3. The Parts ofSecurityIt’s more than just a username/passwordNWO-PUG 3September 20, 2011
- 4. What is SecureProgramming?Minimizing Attack SurfaceEstablishing Secure DefaultsPrinciple of Least PrivilegeDefense in DepthFail SecurelyDon’t Trust Services or UsersSeparation of DutiesAvoid Security through ObscurityKeep Security SimpleFix Security Issues CorrectlySeptember 20, 2011NWO-PUG 4https://www.owasp.org/index.php/Secure_Coding_Principles
- 5. Most Common AttacksAndhow to avoid themNWO-PUG 5September 20, 2011
- 6. OWASP Top 10InjectionCross-SiteScriptingBroken Authentication and Session ManagementInsecure Direct Object ReferencesCross-Site Request ForgerySecurity MisconfigurationInsecure Cryptographic StorageFailure To Restrict URL AccessInsufficient Transport Layer ProtectionUnvalidated Redirects and ForwardsNWO-PUG 6https://www.owasp.org/index.php/Category:OWASP_Top_Ten_ProjectSeptember 20, 2011
- 7.
- 8. What is Injection?Whena user or service corrupts a command due to improper validation of inputSeptember 20, 2011NWO-PUG 8
- 9. Many Shapes andSizesSQL InjectionCommand InjectionHTML InjectionSeptember 20, 2011NWO-PUG 9
- 10. Protecting against InjectionsAttacksFilter user inputEscape anything not hard-codedIgnore $_REQUESTNWO-PUG 10September 20, 2011
- 11. SQL InjectionNWO-PUG 11September20, 2011
- 12. A Bit MoreReal LifeNWO-PUG 12September 20, 2011
- 13. Protecting against SQLInjectionUse PDO and prepared statementsNWO-PUG 13September 20, 2011
- 14. Command InjectionWhen yourscript calls an external program, users can run codeNWO-PUG 14September 20, 2011
- 15. Protecting against CommandInjectionIf allowing the user to specify commands, use escapeshellcmd()If allowing the user to specify arguments, use escapeshellarg()NWO-PUG 15September 20, 2011
- 16. HTML/Script InjectionHTML Injection:When user input is used to create new markup that the application did not expectScript Injection: When user input is used to add new scripting to a pageNWO-PUG 16September 20, 2011
- 17.
- 18. Protecting against HTML/ScriptInjectionDecide if you really need to take HTML inputIf you do:Use an HTML cleaner like Tidy or htmLawedCreate a whitelist of allowed tagsIf you don’t:Use htmlentities()/htmlspecialchars()NWO-PUG 18September 20, 2011
- 19. Cross Site ScriptingOrXSSNWO-PUG 19September 20, 2011
- 20. What is it?Whena user injects a script into a page or extra JS into a command to send information to another siteSeptember 20, 2011NWO-PUG 20
- 21. How to avoidXSS?Since this is an injection attack, use the same steps as a HTML/Script injectionNWO-PUG 21September 20, 2011
- 22. Broken Authentication andSession ManagementNWO-PUG 22September 20, 2011
- 23. What is it?Insecurestoring of credentialsSession IDs exposed via URLSession fixation attacksSeptember 20, 2011NWO-PUG 23
- 24. Storing CredentialsHash witha salt using the hash() commandDo not use md5 or sha1, use at least sha256md5 and sha1 are broken and not recommended for secure hashingIf you have to use the raw data, encrypt using mcrypt() Use AES256 (RIJNDAEL 256)NWO-PUG 24September 20, 2011
- 25. Session IDs inURLCommonly used when cookies can’t be enabledMake sure the following is set in your php.ini:session.use_trans_id = 0session.use_only_cookies = 1NWO-PUG 25September 20, 2011
- 26. Session FixationWhat happensif your users don’t log out?Use sessions to detect login statusNWO-PUG 26September 20, 2011
- 27. Insecure Direct ObjectReferencesNWO-PUG 27September 20, 2011
- 28. What is it?Makingsure that what the user is accessing they have access to.Should be handled by checking authorization when accessed, or mappingThis is not an injection attack, but a logic attackSeptember 20, 2011NWO-PUG 28
- 29. An ExampleNWO-PUG 29September20, 2011
- 30. How to AvoidAlwayscheck to make sure the user has authorization to access the resourceMap variables/whitelist to make it harderNWO-PUG 30September 20, 2011
- 31. Cross Site RequestForgeryOr CSRF AttacksNWO-PUG 31September 20, 2011
- 32. What is it?Whenunauthorized commands are sent to and from a trusted websiteIn days gone by, this would be done with Referral checking, but don’t trust referrer informationSeptember 20, 2011NWO-PUG 32
- 33. An example –Bank TransferA bank transfer is done via $_GET variablesUser is authenticated but not logged outNWO-PUG 33September 20, 2011
- 34. How to avoidthisInclude a hidden element in the form with a one-time valueNWO-PUG 34September 20, 2011
- 35.
- 36. Beyond the scopeof programmingCheck for server hardening guidelines for your OSPassword rotation practicesUnderstanding your settingsKeep your stack up to date!September 20, 2011NWO-PUG 36
- 37. Insecure Cryptographic StorageNWO-PUG37September 20, 2011
- 38. More of alogic problemEncrypting data in the database, but leaving it unencrypted during outputUsing unsalted hashesSeptember 20, 2011NWO-PUG 38
- 39. How to avoidthisLike when storing credentials, use a salt whenever hashing informationOnly decrypt data when it is neededNWO-PUG 39September 20, 2011
- 40. Failure to RestrictURL AccessNWO-PUG 40September 20, 2011
- 41. What is it?Whenusers can gain access to parts of the application just through URL manipulationWhen the app doesn’t check authorization properlySeptember 20, 2011NWO-PUG 41
- 42. Security through ObscurityDon’ttrust that just because a user doesn’t know a URL, they can’t get to itFuzzers can find all kinds of things, especially if the app is commonNWO-PUG 42September 20, 2011
- 43. How to avoidthisALWAYS check authorization. The extra CPU cycles are worth it.NWO-PUG 43September 20, 2011
- 44. Insufficient Transport LayerProtectionNWO-PUG 44September 20, 2011
- 45. Not using SSLwhen you shouldIf your data is sensitive, use SSLAre your logins behind SSL?There isn’t really an excuse. You can get an SSL cert for $9/year. September 20, 2011NWO-PUG 45
- 46. Unvalidated Redirects andForwardsNWO-PUG 46September 20, 2011
- 47. What is it?Whenan app doesn’t properly validate that the redirect destination is validSeptember 20, 2011NWO-PUG 47
- 48. Putting it TogetherNWO-PUG48September 20, 2011
- 49. Attacking from MultipleFrontsAttackers will employ many different vectors in an attackHTML injection can take advantage of a Broken Auth system and use XSS or URL restrictions to force users to do unintended actionsScript injection can lead to Session hijacking September 20, 2011NWO-PUG 49
- 50. Remember…Minimizing Attack SurfaceEstablishingSecure DefaultsPrinciple of Least PrivilegeDefense in DepthFail SecurelyDon’t Trust Services or UsersSeparation of DutiesAvoid Security through ObscurityKeep Security SimpleFix Security Issues CorrectlySeptember 20, 2011NWO-PUG 50https://www.owasp.org/index.php/Secure_Coding_Principles
- 51.