CodeIgniter and XSS protection

[eluser]kenjis[/eluser]
How do you think about this reccomendations?

CodeIgniter 2.0.2: Cross-Site Scripting (XSS) Fixes And Recommendations
http://blog.astrumfutura.com/2011/05/cod...endations/

CodeIgniter is one of the most prominent “micro frameworks”, web application frameworks that prosper by offering their users unparalleled simplicity. It is unusual as a framework in that it does not make any reference to standard escaping mechanisms for views/templates such as the PHP htmlspecialchars() function anywhere in its source code, examples or documentation. This may create the unfortunate impression that users should instead filter input using an XSS filter function in the CI_Security class and do nothing on output. Users taking this approach may be particularly at risk from these security vulnerabilities.

My recommendation to the CodeIgniter developers, as documented in my original report, is to deprecate and remove the CI_Security class’ XSS filter. Responsible vendors should never persist in distributing and advocating the use of insecure software. I also urge them to revise their documentation to ensure that best security practice is noted in the area of writing views/templates and offer a shortcut function to an escaping mechanism for HTML output to standardise and ease its use by members.

[eluser]n0xie[/eluser]
Sanitise input, escape output. It's the first thing they should teach at any web related course.

People might want to read There's more to HTML escaping than &, <, >, and "

[eluser]toopay[/eluser]
As recomendation, thats should be apreciated. But if we talk about xss or any security issues here, at application layer level, i agree with n0xie that everyone which started their step into web developing environment must prepare theirself with good understanding about standard security procedure. We can't, in one or another way, put this "security vulnerabilities" into any framework's shoulder, and pointed them as a "Responsible vendors".

[eluser]InsiteFX[/eluser]
6 words!

Never Never Never Trust User Input!

InsiteFX

[eluser]Padraic Brady[/eluser]

Sanitise input, escape output. It’s the first thing they should teach at any web related course.

Quite true . Unfortunately, PHP has an above average number of developers who are amateurs or self-taught who may not have the advantage of formal training. I'm largely self-taught myself (there were few web related courses back in the 90s and back then web security was not as well understood).

We can’t, in one or another way, put this “security vulnerabilities” into any framework’s shoulder, and pointed them as a “Responsible vendors”.

Bear in mind the vulnerabilities aren't simply at the application layer. Yes, if you fail to escape the output then that is definitely YOUR fault and NOT the framework's, but an XSS sanitiser is also used for HTML output you shouldn't escape (e.g. RSS feed content is HTML and if you escape that it would not render as expected). In such cases, it's not an application layer problem because the user has an expectation that the sanitiser works.

The core of my blog post comes down to one main thing: clarifying the documentation. As much as we can refer to escaping being essential in a forum, the fact is that it's not mentioned anywhere in the official documentation or the CodeIgniter source code. It would be a very minor task to add this, clarify when and where a XSS sanitiser should be used, and how to properly escape output. Adding an escaping function would likewise be a minor task.

Accurately relaying security vulnerabilities pales in comparison to encouraging users to use better security practices.

[eluser]toopay[/eluser]
[quote author="Padraic Brady" date="1305128202"]Bear in mind the vulnerabilities aren't simply at the application layer. Yes, if you fail to escape the output then that is definitely YOUR fault and NOT the framework's, but an XSS sanitiser is also used for HTML output you shouldn't escape (e.g. RSS feed content is HTML and if you escape that it would not render as expected). In such cases, it's not an application layer problem because the user has an expectation that the sanitiser works.[/quote]

A data integrity policy is a set of rules and regulations related with how your application ensures that it stores and outputs expected data. It cover everything from checking that data is valid within your character set and encoding, through filtering undesirable characters, to contextual integrity, such as ensuring the well-formed-ness of stored markup. At least we can chop this concept into two main approach :

First, a workable data integrity policy is based on the founding principle that data inside the application is pristine. That is to say, incoming data is filtered at the border and stored filtered. Outputing the data can then happen with no proccesing required. This approach is sensible for two important reasons. First, filtering is not a trivial efforts, especially for encoding conversions and syntax checking. Second, a typical chunk of application data will have fewer input than output vector. Outputing can then become as easy as reading stright from the data(base) and echoing the content, safe in the knowledge that the contents is valid.

