Click here to Skip to main content
15,892,697 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hey there,

This is just a little security question I was wondering about, because I think many of you struggled with this one.

I have a multi-tier system (Gui > Processor > Core > Data). I use the processor to 'define' processes, like 'create a user'. The processor knows what to do. It calls a validation method in the Core project. If that succeeds, it will create the user in the Core project. Again, if that succeeds, the processor knows it must mail the user to welcome the user in my beautiful system. For me seems like an ordinary story however...

If I install my application on a target machine, the four libraries will be stored on the harddrive somewhere I can't reach it. Any developer can then reference for example the Core library and develop exactly the same methods but (for example) bypassing the validation routine. If that's possible, you can imagine how vulnerable your n-tier application is (the data layer is probably most vulnerable).

How can I protect the (for example) data layer from calls other then from the Core library, and protect the Core library in turn from calls other then the Processor layer. The processor layer can then be exposed widely to allow different UI's and stuff, which is exactly what we want!

Thanks a lot!
Eduard

[Edit]

To get things straight :
My Core project contains 3 functions :

C#
bool ValidateEntity(entity);
bool CommitEntity(entity);
void SendConfirmationEmail();


The Processor project contains one function :
C#
bool CreateUser(entity)
{
    bool success = false;
    if (core.ValidateEntity(entity))
    {
        if (core.CommitEntity(entity))
        {
            success = core.SendConfirmationEmail();
        }
        else
        {
            throw new Exception("Something went wrong in datasource");
        }
    }
    else
    {
        throw new Exception("Validation failed");
    }
    return success;
}


Now in this case, I can reference the Core project and just call core.CommitEntity(entity) without the validation.

[/Edit]
Posted
Updated 14-Oct-13 11:08am
v2
Comments
Sergey Alexandrovich Kryukov 14-Oct-13 16:58pm    
Is it a Web application? If it is, you can keep your data layer not exposed to Internet at all. Same thing about Core library. If this is something else, you need to provide more information on your architectures and explain at least some examples of valid and invalid access (exploit). This is a part of your requirements, not architecture. And keep in mind that the real solution will be not in adding some "protection" but in refining your architecture itself.
—SA
Eduard Keilholz 14-Oct-13 17:11pm    
Sergey,
Thanks for your reply. I assume the Processor, Core and Data layer may be used by any type of presentation, so this may be a website, a WPF or Windows Forms user interface.
Sergey Alexandrovich Kryukov 14-Oct-13 17:20pm    
But then, the important part is: do you have an HTTP server side, which could be the code of the site of one or more Web Services?
If not, you need to provide more information on each of your tiers. If some from-end tier(s) is optional or replaceable, it won't change much. The architectures of the layers closer to the back end is more important.
—SA
Eduard Keilholz 14-Oct-13 17:26pm    
Sergey,
Have you seen I updated the question with an example?
Sergey Alexandrovich Kryukov 14-Oct-13 17:41pm    
Not yet, will look at it, thank you...
—SA

I found a solution. I generated a key (.pfx) file and signed all projects. I declared all methods that I want to protect as internal and added a InternalsVisibleTo attribute to the assembly :

So in my data project, all methods that I want to protect are declared as internal and the assembly info file contains the following line :
C#
[assembly: InternalsVisibleTo("Core, PublicKey=0000.. ..0000")]


For the Core project I did exactly the same. This way all methods can be protected by marking them internal. The assembly in line of order is allowed to access the internal (it can actually call the method even while in design time) but references made to the assembly in the future won't be able to see them because they are not exposed to the big bad world outside.

Victory!
 
Share this answer
 
v2
The design must ensure this.

In your example you stated "It calls a validation method in the Core project".

But then you state any other developer could "reference for example the Core library and develop exactly the same methods but (for example) bypassing the validation routine"

It seems your layers are not doing want you want then. If the "Core" layer is intended to force validation, then the interface to it must also enforce it.

Lets say in the Core there is some validation to get write access to an entity. And maybe the core also is the route to actually write to an entity. If Core is to enforce rules on who gets to write and when (validation) then it best ensure the usage forces a call to access the entity prior to writing
e.g.
LockForEntity GetLock(entityId);
...
UpdateEntity(lockForEntity, entity);

So in the above code if someone uses the Core and tries to call UpdateEntity they immediately see in order to update the entity they need a LockForEntity and then investigate how to get the lock.

In other words the interface enforces the usage.
 
Share this answer
 
v4
Comments
Eduard Keilholz 14-Oct-13 17:09pm    
Collin, Thanks for you answer, but.. I think the issue is not solved yet. I've updated the question to make things more clear.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900