调试工具保证金授权店铺类型说明
运营规范
  • 有赞云平台规范
    • 运营规范
    • 开发规范
    • 发布规范
    • 入驻规范
    • 有赞云安全规则
    • 平台违规处罚规范
    • 有赞云开发者成长计划
    • 有赞云开发者权益说明
    • 有赞云API服务费规则
    • 有赞应用市场技术服务费收费标准
    • 有赞云漏洞应急响应规范
    • 有赞云安全开发规范
    • 资损防范指导规范
    • 三方应用故障处理规范
    • 有赞云cookie使用规范
    • 有容器工具型应用扩容和商业化规则
    • 有赞云API优惠政策
  • 有赞云平台协议
    • 平台服务协议
    • 用户授权服务协议
  • 应用市场平台规范
    • 应用创建规范
      • 工具型应用创建审核规范
      • 有赞云自用型无容器应用创建审核规范
    • 应用上架规范
    • 违规处罚规范
    • 争议处理规则
    • 资源位推荐机制
    • 优质应用模板内容规范
    • 优质内容投放规范
    • 全渠道系统牵手计划解决方案案例规范
    • 应用违规举报规则
    • 应用市场保证金管理规范
    • 应用市场线上退款规范
    • 有赞应用市场客服工具服务使用管理规则
  • 应用市场平台协议
    • 应用上架协议
    • 应用市场使用协议
  • 应用市场类目规范
    • 营销管理类目
    • 商品管理、订单发货及卡券核销类目
    • 电商ERP类目
    • 跨境服务类目
    • 客服管理类目
    • 仓储物流类目
    • 全渠道经营类目
    • 内容管理类目
    • 解决方案类目
    • 企业管理类目
    • 软件定制类目规范
    • 模板市场类目
  • 服务市场平台规范
    • 服务商入驻指南
      • 服务市场招商入驻流程
      • 平台官网入驻操作流程
    • 服务市场保证金管理规范
    • 服务发布与详情编辑
      • 服务发布流程
      • 服务上架标准
      • 商品详情页包装指南
    • 服务上线后如何运营
      • 成长服务商推广PPT制作建议
      • 推荐展位(资源位)指南
      • 爆款服务推荐计划
      • 优质案例投放规范
      • 服务商后台系统操作指导
    • 资质及质量考核标准
      • 类目资质考核标准
      • 服务商退出规范
    • 服务商评级维度及评分标准
    • 有赞服务市场平台服务费收费标准
    • 违规处理规范
    • 争议处理规则
  • 服务市场平台协议
    • 服务市场入驻协议
    • 服务市场保证金协议
  • 服务市场类目规范
    • 装修拍摄服务类目管理规范
    • 代运营类目服务管理规范
运营规范有赞云平台规范入驻规范
入驻规范
最后更新日期:2025-03-25

最新调整日期:2025年03月25日

调整内容:原第3条第4款内容为“应用180天内没有新订购,同时没有正在使用中的商家”,现更新为“应用180天内没有新订购,或正在使用中的商家数低于3个(含3个)”

调整生效日期:2025年04月01日

一. 总则

1、为保证有赞云平台的规范、有序、安全运营,特制定本规范。

2、本规则适用于所有入驻有赞云的开发者。

3、作为有赞云平台的开发者,除了解和遵守《有赞云平台服务协议》、《有赞云应用市场上架协议》、《有赞云应用授权服务协议》等相关平台的协议和规则的约束外,还需仔细阅读并遵守本《有赞云开发规范》。

二. 应用开发规范

1、若开发者开发的应用为自用型应用的,则应用授权店铺账号必须与开发者注册的有赞账号相一致。

2、若开发者开发的应用为工具性应用的,则开发者通过有赞云获取的商家数据均应事先获得商家授权,且该数据仅可展现或使用于该授权商家,不得向任何第三方组织或个人共享。

3、开发者不得聚合数据,应用系统后台不得将多个账号主体下的店铺进行统一展示。

4、应用名称使用规则:

(1)需要提交正式、完整,带上自己的正式品牌名,未重复的应用名称。

