Will such a php code help protect against sql injections and XSS, what vulnerabilities does it have?

Question

PHP

$this->post = str_secure($_POST);
$this->get = str_secure($_GET);
$this->session = str_secure($_SESSION);
$this->cookie = str_secure($_COOKIE);

 function str_secure($str, $int=0)
{
    if (is_array($str))
    {
    foreach($str as $k=>$s)
    $str[str_secure($k)]=str_secure($s);}
    else{
$str = str_replace(array("\r\n","\r","\n","\t"), ' ', $str);
    $str = trim(strip_tags($str));
    $str=str_replace("'",''', $str);
    $str=str_replace('"','"', $str);
    $str=addslashes($str);  
    if ($int==1){
     $str = abs((int)($str));    
    }}
    return $str;
}

I understand that it is correct to use bindParam and placeholders, but I cannot rewrite the sql queries themselves, since there are a lot of them.
The project does not use MySQLi, so real_escape_string would work.
I'll probably write one myself, if $_GET['param1'] should be only integer, then I'll have to describe it separately, otherwise the line can be pushed in.

Answer 1

All this idiotic code does is corrupt the incoming data.
I don't even know if it's worth explaining. After all, 100500 times already explained.
But the most, of course, hell is the answers.
When you start explaining to these puppies what an injection is and how to protect yourself from it, everyone starts to hiss - "Yes, we already know, scientists!" But when it comes down to it - they give out such hell, which becomes clear. Not scientists, but all the same monkeys who memorized a couple of spells, but traditionally do not understand how these spells work, or what they are for.
Those who propose to cut quotes from quote need to cut something themselves.
And this awkward feeling when in 2015 you hear the most cherished mantra of Madagascar hamadryas: "mysql_real_escape_string is sizzling with injection!". There is, damn it, such an "outdated", but still strong archangel with a flaming sword, and smashes the adversary right in the crown - this is how the average user of the pohape imagines the principle of this function.

Answer 2

Will not help. You have no idea what SQL injection is.
If it were, then you would know that you do not need to defend yourself from them. You just need to not confuse data and SQL code.
Article: habrahabr.ru/post/148701

Answer 3

Are you inventing magic quotes again?
From the most stupid attacks will help. Over9000 will add problems to itself.
addslashes can be pierced by attacking the encoding.
You write as if these two independent statements are cause and effect.
Time is SQL - means there is a DB driver. I don't remember a single driver that, even with prepared queries, didn't provide an escape method.

Answer 4

What only people do not go to not use PDO.
If such a booze has already gone - why don’t you remove non-printable characters?
+ html_entity_decode you can go through every fireman.

Answer 5

1) Use ::quote() and remove the outer quotes
2) Brazenly use the deprecated but still present mysql_real_escape_string()

Answer 6

> The project does not use MySQLi, so real_escape_string would work.
What is used? MySQL also has a function mysql_real_escape_string

Answer 7

php.net/manual/ru/function.filter-var.php for help