概述

上一篇文章中，我们介绍了厚客户端GUI方面的问题，本篇文章我们继续来测试网络方面的问题，以及在不同的架构中它是如何运行的。

BetaFast是采用三层架构编写的：

第一层：客户端显示和采集数据

第二层：服务端接受web请求并处理业务逻辑

第三层：数据库服务器修改和获取应用服务器的数据

Beta Bank采用双层架构编写：

第一层：客户端显示和采集数据

第二层：数据库服务器处理业务逻辑，执行客户端数据查询和修改

单层架构也是存在的，客户端，业务逻辑，数据存储都在同一台系统上，本文就不去讲解单层架构了。当然也有三层以上的架构，下面介绍的工具和方法也都是适用的。

双层架构

wireshark工具

一般我开始测试厚客户端时，第一件事就是分析网络请求流量。通常都是用wireshark来捕获和过滤网络流量。

这个例子中，我会测试Beta Bank这个应用。设置好合适的过滤规则，就可以在客户端中进行操作了，如提交表单，浏览应用程序，修改数据等，然后查找wireshark看是否有敏感信息：

· 数据库连接是否未加密？

· 社保账号和医疗信息等敏感信息是否明文传输？

有一次我使用blogger这个用户尝试进行认证，然后再wireshark的数据包流量中搜索blogger，blogger显示在一个登录过程中，这就表明在数据库连接时，用户名未加密，能够访问这个网络的人，都可以轻易的捕获这个数据，好在密码是加密的，这样攻击者就访问不到我的账户了。

真的访问不到吗？

从客户端发送的任何形式的密码，无论是明文的，加密的，还是hash值，其实都可以算是密码。虽然密码加密了，但是获取到这个密码，然后发送到服务端，就可以通过应用的认证。可以看到除了参数值混淆外，没有其他的防御措施，整个传输过程没有进行安全地加密。通过wireshark还观察到登录过程中的输出参数GUID，在应用程序的认证部分，这个过程接受GUID参数。

这个GUID就是我们业务中常说的会话ID，有了这个值，只要blogger用户会话保持在线，攻击者就可以执行通过认证的操作。

即便如此，攻击者没有拿到账号或权限，也已经造成一定的影响了。

Echo Mirage工具

在这个例子中，我是一个精通电脑的高手，并且从登陆过程中，嗅探到了blogger的用户名和加密的密码。

现在我们要用到echo mirage这款软件，这款软件可以截获并修改tcp流量。我们首先输入用户名blogger和任意密码，然后截获数据包：

然后修改密码为刚才我们用wireshark截获到的密码：

发送请求之后，可以看到我们已经成功登录，现在我们来看看这个账户余额有多少钱。

尴尬了，一分都没有，啥也不是。没关系，我们接着看看Beta Bank还有哪些客户。

如下图，取钱按钮已经禁用了，不过上篇文章中讲过一种技术，我们可以启用这个按钮。

抓包，观察wireshark，可以看到这个函数执行了一个sql查询：

Echo Mirage可以直接修改sql语句，虽然不能改变数据包的长度，但是可以注释掉后面的sql语句：

服务端响应了用户表信息，显然，连接到数据库的这个账户权限过高，现在我们获取到了每个用户的信息：

现在攻击面就更加广泛了。数据库层面还有很多可以挖掘和修改的，不过The_Chairman这个账户吸引了我的注意，一听名字就知道是个有钱人，精英人士，那就登录去看看吧：

这么多钱，吓得我一个激灵

三层架构

Burpsuite

Burpsuite可能是我在测试过程中用的最多的工具。在测试过程中，可以进行抓包代理，测试HTTP请求和响应方面，堪称神器。如果你没用过的话，可以参考这篇指南。

如果厚客户端采用三层架构编写，网络部分的测试其实跟web应用差不多，设置代理，在代理选项中设置监听端口，我就不多啰嗦了。

接下来我们设置系统代理，不是浏览器代理：

可能会有很多流量是不属于被测试应用的，所以我们需要知道哪些流量是来自厚客户端的，只要我们知道跟应用程序交互的主机和地址后，设置一个scope就可以了。比如测试BetaFast，我们发现它只向http://www.betafast.net:8080发请求，那我们把它添加到scope就可以了。

其他操作就跟web测试一样，抓包，查看请求。如下，我发现了一个请求，并发送到repeater，并尝试fuzz，发现了一个sql注入：

总结

网络是非常重要的，所以在测试厚客户端应用的时候，不要只关注于客户端。

Beta Bank和BetaFast如何保护他们的系统呢？措施肯定有很多，这里我提出以下几条作为参考：

Beta Bank修复措施

· 加密数据库连接—加密连接，隐藏敏感数据，防止网络窃取。只要执行了安全加密，也可以保护流量无法被修改。

· 最小权限原则—因为Beta Bank使用高权限用户连接数据库，因此当攻击者找到漏洞并加以利用，就可以完全控制数据库，执行任意操作。如果连接数据库的用户只拥有最小权限，那么攻击者只能执行权限以内的正常功能，可以减小危害。

· 密码加盐或者进行hash存储—加密本质上是可以逆向的。在接下来的文章中，我们会重点讲到。

· 强化身份验证逻辑—不要直接把通过网络发送的密码与数据库中存储的密码比对，这样的话，如果攻击者嗅探到密码，甚至不需要解密和破解hash，就可以直接利用。首先密码应该加密传输，然后服务器端对密码进行加盐或者hash处理，再与数据库中加盐过或经过hash加密的密码进行比对。

BetaFast修复措施

· 输入验证和参数化查询—跟Beta Bank不同，不是流量拦截和修改的问题，BetaFast问题出在应用服务器处理用户输入上。客户端输入的任何数据，服务端都应该进行验证，而且sql语句应该采用参数化查询。

ok，本篇文章就到这里，如果想要实战的话，可以去我们的github主页下载BetaFast和Beta Bank。各位表哥们，下篇文章见。

本文翻译自：https://blog.netspi.com/introduction-to-hacking-thick-clients-part-2-the-network/如若转载，请注明原文地址