ウェブ権限検証方法の説明[再現]

序文

この記事では、HTTP基本認証、といえば、パーミッションのクッキーや認証トークン、署名、最後はワンタイムパスワードであるに基づいて、最も基本的な権利からウェブを検証します。

HTTP基本認証

クライアントが要求を開始すると、それは、アクセス許可を確認するために、ユーザー名とパスワードを提供するために、HTTP基本認証を使用することができます。

それはなど、外部要因のクッキー、セッション、に依存しないので、それは許可を確認する最も簡単な方法があります。それを使用する場合、クライアントが付属して、各要求を必要とするAuthorizationリクエストヘッダ、ユーザー名とパスワードは暗号化されていませんが、ニーズは、次のような構造にフォーマットします：

ユーザー名とパスワードは、コロンで接続されている、などusername:password
Base64でエンコードされるこの文字列の必要性
Basicカテゴリーは、符号化後の文字列の前に配置する必要があります

例：

curl --header "Authorization: Basic am9objpzZWNyZXQ=" my-website.com

でNode.js達成することは、以下により、非常に単純であるExpressミドルウェアを達成するための例：

import basicAuth from 'basic-auth';

function unauthorized(res) { res.set('WWW-Authenticate', 'Basic realm=Authorization Required'); return res.send(401); }; export default function auth(req, res, next) { const {name, pass} = basicAuth(req) || {}; if (!name || !pass) { return unauthorized(res); }; if (name === 'john' && pass === 'secret') { return next(); } return unauthorized(res); };

もちろん、あなたものような、より高いレベルでそれを実装することができますnginx。

HTTP基本認証は非常にシンプルですが、注意を払うのにはいくつかの必要性はまだありますが。

ユーザー名とパスワードが要求がその場所への潜在的な暴露である安全な接続、経由で送信された場合でも、すべての要求に置かれます。
サイトの用途の暗号化方式は非常に弱い、または侵害された場合は、ユーザー名とパスワードはすぐに明らかにされます。
ユーザーはこの方法で認証し、外の方法はありませんされている場合
同様に、着地残業はそれを行うための方法はありません、あなただけのユーザーのパスワードを変更することによってシミュレートすることができます。

クッキー

ときにHTTPリクエストに応じて、サーバは、あらかじめプラスに応答することができますSet-Cookie頭。これは、ブラウザのクッキー、およびそれに続くアドレス相同要求に保存されますCookieこれらのCookieリクエストヘッダを付けます。

アクセス許可を確認するためにクッキーを使用する場合は、次の点に注意する必要があります。

クッキーは常に設定されています`HttpOnly`

クッキーを設定するときは、必ず使用HttpOnlyクッキーがでないことができるようにするので、ロゴをdocument.cookies取得、XSS攻撃の可能性を低減します。

必ず署名（署名）クッキーを使用

署名クッキーを使用する場合は、サーバーはクッキーを変更し、クライアントであるかどうかを判断することができます。

不十分：

これは、CSRF攻撃から守るために余分な労力を要します
RESTスタイルと一致していません。それはステートレスプロトコル状態で注入されるからです。

トークン

今日では、どこでもJWT（JSONウェブトークン）。さんのような最後の外観で、それを見てみましょう。

JWTは、3つの部分から構成されています。

Headerハッシュアルゴリズムトークンの種類や組成によって
Payload、それはメインのコンテンツが含まれています
Signatureあなたは構成されていHMAC SHA256アルゴリズムを選択するとHMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)ドロー計算を。

お使いのKoaアプリケーションに加えてJWTわずか数行のコード：

var koa = require('koa');
var jwt = require('koa-jwt'); var app = koa(); app.use(jwt({ secret: 'very-secret' })); // Protected middleware app.use(function *(){ // content of the token will be available on this.state.user this.body = { secret: '42' }; });

例：

curl --header "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ" my-website.com

あなたがモバイルアプリケーションまたは単一ページのウェブアプリケーションを提供するために、ネイティブAPIを書いている場合は、JWTは良い選択です。

不十分：

追加の対策がXSS攻撃を保護するために必要

署名

あなたのコンテンツが他人に傍受され、送信された場合に、クッキーやトークンを使用するかどうか、そして、彼らは本当のユーザーを装っ得ることは非常に簡単になります。

あなたはこの問題を解決した場合は？私たちはAPIではなく、ブラウザ間の通信の間の通信について話しているときは、方法があります。

APIの消費者が必要な権限を確認するためのリクエストを送信するときは、全体の要求に秘密鍵でハッシュすることができます。あなたが要求の内容を使用することができます：

HTTPメソッド
リクエストパス
HTTPヘッダー
HTTP体
そして、秘密鍵

APIのコンシューマとプロバイダが同じ秘密鍵によって保持されなければなりません。世代ではsignature後に、あなたはに追加する必要がありますquery stringまたはHTTPヘッダー。さらに、期限切れの決定のためのタイムスタンプを添付する必要があります。

その際、それは自分自身を生成することはできませんので、あなたは、コンテンツの伝送にさらされた場合でも、攻撃者は、実際のユーザーになりすますことができませんsignature。

不十分：

ブラウザ/クライアントでは利用できません、唯一のAPIとの間の通信に使用することができます。

ワンタイムパスワード

タイムパスワードアルゴリズムは、ワンタイムパスワードを生成するために、共有キーおよびタイムスタンプまたはカウンタの現在を使用しています。

現在の時刻のタイムスタンプを使用して時間ベースのワンタイムパスワードアルゴリズム、
カウンターの使用に基づいてHMAC-タイムパスワードアルゴリズム

ユーザーは、ユーザー名とパスワードを入力し、サーバとクライアントがワンタイムパスワードを生成します。これらのメソッドは、ここで二要素認証（二要素認証）のために使用されています。

でNode.js使用してnotp実現することは比較的簡単です。

不十分：

共有鍵が盗まれた場合、ユーザーのトークンが偽造されます

どのような方法で検証時に選択するには？

あなたが唯一のWebアプリケーションをサポートする必要がある場合には、クッキーとトークンを達成は、（より良いXSRFに対するクッキーの保護、およびJWT保護XSSに簡単です）が可能です。

あなたは、トークンベースの認証を使用するWebアプリケーションやモバイルクライアントをサポートする必要がある場合。

あなたが唯一のAPIのAPIを構築している場合、署名の他、その後、使用して通信します。

遂に

オリジナルリンク：https://blog.risingstack.com/web-authentication-methods-explained/