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

开发代码安全规范 防SQL注入和XSS跨站攻击代码编写规范 修订历史 版本 公布日期 作者 审核者 改版统计 1.0 -12-01 正式版 目 录 TOC \o 1-3 \h \z \u 概述 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 概述 在技术高速发展今天，Web应用被广泛使用，伴随而来是多种安全隐患，关键是编程人员安全意识较淡薄，缺乏安全编程经验，上线前安全检测不全方面。所以，给心怀不轨之人以机会，对企业和个人财产安全造成威胁。本规范期望给编程人员一个较清楚安全概念，在代码编写时提升警惕。 适用范围 xx集团及其分子企业业务系统全部开发人员，包含系统外包第三方开发人员。 一、第一类漏洞类型-SQL注入（SQL Injection）及规范 1.1 名词解释： SQL注入攻击：经过把SQL命令插入到Web表单递交或输入域名或页面请求查询字符串，最终达成欺骗服务器实施恶意SQL命令。 具体来说，它是利用现有应用程序，将（恶意）SQL命令注入到后台数据库引擎实施能力，它能够经过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞网站上数据库，而不是根据设计者意图去实施SQL语句。 1.2 经典案例说明： 例1：用户登录界面及标准输入格式： Web和数据库连接调用方法： 经过“‘空’or’1’=’1’”这类非法输入，进行恶意SQL注入 以上例子是开发人员直接把用户输入看成可信部分直接和SQL语句拼接造成SQL漏洞。 例2：即使开发人员利用PHP内置过滤函数后，还是有可能出现问题： 调用PHP函数能够改善查询和调用，并限制输入类型，但仍然无法避免注入： 利用GBK转译编码方法依旧能够实施‘空’or‘1=1’类注入语句 所以，使用PHP函数规范输入时，还必需注意字符集选择问题： 1.3 代码实例分析： Web应用存在着多个多样SQL注入漏洞，下面以生产实例进行分析。 实例1：参数传输 SQL 语句片断 数据起源：某线上业务被拦截数据 数据日期：-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 列数据。 实例2：参数传输完整 SQL 语句 数据起源：某线上业务被拦截数据 数据日期：-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 () 这里开发人员为了业务便利性，直接从用户端将完整 SQL 语句经过 HTTP 请求发送给后端。这也是很经典 SQL 注入点，对于恶意攻击黑客来说，能够结构恶意 SQL 语句请求给后端，从而达成恶意获取数据、修改数据、毁坏数据目标，甚至假如权限设置不合理话，恶意攻击黑客可能从该注入点获取服务器管理权限。 1.4 SQL注入危害： 敏感数据被获取(cookie盗取) 网络钓鱼 获取 web 用户