目前，要在某些视图上将用户ID传递给服务器，我使用原始用户ID。
http://example.com/page/12345 //12345 Being the users id
虽然通过公开这些数据在我的特定应用程序中没有真正的安全风险，但我无法帮助，但感觉有点肮脏。什么是正确的解决方案？我应该以某种方式伪装数据吗？
提出问题的一个更好的方法是询问标准方法是什么。如果用户ID不是安全风险，那么在普通视图中使用用户ID是否常见？如果存在安全风险，如何处理？我只想在这里寻找正确方向的一点。
答案 0 :(得分：0)
这没有任何内在错误。很多网站都这样做。例如，可以使用以下格式的URL枚举Stack Overflow用户：
http://stackoverflow.com/users/123456
在URL中使用用户名称的规范化形式，或者与ID一起使用，或者作为其替代，可能是一个更好的解决方案，例如：
http://example.com/user/yourusername
http://example.com/user/12345/yourusername
如果您使用前者，则需要确保将规范化用户名设置为用户数据库中的唯一键。
如果您使用后者，您可以选择：如果数据库中的规范化用户名与URL中的用户名不匹配，您可以重定向到正确的URL（如Stack Overflow）确实），或返回404错误。
答案 1 :(得分：0)
除了duskwuff使用用户名而不是ID本身的好建议之外，您可以使用UUIDs而不是整数。它们的长度为128位，因此无法枚举，也避免详细说明您拥有多少用户。作为一项额外的好处，如果您的网站变得非常受欢迎，您的网站将针对用户ID限制进行验证。
例如，对于整数ID，攻击者可以在第一天找到最大的user_id，并在一周或几个月后返回并找到现在最大的user_id。他们可以不断地这样做来监控您网站的增长率 - 对您的示例而言可能不是一件大事 - 但许多组织认为此类信息对商业敏感。还有助于避免社会工程，例如使攻击者更难以通过电子邮件向您要求重置密码＃34;因为我已经更改了电子邮件提供商，而且我已经忘记了我的旧密码，但我记得我的用户ID！＆＃34;。攻击一英寸，他们将跑一英里。
我更喜欢使用Version/Type 4 (Random) UUIDs，但你也可以使用Version / Type 5（基于SHA-1），这样你就可以去UUID.fromName（12345）并获得一个从整数值派生的UUID，如果要迁移现有数据并需要更新一堆外键值，则非常有用。大多数主要语言本地支持UUID或包含在流行的库（C＆amp; C ++）中，尽管某些数据库软件可能需要进行一些调整 - 我已经将它们与postgres和我一起使用并且很容易转换。
缺点是UUID显着更长并且难以忘怀，但听起来您并不需要用户手动输入URL的能力。在创建用户时你也需要check if the UUID already exists，如果确实如此，只需继续生成直到找到未使用的UUID - 实际上考虑到数字的大小，使用版本4随机UUID你将有更好的机会在赢得彩票而不是处理碰撞时，所以它不会影响性能等。
示例网址：http://example.com/page/4586A0F1-2BAD-445F-BFC6-D5667B5A93A9