开发代码安全规范-防SQL注入和XSS跨站攻击代码编写规范.doc

开发代码安全规范 防SQL注入和XSS跨站 修订历史 发布日期 作者 审核者 改版记录 1.0 2015-12-01 正式版 目 录 概述 2 适用范围 2 一、第一类漏洞类型-SQL注入（SQL Injection）及规范 2 1.1名词解释： 2 1.2经典案例说明： 2 1.3代码实例分析： 6 1.4防止SQL注入攻击的代码安全规范总结： 7 二、第二类漏洞类型-XSS跨站脚本攻击及规范 8 2.1名词解释： 8 2.2经典案例说明： 8 2.3 防止XSS跨站脚本攻击的代码安全规范总结： 9 三、安全操作实践 10 概述 在技术高速发展的，淡薄，对公司财产安全威胁较清晰安全概念，在编写时提高警惕 适用范围 注入SQL Injection）及规范 解释 SQL注入攻击： 具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。 1.2 经典案例说明： 登录标准输入格式 Web与数据库连接调用方式： ’or’1’=’1’”这类非法输入，SQL注入 以上是开发人员直接把用户输入当作可信部分直接和SQL语句拼接造成的漏洞。 过滤函数后，有可能出现： 调用PHP函数查询调用，限制输入类型 利用GBK转译编码方式可以执行‘’or‘1=1’类注入语句 因此，使用PHP函数规范，字符集问题 1.3 代码实例： SQL注入漏洞， 实例1：参数传递 SQL 语句片断 数据来源：线上业务被拦截数据 数据日期：2015-10-21 数据内容：HTTP 请求的 URLPATH /WRIROOT?wri=671DBName=devpagenum=15page=1SortValue=%20order%20by%20FeeStamp%20%20DescXXXXX=WWW 处理截图： 案例分析： 在这个案例中，URL 参数 SortValue 的值为 order by FeeStamp Desc，这是一个典型的 SQL 注入点。对于业务需求来说，传递 order by FeeStamp Desc 可能方便了后端的处理，但是如果被恶意攻击，那么可以传不符合业务预期的参数，对后端数据库造成损害。如： order by FeeStamp Desc union select username, password, 1, 2, 3 from users *注：此处假设存在 users 数据表，并且username 和 password 的列数据。 ：参数传递完整 SQL 语句 数据来源：线上业务被拦截数据 数据日期：2015-10-21 数据内容：HTTP 请求的 BODY 处理截图： 案例分析：在这个案例中，HTTP Body 是常见的 application/x-www-form-urlencoded 类型。其中 DBName 参数的值是 dev，sql 参数的值是： select a.payoutid,a.value,b.basket_id,b.inserttime,a.suppliername,a.currentrank from tabpayout_sheet a left join TabPayOut_Basket b on a.payoutid=b.payoutid where a.payoutid in (605641737) 这里为了业务的便利性，直接从客户端将完整 SQL 语句通过 HTTP 请求发送给后端。这也是非常典型的 SQL 注入点，对于恶意攻击的黑客来说，可以构造恶意 SQL 语句请求给后端，从而达到恶意获取数据修改数据毁坏数据的目的，甚至如果权限设置不合理的话，恶意攻击的黑客可能从该注入点获取服务器权限。 SQL注入危害： 敏感数据被获取(cookie盗取) 网络钓鱼 获取 web 用户的网页内容 Session Riding(CSRF 攻击 获取用户的键盘击键数据 web 僵尸1.5防止SQL注入攻击的代码安全规范总结： 1、所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前，几乎所有的数据库系统都提供了参数化SQL语句执行接口，使用此接口可以非常有效的防止SQL注入攻击。 2、对进入数据库的特殊字符（\*;等）进行转义处理，或编码转换。 3、确认每种数据的类型。比如：数字型的数据就必须是数字，数据库中的存储字段必须对应为in