We have implemented a custom STS. Currently, we limit allowed RPs based on realms & hosts that we can configure. This is proving to be slightly unpractical though. I would like to be able to allow people (e.g. our developers) to have access to our auth service, but not allow competitors to use it.
What would be a good approach to implementing some sort of a security mechanism to do this properly? Should I implement some sort of challenge/response mechanism? Or is there something already established as a security practice?
Note, we're using .NET, but I'm sure the solution is agnostic of the technology.
Related
This question might sound trivial, but even after reading a number of tutorials, I still don't get how the REST security should be implemented.
I have a webpage and soon-to-be-ready mobile app. Both of them will be using the REST API (written in node.js), and the question is - how can I prevent users from modyfing those requests? It's very easy to see the network traffic in the browser, and all the GET/POST requests that are made to the server. It also seems very easy to copy such a request, modify its parameters and/or payload and send it to the server.
How do I make sure that's my webpage or the app who made the request, and not someone else?
Sisyphus is absolutely correct: your focus should be on securing the channel (TLS, SSH, etc) and authentication (e.g. OAuth2).
You should absolutely familiarize yourself with the Open Web Application Security Project (OWASP). In particular, start with:
OWASP Top 10 Cheat Sheet
OWASP REST Security Cheat Sheet
Here is an excellent "hands on" tutorial that gives you a great overview of all the different pieces you need to worry about:
Authenticate a Node.js API with JSON Web Tokens
Once you've gone through the tutorial and scanned the OWASP cheat sheets, you'll have a much better idea of what kinds of things you need to worry about, what options/technologies are available to mitigate those risks, and what might work best for your particular scenario.
Good luck!
Typically, security these days uses a combination of Transport Layer Security and OAuth2. OAuth2 provides authentication and authorisation, ensuring appropriate access to resources, with TLS both securing data over the network and preventing the kind of replay attacks which you're concerned about. Neither are really specific to Restful APIs and you can find them being used in non-Rest contexts also.
This question might be naive but I would like to know what are the advantages of using Spring security (or any other security framework) versus custom filters (#WebFilter) to restrict pages in a web-app. In a custom filter I can check the session of an user, see if an user bean has been mapped within the session and then check if the user bean has the appropriate role to gain access to my restricted area. So what do I gain by using Spring security, surely it's more secure, if so then how? I'm asking because I find it harder to use than using custom filters. Thanks in advance.
Security Principle: Don't roll your own security unless you're an expert.
See https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own
The Spring guys aren't sitting around making work up for themselves. They are solving real problems. You could implement all of Spring Security's features with your filters, but then you'd have Spring Security, wouldn't you?
Are you handling CSRF and making it convenient?
Are you handling session fixation?
Do your filters handle path traversal?
Are you handling RunAs functionality?
Read the docs and decide if you should use it or not.
I need a utility to be given to my customer having site name A.com where he can decry-pt messages passed from my own site (i.e. B.com), which is build in Java technology.
Utility should be independent of technologies used by customer web site for their development.
Question: What technology should be used for developing such a Utility ?
Note: I have read that JavaScript is not good for cryptography.
The best option would be to use an existing, tried-and-tested protocol. TLS is a good choice for securing communication between two parties.
If, for some reason, you cannot use an existing protocol, you'll have to design your own, and describe it in such detail that others can implement it on their platforms. But this is very far from ideal for several reasons. Designing cryptographic protocols is hard, and even experts regularly get it wrong. Implementing cryptographic protocols is hard too, and experts often also get this wrong. There is simply no way a non-cryptographer could design or implement a secure protocol.
For 90% of every security-related Grails tutorial, they tell you to store your User objects in a session-scoped variable. That's all nice and easy, but I wonder if it's too good to be true, especially with plugins like Spring Security that offer many times more features.
For the simple, "I am a user and therefore I am entitled to view/edit my own domain objects" applications that I develop, I store my User objects in a session. However, this got me thinking how Grails supports J2EE security and sessions in its own implementation (it does use a temporary session ID in the cookie, right?). Furthermore how vulnerable is it to attacks like cookie injection and cross-site/stray JS?
I don't want to actually invest the time in learning, integrating, and maintaining a plugin for an app that might not need it, so my question is, is Grails's session implementation secure enough for simple applications, and is there a very good reason I should use a security plugin even for these trivial tasks?
On a side-note, if anyone can point me to a good OpenID/Facebook login implementation, that would be terrific.
Regarding security concerns I would always suggest to prefer proven and widely adopted solutions over your own rolled security implementation. Spring Security was founded in 2003 under the name Acegi and brings you more than eight years of experience and development for your security concerns.
As you already pointed to the Grails Spring Security plugin you should have a look at the OpenID plugin Spring Security OpenID which extends the Spring Security Core and brings you the OpenID support.
reason I should use a security plugin even for these trivial tasks?
... on a basic level it's also trivial to use the plugin so what's there to lose? Screencast to get you started
We're trying to implement the Gatekeeper Design pattern as recommended in Microsoft Security Best Practices for Azure, but I;m having some trouble determining how to do that.
To give some background on the project, we're taking an already developed website using the traditional layered approach (presentation, business, data, etc.) and converting it over to use Azure. The client would like some added security built around this process since it will now be in the cloud.
The initial suggestion to handle this was to use Queues and have worker roles process requests entered into the queue. Some of the concerns we've come across are how to properly serialize the objects and include what methods we need run on that object as well as the latency inherent in such an approach.
We've also looked setting up some WCF services in the Worker Role, but I'm having a little trouble wrapping my head around how exactly to handle this. (In addition to this being my first Azure project, this would also be my first attempt at WCF.) We'd run into the same issue with object serialization here.
Another thought was to set up some web services in another web role, but that seems to open the same security issue since we won't be able to perform IP-based security on the request.
I've searched and searched but haven't really found any samples that do what we're trying to do (or I didn't recognize them as doing so). Can anyone provide some guidance with code samples? Thanks.
Please do not take this the wrong way, but it sounds like you are in danger of over-engineering a solution based on the "requirement" that 'the client would like some added security'. The gatekeeper pattern that is described on page 13 of the Security Best Practices For Developing Windows Azure Applications document is a very big gun which you should only fire at large targets, i.e., scenarios where you actually need hardened applications storing highly sensitive data. Building something like this will potentially cost a lot of time & performance, so make sure you weigh pro's & con's thoroughly.
Have you considered leveraging SQL Azure firewall as an additional (and possibly acceptable) security measure? You can specify access on an IP address level and even configure it programmatically through stored procedures. You can block all external access to your database, making your Azure application (web/worker roles) the only "client" that is allowed to gain access.
To answer one of your questions specifically, you can secure access to a WCF service using X.509 certificates and implement message security; if you also need an SSL connection to protect data in transit you would need to use both message and transport security. It's not the simplest thing on earth, but it's possible. You can make it so only the servers that have the correct certificate can make the WCF request. Take a look at this thread for more details and a few more pointers: http://social.msdn.microsoft.com/Forums/en-US/windowsazuresecurity/thread/1f77046b-82a1-48c4-bb0d-23993027932a
Also, WCF makes it easy to exchange objects as long as you mark them Serializable. So making WCF calls would dramatically simplify how you exchange objects back and forth with your client(s).