is there a function in ColdFusion that detects whether or not a browser window is the top window? (Similar to (if (window == window.top)) in JavaScript)
The reason I ask is because I would like to make certain page elements present when the page is directly accessed by the user, and not present if my page is iframed.
CFML code runs on the CF server, whereas any considerations about browser windows obviously run on the client. CF is completely unaware of the UI configuration of the client system, all it sees is "a request". Indeed the requests don't even come from the client, they come from the web server which acts as a go-between for CF-serviced requests: CF has no interaction with the client itself.
The only information the web server gives to CF that in any way relates to the client browser is some of the stuff in the CGI scope, and obviously that's limited. And none of it relates to the configuration of browser windows / iframes.
You will need to solve this with Javascript (which I will add to the tags of your question).
To trigger different code to execute on CF given a certain browsing situation, you are going to need to use Javascript to add some information to the request to identify the situation to CF. This could be adding a parameter on the query string, or something like that.
If someone was 'wrapping' one of my products I'd want to know who and how so I could improve the experience for the user and the site owner. With that in mind, what I would do is automatically break out of any frames by default. I would then create a simple api and provide instructions to other webmasters on the proper way to include your content. Display different content once you've determined if your content is PROPERLY being included in another site. For webmasters that want to include your content:
Provide recommended height/width for the iFrame so you can
include your logo or ads with the content.
Provide anything you want them to include in the query string to help track usage.
You could even add fun stuff to your api to make your content look more integrated into the including website like reacting to url.bgcolor or url.bgimage.
You could go as simple as looking for and recording the value of some url variable like url.remoteSiteAddress or as complicated as registering the site and providing unique key. Of course there are other considerations to take into account to enforce the key. Being that you don't really care that the content is being displayed on a remote site, I suspect just recording a simple url variable is more your speed.
If a different website is putting your page in an iframe on their website, then you could use the CGI.HTTP_REFERRER variable to check if the website domain is yours or not, and load content as desired.
Related
I was wondering if there's a way to add html to a webpage (from another domain) before displaying it in a iframe. Basically my idea is to make a website that allows the user to type in a website and choose or add things to the page, like copy a yahoo anwsers page and still have it function (so javascript and all still works) but the background has changed or a button that does a specific thing to the page has been added in. So far I keep running into cross domain policies and I have no idea how to get round these.
No, you cannot, this will be a massive violation of information security codes.
Imagine if someone could access your code, js and html and just alter it and access your information.
even worse, if you have sensitive information stored in the client code (you shouldn't but lets imagine), everyone across the web will have access to that information.
Displaying the webpage is one thing, you have api's for this sort of things (for example, google, twitter, facebook api's) and you pay for them too.
The reason you are running into cross domain policies is because you are not allowed to make that request. Not by JsonP and not by CORS Requests.
If you want access, look for a proper api.
For beginners, here is the Yahoo Api (Yql)
And here is it's Terms of use
Read them before you continue.
You can't do that because, if you could, an attacker could use this to exploit referred page.
Source: https://developer.mozilla.org/pt-BR/docs/Glossary/Cross-site_scripting
When I am using iframes or frames (older sites), as a extra security precaution I use the JavaScript function:
<SCRIPT LANGUAGE="JavaScript1.1">
if (top == self) self.location.href = "../index.cfm";
</SCRIPT>
then another hidden check to see if the page is being called correctly....
<cfif (HTTP_REFERER DOES NOT CONTAIN "referer_page.cfm")
<cfabort>
</cfif>
It works great to keep visitors (hackers?) from opening and/or trying to post to the page.
The problem is that the JavaScript displays in source code and the less they know...
I know the JS is client side but is there anyway to create the function in the server side CF or otherwise hide from prying eyes?
I a running cf9 on my and most of my client sites.
Thank in advance
No, it is not possible for any server side language to tell if the client that requested a page intends on displaying it inside of a frame. The only way to tell that is to ask the browser once your page reaches it.
What's the concern with the Javascript being visible?
There is literally nothing you can do to permanently avoid clients from seeing your source HTML and/or Javascript. Any attempt at security on the client side is in the end futile. You will keep out casual (i.e. non-web developer or programmer) users, but that is all. Anyone with a rudimentary knowledge of HTML and access to Google (or Alta Vista or ask jeeves for that matter) will be able to circumvent your barriers.
The use of HTTP_REFERER is suspect here as well (I know I know... I'm a negative Nellie :). That CGI var is dependent on the browser and web server working together. It will not be reliable overall because it is dependent on the client side. Someone up to no good will have no problem circumventing your barrier by simply constructing requests with the appropriate referrer.
If you want server side security then you are forced to use some form of authentication and session. This is a growing field what with oAuth and the use of Google, FB, Twitter etc as federated authenticaiton services. But plain old usernames and passwords tied to login sessions works too :)
To be clear, #Luke is saying that some users properly using your site, viewing iframe content, may have problems if they have a security setting, like an anonymity program, blocking their data, like cgi variables.
The only real solution is proper authentication and filtering on every page. If a list shows content for a user and loads details into an iframe, the iframe's page must also check that the user has access. At that point, it doesn't matter if they can get at the url.
For instance, if you get a list of user images like this.
<cfquery name="getImageList">
select imageid,imagefilename_mini
from images
where userid = <cfqueryparam value="#session.userid#">
</cfquery>
Which loads an iframe to load full sized images, you still need the and subclause
<cfquery name="getThisImage">
select imagefilename from images
where imageID = ...
and userID = ...
</cfquery>
That way, even if someone changes the image id in the url, it still only lets them see content bound to the userID.
Also, modern browsers make altering the source of a live page all too easy. I don't mean that browsers can alter the server side file, I mean that contents of the DOM as delivered to the browser. It's an incredibly useful tool for developing and debugging, but it does make mischievous/malevolent activity easier.
In chrome and firefox, you can inspect an element, change the attributes and the page will change before your eyes. Here, that works for iframe src's, so it still is within the DOM it expects to be in.
You should regard client side UI as how you'd like the page to be presented, and the way it works best but use server side safeguarding (proper validation) because it's too easy to get around client-controlled data/elements.
I have a service that I provide to different websites. For the website to use the service they implement a javascript that triggers a lightbox with a iframe in it.
The problem is I don't want any website to be able to use the service/iframe. Is there any way I can authenticate the websites using the iframe?
The way I see it, a random website can just take the javascript from a website using the service/iframe and implement it on it's own website.
Authenticating the actual users inside the iframe is no problem, there will be a login form and a register form. It's just the websites using the iframe I want to identify and authenticate.
Any suggestions is appriciated!
You could check document.referrer in JavaScript, and if the referring domain is not within a whitelist you provide (or the referrer is empty), don't display content at all.
But we all know how unreliable the referrer is, and it might exclude users even under wrong conditions.
Another way would only work it the sites embedding your iframe have server-side scripting and so can calculate some kind of hash - f.e. the hash of the current date and a secret keyword - and pass it as a GET parameter in your iframe URL. In your script, you check if the given value is the same as the hash you create with the same data - and display content based on that or not.
Using the current date could be problematic though if time zone settings for your server and the other site are different, and it might also break when a user calls the page around midnight. To prevent such problems, you could have the remote sites include the unix timestamp value used to create the hash as GET parameter as well - then you can check if that timestamp is not to old, and create the hash with that exact value. (Then other sites might try to just copy the parameters and use them on their page as well, but it will only work for a small time window.)
I have a web page which needs to do the following:
dynamically create an HTML fragment using JavaScript
open a new window
display the HTML in the new window
My first approach used document.write to copy the HTML into the window. This works in most cases, but it causes problems with Internet Explorer when the original window has set document.domain. Plus document.write tends to be discouraged these days.
So my second approach was to put the HTML into a hidden form, set the form's target to the new window, and POST the form. This means I need a script on the server to respond to the form, by echoing the POSTed content.
But this is dangerous, since someone could make a request that includes <script> tags in the content. How can I avoid the potential XSS risk? I guess I could filter out things like <script>, although that seems clumsy. If I were creating the HTML on the server, I could encrypt it, or add some token that can only be verified on the server. But I'm creating it on the client.
EDIT: Thanks for the filtering suggestions so far. I may choose to go this route, but I'm wondering: what if I don't want any restrictions on the HTML I create? Is there any way I can validate that the document was created by my page?
Try HTML Purifier.
Edit:
"Is there any way I can validate that the document was created by my page?"
Not unless you create another copy of the html server-side and compare. Anything in your script can be viewed by the user, although you can make it difficult for non-technical users. Anything that client-side Javascript can do, a malicious user can do on a Javascript console.
Even if you somehow verified that the request came from your script, a malicious user can modify your script using a Javascript console by inserting lines of code that produce a dangerous request. All GET and POST data must be treated as malicious.
Try PHPIDS.
PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application. The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to. Based on a set of approved and heavily tested filter rules any attack is given a numerical impact rating which makes it easy to decide what kind of action should follow the hacking attempt. This could range from simple logging to sending out an emergency mail to the development team, displaying a warning message for the attacker or even ending the user’s session.
Here's my problem - I'd like to communicate between two websites and I'm looking for a clean solution. The current solution uses Javascript but there are nasty workarounds because of (understandable) cross-site scripting restrictions.
At the moment, website A opens a modal window containing website B using a jQuery plug-in called jqModal. Website B does some work and returns some results to website A. To return that information we have to work around cross-site scripting restrictions - website B creates an iframe that refers to a page on website A and includes *fragment identifiers" containing the information to be returned. The iframe is polled by website A to detect the returned information. It's a common technique but it's hacky.
There are variations such as CrossSite and I could perhaps use an HTTP POST from website B to website A but I'm trying to avoid page refreshes.
Does anyone have any alternatives?
EDIT: I'd like to avoid having to save state on website B.
My best suggestion would be to create a webservice on each site that the other could call with the information that needs to get passed. If security is necessary, it's easy to add an SSL-like authentication scheme (or actual SSL even, if you like) to this system to ensure that only the two servers are able to talk to their respective web services.
This would let you avoid the hackiness that's inherent in any scheme that involves one site opening windows on the other.
With jQuery newer than 1.2 you can use JSONP
#jmein - you've described how to create a modal popup (which is exactly what jqModal does) however you've missed that the content of the modal window is served from another domain. The two domains involved belong to two separate companies so can't be combined in the way you describe.
i believe #pat was refering to this
"As of jQuery 1.2, you can load JSON data located on another domain if you specify a JSONP callback, "
http://docs.jquery.com/Ajax/jQuery.getJSON#urldatacallback