セキュリティについて

■セキュリティの知識について

普通の家庭で普通にパソコンを使っていて、身代金を取る「ランサムウエア」の被害にあったり、セキュリテイ漏れにつけ込まれ、善良な市民が、ウィルスをばらまいた張本人として「誤認逮捕」されたり、ドラマや漫画のストーリーのようなことが、現実社会に起こってきていて、どう対処すれば良いのか不安になるこの頃ですが、ひと通りセキュリティを勉強してみると、セキュリティのために用意されている仕組みでは、次にあげた、「暗号技術の基礎」①～⑥が、複雑にからみあって、システム化されているとわかりました。

（暗号技術の基礎）
①共通鍵暗号　②公開鍵暗号　③一方向ハッシュ関数　④メッセージ認証コード　⑤デジタル署名　⑥疑似乱数生成器

セキュリティって、ネットワークの利用を前提にしているので、まずネットワークを勉強するのだけれど、ネットワークがわかったかなと思って、いざ、セキュリティの世界を勉強し始めると、ネットワークの勉強には出てこなかった、暗号技術の基礎事項が前提となっている話があるのが、これが理解するのを難しくしています。これらの知識は、ネットワークに関する知識とは別の種類にあたるものの気がします。

マルっと、イメージでスマートに話をできる人に教えてもらうのが良いかもしれません。そうでないと、難解な数学の話が時折出てきて、頭痛をさそうので、前進できなくて挫折しそうになります。

■セキュリティの危殆化（難しい言葉や）

（コンピュータ計算性能が高まり、解読時間が短くなったために、セキュリティの安全性が低下すること）

コンピュータの処理性能があがるおかげで、暗号技術もそれに合わせて、セキュリティ強度の強いものを使わなくてはなりませんが、これも日々状況が変わるものだから、気が付くと世界標準からはずれたツールを使っていることも、実際にあります。

以下は、１年前に書いた内容ですが、とりあえずは２０４８ビット長で２０３１年ごろまでは大丈夫という話です。ですが、日々アップデートされるセキュリティ事情を追っているので、今回調べなおしました。そして、まだ大丈夫なんだ・・・と安堵しました。

従来の暗号技術（非推奨）：公開鍵暗号ＲＳＡ５１２　ハッシュ関数ＭＤ４／ＭＤ５（実際に脆弱性が発見されている暗号技術）
次世代暗号技術
２０１０年まで：公開鍵暗号ＲＳＡ１０２４　　　　　　　　ハッシュ関数ＳＨＡ１
２０１１年まで：公開鍵暗号ＲＳＡ２０４８　ＥＣＣ２２４　ハッシュ関数ＳＨＡ２２４
２０３１年以降：公開鍵暗号ＲＳＡ３０７２　ＥＣＣ２５６　ハッシュ関数ＳＨＡ２５６
現在推奨鍵長は、公開鍵暗号ＲＳＡ３０７２　ＥＣＣ２５６　ハッシュ関数ＳＨＡ２５６　？

■いたちごっこのセキュリティ対策

一般的に、「セキュリティ対策はいたちごっこ」と言われますが、どういうことかというと。

たとえば、ローマ時代からあった、単一変字暗号。割と単純な仕組みでしかない暗号方法ですが、仕組みは、

Ａ→Ｄ、Ｂ→Ｋ、Ｃ→Ｈ、Ｄ→Ｑ、・・・、Ｚ→Ｒ　というようにアルファベット２６文字の変字表を決めておきます。
この場合、アルファベット２６文字の鍵長は、
２６ｘ２５ｘ２４ｘ・・・ｘ１＝４０３２９１４６１１２６６０５６３５５８４００００００　通りの総数となり、
この古典的な暗号方式でも、ただ調べる方法では、
１秒間に１０億個の鍵を調べたとして、全パターンを調べるのに１２０憶年かかります。

これを暗号技術の専門家が、頻度分析という手法で調査を行うと、
（頻度分析：平文と暗号文で登場する文字頻度は同じ事を利用する分析）

英語の一般的な文章で登場する最も頻度の高い文字は「ｅ」である
英語で最もよく登場する単語は「ｔｈｅ」である
頻度の高い文字だけではなく低い文字も手掛かりになる
はじめとおわりがわかればそれが手掛かりになる

　　　　　　：　　：　　：

慣れたセキュリティ専門家では、ほんの数時間で解読するそうです。

要は暗号するための方法が研究されても、解読するための方法も研究されるので、それでいたちごっこになってしまうのです。

ところで、現在の暗号技術の主要素となる、公開鍵暗号であるＲＳＡでは、暗号のための一時鍵に、鍵長５１２ビットを使います。
この５１２ビットで表現できる素数の数は、およそ１０の１５０乗であり、これは全宇宙に存在する原子の数よりも多い数になるそうです。
（「暗号技術入門　第３版　ひみつの国のアリス」出版社: ソフトバンククリエイティブ、著者: 結城浩）から

■なぜＷｅｂアプリケーションにはリスクがあるのか？

ちなみにＷｅｂアプリケーションで作り込んでします脆弱性の種類は以下のように多いです。
（「体系的に学ぶ安全なWebアプリケーションの作り方」出版社: ソフトバンククリエイティブ、著者: 徳丸浩）から）

