珠海网站推广,网站建设合同交印花税吗,seo关键词优化方案,常州建站程序日常搬砖#xff0c;总少不了需要获取分页数据和总行数。 一直以来的实践是编码两次sql请求#xff0c;分别拉分页数据和totalCount。 最近我在思考#xff1a; 常规实践为什么不是 在一次sql请求中中执行多次sql查询或多次更新#xff0c;显而易见的优势#xff1a; ① 能… 日常搬砖总少不了需要获取分页数据和总行数。 一直以来的实践是编码两次sql请求分别拉分页数据和totalCount。 最近我在思考 常规实践为什么不是 在一次sql请求中中执行多次sql查询或多次更新显而易见的优势 ① 能显著减低“客户端和服务器之间的网络往返次数”提高吞吐量② 简化客户端代码逻辑 1. mysql 默认单sql请求单语句 mysql客户端选项client_multi_statements默认为false会禁止多条 SQL 语句的执行这意味着在单个sql请求中只有第一条 SQL 语句会被执行后续的 SQL 语句将被忽略。 这是一种提高数据库操作安全性的方法可以有效防止 SQL 注入攻击和意外执行多条语句带来的风险。 MySQL客户端支持修改这样的设定 client_multi_statementstrue。 劣势存在sql注入的风险 错误处理比较复杂。 (1) go-sql-driver开启多语句支持: multiStatementstrue (2) SELECT * FROM dict_plugin limit 20 ,10;
SELECT count(*) as totalCount from dict_plugin; 将会形成2个数据集golang的实践如下 results, err p.Query(querystring)for results.Next() {err results.Scan(...)}if !results.NextResultSet() {log.ErrorF(ctx, expected more result sets: %v, results.Err())}for results.Next() {err results.Scan(totalCount)} 既然提到了开启client_multi_statements 有sql注入的风险我们就展开聊一聊。 2. sql注入 我们先看下sql注入的原理 有这样的业务sql var input_name string
query: select * from user where user_name input_name
sql.Query(query) 如果从界面输入的input_namejanus;delete from user; --,会形成恶意sqlselect * from user where user_namejanus;delete from user; -- 。 这个时候客户端的client_multi_statements默认值为false就能于水火之间挽救数据库执行第一个sql之后后面的恶意sql都不会执行。 由此可知client_multi_statementsfalse确实可以显著降低sql注入的风险但是还是没有办法避免单sql注入 比如从界面密码框注入 OR 11 会绕过登录认证。 query: select * from user where user input_name and pwd input_pwd select * from user where userxxx and pwd OR 11 -- 会绕过认证逻辑。 3. 参数化查询防止sql注入 参数化查询可以防止sql注入风险[1] // Correct format for executing an SQL statement with parameters.var queryStr SELECT * FROM dict_plugin_Test WHERE plugin_name ?
var args string 55 union select * from dict_plugin_Testrows, err : db.Query(queryStr, args) sql查询内部会利用提供的参数1创建预编译语句 在运行时实际是执行带参的预编译后的语句。 在服务器收到的查询日志如下 2024-08-13T08:07:18.922818Z 26 Connect rootlocalhost on tcinfra_janus_sharing using TCP/IP
2024-08-13T08:07:18.924525Z 26 Prepare SELECT * FROM dict_plugin_Test WHERE plugin_name ?
2024-08-13T08:07:18.924671Z 26 Execute SELECT * FROM dict_plugin_Test WHERE plugin_name 55 union select * from dict_plugin_Test
2024-08-13T08:07:18.925273Z 26 Close stmt 判断mysql数据库开启了查询日志show variables like %general_log%;打开sql查询日志的开关set global general_log on; 。 注意参数占位符根据DBSM和驱动而有所不同例如Postgres 的pq驱动程序接受占位符形式是 $1而不是?。 3.1 预编译语句 数据库预编译后 SQL语义结构和数据分离这样即使输入包含恶意代码它也只会被当作数据处理不会影响已经被解析固定的SQL语义结构。 预编译语句包含两次 sql交互 ① 预编译阶段Prepare Phase 客户端向服务器发送一个包含 SQL 语句带有参数占位符的请求。sql服务器对SQL 语句进行语法和语义检查然后对其进行预编译并为其分配一个标识符Statement ID。服务器返回一个确认响应表示预编译语句已经成功准备好。 ② 执行阶段Execute Phase 客户端发送执行请求包含预编译语句的标识符和实际参数值。服务器将参数值绑定到预编译语句的占位符上然后执行该语句。服务器返回执行结果如结果集或影响的行数。 图示如下 客户端 服务器| ||----预编译语句Prepare------|| ||-------确认响应OK----------|| ||---执行语句Execute 参数----|| ||----------查询结果-------------| 我们了解到预编译语句将SQL语义和数据分离通过两次sql交互在预编译阶段固定了sql语义结构 有效防止了SQL注入攻击, 另一方面预编译语句在重复执行某一sql语句时确实有加快查询结果的效果。 golang的预编译的写法与常规的sql查询类似 stmt, err : p.Prepare(SELECT * FROM dict_plugin_Test WHERE plugin_name ?)
var args string 55 union select * from dict_plugin_Test
results, err : stmt.Query(args)
if err ! nil {fmt.Printf(query fail: %v, err)return err
}
defer stmt.Close()for results.Next() {err results.Scan(.....)......
} btw, C# 其实也支持预编译语句版本的sqlCommandSqlCommand.Prepare() 总结 本文通过我们最初开始数据库编程时的一个实践 提出在【一次sql请求中执行多次sql查询】的猜想 了解到client_multi_statements false 确实能避免一部分sql注入风险 之后落地到sql注入的原理 给出了参数化查询预编译语句能防止sql注入的核心机制。 参考资料 [1] 参数化查询可以防止sql注入风险: https://go.dev/doc/database/sql-injection 自古以来同步/异步都是八股文第一章 async/await 贴脸输出这次你总该明白了 流量调度、微服务可寻址性和注册中心 Go语言正/反向代理的姿势 两将军问题和TCP三次握手 家长进校园之《计算机和人工智能》 点“赞”戳“在看”
