i have a webservice which is being consumed by my website using ajax. since im using ajax i cannot have ip restrictions on my webservice. i know i can always add an additional layer of security by using a proxy to call my webservice and the ajax code calls the proxy not the webservice. this way i can always restrict access to my webservice to only allow requests from the proxy
but the end problem is not solved. that is any smart end user can always come to know the proxy url im using from my ajax code and fire requests to this proxy to access all the webservice data
how do i secure my webservice (with or without proxy) such that it only serves requests which come from my website
i can always use http_referrer check in my proxy but thats easy to hack...
is there a fool proof way of doing this
One of the ways you can implement this is by using two way SSL authentication for your website.
In two-way SSL authentication, the SSL
client application verifies the
identity of the SSL server
application, and then the SSL server
application verifies the identity of
the SSL-client application.
Two-way SSL authentication is also
referred to as client authentication
because the application acting as an
SSL client presents its certificate to
the SSL server after the SSL server
authenticates itself to the SSL
client.
This way before executing any WS request your WS will first check if your client has the valid SSL certificate or not. If it does not then the WS will not execute. Implementing two way SSL requires configuration at both ends and can be slightly complicated to implement. However once setup this is a really secure way to call your webservice and ensure that only authorized clients(who already have the certificate) make those calls. So your AJAX code can make a call to a Servlet which in turn can make the call to this service. This way your service url is also not exposed to the browser.
Related
I am working on a distributed web application using Spring Microservices design pattern where individual services are running on different ports like -
Product Management - domain:8500
User Management - domain:8501
Now If the user calls User Management by opening the URL "domain:8501/some_url" which internally calls Product Management i.e. "domain:8500/some_other_url" and also assume that certificate is self-signed i.e. for the browser, the CA is unknown and hence the exception needs to be manually added in the browser.
In this case, while Chrome works fine, Firefox and IE also probably adds the exception for domain with port and hence for internal call as well it waits internally for the security exception to be added.
As a result, my API calling is failed. Is this a Firefox behaviour or I am doing something wrong?
AJ
Try either using an API gateway or a proxy. You can use Zuul for a proxy. Please go through Zuul starter.
You can even do some more interesting things by having a proxy. Like:
Implementing Security: Implement Validation & Verification as security check over the proxy and can avoid the same over other microservices.
Response Handling: You can alter a generic response from your microservices in proxy for the client(Web/Mobile Browser/Mobile App)
Hope this helps.
I have an https site that needs data from an API that is only available in http.
To get around the mixed content warning, I changed it so the JS requests a path on the server, which then makes the http request and returns the data.
Is this bad? If it is bad, why?
My understanding of what you're doing :
You are providing a HTTPS url on your server which is essentially acting as a proxy, making a backend connection between your server and the API provider over HTTP.
If my understanding of what you're doing is correct, then what you're doing is better than just serving everything over HTTP...
You are providing security between the client and your server. Most security threats that would take advantage of a plain HTTP connection are in the local environment of the client - such as on a shared local network. Dodgy wifi in a cafe. School lans. etc.
The connection between your server and the API provider is unencrypted but apparently they only provide that unencrypted anyway. This is really the best you can do unless your API provider starts providing an HTTPS interface.
It's more secure than doing nothing and should eliminate the browser errors.
If there is a real need for security (PCI compliance, HIPAA etc) however, you should stop using that API. However it seems unlikely considering the circumstantial evidence in your question.
What does it mean when an application calls another application via 2 way SSL.
Does it mean that an external application calls another application via https and also receives a https response.
Similarly if it was one way SSL, does it mean it sends a https request but the response will be http.
Our web application has a button that is supposed to send data to a server on the local network that in turn prints something on a printer.
So far it was easy: The button triggered an AJAX POST request to http://printerserver/print.php with a token, that page connected to the web application to verify the token and get the data to print and then printed.
However, we are now delivering our web application via HTTPs (and I would rather not go back to HTTP for this) and newer versions of Chrome and Firefox don't make the request to the HTTP address anymore, they don't even send the request to check CORS headers.
Now, what is a modern alternative to the cross-protocol XHR? Do Websockets suffer from the same problem? (A Google search did not make clear what is the current state here.) Can I use TCP Sockets already? I would rather not switch to GET requests either, because the action is not idempotent and it might have practical implications with preloading and caching.
I can change the application on the printerserver in any way (so I could replace it with NodeJS or something) but I cannot change the users' browsers (to trust a self-signed certificate for printerserver for example).
You could store the print requests on the webserver in a queue and make the printserver periodically poll for requests to print.
If that isn't possible I would setup a tunnel or VPN between the webserver and printserver networks. That way you can make the print request from the webserver on the server-side instead of the client. If you use curl, there are flags to ignore invalid SSL certificates etc. (I still suspect it's nicer to introduce a queue anyway, so the print requests aren't blocking).
If the webserver can make an ssh connection to something on the network where the printserver is on, you could do something like: ssh params user#host some curl command here.
Third option I can think of, if printserver can bind to for example a subdomain of the webserver domain, like: print.somedomain.com, you may be able to make it trusted by the somedomain.com certificate, IIRC you have to create a CSR (Certificate Signing Request) from the printserver certificate, and sign it with the somedomain.com certificate. Perhaps it doesn't even need to be a subdomain for this per se, but maybe that's a requirement for the browser to do it client-side.
The easiest way is to add a route to the webapp that does nothing more than relay the request to the print server. So make your AJAX POST request to https://myapp.com/print, and the server-side code powering that makes a request to http://printerserver/print.php, with the exact same POST content it received itself. As #dnozay said, this is commonly called a reverse proxy. Yes, to do that you'll have to reconfigure your printserver to accept (authenticated) requests from the webserver.
Alternatively, you could switch the printserver to https and directly call it from the client.
Note that an insecure (http) web-socket connection on a secure (https) page probably won't work either. And for good reason: generally it's a bad idea to mislead people by making insecure connections from what appears to them to be a secure page.
The server hosting the https webapp can reverse proxy the print server,
but since the printer is local to the user, this may not work.
The print server should have the correct CORS headers
Access-Control-Allow-Origin: *
or:
Access-Control-Allow-Origin: https://www.example.com
However there are pitfalls with using the wildcard.
From what I understand from the question, printserver is not accessible from the web application so the reverse proxy solution won't work here.
You are restricted from making requests from the browser to the printserver by cross-origin-policy.
If wish to communicate with the printserver from an HTTPS page you will need the printserver to expose print.php as HTTPS too.
You could create a DNS A record as a subdomain of your web application that resolves to the internal address of your printserver.
With those steps in place you should be able to update your printserver page to respond with permissive CORS headers which the browser should then respect. I don't think the browser will even issue CORS requests across different protocol schemes (HTTPS vs HTTP) or to internal domains, without a TLD.
Is the data secure if posted programmatically (not through a browser) to an https endpoint?
My understanding is browser encrypts data and sends it to https endpoint. How can a Ruby or Node.js or any other program do the same?
Yes. If you connect to an https endpoint with curl, wget, or whatever library, the transfer is secure from the source of the connection to the destination. That source could be a server (your webserver) or the client browser.
However, if it's done in client side JS or other browser scripting language, you have to make sure the initial request from client to your site is secure as well if first passing secure data to the client for it to pass to the destination https server.
I checked node.js request library as well as Ruby HTTParty libraries. Both these support SSL encryption based on proper options (port: 443 etc.). In general if we use any well supported library that enables HTTP gets and posts, we should be covered in terms of transmitting data securely to the https endpoint.
I think I understand what you mean and that question has been answered. However, I would just point out that HTTPS does not make your data secure, only the connection and even that is only encrypted from eavesdropping which is not really secure.
There is, of course, lots more to think about and do to make your data secure end-to-end.