Security for developers/Architecture

This is being developed to help lead developers, architects, and product managers make decisions that protect MediaWiki's users when developing new features.

= Security Architecture =

"When starting a new application or re-factoring an existing application, you should consider each functional feature, and consider:
 * Is the process surrounding this feature as safe as possible? In other words, is this a flawed process?
 * If I were evil, how would I abuse this feature?
 * Is the feature required to be on by default? If so, are there limits or options that could help reduce the risk from this feature?"

What are we trying to protect?
Although MediaWiki is designed to allow anyone to edit, and to provide access to other user's information, there are a few things that the system attempts to keep private:


 * Confidentiality of Deleted & Suppressed content
 * Content in an article, edit summary, username of editor, specific log entries
 * Confidentiality of data protected by the WMF privacy policy
 * e.g., IP and UserAgent of editors
 * Integrity of content, attribution and logs
 * Prevention of site DoS
 * Prevention of content DoS. E.g., vandalism and spam
 * Prevent accounts from elevating their privileges without authorization
 * Account non-repudiation. A user should not be able to deny that they made an edit attributed to their user, nor should an admin be able to deny taking an administrative action that the logs report they took.

Is this feature a good idea?
A feature may not have any of the implementation flaws listed on Security_for_developers, but if it fails to protect the items listed above, then we don't want this feature running on our sites. Always ensure that the process that your feature enables isn't itself flawed.

Secure Design Principles
There have been many design principles for security features discussed in academia and the information security community for many years. The list from Saltzer and Schroeder's 1975 paper is often used. It states that secure systems will have the following characteristics:


 * Open Design - "The design should not be secret."
 * Fail-safe defaults - "Base access decisions on permission rather than exclusion."
 * Least Privilege - "Every program and every user of the system should operate using the least set of privileges necessary to complete the job."
 * Economy of Mechanism - "Keep the design as simple and small as possible."
 * Separation of privileges - "Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key."
 * Complete mediation - "Every access to every object must be checked for authority."
 * Least Common mechanism - "Minimize the amount of mechanism common to more than one user and depended on by all users."
 * Psychological acceptability - "It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly."

In 2005, a working group with OWASP produced the following list of secure design principles in web applications specifically:
 * Minimize Attack Surface
 * Secure Defaults
 * Least Privilege
 * Defense in Depth
 * Fail Securely
 * Assume External Systems are Insecure
 * Separation of Duties
 * Do not trust Security through Obscurity
 * Simplicity
 * Fix Security Issues Correctly

Threat Modeling
When looking at specific security considerations and controls in your feature, you also need to consider how your feature will be attacked. For each possible attack, you need to decide if the risk is worth mitigating with a technical control and how that should be done, or you can make the conscious decision to accept the risk posed by the threat. Accepted risks should be communicated to your stakeholders.

To think through the different threats that your feature will face, in Threat Modeling: Designing for Security (ISBN 1118809998), Adam Shostack recommends first drawing a data flow diagram representing the external actors, processes, and datastores for your feature and how the data flows between them with trust boundaries drawn around the actors and processes that trust each other. Once this diagram is drawn, for each place where data flows across a trust boundary, consider how your feature will prevent Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, Elevation of privileges (STRIDE).

Alternatively (or in addition to STRIDE modelling), you can also use MITRE's list of common attack patterns (CAPEC) to think through common attacks on your feature, and how you can mitigate each if applicable.

Implementation
As you implement the feature and controls, you and your team need to make sure that:


 * The controls you identified while doing the design and threat models were correctly implemented
 * The code does not allow attacks on the site's users (XSS, CSRF) or the server (SQL or Command Injection). See Security_for_developers.
 * Verify that
 * MediaWiki authorization structure enforced
 * If you code processes xml, you have disabled xml external entity loading (XXE Attacks)
 * If you code serializes and unserializes data, you have prevented unserialization attacks
 * If you code redirects or proxies requests, the location has been sanitized and approved via whitelist

Resources

 * OWASP top 10 - https://www.owasp.org/index.php/Top_10_2013-Top_10
 * CWE top 25 - https://cwe.mitre.org/top25/
 * CAPEC - http://capec.mitre.org/data/definitions/1000.html
 * STRIDE - http://msdn.microsoft.com/en-us/magazine/cc163519.aspx