サイトが以前に「username.github.com」というドメインにあった場合、以降のリクエストは新しいドメイン「username.github.io」にリダイレクトされます。
これ以降、github.comサブドメインでホストされているすべてのサイトは、公式のGitHub製品と見なされる可能性があります。
技術的な詳細
サイトおよびユーザードメインの変更：
- github.comではなくgithub.ioで動作するように構成されたすべてのユーザー、組織、およびプロジェクトサイト。
- すべての* .github.comサイトは、コード301で* .github.ioにリダイレクトされます。
- ユーザードメインを持つサイトは影響を受けません。
- IPアドレスは変更されておらず、既存のAレコードは古いIPを指しています。
GitHubリポジトリの変更：
- ユーザーサイトは、新しいまたは古い契約を使用して呼び出すことができます：username / username.github。[Io / com]。
- 古い契約にちなんで名付けられた既存のサイトリポジトリは、作業を継続します。
- 古い規則と新しい規則で名前が付けられた2つのリポジトリがある場合、* .github.ioが勝ちます。
セキュリティの脆弱性。
これらの変更につながった潜在的な脆弱性には、主に2つのカテゴリがあります。
- セッションとCSRFを変更します。 ユーザーサイトはgithub.comサブドメインに保存されたJavaScriptを有効にできるため、github.comドメインからCookieを書き込むことができます（読み取りはできません）。これにより、攻撃者はgithub.comにアクセスして攻撃を実行できます。
- フィッシング攻撃。攻撃者が同様のサイトを作成し、ユーザーに機密情報を要求します。
しかし、そのような攻撃が前もって阻止しようとしたという証拠はありません。
ソース： github.com/blog/1452-new-github-pages-domain-github-io
UPD ：コメントでは、 s01o は Yegor Khomakovの投稿を指しており、攻撃を実行する方法をすべて示しています。 判明したように、WebKitブラウザーでは特別な方法でCookieを処理するため、可能です。
したがって、通常のブラウザで動作します：
Cookie:_gh_sess=ORIGINAL; _gh_sess=HACKED;
名前に関係なく、_gh_sessは2つの異なるCookieであり、同時に送信されることを理解する必要があります。
WebKitでは、状況は異なります。Cookieはドメインによって送信されません（最初のエントリはDomain = github.comである必要があります）。httpOnlyとまったく同じです（明らかに、先頭にある必要があります）。
実際、それらは作成時間順に並べられています（この場所では間違っているはずですが、これが実際の方法です）