Difference between revisions of "Talk:PHP Security Cheat Sheet"

From OWASP
Jump to: navigation, search
(added link to my page)
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
=== NOTOC ===
 
=== NOTOC ===
  
<nowiki>__NOTOC__</nowiki>
+
I want to keep the TOC in so this is standard like other cheat sheets in this series (Jim Nov 25 2012)
 
+
I'd suggest to remove the TOC when this sheet is close to be finished.
+
[[User:Achim|Achim]], 3-jul-2012
+
  
 
=== TBD ===
 
=== TBD ===
Line 16: Line 13:
 
I've seen infinite developers set it to off, then set it to On for debugging, and leave it there.
 
I've seen infinite developers set it to off, then set it to On for debugging, and leave it there.
  
Why the hell is file_uploads off? Are you one of those guys who believe everything should be off to provide a secure system? Also disabling functions and etc. its a very bad practice. This is only used in dull shared web hosting systems, and nobody gets their hosts.
+
: OWASP makes suggestions for security not for compfy debugging. Security is the goal.
 +
: Hence '''Off''' is the choice for produktive systems. --[[User:Achim|Achim]], 5-jul-2012
 +
 
 +
:: I don't know if you've experienced it or not, but this is exactly the difference between an open community and a commercial rigid ISO workgroup. We provide solutions that people actually use, not solutions that are perfect if we lived on the moon. This error handling issue is very important. Also the startup error should be on, otherwise users only think the site is dead. There shuold be a critical error level, delivered to the admin via SMS or Email, so that these errors are handled properly.
 +
 
 +
Why the hell is file_uploads off? Are you one of those guys who believe everything should be off to provide a secure system?
 +
 
 +
: Yes (but there is a hint that some settings need to be adapted to real systems:) --[[User:Achim|Achim]], 5-jul-2012
 +
 
 +
:: Could you elaborate the security risks with file_uploads?
 +
 
 +
 
 +
Also disabling functions and etc. its a very bad practice. This is only used in dull shared web hosting systems, and nobody gets their hosts.
 +
 
 +
: Either we try to make a crappy PHP secure, or you have to live with brain-dead develpers using something like <code>system($_REQUEST['killme'])</code>
 +
: --[[User:Achim|Achim]], 5-jul-2012
 +
 
 +
:: Develoeprs should be aware of dangerous functions. Some IDE's deliver warnings when variables are used in dangerous functions, we could create a tool that would scan the code and tell so. This is the same scenario as the first issue.
  
 
Most usage of PHP is available source code (Wordpress, Joomla, MyBB, etc.) and they all use these abilities. What you're indicating just says "dont follow this cheat sheet", no offence!
 
Most usage of PHP is available source code (Wordpress, Joomla, MyBB, etc.) and they all use these abilities. What you're indicating just says "dont follow this cheat sheet", no offence!
 +
 +
: the cheat sheet is about security, not about using insecure frameworks. --[[User:Achim|Achim]], 5-jul-2012
 +
 +
:: 15% of websites are powered with Wordpress, and they are among the most secure of all :)) Do you expect every admin to pay a few thousand bucks for it?
  
 
We gotta discuss session handling, there's a lot of issues there.
 
We gotta discuss session handling, there's a lot of issues there.
Line 24: Line 42:
 
Allow_url_fopen Off is not secure at all. my most recent paper lists 12 methods of converting and LFI to a RFI, if somehow has an LFI flaw in the code, url_fopen On or Off wont matter.
 
Allow_url_fopen Off is not secure at all. my most recent paper lists 12 methods of converting and LFI to a RFI, if somehow has an LFI flaw in the code, url_fopen On or Off wont matter.
  
 +
: Right. But if set on, it's definitely insecure and very easy to exploit. --[[User:Achim|Achim]], 5-jul-2012
 +
 +
