I am currently building a web application, that has fully separated a "frontend" server with Lighttpd only serving the index.html and javascript etc.
Backbone.js etc. keep my frontend in connection with my webservice "backend" written in Node.js
The backend is completely stateless, doing authentication each request through http basic and runs SSL (https).
How do I make sure that only the connections happening on my "backend" server are comming from the Lighttpd "frontend" server and not some random hacker?
Thanks for help.
If you know the front-end server is going to be on a specific IP address or range or IP addresses, you might want to restrict traffic on the back-end server to only be from that address.
You may use ssl between the 2 servers and use a certificate to ensure identification. That's really secure if you protect your certificate well.
Related
I've setup a remote, hosted javascript server (DreamFactory Server http://www.dreamfactory.com/) that responds via REST API's.
Locally, I'm running an Angularjs application through the grunt web server via $grunt serve
https://www.npmjs.com/package/grunt-serve
I have setup CORS on the remote server to allow '*' for multiple http:// connection types. THIS WORKS CORRECTLY.
My question is how I can limit the CORS configuration to only allow a connection from my home, grunt web server?
I've tried to create an entry for "localhost", "127.0.0.1", also my home Internet IP that is reported from whatismyip.com, the dns entry that my provider lists for my home IP when I ping it, a dyndns entry that I create for my home internet IP... None of them work, except for '*' (which allows any site to connect).
I think it is an educational issue for me to understand what that CORS entry should look like to allow ONLY a connection from my home web server.
Is this possible? If so, what and where should I be checking in order to find the correct entry to clear in the CORS configuration?
-Brian
To work and actually apply restrictions, the client requesting the connection must support and enforce CORS. In an odd sort of way (from a security point of view), restricting access using CORS requires a self-policing client (one that follows the prescribed access rules). This works for modern browsers as they all follow the rules so it generally works for applications that are served through a browser.
But, CORS access restrictions do not prevent other types of clients (such as any random script in any language) from accessing your API.
In other words, CORS is really about access rules from web pages that are enforced by the local browser. It doesn't sound like your grunt/angular code would necessarily be something that implements and enforces CORS.
If you really want to prevent other systems from accessing your DreamFactory Server, then you will need to implement some server-side access restrictions in the API server itself.
If you just have one client accessing it and that client is using "protected" code that is not public, then you could just implement a password or some sort of logon credentials and your one client would be the only client that would have the logon credentials.
If the access is always from one particular fixed IP address, you could refuse connections on your server from any IP address that was not in a config file you maintained.
You can't secure an API with CORS, for that you will need to implement an authentication scheme on your server. There's essentially 4 steps to do this.
Update the headers your server sends with a few additional Access-control statements.
Tell Angular to allow cross-domain requests.
Pass credentials in your API calls from Angular.
Implement an HTTP Authentication scheme on your web server or in your API code.
This post by Georgi Naumov is a good place to look for details of an implementation in Angular and PHP.
AngularJS $http, CORS and http authentication
We are developing a web application that uses strophe.js to communicate with an openfire server for XMPP chat. The web application is hosted on tomcat and both tomcat and openfire reside on the same server. Strophe.js is using BOSH (essentially http long-polling) as a communication mechanism between the client and the openfire.
Our tomcat instance authenticates (form-based) using a users table in our database. We've configured our openfire instance to read out of the same table. That way mobile apps can directly connect to our chat server using the user's credentials
We also have apache running as a reverse proxy. This might be TMI for the problem at hand, but more information can't hurt. The url schemes look like the following:
http://myserver/web Our web interface. Goes to http://myserver:8080/
http://myserver/chat Forwards to the openfire BOSH url (what strophe.js connects to). Goes to http://myserver:7070/http-bind (openfire bosh endpoint)
The problem I'm trying to figure out is how to log in to our openfire server from the browser. For example, if the user goes to the login.jsp site and enters their credentials, the server will forward that user to index.jsp. The strophe.js connection will try to connect to the chat server (/chat), but at that point, the username and password is no longer available to the javascript code.
I need to figure out how to securely authenticate the user in the web browser with the openfire server AFTER authentication has occurred. I've looked around for some examples, but there's not much information out there (or rather, I don't know what to look for).
Some Possible Solutions
1.) The first strategy I tried was creating an AuthProvider implementation in openfire that can take the browser's cookie as the password, make an HTTP request to tomcat with that cookie, and if succeeds deem that user as authenticated. This worked at first, but when deploying I found that I needed to configure tomcat to allow the document.cookie to be populated with the JSESSIONID. After reading a bit about this, it seems that using cookies is not recommended from a security standpoint. Jeff Atwood has an post Protecting Your Cookies: HttpOnly that discusses the security issues stemming from cookies accessible to javascript. Although I am not completely opposed to using cookies, is there a better way?
2.) A solution I have also thought of (haven't implemented yet) was providing a REST endpoint to create tokens that the user can fetch once they are logged in and use as passwords for the openfire server. Seems a little better, but I'll need to create a new table, manage their expiration, etc.
If anyone has tackled this problem, please let me know. It would be greatly appreciated.
First time working with SSL client authentication. The way it works with node.js while mixing with a certificate issued by a third-party CA (in this case it is StartSSL) is confusing me.
On production servers I'm using nginx as load balancer to different node.js instances. Since this is how I had done it before, nginx is handling all the HTTPS work and then passing a plain http request to a node instance. Since it has been deciding to always enforce SSL (for all kind of requests, using HSTS and using simple redirects), I'm considering the possibility to moving into having nginx doing only the balancing and letting the nodejs instances take care of the rest.
So, what I ignore is how to handle this with Node.js?
I found this blog post http://www.gettingcirrius.com/2012/06/securing-nodejs-and-express-with-ssl.html and this other http://blog.nategood.com/nodejs-ssl-client-cert-auth-api-rest
What I don't understand is how to handle both SSL authentications simultaneously. I hope I'm making some sense.
The idea is to generate a certificate for each user which has a CN that I match to a user, then ask for a password that, after bcrypted, should match what is on the database. While, at the same time, using the verification level 3 certificate that works with the CA to improve our users' safety.
I have a client application in flash and a server application in C++ on linux. They communicate through a TCP socket and the server handles all of the game logic and communication between clients.
I'm now in the process of deploying my application onto a website. Embedding the swf is easy and working fine.
I want to be able to save statistical information about users and would like to use the Facebook login to uniquely identify users and store information about them in the mysql database.
I am now in a situation in which the javascript part of my server application (index.html using apache) needs to send the facebook information to the C++ part of my server (which contains all of the game logic and database management) so that I will know a users unique ID for the database.
Is it possible to send this information from Javascript to the C++ application?
You can make your C server act as a webserver, accepting connections following the HTTP protocol, and then you can send data with Ajax. Just remember to make your server send the Access-Control-Allow-Origin: yourdomain.com response header, replacing yourdomain.com with the domain you host the HTML+JS page on; this is to allow cross site requests, because the C server will be listening on another port than the webserver, and maybe another address too.
I know that there are many similar questions posted, but none of them refers to an HTML/javascript app where the user can access the code.
I have a private REST API written in nodejs. It is private because its only purpose is to server my HTML5 clients apps (Chrome app and Adobe Air app). So an API key is not a good solution since any user can see the javascript code.
I want to avoid bots creating accounts on my server and consuming my resources.
Is there any way to acomplish this?
An API key is a decent solution especially if you require constraints on the API key's request origin; consider that you should only accept an API key if the originating web request comes from an authorized source, such as your private domain. If a web request comes from an unauthorized domain, you could simply deny processing the request.
You can improve the security of this mechanism by utilizing a specialized encoding scheme, such as a hash-based message authentication code (HMAC). The following resource explains this mechanism clearly:
http://cloud.dzone.com/news/using-api-keys-effectively
What you want to do is employ mutually-authenticated SSL, so that your server will only accept incoming connections from your app and your app will only communicate with your server.
Here's the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. If you're using Android, you can use the keytool included with the Android SDK for this purpose; if you're using another app platform, similar tools exist for them as well. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource (keytool will generate this as well). Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.
If someone/something other than your app attempts to connect to your server, the SSL connection will not be created, as the server will reject incoming SSL connections that do not present the client certificate that you have included in your app.
A step-by-step for this is a much longer answer than is warranted here. I would suggest doing this in stages as there are resources on the web about how to deal with self-signed SSL certificate in Android (I'm not as familiar with how to do this on other mobile platforms), both server and client side. There is also a complete walk-through in my book, Application Security for the Android Platform, published by O'Reilly.