心有多大,舞台就有多大,希望结识做网站测试的朋友们; 测试需要横向扩展也需要纵向延伸 我相信自己会在测试的道路上走的很远..............................

发布新日志

  • 安全测试(转)

    2010-07-20 17:07:44

    前段时间接手了对网站进行安全测试的任务。

    刚接到的时候心里非常紧张,因为什么都不懂的,以前也没有接触过这个方面的。虽然小组有人共享过一点东西,那毕竟是理论,大家对于实际操作都是是懂非懂的。

    后来找了很多有关这方面的东西,于是概括一下,主要就是测试下面那些内容了(一些文绉绉的理论就不讲啦,我只是总结测试动作):

    一、没有进行xss过滤的情况:

    a、url中的所有参数值用  '"></script><script>alert("hello,my girl!")</script> 代替测试:

    现象:跳出“hello,my girl!”提示框;

    b、text框输入 '"></script><script>alert("hello,my girl!")</script>,点击提交:

    现象:没有正常写入数据库;或查看阅览页面或者从数据库显示时,没有被转义;

    c、副文本编辑器输入<img nerror = "alert(123)" src=http://xxx.com>;

    现象:没有正常写入数据库;查看阅览页面或从数据库显示时,出现js错误或者排版出现问题;

    d、在数据库字段中写入'"></script><script>alert("hello,my girl!")</script>,查看页面显示:

    现象:跳出alert;或者页面出现js问题等;查看源代码时,没有进行转义;

    注意点:

    1、很多时候,html代码的<title >和<meta  >中的参数会显示数据库的产品名呀,或者其他有可能显示乱码的参数,所以这种地方也需要注意,以'"/></script><script>alert("hello,my girl!")</script>为例,就会跳出alert值,或者显示</script><script>alert("hello,my girl!")</script>不应该显示的值,因为被",或者/>拦截了。

    2、有些html链接,如果url是×××.产品名.html的时候,如果产品名或者其他参数有可能会是乱码的时候,它会把前面的一些单引号或者双引号先优先使用了,以'"/></script><script>alert("hello,my girl!")</script>为例,url = "×××.'"/></script><script>alert("hello,my girl!")</script>",这样的情况的话,页面就会显示/></script><script>alert("hello,my girl!")</script>"这样的不应该显示的值。

    3、如果你的网站有搜索框,那就用包含这样的值的产品名进行搜索,有可能搜索不出来,有可能是页面跳出alert值,或者页面出现了不该出现的代码行等。

    4、主要点就是输入框,显示,链接,url输入,搜索等。

    二、关于crsf:

    1、搜索在所有我数据提交的地方,是否都加了token值;

    2、修改数据提交出的crsf,再提交,是否能正常提交,是否提示数据超时;

    3、每个不同的用户登录后,token值是否都是新值。

    注意点:

    a、虽然加token貌似看起来不难,看到有什么提交按钮就加上token就好了,所以很多时候开发会忘记软更新的时候加上token。比如说,删除这个动作是每条数据产生的时候,跟在数据后面的url链接。我在测试这个的时候,对应的开发就忘记了所有软更新的token添加。所以这个地方需要特别注意;

    b、还有一点是,每个用户登录后的token是不一致的。比如说a用户这一次登录后token值是1111,b用户这一次登录后2222.但登录后,不管什么操作,token值就是一致了。意思是比如a用户产生的token值是1111,那这个值将伴随他直到他下一次重新登录。

    这次我测试的部分只有这两个部分,关于sql注入等,还没有涉及,下次有机会整理。

  • ⊙﹏⊙b汗,我怎么就没想到呢?----验证码漏洞攻击问题

    2009-07-06 17:33:51

      刚才开了个小会,部署这周的工作,我的直接领导问开发上周一个模块的开发和测试情况,
      领导:1、为防止用户进行多次尝试输入不同的PIN来得到有效的PIN,你进行这方面的安全处理了吗?
       2、当用户输入新的PIN时,下面的验证码随之更新没有?(虽然页面并没有变化)

       对于这两个问题,本来应该由我测试提出的,可是当时我怎么就没想到呢?⊙﹏⊙b汗啊
       当时我测试的时候,只是感觉验证码没随之更新感觉好奇怪,但也没往深里想,现在想来,我还真是晕,不应该啊。。。。。。

       验证码作用:防止有人利用机器人自动批量注册、对特定的注册用户用特定程序暴力破解方式进行不断的登陆、灌水。因为验证码是一个混合了数字或符号的图片,人眼看起来都费劲,机器识别起来就更困难。

          同样对于PIN也是,为防止用户批量尝试来获取到有效的PIN,所以当每次输入新的PIN时,验证码也要随之更新。

         结论:
         1、功能模块涉及到验证码的地方每次输入新的东西或刷新,验证码也一定要随之更新,否则就失去了它存在的意义!切记!!
         2、为防止用户的这种恶意获取,可以采取当用户输入一定次数的错误数据时,阻止其进一步使用的方法来达到安全的目的。
         


  • 090601 web安全性测试—sql注入(1)

    2009-06-01 21:18:42

       昨天本来计划是学LR呢,今天因为要对网站安全性进行测试,所以,学习了一些sql注入的知识。

     

       庆贺一下,在网上看一些sql注入的东东,于是想到了对网站的输入框进行一些测试,本来是想在输入框中输入<script>alter("abc")<script>,但是输入框有字符限制,只好输入<script>,结果网站出大问题了,呵呵,终于又出现了个bug。高兴。。。。。。。

     

       另一个就是在URL最后随意输入一些字符或数字,结果,新闻模块那出现了问题,暴露了网站的一些信息,又一个bug,高兴下。。。。。。。

     

        下面把今天看到的有关sql注入方面的知识整理如下:

     

        SQL 注入是一种攻击方式,在这种攻击方式中,恶意代码被插入到字符串中,然后将该字符串传递到 SQL Server 的实例以进行分析和执行。任何构成 SQL 语句的过程都应进行注入漏洞检查,因为 SQL Server 将执行其接收到的所有语法有效的查询。一个有经验的、坚定的攻击者甚至可以操作参数化数据。

     

        SQL 注入的主要形式包括直接将代码插入到与 SQL 命令串联在一起并使其得以执行的用户输入变量。一种间接的攻击会将恶意代码注入要在表中存储或作为元数据存储的字符串。在存储的字符串随后串连到一个动态 SQL 命令中时,将执行该恶意代码。

        注入过程的工作方式是提前终止文本字符串,然后追加一个新的命令。由于插入的命令可能在执行前追加其他字符串,因此攻击者将用注释标记“--”来终止注入的字符串。执行时,此后的文本将被忽略。

     

        以下脚本显示了一个简单的 SQL 注入。此脚本通过串联硬编码字符串和用户输入的字符串而生成一个 SQL 查询:

      var Shipcity;

        ShipCity = Request.form. ("ShipCity");

        var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

     

    用户将被提示输入一个市县名称。如果用户输入 Redmond,则查询将由与下面内容相似的脚本组成: 

     

        SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

    但是,假定用户输入以下内容:

     

        Redmond'; drop table OrdersTable--

     

    此时,脚本将组成以下查询:

     

        SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

     

       分号 (;) 表示一个查询的结束和另一个查询的开始。双连字符 (--) 指示当前行余下的部分是一个注释,应该忽略。如果修改后的代码语法正确,则服务器将执行该代码。SQL Server 处理该语句时,SQL Server 将首先选择 OrdersTable 中的所有记录(其中 ShipCity Redmond)。然后,SQL Server 将删除 OrdersTable

     

         只要注入的 SQL 代码语法正确,便无法采用编程方式来检测篡改。因此,必须验证所有用户输入,并仔细检查在您所用的服务器中执行构造 SQL 命令的代码。本主题中的以下各部分说明了编写代码的最佳做法。

     

         验证所有输入

        

        始终通过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时,请注意应用程序的体系结构和部署方案。请注意,设计为在安全环境中运行的程序可能会被复制到不安全的环境中。以下建议应被视为最佳做法:

     

        如果一个用户在需要邮政编码的位置无意中或恶意地输入了一个 10 MB MPEG 文件,应用程序会做出什么反应?

     

        如果在文本字段中嵌入了一个 DROP TABLE 语句,应用程序会做出什么反应?

        测试输入的大小和数据类型,强制执行适当的限制。这有助于防止有意造成的缓冲区溢出。

        

    输入字符

    Transact-SQL 中的含义

    ;

    查询分隔符。

    '

    字符数据字符串分隔符。

    --

    注释分隔符。

    /* ... */

    注释分隔符。服务器不对 /* */ 之间的注释进行处理。

    xp_

    用于目录扩展存储过程的名称的开头,如 xp_cmdshell

     

     

           

     

     

     

     

Open Toolbar