本文目录一览：
- 1、跨域以及解决跨域的几种方式
- 2、跨域产生的原因和解决方法
- 3、iis 怎么防止攻击
- 4、如何有效防止XSS攻击/AJAX跨域攻击
- 5、什么是跨域，跨域的实现方式有哪些
- 6、哪有放XSS跨站脚本工具的第三方工具/
跨域以及解决跨域的几种方式
跨域是指浏览器允许向服务器发送跨域请求，从而克服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）。
指定本次预检请求的有效期，单位为秒，允许缓存。在缓存期间，不用发出另一条预检请求。
跨域产生的原因和解决方法
同源策略。
同源策略是一种约定，由Netscape公司1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。同源策略限制以下几种行为：Cookie，LocalStorage和IndexDB无法读取DOM和JS对象无法获得AJAX请求不能发送
解决方案：JSONP跨域。原理：就是利用标签没有跨域限制，通过标签src属性，发送带有callback参数的GET请求，服务端将接口返回数据拼凑到callback函数中，返回给浏览器，浏览器解析执行，从而前端拿到callback函数返回的数据。缺点：只能发送get一种请求。
iis 怎么防止攻击
首先SQL注入字段表段要设置复杂一点 不要用admin和username之类的 密码要复杂MD5加密，后台登录页最好不要暴露编写robots.txt防止google黑客。服务器里设置用户读取写入权限防止webshell提权。3389重定向 关闭ICMP报文 除了80和你远程的登录端口不要关闭之外其他都关闭。用户名和密码要设置复杂一点 要防暴库 数据库要防止下载可以加入#之类的符号
路径要复杂 网站文件不要用db admin这样的敏感名字这样很容易被扫描出网站结构的还有及时打补丁 禁止cmd禁止用户创建
禁止xp_cmdshell之类的 禁止一些组件的运行 安装防火墙及时打补丁 网站敏感信息要删除 比如conn.asp之类的 最好网站不要有上传的一些功能 等等。服务器要防止IFEO劫持和缓冲区溢出 弱口令猜解等。这些都可以在防火墙设置 推荐网络安全狗这个防火墙是免费的。 要钱好一点的老牌子 龙盾
如何有效防止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，时常关注安全方面的消息，一有漏洞即刻不上
什么是跨域，跨域的实现方式有哪些
跨源资源共享
通过 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 只能用于浏览器与服务器间的单向通信。
JSONP
JSONP 是 JSON with padding(填充式 JSON 或参数式 JSON)的简写,是应用 JSON 的一种新方法, 在后来的 Web 服务中非常流行。JSONP 看起来与 JSON 差不多,只不过是被包含在函数调用中的 JSON, 4 就像下面这样。
JSONP 由两部分组成:回调函数和数据。回调函数是当响应到来时应该在页面中调用的函数。回调 函数的名字一般是在请求中指定的。而数据就是传入回调函数中的 JSON 数据。下面是一个典型的 JSONP 请求。
这个 URL 是在请求一个 JSONP 地理定位服务。通过查询字符串来指定 JSONP 服务的回调参数是很 常见的,就像上面的 URL 所示,这里指定的回调函数的名字叫 handleResponse()。
JSONP 是通过动态script元素来使用的,使用时可以为src 属性指定一个跨域 URL。这里的script元素与img元素类似,都有能力不受限制地从其他域 加载资源。因为 JSONP 是有效的 JavaScript 代码,所以在请求完成后,即在 JSONP 响应加载到页面中 以后,就会立即执行。来看一个例子。 
这个例子通过查询地理定位服务来显示你的 IP 地址和位置信息。
JSONP 之所以在开发人员中极为流行,主要原因是它非常简单易用。与图像 Ping 相比,它的优点 在于能够直接访问响应文本,支持在浏览器与服务器之间双向通信。不过,JSONP 也有两点不足。
首先,JSONP 是从其他域中加载代码执行。如果其他域不安全,很可能会在响应中夹带一些恶意代码,而此时除了完全放弃 JSONP 调用之外,没有办法追究。因此在使用不是你自己运维的 Web 服务时, 一定得保证它安全可靠。
其次,要确定 JSONP 请求是否失败并不容易。虽然 HTML5 给script元素新增了一个 onerror 事件处理程序,但目前还没有得到任何浏览器支持。为此,开发人员不得不使用计时器检测指定时间内是否接收到了响应。但就算这样也不能尽如人意,毕竟不是每个用户上网的速度和带宽都一样。
参考：javascript高级程序设计第21章
哪有放XSS跨站脚本工具的第三方工具/
不修改网站程序,使用第三方工具来防范XSS跨站式脚本攻击
网站要怎么防范常见的XSS跨站式脚本攻击呢，我们先从XSS跨站式脚本攻击的原理来说起。
网站遭受XSS跨站式脚本攻击的基本原理
1.本地利用漏洞，这种漏洞存在于页面中客户端脚本自身。
其攻击过程如下所示：
A给B发送一个恶意构造了Web的URL。
B点击并查看了这个URL。
恶意页面中的JavaScript打开一个具有漏洞的HTML页面并将其安装在B电脑上。
具有漏洞的HTML页面包含了在B电脑本地域执行的JavaScript。
A的恶意脚本可以在B的电脑上执行B所持有的权限下的命令。
2反射式漏洞，这种漏洞和本地利用漏洞有些类似，不同的是Web客户端使用Server端脚本生成页面为用户提供数据时，如果未经验证的用户数据被包含在页面中而未经HTML实体编码，客户端代码便能够注入到动态页面中。
其攻击过程如下：
A经常浏览某个网站，此网站为B所拥有。B的站点运行A使用用户名/密码进行登录，并存储敏感信息（比如银行帐户信息）。
C发现B的站点包含反射性的XSS漏洞。
C编写一个利用漏洞的URL，并将其冒充为来自B的邮件发送给A。
A在登录到B的站点后，浏览C提供的URL。
嵌入到URL中的恶意脚本在A的浏览器中执行，就像它直接来自B的服务器一样。此脚本盗窃敏感信息（授权、信用卡、帐号信息等）然后在A完全不知情的情况下将这些信息发送到C的Web站点。
3存储式漏洞，该类型是应用最为广泛而且有可能影响到Web服务器自身安全的漏洞，骇客将攻击脚本上传到Web服务器上，使得所有访问该页面的用户都面临信息泄漏的可能，其中也包括了Web服务器的管理员。
其攻击过程如下：
B拥有一个Web站点，该站点允许用户发布信息/浏览已发布的信息。
C注意到B的站点具有存储式的XXS漏洞。
C发布一个热点信息，吸引其它用户纷纷阅读。
B或者是任何的其他人如A浏览该信息，其会话cookies或者其它信息将被C盗走。
类型A直接威胁用户个体，而类型B和存储式漏洞所威胁的对象都是企业级Web应用。
网站遭受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)
举个例子，假如某个脆弱的页面的代码如下：
HTML
TITLEWelcome!/TITLE
Hi
SCRIPT
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
/SCRIPT
BR
Welcome to our system
…
/HTML
攻击者使用如下的URL访问时，则非常危险：
;scriptalert(document.cookie)/script
试了一下，貌似IE、FireFox等浏览器默认 对scriptalert(document.cookie)/script进行了编码，阻止了脚本的执行。但是对于 DOM操作还是要更加谨慎啊，比如把上面的页面修改一下，安全性就增强了不少：
SCRIPT
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);
}
else
{
window.alert("Security error");
}
/SCRIPT
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原样的出现在了页面源码中：
1. input type="text" class="13da-28fc-1683-944b Seach" name="w" value="XXX" /
OK，可以开始做文章了，我们将XXX替换为：abc"/scriptalert('haha')/scripta href="，返回的HTML代码如下：
1. input type="text" class="28fc-1683-944b-43e0 Seach" name="w" value="abc"/
2. scriptalert('haha')/script!--" /
这样，scriptalert('haha')/script被执行了。这里再举例一些XSS攻击行为：
1. IMG SRC="javascript:alert('XSS');"
2. IMG SRC=javascript:alert('XSS')
3. IMG SRC="javascript:alert(String.fromCharCode(88,83,83))"
4. IMG SRC="jav ascript:alert('XSS');"
5. SCRIPT/XSS SRC=""/SCRIPT
6. SCRIPTalert("XSS");///SCRIPT
7. iframe src=
8. INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');"
9. BODY BACKGROUND="javascript:alert('XSS')"
10. BODY ONLOAD=alert(document.cookie)
11. BODY onload!#$%()*~+-_.,:;?@[/|"]^`=alert("XSS")
12. IMG DYNSRC="javascript:alert('XSS')"
13. IMG DYNSRC="javascript:alert('XSS')"
14. BR SIZE="{alert('XSS')}"
15. IMG SRC='vbscript:msgbox("XSS")'
16. TABLE BACKGROUND="javascript:alert('XSS')"
17. DIV STYLE="width: expression(alert('XSS'));"
18. DIV STYLE="background-image: url(javascript:alert('XSS'))"
19. STYLE TYPE="text/javascript"alert('XSS');/STYLE
20. STYLE type="text/css"BODY{background:url("javascript:alert('XSS')")}/STYLE
21. ?='SCRIPTalert("XSS")/SCRIPT'?
22. A HREF="javascript:document.location=''"XSS/A
23. IMG SRC=javascript:alert('XSS')
24. EMBED SRC="" AllowScriptAccess="always"/EMBED
25. a="get";
26. b="URL(""";
27. c="javascript:";
28. d="alert('XSS');"")";
29. eval(a+b+c+d);
总结一下，要防止XSS跨站式脚本攻击主要是要在查询字符串(QueryString)，表单数据（PostData）以及Cookie甚至HTTP报头（Header）中防止掉一些javascript关键字和一些敏感的字符（单引号，分号）以及SQL语言的关键字，以及防止他们使用encode编码。
用ASP或者PHP脚本来实现上面的这些想起来就很麻烦。下面就来介绍下用一个第三方工具IISUTM来处理上面我们说到的问题。
准备工作：先去下载最新的IISUTM版本。
根据IISUTM网站防火墙安装及操作手册 中的说明把IISUTM部署到你的服务器上来，这里需要注意的是使用Windows 2003+iis6的服务器，需要开启iis中“以IIS5.0 隔离模式运行 www 服务”选项才能正常使用该软件。
安装完成，通过浏览器访问IISUTM的配置管理界面默认的是，这个是私有地址，只能在该服务器上访问，你需要任何地方都能访问的话，可以在安装的时候IP地址的选项那里填入你服务器的公网IP地址，和你所开放的端口。这样你就可以通过你配置的地址进行访问，或者你可以在iis中直接管理名为IISUTM的站点。
登陆管理界面后点击上面导航栏中的“基本设置”，然后点击左边菜单的“防XSS攻击”链接。
开启该链接里所有的选项，选中之后IISUTM会自动保存配置，下面的“使用不允许的发送序列”是该软件提供的XSS攻击关键字的特征库，你可以根据你网站的情况进行更改（最好不要修改）。
确认以上的配置以后，你可以返回到IISUTM管理界面的首页，这里会列出最近服务器遭受到的攻击以及详细，赶紧去看看你的网站是不是随时有人在进行SQL注入吧，以及哪些攻击被IISUTM处理掉了。