Memcachedはテキストプロトコルとバイナリプロトコルの二種類を持っています。デフォルトはテキストプロトコルです。テキストプロトコルを利用している場合、テキストインターフェース処理の基本を理解した上で利用しないとセキュリティ問題が発生します。こういった処理のセキュリティ対策を行う、確認するには実は標準の方が簡単で明解 – セキュリティ対策の評価方法も参考になります。
Memcachedはキーバリュー型なのでSQLインジェクションのような脆弱性とは無縁、と思っていた方は是非読んでみてください。
なぜセキュリティ対策の区別が異なるのか？長年疑問だったのですが、その理由の一つが判りました。
以下は、本質的には似たような入力確認である「WAFはセキュリティ対策」で「入力バリデーションはセキュリティ対策ではない」のか？と質問した時のツイートです。
@yohgaki どちらもセキュリティ上効果がありますが、WAFはセキュリティを主目的として、というよりセキュリティのためだけに導入するのに対して、バリデーションはセキュリティが *主目的ではなく* 元々実施すべきものだという主張です
— 徳丸 浩 (@ockeghem) February 6, 2015
どうも「目的」がセキュリティ対策であるか否か、の基準のようです。「セキュリティ対策の定義」が曖昧という問題もありますが、ここでは省略します。
項目を切り出して独立したブログエントリにしておく方が良いと思い書きました。IoT時代（IoT時代でなくてもですが）に最も必要なセキュリティ対策は厳格な入力バリデーションです。
セキュリティ対策としの入力バリデーションはIoTでは更に厳格に行う必要があります。
IoT時代のセキュリティ対策として入力バリデーションが強化が必要なのは、クラウドやレンタルサーバーサービスでWAFを導入する必要性が高いことと同じ理由です。これらのサービス業者はIoTと同様にソフトウェアをバージョンアップすることが非常に困難です。入力バリデーションを強化するのはソフトウェアのバージョンアップより更に困難です。このため、効率悪くや確実な防御が困難なWAFであっても導入しているサービスが多いです。
IoTデバイスを作る場合、非常に厳格な入力バリデーションを行うべきです。
参考：Onion Omega
本来、現在のISO 27000を紹介するべきですが元のブログは敢えて古い標準を使いたかったのでISO 17799を紹介しています。基本的な部分は変わっていません。
以前からセキュリティ対策の本質や定義について何度かブログを書いたり、講演もしてきましたがなかなか理解できない方も多かったです。その構造は
ニュートン力学と相対性理論の理解の壁
これと似ているのでは？と思い書き始めました。「エンジニアのセキュリティ対策理解の壁」は「ニュートン力学と相対性理論の理解の壁」と同類ではないでしょうか？
特に入力バリデーションはセキュリティ対策の基本ではない、と勘違いしている方は続きをご覧ください。
徳丸さんのブログで私のブログ「GHOSTを使って攻撃できるケース」にコメントがあったようなので、好ましいホスト名バリデーションの方法を書いておきます。
特定の低レベルAPIのバグが10年ほど前に書いた本のコードで対応できていない、と議論するのもどうかと思いますがしっかりチェックする場合の例を書いておきます。
「glibcのGHOST脆弱性の内容と検出」はしっかり調べた上で書いていなかったので別エントリとしてまとめておきます。
追記：簡単だったので書かなかったのですが、バリデーション方法がない、とのご意見があったので「ホスト名バリデーションのやり方」を書きました。こちらもどうぞ。
追記：新しいgetaddrinfo問題の方はこちら
glibcのgethostbynameのバッファーオーバーフローバグであるGHOSTがどのようなバグだったのか気になったので調べてみました。Twitterで「GHOSTは4バイトだけオーバーフローする」といったツイートを見かけたことが調べはじめた切っ掛けです。
追記だらけになって解りづらいので別エントリでまとめています。
http://blog.ohgaki.net/glibc-ghost-revisited
参考：より新しいglibcのgetaddrinfoの問題はこちら
久しぶりのSoftware Design (ソフトウェア デザイン) 2015年 02月号 [雑誌]
に寄稿させていただきました。テーマは「開発者は、セキュリティ問題を自己解決できるのか？」です。Software Designの見本と一緒に別冊の「インフラエンジニア教本 ~ネットワーク構築技術解説 (Software Design 別冊)
Phalcon Adventカレンダー18日目として書いています。
一台のアプリケーションサーバーで10リクエスト/秒で十分というサービスであれば、どんなプラットフォームを選んでも問題ありません。一台のサーバーが10リクエスト/秒しか処理できなくても、ページがキャッシュできるならリバースプロキシで簡単に数千リクエスト/秒以上でサービスできます。このようなサービスであればPhalconのようなフレーワムワークを使わなくても大丈夫です。
しかし、メッセージング系などリアルタイム性の高いサービス、つまりHTTPキャッシュがあまり有効に利用できないシステムでは速度が非常に重要です。
SQLiteはファイルベースのオープンソースRDBMSです。オープンソースとしては珍しいパブリックドメインライセンスを採用しています。SQLiteはファイルベースなのでデータベースサーバーが必要なく手軽に利用できます。SQLiteは組み込みデバイスで広く利用され、Android/iOSなどでは標準的なデータベースとして利用されています。モバイルデバイス以外での利用も広がっており例えば、Drupal8はSQLite3に対応しています。
普通のRDBMSのようにSQLクエリが利用できるのでとても便利ですが、SQLiteの仕様は他のRDBMSと異なるので注意が必要です。
追記：論理的・体系的セキュリティを構築していれば、ここに書かれているようなセキュリティ上問題となる事を自身で分析／対応できるようになります。
昨日書いた安全なAPI過信症候群の処方箋 – execv/SQLite3編はSQLiteの仕様がRDBMSとしてエキゾチック過ぎて、さらっと書いたよくあるRDBMSでの「安全なAPI過信症候群」を全く理解して頂けなかったケースもあるようなのでもう一度書きます。
プリペアードクエリには色々問題もあり、セキュリティ対策としてそれだけ教えるのはNG、と考えている方はプリペアードクエリ過信症候群ではないので、このエントリを読む必要はありません。
またプリペアードクエリなど、安全とされるAPI万能と考えている方に会ったのでエントリを書きました。広く病気として治療すべき、と思いエントリを書きます。安全なAPI過信症候群と名付けました。
安全なAPI過信症候群（同類にプリペアードクエリ過信症候群など）：「安全」とされるAPIを使えば安全と、盲目的に信用し考慮すべきリスクを考えない症候群。ITエンジニアが発症し最も重要なセキュリティ対策である入力バリデーションを「必要ない、できない、セキュリティ対策ではない」エスケープは「必要ない、有害である」とする場合、かなり重度の場合が多い。
このブログでは既に何度もプリペアードクエリクエリは不完全である、と指摘しています。プリペアードクエリを使っていれば安全と盲目的に信じている方向けの基礎知識を紹介します。コマンド実行APIのexecvと最も多く利用されているRDBMS、SQLite3が題材です。
現実を知れば安全とされるAPIを盲信することも危険だと解り、安全なAPI過信症候群を完治できると思います。
The Pirate Bay（TPB）と言えば、世界最大のtorrentサイト、著作権違反サイトとして有名です。実際、サイトの運営者は起訴され刑務所に収監されています。にも関わらずTPBは現在も運用されています。
TPBは世界TOP100のサイトで毎日何百万ものユニークビジターが訪問しているサイトです。HOW THE PIRATE BAY REMAINS UNTOUCHABLEにTPBのシステム構成がどのようなものか紹介されています。
ソフトウェア開発において開発者はセキュリティ問題を自己解決できるのか？それとも自己解決できないのか？どちらが正しいのか考えてみます。
もう十年以上前に書いた本でプロアクティブなセキュリティ対策が重要と書いていたと思います。OWASPのプロアクティブコントロールTOP10を紹介します。
