投稿元:
レビューを見る
この手の本では久しぶりにヒット。自分のような、「門外漢だけど、仕事上携わることになってしまった人」がにとって、わかりやすく適度な深度でまとめられている。
・品質管理の三つの考え方
一つ目は、「品質は検査で保証するものではなく、設計段階から作り込んでいくもの」 二つ目は、「プロダクトの品質は、母体組織の品質に依存する」、三つめは「プロダクトの品質は(母体組織の品質に依存するのであれば)、経営課題であり、マネジメントが積極的にコミットしなければならない(現場任せにしてはならない)」
・事故によるセッションIDの漏えいを防ぐ
セッションIDをCookieではなく、URLの一部として設定している場合、攻撃ではなく事故によってセッションIDが漏えいしてしまうケースがあります。…
対策として、セッションIDをURLに含めるのは極力避けましょう。
・HTTPのおさらい
・HTTPはリクエストとレスポンスが一対になっている
・GETメソッドは、URLにWebシステムへ送るパラメータを記述する
・POSTメソッドは、Webシステムへ送るパラメータをリクエストボディに記述する
・パスワード変更機能を設計する際の注意点
第一に、パスワード変更は原則として本人が行うようにします。ユーザーがパスワードを忘れた場合も、管理者がパスワードを変更できないようにします。繰り返しになりますが、「本人しか知り得ない」ことがパスワードの原則です。管理者によるパスワードの変更を許可してしまうと、この原則に反することになります。
第二に、パスワードの世代管理を行い、パスワード変更時に複数世代前と同じパスワードを設定させないようにします。同じパスワードを再設定されてしまっては、せっかく定期的なパスワード変更を求める意味がありません。
第三に、パスワードを含む個人情報やセキュリティ設定が変更されたら、登録されているメールアドレスに変更があったことを通知しましょう。個人情報の変更昨日では、メールアドレスそのものが変更されている場合もあるため、変更前のメールアドレスにも送信するようにします。こうすることで、万が一、他人が登録情報を変更した場合でもユーザーが気付けます。
・外部認証
外部認証としては「OpenID」が有名です。OpenIDはさまざまなWebサイトで共通のID情報を利用できるようにした認証方式の一つで、国内では、Yahoo!Japanやmixiなどが自社のIDをOpenIDとして公開しています。
ユーザーはサービスごとに新たにアカウントとパスワードを登録する必要がなくなります。Webサービス提供者側としては、パスワード認証に関する機能を自社で持つ必要がないので、労力を低減できます。
・他のWebアプリケーションと連携
OAuth自体は本来、認証(本人確認)というよりも、Webアプリケーション間でAPIなどを通じて安全にアクセス権を付与するための仕組みです。OAuthを利用するセキュリティ上の利点は以下の通りです。
・他のアプリケーションにパスワードなどの認証情報を保存する必要がない
・他のアプリケーションに提供できる範囲を指定できる
・他のアプリケ��ションに与えた認可を取り消せる