| Transitions to CI3: handling input/output data |
|
Hi,
I'm a long-time CodeIgniter user since 2009 and I'm looking at transitioning our various web apps from 2.2.2 to CodeIgniter 3. I'm excited about the latest release of CodeIgniter 3 and its new offerings. In reading the 3.0.0 upgrade page, I'm noting our biggest potential code changes. Our major issues pertain to Step 13, particularly with xss_clean() and the way our applications handle input/output data. Historically, CodeIgniter has dealt with data sanitization as an input problem as opposed to sanitizing data upon output. I'm glad to see that this is changing. But it poses a huge transitional problem for us: next to none of our View data is escaped or sanitized because we always clean input data before it's ever stored at the database. Nearly every POST'ed input is run through xss_clean|htmlspecialchars on our web apps. The extend of our output sanitization is basically htmlspecialchars() to ensure that nothing goes too crazy. I'm interested in hearing from other developers in similar situations on how they've gone about transitioning to CodeIgniter 3. I guess the upside is that I know all of our existing data is completely clean. But now, do I remove all input sanitization (i.e. where we utilize Form_validation) and start purifying view variables with something like HTML Purifier? Thanks in advanced.
Hi Pandora,
Its been a nightmare to be honest! We use code igniter along with some legacy PHP code and coming up with a policy that works for both of them consistently has been a challenge. We ended up ditching CI and going over to laravel. How did you end up dealing with the issue?
for transitioning from CI 2 to CI 3 - I just did global search and replace to remove the xss filtering from all the form validation.
On the output filtering - i'm curious if there is a performance hit, but this seems like a pretty simple solution - just put this line right before calling your views? $data = $this->security->xss_clean($data); https://codeigniter.com/user_guide/libra...-filtering I'm also wondering - if the content is created inside the domain holders company - is xss filtering really a necessity? versus blog posts or comments that can be created by anyone. Also you can still filter your input post for XSS by putting TRUE after the field name - but not sure how long this will be supported since it seems like they are trying to discourage xss input filtering https://codeigniter.com/user_guide/libra...-reference
There are three really big steps to transitioning from using xss_clean() on input:
1. cleaning data on output (especially if you are not already doing so) 2. removing xss_clean() from the tasks performed on input (usually relatively easy, but can be tedious if you have a lot of data) 3. fixing the data that was previously stored after running it through xss_clean(), if necessary, to work with whatever process you've put in place for cleaning the data on output. Using xss_clean() on output, where appropriate, is a good step, but does require that third step in many cases. The fact that xss_clean() is not an easily-reversible process and that it shouldn't be performed on the same data twice are two of the reasons not to use it on input in the first place, but they also make it more difficult to transition from using it on input to using it on output. HTML Purifier is another good option, but may not change the amount of work required in the transition. My main focus in transitioning (beyond the steps above) was to focus on the validation, making sure that I was limiting the input to what I really needed to accept, and not just trusting that I could sanitize whatever I received when I needed to do so. Something I try to mention every time I comment on security-related issues is that you should always treat the data coming from your database the same way you would treat data coming from a publicly-visible form. Each portion of your application should treat the data it receives as a potential attack vector, regardless of the source. In any application which is around long enough, there is potential that the actual source of that data will change or be compromised. Treating the data retrieved from your database as potentially malicious allows you to not worry as much about it if the data source changes in the future, and limits the potential impact of an attack when your database is compromised. Additionally, data which is sourced internally today could be opened up to an API tomorrow which used a different set of validations on the data and/or needs to use the data in formats which are incompatible with the output of xss_clean() (and handle potential attacks which xss_clean() was not designed to prevent). One of the items which has been coming up in a lot of IT security briefings in my environment is how attackers will progress to different forms of attack as they gain more access to your environment. They may start by casting a wide net scanning a block of IP addresses for vulnerabilities or using automated attacks against your public-facing website(s). Once those scans/automated attacks gain a foothold, they may run another set of automated attacks which attempt to leverage the detected vulnerabilities to gain greater access, and they'll continue to escalate that process until they get to a point at which they have to actually pay attention and perform some manual tasks to attack your network. In almost every case, though, they are looking for that point at which they have gained some level of trusted access to your network or data, where someone let their guard down because they trusted that access control was enough to protect the data in their system, and therefore that data could be trusted when they used it elsewhere. |
| Welcome Guest, Not a member yet? Register Sign In |
