Sqlserver之sql注入篇

2023年6月21日发(作者：)

Sqlserver之sql注⼊篇SQL Injection关于sql注⼊的危害在这⾥就不多做介绍了，相信⼤家也知道其中的厉害关系。有⼀些sql注⼊的事件⼤家感兴趣可以看⼀下

防范sql注⼊的⽅法⽆⾮有以下⼏种：1.使⽤类型安全的SQL参数2.使⽤参数化输⼊存储过程3.使⽤参数集合与动态SQL4.输⼊滤波5.过滤LIKE条款的特殊字符...如果有遗漏的也欢迎园⼦的⼤⼤们指教。Sample:var Shipcity;ShipCity = ("ShipCity");var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";上⾯是⼀个简单的sql注⼊⽰例⽤户将被提⽰输⼊⼀个市县名称。如果⽤户输⼊ Redmond，则查询将由与下⾯内容相似的脚本组成：SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'但是，假定⽤户输⼊以下内容：Redmond'; drop table OrdersTable--此时，脚本将组成以下查询：1 SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

分号 (;) 表⽰⼀个查询的结束和另⼀个查询的开始。双连字符 (--) 指⽰当前⾏余下的部分是⼀个注释，应该忽略。如果修改后的代码语法正确，则服务器将执⾏该代码。SQL Server 处理该语句时，SQL Server 将⾸先选择 OrdersTable 中的所有记录（其中 ShipCity 为 Redmond）。然后，SQLServer 将删除 OrdersTable。只要注⼊的 SQL 代码语法正确，便⽆法采⽤编程⽅式来检测篡改。因此，必须验证所有⽤户输⼊，并仔细检查在您所⽤的服务器中执⾏构造SQL 命令的代码。本主题中的以下各部分说明了编写代码的最佳做法。下⾯就介绍⼀下常⽤的⼏种防⽌sql注⼊的⽅法：

始终通过测试类型、长度、格式和范围来验证⽤户输⼊。实现对恶意输⼊的预防时，请注意应⽤程序的体系结构和部署⽅案。请注意，设计为在安全环境中运⾏的程序可能会被复制到不安全的环境中。以下建议应被视为最佳做法：对应⽤程序接收的数据不做任何有关⼤⼩、类型或内容的假设。例如，您应该进⾏以下评估：如果⼀个⽤户在需要邮政编码的位置⽆意中或恶意地输⼊了⼀个 10 MB 的 MPEG ⽂件，应⽤程序会做出什么反应？如果在⽂本字段中嵌⼊了⼀个 DROP TABLE 语句，应⽤程序会做出什么反应？测试输⼊的⼤⼩和数据类型，强制执⾏适当的限制。这有助于防⽌有意造成的缓冲区溢出。测试字符串变量的内容，只接受所需的值。拒绝包含⼆进制数据、转义序列和注释字符的输⼊内容。这有助于防⽌脚本注⼊，防⽌某些缓冲区溢出攻击。使⽤ XML ⽂档时，根据数据的架构对输⼊的所有数据进⾏验证。绝不直接使⽤⽤户输⼊内容来⽣成 Transact-SQL 语句。使⽤存储过程来验证⽤户输⼊。在多层环境中，所有数据都应该在验证之后才允许进⼊可信区域。未通过验证过程的数据应被拒绝，并向前⼀层返回⼀个错误。实现多层验证。对⽆⽬的的恶意⽤户采取的预防措施对坚定的攻击者可能⽆效。更好的做法是在⽤户界⾯和所有跨信任边界的后续点上验证输⼊。例如，在客户端应⽤程序中验证数据可以防⽌简单的脚本注⼊。但是，如果下⼀层认为其输⼊已通过验证，则任何可以绕过客户端的恶意⽤户就可以不受限制地访问系统。绝不串联未验证的⽤户输⼊。字符串串联是脚本注⼊的主要输⼊点。在可能据以构造⽂件名的字段中，不接受下列字符串：AUX、CLOCK$、COM1 到 COM8、CON、CONFIG$、LPT1 到 LPT8、NUL 以及PRN。如果可能，拒绝包含以下字符的输⼊。

输⼊字符;'--/* ... */xp_

在 Transact-SQL 中的含义查询分隔符。字符数据字符串分隔符。注释分隔符。注释分隔符。服务器不对 /* 和 */ 之间的注释进⾏处理。⽤于⽬录扩展存储过程的名称的开头，如 xp_cmdshell。注：验证输⼊是最被常⽤和联想到的，但是个⼈感觉这种⽅式不但代码显得肥胖，⽽且效率不是很好2.使⽤类型安全的 SQL 参数SQL Server 中的 Parameters 集合提供了类型检查和长度验证。如果使⽤ Parameters 集合，则输⼊将被视为⽂字值⽽不是可执⾏代码。使⽤ Parameters 集合的另⼀个好处是可以强制执⾏类型和长度检查。范围以外的值将触发异常。以下代码段显⽰了如何使⽤ Parameters 集合：

