लॉगिन के बाद JSESSIONID कुकी को रीफ्रेश करने के लिए कैसे करें

Question

एक उत्पाद जिस पर मैं काम करता हूं उसे एक संभावित ग्राहक द्वारा कठिन सुरक्षा लेखा परीक्षा मिलती है और वे परेशान हैं कि प्रमाणीकरण होने से पहले टोमकैट एक JSESSIONID कुकी सेट करता है। यही है, जब हमारे स्टेटलेस लॉगिन पेज लोड होते हैं, लेकिन लॉगिन से पहले, टोमकैट इस कुकी को सेट करता है। प्रवेश के बाद

1. मुद्दा एक नया jsessionid कुकी
2. (अर्थात प्रमाणीकरण से पहले हुआ है) लॉगिन पृष्ठ पर पहली जगह में स्थापित किया जा रहा से एक jsessionid कुकी को रोकने:

   वे निम्नलिखित में से किसी का सुझाव

मैं इस साइट पर JSESSIONID से संबंधित सब कुछ के माध्यम से पोरिंग कर रहा हूं और कोई आसान जवाब नहीं मिल सकता है। मैं बस कुछ विचारों की उम्मीद कर रहा हूं। प्रत्येक के लिए मेरे सबसे अच्छे समाधान हैं:

1. सही प्रवेश के बाद, सत्र (ऋण आईडी) सभी विशेषताओं को कॉपी, पुराने सत्र अमान्य, एक नया बनाने, मूल्यों को कॉपी, अनुरोध के साथ संबद्ध द्वारा क्लोन , और उम्मीद है कि काम करता है।
2. लॉग इन पेज प्रारंभ में लोड होने से पहले JSESSIONID कुकी को स्ट्रिप करने वाली श्रृंखला के बहुत अंत में एक सर्वलेट फ़िल्टर बनाएं। और फिर उम्मीद है कि लॉगिन अनुरोध JSESSIONID सेट के बिना काम करता है।

मुझे कुछ नींद आनी है, लेकिन सुबह में इनका प्रयास किया जाएगा। लोगों से कुछ ज्यादा प्रतिक्रिया या बेहतर सुझाव प्राप्त करना बहुत ही अच्छा होगा - जैसे आप!

भले ही, मैं यहां अपने परिणाम पोस्ट करूंगा क्योंकि ऐसा लगता है कि बहुत से लोग कुछ ऐसा करना चाहते हैं।

Answer 1

आप पहले के बाद ताज़ा नहीं करेंगे। जब लॉगिन क्रिया निष्पादित करते पहले है:

HttpSession session = request.getSession(false); 
if (session!=null && !session.isNew()) { 
    session.invalidate(); 
} 

तब कार्य करें:

HttpSession session = request.getSession(true); // create the session 
// do the login (store the user in the session, or whatever) 

FYI करें क्या आप इस चाल के साथ हल करते http://www.owasp.org/index.php/Session_Fixation

अन्त में आप स्वत: सत्र निर्माण निष्क्रिय कर सकते हैं और केवल बनाने है सत्र जब आपको वास्तव में इसकी आवश्यकता होती है।यदि आप जेएसपी का उपयोग करते हैं तो आप इसे करते हैं:

<%@page contentType="text/html" 
     pageEncoding="UTF-8" 
     session="false"%> 

Answer 2

क्या समस्या है कि JSESSIONID ब्राउज़र में दिखाई दे रहा है या यह कुकी में बिल्कुल सेट हो जाता है? मुझे लगता है कि यह आपके मामले में उत्तरार्द्ध है।

1.issue एक लॉगिन

इस के बाद नए jsessionid कुकी डिफ़ॉल्ट बिलाव व्यवहार यदि आप लॉग-इन करने के समय https को http स्विच करते हैं। पुराना एक त्याग दिया जाता है और एक नया उत्पन्न होता है।

अपना लॉगिन ही http खत्म हो गया है, तो मुझे लगता है कि है कि लेखा परीक्षकों के लिए एक और सुरक्षा मुद्दा है;)

या HTTPS पर आपके सभी पृष्ठों कर रहे हैं?

Answer 3

दो चीजें जो मुझे मिली हैं जो दूसरों के लिए सहायक हो सकती हैं।

