“日本政府「夏時間」に続き「夏温度」を導入” の続きを読む酷暑対策として「夏時間」の導入を決定した日本政府は新たな酷暑対策として「夏温度」の導入を検討することを発表した。夏時間（サマータイム）と同じく夏季の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のwebformモジュールの更新
Drupal 8のwebfromのバージョンアップをサボっていると、バージョンアップするとパラメータのデータ型が異なる、と致命的なエラーになり動作しなくなります。
最初、エラーメッセージで検索すれば対応策が直ぐに見つかる、と思って検索しました。しかし、的確な対応方法を記載したページが検索されません。対応策は簡単です。FAQ的な情報ですが、誰かの役に立つと思うので対応策を記載します。
問題の原因はデータベーススキーマの更新です。他のデータベーススキーマ更新が必要なモジュールの場合も同様の方法で更新できるはずです。
“Drupalのwebformモジュールの更新” の続きを読むgitlab-ci.ymlチェックスクリプト
gitlabのCI/CDは他の今時のCI/CDシステムと同じくYAMLファイルで記述します。リポジトリにCI/CD定義を書けるのは便利なのですが、コミット前に定義が正しいかチェックししたい場合がほとんとです。
少なくともgitlab-ci.ymlをコミット前に文法をチェック/テストしたい！
この場合に使えるスクリプトをたまたま見つけて、便利だったので紹介します。
“gitlab-ci.ymlチェックスクリプト” の続きを読むセキュアコーディングは言語を問わず適用できる
セキュアコーディングの基本概念は、言語のタイプを問わず、全てのプログラミング言語と互換性があります。
“セキュアコーディングは言語を問わず適用できる” の続きを読むアプリとライブラリの違い – セキュリティの基礎
アプリケーションとライブラリでは作り方/設計が大きく異なります。この違いを理解していないとセキュアなアプリケーションの構築が困難、というより不可能になります。
“アプリとライブラリの違い – セキュリティの基礎” の続きを読むZFSのスナップショットマネージャー Sanoidを使う
ZFSにはスナップショット管理機能があります。スナップショットは便利です。自前スクリプトでも管理できますが管理ツールがある方が便利です。
Sanoidの機能
- スナップショットの作成と削除（sanoidコマンド）
- ZFS send/recieveを利用したローカル／リモートバックアップ（syncoidコマンド）
実際にはもう一つ、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種類に分けられると思います。
「セキュリティ対策の為に自由を制限する対策”だけ”でなければならない」とする意見を時々見かけます。しかし、これでは必要な仕様を満すソフトウェアが作れなかったり、不必要なコストが要るソフトウェアになったりします。
セキュリティに拘ってもセキュアにならない – 開発環境セキュリティ
いくらセキュリティに拘っても安全にならない場合があります。その代表例はソフトウェアの開発環境です。そもそもセキュアにすることが無理な場合、別の対策を取る必要があります。
細かいセキュリティ対策を実施するより、本質を捉えて全体対策を行う方がより安全になる場合があります。開発環境はその代表例です。
データのコンテクスト – セキュリティの基礎
コンテクストを知る、はデータを安全に扱う為に必須の基礎知識です。
よくある致命的な脆弱性を作る考え方は
- コンテクストなんてどうでもよい。このAPIを使えば良い。
です。セキュリティ対策ではコンテクストが何であるのか？を正しく理解することが重要です。ここではコンテクストについて紹介します。
“データのコンテクスト – セキュリティの基礎” の続きを読むプログラミングを覚えたら先ず知るべきコーディングプラクティス
プログラミングを覚えたら先ず知るべきコーディングガイドラインを紹介します。このブログではこれらのガイドラインを時々紹介していましたが、まとめて紹介するのは初めてだと思います。これから紹介するガイドラインはセキュアプログラミング／防御的プログラミング／セキュアコーディングと呼ばれる考え方に基づいたガイドラインです。
ここで紹介する考え方や基本はコンピューターサイエンティストらによって原理／論理から導き出された概念／考え方です。
論理的に出鱈目なセキュリティの考え方が当たり前かのように啓蒙され、脆弱なアプリケーションの作成を助長しています。最後にアンチプラクティスの例として紹介します。
Risk of the session adoption
Abstract
Session management is the center of web security. However, many session management in web application/framework ignored the risk of session adoption for years. PHP 5.5.4 fixed session adoption vulnerability. This article explains the reason why session adoption fix is mandatory for secure web application.
「フェイルセーフ」とは何なのか？
「フェイルセーフ」よく聞く言葉です。最近では「フェイルセキュア」1と言われることもありますが、基本概念は同じです。よく聞く言葉＆簡単な概念ですが、割と広く誤解されている概念の１つに見えます。
フェイルセーフを一言で言うと
何かに失敗しても致命的な問題に至らないよう安全に失敗させる
これがフェイルセーフです。可能ならば「失敗／故障しても、失敗／故障の影響を受けないようする」場合もあります。ITシステムならRAID5や失敗時のリトライなどがこのケースです。
フェイルセーフ（フェールセーフ、フェイルセイフ、英語: fail safe）とは、なんらかの装置・システムにおいて、誤操作・誤動作による障害が発生した場合、常に安全側に制御すること。またはそうなるような設計手法で信頼性設計のひとつ。これは装置やシステムが『必ず故障する』ということを前提にしたものである。
となっています。
こんな単純な概念は間違いようがないでしょ？
と思うかも知れません。しかし、ソフトウェア開発では当たり前に誤解されています。
NHKのスマホセキュリティ対策と今のWebアプリセキュリティ対策は基本構造が同じ
NHKが紹介したスマホのセキュリティ対策には問題があると指摘がある、と少し話題になっていました。
ブログで指摘されているNHKが紹介した対策ページの問題点の概要は以下の通りです。
- Androidの設定から「提供元不明のアプリ」のチェックボックスをオンにしてはならない、必ずオフにする、の説明が無かった。
- セキュリティベンダー広報担当者の説明を長々と回りく引用し説明に終始し、インストールしないことが大事であるのに、インストールしてしまった場合の症状や攻撃手法を羅列した。
- 「見覚えのないアプリは速やかに削除すること。そして、自分がどんなアカウントを利用していたかを確認し、パスワードを変更したり、企業に相談したりするなどしてほしい」などど、そもそもインストールしない、怪しいアプリをインストールできないようにする、の説明がなかった。
要するに著者は、最も根源的かつ基本的なセキュリティ対策である「検証もされていないダメなアプリを入れてはダメ」が抜けた上で、
▽セキュリティー対策ソフトを入れる。
などといった”遅すぎる事後対策”かつ”ベンダーの商売に利する対策”を啓蒙したことが問題である、との認識だと思います。
NHKが紹介した対策ページではスクリーンショット等も交えながら
▽アプリは公式アプリストアからのみダウンロードする。
としているのに、「提供元不明のアプリ」（Android 8ではアプリごとの「不明なアプリ」）のチェックボックスをオフにする、を説明しないのは何事だ！という事です。
確かにその通りだと思います。「提供元不明のアプリ」のチェックボックスは必ずオフにする、は一般スマホユーザーが何がなくてもいの一番にすべきセキュリティ対策でしょう。実際に「提供元不明のアプリ」インストールが原因で攻撃が多数成功しているのですから。
このスマホセキュリティ対策と同じようなことがソフトウェアセキュリティ対策で当たり前に行われている、と感じていました。手元の「危険なアプリの構造、安全なアプリの構造」（公開していません）の導入部分に追加したスライドを紹介します。
SQLインジェクション対策保証付きソースコード検査はじめました
Webシステムに限らず、SQLインジェクション脆弱性は絶対に作りたくない脆弱性の１つです。裁判でSQLインジェクション対策漏れよる損害賠償が契約金額を上回った事例もあります。
ソースコード検査ならSQLインジェクションが行えないことを保証することが可能です。私の会社ではソースコード検査サービスを提供していますが、これまでに検査証を発行したアプリケーションでSQLインジェクションが問題になった事はありません。 “SQLインジェクション対策保証付きソースコード検査はじめました” の続きを読む
何故こうなった？プログラムの動作原理を無視したセキュリティ対策
正しく動作するプログラムには
- 正しい／妥当なデータ
- 正しいコード
の両方が必要です。
仕様から間違っている場合を除けば、セキュリティ問題はプログラムの誤作動によって起こります。データかコード、どちらかの問題によって発生します。
当たり前の常識ですが、これを無視したセキュリティ対策がまかり通っている、それが現在の状況です。何故こうなってしまったのでしょう？
PostgreSQLの文字列型の最大長は？
PostgreSQLには
- varchar(n) 型
- char(n) 型
- text型
の文字列型があります。他にバイナリも保存できる
- bytea型
もあります。
text／byteaの最大サイズは1GiBだ、と私も思っていたのですが違いました。
PHPのserialize()/unserialize()を安全に利用する方法
serialize()でシリアライズしたデータを外部に送信／保存1し、それをunserialize()すると危険です。
アンシリアライズは複雑なメモリ操作が必要で、PHPに限らず、何度もメモリ破壊攻撃の脆弱性が見つかっています。このため、外部入力データのアンシリアライズは行うべきではありません。現在のPHPプロジェクトでは、RubyやPythonと同じく、アンシリアライズのメモリ問題を”脆弱性として取り扱わない”ことになっています。
しかし、外部データでもunserialize()を安全に利用する方法はあります。