Mysql注入防御

Mysql注入防御

一、应用层防御

1、SQL注入的本质原因是应用层的问题

2、SQL注入应用层防御目标是修复SQL所有可能的漏洞，做好事前的防范

• 过滤SQL注入基本字符：

’ or " 字符串闭合

– or # 单行注释

/*…*/ 多行注释

+ 加号，url中替代空格拼接字符

concat 字符拼接

% 通配符

?Param1=foo&Param2=bar url参数

select url打印常量等

@variable 本地变量

@@variable 全局变量

Sleep 10 睡眠10秒

• 过滤SQL关键字

  如：add asc call check cross database both databases alter as by case create

• URL传参的整体加密

  • 原URL

    https://61.106.xxx.xxx/corp/tokusyu.php?mid=1&tksid=473

  • 整体加密处理

    https://61.206.xxx.xxx/corp/tokusyu.php?action=LSKDJFOINWHEO

    
    

二、系统层防御

1、SQL注入的本质原因不是由系统层的问题

2、系统层的防御使辅助的作用，是预防SQL注入与系统层交互提权，预防SQL注入权限的进一步扩大，使得SQL注入在系统层无所作为。

• Iptables限制只允许特定的服务器IP和端口登录

  在黑客SQL注入提权成功之后，预防扩散到其他服务器

• 使用应用防火墙对SQL注入拒绝waf

• 数据库安全中间件，如greenSQL，安全狗等。

  
  

三、数据库层防御

1、SQL注入的本质原因并不是数据库层的问题

2、数据库层防御的目标是辅助性的，预防SQL注入的数据层交互提权，防止SQL注入成功后权限和数据泄露进一步扩大

• 数据库最小化原则

  revoke file on *.* from zhangsan@’%’; //剥夺用户zhangsan读文件权限

  程序连接的权限分配以最小化为原则，能省就别大方

  如大多数据程序连接都是以select,insert,update和delete权限，那么就只给这些权限。这样，对于读取文件系统层文件所需的FILE权限就没有，那么与系统层交互提权的路径就堵上了，使得SQL注入无所作为

• 数据库层设计规范化要求

  • 这个DBA专业的SQL审查的要求

  • 如何设计尽量保持高性能，同时也要预防SQL猜测出错的可能性

  • 数据库架构设计考虑性能与安全的权衡，通常在保障性能的前提下去考虑安全性的折中

    varchar(20)安全与性能的折中

    varchar(5)偏向性能，结果性能与安全不兼得