範例 2：從來源到接收槽（已修改）

範例 2 是範例 1 程式碼的修改。範例 2 是範例 1 的強化版本，差異是新增名為 getVulnerableSource 的驗證常式，以及名為 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();
  }
}

第一次掃描會產生一個堆疊追蹤，類似於範例 1 的堆疊追蹤。

延伸Knowledgebase來併入驗證和編碼常式，會減少發現項目中的雜訊，且可以確認所有呼叫圖都呼叫驗證和編碼常式。比方說，如果您在上例中從任何對於 java.io.FileInputStream.read(byte[]):int 的呼叫指定資料，則任何從 read 發出的呼叫，只要也呼叫這個驗證常式，掃描就會予以排除。另外，從 read 發出的呼叫，只要未呼叫自訂驗證方法，就會升級至明確的安全發現項目狀態，因為在程式碼中未呼叫已知的驗證方法，有可能導致惡意的攻擊。

驗證常式也可能會驗證 FileInputStream 之 read 方法的其他變異。這可能會指定為其他來源。此外，您可能也知道這個方法只驗證某些接收槽（或含某些內容的接收槽）。例如，這個常式僅受限在含 Technology.IO 內容的接收槽，例如用來消耗此範例資料的 PrintWriter.write 接收槽。