ansaurus

Question

escaping input in php

Answer 1

+4 A:

As neither strip_tags nor trim change the input string, there is absolutely no difference between the two versions.

Daniel Vandersluis 2010-10-04 18:19:04

Answer 2

A:

They're both exactly the same.
What are you escaping the input for? Database? XSS?

chigley 2010-10-04 18:19:16

I would say both... but after that I use mysql_real_escape_string for db..

arturs 2010-10-04 18:21:37

Answer 3

A:

Both snippets are exactly the same. Some people will say the first one is better for readability and some people will say the second one is better for conciseness.

Rafael Vega 2010-10-04 18:19:43

Answer 4

A:

Both of the versions mean SAME, you can use any. In my opinion you must use the filter_var, to filter the the input string...

Chetan sharma 2010-10-04 18:20:58

Answer 5

A:

Well, strip_tags can still be exploited. A slightly better solution might be the following:

$destination = htmlentities(trim($_POST['var']));

However this is still not enough, extra work should be done if the $_POST['var'] will go into the database.

Make sure that you understand what htmlentities() does exactly before implementing it in your code on a production level.

Link- 2010-10-04 18:28:56

I read once a topic about this one... and someone said that it might corrupt databese if it will be filled with " etc. and I use mysql_real_ecape_string too.

arturs 2010-10-04 18:35:22

It's not going to "corrupt the database", but `htmlentities()` has absolutely nothing to do with input; it's only useful for escaping output.

meagar 2010-10-04 18:36:52

The reason i suggested htmlentities() is when the input is being output from the database .. strip_tags() will do nothing to prevent an XSS or other vulnerabilities in that case.

Link- 2010-10-04 18:48:33

@Link- That doesn't make sense. Input does not come from the database via `$_POST`. Escaping HTML entities is important, but *not* on data going into the database. It should only be done with data coming *from* the database, immediately before it leaves your app via STDOUT.

meagar 2010-10-04 19:16:52

@meagar: for one, htmlentities() serves as a multiple purpose input filtration. Not only does it help filter XSS but also reduces the risk of sql injection. for two, filtering the output after it leaves the database can still produce code insecurities (Think of log poisoning etc...). Filtering the output as it leaves the app is not practical either! Imagine outputting the data in diverse areas, you have to filter all of them?! That's not a very good practice is it?!

Link- 2010-10-04 21:09:08

@Link- `htmlentities()` has **nothing to do** with input filtration. *"Filtering the output as it leaves the app is not practical either! ... That's not a very good practice is it?!"* *Yes*, it is practical, and *yes*, it is good practice. **It is exactly what you should be doing**. Encoding HTML entities to protect your log files and database is nonsense. You cannot inject HTML into your database because your database doesn't parse HTML. Data shouldn't be encoded for display until you display it. It's that simple.

meagar 2010-10-04 21:12:56

Answer 6

A:

Both versions are the same in terms of vulnerability. If injection is what you're worried about, you may want to include addslashes().

Which is better? Version 2 will actually benchmark a little faster. Setting a variable to another is just an unnecessary step in the process. I would suggest that version 1, while not technically wrong, is bad practice. Even though the resulting value is the same.

Pizano 2010-10-04 19:13:04

ansaurus

tags:

views:

answers:

escaping input in php

related questions