2019-07-05に更新

7payの不正アクセスについての考察

2019年7月はじめ、Twitter上で7payにて不正利用があったことがささやかれはじめた。7payというのはセブンイレブンで簡単にチャージできて簡単に支払いが行えるという最近流行りのQRコード式決済のうちの一つ。それについて色々と考察してみる。

ちなみに会社名やサービス名など、細かい部分を把握する余裕がないため事実どうこうよりも考察メインにとどめる。

何があったのか

自分以外の誰かが勝手にチャージを行い、勝手に支払いを行ってしまうという、不正アクセスによる窃盗が行える状態だった。7payは7/1から開始したため開始から割とすぐに発生した。

原因はなにか

オムニ7という通販サイトがあり、そのユーザーアカウントが7pay利用のために使用されている。Twitterで話題になったため多くの人が知っていることではあるが、そのオムニ7のパスワードリマインダーにて、メールの送信先を設定できる入力欄があったため、その他の入力欄の内容が分かってしまえば誰でもパスワードを変更して乗っ取る事ができる状態であった。

問題になったこと

これらの現象や会見の内容など、様々なことが今回多くの人によって問題提起された。そのあたりをいくつか考察してみる。

display: none 問題

今回問題となったのがパスワードリマインダー機能でメールアドレスを指定できることだった。そのため、オムニ7上のその入力欄が削除されていた。しかし、誰かが調べたところ削除していたわけではなく単にdisplay: noneのスタイルを追加して非表示にしていただけだった。つまり、ChromeのDevTools等でそのスタイルを無効にすれば普通に同様の不正利用ができるままだった可能性があった。この初動対応が問題視された。

なぜその様な対処をしたのか?

Webシステムの開発をしたことがある方であれば経験があると思うが、入力欄を一つ削除する、という対処は必ずしも簡単なことではない。そのパラメータが来る前提でシステムが作られていればフォームを実行した際にエラーになってしまう可能性がある。その場ですぐエラーにならなくとも、その後にデータの不整合によって別の箇所でエラーが出はじめる可能性もある。

単に非表示にすることにより、ただたまたまその任意入力欄が空でフォームを実行した時と同じ状態になるようにしておけば、入力欄を削除してしまう場合に比べ問題の出る可能性がかなり小さくなる。そのためこの対応を行ったのだろうと思われる。

この対応は実際どうだったのか

永久にこの対処だけだったら問題だろうが、とりあえず一瞬でリリースできる初動対応としては大きな効果がある。普通のユーザーには何もわからないだろうし、不正利用者も画面を見て「あ、もう対処されたのか」と諦める可能性もある。

もちろん同じタイミングで入力欄削除までできていたら良かったのだろうとは思うが、大きな会社のシステムのため諸々の確認のバケツリレーと承認が多くて難しかったのだろう。

これも実務経験があればわかると思うが、とにかくWebエンジニアが勝手にちょちょいと修正してしまうと、不具合がでて別の問題が出てしまったりする。実際にどう対処するか、対処した後問題がでていないか、みんなで確認していかなければならない。組織や会社が大きければ大きいほど、ちょっとした修正でもすごく大変なのである。

一応現時点では入力欄まで削除されている。

この仕様でOKになってしまった

実務で何かしらの開発を行ったことがある人であれば普通に考えてこの仕様がヤバイことはリリースして問題が発覚する前から分かる。パスワードリマインダーで通知先のメールアドレスを入力させてはいけない。ではなぜこのような仕様になっていたのか?

可能性の一つとしてあげられるのがエンジニアやプロジェクトマネージャー、仕様策定者等、関わる全員の知識が実務経験がほとんどないレベルの人間だったということ。ただ、その可能性は低いだろう。前述の通り多くの人が関わっているわけなので、全員がわからないという可能性は低そう。

これも分かる人は多いと思うが、多分最終的な物事の是非を決める人間にそのあたりの知識がなく、指摘されても仕様を変更するという決断をしなかったこと。もしくは、その可能性があるということを現場の誰もが経験上よく知っていて、「どうせ言っても変わらないだろうし…もう知らね…」と考えて指摘すらする気力が起きなかったこと。記者会見も悲惨だったので、このあたりは色々と体制の闇があったのではないかということが想像できる。

全て想像だが、このあたりは簡単にエンジニアのスキルがどうのこうのという話ではなさそうに思う。組織がやばそう。

記者会見が悲惨

記者会見がとにかく悲惨だった。

二段階認証を知らない

社長が二段階認証を知らないことがわかった。ただ、実際社長全員が知っているものなのかどうかはよく知らない。社長はあくまでも経営者であり技術的な専門知識を持っているわけではない。(とはいえ最近は二段階認証も一般的になっていると思うが、まだ違うのだろうか。そういう操作は知っているが名称は知らないなど?)

そもそもなんで社長が出てくるんだ、という気持ちもあるが技術的な話をするだけではないし問題も大きいため社長が出てくるのはうなずける話ではある。実際に作業しているプログラマーやプロジェクト管理をしている人間は保護されるべきであるので出してはいけないと思うが、せめてもうすこし話の分かる広報担当者などが出てくればよかったのかもしれない。

セキュリティチェック済み

これでセキュリティチェック済みだったという。まあこれはもう複数の会社にまたがる話のようなのでなんとも言えない。そもそもチェック以前に内部で握りつぶされている話なのではという気がしなくもない。

サービスを停止しない

チャージは停止したがサービス自体は停止していない。まあこれは問題が出ている箇所がチャージということだし外の人間としては何も言えない。

開発者の立場、ユーザーの立場、会社の立場で考えると色々なことが異なってくる。大きな企業となると、割とモラルにとことん拘るというよりも、費用的にどうか、というところの判断も大きいのではないかと思う。被害額がおおよそ5500万ということで恐らく補填が可能な範囲という認識なのではないかと思うため、一番の原因を停止し被害額の増加が収束している状況であれば継続という判断を行う企業は普通にあるのではないかと思う。

まあそもそも会見自体は自分たちが被害者的な考えで話していたようなのでそもそも何を考えているのか、理解しているのかは何もわからないが。

まとめ

とにかく総合して何が問題だったのかというと、古い人間が多い組織の闇という部分が大きいのではないかという気がする。全部想像を元にした考察だが。なにか間違ってる事を書いていたらごめんなさい。


だら@Crieit開発者

Crieitの開発者です。 主にLAMPで開発しているWebエンジニアです(在宅)。大体10年程。 記事でわかりにくいところがあればDMで質問していただくか、案件発注してください。 業務依頼、同業種の方からのコンタクトなどお気軽にご連絡ください。 業務経験有:PHP, MySQL, Laravel5, CakePHP3, JavaScript, RoR 趣味:Elixir, Phoenix, Node, Nuxt, Express, Vue等色々

Crieitは個人で開発中です。 興味がある方は是非記事の投稿をお願いします! どんな軽い内容でも嬉しいです。
なぜCrieitを作ろうと思ったか

また、「こんな記事が読みたいけど見つからない!」という方は是非記事投稿リクエストボードへ!

こじんまりと作業ログやメモ、進捗を書き残しておきたい方はボード機能をご利用ください!

ボードとは?

コメント