通用安全编码规范.doc

1、通用安全编码规范1天翼电子商务有限公司信息技术部【】通用安全编码规范保密申明本文档版权由天翼电子商务有限公司信息技术部所有。未经天翼电子商务有限公司信息技术部书面许可，任何单位和个人不得以任何形式摘抄、复制本文档的部分或全部，并以任何形式传播通用安全编码规范2目 录1 目的 .42 范围 .43 规范概述 .44 安全编码的原则 .55 WEB 应用程序常见安全问题 55.1 跨站脚本攻击 65.1.1 定义 65.1.2 危害 65.1.3 解决方法 75.2 SQL 注入 .95.2.1 定义 95.2.2 危害 105.2.3 解决方法 105.3 恶意脚本执行 115.3.1 定义 1

2、15.3.2 危害 125.3.3 解决方法 125.4 文件上传漏洞 125.4.1 定义 125.4.2 危害 125.4.3 解决方案 125.5 传输敏感信息未使用安全通道 135.5.1 定义 135.5.2 危害 135.5.3 解决方案 135.6 信息泄漏和错误处理不当 135.6.1 定义 135.6.2 危害 145.6.3 解决方案 145.7 跨站请求伪造 155.7.1 定义 155.7.2 危害 155.7.3 代码示例 155.7.4 解决方案 165.8 访问控制缺陷 175.8.1 权限提升 175.8.2 不安全的直接对象引用 185.9 不安全的加密 20

3、5.9.1 定义 205.9.2 弱加密示例 215.9.3 解决方案 215.10 限制 URL 访问失效 215.10.1 定义 215.10.2 解决方案 225.11 Session 管理 .22通用安全编码规范35.11.1 Cookie http only flag 225.11.2 Cookie Secure flag 235.11.3 Session Expires 255.12 日志和监测 266 WEB 应用程序安全编码要点 266.1 SOCKET 网络安全编程要求 266.2 安全认证要求 276.2.1 图片验证码 276.2.2 短信验证码 286.3 加密方法及强

4、度要求 296.4 输入验证 316.4.1 什么是输入 316.4.2 如何处理输入 376.5 输出编码 426.5.1 输出编码的种类 426.5.2 输出编码的必要性 426.5.3 安全输出编码方式 427 翼支付常用 WEB 框架安全 .447.1 Struts2：Action 字段没有验证器（ Action Filed Without Validator） .447.1.1 定义 447.1.2 危害 447.2 Struts2：有重复的 Action 字段验证器（Duplicate Action Field Validators） 457.2.1 定义 457.2.2 危害 4

5、57.2.3 示例 457.3 Struts2：重复的验证文件（Duplicate Validation Files） .457.3.1 定义 457.3.2 危害 467.4 Struts2：重复的验证器（Duplicate Validators） 467.4.1 定义 467.4.2 危害 467.5 Struts2：未声明验证器（Undeclared Validator） .467.5.1 定义 467.5.2 危害 477.5.3 示例 477.6 Struts2：未经验证的 Action（Unvalidate Action） 477.6.1 定义 477.6.2 危害 477.7 S

6、truts2：验证文件无对应的 Action（Validation File Without Action） .477.7.1 定义 477.8 Struts2：验证器无 Action 域（Validator Without Action Field ） .487.8.1 定义 487.9 Spring MVC 的不良做法：请求参数绑定持久对象（Spring MVC Practices：Request Parameters Bound into Persisted Objects） .487.9.1 定义 487.9.2 危害 487.9.3 示例： 48通用安全编码规范48 附录 .498.

7、1 安全性测试_checklist 498.2 代码安全审计 checklist .491 目的为保障天翼电子商务有限公司（以下简称“翼支付”）支付平台的安全性，构建安全健壮的程序，结合翼支付 Web 安全遇到的问题以及启明星辰安全研究实验室在 Web 攻防及代码安全的理论和实践积累，特制定本规范，旨在为翼支付开发团队提供设计及编写应用程序时普遍应该遵循的原则。为充分理解本规范内容，请： 了解应用程序将会受到的威胁； 理解必须考虑的威胁； 在程序设计阶段考虑到这些威胁。2 范围本规范从应用安全开发的角度出发，结合翼支付平台系统的特点和常见的安全问题，给出支付平台应用系统安全开发的规范。供翼支付

