हानिरहित क्रॉलर वेबफॉर्म प्रमाणीकरण को कैसे बाईपास करता है, और उपयोगकर्ता के सत्र को हाइजैक करता है?

Question

पिछली रात एक ग्राहक को बुलाया जाता था, क्योंकि Google ने निजी कर्मचारी की जानकारी के संस्करणों को कैश किया था। जानकारी तब तक उपलब्ध नहीं है जब तक कि आप लॉगिन न करें।

वे अपने डोमेन के लिए एक गूगल खोज, उदा .:

site:example.com 

किया था और पाया है कि Googled क्रॉल था, और कैश की गई, कुछ आंतरिक पृष्ठों।

अपने आप पृष्ठों के संचित संस्करण को देखते हुए:

यह https://example.com/(F(NSvQJ0SS3gYRJB4UUcDa1z7JWp7Qy7Kb76XGu8riAA1idys-nfR1mid8Qw7sZH0DYcL64GGiB6FK_TLBy3yr0KnARauyjjDL3Wdf1QcS-ivVwWrq-htW_qIeViQlz6CHtm0faD8qVOmAzdArbgngDfMMSg_N4u45UysZxTnL3d6mCX7pe2Ezj0F21g4w9VP57ZlXQ_6Rf-HhK8kMBxEdtlrEm2gBwBhOCcf_f71GdkI1))/ViewTransaction.aspx?transactionNumber=12345 का Google का संचय है। यह पृष्ठ का एक स्नैपशॉट है जैसा कि यह 15 सितंबर 2013 को दिखाई दिया था 00:07:22 जीएमटी

मुझे लंबे यूआरएल द्वारा भ्रमित किया गया था। के बजाय:

https://example.com/[...snip...]/ViewTransaction.aspx?transactionNumber=12345 

यह याद रखना मुझे कुछ मिनट लग गए: ASP.net के "कुकी-कम सत्र का लक्षण हो सकता है कि

https://example.com/ViewTransaction.aspx?transactionNumber=12345 

वहाँ एक लंबी स्ट्रिंग डाला था "। यदि आपका ब्राउज़र सेट-कुकी का समर्थन नहीं करता है, तो वेब साइट URL में एक कुकी एम्बेड करेगी।

हमारी साइट इसका उपयोग नहीं करती है।

और अगर हमारी साइट किया कुकी-कम सत्र स्वतः पता लगाए गए है, और गूगल यूआरएल में यह एक सत्र सौंपने में वेब सर्वर फुसलाना करने में कामयाब रहे, यह कैसे किसी अन्य उपयोगकर्ता के सत्र में ले गए थे?

हाँ, गूगल एक गैर दुर्भावनापूर्ण बॉट एक सत्र

साइट वर्षों के लिए बॉट द्वारा क्रॉल कर दिया गया है अपहरण कर लिया। और यह पिछले 2 9 मई कोई अलग नहीं था।

Google आमतौर पर robots.txt फ़ाइल (हमारे पास एक नहीं है) की जांच करके इसकी क्रॉल शुरू करता है। लेकिन कोई भी पहले प्रमाणीकृत जा रहा है बिना (robots.txt सहित) साइट पर तैयार कुछ भी करने के लिए अनुमति दी है, तो यह विफल रहता है:

Time  Uri      Port User Name   Status 
======== ======================= ==== ================ ====== 
1:33:04 GET /robots.txt   80      302 ;not authenticated, see /Account/Login.aspx 
1:33:04 GET /Account/Login.aspx 80      302 ;use https plesae 
1:33:04 GET /Account/Login.aspx 443      200 ;go ahead, try to login 

सभी उस समय गूगल के लिए robots.txt फ़ाइल के लिए देख रहा था। यह कभी नहीं मिला।

Time  Uri      Port User Name   Status 
======== ======================= ==== ================ ====== 
1:33:04 GET/     80      302 ;not authenticated, see /Account/Login.aspx 
1:33:04 GET /Account/Login.aspx 80      302 ;use https plesae 
1:33:04 GET /Account/Login.aspx 443      200 ;go ahead, try to login 

और सुरक्षित साइट पर robots.txt की दोबारा जांच:

Time  Uri      Port User Name   Status 
======== ======================= ==== ================ ====== 
1:33:04 GET /robots.txt   443      302 ;not authenticated, see /Account/Login.aspx 
1:33:04 GET /Account/Login.aspx 443      200 ;go ahead, try to login 

