Szukasz sposobu, aby uniemożliwić korzystanie z java.sql.Statement w projekcie

Question

Nasz zespół stara się lepiej przestrzegać wytycznych OWASP, a jednym z zadań jest zapobieganie atakom SQL Injection. Aby to ułatwić, szukałem sposobu automatycznego sprawdzenia, czy w naszej bazie kodowej użyto kodu java.sql.Statement, aby można było go oznaczyć i zmienić, aby korzystał z PreparedStatement.

Nasz proces budowy oparty jest na Mavenie, a my mamy również konfigurację Sonaru do przeprowadzania analiz dotyczących projektu. W Sonarze obowiązują już pewne zasady, aby nie dopuścić do naszych kompilacji, jeśli zostaną spełnione określone progi, więc można to wprowadzić w życie. Widziałem, gdzie mogę ustawić regułę regex dla checkstyle, szukającą importu, ale chciałem sprawdzić, czy były też inne opcje.

Dowolna lokalizacja wzdłuż ścieżki rozwoju/kompilacji działałaby. Gdyby coś w intelli, które oznaczałoby to, coś w procesie budowania maven, lub inny sposób oznaczania tego w sonarze, każdy z nich byłby w porządku.

Dzięki!

Answer 1

Proponuję creating an architectural constraint w Sonar.

W przykładzie pokazano regułę blokującą użycie klas * java.sql. **.

Answer 2

Nie użyłem tego, ale PMD wygląda na to, że może być dobrym narzędziem do tego.

Answer 3

Zamiast wykrywać użycie klasy, można zamiast tego wykryć ich generowanie za pomocą serwera proxy java.sql.Connection? Kiedy otrzymasz połączenie z fabryki, otoczysz je swoim proxy. Twój serwer proxy może być wyposażony w przyrządy do wywoływania metod, ciągów zapytań dziennika i/lub raportowania śledzenia stosu, gdy ludzie używają createStatement() lub innych wywołań poza limitem.

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(); 
    } 

Jeśli nie chce się zbyt ciężki w produkcji a następnie można je zawsze liczyć i mają volatile boolean logBadCall rodzaju flagi tylko włączyć sprawdzanie przez okres czasu, aby skosztować szuka problemów. Być może najpierw pobierzesz próbkę, zaatakujesz 80% lokalizacji, a następnie będziesz miał tylko detekcję na stałe, gdy zadbasz o wysokie obciążenie części aplikacji.

Jeśli nie masz centralnego miejsca na owinięcie połączenia, być może będziesz musiał zawinąć pulę połączeń lub fabrykę w górę łańcucha.

Mam nadzieję, że to pomoże.