I am tasked with a web application project involving a lot of dynamic design.
I am going to build a RESTful API with Node.js with token-based authentication, and initially I thought about building another Node.js application for web-based UI, but now that I have a basic design of the API, I was wondering if it is feasible to implement all of the UI logic with JavaScript on the browser?
It would involve a HTML page, which has JavaScript that will GET/POST data from the API, and update the DOM accordingly, furthermore, I would save authentication token in cookie, and the JavaScript in browser would do everything ranging from login to updating/deleting/creating all kinds of data through the RESTful API.
I haven't heard anything quite like this, is there any security concerns? Off the top of my head, the API server would get tremendous amount of requests if attacked.
Regardless of the amount of traffic or code, the security concern is the same.
Is anything sensitive being sent to the browser?
Is any request to the server not being validated?
That's pretty much the extent of the security. Any attacker can craft any bombardment of requests to any API, regardless of how complex the client-side code for the application is.
Assume that client-side code might not execute at all. Assume that you have no control over the client-side code. Assume that every request reaching the API must be validated. Assume that any input coming to the API can't be trusted. Etc.
Basically there are no additional security concerns which wouldn't exist in any of the simplest web applications.
Related
My scenarios is simple and perhaps not only me deal with. I have an webservice that is used my a number of my mobile apps. I would like my webservice only be accessed from my mobile apps but I don't wish my apps's user be bothered with registering an account. How can I achieve that kinds of security?
I have read about API KEY and OTP, but it doesn't really convince me.
It isn't possible to do what you want 100%. The reason is that if the security is in your Mobile App, or travels over the internet, it is theoretically possible for someone to read your code or scan your traffic and then impersonate your Mobile App.
However, you can get good results with simple server side checks. EG, from your Mobile App, add a variable into HTTP calls which is checked by your backend. And, most importantly, use SSL. You can make this more complex as well, such as providing a token from the server and then requiring this token back on every call.
It's not unbreakable... but it will deter the casual hacker. And it will probably only take you 10 minutes to implement.
We have web applications that we build internally (server side exposes web-services that are called from client side JS).
We also required to expose our code functionality in REST API.
I wonder - should I also start to use the REST API also for the web application that I build internally?
Originally, the REST architectural style declares that the REST is stateless (http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3). This results in consumers\clients that keeps the state in the client side.
It works well for "rich" clients (mobile applications, etc...) that are built to save the state in their side. But... is it the same for web applications?
Is it good to have server side that expose itself in REST API, and the client side calls those REST API directly?
I see some pros, and some cons.
Pros:
Unified interface - our server side exposes it's API only in one way (REST), for the web application, and for general purposes API
Easy to expose services that we use internally to be used by external users.
Cons:
As said above - browsers are not built to save cache in the client side.
If I have the possibility to use state - why not? It improves performance (less back and forth), and ease on development.
Once we expose the internal API to customers, it restricts us to be very careful with the changes.
Any hints\recommendations?
This is an extremely common and powerful architecture, especially when coupled with heavy front-end clients like AngularJS or EmberJS. The state in that case is held on the client, and passed to the server only what's needed to complete whatever interaction (API call) they're making. It's really clean and scalable, in my experience.
A couple things you need to figure out / handle. Login & "session" info. In general, session stuff doesn't get done on a REST service ,so you have to account for that in various ways. Login is generally done by acquiring a token from the server (e.g. a JavaScript Web Token) and then passing that on further requests. You end up handling expiration on your own.
Using single REST server for all your applications will enable you reuse of the server.
Regarding sessions, in Kaltura we use login to return an encrypted string that holds the user id, his session type (admin/user) and the session expiration, once the client received that session string it will use it for any future API call.
This architecture enable us to save additional information on that session string without keeping a copy of it on the server.
For more API REST server guidelines, see my blog: http://restafar.com/create-new-rest-server/
I am currently working on a single-page web application. The web app will make calls to a REST-like API for authentication and data storage. We are currently in the middle of securing the application, and have worked out a strategy securing the site so only registered users can gain access. But one thing we also want to do is securing the API from others to write their own applications, or access it in any other way than through our web application. The problem from my view is that the API will be open for everybody and not only for my web application.
Anyone who knows how to do this, or who can point me in the right direction. Because right now, don't have a clue.
Considered using certificates and validation?
Your API should only be accessible, if the session of the client is authorized. That's pretty much anything you could do.
There are complex approaches like using client- and server-side encryption or something really basic: render a secret in your webpage that validates the user again on every request.
You could check the headers, where the original request comes from. And so on...
But as most of that is public in a users browser, anyone could read it and adopt it in a third party app.
So save yourself and the people that really want to do a third party app some time and provide a public API :)
Simplest way will be to use OAuth 2.0 ( supports both authentication and authorization) which you need.
Also ensure you secure the data on wire using TLS (HTTPS) and any of the options below
1. HTTP Digest
2. OAuthn 2.0
3. Certificates ( Shared secret)
Stick to HTTPS+Oauth2 for now.
You could lock down your you API to accept requests from known IP's. Also depending on how your network infrastructure is designed, your web application can sit in a DMZ and your API on an internal network accessible only by servers in your network, one of which will include your backend API (This article here info https://www.digitalocean.com/community/tutorials/5-common-server-setups-for-your-web-application has some tips). For better security, a secure network design in addition to an application security framework implementation like OAuth2 and HTTPS (mentioned above). For API's, I've found that resource based authorization works better than role based authorization. Lastly, constant review of your security setup is vital as things change all the time. A good approach to this is Threat Modelling described by OWASP here https://www.owasp.org/index.php/Application_Threat_Modeling
I've recently programmed a REST web service API that allows another website to sign-up for my website remotely.
I've programmed all the necessary validation and filtering in to the API.
My question is, should I now ensure that my own registration form uses the web service API when handling user registration?
The form itself already has the very same validation, but it would seem to be that it would be best if there is only one method that is ultimately responsible for validation/filtering.
That solution doesn't seem to be the best, either, though because I am now making a REST client to touch my own web services API from the exact same website.
The last solution that comes to mind is to put the validation on my user model, and throw an exception up the web services API when validation is triggered. Are there any downsides to this solution?
One of the major benefits of REST is to define a interface that a remote client can access easily with the minimum amount of coupling between client and server. This is very useful when you do not control the client. This allows you to evolve your server interface without breaking existing clients.
The REST interface should really just be a thin layer over your validation and registration logic. In theory it should be easy for you to re-use that logic in your own website without going through the REST api.
Your website is not on a remote machine and you have control over both the client and server portion so you are not gaining anything by going through the REST interface.
We don't exactly comply with the XML-RPC spec, but the concepts are nearly identical. A client comes in over HTTP/HTTPS with an XML payload. We respond with an XML payload answering the request. This is primarily machine to machine, so no human to type a username/password. Our construct runs within apache tomcat. We would like to authenticate the request and since not every service is available to every client, we need to authorize the request as well. We have both subscription and per use charging models so it is necessary to log everything.
What would you recommend for both server and client?
HTTP BASIC/DIGEST works fine for most machine to machine tasks, and it handled by the server so your API is unaffected.
It doesn't work as well for interactive uses because it's difficult to "log out" the user without closing the browser.
Otherwise you'll most likely need to alter your APIs to include authentication information and have your methods authenticate that within your code.
Or you could use the classic "login", set a cookie, keep a session technique.
But, frankly, for machine to machine work, HTTP BASIC is the easiest.
edit, regarding comments.
HTTP BASIC is simply a protocol used to present the artifacts necessary for authentication, and it works well for machine to machine web services.
HOW IT IS IMPLEMENTED is dependent on you and your application. Using Java, you can use container authentication and that will provide authentication as well as role mapping. The user -> role mapping is handled in either a data file or database. The URLs protected, and what roles are valid for each URL, is managed by web.xml.
If you continue to add different roles to different URLs, then, yes, you'll need to redeploy that application.
However, if you're just adding new users, then you simply update your file or database. And if you're adding new logic, and this new URLs, then you have to redeploy anyway. If you have a ROLE structure with a fine enough granularity, you won't have to be messing with the web.xml until you actually add new methods. For example you could, at the extreme, create a role per method, and assign them individually to users. Most don't need to go that far.
If you don't want to use container authentication, then write a Servlet Filter to implement your vision of mapping user and roles to URLs. You can still use the HTTP BASIC protocol for your clients, even if you implement your own facility.
If you're looking for an overall generic Java security framework, I defer to google -- there are several, I've not used any of them. I've had good luck with container authentication and writing our own.
#Will
I second the HTTP Basic suggestion, and can testify that it integrates fairly well with Spring Security, which I implemented on top of a legacy application that rolled its own DB-based authentication/authorization logic.