サンリオエンターテイメント、SQLインジェクションでメアドぶっこ抜かれる
※えー！今どきSQLインジェクション？
ホームページへの不正アクセス被害についてお詫びとお知らせ
https://www.puroland.jp/important/information_0605/
問題点が2つあるような気がします。ひとつは「SQLインジェクションによる情報漏洩はもう10年以上前から問題になっていたし、対策もあるのにやっていなかった」、あと調査をどこの誰がやって、漏洩した日時もわかっているのに書いてないとレポートとしては甘いこと。
個人的には2005年頃でしたか「WinMXで持っている人にお願いするとSQLインジェクションでぶっこ抜かれたデータがもらえる」というのを聞いて、セキュリティに対して関心を持つようになっています。なので、冒頭で書いたようにイマドキSQインジェクションでぶっこ抜かれたっていうのはウーンって感じ。
※ちなみにぶっこ抜かれたデータで一番強烈だったのは「大人のおもちゃの通販サイト」。個人情報もさることながら注文内容から性癖もわかっちゃう
13 件のコメント
コメントするには、ログインまたはメンバー登録（無料）が必要です。
セキュリティ監査をしていたのかどうか…
原因解明と今後の防止策をしっかり策定し早々に発表する必要がありますね。
トカゲの尻尾切りなどでお茶を濁すと信頼回復が遠のきます。
※ピューロランドのすぐそこにベネッセがあって下っ端は覚えていると思うけど
来来週にサンリオの株主総会があるので質問で指名されたらこの件に関して取締役会で話題にし、サンリオサイトの安全性確認をしたのか聞くつもり。
大昔の人間なので、SQLインジェクションよくわからなかったので、調べたらこういう事なんですねー。対策は基本のキなのですね。
大昔のプログラムだと、この辺り怪しいの結構ありそうな気がします…
https://www.ipa.go.jp/files/000024396.pdf
アクセス権奪取とか権限昇格によるコマンドインジェクションって、結構細かなマイナーリリースの隙を突いて仕掛けられるので。
一番良いのはどのようなものでも「外部に公開するものについては、システムを構成している要素の情報を一切提供しない」というところに尽きます。
※例えば、httpd(Apache)のエラー表示一つとっても
それで「脆弱性を抱えているバージョンか否か？」を
窺い知ることは可能なので。
→「404 Not Found」と書いてあっても、その下に「Apache x.xx.xx」とか
バージョン書いてあったら、それで特定できちゃいますから。
普通こういうものは隠蔽設定ではなくて「専用エラーメッセージ画像と
そのコンテンツが置かれる場所のみを参照させる」ように
設計・構成しますけどね。
>> ばななめろん さん
起こりえるからバウンティハンターはまず調べますよね。“バグハンター”たちが競い合うオフラインの「合宿」、報奨金も出るサイボウズの脆弱性発見コンテストで見えたこと
https://internet.watch.impress.co.jp/docs/special/1216715.html
>開発サイドですでに脆弱性を把握しており、脆弱性情報をJPCERT/CC経由で公開直前の状態だった「修正されているハズの脆弱性」が報告された
>> ばななめろん さん
アクセス権奪取とか権限昇格じゃない気がしますが…それだと直接DB侵入ですよね。
>> さと さん
> アクセス権奪取とか権限昇格じゃない気がしますが…> それだと直接DB侵入ですよね。
Webサーバー側であっても「途中通過するリクエストに余計な文字列売っこまれたら SQLが誤動作を起こす可能性はある」んですよ。
んなの RDB構成する以上、基本中の基本です。SQL Injectionはそういう点を狙って行われるものです。
少なからず予防するには「Webサーバーに進入されないようにするためにも、明らかに『こいつはどうやって構成されたサーバーなのか？という情報を提供しない』のが大前提」です。
システム設計・構成上、そんなことは当たり前に考えていて当然です。
しかしながらそれらの対策を行っても「マイナーリリースで隠れた脆弱性を突かれたら、やっぱり瓦解する」んですよ。
お絵かきレベルの綺麗事で対策できるくらいだったら、一般的にはシステム開発時点で十分想定します。
それでも障害発生した場合、「何が原因なのか？と調査をし続ける必要がある」んです。
システム１つ作るといっても、実は非常に難しいお話と主に政治(社内政治なりいろいろ)が絡むので、綺麗事では出来ないもんですよ。
追伸：
もしも「んなことはない。十分可能」ということであれば、
きちんとした青写真を描いて顧客提案資料を作ってみると
理解できると思います。
→私自身、そういうお仕事は日常茶飯事なので。
顧客分析もせずに騒ぎ立てる門外漢がマスコミ含めて
昨今多すぎるなあ、と感じます。
まあ、マスコミは「騒いで火をつけるのも仕事」と言ってしまえば
それまでなのかもしれませんが。
>> pasorin さん
> 起こりえるからバウンティハンターはまず調べますよね。(以下略)
それでなくても OSSだとほぼほぼ開発時のソースコードは公開されてるので、逆に「ソースコードを確認しつつそこから脆弱性を突き当てる」なんて事もできますからね。
セキュリティ的にクラッキング目的であれば、そこまで分析してると私は認識してます。
なので「それに対抗する手段は必要だよね」と思っています。
一番良いのは「レイヤーとして完全に分断できる構成を作る」ってことなんでしょうけど、それを行うと逆に色々面倒なことが発生するので、特にアプリ開発者側は出来る限り「環境の制約がないところ」を要求する傾向かな？、と感じます。
>> ばななめろん さん
ここ見ると、SQLインジェクションとは、DB侵入もせずWebサーバーへの侵入もせず、普通の正規のWeb画面から正規のアクセス方法でSQL文を忍び込ませる手口という事みたいです。https://www.ipa.go.jp/files/000024396.pdf
サーバー侵入などのインフラレベルの話ではなく、Webアプリケーションのコーディングレベルの話です。
｢SQLの誤作動｣(？)ではなく、正規のSQLを忍ばせてデータを抜き取るという事です。
もちろん、ちゃんとコーディングしていたら、余計なSQLを紛れ込まされる事は防げます。
これ既存のアプリに対して、ちまちまと対策して行くの大変ですよ。だから古いアプリにはまだ脆弱性が残っている可能性がある気がします。
新しいアプリなら最初から対策込みの設計にできますけど。