Hardening PHP: How to securely include remote code (part 1) (part 2) (part 3)
Session Puzzling and Session Race Conditions
A Systematic Analysis of XSS Sanitization in Web Application Frameworks (PDF)
Local Session Hijacking in PHP
Local Session Snooping in PHPQuote:
PHP's default session handler stores session data in files. And by default these files are placed in /tmp. In a shared enviroment session files should never be placed in a directory that can be read by a malicious local user like the world readable /tmp directory.
Local Session Poisoning in PHP Part 1: The Basics of Exploitation and How to Secure a ServerQuote:
Local session snooping is not as much a security issue as a way of gathering information from an already compromised web application. Unless it is a badly configured shared host where an attacker might gather otherwise unobtainable information. It's basically about extracting all the information a web application stored in the super global $_SESSION variable.
Local Session Poisoning in PHP Part 2: Promiscuous Session FilesQuote:
Session poisoning is the act of manipulating sessions specific data in PHP. To add, change or remove variables stored in the super global $_SESSION array.
Local session poisoning is enabled by the fact that one web application can manipulate a variable in the $_SESSION array while another web application has no way of knowing how that variable's value came to be, and will interpret the variable according to its own logic. The $_SESSION array can then be manipulated to contain the values needed to spoof a logged in user or exploit a vulnerable function. PHP programmers put far more trust in $_SESSION variables than for example $_GET variables. The $_SESSION array is considered an internal variable, and an internal variable would never contain malicious input, would it?
Local Session Poisoning in PHP Part 3: Bypassing Suhosin's Session EncryptionQuote:
FastCGI, suPHP and suExec can all ensure that a PHP script which is called from the web will execute under the user that owns it, as opposed to the user the web server is running as. This seemingly protects against session poisoning by ensuring that a malicious user no longer can open and manipulate session files owned by other users in a shared host.
The hidden pitfall is that while these protection mechanisms protect session files from unauthorized access, they can not prevent a user from authorizing others to access its session files. If all the session files are stored in a common folder it is trivial to trick a web application into loading session variables from a promiscuous session file.
By default Suhosin transparently encrypts session files stored by PHP. This seems to be adequate protection against local session poisoning in a shared hosting environment. But let's take a closer look.
Nice collection of article links!
As a CEH (Certified Ethical Hacker)), I'm aware of cross-site scripting, SQL-injection attacks, etc., but, aside from properly coding your scripts (e.g., checking submitted values), the MOST important thing to do is to use STRONG passwords. Get more information (and use the tool) at StongPasswordGenerator.com.
Recent threads have asked about SESSIONs and SESSION hijacking so I've posted links to:
- the Electronic Frontier Foundation
- their paper on browser uniqueness
- their article (How Online Tracking Companies Know Most of What You Do Online (and What Social Networks Are Doing to Help Them)) and
- the PC World article (http://www.pcworld.com/article/19264...cy_threat.html)
The point of these is two-fold:
- You can use the information gathered to validate a SESSION (to prevent SESSION hijacking)
As a CEH, I urge every member to look at each of the above links as they're essential to managing information and website security. While you're at it, REread the articles about coding PHP securely, too!
I had responded to a member's request for steps to combat and recover from a "Hack Attack" and it seemed better to add it to this sticky thread:
1. Immediatly delete all FTP access except one (master for the account).
2. Change the master password (cPanel and FTP) to a VERY STRONG one using an http://strongpasswordgenerator.com password of sufficient length.
3. Use maldet scans (on an Apache server) which find and report all forms of malware (viruses, worms and SCRIPTS which can cause problems). This will enable you to find and remove scripts which can be embedded in html, php and js scripts. Repeat the maldet scans until there are no files detected then add a CRON to run maldet scans on a regular basis. Be aware that recovery will primarily consist of DELETING all html, php and js files and replacing them with originals (from your master copies).
4. Additionally, I use a CRON to SHA1 hash verify that files have remain unchanged over the last xx hours for "peace of mind." I created and use the script shown at http://www.sitepoint.com/detect-hack...s-via-cronphp/ but would recommend that NO file extensions be listed so that, if a hacker were to inject a file with an extension you don't use, it'll be picked up in the scan, too. Just heed the advice about keeping your hackscan.php file out of the webspace and note the regular intervals in the e-mails provided to you.
5. Database: If you are running WordPress or the like (database verification for admin accounts), create a new admin and delete all other admin records.
6. Uploaded files: Be sure to do a thorough check of any file uploaded to your website (I limit uploaded files to images and they are recreated and resized by GD before being saved to my "webspace").
7. Update all "canned scripts" (e.g., WP, Zencart, etc.) AND their plug-ins and be sure that they're kept updated in order to prevent further attacks via security problems discovered in those scripts.
There is a place for penetration testing (with a tool like BackTrack) but it is something best left to the sysadmins of your host (or a security professional if you own your server). In fact, you must not use those tools or techniques on others' servers because you will be identified as a hacker, your IP address will be blocked and you will be reported to authorities for prosecution. The anti-hacking laws are beginning to be enforced and you will (and should) be harshly punished.