SQL Server 安全篇——安全元資料（5）——元資料自身安全性
隨著元資料的使用頻率越來越高，安全性也越來越凸顯，因為從元資料中可以得到很多不應該隨意暴露的系統資訊。所以，絕大部分的元資料並不能隨意被檢視，通常都需要授權。
比如當一個使用者A被授權查詢B表，那麼這個使用者A就自動獲得了在sys.tables和sys.objects中關於B表的資訊。否則他無法真正使用這個B表。
如果需要檢視那些沒有許可權訪問的物件的元資料，可以使用VIEW DEFINITION許可權來實現。VIEW DEFINITION可以授權到庫層面或者例項層面，如果是例項層面，可以通過檢視整個例項的元資料來實現某些元資料驅動的自動化指令碼。同時也不需要過度授權。
由於某些物件屬於許可權結構之外，所以這些物件並不能制動授予VIEW DEFINITION許可權，以分割槽為例。每個表可以跨三個分割槽進行拆分: 一個用於行內（in-row）資料, 另一個用於 LOB (大物件) 資料, 第三個用於overflow資料。因為它們不能直接訪問，所以無法對分割槽分配許可權。
在這種情況下，每個登入必須具有的public角色就可以用來檢視關聯的元資料，這個是VIEW DEFINITION不能做到的。public可以看到的元資料有：
- sys.partition_functions
- sys.partition_range_values
- sys.partition_schemes
- sys.data_spaces
- sys.filegroups
- sys.destination_data_spaces
- sys.database_files
- sys.allocation_units
- sys.partitions
- sys.messages
- sys.schemas
- sys.configurations
- sys.sql_dependencies
- sys.type_assembly_usages
- sys.parameter_type_usages
- sys.column_type_usages
但是正如上面說的，可見則存在風險。特別是對SQL注入防範比較差的應用，假設攻擊者通過SQL注入在AdventureWorks2016上執行下面語句：
SELECT 1 + name FROM sys.tables 
這種方式叫“Forced error message”，姑且直譯為“強制錯誤資訊”或者“強制資訊披露”，這些錯誤資訊暴露了以下可用於攻擊的資訊：
- 資料庫中有一個表叫SalesTaxRate。
- 應用程式可以查詢某些元資料。
- 應用程式可能以高許可權帳號執行。
這些資訊怎麼用呢？比如，如果應用程式總是以單使用者執行（假設一直都用sa來使用資料庫），那麼總有一些表是允許這個使用者訪問甚至操作的。然後通過修改查詢， 使其按包含萬用字元字串%user% 或%login% 的表進行篩選。一旦得到了資訊，那麼就可以開始攻擊或者篡改資訊。
這個故事說明，不要總是把安全性歸咎在資料庫上面，系統就是一個完整的體系，環環相扣。所以不僅帳號要有許可權控制，元資料和應用程式都應該要有許可權控制，核心原則還是最小許可權控制。