前言
这个漏洞是我在挖掘某工信部下面的某个众测平台，发现他们的验证码参数大小可控，在那一晚突然而来的灵感，目前大多数CMS的漏洞和SRC,都已经刷完了才公开的，所以不会对市面上大型企业造成影响，针对大型企业比较好的服务器，还是需要上千个才能解决。
1. 这个漏洞不能帮你获取到敏感信息
2.这个漏洞不能帮你获取到shell
3.这个漏洞没有啥利用条件
利用过程
今天这里以PHPcms为例子，讲解一下。
首先我们来到PHPCMS的
第一步
会员登录页面：http://192.168.1.101:81/index.ph ... /index.php?m=member
然后验证码处单击右键
获取该链接。或者将网址替换到下面链接地址。
http://192.168.1.101:81/api.php?op=checkcode&code_len=5&font_size=14&width=120&height=26&font_color=&background=
第二步
在得到了上面的链接地址之后呢 我们进行如下修改
将其中的参数：
font_size
width
height
改为：
font_size：1000
width：1000
height：1000
然后得到链接地址
第三步：返回值大小判断是否存在
Burp开起来，访问上面的链接
抓取数据包
Ctrl+R 将数据包放到重放功能，以方便做测试
当我们点击了Go之后看红色圈中处会有一个数字。
8112 bytes
这个可以代表我们当前从服务端返回到客户端的数据包大小，这样理解即可。
然后我们在请求包中修改一下参数
看图改数据
接着继续。我们看一下返回的数据包大小是否与 1000 有差距
可以看到我们的返回包的数据大小已经变为了：
23759 bytes
与上次的结果相差了万多。
那么证明其存在漏洞
在这里给各位说一下注意的要点：
1. 其中返回的数值 与我这里不一定相等，也就是你测试其他网站的数据返回值与我的估计不是一样的，我们主要测试 1000 与 10000 返回的数据包大小是否有相差值，如果你的相差值只有几百，那么不代表就存在。如果存在的话，他们的相差值是非常巨大的。
第四步：怎么造成DDOS攻击？
通过上面的测试我们知道了漏洞存在，如果我们发送一个10000的数据包到服务器，服务器需要 10s 时间来处理，那么我们如果发送 10 个 10000的数据包呢？
10x10 = 100s
也就是服务器需要花费100s时间去处理，当我们发送 100 个这样的数据包（当然你千万不要用100个数据包扔过去，一般来说经过测试结果 20-50个就能导致网站瘫痪。）
第五步：看一下服务器CPU有何变化？
服务器当前Apache进程Httpd的进程CPU情况如下
为 0 状态，现在我们开始发送数据，先发一个 10000 的数据包我们看看。
可以看到 CPU 损耗 50 % ，我当前配置为 2核3G
如果 发送 10个 10000的数据包呢？
最后发送 10 个，发现还是在 50%左右，于是我加了一个 0 。发送了大概 5 ， 6条 100000 的数据包，达到了预期效果
可以看到服务器 CPU 已经 100%了。成功达到了攻击的目的性。
结后语
如果一个 0 不能解决，那么就再加一个 0 ，直到问题解决，如果一个包没效果，那么就来两个 ，或者 20个，200个。