現在、非常に単純なWebアプリに取り組んでおり、アイドル状態のユーザーが任意のデータを送信する可能性を減らすために、 「難読化」 （正しい用語は何ですか？）または何らかの方法でリクエストパラメーターをエンコードしたいと考えています。
たとえば、URLは次のようになります/webapp?user=Oscar&count=3
次のようなものが必要です。/webapp?data=EDZhjgzzkjhGZKJHGZIUYZTその値を実際のリクエスト情報とともにサーバーでデコードします。
このようなことを自分たちで実装する前に（そしておそらくそれを間違って実行する前に）、これを実行するための何かがすでにあるかどうか知りたいですか？
サーバーにはJavaがあり、クライアントにはJavaScriptがあります。
いいえ、これをしないでください。サーバーに返送されるデータを難読化するためにクライアントコードに何かを構築できる場合は、意図的なハッカーもそうすることができます。公式クライアントが何をしていても、サーバーに送信されるデータを信頼することはできません。クライアントデータをエスケープし、サーバー側のホワイトリストに対して検証することに固執します。SSLを使用し、可能であれば、リクエストパラメータをGETではなくPOSTに配置します。
拡張編集
あなたの混乱は、標準的なセキュリティ対策を実装する必要があるため、ユーザーがリクエストデータを改ざんするのをブロックするという目標から生じています。Webアプリケーションの標準的なセキュリティ対策には、認証、特権とセッションの管理、監査証跡、データ検証、および安全な通信チャネルの組み合わせの使用が含まれます。
SSLを使用しても、クライアントがデータを改ざんするのを防ぐことはできませんが、仲介者がデータを表示したり改ざんしたりするのを防ぐことはできます。また、URL履歴に機密データをキャッシュしないように、正常に動作するブラウザに指示します。
認証がなく、GETでそれを制御するリクエストパラメータを渡す、ある種の単純なWebアプリケーションがあるようです。したがって、技術に精通していない人は、ブラウザバーでuser=WorkerBee簡単に変更できることを理解できるでしょう。 user=Boss、したがって、表示してはいけないデータにアクセスしたり、実行してはいけないことを実行したりできます。これらのパラメータを難読化したいというあなたの願望（または顧客の願望）は、技術に最も精通していない人を失敗させるだけなので、ナイーブです。これは中途半端な対策であり、既存の解決策が見つからない理由は、それが適切なアプローチではないためです。適切な測定のために、監査証跡を備えた適切な認証システムの実装に時間を費やしたほうがよいでしょう（そして、これが実際に行うことである場合は、マークを付けてください）ゲイリーの正解）。
それで、それをまとめるには：
「アイドル状態のユーザーが任意のデータを送信する可能性を減らす」ことが目標である場合は、もう1つの簡単な方法を試してみます。秘密暗号化キーを作成し、アプリケーションサーバー側に保存します。アプリケーションがURLを生成するときはいつでも、秘密暗号化キーを使用してURLのハッシュを作成し、そのハッシュをクエリ文字列に入れます。ユーザーがURLにパラメーターを含むページを要求するたびに、ハッシュを再計算して、一致するかどうかを確認します。これにより、アプリケーションがURLを計算したことを確認できます。ただし、クエリ文字列パラメータは読み取り可能のままになります。擬似コードでは、
SALT = "so9dnfi3i21nwpsodjf";
function computeUrl(url) {
return url + "&hash=" + md5(url + SALT );
}
function checkUrl(url) {
hash = /&hash=(.+)/.match(url);
oldUrl = url.strip(/&hash=.+/);
return md5(oldUrl + SALT ) == hash;
}
データへのアクセスを制限しようとしている場合は、シングルサインオン認証キーを提供するCookieを使用して何らかのログインメカニズムを使用します。クライアントがキーを使用してCookieを送信する場合、クライアントは自分のアカウントに関連付けられている権限（管理者、パブリックユーザーなど）に従ってデータを操作できます。これのJavaでの使いやすい実装については、Spring Security、CASなどをご覧ください。Cookieで提供されるトークンは通常、発行元サーバーの秘密鍵で暗号化されており、通常は改ざん防止されています。
または、パブリックユーザー（認証されていない）がサイトにデータを投稿できるようにする場合は、すべての賭けが無効になります。サーバー側で検証する必要があります。これは、特定のURIへのアクセスを制限し、すべての入力が確実にクリーンアップされるようにすることを意味します。
ここでの黄金律は、安全であることがわかっているものを除いて、すべてを禁止することです。
「静的」URLが操作されないようにすることが目的の場合は、パラメーターを暗号化するか、署名するだけです。URLパラメータのMD5を、いくつかのソルトとともに追加するのは「十分に安全」である可能性があります。ソルトは、セッションに保存されているランダムな文字列にすることができます。
次に、次のことができます。
http://example.com/service?x=123&y=Bob&sig=ABCD1324
この手法はデータを公開します（つまり、xyz = 123を「見る」ことができます）が、データを変更することはできません。
「暗号化」には利点があります（そして私はその用語を大まかに使用します）。ここで、URLのパラメータセクション全体を暗号化します。
ここでは、次のようなことができます。
http://example.com/service?data=ABC1235ABC
暗号化を使用することの良いところは2つあります。
1つはデータを保護します（たとえば、ユーザーはxyz = 123を確認できません）。
他の機能は、拡張可能であるということです。
http://example.com/service?data=ABC1235ABC&newparm=123&otherparm=abc
ここでは、元のペイロードをデコードして、新しいデータと（安全に）マージすることができます。
したがって、リクエストは、既存のデータを変更するのではなく、リクエストにデータを追加できます。
署名手法を使用して同じことを行うことができます。リクエスト全体を単一の「blob」に統合するだけで、そのblobは暗黙的に署名されます。これは「効果的に」暗号化されており、弱い暗号化です。
明らかに、クライアントでこれを実行する必要はありません。意味がありません。あなたがそれを行うことができれば、「彼ら」はそれを行うことができ、あなたは違いを見分けることができないので、通常のHTTPポート（対TLS、しかし、そうすると人々は賢明に「なぜわざわざ」と思うでしょう。
Javaの場合、このすべての作業はフィルターで行われます。これが私が行った方法です。バックエンドはこれから分離されています。
必要に応じて、URLの暗号化/署名を処理するアウトバウンドフィルターを使用して、バックエンドをこれから完全に分離することができます。
それは私がしたことでもあります。
欠点は、それを正しく実行するために非常に関与していることです。URLを引き出すには軽量のHTMLパーサーが必要です（ページ全体をRAMにコピーしないように、その場で実行するストリーミングパーサーを作成しました）。
明るい面は、コンテンツの面のすべてが「正しく機能する」ことです。彼らはそれについて何も知らないからです。
また、Javascriptを処理する場合は、特別な処理がいくつかあります（フィルターは、暗号化するURLがどこにあるかを簡単に「認識」しないため）。これを解決するには、特定の「varsignedURL ='....'」でURLに署名する必要があるため、出力で簡単に見つけることができます。あなたが思うかもしれないほどデザイナーの負担を押しつぶすことはありません。
フィルタのもう1つの明るい面は、無効にできることです。「奇妙な動作」が発生している場合は、単にオフにします。動作が続く場合は、暗号化に関連するバグが見つかりました。また、開発者はプレーンテキストで作業し、統合テストのために暗号化を残すことができます。
やるのは苦痛ですが、最終的には全体的にいいです。
base64などを使用してデータをエンコードできます。引数をJSONでエンコードして、シリアル化します。
jCryptionのようなもの？