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 )
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://YourMidTier:8080/arsys/shared/login.jsp?/arsys/home So far, this is working and I can successfully run multiple sessions without them overwriting each other. (This way you can still use the resource saving functionalities of the MFP.) 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 of course is the most extreme, 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." What do you think? Is my scenario plausible? I look forward to reading (and learning) more from you all on this! :^) 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 [email protected]<mailto:[email protected]> 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. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
