書かない日記
PHP 5.6.38/7.0.32/7.1.22/7.2.10でApache2handler SAPIのセキュリティバグが修正されました。
13 Sep 2018
Apache2:Fixed bug #76582 (XSS due to the header Transfer-Encoding: chunked).
http://php.net/ChangeLog-5.php#5.6.38
攻撃者が送った出鱈目な攻撃用データがPHPプログラムに関係なくブラウザに出力されてしまう問題が修正されました。
この脆弱性の影響が正しく伝わっていないようなので、簡単に紹介します。
“PHP 5.6.38他で修正された任意コンテンツ送信脆弱性について” の続きを読むインターネット上に16億件の企業ユーザーのメールアドレスとパスワードが公開されている、とニュースになっています。ほとんどの漏洩元はこれらの企業ではなく、他の一般公開されているWebサービスなどのアカウント情報漏洩※だと考えられています。
この事例から、非常に多くのWebサービスが情報漏洩を伴うセキュリティ問題を抱えているにも関わらず、気がつくことさえも出来ていないという現状があると考えるべきでしょう。（もしくは気付いていても公開していない）
侵入されたことを検知／対応する技術の導入も重要ですが、ここではなぜWebセキュリティはここまでダメになっているのか？を考えます。
※ 情報漏洩にはベネッセのケースのように内部の人による持ち出しも含まれていますが、外部の攻撃者が盗んだ情報も少なくないと考えるべきでしょう。
“なぜWebセキュリティはここまでダメなのか？” の続きを読むデータフロー分析とはコールフローグラフ（CFG）を使ってプログラムを分析する手法です。ソフトウェアのセキュリティ対策にもデータフロー分析は広く利用されています。例えば、静的ソースコード検査ツールは静的（＝プログラムを動作させず）にプログラム実行時のデータフローを分析し、問題を発見する手法です。
コールフローグラフ
データフロー分析の基礎知識はハーバード大学コンピューターサイエンス学科の講義資料（PDF）が参考になります。こちらを参考にしてください。英語の資料ですが容易な内容です。
“データフロー分析とセキュリティ” の続きを読むできれば全体をよく読む方が良いのですが、まとめとして対策を一覧できるようブログにしました。引用は2017年版 OWASP TOP 10からです。
“OWASP TOP 10のセキュリティ対策” の続きを読む今のプログラムに足りないモノでセキュリティ向上に最も役立つ考え方のトップ2つ挙げなさない、と言われたらどの概念／原則を挙げるでしょうか？
私なら
を挙げます。
極論すると、この2つ知って実践するだけでセキュアなソフトウェアを作れるようになるからです。この2つだけでは十分ではないですが、これを知って、実践しているだけでも開発者は今のコードより段違いにセキュアなコードが自分で書けるようになります。
もう一つ追加するなら
を加えます。これはゼロトラストとフェイルファーストから導き出せる概念です。ゼロトラストとフェイルファーストで検証を行うと自然と多層防御になります。多層防御はセキュリティ対策の基本ですが、特にソフトウェアでは実践されている、とは言えない状況です。
これら3つはとても有用な概念で単純明解な概念ですが、知られていなかったり、誤解されていたりすることが多い概念／原則と言えるかも知れません。
“ゼロトラストとフェイルファースト” の続きを読むphar（PHPプログラムを１つのアーカイブファイルにまとめて利用するファイル形式）のメタデータにserializeが使われている点は議論になったことがあるように思います。そもそも危険なpharファイルだったら意味なし、という結論だったはずです。結構前の事なので詳しくは記憶していません。
pharモジュールはデフォルトで有効化されており、影響範囲は大きく危険度は高いです。
BlackHat 2018でpharアーカイブを利用した攻撃方法が紹介されています。簡単に紹介します。詳しい内容は発表者のPDFを参照ください。WordPress, Type3, TCPDFへの攻撃方法が記載されています。
“PHPのPharを使ったコード実行” の続きを読むOWASP Secure Coding Practices – Quick Reference Guideの訳語が不適切ではないのか？とメールを頂きました。
ブログにして見ていただく方が良いと思ったので公開します。
“OWASP Secure Coding Practices – Quick Reference Guideの訳語” の続きを読む日本はOECD加盟国としてOECDプライバシー８原則を尊重する国です。OECDプライバシー8原則とは1980年にOECD（経済協力開発機構）で、個人情報保護の基本となる原則として定められました。
1980年頃には企業のオンライン化と顧客情報の集積が進むに伴い、個人のプライバシー情報を無制限に企業が利用することへの懸念が高まっていました。先進国間でプライバシーの概念が異なると困ります。先進国の間で同じ概念に基づくプライバシー保護を実現するためにプライバシー勧告が行われました。
セキュアコーディング／セキュアプログラミングはコンピューター動作の基礎的原理から構築されています。初めてプログラムが書かれた時から現在に至るまで、全てのプログラムは同じ基本構造を持っています。
基本原理／基本構造に合わないセキュリティ対策/構造では満足できるセキュリティ状態の達成は不可能です。残念ながら大半のWebアプリが原理に反する脆弱な構造を持っています。
IPAが出鱈目なセキュアプログラミングを啓蒙していた責任は大きいと言わざるを得ないでしょう。昨年、修正しましたが誤りを訂正すべく十分な啓蒙を行っているとは言えないように見えます。
“セキュアコーディングの構造／原理／原則” の続きを読む“日本政府「夏時間」に続き「夏温度」を導入” の続きを読む酷暑対策として「夏時間」の導入を決定した日本政府は新たな酷暑対策として「夏温度」の導入を検討することを発表した。夏時間（サマータイム）と同じく夏季の3ヶ月間は夏温度として20℃低い温度の使用を義務付け2020年から導入する。
政府関係者は「”夏時間”を導入するなら、同じ酷暑対策として”夏温度”を導入するのが道理だ。粛々と進める」とした。夏温度を推進する与党議員は「心頭を滅却すれば火もまた涼し、”夏温度”を導入すれば45℃の酷暑であっても25℃と快適温度となり、気持ちだけでも涼しくなる」と夏時間導入の意義を語った。
この方針に関して医療関係者は「人は気持ち次第で厳しい環境に対する耐性を向上させることが可能な場合もある。一定の効果があるのではないか？」「精神論かも知れないが、真面目な日本人なので気分を変えるだけで本当に良い効果が得られる可能性がある」とコメントした。
政府は気象庁のシステムに”夏温度のデータ”をそのまま保存することを要求することも分かった。”夏温度”期間中は政府および外郭機関は全ての温度データを”夏温度”で提供し、法律で”夏温度”利用を義務化する。
気象庁からの温度データは”夏温度”のまま提供されることになる。気象庁からのデータに依存する気象情報提供会社は「”夏温度”の利用が義務化されると気象データ管理システムの温度データが出鱈目になる」、ITシステムの専門家もシステム改修なしでは、気象関連システムに重大な問題を起こすとして強い懸念を示しました。
夏温度の利用を徹底するため、政府は夏温度期間中は全ての”温度”データを夏温度で保存することを義務化するとしている。
官房長官は”夏時間”の導入でさえオリンピックまでに完了できる。”夏温度”の影響範囲は限定されているとし、気象関連システム改修に関わらず”夏温度”の導入を進めるとした。
（もちろんフィクションです）
2018年８月14日、日本政府は東京オリンピックに合わせて夏季の期間に限り、1kgを1200gとする「夏重さ」の導入の検討に入ると発表した。
官房長官は「夏重さの導入により夏季の過剰なダイエットを防止できる効果が期待できる。国民の健康のために確実に導入したい。」と”夏重さ”導入にかける意気込みを語った。
特に若年層では夏季の過剰なダイエットが恒常的に行われており、成長期に於けるダイエットが問題化していた。夏季に限り1kgを1200gをすることにより50kgの体重は約41.7kgとなり、多くの若年層が理想の体重を見掛け上達成でき、過剰なダイエットを防止する効果が期待できるとしている。
”夏重さ”導入を巡ってはその実効性が疑問視されていた。政府は”夏重さ”の表記／導入を法律で義務付け、違反した場合には懲罰的罰金を課すことを検討している。”夏重さ”で表記していない製品１つあたり1万円程度の罰金が有力視されている。この罰金制度が実現した場合、1万個の製品を”夏重さ”に非対応で出荷した場合、1億円の罰金が課されることになる。
突然の罰金付き”夏重さ”導入に対し産業界からは「夏の間だけ重さの基準が変わるのは困る。夏重さ基準の導入には製品のラベル変更からITシステムの更新など負担が大きい。夏重さが終了後の製品ラベルなどはどうするのか？」「現状のシステムだと取引の際のkgが表記の重さが”夏重さ”なのか”冬重さ”なのか区別できなくなる」と困惑の声があがっている。
夏重さ導入を主導した”夏重さ導入を実現する会”会長は重さ基準の変更による影響に対し「コンピュータなどの重さ設定の変更は、律儀で真面目な国民ならば十分乗り切れるはず」「重さ感覚の違いの問題は、むしろ個人の心構えにより、多くは解消されるはず」とした。
（フィクションです）
サマータイムならぬサマーウェイトだったら？というフィクションです。
時期によって「重さ」の基準が変わると困ります。「時間」の基準が変わるサマータイムは夏時間/冬時間への「切りかえ時」のみの問題に見えますが、コンピューターにとっては「重さ」基準の切り換えが行われた場合と同じような変更が必要になります。
“日本政府が「夏重さ」の導入を決定” の続きを読むサマータイム（デイライトセービング）の導入は可能です。欧米では導入しています。しかし、問題は可能かどうか？だけではないです。
欧米ではITシステムが発達する前からサマータイムを実施しています。つまり最初から時間がコロコロ変わることを前提にITシステムが作られています。
一方、日本ではサマータイムは敗戦後の占領統治下の一時を除いて実施されていません。多くのITシステムは時間がコロコロと変わることを前提として作られていません。
サマータイム導入でITシステムで何をしなければならなくなるのか、簡単にまとめます。結論は、サマータイムの導入は難く、ITシステムにはデメリットしかなく、他もメリットは少くデメリットが目立つ、です。
“サマータイムの導入は簡単！なのか？可能なのか？メリットはあるのか？” の続きを読むDrupal 8のwebfromのバージョンアップをサボっていると、バージョンアップするとパラメータのデータ型が異なる、と致命的なエラーになり動作しなくなります。
最初、エラーメッセージで検索すれば対応策が直ぐに見つかる、と思って検索しました。しかし、的確な対応方法を記載したページが検索されません。対応策は簡単です。FAQ的な情報ですが、誰かの役に立つと思うので対応策を記載します。
問題の原因はデータベーススキーマの更新です。他のデータベーススキーマ更新が必要なモジュールの場合も同様の方法で更新できるはずです。
“Drupalのwebformモジュールの更新” の続きを読むgitlabのCI/CDは他の今時のCI/CDシステムと同じくYAMLファイルで記述します。リポジトリにCI/CD定義を書けるのは便利なのですが、コミット前に定義が正しいかチェックししたい場合がほとんとです。
少なくともgitlab-ci.ymlをコミット前に文法をチェック/テストしたい！
この場合に使えるスクリプトをたまたま見つけて、便利だったので紹介します。
“gitlab-ci.ymlチェックスクリプト” の続きを読むセキュアコーディングの基本概念は、言語のタイプを問わず、全てのプログラミング言語と互換性があります。
“セキュアコーディングは言語を問わず適用できる” の続きを読むアプリケーションとライブラリでは作り方/設計が大きく異なります。この違いを理解していないとセキュアなアプリケーションの構築が困難、というより不可能になります。
“アプリとライブラリの違い – セキュリティの基礎” の続きを読むZFSにはスナップショット管理機能があります。スナップショットは便利です。自前スクリプトでも管理できますが管理ツールがある方が便利です。
Sanoidの機能
実際にはもう一つ、findoidというコマンドもあります。使っていないのでここでは省略します。
参考：
FedoraでZFSを使う
Attack Surface （攻撃可能面=攻撃可能な箇所）の管理はセキュリティ対策の基本中の基本です。あまりに基本すぎてあまり語られていないように思います。
攻撃可能面を管理するには先ず攻撃可能な箇所がどこにあるのか分析（＝リスク分析）します。その上でできる限り攻撃可能な箇所を削減（＝リスク削減）します。攻撃可能面の分析と管理とはリスク分析と管理です。セキュリティ対策そのものと言える、基本的な管理です。
Attack Surface (攻撃可能面)
The attack surface of a software environment is the sum of the different points (the “attack vectors“) where an unauthorized user (the “attacker”) can try to enter data to or extract data from an environment.[1][2] Keeping the attack surface as small as possible is a basic security measure.
出典：Wikipedia
日本語訳すると以下のようになります。
“攻撃可能面の管理 – セキュリティの基本” の続きを読むソフトウェア環境における攻撃可能面は不正なユーザー（攻撃者）がデータを攻撃対象に入力または取り出し可能な様々箇所（アタックベクター）の集合である。攻撃可能面を可能な限り小さくするのは基本的なセキュリティ対策である。
アプリケーション開発におけるセキュリティ対策は大きく別けて、自由を制限するセキュリティ対策と自由を許容するセキュリティ対策の2種類に分けられると思います。
「セキュリティ対策の為に自由を制限する対策”だけ”でなければならない」とする意見を時々見かけます。しかし、これでは必要な仕様を満すソフトウェアが作れなかったり、不必要なコストが要るソフトウェアになったりします。
“開発者の自由を許容するセキュリティ、自由を束縛するセキュリティ” の続きを読む
いくらセキュリティに拘っても安全にならない場合があります。その代表例はソフトウェアの開発環境です。そもそもセキュアにすることが無理な場合、別の対策を取る必要があります。
細かいセキュリティ対策を実施するより、本質を捉えて全体対策を行う方がより安全になる場合があります。開発環境はその代表例です。
“セキュリティに拘ってもセキュアにならない – 開発環境セキュリティ” の続きを読む