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