और फिर प्रवेश पृष्ठ पर स्टाइलशीट:

Time  Uri      Port User Name   Status 
======== ======================= ==== ================ ====== 
1:33:04 GET /Styles/Site.css  443      200  

तो यह मूल को क्रॉल करने की कोशिश करने के लिए रिटर्न

और इस तरह GoogleBot, msnbot, और BingBot से प्रत्येक क्रॉल काम करता है। रोबोट, लॉगिन, सुरक्षित, लॉगिन। कभी भी नहीं मिल रहा है, क्योंकि यह पिछले वेबफॉर्म प्रमाणीकरण नहीं मिल सकता है।और सब दुनिया के साथ अच्छा है।

एक दिन तक; कहीं भी

एक दिन तक, GoogleBot एक सत्र कुकी हाथ में के साथ दिखाई देता है!

Time  Uri      Port User Name   Status 
======== ========================= ==== =================== ====== 
1:49:21 GET/     443 jatwood@example.com 200 ;they showed up logged in! 
1:57:35 GET /ControlPanel.aspx  443 jatwood@example.com 200 ;now they're crawling that user's stuff! 
1:57:35 GET /Defautl.aspx   443 jatwood@example.com 200 ;back to the homepage 
2:07:21 GET /ViewTransaction.aspx 443 jatwood@example.com 200 ;and here comes the private information 

उपयोगकर्ता, jatwood@example.com एक दिन में लॉग इन नहीं किया गया था। (मैं उम्मीद कर रहा था कि आईआईएस ने एक साथ दो विज़िटर्स को एक ही सत्र पहचानकर्ता को एक आवेदन रीसायकल से अलग किया था)। और हमारी साइट (web.config) सत्र-रहित कुकीज़ सक्षम करने के लिए कॉन्फ़िगर नहीं है। और सर्वर (machine.config) सत्र-रहित कुकीज़ सक्षम करने के लिए कॉन्फ़िगर नहीं किया गया है।

तो:

• कैसे गूगल एक sessionless कुकी के ahold मिला?
• Google को वैध सत्र रहित कुकी का अधिकार कैसे प्राप्त हुआ?
• Google को मान्य किसी अन्य उपयोगकर्ता से संबंधित सत्र रहित कुकी का अधिकार कैसे प्राप्त हुआ?

के रूप में हाल में 1 अक्टूबर (4 दिन पहले) के रूप में, GoogleBot अभी भी, दिखा, हाथ में कुकी इस उपयोगकर्ता के रूप में लॉग इन करने, रेंगने, कैशिंग, और प्रकाशन, उनके निजी विवरण में से कुछ था।

कैसे गूगल एक गैर दुर्भावनापूर्ण वेब क्रॉलर को दरकिनार WebForms प्रमाणीकरण है?

आईआईएस 7, विंडोज सर्वर 2008 आर 2, एकल सर्वर।

सिद्धांतों

सर्वर कुकी-सत्र बाहर देने के लिए कॉन्फ़िगर नहीं है। लेकिन उस तथ्य को अनदेखा करते हुए, Google प्रमाणीकरण को कैसे बाईपास कर सकता है?

• GoogleBot वेब साइट पर जाकर है, और यादृच्छिक उपयोगकर्ता नाम और पासवर्ड प्रयास कर
• Googlebot URL स्ट्रिंग में एक यादृच्छिक कुकी-सत्र सम्मिलित करने का निर्णय लिया (संभावना नहीं, लॉग के लिए लॉग इन करने के लिए कोई प्रयास दिखाई देते हैं), और यह किसी मौजूदा उपयोगकर्ता (संभावना नहीं)
• उपयोगकर्ता यह पता लगाने कैसे एक आईआईएस वेब साइट लौट कुकी-यूआरएल (संभावना नहीं) बनाने के लिए करने में कामयाब के सत्र मैच के लिए हुआ है, तो उस यूआरएल पर चिपके हुए एक और वेब साइट (संभावना नहीं), जहां Google ने cookieless url पाया और इसे क्रॉल किया
• उपयोगकर्ता मोबाइल प्रॉक्सी (जो वे नहीं हैं) के माध्यम से चल रहा है। प्रॉक्सी सर्वर कुकीज़ का समर्थन नहीं करता है, इसलिए आईआईएस एक कुकीज सत्र बनाता है। वह (उदा। ओपेरा मोबाइल) कैशिंग सर्वर का उल्लंघन (संभव नहीं) और हैकर फ़ोरम पर पोस्ट किए गए सभी कैश किए गए लिंक का उल्लंघन किया गया था। GoogleBot ने हैकर फ़ोरम को क्रॉल किया, और सभी लिंक का पालन करना शुरू किया; हमारे jatwood@example.com कुकीज सत्र यूआरएल सहित।
• उपयोगकर्ता के पास एक वायरस है, जो किसी भी आईआईएस वेब-सर्वर को कुकेलिस यूआरएल को वापस करने में कामयाब होता है। वह वायरस फिर मुख्यालय की रिपोर्ट करता है। यूआरएल को सार्वजनिक रूप से सुलभ संसाधन पर पोस्ट किया जाता है, जिसे GoogleBot क्रॉल करता है। GoogleBot तब हमारे सर्वर पर cookieless url के साथ दिखाई देता है।

