银行系统安全性 代码检查方案(上篇)

第1章 WEB安全检查主要针对的问题

 SQL注入
SQL注入就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。
 跨站脚本攻击
跨站脚本攻击(也称为XSS)指利用网站漏洞从用户那里恶意盗取信息。用户在浏览网页时通常会点击其中的链接。攻击者通过在链接中插入恶意代码来盗取用户信息。
 数据篡改(URL篡改、签名数据、报文)
数据篡改主要包含对访问URL的篡改,对交易数据的篡改,以及对通讯报文中数据域的篡改。
 密码安全
密码做为网上银行交易的重要安全保证,其安全性具有非同寻常的意义,网银中主要的密码安全保障主要依靠网银的安全控件和加密算法来保证,对于没有使用密码控件和密文传输的行为,需要进行检查和整改。

第2章 WEB安全应当遵循的基本原则

2.1 总体原则

1) 使用POST方法来保证Request参数安全,不得在具有执行、写权限的交易中使用GET方法传递参数。
2) 对所有涉及私密信息的通信都是用SSL,拒绝不使用SSL的请求。
3) 外部数据
a) 不信任任何来源于应用程序外部(包括:客户端提交、数据库返回、第三方系统返回、配置文件读取)的数据。
b) 为非可信数据和可信数据定义独立的存储数据结构,所有非可信数据均须进行合法性验证。
c) 除验证逻辑代码外,其余代码不得访问非可信数据区。
4) 合法性验证不得依赖于前一个Request中的数据验证结果。
5) 对所有的异常构造统一的错误页面,包括HTTP错误和未处理的异常,防止攻击者从应用程序的默认出错页面中获取系统信息。
6) 使用通用的错误消息
a) 不区分错误的用户名和错误的密码,认证失败信息应统一为”认证失败,请重试。”
b) 在返回的报告中不包含主机信息、网络信息、DNS信息、软件版本信息、错误代码或者其它发生的错误的详细信息。
c) 不要把错误的细节放在错误页面的注释里。
7) 不得在JSP页面中保留具有提示意义的代码注释。

2.2 会话安全原则

1) 使用足够长度和足够随机的会话标识符,会话ID应包含长度不得低于128位的随机数。
2) 在每次认证后打开一个新的会话。即使已经有与用户关联的会话标示符,在用户认证成功之后要重新建立一个会话。
3) 强制使用SSL连接方式建立会话,并且经会话的安全标识设置为cookie只能通过安全连接进行传输。
4) 为会话设置一个最大空闲时间(会话超时时间),并强制执行。会话超时时间不得超过30分钟。
5) 为会话设置最大生存周期,并强制执行。会话最大生存周期不得超过6小时,一旦会话过期,用户需重新认证以建立新的会话。
6) 提供注销(退出)操作,允许用户终止其会话以保护自己的账号。
7) 当用户关闭浏览器或客户端应用程序时,视为用户注销此次登陆,应终止会话。
8) 会话终止时,应清除内存中与本次会话相关的数据。

2.3 输入验证原则

2.3.1 集中输入验证
1) 把输入验证作为软件框架的一部分,集中验证如下数据:日期/时间域、金额域、数字域、数据域长度、非空检查、接口合法性等。
2) 统一的输入验证策略。确保各应用模块使用统一的输入验证策略,便于统一的升级和修改,针对同类数据采取统一的异常控制。
3) 输入验证完整性。对所有外部数据进行强制有效性检查,拒绝异常数据输入,保证所有的输入信息都已被验证,以避免由于应用模块忽略验证输入数据带来的系统风险。
4) 降低系统耦合度。有效降低工程实施复杂度,减少开发工作量,提高系统鲁棒性。

2.3.2 可信边界

1) 应定义清晰的可信边界,使用独立的数据结构分别存储可信数据与非可信数据,并尽量减少数据穿越可信边界的次数。
2) 当数据穿越可信边界的时候,必须进行合法性验证。
3) 除输入验证代码外,其余代码不得访问非可信数据区。
例1:接受HTTP请求,并将获取的参数存放在HTTP session中供业务模块使用。

2.3.3 非可信数据

1) 任何来源于应用系统外部的数据均为非可信数据,常见的非可信数据有如下表现形式:
a) 用户输入(客户端系统);
b) 文件导入(客户端系统);
c) HTTP请求(服务端系统):验证来自HTTP请求中所有数据,恶意数据可以从表单域,URL参数,cookie,http头以及URL自身传入http头以及URL自身传入。
d) 服务端返回(客户端系统);
e) 第三方系统返回(服务端系统);
f) 命令行参数;
g) 配置文件。

2.3.4 拒绝失败数据

1) 拒绝验证失败的数据,不得试图对其进行修复。
例2: 校验用户输入长度,拒绝超长输入

2.3.5 输入验证形式

1) 尽量使用相对”最强”形式验证输入。
2) 按照间接选择、白名单以及黑名单的顺序选择验证形式。
例3: 对外支付交易,校验付方账号合法性。

2.3.6 基本验证

1) 防范元字符攻击:
不得允许输入域中包含具有特定含义的字符。
在业务逻辑处理输入数据之前采用统一的过滤器对特殊字符进行处理。
2) 根据业务需求,为每个输入域指定输入验证的最小和最大长度。
3) 根据业务需求,为每个整数输入域指定可保守的、预期的上下界。
例4: [JAVA]某购物网站,未对客户可选购的商品数量上限进行验证

2.3.7 基于上下文验证

1) 不得仅对输入数据孤立的合法性验证,应结合业务逻辑上下文验证某个用户对某个业务或数据的访问操作权限。
2) 根据设计要求,验证必输项不得为空。
3) 根据设计要求,验证输入项类型。
4) 根据设计要求,验证输入项取值范围。
5) 根据设计要求,至少应验证如下输入项业务逻辑关系:
a) 用户ID与相关业务操作权限;
b) 用户ID与业务流程操作权限;
c) 用户ID与付方账户支付权限;
d) 用户ID与相关账户资金限额;
e) 用户ID与业务数据查询权限。

转载请注明:猫头鹰工作室 » 银行系统安全性 代码检查方案(上篇)

喜欢 (0)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址