Поможет ли такой php-код защититься от sql-инъекций и XSS, какие в нём есть уязвимости?

$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;
}

Понимаю, что правильно использовать bindParam и плейсхолдеры, но сами sql-запросы переписать не смогу, так как их очень много.
В проекте не используется MySQLi, так бы real_escape_string заюзал.

Одну, пожалуй, сам напишу, если $_GET['param1'] должен быть только целочисленный, то придётся отдельно описать его, иначе строку могут впихнуть.
  • Вопрос задан
  • 3880 просмотров
Пригласить эксперта
Ответы на вопрос 7
FanatPHP
@FanatPHP
Чебуратор тега PHP
Все что делает этот идиотский код - это портит входящие данные.
Я даже не знаю, стоит ли объяснять. Ведь 100500 раз уже объясняли.

Но самый, конечно ад - это ответы.

Когда начинаешь этим щеночкам объяснять, что такое инъекция, и как от нее защититься, все начинают шипеть - "да знаем уже, учоные!". Но когда доходит до дела - такой ад выдают, что становится понятно. Не учёные, а все те же обезьяны, которые вызубрили пару заклинаний, но по традиции не понимают, ни как эти заклинания работают, ни для чего они нужны.

Тем, кто предлагает отрезать кавычки от quote, надо самим что-нибудь отрезать.

И это неловкое чувство, когда 2015 году слышишь самую заветную мантру мадагаскарских гамадрилов: "mysql_real_escape_string зашышает от ынъекцый!". Стоит, блин, такой "устаревший", но еще крепкий архангел с пылающим мечом, и разит супостата прямо в темечко - вот так представляет себе принцип работы этой функции средний пользователь похапе.
Ответ написан
OnYourLips
@OnYourLips
Не поможет. У вас нет ни малейшего представления, что такое SQL-инъекции.
Если бы было, то вы бы знали, что защищаться от них не надо. Надо просто не путать данные и SQL-код.

Статья: habrahabr.ru/post/148701
Ответ написан
Melkij
@Melkij
PostgreSQL DBA
Вновь магические кавычки изобретаете?
От самых тупых атак поможет. Самому себе проблем добавит over9000.
addslashes пробить можно атакой на кодировку.

В проекте не используется MySQLi, так бы real_escape_string заюзал.

Вы так пишете, как будто эти два независимых высказыванию есть причина и следствие.
Раз есть SQL - значит есть драйвер БД. Не помню ни одного драйвера, который бы даже при наличии подготовленных запросов не предоставлял экранирующий метод.
Ответ написан
index0h
@index0h
PHP, Golang. https://github.com/index0h
На что только люди не идут, что бы не использовать PDO.

Если уже пошла такая пьянка - почему непечатаемые символы не убираешь?
+ html_entity_decode можно пройтись на всякий пожарный.
Ответ написан
nazarpc
@nazarpc
Open Source enthusiast
1) Использовать ::quote() и убирать крайние кавычки
2) Нагло использовать устаревшую, но всё ещё присутствующую mysql_real_escape_string()
Ответ написан
WebSpider
@WebSpider
> В проекте не используется MySQLi, так бы real_escape_string заюзал.
А что используется? В MySQL как бы тоже есть функция mysql_real_escape_string
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы