PHP developers should avoid these mistakes

By Rajeev Pandey, 3rd Eye Advisory®
PHP developers should avoid these mistakes

    It might seem like an easy step, but many developers have poor backup practices. You don't need to back up every hour, but you should run backups each day if you do significant work on a project. Just remember that your backups save your hours of recoding.

    If you have a difficult time figuring out a problem in your code, back up the system so you don't lose the solution-and hours of work-and have to recode it. A backup can also save you from missing a deadline if something happens to go away.

    You should also create backups for your clients in the rare case that a client has a critical failure and no backup. It's a nice gesture, and you can help your client out of a potentially sticky situation.
    Some of the top cyber attacks on the web are SQL injections. In a SQL injection attack, a hacker will insert SQL code you haven't authorized into your database, causing it to execute commands like leaking, altering, or deleting data. However, there are ways that better PHP programming can minimize the risk of SQL injection attacks.

    PHP is the backbone for several CMS's such as WordPress, Joomla, Magento, Opencart, Drupal etc. When writing new extensions and plugins for WordPress sites, developers will likely create inline SQL statements. These statements are built from the front-end and sent back to the SQL database. If these statements are malformed, you run the risk of leaving your site open to SQL injection.

    There are two ways to avoid this. The first way (and the most preferred) is by using prepared statements. The second is by using parameterized queries.

    The following statement builds on user input from a form:

    $stmt = ("SELECT * FROM clients WHERE fname = '".$fname."'");

    This might leave your site vulnerable since it leaves your site open to SQL injection. A safer bet is often to use parameterized and prepared statements like the following:

    $stmt = $dbConnection->prepare('SELECT * FROM clients WHERE fname = ?');
    $stmt->bind_param('s', $fname);

    These are considered better methods because the tick mark the opens and closes a string value in SQL is processed as a literal and not an opening or terminating character.
    This mistake is somewhat directly related to the first mistake we listed. The first mistake-not securing SQL code-can lead to SQL injection security flaws. This mistake references cross-site scripting (XSS) security flaws that can occur when the developer prints data directly from a user.

    Suppose you have a form input text box named "fname." You want your script to display "Hii, $fname" to the viewer. You can do this using the following code:

    Welcome $_POST["fname"];
    However, what happens if a user inputs ""?

    This might seem like a minor, insignificant annoyance that no one would bother doing, but the problem is that you're allowing JavaScript to run indiscriminately in the browser. When JavaScript can run on the browser from user input, an attacker can use XSS to perform any number of events such as stealing passwords and sessions. A hacker could get very creative with the script and perform a number of attacks including session hijacking, phishing, and sneaky redirects.

    Instead of printing user input, make sure you scrub any HTML tags out of the output, especially script tags. This will prevent rogue JavaScript code from running on your user's computer. This type of attack is called an XSS attack, and it allows the attacker to run JS code that could potentially put the entire application at risk.
    It's important for any developer to have a development environment-a staging environment that mimics the production environment, which houses the live code. In some cases, a developer might be rushed and forget to remove development variables and configurations, then upload these by accident to the production environment. This can be a disaster for a live application.

    Many new developers try to skip the staging environment and go straight from development to production in an effort to save time. This is a mistake because staging can help you identify problems that you didn't catch in development (remember, staging mimics production). If you accidentally forget to remove configurations or don't find bugs until staging, you can still catch them before they hit the production environment.

    Always have a staging environment, and use it even if you're just making minimal changes. It's also a good idea to have QA testers test the code in staging before it's moved to production.
    It's easy to accidentally use the wrong operator when writing condition statements. After all, developers can spend several hours assigning values to variables. However, if you accidentally use the assignment operator instead of the conditional comparison, you run the risk of introducing bugs.

    if ($condition = 'value')
    //do something

    In the above code, the developer mistakenly assigns the value "value" to the $condition variable. The condition should read like this:

    if ($condition == 'value')
    //do something

    To avoid this type of mistake, some developers prefer to use "yoda syntax." Yoda syntax switches the order of the condition and value. This is what the above code would look like in yoda syntax:

    if ('value' == $condition)
    //do something

    Now, if you accidentally use the assignment operator instead of a comparison, the compiler will give you an error and you can correct it.

    PHP has different error levels, but you can manually suppress them in your code. This is useful if you have errors that aren't critical and don't cause any serious effects. For instance, you could suppress warning messages regarding PHP versions.

    The "@" symbol is used to suppress errors when you don't need them, but use it with caution- it can sometimes cause some unforeseen issues. Suppose you have an include file that isn't necessary when running the application. It could be optional for users who only have a specific component in their browser. In that case, you could use the following code in your PHP file:


    In the above code, even if the db.php file has errors, they will not be displayed or logged. This error suppression should be used sparingly as you can have errors that aren't being logged and won't be found until something critical occurs in the application. In the long run, it's better to handle errors rather than suppress them for convenience.

#ReadyBusinessPlan #ask3rdEyeAdvisory #LearnAt3rdEyeAdvisory #3rdEyeAdvisory

Article by: Rajeev Pandey, 3rd Eye Advisory®
More on IT Advisory