英文原文：
Insecure Direct Object Reference: Is Your ASP.NET App Data Secure?
引见
作为一个在X94的航空工程师，你的老板请求你从2号楼的工程图中检索出一个特定的专利。不幸的是，进入大楼需求你出示你具有进入大楼的资历的证实，然后你敏捷地以徽章的方式出示给了保安。到了十三楼，进入修建师工程师图纸库请求经过他们的生物判定系统来验证你是你宣称的阿谁人。最初在你的目标地，你供给给库***一串对你毫无意义的字母数字代码，可是在适宜的人手上，它可以转换成那里可以找的你需求的工程图的真实索引。
在上面的比方中，我们可以很轻易地断定恰当的平安办法来维护敏感数据的拜访。除个人拜访所需验证，一个附加的可能不是很分明的平安办法就是以字母数字码的方式混杂技巧文档身份，并直接映照到真实的文档身份和库中的地位。
抽象地说，这个比方是一盛行的被称为“非平安的间接工具援用”的Web使用平安破绽的解答，该破绽在OWASP最要害破绽Top10中排第四。但假如这就是谜底的话, 你接下来天然会问“关于我Web使用的详细问题是甚么且该怎么去处理?”
不平安的间接工具援用
我们对在我们网站上展现商品的设法都很熟习。用户经过倡议恳求来检查商品概况，向他们的购物车里添加商品，或实行相似的运动。你很有可能会应用商品的ID去标识用户正在恳求哪件商品的具体信息，标识添加进他们购物车的商品等等。最主要的是，这个ID很有多是存储商品信息的数据库表的主键。假如真是如许，那末我们就具有了一个间接工具援用。在网页上展现的某个商品（工具）被特定的ID标识，而这个ID是对数据库中类似标识的间接援用。
“说的不错，但那又怎么？”是如许，在容易的商家对主顾场景下，上文所讲的状况不是甚么问题。但假定这是一个金融类办事使用，比如说是你最经常使用的网上银行，上面有你的各个活期、定时储蓄账户和其他敏感数据，那将会如何呢？想象一下，你在你的账户页面选择检查 ID 为 1344573490 的存款账户的具体信息：
作为一个颠末身份核实的名为Mary Wiggins的用户，网站显示了针对你存款账户的信息：
我们可以间接看出这个支票户头就是我们具有的账户，同时也能确认这是一个间接援用。但如果你决议把 accountNumber 参数从 1344573490 改成 1344573491，那将会发作甚么呢？
Erin Maley，谁是Erin Maley？那不是我们。我们作为Mary Wiggins是曾经明白被认证过的。我们一切所做的工作就是次序地增加账户号直到下一个可能的值，而且我们可以看到一个不是我们所持有的账户信息。在这个例子中，我们有一个间接联系关系的账户，它可以被界说为系统内任何地方被标识的账户号。更进一步说，我们演习了一个潜伏的问题，暴光一个间接相干的账户是容易的数据工程。
假如你本人感到这不是间接援用惹的祸，而是身份验证上出了过失，那末你只对了一半。我们会商不平安间接工具援用所酿成的缺点时，实践上看到了两个问题。我发明下图可以更明白的描绘这个缺点终究是甚么：
假如不平安的间接工具援用触及以下两方面……
-
泄漏敏感数据
-
缺少公道的拜访把持
……那末我们关于补偿这个缺点的见解是甚么，和我们应当什么时候采用举动？接下来，我们起首处理影响最大范畴最广的问题——公道的拜访把持。
多层级的拜访把持
就像文章扫尾举的例子，多层级的拜访把持是必需的。固然我们有权进入大楼，但进入楼内某些区域需求特定的权限。当我们思索在Web使用中维护资本时，可使用如许的原则来到达目标。
经过路由实行拜访把持
起首，以后正当用户能否有权恳求资本？在我们对该用户全无所闻的状况下，该怎么断定以后用户可以被答应倡议这个恳求？因而第一步我们要做的是，在和用户交互时，经过添加拜访把持来维护资本。
在ASP.NET中，用户交互经过把持器举措（controller action）完成。我们可以在ASP.NET MVC把持器上运用[Authorize]特征（attribute）来确保用户只要先颠末系统核实身份才干履行把持器上的举措，而匿名用户将被回绝。
[Authorize]
public class AccountsController : Controller
{
[HttpGet]
public ActionResult Details(long accountNumber)
{
//...
如许就确保了API没法被地下运用，依据你的ASP.NET设置装备摆设，用户会被重定向到登录页面（默许行动）。[Authorize]特征经过额定的束缚来适配特定的用户和脚色：
[Authorize(Roles = "Admin, Manager")]
public class AccountsController : Controller
{
//..
[Authorize]特征除可以被使用到把持器举措上外，还能实行更多粒度的把持。例如在把持器上放置身份验证束缚，同时在把持器的分歧举措上运用基于脚色的拜访把持。
在我们的银行账户例子中，只对用户实行身份验证是不敷的，由于我们（只颠末身份验证的用户）居然能拜访另外一个用户的支票账户信息。关于像银行账户例子中看到的这类滥用行动，凡是被称作为横向权限晋升，用户可以拜访其他类似品级的用户信息。但是，有权倡议对某个资本的恳求与具有对实践资本的权限是完整分歧的观点。
数据拜访把持
因而，我们必需采用的第二层也是最主要拜访把持就是，包管用户被受权拜访资本。在基于脚色的拜访把持的状况下，这就跟确保用户属于公道的脚色一样轻易。假如被恳求的资本只需求某个晋升的权限，你可以应用之前演示的[Authorize]的Role属性来搞定。
[Authorize(Roles = "Admin")]
public class AccountsController : Controller
{
//..可是更多的时分，你被请求在数据层面临用户实行权限验证，以包管其有权拜访所恳求的资本。思索到受很多分歧要素的影响，处理计划多种多样，就上文提到的检查银行账户概况的案例，我们可以验证用户能否为其所恳求账户的具有者：
[Authorize]
public class AccountsController : Controller
{
[HttpGet]
public ActionResult Details(long accountNumber)
{
Account account = _accountRepository.Find(accountNumber);
if (account.UserId != User.Identity.GetUserId())
{
return new HttpUnauthorizedResult("User is not Authorized.");
}
//...记得我们曾经在把持器级别运用了[Authorize]特征，所以没需要在举措级别弄巧成拙。
本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。
2KB翻译任务按照
CC 协定，假如我们的任务有进犯到您的权益，请实时联络我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
