Opened 15 years ago
Closed 15 years ago
#2343 closed defect (bug) (fixed)
SECURITY RISK (internal): Forum posts are "promiscuous" and can be hacked by unauthorized users
Reported by: | 3sixty | Owned by: | |
---|---|---|---|
Milestone: | 1.2.4 | Priority: | critical |
Severity: | Version: | ||
Component: | Forums | Keywords: | has-patch, needs-testing |
Cc: | 3sixty, boonebgorges@… |
Description
Forum posts are "promiscuous" and can masquerade as belonging to other forums - even if it is a private forum (probably also a problem with hidden forums).
Here is a working example from testbp.org. Start with this private topic that you do not have rights to view:
Now, replace group name with any existing other group name, such as /baseball/ , and you will now see the private topic:
http://testbp.org/groups/baseball/forum/topic/super-secret-post/
This example shows how an unauthorized user can have access to private posts they should not be seeing.
Attachments (2)
Change History (13)
#1
@
15 years ago
- Summary changed from SECURITY RISK (internal): Forum posts are "promiscuous" and can masquerade as belonging to other forums to SECURITY RISK (internal): Forum posts are "promiscuous" and can be hacked by unauthorized users
#3
@
15 years ago
thanks, I came across this while coding a plugin.
I agree that the permalink will usually be hard to find, but now that the bug is public, it makes me hesitant for reasons I don't want to further describe. probably best to patch this one quickly. I can try to review the core code, but I have no idea where to start on this one - is it a problem at the bp "slug" level??
#5
@
15 years ago
Ironically enough, this problem starts off as a bbPress problem. bbPress doesn't include the name of the forum, category, or tag in the permalink structure when viewing an individual topic.
My patch passes the $forum_id through to the core BuddyPress classes as variable, and then checks against that variable before the topic template processed. If the topic->forum_id doesn't match the current_group->forum_id, then it returns false.
Give the patch some testing and feel free to repatch.
#7
@
15 years ago
jjj - Your patch didn't work for me on the most recent trunk. $bp->groups->current_group->forum_id wasn't getting populated. I didn't trace it all the way back, but could that be because bp_has_forum_topics isn't getting called on the topic pages?
This new patch does a manual lookup of the groupmeta for forum_id instead.
#8
@
15 years ago
This solution works to prevent the bug, but for core we need to take into account situations where groups might not be turned on and forums might be using other components.
There are only a few functions where these two components are required to talk to each other, and its best to keep that to a minimum if we can.
Getting closer.
#9
@
15 years ago
Hm... This also breaks seeing topics by tag, since there is no forum_id listed.
Back to the drawing board.
#10
@
15 years ago
- Cc boonebgorges@… added
bp_has_forum_topics essentially does the same thing as my patch (if $forum_id is missing it uses groups_get_groupmeta to find it). See around line 172 in bp-forums-templatetags.php.
jjj - what you're suggesting sounds like it needs another abstraction layer, something like "forum parent", that groups and other components could tap into.
Great find, 3sixty!
Although it does require actually knowing the forum post's permalink, which in most cases will be hard to find if you're not a member of that group.