8、平台应用系统开发部门内部使用，适用翼支付平台应用系统项目开发的工作。本规范定义了翼支付平台应用系统安全开发和编码安全相关的技术要求。本规范主要提供设计应用程序时应该遵循的一些指南和原则。在应用程序易受攻击的重要环节应采用系统的方法。将重点放在程序部署、输入验证、身份验证和授权、加密及数据敏感度、配置、会话、异常管理以及适当的审核和记录策略上，以确保应用程序的安全可靠性。3 规范概述当今电子商务时代，应用系统为架构设计人员、开发人员提出一系列复杂的安全问题。为应对这些安全问题，须要应用安全思想来构建应用程序。通用安全编码规范5在初始阶段，应该使用可靠的安全体系结构和设计方法，同时要结合考虑应用程

9、序的部署以及企业的安全策略。如果不能做到这一点，将导致在现有基础结构上部署应用程序时，导致危及应用系统的安全性。本规范提供初步的安全体系结构和设计指南，并按照翼支付平台常见的应用程序漏洞类别进行组织。这些指南是应用系统程序安全的重要方面，并且是经常发生错误的领域。4 安全编码的原则 程序只实现你指定的功能 永远不要信任用户的输入，对用户输入数据做有效性检查 必须考虑意外情况并进行处理 不要试图在发现错误之后继续执行 尽可能使用安全函数进行编程 小心、认真、细致地编程5 Web 应用程序常见安全问题下面的安全问题是根据应用程序漏洞类别描述的。实际经验表明，如果这些领域的设计存在薄弱环节，将会导致

10、安全漏洞。下表列出了漏洞的类别，每个类别都突出显示了由于设计不当可能会导致的潜在问题。漏洞类别 由于设计不当而引起的潜在问题输入验证 嵌入到查询字符串、表单字段、cookie 和 HTTP 头中的恶意字符串的攻击。这些攻击包括命令执行、跨站点脚本（XSS） 、SQL 输入和缓冲区溢出攻击。身份验证 标识欺骗、密码破解、特权提升和未经授权的访问。授权 访问保密数据或受限数据、篡改数据以及执行未经授权的操作。配置管理 对管理界面进行未经授权的访问、具有更新配置数据的能力以及对用户账户和账户配置文件进行未经授权的访问。敏感数据 泄漏保密信息以及篡改数据。会话管理 捕捉会话标识符，从而导致会话劫持及标

11、识欺骗。通用安全编码规范6加密 访问保密数据或者账户凭据，或者二者均能访问。参数操作 路径遍历攻击、命令执行以及绕过访问控制机制，从而导致信息泄漏、特权提升和拒绝服务。异常管理 拒绝服务和敏感的系统级详细信息的泄漏。审核和记录 不能发现入侵迹象、不能验证用户操作，以及在诊断问题时出现困难。5.1 跨站脚本攻击5.1.1定义什么是跨站脚本攻击：跨站脚本攻击（通常简写为 XSS）是最普通的 web 应用安全漏洞，当应用程序在发送给浏览器的页面中包含用户提供的数据，没有经过严格验证或转义，那么攻击者就有可能利用网站程序对用户输入过滤不严，输入可以显示在页面上对其他用户造成影响的 HTML 代码，从而

12、盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。5.1.2危害 敏感数据被获取（cookie 盗取） 网络钓鱼 获取 web 用户的网页内容 Session Riding（CSRF 攻击） 获取用户的键盘击键数据 Web 僵尸 XSS 蠕虫攻击者能在受害者浏览器中执行脚本以劫持用户会话、迫害网站、插入恶意内容、重定向用户、使用恶意软件劫持用户浏览器等等。入侵者便通过技术手段在某个页面里插入一个恶意 HTML 代码，例如记录论坛保存的用户信息（Cookie），由于 Cookie 保存了完整的用户名和密码资料，用户就会遭受安全损失。如这句简单的 javascript

