在后端服务中经常需要通过传入参数动态生成sql查询mysql，如查询用户信息、资产信息等，一条常见的sql如下： SELECT vip, coin FROM user_asset WHERE uid='u123456' 该条sql查询用户"u123456"的的vip身份与游戏币数量，其中具体的uid取值就应该是传入的动态参数，不同用户生成的对应sql自然是不同的。

在python中,对于这条动态sql的拼接至少存在以下四种方案

其中1,2,3三种方式均是通过python本身的占位符语法先动态生成完整sql，而后直接提交到db执行，我们将其归为第一类，后面均以第1种方式作为代表进行分析，第4种方法则归为第二类。

第一类方法其实十分危险，是需要我们极力避免的错误方式，因为它存在确切的sql注入风险。具体分析来看，uid作为一个字符串类型，要想生成sql中带引号的参数，需要额外再在占位符两侧添加引号才行，否则将生成错误的sql，如下例:

问题在于uid的来源并不一定是可信的，如果uid参数是由客户端直接传过来、或者其他不可信的恶意来源传递，服务端直接取用该参数拼接sql的话，就可能直接被sql注入攻击，比如客户端传递恶意的uid本身带有引号的情况，则可以生成包括以下sql在内的各种恶意sql:

由此可见，通过使用python占位符直接拼装sql执行，是十分危险的行为。

事实上，在各类语言中拼装sql的标准写法应该都是采用第4种方式，即传入包含占位符的sql与参数列表，由库内部处理最终sql的拼装，其内部会对参数进行保护性转义之后再拼入sql之中。 那MySQLdb内部具体是如何处理参数转义拼接的呢？有没有办法可以得到最终拼装完成的sql在日志中输出方便调试呢？

先看第一个问题，通过查看源码可以在MySQLdb的cursors.py 中找到execute函数定义，其中有如下代码：

可以看到，如果传入args为tuple，则将通过args = tuple(map(db.literal, args))将其每个参数通过db.literal进行转义，最终还是通过 query = query % args 生成字符串，由于所有参数都已经经过转义了，所以能避免之前的注入问题。 那么能不能得到execute内部最终生成的这个query sql呢，很遗憾我们发现query是个函数内的局部变量，所以外部是无法直接获取其值的。当然如果一定要获取最终生成的sql也不是没办法，可以在代码中模拟这一literal操作拼接sql，而后输出。 接下来探究一下db.literal是个什么函数，外部能否直接调用它。

经过一通查找，发现literal函数定义在connections.py文件中：

可以看到，db.literal其实就是根据传入参数的类型，再调用不同类型的literal方法对其进行转义，而且db.literal本身是个实例方法，这意味着至少需要一个Connection 实例才可以引用到这一个方法。

通过初始化一个Connection示例，便可以调用其literal方式进行参数转义了，以下示例代码演示了通过literal对参数转义生成最终防注入风险的安全sql：

输出结果：

可以看到，uid内部添加的单引号'都会被'转义后才拼入sql之中。 需要注意的是，Connection.literal函数注释已明确说明该函数是Non-standard. For internal use; do not use this in your applications.，所以该函数的直接调用应仅限于调试用途，不可用于线上业务逻辑，同时由于必须现在实例化一个Connection对象才可调用其literal方法，要注意连接的正常关闭，防止泄漏。 转载请注明出处，原文地址: https://www.cnblogs.com/AcAc-t/p/python_sql_placeholder_prevent_injection.html