Sanitize input->get()

[VeiJari]

Hello forum, this is my first security related post, so I'm a bit of a newbie.

I understand that when I have direct front-input from user I should sanitize the input, but how about when I use a secret key for showing a API for a third-party supplier? Should I sanitize the input->get() key?

I've tested this issue and I tried ?key=<?php echo $page->field; ?> And without adding any sanitization it comes back: /?key=<?php%20echo%20$page->field;%20?>

So can I rely on this, or should I still use $sanitizer just in case?

 

Thanks for the help!

[teppo]

14 hours ago, VeiJari said:

I understand that when I have direct front-input from user I should sanitize the input, but how about when I use a secret key for showing a API for a third-party supplier? Should I sanitize the input->get() key?

I've tested this issue and I tried ?key=<?php echo $page->field; ?> And without adding any sanitization it comes back: /?key=<?php%20echo%20$page->field;%20?>

So can I rely on this, or should I still use $sanitizer just in case?

What you're seeing there is just what happens between browser and server, i.e. spaces getting replaced by %20. If you're echoing the value, it won't get executed as PHP code (you'd have to call eval or something similar to get that effect), but it could still allow HTML or JavaScript through – which is probably also something you don't want to allow. For an example, see what happens if you set the key value as <script>alert("hi")</script> instead.

The general rule of thumb is to always sanitize user input ?

That being said, if you're certain that you're only reading the GET variable and comparing it to some pre-defined value, and you'll never store or output it as-is, then there's no real harm in not sanitizing it. As you've proven yourself, it won't get evaluated as PHP code.

[VeiJari]

On 8/5/2019 at 7:34 PM, teppo said:

What you're seeing there is just what happens between browser and server, i.e. spaces getting replaced by %20. If you're echoing the value, it won't get executed as PHP code (you'd have to call eval or something similar to get that effect), but it could still allow HTML or JavaScript through – which is probably also something you don't want to allow. For an example, see what happens if you set the key value as <script>alert("hi")</script> instead.

The general rule of thumb is to always sanitize user input ?

That being said, if you're certain that you're only reading the GET variable and comparing it to some pre-defined value, and you'll never store or output it as-is, then there's no real harm in not sanitizing it. As you've proven yourself, it won't get evaluated as PHP code.

Thank you, it's only to compare it to a backend field that only admin's has access to.

I understand the basic principle now.

[Andy]

@teppo and @VeiJari

On 8/5/2019 at 7:34 PM, teppo said:

The general rule of thumb is to always sanitize user input 

I would also remind you that there is a SQL injection.

[kongondo]

4 hours ago, Andy said:

I would also remind you that there is a SQL injection.

True, but not applicable to usage of ProcessWire itself unless something's changed ?.