In the MVC way of doing things, where is the best place to run, for example htmlspecialchars() on any input? Should it happen in the view (it sort of makes sense to do it here, as I should be dealing with the raw input throughout the controller and model?)
I'm not quite sure... What are benefits of doing it in the view or controller? This is just reguarding outputting to a page... to minimize potential XSS exploits.
You can do it in the view (via javascript validation), but data coming from the rendered view to the controller is still considered untrusted, so you will still have to sanitize it in the controller.
In the examples I've seen (such as nerddinner), the sanitizing code is part of the model classes. Some people use validation libraries.
I don't there's any 'best' place to sanitize. Depending on the use case, we may need to implement sanitizing logic in more than one tiers.
Well, that depends, doesn't it? You should sanitize everything you OUTPUT in the view. First, because sanitization depends on the format of your output. A JSON sanitized output is different than an HTML sanitized output, right? Second, because you never want to trust the data you have. It might have been compromised through any number of ways.
That won't protect against SQL injections and such, though. Now, you never want to do that in a client-side javascript, because an attacker may easily replace that. Again, my advice is sanitization at the point of usage. If you are just writing to a file, it might not be needed. And some database access libraries do not needed it either. Others do.
At any rate, do it at the point of usage, and all the source code becomes more reliable against attacks and bugs (or attacks through bugs).
The general rule is : fat model, thin controller.
Now, how you apply that rule is a different story :)
The way i think of it is your controller should really just be controlling the flow, redirecting to pages and etc. Any validation should take place in your model. If you want to do client side validation, you'd probably put it in the view. Any developer concerned about security would do validation on the client and on the server.
This is why thinking in design patterns sucks. What you should be asking is where is the most efficient place to do this? If the data is write-once/read-many then sanitising it every time it's output (on page view) is going to put unnecessary load on the server. Make your decision based on how the data will be used, where you can setup caching, how you do searches, etc.. not on the merits of a pattern.
From what you've said I'd perform the sanitation just ahead of writing it to the DB. Then you're not only ensuring the data is safe to insert but you're also ensuring that no future mistakes can result in unsanitised data being sent. If you ever want the original text for some reason you just invert your original transformation.
You should not be concerned about storing html encoded text in your DB since ALL text is encoded in one form or another. If you need to search the text you just encode the search string as well. If you need another format then that's another story but then you would have to evaluate your options based on your needs.
Howdy,
I think the best way is to escape the view - output, and store everything in original in your database.
Why ? With this method you're able to use the db records for every use case.
I put it in the "controller" as most of today's frameworks define it. (Not getting into the discussion of how pure that is) It is not something that belongs directly in a view template, but it also does not necessarily need to be in the model, as you may want the original data sometimes and not others.
So when I'm loading data from the model in the controller and assigning it to a view (smarty template, in my case), I run it through the HTML Purifier first.
I'm going to buck the answering trend here and give this advice:
Untrusted input should be confined as rigidly as possible - by reducing the number of places that you interact with input before its safety has been evaluated, you reduce your threat exposure when someone who is thinking about a bug fix or functionality improvement rather than security changes the system under discussion.
Depends on the type of user input and what the validation it is you're running on it.
If you want to clean the input, I'd put the logic in the controller, and also in the view when you output data that comes from the database (or any source really).
If you are doing data validation, I'd do it both on the client side with javascript, as well as in the model.