xss跨域访问（xss跨域发送cookie）

xss是什么意思 xss的意思介绍

跨站脚本，英文全称为Cross-Site Scripting，也被称为XSS或跨站脚本或跨站脚本攻击，是一种针对网站应用程序的安全漏洞攻击技术，是代码注入的一种。它允许恶意用户将代码注入网页，其他用户在浏览网页时就会收到影响。恶意用户利用XSS代码攻击成功后，可能得到很高的权限(如执行一些操作)、私密网页内容、会话和cookie等各种内容。

XSS攻击可以分为三种：反射型、存储型和DOM型。

反射型XSS：

又称非持久型XSS，这种攻击方式往往具有一次性。

攻击方式：攻击者通过电子邮件等方式将包含XSS代码的恶意链接发送给目标用户。当目标用户访问该链接时，服务器接收该目标用户的请求并进行处理，然后服务器把带有XSS代码的数据发送给目标用户的浏览器，浏览器解析这段带有XSS代码的恶意脚本后，就会触发XSS漏洞。

存储型XSS：

存储型XSS又称持久型XSS，攻击脚本将被永久地存放在目标服务器的数据库或文件中，具有很高的隐蔽性。

攻击方式：这种攻击多见于论坛、博客和留言板，攻击者在发帖的过程中，将恶意脚本连同正常信息一起注入帖子的内容中。随着帖子被服务器保存下来，恶意脚本也永久地被存放在服务器的后端存储器中。当其他用户浏览这个被注入了恶意脚本的帖子时，恶意脚本会在他们的浏览器中得到执行。

DOM型XSS

DOM全称Document Object Model，使用DOM可以使程序和脚本能够动态访问和更新文档内容、结构及样式。

DOM型XSS其实是一种特殊类型的反射型XSS，它是基于DOM文档对象模型的一种漏洞。

HTML的标签都是节点，而这些节点组成了DOM的整体结构——节点树。通过HTML DOM，树中所有节点均可通过JavaScript进行访问。所有HTML(节点)均可被修改，也可以创建或删除节点。

如何有效防止XSS攻击/AJAX跨域攻击

1，利用字符过滤漏洞，提交恶意js代码，当用户打开页面时执行

2，需要填写图片地址或css等直接在页面加载时执行的地方，填写恶意js [javascript：xxxx]，当用户打开包含图片的页面时，可以执行js。比如GET s1.game.com/fight/:id 表示发兵到某个用户，虽然做了用户验证，但没做来源验证，用户只需将这个地址发到同用户的论坛作为图片地址即可执行

3，通过跳转页面漏洞，比如 refer.php?message=xxxx ，页面上直接用 $_GET['message'] 的话，就会造成xss漏洞，把message的参数换成js代码或恶意网址，即可盗取用户cookie，或执行恶意js，或跳转到钓鱼页面等

4，利用浏览器或服务器0day漏洞

1，XSS主要是你的页面可以运行用户写的js，所以对所有的用户提交的数据进行过滤，对于判断用户是否登录状态的cookie信息进行加密，并且加上Ip信息，这样基本被盗取也无法获取登录权限

2，对update或delete的操作采用post方式提交，每次form里加一个唯一验证字符串，用hiden方式提交，用于服务器验证是否来自用户客户端

3，跳转程序需要对传递的url进行匹配判断，只允许特定的格式

4，时常关注安全方面的消息，一有漏洞即刻不上

最近网上流行的XSS是什么意思

最近网上流行的XSS是小学生的恶称，骂小学生的。

一是指某些人的想法、思维方式、对事物的认知和思考能力如孩子般幼稚、单纯、天真。

二是特指某类相对于同龄的人，在游戏竞技或者社交 *** 中， 态度傲慢、技术水准较差、拒绝与队友沟通、独断专行、忽视团队合作、甚至喜欢恶语相向的网游玩家。

三是指对没有接触过社会或社会经验不足。

扩展资料：

1、小学生技术菜，爱骂人，玻璃心（说他一句就挂机送人头，不管说什么，比如：中路的你不要再送了，然后他就说“我就送”，接着就开始了。）小学生的心思就像星空，摸不着猜不透。

2、大喷子（ *** 中对喜欢肆意谩骂、地域黑、招黑、互黑等网友的一种广泛性定义。），不分青红皂白就开喷。

3、说话不经过大脑考虑，以自我为中心，可能是在家被宠惯了。

4、没有接触过社会大家庭或接触社会经验不足。比如：参加工作，你要是不让新人上，永远都是新人。这也是小学生。

