Security Issue with Logout

[J.R. Noe]

I have found an issue with security in my web app.
I can logoff fine and i get returned to the index page and the menu bar shows that i have successfully logged out. However, if i click the back button in the browser, i am not only back into the application and able to work on it, but i can now access all records, which i should not be able to do. I have it setup where the personnel can only access their own records, but once i hit the back button, i can edit, delete records of other personnel.

I thought this code would take care of it, and I am using the ATG template, although that should have nothing to do with it. This code should eliminate the permissions but how can we do a workaround with the back button. a5ws_logoutuser(session,request,response)
session.reset()
delete session.__protected__ulink
delete session.Pers_ID
response.redirect("index.a5w")

I found this by accident, and I cannot be the only one who has ssen this, so if someone can tell me how they resolved it, i would greatlky appreciate it.

Thanks

[iRadiate]

Re: Security Issue with Logout

J.R.

I came across this a while back and here's how I solved it http://msgboard.alphasoftware.com/al...highlight=back

Hope it helps,
Stephen

[waldhorn]

Re: Security Issue with Logout

As a new user to Alpha Five, I was surprised to run into the same issue last week while studying Steve Workings' videos on Alpha security system. I quickly discovered that, after logging out, one can use the back button to (1) view secured pages (2) make changes to records. Ouch.

This behavior, as I see it, breaks down into two main problems:

1 - Server-side session reuse/leakage: After calling a5ws_logoutuser(), a browser can continue to interact with the server possibly because (a) the server restarts a logged-out session when presented with a cached session cookie, (b) requests made to underlying A5 web components are not adequately checked for session state, even though A5 page requests appear to be checked, or (c) the server simply fails to fully destroy sessions when requested to do so. Or perhaps it's a combination of these or other issues.

2 - Relaxed browser caching: Alpha's web server sends back page headers that don't appear to employ a cross-browser compatible method to completely kill the browser cache and force the browser to make a new server request.

#1 appears to be a bug. I'll file a bug report and hope that it's addressed ASAP.

#2 suggests that Alpha might want to fine-tune their page caching techniques. Having poked around in this area for a few years, I've learned that it's a moving target as browser specs change. The required vodoo to address this is best left to a team of seasoned programmers/security pros who have the resource to keep on top of this. Studying how the big name sites (e.g., Facebook, Google Apps, etc) handle this might help Alpha formulate an approach. Combing through this forum, I've found several discussions on this topic--going back several years--that propose solutions of varying efficacy.

I came across this a while back and here's how I solved it http://msgboard.alphasoftware.com/al...highlight=back

Regrettably, resorting to client-side JavaScript to disable the browser's back button is a band-aid on what appears to be a server-side bug (#1). It's trivial to surreptitiously disable a specific client-side inline JavaScript using something like FireFox's GreaseMonkey (which I successfully tested), various NoScript/RightToClick add-ons, or a web debugging proxy (e.g., Fiddler or Charles). Also, JavaScript errors and the inevitable creep in browser behavior can nullify a previously-working JavaScript solution. Once disabled, the underlying server session leak problem is again exposed.

Addressing these issue is critical to ensuring that Alpha web applications are rock-solid secure in environments where multiple users share the same computer.

[Lenny Forziati]

Re: Security Issue with Logout

1 - Server-side session reuse/leakage: After calling a5ws_logoutuser(), a browser can continue to interact with the server possibly because (a) the server restarts a logged-out session when presented with a cached session cookie, (b) requests made to underlying A5 web components are not adequately checked for session state, even though A5 page requests appear to be checked, or (c) the server simply fails to fully destroy sessions when requested to do so. Or perhaps it's a combination of these or other issues.

There is no session leakage or reuse.
a) The server will NOT restart a session when presented with a cached or otherwise invalid cookie.
b) Component level security must be used in order to enforce security at this level. If you don't have it enabled, it won't be enforced.
c) Session.Abandon() will fully destroy a session. Session.Clear() will remove everything stored in a session without ending that session. a5ws_logoutuser() however does not operate on the session, only the login tokens. It is up to the application developer to determine if the session should be reset or destroyed upon logout.

2 - Relaxed browser caching: Alpha's web server sends back page headers that don't appear to employ a cross-browser compatible method to completely kill the browser cache and force the browser to make a new server request.

