安全性可以说是 21^st 世纪编写的任何基于 Web 的应用程序中最关键的架构组件之一。在恶意软件、犯罪分子和流氓员工始终存在并积极测试软件以发现漏洞的时代，智能和全面地使用安全性是您负责的任何项目的关键要素。

本书遵循一种开发模式，我们认为，这种模式为处理复杂主题提供了一个有用的前提——以 Spring 4.2 为基础的基于 Web 的应用程序，并理解使用 Spring Security 保护它的核心概念和策略4.2.我们通过以完整的 Web 应用程序的形式为每一章提供示例代码来补充这种方法。

无论您已经在使用 Spring Security，还是有兴趣将软件的基本使用提升到更高的复杂程度，您都会在本书中找到对您有所帮助的内容。在本章的课程中，我们将讨论以下主题：

• The results of a fictional security audit
• Some common security problems of web-based applications
• Several core software security terms and concepts

如果你已经熟悉基本的安全术语，你可以跳到第2章，Spring Security 入门，我们从这里开始使用框架的基本功能。

现在是您作为 Jim Bob Circle Pants 在线日历 (JBCPCalendar.com) 的软件开发人员的一大早，当您收到以下电子邮件时，您的第一杯咖啡已经喝到一半了来自您的主管：

什么？您在设计应用程序时没有考虑安全性吗？事实上，在这一点上，您甚至不确定什么是安全审计。听起来您可以从安全审计员那里学到很多东西！在本章后面，我们将回顾什么是审计以及审计结果。首先，让我们花点时间检查正在审查的应用程序。

尽管我们将在阅读本书的过程中处理一个人为的场景，但应用程序的设计和我们将对它进行的更改是从基于 Spring 的应用程序的实际使用中得出的。日历应用程序允许用户创建和查看事件：

输入新事件的详细信息后，您将看到以下屏幕截图：

该应用程序被设计得非常简单，让我们能够专注于安全的重要方面，而不是被对象关系映射（ORM）的细节所束缚，并且复杂的用户界面技术。我们希望您参考附录中的其他补充材料，附加参考材料（在本书的补充材料部分) 以涵盖作为示例代码的一部分提供的一些基线功能。

代码是用 Spring 和 Spring Security 4.2 编写的，但是将许多示例调整到其他版本的 Spring Security 会相对容易。参考 第 16 章 ，迁移到 Spring Security 4.2，用于帮助将示例转换为 Spring Security 4 语法。

请不要将此应用程序用作构建真正在线日历应用程序的基准。它的结构特意简单，并专注于我们在本书中说明的概念和配置。

Web 应用程序遵循标准的三层架构，包括 Web、服务和数据访问层，如下图所示：

您可以在附录的补充材料部分中找到有关 MVC 架构的其他材料，其他参考材料。

Web 层封装了 MVC 代码和功能。在这个示例应用程序中，我们将使用 Spring MVC 框架，但我们也可以轻松地使用 Spring Web Flow (SWF)、Apache Struts ，甚至是对 Spring 友好的 Web 堆栈，例如 Apache Wicket。

在典型的 Web 应用程序中，利用 Spring Security，Web 层是代码的大部分配置和扩充发生的地方。例如，EventsController 类用于将 HTTP 请求转换为将事件持久化到数据库中。如果您对 Web 应用程序和 Spring MVC 没有很多经验，那么在我们继续讨论更复杂的主题之前，仔细查看基线代码并确保您理解它是明智的。同样，我们试图使网站尽可能简单，日历应用程序的构造仅用于为网站提供合理的标题和轻巧的结构。

服务层封装了应用程序的业务逻辑。在我们的示例应用程序中，我们使用 DefaultCalendarService 作为数据访问层上的一个非常轻的外观，以说明有关保护应用程序服务方法的特定要点。服务层还用于在单个方法调用中对 Spring Security API 和我们的 Calendar API 进行操作。我们将在 第 3 章，自定义中更详细地讨论这个问题身份验证。

