|
|
1
3
我的建议是使用guid而不是自动增加id。这就彻底摆脱了“猜谜游戏”。 |
|
|
2
0
我一直非常怀疑使用Guid;然而,正如Lucerno指出的,它确实有助于根据Guid的生成和使用方式最大限度地减少猜测游戏。例如,使用SQL Server中的sequential生成的GUID不会阻止猜谜游戏。 如果您有一个域模型,并且您使用像nHibernate这样的ORM,甚至使用自己的ORM,那么GUI也非常方便。因为它大大简化了插入反向引用的复杂性,因为所有对象都可以在早期获得id。 也就是说,如果你的Id包含在URL中,它们应该被视为非常公开的数据。即使通过HTTPS,恶意攻击也可能获取整个URL。如果您的页面请求任何第三方内容,例如Google analytics,则url查询字符串和所有内容都将作为引用发送给第三方。 |
|
|
3
0
将登录的用户保持在服务器端的会话上,而不是将其传递给客户端-这样客户端就永远不会在恶意查询中更改用户id。 |
|
|
4
0
|
|
|
Michael · 某些Windows客户端上的命名管道安全问题 2 年前 |
|
|
adamency · 是否可以从Go二进制文件的源代码中检索字符串? 2 年前 |
|
|
AlboSimo · PayPal Api密钥安全 2 年前 |