ajax请求存在不安全的问题有哪些？如何解决这些不安全的很问题

主要有以下的三个：
a) XSS（跨站点脚本攻击）（cross-site scripting）

-> 伪造会话（基于XSS实现CSRF） -> 劫持cookie

-> 恶意代码执行

b) CSRF（跨站请求伪造）（cross-site request forgery）

-> 伪造用户身份操作

c) sql注入

其原理主要是：通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令的目的

d）界面操作劫持

防范sql注入的措施

1）永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双"-"进行转换等

2）永远不要使用动态拼装SQL，可以使用参数化的SQL进行数据查询存取

3）永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限的数据库连接

4）不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。

浏览器的Cookie策略：

Cookie 是服务器发送到用户浏览器，并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时，被携带在请求头中并发送到服务器

跨站请求伪造(CSRF)的定义

跨站请求伪造（请求是来源于其他网站的—跨站请求，这个请求并不是来自于用户的意愿----伪造的请求），简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的

定义：
是一种劫持受信任用户，向服务器发送非预期请求的攻击方式。

通常情况下，CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任，可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作

跨站请求伪造(CSRF)和跨站脚本攻击（XSS）的区别

XSS是获取信息，不需要提前知道其他用户页面的代码和数据包。CSRF是代替用户完成指定的动作，需要知道其他用户页面的代码和数据包.

跨站请求伪造(CSRF)的特点

a) 采用cookie来进行用户校验

b) 登录受信任网站A，并在本地生成Cookie

c) 在不登出A的情况下，访问危险网站B

CSRF的类型

1）请求类型区分：get和post型CSRF攻击

2）按照攻击方式分类：HTML CSRF攻击；JSON HiJacking攻击；Flash CSRF攻击等

HTML CSRF攻击：发起的CSRF请求都属于HTML元素，比如

GET型的CSRF:
通过html标签
<link href=''>
<a href=''>
<img src=''>
<script src=''></script>
<audio src=''>
<video src=''>
 
css样式中的：
@import 'url'
background:url('url')
 
通过js动态生成的标签对象或者css独享发起GET请求
 
POST型的CSRF:只能通过form提交

JSON HiJacking攻击：攻击过程是CSRF，但是是对AJAX中的响应JSON数据类型进行劫持：

数据类型有：字典格式，列表格式

// 字典格式
{
	'id':1,
	'name':'jiang'
}
 
// 列表格式
['foo','to']

危害：

1）篡改目标网站上的用户数据

2）盗取用户隐私数据

3）传播CSRF蠕虫

4）作为其他攻击向量的辅助攻击手法

几种常见的CSRF防御手段

a) 验证HTTP Referer字段

原理：就是对比HTTP请求发送的网站的referer字段是否和当前网站是否是同一个网站

referer：指示一个请求是从哪里连接过来的

（非常简单，但是鉴于客户端并不可信任，所以并不是很安全）(防止CSRF，检查Referer字段简单直接，但是其完全依赖浏览器发送正确的Referer字段。虽然http协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其Referer字段的可能。）

b) 在请求地址中添加token并验证（譬如post中，以参数的形式加入一个随机产生的token）

token的作用：具有不重复性 + 含有特定的功能信息，比如过期时间戳

组成：a).msg b). separator c).signature

msg部分：随机字符的主体 + 过期时间戳

分隔符号：用符号分隔msg部分，和加密后生成的signature签名部分

签名signature：用密钥对msg进行加密之后的内容

token的格式：例如–token = base64(msg)…base64(sha256(“秘锁”, msg))

token的加密：

首先：用加密方法对msg数据进行加密----sha256散列算法，得到签名signature；

然后：对msg signature进行BASE64的格式转换。

需要在token串中隐含过期时间的设定。每条与服务器交互的token是有过期时间的，超过这个时间范围，就无效了，需要重新从服务器中重新拉取

token验证：当客户端将token,提交到服务器的时候，服务器需要判断token的有效性

首先：token解包—分为msg部分+分隔符+signature签名部分

然后：对比签名

首先，对msg部分进行base64解码, decode_base64(msg);

然后，在对解码后的msg明文，使用相同秘锁进行同样的encode_base64(sha256(msg))加密,

接着，判断加密后的数据和客户端传过来的token中的signature的部分是否一致。如果一致，说明这个token是有效的
最后： 判断过期时间。如果是有效的,取出msg.timestamp，和当前系统时间进行比较，如果过期时间小于当前时间，那这个token是过期的，需要重新取得token

XSS(跨站脚本，cross-site scripting)

攻击者往Web页面里插入恶意的html标签（在img加载失败的时候。触发onerror事件，在该事件里面写入恶意的js代码）或者javascript代码。比如：攻击者在论坛中放一个看似安全的链接，骗取用户点击后，窃取cookie中的用户私密信息；或者攻击者在论坛中加一个恶意表单，当用户提交表单的时候，却把信息传送到攻击者的服务器中，而不是用户原本以为的信任站点。

定义：

XSS指的是跨站脚本-----重点是脚本而非跨站，发生在目标网站的目标用户（场景）的浏览器层面上，当目标用户的浏览器渲染整个HTML文档的过程中出现了不被预期的脚本指令并执行时，XSS就会发生。

通俗的讲，就是想尽一切办法将脚本内容在目标网站中的目标用户的浏览器中解析执行

XSS的类型

反射型XSS(非持久性XSS)；存储型XSS（持久性）；DOM XSS

反射型XSS(非持久性XSS)：客户端发出请求时，XSS代码出现在URL中，作为输入提交到服务端，服务端解析后响应，在响应内容中出现这段XSS代码，最后浏览器解析执行

如点击恶意链接、提交表单、进入一个恶意网站时，注入脚本进入被攻击者的网站

// http://www.foo.com/reflect.php内容如下； 输入的值未经过滤,
// 直接输出到响应体中，然后浏览器解析执行
<?
	echo $_GET['x'];
?>
 
// 提交的url为 http://www.foo.com/reflect.php？x=<script>alert(1)</script>

存储型（非持久）xss：与反射型XSS的差别仅在于-----提交的xss代码会存储在服务端（数据库、内存、文件系统等），下次请求目标页面时，不用再提交XSS代码

留言板XSS----用户提交一条包含XSS代码的留言，存储到数据库，目标用户查看留言板时，留言内容从数据库查询出来并显示，浏览器发现有XSS代码，也当做正常的HTML与JS解析执行，就触发XSS攻击

DOM XSS：与反射型、存储型XSS的差别在于----DOM XSS的XSS代码不需要服务器解析响应的直接参与，仅靠浏览器端的DOM解析就可以完成

<script>
	eval(location.hash.substring(1));
</script>
 
触发XSS方式：http://www.foo.com/xssme.html#alert(1)
 
常见的输入点有：
document.url
document.location
document.referer

危害：

1）挂马

2）盗取用户Cookie

3）DoS(拒绝服务)客户端浏览器

4）钓鱼攻击，高级钓鱼技巧

5）编写针对性的XSS病毒，删除目标文章、恶意篡改数据、嫁祸

6）劫持用户Web行为，进一步渗透内网

7）爆发WEB2.0蠕虫

防御XSS的方法

a) 输入校验----长度限制、值类型是否正确、是否包含特殊字符（< >，过滤和编码）

校验是对数据无害的，满足就放行，不满足就阻止，一般不建议任何过滤，能保证数据的原生态

b) 输出编码--------根据输出的位置进行相应的编码，如HTML编码、JS编码、URL编码，原则-----该数据不要超出 自己所在的区域，也不要被当做指令执行

HTML编码：

作为body文本输出

< 转成 &lt;

> 转成 &gt;

& 转成 &amp;

" 转成 &quot;

' 转成 &#39

其他的转义

\ 转成 \\

/ 转成 \/

; 转成 ；(全角;)

js编码：encodeURIComponent()    encodeURI()       escape()

c) cookie设置Http-Only，这样用脚本就无法获取cookie了（这样只有浏览器向Web服务器发起请求的时才会带上cookie字段，避免了XSS攻击利用JavaScript的document.cookie获取cookie）;对cookie中敏感信息加密；设置secure=true;给cookie设置有效期；指定cookie domain的子域名

d) Cookie防盗，尽可能地避免在Cookie中泄露隐私，如用户名、密码等；或者，为了防止重放攻击，可以将Cookie和IP进行绑定，这样也可以阻止攻击者冒充正常用户的身份。

e) 注意，特别是后台，一定不能信任前端的输入，需要过滤与校验

f) 尽量采用POST而非GET提交表单