fortify扫描结果速查(Java/JSP)

2020-12-25

× 文章目录

1. Java/JSP
1.3. 封装
1.4. 环境配置
1.5. 异常处理
1.6. 输入验证与展示问题
1.7. 安全特性
1.8. 时间和状态

fortify扫描结果速查(Java/JSP)，篇幅十分大，推荐使用ctrl+F查找~~~

Java/JSP

API误用
API 是调用方与被调用方之间的合约。最常见的 API 滥用形式是由于调用方未能履行本合约而造成的。例如，如果程序未能在调用 chroot() 之后调用 chdir()，则违反了合约针对如何以安全的方式更改活动根目录的规定。库滥用的另一个绝佳示例是希望被调用方将可信 DNS 信息返回给调用方。在这种情况下，调用方通过对被调用方的行为做出某些假设（即返回值可用于身份验证）而滥用被调用方 API。此外，一方还可以从另一方违反调用方和被调用方间的合约。例如，如果编码器将 SecureRandom 归入子类并返回非随机值，则违反了合约。

代码质量
代码质量低会导致不可预知的行为。从用户角度来看，这种情况通常表现为可用性差。对于攻击者而言，它提供了以各种意想不到的方式为系统施压的机会。

封装
封装是指划定明确的边界。在 Web 浏览器中，这可能意味着确保您的移动代码不会被其他移动代码滥用。在服务器上，它可能意味着对经过验证的数据和未经验证的数据、一个用户的数据和另一用户的数据或对用户可以查看的数据和不能查看的数据进行区分。

环境配置

这部分包含源代码以外的所有内容，但对于即将创建的产品的安全仍至关重要。因为此分类中涵盖的问题与源代码没有直接关系，所以我们将其与其他分类分开。

异常处理

错误和错误处理代表 API 的一个类。与错误处理相关的错误十分常见，它们单独需要一个特殊的界。对于“API 滥用”，有两种方式可以引入与错误相关的安全漏洞：最常用的方式是不当处理错误（或根本不处理）。第二种方式是制造提供太多信息（给潜在的攻击者）或难以处理的错误。

输入验证与展示问题

输入验证和表示问题是由于元字符、备选编码和数值表示而引起的。安全问题是由于信任输入而引起的。这些问题包括：“缓冲区溢出”、“跨站点脚本”攻击、“SQL 注入”和许多其他问题。

安全特性

软件安全不是安全软件。在此处，我们讨论类似于身份验证、访问控制、机密性、加密和权限管理之类的主题。

时间和状态

分布式计算与时间和状态有关。即，为了使多个组件进行通信，必须共享状态，而这一切都需要时间。

大部分程序员会将其工作人格化。他们想象一个控制线程以他们会采用的相同方式执行整个程序（如果他们需要自己完成任务的话）。但是，现代计算机可以在不同的任务之间迅速切换，并且是在多核、多 CPU 或分布式系统中进行切换，两个事件可以在完全相同的时间发生。对于程序如何执行，程序员的模型和实际情况之间存在差距，匆忙之中缺陷便会趁虚而入。这些缺陷与线程、进程、时间和信息之间的意外交互相关。这些交互通过共享状态实现：信号、变量、文件系统以及基本上任何可以存储信息的介质。

API误用

API 是调用方与被调用方之间的合约。最常见的 API 滥用形式是由于调用方未能履行本合约而造成的。例如，如果程序未能在调用 chroot() 之后调用 chdir()，则违反了合约针对如何以安全的方式更改活动根目录的规定。库滥用的另一个绝佳示例是希望被调用方将可信 DNS 信息返回给调用方。在这种情况下，调用方通过对被调用方的行为做出某些假设（即返回值可用于身份验证）而滥用被调用方 API。此外，一方还可以从另一方违反调用方和被调用方间的合约。例如，如果编码器将 SecureRandom 归入子类并返回非随机值，则违反了合约。
ADF Faces Bad Practices: unsecure Attribute

Castor Bad Practices: Query Mode Not Read-Only

Castor Bad Practices: Unspecified Query Mode

Code Correctness: Call to System.gc()

Code Correctness: Class Does Not Implement equals

Code Correctness: Erroneous finalize() Method

Code Correctness: Incorrect Serializable Method Signature

Code Correctness: Multiple Stream Commits

