4. 传输层安全
对于WEB传输层安全，首当其冲的就是基于HTTPS协议的SSL/TLS协议。SSL（Transport Layer Security）安全套接字层协议，TLS传输层安全性。SSL有v1.0、v2.0、v3.0和v3.1 4个版本号，其中仅有v3.1版本是安全的。支持SSL协议的服务器包括： Tomcat 5.x、Nginx、IIS、 Apache 2.x、IBM HTTP SERVER 6.0等。TLS （Transport Layer Security）有v1.0、v1.1、v1.2 3个版本号。SSL v3.1与TLS v1.0是等效的。下面从安全服务设计、服务端安全证书配置和服务器协议和密码设置来进行讨论基于HTTPS协议的安全性。
1）安全服务设计
- 在任何地方都要使用SSL/TLS进行安全传输。包括内部网络和外部网络。否则容易引起信息的窃取。
- 不要为HTTPS页面提供HTTP访问。本应还是https://www.mtdomain.com的网站被用户误输入https://www.mtdomain.com，照样可以访问。
- 不要混合使用SSL/TSL非SSL/TSL。不要在SSL/TSL页面包含非SSL/TSL传输的内容，否则容易引起信息的泄露。
- Cookie使用Secure属性。这点已经在会话管理中描述过。
- 不要将敏感数据存在URL中。
- 防止敏感数据缓存。
- 使用HSTS(HTTP Strict Transport Security)安全响应头，其目的是为了阻止HTTP传输。
- 使用HPKP(Public Key Pinning Extension for HTTP)全响应头，其目的是加强HTTPS抵御攻击能力。
2）服务器端安全证书配置
- 使用安全的非对称密钥对，正如12.14-1中对称加密与非对称加密章节中介绍，非对称加密比对称加密更为安全。
- 使用支持域名的证书。
- 在证书中使用完全限定名称，注意不要用localhost或类似192.168.1.1私有地址的证书
- 不要使用通配符证书：比如“*”。
- 使用适当的证书颁发机构，不要使用自签名的证书。在浏览器打开HTTPS网站，然后点击地址栏前面的小锁图标，点击证书就可以看到网站证书的颁发机构。47为百度搜索引擎的安全证书。
47 百度搜索引擎的安全证书
- 始终提供所需要的证书。
- 启用SHA-256证书，禁用SHA-1证书。正如3.14-1-2)区块链的私钥、公钥和地址中个所述，SHA-1会发生哈希碰撞，已经被证明不安全。
3）服务器协议和密码设置
- 仅支持强协议，就SSL/TSL而言。
Ø 不要使用SSLv1~SSLv3，因为已经发现这三个版本存在缺陷。
Ø 建议仅支持TLS协议 TLSv1.0, TLSv 1.1, TLSv 1.2协议。
Ø 浏览器不要将TLS1.0协议视为最佳协议。原因是现在发现TLS1.0协议容易遭受CBC Chaining攻击和Padding Oracle攻击（Padding Oracle攻击指应用在解密客户端提交的加密数据时,泄露了解密数据的分段填充是否合法的信息）。
- 进行临时(Ephemeral)的密钥交换。临时密码交换是基于Diffie-Hellman(DH)的算法，在初始化SSL/TLS握手期间完成，保证了前项保密性(PFS)
- 仅支持密码学强加密。关于密码学强加密如下。
Ø 使用最新安全建议。
Ø 服务器端激活并设置密码算法顺序，比如SSLHonorCipherOrderOn。
Ø 前项保密密码的密码为最高优先级，如DHE、ECDHE。
Ø ECDHE优于DHE, ECDHE基于椭圆曲线的密钥交换。
Ø GCM优于CBC, GCM包含关联数据加密认证消息（AEAD）。
Ø 使用RSA密钥签名，慎用DSA、DSS、ECDSA签名。
Ø 使用SHA-256或更长的散列算法。
Ø 尽量不要使用3DES。
Ø 禁用不提供加密的密码套件。
Ø 禁用不提供认证的密码套件，包括匿名密码套件。
Ø 禁用DES。
Ø 禁用密钥长度小于128的密钥。
Ø 禁用MD5、SHA-1散列算法。
Ø 禁用IDEA密码套件。
Ø 禁用RC4密码套件。
Ø DHE密钥长度大于2048位。
Ø ECDHE密钥长度大于256位。
- 使用FIPS 140-2验证的加密模块。建议使用FIPS 140-2加密TLS。FIPS 140-2 是由NIST（National Institute of Standards and Technology ）发布
- 密码库更新。仅适用支持sill机制的加密库，比如OpenSSL
5. 案例
案例4-7 用户登录页面安全用例设计
用户登录页面如48所示，下面是安全测试的测试点。
48 用户登录页面
- 通过抓包工具查看，在传输过程，用户名和密码是否加密？
- 密码框是否支持复制粘贴？
- 密码是否明文显示在页面上？
- 密码在查看源代码情况下是否可以查看？
- Cookie是否有httpOnly属性？
- 如果是HTTPS传输，Cookie是否Secure属性？
- 登录请求错误是否有次数限制？
- 勾选了“记住我”后，用户名和密码信息在浏览器端存储是否安全？
- 是否支持单点登录？
- 是否存在SQL注入？
- 是否存在XSS注入？
- 是否存在其他代码注入，比如XML、XPath、JSON注入？
- 是否存在参数污染HPP？
- 是否存在参数污染CSRF注入？
- 界面是否存在点击挟持的危险？
- 登录成功后长时间不操作，登录是不是会自动退出？
- 登录失败后的提示语言是否安全？
- 刷新验证码是否成功？
- 长时间处于登录界面，验证码是否会失效？
- 刷新页面，验证码是否会刷新？
- 不同权限用户登录，显示页面是否相同？
- 没有登录的情况下，输入登录后的URL是否可以进入？
- 是否可以绕过验证码登录？
案例4-8 注册用户安全用例设计
用户注册如49所示，下面是安全测试的测试点。
49 用户注册页面
- 通过抓包工具查看，在传输过程，用户名、密码、Email、手机信息是否加密？
- 对Email是否验证可以接受邮件信息。
- 对手机是否验证可以接受短信信息。
- 密码、确认密码框是否支持复制粘贴？
- 密码、确认密码是否明文显示在页面上？
- 密码、确认密码在查看源代码情况下是否可以查看？
- 如果是HTTPS传输，Cookie是否Secure属性？
- 是否存在SQL注入？
- 是否存在XSS注入？
- 是否存在其他代码注入，比如XML、XPath、JSON注入？
- 是否存在参数污染HPP？
- 是否存在参数污染CSRF注入？
- 界面是否存在点击挟持的危险？
- 用户名与密码在服务器端存储是否安全，比如是否使用密码学强密码方式加密？
- 是否有密码强度设置？如果有设置是否合理？
- 是否允许注册的用户名重复？
- 是否允许批量注册？
- 注册后多久可以登录？
案例4-9 找回密码安全用例设计
下面是找回密码安全测试的测试点。
- 在设置新的密码前是否有安全信息认证？
- 是否通过多种方式找回密码？
- 通过手机重置密码，是否每次向手机发送验证码或激活连接前都验证手机是否为当前用户注册信息？
- 通过电子邮件重置密码，是否每次向电子邮件发送验证码或激活连接前都验证电子邮件是否为当前用户注册信息？
- 通过安全问题找回密码，安全问题及问题答案在服务器端是否安全？
- 通过安全问题找回密码，需要回答是否设置为三次？
- 重置密码是否允许与以前的密码相同？
- 重置密码是否在浏览器端明文显示？
- 重置密码是否加密传输？
- 重置的密码存储是否安全？
- 是否会不会存在XSS注入、SQL注入、其他注入、参数污染HPP、CSRF注入和点击挟持漏洞？
- 重置的密码的强度要求是否与注册时候保持一致？
- 重置的密码在查看源代码情况下是否可以查看？
- 一天中是否允许多次重置？
- 是否提供其他方式（比如手势、扫脸）等方式登录，然后修改密码？
以上的测试点并不是很全面，建议读者在自己团队里采取头脑风暴的形式找到更多的测试点。
