Username Password
Bookmark and Share
View All Tickets
Visitors (and others) can bypass group-by-IP restrictions  (#11552)

IP-based groups are not restrictive enough when there are multiple users sharing the same WebGUI user to access the site. This is primarily a problem with the Visitor account, but appears to exist in all accounts where logins occur from multiple IP addresses within a relatively short amount of time. If someone who falls within the IP range views content restricted to this group, then others who are viewing the site as the same user, but who are outside the IP range, get to see the restricted content.

Or, from a more expert opinion, preaction described this on IRC as a "case of WebGUI's aggressive group calculation (calculating as many members as possible every time)".

To replicate:

  1. Create an IP-based group with an IP range that includes one of your network connections. (You'll need a computer on another network connection outside this range for testing.)

  2. Create content on a WebGUI site that (1) has its view restrictions set to the new group, and (2) has caching set to 0 seconds.
  3. Save, commit, etc.

Try viewing the page from a computer outside the IP range, without logging in (as Visitor). As expected, you should not see the restricted content. Next, view the content as Visitor from a computer within the IP range; you SHOULD see the restricted content now. Finally, go back to the first computer and re-load the content while still as Visitor; this time you should see the restricted content as well, despite being outside the IP range. It appears that once the Visitor account is added to the IP-based group, that group membership is applied to all instances/sessions of the Visitor account, regardless of which IP address that instance is connecting from.

The above series shoud have the same effect with ANY account used from multiple IP addresses. If you log in from outside the approved IP range, you should not see the restricted content at first, but if you log in with the same account from an IP address that is approved and then go back to the first account, the restricted content should appear.

Even with caching set to 0 seconds, the above tests seem to get unpredictable with multiple logins and logouts. Sometimes clearing the WebGUI cache helps. (You can get to situations where the content does NOT appear, even when it SHOULD.)

I discovered this behavior on a system running 7.5.38, but confirmed the same behavior exists using a WebGUI demo site, running 7.8.18

I marked this ticket as "minor" because it doesn't prevent us from using WebGUI; however, it does keep us from using the group-by-IP feature, because it doesn't do what we need it to.

Solution Summary
4/30/2010 3:49 pm
Also, setting the "Expire Offset" for the group to zero or 1 seconds does not appear to help, though one would expect that this might have been one way to resolve the problem.
5/11/2010 7:00 pm
The same problem exists for group membership via Scratch variables.
5/11/2010 9:28 pm
More notes:

Group membership is cached in the session.  Each session is uniquely tied to the browser via the cookie.  It's not possible for group membership to leak in the way that's described in the bug, which also explains why changing the group timeout doesn't affect the behavior.

It's much, much more likely that this is due to content caching, like that done by the Layout, Article and Snippet assets.  Those assets fill and empty their caches based on usernames, not on group membership.
5/12/2010 9:52 am
Because I have run across similar caching issues before, one of the first thing I checked when I ran across this issue was that the content I wanted to be restricted didn't have caching enabled. For all the user-configurable settings, the problem persists, even when caching is set to 0 seconds.

If there is caching done for layouts, there is no control available for managing it on a per-layout basis. (Or anywhere else that I can tell.)

To help simplify testing, I created a snippet with view restrictions set to an IP-based group and 0 second caching on a WebGUI demo site. Viewing the snipped alone (no style or other templates wrapped around it) the problem persists -- once viewed as visitor from the proper IP, it can also be viewed as visitor from other IPs.

If it is a caching issue, one of the most confusing aspects is that clearing the cache does NOT resolve the problem! If were able to see the snippet on a non-permitted IP, then cleared both the WebGUI cache and the browser cache, then reloaded the snippet in the same non-permitted IP browser, the restricted content continues to appear.

(I just confirmed this further by clearing the WebGUI cache, then opening a different browser that had never seen the snippet before on the computer with the non-permitted IP, and the content still appeared. However, reloading a few minutes later resulted in the permission denied page.)
5/12/2010 10:31 am
The Layout has a hard-coded 60-second cache for Visitors.

To be sure I understand you, when you say you "viewed the snippet alone", it was not part of a layout?

Also, between you and the WebGUI sites that you're viewing, is there any kind of proxy or cache?
5/12/2010 10:54 am
Yes, when I said "view the snippet alone" I meant to put the snippet's URL directly into your browser so that all you see is the snippet's HTML.

As far as I know, there is no proxy/cache specific to me -- the results of my testing are consistent on the U of MN network (LAN, wireless and VPN), my iPhone's 3G connection, a local friend on Comcast, and another friend checking for me from his office LAN in California.

Here is another test that suggests it is a group/session issue, rather than an asset caching issue:

1. Have ready an IP-based group that you've already used under a variety of conditions, such that content set to view by this group is visible to visitors even on computers with IP addresses where they SHOULDN'T be able to do so. This sets up whatever caching/session problem is trying to be debugged...

2. Create a new IP-based group with a random IP address that you do not have access to. This means that in testing you will never be able to view content restricted to this group when viewing it as a visitor.

3. Create a new snippet and immediately set it to be view-restricted to the second, random-IP-based group and have 0 second caching.

4. Go to a computer with an IP address that should not be able to see content in either of the IP-based groups (but which has seen content from the first IP-based group which it shouldn't have) and view the snippet directly. You will see a permission-denied page, rather than the snippet. This is as expected -- the visitor is not part of the group because the visitor is not of the right IP, and no one other than whoever created it has viewed the snippet, so it has been cached under no other usernames.

5. Edit the snippet and change it so that it is view restricted to the first group. DO NOT view the snippet from the computer that is on the permitted IP address. You want to see if the snippet is visible before it has had a chance to be cached in WebGUI. The only user to have viewed the snippet at this point is still just the account that created it.

6. On the computer with the IP that should not be able to view content restricted by either IP, reload the page, still as visitor. The snippet will appear, even though no visitor has seen the content before! This repeats the observed problem that somehow visitors from the wrong IP are able to view content restricted by IP, and further, the problem does NOT appear to be linked to caching of individual assets.

7. Change the view permissions on the snippet back to the random-IP group, and the permission denied page will re-appear for the visitor on the non-permitted computer. Although the visitor has already seen the content and has not changed sessions (presumably)  the content is no longer visible. If content were cached based on usernames only, should not the visitor continue to see the content once it has been viewed and cached under the visitor username?

You can switch the view permissions between these two IP groups all you like, clearing caches on WebGUI and the browser's end each time, and you will consistently see the content that you are not supposed to be able to see with the first group, but not the second. If this were purely a caching issue, shouldn't clearing out the WebGUI cache resolve the problem? (In other words, after you clear out the cache, shouldn't any caching-related problem/permission inconsistency go away?)
5/17/2010 0:08 am
Preliminary fix commited into 7.9 as (d2b6a7fff1dcfd289f57dd5b1ae31df7fb05fab4), considering fix for 7.8
5/17/2010 10:06 am
Started caching visitor lookups by userId AND sessionId to prevent this problem in both groups that use IP and Scratch variables.

Fixed in 7.9.5 (d99e4cc, d2b6a7fff1d)
Fixed in 7.8.20 (c3ba08b, 2412a8d)
Ticket Status Resolved  
Submitted ByTrex 
Date Submitted2010-04-30 
Assigned To unassigned  
Date Assigned2019-05-20 
Assigned By 
Severity Minor (annoying, but not harmful)  
What's the bug in? WebGUI Stable  
WebGUI / WRE Version 7.8.18  
Ticket History
3:06 PM
Resolved perlDreamer
8:45 PM
Ticket created Trex
© 2019 Plain Black Corporation | All Rights Reserved