Webアプリケーションのセキュリティ の編集履歴

nishikawa が 2016-11-30 23:57 に編集

--- Ver.5	2016-08-27 16:29:34+09:00
+++ Ver.6	2016-11-30 23:57:47+09:00
@@ -671,7 +671,7 @@
  * PBKDF2
  * Argon2
 
-などがあります。これらのアルゴリズムでは、上述したソルトやストレッチングといった要素が盛り込まれているので、自前で実装する必要がありません。Java 8 以上であれば JCA (Java Cryptography Architecture) に PBKDF2 が含まれるので、サードパーティ製のライブラリを必要としません。bcrypt, scrypt, Argon2 については、Java の標準 API には用意されていないので、サードパーティ製の実装を用意する必要があります。
+などがあります。これらのアルゴリズムでは、上述したソルトやストレッチングといった要素が盛り込まれているので、自前で実装する必要がありません。Java 8 以上であれば [JCA (Java Cryptography Architecture) に PBKDF2 が含まれる](https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/SunProviders.html#SunJCEProvider) ので、サードパーティ製のライブラリを必要としません。bcrypt, scrypt, Argon2 については、Java の標準 API には用意されていないので、サードパーティ製の実装を用意する必要があります。
 
 以下は SHA-256 と PBKDF2 でパスワードをハッシュ化する実装例です。SHA-256 のほうでは、自前でソルトとストレッチングを行っています。
 

nishikawa が 2016-08-27 16:29 に編集

--- Ver.4	2016-08-27 16:19:04+09:00
+++ Ver.5	2016-08-27 16:29:34+09:00
@@ -387,8 +387,6 @@
 
 のようなパラメータにすると、パスワードなしに認証を通すことができます。これが SQL インジェクションを悪用した認証回避です。
 
-ちなみにこの例ではサボっているのですが、本来なら GET メソッドでログインできるようにするべきではありません。POST メソッドのみを受け付けるようにしましょう。
-
 他にも、パラメータに
 
 ```sql

nishikawa が 2016-08-27 16:19 に編集

--- Ver.3	2016-08-27 12:50:27+09:00
+++ Ver.4	2016-08-27 16:19:04+09:00
@@ -1,4 +1,4 @@
-Web アプリケーションは HTTP や JavaScript、ブラウザ、HTTP プロトコル、インターネットを介した通信など、脆弱性の入り込む余地が多いものです。脆弱性の多くは開発者の不注意によって作りこまれます。脆弱性とは、悪用できるバグです。
+Web アプリケーションは HTML や JavaScript、ブラウザ、HTTP プロトコル、インターネットを介した通信など、脆弱性の入り込む余地が多いものです。脆弱性の多くは開発者の不注意によって作りこまれます。脆弱性とは、悪用できるバグです。
 
 今回は Web アプリケーションにおける脆弱性を取り上げます。まず、Web アプリケーションの基本となり、かつ脆弱性に対する攻撃で盗む対象になりがちなクッキーとセッション管理について触れます。次に Web アプリケーションで代表的な脆弱性の紹介、攻撃例、対策について触れます。最後に、パスワードの保存方法、認証などのセキュリティを高めることに関するトピックに触れます。
 
@@ -70,7 +70,7 @@
 
 # 代表的な脆弱性と、その対策 #
 
-この章では Web アプリケーションで脆弱性の中でも、作り込みやすいもの、被害が大きくなりがちな脆弱性と、その対策の紹介します。
+この章では Web アプリケーションの脆弱性の中でも、作り込みやすかったり、被害が大きくなりがちな脆弱性と、その対策の紹介します。
 
 ## XSS (クロスサイトスクリプティング) ##
 
@@ -155,13 +155,13 @@
 
 > JSTL 1.2 is part of the Java EE 5 platform.
 
-JSP を利用せず、テンプレートエンジンを利用する場合には、だいたいテンプレートエンジンが変数を展開するタイミングでエスケープされるので、これを積極的に利用したいところです。例えば Spring Boot のデフォルトのテンプレートエンジンである Thymeleaf なら、`th:text` で指定したテキストは自動的に HTML エスケープされます。
+JSP を利用せず、テンプレートエンジンを利用する場合には、テンプレートエンジンが変数を展開するタイミングでエスケープしてくれることが大半です。逆にエスケープをかけたくない場合に、特別なことをしなければなりません。例えば Spring Boot のデフォルトのテンプレートエンジンである Thymeleaf なら、`th:text` で指定したテキストは自動的に HTML エスケープされます。
 
 ```html
 <span th:text="${name}">hogehoge</span>
 ```
 
-上記を Thyemeleaf のテンプレートエンジンに処理させると、パラメータ `name` が HTML エスケープ処理された結果が `&lt;span>` 要素の内容となります (hogehoge は消える)。
+上記を Thyemeleaf のテンプレートエンジンに処理させると、パラメータ `name` が HTML エスケープ処理された結果が `<span>` 要素の内容となります (hogehoge は消える)。
 
 ### URL を持つ属性 ###
 
@@ -457,7 +457,7 @@
 
 この方式ではプレースホルダの段階で SQL 文が確定しないため、ライブラリにバグがある場合、SQL 構文が変化してしまう可能性があります。安全性の観点から言えば、静的プレースホルダよりも劣ります。
 
-JDBC ドライバの実装状況についてざっと調べたところ、Oracle, PostgreSQL, SQLServer のドライバでは静的プレースホルダのみサポートしています。MySQL のドライバではデフォルトで動的プレースホルダ。設定変更で静的プレースホルダを利用できるようです。
+JDBC ドライバの実装状況についてざっと調べたところ、Oracle, PostgreSQL, SQLServer のドライバでは静的プレースホルダのみサポートしています。MySQL のドライバではデフォルトで動的プレースホルダです。設定変更で静的プレースホルダを利用できるようです。
 
 ## CSRF (クロスサイトリクエストフォージェリ) ##
 
@@ -535,7 +535,7 @@
 
 このとき利用するトークンはワンタイムである必要は必ずしもありません。ワンタイムトークンを採用する場合、例えば複数タブを開いた場合など、使い勝手に影響する可能性があります。必要によって使い分けたり、使い勝手に悪影響を及ぼさないようにするべきです。
 
-セッション ID を秘密のトークンとして利用することも (セッション ID が予測可能な値ではないという点では) 可能ですが、不慮の事故によってセッションIDが漏洩してしまったときに備えて、避けるべきです。
+セッション ID を秘密のトークンとして利用することも (セッション ID が予測可能な値ではないという点では) 可能ですが、不慮の事故によってセッション ID が漏洩してしまったときに備えて、避けるべきです。
 
 以下は Java による簡単な実装例です:
 
@@ -570,7 +570,7 @@
 
 などがあげられます。外部からディレクトリパスを指定させないことが基本です。どうしてもそれが避けられない場合には、入力値検証により、予期しないパスへのアクセスを回避するべきです。
 
-以下はファイルIDを用いた対策の簡単な実装例です。ファイルIDをキーとして DB を検索して得たファイルパスを利用してファイルにアクセスしています。
+以下はファイル ID を用いた対策の簡単な実装例です。ファイル ID をキーとして DB を検索して得たファイルパスを利用してファイルにアクセスしています。
 
 ```java
 String fileId = ...;
@@ -584,7 +584,7 @@
 
 ファイルアップロード機能に対する DoS 攻撃、攻撃の仕掛けのあるファイルを利用者にダウンロードさせる、権限を超えたダウンロードといった攻撃が考えられます。
 
-### 対策 ###
+### 対策 (DoS 攻撃) ###
 
 DoS 攻撃は、
 
@@ -601,9 +601,13 @@
  * [Java EE 7 - MultipartConfig](https://docs.oracle.com/javaee/7/api/javax/servlet/annotation/MultipartConfig.html)
  * [PHP: php.ini - ファイルアップロード](http://php.net/manual/ja/ini.core.php#ini.sect.file-uploads)
 
+### 対策 (仕掛けのあるファイルのアップロード) ###
+
 仕掛けのあるファイルをアップロードさせないためには、そもそもアップロード可能なファイルの種類を縛ってしまうのが有効です。画像のアップロードを期待するところで、画像以外のファイル、たとえば PDF をアップロードを拒否するといった具合です。
 
 この対策が取れない場合は、根本的な対策は難しいかもしれません。たとえば悪意のある JavaScript を含む PDF を検出するのは、ふつうの文字列チェックなどに比べれば格段に難しいでしょう。こうした場合は、基本的にはアップロードした側に責任の責任が問われます。が、運営側の責任を問われる場合もあるので、検討段階で加味しておくべき課題です。
+
+### 対策 (権限を超えたダウンロード) ###
 
 権限を超えたダウンロードとは、秘密の領域にアップロードしたファイルを、本来秘密の領域にアクセスできないはずの第三者が閲覧できる状態になっていることを指します。ファイルへのリンクは画面に出ないようになっているものの、URL さえ知っていればアクセスできる、という具合です。
 

nishikawa が 2016-08-27 12:50 に編集


nishikawa が 2016-08-27 12:49 に編集

--- Ver.1	2016-08-27 12:08:52+09:00
+++ Ver.2	2016-08-27 12:49:10+09:00
@@ -1,4 +1,4 @@
-Web アプリケーションは HTTP や JavaScript、ブラウザ、HTTP プロトコル、インターネットを介した通信などなど、脆弱性の入り込む余地が多いものです。脆弱性の多くは開発者の不注意によって作りこまれます。脆弱性とは、悪用できるバグです。
+Web アプリケーションは HTTP や JavaScript、ブラウザ、HTTP プロトコル、インターネットを介した通信など、脆弱性の入り込む余地が多いものです。脆弱性の多くは開発者の不注意によって作りこまれます。脆弱性とは、悪用できるバグです。
 
 今回は Web アプリケーションにおける脆弱性を取り上げます。まず、Web アプリケーションの基本となり、かつ脆弱性に対する攻撃で盗む対象になりがちなクッキーとセッション管理について触れます。次に Web アプリケーションで代表的な脆弱性の紹介、攻撃例、対策について触れます。最後に、パスワードの保存方法、認証などのセキュリティを高めることに関するトピックに触れます。
 
@@ -10,7 +10,7 @@
 
 クッキーは HTTP プロコトル仕様に含まれる機能です。名前=値 の組を、ブラウザ上に保存します。保存したクッキーは、サーバーへのリクエストに付加して送られてきます。サーバーは `Set-Cookie` ヘッダを使うことで、ブラウザに値を覚えさせることができます。
 
-セッション管理は HTTP プロトコル仕様に含まれるものではなく、「考え方」のようなものです。実装方法もいくつかバリエーションがあります。クッキーはクライアントサイドに保存されます。セッションはどこに保存してもよいのですが、サーバー上に保存するのが一般的です。
+セッション管理は HTTP プロトコル仕様に含まれるものではなく、「考え方」のようなものです。実装方法もいくつかバリエーションがあります。クッキーの保存場所がブラウザであると決まっている一方で、セッションはどこに保存してもよいものです。サーバー上に保存するのが一般的です。
 
 セッション管理の事例としてよく挙げられるのは、EC サイトのカート情報です。購入するまでの「カートの中身」を、セッションとして保存しておきます。
 
@@ -20,11 +20,11 @@
  * 通信傍受による情報漏洩の可能性がある
  * サイズ制限がある
 
-など、セッション情報を直接保存するには向きません。そこでクッキーにはセッションを特定するための情報 (セッション ID) だけを保持しておくようにするのが一般的です。しかしこのセッション ID というものは、サイトの作り方次第ではありますが、認証状態に直結することが多いため、外部に漏れるようなことは極力避けなければなりません。クッキーを盗聴され、セッション ID が盗まれると、なりすましの被害を受ける可能性があります。後述する XSS などは、攻撃者がスクリプトを仕込み、クッキーを盗みとろうとする典型です。XSS の脆弱性があったとしても後述する属性を適切に設定し、情報漏洩に備えるべきです。
+など、セッション情報を直接保存するには向きません。そこでクッキーにはセッションを特定するための情報 (セッション ID) だけを保持しておくようにするのが一般的です。しかしこのセッション ID というものは、サイトの作り方次第ではありますが、認証状態に直結することが多いため、外部に漏れるようなことは極力避けなければなりません。クッキーを盗聴され、セッション ID が盗まれると、なりすましの被害を受ける可能性があります。後述する XSS などは、攻撃者がスクリプトを仕込み、クッキーを盗みとろうとする典型です。後述する属性を適切に設定し、情報漏洩に備えるべきです。
 
 ## クッキーの属性 ##
 
-クッキーには 名前=値 の組ごとに、属性を付加することができます。脆弱性という文脈において重要な secure 属性を中心に、クッキーに設定できる属性について触れます。
+クッキーでは 名前=値 の組ごとに、属性を付加することができます。脆弱性という文脈において重要な secure 属性を中心に、クッキーに設定できる属性について触れます。
 
 ### secure 属性 ###
 
@@ -35,11 +35,13 @@
 ```java
 // 秘密のトークンの生成
 String token = generateSecretToken();
+session.setAttribute("token", token);
 Cookie c = new Cookie("token", token);
 c.setSecure(true);
-session.setAttribute("token", token);
 resp.addCookie(c);
-
+```
+
+```java
 // HTTPS ページにおけるトークンのチェック
 Cookie[] cs = req.getCookies();
 if (cs == null)
@@ -163,7 +165,7 @@
 
 ### URL を持つ属性 ###
 
-href や src のような URL を値にとる属性では、`javascript:JavaScript式` で任意の JavaScript の式を評価することができます。ここに攻撃スクリプトを仕込まれる場合、他の属性と同じような対策では不十分です。URL の妥当性 (http:, https: で始まる、など) をチェックしたうえで、他の属性と同じ対策 ("" で囲う、エスケープする) を行えばよいです。
+`href` や `src` のような URL を値にとる属性では、`javascript:JavaScript式` で任意の JavaScript の式を評価することができます。ここに攻撃スクリプトを仕込まれることを考慮すると、他の属性と同じような対策では不十分です。URL の妥当性 (http:, https: で始まる、など) をチェックしたうえで、他の属性と同じ対策 ("" で囲ってエスケープ) を行えばよいです。
 
 何を妥当な URL とするかはアプリケーションによって異なります。以下は単純な例として、http:, https:, / のいずれかで始まるものを妥当な URL であると判定するメソッドです:
 
@@ -233,13 +235,13 @@
 
 ### script タグ内 ###
 
-script タグ内に入力値を埋め込む場合も、特別な対処が必要です。script タグ内では文字参照が解決されないので、HTML エスケープによる対策はできません。JavaScript エスケープ、</ が含まれないようにするという対策が必要です。後者は、script タグ内では </script> が文脈を加味せずに解釈されてしまうためです。
+script タグ内に入力値を埋め込む場合も、特別な対処が必要です。script タグ内では文字参照が解決されないので、HTML エスケープによる対策はできません。JavaScript エスケープ、&lt;/ が含まれないようにするという対策が必要です。後者は、script タグ内では `</script>` が文脈を加味せずに解釈されてしまうためです。
 
 ```html
 <script>alert('</script>');</script>
 ```
 
-このコードには </script> が 2 つ出てきますが、1 つめが閉じタグとして有効です。画面には '); と表示されます。JavaScript としては「閉じられていない文字列リテラルである」ものとして、エラー扱いになります。
+このコードには 2 つの `</script>` が出てきますが、閉じタグとして有効なのは 1 つめです。画面には '); と表示されます。JavaScript としては「閉じられていない文字列リテラルである」ものとして、エラー扱いになります。
 
 そもそも script タグ内に入力値を埋め込むという実装を避けるべきです。外部の入力を JS への入力としたい場合には、より簡単かつ確実に対策ができる、他の手段を採るべきです。たとえば input/hidden を使うといった方法が考えられます。
 
@@ -247,15 +249,7 @@
 
 XSS はサーバーサイドの不具合と考えられがちですが、クライアントサイドでも発生します。JavaScript で生成した HTML を表示する際に発生する XSS を、DOM based XSS と呼びます。サーバー側で生成された HTML には攻撃者のスクリプトが含まれないので、こういう呼び方になっています。最近は JavaScript を使ったアプリケーションが広く利用されており、DOM based XSS も身近な存在になっています。
 
-DOM based XSS が入り込むのは、JavaScript で HTML 文字列を食わせて画面を表示する処理です。例えば `document.innerHTML` への代入や、`document.write` を使っている部分です。また、`window.location` の更新に `javascript:JavaScript式` を与えるようなものも NG です。
-
-対策としては:
-
- * 文字列による HTML 構築ではなく DOM 操作用の API を使う (`document.createElement` など)
- * エスケープする。メタ文字を文字参照に置き換える他にも、`encodeURIComponent` なども適切に利用する
- * 不適切な文字列が含まれないかチェックする
-
-といったところがあります。思わぬところがユーザーの入力になるので、つい対策が見逃しがちになります。例えば `location.href` なども入力になります。クエリパラメータやハッシュには任意の値を設定することができるので、注意が必要です。
+DOM based XSS が入り込むのは、JavaScript で HTML 文字列を食わせて画面を表示する処理です。例えば `document.innerHTML` への代入や、`document.write` を使っている部分です。また、`window.location` への代入も、`javascript:JavaScript式` を使った攻撃が可能です。
 
 以下は脆弱性を持つ実装例です:
 
@@ -301,6 +295,14 @@
 
 こんなハッシュつけてアクセスすると、クッキーを表示するアラートが開きます。
 
+対策としては:
+
+ * 文字列による HTML 構築ではなく DOM 操作用の API を使う (`document.createElement` など)
+ * エスケープする。メタ文字を文字参照に置き換える他にも、`encodeURIComponent` なども適切に利用する
+ * 不適切な文字列が含まれないかチェックする
+
+といったところがあります。思わぬところがユーザーの入力になるので、つい対策が見逃しがちになります。例えば `location.href` なども入力になります。クエリパラメータやハッシュには任意の値を設定することができるので、注意が必要です。
+
 ## SQL インジェクション ##
 
 SQL 発行の実装に問題がある場合に発生する脆弱性です。XSS とならんで Web アプリケーションとしてはポピュラーな(?)脆弱性です。
@@ -428,7 +430,7 @@
 
 もともと文字列連結で指定していた `account` と `password` の検索値は、`?` で置き換えられました。以後、SQL 文そのものを編集することはありません。`account` と `password` は `stmt.setString(int, String)` を使ってパラメータに指定しています。SQL 文のはじめの `?` に `account` が、`?` に `password` がバインドされるよう動作します。
 
-以下は入力値検証oによる対策の例です。`ORDER BY` 句に連結するための入力値に対し、列名として有効な文字列だけを認めるよう動作します。
+以下は入力値検証による対策の例です。`ORDER BY` 句に連結するための入力値に対し、列名として有効な文字列だけを認めるよう動作します。
 
 ```java
 String col = ...;
@@ -559,12 +561,12 @@
 
 外部入力によるファイルアクセスを行う機能において、入力値検証に不備がある場合に発生する脆弱性です。/etc/passwd の内容が参照されてしまったり、ファイルを不正に書き換えられてしまったりします。
 
-対策
+### 対策 ###
 
 ディレクトリトラバーサルへの対策としては
 
-ファイル名を外部から直接指定する設計を避ける
-ディレクトリ名を含めないようにする
+ * ファイル名を外部から直接指定する設計を避ける
+ * ディレクトリ名を含めないようにする
 
 などがあげられます。外部からディレクトリパスを指定させないことが基本です。どうしてもそれが避けられない場合には、入力値検証により、予期しないパスへのアクセスを回避するべきです。
 
@@ -582,6 +584,8 @@
 
 ファイルアップロード機能に対する DoS 攻撃、攻撃の仕掛けのあるファイルを利用者にダウンロードさせる、権限を超えたダウンロードといった攻撃が考えられます。
 
+### 対策 ###
+
 DoS 攻撃は、
 
  * そもそもファイルアップロード機能を無効化する
@@ -593,23 +597,19 @@
 
 Servlet API も 3.0 (Java EE 6) になってファイルアップロード対応しました (それまではサードパーティ製のライブラリが必要だった)。Servlet API においても上記のような設定が可能となっています。
 
-あぱっちの設定へのリンク
-サーブレットAPIへのリンク
-Php.ini へのリンク
+ * [Apache - LimitRequestBody ディレクティブ](https://httpd.apache.org/docs/2.4/ja/mod/core.html#limitrequestbody)
+ * [Java EE 7 - MultipartConfig](https://docs.oracle.com/javaee/7/api/javax/servlet/annotation/MultipartConfig.html)
+ * [PHP: php.ini - ファイルアップロード](http://php.net/manual/ja/ini.core.php#ini.sect.file-uploads)
 
 仕掛けのあるファイルをアップロードさせないためには、そもそもアップロード可能なファイルの種類を縛ってしまうのが有効です。画像のアップロードを期待するところで、画像以外のファイル、たとえば PDF をアップロードを拒否するといった具合です。
 
 この対策が取れない場合は、根本的な対策は難しいかもしれません。たとえば悪意のある JavaScript を含む PDF を検出するのは、ふつうの文字列チェックなどに比べれば格段に難しいでしょう。こうした場合は、基本的にはアップロードした側に責任の責任が問われます。が、運営側の責任を問われる場合もあるので、検討段階で加味しておくべき課題です。
 
-権限を超えたダウンロード
-
-秘密の領域にアップロードしたファイルを、本来秘密の領域にアクセスできないはずの第三者が閲覧できる状態になっていることを指します。ファイルへのリンクは画面に出ないようになっているものの、URL さえ知っていればアクセスできる、という具合です。
+権限を超えたダウンロードとは、秘密の領域にアップロードしたファイルを、本来秘密の領域にアクセスできないはずの第三者が閲覧できる状態になっていることを指します。ファイルへのリンクは画面に出ないようになっているものの、URL さえ知っていればアクセスできる、という具合です。
 
 このようなファイルアクセスにおいても、「リンクがないからアクセスできないはず」というような前提を作らず、認可の実装が必要です。
 
-認可で DB との連携が必要な場合、アプリケーションサーバーで実装します。認可後のファイルの配信は HTTP サーバーに任せてしまうのが効率的です。一般的には、アプリケーションサーバーよりも HTTP サーバーの方がデータの転送に長けています。実現するには X-Sendfile などを利用するとよいです。
-
-https://tn123.org/mod_xsendfile/
+認可で DB との連携が必要な場合、アプリケーションサーバーで実装します。認可後のファイルの配信は HTTP サーバーに任せてしまうのが効率的です。一般的には、アプリケーションサーバーよりも HTTP サーバーの方がデータの転送に長けています。実現するには [X-Sendfile](https://tn123.org/mod_xsendfile/) などを利用するとよいです。
 
 # 安全な Web アプリケーションのための設計と実装 #
 
@@ -644,7 +644,7 @@
 h = hashfn(salt + password)
 ```
 
-乱数からソルトを決定する方法も考えられます。この場合、再計算によってソルトを求めることができないので、パスワードとあわせてソルトを何かしらの方法で保存しておく必要があります。`bcrypt` などでは、ハッシュ化したパスワードに連結する形でソルトを保存します。
+乱数からソルトを決定する方法も考えられます。この場合、再計算によってソルトを求めることができないので、パスワードとあわせてソルトを何かしらの方法で保存しておく必要があります。たとえば bcrypt では、ハッシュ化したパスワードに連結する形でソルトを保存します。
 
 ハッシュ関数を 1 回だけでなく複数回かけて最終的なハッシュ値を得るという実装方法を、ストレッチングと呼びます。攻撃者はアプリケーションが何回ハッシュ化関数をかけているかを知らない限り、パスワードを特定することができません。
 
@@ -656,9 +656,9 @@
 
 この繰り返し回数を可変とする場合も、乱数ベースのソルトと同様、パスワードとあわせて保存しておく必要があります。
 
-#### アルゴリズムの選定 ####
-
-MD5, SHA-1 などはいわゆるメッセージダイジェストと呼ばれる類のデータ (ハッシュ値) を生成する目的で作られたアルゴリズムです。このため比較的高速に計算できるようになっており、これは攻撃者にとって有利な条件となってしまいます。可能ならば、パスワードの保存向けに設計されたアルゴリズムを使うのが望ましい。
+### アルゴリズムの選定 ###
+
+MD5, SHA-1 などはいわゆるメッセージダイジェストと呼ばれる類のデータ (ハッシュ値) を生成する目的で作られたアルゴリズムです。メッセージ全体を比較することなく、メッセージの内容が同一であるかを手早くチェックするという目的のために利用されます。このため比較的高速に計算できるようになっています。これは攻撃者にとって有利な条件となってしまいます。可能ならば、パスワードの保存向けに設計されたアルゴリズムを使うのが望ましいです。
 
 パスワードの保存向けに設計されたアルゴリズムは、あえて計算負荷が高くなるように設計されています。これはハッシュ関数を大量に呼びださなければならない攻撃者にとって都合が悪い状況を作るためです。ログイン処理に時間がかかるようになってしまいますが、多くの場合は、一度のログイン処理で多少の時間がかかるようになったところで、使い勝手に与える影響は小さいと考えられるでしょう。
 
@@ -706,7 +706,7 @@
 
 認可を行う際には、大半の場合は認証を伴います。そのため、OAuth を認証のために利用するケースもあるようです。しかし OAuth はあくまでも認可のためのプロトコルであり、[認証のために利用することは安全でない](https://www.sakimura.org/2012/02/1487/)という意見も多い。
 
-OpenID Connect は OAuth 2.0 上に構築した認証プロトコルです。OpenID Foundation が管理しています。認証は OpenID Connect で、以後の認可は OAuth 2.0 で、という住み分けのようです。
+[OpenID Connect](http://openid.net/connect/) は OAuth 2.0 上に構築した認証プロトコルです。OpenID Foundation が管理しています。認証は OpenID Connect で、以後の認可は OAuth 2.0 で、という住み分けのようです。
 
 # 参考 #
 

nishikawa が 2016-08-22 00:22 に投稿