10

これはしばらく前から気になっていた質問なので、アプリがセキュリティリスクになる可能性を抑えるための意見や解決策を探しています。

私は多くのことにjQueryを使用していますが、主にjQueryダイアログウィンドウの処理に使用しています。多くの場合、フォームのフィールドから値を取得し、その情報を.serialize（）コマンドで連結し、それをjQuery ajax呼び出しに渡して、データベースとの対話のためにPHPファイルに移動する必要があります。

これが私の質問です（ついに）、

PHP処理でURLがどのように見えるかを「推測」するのは、ばかばかしいほど簡単ではありませんか？
最新のブラウザでソースを開き、リンクをクリックして、ajax呼び出しを含む完全なJavaScriptファイルを確認できます。

難読化のためにJavaScriptファイルを縮小することもできますが、それは信頼できるセキュリティの形式ではありません。

SQLインジェクション攻撃用のプリペアドステートメントを使用したデータベースアクセスにPDPを使用していますが、誰かが時間をかけて調べた場合、有効なURLを作成してデータベースに送信し、必要なものを挿入することはできませんか？

私はデータベースを鉄鋼情報にハッキングすることについて話しているのではなく、データがアプリケーション自体から追加されたかのように悪意のある情報を挿入することについて話しているのです。たった25ドルで50ドルの何かをショッピングカートに追加することを考えてください。

ajaxリクエストをGETからPOSTに変更し、PHPファイルを変更するのと同じくらい簡単な場合はどうでしょうか。

編集：その人はログインしていて、適切に認証されています。

他の人が何をしているのか疑問に思っています。

ありがとう！

4

6 に答える 6

13

あなたは非常に正しいです。少し技術に精通している人なら誰でも、任意のWebアプリのパブリックサーバーエンドポイントを識別できます。彼らはコードを見る必要さえありません。Webkit / firebugを使用してリクエストを追跡したり、Charlesのようなネットワークアクティビティを監視するプログラムを使用したりできます。

そのため、サーバー側のコードで 認証と承認の処理が必要になります。

認証は通常、ユーザー名とパスワードによって処理されます。これは、ユーザーが本人であることを確認する行為です。

承認はサーバー上のロールによって処理でき、ユーザーが実行しようとしていることを実行できることを確認するためのチェックです。

これらの2つのメカニズムは、ユーザーがURLを知っている場合でも、「ログイン」して、やりたいことを実行する権限を持っている必要があります。

考えてみてください。オンラインで銀行口座情報を見ると、口座情報を読み込むリクエストを簡単に特定できます。これらのメカニズムがなければ、単にアカウントを変更することを防ぐにはどうすればよいですか？他の誰かのアカウント情報を取得するためにサーバーに渡しますか？認証/承認により、サーバーは、データのロード要求を受け取った場合でも、ユーザーの詳細をチェックして、そのデータを取得する権限があるかどうかを確認し、要求を拒否できることを認識します。

于 2012-04-26T12:30:30.617 に答える
9

GETからPOSTに切り替えた場合でも、サーバーに渡されているパラメーターを確認（および変更）することに関心のある人は誰でも簡単に確認できます。しかし、ここにキッカーがあります。AJAXをまったく使用していないが、単純な古いフォームを使用している場合でも、サーバーに渡されているパラメーターを確認および編集するのは非常に簡単です。

危機的な状況では、クライアントから受け取ったものに完全に依存することはできません。

たとえば、ショッピングカートに何かを追加する場合は、アイテムのIDと数量のみをサーバーに渡します。クライアントからではなく、データベースから価格の詳細を取得します。誰かがあなたをハッキングして、送信されているアイテムIDまたは数量を編集しようとすると、最悪の事態は、彼らが望まないものを購入してしまうことです。完全に彼らの問題。（ただし、まったく同じ理由で、限定オファーの場合は、たとえば、受け取る数量が1人の顧客に購入を許可する数量を超えていないことを確認する必要があります）。

