User:Navdeep Bagga/Proposal

Name: Navdeep Bagga Email Address: admin@navdeepbagga.com IRC Username: navdeep Blog: http://navdeepbagga.com Location: Ludhiana, Punjab, India Timezone: GMT + 5:30 Reference: I got to know about OPW from my friend, Harmanpreet Singh, 2013 GSoC student.

Project Title: Implement whitelist functionality in CSS Extension

Mentor: Rusty Burchfield 

Project Overview:

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 an XSS attack. To prevent from such XSS, there is already implemented a blacklist functionality which block various XSS attacks. 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/unknown XSS attack is done. A better problem solving approach will be implementing a whitelist, which only allows the CSS properties and values (with help of regular expressions) which is whitelisted.

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:

Goal of this project is to replace the blacklist functionality with whitelist functionality to prevent XSS in the CSS extension. Goal of this project is incomplete without a good css parser, which I will find, and use it accordingly. These both parts will be combined as a standalone application, and later will be integrated into the CSS Extension.

Implementation:

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

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 his browser and executed. However all XSS attacks follow this pattern, which is depicted in the diagram below.

A few examples:

[1] Malicious CSS 

When CSS parser will read the background URL, we can set whitelist on *.jpg, *.png Just to ensure if url is actually an image and whitelist functionality will only allow specific image format, and remove any unnecessary thing. Similarly more whitelists can be set.

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

Click on the link to follow me: 

CLICK ME!

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.

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: 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: 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.

Content Security Policy is used to prevent ClickJacking (UI redress). X-Frame-Options ( also known as XFO ) can also be used to defend this attack.

Milestones:

10 Dec - 19 Dec Find, review and test various CSS parsers available. Get know about their capability and to find how they can fit in our project. 20 Dec - 5 Jan Implement CSS XSS whitelist input validation script with the selected CSS parser. 6 Jan - 12 Jan Generalize the whitelist functionality so it is easy to add new whitelists and use more than one whitelist at once. 13 Jan - 25 Jan Implement an additional whitelist script that prevents UI redress attacks. 26 Jan - 15 Feb Merge both whitelist functionality with CSS parser into the CSS Extension. 16 Feb - 28 Feb Fixing bugs, Testing. 1 Mar - 10 Mar Start documentation (using LaTeX or any other tool recommended) including developers documentation, user’s documentation.

Time Availability:

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