HTTPS的风险

移动银行环境中，存在一些HTTPS漏洞，本文将对其进行简要分析，并给出一些对策。

SSL协议和TLS 1.0或1.1

简而言之，HTTPS应该使用TLS 1.2+。这是因为其他可用于HTTPS的协议（例如安全套接字层（SSL）协议（SSL 1.0、2.0和3.0）以及传输层安全性（TLS）协议版本1.0和1.1）被认为是不安全和破碎。SSL容易受到POODLE攻击。POODLE的一个版本也针对TLS。Heartbleed的目标是SSL / TLS的OpenSSL实现，这是迄今为止最受欢迎的SSL和TLS库。Sweet32还针对TLS中使用的多个64位密码。最后，BEAST针对TLS 1.0本身。

中间人攻击

由于其结构，HTTPS完全容易受到中间人攻击。如果攻击者设法使目标用户接受“恶意”证书，则代理SSL服务器可以站在中间，并以明码记录所有HTTPS流量。

例如，如果用户接受“间谍”服务器的根证书，则可以通过修改用户的主机文件，通过重新路由或使用恶意DNS将到合法服务器的流量重定向到间谍服务器。由于用户先前接受了恶意根证书，因此将向用户提供有效的证书。因此，与Web服务器的连接将看起来完全正常。然后，可以在代理SSL服务器中解密HTTPS流量，然后将其解密并转发到合法的Web服务器。

应对措施

为了防止对HTTPS的攻击，可以采取几种对策： 

• 创建一个额外的安全通道，例如，对HTTPS层本身内部的数据进行加密。此方法可以防止MITM攻击，因为它允许将https隧道本身中的数据从移动银行或支付应用程序隧道传输到远程服务器，但是它还需要服务器端具有足够的软件来解密/加密数据。 
  

• 检查提供给客户端的证书的指纹，以防止恶意SSL代理发送虚假证书。精确定位远程SSL证书会阻止我们前面描述的SSL流氓代理方案运行。

• 检查客户端/应用程序使用的密码套件和协议，以防止使用不安全的密码，SSL协议或TLS 1.0 / 1.1协议。不应允许移动银行或支付应用程序使用弱密码，例如易受“生日攻击”的密码等。

• 此外，可以实现针对移动应用程序与外界之间所有流量的专用安全代理，以防止恶意HTTPS代理运行。移动银行或支付应用程序之间的所有https通信都应由位于移动操作系统本身内部的代理进行过滤，并且该代理应进行所有必要的安全检查。

结论

移动银行应用程序与远程银行服务器之间的通信必须在端到端安全通道内进行。在保护移动应用程序的上下文中，必须使用TLS。这是为了防止在黑客拦截通信的情况下“嗅探”敏感数据。最方便的安全通道是HTTPS协议。通常，HTTPS被认为是完全安全的。不幸的是，这并不完全正确，这就是为什么在部署高度敏感且针对性强的金融应用程序时需要如上所述的其他保护措施。

揽阁信息可提供的部分安全产品和解决方案信息

联系揽阁信息，您可以获取到更多满足全球合规性要求的信息安全产品资料，以及相关的整体解决方案的相关资料。如：

• 数据库访问控制：揽阁LGPAC系统

• 通用HSM：Luna HSM、ProtectServer HSM

• 支付HSM：payShield 10K

• KMS产品：CipherTrust Manager、Vormetric、KeySecure

• 数据保护：应用层数据加密、数据库加密、令牌化（Tokenization）、透明加密

• 网络传输加密：Thales High Speed Encryption（HSE）

• 身份认证：STA、SAS、USB令牌、智能卡、OTP令牌、手机令牌、虚拟智能卡、FIDO2、读卡器

您还可以得到揽阁信息所提供的优质服务。

揽阁信息 · 值得您信赖的信息安全顾问！

相关阅读

• EV SSL 证书：优点和缺点

• 较短证书有效期的优点：证书自动化的好处

• 孟加拉国NCC银行通过Thales Luna HSM确保安全、无缝的实时BINIMOY交易

• 从398天到90天：Google缩短TLS证书有效期的提议 – 您准备好了吗？

• 联网车辆的网络安全