​MySQL Load data infile是有一个很有意思的功能，最早接触的时候，没有太过在意，后来在安全扫描中，被提示需要关闭local_infile选项（当然，默认该选项就是关闭的，只是安全扫描要求在配置文件中做明确配置），才又注意到了其中的local关键字​。

    ​所谓的local，指的是客户端，即LOAD DATA是从客户端加载文件，这就让客户端有机会把本机的文件内容上传到服务器的表中。当然，文件要落地到服务器磁盘的话，还要配合secure_file_priv选项，这个一般是关闭或只开到限定目录。所以通过LOAD DATA LOCAL INFILE攻击服务器的风险是很小的，它的安全隐患主要在于从客户端发起LOAD DATA LOCAL INFILE，获取客户端的文件信息（比如被SQL注入）。MySQL服务端关闭local_infile选项的目的是协防客户端​。

    ​最近，又看到了利用local来制作蜜罐，才发现自己真的没有好好理解这个LOAD DA​TA。在之前的理解中，既然是将客户端将自己的文件发到服务端，那么它应该是自己读取本机的文件，组织内容往服务端发送就行了，服务端这个蜜罐去反向操控​客户端呢？

    ​在这里，忽略了一个很简单的常识，LOAD DATA也是一个SQL语句，既然是一个SQL语句，那么它是发到服务器去做解析执行的，客户端不会有解析SQL语句的行为​。所以对于一个LOAD DATA LOCAL语句，客户端驱动自己是不会知道这个语句是干嘛的，它要先发到服务端，服务端解析后，发现这个语句是从客户端LOAD FILE，于是回复客户端一个Response TABULAR，里面包含要求客户端提供数据的文件名​。关键点就在这个Response TABULAR包上了，由于客户端是不解析SQL语句的，所以它自己不知道要给服务端推送哪个文件，自然是服务端要那个就给那个，所以蜜罐就是利用这一点，把自己伪装成MySQL服务端，在收到客户端请求之后，直接回复一个Response TABULAR给客户端，这样就能让客户端乖乖提供服务端所需要的文件​内容了。

    ​对于正常用户来说，要防患这个蜜罐，不连接不信任的MySQL服务器即可。如果因为某些原因，你一定要连接的话，那么最简单的一招是确保自己在建立 数据库连接时，没有打开local_infile选项（客户端选项，只有客户端和服务器都开启local_infile选项时，LOAD DATA LOCAL才能正常运行）。

    ​比如使用mysql命令行工具，在Windows下，需要指定参数--local-file=0，而Linux下，则该工具默认是关闭了这个选项的（感觉Windows下的这里是留坑了，mysql --help显示这个选项默认是关闭的）​。

​    ​如果使用程序连接，通常连接字符中也是有对应选项的，比如MySQL官网的驱动中，是包含对应选项的​。

    ​如果你所用的连接方法中找不到关闭local_file选项的方法，那么你可以在一个最低权限的用户中运行你的程序，这样它能读取的文件就只限于运行工具的用户所能访问的文件。

    ​（至于​具体的蜜罐原理和制作方法，网上有很多文章，这里就不啰嗦了）

【本文在个人微信公共号ZJCXC上同步发表】