Eight simple rules to writing secure PHP programs

Eight Simple Rules… for Writing Secure PHP Programs Aleksandr Yampolskiy

Security: Bird’s Eye View ... Hash Key Management Signature Encryption Security Toolbox DL(g x ) Fact(p*q) Hard problems Prob[ Attack ] ≤ ɛ Proof of security

Building Secure Systems … Looks safe to me

Building Secure Systems
All is well until it starts raining…

This Talk
Think of your software system as a “house” , and coding standards as the “glue” .
In this talk, we give eight rules for writing secure PHP programs
They are:
A glue for building secure systems.
Practical and can be easily implemented!
Will prevent many of the security exploits.
vs.

Rule 1: Use proper cryptography
Do not use stream ciphers (such as RC4). Instead use block ciphers AES, 3DES .
For hashing, use SHA-2 (although SHA-1 is still ok).
Do not use a single master key for all encryption purposes. Use different keys .
Do not hard code key or passwords into your code.
For sensitive operations, use a secure random number generator instead of default rand().
Do not invent your own cryptographic algorithm or download one from the web. Contact [email_address] for advice, first.

Common mistakes
Poor choice of algorithm
Attempting to develop an encryption scheme in house
Failure to change encryption keys
Insecure storage of passwords, keys, certs
Many attacks exploit poorly-developed random numbers that are used to generate session IDs.
<?php for ($i=0; $i<6; $i++) {
$d=rand(1,30)%2;
echo $d ? chr(rand(65,90)) : chr(rand(48,57)); } ?>

Randomness

In Theory
Cryptography is based on random numbers :
Secret keys must be random
Random bits are needed for public-key encryption, signatures, SSL, etc.
In theory, all parties have access to a perfect random source [BR93].
Under this assumption, many crypto tools can be proven formally secure .

Examples of Real Problems
Earlier versions of Majordomo used a bad PRG. Could forge mailing list acceptance and subscribe an unknowing victim to thousands of lists.
Kerberos 4 used memset() to erase a seed before it was used. Seed was always zero and secret keys could be guessed in a few seconds .
Netscape 1.1 generated SSL keys using time and process ID as seed; easily guessable and breakable.
Problem: Secret keys aren’t truly random!

Lessons Learnt
Seeds must be unpredictable
128 bit sequences are sufficient
All possibilities equally likely
Best seeds are truly random
PRG (pseudorandom number generator) must be secure
No detectable pattern
Even if attacker guesses some pseudorandom bits, no correlation to other bits.

What is (Pseudo)-Random? PRG random seed pseudorandom string random string look indistinguishable to any efficient observer Definition [Blum-Micali-Yao]: PRG is a polytime function whose output is indistinguishable from random by any efficient observer 01010111001… 11010011010… 1001

Implementation
To generate cryptographically secure random numbers in PHP, use md5(mt_rand()) or better yet read from /dev/urandom
better_token = md5 (uniqid( mt_rand() , true));
$uniqueId = bin2hex(file_get_contents('/dev/urandom', 0, null, -1, 16));
Make sure not to use rand() for security-sensitive applications

Rule 2 – Validate all input
Input validation failures are behind most common security vulnerabilities (buffer overflows, XSS, log forging, etc.).
Source of confusion is that input can come from many sources (HTML forms, query strings, environment variables, data files, shared memory, etc.)
Always validate user input on the server-side before acting on it (even if it has been validated by the client)

Rule 2 – Validate all input (cont.)
Decode data into canonical representation before validation
Always establish length constraints
Canonicalize paths
http://website/servlet/webacc?user.html=../../../../../../../ boot.ini%00
Use whitelists instead of blacklists

Use regexps to validate strings
<?php
if (ereg("^[a-z]+.html$", $id)) {
echo "Good!";
} else {
die("Try hacking somebody else's site.");
}
?>

Tainted Variables
Use Tainted Variables in PHP to eliminate opportunities for injection or hijacking before they’re exploited.
All external content marked as tainted and refuses to execute potentially insecure functions unless validated and sanitized.

Example –w/o taint, this will echo the contents inputfield, including malicious HTML script code.
$inputfield = $_GET['inputfield'];
echo "You entered: $inputfieldn";
Modify php.ini to include –
taint_error_level=E_WARNING
And the code will execute, but also produce a warning
Warning: echo(): Argument contains data that is not converted with htmlspecialchars() or htmlentities() in /path/to/script on line 3

Example cont. – Modify php.ini to include –
taint_error_level=E_ERROR
And the code will terminate before “echo” produces any
output.
If you convert $inputfield , the program becomes immune to HTML script injection and the warning disappears.
$inputfield = htmlspecialchars($_GET['inputfield']);
echo "You entered: $inputfieldn";

