I'm planning on making an android application that sends user data to a web server and stores it temporarily in a database. Now I've never worked with databases or web servers before, but after reading a bunch of tutorials and a few days of hacking away I managed to get a node.js server with mongodb up and running on the openshift platform.
Right now anyone can interact with the database just by sending a GET request or even just pulling up the url in a browser. Is there a way to prevent that by happening or would I have to maybe encrypt the data myself before storing it?
You describe a typical web application using REST APIs. To secure it, do two things:
Deploy your REST APIs (or the entire site) using HTTPS instead of HTTP. This provides end to end encryption so your sensitive data cannot be viewed while in transit
Add an authentication and authorization mechanism, so that only authenticated endpoints can access your REST APIs.
Related
I'm new to whole authentication/authorization part in web development. Specifically JWT. So I came across a medium post explaining the fundamentals of JWT. There was a diagram which showed how the web server and authentication server had no direct communication, AFTER a JWT token had been issued by the authentication server.
So, my 3 questions are:
What's the difference between the authentication server and the web server?
Is the authentication server, the database server?
And, since you are going to take user data(e.g password/username) from the
client(browser/user), to which server do you write the code to? authentication or web?
Because NodeJS/Express allows you to write the app server code right?
1 - An auth server is usually part of a microservice architecture, if you do not have to scale you can have a simple authentification middleware in your web server.
2 - The auth server is a server usually part of a microservice architecture which role is to authentificate requests and act as a gateway to the rest of the microservices.
3 - Depends if you want to scale or not. If you want to separate auth and the rest of the apis, there are multiple ways to scale.
Hope it helps =)
What's the difference between the authentication server and the web server?
These are two separate servers. Two different programs, potentially running on two (or more) different machines. With different purposes and responsibilities.
Is the authentication server, the database server?
No. For all you know the auth server may not use db at all. For example it can store all the data directly in files, or even in memory. Although, in practice there will be some db behind it. Auth server is just a server with a special purpose: user authentication (as the name suggests).
And, since you are going to take user data(e.g password/username) from the client(browser/user), to which server do you write the code to? authentication or web? Because NodeJS/Express allows you to write the app server code right?
Write code? Both? Depends on whether you implement the auth server by yourself or not. I'm not sure I get that question.
The point is that user credentials should be send to the auth server and the auth server is responsible for validation, secure storage and token issuing. So that other servers (in particular the one you call "web") don't have to worry about it.
I am quite new to the world of Xamarin and mobile development, but have been asked to create a simple cross-platform mobile app which is able to log into a secure web server, download some SQL data and then display it in the app.
What I am trying to understand is how to get the mobile app to request the data from my web server securly. I've seen and read a lot of information about requesting data from a web server using HttpWebRequest, but none of the examples describe how to secure this data. Also I see a lot of info about creating a REST API, but again I am not sure if thats the way I need to go?
Can anyone give me a really simple breakdown of the steps I will need to implement in order to achieve this? I feel like I'm drowning in a sea of web technologies and not sure which way to swim :)
I will be using IIS as the database and the Xamarin App will need to run on both iOS and Android.
Any help greatly appreciated!
Mike
It´s a bit confusing the way you want to implement this and the level of security you need. There are many techniques to secure your app and your server. Some are easy to implement and others not so easy.
What I understand is that your application will be hosted on IIS. There is no such thing as a IIS database. IIS is just an application server by Microsoft.
The most common technology hosted in IIS is Asp.NET and Microsoft SQL Server database. But others can be used, like php (installing some extensions) and mysql server. Anyway, using just php in IIS is a bad decision IMO, as there many other light weight and better servers to do that.
Xamarin has nothing to do with server security. Xamarin is just a client technology and the security must reside on your server application.
That said, there are many good practices you should follow to make clients more secure:
Never store user passwords or sensible data on a local store (device database, settings, file system, etc)
As others suggested, send your data to the server through https protocol (SSL must be configured on the server side)
If you must save critical data on the device, use an encryption
algorithm (there are tons of libraries to encrypt local SQL
databases, just google it)
In case you go for Asp.NET I suggest that you go ahead and integrate Asp.Net Identity. It´s the standard authentication/authorization system for ASP.Net and the built-in features will handle you user database as well as security issues you would hardly find out by yourself (ie: storing passwords "as is" in the database is a big security hole)
Afterwards, you will have to choose an authentication (login) system. There are multiple choices but the industry standard would be oAuth2. Use refresh tokens if you want to make oAuth2 more secure. oAuth is supported by Asp.Net identity and Xamarin. For Xamarin you can use an oAuth .NET client library or make simple http calls (HttpWebRequest) to request tokens, refresh tokens, etc.
About REST API: I think that´s the way to go, no matter what client or server stack you´re using. Again, Asp.NET has a WebApi that will enable REST on your application.
If all this sounds like too much, don´t worry. When you create an Asp.Net application in Visual Studio using a template, you will get a ready app with REST (WebApi) and authentication/authorization/security (Asp.Net Identity) by default.
It´s important that you implement oAuth correctly both in the server and the client side. Otherwise you could face some security problems
I am using Nodejs,expressjs,and mongoose to develop a application.Now what is procedure or way to identify that the request hit of my rest api service is from my front end application not from any unknown request.
If your front end application is a browser web page, then there is no real way to limit your REST API service to only your web app.
The issue is that by its very nature the REST API service is available on the web to any client that wants to access it. You could add some authentication (some sort of secret key) that is required before the REST API service can be accessed, but you cannot hide that secret key in a browser web page. If the browser web page can get access to the key, then so can anyone else who looks at the code in the web page or on the wire.
Because browsers, by default, will not allow cross origin Ajax calls, you are already protected from some other web pages (on a different site) using your REST API service from the browser. But, other servers can still use your REST API service.
One common way that services attempt to manage the use of their APIs is that they require an API key be obtained for each legitimate use of the API. If a particular API key is found to be abusing the service, you can revoke the privileges of that API key. You can grant your own applications API keys (embedded in your web pages ) and you can even change those web keys regular (such as daily) to keep people from copying them once and then using them for a long time. But a determined hacker will still find a working API key and use it for awhile.
One common way that services attempt to prevent excess usage of their API and protect the integrity of their service is to implement rate limiting. You establish what you think is a reasonable number of API calls per second (or some such metric) that your own app would not exceed and you measure the number of API calls coming from each endpoint and if they exceed some threshold, then you either delay or deny or error their calls until they stop exceeding your threshold.
I am starting to plan a web-app and Backbone.js will be a perfect fit for the client side. I have been planning on using node for the backend but this is open for the time being.
I need a way to secure the front-end app's connection to a database. I have had discussions with others on Quora but I think the thought process was too abstracted from the core problem.
I would prefer to be accessing the data by RESTful end-points, but I need to ensure only my app can talk to the API. I will have full control over both the front-end and back-end of the application. There is a possibility of other apps being built around the database (in a year or two), however they will be developed by me (i.e. not a public API) and these will probably use separate OAuth end-points.
Some notes on the app (may or may not be useful):
The app is planned to be offered in a SaaS model where companies subscribe and are allowed multiple users.
The data for each company needs to be secure and only accessible to members of that company.
All traffic (front-end and app to API) will be sent through SSL.
Any advice on the best way to do this will be greatly appreciated.
We have the exact same setup as you - SaaS model, multiple apps (mobile, web, etc) and when I followed your link, Miguel has the exact solution we use.
Token that is time stamped and sent to the client on auth. We store that hash token in a User Model and then every subsequent request we validate that token.
You can extend Backbone.Model with a BaseModel that appends the token to every server request by overriding Backbone.Sync
See here about how they extended a baseview and you can apply the same thing to a basemodel.
I am creating a web application that uses the Drupal 7 Content Management System. The web pages heavily use JQuery and AJAX.
The AJAX calls hit REST services, which are actually implemented using JAVA. Apache is running Drupal 7 and is configured to pass any calls to the REST urls through to the Java EE server (Jboss AS7). Everything is over SSL.
I need to Authorise and Authenticate calls to the REST services, and access the username or ID of the person currently logged-in to Drupal from the Java app. The question is... how...
As the AJAX calls are made to the same Apache server (rather than to a separate server etc), everything happens within the same http session, so I'm hoping this will be quite easy.
Things I've thought-of:
Configure a java security interceptor that calls a custom (locally
accessed only) drupal service that somehow reads the session id and
returns the logged-in username
create a "dumb" drupal REST service to act as a gateway for all of my REST calls, which authorises/ authenticates then injects the username before passing-through to the Java backend service
The article at https://lists.wisc.edu/read/messages?id=7777296#7777296 made me wonder if I could get-away with calling a Drupal service (just at the start of each Java service session) that takes a Drupal sessionID and returns the current user and his roles. I could configure it in my Java service so it would reperform this call every x seconds or y calls to check for role changes or logouts.
How does everyone else do it? This must be a common problem to solve isn't it? If not, what do you do instead to securely access authenticated services over AJAX? I'd rather not introduce a second user control process in addition to Drupal unless it's unavoidable. DRY :)
Thank you - this has me stumped!
Looking at what you are doing and trying to keep things as simple as possible, I would go for a variation of the first option. This is basically what the current node.js module does although it does it with unique authorization tokens. The workflow is something like this:
When a logged in user loads a page, a unique token is generated and stored in the Drupal database and sent to the browser
When the browser goes to connect to the node.js server it sends the auth token along with the request
The node.js server, upon receiving the request with token for the first time, will connect to a web service on the Drupal site and verify that the token is valid and send back any info about the user, and what roles/etc they have.
The node.js server then stores this internally for future requests, so that it doesn't have to ping the Drupal site for each request.
When a user logs out of Drupal, Drupal makes a direct request to the node.js server asking it to delete the token for that user.
Sounds like basically swapping your java app for node.js this should be pretty doable, with the advantage that it can scale well if you split this to multiple servers in the future.