本文目录一览：
- 1、如何有效防止XSS攻击/AJAX跨域攻击
- 2、XSS是什么
- 3、请教各位大神关于从js写法上避免xss攻击的问题
- 4、css安全问题
- 5、如何正确防御xss攻击
如何有效防止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，时常关注安全方面的消息，一有漏洞即刻不上
XSS是什么
1、XSS是跨站脚本攻击(Cross Site Scripting)，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。
2、恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。
3、XSS攻击分成两类，一类是来自内部的攻击，主要指的是利用程序自身的漏洞，构造跨站语句，如:dvbbs的showerror.asp存在的跨站漏洞。
4、另一类则是来自外部的攻击，主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当要渗透一个站点，自己构造一个有跨站漏洞的网页，然后构造跨站语句，通过结合其它技术，如社会工程学等，欺骗目标服务器的管理员打开。
请教各位大神关于从js写法上避免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);//");
最后输出x22abcx3Balertx28123x29x3Bx2Fx2F
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()
css安全问题
随着前端技术的发展,安全问题已经从服务器悄然来到了每一个用户的的面前，盗取用户数据, 制造恶意的可以自我复制的蠕虫代码,让病毒在用户间传播,使服务器当掉. 更有甚者可能会在用户不知觉得情况下,让用户成为攻击者,这绝对不是骇人听闻。富客户端的应用越来越广，前端的安全问题也随之增多,今天就简单介绍下一些常见的攻击方式和预防攻击办法。
常见攻击
XSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入的恶意html代码会被执行，从而达到恶意用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。但是随着前端技术的不断进步富客户端的应用越来越多，这方面的问题越来越受关注。举个简单例子 ： 假如你现在是sns站点上一个用户，发布信息的功能存在漏洞可以执行js 你在 此刻输入一个 恶意脚本，那么当前所有看到你新信息的人的浏览器都会执行这个脚本弹出提示框 （很爽吧 弹出广告 ：）），如果你做一些更为激进行为呢 后果难以想象。
CSRF(Cross Site Request Forgery)，跨站点伪造请求。顾名思义就是 通过伪造连接请求在用户不知情的情况下，让用户以自己的身份来完成攻击者需要达到的一些目的。csrf 的攻击不同于xss csrf 需要被攻击者的主动行为触发。这样听来似乎是有“被钓鱼”的嫌疑哈哈。
多窗口浏览器这这方面似乎是有助纣为虐的嫌疑，因为打开的新窗口是具有当前所有会话的，如果是单浏览器窗口类似ie6 就不会存在这样的问题，因为每个窗口都是一个独立的进程。举个简单例子 ： 你正在玩白社会， 看到有人发了一个连接，你点击过去，然后这个连接里面伪造了一个送礼物的表单，这仅仅是一个简单的例子，问题可见一般。
cookie劫持，通过获取页面的权限，在页面中写一个简单的到恶意站点的请求，并携带用户的cookie 获取cookie后通过cookie 就可以直以被盗用户的身份登录站点。这就是cookie 劫持。举个简单例子： 某人写了一篇很有意思的日志，然后分享给大家，很多人都点击查看并且分享了该日志，一切似乎都很正常，然而写日志的人却另有用心，在日志中偷偷隐藏了一个对站外的请求,那么所有看过这片日志的人都会在不知情的情况下把自己的cookie 发送给了 某人，那么他可以通过任意一个人的cookie 来登录这个人的账户。
我们该怎么做？
大致可以分为两类 1 一般用户 2网站开发人员。
首先我们来说说做为一个一般的web产品使用者，很多时候我们是被动的，是在不知情的情况下被利用的。那么我们可以：
1 对于安全级别较高的web应用访问 需要打开一个独立浏览器窗口。
2 对于陌生人发布的链接最好也是复制然后在新开的窗口中打开，当然最好的办法就是无视 – -。
对于开发人员来说我们得从相对详细的一些角度来分析：
对于xss 攻击 特点是攻击者的代码必须能获取用户浏览器端的执行权限，那么代码是从哪里来的呢，想要杜绝此类攻击出现 其实可以在入口 和出口 进行严格的过滤，这样的双保险应当说99% 的类似问题就被我们解决掉了，另外的1% 是那些蹩脚的浏览器带来的后遗症，相信在未来这种问题会越来越少的。
这里我对xss漏洞的形式作了一些整理
恶意代码值被作为某一标签的内容显示 （如果输入的是html 则html会被解析）例如你输入用户名 更新后用户名会显示到页面中的某一个标签内 如果你输入的是
popper.w＜script src="hack.js" type="text/javajscript"＞＜/script＞
那么如果不做过滤直接显示到页面， 会引进一个第三方的js 代码并且会执行。
策略：在不需要html输入的地方对html 标签 及一些特殊字符( ” ＜ ＞ 等等 )做过滤，将其转化为不被浏览器解释执行的字符
恶意代码被作为某一标签的属性显示（通过用 “ 将属性截断来开辟新的属性 或恶意方法） 这种情况往往是是开发人员为了实现功能可能会在某些dom标签上记录一些用户输入的信息例如你输入的用户名 会在页面中的标签中以 title 的形式出现 这时候 如果 你输入的是精心设计的内容 那么 看看 这个
＜a title="popper.w" onclick="alert(1)"＞popper.w" onclick="alert(1)＜/a＞
这里我实际上输入的内容是“popper.w” onclick=”alert(1)”，当然你可以在上边写更多的内容。
策略：对属性中可能存在截断的一些字符进行过滤 属性本身存在的 单引号和双引号都需要进行转码。
恶意代码被作为html代码本身显示 (常见的html编辑器) 这种情况存在的问题最多，不再这里举例子了。
策略：最好对用户输入的html 标签及标签属性做白名单过滤，也可以对一些存在漏洞的标签和属性进行专门过滤。
恶意代码被作为一段json字符串显示 （通过 变量截断 创造新的 恶意的js 变量 甚至是可执行的代码） 这个问题的关键是用户输入的信息可能会成为页面中js 代码的一部分。
策略：对属性中可能存在截断的一些字符进行过滤 属性本身存在的 单引号和双引号都需要进行转码。
对于crsf 和cookie 劫持
特点 隐蔽性比较高 有些时候是先利用xss 漏洞 然后再做 欺骗的
策略
通过 referer、token 或者 验证码 来检测用户提交。
尽量不要在页面的链接中暴漏任何与用户唯一号（用户id）有关的信息。
对于用户修改 删除 提交的操作最好都使用post 操作 。
避免全站通用的cookie 严格的设置cookie的域。
ok 就写到这里~
上边讲的都是一些比较常见的安全问题，主要是从js hack 方面来讲的，随着前端技术的不断发展进步，更多的安全问题可能会展现在我们面，对于开发者来说大多数的问题是可以在开发阶段避免的，所以可怕的不是hack 可怕的是我们对自己的产品安全的松懈
如何正确防御xss攻击
传统防御技术
2.1.1基于特征的防御
传统XSS防御多采用特征匹配方式，在所有提交的信息中都进行匹配检查。对于这种类型的XSS攻击，采用的模式匹配方法一般会需要对“javascript”这个关键字进行检索，一旦发现提交信息中包含“javascript”，就认定为XSS攻击。
2.1.2 基于代码修改的防御
和SQL注入防御一样，XSS攻击也是利用了Web页面的编写疏忽，所以还有一种方法就是从Web应用开发的角度来避免：
1、对所有用户提交内容进行可靠的输入验证，包括对URL、查询关键字、HTTP头、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。
2、实现Session标记(session tokens)、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。
3、确认接收的的内容被妥善的规范化，仅包含最小的、安全的Tag(没有javascript)，去掉任何对远程内容的引用(尤其是样式表和javascript)，使用HTTP only的cookie。
当然，如上方法将会降低Web业务系统的可用性，用户仅能输入少量的制定字符，人与系统间的交互被降到极致，仅适用于信息发布型站点。
并且考虑到很少有Web编码人员受过正规的安全培训，很难做到完全避免页面中的XSS漏洞。
扩展资料：
XSS攻击的危害包括
1、盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
2、控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
3、盗窃企业重要的具有商业价值的资料
4、非法转账
5、强制发送电子邮件
6、网站挂马
7、控制受害者机器向其它网站发起攻击
受攻击事件
新浪微博XSS受攻击事件
2011年6月28日晚，新浪微博出现了一次比较大的XSS攻击事件。
大量用户自动发送诸如：
“郭美美事件的一些未注意到的细节”，“建党大业中穿帮地方”，“让女人心动的100句诗歌”，“这是传说中的神仙眷侣啊”等等微博和私信，并自动关注一位名为hellosamy的用户。
事件的经过线索如下：
20:14，开始有大量带V的认证用户中招转发蠕虫
20:30，某网站中的病毒页面无法访问
20:32，新浪微博中hellosamy用户无法访问
21:02，新浪漏洞修补完毕
百度贴吧xss攻击事件
2014年3月9晚，六安吧等几十个贴吧出现点击推广贴会自动转发等。并且吧友所关注的每个关注的贴吧都会转一遍，病毒循环发帖。并且导致吧务人员，和吧友被封禁。
参考资料：
XSS攻击-百度百科