英语原文共 12 页，剩余内容已隐藏，支付完成后下载完整资料

第十章

保护措施

Java的特点之一是可以很容易地下载代码并将其编入运行中的应用程序。然而，这些代码有可能会执行操纵敏感系统数据的关键操作，因此必须区分可以信任的代码和不信任的代码。为此，Java的安全模型是基于运行代码的来源。敏感操作被允许或不允许的依据是，当前调用堆栈中的类是从哪里加载的和/或谁签署了它们。

在分布式系统中，表示业务操作的代码托管在一个或多个服务器上。客户端请求充当触发器来执行服务器代码，该代码有可能执行操作敏感系统数据的关键操作。区分那些可以被信任的请求和那些不能被信任的请求是很重要的。服务器必须根据试图运行代码的人来强制执行安全性，这意味着它能够验证调用者的身份。

当客户和服务器通过公共网络进行通信时，确保安全变得更加复杂，因为服务器可能更容易被欺骗。客户端也可能希望在接受或提供某些信息之前得到一些保证，即服务器是真实的。有一些问题需要回答。系统如何判断哪些客户是可以信任的？如何能指定哪些客户可以访问哪些功能？客户端如何告诉哪些服务器可以信任？如何阻止恶意的人访问系统或篡改请求和响应？如何使敏感数据不被窥视？所有这些都是安全问题，在本章中都有回答。

本章将讨论以下主题：

• 什么是安全。
• 声明性安全：通过web.xml保护资源。
• 程序安全。
• 加密通信：保护在客户端和服务器之间发送的信息。

bull; 安全性：关于Web应用程序的安全性的一点看法。

本章的内容旨在通读。网络应用程序的安全问题是非常重要的。没有它，你怎么能防止用户访问网站的受限部分？更重要的是，考虑一下用于电子商务的Web应用程序；如果你正在经营一个有在线业务的企业，为了保护客户的个人信息（例如，信用卡号码），必须要有安全保障。

我们说的安全是什么意思？

在谈论安全问题时，我们必须介绍几个术语。第一个术语是安全主体，简称主体。委托人是参与通信的各方之一。它可能是一个人类用户或一台机器，也可能是一个软件。在安全文献中，委托人通常被赋予名字。Alice和Bob是试图进行通信的两个委托人；Eve是监听通信的窃听者；Mallory是试图改变通信数据或以某种方式破坏通信的恶意攻击者。本章将采用这种命名方式，我们将介绍许多原则。

分布式系统的安全是建立在委托人能够相互信任的基础上的。在相互信任之前，委托人必须知道他们在与谁通信，也就是说，Alice必须能够知道在通信的另一端是Bob，反之亦然。要做到这一点，Alice必须能够证明她正在与Bob交谈。这个过程被称为认证。在客户机/服务器的情况下，服务器通常要对客户机进行认证。然而，有时客户也想认证服务器--例如，如果客户向服务器发送信用卡的详细信息，客户必须能够信任服务器。另外，在有些情况下需要相互认证。为了认证一个委托人，委托人必须提供一组凭证。这些凭证可以是用户名/密码对、指纹、视网膜扫描、证书，或任何可以唯一识别委托人的东西。然后，这些凭证通常被传递给一个受信任的机构（在安全文献中称为Trent）进行检查。Trent可以是一个持有证书的数据库，也可以是一个Kerberos服务器，或其他一些第三方，如认证机构，例如Thwate或Verisign。

一旦主体经过身份验证，就会出现的下一个问题是：是否允许他们执行他们所要求的任何操作？爱丽丝可能已经证明她在和鲍勃说话，但是鲍勃被允许执行要求的动作吗？此步骤被称为授权。

当Alice和Bob在交换数据时，攻击者可能会在数据传输过程中改变该数据。Alice和Bob可能需要知道数据已经被改变。有一些技术可以用来进行这种检查。在安全方面，这被称为数据完整性。