13、脚本就能轻易获取用户信息：alert(document.cookie)，它会弹出一个包含用户信息的消息框。通用安全编码规范7入侵者运用脚本就能把用户信息发送到他们自己的记录页面中，稍作分析便获取了用户的敏感信息。跨站脚本攻击的危险，在如今 WEB 安全越来越得到重视，他的危险性也越来越大。有效防止跨站脚本攻击，是 WEB 程序是否安全的一个重要标准。5.1.3解决方法主要防御方式5.1.3.1 验证输入验证输入很简单，检查每个输入的有效性。这可能意味着很多东西，但在典型的和简单的情况下，这意味着检查输入类型和数据的长度。例如，如果你是从一个文本框接受一个标准的邮政编码，你会知道，唯一有效的类型

14、是一个数字（0-9） ，而长度应该是 6，不能多也不能少。并非所有的案例都如此简答，但很多是相似的。下图显示验证输入的架构。这里的关键是，一切都进行验证，所有的输入，这并不来自于应用程序（包括用户输入，请求头，Cookie，数据库数据） 。通用安全编码规范85.1.3.2 编码输出对于不支持 HTML 代码的地方，可用编码输出。如：Server.UrlEncode 等方法编码输出。优点：安全可靠。缺点：不支持 HTML 代码。对于验证输入的另一面就是编码输出。编码输出，是用来确保字符被视为数据，而不是作为 HTML 元字符被浏览器解析。这些技术定义一些特殊的“转义”字符。没有正确转义的数据它仍

15、然会在浏览器中正确解析。编码输出只是让浏览器知道数据是不是要被解析，达到攻击无法实现的目的。需要编码的部分：HTML 实体HTML 属性JavascriptCSSURL5.1.3.3 辅助防御方式防御手段一：iframe security=“restricted”保护级别：描述：通过设置 iframe security=“restricted”，能有效防止 iframe 类的攻击（对 IE 有效）。优点：有效防止 iframe 的攻击。防御手段二：HttpOnly保护级别：描述：设置 Cookie 的 HttpOnly 属性，有效地防止 Cookie 通过脚本泄密（IE6 SP1 以上、Fir

16、efox3）。优点：有效保护了用户的 Cookie 信息。应用举例：通用安全编码规范9系统中，所有登录验证的地方，验证成功后设置authCookie.HttpOnly=true,设置 Cookie 的 HttpOnly 属性，这些都应用于用户登录成功的地方。防御手段三：字符过滤保护级别：描述：通过函数进行过滤，能有效防止常见跨站脚本的跨站攻击。主要过滤常见恶意脚本代码，如：OnX 事件代码、Javascript、Vbscript 和 Style 中的 expression、behaviour、script、position 等。但过滤可能存在不完全的情况。建立自己的 XSS 攻击库，方便测试和

17、收集新的攻击方式，使过滤函数更加完善。优点：支持 HTML，有效防止大部分攻击代码。缺点：可能存在过滤不全的情况。5.2 SQL 注入5.2.1定义什么是 SQL 注入所谓 SQL 注入，就是通过把 SQL 命令插入到 Web 表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的 SQL 命令。通过递交参数构造巧妙的 SQL 语句，从而成功获取想要的数据。简单来说，注入往往是应用程序缺少对输入进行安全性检查所引起的，攻击者把一些包含指令的数据发送给解释器，解释器会把收到的数据转换成指令执行，注入漏洞十分普遍，通常能在 SQL 查询、程序参数等中出现。下图为 SQL 攻击原理图

18、：通用安全编码规范105.2.2危害注入能导致数据丢失或数据破坏、缺乏可审计性或是拒绝服务。注入漏洞有时甚至能导致完全接管主机，主要危害有以下几点： 绕过防火墙进行攻击 绕过 web 应用程序的验证过程 非法越权操作数据库内容 随意篡改网页内容 添加系统账户或数据库账户 上传和下载非法文件 本地溢出并获取系统最高权限 安装木马后门/僵尸网络5.2.3解决方法SQL 注入实例：String sqlString=“SELECT * FROM users WHERE fullname=”+form.getFul通用安全编码规范11lName()+”AND password=” +form.getPa

