@keislamoglu wrote:

Insecure Solid Authentication Mechanism

While practicing & testing the Solid, I’ve noticed that Solid has an insecure authentication mechanism. I am going to explain this issue with a scenario, then I will give a proposition to fix it.

Assumptions

• pro-a.net is a POD provider and its URL is https://pro-a.net
• app-x is a malicious Solid-enabled client application.
• hacker-x is a hacker.
• app-x belongs to hacker-x.
• user-a is a user and has a POD on pro-a.net.
• user-a’s WebID is https://user-a.pro-a.net/profile/card#me

Scenario

1. user-a sign-in to app-x using their credentials for https://user-a.pro-a.net/profile/card#me
2. app-x copy user-a’s session information from localStorage, then sends to hacker-x’s e-mail.
3. hacker-x opens https://user-a.pro-a.net then pastes user-a’s session information to localStorage.
4. Consequently, hacker-x signed-in as user-a (the data owner).

Those steps can be tested without a client-app of course. That is just for figuring out as a real scenario. To test this issue, you can basically copy and paste the localStorage data.

Proposition

To fix this major security issue, authentication tokens should be generated domain-based. Thus, one session is going to be related to just one domain, eventually hacking will be blocked.

Posts: 14

Participants: 4

Read full topic