cas 的安全性是乙個非常重要的 topic 。 cas 從 v1 到 v3 ，都很依賴於 ssl ，它假定了這樣乙個事實，使用者在乙個非常不安全的網路環境中使用 sso ， hacker 的 sniffer 會很容易抓住所有的 http traffic ，包括通過 http 傳送的密碼甚至 ticket 票據。
tgc/pgt 安全性
對於乙個 cas 使用者來說，最重要是要保護它的 tgc ，如果 tgc 不慎被 cas server 以外的實體獲得， hacker 能夠找到該 tgc ，然後冒充 cas 使用者訪問所有授權資源。
sso 的安全性問題比普通應用的安全性還要嚴重，因為 sso 存在一種門檻效應。以前即使 hacker 能夠截獲使用者在 web 應用 a 的密碼，它也未必能知道使用者在 web 應用 b 的密碼，但 sso 讓 hacker 只需要截獲 tgc( 突破了門檻 ) ，即能訪問所有與該使用者相關的所有應用系統。
pgt 跟 tgc 的角色是一樣的，如果被 hacker 獲得，後果可想而知。
從基礎模式可以看出， tgc 是 cas server 通過 ssl 方式傳送給終端使用者，因此，要擷取 tgc 難度非常大，從而確保 cas 的安全性。
因此，某些人認為 cas 可以不使用 ssl 的想法需要更正一下， cas 的傳輸安全性僅僅依賴與 ssl 。
跟 kerberos 一樣 tgt ， tgc 也有自己的存活週期。下面是 cas 的 web.xml 中，通過 grantingtimeout 來設定 cas tgc 存活週期的引數，引數預設是 120 分鐘，在合適的範圍內設定最小值，太短，會影響 sso 體驗，太長，會增加安全性風險。
edu.yale.its.tp.cas.grantingtimeout
7200
tgc 面臨的風險主要並非傳輸竊取。比如你登陸了之後，沒有 logout ，離開了電腦，別人就可以開啟你的瀏覽器，直接訪問你授權訪問的應用 ) ，設定乙個 tgc 的有效期，可以減少被別人盜用，或者被 hacker 入侵你的電腦直接獲取你系統目錄下的 tgc cookie 。
service ticket/proxy ticket 安全性
首要明白， service ticket 是通過 http 傳送的，以為著所網路中的其他人可以 sniffer 到其他人的 ticket 。
cas 協議從幾個方面讓 service ticket 變得更加安全。
lservice ticket 只能使用一次。
cas 協議規定，無論 service ticket 驗證是否成功， cas server 都會將服務端的快取中清除該 ticket ，從而可以確保乙個 service ticket 被使用兩次。
lservice ticket 在一段時間內失效。
假設使用者拿到 service ticket 之後，他請求 helloservice 的過程又被中斷了， service ticket 就被空置了，事實上，此時， service ticket 仍然有效。 cas 規定 service ticket 只能存活一定的時間，然後 cas server 會讓它失效。通過在 web.xml 中配置下面的引數，可以讓 service ticket 在多少秒內失效。
edu.yale.its.tp.cas.servicetimeout
300
該引數在業務應用的條件範圍內，越小越安全。
lservice ticket 是基於隨機數生成的。
service ticket 必須足夠隨機，如果 service ticket 生成規則被猜出（如果你使用了 st+helloservice+ 自增序列的方式， hacker 就可以構造下乙個 ticket ）， hacker 就等於繞過 cas 認證，直接訪問所有服務。
CAS安全性介紹
cas 的安全性是乙個非常重要的 topic cas 從 v1 到 v3 都很依賴於 ssl 它假定了這樣乙個事實，使用者在乙個非常不安全的網路環境中使用 sso hacker 的 sniffer 會很容易抓住所有的 http traffic 包括通過 http 傳送的密碼甚至 ticket 票據。...
mysql安全性試驗 Mysql安全性測試
一 沒有進行預處理的sql語句 1.連線資料庫 conn mysql connect 127.0.0.1 3306 root 518666 if conn die could not connect mysql error 2.選擇資料庫 mysql select db mysql safe con...
安全性測試
1.url哪些引數可以放進去，哪些不可以放。後面的id 可以隨便改，可以查所有活動。url作處理 後端限制。編輯 時，不應帶有 id，防有人改id編輯其它人的 加密。比如每個使用者金鑰都不一樣，很難破解。2.有些操作自已去資料庫確認，而不靠control層。比如，編輯活動時活動時，活動還沒有開始，但...