Just saying "Hi" (includes discussion of programming practices)

Hi all. New guy to the forum.

Just got back into coding/scripting/programming (whatever you like to call it).

It’s been a while, but my first experience was PHP and I’m looking to rekindle my relationship with it.

Seems to be a lot of putting down of PHP across the www, but I can’t think of any good reason not to dive in again.

I’m sure you’ll be hearing lots from me on the beginner forum (although I’m not an absolute beginner).

My initial focus is on security. I’ve been brushing up on prepared statement use; which I think pretty much negates sql injection issues, as I understand it?

Now moving on to cross site scripting. For this, I have implemented csrf token usage for any forms on my site(s) and welcome any other recommendations you may have. High level suggestions of reading material welcomed.

Thanks for reading

/Danny

You’re correct; using prepared statements properly completely removes any risk of SQL injection attacks.

CSRF tokens are useful to prevent cross site scripting; you should also be sure to escape any output created dynamically by your program. PHP has a useful built in function for doing this for HTML output: htmlspecialchars:

// Not safe:
echo someResult();

// Safer:
echo htmlspecialchars(someResult());
1 Like

Thanks for that tip, skawid.

Interestingly, I had just been reading that $_SERVER[“PHP_SELF”] is not considered secure and instead, you should use $_SERVER[“SCRIPT_NAME”], but still encode it with htmlentities($_SERVER[“SCRIPT_NAME”]).

I guess this is along the same lines you have described above. I am just trying to understand the situational differences between htmlentities() and htmlspecialchars().

Interestingly, I previously used to more concerned about what was being put in to a DB, now it’s all about securing what is coming out.

Is there a recommended standard for wrapping $_POST / $_GET variables in anything, from a form e.g. stripslashes() or any of the two html encoding methods above?

Don’t bother with any of the above. If building links or form action attributes, use a relative link or leave the whole action attribute out.

Always just use htmlentities().

None of those. stripslashes(), when it was needed, should have been conditionally applied, but the need to do this, magic_quotes, was removed from php in 2012. htmlentities() and htmlspecialchars() are output functions. They are used when outputting data in a html context. The only thing you should do to input data is trim() it, mainly for the purpose of detecting if it consists of all white-space characters. Anything else alters the meaning of the data. You would then validate the inputs and only use them if they pass validation.

1 Like

Hopefully, using the much simpler and more consistent PDO extension, rather than the crippled mysqli extension.

Yes. One of the first things I jumped on was the CRUD operations on mySQL and PDO seems to be considered best practice. I am right in thinking that with pdo and prepared statements, you do not need to declare the variable type? e.g.

$stmt=$pdo->prepare("INSERT INTO my_table SET id=? AND country=?");
$stmt->execute([$id, $country);

So either .<form action=“inc/form-handler.php”… or <form action=""… is the preferred choice?

/Danny

Correct, because when you use a true (non-emulated) prepared query with the PDO extension and use implicit binding, i.e. supplying an array of values to the ->execute(…) call, the types of the values are carried through to the database server. This works as expected for string, integer, decimal, boolean, and null values. I don’t do blob/binary data in a database, so, don’t know what occurs for this data type.

When you use an emulated prepared query and use implicit binding, all values are treated as strings and are enclosed by the appropriate string quoting method in the built sql query statement. This causes problems in some contexts for integers (a limit clause) and doesn’t work for boolean and null values.

Leave the entire action="" attribute out. An empty action="" attribute is not valid in html5. It was in html4. A side affect of leaving the action=’’ attribute out, is the browser will automatically propagate any existing query string get parameters for you.

Great, thanks for the tip. I am assuming that setting the attribute of PDO::ATTR_EMULATE_PREPARES to FALSE is recommended in that case? My initial “get back into it” app is quite heavy in terms of numerical data.

I’ve actually run into my first real issue and not wanting to turn this intro thread into a full blown help topic, I’ll move across to the help forum with that one.

Thanks a ton for your input.

/Danny

The recommend settings/options when making a PDO connection are to set emulated prepared queries to false, set the error mode to exceptions, and set the default fetch mode to assoc.

1 Like

Here is a good way to clean SERVER variables

trim(htmlentities($_SERVER[‘REMOTE_ADDR’], ENT_QUOTES | ENT_SUBSTITUTE, ‘UTF-8’));

UPDATE: I feel this last example is not good practice as the string param is still not trimmed, htmlentities here will be trimmed twice?

Here is my update…

htmlentities(trim($_SERVER[‘REMOTE_ADDR’]), ENT_QUOTES | ENT_SUBSTITUTE, ‘UTF-8’);

Now the string inside the html entities function will be trimmed. Sorry if anyone has used my code there but i will be updating my code this way.

1 Like

Thanks for the update jimbopp.

For myself, I’ve actually taken to the practice of calling from a form as per phdr’s recommendation, above.
If it’s a direct call to the running script, I leave out the action attribute altogether, otherwise I call exclusively e.g.

<form method="post" action="formhandler.php?id=<?=$id; ?>">

(in the above example, $id will have already been sanitized)

/Danny

Sponsor our Newsletter | Privacy Policy | Terms of Service