文章目录
- 密码学经典误区
- PGP优良保密协议
- 信安经典
- 其它安全手段
- XSS与CSRF cross site request forgery
- CSRF的利用逻辑
- CSRF示例
- CSRF防范
- 检查Referer字段
- 添加校验token
- XSS cross site scripting
- common weakness enumeration
- 常见密码api误用（摘自毕设参考文献）
- 对称加密
- hash
- 非对称加密
- Improper Certificate Validation
- 密钥管理
- 安全建议
密码学经典误区
口令和密码不应误用。口令不涉及加解密，也不是密文。整个过程只涉及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分析等。
)