Code Correctness: Negative Content-Length

Code Correctness: toString on Array

Dangerous Field

Dangerous Method

Dangerous Type

EJB Bad Practices: Use of AWT/Swing

EJB Bad Practices: Use of Class Loader

EJB Bad Practices: Use of Sockets

EJB Bad Practices: Use of Synchronization Primitives

EJB Bad Practices: Use of java.io

File Disclosure: J2EE

File Disclosure: Spring

File Disclosure: Spring Webflow

File Disclosure: Struts

Immutable Classes: Field Mutation

Immutable Classes: Non-final Fields

Immutable Classes: Public Mutable Fields

J2EE Bad Practices: Sockets

J2EE Bad Practices: getConnection()

Mass Assignment: Insecure Binder Configuration

Mass Assignment: Request Parameters Bound into Persisted Objects

Missing Check against Null

Missing Check for Null Parameter

Object Model Violation: Erroneous clone() Method

Object Model Violation: Just one of equals() and hashCode() Defined

Object Model Violation: Just one of restoreState() and saveState() Defined

Obsolete: Deprecated by ESAPI

Often Misused: Android Permission Check

Often Misused: Authentication

Often Misused: Boolean.getBoolean()

Often Misused: Encoding

Often Misused: File Upload

Often Misused: Spring Remote Service

Often Misused: Spring Web Service

Password Management: Weak Redundancy

Poor Style: Explicit Call to finalize()

Struts 2 Bad Practices: Application Map Tampering

Struts 2 Bad Practices: Dynamic Method Invocation

Struts 2 Bad Practices: Request Map Tampering

Struts 2 Bad Practices: Session Map Tampering

Unchecked Return Value

ADF Faces Bad Practices: unsecure Attribute

ABSTRACT

unsecure 属性会指定可在客户端上设置值的属性列表。

EXPLANATION

Oracle ADF Faces 组件的属性值通常只能在服务器上设置。但许多组件都允许开发人员定义可在客户端上设置的属性列表。这些组件的 unsecure 属性可以指定此列表。

目前唯一一个可在 unsecure 属性中显示的属性是 disabled，该属性允许客户端定义要启用和禁用的组件。最好不要让客户端控制只应在服务器上设置的属性值。

示例：以下代码显示了从用户收集密码信息并使用 unsecure 属性的 inputText 组件。


<af:inputText id="pwdBox"

              label="#{resources.PWD}"

              value=""#{userBean.password}

              unsecure="disabled"

              secret="true"

              required="true"/>

RECOMMENDATIONS

最好不要让客户端控制可在服务器上设置的属性值。特别是在使用输入和命令组件时，避免使用此功能。

REFERENCES

[1] Oracle ADF Faces Tag Reference

Android Bad Practices: Use of File Scheme Cookies

ABSTRACT

应用程序允许将 Cookie 用于 file:// 协议，这可能导致不利的安全隐患。

EXPLANATION

根据 RFC 2109，Cookie 严格意义上属于 HTTP 机制。不应用于除 HTTP 以外的其他协议，包括 file://。目前还不清楚它们的行为应该是什么，以及适用何种安全分隔规则。例如，从 Internet 下载到本地磁盘的 HTML 文件是否应与本地安装的任意 HTML 代码共享相同的 Cookie？

RECOMMENDATIONS

根据 Android 文档，将 Cookie 用于文件架构 URL 具有安全隐患并且默认会被关闭。请勿使用此功能，除非您可以确定不会发生意外的 Cookie 数据共享。

REFERENCES

[1] Standards Mapping - General Data Protection Regulation Indirect Access to Sensitive Data

Castor Bad Practices: Query Mode Not Read-Only

ABSTRACT

非只读模式的 Castor 查询可能会影响性能。

EXPLANATION

即便 castor 创建了对象的锁定，也不能阻止其他线程对该对象执行读取或写入。另外，与默认的共享模式相比，只读模式的查询的运行速度大约是前者的 7 倍。

例 1：下例指定 SHARED 查询模式，该模式允许读取和写入访问。

results = query.execute(Database.SHARED);

RECOMMENDATIONS

如果不需要对检索的对象进行修改，请确保查询为只读模式。

例 2：下例指定只读查询模式。

results = query.execute(Database.READONLY);

