(Last Updated On: 2018年9月13日)ISO 27000（ISMS）をはじめ、セキュアコーディング／セキュアプログラミングを行いなさい、と推奨するセキュリティガイドラインが多くあります。2014年改訂のISO 27000に至っては、セキュアプログラミングが広く普及したのでセキュアプログラミングを行うとする記述に簡素化しています。1 しかし、広く使われているフレームワークでさえセキュアコーディング／セキュアプログラミングをサポートする機能が無かったり／不十分でだったり、現状は到底普及している、とは言えないです。辛うじて普及しているかも？と言えるのはセキュアコーディング／セキュアプログラミングでは枝葉末節にあたるコーディング技術（ああすべき／こうすべき）くらいではないでしょうか？ なぜセキュアコーディング／セキュアプログラミングが普及していないのか？考えられる理由を挙げます

(Last Updated On: 2018年8月13日)前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS（十分短い文字列で指数関数的に実行時間が増加する）が可能なことが判りました。 結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。（特にRubyユーザー） 追記：影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイト

(Last Updated On: 2018年8月4日)私が長年徳丸さんと議論していることをご存知の方も多いと思います。徳丸さんがなぜ論理的に矛盾する主張、明らかにセキュリティ標準規格／ベストプラクティスに反する主張を繰り返えしたのか、その理由が判明しました。それと同時に長年の議論に終止符が打たれ、徳丸さんの考えを完全に理解することができたと思われます。 徳丸さんがセキュリティ対策製品であるWAF（Web Application Firewall）を販売／推奨しつつ、アプリケーション側のファイアーウォールと言える「入力バリデーション」を「セキュリティ対策ではない」と主張されるのは、ジョブセキュリティやステスルマーケティングの類ではないのか？と思えるほどでした。アプリケーションがバリデーションしなければしないほどWAFの有効性は上がり、WAFが売れるでしょう。「WAFはセキュリティ対策」「ア

(Last Updated On: 2018年8月13日)徳丸さんのブログで私のブログ「GHOSTを使って攻撃できるケース」にコメントがあったようなので、好ましいホスト名バリデーションの方法を書いておきます。 特定の低レベルAPIのバグが10年ほど前に書いた本のコードで対応できていない、と議論するのもどうかと思いますがしっかりチェックする場合の例を書いておきます。 そもそもホスト名の仕様はどうなっているのか？ 入力バリデーションを行うには仕様を理解する必要があります。ホスト名の仕様は幾つかのRFCで言及されています。例えば、RFC 2181の11. Name syntaxには That one restriction relates to the length of the label and the full name. The length of any one label is li

(Last Updated On: 2018年8月16日)まずエスケープ処理について全て書こう、ということでPHP Securityカテゴリで様々なエスケープ処理について書いてきました。しかし、「エスケープ処理とは何か？」を解説していなかったので解説します。 エスケープ処理は文字列処理の基本中の基本です。 「エスケープは要らない、知る必要もない」という意見を稀に聞きますが、プログラムに於ける文字列処理とその重要性を理解していないからでしょう。全ての開発者はエスケープ処理の必要性を理解し、確実かつ適切にエスケープできなければなりません。 エスケープ処理の定義 エスケープ処理には複数の役割があります。エスケープ処理とは「エスケープ文字によって、それに続く文字に別の意味を持たせる処理」です。 通常、以下の3つの役割があります。 意味を持つ文字列にエンコードする（文字列に意味を持たせる） キーボー

(Last Updated On: 2018年8月13日)PostgreSQL Advent Calender 2013、13日目のエントリです。 表題の通り「タグ検索するならPostgreSQLで決まり！」です。 追記：JSONの場合はPostgreSQLのJSONB型を利用してタグ検索を行うを参照 RDBはタグが苦手 WebアプリではRDBでは取り扱いづらいデータを取り扱う事がよくあります。タグの管理・検索はその一つです。 RDBはタグ情報の管理・検索をしっかりやれますが、どちらかと言うと苦手な分野です。しかし、PostgreSQLの 配列 GIN（Generalized Inverse Index – 転置インデックス） を使うと簡単かつ高速に処理できます。 PostgreSQLを使うとタグ検索が簡単・高速に実現できますが、Googleで「タグ検索 PostgreSQL」と検索しても

(Last Updated On: 2005年12月22日)プログラミング言語によらずセキュリティ対策には3つの基本があると思います。 1．外部からの入力は信用せず、形式、範囲が想定内か確認する 2．外部システムへ出力を行う場合は適切なエスケープ処理を行う 3．セキュリティ上の問題が発生しても被害を最小限に留める措置を行う 1．の外部からの入力は信用しない、にはユーザからの入力だけでなく他のサブシステムの入力も信用してはならないです。例えばqmailのコマンド郡は同じ作者が作っているにも関わらずお互いに信用していません。 2．の適切にエスケープ処理を行う、はシステムに合った最適なエスケープ処理を行う事が必要です。例えば、システム上のコマンドを実行する場合やSQL文を実行する場合、適切なエスケープ処理は処理系によって異なる場合があります。 3．はfail safe機能は使えるものは使う、とい

