*** 安全攻击 *** 分为

1、跨站脚本-XSS

相关研究表明，跨站脚本攻击大约占据了所有攻击的40%，是最为常见的一类 *** 攻击。但尽管最为常见，大部分跨站脚本攻击却不是特别高端，多为业余 *** 罪犯使用别人编写的脚本发起的。

跨站脚本针对的是网站的用户，而不是Web应用本身。恶意黑客在有漏洞的网站里注入一段代码，然后网站访客执行这段代码。此类代码可以入侵用户账户，激活木马程序，或者修改网站内容，诱骗用户给出私人信息。

防御 *** ：设置Web应用防火墙可以保护网站不受跨站脚本攻击危害。WAF就像个过滤器，能够识别并阻止对网站的恶意请求。购买网站托管服务的时候，Web托管公司通常已经为你的网站部署了WAF，但你自己仍然可以再设一个。

2、注入攻击

开放Web应用安全项目新出炉的十大应用安全风险研究中，注入漏洞被列为网站更高风险因素。SQL注入 *** 是 *** 罪犯最常见的注入 *** 。

注入攻击 *** 直接针对网站和服务器的数据库。执行时，攻击者注入一段能够揭示隐藏数据和用户输入的代码，获得数据修改权限，全面俘获应用。

防御 *** ：保护网站不受注入攻击危害，主要落实到代码库构建上。比如说：缓解SQL注入风险的首选 *** 就是始终尽量采用参数化语句。更进一步，可以考虑使用第三方身份验证工作流来外包你的数据库防护。

3、模糊测试

开发人员使用模糊测试来查找软件、操作系统或 *** 中的编程错误和安全漏洞。然而，攻击者可以使用同样的技术来寻找你网站或服务器上的漏洞。

采用模糊测试 *** ，攻击者首先向应用输入大量随机数据让应用崩溃。下一步就是用模糊测试工具发现应用的弱点，如果目标应用中存在漏洞，攻击者即可展开进一步漏洞利用。

防御 *** ：对抗模糊攻击的更佳 *** 就是保持更新安全设置和其他应用，尤其是在安全补丁发布后不更新就会遭遇恶意黑客利用漏洞的情况下。

4、零日攻击

零日攻击是模糊攻击的扩展，但不要求识别漏洞本身。此类攻击最近的案例是谷歌发现的，在Windows和chrome软件中发现了潜在的零日攻击。

在两种情况下，恶意黑客能够从零日攻击中获利。之一种情况是：如果能够获得关于即将到来的安全更新的信息，攻击者就可以在更新上线前分析出漏洞的位置。第二种情况是： *** 罪犯获取补丁信息，然后攻击尚未更新系统的用户。这两种情况，系统安全都会遭到破坏，至于后续影响程度，就取决于黑客的技术了。

防御 *** ：保护自己和自身网站不受零日攻击影响最简便的 *** ，就是在新版本发布后及时更新你的软件。

5、路径(目录)遍历

路径遍历攻击针对Web

root文件夹，访问目标文件夹外部的未授权文件或目录。攻击者试图将移动模式注入服务器目录，以便向上爬升。成功的路径遍历攻击能够获得网站访问权，染指配置文件、数据库和同一实体服务器上的其他网站和文件。

防御 *** ：网站能否抵御路径遍历攻击取决于你的输入净化程度。这意味着保证用户输入安全，并且不能从你的服务器恢复出用户输入内容。最直观的建议就是打造你的代码库，这样用户的任何信息都不会传输到文件系统API。即使这条路走不通，也有其他技术解决方案可用。

6、分布式拒绝服务-DDOS

DDoS攻击本身不能使恶意黑客突破安全措施，但会令网站暂时或永久掉线。相关数据显示：单次DDOS攻击可令小企业平均损失12.3万美元，大型企业的损失水平在230万美元左右。

DDoS旨在用请求洪水压垮目标Web服务器，让其他访客无法访问网站。僵尸 *** 通常能够利用之前感染的计算机从全球各地协同发送大量请求。而且，DDoS攻击常与其他攻击 *** 搭配使用;攻击者利用DDOS攻击吸引安全系统火力，从而暗中利用漏洞入侵系统。

防御 *** ：保护网站免遭DDOS攻击侵害一般要从几个方面着手：首先，需通过内容分发 *** 、负载均衡器和可扩展资源缓解高峰流量。其次，需部署Web应用防火墙，防止DDOS攻击隐蔽注入攻击或跨站脚本等其他 *** 攻击 *** 。

7、中间人攻击

