应用系统安全开发技术规范V3.docx

上传人:b****1 文档编号:13733764 上传时间:2023-06-16 格式:DOCX 页数:59 大小:269.96KB
下载 相关 举报
应用系统安全开发技术规范V3.docx_第1页
第1页 / 共59页
应用系统安全开发技术规范V3.docx_第2页
第2页 / 共59页
应用系统安全开发技术规范V3.docx_第3页
第3页 / 共59页
应用系统安全开发技术规范V3.docx_第4页
第4页 / 共59页
应用系统安全开发技术规范V3.docx_第5页
第5页 / 共59页
应用系统安全开发技术规范V3.docx_第6页
第6页 / 共59页
应用系统安全开发技术规范V3.docx_第7页
第7页 / 共59页
应用系统安全开发技术规范V3.docx_第8页
第8页 / 共59页
应用系统安全开发技术规范V3.docx_第9页
第9页 / 共59页
应用系统安全开发技术规范V3.docx_第10页
第10页 / 共59页
应用系统安全开发技术规范V3.docx_第11页
第11页 / 共59页
应用系统安全开发技术规范V3.docx_第12页
第12页 / 共59页
应用系统安全开发技术规范V3.docx_第13页
第13页 / 共59页
应用系统安全开发技术规范V3.docx_第14页
第14页 / 共59页
应用系统安全开发技术规范V3.docx_第15页
第15页 / 共59页
应用系统安全开发技术规范V3.docx_第16页
第16页 / 共59页
应用系统安全开发技术规范V3.docx_第17页
第17页 / 共59页
应用系统安全开发技术规范V3.docx_第18页
第18页 / 共59页
应用系统安全开发技术规范V3.docx_第19页
第19页 / 共59页
应用系统安全开发技术规范V3.docx_第20页
第20页 / 共59页
亲,该文档总共59页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

应用系统安全开发技术规范V3.docx

《应用系统安全开发技术规范V3.docx》由会员分享,可在线阅读,更多相关《应用系统安全开发技术规范V3.docx(59页珍藏版)》请在冰点文库上搜索。

应用系统安全开发技术规范V3.docx

应用系统安全开发技术规范V3

 

应用系统安全开发技术规范

(版本号V1.3)

朗新科技股份有限公司

二〇一五年十二月

 

更改履历

版本号

修改编号

更改时间

更改的

图表和章节号

更改简要描述

更改人

批准人

0.5

2013-11-24

初稿

施伟

施伟

1.0

2015-11-19

修改

宋月欣

陈志明

1.1

2015-11-30

修改

宋月欣

陈志明

1.2

2015-12-3

修改

宋月欣

施伟

1.3

2015-12-3

修改

施伟

注:

更改人除形成初稿,以后每次修改在未批准确认前均需采用修订的方式进行修改。

1背景与目标

在Internet大众化及Web技术飞速演变的今天,Web安全所面临的挑战日益严峻。

黑客攻击技术越来越成熟和大众化,针对Web的攻击和破坏不断增长,Web安全风险达到了前所未有的高度。

许多程序员不知道如何开发安全的应用程序,开发出来的Web应用存在较多的安全漏洞,这些安全漏洞一旦被黑客利用将导致严重甚至是灾难性的后果。

这并非危言耸听,类似的网上事故举不胜举,公司的Web产品也曾多次遭黑客攻击,甚至有黑客利用公司Web产品的漏洞敲诈运营商,造成极其恶劣的影响。

本规范为解决Web应用系统安全问题,对主要的应用安全问题进行分析,并有针对性的从设计及开发规范、开发管理、安全组件框架、安全测试方面提供整体的安全解决方案。

使本组织能以标准的、规范的方式设计和编码。

通过建立编码规范,以使每个开发人员养成良好的编码风格和习惯;并以此形成开发小组编码约定,提高程序的可靠性、可读性、可修改性、可维护性和一致性等,增进团队间的交流,并保证软件产品的质量。

2安全编程概念

2.1安全编程

安全编程是指开发人员首先需要具备一定的安全知识,然后识别数据在流转(输入、处理和输出)过程中可能面对的威胁,对这些威胁进行分析得出其利用的漏洞,通过合理地编写代码消除这些漏洞,降低软件面临的风险。

