如何正确防御xss攻击
XSS攻击通常是指黑客通过"HTML注入"篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。
一、HttpOnly防止劫取Cookie
HttpOnly最早由微软提出，至今已经成为一个标准。浏览器将禁止页面的Javascript访问带有HttpOnly属性的Cookie。目前主流浏览器都支持，HttpOnly解决是XSS后的Cookie支持攻击。
我们来看下百度有没有使用。
未登录时的Cookie信息
可以看到，所有Cookie都没有设置HttpOnly，现在我登录下
发现在个叫BDUSS的Cookie设置了HttpOnly。可以猜测此Cookie用于认证。
下面我用PHP来实现下：
?php
header("Set-Cookie: cookie1=test1;");
header("Set-Cookie: cookie2=test2;httponly",false);
setcookie('cookie3','test3',NULL,NULL,NULL,NULL,false);
setcookie('cookie4','test4',NULL,NULL,NULL,NULL,true);
?
script
alert(document.cookie);
/script
js只能读到没有HttpOnly标识的Cookie
二、输入检查
输入检查一般是检查用户输入的数据中是否包含一些特殊字符，如、、'、"等，如果发现存在特殊字符，则将这些字符过滤或者编码。
例如网站注册经常用户名只允许字母和数字的组合，或者邮箱电话，我们会在前端用js进行检查，但在服务器端代码必须再次检查一次，因为客户端的检查很容易绕过。
网上有许多开源的“XSS Filter”的实现，但是它们应该选择性的使用，因为它们对特殊字符的过滤可能并非数据的本意。比如一款php的lib_filter类：
$filter = new lib_filter();
echo $filter-go('1+11');
它输出的是1，这大大歪曲了数据的语义，因此什么情况应该对哪些字符进行过滤应该适情况而定。
三、输出检查
大多人都知道输入需要做检查，但却忽略了输出检查。
1、在HTML标签中输出
如代码：
?php
$a = "scriptalert(1);/script";
$b = "img src=# onerror=alert(2) /";
?
div?=$b?/div
a href="#"?=$a?/a
这样客户端受到xss攻击，解决方法就是对变量使用htmlEncode,php中的函数是htmlentities
?php
$a = "scriptalert(1);/script";
$b = "img src=# onerror=alert(2) /";
?
div?=htmlentities($b)?/div
a href="#"?=htmlentities($a)?/a
2、在HTML属性中输出
div id="div" name ="$var"/div
这种情况防御也是使用htmlEncode
在owasp-php中实现：
$immune_htmlattr = array(',', '.', '-', '_');
$this-htmlEntityCodec-encode($this-immune_htmlattr, "\"script123123;/script\"");
3、在script标签中输出
如代码：
?php
$c = "1;alert(3)";
?
script type="text/javascript"
var c = ?=$c?;
/script
这样xss又生效了。首先js变量输出一定要在引号内，但是如果我$c = "\"abc;alert(123);//"，你会发现放引号中都没用，自带的函数都不能很好的满足。这时只能使用一个更加严格的JavascriptEncode函数来保证安全——除数字、字母外的所有字符，都使用十六进制"\xHH"的方式进行编码。这里我采用开源的owasp-php方法来实现
$immune = array("");
echo $this-javascriptCodec-encode($immune, "\"abc;alert(123);//");
最后输出\x22abc\x3Balert\x28123\x29\x3B\x2F\x2F
4、在事件中输出
a href="#" onclick="funcA('$var')" test/a
可能攻击方法
a href="#" onclick="funcA('');alter(/xss/;//')"test/a
这个其实就是写在script中，所以跟3防御相同
5、在css中输出
在owasp-php中实现：
$immune = array("");
$this-cssCodec-encode($immune, 'background:expression(window.x?0:(alert(/XSS/),window.x=1));');
6、在地址中输出
先确保变量是否是"http"开头，然后再使用js的encodeURI或encodeURIComponent方法。
在owasp-php中实现：
$instance = ESAPI::getEncoder();
$instance-encodeForURL(‘url’);
四、处理富文体
就像我写这篇博客，我几乎可以随意输入任意字符，插入图片，插入代码，还可以设置样式。这个时要做的就是设置好白名单，严格控制标签。能自定义 css件麻烦事，因此最好使用成熟的开源框架来检查。php可以使用htmlpurify
五、防御DOM Based XSS
DOM Based XSS是从javascript中输出数据到HTML页面里。
script
var x = "$var";
document.write("a href='"+x+"'test/a");
/script
按照三中输出检查用到的防御方法，在x赋值时进行编码，但是当document.write输出数据到HTML时，浏览器重新渲染了页面，会将x进行解码，因此这么一来，相当于没有编码，而产生xss。
防御方法：首先，还是应该做输出防御编码的，但后面如果是输出到事件或脚本，则要再做一次javascriptEncode编码，如果是输出到HTML内容或属性，则要做一次HTMLEncode。
会触发DOM Based XSS的地方有很多：
document.write()、document.writeln()、xxx.innerHTML=、xxx.outerHTML=、innerHTML.replace、document.attachEvent()、window.attachEvent()、document.location.replace()、document.location.assign()
ASP网站的XSS跨站漏洞出现原因及解决办法？
Xss漏洞主要利用的是把输出的内容信息转化成脚本信息，这就需要把输出信息做过滤，这方面的过滤API可以考虑OWASP的ESAPI。这个API有面向ASP的版本，去OWASP官网去找吧。
恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。
ASP
漏洞代码示例：
%
Dim param
Set param=Request.QueryString(“dd”)
response.write param
%
修复范例：
%
Dim param
Set param=Request.QueryString(“dd”)
response.write Server.HTMLEnCode(param)
%
PHP
漏洞代码示例：
?php
$aa=$_GET['dd'];
echo $aa.”123″;
?
修复范例：
?php
$aa=$_GET['dd'];
echo htmlspecialchars($aa).”123″;
?
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注入漏洞产生的原因？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， JS脚本顺利执行。当攻击者找到这种方法后，就可以传播这种链接格式的链接 （http://go.ent.163.com/goproducttest/test.jsp?key=JSCODE）如：http: //go.ent.163.com/goproducttest/test.jsp?key=scriptalert(‘xss’) lt;/script，并对JSCODE做适当伪装，如：
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,当其 它用户当点此链接的时候，JS就运行了，造成的后果会很严重，如跳去一个有木马的页面、取得登陆用户的COOKIE等。
第二种：在代码区里有用户输入的内容
原则就是，代码区中，绝对不应含有用户输入的东西。
第三种：允许用户输入HTML标签的页面。
用户可以提交一些自定义的HTML代码，这种情况是最危险的。因为，IE浏览器默认采用的是UNICODE编码，HTML编码可以用ASCII方式来写，又可以使用”/”连接16进制字符串来写，使得过滤变得异常复杂，如下面的四个例子，都可以在IE中运行。
1，直接使用JS脚本。
img src=”javascript:alert(‘xss’)” /
2，对JS脚本进行转码。
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标签。标签内的内容不会解释，直接显示。
第三、严格执行字符输入字数控制。
四、在脚本执行区中，应绝无用户输入。
xss漏洞类型有哪些？
大家好，大家经常听到XSS攻击这个词，那么XSS攻击到底是什么，以及如何防御XSS攻击大家清楚么？今天，天下数据就给大家讲一下：XSS攻击的定义、类型以及防御方法。
什么是XSS攻击？
XSS攻击全称跨站脚本攻击，是一种在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。
XSS攻击有哪几种类型？
常见的 XSS 攻击有三种：反射型XSS攻击、DOM-based 型XXS攻击以及存储型XSS攻击。
1.反射型XSS攻击
反射型 XSS 一般是攻击者通过特定手法（如电子邮件），诱使用户去访问一个包含恶意代码的 URL，当受害者点击这些专门设计的链接的时候，恶意代码会直接在受害者主机上的浏览器执行。反射型XSS通常出现在网站的搜索栏、用户登录口等地方，常用来窃取客户端 Cookies 或进行钓鱼欺骗。
2.存储型XSS攻击
也叫持久型XSS，主要将XSS代码提交存储在服务器端（数据库，内存，文件系统等），下次请求目标页面时不用再提交XSS代码。当目标用户访问该页面获取数据时，XSS代码会从服务器解析之后加载出来，返回到浏览器做正常的HTML和JS解析执行，XSS攻击就发生了。存储型 XSS 一般出现在网站留言、评论、博客日志等交互处，恶意脚本存储到客户端或者服务端的数据库中。
3.DOM-based 型XSS攻击
基于 DOM 的 XSS 攻击是指通过恶意脚本修改页面的 DOM 结构，是纯粹发生在客户端的攻击。DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞。
如何防御XSS攻击？
1. 对输入内容的特定字符进行编码，例如表示 html标记的 等符号。
2. 对重要的 cookie设置 httpOnly, 防止客户端通过document.cookie读取 cookie，此 HTTP头由服务端设置。
3. 将不可信的值输出 URL参数之前，进行 URLEncode操作，而对于从 URL参数中获取值一定要进行格式检测（比如你需要的时URL，就判读是否满足URL格式）。
4. 不要使用 Eval来解析并运行不确定的数据或代码，对于 JSON解析请使用 JSON.parse() 方法。
5. 后端接口也应该要做到关键字符过滤的问题。
以上，是天下数据给大家分享的关于XSS攻击的全部内容，大家记得收藏方便以后查看哦。
如今，各种类型网络攻击日益频繁，除了XSS攻击之外，比较常见的网络攻击类型还包括DDoS攻击、CC攻击等，它们非常难以防御，除了需要做好日常网络安全防护之外，还需要接入高防服务，可以接入天下数据高防cdn，通过天下数据高防cdn隐藏源IP，对攻击流量进行清洗，保障企业网络及业务的正常运行。
html5 localstorage 怎么取存储条数
在HTML5本地存储出现以前，WEB数据存储的方法已经有很多，比如HTTP Cookie，IE userData，Flash Cookie，Google Gears。其实再说细点，浏览WEB的历史记录也算是本地存储的一种方式。到目前为止，HTML5本地存储方式已经获得了广泛的支持，其中支持的浏览器包括：IE 8+、FF 3.5+、Safari 4+、Chrome 4+、Opera 10.5+，手机平台包括iPhone 2+和Android 2+。最新的HTML5本地存储规范文档，可以在线查看
http://dev.w3.org/html5/webstorage/
HTML5本地存储的前身就是Cookie，通过使用localStorage对象将WEB数据持久留存在本地。相比较而言，HTML5本地存储中每个域的存储大小默认是5M，比起Cookie的4K要大的多。而且存储和读取数据的代码极为简练：
那么现在我们是否可以简单的认为，HTML5存储已经可以代替Cookie存储了呢？还有这种新的存储方式在实际应用中带来了哪些新的安全风险呢？带着这些疑问我们来进行下面的讨论。
（1） 是否可以代替Cookie
浏览器使用Cookie进行身份验证已经好多年，既然现在localStorage存储空间那么大，是否可以把身份验证的数据直接移植过来呢？目前来看，把身份验证数据使用localStorage进行存储还不太成熟。我们知道，通常可以使用XSS漏洞来获取到Cookie，然后用这个Cookie进行身份验证登录。后来为了防止通过XSS获取Cookie数据，浏览器支持了使用HTTPONLY来保护Cookie不被XSS攻击获取到。而目前localStorage存储没有对XSS攻击有任何抵御机制，一旦出现XSS漏洞，那么存储在localStorage里的数据就极易被获取到。
如果一个网站存在XSS漏洞，那么攻击者注入如下代码，就可以获取使用localStorage存储在本地的所有信息。
攻击者也可以简单的使用localStorage.removeItem(key)和localStorage.clear()对存储数据进行清空。
（2） 不要存储敏感信息
从（1）中知道，从远程攻击角度来看，localStorage存储的数据容易被XSS攻击获取，所以不宜把身份验证信息或敏感信息用localStorage存储。而从本地攻击角度来看， localStorage自身的存储方式和存储时效并不宜存储敏感信息。
五大浏览器现在都已经支持以localStorage方式进行存储，其中Chrome,Opera,Safari这三款浏览器中都有了查看本地存储的功能模块。但是不同浏览器对localStorage存储方式还是略有不同的。以下是五大浏览器localStorage存储方式：
通过上面的描述可以看出，除了Opera浏览器采用BASE64加密外（BASE64也是可以轻松解密的），其他浏览器均采用明文存储数据。
另一方面，在数据存储的时效上，localStorage并不会像Cookie那样可以设置数据存活的时限，只要用户不主动删除，localStorage存储的数据将会永久存在。
根据以上对存储方式和存储时效的分析，建议不要使用localStorage方式存储敏感信息，那怕这些信息进行过加密。
（3） 严格过滤输入输出
对于本地存储，为了方便加载数据，常常会把数据存储在本地，等再次加载时，直接从本地读取数据显示在网页上。在某些情况下，在localStorage存储中写入或读取数据的时候，如果数据没有经过输入输出严格过滤，那么这些数据极可能被作为HTML代码进行解析，从而产生XSS攻击。
Twitter就发生过localStorage XSS漏洞。此漏洞触发的条件是，在Twitter的个人主页上执行以下存储代码后，每次再打开个人主页时就会弹出/xss/框。
从这段代码可以看出，Twitter会使用localStorage方法把一些个人数据存储到本地，每次加载个人主页面的时候就会从本地存储获取数据，然后由于Twitter忽略了对去除数据的严格过滤，导致存储的代码会被当作HMTL编码执行，进而发生跨站攻击。
有关Twitter localStorage XSS 漏洞详的细信息可以查看：http://www.wooyun.org/bugs/ wooyun-2010-03075。虽然Twitter这个漏洞利用起来非常困难，但它再一次告诉我们：本着一切输入输出都是有害的原则，要对数据进行严格的输入输出过滤。
（4） 容易遭受跨目录攻击
localStroage存储方式不会像Cookie存储一样可以指定域中的路径，在localStroage存储方式中没有域路径的概念。也就是说，如果同一个域下的任意路径存在XSS漏洞，整个域下存储的数据在知道存储名称的情况下都可以被获取到。
假设下面两个链接是使用localStorage来存储数据：
用户xisigr和xhack各自的blog链接虽然属于同一个域，但却有不同的路径，一个路径为xisigr，另一个路径为xhack。假设xisigr用户发现自己的路径下存在存储型XSS漏洞，那么就可以在自己的blog中加入获取数据代码，其中核心代码为localStorage.getItem(“name”)。xhack用户并不需要登录blog,他只要访问http://h.example.com/xisigr，本地存储数据就会被获取到。
（5） 容易遭受DNS欺骗攻击
Google在没有使用HTML5本地存储前，是使用Google Gears方式来进行本地存储的。那时Google Gears就遭到过DNS欺骗攻击。Google Gears支持离线存储，可以把Gmail,WordPresss这样的网站数据以SQLite数据库的形式存储下来，以后用户就可以对存储的网站数据进行离线读取或删除操作。如果攻击者发动DNS欺骗攻击，那么就可以注入本地数据库，获取数据或者留下永久的后门，造成对用户持久的危害。Google Gears所遭受的DNS欺骗攻击方式在HTML5本地存储上也是同样有效的。
（6） 恶意代码栖息的温床
在第六点中给出“恶意代码栖息的温床”这个小标题有些夸大的效果。其实这里想说的是，HTML5本地存储在空间上和时间上都将成为今后存储的趋势，料想“恶意代码们”自然会大雁南飞转移栖息到这张温床上。
那么，何为HTML5本地存储的空间和时间呢？空间这里指的是存储空间，比起Cookie 4K空间的微小来说，HTML5的localStroage方法默认就可以使浏览器存储5M空间可以说是博大，而Safari浏览器可以支持到500M更加让HTML5存储霸气外露。时间上，随着HTML5技术日渐成熟，除了各大浏览器厂商争先在自己的产品中支持HTML5外，一些大应用软件厂商也对其信赖有加。比如2011年11月Adobe宣布放弃手机上的FLASH， 而由HTML5全面取而代之。随着时间的推移，HTML5大步流星的前行速度也会越来越快，也会使得用到HTML5本地存储的应用会越来越多。
上面从理论上分析了 “恶意代码栖息的温床”的可能性。而从实际技术上的可行性也非常简单。下面是在本地留后门的核心代码：
以上分析，均出自天融信TopLAB前沿安全实验室的研究，希望借此文让HTML5的本地存储安全问题得到大家的广泛重视。HTML5非常精彩，但也存在风险，我们要做的工作还很多。
XSS攻击的定义，类型以及防御方法？
XXS攻击全称跨站脚本攻击，是一种在Web应用中的计算机安全漏洞，它允许恶意Web用户将代码植入到提供给其他使用的页面中。
XSS攻击有哪几种类型?下面就由锐速云的小编为大家介绍一下
经常见到XSS攻击有三种：反射XSS攻击、DOM-based型XSS攻击以及储存型XSS攻击。
[if !supportLists]1、[endif]反射型XSS攻击
反射性XSS一般是攻击者通过特定手法(如电子邮件)，诱使用户去访问一个包含恶意代码的URL，当受害者点击这些专门设计链接的时候，恶意代码会直接在受害主机上的浏览器上执行，反射型XSS通常出现在网站搜索栏，用户登入口等地方，常用来窃取客户端或进行钓鱼欺骗。
[if !supportLists]2、[endif]存储型XSS攻击
存储型XSS攻击也叫持久型XSS，主要将XSS代码提交储存在服务器端(数据库，内存，文件系统等)下次请求目标页面时不用在提交XSS代码。当目标用户访问该页面获取数据时，XSS代码会从服务器解析之后加载出来，返回到浏览器做正常的HTML和JS解析执行，XSS攻击就发生了。储存型XSS一般出现在网站留言，评论，博客日志等交互处，恶意脚本储存到客户端或者服务端的数据库中。
[if !supportLists]3、[endif]DOM-based型XSS攻击
DOM-based型XSS攻击它是基于DOM的XSS攻击是指通过恶意脚本修改页面的DOM结构，是纯粹发生在客户端的攻击。DOM型XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端JavaScript自身的安全漏洞。
如何防御XSS攻击?
[if !supportLists]1、[endif]对输入内容的特定字符进行编码，列如表示html标记等符号。
[if !supportLists]2、[endif]对重要的cookie设置httpOnly，防止客户端通过document。cookie读取cookie，此HTTP开头由服务端设置。
[if !supportLists]3、[endif]将不可信的输出URT参数之前，进行URLEncode操作，而对于从URL参数中获取值一定要进行格式检查
[if !supportLists]4、[endif]不要使用Eval来解析并运行不确定的数据或代码，对于JSON解析请使用JSON。Parse()方法
[if !supportLists]5、[endif]后端接口也应该要做到关键字符过滤的问题。