We provide a third-party site to clients. Frequently when we are handling an RFP, we are asked if it is possible to embed our site within our client's site. Many of our prospective clients have unusual limits or requests, such as 'do not use iframes'.
To that end, I've been asked to ensure that our upcoming redesign of our site makes it practical to embed in client's sites in at least two ways.
The methods of embedding a full-functioning website (as opposed to a cross-site image or piece of static content) within another are as follows:
iframe - Much used, frequently maligned, and some of our
previous RFPs have specifically excluded this as a possiblility.
Object/Embed tags - going way back, it's possible to embed a
full-functioning HTML page into another the same way you would embed
a flash object.
Ajax - Supposedly capable of loading a full
site into an HTML object (such as a div tag), but there seem to be additional security hoops to jump through, due to the dangers of cross-domain requests.
Are there other methods for placing a full site within another from a different domain? Are there any caveats or limitations to any of the above three (for instance, our site uses AJAX calls for login and to update some user-defined settings, will those all function correctly in each of the above embed strategies?) that I might be unaware of?
Thanks in advance.
X-Frame-OptionsResponse Header
If you are embedding your site to somebody else's site, you must be careful about the X-Frame-Options response header. Make sure your site does not send SAMEORIGIN as the value for X-Frame-Options. If you do, it will cause problems for iframes and embedded objects. You can do two things:
You absolutely do not send the header: Any site will be able to display your site in an iframe or as an embedded object. This can cause security problems like clickjacking. See this article for more info and defense on clickjacking.
You can make sure only the site you authorize will be able to embed your site: This is done by sending ALLOW-FROM url value for X-Frame-Options header. You can sniff the HTTP-referer to identify which site is requesting your page. This is really secure than option 1 (unless users' browsers are malicious, of course). NOTE: Not all browswers support ALLOW_FROM. See linked reference for supported browsers
Same Origin Policy
Same Origin Policy will not affect you as far as your site and your clients site do not access each others DOM.
CORS
Cross-Origin Resource Sharing should be considered if a script from your clients' website makes an AJAX request (XmlHttpRequest) to the resources in your site. But as far as your question is concerned, this is not the case, I think.
I gave an answer explaining CORS some time back, you can read it if you want to get a basic understanding of CORS.
Plugins for third party sites
It seems like you are trying to embed some functionality in clients site. Consider offering site plugins like those Facebook and Disqus does.
I am not sure if Same-Origin Policy or CORS applies here. I will find that out and get back to you.
Note: X-Frame-Options, Same-Origin Policy, and CORS is implemented by browsers. There's nothing you can do if the users browser does not implement these things, or if the browser is hacked to not respect these security policies.
Related
I've read on multiple pages that hidden iFrames are used for silent authentication, but I couldn't figure out yet why. What are the benefits to using an iFrame over directly sending a GET Request to the Identity Server?
It's a convenient way to get around the Single-Origin-Policy in the browser when we want to do cross-origin requests (across domains).
This was a popular approach when we didn't have the more modern CORS feature to get around the SOP-policy.
I am creating my own short url website 9o9.in
While a visitor hits a short url generated by my site, he will essentially hit my server first. But I know there might be several links of potentially harmful or inappropriate sites which will be shortened using my site's service.
In order to make sure that I am not not setting a negative reputation of my site in terms of SEO, by linking or http referring unaccepted sites in the eyes of a Search Engine, should I go for a server side redirect like using php header() function, or shall I do a javascript based client side redirect?
Well, I know the wiser solution is to prevent users from generating short links of unacceptable sites. But right now I can't afford to implement it, as it would require extensive amount of data analysis or using expensive word filtering APIs...
Any help is highly appretiated.
Thanks.
A server-side redirect will be lower latency, as the browser can immediately begin fetching the new page whereas, with a client-side redirect in JavaScript, the browser must continue downloading your JavaScript code and then must execute this JavaScript code. Therefore, it is in your users' best interest to use a server-side redirect wherever possible over doing client-side redirecting. And, because it is in the users' best interest, it is also in a search engine's best interest to reward such behavior (indeed, Google has publicly stated that end user latency is one of many ranking signals that is used).
On the subject, though, you may want to take advantage of the safe browsing API to help you validate the URLs to which you redirect for malware, so that you don't serve malware from these links.
I am trying to embed 3D secure and net banking pages in an IFrame, and I am able to achieve it successfully for a few sites which I have tested. But I suspect if ALL the bank pages will open in IFrame.
What if any bank has set x-frame-otpions to SAMEORIGIN or DENY?
Tried searching for a tech spec regarding this, but couldn't find anything.
Is there a common thumb rule or convention (in any spec) that an authenticating bank should/shouldn't use this header? How do I believe if this will work for all the banks?
Any clarifications would be of great help.
P.S.: I know there are other ways of opening the authorization gateways. But still, I need clarity on this approach.
You typically wouldn't just open an iframe with the bank domain. Instead you open an iframe from an outside payments' provider domain(adyen, braintree etc.) and they, in turn, open another iframe inside so that they only have to allow payments' providers iframe to communicate with it.
What's interesting that those iframes still usually have same-origin policies.
Is it possible to serve two different pages based on the user agent.
I want to serve pagename-iphone.html if the user agent matches iPhone and pagename-other.html for all other user agents. I want all pages on the site to follow this pattern. Is it possible to do this at the CDN level (cloud front, akamai etc).
thanks for your help!
I think what you are after is User Agent based caching, like vary: User-Agent.
In theory, a server provide Cache service can definitely do so, however, as far as I can tell CloudFront and most of other major CDN providers don' support so.
The basic reason is very straightforward that the currently there are too many User-Agent header, and it's almost unique on every single browser, not mention the different versions of the same browser. If you purely do things based on the whole User-Agent, you will lost the benefit of CDN cache most of the time.
Some of the more advanced servers allow you to add condition based on headers, for example, in Varnish, you can even add if,else logic for returning different values. But this is not available for majority of CDNs.
In the other hand, you should not rely on CDN to return different html pages. CDN is more commonly used to accelerate artifacts (js/css/imgs) instead of the whole page.
EDIT: Actually, I just recieved an email from AWS mentioned now CloudFront starts to support this:
Mobile Device Detection: You can now cache and deliver customized
content to your viewers on different devices (e.g. mobile vs. desktop)
based on the value of the User Agent header.
Please refers to: http://aws.amazon.com/about-aws/whats-new/2014/06/26/amazon-cloudfront-device-detection-geo-targeting-host-header-cors/ for more details.
I have an MVC application that I would like to add some custom stats to. For some of the stats, it would be nice to have a unique identifier for a device.
For example, if I have a unique id for a RSS subscriber, I can monitor the active number of RSS subscribers.
I was wondering if anyone knew of anything in the web request that could be used as an ID other than the IP (which can obviously change). Something like a device ID or something?
Here are some approaches to consider.
HTTP Headers
There are a few HTTP Headers you can look at that can help you identify a unique user or device - some would refer to the sim card, some refer to the device.
Here is a list that I derived from the headers that Google Adsense Mobile uses to help track their advertising:
x-dcmguid
x-up-subno
x-jphone-uid
x-em-uid
These are probably some very popular one's, but there would be more vendor/device specific headers that are popular. You could start gathering all the headers your site receives and count how many of each you receive and start building up your own database of common headers.
Some other approaches
Cookies
Cookies is something that can be set on the requesting agent (browser for example) and returned when the agent visits again. For a list of methods, check out Ever Cookie - the virtually permanent cookie - it works by using one of the following methods of which at least one will work:
- Standard HTTP Cookies
- Local Shared Objects (Flash Cookies)
- Silverlight Isolated Storage
- Storing cookies in RGB values of auto-generated, force-cached
PNGs using HTML5 Canvas tag to read pixels (cookies) back out
- Storing cookies in Web History
- Storing cookies in HTTP ETags
- Storing cookies in Web cache
- window.name caching
- Internet Explorer userData storage
- HTML5 Session Storage
- HTML5 Local Storage
- HTML5 Global Storage
- HTML5 Database Storage via SQLite
Combinations
It's also possible to come up with your own scheme, e.g. take the user-agent header, some other headers like accept, x-fowarded-for and the ip make a unique hash value of out them to more accurately determine the uniqueness of the agent.
There are many different mobile headers as seen here. I also hit a page of mine and store mobile headers from various devices for my own purposes here http://wap.defza.com/ua/ua.txt (also ua1.txt, ua2.txt etc)
The short answer is their isn't any (and with good reason given privacy concerns). The more helpful answer would be that this is something you would normally do using cookies. You set a cookie and then check that to identify the specific browser making the request.
Of course, this is by no means fool-proof as users can reject cookies, delete them and they can use many different browsers (each of which will have a different cookie). If you are being devious (and I wouldn't recommend this) you could use a Local Shared Object (Flash Cookie) as this is less likely to be removed. At the end of the day, though, if someone doesn't want to be tracked you can't force them to be.
Generally, though, if you want analytics and tracking then consider using a 3rd party solution like Google Analytics. This will give you very detailed data (albeit still relying on cookies and javascript) about your visitors and their browsing habits.
other than the IP
If your site doesn't require any sort of authentication in order to serve this content, the IP address is the only thing you could get to identify clients, and even this might not be unique, for example you could have two clients behind the same proxy => no way of distinguishing those requests in this case. Another possibility is to use cookies, but that sort of falls in the first category => authentication.
There is no identifier that's provided by a browser, privacy concerns make it very unlikely that any vendor would ever implement that, now at least.
The only option you have is some form of cookie.
For RSS feeds, you could conceivably embed a random unique ID in the feed URL every time its rendered, so you'd know when the person that retrieved that URL downloaded your feed. However, if the user shared that URL with others you'd have no real way of knowing.