中间人攻击常见于用户与服务器间传输数据不加密的网站。作为用户，只要看看网站的URL是不是以https开头就能发现这一潜在风险了，因为HTTPS中的s指的就是数据是加密的，缺了S就是未加密。

攻击者利用中间人类型的攻击收集信息，通常是敏感信息。数据在双方之间传输时可能遭到恶意黑客拦截，如果数据未加密，攻击者就能轻易读取个人信息、登录信息或其他敏感信息。

防御 *** ：在网站上安装安 *** 接字层就能缓解中间人攻击风险。SSL证书加密各方间传输的信息，攻击者即使拦截到了也无法轻易破解。现代托管提供商通常已经在托管服务包中配置了SSL证书。

8、暴力破解攻击

暴力破解攻击是获取Web应用登录信息相当直接的一种方式。但同时也是非常容易缓解的攻击方式之一，尤其是从用户侧加以缓解最为方便。

暴力破解攻击中，攻击者试图猜解用户名和密码对，以便登录用户账户。当然，即使采用多台计算机，除非密码相当简单且明显，否则破解过程可能需耗费几年时间。

防御 *** ：保护登录信息的更佳办法，是创建强密码，或者使用双因子身份验证。作为网站拥有者，你可以要求用户同时设置强密码和2FA，以便缓解 *** 罪犯猜出密码的风险。

9、使用未知代码或第三方代码

尽管不是对网站的直接攻击，使用由第三方创建的未经验证代码，也可能导致严重的安全漏洞。

代码或应用的原始创建者可能会在代码中隐藏恶意字符串，或者无意中留下后门。一旦将受感染的代码引入网站，那就会面临恶意字符串执行或后门遭利用的风险。其后果可以从单纯的数据传输直到网站管理权限陷落。

防御 *** ：想要避免围绕潜在数据泄露的风险，让你的开发人员分析并审计代码的有效性。

10、 *** 钓鱼

*** 钓鱼是另一种没有直接针对网站的攻击 *** ，但我们不能将它除在名单之外，因为 *** 钓鱼也会破坏你系统的完整性。

*** 钓鱼攻击用到的标准工具就是电子邮件。攻击者通常会伪装成其他人，诱骗受害者给出敏感信息或者执行银行转账。此类攻击可以是古怪的419骗局，或者涉及假冒电子邮件地址、貌似真实的网站和极具说服力用语的高端攻击。

防御 *** ：缓解 *** 钓鱼骗局风险最有效的 *** ，是培训员工和自身，增强对此类欺诈的辨识能力。保持警惕，总是检查发送者电子邮件地址是否合法，邮件内容是否古怪，请求是否不合常理。

如何正确防御xss攻击?

1、基于特征的防御。XSS漏洞和著名的SQL注入漏洞一样，都是利用了Web页面的编写不完善，所以每一个漏洞所利用和针对的弱点都不尽相同，这就是给XSS漏洞防御带来的困难，不可能以单一特征来概括所有XSS攻击。

传统的XSS防御在进行攻击鉴别时多采用特征匹配方式，主要是针对JavaScript这个关键词进行检索，但是这种鉴别不够灵活，凡是提交的信息中各有JavaScript时，就被硬性的判定为XSS攻击。

2、基于代码修改的防御。Web页面开发者在编写程序时往往会出现一些失误或漏洞，XSS攻击正是利用了失误和漏洞，因此一种比较理想的 *** 就是通过优化Web应用开发来减少漏洞，避免被攻击：

①用户向服务器上提交的信息要对URL和附带的HTTP头、POST数据等进行查询，对不是规定格式、长度的内容进行过滤。

②实现Session标记、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。

③确认接收的内容被妥善的规范化，仅包含最小的、安全的Tag，去掉任何对远程内容的引用，使用HTTP only的cookie。

3、客户端分层防御策略。客户端跨站脚本攻击的分层防御策略是基于独立分配线程和分层防御策略的安全模型。它建立在客户端，这是它与其他模型更大的区别。之所以客户端安全性如此重要，客户端在接受服务器信息，选择性的执行相关内容。这样就可以使防御XSS攻击变得容易，该模型主要由三大部分组成：

①对每一个网页分配独立线程且分析资源消耗的网页线程分析模块;

②包含分层防御策略四个规则的用户输入分析模块;

③保存互联网上有关XSS恶意网站信息的XSS信息数据库。

跨站脚本攻击xss的原理是什么？有什么危害？如何防范