19、ssword()+ “”;正常：username=tony，password=123456SELECT * FROM users WHERE username=tony AND password=123456攻击：username=tony，password= OR 1=1SELECT *FROM users WHERE username=tony AND password= OR 1=1参数化查询预处理对于 JDBC 而言，SQL 注入攻击只对 Statement 有效，对PreparedStatement 是无效的，这是因为 PrepareStatement 不允许在不同的插入时间改变查询

20、的逻辑结构。如验证用户是否存在的 SQL 语句为：select count(*) from usertable where name=用户名 and pswd=密码如果在用户名字段中输入or 1=1 or 1=1或是在密码字段中输入 1 or 1=1将绕过验证，但这种手段只对 Statement 有效，对 PreparedStatement 无效，PreparedStatement 相对 Statement 有以下优点： 防注入攻击 多次运行速度快 防止数据库缓冲区溢出 代码的可读性可维护性好5.3 恶意脚本执行5.3.1定义恶意文件执行是一种能够威胁任何网站形式的漏洞，只要攻击者在具有引入（

21、include）功能程式的参数中修改参数内容，WEB 服务器便会引入恶意程序内容从而收到恶意文件执行漏洞攻击。5.3.2危害攻击者可利用恶意文件执行漏洞进行攻击取得 WEB 服务器控制权，进行通用安全编码规范12不法利益或获取经济利益。5.3.3解决方法 验证输入，验证上传文件名 检查上传文件的大小5.4 文件上传漏洞5.4.1定义Web 应用程序在处理用户上传的文件时，没有判断文件的扩展名是否在允许的范围内，就把文件保存在服务器上，导致恶意用户可以上传任意文件，甚至上传脚本木马到 web 服务器上，直接控制 web 服务器。5.4.2危害攻击者可利用文件上传功能，上传 Webshell 从而

22、控制整个主机系统。5.4.3解决方案 检查上传文件扩展名白名单，不属于白名单内，不允许上传。 上传文件的目录必须是 http 请求无法直接访问到的。如果需要访问的，必须上传到其他（和 web 服务器不同的）域名下，并设置该目录为不解析 jsp 等脚本语言的目录。 上传文件要保存的文件名和目录名由系统根据时间生成，不允许用户自定义。 图片上传，要通过处理（缩略图、水印等） ，无异常后才能保存到服务器。 上传文件需要做日志记录，请参照“Error Handing and Logging 章节” 。5.5 传输敏感信息未使用安全通道通用安全编码规范135.5.1定义对于未加密的敏感数据在网络上传输时

23、，需要使用安全的通道。否则应用程序将暴露身份验证或会话令牌。5.5.2危害 攻击者能够取得或者篡改机密的或是私有的信息； 攻击者通过这些私密信息的窃取从而进行进一步的攻击； 造成企业形象破损，用户满意度下降，甚至会有法律诉讼等。5.5.3解决方案 提供合理的保护机制； 对于敏感数据的传输，对所有连接都要使用 TLS； 在传输前对单个数据都要进行加密；（如 XML-Encryption） 在传输前对信息进行签名；（如 XML-Signature） 正确的使用这些机制； 使用标准的强加密算法； 合理管理密钥和证书； 在使用前验证 SSL 证书；5.6 信息泄漏和错误处理不当5.6.1定义应用程序没

24、有统一的异常处理页面，导致敏感信息泄漏，常常产生错误信息并显示给使用者。很多时候，这些错误信息是非常有利于攻击者发起攻击，因为他们揭示实施细节或者对利用漏洞有用的开发信息。示例：通用安全编码规范14看到此信息，攻击者可以做以下判断：a) 数据库是 oracleb) 查询语句的列数不正确根据这个判断，攻击者调整 get 请求的内容，最终达到获取数据库所有数据的目的。5.6.2危害 泄漏太多细节（如错误堆栈跟踪信息、SQL 语句等等） ； 登录失败后，通知用户是否用户 ID 或密码出错-登录失败可能是由于 ID或密码错误造成的。这为一个对关键资产发动暴力破解的攻击者提供重要信息。5.6.3解决方案

