常见攻击
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 可怕的是我们对自己的产品安全的松懈
织梦后台内容管理修改PHP或者模板，保存后会出现DedeCMS:CSRF Token Check Failed提示无法保存修改的文件。CSRF（Cross-site request forgery）中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。出现DedeCMS:CSRF Token Check Failed!，由于您重新打开了一个需要CSRF校验的表单页面。
织梦后台CSRF Token Check Failed解决方法
织梦后台-模块-文件管理器，打开 dede/file_manage_view.php 找到
$path_parts = pathinfo($filename)大约处于121行
在上面一行，下面加入
$GLOBALS['token'] = make_hash()
保存就不会再出现DedeCMS:CSRF Token Check Failed!提示了，觉得有用，就请采纳吧！
同源策略是web应用安全模型，是浏览器为了安全作出的限制。
浏览器只允许同一个域下的A网站的脚本访问B网站的数据，同一个域的定义：{uri scheme，host，port}。同源策略只对脚本有限制，对HTML的标签，例如img、css、以及静态加载的脚本并不会有限制，所CSRF攻击能够通过HTML tags进行。
Example:
对同源策略的理解：
为了保证不同域名下网站的隔离性，不同域名下的网站之间不能互相修改、读取信息。比如A域名下的网页去请求B网站，同源策略其实是为了保证B域名下网页的安全性，保证B网站不会被修改和读取请求信息。而脚本的执行（例如ajax请求）浏览器是认为会读取到返回信息，也就是存在信息泄露的风险（浏览器会限制能够发送请求，但是无法获取到结果）。而form表单的提交并不会受到限制的原因为：因为如果是通过A网站下form表单等请求B网站上资源，返回结果将会是一个新的页面，也就是说A网站页面并不能获取到B网站的数据，也不能修改；同源策略避免的是不同域名下，A网站去读取、修改B网站的信息，如果是一个新的网站，那原网站并不会对返回结果进行任何操作。
跨域资源共享则是一种协议，用于在服务器允许的情况下，允许被同源策略拒绝的访问行为：发送HTTP、Ajax请求，获取结果数据。其中服务器能够制定访问的请求类型、是否能够带上访问的认证信息（cookie、HTTP认证信息）等。这是由服务器端来指定权限，而浏览器来强制执行限制。
跨域需要的场景
Example：
相关请求头
CORS请求可以划分为两种：简单请求、预检请求；浏览器执行不同的操作
简单请求
处理方法：
1、浏览器发送简单请求至服务器
2、服务器返回能够允许的域，浏览器根据结果判断是否将结果返回给请求方
请求报文
预检请求
1、浏览器预先发送OPTIONS请求
2、服务器返回预检结果，浏览器判断是否能够发起真正的请求
3、如果可以，则发送真正的请求
参考：
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS
Example
攻击的防范：
1）对不安全的请求通过带上csrf token，来保证请求是由用户发出
2）通过SameSite 属性，在cookie中设置，但是老的浏览器可能不支持，因此这个推荐作为更深一层的防范。
上述概念其实可以理解为是浏览器本身能够访问多个站点，多个站点之间的隔离性和安全性问题而引入的；如果不是通过浏览器访问，那就没有这些概念和顾虑了。
