概念
SQL注入是一种欺骗数据库服务器的攻击手段 , 通过修改或拼接web界面中表单域、原URL或数据包输入的参数为SQL语句 , 输入到web服务器中进而使数据库服务器执行数据库命令 。
文章插图
简单的说 , 就是在输入字符串中嵌入SQL命令 , 在设计程序中忽略了对特殊字符串的检查 , 这些嵌入的指令便会被误认为是正常的SQL命令从而在数据库中执行 , 从而攻击成功 。
假如一个网站的页面显示URL为example.com?test=111 , 此时URL实际向服务器传递了值为111的变量test , 这表明当前页面是对数据库进行动态查询的结果 , 此时在URL中插入恶意SQL语句并执行 。
例如一个网站登录验证的 SQL 查询代码为:
strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ password +"');"
如果填入以下内容:
userName = "1' OR '1'='1";
passWord = "1' OR '1'='1";
那么 SQL 查询字符串为:
strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"
此时无需验证通过就能执行以下查询:
strSQL = "SELECT * FROM users;"
分类
目前SQL注入大致分为普通注入和盲注:
普通注入
根据后台数据库提示有价值的错误信息进行注入 。
盲注
有经验的管理员在给出代码有漏洞的页面时 , 没有提供详细的错误信息 。
攻击者需要运用脚本通过仅有的判断信息(比如时间差)对表中的每一个字段进行探测 , 从而实现注入的技术(盲注的难度较大 , 但注入测试中经常会遇到) 。
危害
只要是使用数据库开发的应用系统就可能存在SQL注入攻击 。
自1999年起 , SQL注入就成了常见安全漏洞之一 , SQL注入漏洞至今仍然在CVE列表中排前十 。
防范SQL注入的方法
错误消息处理
要防御SQL注入 , 就要避免在网页中出现一些详细的错误信息 。
攻击者可以利用这些信息来插入SQL语句 , 因此使用一种标准的输入确认机制来验证所有的输入数据的类型、长度、规则、语句等 。
输入验证
检查用户输入的合法性 , 尽量限制用户输入特殊的符号 , 确保输入的内容只包含合法的数据 。
在客户端和服务器端都要执行用户输入检查 。之所以要执行服务器端验证 , 是为了弥补客户端验证机制脆弱的安全性 。
加密处理
没有加密的数据可以被直接利用 , 但是加密了就不一定会解密成功 , 因此尽量不要使用一些常见的加密算法 , 就算用也要使用32位以上的加密算法 , 将用户登录名称、密码等数据加密保存 。
加密用户输入的数据 , 然后再将它与数据库中保存的数据比较 , 这相当于对用户输入的数据进行了“消毒”处理 , 用户输入的数据不再对数据库有任何特殊的意义 , 从而也就使攻击者无法利用用户输入来注入SQL命令 。
存储过程来执行所有的查询
SQL参数的传递方式将防止利用单引号和连字符实施注入 。
此外 , 它还使得数据库权限只允许特定的存储过程执行 , 所有的用户输入必须遵从被调用的存储过程 , 这样就很难再发生SQL注入了 。
【简述SQL注入攻击】
推荐阅读
- SQL注入原理及防御
- MySQL性能优化实践
- CentOS7下yum方式安装MySQL5.7数据库
- PostgreSQL的最佳群集高可用性方案
- MySQL必须要掌握的常用查询语句
- SpringBoot+Mysql做登陆接口,抛弃mapper.xml
- MySQL多表查询讲解
- 简述长城的建造历史 我国最早的长城遗址是
- 记一次 MySQL 复制故障-Error_code:1317
- MySQL数据迁移到TiDB的流程及为何放弃MyCat