JavaWeb安全开发规范

1、JavaWeb全开发规范1.目的保障WEB应用平台的安全性， 保证WEB应用系统的可用性、 完整性和保密性从安全角度规范WEB应用系统开发人员，能够让WEB应用开发者树立很强的安全意识，在开发过程中编写安全代码，进行安全编程。2 .范围本规范从应用安全开发角度出发，给出WEB应用系统安全开发的规范。供软通动力内部使用，适用各个WEB应用系统项目开发的工作。本规范定义了WEB应用系统安全开发和WEB编码安全相关的技术要求。3 .规范概述WEB应用系统为架构设计人员、开发人员提出了一系列复杂的安全问题。最安全、最有能力抵御攻击的Web应用程序是那些应用安全思想构建的应用程序。在设计初始阶段，应该使

2、用可靠的安全体系结构和设计方法，同时要结合考虑应用程序的部署以及企业的安全策略。如果不能做到这一点，将导致在现有基础结构上部署应用程序时，要不可避免地危及网站系统的安全性。本规范提供初步的安全体系结构和设计指南，并按照常见的应用程序漏洞类别进行组织。这些指南是WEB应用程序安全的重要方面，并且是经常发生错误的领域。4 .安全编码原则程序只实现你指定的功能永不要信任用户输入，对用户输入数据有效性检查必须考虑意外情况并进行处理不要试图在发现错误之后继续执行尽可能使用安全函数进行编程小心、认真、细致地编程5 .软件编码安全5.1. 输入校验WEB应用程序从各个方面获取输入，例如所有用户发送的，或者W

3、eb应用程序与用户交互往返的数据（用户提交的数据，cookie信息，查询字符串参数），以及后台数据（数据库、配置文件、其他数据来源）。所有输入的数据都会在某种情况下影响请求的处理。正确的输入验证是防御目前应用程序攻击的最有效方法之一。正确的输入验证是防止XSSSQL注入、缓冲区溢出和其他输入攻击的有效对策。以下做法可以增强Web应用程序的输入验证：假定所有输入都是恶意的开始输入校验时，首先假定所有输入都是恶意的，除非有证据表明它们并无恶意，无论输入是来自服务、共享文件、用户还是数据库，只有其来源不在可信任的范围之内，就应对输入进行验证。集中方法将输入验证策略作为应用程序的核心元素。考虑集中式验

4、证方法，例如通过使用共享库中的公共验证和筛选代码。这确保验证规则应用的一致性。此外还能减少开发工作量，并且有助于以后的维护工作。不要依赖客户端验证应使用服务器端代码执行其自身的验证，如果攻击者绕过客户端或者禁用客户端JavaScript脚本，后果如何？使用客户端验证可以减少客户端到服务器端的往返次数，但是不要依赖这种方法进行安全验证。注意标准化问题数据的标准形式是最标准、最简单的形式。标准化是指将数据转化为标准形式的过程。文件路径和URL尤其倾向于标准化问题。例如Zwww/public/testfile.jsp/www/public/./public/testfile.jsp/www/publ

5、ic/Z/testfile.jsp%2fwww%2fpublic%2f%2f%2ftestfile.jsp都表示同一个文件。通常，应设法避免让应用程序接受用户输入的文件名，以防止标准化问题。可以考虑其他方式，例如由应用程序为用户确定文件名。如果确实需要用户输入文件名，在作出安全决策 （如授予或拒绝特定文件的访问权限） 之前应确保这些文件名具有严格定义的形式。限制输入定义应用程序字段可以接受的数据输入，并强制应用该定义，拒绝一切有害数据。验证数据的类型、长度、格式和范围在适当的地方对输入数据使用强类型检查，可以使用参数化的存储过程来访问数据。应该检查字符串字段的长度，在许多情况下还应检查字符串的

6、格式是否正确，例如邮政编码、手机号码、身份证号码等都具有明确定义的格式，可以使用常规表达式进行验证。长度检查会加大攻击者实施其所喜欢的攻击方式的难度。拒绝已知的有害输入例如查询条件中禁止输入or1=1等。净化输入净化包括从删除用户输入字符串后面的空格到去除值等一切行为。常见的净化输入示例是使用URL编码或者HTML编码来包装数据，并将其作为文本而不是可执行脚本来处理。5.2. 输由编码输出编码是转换输入数据为输出格式的过程。输出格式不包含或者只是有选择性的包含允许的特殊字符。输出的重量有：1）支持HTML代码的输出2）不支持HTML代码的输出3）URL的输出4）页面内容的输入Js脚本的输出St