Example of Real Problem - XSS
If we don’t limit username length, an attacker could create the following:
Username<script type="text/javascript" src="http://www.website.com/malicious.js"></script>
JS has been loaded from another site invisibly.
Combat by limiting the character set that can be used, and disallow special characters and HTML tags.

Rule 3 - Sanitize data sent to other systems
Sanitize all data passed to complex subsystems such as command shells, relational databases, and vendor products.
Not necessarily an input validation problem because the subsystem does not understand the context in which the call is made.
Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks.

SQL Injection
SQL injection aims to influence database queries by manipulating input params. Very common in web apps!
Example:
$check = mysql_query("SELECT Username, Password, UserLevel FROM Users WHERE Username = '".$_POST['username']."' and Password = '".$_POST['password']."'");
If a user enters ‘OR 1=1 #’ as the Username, this query will be executed: SELECT Username, Password FROM Users WHERE Username = '' OR 1=1 #' and Password = ''

SQL Injection (cont.)
Validate that data we enter/query against DB is “well formed”.
Instead of passing a string to the conditions option, you can pass an array to sanitize tainted strings
function make_safe($variable) { $variable = sql_real_escape_string(trim($variable)); return $variable; }
Now run user data through make_safe:
$username = make_safe($_POST['username']); $password = make_safe($_POST['password']); $check = mysql_query("SELECT Username, Password, UserLevel FROM Users WHERE Username = '".$username."' and Password = '".$password."'");

Global Variables
If register_globals is enabled, PHP will create global variables for each GET, POST, and cookie variable included in the HTTP request.
Disable register_globals in your php.ini file. Use the $HTTP_GET_VARS and $HTTP_POST_VARS to access GET and POST inputs instead of global variables.
Write code to initialize all global variables or to check that a global variable is not in the $HTTP_POST or $HTTP_GET .
Ensure session variables really do come from the session and not from a malicious user

PHP.INI Security Settings
The disable_functions line disables functions commonly used in attacks against PHP web applications and PHP backdoors.
Example: disable_functions=eval, dl, phpinfo, system, exec, passthru, shell_exec, proc_close, proc_terminate, popen
Disable the use of URLs to be in include() and fopen() functions to reduce the change of successful remote file inclusion attack.
Example: allow_url_include=0 and allow_url_fopen=0

When safe_mode is turned on, you can specify which directories are searched for files and which are excluded using safe_mode_include_dir and safe_mode_exclude_dir.
Restrict the programs a PHP script can run with the exec() command by placing the binaries in a special directory and telling PHP about it using safe_mode_include_dir
Example: Only binaries in this directory will be accessible via exec() safe_mode_include_dir=/usr/local/lib/php/safe-include
safe_mode_exec_dir=/usr/local/lib/php/safe-bin

open_basedir will not allow files to be open by PHP scripts outside of the base directory, where you store your websites’ files.
Example: open_basedir = /var/www
Turn register_globals=off , so attackers cannot override variables in your scripts by specifying them in URL parameters.
Turn expose_php=off . An attacker may query an exploit database to find vulnerabilities in your application version.

Rule 4 – Avoid information leakage
Apps can accidentally leak info about their internal workings , config, etc.
Attackers can use this weakness to steal sensitive data.
Ensure sensitive responses with multiple outcomes return identical result .
Ensure error messages are returned in roughly the same time or impose a random wait time for all transactions
Don’t log sensitive data.

