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




login session-cookies (7)

आप पहले लेकिन पहले से ताज़ा नहीं करेंगे। लॉगिन कार्रवाई को निष्पादित करते समय पहले करें:

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)

एफवाईआई आप इस चाल के साथ क्या हल कर रहे हैं http://www.owasp.org/index.php/Session_Fixation

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

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

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

वे निम्न में से किसी एक का सुझाव देते हैं:

  1. लॉगिन के बाद एक नया JSESSIONID कुकी जारी करें
  2. एक JSESSIONID कुकी को लॉग इन पेज पर पहले स्थान पर सेट करने से रोकें (यानी, प्रमाणीकरण होने से पहले)

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

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

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

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


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

1. लॉगिन के बाद एक नया JSESSIONID कुकी जारी करें

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

यदि आपका लॉगिन स्वयं http से अधिक है, तो मुझे लगता है कि ऑडिटर के लिए यह एक और सुरक्षा समस्या है;)

या आपके सभी पेज https पर हैं?


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

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

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

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

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

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

इसका क्या अर्थ है, यह है कि भले ही कोई हमलावर लॉग इन करने से पहले नियंत्रित मूल्य का उपयोग करने में आपको चाल करने का प्रबंधन करता है, फिर भी आप सुरक्षित हैं .. एप्लिकेशन लॉग इन करने के बाद मूल्य को जबरन बदल देता है।

इस मुद्दे के बारे में यहां एक अच्छा ब्लॉग है - https://blog.whitehatsec.com/tag/session-fixation/


मैंने पुराने सत्र से नए सत्र को पुन: उत्पन्न करने के लिए निम्नलिखित तरीके का पालन किया है। आशा है कि आप इससे लाभान्वित होंगे।

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));
        }
    }

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


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

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

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

  1. नया सत्र बनाएं
  2. पुराने सत्र के tranfer विशेषताएँ।

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);
}