इनमें से कोई भी वास्तव में व्यवहार्य नहीं है।

Google एक गैर-दुर्भावनापूर्ण वेब-क्रॉलर बायपास वेबफॉर्म प्रमाणीकरण, और उपयोगकर्ता के मौजूदा सत्र को हाइजैक कर सकता है?

आप क्या पूछ रहे हैं?

मुझे यह भी पता नहीं है कि कैसे एक एएसपीनेट वेब साइट है, जो कुकीज-सत्र देने के लिए कॉन्फ़िगर नहीं है, कुकीज सत्र दे सकता है। क्या कुकी-आधारित सत्र आईडीकुकीज-आधारित सत्र आईडी में वापस कनवर्ट करना संभव है? मैं web.config और machine.config के प्रासंगिक <sessionState> अनुभाग बोली सकता है, और दिखाने के

<sessionState cookieless="true"> 

कैसे वेब सर्वर का फैसला करता है कि ब्राउज़र समर्थन नहीं देता है की कोई उपस्थिति नहीं है? मैंने क्रोम में कुकीज़ को अवरुद्ध करने का प्रयास किया, और मुझे कभी कुकी-कम सत्र पहचानकर्ता नहीं दिया गया था। क्या मैं एक ब्राउज़र को अनुकरण कर सकता हूं जो 'कुकीज़ का समर्थन नहीं करता है, यह सत्यापित करने के लिए कि मेरा सर्वर कुकीज सत्र नहीं दे रहा है?

क्या सर्वर उपयोगकर्ता-एजेंट स्ट्रिंग द्वारा कुकीज सत्र का निर्णय लेता है? यदि ऐसा है, तो मैं इंटरनेट एक्सप्लोरर को एक स्पूफेड UA के साथ सेट कर सकता हूं।

क्या एएसपीनेट में सत्र पहचान पूरी तरह से कुकी पर निर्भर करती है? क्या कोई भी आईपी, कुकी-यूआरएल के साथ, उस सत्र तक पहुंच सकता है? क्या एएसपीनेट डिफ़ॉल्ट रूप से नहीं खाता है?

ASP.net हैं सत्र के साथ टाई आईपी पता, इसका मतलब यह नहीं होता है कि सत्र उनके घर के कंप्यूटर पर कर्मचारी से उत्पन्न नहीं हो सकता था? क्योंकि तब जब GoogleBot क्रॉलर ने इसे Google आईपी से उपयोग करने का प्रयास किया, तो यह असफल रहा होगा?

क्या एएसपीनेट के कहीं भी (उदाहरण के लिए मैंने लिंक किया है) के अलावा कोई भी उदाहरण है जब इसे कॉन्फ़िगर नहीं किया गया है? क्या इस पर एक माइक्रोसॉफ्ट कनेक्ट मुद्दा है?

क्या वेब-फॉर्म प्रमाणीकरण समस्याएं हैं, और सुरक्षा के लिए उपयोग नहीं किया जाना चाहिए?

बोनस पढ़ना

• A guy on StackOverflow who's web-server is sometimes giving out cookieless urls when it's not configured to