The "correct" headers vary greatly from application to application and even from page to page within the same application. For this reason, Alpha makes no attempt to use the "best" headers and does not claim to. This is something that can only be done with intimate knowledge of the exact application, so it is something that must be done by the application programmer.

Regrettably, resorting to client-side JavaScript to disable the browser's back button is a band-aid on what appears to be a server-side bug (#1). It's trivial to surreptitiously disable a specific client-side inline JavaScript using something like FireFox's GreaseMonkey (which I successfully tested), various NoScript/RightToClick add-ons, or a web debugging proxy (e.g., Fiddler or Charles). Also, JavaScript errors and the inevitable creep in browser behavior can nullify a previously-working JavaScript solution. Once disabled, the underlying server session leak problem is again exposed.

Addressing these issue is critical to ensuring that Alpha web applications are rock-solid secure in environments where multiple users share the same computer.

While I disagree with your claim that this is a server bug (see above), I strongly agree that client-side JavaScript is not the way to protect your application. While it can be useful as an additional layer in order to help improve the UX and reduce server round-trips, it is near-trivial to bypass/defeat and should not be used alone.

Application developers should be sure to use component level security and determine the best caching settings for the various parts of their applications.

[iRadiate]

Re: Security Issue with Logout

c) Session.Abandon() will fully destroy a session. Session.Reset() will remove everything stored in a session without ending that session. a5ws_logoutuser() however does not operate on the session, only the login tokens. It is up to the application developer to determine if the session should be reset or destroyed upon logout.

Lenny, this is very useful information. I did not find anything about Session.Abandon() in the documentation but would I be correct to place this on the logout.a5w page?
Would destroying the current user session this way prevent the user from clicking the back button and getting back into the application without logging in? Or does the browser still cache the previous page anyway? Forgive my ignorance but I can see no situation where I would want a user to logout and then be able to click the browser back button and then be able to hop right back into the application.
I do use component level security throughout but this seems irrelevant if a user can just click back and be back into the app due to browser caching.

Anyway, it seems a few of us have run across this, so for the sake of learning, can you elaborate on what is the recommended best practice to deal with this in Alpha?

Thanks again,
Stephen

[Lenny Forziati]

Re: Security Issue with Logout

Lenny, this is very useful information. I did not find anything about Session.Abandon() in the documentation but would I be correct to place this on the logout.a5w page?

This is precisely the type of question that cannot be answered without intimate knowledge of your specific application. I can try to give you some guidance and explanation, but this is not something that Alpha can address automatically and generically. Many times there is nothing of consequence stored in the session, so nothing in particular needs to be done. Other times, there is data in the session that you want to ensure continues to be available even after logout.

If you have stored something in the session and you want to remove that upon logout, you can:

1. Explicitly delete it by name (e.g. delete Session.MySensitiveData).
2. Use Session.Clear() to delete everything stored in the session.
3. Use Session.Abandon() to fully destroy the current session and create a new one.

#1 is best if you want to maintain some of the data that is in the session.
#2 is easier if you want to get rid of all session data and do not want to have to maintain a list of variables names to remove as you would have to with #1.
#3 is a bit of a sledgehammer approach because a session that has been Reset() is just as empty as a brand new one. It can be useful to implement specific protection against session hijacking though.

Would destroying the current user session this way prevent the user from clicking the back button and getting back into the application without logging in? Or does the browser still cache the previous page anyway?

Session and browser cache are completely separate. What happens when the user clicks on the back button depends on what is stored in the browser's cache and the cache settings.

• If the previously displayed page is in the cache, and the browser's cache settings do not specify that it should validate the page, the page will be displayed directly from the cache and no request will ever be sent to the server.
• If the previously displayed page is in the cache, but the browser's cache settings specify that it should validate the page before displaying it again, the browser will send a request to the server and the server will execute the page again.

If the browser never sends a request to the server, you obviously have no opportunity to change what may be displayed. This is where setting various cache directives comes into play. But only you, as the application developer, know which pages must be protected in this manner, so only you know where to apply those directives.

If the browser does send a request to the server, the security framework and your application code now have an opportunity to prevent the display of sensitive information. This requires that you identify what information is sensitive and then protect it using the security framework settings, your own code, or both.

Forgive my ignorance but I can see no situation where I would want a user to logout and then be able to click the browser back button and then be able to hop right back into the application.

