pc4beginnerの日記 はてなブログ版

はてなダイアリーで書いていたブログの移行です。

JRE1.6.0_29を使うと、リモートスクリプトの処理が動かない

JavaVMの該当バージョンを使うと、リモートスクリプトの処理が動かなくなって困ってます。


で、やっとJavaのユーザーフォーラムでそれっぽい情報が上がってきたので翻訳をしておきます。
https://forums.oracle.com/forums/thread.jspa?threadID=2300917&tstart=0
※2011/10/27 9:50 の投稿を参照
なお、英検三級(数十年前)、Javaは門外漢の人間が翻訳してるので突っ込みどころがあればコメントいただければ直ぐに直します。


ざっくりまとめると、Javaが同一生成元ポリシー(SOP)というweb標準の考え方に即してないところがあって(どうやらこれがセキュリティホールだったみたい)、そいつの修正を実施したらバグが出てしまった、と。
ただし挙動としてはSOPに準拠したものなので、その考え方ではバグじゃないよと最期の一文で言い訳してます。
このバグは1.7にも含まれると書いてあります。

ちなみにこのセキュリティホールについてはUSで一般公開されている脆弱性情報データベース(CVE、http://ja.wikipedia.org/wiki/%E8%84%86%E5%BC%B1%E6%80%A7%E6%83%85%E5%A0%B1%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9)で取り挙げられているもので(CVE-2011-3555で検索して下さい。英文しか出てこないけど)、SSL認証に関わるものなのでJavaだけでなく、SSL通信を利用するアプリは全て緊急の対策を行っているみたいです。


では翻訳開始。

In JDK 6u29 a change was made to bring Java into closer alignment with the web Same Origin Policy.

JDK6u29の変更は、Javaにwebの同一生成元ポリシー(http://keicode.com/script/jsonp-same-origin-policy.php)と整合をもたらすために行われました。

In some cases this has caused existing applications to break.
The problem manifests when secure cookies are expected to be sent over an insecure connection.

場合によっては、これは既存のアプリケーションが中断する原因となっています。
問題は、セキュリティで保護されたcookieが安全性が保証されない接続を介して送信することが予想される場合に現れます。

If you application depends on this behavior you will need to sign the application.
In addition, if the request originates via a LiveConnect (javascript) call then it will need to be wrapped in a doPriviliged() block as javascript calls are treated as untrusted and do not carry the same protection domain.

もしアプリケーションがこの動作に依存している場合は、アプリケーションに署名する必要があります。
加えて、LiveConnect(javascript)を介してリクエストが発信する場合、同じ保護ドメインを持っていないjavascriptの呼出の処理と同じようにdoPriviliged() blockでラップする必要があります。

I realize that if your application uses just the Microsoft RSProxy class for remote scripting this isn't a likely solution for you.
We're still looking at this.

私はアプリケーションがremote scriptingにマイクロソフトのRSProxyクラスを使用する場合、この方法は解決策にはならない可能性が高いと認識している。
これについては我々はまだ調査中だ。

=== and ===

I wanted to let everyone know that the latest builds of the JRE (to be released in December) have the fix for this problem incorporated.
The latest build of 6u30 is at http://jdk6.java.net/6uNea.html.

そして。

私は皆さんにJREの最新ビルドが(12月にリリース予定)にこの問題の修正プログラムが組み込まれていることを知ってもらいたい。
6u30の最新のビルドはhttp://jdk6.java.net/6uNea.htmlにあります。

The background on this is:

  • We made a change in 6u29 to improve security in regards to the same origin policy (SOP), bringing Java into better alignment with the web standard (while trying not to break existing applications).
  • There is a bug where calls from Javascript (via "LiveConnect") to applets did not carry the same protection domain as the applet. This is what has been corrected in the latest early access builds of JRE 6 and 7. Sorry about that!
  • If (your application is unsigned OR you call a method via Javascript that attempts to access a secure cookie) we now check that the application is served from the same domain via httpS. If not you will still get this error, and that is the expected behavior because it's clearly a violation of the SOP.

当件の背景::

  • 我々は(既存のアプリケーションを破壊しないよう検討しているとき)JavaWeb標準により則するように、同一生成元ポリシー(SOP)に配慮して、セキュリティを向上させるために6u29の変更を行いました。
  • アプレットへの(LiveConnect経由の)Javascriptからの呼び出しが、アプレットと同じ保護ドメインを持っていないバグがありました。これは、最新のJRE 6と7のビルドで修正されたものです。ごめんね!
  • (アプリケーションが認証の無い状態、もしくはJavascriptを経由してセキュリティで保護されたcookieにアクセスしようとするメソッドを呼び出す)場合、Javaは、現在アプリケーションがHTTPS経由で同じドメインから提供されていることを確認します。そうでない場合でも、このエラーが表示されます、そしてそれは明らかにSOPの違反だからそれは正常な動作です。

Hope that helps.

私のこの助言が役に立つことを祈る


だ、そうです。
ごめんね!って。。。


今日はそんな感じで。

(2011/11/01追記)
バグデータベースにも情報がありました。
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7102914

これの翻訳は又今度。。。。

(2011/12/14追記)
12/12リリースのupdate30でこの問題が解消されました。リリースノートの翻訳はこちら。→http://d.hatena.ne.jp/pc4beginner/20111214