雇用調整助成金のオンライン受付システムの不具合、「戻る」で他社の情報を閲覧できる状態に 25
ストーリー by hylom
網羅的なテストは大変だ 部門より
網羅的なテストは大変だ 部門より
公開後すぐに不具合が発生したために停止され、その後再公開されるもまたすぐ不具合が確認されて再び停止していた厚生労働省の雇用調整助成金オンライン受付システムだが、再停止になった原因はWebブラウザで特定の画面を閲覧中に「戻る」操作を行うと特定の事業者の申請内容を表示するようになっていたためだという(ITmedia、NHK、日経xTECH)。
表示される情報には役員や従業員の氏名、生年月日、給与、法人の口座情報などが含まれていたとのこと。申請書類をダウンロードすることもできたようだ。厚生労働省はテストが不十分だったとしており、また不具合があるとして停止された最初のバージョンでもこの不具合が発生していた可能性が高い。
このシステムは富士通が約1億円で受注したもので、開発・保守・テストをそれぞれ3社に外注していた。
むかしの社内システム (スコア:0)
昔の社内システムは、IEのみ対応で、「戻る」を無効化してたりするので、
戻ることが不可能だったりした
複数ブラウザ対応だと、「戻る」の無効化とか無理だからな
Re: (スコア:0)
なぜ素直に「戻る」ボタンに対応しないんだ?
そんなに遷移の処理ができないのか?
Re:むかしの社内システム (スコア:1)
なぜ素直に「戻る」ボタンに対応しないんだ?
そんなに遷移の処理ができないのか?
技術的にはできても、予算的にできないこと、あるよね。
全ルートでのページごとに「戻る」を押すテスト、工数結構かかる。
Re: (スコア:0)
全ルートでのページごとに「戻る」を押すテスト
工数はかかるが、そもそもそんなやり方の全ルートのテストは金のないシステムに不要。
Re: (スコア:0)
「戻る」って実際なんなんだろうな。
俺はECサイトのカート情報はアプリサーバーのセッションにあるだろうから、戻って画面表示が購入前になってもそこが変わらないだろうと考えるけど、一般的にそれは正しいとみなされるだろうか。
SPAなサイトは作ったことないけど、SPAにおける戻るはサイトの状態がどこまで戻すのかベストプラクティスがあるのだろうか。
Re:むかしの社内システム (スコア:1)
そもそもここでいう戻るは「ブラウザ」の戻るなので、
そもそもWEBアプリケーション側で動作を定義なんてできない。
ブラウザ毎の仕様により動作が変わってしまうので、
アプリケーションとしては一律同一制限のボタン禁止か、不正遷移エラーに寄せるしかない。
教えて偉い人 (スコア:0)
>「戻る」操作を行うと特定の事業者の申請内容を表示する
...一体どういうバグだったんだろう?
「戻るボタン」で「特定の」事業者の申請内容。
故意に表示させるのはできるけど、バグとなると、うーん、わからん。
Re: (スコア:0)
仕様バグ。
開発業者は仕様書通りに作っただけ。
テスト業者は[戻る]ボタンで特定事業者の申請内容を正しく表示することを確認しただけ。
保守業者は・・・・保守フェーズまで進行してないので仕事できていない(自粛中)。
Re: (スコア:0)
セッションidを単純にインクリメントかつ恒久的に使われるように実装しちゃって
戻った時にセッションidが無くて初期値の0番目の事業者の情報が表示されたとか?
Re: (スコア:0)
サーバサイドキャッシュでも入れてたんでは?
Re: (スコア:0)
それくらいしか考えつかないね。
Re: (スコア:0)
「戻るボタンで情報が漏洩するサイトを作ってみた」 by 徳丸浩 氏
https://www.youtube.com/watch?v=Aaig2d3m_cg [youtube.com]
Re: (スコア:0)
showpdf.php
session_start()する前にセッション変数を参照していて草生える
Re: (スコア:0)
ご指摘ありがとうございます。よく見ていますね。デモの後にソースコードの見栄えを修正した際のバグでした。github上のコードは修正しました。
https://github.com/ockeghem/web-sec-study/tree/master/browser-back-incident [github.com]
Re: (スコア:0)
キーが連番で、別のキーでテーブルからデータを引いてしまうバグはままあると思います。
その別のキーが戻る操作の時に特定の値になる、で今回の事象は起こり得ます。
まあそれ以前の話として、そういう事故を忌避する努力が行われていない設計であることが推察されます。
問題はそこですね。作り直さないとヤバそう。
Re: (スコア:0)
典型的な問題というのが想像出来なかったのだが
なるほど、自分の想像を大きく超える仕組みか、それじゃ想像無理だわw
単純に穴だけ防げば問題解決するものじゃなさそうですね
Re: (スコア:0)
ひとつめからして何言ってるのか分からんが…なんで連番だと他の値でデータを取りに行くの?
Re: (スコア:0)
「連番だと他の値でデータを取りに行く」とは書いていない。
例えばキーにUUIDを使用していればキーが誤っていてもデータがヒットせず、他のデータを引いてしまう結果の条件が成立しない、ということ。
Re: (スコア:0)
申請を受け付ける側の処理としては、一連のキューを処理していって前の申請書類を見たいと思うことはあるかも。
なので、ページをめくるように戻ったり進んだりする機能があるのでしょう。
そして、画面上のボタン類だけじゃなく、ブラウザの戻るを押してもページが戻るようになっていたんですよ、きっと。
ここまでなら親切適切な処理でしょう。
申請する側の画面でそれを無効にしてなかっただけでは。
それで、キューにある前の申請情報が見えてしまった、んじゃないかな?
Re: (スコア:0)
「前の」申請情報ならまだ分からなくもないんですよ。
「特定の」だから何故? ってなる。
Re: (スコア:0)
ふつうに、変数の初期化漏れの類かと思います。(見当違いかもしれませんが。)
(1)
開発段階でご都合がいいように、とりあえず、事業者IDを特定の事業者IDで「仮」初期化しておく
↓
運用段階で事業者IDの「本」初期化処理の漏れ(ブラウザの戻るボタン)で、特定の事業者の情報漏洩
(2)
ブラウザの戻るボタンを押す
↓
ランタイムエラーだ。(未初期化変数のnull参照)
↓
null以外にしておくか。変数を特定の事業者IDで初期化する
↓
画面が出た(とりあえず、ヨシ!)
なんだろ、これ、PMと開発者との間に、大きな亀裂があるように見える。正常に動いている様に見せることにこだわった結果か?
例のPMを思い出した人もいるのではなかろうか。
Re: (スコア:0)
PM「何でこんな状況になってるの!?毎日徹夜でも何でもして進捗上げて!」
↓
PM「よくやってくれた。ここまでできていれば後は大丈夫だ。あとは任せろ。」
↓
PM「ぜんぜんできていないじゃないか!!」
人月の神話からまるで進歩していない。偽装進捗の罠じゃないか。外野が想像する以上に、(典型的な)問題があるんじゃないの?
よく出来たデバッガー呼んで来いよ〜富士通 (スコア:0)
お下げの似合う、よくバグを見つけそうな子とかさ。
Re:よく出来たデバッガー呼んで来いよ〜富士通 (スコア:1)
お勧めしない。
Re: (スコア:0)
社員が働かないのがいけない