Within my app (http://www.example.com) I am running an iFrame (https://www.example.com/iframe-application).
The main page (www.example.com) only renders custom data based on cookies set by the iFrame. The iFrame has all the smarts, the Javascript, the secure cookies, etc. The iFrame has NO text, images, etc. only javascript code.
Is there any risk that someone would embed the iFrame in another site and access secure cookies, login tokens, etc?
By default cookies are bound to the domain name, so in normal case that should not possible.
If you got a XSS Vuln. on your site, he could access the cookies, so rather be sure to escape all Inputstrings.
That would be a cross-site scripting attack and most browser will prevent it unless the user has configured them not to.
Related
I have an iframe, says it's hosted at example.com, and I want siteA.com and siteB.com to have the same cookie, I plan to embed iframe (example.com) into siteA and siteB, is that possible? As I know cookie is per domain only.
It depends on if you control siteA and siteB. If you cannot make changes to them, this is not possible.
Otherwise, you can leverage two way iframe communication to send siteA / siteB a message with the cookie value, which you then write.
I am setting the cookie from a local HTML file as below using cookie.js library
$.cookies.set("Demo","Dummy Data");
From another domain I am trying to get the cookie value using below code
alert($.cookies.get("Demo"));
But it is returning me null.
Please help me on this
This is by design. You can only get the value of a cookie which was set on the current domain.
What you are asking for is not possible due to the security measures built in to web browsers.
The best alternative is to make a JSONP AJAX request which can cross domains.
You can not read a cookie set by another domain.
Take a look at this thread about cross-domain cookies:
Cross domain cookies
Basically, this is a security feature. If domain.com set a cookies, domain1.com should not have any access to it, otherwise you could get authentication tokens and other stuff for any website.
Unfortunately, it is returning null because cookies from another domain are not accessible. This is a security feature.
Consider, for example, your session cookie for some website. If I could access that cookie via JS on another domain, then my malicious website (that I trick you into visiting), can then take that session information and give it to some hacker. Then it becomes much more likely that the hacker can hijack your session. All too commonly, there are not other measures in place to make sure that the session used is used by the same person, so all a blackhat needs is the ID and voila - total access as you to the website. Say you're logged into your bank on one window, and then have my hacked evil webiste open in the other... now I might be able to access your bank account. Whoops!
So - it's not possible, and for good reason!
Indeed, this is not possible because of SOP (Same Origin Policy).
You can solve this problem with cross domain methods like: postMessage, JSONP, xmlHttpRequest or iframe to name a few.
However, you have to be concerned about security issues. This podcast explain how to breack cross domain barrier. The posts below also have solutions for your problem.
Stackoverflow Posts
How do I set cookies from outside domains inside iframes in Safari?;
Resizing an iframe based on content;
A recommendation for being able to include a csrf prevention token in ajax calls is to include them as a meta tag in your page, which can then be accessed and included in the header.
http://docs.spring.io/spring-security/site/docs/3.2.0.CI-SNAPSHOT/reference/html/csrf.html
How is this not exploitable? For example if example.com included the csrf token in a meta tag, could I not just create a malicious site that has some javascript that will make a call to example.com, and then parse the response, find the meta tag, and then inject the token value into my malicious page form?
The CSRF token is unique to each session. Once it's generated it is only valid for use once, tied to a specific session.
A malicious person could get one generated, but it would be specific to their browser session. In short, they would only use it to be able to exploit themselves.
As for generating an attack through JavaScript, it's really an issue separate from CSRF. CSRF is an attack like this one from Wikipedia:
<img src="http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Mallory"/>
Protecting against malicious JavaScript is a different story. Sites protect themselves from XSS and other types of JavaScript injection by scrubbing user input, iframe sandboxing, and relying on the same-origin policy.
TL;DR
If you're running other people's untrusted JavaScript in your site, then you have bigger problems than CSRF.
A script running in Alice's browser at chuck.com cannot read carol.com's content due to the http://en.wikipedia.org/wiki/Same-origin_policy .
The script on chuck.com can POST to carol.com, but it cannot read and parse its content.
I have a web app http://embed.myapp.com that is intended to be embedded on a few whitelisted sites. The frame access is controlled with X-Frame-Options ALLOW-FROM
However, I do not want users to access it by putting in the above link directly in the web browser.
What is the best way to block plain (non-embedded) access?
I can determine whether the site is embedded with javascript, but by that point a session is already created and certain sensitive information such as CSRF tokens can be seen.
You may not quite get an absolutely foolproof way of stopping users from looking at the content directly.
A simple way to catch most cases would be to look at the referer header ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.36) on the server side and only serve the content when it is referred from the correct pages.
I am developing a web app that is served from domain.ext. This web app uses cookie–based sessions and provides users with the ability to host a web pages containing custom JavaScript on a subdomain, ex. sub1.domain.ext, sub2.domain.ext. The subdomains do not use cookie–backed sessions.
Given this setup, is it possible to ensure the following?:
users at sub1.domain.ext cannot read or write a cookie for domain.ext (i.e. domain.ext sessions cannot be stolen or hijacked by JavaScript embedded in a page at sub1.domain.ext).
JavaScript embedded in a page at sub1.domain.ext cannot read or write cookies at sub2.domain.ext, and vice versa.
I’ve tested out a few things, for example it appears to be possible to interact with domain.ext’s cookies from sub1.domain.ext by running document.domain = 'domain.ext' inside the sub1.domain.ext’s window. Is there some way to prevent this, for example by specifying some kind of policy when setting the domain from domain.ext?
You can't specify that a cookie should only be valid for example.com by setting the domain parameter. If you set domain=example.com, it will be valid for *.example.com.
Setting a cookie on example.com without a domain parameter sets a cookie for only example.com in most browsers. But not IE.
So, if you ever want to have subdomains with separate cookie contexts, you should serve your site from www.example.com only. As Gaby said, naturally you can still support access through example.com by giving a 301 redirect to the www version.