|
1
2
SQL注入是一个严重的风险,你应该尽你所能来防范它。即使您认为您的$user_id来自会话数据,您仍然必须考虑会话数据的来源。你说是数据库,但它是怎么进入数据库的? 只需进行防御性编码。在这种情况下,这是非常简单和容易的——只要将$user_id强制为一个整数,就可以确保在将其插入查询时不会出现额外的SQL语法。 另外,你的函数不需要使用递归。下面是一个以更简单的方式执行相同功能的示例:
这个简单的代码唯一不支持的是$clearance中的嵌套数组。但你真的需要支持吗? 附言:我也建议你换成 PDO . 它易于使用,并且支持带参数的SQL查询,这对SQL注入是更好的防御。例如:
|
|
|
2
6
|
|
|
3
0
还有一种情况是SQL注入。你可以注入一个简单的重言式,比如
|
|
|
4
0
|
|
|
5
0
即使你现在百分之百地知道$id从哪里来,也不一定会认为总是这样。如果你的应用程序增长了怎么办?如果你有更多的人在做呢?如果在$会话值之外使用不同的值调用此函数,会怎么样?当然,你可能知道你的应用程序的来龙去脉,你知道这可能永远不会发生,但这仍然是一个坏的做法。至少,您可以使用mysql_real_escape_字符串。
|
|
|
Michael · 某些Windows客户端上的命名管道安全问题 2 年前 |
|
|
adamency · 是否可以从Go二进制文件的源代码中检索字符串? 2 年前 |
|
|
AlboSimo · PayPal Api密钥安全 2 年前 |