  |
はてなキーワード: sqlインジェクションとは
フレームワークを狙う方法もある。DNS偽装を使うと、ほぼあらゆるフレームワークがインジェクション
DNSインジェクション こんなもの署名検証で一撃だけど 署名検証しないAutoUpdateがどんだけあると思ってんだと
セキュリティー担当だともっとうるさいが、そこが面白い話がある
おれたちプログラマーが、銀座で口が軽くなるの法則知ってる？酔っ払うとどうしてもな
＞付け加えると、更新系処理のSQLインジェクションを「安全に」確認することも難しいです。試している人は「正義のため」という意識でやっているかもしれませんが、本番データ壊したら「正義」どころではないですからね
本来なら各自治体が作成した優先接種対象者の情報（マイナンバー、接種券番号、氏名、生年月日）を大規模予約システムに集約し照合をかけるべきだった。
しかしなあ、優先接種対象者の連携仕様ができたのいつだと思う？ついこの間の4月だよ。
ベンダー側のプログラム入替が完了してなくて未対応の自治体がほとんどだよ。
防衛省の仕様段階で照合なしの予約システムだったのは確定だろう。
存在しない生年月日と自治体コードくらいはバリデーションすべきだとは思うが、
リリース前に開発元がやれたことといったらそのくらいしかない。
あとSQLインジェクションの噂があるが、本当であれば速やかにIPAなり開発元なり防衛省なりに通知すべきことで、噂だけ広めていいことじゃないだろう。
この記事をめぐる話題について。システム的な側面よかもうちょい根っこの部分で噛み合ってない気がしてて。
これから数ヶ月でてんこ盛りで来るはずのワクチンをどう捌くかというのが論点のはずなのに、
「ワクチン一滴血の一滴！二重予約を許すな」的な論調がやたら強くない？という感じがする。
ワクチン契約状況は厚労省のプレスリリースによるとだいたいこんな感じで
令和３年１月 20 日
本日、厚生労働省は、米国ファイザー社の新型コロナウイルスワクチンについて、
https://www.mhlw.go.jp/content/10906000/000723852.pdf
( https://flyteam.jp/news/article/131928 の表はおそらくこの契約の一部分。５月には週1000万本ペースで5000万本の入荷予定との話だけど、河野大臣が以前出してたツイや厚労省の接種予定報告とおおむね整合性が取れてる)
令和２年 10 月 29 日
本日、厚生労働省は、米国モデルナ社及び武田薬品工業株式会社が新型コロナワク
チンの開発に成功した場合、武田薬品工業株式会社による国内での流通のもと、来年
上半期に 4,000 万回分（2,000 万人分）、来年第３四半期に 1,000 万回分（500 万人分）
https://www.mhlw.go.jp/content/10906000/000723852.pdf
令和3年5月14日
https://www.mhlw.go.jp/stf/newpage_18648.html
まとめると、今後数ヶ月で1億本分以上のワクチンが来る予定が立ってる(ほんとに予定通り来るかどうかは来てみないとわからないけど)。
まあ国内の各地自治体に分配する手間があるので、入荷したらすぐに射てるようになる訳ではないけれど。
で、おそらく件の「ワクチン予約のクソシステム」は、この直近数ヶ月で積み上がるであろう莫大な在庫（賞味期限があるし保存も面倒だし長時間停電とか発生したら責任問題で目もあてられないし一刻も早く減らしたい）をいかにハイペースで減らすかというのが大目標になってるはず。
と考えると、市町村の接種システムとの二重予約とかシステム内の多重予約をどうするかみたいな（システム的に解決しようとしたら外部連携でコストと時間がかかりそうだけど、運用で回避できそうな）話、二の次になってもしょうがないよな感がある。
なんというか、「ちゃんとした」システムは来年あたりの余裕が出来たときに改めて開発良いのでは？今必要なのは直近で業務を回せる「クソシステム」で。
まともなシステムでもクソシステムでも、どのみち会場で本人確認は取らないといけないし、イレギュラーな予約を会場で弾くのもまあありなんじゃね感。
「いやそれでもちゃんと事前に計画しとけよ」というのは正論では有るけど、上で貼った契約のうち三個目の7～９月に5000万回分入荷する話が公開されたの、ほんの数日前だかんね。
あと一応貼っとくけど、世界に冠たるIT先進国なアメリカのワクチン接種管理、こんな感じのゆるゆるシステムなので。
これでも仕組みは回る。「とにかく接種数を稼ぐ」という目標を関係者全員で共有できれば…だけど。
現状が理想と言いたいわけじゃなく、ここ数ヶ月から半年ぐらいの土壇場を乗り切るために突貫工事もやむを得ないし、必要に迫られてる突貫工事に対して「ちゃんとやれ」というのはあんま意味ないよねという話。（「ちゃんと」やった結果としてスケジュールが遅れたら洒落にならないので）
まあ、流石にSQLインジェクションであれこれ的な話が本当なら要改修だと思うけど。
色々情報が出てきたので答え合わせ。
前提として、
その通達では、券番号として、自治体内で一意であることしか定められていなかった。
したがって早期にシステムが稼働していることが求められ、期間的に全国2000ある自治体のシステムと連携させるとか、自治体にデータ入力させるとかいった手立てはとれない。
また、本システム側から発番済みの番号がわからない以上、仮パスワードを登録すること自体が困難。
システム設計レイヤーの問題と、実装レイヤーの問題があって、その2つは分けて考えないといけない。
SQLインジェクション可能とか、無茶苦茶な生年月日を登録できるとか。
特にSQLインジェクション可能が事実なら論外で、自治体と連携させなくてむしろよかったなぁという感想。
でも、5chのデマらしいけど。
誰でも予約可能みたいなのは、このシステム会社からはどうしようもなかった。
むしろ全国横断のシステムにするのではなく、パッケージにして、自治体に配布するほうが良かったんではと思うが、それはそれで、自治体側に運用コストが発生するし、結局データを自治体側に入力させることになるし、早期の稼働には間に合わなかっただろう。
本システムには、開発会社に起因する、稚拙な不具合が含まれている一方で、認証まわりの誰でもログイン問題は、開発会社の責任ではない。
去年の早い時期、ワクチン交渉の段階で、官邸や厚労省はすでに設計を開始しておくべきだった。
「誰でも予約」の問題は、直接には官邸の思いつきの大規模接種のブッコミが原因だけど、そもそも大規模接種や予約の問題は、厚労省が接種番号の仕様設計の段階で考慮しておくべきことだった。QRコードもな。
「この日に来てください、嫌なら希望の日の当日整理券を受け取って、別レーンに並んでください、接種券と本人確認書類を持ってきてね」ってはがきを送りつければよかった。
追記ここまで
=============
この件ね
https://b.hatena.ne.jp/entry/s/dot.asahi.com/dot/2021051700045.html
いや俺も、最初はこの会社クソやなと思ったんだけどさ。冷静に考えると、取れる手立ては少ないんでは。
このシステム、まともに作るなら、ワクチン接種番号の他に仮パスワードをつけてログインさせ、初回ログイン時にパスワード変更させるかたちになるだろう。
年寄りにそれができると思えないし、問い合わせは今の10倍以上くるだろう。
それに、日本中からアクセスしても落ちない認証システムを、このためだけに急遽立てろというのは酷だよ。
認証させないなら、それはそれで他人の番号で勝手に予約して、本人に摂取させない嫌がらせができてしまう。
そもそもワクチン接種券の仕様を決めたのは、竹中の会社じゃない。仮パスワード印刷をして各家庭に配布するのも、竹中の会社じゃむりだし、自衛隊側も嫌がるだろう。
詰んでんだよね。
そもそも番号と個人の紐づけ情報を参照できたのかも不明なんだけど。
Webエンジニアの技術確認って、知識や経験が多方面に渡るから難しいと思ってる。
Webアプリ作れます！と言って完成物だけを見るとたしかにそれなりのができてる。
もちろんテストはない。動けばいい。
N+1やSQLインジェクションが埋め込まれてる（後者はフレームワーク側でほぼ無いが）。
Gitは漢のmaster(main)一本だし、rebaseはできない。何かgitでトラブったら全消ししてcloneし直す。
デプロイもHerokuコマンドをよく分からず打ち込んでるだけ。ちょっと凝ったことはできない。
データベースも大きなExcel程度と考えていて、一つのテーブルに全部のデータを入れる漢のスキーマ。
コマンドも例えばgrepやfindを使えない。XXenvの使い方がわからない。何でもかんでもsudoをつける。
vimが使えないからなんかのはずみでvimの画面になったらパニックになる。
まだまだいろいろあるけど挙げたらきりがない。
となるとどこかで線引きをしなければいけないけど、その線引きの一つの手段が対面での会話の内容、受け答えの態度だと思う。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
254あとで/2503users 総説 新型コロナウイルス感染症（COVID-19）｜中外医学社Online｜note
204あとで/1478users 上手な「在宅勤務」のコツ | Google Cloud Blog
165あとで/2268users 「先生がオメガを倒したら宿題やってきてやるよ」と生徒が言ったので、わたしはゲームライターになった｜Yuka S.｜note
145あとで/706users さくら、Pythonの基礎講座を無償提供 新型コロナで外出控える人向け - ITmedia NEWS
142あとで/1433users アルゴリズムビジュアル大事典
137あとで/731users 【翻訳】コードは書けないけど、1人で作ったwebサービスを収益化した話 - Qiita
131あとで/2848users 100日間おなじ商品を買い続けることでコンビニ店員からあだ名をつけられるか。｜yosano｜note
130あとで/624users 普通のプログラマーがAWSをゼロから勉強するためにやったことと現在の勉強方法 ｜ Developers.IO
129あとで/676users systemd エッセンシャル
129あとで/746users Wikipedia、特に人物の記事と言うのは簡潔な表記なのに長編小説を読んだかのように強烈な印象を与えるものが多い。 - Togetter
127あとで/926users 家で暇をつぶせるサイトを10個ほど紹介する:哲学ニュースnwk
120あとで/2055users 高校レベルの数学から大学の教養数学くらいまでを学び直した - razokulover publog
119あとで/774users 実は便利な「Google Keep」、その使い道は？ 電話取次メモを同僚と共有、写真からの“文字起こし”にも ～小ワザ集＜1＞【「G Suite」時短＆コラボ仕事術】 - INTERNET Watch
114あとで/605users 社内で好評だったSQLインジェクションの資料を公開します – Webセキュリティの小部屋
113あとで/902users スタートアップの組織設計図の5類型と、その失敗率 | Coral Capital
110あとで/845users 現代ウェブフロントエンド（ウェブアプリケーション）について理解する唯一の方法｜erukiti｜note
106あとで/973users 話が上手な人と下手な人の違い | knowledge / baigie
103あとで/615users イミュータブルデータモデル - kawasima
102あとで/1194users ゴミ屋敷で父親が腐って死んでた上に仕事も失ったけど最終的に何とかなった話｜麻宮ミヤネ｜note
101あとで/513users エンジニアリングスキルで捉えるチームマネジメント - mtx2s’s blog
97あとで/499users The History of the URL | The Cloudflare Blog
97あとで/523users 今からVue.jsを始める人のための「知るのを後回しにしてよい」n個のこと - Qiita
97あとで/1087users 男子校出身の18歳に鴻上尚史が教えた「絶対に選んではいけないサークルとバイト」とは？ (1/4) 〈dot.〉｜AERA dot. (アエラドット)
97あとで/2505users 24年暮らしてきたイタリアが、大変なことになっている。
96あとで/1494users 全国一斉休校を受け無償提供されたオンラインサービスをまとめてみた - piyolog
93あとで/852users 米グーグルはテレワークでVPNを使わない、なぜなら「あれ」が危険だから | 日経クロステック（xTECH）
93あとで/1880users よく心理戦で「相手は私の思考を読んでこうするから、それに対し私はこうする」みたいな読み合いがありますが、ずっと互いに読み合っていたら無限ループで切りが無いはずです。どこまで読むのが正解なのですか？に対するMasahiro Sekiguchiさんの回答 - Quora
92あとで/488users 0から始めるNode.jsパフォーマンスチューニング | kohsweblog
91あとで/513users エンジニアとして影響を受けた技術書ランキング2020年版
90あとで/628users UIの細かい動きについて | ゲームUI演出
90あとで/661users そうだ、任天堂・宮本茂さんに聞いてみよう──ビデオゲームのこの40年、マリオと任天堂の“らしさ”と今後【インタビュー】 - ファミ通.com
あとで読むタグは2月に激減したが3月はさらにもう少し減った。
ここ連日騒がれている7pay。
パスワードリセットリンク送付先のメールアドレスに対して設計上の問題で脆弱性が発覚して大変な事態に発展しています。
昨日の会見では社長のITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています。
また、会見内で「セキュリティー審査を実施した」と明言がされました。
https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html
セキュリティー審査を実施していたにも関わらず、何故今回の問題が見逃されたのか。
非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います。
その名の通り、サービスローンチ前に実施する、脆弱性や問題がないかの審査の事・・・だと解釈しました。
一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます。
「実施した」とはいっても、どういった内容を実施したかはわかりません。
ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチな脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います。
通常、脆弱性診断というと、以下のような項目があげられると思います。
抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います。
詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています。
LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティ、スプラウトなど。
ただ、今回の脆弱性診断が外部ベンダで実施されたのか、内部で実施されたのかはわかりません。
以下、推測をつらつら書いていきます。
脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります。
Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます。
また、数量計算もベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。
お願いすれば見積もり時にステージング環境で動いているWebサービスをクロールして、各ページの評価を付けてくれるベンダもあります。
規模と見積もり内容にもよりますが、100～200万といったところでしょうか。
スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万～100万程度でしょうか。
プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います。
これ以外にWebSocketを使っていたり、別のサービスと連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります。
Webサービス200万、スマホアプリ(iOS、Android)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。
脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。
そしてこれをそのまま発注するかと言われると、多分しないでしょう。
セキュリティはお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。
経営層は中々首を縦には振らないでしょう。
会見でも明らかになったことですが、社長のITリテラシはあまり高そうにありません。
こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。
また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。
いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。
削れるものをあげていってみましょう。
例えば、iOS用スマホアプリは実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からのアクセスは基本不可であるためです。確か。
そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセス用インターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータはほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います。
・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。
プラットフォームも、ベンダによりますが実施しなくとも良いとも思います。
ベンダの説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います。
Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います。
サーバのコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。
そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。
ワイドショーでは「不正は海外IPからで、国外からのアクセスを許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります。
実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います。
Webサービスですが、ログイン・ログアウト処理は必須でしょう。また、新規登録、情報変更、退会処理も重要です。
パスワードリセットはどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。
ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。
ただ、NRIにはNRIセキュアというセキュリティに特化した子会社が存在しています。
もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います。
ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。
NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります。
別のベンダに発注したことで、抜け落ちた可能性はゼロではないかもしれません。
また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料をセブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断はセブンに委ねられます。
考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・。
ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます。
使ったことはありませんが、SecurityBlanket 365というサービスは自動での定期診断が可能なようです。
ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダに逐次依頼する脆弱性診断よりかは安く済むはずです。
ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。
ツールの手が届く範囲での、XSSやPoC、ヘッダの有無など、ごく一般的な脆弱性診断になると考えられます。
でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。
脆弱性診断ツールはOSSのものもあればベンダが販売していたり、SaaSで提供しているものもあります。
OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります。
ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。
有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います。
SASTになると、RIPS TECH、Contrast Securityなどでしょうか。
上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。
こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。
ただし、社内のエンジニアに任せる事になるため、片手間になってしまう可能性があります。
また、ツールの使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います。
・・・とは言ってもセブンにはCSIRT部隊がちゃんとあるんですよね。
https://www.nca.gr.jp/member/7icsirt.html
『7&i CSIRT は、7&i グループの CSIRT として設置され、グループ企業に対してサービスを提供しています。』と記載があります。
また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています。
グループ企業の情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査・分析とリスク情報の共有、ならびにインシデント対応活動を行なっています。』
という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。
組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会、情報管理委員会のどこかに所属しているんじゃないかと思われます。
日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバーは専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。
なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います。
会見内で言われた二段階認証も検討事項に上がらなかったのかなあ・・・と。
で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。
https://www.7pay.co.jp/news/news_20190705_01.pdf
これを見ると内部のCSIRTが機能していなかったか、力不足と判断されたかどちらかになるのかな・・・と。
実際はどうだかわかりませんけど・・・。
これも有り得る話かなあ・・・と。
開発やベンダやCSIRT部隊が情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧な表現で伝わっていなかったとか・・・。
ベンダが実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。
7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応に時間を取られることになります。
そういった事を許さない空気が出来上がっていると、まあ中々上には上がってきづらいです。
これも十分にありえる話ですかね。ないといいんですけど。
どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。
そこで思ったのですが、情報セキュリティ基本方針と個人情報保護方針を元にしたチェックリストのようなものがセブン内にあって、それを埋めた・・・みたいなことを「セキュリティー審査」と言っていたりするのかなと思ってしまったんですね。
でもこれはセブンペイの社長が個人情報保護管理責任者ということで、ISMSやPMS等で慣れ親しんだ単語である『審査』を使っただけかもしれません。
そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業が・・・。
大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・。
というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。
そういえばomni7で以下のお知らせが上がっていましたね。
https://www.omni7.jp/general/static/info190705
『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。
もしくはわかりやすい対策を提示しろと言われたのかもしれません。それなら仕方ないんですけど。
以上。
一部typoとか指摘事項を修正しました(役不足→力不足 etc)。
ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。
ちゃんと読んでいただけましたか？全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・。
一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性や問題がないかの審査の事」、つまり「脆弱性診断」を指していると仮定して本エントリを書いています。
そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。
監査は貴方の記載する通り「ある事象・対象に関し、遵守すべき法令や社内規程などの規準に照らして、業務や成果物がそれらに則っているかどうかの証拠を収集し、その証拠に基づいて、監査対象の有効性を利害関係者に合理的に保証すること」です。
貴方の言う「監査」に近いことは「セキュリティー審査自体が、情報セキュリティ基本方針と個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48
542 仕様書無しさん sage 2015/01/23(金) 12:39:08.24 >>541 ちょっと違うと思う。IT疎い人はこういう説明でなるほど開発会社が悪い！となって、裁判官も多分そう思って判決出してる。 普通に運用しててビニール入るのは欠陥だが、SQLインジェクションは欠陥ではない。 俺が思うに、ローカルのディレクトリが外から見えるようになってたとか、認証掛けてるつもりがかかってなかったとかが重過失。 何故ならそれは家に鍵を掛けずドアが開いているか、ドアがないのと同じだから。 泥棒するつもりのない人でもうっかり入って来れちゃう。 それに対しSQLインジェクションは犯罪者がすること。悪意を持って行われる攻撃行為で、一般人はやらない。 家で言うと鍵のピッキングだな。 ピッキングで泥棒入ったら工務店が悪い、みたいなのが今回の判決。 ピッキングにどこまで耐えられるように作るべきか、事前に仕様で決めておく必要がある。今回はSQLインジェクション対策が仕様に入っていなかった。 仕様にないから強い鍵を付けなかったら破られた。これを重過失ってのはひどすぎ。重過失って故意に匹敵するレベルの過失だぜ。契約書の賠償上限無効にしてしまう程の。 俺の考えはこうだ。SQLインジェクションなどセキュリティ対策の実装について、 仕様に書いてあった → 重過失 仕様に一切無し →無罪または普通の過失 パスワードがadmin/passwordとか改善の提案を拒否したとか別の話も話をややこしくしているが、話のコアの部分は以上のようなことだと思う。
従兄弟から「プログラミングやりはじめたんだけれど、この問題の答えになるようなのJavaで書いて欲しいんだ」みたいなリクエストがあった。
俺は一応エンジニアで飯を食っているのでよく懐いてくれた。
よくある初心者用の問題だったので、初心者が躓くポイントにコメントをつけてメールで返す。
何度かやり取りが続いた。
たまにコードのダメ出しをして欲しいとかいってくるが、ほとんど俺が書いていた。
俺の勘としては勉強のためというかは宿題の代行をしているみたいな気がしてきた。
なんかどこかに公開してんじゃないか？と思って、
コードのある部分をグーグルで検索してみた結果一つのブログが出てきた。
ブログというよりは、SNSに近いあのサービスなのだが、完全に俺のコードがそのまま公開されていた。
もう完全に本人。
なんかそのブログはいわゆるワナビーたちがいっぱいコメント書いていて
何だが微笑ましいんだけれども
なんかワナビーたちのグループが幾つかあって、そのグループ間でバトルになっていた。（総勢7人もいなかったが）
情弱とかスクリプトキディとかそんな煽り言葉が飛び交い、知識のひけらかしと揚げ足取りの激しい応酬が繰り広げられていた。
IP抜く、IP抜いてそこにトロイを送る、IPで住所を調べる、IPでどこ中かしらべる。
太古の日本で本名を知られたら魂を操られるという信仰くらいIP信仰すごいよ。
Wikipediaとかで知識を仕入れるんだろうね。
「SQLインジェクションでお前のパソコンパスワード抜く」とか、「クロスサイトスクリプティングでクッキー攻撃だ」とか…
そんな中で、従兄弟は自分の成果として俺のコードを出していた。
ヘッダの署名や、冗談でMITライセンスを記載していたがそれまでそのままコピペ。
ここに集まってくる子たちはどんな子なのかと、それぞれのIDをぐぐってみたら
出るわ出るわ。ツブヤキサービスや別のブログサービスのアカウントが…そして学校名も…
不正アクセスなんかしなくても個人情報すぐわかるのに、彼らはバトル中にそれらググれば分かる情報をつかって煽ることは無かった…
まあ、そんなもんか
リアルタイムで生産される黒歴史が見れて兄ちゃんちょっと懐かしい気持ちになったよ。
しばらくすれば飽きてくるだろう。
新卒で入社したA社は、親会社B社のシステムの内製と、B社の顧客層向けのパッケージソフトウェアを制作販売するソフトウェアハウスだった。
入社1年目の自分は、いくつかの細かい業務を平行して担当することになったが、その中にホームページの管理があった。主な業務は、ページの文章の更新と確認、誤字脱字の修正、古く間違ったHTMLの修正など。
会社のホームページには自社のサービスや製品だけを扱う小さなショッピングシステムがあり、ユーザ登録・ログイン・購入・履歴確認など一通りの機能を持っていた。このシステムを改修したり更新したりする予定はなかったが、せっかく担当となったわけだし、以前から興味のあったWebアプリケーションのセキュリティを勉強しようと、徳丸本を購入した。（当時は紙の本しかなかった）
http://tatsu-zine.com/books/sbcr-taiketekinimanabu
この本は説明不要の名著で、平易な文章で細かく正確な記述がなされている。Webアプリケーション制作に携わる新人プログラマは必読だ。
頭から読み進める。1章に用語の整理があるおかげでだいぶ理解しやすい。2章の実習環境の用意は、都合がつかず読み飛ばした。3章は流し読みし、いよいよ4章。様々な脆弱性を個別にとり挙げ、原因と対策について具体的な説明がされており、非常に興味深い。
なるほど、XSS（クロスサイト・スクリプティング）という言葉は知っていたが、具体的にこういうものなのだな。入力ボックスに入力した内容が遷移後のページに表示されるというUIはよくあるから、気をつけなければ……そういえば、会社のホームページにも検索機能があって、「検索ワード：○○」と表示されるところがあったな。あれもXSS対策がされているはずだ。どれ、見てみよう。テスト用サーバで画面を表示して、＜script＞alert(1)＜/script＞（本当は半角）と入力……
検索ワード： +----------------+ | | | 1 | | [ OK ] | +----------------+
なるほどこれがXSSか。実習環境の用意はしなかったが、実物を拝むことができたぞ。脆弱性の修正の実習もできるな。
このようにして、徳丸本を読み進め、（テスト用サーバで）攻撃を実践しながら、脆弱性を直していった。覚えている限りでは、以下の実習ができた：
ショッピングシステムの中身が、フレームワークやライブラリなし・SQL発行共通関数なし・オブジェクト指向なし・数万行の巨大ファイル1つであることを知ったのは、脆弱性の修正にとりかかってからだった。その他のシステムもすべてこのショッピングシステムを参考に作られているらしく、プレースホルダもエスケープもない文字列組み立てSQL発行があらゆる場所に散乱していた。とても直し甲斐があるシステムであった。
これらのシステムは、日付zip以上のバージョン管理が行われていなかったため、該当部分を誰が書いたのかはわからなかった。そんな状況であったので、大量に報告された脆弱性の始末書は、すべて現在の担当である自分が書くことになった。
自分が入社するより前からあった、誰が作ったのかもわからない脆弱性を、探し修正し始末書を書いた。「私が担当になる前からあった脆弱性なので、原因はわかりません。おそらく不勉強が原因です。対策は、勉強会とコードレビューとバージョン管理です。」などと書いた。今思えば、"よい始末書"の書き方を勉強する機会を逃していたのかもしれない。
自分の作業はすべてgitで記録していたので、自分が担当になったときにはすでに脆弱性があったと主張したが、「自分だけバージョン管理などという便利なものを使っていてずるい」と怒られて終わった。（なお、それよりも前に社内でのバージョン管理ツールの使用は提言していたし、それが「よくわからないから」と却下されてからは、自分だけで使う許可は得ていた。）この経験から、バージョン管理をしていない、もしくはクソみたいな管理しかしていない組織内で、自分だけでも上手く管理する方法についての知見を得た。
こうして、徳丸本の内容を実践しながら学習できたので、セキュリティ分野についての興味はより高まり、知識も増え、A社に対する信頼はほとんど失われたので、さらに勉強し、3年目に入るころには情報セキュリティスペシャリスト試験に合格し、転職した。
Webサービスのセキュリティを勉強したいと思ったならば、徳丸本を読んで、実践しながら勉強することを強く推奨する。紙の本には実験用環境のCDもついているので、A社でホームページを担当していなくても、実践しながら勉強することが可能だ。（電子版の場合はどうなのだろうか。申し訳ないが各自確認していただきたい。）
金が絡むサービスに限って、脆弱なパスワードしか使えないことが多い気がする。
「8文字以上、16文字以内で記号なし」とか。
SQLインジェクションにビビって記号さけるのはまぁ10000歩譲って分かるけど、なんでパスワードに桁数制限があるの。
単なる文字列なんか100文字ぐらい許してくれてもいいでしょ。そんなにリソース取らんでしょ。
問題は使用者が覚えてられるかだけど、そんな長いパスワード毎回入力するのはキチガイだけで、コピペするのが現実。
最近は1Passwordで自動生成したパスワードしか使ってないので、一つも覚えてない。
