text/html
この登録は、IANAで正常に提出されている。
charset
charset
パラメータは、文書内の任意の文字エンコーディング宣言を上書きし、文書の文字エンコーディングを断定的に指定するために供給されてもよい。パラメータの値は、ファイルをシリアル化するために使用される文字エンコーディングのラベルでなければならない。[ENCODING]
全体小説はHTML文書に適用するセキュリティ上の考慮事項について書かれている。読者が詳細について参照する場合、多くはこの文書に記載されている。しかし、一部の一般的な懸念はここで特筆に値する:
HTMLはスクリプト化言語であり、多数のAPI(一部はこの文書に記載される)を持つ。スクリプトは、情報漏洩、認証情報漏洩、クロスサイトスクリプティング攻撃、クロスサイトリクエストフォージェリ、および他の多くの問題に関して潜在的なリスクをユーザーに公開できる。この仕様の設計は正しく実装されれば安全であることを意図する一方で、任意のソフトウェアと同様に、完全な実装は大規模な事業であり、ユーザーエージェントはセキュリティーバグを持つ可能性がある。
スクリプトを使用しないけれども、歴史的な理由により、レガシーコンテンツとの幅広い互換性を保つために必要であるが、不幸なセキュリティー上の問題をユーザーに公開するHTML内の特定の機能が存在する。具体的に、img
要素はインターネット上のユーザーの場所からポートスキャンに影響を与えるための方法として他の機能と組み合わせて使用できる。これは、攻撃者が別の方法で判断することができないだろうローカルネットワークトポロジーを公開できる。
HTMLは、時に同一生成元ポリシーとして知られる区画化スキームに依存する。ほとんどの場合に生成元は、同じプロトコルを使用して、同じポート上で同じホストから提供されるすべてのページで構成する。
したがって、サイトの一部を形成する任意の信頼できないコンテンツがそのサイト上のすべての機密コンテンツとは異なる生成元でホストされていることを確認することは非常に重要である。信頼できないコンテンツは、同じ生成元に他のページを簡単に偽装でき、その生成元からデータを読み取り、実行するために生成元にスクリプトを引き起こし、たとえそれらがユニークなトークンによってクロスサイトリクエストフォージェリ攻撃から保護されている場合でも、その生成元からフォームを送信し、任意のサードパーティのリソースを公開するために活用するまたはその生成元に付与された権利を利用することができる。
multipart/x-mixed-replace
この登録は、IANAで正常に提出されている。
boundary
(RFC2046で定義される)[RFC2046]
multipart/x-mixed-replace
リソースのサブリソースは、text/html
などの自明でないセキュリティーへの影響を持つタイプを含めた、任意のデータ型を指定できる。
application/xhtml+xml
xhtml
"および"xht
"は、時にHTML名前空間由来のルート要素を持つXMLリソースの拡張子として使用される。application/x-www-form-urlencoded
この登録は、IANAで正常に提出されている。
分離して、application/x-www-form-urlencoded
ペイロードはセキュリティ上のリスクをもたらすものでない。しかし、このタイプは通常フォーム送信の一部として使用されるので、HTMLフォームに適用するすべてのリスクは、このタイプのコンテキストで考慮する必要がある。
これらのリスクは、同一生成元ポリシーおよびHTMLフォームの異なる生成元のリーチ(http://www.w3.org/TR/cors/#security)、一般的なHTMLアプリケーションの脅威(http://www.w3.org/TR/html/single-page.html#writing-secure-applications-with-html)、ユーザからのフィードバック以外でクライアント側の検証に頼らない(http://www.w3.org/TR/html/single-page.html#security-forms)に関連する複数のカテゴリに分類される。
application/x-www-form-urlencoded
ペイロードを生成して処理するための規則は、この仕様で定義される。
text/cache-manifest
この登録は、IANAで正常に提出されている。
charset
charset
パラメータは提供されてもよい。パラメータの値は"utf-8
"でなければならない。このパラメータは、目的を達成しない。これはレガシーサーバとの互換性のためのみに許可される。
キャッシュマニフェスト自身は、実行可能なコンテンツを含まず、機密情報がマニフェスト内に含まれない限り、すぐに危険を引き起こさない。
しかし、実装は、キャッシュマニフェストに基づくキャッシュを取り込む際、その特定の生成元ベースの制限が履行されることを確認するために、特定の規則に従う必要がある。これらの規則を正しく実装できない場合、情報漏洩、クロスサイトスクリプティング攻撃などが発生するかもしれない。
キャッシュ機構は典型的に汚染攻撃の対象であり、このファイルタイプがサポートするものも例外ではない。公開された仕様は、そのような問題(キャプティブポータルから特に悪意のないキャッシュポイズ)を軽減することを意図する手順を含むが、実装者は、キャッシングに注意を払うことを勧める。
また、このキャッシュ機構の永続性、ユーザーのプライバシー(http://www.w3.org/TR/html/single-page.html#expiring-application-caches)およびストレージリソース(http://www.w3.org/TR/html/single-page.html#disk-space)に関して注意がとられる必要がある。
web+
スキーマ接頭辞このセクションは、IANAのURIスキームレジストリで使用するための規則を説明する。これ自体は特定のスキームを登録しない。[RFC4395]
web+
"で始まり、その後にa
-z
範囲内の1つ以上の文字が続く。
web+
"スキームは、UTF-8エンコーディングが関連したように使用すべきである。web+
"スキームに対するハンドラを登録できる。このように、これらスキームはコアプラットフォームの機能(たとえばHTTPまたはFTPなどのネットワーク転送プロトコルなど)になるように意図された機能のために使用してはならない。同様に、このようなスキームは、ユーザー名、パスワード、個人情報、または機密プロジェクト名として、そのURLに機密情報を格納してはならない。