Exemple 2 : d'une source au collecteur, avec modification

L'exemple 2 est une modification du code de l'exemple 1. Il étend l'exemple 1 en ajoutant une routine de validation, appelée getVulnerableSource, et une routine de codage, appelée dans writeToVulnerableSink.

import java.io.*;

public class TestCase_IOT_Instance_Val_Encode {
  public static void main(String[] args) {
    try {
      TestCase_IOT_Instance_Val_Encode testCase = new 
        TestCase_IOT_Instance_Val_Encode();
      String file = args[0];
      String source = testCase.getVulnerableSource(file);
      source = testCase.validate(source);
      String encodedStr = testCase.encode(source);
      testCase.writeToVulnerableSink(file, encodedStr);
    } catch (Exception e) {
    }
  }

  public String getVulnerableSource(String file) throws Exception {
    FileInputStream fis = new FileInputStream(file);
    byte[] buf = new byte[100];
    fis.read(buf);
    fis.close();

    String ret = new String(buf);
    return ret;
  }

  public void writeToVulnerableSink(String file, String str) 
      throws FileNotFoundException {
    FileOutputStream fos = new FileOutputStream(file);
    PrintWriter writer = new PrintWriter(fos);
    writer.write(str);
  }

  private String validate(String source) throws Exception {
    if (source.length() > 100) {
      throw new Exception("Length too long: " + source.length());
    }
		return source;
  }

  private String encode(String source) {
    return source.trim();
  }
}

Le premier examen produit une trace de pile similaire à celle de l'exemple 1.

L'extension de la Knowledgebase afin d'inclure des routines de validation et de codage réduit les données parasites dans les constatations et vérifie que ces routines sont appelées pour tous les graphes d'appels. Par exemple, si vous aviez spécifié les données d'un appel quelconque à java.io.FileInputStream.read(byte[]):int dans l'exemple précédent, l'examen éliminerait tous les appels de read qui appelaient également cette routine de validation. De même, les appels de read n'appelant pas la méthode de validation personnalisée passeraient à l'état de constatation de sécurité définitive, puisque l'abstention de l'appel d'une méthode de validation connue dans le code peut induire des attaques malveillantes.

La routine de validation peut également valider les autres variations des méthodes read de FileInputStream. Elles peuvent être spécifiées comme des sources supplémentaires. En outre, vous savez peut-être également que seuls certains collecteurs (ou des collecteurs ayant certaines propriétés) sont validés par cette méthode. Par exemple, cette routine pourrait être limitée aux collecteurs ayant la propriété Technology.IO, tels que le collecteur PrintWriter.write qui est utilisé pour consommer les données de cet exemple.