Thanks for reading! I’m trying to figure out a way to gracefully and safely process forms (post variables).
In Codeigniter there’s a vibe where you can say:
$username = $this->input->post(‘username’);
…and that will fetch the posted variable which happens to have a key of ‘username’. However, you can also add the word ‘true’, like this:
$username = $this->input->post(‘username’, true);
By simply adding the word ‘true’, you send the username variable through an impressive and extensive chunk of code, all dedicated to making sure the variable is safe.
I was just wondering, does Yii2 have a similar feature?
I’ve had a look around the web and I can’t find anything similar for Yii2. This page from the userguide doesn’t seem to discuss it and - as a matter of fact - I found a thread HERE in which a very important person says that Yii doesn’t provide a sanitization feature. However, that was an old post and perhaps things have changed.
Can anyone shed any light on this? My only goal is to process basic forms - taking in post variables - as safely as possible.
Safe for what? Different contexts require different sanitization/filtering/escaping strategies and that’s why any automatic input sanitization gives you only a false sense of security and should be avoided.
CodeIgniter sanitization isn’t as good as it’s advertized. In fact, it gives you false sense of safety which is quite bad. As phtamas mentioned, it’s all about context. There’s no way to sanitize data for all possible use cases.
It’s been a long time since I’ve gone into the bowels of Codeigniter to figure out precisely how the inbuilt security features work. However, from memory, it’s a couple of hundred lines of code and it appears to be pretty solid (nobody out there is talking about Codeigniter getting hacked).
Now, I realise that (with Yii2) you can use things like Html::encode or even HtmlPurifier::process($html) to make sure the information being presented to the user is safe, however, I think some web owners wouldn’t want unsafe data going into the database in the first place. HTML encode and HTML purifier might do a good job of making the data safe upon presentation to the end user, but - as far as I can tell - they do nothing to stop people from adding dangerous scripts into your database.
I’m very grateful for the suggestion of using filter_var. It’s a good suggestion which seems to have the endorsement of some very good Yii developers. However, personally speaking, I think the syntax for using that is horrible. Don’t you? I’d like to think frameworks can help us to write syntax which looks nice.
Perhaps the best way forward would just be to use something like addslahes(trim(strip_tags($info))) . It’s a bit old school but at least it’s easy to read and it gets the job done.
I’m not exactly sure if LOC is an applicable measure when we talk about security but HTMLPurifier.standalone.php has more than 17000 lines.
Depends on usage. HTMLPurifier can be used to filter data before saving it to database. E.g. in the beforeSave hook of your models.
Old school and almost totally useless. The key point is that you cannot simply apply the same filter blindly to all input. You have to know how and in what context the data will be used and setup your filters/sanitization accordingly.
Will it be displayed as HTML? (Are users allowed to use some HTML tags? Are some authorized users allowed to use even "dangerous" tags, e.g. in a CMS admin backend?) - HTMLPurifier is the tool for the job.
Will it be saved to an SQL database? - Use prepared statements.
Will it be sent as an email? - Use some mailer library with built-in protection against header injections.
I’m quite comfortable with the “validation” schema that is implemented in Yii’s Model layer. It makes it possible for us to write context-aware validators (including filters) in a very simple fashion. The combination of Model and ActiveForm is quite powerful and helps to make controllers and views very simple.
As opposed to that, in CodeIgniter the concept of "form validation" is implemented as a helper that is to be used in the Controller layer.
Using solid accepted code is almost always better than roll your own.
TBH, I don’t believe any framework (unless it’s a pure security framework) should provide point solutions for general security items. It’s hard enough writing secure code without also having to write the code for security.
PS: Seems I can’t include URLS so look up OWASP and OWASP PHP for great reading.