最后，假设Alice和Bob之间的数据交换必须是保密的，也就是说，不仅Mallory不能改变数据，而且Eve也不能读取数据。在这种情况下，数据必须是加密的。在HTTP的世界里，用于管理加密的技术是传输层安全（TLS），以前被称为安全套接字层（SSL）。这是通过HTTPS协议使用的，稍后将进行研究。

声明性安全

为应用程序添加安全性可能是一项繁琐但必要的任务，而且无论编写何种应用程序，大部分工作都是类似的。以所有应用程序共享的以下安全操作为例：

• • 接收请求。
  • 认证呼叫者。
  • 检查呼叫者的授权。
  • 允许或不允许访问。

由于不同的应用程序所要做的安全工作具有相似性，因此有可能将安全问题抽象为一个框架。就 J2EE 而言，安全框架通常不是程序化的，而是声明性的。这意味着什么呢？它意味着应用程序可以通过部署设置（即 web.xml）指定特定资源需要的安全级别，而安全由 Web 应用程序容器提供。这种声明式的方法相当灵活，也相当容易使用。Servlet 规范还允许应用程序在提供安全的容器中添加 'hooks'，以允许应用程序对容器提供的安全进行微调。

应用程序也可以选择完全忽略这种声明性的安全并提供自己的安全。通常，这样做的应用程序将提供一个过滤器来处理所有请求，并在过滤器中进行所有必要的安全检查。关于安全问题，需要意识到的一件重要的事情是，所有的检查都应该尽可能早地进行。例如，在确定调用者没有被授权使用数据库之前，一个应用程序不应该让一个请求一直到达数据库。请记住，就使用的资源而言，安全是昂贵的；因此，要尽早检查，并且只在必要时检查。例如，一旦一个用户被认证，可能就不需要在每个请求中重新认证。

基于角色的安全

我们将讨论的第一种声明性安全性类型是基于角色的安全性。在Servlet世界中，安全是基于两件事的：资源和角色。

• 资源是需要保护的东西。
• 角色是被授权访问这些资源的用户。

那么，什么是角色呢？想象一下，一个有数千名个人用户的公共网站，其中大多数人不为网站的维护者所知。不同的用户将被赋予不同的访问级别。例如，网站可能有一个对所有人开放的免费部分，一个只对那些已付费的用户开放的部分，以及一个只对网站管理员开放的部分。理论上，可以根据用户的证书来检查对网站的每一次访问，所以Alice可以访问所有的网站，Bob可以访问非订阅部分，Joe可以访问非订阅部分和订阅部分，以此类推，对网站的所有不同负责人都是如此。但对于成千上万的用户来说，管理单个用户的访问很快就会成为一场噩梦。相反，发生的情况是，用户被分配到一个 '角色'。在这种情况下，可能有三个角色：非订阅者、订阅者和管理员。每个用户在浏览网站时都会被分配到一个角色。然后，网站中的每个资源都只能被某些角色访问。请注意，角色和角色名称是完全针对应用程序的；没有所有应用程序都可以或必须使用的标准角色。

Servlet规范对用户如何被分配到角色没有任何说法，无论是你使用的命名方案还是用来执行的代码。该规范只是说，角色是存在的，而且容器必须识别它们。在Tomcat1中，管理角色的默认机制是Tomcat安装的/conf目录下的tomcat- users.xml文件。默认文件看起来像这样。

lt;tomcat-usersgt;

lt;user name='tomcat' password='tomcat' roles='tomcat' /gt;

lt;user name='role1' password='tomcat' roles='role1' /gt;

lt;user name='both' password='tomcat' roles='tomcat, role1' /gt;

lt;/tomcat-usersgt;