セッションハイジャック（なりすまし）を引き起こす「セッションID」の脆弱性
Referer（サイトブラウジング元からのジャンプで情報が洩れる）の脆弱性
セッションフィクセーション（攻撃者のセッションIDを知らない間に使わせられている）の脆弱性
クロスサイトスクリプティング（略称：XSS）
クロスサイトリクエストフォージェリ（略称：CSRF）
オープンリダイレクト脆弱性（他のサイトにジャンプする処理に不備）
HTTPヘッダ・インジェクション
クッキーの脆弱性
メールヘッダ・インジェクション
デレクトリトラバーサル
デレクトリ・リスティング
ＯＳコマンドインジェクション
ＳＱＬインジェクション
ファイルアップロード問題
ファイルインクルード攻撃
evalインジェクション攻撃
デシリアライゼーション問題
XML外部実体参照（XXE）
競合状態の脆弱性
キャッシュからの情報漏洩
JSONエスケープの不備
JSON直接閲覧によるXSS
JSONPのコールバック関数名によるXSS
Web API のクロスサイトリクエストフォージェリ
JSONハイジャック
JSONPの脆弱性
CORSの不備
DOM Based XSS脆弱性

今、便利なシステムを作ろうとすると、インターネットを使った、Ｗｅｂアプリケーションの仕組みを使うのが、まず、候補にあがりますが、その場合にウィルスに付け入るスキのない、セキュリティに強いプログラムを作ろうとしたとき、上記パターンの悪いプログラミングの危険性があることを知り、またどう気を付けなければならないのか気を配らないといけないのです。

プログラミングもやる立場で、納期やら、マンパワーやら、教育やらの問題を考えると、「現実的には無理なんじゃないかなあ」、と思ってしまいます。

■脆弱性診断

Ｗｅｂアプリケーションに脆弱性があるのは分かっているので、ではその対応で最近重要になってきているのが脆弱性診断。

1. プラットフォーム診断
  Webサイトを構成するサーバやネットワーク機器など（IPアドレスがあるもの）に既知の脆弱性がないかを調べる。
  通常、脆弱性スキャナで調べる。
  ●Ｎｍａｐによるポートスキャン
  ●ＯｐｅｎＶＡＳによるサイトを指定した検査
2. アプリケーション診断
  Webアプリケーションに対して、未知の脆弱性がないかを確認する。
3. 動的診断　ブラックボックス診断
  ②－１　ツールによる診断　ＯＷＡＳＰＺＡＰ自動診断
  ②－２　手動による診断　　ＯＷＡＳＰＺＡＰ手動診断
4. ソースコード診断
  ホワイトボックス診断②－３　ツールによる診断　ＲＩＰＳなどソースコード診断
  ホワイトボックス診断②－３　ツールによる診断　ＲＩＰＳなど

注意点

可能な限り診断専用環境を用意する
サイト停止やデータ破壊の場合を想定して計画を立てる
関係者への通知やメールで通知が出る可能性があれば事前に通知する

■開発マネージメントにおけるセキュリティ施策

開発体制　セキュリティガイドラインを整備する＆セキュアプログラミングの教育

開発プロセス　発注時の提案依頼書（ＲＦＰ）について

セキュリティ機能（要件）とセキュリティバグを分ける
セキュリティバグは、脆弱名を列挙し、検収方法・基準を明示し、必要な追加提案があれば求める
セキュリティテストの方法の提案を求め、テスト結果を成果物として要求する
検収後に発見された脆弱性の対応方法と費用負担を明確にする

脆弱性に対する責任の所在

経済産業省が発行している「情報システム・モデル取引・契約書（モデル契約書）」にはシステム仕様書に明確に記載していないものに対しては瑕疵にならないと明記されています。このため、発注者の立場で考えれば、自衛のために契約書と仕様書にセキュリティ上の要求を明記する必要がある。

しかし、2014年、東京地裁の判決で、受注者がＳＱＬインジェクション脆弱性対策を怠ったために、債務不履行で損害賠償が命じられた判決がありました。アプリケーションのセキュリティ施策の責任は全体として発注者が負うが、発注者の指示がない場合でも、自明な脆弱性対策は受注者にも責任が生じると思われる。

（「体系的に学ぶ安全なWebアプリケーションの作り方」出版社: ソフトバンククリエイティブ、著者: 徳丸浩）から

ホームページ作成を頼む側も、作り込む側も、社会的な責任があり、仕様をはっきり決めておく必要があります。
また、大企業のインフラに一部接続する中小企業にも、その責任が影響してきています。

■これほっといて良いの？

ＷｏｒｄＰｒｅｓｓの問題

こちらは WordPress社の問題ではなく、WordPressをベースにホームページを制作している制作会社の問題。良く言われることですが、ＩＰＡが啓蒙しているように WordPress自体の脆弱性でバージョンアップがあったら、すぐ適用しなければなりません。それに付随してプラグインも対応した時点で適用しなければなりません。

でも WordPress自体のバージョンアップとプラグインのバージョンアップのタイミングが必ずしも合わないので（プラグインは１０個も２０個も使っている場合もあるし）作業自体が難しい。

メンテナンスが行われていないプラグインがあれば、代わりのプラグインを探したり、使用を止めて、代替案を提案しなければならないこともあるし、調査だけでも大変。

更にバージョンアップの結果、画面が真っ白になるなどの不具合が発生することもあり、問題を難しくしています。

私が知っている会社もそうですが、世の中の制作会社はこの辺の事情から、作るだけ作って、メンテナンス作業をまったく行わないところが多いのです。リスクをかかえたまま、ずっと運転していて、そのリスクの意識もなく、へたすると WordPress自体にメンテナンスの機能があり、バージョンアップも管理画面からユーザが作業できることも知らないことも多いみたい・・・

2017年には世界中の WordPress利用サイト150万件以上が改ざん被害を受けそうで、最近でも大塚商会提供のホスティングサービスの「アルファメール」で顧客のWebサイト５０００件が改竄される事件がありました。（2019/01/19犯行声明）
WordPressは大手企業から一般ユーザーまで、全世界各国でCMS所有率の実に６０％とも良く目にしますし・・・