クエリ文字列を論理的に非表示にしますか？
クエリ文字列パラメーターを次のように使用すると、不快に感じます。
http://xyz.com/default.aspx?carId=1129&country=uk&uniqueId=98745DVF4563VVf1259
私はむしろ、URLから意味をなそうとしている人には意味をなさないものを使用したいと思います。
?a=1129&b=uk&c=98745DVF4563VVf1259
（このすべてのクエリ文字列情報は私の使用のみのためです）
まず、これは良いことですか？ （クエリ文字列のロジックを非表示にすることを意味します）
そうであれば、内部で開発者がコードでcarId、countryおよびuniqueIdを使用できる方法がありますが、外部ではURLがaを使用します。 bとcそれぞれ？
だから誰かが行くなら?a=1129&b=uk&c=98745DVF4563VVf1259
私がする時 Request.QueryString["carId"]
1129を取得する必要があります。
これはできますか？
サーバーのセキュリティについて考えているのは良いことです。
パラメータ名を難読化しても、最も偶発的な攻撃者が阻止されるだけです。
パラメータ文字列全体を暗号化し、代わりに結果をサーバーに送信することを検討してください。これはより複雑なセキュリティ手段であり、独自の長所と短所（プログラミング作業、長くて混乱するURL）が付属しています。特に、暗号化はエンドノードで実行されるため、特定の攻撃者はローカルでそれを解読できる可能性があります。しかし、もう一度-より大きな努力で。
最後に、攻撃者がどれほど献身的であると考えるか（多くの場合、賞品の価値によって決定される）、および攻撃者の行動がどれほど破壊的であるかについて決定する必要があります。これに基づいて、適切に強力なレベルのセキュリティを選択します。
あなたの例では、誰かが変更されたURLを送信することはどれほど悪いことですか？彼らは何も見えませんか？エラーメッセージ？別の結果？別の結果、他の誰かにプライベートであるはずだったもの？彼らはあなたのサーバーをクラッシュさせることができますか？彼らはあなたのサーバーを引き継ぐことができますか？他のユーザーのアカウントにハッキングできますか？この質問への答えはあなたを導くのに役立ちます。
誰から何を守ろうとしているのですか？
自分と有効なユーザー間のトラフィックを傍受しようとする攻撃者からクエリ文字列の値を保護しようとしている場合は、HTTPSを使用してください。この場合、トランスポート層をセキュリティで保護することで、費用対効果が最も高くなり、それを実装する最も簡単で簡単な方法になります。ハッカーは、クエリ文字列で渡される個々のパラメーターをはるかに下回って、送受信しているものを理解できなくなります。
クエリ文字列の値をアプリケーションの悪意のあるユーザーから保護しようとしている場合は、おそらくそれを間違った方法で行っていると思います。まず、クライアントが暗号化されたクエリ文字列を送信するためには、クライアントが最初に暗号化されたクエリ文字列buildを送信する必要があるという事実を考慮する必要があります。暗号化するパラメーターと値を具体的に知らなくても、どうやってこれを実行できますか？ Webアプリの場合、クエリ文字列の作成と暗号化に使用しているロジックがユーザーに表示されないようにすることはほぼ不可能です。
次に、ユーザーがこのクエリ文字列を操作できるのはなぜ危険だと思うのでしょうか。理由の1つは、許可されていない情報を表示できることです。たとえば、carIdを任意の値123に変更して、その車に関する情報に不正にアクセスする可能性があります。私がその番号を送信するのを回避するのではなく、要求が来たときに検査して、実際にそのデータを表示することが許可されているかどうかを検証します。そうでない場合は送信しないでください。それはとても簡単です。
ユーザーが何らかの方法でアプリを壊すような値を渡すことができる場合、答えは入力を検証してサニタイズすることです。 _carId=-1_または_carId=DROP+TABLE+[Cars]_を渡してデータベースが破壊された場合は、それらの値を受け入れないようにしてください。 If carId <=0 throw new ArgumentException("carId")など。
まあ、実際には難読化せずにMVC Asp.netでクエリ文字列を簡単に隠すことができます。
一般的なアイデアは、クエリ文字列を使用して、URLへの少なくとも2つのパスを作成することです。人々がアクセスできるようにする経路で、ビューを返したいアクションにリダイレクトする中間メソッドを作成します。 2番目の経路は、前述のアクションに直接アクセスします。中間の方法では、このページに以前にアクセスしたことがあるの値を1に増やすようにデータベースに指示します。
99％の確率で機能する理由を理解する前に、次の部分を数時間考える必要があるかもしれません。中間メソッドの最後に、値を0に戻します。ビューを返すアクションで、値を0に設定した場合にのみ、返したいビューが返されるようにします。ただし、ビューが返される前に、値を1に設定してください。
ただし、この方法は100％安全ではありません。私はそれが基本のみと非常に少ないコードを使用する唯一の実装だと思います。難読化しても、クエリ文字列のURLにアクセスできなくなります。それは人々がウェブサイトにアクセスすることをより困難にします。
まず、これは良いことですか？ （私はあなたのクエリ文字列のロジックを隠すことを意味します）？
私はそうは思いません。悪意のあるユーザーはクエリ文字列パラメーターを自由に変更できますが、システムをさらに複雑にする代わりに、少し困難にするだけです。
ある種の中間クラスを作成したり、プレーンなクエリ文字列名を難読化された名前にマップするメソッドを作成したりできます。
string ObfuscateQueryString(string myString)
{
switch(myString)
{
case "CardId":
return "a";
break;
case "Country":
return "b";
break;
}
}
次に、このように使用します
Request.QueryString[Obfuscate("CardId")]
もちろん、これはメソッドの馬鹿げたデザインですが、よりスマートなものをデザインできるというアイデアが得られます。
単純な1対1のマッピングを行うことで、クエリ文字列を難読化できます。これをカスタムWeb構成セクションまたは要件に適したものに配置できます。あなたはURL書き換えモジュールを使って調べることができます-それはきれいではありませんが、うまくいくはずです。例えば。 carIdをfooに書き換えます。
とは言っても、クエリ文字列が自分専用である場合は、使用しないでください。別の方法を見つけます。誰かがそれを見つけ出し、何らかのダメージを与えるのは時間の問題です。
クエリ文字列のIDを使用してWebアプリケーションで作業して潜在的に機密性の高いデータを検索する場合、以前は2つのフィールドを組み合わせてセキュリティを向上させてきました。ユーザーIDとユーザーの電子メールアドレス。サーバー側のコードチェックでは、渡されたIDがその電子メールアドレスに対して正しいことを確認します。
userId = Request.Querystring("userId")
userEmail = Request.Querystring("userEmail")
userObj = db.getUser(userId)
if(userObj.email == userEmail)
//all good
else
//someone's made a mistake / being naughty with the querystring
私は専用ハッカーがこれ（およびほとんどのセキュリティ対策）を回避できることは間違いありませんが、その時点で必要なセキュリティのレベルには適切であり、他の人のデータを表示するためにuserIdを単純に編集することはできません。
これがあなたの状況に役立つ/漠然と関連していることを願っています。
クエリ文字列には多くのメソッドを使用できます。私はスクランブル/デスクランブルを使用することを好みます。あなたがする必要があるのは、文字列全体を次のようにスクランブルするだけです。
string strQS = "id=23&Name=hagsh";
string QueryString1 = ScrambleString(strQS);
Response.Redirect("test.aspx?Query=" + QueryString1 );
反対側では手順を逆にしてください...
スクランブル/デスクランブルアルゴリズムのためにグーグルするだけです。準備ができたDLLを取得できます。