Java安全开发规范

Java安全开发规范

第1章前言

为提高应用安全水平，特制定本规范对代码编制进行规范。

规范中的安全要求按照严格程度分为三级：

Policy

必须遵循的策略，实现方法可以自定义，但不能外翻策略的规定。

Discipline

必须遵守的纪律，必须按照规定中的描述实施，绝对不能违反。

Guideline

建议性的指南和规范，将逐步要求遵循实施。

第2章Java安全性开发规范

2.1跨站脚本XSS

?风险及危害性：

跨站脚本XSS指利用网站漏洞从用户那里恶意盗取信息。用户在浏览网站、使用即时通讯软件、甚至在阅读电子邮件时，通常会点击其中的链接。攻击者通过在链接中插入恶意代码，就能够盗取用户信息。攻击者通常会用十六进制（或其他编码方式）将链接编码，以免用户怀疑它的合法性。网站在接收到包含恶意代码的请求之后会产成一个包含恶意代码的页面，而这个页面看起来就像是那个网站应当生成的合法页面一样。许多流行的留言本和论坛程序允许用户发表包含HTML和javascript的帖子。假设用户甲发表了一篇包含恶意脚本的帖子，那么用户乙在浏览这篇帖子时，恶意脚本就会执行，盗取用户乙的session信息。

如何导致XSS攻击，一般来说来自http的post，或者get方式取得参数值很可能为恶意代码，如果开发者直接用这些参数组合成http链接，用户点击该

连接，就会造成XSS攻击风险。

?应对措施

开发者要保证代码的安全性，使其免受XSS攻击，可采取以下措施：

1．过滤或转换用户提交数据中的HTML代码。

2．限制用户提交数据的长度

?非安全代码示例

<%

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

%>

name="importXml"

action="mofXml.cmd?method=importMofXml&primaryKey=<%=mofWindowId%>" method="post">

?安全代码示例

<%

String mofWindowId=XSSCheck.getParameter(request,”mofWindowId”);

%>

name="importXml"

action="mofXml.cmd?method=importMofXml&primaryKey=<%=mofWindowId%>" method="post">

注：XSSCheck为公用工具类，用于XSS检查，其getParameter实现逻辑如下：

1、通过参数名称，从请求中取得参数值。

2、将&,<,>,’,”转义: & -> &

< -> ⁢

> -> >

“ -> "

‘ -> ´

3、返回安全的字符串。

2.2违反信任边界规则（Trust Boundary Violation）

?风险及危害

一个受信任的边界可以被认为是由系统划出的边境，例如session,attribute，aplication,数据库，文件等在服务端存储边界都认为是受信任的。反之来来自http的post，或者get方式取得参数值是不受信任的。凡

是将非受信任边界的参数转入到受信任的边界内，需要对参数值进行检查，否则造成信任边界违例，当开发者直接操作受信边界内部的参数时会认为该参数是安全的，而造成安全隐患，例如脚本注入，XSS攻击等。

?应对措施

开发者要保证代码的安全性，当参数信任边界切换的时候，对参数值进行检查，检查其内容里是否用非法脚本信息：

1．过滤或转换用户提交数据中的HTML代码。

2．限制用户提交数据的长度

?非安全代码示例

String dsn = request.getParameter("DSN");

String sql = request.getParameter("SQL");

if (sql == null) {

sql = "";

}

dsn = (String) session.getAttribute("SqlHelper.DSN");

} else {

session.setAttribute("SqlHelper.DSN", dsn);

}

?安全代码示例

String dsn = XSSCheck.getParameter(request,"DSN");

String sql = request.getParameter("SQL");

if (sql == null) {

sql = "";

}

dsn = (String) session.getAttribute("SqlHelper.DSN");

} else {

session.setAttribute("SqlHelper.DSN", dsn);

}

2.3不安全的反射（Unsafe Reflection）

?风险及危害

攻击者能够建立一个不可预测的、贯穿应用程序的控制流程，使得他们可以潜在地避开安全检测。攻击者能够建立一个在开发者意料之外的、不可预测的控制流程，贯穿应用程序始终。这种形式的攻击能够使得攻击者避开身份鉴定，或者访问控制检测，或者使得应用程序以一种意料之外的方式运行。如果攻击者能够将文件上传到应用程序的classpath或者添加一个classpath的新入口，那么

这将导致应用程序陷入完全的困境。无论是上面哪种情况，攻击者都能使用反射将新的、多数情况下恶意的行为引入应用程序。

?应对措施