Information Leakage - Example
Sensitive information can be leaked very subtly.
Example 1 : Account Harvesting
App responds differently to a valid username with invalid password, then it would to a invalid username.
App discloses which logins are valid vs. which are invalid, and allows accounts to be guessed and harvested.
Example 2 : Production code comments . More innocuous.
<script type="text/javascript"> $(function() {$("#19468751").qtip({content: '<div class="calendar_hover"><div class="title_bar"><h2 class="on" lang="en">OGIO Bags</h2></div><img oncontextmenu="return false;" galleryimg="no" src="http://cdn1.gilt.com/images/share/uploads/0000/0000/1991/19911713/orig.jpg?43_1258590331" height="207" border="0" alt="OGIO Bags" width="303" /></div>',style: {padding: 0,width: 303 + 2,border: {width: 0//color: '#575757',//radius: 1}},position: {target: 'mouse',adjust: {mouse: true,screen: true,x: 30,y: 0 }}});// Last resort if Andy can't figure out how to style a border/*var api = $("#19468751 ").qtip("api");api.beforeRender = function() {// Strip out the default styledelete this.options.style.background;delete this.options.style.color;delete this.options.style.textAlign;this.options.style.width = {};delete this.options.style.padding;this.options.style.border = {};this.options.style.title = {};};*/});</script>

Information Leakage - Logging
Logging is great for debugging, performance monitoring, compliance, etc.
But… do not log sensitive data (passwords, SSO cookies, credit card numbers, cryptographic keys, etc.)
Don’t display detailed internal error messages including stack traces, messages with database or table names, protocols, and other error codes. (This can provide attackers clues as to potential flaws.)
In PROD, it’s a good idea to set the error_reporting to 0. Use error_log() to log errors to a file or e-mail alert.

Information Leakage - Logging

Rule 5 – Proper session management
Session tracking answers the question:
After a user authenticates how does server identify subsequent requests to the user?
Many web app vendors have built-in session tracking, which is good if used properly
Often done through cookies with session IDs
session[:user_id] = @current_user.id; User.find(session[:user_id])
Often developers will make the mistake of inventing their own session tracking.
If session tokens aren’t properly protected, attackers can steal them to assume user identities .

Example 1 - Session Hijacking
Session ID is disclosed or is guessed.
An attacker using the same session ID has the same privileges as the real user.
Allows initial access to the web application to be combined with other attacks.
Two ways: intercepting (steal session token by observing network traffic) or stealing (steal token by persuading user to execute malicious code).

Example 2- CSRF Website Evil Doer
Alice downloads webpage from Evil Doer’s website
Downloaded webpage accesses website (e.g. <img src= http://www.site.com/withdraw?account=bob&amount=1000 > ) and performs a command without the user’s authorization
1 2

Example 2- CSRF (cont.)
Also known as one click attack or session riding.
Transmits unauthorized commands from a user the website trusts.
To prevent,
Require authn POST param, not only cookies
Use a form timeout – set min and max allowed time to filter automated CSRF attacks
Limit lifetime of authn cookies
Double-submit the security tokens

Proper session mgmt
Enforce a limited lifetime on user sessions.
Validate a session ID before using it (current active session)
Do not use deterministic seeds to generate random numbers for session IDs (e.g. don’t use IP as a seed)
Redirect user to logon page if session is stale or logged out.

Proper session mgmt (cont.)
Use long complex random session ID that cannot be guessed.
Protect the transmission and storage of the Session ID to prevent disclosure and hijacking (transmit entire session over HTTPS).
A URL query string should not be used for Session ID or any User/Session information
URL is stored in browser cache
Logged via Web proxies and stored in the proxy cache

Proper session mgmt (cont).
Session ID should expire and/or time-out on the Server when idle or on logout (reset_session)
Client side cookie expirations useful, but should not be trusted.
Consider regenerating a new session upon successful authentication or privilege level change

Rule 6 – Authentication & Entitlements
Authenticate first. Authorize second.
Use strong passwords.
Most developers understand authentication well. Many still make mistakes with authorization.
Authorization (aka entitlements) = the process of granting or denying access to something we are trying to protect.

Authentication & Entitlements (cont.)
Pitfalls
Over privileging users
Not performing authorization checks at all
Using default allow (instead of default deny, which is correct)
Principle of least privilege = give users least privilege required to perform their business duties.

Authentication & Entitlements (cont.)
Fail securely
Applications regularly fail to process txns for many reasons. How they fail can determine if an application is secure or not.
For example see below:
If either codeWhichMayFail() or isUserInRole fails or throws and exception, the user is an admin by default. This is obviously a security risk.
isAdmin = true;
try {
codeWhichMayFail();
isAdmin = isUserInRole( “Administrator” );
} catch (Exception ex) {
log.write(ex.toString());
}

Rule 7 – Use Secure Communication Channels
Failure to encrypt network traffic enables it to be sniffed from any compromised system/device on the network.
Use SSL/TLS for ALL connections that are authenticated or transmitting sensitive information (PII, user credentials, credit card data, etc.)
Use SSL/TLS for mid-tier and internal network communications between Web Server, Application and database.
Use only SSLv3 and TLSv1 with strong ciphers.
Use only valid trusted SSL/TLS certificates and train users to actually expect valid certificates to prevent MITM attacks.

Rule 8 – Keep Security Simple
Avoid security by obscurity
Kerchkoffs’ principle (1883) = “the enemy knows the system”
Linus Torvald’s law = ” many eyes make all bugs shallow”.
Better security for algorithms and protocols whose details are published.
Examples of exploits: Diebold election systems , Skype, chessclub.com, etc.

Recap : the 8 rules
Use proper cryptography
Validate all input
Sanitize data sent to other systems
Avoid information leakage
Proper session management
Authentication and entitlements
Use secure communication channels
Keep security simple

Often the easiest way to break security is to circumvent it rather than defeat it. Parting Thought

Eight simple rules to writing secure PHP programs

by Aleksandr Yampolskiy

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Eight simple rules to writing secure PHP programs Presentation Transcript