I'm trying to make a fetch to my API hosted locally from my GitHub page, but I can't due to the mixed content error. Is there a way to get around it? I'm not sending sensitive information or whatever and I don't need a response.
You need to either use HTTPS or HTTP across the board. You can't use half one and half the other.
I'm not sending sensitive information or whatever
HTTPS is not just about the encryption of the information, but also to ensure that you're connected to an authorized server. There are many ways connections get hijacked... including broken public WiFi access points with captive portals. In any case, the browser vendors don't give us much of a choice these days.
Related
First, let me start with, I understand JavaScript can be tampered with so I'm not looking for a fool-proof solution. I have a public API that takes requests from external web applications. Sometimes the web applications are directly hitting our API and other times they jump through another API offered by some of our Partners.
In a partner scenario, we want to ensure the API requests are ultimately coming from specific URLs. My idea is this:
We're allowed to offer a script that the webapps can add to their sites so I was thinking we can set up an API Endpoint whose job is to capture the request, verify the origin (URL), and spit out a token that they must ultimately send later with the real API request through the partner API.
Is there a better approach or am I just really limited to the origin header to find out the website? I was hoping there were additional data points I can leverage on the client side to verify the traffic is coming from a specific URL
I'm using Google Firebase, and unfortunately, Google Firebase put some countries under sanctions which means they must use a proxy (or VPN) to access the website.
Is there any way I can set a proxy setting for each client request that they can freely access Firebase without a VPN?
I know there are options for Node.js, but I'm looking for a web browser solution. Firefox has this proxy settings, and Google Chrome also has some options for extension developers, but I need a solution that works just in a web page, and it means when a user comes to my website, he/she does not need to set a proxy to access Firebase.
Example: when a user comes to my website from (for example) Syria or Sudan, they don't need to set VPN for their browser, because I have done some proxy configuration in my website
Short answer: You can't do it website-only.
Longer answer / explanation:
I know there are options for Node.js,
Good... that could work. Deploy your own Node.js server on Heroku or the like, which proxies requests to Firebase.
but I'm looking for a web browser solution. Firefox has this proxy settings, and Google Chrome also has some options for extension developers, but
This could work too, but as I'm sure you've considered... that would rely on the end-users installing those extensions before attempting to visit your site.
I need a solution that works just in a web page,
Nope. Not possible. The Google servers will not respond to any request coming from a sanctioned country. If a request comes from a disallowed country, the Firebase servers won't respond with your website - instead they respond with a 403. Firebase won't send the website. Your website won't be sent to the client. It doesn't matter what your website contains, it will never be sent to those end users in the first place.
Even if you host the site elsewhere, and just use the Firebase database, it still won't work - for the same reasons. When the Firebase servers receive the request from a browser running in a sanctioned country, they respond with 403.
The question then becomes: How to make the request appear to come from outside the sanctioned country, from the website only?
You can't, not when you only control the website itself. That part of the request/response cycle is, for end-user protection purposes, handled by the browser. Browsers do not expose that functionality to webpages.
If you want to handle everything for your users, without them needing a VPN (desktop, or browser), your only choice will be to send the request to a different non-Google server (such as a Node.js server you host on Heroku or the like), which then makes the request to Firebase on their behalf, gets the response, and responds back to the client. That way, to the Firebase servers, it looks like the request is coming from X* location.
*X: Where ever the Heroku server is running.
I have a WebApp(PHP) to which the user sends requests to my server, it processes this data and queries on a social network and returns the information to the user.
But I'm having problems where social networks are blocking the IP of my server because of the volume of queries.
Below is my current flow:
I would like to know if there is a way to return this information to my user's browser and make queries from his computer, since it is a new and residential IP.
I do not know if you can make a proxy server with websocket where you would use the user's machine to send the requests.
Here is the flow you want:
Maybe have some way using websocket with a node.js server.
Thank you very much in advance.
You cannot use a client side proxy as such. Protocols built on top of connection-oriented(TCP) protocol will need a valid IP to get response. Establishing a two-way connection will become difficult once you send different request IPs. Even if you are able to do this by some kind of IP spoofing, which I am unaware of, you'll most likely will not be able to have the solution at scale for your app's users.
The best known method would be to use some kind of desktop based solution for such problems and thereby having organic request IPs. If that is not what you want, then you can use proxy servers, that might even be good if you have fewer users, but that might not scale.
Let's imagine the following situation.
I have a website mysearchengine.com and then I use search suggestions from external sites, for example eniro.no:
http://map01.eniro.no/search/search.json?q=de&index=yp_sug&profile=pl&pageSize=10&callback=C
Does eniro.no can see that their JSON is requested from website mysearchengine.com?
My issue is that I want to use some JSON resources of another (not my) server and I wonder if it is seen for them that I'm doing that?
The above is only an example, easiest I found to show my question about how JSON works.
Yes, in one of two main ways:
HTTP Referrer Header:
http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z14
Direct IP address logging: If they log your IP address, they could potentially do a reverse lookup to find your web address. Alternatively, if you are under a shared IP, they may just block your IP address if you are abusing their web resources.
Note: You can choose whether to pass the referrer header or not. It is up to your server. However, there is no way to mask what computer/server requests the remote resource (yes, using a proxy they will be able to tell that the proxy's IP requested the resource, but that is beside the point).
Are you looking to have a user click a button on your site, and your site will make a GET request, in javascript, to another site, and then put content on your site? That's called Cross Origin Resource Sharing (CORS).
If you're controlling the javascript, you can insert additional headers into the request, and since it's the user's browser that's making the request, the site will only see that user's information, not your site's.
Besides that, the answer by Andrew M. is correct, based on the browser, there will probably be a referred header sent, and I am not sure you can get rid of it through JS.
We have a "widget" that runs on 3rd party websites, that is, anyone who signs up with our service and embeds the JavaScript.
At the moment we use JSONP for all communication. We can securely sign people in and create accounts via the use of an iFrame and some magic with detecting load events on it. (Essentially, we wait until the iFrames source is pointing back to the clients domain before reading a success value out of the title of it).
Because we're running on JSONP, we can use the browsers HTTP cookies to detect if the user is logged in.
However, we're in the process of transitioning our system to run realtime and over web sockets. We will still have the same method for authentication but we won't necessarily be making other calls using JSONP. Instead those calls will occur over websockets (using the library Faye)
How can I secure this? The potential security holes is if someone copies the JavaScript off an existing site, alters it, then gets people to visit their site instead. I think this defeats my original idea of sending back a secure token on login as the malicious JavaScript would be able to read it then use it perform authenticated actions.
Am I better off keeping my secure actions running over regular JSONP and my updates over WebSockets?
Websocket connections receive cookies only during the opening handshake. The only site that can access your websocket connection is the one that opened it, so if you're opening your connection after authentication then I presume your security will be comparable to your current JSONP implementation.
That is not to say that your JSONP implementation is secure. I don't know that it isn't, but are you checking the referrers for your JSONP requests to ensure they're really coming from the same 3rd-party site that logged in? If not, you already have a security issue from other sites embedding your javascript.
In any case, the 3rd-party having an XSS vulnerability would also be a very big problem, but presumably you know that already.
Whether you are sent cookies during opening WebSocket handshake by browser (and if so, what cookies) is not specified by the WS spec. It's left up to browser vendors.
A WS connection can be opened to any site, not only the site originally serving the JS doing the connection. However, browsers MUST set the "Origin" HTTP header in the WS opening handshake to the one originally serving the JS. The server is then free to accept or deny the connection.
You could i.e. generate a random string in JS, store that client side, and let that plus the client IP take part in computing an auth token for WS ..