アプリケーションのセキュリティ開発に関する考慮事項

Sina のセキュリティ部門は、Weibo アプリケーションがより良いユーザーエクスペリエンスとより安全な機能を備えられるように、オープンプラットフォームでの製品セキュリティの推進に取り組んでいます。現状から判断すると、一部のアプリケーションに以下のような共通のセキュリティ上の脆弱性や欠陥が存在し、アプリケーション自体に影響を与えるだけでなく、ユーザーに損害を与える可能性があることが判明しました。

アプリシークレットの漏洩

app_secret は、アプリケーションがオープンプラットフォームに access_token の生成を要求するための唯一の認証です。app_secret を使用する目的は、アプリケーションが確実にアクセスされていることを確認することです。開発者自身が使用しています。

オープンプラットフォームでは、アプリケーションごとにリソースと API 権限を呼び出すインターフェイスが異なります。アプリケーションのインターフェイスリソースが悪用され、スパム情報の投稿や注意喚起などの悪意のある操作が実行された場合、オープンプラットフォームによりアプリケーションのリソースと権限が制限され、アプリケーションの通常の API 呼び出しに直接影響します。したがって、開発者は、アプリケーションの正常な動作を保証するために、自身のアプリケーションのセキュリティを保護し、対応するセキュリティリソースの不正使用を防止する必要があります。

アプリケーションシークレットをアプリケーションサーバーに保存することをお勧めします。アプリケーションのセキュリティをより適切に保護するために、管理センター/セキュリティ設定でアプリケーションのサーバー IP をバインドすることをお勧めします。

#アプリケーションのアプリシークレットが漏洩したことを発見した場合は、アプリケーション管理センターにアクセスしてください。すぐにリセットしてください。 http://open.weibo.com/apps/

アプリシークレットが漏洩する一般的な理由:

1. アプリシークレットがページのソースコードまたは URL に表示され、その結果、直接表示ソースコードが利用可能です。

2. app_secret はクライアントプログラム自体に保存され、すべてのネイティブアプリケーション (iOS、Android、または Windows デスクトップアプリケーションなど) は逆コンパイルされたコードによって取得できます。

3. HTTPS 安全な伝送プロトコルは使用されず、攻撃者はネットワークスニッフィングを通じてこのプロトコルを入手します。

access_token 漏洩

access_token は、ユーザーがアプリケーションを通じてオープンプラットフォームにアクセスするために使用するセッション ID です。アプリケーションは、第三者による盗難を防ぐために保護する必要があります。

一般的な access_token 漏洩方法:

1. access_token は Cookie またはページコードに保存され、攻撃者は xss の脆弱性を通じてユーザートークンを盗みます。

2. アプリケーションサーバーには SQL インジェクションの脆弱性があり、ユーザートークンが漏洩します。

Weibo ユーザーの CSRF 脆弱性のバインド

アプリケーションに独自のアカウントシステムがあり、Weibo にバインドされている場合、ユーザーがログインするときにこの機能を使用する場合は、バインディングインターフェイスに CSRF 攻撃を防ぐ機能があるかどうかを確認してください。認可インターフェイスの状態パラメータは、認可プロセス中の CSRF 攻撃を防ぐために使用できます。詳細な使用法については、SDK コードの最新バージョン (https://github.com/ElmerZhang/WeiboSDK) を参照してください。

Weibo で CSRF 脆弱性をフォローして投稿してください

CSRF 脆弱性の詳細については、こちらを参照してください。 http://baike.baidu.com/view/1609487.htm

Weibo アプリケーションの CSRF 脆弱性は、フォロワーの追加や Weibo への投稿などの書き込みインターフェイスでよく見られます。ユーザーに見られる現象は次のとおりです。 Weibo が不可解な注目を集めたり、Weibo に関するマーケティングが転送されたりしています。

開発者は、リファラーが合法かどうかを確認するか、フォームに csrf_token を追加することで、CSRF 攻撃を防御できます。

ユーザー ID の偽造

OAuth 2.0 認可認証を完了すると、アプリケーションはユーザーの ID を象徴する access_token を取得できます。これは通常、インターフェイス呼び出しに直接使用されます。ただし、一部のアプリケーションは、アプリケーション独自のサービスコンテンツをさらに提供するために、独自のアカウントシステムに関連付けられた認証資格情報としてユーザーの uid を取得する必要があります。一般的な状況には、Weibo SSO SDK を使用するモバイルアプリケーションやネットワークストレージサービスアプリケーションが含まれます。

このシナリオでは、一般的な脆弱性は次のとおりです:

1. クライアントは、認可インターフェイスから返された uid を直接使用するか、access_token 内の uid を抽出して、アプリケーション独自のサーバーを返します。認証資格情報として。この送信プロセスは不正に傍受され、uid を改ざんすることでユーザーの身元が偽造される可能性があります。

2. クライアントは access_token を自身のサーバーに送り返し、サーバーはその中の uid を認証資格情報として抽出しますが、access_token の正当性は検証しません。このとき、ユーザー A をだまして X アプリケーションを認可し、access_token を取得して Y アプリケーションサーバーに渡すことで、A ユーザーの Y アプリケーションに対する資格情報を取得し、Y アプリケーション内のユーザーのサービスコンテンツにアクセスできるようになります。

修復提案:

1. 独自のサービスの認証資格情報と引き換えに、認可情報なしで uid を直接使用しないでください。使用できるのは access_token のみです。

2. サーバー側で access_token の uid を抽出するには、オープンプラットフォームの OAuth2/get_token_info インターフェイスを呼び出す必要があります。このインターフェイスを使用する場合は、access_token が属する appkey が独自のクライアントアプリケーションの appkey であるかどうかも確認する必要があります。一貫した Appkey ソースを持つユーザーのみが、独自のサービスの認証資格情報を交換できます。

3. 保存されているすべてのバインドされた access_token を確認し、access_token 内の Sina uid がバインドされた Sina uid と矛盾していること、独自のクライアントアプリケーション以外のアプリキーによって承認された access_token、期限切れの access_token およびその他の異常な状況が必要であることを確認します。は取り消され、これらの異常なユーザーはログインを再認証する必要があります。

クリックハイジャックの脆弱性

悪意のあるサイトは、iframe に Weibo アプリケーションサイトを埋め込み、HTML 透明オーバーレイなどのテクノロジーを使用してユーザーのクリック操作をハイジャックします。ユーザーに悪意のある行為を誘導し、注意を喚起する目的を達成するため。

修復提案:

1. iframe を必要としないアプリケーションの場合は、次のいずれかの方法を選択できます。

- a. ヘッダー宣言 header("X-FRAME-OPTIONS:DENY");
- b. JS は現在のページが iframe であるかどうかを判断します。サンプルコード: if (top.location!=location){top.location=locaiton;}

2. iframe が必要な商品。

アプリケーションのセキュリティは広範囲に及びます。開発者は、上記の一般的なセキュリティ問題の回避に注意を払うことに加えて、最新のセキュリティの傾向にも注意を払い、理解する必要があります。製品や開発者のセキュリティ意識を高めることがより重要であり、それによってのみセキュリティ問題を可能な限り減らすことができます。セキュリティ上の脆弱性が発生した場合は、時間内にご連絡いただければ、できるだけ早く解決策を提供いたします。

###