Is it possible to make a cross-domain request from a Chrome extension without statically listing the domain in manifest.json (presumably by dynamically prompting the visitor for permission)?
For a use case, suppose I wanted to let visitors supply an RSS feed address, which I'd then query as part of my application's dashboard screen. I cannot list that domain in manifest.json since I clearly can't know the domain until the visitor enters it at runtime.
I'm hoping there's some mechanism for dynamically requesting access to a domain ("This extension wants to browse your data on www.example.com; do you want to allow this?")
Any ideas?
I think you'd need to specify a match pattern of: http://*/*
Related
Suppose I have a drawing html application that my users can use in their web pages. They include the widget setting its src in an iframe (with their generated key passed as query string), I send it with a frame-ancestors header to restrict use to their domain and their users can use the widget to draw.
Now suppose they want to load drawings saved on their servers and pass them to my iframe widget, and they want users to click a button (on their site) to save the current drawing on their server. In both cases, they can send a message to my iframe specifying a signed url, and my iframe can listen to the event and use fetch to, respectively, download or upload the desidered asset.
What are the security implications of my iframe downloading or uploading on their behalf? Is this setup solid or can it be abused? If it can be abused, how?
I am not sure of downloading and uploading , but it is possible to share/pass messages to and from iframe.
More details here - https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
Security concerns
If you do not expect to receive messages from other sites, do not add any event listeners for message events. This is a completely foolproof way to avoid security problems.
If you do expect to receive messages from other sites, always verify the sender's identity using the origin and possibly source properties. Any window (including, for example, http://evil.example.com) can send a message to any other window, and you have no guarantees that an unknown sender will not send malicious messages. Having verified identity, however, you still should always verify the syntax of the received message. Otherwise, a security hole in the site you trusted to send only trusted messages could then open a cross-site scripting hole in your site.
Always specify an exact target origin, not *, when you use postMessage to send data to other windows. A malicious site can change the location of the window without your knowledge, and therefore it can intercept the data sent using postMessage.
I am learning the basic knowledge of Same-Origin-Policy and cross-site-request.
The question is can I get cookies for current domain and send them to another domain by jsonp ?
For example, there are two websites. www.A.com and www.B.com.
If user login to A, there are some cookies in user's browser for A. We know that we cannot send XHR to B with cookies because of the restriction of Same-Origin-Policy. But can we get the cookies using js and send them as parameters using jsonp.
such as:
<script>http://www.B.com/xxx?cookies=REALCOOKIES ?
If I am reading this right, this is essentially how Google Analytics cross-domain tracking works. When a user clicks on a link to another domain, the cookie values are appended onto the querystring for the link which are then picked up on the other end and then turned back into a cookie (or whatever it is you want to do with it).
If you are talking about reading cookies from one domain to the other, you can do this server-side IF you have some sort of asset request that is available to both domains e.g. an image. This is (in essence) how affiliate, media banner, facebook tracking works, i.e. the concept of ads "following" you around while you are surfing (do people still surf?) the internet.
If you are the developer for both domains you could also write an api (server-side) that makes a request to domain www.A.com and retrieves the required cookies.
I've got a theoretical problem I'd like to solve. Imagine I want to reference an external resource from within an HTML document. However, I want the behaviour when following the link to vary depending on the domain of the referring page (the page with the link).
e.g.
A page hosted at http://somedummydomain.com/mypage.html contains a link to a resource http://someotherdummydomain.com/mydoc.pdf?key=123456789.
When a user clicks on the link to mydoc.pdf, I would only like mydoc.pdf to be returned (200 OK) if the referrer is somedummydomain.com - if it's any other domain then return 401 NOT AUTHORIZED. The significance of the key in the query params is that the application serving mydoc.pdf will, internally, have associated that key with the somedummydomain.com domain, thus stipulating that the resource can only be accessed via that domain.
Obviously I could check the referrer, but it's trivial to spoof the referrer in the HTTP headers so, were I genuinely trying to lock something down, the referrer header is not going to be satisfactory.
I'm kind of assuming that JavaScript would have to come into play in some way? I'm judging that based on things like the Google Analytics JS code that will only accept events occurring on a page hosted at a pre-registered domain.
Does anyone know how this type of behaviour could be achieved?
I have the main website hosted by a reliable static web hosting service. Which only allow me to host static files like html, css, js etc. Now I have few requirements which would need user Login and data storage. I think I can handle this using App Engine Python.
My app is similar to a Voting module, So i will explain it using its example.
My plan is to configure things something like this:
main website: www.example.com
appengine: gae.example.com
On the main website an anonymous user visits: http://www.example.com/vote.html, he should see current voting status (which has been retrieved from app engine). and a login button (from twitter/facebook). when he logins, he should be able to cast his vote and the vote be saved back to the appengine server.
I can handle most of the things but two. (taking same origin policy into account.)
How do I maintain authentication between two domain names. i.e. www.example.com and gae.example.com.
How do I make HTTP POST request to the gae.example.com from www.example.com and use the returned json data.
Note: I want to avoid iframes as much as possible.
You need to use JSONP.
Subdomains actually violate the same origin policy. This is because some hosted solutions provide subdomains for different users. This would allow users to attack each other's sites.
See: Same Origin Policy - AJAX & using Public APIs
You can maintain login between the two sub-domains by making sure that the login cookie is set on the root domain with subdomain access allowed. The sub-domains will be able to access the cookies of the root domain. See https://serverfault.com/questions/153409/can-subdomain-example-com-set-a-cookie-that-can-be-read-by-example-com for some examples.
I don't believe you can make ajax calls directly to another sub-domain. If the target sub-domain is cooperating and supports JSONP, you can do it that way (you end up inserting a script tag with a call to a script and that script calls you back with the data). Because the loading of scripts isn't subject to the same origin policy, you can work around it, but the target sub-domain has to be configured to allow and support JSONP.
Using javascript one cannot convert an image (hosted on a different domain than the one the javascript comes from) into a canvas.
What's the security risk with that? It can't just be to avoid phishing, right?
Same origin policy stops any remote data from being accessible by a different domain. One of the main attacks this stops is being able to circumvent a user's login by waiting for them to be logged into another site, and then piggy-back your request on their authenticated session.
Whether the data loaded is an HTML snippet, an image file or anything else, it's blocked so you can't take advantage in any way (for example, by inspecting the pixel data of an image retrieved this way)
There is one tricky attack vector connected with external images: someone can post image which will be loaded from the external resource, which they control. After some time this url can be changed to return the request for the basic http authentication. So the other users will see windows requesting their login and password. Some users, especially non-experienced ones can enter the credentials of the attacking resources which will be sent to the attacker. So be careful with external resources.