Czy uśpienie wejścia funkcji hibernacji createCriteria()?

Question

Przenieś dziś przez jakiś kod, który wykorzystuje Hibernate do wykonania zapytania. Kwerenda używa wartości przesłanej z formularza. Zastanawiało mnie, czy ten rodzaj kodu "oczyszcza" jego dane wejściowe.

public List<School> search(String query) { 
    Session session = this.getCurrentSession(); 
    query = "%" + query + "%"; 
    Criteria criteria = session.createCriteria(getPersistentClass()); 
    criteria.createAlias("country", "a"); 
    Criterion nameCriterion = Restrictions.ilike("name", query); 
    Criterion cityCriterion = Restrictions.ilike("city", query); 
    Criterion countryCriterion = Restrictions.ilike("a.name", query); 
    Criterion criterion = Restrictions.or(Restrictions.or(nameCriterion, cityCriterion), countryCriterion); 
    criteria.add(criterion); 
    return criteria.list(); 
} 

Czy to jest bezpieczne?

Answer 1

Kwerendy kryteriów hibernacji Kwerendy są ciche, bezpieczne pod względem iniekcji Sql, ponieważ przekazują ciągi znaków jako parametr podczas wykonywania dowolnego pobierania. Nawet, Hql jest cicho bezpieczny, chyba że zbudujesz zapytanie poprzez literał łańcuchowy.

Aby uzyskać więcej informacji, należy spojrzeć na kwerendy uruchamiane na poziomie bazy danych, włączając rejestrowanie w trybie hibernacji sql.

Answer 2

Jeśli myślisz o atakach SQL injection, to tak, interfejs API Hibernate Criteria jest bezpieczny.

Generuje zapytanie bazowe, najpierw kompilując je z podanych pól zapytania i dopiero po zastosowaniu parametrów zapytania (powinno używać klasycznego PreparedStatement). W ten sposób sterownik JDBC będzie wiedział, która część zapytania to pola, a która część to parametry. Następnie kierowca będzie dbał o higienę parametrów.

Trudno sobie radzić z ograniczeniami SQL zastosowanymi na Criteria, jeśli chcesz umieścić tam parametry. Na przykład

String vulnerable = //parameter from user interface 

criteria.add(
    Restrictions.sqlRestriction("some sql like + vulnerable") //vulnerable 

criteria.add(
    Restrictions.sqlRestriction("some sql like ?", 
       vulnerable, Hibernate.STRING)) //safe 

W tym przypadku parametr vulnerable może „przeciek” do kwerendy pola udział i być pomijany przez sterownik JDBC sprawdzanie jak w normalnym zapytania SQL wrażliwej.

Answer 3

Hibernacja jest przydatna do odkażania danych wejściowych, ale dane wejściowe do odkażania nie są uważane za najlepszą praktykę zapobiegania atakom wstrzykiwania SQL. Wraz z rozwojem kodu w czasie, będziesz musiał pamiętać, aby zmienić higienę Hibernacji jako bazę danych i zmianę aplikacji po stronie klienta; to pozostawia wiele miejsca na błędy i każdy błąd może zagrozić twojej bazie danych.

Aby zapobiec atakom typu SQL injection, lepiej użyć przygotowanych instrukcji. W przygotowanym oświadczeniu twoja aplikacja po stronie klienta złoży zapytanie inne niż SQL i pozwoli twojemu serwerowi wygenerować instrukcję SQL.

Na przykład, jeśli użytkownik chce, aby wszyscy użytkownicy w mieście „Dallas”, a następnie aplikacja po stronie klienta powinna złożyć wniosek podobny do nazwa_użytkownika równa się „Dallas” a następnie serwer może generować:

SELECT * FROM users WHERE name='Dallas'