Catégorie : J2EE

Trop souvent les sites webs réalisés en J2EE font entièrement confiance aux API Java pour sécuriser leurs applications. Si le java permet de se prémunir contre les attaques de type buffer overflow, il est totalement inutile face à deux attaques pourtant très utilisées.

SQL

Les attaques de type SQL injections sont des attaques courantes qui consistent à attaquer la base de données en utilisant un formatage particulier lors de la saisie de formulaire. Bien entendu, si le cas des formulaires est le plus courant, n’importe quelle requête dynamique exécutée dans une base de données peut être susceptible de laisser une faille.

La première règle de sécurité est de ne pas faire confiance aux admins. Avant toute chose, il est très judicieux de n’autoriser l’accès à votre base de données qu’en local. Même si votre base de données n’est utilisée qu’en local, il est judicieux d’avoir un utilisateur autre que root et que l’ensemble de vos utilisateurs disposent de droits réduits et d’un mot de passe sur.

On voit régulièrement des requêtes de la forme:

try {
string login = request.getParameter(“login”);
string password = request.getParameter(“password”);
password = password.replaceAll("\'","");
login = login.replaceAll("\'","");
string request = “SELECT * FROM User WHERE login = ‘” +
login + “’ AND password = ‘” + password + “’”;
Statement statement = con.createStatement();
ResultSet rs = statement.ExecuteQuery(request);
...
} catch(Exception e) {
e.printStackTrace();
}

Ceci ne sécurise en rien votre application, il suffira d’offusquer légèrement les inputs pour palier à cette contremesure. Utiliser plutôt les API java qui disposent de vrai règles de sécurité comme par exemple :

string login = request.getParameter(“login”);
string password = request.getParameter(“password”);
 
PreparedStatement updateMembers = con.prepareStatement(
"UPDATE MEMBERS SET password = ? WHERE login LIKE ?");
updateMembers.setString(1, login);
updateMembers.setString(2, password);
updateMembers.executeUpdate();

Authentification

Java propose plusieurs modules permettant l’authentification. Il est aussi possible d’implémenter son propre système. Cependant dans les deux cas, il y a quelques règles à suivre :

Dans le cas d’un système de login, mot de passe, il est indispensable de vérifier la robustesse du mot de passe entré. Pour rendre son déchiffrement plus difficile, il est aussi indispensable de le saler et d’exécuter une fonction de hachage. Le md5 n’est pas suffisamment sur, préférez au moins le sha1 voir sha256.

Le modèle le plus simple consiste à concaténer le hash du mot de passe avec le login et à refaire un hash dessus. Ceci ne doit être mis en place que sous une session TLS (SSL). En effet, ceci permet de protéger les mots de passe en base de données et de les rendre difficiles à retrouver mais ne permet en aucun cas d’éviter le rejeux de ceux ci. Dans le cas d’une session en claire utilisez un modèle dynamique avec l’envoi d’un challenge (un article est prévu sur une authentification en php sans session TLS).

Enfin, souvent les cookies permettent de sauvegarder un contexte de session. Dans ce cas, utilisez des cookies générés à partir de données dynamiques et chiffrez le contenu avec une clé AES128. De cette manière vous serez sur que seul votre serveur est capable de lire ce qu’il y a dans le cookie. Bien que ceci ne soit valable que si la clé est correctement stockée, préférez stocker les clés directement dans le code plutôt que dans des fichiers de configuration et interdisez l’accès depuis l’extérieur aux dossiers contenant ces fichiers. N’hésitez pas à changer régulièrement les clés.

Sources

Une présentation qui commence à avoir de l’age : AnIntroToAppSecurityInJ2EEEnvironments
Google 🙂