A stored cross-site scripting has been found in the image upload functionality that can be used by normal registered users: It is possible to upload a SVG image containing JavaScript and it's also possible to upload a HTML document when the format parameter is manually changed to documents or a string of an unsupported format. If an authenticated user or administrator visits that uploaded image or document malicious JavaScript can be executed on their behalf (e.g. changing or deleting content inside of the CMS.)
Proof of concept
Login as a normal user (if user signup is enabled).
Go to the user's profile.
And upload the following profile picture via drag and drop.
The content of the SVG file could be as follows (e.g. name it test-xss.svg):
<script type="text/javascript">
alert("This is an example of a stored XSS attack in an SVG image, here's the cookie: " + document.cookie);
</script>
The server might fail with a 500 internal server error, but the uploaded image should be available at a location like https:///media/1/test-xss-cookie.svg. If an authenticated user or administrator accesses that link their auth_token is reflected. Since the auth_token cookie contains a static [auth token](https://github.com/owen2345/camaleon-cms/blob/feccb96e542319ed608acd3a16fa5d92f13ede67/app/models/concerns/camaleon_cms/user_methods.rb#L18-L19) value that only changes when a user changes their password.
Impact
This issue may lead to account takeover due to reflected Cross-site scripting (XSS).
Remediation
Only allow the upload of safe files such as PNG, TXT and others or serve all "unsafe" files such as SVG and other files with a content-disposition: attachment header, which should prevent browsers from displaying them.
Additionally, a Content security policy (CSP) can be created that disallows inlined script. (Other parts of the application might need modification to continue functioning.)
To prevent the theft of the auth_token it could be marked with HttpOnly. This would however not prevent that actions could be performed as the authenticated user/administrator. Furthermore, it could make sense to use the authentication provided by Ruby on Rails, so that stolen tokens cannot be used anymore after some time.
References
texpert Analyst
A stored cross-site scripting has been found in the image upload functionality that can be used by normal registered users: It is possible to upload a SVG image containing JavaScript and it's also possible to upload a HTML document when the format parameter is manually changed to documents or a string of an unsupported format. If an authenticated user or administrator visits that uploaded image or document malicious JavaScript can be executed on their behalf (e.g. changing or deleting content inside of the CMS.)
Proof of concept
Login as a normal user (if user signup is enabled).
Go to the user's profile.
And upload the following profile picture via drag and drop.
The content of the SVG file could be as follows (e.g. name it test-xss.svg):
<script type="text/javascript"> alert("This is an example of a stored XSS attack in an SVG image, here's the cookie: " + document.cookie); </script> The server might fail with a 500 internal server error, but the uploaded image should be available at a location like https:///media/1/test-xss-cookie.svg. If an authenticated user or administrator accesses that link their auth_token is reflected. Since the auth_token cookie contains a static [auth token](https://github.com/owen2345/camaleon-cms/blob/feccb96e542319ed608acd3a16fa5d92f13ede67/app/models/concerns/camaleon_cms/user_methods.rb#L18-L19) value that only changes when a user changes their password.Impact
This issue may lead to account takeover due to reflected Cross-site scripting (XSS).
Remediation
Only allow the upload of safe files such as PNG, TXT and others or serve all "unsafe" files such as SVG and other files with a content-disposition: attachment header, which should prevent browsers from displaying them.
Additionally, a Content security policy (CSP) can be created that disallows inlined script. (Other parts of the application might need modification to continue functioning.)
To prevent the theft of the auth_token it could be marked with HttpOnly. This would however not prevent that actions could be performed as the authenticated user/administrator. Furthermore, it could make sense to use the authentication provided by Ruby on Rails, so that stolen tokens cannot be used anymore after some time.
References