req_id

वर्किंग ग्रुप का सुझाव

8.1.6

इस ज़रूरी शर्त पर कुछ और कार्रवाई की जाएगी (उदाहरण के लिए, बैक अप को सिर्फ़ X समय तक सेव करके रखना चाहिए. बैक अप पर चोरी/करप्शन के लिए नज़र रखी जानी चाहिए, बैक अप को समय-समय पर ऑडिट किया जाना चाहिए, ताकि यह पक्का किया जा सके कि उन्हें प्रोडक्शन में वापस ले जाया जा सके). मौजूदा अनुमान बहुत बड़ा है और इसके लिए और परिभाषा की ज़रूरत है.

5.1.4

अन्य टेस्ट केस की डुप्लीकेट कॉपी. यह एक कम प्रयास वाला उदाहरण है. इन्हें हटाने का सुझाव दिया जाता है.

7.3.3

अन्य टेस्ट केस की डुप्लीकेट कॉपी. यह एक कम प्रयास वाला उदाहरण है. इन्हें हटाने का सुझाव दिया जाता है.

1.2.2

4.1.1 जैसी दूसरी ज़रूरी शर्तों के तहत कवरेज की वजह से हटाना

2.2.4

ज़रूरत के हिसाब से, 4.3.1 वर्शन से हटाएं

(4.3.1 पुष्टि करना कि एडमिन इंटरफ़ेस सही मल्टी-फ़ैक्टर पुष्टि का इस्तेमाल करता है

इसमें, बिना अनुमति के इस्तेमाल किए जाने पर रोक होती है. इसमें, एडमिन इंटरफ़ेस और दूसरे अंदरूनी ऐक्सेस पाथ में फ़िशिंग के ख़िलाफ़ पहचान की चोरी होने से बचा जाता है

2.2.5

ज़्यादातर सीएसपी, mTLS के साथ काम नहीं करते हैं. इसलिए, CASA के लिए टेस्ट किए गए ज़्यादातर डेवलपर, पासवर्ड के आधार पर पुष्टि करने की सुविधा का इस्तेमाल करेंगे

2.4.3

जैसा कि लिखा गया स्टैंडर्ड उतना बड़ा नहीं है जितना उसे लागू किया जा सके

2.4.5

ASVS के V5 में बताई गई ज़रूरी शर्त और 2.4.1 के सुझाए गए हैशिंग एल्गोरिदम इस शर्त को पूरा नहीं कर सकते

2.7.5

टेस्ट करना मुमकिन नहीं है, क्योंकि इसके लिए तीसरे पक्ष की 'OB' कंपनियों के विश्लेषण की ज़रूरत पड़ सकती है. इसलिए, पुष्टि का कोड बहुत कम होने की वजह से, इस काम में जोखिम कम होता है.

2.8.2

यह ज़रूरत सिर्फ़ उन कस्टम MFA सलूशन के लिए है जो 6.4.2 और 6.4.1 वर्शन पर भी लागू होते हैं

2.8.5

2.7.6 से जुड़ी ज़रूरी शर्त को हटा दें, नहीं तो लॉगिन न हो पाने की कोशिशों को ASVS की लॉगिंग ज़रूरत के हिसाब से कवर किया जाता है

2.8.6

ऐप्लिकेशन लेवल पर इसे इस्तेमाल करना सामान्य बात नहीं है. एडमिन के इंटरफ़ेस के लिए यह अनुरोध ज़रूरी है. हालांकि, 4.3.1 वर्शन ज़रूरी है. पुष्टि करें कि एडमिन इंटरफ़ेस, बिना अनुमति के इस्तेमाल के लिए, मल्टी-फ़ैक्टर ऑथेंटिकेशन का इस्तेमाल करता है. इसमें एडमिन इंटरफ़ेस के लिए, एमएफ़ए इस्तेमाल किया जाता है और इस जोखिम को पूरा किया जाता है

2.9.1

एएसवीएस के हिसाब से, फ़िज़िकल डिवाइसों पर भी यह शर्त लागू होती है (क्रिप्टोग्राफ़िक ग्राफ़िक कुंजियां, स्मार्ट कार्ड या FIDO बटन होती हैं. इनमें, उपयोगकर्ता को डिवाइस को प्लग इन या किसी दूसरे डिवाइस से जोड़ना होता है)

पुष्टि करने के लिए कंप्यूटर पर क्रिप्टोग्राफ़िक डिवाइस भेजा जाएगा. पुष्टि करने वाले लोग इसमें कोई चुनौती नहीं भेजते हैं

क्रिप्टोग्राफ़िक डिवाइस या सॉफ़्टवेयर, और डिवाइस या सॉफ़्टवेयर सुरक्षित तरीके से जवाब देता है

सेव की गई क्रिप्टोग्राफ़िक कुंजी.) इस ज़रूरत को CASA के दायरे से बाहर रखते हुए, MFA (फ़िज़िकल या सॉफ़्टवेयर) के लिए, फ़िज़िकल डिवाइसों की पुष्टि करने से जुड़े जोखिम को 4.3.1 से कवर किया जाता है

