GitHub पेज imtqy.com पर जाते हैं

आज से, सभी GitHub पृष्ठ साइटें नए डोमेन पर जा रही हैं: imtqy.com। यह सुरक्षा उपाय मुख्य सर्वर पर CSRF के हमलों को रोकने के लिए है - github.com। यदि आपकी साइट को "yoursite.github.com" के बजाय "yourite.com" के रूप में कॉन्फ़िगर किया गया है - तो परिवर्तन आपको प्रभावित नहीं करेंगे।
यदि आपकी साइट पहले डोमेन "username.github.com" पर स्थित थी, तो बाद के अनुरोधों को नए डोमेन: "username.imtqy.com" पर पुनर्निर्देशित किया जाएगा।
अब से, सभी साइट github.com उप डोमेन पर होस्ट की जा सकती है और इसे आधिकारिक GitHub उत्पाद माना जाना चाहिए।

तकनीकी विवरण

साइटों और उपयोगकर्ता डोमेन में परिवर्तन:

• सभी उपयोगकर्ता, संगठन और प्रोजेक्ट साइट github.com के बजाय imtqy.com के साथ काम करने के लिए कॉन्फ़िगर किए गए हैं।
• सभी * .github.com साइटों को कोड 301 से * .imtqy.com पर पुनर्निर्देशित किया गया है।
• उपयोगकर्ता डोमेन वाली साइटें प्रभावित नहीं हुईं ।
• आईपी ​​पते नहीं बदले हैं, मौजूदा ए-रिकॉर्ड पुराने आईपी को इंगित करते हैं।

GitHub रिपॉजिटरी में परिवर्तन:

• उपयोगकर्ता साइटों को नए या पुराने समझौते का उपयोग करके बुलाया जा सकता है: उपयोगकर्ता नाम / username.github। [Io / com]।
• पुराने समझौते के नाम पर मौजूदा साइट भंडार अपने काम को जारी रखेंगे।
• यदि पुराने और नए सम्मेलन द्वारा नामित दो रिपॉजिटरी हैं - * .imtqy.com जीत जाएगा।

सुरक्षा कमजोरियां।

संभावित कमजोरियों की दो मुख्य श्रेणियां हैं जिनके कारण ये परिवर्तन हुए।

• परिवर्तन सत्र और CSRF। चूंकि उपयोगकर्ता साइटें github.com उप डोमेन पर संग्रहीत जावास्क्रिप्ट को सक्षम कर सकती हैं, इसलिए github.com डोमेन से कुकीज़ रिकॉर्ड करना (लेकिन पढ़ना नहीं) संभव है, जो एक हमलावर को github.com तक पहुंचने और एक हमले को अंजाम देने की अनुमति देता है।
• फ़िशिंग हमले, जिसमें एक हमलावर एक समान साइट बनाता है और उपयोगकर्ता से गोपनीय जानकारी का अनुरोध करता है।

हमारे पास इस बात का कोई सबूत नहीं है कि इस तरह के हमले थे, फिर भी, हमने उन्हें पहले से रोकने की कोशिश की।
स्रोत: github.com/blog/1452-new-github-pages-domain-imtqy.com

UPD : टिप्पणियों में, s01o ने येगोर खोमकोव के पोस्ट की ओर इशारा किया, यह बताता है कि आप सभी एक हमले को कैसे अंजाम दे सकते हैं। जैसा कि यह पता चला, यह WebKit ब्राउज़रों में संभव है, क्योंकि वे एक विशेष तरीके से कुकीज़ के साथ काम करते हैं।

तो यह सामान्य ब्राउज़रों में काम करता है:
Cookie:_gh_sess=ORIGINAL; _gh_sess=HACKED;
आपको यह समझने की आवश्यकता है कि नाम के बावजूद _gh_sess दो अलग कुकीज़ हैं, और उन्हें एक ही समय में भेजा जाता है।
WebKit में, स्थिति अलग है, कुकीज़ डोमेन द्वारा नहीं भेजी जाती हैं (पहली प्रविष्टि होनी चाहिए डोमेन = github.com) httpOnly (जाहिर है, वे भी शुरुआत में होनी चाहिए) के साथ ही।
वास्तव में, वे सृजन समय के अनुसार हैं (इस स्थान पर मुझे गलत होना चाहिए, लेकिन यह वास्तव में ऐसा है)