xxs攻击原理是网页对用户输入的字符串过滤不严，导致在提交输入信息的时候浏览器执行了黑客嵌入的xxs脚本，致使用户信息泄露。黑客可将伪装过的含义脚本语句的链接发送给受害者，当受害者点击链接的时候，由于网页没有过滤脚本语句，所以浏览器执行了脚本语句，而这个脚本语句的作用是将用户的cookie发送到黑客指定的地址，然后黑客就可以利用受害者的cookie窃取受害者的个人信息等等。这种攻击对服务器没有多大危害，但对用户危害很大，要防范这种攻击应该在设计网站的时候对用户提交的内容进行严格的过滤。

如何彻底防范XSS漏洞？

谈到XSS漏洞攻击，可能很多童鞋或多或少的晓得一些基础的东西。

XSS是一种经常出现在web应用中的计算机安全漏洞，恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。详细的防范和修复 *** ，一两句话是说不清楚的，建议你去i春秋学院听一听这方面的课程吧，知道创宇录制的“WEB安全漏洞原理分析”课程就有专门讲XSS漏洞的。很专业，很牛B！

黑客攻击常见的几种方式及预防措施

比较常见的攻击方式：sql注入，xss，弱口令，敏感信息泄露，安全配置错误等，建议参考owasp top 10。

预防：定期检查服务器日志，更改网站管理密码，如有一定代码基础可参考360的网站安全防注入代码进行代码安全控制，对网站目录进行权限控制等，对网站整体安全进行不定期的安全扫描，可使用第三方免费的扫描服务，如百度网站安全检测等，另外可接入第三方云安全服务，对网站进行ip隐藏，注入等防止操作，强烈不推荐服务器安全各类安全软件，导致服务器各种卡死还没有任何作用。网站出问题大部分都是第三方安全软件导致！建议可多去一些安全门户网进行安全知识的普及，推荐两个优秀的安全导航站点：安全圈info，攻防小组导航。强烈推荐。

ps：百度知道手机版竟然无法进行排版，强烈吐槽一波。

如何防范XSS跨站脚本攻击测试篇

