可用fidder测试的一些安全测试点
时间： 16:02:15
&&&& 阅读：8820
&&&& 评论：
&&&& 收藏：0
标签：以下是整理的一些常见的安全渗透测试点
1.用工具fidder抓包拦截篡改服务器端返回的代码，导致下级拥有对上级的访问操作权限
以下是公司开发写的用户角色权限页面跳转
修改普通角色跳转的页面为管理员跳转的页面
2.篡改传输的数据，积分兑换下订单，可以花别人的积分兑换东西送货到我想送的人和地址
3.任意修改用户资料
某交易平台的用户可以通过该系统的个人资料修改页面修改个人的昵称和头像。
截取发送修改请求的数据包抓取进行分析。我们发现在提交的过程中，其实请求自带了一个隐藏的参数investor.loginName，其实 investor.loginName为登录的手机号码(或用户名)，investor.Name为重置的用户名，通过直接修改掉参数 investor.loginName为任意注册的用户名或者手机号码，即可成功篡改重置该用户的用户名。
4.任意查询用户信息
在对金融交易平台测试的过程中，我们发现大部分平台并未对查询功能进行优化，使用用户的uid之类的账号标志参数作为查询的关键字，并且未对查询范 围进行控制，导致出现任意信息查询的安全漏洞。该类型漏洞在手机客户端较为常见，如在某交易平台手机商城就发现了任意查询其他用户信息的安全问题。
当点击商城的个人资料修改处，系统会通过将当前用户的phone_client_uuid提交到服务器进行查询，调出个人资料的内容
但由于系统并未对该功能进行访问控制，导致可通过遍历uuid的方式查询平台中任意用户的资料，通过工具对phone_client_uuid的后5位进行爆破尝试，如下图：
通过对返回值的length进行筛选，发现成功爆破部分phone_client_uuid所对应的用户信息。
针对平行权限的访问控制缺失，我们建议使用基于用户或者会话的间接对象引用进行防护，比方说，一个某个选项包含6个授权给当前用户的资源，它可以使 用一串特殊的数字或者字符串来指示哪个是用户选择的值，而不是使用资源的数据库关键字来表示，数字和字符串的生成可以结合账号信息进行生成，使得攻击者难 以猜测生成的方式。
针对垂直权限的访问控制缺失，我们建议可以使用缺省拒绝所有的访问机制，然后对于每个功能的访问，可以明确授予特定角色的访问权限，同时用户在使用该功能时，系统应该对该用户的权限与访问控制机制进行校对。
5.任意重置用户密码
用户越权去修改其他用户的信息，如密保电话、密保邮箱等，由于它敏感性所以我们将它归纳成一类进行探讨。
绕过短信验证码
基本所有的金融交易平台都有短信找回密码的功能，但部分短信验证的功能较为不完善导致可被利用重置任意用户的账号，同样是某金融平台的实际案例：
在已知对方用户名和手机号码的情况下，通过站点的密码找回功能可绕过短信验证码直接重置该账号密码。下图为密码重置页面：
该漏洞出现主要的原因在于开发人员在第二步设置新密码时服务端没有对手机验证码进行二次校验，提示：重要的功能都需要做服务器端验证，导致当攻击者可以利用修改返回值的方式直接跳转到设置新密码页面，然后重置用户的密码。
6.短信验证码暴力破解
部分金融交易平台为了用户登录方便会设置短信验证码登录功能，但并未对验证码的登录错误次数进行限制，导致可利用验证码爆破的方式强行登录账号。在某证券交易平台就曾出现过该安全问题。
该平台使用6位数字随机验证码进行登录，但并未对登录错误次数和验证码失效时间进行限制，导致可以暴力破解该验证码强制登录账号。如下图：
同样是通过返回值的length字段进行判断是否登录成功。6位字段的爆破需要较长的时间，但4位验证码的爆破时间最慢也仅需要约5分钟左右。
针对案例一中的漏洞，我们建议在第二步修改密码时服务端再次验证手机验证码，部分平台所采用的做法是，第一步验证码提交成功后，将验证码隐藏在一个 &hidden&表单中，并在第二步修改密码中进行提交，服务端再次验证短信验证码，保证准确性，同时对验证码的错误次数进行限制，当验证错误超过特定次 数，当前验证码无效。
针对案例二中的漏洞，我们同样建议随机验证码设置错误次数限制，当验证错误超过特定次数，当前验证码即无效。
7.恶意注册
恶意注册，是指攻击者利用网站注册功能的安全漏洞，注册大量的垃圾账号，导致系统增多大量无用数据。一般网站开发者为了防止恶意注册的行为，在注册 页面均会在加入一些需要人工输入的步骤，比方说短信验证码，邮箱验证等。但是在对金融平台测试的过程中，同样也发现了部分验证功能可被绕过。
注册数据包重放绕过验证码
部分金融交易平台为了保证注册用户的真实性，往往都会要求验证手机，并通过发送验证码的方式来保证注册账号并非僵尸账号，但是部分平台的验证码可被多次重放，导致可注册大量垃圾账号，在某交易商城的注册功能就存在该漏洞，下图为注册时需要给手机发送验证码的数据包：
短息码验证完后，直接注册写数据库，通过修改phoneNum的值可以实现批量注册账号：
通过修改phoneNum的值为15527xxxx96、15527xxxx97可成功注册这两个账号:
该漏洞出现的原因在于后台未校验验证码的使用次数和时间，只校验了其准确性，因此可被利用进行多次注册。
目前遇到的大部分恶意注册类的安全漏洞均为验证码可被多次使用造成，我们建议后台对验证码的使用进行限制，任何的验证码应为一次性，防止验证码被多次使用
8.恶意短信
恶意短信是一种类似于DDoS的攻击方式，他是利用网站的短信相关的功能，对用户的手机进行长时间的短信轰炸，导致手机瘫痪。除了单纯的短信轰炸之外，我们在测试过程中也发现，部分金融交易平台对所发送的短信内容也并没有进行限制，导致可被利用进行短信欺诈。
在测试的过程中，我们发现众多的金融交易平台仅在前端通过JS校验时间来控制短信发送按钮，但后台并未对发送做任何限制，导致可通过重放包的方式大 量发送恶意短信。如某交易平台的手机注册处就出现过该类型漏洞。利用fiddler抓取数据包，并进行重放可以绕过前端的限制，大量发送恶意短信。
任意短信内容编辑
在某平台的修改绑定手机功能就曾出现过可编辑短信内容的问题。
点击&获取短信验证码&，并抓取数据包内容，如下图。通过分析数据包，可以发现参数sendData/insrotxt的内容有客户端控制，可以修改为攻击者想要发送的内容
将内容修改&恭喜你获得由xx银行所提供的iphone6一部，请登录http://www.xxx.com领取，验证码为236694&并发送该数据包，手机可收到修改后的短信内容，如下图：
该类型漏洞对系统的影响不大，但若被攻击者利用进行短信欺诈，将严重影响平台的声誉，甚至可能会惹上法律纠纷。
针对恶意短信类的安全问题，我们建议可以通过以下两种方式进行防护：
1、从服务端限制每个号码的发送频率和每天的发送次数，防止攻击者利用短信接口进行恶意轰炸。&&
&&2、发送短信的内容应直接由系统内部进行定义，客户端可通过数字或字符的方式，对所需要发送的内容进行选择，如messagetype=1 为密码找回，messtype=2为注册，然后通过数字来索引要发送的内容。
9.增加抽奖机会
本来没有抽奖的次数，点击立即抽奖，fidder抓包，篡改状态将0改为1，去掉提示
&标签：原文地址：http://www.cnblogs.com/JeanX/p/4468783.html
&&国之画&&&& &&&&chrome插件&&
版权所有 京ICP备号-2
迷上了代码！据英国《镜报》4月10日报道，日前新发现的“心脏出血”网络安全漏洞（Heartbleed Bug）可能会影响全球66%的网站，数百万网民被建议立即修改密码。[资料图]
据英国《镜报》4月10日报道，日前新发现的“心脏出血”网络安全漏洞（Heartbleed Bug）可能会影响全球66%的网站，数百万网民被建议立即修改密码。
该网络安全漏洞已潜伏两年，但于本周才被发现并公布。其影响范围覆盖了全球66%的网站，包括谷歌、亚马逊、雅虎、脸谱等大型网站。
昨日数百万网民被建议立即修改密码，以保护其在网站上的敏感信息，包括登录密码、邮件和银行数据等。但由于此攻击不留下痕迹，目前尚不清楚有多少个人信息已被窃取。
谷歌研发人员于周一发现了这一官方名为CVE-的安全漏洞，称其是在软件中的编码错误，在电子商务网站中常见。
OpenSSL（即开放源码的安全套接层协议）加密系统使网民可以安全地发电子邮件、聊天、购物，但黑客可以通过此安全漏洞窃取网民的数据。
谷歌在发现此漏洞后，通知了一些公司，然后再公之于众。谷歌的对手雅虎公司仍建议用户修改密码，而亚马逊则称除少数几项服务外，其它已经处理妥当。
Heartbleed Bug安全漏洞可影响银行、购物、交友类网站以及电子邮件服务等。（编译：张露露）
Add your comments...
Your Comment
Enter the words you see:   
Racist, abusive and off-topic comments may be removed by the moderator.
Get more from China.org.cnWeb安全测试中常见逻辑漏洞解析（实战篇） - FreeBuf互联网安全新媒体平台 | 关注黑客与极客
Web安全测试中常见逻辑漏洞解析（实战篇）
共1505269人围观
，发现 21 个不明物体
*文章原创作者： ArthurKiller@漏洞盒子安全研究团队，转载请注明来自FreeBuf黑客与极客（FreeBuf.COM）&
逻辑漏洞挖掘一直是安全测试中“经久不衰”的话题。相比SQL注入、XSS漏洞等传统安全漏洞，现在的攻击者更倾向于利用业务逻辑层的应用安全问题，这类问题往往危害巨大，可能造成了企业的资产损失和名誉受损，并且传统的安全防御设备和措施收效甚微。今天漏洞盒子安全研究团队就与大家分享Web安全测试中逻辑漏洞的挖掘经验。
一：订单金额任意修改
很多中小型的购物网站都存在这个漏洞。在提交订单的时候抓取数据包或者直接修改前端代码，然后对订单的金额任意修改。
如下图所示：
经常见到的参数大多为
关于支付的逻辑漏洞这一块还有很多种思路，比如相同价格增加订单数量，相同订单数量减少产品价格，订单价格设定为负数等等。
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，验证码等。
如果设定验证码，最好不要单纯的采取一个前端验证，最好选择后端验证。
如果设定token，请确保每个token只能采用一次，并且对token设定时间参数。
2. 注册界面的接口不要返回太多敏感信息，以防遭到黑客制作枚举字典。
3. 验证码请不要以短数字来甚至，最好是以字母加数字进行组合，并且验证码需要设定时间期限。
4. 优惠券，VIP卡号请尽量不要存在规律性和简短性，并且优惠券最好是以数字加字母进行组合。
5. 以上这是部分个人建议，实际方案需要参考业务的具体情况。
五：cookie设计存在缺陷
这里需要对其详细的说一下。我们先一个一个来吧。
Cookie的效验值过于简单。有些web对于cookie的生成过于单一或者简单，导致黑客可以对cookie的效验值进行一个枚举，如下图所示
根据上图，我们可以分析出，这家网站对于cookie的效验只单纯的采用了一组数字，并且数值为常量，不会改变，这样非常容易遭到黑客的枚举。甚至有一些网站做的更简单，直接以用户名，邮箱号或者用户ID等来作为cookie的判断标准。
2. cookie设置存在被盗风险
有很多时候，如果一个用户的cookie被盗取，就算用户怎么修改账号和密码，那段cookie一样有效。详情可以参考。
其原理如下：
国内大部分厂商都不会把这个地方当作安全漏洞来处理，他们认为这个漏洞的利用条件是黑客必须要大批量获取到用户的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很熟悉
www.xxx.com/resetpassword.php?id=MD5
用户修改密码时，邮箱中会收到一个含有auth的链接，在有效期内用户点击链接，即可进入重置密码环节。而大部分网站对于auth的生成都是采用rand()函数，那么这里就存在一个问题了，Windows环境下rand()最大值为32768，所以这个auth的值是可以被枚举的。
如下面这个代码可以对auth的值做一个字典。
然后重置某个账号，并且对重置链接内的auth进行枚举
整个漏洞的运作的流程图如下：
2.对response做验证
这个漏洞经常出现在APP中，其主要原因是对于重置密码的的验证是看response数据包，由于之前的案例没有截图，只能画个流程图给大家演示一下。
3.这篇文章很全面的总结了密码找回漏洞的几个具体思路和分析，这里我就不再继续滚轮子了。
1.严格使用标准加密算法，并注意密钥管理。
2.在重置密码的链接上请带入多个安全的验证参数。
七：单纯读取内存值数据来当作用户凭证
实际上这个应该算作一个软件的漏洞，但是因为和web服务器相关，所以也当作WEB的逻辑漏洞来处理了。最能当作例子是这个漏洞，但是我相信这种奇葩的漏洞不一定只有腾讯才有，只是还没人去检测罢了。
产生这个漏洞的主要原因是程序在确定一个用户的登陆凭证的时候主要是依靠内存值中的某个value来进行确认，而不是cookie。但是内存值是可以更改和查看的。其流程图如下：
1. 走服务器端的数据最好做cookie验证。
2. 我不反对直接在进程中确定用户的登陆凭证，但是请对进程进行保护，或者对进程中的value做加密处理。
以上见到的只是几个比较经典的和常见的逻辑漏洞，这些逻辑漏洞也是程序开发人员和安全检测人员需要留意的。
如果对逻辑漏洞感兴趣的可以查看以下的扩展阅读：
*文章原创作者： ArthurKiller @漏洞盒子安全研究团队，转载请注明来自FreeBuf黑客与极客（FreeBuf.COM）
真心不错！干货！！
FreeBuf常务处主任
@ 北京大屌
小编操作失误，评论区忘打开了。。。已拖出去重打20大板
必须您当前尚未登录。
必须（保密）
互联网安全测试平台
关注我们 分享每日精选文章
可以给我们打个分吗？Web漏洞检测及修复
Web漏洞是指以各种语言（PHP、JSP、C++等）开发的CGI/Web Service中存在的安全漏洞。
下面是漏洞的定义，检测方法以及修复方案。
名称： SQL注入漏洞（SQL Injection）
描述：Web程序代码中对于用户提交的参数未做过滤就直接放到SQL语句中执行，导致参数中的特殊字符打破了SQL语句原有逻辑，黑客可以利用该漏洞执行任意SQL语句。
检测方法：通过修改参数来判断是否存在漏洞。
修复方案：
1. 针对ASP.NET的防XSS库，Microsoft有提供统一的方法，具体可以参见如下链接:
2. 针对其它语言如下细分：
在代码级对带入SQL语句中的外部参数进行转义或过滤：
（1）对于整数，判断变量是否符合[0-9]的值；其他限定值，也可以进行合法性校验
（2）对于字符串，对SQL语句特殊字符进行转义(单引号转成两个单引号，双引号转成两个双引号)。关于这点，PHP有类似的转义函数mysql_escape_string和mysql_real_escape_string。
（1）使用腾讯存储方案；
（2)对与数据库进行交互的用户请求数据，要先做过滤，防止SQL注入。
名称：XSS注入漏洞（Cross-site Scripting）
描述：Web程序代码中把用户提交的参数未做过滤就直接输出到页面，参数中的特殊字符打破了HTML页面的原有逻辑，黑客可以利用该漏洞执行恶意HTML/JS代码、构造蠕虫传播、篡改页面实施钓鱼攻击等。
检测方法：通过修改参数来判断是否存在漏洞。
比如用户输入内容：’&u&a&/u&”的时候，合法的显示是： ’&u&a&/u&” ，合法的显示的源码是：
而存在漏洞的页面显示却是：’a”
修复方案：
1. 开发者应该严格按照判断openid和openkey是否合法，且判断其它参数的合法性，不合法不返回任何内容。
2. 严格限制URL参数输入值的格式，不能包含不必要的特殊字符（&%0d、%0a、%0D 、%0A 等）。
3. 针对ASP.NET的防XSS库，Microsoft有提供统一的库，具体可以参见如下链接
微软官网：
4. 具体的js方法如下：
（1）对于用户输入的参数值展现在HTML正文中或者属性值中的情况，例如：
展现在html正文中：&a href='http://www.contoso.com'&Un-trusted input&/a&
展现在属性值中：&input name="searchword" value="Un-trusted input"&
此时需要将红色的不可信内容中做如下的转码(即将& & ‘ “ ` 转成html实体)：
（2）对于用户输入落在&script&的内容中的情况，例如:
&script type="text/javascript"&
var mymsg="Un-trusted input";
var uin=Un-
需要将红色的不可信内容中做如下的转码: [a-zA-Z0-9.-_,]以及ASC值大于0x80之外的所有字符转化为\x**这种形式，例如：
名称：命令注入漏洞（Command Injection）
描述：Web程序代码中把用户提交的参数未做过滤就直接使用shell执行，攻击者可以执行任意系统命令。
检测方法：通过修改参数来判断是否存在漏洞。
修复方案：在代码级调用shell时，对命令行中的特殊字符进行转义（|、&、；等），防止执行其他非法命令。
PHP中可使用escapeshellarg、escapeshellcmd来转义。
名称：HTTP响应头注入漏洞（HTTP-Response-Splitting，HTTP_header_injection）
描述：Web程序代码中把用户提交的参数未做过滤就直接输出到HTTP响应头中，攻击者可以利用该漏洞来注入HTTP响应头，可以造成xss攻击、欺骗用户下载恶意可执行文件等攻击。
另外根据国际安全组织司acunetix统计，以下apache存在header injection漏洞：1.3.34/2.0.57/2.2.1。
检测方法：通过修改参数来判断是否存在漏洞。
比如国内某著名网站曾经出现过header注入漏洞，如下url：
http://www.YYYYYYYYY.com/YYYYWeb/jsp/website/agentInvoke.jsp?agentid=%0D%0AX-foo:%20bar
抓包时发现：
修复方案：
1. 在设置HTTP响应头的代码中，过滤回车换行（%0d%0a、%0D%0A)字符。
2. 不采用有漏洞版本的apache服务器，同时对参数做合法性校验以及长度限制，谨慎的根据用户所传入参数做http返回包的header设置。
名称：跳转漏洞
描述：Web程序直接跳转到参数中的URL，或页面引入任意的开发者URL。
检测方法：修改参数中的合法URL为非法URL。例如测试一下如下URL：
http://***.qq.com/cgi-bin/demo_es.cgi?backurl=http://www.***.com，看是否会跳转到注入的http://www.***.com站点。
修复方案：在控制页面转向的地方校验传入的URL是否为可信域名。
例如以下是一段校验是否是腾讯域名的JS函数：
function VaildURL(sUrl)
return (/^(https?:\/\/)?[\w\-.]+\.(qq|paipai|soso|taotao)\.com($|\/|\\)/i).test(sUrl)||(/^[\w][\w\/\.\-_%]+$/i).test(sUrl)||(/^[\/\\][^\/\\]/i).test(sUrl)&? true&:
名称：XML注入漏洞
描述：Web程序代码中把用户提交的参数未做过滤就直接输出到XML中。
检测方法：通过修改参数来判断是否存在漏洞。
修复方案：在代码级输出时对XML特殊字符（“&”、“&”、“&]]”）进行转义。
名称：PHPInfo()信息泄漏漏洞
描述：Web站点的某些测试页面可能会使用到PHP的phpinfo()函数，会输出服务器的关键信息。如下图所示：
检测方法：访问http://[ip]/test.php 以及http://[ip]/phpinfo.php看是否成功。
修复方案：删除该PHP文件。
名称：测试页面泄漏在外网漏洞
描述：一些测试页面泄漏到外网，导致外界误传公司被黑客入侵。如下图所示：
检测方法：检测页面内容，看是否是测试页面。
修复方案：删除测试页面，例如test.cgi，phpinfo.php，info.pho， .svn/entries等。
名称：备份文件泄漏在外网漏洞
描述：编辑器或者人员在编辑文件时，产生的临时文件，如vim自动保存为.swp后缀、UltrlEditor自动保存.bak后缀等，这些文件会泄漏源代码或者敏感信息。如下图所示：
泄漏源代码可以让黑客完全了解后台开发语言、架构、配置信息等。下图是国内某著名网站曾经出现过的源代码泄漏漏洞：
检测方法：在cgi文件后面添加.bak、.swp、.old、~等后缀探测。
修复方案：删除备份文件。
名称：版本管理工具文件信息泄漏漏洞
描述：版本管理工具SVN和CVS会在所有目录添加特殊文件，如果这些文件同步到Web目录后就会泄漏路径等信息。如下图所示：
检测方法：访问http://[ip]/CVS/Entriesp 以及http://[ip]/.svn/entriesp看是否成功。
修复方案：删除SVN各目录下的.svn目录；删除CVS的CVS目录。
名称：HTTP认证泄漏漏洞
描述：Web目录开启了HTTP Basic认证，但未做IP限制，导致攻击者可以暴力破解帐号密码。如下图所示：
修复方案：限制IP访问该目录。
名称：管理后台泄漏漏洞
描述：管理后台的帐号和密码设计过于简单，容易被猜测到，导致攻击者可以暴力破解帐号密码。如下图所示：
修复方案：
1. 将管理后台的服务绑定到内网ip上，禁止开放在外网。
2. 如果该管理后台必须提供给外网访问，则未登录页面不要显示过多内容，防止敏感信息泄漏，登录帐号需经过认证，且密码设置规则尽量复杂，增加验证码，以防止暴力破解。
名称：泄漏员工电子邮箱漏洞以及分机号码
描述：泄漏员工内部电子邮箱以及分机号码相当于泄漏了员工内部ID，可以为黑客进行社会工程学攻击提供有价值的材料，同时也为黑客暴力破解后台服务提供重要的帐号信息。
修复方案：删除页面注释等地方中出现腾讯员工电子邮箱以及分机号码的地方。
名称：错误详情泄漏漏洞
描述：页面含有CGI处理错误的代码级别的详细信息，例如sql语句执行错误原因，php的错误行数等。
检测方法：修改参数为非法参数，看页面返回的错误信息是否泄漏了过于详细的代码级别的信息。
修复方案：将错误信息对用户透明化，在CGI处理错误后可以返回友好的提示语以及返回码。但是不可以提示用户出错的代码级别的详细原因。
名称：CSRF漏洞（Cross Site Request Forgery）
描述：用户以当前身份浏览到flash或者开发者网站时，JS/flash可以迫使用户浏览器向任意CGI发起请求，此请求包含用户身份标识，CGI如无限制则会以用户身份进行操作。
检测方法：
1. 在实际的测试过程中，测试人员需要判断操作是否为保存类操作，是否强制为POST方式传输参数。
判断方式是通过抓包工具把所有的POST参数都改成GET方式提交。
需要注意的是，这种方法只可防止图片跳转式CSRF漏洞，如果页面上有XSS漏洞话，CSRF无法防御。
2. 最简单的办法就是查阅该cgi是否带有无法预知的参数，例如随机字符串等。
修复方案：可使用以下任意办法防御CSRF攻击：
1. 在表单中添加form token（隐藏域中的随机字符串）；
2. 请求referrer验证；
3. 关键请求使用验证码。
名称：JSON-hijackin漏洞
描述：CGI以JSON形式输出数据，黑客控制的开发者站点以CSRF手段强迫用户浏览器请求CGI得到JSON数据，黑客可以获取敏感信息。
检测方法：
1. 检查返回的json数据是否包含敏感信息，例如用户ID，session key，邮箱地址，手机号码，好友关系链等。
2. 确认提交是否带有无法预知的参数，例如随机字符串等。
修复方案：可使用以下任意办法防御JSON-hijackin攻击：
1. 在请求中添加form token（隐藏域中的随机字符串）；
2. 请求referrer验证。
名称：文件上传漏洞
描述：接受文件上传的Web程序未对文件类型和格式做合法性校验，导致攻击者可以上传Webshell（.php、.jsp等）或者非期望格式的文件（.jpg后缀的HTML文件）
修复方案：文件上传的CGI做到：
1. 上传文件类型和格式校验；
2. 上传文件以二进制形式下载，不提供直接访问。
名称：crossdomain.xml配置不当漏洞
描述：网站根目录下的文件crossdomain.xml指明了远程flash是否可以加载当前网站的资源（图片、网页内容、flash等）。
如果配置不当，可能带来CSRF攻击。如下图所示：
检测方法：
访问http://[domain]/crossdomain.xml
修复方案：对于不需要外部加载资源的网站，crossdomain.xml中更改allow-access-from的domain属性为域名白名单。
修复大致样本参考如下（备注：示例中的app10000.qzoneapp.com,app10000.imgcache.qzoneapp.com请修改为自己指定的站点）：
&?xml version="1.0"?&
&cross-domain-policy&
&allow-access-from secure="false" domain="*.qq.com"/&
&allow-access-from secure="false" domain="*.soso.com"/&
&allow-access-from secure="false" domain="*.paipai.com"/&
&allow-access-from secure="false" domain="*.gtimg.cn"/&
&allow-access-from secure="false" domain="*.pengyou.com"/&
&allow-access-from secure="false" domain="app10000.qzoneapp.com"/&
&allow-access-from secure="false" domain="app10000.imgcache.qzoneapp.com"/&
&/cross-domain-policy&
名称：flash标签配置不当漏洞
描述：网页在引入flash的时候，会通过object/embed标签，在设置的时候，如果一些属性配置不当，会带来安全问题：
1. allowScriptAccess：是否允许flash访问浏览器脚本。如果不对不信任的flash限制，默认会允许调用浏览器脚本，产生XSS漏洞。
always（默认值），总是允许；sameDomain，同域允许；never，不允许
2. allowNetworking：是否允许flash访问ActionScript中的网络API。如果不对不信任的flash限制，会带来flash弹窗、CSRF等问题。
all，允许所有功能，会带来flash弹窗危害；internal，可以向外发送请求/加载网页；none，无法进行任何网络相关动作（业务正常功能可能无法使用）
修复方案：对于不信任flash源，allowScriptAccess设置为never，allowNetworking设置为none（业务需要可以放宽为internal）。
名称：embed标签配置不当漏洞
描述：网页会通过embed标签引入媒体文件（如rm、avi等视频音频），这些媒体文件中如有脚本指令（弹窗/跳转），如果没有限制就会出现安全问题。
检测方法：检查embed标签中是否有invokes标签。
修复方案：添加属性invokes值为-1。
名称：并发漏洞
描述：攻击者通过并发http/tcp请求而达到次获奖、多次收获、多次获赠等非正常逻辑所能触发的效果。
下面以简化的例子说明在交易的Web应用程序中潜在的并行问题，并涉及联合储蓄帐户中的两个用户（线程）都登录到同一帐户试图转账的情况：
帐户A有100存款，帐户B有100存款。用户1和用户2都希望从帐户A转10分到帐户B.
如果是正确的交易的结果应该是：帐户A 80分，帐户B 120分。
然而由于并发性的问题，可以得到下面的结果：
用户1检查帐户A （ = 100 分）
用户2检查帐户A （ = 100 分）
用户2需要从帐户A 拿取10 分（ = 90 分） ，并把它放在帐户B （ = 110 分）
用户1需要从帐户A 拿取10分（仍然认为含有100 个分）（ = 90 分） ，并把它放到B（ = 120 分）
结果：帐户A 90 分，帐户B 120 分。
检测方法：发送并发http/tcp请求，查看并发前后CGI 功能是否正常。例如：并发前先统计好数据，并发后再统计数据，检查2次数据是否合理。
修复方案：对数据库操作加锁。
名称：Cookie安全性漏洞
描述：cookie的属性设置不当可能会造成其他SNS游戏的运行出错等安全隐患。
检测方法：抓取数据包查看cookie的domain属性设定是否合理。
修复方案：对cookie字段的domain属性做严格的设定，openkey以及openid的domain只能设置到子域，禁止设置到父域qzoneapp.com。如下图所示：
名称：Frame-proxy攻击漏洞
描述：在一些老版本浏览器（比如IE6）下，Frame-proxy攻击可以把非常驻XSS漏洞以常驻型的方式做攻击。
修复方案：qzoneapp.com域名下的应用不能再通过iframe嵌入qq.com域名下页面。
原理如下图所示，假设域名xiaoyou.qq.com底下没有任何xss漏洞，然后xiaoyou.qq.com通过iframe嵌入了一个xxx.qzoneapp.com域名。
假设qq.com的某个子域vul.qq.com存在一个非常驻的xss漏洞，那么当xxx.qzoneapp.com通过iframe嵌入vul.qq.com时，访问xiaoyou.qq.com域名的用户将受到常驻型XSS漏洞的攻击。}