1 SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn);2 dType = Procedure;3 SqlParameter parm = ("@au_id",4 r, 11);5 = ;在此⽰例中，@au_id 参数被视为⽂字值⽽不是可执⾏代码。将对此值进⾏类型和长度检查。如果 @au_id 值不符合指定的类型和长度约束，则将引发异常。

存储过程如果使⽤未筛选的输⼊，则可能容易受 SQL Injection 攻击。例如，以下代码容易受到攻击：

SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure '" + + "'", conn);

如果使⽤存储过程，则应使⽤参数作为存储过程的输⼊。注：在鄙⼈现在的项⽬中，这种⽅法应⽤最为⼴泛3.在动态 SQL 中使⽤参数集合如果不能使⽤存储过程，您仍可使⽤参数，如以下代码⽰例所⽰：

1 SqlDataAdapter myCommand = new SqlDataAdapter(2 "SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn);3 SQLParameter parm = ("@au_id",

4 r, 11);5 = ;注：和第⼆种雷同，这种⽅法是为了补充⽅法2存在，因为往往在很多时候业务简单不需要⽤proc的时候，可以⽤这种⽅法4.筛选输⼊筛选输⼊可以删除转义符，这也可能有助于防⽌ SQL 注⼊。但由于可引起问题的字符数量很⼤，因此这并不是⼀种可靠的防护⽅法。以下⽰例可搜索字符串分隔符。

1 private string SafeSqlLiteral(string inputSQL)2 {3 return e("'", "''");4 }

注：Filtering Input有种类似⽅法 ⼦句请注意，如果要使⽤ LIKE ⼦句，还必须对通配符字符进⾏转义：

1

2 s = e("[", "[[]");3 s = e("%", "[%]");4 s = e("_", "[_]");注：针对like⼦句，在使⽤时的效率这⾥就不多说了，总之要慎⽤了。

以上所有⽅法及其注释⾼亮显⽰部分，均为本⼈愚见，如果对⽅法有补充或者对⾼亮部分有不同意见的，欢迎⼤家给出意见，共同进步.本⽂是在借鉴的前提下加了⼀些⾃⼰的理解与意见， 转载请注⼊出处。 thx.

if您看了这篇博客。对您有所帮助，请不要吝啬您的“推荐”，您的推荐将是我最⼤的动⼒。有问题的话可以评论交流。

2023年6月21日发(作者：)

Sqlserver之sql注⼊篇SQL Injection关于sql注⼊的危害在这⾥就不多做介绍了，相信⼤家也知道其中的厉害关系。有⼀些sql注⼊的事件⼤家感兴趣可以看⼀下

防范sql注⼊的⽅法⽆⾮有以下⼏种：1.使⽤类型安全的SQL参数2.使⽤参数化输⼊存储过程3.使⽤参数集合与动态SQL4.输⼊滤波5.过滤LIKE条款的特殊字符...如果有遗漏的也欢迎园⼦的⼤⼤们指教。Sample:var Shipcity;ShipCity = ("ShipCity");var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";上⾯是⼀个简单的sql注⼊⽰例⽤户将被提⽰输⼊⼀个市县名称。如果⽤户输⼊ Redmond，则查询将由与下⾯内容相似的脚本组成：SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'但是，假定⽤户输⼊以下内容：Redmond'; drop table OrdersTable--此时，脚本将组成以下查询：1 SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

分号 (;) 表⽰⼀个查询的结束和另⼀个查询的开始。双连字符 (--) 指⽰当前⾏余下的部分是⼀个注释，应该忽略。如果修改后的代码语法正确，则服务器将执⾏该代码。SQL Server 处理该语句时，SQL Server 将⾸先选择 OrdersTable 中的所有记录（其中 ShipCity 为 Redmond）。然后，SQLServer 将删除 OrdersTable。只要注⼊的 SQL 代码语法正确，便⽆法采⽤编程⽅式来检测篡改。因此，必须验证所有⽤户输⼊，并仔细检查在您所⽤的服务器中执⾏构造SQL 命令的代码。本主题中的以下各部分说明了编写代码的最佳做法。下⾯就介绍⼀下常⽤的⼏种防⽌sql注⼊的⽅法：

