Stratégie de paramétrage pour l'injection de caractères dangereux


-2

J'ai un champ de saisie pour l'acceptation de l'ID de courrier électronique. Si l'ID d'utilisateur n'est pas entré par l'utilisateur, J'ai une validation côté client en utilisant Java Script pour afficher le message d'erreur qui se lit comme suit: "Veuillez entrer un ID email valide". Le code est comme,

if(EmailIdIsNull) 
{ 
    error = "Please enter valid email id"; 
    //Submit this error message to the form 
} 

Cette façon de gérer le contrôle est vulnérable à l'injection de caractères dangereux. Pour par exemple., On a changé "S'il vous plaît entrer id email valide" à "%[email protected]%3ECIMG+SRC%3D.html%22%3E"

Solution pour cela a été donné que,

"If available, use structured mechanisms that automatically enforce the separation 
between data and code. These mechanisms may be able to provide the relevant quoting, 
encoding and validation automatically, instead of relying on the developer to provide 
this capability at every point where output is generated" 

Je cherche une explication de la solution ci-dessus. Aussi, comment peut-on appliquer la solution ci-dessus dans mon cas concernant la vérification côté client de l'adresse email?

  0

Peut-être que c'est juste moi, mais je n'ai aucune idée de ce que vous demandez. 09 août. 132013-08-09 09:41:47

  0

@Svetlana Suis à la recherche d'une explication pour, "Si disponible, utiliser des mécanismes structurés qui appliquent automatiquement la séparation ......" Ce que j'ai mentionné dans ma question .. 09 août. 132013-08-09 09:47:43

  0

Source possible de la citation: http: // cwe .mitre.org/data/definitions/116.html (@Svetlana) 09 août. 132013-08-09 09:58:59

+1

Pouvez-vous expliquer pourquoi vous croyez que votre code est vulnérable à une attaque par injection? Pour autant que je vois, il n'y a aucune donnée utilisateur injectée n'importe où. 09 août. 132013-08-09 10:03:27

  0

Je pense que votre doute devrait être mieux expliqué. Quel est le problème avec cette phrase? 09 août. 132013-08-09 10:04:35

  0

@VikasV Non, toujours une mauvaise question. Vous n'expliquez pas correctement votre problème. De quoi as-tu peur?Vous parlez de quelqu'un qui change "Veuillez entrer un identifiant email valide" à une autre chaîne, comment vont-ils faire cela? et je ne suis pas le seul à avoir du mal à déchiffrer votre question. 09 août. 132013-08-09 10:09:56

  0

@Perseids +1 pour votre commentaire. Je pense que vous êtes le seul ici qui a compris le vrai problème de cette question. 09 août. 132013-08-09 10:29:13

  0

Je ne sais pas comment mon code est vulnérable à une attaque par injection. Il y avait un test de pénétration pour mon site Web à partir d'un outil de sécurité qui a signalé cela. Et la solution donnée était: «Si possible, utilisez des mécanismes structurés qui imposent automatiquement la séparation ...» Je ne suis pas capable de comprendre ce que cela signifie. Suis à la recherche d'une explication pour cette déclaration .. 09 août. 132013-08-09 10:49:18

2

Tout d'abord, vous devriez jamais compter sur le code côté client pour toute sorte de validation que ce soit. Il est ridiculement trivial de contourner toute validation du côté client.

Au lieu de cela, vous devriez toujours désinfecter et d'échapper toutes les entrées sur le côté serveur. Bien sûr, vous pouvez effectuer une validation côté client pour assurer une bonne expérience utilisateur, mais toujours valider également sur votre serveur.

Je présume que l'adresse e-mail sera écrite dans une base de données quelque part. Dans ce cas, utilisez les requêtes parameterized au lieu du SQL dynamique. Cela vous protégera contre les attaques par injection SQL. Vous devriez échapper les données lors de la sortie pour empêcher les attaques XSS. Les feuilles de diagnostic de prévention XSS et SQL injection de OWASP est une référence utile ici.

  0

pouvez-vous éditer votre réponse et fournir une explication pour "Si disponible, utilisez des mécanismes structurés qui appliquent automatiquement la séparation ......." que j'ai mentionné dans ma question .. 09 août. 132013-08-09 09:48:42

+1

@VikasV Requêtes paramétrées ** IS ** imposant la séparation du code des données. Je vous suggère de lire les liens dans ma réponse. 09 août. 132013-08-09 09:49:38

  0

-1 Bien que la question elle-même soit mal écrite et ne décrive pas assez bien le problème, votre réponse n'a rien à voir avec la question. En outre, ce n'est pas ce que la séparation du code des moyens de données. 09 août. 132013-08-09 09:53:30


1

Les requêtes paramétrées ou prepared statements sont un exemple de "mécanismes qui imposent automatiquement la séparation entre les données et le code". Le problème quand il n'y a pas separation between data and code est que les données introduites par un utilisateur peuvent être injectées dans le code et peuvent manipuler l'application d'une manière non pensée par le programmeur.

Pour les autres mécanismes qui "fournissent automatiquement le devis, l'encodage et la validation", vous pouvez rechercher des informations sur OWASP ESAPI ou Java Spring Security Framework. La recommandation de ne pas "compter sur le développeur pour fournir cette capacité à chaque point où la sortie est générée" est parce que si vous comptez sur un humain, vous aurez probablement des erreurs. Si vous utilisez une API centralisée qui empêche les programmeurs de manquer une validation d'entrée, vous serez plus en sécurité.