XSS & XML entity expansion attack using via svg file (XML rendering) in File uploads

[rishaldwivedi]

Step to reproduce -

• Upload (http://localhost/GetSimpleCMS-master/admin/upload.php) the malicious svg file & browse though, XSS & XML entity expansion attack( lead to DOS) would be reproduced.

[tablatronix]

Mitigation , maybe filter svg uploads for malicous content.

[rishaldwivedi]

All the best with that, not sure if blacklist approach would be fair enough. SVG provides a lot of flexibility to an attacker.

Below are the possible workarounds:

• Don’t allow SVG
• Allow SVG submissions but don’t display them, just allow them to be downloaded
• Strip out dangerous stuff from the SVG before displaying. (Be careful to catch everything)
• Convert to a different image format before displaying, eg PNG or JPEG.

Ref: https://www.grepular.com/Scalable_Vector_Graphics_and_XSS

Also attaching the POC files used. xss & xxe.zip

[bigin]

Just my opinion, it has only a low potential vulnerability:

1. You need admin rights to upload SVG file.
2. Embedding SVG via <img> "should" be harmless.

It should be clear to everyone in the meantime that SVG are not just pictures but small applications.

Apart from upload SVG there are other ways for admins to execute "potential" dangerous code: eval() create_function() assert() include() require() etc ... or just another dumb coding in components or template editor, should these all options be forbidden now?

If you do not want that in the core, there should be at least one way to enable SVG support again, maybe a config variable with a note?

Personally, I see not really urgent need for action here, but that's just my opinion.

[tablatronix]

No but making some things default prohibited and requiring that the end user explicitly enables it and understands the risks might be useful. They can also implement their own protections as needed.

This is a good idea to remove svg from our whitelist.

[rishaldwivedi]

@bigin Rightly pointed by you it has only a low potential vulnerability, as it will be requiring some quality social engineering to make the file be available on the server.

• When talking about template editor, do you imagine fooling an admin to make code level changes by tricking them?. Instead tricking them upload a file, which may seem legit to them (but secretly hiding some malicious payload inside) is still viable.

• Coming to another scenario, what if someone goes forward to customize the application by adding more user groups to it?. Few having access to upload functionality, but restrictions to admin related functionalities. Critical right?.

These kind of attack scenarios never end. So my opinion comes in like getting rid of these kind of low vulnerabilities is what makes a secure application, giving no way for an attacker to get in.

Embedding SVG via "should" be harmless.

Sounds incomplete!, at the end of the day the svg file still resides & can be accessed directly. To make it complete, force download the file when accessed directly.

[rishaldwivedi]

@tablatronix Fair enough, but why not force download it?.

[tablatronix]

Force download how, thats a hosting mime configuration.

I mean we can htaccess something, but that does not cover all hosts and can break stuff on hosts with strict override rules.

[bigin]

@rishaldwivedi

• When talking about template editor, do you imagine fooling an admin to make code level changes by >tricking them?. Instead tricking them upload a file, which may seem legit to them (but secretly hiding >some malicious payload inside) is still viable.

• Coming to another scenario, what if someone goes forward to customize the application by adding >more user groups to it?. Few having access to upload functionality, but restrictions to admin related functionalities. Critical >right?

Agree, what about a simple url? A url looks even more harmless, if no upload is allowed, an SVG can still be added:

<embed type="image/svg+xml" src="https://foooo.com/image.svg" /> or <iframe src="https://foooo.com/image.svg"></iframe>

Tell me how can this be prevented if admin is a naive guy? ;-)

These kind of attack scenarios never end. So my opinion comes in like getting rid of these kind of low >vulnerabilities is what makes a secure application, giving no way for an attacker to get in.

A secure application on the web is a fantasy and will never exist. It is important that you don't make the application boring by senseless restrictions. Trying to control everything can make you paranoid.

Sounds incomplete!, at the end of the day the svg file still resides & can be accessed directly. To make it complete, force download the file when accessed directly.

That's correct.

However, I agree with the restriction to remove svg from our whitelist.

[rishaldwivedi]

@tablatronix True, my bad.

[rishaldwivedi]

A secure application on the web is a fantasy and will never exist.

+1 to this 🤣

[tablatronix]

I saw this and then went and read about svg injections and thought, shit might as well just turn the computers off...

😄