Security for developers/Tutorial

Welcome to the tutorial on Secure Coding and Code Review, originally given at the Berlin Hackathon 2012. The live tutorial will cover:
 * Problems we see on MediaWiki: Top Vulnerabilities (20 min overview)
 * "Spot the Vulnerability" (5 min)
 * Secure Design Principles (5-10 min)
 * Collaborative: write some secure code (15 min)
 * Security review of developers' code

Tutorial Preparation
Would you like to see some specific code reviewed, live, during the tutorial? You can suggest it via this list, below.

Introduction
The Secure coding and code review for MediaWiki Tutorial is based on MediaWiki security best practices and was originally created for the Berlin Hackathon 2012. It is designed to teach skills, to be reusable and, as all things Wikimedia, to be a living, editable document. Please contribute your thoughts on the discussion page and update this tutorial as needed. Tutorial slides are available. Preliminary tutorial slides are also available.

Top Problems We See

 * Stuff we keep seeing
 * Cross-site Scripting (XSS)
 * Cross-site Request Forgery (CSRF)
 * Not protecting against Register Globals
 * SQL Injection

XSS

 * 1) Definition: an attacker is able to inject client-side scripting into a web page viewed by other users.
 * 2) Results in:
 * 3) Authenticated Requests
 * 4) Session Hijacking
 * 5) Click Jacking
 * 6) XSS Worms
 * 7) Internal network portscanning
 * 8) Types
 * 9) Reflected
 * 10) Stored / 2nd Order
 * 11) DOM / 3rd Order
 * 12) XSSI / "javascript hijacking"

Reflected XSS
An attacker is able to inject client-side scripting into a web page, executed by others.

2nd Order (Stored) XSS
Attacker-controlled data is stored on the website, and executable scripts are displayed to the viewer (victim)

3rd Order (Dom-based) XSS
Attacker influences existing DOM manipulations in a way that generates attacker-controlled execution of scripts

XSSI

 * A script with sensitive data is included and manipulated from another domain
 * Known as "JavaScript hijacking" Here
 * Used in 2006 to compromise gmail
 * Often used to enable a CSRF attack

More about XSS

 * For the theories behind XSS, and why certain filter should be applied, read: OWASP XSS Prevention Cheat Sheet
 * Quick reference of how to escape data in different document settings: OWASP Abridged XSS Prevention Cheat Sheet

Same Origin Policy
To understand the cross-site aspects of xss, you will need to understand Same Origin Policy SOP Lots of useful information about how browsers handle cross-domain situations  SOP is NOT the same for JavaScript vs. Flash vs. XHR  SOP is changing with CORS
 * OWASP .ppt on SOP
 * http://code.google.com/p/browsersec/wiki/Part2

Understanding

 * When an HTTP session is tracked with a cookie, the cookie is appended to every call to the cookie's originating server. This is done automatically by the browser.
 * This includes calls to a server for an image, or an iframe
 * If a user has an authenticated session established, a remote site can request remote resources from that site. The browser will request those resources with the authority of the logged in user.

Or more likely:

Preventing

 * Tokens given out just prior to editing, checked to authorized edit
 * In addition to authentication / authorization checks (not a replacement for)
 * Must be difficult to predict / guess (e.g., md5( $username, $timestamp ) would be bad; md5( $username, $secretKey, $timestamp ) would be ok)

Register Globals

 * If register_globals is on, then an attacker can set variables in your script

Dangers

 * Remote File Inclusion (RFI), if allow_url_fopen is also true
 * Alter code execution

Protections

 * Don't use globals in script paths
 * Ensure your script is called in the correct context
 * if ( !defined( 'MEDIAWIKI' ) ) die( 'Invalid entry point.' );
 * Sanitize defined globals before use
 * Define security-critical variables before use as 'false' or 'null'

Understanding

 * Poorly validated data received from the user is used as part of a database (SQL) statement
 * Often occurs when attacker-controlled values are concatinated into INSERT or WHERE clauses

Dangers

 * Authentication Bypass
 * SELECT * FROM users WHERE username='$username' AND password='$pass';
 * If $pass is set to "' OR 1='1"?
 * Data corruption
 * DROP TABLE, UPDATE data (esp. user tables)
 * In the worst case, complete system compromose
 * xp_cmdshell on SQL Server
 * SELECT INTO OUTFILE on MySql
 * lots of other bad stuff...

Preventing

 * Use MediaWiki builtin db classes and pass variables by key=>value for CRUD
 * select
 * selectRow
 * insert
 * insertSelect
 * update
 * delete
 * deleteJoin
 * buildLike
 * If you really have to, use database::addQuotes to escape a single value

Top Vulnerabilites in Web Apps OWASP top 10

 * A1: Injection
 * A2: Cross-Site Scripting (XSS)
 * A3: Broken Authentication and Session Management
 * A4: Insecure Direct Object References
 * A5: Cross-Site Request Forgery (CSRF)
 * A6: Security Misconfiguration
 * A7: Insecure Cryptographic Storage
 * A8: Failure to Restrict URL Access
 * A9: Insufficient Transport Layer Protection
 * A10: Unvalidated Redirects and Forwards

More Bad Code...
Vulnerabilites: Extra Credit:
 * RFI in lang parameter
 * sqli in auth
 * $lang xss in form
 * errMsg reflective xss
 * $translations['login'] reflective xss (with register globals on)
 * insecure cookie for authentication
 * nextUrl header injection
 * $translations['bad_login'] header injection (with register globals on)
 * No salt for md5 hash of passwords
 * PHP_SELF reflective xss

Simplicity (Demonstrable Security)
The larger and more complex your code, the more likely that it will contain a vulnerability. Keeping your code clean, simple, and easy to understand will reduce the number of places your code can be attacked, as well as making it easy for others to spot flaws or potential attacks before attackers do. Clearly document any security assumptions that your code makes.

Secure by Default
This principle states that the most strict security posture for your feature / code should be the default as soon as it goes into production. If an administrator needs to lower the security for their users, they should be able to do so, but it would be an intentional action on their part to increase their risk. If you're not sure what the most secure option is, ask someone!

Secure the Weakest Link
Successful attackers will nearly always attack the weakest point in a system, instead of the most well protected ones. For example, an attacker will not spend time circumventing the MediaWiki parser functions to inject a xss if they are able to make a change to Common.js, or socially engineer an admin to give them their password. Keep the whole system in mind as you design.

Least Privileges
In general, any features you develop should be able to run with "Just enough authority to get the job done." For example, if most of your users will only need to see public information, but a few would benefit from some privileged data, segment based on a role instead of giving everyone advances privileges or showing all of the data to everyone.

MediaWiki Secure Coding Checklist

 * Please see the more recent and comprehensive Security Checklist For Developers

Collaborative Development of Code

 * Starting with a skeleton of a SpecialPage
 * Create a Special Page that allows searching, and showing results
 * Assume a database of text data
 * CREATE table `myData` (`id` INT, `name` varchar(80), `body` TEXT);
 * Presents a search box to users of your content.
 * When a search is received, search the database for a match in the `name` or `body` fields, display the search term, and a list of article names (which link to the article), and the beginning of the body to the users.

Hands-on Code Review

 * Suggested Code for Live Review (if it's long, please post somewhere and link to it.)