(Last Updated On: 2018年8月14日)PostgreSQLのプリペアードクエリを使ったプログラムのユニットテストを書いてユニットテストの書き方の問題に気がつきました。普通にユニットテストを書くと relation with OID ##### does not exist というPL/PgSQLで良く見かけるエラーが発生してしまう場合があります。 通常ユニットテストを書く場合、テストのセットアップ関数(メソッド)で create table test (a text, i int); テスト終了時に drop table test; と書きます。 プリペアードクエリの場合、コンパイルされたSQL文がバックエンドにキャッシュされるので「Web環境などで永続的な接続」を行っている環境でこの様な初期化、終了ルーチンを持つユニットテストでPostgreSQLのプリペアードクエリ

(Last Updated On: 2018年8月13日)PostgreSQL Advent Calender用のエントリです。 エスケープ処理が必要なのにエスケープ用のAPIが無い状態は良くありません。エスケープしないために動かないのはまだ良い方です。エスケープが必要なのにエ スケープをしなくても動いてしまい、セキュリティ上の問題となる場合もあります。全てのアプリケーション・ライブラリはエスケープが必要なデータに対するAPIを持っておくべき です。今回はPostgreSQL 9.0から追加されたエスケープ関数を紹介します。 PostgreSQL使い始めて最初の頃に気づくのはuserなどの予約語がフィールド名に使えない事かも知れません。例えば、 yohgaki@[local] test=# CREATE TABLE user (name text); ERROR:  syntax erro

(Last Updated On: 2018年8月19日)PostgreSQL Advent Calender 2012用のエントリです。 PostgreSQLや他のDBMSを利用していてプリペアードクエリを知らない方は居ないと思いますが、プリペアードクエリを使いこなす為のTIPSです。役に立つかどうか、は多少疑問ですが、内部がどうなっているか知っているとなにかの役に立つかも知れません。時間的制約で多少端折っているところは勘弁してください。 完全なSQLインジェクション対策は以下を参照してください。 完全なSQLインジェクション対策 libpqを知る libpqとはPostgreSQLデータベースサーバにアクセスするためのC言語のライブラリです。PHP,Ruby,Perl,Python,NodeJS,etcはlibpqを利用してPostgreSQLにアクセスするAPIを提供しています。 で

(Last Updated On: 2018年8月13日)SQLのリテラルはエスケープが必要であることは広く認知されていると思います。しかし、識別子のエスケープはあまり広く認知されていないように思います。 PostgreSQLの場合、識別子のエスケープAPI（libpqのPQescapeIdentifier）が提供されておりPHPでもpg_escape_identifier()として利用できます。PostgreSQLの場合は”（ダブルクオート）で識別子を囲むことにより、ダブルクォート無しでは利用できない文字（例えば日本語）も識別子に利用できるようになります。 http://www.postgresql.org/docs/9.3/static/sql-syntax-lexical.html SQLリテラルのシングルクォートをシングルクォートでエスケープするように、SQL識別子ではダブルクォー

(Last Updated On: 2018年8月4日)SQLにエスケープなんて必要ないと考えている方も居るとは思いますが、現実にはエスケープを知っておくことは必須と言っても構わないと思います。 既にSQL識別子のエスケープについては書きましたが、今回はSQLエスケープというよりは安全にSQLデータベース利用する話です。先ずはエスケープの話を全て終わらせよう、と思っているのですがSQLエスケープのエントリが無いので作りました。私のブログを読んでいる方はエスケープ処理、プリペアードクエリの利用方法などはよくご存知だと思うのでここの部分は省略しています。 現在広く利用されているSQLデータベースのほとんどがプリペアードクエリをサポートしています。プリペアードクエリを利用すれば、SQL文とパラメーターを分離できるため、パラメーターがSQL文の一部として解釈されてしまう問題を回避できます。 プリペ

(Last Updated On: 2018年8月20日)ツイッターでの議論を見て「SQLエスケープを教える必要はない」とする原因は「教育の基本」と「セキュリティの基本」の理解不足が「根本的な原因」だと解ってきました。この事についてもブログを書くかも知れませんが、今日は「オレオレSQLセキュリティ教育」、言い換えると「自分の環境に特化したSQLセキュリティ教育」について書きます。一般論・基礎としてのセキュリティ教育は、自分の環境に特化したセキュリティ教育では困る、という話です。 このエントリは「貴方が普段言っている事が間違っている」と非難または攻撃しているのではありません。実務で「プリペアードクエリ・プレイスホルダ・ORMを使いましょう」と言うことは全く間違っていません。セキュリティ教育はこういう手順で教えたほうが解りやすいです、と提案しています。 ツイッターでSQLセキュリティ教育に「エ