I have a website that uses IFrame in a page that loads other pages based on server side logic. So, if I do a View source, I would see something like this:
<iframe src="DeterminedOnServerSide.aspx" id="myFrame">
</iframe>
My question is - Is there any way, an attacker can change the src attribute to point other users to a malicious website considering that the src is determined on the server side?
Yes or no. You have not specified how "DeterminedOnServerSide.aspx" is determined. If your code for this consists of DeterminedOnServerSide = Server.Request["frame"] then it can clearly be 'hacked'. If you use a method that ensures only valid urls are chosen, then it is not vulnerable.
No, not unless they've compromised your server and can access and modify those source files. And if that's the case, changing of the 'src' attribute in the iframe is the least of your worries.
Yes. A XSS attack has the capability of changing the src of an iFrame.
Check it out: http://research.zscaler.com/2009/12/xss-embedded-iframes.html
The page you "include" using the IFRAME can navigate to a new page, changing the source.
Any user of the site can change the src value of the IFrame, using Developer tools like Firebug and IE Developer Tools
Any sucsessful man in the middle attack can change all your html source including the src attribute. If the attacker is in control of a proxy or network between your customer and your server they can change any of your html including the src attribute.
Any sucsessful hack into your server can change all you sourcecode and change the attribute.
What Hacker are you thinking of? you should only iframe to people/sites you trust, as this is a common way for cross site scripting attacks.
The only ways to change the src attribute of your iframe (or anything in your website) are:
The webpage which load the iframe has an XSS vulnerability and the attacker use the DOM to change it.
He (or she) get access to your source code. Then the change of a iframe attribute is your less important concern ;-)
Related
I've created a project with the moovweb sdk and have trouble editing the content within an iframe on one of the pages. For instance, moving a div around inside the iframe doesn't seem to work with the tritium I'm writing. What can I do with tritium to make this work? The domains are different FYI.
Unfortunately, Tritium only allows you to edit the attributes of the iframe itself, not the content within.
This is because the request for content in the iframe is made after the browser constructs the DOM of the main page. Tritium can only intercept the first request for the main page, not the second request for content from a different domain.
I know of two workarounds:
Add the second website as a Moovweb project and you will be able to use Tritium to manipulate the content. Then you can point the iframe of the original page to this new content.
Use JavaScript/AJAX to modify the iframe's content.
However there are implications for production domains... I'm afraid I may have rushed this answer and will update it after I do more research.
If the iframe is on the same origin (http://m.yoursite.com) or on an origin you have in your config.json you can absolutely use tritium! However, maybe not in the way you expect!
So, the iFrame is going to make a separate request to the src attribute's location. If you ensure this request is going through the SDK (by rewriting it) like so:
$(".//iframe[#src]") {
attribute("src") {
rewrite("link")
}
}
Then you can map that url and perform your regular tritium on it!
you need to analyses the src of iframe and need to write mapping in mappings.ts for the url in src. Include proper .ts file in pages folder and start transforming it.
How to add Open Graph properties to an iframe?
For example, this is a Facebook "Like" button generated by default by prettyPhoto (lightbox-like jquery plugin for displaying full-screen images):
<iframe src="//www.facebook.com/plugins/like.php?locale=en_US&href=http%3A%2F%2Fexample.com%2F%23prettyPhoto%2F2%2F&layout=button_count&show_faces=true&width=500&action=like&font&colorscheme=light&height=23" scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:500px; height:23px;" allowtransparency="true"></iframe>
This code has the following problems:
in practice, it Likes the page http://example.com instead of the
dynamic photo page (which is http://example.com/#prettyPhoto/2/)
It shows title and description from page http://example.com instead of the dynamic photo page
The http://developers.facebook.com/tools/debug tool, when I pass my dynamic image page address to it (http://example.com/#prettyPhoto/2/) tells me that:
Inferred Property: The 'og:url' property should be explicitly provided, even if a value can be inferred from other tags.
Inferred Property: The 'og:title' property should be explicitly provided, even if a value can be inferred from other tags.
Inferred Property: The 'og:description' property should be explicitly provided, even if a value can be inferred from other tags.
Will setting those properties help to have the correct url and description for the image? How to insert those properties into the "Like" button iframe? For example, let's assume that the og:title is "My super image". How should the mentioned above iframe code look like with this property set, where to put it?
How to add Open Graph properties to an iframe?
Not at all, of course.
Those properties are put into the HTML code of URLs delivering HTML documents; the “iframe” has nothing to do with it whatsoever.
This code has the following problems:
in practice, it Likes the page http://example.com instead of the dynamic photo page (which is http://example.com/#prettyPhoto/2/)
It shows title and description from page http://example.com instead of the dynamic photo page
Those are not problems of the like button code, but of the site at http://example.com.
The hash part of an URL has only client-side meaning – it does not even get transferred to the web server at all. So http://example.com/#prettyPhoto/2/ and http://example.com/ are the exact same URL, from the web server’s view (the server serving example.com). So it will deliver the same data for requests to “both” of those URLs, and that is totally not the like button’s or for that matter Facebook’s fault.
It is most likely the fault of the noob who set up that page on example.com using fancy AJAX an’ stuff, thinking that’s cool and whatnot, but lacking basic knowledge about the techniques involved at the same time.
Will setting those properties help to have the correct url and description for the image?
No; not until the matter of making the individual contents of the site available under individual URLs is not resolved first.
I am using WebRequest to retrieve a html page from the web and then displaying it using Response.Write.
The resulting page looks different from the original mostly in font and layout.
What could be the possible reasons and how to fix it?
Most probably, the HTML you retrieve contains relative URLs for loading images, stylesheets, scripts. These URLs are not correct for the page as you serve it from your site. You can fix this by converting all of the relative URLs into absolute URLs or by including a BASE tag in the head of the HTML, pointing to the URL of the original page.
Be advised though that deeplinking to images and other resources is considered bad practice. The source site may not like what you are doing.
The reason might be that the original html page contains relative (to the original site) paths to the stylesheet files so when you render the html in your site it cannot find the css.
Does the remote web site include CSS, JavaScript, or images?
If so, are any of the above resources referenced with relative links (i.e.: /javascript/script.js)?
If so, when the browser receives the HTML from your server, the relative links (which were originally relative to the source server) are now relative to your server.
You can fix this by either changing the HTML to use absolute links (i.e.: http://www.server.com/javascript/script.js). This is more complicated than it sounds: you'll need to catch <link href="..."/>, <a href="..."/>, <form action="..."/>, <script src="..."/>, <img src="..."/>, etc.
A more limited solution would be to place the actual resources onto your server in the same structure as they exist on the original server.
The remote site might look at the User-Agent and serve different content based on that.
Also, you should compare the HTML you can retrieve from the remote site, with the HTML you get by visiting the site in a browser. If they are not different, you are probably missing images and/or css and javascript, because of relative paths, as already suggested in another answer.
I'm trying to execute an HTTP GET from my website to another website that is brought in via iframe.
On Firefox, you can see in the source that the correct url is in the iframe src along with it's correct parameters-- and it works.
On IE, you can see in the source that the correct url is in the iframe src along with it's correct parameters-- and it doesn't work...
Is there something about IE that doesn't let you pass parameters through an iframe in the querystring?
I've tried refreshing the iframe in IE, I've tried refreshing my page & the iframe in IE, and I've tried copying the url and re-pasting it into the iframe src (forcing it to refresh as if I just entered it into the address bar for that iframe window). Still no luck!
Anyone know why this is happening, or have any suggestions to try to get around this?
Edit: I cannot give a link to this because the site requires a password and login credentials to both our site and our vendor's site. Even though I could make a test account on our site, it would not do any good for the testing process because I cannot do the same for the vendor site. As for the code, all it's doing is creating the src from the backend code on page load and setting the src attribute from the back end...
//Backend code to set src
mainIframe.Attributes["src"] = srcWeJustCreated;
//Front end iframe code
<iframe id="mainIframe" runat="server" />
Edit: Problem was never solved. Answer auto accepted because the bounty expired. I will re-ask this question with more info and a link to the page when our site is closer to going live.
Thanks,
Matt
By the default security settings in IE query parameters are blocked in Iframes. On the security tab under internet options set your security level to low. If this fixes your problem then you know that is your issue. If the site is for external customers then expecting them to turn down their security settings is probably unreasonable, so you may have to find a work around.
Let's say your site is www.acme.com and the iframe source is at www.myvendor.com.
IIRC, most domain-level security settings don't care about the hostname, so add a DNS CNAME to your zone file for myvendor.acme.com, pointed back to www.myvendor.com. Then, in your IFRAME, set the source using your hostname alias.
Another solution might be to have your Javascript set the src to a redirector script on your own server (and, thus, within your domain). Your script would then simply redirect the IFRAME to the "correct" URL with the same parameters.
If it suits you, you can communicate between sites with fragment identifiers. You can find an article here: http://tagneto.blogspot.com/2006/06/cross-domain-frame-communication-with.html
What BYK said. I think what's happening is you are GETting a URL that is too large for IE to handle. I notice you are trying to send variable named src, which is probably very long, over 4k. I ran into this problem before, and this was my code. Notice the comment about IE. Also notice it causes a problem with Firefox then, which is addressed in another comment.
var autoSaveFrame = window.frames['autosave'];
// try to create a temp form object to submit via post, as sending the browser to a very very long URL causes problems for the server and in IE with GET requests.
var host = document.location.host;
var protocol = document.location.protocol;
// Create a form
var f = autoSaveFrame.document.createElement("form");
// Add it to the document body
autoSaveFrame.document.body.appendChild(f);
// Add action and method attributes
f.action = protocol + '//' + host + "/autosave.php"; // firefox requires a COMPLETE url for some reason! Less a cryptic error results!
f.method = "POST"
var postInput = autoSaveFrame.document.createElement('input');
postInput.type = 'text'
postInput.name = 'post';
postInput.value = post;
f.appendChild(postInput);
//alert(f.elements['post'].value.length);
// Call the form's submit method
f.submit();
Based on Mike's answer, the easiest solution in your case would be to use "parameter hiding" to convert all GET parameters into a single URL.
The most scalable way would be for each 'folder' in the URL to consist of the parameter, then a comma, then the value. For example you would use these URLs in your app:
http://example.com/app/param,value/otherparam,othervalue
http://example.com/app/param,value/thirdparam,value3
Which would be the equivalent of these:
http://example.com/app?param=value&otherparam=othervalue
http://example.com/app?param=value&thirdparam=value3
This is pretty easy on Apache with .htaccess, but it looks like you're using IIS so I'll leave it up to you to research the exact implementation.
EDIT: just came back to this and realised it wouldn't be possible for you to implement the above on a different domain if you don't own it :p However, you can do it server-side like this:
Set up the above parameter-hiding on your own server as a special script (might not be necessary if IE doesn't mind GET from the same server).
In Javascript, build the static-looking URL from the various parameters.
Have the script on your server use the parameters and read the external URL and output it, i.e. get the content server-side. This question may help you with that.
So your iframe URL would be:
http://yoursite.com/app/param,value/otherparam,othervalue
And that page would read and display the URL:
http://externalsite.com/app?param=value&otherparam=othervalue
Try using an indirect method. Create a FORM. Set its action parameter to the base url you want to navigate. Set its method to POST. Set its target to your iframe and then create the necessary parameters as hidden inputs. Finally, submit the form. It should work since it works with POST.
The web dev toolbar for Firefox is quite an impressive tool.
What I am completely clueless about is how does this tool get the css stylesheet file of a site? This is hosted on a host which is secure etc. I am completely stumped.
I must be thinking about this in all the wrong way.
Thanks
The client (in this case Firefox) has to download the CSS file in order to render the page correctly. The plugin (in this case Firebug) simply requests the proper URL and the browser it gets it--most likely from the cache. There is no real mystery here.
In every HTML file, there's a link to the CSS stylesheet, or else the browser wouldn't know where to find it, thus losing the ability to render the page correctly.
It's in the form of <link rel="stylesheet" type="text/css" href="theme.css">,
I'd like to add that regardless of whether the host is 'secure' or not, it still is presenting the file to the client.
Unless, of course, you're looking at a XML file. Then you need to consult the XSL which'll tell you where the stylesheet is.