Saturday, 25 August 2007

PHP Basics (Section 3) - Security

Defense in Depth

  1. When you plan with defense in depth, you plan for failure. Rather than internal functions assuming the data they receive is already validated or escaped, they will check and confirm.
  2. Application that demonstrate defense in depth are not noly more resistant to attack when they are developed, they also remain more resistant over time as new attacks are developed, and as more code is added to them.
Least Privilege
  1. Your PHP applications by default has a lot of power, they execute as the web user (often apache or www-data) with all the rights and privileges thereof.
  2. If an attacker gains control of PHP through an application vulnerability this can be used and abused.
Validation vs Escaping
  1. These terms are often confused, or used interchangeably.
  2. Validation or Filtering is the process by which you subject data to a series of rules, either it passes (validates) or does not.
  3. Escaping is the process by which you prepare data for a specific resource by "escaping" certain portions of the data to avoid confusion of instruction and data.
Validate Input
  1. Whenever you receive data one of three things can be said about it: 1) It is valid, the user entered the data you want, in the format you desire; 2) It is invalid because the user either did not comply or did not understand the rules on the data you requested (eg. Poorly formatted postcode); 3) It is invalid because the user is attempting to compromise your application.
  2. Data from the end user can not be trusted, it must be validated before it can be used.
  3. Validate data first don't save it for last.
  4. Fail early, tell the user what went wrong.
Whitelist vs Blacklist
  1. There are two major approaches to data validation, the whitelist and blacklist approach.
  2. Under the whitelist approach you select a series of valid characteristics (frequently characters) only data that follows these rules is accepted as valid.
  3. Under the blacklist approach you select a series of invalid characteristics, any data that contains these characteristics is considered invalid.
  1. Under a cross site scripting attack an attacker injects code into your page (forum post, shout box, etc) that contains code that re-writes the page to do something nefarious.
  2. This can be prevented through proper escaping and data validation techniques
  1. Under a cross site request forgery attack a site exploits another sites persistent user trust relationship to make something happen.
  2. iFrames are another common tool leveraged in this technique.
  1. Sessions provide safer state, it may not nesesarily be safe.
  2. Basically, sessions combine cookies containing a session ID with a local(ish) data store corresponding to that session id.
  3. If the session id is compromised, or the data store is not secure (/tmp on a shared machine) sessions are still vulnerable to attack.
  4. Session IDs are very random.
  5. Predicting them is hard, it’s much easier to: 1) Check out /tmp on a shared server, see what people have; 2)Intercept communications; 3)Implement session fixation.
  6. To defend, implement some browser fingerprinting.
For more information, please read my another post PHP Application Security Rules

No comments: