sql注入漏洞

共黄昏

已于 2022-05-03 12:31:47 修改

阅读量3.2k

点赞数 4

分类专栏：渗透测试文章标签： web安全

于 2022-04-27 00:11:40 首次发布

本文链接：https://blog.csdn.net/weixin_49472648/article/details/124440597

版权

SQL注入漏洞

严正声明：本文仅限于技术讨论，严禁用于其他用途。

在数据交互中，前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”拼接到SQL语句中后，被当作SQL语句的一部分执行。从而导致数据库受损（被脱裤、被删除、甚至整个服务器权限沦陷）。简而言之就是,由于用户不可控输入，攻击者可以任意的输入恶意的sql语句，使原始的查询语句的语义发生改变。从而对数据库或操作系统产生风险。
注意:注入攻击的本质，就是把用户输入的数据当做代码执行。
注入漏洞最根源的问题是,没有安全编码规范

SQL注入上得了机器权限，下得了数据。攻击者利用SQL注入漏洞，带来的风险有很多，例如数据库被拖库，管理员和重要人员信息泄露，甚至还能通过SQL注入漏洞直接获取webshell或者服务器系统权限等等。

对传进SQL语句里面的变量进行过滤，不允许危险字符传入；
预编译参数化查询 (提前编译SQL语句，将所有的用户输入都当做『数据』，而非『语法』)在设计与数据库连接并访问数据时，在需要填入数值或数据的地方，使用参数（Parameter）来给值
目前有很多ORM框架会自动使用参数化解决注入问题,但其也提供了"拼接"的方式,所以使用时需要慎重!
采用黑名单、白名单等形式对用户提交的信息进行过滤，一旦发现用户参数中出现敏感的词或者内容，则将其删除，使得执行失败。
安全设计遵循“数据与代码分离”原则
使用WAF(web应用防护墙)等安全产品

注:最好的防御，就是内部先发现。

日志监控—>蜜罐数据—>异常报警

监测方面目前大多都是：日志监控+waf。日志推荐走数据库日志，越是离资源操作近的地方，越是容易做到真正的安全。数据库日志容易解析，语法出错的、语法读 Info表的，都明确是黑客嘛，还能帮我们发现SQL注入点。
蜜罐方面：数据库里可放置一些蜜罐数据的帐号和密码。假如这有一个服务，可以先从日志入手，发现请求恶意异常时，自动转发蜜罐。比如用户表里，前几十行里，做些用户名和密码进行，实际上没有人用，一旦被登录

关注