संपादित: गूगल बॉट कि विशेषाधिकार को नजरअंदाज कर, के रूप में लोगों को सिर से मंद पर पैंट हैं निकाला गया नाम; उलझन में Google किसी और चीज़ के लिए क्रॉलर का नाम। मैं Google क्रॉलर का नाम अनुस्मारक के रूप में उपयोग करता हूं कि यह एक गैर-दुर्भावनापूर्ण वेब-क्रॉलर था जो किसी अन्य उपयोगकर्ता के वेबफॉर्म सत्र में इसे क्रॉल करने में कामयाब रहा।यह एक दुर्भावनापूर्ण क्रॉलर के विपरीत है, जो किसी अन्य उपयोगकर्ता के सत्र में तोड़ने की कोशिश कर रहा था। उत्तेजना लाने के लिए एक पैडेंट की तरह कुछ भी नहीं।

Answer 1

हालांकि प्रश्न मुख्य रूप से सत्र पहचानकर्ताओं का संदर्भ देता है, पहचानकर्ता की लंबाई ने मुझे असामान्य रूप से मारा।

कम से कम दो प्रकार की कुकी/कुकीज ऑपरेशंस हैं जो आईडी को शामिल करने के लिए क्वेरी स्ट्रिंग को संशोधित कर सकते हैं।

• कुकी-सत्र
• कुकी-रूपों को प्रमाणीकरण टोकन का

वे एक दूसरे से पूरी तरह अलग हैं (जहाँ तक मैं बता सकता हूँ)।

सत्र स्थिति

कुकी-सत्र सर्वर बनाम एक कुकी में एक अद्वितीय ID URL में एक अद्वितीय ID के आधार पर सत्र स्थिति डेटा का उपयोग करने की अनुमति देता है। इसे आमतौर पर एक अच्छा अभ्यास माना जाता है, हालांकि एएसपी.Net सत्र आईडी का पुन: उपयोग करता है जो इसे सत्र निर्धारण प्रयासों (अलग विषय के बारे में जानने के लायक) के लिए अधिक प्रवण बनाता है।

क्या एएसपीनेट में सत्र पहचान पूरी तरह से कुकी पर निर्भर करती है? किसी भी आईपी से, कुकी-यूआरएल के साथ, उस सत्र तक पहुंच सकते हैं? डिफ़ॉल्ट रूप से ASP.net नहीं, खाते में भी ध्यान देता है?

सत्र आईडी सभी आवश्यक है।

General Session Security Reading

फार्म प्रमाणीकरण

उदाहरण डेटा की लंबाई के आधार पर, मेरा अनुमान है कि अपने URL वास्तव में एक रूपों प्रमाणीकरण मूल्य, नहीं एक सत्र ID शामिल हैं। स्रोत कोड से पता चलता है कि कुकीज मोड ऐसा कुछ नहीं है जिसे आपको स्पष्ट रूप से सक्षम करना चाहिए।

/// <summary>ASP.NET determines whether to use cookies based on 
/// <see cref="T:System.Web.HttpBrowserCapabilities" /> setting. 
/// If the setting indicates that the browser or device supports cookies, 
/// cookies are used; otherwise, an identifier is used in the query string.</summary> 
UseDeviceProfile 

यहाँ कैसे दृढ़ संकल्प किया जाता है है:

// System.Web.Security.CookielessHelperClass 
internal static bool UseCookieless(HttpContext context, bool doRedirect, HttpCookieMode cookieMode) 
{ 
    switch(cookieMode) 
    { 
     case HttpCookieMode.UseUri: 
      return true; 
     case HttpCookieMode.UseCookies: 
      return false; 
     case HttpCookieMode.AutoDetect: 
      { 
       // omitted for length 
       return false; 
      } 
     case HttpCookieMode.UseDeviceProfile: 
      if(context == null) 
      { 
       context = HttpContext.Current; 
      } 
      return context != null && (!context.Request.Browser.Cookies || !context.Request.Browser.SupportsRedirectWithCookie); 
     default: 
      return false; 
    } 
} 

पता है क्या डिफ़ॉल्ट है? HttpCookieMode.UseDeviceProfile। एएसपी.Net उपकरणों और क्षमताओं की एक सूची बनाए रखता है। यह सूची आम तौर पर एक बहुत बुरी बात है; नेटस्केप के साथ बराबर के example, IE11 gives a false positive for being a downlevel browser के लिए 4.

कारण

मुझे लगता है कि जीन की व्याख्या बहुत संभावना है; Google ने कुछ उपयोगकर्ता कार्रवाई से यूआरएल पाया और इसे क्रॉल किया।