这个文件定义了用户名、密码和角色之间的简单映射。注意，一个给定的用户可能有多个角色，例如，用户名称='both '在 'tomcat '角色和 'role1 '角色中。在Tomcat中，定义角色的区域被称为安全域，尤其是这种基于XML文件的机制被称为内存安全域。如果你不改变Tomcat的配置，它是你的应用程序中默认的安全域。然而，Tomcat还有其他安全域，特别是JDBC安全域和JNDI安全域。这些为应用程序提供了更多的灵活性。我们稍后将回到安全域和配置，但首先让我们看看在应用程序中如何使用角色。

通过使用web.xml中的security-constraint元素，基于角色的安全限制可以被放置在Web应用程序资源上。作为一个例子，将清单10-1添加到jspbook Web应用程序的/WEB-INF目录下的/web.xml。

清单10-1web.xml中的安全约束项

...

lt;web-appgt;

...

lt;security-constraintgt;

lt;web-resource-collectiongt;

lt;web-resource-namegt;SecuredBookSitelt;/web-resource-namegt;

lt;url-patterngt;/secured/*lt;/url-patterngt;

lt;http-methodgt;GETlt;/http-methodgt;

lt;http-methodgt;POSTlt;/http-methodgt;

lt;/web-resource-collectiongt;

lt;auth-constraintgt;

lt;role-namegt;Readerlt;/role-namegt;

lt;/auth-constraintgt;

lt;/security-constraintgt;

lt;login-configgt;

lt;auth-methodgt;BASIClt;/auth-methodgt;

lt;realm-namegt;Read Accesslt;/realm-namegt;

lt;/login-configgt;

...

前面的条目使用lt;security-constraintgt;元素来限制任何 HTTP GET或POST调用任何与/secured/*匹配的URL。web-resource- name子元素被用来提供一个任意的名字，在这个例子中是SecuredBookSite。

lt;web-resource-namegt;SecuredBookSitelt;/web-resource-namegt;

你选择什么作为名字并不重要。稍后我们将看到名字只是作为元信息使用。更重要的子元素是url-pattern和http-method。url-pattern元素的作用与Servlet、JSP或Filter映射的url-pattern元素相同。http-method元素是新的，但使用起来很直观。它可以有一个与任何HTTP方法相匹配的值，并且每个指定的方法在使用前都会被检查。例如，在上面的例子中，GET和POST被指定。

lt;http-methodgt;GETlt;/http-methodgt;

lt;http-methodgt;POSTlt;/http-methodgt;

这两个条目将意味着对/secured/*所匹配的URL的任何HTTP GET或POST请求都将受到安全限制。

lt;security-constraintgt;的最后一部分，即auth-constraint子元素，用于将安全限制与定义的角色相匹配。单个角色是由角色名称元素定义的。在前面的条目中，角色Reader被赋予访问安全资源的权限。

auth-constraintgt;

lt;role-namegt;Readerlt;/role-namegt;

lt;/auth-constraintgt;

最后，使用登录配置元素来描述身份验证的基本形式2.

lt;security-rolegt;

lt;role-namegt;Readerlt;/role-namegt;

lt;/security-rolegt;

最终的结果是，只有角色Reader中的用户能够浏览jspbook Web应用程序的/secured目录下的资源。即使没有/secured目录或其中的资源，你也可以试试这个安全限制。保存安全条目并重新加载jspbook Web应用程序。然后尝试浏览包括/security目录在内的任何URL。比如说。

http://127.0.0.1/jspbook/secured/SecurityTest

您应该看到一个要求您登录的对话框，而不是得到一个404错误或看到一个资源（应该存在一个资源）。 图10-1显示了Mozilla的登录界面。无论你使用哪种浏览器，它都是类似的。

输入任何你喜欢的用户名或密码值。无论你输入什么，Web应用程序将拒绝你访问所请求的资源（即使它不存在）。点击 '取消 '来删除认证框。图10-2显示了典型的拒绝访问页面的样子。

图10-1Mozilla登录

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[603271]，资料为PDF文档或Word文档，PDF文档可免费转换为Word