3

最近、第三者から、「セキュリティ上の理由から」すべてのサーバー応答で HTML 特殊文字をエンコードするようにという勧告を受けました。そう：

' --> '
& --> &

例えば

{ "id": 1, "name": "Miles O'Brien" }

質問: これを行うことでセキュリティ上の利点はありますか?それとも単なるパラノイアですか?

4

3 に答える 3

3 
& --> &

これが彼らが意図した種類のエンコーディングであったと確信していますか?

JSON 応答内で返される HTML 特殊文字をエンコードする理由があります。これは、不要なタイプ スニッフィングによって XSS が発生するのを回避するためです。たとえば、次の場合：

{ "name": "<body>Mister <script>...</script>" }

攻撃者が JSON を返すリソースへのリンクを HTML コンテキスト (iframe src など) に含めた場合、愚かなブラウザーは、景品文字列のために<body>、ドキュメントが JSON オブジェクトではなく HTML ドキュメントであると判断する可能性があります。次に、セキュリティ コンテキストでスクリプトを実行し、XSS 脆弱性につながる可能性があります。

これに対する解決策は、JSON 文字列リテラルのエスケープを使用することです。次に例を示します。

{ "name": "\u003Cbody\u003EMister \u003Cscript\u003E...\u003C/script\u003E" }

このコンテキストで HTML エスケープを使用すると、問題を回避できますが、文字列の意味が変わるという副作用があります。"Miles O&#x27;Brien"JSON パーサーによって読み取られる値はまだMiles O&#x27;Brienアンパサンド-x-27 が含まれているため.value、.textContentや jQuery などを使用してその値をページに書き込むと、.text()奇妙に見えます。

.innerHTMLその文字列を代わりにまたは jQueryに割り当てていた場合.html()は、JSON XSS の問題に関係なく、ある時点でそれを HTML エスケープする必要があります。ただし、この場合、関心の分離の理由から、JSON を生成するサーバー側ではなく、実際にコンテンツを HTML マークアップに挿入するクライアント側にある必要があることをお勧めします。一般に、より安全な DOM スタイルのメソッドが利用できる場合は、文字列をマークアップに挿入することは避けたほうがよいでしょう。

于 2012-11-05T18:07:20.103 に答える
1

データを何に使用するかに応じて、はい、セキュリティ上の利点があります。

ユーザー入力を取得してサーバーに送り返し、それを使用してデータベースと対話する場合。文字列の1つを終了して、独自のSQLステートメントを挿入する可能性があります。また、悪意のある考え方がなくても、引用符を送信すると、誤って文字列が終了する可能性があります。

于 2012-11-05T16:52:00.217 に答える
1

初心者/愚かな/ナイーブな開発者をサイトにXSSホールを作成することから保護する傾向があるようです。特に、他の誰かがこれらの応答を処理しようとしている場合（たとえば、オープンAPI、チームの一部のジュニア開発者）、文字列を$('#myelement).html()メソッドにフィードする前に、文字列を適切にHTMLエンコードするのを忘れる可能性があります。サーバー上でこれらの応答をエスケープすると、エスケープを理解していない開発者にとっては二重エスケープ（最悪の場合）になりますが、「賢い」開発者は、値を使用する前にいつエスケープを解除するかを知っています。代替案は、「あまり賢くない」開発者がXSSセキュリティホールでいっぱいのサイトを作成することです。

個人的にはこの傾向の大ファンではありませんが、特にWeb開発が趣味としてますます実践されているため、インターネット全体がより安全になることは確かです。ただし、これが、JSONのすべての文字列をhtmlエスケープするリクエストの背後にある理論的根拠です。

これを行う他の例：

  • Spotify
  • Open Social（リンクはありません。私の言葉を信じていただけると思います）
于 2012-11-06T00:46:03.640 に答える