| |
|
|
|
|
|
|
|
|
|
 |  | |
| | |
| | |
| | |
 | | |
|
|
|
| Re: Browser Back button opening up security holes??? |
|
|
Brandon, I'm not at all suggesting that we should change Firefox's default setting (which normally caches secure pages in memory) so as to make it cache the same on disk. Setting browser.cache.disk_cache_ssl to true was to confirm what Cathal said-that Firefox caches pages in memory by default and changing that to a disk cache meant that DNN was able to take advantage of that change with Authenticated Cacheability set to ServerAndNoCache doing what it was meant to do (invalidate the cache on a logout). However, this is not a solution to the problem. A viable and sustainable solution, IMHO, would be one that would enable DNN to invalidate cached secure pages stored even in memory, and the examples I'd given of other websites doing exactly that, but not DNN led me to believe that the invalidation strategy adopted by DNN is perhaps flawed and therefore needs to be reviewed. However, I'm still waiting for someone who can tell me where to set these as they may prove to be the solution(s) to this problem :-
response.Cache.SetExpires(DateTime.UtcNow.AddMinutes(-1))
response.Cache.SetCacheability(HttpCacheability.NoCache)
response.Cache.SetNoStore() |
|
|
|
| |
|
|
| Re: Browser Back button opening up security holes??? |
|
|
I think the key point here is that when you are using a machine to access your site, YOU the user is required to clear history etc to ensure 100% compliance.
With the disconnected nature of the web, the differences in browers and browser configurations, the only true way to prevent the issue you are talking about is to actually manually clear the cache and cookies.
Really it isnt much of a risk, unless you are making these changes on a public or shared PC and leaving the browser session open with full history.
-Mitchel Sellers
MCITP, MCPD, MCTS
CEO/Director of Development - IowaComputerGurus Inc.
Visit mitchelsellers.com for my mostly DNN Blog and support forum.
Visit IowaComputerGurus.com for free DNN Modules, DNN Consulting Quotes, and DNN Technical Support Services
I reccomend 3Essentials for shared hosting and BaseCamp for project management |
|
|
|
| |
|
|
| Re: Browser Back button opening up security holes??? |
|
|
Thank you, Mitch for taking the time to respond.
As far as possible, we should mitigate the issue through code or settings.
In default.aspx.vb, under If Request.IsAuthenticated = True and before the last End IF added the lines :
response.Cache.SetExpires(DateTime.UtcNow.AddMinutes(-1))
response.Cache.SetNoStore()
and now it works, thanks to Cathal. Issue resolved in Firefox!
|
|
|
|
| |
|
|
| Re: Browser Back button opening up security holes??? use |
|
|
I have a single username and password that I use for my seasonal employee's page. I have set it up that the User Profile page is (supposedly) not displayed. When the user logs in, then clicks the Browser's Back Button, they are taken back to the login screen, however, the "Logout" link now becomes a "Login" link. They can click that link and it will bring them to a page that says they are already logged in. All they need to do now is click their "Username" and they now have access to their User Profile, including changing the email address and the password. This, to me, is a security violation. If I am stating that the User Profile should not be displayed (In the User Settings) because I don't wish them to have this ability to make the changes, but now there is a way for them to get around this, that is not secure. I have had the password changed for this particular User Name two times now by a couple clever teenage employees.
Any help here would be GREATLY appreciated.
Thanks,
Mark Gordon |
|
|
|
| |
|
|
| Re: Browser Back button opening up security holes??? use |
|
|
Mark,
AFAIR the display user profile option is simply a way of ensuring that the details a user registered with can't get altered after registration. However, their username/password will always be editable (they're an intrinsic part of the user, not extended properties such as the profile). What you're talking about is "security by obscurity" rather than a security violation. Fixing that quirk would not stop the user having the ability to change their password - the user can simply provide the correct url which will validate that they have the rights to see their user details and display correctly. I would recommend that you do not share 1 dotnetnuke user across multiple actual users, that is not a very safe setup. If you need to grant access to a shared page, create a role (e.g "seasonal employee") and add users to that role.
Cathal |
|
|
|
| |
| | |
| | |
| | |
|  |
| |
|
|
|
These Discussion Forums are dedicated to the discussion of the DotNetNuke Web Application Framework.
For the benefit of the community and to protect the integrity of the project, please observe the following posting guidelines:
1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DotNetNuke.
2. Discussion or promotion of DotNetNuke product releases under a different brand name are strictly prohibited.
3. No Flaming or Trolling.
4. No Profanity, Racism, or Prejudice.
5. Site Moderators have the final word on approving/removing a thread or post or comment.
6. English language posting only, please.
|
| |
|
|
|
|
|
|
|
|