7、yle样式的输出Xml数据的输出8）服务空间的输出输出编码能有效的防止HTML注入（跨站脚本XSSC击）等，也能确保输出内容的完整性和正确性。对于支持HTML代码的输出，输出前要确保代码中不含有跨站攻击脚本才能输出。通过编写过滤函数来进行强制过滤。对于不支持HTML代码的输出，在输出到页面前要进行HTML编码。对于URL的输出要对URL进彳TUHEncode处理，要确保URL编码正确，不允许URL中输出引号。要确保内容输出中不包含特殊符号（单引号、双引号、/、。等）。5.3. SQL 注入所谓SQL注入就是通过把SQL命令插入到Web表单提交到页面的查询字符串， 最终达到欺骗服务器执行恶意的S

8、QL命令。通过提交参数构造巧妙的SQL语句，从而成功获取想要的数据。SQL注入往往是应用程序缺少对输入进行安全性检查所引起的。在对数据库进行查询与各类操作时，SQL语句中的参数应该以变量形式传输给服务器，不应该直接将参数的值拼接到SQL语句的文本中。参数的类型包括所有的数据类型，而不仅是字符串类型。参数值的来源包括但不限于：用户输入的数据、从数据库中读取的数据、从配置文件中读取的数据、从外部系统中获取的数据、其他程序逻辑计算得出的数据等等。SQL语句的执行位置包括但不限于：代码中的SQL语句，数据库的存储过程、触发器、定时器等。应用程序在处理用户非法请求触发后台应用程序的SQL错误时，应返回处

9、理后的错误页面提示，禁止直接抛出数据库SQL错误，如出现ORA-xxxxxx等。5.4. 恶意文件执行恶意文件执行是一种能够威胁任何网站形式的漏洞，只要攻击者在具有引入功能程序的参数中修改参数内容，WEB服务器便会引入恶意程序内容从而受到恶意文件执行漏洞攻击。 攻击者可以利用恶意文件执行漏洞进行攻击取得WEB服务器控制权，进行不法利益或者获取经济效益。解决方法：输入验证，验证上传文件名；检查上传文件类型和文件大小；禁止上传危险的文件类型（如：.jsp;.exe;.sh;.war;.jar等），只接受指定类型的文件（如zip、图片等）5.5. 不安全的直接对象引用所谓“不安全的直接对象引用”意指

10、一个已经授权的用户，通过修改访问时的一个参数，从而访问到原本其并没有得到授权的对象。例如攻击者发现他自己的参数是6065,即？acct=6065;他可以直接更改参数为6066,即？acct=6006;这样他就可以直接看到6066用户的信息。解决方法：检查访问。来自不受信源所使用的所有直接对象引用都必须包含访问控制检测，这样才能确保用户对要求的对象有访问权限。5.6. 信息泄露和错误处理不当应用程序常常产生错误信息并显示给使用者。很多时候错误信息是非常有用的攻击，因为它们揭示了实施细则或者有用的开发信息利用的漏洞。解决方法针对登陆尝试的攻击，可以使用相同的报错提醒，比如“输入的用户名或者密码错误

11、”；通过配置web.xml指定异常时跳转的页面，禁止直接显示异常信息堆栈。5.7. 限制 URL 访问失效攻击者通过伪造请求路径直接访问未授权的页面。例如攻击者发现自己的访问页面/user/getAccounts;他通过修改URL的形式请求/admin/getAccounts或者/manger/getAccounts来访问更多用户信息。解决方法：针对每个不公开的URL,必须限制能够访问他的授权用户，加强基于用户或者角色的访问控制；完全禁止访问未被授权的页面类型（如配置文件、日志文件、源文件等）；确保每个URL都被外部过滤器或者其他机制保护。6 .系统部署安全6.1. 限制主机上 WEB 系统启

12、动用户的权限应将WEB系统的启动用户的权限限制在最小范围内，禁止该用户访问其它不必要的路径（如:/etc/、/root）6.2. 隐藏后台调试信息WEB系统、数据库等报告的异常信息、调试信息不应该出现在页面上。6.3. 密码加密存储WEB系统中存储的密码应采用一定的加密算法，以密文形式存放。此处所指的密码包括但不限于：.配置文件中的主机、网络、数据库、邮箱的密码；.数据库中的用户资料密码加密算法的选择应根据实际需要，首选不对称加密算法，次选破解难度高的对称加密算法。6.4. 隐藏重要配置参数信息对于重要的配置参数信息，应采用必要的隐藏措施。此处所指的配置参数包括但不限于：.重要的用户名、密码；.重要设备的内网地址（如：数据库、存储设备）6.5. 隐藏日志文件不应将日志文件的路径设置在页面可达的位置，用户通过页面应该无法访问到系统产生的日志文件。6.6. 禁止不需要的 HTTP 方法在无特定的需求情况下，应只开放GET,HEAD,POS待安全的HTTP方法，禁用