只是一个多层安全问题 [英] Just a multi-tier security question

问题描述

嘿那里，



这只是我想知道的一个小安全问题，因为我觉得很多人都在努力解决这个问题。



我有一个多层系统（Gui> Processor> Core> Data）。我使用处理器来定义流程，比如创建用户。处理器知道该怎么做。它在Core项目中调用验证方法。如果成功，它将在Core项目中创建用户。同样，如果成功，处理器知道它必须邮寄用户以欢迎用户在我漂亮的系统中。对我而言，似乎是一个普通的故事...



如果我在目标机器上安装我的应用程序，那么这四个库将存储在硬盘驱动器的某个地方我可以'到达它。然后，任何开发人员都可以引用例如Core库并开发完全相同的方法，但（例如）绕过验证例程。如果可能的话，你可以想象你的n层应用程序有多脆弱（数据层可能最容易受到攻击）。



如何保护（例如）数据层来自其他调用，然后来自Core库，并依次保护Core库，而不是处理器层之外的其他调用。然后可以广泛地暴露处理器层以允许不同的UI和东西，这正是我们想要的！



非常感谢！

Eduard







为了顺利完成任务：

我的核心项目包含3个功能：

  bool  ValidateEntity（entity）; 
  bool  CommitEntity（entity）; 
  void  SendConfirmationEmail（）; 

处理器项目包含一个函数：

  bool  CreateUser（entity）
 {
  bool  success =  false ; 
  if （core.ValidateEntity（entity））
 {
  if （core.CommitEntity（entity））
 {
 success = core.SendConfirmationEmail（）; 
} 
 其他 
 {
  throw   new 异常（ 数据源出错 ）; 
} 
} 
  else  
 {
  throw   new 异常（ 验证失败）; 
} 
 返回成功; 
} 

现在在这种情况下，我可以引用Core项目并只需调用 core。没有验证的CommitEntity（实体）。



[/ Edit]

解决方案

< blockquote>我找到了解决方案。我生成了一个密钥（.pfx）文件并签署了所有项目。我将所有想要保护的方法声明为内部，并为程序集添加了 InternalsVisibleTo 属性：



所以在我的数据项目中，我要保护的所有方法都被声明为内部，汇编信息文件包含以下行：

 [汇编：InternalsVisibleTo（  Core，PublicKey = 0000 .. ..0000）

对于Core项目，我做了完全相同的事情。这样，通过标记 internal ，所有方法都可以 受保护 。按顺序组装允许访问内部（即使在设计时也可以调用方法），但是将来对程序集的引用将无法看到它们，因为它们没有暴露给大外面的坏世界。



胜利！

设计必须确保这一点。



在您的示例中，您说它在核心项目中调用验证方法。



但是然后你陈述任何其他开发人员可以参考例如核心库并开发完全相同的方法，但（例如）绕过验证例程



看来你的图层不想做你想要的。如果Core层用于强制验证，那么它的接口也必须强制执行它。



可以在 Core 中说有一些验证可以获得对实体的写访问权限。也许核心也是实际写入实体的途径。如果 Core 要强制执行关于谁写入以及何时（验证）的规则，则最好确保使用强制在写入之前调用访问实体

，例如

LockForEntity GetLock（entityId）;

...

UpdateEntity（lockForEntity，entity）;



所以在上面的代码中，如果有人使用Core并尝试调用UpdateEntity，他们会立即看到为了更新实体，他们需要一个 LockForEntity ，然后调查如何获得锁定。



换句话说，界面强制使用。

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 :

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

The Processor project contains one function :

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]

解决方案

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 :

[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!

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.

这篇关于只是一个多层安全问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！