[Segurança de Rede] Avaliação do Teste de Benchmark OWASP

1. Fundo

O Source Code Static Analysis Tool (SAST), como uma importante ferramenta de garantia de segurança de software, tem sido amplamente utilizado em diversas áreas. Com o amplo uso de ferramentas SAST de código aberto e o aumento dos tipos de ferramentas, é difícil para os usuários julgar os prós e contras das ferramentas e se elas são adequadas para cenários de aplicativos corporativos. Este documento analisa a estática A análise realiza uma breve avaliação fornecer uma base para que todos possam escolher ferramentas de análise estática Além disso, este artigo analisa os problemas técnicos existentes nas ferramentas de análise de código estático atuais e os critérios básicos para avaliação da ferramenta.

2. Visão geral

De um modo geral, as taxas de falso positivo e falso negativo são os indicadores de avaliação técnica mais importantes do SAST, mas, como não há teste definido em um sentido geral, ele pode refletir totalmente a precisão da detecção das ferramentas de análise estática e a sensibilidade da análise. Portanto, para simplificar a dificuldade do teste, escolhemos uma linguagem Java e um conjunto de teste geral internacional relativamente seguro OWASP benchmark para esta avaliação para refletir a força das ferramentas de análise de código nos recursos de detecção de segurança Java.

O OWASP Benchmark é um aplicativo de amostra que contém milhares de vulnerabilidades de 11 categorias. O benchmark inclui fragmentos de código difíceis de lidar por meio de análise estática, como: chamadas indiretas, branches inacessíveis, mapas, valores que dependem de arquivos de configuração.

Endereço de download do caso de uso: github.com/OWASP/Bench… , que pode refletir os recursos de detecção das ferramentas de análise de código até certo ponto.

1. Base de teste

A tabela a seguir mostra os resultados da detecção OWASP de uma determinada ferramenta. Conforme mostrado na figura, a coluna da esquerda indica todas as categorias, P/N é o número de amostras positivas/negativas (badcase/goodcase) e TP/FP é o número de verdadeiros/falsos positivos (número relatado de caso ruim/número falso positivo), TN/FN é o número de negativos verdadeiros/falsos (número relatado de caso bom/número negativo perdido), TPR e FPR são taxa correta e taxa de falso positivo, Y é Índice de Youden, índice de Youden (índice de Youden, YI) é o índice correto, e o intervalo desse valor de índice é apenas de 0 a 1. Quanto maior o índice de Youden, melhor sua autenticidade. As fórmulas de cálculo de TPR, FPR e Y são as seguintes:

TPR=TP/P

FPR=FP/N

Y=[TP/(TP+FN)+TN/(FP+TN)]-1

categoria	P	N	PT	PF	TN	FN	TPR	FPR	Y
Injeção de comando (cmdi)	126	125	126	45	80	0	1,0	0,36	0,64
Criptografia fraca (cripto)	130	116	130	0	116	0	1,0	0,0	1,0
Aleatoriedade fraca (hash)	129	107	129	0	107	0	1,0	0,0	1,0
Injeção de LDAP (ldapi)	27	32	27	13	19	0	1,0	0,41	0,59
Caminho Traversal (pathtraver)	133	135	133	36	99	0	1,0	0,27	0,73
Secure Cookie Flag Securecookie)	36	31	36	0	31	0	1,0	0,0	1,0
Injeção de SQL (sqli)	272	232	272	87	145	0	1,0	0,375	0,63
Violação de limite de confiança (confiável)	83	43	83	24	19	0	1,0	0,56	0,44
Randomização fraca (weakrand)	218	275	218	0	275	0	1,0	0,0	1,0
Injeção de XPATH (xpathi)	15	20	15	7	13	0	1,0	0,35	0,65
Cross Site Scripting (xss)	246	209	246	48	161	0	1,0	0,23	0,77
Média de todos	1415	1325	1415	290	1035	0	1,0	0,23	0,77

2. Resultados do teste

选取市场上主流的SAST工具进行测试，本次选取的测试工具涵盖较广，包含国外商业工具、开源工具以及国内自研工具。如SonarQube[1]代码自动审查工具，该工具是开源工具中使用最多的工具，因为开源免费尤其受很多金融企业喜爱；以色列的Checkmarx CxSAST[2]，Micro Focus Fortify[3]，目前在电力、金融等行业推广较多，是中国市场Java应用最多的工具之一；还有在互联网领域应用的比较广泛的新思科技的Coverity[4]、IBM Appscan[5]。军工领域应用比较广泛的Parasoft的JTest[6]、VeraCode[7]等。下图是10款静态分析工具的OWASP基准测试结果。商业SAST工具01-06包括：Checkmarx CxSAST、Micro Focus Fortify、IBM AppScan Source、Coverity Code Advisor、Parasoft Jtest、SourceMeter[9]和Veracode工具。

分析工具	OWASP版本	TPR	FPR	Y
FBwfindSecBugs[10]	1.2	0.97	0.58	0.39
SonarQube	1.2	0.5	0.17	0.33
鸿渐SAST	1.2	1.0	0.12	0.88
SAST-04	1.1	0.61	0.29	0.33
SAST-06	1.1	0.85	0.52	0.33
SAST-02	1.1	0.56	0.26	0.31
SAST-03	1.1	0.46	0.214	0.25
SAST-05	1.1	0.48	0.29	0.19
SAST-01	1.1	0.29	0.12	0.17
PMD	1.2	0.00	0.00	0.00

从上图可知，覆盖率指数最大为1（即100%覆盖，不存在漏报）；而误报率最低的指数为0.12，最高为0.58,尚无。

三、技术分析

