phar（PHPプログラムを１つのアーカイブファイルにまとめて利用するファイル形式）のメタデータにserializeが使われている点は議論になったことがあるように思います。そもそも危険なpharファイルだったら意味なし、という結論だったはずです。結構前の事なので詳しくは記憶していません。
pharモジュールはデフォルトで有効化されており、影響範囲は大きく危険度は高いです。
BlackHat 2018でpharアーカイブを利用した攻撃方法が紹介されています。簡単に紹介します。詳しい内容は発表者のPDFを参照ください。WordPress, Type3, TCPDFへの攻撃方法が記載されています。
(さらに…)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システムにはデメリットしかなく、他もメリットは少くデメリットが目立つ、です。
(さらに…)gitlabのCI/CDは他の今時のCI/CDシステムと同じくYAMLファイルで記述します。リポジトリにCI/CD定義を書けるのは便利なのですが、コミット前に定義が正しいかチェックししたい場合がほとんとです。
少なくともgitlab-ci.ymlをコミット前に文法をチェック/テストしたい！
この場合に使えるスクリプトをたまたま見つけて、便利だったので紹介します。
(さらに…)セキュアコーディングの基本概念は、言語のタイプを問わず、全てのプログラミング言語と互換性があります。
(さらに…)アプリケーションとライブラリでは作り方/設計が大きく異なります。この違いを理解していないとセキュアなアプリケーションの構築が困難、というより不可能になります。
(さらに…)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種類に分けられると思います。
「セキュリティ対策の為に自由を制限する対策”だけ”でなければならない」とする意見を時々見かけます。しかし、これでは必要な仕様を満すソフトウェアが作れなかったり、不必要なコストが要るソフトウェアになったりします。
いくらセキュリティに拘っても安全にならない場合があります。その代表例はソフトウェアの開発環境です。そもそもセキュアにすることが無理な場合、別の対策を取る必要があります。
細かいセキュリティ対策を実施するより、本質を捉えて全体対策を行う方がより安全になる場合があります。開発環境はその代表例です。