Java

[java]入力チェック-日付の妥当性のみでは脆弱性あり

kox@wankuma.com — Sun, 25 Oct 2009 20:04:00 GMT

最近、プロジェクトで発生した脆弱性関連の障害の話です。

入力データのチェックにはvalidatorなどを使うのが定番ですが、

このプロジェクトでは使用していません。

その場合入力データに対して、

SimpleDateFormatクラスなどを使用して#setLenient(false)、#parse(入力データ)をするかと思います。

ネットでも、このように書かれているものが多いみたいですね。

しかし、#parse()って前方一致なのです。

つまり、

入力文字列が「2009/10/23は給料日」という文字列も通り抜けてしまいます。

この日付の後ろの文字列が、javascriptだったら・・・。

この文字列を日付のみと疑わずエスケープせずに出力してしまったら・・・。

いくつかの状況が重なってしまうと、脆弱性につながってしまうという事例でした。

if条件判定はどちらがよい？（その２）

kox@wankuma.com — Fri, 15 Feb 2008 18:03:00 GMT

ネタ元：if条件判定はどちらがよい？（以前のブログエントリ（古い））
　　　　：文字列をequalsで判定する時(@IT)

いままで、僕は以前のブログに書いてあるように、
if(変数.equals("定数"))
のほうが、
if("定数".equals(変数))
より保守の観点では優れていると思っていました。
しかし、この考えが120度くらい変わってしまったので、
再エントリをすることにしました。

どちらのケースでも
nullの対応がきちんと行われているのであれば、それほど問題となりません。
しかし実際にはnullの考慮をし忘れて、不具合となるケースが少なくありません。

以前までの僕は、以下のように考えていました。
if(変数.equals("定数"))
を使用していれば、その箇所でNullPointerExceptionが発生するため安全です。
if("定数".equals(変数))
を使用してしまうと、nullの場合に処理をしないだけなので、
処理は正常に動作し、最悪の不具合の場合にはデータの破損や、
不具合箇所の特定が困難になります。

そして以下が考えを改めた理由です。
単純に
if(変数.equals("定数"))と使用していれば、
上記のようにバグはその時点でNullPointerExceptionが発生し問題ありません。
しかし多くの場合は、
if(変数!=null && 変数.equals("定数"))
と書かかれています。
まるで、枕詞のように頻繁に。
であるならば、
この書き方は、
if("定数".equals(変数))
と等しく、以前までの僕が懸念してきたことは、
まったく意味のないものとなってしまいます。

どちらの場合でも同じような懸念が残ってしまうのです。

意図的に
「変数!=nullを使わないようにし、変数.equals("定数")のみで記述するようにすれば・・・」
とも思いましたが、
そもそも意図的に「変数!=nullを使わない」部分に気をつけるのであれば、
「null時の対応を考慮し忘わすれない」部分に気をつけるべきなのだろうと考えました。

if(変数.equals("定数"))と
if("定数".equals(変数))を
比較したとき、
今までの考えと変わらず前者が安全だと思っています。
しかし
if(変数!=null && 変数.equals("定数"))と
if("定数".equals(変数))を
比較したとき、
後者のほうが分かりやすいと、僕は考えます。

考えた末出した結論は、
ケースバイケースで。
・・・
・・・
結論になってないですね。

どちらにしろ、この手の記述がある際には
その状況などを考慮し注意する必要があるぞと、
胸の奥にとどめておく程度でよいかと思います。

ダウンロードファイル名の文字化け（実際にはServlet名になる）

kox@wankuma.com — Thu, 10 Jan 2008 11:25:00 GMT

担当しているサイトのダウンロード機能のファイル名は文字化けが起こっていたのだが、
IE7になり、いつの間にか解消されていた。

ダウンロードファイル名の文字化け自体は、かなり有名な話で対応策などはそこら中サイトで見つけることができる。
ちなみにファイル名は日本語ではない。

この事象が発生していたのは、
WindowsXP IE6 SP2がでて間もない頃の話。

