June 18, 2005 TCPHP meeting
Topic: Open discussions about PHP and web security

Introductions:

We met as usual at the Renasissance Box [1]. Attendes included:

Allie Micka
Scot Jenkins
HJ Schmidt
Dan Cain
Eric Hanson
Keith Connelly
Jay Taylor
Sam Buchanan
Jason Heiser
Tim McGuyer
And several other folks who joined us after the initial introductions.

Dan Cain recommended Innocent Code [2], a book about web security.

HJ launced the discussion with:  Given an old piece of code, what should the priority be when first looking for security vulnerabilities?

Authentication: (pagename/login=true)

• look for cookie, userid=admin
• redirecting when not authenticated (disable javascript and you can view the page); php redirection can also be circumvented.
• curl can be used to view the page
• redirection: location header
• login at the top of the page, if authentication error, throw up an error page and die
• session variable "loggedin=true"; you can override it. There's no reason to have a session variable "loggedin" because your sessionid is different when you're logged in vs. when you're not.
• use session_regenerate_id() [3] on your login page
• Basically you can't trust anything
• user agent string is not reliable; it can change through proxy farms like AOL. (cf. George Schlossnagle [4])
• use session id + some string that you append to POST variables. This way you need to have both things to get logged in.
• PHP sessions id's are "pretty" secure. They are relatively hard to guess, but they're still clear text and open to sniffing, especially over wireless.
• Using SSL on a site is expensive for authentication.
• Allie commented:
  • Use a 3rd party for authentication...authenticate to the main website, it returns a hash or secret, take this to an SSL server which gives you a cookie and returns you to the original website. Sort of works like kerberos or a token based system.
  • "All security is a cost/benefit". Security is a continum, not a "we have reached security." Security is about layers.
  • Are you storing info people want (to steal)?
  • Are you hosting a site that is controversial?

Data input validation:

• Filter all user input, focus on what you want to let in and code for that. Escape all output; escape meta chars to prevent SQL injection.
• HJ: Recommended prefixing a variable with a "u" char meaning it's "unclean". Once you've processed it and made sure the data is "clean", put the data in a variable without the "u" prefix.
• Register globals turned off; bring all variables in the POST array and clean it using PHP functions to filter input/output: str_replace [5], escapeshellcmd [6]
• Put all "cleaned" data in a global variable.
• What is dangerous input?
• The backtick does nothing in HTML or SQL, just on the command line.
• Single quotes change the context in a database.
• Use PEAR form handling functions, or create your own set of validation functions (validate_number, validate_string, etc...). You can reuse the functions later.

Security Testing Tools, etc.

• O'Reilly published Apache Security [7]. There's a free chapter available online.
• HJ: Apache as hardware?
• WinLAMP [8] - similar to J Wynia's PHP Triad [9].
• Installed in about 20 minutes but when rebooting Windows XP it said it found new hardware: "apache2".
• HJ had to remove the hardware device "apache2"
• Tim mentioned:
  • SPIKE Proxy [10] - point it at web logs and it pounds away on your password forms and looks for SQL injection, etc... It gives you a report of what it thinks you should look at for vulnerabilities.
  • Achilles [11] - another security tool form that won't let you in if you try a password 6 times, etc...
• Allie discussed mod_security [12] an Apache module that does filtering. It basically acts as a web application security firewall, blocking known "bad" signatures.
• insecure.org lists lots of good security testing tools [13]
• Dan commented on filters in PHP5, although they require that one write C code.
• Sam presented some slides on web app security testing, from the penetration testing point of view
• Browser tools: liveHTTPheaders [14] - mozilla/firefox plugin that displays all the headers so you can see what's going through and you can manipulate it to see what happens when you change things. liveHTTPheaders makes a great debugging tool.
• Dory (named after the Finding Nemo [15] character) - HTTP is stateless
• fiddler [16] - Windows only; it's like liveHTTPheaders on steroids. It's a .NET tool, intergrates with IE, but it can also work as a proxy (you can point other browsers to it). More info on the MSDN site [17].
• WebScarab [18] - HTTP proxy; written in java; checks session id's to monitor for patterns
• Other tools: nikto [19] - perl script that looks for vulnerabilities
• Nessus [20] - overall security assessment tool for penetration testing. It runs as a server, you run clients on boxes. You really want to make use of it's GUI. There's a commercial version available. It's not just for web application security. You can tell it to try NOT to crash a server. You should probably get written permission from the site owner before running Nessus.
• web inspect - used by Imation very insightful report
• Tim asked about how gmail [21] worked. He said ethereal wasn't showing the XML requests. It's still a mystery. The johnnyihackstuff.com [22] website was mentioned.
• Drupal [23] has throttling option to prevent DoS attacks.
• Watch for proper error handling; don't display too much data in the error messages. Allie mentioned how a few years back there was a hack for ColdFusion where if you added "$$data" to the end of a URL, it would spit out all the Cold Fusion source code, include files.
• Apache tips from Allie:
• By default, Apache serves ".inc" files as text. Configure Apache to NOT serve ".inc" files.
• If you are unable to modify the main Apache httpd.conf file, you can put these restrictions in a .htaccess file.
• You should keep include files (that contain database connection info and such) outside of the DocumentRoot.
• autoprepend is a cool feature and under utilized
• if __FILE__ == $PHP_SELF this means someone hit your page directly; this shouldn't happen.

Next month's meeting, July 16: More on Apache, safe mode, security, shared hosting environments.

Did you find these notes helpful? Please consider attending a meeting, taking notes, and posting them to the TCPHP web site to keep the group growing.