I'm not sure exactly what you mean by "hop right back into the application", and application functionality varies wildly so what may be desirable for one application may be undesirable for another. If you don't want a logged out user to be able to go back and use your application, make sure you set your security to prevent that. Even if you have set caching directives to prevent the caching of the previous page, don't blindly trust that it will work and make sure that your security is properly configured.

I do use component level security throughout but this seems irrelevant if a user can just click back and be back into the app due to browser caching.

Browser caching would allow a user to redisplay a previously displayed page only. This may or may not be significant depending on your specific application (if the previous page displayed noting sensitive, there may be no harm in having it displayed again), and can be mitigated with caching directives.

However, caching would not allow the logged out user to actually execute your application. If a logged out user presses back and gets a locally cached page, any navigation, update, etc. would send a new request to the server. If that user is no longer logged in, and your application security is properly configured, they will not be able to use the application.

Anyway, it seems a few of us have run across this, so for the sake of learning, can you elaborate on what is the recommended best practice to deal with this in Alpha?

What you are really asking about is best practices in building browser-based applications using any development tool. Alpha can help with the heavy lifting of building the user authentication and authorization (Security Framework), but the application developer must still educate themselves about general browser-based security issues and mitigation techniques.

Pages that display sensitive information should have cache directives set so that they are never stored in the browser's cache. See Caching Tutorial for Web Authors and Webmasters as a good starting point.

Pages, components, and any other resources that should not be accessible to users that have not been properly authorized should be protected using the Security Framework. See Web Security Framework V10 and Web Application Security Framework for details on the specific configuration options.

It is possible to write your own application code that bypasses or weakens the Security Framework, so be sure to include additional logic to maintain protection if you do so. For example, it is fairly common to create an A5W page that allows downloads of files that are stored outside of the webroot. In a case like this, it is up to the application developer to ensure that users access only those files which they should have access to.

Application security is a broad topic which goes well beyond just caching and session management that have been discussed here. Any browser-based application developer would be very well served by spending time on educating themselves on the broader topics as well. To that end, Amazon has quite a few titles on the subject, and The Open Web Application Security Project (OWASP) is a great online starting point.

[iRadiate]

Re: Security Issue with Logout

Lenny,

Thanks for such a thorough, detailed response. Your explanation of session clearing makes sense. In terms of browser cache, I still have some learning to do.

What you are really asking about is best practices in building browser-based applications using any development tool. Alpha can help with the heavy lifting of building the user authentication and authorization (Security Framework), but the application developer must still educate themselves about general browser-based security issues and mitigation techniques.

I understand what you are saying. I have absolutely no problem doing the legwork and research required to educate myself about this stuff. In fact, I would be foolish not to learn. From my perspective however, I am a non-programmer, so even being aware of such issues let alone knowing what questions to ask can sometimes be a challenge to say the least. It looks like the links you have provided will give me the much needed nudge in the right direction, thanks for sharing them. I'm sure this will be of great help to others here as well.

Thanks again, much appreciated,
Stephen

[waldhorn]

Re: Security Issue with Logout

Lenny,

Thank you for your thorough replies on this topic. As a new Alpha user, I appreciate knowing that someone with inside knowledge of the product is available to address these type of questions.

There is no session leakage or reuse .... Component level security must be used in order to enforce security at this level. If you don't have it enabled, it won't be enforced.

You're absolutely correct. My concerns were the result of a beginner's misunderstanding.

As way of explanation: I recently purchased an Alpha subscription that includes Steve Workings' Alpha Five v11 Total Training series. In his preliminary instructions for setting up Alpha's security system (video 42), he asks the viewer to uncheck 'Enable component level security for virtual pages' (which automatically disables 'Always enforce security at component level for AJAX grids'), stating that it simplifies setup but that we may want to enable it in the future. There is no explanation that this goes against best practices or that we had just disabled a critical component of Alpha's security framework. Lesson learned.

The "correct" headers vary greatly from application to application and even from page to page within the same application. For this reason, Alpha makes no attempt to use the "best" headers and does not claim to. This is something that can only be done with intimate knowledge of the exact application, so it is something that must be done by the application programmer.

What you are really asking about is best practices in building browser-based applications using any development tool. Alpha can help with the heavy lifting of building the user authentication and authorization (Security Framework), but the application developer must still educate themselves about general browser-based security issues and mitigation techniques.

