来自海边的一片云
focus on Test Automation Methodologies
博客园 | 首页 | 发新随笔 | 发新文章 | 联系 | 订阅 订阅 | 管理

2009年12月24日

重新试着写blog

由于最近稍微轻松了一点,不需要一天当成48小时用,可以写写博客了。另外利用这段时间补充一些知识,make a deep dive.

:D

posted @ 2009-12-24 15:53 来自海边的一片云 阅读(2) 评论(0) 编辑
 

2007年8月2日

SQL injection
 

最近自己折腾一个数据库的东西,自己研究了一下SQL injection.

SQL injection 看起来还是挺有意思。可以看看youtube 上的一个SQL injection的实例还是比较简单的。http://www.youtube.com/watch?v=MJNJjh4jORY

 

当然这是最基本的SQL injection了。这种最基本的问题一般都出在query的字段连接上。

SqlCommand cmd = new SqlCommand(
  
"SELECT ID, FullName FROM User WHERE Login='"
  
+ Login.Text
  
+ "' AND Password='" 
  
+ Password.Text 
  
+ "'");

 

这种类型的错误相当常见,在一般情况下这个SQL语句执行没有任何问题,但是如果往用户的密码框里填上

' OR ''='

那么这个验证就被跳过去了。

当然高级的injecition 需要不停的试最终找到你的sever种这样的bug。 

具体的如何Injection 可以看后面的附件。

下面说一下如何尽可能地防止这种injection的发生:

1输入检查。相信所有的输入都是有害的!对所有接受的输入要检查,对非法数据进行休整使他变得合法(不一定正确).

2. 在编程上最好不要创建非类型安全的动态SQL语句,尽可能使用参数化的查询。

3.对上线的code都要做一个security review. 即使是小的更新也要做security review. 很多安全的漏洞发生在一个小更新上,这个更新太小了以至于让我们等到下次一起review吧。往往问题就出在这样的更新上,千里长堤毁于蚁穴。

4.尽量不要把机密资料以明文的形式存储在数据库中。密码之类的东西最好以单向hash的形式存储 。信用卡信息之类的东西尽量要加密。这样就算你的数据库被攻破了也能保证你的客户资料不会受到损失。

5. 用一些自动化测试来保证你的数据访问层和Web application能够抵御SQL injection的测试用例。这个对于需要经常更新的网站特别重要。能够有效防止你因为一个小的check in 而带来了安全漏洞。

6.不要在出错信息里泄露任何机密。

6.最小权限。确保你的Web application仅能访问必要的表。你的Web Application没有必要访问的表就必须确保他们无法被访问到。另外对于一些表能只给读权限就只给读权限。尽可能地限制Web application的访问权限。

Appendix :
1.SQL injection WhitePaper
2.深入分析SQL注入攻击及安全防范
3.How To: Protect from Form Injection Attacks with ASP.NET
4.How To: Protect from SQL Injection Attacks with ASP.NET 

posted @ 2007-08-02 01:23 来自海边的一片云 阅读(50) 评论(0) 编辑
 

2007年7月12日

Fuzz testing

看如下这段代码

 

 1int func1(int a,char b, char c)
 2
 3{
 4
 5         if(a>0&&a<100&& b==0 && c==255)
 6
 7         {
 8
 9                   printf("trig a bug");
10
11                   return 0;
12         }

13
14         return 1;
15}

16


这段代码的意思就是在参数 a,b,c所组成的参数空间中的 一个 特殊的 取值范围内即当0<a<100 ,b=0,c=255这个特殊 空间的时候会触发一个特殊的bug.当然实际的情况要比这种情况复杂的多。但是总会隐藏着类似的bug.

如何通过测试找到这些bug呢?这是一个问题,如何在一堆API的参数中找到这样的bug,这是一个大问题。嗯我们现在就讨论这个问题。


从我们便于理解的角度上看这个问题。其实我们希望我们的测试用例能够在一定概率的情况下在整个参数空间中触及到这个
bug的触发参数区域。

最笨的办法就是枚举测试空间,这个实际上并不是一个可行的方法。参数空间会随着参数的个数增加产生参数空间爆炸。

那到底该怎么办呢?在有限的资源下最大可能的找到这样的有问题的参数样本,可行的办法就是一堆随机的参数来然后通过合适的组合来尽可能的覆盖整个参数空间。现在问题就是如何产生合适的随机数了。下面我们就讨论一下如何或者比较好的随机数和如何比较好的组合在一起。

随机数:

随机数在软件开发中应用很广泛,在通信,加密,游戏中都需要随机数发生器。那什么是随机数呢?

随机数至少应该具备两个条件:

1. 数字序列在统计上是随机的。

2. 不能通过已知序列来推算后面未知的序列。

 

只有实际物理过程才是真正随机的。而一般来说,计算机是很确定的,它很难得到真正的随机数。所以计算机利用设计好的一套算法,再由用户提供一个种子值,得出被称为“伪随机数”的数字序列,这就是我们平时所使用的随机数。

 

这种伪随机数字足以满足一般的应用,但它不适用于加密等领域,因为它具有弱点:

 

1. 伪随机数是周期性的,当它们足够多时,会重复数字序列。

2. 如果提供相同的算法和相同的种子值,将会得出完全一样的随机数序列。

3. 可以使用逆向工程,猜测算法与种子值,以便推算后面所有的随机数列。

 

即是说: 随机序列 = F(算法, 种子)

 

