VMware 14にはパッチがでるそうです。まだ12を使っているので以下のパッチが必要でした。13にアップグレードする意味はなさそうだったので12のままでしたが、そろそろ14にアップグレードする時期のようです。
-
ソフトウェアセキュリティのアンチパターン
アンチパターンを知ることにより失敗を防ぐ。これはデータベース設計やソフトウェア設計で多く利用されている手法です。今回はソフトウェアセキュリティのアンチパターンを紹介します。
このエントリは不定期にメンテナンスするつもりです。
-
なぜセキュアなシステムが作れないのか?
なぜセキュアなシステムが作れないのか?この問いは
なぜバグフリーのシステムが作れないのか?1
と同類の問いです。一定規模を超えると完全にバグ/問題がないシステムを作るのは非常に困難です。どのような状況でも正常に動作する完全にバグ/問題がないシステムは簡単には作れません。しかし、バグ/問題がないシステムが容易に作れないからといって「体系的な対策を行わない」のは賢明なアプローチではありません。
このエントリではよりセキュリティ問題が少くなるアプローチを紹介します。これはセキュリティ標準やガイドラインに記載されている考え方をまとめたモノです。
ポイントは
- 構造化が大事
- 基礎が大事
- 目的が大事
です。
-
PHP用入力バリデーションモジュール – validate
ブログで紹介するのを忘れていました。PHP用の入力バリデーションモジュール validateを作りました。
https://github.com/yohgaki/validate-php
PHP開発MLでの議論用に作ったので、作りかけと言える状態ですが、一応動作し使えます。
関数名はvalidate()の方が良いのでは?という意見があったので、名前は変更する予定です。valid()にしていた理由は”validate”だとあまりに一般的過ぎて、同じ名前の関数を定義しているユーザーがいるだろう、と予想したからです。自分のアプリやライブラリには名前空間を使うべきなので、モジュール関数はvalidate()にします。
いろいろ意見があったのですが、やはり入力処理における入力バリデーションとロジック処理の混同がありました。
入力処理における「形式的バリデーション」とロジック処理における「論理的/仕様的バリデーション」は別処理とした方が、構造的に優れています。この理由はまたの機会に書きます。
-
Python 2.7.14から学ぶセキュリティの基本
Python 2.7.14が2017/9/16にリリースされました。Pythonの開発はバージョン3系に移行しており、2系はセキュリティ修正のみのリリースになっています。とは言ってもモジュールの変更を見るとバグフィックスやドキュメント修正も含まれているようです。
Python 2.7.14のリリースはソフトウェアセキュリティの基本を学ぶには良い題材になります。
-
Fedora 26でVMware Workstationを利用する方法
Fedora 26でVMware Workstation Pro 12を使うことは可能です。可能ですが、少し手間が必要です。
追記: 2017/12現在、Fedora 27 + VMwareWorkstaion Pro 14を利用しています。この組み合わせの場合、普通にインストールするだけで利用できます。
-
Intel Graphics for Linuxの更新ができない
先日、Fedora 25から26にアップグレードしました。特に問題なく使えているのですが、Intel Graphics for Linuxが更新されていない事に気がつきました。Intel Graphics for Linuxを更新する方法の備忘録です。インストール方法もほぼ同じです。
-
セキュリティ対策が論理的に正しいか検証する方法
全てのセキュリティ対策は緩和策だと考えるべきです。これは個々の対策が完全であるか検証することが容易ではないからです。例えば、SQLインジェクション1つとっても本当に完全であるか?検証することは容易ではありません。プログラムが本当に思っているように動作するのか?検証する研究は、まだまだ研究段階です。
しかし、容易ではないからといって諦める訳にもいきません。不完全であっても形式的な論理検証は容易にできます。
-
本当にプリペアードクエリだけを使っていますか?
'SELECT '.pg_escape_idetifier($_GET['col']).' WHERE '.pg_escape_identifier('tbl').' ORDER BY '.pg_escape_idetifier($_GET['col'])SQLクエリにはプリペアードクエリを使いましょう!と言われて久しいです。私もプリペアードクエリを積極的に使うべきだと考えています。
- 多くの場合、速い
- SQLパラメーターを分離して書くので「ついうっかり」が起こりにくい
- 特に初心者は「ついうっかり」が多い
しかし、「プリペアードクエリだけを使っていれば良いので、エスケープは要らない」という意見には賛成できません。なぜ賛成できないのか?コードを見れば分かります。
何年か前に議論になった話題です。自分のエントリを検索して、たまたま見つけたのですが物がありました。
例えば、入力バリデーションなしで以下のようなクエリは絶対に安全に実行できません。
$result = pg_query_params('SELECT '.pg_escape_identifier($_GET['col]). ' FROM '.pg_escape_identifier($_GET['table']). ' WHERE id = $1', [$_GET['id']]);こんなクエリをそのまま書く人は居ませんが、プリペアードクエリ”だけ”ではインジェクション対策にならない事はSQLを知っていれば学生でも理解ります。
特定カラムの抽出/ソート(これはエスケープでぼほOK)、テーブル指定をするクエリは当たり前に存在します。
-
DBMSの脆弱なAPI仕様は何時まで放置されるのか?
広く使われているデータベースでもAPIが仕様として脆弱な物が長年放置されています。OracleやMS SQL Serverを利用している方ならよくご存知だと思います。
-
ネットワークから学ぶソフトウェアセキュリティの基礎
Slideshareで「ネットワークから学ぶソフトウェアセキュリティの基礎」を公開しました。
ネットワークの世界で”当たり前”のセキュリティアーキテクチャーですが、残念ながらソフトウェアの世界では”当たり前”ではありません。
必要なセキュリティ対策やアーキテクチャーは状況やニーズによって変わります。セキュリティについて様々な考え方を持つことは構わないのですが、基礎中の基礎は”適用しないとしても”普遍です。
https://www.slideshare.net/yohgaki/ss-79410254