(2)在未得到有赞品牌授权的情况下请勿在品牌名中使用“有赞“字样。

(3)申请名称请勿出现“测试”、“test”等字样。

(4)申请名称请勿出现法律不允许的敏感词。

(5)申请名称申请通过后无法修改,申请名称需慎重。

三. 应用使用规范

1、应用创建后如3个月内未发布成功或工具型应用3个月内未上架应用市场,平台将删除应用并回收应用标签。

2、应用近60天内无API有效调用的,平台将删除应用并回收应用标签。

3、应用的使用者必须为该应用的开发者,不得将账号密码转借或转让给任何第三方使用,否则平台将删除应用并回收应用标签。

4、应用180天内没有新订购,或正在使用中的商家数低于3个(含3个);应用后续不再维护,同时未上架应用市场或已被下架,平台会自动回收应用使用的各项资源和权限,包括容器实例、数据库、缓存、API调用权限等。

5、工具型应用只服务于自己的店铺,平台发现后将下架应用,回收应用使用的各项资源和权限,包括容器实例、数据库、缓存、API调用权限等。

6、有容器工具型应用连续1年服务商家数少于5家,且应用近1年收入少于50,000元,平台将下架应用,回收应用使用的各项资源和权限,包括容器实例、数据库、缓存、API调用权限等。

7、有容器工具型应用,在应用市场处于隐藏状态的,平台有权进行特定处理,予以应用下架,回收应用使用的各项资源和权限,包括容器实例、数据库、缓存、API调用权限等。

四.API使用规范

1、若API近90天无有效调用的,有赞云平台有权收回开发者的API调用权限。

2、有赞非常重视商家的隐私,因此,开发者在通过开放API获取商家数据前必须先获得商家授权,同时,开发者需要采取必要的措施保护商家的隐私安全,严禁将数据泄露给任何第三方,否则,有赞云平台有权将收回开发者的API调用权限;

3、开发者调用API的行为若侵犯有赞权利的,有赞云平台有权收回开发者的API调用权限。

4、开发者调用有赞接口的日均请求成功率需高于90%。

5、严禁开发者在富文本插入时注入恶意代码,否则,有赞云平台有权收回开发者的API调用权限。

五. 代码安全规范

1、针对“反序列化命令执行”漏洞

(1)定义:Java反序列化是指把字节序列恢复为Java对象的过程,ObjectInputStream类的readObject()方法用于反序列化。

(2)风险:暴露或间接暴露反序列化API,导致用户可以操作传入数据,攻击者可以精心构造反序列化对象并执行恶意代码。

(3)代码规范:

1)使用spring、struts2、fastjson、dubbo等开源框架时,一定要保证为最新版本;

2)业务中自行开发的涉及到序列化与反序列化时在ObjectInputStream 中resolveClass 里只是进行了class 是否能被load,自定义ObjectInputStream, 重载resolveClass的方法,对className 进行白名单校验:

public final class test extends ObjectInputStream{

...

protected Class<?> resolveClass(ObjectStreamClass desc)

​ throws IOException, ClassNotFoundException{

​ if(!desc.getName().equals("className")){

​ throw new ClassNotFoundException(desc.getName()+" forbidden!");

​ }

​ returnsuper.resolveClass(desc);

}

...

}

2、针对“SSRF”漏洞

(1)定义:SSRF(Server-Side Request Forger)即服务器端请求伪造,是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。

(2)风险:一般情况下,SSRF攻击的目标是从外网无法访问的内部系统。(正是因为它是由服务端发起的,所以它能够请求到与它相连而与外网隔离的内部系统),如果没有对目标地址做过滤与限制时就会出现SSRF。

(3)代码规范:尽量不要使用服务器端请求的方式获取相关内容,如无法避免,服务器端对前端传来的 URL 进行请求时,需验证 URL 的可靠性,根据白名单策略进行过滤。

例如:URL url = new URL(check(uri)); 定义check白名单校验功能

3、针对“XXE”漏洞

(1)定义及风险:XXE全称为XML External Entity attack;当XML解析时由于引用不可信的外部实体造成命令执行漏洞。