开发者可以定制一份白名单，通过关键字关联需要实例化的类，http请求中传递是不是实际的类名，而是关键字，开发者得到关键字后在白名单中寻找需要的信息，进行实例化。

?非安全代码示例

String className = request.getParameter("classname");

if ((className != null)&& ((className = className.trim()).length() != 0)) {

// Attempt to load class and get its location.

try {

ProtectionDomain pd = Class.forName(className).getProtectionDomain();

if (pd != null) {

CodeSource cs = pd.getCodeSource();

?安全代码示例

String classNameKey = request.getParameter("classname");

String className=WhiteList.get(classNameKey);

if ((className != null)&& ((className = className.trim()).length() != 0)) {

// Attempt to load class and get its location.

try {

ProtectionDomain pd = Class.forName(className).getProtectionDomain();

if (pd != null) {

CodeSource cs = pd.getCodeSource();

注1：WhiteList.get其具体实现如下：

1、从描述白名单的文件中，读出白名单列表；

2、根据传入的关键值寻找该白名单的真实值；

3、返回该值，如果没有找到，抛出异常。

2.4SQL 注入（SQL Injection）

?风险及危害：

SQL注入是一种常见攻击方式，由于开发者采用sql拼凑的方式，用来自网络中不安全的参数形成sql语句访问数据库，攻击者常常采用该漏洞组合成非法的sql语句，使得信息泄露，访问到本来没有权限查看的内容或者直接破坏数据

库信息等。发生SQL Injection有以下几种方式：

一、进入程序的数据来自不可信赖的资源。

二、数据用于动态构造一个SQL查询。

?应对措施：

一、开发者可以采用带参方式访问sql语句访问数据库，在java中即采用PreparedStatement的方式访问数据库。

二、如果开发者一定要使用sql拼凑的方式访问数据，对字符串要检查并过滤单引号’,对于可能为整形或者浮点类型参数，要先转整形，或者浮点，再进行拼凑。

?非安全代码示例

String userid= (String)session.getAttribute("classname");

String param1= request.getParameter(“param1”);

StringBuffer strbuf=new StringBuffer();

strbuf.append(“select * from table1 where userid=”);

strbuf.append(userid);

strbuf.append(“ and param1=’”).append(param1).append(“’”);

String sql=strbuf.toString();

//当param1为 test’ or 1=1

那么这条语句就为 select * from table1 where userid=$userid and param1=’test’ or 1=1这样查询出来的数据就超越了这个用户访问的范围。?安全代码示例

方法一：采用PreparedStatement访问数据库。

String userid= (String)session.getAttribute("classname");

String param1= request.getParameter(“param1”);

StringBuffer strbuf=new StringBuffer();

String sql= “select * from table1 where userid=? and param1=?”;

方法二：检查并过滤特殊字符

String userid= (String)session.getAttribute("classname");

String param1= request.getParameter(“param1”);

StringBuffer strbuf=new StringBuffer();

strbuf.append(“select * from table1 where userid=”);

strbuf.append(userid);

strbuf.append(“ and param1=’”)

.append(SqlInjectCheck.checkStringValue(param1)).append(“’”);

String sql=strbuf.toString();

注：SqlInjectCheck.checkStringValue是公用函数，其实现如下：

1、将’转化成´

2、返回字符串。

2.5系统信息泄露（System Information Leakage）

?风险及危害：

JSP中出现HTML注释（System Information Leakage：HTML Comment in JSP），攻击者可以通过html的注释得到用于攻击的信息。

?应对措施：

应该使用JSP注释代替HTML注释。(JSP注释不会被传递给用户)。

?非安全代码示例

?安全代码示例

<%//此处是取得系统信息的注释%>

2.6资源注入(resource injection)

?风险及危害：

允许用户可以通过输入来控制资源标识符，会让攻击者有能力访问或修改被保护的系统资源。

发生resource injection有以下两种方式：

1. 攻击者可以指定已使用的标识符来访问系统资源。例如，攻击者可以指定用来连接到网络资源的端口号。

2. 攻击者可以通过指定特定资源来获取某种能力，而这种能力在一般情况下是不可能获得的。

?应对措施

开发者可以定制一份白名单，通过关键字关联需要资源内容，http请求中传递是不是实际的资源内容，而是关键字，开发者得到关键字后在白名单中寻找需要的信息，进行后续操作。

?非安全代码示例

String dsn = request.getParameter("DSN");

DataSource ds = (DataSource) ctx.lookup(dsn);

?安全代码示例

String dsnKey = request.getParameter("DSN ");

String dsn =WhiteList.get(dsnKey);

DataSource ds = (DataSource) ctx.lookup(dsn);