目标：编写SQL动态查询，防止SQL注入
通常所说的“SQL动态查询”是指将程序中的变量和基本SQL语句拼接成一个完整的查询语句。
反模式：将未经验证的输入作为代码执行
当向SQL查询的字符串中插入别的内容，而这些被插入的内容以你不希望的方式修改了查询语法时，SQL注入就成功了。
传统的SQL注入案例中，所插入的内容首先完成了一个查询，然后再执行第二个完整的查询逻辑比如：@bugId的值是
1234;Delete from Bugs，最后的SQL语句变成如下格式：
Select * from Bugs where bugId = 1234;Delete from Bugs
1、意外无处不在
由于字符串引起的语法错误，SQL语句是不会被执行的。
风险较大的是产生的SQL没有任何语法错误，并且以一种你所不希望的方式执行。
2、对Web安全的严重威胁
当攻击者能够使用SQL注入操控你的SQL查询语句时，就变成了一个巨大的威胁。
通常做法是在参数后插入额外的字符串，改变对应SQL语句的意义，例如：
Update Account
set password = SHA2('zyxzy'
where accountId = 123 or true --在传入accountId参数等于123的后面，添加了 or true
理解SQL注入的关键，也是如何防止SQL注入的关键：SQL注入是通过在SQL语句被数据库解析之前，
以修改其语法的形式工作的。只要在解析语句之前插入动态部分，就存在SQL注入的风险。
3、寻找解决方法
（1）转义：对传入的参数字符串进行转义操作，使它们不至于成为字符串的结束符。
使用2个连续的单引号或者反斜杠来转义。实现原理是在将应用程序中的数据插入到SQL语句之前
就进行转换。这种技术能减少由于动态内容中不匹配是引号做造成的SQL注入的风险，但在非字符串
内容的情况下，这种技术就会失效。
（2）查询参数：查询参数的做法是在准备查询语句的时候，在对应参数的地方使用“参数占位符”。随后，
在执行这个预先准备好的查询时提供一个参数。
该方法的确是应对SQL注入的强劲解决方案，但是这还不是一个通用的解决方案，因为查询参数总是被视为是一个字面值。
（a）多个值的列表不可以当成单一参数；
（b）表名无法作为参数；
（c）列名无法作为参数；
（d）SQL关键字无法作为参数；
（3）存储过程：存储过程是包含固定的SQL语句，这些语句在定义这个存储过程的时候被解析的。
在存储过程也可以使用SQL动态查询的，这样也存在安全隐患。
（4）数据访问框架ORM：对于所有允许你使用字符串方式传入SQL语句的框架来说，都无法抵御SQL注入的攻击。
如何识别反模式：几乎所有的数据库应用程序都动态地构建SQL语句，如果使用拼接字符串的形式或者将变量插入到字符串的
方法来构建SQL语句，这样的sql语句就会受到SQL注入攻击的威胁。
合理使用反模式：没有任何理由使用反模式
解决方案：
1、过滤输入内容，将所有不合法的字符从用户输入中剔除掉。
2、参数化动态内容：如果查询中的变化部分是一些简单的类型，应该使用查询参数将其和SQL表达式分离。
如果是在RDBMS解析完SQL语句之后才插入这个参数值，没有哪种SQL注入的功能能改变一个参数化了查询的语法结构。
即使攻击者尝试使用带有恶意的参数值，诸如123 or true ，关系型数据库管理系统也会将这个字符串当成一个完整的值插入
Update Account
set password = SHA2('zyxzy'
where accountId ='123 or true' --当做一个完整的字符串而不会造成威胁
3、给动态输入的值加引号
参数查询通常来说是最好的解决方案，但是在有些特殊的情况下，参数的占位符会导致查询优化器无法选择使用
哪个索引来进行优化查询。
4、找个可靠的人来帮你审查SQL语句
在检查代码是否包含SQL注入风险的时候，参考一下几点：
（1）找出所有使用了程序变量、字符串链接或者替换等方法组成的SQL语句。
（2）跟踪在SQL语句中使用的动态内容的来源。找出所有的外部输入，比如用户输入、文件、系统环境、网络服务、
第三方代码，甚至于从数据库中获取的字符串。
（3）假设任何外部内容都是潜在的威胁，对于不受信任的内容都要进行过滤、验证或者使用数组映射的方式来处理。
（4）在将外部数据合并到SQL语句时，使用查询参数，或者用稳健的转义函数预先处理。
（5）在存储过程的代码以及任何其他使用SQL动态查询语句的地方都做同样的检查。
结论：让用户输入内容，但永远别让用户输入代码
SQL反模式，系列学习汇总