最新调整日期: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)访问要求:正常的业务操作和数据维护,只能通过应用系统访问数据库。