1. यदि आप अपाचे विकेट का उपयोग कर रहे हैं, तो संस्करण 1.4 के बाद इसका समाधान है। मेरा ऐप अभी भी 1.3 पर है, इसलिए मुझे एहसास नहीं हुआ, लेकिन मैं इसे अपने वेब सत्र वर्ग में बहुत आसानी से बंद कर सकता था। विकेट 1.4 वेबसेशन में एक प्रतिस्थापन सत्र() विधि जोड़ता है, जो बहुत अच्छा काम करता है। प्रमाणीकरण के बाद आप इसे सही कह सकते हैं और आपको एक नया JSESSIONID मिल जाएगा। यह मूल रूप से मेरे लिए इस समस्या को हल किया। यहां अधिक जानकारी: https://issues.apache.org/jira/browse/WICKET-1767।

2. संस्करण 5.5.29 के बाद एक अपाचे टॉमकैट वाल्व उपलब्ध है जिसे आप context.xml में जोड़ सकते हैं। यह प्रमाणीकरण के बाद एक नया JSESSIONID जारी करने में संभाल लेंगे। अधिक जानकारी यहां उपलब्ध है: https://issues.apache.org/bugzilla/show_bug.cgi?id=45255। वाल्व के लिए प्रवेश इस प्रकार दिखाई देगा: <Valve className="org.apache.catalina.authenticator.FormAuthenticator" changeSessionIdOnAuthentication="true"/>

Answer 4

मैं @ cherouvim के जवाब पर टिप्पणी नहीं कर सकता, जैसा कि ऊपर मैं पर्याप्त अंक नहीं है। सत्र निर्धारण से बचने के लिए, नया सत्र आईडी उपयोगकर्ता को "सफलतापूर्वक लॉग इन" करने के बाद सेट किया जाना चाहिए। मैं अपने तर्क की कोशिश करूँगा और समझाऊंगा।

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

अब मान लें कि हम पीड़ित उपयोगकर्ता लॉग इन करने से पहले session.invalidate चला चुके हैं। आइए कहें कि कुकी में शुरुआत में एक मूल्य एबीसी था। चल रहे session.invalidate पर मूल्य एबीसी सर्वर के सत्र से शुद्ध किया गया है।

अब वह हिस्सा आता है जहां मैं असहमत हूं। आप जो सुझाव देते हैं वह उपयोगकर्ता वास्तव में लॉग इन करने से पहले एक नया सत्र उत्पन्न करना है (उपयोगकर्ता नाम और पासवर्ड दर्ज करता है और क्लिक सबमिट करता है)। इसमें कोई संदेह नहीं होगा कि एक नई कुकी उत्पन्न हो जाएगी लेकिन यह लॉगिन करने से पहले उपयोगकर्ता के ब्राउज़र पर होगी। तो यदि कोई हमलावर फिर से "प्रीलॉगिन" कुकी को संपादित कर सकता है, तो हमला अभी भी जारी रहता है, क्योंकि उपयोगकर्ता के लॉग इन करने के बाद भी उसी कुकी का उपयोग किया जाएगा।

मुझे लगता है कि यह सही प्रवाह है।

• उपयोगकर्ता किसी GET /login.html
• उपयोगकर्ता में प्रवेश करती है साख और क्लिक्स प्रस्तुत
• आवेदन साख
• पुष्टि करता है कि खोजने पर जो कुछ भी कुकी ब्राउज़र में वर्तमान में है के साथ
• वापसी लॉग इन पेज करता है प्रमाण पत्र सही थे। session.invalidate() चलाया जाता है .. पुरानी कुकी को नष्ट कर रहा है।
• अब request.getSession (सच)

इसका मतलब क्या है, कि एक हमलावर में प्रवेश करने से पहले एक नियंत्रित मूल्य का उपयोग कर जाल में फंसाने की प्रबंधन करता है, भले ही आप कर रहे हैं है का उपयोग करते हुए नई कुकी उत्पन्न अभी भी सुरक्षित है .. एप्लिकेशन लॉग इन करने के बाद जबरन मूल्य बदलता है।https://blog.whitehatsec.com/tag/session-fixation/

Answer 5

मैं पुराने सत्र से नया सत्र पुनर्जीवित करने के लिए जिस तरह से निम्नलिखित का पालन किया है -

यहाँ इस मुद्दे के बारे में एक अच्छा ब्लॉग है। आशा है कि आप इससे लाभान्वित होंगे।