本规范对开发人员的编码提出统一的安全要求,主要涉及输入处理、输出处理、数据库访问、文件操作、异常管理等方面,如下图:

输入处理部分能指导开发者避免用户的不良输入;输出处理能指导开发者对输出内容进行过滤;数据库访问、文件操作部分则能指导开发者进行数据库查询,写入文件等操作时进行防护;而异常管理、敏感数据保护、对象重用等技术则指导开发者改进软件的自身缺陷。

WEB开发规范部分则指导用户在WEB系统(B/S架构应用)的研发方面时如何增加对应用软件的保护。

2.2结构化编程

结构化编程,一种编程典范。

它采用子程序、程式码区块、for循环以及while循环等结构,来取代传统的goto。

希望借此来改善计算机程序的明晰性、品质以及开发时间,并且避免写出面条式代码。

2.3脆弱性

脆弱性指计算机系统安全方面的缺陷,使得系统或其应用数据的保密性、完整性、可用性、访问控制、监测机制等面临威胁。

2.4可信计算

可信计算的行为会更全面地遵循设计,而执行设计者和软件编写者所禁止的行为的概率很低。

2.5安全可信模块

审计和访问控制模块是唯一的安全可信模块。

2.6不可信任模块

除审计和访问控制模块外其它所有模块均为不可信模块。

2.7敏感信息

系统的敏感信息包括用户身份信息、认证信息、授权信息、交易过程中的私密或隐私信息、其它的敏感信息。

2.8特权

特权只是允许去做并不是每个人都可以做的事情。

2.9信息隐藏

信息隐藏指在设计和确定模块时,使得一个模块内包含的特定信息(过程或数据),对于不需要这些信息的其他模块来说,是不可访问的。

信息隐藏基本原理框图:

2.10中间件

中间件是提供系统软件和应用软件之间连接的软件,以便于软件各部件之间的沟通.中间件技术创建在对应用软件部分常用功能的抽象上,将常用且重要的过程调用、分布式组件、消息队列、事务、安全、连结器、商业流程、网络并发、HTTP服务器、WebService等功能集于一身或者分别在不同品牌的不同产品中分别完成。

2.11死锁

死锁是操作系统或软件运行的一种状态:

在多任务系统下,当一个或多个进程等待系统资源,而资源又被进程本身或其它进程占用时,就形成了死锁。

2.12可信边界

可信边界可以被认为是在程序中划定的一条分隔线,一边的数据是不可信的而另一边则是可信的。

当数据要从不可信的一侧到可信一侧的时候,需要使用验证逻辑进行判断。

2.13元字符

元字符就是在编程语言中具有特定含义的字符或者字符串。

例如在SQL查询中,单引号(‘)是危险的字符;在文件系统路径中两个点号(..)是危险的字符;在命令shell中,分号(;)和双&(&&)符号同样是危险的字符,而换行符(\n)对日志文件很关键。

2.14参数化查询

参数化查询(ParameterizedQuery或ParameterizedStatement)是指在设计与数据库链接并访问数据时,在需要填入数值或数据的地方,使用参数(Parameter)来给值,这个方法目前已被视为最有效可预防SQL注入攻击(SQLInjection)的攻击手法的防御方式。

2.15UNIXJAIL环境

一个被改变根目录的程序不可以访问和命名在被改变根目录外的文件,那个根目录叫做“chroot监狱(chrootjail,chrootprison)”。

2.16临时文件

创建临时文件的程序会在完成时将其删除。

2.17信息熵

信息熵指信息的不确定性,一则高信息度的信息熵是很低的,低信息度的熵则高。

2.18SSL

安全套接层(SecureSocketsLayer,SSL),一种安全协议,是网景公司(Netscape)在推出Web浏览器首版的同时提出的,目的是为网络通信提供安全及数据完整性。

SSL在传输层对网络连接进行加密。

SSL采用公开密钥技术,保证两个应用间通信的保密性和可靠性,使客户与服务器应用之间的通信不被攻击者窃听。

它在服务器和客户机两端可同时被支持,目前已成为互联网上保密通讯的工业标准。

现行Web浏览器亦普遍将HTTP和SSL相结合,从而实现安全通信。

此协议和其继任者是TLS。

2.19TLS

