关于前端:如何破解不安全的Web应用程序

2次阅读

共计 2274 个字符，预计需要花费 6 分钟才能阅读完成。

在本文中，我想展现从 Web 应用程序获取机密信息的容易水平，而这些应用程序……对安全性并不太器重。我将应用的是我在 Spring Boot 中创立的示例 Java 应用程序，用于演示。然而执行的攻打对任何其余编程语言或框架均无效。将展现的一些破绽和安全性问题包含：

咱们将应用一个虚构的 Web 应用程序，该应用程序容许您以属于某些组的用户身份登录。依据用户角色，他能够查看根本数据或秘密数据。在这种状况下，您将看到公司中的员工列表，他们的状态等。

您能够在我的 Github 中找到此应用程序的源：https : //github.com/rapasoft/hackme。

假如您正坐在餐厅里，并且想查看下面的应用程序中的某些内容。您连贯到餐厅的 Wi-Fi，关上登录页面，输出凭据并获取所需的信息（例如，特定员工的列表）。您当初可能不晓得的是，您的凭据已被泄露。让咱们仔细检查登录页面：

该应用程序不应用 SSL / TLS（例如，无 https:// 连贯）。这意味着，任何有权拜访客户端和服务器之间通信的人都能够将发送的任何信息视为纯文本。

这正是所谓的_“中间人袭击”中_产生的事件。更具体地说，在这种状况下，ARP 坑骗已被用作毒害整个网络的形式，从而使攻击者能够理解正在产生的所有并能够嗅探所有数据包。我不会具体介绍 ARP 坑骗的工作原理，但将在此视频中进行演示：

您可能须要在新窗口和全屏模式下关上此 YouTube 视频，以查看更多详细信息

下面您能够看到，我曾经启动了 Ettercap，这是一个用于 MITM 攻打的综合套件，并在本地网络中执行了 ARP 坑骗。同时，当用户（我通过 iPad）输出凭据时，它们在 Ettercap 和 Wireshark（用于网络流量剖析的工具）中都是可见的。

持续作为该应用程序的攻击者，咱们当初领有 hgraves 明码为的用户凭证P4SSW0RD。您能够看到，不仅此应用程序不应用 TLS，而且明码策略十分弱，使用户能够抉择十分蹩脚的明码。

咱们应用下面的凭据登录，能够看到一个输出字段，其中蕴含用于搜寻人员列表的选项。按下时，Search咱们将取得残缺的人员列表。例如，如果咱们输出“Fra”，咱们将依据搜寻后果取得过滤后果。如果咱们搁置一些非法字符怎么办？不言而喻，此应用程序前面有一些数据库，因而让咱们尝试一下该 ' 字符：

这不仅失败，而且咱们能够看到 POST 申请失败，并显示了十分具体的谬误音讯，该谬误音讯裸露了整个 SQL 语句的构造。咱们能够看到 WHERE P.NAME LIKE '%'%' 最初应用了它。

纯熟的黑客不须要更多。通过几次尝试，调整搜寻字符串能够产生以下后果：

在这种状况下，注入创立了联结以抉择语句，该语句将获取用户名和明码及其角色。不仅胜利，而且咱们设法将其显示在原始客户端应用程序中。

当初，咱们领有所有用户的凭据及其角色（在“年龄”列中以整数显示）。因而 hframe，如果具备角色 1，则rgraves 必须是具备角色 3 的更重要的用户。

咱们在第一次攻打中理解到，可能没有为此应用程序设置任何明码策略。这将使咱们心愿 rgraves 也不要过多地关注安全性。

应用有余的哈希算法（在这种状况下为 MD5）破解明码哈希的最简略办法是执行字典或 Rainbow 表攻打。有很多可能性，然而最简略的一种办法是应用曾经具备明码到哈希组合的大型数据库的 Internet 服务：

第 hframe 一个是 rgraves。smorgan 因为它不在字典中，因而仿佛应用的明码比其余明码更强。

您会看到明码 rgraves 是箭鱼，这意味着他当初抉择非字典式明码;）并不重要。当初，没有什么能够阻止咱们以该用户身份登录并发现“admin”局部和机密信息：

您可能会说，所有这些都能够轻易防止。您可能会说这些是_菜鸟的谬误_。嗯，这可能是正确的，但同样正确的是，“开放式 Web 应用程序安全性我的项目”将“_注入”_列为 Web 应用程序中的#1 破绽（并且这种状况曾经存在了好几年了）。

因而，如果您发现自己想晓得如何避免所有这些状况，那么让咱们回顾一下：

向服务器发送内容时，始终应用 SSL / TLS。它不用肯定是凭据，目前通常被认为是一种很好的做法。即便您的页面上基本没有任何输出！最简略的办法是通过 Let’s Encrypt 之类的服务来提供证书。
请记住，自签名证书能够缓解数据泄露的问题，但不能阻止 MITM 攻击者应用本人的自签名证书伪造整个站点。
解决 SQL 查问时，请 始终本义从 client 取得的参数。最简略的办法是应用框架的性能，例如，在 Spring 中，您能够应用 NamedParameterJdbcTemplate，这也有利于进步可读性。
偏执。验证任何用户输出。再次在 Java / Spring 世界中，您能够应用 JSR-380 诸如 Hibernate 验证程序之类的 bean 验证实现来增加验证规定，并正文参数，例如@Pattern(regexp = "[a-z|A-Z]*") String name，避免输出'。
记录在应用程序中传递有效输出的任何尝试。此外，在产生谬误的状况下，请勿向客户端 公开任何特定 于实现的信息。
改善您的身份验证。
- 如果可能，请至多应用 2 因子身份验证。
- 不要实现自定义明码存储或加密算法。一个人很难做，而且必定会失败。有像 BCrypt 这样的成熟解决方案。
浏览并标记 OWASP TOP 10。从那里开始，而后浏览他们的最佳做法列表。