2017-04-12 3 views
0

J'ai essayé de trouver le terme exact pour "suivre le paramètre d'une méthode" pour le langage de programmation Java et j'ai généralement trouvé "l'analyse des souillures", mais je ne sais pas si je suis sur le bon chemin.Comment suivre un paramètre de méthode?

Ce que je veux, c'est garder une trace du paramètre d'une méthode et voir quelle partie de la méthode (dans la portée) fait l'effet du paramètre. Par exemple, si un paramètre est assigné à une autre variable, je veux aussi garder une trace de la variable assignée. En mentionnant «parties», il pourrait s'agir de lignes de code, d'une déclaration ou d'une branche d'un graphique de flux de contrôle.

J'ai également vérifié les outils et rencontré Checker Framework et Findbugs, mais il semble qu'ils ne répondent pas tout à fait aux besoins que je veux ou que je n'arrive pas à faire fonctionner pour mes besoins.

S'il vous plaît, dites-moi si "analyse de la souillure" est le bon terme que je cherche. En outre, toutes les autres suggestions d'outils sont les bienvenues.

Il existe un code modifié ci-dessous de Checker Framework Live Demo. Ce que j'attends, à l'intérieur processRequest() lorsque la variable String input est Tainted, je m'attends à recevoir un avertissement ou une erreur pour toutes les lignes à l'intérieur de la méthode executeQuery(). Parce qu'une variable contaminée est passée à son paramètre.

import org.checkerframework.checker.tainting.qual.*; 

public class TaintingExampleWithWarnings { 
    String getUserInput() { 
     return "taintedStr"; 
    } 

    void processRequest() { 
     @Tainted String input = getUserInput(); 
     executeQuery(input); //error: pass tainted string to executeQeury() 
    } 

    public void executeQuery(@Untainted String input) { 
     // Do some SQL Query 
     String token = input + " Hello World"; 
     String tokens[] = token.split(" "); 

     for(int i=0; i<tokens.length; i++) 
     { 
       System.out.println((i+1)+"String: "+tokens[i]) 
     } 

    } 


    /* To eliminate warning in line 10, replace line 10 by 
    * executeQuery(validate(input)); */ 
    /*@Untainted*/ public String validate(String userInput) { 
     // Do some validation here 
     @SuppressWarnings("tainting") 
     @Untainted String result = userInput; 
     return result; 
    } 
} 
+0

Il existe différents outils de contrôle des défauts pour différentes langues. Vous n'avez pas spécifié une langue donc je ne peux rien recommander mais google est votre meilleur ami –

+0

@UlugToprak merci pour le rappel, j'ai édité la question en spécifiant la langue comme "Java". – Ekin

+0

IntelliJ IDEA a des outils intégrés que vous pouvez utiliser. Checkstyle serait mon choix qui peut également être intégré aux IDE –

Répondre

1

Le Tainting Checker du Checker Framework émet un avertissement sur exactement la ligne défectueuse de votre code:

% javac -g TaintingExampleWithWarnings.java -processor tainting 
TaintingExampleWithWarnings.java:10: error: [argument.type.incompatible] incompatible types in argument. 
     executeQuery(input); //error: pass tainted string to executeQeury() 
        ^
    found : @Tainted String 
    required: @Untainted String 
1 error 

Ce défaut et met en évidence indique exactement ce que vous devez corriger dans votre programme.

Je me attends à un avertissement ou une erreur pour toutes les lignes à l'intérieur executeQuery() méthode

La mise en œuvre de executeQuery() est correcte; c'est le qui utilise de executeQuery() qui est problématique.

(Contexte:. Une analyse modulaire est un qui fonctionne une méthode à la fois une analyse modulaire repose sur les spécifications des méthodes.)

type de vérification est un exemple d'une analyse modulaire. Ses spécifications sont des annotations écrites par l'utilisateur sur des paramètres formels.

  • Lorsque le type de vérification du corps de executeQuery(), le vérificateur de type suppose que les déclarations de paramètres formels sont corrects.
  • Lors de la vérification par type d'un appel à executeQuery(), le vérificateur de type vérifie que les arguments sont légaux.

S'il y a même une erreur de vérification de type quelque part dans votre programme, puis votre programme peut se comporter de façon non sécuritaire (peut-être à un autre endroit).

Si vous voulez connaître tous les endroits possibles dans lesquels votre programme a pu s'infiltrer, vous devez utiliser une analyse complète non modulaire.De plus, l'analyse de tout le programme devrait ignorer toute annotation écrite par l'utilisateur dans le programme. Une telle analyse est possible de faire et est un désir raisonnable, mais il n'est pas abordé par les outils que vous avez mentionnés dans votre question.