漏洞分析連載第十四期 | 拘於小節的呼叫許可權，函式呼叫許可權漏洞
引子：天下難事，必作於易，天下大事，必作於細 —— 《道德經·第六十三章》
前情提要ofollow,noindex" target="_blank"> 上回書，邏輯判斷失誤事與願違，功能實現不周弄巧成拙
自1995年尼克薩博第一次提出智慧合約理念以來，智慧合約的功能延展越來越迅速，程式碼邏輯功能也越來越複雜。在開發的過程中，由於欠缺全域性考慮和邏輯測試，非常容易出現邏輯判斷和功能實現的不理想，導致合約的正常功能出現異常甚至產生可以被攻擊者繞過的邏輯漏洞。稽核程式碼的通篇邏輯或者從歷史教訓中汲取開發經驗成為規避此類漏洞最有效，可行的方案。
本期話題
可見修飾字斟句酌，函式呼叫約法三章
自由與限制，兩個矛盾又相輔相成的狀態。有人言，沒有限制的自由不是真正的自由。正如《海上鋼琴師》的臺詞：“鋼琴有低音的開頭，也有高音的結束，八十八個琴鍵是有限的，卻可揮灑出無限的動人音符，我喜歡這說法，這也是我生存的方式…陸地對我而言就是一艘大船，這世界上有數以千計的街道，而你要如何走到盡頭，你要如何選擇一個妻子，一棟房子，一幅風景，甚至何種方式死去？這些在我面前就像無窮多琴鍵的鋼琴，但我卻一個音符也彈不出來…”當自由掙脫限制的束縛，會讓人感到恐懼和迷茫。
自由和限制的關係，也正是科技發展和安全的關係。合約安全的精髓就是限制及控制理念，精確的附加限制條件是防禦安全漏洞的有效手段。在函式呼叫許可權的問題上，正確新增函式說明符或者修飾符來控制呼叫的範圍和許可權，是協助預防攻擊者呼叫重要和敏感的函式的“保護傘”。
基礎知識
函式可見性說明符（Function Visibility Specifiers）和函式修飾符（Function Modifiers）都可以歸納為修飾函式的成分，為了區分我們分開講解兩個概念：
- 什麼是函式可見性說明符（Function Visibility Specifiers）？
Solidity有兩種函式呼叫方式，一種是內部呼叫，不會建立一個EVM呼叫（也叫做訊息呼叫），另一種則是外部呼叫，會建立EVM呼叫（會發起訊息呼叫）。Solidity對函式和狀態變數提供了四種可見性。分別是external,public,internal,private。其中函式預設是public。
external
- 宣告為external的函式可以從其它合約或通過Transaction進行呼叫，所以宣告為external的函式是合約對外介面的一部分。
- 不能直接進行內部呼叫。
- 函式預設宣告為public。
- public的函式既允許內部呼叫，也允許外部呼叫。
- public的函式由於被外部合約訪問，是合約對外介面的一部分。
public
internal
- 在當前的合約或繼承的合約中，只允許內部呼叫。
- 只能在當前合約中被訪問（不可在被繼承的合約中訪問）。
- 即使宣告為private，仍能被所有人檢視到裡面的資料。訪問許可權只是阻止了其它合約訪問函式或修改資料。
private
由於變數的可見性說明符與函式類似，這個特殊情況也可以造成變數的外部讀取，我們在第九期重點解析了這個問題，請移步： https://mp.weixin.qq.com/s/hP_Cc2CiqFyrnYqK9W_3nQ- 什麼是函式修飾符（Function Modifiers）
修飾符可以用來輕鬆改變函式的行為，比如在執行的函式之前自動檢查條件。他們可繼承合約的屬性，也可被派生的合約重寫。除了官方的一些修飾符，例如，view（函式不會更改和儲存任何資料）；pure（函式既不會往區塊鏈寫資料，也不從區塊鏈讀取資料）之外，我們還有自定義修飾符，用來自定義其對函式的約束邏輯。這些函式可以同時作用於一個函式，例如：
function test() external view oneModifier anotherModifier限制缺失，函式迷失
從上面的知識我們可以總結，可見性說明符和函式修飾符直接關係到函式可以被誰呼叫。如果重要和敏感函式缺少相關的修飾成分，就可能淪為攻擊者不勞而獲的工具。如同各種電影動漫中神祕的力量需要被封印一樣，不能正確限制這種力量，勢必帶來無法挽回的後果。
函式呼叫許可權漏洞
我們按照可見性說明符和修飾符將漏洞分為兩類：
- 可見性許可權漏洞
在基礎知識中我們提到，函式預設的可見性為public，允許使用者從外部呼叫它們。可見性說明符的不正確使用可能會導致智慧合約中的資金流失：
- 錯誤程式碼示例
函式的預設可見性是public，意味著任何人都可以操作上面的_transfer函式，實現不需要授權就可以轉走他人的代幣。
- 呼叫許可權不符
部分敏感函式需要onlyOwner許可權，如果該函式忘記新增onlyOwner函式修飾器，那麼任何人都可以操作該函式，破壞合約執行邏輯。
- 錯誤程式碼示例
setOwner() 函式的作用是修改 owner，通常情況下該函式只有當前 owner 可以呼叫。 但問題程式碼中，任何人都可以呼叫 setOwner() 函式，這就導致了任何人都可以修改合約的 owner。 該問題本質上是函式呼叫許可權不符的漏洞。
- 漏洞修復
水能載舟，亦能覆舟
實現函式重要功能的環節變為使專案功虧一簣的致命漏洞，這是所有人不願意看到的。
開發過程中準確理解函式執行的安全範疇，在充分理解智慧合約知識的基礎上加以精確的許可權控制，是防止合約函式功能被利用的重要舉措。同時，許可權的控制需要對合約邏輯的全面理解以及細節掌握。在智慧合約開發時，注意細微之處的重要許可權相關問題，才能實現合約真正的自由發展。
結語：夫禍患常積於忽微,而智勇多困於所溺。
引用：
[1]: solidity中的函式修飾符
https://steemit.com/solidity/@a186r/solidity
[2]: 函式修改器(Function Modifiers)
http://www.tryblockchain.org/Solidity-FunctionModifiers-%E5%87%BD%E6%95%B0%E4%BF%AE%E6%94%B9%E5%99%A8.html
[3]: 深入理解Solidity——函式修飾符:
https://blog.csdn.net/qq_33829547/article/details/80378135
[4]: 【Solidity入門系列】函式的可見性與訪問許可權控制
http://me.tryblockchain.org/solidity-function-advanced1.html
[5]: 可見性或許可權控制(Visibility And Accessors)
http://www.tryblockchain.org/Solidity-VisibilityandAccessors-%E5%8F%AF%E8%A7%81%E6%80%A7%E5%92%8C%E8%AE%BF%E9%97%AE%E6%8E%A7%E5%88%B6%E5%99%A8.html
作者：成都鏈安科技 如需轉載請聯絡原作者
[6]: CVE-2018-10705 Detail
https://nvd.nist.gov/vuln/detail/CVE-2018-10705