在典型的 Web 应用程序中，该层将包含业务规则验证、业务对象的组合和分解以及诸如审计之类的横切关注点。

数据访问层封装了负责操作数据库表内容的代码。在许多 Spring 应用程序中，您会看到 ORM 的使用，例如 Hibernate 或 JPA。它将基于对象的 API 暴露给服务层。在我们的示例应用程序中，我们使用基本的 JDBC 功能来实现内存中 H2 数据库的持久性。例如，JdbcEventDao 用于将事件对象保存到数据库中。

在典型的 Web 应用程序中，将使用更全面的数据访问解决方案。由于 ORM，以及更普遍的数据访问，往往会让一些开发人员感到困惑，为了清晰起见，我们选择了尽可能简化的领域。

我们致力于通过专注于几乎每个 Spring 开发人员在他们的开发机器上都会拥有的一些基本工具和技术，使应用程序尽可能易于运行。尽管如此，我们在附录中提供了入门部分作为补充信息，JBCP 日历示例代码入门。

与示例代码集成的主要方法是提供与 Gradle 兼容的项目。由于许多 IDE 都与 Gradle 进行了丰富的集成，因此用户应该能够将代码导入任何支持 Gradle 的 IDE。由于许多开发人员使用 Gradle，我们认为这是打包示例最直接的方法。无论您熟悉什么开发环境，都希望您能找到一种方法来完成本书中的示例。

许多 IDE 提供 Gradle 工具，可以自动为您下载 Spring 和 Spring Security 4.2 Javadoc 和源代码。但是，有时可能无法做到这一点。在这种情况下，您需要下载 Spring 4.2 和 Spring Security 4.2 的完整版本。 Javadoc 和源代码是一流的。如果您感到困惑或想了解更多信息，这些示例可以为您的学习提供额外的支持或保证。访问 Supplementary Materials 部分，在 Appendix，Additional Reference Material 中找到有关 Gradle 的更多信息，包括运行示例、获取源代码和 Javadoc，以及在没有 Gradle 的情况下构建项目的替代方案。

让我们回到我们的电子邮件，看看审计进展如何。呃，结果看起来不太好：

申请审核结果

此应用程序表现出以下不安全行为：

• Inadvertent privilege escalation due to lack of URL protection and 
general authentication
• Inappropriate or non-existent use of authorization
• Missing database credential security
• Personally-identifiable or sensitive information is easily accessible 
or unencrypted
• Insecure transport-level protection due to lack of SSL encryption
• Risk level is high

我们建议在解决这些问题之前让该应用程序脱机。

哎哟!这个结果对我们公司来说看起来很糟糕。我们最好尽快解决这些问题。

公司（或其合作伙伴或客户）经常聘请第三方安全专家，通过结合白帽黑客、源代码审查以及与应用程序开发人员和架构师的正式或非正式对话来审计其软件安全的有效性。

白帽黑客攻击或道德黑客攻击由受雇指导公司如何更好地保护自己的专业人员完成，而不是出于恶意。

通常，安全审计的目标是向管理层或客户提供已遵循基本安全开发实践的保证，以确保客户数据和系统功能的完整性和安全性。根据软件所针对的行业，审核员还可以使用行业特定的标准或合规性指标对其进行测试。

接收安全审计的结果可能是令人大开眼界的体验。完成所需的软件改进可能是自我教育和软件改进的绝佳机会，并且可以让您实施导致安全软件的实践和策略。

让我们回顾一下审计师的调查结果，并制定一个详细解决这些问题的计划。

身份验证是开发安全应用程序时必须内化的两个关键安全概念之一（另一个是授权）。 身份验证 识别谁正在尝试请求资源。您可能熟悉日常在线和离线生活中的身份验证，在非常不同的环境中，如下所示：

