Web系統(tǒng)因為是面向Internet/Intranet的，所以其安全性比常規(guī)的應用程序系統(tǒng)更難以保證。
在談到其安全性的時候，很多的都是從“網(wǎng)絡安全”的角度去看待問題，殊不知，堡壘
的內(nèi)部是最最不安全的。對付“黑客攻擊”是系統(tǒng)管理員所要面對的問題，而如何更好的
加強堡壘內(nèi)部自身的安全，是在Web程序的設(shè)計中就需要考慮的問題。
系統(tǒng)管理員所要面對的網(wǎng)絡攻擊、操作系統(tǒng)?安全不是我所考慮的問題，如何加強Web系統(tǒng)
自身的健康是我所最最關(guān)心的事情。?
從“構(gòu)造URL”攻擊到“注入SQL文”攻擊，都是屬于過分信任用戶輸入，而造成的安全問題。
這恰恰應該是由應用程序自身加以重視、解決的問題。
基于角色的安全控制已經(jīng)逐漸的被大家逐漸的接受，每個用戶被分配為不同的角色，不同的角色
具有不同的操作權(quán)限。 但是如何劃分角色、用戶、操作權(quán)限，則是需要認真對待的問題。
舉例：
一個MIS系統(tǒng)中，員工有查詢工資的權(quán)限，但是某個員工是否具有查詢其他員工的權(quán)限呢？
不能深入的追問問題，詳細的分辨清楚系統(tǒng)中到底有多少角色、每個用戶所在的角色，是不能完成安全控制的。
btw:?以上的問題，大家不妨在自己的類似系統(tǒng)中自己去檢查一下，有此問題的占絕大多數(shù)吧。
看過此文的，愿意回答“是”“否”的，可以留言，?也當作一個調(diào)查吧。
上面的這個例子，就是一個很成熟的辦公系統(tǒng)中存在的問題。使用客戶端script腳本，控制了用戶的界面操作，殊不知maxthon就可以解除這個限制。此系統(tǒng)中，用戶的請求都被整理為URL（get方式提交），雖然URL中的鍵值含義并不是很明顯，但是還是可以嘗試著去攻擊，獲取秘密。
認真的核查用戶的輸入，利用AOP部署，細密的對用戶的輸入進行核查，是很有必要的事情。
某個人、某個資源、某個操作，這三個要素組織在一起則是：某個人對某個資源進行某項操作
實際情況下，許多人、許多資源、對每個資源冰存在著多個操作。
將人、資源、操作進行劃分，可以得到：
具體的某一類人，可以對某些資源，進行某些的操作＝》 這就是具體的某項權(quán)限限制。
??? 某一類人，則可以歸納為角色。
??? 對某些資源的某些操作，則可以歸納為工作任務。
也就是說，整個系統(tǒng)是“某個角色去完成某些工作任務，而具體的一個帳戶屬于某個角色，某項工作則具體的是指對某個資源進行某個操作”。
相對來說，系統(tǒng)中的人員是最容易辨認的，系統(tǒng)中的資源也是可以在系統(tǒng)的功能調(diào)查時分清楚的，系統(tǒng)中的操作則是最復雜、最難分清晰，甚至在系統(tǒng)完成時都會變化的。
只有分辨清楚了系統(tǒng)中的人、資源、操作，才能辨別清楚系統(tǒng)中的具體的權(quán)限限制。
“基于角色的安全控制”這樣的提法，只提及了人，未能強調(diào)將資源、操作進行規(guī)類，這是很不充分的一種提法。
在Web系統(tǒng)中，系統(tǒng)在設(shè)計的過程中，就分清楚資源，分清楚操作，極大縮小每個頁面的功能、提高頁面功能的原子性，這也是權(quán)限控制對系統(tǒng)設(shè)計提出的一項要求。
前面提及使用AOP進行權(quán)限控制，現(xiàn)在簡述一下各部件的功能：
?? 業(yè)務模塊－－完成具體的對某個資源的操作；
?? 前臺頁面模塊－－ 完成整體頁面的整合；
?? 安全控制模塊－－實現(xiàn)安全控制功能，完成人員、角色、工作的邏輯判斷；
?? AOP配置整合模塊－－粘合安全控制模塊和業(yè)務模塊；
在于如何去解決，而是如何去發(fā)現(xiàn)。隱藏起來的問題更是危險。
而如何發(fā)現(xiàn)問題，則完全是一個素質(zhì)、能力的事情，也許這是下一個話題。