Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Self-attack vulnerabilities] possibilities/list #57

robiso opened this issue Feb 8, 2018 · 5 comments

[Self-attack vulnerabilities] possibilities/list #57

robiso opened this issue Feb 8, 2018 · 5 comments


Copy link

@robiso robiso commented Feb 8, 2018

The bugs below work only if an admin is logged and is tricked into pasting JavaScript code or uploading SVG's

WonderCMS comes with some security features and some responsibilities.

1. A logged-in user (admin) can execute JavaScript anywhere on their website.

  • This has always been a WonderCMS feature.
  • I personally don't consider this needs fixing, since a logged-in admin can do much more damage than just XSS attacks (including website defacement, malware distribution, cryptominers, ...)

2. A logged in user can upload a SVG (containing code other than an image, such as JavaScript).

  • SVG's are generally not just images, they can also include code such as JavaScript, XML, these are awesome features of SVG's.
  • Sanitizing SVG's would partially kill their functionality.
  • If there are enough wishes for this action, the SVG uploading functionality can be completely removed from WonderCMS.
  • If we already allow JavaScript to be executed at any part of the CMS, would removing the SVG functionality make any difference?

3. Host header attack.

  • This will not be considered a vulnerability until we see a live exploit of this (not local).
  • Using the Burp Suite Tool to create/show a local attack is not enough, since there needs to be a way to exploit a WonderCMS installation (and not just locally attack one-self).

How to prevent self-attack vulnerabilities

  • Avoid pasting random JavaScript code.
  • Avoid uploading random SVG's.
    - Install themes and plugins only from

The list above is subject to change. All discussions are welcome.
Reporting the above issues/bugs/vulnerabilities will not include you in the WonderCMS reward system.

Copy link
Owner Author

@robiso robiso commented Feb 14, 2018

I'm trying to think of a reason to counter myself and ask should we remove SVG uploading functionality and why?

  • even if we remove SVG uploading, users can still INLINE SVG's with HTML, which is a good thing
  • this way we can prevent users being "tricked" into uploading malicious SVG's onto their site, since they can't see the SVG content (if someone tricks them).

Please share your opinion on this topic.
TLDR: Remove SVG uploading or not? (even if we remove it, users can inline SVG's)

  • please note we would be still supporting executing JavaScript in any part of WonderCMS as we already do.
Copy link
Owner Author

@robiso robiso commented Feb 15, 2018

Added additional warning for uploading SVG's on the WonderCMS download page.

Here's the safety tips:
5 safety tips to avoid being hacked

  • Change the default password and default login URL immediately.
  • Install themes and plugins only from this website.
  • Regularly update WonderCMS. Always create backups.
  • WonderCMS supports running JavaScript anywhere. Be careful not to paste random/malicious JavaScript code.
  • WonderCMS supports uploading SVG's which could also contain JavaScript code. Don't get tricked into uploading malicious SVG's. If in doubt, avoid uploading any SVG file extension.
@robiso robiso changed the title [Don't report "self-admin vulnerabilities"] [Don't report "self-attack vulnerabilities"] Apr 22, 2018
This was referenced Aug 17, 2018
@robiso robiso changed the title [Don't report "self-attack vulnerabilities"] ["Self-attack vulnerabilities"] Jan 4, 2019
Copy link

@NicolasCARPi NicolasCARPi commented Jan 4, 2019

Change the default password and default login URL immediately.

Better: generate a random password from start so in the (likely) event that the user doesn't change the password, it's different on all installs.

Copy link
Owner Author

@robiso robiso commented Jan 4, 2019

@NicolasCARPi since WonderCMS doesn't pick up the users email, we would still have to display the password on the users home page.

This would however prevent any automated attacks with the default password.

@robiso robiso changed the title ["Self-attack vulnerabilities"] [Self-attack vulnerabilities] possibilities/list Jan 2, 2020
Copy link
Owner Author

@robiso robiso commented Feb 10, 2020

@robiso robiso closed this Feb 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants