Web安全XSS、CSRF和SQL注入

SQL注入

　　SQL注入是以用户的输入作为sql语句的一部分，如后端接收到用户的请求数据后，不经过数据转义，就把数据拼接到SQL中执行，容易导致SQL的语义被篡改，即受到攻击了。

　　解决办法是对接收的数据进行转义即可，如果使用框架，则基本不用考虑sql注入攻击了，框架已经实现了相关处理了，能保证安全。

XSS

　　页面被插入恶意JS，导致页面的逻辑被篡改。常见的篡改方式有：使页面自动跳转到另一个地址、修改超链接的地址、修改页面的展示内容等。

　　插入恶意的JS：服务器接收到用户的输入，将输入数据保存起来，然后供其他地方展示。如果用户输入的是一段JS脚本，则其他地方展示时，将文本渲染到html中，文本是脚本的时候，脚本会马上执行，这就实现了插入脚本的目的。

　　防范措施：对于页面要渲染的数据，都要经过JS转义后再显示出来，这样一来，即使出现恶意脚本，被转义后也不会执行了。

　　到这里可以发现，XSS和SQL注入本质都是一样，只不过前者是针对JS，而后者是针对SQL，解决办法都是在使用数据的时候，都转义即可避免。

CSRF

　　本质就是页面的src元素可以跨域，而且会带上这个域名下的cookie，从而使用了用户身份去做一些不好的事情。

　　测试如下：

　　我现在登录某网站了，登录成功了，网站给我一个cookie身份凭证，如下：

　　

　　然后再任意页面的控制台，执行如下：

　　【之所以这么做是因为懒得写页面了，以下方式虽然不常规，但足以模拟用户打开了其他页面的情况了并且发出了跨域请求】

　　

　　页面就发出了一个请求（自动包含用户的身份信息了，即之前登录的cookie）：

　　

　　以上可以看出，在用户不知情的情况下，他只是访问了一个其他页面，他的身份信息就被盗用了。所以简单cookie方式不能代表就是用户本人的操作，因为这是浏览器的特征：发出请求的同时，会自动带上对应域的cookie。

防范措施

　　1.后端判断refer头是否与当前服务器地址一致。因为客户端发来的请求，可以手动修改请求里面的refer头，所以不完全可信，这个方式不行。

2.发送请求前，将cookie手动读取出来，放在请求参数（GET）或放在数据体（POST）中，后端读取这个额外的数据来判断用户的身份。这个方式能行，是因为JS没办法操作第三方的cookie，也就是说攻击者没办法将cookie数据移动到请求参数或数据体中。

针对iframe

　　以上提到一个可行的方式是基于同源协议，即不能跨域。如使用iframe打开一个第三方的页面，是能打开，但是没办法通过对应的iframe.contentWindow对象来操作页面数据，这个window对象是能获取到，只不过这个对象没有数据，这就起到了保护作用。举个例子，跨域访问window对象，里面没有数据

而正常情况下：

　　但是对于客户端程序，如nw.js，里面就没有同源限制，也就是说如果在nw中嵌入一个iframe，则js是可以跨域访问数据的，即所有cookie都能随意被读写。所以登录客户端时（非浏览器），一定要慎重！