反应身份验证处理
我是 frontend dev并不那么熟悉安全。
当前，IM将用户的用户IDER存储在Web LocalStorage中。
通过使用UserID，我们可以向服务器请求有关用户信息。
问题是，我有点担心这种处理用户ID的方法是否存在潜在的危险。
当然，如果用户尝试使用其他用户ID值请求，他们可以获取其他用户数据（而不是私人信息，例如电子邮件或密码等等），
我允许用户获取其他用户数据的原因是在其他用户的配置文件时检查其他用户的配置文件。是否（如在个人资料页面上）
得出结论，在我的localStorage上存储了UserID，可以让用户减少登录，以检查当前路由中是否对用户进行身份验证。这不脆弱吗？
你们能给我建议吗？
I’m
FrontEnd dev who isn’t that familiar to security.
Currently, Im storing user’s userId at web localStorage.
By using userId , we could request to server about user Info.
The problem is that, Im little bit afraid whether there could be potential danger about this method of handling userId.
Of course If user tried to request with other userId value, they could get other users data(But not private infos like email or password blah blah)
The reason why I allow user to get other user’s data is to check profile of other user when they want ( like on profile page)
To conclude , on my localstorage, userId is stored, which can let user to less login, to check if user is authenticate in current route. Is this not vulnerable?
Can you guys give me advise whether its enough or not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我看到的主要安全问题是，任何人都可以更改其存储的用户ID，以将其作为其他用户进行身份验证。
而且，如果您的用户ID是增量的，您甚至不必知道任何用户ID，您可以猜到它们。如果我的用户ID是108，那么可能有107，109等。
我的建议是尝试实现诸如JWT身份验证之类的东西，但是如果一开始太多，则存储用户ID和秘密字符串的哈希（例如SHA256）将使无法猜测。这样，您就不能仅将用户形式复制到本地存储。在服务器中，您会收到Hash和userId，因此您可以使用UserId和Secret String复制哈希，如果它们匹配，则可以使用。
The main security issue I see is that anyone can change their stored userId to be authenticated as any other user.
And if your userIds are incremental, you don't even have to know any userId, you can guess them. If my userId is 108, then probably there's a 107, a 109, and so on.
My advice is to try to implement something like a JWT authentication, but if it's too much to begin with, storing a hash (like sha256) of the userId plus a secret string will make it impossible to guess. This way you can't just copy userIds to your localstorage. In the server you receive the hash and the userId, so you replicate the hash with the userId plus your secret string, and if they match, you're good to go.
LocalStorage可以存储与用户相关的不敏感信息。如果用户可以通过更改用户ID来获取其他用户信息，则他可以在服务器上加密用户ID并将其返回到页面。如果用户无法获得他人的加密用户ID，则他将无法要求。别人的信息
localstorage can store insensitive user-related information. If the user can get other user information by changing the userID, he can encrypt the userID on the server and return it to the page. If the user cannot get the encrypted user id of others, he will not be able to request. other people's information
如果用户登录成功，请从后端返回JSON Web令牌。然后，您可以将其存储在浏览器中存储的任何东西。在令牌中，您可以附加有效载荷。对于示例用户ID。您可以在后端中实现中间件接受令牌并将其解码以获取有效负载。然后，您可以使用该有效载荷实现逻辑以保存或获取数据。
您也可以使用刷新令牌到期，并重新生成新的令牌。这是其他安全机制。我们用来访问资源的令牌称为访问令牌，我们用来再生新令牌的令牌称为“刷新令牌”。
If the user sign-in successful, return json web token from the backend. Then you can store that token what ever store in the browser. In the token you can attach a payload. For a example user id. You can implement a middleware in the backend accept that token and decode it to get payload attached to it. Then you can implement logics to save or fetch data using that payload.
Also you can expire the token and regenerate a new token using refresh token. This is additional security mechanism. The token we used to access resources are called access tokens, the token we used to regenerate a new token is called refresh token.