这是一个创建于 1299 天前的主题，其中的信息可能已经有所发展或是发生改变。
后端表示参数拼接成 SQL 接收，真的服了，就不怕 SQL 注入吗
 |
1
jack778 2021-04-29 10:35:48 +08:00  1
复制黏贴，能跑就行
|
 |
2
buffzty 2021-04-29 10:36:01 +08:00
2021 年了为啥还有程序员天天编程写 bug 啊?
|
 |
3
Mr0C OP 常见的安全问题都不 care 吗
|
 |
4
jk1030 2021-04-29 10:42:37 +08:00 3
2B 的产品有时候 sql 拼接参数是 feature
|
 |
5
PDX 2021-04-29 10:43:45 +08:00
你去看看事业单位用的办公系统
|
 |
6
statement 2021-04-29 10:45:46 +08:00 via iPhone
后端校验啊。 前端只有约定好格式就行。和前端有什么关系。 你只要约定好 前端 delete 。后端当 select 用也行啊
|
 |
7
watcher 2021-04-29 10:48:29 +08:00
sql 作为描述语言，谁规定一定就是用来操作数据库的？用来操作搜索引擎不可以吗？
|
 |
8
panda666 2021-04-29 10:49:46 +08:00
sql 和前端有毛的关系
|
 |
9
mengdodo 2021-04-29 10:56:17 +08:00
@panda666 还真有，那个前两年兴起的前端 sql 技术，后端只需要约定接口通往数据层的表模型，前端自己调 sql 读写，我忘记叫什么了。 我一直觉得不靠谱……
|
 |
10
zjsxwc 2021-04-29 10:56:28 +08:00
我记得 老项目 CS 架构的 都是 直接客户端传 SQL，
服务端搞个 sql parser 就知道这条客户端提交的 sql 是否有权限。 |
 |
11
no1xsyzy 2021-04-29 11:06:02 +08:00
https://data.stackexchange.com/
https://www.opendota.com/explorer 不怕注入吗？ @mengdodo 这也不是前端，这是 API 。同样一个 HTTP API，另一个后端程序也可以调用。 前端是 UI 到 API 中间的东西（不管它的技术手段是啥） |
 |
12
KouShuiYu 2021-04-29 11:15:08 +08:00
https://carto.com/
这个公司为每个用户新建一个数据库 |
 |
13
bthulu 2021-04-29 11:18:08 +08:00
怕什么注入, 法院重拳出击就行了
|
 |
14
darknoll 2021-04-29 11:38:32 +08:00
这能怪前端？？你后端干嘛吃的
|
 |
15
yaphets666 2021-04-29 11:45:34 +08:00
现在有种东西叫 graphql，类似
|
 |
16
opengps 2021-04-29 12:04:40 +08:00 2
能这么做的项目显然确实没啥用户量，甚至说是自己给自己用。对于注入这种事，小公司不遇到是不会去防的
|
 |
17
Cbdy 2021-04-29 12:07:03 +08:00 via Android
老板：又不是不能用
|
 |
19
ijrou 2021-04-29 12:36:28 +08:00
老板：能用为啥还这么讲究？
|
 |
20
mypchas6fans 2021-04-29 12:39:56 +08:00
告诉各位我曾经呆过的某公司，近两年做的一个模块，名曰 xxx risk analysis，
卖点是分析业务相关的指标和风险点，具体怎么做的呢？ 业务人员默认准备了一堆 SQL，可以根据需要在页面上微调，然后发到后端执行，结果再存到特定表里，前端做成报表，给客户大佬看…… 实际上就是个 xxx sql analysis…… |
 |
21
Trim21 2021-04-29 12:46:20 +08:00 via Android
@yaphets666 grqphql 也有占位符和参数…
|
 |
23
unco020511 2021-04-29 16:00:37 +08:00
领导:又不是不能用
|
 |
24
3dwelcome 2021-04-29 16:20:08 +08:00
我以前也想过这问题，为什么前端写 SQL ？因为代码改起来方便，开发速度快啊。
当初的设想是，开发阶段前端写明文 SQL，发布阶段把 SQL 全部都用 hash 替代，然后后端校验 hash 有效性，再根据前端的 HASH，来还原明文 SQL 语句，并阻止未授权的 SQL 运行。 这样既保证了开发效率，又保证了安全性。 |
 |
25
lagoon 2021-04-29 16:21:45 +08:00
http，直接明文传输各种数据，都见怪不怪了。
|
 |
27
KyonLi 2021-04-29 21:01:07 +08:00 via iPhone
对对对，就是前端求着后端自己来写 sql 的
|
|
29
3dwelcome 2021-04-29 23:29:45 +08:00
@evilStart 不需要还原，后端的 hash 白名单而已。开发明文阶段，后端每条语句都有缓存明文和对应 hash 值的。
生产环境只是简单查个表。 |
 |
30
chanchan 2021-04-30 04:29:02 +08:00
这不是我上家吗 哈哈
|
 |
31
codingKingKong 2021-04-30 09:58:05 +08:00
看使用范围, 如果是内部应用, 所有人拥有所有表操作权限, 或者就是个面馆管理系统, 恰好老板会点 sql, 也不是不行
要是还需要控制权限呢, 就考虑查之前做一下鉴权 要是还需要审计呢, 就考虑一下再加上 log 要是还需要公开使用呢...考虑一下再加上敏感字段加密, sql 防注入...不过公网公开的这种接口, 我还没遇到也就是了 |
 |
32
passerbytiny 2021-04-30 10:01:10 +08:00 via Android
@3dwelcome 用名单管理 sql，我敢保证想出这点子的人不是干活——包括但不限于编码、测试、评审——的。玩呢，这干活时间那不是翻倍，是翻几番。
|
|
33
passerbytiny 2021-04-30 10:04:40 +08:00 via Android
为啥还有公司前端使用 SQL 拼接参数？简单来说，懒。深入一点可能是：甲方，或者更可能是乙方老板，压根就没打算做能用的东西。
|
 |
34
lajunnow888 2021-04-30 14:24:41 +08:00
一句话，又不是不能用
|
 |
36
ZhaoHuiLiu 2021-05-01 01:10:08 +08:00
都是拿钱做事，安全这东西，得负责人懂程序，不然大家都是玩玩。。。
|
Select Language