[转载]安全测试学习笔记一—-陈怀可

转自http://qa.taobao.com/?p=11352，有几个评论顺便贴上来了。感觉安全测试和性能测试不实践实在是不懂啊。

安全测试学习笔记一—-陈怀可
2011年1月23日 由 chenhuaike 留言 ??

来公司有三天了，这几天真正意义上的接触到了安全这方面的东西，感觉收获很大，但是同时也感觉到了自己以前那么多时间的荒废，这里想跟大家分享一下这几天到安全风险测试以后的学习所获…..

在这里就不讲测试流程之类的东西了，就黑盒测试学习心得写一下，由于第一次写，感觉压力很大，望各位前辈们多多指正啊！

黑盒测试心得：

1.XSS（cross-site-scripting）跨站脚本攻击

攻击过程描述：

攻击者发送链接给用户，用户无意识的点击了链接，就会发送脚本给服务器，服务器响应正当用户请求执行脚本返回数据给用户，在用户不知道的情况下把 cookie and session发给了攻击者，攻击者用用户那边获得的session伪装成用户实施破坏，至此XSS攻击结束.

测试漏洞的方法：工具测试paros，

手动测试一：

有输入框：非富文本框：输入<” huaike ‘>    ;富文本框：输入<img nerror=” alert(1)” src=http://xx.com>;

含页面链接参数： 可以改写参数

手动测试二：

非持久化：URL加入: ‘”></script><script>alert(1)</script><”

直接加：’”;alert(1);x=”‘

持久化：用户输入—>>  数据库输出—->>

DOM：利用闭合标签执行JS代码：”><script>alert(1)</script>

浏览器漏洞：http://www.google.cn/search?q=’”><script>alert(/xss/)</script><’

产生XSS漏洞的原因：用户不正当的输入

白盒测试时，发现XSS漏洞，必须强制编码规范

防御原理：

使用语言抵御的方法，或用框架把用户输入的数据转化成XML格式输出

如：PHP语言的htmlspecialchars()\htmlentities\strip_tags()等函数；

淘宝框架：taobao-security-2.0,jakarta-velocity-1.6.X

（注：频繁的使用$_REQUEST对象会引发CSRF漏洞，可以用$_Post代替）

2.CSRF（cross-site request forgery）跨站请求伪造攻击

攻击过程：

受害者发起伪造请求，攻击者发送恶意代码，受害者在不知不觉中发送执行恶意代码的请求，服务器响应受害者的正当请求确认执行，至此CSRF攻击结束。这里比较恶心的是受害者是请求的发送方但是受害者有完全无意识的受到。

CSRF攻击的本质：强迫受害者的浏览器向一个易受攻击的Web应用程序发送请求.

CSRF攻击特征：

1.用户请求修改信息——Web服务响应一张空白表单

2.用户修改信息并提交—-Web服务响应请求，保存

CSRF攻击直接跨越了第一步，直接修改数据….

攻击原理：

1.Get请求：隐式的通过http标签发出一个Get请求;

2.Post请求：通过Iframe能够设置界面大小为0的特性，加载页面自动执行，达到隐藏的目的；

登录式CSRF攻击：监听用户实际操作（这个不是很清楚，感觉就像钓鱼网站）；

Web2.0攻击：Web2.0虽然在一定程度上限制了CSRF攻击但是，通过脚本渗透漏洞，邮件或者上传文件攻击，也能达到攻击的目的

测试方法（针对taobao）：

表单：添加token，用Firefox插件httpfox获取post请求字段，去掉token，再用Firefox插件hackbar执行（其他网站可能是referer或者是根本就是乱七八糟的字段）

A标签：用form替换，用firebug或httpfox抓取A标签提交http://stc.taobao.net/wiki/Wiki.jsp?page=Csrf-url-token

防范思路：

1.form中添加秘密信息、用户代号验证等

