Summary
Improper sanitization of postContent
when submitting POST requests to /createpost
leads to arbitrary JavaScript execution (XSS) on all pages the post is reflected on including /
, /post/[ID]
, /admin/posts
, and /user/[ID]
of the user that made the post.
Details
Line 22 of the postCardMacro.html
template and line 27 of the dashboard.html
template contain the safe
directive ({{ post[3]|safe }}
) meaning HTML symbols are not escaped as they are in other variables. This is likely to be able to render text features from the post editor in /createpost
. When submitting the /createpost
form, the postContent
variable is sanitized client-side (e.g. <script>
is escaped to <script>
), however this can be modified by intercepting the request and replacing the postContent
with unescaped JavaScript code. This will be stored in the database without any sanitization on the server side (read in at line 42 of createPost.py
: postContent = request.form["postContent"]
and stored in the database in line 61 cursor.execute(insert into posts(...))
).
A previous issue listed several XSS vulnerabilities which were fixed with this PR by setting app.jinja_options["autoescape"] = True
. This vulnerability exists despite this fix.
PoC
- Login as a user
- Create a post using
/createpost
but intercept the POST request
- Modify the
postContent
form-data parameter to include <script>alert('XSS')</script>
- Browse to any page featuring the post (
/
, /post/[ID]
, /admin/posts
, or /user/[ID]
) and observe the JavaScript pop-up
Impact
An attacker can execute JavaScript in the browser of any user that views a page featuring the post. In some cases this could be used to steal sensitive user data or deface the website.
Summary
Improper sanitization of
postContent
when submitting POST requests to/createpost
leads to arbitrary JavaScript execution (XSS) on all pages the post is reflected on including/
,/post/[ID]
,/admin/posts
, and/user/[ID]
of the user that made the post.Details
Line 22 of the
postCardMacro.html
template and line 27 of thedashboard.html
template contain thesafe
directive ({{ post[3]|safe }}
) meaning HTML symbols are not escaped as they are in other variables. This is likely to be able to render text features from the post editor in/createpost
. When submitting the/createpost
form, thepostContent
variable is sanitized client-side (e.g.<script>
is escaped to<script>
), however this can be modified by intercepting the request and replacing thepostContent
with unescaped JavaScript code. This will be stored in the database without any sanitization on the server side (read in at line 42 ofcreatePost.py
:postContent = request.form["postContent"]
and stored in the database in line 61cursor.execute(insert into posts(...))
).A previous issue listed several XSS vulnerabilities which were fixed with this PR by setting
app.jinja_options["autoescape"] = True
. This vulnerability exists despite this fix.PoC
/createpost
but intercept the POST requestpostContent
form-data parameter to include<script>alert('XSS')</script>
/
,/post/[ID]
,/admin/posts
, or/user/[ID]
) and observe the JavaScript pop-upImpact
An attacker can execute JavaScript in the browser of any user that views a page featuring the post. In some cases this could be used to steal sensitive user data or deface the website.