private void regenerateSession(HttpServletRequest request) { 

    HttpSession oldSession = request.getSession(); 

    Enumeration attrNames = oldSession.getAttributeNames(); 
    Properties props = new Properties(); 

    if (attrNames != null) { 
     while (attrNames.hasMoreElements()) { 
      String key = (String) attrNames.nextElement(); 
      props.put(key, oldSession.getAttribute(key)); 
     } 

     //Invalidating previous session 
     oldSession.invalidate(); 
     //Generate new session 
     HttpSession newSession = request.getSession(true); 
     attrNames = props.keys(); 

     while (attrNames.hasMoreElements()) { 
      String key = (String) attrNames.nextElement(); 
      newSession.setAttribute(key, props.get(key)); 
     } 
    } 

Answer 6

session=request.getSession(true); 
Enumeration keys = session.getAttributeNames();  
HashMap<String,Object> hm=new HashMap<String,Object>(); 
while (keys.hasMoreElements()) 
{ 
    String key = (String)keys.nextElement(); 
    hm.put(key,session.getValue(key)); 
    session.removeAttribute(key);  
} 
session.invalidate(); 
session=request.getSession(true); 
for(Map.Entry m:hm.entrySet()) 
{ 
    session.setAttribute((String)m.getKey(),m.getValue()); 
    hm.remove(m); 
} 

Answer 7

जब वसंत का उपयोग कर, आप SessionFixationProtectionStrategy उपयोग करना चाहिए।

<property name="sessionAuthenticationStrategy" ref="sas"/> 
... 
<bean id="sas" class="org.springframework.security.web.authentication.session.SessionFixationProtectionStrategy"/> 

जब source code निरीक्षण, आपको लगता है कि इस harsha89 के दृष्टिकोण के समान है देखेंगे: यह

1. एक नया सत्र वर्ष सत्र के
2. tranfer गुण पैदा करेगा।

Answer 8

आप बिलाव उपयोग कर रहे हैं और अपने सभी सर्वलेट्स जो बिलाव के प्रमाणीकरण तंत्र का उपयोग करने के लिए विश्व स्तर इस लागू करना चाहते हैं, तो आप के रूप में इस sample code.

Answer 9

में दिखाया गया है, इस व्यवहार के लिए मजबूर करने के लिए एक वाल्व लिख सकते हैं आप उपयोग कर रहे हैं जेबॉस 4 का पुराना संस्करण jboss 4 की तरह बस session.validate() कॉल के बाद request.getSession (true) को कॉल करना सत्र आईडी को नहीं बदलेगा।

यदि आप वाल्व का उपयोग नहीं करना चाहते हैं और एक्शन क्लास में सत्र आईडी को बदलना चाहते हैं तो प्रतिबिंब का उपयोग करके संग्रहीत किया जा सकता है क्योंकि CatalinaRequest सीधे आपके एक्शन क्लास में उपलब्ध नहीं होगा।

नमूना कोड

private HttpSession changeSessionId(HttpServletRequest request) 
{ 
    HttpSession oldSession = request.getSession(false); 
    HttpSession newSession = null; 

    try 
    { 
     //get all cookies from request 
     Cookie[] cookies = request.getCookies(); 

     //Get all attribute from old session 
     Enumeration<Object> attrNames = oldSession.getAttributeNames(); 

     Properties attributFromOldSession = new Properties(); 

     while (attrNames.hasMoreElements()) 
     { 
      String key = (String)attrNames.nextElement(); 
      attributFromOldSession.put(key, oldSession.getAttribute(key)); 
     } 

     //Actual logic to change session id 

     Field catalinaRequestField; 

     //Getting actual catalina request using reflection 
     catalinaRequestField = request.getClass().getDeclaredField("request"); 
     catalinaRequestField.setAccessible(true); // grant access to (protected) field 
     Request realRequest = (Request)catalinaRequestField.get(request); 

     //Invalidating actual request 
     realRequest.getSession(true).invalidate(); 
     realRequest.setRequestedSessionId(null); 
     realRequest.clearCookies(); 

     //setting new session Id 
     realRequest.setRequestedSessionId(realRequest.getSessionInternal(true).getId()); 

     //Put back the cookies 
     for (Cookie cookie : cookies) 
     { 

      if (!"JSESSIONID".equals(cookie.getName())) 
      { 
       realRequest.addCookie(cookie); 
      } 
     } 

     // put attribute from old session 
     attrNames = attributFromOldSession.keys(); 

     while (attrNames.hasMoreElements()) 
     { 
      String key = (String)attrNames.nextElement(); 
      newSession.setAttribute(key, attributFromOldSession.get(key)); 
     } 
    } 
    catch (Exception e) 
    { 
     e.printStackTrace(); 
    } 
    return newSession; 

} 

Answer 10

HttpServletRequest.changeSessionId() किसी भी समय पर सत्र आईडी बदलने के लिए उपयोग हो सकता है।