25、 通过 web.xml 配置文件实现，产生异常或者错误时跳转到统一的错误处理页面，避免泄漏过多敏感信息。 java.lang.Throwable /error.jsp 针对登录尝试的攻击，如果输入用户名或者是口令错误，可以使用相同的报错信息，比如都提示“输入用户名或密码错误！”。通用安全编码规范155.7 跨站请求伪造5.7.1定义Cross-Site Request Forgery（CSRF） ，跨站请求伪造攻击。攻击者在用户浏览网页时，利用页面元素（例如 img 的 src） ，强迫受害者的浏览器向 Web 应用程序发送一个改变用户信息的请求。5.7.2危害由于发生 CSRF 攻击后，攻击

26、者是强迫用户向服务器发送请求，所以会造成用户信息被迫修改，更严重者引发蠕虫攻击。CSRF 攻击可以从站外和站内发起。从站内发起 CSRF 攻击，需要利用网站本身的业务，比如“自定义头像”功能，恶意用户指定自己的头像 URL 是一个修改用户信息的链接，当其他已登录用户浏览恶意用户头像时，会自动向这个链接发送修改信息请求。从站外发送请求，则需要恶意用户在自己的服务器上，放一个自动提交修改个人信息的 html 页面，并把页面地址发给受害者用户，受害者用户打开时，会发起一个请求。如果恶意用户能够知道网站管理后台某项功能的 URL，就可以直接攻击管理员，强迫管理员执行恶意用户定义的操作。5.7.3代码示

27、例一个没有 CSRF 安全防御的代码如下：通用安全编码规范16代码中接收用户提交的参数“email,tel,realname” ，之后修改了该用户的数据，一旦接收到一个用户发来的请求，就执行修改操作。提交表单代码：当用户点提交时，就会触发修改操作。5.7.4解决方案要防御 CSRF 攻击，必须遵循一下三步：1、 在用户登陆时，设置一个 CSRF 的随机 TOKEN，同时种植在用户的cookie 中，当用户浏览器关闭、或用户再次登录、或退出时，清除 token。2、 在表单中，生成一个隐藏域，它的值就是 COOKIE 中随机 TOKEN。3、 表单被提交后，就可以在接收用户请求的 web 应用中

28、，判断表单中的TOKEN 值是否和用户 COOKIE 中的 TOKEN 值一致，如果不一致或没有这个值，就判断为 CSRF 攻击，同时记录攻击日志（日志内容见“Error Handing and Logging”章节） 。由于攻击者无法预测每一个用户登录时生成的那个随机 TOKEN 值，所以无通用安全编码规范17法伪造这个参数。示例：代码中$csrfToken.hiddenField 将会生成一个隐藏域，用于生成验证token，它将会作为表单的其中一个参数一起提交。5.8 访问控制缺陷5.8.1权限提升5.8.1.1 定义访问控制过程中身份验证有缺陷，导致用户越权访问信息。5.8.1.2 危害

29、由于 web 应用程序没有做权限控制，或仅仅在菜单上做了权限控制，导致的恶意用户只要猜测其他管理页面的 URL，就可以访问或控制其他角色拥有的数据或页面，达到权限提升目的。这个威胁可能导致普通用户变成管理员权限。5.8.1.3 代码示例一个仅仅做了菜单控制的代码：恶意用户，可以直接猜测“管理所有用户”的页面，通过 URL 访问，看通用安全编码规范18到管理员页面。5.8.1.4 解决方案在打开管理页面 URL 时，首先判断当前用户是否拥有该页面的权限，如果没有权限，就判定为“权限提升”攻击，同时记录安全日志。建议使用成熟的权限框架处理权限问题，比如 spring security。5.8.2不

30、安全的直接对象引用5.8.2.1 定义所谓“不安全的直接对象引用” ，指的是一个已经授权的用户，通过更改访问时的一个参数，从而访问到原本并没有得到授权的对象。Web 应用往往在生成 Web 页面时会用它的真实名字，且并不会对所有的对象访问时来检查用户权限，所以这就造成不安全的对象直接引用漏洞。我们看如下的一个示例，也许这样就更容易理解什么是不安全的对象直接引用。 攻击者发现他自己的参数是 6065，即?acct=6065; 他可以直接更改参数为 6066，即?acct=6066; 这样他就可以直接看到 6066 用户的账户信息。5.8.2.2 危害这种漏洞损害参数所引用的所有数据。除非名字空间

