密碼學經典誤區

口令和密碼不應誤用。口令不涉及加解密，也不是密文。整個過程只涉及hash。
密鑰而不是密碼算法決定安全性。
古典加密的特征是，加密字符而非比特。

PGP優良保密協議

信安經典

可靠性，天災人禍時還能不能用。
可用性，四個九。
保密性，只有該看的人能看見。
完整性，傳輸錯誤、人為篡改。
不可抵賴，你發過、你收過、你說過。
可控性，信息不會到不該去的地方。

其它安全手段

除了上圖的對稱/非對稱加密、摘要、簽名等密碼學手段，
主要的安全手段還有正確配置（比如不允許root遠程登錄，關閉不必要端口等），正確使用加密api（認證函數要自己實現不要留一段注釋然后return true，使用合適的密碼學算法，正確生成參數等），安全審計（日志），版本更新（如漏洞修補，放棄兼容有安全問題的舊版本等），用戶管理（如臨時權限，定期更換密碼等）。

XSS與CSRF cross site request forgery

（CSRF有關內容均來自CSRF百度百科https://baike.baidu.com/item/%E8%B7%A8%E7%AB%99%E8%AF%B7%E6%B1%82%E4%BC%AA%E9%80%A0/13777878）
XSS 利用的是用戶對指定網站的信任，CSRF 利用的是網站對用戶網頁瀏覽器的信任。

CSRF的利用邏輯

簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自愿發出的。

CSRF示例

假如一家銀行用以運行轉賬操作的URL地址如下：http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
那么，一個惡意攻擊者可以在另一個網站上放置如下代碼： <img src=“http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman”>
如果有賬戶名為Alice的用戶訪問了惡意站點，而她之前剛訪問過銀行不久，登錄信息尚未過期，那么她就會損失1000資金。
這種惡意的網址可以有很多種形式，藏身于網頁中的許多地方。此外，攻擊者也不需要控制放置惡意網址的網站。例如他可以將這種地址藏在論壇，博客等任何用戶生成內容的網站中。這意味著如果服務端沒有合適的防御措施的話，用戶即使訪問熟悉的可信網站也有受攻擊的危險。
透過例子能夠看出，攻擊者并不能通過CSRF攻擊來直接獲取用戶的賬戶控制權，也不能直接竊取用戶的任何信息。他們能做到的，是欺騙用戶瀏覽器，讓其以用戶的名義運行操作。

CSRF防范

檢查Referer字段

HTTP頭中有一個Referer字段，這個字段用以標明請求來源于哪個地址。在處理敏感數據請求時，通常來說，Referer字段應和請求的地址位于同一域名下。以上文銀行操作為例，Referer字段地址通常應該是轉賬按鈕所在的網頁地址，應該也位于www.examplebank.com之下。而如果是CSRF攻擊傳來的請求，Referer字段會是包含惡意網址的地址，不會位于www.examplebank.com之下，這時候服務器就能識別出惡意的訪問。
這種辦法簡單易行，工作量低，僅需要在關鍵訪問處增加一步校驗。但這種辦法也有其局限性，因其完全依賴瀏覽器發送正確的Referer字段。雖然http協議對此字段的內容有明確的規定，但并無法保證來訪的瀏覽器的具體實現，亦無法保證瀏覽器沒有安全漏洞影響到此字段。并且也存在攻擊者攻擊某些瀏覽器，篡改其Referer字段的可能。

添加校驗token

由于CSRF的本質在于攻擊者欺騙用戶去訪問自己設置的地址，所以如果要求在訪問敏感數據請求時，要求用戶瀏覽器提供不保存在cookie中，并且攻擊者無法偽造的數據作為校驗，那么攻擊者就無法再運行CSRF攻擊。這種數據通常是窗體中的一個數據項。服務器將其生成并附加在窗體中，其內容是一個偽隨機數。當客戶端通過窗體提交請求時，這個偽隨機數也一并提交上去以供校驗。正常的訪問時，客戶端瀏覽器能夠正確得到并傳回這個偽隨機數，而通過CSRF傳來的欺騙性攻擊中，攻擊者無從事先得知這個偽隨機數的值，服務端就會因為校驗token的值為空或者錯誤，拒絕這個可疑請求。

XSS cross site scripting

https://www.jianshu.com/p/4fcb4b411a66
（我的描述非常不嚴謹，純粹是為了好記。原理、 示例、防范可參考上面的鏈接）
反射型XSS，比如，在搜索框里輸入了js代碼，如果網站沒有防范，會執行這個代碼。
存儲型XSS，如果用戶的輸入會被存儲到文件/數據庫中，且用戶輸入是js代碼，那么其它用戶訪問網站時，由于也會加載文件/數據庫，每次訪問都會執行這個代碼。

common weakness enumeration

https://cwe.mitre.org/

常見密碼api誤用（摘自畢設參考文獻）

對稱加密

Use a Non-Random IV for CBC Encryption （字典攻擊）
Use ECB-Mode for Encryption （選擇明文攻擊。在java/android中，cipher.getinstance如果不指定模式和IV，會默認使用ECB模式）
Insufficient Key Length （128位以下的密鑰面臨暴力破解）
Use a Risk or Broken Algorithm for Symmetric Encryption （如DES）
Use the Same Cryptographic Key Multiple Times or Hard-Coded Crptographic Keys for Encryption

hash

Use a Risk or Broken Algorithm （如MD4，MD5）

非對稱加密

Inadequate Key Length （比如RSA，現在推薦2048位）
RSA Algorithm without OAEP （Optimal Asymmetric Encryption Padding，若不支持會削弱安全性）

Improper Certificate Validation

Missing Validation of Certificate
Improper Check for Certificate Revocation（撤銷）
Improper Validation of Certificate Expiration
Improper Validation of Certificate with Host Mismatch
Improper Following of a Certificate’s Chain of Trust

密鑰管理

Reusing a Nonce, Key Pair in Encryption （重放攻擊）
Use of a Key Past its Expiration Date （擴大了攻擊窗口）

安全建議

如選用基于口令的算法或在用戶輸入密碼時，請避免使用String來引用，使用char[]，用完立刻置空char[]，避免內存攻擊，如heap dump分析等。