2.9.3

एएसवीएस के हिसाब से, फ़िज़िकल डिवाइसों पर भी यह शर्त लागू होती है (क्रिप्टोग्राफ़िक ग्राफ़िक कुंजियां, स्मार्ट कार्ड या FIDO बटन होती हैं. इनमें, उपयोगकर्ता को डिवाइस को प्लग इन या किसी दूसरे डिवाइस से जोड़ना होता है)

पुष्टि करने के लिए कंप्यूटर पर क्रिप्टोग्राफ़िक डिवाइस भेजा जाएगा. पुष्टि करने वाले लोग इसमें कोई चुनौती नहीं भेजते हैं

क्रिप्टोग्राफ़िक डिवाइस या सॉफ़्टवेयर, और डिवाइस या सॉफ़्टवेयर सुरक्षित तरीके से जवाब देता है

सेव की गई क्रिप्टोग्राफ़िक कुंजी.) इस ज़रूरत को CASA के दायरे से बाहर रखते हुए, MFA (फ़िज़िकल या सॉफ़्टवेयर) के लिए, फ़िज़िकल डिवाइसों की पुष्टि करने से जुड़े जोखिम को 4.3.1 से कवर किया जाता है

2.10.1

ज़रूरी शर्त, 2.10.2 का कॉन्ट्राडिक्शन है

2.10.3

2.4.1 में शामिल (पुष्टि करें कि ऐप्लिकेशन के लिए उपयोगकर्ता का पासवर्ड सेव करते समय, यहां दी गई पासवर्ड हैशिंग सुविधाओं में से किसी एक का इस्तेमाल किया जाता है: argon2id, scrypt, bcrypt या PBKDF2). इन पर ऑफ़लाइन हमला होने और पासवर्ड सेव होने का जोखिम रहता है.

2.10.4

6.4.2 के ज़रिए कवर किया गया

3.2.3

3.4.1, 3.4.2 और 3.4.3 तक कवरेज

3.5.1

उपयोगकर्ता, OAuth देने वाले के ज़रिए टोकन निरस्त कर सकता है

4.3.3

एडमिन इंटरफ़ेस और खास अधिकारों वाले ऐक्सेस के लिए, Req को MFA से कवर किया जाता है

5.1.3

इस अनुरोध में, इनपुट की पुष्टि से जुड़ी दूसरी ज़रूरी शर्तें शामिल हैं. साथ ही, अगर पुष्टि करने की प्रोसेस पूरी न हो पाने की वजह से, कारोबार के लॉजिक के जोखिम की संभावना कम हो जाती है, तो इस कार्रवाई से गंभीरता कम हो सकती है. फ़ोन नंबर की सही तरीके से पुष्टि न होने की वजह से, जानकारी वाले पेज पर फ़ोन नंबर गलत तरीके से दिख सकता है, जिसका सीधा सुरक्षा से कोई मतलब नहीं है.