从设计的角度而言，使用只读查询符合最小特权的准则。如果攻击者找到了修改 Castor 对象的方法，只读查询可限制其造成的破坏。

REFERENCES

[1] ExoLab Group Castor JDO - Best practice

[2] Standards Mapping - Common Weakness Enumeration CWE ID 265

[3] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 7.1.1

[4] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 7.1.1

[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 7.1.2

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 7.1.2

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 7.1.2

[8] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3500 CAT II

[9] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3500 CAT II

[10] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3500 CAT II

[11] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3500 CAT II

[12] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3500 CAT II

[13] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3500 CAT II

[14] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3500 CAT II

Castor Bad Practices: Unspecified Query Mode

ABSTRACT

该 Castor 查询未明确定义查询模式。

EXPLANATION

默认情况下，Castor 以共享模式执行查询。由于共享模式允许读取访问和写入访问，因此该查询需要采取何种操作并不清楚。如果要在只读上下文中使用该对象，则共享访问会增加不必要的性能负担。

例 1：以下示例未指定查询模式。

results = query.execute(); //missing query mode

RECOMMENDATIONS

为所有查询明确设置查询模式。该操作可以更清楚地显示查询的意图，而且还能够提高性能。

例 2：下例指定只读查询模式：

results = query.execute(Database.READONLY);

从设计的角度而言，采用只读查询模式可限制攻击者在程序人员不希望进行更新的位置更新对象的潜在风险。

REFERENCES

[1] ExoLab Group Castor JDO - Best practice

[2] ExoLab Group, Intalio Inc., and Contributors Database (Castor JavaDoc)

[3] Standards Mapping - Common Weakness Enumeration CWE ID 265

[4] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 7.1.1

[5] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 7.1.1

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 7.1.2

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 7.1.2

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 7.1.2

[9] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3500 CAT II

[10] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3500 CAT II

[11] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3500 CAT II

[12] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3500 CAT II

[13] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3500 CAT II

[14] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3500 CAT II

[15] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3500 CAT II

Code Correctness: Call to System.gc()

ABSTRACT

显式的调用垃圾回收机制可以预示系统性能可能出现的问题。

EXPLANATION

几乎所有的 Java 开发人员都会在工作中碰到这样的情况，有时候某个问题看上去非常神秘，让人难以理解，而且根本调试不出来，好像一点办法都没有，只能将原因归结为垃圾回收机制的问题。特别是当问题与 time and state 相关时，我们可以根据经验进行推断，并找到支持这一理论的根据：插入对 System.gc() 的调用似乎可以使问题迎刃而解。

在我们遇到的绝大多数情况中，调用 System.gc() 并非什么好方法。事实上，过于频繁地调用 System.gc() 会带来性能问题。

RECOMMENDATIONS

发现通过调用 System.gc() 似乎解决了问题时，找找看问题的解决是否源于其他原因，特别是涉及到了调用时间以及线程、进程、JVM 和操作系统间的交互问题。问题的症结可能是 I/O 缓存、同步和 race condition。

REFERENCES

[1] D. H. Hovermeyer FindBugs User Manual

[2] Standards Mapping - Common Weakness Enumeration CWE ID 730

[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)

[4] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service

[5] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9

[6] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II

[7] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II

[8] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II

[9] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II

[10] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II

[11] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II

[12] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II

[13] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II

[14] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II

[15] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II

[16] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service

[17] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)

Code Correctness: Class Does Not Implement equals

ABSTRACT

在没有实现 equals() 的对象上调用了 equals() 方法。

EXPLANATION

当比较对象时，开发人员通常希望比较对象的属性。然而，在没有明确实现 equals() 的类（或任何超类/接口）上调用 equals() 会导致调用继承自 java.lang.Object 的 equals() 方法。Object.equals() 将比较两个对象实例，查看它们是否相同，而不是比较对象成员字段或其他属性。尽管可以合法地使用 Object.equals()，但这通常表示存在错误代码。
例 1：

public class AccountGroup

{

	private int gid;

 

	public int getGid()

	{

		return gid;

	}

 

	public void setGid(int newGid)

	{

		gid = newGid;

	}

}
...

public class CompareGroup

{

	public boolean compareGroups(AccountGroup group1, AccountGroup group2)

	{

		return group1.equals(group2);   //equals() is not implemented in AccountGroup

	}

}