说到随机数的产生不得不提的是我们的随机数发生器往往是可以预测的。例如我们常用的随机rand 函数就是一个可以预测的。

  int   __cdecl   rand   (void ) 
  { 

  return(((holdrand   =   holdrand   *   214013L   +   2531011L)   >>   16)   &   0x7fff); 

  }  

在这个的背后其实是用的是Knuth pseudo-random number-generating 技术。Knuth 在这本书中"Seminumerical Algorithms," Vol. 2 of The Art of Computer Programming (Addison-Wesley, 1981)发表了这个算法。在实际的应用中我们如何产生适合应用的随机数是根据实际情况定的。比如我们在输入参数的安全性方面没有任何先验知识的情况下,均匀分布是比较好的。在有先验知识或者是白盒测试的情况下正态分布可能是比较好的随机数分布。

这些分布的产生一般都是先产生一个平均分布然后求对应分布的逆。网上能找到一堆伪随机数生成器的代码。下面就随便给一个。如何产生一个更好的伪随机数,以后再说吧。

 1double AverageRandom(double min,double max)
 2{
 3    
 4    int minInteger = (int)(min*10000);
 5    int maxInteger = (int)(max*10000);
 6    int randInteger = rand()*rand();
 7    int diffInteger = maxInteger - minInteger;
 8    int resultInteger = randInteger % diffInteger + minInteger;
 9    return resultInteger/10000.0;
10}

11double Normal(double x,double miu,double sigma)   
12{
13    return  1.0/sqrt(2*PI*sigma) * exp(-1*(x-miu)*(x-miu)/(2*sigma*sigma));
14}

15double NormalRandom(double miu,double sigma,double min,double max)
16{
17    double dResult;
18    double dScope;
19    double dNormal;
20    do
21    {
22        dResult = AverageRandom(min,max);
23        dScope = AverageRandom(0,Normal(miu, miu, sigma));
24        dNormal = Normal(dResult, miu, sigma);
25    }
while( dScope > dNormal);
26    return dResult;
27    
28}

29

产生了随机数以后,参数进行适当的组合对对应的
API函数进行测试,这样就能在数学上保证尽可能得覆盖到对应得参数空间。最大可能的找到bug。

 

对于白盒测试来讲这种测试方法就更加适合,因为可以找一些比较合适的值作为初始值然后再产生随机的参数,就可以更有针对性的找到bug。

其实这是一种测试-FUZZ testing 的基本思想.

posted @ 2007-07-12 02:28 来自海边的一片云 阅读(169) 评论(0) 编辑
 

2007年4月27日

XML库的解析效率

XML库的解析效率主要包括解析、存储、导出、遍历、修改、XPath定位 等等。

XML的访问模型主要有三种,DOM, SAX,PULL。

DOM即Document Object Model,是最常用的XML解析库。DOM 适用的范围是频繁的不定向随机性访问,以及进行 xslt 之类的转换。 例如如果你需要用xpath 查询或者你要遍历, DOM.还是不错的 只读不只读基本上对规模/性能没什么太大影响. BTW XSLT的功能还是相当强大的。

如果格式基本上固定的单向读取,即不用遍历, 或者一次性遍历, SAX 就是了.

如果格式比较灵活且对效率要求高 pull 模型适用, XmlLite是基于 pull 模型的。在第四期的MSDN magazine上有关于XML lite的讨论。

因为 sax 是由 reader 将所有内容推给你,pull 则是在需要的时候将信息从 reader 拉回来,如果一个节点忽略不处理时,sax 引擎后台还是解析pull 则只需要做最简单的 tag 匹配就可跳过。

DOM在进行解析时基本上也是用 sax 实现,但因为其要维护完整的可随机访问、修改的树

在内存消耗和解析上的成本往往大大超过预期。跟 sax/pull 模型来说,加载xml树的时间,

以及占用内存的大小,基本上都是一个数量级以上差别。

从本质上来说,xml 实际上有两种使用策略,基于文档的和基于数据流的前者类似于xhtml或OpenDocument这样,结构复杂且相互嵌套甚至引用,后者类似RSS或XMPP相对来说格式固定,使用时只需要进行一次解析,当然还有很多将两种策略混用或介于两者之间的,需要独立分析需求。因此如何选择解析模型,实际上依赖于你是期望如何定义数据模型,而实际上就算解析模型,也不完全是这三种,有很多满足特定需求的实现。例如以前见过一个基于pull策略的dom模型,快速建立,随用随取,还有基于token的,一个64bit标记快速定位来读取和修改,为硬件实现优化等等诸如此类的思路。

 
posted @ 2007-04-27 00:14 来自海边的一片云 阅读(442) 评论(0) 编辑
 

2007年4月12日

Init()

哈哈。

posted @ 2007-04-12 00:03 来自海边的一片云 阅读(29) 评论(0) 编辑
 
仅列出标题  
随笔:5 文章:0 评论:0 引用:0
<2012年2月>
日一二三四五六
2930311234
567891011
12131415161718
19202122232425
26272829123
45678910

公告

昵称:来自海边的一片云
园龄:5年11个月
粉丝:0
关注:0

搜索

 
 

常用链接

  • 我的随笔
  • 我的评论
  • 我的参与
  • 最新评论
  • 我的标签

随笔分类

  • Testing(2) (rss)

随笔档案

  • 2009年12月 (1)
  • 2007年8月 (1)
  • 2007年7月 (1)
  • 2007年4月 (2)

文章分类

  • CLR, SSCLI and related (rss)
  • Enterprise (rss)

最新评论


Powered by: 博客园
模板提供:沪江博客
Copyright ©2012 来自海边的一片云