Otaku – Cedric's blog

8 Comments

• #1 by Nelson on February 19, 2005 - 8:20 am

  

  It’s ch3ap enough to slam random pages with exploits. My Apache logs are full of attacks on IIS.
  PS: Cedric, your filter wouldn’t let me post the word “ch3ap”, as in inexpensive.

• #2 by Emmanuel Pirsch on February 19, 2005 - 8:28 am

  

  Security by Obscurity… That’s the way to go 😉

• #3 by John Beatty on February 19, 2005 - 9:29 am

  

  I believe some people do at least a little profiling… Off the top of my head, there’s a few ways you could detect PHP: (1) standard session cookie names; PHP uses ‘PHPSESSID’ by default. (2) ‘Server:’ header in HTTP response. Apache lists the installed modules by default (‘mod_python’, ‘PHP/x.x.x’, etc.). (3) Some PHP installs spit back an ‘X-Powered-By: PHP/x.x.x’ header, too. All the above can be turned off, I believe. The Live HTTP Headers extension for Firefox can be useful when fiddling around with this stuff.

• #4 by Frank Bolander on February 19, 2005 - 11:38 am

  

  Obfuscating is often a weak approach (http://www.php.net/manual/en/security.hiding.php). Like John said, there usually is a profiling stage where suspect boxes are probed and then broadcast over IRC to miscreants. Unfortnuately, a lot of the script kiddies are pretty smart in getting around these obfuscation techniques. The problem , with Cross-Site Scripting attacks, is that system commands are embedded/encoded in GET parameters. When they are deserialized, they execute the offending code. What next, obsfucate your script names and GET parameter names. I don’t think this should be an application level problem to solve obvious container issues.
  I originally liked PHP especially with the new V.5 OO extensions. However, this product is V.4+ now and some of the exploits, IMO, should have been taken care of in previous releases. For example, there is a config parameter openbase_dir where you can create a /tmp sandbox on a boxed directory — where most cross-script attacks occur. Unfortunately, until the latest release, it was completely bypassed by the low-levevel functions that you would want to protect against in the first place.
  As a note for non-PHP stuff, I think a good discussion would be, “Is L*nux really that secure?”. Luckily, my compromised machine was a development box, but I’ve still had to spend alot of time and effort to secure it. No more/less time than I’ve had to secure M$soft machines. My mistake was I purchased the box from a third party and assumed an Enterprise Edition of L*nux would have a different install profile than let’s say a raw L*nux install. To my chagrin, it didn’t and in some cases was worse. Also, the auto update from the OS vendor was disappointing. These critical vulnerabilities were posted on well-known security forums in Nov 2004, I received the alert in early Feb 2005. So much for the value of purchasing an enterprise support contract.
  FWIW and IMHO, to all other people h0sting a dedicated or self-managed machine, make sure they mount /tmp on it’s own partition with noexec,nosetuid options in mount. It still can be hacked, but will thwart a good number of attacks without having to obfuscate anything. And if you have the time, check out snort.org for intrusion detection. I installed the snort_inline with dynamic rule capabilities in iptables, and has been great(knock wood). The best place would be to stop the stuff at the network layer edge before it hits any container.

• #5 by kebernet on February 19, 2005 - 1:42 pm

  

  Basically, the question I’m asking is: how do hackers target PHP sites? Is there any other means to guess that a page is generated by PHP except for its suffix?
  You might look at the server ID headers. These will indicate that PHP is installed, even though it might not indicate that .foo files are actually PHP.

• #6 by Alan Knowles on February 20, 2005 - 1:37 am

  

  I think you missed the point, there are very few PHP exploits out there, most of them are specific to a particular application, phpNuke, phpBuletin etc.
  So hiding the fact that it’s PHP is pretty pointless…
  It’s pretty simple to do a security review of most php applications starting with grep.
  A) check ito see if it has a db abstraction layer. that escapes stuff
  B) check to see if it has an output layers that escapes stuff.
  C) check for common mistakes – unescaped/checked values used in exec , preg_match with /e
  D) check it doesnt need register_globals.
  If it doesnt pass those tests, then it’s probably only good for the intranet..

• #7 by Jason Barker on February 21, 2005 - 5:59 pm

  

  I second that, the problem is mostly on PHP applications, not PHP itself.
  It is possible to implement insecure J2EE applications as well.
  Then why are there many insecure PHP based applications, compared to J2EE based applications?
  – skills. PHP is easier to learn, hence there are more novice PHP programmers than in J2EE.
  If you ask some high schools kids on which language to use to implement web applications, they’ll choose PHP over J2EE. Unless they really have to, or have the willingness to learn J2EE.
  I’m not saying that those PHP applications (phpBB, nuke etc) are developed by novice programmers.
  – security is less of a priority in PHP commmunity than it is in J2EE community.
  The problem is really not the language, it is how you develop the applications.
  For example:
  Many PHP programmers simply pass request parameter values straight to the sql. While in J2EE development, my colleagues will kill me if I do that.
  J2EE community exercise better practices than the PHP community.

• #8 by Confluence: 0. Gonzo on June 17, 2005 - 10:04 am

  

  Cedric Beust has a couple
  Cedric Beust has a couple of interesting blogs on PHP : PHP confessions from a Java fiend

Comments are closed.