XSS Injection from parameters

1

Hi there, I’m facing some XSS vulnerabilities when using parameters.

Please consider this code inside a twig file:

{% if uri.query('foobar') %}
    <a href="{{ 'http://www.google.co.uk/' ~ uri.query('foobar') }}">Link</a>
{% endif %}

Then I’m reaching my page using the following URL:

https://www.mysite.com/fr?foobar=x"><svg onload="alert('hi')">

This actually generate the following code (see screenshot) and fires the JavaScript alert.

05
Screen Shot 2017-12-11 at 13.44.05.png822×106 12 KB

It can be tested with Grav v1.3.7 and Firefox v57, I’m on Mac. This doesn’t seems to happen in Chrome has Chrome stops the load of the page:
"Chrome detected unusual code on this page and blocked it to protect your personal information (for example, passwords, phone numbers, and credit cards). ERR_BLOCKED_BY_XSS_AUDITOR"

Solution:
I found that using a Twig escape filter solves the issue but that’s not convenient.

Is it something Grav knows about and should be fixed on the uri.query API root or do I have to find my own solution for that?

Thanks

2

I can’t replicate this on any browser including an older browser based on Firefox 56. I’ve tried Grav 1.3.7 as well as latest, no popups at all.

3

Hi rhuk,

I just downloaded the last version of Grav (v1.3.10) and I was able to reproduce on Firefox v57. I’m on OSX El Capitan v10.11.6:

10
Screen Shot 2017-12-13 at 10.06.10.png2032×1289 388 KB

You can find here a zip with the archive to reproduce the problem: https://we.tl/OICYYGRDSJ
I simply created a new page folder called foobar and created a template file called foobar.html.twig where I added the following code:

{% extends 'partials/base.html.twig' %}

{% block content %}

    <div>
        {% if uri.query('myquery') %}
            <a href="{{ 'http://www.google.co.uk/' ~ uri.query('myquery') }}">Link</a>
        {% endif %}
    </div>

{% endblock %}

To reproduce the problem, open Firefox v57 and fetch the following URL:
http://localhost/grav/foobar?myquery=x"><svg onload="alert('hi')">

Thanks

4

OK, now I follow you. So this is not actually an XSS issue in Grav itself, it’s more of a developer awareness that you need to be aware of when creating custom Twig.

Some points:

  1. Grav is not forcing escaping on the frontend. This is primarily because when we started Grav, we figured that Twig templates were something that a developer would put together, and in this case (just like in PHP logic), the developer would be aware and smart enough to filter things that need escaping.

  2. After the initial release of Grav, we actually thought it would be a good safety feature to force escaping in Twig, however, there never was a good point to do this because it would definitely break sites. We have identified Grav 2.0 as a good point to switch over to automatic escaping, however, this is not a simple toggle as it would break things in places and needs extensive testing.

  3. You can actually enable this yourself if you wish, but you are going to have to update any Twig that outputs stuff incorrectly. You will probably have to use |raw filter in places where you are expecting special chars but don’t get it. In system.yaml set:

twig:
 autoescape: true
1 Like
5

All right, it’s the answer I needed - wasn’t sure yet if it was something we had to do as developers or a Grav issue, thank you!