不可信数据 不可信数据通常是来自HTTP请求的数据，以URL参数、表单字段、标头或者Cookie的形式。不过从安全角度来看，来自数据库、 *** 服务器和其他来源的数据往往也是不可信的，也就是说，这些数据可能没有完全通过验证。 应该始终对不可信数据保持警惕，将其视为包含攻击，这意味着在发送不可信数据之前，应该采取措施确定没有攻击再发送。由于应用程序之间的关联不断深化，下游直译程序执行的攻击可以迅速蔓延。 传统上来看，输入验证是处理不可信数据的更好办法，然而，输入验证法并不是注入式攻击的更佳解决方案。首先，输入验证通常是在获取数据时开始执行的，而此时并不知道目的地所在。这也意味着我们并不知道在目标直译程序中哪些字符是重要的。其次，可能更加重要的是，应用程序必须允许潜在危害的字符进入，例如，是不是仅仅因为SQL认为Mr. O'Malley名字包含特殊字符他就不能在数据库中注册呢? 虽然输入验证很重要，但这始终不是解决注入攻击的完整解决方案，更好将输入攻击作为纵深防御措施，而将escaping作为首要防线。 解码(又称为Output Encoding) “Escaping”解码技术主要用于确保字符作为数据处理，而不是作为与直译程序的解析器相关的字符。有很多不同类型的解码，有时候也被成为输出“解码”。有些技术定义特殊的“escape”字符，而其他技术则包含涉及若干字符的更复杂的语法。 不要将输出解码与Unicode字符编码的概念弄混淆了，后者涉及映射Unicode字符到位序列。这种级别的编码通常是自动解码，并不能缓解攻击。但是，如果没有正确理解服务器和浏览器间的目标字符集，有可能导致与非目标字符产生通信，从而招致跨站XSS脚本攻击。这也正是为所有通信指定Unicode字符编码(字符集)(如UTF-8等)的重要所在。 Escaping是重要的工具，能够确保不可信数据不能被用来传递注入攻击。这样做并不会对解码数据造成影响，仍将正确呈现在浏览器中，解码只能阻止运行中发生的攻击。 注入攻击理论 注入攻击是这样一种攻击方式，它主要涉及破坏数据结构并通过使用特殊字符(直译程序正在使用的重要数据)转换为代码结构。XSS是一种注入攻击形式，浏览器作为直译程序，攻击被隐藏在HTML文件中。HTML一直都是代码和数据最差的mashup，因为HTML有很多可能的地方放置代码以及很多不同的有效编码。HTML是很复杂的，因为它不仅是层次结构的，而且还包含很多不同的解析器(XML、HTML、JavaScript、VBScript、CSS、URL等)。 要想真正明白注入攻击与XSS的关系，必须认真考虑HTML DOM的层次结构中的注入攻击。在HTML文件的某个位置(即开发者允许不可信数据列入DOM的位置)插入数据，主要有两种注入代码的方式： Injecting UP，上行注入 最常见的方式是关闭现有的context并开始一个新的代码context，例如，当你关闭HTML属性时使用"并开始新的 可以终止脚本块，即使该脚本块被注入脚本内 *** 调用内的引用字符，这是因为HTML解析器在JavaScript解析器之前运行。 Injecting DOWN，下行注入 另一种不太常见的执行XSS注入的方式就是，在不关闭当前context的情况下，引入一个subcontext。例如，将改为 ，并不需要躲开HTML属性context，相反只需要引入允许在src属性内写脚本的context即可。另一个例子就是CSS属性中的expression()功能，虽然你可能无法躲开引用CSS属性来进行上行注入，你可以采用x ss:expression(document.write(document.cookie))且无需离开现有context。 同样也有可能直接在现有context内进行注入，例如，可以采用不可信的输入并把它直接放入JavaScript context。这种方式比你想象的更加常用，但是根本不可能利用escaping(或者任何其他方式)保障安全。从本质上讲，如果这样做，你的应用程序只会成为攻击者将恶意代码植入浏览器的渠道。 本文介绍的规则旨在防止上行和下行XSS注入攻击。防止上行注入攻击，你必须避免那些允许你关闭现有context开始新context的字符;而防止攻击跳跃DOM层次级别，你必须避免所有可能关闭context的字符;下行注入攻击，你必须避免任何可以用来在现有context内引入新的sub-context的字符。 积极XSS防御模式 本文把HTML页面当作一个模板，模板上有很多插槽，开发者允许在这些插槽处放置不可信数据。在其他地方放置不可信数据是不允许的，这是“白名单”模式，否认所有不允许的事情。 根据浏览器解析HTML的方式的不同，每种不同类型的插槽都有不同的安全规则。当你在这些插槽处放置不可信数据时，必须采取某些措施以确保数据不会“逃离”相应插槽并闯入允许代码执行的context。从某种意义上说，这种 *** 将HTML文档当作参数化的数据库查询，数据被保存在具体文职并与escaping代码context相分离。 本文列出了最常见的插槽位置和安全放置数据的规则，基于各种不同的要求、已知的XSS载体和对流行浏览器的大量手动测试，我们保证本文提出的规则都是安全的。 定义好插槽位置，开发者们在放置任何数据前，都应该仔细分析以确保安全性。浏览器解析是非常棘手的，因为很多看起来无关紧要的字符可能起着重要作用。 为什么不能对所有不可信数据进行HTML实体编码? 可以对放入HTML文档正文的不可行数据进行HTML实体编码，如 标签内。也可以对进入属性的不可行数据进行实体编码，尤其是当属性中使用引用符号时。但是HTML实体编码并不总是有效，例如将不可信数据放入 directlyinascript insideanHTMLcomment inanattributename ...NEVERPUTUNTRUSTEDDATAHERE...href="/test"/ inatagname 更重要的是，不要接受来自不可信任来源的JavaScript代码然后运行，例如，名为“callback”的参数就包含JavaScript代码段，没有解码能够解决。 No.2 – 在向HTML元素内容插入不可信数据前对HTML解码 这条规则适用于当你想把不可信数据直接插入HTML正文某处时，这包括内部正常标签(div、p、b、td等)。大多数网站框架都有HTML解码的 *** 且能够躲开下列字符。但是，这对于其他HTML context是远远不够的，你需要部署其他规则。 ...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE... ...ESCAPEUNTRUSTEDDATABEFOREPUTTINGHERE... 以及其他的HTML常用元素 使用HTML实体解码躲开下列字符以避免切换到任何执行内容，如脚本、样式或者事件处理程序。在这种规格中推荐使用十六进制实体，除了XML中5个重要字符(、、 、 "、 ')外，还加入了斜线符，以帮助结束HTML实体。 -- -- -- "--" '--''isnotrecommended /--/forwardslashisincludedasithelpsendanHTMLentity ESAPI参考实施 Stringsafe=ESAPI.encoder().encodeForHTML(request.getParameter("input")); No.3 – 在向HTML常见属性插入不可信数据前进行属性解码 这条规则是将不可信数据转化为典型属性值(如宽度、名称、值等)，这不能用于复杂属性(如href、src、style或者其他事件处理程序)。这是及其重要的规则，事件处理器属性(为HTML JavaScript Data Values)必须遵守该规则。 contentinsideUNquotedattribute content insidesinglequotedattribute 除了字母数字字符外，使用小于256的ASCII值HH格式(或者命名的实体)对所有数据进行解码以防止切换属性。这条规则应用广泛的原因是因为开发者常常让属性保持未引用，正确引用的属性只能使用相应的引用进行解码。未引用属性可以被很多字符破坏，包括[space] % * + , - / ; = ^ 和 |。 ESAPI参考实施 String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) ); No.4 – 在向HTML JavaScript Data Values插入不可信数据前，进行JavaScript解码 这条规则涉及在不同HTML元素上制定的JavaScript事件处理器。向这些事件处理器放置不可信数据的唯一安全位置就是“data value”。在这些小代码块放置不可信数据是相当危险的，因为很容易切换到执行环境，因此请小心使用。