跨域以及解决跨域的几种方式

跨域是指浏览器允许向服务器发送跨域请求，从而克服Ajax只能 同源 使用的限制。

同源策略 是一种约定，由Netscape公司1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击。所谓同源是指"协议 + 域名 + 端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。

常见的跨域场景：

对于简单请求，浏览器会直接发出CORS请求，具体的就是在头信息中，增加一个 Origin 字段。

非简单请求是那种对服务器有特殊要求的请求，譬如 put delete *** ，或者 Content-Type 字段类型是 application/json 的，非简单请求在正式通信前，会增加一次请求，称为预检请求，也就是 options *** 。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的 XMLHttpRequest 请求，否则就报错。

与简单请求不同的是， option 请求多了2个字段：

Access-Control-Request-Method ：必须字段，用来列出浏览器的CORS请求会用到哪些HTTP *** 。

Access-Control-Request-Headers ：该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段。

服务器收到"预检"请求以后，检查了 Origin 、 Access-Control-Request-Method 和 Access-Control-Request-Headers 字段以后，确认允许跨源请求，就可以做出回应。

表明服务器支持的所有跨域请求的 *** 。

表明服务器支持的所有头信息字段，不限于浏览器在"预检"中请求的字段。

表示是否允许发送认证信息（Cookie）。

指定本次预检请求的有效期，单位为秒，允许缓存。在缓存期间，不用发出另一条预检请求。

什么是跨域，跨域的实现方式有哪些

跨源资源共享

通过 XHR 实现 Ajax 通信的一个主要限制,来源于跨域安全策略。默认情况下,XHR 对象只能访 问与包含它的页面位于同一个域中的资源。这种安全策略可以预防某些恶意行为。但是,实现合理的跨 域请求对开发某些浏览器应用程序也是至关重要的。

CORS(Cross-Origin Resource Sharing,跨源资源共享)是 W3C 的一个工作草案,定义了在必须访 问跨源资源时,浏览器与服务器应该如何沟通。CORS 背后的基本思想,就是使用自定义的 HTTP 头部 让浏览器与服务器进行沟通,从而决定请求或响应是应该成功,还是应该失败。

比如一个简单的使用 GET 或 POST 发送的请求,它没有自定义的头部,而主体内容是 text/plain。在 发送该请求时,需要给它附加一个额外的 Origin 头部,其中包含请求页面的源信息(协议、域名和端 口),以便服务器根据这个头部信息来决定是否给予响应。下面是 Origin 头部的一个示例:

如果服务器认为这个请求可以接受,就在 Access-Control-Allow-Origin 头部中回发相同的源信息(如果是公共资源,可以回发”*”)。例如:

如果没有这个头部,或者有这个头部但源信息不匹配,浏览器就会驳回请求。正常情况下,浏览器 会处理请求。注意,请求和响应都不包含 cookie 信息。

IE对CORS的实现

微软在 IE8 中引入了 XDR(XDomainRequest)类型。这个对象与 XHR 类似,但能实现安全可靠 的跨域通信。XDR 对象的安全机制部分实现了 W3C 的 CORS 规范。以下是 XDR 与 XHR 的一些不同之 处。

cookie 不会随请求发送,也不会随响应返回。

只能设置请求头部信息中的 Content-Type 字段。  不能访问响应头部信息。 只支持GET和POST请求。

这些变化使 CSRF(Cross-Site Request Forgery,跨站点请求伪造)和 XSS(Cross-Site Scripting,跨 站点脚本)的问题得到了缓解。被请求的资源可以根据它认为合适的任意数据(用户 *** 、来源页面等) 来决定是否设置 Access-Control- Allow-Origin 头部。作为请求的一部分,Origin 头部的值表示 请求的来源域,以便远程资源明确地识别 XDR 请求。

XDR 对象的使用 *** 与 XHR 对象非常相似。也是创建一个 XDomainRequest 的实例,调用 open() *** ,再调用 send() *** 。但与 XHR 对象的 open() *** 不同,XDR 对象的 open() *** 只接收两个 参数:请求的类型和 URL。

所有 XDR 请求都是异步执行的,不能用它来创建同步请求。请求返回之后,会触发 load 事件, 响应的数据也会保存在 responseText 属性中,如下所示。

在接收到响应后,你只能访问响应的原始文本;没有办法确定响应的状态代码。而且,只要响应有 效就会触发 load 事件,如果失败(包括响应中缺少 Access-Control-Allow-Origin 头部)就会触 发 error 事件。遗憾的是,除了错误本身之外,没有其他信息可用,因此唯一能够确定的就只有请求 未成功了。要检测错误,可以像下面这样指定一个 onerror 事件处理程序。

