認証のベストプラクティス
APIキーとトークンは非常に慎重に保護する必要があります。
これらの認証情報は、開発者アプリと、ユーザーが開発者に代理リクエストを許可したTwitterアカウントに直接紐付けられています。キーが侵害されると、攻撃者は開発者アプリやその認証されたユーザーに代わり、キーを使用してTwitterエンドポイントにリクエストを送信できるようになります。このリクエストにより、予期せぬうちにレート制限に達したり、支払い済みのアクセス割り当てを使い切ったり、さらには開発者アプリが停止される原因になる可能性があります。
以下のセクションでは、APIキーとトークンを管理する際に考慮すべきベストプラクティスを紹介します。
APIキーとトークンの再生成
APIキーが漏えいしたと思われる場合は、次の手順でAPIキーを再生成する必要があります。
- 開発者ポータルの [Projects and Apps] ページにアクセスします。
- 該当するアプリの横にある [Keys and tokens] アイコン（🗝）をクリックします。
- 再生成するキーとトークンのセットの横にある [Regenerate] ボタンをクリックします。
アクセストークンやベアラートークンをプログラムで再生成する場合は、認証エンドポイントを使用して行えます。
- アクセストークンを再生成する場合は、POST oauth/invalidate_tokenエンドポイントを使用してトークンを無効化し、3レッグOAuthフローを使用してトークンを再生成します。
- ベアラートークンを再生成する場合は、POST oauth2/invalidate_tokenエンドポイントを使用してトークンを無効化し、POST oauth2/tokenエンドポイントを使用してトークンを再生成します。
シークレットの中央ファイルを用意する
.ENVファイルや他の種類の.yamlファイルを用意してシークレットを格納することは有効な選択肢ですが、これらをgitリポジトリに誤ってコミットするのを防止できる強力な.gitignoreファイルを用意するようにしてください。
環境変数
環境変数を使用してコードを記述すると有効な場合があります。
以下は、Pythonで記述された例です。
import os
consumer_key = os.environ.get("CONSUMER_KEY")
consumer_secret = os.environ.get("CONSUMER_SECRET")
ターミナル内で次のようなコードを記述します。
export CONSUMER_KEY='xxxxxxxxxxxxxxxxxxx'
export 'CONSUMER_KEY'='xxxxxxxxxxxxxxxxxxxxxxx'
ソースコードとバージョン管理
開発者がよくしてしまうセキュリティ上の誤りは、GitHubやBitBucketなどのアクセス可能なバージョン管理システムのソースコードにAPIキーとトークンがコミットされてしまうことです。これらのコードリポジトリの多くは一般にアクセス可能であり、この誤りが公開されたコードリポジトリで頻繁に起こるため、APIキーをかき集める悪質なボットが存在しています。
- サーバーの環境変数を使用します。APIキーを環境変数でソートすることで、コードとバージョン管理から、ボットを締め出すことができます。 また、これによりさまざまな環境でさまざまなキーを簡単に使用できるようになります。
- ソース管理から除外された構成ファイルを使用します。.gitignoreファイルにファイル名を追加して、ファイルがバージョン管理でトラッキングされないようにします。
- バージョン管理を使用した後にコードからAPIキーを削除すると、コードベースの以前のバージョンにアクセスしてAPIキーに引き続きアクセスできてしまう可能性があります。次のセクションで説明するように、APIキーを再生成します。
データベース
データベース内にアクセストークンを保存する必要がある場合は、次の点に注意してください。
- アクセストークンがトークンの所有者によってのみ読み取り可能となるように、データベースへのアクセスを制限します。
- アクセストークン用のデータベーステーブルへの編集/書き込み権限を制限します。これは、キー管理システムによって自動化する必要があります。
- 何らかのデータストアに保存する前に、アクセストークンを暗号化します。
パスワード管理ツール
1passwordやLast Passなどのパスワード管理ツールは、キーやトークンを安全な場所に保存するのに有効です。これらをチームのパスワード管理ツールで共有することは避けたほうがよいでしょう。
ウェブストレージとCookie
ウェブストレージにはLocalStorageとSessionStorageの2種類があります。ウェブストレージのストレージ容量はCookieのストレージよりもはるかに大きいため、Cookieの使用を改善するために作成されます。しかし、これらのストレージオプションには別のメリットとデメリットがあります。
ウェブストレージ：LocalStorage
ローカルのウェブストレージに保存されるものはすべて永続的です。つまり、データを明示的に削除するまで、データは保持されます。プロジェクトのニーズによっては、これはメリットと見なされるかもしれませんが、データへのすべての変更や追加は、対象のウェブページに今後アクセスした際に確認できてしまうため、LocalStorageの使用には注意が必要です。通常はLocalStorageの使用は推奨されませんが、これにはいくつかの例外があります。LocalStorageを使用する場合は、同一オリジンポリシーがサポートされているため、ここに保存されるすべてのデータは同じソースを介してのみアクセス可能となります。それ以外に、LocalStorageを使用するパフォーマンスメリットとして、クライアントとサーバー間のトラフィックの削減があります。これは、HTTPリクエストごとにデータをサーバーに送り返す必要がないためです。
ウェブストレージ：SessionStorage
SessionStorageはLocalStorageと似ていますが、主な違いはSessionStorageが永続的ではないことです。SessionStorageの書き込みに使用されたウィンドウ（またはタブ。使用しているブラウザーによる）が閉じられると、データは失われます。これは、トークンへの読み取りのアクセスをユーザーセッション内に制限するのに役立ちます。セキュリティの観点では、通常、SessionStorageを使用するほうが、LocalStorageを使用するよりも望ましいと言えます。LocalStorageと同様に、同一オリジンポリシーのサポートおよびクライアントとサーバー間のトラフィック削減のメリットがSessionStorageにも当てはまります。
Cookie
Cookieはセッションデータを保存する従来型の方法です。各Cookieについて有効期限を設定できるため、アクセスの取り消しと制限をより簡単にできます。ただし、Cookieを使用するとクライアントとサーバー間のトラフィックは確実に増加します。これは、HTTPリクエストごとにデータがサーバーに送り返されるためです。Cookieを使用する場合は、セッションのハイジャックから保護する必要があります。デフォルトでは、CookieはHTTPを介してプレーンテキストで送信されるため、コンテキストがパケットのスニッフィングや中間者攻撃に対し脆弱になり、攻撃者がトラフィックを改ざんする可能性があります。常にHTTPSを使用して転送中のデータを保護する必要があります。これにより、機密性、（データの）統合性、認証が確保されます。ただし、ウェブアプリケーションやサイトがHTTPとHTTPSの両方で利用可能な場合は、Cookieに「Secure」フラグも使用するとよいでしょう。これにより、攻撃者がサイトのHTTPバージョンへのリンクをユーザーに送信可能になるのを防ぎ、その結果生成されたHTTPリクエストをリッスンできなくします。
Cookieを使用する際のセッションハイジャックに対するもう1つの防御策は、影響が大きいアクションが実行される前にユーザーのIDを再度検証することです。Cookieのセキュリティを高めるために考えられるもう1つのフラグは、「HttpOnly」フラグです。このフラグは、対象のCookieが指定したサーバーからのみアクセス可能となることをブラウザーに伝えます。クライアント側のスクリプトによって行われるすべての試行はこのフラグにより禁止されるため、ほとんどのクロスサイトスクリプティング（XSS）の攻撃から保護できます。
次の手順
- 開発者ポータルで、Twitterアプリ、APIキーと設定を管理します。
- ウェブアプリケーションのセキュリティの詳細を確認します。
- Open Web Application Security Project（OWASP）
これは、一般的な脆弱性、攻撃、それぞれの防御方法など、ウェブアプリケーションのセキュリティの基本的なコンセプトを理解するのに役立つリソースです。OWASPは、オンラインの情報セキュリティコミュニティが参加するオープンソースのプロジェクトです。ウェブアプリケーションが攻撃される最も一般的な脆弱性について、「OWASP Top 10」をご覧ください。 - OWASP Webgoat Project
広範なOWASPプロジェクトの小規模なプロジェクトの1つです。Webgoatは、OWASPコミュニティにより設計、開発、保守されている、意図的にセキュリティ保護されていないウェブアプリケーションです。これは、関心のあるユーザーにウェブアプリケーションのセキュリティ上の教訓を伝えることを目的としています。これは、ユーザーが特定のセキュリティ上の問題について学習し、ホストされたアプリケーションの実際の脆弱性を攻撃できる、体験型のリソースです。 - 24 Deadly Sins of Software Security：Programming Flaws and How to Fix Them（M. Howard、D. Leblanc、J. Viega著）
この書籍では、より広範かつ一般的な視点でセキュリティに関するトピック（脆弱性、予防策、修正方法）を取り扱っていますが、ウェブアプリケーションのセキュリティに特化したセクションには、よくある間違いと修正に関するいくつかの非常に役に立つ情報も記載され、セキュリティの学習ニーズに対応する追加リソースとなっています。
- Open Web Application Security Project（OWASP）