當今大多數web應用程式都需要至少採用某種基本的安全策略。例如，提供用口令保護的內容的**、僅具有管理員後端的**、網誌和個人雜誌、電子商務**、企業內聯網，等等。
構建這些型別的web應用程式最常用的設計方法是將安全策略整合到web應用程式的業務邏輯中，即由應用程式決定某個使用者是否有權訪問資料庫中的某個資料。在這種情形下，資料庫的角色僅為儲存資料和依請求提供資料。換句話說，如果web應用程式命令資料庫提供特定資訊，則資料庫會直接執行該命令而不檢查使用者的許可權。
在該文中，您將學習如何利用oracle
內建的安全特性在資料庫級執行應用程式安全規則，以提高應用程式的整體安全性。作為附帶的好處，直接在資料庫中實現資料訪問安全不但有助於提高應用程的安全性，而且有助於降低複雜性。
對資料庫端安全性的需求
假設建立乙個內容管理系統(cms)。其中使用資料庫來儲存**上發布的內容。大部分資料是公開的，允許匿名web使用者讀取；但只允許編輯更改資料。使用單一資料庫帳戶訪問和修改資料庫中的記錄，並通過用口令保護僅管理員可以訪問的頁面的訪問許可權用php**控制安全性。
如果web應用程式的公共端遭受了乙個諸如公共搜尋表單（即編碼不夠嚴密的表單）上的sql注入的攻擊，則該入侵者可能能夠對該公共帳戶可以訪問的資料庫物件執行任意sql語句。當然，就這裡的情形而言，執行select語句不會造成什麼大問題，這是因為資料本來就是公共的。但由於公共許可權和管理許可權使用同一資料庫帳戶，因此入侵者還能執行update和delete語句，甚至是從資料庫中刪除表。
怎麼才能防止該情況的發生呢？最簡單的方法就是徹底限制公共資料庫帳戶修改資料的許可權。我們來看看oracle是如何解決這個問題的。
oracle安全性基本概述
oracle資料庫為web開發人員提供了控制資料訪問的許多方法，從管理對特定資料庫物件（如表、檢視和過程）的訪問到控制個別行或列的資料的訪問。很顯然，對oracle每個安全特性或可用選項的討論超出了本文的範圍。在這裡，我們將不涉及過多細節，而僅介紹oracle資料訪問安全性的最基本方面：
驗證和使用者帳戶 許可權
角色 驗證和使用者帳戶。與其他資料庫一樣，請求訪問oracle的每個使用者（資料庫帳戶）必須通過驗證。驗證工作可以由資料庫、作業系統或網路服務來做。除基本的驗證（口令驗證）外，oracle還支援強驗證機制，如kerberos、cybersafe、radius，等等。
角色。oracle角色是乙個許可權的有名集。儘管可以直接授予使用者帳戶許可權，但使用角色可以極大簡化使用者管理，尤其是需要管理大量使用者時。建立易管理的小角色，然後根據使用者的安全級別授予使用者乙個或多個角色，這樣做的效率非常高。更不用說修改許可權變得如何簡單了—只需修改角色關聯的角色即可，無需修改每個使用者帳戶。
為了簡化新使用者建立初期的工作，oracle自帶了三個預定義的角色：
connect角色—該角色使使用者可以連線資料庫以及執行基本的操作，如建立自己的表。預設情況下，該角色不能訪問其他使用者的表。
resource角色—resource角色與connect角色相似，但它允許使用者擁有較多的系統許可權，如建立觸發器或儲存過程。
dba角色—允許使用者擁有所有系統許可權。
使用中的授權和許可權
在本部分中，我們將討論如何使用oracle的授權和許可權來提高本文開頭部分討論的那個簡單cms示例的安全性。假定，提供給應用程式使用者的內容儲存在web_content表中。
現在，可以使用物件瀏覽器或通過執行sqlcommands視窗建立新錶。下面是建立該錶的**：
createtableweb_content(
page_idnumberprimarykey,
page_contentvarchar2(255)
由於該表是使用hr使用者帳戶建立的，因此該錶歸hr帳戶所有並位於hr模式中，並且在明確授予其他使用者訪問該錶的許可權前，其他使用者無法訪問該錶。如果不信，可以建立乙個新使用者，用該使用者訪問web_content表試試。
現在，建立兩個新使用者，cms_user和cms_editor。最終，將授予cms_user對web_content表的唯讀許可權，並將該使用者用作為匿名web使用者提供內容的資料庫帳戶。cms_editor帳戶將在該錶上擁有更多許可權，將被用作cms編輯的帳戶（該帳戶需要更改和維護該表中的資料）。
可以使用xe的圖形介面或通過執行以下命令建立新使用者：
createusercms_useridentifiedbycms_user;
createusercms_editoridentifiedbycms_editor;
（出於簡化的目的，此處的口令與使用者名稱對應。）
為了讓這兩個帳戶都登入資料庫，我們需要賦予它們connect角色。為此，在xe圖形介面的administration/databaseusers部分選中使用者資訊下的connect核取方塊，或執行以下命令：
grantconnecttocms_user;
grantconnecttocms_editor;
現在，如果嘗試以cms_user或cms_editor使用者登入並試圖從web_content表讀取資料(select*fromhr.web_content;)，將遇到以下錯誤：
ora-00942:tableorviewdoesnotexist
為了訪問資料或僅是看到表，需要授予cms_user和cms_editor帳戶對web_content表的唯讀許可權：
grantselectonhr.web_contenttocms_user;
grantselectonhr.web_contenttocms_editor;
以上**使這兩個帳戶可以對web_content表執行select語句。如果嘗試執行其他語句，則會遇到錯誤。例如，插入一行：
insertintohr.web_content(page_id,page_content)values(1,'helloworld');
將產生錯誤訊息
ora-01031:insufficientprivileges
要允許cms_editor更改該錶的內容，需要授予以下許可權：
grantinsert,update,deleteonhr.web_contenttocms_editor;
從現在起，cms_editor帳戶可以對web_content表執行insert、update和delete語句。
您看，這有多簡單！可見通過角色管理許可權是更有效的方法。如果使用的oracle資料庫不是xe，可以執行如下操作：
建立角色：
createrolereader;
createrolewriter;
授予角色許可權：
grantselectonweb_contenttoreader;
grantinsert,update,deleteonweb_contenttowriter;
賦予使用者角色：
grantreadertocms_user;
grantreadertocms_editor;(theyneedtoreadtoo)
grantwritertocms_editor;
請注意，如果更改reader角色的定義，則這些更改會影響所有具有該角色的使用者帳戶。如果是直接將許可權授予使用者的，則必須逐個更新每個使用者帳戶。
完成上述步驟後，可以配置php應用程式，使之對由匿名web使用者請求的所有資料庫連線均使用cms_user帳戶，對由受口令保護的管理頁面引發的連線使用cms_editor帳戶。現在，即使公共web表單受到攻擊，該攻擊對資料庫的影響將微乎其微，這是因為cms_user帳戶僅具有唯讀許可權。結論
在本文中，我們只是簡單介紹了oracle資料訪問安全性的一些最基本的特性。此外，oracle還有許多其他特性，可把您的web應用程式的安全性提高到乙個新的等級—包括虛擬專用資料庫(vpd)和標籤安全性。
新特性速遞 將純色背景轉換為內建主題！
fineuipro mvc core js的下個版本 v6.3.0 我們會將目前的自定義純色背景 pure black,pure green,pure blue.轉換為內建主題。為了應對這個變化，你需要做如下幾個步驟 1.刪除 res themes pure black 等以 pure 開頭的 6 ...
併發安全的特性 原子性 鎖
jdk為我們提供了兩種我們比較常見的鎖，分別是 第一種，就是我們比較熟悉的synchronized 依賴於jvm的關鍵字。第二種，是lock 依賴特殊的cpu指令，實現，reektrantlock。主要有以下幾種使用方法 大括號括起來的 作用於呼叫的物件。指定加鎖物件，對給定物件加鎖，進入同步 庫前...
Oracle資料安全的維護
oracle資料安全的維護 記得某位哲學家說過 事物的變化離不開內因和外因。那麼對於 oracle資料安全這個話題而言，也勢必分為 內 和 外 兩個部分。那麼好，我們就先從 內 開始說起 1.從oracle系統本身說起 我們先拋開令人聞風色變的 hacker 和其他一些外部的原因，先想一下我們的資料...