5.1.4

इस अनुरोध में, इनपुट की पुष्टि से जुड़ी दूसरी ज़रूरी शर्तें शामिल हैं. साथ ही, अगर पुष्टि करने की प्रोसेस पूरी न हो पाने की वजह से, कारोबार के लॉजिक के जोखिम की संभावना कम हो जाती है, तो इस कार्रवाई से गंभीरता कम हो सकती है. फ़ोन नंबर की सही तरीके से पुष्टि न होने की वजह से, जानकारी वाले पेज पर फ़ोन नंबर गलत तरीके से दिख सकता है, जिसका सीधा सुरक्षा से कोई मतलब नहीं है.

5.3.2

इस ज़रूरत के मुताबिक, हर यूनिकोड वर्ण के मान्य होने की जांच करना मुश्किल हो सकता है. हर ऐप्लिकेशन में ऐसा टेक्स्ट फ़ॉर्म शामिल नहीं किया जाना चाहिए जो हर यूनिकोड वर्ण को फ़िट करने के लिए ज़रूरी हो. पूरे यूनिकोड स्पेस के लिए, कुछ ऑपरेटिंग सिस्टम और हैकिंग टूल के लिए सहायता उपलब्ध नहीं है. इसकी वजह से, सर्वर इस पर काम करने के बावजूद पेज की जांच नहीं कर सकता. कुल मिलाकर, सुरक्षा से जुड़ी संदिग्ध वैल्यू. ऐप्लिकेशन को शुरुआत में बीटा वर्शन में शामिल किया गया था, लेकिन जांच में कुछ समस्याओं की वजह से इसे हटा दिया गया.

6.2.5

6.2.4 और 6.2.3 तक कवर

6.2.6

6.2.4 और 6.2.3 तक कवर

6.3.1

6.2.4 और 6.2.3 तक कवर

6.3.3

इसमें कोई भी अन्य संख्या जनरेट करने की ज़रूरी शर्तें शामिल होती हैं.

7.1.2

7.1.1 में शामिल है

7.1.3

7.1.1 में शामिल है

7.3.1

7.1.1 में शामिल है

7.3.3

7.1.1 में शामिल है

8.1.3

यह बताना मुश्किल है कि किस तरह के पैरामीटर का इस्तेमाल किया जा सकता है या किन चीज़ों को शामिल करने की ज़रूरत है. टेस्ट करने लायक मामला नहीं है. इसमें क्या ज़रूरी है? हम यह कैसे पता करेंगे कि कोई अपवाद मान्य है या नहीं? CASA का दायरा सही नहीं है

8.3.3

निजता नीति और सेवा की शर्तों से जुड़ी कोई ज़रूरी शर्त नहीं है. यह ऐप्लिकेशन की सुरक्षा के लिए ज़रूरी नहीं है. यह एक कानूनी और अनुपालन संबंधी समीक्षा है और यह CASA के दायरे से बाहर है

8.3.6

कंट्रोल, खास तौर पर सिस्टम के लिए होता है, जैसे कि Windows या Linux का वैरिएंट. हालांकि, ज़्यादातर मामलों में यह ऐप्लिकेशन कंट्रोल के बजाय, डिवाइस के हिसाब से होता है.

8.3.8

1.8.1, 1.8.2, और 1.1.4 तक कवर

9.2.5

8.3.5 और लॉग इन नीतियों के बारे में समीक्षा शामिल है.

10.1

इस पर आर्किटेक्चर समीक्षा की जानकारी है और यह सबसे सही तरीका है. इस सुविधा की जांच नहीं की जा सकती

10.2.3

इसे तय समय में पूरा नहीं किया जा सकता. किसी भी अजीब कोड का दस्तावेज़ दिया जाना चाहिए और उसकी समीक्षा की जानी चाहिए, लेकिन बैकडोर मौजूद नहीं हैं यह पक्का करने के लिए खास काम को सेट करने के लिए लाइन कोड गहराई से लाइन की गहराई से समीक्षा की जानी चाहिए. इससे यह गारंटी नहीं मिलती कि बैकडोर मौजूद नहीं हैं.

