«Небезопасная ошибка зависимости при работе с ключом -T» с помощью cicindela2 - PullRequest
Новая
       59

«Небезопасная ошибка зависимости при работе с ключом -T» с помощью cicindela2

0 голосов
/ 05 сентября 2018

Я применяю cicindela2 рекомендованный движок

Используется Apache mod_perl и модуль Perl DBI.

Вот примерный пример того, как это работает

  • Ввод данных обработчиком записи

  • Данные передаются через цепочку фильтров для пакетной обработки

  • Временные таблицы выводятся из пакетной обработки

  • Результат рекомендации запрашивается путем доступа к Рекомендующему Обработчику, который запускает действие Рекомендатора

Я настроил агрегацию и запустил пакетный скрипт проекта. Я знаю, что пакетная обработка прошла успешно, потому что я увидел результаты обработки из БД. Но когда я попытался получить доступ к результату рекомендации с помощью URL, который запускает обработчик рекомендаций, я увидел пустую белую страницу и в журнале было написано

FATAL: небезопасная зависимость в параметре 1 DBIx :: ContextualFetch :: db = HASH (0x7f2a76169e78) -> вызов метода prepare_cached при запуске с ключом -T в строке /usr/local/share/perl5/Ima/DBI.pm 398.

Это где ошибка была выброшена из Ima::DBI базовый модуль

/ USR / местные / доли / perl5 / ИМА / DBI.pm. 

sub _mk_sql_closure {

    my ($class, $sql_name, $statement, $db_meth, $cache) = @_;

    return sub {
        my $class = shift;
        my $dbh   = $class->$db_meth();

        # Everything must pass through sprintf, even if @_ is empty.
        # This is to do proper '%%' translation.

        my $sql = $class->transform_sql($statement => @_);

        return $cache    # Line 398
            ? $dbh->prepare_cached($sql)
            : $dbh->prepare($sql);
    };
}

Кажется, что подготовленный программой SQL-запрос небезопасен, верно?

В чем причина этой ошибки?

Это связано с функцией управления кешем DBI?

Будет ли это решено, если я регулярно очищаю кеш?

Кроме того, я попытался записать сгенерированный оператор SQL, но вывод не удался, даже если я поместил что-то вроде $LOGGER->warn("123") в подпрограмму handle обработчика Recommended.

Почему журнал вышел из строя и как его правильно зарегистрировать?

1 Ответ

0 голосов
/ 05 сентября 2018

Insecure dependency... while running with -T switch - это способ, которым Perl сообщает вам, что вы работаете с taint mode active и пытаетесь что-то сделать с испорченными данными, которые могут быть потенциально небезопасными. В этом конкретном случае, $sql испорчен, потому что часть или весь его контент поступил из внешних источников программы - возможно, из пользовательского ввода, хотя его также можно было прочитать из файла.

Чтобы исправить это, вам нужно подумать о том, откуда взялась $sql, чтобы вы могли найти подходящий способ его очистки.

В наиболее вероятном сценарии вы попросили пользователя ввести поисковые термины, а затем вставили эти термины непосредственно в строку SQL. В общем, это плохая идея, так как она открывает вам возможность атак с использованием SQL-инъекций. (Обязательная Таблица Бобби ссылка.) Пересмотрите свою обработку SQL, чтобы использовать Заполнители SQL вместо вставки пользовательского ввода в предложение WHERE, и эта уязвимость должна исчезнуть.

Если испорченные данные попадают в $sql каким-либо другим способом, вам нужно очистить испорченные данные с помощью регулярного выражения, чтобы проверить их и захватить проверенные данные, а затем назначить захваченные данные вашей переменной. например., 

my $tainted = <STDIN>;
$tainted =~ /([A-Z]*)/; # Only allow uppercase characters
my $clean = $1;  # No longer tainted because it came from $1

Если вам нужно выбрать этот маршрут, НЕ используйте .* в качестве регулярного выражения, чтобы без серьезного и серьезного рассмотрения данных, потому что, если вы просто слепо принимаете любое и все данные, вы будете отбрасывать все преимущества, предоставляемые в режиме Taint.

...