PayPay の20%還元キャンペーンはすごかったわん！
そうですね。ですがいいことがある裏では必ず悪い人が動くもので悲しいです。
今回は不正利用があったみたいだけどそんな簡単にできるものなのかにゃ？
セキュリティは1つでも穴があるとそこからいくらでも被害は拡大してしまうものです。安全なサイト運営のために今日はセキュリティに関して学んでいきましょう！
はい！
はい！
こんにちは！！あっきーです！
みなさん PayPay の20%還元のキャンペーンでなにかお買い物したりしましたか？
本当にものすごい勢いでネットニュースや Twitter は大賑わいでしたね！
ぼくはとくにほしいものが出てこなく完璧に波に乗れなかった勢です(笑)
そんな勢いもつかの間、こんどは不正利用の報告のニュースがあとを絶えず。。。
出る杭は打たれるというのか、やっぱり世間を騒がすできごとが起きると絶対といっていいほど悪いひとが動きます。
ちょっと前でいうと NEM の580億円流出とか典型的なパターンで数日で一気に価格が高騰したそのあとすぐの出来事でしたね。
あの時ぼくも仮想通貨に結構つぎこんでたのでなかなかに痛い目に遭いました(笑)
そんなことはさておき！
流行りすたれの早い昨今の IT 業界では早くリリースして走りながら整えていくビジネススタイルが多いと感じます。
そのリリース当初のセキュリティ対策が万全でない段階で被害はおきるものなのかなぁと思ったりします。
ということで、今日は現役セキュリティエンジニアが語る PayPay から学ぶセキュリティ観点という話題で話していこうと思いますのでよろしくお願いします。
PayPay 不正利用の原因
今回この記事を書く経緯に至ったさいに参考にさせていただいた記事です。
不正利用された原因や、それに対する対策を非常に丁寧に説明していただいてますので PayPay でお買い物をされたユーザーさんはぜひ読んでください。
原因はクレジットカード情報が流出したのが大元の理由ではありますが、その前に登録の段階や決済時のセキュリティ対策もガバガバだったのも起因してるみたいですね。
こんな感じだったみたいです。
・クレジットカード情報登録の記入項目
上記3項目のみで登録が可能だったそうです。
登録時のパスワード入力、2段階認証の機能すら存在しなかったみたいです。
この時点でだいぶびっくりしたのですが、さらにセキュリティコードなどの入力ミスにたいするアカウントロック機能の不備、さらに同一カード情報の登録が可能ともうセキュリティホールガバガバの仕様だったようです。
この感じですと推測ですが、多重ログインなども許可していたのかなと思います。
他サイトのセキュリティ不備も原因
PayPay 自体は「情報流出した事実ない」と発表しているようです。
ですが、 PayPay だけがそういってもどうしようがないのがセキュリティの難しいところです。
他の商品を販売していた家電量販店さん側が原因かもしれませんし、実際どこがおおもとの原因が調べるのは困難です。
どんなに堅牢なサイトであろうと小さい1つの穴があればそこを突破口をに不正アクセスなどは行われます。
全体的に良くても提携している企業も含め、セキュリティの最も弱い部分がサイト全体のセキュリティレベルになってしまいます。
脆弱性の種類と対策指針
ここからはエンジニアのかたを対象に今回の PayPay の不正利用の原因として潜んでいた脆弱性の種類と対策指針を話していこうと思います。
※あくまで推測や可能性の話ですので事実かどうかはわかりません
脆弱性の多くはプログラムの不備に起因しています。
今後開発に携わっていく人たちはセキュリティを考慮した実装をできることは大前提です。
今回は細かい対策などは割愛し大枠の部分を説明していきますが、この記事で少しでもセキュリティのイメージやどんな脆弱性からどんな被害が起きるかということをイメージしてもらえたらと思います！
SQL インジェクション
まず、今回の原因の大元になったクレジットカード情報の流出についてです。
これは SQL インジェクションによる脆弱性の典型かと思います。
Web に関してニュースレベルで問題になる事件にはだいたいこいつがつきものです。
まず一番に対策したい脆弱性の1つです。
SQL インジェクションは名前の通りデータベースに関する脆弱性です。
Web アプリケーションの多くはデータベースを利用し、テーブル内のデータを検索、追加、削除、編集などの処理を行っていきます。
SQL の呼び出し方に不備があった場合、ユーザー任意の SQL 文を挿入するすることでその構文が SQL の組み立てに使用されてしまい、意図しないデータベースの実行が行われてしまいます。
その結果として以下のような被害に遭います。
今回はテーブル内のクレジット情報が流出したことが原因で引き起こったと推測できます。
対策
アクセス制御
他のユーザーからクレジット決済が可能であったことからアクセス制御に不備があった可能性が考えられます。
アクセス制御とは、認証後(ログイン後)のユーザーのみにしか権限がない処理(今回だと決済処理)を他のユーザによって実行されてしまう脆弱性の事を指します。
原因としてはセッション管理に不備があることがほとんどです。
この脆弱性があると以下のようなことができてしまいます。
被害は一概に言えないですが、他人にアカウントを乗っ取られたような状態ですのでさまざまな大きな問題をもたらします。
対策
混合しやすいのですが認証と認可は別物です。
認証とは、ユーザを一意に特定すること。
認可とは、認証済みユーザに対して、サービスの利用やリソースへのアクセスを行なえる権限を与えることです。
この認可制御を実装することで、ログイン中の利用者が他人になりすましてアクセスするなどのアクセス制御による脆弱性は対策することができます。
ですので、これから開発を行っていく方はどのユーザーにどんな、どこまでの処理を許可するかを制御するということを設計の段階で定義することを意識したらいいと思います。
CSRF
SQL インジェクションとアクセス制御に不備があったことから CSRF による脆弱性もあった可能性が考えられます。
CSRFは認証後(ログイン後)のコミット処理(データベースに処理を加えるアクション)時に起きる脆弱性です。
フィッシングによる第三者からのリクエストの強制を行われ、知らぬうちにユーザー情報への書き換えなどがおこなわれます。
これにより以下のような被害に遭います。
CSRFは攻撃に被害者の介在が必要な受動的攻撃に分類されるため、今回に関しては CSRF による被害で引き起こされたわけではないと思いますが、潜在的な脆弱性として可能性があることから説明させていただきました。
対策
ブルートフォースアタック
セキュリティコードなどの入力ミスにたいするアカウントロックの機能がなかったことからブルートフォースアタックの被害に遭う可能性があります。
ブルートフォースアタックは「総当たり攻撃」とも呼ばれる、パスワードを破る手法のひとつです。
総当たりという言葉からも想像できるように、パスワードに使われていると推測される文字列を1つずつ
変えながら片っ端から試していき、正解に当たるまで試し続ける手法です。
クレジットカードのセキュリティコードは3桁でかつ数値のみですのでブルートフォースアタックをされたらわりと
すぐに番号の解読をされてしまいます。
以下の図でブルートフォースアタックによるパスワード解読までの所要時間を参照してください。
対策
本来ログイン画面での脆弱性ですので、パスワードの長さや文字の組み合わせによるパスワードの強固かがあげられますがクレジットカードのセキュリティコードは3桁の数値なので、
などが妥当なのかと思います。
その他にもパスワードの再入力や本人認証などを組み合わせることで今回のような事件は防げたかもしれません。
ユーザーとのギャップに生じるセキュリティレベルの低下
PayPay を例にいろいろとセキュリティの話をしましたが、実は IPA によるセキュリティの基準などは定められていて、それに沿って設計すればそこそこ堅牢なサイトは構築できます。
なのになぜ、セキュリティ事故は絶えず起きるのでしょうか。
おそらく提供者とユーザーとのギャップによるセキュリティの甘さが原因にもあると思います。
正直つかう側としては何かとパスワード入力したり、チェックの多いサイトってたぶんうざいですよね。
たぶんそれが原因でユーザー離れが起きることも多々あるかと思います。
提供者もそれを十分に理解しているからこそついつい UI 重視の設計にしてしまいセキュリティレベルを妥協してしまっているところもあるでしょう。
ですが、結局それが原因でお互いにとってよくない結果を招いてしまっています。
こればっかしはたぶんなくならない気もします笑
なので落としどころを明確に定義しておく必要があります。
またはセキュリティエンジニアが不足していることも起因しているのかもしれません。
エンジニアとしては１人１人のセキュリティレベルの底上げをし、ユーザーも開発者はそういう
ところも気にかけてつくっているということを認識して多少めんどくさい処理も自分たちのためでもあるということを理解して寛大な心でサービスを利用していただけたらこういう事件も減っていくかもしれませんね。
個人でできること
最後に個人的に思った対策です。
対策というより完璧リスクヘッジですが(笑)
単純にクレジットカードではなくデビットカードで予め上限額を決めてしまうといいのではないかと思いました。
上限額が大きいほどリスクは高いのでリスクヘッジとして僕はオンラインではデビットカードを今後は使っていこうと思いました。
なにがおきるかわからないのでちょっとした工夫と対策、まめにクレジット明細などを確認するようにして被害を最小限に抑えていきましょう！
さいごに
最後まで読んでいただきありがとうございます。
まだまだ発展する IT 業界で、これからもセキュリティに関する事故は無くならないと思います。
今回の記事でこれから開発者になる人たちはセキュリティを考慮した開発を心掛けてくれたらさいわいです。
それではまた次の記事でお会いしましょう！