:: I'm just saying LFI is enough big of a threat that we need to '''educate''' developers about it. If we don't, there are absolutely no countermeasures.
  
 
The memory and execution time limit defined there,  is very bad practice. This limit kills the php script, and results in numerous errors which are extremely hard to debug. They do not mitigate DOS, you can simply run 10 scripts instead of 1.  The optimum values are 32MB memory, 30 second execution time, with ability to extend it in user code.
 
The memory and execution time limit defined there,  is very bad practice. This limit kills the php script, and results in numerous errors which are extremely hard to debug. They do not mitigate DOS, you can simply run 10 scripts instead of 1.  The optimum values are 32MB memory, 30 second execution time, with ability to extend it in user code.
 +
 +
: It's a suggestion, feel free to adapt it to proper values. Just using the default may bring you to some risks. --[[User:Achim|Achim]], 5-jul-2012
 +
 +
:: We need to find a solution to put a cognitive limit, otherwise there's no ''JUST" value for it. I need to delve my head into PHP manuals.
  
 
Please get back to me on this, or my email at owasp@abiusx.com
 
Please get back to me on this, or my email at owasp@abiusx.com
 +
 
--[[User:Abbas Naderi|Abbas Naderi]]
 
--[[User:Abbas Naderi|Abbas Naderi]]
PS. I really appreciate you working on this page, ignore my rude tone!
+
 
 +
Hi Abbas, could you add some clarification for ORM? Not everyone knows the acronym which diminishes the general readability and usability. Thanks! --[[User:Peter Mosmans|Peter Mosmans]] 04:47, 16 October 2012 (UTC)

Revision as of 19:07, 25 November 2012

NOTOC

I want to keep the TOC in so this is standard like other cheat sheets in this series (Jim Nov 25 2012)

TBD

I'm (mis-)using the {{TBD: ...}} wiki syntax to mark texts and paragraphs "to be discussed". Achim, 3-jul-2012


php.ini

I think your error configuration is not good. You have to set display_errors and display_startup_errors to On, otherwise it would be too hard to debug your code (yes you need debugging even on the server). The better practice, is to set to to On by default, and use a framework (a piece of code) to redirect that to a log for general user, and keep it on the screen for admins/developers. I've seen infinite developers set it to off, then set it to On for debugging, and leave it there.

OWASP makes suggestions for security not for compfy debugging. Security is the goal.
Hence Off is the choice for produktive systems. --Achim, 5-jul-2012
I don't know if you've experienced it or not, but this is exactly the difference between an open community and a commercial rigid ISO workgroup. We provide solutions that people actually use, not solutions that are perfect if we lived on the moon. This error handling issue is very important. Also the startup error should be on, otherwise users only think the site is dead. There shuold be a critical error level, delivered to the admin via SMS or Email, so that these errors are handled properly.

Why the hell is file_uploads off? Are you one of those guys who believe everything should be off to provide a secure system?

Yes (but there is a hint that some settings need to be adapted to real systems:) --Achim, 5-jul-2012
Could you elaborate the security risks with file_uploads?


Also disabling functions and etc. its a very bad practice. This is only used in dull shared web hosting systems, and nobody gets their hosts.

Either we try to make a crappy PHP secure, or you have to live with brain-dead develpers using something like system($_REQUEST['killme'])
--Achim, 5-jul-2012
Develoeprs should be aware of dangerous functions. Some IDE's deliver warnings when variables are used in dangerous functions, we could create a tool that would scan the code and tell so. This is the same scenario as the first issue.

Most usage of PHP is available source code (Wordpress, Joomla, MyBB, etc.) and they all use these abilities. What you're indicating just says "dont follow this cheat sheet", no offence!

the cheat sheet is about security, not about using insecure frameworks. --Achim, 5-jul-2012
15% of websites are powered with Wordpress, and they are among the most secure of all :)) Do you expect every admin to pay a few thousand bucks for it?

We gotta discuss session handling, there's a lot of issues there.

Allow_url_fopen Off is not secure at all. my most recent paper lists 12 methods of converting and LFI to a RFI, if somehow has an LFI flaw in the code, url_fopen On or Off wont matter.

Right. But if set on, it's definitely insecure and very easy to exploit. --Achim, 5-jul-2012
I'm just saying LFI is enough big of a threat that we need to educate developers about it. If we don't, there are absolutely no countermeasures.

The memory and execution time limit defined there, is very bad practice. This limit kills the php script, and results in numerous errors which are extremely hard to debug. They do not mitigate DOS, you can simply run 10 scripts instead of 1. The optimum values are 32MB memory, 30 second execution time, with ability to extend it in user code.

It's a suggestion, feel free to adapt it to proper values. Just using the default may bring you to some risks. --Achim, 5-jul-2012
We need to find a solution to put a cognitive limit, otherwise there's no JUST" value for it. I need to delve my head into PHP manuals.

Please get back to me on this, or my email at owasp@abiusx.com

--Abbas Naderi

Hi Abbas, could you add some clarification for ORM? Not everyone knows the acronym which diminishes the general readability and usability. Thanks! --Peter Mosmans 04:47, 16 October 2012 (UTC)