XX-3-DEV-安全编码规范20110501

第10页共NUMPAGES\*Arabic10页文档编号文档编号XX_安全编码规范版本号V2.0密级秘密安全编码规范版本控制编号修订人修订时间版本号修订内容说明第10页共NUMPAGES\*Arabic10页目录TOCHYPERLINK\l"__RefHeading__2_470868493"1背景 4HYPERLINK\l"__RefHeading__4_470868493"2目标 4HYPERLINK\l"__RefHeading__6_470868493"3适应范围 4HYPERLINK\l"__RefHeading__8_470868493"4安全概念 4HYPERLINK\l"__RefHeading__10_470868493"5应用安全编码规范 4HYPERLINK\l"__RefHeading__12_470868493"1.1Session使用及处理 4HYPERLINK\l"__RefHeading__14_470868493"1.2Cookie使用及处理 4HYPERLINK\l"__RefHeading__16_470868493"1.3URL参数 5HYPERLINK\l"__RefHeading__18_470868493"1.4表单提交 5HYPERLINK\l"__RefHeading__20_470868493"1.5Ajax 5HYPERLINK\l"__RefHeading__22_470868493"1.6接口签名 5HYPERLINK\l"__RefHeading__24_470868493"1.7信息验证 6HYPERLINK\l"__RefHeading__26_470868493"1.8线程控制 6HYPERLINK\l"__RefHeading__28_470868493"1.9业务边界及业务检测 6HYPERLINK\l"__RefHeading__30_470868493"1.10数据库 7HYPERLINK\l"__RefHeading__32_470868493"1.11资金处理 7HYPERLINK\l"__RefHeading__34_470868493"1.12数据 7HYPERLINK\l"__RefHeading__36_470868493"1.13远程调用 7HYPERLINK\l"__RefHeading__38_470868493"1.14口令策略 8HYPERLINK\l"__RefHeading__40_470868493"1.15应用攻击防守策略 8HYPERLINK\l"__RefHeading__42_470868493"6JVM安全和java语言安全特性 8HYPERLINK\l"__RefHeading__44_470868493"7日常维护发布检测规范 9HYPERLINK\l"__RefHeading__46_470868493"8参考资料 10背景安全编码规范可以说是公司安全体系的重要部分，安全编码做得不好，直接导致系统漏洞，资金账户被盗，用户损失，更重要的是给XXX公司的形象带来负面的影响。因此安全编码规范亟待出炉，来进一步规范公司的工程师编码安全意识。本编码规范以J2EE相关编程为基础，进行举例和解释。目标从应用系统安全角度出发，结合过去的编码经验和问题总结，给出合适的安全编码条文实例，突出重点和安全分类，在目前已知的多项重大安全问题上进行总结和目前流行的安全问题做法，当然安全问题的多样性，也会不断进行修改本规范，以持续的进行指导XXX工程师的编码安全意识。适应范围公司相关程序员、工程师及相关技术人员。安全概念不仅仅是被攻击和解密，造成代码覆盖、金额数据错误、内存溢出，死锁，宕机，甚至发布顺序错误等等一切非正常现象，XXX都认为是安全问题。软件开发安全应该在几个阶段都有体现，需求，设计，开发，测试，部署上线等多个阶段。本规范主要描述在研发编码阶段的注意事项。本标准基本参照OWASPTOP10的相关要求制订，建议读者认真阅读其中具体内容，以加深对信息安全的理解。应用安全编码规范Session使用及处理Session修改：除了登录处理公共类，不允许在代码中修改Session中的用户识别信息，如user_id、user_email等，以及用户操作相关的的内容。(说明：可防止用户原始ID被覆盖，造成用户信息混乱)使用session变量：A：防止放入session的值覆盖已经存在的变量，要注意命名。B：不允许在session中存放大对象，否则，容易造成系统堆空间溢出。Cookie使用及处理Cookie中的关键业务数据必须进行加密。（建议不要将敏感数据放入cookie）URL参数HTML中通过hidden或者url中的参数来传递业务数据，隐藏字段已经是黑客攻击的最基本手段之一了，必须做到关键业务数据的加密和防止篡改。不能把关键业务数据直接通过hidden字段传递，用户完全可以通过重写源代码的方式修改业务数据发送请求从而绕过我们的安全规范。建议：可以通过session和request中的请求参数一致来处理、参数作加密、或者作摘要的方式。例如：有一个业务是通过类似下面这样一个链接就可以操作某项业，我们必须要对这个传值做一定的防伪，可以在请求之前就把这个user_id记录在session中，业务操作的时候做一下比对；或者接口参数中再加入一个参数sign=xxx作为摘要。（防篡改：可使用MD5对关键数据做摘要；数据保密：对敏感数据进行加密，算法有BlowfishDES3DES等。）一些页面的出现必须有前一页面出现才可以进入下一页面，禁止出现用户可以直接输入下一个页面URL就可以跨过前面页面的业务限制就直接操作。后门调试URL漏洞：开发人员常常建立一些后门并依靠调试来排除应用程序的故障。在开发过程中这样做可以，但这些安全漏洞经常被留在一些放在Internet上的最终应用中。一些常见的后门使用户不用口令就可以登录或者访问允许直接进行应用配置的特殊URL，日常测试的URL在产品上线后必须撤销。（所有可以在线上环境访问到的测试全部放到统一的测试模块）表单提交避免使用以GET方式提交表单。GET方式提交表单，表单中的参数会在浏览器地址栏中显示，而且浏览器不会控制表单提交的刷新操作。在浏览器中显示表单参数，容易造成恶意用户欺骗对电脑安全不熟悉的用户复制带参数的URL供他使用。对于不允许重复提交的表单，必须采用相关框架中的工具控制住表单的重复提交。建议所有的表单都做控制。不允许出现页面向自身重定向、或者多个页面间相互重定向的情况。如果控制不当，很容易造成系统宕机。不允许直接将用户的输入嵌入在页面模板中直接输出。例如，用户请求user/user_register.htm?registerFrom="><script>alert('xss');</script><"，在页面上直接输出$registerFrom，造成了跨站脚本攻击。疑问:这个要求对开发人员是否要求过高？研究统一的解决方案，如果可以统一解决，则开发人员可以避免自行处理这类繁琐的问题。(说明，目前这样的问题在系统中是大量存在的，统一解决方案势在必行)添加新的页面，必须同时添加权限控制规则Form提交数据，尽可能使用POST，而避免使用GET方法（容易被人模拟）AjaxAJAX很多时候把service层暴露出去，考虑如何将Service隐藏，来保证自身的业务安全性。接口签名外部接口必须要考虑签名，现在XXX通用的有HMAC，也可以在考虑使用MD5和DSA。特别是通过HTTP请求的外部重定向，只要用一些工具都可以看到重定向信息；通过客户端（例如网页嵌套flash）访问系统也需要签名。接口、类专人专管：重要的类、接口有专人管理。不要随便动其他人重要的类，也不要让别人随便动我们重要的类。把这些不能随便改的代码以及负责人进行统一管理。（建议SVN、CVS权限分开）信息验证信息公开发送问题：不能将用户信息通过邮件或者其他方式发送到第三方网站！信息双重验证机制：输入信息严格禁止仅仅通过客户端代码(例如javascript)验证，程序必须要再次验证一下。用户信息获取和归属权验证：用户身份信息只允许从session中获取，不允许通过输入参数获取；在进行业务处理之前，必须校验用户操作的数据是他所拥有的数据，而不是他人的数据。（说明：可防止诸如修改了其它人的领奖地址记录，进行积分兑换等问题）并发控制多用户操作的数据必须加并发控制，分布式应用不宜采用线程安全(synchronized)的方式，目前来说通过锁定数据库关键记录是一个不错的建议。数据资源是单行的情况下，如果涉及到资金操作，必须先锁定。例如：某用户的积分，某用户的余额等（对于非更新操作时，可通过表中增加uniqueindex）更新多条记录，或者为记录加锁需要使用一致的顺序，否则会造成死锁。单例对象或者静态Util必须是线程安全的，否则一旦共享对象被破坏，会产生严重的业务错误，或者系统不可用。说明：论坛系统中的一个日期静态Util类的线程安全问题曾造成论坛宕机；工作流平台的一个线程安全问题造成线程处理死循环，服务器load异常升高。（springbean默认为singleton）如果使用了线程上下文变量，必须确保线程上下文变量的设置操作与清除操作是配对的，要求以try{设置线程上下文变量}finally{清除线程上下文变量}的形式确保两者是配对的。DateFormat类是非线程安全的，类变量使用时会被破坏，每次使用都要构造。线程控制线程统一处理，不允许在应用中自行显式创建线程，需使用线程池。不允许在响应前台用户请求的处理中使用线程的sleep方法，或者wait/notify方法。服务前台请求的线程在系统中共享使用的宝贵资源，一旦被堵塞，很容易造成系统不可用。异步任务处理中，可以恰当地使用wait/notify等线程同步机制，但必须确保设计的可靠性与鲁棒性。业务边界及业务检测多表的修改或者更新必须要考虑事务机制无论web层是否检测，核心业务层必须有完善的检测机制。业务边界检测：关键判断必须有边界检查，例如我们剩余商品都是正整数，那它的边界检查就是X<=0或者X>0，X=0的事情，这样就是通过系统去保证业务正确性，如果有一个系统代码有问题就可能破坏业务的正确性。注：业务数字与自然数字的区别在于：业务数据具有很强的约束；例如不能为负值，不能超过某一额度，累计不能超过某一额度等数据库批量任务及事务分割：批量任务必须要考虑会不会重复执行。避免一个事务中进行大规模数据处理。批量任务处理时，必须恰当设计事务的大小，一般在500到1000次处理提交一次比较合理。事务长度过小，会造成性能低下；事务长度过大，会大量占用数据库回滚段（假设有一个每天晚上的认证提现，一次5万笔。最好拆成1000笔一批，做完一批提交一次。具体视业务情况而定）事务处理过程中，不允许执行可能产生线程阻塞的调用，如文件读写、未设置超时的网络访问等，否则一旦线程阻塞，会始终占用数据库连接资源，甚至可能占用数据库共享记录，造成其它业务处理无法继续（应用中在事务内生成一个随机数，结果API调用阻塞了，服务器就挂了。读取文件的时候,如果文件不可用,那么出现问题）大数据量查询限制：对于返回多记录的查询，如果业务上不能保证数据量的限制，必须在查询中加上数据量限制，否则查询结果集过大会造成数据库与服务器性能严重问题。例如：在登录时有一个IP地址黑名单检查操作，操作中查询出黑名单表中的所有IP地址记录，随着黑名单表大小的增加，这样的操作会产生很大的性能风险数据库的更新与删除语句中，尽量不使用动态条件子句，否则一旦出现SQL的所有动态条件子句都不满足的情况，可能出现更新或删除表中全部记录的情况，造成灾难性的后果。（如wheretrade_no=?），数据库有时也是不可信的。资金处理资金处理：资金计算与处理必须使用BigDecimal类，而不允许使用浮点数（如double/float等），否则会有精度问题。BigDecimal类的构造不允许使用浮点数，否则，由于Oracledriver的一个bug，会造成数据存储之后的值产生数量级的变化，产生严重的资金风险。DB2目前还不清楚，有待发现验证。正确的构造方法是使用整型数或者字符串来构造BigDecimal，如newBigDecimal(“10.00”)。数据数据安全检查：业务数据安全检查时，确保该业务数据是当前操作用户的，例如查找某一个订单时，使用订单ID、用户ID一起进行查找，同样更新某信息时一定也是依据多关键字进行更新。必须确保总帐数据和明细数据的一致性。对于具有平衡关系的业务数据，每次进行数据修改之前，进行平衡检查。必须考虑到发布期间可能出现的各种问题，如前台和交易核心的发布顺序问题远程调用远程调用中传输对象必须序列化。远程服务接口发生变更，包括webservice接口方法或者接口参数发生改变，或者消息体发生变化，必须测试新旧接口和数据的兼容性，如果兼容性存在问题，必须制定完善的发布计划解决这个问题。否则或者造成发布期间系统不可用，或者由于客户端与服务端对数据理解不一致引起业务处理错误。使用SSL进行通信：SSL是SecuritySocketLayer的缩写，技术上称为安全套接字，可以简单为加密通讯协议，使用SSL可以对通讯（包括电子邮件）内容进行高强度的加密，以防止黑客监听您的通讯内容甚至是用户密码。SSL协议指定了一种在应用程序协议（如HTTP、Telenet、NMTP和FTP等）和TCP/IP协议之间提供数据安全性分层的机制，它为TCP/IP连接提供数据加密、服务器认证、消息完整性以及可选的客户机认证。口令策略强制要求和验证用户设置的口令强度，如验证口令长度、身份包含数字、字符、特殊符合等允许用户更改自己的口令源码中不出现任何口令口令加密存储默认口令必须修改使用应用攻击防守策略SQL注入：例如：SELECT*FROMEMPWHERENAME=”DALEZHU”攻击者通常会使用特殊含义的字符或字符串利用这些漏洞例如在SQL中单引号是危险的字符；在Shell命令中；分号比较危险；通过对同一段元字符的多种编码方式及对同一种语言的多种实现方式，这个问题更加危险；使用正确的参数化SQL；SQL特殊字符转义为了防止他人使用特殊SQL字符破坏SQL的语句结构或植入恶意操作，必须在变量拼接到SQL语句之前对其中的特殊字符进行转义处理方法入参检测工具。JVM安全和java语言安全特性假如攻击者能在一个多用户共享JVM的环境中(例如TomcatHTTP服务器)利用以下函数的话,那么就能造成拒绝服务攻击:java.util.zip.Adler32().update();java.util.zip.Deflater().setDictionary();java.util.zip.CRC32().update();java.util.zip.Deflater().deflate();java.util.zip.CheckedOutputStream().write();java.util.zip.CheckedInputStream().read();尽可能的减小方法和字段的作用域范围.检查包私有(package-private)成员是否应该是私有(private),保护(protected)成员是否应该是包私有或私有等等。尽可能不使用非终态公共静态变量，因为没有机制来检测改变此变量的代码是否有适当的权限。注意语言特性(例如整数溢出(IntegerOverflow))注意使用序列化,注意使用特权代码将字段和方法定义到适当的可见性作用域日常维护发布检测规范不能调用未经过确认的接口，不能想当然的认为某一接口是为了实现什么功能。新加业务都有良好和规范的日志,可以避免很多问题，关键业务的日志必须是可以监控的。必须要考虑到服务重启或者机器宕机给业务带来的影响。（特别是任务服务器等）关键信息保密，关键保密信息不允许直接显示在页面上。例如用户的证件号或者银行信息等代码合并的时候禁止覆盖别人代码。代码合并时，不能只review有冲突的代码，还需要reviewSVN自动成功合并的代码，这是因为SVN能够判断同一行的修改冲突，但无法判断不同行的修改是否在逻辑上存在冲突。这样的问题潜在会造成严重后果。预发布一定需要开发人员自己确认发布内容，并且要跟踪日志。开发完代码后，开发人员交叉review开发人员要保证24小时开机对其他人员提供支持时，要全力配合（出现问题，共同承担责任）修改别人代码，必须要熟悉现有业务流程并通知测试，如果能找到相关开发负责人，最好和最近一次修改的开发工程师有效的沟通一下。修改别人代码时，记得对修改的代码添加注释，包括时间，原因，作者。修改一个bug或者function的时候都可能造成新的bug，因此在修改之前首先要考虑的是对其他业务的影响。发现可