J'ai vu une réponse d'un autre POST :
chaîne a été largement utilisé comme paramètre pour de nombreuses classes Java par exemple. Pour ouvrir la connexion réseau, pour ouvrir la connexion de la base de données, ouvrir des fichiers. Si la chaîne n'est pas immuable, cela conduirait à une menace grave de la sécurité.
Je pense que vérifier la chaîne avant utilisation, cela résoudrait le problème. Pourquoi est-ce une raison pour laquelle la chaîne est conçue pour être immuable?
Quelqu'un peut-il me donner un exemple de code concret?
3 Réponses :
Le message que vous avez lié à des liens supplémentaires à ce poste, où le problème est expliqué plus en détail:
En général, il est plus facile d'écrire et d'examiner le code sensible lorsque les valeurs ne changent pas, car Il y a moins d'entrelages d'opérations susceptibles d'affecter le résultat.
Imagine code comme Le code fait des vérifications pour empêcher une escalade de l'autorité, mais cela ne tient que si Si les deux premières déclarations ont été commandées, cela ne serait pas un problème, de sorte que l'insécurité se pose, en partie, d'une mauvaise entrelacement. Mais un autre code peut appeler cette fonction et supposer que nom n'est pas modifié, il peut donc avoir à exécuter et réacquer les contrôles de validité. si Non seulement la quantité de code qui doit fonctionner correctement Plus grand, mais un mainteneur qui rend les modifications locales à une seule fonction pourrait affecter la sécurité d'autres fonctions lointaines. Les effets non locaux rendent la maintenance du code. Le maintien des propriétés de sécurité est toujours désagréable car les vulnérabilités de sécurité sont rarement évidentes, la mutabilité peut entraîner la dégradation de la sécurité au fil du temps. Pourquoi est-ce une raison pour laquelle la chaîne est conçue pour être immuable?
c'est séparé de la raison pour laquelle c'est une mauvaise sécurité-sage. Il est largement convaincu que les programmes écrits en langues avec des types de chaînes immuables facilement disponibles font moins de copies tampon inutiles que celles que ne pas. Des copies de tampon inutiles consomment de la mémoire, provoquent une barnve GC et peuvent entraîner des opérations simples sur les grandes intrants pour effectuer beaucoup pire que sur de petites entrées. Il est également considéré comme il est plus facile d'écrire des programmes corrects lors de l'utilisation de Cordes immuables, car il est peu probable que vous n'ayez pas échoué à copier de manière défensive un tampon. isalphanumérique (nom) est vrai lorsque l'argument de exécutstatement est appelé. String n'est pas immuable, il aurait peut-être été modifié par lookeztation . Pour être sûr que la vérification de la sécurité fonctionne, il existe une quantité de code beaucoup plus importante qui doit fonctionner correctement pour que ce code soit sécurisé contre l'injection SQL.
Ou pire, peut-être que la chaîne est visible pour un autre fil, qui pourrait ensuite modifier sa valeur entre la vérification de l'intégrité et l'utilisation - même sans un appel intermédiaire clair!
C'est la plus ancienne spoof de sécurité dans le livre: présentez-vous un certain parm au système d'exploitation, demandez-lui de valider le parm, puis mettez à jour le parm pendant que le système d'exploitation se réfère donc à la différence de ce qu'elle a vérifié.
Ceci a été utilisé pour casser IBM OS / 360 dans les années 60: Pour demander le disque d'E / S, vous transmettriez le système d'exploitation d'un "programme de canaux" qui contenait l'adresse de disque et l'adresse de la mémoire et d'autres choses. Le système d'exploitation vérifierait que les adresses de disque et de mémoire étaient des emplacements auxquels vous avez été autorisé, puis il passerait ce "programme de canaux" sur le matériel de canal d'E / S à exécuter, sans effectuer d'abord une copie locale. Ce n'était pas difficile de faire du temps afin que vous modifiez le programme de canal après avoir été vérifié, mais avant que le matériel de canal d'E / S aient exécuté, permettant d'accéder au disque et à la mémoire non autorisés.
(Gardez à l'esprit que dans cette mémoire de réflexion était très précieux, la copie du programme de canal n'a donc pas sauvegardé une quantité non triviale de mémoire. Mais cette échappatoire a été assez rapidement fermée une fois que la façon de l'exploiter est devenue assez bien connue.)
(Bien sûr, il faut se demander si tout programme Objective-C peut être considéré comme "sécurisé" à partir d'un autre code exécuté dans le même processus. La nature "dactylographie de canard" de l'objectif-c rend vrai la sécurité improbable au mieux. L'utilisation de chaînes immuables est plus une protection contre la modification accidentelle que la modification malveillante.)
"Je pense que vérifier la chaîne avant utilisation, cela résoudrait le problème" Sauf si vous n'utilisez pas explicitement une sorte de serrure, non.
Si mis en œuvre de manière incorrecte, ce qui empêche un délinquant de changer la référence de votre chèque?
Il y a beaucoup de raisons que la chaîne est conçue pour être immuable, comprendre l'immuable comme celle-ci: Quand une classe est indépendante et totalement concrète de nature.