Comp527 Final Project Weekly Report Nov 25

Detection & Sanitization of XSS

Jun Zheng (jz33)

Rice University

Overview

We are wrapping up our previous works and doing PPT now.  Some remaining issue is how to protect <b>, as previous report indicated.

Comp527 Final Project Weekly Report Nov 18

Detection & Sanitization of XSS

Jun Zheng (jz33)

Rice University

Overview

This week we made 2 progresses. One is from continuing study of OWASP[1][2], the other is from our simple Django 1.5.4 test app.

ESAPI on OWSAP

As our last report, OWSAP provides some interactive Django xss check page as well as a more strict escape rule called ESAPI. However, comparing to our Django test app, [2]’s results are not valid in Django 1.5.4. Currently, we contribute this to the version problem, although we are not sure which version of Django [2] is adopted, but generally we guess it is earlier from 1.5.4, since the xss protection failure of [2] (that is, the input XSS scripts actually work) is well proteced in our test app. We saw a more strict character escape rule in Django 1.5.4, as will talk in next secion.

On the other hand, ESAPI is very strict, which mean, it extends the basic “5 symbol escaping rules”[3] to escape more symbols. Their rule are basically based on “URL Encoding Reference”[4], that except alphabetics, all other symbols are escaped accordingly, for example:

: → =

( → (

This feature is quite similay to Django’s autoescaping rules in next section.

Autoescaping Reference in Django 1.5.4

We wrote our very simple app with Django’s amazing templete and rendering features. In the templete, a textfield is shown up, and after input some scripts, clicking submit, the scripts will be transferred to server side via “GET’. And in Django’s view, we use the built-in function “render”, to return the input scripts back to previous template.

We did not find the autoescaping reference on line, so we test on our test app. The rule we found is, except alphabetics, Django 1.5.4’s escape rule are applied to almost all other symbols on the keyboard except: * _ -. However, their code number is not same as “URL Encoding Reference”, to which we do not understand yet. A full list is in Appendix, where ‘u’ indicts ‘unchanged’.

So Is Django Invulnerable?

Hell no. In our test app, we simply input <b>, the following output strings are all turned to bold; we input <i>, the following output strings are all turned to italic style. So aren’t pointed brackets already escaped? Nope. If get the server side url, pointed brackets are escaped, but in the url of the template page, they are not. These kinda symbols are summarized in Appendix, with ‘v’ indicating their variable features.

Future Work

How could Django protect <b> like tags?

References:

[1] http://owasp-esapi-python-swingset.appspot.com/xss/esapi

[2] http://owasp-esapi-python-swingset.appspot.com/xss/django

[3] https://docs.djangoproject.com/en/dev/topics/templates/#automatic-html-escaping

[4] http://www.w3schools.com/tags/ref_urlencode.asp

Appendix:

Django 1.5.4 autoescaping references:

Comp527 Final Project Weekly Report Nov 11

Detection & Sanitization of XSS

Jun Zheng (jz33)

Rice University

Overview

Accidently, I found an interesting post [1] from OWASP discussing in detailes about several loopholes an XSS attack can make impact. So our implementation of XSS test finally finds a more concrete guideline. The post separate different genre of XSS as 5 “rules” for programmers, or equivalent to say, 5 possible XSS attack gateways. And as in their experiments, Django’s auto-escape might fail to protect last 3 kinds. Below is a more simplified categorization by the author, to especially talk for Django:

2 Levels

Level 1 is to insert untrusted javascript between html tags or as html attributes or style, like:

<td><script> UNTRUSTED </script></td>

<td class = “…” UNTRUSTED “…”></td>

<a style= “…” UNTRUSTED “… .”></a>

Comments: with the “<script></script>” it looks fairly common, on which I believe most web framework tutorials has pointed out to its programmers (also a precise list is not clear now), by simply escape:

> : &lt;

< : &gt;

‘ : ‘

“ : $quot;

Therefore the “<script></script>” is escaped. But without <script></script>, Django also makes decent work to escape executing of the javascript. We shall look into this in later work.

Level 2 is to insert untrusted javascript as part of the javascript, like:

<… onclick = “var v = ‘…’ UNTRUSTED ‘…‘”>

Comment: if the untrusted codes contain “<script></script>” tag, Django can still handle this by escape, but without “<script></script>”, Django’s auto-escape will fail. Then a manual escape is required here.

ESAPI

Surprisely, a mechanism called ESAPI from OWASP can handle all issues the Django cannot handle, but using more sophisticated escape references, to which our groups’s later work will focus on.

References:

[1] https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes

Comp527 Final Project Weekly Report

Detection & Sanitization of XSS

Jun Zheng (jz33) Chao Zhang (cz15)

Rice University

Overview

Our project goes slowly but steadily. For now, we are focusing on 2 aspects simutaneously.

Part I

On one side, our group is researching theories on XSS, that is, definition, significance, and more importantly, how common web frameworks (as currently selected, Django, GWT at least) support sanitization. [1][2] shows that mechanism on different frameworks varies a lot, but generally categories can be recorded according to 1) what language /expression (HTML, CSS, Javascript) is supported; 2) untrusted data separation; 3) auto sanitizaiton abilities (context-insensitive sanitization, context-sensitive sanitization, able to handle nested context, able to handle dynamic context); 4) placement of sanitizers

