Hello All, Something I hinted at earlier that I wanted to share more information about: Internet Explorer 8's new "Merged Frame Process<http://blogs.msdn.com/b/askie/archive/2009/03/13/clicking-on-the-blue-e-in-taskbar-does-not-launch-a-new-process-in-ie8.aspx>" technology will allow the latest web client login to overwrite the last, unless you take steps to stop this. (Info on MFP here, in case you can't see the link above: http://blogs.msdn.com/b/askie/archive/2009/03/13/clicking-on-the-blue-e-in-taskbar-does-not-launch-a-new-process-in-ie8.aspx - h/t to Srikanth PSS for the IE info. :^)
One of Microsoft's stated goals was to use less resources by allowing one browser 'frame' process (the object that holds the parts around the tabs) to hold multiple tab sessions, and to not create a new frame if it didn't seem necessary. The result is that if you open a web client URL and login (creating one active Remedy session w/cookies), then open a second web client URL (even in a different window) and login, the second login can overwrite the first's session. For example, here's what I can do right now on a 7.6.4 system loaded with service desk and test data I am using to test for an upgrade: 1.) Open browser window A, browse to ...login.jsp, login as "customer01" (a read-only account) - I see the IT Home page: The greeting and status bar below say customer01. 2.) Open browser window B, browse to ...login.jsp, login as "Allen" (an administrator account) - I see the IT Home page: The greeting and status bar below say Allen. 3.) Go back to browser window A now, open the 'Applications' quick menu, choose "Application Administration Console" - I see the administrator's console, and the status bar at the bottom now identifies the formerly read-only user as administrator Allen with a fixed license. From this point on, window A operates with Allen's permissions. Originally, this concerned me because it seemed to prevent a basic functionality of Remedy User that I use almost every day: Opening multiple sessions with different logins to run different processes, monitor actions, troubleshoot issues, test user access, etc. Fortunately, the link I provided above notes some workarounds: I chose the command line option and created a desktop icon for IE with "-NoFrameMerging", as such "C:\Program Files\Internet Explorer\iexplore.exe" -NoFrameMerging http://MyMidTier:8080/arsys/shared/login.jsp?/arsys/home So far, this is working - I can successfully run multiple Remedy sessions using this shortcut without them overwriting each other, and still run regular IE with MFP for everything else. Now however, my concern is that this may be a security issue as well. As I've noted above, even a read-only browser frame can be merged with another browser frame that has the highest permissions possible. It seems to me that with a minimum of security barriers, someone with a fair knowledge of HTML and Java programming could gain administrative access by: 1.) Get any login to the Remedy server - not a problem, many companies have read-only id/pws they freely distribute for self-service and the like. 2.) Create a site that a Remedy administrator is likely to browse to and have up when logging in to the Remedy server. 3.) Put code on that site that mimics the login.jsp (or calls it invisibly) using the known login, logs into the server to create a valid (read-only) session, and waits. 4.) Remedy admin logs in, the read-only session gains administrator permissions, and it can now run any number of queries or other Remedy actions for as long as the administrator is logged in. This an extreme scenario, gaining admin access and putting the server in danger. It would be even easier however to 'trojan' the larger number of regular users who have permissions to secure data (HIPAA, financial, military, etc) kept in Remedy to pull the data they have access to, and all actions would be, as far as Remedy was concerned, performed by the user during a valid login session. BMC support's answer was that "since the Mid-tier tracks session based on two cookies which exist in the context of hitting the Mid-tier server, it is unclear how it'd be possible to obtain/use these cookies via a rouge (sic) website outside of this context, not to mention somehow authenticating as an administrator." I am unconvinced by this answer as it appears to me that the read-only session does obtain and use those cookies when the frames merge as demonstrated by the ability of that formerly read-only session to conduct administrative level actions. What do you think? Is my scenario plausible? I look forward to reading (and learning) more on this issue! :^) Kelly Logan, Sr. Systems Administrator (Remedy), GMS ProQuest | 789 E. Eisenhower Parkway, P.O. Box 1346 | Ann Arbor MI 48106-1346 USA | 734.997.4777 kelly.lo...@proquest.com<mailto:kelly.lo...@proquest.com> www.proquest.com ProQuest...Start here. 2010 InformationWeek 500 Top Innovator P Please consider the environment before printing this email. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender, and delete the message from your computer. P.S.: Second posting - seems like the first was lost in the changeover yesterday. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
