云计算安全 第二篇
1. 设计阶段的安全考虑
1.1. 清晰定义安全用例。用例设计要考虑所有的边界情况，覆盖所有可能的异常路径。（把异常路径写进用例中）
?
1.2. 统一的认证入口，或称单点登入。入口可以提供直接的认证方式（Form，Client Certificate）或者间接的（联邦）认证方式。所有的应用和服务都应当通过认证。
?
1.3. 单点注销。如果用户从入口点注销，那BSS需要引导用户把所有已经打开的应用都注销掉。
?
1.4. 服务器间调用的认证：
- 服务器间可以共享一对称密钥，调用方把用户ID用这个密钥加密后作为一个token放到HTTP请求头里，服务方解密即可。如果不能解密说明不是信任的服务器。
- 也可以用PKI密钥来完成。调用方使用服务方的公钥对用户ID做加密，用自己的私钥做签名，然后放到HTTP请求头里。
- 也可以建立一个STS服务。每一个调用方先到STS请求一个token，然后用这个token去访问服务方。
?
1.5. 信息保护
- 密码、秘密和token在存储的时候需要加密。
- 所有的传输都应该基于SSL。
- 富客户端、移动设备都应当存储共享密钥。
?
1.6. API访问
- OAuth，外部应用可使用OAuth。
- Basic Auth。
?
2. 代码安全标准2.1. XSS防护
XSS发生在用户的输入中，用户有可能在输入中带有一些java script，如果程序逻辑不对用户输入做任何过滤就返回到browser，那这些java script就会被执行，从而导致一些问题。
?
解决的策略就是不要把用户的输入原封不动得响应回去，而是对用户输入的内容做escape处理，如下面的代码：
?
?
2.2. CSRF防护
CSRF主要发生在一些关键性的REST API或敏感信息的输入请求上。现代浏览器都是多tab页的，tab页之间是可以共享cookie的。假设用户打开并登录某网银页面，同时在另外一个tab页上打开另外一个网站。这个网站上可能会有某个image tag，它实际指向的URL被写成了网银某REST API的请求。那么这个请求就会以合法用户的身份被网银接受。
?
解决的策略很简单，一般用双提交策略。在cookie里面放一个随机数，同时在请求里也放这个随机数即可。服务器端对这两个值做一下比对即可。
?
或者server生成一个随机数的密文，送给客户端。当请求过来的时候，看请求头里带过来的密文是否能被解开即可。
?
2.3. 慎重处理用户提供的File/URL
要慎重处理用户提供的URL。如果需要渲染用户提供的URL，只允许HTTP协议开头的URL。
不要让用户用相对路径访问到根目录，如../../../../../../../etc/passwd.
不要从服务器端访问用户提供的URL?
?
2.4. SQL注入
不要用字符串拼SQL，使用参数化的查询API。?
?
2.5. 用户上传文件
所有用户上传的文件要经过防毒软件过滤。
不要让用户直接下载其他用户上传的文件，因为他可能上传一个含有恶意代码的HTML文件，这样当用户下载这个HTML文件的时候，浏览器很可能直接就去渲染这个HTML文件了。
如果用户想下载HTML文件，Content-Type：application/x-download，Content-Disposition:attachment。
?
2.6. URL参数
?不用把用户信息（比如用户名，或者EMail）作为URL的参数出现。在URL参数中一般使用ID.
