DEV Community

loading...

Don't Reject Something

Imam Ali Mustofa
Founder of Betta Dev Indonesia - Software & Application Developer "The best moment in my life is.. when I encountered an error and I can fix it!"
・2 min read

Hi there,

In line with the title (I don't want to say it again). I warn you again not to waste a minute of your time reading this article, because it is useless.

Sanitize database inputs

When inserting data in your database, you have to be really careful about SQL injections and other attempts to insert malicious data into the db. The function below is probably the most complete and efficient way to sanitize a string before using it with your database.

<?php

function cleanInput($input) {

  $search = array(
    '@<script[^>]*?>.*?</script>@si',   // Strip out javascript
    '@<[\/\!]*?[^<>]*?>@si',            // Strip out HTML tags
    '@<style[^>]*?>.*?</style>@siU',    // Strip style tags properly
    '@<![\s\S]*?--[ \t\n\r]*>@'         // Strip multi-line comments
  );

    $output = preg_replace($search, '', $input);
    return $output;
}

function sanitize($input) {
    if (is_array($input)) {
        foreach($input as $var=>$val) {
            $output[$var] = sanitize($val);
        }
    }
    else {
        if (get_magic_quotes_gpc()) {
            $input = stripslashes($input);
        }
        $input  = cleanInput($input);
        $output = mysql_real_escape_string($input);
    }
    return $output;
}
?>
Enter fullscreen mode Exit fullscreen mode

Here’s some examples of use:

<?php
  $bad_string = "Hi! <script src='http://www.evilsite.com/bad_script.js'></script> It's a good day!";
  $good_string = sanitize($bad_string);
  // $good_string returns "Hi! It\'s a good day!"

  // Also use for getting POST/GET variables
  $_POST = sanitize($_POST);
  $_GET  = sanitize($_GET);
?>
Enter fullscreen mode Exit fullscreen mode

In my opinion, this is a very tedious and addictive step in the code for the application you are currently developing. There are too many functions and techniques that make your job as a php developer difficult.

So, it's better not to write a line of the above code in the code you are working on. Even when there is an injection into your database or your client's, it will add a surprising new variation and get your adrenaline pumping as a programmer to get anger from clients or warning letters from project managers.

Thank you for reading this useless article, because what I say is true and may or may not be true. There is absolutely no benefit.

Source Code From:
https://css-tricks.com/snippets/php/sanitize-database-inputs/

Discussion (3)

Collapse
darkain profile image
Vincent Milum Jr

Due to the security nature of dealing with SQL Injection and Cross Site Scripting mitigations, I'm just going to flat out say that the code above is wrong. Normally, I wouldn't, but, I really REALLY don't want someone to copy that code and get exploited.

A couple points.

1) the mysql_ functions in PHP were removed many years ago. They're highly problematic. They should never be used. mysqli_ functions should be used instead.

2) magic quotes was also removed many years ago too. Don't rely on them, they don't exist now, due to all the issues surrounding them.

3) don't intermix strip_slashes and any of the _escape_string functions, this is just leading into disaster with mangling data, potentially causing unforeseen problems.

4) PHP has a strip_tags function built in. Use theirs, don't re-implement it, or else prepare for it to be abused and exploited by missing some subtleties in how HTML/XML work. A regex is never a good way to parse/strip HTML.

5) stripping and <style> are redundant, since they&#39;re all HTML tags, which are already being stripped.</p> <p>6) this implementation takes the false assumption that &quot;bad data&quot; comes from SOME external sources only ($_GET and $_POST). There are other external sources, such as $_REQUEST and $_FILE. But more importantly, there are also INTERNAL sources of data. It very much is possible for data to be written to the database, read back for processing, and then written back to the database, and in that process, become exploitable data. If it was escaped going in, then it needs to be re-escaped to go in again the next time too.</p> <p>I&#39;d <em>HIGHLY</em> recommend just using a database connection and processing library that handles all of this securely for you, so you don&#39;t have to think about it anymore, such as PUDL: <a href="https://github.com/darkain/pudl" rel="nofollow">https://github.com/darkain/pudl</a></p>

Collapse
darkain profile image
Vincent Milum Jr

Looks like my comment is a GREAT EXAMPLE of how things could get mangled from improper sanitation and validation! LMAO. Time to go file a bug with dev.to

Collapse
darkterminal profile image
Imam Ali Mustofa Author

Thank you for your comments, hopefully those who read can get the benefits.

Forem Open with the Forem app