SSL(SecureSocketsLayer)是网景公司(Netscape)设计的主要用于Web的安全传输协议。

这种协议在Web上获得了广泛的应用。

IETF(www.ietf.org)将SSL作了标准化,即RFC2246,并将其称为TLS(TransportLayerSecurity),其最新版本是RFC5246,版本1.2。

从技术上讲,TLS1.0与SSL3.0的差异非常微小。

2.20HTTPS

超文本传输安全协议(缩写:

HTTPS,英语:

HypertextTransferProtocolSecure)是超文本传输协议和SSL/TLS的组合,用以提供加密通讯及对网络服务器身份的鉴定。

HTTPS连接经常被用于万维网上的交易支付和企业信息系统中敏感信息的传输。

HTTPS不应与在RFC2660中定义的安全超文本传输协议(S-HTTP)相混。

2.21Http会话

在计算机科学领域来说,尤其是在网络领域,会话(session)是一种持久网络协议,在用户(或用户代理)端和服务器端之间创建关联,从而起到交换数据包的作用机制,session在网络协议(例如telnet或FTP)中是非常重要的部分。

在不包含会话层(例如UDP)或者是无法长时间驻留会话层(例如HTTP)的传输协议中,会话的维持需要依靠在传输数据中的高级别程序。

例如,在浏览器和远程主机之间的HTTP传输中,HTTPcookie就会被用来包含一些相关的信息,例如sessionID,参数和权限信息等。

当客户端在多个服务器调取数据时,保持会话状态的一致性是需要注意的,客户端需用同时保持和某一个主机的连接,或者多个服务器端需要共享一个储存会话信息的文件系统或者数据库。

否则,当用户在一个新的而不是一开始保存会话信息的主机上提交访问请求的时候,主机会因为无法获知原来主机的会话的访问状态而产生问题。

2.22Cookie

Cookie(复数形态Cookies),中文名称为小型文本文件或小甜饼,指某些网站为了辨别用户身份而储存在用户本地终端(ClientSide)上的数据(通常经过加密)。

定义于RFC2109。

为网景公司的前雇员LouMontulli在1993年3月所发明。

2.23HttpOnlyCookie

HttpOnly是包含在Http响应头信息Set-Cookie中的一个额外标志,如果浏览器支持HttpOnly标志的话,在生成Cookie时使用HttpOnly标志可帮助减轻客户端脚本访问受保护的Cookie时带来的风险(客户端脚本不能访问HttpOnlyCookie)。

3安全编程原则

3.1统一的安全规范

每个软件项目在设计阶段都应明确在项目实施过程中项目组应遵循的统一规范,具体包括:

1.命名规则、组件使用规范、异常处理规范、日志处理规范、工具使用要求、代码集成规范。

2.针对本规范提出的主要代码脆弱性应进行相应的防范设计,具体内容应在软件概要设计中体现或有单独的文档体现。

3.2模块划分

1.软件应该按照安全性划分模块,审计和访问控制模块为安全可信模块,其它模块为不可信任模块。

只有安全可信模块才可以执行安全控制功能,其它的模块不能访问安全可信模块的安全信息、功能或者权限。

安全可信模块应该与其它模块分离,由经授权的内部专人进行管理。

2.只有安全可信模块,才能以高安全等级访问系统的敏感信息,对于其他模块限制其访问敏感信息。

3.3最小化功能

根据“没有明确允许的就默认禁止”的原则,软件应只包含那些为达到某个目标而确实需要的功能,不应包含只是在将来某个时间需要但需求说明书中没有的功能。

软件在最小化功能建设方面应遵循如下原则:

1.只运行明确定义的功能。

2.系统调用只在确实需要的时候。

3.一次只执行一个任务。

4.只有在上一个任务完成后才开始下一个任务。

5.只在确实需要的时候访问数据。

3.4最小化特权

1.只为程序中需要特权的部分授与特权。

2.只授与部分绝对需要的具体特权。

3.将特权的有效时间或者可以有效的时间限制到绝对最小。

3.5对多任务、多进程加以关注

软件开发应尽量使用单任务的程序。

如果软件需要使用多任务和多进程,应该认真分析研究多任务和多进程会不会发生冲突,同步所有的进程和任务以避免冲突。

同时作为结构化的编程,每个原子化组件都要保证一个入口和一个出口。

