Unsafe Reflection

ABSTRACT

攻擊者會創建一個意想不到且貫穿于整個應用程序的控制流路徑，從而逃避潛在的安全檢查。

EXPLANATION

若攻擊者可以為應用程序提供確定實例化哪個類或調用哪個方法的參數值，那么就有可能創建一個貫穿于整個應用程序的控制流路徑，而該路徑并非是應用程序開發者最初設計的。這種攻擊途徑可能使攻擊者避開 authentication 或 access control 檢測，或使應用程序以一種意想不到的方式運行。即使狡猾的攻擊者只能控制傳送給指定函數或構造函數的參數，也有可能會成功地發起攻擊。


例：應用程序采用反射技術的一個共同理由是實現自己的命令發送器。以下例子顯示了一個沒有使用反射的命令發送器：

var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var ctl:String = String(params["ctl"]);
var ao:Worker;
if (ctl == "Add) {
ao = new AddCommand();
} else if (ctl == "Modify") {
ao = new ModifyCommand();
} else {
throw new UnknownActionError();
    }
ao.doAction(params);

程序員可能會修改這段代碼，以便按照如下情況使用反射：

var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var ctl:String = String(params["ctl"]);
var ao:Worker;
var cmdClass:Class = getDefinitionByName(ctl + "Command") as Class;
ao = new cmdClass();
ao.doAction(params);

乍一看，這種修改似乎具有許多優點。代碼的行數比原先少了，if/else 代碼段也完全刪除了，而且還可以在不改變命令發送器的情況下增加新的命令類型。

然而，這種修改允許攻擊者將任意實現了 Worker 接口的對象實例化。如果命令發送器仍對 access control 負責，那么只要程序員創建實現 Worker 接口的新類，就務必要修改發送器的 access control 代碼。如果未修改 access control 代碼，那么一些 Worker 類就沒有任何 access control 權限。

解決 access control 問題的方法是讓 Worker 對象負責執行 access control 檢查。下面是一段重新修改的代碼：

var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var ctl:String = String(params["ctl"]);
var ao:Worker;
var cmdClass:Class = getDefinitionByName(ctl + "Command") as Class;
ao = new cmdClass();
ao.checkAccessControl(params);
ao.doAction(params);

雖然有所改進，但它鼓勵了采用分散化的手段進行 access control，這使程序員在 access control 上更加容易犯錯誤。

REFERENCES

[1] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A1 Unvalidated Input

[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A4 Insecure Direct Object Reference

[3] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A4 Insecure Direct Object References

[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3570 CAT I

[5] Standards Mapping - Security Technical Implementation Guide Version 3.4 - (STIG 3.4) APP3510 CAT I, APP3570 CAT I

[6] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 470

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.4

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.1

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.8

[10] Standards Mapping - FIPS200 - (FISMA) SI

97av