Codeigniter: Bypass for xss_clean() in latest version

Created on 26 Oct 2016  路  14Comments  路  Source: bcit-ci/CodeIgniter

Hi all, we believe we (during a penetration test) found a bypass affecting CodeIgniter's xss_clean() function, as it seems even in the latest version:

<map name=x><area shape="rect" coords="0,0,1000,1000" 
href="data:x,% 3 c script % 3 ealert(document.domain)% 3 c /script % 3 e"></map>
<img src="x" usemap="#x" height="1000" width="1000">

It reproduces well for us in latest Firefox, causes XSS after clicking the rendered image-map.

Cheers,
.mario

Bug Critical

Most helpful comment

Yep, and people ask me why I hate front-end tech. :)

All 14 comments

Thanks for reporting it.
Did it have to be public though?

Why not, bypasses in earlier versions were reported in the exact same manner :)

Maybe I missed some details in the docs on reporting bugs of that kind though? If so, sorry.

Well, the readme file does say we are on HackerOne and we also have a security@ mail address.
Your profile suggests that you'd know better, which I can't necessarily say for the people behind the old issues you've linked (plus 2 out of 3 refer to development versions at the time).

Anyway, just have it in mind in the future.

Report security issues to our Security Panel or via our page on HackerOne, thank you.
https://github.com/bcit-ci/CodeIgniter#resources

Security issues should be reported with an email to our security team, rather than being brought up on the forum or raised as a Github issue, thanks!
https://codeigniter.com/community

Haha, well said - and you are right :) The fix looks good by the way. The bypass was mostly possible because Gecko ignores white-space in certain data URI constructs.

Yep, and people ask me why I hate front-end tech. :)

@cure53 After the above discussion, you tweet this? That action suggests you do not know better.

@jim-parry Before the discussion, good sir, before :) Check the timestamps. Why are you folks all so grumpy?

@cure53 We are grumpy because normal practice with security issues is to disclose them to the security team, so they can fix them before they are broadcast to the world. Doing things the other way around invites exploiting of vulnerabilities, which doesn't appear to be your intent, although it is the outcome.

@jim-parry Your code is broadcast to the world, and with it all vulnerabilities in it :) Your team created the bug, we just point at it. We reserve the right to chose how we do that.

@narfbg and me already discussed the deviation from your protocol above and I thought things were okay. Then you @jim-parry came in and made an unnecessarily snarky comment based on a faulty assumption. I wonder why that was necessary. Or how that was constructive.

You received a bug for free and we even had a look at the fix for free. And still you assume you have the privilege to tell people that their "action suggests you do not know better."?

I even somewhat understand your point - we have been in this field for many many years. And likely so have you. But please let's keep a base-line of politeness and stick to the topic instead of borderline insulting people who gave you something for free.

I propose to lead the discussion form here..

After the above discussion, you tweet this? That action suggests you do not know better.

...to a potential here:

Hm, interesting find. Might there be more like this - or is that it?

Feels a bit more constructive to me, don't you think?

@cure53 Sorry for being grumpy. We have a small team, and are trying to build the best & most secure framework possible. We appreciate your finding and fixing a security bug, but would like the opportunity to fix those before they are broadcast.

Oh, boy. @jim-parry is involved in an argument, and I'm playing the peace-maker. I guess hell froze over. :smile:

@cure53 We're grumpy because almost nobody follows our guidelines, and yes - immediately tweeting about a vulnerability _is_ making it worse. And I have to say, by doing that you kind of submit the position on a high horse that security researchers usually have.

Also, you're not being fair with this:

Your code is broadcast to the world, and with it all vulnerabilities in it :) Your team created the bug, we just point at it. We reserve the right to chose how we do that.

You know our team didn't create the bug. Mozilla did, you alluded to that yourself already.


You as a security consultant, and we as OSS maintainers, are virtually on the same team and deal with the same shit, that's why we hold each other to higher standards. Can there be peace now?

We appreciate your finding and fixing a security bug, but would like the opportunity to fix those before they are broadcast.

Fair enough. As mentioned, our reports will be more discreet next time :) No grudge on my side. I just don't like being accused of things for no reason.

We're grumpy because almost nobody follows our guidelines

To be quite honest, I searched the homepage for a security contact. And checked the bug tracker for XSS reports. But I missed the bottom of the readme. Maybe the guideline gets more visibility if there is a link on the homepage as well? The about-page talks about the security team. Adding the email address / link to H1 there would help a lot.

Can there be peace now?

Absolutely. Never actually intended conflict. Just protested the tone used here by @jim-parry - rightfully so I believe.

So, I had a closer look at the filter and found a couple of other bypasses.
I'll post them on Twitter as we agreed, okay?

Just kidding, will send you a mail :D

Was this page helpful?
0 / 5 - 0 ratings

Related issues

boblennes picture boblennes  路  4Comments

olisaagbafor picture olisaagbafor  路  3Comments

alexmason528 picture alexmason528  路  6Comments

sasbass picture sasbass  路  7Comments

vahidvdn picture vahidvdn  路  4Comments