RECOMMENDATIONS

验证 Object.equals() 的使用确实是您要调用的方法。如果不是，那么可实现 equals() 方法，或者使用其他方法来比较对象。

例 2：以下代码将 equals() 方法添加到“说明”部分中的示例。

public class AccountGroup

{

	private int gid;

 

	public int getGid()

	{

		return gid;

	}

 

	public void setGid(int newGid)

	{

		gid = newGid;

	}

 

	public boolean equals(Object o)

	{

		if (!(o instanceof AccountGroup))

			return false;

		AccountGroup other = (AccountGroup) o;

		return (gid == other.getGid());

	}

}

...

public class CompareGroup

{

	public static boolean compareGroups(AccountGroup group1, AccountGroup group2)

	{

		return group1.equals(group2);

	}

}

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 398

Code Correctness: Erroneous finalize() Method

ABSTRACT

finalize() 方法应该调用 super.finalize()。

EXPLANATION

The Java Language Specification 中指出，finalize() 方法调用 super.finalize() 是一种非常好的做法 [1]。

例 1：以下方法没有调用 super.finalize()。

protected void finalize() {

  discardNative();

}

RECOMMENDATIONS

每次实现 finalize 方法时，都应该调用 super.finalize()。

例 2：例 1 中的代码应该用以下方式重写：

protected void finalize() {

  discardNative();

  super.finalize();

}

REFERENCES

[1] J. Gosling, B. Joy, G. Steele, G. Bracha The Java Language Specification, Second Edition Addison-Wesley

[2] MET12-J. Do not use finalizers CERT

[3] Standards Mapping - Common Weakness Enumeration CWE ID 568

Code Correctness: Incorrect Serializable Method Signature

ABSTRACT

在序列化方法上使用错误的方法签名可能导致永远不会调用该方法。

EXPLANATION

代码正确性：当可序列化的类创建序列化或反序列化函数但未采用正确的签名时，会发生“可序列化的方法签名不正确”的问题：

private void writeObject(java.io.ObjectOutputStream out) throws IOException;

private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;

private void readObjectNoData() throws ObjectStreamException;

未使用序列化所要求的方法签名会导致在序列化/反序列化过程中永远不会调用该方法，这意味着将无法完成序列化/反序列化，或意味着不可信赖的代码可以获取对象的访问权限。如果存在未抛出的异常，则可能意味着序列化/反序列化将失败并使应用程序崩溃，甚或可能悄然失败，以致构造的对象只是部分正确，从而导致出现极难调试的缺陷。调用程序应捕获这些异常，以便可以正确地处理错误的序列化/反序列化，而不会出现崩溃或部分构造的对象。

RECOMMENDATIONS

在使用 Java 中需要特殊处理的类的序列化时，writeObject()、readObject() 和 readObjectNoData 方法必须具有正确的签名：

private void writeObject(java.io.ObjectOutputStream out) throws IOException;

private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;

private void readObjectNoData() throws ObjectStreamException;

REFERENCES

[1] SER01-J. Do not deviate from the proper signatures of serialization methods CERT

Code Correctness: Multiple Stream Commits

ABSTRACT

提交 servlet 的输出流之后，重置流缓冲区或执行重新提交该数据流的其他任何操作都是错误的做法。与之类似，在调用 getOutputStream 之后调用 getWriter() 也是错误的做法，反之亦然。

EXPLANATION

转发 HttpServletRequest、重定向 HttpServletResponse 或者刷新 servlet 的输出流缓冲区会导致提交相关的数据流。后续执行的任何缓冲区重置或数据流提交操作，例如额外的刷新或重定向，将会导致出现 IllegalStateException。

此外，Java servlets 允许使用 ServletOutputStream 或 PrintWriter（但不能同时使用）将数据写入响应数据流。调用 getOutputStream() 之后调用 getWriter() 或者反向调用，也会导致出现 IllegalStateException。

在运行时，IllegalStateException 会阻止响应处理程序完成运行，轻易地使其中断响应。这会导致服务器不稳定，也间接表明 servlet 实现不正确。

例 1：以下代码会在 servlet 的输出流缓冲区刷新之后重定向其响应。

