Est-ce une bonne ou une mauvaise façon de sursécuriser?

Si une fonction fait toutes les vérifications appropriées à l'intérieur, dois-je vérifier tout avant de l'appeler, ou mieux? La redondance de sécurité est-elle considérée comme une bonne pratique?Est-ce une bonne ou une mauvaise façon de sursécuriser?

Exemple (dans une sorte de pseudo-code avec des arguments par référence passant C# -comme):

 

doSomething(vector v) { 
    ...; 
    v.clear; 
    useCleanVector(v) 
} 

useCleanVector(vector v) { 
    if(!v.isClean) v.clear; 
    ... 
}

Source

2010-10-08 Ivan

Cela dépend vraiment du type de logiciel que vous écrivez. –

Cette question est trop générale pour une bonne réponse ... peut-être pourriez-vous donner quelques exemples de code? –

Qu'est-ce que cela a à voir avec la programmation fonctionnelle? –

Je dirais que c'est une mauvaise forme. Pas terrible forme, mais le même genre de forme qui mène à ceci:

v.clear(); // clear the vector to be safe. 
v = v2;

Si votre manière est de reproduire le code qui est déjà à l'intérieur d'une fonction, alors vous n'êtes pas de gagner du temps en ayant dans la fonction dans la première place. Vous violez le concept DRY si chaque appel à une fonction a le même préambule.

Il est préférable de comprendre ce que la fonction vérifie et ce qu'elle ne vérifie pas et de l'utiliser en conséquence.

Source

2010-10-08 01:54:42 JoshD

Je ne pense pas que ce soit ce qu'il veut dire. Ce qu'il veut dire, c'est vérifier des arguments de fonction pour la validité une fois en appelant la fonction, et une fois dedans –

@Pekka, exactement. Mais du point de vue de la logique mathématique, c'est la même chose que @JoshD. – Ivan

@Ivan oui, mais votre fonction peut être utilisée plus tard dans un contexte qui * ne * fait pas la première vérification. Dans ce cas, la deuxième vérification * peut * avoir un sens (elle peut aussi être inutile, cela dépend vraiment de votre projet) –

Ce qui compte le plus, c'est de documenter vos conditions préalables et les conditions exceptionnelles d'une manière évidente. Quelque chose comme ça semble raisonnable.

/** 
* precondition : id must be the id of a flarg. 
* 
* myfunc will return -1 if value is outside the valid 0-10 range. 
*/ 
int myfunc(int id, int value);

Cela me permet de code quelque chose comme ça

int flarg_id = ... 
if (! is_flarg(flarg_id)) { printf("Bad flarg"); exit(1); } 
int value = ... 
int rv = myfunc(flarg_id, value); 
if(rv == -1) { printf("Bad value"); exit(1); }

Source

2010-10-08 01:55:43

+1. Tant que les docs disent clairement ce que la fonction va faire dans quelles circonstances, une grande partie de l'incertitude disparaît –

Oui, vous devriez toujours effectuer les contrôles nécessaires à ce niveau de la portée.

La raison? Quand quelqu'un entre après vous dans n mois, ils ne vont pas suivre les appels de fonction jusqu'au dernier élément. S'assurer que chaque fonction est protégée en soi aidera à soulager les bogues stupides ou, pire encore, les bogues qui sont difficiles à traquer.

Source

2010-10-08 01:57:43

Cela dépend vraiment de la cherté du chèque. Si le code est bien documenté, être strict peut être plus que nécessaire –

Je le pense surtout, mais j'ai peur que cela puisse même introduire des bugs difficiles à repérer dans certains cas. – Ivan

@Ivan pas si votre fonction est bien documentée, et chaque instance appelant la fonction a été écrite avec cette documentation à l'esprit. La documentation est la clé vraiment - si c'est bon, il est possible d'écrire du code contre lui et de croire qu'il va nourrir l'entrée attendue –

Il y a redondance (souvent bonne), et vous vous répétez.

Pour reprendre l'exemple de Josh, si la fonction Foo garantit qu'il efface un vecteur, il n'y a aucune raison de l'effacer au préalable. Faites confiance et vérifiez les garanties fournies par votre API. D'un autre côté, même si vous êtes sûr qu'une surface d'accès aux données est complètement protégée contre toute activité malveillante (vous avez vérifié toutes les procédures avant et après vous-même!), Il n'y a aucune raison d'exposer cette surface à utilisateurs non autorisés. Trouvez vos goulots d'étranglement et sécurisez-les, juste au cas où le code contient des vulnérabilités dont vous ne savez pas encore.

Source

2010-10-08 02:00:58

Est-ce une bonne ou une mauvaise façon de sursécuriser?

Répondre

Questions connexes