I've been thinking about this a little more and agree that this should probably be a separate plugin rather than a patch for the current SecurityComponent.
The more I think about it, tokenizing basically serves to prevent record hijacking (overtyping a primary or foreign key or other hidden field in a form) and field insertion (adding extra fields to the form). But most modern web apps expose CRUD methods in a JSON REST API for use with Ajax, where form field hashes don't (or shouldn't) apply. In the threads I've seen on the subject, it's recommended to disable SecurityComponent's POST validation for Ajax requests to avoid black boxes. This exposes the REST API to CSRF attacks. Even when CSRF protection is restored (by checking that Ajax requests include header information, appended to the XHR by JavaScript--non-exotic CSRF attack sites can't do this), record hijacking and field insertion must be coded for manually. Effectively, as far as such applications are concerned, field hashing may as well not exist at all. Perhaps it would be better to produce a plugin that recommends use of fieldLists in save() calls and record ownership verification, instead of relying on field hashing. For CSRF protection, it could use session- specific tokens appended as hidden fields in forms and as HTTP Request Headers in Ajax requests. Does anyone think I've overlooked something with this concept? It's quite an extension of my original goal! Thanks. On Jul 16, 9:00 am, cricket <[email protected]> wrote: > On Fri, Jul 16, 2010 at 9:30 AM, jdbartlett <[email protected]> wrote: > > SecurityComponent is good for protecting against CSRF attacks, but > > when I encounter a black hole while debugging an app, I want to know > > why. When SecurityComponent black holes a request, it's only capable > > of telling you one thing: you sent a bad request. That's good for > > production--you want attackers to have as little information as > > possible--but it's frustrating for developers who are debugging their > > code. > > > I think it would be helpful if there were an option to have > > SecurityComponent and FormHelper log the unserialized field lists they > > use to produce token hashes. > > > My idea is to create a security.log in tmp/logs with entries like: > > * [Time and Request URI] - Form field hash [hash] based on [field > > list] > > * [Time and Request URI] - Request field hash [hash] based on [field > > list] > > * [Time and Request URI] - Request field hash [hash] does not match > > Form field hash [hash] > > > Because it's intended for debugging specific black holes, I think such > > logging should be a discrete configuration option for > > SecurityComponent. Developers would enable it only when they need to > > work out why a specific request is being black holed. > > > Does anyone else think this would be helpful? Are there good reasons > > to avoid such an approach? I've hacked my own SecurityComponent and > > FormHelper forks to do this, but wanted the community's opinion on the > > idea before cleaning it up and submitting a patch/pull request. > > One vote from me. That seems worthwhile. Perhaps a good approach would > be to create a plugin. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