鉴于导致 XDR 请求失败的因素很多,因此建议你不要忘记通过 onerror 事件处 理程序来捕获该事件;否则,即使请求失败也不会有任何提示。

在请求返回前调用 abort() *** 可以终止请求:

与 XHR 一样,XDR 对象也支持 timeout 属性以及 ontimeout 事件处理程序。下面是一个例子。

这个例子会在运行 1 秒钟后超时,并随即调用 ontimeout 事件处理程序。

为支持 POST 请求,XDR 对象提供了 contentType 属性,用来表示发送数据的格式,如下面的例子所示。



这个属性是通过 XDR 对象影响头部信息的唯一方式。 其他浏览器对CORS的实现

Firefox 3.5+、Safari 4+、Chrome、iOS 版 Safari 和 Android 平台中的 WebKit 都通过 XMLHttpRequest 对象实现了对 CORS 的原生支持。在尝试打开不同来源的资源时,无需额外编写代码就可以触发这个行 为。要请求位于另一个域中的资源,使用标准的 XHR 对象并在 open() *** 中传入绝对 URL 即可,例如:

与 IE 中的 XDR 对象不同,通过跨域 XHR 对象可以访问 status 和 statusText 属性,而且还支 持同步请求。跨域 XHR 对象也有一些限制,但为了安全这些限制是必需的。以下就是这些限制。

不能使用 setRequestHeader()设置自定义头部。

不能发送和接收 cookie。

调用 getAllResponseHeaders() *** 总会返回空字符串。

由于无论同源请求还是跨源请求都使用相同的接口,因此对于本地资源,更好使用相对 URL,在访 问远程资源时再使用绝对 URL。这样做能消除歧义,避免出现限制访问头部或本地 cookie 信息等问题。

Preflighted Reqeusts

CORS 通过一种叫做 Preflighted Requests 的透明服务器验证机制支持开发人员使用自定义的头部、 GET 或 POST 之外的 *** ,以及不同类型的主体内容。在使用下列高级选项来发送请求时,就会向服务 器发送一个 Preflight 请求。这种请求使用 OPTIONS *** ,发送下列头部。

Origin:与简单的请求相同。

Access-Control-Request-Method:请求自身使用的 *** 。

Access-Control-Request-Headers:(可选)自定义的头部信息,多个头部以逗号分隔。

以下是一个带有自定义头部 NCZ 的使用 POST *** 发送的请求。

跨源资源共享

发送这个请求后,服务器可以决定是否允许这种类型的请求。服务器通过在响应中发送如下头部与 浏览器进行沟通。

Access-Control-Allow-Origin:与简单的请求相同。

Access-Control-Allow-Methods:允许的 *** ,多个 *** 以逗号分隔。

Access-Control-Allow-Headers:允许的头部,多个头部以逗号分隔。

Access-Control-Max-Age:应该将这个 Preflight 请求缓存多长时间(以秒表示)。

例如:

支持 withCredentials 属性的浏览器有 Firefox 3.5+、Safari 4+和 Chrome。IE 10 及更早版本都不 9 支持。



Preflight 请求结束后,结果将按照响应中指定的时间缓存起来。而为此付出的代价只是之一次发送 这种请求时会多一次 HTTP 请求。

支持 Preflight 请求的浏览器包括 Firefox 3.5+、Safari 4+和 Chrome。IE 10 及更早版本都不支持。

带凭据的请求

默认情况下,跨源请求不提供凭据(cookie、HTTP 认证及客户端 SSL 证明等)。通过将 withCredentials 属性设置为 true,可以指定某个请求应该发送凭据。如果服务器接受带凭据的请 求,会用下面的 HTTP 头部来响应。

如果发送的是带凭据的请求,但服务器的响应中没有包含这个头部,那么浏览器就不会把响应交给JavaScript(于是,responseText 中将是空字符串,status 的值为 0,而且会调用 onerror()事件处 理程序)。另外,服务器还可以在 Preflight 响应中发送这个 HTTP 头部,表示允许源发送带凭据的请求。

跨浏览器的CORS

即使浏览器对 CORS 的支持程度并不都一样,但所有浏览器都支持简单的(非 Preflight 和不带凭据 的)请求,因此有必要实现一个跨浏览器的方案。检测 XHR 是否支持 CORS 的最简单方式,就是检查 是否存在 withCredentials 属性。再结合检测 XDomainRequest 对象是否存在,就可以兼顾所有浏 览器了。



