I nostri sviluppatori hanno lasciato una sorpresa nella gestione dell'accesso utente. Vale a dire:
// java
List users = hibernate.find("from Users where username = '"+formUsername+"'";
if (users.length==0) { return BAD_USER; }
if (!checkPassword(users.get(0).getPassword(), formPassword)) {
return BAD_USERNAME_PASSWORD_COMBO;
}
// continue to mark session as authenticated
Ora, ovviamente, è possibile iniettare nella query. Ma questo è il linguaggio HQL. Se si trattasse di SQL, e conoscevo la struttura del database, avrei potuto bloccare un'operazione "unione" e accedere a qualsiasi account. Ma non vedo proprio quale tipo di HQL dannoso possa aggrapparmi qui, per far accadere davvero qualcosa di brutto.
Sì, abbiamo già sostituito questo codice per utilizzare i parametri, ma sono solo curioso di sapere cosa si può fare in quella situazione. Gli esempi HQL che ho visto riguardano l'aggiunta dell'operatore "OR", che in questo caso non sarà di aiuto.
Inoltre, il database sottostante è postgres, quindi tutte le funzioni di postgres sono corrette.
P.S.
C'era una domanda su come il sindacato avrebbe aiutato. Data la struttura della tabella di (id, nome utente, password) e la query SQL di:
select id, username, password from users where username = ...
Posso inserire:
' union select 1, 'root', 'synthetic_password
e il completo SQL eseguito diventerà:
select id, username, password from users where username = '' union select 1, 'root', 'synthetic_password'
La prima selezione non restituirebbe alcun record e la seconda restituirà un record che il codice JAVA leggerà e popolerà i suoi bean da esso. Quindi confronterà la password, ma dato che ho fornito i dati della password in entrambi gli SQL iniettati e nel modulo, essi verificheranno.