如果进程之间需要交互,则这些交互操作应同步。

对于每一种可能的交互情况都要考虑相关的安全策略。

3.6界面输出最小化

软件应保持用户界面只提供必须的功能,没有多余的、不必要的功能,确保用户不能通过用户界面直接访问数据或者直接访问被保护对象。

3.7使代码简单、最小化和易于修改

开发时应尽量使代码简单、最小化和易于修改。

使用结构化的编程语言,尽量避免使用递归和Goto声明。

使用简单的代码,清除不必要的功能,防止采用信息隐藏方式进行数据保护。

3.8避免高危的服务、协议

软件应尽量避免使用不加保护的及已被证明存在安全漏洞的服务和通信协议传输文件,如FTP、SMTP。

3.9数据和代码分离

软件应该把数据与程序放置在不同的目录中,这里的数据包括远程下载文件等。

3.10关键数据传输保护

1.软件在传输关键数据时,使用加密算法保证数据在通信过程不被破译,使用数字签名保证数据在传输过程中的一致性和不可否认性。

相关的加密算法和签名技术等应符合国家相关法律法规要求。

2.信息隐藏是不可靠、效率低的做法,软件应该使用正确的安全保护措施,不要依赖隐藏进行数据保护。

3.11禁止赋予用户进程特权

用户进程的授权应采用最小授权法,对于软件的普通用户进程,禁止赋予该类进程特权用户权限。

特权用户类型包括:

1.超级用户。

2.直接操作数据库用户。

3.安全管理用户。

3.12使用适当的数据类型

应该小心使用数据类型,尽量使用占用内存较小的数据类型,如可用整型数据的不用实型,特别是在程序接口部分。

例如,在一些编程语言中signed和unsigned的数据类型是视为不同的(如C或者C++语言)。

3.13使用经过验证的安全代码

使用经过验证的安全代码模块和外部源程序,防止潜在的安全风险。

3.14使用应用中间件

中间件作为一种应用层架构,软件设计应尽可能使用中间件,中间件选型时应选择成熟的、业界主流的中间件产品。

3.15设计错误、异常处理机制

软件设计开发时应建立防止系统死锁的机制,异常情况的处理和恢复机制,具体包括错误和异常检测、数据回滚、安全错误通知、错误和异常记录、断点保护等。

3.16提供备份机制

为保证运行数据的完整性和可用性,软件开发应设计有效的备份策略,根据业务和系统维护需要提供定期或不定期、自动或手动方式的备份机制。

3.17检查传递变量的合法性

应检查所有传递给系统函数调用(SystemCalls)或本地调用(NativeCalls)的变量的合法性。

3.18检查所有函数返回代码

应检查所有函数调用返回代码(错误代码),对每个期望的返回值设置相应的处理程序。

3.19修改面向用户的操作的反馈缺省描述

应对面向用户的操作的反馈缺省描述进行必要的封装,删除有关后台系统或其它敏感信息。

3.20文件操作的要求

在需要进行文件操作时,应预先设定目前工作路径(全路径名),使用全路径名表示文件的位置。

3.21其他编码原则

1.当一个进程对敏感对象(包含秘密信息或包含不可更改信息)使用完后,应立即擦除对象的敏感信息,然后再删除对象。

任何不需要使用的资源应及时释放。

2.确保所有用来指示数组下标的数据(或指针)都指向了一个有效的数组元素。

如果某个函数不能保证下标所指向元素的有效性,或者根本不去检查边界时,不要使用该函数,应该寻找一个安全的函数,或者自己重新编写一个或者封装一个不安全的函数,加上必要的判断条件,使它安全。

3.当输入不可信任数据时,要在该数据的内容和格式上同时加以检查。

对于整数,应该检查数据大小是否超出了能够表示的范围;对于输入的字符串,要确保长度没有溢出,保证每一个字符都是有效的。

4.对经常使用的类似的SQL语句应使用绑定变量的方法,避免数据库执行类似SQL语句时重复解析、重复访问数据文件的行为。

5.程序编码结束后,应对代码进行优化,提高应用处理SQL的性能。

6.禁止使用通配符的方式进行数据的插入操作。

7.采用数据库作为系统间接口方式时,应建立独立的接口表,并按最小化特权原则进行授权。

