◎sql注入产生的原因？又如何防御sql注入？
SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。
也可以说成其实还是没有对输入输出进行安全过滤的问题，后台的直接将用户的输入当做了sql语句的一部分，然后就直接执行了，导致用户对sql语句可控。
常用工具为:Burp Suite、Tamper Data、HackBer、sqlmap。
sql注入的几种类型
（1）报错注入
（2）bool型注入
（3）延时注入
（4）宽字节注入
原因：
①不当的类型处理；
②不安全的数据库配置；
③不合理的查询集处理；
④不当的错误处理；
⑤转义字符处理不合适；
⑥多个提交处理不当。
危害：
•非法查询其他数据库资源，如管理员帐号。
•执行系统命令
•获取服务器root权限
防御：
1.永远不要信任客户端提交的数据，一定要对客户端提交的数据进行校验，校验可以考虑数据类型，字符长度或者正则表达式等方式。
2.对客户端提交的数据进行转义，例如将" ' "转义为" ' "。
3.采用预编译绑定变量的SQL语句而不是直接拼接SQL语句。
4.避免在生产环境中，直接输出错误信息，因为这些错误信息有可能被攻击者利用。
5.严格执行数据库账号权限管理。
6.对用户敏感信息特别是密码做严格加密处理。
◎SQL漏洞产生的原因：SQL注入漏洞的产生原因是网站程序在编写时，没有对用户输入数据的合法性进行判断，导致应用程序存在安全隐患。SQL注入漏洞攻击的就是利用现有应用程序没有对用户输入数据的合法性进行判断，将恶意的SQL命令注入到后台数据库引擎执行的黑客攻击手段。
CTF中也常有sql注入的题目，例如实验吧中简单的sql注入:
在文本框输入1，提交，链接变成id=1
在文件框输入1‘，提交，报错，判断存在注入。
初步预计后台表为flag,字段名为flag,需要构造union select flag from flag来执行。
根据第二步的报错信息看，多加个‘，后面的语句需要再构造一个条件来结束’，注入语句为：1‘ union select flag from flag where 't'='t
执行后报错：heck the manual that corresponds to your MySQL server version for the right syntax to use near 'flag flag 't'='t'' at line 1
分析：根据错误信息发现只有变量了，其他的关键字都被过滤了。
把关键字写2遍提交，发现如下报错：corresponds to your MySQL server version for the right syntax to use near 'unionselectflag fromflag where't'='t'' at line 1
分析：发现空格被过滤了
使用+号在空格之前连接：http://ctf5.shiyanbar.com/423/web/?id=1 '+unionunion +selectselect +flag+fromfrom +flag+wherewhere+'t'='t。
◎什么是CSRF？
CSRF，跨站请求伪造攻击。那么 CSRF 到底能够干嘛呢？你可以这样简单的理解：攻击者可以盗用你的登陆信息，以你的身份模拟发送各种请求。攻击者只要借助少许的社会工程学的诡计，例如通过 QQ 等聊天软件发送的链接(有些还伪装成短域名，用户无法分辨)，攻击者就能迫使 Web 应用的用户去执行攻击者预设的操作。例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个 QQ 好友发来的链接，那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。
所以遇到 CSRF 攻击时，将对终端用户的数据和操作指令构成严重的威胁。当受攻击的终端用户具有管理员帐户的时候，CSRF 攻击将危及整个 Web 应用程序。
CSRF 原理
下图大概描述了 CSRF 攻击的原理，可以理解为有一个小偷在你配钥匙的地方得到了你家的钥匙，然后拿着钥匙去你家想偷什么偷什么。
CSRF 攻击必须要有三个条件 :
1 . 用户已经登录了站点 A，并在本地记录了 cookie
2 . 用户没有登出站点 A 的情况下（也就是 cookie 生效的情况下），访问了恶意攻击者提供的引诱危险站点 B (B 站点要求访问站点A)。
3 . 站点 A 没有做任何 CSRF 防御
你也许会问：「如果我不满足以上三个条件中的任意一个，就不会受到 CSRF 的攻击」。
其实可以这么说的，但你不能保证以下情况不会发生 :
1 . 你不能保证你登录了一个网站后，不再打开一个 tab 页面并访问另外的网站，特别现在浏览器都是支持多 tab 的。
2 . 你不能保证你关闭浏览器了后，你本地的 cookie 立刻过期，你上次的会话已经结束。
3 . 上图中所谓的攻击网站 B，可能是一个存在其他漏洞的可信任的经常被人访问的网站。
预防 CSRF
目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。
1、尽量使用POST，限制GET
GET接口太容易被拿来做CSRF攻击，看第一个示例就知道，只要构造一个img标签，而img标签又是不能过滤的数据。
接口最好限制为POST使用，GET则无效，降低攻击风险。
当然POST并不是万无一失，攻击者只要构造一个form就可以，但需要在第三方页面做，这样就增加暴露的可能性。
2、浏览器Cookie策略
IE6、7、8、Safari会默认拦截第三方本地Cookie（Third-party Cookie）的发送。
但是Firefox2、3、Opera、Chrome、Android等不会拦截，所以通过浏览器Cookie策略来防御CSRF攻击不靠谱，只能说是降低了风险。
PS：Cookie分为两种
Session Cookie（在浏览器关闭后，就会失效，保存到内存里），
Third-party Cookie（即只有到了Exprie时间后才会失效的Cookie，这种Cookie会保存到本地）。
PS：另外如果网站返回HTTP头包含P3P Header，那么将允许浏览器发送第三方Cookie。
3、加验证码
验证码，强制用户必须与应用进行交互，才能完成最终请求。在通常情况下，验证码能很好遏制CSRF攻击。
但是出于用户体验考虑，网站不能给所有的操作都加上验证码。
因此验证码只能作为一种辅助手段，不能作为主要解决方案。
4、Referer Check
Referer Check在Web最常见的应用就是“防止图片盗链”。
同理，Referer Check也可以被用于检查请求是否来自合法的“源”（Referer值是否是指定页面，或者网站的域），如果都不是，那么就极可能是CSRF攻击。
但是因为服务器并不是什么时候都能取到Referer，所以也无法作为CSRF防御的主要手段。
但是用Referer Check来监控CSRF攻击的发生，倒是一种可行的方法。
5 、Anti CSRF Token
现在业界对CSRF的防御，一致的做法是使用一个Token（Anti CSRF Token）。
例子：
- 用户访问某个表单页面。
- 服务端生成一个Token，放在用户的Session中，或者浏览器的Cookie中。
- 在页面表单附带上Token参数。
- 用户提交请求后， 服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致，一致为合法请求，不是则非法请求。
这个Token的值必须是随机的，不可预测的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性，尽量把敏感操作由GET改为POST，以form或AJAX形式提交，避免Token泄露。
总的来说，csrf有一种隐藏在黑暗中的刺客的感觉，而且是借刀杀人的那种，这里借的刀就是用户的会话状态（或者说cookie?）,用一个例子，比如你请求了一个带有csrf漏洞的普通页面，可能这个页面中就有这么一段代码<img src=http://www.xxx.com?action=del&id=1>这段代码就悄悄地去请求了你的博客（www.xxx.com），并且删除了id为1的文章。