Part II

One the other side, our group is trying to design tiny web applications based on selected frameworks, in order to observe XSS attack. Current design are basically composed by 3 parts, a naive victim app (citizen), a randomized attacker (killer), a status estimator (judge). This part goes slowly, because neither of us has experiences on Django /GWT, but expecting result might be interesting that to see our own app is been killed by ourselves.

Reference

[1] Weinberger, J., et al., “A Systematic Analysis of XSS Sanitization in Web Application Frameworks”, Springer-Verlag Berlin Heidelberg 2011

[2] Weinberger, J., et al., “An Empirical Analysis of XSS Sanitization in Web Application Frameworks”, Technical Report No. UCB/EECS-2011-11

Comp527 Final Project Weekly Report

Detection & Sanitization of XSS

Jun Zheng (jz33) Chao Zhang (cz15)

Rice University

Overview

For now, our group focus on figuring out what exactly XSS is, why XSS defense is so significant and, which is more important, what kinds of challenges of XSS sanitization exist in real world industry.

Problem comes from XSS attack

XSS enables attackers to inject client-side script to Web pages viewed by other users. XSS may be used by attackers to bypass access controls such as the same origin policy.

An canonical example from A Systematic Analysis of XSS Sanitization in Web Application Frameworks, consider a blogging Web application emits untrusted content on the Web page. If some developer is not careful, an attacker can use text with <script> tag, which may be verbatim in the server’s output HTML page. As the result, when a user visits this blog page, the user’s Web browser will execute the attacker’s text as script code.

XSS defense

XSS sanitization’s responsibility is to remove dangerous contents from untrusted data.

Challenges of XSS sanitization

1. Context Sensitivity

Sanitization for XSS defense needs to know where untrusted contents appear in the Web application.

2. Nested Contexts

This situation occurs when a string in a Web application’s output can be parsed by multiple sub-parsers in a browser, so this kind of string is nested contexts.

3. Browser Transductions

Browsers can hand data from one sub-parser to another, this transduction can undo sanitization applied on the server.

4. Dynamic Code Evaluation

The chain of edges traversed by browser while parsing a text can be very long because the browser can dynamically evaluate code, so the untrusted content can keep looping through HTML and JavaScript contexts, the untrusted contents can not be determined statically.

5. Character-set Issues

Successfully sanitizing a string needs the sanitizer and browser have the same character-set.

6. Other challenges such as MIME-based XSS, Universal XSS and Mashup Confinement

These are related to sanitization defenses in Web frameworks, so not consider those in final project.

Reference:

[1] A Systematic Analysis of XSS Sanitization in Web Application Frameworks, Joel Weinberger, Prateek Saxena, Devdatta Akhawe, Matthew Finifter, Richard Shin, and Dawn Song

Comp527 Final Project Proposal 02

Detection & Sanitization of XSS

Jun Zheng (jz33) Chao Zhang (cz15)

Rice University

Introduction