4应用安全分析

4.1安全需求

系统安全本质上属于信任问题,要保证应用安全,就必须将解决各种操作过程中不可信问题。

安全的几个基本要素为机密性、完整性、可用性、可审计性、不可抵赖性等方面的安全要求。

机密性要求保护数据内容不能泄露,加密是实现机密性的要求的常见手段。

完整性要求保护数据内容是完整、没有被篡改的。

可用性要求保护资源是可被按照需要访问。

可审计性对出现的安全问题提供调查的依据和手段。

不可抵赖性建立有效的责任机制,防止用户否认其行为。

4.2安全威胁

4.2.1Web安全漏洞

根据结合国网系统安全检测项目常见安全问题及OWASP组织发布的安全漏洞,系统中存在的需要解决的安全风险如下:

序号

安全威胁

产生环节

1

SQL注入

编码

2

失效的身份认证及会话管理

设计、编码

3

跨站脚本(XSS)

编码

4

点击劫持(ClickJacking)

编码

4

不安全的直接对象引用

编码

5

安全配置错误

配置实施

6

敏感信息泄露

设计、编码

7

功能级访问控制缺失(失败的URL访问权限限制)

设计

8

跨站请求伪造(CSRF)

编码

9

使用含有已知漏洞的组件

管理、设计

10

未验证的重定向和转发

编码

11

传输层保护不足

设计、编码

12

文件上传漏洞

编码

13

不安全的加密存储

设计、编码

4.2.2拒绝服务攻击

分布式拒绝服务攻击(英文:

DistributedDenialofService,缩写:

DDoS)亦称洪水攻击。

顾名思义,即是利用网络上已被攻陷的电脑作为“僵尸”,向某一特定的目标电脑发动密集式的“拒绝服务”式攻击,用以把目标电脑的网络资源及系统资源耗尽,使之无法向真正正常请求的用户提供服务。

黑客通过将一个个“丧尸”或者称为“肉鸡”组成僵尸网络,就可以发动大规模DDoS或SYN洪水网络攻击,或者将“丧尸”们组到一起进行带有利益的刷网站流量、Email垃圾邮件群发,瘫痪预定目标受雇攻击竞争对手等商业活动。

4.2.3嗅探攻击

利用计算机的网络接口截获目的地为其他计算机的数据报文的一种技术。

它工作在网络的底层,把网络传输的全部数据记录下来.嗅探器可以帮助网络管理员查找网络漏洞和检测网络性能。

嗅探器可以分析网络的流量,以便找出所关心的网络中潜在的问题。

证明你的网络有嗅探器有两条经验:

1.网络通讯丢包率非常高:

通过一些网管软件,可以看到信息包传送情况,最简单是ping命令。

它会告诉你掉了百分之多少的包。

如果你的网络结构正常,而又有20%-30%数据包丢失以致数据包无法顺畅的流到目的地。

就有可能有人在监听,这是由于嗅探器拦截数据包导致的。

2.网络带宽出现反常:

通过某些带宽控制器,可以实时看到目前网络带宽的分布情况,如果某台机器长时间的占用了较大的带宽,这台机器就有可能在监听。

应该也可以察觉出网络通讯速度的变化。

4.2.4中间人攻击

在密码学和计算机安全领域中,中间人攻击(Man-in-the-middleattack,通常缩写为MITM)是指攻击者与通讯的两端分别建立独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话,但事实上整个会话都被攻击者完全控制。

在中间人攻击中,攻击者可以拦截通讯双方的通话并插入新的内容。

在许多情况下这是很简单的(例如,在一个未加密的Wi-Fi无线接入点的接受范围内的中间人攻击者,可以将自己作为一个中间人插入这个网络)。

一个中间人攻击能成功的前提条件是攻击者能将自己伪装成每一个参与会话的终端,并且不被其他终端识破。

中间人攻击是一个(缺乏)相互认证的攻击。

大多数的加密协议都专门加入了一些特殊的认证方法以阻止中间人攻击。

例如,SSL协议可以验证参与通讯的一方或双方使用的证书是否是由权威的受信任的数字证书认证机构颁发,并且能执行双向身份认证。

4.3安全约束

序号

限制

1

外网不允许部署数据库

2

