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.
Related
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.
I'm currently building an oAuth2 server so that external clients/devices can access data from my service without having to send over user credentials with every request. I've finally grasped how oAuth works after spending an entire day reading numerous tutorials and online documentation, however, there's still one thing that I'm rather unsure of...
When sending a request for an authorization code to an oAuth server, how should I deal with a callback to mobile devices and devices that aren't a webserver?
E.g. this request to my oAuth server will send an authorization code as a callback to a specified webserver (http://client-url.com in this case)
http://mydomainname/oauth2/?client_id=test&grant_type=authorization_code&client_details=test&redirect_uri=http://client-url.com&response_type=code
The server at http://client-url.com will receive a response containing an authorization code and the developer will be able to store a user's oAuth credentials accordingly.
Obviously a mobile device isn't a webserver, so is there a standardised way of dealing with this? I've read online that you can define something called a custom URI scheme within iOS and Android apps. But what about the other mobile platforms out there? And desktop apps? I want my API to be accessible from as many platforms and devices as possible.
The reason why I'm asking this question is because I want to add validation to my oAuth server so that users can only register apps with valid callback URL's. I wasn't sure if should allow any other type of input as a callback apart from a valid URL.
Can anyone shine any light on this? I want to avoid spending hours validating and testing this across all devices as I'm sure anyone that has developed for multiple mobile platforms in the past must have some knowledge about this.
Thanks in advance.
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 am working on a cross platform app that will be created using C++-> mobile devices, and using Perl-> Desktop PCs (like Windows /Linux/Mac OS).
Now, since the app will be downloadable, I have concerns regarding the ability of hackers to obtain the source code of my app.
Specifically, the app will connect to my central database-- at the minimum, I want that hackers are not able to obtain my database connection details. Ideally, I would want no part of the code to be hacked.
Basically, the user can update some of his information using this app-- if hackers get hold of this data they can easily change any unfortunate user's data. One thing that I have thought of is that the user will have to initially authenticate with OAuth/OAuth2 ( using his email ID #yahoo/#hotmail/#gmail)-- and only after that the app will actually show the admin interface. But at any rate, at some point the app will connect to the central database-- which is why I dont want the database's access details to be compromised.
Many organisations make such apps, so they must be facing this type of problem themself? I would like to know how I can protect my app (ideally entire code), and atleast the db credentials.
The simple answer is you do not expose your database. Ever.
Add a service layer (could be HTTP-based but doesn't have to be) on top that will deal with authentication and authorisation. Your app then logs in using the user's credentials and acts on their behalf. Your service layer exposes an API which your application talks to, but your service makes and controls all calls to the DB.
You already mention OAuth - that's a perfectly acceptable way of adding authentication to such an API.
You cannot.
On the bright side you can put security on your server. The connecting client provides credentials that they are a given user. The server generates the SQL command after proving the request is allowed. Backers can do anything your app can do, but your app becomes incapable of behaving badly to your database.
The previous answers are absolutely correct. You want a server based service layer that provides the authentication/authorization code and interacts with the database. However, it isn't always a perfect world and if you are stuck with the requirement that these applications must act as a database client you want to limit the exposure as much as possible. Typically this is done by having the client use a specific account which has not been granted any access to the general database. You then create specific stored procedures that can only do the operations and queries that are required of the application. This prevents anyone finding the credentials in the code from doing anything in the database that isn't intended, but you still have the problem that anyone can impersonate someone else by reviewing the code. There isn't a way to prevent that without a server side component. This might be okay for a closed/trusted group of users, but I wouldn't release anything to the general public with this method.
If you can do it, use OAuth2 and allow a trusted third party handle authentication. Twitter, Facebook and GitHub are all relatively paranoid about security; and the other poster is correct: never expose direct db access as part of the app the user has access to; put it behind a service of its own.
Good luck! :)
I want to implement a new REST-based API on our infrastructure, and OAuth seems to be the way to go.
For our implementation, there will first just be server-to-server access, which will be completely unrestricted. I believe this is called two-legged authorization.
Later on, we'd like to allow the API to be consumed by the browser, which will turn our authorization into three-legged.
Is there a good starting point for implementing this? How can we fully authorize a server and down the road add restricted authorization per-user?
The OAuth specification is not really helpful in these scenarios, but I believe this implies we need to create a never-expiring session for the server-to-server access, and later on add normal sessions with limited access for user-only APIs.
I'm hoping to find starting points for more information, let me know!
Is OAuth for me? I'm only looking for a authenticated request system, and only the consumer and service provider exist in this scenario. The end-user does not come in to play!
Ya, OAuth is probably for you.
There are actually two OAuth specifications, the 3-legged version and the 2-legged version. The 3-legged version is the one that gets most of the attention, and it's not the one you want to use.
The good news is that the 2-legged version does exactly what you want, it allows an application to grant access to another via either a shared secret key (very similar to Amazon's Web Service model, you will use the HMAC-SHA1 signing method) or via a public/private key system (use signing method: RSA-SHA1). The bad news, is that it's not nearly as well supported yet as the 3-legged version yet, so you may have to do a bit more work than you otherwise might have to right now.
Basically, 2-legged OAuth just specifies a way to "sign" (compute a hash over) several fields which include the current date, a random number called "nonce," and the parameters of your request. This makes it very hard to impersonate requests to your web service.
OAuth is slowly but surely becoming an accepted standard for this kind of thing -- you'll be best off in the long run if you embrace it because people can then leverage the various libraries available for doing that.
It's more elaborate than you would initially want to get into - but the good news is that a lot of people have spent a lot of time on it so you know you haven't forgotten anything. A great example is that very recently Twitter found a gap in the OAuth security which the community is currently working on closing. If you'd invented your own system, you're having to figure out all this stuff on your own.
Good luck!
Remember to distinguish between authentication and authorization. In some places, I believe that the OP mixes the two.
For example, once a server authenticates someone, it usually explicitly or implicitly (using cookies) provides an authentication token so that subsequent requests are already authorized.
It is up to the server how long the credentials last. It is smart to plan that the credentials will time-out at some point. Just have the client server be prepared to re-authenticate itself whenever it receives the "authorization expired" error response.
You don't want to try to provide a "never-expiring" session since:
Everything expires at some point. For example, how will the client server be able to start accessing the application again if it loses power or is rebooted?
You're creating an inflexible system. They tend to break more often.
Since you know that you want to add additional types of logins in the future, instead of two types of logins (server clients and browser clients), make just one type of login now. The additional work for the client server will be to implement a "re-login as necessary" capability.
OAuth will end up being too difficult for our needs. I've decided to adopt Amazon S3's authentication scheme, simply because it fits our model better.
Thanks for helping out finding an answer though..