Comp527 Final Project Weekly Report Nov 18
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:
