mikolaboのブログ

パソコンからくり研究室

セキュリティについて

Securityこのブログ技術ネタでは、すべて実際に構築して動作したものを載せます。

このブログ大体のネタは、TeraTermのログで記録を取ってあります。

 

このブログのカテゴリ「セキュリティ」について

f:id:mikolabo:20201001181928p:plain

 

■その1:WordPressサイト■

 

知り合いのWordPressでできたホームページをちょこっと手直しをしたときに、「世の中のWeb制作会社さまは、メンテナンスはやらないところが多いんだあ!!」と初めて知ったことから、手をつけるようになりました。

 

WordPress自体は、全世界各国でCMS所有率の実に60%とも言われ、身の回りのホームページの作り込みに使われていますが、IPAが啓蒙しているように WordPress脆弱性バージョンアップがあったら、すぐ適用し、同時にプラグインも適用しなければなりません。

 

ですが、WordPress自体のバージョンアップとプラグインのバージョンアップのタイミングが必ずしも合わないので(プラグインは10個も20個も使っている場合もあるし)作業自体が難しいという運用の弱点を抱えています。

 

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

 

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

 

そのような状況があり、ホームページ制作を真面目に対応していると利益が上げられないので、作るだけ作って、メンテナンス作業をまったく行わないところが多いようです。

 

リスクをかかえたまま、ずっと運転していて、そのリスクの意識もなく、へたすると WordPress自体にメンテナンスの機能があり、バージョンアップも管理画面からユーザが作業できることも知らないことも多いみたい・・・

 

当時、2017年頃は世界中のWordPress利用サイト150万件以上が改ざん被害を受けて、大問題になっていました。

 

その時には、DockerコンテナやVirtualBoxUSBメモリ機能のOS環境などに、WordPressのテスト環境を構築しました。あと、セキュリティデモなんかもやってみました。

 

■その2:セキュリティ監査のための資料作り■

 

この時、セキュリティを勉強し直したのですが、ちょうどその時、ベンダー事業部のセキュリティ監査の面倒を見て欲しいとの話を受けることがありました。

 

食いぶちもなかったので、その趣旨に乗っかって、セキュリティ施策を行うための教育資料の作成を行いました。

 

ちょうど、その頃、Webセキュリティのバイブル的教本の「体系的に学ぶ 安全なWebアプリケーションの作り方」出版社: ソフトバンククリエイティブ、著者: 徳丸浩 が改訂2版として、出版されました。

 

この本では、VirtualBoxのテストイメージファイルがインターネット上に掲載され、実際のPHPのWebアプリを教材に、インターネット上のHTTPプロトコルの電文やり取りイメージをアナライザーで採取して勉強できる環境が用意されていましたので、実際に環境を構築し、作成資料に反映していました。

 

この教本で指摘させているWebアプリケーションの脆弱性の種類は、以下のようにすごく多い。(文頭の番号は、章立て番号)

 

  • 4.3 クロスサイト・スクリプティング
  • 4.4 SQL呼び出しに伴う脆弱性
  • 4.5.1 クロスサイト・リクエストフォージェリ(CSRF
  • 4.5.2 クリックジャッキング
  • 4.6 セッション管理の不備
  • 4.7 リダイレクト処理にまつわる脆弱性
  • 4.7 HTTPヘッダインジェクションの脆弱性
  • 4.8 クッキー出力にまつわる脆弱性
  • 4.9 メール送信の問題
  • 4.10 ファイルアクセスにまつわる問題
  • 4.11 OSコマンド呼び出しの際に発生する脆弱性
  • 4.12 ファイルアップロードにまつわる問題
  • 4.12.4 PDFのFormCalcによるコンテンツハイジャック
  • 4.13 インクルードにまつわる問題
  • 4.14 evalインジェクション
  • 4.14.3 XML外部実体参照(XXE)
  • 4.14.3 XML外部実体参照(Java)
  • 4.15 共有資源やキャッシュに関する問題
  • 4.16 Web APIにまつわる問題1
  • 4.16 Web APIにまつわる問題2(CSRF)
  • 4.17 JavaScriptの問題
  • 4.17.3 postMessage呼び出しの不備
  • 4.17.4 オープンリダイレクト

 

これらのパターンの脆弱性があることを、Web開発メンバに教育し、実際にソースレビューなどでリスクを評価し、不安なところはツールよる脆弱性検査と脆弱性診断を実施する。

 

これが安心できる開発手順となるのだろうが、これを実際にできているのは何%ぐらいになるのだろうか?とりあえず、これから修行するとしても、私の能力ではできそうにない。

 

■その3:Webサイト構築■

 

以前にいた会社で、メンタルヘルスのWebサイトを自社で立てた時に、プロジェクトリーダーであったのと、最近も知り合いのWebサイトの環境周りを一部構築したが、Webサイト制作で感じたことが・・・

 

Webサイトの構築を制作会社に頼むときにも、発注者側の責任を知っている必要がある

 

というのも・・・

経済産業省が発行している「情報システム・モデル取引・契約書(モデル契約書)」にはシステム仕様書に明確に記載していないものに対しては瑕疵にならないと明記されています。

 

発注者の立場で考えれば、自衛のために契約書と仕様書にセキュリティ上の要求を明記する必要があるということ。

 

2014年、東京地裁の判決で、受注者がSQLインジェクション脆弱性対策を怠ったために、債務不履行で損害賠償が命じられた判決がありました。

 

アプリケーションのセキュリティ施策の責任は全体として発注者が負うが、発注者の指示がない場合でも、自明な脆弱性対策は受注者にも責任が生じると思われます。

(「体系的に学ぶ 安全なWebアプリケーションの作り方」より)

 

Webサイト作成を頼む側も、作り込む側も、社会的な責任があり、仕様をはっきり決めておく必要があります。

 

また、特に最近では、中小企業でも結果的に、大企業のインフラに一部接続することになっており、責任が増してきているとのこと。

 

ということで、関わらないようにしていたとしても、結局、関わらないわけにはいかないことが多く、ネタも溜まっているので、少し公開しようと思います。