public class RedirectServlet extends HttpServlet {

    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {

        ...

        OutputStream out = res.getOutputStream();

        ...

        // flushes, and thereby commits, the output stream

        out.flush();

        out.close();        // redirecting the response causes an IllegalStateException

        res.sendRedirect("http://www.acme.com");

    }

}

例 2：相反，以下代码在请求转发之后会尝试写入并刷新 PrintWriter 的缓冲区。

public class FlushServlet extends HttpServlet {

    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {

        ...

        // forwards the request, implicitly committing the stream

        getServletConfig().getServletContext().getRequestDispatcher("/jsp/boom.jsp").forward(req, res);

        ...

 

        // IllegalStateException; cannot redirect after forwarding

        res.sendRedirect("http://www.acme.com/jsp/boomboom.jsp");

 

        PrintWriter out = res.getWriter();

 

        // writing to an already-committed stream will not cause an exception,

        // but will not apply these changes to the final output, either

        out.print("Writing here does nothing");

 

        // IllegalStateException; cannot flush a response's buffer after forwarding the request

        out.flush();

        out.close();

    }

}

RECOMMENDATIONS

确保提交数据流之后为未对其进行其他更改。对数据流执行其他写入操作最多只是操作无效，而执行其他提交操作可能会导致 servlet 抛出 IllegalStateException。如果可能，最好遵守以下准则：

执行 forward() 或 sendRedirect 之后立即返回。
避免在调用 ServletResponse.getWriter() 或 ServletResponse.getOuputStream() 之后调用 forward() 或 sendRedirect()。

REFERENCES

[1] IllegalStateException in a Servlet - when & why do we get?

[2] Standards Mapping - Common Weakness Enumeration CWE ID 398

[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)

[4] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II

[5] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II

[6] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II

Code Correctness: Negative Content-Length

ABSTRACT

Content-Length 头文件设为负值。

EXPLANATION

在大多数情况下，设置 Content-Length 请求标题表示开发者对发送给服务器的 POST 数据长度感兴趣。但是，此标题应为 0 或正整数。

示例 1：以下代码将设置不正确的 Content-Length。

URL url = new URL("http://www.hp.com");

HttpURLConnection huc = (HttpURLConnection)url.openConnection();

huc.setRequestProperty("Content-Length", "-1000");

RECOMMENDATIONS

请使用能正确计算和设置 Content-Length 头文件的库。

REFERENCES

[1] Standards Mapping - Common Weakness Enumeration CWE ID 398

[2] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6

[3] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6

[4] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6

Code Correctness: toString on Array

ABSTRACT

toString() 在数组上被调用。

EXPLANATION

