2013-04-05 10 views
6

È venuto in qualche codice oggi che utilizza Hibernate per eseguire una query. La query utilizza un valore inviato da un modulo. Mi ha fatto incuriosire se questo tipo di codice "disinfetti" il suo input o meno.La funzione createCriteria() di Hibernate immette input?

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

È sicuro?

risposta

4

Hibernate Criteria Le query sono silenziose in termini di Sql Injection poiché passano le stringhe come parametri durante l'esecuzione di qualsiasi recupero. Anche, Hql è silenzioso a meno che non si costruisca la query tramite string letterale.

Per ulteriori dettagli, è necessario dare un'occhiata alle query che vengono attivate a livello di database attivando la registrazione sql di ibernazione.

+0

Accade così che stavo guardando l'SQL generato (che è quello che mi ha ricordato di controllare queste risposte) e hai assolutamente ragione. – Marvo

5

Se si pensa agli attacchi di SQL injection, allora sì, l'API di Hibernate Criteria è sicura.

Genera la query sottostante compilandola prima dai campi di query specificati e solo dopo aver applicato i parametri di query (dovrebbe utilizzare un classico PreparedStatement). In questo modo il driver JDBC saprà quale parte della query sono campi e quale parte sono parametri. Quindi l'autista si prenderà cura di disinfettare i parametri.

Difficile si dovrebbe prestare attenzione con le restrizioni SQL applicate su Criteria, se è necessario inserire i parametri lì. Ad esempio

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 

In questo caso il parametro vulnerable potrebbe "fuga" a query campi parte ed essere bypassato da driver JDBC controllando come in una normale query SQL vulnerabile.

+0

Ah, ottimo punto sulle restrizioni. – Marvo

+0

Vorrei poter accettare entrambe le risposte. Ankit ha risposto per primo, così gli ho dato il segno di spunta. – Marvo

1

Hibernate è utile per disinfettare gli input ma gli input di sanificazione non sono considerati la migliore procedura per prevenire attacchi di SQL injection. Man mano che il tuo codice si sviluppa nel tempo, dovrai ricordarti di cambiare i servizi igienici di Hibernate mentre il database e le applicazioni sul lato client cambiano; questo lascia un sacco di spazio per errori e qualsiasi errore può compromettere il tuo database.

Per evitare attacchi di SQL injection, è meglio utilizzare istruzioni preparate. In una dichiarazione preparata, l'applicazione client eseguirà una richiesta non SQL e consentirà al server di generare la propria istruzione SQL.

Ad esempio, se un utente vuole che tutti gli utenti della città "Dallas", quindi l'applicazione client-side devono fare una richiesta simile a nome utente uguale "Dallas" e quindi il server in grado di generare:

SELECT * FROM users WHERE name='Dallas' 
Problemi correlati