16

A common Java security guideline for handling sensitive data (== passwords) recommends never using a String object to store the data, and instead using an array of bytes or chars. I am trying to apply this guideline in a HttpServlet handler. In particular, I am using a basic-authentication-like approach where the credentials are passed in in a header (this is a GET request, so no body).

The issue I'm running into is that it seems impossible to get to the header data without generating a String object, which violates the guideline from the get-go. I've searched for a solution pretty thoroughly, and didn't find any relevant discussion. Does anybody have any insight into this issue?

NOTE: this takes place over HTTPS, so there is no connection security problem here.

4

1 に答える 1

16

簡単な答えは、文字列以外の形式でパラメーターを取得できないということです。少なくとも、標準のサーブレット API は使用しません。しかし、いくつかの「抜け出す」可能性があります。

  1. 本当に醜いことを覚悟しているなら、実際には String オブジェクトの抽象化を破り、文字に手を伸ばして上書きすることができます。(ルールを破る準備ができている場合、実際には文字列は変更可能です。これは、これが正当化される数少ない状況の 1 つです。)

  2. これを行うための (たとえば) の Web コンテナーの実装には、非標準の API 拡張機能が含まれている可能性がありますHttpServletRequest。そうでない場合は、ソース コードを入手して追加できる場合があります。(オープンソースの Web コンテナーを使用していると仮定します。)

そうは言っても、IMO の Java セキュリティへの「文字列なし」アプローチは見当違いであるか、少なくともそれが達成することに関して過大評価されています。

「文字列なし」アプローチは、何かがアプリケーションのアドレス空間をトロールし、文字列のように見えるものを見つけ、可能性のあるパスワードを盗み出す可能性を防ぎます。理論的には、これは次の方法で実行できます。

  • JVM の実行モデルを壊し、生のメモリを調べるハック、
  • Java デバッガーを接続し、到達可能なオブジェクトをトロールします。
  • 「/dev/mem」などを使用して外部からプロセスメモリを読み取り、
  • ハードドライブ上のプログラムのスワップイメージの残りにアクセスする、または
  • どういうわけかコアダンプを引き起こし、ダンプを読み取ります。

ただし、これらのうち最初のものを除くすべての場合、悪者がシステムのセキュリティをすでに破っている必要があります。そして、悪者があなたのプログラムからパスワードを盗む他の (おそらくもっと簡単な) 方法があるとしたら、「文字列なし」のアプローチでは防げません。

また、Java のセキュリティ上の欠陥を悪用して raw メモリを読み取るハッキングが心配な場合、その欠陥はおそらく他の方法で使用される可能性があります。たとえば、コードを挿入して、コードによるパスワードの処理方法を変更します。

要約すると、「文字列なし」は、非常に困難なハッキングや、セキュリティがすでに吹き飛ばされているケースから保護します。IMO、努力する価値はありません...ミリタリーグレードのセキュリティを実装する必要がない限り.

于 2013-02-22T03:48:32.290 に答える