Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Wait for a frame to load tecnique 2

Status
Not open for further replies.

Diancecht

Programmer
Jan 8, 2004
4,042
ES
Hi all.

I'm facing the common problem of waiting for a frame to load. The url loaded in the frame is external, so no chance to use the onLoad event of the second frame.

I've been searching for sollutions in this forum and in the outer dark space and I must admit I'm a little dissapointed.

What I've found is the sollution is just entering a loop with some delay and check if the frame is loaded examining the content of the frame.

So I have two questions:

1.- Is there a more elegant way that I was not able to find, any event, any way to add a listener or maybe a wizard's spell?

2.- If not, which would be the best way to check, the end of body tag, if the location type is still undefined, maybe if the sky is blue?

I should remark that my objective is not showing the page to the user but have it cached by the browser.

Thank you.

Dian
 
It has occured in the past that a URL has been illegally redirected. If a scammer managed to redirect a url like to their own URL but then loaded the actual citibank.com web site into their own frame the client would have no way of knowing their data had been captured. Sure the same could be done with a bogus login page but then the user would fail to actually get into the system after what should have been a successful login and that would start triggering alarms for people.

Another problem would be when people provide links from their web site to another web site. Everyone does this and it is often encouraged as a way to get more traffic to various sites so nobody is ever suspicious of links from one site to another. It is also easy to spoof the data that appears on the Status bar of the browser so when someone hovers over a link on the page it shows what appears to be a legitimate URL for the link in the status bar but the real link redirects them through a frame that loads the legitimate page but inside of a frame. If that happened and security was not in place then all the content in that frame is vulnerable, the client is seeing the legitimate page from what seemed to be a legitimate link and has no suspicion that their data is now accessible to someone with ill intent.

There are lots of ways something like this can be used for ill which is why cross site scripting is locked down the way it is. I could not even begin to guess at all of the potential ways it could be abused. But it does not have to be one hacked site making the rest vulnerable. Security should never involve trust that other web sites are making the correct and best efforts to protect you. One sites vulnerability should never lead to the compromise of data for other sites.

Sure, people can always be scammed with bogus pages, surreptitious redirections, etc. But those methods rely on trickery and gullibility not necessarily flaws in the programming environment leaving security holes.

How long have email scams been going on where an email claims to be from a credit card company telling you that your account needs to be verified and "Click Here" to login only to direct that person to a bogus login page and steal their data? That has nothing to do with security holes or the compromise of a web site, just lying to people and counting on their gullibility. And after this has been going on for YEARS people are still falling for it by the thousands because they JUST DONT THINK.
You cannot protect people from themselves but you can work to protect them from others and that is the reason behind the cross site scripting security.


Paranoid? ME?? WHO WANTS TO KNOW????
 
We've suffered a similar attack as CityBank, but in this case, the user was redirected to a bogus login page, the info was submitted to the cracker and then the user redirected again to the true login page with an "username and password" don't match.

The user entered them again, everything worked, no one suspects.

I get the point of the non-cross scripting, just hoping it's closed any door that now cannot be opened.

From the examples and what I've been thinking, it just closes a door, but the window is still open.

Thank you for your time and effort.

Cheers,
Dian
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top