0

Slim Microframework を使用して RESTful Webservice を作成しており、GET を使用して mysql データベースからデータを読み取り (選択クエリ)、データベースの行を挿入/更新/削除するために POST/PUT/DELETE も使用しています。

私の質問は今、誰もがデータベースにデータを書き込んだり削除したりできる場合、これは大きなセキュリティ上の問題ではないでしょうか? しかし、どうすればこれを防ぐことができるでしょうか。REST の ST は状態転送 (つまり、Web サービスはステートレス) を表していると思いました。これは、ログインしているかどうかなどの状態と矛盾しています。そして、データベースへの書き込みが許可されているクライアントにログインデータを渡すと、悪者はログインデータをキャッチしてリクエストを偽造し、たとえばすべてのエントリを削除することはできませんか?

したがって、これを使用する通常の方法は何ですか。私が見つけた唯一のSlim Frameworkの例は、常にルートの例を示していますが、それを保護する方法は示していません.

Slim Framework には、必要なものを実装する機会もありますか? それはできるだけ簡単であるべきであり、要求は認証などなしでほぼ​​同じ速さで応答されるべきです。パスワードのような機密データはありません。私にとっては、cURL コマンドライン ツールを使用しているすべての人がすべての行などを削除できるわけではないということで十分です。

誰かが私に何をすべきかを説明したり、いくつかの例を挙げたりできれば素晴らしいと思います. また、リクエストの送信を許可されているクライアントで何を変更する必要があるかを知る必要があります。

どうもありがとう。

4

4 に答える 4

1

各リクエストは、認証および認可される必要があります。

人々はしばしば「ステートレス」という言葉に縛られます。これは、あるリクエストから次のリクエストまで、RESTful サービスがユーザーの状態を事前に把握していないことを意味します。

しかし、サービスは明らかに、リクエストを行ったばかりの認証済みユーザーを認識することが許可されています。そうでなければ、アクセスを許可するかどうかをどのように決定しますか?

したがって、各リクエスト中に、認証されたユーザーを変数に「保存」できます。次に、この情報を使用してリクエストを承認する方法はあなた次第です。

シンプルに保ち、すべてのユーザーを URI チェーンのリソースとして保持するのが好きです。のようなリクエストをしますusers/{username}/someresource。

http 基本認証 (SSL 経由) を使用して認証し、URI に基づいて承認します。リクエストが認証に失敗した場合、それは 401 Unauthorized Request です。URI {username} と認証された {username} が一致しない場合、リクエストは 403 禁止です。認証および承認されている場合、リクエストは許可されます (http 動詞に依存する http コード)

これで Web サービスがカバーされ、次は Web サービス クライアントに進みます。もちろん、これは状態を保存する必要があります。そうしないと、ユーザーはリクエストを行うたびにログインする必要があります。

ユーザー セッションをアプリケーションに保存するだけで (通常のセッション管理と同様)、ユーザー名とパスワードを (もちろん暗号化して) セッションに保存できます。これで、リクエストが行われるたびに、Web サービス クライアントはユーザー名とパスワードを取得し、リクエストと共にそれを Web サービスに送信する必要があります。

于 2013-03-04T17:16:47.720 に答える
0

通常の http 認証セッションと同じくらい安全です。これらはCookieなどを使用して、接続されたユーザーを保存されたセッション状態に認証します。

ステートレス サービスも例外ではありません。通常の http の Cookie にトークンが格納されるのと同じように、トークンがサービスに渡されます。スニッフィング (IE 中間者攻撃) が心配な場合は、SSL 経由でリンクを保護します。

サービスによって生成された認証トークンは暗号化され、リクエストごとにサーバー上で検証されるソルトも含まれます。また、パラノイアに合わせてセッション時間を制限し、ソース IP、ユーザー エージェントなどの変更を確認し、これらが変更された場合はユーザーのトークンを期限切れにすることもできます。

于 2013-03-27T06:01:07.930 に答える
0

セッションや Cookie がないという意味で、ステートレスになります。通常、INSERT/UPDATE/DELETE に必要なキーを発行します。

その後、各リクエストでキーを渡し、キーの有効期限を決定するのはあなた次第です。

于 2013-02-27T14:12:32.870 に答える
0

私は最近、同様の問題に遭遇しました。ここの人々が推奨するように、私は OAuth 認証を使用することにしました。

OAuth 用のHybridAuth A php ラッパーと、Facebook、Twitter、Google、LinkedIn などのすぐに使用できるサインイン ソリューションを使用しています。

于 2014-03-25T05:32:21.027 に答える