java.net.SocketPermission 中的奇怪通配符行为
Odd Wildcard Behavior in java.net.SocketPermission
我正在尝试使 Java 安全策略正确。我的代码需要解析并连接到 login.salesforce.com
和 xx99.salesforce.com
,其中 xx99
可以采用大约 100 个不同值中的任何一个。
如果我对特定主机进行硬编码,它会起作用 - 例如
permission java.net.SocketPermission "login.salesforce.com:443", "connect, resolve";
permission java.net.SocketPermission "na30.salesforce.com:443", "connect, resolve";
但这会导致我向我的安全策略文件添加大约 100 个条目以涵盖所有可能性,并且 Salesforce 一直在添加新实例,使维护成为一场噩梦。
如果我通配任何 host/port:
permission java.net.SocketPermission "*", "connect, resolve";
但明显的答案是失败的——这个
permission java.net.SocketPermission "*.salesforce.com:443", "connect, resolve";
给我
2016-03-20 22:19:56,024 [user:*admin] [pipeline:Pipeline1] [thread:preview-pool-1-thread-1] WARN Pipeline - Stage 'com_streamsets_stage_destination_waveanalytics_WaveAnalyticsDTarget_1' initialization error: java.security.AccessControlException: access denied ("java.net.SocketPermission" "login.salesforce.com:443" "connect,resolve")
java.security.AccessControlException: access denied ("java.net.SocketPermission" "login.salesforce.com:443" "connect,resolve")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1051)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
...etc...
已经盯着这个看一段时间了 - 我就是不明白!
所以 this question 引导我朝着正确的方向前进。通过 JDK 源代码,它解析主机名,然后进行反向查找,并进行一系列检查以防止欺骗。问题是 login.salesforce.com
...
让我们解决login.salesforce.com
:
$ dig login.salesforce.com
; <<>> DiG 9.8.3-P1 <<>> login.salesforce.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28719
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;login.salesforce.com. IN A
;; ANSWER SECTION:
login.salesforce.com. 2288 IN CNAME login.gslb2.salesforce.com.
login.gslb2.salesforce.com. 57 IN A 136.147.59.44
login.gslb2.salesforce.com. 57 IN A 136.147.57.172
login.gslb2.salesforce.com. 57 IN A 136.147.58.44
login.gslb2.salesforce.com. 57 IN A 136.147.58.172
好的 - 让我们对第一个 IP 地址进行反向查找:
$ nslookup 136.147.59.44
Server: 192.168.69.1
Address: 192.168.69.1#53
Non-authoritative answer:
44.59.147.136.in-addr.arpa name = dcl7-dfw.login-dfw.salesforce.com.
Authoritative answers can be found from:
嗯 - 好的,让我们解析主机名:
$ dig dcl7-dfw.login-dfw.salesforce.com
; <<>> DiG 9.8.3-P1 <<>> dcl7-dfw.login-dfw.salesforce.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26165
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;dcl7-dfw.login-dfw.salesforce.com. IN A
;; Query time: 35 msec
;; SERVER: 192.168.69.1#53(192.168.69.1)
;; WHEN: Thu Apr 28 13:25:56 2016
;; MSG SIZE rcvd: 51
此时,JDK 尝试将其持有的 IP 地址 (136.147.59.44
) 与通配符策略 (*.salesforce.com
) 进行比较,不出所料,确定它们没有t 匹配。
所以,我在政策中坚持使用“*”。
我正在尝试使 Java 安全策略正确。我的代码需要解析并连接到 login.salesforce.com
和 xx99.salesforce.com
,其中 xx99
可以采用大约 100 个不同值中的任何一个。
如果我对特定主机进行硬编码,它会起作用 - 例如
permission java.net.SocketPermission "login.salesforce.com:443", "connect, resolve";
permission java.net.SocketPermission "na30.salesforce.com:443", "connect, resolve";
但这会导致我向我的安全策略文件添加大约 100 个条目以涵盖所有可能性,并且 Salesforce 一直在添加新实例,使维护成为一场噩梦。
如果我通配任何 host/port:
permission java.net.SocketPermission "*", "connect, resolve";
但明显的答案是失败的——这个
permission java.net.SocketPermission "*.salesforce.com:443", "connect, resolve";
给我
2016-03-20 22:19:56,024 [user:*admin] [pipeline:Pipeline1] [thread:preview-pool-1-thread-1] WARN Pipeline - Stage 'com_streamsets_stage_destination_waveanalytics_WaveAnalyticsDTarget_1' initialization error: java.security.AccessControlException: access denied ("java.net.SocketPermission" "login.salesforce.com:443" "connect,resolve")
java.security.AccessControlException: access denied ("java.net.SocketPermission" "login.salesforce.com:443" "connect,resolve")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1051)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
...etc...
已经盯着这个看一段时间了 - 我就是不明白!
所以 this question 引导我朝着正确的方向前进。通过 JDK 源代码,它解析主机名,然后进行反向查找,并进行一系列检查以防止欺骗。问题是 login.salesforce.com
...
让我们解决login.salesforce.com
:
$ dig login.salesforce.com
; <<>> DiG 9.8.3-P1 <<>> login.salesforce.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28719
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;login.salesforce.com. IN A
;; ANSWER SECTION:
login.salesforce.com. 2288 IN CNAME login.gslb2.salesforce.com.
login.gslb2.salesforce.com. 57 IN A 136.147.59.44
login.gslb2.salesforce.com. 57 IN A 136.147.57.172
login.gslb2.salesforce.com. 57 IN A 136.147.58.44
login.gslb2.salesforce.com. 57 IN A 136.147.58.172
好的 - 让我们对第一个 IP 地址进行反向查找:
$ nslookup 136.147.59.44
Server: 192.168.69.1
Address: 192.168.69.1#53
Non-authoritative answer:
44.59.147.136.in-addr.arpa name = dcl7-dfw.login-dfw.salesforce.com.
Authoritative answers can be found from:
嗯 - 好的,让我们解析主机名:
$ dig dcl7-dfw.login-dfw.salesforce.com
; <<>> DiG 9.8.3-P1 <<>> dcl7-dfw.login-dfw.salesforce.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26165
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;dcl7-dfw.login-dfw.salesforce.com. IN A
;; Query time: 35 msec
;; SERVER: 192.168.69.1#53(192.168.69.1)
;; WHEN: Thu Apr 28 13:25:56 2016
;; MSG SIZE rcvd: 51
此时,JDK 尝试将其持有的 IP 地址 (136.147.59.44
) 与通配符策略 (*.salesforce.com
) 进行比较,不出所料,确定它们没有t 匹配。
所以,我在政策中坚持使用“*”。