यह पूरी तरह से कल्पना की जा सकती है कि Google बॉट कुकीज़ का समर्थन नहीं करने के लिए समझा जाता है। लेकिन यह यूआरएल की उत्पत्ति की व्याख्या नहीं करता है, यानी Google ने यूआरएल को पहले से मौजूद आईडी के साथ यूआरएल देखने के परिणामस्वरूप क्या किया है? एक साधारण स्पष्टीकरण एक ब्राउज़र वाला उपयोगकर्ता हो सकता है जिसे कुकीज़ का समर्थन नहीं माना जाता था। ब्राउज़र के आधार पर, बाकी सब कुछ उपयोगकर्ता के लिए ठीक लग सकता है।

समय, यानी वैधता की अवधि लंबी लगती है, हालांकि मैं इस बात से परिचित नहीं हूं कि प्रमाणीकरण टिकट कब मान्य हैं और किस परिस्थिति में उन्हें नवीनीकृत किया जा सकता है। यह पूरी तरह से संभव है एएसपी.Net निरंतर सक्रिय उपयोगकर्ता के लिए टिकटों को फिर से जारी/नवीनीकृत करना जारी रखता है।

संभव समाधान

मैं यहाँ मान्यताओं का एक बहुत बना रही हूँ, लेकिन अगर मैं सही हूँ:

• पहले, अपने वातावरण में व्यवहार को पुनः।

• HttpCookieMode.UseCookies का उपयोग कर कुकीज व्यवहार को स्पष्ट रूप से अक्षम करें।

  web.config:

  <authentication mode="Forms"> 
      <forms loginUrl="~/Account/Login.aspx" name=".ASPXFORMSAUTH" timeout="26297438" 
        cookieless="UseCookies" /> 
  </authentication> 
  

इस व्यवहार को हल करना चाहिए, आप रूपों प्रमाणीकरण HTTP मॉड्यूल का विस्तार और अतिरिक्त सत्यापन (या कम से कम प्रवेश/निदान) जोड़ने की जांच हो सकती है।

Answer 2

आपने विचारों के लिए कहा, इसलिए मैं कुछ दूंगा। कोई वारंटी व्यक्त या निहित नहीं है।

यह विचार छोड़ दें कि आपकी साइट को यूआरआई में सत्र जानकारी एन्कोड न करने के लिए कॉन्फ़िगर किया गया है। बहुत अधिक संभावना के साथ ऐसा किया। या तो आप कॉन्फ़िगरेशन के बारे में गलत हैं या (अधिक संभावना है) वहां एक बग है जो ऐसा करने का कारण बनती है।

यह केंद्रीय प्रश्न छोड़ देता है: Google ने यूआरआई सत्र कैसे प्राप्त किया?

आपने ग्राहक आधार के बारे में कुछ भी नहीं कहा। यहां अनुमान लगाया गया है:

एक ग्राहक ने सिस्टम में लॉग इन किया जिसने सत्र के यूआरआई एन्कोडिंग का निर्माण किया, फिर किसी अन्य व्यक्ति को जीमेल खाते का उपयोग करके ईमेल किया। Google ने ईमेल स्कैन किया और यूआरआई को क्रॉलर बॉट प्रदान किया।

ऐसे अन्य तरीके भी हैं जिनसे ग्राहक जिस ग्राहक ने यूआरआई का उत्पादन किया है, वह अनजाने में Google को आत्मसमर्पण कर सकता है। Google ड्राइव दस्तावेज़। Google प्लस पोस्टिंग। आदि

Google बुरा नहीं हो सकता है, लेकिन फिर भी वे हर जगह हैं। उनके उपयोग समझौते से उन्हें खोज के लिए मेल (आदि) में, उत्पाद सीमाओं में लिंक को स्थानांतरित करने देता है।

असली सवाल यह है कि आपको इस बारे में सोचना चाहिए कि आपकी साइट क्रॉस-साइट अनुरोध जालसाजी से क्यों सुरक्षित नहीं है। रेल explain this pretty nicely लोग हैं। रेल protect_from_forgery तंत्र ने रिपोर्ट की समस्या को रोका होगा।

एक संबंधित प्रश्न यह है कि एन्कोडेड कुकी (स्पष्ट रूप से) कभी समाप्त नहीं होती है। इसे बनाने के लिए सत्रों को टाइमस्टैम्प रखना आसान होना चाहिए।