通常は、ファイル名を指定したい場合に
　response.addHeader( "Content-Disposition", "attachment; filename=ファイル名 );
とする。
しかしこの対応策は取れなかった。
Content-Disposition: attachment でファイルをダウンロードするとフレームが更新されなくなる。
この障害に見事にマッチし、回避策もとることはできなかった。
エンドユーザの大半はまだIE6 SP2を使用しておらず、
このエラーはランタイムエラーが発生してしまうため、使用するわけにはいかなかった。

結果として
　response.addHeader( "Content-Disposition", "inline; filename=ファイル名 );
とすることにした。
この場合、WindowsXP IE6 SP2 よりも前のバージョンであればファイル名を取得できるが、
WindowsXP IE6 SP2以降はファイル名を取得できない。
圧縮さえかかっていなければファイル名を取得できるのだが、
データ量が大きかったため圧縮をかける必要があった。
そのため、「まあ大きな害はないよね。」ということでこのまま運用することにした。

あれから数年。
IE7となり、気がつけばファイル名が取得されるようになっていた。
めでたし、めでたし。

バグの隠蔽化

kox@wankuma.com — Tue, 02 Oct 2007 16:42:00 GMT

public class Hoge
{
  ...いろいろなメソッド
  public void バグのあるメソッド()
  {
    ...
    ...
    バグのコード
    ...
  }
}

public class Piyo extends Hoge
{
  public void バグのあるメソッド()
  {
    ...
    ...
    バグのコードをなおしたソース
    ...
  }
}

Hogeクラスは共通クラスです。
Piyoクラスは、Hogeクラスを継承し、バグのメソッドのみ修正しています。
Piyoクラスを使用することで、バグを回避し、Hogeクラスと同様の機能を使用することができます。
ってバグ直せよ！

というプログラムを見かけることがあります。
Hogeクラスが修正できない状況なら分からなくもないのですが・・・ブツブツ

parseIntの挙動

kox@wankuma.com — Thu, 23 Aug 2007 11:26:00 GMT

凪瀬さんの以前のエントリで、
自分もはまった事あったなと思いつつ、どんなんだったけ？と思っていました。
それを先日思い出しましたので、備忘録として残しておこうかと思います。

javaのInteger.parseInt()とjavascriptのparceInt()の8進数に関する挙動。
java：

  Integer.parceInt( "08" );      //8を返す。
  Integer.parceInt( "08", 10 );  //8を返す。
  Integer.parceInt( "08",  8 );  //NumberFormatExceptionを返す。

javascript：

  parseInt( "08" );              //0を返す。
  parseInt( "08", 10 );          //8を返す。
  parseInt( "08", 8 );           //0を返す。
  parseInt( "8",  8 );           //NaNを返す。

javascriptでは計算処理をする場合に注意が必要。

メール配信した内容とDB内容不一致の不具合事例

kox@wankuma.com — Mon, 06 Aug 2007 13:36:00 GMT

仕様：
顧客ごとに商品情報をDB更新し、各顧客に対して変更内容をメール配信する。

ソース：
List list = 顧客リスト;
for( int i=0; i<list.size(); i++ ){
update( list.get(i) ); //顧客ごとに商品情報をDB更新
sendMail( list.get(i) ); //顧客ごとに更新した商品情報をメール配信
}

2件目以降のupdate処理中に、何かしらの理由でExceptionが発生し、
トランザクションはrollbackされたが、既にメールは配信してしまっているため、データの不整合が発生。

直接的な原因は、「何かしらの理由でExceptionが発生」したことにあります。
そして、この障害を取り除けば、処理としては正常に流れます。

しかし実装方法として適切かどうかというと疑問が残ります。
このような実装をしているということは、
おそらく、トランザクションの適用範囲が考慮されていません。
そして、今後も似たような障害が発生するたびに、同じ状況が発生することになります。

直接的な修正だけでは、根本解決にならないという事例ですね。

if条件判定はどちらがよい？

kox@wankuma.com — Thu, 12 Jul 2007 12:48:00 GMT

if( 文字列定数.equals( 変数 ){
}
と
if( 変数.equals( 文字列定数 ){
}

書き方の違う２つの似たif文がありますが、
どちらが保守に強い書き方なのでしょうか。

２つの動作の大きな違いとして、
前者はNullPointerExceptionは発生しないが、
後者はNullPointerExceptionは発生する可能性があります。

前者の場合は、変数にたとえNullが入っていたとしても、処理を継続します。
実行時エラーは発生しません。（少なくともこの段階では））
Nullの場合はそもそも意図した処理をする必要がないため、
Nullであろうがなんだろうが気にしません。

後者の場合は、変数にNullが入ってきた場合の処理を考える必要があります。
NullPointerExceptionを投げられたら嫌ですもん。
ですから、通常Nullである可能性がある場合は、

if( 変数 != null && 変数.equals( 文字列定数 ) ){
}

と言ったような書き方をします。

上記のような書き方は、実はどちらもNullを考慮したつくりになっています。
Nullが入ってくることを許容したつくりですね。
その場合は確かに前者の方が優れているといえそうです。

次にNullを許容していない場合を考えてみます。
前者の場合は、Nullを許容してしまっているので、処理はされませんがエラーにもなりません。
実行時エラーを出さないのも大切ですが、
意図しない結果をエンドユーザに出力してしまうほうが問題です。
エラーとならないので、最終的な処理結果が意図していたものと違うかどうかが分からず
障害が発生した場合のエラー箇所の特定が困難になります。
#まあ言ってしまえば前者自体がバグなのですが。
後者の場合は、NullPointerExceptionを投げます。
例外を投げるので、エラー箇所を特定することも容易です。
ここより前の段階で何かしらの理由で変数にNullが含まれたことが明らかだからです。

結論として、どちらのif文を使用するかはケースバイケースと言うことになりますが、
状況によりどちらのケースが適切であるかを考えるよりも
Nullの許容有無に関わらず使用できる後者ほうが、保守に強いといえるかもしれません。

LOG出力によるパフォーマンス遅延

kox@wankuma.com — Tue, 03 Jul 2007 11:58:00 GMT

ログの過度な出力はパフォーマンスに影響を与えるので注意が必要です。
「そんなの当たり前だ」という声も聞こえてきそうですが、
以下は結構見受けられる間違いです。

Log4Jを使った例を示します。
通常は本番用と開発用のログを分けるためにログレベルを設定します。
そして開発用としてはdebugレベルを使用しますよね。

  logger.debug("Hello World");

この程度の内容であれば、あまり問題視することもありませんが、

  List list = new ArrayList();
  list.add();
  ....（省略）
  logger.debug(list.toString());

としている場合があります。この場合、listの大きさによって大きな負荷が生じます。
#debug()の引数になにを入れるかによって、その性能に差が生じてしまうということです。
面倒ですが必ず

  if( logger.isDebugEnabled ){
    logger.debug(list.toString());
  }

とする必要があります。