gpt4 book ai didi

oracle - 在 Oracle VPD/RLS 中,如何防止恶意用户谓词泄露信息?

转载 作者:行者123 更新时间:2023-12-02 06:46:30 27 4
gpt4 key购买 nike

我一直在阅读 Oracle VPD(虚拟专用数据库,又名细粒度安全性,基于标签的安全性的基础)的文档,有一些东西我很难理解。 VPD如何防止用户利用WHERE中的恶意功能泄露信息条款?

假设您有一个 VPD 策略,它生成一个静态谓词,如 cust_no = SYS_CONTEXT('order_entry', 'cust_num'); (如 the Oracle VPD tutorial )。

这会导致查询被重写,因此:

SELECT * FROM orders;

变成:

SELECT * FROM orders 
WHERE cust_no = SYS_CONTEXT('order_entry', 'cust_num');

到目前为止还不错。但是如果用户写:

SELECT * FROM orders WHERE my_malicious_function(secret_column);

?哪里my_malicious_function将它看到的每个值插入到恶意用户控制的另一个表中,这样他们就可以通过选择该表来查看 secret 数据。

根据文档,VPD 重写器将生成如下内容:

SELECT * FROM orders 
WHERE cust_no = SYS_CONTEXT('order_entry', 'cust_num')
AND my_malicious_function(secret_column);

但 Oracle 可以自由地重新排序 WHERE 中的子条款。是什么阻止它运行my_malicious_function首先,它是否认为这将是更便宜或更具选择性的谓词? (当安全条件是 SYS_CONTEXT 查找时不太可能,但如果条件是针对另一个表的子查询,或者是 UDF 本身,则很可能)。

我已阅读文档,但没有看到它在哪里指定 VPD 谓词与用户提供的谓词的执行顺序保证。是否有这样的保证或任何其他机制来防止恶意谓词函数?

(我也很好奇,VPD 策略中的恶意谓词函数是否会导致特权用户通过生成引用恶意函数的谓词来运行他们不希望运行的用户提供的代码,但这在某种程度上是独立的。 )

最佳答案

“恶意函数”在应用VPD策略后运行,因此无法看到隐藏数据。

因此,在您的示例中,以下查询:

SELECT * FROM orders WHERE my_malicious_function(secret_column);

被重写为:

SELECT * FROM (
SELECT * FROM orders orders
WHERE cust_no = SYS_CONTEXT('order_entry', 'cust_num')
)
WHERE my_malicious_function(secret_column);

因此,该函数仅针对满足 VPD 谓词的行执行。

引用:http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_rls.htm#i1005326

When a table alias is required (for example, parent object is a type table) in the predicate, the name of the table or view itself must be used as the name of the alias. The server constructs the transient view as something like

select c1, c2, ... from tab tab where <predicate>

关于oracle - 在 Oracle VPD/RLS 中,如何防止恶意用户谓词泄露信息?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19786499/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com