Santos Gallegos (Posts about django)

XSS in django-impersonate 1.9.3 and django-gravatar2 1.4.4

Santos Gallegos — Sat, 08 Feb 2025 05:00:00 GMT

This post details two cross-site scripting (XSS) vulnerabilities I discovered in django-impersonate, and django-gravatar2. I'm writing about them together because they share the same vulnerability, and are similar in other aspects that I'll explain below.

Background

At Read the Docs, we use both packages. While waiting for my PRs to be reviewed, and taking a break from coding, I decided to do a quick security audit of some of our dependencies, since both packages have a relatively small codebase, they were good candidates for a quick review.

django-impersonate

django-impersonate allows you to impersonate other users, really useful for debugging and support.

The vulnerability

After grepping the codebase for common vulnerable patterns, I found this line of code that caught my attention:

def get_redir_field(request):
    redirect_field_name = settings.REDIRECT_FIELD_NAME
    if redirect_field_name:
        nextval = request.GET.get(redirect_field_name, None)
        if nextval:
            return mark_safe(
               u'<input type="hidden" name="{0}" value="{1}"/>'.format(
                  redirect_field_name, nextval,
               )
            )
    return u''

You can see that the application is building an HTML input field with the value of a query parameter (if the IMPERSONATE["REDIRECT_FIELD_NAME"] setting is defined), and marking it as safe with mark_safe (Django won't escape it when including it in a template). The problem arises as the query parameter is controlled by the user, and isn't escaped before being included in the string.

Exploitation

Searching for the usage of the get_redir_field function, I found it was used in two views related to listing users:

But only the template rendered from the search_users view includes the result of the function.

# impersonate/views.py (search_users)
return render(
    request,
    template,
    {
        'users': users,
        'paginator': paginator,
        'page': page,
        'page_number': page_number,
        'query': query,
        'redirect': get_redir_arg(request),
        'redirect_field': get_redir_field(request),
    },
)

<!-- impersonate/templates/impersonate/search_users.html -->
<form action="{% url 'impersonate-search' %}" method="GET">
   Enter Search Query:<br />
   <input type="text" name="q" value="{% if query %}{{ query }}{% endif %}"><br />
   {{redirect_field}}
   <input type="submit" value="Search"><br />
</form>

Assuming the application defined the IMPERSONATE["REDIRECT_FIELD_NAME"] setting as next, the URL used to exploit the vulnerability would be /impersonate/search/?next={payload}. Where {payload} can be:

"/><script>alert(document.domain)</script><input type="hidden

What this does is:

Uses a "/> to close the input tag.
Injects a script that shows an alert with the current domain.
Opens a new tag so the rest of the HTML is not shown as broken.

The payload injected into the template would look like this:

<input type="hidden" name="next" value="">
<script>alert(document.domain)</script>
<input type="hidden"/>

Proof of concept

I created a proof of concept to demonstrate the vulnerability, so you can see it in action, you just need to have Python and uv installed:

It consists of a simple Django project with django-impersonate==1.9.3 installed, with the IMPERSONATE["REDIRECT_FIELD_NAME"] setting defined as next.

$ git clone https://github.com/stsewd/poc-xss-django-impersonate
$ cd poc-xss-django-impersonate
$ uv run manage.py migrate
# Create a user to log into the application.
$ uv run manage.py createsuperuser
$ uv run manage.py runserver

Go to http://127.0.0.1:8000/admin/login/
Log in with the user you created
Go to http://127.0.0.1:8000/impersonate/search/?next=?next="><script>alert(document.domain)</script><input type="hidden
A pop-up with the domain of the page should appear

Showing an alert is just a simple example, but an attacker can execute any JavaScript code in the context of the user's session.

Mitigation

You should never use mark_safe with user-controlled content, if you need to build HTML with user-controlled data outside of a template, you can use the format_html function, as you can see in the two commits that fixed the vulnerability: 06991a735f29, 33cb8c77262a.

Timeline

11/06/2024: Found and reported the vulnerability to the maintainer.
13/06/2024: Maintainer replied and confirmed the vulnerability.
14/06/2024: Maintainer released version 1.9.4 with the fix.

django-gravatar2

django-gravatar2 allows you to integrate Gravatar in your project, so you can show the user's avatar based on their email.

The vulnerability

After grepping the codebase for common vulnerable patterns, I found this code that caught my attention:

You can see that the application is building an HTML img tag with several attributes, like CSS class, alt text, size, and the URL of the Gravatar image, and marking it as safe with mark_safe (Django won't escape it when including it in a template). Of all these attributes, only the URL is being escaped, all other values are used as is.

I found that the function is used as a template tag to render the Gravatar image:

For example, you can use it in a template like this:

{% load gravatar from gravatar %}

{% gravatar user 50 "User profile" %}

In this example, the size and the alt text are hardcoded, so there is no way for an attacker to inject arbitrary HTML. But what happens if the size or alt text come from the user? Then we have a problem, as the values are not escaped before being included in the template.

{% load gravatar from gravatar %}

{% gravatar user 50 user.name %}

Exploitation

Since the vulnerability is in a template tag, exploiting the vulnerability will depend if the application uses the template tag with user-controlled content. We can assume that a common alt text is the user's name.

{% load gravatar from gravatar %}

{% gravatar user 50 user.first_name %}

Then the attacker can inject the payload in the user's name. A simple payload could be:

"/><script>alert(document.domain)</script><img src="

What this does is:

Uses a "/> to close the img tag.
Injects a script that shows an alert with the current domain.
Opens a new tag so the rest of the HTML is not shown as broken.

The payload injected into the template would look like this:

<img class="gravatar" src="https://www.gravatar.com/" width="50" height="50" alt=""/>
<script>alert(document.domain)</script>
<img src="" />

But that's very similar to the previous example, so let's assume that the application uses the user's email as the alt text instead.

{% load gravatar from gravatar %}

{% gravatar user 50 user.email %}

You may think that's the same as the previous example, but now the payload needs to be a valid email. And if you try to create an email with the previous payload, it won't work, as the Django user model will validate the email format.

Making the payload a valid email is not as simple as just adding @example.com at the end, as the part before the @ (local part) can't contain special characters like "<>(), which are part of the payload.

Luckily, the spec says that the local part can contain any ASCII characters if it's quoted, and coincidentally, our payload has already quotes around it, so it's just a matter adding @example.com at the end! Or almost... Django's email validator does allow the local part to be quoted, but it doesn't allow spaces, luckily HTML is very forgiving, so we can add almost anything instead of the spaces, and our payload will still work

"/><script>alert(document.domain)</script><img/src="@example.com

You could also leave the tag unclosed, but that will break the rest of the HTML in the template.

"/><script>alert(document.domain)</script>"@example.com

Proof of concept

I created a proof of concept to demonstrate the vulnerability, so you can see it in action, you just need to have Python and uv installed:

It consists of a simple Django project with django-gravatar2==1.4.4 installed, it shows the Gravatar of a user given its email.

$ git clone https://github.com/stsewd/poc-xss-django-gravatar2
$ cd poc-xss-django-gravatar2
$ uv run manage.py migrate
$ uv run manage.py runserver

Go to http://127.0.0.1:8000/
In the form enter "/><script>alert(document.domain)</script><img src=" as the name, or "/><script>alert(document.domain)</script><img/src="@example.com as the email.
Click on the "Submit" button.
A pop-up with the domain of the page should appear.

Showing an alert is just a simple example, but an attacker can execute any JavaScript code in the context of the user's session.

Mitigation

As the previous vulnerability, you should never use mark_safe with user-controlled content, if you need to build HTML with user-controlled data outside of a template, you can use the format_html function.

Timeline

21/06/2024: Found and reported the vulnerability to the maintainer.
21/06/2024: Maintainer replied and confirmed the vulnerability.
29/08/2024: Maintainer released version 1.4.5 with the fix.

More in common than you think

Apart from sharing the same vulnerability, there are other similarities between the two packages:

Widely used packages. At the time of writing, django-impersonate had 220K downloads in the last month, and django-gravatar2 had 32K downloads in the last month.
Mostly maintained by a single person.
Not actively maintained.

While the functionality that both packages provide is very specific, they may be considered complete and stable without the need for active development. But as with any software, there is always room for improvement, or updates to keep up with the latest versions of Python and Django.

If you or your company use these packages, please consider contributing to them in any way you can. Another thing these packages have in common is that they are looking for maintainers, so if you have the time and knowledge, consider helping them.

Acknowledgements

Thanks to Peter Sanchez (maintainer of django-impersonate), and Tristan Waddington (maintainer of django-gravatar2) for their quick responses and fixes.
It's also great I have the support at Read the Docs to spend part of my work time on security audits on packages we use. Even if the vulnerabilities don't affect our systems directly, it's nice to have the chance to give back to the community.

XSS in django-allauth 0.63.5

Santos Gallegos — Sun, 19 Jan 2025 05:00:00 GMT

This post details a Cross-Site Scripting (XSS) vulnerability I discovered in django-allauth, a popular Django package for authentication. This vulnerability affected the Facebook provider only, and it was fixed in version 0.63.6 on July 12, 2024.

Background

Before I found this vulnerability, I already reported another one to django-allauth, a login CSRF vulnerability in its SAML provider, which was fixed in version 0.63.3 (maybe I'll write a post about it if people are interested in more posts like this).

At Read the Docs, we use django-allauth for user authentication. I was in charge of integrating SAML into our authentication system, while working on that I noticed the CSRF vulnerability. After reporting it and seeing how quick it was fixed, I decided to do a quick security audit of the project.

The vulnerability

After grepping the codebase for common vulnerable patterns, I found this line of code that caught my attention:

django-allauth allows using Facebook as a provider for social authentication, and allows using the regular form (oauth2 method) or the Facebook JavaScript SDK (js_sdk method) to login. When using the js_sdk method, the fb_data variable is passed to the template to be used in the frontend.

Which is then used in the fbconnect.js script to initialize the Facebook SDK.

So, what's the problem here? The fb_data variable is marked as safe (Django won't escape it when including it in a template) after being transformed into a JSON string. Since json.dumps doesn't escape HTML characters, it's possible to inject arbitrary HTML and JavaScript code into the template.

Exploitation

Using mark_safe by itself is not a vulnerability, as long as the content is trusted and doesn't contain user input. So the next step was to find a way to inject user-controlled content into the fb_data variable.

As shown below, most of the content in the fb_data variable is static:

Except for loginOptions, which includes the value from the scope query parameter:

With that, we now can inject arbitrary HTML and JavaScript using the scope query parameter.

But wait... In which page can we control the scope query parameter? By following the code, I found that media_js is used in the providers_media_js template tag, which is called in the login_extra.html snippet, and furthermore that snippet is included anywhere the social providers are listed, like the login page (/accounts/login/), and the social account connections page (/accounts/3rdparty/).

Payload

To exploit this vulnerability, an attacker could inject the following content in the scope query parameter:

</script><script>alert(document.domain)</script><script>

What this does is:

Closes the script tag containing the fb_data variable.
Injects a script that shows an alert with the current domain.
Opens a new script tag, so the rest of the JSON content is not shown as plain text.

Proof of concept

I created a proof of concept to demonstrate the vulnerability, so you can see it in action, you just need to have Python and uv installed:

It consists of a simple Django project with django-allauth==0.63.5 installed, and a Facebook provider configured using the JavaScript SDK.

$ git clone https://github.com/stsewd/poc-xss-django-allauth
$ cd poc-xss-django-allauth
$ uv run manage.py migrate
# Create a user to log into the application.
$ uv run manage.py createsuperuser
$ uv run manage.py runserver

XSS in login page:

While logged out, go to http://127.0.0.1:8000/accounts/login/?scope=</script><script>alert(document.domain)</script><script>.

XSS in social connections page:

Go to http://127.0.0.1:8000/accounts/login/.
Log in with the user you created.
Go to http://127.0.0.1:8000/accounts/3rdparty/?scope=</script><script>alert(document.domain)</script><script>.

Showing an alert is just a simple example, but an attacker can execute any JavaScript code in the context of the user's session.

Mitigation

You should never mark user-controlled content as safe, but if you find yourself wanting to include JSON content in a template, escaping will break the JSON format.

Luckily, Django has a built-in template filter to include JSON content in a template safely, json_script. Sadly, that filter wasn't available at the moment the allauth code was written, but it's been available since Django 2.1, since allauth supports newer versions of Django, it was possible to use it, as you can see in the fix.

Timeline

11/07/2024: Found and reported the vulnerability to django-allauth.
12/07/2024: Maintainer confirmed the vulnerability and released version 0.63.6 with the fix.

Acknowledgements

I'm always surprised by how quickly open source maintainers fix security vulnerabilities (so much faster than commercial software vendors), kudos to Raymond Penners, maintainer of django-allauth.
It's also great I have the support at Read the Docs to spend part of my work time on security audits on packages we use. Even if the vulnerabilities don't affect our systems directly (we don't use the Facebook provider), it's nice to have the chance to give back to the community.

Are you still using django-allauth <0.63.6? The fix was released more than 6 months ago, please update your dependencies! Thank you for reading, and let me know if you'd like to see more posts like this!