Cross-site scripting (XSS) is a major computer security violation mostly found in web applications that allows an attacker injects malicious client side scripts, thus makes an impact to server as well as to the browser of other users. For instance, if a web page provides user a textfield to input, instead of typing in “plain” strings, the attacker could input Javascripts or CSS styless or DOMs. If this textfield is without sanitization it can typically results that, an attacker could via the executable codes, gain access privileges to some secrets of the server, or other important informations maintained by the browser on behalf of other users.

Major web application framework vendors provide mechanism or requirements in their products to protect XSS. For example, JSP requires programmer to add “fn:escapeXml()” right before a string that is intended to be plain text.[1] In Spring, programmer is able to set a parameter “defaultHtmlEscape”[2]. And in Django, XSS is protected by “Auto-sanitization”[3], on which mainly our team’s research focus. explore the protection mechanism (sanitization) against XSS in Django, focusing on.

Strategy

First, we do research on analysis of XSS attacks. 2 papers from Weinberger [4][5] made very deep research on this topic, and [6] also provides good summary of existing solutions. Second, as the time limit of this project, out team will mainly focus on Django’s Auto-sanitization mechanism, with its implementation, backend support, working scope, and limitations. Third, out team will design some assistant programs or plug-ins to detect or scan possible XSS attack codes. A good open source example is in [7].

References & Links:

[1] http://www.tutorialspoint.com/jsp/jstl_function_escapexml.htm

[2] http://stackoverflow.com/questions/9111105/spring-mvc-defaulthtmlescape-does-it-work-on-the-way-in-or-out

[3] https://docs.djangoproject.com/en/dev/topics/security/

[4] Weinberger, J., et al., “A Systematic Analysis of XSS Sanitization in Web Application Frameworks”, Springer-Verlag Berlin Heidelberg 2011

[5] Weinberger, J., et al., “An Empirical Analysis of XSS Sanitization in Web Application Frameworks”, Technical Report No. UCB/EECS-2011-11

[6] Bugeja, Joseph, “A PRAGMATIC POLICY-DRIVEN XSS PROTECTION FRAMEWORK ”, master thesis of Royal Holloway University of London, 2011

[7] https://github.com/stamparm/DSXS

Comp527 Final Project Proposal: Rich Text Editor Research

Group: Jun Zheng (jz33) Chao Zhang (cz15)

Category: Thing to go others

Date: Oct 05 2013

Introduction

Rich text, also known as formatted text, as opposed to plain text, has styling information beyond the minimum of semantic elements: colours, styles (boldface, italic), sizes, and special features (such as hyperlinks)[1]. A general rich text editor providing an interface to edit rich text which presents a “What You See is What You Get” (WYSIWYG)[2] tenet, can save the programmer from trivial HTML/CSS tags, attributes, values debugs. Several major browser manufactures provide free rich text editor

service, i.e., Google Forms[3], but not in open source regime. Moreover, several simple open source rich text editors lack of precaution to potential HTML riskes and maliciousness. Then our group’s work is to reseach on existed open source projects of rich text editor, analyze specifically on their possible security issues and try make improvement.

Strategy

First we will research on forms of potential HTML/CSS attacks and harms. Currenct topics are:

1. Invalid, unknown or deprecated(at HTML5) tags;

2. Inline styles;

3. Sandbox;

4. CSS risks

More paper research and thinking is needed at this step.

Second, we shall look into previous contributors and their commits in rich text editors. Currently we will look into source codes from GitHub, a social coding host site for open source programming

languages like Javascript, Python, PHP, etc. Our starting source code is on projects “xing/wysihtml5″[4] and “mindmup/bootstrap-wysiwyg”[5]. But later we might move to other projectes. We will make comments on each projects about protection mechanism and potential risks. We might generate limited malicious codes to test tolerance and durability of each projects

Third, we will combine previous inspirations to create our own rich text editor, with functions like converting input to html view and vice versa. Hopefully, our editor will also be capable to convert a risky html file into a safety htm file based on our judge.

References & Links:

[1] http://en.wikipedia.org/wiki/Formatted_text

[2] http://en.wikipedia.org/wiki/WYSIWYG

[3] https://chrome.google.com/webstore/detail/google-forms/jhknlonaankphkkbnmjdlpehkinifeeg

[4] https://github.com/xing/wysihtml5

[5] https://github.com/mindmup/bootstrap-wysiwyg