User:Navdeep Bagga/Proposal

From mediawiki.org

Contact Information[edit]

Name: Navdeep Bagga
Email Address: admin@navdeepbagga.com
IRC Username: navdeep / navdeep_
Blog: http://navdeepbagga.com
Location: Ludhiana, Punjab, India
Timezone: GMT + 5:30

Project Overview[edit]

Project Title[edit]

Implement whitelist functionality in CSS Extension.

Project Mentor[edit]

Rusty Burchfield <GICodeWarrior@gmail.com>

Project Description[edit]

Currently, CSS extension allow users to use their own custom CSS to be embedded into wiki pages. On client side, with help of CSS attributes, some malicious code can be injected, which we call XSS attack. To prevent from such attacks, a blacklist functionality is already implemented that block various XSS attacks. But the problem with blacklist functionality is that, it is quite fragile. We cannot block each and every XSS attack by blacklisting it, because our blacklist functionality fails when a new or unknown XSS attack occurs. A better problem solving approach would be implement a whitelist, which only allows the whitelisted CSS properties and values (with help of regular expressions).

I would prefer to use “MediaWikiPerformAction” or any other similar hook (as suggested). By doing so, we may able to do CSS caching in a better and efficient way, at the MediaWiki core. Another important thing here is, to minimize the use of JavaScript and getting most of the control on the back-end. Such approach will also help us in preventing ClickJacking.

Goal[edit]

Goal of this project is to replace the blacklist functionality with whitelist functionality to prevent XSS in the CSS extension. But it is incomplete without a good CSS parser, which is needed to be found out, and implement accordingly. Both of these (whitelist and CSS parser) will be combined as a standalone application, and later will be integrated into the CSS Extension.

Implementation[edit]

1. Find, review, and test various CSS parsers available. For example,
https://github.com/sabberworm/PHP-CSS-Parser.
http://www.phpclasses.org/package/1289-PHP-CSS-parser-class.html
http://csstidy.sourceforge.net/
2. Select a suitable CSS parser on the basis of time, available features and scope of customizability.
3. Implement a standalone CSS whitelist script with chosen CSS Parser.
4. Once approved by mentor, merge CSS parser into the CSS Extension. CSS will be loaded with help of mediawiki core hooks. For instance, “MediaWikiPerformAction” or similar.
5. Generalize the whitelist functionality so as to make it is easy to use with new rules and conditions in the whitelists.
6. Implement an additional whitelist feature that prevents UI redress attacks (also known as ClickJacking).

In XSS attack, the hacker infects a web page with his malicious client-side script. When a user visits that web page the script is downloaded to user’s system and executed. Same is depicted in the diagram below.

Few examples:

Malicious CSS[edit]

{{#css:
body {
    background-image: url(javascript:alert('XSS ATTACK WORKS!'));</br>
    font-size: 20pt;</nowiki></br>
    color: red;</nowiki></br>
  }
}}</nowiki>

This shows an example of XSS attack in css, exactly in the syntax of mediawiki’s ‘CSS Extension’.

Clickjacking[edit]

Example 1

<a style="pointer-events:none;position:absolute;">
<a style="position:absolute;" onclick="alert(1);">
XXX
</a>
</a>
<a href="javascript:alert(2)">
XXX
</a>

It displays another “a” tag in the “a” tag, which holds the “pointer-events” property. The nested links ensures an alert window that will appear with the value “1” by clicking on the “XXX” link and thus the feature of “pointer-events” breaks. This example illustrates that “a” tags should not be used with the pointer-event logic which may lead to clickJacking.
To solve this problem, whitelist will be very helpful because properties like position absolute will not be whitelisted so, they will be automatically discarded by the parser.

Example 2

<style>
iframe {
  width:300px;
  height:100px;
  position:absolute;
  top:0; left:0;
  filter:alpha(opacity=50); /* in real life opacity=0 */
  opacity:0.5;
}
</style>

<div>Click on the link to follow me:</div>
<iframe src="http://clickJacked.com"></iframe>
<a href="http://twitter.com" target="_blank" style="position:relative;left:20px;z-index:-1">CLICK ME!</a>

In this example, user will try to follow some person, but a transparent button over the follow link works and does not let user to reach the actual link. X-Frame-Options ( also known as XFO ) can be used to defend this attack.

The best protection for XSS is a combination of "whitelist" validation of all incoming data and appropriate encoding of all output data. Validation allows the detection of attacks, and encoding prevents any successful script injection from running in the browser.

Whitelist input validation[edit]

Use a standard input validation mechanism to validate all input data for length, type, syntax, and business rules before accepting the data to be displayed or stored.

Strong output encoding[edit]

Ensure that all user-supplied data is appropriately entity encoded before rendering, taking the approach to encode all characters other than a very limited subset. For example, ‘>’ is encoded as &gt; Unless you want to close some tag.

Delivery Schedule[edit]

Schedule Milestones
10 Dec - 14 Dec Find, review and test various CSS parsers available.

Get know about their capability and to find how they can fit in our project.

15 Dec - 22 Dec Search and implement a standalone CSS whitelist script with CSS Parser.
23 Dec - 27 Dec Test a standalone application with respect to different cases.
28 Dec - 15 Jan Understand the working of CSS Extension, Merge CSS Parser into the CSS Extension.
16 Jan - 25 Jan Test the work done, find and fix bugs.
26 Jan - 31 Jan Generalize the whitelist functionality so it is easy to use with new rules and conditions in the whitelists.
1 Feb - 7 Feb Implement an additional whitelist script that prevents UI redress attacks.
8 Feb -28 Feb Finding and fixing bugs (Along with various tests of XSS attempts).
1 Mar - 10 Mar Start documentation (using LaTeX or any other tool recommended) including developers documentation and user’s documentation.

Time Availability[edit]

I will be available 40 hours / week, if needed can spend more. No restriction of time.

About Me[edit]

I graduated in Computer Science & Engineering this year from Guru Nanak Dev Engineering College, Ludhiana, Punjab, India. Currently, I am doing freelancing used to work on real world web development projects that keeps on enhancing my technical skills. My interests are mainly in Database driven applications. I am blessed with great power of being dreamed about programs.
Skills : HTML, CSS, JavaScript, PHP, MySQL and strong Object Oriented & MVC (Model View Controller) concepts.
Various other technologies that I worked with are: APIs, LaTeX, LDAP, Git, DOxygen, Secure shell access (SSH), LimeSurvey, Kannel.

Mediawiki[edit]

As a User[edit]

I like mediawiki from the first day when I installed it. Its 5 step installation wonders me how good the installation guide is and how easy to install it. After when I chose CSS Extension as my project, I downloaded and installed it very smoothly.

As a Contributor[edit]

I became an IRC fan. As I am noob to mediawiki, my questions are answered very quickly which helps me a lot in solve bug and obviously patch submission process(gerrit). I easily understood the CSS Extension code by reading developer’s guide in which tutorials on how to develop Mediawiki extension and came to know about default files and functionality.

My Open Source Experience[edit]

I was assigned with following microtask ( by mentor ), in which I had to fix CSS of category tree according to the vector layout of sidebar.

Link to the bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=41859

Patch submitted to gerrit:
https://gerrit.wikimedia.org/r/#/c/94099/