XSS和CSRF的原理及防御

XSS是跨站脚本攻击,是一种常见的web应用程序中的计算机安全漏洞,xss通过用户端注入恶意的可运行脚本,若服务器对用户输入不进行处理,直接将用户的输入
输出到浏览器,然后浏览器将会执行注入的脚本;
可以直接写一个可执行脚本,也可以直接写html,在标签里面写一个恶意脚本;
分类有两种:非持久型和持久型
非持久型:反射型XSS,数据是要呈现给用户的
持久型:存储型XSS,数据是存储在服务器中的
理论上,所有可输入的地方没有对输入数据进行处理的话,都会存在XSS漏洞,漏洞的危害取决于攻击代码的威力,攻击代码也不局限于script。
防御:
 1. 在输入流中截住form data中的恶意脚本(然后过滤,只允许用户输入应该合法的值)
具体是:我们可以截下进入server的每一个request,对用户的输入数据进行恶意脚本清理。其中有效的一个方法就是使用spring的filter。
 2.html encode,对用户输入进行编码,对标签进行转换

 
CSRF跨站点请求伪造
关键是:绕过用户伪造请求进行攻击

 CSRF攻击攻击原理及过程如下:
1. 用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A;
2.在用户信息通过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送请求到网站A;
3. 用户未退出网站A之前,在同一浏览器中,打开一个TAB页访问网站B;
4. 网站B接收到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方站点A;
5. 浏览器在接收到这些攻击性代码后,根据网站B的请求,在用户不知情的情况下携带Cookie信息,向网站A发出请求。
网站A并不知道该请求其实是由B发起的,所以会根据用户C的Cookie信息以C的权限处理该请求,导致来自网站B的恶意代码被执行。 
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攻击.黑客不能拿到cookie,也没办法对服务器返回的内容进行解析.唯一能做的就是给服务器发送请求.通过发送请求改变服务器中的数据.

上面的例子中攻击者诱导用户点击链接进行转账操作,使得银行数据库中受害者的金额发生了改变.


了解了csrf攻击的原理和目标,提出了两种防御手段
referer 验证
根据HTTP协议,在http请求头中包含一个referer的字段,这个字段记录了该http请求的原地址.通常情况下,执行转账操作的post请求
www.bank.com/transfer.php应该是点击www.bank.com网页的按钮来触发的操作,这个时候转账请求的referer应该是www.bank.com.而如果黑客
要进行csrf攻击,只能在自己的网站www.hacker.com上伪造请求.伪造请求的referer是www.hacker.com.所以我们通过对比post请求的referer是
不是www.bank.com就可以判断请求是否合法.
这种方式验证比较简单,网站开发者只要在post请求之前检查referer就可以,但是由于referer是由浏览器提供的.虽然http协议有要求不能篡改
referer的值.但是一个网站的安全性绝对不能交由其他人员来保证.
token 验证
从上面的样式可以发现,攻击者伪造了转账的表单,那么网站可以在表单中加入了一个随机的token来验证.token随着其他请求数据一起被提交
到服务器.服务器通过验证token的值来判断post请求是否合法.由于攻击者没有办法获取到页面信息,所以它没有办法知道token的值.那么伪造
的表单中就没有该token值.服务器就可以判断出这个请求是伪造的.
SQL注入攻击
这个就是在用户输入后增加一段sql语句,去非法读取服务器中的数据;
展开阅读全文

没有更多推荐了,返回首页