Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent the user from not being able to use the chatbot if not authenticated #48

Closed
MrDave1999 opened this issue Sep 13, 2022 · 1 comment · Fixed by #155
Closed

Prevent the user from not being able to use the chatbot if not authenticated #48

MrDave1999 opened this issue Sep 13, 2022 · 1 comment · Fixed by #155
Labels
security Issue or pull request related to application security

Comments

@MrDave1999
Copy link
Member

MrDave1999 commented Sep 13, 2022

Currently the endpoint where the bot listens is public, so anyone could communicate with the bot. It would be nice if only authenticated users could access the bot from the website.

In addition, the same security token can be passed to the bot as the one provide by the website when the user logs in.
In that case, on the bot side, the access token would have to be validated to check if the user has authenticated.

If no check is performed, any user can schedule appointments for other users simply by knowing the user ID (this is known as user impersonation).

@MrDave1999 MrDave1999 added needs review Issue or pull request that need review or further investigation security Issue or pull request related to application security labels Sep 13, 2022
@MrDave1999 MrDave1999 modified the milestone: v1.0.0 Jan 16, 2023
@MrDave1999
Copy link
Member Author

MrDave1999 commented Jan 29, 2023

The solution was easier than I thought. There is no need to pass any security token to the bot.

The only thing to do is to link the user ID in the Direct Line token, that way, Direct Line can perform an additional validation, as described in the documentation:

Direct Line can perform additional security validation of the user ID and name, inhibiting tampering of these values by malicious clients.

This means that Direct Line will use the user ID attached to the token, regardless of whether a malicious user tries to alter it.

However, there is a problem, the person ID (the identification of a user's personal information) field is still manipulable. Any malicious user can modify this field. So the proposed solution is to embed the person ID together with the user ID in the Direct Line token.

Example:

{
  "user": {
    "id": "dl_{userID}-{personID}",
  }
}

{userID} and {personID} must be replaced by their respective IDs. Then, on the bot side, can add a code that is in charge of performing a split to obtain the IDs.
If this process is not performed, a malicious user may provide their own person ID and attempt to schedule an appointment for another user without their consent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security Issue or pull request related to application security
Projects
No open projects
1 participant