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.
Related
Please bear with me, I have only some web development experience. In the window.postmessage() documentation syntax is shown for listening for the event caused by postmessage() on the listening page. It is explicitly stated for security reasons that when the event listener is triggered, event.origin should be check to ensure it comes from an expected host. Typically done in the fashion:
if ( event.origin == somehostname.com) {}
Where I get confused is why a malicious user can't just pause the code using a breakpoint and modify the some hostname.com value. This same thing probably applies for the postmessage() call itsself as well for the target origin parameter. How does this provide any "security" when someone could just go edit the string value before it ever happens?
Your theoretical malicious user already has full access to the client-side of both websites. They don't need postMessage to access the data from either of them.
The Same Origin Policy is designed to stop a malicious website from accessing data from a different website using the credentials of the user of the browser (who has been tricked into visiting the malicious website).
postMessage can limit which origins are allowed to read the messages it sends, so if a website used it to send a message containing confidential information, it can mark the posted message as being for some-trusted-website.com which would prevent the malicious website from reading the message.
A "malicious" user could, certainly, make the client-side code do most anything they want, such as leaking information [that they already have access to] to another website, via window.postMessage or just by copying it and pasting it into an e-mail.
In your follow-up comment, you describe "we create a malicious website ready to receive some confidential info" as the threat model. That's a different thing entirely.
Yes, any website that's window.postMessage on sensitive data ought to do at least one of the following to be secure:
Check the Referer header to make sure that your parent is a trusted domain
Set targetOrigin to restrict recipients to those intended
I'm attempting to create an app with Node.js (using http.createServer()) which will be a single page application with requests for data via XMLHttpRequest. To do this I need to be able to differentiate between a user navigating to my domain, and AJAX requests and requests generated by the browser for linked resources.
If the request is from the user I always want to return the index.html page which will handle requesting content but if the request is browser generated or AJAX and is for CSS, Javascript or other linked files I want to serve those files. Is there any way to detect this?
Looking at the request headers for the different file types I saw the referer header appeared when the request for content was generated by the page. I figured that was the solution I was looking for but that header is also set when a user clicks on a link to the page making it useless.
The only other thing which seems to change is the accept header which could sort of work but might not be a catch all solution. Any user requests always seem to have text/html as the preferred return type regardless of which url was entered. I could detect that but I'm pretty sure AJAX requests for html files would also have that accept header which would cause problems.
Is there anything I'm missing here (any headers or properties I can look for)?
Edit: I do not need the solution to protect files and I don't care about users bypassing it with their own requests. My intention is not to hide files or make them secure, but rather to keep any data that is requested within the scope of the app.
For example, if a user navigates to http://example.com/images/someimage.jpg they are instead shown the index.html file which can then show the image in a richer context and include all of the links and functionality to go with it.
TL/DR: I need to detect when someone is trying to access the app to then serve them the index page and have that send them the content they want. I also need to detect when the browser has requested resources (JS, CSS, HTML, images, etc) needed by the app to be able to actually return the resource not the index file.
In terms of HTTP protocol there are NO difference between a user-generated-query and a browser-generated-query.
Every query is just... a query.
You can make a query with a command line, with a browser, you can click a link, send some ascii text via telnet, request a proxy which will make the query for you, the server goal is never to identify how the query was requested by the user.
See for example a request made by a user on a reverse proxy cache, this query will never reach your server (response comes from the cache), the first query made to build this response could have been made by a real user or by a browser.
In terms of security trying to control that the user is never requesting data by-himself cannot be done by detecting that the query is a real human click (and search google for clickjacking if you want to be afraid). Every query that a browser can make can also be played by the user, every one, you have no way to prevent that.
Some browsers plugins are even doing pre-fetching, detecting links on the page and making the request before you do it yourself (if it's a GET query).
For ajax, some libraries like JQuery will add an X-Requested-With: XMLHttpRequest header, and this is used on most framework to detect ajax mode.
But it is more robust to depend on a location policy for that (like making your ajax queries with a /format/ajax, which could also be used on other ways (like /format/json, /format/html, or /format/csv).
Spending time on a location policy based routing is certainly more usefull.
But one thing can make a difference, POST queries are not indempotent, it means the browser cannot make a POST query without a real user interaction, because a POST query may alter the state of the session or the state of the server data (but js can make POST queries, this is just a default behavior of browsers). The browser will never automatically retrieve a POST query, so you could make a website where all users interactions are POST queries (via forms or via some js altering link clicks to send POST ajax queries instead). But I'm not that's your real goal.
Not technically an answer to the question but I found a simple solution which does what I want: prefix all app based requests with a subdomain eg. http://data.example.com/. It's then really simple to check the host header for that subdomain: if present send the resource else send the index page.
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://*/*
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.
I have an application where I am displaying some stuff in javascript modals using jquery.
It requires the user to login for certain flows; but the user never leaves the modal.
So here is what we do currently.
During user flow if the user needs to be logged in, we hide the current div and show a login div
Keep a hidden iframe with Source link as that of our SSO server.
Once user submits the form, we submit the hidden iframe to the SSO server
If user gets logged in we proceed with the flow.
Problem is when there is error logging in. We need to get the error codes from the hidden iframe of the page; but because we don't control the content inside iframe, and it's returned by SSO server; we don't know how to read it since it's cross domain.
Any insights?
So long as there is not client side script being executed from the SSO party you do not need the iframe. The point of using an iframe for security is to prevent AJAX methods from ignoring single origin policy and circumventing SSL encryption. The answer is to remove the iframe. Request the SSO data from the server side and send it to the client from your server as the page is built.
You can't get around x-domain restrictions unless you use the jsonp protocol.
Could the user simply see the error response on page? Why do you have the iframe hidden atm?
Are you trying to silently log in the user to another system using the iframe technique?
Even though that might work on most browsers - some browsers won't pass cookies in i-frames - making this approach not a good broad audience solution.
Let me know if I can clarify.
Use JSONP to callback the function you prevented in your website, then in the iframe, you just need to invoke the javascript function: "parent.callback()".