Est-il plus sûr de programmer un système client-serveur dans une langue autre que l'anglais?
Je développe un système avec une communication via REST entre le front (JavaScript) et le back-end (Java/Spring) et cette question est apparue.
Cela rend-il ce système plus sûr pour nommer les variables, les URL, etc. dans une langue autre que l'anglais?
J'imagine que c'est possible parce que, puisque les langages de programmation les plus importants sont en anglais, il est probable que la plupart des programmeurs en connaissent au moins un peu. Nommer nos trucs dans une autre langue pourrait rendre le piratage plus difficile car l'attaquant aurait plus de mal à comprendre ce que signifie et fait quoi.
Je n'ai pas pu trouver de résultats sur Google car "programmer" une "langue" ensemble ne permet pas de trouver des résultats sur l'autre sens de "langue".
Techniquement légèrement, oui. Mais:
- Ce serait sécurité par obscurité , ce qui est une mauvaise idée
- Cela ne renforce pas la confiance dans votre produit
- Il serait très facile de comprendre ce qui fait quoi, cela ne prendrait qu'un peu de temps
- Google Translate, vous pouvez simplement utiliser des noms dénués de sens, cela n'aiderait pas beaucoup
- Cela rendrait la maintenance plus difficile
- Cela rendrait les audits très difficiles, car les auditeurs peuvent ne pas comprendre le langage
Tout bien considéré, cela n'en vaut probablement jamais la peine.
Ce ne serait pas sensiblement plus sûr. Les ingénieurs en rétro-ingénierie sont souvent obligés de travailler avec des systèmes qui n'ont aucun nom d'origine intact (le logiciel de production enlève souvent les noms des symboles), de sorte qu'ils s'habituent à gérer avec des noms qui ont été générés par un ordinateur. Un exemple , tiré de Wikipedia, d'un extrait du type de code C décompilé qui est souvent vu:
struct T1 *ebx;
struct T1 {
int v0004;
int v0008;
int v000C;
};
ebx->v000C -= ebx->v0004 + ebx->v0008;
Les gens qui ont l'habitude de travailler avec ce type de représentation ne sont pas dupes de l'utilisation de variables et telles qu'on leur donne des noms non pertinents. Ce n'est pas spécifique au code compilé, et l'utilisation de C n'était qu'un exemple. Les ingénieurs inverses en général sont habitués à comprendre un code qui n'est pas intuitif. Peu importe si vous utilisez JavaScript, Java ou C. Cela n'a même pas d'importance s'ils n'analysent que la communication avec l'API elle-même. L'ingénierie inverse ne sera pas dupe de l'utilisation de noms de variables ou de fonctions aléatoires ou non pertinents.
Pas vraiment - toutes les fonctions intégrées seront toujours en anglais, il ne faudrait donc pas beaucoup d'efforts supplémentaires pour déterminer ce que vos variables vont représenter. Cela pourrait ralentir légèrement quelqu'un, mais étant donné que les gens parviennent toujours à procéder à une rétro-ingénierie du code avec des variables à caractère unique partout, ou qui a été exécuté via des obscurcisseurs, permuter le langage utilisé pour les variables et les fonctions signifie simplement faire une recherche-remplacement une fois que vous avez déterminé à quoi sert l'une de vos variables, puis répétez jusqu'à ce que vous ayez suffisamment compris.
C'est la sécurité à travers l'obscurité et retardera un attaquant dédié toutes les cinq minutes.
Si vous voulez confondre un attaquant, nommer les choses leur contraire ou quelque chose sans rapport aurait le même effet. Ainsi, votre fonction "créer un utilisateur" pourrait être nommée "BakeCake". Maintenant, vous pouvez répondre vous-même au niveau de sécurité que cela vous apporte. En fait, ce serait plus sécurisé, car il ne peut pas être vaincu en utilisant simplement un dictionnaire.
Oui, au début, ce serait confus, mais on regarde le système en fonctionnement et tout devient clair comme du cristal immédiatement.
Votre système DOIT être sécurisé par lui-même . S'il repose sur le javascript côté utilisateur passant un paramètre avec la valeur "sésame ouvert", vous le faites mal.
Vous devez développer le programme dans la langue qui vous convient le mieux (par exemple, en fonction de vos compétences de codeur, de la cohérence avec votre base de code ou même des termes que vous utilisez).
D'autres réponses ont déjà souligné comment cela n'assure pas vraiment la sécurité. Si vous voulez créer un programme sécurisé, plutôt que de vous soucier des hackers potentiels lisant facilement votre code et apprenant un trou secret, vous devriez probablement vous soucier davantage de le rendre lisible pour les personnes qui l'auditent .
S'il existe un paramètre de fonction appelé nonce et un commentaire indiquant comment nous nous assurons qu'il est unique parmi les demandes, mais qu'il n'est pas envoyé sur la demande, vous pouvez être sûr qu'il s'agit d'une erreur. En fait, avoir ce code facilement lisible diminuera les chances que ce paramètre soit supprimé/vide (après tout, tout a fonctionné sans lui ...), ou si cela se produit vraiment, rend plus facile qu'un autre de vos les développeurs remarquent le problème.
(Des tiers peuvent également vous en faire part. Probablement, il y aura plus de gens qui le regarderont de manière décontractée que ceux qui essaient de le briser. Un attaquant aléatoire commencera très probablement par lancer un outil automatisé et en espérant qu'il trouve quelque chose. )
TL; DR: produire du code lisible. Pour les personnes qui devraient s'en occuper. En cas de doute, vous devriez préférer celui que la plupart des gens connaissent.
Cela pourrait même aggraver les choses en rendant le système plus difficile à entretenir.
Prenons un exemple extrême inspiré par l'histoire et communiquez entre les extrémités avant et arrière dans Navajo . Quand (pas si) vous devez patcher le code, vous devez soit:
- travailler avec ce qui est pour vous un non-sens (avec la possibilité supplémentaire de bugs/fautes de frappe et il faut plus de temps pour travailler sur du code non intuitif), ou
- embaucher/garder des programmeurs parlant couramment Navajo (une combinaison de compétences rare et potentiellement chère, peut-être impossible de trouver un entrepreneur)
Je voudrais également noter que dans la plupart des cas pour javascript côté client, le script tel qu'il a été développé (avec des noms de variables significatifs, etc.) serait `` minifié '' afin d'augmenter les performances sur le client (taille de fichier plus petite à télécharger).
Dans ce cadre, la plupart des noms de variables sont réduits à des caractères uniques et le plus d'espace possible est supprimé. Cela devient à peu près aussi illisible que tout ce que vous pourriez écrire.
Je voudrais également noter que chrome (par exemple) a des méthodes qui prennent un fichier `` moins lisible par l'homme '' comme celui-ci et le `` joliment imprimé '', ce qui rend beaucoup plus facile de comprendre ce qui se passe sur.
En bref, le langage humain que vous utilisez pour écrire votre code côté client ne fait vraiment pas une grande différence.
Si l'on en croit les médias, la majorité des hackers sont russes, chinois, nord-coréens, ils sont donc déjà opérant sous le "handicap" de devoir pirater les systèmes occidentaux dans un pays non natif Langue. Par conséquent, à moins que vous ne choisissiez quelque chose d'incroyablement obscur, comme dans le film Windtalkers cela ne fera aucune différence pour eux. Mais l'effort supplémentaire pour vous signifie moins de temps pour trouver et corriger les bogues, donc si quelque chose cette stratégie rendrait votre sécurité plus faible.
Plusieurs réponses ont (à juste titre) souligné qu’il s’agissait de "sécurité par le biais de l’obscurité", qui n’est en fait pas une forme de sécurité. Il est plus sûr de supposer que l'attaquant a entièrement annoté le code source en face d'eux tout en attaquant activement.
Le logiciel est "sécurisé" lorsque la connaissance de tout ce qui peut être connu avant une demande/transaction/session est de notoriété publique ET cela n'a aucun impact sur la sécurité réelle du produit.
Le code source doit être supposé être de notoriété publique, ne serait-ce que parce que les employés mécontents ne sont pas repris et abattus lorsqu'ils sont licenciés. Ou comme on le dit souvent: "La seule façon pour deux personnes de garder un secret, c'est si l'une d'entre elles est morte." Ainsi, toute "connaissance spéciale" qui est cachée par une obscurcissement de quelque nature que ce soit doit être supposée être devenue une "connaissance générale" dès sa production.
La sécurité, à la base, n'est rien d'autre que "dire ce que vous faites et faire ce que vous dites". L'analyse de la sécurité - l'audit du code et les programmes d'évaluation formels, tels que ceux menés dans le cadre des Critères communs - nécessitent que les mécanismes d'exécution d'une action soient bien documentés et que toutes les transitions d'un état sécurisé à un autre état sécurisé ne soient possibles que lorsque toutes les exigences sont satisfait. Un risque avec l'obscurcissement de toutes sortes est que ces exigences sont obscurcies par un codage intelligent - voir l'exemple de "create_user ()" échouant parce que c'est "secrètement" la "suppression d'utilisateur" ou "renommer l'utilisateur" ou quelque chose d'autre. Pour un exemple concret de la difficulté de ce changement de nom sur le cerveau, il existe des tests en ligne dans lesquels vous devez lire le nom d'une couleur imprimée à l'écran dans une couleur différente. Par exemple, le mot "ROUGE" écrit en bleu fera en sorte qu'un certain nombre de personnes diront "BLEU" au lieu de "ROUGE".
Cela pourrait ne pas être pertinent. Considérez le scénario où vous codez en (par exemple) italien au lieu de l'anglais, mais la plupart de vos clients sont en Italie, naturellement les pirates italophones ont une motivation/récompense plus élevée à vous attaquer.
Dans ce scénario, le codage dans une autre langue n'a aucun effet ou peut même faciliter le piratage.