始终通过测试类型、长度、格式和范围来验证⽤户输⼊。实现对恶意输⼊的预防时，请注意应⽤程序的体系结构和部署⽅案。请注意，设计为在安全环境中运⾏的程序可能会被复制到不安全的环境中。以下建议应被视为最佳做法：对应⽤程序接收的数据不做任何有关⼤⼩、类型或内容的假设。例如，您应该进⾏以下评估：如果⼀个⽤户在需要邮政编码的位置⽆意中或恶意地输⼊了⼀个 10 MB 的 MPEG ⽂件，应⽤程序会做出什么反应？如果在⽂本字段中嵌⼊了⼀个 DROP TABLE 语句，应⽤程序会做出什么反应？测试输⼊的⼤⼩和数据类型，强制执⾏适当的限制。这有助于防⽌有意造成的缓冲区溢出。测试字符串变量的内容，只接受所需的值。拒绝包含⼆进制数据、转义序列和注释字符的输⼊内容。这有助于防⽌脚本注⼊，防⽌某些缓冲区溢出攻击。使⽤ XML ⽂档时，根据数据的架构对输⼊的所有数据进⾏验证。绝不直接使⽤⽤户输⼊内容来⽣成 Transact-SQL 语句。使⽤存储过程来验证⽤户输⼊。在多层环境中，所有数据都应该在验证之后才允许进⼊可信区域。未通过验证过程的数据应被拒绝，并向前⼀层返回⼀个错误。实现多层验证。对⽆⽬的的恶意⽤户采取的预防措施对坚定的攻击者可能⽆效。更好的做法是在⽤户界⾯和所有跨信任边界的后续点上验证输⼊。例如，在客户端应⽤程序中验证数据可以防⽌简单的脚本注⼊。但是，如果下⼀层认为其输⼊已通过验证，则任何可以绕过客户端的恶意⽤户就可以不受限制地访问系统。绝不串联未验证的⽤户输⼊。字符串串联是脚本注⼊的主要输⼊点。在可能据以构造⽂件名的字段中，不接受下列字符串：AUX、CLOCK$、COM1 到 COM8、CON、CONFIG$、LPT1 到 LPT8、NUL 以及PRN。如果可能，拒绝包含以下字符的输⼊。

输⼊字符;'--/* ... */xp_

在 Transact-SQL 中的含义查询分隔符。字符数据字符串分隔符。注释分隔符。注释分隔符。服务器不对 /* 和 */ 之间的注释进⾏处理。⽤于⽬录扩展存储过程的名称的开头，如 xp_cmdshell。注：验证输⼊是最被常⽤和联想到的，但是个⼈感觉这种⽅式不但代码显得肥胖，⽽且效率不是很好2.使⽤类型安全的 SQL 参数SQL Server 中的 Parameters 集合提供了类型检查和长度验证。如果使⽤ Parameters 集合，则输⼊将被视为⽂字值⽽不是可执⾏代码。使⽤ Parameters 集合的另⼀个好处是可以强制执⾏类型和长度检查。范围以外的值将触发异常。以下代码段显⽰了如何使⽤ Parameters 集合：

1 SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn);2 dType = Procedure;3 SqlParameter parm = ("@au_id",4 r, 11);5 = ;在此⽰例中，@au_id 参数被视为⽂字值⽽不是可执⾏代码。将对此值进⾏类型和长度检查。如果 @au_id 值不符合指定的类型和长度约束，则将引发异常。

存储过程如果使⽤未筛选的输⼊，则可能容易受 SQL Injection 攻击。例如，以下代码容易受到攻击：

SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure '" + + "'", conn);

如果使⽤存储过程，则应使⽤参数作为存储过程的输⼊。注：在鄙⼈现在的项⽬中，这种⽅法应⽤最为⼴泛3.在动态 SQL 中使⽤参数集合如果不能使⽤存储过程，您仍可使⽤参数，如以下代码⽰例所⽰：

1 SqlDataAdapter myCommand = new SqlDataAdapter(2 "SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn);3 SQLParameter parm = ("@au_id",

4 r, 11);5 = ;注：和第⼆种雷同，这种⽅法是为了补充⽅法2存在，因为往往在很多时候业务简单不需要⽤proc的时候，可以⽤这种⽅法4.筛选输⼊筛选输⼊可以删除转义符，这也可能有助于防⽌ SQL 注⼊。但由于可引起问题的字符数量很⼤，因此这并不是⼀种可靠的防护⽅法。以下⽰例可搜索字符串分隔符。

1 private string SafeSqlLiteral(string inputSQL)2 {3 return e("'", "''");4 }

注：Filtering Input有种类似⽅法 ⼦句请注意，如果要使⽤ LIKE ⼦句，还必须对通配符字符进⾏转义：

1

2 s = e("[", "[[]");3 s = e("%", "[%]");4 s = e("_", "[_]");注：针对like⼦句，在使⽤时的效率这⾥就不多说了，总之要慎⽤了。

以上所有⽅法及其注释⾼亮显⽰部分，均为本⼈愚见，如果对⽅法有补充或者对⾼亮部分有不同意见的，欢迎⼤家给出意见，共同进步.本⽂是在借鉴的前提下加了⼀些⾃⼰的理解与意见， 转载请注⼊出处。 thx.

if您看了这篇博客。对您有所帮助，请不要吝啬您的“推荐”，您的推荐将是我最⼤的动⼒。有问题的话可以评论交流。