本文目录一览：
- 1、二维码病毒为什么扫一扫就会中毒？
- 2、XSS攻击如何实现以及保护Web站点免受跨站点脚本攻击
- 3、XSS攻击原理是什么？
- 4、如何正确防御xss攻击?
- 5、二维码存在哪些应用风险，该如何防范
- 6、什么是xss攻击，如何预防
二维码病毒为什么扫一扫就会中毒？
首先通俗的解释一下“中毒”的概念。中毒和生病一样。
一，现在二维码里大致有这样一些类型的数据：长文本、短文本、名片、网址、wifi配置信息、地理位置信息。
第二，中毒和生病一样，病毒需要一个生存和发展的环境，如果扫码能中毒，那么环境是谁?当然是扫码软件以及扫码软件的运行环境(通常就是手机操作系统)了。
现在已知的二维码“病毒”大致有以下3种方式：
钓鱼网址，这个严格来说不是“病毒”，属于社会工程学威胁范畴，用户只需稍有安全意识则能有效避免被骗上当。在手机上，打开一个网址本身在大多数情况下是安全的，但危险在于停留在这个打开的网站上，用户干了些什么。用户自己主动输入信用卡号、安全码，用户自己主动输入支付宝用户帐号。。。另外，网址并不等于网站入口。比如，有一类特殊的网址，叫做伪协议地址，这个也有想象力空间(但似乎没见到攻击案例)，例如sms://、tel://等等，这些点击之后，在不同的系统上有可能会打开不同的应用程序，例如发短信、打电话等等。
HTML/JS混合代码，这是由于很多二维码软件提供了所谓的智能内容感知和识别，调用了浏览器解释引擎去承载和处理这些代码，实质上就是给“病毒”提供了“温床”，所以会“中毒”。但，就目前已知的攻击案例来说，纯第三方二维码类应用软件即使被这些浏览器客户端恶意代码攻击，在绝大多数情况下对用户造成的影响也很有限。极少数情况，可能会发生在：
恶意代码直接攻击浏览器解释引擎，造成内存破坏类攻击，直接获得原生应用程序级别的任意代码执行甚至是提升权限。这种问题发生的概率要远远小于PC端浏览器遭受同类型攻击的概率。主要原因是：大多数攻击程序是需要一定“行数”的代码组成的，而二维码的承载数据能力又是受限制于图片编码的容量极限的。简单理解就是：复杂攻击需要更多行数的代码，较少行数的代码只能实现较简单的“攻击”，二维码由于自身设计的“缺陷”，无法提供恶意代码存储所必要的足够空间，故攻击想象空间和影响效果有限。
自定义的二维码应用。虽然二维码本身承载的其实就只是普通文本数据(数字、字符啥的)，但有些软件给这些数据定义了一些自己的解析规则，目的是实现扫码后自动XXX或自动YYY。坏就坏在这个自动化的过程，给了数据一秒变病毒的机会。如何理解?参考Web安全里的SQL注入、XSS等，就是最典型的数据一秒变病毒的参考案例。
XSS攻击如何实现以及保护Web站点免受跨站点脚本攻击
使用工具和测试防范跨站点脚本攻击. 跨站点脚本（XSS）攻击是当今主要的攻击途径之一，利用了Web站点的漏洞并使用浏览器来窃取cookie或进行金融交易。跨站点脚本漏洞比较常见，并且要求组织部署涵盖威胁建模、扫描工具和大量安全意识在内的周密的安全开发生命周期，以便达到最佳的XSS防护和预防。本文解释了跨站点脚本攻击是如何实现并且就如何保护企业Web应用免于这种攻击提供了建议。 跨站点脚本（XSS）允许攻击者通过利用因特网服务器的漏洞来发送恶意代码到其他用户。攻击者利用跨站点脚本（XSS）攻击向那些看似可信任的链接中注入恶意代码。当用户点击了链接后，内嵌的程序将被提交并且会在用户的电脑上执行，这会使黑客获取访问权限并偷走敏感数据。攻击者使用XSS来攻击受害者机器上的漏洞并且传输恶意代码而不是攻击系统本身。 通过用户输入的数据返回错误消息的Web表格，攻击者可以修改控制Web页面的HTML代码。黑客能够在垃圾信息中的链接里插入代码或者使用欺诈邮件来诱使用户对其身份产生信任。 例如攻击者可以发送带有URL的邮件给受害人，这个URL指向一个Web站点并且提供浏览器脚本作为输入；或者在博客或诸如Facebook、Twitter这样的社交网站上发布恶意URL链接。当用户点击这个链接时，该恶意站点以及脚本将会在其浏览器上运行。浏览器不知道脚本是恶意的并将盲目地运行这个程序，这转而允许攻击者的浏览器脚本使用站点的功能来窃取cookie或者冒充合法的用户来完成交易。 一些通常的跨站点脚本预防的最佳实践包括在部署前测试应用代码，并且以快速、简明的方式修补缺陷和漏洞。Web应用开发人员应该过滤用户的输入来移除可能的恶意字符和浏览器脚本，并且植入用户输入过滤代码来移除恶意字符。通常管理员也可以配置浏览器只接受来自信任站点的脚本或者关闭浏览器的脚本功能，尽管这样做可能导致使用Web站点的功能受限。 随着时代的进步黑客们变得更加先进，使用收集的工具集来加快漏洞攻击进程。这意味着仅仅部署这些通常的XSS预防实践是不够的，保护和预防过程必须从底层开始并持续提升。预防过程必须在开发阶段开始，建立在一个牢靠、安全的开发生命周期方法论之上的Web应用在发布版本中不太可能暴露出漏洞。这样以来，不仅提升了安全性，也改善了可用性而且缩减了维护的总体费用，因为在现场环境中修补问题比在开发阶段会花费更多。 威胁建模在XSS预防中也是重要的一个方面，应该纳入到每个组织的安全开发生命周期当中。威胁建模评估和辨识在开发阶段中应用程序面临的所有的风险，来帮助Web开发人员更好地理解需要什么样的保护以及攻击一旦得逞将对组织产生怎样的影响。要辨识一个特定应用的威胁级别，考虑它的资产以及它访问的敏感信息量是十分重要的。这个威胁建模过程将确保在应用的设计和开发过程中战略性地融合了安全因素，并且增强了Web开发人员的安全意识。 对于大型项目的Web开发人员来说，源代码扫描工具和Web应用漏洞扫描器是提高效率和减少工作量的通常选择。
XSS攻击原理是什么？
什么是XSS攻击XSS又叫CSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常忽略其危害性。而本文主要讲的是利用XSS得到目标服务器的shell。技术虽然是老技术，但是其思路希望对大家有帮助。 [编辑本段]如何寻找XSS漏洞就个人而言，我把XSS攻击分成两类，一类是来自内部的攻击，主要指的是利用程序自身的漏洞，构造跨站语句，如:dvbbs的showerror.asp存在的跨站漏洞。另一类则是来来自外部的攻击，主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点，我们自己构造一个有跨站漏洞的网页，然后构造跨站语句，通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开。
如何正确防御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信息数据库。
二维码存在哪些应用风险，该如何防范
第一个问题，现在二维码里大致有这样一些类型的数据：长文本、短文本、名片、网址、wifi配置信息、地理位置信息。
第二个问题，首先通俗的解释一下“中毒”的概念。
中毒和生病一样，病毒需要一个生存和发展的环境，如果扫码能中毒，那么环境是谁?当然是扫码软件以及扫码软件的运行环境(通常就是手机操作系统)了。现在已知的二维码“病毒”大致有以下3种方式：
钓鱼网址，这个严格来说不是“病毒”，属于社会工程学威胁范畴，用户只需稍有安全意识则能有效避免被骗上当。在手机上，打开一个网址本身在大多数情况下是安全的，但危险在于停留在这个打开的网站上，用户干了些什么。用户自己主动输入信用卡号、安全码，用户自己主动输入支付宝用户帐号。另外，网址并不等于网站入口。比如，有一类特殊的网址，叫做伪协议地址，这个也有想象力空间(但似乎没见到攻击案例)，例如sms://、tel://等等，这些点击之后，在不同的系统上有可能会打开不同的应用程序，例如发短信、打电话等等。
HTML/JS混合代码，这是由于很多二维码软件提供了所谓的智能内容感知和识别，调用了浏览器解释引擎去承载和处理这些代码，实质上就是给“病毒”提供了“温床”，所以会“中毒”。但，就目前已知的攻击案例来说，纯第三方二维码类应用软件即使被这些浏览器客户端恶意代码攻击，在绝大多数情况下对用户造成的影响也很有限。极少数情况，可能会发生在：
恶意代码直接攻击浏览器解释引擎，造成内存破坏类攻击，直接获得原生应用程序级别的任意代码执行甚至是提升权限。这种问题发生的概率要远远小于PC端浏览器遭受同类型攻击的概率。主要原因是：大多数攻击程序是需要一定“行数”的代码组成的，而二维码的承载数据能力又是受限制于图片编码的容量极限的。简单理解就是：复杂攻击需要更多行数的代码，较少行数的代码只能实现较简单的“攻击”，二维码由于自身设计的“缺陷”，无法提供恶意代码存储所必要的足够空间，故攻击想象空间和影响效果有限。
自定义的二维码应用。
虽然二维码本身承载的其实就只是普通文本数据(数字、字符啥的)，但有些软件给这些数据定义了一些自己的解析规则，目的是实现扫码后自动XXX或自动YYY。坏就坏在这个自动化的过程，给了数据一秒变病毒的机会。如何理解?参考Web安全里的SQL注入、XSS等，就是最典型的数据一秒变病毒的参考案例。
上面3类“病毒”，第一种可以归类为需要用户交互才能得逞的病毒，后两种可以归类为无需用户交互即可实现“感染”的病毒。
前者在目前来说最常见，后两者攻击易得手但造成的影响大多数情况下极为有限。
应对方式和Web时代的安全问题类似，需要几方面参与者的共同努力。
扫码软件厂商，在提供基于二维码的新应用时，要安全的设计和实现二维码识别后内容的解析引擎，对网址的识别可以集成第三方安全厂商提供的URL黑名单查询服务，对已知恶意网址提前向扫码用户告警，并取消点击交互行为的支持。另外，扫码软件可以提供一个牛逼闪闪的安全模式(其实就是纯文本模式啦)，让有安全意识和能力的用户可以先看看是什么，再决定下一步如何解析、是否允许软件自动化做XXX或自动化YYY。当然了，做产品，还可以在用户体验层面再智能一些，让用户可以更傻瓜一些点【下一步】。
用户要做到：
一要选择知名的二维码扫描软件，二要避免打开陌生和奇怪的网址。
安全厂商，还和现在一样，该干嘛干嘛，多给扫码软件厂商做做推广，集成你们的恶意网址识别引擎吧。再牛逼一点，云扫码吧，所有二维码里的数据，你们先在云端看看，不良内容给消消毒就是了。
至于二维码未来的安全问题?先让我们看到二维码在未来有什么新应用吧，如果没有新应用，那么以上内容已经涵盖了二维码病毒的成因和对策。新应用?我已经预测了以上的第三种方式了。
其实二维码在很久以前就开始研发运用了，阿里与腾讯也是进行二维码支付运营的大企业，只要大家有一定的安全防范意识，二维码还是相对安全的。
什么是xss攻击，如何预防
xss攻击是webshell类中的一种，是跨站攻击，可以通过WAF应用防火墙防御，如果懂技术可以自己写，相关的程序规则进行拦截，返回错误请求信息，或者安装安全狗 云锁之类的，和百度云加速等都带有免费的WAF功能，也可以找智多互联，专业防御各种攻击，提供专业的防御方案