अच्छी तरह से डिज़ाइन किए गए नुकसान पहुंचाने वाले फ़ंक्शन की जांच करना मुश्किल होता है

10.2.4

जांच करने का कोई तरीका नहीं है. सही समय में ऐसा नहीं किया जा सकता. किसी भी अजीब कोड का दस्तावेज़ तैयार किया जाना चाहिए और उसकी समीक्षा की जानी चाहिए, फिर भी बैकडोर मौजूद नहीं हैं यह पक्का करने के लिए खास टास्क सेट करने के लिए लाइन कोड के मुताबिक गहराई से लाइन की जांच की जाएगी और यह गारंटी नहीं देता है कि बैकडोर मौजूद नहीं हैं.

अच्छी तरह से डिज़ाइन किए गए नुकसान पहुंचाने वाले फ़ंक्शन की जांच करना मुश्किल होता है

10.2.5

जांच करने का कोई तरीका नहीं है. सही समय में ऐसा नहीं किया जा सकता. किसी भी अजीब कोड का दस्तावेज़ तैयार किया जाना चाहिए और उसकी समीक्षा की जानी चाहिए, फिर भी बैकडोर मौजूद नहीं हैं यह पक्का करने के लिए खास टास्क सेट करने के लिए लाइन कोड के मुताबिक गहराई से लाइन की जांच की जाएगी और यह गारंटी नहीं देता है कि बैकडोर मौजूद नहीं हैं.

अच्छी तरह से डिज़ाइन किए गए नुकसान पहुंचाने वाले फ़ंक्शन की जांच करना मुश्किल होता है

13.1.1

यह 5.2.6 और 5.3.9 के दायरे में आता है

12.3.1

ASVS और CASA के चैप्टर 5 (पुष्टि करना, सैनिटाइज़ेशन, और कोड में बदलने की प्रोसेस) से जुड़ी अन्य मौजूदा ज़रूरी शर्तें, कवर किए गए पाथ ट्रैवर्सल के लिए तय की गई हैं

12.3.3

यह 5.2.6 और 5.3.9 के दायरे में आता है

12.3.6

10.3.2 12.4.1 और 12.4.2 में शामिल है

12.5.1

10.3.2 और 12.4.2 के दायरे में

12.5.2

10.3.2 12.4.1 और 12.4.2 में शामिल है

13.1.5

इस अनुरोध में, इनपुट की पुष्टि से जुड़ी दूसरी ज़रूरी शर्तें शामिल हैं. साथ ही, अगर पुष्टि करने की प्रोसेस पूरी न हो पाने की वजह से, कारोबार के लॉजिक के जोखिम की संभावना कम हो जाती है, तो इस कार्रवाई से गंभीरता कम हो सकती है. फ़ोन नंबर की सही तरीके से पुष्टि न होने की वजह से, जानकारी वाले पेज पर फ़ोन नंबर गलत तरीके से दिख सकता है, जिसका सीधा सुरक्षा से कोई मतलब नहीं है.

13.2.2

इस अनुरोध में, इनपुट की पुष्टि से जुड़ी दूसरी ज़रूरी शर्तें शामिल हैं. साथ ही, अगर पुष्टि करने की प्रोसेस पूरी न हो पाने की वजह से, कारोबार के लॉजिक के जोखिम की संभावना कम हो जाती है, तो इस कार्रवाई से गंभीरता कम हो सकती है. फ़ोन नंबर की सही तरीके से पुष्टि न होने की वजह से, जानकारी वाले पेज पर फ़ोन नंबर गलत तरीके से दिख सकता है, जिसका सीधा सुरक्षा से कोई मतलब नहीं है.

13.2.3

4.2.2 से कवर

13.2.5

