1. PHP / Говнокод #7294

    +157

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    function parse_req($value) 
    {
        global $log_conf;
        if(!is_array($value)) 
        {
            if(preg_match("#UNION|OUTFILE|SELECT|ALTER|INSERT|DROP|TRUNCATE#i", base64_decode($value))) 
            {
                if($log_conf['queryError'] == 1) writeInLog('Попытка произвести SQL-Inj текст: '.$value, 'sql');
                //fatal_error(_ERROR, _UNKNOWN_ERROR);	
    			die();
            }
        }
        else
        {
            foreach($value as $val) 
            {
                parse_req($val);
            }
        }
    }

    Баян конечно, но всегда удивляюсь на что они рассчитывают?
    Как-бы борится с SQL-Injection...

    Запостил: nethak, 20 Июля 2011

    Комментарии (18) RSS

    • А это он себе жизнь упростил)))

      function showText($text)
      {
      return stripslashes($text);
      }


      Заметьте какая колоссальная разница! В целых 4 символа, бережёт себя...
      Ответить
    • > 'Попытка произвести SQL-Inj текст: '
      :D:D:D
      Ответить
    • Да грёбаный попугай!
      Когда они prepared statements использовать научатся?
      Ответить
      • И чо? При чем тут prepared statements и SQL-inj? Дурак что угодно может сломать.
        Ответить
        • как раз prepared statements от SQL-inj или вы не в курсе???
          Ответить
          • Ну это вроде как побочный эффект ps, я так понял, что благодаря отделению данных от запроса методом каких-нить placeholders можно экранировать данные.
            А основная задача ps кажись ускорение выполнения однообразных запросов.
            Ответить
            • > побочный эффект
              почитали бы. неужто не используете?
              вообще-то prepared statements эффективно решают обе задачи
              Ответить
              • Использую, в рельсах совсем недавно прикрутили :)
                Но все равно не уверен, что если не использовать placeholders, а в подготавливаемом запросе интерполировать какую-нить переменную извне, то есть подготовить запрос с инъекцией.
                Ответить
                • экранируются только параметры, подставляемые в placeholders, в других местах а вдруг так и должно быть
                  Ответить
              • Надо лучше сейчас поиграться с этим.
                Ответить
    • А вот в PHP есть замечательный PDO. По-моему что-то не так сделать там просто нереально. Сам класс экранирует даже имя/пароль для базы.
      Ответить
      • единственное, скотина, не окавычивает имена. т.е. INSERT INTO ? не пройдет.
        Ответить
        • SELECT * FROM entries WHERE id IN(' . $in_query . ') ORDER BY FIND_IN_SET(id,"' . $in_query_ids .'")
          Знакомо, еще вот такой фигней приходится заниматься, когда число параметров для IN меняется. Это так выдираются результаты поиска сфинкса из базы. Лучшего решения не нашел.
          Ответить
          • Я делал str_repeat('?,', count($args)) (с отбрасыванием лишней запятой) и потом просто передавал массив вариантов как параметр. Но тоже не совсем, как мне кажется...
            Ответить
        • а должно? специально же так сделали от шаловливых игрунков!
          Ответить
          • Не от "шаловливых игрунков", а по логике работы подготовленных выражений. На этапе подготовки составляется план выполнения запроса, а как его составишь, если неизвестно, о каких таблицах идёт речь?
            Ответить
            • мокроносые игрунки не знают таких слов, они думают что prepared statements это такой sprintf
              Ответить

    Добавить комментарий