通用安全编码规范.docx

通用安全编码规范天翼电子商务有限公司信息技术部【】通用安全编码规范保密申明本文档版权由天翼电子商务有限公司信息技术部所有。未经天翼电子商务有限公司信息技术部书面许可，任何单位和个人不得以任何形式摘抄、复制本文档的部分或全部，并以任何形式传播目 录1目的42范围43规范概述44安全编码的原则55WEB应用程序常见安全问题55.1跨站脚本攻击65.1.1定义65.1.2危害65.1.3解决方法75.2SQL注入95.2.1定义95.2.2危害105.2.3解决方法105.3恶意脚本执行115.3.1定义115.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不安全的加密205.9.1定义205.9.2弱加密示例215.9.3解决方案215.10限制URL访问失效215.10.1定义215.10.2解决方案225.11Session管理225.11.1Cookie http only flag225.11.2Cookie Secure flag235.11.3Session Expires255.12日志和监测266WEB应用程序安全编码要点266.1SOCKET网络安全编程要求266.2安全认证要求276.2.1图片验证码276.2.2短信验证码286.3加密方法及强度要求296.4输入验证316.4.1什么是输入316.4.2如何处理输入376.5输出编码426.5.1输出编码的种类426.5.2输出编码的必要性426.5.3安全输出编码方式427翼支付常用WEB框架安全447.1Struts2：Action字段没有验证器（Action Filed Without Validator）447.1.1定义447.1.2危害447.2Struts2：有重复的Action字段验证器（Duplicate Action Field Validators）457.2.1定义457.2.2危害457.2.3示例457.3Struts2：重复的验证文件（Duplicate Validation Files）457.3.1定义457.3.2危害467.4Struts2：重复的验证器（Duplicate Validators）467.4.1定义467.4.2危害467.5Struts2：未声明验证器（Undeclared Validator）467.5.1定义467.5.2危害477.5.3示例477.6Struts2：未经验证的Action（Unvalidate Action）477.6.1定义477.6.2危害477.7Struts2：验证文件无对应的Action（Validation File Without Action）477.7.1定义477.8Struts2：验证器无Action 域（Validator Without Action Field）487.8.1定义487.9Spring MVC的不良做法：请求参数绑定持久对象（Spring MVC Practices：Request Parameters Bound into Persisted Objects）487.9.1定义487.9.2危害487.9.3示例：488附录498.1安全性测试_checklist498.2代码安全审计checklist491 目的为保障天翼电子商务有限公司（以下简称“翼支付”）支付平台的安全性，构建安全健壮的程序，结合翼支付Web安全遇到的问题以及启明星辰安全研究实验室在Web攻防及代码安全的理论和实践积累，特制定本规范，旨在为翼支付开发团队提供设计及编写应用程序时普遍应该遵循的原则。为充分理解本规范内容，请： 了解应用程序将会受到的威胁； 理解必须考虑的威胁； 在程序设计阶段考虑到这些威胁。2 范围本规范从应用安全开发的角度出发，结合翼支付平台系统的特点和常见的安全问题，给出支付平台应用系统安全开发的规范。供翼支付平台应用系统开发部门内部使用，适用翼支付平台应用系统项目开发的工作。本规范定义了翼支付平台应用系统安全开发和编码安全相关的技术要求。本规范主要提供设计应用程序时应该遵循的一些指南和原则。在应用程序易受攻击的重要环节应采用系统的方法。将重点放在程序部署、输入验证、身份验证和授权、加密及数据敏感度、配置、会话、异常管理以及适当的审核和记录策略上，以确保应用程序的安全可靠性。3 规范概述当今电子商务时代，应用系统为架构设计人员、开发人员提出一系列复杂的安全问题。为应对这些安全问题，须要应用安全思想来构建应用程序。在初始阶段，应该使用可靠的安全体系结构和设计方法，同时要结合考虑应用程序的部署以及企业的安全策略。如果不能做到这一点，将导致在现有基础结构上部署应用程序时，导致危及应用系统的安全性。本规范提供初步的安全体系结构和设计指南，并按照翼支付平台常见的应用程序漏洞类别进行组织。这些指南是应用系统程序安全的重要方面，并且是经常发生错误的领域。4 安全编码的原则 程序只实现你指定的功能 永远不要信任用户的输入，对用户输入数据做有效性检查 必须考虑意外情况并进行处理 不要试图在发现错误之后继续执行 尽可能使用安全函数进行编程 小心、认真、细致地编程5 Web应用程序常见安全问题下面的安全问题是根据应用程序漏洞类别描述的。实际经验表明，如果这些领域的设计存在薄弱环节，将会导致安全漏洞。下表列出了漏洞的类别，每个类别都突出显示了由于设计不当可能会导致的潜在问题。漏洞类别由于设计不当而引起的潜在问题输入验证嵌入到查询字符串、表单字段、cookie和HTTP头中的恶意字符串的攻击。这些攻击包括命令执行、跨站点脚本（XSS）、SQL输入和缓冲区溢出攻击。身份验证标识欺骗、密码破解、特权提升和未经授权的访问。授权访问保密数据或受限数据、篡改数据以及执行未经授权的操作。配置管理对管理界面进行未经授权的访问、具有更新配置数据的能力以及对用户账户和账户配置文件进行未经授权的访问。敏感数据泄漏保密信息以及篡改数据。会话管理捕捉会话标识符，从而导致会话劫持及标识欺骗。加密访问保密数据或者账户凭据，或者二者均能访问。参数操作路径遍历攻击、命令执行以及绕过访问控制机制，从而导致信息泄漏、特权提升和拒绝服务。异常管理拒绝服务和敏感的系统级详细信息的泄漏。审核和记录不能发现入侵迹象、不能验证用户操作，以及在诊断问题时出现困难。5.1 跨站脚本攻击5.1.1 定义什么是跨站脚本攻击：跨站脚本攻击（通常简写为XSS）是最普通的web应用安全漏洞，当应用程序在发送给浏览器的页面中包含用户提供的数据，没有经过严格验证或转义，那么攻击者就有可能利用网站程序对用户输入过滤不严，输入可以显示在页面上对其他用户造成影响的HTML代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。5.1.2 危害 敏感数据被获取（cookie盗取） 网络钓鱼 获取web用户的网页内容 Session Riding（CSRF攻击） 获取用户的键盘击键数据 Web僵尸 XSS蠕虫攻击者能在受害者浏览器中执行脚本以劫持用户会话、迫害网站、插入恶意内容、重定向用户、使用恶意软件劫持用户浏览器等等。入侵者便通过技术手段在某个页面里插入一个恶意HTML代码，例如记录论坛保存的用户信息（Cookie），由于Cookie保存了完整的用户名和密码资料，用户就会遭受安全损失。如这句简单的javascript脚本就能轻易获取用户信息：alert(document.cookie)，它会弹出一个包含用户信息的消息框。入侵者运用脚本就能把用户信息发送到他们自己的记录页面中，稍作分析便获取了用户的敏感信息。跨站脚本攻击的危险，在如今WEB安全越来越得到重视，他的危险性也越来越大。有效防止跨站脚本攻击，是WEB程序是否安全的一个重要标准。5.1.3 解决方法主要防御方式 验证输入验证输入很简单，检查每个输入的有效性。这可能意味着很多东西，但在典型的和简单的情况下，这意味着检查输入类型和数据的长度。例如，如果你是从一个文本框接受一个标准的邮政编码，你会知道，唯一有效的类型是一个数字（0-9），而长度应该是6，不能多也不能少。并非所有的案例都如此简答，但很多是相似的。下图显示验证输入的架构。这里的关键是，一切都进行验证，所有的输入，这并不来自于应用程序（包括用户输入，请求头，Cookie，数据库数据）。 编码输出对于不支持HTML代码的地方，可用编码输出。如：Server.UrlEncode等方法编码输出。优点：安全可靠。缺点：不支持HTML代码。对于验证输入的另一面就是编码输出。编码输出，是用来确保字符被视为数据，而不是作为HTML元字符被浏览器解析。这些技术定义一些特殊的“转义”字符。没有正确转义的数据它仍然会在浏览器中正确解析。编码输出只是让浏览器知道数据是不是要被解析，达到攻击无法实现的目的。需要编码的部分：HTML实体HTML属性JavascriptCSSURL 辅助防御方式防御手段一：iframe security=“restricted”保护级别：描述：通过设置iframe security=“restricted”，能有效防止iframe类的攻击（对IE有效）。优点：有效防止iframe的攻击。防御手段二：HttpOnly保护级别：描述：设置Cookie的HttpOnly属性，有效地防止Cookie通过脚本泄密（IE6 SP1以上、Firefox3）。优点：有效保护了用户的Cookie信息。应用举例：系统中，所有登录验证的地方，验证成功后设置authCookie.HttpOnly=true,设置Cookie的HttpOnly属性，这些都应用于用户登录成功的地方。防御手段三：字符过滤保护级别：描述：通过函数进行过滤，能有效防止常见跨站脚本的跨站攻击。主要过滤常见恶意脚本代码，如：OnX事件代码、Javascript、Vbscript和Style中的expression、behaviour、script、position等。但过滤可能存在不完全的情况。建立自己的XSS攻击库，方便测试和收集新的攻击方式，使过滤函数更加完善。优点：支持HTML，有效防止大部分攻击代码。缺点：可能存在过滤不全的情况。5.2 SQL注入5.2.1 定义什么是SQL注入所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。通过递交参数构造巧妙的SQL语句，从而成功获取想要的数据。简单来说，注入往往是应用程序缺少对输入进行安全性检查所引起的，攻击者把一些包含指令的数据发送给解释器，解释器会把收到的数据转换成指令执行，注入漏洞十分普遍，通常能在SQL查询、程序参数等中出现。下图为SQL攻击原理图：5.2.2 危害注入能导致数据丢失或数据破坏、缺乏可审计性或是拒绝服务。注入漏洞有时甚至能导致完全接管主机，主要危害有以下几点： 绕过防火墙进行攻击 绕过web应用程序的验证过程 非法越权操作数据库内容 随意篡改网页内容 添加系统账户或数据库账户 上传和下载非法文件 本地溢出并获取系统最高权限 安装木马后门/僵尸网络5.2.3 解决方法SQL注入实例：String sqlString=“SELECT * FROM users WHERE fullname=”+form.getFullName()+”AND password=” +form.getPassword()+ “”;正常：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不允许在不同的插入时间改变查询的逻辑结构。如验证用户是否存在的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 定义恶意文件执行是一种能够威胁任何网站形式的漏洞，只要攻击者在具有引入（include）功能程式的参数中修改参数内容，WEB服务器便会引入恶意程序内容从而收到恶意文件执行漏洞攻击。5.3.2 危害攻击者可利用恶意文件执行漏洞进行攻击取得WEB服务器控制权，进行不法利益或获取经济利益。5.3.3 解决方法 验证输入，验证上传文件名 检查上传文件的大小5.4 文件上传漏洞5.4.1 定义Web应用程序在处理用户上传的文件时，没有判断文件的扩展名是否在允许的范围内，就把文件保存在服务器上，导致恶意用户可以上传任意文件，甚至上传脚本木马到web服务器上，直接控制web服务器。5.4.2 危害攻击者可利用文件上传功能，上传Webshell从而控制整个主机系统。5.4.3 解决方案 检查上传文件扩展名白名单，不属于白名单内，不允许上传。 上传文件的目录必须是http请求无法直接访问到的。如果需要访问的，必须上传到其他（和web服务器不同的）域名下，并设置该目录为不解析jsp等脚本语言的目录。 上传文件要保存的文件名和目录名由系统根据时间生成，不允许用户自定义。 图片上传，要通过处理（缩略图、水印等），无异常后才能保存到服务器。 上传文件需要做日志记录，请参照“Error Handing and Logging章节”。5.5 传输敏感信息未使用安全通道5.5.1 定义对于未加密的敏感数据在网络上传输时，需要使用安全的通道。否则应用程序将暴露身份验证或会话令牌。5.5.2 危害 攻击者能够取得或者篡改机密的或是私有的信息； 攻击者通过这些私密信息的窃取从而进行进一步的攻击； 造成企业形象破损，用户满意度下降，甚至会有法律诉讼等。5.5.3 解决方案 提供合理的保护机制； 对于敏感数据的传输，对所有连接都要使用TLS； 在传输前对单个数据都要进行加密；（如XML-Encryption） 在传输前对信息进行签名；（如XML-Signature） 正确的使用这些机制； 使用标准的强加密算法； 合理管理密钥和证书； 在使用前验证SSL证书；5.6 信息泄漏和错误处理不当5.6.1 定义应用程序没有统一的异常处理页面，导致敏感信息泄漏，常常产生错误信息并显示给使用者。很多时候，这些错误信息是非常有利于攻击者发起攻击，因为他们揭示实施细节或者对利用漏洞有用的开发信息。示例：看到此信息，攻击者可以做以下判断：a) 数据库是oracleb) 查询语句的列数不正确根据这个判断，攻击者调整get请求的内容，最终达到获取数据库所有数据的目的。5.6.2 危害 泄漏太多细节（如错误堆栈跟踪信息、SQL语句等等）； 登录失败后，通知用户是否用户ID或密码出错-登录失败可能是由于ID或密码错误造成的。这为一个对关键资产发动暴力破解的攻击者提供重要信息。5.6.3 解决方案 通过web.xml配置文件实现，产生异常或者错误时跳转到统一的错误处理页面，避免泄漏过多敏感信息。n n java.lang.Throwablen /error.jspn 针对登录尝试的攻击，如果输入用户名或者是口令错误，可以使用相同的报错信息，比如都提示“输入用户名或密码错误！”。5.7 跨站请求伪造5.7.1 定义Cross-Site Request Forgery（CSRF），跨站请求伪造攻击。攻击者在用户浏览网页时，利用页面元素（例如img的src），强迫受害者的浏览器向Web应用程序发送一个改变用户信息的请求。5.7.2 危害由于发生CSRF攻击后，攻击者是强迫用户向服务器发送请求，所以会造成用户信息被迫修改，更严重者引发蠕虫攻击。CSRF攻击可以从站外和站内发起。从站内发起CSRF攻击，需要利用网站本身的业务，比如“自定义头像”功能，恶意用户指定自己的头像URL是一个修改用户信息的链接，当其他已登录用户浏览恶意用户头像时，会自动向这个链接发送修改信息请求。从站外发送请求，则需要恶意用户在自己的服务器上，放一个自动提交修改个人信息的html页面，并把页面地址发给受害者用户，受害者用户打开时，会发起一个请求。如果恶意用户能够知道网站管理后台某项功能的URL，就可以直接攻击管理员，强迫管理员执行恶意用户定义的操作。5.7.3 代码示例一个没有CSRF安全防御的代码如下：代码中接收用户提交的参数“email,tel,realname”，之后修改了该用户的数据，一旦接收到一个用户发来的请求，就执行修改操作。提交表单代码：当用户点提交时，就会触发修改操作。5.7.4 解决方案要防御CSRF攻击，必须遵循一下三步：1、在用户登陆时，设置一个CSRF的随机TOKEN，同时种植在用户的cookie中，当用户浏览器关闭、或用户再次登录、或退出时，清除token。2、在表单中，生成一个隐藏域，它的值就是COOKIE中随机TOKEN。3、表单被提交后，就可以在接收用户请求的web应用中，判断表单中的TOKEN值是否和用户COOKIE中的TOKEN值一致，如果不一致或没有这个值，就判断为CSRF攻击，同时记录攻击日志（日志内容见“Error Handing and Logging”章节）。由于攻击者无法预测每一个用户登录时生成的那个随机TOKEN值，所以无法伪造这个参数。示例：代码中$csrfToken.hiddenField将会生成一个隐藏域，用于生成验证token，它将会作为表单的其中一个参数一起提交。5.8 访问控制缺陷5.8.1 权限提升 定义访问控制过程中身份验证有缺陷，导致用户越权访问信息。 危害由于web应用程序没有做权限控制，或仅仅在菜单上做了权限控制，导致的恶意用户只要猜测其他管理页面的URL，就可以访问或控制其他角色拥有的数据或页面，达到权限提升目的。这个威胁可能导致普通用户变成管理员权限。 代码示例一个仅仅做了菜单控制的代码：恶意用户，可以直接猜测“管理所有用户”的页面，通过URL访问，看到管理员页面。 解决方案在打开管理页面URL时，首先判断当前用户是否拥有该页面的权限，如果没有权限，就判定为“权限提升”攻击，同时记录安全日志。建议使用成熟的权限框架处理权限问题，比如spring security。5.8.2 不安全的直接对象引用 定义所谓“不安全的直接对象引用”，指的是一个已经授权的用户，通过更改访问时的一个参数，从而访问到原本并没有得到授权的对象。Web应用往往在生成Web页面时会用它的真实名字，且并不会对所有的对象访问时来检查用户权限，所以这就造成不安全的对象直接引用漏洞。我们看如下的一个示例，也许这样就更容易理解什么是不安全的对象直接引用。 攻击者发现他自己的参数是6065，即?acct=6065; 他可以直接更改参数为6066，即?acct=6066; 这样他就可以直接看到6066用户的账户信息。 危害这种漏洞损害参数所引用的所有数据。除非名字空间很稀疏，否则攻击者很容易访问该类型的所有数据。或者恶意用户可以删除或修改其他人数据。 代码示例以下代码存在这个漏洞，web应用在修改用户个人信息时，从从用户提交的request参数（用户可控数据）中，获取了userid，执行修改操作。修改用户个人信息页面：表单中，将用户的userid作为隐藏字段，提交给处理修改个人信息的应用。下面代码是修改个人信息的应用：这段代码是从request的参数列表中，获取userid，也就是表单提交上来的userid，之后修改userid对应的用户数据。而表单中的userid是可以让用户随意修改的。 解决方案从用户的加密认证cookie中，获取当前用户的id，并且需要在执行的SQL语句中，加入当前用户id作为条件语句。由于是web应用控制的加密算法，所以恶意用户无法修改加密信息。示例代码：代码中通过GetUseridFromCookie，从加密的COOKIE中获取了当前用户的id，并加入到SQL语句中的WHERE条件中。5.9 不安全的加密5.9.1 定义系统中涉及到敏感信息的数据直接明文存储，极不安全，需要加密存储。或者采用程序员自己编写的“简单算法”加密，一旦被人获取足够的“样本”，将有可能被反向推测出解密算法，从而泄露重要信息。一些低强度的密码算法，如DES、RC2等已经可以很容易的在短时间内被人所破解，其它一些容易被误用的“密码算法”，如base64、escape、urlencode等，其实并不是密码算法，只是简单的编码而已，不能起到密码算法保护信息的作用。5.9.2 弱加密示例线性加密算法，下面以“古典密码算法”为例：该算法对字符串做“Offset”位偏移，极易被破解，不宜采用。5.9.3 解决方案详见6.3。5.10 限制URL访问失效URL中或者其他参数包含文件、目录、数据库记录或者关键字等参照物，导致接口处信息泄露。5.10.1 定义这个漏洞事实上也是与认证相关的，与我们前面提到的不安全的直接对象引用也是类似的，不同在于这个漏洞是说系统已经对URL的访问做限制，但这种限制却实际并没有生效。常见的错误是，我们在用户认证后只显示给用户认证过的页面和菜单选项，而实际上这些仅仅是表示层的访问控制而不能真正生效，攻击者能够很容易的就伪造请求直接访问未被授权的页面。我们举个例子来说明这个过程： 攻击者发现他自己的访问地址为/user/getAccounts; 他修改他的目录为/admin/getAccounts或/manager/getAccounts; 这样攻击者就能够查看到更多的账户信息。5.10.2 解决方案对每个URL，我们必须做三件事： 如果这个URL不是公开的，那么必须限制能够访问他的授权用户l 加强基于用户或者角色的访问控制；l 完全禁止访问未被授权的页面类型（如配置文件、日志文件、源文件等） 验证架构l 在每一个层次都使用简单肯定的模型；l 确保每一层都有一个访问机制。 验证实现l 不要使用自动化分析工具；l 确保每个URL都被外部过滤器或其他机制保护；l 确保服务器的配置不允许对非授权页面的访问。5.11 Session管理5.11.1 Cookie http only flag 定义Cookie http only，是设置COOKIE时，可以设置的一个属性，如果COOKIE没有设置这个属性，该COOKIE值可以被页面脚本读取。当攻击者发现一个XSS漏洞时，通常会写一段页面脚本，窃取用户的COOKIE，为了增加攻击者的门槛，防止出现因为XSS漏洞导致大面积用户COOKIE被到，应该在设置认证COOKIE时，增加这个属性。 代码示例这段代码没有设置http only属性：response.setHeader(SET-COOKIE, user= + request.getParameter(cookie); 解决方案设置cookie时，加入属性即可：response.setHeader(SET-COOKIE, user= + request.getParameter(cookie) + ; HttpOnly);下图可以看到cookie已经加入了httponly属性： 常见问题 如何在COOKIE类中设置httponly？n 目前的jdk版本只支持在setHeader时，设置httponly。 Httponly已经可以防止用户COOKIE被窃取，还需要做XSS防御吗？n 这个flag只能增加攻击者的难度，不能达到完全防御xss攻击。5.11.2 Cookie Secure flag 定义Cookie Secure，是设置COOKIE时，可以设置的一个属性，设置了这个属性后，只有在https访问时，浏览器才会发送该COOKIE。浏览器默认只要使用http请求一个站点，就会发送明文COOKIE，如果网络中有监控，可能被截获。如果Web应用网站全站是https的，可以设置COOKIE加上Secure属性，这样浏览器就只会在https访问时，发送cookie。攻击者即使窃听网络，也无法获取用户明文cookie。 代码示例这段代码没有设置Secure属性response.setHeader(SET-COOKIE, user=+ request.getParameter(cookie) + ; HttpOnly);进行网络监听，可以看到下图是没有设置Secure属性的COOKIE发送的数据包： 解决方案在设置认证COOKIE时，加入Secure：response.setHeader(SET-COOKIE, user= + request.getParameter(cookie) + ; HttpOnly ; Secure );再次访问http网站，抓数据包可以看到，已经不再发送这个COOKIE了。5.11.3 Session Expires 定义Session有效期安全攻击。由于Session没有在Web应用中设置强制超时时间，攻击者一旦曾经获取过用户的Session，就额可以一直使用。 代码示例这段代码没有在服务器中设置强制超时时间。response.setHeader(SET-COOKIE, user=+ request.getParameter(cookie) + ; HttpOnly ; Secure ); 解决方案在设置认证cookie中，加入两个时间，一个是“即使一直在活动，也要失效”的时间，一个是“长时间不活动的失效时间”。并在Web应用中，首先判断两个时间是否已经超时，再执行其他操作。/ 判断会员的cookie是否过期5.12 日志和监测做好系统的日志监测，记录好后台管理操作和异常情况，有利于监测系统未知漏洞，通过操作日志，还能找出系统出错或对某些重要操作的管理员、操作时间、IP等信息。有效地预防，检测，增强系统的安全性。对重要的日志都进行记录，如：登陆日志、系统错误日志、数据库错误日志等。6 Web应用程序安全编码要点6.1 SOCKET网络安全编程要求 在socket函数调用时，明确参数中绑定的端口、IP地址和网卡接口。Windows环境下，在遇到多个网卡的情况时，需要通过注册表来获得网卡接口和IP地址的信息，包括Windows NT和windows 2000。 判断连接的合法身份。即，为防止恶意的连接以及可能是无效的连接，建议在socket连接期间，判断连接的对端是否是合法的真正的连接。 对于UDP连接，可以获得连接对方的IP地址和端口，从而可以判断对方的有效性和合法性；对于TCP连接，由于每次连接需要三次握手，而且还有超时机制，存在两种方式来控制。 对于TCP连接，需要尽量在三次握手完成前完成判断，同时防止端口扫描的攻击。 尽可能确保socket应用能通过合理设置的防火墙。 在可能的情况下，尽量减少socket连接数目。 尽量不能使用回拨的技术。 尽量采用有连接状态的协议，例如TCP协议。由于防火墙一般采取禁止一切的策略，对于UDP协议比较难以设置。 在一个应用程序中，尽量使用同一种协议，不能使用多种协议。 尽量将客户端和服务器端的端口做成可以配置，不能硬编码在程序中。6.2 安全认证要求 为防止采用单一用户名、口令登陆被暴力破解，部分页面被重复提交数据造成灌水、刷票等，网站应考虑双因素或多因素认证。目前，普遍采用图片验证码、短信验证码，加入时间等随机因素，进行双因素认证。6.2.1 图片验证码在网站登录、发表评论时，往往都需要用户输入验证码。图片验证机制就是指根据一定的随机数产生算法来产生的一串随机数字或符号，并加入一些干扰像素最终生成相应的用于验证的图片。只有当用户肉眼识别出其中的验证码信息，输入表单并提交网站验证，验证成功后才能使用该网站提供的某项特定功能。验证码的主要用途是用于防止有人利用机器人自动批量注册、对特定的注册用户用特定的程序暴力破解。一般来讲，自动注册或者表单自动填写程序不能有效识别图片验证码中的数字或字符，因此从一定程度上实现了阻挡攻击的作用。在某支付公司某应用系统中用户登录表单无验证码验证，存在暴力破解的风险。建议页面增加图片验证码，以防止帐户被暴力破解。同时因为图片验证码也存在被绕过的可能，为解决该问题，在增加验证码的同时，须要在服务端进一步做判断，比如每分钟客户端尝试向服务器提交的验证码次数不能超过三次，如果超过需要在下一分钟再提交服务器进行验证。6.2.2 短信验证码在网站安全架构设计中，短信验证码提供了有效的用户辅助身份验证。但是，为了防止短信验证码被绕过，应注意，用户手机号应包含在服务器端，系统在调用用户手机号是只能从服务器端获得，不得提供手机号的接口，防止被恶意用户篡改。例如，下图是某支付公司支付页面，点击“获取验证码”时，获取的请求中包含了手机号码参数，可被篡改，且无校验，导致可将验证码发送到任意手机上，绕过手机短信的校验。6.3 加密方法及强度要求 禁止使用自己编写的密码算法。 不要将编码(如Base64)和密码算法混为一谈，前者不是密码算法。 不要使用低强度的密码算法，如DES、RC2等，必须采用符合业内安全强度标准的密码算法，见下表： 对于存储在数据库或日志中的敏感数据，建议采用安全的Hash算法。1） 存储策略基于安全哈希算法加密存储用户的口令安全哈希算法的存储方式已经得到广泛使用。哈希算法可用于保障信息的完整性、抗抵赖性、属于单向算法，即便哈希的结果被截获，对方也是无法还原出明文的。如果在哈希的过程中加入盐值，那就更好了，可以起到混淆的作用。也有加密方案提到通过非对称加密算法加密后存储，比如RSA，但是这种方法使用起来比较麻烦，另外还需要考虑系统后台的密钥管理，一旦密钥泄漏，后果非常严重。强对称加密算法如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。可以看到，服务端不知道用户的口令明文，所以即使数据库被攻破，也不会泄漏用户的口令。加盐的好处在于使口令存储变的更加安全。比如最常见的口令是123456，假设有100个用户都这么设置，如果不加盐，这100个用户后台加密存储的口令就一模一样，这就是一个安全隐患。加了盐值还可以增加彩虹表碰撞的难度，就算用户使用了最简单的口令，加了盐值后就难以破解。另外盐值最好选择用户注册后，就不会改变的信息，或是由这些信息计算后的另一个值。比如，如果盐值设置成了用户邮箱，那就要确保这个邮箱不能修改，否则一旦邮箱改了，HASH（“新邮箱+口令”）HASH（“旧邮箱+口令”），从而用户改了邮箱就不能再登录了。6.4 输入验证6.4.1 什么是输入应用程序从各个方面获取输入，例如所有用户发送的，或者是应用程序与用户交互往返的数据（用户提交的数据，cookie信息，查询字符串参数等），以及后台数据（数据库、配置数据和其他数据来源）。所有输入的数据都会在某些情况下影响请求的处理。输入验证是一个很复杂的问题，并且是应用程序开发人员需要解决的首要问题。然而，正确的输入验证是防御目前应用程序攻击的最有效方法之一。正确的输入验证是防止XSS、SQL注入、缓冲区溢出和其他输入攻击的有效对策。输入验证非常复杂，因为对于应用程序之间甚至应用程序内部的输入，其有效构成没有一个统一的答案。同样，对于恶意的输入也没有一个统一的定义。更困难的是，应用程序对如何处理此输入将会影响应用的风险。例如，您是否存储用于其他应用程序的数据，或者应用程序是否接受来自其他应用程序所创建的数据源的输入？以下做法可以增强Web应用程序的输入验证： 假定所有输入都是恶意的 集中方法 不要依赖客户端验证 注意标准化问题 限制，拒绝和净化输入假定所有输入都是恶意的开始输入验证时，首先假定所有输入都是恶意的，除非有证据表明它们并无恶意。无论输入是来自服务、共享文件、用户还是数据库，只要其来源不在可信任的范围之内，就应对输入进行验证。例如，如果调用返回字符串的外部Web服务，如何知道该服务不会执行恶意命令呢？另外，如果几个应用程序写入同一个共享数据库，您在读取数据时，如何知道该数据是否安全呢？集中方法将输入验证策略作为应用程序设计的核心元素。考虑集中式验证方法，例如，通过使用共享库中的公共验证和筛选代码。这可确保验证规则应用的一致性。此外，还能减少开发的工作量，且有助于以后维护工作。许多情况下，不同的字段要求不同的验证方法，例如，要求使用专门开发的常规表达式。但是，通常可以得到验证常用手段（如电子邮件地址、标题、名称、包括邮政编码在内的通讯地址，等等）的常规方法。下图显示了此验证方法：不要依赖客户端验证应使用服务器端代码执行其自身的验证。如果攻击者绕过客户端或关闭客户端脚本例程（例如，通过禁用JavaScript脚本），后果如何？使用客户端验证可以减少客户端到服务端的往返次数，但不要依赖这种方法进行安全验证。注意标准化问题数据的标准形式是最标准、最简单的形式。标准化是指将数据转化为标准形式的过程。文件路径和URL尤其倾向于标准化问题，许多广为人知的漏洞利用都直接源自标准化缺陷。例如，请考虑以下字符串，它以标准形式表示了文件及其路径。/www/public/testfile.jsp以下字符串都指向同一个文件testfile.jsp/www/public/./root/testfile.jsp/www/public/testfile.jsp%2fwww%2fpublic%2f%2f%2ftestfile.jsp(url encode)0x2f7777772f7075626c69632f7465737466696c652e6a7370(十六进制表示)最后一个示例使用十六进制指定字符：%2E代表句号%3A代表冒号%5C代表反斜杠符号%2f代表斜杠通常，应设法避免让应用程序接受用户输入的文件名，以防止标准化问题。可以考虑其他设计方法。例如，让应用程序为用户确定文件名。如果确实需要用户输入文件名，在作出安全决策（如授予或者拒绝对特定文件的访问权限）之前，应确保这些文件名具有严格定义的形式。限制、拒绝和净化输入输入验证的首选方法是从开始就限制允许输入的内容。按照已知的有效类型、模式和范围验证数据要比通过查找已知有害字符的数据验证方法容易。设计应用程序时，应了解应用程序需要输入什么内容。与潜在的恶意输入相比，有效数据的范围通常是更为有限的集合。然而，为了使防御更为彻底，您可能还希望拒绝已知的有害输入，然后净化输入。下图显示了我们推荐的策略。限制输入限制输入与允许输入有益数据类似。这是首选的输入验证方法。其思想是定义一个筛选器，根据类型、长度、格式和范围来筛选输入的数据。定义应用程序字段可以接受的数据输入，并强制应用该定义。拒绝一切有害数据。限制输入可能包括在服务器上设置字符集，以便在本地建立输入的规范格式。验证数据的类型、长度、格式和范围在适当的地方对输入数据使用强类型检查，例如，在用于操作和处理输入数据的类中，以及在数据访问例程中。例如，可以使用参数化的存储过程来访问数据，以便利于输入字段的强类型检查所带来的好处。应该检查字符串字段的长度，在许多情况下，还应检查字符串的格式是否正确。例如，邮政编码和身份证号码等都具有明确定义的格式，可以使用常规表达式进行验证。严格的检查不仅是很好的编程习惯，还能让攻击者更难利用您的代码。攻击者可能会通过类型检查，但长度检查会加大攻击者实施攻击的难度。拒绝已知的有害输入虽然不能完全依赖于这种方法，但还是应该拒绝“有害”数据。此方法通常不会像使用上述的“允许”方法那样有效，但二者结合使用可以收到最佳效果。要拒绝有害数据，需假定应用程序知道恶意输入的所有变体。请记住，字符有多种表达方式。这是“允许”方法成为首选方法的另一个原因。虽然在应用程序已经部署、不能再做重大更改时，“拒绝”方法非常有用，但它不如“允许”方法那样可靠，因为有害数据（如可用于识别常见攻击的样式）不是保持不变的。有效数据的形式是保持不变的，但有害数据的范围却是时常变化的。净化输入净化是为了使用潜在危害的数据变得安全。如果所允许的输入范围不能保证输入数据的安全性，那么净化输入是非常有用的。净化包括从删除用户输入字符串后面的空格到去除值（以便按照文字格式处理该数据）等一切行为。在Web应用程序中，另一个常见的净化输入示例是使用URL编码或HTML编码来包装数据，并将其作为文本而不是可执行脚本来处理。HtmlEncode方法去除HTML自字符，而UrlEncode方法对URL进行编码，使其成为有效的URI请求。在实践中以下是使用上述方法处理常见输入字段的几个示例：姓氏字段：这是一个很好的应用限制输入的示例。在这种情况下，可以接受的字符串范围为ASCIIA-Z和a-z，以及连字符和波浪线（在SQL中，波浪线没有意义），以便处理类似ODell之类的姓氏。还应限制输入内容的最大长度。数量字段：这是应用输入限制的另一个例子。在此示例中，可以使用简单的类型和范围限制。例如，输入数据应该是介于0和1000之间的正整数。自定义文本字段：示例包括留言板上的备注字段。在这种情况下，您可能允许输入字母和空格，以及省