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 Verify administrative interfaces use appropriate multi-factor authentication to

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

2.2.5

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

2.4.3

लिखे गए स्टैंडर्ड में, ज़रूरी जानकारी नहीं दी गई है. इसलिए, इसे लागू नहीं किया जा सकता

2.4.5

ASVS के V5 में इस ज़रूरी शर्त को हटा दिया गया है. साथ ही, 2.4.1 में सुझाए गए हैशिंग एल्गोरिदम, इस ज़रूरी शर्त को पूरा नहीं कर सकते

2.7.5

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

2.8.2

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

2.8.5

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

2.8.6

ऐप्लिकेशन लेवल पर फ़िज़िकल ओटीपी का इस्तेमाल आम तौर पर नहीं किया जाता. इसकी ज़रूरत एडमिन इंटरफ़ेस के लिए होती है. हालांकि, req 4.3.1 (Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.) covers MFA for admin interfaces and will cover this risk

2.9.1

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

क्रिप्टोग्राफ़िक डिवाइस को कंप्यूटर से कनेक्ट करें, ताकि पुष्टि की प्रक्रिया पूरी की जा सके. पुष्टि करने वाले लोग,

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

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

2.9.3

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

क्रिप्टोग्राफ़िक डिवाइस को कंप्यूटर से कनेक्ट करें, ताकि पुष्टि की प्रक्रिया पूरी की जा सके. पुष्टि करने वाले लोग,

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

क्रिप्टोग्राफ़िक कुंजी सेव की जाती है.) इस वजह से, यह ज़रूरी शर्त CASA के दायरे से बाहर है, क्योंकि फ़िज़िकल डिवाइसों से पुष्टि करने के जोखिम को एमएफ़ए (फ़िज़िकल या सॉफ़्टवेयर) के मकसद से 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

एडमिन इंटरफ़ेस और खास अधिकारों वाले ऐक्सेस के लिए, एमएफ़ए की सुविधा चालू है

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.1

आर्किटेक्चर की समीक्षा में शामिल है और इसे सबसे सही तरीका माना जाता है. ज़रूरी शर्त की जांच नहीं की जा सकती

10.2.3

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

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

10.2.4

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

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

10.2.5

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

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

13.1.1

5.2.6 और 5.3.9 के तहत कवर किया गया

12.3.1

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

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

यह कैज़ा के लिए काम का नहीं है, क्योंकि जोखिम को अन्य एंटी ऑटोमेशन कंट्रोल से कवर किया जाता है

2.5.6

पासवर्ड की सुरक्षा से जुड़ी किसी अन्य सुविधा के तहत आता हो

3.1.1

एक्सपोज़र का जोखिम कम है और ASVS के अन्य कंट्रोल के दायरे में आता है

3.2.1

एक्सपोज़र का जोखिम कम है और ASVS के अन्य कंट्रोल के दायरे में आता है

3.4.4

एक्सपोज़र का जोखिम कम है और ASVS के अन्य कंट्रोल के दायरे में आता है

3.4.5

एक्सपोज़र का जोखिम कम है और ASVS के अन्य कंट्रोल के दायरे में आता है

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

हालांकि, यह उन ऐप्लिकेशन के लिए सही नहीं है जो बिना किसी स्टेटस के पुष्टि करने और अनुमति देने की सुविधा का इस्तेमाल करते हैं. एनसीसी ग्रुप के सुझाव के मुताबिक, इसे हटा दें. यह 3.3.3 के तहत आना चाहिए

req_id

ब्यौरा

1.1.4

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

1.8.1

पुष्टि करें कि सभी संवेदनशील डेटा की पहचान की गई हो और उसे सुरक्षा के स्तरों के हिसाब से बांटा गया हो

1.8.2

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

आर्किटेक्चर में लागू किया गया है.

2.1.1

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

2.5.4

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

"admin" या "sa").

4.2.1

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

1.14.6

पुष्टि करें कि ऐप्लिकेशन में, काम न करने वाले, असुरक्षित या बंद किए गए

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

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