A third party application runs within an IFRAME on our company's site. The following steps describe the process used to log in to this third patry application directly from our home page. Is this a secure process?
1. The user enters their user name and password into the form fields on our home page.
2. They click the Go button or hit the enter key.
3. The location of a hidden IFRAME is set to a secure page on our site: https://www.ourcompany.com
4. When that secure page loads (onLoad event), java script moves the user name and password from the home page form to fields in a form in the hidden IFRAME.
5. The form in the hidden IFRAME is submitted to a secure page:
https://www.thirdparty.com
This logs the user into the third party application inside the IFRAME and stores an authentication cookie from the third party application.
6. After the page loads into the hidden IFRAME indicating that the user has logged into the third party application, the onUnload event in the BODY of the IFRAME document fires.
7. That event sets the parent document’s location to a page on our site and the browser navigates there.
8. This page itself contains an IFRAME that in turn contains a page that redirects to the main menu page of the third party application: https://www.thirdparty.com
9. The user's info for the third party application then appears within the IFRAME within our page.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
i would risk saying that assuming that xss exploits have all been corrected and that everyone using said service(s) is patched is an assumption that would get you into trouble. similarly, i'm not sure i would trust a user's choices in browsing to reduce that threat. as it stands, most popular browsers have a well-documented security model regarding what is "supposed" to be allowed and is usually broken down by user policy/settings. logically an iframe embedded in a controlled page isn't going to serve any more risk that simply opening that page up, standalone. but this has been proven to be false on a number of occasions because of improper handling/parsing of domains/cookie data/etc.
take the business approach, evaluate the cost of risk, apply the likelyhood of threat, and go from there. "secure" isn't always about being impenetrable or irreversable - sometimes it's about knowing the issues and accepting them for purposes of functionality and concentrating on the means to reduce impact.
simply put, no, it's not a secure process. but what is?
No comment has been added to this question in more than 21 days, so it is now classified as abandoned..
I will leave the following recommendation for this question in the Cleanup topic area:
Accept Droby10's comment as answer
Any objections should be posted here in the next 4 days. After that time, the question will be closed.
gurutc
EE Cleanup Volunteer
Business Accounts
Answer for Membership
by: Droby10Posted on 2004-03-14 at 08:13:33ID: 10592282
there is a generic phrase that i think is appropriate....KISS. the IFRAMES do not add security and neither do the transactions between them. they only serve to add complexity, dependent of user action, which is generally not the best combination. you have ultimately described 4-5 different user/browser states for the purpose of logging in.
there is a degree of security that needs to be applied at the client level. but most of what will determine a secure login is going to exist in server-side handling of data and controls/policies for enforcement. you are using ssl which is fine for transmission of secure data. handshaking techniques in HTTP(S) are of little value because of the ease of generation. so long as you are not returning user credentials back to the browser - SSL pretty much completes the client-end security objectives in most cases (regardless of how/where those transactions actually occur in the logical web page).
you will want to focus your time/energy on server handling. ie. sql driven logins and the plague that is sql injection needs to be addressed. a password policy that enforces/defines the number of failed logins per time spec, password complexity, aging, storage procedures of those passwords (plaintext vs. hashed values), and the appropriate means to reset them. the reduction of threat that lies in login automation, typically through the use of a tertiary credential (ie. the random generated text on an image). the security of the server itself, is it patched? is it protected at a network level?