xss注入漏洞产生的原因？xss注入过程步骤是什么？防范xss注入的 *** 有哪些

对于的用户输入中出现XSS漏洞的问题，主要是由于开发人员对XSS了解不足，安全的意识不够造成的。现在让我们来普及一下XSS的一些常识，以后在开发的时候，每当有用户输入的内容时，都要加倍小心。请记住两条原则：过滤输入和转义输出。

一、什么是XSS

XSS又叫CSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。

在WEB2.0时代，强调的是互动，使得用户输入信息的机会大增，在这个情况下，我们作为开发者，在开发的时候，要提高警惕。

二、XSS攻击的主要途径

XSS攻击 *** 只是利用HTML的属性，作各种的尝试，找出注入的 *** 。现在对三种主要方式进行分析。

之一种：对普通的用户输入，页面原样内容输出。

打开http://go.ent.163.com/goproducttest/test.jsp(限公司IP)，输 入：scriptalert(‘xss’)/script， *** 脚本顺利执行。当攻击者找到这种 *** 后，就可以传播这种链接格式的链接 （http://go.ent.163.com/goproducttest/test.jsp?key= *** CODE）如：http: //go.ent.163.com/goproducttest/test.jsp?key=scriptalert(‘xss’) lt;/script，并对 *** CODE做适当伪装，如：

http://go.ent.163.com/goproducttest/test.jsp?key=%3c%73%63%72%69%70 %74%3e%61%6c%65%72%74%28%27%78%73%73%27%29%3c%2f%73%63%72%69%70%74%3e,当其 它用户当点此链接的时候， *** 就运行了，造成的后果会很严重，如跳去一个有木马的页面、取得登陆用户的COOKIE等。

第二种：在代码区里有用户输入的内容

原则就是，代码区中，绝对不应含有用户输入的东西。

第三种：允许用户输入HTML标签的页面。

用户可以提交一些自定义的HTML代码，这种情况是最危险的。因为，IE浏览器默认采用的是UNICODE编码，HTML编码可以用ASCII方式来写，又可以使用”/”连接16进制字符串来写，使得过滤变得异常复杂，如下面的四个例子，都可以在IE中运行。

1，直接使用 *** 脚本。

img src=”javascript:alert(‘xss’)” /

2，对 *** 脚本进行转码。

img src=”javascript:alert(‘xss’)” /

3，利用标签的触发条件插入代码并进行转码。

img onerror=”alert(‘xss’)” /

4，使用16进制来写(可以在傲游中运行)

img STYLE=”background-image: /75/72/6c/28/6a/61/76/61/73/63/72/69/70/74/3a/61/6c/65/72/74/28/27/58/53/53/27/29/29″

以上写法等于img STYLE=”background-image: url(javascript:alert(‘XSS’))”

三、XSS攻击解决办法

请记住两条原则：过滤输入和转义输出。

具体执行的方式有以下几点：

之一、在输入方面对所有用户提交内容进行可靠的输入验证，提交内容包括URL、查询关键字、http头、post数据等

第二、在输出方面，在用户输内容中使用XMP标签。标签内的内容不会解释，直接显示。

第三、严格执行字符输入字数控制。

四、在脚本执行区中，应绝无用户输入。

Cookie如何防范XSS攻击？

XSS（跨站脚本攻击）是指攻击者在返回的HTML中嵌入javascript脚本，为了减轻这些攻击，需要在HTTP头部配上set-cookie：

httponly此属性可以防止XSS,它会禁止javascript脚本来访问cookie。

secure 属性告诉浏览器仅在请求为https的时候发送cookie。