(2)代码规范:解析XML时禁止外部实体

DocumentBuilderFactory domfac = DocumentBuilderFactory.newInstance();

domfac.setExpandEntityReferences(false);

4、针对“跨站XSS”漏洞

(1)定义及风险:攻击者利用应用程序的动态展示数据功能,在html页面里嵌入恶意代码(如:“”)。当用户浏览该页之时,这些嵌入在html中的恶意代码会被执行,用户浏览器被攻击者控制,从而达到攻击者的特殊目的。

(2)代码规范:

1)node语言

如果node采用了nunjucks 模版(目前大部分业务都采用该模板),那么node主文件的 nunjucksConfig配置中设置autoescape: true或者不做任何设置,nunjuck输出的所有数据都会进行XSS转义。

当输出内容为富文本的时候,可以局部关闭nunjuck转义功能。

如果node功能没有采用nunjuck模版,那么可以在render渲染view的环节进行数据递归遍历转义,采用node开源模块xss-escape。

针对富文本,采用代码清洗的思路,即保留正常的html标签入:

等的代码格式,针对攻击性的js代码进行格式转义,具体实现方式为:在render渲染环节,针对数据进行遍历递归转义。

2)java语言

非富文本:采用escape转义

富文本:采用owasp antisamy

3)在javascript内容中输出的“用户可控数据”,需要做javascript escape转义”。

5、针对“flash”漏洞

(1)定义及风险:利用flash服务端和客户端在安全配置和文件编码上的问题,导致攻击者可以利用客户端的flash文件发起各种请求或者攻击客户端的页面。

(2)代码规范:

1)Crossdomain.xml的安全配置

如果没有flash应用,去掉crossdomian.xml文件,对有flash应用域的根目录下需要配置crossdomain.xml策略文件,设置为只允许来自特定域的请。不允许添加,这样会导致客户端可能自己加载自定义策略文件

2)客户端嵌入flash文件的安全配置:

A.禁止设置flash的allowscriptaccess为always,必须设置为never,如果设置为SameDomain,需要客户可以上传的flash文件要在单独的一个域下

B.设置allowNetworking选项为none

C.设置allowfullscreen选项为false

6、针对“跨站请求伪造CSRF”漏洞

(1)定义及风险:攻击者在用户浏览网页时,利用页面元素(例如img的src),强迫受害者的浏览器向Web应用程序发送一个改变用户信息的请求。

(2)代码规范:

1)用户登陆时,设置一个CSRF的随机TOKEN,同时种植在server的session中。

2)生成表单的同时,推送TOKEN值。

3)表单提交,判断token是否一致,如果不一致或没有这个值,判断为CSRF攻击,并记录日志 ,如一致就放行,并重新生成下一个新的token。

4)重要操作增加二次图片验证码或滑动验证码等。

5)致命操作使用二次密码验证或人脸识别等。

7、针对“URL跳转”漏洞

(1)定义及风险:Web应用程序接收到用户提交的URL参数后,没有对参数做“可信任URL”的验证,就向用户浏览器返回跳转到该URL的指令。

(2)代码规范:建议采取下列两种方案的其中之一进行开发 方案一:

1)当用户访问需要生成跳转URL的页面时,首先生成随机token,并放入cookie。

2)在显示连接的页面上生成URL,在URL参数中加入token(http://china.youzan.com/member/sigin.htm?done=http://www.youzan.com&token=5743892783432432)

3)应用程序在跳转前,判断token是否和cookie中的token一致,如果不一致,就判定为URL跳转攻击,并记录日志

4)如果在javascript中做页面跳转,需要判断域名白名单后,才能跳转。

方案二:

如果应用只有跳转到Youzan网站的需求,可以设置白名单,判断目的地址是否在白名单列表中,如果不在列表中,就判定为URL跳转攻击,并记录日志。不允许配置Youzan以外网站到白名单列表中。

8、针对“SQL注入”漏洞

(1)定义及风险:当应用程序将用户输入的内容,拼接到SQL语句中,一起提交给数据库执行时,就会产生SQL注入威胁。

