MugeSoの日記 このページをアンテナに追加 RSSフィード

2016-02-19

[][][] OpenAPI(Swagger)でいい感じに自動テストさせるためのベンダー拡張を考えてみた。

定義するのは下記の二つ

  • Path Item Object の x-create-operation
  • Parameter Object の x-found-in

x-create-operationはそのリソースを作成するための操作のoperationIdを指定する

x-found-inはパラメーターを取得するためのoperationとパラメーターがレスポンスのどこにあるかを示すオブジェクトあるいは同オブジェクトを共通定義した#/x-found-ins/以下へのReference Objectをしていする。

パラメーターの所在は指定はParameter Objectと同じように行えばいい。

APIによる生成・参照が不可能なやつはこれらの値を設定しない。

これによって、依存するオペレーションが明示されるので、

(再帰参照になっていない限り)いい感じにテストができるはず。

2013-11-18

[][]続フレームワークの責務とセキュリティ

先日のエントリに対してさまざまな反応を戴きました。ありがとうございます。

今回はその中からいくつかを取り上げていきたいと思います。

最低限であるという認識は僕も同じです。

こちらについては誤解があるようです。

今回の件に関してはまず前提としてBasic認証の実装です。他の認証についてはおっしゃるようにフレームワークでは何ら規制も規定するという訳ではありません。また、平文パスワード保存については積極的に提供しないというだけであり、必要な状況に応じて実装することをフレームワークで禁止するということでもありません。

平文パスワード保存をフレームワークで安易に提供してしまうと、その危険性を理解していない開発者が利用用途が適切でない場面で乱用してしまう可能性が高まるため、十分な注意喚起を最低限としてできれば提供を避ける(=障壁を設ける)べきだということです。

PRでも僕は下記のように言及しています。

拡張・変更が容易なようにDIやAOPを導入しているのでエッジケースには対応しないというのであれば、

むしろ、プレーンテキストでパスワードソースコードに記述しなければいけないような危険な要件はエッジケースとして扱って実装対象から外すべきだと僕は思います。

その他、koriymさんを殴る殴らないというコメントもありましたが、たった1度の意見の対立で暴力に訴えるとかどんな世紀末ですか。

ちなみに今夜はローストビーフを仕込んでいます。

f:id:MugeSo:20131119073146j:image

2013-11-16

[][] フレームワークの責務とセキュリティ

お久しぶりです。 夜中にモツ煮込み作りながら書いてます。

さて、今回はフレームワークの責務とセキュリティについて思うところがあって久しぶりにエントリを書くことにしました。

背景

まず、背景としてBEAR.Sundayの一部であるBEAR.PackageにサンプルとしてBasic認証の実装を追加するPullRequest#90でのやり取りがあります。このPRはzukimochiさんが作ったものに僕が修正を加えて出した物です。この中では、Basic認証用のパスワードハッシュとして扱うように実装されています。

多くの人が斜め読みしているのは背景説明が長すぎるからだと思ったので削除しました。詳しく知りたい方はPRをご覧ください。

本題

いよいよ本題です。 PRの最後にkoriymさんが発言している次の言葉はフレームワーク開発に於いてとても重要です。

より関心のある問題に集中するために、特に専門としていない問題に注力しすぎないようにするために役立てているのです。

言い換えれば、「余計な機能作ってる暇あったらよりいいフレームワーク作ろうぜ!」といったところでしょうか。この考えをもとに開発することによってフレームワークは肉を削ぎ落して、骨格だけをもつ枠組みとしてより洗練されていきます。

そこで重要になってくるのが、削ぎ落すべきものと削ぎ落してはならないものの線引きです。先のPRでの問答は「生パスワードのセキリティリスク」がその線の内か外かあるいは内側の場合どう対処するのかの議論になります。ちなみに、本エントリのタイトル「フレームワークの責務とセキュリティ」の責務とは境界線の内側のことです。

では、この実装がフレームワークの実装として取り込まれるという前提で話を進めましょう。

ここで、生パスワード保存機能を削ぎ落さずにリリースした場合に想定しうるセキュリティリスクを考えてみると、こんなシナリオが浮かびます。

  1. 開発者が生パスワードを設定ファイルに書く形で管理画面のアクセス制御を行うアプリケーションを作成
  2. アプリケーション利用者AがSNSでも利用しているパスワードを設定ファイルに書きインストール
  3. アプリケーションバグ(ディレクトリトラバーサル脆弱性)を利用し攻撃者がパスワード設定ファイルを取得
  4. 攻撃者がアプリケーション利用者AのSNSアカウントを乗っ取る

より具体的にしました

これは、PRで挙げた問題点の具体例ですね。

では、このセキュリティリスクに対する責務はフレームワークにあるのでしょうか? それとも、フレームワークの本質ではないと切り捨てるべきでしょうか?

僕はフレームワークの責務であると考えます。 提供する機能がセキリティリスクを抱えているのであれば当然です。フレームワークに余分な複雑さを持ち込みたくないのは分りますし、一般にはそうあるべきですが、セキュリティリスクが絡む場合はリスク回避もフレームワークの責務です。

ならばどうすればいいのか、選択肢は3つほどあります。