• Credential-based authentication: When you log in to your web-based email account, you most likely provide your username and password. The email provider matches your username with a known user in its database and verifies that your password matches what they have on record. These credentials are what the email system uses to validate that you are a valid user of the system. First, we'll use this type of authentication to secure sensitive areas of the JBCP calendar application. Technically speaking, the email system can check credentials not only in the database but anywhere, for example, a corporate directory server such as Microsoft Active Directory. A number of these types of integrations are covered throughout this book.
• Two-factor authentication: When you withdraw money from your bank's automated teller machine, you swipe your ID card and enter your personal identification number before you are allowed to retrieve cash or conduct other transactions. This type of authentication is similar to the username and password authentication, except that the username is encoded on the card's magnetic strip. The combination of the physical card and user-entered PIN allows the bank to ensure that you should have access to the account. The combination of a password and a physical device (your plastic ATM card) is a ubiquitous form of two-factor authentication. In a professional, security-conscious environment, it's common to see these types of devices in regular use for access to highly secure systems, especially dealing with finance or personally identifiable information. A hardware device, such as RSA SecurID, combines a time-based hardware device with server-based authentication software, making the environment extremely difficult to compromise.
• Hardware authentication: When you start your car in the morning, you slip your metal key into the ignition and turn it to get the car started. Although it may not feel similar to the other two examples, the correct match of the bumps on the key and the tumblers in the ignition switch function as a form of hardware authentication.

从字面上看，有几十种形式的身份验证可以应用于软件和硬件安全问题，每种形式都有自己的优缺点。我们将回顾这些方法中的一些，因为它们在本书的前半部分适用于 Spring Security。我们的应用程序缺乏任何类型的身份验证，这就是为什么审计包括无意提升权限的风险。

通常，软件系统将分为两个高级领域，例如未经身份验证（或匿名）和经过身份验证，如以下屏幕截图所示：

匿名领域中的应用程序功能是独立于用户身份的功能（想想在线应用程序的欢迎页面）。

匿名区域不执行以下操作：

• Require a user to log in to the system or otherwise identify themselves 
to be usable
• Display sensitive information, such as names, addresses, credit cards, 
and orders
• Provide functionality to manipulate the overall state of the system or its data

系统中未经身份验证的区域旨在供所有人使用，即使是我们尚未明确识别的用户。但是，在这些区域中，可能会向已识别的用户显示附加功能（例如，无处不在的 Welcome {First Name} 文本）。通过使用 Spring Security 标记库完全支持向经过身份验证的用户选择性显示内容，并在 第 11 章，细粒度访问控制。

我们将在 第 2 章，Spring Security 入门。之后，我们将探索执行身份验证的各种其他方法（通常围绕与企业或其他外部身份验证存储的系统集成）。

授权使用不当或不存在

授权是对实施和理解应用程序安全至关重要的两个核心安全概念中的第二个。 授权使用在身份验证期间验证的信息来确定是否应授予对特定资源的访问权限。围绕应用程序的授权模型构建，授权对应用程序功能和数据进行分区，以便通过将权限、功能和数据的组合与用户匹配来控制这些项目的可用性。我们的应用程序在审计时的失败表明应用程序的功能不受用户角色的限制。想象一下，如果您正在运行一个电子商务网站，并且该网站的任何用户都可以查看、取消或修改订单和客户信息！

授权通常涉及以下两个独立的方面，它们结合起来描述安全系统的可访问性：

• The first is the mapping of an authenticated principal to one or more authorities (often called roles). For example, a casual user of your website might be viewed 
as having visitor authority, while a site administrator might be assigned administrative authority.
• The second is the assignment of authority checks to secured resources of the system. This is typically done at the time a system is developed, either through an explicit declaration in code or through configuration parameters. For example, the screen that allows for the viewing of other users' events should be made available only to those users with administrative authority.

基于 Web 的应用程序的安全资源可以是单个网页、网站的整个部分或单个页面的部分。相反，受保护的业务资源可能是对类或单个业务对象的方法调用。

您可能会想象一个权限检查会检查主体、查找其用户帐户并确定主体是否实际上是管理员。如果此权限检查确定尝试访问受保护区域的主体实际上是管理员，则请求将成功。但是，如果委托人没有足够的权限，则应拒绝该请求。