2.双提交cookie：cookie在form. post之前被JS读取，限制跨域规则将被应用。

这里就涉及到同源策略：
同源策略：要求动态内容只能阅读与之同源的Http应答和cookie，而不能阅读来自不同源的内容，但是它对写操作没有任何限制。

同源：指的是同协议，同域名和同端口

可以通过被请求的页面中对JS的变量document.domain进行响应的设置，

可以使浏览器有限度地违反同源策略：

—————————————————————————————————————————

举例：

如果http://www.foo.com/bar/baz.html页面中含有下列内容：
< script. >
document.domain = “foo.com”;
< / script. >
那么任何http://xyz.foo.com/anywhere.html页面内的脚本都可以向http://www.foo.com/bar /baz.html发送HTTP请求，并可以读取其内容。在此种情况下，如果攻击者能够向http://xyz.foo.com /anywhere.html中注入HTML或JavaScript的话，那么他同时也能在http://www.foo.com/bar /baz.html中注入JavaScript代码。
为此，攻击者需要首先在http://xyz.foo.com/anywhere.html（其document.domain设为foo.com）中注入HTML和JavaScript，并向http://www.foo.com/bar/baz.html（其document.domain也设为 foo.com）中载入一个iframe，然后就可以通过JavaScript来访问该iframe的内容了。例如，http://xyz.foo.com/anywhere.html中的下列代码将在www.foo.com域中执行一个JavaScript的 alert（）函数：
< iframe. src=”http://www.foo.com/bar/baz.html”
nload=”frames[0].document.body.innerHTML+=’onerror=alert(1)’”>< / iframe. >
这样，document.domain将允许攻击者跨域活动（域际旅行）。注意，你不能在document.domain变量中放入任何域名，相反，只能在document.domain变量中放置“源”页面即所在页面的域名的上级域名，如www.foo.com的上级域名是foo.com 。

————————————————————————————————————————–

这里涉及到了域的概念（http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.4.1），

set-cookie机制:

Set-Cookie: <name>=<value>[; <name>=<value>]...
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure][; httponly]

里面也有对域的访问设置，其中的path and domain可以设置.

cookie机制里面有一个特性就是共享特性，在我理解就是在设置的域范围内可以共享这个cookie (不知道对不对)

同源策略虽然让Web的安全有了一定的提高但是在Web应用是极为不利的，

所以之后W3就提出了P3P概念：跨域访问cookie。

P3P：解决了Web应用上的难题，但是浏览器读取P3P头打开了第三方cookie的读取开关，带来了安全的隐患。这就要防止站外提交。

防止站外提交：判断Http头的Referer

但是Flash没有Referer头，这就要引申到Flash Security了，Flash的安全也是非常重要的可以说另外一个JS的安全隐患（从安全的威胁性来讲）

Flash Security由于时间有限暂时还没看到这一块，这里先放一放．不做重点介绍：

Discuz 论坛存在一个flash CSRF的Bug，由于Discuz!对flash跨域策略文件及上传图片文件处理不严导致可以绕过formhash及Referer的限制,导致csrf攻击.

这里稍微提一下Discuz的一类论坛的formhash技术，

formhash:类似于验证码，防止网站外部提交数据。

我们回到上面的CSRF攻击，额好像讲的差不多了，这里可以提一下JS的劫持技术

JS劫持技术:针对Json动态数据接口的攻击方式，也是一种变现的CSRF攻击

劫持技术还有DNS劫持技术、Dll劫持技术等等，额，原理也挺简单，不过这些跟CSRF不搭边，就不去讲了。

3.SQL Injection(SQL注入攻击)

定义：利用现有的应用程序，将恶意的SQL注入到后台数据库引擎执行的能力

攻击步骤：

1.判断Web环境是否可以注入（有数据操作的前提下）；

2.寻找注入点（特殊语句）；

3.猜解用户名、密码；

4.寻找Web管理后台入口；

