I'm running a company web application in aws. This web app is behind a cognito+External Identity provider with saml for only allowing company employees to reach the app (then they log in with local credentials to the app, as it is not possible to use saml).
In this context, does it make sense to put a WAF? A potential attacker could not launch attacks if he is not authenticated.
Thanks
Farid
A potential attacker could not launch attacks if he is not authenticated.
That's a very strong assumption. Most of incidents happen using stolen credentials, bad actors (malicious users) or an application bug
As well your application is not behind the Cognito, but both need to accesible to the clients or public internet directly.
does it make sense to put a WAF?
WAF protects partly against DDoS (filtering specific IP addresses or regions) and some other attack types (sql injection,..).
Every additional component is a tradeoff decision with complexity, usability and price. If it's worth - it is a decision if the threats or incident impacts are worth the price and effort to learn and manage the waf (baseline setup provides only baseline protection, for the best results you have to put the best effort to learn and manage the waf rules)
Maybe it's not an answer you are looking for and the question is more suited for https://security.stackexchange.com/ , but it's your decision
WAF will assist you with protecting your app from various different kinds of exploits on the web. Regardless of the AWS Cognito authentication which you have described, there are many, many vulnerabilities you might still be open to, DDOS attacks being one simple example.
If your web server is publicly accessible from a network perspective (unrelated to whether someone can login or not) then it still might make sense to use WAF.
Even an authenticated users may try to run an attack.
So WAF is of use even if you're using an IdP.
Related
I would like to know whether there is any security benefit to using OAuth2 for authorization where all clients are developed, owned and controlled by the API developer/owner/controller; as opposed to using token authentication per Django Rest Framework's Token Authentication.
My understanding OAuth is that it was created for the purpose of delegated authorization - allowing third party applications access to your user's data without knowing the user's credentials. It seems to now have become a standard, even where delegation is not required. I do not understand why. Is there any benefit at all where delegation is not required?
My setup will be a Django Rest Framework API with a web SPA client and mobile clients. Permissions are associated with user accounts. Users login with email and password.
I do not think that this is an opinion question, because I'm not asking which is better, I will make that decision myself, I'm just trying to understand whether there is actually any security benefit at all to the OAuth option. This question might be somewhat open-ended but hopefully is within an acceptable margin since I'm restricting the considerations to security considerations. Developer effort etc are not necessary to discuss.
OAuth is primarily a set of best practice security design patterns, represented by standards specifications that map to use cases for software companies. It is not just about delegation.
I wouldn't say solutions are more secure just because OAuth is used. It is more a case of the threats being better thought through, as well as the general architecture.
PROTECTING DATA IN APIs
The OAuth solution involves validating a JWT access token on every request, then using claims to implement the real authorization work.
This scales well to zero trust architectures, where JWTs can be forwarded between APIs, and the scope and audience claims can be used for boundary checks. The IAM Primer provides a good overview.
UI FLOWS
Web and mobile are tricky, and it is worth being aware of SPA Best Practices, whether you use OAuth or any other solution, such as a site that manages its own passwords.
FULL OAUTH SOLUTIONS
A full OAuth solution involves use of a third party Authorization Server (AS), which manages the difficult security work, but there is a learning curve in integrating one. It also enables you to use the code flow, which is worth reading about.
Sometimes companies adopt an AS when they want multiple sign in methods, custom authentication, business partner integration, or to use advanced flows or financial grade security, which is required in some industry sectors.
YOUR SOLUTION
SecurÃty for web, mobile and APIs is difficult however you do it. Usually companies identify requirements and design how they want end-to-end flows to work, rather than it just being a developer task. My blog post suggests a people process.
My general recommendation would be to follow OAuth patterns to protect data, even if you implement UI flows in a simpler way initially. Your code will then be migratable to a full OAuth architecture in future, if your security requirements evolve.
Let me just start with I am extremely new to OAuth 2.0 and security is not exactly my strength. Because of this, if something in my question sounds strange or hints that I have no idea what I am talking about, that is precisely why.
Moving on, we have a need for users to have access to our system, hosted on AWS, both through a user interface that we will be building and also through our API directly. The challenge is: when it comes to our API users, I am unsure how authorization should be performed for them. All of our users are mandated to reset their passwords every 6 months for legal reasons, which means that I cannot register any of the applications that will be accessing our API as app clients because Cognito does not allow client secrets to be changed once generated.
I am also getting the feeling that OAuth seems much more heavily geared for granting access to a service on the behalf of someone else rather than being geared toward granting access to a known entity directly, but I could be wrong.
I have been told that we need our customers (both UI and API) to be able to submit a username and password and get a token. I understand that the implicit grant has many security flaws and should not be used, so I don't want to use that, but how can I keep the experience easy for our API users?
Cognito's hosted UI makes things easy enough for people who will be logging in manually to use our system, but most of our business is all automated and I am just stuck on how to proceed.
They don't want the login process to be any more complex than (username + password) = token. With that being the case, and me not being a security expert, I am not sure how I should proceed with Cognito. I know this question might illicit opinions, but I'm hoping it's specific enough of a problem to get some specific responses. I'm just at a loss and don't know what else to do. I've been researching this for 2 weeks non-stop and I'm just totally lost. Any help is seriously appreciated.
Thank you.
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 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..
Several web service APIs have you sign up for an API key. For example, UPS Web services requires a key, which is included in calls to their service -- In addition to the username and password.
What is this key used for by the provider? Perhaps UPS is the only one to require both API key and username/password?
One idea is that they use it to limit or measure API usage, but it seems to me that a setting in the users profile could easily do the same thing -- especially since you generally have to get an account w/ username and password to get the API in the first place.
There are two predominant use cases. The first is to measure, track and restrict API usage. If someone is building a service that allows third parties to access it, the service provider may want to control (or at least know) who has access so that they can try and prevent things like denial of service attacks. On the measure and track side, interesting information can be obtained such as knowing which applications are popular for accessing the service or which features people use the most.
The other use case is related to security and authentication. It is unwise for a service provider to have third party applications and services require users to give up their username and password for the primary service. This is a huge exposure. That is why many services are standardizing on protocols such as OAuth, which provides delegated access via authorization to a user's data. While not foolproof, it is definitely preferable to distributing user credentials to unknown, and untrusted, parties.
Most of the time it is to monitor how developers are using the web-api. If they somehow disagree with your usage of the api it provides a means for them to shut it/you down without hurting the other users. And the statistics per user/app are always valuable.
I've used the flickr api - in that situation the key is yours, but the login data might be those of people using your app, so the api key is the only way to differentiate between the apps.
Usually it used to get stats on how much application performing queries to API.
I think asking username/password with API key is ambigious in some cases, but it is a way how it is implemented - so we can't do something with it.
They ask for API key because you could have more than one API under same account - in case you have more than one site which are use same API.
They could use it to signify which version of the API you are trying to use. Perhaps in Version 1.0, there is a method that takes a POST on www.UPS.com/search and there is another one in version 2.0 at the same address, but takes a different parameter set, or even returns data in a different format/style. Your program was built on V1.0 and expects a certain API contract. They want to be able to create V2.0 without interfering with their customer's products.
That's just a guess, but it sounds good to me.
I think Gracenote does a similar thing for cddb. I forget the details, but I remember something about some token.
(They have/had really draconian rules about using their service too.)
Simon reminded me what the gracenote thing was. Gracenote and Fedex and other webservices have lots of developers writing apps for the software. So the developers get a token to put into their apps, but the end users have their own user name and password. It lets the services keep an eye on abusing programs, etc. That is probably te primary reason. (like a browser or a webbot informing the webserver who/what it is)
Originally, Blogger required you to apply for an API key (a la Google Maps) and used it to restrict access to the API. As Blogger evolved into Metaweblog, the requirement for the API became less important, and Blogger no longer requires you to apply for a key. As noted by others, it can still be used for tracking purposes.
In our situation, our clients want it for:
Tracking/analytics - figuring out who's doing what and building what products. Because a number of users are desktop apps, just looking at referrers isn't always enough.
Permissions - which resources should a user have access to? How can a user build apps that have access to specified resources?
Licensing/legal - enforcing that users have read and accepted ToU/licensing information.
Security - passing around usernames/passwords is a really bad idea.