Closed richardsavio closed 7 years ago
zgrossbart
commented
7 years ago Hello Richard,
Thank you for both of your bugs. I'm getting ready to take your first pull request right now.
We use the PHP to do the downloading so we don't get into trouble with the same origin policy. Do you know a way to get around that which will work with older browsers?
richardsavio
commented
7 years ago Hi Zack, I hadn't researched the problem properly. I am new to web development and didn't know of the same origin policy of browsers. From what I have read, we have a few alternatives, or we could combine them:
Use CORS. There is decent browser support. It is standards compliant and not a hack. The downside is that both the server and client must have support for CORS. It will not work otherwise.
Use JSONP. JSONP again requires server side support. We have no direct way to find out if the request succeeded except to wait for the callback to happen.
It also allows a malicious server to run arbitrary JS. But is it something we need to be worried about? I mean there is nothing to protect on the site.
Use a script tag to bypass same-origin policy. Like JSONP, but doesn't require server side support. We lose the callback function, so we will need to manually retrieve the data. It would also cause the browser to throw an error (if the response was indeed JSON), as it would interpret { as the beginning of a block of code. Will this cause an issue with the website?
Like JSONP, finding out if the loading finished without an error might be problem.
What do you think? I am not sure of how the user interaction would work if we decide to go ahead with this. Similarly, we would need a way to find out if the download succeeded when using JSONP or script tags. I am also not sure if I missed any possible security issues when using JSONP or script tags. The current approach of using a proxy bypasses them by always returning a string to work with.
What are your thoughts?
zgrossbart
commented
7 years ago Hello Richard,
Both CORS and JSONP require support from the server we're calling.
In the case of CORS that server would have to be specifically configured to supply the HTTP headers that allow requests from jsondiff.com or anywhere else the code was running. Getting every other server with JSON on it to configure those HTTP headers isn't practical.
In the case of JSONP we would still need to have the other server support us and we would have to execute the JSON in the browser which would open us up to XSS attacks.
Just using a script tag directly has even more problems. Loading random JSON would make it very difficult to get access to the JSON. In addition it would become very easy to use jsondiff.com as a vector for a CSRF attack.
These reasons are why every site that downloads data from random locations like this uses a proxy server. JSONDiff uses a proxy written in PHP because that's generally available at any hosting company.
richardsavio
commented
7 years ago Hey Zack.
I did some more reading. And yes, as you say, it would create a lot of issues. Being able to use CORS would have been ideal. But servers and browsers, both, would need to support them. And using other approaches are hacky and can make jsondiff vulnerable in various ways.
I am rather new to web development, and hadn't considered the security aspect at all when I mentioned possible solutions earlier. Thanks for writing a detailed response.
I am closing the issue.
Thanks Richard
Enabling the website to download remote JSON from the browser itself would allow the site to work completely offline. The site can also be hosted statically instead of requiring a PHP server. I would like to work on it if it is okay.