静态代码分析基本原理：首先将源代码解析为抽象语法树；采用控制流分析、多态分析、指向分析、函数调用分析等多种分析算法对基本分析模型；考虑路径敏感等多种情况，建立符号执行、抽象解释、图可达性等程序模型；根据缺陷模式在程序模型的基础上生成一阶逻辑表达式并采用SMT进行可满足性约束求解，生成最终结果。目前很多工具只做基本分析层面，尤其是开源工具，针对全模式的敏感分析很多工具并不支持，或支持的不好，因此可能产生大量的误漏报，下面分析了几种典型的问题：

基于以上要点，分析误报原因，了解工具的局限性。通过分析，误报基本由以下几种情况导致。

1. 集合覆盖问题

在集合中，部分集合数据存在污染数据，当检索集合中未污染部分时，导致整个集合覆盖污染，误报产生。如：以下代码中，map中填充带有一个污点（param）和一个未污点的值（a_value），并且从映射中检索参数赋值给bar。如果一个集合的一部分被污染了，假设整个collection都被污染，那么在本例中，当我们检索集合的未污染部分时，导致误报。

private class Test {
  public String doSomething(String param) throws ServletException, IOException {
        String bar = "safe!";
        java.util.HashMap map831 = new java.util.HashMap();
        map831.put("keyA-831", "a_Value"); // put some stuff in the collection
        map831.put("keyB-831", param); // put it in a collection
        map831.put("keyC", "another_Value"); // put some stuff in the collection
        bar = (String)map831.get("keyB-831"); // get it back out
        bar = (String)map831.get("keyA-831"); // get safe value back out
        return bar;
     }
  } // end innerclass Test 

2. 集合过度污染问题

在一个集合中，部分集合数据存在污染数据，当对集成做一些操作后，工具无法识别出受污染的数据，导致其他正常数据收到影响，产生误报。如：在以下代码中，存在一个未受污染的值（safe），一个受污染的值(param) 和另一个未受污染的值(moresafe) 被添加到列表中。 当第一个值“safe”被删除后，从列表的开头，检索索引为 1 的列表元素，即读取未受污染的值“moresafe”。同样导致误报。

 public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
   response.setContentType("text/html");
   String param = "";
   boolean flag = true;
   java.util.Enumeration names = request.getParameterNames();
   while (names.hasMoreElements() && flag) {
   String name = (String) names.nextElement(); 
   String[] values = request.getParameterValues(name);
   if (values != null) {
   for(int i=0;i<values.length && flag; i++){
   String value = values[i];
   if (value.equals("vector")) {
   param = name;
      flag = false;
   }
   }
   }
   } 
   String bar = "alsosafe";
   if (param != null) {
   java.util.List valuesList = new java.util.ArrayList( );
   valuesList.add("safe");
   valuesList.add( param );
   valuesList.add( "moresafe" ); 
   valuesList.remove(0); // remove the 1st safe value 
   bar = valuesList.get(1); // get the last 'safe' value
   } 
   String cmd = org.owasp.benchmark.helpers.Utils.getInsecureOSCommandString(this.getClass().getClassLoader());
   String[] args = {cmd};
          String[] argsEnv = { bar }; 
   Runtime r = Runtime.getRuntime();
   try {
   Process p = r.exec(args, argsEnv, new java.io.File(System.getProperty("user.dir")));
   org.owasp.benchmark.helpers.Utils.printOSCommandResults(p, response);
   } catch (IOException e) {
   System.out.println("Problem executing cmdi - TestCase");
              throw new ServletException(e);
   }
   } 

3. 分支问题

在条件分支中，由于条件设置问题，导致某些分支可能永远无法执行，若工具无法判定某些无法执行的分支，可能导致误报的产生。如：在以下代码中，因为num为常量106，（7*18）+num的值永远大于200，导致bar的值始终都为常量字符串，“This_should_always_happen”。另外一个包含污染数据的分支“param”永远无法执行。导致工具产生误报。

 private class Test {
  public String doSomething(String param) throws ServletException, IOException {
     String bar;// Simple ? condition that assigns constant to bar on true condition
     int num = 106;
     bar = (7*18) + num > 200 ? "This_should_always_happen" : param;
     return bar;
   }
  } 

四、结论

全面、高效地静态识别漏洞，减少工具的误报是静态分析中至关重要的技术，目前在该领域中，仍然有很大的进步空间。针对本次OWASP的基准测试，在选取的工具中，目前结果最好的工具覆盖率可以达到100%，且同时误报率为12%，也说明了工具正不断趋于成熟，但该结果仅针对OWASP测试用例。在后续的静态代码分析技术中，需要不断对静态数据流跟踪器进行持续优化，以此提高检测精度。

为了更好地对代码分析工具进行评价，笔者提出了几个评价维度，并给出评价等级：

评价指标	描述	Level 1	Level 2	Level 3
约登指数	查全率-误报	0.9-1.0	0.7-0.9	0.7-
吞吐量	最大检测代码规模	1000W+	100W+	10W+
检测效率	每小时代码检测代码行数	100W+	50W+	10W+
片段代码检测能力	能否在编译不通过情况下检测	支持所有语言	C/C++,Java	不支持
并发检测能力	支持单CPU的多并发测试	硬件允许的最大值	单进程	单进程
跨语言及框架分析能力	支持最新的框架及兼容语言间调用	支持70种以上框架	支持10种以下	不支持
支持语言	支持检测的语言种类	20种+	10种+	3种+
与Devops集成能力	是否与DevOps主要工具集成	支持持续集成工具、版本管理及测试工具，三个方面	仅支持版本管理	不支持
CWE模式覆盖数	覆盖的缺陷模式个数	200+	100+	50+