したがって、結局のところ、ユーザーが制御する値を決定し、ユーザーが必要とする範囲外のリクエストを受信して​​いないことをサーバー側で検証する必要があるのは、常に開発者です。できるように。

于 2012-04-26T12:32:04.510 に答える
3

jQueryに関連するだけでなく、クライアント側からのアクションやデータに依存することはできません。

サーバー側であらゆる種類のセキュリティ問題に対処する必要があります。ユーザーからのデータを常に再確認してください（1つはパフォーマンス要求の数を減らすためにクライアント側にあり、もう1つは実際の確認のためにサーバー側にあります）。

リクエストタイプ（GETまたはPOST）は実際には重要ではなく、簡単にシミュレートできます。ユーザーが$50のアイテムを$25で追加しようとした後、DBをチェックして、アイテムの実際の価格を確認する必要があります。

于 2012-04-26T12:33:44.663 に答える
2

このような方法でコードを記述しないでください。価格はクライアントから個別に転送されます。これにより、商品やサービスの量などについて、価格=0または0.01のデータを誰でも送信できるようになります。

より一般的には、クライアントデータを決して信頼しないでください。

于 2012-04-26T12:35:13.010 に答える
2

はい、すべてのデータがサーバーに送信されたことを確認するには、サーバー側のセキュリティが必要です。たとえば、javascript/jqueryのデータを検証します。

if($(this).val() != ""){
   // post to my server page (mypage.cfm/php/asp)
}

ただし、サーバーページを保護しない場合は、空のデータをサーバーに非常に簡単に投稿してJavaScriptを回避できるため、次のような別の検証スクリプトを使用してサーバーページを保護する必要があります。

<cfif val is "">
  //dont post to my server ...
</cfif>

時にはそれは二重の仕事ですが、私たち全員が時々それに直面します...。

于 2013-05-27T04:54:46.857 に答える
2

データベースのリスクは通常、悪意のあるデータ、SQLインジェクション、CSRFです。

javascriptを縮小/醜くすることが役立ちます。ただし、ユーザーは、ユーザーが何をするかに関係なく、自分のリクエストデータを簡単にキャプチャできます。そして、ユーザーが厄介なコードを通過するのを防ぐ明確な方法はありません。

セキュリティは、ユーザーがすべてのソースコードと構成を知っているにもかかわらず、ユーザーがあなたをハッキングできない場合にのみ当てはまります。

セキュリティに対する簡単な解決策はありません。ほとんどの状況で問題を回避するための一般的な方法は次のとおりです。

HTTPSおよびPOSTリクエストを使用します。 HTTPSを介したPOSTリクエストでは、リクエストデータは暗号化されます。URLは公開されていますが、通常は問題ありません。これにより、中間者攻撃を防ぎ、プライバシーの懸念（パスワード/クレジットの漏洩など）を大幅に軽減します。GETリクエストを使用する場合、すべてのデータはURLのクエリ文字列として渡されます。これは、サードパーティのデータを変更する良い機会を意味します。

サーバー側の検証 常にサーバー側でデータを検証します。ユーザーが悪意を持っている可能性があり、クライアント側にバグがある可能性があります。たとえば、クライアント側ではなくサーバー側で合計価格を計算します。そうしないと、ユーザーはそこに0を入れる可能性があります。

アクセス権制御AKA承認許可 されるアクションに制限を設定し、それらの有効範囲を制限します。たとえば、ユーザーが他のユーザーに代わって注文することを許可しないでください。また、アクション履歴を削除させないでください。

一部のライブラリがCSRFから保護できるCSRFを防ぐためのトークンを生成します。または、独自に実装することもできます。主な概念は、ランダムトークンを生成し、クライアントにそれを返すように要求することです。これにより、他のWebサイトが（クライアントの資格情報を使用して）サーバーへの要求をトリガーするのを防ぎます。

適切なバックアップとloggin データベースを定期的にバックアップすると、災害からの復旧に役立ちます（はい、発生します）。また、ロギングモジュールを介してユーザーが行ったことを追跡します。

于 2019-03-14T08:11:41.697 に答える