3

Let's take a server-side WebServices app, we need to make sure that all function applies every security rules, and keep the code clean.

In such a case, I usually prefer to place my security checks on the upper layers. As soon as the user call a function, I check if he has the rights to access it or not. But this strategy doesn't always works, if we need to retrieve infos from the database before performing all the checks, for instance.

Is this a bad idea? Should it be better to place security checks in deep layers, just before/after accessing database? I'm trying to figure out the best approach for a system that have a lot of security checks, and avoiding creating a big spaguetti.

The question could be like "What are the best practice to make sure an app is secure and the code is easy to maintain?".

Improve this question
  • Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. – Robert Harvey Mar 12 '14 at 19:55
  • Anecdotally, it seems like the answer to your question is "Yes." Yes, you need to check things client-side, but because Javascript and the DOM can be manipulated, you also have to check those things server-side. As you've already pointed out, some checks have more to do with things like database integrity than they have to do with business rules, so those checks belong in a different place. – Robert Harvey Mar 12 '14 at 19:57
  • I added more details, but the question is really open because I'm not looking for a clear answer, only best practices and tips. – NLemay Mar 12 '14 at 20:12
  • 1
    Recommended reading: Why is asking a question about best practices a bad thing? – Robert Harvey Mar 12 '14 at 20:19
  • 2
    Your edit "What are the best practice to make sure an app is secure and the code is easy to maintain?" makes the question more generic and less answerable than the original. You may consider changing your question to "Where should security checks be placed - closer to the client, closer to the database, or all throughout? And why?" – Phil Mar 12 '14 at 21:47
0

Treating security as a separate concern, and handling it in a layer above application logic is a good practice.

One project I was on was a great example. It involved a family of web services. The evolution of our authorization check went like this (it's a bit Java-centric, but hopefully the idea is clear):

  • First as a shared jar bundled into all the services.

However, as we tweaked the security logic, it forced us to rebuild and redeploy everything. Yuck.

  • Next a shared jar that implemented a JEE Filter, bundled with all the services.

This was better, but any tweak still required us to rebuild & redeploy everything.

  • Next as a Tomcat filter that we deployed with Tomcat, outside the .war file

Better still. But our tweaks still required a deployment & reboot of the Tomcat servers.

  • Finally as a reverse proxy that ran as its own service separate from the other services, which took all requests, and authorized and forwarded valid requests down to the right server, or else returned an "unauthorized" error.

And this worked like a charm, because changing the authorization concerns only required a rebuild and redeploy of one service -- the reverse proxy.

So, see, in that case we ended up abstracting security up and out of the service altogether.

I agree with your feeling that pushing security higher in the call stack as a gate makes the implementation logic much cleaner and easier to handle. If you combine application logic with security checks, there's the risk of doing extra work before finding out (whoops) they aren't allowed to do step 3. Or worse, it might be a rollback situation where the app actually has to un-do what it did in step 2.

It's valuable to treat your security as a separate layer -- whether that layer is in code, a servlet filter, or an upstream proxy. Even if the security is a shopping list of actions, determine what they want to do up front, and then validate they are authorized to do all that before any actual work begins. That provides a really important separation of concerns.

...

Another practice that I've found that greatly simplifies security concerns is tying security rules to "roles" or "scopes". You cold say, client X wants to do operations X, Y and Z, and that requires scope M and P. A quick lookup (possibly cached) answers quickly whether the operations they want to do are covered by the scopes they have.

How broad or granular the scopes is just a design question, but allows you to be broad or granular as needed.

Improve this answer
  • 1
    There are a lots of good tips in here! I really like the idea of the proxy! – NLemay Mar 12 '14 at 20:44
  • 1
    This sounds pretty good, but I'd be concerned about having only one layer of security. If someone is able to somehow get past your proxy, your whole system is rendered naked and vulnerable. – Phil Mar 12 '14 at 21:57
  • In that case, the internal network was hidden inside a "virtual data center", so the services were only addressable by the proxy, and only the proxy had a IP visible outside the virtual environment. It's a broader question how to secure your internal network; some shops terminate SSL at the load-balancer and run plain HTTP to the services. – sea-rob Mar 13 '14 at 0:52
8

There are two facets to this problem and both should be satisfied for a good application to work:

  1. Fail Fast - having the user fill all the data, press the action button, wait 5 seconds, only to fail since some text at the beginning of the form should be at least 3 characters, or a dash has been forgotten is a very bad experience - do your security and validation checks as close as possible to the beginning of the transaction, and fail it as soon as you discover a problem. This means that UI validations are very important for a smooth experience, and even checks on the server-side before the "heavy lifting" is important.
  2. Trust no one - clients are easily hacked, service APIs are exposed to spoofing, 3rd party implementations may be lacking - don't trust that an earlier validation was made, and make sure as low as possible that your data remains consistent, and that the transaction is authorized. This is why you put constraints on your data tables, and not only count on the business logic to keep your data consistent.

Bottom line - each layer should make its own validations on its input, and on its output, even if that means that some validations are made more than once in a transaction. This might seem like it is 'less easy to maintain' since you may implement a validation more than once, but each validation has its own merit and its own importance - upper layer validation for better user experience, and lower layer validations for security.

Improve this answer
  • 3
    I like the last sentence! "upper layer validation for better user experience, and lower layer validations for security." – NLemay Mar 12 '14 at 20:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.