不安全的直接对象引用

一般网站开发人员的学习大体路子应该是

HTML/(JS/CSS)->某种服务器上可使用的语言->该后台语言对应的框架->看一些Demo->翻阅一下框架或者语言的参考文档->开发网站

开发动态网站一般情况下都会涉及到用户、权限这些安全层面的东西，如何确保自己的网站是一个相对安全的网站呢？

是否觉得自己做的网站好像没有什么漏洞，因为Demo啊，Docs啊都没有提及这方面，都是说应该怎么做，但同时又总有些不放心，隐隐约约觉得怕出问题，

只好盲目的以为框架会带来一定的安全性，自己可能不需要知道太多。但是在刚刚刚接触了几篇安全的文章我也才发现，如果做法出了问题，安全漏洞自然就会出现，

框架在安全性上几乎没有什么太大的贡献。

一切的模糊、不放心和盲目都是由于自己对网络安全，狭义点说，网络应用安全知识的匮乏导致的，所以从今天开始，我的学习图谱里也要开始增加这方面的知识了。

我发现了一个很有意思的网站 OWASP,里面介绍了很多网络应用相关的安全知识，但是没有中文版的，我的英文水平也有限，需要边查词义边翻译，坚持看吧。

现在开始翻译OWASP 2013 TOP TEN安全问题。

作为学习之用，翻译有误之处请指正，为了快速理解，翻译顺序可能不是按照OWASP的顺序来的

威胁载体：

考虑你的系统中的用户类型，是否某些用户只对某些特定类型的系统数据有访问权限？

攻击媒介：

攻击者是已经授权的系统用户，通过简单地改变一个系统直接引用的对象到另一个该用户无权限的对象上，是否就允许访问了？

安全弱点：

当生成web页面时应用经常使用一个对象的准确名字或者键值。应用不经常检查用户是否对该目标对象有权限。这是由于一个不安全的直接对象引用漏洞导致的。

        测试者可以很容易的操纵参数值去发现此类漏洞。代码分析可以很快速的展现出权限是否被正确的验证了。

技术影响:

       此种漏洞可以威胁到所有可以通过参数引用的数据。除非对象的引用是不可预知的。攻击者很容易访问到某个类型的所有数据。

业务影响:

       考虑暴露数据的商业价值，同时漏洞公开后造成的商业影响

攻击场景举例：

应用程序在SQL调用中使用未经过检查的数据去访问用户信息

        

String query = "SELECT * FROM accts WHERE account = ?";PreparedStatement pstmt = connection.prepareStatement(query , … );pstmt.setString( 1,<span style="color:#ff0000;"> request.getParameter("acct")</span>);ResultSet results = pstmt.executeQuery( );

攻击者在他们的浏览器中简单的修改"acct"参数发送任何他们想要的账户数字。如果不经检验，攻击者可以访问任何用户的账户，而不是预期客户的账户。

http://example.com/app/accountInfo?<span style="color:#ff0000;">acct=notmyacct</span>

我是否在“不安全的直接对象引用”漏洞上容易被攻击？

找出一个应用程序在"不安全的直接对象引用"中是否存在漏洞的途径就是确保所有对象的引用已经被适当防御了。这做到这点，需要考虑：

1.对保密资源的直接引用中，应用是否没有验证用户是否有权访问他们所请求的资源？

2.如果引用是一个非直接引用，是否其到直接引用的映射没有为当前用户限制那些授过权和没授过权的值。

代码评审可以快速检查出这两种做法是否是被安全地实现的。测试也对识别直接对象引用是否安全有效。自动检测工具通常不检查此种漏洞，

因为它们无法识别出什么需要保护或者什么是安全或者不安全的

我们应该怎么做？

防止不安全直接对象引用要求选择一种方法去保护每个用户可访问的对象(例如：对象数量，文件名称)：

1.使用每个用户或每个Session非直接对象引用。这可以防止攻击者直接命中未授权资源。例如，为当前用户使用一个包含6个已授权资源的下拉列表，可以使用1到6去指定用户所选择的那个资源，而不是直接使用数据库键去指定。应用需要在服务器上把每个用户的非直接引用映射到具体的数据库键。OWASP的ESAPI包含顺序和随机2中引用映射，开发人员可以使用它去消除直接对象引用

2..检查访问。 对于每个用户，每次使用来自不受信任来源的直接对象引用必须包括一个访问控制检查，以确保用户对请求的对象有授权

通过工作中的一个例子举例加深理解：

场景：比如我有一个已经登录的用户，其UserID记录在Session中，用户通过UserID去查询他所有的文章

比如查询链接形式 http://example.com?userID=123456

在后台如果我只检查了此用户是否登录，也就是检查Session中的UserID是否为空，不为空，则直接使用userID去数据库查询，

这就是一个不安全的直接引用。

如何让这种直接引用变安全呢？

1.让userID加密，在后台解密，之后再去数据库中使用解密的userID去查询，这样用户无法从页面上直接传入恰当的参数去找到想要的用户的数据。

2.在查询数据库之前，我需要对比这个通过连接传进来的userID是否和Session中记录的UserID一致，不一致就拒绝请求，不允许其访问不属于此用户的数据。

相比之下我还是觉得第二种做法是更好的。