Sécurité des applications Java
Fermé
MegaTruite
Messages postés
27
Date d'inscription
mardi 30 septembre 2014
Statut
Membre
Dernière intervention
7 septembre 2016
-
6 sept. 2016 à 10:29
ElementW Messages postés 4816 Date d'inscription dimanche 12 juin 2011 Statut Contributeur Dernière intervention 5 octobre 2021 - 7 sept. 2016 à 21:38
ElementW Messages postés 4816 Date d'inscription dimanche 12 juin 2011 Statut Contributeur Dernière intervention 5 octobre 2021 - 7 sept. 2016 à 21:38
A voir également:
- Sécurité des applications Java
- Waptrick java football - Télécharger - Jeux vidéo
- Java apk - Télécharger - Langages
- Mode securite - Guide
- Url masquée pour votre sécurité - Forum TV & Vidéo
- Jeux java itel football - Télécharger - Jeux vidéo
1 réponse
KX
Messages postés
16734
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
24 avril 2024
3 015
6 sept. 2016 à 20:57
6 sept. 2016 à 20:57
Bonjour,
"fautes les plus répétées par des développeurs Java nuisant à la sécurité"
La majorité des fautes récurrentes ne sont pas spécifiques au Java, mais à l'informatique en générale (injection SQL, ressources non libérées, etc.)
"failles inhérentes au langage (et pas à la JVM)"
C'est bizarre de distinguer les deux, car au final c'est la JVM qui fait le boulot, la plupart des risques applicatifs sont liés à une méconnaissance du comportement de la JVM (pollution de la heap, interblocage, etc.)
"procédures d'investigation white box/black box"
Puisque tu es côté client, avec l'application accessible sur ton poste, tu peux regarder le code dedans... du coup la boîte noire est facile à ouvrir !
Alors les mots de passe en dur dans le code c'est sûr qu'on oublie (mais ce n'est pas spécifique à Java non plus).
Je t'invites à lire cet article : Générer des rapports sur la qualité d'un projet
Si tu as un projet Java sous la main, je t'invites à faire tourner une analyse dessus et de voir les différentes erreurs qui peuvent t'être remontées, ce sera plus parlant.
Sans oublier d'aller voir les différentes documentations des règles (pourquoi elles existent et comment les corriger), le lien pour PMD est dans l'article, celui de SonarQube pourrait t'intéresser aussi.
Exemple : voici les 7 erreurs les plus graves pour SonarQube.
On y retrouve sans surprise l'injection SQL, les mots de passes en dur, l'utilisation des algorithmes de sécurité obsolètes, etc.
Remarque : le niveau de gravité est souvent à nuancer... typiquement une analyse Sonar remonte beaucoup de faux positifs, car dans le contexte de l'application ça n'a pas de sens (mais il vaut mieux trop d'alertes que passer à côté d'une faille importante).
"fautes les plus répétées par des développeurs Java nuisant à la sécurité"
La majorité des fautes récurrentes ne sont pas spécifiques au Java, mais à l'informatique en générale (injection SQL, ressources non libérées, etc.)
"failles inhérentes au langage (et pas à la JVM)"
C'est bizarre de distinguer les deux, car au final c'est la JVM qui fait le boulot, la plupart des risques applicatifs sont liés à une méconnaissance du comportement de la JVM (pollution de la heap, interblocage, etc.)
"procédures d'investigation white box/black box"
Puisque tu es côté client, avec l'application accessible sur ton poste, tu peux regarder le code dedans... du coup la boîte noire est facile à ouvrir !
Alors les mots de passe en dur dans le code c'est sûr qu'on oublie (mais ce n'est pas spécifique à Java non plus).
Je t'invites à lire cet article : Générer des rapports sur la qualité d'un projet
Si tu as un projet Java sous la main, je t'invites à faire tourner une analyse dessus et de voir les différentes erreurs qui peuvent t'être remontées, ce sera plus parlant.
Sans oublier d'aller voir les différentes documentations des règles (pourquoi elles existent et comment les corriger), le lien pour PMD est dans l'article, celui de SonarQube pourrait t'intéresser aussi.
Exemple : voici les 7 erreurs les plus graves pour SonarQube.
On y retrouve sans surprise l'injection SQL, les mots de passes en dur, l'utilisation des algorithmes de sécurité obsolètes, etc.
Remarque : le niveau de gravité est souvent à nuancer... typiquement une analyse Sonar remonte beaucoup de faux positifs, car dans le contexte de l'application ça n'a pas de sens (mais il vaut mieux trop d'alertes que passer à côté d'une faille importante).
7 sept. 2016 à 11:43
Merci pour votre retour. Concernant le black/white boxing, j'aimerai également pouvoir procéder en supposant que le code est obfusqué, donc bien évidemment je ne peux me permettre de ne faire que de l'audit de code. Un des logiciels concernés, de plus, contient un nombre de lignes beaucoup trop important pour être analysé par une seule personne (même avec des outils) dans des délais raisonnables.
7 sept. 2016 à 19:03
Du coup que veux tu ?
Parce que si même les outils ne peuvent pas t'aider qui le pourra ?
Au départ ta question partait sur une recherche bibliographique des erreurs mes plus fréquentes, donc les listes de règles PMD ou Sonar sont pertinentes puisqu'elles détaillent chaque erreur en documentant les bonnes pratiques et fournissant aux outils qui les utilisent des pattern de détection automatique.
Quant à l'obfuscation ça ne change pas grand chose. Ça masque la partie spécifique du programme, mais les erreurs sont souvent dans l'utilisation des couches de bas niveau (requêtes SQL, manipulation de fichiers etc.) et ces codes là restent visibles et donc analysables.
7 sept. 2016 à 21:38
J'ai à plusieurs reprises compris et réimplémenté le fonctionnement de systèmes (simples) de chiffrement ou d'obfuscation/mélange de données, en Java "classique" (bytecode JVM) comme en Java d'Android (bytecode Dalvik en représentation Smali).
Petit exemple sur mon profil GitHub, pour l'idée. Dans le cas présent, l'obfuscation m'a à peine ralenti.