大多数情况下，在数组上调用 toString() 表示开发者希望将数组内容作为字符串返回。然而，在数组上直接调用 toString() 将返回一个字符串值，它包含内存中该数组的类型和哈希码。例 1：以下代码将输出 [Ljava.lang.String;@1232121。

String[] strList = new String[5];

...

System.out.println(strList);

RECOMMENDATIONS

在 Java 5 [1] 中引入了多种 Array.toString() 方法。这些方法将以逗号分隔的格式返回数组内容的字符串形式。例 2：

String[] strList = new String[5];

...

System.out.println(Arrays.toString(strList));

如果您使用的 Java 的版本较旧，那么可能需要迭代通过数组以获得每个元素的值。

REFERENCES

[1] Class Arrays Sun Microsystems

[2] Standards Mapping - Common Weakness Enumeration CWE ID 398

Dangerous Field

ABSTRACT

该字段已标注为危险。所有对其的使用都将加注标记。

EXPLANATION

已将注释 FortifyDangerous 应用于此字段。这被用来表示该类型危险，并且所有对其的使用都应进行安全性检查。

RECOMMENDATIONS

检查其用法以确保其正确性与安全性。

Dangerous Method

ABSTRACT

该方法已标注为危险。所有对此方法的使用都会标记为问题。

EXPLANATION

已将注释 FortifyDangerous 应用于此方法。这被用来表示该类型危险，并且所有对其的使用都应进行安全性检查。

RECOMMENDATIONS

检查其用法以确保其正确性与安全性。

REFERENCES

[1] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6

[2] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6

[3] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6

[4] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676

Dangerous Type

ABSTRACT

这是标注为危险类型的变量。

EXPLANATION

已将注释 FortifyDangerous 应用于此类型。这被用来表示该类型危险，并且所有对其的使用都应进行安全性检查。

RECOMMENDATIONS

检查其用法以确保其正确性与安全性。

REFERENCES

[1] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6

[2] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6

[3] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6

EJB Bad Practices: Use of AWT/Swing

ABSTRACT

程序使用了 AWT/Swing，这违反了企业级 JavaBeans 编程规范。

EXPLANATION

企业级 JavaBeans 编程规范要求每个 bean 提供者都必须遵守一系列编程规范，以确保 bean 在任何 EJB 容器 [1] 中的可移植性与行为的一致性。

在这里，程序违背了以下 EJB 指导原则：

“一个企业级 bean 必须禁止利用 AWT 机制，将信息输出到显示设备，或者通过键盘输入信息。”

制定该规范理由如下：

“大部分服务器都不允许应用程序中的程序与连接至服务器系统上的键盘/显示设备进行直接交互。”

RECOMMENDATIONS

为了确保在多部署环境中的可移植性与行为的一致性，应该严格遵守企业级 JavaBeans 规范中建议的指导原则。

REFERENCES

[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems

[2] Standards Mapping - Common Weakness Enumeration CWE ID 575

EJB Bad Practices: Use of Class Loader

ABSTRACT

程序使用了程序类加载器，这违反了企业级 JavaBeans 编程规范。

EXPLANATION

企业级 JavaBeans 编程规范要求每个 bean 提供者都必须遵守一系列编程规范，以确保 bean 在任何 EJB 容器 [1] 中的可移植性与行为的一致性。

在这里，程序违背了以下 EJB 指导原则：

“企业级 bean 必须禁止以下内容：创建类加载器；获取当前类加载器；设置类加载器上下文；设置安全管理器；创建新的安全管理器；停止 JVM 或者篡改输入、输出及错误流。”

制定该规范理由如下：

“这些功能都是为 EJB 容器预留的。允许企业级 bean 使用这些功能会造成一些安全上的漏洞，并使容器无法正确地管理运行时环境。”

RECOMMENDATIONS

为了确保在多部署环境中的可移植性与行为的一致性，应该严格遵守企业级 JavaBeans 规范中建议的指导原则。

REFERENCES

[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems

[2] Standards Mapping - Common Weakness Enumeration CWE ID 578

EJB Bad Practices: Use of Sockets

ABSTRACT

程序使用了 socket 接口，这违反了企业级 JavaBeans 编程规范。

EXPLANATION

企业级 JavaBeans 编程规范要求每个 bean 提供者都必须遵守一系列编程规范，以确保 bean 在任何 EJB 容器 [1] 中的可移植性与行为的一致性。

在这里，程序违背了以下 EJB 指导原则：

“一个企业级 bean 必须禁止监听 Socket 接口、接受 Socket 连接或者使用 Socket 做多点传送。”

制定该规范理由如下：

“EJB 体系结构允许企业级 bean 实例作为网络 Socket 客户端来运行，但禁止其作为网络服务器来运行。而且，允许企业级 bean 实例作为网络服务器来运行与企业级 bean 的基本功能（为 EJB 客户端提供服务）相冲突。”

RECOMMENDATIONS

为了确保在多部署环境中的可移植性与行为的一致性，应该严格遵守企业级 JavaBeans 规范中建议的指导原则。

REFERENCES

[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems

[2] Standards Mapping - Common Weakness Enumeration CWE ID 577

EJB Bad Practices: Use of Synchronization Primitives

ABSTRACT

程序使用了多线程同步，这违反了企业级 JavaBeans 编程规范。

EXPLANATION

企业级 JavaBeans 编程规范要求每个 bean 提供者都必须遵守一系列编程规范，以确保 bean 在任何 EJB 容器 [1] 中的可移植性与行为的一致性。

在这里，程序违背了以下 EJB 指导原则：

“一个企业级 bean 必须禁止利用线程同步机制来同步执行多个实例。”

制定该规范理由如下：

“这一规则要求确保一致的运行时语义，因为一些 EJB 容器可能会使用单个 JVM 来执行所有 bean 实例，而其他一些可能会跨多个 JVM 分布各个 bean 实例。”

RECOMMENDATIONS

为了确保在多部署环境中的可移植性与行为的一致性，应该严格遵守企业级 JavaBeans 规范中建议的指导原则。

REFERENCES

[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems

[2] THI01-J. Do not invoke ThreadGroup methods CERT

[3] Standards Mapping - Common Weakness Enumeration CWE ID 574

EJB Bad Practices: Use of java.io

ABSTRACT

程序使用了 java.io 包，这违反了企业级 JavaBeans 编程规范。

EXPLANATION

企业级 JavaBeans 编程规范要求每个 bean 提供者都必须遵守一系列编程规范，以确保 bean 在任何 EJB 容器 [1] 中的可移植性与行为的一致性。

在这里，程序违背了以下 EJB 指导原则：

“一个企业级 bean 必须禁止利用 java.io 包访问 file system 中的文件和目录。”

制定该规范理由如下：

“file system API 不适用于商业组件的数据访问。商业组件应利用资源管理 API（如 JDBC）存储数据。”

RECOMMENDATIONS

为了确保在多部署环境中的可移植性与行为的一致性，应该严格遵守企业级 JavaBeans 规范中建议的指导原则。

REFERENCES

[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems

[2] Standards Mapping - Common Weakness Enumeration CWE ID 576

File Disclosure: J2EE

ABSTRACT

若通过用户输入构造服务器端重定向路径，攻击者便能够下载应用程序二进制码（包括应用程序的类或 jar 文件）或者查看受保护的目录下的任意文件。

EXPLANATION

在以下情况下，会发生文件泄露：
1、数据从一个不可信赖的数据源进入程序。

2、数据用于动态地构造一个路径。

例 1：下面的代码会接受不可信赖的数据，并使用其构造服务器端转发所使用的路径。

...

String returnURL = request.getParameter("returnURL");

	RequestDispatcher rd = request.getRequestDispatcher(returnURL);

	rd.forward();

...

例 2：下面的代码会接受不可信赖的数据，并使用其构造服务器端转发所使用的路径。

...

	<% String returnURL = request.getParameter("returnURL"); %>

	<jsp:include page="<%=returnURL%>" />

	...

如果攻击者使用请求参数提供与某个敏感文件位置相匹配的 URL，他们将能够查看该文件。例如，使用 “http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml” 将能够查看该应用程序的 applicationContext.xml 文件。一旦攻击者掌握了 applicationContext.xml 的信息，他们便能够定位和下载 applicationContext.xml 中引用的其他配置文件，甚至类文件或 jar 文件。这样一来，攻击者将能够获得与应用程序有关的敏感信息，并以之为目标发动其他类型的攻击。

RECOMMENDATIONS

请不要要使用不可信赖的数据请求服务器端资源。而应使用介于位置与路径之间的间接方法。请不要使用：

< a href="http://www.yourcorp.com/webApp/logic?nextPage=WEB-INF/signup.jsp">New Customer</a>

而应使用：

< a href="http://www.yourcorp.com/webApp/logic?nextPage=newCustomer">New Customer</a>

服务器端逻辑应具有逻辑名称与服务器端路径的映射（以逻辑名称为键），在上例中，键“newCustome”中存储的路径应为“/WEB-INF/signup.jsp”。

REFERENCES

[1] Ryan Berg and Dinis Cruz Two Security Vulnerabilities in the Spring Framework’s MVC

[2] INPUT-1: Validate inputs Oracle

[3] Standards Mapping - Common Weakness Enumeration CWE ID 552

[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[5] Standards Mapping - OWASP Mobile Top 10 Risks 2014 M1 Weak Server Side Controls

[6] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input

[7] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference

[8] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References

[9] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8

[16] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 073

[17] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I

[18] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I

[19] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I

[20] Standards Mapping - Web Application Security Consortium Version 2.00 URL Redirector Abuse (WASC-38)

File Disclosure: Spring

ABSTRACT

若通过用户输入构造服务器端重定向路径，攻击者便能够下载应用程序二进制码（包括应用程序的类或 jar 文件）或者查看受保护的目录下的任意文件。

EXPLANATION

在以下情况下，会发生文件泄露：
1、数据从一个不可信赖的数据源进入程序。

2、数据用于动态地构造一个路径。

例 1：下面的代码会接受不可信赖的数据，并使用其构造服务器端转发所使用的路径。

...

	String returnURL = request.getParameter("returnURL");

	return new ModelAndView(returnURL);

	...