CSRF Vulnerabilities and Code Igniter plugin

[eluser]JensRoland[/eluser]
[quote author="bevans" date="1227244977"]EDIT:
THIS IS WORKING NOW...

setcookie('ci_token', $ci_token, time()+$this->CSRF_expire, "/", "", "0");

[/quote]

Can I just ask, why not add the 7th parameter (introduced in PHP 5.2.0) to set the cookie to be httpOnly? Isn't that considered best practice now?

/Jens Roland

[eluser]Nick Husher[/eluser]
[quote author="Pascal Kriete" date="1222795033"]@Bill,
It's not infected browsers that make these attacks possible. It's insecure sites.
[/quote]

I don't think that's strictly true. The security flaw is attributable to the way browsers handle their security model that allows for a confused deputy exploit. When you log into a web site, you aren't saying, "I want to have access to this web site," you're saying, "I want my browser to have access to this web site." One of the design features of browsers is that they perform actions on behalf of their user, many times transparently (in the form of requesting images or sending AJAX requests). CSRF takes advantage of the browser's implicit trust in itself to make good decisions about what actions it takes on its user's behalf with its user's permissions.

The most obvious way to solve the issue would be to unify site authentication models so a browser could reasonably determine if you have a secure session open for a particular domain. When a potential CSRF attack comes up (i.e. one domain is accessing a domain for which the user has an open secure session), the user can be prompted much like how popups are handled currently.

Unfortunately, that's an "in the future" thing, and we have the problem now. It looks like this is a good solution, overall.

[eluser]JensRoland[/eluser]
[quote author="Nick Husher" date="1232661465"]When you log into a web site, you aren't saying, "I want to have access to this web site," you're saying, "I want my browser to have access to this web site." One of the design features of browsers is that they perform actions on behalf of their user, many times transparently (in the form of requesting images or sending AJAX requests).[/quote]

Unfortunately, the change in browser behavior you're advocating would turn the browser experience into a Windows "Are you SURE you want to allow thread X access to process Y" Vista experience.

I *want* my browser to make micro-requests on my behalf, and not have to ask me about them. Popups are the exception because the vast majority of popups are unwanted, and most users can tell the difference. Most users wouldn't know what to do with a cross-site security warning. Sometimes they're fine, other times they're not, and it takes a geek (or a computer) to tell them apart.

[eluser]Nick Husher[/eluser]
Think about the number of times that you have a secure session open on one domain and another domain requests a resource that's specifically protected by that secure session (i.e. requesting the resource without the authentication token returns a 403/Forbidden header). This is a protection feature that would come up very rarely, and you could always design the dialogue to have an "Always allow" option.

Basically, such a behavior would create a conditional same-domain policy on protected resources.

[eluser]JensRoland[/eluser]
Now you're talking about authentication tokens - and tokens are a site implementation question. If the site doesn't implement them, there's little the browser can do about it - again, unless we're talking SSL (which is already handled in the browser).

[eluser]TWP Marketing[/eluser]
FIXED: the function getCSRFToken() is located outside of the class brackets in MY_Input.php and I "cleaned up" all the function brackets and missed where the class ended. My bad.
---
Bill, I'm getting this error from your CSRF code

Code:

Fatal error: Call to undefined function getCSRFToken() in W:\www\gfg\system\helpers\form_helper.php on line 64

I've autoloaded the CI input library, which should have accessed your MY_Input library, which is installed in system/applications/libraries and the MY_ prefix is set in the config file.
I've also loaded the 'form_helper' helper file, which is where the error points, but I have no idea why the function cannot be found.

Any suggestions on why it is failing?

[eluser]Tom Schlick[/eluser]
i see that this was posted in sept. has this been patched in the 1.7 version of CI?

[eluser]TWP Marketing[/eluser]
trs21219,
I'm not sure which post you are referring to. The reason I "cleaned up" the CSRF code in my copy was because the author uses the convention of NOT closing the function brackets, which is legal in php, if there is another function call or the end of the file following the 'missing' bracket. I don't subscribe to this practice as it slightly more difficult to read.

If you are referring to the date of the first post in this thread, I don't think there has been an update. I downloaded my copy two days ago and have installed it. Whether it works or not remains to be tested, pending the rest of my coding. Perhaps someone else can address the previous poster's request for changes?

[eluser]Unknown[/eluser]
TWP Marketing: I definitely do not use the convention of not closing function brackets, although this may have happened unintentionally. Can you point me to the unclosed bracket?

[eluser]TWP Marketing[/eluser]
Bill, Sorry for the confusion, it is on my part. When I "cleaned up" the code, I also re-tabbed the formatting to suit my taste and I think I removed your closing brackets, probably because I missed the fact that the final function was outside the class declaration. Again, it was my mistake, not yours, your code is fine.
TWP