知识散点（二）

sql注入，把用户输入的数据和代码混淆在一起了，使用户可以操控数据，并且数据可以被带到数据库里去执行，

防御方式：
使用预编译语句
使用安全的存储过程
检查数据类型
使用安全的函数

应该遵循“数据与代码分离”的原则。

CRLF注入，利用“\r\n”这两个换行符来进行操作，可以进行http头注入，防御方式，只要注意“\r\n”来作为分隔符的应用

xss，跨站脚本攻击，通过向网页注入恶意的HTML代码，让浏览器执行达到自己的目的，混淆原本的语义，产生新的语义。
可是跨站？怎么个跨站法呢？

三种类型xss
第一种，反射型xss，也就是需要用户主动点击才会生效的xss恶意url
第二种，持久性xss，同样是触发xss，第一种是镶嵌在表面，第二种已经存储到了服务器当中，只要浏览了当前恶意页面，可以在用户神不知鬼不觉的情况下触发，这个可以一直存在，不会消失。
第三种，DOM型xss，算是一种反射型xss，但是是通过改变网页中的html代码来进行xss攻击的。
这里对dom进行一个小解释，浏览器在加载网页时都会生成一个dom树，里面包含了所有的html里的标签。

cookie劫持
发送get与post请求
钓鱼
识别用户的操作系统和浏览器
识别用户的软件
获取真实ip地址

绕过方式:
字符编码
注释号的妙用

标签 windows.name的用法

httponly：防止客户端脚本读取cookie
输入检查之白名单
输出检查之字符转义和编码

正确地防御xss
处理富文本（指含有<>的合理页面）
防御DOM BASED XSS

csrf，跨站请求伪造。

在a.com中嵌入一个get请求，让b页面转账
此时b页面打开了并且登陆了，此时浏览器会自动使用session cookie去完成此项操作，那么应该如何防止这种操作呢？

攻击者模仿受害者的身份对浏览器进行操作，但浏览器不能识别出来，所以中招了。

存在两种cookie，跨站多数都是使用第一种cookie，因为一些浏览器是禁止跨域发送第三方cookie的，比如：IE。所以如果客户端是IE浏览器的话，那么此时的csrf不会发起作用，但是火狐是没有使用禁止发送第三方跨域的。

往往通过类似

虽说p3p头可以支持浏览器跨域获取资源，所以那些禁止获取第三方cookie的浏览器方案也失效了，所以我们需要寻找别的出路。

防御方法：
验证码，对所有关键操作加上验证码
referer检查，对关键请求进行前一个跳转页面的检查
token，对关键操作进行token检查，如果token和cookie中的token不一致，那么就不会执行。

csrf的关键在于攻击者可以猜测出受害者执行此次操作的所有参数，那么是不是只要不知道所有参数的话就好了，对的不知道就好了，设置了一个token，在发送表单时发送token出去，同时在刚开始就发送了token在cookie中，这里首先是cookie是攻击者不知道的，这样子才会成功，如果攻击者通过xss获取了cookie的话，那么就没什么而好说的了。