1つ目は、問題の機能自体を切り捨てることです。 もしフレームワークの本質を損なわないのなら切り捨ててしまえば簡単です。フレームワークが十分な拡張性を持っているならば、第三者による実装に期待することができます。

2つ目は、セキュリティリスクを抱えていることをフレームワークの利用者(=アプリケーション開発者)に対して周知徹底することです。 マニュアルやソースコード中のコメントにわかり安く注意事項を表示します。先のシナリオでは開発者が広く一般に使われるアプリケーションを生パスワードを利用する形で実装しなければ、リスクは回避できたわけです。消極的な対策であり、マニュアルをきちんと読まない開発者を想定するとまだリスクは残りますが、責務を果たしていると言えるでしょう。

3つ目は、リスク排除した実装を提供することです。今回で言えば、生パスワード保存を提供せず、適切なハッシュ化などを用いたパスワード保存のみを提供します。 こちらも、生パスワード保存機能を自分で開発して利用してしまう開発者というリスクはまだあるわけですが、それを言い出したらさすがにきりがないですし、水が低い方に流れるように、開発者も楽に実装できる方に流れるのできっとハッシュ化されたパスワード保存を利用してくれるでしょう。(これがPRでの僕の主張です)

最終的にどれを選択するかはリードコミッターやプロダクトオーナーの采配によることになりますが、何も対策しないというのはあり得ません。オープンソースでタダで開発していても、その倫理的責任から逃れることはできません。

また、3つ目の積極的な解決方法を容易にとることができるのであれば、2つ目を採用するのではなく3つ目で対策を行うべきでしょう。責任の範囲内ではベストエフォートをなすべきです。

結論

フレームワークを含め、プロダクト開発に於いてはセキュリティリスクを常に考え、適切な対策を講じるべきである。

セキュリティの専門家の方からのご意見も頂けたら嬉しいですね。

さて、モツ煮がいい感じに出来上がったので味見してきます。 よい週末を。

f:id:MugeSo:20131117061135j:image

2013-10-06

[][]今あるJSONベースのHypermediaフォーマット仕様まとめ

RESTful Web APIsをよんだりなんだりして、JSONベースのHypermediaフォーマットに興味が出たので調べてみました。

ここで紹介するフォーマットは2013年10月6日現在どれも策定段階です。

リスト化するに当たりググってもパッとしなかったので、IANAに登録されているmedia-typeのうち"+json"を接尾辞に持っているものからそれっぽいモノを選びました。

Collection+JSON

その名の通り、コレクション(を含む)リソースのための仕様です。

この仕様ではコレクションの参照だけではなく、コレクションに対する追加・更新・削除操作に言及しています。

Collection.next+JSON

上記Collection+JSONの拡張し、より複雑な定義をできるようにしています。

追加されている主な機能は下記になります。

Siren: a hypermedia specification for representing entities

サブタイトルの示す通り、エンティティ(リソース)を表現するための仕様です。

Collection+JSON系と異なり、エンティティの表現方法についても言及しています。またフォーム表現も充実しており、柔軟に追加・更新を行えます。

JSON-LD

DocJSON

JSON API

HAL

2013-04-02

株式会社VOYAGE GROUPを退職し、ウェブニウム株式会社を設立しました。

お久しぶりです。アドベントカレンダー以来の投稿となりますね。

さて、この度、3月31日付でVOYAGE GROUPを退職しました。

PHPカンファレンス2011の翌日の2011年9月12日に株式会社ECナビに入社し、翌10月に株式会社VOYAGE GROUPに社名変更、その後MBOを行いIPOを目指すと宣言する、という激動の時期に内部で関わることができました。

私の入社した頃はVOYAGE GROUP内のエンジニア陣が強化される時期でもあり、元々いた優秀なエンジニアに加えて様々な分野からの中途組と一緒に仕事をしたり、部署の違う方とは社内勉強会などを通じて刺激を受けることができました。 また、それまで経験してこなかった、専任のインフラチームが居る環境で働くことを通じても多くのことを学ぶことができました。

VOYAGE GROUPという会社は、コーポ―レートカルチャーの推進に専任担当者を設けていて、半期に1度の総会やVOYAGE CUPという運動会、クリスマスなどの年中行事などの刺激と楽しみに満ちたとても良い職場でした。

また、福利厚生として四半期ごとに加入できるサークル活動を通じて1年前からボルダリングを始めました。 本当に楽しい活動で、この活動を通じてCTOの小賀さんとも親しくなることができました。 今後もボルダリングサークルの活動にご一緒したいと思っています。

自分の中の予定では、もっともっと、VOYAGE GROUPの一員として働き続けるつもりでした。本心からそう思っていました。 それくらい働き甲斐のある会社でした。

けれど、漢には夢があります。

僕の夢は、いつか、信頼できる人とともに会社を興し、日本にそして世界に誇れるサービスを創りたいというものです。 僕はトップになれる性格ではないので、社長にはなれそうもないのでパートナーが必要なのです。

そして、ついに、信頼できるパートナーにめぐり合うことができ、2013年4月1日にウェブニウム株式会社を設立いたしました。

これからは、一従業員という立場を卒業し、取締役CTOとして精進していきます。 改めて、よろしくお願いします。

ウェブニウム株式会社@facebook