इस अनुरोध में, इनपुट की पुष्टि से जुड़ी दूसरी ज़रूरी शर्तें शामिल हैं. साथ ही, अगर पुष्टि करने की प्रोसेस पूरी न हो पाने की वजह से, कारोबार के लॉजिक के जोखिम की संभावना कम हो जाती है, तो इस कार्रवाई से गंभीरता कम हो सकती है. फ़ोन नंबर की सही तरीके से पुष्टि न होने की वजह से, जानकारी वाले पेज पर फ़ोन नंबर गलत तरीके से दिख सकता है, जिसका सीधा सुरक्षा से कोई मतलब नहीं है.

13.3.1

इस अनुरोध में, इनपुट की पुष्टि से जुड़ी दूसरी ज़रूरी शर्तें शामिल हैं. साथ ही, अगर पुष्टि करने की प्रोसेस पूरी न हो पाने की वजह से, कारोबार के लॉजिक के जोखिम की संभावना कम हो जाती है, तो इस कार्रवाई से गंभीरता कम हो सकती है. फ़ोन नंबर की सही तरीके से पुष्टि न होने की वजह से, जानकारी वाले पेज पर फ़ोन नंबर गलत तरीके से दिख सकता है, जिसका सीधा सुरक्षा से कोई मतलब नहीं है.

14.4.1

5.3.1 तक कवर

14.4.2

इस अनुरोध में, इनपुट की पुष्टि से जुड़ी दूसरी ज़रूरी शर्तें शामिल हैं. साथ ही, अगर पुष्टि करने की प्रोसेस पूरी न हो पाने की वजह से, कारोबार के लॉजिक के जोखिम की संभावना कम हो जाती है, तो इस कार्रवाई से गंभीरता कम हो सकती है. फ़ोन नंबर की सही तरीके से पुष्टि न होने की वजह से, जानकारी वाले पेज पर फ़ोन नंबर गलत तरीके से दिख सकता है, जिसका सीधा सुरक्षा से कोई मतलब नहीं है.

14.4.3

5.2.7 और 5.3.3 तक कवर

14.4.5

6.2.1 और 9.2.1 तक कवर करने वाला कॉन्टेंट

14.4.7

12.4.1 तक कवर

14.5.3

14.5.2 तक कवर

2.1.5

2.1.1 में शामिल

2.1.6

2.1.1 में शामिल

2.2.3

यह डेटा, casa के लिए सही नहीं है, क्योंकि जोखिम से जुड़े अन्य एंटी-कंट्रोल कंट्रोल शामिल हैं

2.5.6

दूसरे पासवर्ड से सुरक्षित

3.1.1

जोखिम का कम जोखिम और एएसवीएस के अन्य कंट्रोल की मदद से

3.2.1

जोखिम का कम जोखिम और एएसवीएस के अन्य कंट्रोल की मदद से

3.4.4

जोखिम का कम जोखिम और एएसवीएस के अन्य कंट्रोल की मदद से

3.4.5

जोखिम का कम जोखिम और एएसवीएस के अन्य कंट्रोल की मदद से

4.2.1

13.1.4 तक कवर

5.2.8

इसमें, इनपुट की पुष्टि करने और सैनिटेशन की जांच करने वाले अन्य सिस्टम शामिल हैं

5.3.5

इसमें, इनपुट की पुष्टि करने और सैनिटेशन की जांच करने वाले अन्य सिस्टम शामिल हैं

7.4.1

लॉगिंग जांच के तहत कवर किया जाता है

8.2.3

8.1.1 से कवर

9.1.1

6.2.1 और 9.2.1 तक कवर करने वाला कॉन्टेंट

1.2.3

1.1.4, 1.8.4 और 1.8.2 कवर करती है

1.4.4

1.1.4, 1.8.4 और 1.8.2 कवर करती है

1.5.2

1.1.4, 1.8.4 और 1.8.2 कवर करती है

1.5.3

1.1.4, 1.8.4 और 1.8.2 कवर करती है

1.5.4