31、很稀疏，否则攻击者很容易访问该类型的所有数据。或者恶意用户可以删除或修改其他人数据。5.8.2.3 代码示例以下代码存在这个漏洞，web 应用在修改用户个人信息时，从从用户提交通用安全编码规范19的 request 参数（用户可控数据）中，获取了 userid，执行修改操作。修改用户个人信息页面：表单中，将用户的 userid 作为隐藏字段，提交给处理修改个人信息的应用。下面代码是修改个人信息的应用：这段代码是从 request 的参数列表中，获取 userid，也就是表单提交上来的userid，之后修改 userid 对应的用户数据。而表单中的 userid 是可以让用户随意修改的。通用安全

32、编码规范205.8.2.4 解决方案从用户的加密认证 cookie 中，获取当前用户的 id，并且需要在执行的SQL 语句中，加入当前用户 id 作为条件语句。由于是 web 应用控制的加密算法，所以恶意用户无法修改加密信息。示例代码：代码中通过 GetUseridFromCookie，从加密的 COOKIE 中获取了当前用户的 id，并加入到 SQL 语句中的 WHERE 条件中。5.9 不安全的加密5.9.1定义系统中涉及到敏感信息的数据直接明文存储，极不安全，需要加密存储。或者采用程序员自己编写的“简单算法”加密，一旦被人获取足够的“样本” ，将有可能被反向推测出解密算法，从而泄露重要信

33、息。一些低强度的密码算法，如 DES、RC2 等已经可以很容易的在短时间内被人所破解，其它一些容易被误用的“密码算法” ，如base64、escape、urlencode 等，其实并不是密码算法，只是简单的编码而已，通用安全编码规范21不能起到密码算法保护信息的作用。5.9.2弱加密示例线性加密算法，下面以“古典密码算法”为例：该算法对字符串做“Offset”位偏移，极易被破解，不宜采用。5.9.3解决方案详见6.3。5.10限制 URL 访问失效URL 中或者其他参数包含文件、目录、数据库记录或者关键字等参照物，导致接口处信息泄露。5.10.1 定义这个漏洞事实上也是与认证相关的，与我们前面

34、提到的不安全的直接对象引用也是类似的，不同在于这个漏洞是说系统已经对 URL 的访问做限制，但通用安全编码规范22这种限制却实际并没有生效。常见的错误是，我们在用户认证后只显示给用户认证过的页面和菜单选项，而实际上这些仅仅是表示层的访问控制而不能真正生效，攻击者能够很容易的就伪造请求直接访问未被授权的页面。我们举个例子来说明这个过程： 攻击者发现他自己的访问地址为/user/getAccounts; 他修改他的目录为/admin/getAccounts 或/manager/getAccounts; 这样攻击者就能够查看到更多的账户信息。5.10.2 解决方案对每个 URL，我们必须做三件事：

35、如果这个 URL 不是公开的，那么必须限制能够访问他的授权用户 加强基于用户或者角色的访问控制； 完全禁止访问未被授权的页面类型（如配置文件、日志文件、源文件等） 验证架构 在每一个层次都使用简单肯定的模型； 确保每一层都有一个访问机制。 验证实现 不要使用自动化分析工具； 确保每个 URL 都被外部过滤器或其他机制保护； 确保服务器的配置不允许对非授权页面的访问。5.11Session 管理5.11.1 Cookie http only flag5.11.1.1 定义Cookie http only，是设置 COOKIE 时，可以设置的一个属性，如果COOKIE 没有设置这个属性，该 COO

