I have an html page that is meant to be used in an iframe, this page makes an ajax request based on a received message (using postMessage from the parent). I can see this request using the Firefox's Network Monitor even though it is happening in the iframe. I assume all browsers have similar capabilities.
The request contains sensitive information that shouldn't be logged/saved. Is there any way to prevent this request from ever being seen (by the browser or through any other method)?
Related
Are the responses/payloads of previously made HTTP requests accessible programmatically via Javascript?
I’d like know, if in the same way hackers can use XSS to access cookies/localStorage stores in the browser, can they access data from previously made HTTP requests (since the browser DevTools has the previous requests listed and visible in the network tab).
They are only accessible if code runs before or during the request that programatically saves the response. For example, one could overwrite window.fetch and save (but pass through) all requests and responses, or do the same for XMLHttpRequest, or save the result of a request normally inside a .then or in an onload handler.
Devtools does have access to prior requests, but devtools has access to many things that can't be done via JavaScript - this is one of them.
Let's say, I'm a logged-in user in google.
Now I'd like to send one ajax request there WITHOUT sending any cookies.
(But naturally, I want to keep those cookies for the future).
How is that possible?
i'm interested in solution for ajaxing INSIDE chrome extension
important edit: I'm talking about intercepting requests sent FROM the extension itself! There the beforeHeadersSend don't work...
I have a page that makes a cross site request to another application to gather some details.
One page in the app succeeds in making this GET request. This page, by and large, just displays the details that come from that request.
Another page in the app fails to make the GET request (the browser aborts the request). This page displays the same details as the first page, but also has several additional UI elements.
The pages are from the same app, they have the same domain and protocol. The only thing different is the path of the page.
Specifically, I have:
Working Page: https://outreach.example.com/members/32234254
Failing Page: https://outreach.example.com/cases/9975
Both pages are making a request to:
https://crucible.example.com/api/members/234ABE2342349.json?token=valid_token
The Access-Control-Allow-Origin header is being returned with the value: https://outreach.example.com
The AJAX requests are identical and Fiddler clearly shows both succeeding; but IE aborts the request coming from the failing page.
In both cases, the pages have a client side UI generated by knockout.js. The biggest difference is that the page that succeeds doesn't start rendering until the request returns, while the page that fails is rendering while the request is pending.
Is the XDR sensitive to other DOM or javascript activity in the browser? The best discussion of XDR that I have found is here, but it doesn't mention anything about this. There's also nothing about this in the XDR documentation.
Are there steps that I can take to ensure that my requests are not aborted by the browser?
I would like to create a secure postMessage connection (origin safe), with an Iframe that is created at runtime.
Current state:
I have a script, that generates an iframe with a specific domain (domain.b.com in the example below). I want that iframe to receive messages only from the parent domain (the page that included my script). Since the parent domain is unknown at runtime, I'm thinking of a "Handshake" process as described and illustrated below:
Wait for Iframe to be loaded.
Send postMessage from the parent domain with it's origin.
Set the allowed origin to be the 1st received origin
Edit:
More Info:
On my server I have a whitelist domains (for example domain.a.com, any.domain.com, domain.b.com)
My Goal is to integrate with some of my clients (for example domain.a.com , domain.b.com)
Once integrated I want to prevent hackers injecting Iframes that can listen to sensitive information over postMessage
I want to avoid checking the whitelist, I prefer to give some acessToken, but not sure what is the right flow.
Example 1:
Example 2:
Is that the right way to implement it?
As mentioned here, you should not expect the parent's origin to be sent to you in postMessage's parameter. Instead:
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.
And once you have the main frame's URI in your iframe, you can verify its authorization with a simple AJAX call to the server. In my point of view, a server call is inevitable and one way or another you will make such a call.
There are other ways to know who is including your iframe but they are not relying on postMessage. For instance if you are using PHP, you can check $_SERVER['HTTP_REFERER'] to see who is requesting your iframe even before it is sent to the browser. Yet there are ways to referrer spoofing as well.
If your application requires a solid bullet proof solution then server to server communication is your way. In this scenario, each client of yours has a username and password and the web server who is going to serve the main page should ask for a one time pass token from the web server who is serving the iframe (this is a server to server communication). And then use the token in the iframe's URL to be sent back to the server generated it. Here's a step by step of this scenario:
End user asks for the URL http://customer.com/main.php.
While main.php is executing and populating the response, it also
connects to
http://you_website.com/generate_token.php?username=cutomer1&password=123
and gets a one time pass token token1.
The response is returned to the browser containing an iframe with URL http://your_website.com/iframe.php?token=token1.
In iframe.php you verify the token1 to see if it is valid, and
, at the same time, you are authenticating the requester without actually asking
for his username and/or password (since you know who you have
generated the token for).
Such tokens are usually deleted once used (one time pass) and they also usually come with an expiration data. But that's up to you and your application.
I am working on a web app that makes several ajax requests at startup. The applications works fine when ran individually, in the browser.
When running it into a iframe, one of the ajax requests returns a 302 Found HTTP status. I'm sure I'm hitting the same url with both the browser and the iframe.
The application that creates the frame is on a different domain and port.
What could be causing this? Out of 5 get requests to the same server, only one (the third) gets a 302.
The application that creates the frame is on a different domain and port.
That's why. You're making a cross-domain AJAX request which isn't allowed without special considerations.
You need to set up CORS on the server-side to allow this. See https://developer.mozilla.org/en-US/docs/HTTP_access_control