开发安全规约(三)——XML最佳安全实践
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了开发安全规约(三)——XML最佳安全实践相关的知识,希望对你有一定的参考价值。
参考技术AXML 指可扩展标记语言(EXtensible Markup Language),是一种标记语言,很类似 html。其设计宗旨是传输数据和存储数据。
DTD指文档类型定义(Document Type Definition),用于声明实体来定义变量(或是文字类的宏),以便在接下来的DTD或者XML文档中多次使用。
ENTITY实体:一般实体用来访问内部资源,而外部实体用来访问外部资源。在解析外部实体的过程中,XML的分析器支持众多网络协议和服务(DNS,FTP,HTTP,SMB等等),这取决于URLs的值。
XML在Java中分两种解析方式:
如上图实体 lol9 由 10 个 lol8 组成,由此类推,lol9 为 一亿 个 lol 组成。一个小于1K的XML能消耗3.5G内存。若 lol 定义的字符更长,或阶层更多,可瞬间使服务器宕机。
XML组件默认允许 XML 文档包含来自外部 URI 的数据,例如包含本地计算机或远程系统上的某个文件。当接受用户的输入作为文档的一部分动态构建XML时,防护不当可能导致:
XML支持用XPath查询语句,如: //users/user[loginID/text()=’user’ and password/text()=’pwd’] ,若未严格验证输入,就容易被注入攻击(类似SQL注入)。如: //users/user[loginID/text()=\'admin\' and password/text()=\'\' or 1=1 or \'\'=\'\']
1、若在使用XML时, 无需使用内联文档类型声明,请禁止DTD ,可规避拒绝服务和外部实体注入攻击。
2、若 需要使用内联文档类型,请开启安全进程 ,可避免多层嵌套引起的拒绝服务攻击。
3、若 需要使用内联文档类型,还需要限制实体类型(需JDK7+) 。
4、若 需要使用XPath进行查询 ,请使用 ESAPI.encoder().encodeForXPath(xpath) 对用户输入进行转义。
Nacos配置安全最佳实践
前言
Nacos 配置架构
-
通过 Nacos-client 获取配置。 -
通过控制台获取配置。 -
通过服务器之间的通信协议获取配置。 -
直接访问持久化层(比如 DB)获取配置。
|
|
|
|
|
|
|
|
|
|
|
不需要 |
|
|
不需要 |
Nacos 客户端场景的认证和鉴权
开源版本的 Nacos
nacos.core.auth.enabled=true
String serverAddr = "{serverAddr}";
Properties properties = new Properties();
properties.put("serverAddr", serverAddr);
properties.put("username","nacos-readonly");
properties.put("password","nacos");
ConfigService configService = NacosFactory.createConfigService(properties);
阿里云 MSE-AK/SK
第一步:创建 RAM 权限策略如下:
第二步:创建用户并赋予权限:
最后,只需要在代码中添加 AK/SK 就可以了:
String serverAddr = "{serverAddr}";
Properties properties = new Properties();
properties.put("serverAddr", serverAddr);
properties.put(PropertyKeyConst.ACCESS_KEY, "${accessKey}");
properties.put(PropertyKeyConst.SECRET_KEY, "${secret}");
ConfigService configService = NacosFactory.createConfigService(properties);
阿里云 MSE- 基于 ECS 的 Ram 角色认证
第一步,创建 MSE Nacos 实例,并创建对应的权限策略(上文有说明,此处不赘述)。
第二步,创建 RAM 角色并授权。
第三步,将该角色和 ECS 关联:
最后一步,在代码中 指定 RAM 角色 即可:
String serverAddr = "{serverAddr}";
Properties properties = new Properties();
properties.put("serverAddr", serverAddr);
properties.put(PropertyKeyConst.RAM_ROLE_NAME, "StoreServiceRole");
ConfigService configService = NacosFactory.createConfigService(properties);
经过如上配置,Nacos 客户端在获取配置时,云服务器会扮演指定的 RAM 角色,阿里云临时安全令牌(Security Token Service,STS)来访问 MSE Nacos 实例。
如果攻击者获取代码,也无法在其他机器上运行,因为攻击者的机器没有扮演 RAM 角色的权限。
如果攻击者获取扮演之后的认证信息,由于 STS 失效较短(默认是1小时),攻击者拿到后很快就失效,有效减少了攻击面。
如果需要撤销授权,只需要在阿里云控制台上就可以操作,不需要重新发布应用。
相比于 AK/SK 方式的认证鉴权,ECS 关联角色的认证鉴权更可控、更安全,所以推荐使用这种认证鉴权方式。
配置控制台场景的认证和鉴权
开源版本的 Nacos
开源版本的 Nacos 控制台,在登录的时候,会通过控制台的 login 接口,获取临时的 accessToken,然后后续的操作,都是以 accessToken 来做认证鉴权。
比如前文提到的 readonly-user 用户,登录后,就只能看到 public 命名空间下的配置信息,无法修改、无法查看其他命名空间下的配置信息。
另外,如果需要创建命名空间、删除命名空间,则只能管理员登录才可以。
开源版本 Nacos 的认证鉴权,可以参考该文档:https://nacos.io/zh-cn/docs/auth.html。
阿里云 MSE
|
|
|
|
|
|
|
|
|
|
|
|
|
|
比如,只允许读取一个命名空间下的配置,不允许修改。那权限策略就可以写:
{
"Action": [
"mse:Get*",
"mse:List*",
"mse:Query*"
],
"Resource": [
"acs:mse:*:*:instance/${instanceId}/${namespaceId}"
],
"Effect": "Allow"
}
服务器之间的认证
Nacos 服务器之间需要同步一些信息,这时也需要认证对方身份,以确认对方真的是 Nacos-server,而不是伪装的。
nacos.core.auth.enable.userAgentAuthWhite=false
nacos.core.auth.server.identity=Authorization
nacos.core.auth.server.identity.value=secret
Authorization: secret
的请求,
才能确认对方是服务端,才能同步集群信息;否则就拒绝同步。
持久化层的安全
-
将 Nacos server 访问数据库的用户从 UserA 切换到 UserB。 -
更新 UserA 的密码。 -
将 Nacos server 访问数据库的用户从 UserB 切换回UserA。 -
更新 UserB 的密码。
配置安全最佳实践
捋了一遍 Nacos 配置安全的关键点,那么怎么才能保证配置安全呢。只需要做到如下最佳实践就可以了:
-
定时检查配置的监听列表,确认没有未授权的机器。 -
AK/SK 泄漏时,该如何更新 AK/SK,如何撤销泄漏的 AK/SK。 -
对于自建 Nacos,服务器被攻破后,如何修改 nacos.core.auth.server.identity.value 的方案。
总结
而对于中大型企业,阿里云产品 MSE 支持更加精细、更加灵活的权限配置、安全管理,也能利用和其他阿里云产品一起做到更加安全的配置能力。
招贤纳士
我们 Dubbo / Spring Cloud 商业化团队正在招人。除了 EDAS,我们还有 ARMS (应用实时监控服务)、MSE(微服务引擎)、SAE(Serverless 应用引擎)等独立产品。我们在忙什么?用心打磨这些产品,就是我们的工作。团队的目标是将阿里巴巴在服务治理上的最佳实践通过产品化的形式输出给阿里云上的企业客户,帮助客户实现业务永远在线。
以上是关于开发安全规约(三)——XML最佳安全实践的主要内容,如果未能解决你的问题,请参考以下文章