Lets say I make an elm app; it requests data from a websocket to check the price of bitcoin from say poloniex.com. I compile it to an .html file and I deploy it to say Heroku or whatever server I like on the backend.
When a user comes to my website and requests that .html file, and is then looking at the bitcoin price from the websocket request, is the user's IP address making that websocket request or is it the backend's (eg Heroku in this case) IP address making the websocket request?
I ask because I was considering two different designs. Either have my backend pull the bitcoin price data and then serve that to my users or have the users directly request the price from the source itself (i.e poloniex in this case). The latter would be less headache but won't be possible if all the requests end up coming from the backend and therefore one ip address (they would have request limits)
Edit: Bolded for people who couldn't see where the question was.
Assuming you are using the standard Elm Websocket package, elm-lang/websocket, the websocket connects with whatever URL you point it at. If you set it up like this:
subscriptions model =
listen "ws://echo.websocket.org" Echo
Then the client browser will connect directly with echo.websocket.org. The target of that websocket connection will likely see your application as a referrer, but its connection will be with the IP of the user's browser that is acting as the client.
If you instead want your backend server application to act as a proxy, you would use that URL in listen
subscriptions model =
listen "ws://myapp.com" ...
Related
I know that if presented with an mTLS request an modern browser will request the user select a certificate from a store (OS-based or in Firefox's case NSS-based). I was wondering if there is any other way for the Webpage that is returned after the mTLS handshake to requests actions be performed with the users certificate or private key, such as:
Can the webpage be aware of the selected certificate and read some of the field with a Javascript API? (IE: <h1> Hello {x509CommonName}</h1>)
Can the webpage request that the user sign something with their private key? (little risky but potentially useful)
I am not asking how easy it is to just use the web server to reflect the certificate back to the client.
From the client side, it is not possible to obtain the certificate used in the SSL connection, nor to perform a digital signature. The browser keystore is not accessible via JavaScript. Although there has been some attempt to develop a standard API, it seems that it is not succeeding. See https://www.w3.org/TR/webcrypto-key-discovery/
On the server side you can easily obtain the certificate used. Any web server will provide it to the application layer. The web page could navigate to a zone with ssl two ways authentication, the server would retrieve the certificate and return it in the response
I'm developing a website and mobile application that communicate with each other.
It's very basic at the moment: the app makes a get request to a URL and the server returns JSON data.
I want to secure this and make sure no-one can send a get request to the URL and get this data (only the website and the app). Is it ok to make a 60+ character password that the app can send with the request that the server accepts before data is sent, or is this breakable?
I dont want to use OAuth because it's overkill as only the app and the site are going to communicate. Please provide me with a few solutions, thanks!
You can use HTTPS to transmit data.But you will need an SSL cerificate for this.
I have an iPhone application that needs to collect data from an online MySQL database. I've written a PHP web service so I collect the data with JSON. The problem is that everyone can see the data if they go to the URL now. How do i secure the data transfer properly?
Thanks for your suggestions.
Typically, if you are showing data private to a particular user, then each user will generally have an account (user id and password). The app will pass the user's credentials to the server before the server will provide the user's data.
You can also do something similar using SSO integration, or OAuth (ala Facebook).
In some cases, your app may only pass the username/password on the initial call and receive a session ID, which the app passes on remaining calls. This allows the server to store session data.
Even if the data isn't private to a particular user, you can use accounts to restrict access and privileges for a publicly reachable web API.
In all of the above cases encryption such as SSL (HTTPS) must be used to protect the authentication mechanisms and data transfer.
I'm assuming your data is public for all users of your app, in other words, you don't want to implement a login mechanism for your users. If you just want to make sure you return the data only to users of your app and not to anyone who happens to enter the right URL in their browser, you will need to sign your requests, so that only requests from your app are accepted by your server.
I use a secret key that my app uses to create a hash/digest of the request which the server verifies (it knows the secret key as well). Also I make sure requests cannot be replayed if they are intercepted by adding a timestamp and a nonce. The timestamp is checked to be within 10 minutes of the server's timestamp (relaxed sync) and the nonce must be unique (server keeps the last 10 minutes of nonces). This way no-one can copy the same request, the server will just serve an error if they try.
This post explains how to sign your requests in a bit more detail:
http://www.naildrivin5.com/blog/2008/04/21/rest-security-signing-requests-with-secret-key-but-does-it-work.html
If your API and Website making ajax calls to that API are on the same server (even domain), how would you secure that API?
I only want requests from the same server to be allowed! No remote requests from any other domain, I already have SSL installed does this mean I am safe?
I think you have some confusion that I want to help you clear up.
By the very fact that you are talking about "making Ajax calls" you are talking about your application making remote requests to your server. Even if your website is served from the same domain you are making a remote request.
I only want requests from the same server to be allowed!
Therein lies the problem. You are not talking about making a request from server-to-server. You are talking about making a request from client-to-server (Ajax), so you cannot use IP restrictions (unless you know the IP address of every client that will access your site).
Restricting Ajax requests does not need to be any different than restricting other requests. How do you keep unauthorized users from accessing "normal" web pages? Typically you would have the user authenticate, create a user session on the server, pass a session cookie back tot he client that is then submitted on every request, right? All that stuff works for Ajax requests too.
If your API is exposed on the internet there is nothing you can do to stop others from trying to make requests against it (again, unless you know all of the IPs of allowed clients). So you have to have server-side control in place to authorize remote calls from your allowed clients.
Oh, and having TLS in place is a step in the right direction. I am always amazed by the number of developers that think they can do without TLS. But TLS alone is not enough.
Look at request_referer in your HTTP headers. That tell you where the request came from.
It depends what you want to secure it from.
Third parties getting their visitors to request data from your API using the credentials those visitors have on your site
Browsers will protect you automatically unless you take steps to disable that protection.
Third parties getting their visitors to request changes to your site using your API and the visitors' credentials
Nothing Ajax specific about this. Implement the usual defences against CSRF.
Third parties requesting data using their own client
Again, nothing Ajax specific about this. You can't prevent the requests being made. You need authentication/authorisation (e.g. password protection).
I already have SSL installed does this mean I am safe
No. That protects data from being intercepted enroute. It doesn't prevent other people requesting the data, or accessing it from the end points.
you can check ip address, if You want accept request only from same server, place .htaccess in api directory or in virtualhost configuration directive, to allow only 127.0.0.1 or localhost. Configuration is based on what webserver You have.
How does one programmatically determine if a given proxy is elite?
What is the general method/headers checked for?
One method would be to send an HTTP request to yourself, via the proxy. Make the request something uniquely identifiable... perhaps with a dummy query string with a unique signature.
Then, check the access log for the request. Did the request appear to come from your own IP address? If so, the proxy is not elite. Otherwise... it is!
It's my experience that you can't detect elite proxy use from HTTP response headers. In the case of onion routers, the header will show you an IP address that makes it seem as if the traffic originated from the onion router's exit node. And w/r/t Tor, which i would imagine is the most widely used onion router, Tor publishes their exit nodes and allow it to be accessed via API. I know that some Sites access this list and then block any IP address originating from it.