Firefox、Safari 和 Chrome 中的 XMLHttpRequest 对象与 IE 中的 XDomainRequest 对象类似,都 提供了够用的接口,因此以上模式还是相当有用的。这两个对象共同的属性/ *** 如下。

abort():用于停止正在进行的请求。

onerror:用于替代 onreadystatechange 检测错误。  onload:用于替代 onreadystatechange 检测成功。 - responseText:用于取得响应内容。

send():用于发送请求。

以上成员都包含在 createCORSRequest()函数返回的对象中,在所有浏览器中都能正常使用。

其他跨域技术

在 CORS 出现以前,要实现跨域 Ajax 通信颇费一些周折。开发人员想出了一些办法,利用 DOM 中 能够执行跨域请求的功能,在不依赖 XHR 对象的情况下也能发送某种请求。虽然 CORS 技术已经无处 不在,但开发人员自己发明的这些技术仍然被广泛使用,毕竟这样不需要修改服务器端代码。

图像Ping

上述之一种跨域请求技术是使用img标签。我们知道,一个网页可以从任何网页中加载图像,不 用担心跨域不跨域。这也是在线广告跟踪浏览量的主要方式。正如第 13 章讨论过的,也可以动态地创 建图像,使用它们的 onload 和 onerror 事件处理程序来确定是否接收到了响应。

动态创建图像经常用于图像 Ping。图像 Ping 是与服务器进行简单、单向的跨域通信的一种方式。 请求的数据是通过查询字符串形式发送的,而响应可以是任意内容,但通常是像素图或 204 响应。通过 图像 Ping,浏览器得不到任何具体的数据,但通过侦听 load 和 error 事件,它能知道响应是什么时 候接收到的。来看下面的例子。

这里创建了一个 Image 的实例,然后将 onload 和 onerror 事件处理程序指定为同一个函数。这 样无论是什么响应,只要请求完成,就能得到通知。请求从设置 src 属性那一刻开始,而这个例子在请 求中发送了一个 name 参数。

图像 Ping 最常用于跟踪用户点击页面或动态广告曝光次数。图像 Ping 有两个主要的缺点,一是只 能发送 GET 请求,二是无法访问服务器的响应文本。因此,图像 Ping 只能用于浏览器与服务器间的单向通信。

*** ONP

*** ONP 是 *** ON with padding(填充式 *** ON 或参数式 *** ON)的简写,是应用 *** ON 的一种新 *** , 在后来的 Web 服务中非常流行。 *** ONP 看起来与 *** ON 差不多,只不过是被包含在函数调用中的 *** ON, 4 就像下面这样。

*** ONP 由两部分组成:回调函数和数据。回调函数是当响应到来时应该在页面中调用的函数。回调 函数的名字一般是在请求中指定的。而数据就是传入回调函数中的 *** ON 数据。下面是一个典型的 *** ONP 请求。

这个 URL 是在请求一个 *** ONP 地理定位服务。通过查询字符串来指定 *** ONP 服务的回调参数是很 常见的,就像上面的 URL 所示,这里指定的回调函数的名字叫 handleResponse()。

*** ONP 是通过动态script元素来使用的,使用时可以为src 属性指定一个跨域 URL。这里的script元素与img元素类似,都有能力不受限制地从其他域 加载资源。因为 *** ONP 是有效的 JavaScript 代码,所以在请求完成后,即在 *** ONP 响应加载到页面中 以后,就会立即执行。来看一个例子。 

这个例子通过查询地理定位服务来显示你的 IP 地址和位置信息。

*** ONP 之所以在开发人员中极为流行,主要原因是它非常简单易用。与图像 Ping 相比,它的优点 在于能够直接访问响应文本,支持在浏览器与服务器之间双向通信。不过, *** ONP 也有两点不足。

首先, *** ONP 是从其他域中加载代码执行。如果其他域不安全,很可能会在响应中夹带一些恶意代码,而此时除了完全放弃 *** ONP 调用之外,没有办法追究。因此在使用不是你自己运维的 Web 服务时, 一定得保证它安全可靠。

其次,要确定 *** ONP 请求是否失败并不容易。虽然 HTML5 给script元素新增了一个 onerror 事件处理程序,但目前还没有得到任何浏览器支持。为此,开发人员不得不使用计时器检测指定时间内是否接收到了响应。但就算这样也不能尽如人意,毕竟不是每个用户上网的速度和带宽都一样。

参考：javascript高级程序设计第21章