This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Talk:PHP Security Cheat Sheet"
(TBD) |
(reference to PHP distribution) |
||
(10 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
=== NOTOC === | === NOTOC === | ||
− | + | I want to keep the TOC in so this is standard like other cheat sheets in this series (Jim Nov 25 2012) | |
− | |||
− | I | ||
− | |||
=== TBD === | === TBD === | ||
I'm (mis-)using the <code><nowiki>{{TBD: ...}}</nowiki></code> wiki syntax to mark texts and paragraphs "to be discussed". | I'm (mis-)using the <code><nowiki>{{TBD: ...}}</nowiki></code> wiki syntax to mark texts and paragraphs "to be discussed". | ||
[[User:Achim|Achim]], 3-jul-2012 | [[User:Achim|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. --[[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! | ||
+ | |||
+ | : 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. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | : 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 [email protected] | ||
+ | |||
+ | --[[User:Abbas Naderi|Abbas Naderi]] | ||
+ | |||
+ | 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) | ||
+ | |||
+ | == Citing 72% of servers stat == | ||
+ | |||
+ | Can someone provide the source for the statistic under the “PHP overview” section that 72% of web servers run PHP. Also, is that 72% of ''all'' servers worldwide? | ||
+ | — [[User:Roy Vanegas|Roy Vanegas]] ([[User talk:Roy Vanegas|talk]]) 22:45, 17 March 2014 (CDT) | ||
+ | |||
+ | : W3 Techs claims [http://w3techs.com/technologies/details/pl-php/all/all 81.8%] "of all the websites whose server-side programming language we know". --[[User:Markus Malkusch|Markus Malkusch]] ([[User talk:Markus Malkusch|talk]]) 07:31, 18 March 2014 (CDT) |
Latest revision as of 12:31, 18 March 2014
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 [email protected]
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)
Citing 72% of servers stat
Can someone provide the source for the statistic under the “PHP overview” section that 72% of web servers run PHP. Also, is that 72% of all servers worldwide? — Roy Vanegas (talk) 22:45, 17 March 2014 (CDT)
- W3 Techs claims 81.8% "of all the websites whose server-side programming language we know". --Markus Malkusch (talk) 07:31, 18 March 2014 (CDT)