也谈跨站脚本攻击与防御之xss

《也谈跨站脚本攻击与防御之xss》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、也谈跨站脚本攻击与防御之XSS～教育资源库　　网络上曾经有过关于跨站脚本攻击与防御的文章，但是随着攻击技术的进步，以前的关于跨站脚本攻击的看法与理论已经不能满足现在的攻击与防御的需要了，而且由于这种对于跨站脚本认识上的混乱，导致现在很多的程序包括现在的动网都存在着跨站脚本过滤不严的问题，希望本文能给写程序的与研究程序的带来一点思路。　　还是首先看看跨站脚本漏洞的成因，所谓跨站脚本漏洞其实就是Html的注入问题，恶意用户的输入没有经过严格的控制进入了数据库最终显示给来访的用户，导致可以在来访用户的浏览器里以浏览用户的身份执行HTml代码，数据流程如下:　　恶意用户的Htm

2、l输入>dash;>进入数据库>dash;>用户浏览器　　这样我们就可以清楚的看到Html代码是如何进入受害者浏览器的了，我们也就可以根据这个流程来讨论跨站脚本的攻击与防御了!　　1什么是HTml输入?　　这里给出一个HTml代码的示例　　以下是引用片段：＜imgsrc=.loveshell.jpgl标记，img是这个Html标记的名称，src是这个标记的第一个属性，=后面是这个属性的值，后面的l标记是包括很多元素的，并不是传统意义上的只有输入<>才会注入Html，事实上只要你的输入处在Html标签内，产生了新的元素或者属性，就实现了

3、跨站脚本攻击!实际上大多数隐秘的跨站脚本攻击是不需要<>的，因为现在的Ubb标签已经让你处在了Html标记之内，很有意思，不是么?　　2哪里才是罪恶的?　　既然我们的目标是引入代码在目标用户的浏览器内执行，那么我们来看看哪些地方可以引入HTml代码吧!如果用户可以不受限制的引入<>，那么很显然他可以完全操纵一个Html标记，譬如这样的形式，这对于追求安全的程序来说是绝对不允许的，所以首先要做转换的就是<>，通过如下代码:　　过滤代码:以下是引用片段：　　replace(str,<,<)replace(str,>,&g

4、t;)　　好了，用户可能不能构造自己的HTml标记了，那么利用已经存在的属性如何呢?下面的代码依然可以工作得很好:　　以下是引用片段：＜imgsrc=javascript:alert(/xss/)l标记里属性都支持javascript:[code]的形式，很好，很多的程序意识到了这一点，可能做了如下的转换:　　过滤代码　　以下是引用片段：　　Dimre　　　Setre=nel属性的值，注意是值而不是属性本身是支持#ASCii这种形式表示的，譬如上面的代码可以换成这样:　　以下是引用片段：＜imgsrc=javascript:alert(/xss/)p;,)　　行了，失去

5、它原来的意义了，用户不能以其他方式表示Html属性值了哦!等等，这样的过滤真可以相信么?只要发现这种过滤的关键字机制，饶过就是简单的问题了:　　以下是引用片段：<imgsrc=javascript:alert(/xss/)l代码的，首先说说事件机制吧:　　以下是引用片段：＜imgsrc=#onerror=alert(/xss/)＞　　这样依然可以执行代码的哦!明白问12下一页友情提醒：，特别！题出在哪了，不是么?有的程序员仿佛明白了，注意我说的是仿佛，动网就是一个典型的例子，事件属性不是要onerror么?很多人开始用正则表达式了，发现关键的词如onerror就会

6、做转换或者提示用户不执行，是不是没有机会了呢?　　当然不是的，事件只是让代码运行的一种方法而不是所有的，可以定义事件了那么也就可以实现自己弄出自己的属性了，试试下面的:　　以下是引用片段：＜imgsrc=#style=Xss:expression(alert(/xss/));＞　　呵呵，还是执行了哦!在做关键字过滤之后有人发现是不是属性之间分隔要用到空格，好，他们把空格堵死了(这样认为的人很多，呵呵)!将空格转成是个很普遍的方法?是么?甚至还可以让别人无法关键字拆分，不要太自信了，试试下面的代码看看如何:　　以下是引用片段：＜imgsrc=#/**/onerror=al

7、ert(/xss/)gsrc=.loveshell.＞　　这是个好的安全习惯，然后呢?就要让用户的输入处在安全的领域里了，这可以通过过滤用户输入里实现，但是不要忘记了，这个标签本身也是不安全的，过滤掉空格和tab键就不用担心关键字被拆分饶过了，然后就是用文章中提到的办法过滤掉script关键字，最后就是防止用户通过#这样的形式饶过检查，转换掉吧!　　在文章中开始提到的图里可以看到，数据的转换和过滤是可以在3个地方进行转换的，在接受数据的时候可以转换下，在进入数据库的时候可以转换下，在输出数据的时候也可以转换下，但是困惑在哪里呢?不得不面对