Authentication Bypass: Anon can read/edit/create anything

[nakato]

With a config set:

{
    "ALLOW_ANON": "false",
    "REGISTRATION_ENABLED": "true",
    "PRIVATE_WIKI": "true"
}

A login page appears for non-authenticated users on many pages, viewing, history, index.

However the /_create and /_edit paths both show data and are writable.

Anon can edit/update/read/create anything if Anon knows the path.

[nakato]

Related #137

[nakato]

This issue needs to be reopened, I should not have put closes on #139, was only a small part of this bug.

There is still authentication bypass on /_create and /_edit paths.

[gazpachoking]

Hmm, I'm getting redirected to the login page for _create and _edit paths.

[gazpachoking]

@nakato Do you have any more details about the situation where this is possible still?

[nakato]

I've just validated this against the latest that is in pypi currently:

With the realms config

{
      "ALLOW_ANON": "false",
      "BASE_URL": "https://x",
      "CACHE_TYPE": "simple",
      "DB_URI": "sqlite:////tmp/wiki.db",
      "PORT": 5000,
      "REGISTRATION_ENABLED": true,
      "SEARCH_TYPE": "simple",
      "SECRET_KEY": "x",
      "SITE_TITLE": "x",
      "WIKI_PATH": "/tmp/wiki",
      "PRIVATE_WIKI": "true"
}

I can navigate to:

https://x/_edit/home and get the contents of home without logging in. _create will create pages

Seems to be something going wrong in login_required.

[jdexyz]

I can replicate this on a clean install on Ubuntu 14.04. The anonymous user can see the contents of the page and edit it. After clicking on the save button, you get redirected to the login page, but the file has been edited.

[gazpachoking]

With a config set:

{ "ALLOW_ANON": "false", "REGISTRATION_ENABLED": "true", "PRIVATE_WIKI": "true" }

Aha, these config values are meant to be booleans, not strings. The string "false" is truthy in python, so this is turning ALLOW_ANON on right now. Perhaps some form of config validation is in order.

[gazpachoking]

I think we are in better shape now that #183 is in. When a wiki gets marked as private now there isn't a loophole where the ALLOW_ANON can still let anonymous users in to some endpoints. Otherwise this is just a config issue.