And actually, you were just talk to one approach regarding with data integrity policy concept, the second one. Of course, not all filtering should necessarily be performed up front, though. When the data we talked is in an XML document, it will need the four XML meta-chars (<, >, " and &) to be escaped. But when , lets say the name field, is displayed in an email or in javascript, it doesn't need to be escaped (or needs to be escaped differently).

So, should we store the data escaped and unescape it for the edge case, or store it unescaped and escape it for typical case? This is very very (much) a point of style. I prefer to store all data unescape and escape it during display, but reserve of that can easily be argued by someone else (like n0xie approachment for example). Set a standard for your application and stick to it - mixing the two methods is a recipe for disaster, leading to unescaped vulnerabilities or double-escaped uglyness. The policy we came up with, should reflect the way we use the data within our system.

Also, as i stated above, your whole article just covering security/vulnerabilities issue on application layer, furthermore, the outer of application layer! You didnt said anything else, related security/vulnerabilities issues on other layer, for example : multiple disk in mirrored or parity RAID configuration help avoid data loss, or about backup tapes and offsite backup cycles aid in disaster recovery and so on.

At the end, look again at my previous post, and you will find that I think, introductory articles on security issues such as yours, must be apreciated. The only objections have come from me, how can you have a conclusion, later, which connects the "security vulnerabilities" with "CodeIgniter developers" as "Responsible vendors" ? It doesnt make any sense for me. Its really like a mechanic who blame the hammer and screwdriver (his own equipment) when the door that he made were poor and resulted in his house robbed.

[eluser]Padraic Brady[/eluser]

At the end, look again at my previous post, and you will find that I think, introductory articles on security issues such as yours, must be apreciated. The only objections have come from me, how can you have a conclusion, later, which connects the “security vulnerabilities” with “CodeIgniter developers” as “Responsible vendors” ? It doesnt make any sense for me. Its really like a mechanic who blame the hammer and screwdriver (his own equipment) when the door that he made were poor and resulted in his house robbed.

I'm not sure how you're interpreting my blog post so I'll clarify. My point was simply that distributing an XSS sanitiser which, in all probability, has undiscovered security vulnerabilities is not the mark of a responsible vendor (in this case, EllisLab and/or the CodeIgniter developers responsible for this function). Bear in mind my security report specifically recommended deprecating and removing the XSS sanitiser due to its high risk of being compromised. Let's be brutally honest here that EllisLab is not alone. PEAR, for example, continues to distribute a package called HTML_Safe which I also recommmended be removed - and it is an entire order of magnitude worse than CodeIgniter's XSS sanitiser. Would you call PEAR responsible?

It is simply my opinion that shipping risky software and downplaying the security impact of reported vulnerabilities (whether though innocent omission or not) is an irresponsible act. I'm trying to help here. I committed time to reviewing CodeIgniter at no cost and, despite having no reply from a developer, still kept my mouth shut for six weeks giving them all the time in the world to take action. The only reason I even blogged it is because of the lack of accurate disclosure.

As a user you should be asking EllisLab why some guy could report 7-8 vulnerabilities in the first place and how they will ensure such a security scenario will be actively prevented going forward. Hoping something is secure does not make it so, and the next review may not be performed by someone as friendly .

[eluser]toopay[/eluser]
*Sigh, i think we were talked about security/vulnerabilities issues here. I was give, at least general understanding of data integrity policy, at my previous post (and again, i didnt see you quote any of them, since you'd always just quoting, the most un-necessary part of my posts.).

I think it will be better, if before anyone read what you called "security report", they understand what i mention above. Or, i missed the point of your article? Or, your point at that article, is just complaining some lack of "Open-Source" framework's disclosure instead talked about security/vulnerabilities issues?

[eluser]kenjis[/eluser]
Padraic, thank you for your comments, and your blog article.

The disclosure of the incident is not enough, I feel. Official Information about the security bug is too little.

And the CI documentaion about XSS protection is not good, at least the best security practice http://ellislab.com/codeigniter/user-gui...urity.html is not the best.

I think that improving CI documentaion benefits all CI users.

[eluser]Padraic Brady[/eluser]
[quote author="toopay" date="1305296947"]*Sigh, i think we were talked about security/vulnerabilities issues here. I was give, at least general understanding of data integrity policy, at my previous post (and again, i didnt see you quote any of them, since you'd always just quoting, the most un-necessary part of my posts.).

I think it will be better, if before anyone read what you called "security report", they understand what i mention above. Or, i missed the point of your article? Or, your point at that article, is just complaining some lack of "Open-Source" framework's disclosure instead talked about security/vulnerabilities issues?[/quote]

The only point of my article was to disclose the fact that vulnerabilities existed in prior version, that CodeIgniter 2.0.2 fixes most of them, that improving the documentation would be a good thing to resolve any remaining uncertainty, and that there were a couple of simple things anyone using CI could do to improve their security in that specific area without it costing an arm and a leg .

There are, of course, lots of related security practices we could rely on. And I agree that consistency is important. Just as important is convention, which for the sake of promoting simplicity in PHP, has always leaned towards escaping on output (easier to audit, PHP has fast functions for it, it's near foolproof barring a PHP bug when used properly, etc.). Makes more sense than relying on an XSS sanitiser that might be vulnerable (not just picking on CI - ALL sanitisers will eventually have a vulnerability reported including HTMLPurifier every year or so).