2

I want to know how to protect my website from hackers. I am a php-mysql developer. For fetching data from databases I always use MySQLi. For preventing my website from SQL injection, I always use PHP's $db->real_esacpe_string() function. In order to prevent my website from XSS (cross-site scripting), I used this function:

function parsing($text)
{
global $db;
        $text=$db->real_escape_string($text);
 $text= @trim($text);
       $text= strip_tags($text);
 if(get_magic_quotes_gpc()) {
            $text= stripslashes($text);
        }
    $text=str_replace('<','',$text);
    $text=str_replace('>','',$text);   
       $text=htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
    return($text);
}
$name=parsing($_POST['name']);

Any suggestion from your side is welcomed. Thanks in advance.

6

To be awfully honest, this function is just an arbitrary collection of more or less useless or harmful and sometimes even contradicting procedures, most of which has nothing to do with security at all. Now to the most important part.

SQL Injection

For prevent my website from sql injection i always use $db->real_esacpe_string()

Which is what you are doing wrong. You're not alone though, I list it as the most infamous PHP delusion. Citing from that page:

this function has absolutely nothing to do with safety or injections, merely escaping special characters in SQL string literals, making them immune to SQL injection as a side effect, but being utterly useless for any other query part, from a table name to a numeric literal. To protect from SQL injection, one should follow two simple rules:

  • Any variable data literal (i.e. a string or a number) should be substituted with a parameter, whereas actual value should be sent to the query separately, through bind/execute process.
  • All other query parts that happen to be added through a variable, should be explicitly filtered through a hardcoded list of allowed values.

Given raw mysqli is rather tough with prepared statements, I would strictly suggest to use PDO instead.

So the main idea that nothing related to SQL security should be in such a function at all.

XSS

Let's see what are you doing with malicious < and > characters:

  • first, all tags get removed by strip_tags($text);
  • then these symbols (already extinct from the text) get replaced with an empty string
  • finally those non-existent characters get converted to HTML entities

If you ever ask me to define "overkill" I will just show you this function. htmlspecialchars() alone should be enough to prevent XSS in the page body.

What is more important, you seems to be using this function on the data input which is wrong. A text should be formatted right before the output, according to the formatting rules for the certain medium. If you're outputting into HTML page body, it would be htmlspecialchars. It the text goes to JavaScript then it should be another formatting and so on.

Useless stuff

  • trim() has nothing to do with security at all, you could use this function for convenience.
    • on a side note, never even use this @ operator. It is harmful for your programming experience.
  • stripslashes() as well, has nothing to do with security. Besides, this function is just useless, never doing anything sensible at all.
  • Not to mention that get_magic_quotes_gpc() is twice useless, returning a value that has been removed from PHP 10 years ago.

Conclusion

  • get rid of this function
  • to prevent SQL injection follow 2 rules from above
  • to prevent XSS use htmlspecialchars when outputting your data or any other appropriate formatting.
2

The answer by @YourCommonSense is good, but to add a bit to it: SQLi and XSS are not the only important webapp security threats! In fact, there's a few that I'd put well above those, such as command injection (a risk if your server runs any commands, especially in a shell, containing user-supplied input) or other ways to potentially get arbitrary code execution (uploading and running executable files, deserialization attacks, etc.). Those sorts of attacks are more likely to enable somebody to delete server files than XSS or SQLi, anyhow.

Without knowing more about what your site does and its security model, I can't produce a proper list of security vulnerabilities that you're at risk of, but I guarantee it's more than XSS and SQLi. For example, CSRF is almost certainly a risk. There's a whole pile of ways to do authentication and session management wrong. File uploads of any kind are a potential risk. Processing XML is a risk. Doing crypto is very hard to get right. Clickjacking is a risk. This is not an exhaustive list, by any means, but hopefully you get the idea.

OWASP is a decent place to go to learn more about the incredibly wide range of ways for a web application to be insecure.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.