Ищете способ предотвратить использование java.sql.Statement в проекте - PullRequest
Новая
       18

Ищете способ предотвратить использование java.sql.Statement в проекте

5 голосов
/ 16 января 2012

Наша команда стремится лучше соответствовать рекомендациям OWASP, и одной из задач является предотвращение атак SQL-инъекций. Чтобы облегчить это, я искал способ автоматической проверки использования java.sql.Statement в нашей кодовой базе, чтобы его можно было пометить и изменить на использование PreparedStatement.

Наш процесс сборки основан на Maven, и мы также настроили Sonar для запуска аналитики проекта. В Sonar уже есть некоторые правила для отказа наших сборок, если соблюдены определенные пороги, так что это может быть реализовано там. Я видел, где можно настроить правило регулярного выражения checkstyle для поиска импорта, но я хотел посмотреть, есть ли другие варианты.

Будет работать любое место на пути разработки / сборки. Если бы в intellij было что-то, помечающее это, что-то в процессе сборки maven или другой способ пометить это в Sonar, то все это было бы хорошо.

Спасибо !!

Ответы [ 3 ]

7 голосов
/ 17 января 2012

Я бы предложил создать архитектурное ограничение внутри сонара.

В этом примере демонстрируется правило, запрещающее использование * java.sql. ** классов.

1 голос
/ 16 января 2012

Я не использовал его, но PMD похоже, что это может быть хорошим инструментом для этого.

0 голосов
/ 17 января 2012

Вместо того, чтобы обнаруживать использование классов, вы могли бы вместо этого обнаруживать их генерацию с помощью java.sql.Connection прокси? Когда вы получаете ваше соединение с завода, вы бы обернули его в прокси. Ваш прокси-сервер будет иметь инструментарий для вызовов методов, записи строк запросов и / или отчета о трассировке стека, когда люди используют createStatement() или другие запрещенные вызовы. 

public class ProxyConnection implements Connection {
    private Connection realConnection;

    public ProxyConnection(Connection realConnection) {
        this.realConnection = realConnection;
    }

    public Statement createStatement() throws SQLException {
       // could the offenders
       createCounter.incrementAndGet();
       // log the callers -- expensive so maybe every 100th or every 10 secs
       logger.info("call to createStatment", new Exception("createStatement"));
       // maybe just throw
       if (throwOnBadCall) {
           throw new SQLException("calls to createStatement aren't allowed"));
       }
       return realConnection.createStatement();
    }

Если вы не хотите слишком загружаться в производственном процессе, вы всегда можете их подсчитать и иметь тип флага volatile boolean logBadCall, чтобы включить проверку только на период времени для выборочного поиска проблем. Возможно, сначала вы делаете выборку, атакуете 80% местоположений, а затем постоянно обнаруживаете, только когда позаботились о частях вашего приложения с высокой загрузкой запросов.

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

Надеюсь, это поможет.

...