xsrp/csrf 跨站請求偽造：xss利用站點內的信任使用者，而csrf則通過偽裝來自受信任使用者的請求來利用受信任的**。與xss攻擊相比，csrf攻擊往往不大流行（因此對其進行防範的資源也相當稀少）和難以防範，所以被認為比xss更具危險性。
1.驗證 http referer 字段：
要防禦 csrf 攻擊，銀行**只需要對於每乙個轉賬請求驗證其 referer 值，如果是以 ***xx開頭的網域名稱，則說明該請求是來自銀行**自己的請求，是合法的。如果 referer 是其他**的話，則有可能是黑客的 csrf 攻擊，拒絕該請求。
這種方法並非萬無一失。referer 的值是由瀏覽器提供的，雖然 http 協議上有明確的要求，但是每個瀏覽器對於 referer 的具體實現可能有差別，並不能保證瀏覽器自身沒有安全漏洞。使用驗證 referer 值的方法，就是把安全性都依賴於第三方（即瀏覽器）來保障，從理論上來講，這樣並不安全。事實上，對於某些瀏覽器，比如 ie6 或 ff2，目前已經有一些方法可以篡改 referer 值。如果 ***xx **支援 ie6 瀏覽器，黑客完全可以把使用者瀏覽器的 referer 值設為以 ***xx網域名稱開頭的位址，這樣就可以通過驗證，從而進行 csrf 攻擊。
2、在請求位址中新增 token 並驗證
csrf 攻擊之所以能夠成功，是因為黑客可以完全偽造使用者的請求，該請求中所有的使用者驗證資訊都是存在於 cookie 中，因此黑客可以在不知道這些驗證資訊的情況下直接利用使用者自己的 cookie 來通過安全驗證。要抵禦 csrf，關鍵在於在請求中放入黑客所不能偽造的資訊，並且該資訊不存在於 cookie 之中。可以在 http 請求中以引數的形式加入乙個隨機產生的 token，並在伺服器端建立乙個***來驗證這個 token，如果請求中沒有 token 或者 token 內容不正確，則認為可能是 csrf 攻擊而拒絕該請求。
3、在 http 頭中自定義屬性並驗證
這種方法也是使用 token 並進行驗證，這裡並不是把 token 以引數的形式置於 http 請求之中，而是把它放到 http 頭中自定義的屬性裡。通過 xmlhttprequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 http 頭屬性，並把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，通過 xmlhttprequest 請求的位址不會被記錄到瀏覽器的位址列，也不用擔心 token 會透過 referer 洩露到其他**中去。
ActiveX 安全問題
工作中寫了乙個mfc activex，測試的時候，發現ie6和ie8修改了安全設定後能夠正常執行，ie7和別的瀏覽器則始終無法正常執行，經過多方查詢，發現缺少一些安全資訊註冊，新增下列 後能夠正常執行了。首先定義三個函式 然後在stdapi dllregisterserver void 和stdap...
yii 安全問題
1.對於傳入的引數值，進行過濾，譬如分頁，排序等，如果傳入的引數，有乙個引數不在約定的陣列，則報錯，對於有一些值，譬如乙個頁的個數，這些也需要做限制，如果不在這個個數陣列中，則報錯 譬如 sortby get sort if in array sortby,title created at stat...
執行緒安全問題
執行緒安全問題導致的原因 當多條語句在操作同乙個執行緒共享資料時，乙個執行緒對多條語句只執行了一部分，還沒有徹底執行完畢，此時另乙個執行緒參與進來執行，導致共享資料的錯誤。執行緒安全解決辦法 對多條操作共享的語句，每次只能讓乙個執行緒執行完成。在執行的過程中，其他執行緒不可以參與執行。解決方案 同步...