web-dev-qa-db-ja.com

ユーザーが編集可能なURLはクライアントの脆弱性の影響を受けますか?

私はAndroid=アプリケーションに取り組んでいます。会社のリクエストは、さまざまなテスト環境で機能するために、ユーザーがアプリで使用するAPI URLを編集できるようにすることです。

これにより、攻撃者が何らかの不正なURLを入力し(API URLを変更する機能を有効にする方法を知っている場合)、デバイスに何か悪影響を及ぼす可能性があるため、すぐに私に赤信号が発生しました。

私はセキュリティのバックグラウンドを持っていないので、これが問題であるかどうかはわかりませんが、デバイスの悪用などに悪用される可能性があると感じています。

私は押し戻し、それは良いアイデアではないと言ってみましたが、編集可能にすることに固執しているようで、これが悪いアイデアであることを証明するものとして私は何もバックアップしません。

このルートを下りることを心配する必要がありますか?

1
tyczj

これは質問するのに良いことです。答えは、このAPI URLの使用方法です。つまり、クライアント側で使用されるかサーバー側で使用されるか。

クライアント側

これは、Androidアプリがサーバーに接続するために使用するURLですか?

Client fetching a URL

サーバーの観点からは、これで問題ありません。これは、アプリから認証資格情報を抽出し、curlまたはPostmanからこのAPIを呼び出すのと同じです。これはとにかくサーバーが保護すべき脅威であるため、ここでは未承認のアクセスをブロックするための適切な認証と承認がすでに存在していることを願っています。

ポーキングを行う1つの場所は、アプリがこのAPIからの応答を処理する方法です。たとえば、アプリがAPI1からの応答を期待しているが、ユーザーがそれをだましてAPI2を呼び出すようにした場合、API2からの応答データがクライアントで予期しない動作を引き起こしますか?

ただし、一般的には、このURLがクライアントによって使用されている場合、これが大きな問題であるとは思いません。

サーバ側

このURLはサーバーに渡され、サーバーはそれに接続しますか?

Server fetching a client-provided URL

この状況はほぼ間違いなく間違っており、ほぼ確実に Server-Side Request Forgery(SSRF) に対して脆弱です。

この場合、このAPIの設計全体を注意深く検討する必要があります。

1
Mike Ounsworth

このルートを下りることを心配する必要がありますか?

あんまり。誰かが変更されたURLをサーバーに送信する方法はたくさんあるので、アプリでフィールドを編集不可にすることが保護である場合、深刻な問題に直面します。

たとえば、ユーザーはPostmanのような特別なツールを使用できます。ユーザーはBurpプロキシを設定して、リクエストを傍受して編集することができます。ユーザーは、Pythonまたはその他の柔軟な言語で独自のクライアントを実装できます。

公開するアプリケーションは、サービスへのエントリポイントの1つにすぎません。代わりに、予期しない入力に対してサービスを回復力のあるものにすることに焦点を当てます。

1
gowenfawr