1.1.4, 1.8.4 और 1.8.2 कवर करती है

1.9.1

1.1.4, 1.8.4 और 1.8.2 कवर करती है

1.11.3

1.1.4, 1.8.4 और 1.8.2 कवर करती है

1.14.1

1.1.4, 1.8.4 और 1.8.2 कवर करती है

1.14.2

1.1.4, 1.8.4 और 1.8.2 कवर करती है

1.14.3

1.1.4, 1.8.4 और 1.8.2 कवर करती है

1.14.4

1.1.4, 1.8.4 और 1.8.2 कवर करती है

1.14.5

1.1.4, 1.8.4 और 1.8.2 कवर करती है

1.14.6

1.1.4, 1.8.4 और 1.8.2 कवर करती है

6.1.2

6.1.1 तक कवर

6.1.3

6.1.1 तक कवर

2.10.2

2.5.4 से कवर

2.2.1

11.1.4 कवरेज में

2.7.3

2.7.2 में शामिल

2.7.4

2.7.2 में शामिल

5.1.2

एंटी ऑटोमेशन कंट्रोल से कवर किया गया

6.2.2

स्वीकार किए गए क्रिप्टोग्राफ़िक एल्गोरिदम के बारे में नहीं बताया गया है

8.2.1

8.1.1 से कवर

9.1.2

9.2.1 में शामिल

9.1.3

9.2.1 में शामिल

5.5.1

1.8.2 में शामिल

14.2.1

1.14.6 में शामिल

3.3.4

यह स्टेटलेस AuthN/Z का इस्तेमाल करने वाले ऐप्लिकेशन के लिए सही नहीं है. एनसीसी ग्रुप के उस सुझाव को स्वीकार करें जिसे हटाना है. यह लेख 3.3.3 की जगह

req_id

जानकारी

1.1

ऐप्लिकेशन के ट्रस्ट बाउंडर, कॉम्पोनेंट, और अहम डेटा फ़्लो के डॉक्यूमेंटेशन और पुष्टि की वजह की पुष्टि करें.

1.8.1

पुष्टि करें कि सभी संवेदनशील जानकारी की पहचान की जाती है और उसे सुरक्षा के लेवल में बांटा जाता है

1.8.2

पुष्टि करें कि सुरक्षा के सभी लेवल से जुड़ी हुई हों. जैसे, एन्क्रिप्ट (सुरक्षित) करने की ज़रूरी शर्तें, सुरक्षा से जुड़ी ज़रूरी शर्तें, निजी डेटा का रखरखाव, और निजता से जुड़ी अन्य ज़रूरी शर्तें. साथ ही, सुरक्षा से जुड़ी ये ज़रूरी शर्तें

आर्किटेक्चर का इस्तेमाल.

2.1.1

पुष्टि करें कि उपयोगकर्ता सेट के पासवर्ड में कम से कम 12 वर्ण हों

2.5.4

पुष्टि करें कि शेयर किए गए या डिफ़ॉल्ट खाते मौजूद नहीं हैं (उदाहरण के लिए, "रूट",

या "sa".

4.2.1

पुष्टि करें कि संवेदनशील डेटा और एपीआई असुरक्षित डायरेक्ट ऑब्जेक्ट रेफ़रंस (आईडीओआर) हमलों से सुरक्षित हैं. ये रिकॉर्ड, रिकॉर्ड बनाने, पढ़ने, अपडेट करने, और किसी दूसरे का रिकॉर्ड अपडेट करने, सभी के रिकॉर्ड देखने या सभी रिकॉर्ड मिटाने के लिए होते हैं.

1.14.6

इस बात की पुष्टि करें कि यह ऐप्लिकेशन इस्तेमाल नहीं किया जा रहा है. यह असुरक्षित या असुरक्षित है

क्लाइंट-साइड टेक्नोलॉजी, जैसे कि NSAPI प्लग इन, Flash, Shockwave, ActiveX,

Silverlight, NACL या क्लाइंट-साइड Java ऐप्लेट.