I just set up a few phpBibliography systems on a single Webserver to serve different bibliographies for different uses. Now, when logged in to ONE of them with a regular user it seems I can just use that Cookie to go to another Databases ./login/ URL and I am instantly logged in with write permission!! Even if the second DB doesn't even know about that user!!!
But it gets worse than that. A regular User can actually change another users password under a certain scenario. Like this:
User A logs in to Database A. User A does change his password on the "Admin menu / List users" page and closes the Window.
User B logs in to Database B. Uses the Cookie to switch to Database A's ./login/ page, and clicks on "Admin menu / List users". Now User B gets presented User A's username in the "Username" field AAAND can actually change User A's password without superuser permissions!!
I believe these are major security loopholes that need to be fixed ASAP. I'll see about the bugtracking system here and submit this on the Bugtracker if I am allowed to. Just wanted to make sure people know about this.
One good thing: The attack seems to work only for Databases running on the same host. An attack on a phpBibliography somewhere on the web using the Cookie of your own, compromised one does not work as far as I have tested.
This stuff really hurts my confidence in this system, even though it is otherwise very convenient to use.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi
the two different phpbibliographies have different URLS I assume, right?
it then sounds strange that the cookie is reused since the actual absolute URL should be part of the session cookie, I guess.
I'll try to address this issue as soon as possible.
Thanks for the report!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greetings!
I just set up a few phpBibliography systems on a single Webserver to serve different bibliographies for different uses. Now, when logged in to ONE of them with a regular user it seems I can just use that Cookie to go to another Databases ./login/ URL and I am instantly logged in with write permission!! Even if the second DB doesn't even know about that user!!!
But it gets worse than that. A regular User can actually change another users password under a certain scenario. Like this:
User A logs in to Database A. User A does change his password on the "Admin menu / List users" page and closes the Window.
User B logs in to Database B. Uses the Cookie to switch to Database A's ./login/ page, and clicks on "Admin menu / List users". Now User B gets presented User A's username in the "Username" field AAAND can actually change User A's password without superuser permissions!!
I believe these are major security loopholes that need to be fixed ASAP. I'll see about the bugtracking system here and submit this on the Bugtracker if I am allowed to. Just wanted to make sure people know about this.
One good thing: The attack seems to work only for Databases running on the same host. An attack on a phpBibliography somewhere on the web using the Cookie of your own, compromised one does not work as far as I have tested.
This stuff really hurts my confidence in this system, even though it is otherwise very convenient to use.
hi
the two different phpbibliographies have different URLS I assume, right?
it then sounds strange that the cookie is reused since the actual absolute URL should be part of the session cookie, I guess.
I'll try to address this issue as soon as possible.
Thanks for the report!
Please, try to change in all your phpbibliography installation on the same machine this value in core.php
I mean, in each installation use a different random string, and please tell me whether the problem is still there.