filter_var or htmlentities() or htmlspecialchars()

[hany]

Hello Guys ... i am new here and i am also new in php

i selfstudy html css and js and bootstrap for front-end

and for back-back php & mysql & PDO  & OOP and  i will soon start mvc then laravel

and i am trying to secure my input field  and i do not want any attacks or sql injects

and i see people user filter_var and htmlentities and htmlspecialchars  and each one has diffrent opinion

can some one help me and tell me what is the best for securing input which all values will store in database

thanks <3

[Phi11W]

In a Client-Server application, like this, you have to consider two, very separate Environments:  

1. The secure Environment, in which your code runs and your database lives. 
   Here, you can Trust everything. 
   Everything is stored in "proper" Data Types.  
   Life is Good.  🙂
2. The unsecure Environment, which is everything outside the secure Environment.  This includes the User's browser and even the TCP/IP channel between your server and that browser. 
   Here, you can Trust nothing. 
   All data is encoded into Character Representations of itself (Users cannot enter "numbers" or "dates" as a computer or a database would store them). 

The trick, then, is how to get Data back and forth, between the two?  

For data coming "in", you have to clean, verify and decode those data to make them safe to be "admitted" into your "Inner Sanctum", most importantly, your database.  This is basic, defensive programming-type stuff, plus things like Prepared SQL statements to minimise database vulnerability. 
That's where filter_var can help (once you've figured out what sort of Wee Beastie the datum is - trying to do numeric range checks on the letter 'q' always causes "fun" in testing. 

For data going "out", you have to encode those data to make them safe for the browser receiving them.  
That's what things like htmlentities and htmlspecialchars come in, to defend against Cross-Site Scripting (XSS) Attacks and other things. 
You should also consider more general things, like date and number formatting, which different User communities may want presented differently. 

Here's a comprehensive StackExchange Accepted answer on the subject. 

Regards, 
   Phill  W.

 

 

[Strider64]

The following simplifies this for me to understand.

Quote

I go by the rule never trust user’s input (Client Side), so that means to me never trust their output (Server Side).

 

Edited May 21, 2021 by Strider64

[sen5241b]

 

I have come to the conclusion that nothing works perfectly to do this. This surprises me. How many servers and for how many years has this problem been around? 

OPTIONS

PHP provides filters. The filters are pretty generic.

Strip tag seems useless. One greater than symbol in the input and most of the good data is stripped out

Clean-html seems better than the rest but I'll be damned if I can get it to work on  my system

https://github.com/dave-kennedy/clean-html

 

Edited May 26, 2021 by sen5241b

[requinix]

Too many people are obsessed with "filtering" bad inputs.

You don't have to "filter" anything. You don't have to remove HTML tags. You don't have to remove SQL keywords. You don't have to strip quotes or backslashes.

All you have to do is make sure that whatever the user typed doesn't screw around with what you're trying to do.

Want to put it into HTML? Make sure it doesn't screw around with your HTML.
Want to put it into SQL? Make sure it doesn't screw around with your SQL.
Want to send it in JSON? Make sure it doesn't screw around with your JSON.

And every single one of those situations has a simple, single best-practice solution:

HTML? Use htmlspecialchars with ENT_QUOTES* and the correct charset.
SQL? Use prepared statements.
JSON? Use json_encode.

That's it. No filter_vars or filter_inputs, no strip_tags, no regular expressions, nothing stupid like that. User wants to look cool and type <script> tags into their forum post? Go ahead and let them, because it'll just show up as plain and simple text. Like it just did now.

* Only actually required if you are putting the input into an single quote-delimited tag attribute. Using double quotes for your attributes? Not outputting into an HTML tag? Then you don't technically need ENT_QUOTES.

[hany]

Thanks guys for all your replays ❤️ it's very helpfull