让我们仔细看看特定安全资源的示例，即 所有事件 页面。 All Events 页面需要管理员权限（毕竟，我们不希望普通用户查看其他用户的事件），因此，在主体访问它。

如果我们考虑当站点管理员尝试访问受保护资源时如何做出决定，我们会想象实际权限与所需权限的检查可以用集合论简洁地表达。然后，我们可能会选择将此决定表示为管理用户的 维恩图：

页面的 User Authorities（用户和管理员）和 Required Authorities（管理员）之间存在交集，因此为用户提供了访问权限。

将此与未经授权的用户进行对比，如下所示：

这组权威是脱节的，没有共同的元素。因此，用户被拒绝访问该页面。至此，我们演示了授权访问资源的基本原理。

实际上，有真正的代码做出这个决定，结果是允许或拒绝用户访问所请求的受保护资源。我们将在 第 2 章< /a>，Spring Security 入门，然后在 第 12 章、访问控制列表和 第 13 章，自定义授权。

数据库凭据不安全或不易于访问。通过对应用程序源代码和配置文件的检查，审计人员注意到用户密码以明文形式存储在配置文件中，使得访问服务器的恶意用户很容易获得对应用程序的访问权限。

由于该应用程序包含个人和财务数据，因此能够访问任何数据的流氓用户可能会使公司面临身份盗用或篡改。保护对用于访问应用程序的凭据的访问应该是我们的首要任务，重要的第一步是确保安全中的一个故障点不会危及整个系统。

我们将在 第 4 章，基于 JDBC 的身份验证。在同一章中，我们还将研究提高存储在数据库中的密码安全性的内置技术。

个人身份信息或敏感信息易于访问或未加密。审计人员指出，一些重要且敏感的数据在系统中的任何地方都完全未加密或被屏蔽。幸运的是，有一些简单的设计模式和工具可以让我们安全地保护这些信息，在 Spring Security 中具有 基于注解的 AOP 支持。

由于缺乏 SSL 加密，存在不安全的传输级保护。

虽然在现实世界中，包含私人信息的在线应用程序在没有 SSL 保护的情况下运行是不可想象的，但不幸的是，JBCP 日历正是这种情况。 SSL 保护确保浏览器客户端和 Web 应用程序服务器之间的通信是安全的，可以防止多种篡改和窥探。

在Tomcat 中的HTTPS 设置部分，在附录，其他参考资料中，我们将回顾使用传输的基本选项级安全性作为应用程序安全结构定义的一部分。

Spring Security 4.2 提供了丰富的资源，允许以简单的方式声明或配置许多常见的安全实践。在接下来的章节中，我们将结合使用源代码和应用程​​序配置更改来解决安全审计员（以及更多）提出的所有问题，让我们确信我们的日历应用程序是安全的。

使用 Spring Security 4.2，我们将能够进行以下更改以提高应用程序的安全性：

• Segment users of the system into user classes
• Assign levels of authorization to user roles
• Assign user roles to user classes
• Apply authentication rules globally across application resources
• Apply authorization rules at all levels of the application architecture
• Prevent common types of attacks intended to manipulate or steal a 
user's session

Spring Security 的存在是为了填补 Java 第三方库领域的空白，就像 Spring 框架在首次引入时最初所做的那样。 Java Authentication and Authorization Service (JAAS) 或 Java EE Security 等标准确实提供了一些执行某些相同身份验证和授权功能的方法，但 Spring Security 是赢家，因为它包含了以简洁和明智的方式实现自上而下的应用程序安全解决方案所需的一切。

此外，Spring Security 吸引了许多人，因为它提供了与许多常见企业身份验证系统的开箱即用集成；因此它可以适应大多数情况，开发人员只需付出很少的努力（除了配置之外）。

它被广泛使用是因为真的没有其他主流框架能像它一样！

在本章中，我们回顾了不安全 Web 应用程序中的常见风险点以及示例应用程序的基本架构。我们还讨论了保护应用程序的策略。

在下一章中，我们将探索如何快速设置 Spring Security 并基本了解它的工作原理。