外网仅提供HTTP、HTTPS访问,不提供FTP、SFTP等

3

外网访问内网必须通过强隔离装置,仅支持TNS协议(国网系统要求)

4

外网应用不允许直接访问内网关键业务系统数据库

5

其它系统原则上都不允许直接连接营销系统数据库

5安全编程要求

5.1输入处理

5.1.1建立可信边界

需要在程序中定义清晰的可信边界。

在一些代码中用于保存可信数据的数据结构,不能被用来在其它代码中存储不可信数据。

使数据穿越可信边界的次数降到最低。

当程序混淆了可信和不可信数据的界限时会导致安全边界发生问题,最容易导致这种错误的情况是把可信和不可信数据混合在一个数据结构里。

如下例:

该例中程序接受一个http请求并将"usrname"参数放在HTTPsession里,但是并未检查用户是否被授权。

usrname=request.getParameter("usrname");

if(session.getAttribute(ATTR_USR)==null){

session.setAttribute(ATTR_USR,usrname);

}

 

由于开发者都知道用户是不能直接访问session对象的,所以很容易信任来自session的所有信息,但是如果在该session中混合存储了可信和不可信的数据,就会违反完全可信边界的原则,带来安全隐患。

如果不能很好的建立和维护可信边界,开发者将不可避免的混淆未被验证和已验证的数据,从而导致一些数据在未经验证时就被使用。

如果输入的数据在处理前通过一些用户的交互发生了改变,可信边界就会遇到一定的问题,因为它很可能在所有数据进入之前不能做出完全的输入验证。

在这种情况下,维护一个可信的边界就尤为重要,不可信数据应该单独存放在专门存放不可信数据的数据结构内,在经过验证之后才被放在可信区域。

这样在看一段代码时,就很容易识别数据是在可信边界的哪一侧。

5.1.2验证各种来源的输入

不要将软件的安全性寄托在配置、使用和维护人员的敏锐理解力、深刻洞察力或良好意愿上,不仅需要验证用户输入,而且还要验证所有来自于软件之外的输入,这些输入应当包括下列内容,但并不仅仅局限于此:

1.HTTP请求消息的全部字段,包括GET数据、POST数据、COOKIE和Header数据等。

2.不可信来源的文件。

3.第三方接口数据。

4.从数据库中检索出的数据。

5.对来自命令行、环境以及配置文件的输入。

6.网络服务。

7.注册表值。

8.系统性能参数。

9.临时文件。

5.1.3保证所有的输入信息是被验证过的

确保在输入验证之前,新输入的数据不能被添加到程序中(输入的数据不能进入程序代码中被执行)。

也就是说,程序默认情况下要对所有的输入信息进行验证,不能通过验证的数据将会被拒绝。

5.1.4对输入内容进行规范化处理后再进行验证

当输入数据包含文件名、路径名、URL等数据时,应先对输入内容进行规范化处理后再进行验证,如文件路径、URL地址等数据,需要规范化为标准的格式后再进行验证。

5.1.5选择合适的数据验证方式

应根据情况综合采用多种输入验证的方法,包括:

1.检查数据是否符合期望的类型。

2.检查数据是否符合期望的长度。

3.检查数值数据是否符合期望的数值范围,比如检测整数输入的最大值与最小值。

4.检查数据是否包含特殊字符,如:

、"、'、%、(、)、&、+、\、\'、\"等。

5.应使用正则表达式进行白名单检查尽量避免使用黑名单法。

5.1.6防范元字符攻击

攻击者通常会使用元字符对应用程序发起攻击。

攻击者可以通过对同一个元字符采取多种编码方式或者根据语言特征采取多种实现方式,因此应过滤输入数据中那些具有特定含义的字符,如单引号、双引号、圆括号、分号等。

5.1.7拒绝验证失败的数据

应拒绝验证失败的输入数据,不试图对其进行修复(如处理密码域时自动剪裁掉超过最大长度的输入,替换掉在输入框输入的JavaScript字符等)。

输入验证本身就很复杂,如果和自动错误恢复的代码混合在一起的话,将会造成更大的复杂性,自动错误恢复代码很可能改变请求的含义或者截断验证逻辑。

如果我们能够引导用户,使他们提交的请求能够通过输入

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 表格模板 > 合同协议

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2