(2)代码规范:

1)使用预处理执行SQL语句

2)如果使用的是mybatis那么所有的变量必须使用#符号;如果特殊应用必须使用$的情况,必须确保变量完全来源于系统内部或代码定义好的固定常量

9、针对“代码注入”漏洞

(1)定义及风险:web应用代码中,允许接收用户输入一段代码,之后在web应用服务器上执行这段代码,并返回给用户。由于用户可以自定义输入一段代码,在服务器上执行,所以恶意用户可以写一个远程控制木马,直接获取服务器控制权限,所有服务器上的资源都会被恶意用户获取和修改,甚至可以直接控制数据库。

(2)代码规范:执行代码的参数,或文件名,禁止和用户输入相关,只能由开发人员定义代码内容,用户只能提交“1、2、3”参数,代表相应代码。

10、针对“XML注入”漏洞

(1)定义及风险:XML是存储数据的地方,如果在查询或修改时,如果没有做转义,直接输入或输出数据,都将导致XML注入漏洞。攻击者可以修改XML数据格式,增加新的XML节点,对数据处理流程产生影响。

(2)代码规范:在XML保存和展示前,对数据部分,单独做xml escape。

11、针对“系统命令注入”漏洞

(1)定义及风险:系统命令执行攻击,是指代码中有一段执行系统命令的代码,但是系统命令需要接收用户输入,恶意攻击者可以通过这个功能直接控制服务器。

(2)代码规范:所有需要执行的系统命令,必须是开发人员定义好的,不允许接收用户传来的参数,加入到系统命令中去。

12、针对“任意文件上传”漏洞

(1)定义及风险:Web应用程序在处理用户上传的文件时,没有判断文件的扩展名是否在允许的范围内,就把文件保存在服务器上,导致恶意用户可以上传任意文件,甚至上传脚本木马到web服务器上,直接控制web服务器。

(2)代码规范:

1)检查上传文件扩展名白名单,不属于白名单内,不允许上传。

2)上传文件的目录必须是http请求无法直接访问到的。如果需要访问的,必须上传到其他(和web服务器不同的)域名下,并设置该目录为不解析jsp等脚本语言的目录。

3)上传文件要保存的文件名和目录名由系统根据时间生成,不允许用户自定义。

4)图片上传,要通过处理(缩略图、水印等),无异常后才能保存到服务器。

13、针对“任意文件下载”漏洞

(1)定义及风险:处理用户请求下载文件时,允许用户提交任意文件路径,并把服务器上对应的文件直接发送给用户,这将造成任意文件下载威胁。如果让用户提交文件目录地址,就把目录下的文件列表发给用户,会造成目录遍历安全威胁。

(2)代码规范:

1)要下载的文件地址保存至数据库中。

2)文件路径保存至数据库,让用户提交文件对应ID下载文件。

3)下载文件之前做权限判断。

4)文件放在web无法直接访问的目录下。

5)不允许提供目录遍历服务。

14、针对“垂直权限安全”漏洞

(1)定义及风险:由于应用程序没有做鉴权,或鉴权做的比较粗,导致的恶意用户可以通过穷举遍历管理页面的URL,就可以访问或控制其他角色拥有的数据或管理功能,达到权限提升目的。

(2)代码规范:采用细粒度鉴权策略,判断当前用户是否拥有功能的权限,如果没有权限,就判定为“权限提升”攻击。

15、针对“水平权限安全”漏洞

(1)定义及风险:应用程序根据用户提交的ID(如订单id、userid、余额id等),在没有校验身份的情况下,直接返回用户信息,从而会造成攻击者越权遍历所有其他用户信息的问题。

(2)代码规范:涉及到用户数据的操作应进行严格的身份校验,可以从服务端登录态cookie或session信息中取值校验,禁止通过用户提交的ID信息直接进行数据操作。

16、针对“Cookie http only”漏洞

(1)定义及风险: Cookie http only,是设置COOKIE时,可以设置的一个属性,如果COOKIE没有设置这个属性,该COOKIE值可以被页面脚本读取。

