XSS
XSS全称跨站脚本攻击(Cross Site Scripting),顾名思义,就是通过向某网站写入js脚本来实现攻击。如果熟悉或了解SQL注入的话,这么一说大概就十分清楚了。
如果是刚接触web开发的同学,可能乍想不明白,自己的网站,别人如何写入js脚本?开发中也会忽视容易被注入的点,导致XSS漏洞。
常见攻击形式
1. 非持久型攻击
有些网站的网页内容与url参数相关,比如很多搜索结果页。
如搜狗搜索xss:https://www.sogou.com/web?query=xss
。
那么网页中将存在会大量的a标签中带有query=xss
。
假如搜狗不给参数做任何安全处理,此时只要把query=xss
改成query=xss"a/><script>alert('XSS')</script>
。那么再打开此链接,就会直接执行alert。当然搜狗肯定是做了安全处理了。
这种攻击都是一次性的,得先找到漏洞地址后,设置好url,然后发给别人,诱使别人点击,从而通过执行脚本,获取对方的cookie。你得到对方的cookie后,就可以为所欲为了。
比如什么教务系统啦,发个xss注入的链接给你的老师,他一点击,跳到教务系统,神不知鬼不觉的把他的cookie发到你的服务器上。
你马上用老师的cookie登陆教务系统,改成绩,谦虚点,改个99分。
然后过几天被开除了。
2. 持久性攻击
这种攻击就不是在url上下手了,而是直接把注入代码写到网站数据库中。
有些网站呢,是内容生成网站,比如很多的博客站,有非常多的用户输入页。用户敲了一篇博客,存到网站数据库,然后网站读出内容,呈现给其他用户。
此时,如果不对用户输出的内容加以过滤,就可以注入一些js脚本内容。这样,别人看到这篇博客时,已经在执行他写的js脚本了。
之前新浪微博就爆发过这样的漏洞,一些大V先是中了招,然后自动向粉丝发送被攻击的页面地址,于是不断循环。
危害
xss注入后,本来你的网站页面js能做的事情,它都可以做了。除了上面所述的,我再随便举几个例子。
获取他人隐私信息。
破坏、修改网站原本页面内容。
跳转到其他恶意页面。
如果页面影响大,可以对其他网站发起DDoS攻击。
如何防范
其实现在大多成熟的web框架,自带过滤XSS脚本。很多浏览器如Chrome,也自带了XSS过滤器。但也正因为如此,开发过程中就更容易忽略这个问题。
1. 过滤用户输入
千万不要相信用户的任何输入,不要认为用户都是无害的。他们会想尽办法的绕弯来攻击。所以,任何用户的任何输出,都是不可信的。对于网站上有用户输入的部分,如各种表单内容、富文本内容,都应该对js脚本进行过滤,直接去除或者替换修改。
2. 对不可信输出编码
虽然已经过滤了用户输入,但总有可能百密一疏。所以还是不能相信任何用户输入的内容。如果网站需要将这些内容输出到页面上,必须得对这些数据先进行转义、编码。
3. 安全Cookie
之所以XSS能干很多坏事,有一部分是因为获取到了其他用户的cookie。所以将cookie设置HttpOnly后,js就无法获取到该网站的cookie。自然也没办法将其他用户的隐私信息传到自己的服务器。
4. 提高防范意识、多测试
如XSS、CSRF这样的攻击,已经有了很多成熟的防范手段,相信大家随便搜搜都能找到。但重点还是得培养这个防范意识,对于任何有可能执行脚本的地方,都应该多提防。对于任何用户输入的地方,都应该多测试,现在也有很多XSS测试工具。
CSRF
CSRF全称跨站请求伪造(Cross-site request forgery)。一听好像跟XSS没什么差,确实XSS也是实现CSRF的一种手段。XSS点是在于跨站注入脚本,进而干坏事。CSRF点在于利用各种手段,实现伪造其他网站请求,不一定是通过XSS。
常见攻击途径
1. 通过GET请求
假如某博客网站发布留言的请求是 get: http://www.blog.com/message?content=留言内容
。
现在我登录了此博客网站A,然后又访问了另外一个网站B,B网站直接跳转到:http://www.blog.com/message?content=嘿嘿嘿
。那么你就在A网站自动的留言了一条“嘿嘿嘿”这样的内容。
所以说一切操作资源的请求,都不应该是GET请求。
2. 通过XSS
之前也阐述过,如果cookie设置的不安全,就可以通过xss获取他人的cookie,有了别人的cookie,服务端再也分不清我是敌是友了,便可以为所欲为。切记,通过xss获取到cookie,发起的CSRF攻击,理论上无法防御。但可以通过一些手段提高技术门槛。
防御手段
1.规范请求类型。
任何资源操作的请求,必须是POST、PUT、DELETE,总之不能是GET
2.检查Referer
即检查请求头中的来源网站,从而保证此次请求来源于信任的网站。
3.设置请求Token
当我访问页面时,服务端会在页面写入一个随机token值,并设置token生命周期。之后我的请求就必须带上此次token值,请求过的token就会失效,无法再用。更加安全性的页面,如登录页面,应该加验证码。
4.防住第一道防线-XSS
再次强调,如果cookie被别人拿走,任何防御都将在理论上失效。上述的防御手段仅仅是提高攻击门槛。有了你的cookie,我可以直接请求你的页面,获取你的token,获取你的验证码图片并解析出来,然后再发起请求。而服务器还以为这是你本人。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。