It's not a security issue cause you can only view the information if you / your users visit the site --> go into sensitive information --> log out and leave a public computer without closing internet browser or clearing the browsers cache. Its not DNN caching causing it its the client's browser. As you point out the second you try to make any call to the server you get shut down instantly. Keep in mind any webpage is just html / javascript that is it. Every time a page is loaded into a browser by default it caches that page for x amount of time. This is to allow the back button to work without having to constantly reload the information.

Like I said its only a slight security risk if you are on a public machine and logout and then don't close internet explorer. Otherwise its not a security issue. I checked the DNN site it does the same thing as your site does. With displaying the profile information even though I logged out. They just have a warning message stating you are not authorized to edit this user. There are a billion different ways they could have added that line.

Sorry, but I'm still not convinced that this is not a security issue. For one, I fail to understand how displaying a user's email address or displaying DNN Authentication Settings when the back button is clicked after logout cannot be considered a security issue. At the least, can it be considered a "sensitive information disclosure" issue?

To be specific (at the cost of sounding repetitive), this is what I observed on the DNN site :

After logging in, clicking on my username took me to my user profile Page. Leave that alone, now log out, I am directed to Preferred User Information page (although why I'm directed to this page is beyond my understanding-I expected to get redirected to the home page or login page). Leave that as is. Next, I click on my browser's Back button. I am shown the Home>User Profile page. My username and "Logout" link are clearly visible along with my User Name, First Name, Last Name, Display Name and Email Address. I click on my username and I am again shown Preferred User Information page! Again I click browser Back button. On the User Account page, when I hover over Manage User Credentials, I realize that its not clickable (supposedly because I'm already in the User Credentials). When I click on Manage Password, I can see the warning message "You are not authorized to edit this user." but the Change Password Section is also shown with blank textboxes (although why this was also included is beyond me-I expected just the warning). Next, I click on the browser's Back button. I'm in the home page- at last!- did the browser's cache expire at this point? No, I believe not, because when I click again on browser's back button, I am shown the login page!

IMHO, this is erratic and out-of-context behavior and discloses sensitive information.


Cathal, in the post you referred to you said, and I quote :

"...with ServerAndNoCache being the one that was hardcoded into DotNetNuke."

Sorry, but in my case this was not the default. In my case it was ServerAndPrivate. May I know what are the differences between the various options in the Authenticated Cacheability drop-down. For e.g., what is the difference between ServerAndNoCache and simply NoCache? Alternatively, where can I find the detailed description of these options?

Again, I quote your post :

"...it's actually a security best practice. It ensures that if you log out, no-one can access your previous pages by pressing the back button, or viewing the temporary internet files."

Exactly! the point I'm trying to make is that this didn't work in my case or for that matter in DNN site's case, despite the host performance settings I mentioned. The back button still displayed my previous page!

Of course, I do not know what the settings in the DNN site were, but it looks like even with the same settings, it wouldn't purge the browser's cache.

I've seen many sites that do not exhibit such erratic and out-of-context behavior as detailed above. Some of them use a JavaScript function like history.go(1); to disable the browser's back button. Others may be implementing other techniques. Now, I cannot buy into an argument that says "JS can be disabled on the browser", because DNN relies on JS being enabled anyway!

And as for the statement "There is no logic to redirect you to the homepage for unautheticated requests, it should simply redirect you to a login screen - this is needed as users will receive a link to a page that is not public, so they should be presented with a login page and once succesfully logged in then the login page can redirect to the correct originally requested page" , I agree that this is how DNN behaves when an unauthenticated user tries to access a secure page or function which requires a login. That is perfectly acceptable. What I was trying to say is that once a user is logged out it is better (if possible) to redirect him to the home page or login page when he tries to click the browser's back button.

What I'm looking for is for a way to circumvent this issue, and will be happy of others can chime in and give me some tips. After all, DotNetNuke is about Community, Content and Collaboration. C'mon, guys!