(2)代码规范:

设置cookie时,加入属性即可,具体如下:

response.setHeader("SET-COOKIE", "user=" + request.getParameter("cookie") + "; HttpOnly");

17、针对“Cookie Secure”漏洞

(1)定义及风险:Cookie Secure,是设置COOKIE时,可以设置的一个属性,设置了这个属性后,只有在https访问时,浏览器才会发送该COOKIE。

(2)代码规范:

在设置认证COOKIE时,加入Secure,具体如下:

response.setHeader("SET-COOKIE", "user=" + request.getParameter("cookie") + "; HttpOnly ; Secure ");

18、针对“Session 有效期”漏洞

(1)定义及风险:由于Session没有在web应用中设置强制超时时间,攻击者一旦曾经获取过用户的Session,就可以一直使用。

(2)代码规范:在设置认证cookie中,加入两个时间,一个是“即使一直在活动,也要失效”的时间,一个是“长时间不活动的失效时间”。并在web应用中,首先判断两个时间是否已超时,再执行其他操作。

19、针对“伪随机性”漏洞

(1)定义及风险:如果使用Random()生成的图片验证码,那么根据前两个值就可以计算出来后面的所有随机值。

(2)代码规范:

1)在java中,推荐采用secureRandom()函数代替伪随机的Random()函数。该算法提供了强随机的种子算法(SHA1PRNG);

2)使用随机算法时,尽量将随机数种子复杂化,例如在以ServerTime作为随机种子时,在其后面加一个固定的“offside”整数值,这样可以有效避免被猜到随机种子的来源。

20、针对“弱加密强度”漏洞

(1)定义及风险:项目中设计到敏感信息的数据采用程序员自己编写的“简单算法”加密,一旦被人获取足够的“样本”,将有可能被反向推测出解密算法,从而泄露重要信息。

(2)代码规范:

1)不要将编码(如Base64)和密码算法混为一谈,前者不是密码算法。

2)不要使用低强度的密码算法,如DES、RC2等,必须采用符合业内安全强度标准的密码算法

21、针对“错误处理”漏洞

(1)定义及风险:在web应用程序出错时,会返回一些程序异常信息,从而暴露很多对攻击者有用的信息,攻击者可以利用这些错误信息,制定下一步攻击方案。

(2)代码规范:配置错误页面,让所有的错误都只显示友好信息,不显示任何与实际错误相关的信息。

22、针对“认证”漏洞

(1)定义及风险:如果没有严格的登陆认证策略极有可能遭到频繁的暴力破解、字典攻击。

(2)代码规范:

1)所有系统必须启用账号失败锁定策略(如:3分钟失败10次 锁定10分钟);

2)用户账号或密码错误时,返回的信息必须一致(如:您的账号或密码错误);

3)所有具备登陆功能的系统,必须同时具备注销或退出功能。

23、针对“验证码”漏洞

(1)定义及风险:登陆、注册、短信验证、邮件验证等api往往会成为攻击者撞库、轰炸的目标。

(2)代码规范:

1)登陆、注册、短信发送、邮件发送等环节必须加入图片验证码;

2)验证码必须设置有效期和有效次数(一般为一次性);

3)使用短信/邮件验证时,必须限制同一ID或接收者的验证码发送频率。

24、针对“明文传输”漏洞

(1)定义及风险:攻击者通过嗅探的方式很容易获取http中的所有数据。

(2)代码规范:

1)禁止使用http get的方式提交不安全算法处理过的账号密码;

2)禁止在http明文协议中传输任何敏感数据;

3)requst中字段尽量不要使用username、passpwrd等常见单词。

六. 规范的发布与更新

1、有赞云平台会在必要时调整本规范,且无需另行通知开发者,新的规范一旦公开即有效替代原来的规范,并对有赞、有赞云、开发者产生约束力。

2、本规范是开发者已经签署的《有赞云平台服务协议》等相关协议的一部分,与其有同等效力,自该规范发布之日起对有赞、有赞云、开发者产生约束力。

七.数据存储和使用规范

1、数据库命名规范