36、KIE 值可以被页面脚本读取。当攻击者发现一个 XSS 漏洞时，通常会写一段页面脚本，窃取用户的 COOKIE，为了增加攻击者的门槛，防止出现因为 XSS 漏洞导致大面积用户 COOKIE 被到，通用安全编码规范23应该在设置认证 COOKIE 时，增加这个属性。5.11.1.2 代码示例这段代码没有设置 http only 属性：response.setHeader(“SET-COOKIE“, “user=“ + request.getParameter(“cookie“);5.11.1.3 解决方案设置 cookie 时，加入属性即可：response.setHeader(“SET-COO

37、KIE“, “user=“ + request.getParameter(“cookie“) + “; HttpOnly“);下图可以看到 cookie 已经加入了 httponly 属性：5.11.1.4 常见问题 如何在 COOKIE 类中设置 httponly？ 目前的 jdk 版本只支持在 setHeader 时，设置 httponly。 Httponly 已经可以防止用户 COOKIE 被窃取，还需要做 XSS 防御吗？ 这个 flag 只能增加攻击者的难度，不能达到完全防御 xss 攻击。5.11.2 Cookie Secure flag5.11.2.1 定义Cookie Secu

38、re，是设置 COOKIE 时，可以设置的一个属性，设置了这个属性后，只有在 https 访问时，浏览器才会发送该 COOKIE。通用安全编码规范24浏览器默认只要使用 http 请求一个站点，就会发送明文 COOKIE，如果网络中有监控，可能被截获。如果 Web 应用网站全站是 https 的，可以设置 COOKIE 加上 Secure 属性，这样浏览器就只会在 https 访问时，发送 cookie。攻击者即使窃听网络，也无法获取用户明文 cookie。5.11.2.2 代码示例这段代码没有设置 Secure 属性response.setHeader(“SET-COOKIE“, “user

39、=“+ request.getParameter(“cookie“) + “; HttpOnly“);进行网络监听，可以看到下图是没有设置 Secure 属性的 COOKIE 发送的数据包：5.11.2.3 解决方案在设置认证 COOKIE 时，加入 Secure：response.setHeader(“SET-COOKIE“, “user=“ + request.getParameter(“cookie“) + “; HttpOnly ; Secure “);再次访问 http 网站，抓数据包可以看到，已经不再发送这个 COOKIE 了。通用安全编码规范255.11.3 Session Ex

40、pires5.11.3.1 定义Session 有效期安全攻击。由于 Session 没有在 Web 应用中设置强制超时时间，攻击者一旦曾经获取过用户的 Session，就额可以一直使用。5.11.3.2 代码示例这段代码没有在服务器中设置强制超时时间。response.setHeader(“SET-COOKIE“, “user=“+ request.getParameter(“cookie“) + “; HttpOnly ; Secure “);5.11.3.3 解决方案在设置认证 cookie 中，加入两个时间，一个是 “即使一直在活动，也要失效”的时间，一个是“长时间不活动的失效时间”

41、。并在 Web 应用中，首先判断两个时间是否已经超时，再执行其他操作。/ 判断会员的 cookie 是否过期通用安全编码规范265.12日志和监测做好系统的日志监测，记录好后台管理操作和异常情况，有利于监测系统未知漏洞，通过操作日志，还能找出系统出错或对某些重要操作的管理员、操作时间、IP 等信息。有效地预防，检测，增强系统的安全性。对重要的日志都进行记录，如：登陆日志、系统错误日志、数据库错误日志等。6 Web 应用程序安全编码要点6.1SOCKET 网络安全编程要求 在 socket 函数调用时，明确参数中绑定的端口、IP 地址和网卡接口。Windows 环境下，在遇到多个网卡的情况时，需

42、要通过注册表来获得网卡接口和 IP 地址的信息，包括 Windows NT 和 windows 2000。 判断连接的合法身份。即，为防止恶意的连接以及可能是无效的连接，建议在 socket 连接期间，判断连接的对端是否是合法的真正的连接。 对于 UDP 连接，可以获得连接对方的 IP 地址和端口，从而可以判断对通用安全编码规范27方的有效性和合法性；对于 TCP 连接，由于每次连接需要三次握手，而且还有超时机制，存在两种方式来控制。 对于 TCP 连接，需要尽量在三次握手完成前完成判断，同时防止端口扫描的攻击。 尽可能确保 socket 应用能通过合理设置的防火墙。 在可能的情况下，尽量减少

43、 socket 连接数目。 尽量不能使用回拨的技术。 尽量采用有连接状态的协议，例如 TCP 协议。由于防火墙一般采取禁止一切的策略，对于 UDP 协议比较难以设置。 在一个应用程序中，尽量使用同一种协议，不能使用多种协议。 尽量将客户端和服务器端的端口做成可以配置，不能硬编码在程序中。6.2安全认证要求为防止采用单一用户名、口令登陆被暴力破解，部分页面被重复提交数据造成灌水、刷票等，网站应考虑双因素或多因素认证。目前，普遍采用图片验证码、短信验证码，加入时间等随机因素，进行双因素认证。6.2.1 图片验证码在网站登录、发表评论时，往往都需要用户输入验证码。图片验证机制就是指根据一定的随机数产

44、生算法来产生的一串随机数字或符号，并加入一些干扰像素最终生成相应的用于验证的图片。只有当用户肉眼识别出其中的验证码信息，输入表单并提交网站验证，验证成功后才能使用该网站提供的某项特定功能。验证码的主要用途是用于防止有人利用机器人自动批量注册、对特定的注册用户用特定的程序暴力破解。一般来讲，自动注册或者表单自动填写程序不能有效识别图片验证码中的数字或字符，因此从一定程度上实通用安全编码规范28现了阻挡攻击的作用。在某支付公司某应用系统中用户登录表单无验证码验证，存在暴力破解的风险。建议页面增加图片验证码，以防止帐户被暴力破解。同时因为图片验证码也存在被绕过的可能，为解决该问题，在增加验证码的同时

45、，须要在服务端进一步做判断，比如每分钟客户端尝试向服务器提交的验证码次数不能超过三次，如果超过需要在下一分钟再提交服务器进行验证。6.2.2 短信验证码在网站安全架构设计中，短信验证码提供了有效的用户辅助身份验证。但是，为了防止短信验证码被绕过，应注意，用户手机号应包含在服务器端，系统在调用用户手机号是只能从服务器端获得，不得提供手机号的接口，防止被恶意用户篡改。通用安全编码规范29例如，下图是某支付公司支付页面，点击“获取验证码”时，获取的请求中包含了手机号码参数，可被篡改，且无校验，导致可将验证码发送到任意手机上，绕过手机短信的校验。6.3加密方法及强度要求 禁止使用自己编写的密码算法。

46、不要将编码(如 Base64)和密码算法混为一谈，前者不是密码算法。 不要使用低强度的密码算法，如 DES、RC2 等，必须采用符合业内安全强度标准的密码算法，见下表：对于存储在数据库或日志中的敏感数据，建议采用安全的 Hash 算法。通用安全编码规范301） 存储策略基于安全哈希算法加密存储用户的口令安全哈希算法的存储方式已经得到广泛使用。哈希算法可用于保障信息的完整性、抗抵赖性、属于单向算法，即便哈希的结果被截获，对方也是无法还原出明文的。如果在哈希的过程中加入盐值，那就更好了，可以起到混淆的作用。也有加密方案提到通过非对称加密算法加密后存储，比如 RSA，但是这种方法使用起来比较麻烦，另

47、外还需要考虑系统后台的密钥管理，一旦密钥泄漏，后果非常严重。强对称加密算法如 3DES 也存在类似问题。所以依然推荐采用哈希算法。2） Hash 算法的选择哈希算法有多种，常见的有 MD5 和 SHA 系列。现在有个叫彩虹表的东西，穷举某个哈希值所对应的明文，导致 MD5 和 SHA-1 已经不再安全。而 SHA-256 或者 SHA-512 目前还是比较安全的，而且计算消耗的资源不会比 MD5 或SHA-1 差太多。从代码实现的角度考虑，各算法的参数都一样，返回值类型也一样，只是函数名和返回值长度变了，所以如果已经使用了 MD5 或 SHA-1，可以很方便切换到更安全的算法上。3） 添加盐值以盐值为用户名，算法为 SHA-256 为例，用户最终存储在后台的口令就可以为 SHA256（“用户名+口令” ） 。而登录的时候，有两种验证策略：可在客户端计算出 SHA256（“输入的用户名+输入的口令” ） ，将计算的结果明文传输给服务端，由服务端比较该值与后台数据库中存储的是否相同。将输入的用户名，口令加密传输到服务端，在服务端计算 SHA256（“输入的用户名+输入的口令” ） ，再与数据库存储的内容做比较。加密传输现在比较流行的方法是 HTTPS。可以看到，服务端不知道用户的口令明文，所以即使数据库被攻破，也不会泄漏用户的口令。