5.入侵、破坏；

SQL注入条件：调用或查询数据库的动态页面；

原理：提交具有数据查询功能的语句，加入到程序将要提交的数据中去，再根据服务器返回信息判断数据库内容。

测试方法：

字符型： url后添加：’or’ 1′=’1 ;’or’1′=’2

数字型：url后添加：and 1=1;  and 1=2

确认注入点，判断数据库类型：

1:添加 :’  (不过这个估计大部分网站都行不通了，被数据清理了)

2:添加：；–（正常的是MSSQL，不正常的基本是Access）

3:添加： and exists(select count(*)from sysobjects);因为sysobjects是MSSQL的系统数据库所以会显示正常

and exists(select count(*)from msysobjects)

(access会显示：记录无法读取；’msysyobjects’没有读取权限)

预防思路：

1.数据清理：保证任何存在风险的字符不会传到SQL序列里面；

2.验证：确保提交的数据以希望的格式出现；

3.软件和数据更新，打补丁；

4.防火墙：含有完整的缺省规则设置；

5.删除不必要的数据库功能，有些冗余的功能容易引起漏洞；

6.权限设置，最好不要用sa权限；

7.加密；

8.不要泄录权限以外的信息；

9.定期更改数据库密码；

4.URL redirection（URL重定向攻击）

攻击过程：例如:

URL重定向：http://www.taobao.com/local-url?q=http://www.tabao.com/login.html

http://www.tabao.com/login.html是攻击者的恶意页面，提取你用户名、密码;

攻击者可以将URL的一部分URL16进制化，这样网址更加混乱，让受害者无法识别

测试方法:

Get:http;//www.fvck.com/url.phh?url=http://www.baidu.com

CRLF:http://www.fvck.com/url.php?url=%OA%ODLocation:%20http://www.baidu.com%OA%OD

JS:协议触发脚本

http://www.fvck.com/url.php?url=javascript.:alert%281%29

这里涉及到CRLF 注入，也常常称为Http响应拆分，

CRLF：将CRLF命令注入到系统中（CRLF模拟键盘‘Enter’键）

产生CRLF注入的原因：开发者并没有意识到有此类的攻击（开发者要特别注意）

预防思路：

1.window.location方式：参数固定方式（防JavaScript的跳转）

2.webx方式，默认自动处理（防服务端与外部跳转）

3.自定义宝贝链接，使用正则匹配处理：（防CRLF的跳转）
–String safRegex = “^(http[s]{0,1}://([a-z0-9\\-_]+\\.)*(taobao)\\.(com|cn)(/.*)*)$”;

好了，累死我了，就到这里了，要先走了，明天过来再编辑吧…..

终于改好了，发现已经写了好长好长了，主要是CSRF那一块花了很多的功夫，因为涉及到的面太广了，如有错误请各位前辈、师兄师姐们多多指正啊…….

写于：2011.1.23日 PM20:00

第一次编：2011.1.24.日 AM9:20

第二次编：2011.1.24.日 ＡＭ10:10

第三次编：2011.1.24.日  AM13:20
VN:F [1.9.6_1107]
please wait...
Rating: 7.5/10 (4 votes cast)
安全测试学习笔记一----陈怀可, 7.5 out of 10 based on 4 ratings 转载务必注明出处Taobao QA Team，原文地址：http://qa.taobao.com/?p=11352
 王挺 说：
2011/01/24 于 09:34

很好，顶一下，学习要循环渐进，继续努力！
另外，这些是整体的学习，针对某个方面的细节，还需深入：）
chenhuaike 说：
2011/01/24 于 09:45

某个方面的细节是指？？？
王挺 说：
2011/01/24 于 09:55

比如 js 劫持，更详细的是：
http://www.net-security.org/dl/articles/JavaScript_Hijacking.pdf

浅谈javascript函数劫持：
http://www.xfocus.net/articles/200712/963.html