I believe that most of Alpha's customers would agree that the point of purchasing Alpha Five is to be able to design and deploy the essentials of an application quickly & securely, without needlessly delving into programming or web security research. And so the programmers at Alpha Software have indeed done a fine job of distilling the arcana of web security down to the essential choices and making them easily configurable.

That said, users of secure web applications expect that once they log out, they should not be able to browse back and view protected data-even if it is read-only at that point. That's the standard experience at any reputable web site--and should be for any out-of-the box Alpha application with the security framework enabled. From a developer's perspective, once page security has been set to require authentication, the strongest available cache busting techniques should be employed. These considerations are part-and-parcel of a complete security framework and involve complex cross-browser issues that are best addressed by the experts at Alpha, not by an audience of customers who desire fast deployment and whose target skill levels span from beginner to seasoned programmer.

Alpha already makes default page caching decisions for the user, but, clearly, they could be stronger. My suggestion is that Alpha extend this by (1) perfecting its default caching techniques and (2) mapping them to the chosen page security, with no caching for 'Requires Login' and liberal caching for 'Always Allowed'. Moving forward, Alpha would issue updates that address browser changes/eccentricities as necessary. Meanwhile, developers would remain free to cook up their own specialized caching recipes. This would immediately improve both security and the fit & finish of customers' applications.

I remain impressed by Alpha Five and by Alpha's desire to regularly release product updates and improvements. Again, thank you for taking the time to listen and provide feedback.

[Steve Workings]

Re: Security Issue with Logout

Mark - let me explain this:

In his preliminary instructions for setting up Alpha's security system (video 42), he asks the viewer to uncheck 'Enable component level security for virtual pages' (which automatically disables 'Always enforce security at component level for AJAX grids'), stating that it simplifies setup but that we may want to enable it in the future. There is no explanation that this goes against best practices or that we had just disabled a critical component of Alpha's security framework. Lesson learned.

I did this for a couple reasons:

1) These videos should be considered introductory. I do a few things throughout to try to keep the complexity down, reduce the number of things the user has to know/learn/understand to successfully work through the series. There are so many details that I choose to set aside to try to keep the production (and consumption) of that series manageable. That little app we build in the tutorials is only a start, but we think it's an important start. I'm glad you came here for more understanding.

2) I have one customer who on his own implemented a variety of component level security / field level security and such a mish-mash in a large complex project that figuring out what is where is a major undertaking. Making various decisions about what to do should be in an orderly, logical manner.

3) My own style (and this is a subjective, app-dependent choice) is to turn off component level security as one less thing to deal with. This is not to say that my practice is good or bad - but it fits what I do well, and how I build the complete application. Alpha put it there for good reason - just like so many other things I simply can't cover in any set of tutorials (I empathize greatly with the staff at Alpha working to keep the wiki up to date and explanatory). A5 is incredibly rich and deep --- you will no doubt configure many pieces of your app differently than anyone else. It's amazing (I mean this in a good way) the number of new inventions people have come up with to do things then come to me for help with this or that. I usually learn something new from each and every encounter with the customer this way.

My thanks to Lenny as well for his information here. Everyone at Alpha wants us to succeed and as you spend time here you'll wonder why you didn't show up to our party a while ago.

[waldhorn]

Re: Security Issue with Logout

My own style (and this is a subjective, app-dependent choice) is to turn off component level security as one less thing to deal with. This is not to say that my practice is good or bad - but it fits what I do well, and how I build the complete application.
....
Everyone at Alpha wants us to succeed and as you spend time here you'll wonder why you didn't show up to our party a while ago.

Thank you for your explanation and hearty welcome, Steve. Watching your videos has made for a productive start in learning A5. Many thanks! I'm also encouraged by the enthusiastic involvement of A5 users at this forum and feel that members have much to offer.

Question: What methods do you use to enforce AJAX callback security while avoiding setting component-level security? My testing indicates that without enabling component-level security, the server allows for the unlimited replaying of AJAX callbacks, even outside the context of a session.

Thanks again,

--Mark

[Larsman]

Re: Security Issue with Logout

Lenny,
Thank you for tackling this topic like I have seen nowhere else on the message board or wiki. Well Done. We here have struggled with these issues for many months, through a few applications developed. I find myself in agreement with Mark above:

I believe that most of Alpha's customers would agree that the point of purchasing Alpha Five is to be able to design and deploy the essentials of an application quickly & securely, without needlessly delving into programming or web security research....