(1)所有数据库对象名称必须使用小写字母并用下划线分割

(2)所有数据库对象名称禁止使用mysql保留关键字(如果表名中包含关键字查询时,需要将其用单引号括起来)

(3)数据库对象的命名要能做到见名识意,并且最后不要超过32个字符

(4)临时库表必须以tmp为前缀并以日期为后缀,备份表必须以bak为前缀并以日期(时间戳)为后缀

(5)所有存储相同数据的列名和列类型必须一致(一般作为关联列,如果查询时关联列类型不一致会自动进行数据类型隐式转换,会造成列上的索引失效,导致查询效率降低)

2、数据库基本设计规范

(1)所有表必须使用Innodb存储引擎

没有特殊要求(即Innodb无法满足的功能如:列存储,存储空间数据等)的情况下,所有表必须使用Innodb存储引擎(mysql5.5之前默认使用Myisam,5.6以后默认的为Innodb)Innodb 支持事务,支持行级锁,更好的恢复性,高并发下性能更好

(2)数据库和表的字符集统一使用UTF8

兼容性更好,统一字符集可以避免由于字符集转换产生的乱码,不同的字符集进行比较前需要进行转换会造成索引失效

(3)所有表和字段都需要添加注释

使用comment从句添加表和列的备注 从一开始就进行数据字典的维护

(4)尽量控制单表数据量的大小,建议控制在500万以内

500万并不是MySQL数据库的限制,过大会造成修改表结构,备份,恢复都会有很大的问题

可以用历史数据归档(应用于日志数据),分库分表(应用于业务数据)等手段来控制数据量大小

(5)谨慎使用MySQL分区表

分区表在物理上表现为多个文件,在逻辑上表现为一个表 谨慎选择分区键,跨分区查询效率可能更低 建议采用物理分表的方式管理大数据

(6)尽量做到冷热数据分离,减小表的宽度

MySQL限制每个表最多存储4096列,并且每一行数据的大小不能超过65535字节 减少磁盘IO,保证热数据的内存缓存命中率(表越宽,把表装载进内存缓冲池时所占用的内存也就越大,也会消耗更多的IO) 更有效的利用缓存,避免读入无用的冷数据 经常一起使用的列放到一个表中(避免更多的关联操作)

(7)禁止在表中建立预留字段

预留字段的命名很难做到见名识义 预留字段无法确认存储的数据类型,所以无法选择合适的类型 对预留字段类型的修改,会对表进行锁定

(8)禁止在数据库中存储图片,文件等大的二进制数据

通常文件很大,会短时间内造成数据量快速增长,数据库进行数据库读取时,通常会进行大量的随机IO操作,文件很大时,IO操作很耗时 通常存储于文件服务器,数据库只存储文件地址信息

(9)禁止在线上做数据库压力测试

(10)禁止从开发环境,测试环境直接连接生成环境数据库

3、数据库字段和索引设计规范

(1)优先选择符合存储需要的最小的数据类型

(2)避免使用TEXT、BLOB数据类型,最常见的TEXT类型可以存储64k的数据

(3)避免使用ENUM类型

(4)尽可能把所有列定义为NOT NULL

(5)使用TIMESTAMP(4个字节)或DATETIME类型(8个字节)存储时间

(6)同财务相关的金额类数据必须使用decimal类

(7)限制每张表上的索引数量,建议单张表索引不超过5个

(8)禁止给表中的每一列都建立单独的索引

(9)每个Innodb表必须有个主键

4、数据安全

(1)明文风险:明文存储用户敏感数据,一旦发生内部泄漏,会对公司产生致命的威胁,可能造成刑事风险。

(2)加密存储:禁止数据库、日志文件中存储个人信息和敏感数据(如:用户姓名、电话、身份证、银行卡、邮箱地址、密码等),禁止使用不安全算法存储这些数据。

(3)保密要求:数据库管理员、数据库安全员、数据库审计员应签署保密协议。

(4)访问要求:正常的业务操作和数据维护,只能通过应用系统访问数据库。

此篇文档是否对你有帮助?
文档反馈