I would only add that "[purchasers] of secure web applications expect that once [their users] log out, they should not be able to browse back and view protected data-even if it is read-only at that point."

I do not think anyone dealing with this issue expects Alpha Software to cover exhaustively all of the applications nuances that programmers can dream up. I do think that Alpha Software should provide a primer on web security issues and in particular how various scenarios can be handled with the web security features built in to A5. After all Alpha 5 is marketed to non-programmers as well as programmers. Here is a quote from previous literature "Non-programmers now can create web database applications without learning how to code. "

I think it would be great if your detailed response could be written up as an article with the appropriate A5 commands, functions, etc included along with examples of how to implement them so that the developers can make informed decisions as to where and how they are integrated into their particular application.

I think the high level of sophistication of Alpha software's in-house developers perhaps obscures the level of ignorance that some of the users are experiencing. Alpha 5 is an OUTSTANDING product! Documentation and in particular conceptual documentation and code examples is the only area where I see a real need for improvement.

Thank you for all of the hard work and commitment to keeping Alpha 5 relevant in a rapidly changing environment!

[JerryBrightbill]

Re: Security Issue with Logout

We take web security very seriously, especially since there are applications using Alpha Five in regular use that must meet very strict regulations such as HIPAA requirements. One of the features of the Alpha Five security system is that security is checked for nearly every request to the server. The only exceptions are requests to the session folder and for some system generated static items such as system images. Even requests for JavaScript and CSS files go through the web security. If you follow Lenny's suggestions and add login security restrictions to all elements including components, this is very secure as the server will prevent access to anything the user is not permitted to access based on their security role.

Destroying the session or session values is rarely needed. If login security is added to pages and components that use session variables, they can't even be opened if no one is logged in. If there is some desire to destroy the session or set values based on the current user, it is very simple to determine if anyone is logged in. The function a5ws_getcurrentuser() will return an empty value if no one is logged in. This is a very efficient function and has no speed impact.

However, as pointed out in this thread, securing server requests does not address the issues of browser caching. Caching is a great feature for static items such as images and items that don't need any security, such as JavaScript and CSS files, as it greatly increases performance. The browser doesn't have to send a request for the static item and instead pulls it out of the stored values in the local client system. But if a users clicks the back or forward browser button, most browsers will looked for a cached page to display instead of making a request to the server. Since there isn't any request to the server, security is not checked for a cached page.

Currently, the only viable solution is to try to force the browser to make a request to the server instead of using a cached local value. There are industry standard methods to prevent local caching that nearly all browsers acknowledge and accept. In the past, we have supplied a built in method that could be added to an xbasic section on a page to ask the browser to not cache - Response.NoCache(). This is very effective and has been shown to work in all common browsers. But this required the developer to manually add the command to any page they didn't want cached.

Based on the comments here, we have added a new feature to the security system. This will be available in the next pre-release build.

You will now be able to specify a property in the "Customize Options" in the web security to "Ask browser to not cache requests requiring login". This will automatically add the correct headers to any request that requires login to ask the browser to not cache the response. If the back button is used in the browser to access a page with login restrictions, the browser should make a request to the server as the page should not be cached. The server security can then respond accordingly. With this option, a developer won't have to add special command or headers to pages as they will automatically be added for requests that require checking the security role.

It is expected that caching isn't a concern if the item requested is always allowed. If caching is not desired for a page, login security can be added to the page with all roles allowed, or the page can be edited manually to add Response.NoCache() to an xbasic section on a page.

While there is no guarantee that all browsers will respond appropriately, the methods we use are industry standard and have been shown to work in all common browsers.

[J.R. Noe]

Re: Security Issue with Logout

Thank you Jerry, thank you very much.

[kkfin]

Re: Security Issue with Logout

If you have stored something in the session and you want to remove that upon logout, you can:

1. Explicitly delete it by name (e.g. delete Session.MySensitiveData).
2. Use Session.Reset() to delete everything stored in the session.
3. Use Session.Abandon() to fully destroy the current session and create a new one.

Wiki says that session.reset() in deprecated and you should use session.clear() as a replacement for future compatibility.

[Lenny Forziati]

Re: Security Issue with Logout

Wiki says that session.reset() in deprecated and you should use session.clear() as a replacement for future compatibility.

Ken, thank you for pointing that out. I will update my post to reflect Session.Clear().