diff --git a/5.0/pa-IN/0x01-Frontispiece.md b/5.0/pa-IN/0x01-Frontispiece.md new file mode 100644 index 0000000000..13c32a4a15 --- /dev/null +++ b/5.0/pa-IN/0x01-Frontispiece.md @@ -0,0 +1,80 @@ + + + + +# Frontispiece +# ਸਿਰਲੇਖ ਪੰਨਾ + +## About the Standard +## ਮਿਆਰ ਬਾਰੇ + +The Application Security Verification Standard is a list of application security requirements that architects, developers, testers, security professionals, tool vendors, and consumers can use to define, build, test, and verify secure applications. + +ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਤਸਦੀਕ ਮਿਆਰ (Application Security Verification Standard) ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਹੈ ਜਿਸ ਨੂੰ ਆਰਕੀਟੈਕਟ, ਵਿਕਾਸਕਾਰ, ਟੈਸਟਰ, ਸੁਰੱਖਿਆ ਪੇਸ਼ੇਵਰ, ਟੂਲ ਵਿਕਰੇਤਾ, ਅਤੇ ਖਪਤਕਾਰ ਸੁਰੱਖਿਅਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ, ਬਣਾਉਣ, ਟੈਸਟ ਕਰਨ ਅਤੇ ਤਸਦੀਕ ਕਰਨ ਲਈ ਵਰਤ ਸਕਦੇ ਹਨ। + +## Copyright and License +## ਕਾਪੀਰਾਈਟ ਅਤੇ ਲਾਇਸੈਂਸ + +Version 5.0.0, May 2025 + +ਸੰਸਕਰਣ 5.0.0, ਮਈ 2025 + +![license](../images/license.png) + +Copyright © 2008-2025 The OWASP Foundation. + +ਕਾਪੀਰਾਈਟ © 2008-2025 OWASP ਫਾਊਂਡੇਸ਼ਨ। + +This document is released under the [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/). + +ਇਹ ਦਸਤਾਵੇਜ਼ [ਕਰੀਏਟਿਵ ਕਾਮਨਜ਼ ਐਟਰੀਬਿਊਸ਼ਨ-ਸ਼ੇਅਰਅਲਾਈਕ 4.0 ਅੰਤਰਰਾਸ਼ਟਰੀ ਲਾਇਸੈਂਸ](https://creativecommons.org/licenses/by-sa/4.0/) ਅਧੀਨ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਹੈ। + +For any reuse or distribution, you must clearly communicate the license terms of this work to others. + +ਕਿਸੇ ਵੀ ਮੁੜ-ਵਰਤੋਂ ਜਾਂ ਵੰਡ ਲਈ, ਤੁਹਾਨੂੰ ਇਸ ਕੰਮ ਦੀਆਂ ਲਾਇਸੈਂਸ ਸ਼ਰਤਾਂ ਨੂੰ ਦੂਜਿਆਂ ਨੂੰ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਦੱਸਣਾ ਲਾਜ਼ਮੀ ਹੈ। + +## Project Leads +## ਪ੍ਰੋਜੈਕਟ ਮੁਖੀ + +| | | +|---------------------- |----------------- | +| Elar Lang | Josh C Grossman | +| Jim Manico | Daniel Cuthbert | + +## Working Group +## ਕਾਰਜ ਸਮੂਹ + +| | | | | +|---------------- |------------------ |------------------- |----------------- | +| Tobias Ahnoff | Ralph Andalis | Ryan Armstrong | Gabriel Corona | +| Meghan Jacquot | Shanni Prutchi | Iman Sharafaldin | Eden Yardeni | + +## Other Major Contributors +## ਹੋਰ ਮੁੱਖ ਯੋਗਦਾਨੀ + +| | | +|-------------------|-------------------| +| Sjoerd Langkemper | Isaac Lewis | +| Mark Carney | Sandro Gauci | + +## Other Contributors and Reviewers +## ਹੋਰ ਯੋਗਦਾਨੀ ਅਤੇ ਸਮੀਖਿਅਕ + +We have included a list of the other contributors in Appendix E. + +ਅਸੀਂ ਹੋਰ ਯੋਗਦਾਨੀਆਂ ਦੀ ਸੂਚੀ ਅੰਤਿਕਾ E ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੀ ਹੈ। + +If a credit is missing from the 5.x credit list, please log a ticket at GitHub to be recognized in future 5.x updates. + +ਜੇਕਰ 5.x ਕ੍ਰੈਡਿਟ ਸੂਚੀ ਵਿੱਚੋਂ ਕੋਈ ਕ੍ਰੈਡਿਟ ਗੁੰਮ ਹੈ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ GitHub 'ਤੇ ਟਿਕਟ ਦਰਜ ਕਰੋ ਤਾਂ ਜੋ ਭਵਿੱਖ ਦੇ 5.x ਅੱਪਡੇਟਾਂ ਵਿੱਚ ਮਾਨਤਾ ਮਿਲ ਸਕੇ। + +The Application Security Verification Standard builds on the work of those involved in ASVS 1.0 (2008) through 4.0 (2019). Much of the structure and many of the verification items that remain in ASVS today were originally written by Andrew van der Stock, Mike Boberski, Jeff Williams, and Dave Wichers, among numerous other contributors. We would also like to acknowledge Jim Manico for his significant and long-standing contributions to ASVS, starting as a Lead Author from version 1.0 (2009) and serving as a Project Lead from ASVS 4.0 through to after the release of ASVS 5.0. Thank you to everyone who has contributed in the past. For a comprehensive list of earlier contributors, please consult each prior version. + +ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਤਸਦੀਕ ਮਿਆਰ ASVS 1.0 (2008) ਤੋਂ 4.0 (2019) ਤੱਕ ਸ਼ਾਮਲ ਲੋਕਾਂ ਦੇ ਕੰਮ 'ਤੇ ਬਣਿਆ ਹੈ। ਅੱਜ ASVS ਵਿੱਚ ਮੌਜੂਦ ਬਹੁਤ ਸਾਰੀ ਬਣਤਰ ਅਤੇ ਤਸਦੀਕ ਇਕਾਈਆਂ ਅਸਲ ਵਿੱਚ Andrew van der Stock, Mike Boberski, Jeff Williams, ਅਤੇ Dave Wichers ਦੁਆਰਾ ਲਿਖੀਆਂ ਗਈਆਂ ਸਨ, ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਯੋਗਦਾਨੀਆਂ ਸਮੇਤ। ਅਸੀਂ Jim Manico ਦਾ ਵੀ ਧੰਨਵਾਦ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਜਿਨ੍ਹਾਂ ਨੇ ASVS ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਅਤੇ ਲੰਮੇ ਸਮੇਂ ਤੋਂ ਯੋਗਦਾਨ ਪਾਇਆ ਹੈ — ਸੰਸਕਰਣ 1.0 (2009) ਤੋਂ ਮੁੱਖ ਲੇਖਕ (Lead Author) ਵਜੋਂ ਸ਼ੁਰੂਆਤ ਕਰਕੇ, ਅਤੇ ASVS 4.0 ਤੋਂ ਲੈ ਕੇ ASVS 5.0 ਦੀ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਤੱਕ ਪ੍ਰੋਜੈਕਟ ਲੀਡ (Project Lead) ਵਜੋਂ ਸੇਵਾ ਨਿਭਾ ਕੇ। ਅਤੀਤ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲੇ ਸਾਰਿਆਂ ਦਾ ਧੰਨਵਾਦ। ਪਹਿਲਾਂ ਦੇ ਯੋਗਦਾਨੀਆਂ ਦੀ ਵਿਆਪਕ ਸੂਚੀ ਲਈ, ਕਿਰਪਾ ਕਰਕੇ ਹਰੇਕ ਪਿਛਲੇ ਸੰਸਕਰਣ ਵੇਖੋ। + +## Panjabi Translation +## ਪੰਜਾਬੀ ਅਨੁਵਾਦ + +This bilingual translation is maintained by [GeeksikhSecurity](https://github.com/GeeksikhSecurity) as part of the OWASP community effort to make cybersecurity knowledge accessible to Panjabi speakers worldwide. + +ਇਹ ਦੋਭਾਸ਼ੀ ਅਨੁਵਾਦ [GeeksikhSecurity](https://github.com/GeeksikhSecurity) ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਦੁਨੀਆ ਭਰ ਦੇ ਪੰਜਾਬੀ ਬੋਲਣ ਵਾਲਿਆਂ ਲਈ ਸਾਈਬਰ ਸੁਰੱਖਿਆ ਗਿਆਨ ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਣ ਦੇ OWASP ਭਾਈਚਾਰਕ ਯਤਨ ਦਾ ਹਿੱਸਾ ਹੈ। diff --git a/5.0/pa-IN/0x02-Preface.md b/5.0/pa-IN/0x02-Preface.md new file mode 100644 index 0000000000..b0e3b0f318 --- /dev/null +++ b/5.0/pa-IN/0x02-Preface.md @@ -0,0 +1,59 @@ + + + + +# Preface +# ਮੁਖਬੰਧ + +Welcome to the Application Security Verification Standard (ASVS) Version 5.0. + +ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਤਸਦੀਕ ਮਿਆਰ (ASVS) ਸੰਸਕਰਣ 5.0 ਵਿੱਚ ਜੀ ਆਇਆਂ ਨੂੰ। + +## Introduction +## ਜਾਣ-ਪਛਾਣ + +Originally launched in 2008 through a global community collaboration, the ASVS defines a comprehensive set of security requirements for designing, developing, and testing modern web applications and services. + +2008 ਵਿੱਚ ਗਲੋਬਲ ਭਾਈਚਾਰਕ ਸਹਿਯੋਗ ਰਾਹੀਂ ਸ਼ੁਰੂ ਕੀਤਾ ਗਿਆ, ASVS ਆਧੁਨਿਕ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਦੇ ਡਿਜ਼ਾਈਨ, ਵਿਕਾਸ ਅਤੇ ਟੈਸਟਿੰਗ ਲਈ ਸੁਰੱਖਿਆ ਲੋੜਾਂ (Security Requirements) ਦਾ ਇੱਕ ਵਿਆਪਕ ਸੈੱਟ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। + +Following the release of ASVS 4.0 in 2019 and its minor update (v4.0.3) in 2021, Version 5.0 represents a significant milestone—modernized to reflect the latest advances in software security. + +ASVS 4.0 ਦੀ 2019 ਵਿੱਚ ਰਿਲੀਜ਼ ਅਤੇ ਇਸ ਦੇ ਛੋਟੇ ਅੱਪਡੇਟ (v4.0.3) 2021 ਵਿੱਚ ਤੋਂ ਬਾਅਦ, ਸੰਸਕਰਣ 5.0 ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਮੀਲ ਪੱਥਰ ਹੈ — ਸਾਫ਼ਟਵੇਅਰ ਸੁਰੱਖਿਆ ਵਿੱਚ ਨਵੀਨਤਮ ਤਰੱਕੀਆਂ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਆਧੁਨਿਕ ਕੀਤਾ ਗਿਆ ਹੈ। + +ASVS 5.0 is the result of extensive contributions from project leaders, working group members, and the wider OWASP community to update and improve this important standard. + +ASVS 5.0 ਪ੍ਰੋਜੈਕਟ ਮੁਖੀਆਂ, ਕਾਰਜ ਸਮੂਹ ਮੈਂਬਰਾਂ, ਅਤੇ ਵਿਸ਼ਾਲ OWASP ਭਾਈਚਾਰੇ ਦੇ ਵਿਆਪਕ ਯੋਗਦਾਨ ਦਾ ਨਤੀਜਾ ਹੈ ਜੋ ਇਸ ਮਹੱਤਵਪੂਰਨ ਮਿਆਰ ਨੂੰ ਅੱਪਡੇਟ ਅਤੇ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਕੀਤਾ ਗਿਆ ਹੈ। + +## Principles behind version 5.0 +## ਸੰਸਕਰਣ 5.0 ਦੇ ਪਿੱਛੇ ਦੇ ਸਿਧਾਂਤ + +This major revision has been developed with several key principles in mind: + +ਇਹ ਵੱਡਾ ਸੋਧ ਕਈ ਮੁੱਖ ਸਿਧਾਂਤਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ: + +* Refined Scope and Focus: This version of the standard has been designed to align more directly with the foundational pillars in its name: Application, Security, Verification, and Standard. Requirements have been rewritten to emphasize the prevention of security flaws rather than mandating specific technical implementations. Requirement texts are intended to be self-explanatory, explaining why they exist. + +* ਸੁਧਰਿਆ ਘੇਰਾ ਅਤੇ ਧਿਆਨ (Refined Scope and Focus): ਮਿਆਰ ਦੇ ਇਸ ਸੰਸਕਰਣ ਨੂੰ ਇਸ ਦੇ ਨਾਮ ਦੇ ਬੁਨਿਆਦੀ ਥੰਮ੍ਹਾਂ — ਐਪਲੀਕੇਸ਼ਨ (Application), ਸੁਰੱਖਿਆ (Security), ਤਸਦੀਕ (Verification), ਅਤੇ ਮਿਆਰ (Standard) — ਨਾਲ ਵਧੇਰੇ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਮੇਲ ਖਾਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਲੋੜਾਂ ਨੂੰ ਖ਼ਾਸ ਤਕਨੀਕੀ ਅਮਲ ਲਾਜ਼ਮੀ ਕਰਨ ਦੀ ਬਜਾਏ ਸੁਰੱਖਿਆ ਕਮੀਆਂ ਦੀ ਰੋਕਥਾਮ 'ਤੇ ਜ਼ੋਰ ਦੇਣ ਲਈ ਦੁਬਾਰਾ ਲਿਖੀਆਂ ਗਈਆਂ ਹਨ। ਲੋੜ ਦੇ ਪਾਠ ਸਵੈ-ਵਿਆਖਿਆਤਮਕ ਹੋਣ ਦੇ ਇਰਾਦੇ ਨਾਲ ਲਿਖੇ ਗਏ ਹਨ, ਜੋ ਦੱਸਦੇ ਹਨ ਕਿ ਉਹ ਕਿਉਂ ਮੌਜੂਦ ਹਨ। + +* Support for Documented Security Decisions: ASVS 5.0 introduces requirements for documenting key security decisions. This enhances traceability and supports context-sensitive implementations, allowing organizations to tailor their security posture to their specific needs and risks. + +* ਦਸਤਾਵੇਜ਼ੀ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਿਆਂ ਲਈ ਸਹਾਇਤਾ (Support for Documented Security Decisions): ASVS 5.0 ਮੁੱਖ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਿਆਂ ਦੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਲਈ ਲੋੜਾਂ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਇਹ ਟਰੇਸੇਬਿਲਟੀ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਸੰਦਰਭ-ਸੰਵੇਦਨਸ਼ੀਲ ਅਮਲਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸੰਸਥਾਵਾਂ ਆਪਣੀ ਸੁਰੱਖਿਆ ਸਥਿਤੀ ਨੂੰ ਆਪਣੀਆਂ ਖ਼ਾਸ ਲੋੜਾਂ ਅਤੇ ਖ਼ਤਰਿਆਂ ਅਨੁਸਾਰ ਢਾਲ ਸਕਦੀਆਂ ਹਨ। + +* Updated Levels: While ASVS retains its three-tier model, the level definitions have evolved to make the ASVS easier to adopt. Level 1 is designed as the initial step to adopting the ASVS, providing the first layer of defense. Level 2 represents a comprehensive view of standard security practices, and Level 3 addresses advanced, high-assurance requirements. + +* ਅੱਪਡੇਟ ਕੀਤੇ ਪੱਧਰ (Updated Levels): ਜਦੋਂ ਕਿ ASVS ਆਪਣਾ ਤਿੰਨ-ਪੱਧਰੀ ਮਾਡਲ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ, ਪੱਧਰ ਦੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ASVS ਨੂੰ ਅਪਣਾਉਣਾ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਵਿਕਸਿਤ ਹੋਈਆਂ ਹਨ। ਪੱਧਰ 1 (Level 1) ASVS ਅਪਣਾਉਣ ਦੇ ਸ਼ੁਰੂਆਤੀ ਕਦਮ ਵਜੋਂ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਸੁਰੱਖਿਆ ਦੀ ਪਹਿਲੀ ਪਰਤ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਪੱਧਰ 2 (Level 2) ਮਿਆਰੀ ਸੁਰੱਖਿਆ ਅਭਿਆਸਾਂ ਦੀ ਵਿਆਪਕ ਦ੍ਰਿਸ਼ਟੀ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਪੱਧਰ 3 (Level 3) ਉੱਨਤ, ਉੱਚ-ਭਰੋਸੇ ਵਾਲੀਆਂ ਲੋੜਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ। + +* Restructured and Expanded Content: ASVS 5.0 includes approximately 350 requirements across 17 chapters. Chapters have been reorganized for clarity and usability. A two-way mapping between v4.0 and v5.0 is provided to facilitate migration. + +* ਪੁਨਰਗਠਿਤ ਅਤੇ ਵਿਸਤਾਰਿਤ ਸਮੱਗਰੀ (Restructured and Expanded Content): ASVS 5.0 ਵਿੱਚ 17 ਅਧਿਆਵਾਂ ਵਿੱਚ ਲਗਭਗ 350 ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ। ਅਧਿਆਵਾਂ ਨੂੰ ਸਪੱਸ਼ਟਤਾ ਅਤੇ ਵਰਤੋਂਯੋਗਤਾ ਲਈ ਪੁਨਰਗਠਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਸਹੂਲਤ ਲਈ v4.0 ਅਤੇ v5.0 ਵਿਚਕਾਰ ਦੋ-ਤਰਫ਼ੀ ਮੈਪਿੰਗ ਪ੍ਰਦਾਨ ਕੀਤੀ ਗਈ ਹੈ। + +## Looking ahead +## ਅੱਗੇ ਵੇਖਦਿਆਂ + +Just as securing an application is never truly finished, neither is the ASVS. Although Version 5.0 is a major release, development continues. This release allows the wider community to benefit from the improvements and additions which have been accumulated but also lays the groundwork for future enhancements. This could include community-driven efforts to create implementation and verification guidance built on top of the core requirement set. + +ਜਿਵੇਂ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਕਦੇ ਸੱਚਮੁੱਚ ਮੁਕੰਮਲ ਨਹੀਂ ਹੁੰਦਾ, ਉਵੇਂ ASVS ਵੀ ਨਹੀਂ। ਹਾਲਾਂਕਿ ਸੰਸਕਰਣ 5.0 ਇੱਕ ਵੱਡੀ ਰਿਲੀਜ਼ ਹੈ, ਵਿਕਾਸ ਜਾਰੀ ਹੈ। ਇਹ ਰਿਲੀਜ਼ ਵਿਸ਼ਾਲ ਭਾਈਚਾਰੇ ਨੂੰ ਇਕੱਤਰ ਕੀਤੀਆਂ ਸੁਧਾਰਾਂ ਅਤੇ ਵਾਧਿਆਂ ਤੋਂ ਲਾਭ ਲੈਣ ਦਿੰਦੀ ਹੈ ਅਤੇ ਭਵਿੱਖ ਦੀਆਂ ਤਰੱਕੀਆਂ ਲਈ ਨੀਂਹ ਵੀ ਰੱਖਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਮੁੱਖ ਲੋੜ ਸੈੱਟ ਦੇ ਉੱਪਰ ਬਣਾਈ ਗਈ ਅਮਲ ਅਤੇ ਤਸਦੀਕ ਮਾਰਗਦਰਸ਼ਨ ਬਣਾਉਣ ਲਈ ਭਾਈਚਾਰਕ ਯਤਨ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ। + +ASVS 5.0 is designed to serve as a reliable foundation for secure software development. The community is invited to adopt, contribute, and build upon this standard to collectively advance the state of application security. + +ASVS 5.0 ਸੁਰੱਖਿਅਤ ਸਾਫ਼ਟਵੇਅਰ ਵਿਕਾਸ ਲਈ ਇੱਕ ਭਰੋਸੇਯੋਗ ਨੀਂਹ ਵਜੋਂ ਕੰਮ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਭਾਈਚਾਰੇ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸਮੂਹਿਕ ਤੌਰ 'ਤੇ ਅੱਗੇ ਵਧਾਉਣ ਲਈ ਇਸ ਮਿਆਰ ਨੂੰ ਅਪਣਾਉਣ, ਯੋਗਦਾਨ ਪਾਉਣ ਅਤੇ ਇਸ 'ਤੇ ਨਿਰਮਾਣ ਕਰਨ ਦਾ ਸੱਦਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। diff --git a/5.0/pa-IN/0x03-What-is-the-ASVS.md b/5.0/pa-IN/0x03-What-is-the-ASVS.md new file mode 100644 index 0000000000..3c45e5740a --- /dev/null +++ b/5.0/pa-IN/0x03-What-is-the-ASVS.md @@ -0,0 +1,364 @@ + + + + +# What is the ASVS? +# ASVS ਕੀ ਹੈ? + +The Application Security Verification Standard (ASVS) defines security requirements for web applications and services, and it is a valuable resource for anyone aiming to design, develop, and maintain secure applications or evaluate their security. + +ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਤਸਦੀਕ ਮਿਆਰ (Application Security Verification Standard, ASVS) ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਲਈ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਹਰ ਉਸ ਵਿਅਕਤੀ ਲਈ ਇੱਕ ਕੀਮਤੀ ਸਰੋਤ ਹੈ ਜੋ ਸੁਰੱਖਿਅਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ, ਵਿਕਸਿਤ ਕਰਨ ਅਤੇ ਬਣਾਈ ਰੱਖਣ, ਜਾਂ ਉਹਨਾਂ ਦੀ ਸੁਰੱਖਿਆ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਦਾ ਟੀਚਾ ਰੱਖਦਾ ਹੈ। + +This chapter outlines the essential aspects of using the ASVS, including its scope, the structure of its priority-based levels, and the primary use cases for the standard. + +ਇਹ ਅਧਿਆਇ ASVS ਦੀ ਵਰਤੋਂ ਦੇ ਜ਼ਰੂਰੀ ਪਹਿਲੂਆਂ ਦੀ ਰੂਪਰੇਖਾ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਸ ਦਾ ਘੇਰਾ (scope), ਇਸ ਦੇ ਤਰਜੀਹ-ਆਧਾਰਿਤ ਪੱਧਰਾਂ (levels) ਦੀ ਬਣਤਰ, ਅਤੇ ਮਿਆਰ ਦੇ ਮੁੱਖ ਵਰਤੋਂ ਦੇ ਮਾਮਲੇ ਸ਼ਾਮਲ ਹਨ। + +## Scope of the ASVS +## ASVS ਦਾ ਘੇਰਾ + +The scope of the ASVS is defined by its name: Application, Security, Verification, and Standard. It establishes which requirements are included or excluded, with the overarching goal of identifying the security principles that must be achieved. The scope also considers documentation requirements, which serve as the foundation for implementation requirements. + +ASVS ਦਾ ਘੇਰਾ ਇਸ ਦੇ ਨਾਂ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ: ਐਪਲੀਕੇਸ਼ਨ (Application), ਸੁਰੱਖਿਆ (Security), ਤਸਦੀਕ (Verification), ਅਤੇ ਮਿਆਰ (Standard)। ਇਹ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਲੋੜਾਂ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਜਾਂ ਬਾਹਰ ਰੱਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸ ਦਾ ਸਰਬ-ਵਿਆਪਕ ਟੀਚਾ ਉਹਨਾਂ ਸੁਰੱਖਿਆ ਸਿਧਾਂਤਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ ਹੈ ਜੋ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਘੇਰਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਲੋੜਾਂ (documentation requirements) ਨੂੰ ਵੀ ਵਿਚਾਰਦਾ ਹੈ, ਜੋ ਲਾਗੂਕਰਨ ਲੋੜਾਂ ਦੀ ਨੀਂਹ ਵਜੋਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। + +There is no such thing as scope for attackers. Therefore, ASVS requirements should be evaluated alongside guidance for other aspects of the application lifecycle, including CI/CD processes, hosting, and operational activities. + +ਹਮਲਾਵਰਾਂ ਲਈ ਘੇਰਾ ਵਰਗੀ ਕੋਈ ਚੀਜ਼ ਨਹੀਂ ਹੁੰਦੀ। ਇਸ ਲਈ, ASVS ਲੋੜਾਂ ਦਾ ਮੁਲਾਂਕਣ ਐਪਲੀਕੇਸ਼ਨ ਜੀਵਨ-ਚੱਕਰ ਦੇ ਹੋਰ ਪਹਿਲੂਆਂ ਲਈ ਮਾਰਗਦਰਸ਼ਨ ਦੇ ਨਾਲ-ਨਾਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ CI/CD ਪ੍ਰਕਿਰਿਆਵਾਂ, ਹੋਸਟਿੰਗ, ਅਤੇ ਸੰਚਾਲਨ ਸੰਬੰਧੀ ਗਤੀਵਿਧੀਆਂ ਸ਼ਾਮਲ ਹਨ। + +### Application +### ਐਪਲੀਕੇਸ਼ਨ + +ASVS defines an "application" as the software product being developed, into which security controls must be integrated. ASVS does not prescribe development lifecycle activities or dictate how the application should be built via a CI/CD pipeline; instead, it specifies the security outcomes that must be achieved within the product itself. + +ASVS ਇੱਕ "ਐਪਲੀਕੇਸ਼ਨ" ਨੂੰ ਉਸ ਸਾਫ਼ਟਵੇਅਰ ਉਤਪਾਦ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਵਿਕਸਿਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਜਿਸ ਵਿੱਚ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣਾਂ (security controls) ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਏਕੀਕ੍ਰਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ASVS ਵਿਕਾਸ ਜੀਵਨ-ਚੱਕਰ ਦੀਆਂ ਗਤੀਵਿਧੀਆਂ ਨੂੰ ਨਿਰਧਾਰਿਤ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਨਾ ਹੀ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ CI/CD ਪਾਈਪਲਾਈਨ ਰਾਹੀਂ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ; ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਉਹਨਾਂ ਸੁਰੱਖਿਆ ਨਤੀਜਿਆਂ ਨੂੰ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਜੋ ਉਤਪਾਦ ਦੇ ਅੰਦਰ ਹੀ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। + +Components that serve, modify, or validate HTTP traffic, such as Web Application Firewalls (WAFs), load balancers, or proxies, may be considered part of the application for those specific purposes, as some security controls depend directly on them or can be implemented through them. These components should be considered for requirements related to cached responses, rate limiting, or restricting incoming and outgoing connections based on source and destination. + +ਉਹ ਹਿੱਸੇ ਜੋ HTTP ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਪਰੋਸਦੇ, ਸੋਧਦੇ, ਜਾਂ ਪ੍ਰਮਾਣਿਤ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਫ਼ਾਇਰਵਾਲ (WAF), ਲੋਡ ਬੈਲੈਂਸਰ, ਜਾਂ ਪ੍ਰੌਕਸੀ, ਉਹਨਾਂ ਖ਼ਾਸ ਉਦੇਸ਼ਾਂ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਹਿੱਸਾ ਮੰਨੇ ਜਾ ਸਕਦੇ ਹਨ, ਕਿਉਂਕਿ ਕੁਝ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਸਿੱਧੇ ਉਹਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਜਾਂ ਉਹਨਾਂ ਰਾਹੀਂ ਲਾਗੂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਇਹਨਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਕੈਸ਼ ਕੀਤੇ ਜਵਾਬਾਂ, ਦਰ ਸੀਮਾ (rate limiting), ਜਾਂ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਦੇ ਆਧਾਰ 'ਤੇ ਅੰਦਰ-ਆਉਣ ਵਾਲੇ ਅਤੇ ਬਾਹਰ-ਜਾਣ ਵਾਲੇ ਸੰਪਰਕਾਂ ਨੂੰ ਪ੍ਰਤਿਬੰਧਿਤ ਕਰਨ ਨਾਲ ਸੰਬੰਧਿਤ ਲੋੜਾਂ ਲਈ ਵਿਚਾਰਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। + +Conversely, ASVS generally excludes requirements that are not directly relevant to the application or where configuration is outside the application's responsibility. For example, DNS issues are typically managed by a separate team or function. + +ਇਸ ਦੇ ਉਲਟ, ASVS ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਲੋੜਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖਦਾ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸੰਬੰਧਿਤ ਨਹੀਂ ਹਨ ਜਾਂ ਜਿੱਥੇ ਸੰਰਚਨਾ (configuration) ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਤੋਂ ਬਾਹਰ ਹੈ। ਉਦਾਹਰਨ ਲਈ, DNS ਮੁੱਦਿਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਵੱਖਰੀ ਟੀਮ ਜਾਂ ਕਾਰਜ-ਇਕਾਈ ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। + +Similarly, while the application is responsible for how it consumes input and produces output, if an external process interacts with the application or its data, it is considered out of scope for ASVS. For instance, backing up the application or its data is usually the responsibility of an external process and is not controlled by the application or its developers. + +ਇਸੇ ਤਰ੍ਹਾਂ, ਭਾਵੇਂ ਐਪਲੀਕੇਸ਼ਨ ਇਸ ਗੱਲ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ ਕਿ ਉਹ ਇਨਪੁੱਟ ਨੂੰ ਕਿਵੇਂ ਖਪਤ ਕਰਦੀ ਹੈ ਅਤੇ ਆਊਟਪੁੱਟ ਕਿਵੇਂ ਪੈਦਾ ਕਰਦੀ ਹੈ, ਜੇਕਰ ਕੋਈ ਬਾਹਰੀ ਪ੍ਰਕਿਰਿਆ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਇਸ ਦੇ ਡਾਟੇ ਨਾਲ ਆਪਸੀ ਤਾਲਮੇਲ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਸ ਨੂੰ ASVS ਦੇ ਘੇਰੇ ਤੋਂ ਬਾਹਰ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਮਿਸਾਲ ਵਜੋਂ, ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਇਸ ਦੇ ਡਾਟੇ ਦਾ ਬੈਕਅੱਪ ਲੈਣਾ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਬਾਹਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਇਸ ਦੇ ਵਿਕਾਸਕਾਰਾਂ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਹੁੰਦੀ। + +### Security +### ਸੁਰੱਖਿਆ + +Every requirement must have a demonstrable impact on security. The absence of a requirement must result in a less secure application, and implementing the requirement must reduce either the likelihood or the impact of a security risk. + +ਹਰ ਲੋੜ ਦਾ ਸੁਰੱਖਿਆ 'ਤੇ ਇੱਕ ਪ੍ਰਦਰਸ਼ਨਯੋਗ ਪ੍ਰਭਾਵ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਕਿਸੇ ਲੋੜ ਦੀ ਗ਼ੈਰ-ਮੌਜੂਦਗੀ ਦਾ ਨਤੀਜਾ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਇੱਕ ਘੱਟ ਸੁਰੱਖਿਅਤ ਐਪਲੀਕੇਸ਼ਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਲੋੜ ਨੂੰ ਲਾਗੂ ਕਰਨ ਨਾਲ ਕਿਸੇ ਸੁਰੱਖਿਆ ਜੋਖਮ (risk) ਦੀ ਸੰਭਾਵਨਾ ਜਾਂ ਉਸ ਦੇ ਪ੍ਰਭਾਵ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਦਾ ਘਟਣਾ ਲਾਜ਼ਮੀ ਹੈ। + +All other considerations, such as functional aspects, code style, or policy requirements, are out of scope. + +ਹੋਰ ਸਾਰੇ ਵਿਚਾਰ, ਜਿਵੇਂ ਕਿ ਕਾਰਜਾਤਮਕ ਪਹਿਲੂ, ਕੋਡ ਸ਼ੈਲੀ, ਜਾਂ ਨੀਤੀ ਸੰਬੰਧੀ ਲੋੜਾਂ, ਘੇਰੇ ਤੋਂ ਬਾਹਰ ਹਨ। + +### Verification +### ਤਸਦੀਕ + +The requirement must be verifiable, and the verification must result in a "fail" or "pass" decision. + +ਲੋੜ ਤਸਦੀਕਯੋਗ ਹੋਣੀ ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ ਤਸਦੀਕ ਦਾ ਨਤੀਜਾ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਇੱਕ "ਅਸਫਲ" (fail) ਜਾਂ "ਸਫਲ" (pass) ਫ਼ੈਸਲਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। + +### Standard +### ਮਿਆਰ + +The ASVS is designed to be a collection of security requirements to be implemented to comply with the standard. This means that requirements are limited to defining the security goal to achieve that. Other related information can be built on top of ASVS or linked via mappings. + +ASVS ਨੂੰ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਦੇ ਇੱਕ ਸੰਗ੍ਰਹਿ ਵਜੋਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮਿਆਰ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਹੈ। ਇਸ ਦਾ ਅਰਥ ਹੈ ਕਿ ਲੋੜਾਂ ਉਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸੁਰੱਖਿਆ ਟੀਚੇ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਤੱਕ ਸੀਮਤ ਹਨ। ਹੋਰ ਸੰਬੰਧਿਤ ਜਾਣਕਾਰੀ ASVS ਦੇ ਉੱਪਰ ਬਣਾਈ ਜਾ ਸਕਦੀ ਹੈ ਜਾਂ ਮੈਪਿੰਗ ਰਾਹੀਂ ਜੋੜੀ ਜਾ ਸਕਦੀ ਹੈ। + +Specifically, OWASP has many projects, and the ASVS deliberately avoids overlapping with the content in other projects. For example, developers may have a question, "how do I implement a particular requirement in my particular technology or environment," and this should be covered by the Cheat Sheet Series project. Verifiers may have a question "how do I test this requirement in this environment," and this should be covered by the Web Security Testing Guide project. + +ਖ਼ਾਸ ਤੌਰ 'ਤੇ, OWASP ਦੇ ਕਈ ਪ੍ਰੋਜੈਕਟ ਹਨ, ਅਤੇ ASVS ਜਾਣ-ਬੁੱਝ ਕੇ ਹੋਰ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਸਮੱਗਰੀ ਨਾਲ ਓਵਰਲੈਪ ਹੋਣ ਤੋਂ ਬਚਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਵਿਕਾਸਕਾਰਾਂ ਦਾ ਇੱਕ ਸਵਾਲ ਹੋ ਸਕਦਾ ਹੈ, "ਮੈਂ ਆਪਣੀ ਖ਼ਾਸ ਤਕਨਾਲੋਜੀ ਜਾਂ ਵਾਤਾਵਰਣ ਵਿੱਚ ਇੱਕ ਖ਼ਾਸ ਲੋੜ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਾਂ," ਅਤੇ ਇਸ ਨੂੰ Cheat Sheet Series ਪ੍ਰੋਜੈਕਟ ਦੁਆਰਾ ਕਵਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਤਸਦੀਕਕਰਤਾਵਾਂ ਦਾ ਇੱਕ ਸਵਾਲ ਹੋ ਸਕਦਾ ਹੈ "ਮੈਂ ਇਸ ਵਾਤਾਵਰਣ ਵਿੱਚ ਇਸ ਲੋੜ ਨੂੰ ਕਿਵੇਂ ਟੈਸਟ ਕਰਾਂ," ਅਤੇ ਇਸ ਨੂੰ Web Security Testing Guide ਪ੍ਰੋਜੈਕਟ ਦੁਆਰਾ ਕਵਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। + +Whilst the ASVS is not just intended for security experts to use, it does expect the reader to have technical knowledge to understand the content or the ability to research particular concepts. + +ਭਾਵੇਂ ASVS ਸਿਰਫ਼ ਸੁਰੱਖਿਆ ਮਾਹਰਾਂ ਦੀ ਵਰਤੋਂ ਲਈ ਹੀ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ, ਇਹ ਪਾਠਕ ਤੋਂ ਸਮੱਗਰੀ ਨੂੰ ਸਮਝਣ ਲਈ ਤਕਨੀਕੀ ਗਿਆਨ ਜਾਂ ਖ਼ਾਸ ਸੰਕਲਪਾਂ ਦੀ ਖੋਜ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੀ ਉਮੀਦ ਜ਼ਰੂਰ ਰੱਖਦਾ ਹੈ। + +### Requirement +### ਲੋੜ + +The word requirement is used specifically in the ASVS as it describes what must be achieved to satisfy it. The ASVS only contains requirements (must) and does not contain recommendations (should) as the main condition. + +ASVS ਵਿੱਚ "ਲੋੜ" (requirement) ਸ਼ਬਦ ਦੀ ਵਰਤੋਂ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਵਰਣਨ ਕਰਦਾ ਹੈ ਕਿ ਉਸ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਕੀ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ASVS ਵਿੱਚ ਮੁੱਖ ਸ਼ਰਤ ਵਜੋਂ ਸਿਰਫ਼ ਲੋੜਾਂ (ਲਾਜ਼ਮੀ, must) ਹੀ ਸ਼ਾਮਲ ਹਨ ਅਤੇ ਸਿਫ਼ਾਰਸ਼ਾਂ (ਚਾਹੀਦਾ, should) ਸ਼ਾਮਲ ਨਹੀਂ ਹਨ। + +In other words, recommendations, whether they are just one of many possible options to solve a problem or code style considerations, do not satisfy the definition to be a requirement. + +ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਸਿਫ਼ਾਰਸ਼ਾਂ, ਭਾਵੇਂ ਉਹ ਕਿਸੇ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਕਈ ਸੰਭਵ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੋਣ ਜਾਂ ਕੋਡ ਸ਼ੈਲੀ ਸੰਬੰਧੀ ਵਿਚਾਰ ਹੋਣ, ਲੋੜ ਹੋਣ ਦੀ ਪਰਿਭਾਸ਼ਾ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰਦੀਆਂ। + +ASVS requirements are intended to address specific security principles without being too implementation or technology-specific, at the same time, being self-explanatory as to why they exist. This also means that requirements are not built around a particular verification method or implementation. + +ASVS ਲੋੜਾਂ ਦਾ ਉਦੇਸ਼ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲਾਗੂਕਰਨ- ਜਾਂ ਤਕਨਾਲੋਜੀ-ਵਿਸ਼ੇਸ਼ ਹੋਏ ਬਿਨਾਂ ਖ਼ਾਸ ਸੁਰੱਖਿਆ ਸਿਧਾਂਤਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਨਾ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ ਇਸ ਬਾਰੇ ਸਵੈ-ਵਿਆਖਿਆਤਮਕ ਹੋਣਾ ਹੈ ਕਿ ਉਹ ਕਿਉਂ ਮੌਜੂਦ ਹਨ। ਇਸ ਦਾ ਇਹ ਅਰਥ ਵੀ ਹੈ ਕਿ ਲੋੜਾਂ ਕਿਸੇ ਖ਼ਾਸ ਤਸਦੀਕ ਵਿਧੀ ਜਾਂ ਲਾਗੂਕਰਨ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਨਹੀਂ ਬਣਾਈਆਂ ਗਈਆਂ। + +### Documented security decisions +### ਦਸਤਾਵੇਜ਼ੀ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲੇ + +In software security, planning security design and the mechanisms to be used early on will lead to a more consistent and reliable implementation in the finished product or feature. + +ਸਾਫ਼ਟਵੇਅਰ ਸੁਰੱਖਿਆ ਵਿੱਚ, ਸੁਰੱਖਿਆ ਡਿਜ਼ਾਈਨ ਅਤੇ ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਯੋਜਨਾ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਬਣਾਉਣ ਨਾਲ ਤਿਆਰ ਉਤਪਾਦ ਜਾਂ ਫ਼ੀਚਰ ਵਿੱਚ ਵਧੇਰੇ ਇਕਸਾਰ ਅਤੇ ਭਰੋਸੇਯੋਗ ਲਾਗੂਕਰਨ ਹੋਵੇਗਾ। + +Additionally, for certain requirements, implementation will be complicated and very specific to an application's needs. Common examples include permissions, input validation, and protective controls around different levels of sensitive data. + +ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੁਝ ਲੋੜਾਂ ਲਈ, ਲਾਗੂਕਰਨ ਗੁੰਝਲਦਾਰ ਅਤੇ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਲੋੜਾਂ ਲਈ ਬਹੁਤ ਖ਼ਾਸ ਹੋਵੇਗਾ। ਆਮ ਉਦਾਹਰਨਾਂ ਵਿੱਚ ਇਜਾਜ਼ਤਾਂ, ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ (input validation), ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਦੇ ਵੱਖ-ਵੱਖ ਪੱਧਰਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸੁਰੱਖਿਆਤਮਕ ਨਿਯੰਤਰਣ ਸ਼ਾਮਲ ਹਨ। + +To account for this, rather than sweeping statements like "all data must be encrypted" or trying to cover every possible use case in a requirement, documentation requirements were included which mandate that the application developer's approach and configuration to these sorts of controls must be documented. This can then be reviewed for appropriateness and then the actual implementation can be compared to the documentation to assess whether the implementation matches expectations. + +ਇਸ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਲਈ, "ਸਾਰਾ ਡਾਟਾ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਏਨਕ੍ਰਿਪਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ" ਵਰਗੇ ਵਿਆਪਕ ਕਥਨਾਂ ਜਾਂ ਇੱਕ ਲੋੜ ਵਿੱਚ ਹਰ ਸੰਭਵ ਵਰਤੋਂ ਦੇ ਮਾਮਲੇ ਨੂੰ ਕਵਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ, ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਲੋੜਾਂ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਗਈਆਂ ਜੋ ਇਹ ਲਾਜ਼ਮੀ ਕਰਦੀਆਂ ਹਨ ਕਿ ਇਸ ਕਿਸਮ ਦੇ ਨਿਯੰਤਰਣਾਂ ਪ੍ਰਤੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿਕਾਸਕਾਰ ਦੀ ਪਹੁੰਚ ਅਤੇ ਸੰਰਚਨਾ ਨੂੰ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਦਿੱਤਾ ਜਾਵੇ। ਫਿਰ ਇਸ ਦੀ ਢੁਕਵੇਂਪਣ ਲਈ ਸਮੀਖਿਆ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਅਤੇ ਫਿਰ ਅਸਲ ਲਾਗੂਕਰਨ ਦੀ ਦਸਤਾਵੇਜ਼ ਨਾਲ ਤੁਲਨਾ ਕਰਕੇ ਇਹ ਮੁਲਾਂਕਣ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਲਾਗੂਕਰਨ ਉਮੀਦਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। + +These requirements are intended to document the decisions which the organization developing the application has taken regarding how to implement certain security requirements. + +ਇਹਨਾਂ ਲੋੜਾਂ ਦਾ ਉਦੇਸ਼ ਉਹਨਾਂ ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਦੇਣਾ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਵਿਕਸਿਤ ਕਰਨ ਵਾਲੀ ਸੰਸਥਾ ਨੇ ਕੁਝ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ, ਇਸ ਬਾਰੇ ਲਏ ਹਨ। + +Documentation requirements are always in the first section of a chapter (although not every chapter has them) and always have a related implementation requirement where the decisions that are documented should actually be put into place. The point here is that verifying that the documentation is in place and that the actual implementation are two separate activities. + +ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਲੋੜਾਂ ਹਮੇਸ਼ਾ ਕਿਸੇ ਅਧਿਆਇ ਦੇ ਪਹਿਲੇ ਭਾਗ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ (ਹਾਲਾਂਕਿ ਹਰ ਅਧਿਆਇ ਵਿੱਚ ਇਹ ਨਹੀਂ ਹੁੰਦੀਆਂ) ਅਤੇ ਇਹਨਾਂ ਦੀ ਹਮੇਸ਼ਾ ਇੱਕ ਸੰਬੰਧਿਤ ਲਾਗੂਕਰਨ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਦਿੱਤੇ ਗਏ ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਅਸਲ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਥੇ ਨੁਕਤਾ ਇਹ ਹੈ ਕਿ ਇਹ ਤਸਦੀਕ ਕਰਨਾ ਕਿ ਦਸਤਾਵੇਜ਼ ਮੌਜੂਦ ਹੈ ਅਤੇ ਅਸਲ ਲਾਗੂਕਰਨ ਦੀ ਤਸਦੀਕ ਕਰਨਾ, ਦੋ ਵੱਖਰੀਆਂ ਗਤੀਵਿਧੀਆਂ ਹਨ। + +There are two key drivers for including these requirements. The first driver is that a security requirement will often involve enforcing rules e.g., what kind of file types are allowed to be uploaded, what business controls should be enforced, what are the allowed characters for a particular field. These rules will differ for every application, and therefore, the ASVS cannot prescriptively define what they should be, nor will a cheat sheet or more detailed response help in this case. Similarly, without these decisions being documented, it will not be possible to perform verification of the requirements that implement these decisions. + +ਇਹਨਾਂ ਲੋੜਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦੇ ਦੋ ਮੁੱਖ ਕਾਰਨ ਹਨ। ਪਹਿਲਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਇੱਕ ਸੁਰੱਖਿਆ ਲੋੜ ਵਿੱਚ ਅਕਸਰ ਨਿਯਮ ਲਾਗੂ ਕਰਨਾ ਸ਼ਾਮਲ ਹੋਵੇਗਾ, ਜਿਵੇਂ ਕਿ ਕਿਸ ਕਿਸਮ ਦੀਆਂ ਫ਼ਾਈਲ ਕਿਸਮਾਂ ਨੂੰ ਅੱਪਲੋਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਕਿਹੜੇ ਕਾਰੋਬਾਰੀ ਨਿਯੰਤਰਣ ਲਾਗੂ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ, ਕਿਸੇ ਖ਼ਾਸ ਫ਼ੀਲਡ (field) ਲਈ ਇਜਾਜ਼ਤ ਪ੍ਰਾਪਤ ਅੱਖਰ ਕਿਹੜੇ ਹਨ। ਇਹ ਨਿਯਮ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਵੱਖਰੇ ਹੋਣਗੇ, ਅਤੇ ਇਸ ਲਈ, ASVS ਨਿਰਦੇਸ਼ਾਤਮਕ ਤੌਰ 'ਤੇ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਉਹ ਕੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਨਾ ਹੀ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਕੋਈ ਚੀਟ ਸ਼ੀਟ ਜਾਂ ਵਧੇਰੇ ਵਿਸਤ੍ਰਿਤ ਜਵਾਬ ਮਦਦ ਕਰੇਗਾ। ਇਸੇ ਤਰ੍ਹਾਂ, ਇਹਨਾਂ ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਦਿੱਤੇ ਬਿਨਾਂ, ਇਹਨਾਂ ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਾਲੀਆਂ ਲੋੜਾਂ ਦੀ ਤਸਦੀਕ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਹੋਵੇਗਾ। + +The second driver is that for certain requirements, it is important to provide an application development with flexibility regarding how to address particular security challenges. For example, in previous ASVS versions, session timeout rules were very prescriptive. Practically speaking, many applications, especially those that are consumer-facing, have much more relaxed rules and prefer to implement other mitigation controls instead. Documentation requirements, therefore, explicitly allow for flexibility around this. + +ਦੂਜਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਕੁਝ ਲੋੜਾਂ ਲਈ, ਐਪਲੀਕੇਸ਼ਨ ਵਿਕਾਸ ਨੂੰ ਇਸ ਬਾਰੇ ਲਚਕ ਪ੍ਰਦਾਨ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਖ਼ਾਸ ਸੁਰੱਖਿਆ ਚੁਣੌਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਸੰਬੋਧਿਤ ਕਰਨਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਪਿਛਲੇ ASVS ਸੰਸਕਰਣਾਂ ਵਿੱਚ, ਸੈਸ਼ਨ ਸਮਾਂ-ਸੀਮਾ ਦੇ ਨਿਯਮ ਬਹੁਤ ਨਿਰਦੇਸ਼ਾਤਮਕ ਸਨ। ਵਿਹਾਰਕ ਤੌਰ 'ਤੇ, ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ, ਖ਼ਾਸ ਕਰਕੇ ਉਹ ਜੋ ਖਪਤਕਾਰ-ਮੁਖੀ ਹਨ, ਦੇ ਨਿਯਮ ਕਿਤੇ ਵਧੇਰੇ ਢਿੱਲੇ ਹਨ ਅਤੇ ਉਹ ਇਸ ਦੀ ਬਜਾਏ ਹੋਰ ਘਟਾਉ ਨਿਯੰਤਰਣ ਲਾਗੂ ਕਰਨ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਹਨ। ਇਸ ਲਈ, ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਲੋੜਾਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਲਚਕ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ। + +Clearly, it is not expected that individual developers will be making and documenting these decisions but rather the organization as a whole will be taking those decisions and making sure that they are communicated to developers who then make sure to follow them. + +ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਇਹ ਉਮੀਦ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ ਕਿ ਵਿਅਕਤੀਗਤ ਵਿਕਾਸਕਾਰ ਇਹ ਫ਼ੈਸਲੇ ਲੈਣਗੇ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਦੇਣਗੇ, ਸਗੋਂ ਸੰਸਥਾ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਉਹ ਫ਼ੈਸਲੇ ਲਵੇਗੀ ਅਤੇ ਯਕੀਨੀ ਬਣਾਏਗੀ ਕਿ ਉਹ ਵਿਕਾਸਕਾਰਾਂ ਤੱਕ ਪਹੁੰਚਾਏ ਜਾਣ, ਜੋ ਫਿਰ ਉਹਨਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨਾ ਯਕੀਨੀ ਬਣਾਉਣਗੇ। + +Providing developers with specifications and designs for new features and functionality is a standard part of software development. Similarly, developers are expected to use common components and user interface mechanisms rather than just making their own decisions each time. As such, extending this to security should not be seen as surprising or controversial. + +ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਨਵੇਂ ਫ਼ੀਚਰਾਂ ਅਤੇ ਕਾਰਜਸ਼ੀਲਤਾ ਲਈ ਨਿਰਧਾਰਨ (specifications) ਅਤੇ ਡਿਜ਼ਾਈਨ ਪ੍ਰਦਾਨ ਕਰਨਾ ਸਾਫ਼ਟਵੇਅਰ ਵਿਕਾਸ ਦਾ ਇੱਕ ਮਿਆਰੀ ਹਿੱਸਾ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਵਿਕਾਸਕਾਰਾਂ ਤੋਂ ਹਰ ਵਾਰ ਸਿਰਫ਼ ਆਪਣੇ ਫ਼ੈਸਲੇ ਆਪ ਲੈਣ ਦੀ ਬਜਾਏ ਸਾਂਝੇ ਹਿੱਸਿਆਂ ਅਤੇ ਉਪਭੋਗਤਾ ਇੰਟਰਫ਼ੇਸ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਲਈ, ਇਸ ਨੂੰ ਸੁਰੱਖਿਆ ਤੱਕ ਵਧਾਉਣ ਨੂੰ ਹੈਰਾਨੀਜਨਕ ਜਾਂ ਵਿਵਾਦਪੂਰਨ ਨਹੀਂ ਸਮਝਿਆ ਜਾਣਾ ਚਾਹੀਦਾ। + +There is also flexibility around how to achieve this. Security decisions might be documented in a literal document, which developers are expected to refer to. Alternatively, security decisions could be documented and implemented in a common code library that all developers are mandated to use. In both cases, the desired result is achieved. + +ਇਸ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ, ਇਸ ਬਾਰੇ ਵੀ ਲਚਕ ਹੈ। ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਇੱਕ ਅਸਲ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਦਰਜ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਦਾ ਹਵਾਲਾ ਲੈਣ ਦੀ ਵਿਕਾਸਕਾਰਾਂ ਤੋਂ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਬਦਲ ਵਜੋਂ, ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਕੋਡ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਦਿੱਤਾ ਅਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਿਸ ਦੀ ਵਰਤੋਂ ਸਾਰੇ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਲਾਜ਼ਮੀ ਹੋਵੇ। ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਲੋੜੀਂਦਾ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਹੋ ਜਾਂਦਾ ਹੈ। + +## Application Security Verification Levels +## ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਤਸਦੀਕ ਪੱਧਰ + +The ASVS defines three security verification levels, with each level increasing in depth and complexity. The general aim is for organizations to start with the first level to address the most critical security concerns, and then move up to the higher levels according to the organization and application needs. Levels may be presented as L1, L2, and L3 in the document and in requirement texts. + +ASVS ਤਿੰਨ ਸੁਰੱਖਿਆ ਤਸਦੀਕ ਪੱਧਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਪੱਧਰ ਡੂੰਘਾਈ ਅਤੇ ਗੁੰਝਲਤਾ ਵਿੱਚ ਵਧਦਾ ਜਾਂਦਾ ਹੈ। ਆਮ ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ ਸੰਸਥਾਵਾਂ ਸਭ ਤੋਂ ਨਾਜ਼ੁਕ ਸੁਰੱਖਿਆ ਚਿੰਤਾਵਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਨ ਲਈ ਪਹਿਲੇ ਪੱਧਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ, ਅਤੇ ਫਿਰ ਸੰਸਥਾ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਲੋੜਾਂ ਅਨੁਸਾਰ ਉੱਚੇ ਪੱਧਰਾਂ ਵੱਲ ਵਧਣ। ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਅਤੇ ਲੋੜਾਂ ਦੇ ਪਾਠ ਵਿੱਚ ਪੱਧਰਾਂ ਨੂੰ L1, L2, ਅਤੇ L3 ਵਜੋਂ ਪੇਸ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। + +Each ASVS level indicates the security requirements that are required to achieve from that level, with the higher remaining level requirements as recommendations. + +ਹਰ ASVS ਪੱਧਰ ਉਹਨਾਂ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਸ ਪੱਧਰ ਤੋਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ, ਜਦੋਂ ਕਿ ਬਾਕੀ ਰਹਿੰਦੇ ਉੱਚੇ ਪੱਧਰਾਂ ਦੀਆਂ ਲੋੜਾਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਵਜੋਂ ਹੁੰਦੀਆਂ ਹਨ। + +In order to avoid duplicate requirements or requirements that are no longer relevant at higher levels, some requirements apply to a particular level but have more stringent conditions for higher levels. + +ਦੁਹਰਾਈਆਂ ਗਈਆਂ ਲੋੜਾਂ ਜਾਂ ਉਹਨਾਂ ਲੋੜਾਂ ਤੋਂ ਬਚਣ ਲਈ ਜੋ ਉੱਚੇ ਪੱਧਰਾਂ 'ਤੇ ਹੁਣ ਸੰਬੰਧਿਤ ਨਹੀਂ ਰਹਿੰਦੀਆਂ, ਕੁਝ ਲੋੜਾਂ ਇੱਕ ਖ਼ਾਸ ਪੱਧਰ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ ਪਰ ਉੱਚੇ ਪੱਧਰਾਂ ਲਈ ਵਧੇਰੇ ਸਖ਼ਤ ਸ਼ਰਤਾਂ ਰੱਖਦੀਆਂ ਹਨ। + +### Level evaluation +### ਪੱਧਰ ਮੁਲਾਂਕਣ + +Levels are defined by priority-based evaluation of each requirement based on experience implementing and testing security requirements. The main focus is on comparing risk reduction with the effort to implement the requirement. Another key factor is to keep a low barrier to entry. + +ਪੱਧਰਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਅਤੇ ਟੈਸਟ ਕਰਨ ਦੇ ਤਜਰਬੇ ਦੇ ਆਧਾਰ 'ਤੇ ਹਰ ਲੋੜ ਦੇ ਤਰਜੀਹ-ਆਧਾਰਿਤ ਮੁਲਾਂਕਣ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਮੁੱਖ ਧਿਆਨ ਜੋਖਮ ਘਟਾਉ ਦੀ ਤੁਲਨਾ ਲੋੜ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਯਤਨ ਨਾਲ ਕਰਨ 'ਤੇ ਹੈ। ਇੱਕ ਹੋਰ ਮੁੱਖ ਕਾਰਕ ਦਾਖ਼ਲੇ ਦੀ ਰੁਕਾਵਟ ਨੂੰ ਘੱਟ ਰੱਖਣਾ ਹੈ। + +Risk reduction considers the extent to which the requirement reduces the level of security risk within the application, taking into account the classic Confidentiality, Integrity, and Availability impact factors as well as considering whether this is a primary layer of defense or whether it would be considered defense in depth. + +ਜੋਖਮ ਘਟਾਉ ਇਸ ਹੱਦ ਨੂੰ ਵਿਚਾਰਦਾ ਹੈ ਕਿ ਲੋੜ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ ਸੁਰੱਖਿਆ ਜੋਖਮ ਦੇ ਪੱਧਰ ਨੂੰ ਕਿੰਨਾ ਘਟਾਉਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਕਲਾਸਿਕ ਗੁਪਤਤਾ (Confidentiality), ਅਖੰਡਤਾ (Integrity), ਅਤੇ ਉਪਲਬਧਤਾ (Availability) ਪ੍ਰਭਾਵ ਕਾਰਕਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਨਾਲ ਹੀ ਇਹ ਵਿਚਾਰਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਕੀ ਇਹ ਰੱਖਿਆ ਦੀ ਇੱਕ ਮੁੱਢਲੀ ਪਰਤ ਹੈ ਜਾਂ ਇਸ ਨੂੰ ਡੂੰਘਾਈ ਵਿੱਚ ਰੱਖਿਆ (defense in depth) ਮੰਨਿਆ ਜਾਵੇਗਾ। + +The rigorous discussions around both the criteria and the leveling decisions have resulted in an allocation which should hold true for the vast majority of cases, whilst accepting that it may not be a 100% fit for every situation. This means that in certain cases, organizations may wish to prioritize requirements from a higher level earlier on based on their own specific risk considerations. + +ਮਾਪਦੰਡਾਂ ਅਤੇ ਪੱਧਰ-ਨਿਰਧਾਰਨ ਦੇ ਫ਼ੈਸਲਿਆਂ, ਦੋਵਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸਖ਼ਤ ਵਿਚਾਰ-ਵਟਾਂਦਰੇ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਇੱਕ ਅਜਿਹੀ ਵੰਡ ਹੋਈ ਹੈ ਜੋ ਮਾਮਲਿਆਂ ਦੀ ਵੱਡੀ ਬਹੁਗਿਣਤੀ ਲਈ ਸਹੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਇਹ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਇਹ ਹਰ ਸਥਿਤੀ ਲਈ 100% ਢੁਕਵੀਂ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਇਸ ਦਾ ਅਰਥ ਹੈ ਕਿ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਸੰਸਥਾਵਾਂ ਆਪਣੇ ਖ਼ਾਸ ਜੋਖਮ ਵਿਚਾਰਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਉੱਚੇ ਪੱਧਰ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤਰਜੀਹ ਦੇਣਾ ਚਾਹ ਸਕਦੀਆਂ ਹਨ। + +The types of requirements in each level could be characterized as follows. + +ਹਰ ਪੱਧਰ ਵਿੱਚ ਲੋੜਾਂ ਦੀਆਂ ਕਿਸਮਾਂ ਨੂੰ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਦਰਸਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। + +### Level 1 +### ਪੱਧਰ 1 + +This level contains the minimum requirements to consider when securing an application and represents a critical starting point. This level contains around 20% of the ASVS requirements. The goal for this level is to have as few requirements as possible, to decrease the barrier to entry. + +ਇਸ ਪੱਧਰ ਵਿੱਚ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਸਮੇਂ ਵਿਚਾਰਨ ਲਈ ਘੱਟੋ-ਘੱਟ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ ਅਤੇ ਇਹ ਇੱਕ ਨਾਜ਼ੁਕ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਇਸ ਪੱਧਰ ਵਿੱਚ ASVS ਲੋੜਾਂ ਦਾ ਲਗਭਗ 20% ਸ਼ਾਮਲ ਹੈ। ਇਸ ਪੱਧਰ ਦਾ ਟੀਚਾ ਦਾਖ਼ਲੇ ਦੀ ਰੁਕਾਵਟ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਜਿੰਨੀਆਂ ਸੰਭਵ ਹੋ ਸਕੇ ਓਨੀਆਂ ਘੱਟ ਲੋੜਾਂ ਰੱਖਣਾ ਹੈ। + +These requirements are generally critical or basic, first-layer of defense requirements for preventing common attacks that do not require other vulnerabilities or preconditions to be exploitable. + +ਇਹ ਲੋੜਾਂ ਆਮ ਤੌਰ 'ਤੇ ਨਾਜ਼ੁਕ ਜਾਂ ਬੁਨਿਆਦੀ, ਰੱਖਿਆ ਦੀ ਪਹਿਲੀ ਪਰਤ ਵਾਲੀਆਂ ਲੋੜਾਂ ਹਨ ਜੋ ਉਹਨਾਂ ਆਮ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਸ਼ੋਸ਼ਣਯੋਗ ਹੋਣ ਲਈ ਹੋਰ ਕਮਜ਼ੋਰੀਆਂ ਜਾਂ ਪੂਰਵ-ਸ਼ਰਤਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। + +In addition to the first layer of defense requirements, some requirements have less of an impact at higher levels, such as requirements related to passwords. Those are more important for Level 1, as from higher levels, the multi-factor authentication requirements become relevant. + +ਰੱਖਿਆ ਦੀ ਪਹਿਲੀ ਪਰਤ ਵਾਲੀਆਂ ਲੋੜਾਂ ਤੋਂ ਇਲਾਵਾ, ਕੁਝ ਲੋੜਾਂ ਦਾ ਉੱਚੇ ਪੱਧਰਾਂ 'ਤੇ ਘੱਟ ਪ੍ਰਭਾਵ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਪਾਸਵਰਡਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਲੋੜਾਂ। ਉਹ ਪੱਧਰ 1 ਲਈ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਕਿਉਂਕਿ ਉੱਚੇ ਪੱਧਰਾਂ ਤੋਂ, ਬਹੁ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ (multi-factor authentication) ਦੀਆਂ ਲੋੜਾਂ ਸੰਬੰਧਿਤ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। + +Level 1 is not necessarily penetration testable by an external tester without internal access to documentation or code (such as "black box" testing), although the lower number of requirements should make it easier to verify. + +ਪੱਧਰ 1 ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਕੋਡ ਤੱਕ ਅੰਦਰੂਨੀ ਪਹੁੰਚ ਤੋਂ ਬਿਨਾਂ ਕਿਸੇ ਬਾਹਰੀ ਟੈਸਟਰ ਦੁਆਰਾ ਪੈਨੇਟ੍ਰੇਸ਼ਨ ਟੈਸਟ ਕਰਨ ਯੋਗ ਨਹੀਂ ਹੈ (ਜਿਵੇਂ ਕਿ "ਬਲੈਕ ਬਾਕਸ" ਟੈਸਟਿੰਗ), ਹਾਲਾਂਕਿ ਲੋੜਾਂ ਦੀ ਘੱਟ ਗਿਣਤੀ ਇਸ ਦੀ ਤਸਦੀਕ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ। + +### Level 2 +### ਪੱਧਰ 2 + +Most applications should be striving to achieve this level of security. Around 50% of the requirements in the ASVS are L2 meaning that an application needs to implement around 70% of the requirements in the ASVS (all of the L1 and L2 requirements) in order to comply with L2. + +ਬਹੁਤੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਦੇ ਇਸ ਪੱਧਰ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਯਤਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ASVS ਵਿੱਚ ਲਗਭਗ 50% ਲੋੜਾਂ L2 ਹਨ, ਜਿਸ ਦਾ ਅਰਥ ਹੈ ਕਿ L2 ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ASVS ਦੀਆਂ ਲਗਭਗ 70% ਲੋੜਾਂ (ਸਾਰੀਆਂ L1 ਅਤੇ L2 ਲੋੜਾਂ) ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। + +These requirements generally relate to either less common attacks or more complicated protections against common attacks. They may still be a first layer of defense, or they may require certain preconditions for the attack to be successful. + +ਇਹ ਲੋੜਾਂ ਆਮ ਤੌਰ 'ਤੇ ਜਾਂ ਤਾਂ ਘੱਟ ਆਮ ਹਮਲਿਆਂ ਨਾਲ ਜਾਂ ਆਮ ਹਮਲਿਆਂ ਵਿਰੁੱਧ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਸੁਰੱਖਿਆਵਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ। ਇਹ ਅਜੇ ਵੀ ਰੱਖਿਆ ਦੀ ਪਹਿਲੀ ਪਰਤ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਜਾਂ ਹਮਲੇ ਦੇ ਸਫਲ ਹੋਣ ਲਈ ਇਹਨਾਂ ਨੂੰ ਕੁਝ ਪੂਰਵ-ਸ਼ਰਤਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। + +### Level 3 +### ਪੱਧਰ 3 + +This level should be the goal for applications looking to demonstrate the highest levels of security and provides the final ~30% of requirements to comply with. + +ਇਹ ਪੱਧਰ ਉਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਟੀਚਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸੁਰੱਖਿਆ ਦੇ ਸਭ ਤੋਂ ਉੱਚੇ ਪੱਧਰਾਂ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰਨਾ ਚਾਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਇਹ ਪਾਲਣਾ ਕਰਨ ਲਈ ਅੰਤਿਮ ~30% ਲੋੜਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। + +Requirements in this section are generally either defense-in-depth mechanisms or other useful but hard-to-implement controls. + +ਇਸ ਭਾਗ ਦੀਆਂ ਲੋੜਾਂ ਆਮ ਤੌਰ 'ਤੇ ਜਾਂ ਤਾਂ ਡੂੰਘਾਈ ਵਿੱਚ ਰੱਖਿਆ ਦੀਆਂ ਪ੍ਰਣਾਲੀਆਂ ਹਨ ਜਾਂ ਹੋਰ ਲਾਭਦਾਇਕ ਪਰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਔਖੇ ਨਿਯੰਤਰਣ ਹਨ। + +### Which level to achieve +### ਕਿਹੜਾ ਪੱਧਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ + +The priority-based levels are intended to provide a reflection of the application security maturity of the organization and the application. Rather than the ASVS prescriptively stating what level an application should be at, an organization should analyze its risks and decide what level it believes it should be at, depending on the sensitivity of the application and of course, the expectations of the application's users. + +ਤਰਜੀਹ-ਆਧਾਰਿਤ ਪੱਧਰਾਂ ਦਾ ਉਦੇਸ਼ ਸੰਸਥਾ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਪਰਿਪੱਕਤਾ ਦਾ ਪ੍ਰਤੀਬਿੰਬ ਪ੍ਰਦਾਨ ਕਰਨਾ ਹੈ। ASVS ਦੁਆਰਾ ਨਿਰਦੇਸ਼ਾਤਮਕ ਤੌਰ 'ਤੇ ਇਹ ਦੱਸਣ ਦੀ ਬਜਾਏ ਕਿ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਕਿਸ ਪੱਧਰ 'ਤੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਇੱਕ ਸੰਸਥਾ ਨੂੰ ਆਪਣੇ ਜੋਖਮਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਹ ਫ਼ੈਸਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਸ ਦੇ ਵਿਸ਼ਵਾਸ ਅਨੁਸਾਰ ਉਸ ਨੂੰ ਕਿਸ ਪੱਧਰ 'ਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸੰਵੇਦਨਸ਼ੀਲਤਾ ਅਤੇ ਬੇਸ਼ੱਕ, ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਦੀਆਂ ਉਮੀਦਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। + +For example, an early-stage startup that is only collecting limited sensitive data may decide to focus on Level 1 for its initial security goals, but a bank may have difficulty justifying anything less than Level 3 to its customers for its online banking application. + +ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸ਼ੁਰੂਆਤੀ-ਪੜਾਅ ਦਾ ਸਟਾਰਟਅੱਪ ਜੋ ਸਿਰਫ਼ ਸੀਮਤ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਇਕੱਠਾ ਕਰ ਰਿਹਾ ਹੈ, ਆਪਣੇ ਸ਼ੁਰੂਆਤੀ ਸੁਰੱਖਿਆ ਟੀਚਿਆਂ ਲਈ ਪੱਧਰ 1 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨ ਦਾ ਫ਼ੈਸਲਾ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕ ਬੈਂਕ ਨੂੰ ਆਪਣੀ ਆਨਲਾਈਨ ਬੈਂਕਿੰਗ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਆਪਣੇ ਗਾਹਕਾਂ ਸਾਹਮਣੇ ਪੱਧਰ 3 ਤੋਂ ਘੱਟ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦੀ ਹੈ। + +## How to use the ASVS +## ASVS ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰੀਏ + +### The structure of the ASVS +### ASVS ਦੀ ਬਣਤਰ + +The ASVS is made up of a total of around 350 requirements which are divided into 17 chapters, each of which is further divided into sections. + +ASVS ਕੁੱਲ ਲਗਭਗ 350 ਲੋੜਾਂ ਤੋਂ ਬਣਿਆ ਹੈ, ਜੋ 17 ਅਧਿਆਇਆਂ ਵਿੱਚ ਵੰਡੀਆਂ ਗਈਆਂ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਅਧਿਆਇ ਨੂੰ ਅੱਗੇ ਭਾਗਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ। + +The aim of the chapter and section division is to simplify choosing or filtering out chapters and sections based on what is relevant for the application. For example, for a machine-to-machine API, the requirements in chapter V3 related to web frontends will not be relevant. If there is no use of OAuth or WebRTC, then those chapters can be ignored as well. + +ਅਧਿਆਇ ਅਤੇ ਭਾਗ ਦੀ ਵੰਡ ਦਾ ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਜੋ ਸੰਬੰਧਿਤ ਹੈ, ਉਸ ਦੇ ਆਧਾਰ 'ਤੇ ਅਧਿਆਇਆਂ ਅਤੇ ਭਾਗਾਂ ਨੂੰ ਚੁਣਨਾ ਜਾਂ ਛਾਂਟ ਕੇ ਬਾਹਰ ਕੱਢਣਾ ਸਰਲ ਬਣਾਇਆ ਜਾਵੇ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਮਸ਼ੀਨ-ਤੋਂ-ਮਸ਼ੀਨ API ਲਈ, ਅਧਿਆਇ V3 ਵਿੱਚ ਵੈੱਬ ਫਰੰਟਐਂਡਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਲੋੜਾਂ ਸੰਬੰਧਿਤ ਨਹੀਂ ਹੋਣਗੀਆਂ। ਜੇ OAuth ਜਾਂ WebRTC ਦੀ ਕੋਈ ਵਰਤੋਂ ਨਹੀਂ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਅਧਿਆਇਆਂ ਨੂੰ ਵੀ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। + +### Release strategy +### ਰਿਲੀਜ਼ ਰਣਨੀਤੀ + +ASVS releases follow the pattern "Major.Minor.Patch" and the numbers provide information on what has changed within the release. In a major release, the first number will change, in a minor release, the second number will change, and in a patch release, the third number will change. + +ASVS ਰਿਲੀਜ਼ਾਂ "Major.Minor.Patch" ਦੇ ਨਮੂਨੇ ਦੀ ਪਾਲਣਾ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਇਹ ਅੰਕ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦਿੰਦੇ ਹਨ ਕਿ ਰਿਲੀਜ਼ ਦੇ ਅੰਦਰ ਕੀ ਬਦਲਿਆ ਹੈ। ਇੱਕ ਮੇਜਰ (major) ਰਿਲੀਜ਼ ਵਿੱਚ ਪਹਿਲਾ ਅੰਕ ਬਦਲੇਗਾ, ਇੱਕ ਮਾਈਨਰ (minor) ਰਿਲੀਜ਼ ਵਿੱਚ ਦੂਜਾ ਅੰਕ ਬਦਲੇਗਾ, ਅਤੇ ਇੱਕ ਪੈਚ (patch) ਰਿਲੀਜ਼ ਵਿੱਚ ਤੀਜਾ ਅੰਕ ਬਦਲੇਗਾ। + +* Major release - Full reorganization, almost everything may have changed, including requirement numbers. Reevaluation for compliance will be necessary (for example, 4.0.3 -> 5.0.0). +* Minor release - Requirements may be added or removed, but overall numbering will stay the same. Reevaluation for compliance will be necessary, but should be easier (for example, 5.0.0 -> 5.1.0). +* Patch release - Requirements may be removed (for example, if they are duplicates or outdated) or made less stringent, but an application that complied with the previous release will comply with the patch release as well (for example, 5.0.0 -> 5.0.1). + +* ਮੇਜਰ ਰਿਲੀਜ਼ - ਪੂਰਾ ਪੁਨਰਗਠਨ, ਲਗਭਗ ਸਭ ਕੁਝ ਬਦਲਿਆ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਲੋੜਾਂ ਦੇ ਨੰਬਰ ਵੀ ਸ਼ਾਮਲ ਹਨ। ਪਾਲਣਾ ਲਈ ਮੁੜ-ਮੁਲਾਂਕਣ ਜ਼ਰੂਰੀ ਹੋਵੇਗਾ (ਉਦਾਹਰਨ ਲਈ, 4.0.3 -> 5.0.0)। +* ਮਾਈਨਰ ਰਿਲੀਜ਼ - ਲੋੜਾਂ ਜੋੜੀਆਂ ਜਾਂ ਹਟਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਸਮੁੱਚੀ ਨੰਬਰਿੰਗ ਉਹੀ ਰਹੇਗੀ। ਪਾਲਣਾ ਲਈ ਮੁੜ-ਮੁਲਾਂਕਣ ਜ਼ਰੂਰੀ ਹੋਵੇਗਾ, ਪਰ ਇਹ ਆਸਾਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, 5.0.0 -> 5.1.0)। +* ਪੈਚ ਰਿਲੀਜ਼ - ਲੋੜਾਂ ਹਟਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਜੇ ਉਹ ਦੁਹਰਾਈਆਂ ਗਈਆਂ ਜਾਂ ਪੁਰਾਣੀਆਂ ਹਨ) ਜਾਂ ਘੱਟ ਸਖ਼ਤ ਬਣਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਜਿਹੜੀ ਐਪਲੀਕੇਸ਼ਨ ਪਿਛਲੀ ਰਿਲੀਜ਼ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਸੀ, ਉਹ ਪੈਚ ਰਿਲੀਜ਼ ਦੀ ਵੀ ਪਾਲਣਾ ਕਰੇਗੀ (ਉਦਾਹਰਨ ਲਈ, 5.0.0 -> 5.0.1)। + +The above specifically relates to the requirements in the ASVS. Changes to surrounding text and other content such as the appendices will not be considered to be a breaking change. + +ਉਪਰੋਕਤ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ASVS ਵਿਚਲੀਆਂ ਲੋੜਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ। ਆਲੇ-ਦੁਆਲੇ ਦੇ ਪਾਠ ਅਤੇ ਹੋਰ ਸਮੱਗਰੀ, ਜਿਵੇਂ ਕਿ ਅੰਤਿਕਾਵਾਂ, ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਤੋੜਨ ਵਾਲੀ ਤਬਦੀਲੀ (breaking change) ਨਹੀਂ ਮੰਨਿਆ ਜਾਵੇਗਾ। + +### Flexibility with the ASVS +### ASVS ਨਾਲ ਲਚਕ + +Several of the points described above, such as documentation requirements and the levels mechanism, provide the ability to use the ASVS in a more flexible and organization-specific way. + +ਉੱਪਰ ਦੱਸੇ ਗਏ ਕਈ ਨੁਕਤੇ, ਜਿਵੇਂ ਕਿ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਲੋੜਾਂ ਅਤੇ ਪੱਧਰਾਂ ਦੀ ਪ੍ਰਣਾਲੀ, ASVS ਨੂੰ ਵਧੇਰੇ ਲਚਕਦਾਰ ਅਤੇ ਸੰਸਥਾ-ਵਿਸ਼ੇਸ਼ ਢੰਗ ਨਾਲ ਵਰਤਣ ਦੀ ਸਮਰੱਥਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। + +Additionally, organizations are strongly encouraged to create an organization- or domain-specific fork. + +ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸੰਸਥਾਵਾਂ ਨੂੰ ਇੱਕ ਸੰਸਥਾ- ਜਾਂ ਖੇਤਰ-ਵਿਸ਼ੇਸ਼ (domain-specific) ਫ਼ੋਰਕ (fork) ਬਣਾਉਣ ਲਈ ਜ਼ੋਰਦਾਰ ਢੰਗ ਨਾਲ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। + +### Forking the ASVS +### ASVS ਨੂੰ ਫ਼ੋਰਕ ਕਰਨਾ + +Organizations can benefit from adopting ASVS by choosing one of the three levels or by creating a domain-specific fork that adjusts requirements per application risk level. This type of fork is encouraged, provided that it maintains traceability so that passing requirement 4.1.1 means the same across all versions. + +ਸੰਸਥਾਵਾਂ ਤਿੰਨ ਪੱਧਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਚੁਣ ਕੇ, ਜਾਂ ਇੱਕ ਅਜਿਹਾ ਖੇਤਰ-ਵਿਸ਼ੇਸ਼ ਫ਼ੋਰਕ ਬਣਾ ਕੇ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਜੋਖਮ ਪੱਧਰ ਅਨੁਸਾਰ ਲੋੜਾਂ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰਦਾ ਹੈ, ASVS ਨੂੰ ਅਪਣਾਉਣ ਦਾ ਲਾਭ ਲੈ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਕਿਸਮ ਦੇ ਫ਼ੋਰਕ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਬਸ਼ਰਤੇ ਕਿ ਇਹ ਖੋਜਯੋਗਤਾ (traceability) ਬਣਾਈ ਰੱਖੇ, ਤਾਂ ਜੋ ਲੋੜ 4.1.1 ਨੂੰ ਪਾਸ ਕਰਨ ਦਾ ਅਰਥ ਸਾਰੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹਾ ਰਹੇ। + +Ideally, each organization should create its own tailored ASVS, omitting irrelevant sections (e.g., GraphQL, Websockets, SOAP, if unused). Forking should start with ASVS Level 1 as a baseline, advancing to Levels 2 or 3 based on the application’s risk. + +ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਹਰ ਸੰਸਥਾ ਨੂੰ ਆਪਣਾ ਅਨੁਕੂਲਿਤ ASVS ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਅਸੰਬੰਧਿਤ ਭਾਗਾਂ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਜਾਵੇ (ਜਿਵੇਂ, GraphQL, Websockets, SOAP, ਜੇ ਵਰਤੇ ਨਹੀਂ ਜਾਂਦੇ)। ਫ਼ੋਰਕ ਕਰਨਾ ASVS ਪੱਧਰ 1 ਨੂੰ ਆਧਾਰ-ਰੇਖਾ (baseline) ਵਜੋਂ ਲੈ ਕੇ ਸ਼ੁਰੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਜੋਖਮ ਦੇ ਆਧਾਰ 'ਤੇ ਪੱਧਰ 2 ਜਾਂ 3 ਵੱਲ ਅੱਗੇ ਵਧਣਾ ਚਾਹੀਦਾ ਹੈ। + +### How to Reference ASVS Requirements +### ASVS ਲੋੜਾਂ ਦਾ ਹਵਾਲਾ ਕਿਵੇਂ ਦੇਣਾ ਹੈ + +Each requirement has an identifier in the format `.
.`, where each element is a number. For example, `1.11.3`. + +ਹਰ ਲੋੜ ਦਾ `.
.` ਫਾਰਮੈਟ ਵਿੱਚ ਇੱਕ ਪਛਾਣਕਰਤਾ (identifier) ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਹਰ ਤੱਤ ਇੱਕ ਅੰਕ ਹੈ। ਉਦਾਹਰਨ ਲਈ, `1.11.3`। + +* The `` value corresponds to the chapter from which the requirement comes; for example, all `1.#.#` requirements are from the 'Encoding and Sanitization' chapter. +* The `
` value corresponds to the section within that chapter where the requirement appears, for example: all `1.2.#` requirements are in the 'Injection Prevention' section of the 'Encoding and Sanitization' chapter. +* The `` value identifies the specific requirement within the chapter and section, for example, `1.2.5` which as of version 5.0.0 of this standard is: + +* `` ਮੁੱਲ ਉਸ ਅਧਿਆਇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜਿਸ ਤੋਂ ਲੋੜ ਆਉਂਦੀ ਹੈ; ਉਦਾਹਰਨ ਲਈ, ਸਾਰੀਆਂ `1.#.#` ਲੋੜਾਂ 'ਏਨਕੋਡਿੰਗ ਅਤੇ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ' (Encoding and Sanitization) ਅਧਿਆਇ ਤੋਂ ਹਨ। +* `
` ਮੁੱਲ ਉਸ ਅਧਿਆਇ ਦੇ ਅੰਦਰਲੇ ਉਸ ਭਾਗ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜਿੱਥੇ ਲੋੜ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ: ਸਾਰੀਆਂ `1.2.#` ਲੋੜਾਂ 'ਏਨਕੋਡਿੰਗ ਅਤੇ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ' ਅਧਿਆਇ ਦੇ 'ਇੰਜੈਕਸ਼ਨ ਰੋਕਥਾਮ' (Injection Prevention) ਭਾਗ ਵਿੱਚ ਹਨ। +* `` ਮੁੱਲ ਅਧਿਆਇ ਅਤੇ ਭਾਗ ਦੇ ਅੰਦਰ ਖ਼ਾਸ ਲੋੜ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, `1.2.5`, ਜੋ ਇਸ ਮਿਆਰ ਦੇ ਸੰਸਕਰਣ 5.0.0 ਅਨੁਸਾਰ ਇਹ ਹੈ: + +> Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. + +> ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ OS ਕਮਾਂਡ ਇੰਜੈਕਸ਼ਨ ਤੋਂ ਬਚਾਅ ਕਰਦੀ ਹੈ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਕਾਲਾਂ ਪੈਰਾਮੀਟਰਾਈਜ਼ਡ OS ਕਿਊਰੀਆਂ ਵਰਤਦੀਆਂ ਹਨ ਜਾਂ ਸੰਦਰਭੀ ਕਮਾਂਡ ਲਾਈਨ ਆਊਟਪੁੱਟ ਏਨਕੋਡਿੰਗ ਵਰਤਦੀਆਂ ਹਨ। + +Since the identifiers may change between versions of the standard, it is preferable for other documents, reports, or tools to use the following format: `v-.
.`, where: 'version' is the ASVS version tag. For example: `v5.0.0-1.2.5` would be understood to mean specifically the 5th requirement in the 'Injection Prevention' section of the 'Encoding and Sanitization' chapter from version 5.0.0. (This could be summarized as `v-`.) + +ਕਿਉਂਕਿ ਪਛਾਣਕਰਤਾ ਮਿਆਰ ਦੇ ਸੰਸਕਰਣਾਂ ਦੇ ਵਿਚਕਾਰ ਬਦਲ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਹੋਰ ਦਸਤਾਵੇਜ਼ਾਂ, ਰਿਪੋਰਟਾਂ, ਜਾਂ ਟੂਲਾਂ ਲਈ ਹੇਠ ਲਿਖੇ ਫਾਰਮੈਟ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ: `v-.
.`, ਜਿੱਥੇ: 'version' ASVS ਸੰਸਕਰਣ ਟੈਗ ਹੈ। ਉਦਾਹਰਨ ਲਈ: `v5.0.0-1.2.5` ਨੂੰ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਸੰਸਕਰਣ 5.0.0 ਦੇ 'ਏਨਕੋਡਿੰਗ ਅਤੇ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ' ਅਧਿਆਇ ਦੇ 'ਇੰਜੈਕਸ਼ਨ ਰੋਕਥਾਮ' ਭਾਗ ਦੀ 5ਵੀਂ ਲੋੜ ਵਜੋਂ ਸਮਝਿਆ ਜਾਵੇਗਾ। (ਇਸ ਨੂੰ `v-` ਵਜੋਂ ਸੰਖੇਪ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ)। + +Note: The `v` preceding the version number in the format should always be lowercase. + +ਨੋਟ: ਫਾਰਮੈਟ ਵਿੱਚ ਸੰਸਕਰਣ ਨੰਬਰ ਤੋਂ ਪਹਿਲਾਂ ਆਉਣ ਵਾਲਾ `v` ਹਮੇਸ਼ਾ ਛੋਟੇ ਅੱਖਰ (lowercase) ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। + +If identifiers are used without including the `v` element then they should be assumed to refer to the latest Application Security Verification Standard content. As the standard grows and changes this becomes problematic, which is why writers or developers should include the version element. + +ਜੇ ਪਛਾਣਕਰਤਾਵਾਂ ਨੂੰ `v` ਤੱਤ ਸ਼ਾਮਲ ਕੀਤੇ ਬਿਨਾਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਨਵੀਨਤਮ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਤਸਦੀਕ ਮਿਆਰ ਦੀ ਸਮੱਗਰੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ। ਜਿਵੇਂ-ਜਿਵੇਂ ਮਿਆਰ ਵਧਦਾ ਅਤੇ ਬਦਲਦਾ ਹੈ, ਇਹ ਸਮੱਸਿਆ ਵਾਲਾ ਬਣ ਜਾਂਦਾ ਹੈ, ਇਸੇ ਕਰਕੇ ਲੇਖਕਾਂ ਜਾਂ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਸੰਸਕਰਣ ਤੱਤ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। + +ASVS requirement lists are made available in CSV, JSON, and other formats which may be useful for reference or programmatic use. + +ASVS ਲੋੜਾਂ ਦੀਆਂ ਸੂਚੀਆਂ CSV, JSON, ਅਤੇ ਹੋਰ ਫਾਰਮੈਟਾਂ ਵਿੱਚ ਉਪਲਬਧ ਕਰਵਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜੋ ਹਵਾਲੇ ਜਾਂ ਪ੍ਰੋਗਰਾਮੀ ਵਰਤੋਂ ਲਈ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੀਆਂ ਹਨ। + +## Use cases for the ASVS +## ASVS ਦੇ ਵਰਤੋਂ ਦੇ ਮਾਮਲੇ + +The ASVS can be used to assess the security of an application and this is explored in more depth in the next chapter. However, several other potential uses for the ASVS (or a forked version) have been identified. + +ASVS ਦੀ ਵਰਤੋਂ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸੁਰੱਖਿਆ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਅਤੇ ਅਗਲੇ ਅਧਿਆਇ ਵਿੱਚ ਇਸ ਦੀ ਵਧੇਰੇ ਡੂੰਘਾਈ ਨਾਲ ਪੜਚੋਲ ਕੀਤੀ ਗਈ ਹੈ। ਹਾਲਾਂਕਿ, ASVS (ਜਾਂ ਇਸ ਦੇ ਫ਼ੋਰਕ ਕੀਤੇ ਸੰਸਕਰਣ) ਦੇ ਕਈ ਹੋਰ ਸੰਭਾਵੀ ਉਪਯੋਗਾਂ ਦੀ ਪਛਾਣ ਕੀਤੀ ਗਈ ਹੈ। + +### As Detailed Security Architecture Guidance +### ਵਿਸਤ੍ਰਿਤ ਸੁਰੱਖਿਆ ਆਰਕੀਟੈਕਚਰ ਮਾਰਗਦਰਸ਼ਨ ਵਜੋਂ + +One of the more common uses for the Application Security Verification Standard is as a resource for security architects. There are limited resources available for how to build a secure application architecture, especially with modern applications. ASVS can be used to fill in those gaps by allowing security architects to choose better controls for common problems, such as data protection patterns and input validation strategies. The architecture and documentation requirements will be particularly useful for this. + +ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਤਸਦੀਕ ਮਿਆਰ ਦੇ ਵਧੇਰੇ ਆਮ ਉਪਯੋਗਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੁਰੱਖਿਆ ਆਰਕੀਟੈਕਟਾਂ ਲਈ ਇੱਕ ਸਰੋਤ ਵਜੋਂ ਹੈ। ਇੱਕ ਸੁਰੱਖਿਅਤ ਐਪਲੀਕੇਸ਼ਨ ਆਰਕੀਟੈਕਚਰ (architecture) ਕਿਵੇਂ ਬਣਾਈ ਜਾਵੇ, ਇਸ ਬਾਰੇ ਸੀਮਤ ਸਰੋਤ ਉਪਲਬਧ ਹਨ, ਖ਼ਾਸ ਕਰਕੇ ਆਧੁਨਿਕ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ। ASVS ਦੀ ਵਰਤੋਂ ਸੁਰੱਖਿਆ ਆਰਕੀਟੈਕਟਾਂ ਨੂੰ ਆਮ ਸਮੱਸਿਆਵਾਂ, ਜਿਵੇਂ ਕਿ ਡਾਟਾ ਸੁਰੱਖਿਆ ਨਮੂਨਿਆਂ ਅਤੇ ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ ਰਣਨੀਤੀਆਂ, ਲਈ ਬਿਹਤਰ ਨਿਯੰਤਰਣ ਚੁਣਨ ਦੇ ਯੋਗ ਬਣਾ ਕੇ ਇਹਨਾਂ ਖੱਪਿਆਂ ਨੂੰ ਭਰਨ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਲੋੜਾਂ ਇਸ ਲਈ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੋਣਗੀਆਂ। + +### As a Specialized Secure Coding Reference +### ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸੁਰੱਖਿਅਤ ਕੋਡਿੰਗ ਹਵਾਲੇ ਵਜੋਂ + +The ASVS can be used as a basis for preparing a secure coding reference during application development, helping developers to make sure that they keep security in mind when they build software. Whilst the ASVS can be the base, organizations should prepare their own specific guidance which is clear and unified and ideally be prepared based on guidance from security engineers or security architects. As an extension to this, organizations are encouraged wherever possible to prepare approved security mechanisms and libraries that can be referenced in the guidance and used by developers. + +ASVS ਦੀ ਵਰਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਵਿਕਾਸ ਦੌਰਾਨ ਇੱਕ ਸੁਰੱਖਿਅਤ ਕੋਡਿੰਗ ਹਵਾਲਾ ਤਿਆਰ ਕਰਨ ਦੇ ਆਧਾਰ ਵਜੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਜੋ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਸਾਫ਼ਟਵੇਅਰ ਬਣਾਉਂਦੇ ਸਮੇਂ ਸੁਰੱਖਿਆ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ। ਭਾਵੇਂ ASVS ਆਧਾਰ ਹੋ ਸਕਦਾ ਹੈ, ਸੰਸਥਾਵਾਂ ਨੂੰ ਆਪਣਾ ਖ਼ਾਸ ਮਾਰਗਦਰਸ਼ਨ ਤਿਆਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਸਪੱਸ਼ਟ ਅਤੇ ਇਕਸਾਰ ਹੋਵੇ ਅਤੇ ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਆ ਇੰਜੀਨੀਅਰਾਂ ਜਾਂ ਸੁਰੱਖਿਆ ਆਰਕੀਟੈਕਟਾਂ ਦੇ ਮਾਰਗਦਰਸ਼ਨ ਦੇ ਆਧਾਰ 'ਤੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੋਵੇ। ਇਸ ਦੇ ਵਿਸਤਾਰ ਵਜੋਂ, ਸੰਸਥਾਵਾਂ ਨੂੰ ਜਿੱਥੇ ਵੀ ਸੰਭਵ ਹੋਵੇ, ਪ੍ਰਵਾਨਿਤ ਸੁਰੱਖਿਆ ਪ੍ਰਣਾਲੀਆਂ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਤਿਆਰ ਕਰਨ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਦਾ ਮਾਰਗਦਰਸ਼ਨ ਵਿੱਚ ਹਵਾਲਾ ਦਿੱਤਾ ਜਾ ਸਕੇ ਅਤੇ ਜੋ ਵਿਕਾਸਕਾਰਾਂ ਦੁਆਰਾ ਵਰਤੀਆਂ ਜਾ ਸਕਣ। + +### As a Guide for Automated Unit and Integration Tests +### ਸਵੈਚਾਲਿਤ ਯੂਨਿਟ ਅਤੇ ਏਕੀਕਰਨ ਟੈਸਟਾਂ ਲਈ ਇੱਕ ਮਾਰਗਦਰਸ਼ਕ ਵਜੋਂ + +The ASVS is designed to be highly testable. Some verifications will be technical where as other requirements (such as the architectural and documentation requirements) may require documentation or architecture review. By building unit and integration tests that test and fuzz for specific and relevant abuse cases related to the requirements that are verifiable by technical means, it should be easier to check that these controls are operating correctly on each build. For example, additional tests can be crafted for the test suite for a login controller, testing the username parameter for common default usernames, account enumeration, brute forcing, LDAP and SQL injection, and XSS. Similarly, a test on the password parameter should include common passwords, password length, null byte injection, removing the parameter, XSS, and more. + +ASVS ਨੂੰ ਉੱਚ ਪੱਧਰ 'ਤੇ ਟੈਸਟ ਕਰਨ ਯੋਗ ਹੋਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਕੁਝ ਤਸਦੀਕਾਂ ਤਕਨੀਕੀ ਹੋਣਗੀਆਂ, ਜਦੋਂ ਕਿ ਹੋਰ ਲੋੜਾਂ (ਜਿਵੇਂ ਕਿ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਲੋੜਾਂ) ਲਈ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਆਰਕੀਟੈਕਚਰ ਦੀ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਤਕਨੀਕੀ ਸਾਧਨਾਂ ਦੁਆਰਾ ਤਸਦੀਕ ਕਰਨ ਯੋਗ ਲੋੜਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਖ਼ਾਸ ਅਤੇ ਸੰਬੰਧਿਤ ਦੁਰਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ (abuse cases) ਲਈ ਟੈਸਟ ਅਤੇ ਫ਼ਜ਼ (fuzz) ਕਰਨ ਵਾਲੇ ਯੂਨਿਟ ਅਤੇ ਏਕੀਕਰਨ (integration) ਟੈਸਟ ਬਣਾ ਕੇ, ਹਰ ਬਿਲਡ 'ਤੇ ਇਹ ਜਾਂਚ ਕਰਨਾ ਆਸਾਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਨਿਯੰਤਰਣ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਲੌਗਇਨ ਕੰਟਰੋਲਰ ਦੇ ਟੈਸਟ ਸੂਟ ਲਈ ਵਾਧੂ ਟੈਸਟ ਤਿਆਰ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਜੋ ਉਪਭੋਗਤਾ-ਨਾਂ ਪੈਰਾਮੀਟਰ ਨੂੰ ਆਮ ਡਿਫ਼ਾਲਟ ਉਪਭੋਗਤਾ-ਨਾਵਾਂ, ਖਾਤਾ ਐਨੂਮਰੇਸ਼ਨ (account enumeration), ਬਰੂਟ ਫੋਰਸਿੰਗ, LDAP ਅਤੇ SQL ਇੰਜੈਕਸ਼ਨ, ਅਤੇ XSS ਲਈ ਟੈਸਟ ਕਰਨ। ਇਸੇ ਤਰ੍ਹਾਂ, ਪਾਸਵਰਡ ਪੈਰਾਮੀਟਰ 'ਤੇ ਇੱਕ ਟੈਸਟ ਵਿੱਚ ਆਮ ਪਾਸਵਰਡ, ਪਾਸਵਰਡ ਦੀ ਲੰਬਾਈ, ਨਲ ਬਾਈਟ ਇੰਜੈਕਸ਼ਨ, ਪੈਰਾਮੀਟਰ ਨੂੰ ਹਟਾਉਣਾ, XSS, ਅਤੇ ਹੋਰ ਸ਼ਾਮਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। + +### For Secure Development Training +### ਸੁਰੱਖਿਅਤ ਵਿਕਾਸ ਸਿਖਲਾਈ ਲਈ + +ASVS can also be used to define the characteristics of secure software. Many “secure coding” courses are simply ethical hacking courses with a light smear of coding tips. This may not necessarily help developers to write more secure code. Instead, secure development courses can use the ASVS with a strong focus on the positive mechanisms found in the ASVS, rather than the Top 10 negative things not to do. The ASVS structure also provides a logical structure for walking through the different topics when securing an application. + +ASVS ਦੀ ਵਰਤੋਂ ਸੁਰੱਖਿਅਤ ਸਾਫ਼ਟਵੇਅਰ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ ਵੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਬਹੁਤ ਸਾਰੇ "ਸੁਰੱਖਿਅਤ ਕੋਡਿੰਗ" ਕੋਰਸ ਅਸਲ ਵਿੱਚ ਕੋਡਿੰਗ ਸੁਝਾਵਾਂ ਦੀ ਹਲਕੀ ਜਿਹੀ ਪਰਤ ਵਾਲੇ ਨੈਤਿਕ ਹੈਕਿੰਗ ਕੋਰਸ ਹੀ ਹੁੰਦੇ ਹਨ। ਇਹ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਕੋਡ ਲਿਖਣ ਵਿੱਚ ਮਦਦ ਕਰੇ। ਇਸ ਦੀ ਬਜਾਏ, ਸੁਰੱਖਿਅਤ ਵਿਕਾਸ ਕੋਰਸ ASVS ਦੀ ਵਰਤੋਂ ASVS ਵਿੱਚ ਮਿਲਣ ਵਾਲੀਆਂ ਸਕਾਰਾਤਮਕ ਪ੍ਰਣਾਲੀਆਂ 'ਤੇ ਮਜ਼ਬੂਤ ਧਿਆਨ ਨਾਲ ਕਰ ਸਕਦੇ ਹਨ, ਨਾ ਕਿ ਨਾ ਕਰਨ ਵਾਲੀਆਂ Top 10 ਨਕਾਰਾਤਮਕ ਚੀਜ਼ਾਂ 'ਤੇ। ASVS ਦੀ ਬਣਤਰ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਸਮੇਂ ਵੱਖ-ਵੱਖ ਵਿਸ਼ਿਆਂ ਵਿੱਚੋਂ ਲੰਘਣ ਲਈ ਇੱਕ ਤਰਕਪੂਰਨ ਬਣਤਰ ਵੀ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। + +### As a Framework for Guiding the Procurement of Secure Software +### ਸੁਰੱਖਿਅਤ ਸਾਫ਼ਟਵੇਅਰ ਦੀ ਖ਼ਰੀਦ ਦੇ ਮਾਰਗਦਰਸ਼ਨ ਲਈ ਇੱਕ ਫ੍ਰੇਮਵਰਕ ਵਜੋਂ + +The ASVS is a great framework to help with secure software procurement or procurement of custom development services. The buyer can simply set a requirement that the software they wish to procure must be developed at ASVS level X, and request that the seller proves that the software satisfies ASVS level X. + +ASVS ਸੁਰੱਖਿਅਤ ਸਾਫ਼ਟਵੇਅਰ ਦੀ ਖ਼ਰੀਦ ਜਾਂ ਕਸਟਮ ਵਿਕਾਸ ਸੇਵਾਵਾਂ ਦੀ ਖ਼ਰੀਦ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਫ੍ਰੇਮਵਰਕ (framework) ਹੈ। ਖ਼ਰੀਦਦਾਰ ਬਸ ਇਹ ਲੋੜ ਨਿਰਧਾਰਿਤ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਜੋ ਸਾਫ਼ਟਵੇਅਰ ਉਹ ਖ਼ਰੀਦਣਾ ਚਾਹੁੰਦਾ ਹੈ, ਉਹ ASVS ਪੱਧਰ X 'ਤੇ ਵਿਕਸਿਤ ਕੀਤਾ ਜਾਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ ਵਿਕਰੇਤਾ ਤੋਂ ਇਹ ਮੰਗ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਸਾਬਤ ਕਰੇ ਕਿ ਸਾਫ਼ਟਵੇਅਰ ASVS ਪੱਧਰ X ਨੂੰ ਸੰਤੁਸ਼ਟ ਕਰਦਾ ਹੈ। + +## Applying ASVS in Practice +## ASVS ਨੂੰ ਅਮਲ ਵਿੱਚ ਲਾਗੂ ਕਰਨਾ + +Different threats have different motivations. Some industries have unique information and technology assets and domain-specific regulatory compliance requirements. + +ਵੱਖ-ਵੱਖ ਖ਼ਤਰਿਆਂ ਦੀਆਂ ਵੱਖ-ਵੱਖ ਪ੍ਰੇਰਨਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਕੁਝ ਉਦਯੋਗਾਂ ਕੋਲ ਵਿਲੱਖਣ ਜਾਣਕਾਰੀ ਅਤੇ ਤਕਨਾਲੋਜੀ ਸੰਪਤੀਆਂ ਅਤੇ ਖੇਤਰ-ਵਿਸ਼ੇਸ਼ ਨਿਯਮਕ ਪਾਲਣਾ ਲੋੜਾਂ ਹੁੰਦੀਆਂ ਹਨ। + +Organizations are strongly encouraged to look deeply at their unique risk characteristics based on the nature of their business, and based upon that risk and business requirements determine the appropriate ASVS level. + +ਸੰਸਥਾਵਾਂ ਨੂੰ ਆਪਣੇ ਕਾਰੋਬਾਰ ਦੇ ਸੁਭਾਅ ਦੇ ਆਧਾਰ 'ਤੇ ਆਪਣੀਆਂ ਵਿਲੱਖਣ ਜੋਖਮ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਡੂੰਘਾਈ ਨਾਲ ਵੇਖਣ ਲਈ, ਅਤੇ ਉਸ ਜੋਖਮ ਅਤੇ ਕਾਰੋਬਾਰੀ ਲੋੜਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਢੁਕਵਾਂ ASVS ਪੱਧਰ ਨਿਰਧਾਰਿਤ ਕਰਨ ਲਈ ਜ਼ੋਰਦਾਰ ਢੰਗ ਨਾਲ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। diff --git a/5.0/pa-IN/0x04-Assessment_and_Certification.md b/5.0/pa-IN/0x04-Assessment_and_Certification.md new file mode 100644 index 0000000000..072626a327 --- /dev/null +++ b/5.0/pa-IN/0x04-Assessment_and_Certification.md @@ -0,0 +1,91 @@ + + + + +# Assessment and Certification +# ਮੁਲਾਂਕਣ ਅਤੇ ਸਰਟੀਫ਼ਿਕੇਸ਼ਨ + +## OWASP's Stance on ASVS Certifications and Trust Marks +## ASVS ਸਰਟੀਫ਼ਿਕੇਸ਼ਨਾਂ ਅਤੇ ਭਰੋਸਾ ਚਿੰਨ੍ਹਾਂ ਬਾਰੇ OWASP ਦਾ ਰੁਖ਼ + +OWASP, as a vendor-neutral nonprofit, does not certify any vendors, verifiers, or software. Any assurance, trust mark, or certification claiming ASVS compliance is not officially endorsed by OWASP, so organizations should be cautious of third-party claims of ASVS certification. + +OWASP, ਇੱਕ ਵਿਕਰੇਤਾ-ਨਿਰਪੱਖ (vendor-neutral) ਗ਼ੈਰ-ਮੁਨਾਫ਼ਾ ਸੰਸਥਾ ਹੋਣ ਦੇ ਨਾਤੇ, ਕਿਸੇ ਵੀ ਵਿਕਰੇਤਾ, ਤਸਦੀਕਕਰਤਾ (verifier), ਜਾਂ ਸਾਫ਼ਟਵੇਅਰ ਦਾ ਸਰਟੀਫ਼ਿਕੇਸ਼ਨ (certification) ਨਹੀਂ ਕਰਦਾ। ASVS ਪਾਲਣਾ (compliance) ਦਾ ਦਾਅਵਾ ਕਰਨ ਵਾਲਾ ਕੋਈ ਵੀ ਭਰੋਸਾ (assurance), ਭਰੋਸਾ ਚਿੰਨ੍ਹ (trust mark), ਜਾਂ ਸਰਟੀਫ਼ਿਕੇਸ਼ਨ OWASP ਦੁਆਰਾ ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਸੰਸਥਾਵਾਂ ਨੂੰ ASVS ਸਰਟੀਫ਼ਿਕੇਸ਼ਨ ਦੇ ਤੀਜੀ-ਧਿਰ ਦਾਅਵਿਆਂ ਤੋਂ ਸਾਵਧਾਨ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। + +Organizations may offer assurance services, provided they do not claim official OWASP certification. + +ਸੰਸਥਾਵਾਂ ਭਰੋਸਾ ਸੇਵਾਵਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਬਸ਼ਰਤੇ ਕਿ ਉਹ ਅਧਿਕਾਰਤ OWASP ਸਰਟੀਫ਼ਿਕੇਸ਼ਨ ਦਾ ਦਾਅਵਾ ਨਾ ਕਰਨ। + +## How to Verify ASVS Compliance +## ASVS ਪਾਲਣਾ ਦੀ ਤਸਦੀਕ ਕਿਵੇਂ ਕਰੀਏ + +The ASVS is deliberately not prescriptive about exactly how to verify compliance at the level of a testing guide. However, it is important to highlight some key points. + +ASVS ਜਾਣ-ਬੁੱਝ ਕੇ ਇਸ ਬਾਰੇ ਨਿਰਦੇਸ਼ਾਤਮਕ (prescriptive) ਨਹੀਂ ਹੈ ਕਿ ਕਿਸੇ ਟੈਸਟਿੰਗ ਮਾਰਗਦਰਸ਼ਿਕਾ (testing guide) ਦੇ ਪੱਧਰ 'ਤੇ ਪਾਲਣਾ ਦੀ ਤਸਦੀਕ ਬਿਲਕੁਲ ਕਿਵੇਂ ਕੀਤੀ ਜਾਵੇ। ਫਿਰ ਵੀ, ਕੁਝ ਮੁੱਖ ਨੁਕਤਿਆਂ ਨੂੰ ਉਜਾਗਰ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। + +### Verification reporting +### ਤਸਦੀਕ ਰਿਪੋਰਟਿੰਗ + +Traditional penetration testing reports issues “by exception,” only listing failures. However, an ASVS certification report should include scope, a summary of all requirements checked, the requirements where exceptions were noted, and guidance on resolving issues. Some requirements may be non-applicable (e.g., session management in stateless APIs), and this must be noted in the report. + +ਰਵਾਇਤੀ ਪੈਨੇਟ੍ਰੇਸ਼ਨ ਟੈਸਟਿੰਗ (penetration testing) ਰਿਪੋਰਟਾਂ ਮੁੱਦਿਆਂ ਦੀ ਰਿਪੋਰਟ "ਅਪਵਾਦ ਦੇ ਆਧਾਰ 'ਤੇ" (by exception) ਕਰਦੀਆਂ ਹਨ, ਅਰਥਾਤ ਸਿਰਫ਼ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਹੀ ਸੂਚੀਬੱਧ ਕਰਦੀਆਂ ਹਨ। ਫਿਰ ਵੀ, ਇੱਕ ASVS ਸਰਟੀਫ਼ਿਕੇਸ਼ਨ ਰਿਪੋਰਟ ਵਿੱਚ ਘੇਰਾ, ਜਾਂਚੀਆਂ ਗਈਆਂ ਸਾਰੀਆਂ ਲੋੜਾਂ ਦਾ ਸਾਰ, ਉਹ ਲੋੜਾਂ ਜਿੱਥੇ ਅਪਵਾਦ ਦਰਜ ਕੀਤੇ ਗਏ, ਅਤੇ ਮੁੱਦਿਆਂ ਨੂੰ ਹੱਲ ਕਰਨ ਬਾਰੇ ਮਾਰਗਦਰਸ਼ਨ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੁਝ ਲੋੜਾਂ ਗ਼ੈਰ-ਲਾਗੂ ਹੋ ਸਕਦੀਆਂ ਹਨ (ਜਿਵੇਂ, ਸਟੇਟਲੈੱਸ (stateless) API ਵਿੱਚ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ), ਅਤੇ ਇਸ ਨੂੰ ਰਿਪੋਰਟ ਵਿੱਚ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਦਰਜ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। + +### Scope of Verification +### ਤਸਦੀਕ ਦਾ ਘੇਰਾ + +An organization developing an application will generally not implement all requirements, as some may be irrelevant or less significant based on the functionality of the application. The verifier should make the scope of the verification clear including which Level the organization is attempting to achieve and which requirements were included. This should be from the perspective of what was included rather than what was not included. They should also provide an opinion on the rationale of excluding the requirements which haven't been implemented. + +ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਵਿਕਾਸ ਕਰਨ ਵਾਲੀ ਸੰਸਥਾ ਆਮ ਤੌਰ 'ਤੇ ਸਾਰੀਆਂ ਲੋੜਾਂ ਲਾਗੂ ਨਹੀਂ ਕਰੇਗੀ, ਕਿਉਂਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਕਾਰਜਸ਼ੀਲਤਾ ਦੇ ਆਧਾਰ 'ਤੇ ਕੁਝ ਲੋੜਾਂ ਅਪ੍ਰਸੰਗਿਕ ਜਾਂ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਤਸਦੀਕਕਰਤਾ ਨੂੰ ਤਸਦੀਕ ਦਾ ਘੇਰਾ ਸਪੱਸ਼ਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਹ ਸ਼ਾਮਲ ਹੈ ਕਿ ਸੰਸਥਾ ਕਿਹੜਾ ਪੱਧਰ ਹਾਸਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਹੈ ਅਤੇ ਕਿਹੜੀਆਂ ਲੋੜਾਂ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ। ਇਹ ਇਸ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਸੀ, ਨਾ ਕਿ ਕੀ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਉਹਨਾਂ ਨੂੰ ਉਹਨਾਂ ਲੋੜਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖਣ ਦੇ ਤਰਕ-ਆਧਾਰ ਬਾਰੇ ਵੀ ਆਪਣੀ ਰਾਏ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਲਾਗੂ ਨਹੀਂ ਕੀਤੀਆਂ ਗਈਆਂ। + +This should allow the consumer of a verification report to understand the context of the verification and make an informed decision about the level of trust they can place in the application. + +ਇਸ ਨਾਲ ਤਸਦੀਕ ਰਿਪੋਰਟ ਦਾ ਖਪਤਕਾਰ ਤਸਦੀਕ ਦੇ ਸੰਦਰਭ ਨੂੰ ਸਮਝਣ ਅਤੇ ਇਸ ਬਾਰੇ ਸੂਚਿਤ ਫ਼ੈਸਲਾ ਲੈਣ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਕਿਸ ਪੱਧਰ ਦਾ ਭਰੋਸਾ ਰੱਖ ਸਕਦਾ ਹੈ। + +Certifying organizations can choose their testing methods but should disclose them in the report and this should ideally be repeatable. Different methods, like manual penetration tests or source code analysis, may be used to verify aspects such as input validation, depending on the application and requirements. + +ਸਰਟੀਫ਼ਿਕੇਸ਼ਨ ਕਰਨ ਵਾਲੀਆਂ ਸੰਸਥਾਵਾਂ ਆਪਣੀਆਂ ਟੈਸਟਿੰਗ ਵਿਧੀਆਂ ਚੁਣ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਇਹ ਰਿਪੋਰਟ ਵਿੱਚ ਪ੍ਰਗਟ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਅਤੇ ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਇਹ ਦੁਹਰਾਉਣਯੋਗ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਲੋੜਾਂ ਦੇ ਆਧਾਰ 'ਤੇ, ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ ਵਰਗੇ ਪਹਿਲੂਆਂ ਦੀ ਤਸਦੀਕ ਕਰਨ ਲਈ ਵੱਖ-ਵੱਖ ਵਿਧੀਆਂ, ਜਿਵੇਂ ਕਿ ਹੱਥੀਂ (manual) ਪੈਨੇਟ੍ਰੇਸ਼ਨ ਟੈਸਟ ਜਾਂ ਸਰੋਤ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ, ਵਰਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। + +### Verification Mechanisms +### ਤਸਦੀਕ ਪ੍ਰਣਾਲੀਆਂ + +There are a number of different techniques which may be needed to verify specific ASVS requirements. Aside from penetration testing (using valid credentials to get full application coverage), verifying ASVS requirements may require access to documentation, source code, configuration, and the people involved in the development process. Especially for verifying L2 and L3 requirements. It is standard practice to provide robust evidence of findings with detailed documentation, which may include work papers, screenshots, scripts, and testing logs. Merely running an automated tool without thorough testing is insufficient for certification, as each requirement must be verifiably tested. + +ਖ਼ਾਸ ASVS ਲੋੜਾਂ ਦੀ ਤਸਦੀਕ ਕਰਨ ਲਈ ਕਈ ਵੱਖ-ਵੱਖ ਤਕਨੀਕਾਂ ਦੀ ਲੋੜ ਪੈ ਸਕਦੀ ਹੈ। ਪੈਨੇਟ੍ਰੇਸ਼ਨ ਟੈਸਟਿੰਗ (ਪੂਰੀ ਐਪਲੀਕੇਸ਼ਨ ਕਵਰੇਜ ਹਾਸਲ ਕਰਨ ਲਈ ਜਾਇਜ਼ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ) ਤੋਂ ਇਲਾਵਾ, ASVS ਲੋੜਾਂ ਦੀ ਤਸਦੀਕ ਕਰਨ ਲਈ ਦਸਤਾਵੇਜ਼ਾਂ, ਸਰੋਤ ਕੋਡ, ਸੰਰਚਨਾ, ਅਤੇ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਲੋਕਾਂ ਤੱਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਪੈ ਸਕਦੀ ਹੈ। ਖ਼ਾਸ ਕਰਕੇ L2 ਅਤੇ L3 ਲੋੜਾਂ ਦੀ ਤਸਦੀਕ ਕਰਨ ਲਈ। ਵਿਸਤ੍ਰਿਤ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਨਾਲ ਖੋਜਾਂ (findings) ਦੇ ਮਜ਼ਬੂਤ ਸਬੂਤ ਪ੍ਰਦਾਨ ਕਰਨਾ ਮਿਆਰੀ ਅਮਲ ਹੈ, ਜਿਸ ਵਿੱਚ ਕਾਰਜ-ਪੱਤਰ, ਸਕ੍ਰੀਨਸ਼ਾਟ, ਸਕ੍ਰਿਪਟਾਂ, ਅਤੇ ਟੈਸਟਿੰਗ ਲੌਗ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ। ਡੂੰਘੀ ਟੈਸਟਿੰਗ ਤੋਂ ਬਿਨਾਂ ਸਿਰਫ਼ ਕੋਈ ਸਵੈਚਾਲਿਤ ਟੂਲ ਚਲਾ ਦੇਣਾ ਸਰਟੀਫ਼ਿਕੇਸ਼ਨ ਲਈ ਨਾਕਾਫ਼ੀ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਲੋੜ ਨੂੰ ਤਸਦੀਕਯੋਗ ਢੰਗ ਨਾਲ ਟੈਸਟ ਕੀਤਾ ਜਾਣਾ ਲਾਜ਼ਮੀ ਹੈ। + +The use of automation to verify ASVS requirements is a topic that is constantly of interest. It is therefore important to clarify some points related to automated and black box testing. + +ASVS ਲੋੜਾਂ ਦੀ ਤਸਦੀਕ ਲਈ ਸਵੈਚਾਲਨ (automation) ਦੀ ਵਰਤੋਂ ਇੱਕ ਅਜਿਹਾ ਵਿਸ਼ਾ ਹੈ ਜਿਸ ਵਿੱਚ ਲਗਾਤਾਰ ਦਿਲਚਸਪੀ ਬਣੀ ਰਹਿੰਦੀ ਹੈ। ਇਸ ਲਈ ਸਵੈਚਾਲਿਤ ਅਤੇ ਬਲੈਕ ਬਾਕਸ (black box) ਟੈਸਟਿੰਗ ਨਾਲ ਸੰਬੰਧਿਤ ਕੁਝ ਨੁਕਤਿਆਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। + +#### The Role of Automated Security Testing Tools +#### ਸਵੈਚਾਲਿਤ ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ ਟੂਲਾਂ ਦੀ ਭੂਮਿਕਾ + +When automated security testing tools such as Dynamic and Static Application Security Testing tools (DAST and SAST) are correctly implemented in the build pipeline, they may be able to identify some security issues that should never exist. However, without careful configuration and tuning they will not provide the required coverage and the level of noise will prevent real security issues from being identified and mitigated. + +ਜਦੋਂ ਸਵੈਚਾਲਿਤ ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ ਟੂਲ, ਜਿਵੇਂ ਕਿ ਗਤੀਸ਼ੀਲ ਅਤੇ ਸਥਿਰ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ ਟੂਲ (DAST ਅਤੇ SAST), ਬਿਲਡ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਸਹੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਉਹ ਕੁਝ ਅਜਿਹੇ ਸੁਰੱਖਿਆ ਮੁੱਦਿਆਂ ਦੀ ਪਛਾਣ ਕਰਨ ਦੇ ਯੋਗ ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਕਦੇ ਮੌਜੂਦ ਹੀ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ। ਫਿਰ ਵੀ, ਧਿਆਨਪੂਰਵਕ ਸੰਰਚਨਾ ਅਤੇ ਟਿਊਨਿੰਗ ਤੋਂ ਬਿਨਾਂ ਉਹ ਲੋੜੀਂਦੀ ਕਵਰੇਜ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਨਗੇ ਅਤੇ ਸ਼ੋਰ ਦਾ ਪੱਧਰ ਅਸਲ ਸੁਰੱਖਿਆ ਮੁੱਦਿਆਂ ਨੂੰ ਪਛਾਣੇ ਜਾਣ ਅਤੇ ਘਟਾਏ ਜਾਣ ਤੋਂ ਰੋਕੇਗਾ। + +Whilst this may provide coverage of some of the more basic and straightforward technical requirements such as those relating to output encoding or sanitization, it is critical to note that these tools will be unable entirely to verify many of the more complicated ASVS requirements or those that relate to business logic and access control. + +ਭਾਵੇਂ ਇਹ ਕੁਝ ਵਧੇਰੇ ਬੁਨਿਆਦੀ ਅਤੇ ਸਿੱਧੀਆਂ ਤਕਨੀਕੀ ਲੋੜਾਂ, ਜਿਵੇਂ ਕਿ ਆਊਟਪੁੱਟ ਏਨਕੋਡਿੰਗ ਜਾਂ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ ਨਾਲ ਸੰਬੰਧਿਤ ਲੋੜਾਂ, ਦੀ ਕਵਰੇਜ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦਾ ਹੈ, ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਬੇਹੱਦ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਇਹ ਟੂਲ ਬਹੁਤ ਸਾਰੀਆਂ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ASVS ਲੋੜਾਂ, ਜਾਂ ਕਾਰੋਬਾਰੀ ਤਰਕ ਅਤੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਨਾਲ ਸੰਬੰਧਿਤ ਲੋੜਾਂ, ਦੀ ਤਸਦੀਕ ਕਰਨ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਮਰੱਥ ਹੋਣਗੇ। + +For less straightforward requirements, it is likely that automation can still be utilized but application specific verifications will need to be written to achieve this. These may be similar to unit and integration tests that the organization may already be using. It may therefore be possible to use this existing test automation infrastructure to write these ASVS specific tests. Whilst doing this will require short term investment, the long term benefits being able to continually verify these ASVS requirements will be significant. + +ਘੱਟ ਸਿੱਧੀਆਂ ਲੋੜਾਂ ਲਈ, ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਸਵੈਚਾਲਨ ਦੀ ਵਰਤੋਂ ਅਜੇ ਵੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਪਰ ਇਸ ਨੂੰ ਹਾਸਲ ਕਰਨ ਲਈ ਐਪਲੀਕੇਸ਼ਨ-ਵਿਸ਼ੇਸ਼ ਤਸਦੀਕਾਂ ਲਿਖਣੀਆਂ ਪੈਣਗੀਆਂ। ਇਹ ਉਹਨਾਂ ਯੂਨਿਟ ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟਾਂ ਵਰਗੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ ਜੋ ਸੰਸਥਾ ਸ਼ਾਇਦ ਪਹਿਲਾਂ ਹੀ ਵਰਤ ਰਹੀ ਹੋਵੇ। ਇਸ ਲਈ ਇਹ ASVS-ਵਿਸ਼ੇਸ਼ ਟੈਸਟ ਲਿਖਣ ਲਈ ਇਸ ਮੌਜੂਦਾ ਟੈਸਟ ਸਵੈਚਾਲਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੰਭਵ ਹੋ ਸਕਦਾ ਹੈ। ਭਾਵੇਂ ਅਜਿਹਾ ਕਰਨ ਲਈ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਨਿਵੇਸ਼ ਦੀ ਲੋੜ ਪਵੇਗੀ, ਇਹਨਾਂ ASVS ਲੋੜਾਂ ਦੀ ਨਿਰੰਤਰ ਤਸਦੀਕ ਕਰ ਸਕਣ ਦੇ ਲੰਮੇ ਸਮੇਂ ਦੇ ਲਾਭ ਮਹੱਤਵਪੂਰਨ ਹੋਣਗੇ। + +In summary, testable using automation != running an off the shelf tool. + +ਸੰਖੇਪ ਵਿੱਚ, ਸਵੈਚਾਲਨ ਰਾਹੀਂ ਟੈਸਟਯੋਗ ਹੋਣਾ != ਕੋਈ ਤਿਆਰ-ਬਰ-ਤਿਆਰ (off the shelf) ਟੂਲ ਚਲਾ ਦੇਣਾ। + +#### The Role of Penetration Testing +#### ਪੈਨੇਟ੍ਰੇਸ਼ਨ ਟੈਸਟਿੰਗ ਦੀ ਭੂਮਿਕਾ + +Whilst L1 in version 4.0 was optimized for "black box" (no documentation and no source) testing to occur, even then the standard was clear that it is not an effective assurance activity and should be actively discouraged. + +ਭਾਵੇਂ ਸੰਸਕਰਣ 4.0 ਵਿੱਚ L1 ਨੂੰ "ਬਲੈਕ ਬਾਕਸ" (ਬਿਨਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਅਤੇ ਬਿਨਾਂ ਸਰੋਤ ਕੋਡ ਦੇ) ਟੈਸਟਿੰਗ ਕੀਤੇ ਜਾਣ ਲਈ ਅਨੁਕੂਲਿਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਉਦੋਂ ਵੀ ਮਿਆਰ ਇਸ ਬਾਰੇ ਸਪੱਸ਼ਟ ਸੀ ਕਿ ਇਹ ਕੋਈ ਅਸਰਦਾਰ ਭਰੋਸਾ ਗਤੀਵਿਧੀ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਸਰਗਰਮੀ ਨਾਲ ਨਿਰਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। + +Testing without access to necessary additional information is an inefficient and ineffective mechanism for security verification, as it misses out on the possibility of reviewing the source, identifying threats and missing controls, and performing a far more thorough test in a shorter timeframe. + +ਲੋੜੀਂਦੀ ਵਾਧੂ ਜਾਣਕਾਰੀ ਤੱਕ ਪਹੁੰਚ ਤੋਂ ਬਿਨਾਂ ਟੈਸਟਿੰਗ ਕਰਨਾ ਸੁਰੱਖਿਆ ਤਸਦੀਕ ਲਈ ਇੱਕ ਅਕੁਸ਼ਲ ਅਤੇ ਬੇਅਸਰ ਪ੍ਰਣਾਲੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਸਰੋਤ ਕੋਡ ਦੀ ਸਮੀਖਿਆ ਕਰਨ, ਖ਼ਤਰਿਆਂ ਅਤੇ ਗੁੰਮ ਨਿਯੰਤਰਣਾਂ ਦੀ ਪਛਾਣ ਕਰਨ, ਅਤੇ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਕਿਤੇ ਵਧੇਰੇ ਡੂੰਘਾ ਟੈਸਟ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਤੋਂ ਵਾਂਝੀ ਰਹਿ ਜਾਂਦੀ ਹੈ। + +It is strongly encouraged to perform documentation or source code-led (hybrid) penetration testing, which have full access to the application developers and the application's documentation, rather than traditional penetration tests. This will certainly be necessary in order to verify many of the ASVS requirements. + +ਰਵਾਇਤੀ ਪੈਨੇਟ੍ਰੇਸ਼ਨ ਟੈਸਟਾਂ ਦੀ ਬਜਾਏ, ਦਸਤਾਵੇਜ਼-ਅਗਵਾਈ ਵਾਲੀ ਜਾਂ ਸਰੋਤ ਕੋਡ-ਅਗਵਾਈ ਵਾਲੀ (ਹਾਈਬ੍ਰਿਡ) ਪੈਨੇਟ੍ਰੇਸ਼ਨ ਟੈਸਟਿੰਗ ਕਰਨ ਲਈ ਜ਼ੋਰਦਾਰ ਢੰਗ ਨਾਲ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਵਿਕਾਸਕਾਰਾਂ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਦਸਤਾਵੇਜ਼ਾਂ ਤੱਕ ਪੂਰੀ ਪਹੁੰਚ ਹੁੰਦੀ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ASVS ਲੋੜਾਂ ਦੀ ਤਸਦੀਕ ਕਰਨ ਲਈ ਇਹ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਜ਼ਰੂਰੀ ਹੋਵੇਗਾ। diff --git a/5.0/pa-IN/0x05-For-Users-Of-4.0.md b/5.0/pa-IN/0x05-For-Users-Of-4.0.md new file mode 100644 index 0000000000..1088edd7c2 --- /dev/null +++ b/5.0/pa-IN/0x05-For-Users-Of-4.0.md @@ -0,0 +1,171 @@ + + + + +# Changes Compared to v4.x +# v4.x ਦੇ ਮੁਕਾਬਲੇ ਤਬਦੀਲੀਆਂ + +## Introduction +## ਜਾਣ-ਪਛਾਣ + +Users familiar with version 4.x of the standard may find it helpful to review the key changes introduced in version 5.0, including updates in content, scope, and underlying philosophy. + +ਮਿਆਰ ਦੇ ਸੰਸਕਰਣ 4.x ਤੋਂ ਜਾਣੂ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਸੰਸਕਰਣ 5.0 ਵਿੱਚ ਪੇਸ਼ ਕੀਤੀਆਂ ਗਈਆਂ ਮੁੱਖ ਤਬਦੀਲੀਆਂ ਦੀ ਸਮੀਖਿਆ ਕਰਨਾ ਮਦਦਗਾਰ ਲੱਗ ਸਕਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਸਮੱਗਰੀ, ਘੇਰੇ (scope), ਅਤੇ ਅੰਤਰਨਿਹਿਤ ਫ਼ਲਸਫ਼ੇ ਵਿੱਚ ਕੀਤੇ ਗਏ ਅੱਪਡੇਟ ਸ਼ਾਮਲ ਹਨ। + +Of the 286 requirements in version 4.0.3, only 11 remain unchanged, while 15 have undergone minor grammatical adjustments without altering their meaning. In total 109 requirements (38%) are no longer separate requirements in version 5.0 with 50 simply being deleted, 28 removed as duplicates and 31 merged into other requirements. The rest have been revised in some way. Even requirements that were not substantively modified have different identifiers due to reordering or restructuring. + +ਸੰਸਕਰਣ 4.0.3 ਦੀਆਂ 286 ਲੋੜਾਂ (requirements) ਵਿੱਚੋਂ, ਸਿਰਫ਼ 11 ਬਿਨਾਂ ਤਬਦੀਲੀ ਦੇ ਰਹੀਆਂ ਹਨ, ਜਦਕਿ 15 ਵਿੱਚ ਉਹਨਾਂ ਦੇ ਅਰਥ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਮਾਮੂਲੀ ਵਿਆਕਰਨਕ ਸੋਧਾਂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਕੁੱਲ ਮਿਲਾ ਕੇ 109 ਲੋੜਾਂ (38%) ਸੰਸਕਰਣ 5.0 ਵਿੱਚ ਹੁਣ ਵੱਖਰੀਆਂ ਲੋੜਾਂ ਨਹੀਂ ਰਹੀਆਂ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ 50 ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਮਿਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ, 28 ਨੂੰ ਦੁਹਰਾਅ (duplicates) ਵਜੋਂ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ ਅਤੇ 31 ਨੂੰ ਹੋਰ ਲੋੜਾਂ ਵਿੱਚ ਮਿਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਬਾਕੀ ਨੂੰ ਕਿਸੇ ਨਾ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਸੋਧਿਆ ਗਿਆ ਹੈ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਜਿਨ੍ਹਾਂ ਲੋੜਾਂ ਵਿੱਚ ਕੋਈ ਸਾਰਥਕ ਸੋਧ ਨਹੀਂ ਕੀਤੀ ਗਈ, ਉਹਨਾਂ ਦੇ ਵੀ ਮੁੜ-ਤਰਤੀਬ ਜਾਂ ਮੁੜ-ਸੰਰਚਨਾ ਕਾਰਨ ਵੱਖਰੇ ਪਛਾਣਕਰਤਾ (identifiers) ਹਨ। + +To facilitate adoption of version 5.0, mapping documents are provided to help users trace how requirements from version 4.x correspond to those in version 5.0. These mappings are not tied to release versioning and may be updated or clarified as needed. + +ਸੰਸਕਰਣ 5.0 ਨੂੰ ਅਪਣਾਉਣ ਵਿੱਚ ਸਹੂਲਤ ਦੇਣ ਲਈ, ਮੈਪਿੰਗ ਦਸਤਾਵੇਜ਼ (mapping documents) ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਹਨ ਜੋ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਇਹ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਕਿ ਸੰਸਕਰਣ 4.x ਦੀਆਂ ਲੋੜਾਂ ਸੰਸਕਰਣ 5.0 ਦੀਆਂ ਲੋੜਾਂ ਨਾਲ ਕਿਵੇਂ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ। ਇਹ ਮੈਪਿੰਗਾਂ ਰਿਲੀਜ਼ ਸੰਸਕਰਣ-ਨਿਰਧਾਰਨ ਨਾਲ ਬੱਝੀਆਂ ਹੋਈਆਂ ਨਹੀਂ ਹਨ ਅਤੇ ਜ਼ਰੂਰਤ ਅਨੁਸਾਰ ਅੱਪਡੇਟ ਜਾਂ ਸਪੱਸ਼ਟ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। + +## Requirement Philosophy +## ਲੋੜਾਂ ਦਾ ਫ਼ਲਸਫ਼ਾ + +### Scope and Focus +### ਘੇਰਾ ਅਤੇ ਕੇਂਦਰ-ਬਿੰਦੂ + +Version 4.x included requirements that did not align with the intended scope of the standard; these have been removed. Requirements that did not meet the scope criteria for 5.0 or were not verifiable have also been excluded. + +ਸੰਸਕਰਣ 4.x ਵਿੱਚ ਅਜਿਹੀਆਂ ਲੋੜਾਂ ਸ਼ਾਮਲ ਸਨ ਜੋ ਮਿਆਰ ਦੇ ਇੱਛਿਤ ਘੇਰੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀਆਂ ਸਨ; ਇਹਨਾਂ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਉਹ ਲੋੜਾਂ ਜੋ 5.0 ਲਈ ਘੇਰੇ ਦੀਆਂ ਕਸੌਟੀਆਂ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰਦੀਆਂ ਸਨ ਜਾਂ ਤਸਦੀਕਯੋਗ ਨਹੀਂ ਸਨ, ਉਹਨਾਂ ਨੂੰ ਵੀ ਬਾਹਰ ਰੱਖਿਆ ਗਿਆ ਹੈ। + +### Emphasis on Security Goals Over Mechanisms +### ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਬਜਾਏ ਸੁਰੱਖਿਆ ਟੀਚਿਆਂ 'ਤੇ ਜ਼ੋਰ + +In version 4.x, many requirements focused on specific mechanisms rather than the underlying security objectives. In version 5.0, requirements are centered on security goals, referencing particular mechanisms only when they are the sole practical solution, or providing them as examples or supplementary guidance. + +ਸੰਸਕਰਣ 4.x ਵਿੱਚ, ਬਹੁਤ ਸਾਰੀਆਂ ਲੋੜਾਂ ਅੰਤਰਨਿਹਿਤ ਸੁਰੱਖਿਆ ਉਦੇਸ਼ਾਂ (security objectives) ਦੀ ਬਜਾਏ ਖ਼ਾਸ ਪ੍ਰਣਾਲੀਆਂ (mechanisms) 'ਤੇ ਕੇਂਦਰਿਤ ਸਨ। ਸੰਸਕਰਣ 5.0 ਵਿੱਚ, ਲੋੜਾਂ ਸੁਰੱਖਿਆ ਟੀਚਿਆਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹਨ, ਅਤੇ ਖ਼ਾਸ ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਹਵਾਲਾ ਸਿਰਫ਼ ਉਦੋਂ ਦਿੰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਇੱਕੋ-ਇੱਕ ਵਿਹਾਰਕ ਹੱਲ ਹੋਣ, ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਉਦਾਹਰਨਾਂ ਜਾਂ ਪੂਰਕ ਮਾਰਗਦਰਸ਼ਨ ਵਜੋਂ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ। + +This approach recognizes that multiple methods may exist to achieve a given security objective, and avoids unnecessary prescriptiveness that could limit organizational flexibility. + +ਇਹ ਪਹੁੰਚ ਇਸ ਗੱਲ ਨੂੰ ਮਾਨਤਾ ਦਿੰਦੀ ਹੈ ਕਿ ਕਿਸੇ ਦਿੱਤੇ ਗਏ ਸੁਰੱਖਿਆ ਉਦੇਸ਼ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕਈ ਵਿਧੀਆਂ ਮੌਜੂਦ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਬੇਲੋੜੀ ਨਿਰਦੇਸ਼ਾਤਮਕਤਾ (prescriptiveness) ਤੋਂ ਬਚਦੀ ਹੈ ਜੋ ਸੰਸਥਾਗਤ ਲਚਕ ਨੂੰ ਸੀਮਤ ਕਰ ਸਕਦੀ ਹੈ। + +Additionally, requirements addressing the same security concern have been consolidated where appropriate. + +ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇੱਕੋ ਸੁਰੱਖਿਆ ਸਰੋਕਾਰ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਨ ਵਾਲੀਆਂ ਲੋੜਾਂ ਨੂੰ, ਜਿੱਥੇ ਢੁਕਵਾਂ ਸੀ, ਇਕੱਠਾ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ। + +### Documented Security Decisions +### ਦਸਤਾਵੇਜ਼ੀ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲੇ + +While the concept of documented security decisions may appear new in version 5.0, it is an evolution of earlier requirements related to policy application and threat modeling in version 4.0. Previously, some requirements implicitly demanded analysis to inform the implementation of security controls, such as determining permitted network connections. + +ਭਾਵੇਂ ਦਸਤਾਵੇਜ਼ੀ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਿਆਂ ਦਾ ਸੰਕਲਪ ਸੰਸਕਰਣ 5.0 ਵਿੱਚ ਨਵਾਂ ਜਾਪ ਸਕਦਾ ਹੈ, ਇਹ ਸੰਸਕਰਣ 4.0 ਵਿੱਚ ਨੀਤੀ ਲਾਗੂ ਕਰਨ ਅਤੇ ਖ਼ਤਰਾ ਮਾਡਲਿੰਗ (threat modeling) ਨਾਲ ਸੰਬੰਧਿਤ ਪਹਿਲੀਆਂ ਲੋੜਾਂ ਦਾ ਹੀ ਵਿਕਸਿਤ ਰੂਪ ਹੈ। ਪਹਿਲਾਂ, ਕੁਝ ਲੋੜਾਂ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣਾਂ ਦੇ ਲਾਗੂਕਰਨ ਨੂੰ ਸੇਧ ਦੇਣ ਲਈ ਅਸਿੱਧੇ ਤੌਰ 'ਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਮੰਗ ਕਰਦੀਆਂ ਸਨ, ਜਿਵੇਂ ਕਿ ਇਜਾਜ਼ਤ-ਪ੍ਰਾਪਤ ਨੈੱਟਵਰਕ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ। + +To ensure that necessary information is available for implementation and verification, these expectations are now explicitly defined as documentation requirements, making them clear, actionable, and verifiable. + +ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਲਾਗੂਕਰਨ ਅਤੇ ਤਸਦੀਕ ਲਈ ਜ਼ਰੂਰੀ ਜਾਣਕਾਰੀ ਉਪਲਬਧ ਹੋਵੇ, ਇਹਨਾਂ ਉਮੀਦਾਂ ਨੂੰ ਹੁਣ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਲੋੜਾਂ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਨਾਲ ਇਹ ਸਪੱਸ਼ਟ, ਕਾਰਜਯੋਗ ਅਤੇ ਤਸਦੀਕਯੋਗ ਬਣ ਗਈਆਂ ਹਨ। + +## Structural Changes and New Chapters +## ਢਾਂਚਾਗਤ ਤਬਦੀਲੀਆਂ ਅਤੇ ਨਵੇਂ ਅਧਿਆਇ + +Several chapters in version 5.0 introduce entirely new content: + +ਸੰਸਕਰਣ 5.0 ਦੇ ਕਈ ਅਧਿਆਇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਵੀਂ ਸਮੱਗਰੀ ਪੇਸ਼ ਕਰਦੇ ਹਨ: + +* OAuth and OIDC – Given the widespread adoption of these protocols for access delegation and single sign-on, dedicated requirements have been added to address the diverse scenarios developers may encounter. This area may eventually evolve into a standalone standard, similar to the treatment of Mobile and IoT requirements in previous versions. +* WebRTC – As this technology gains popularity, its unique security considerations and challenges are now addressed in a dedicated section. + +* OAuth ਅਤੇ OIDC – ਪਹੁੰਚ ਸੌਂਪਣ (access delegation) ਅਤੇ ਸਿੰਗਲ ਸਾਈਨ-ਔਨ ਲਈ ਇਹਨਾਂ ਪ੍ਰੋਟੋਕਾਲਾਂ ਦੇ ਵਿਆਪਕ ਅਪਣਾਏ ਜਾਣ ਨੂੰ ਦੇਖਦਿਆਂ, ਵਿਕਾਸਕਾਰਾਂ ਦੇ ਸਾਹਮਣੇ ਆ ਸਕਣ ਵਾਲੇ ਵੱਖ-ਵੱਖ ਹਾਲਾਤਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਨ ਲਈ ਸਮਰਪਿਤ ਲੋੜਾਂ ਜੋੜੀਆਂ ਗਈਆਂ ਹਨ। ਇਹ ਖੇਤਰ ਅੰਤ ਵਿੱਚ ਇੱਕ ਸੁਤੰਤਰ ਮਿਆਰ ਵਿੱਚ ਵਿਕਸਿਤ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਪਿਛਲੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਮੋਬਾਈਲ ਅਤੇ IoT ਲੋੜਾਂ ਨਾਲ ਕੀਤਾ ਗਿਆ ਸੀ। +* WebRTC – ਜਿਵੇਂ-ਜਿਵੇਂ ਇਹ ਤਕਨਾਲੋਜੀ ਪ੍ਰਸਿੱਧ ਹੋ ਰਹੀ ਹੈ, ਇਸ ਦੇ ਵਿਲੱਖਣ ਸੁਰੱਖਿਆ ਵਿਚਾਰਾਂ ਅਤੇ ਚੁਣੌਤੀਆਂ ਨੂੰ ਹੁਣ ਇੱਕ ਸਮਰਪਿਤ ਭਾਗ ਵਿੱਚ ਸੰਬੋਧਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। + +Efforts have also been made to ensure that chapters and sections are organized around coherent sets of related requirements. + +ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਵੀ ਯਤਨ ਕੀਤੇ ਗਏ ਹਨ ਕਿ ਅਧਿਆਇ ਅਤੇ ਭਾਗ ਸੰਬੰਧਿਤ ਲੋੜਾਂ ਦੇ ਸੁਸੰਗਤ ਸਮੂਹਾਂ ਦੁਆਲੇ ਸੰਗਠਿਤ ਹੋਣ। + +This restructuring has led to the creation of additional chapters: + +ਇਸ ਮੁੜ-ਸੰਰਚਨਾ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਵਾਧੂ ਅਧਿਆਇ ਬਣਾਏ ਗਏ ਹਨ: + +* Self-contained Tokens – Formerly grouped under session management, self-contained tokens are now recognized as a distinct mechanism and a foundational element for stateless communication (such as in OAuth and OIDC). Due to their unique security implications, they are addressed in a dedicated chapter, with some new requirements introduced in version 5.x. +* Web Frontend Security – With the increasing complexity of browser-based applications and the rise of API-only architectures, frontend security requirements have been separated into their own chapter. +* Secure Coding and Architecture – New requirements addressing general security practices that did not fit within existing chapters have been grouped here. + +* ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨ (Self-contained Tokens) – ਪਹਿਲਾਂ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਦੇ ਅਧੀਨ ਸਮੂਹਬੱਧ, ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨਾਂ ਨੂੰ ਹੁਣ ਇੱਕ ਵੱਖਰੀ ਪ੍ਰਣਾਲੀ ਅਤੇ ਸਟੇਟਲੈੱਸ (stateless) ਸੰਚਾਰ (ਜਿਵੇਂ ਕਿ OAuth ਅਤੇ OIDC ਵਿੱਚ) ਲਈ ਇੱਕ ਬੁਨਿਆਦੀ ਤੱਤ ਵਜੋਂ ਮਾਨਤਾ ਦਿੱਤੀ ਗਈ ਹੈ। ਉਹਨਾਂ ਦੇ ਵਿਲੱਖਣ ਸੁਰੱਖਿਆ ਪ੍ਰਭਾਵਾਂ ਕਾਰਨ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸਮਰਪਿਤ ਅਧਿਆਇ ਵਿੱਚ ਸੰਬੋਧਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਵਿੱਚ ਸੰਸਕਰਣ 5.x ਵਿੱਚ ਕੁਝ ਨਵੀਆਂ ਲੋੜਾਂ ਪੇਸ਼ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। +* ਵੈੱਬ ਫਰੰਟਐਂਡ ਸੁਰੱਖਿਆ (Web Frontend Security) – ਬ੍ਰਾਊਜ਼ਰ-ਆਧਾਰਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਵਧਦੀ ਗੁੰਝਲਤਾ ਅਤੇ ਸਿਰਫ਼-API ਆਰਕੀਟੈਕਚਰਾਂ ਦੇ ਉਭਾਰ ਦੇ ਨਾਲ, ਫਰੰਟਐਂਡ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਆਪਣੇ ਵੱਖਰੇ ਅਧਿਆਇ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਹੈ। +* ਸੁਰੱਖਿਅਤ ਕੋਡਿੰਗ ਅਤੇ ਆਰਕੀਟੈਕਚਰ (Secure Coding and Architecture) – ਆਮ ਸੁਰੱਖਿਆ ਅਮਲਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਨ ਵਾਲੀਆਂ ਨਵੀਆਂ ਲੋੜਾਂ, ਜੋ ਮੌਜੂਦਾ ਅਧਿਆਇਆਂ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਬੈਠਦੀਆਂ ਸਨ, ਇੱਥੇ ਸਮੂਹਬੱਧ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। + +Other organizational changes in version 5.0 were made to clarify intent. For example, input validation requirements were moved alongside business logic, reflecting their role in enforcing business rules, rather than being grouped with sanitization and encoding. + +ਸੰਸਕਰਣ 5.0 ਵਿੱਚ ਹੋਰ ਸੰਗਠਨਾਤਮਕ ਤਬਦੀਲੀਆਂ ਇਰਾਦੇ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਲਈ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ। ਉਦਾਹਰਨ ਲਈ, ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ (input validation) ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਕਾਰੋਬਾਰੀ ਤਰਕ ਦੇ ਨਾਲ ਲਿਜਾਇਆ ਗਿਆ, ਜੋ ਕਾਰੋਬਾਰੀ ਨਿਯਮਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਭੂਮਿਕਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਉਹਨਾਂ ਨੂੰ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਏਨਕੋਡਿੰਗ ਨਾਲ ਸਮੂਹਬੱਧ ਰੱਖਿਆ ਗਿਆ। + +The former V1 Architecture chapter has been removed. Its initial section contained requirements that were out of scope, while subsequent sections have been redistributed to relevant chapters, with requirements deduplicated and clarified as necessary. + +ਪੁਰਾਣੇ V1 ਆਰਕੀਟੈਕਚਰ ਅਧਿਆਇ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਇਸ ਦੇ ਸ਼ੁਰੂਆਤੀ ਭਾਗ ਵਿੱਚ ਅਜਿਹੀਆਂ ਲੋੜਾਂ ਸਨ ਜੋ ਘੇਰੇ ਤੋਂ ਬਾਹਰ ਸਨ, ਜਦਕਿ ਬਾਅਦ ਵਾਲੇ ਭਾਗਾਂ ਨੂੰ ਸੰਬੰਧਿਤ ਅਧਿਆਇਆਂ ਵਿੱਚ ਮੁੜ-ਵੰਡ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਲੋੜਾਂ ਵਿੱਚੋਂ ਦੁਹਰਾਅ ਹਟਾ ਕੇ ਉਹਨਾਂ ਨੂੰ ਜ਼ਰੂਰਤ ਅਨੁਸਾਰ ਸਪੱਸ਼ਟ ਕੀਤਾ ਗਿਆ ਹੈ। + +## Removal of Direct Mappings to Other Standards +## ਹੋਰ ਮਿਆਰਾਂ ਨਾਲ ਸਿੱਧੀਆਂ ਮੈਪਿੰਗਾਂ ਦਾ ਹਟਾਇਆ ਜਾਣਾ + +Direct mappings to other standards have been removed from the main body of the standard. The aim is to prepare a mapping with the OWASP Common Requirement Enumeration (CRE) project, which in turn will link ASVS to a range of OWASP projects and external standards. + +ਮਿਆਰ ਦੇ ਮੁੱਖ ਭਾਗ ਵਿੱਚੋਂ ਹੋਰ ਮਿਆਰਾਂ ਨਾਲ ਸਿੱਧੀਆਂ ਮੈਪਿੰਗਾਂ ਹਟਾ ਦਿੱਤੀਆਂ ਗਈਆਂ ਹਨ। ਉਦੇਸ਼ OWASP Common Requirement Enumeration (CRE) ਪ੍ਰੋਜੈਕਟ ਨਾਲ ਇੱਕ ਮੈਪਿੰਗ ਤਿਆਰ ਕਰਨਾ ਹੈ, ਜੋ ਅੱਗੇ ASVS ਨੂੰ OWASP ਪ੍ਰੋਜੈਕਟਾਂ ਅਤੇ ਬਾਹਰੀ ਮਿਆਰਾਂ ਦੀ ਇੱਕ ਲੜੀ ਨਾਲ ਜੋੜੇਗੀ। + +Direct mappings to CWE and NIST are no longer maintained, as explained below. + +CWE ਅਤੇ NIST ਨਾਲ ਸਿੱਧੀਆਂ ਮੈਪਿੰਗਾਂ ਹੁਣ ਕਾਇਮ ਨਹੀਂ ਰੱਖੀਆਂ ਜਾਂਦੀਆਂ, ਜਿਵੇਂ ਕਿ ਹੇਠਾਂ ਸਮਝਾਇਆ ਗਿਆ ਹੈ। + +### Reduced Coupling with NIST Digital Identity Guidelines +### NIST ਡਿਜੀਟਲ ਪਛਾਣ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਾਂ ਨਾਲ ਘਟਾਇਆ ਗਿਆ ਜੋੜ + +The NIST [Digital Identity Guidelines (SP 800-63)](https://pages.nist.gov/800-63-3/) have long served as a reference for authentication and authorization controls. In version 4.x, certain chapters were closely aligned with NIST's structure and terminology. + +NIST [Digital Identity Guidelines (SP 800-63)](https://pages.nist.gov/800-63-3/) ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਅਧਿਕਾਰੀਕਰਨ ਨਿਯੰਤਰਣਾਂ ਲਈ ਇੱਕ ਹਵਾਲੇ ਵਜੋਂ ਕੰਮ ਕਰਦੇ ਆਏ ਹਨ। ਸੰਸਕਰਣ 4.x ਵਿੱਚ, ਕੁਝ ਅਧਿਆਇ NIST ਦੀ ਬਣਤਰ ਅਤੇ ਸ਼ਬਦਾਵਲੀ ਨਾਲ ਨੇੜਿਓਂ ਜੁੜੇ ਹੋਏ ਸਨ। + +While these guidelines remain an important reference, strict alignment introduced challenges, including less widely recognized terminology, duplication of similar requirements, and incomplete mappings. Version 5.0 moves away from this approach to improve clarity and relevance. + +ਭਾਵੇਂ ਇਹ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਵਾਲਾ ਬਣੇ ਰਹਿੰਦੇ ਹਨ, ਸਖ਼ਤ ਇਕਸਾਰਤਾ ਨੇ ਚੁਣੌਤੀਆਂ ਪੈਦਾ ਕੀਤੀਆਂ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਘੱਟ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਮਾਨਤਾ-ਪ੍ਰਾਪਤ ਸ਼ਬਦਾਵਲੀ, ਮਿਲਦੀਆਂ-ਜੁਲਦੀਆਂ ਲੋੜਾਂ ਦਾ ਦੁਹਰਾਅ, ਅਤੇ ਅਧੂਰੀਆਂ ਮੈਪਿੰਗਾਂ ਸ਼ਾਮਲ ਹਨ। ਸੰਸਕਰਣ 5.0 ਸਪੱਸ਼ਟਤਾ ਅਤੇ ਪ੍ਰਸੰਗਿਕਤਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਇਸ ਪਹੁੰਚ ਤੋਂ ਦੂਰ ਜਾਂਦਾ ਹੈ। + +### Moving Away from Common Weakness Enumeration (CWE) +### Common Weakness Enumeration (CWE) ਤੋਂ ਦੂਰ ਜਾਣਾ + +The [Common Weakness Enumeration (CWE)](https://cwe.mitre.org/) provides a useful taxonomy of software security weaknesses. However, challenges such as category-only CWEs, difficulties in mapping requirements to a single CWE, and the presence of imprecise mappings in version 4.x have led to the decision to discontinue direct CWE mappings in version 5.0. + +[Common Weakness Enumeration (CWE)](https://cwe.mitre.org/) ਸਾਫ਼ਟਵੇਅਰ ਸੁਰੱਖਿਆ ਖ਼ਾਮੀਆਂ (weaknesses) ਦਾ ਇੱਕ ਲਾਭਦਾਇਕ ਵਰਗੀਕਰਨ (taxonomy) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਸਿਰਫ਼-ਸ਼੍ਰੇਣੀ ਵਾਲੇ CWE, ਲੋੜਾਂ ਨੂੰ ਕਿਸੇ ਇੱਕ CWE ਨਾਲ ਮੈਪ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲਾਂ, ਅਤੇ ਸੰਸਕਰਣ 4.x ਵਿੱਚ ਅਸ਼ੁੱਧ ਮੈਪਿੰਗਾਂ ਦੀ ਮੌਜੂਦਗੀ ਵਰਗੀਆਂ ਚੁਣੌਤੀਆਂ ਕਾਰਨ ਸੰਸਕਰਣ 5.0 ਵਿੱਚ ਸਿੱਧੀਆਂ CWE ਮੈਪਿੰਗਾਂ ਨੂੰ ਬੰਦ ਕਰਨ ਦਾ ਫ਼ੈਸਲਾ ਲਿਆ ਗਿਆ ਹੈ। + +## Rethinking Level Definitions +## ਪੱਧਰ ਪਰਿਭਾਸ਼ਾਵਾਂ 'ਤੇ ਮੁੜ-ਵਿਚਾਰ + +Version 4.x described the levels as L1 ("Minimum"), L2 ("Standard"), and L3 ("Advanced"), with the implication that all applications handling sensitive data should meet at least L2. + +ਸੰਸਕਰਣ 4.x ਨੇ ਪੱਧਰਾਂ ਨੂੰ L1 ("ਘੱਟੋ-ਘੱਟ", Minimum), L2 ("ਮਿਆਰੀ", Standard), ਅਤੇ L3 ("ਉੱਨਤ", Advanced) ਵਜੋਂ ਵਰਣਿਤ ਕੀਤਾ ਸੀ, ਇਸ ਸੰਕੇਤ ਦੇ ਨਾਲ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਸੰਭਾਲਣ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਘੱਟੋ-ਘੱਟ L2 ਪੂਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। + +Version 5.0 addresses several issues with this approach which are described in the following paragraphs. + +ਸੰਸਕਰਣ 5.0 ਇਸ ਪਹੁੰਚ ਨਾਲ ਜੁੜੇ ਕਈ ਮੁੱਦਿਆਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਦਾ ਵਰਣਨ ਅਗਲੇ ਪੈਰਿਆਂ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਹੈ। + +As a practical matter, whereas version 4.x used tick marks for level indicators, 5.x uses a simple number on all formats of the standard including markdown, PDF, DOCX, CSV, JSON and XML. For backwards compatibility, legacy versions of the CSV, JSON and XML outputs which still use tick marks are also generated. + +ਵਿਹਾਰਕ ਤੌਰ 'ਤੇ, ਜਿੱਥੇ ਸੰਸਕਰਣ 4.x ਪੱਧਰ ਸੂਚਕਾਂ ਲਈ ਟਿੱਕ ਚਿੰਨ੍ਹ ਵਰਤਦਾ ਸੀ, ਉੱਥੇ 5.x ਮਿਆਰ ਦੇ ਸਾਰੇ ਫਾਰਮੈਟਾਂ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ markdown, PDF, DOCX, CSV, JSON ਅਤੇ XML ਸ਼ਾਮਲ ਹਨ, ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਅੰਕ ਵਰਤਦਾ ਹੈ। ਪਿਛਲੀ ਅਨੁਕੂਲਤਾ (backwards compatibility) ਲਈ, CSV, JSON ਅਤੇ XML ਆਊਟਪੁੱਟਾਂ ਦੇ ਪੁਰਾਣੇ (legacy) ਸੰਸਕਰਣ, ਜੋ ਅਜੇ ਵੀ ਟਿੱਕ ਚਿੰਨ੍ਹ ਵਰਤਦੇ ਹਨ, ਵੀ ਤਿਆਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। + +### Easier Entry Level +### ਸੌਖਾ ਪ੍ਰਵੇਸ਼ ਪੱਧਰ + +Feedback indicated that the large number of Level 1 requirements (~120), combined with its designation as the "minimum" level that is not good enough for most applications, discouraged adoption. Version 5.0 aims to lower this barrier by defining Level 1 primarily around first-layer defense requirements, resulting in clearer and fewer requirements at that level. To demonstrate this numerically, in v4.0.3 there were 128 L1 requirements out of a total of 278 requirements, representing 46%. In 5.0.0 there are 70 L1 requirements out of a total of 345 requirements, representing 20%. + +ਫ਼ੀਡਬੈਕ ਨੇ ਸੰਕੇਤ ਦਿੱਤਾ ਕਿ ਪੱਧਰ 1 ਦੀਆਂ ਲੋੜਾਂ ਦੀ ਵੱਡੀ ਗਿਣਤੀ (~120), ਇਸ ਦੇ "ਘੱਟੋ-ਘੱਟ" ਪੱਧਰ ਵਜੋਂ ਨਾਮਕਰਨ ਦੇ ਨਾਲ ਮਿਲ ਕੇ — ਜੋ ਜ਼ਿਆਦਾਤਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਕਾਫ਼ੀ ਚੰਗਾ ਨਹੀਂ ਹੈ — ਅਪਣਾਏ ਜਾਣ ਨੂੰ ਨਿਰਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਸੀ। ਸੰਸਕਰਣ 5.0 ਦਾ ਉਦੇਸ਼ ਪੱਧਰ 1 ਨੂੰ ਮੁੱਖ ਤੌਰ 'ਤੇ ਪਹਿਲੀ-ਪਰਤ ਰੱਖਿਆ ਲੋੜਾਂ ਦੁਆਲੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਕੇ ਇਸ ਰੁਕਾਵਟ ਨੂੰ ਘਟਾਉਣਾ ਹੈ, ਜਿਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਉਸ ਪੱਧਰ 'ਤੇ ਵਧੇਰੇ ਸਪੱਸ਼ਟ ਅਤੇ ਘੱਟ ਲੋੜਾਂ ਹਨ। ਇਸ ਨੂੰ ਅੰਕੜਿਆਂ ਵਿੱਚ ਦਰਸਾਉਣ ਲਈ, v4.0.3 ਵਿੱਚ ਕੁੱਲ 278 ਲੋੜਾਂ ਵਿੱਚੋਂ 128 L1 ਲੋੜਾਂ ਸਨ, ਜੋ 46% ਬਣਦੀਆਂ ਹਨ। 5.0.0 ਵਿੱਚ ਕੁੱਲ 345 ਲੋੜਾਂ ਵਿੱਚੋਂ 70 L1 ਲੋੜਾਂ ਹਨ, ਜੋ 20% ਬਣਦੀਆਂ ਹਨ। + +### The Fallacy of Testability +### ਟੈਸਟਯੋਗਤਾ ਦਾ ਭੁਲੇਖਾ + +A key factor in selecting controls for Level 1 in version 4.x was their suitability for assessment through "black box" external penetration testing. However, this approach was not fully aligned with the intent of Level 1 as the minimum set of security controls. Some users argued that Level 1 was insufficient for securing applications, while others found it too difficult to test. + +ਸੰਸਕਰਣ 4.x ਵਿੱਚ ਪੱਧਰ 1 ਲਈ ਨਿਯੰਤਰਣ ਚੁਣਨ ਵਿੱਚ ਇੱਕ ਮੁੱਖ ਕਾਰਕ "ਬਲੈਕ ਬਾਕਸ" ਬਾਹਰੀ ਪੈਨੇਟ੍ਰੇਸ਼ਨ ਟੈਸਟਿੰਗ (penetration testing) ਰਾਹੀਂ ਮੁਲਾਂਕਣ ਲਈ ਉਹਨਾਂ ਦੀ ਅਨੁਕੂਲਤਾ ਸੀ। ਹਾਲਾਂਕਿ, ਇਹ ਪਹੁੰਚ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣਾਂ ਦੇ ਘੱਟੋ-ਘੱਟ ਸਮੂਹ ਵਜੋਂ ਪੱਧਰ 1 ਦੇ ਇਰਾਦੇ ਨਾਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ ਸੀ। ਕੁਝ ਵਰਤੋਂਕਾਰਾਂ ਨੇ ਦਲੀਲ ਦਿੱਤੀ ਕਿ ਪੱਧਰ 1 ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਨਾਕਾਫ਼ੀ ਸੀ, ਜਦਕਿ ਹੋਰਾਂ ਨੂੰ ਇਸ ਦੀ ਟੈਸਟਿੰਗ ਬਹੁਤ ਮੁਸ਼ਕਲ ਲੱਗੀ। + +Relying on testability as a criterion is both relative and, at times, misleading. The fact that a requirement is testable does not guarantee that it can be tested in an automated or straightforward manner. Moreover, the most easily testable requirements are not always those with the greatest security impact or the simplest to implement. + +ਟੈਸਟਯੋਗਤਾ (testability) 'ਤੇ ਇੱਕ ਕਸੌਟੀ ਵਜੋਂ ਨਿਰਭਰ ਕਰਨਾ ਸਾਪੇਖਿਕ ਵੀ ਹੈ ਅਤੇ, ਕਈ ਵਾਰ, ਗੁਮਰਾਹਕੁੰਨ ਵੀ। ਇਹ ਤੱਥ ਕਿ ਕੋਈ ਲੋੜ ਟੈਸਟਯੋਗ ਹੈ, ਇਸ ਗੱਲ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਕਿ ਇਸ ਦੀ ਟੈਸਟਿੰਗ ਸਵੈਚਾਲਿਤ ਜਾਂ ਸਿੱਧੇ-ਸਾਦੇ ਢੰਗ ਨਾਲ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਭ ਤੋਂ ਸੌਖਿਆਂ ਟੈਸਟਯੋਗ ਲੋੜਾਂ ਹਮੇਸ਼ਾ ਉਹ ਨਹੀਂ ਹੁੰਦੀਆਂ ਜਿਨ੍ਹਾਂ ਦਾ ਸੁਰੱਖਿਆ ਪ੍ਰਭਾਵ ਸਭ ਤੋਂ ਵੱਧ ਹੋਵੇ ਜਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸਭ ਤੋਂ ਸਰਲ ਹੋਵੇ। + +As such, in version 5.0, the level decisions were made primarily based on risk reduction and also keeping in mind the effort to implement. + +ਇਸ ਲਈ, ਸੰਸਕਰਣ 5.0 ਵਿੱਚ, ਪੱਧਰ ਦੇ ਫ਼ੈਸਲੇ ਮੁੱਖ ਤੌਰ 'ਤੇ ਜੋਖਮ ਘਟਾਉਣ ਦੇ ਆਧਾਰ 'ਤੇ ਲਏ ਗਏ ਸਨ, ਅਤੇ ਨਾਲ ਹੀ ਲਾਗੂ ਕਰਨ ਦੇ ਯਤਨ ਨੂੰ ਵੀ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਸੀ। + +### Not Just About Risk +### ਸਿਰਫ਼ ਜੋਖਮ ਦੀ ਗੱਲ ਨਹੀਂ + +The use of prescriptive, risk-based levels that mandate a specific level for certain applications has proven to be overly rigid. In practice, the prioritization and implementation of security controls depend on multiple factors, including both risk reduction and the effort required for implementation. + +ਨਿਰਦੇਸ਼ਾਤਮਕ, ਜੋਖਮ-ਆਧਾਰਿਤ ਪੱਧਰਾਂ ਦੀ ਵਰਤੋਂ, ਜੋ ਕੁਝ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਇੱਕ ਖ਼ਾਸ ਪੱਧਰ ਨੂੰ ਲਾਜ਼ਮੀ ਬਣਾਉਂਦੇ ਹਨ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਖ਼ਤ ਸਾਬਤ ਹੋਈ ਹੈ। ਅਮਲ ਵਿੱਚ, ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣਾਂ ਦੀ ਤਰਜੀਹ ਅਤੇ ਲਾਗੂਕਰਨ ਕਈ ਕਾਰਕਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਜੋਖਮ ਘਟਾਉਣਾ ਅਤੇ ਲਾਗੂਕਰਨ ਲਈ ਲੋੜੀਂਦਾ ਯਤਨ ਦੋਵੇਂ ਸ਼ਾਮਲ ਹਨ। + +Therefore, organizations are encouraged to achieve the level that they feel like they should be achieving based on their maturity and the message they want to send to their users. + +ਇਸ ਲਈ, ਸੰਸਥਾਵਾਂ ਨੂੰ ਉਹ ਪੱਧਰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਉਹਨਾਂ ਨੂੰ ਆਪਣੀ ਪਰਿਪੱਕਤਾ ਅਤੇ ਉਸ ਸੰਦੇਸ਼ ਦੇ ਆਧਾਰ 'ਤੇ, ਜੋ ਉਹ ਆਪਣੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਦੇਣਾ ਚਾਹੁੰਦੀਆਂ ਹਨ, ਲੱਗਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। diff --git a/5.0/pa-IN/0x10-V1-Encoding-and-Sanitization.md b/5.0/pa-IN/0x10-V1-Encoding-and-Sanitization.md new file mode 100644 index 0000000000..f35591af46 --- /dev/null +++ b/5.0/pa-IN/0x10-V1-Encoding-and-Sanitization.md @@ -0,0 +1,190 @@ + + + + +# V1 Encoding and Sanitization +# V1 ਏਨਕੋਡਿੰਗ ਅਤੇ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +This chapter addresses the most common web application security weaknesses related to the unsafe processing of untrusted data. Such weaknesses can result in various technical vulnerabilities, where untrusted data is interpreted according to the syntax rules of the relevant interpreter. + +ਇਹ ਅਧਿਆਇ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਡਾਟੇ (untrusted data) ਦੀ ਅਸੁਰੱਖਿਅਤ ਪ੍ਰੋਸੈਸਿੰਗ ਨਾਲ ਸੰਬੰਧਿਤ ਸਭ ਤੋਂ ਆਮ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਖ਼ਾਮੀਆਂ (weaknesses) ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ। ਅਜਿਹੀਆਂ ਖ਼ਾਮੀਆਂ ਵੱਖ-ਵੱਖ ਤਕਨੀਕੀ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀਆਂ ਹਨ, ਜਿੱਥੇ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਡਾਟੇ ਦੀ ਵਿਆਖਿਆ ਸੰਬੰਧਿਤ ਇੰਟਰਪ੍ਰੇਟਰ (interpreter) ਦੇ ਸਿੰਟੈਕਸ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। + +For modern web applications, it is always best to use safer APIs, such as parameterized queries, auto-escaping, or templating frameworks. Otherwise, carefully performed output encoding, escaping, or sanitization becomes critical to the application's security. + +ਆਧੁਨਿਕ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ, ਹਮੇਸ਼ਾ ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ API ਵਰਤਣਾ ਸਭ ਤੋਂ ਚੰਗਾ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਪੈਰਾਮੀਟਰਾਈਜ਼ਡ ਕਿਊਰੀਆਂ (parameterized queries), ਸਵੈ-ਐਸਕੇਪਿੰਗ (auto-escaping), ਜਾਂ ਟੈਂਪਲੇਟਿੰਗ ਫ੍ਰੇਮਵਰਕ। ਨਹੀਂ ਤਾਂ, ਧਿਆਨ ਨਾਲ ਕੀਤੀ ਗਈ ਆਊਟਪੁੱਟ ਏਨਕੋਡਿੰਗ (output encoding), ਐਸਕੇਪਿੰਗ (escaping), ਜਾਂ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ (sanitization) ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਅਤਿ ਮਹੱਤਵਪੂਰਨ ਬਣ ਜਾਂਦੀ ਹੈ। + +Input validation serves as a defense-in-depth mechanism to protect against unexpected or dangerous content. However, since its primary purpose is to ensure that incoming content matches functional and business expectations, requirements related to this can be found in the "Validation and Business Logic" chapter. + +ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ (input validation) ਅਣਕਿਆਸੀ ਜਾਂ ਖ਼ਤਰਨਾਕ ਸਮੱਗਰੀ ਤੋਂ ਬਚਾਅ ਲਈ ਇੱਕ ਡੂੰਘਾਈ-ਵਿੱਚ-ਰੱਖਿਆ (defense-in-depth) ਪ੍ਰਣਾਲੀ ਵਜੋਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਕਿਉਂਕਿ ਇਸ ਦਾ ਮੁੱਖ ਉਦੇਸ਼ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਆਉਣ ਵਾਲੀ ਸਮੱਗਰੀ ਕਾਰਜਾਤਮਕ ਅਤੇ ਕਾਰੋਬਾਰੀ ਉਮੀਦਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਇਸ ਨਾਲ ਸੰਬੰਧਿਤ ਲੋੜਾਂ "ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਕਾਰੋਬਾਰੀ ਤਰਕ" (Validation and Business Logic) ਅਧਿਆਇ ਵਿੱਚ ਮਿਲ ਸਕਦੀਆਂ ਹਨ। + +## V1.1 Encoding and Sanitization Architecture +## V1.1 ਏਨਕੋਡਿੰਗ ਅਤੇ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ ਢਾਂਚਾ + +In the sections below, syntax-specific or interpreter-specific requirements for safely processing unsafe content to avoid security vulnerabilities are provided. The requirements in this section cover the order in which this processing should occur and where it should take place. They also aim to ensure that whenever data is stored, it remains in its original state and is not stored in an encoded or escaped form (e.g., HTML encoding), to prevent double encoding issues. + +ਹੇਠਲੇ ਭਾਗਾਂ ਵਿੱਚ, ਸੁਰੱਖਿਆ ਕਮਜ਼ੋਰੀਆਂ ਤੋਂ ਬਚਣ ਲਈ ਅਸੁਰੱਖਿਅਤ ਸਮੱਗਰੀ ਦੀ ਸੁਰੱਖਿਅਤ ਪ੍ਰੋਸੈਸਿੰਗ ਵਾਸਤੇ ਸਿੰਟੈਕਸ-ਵਿਸ਼ੇਸ਼ ਜਾਂ ਇੰਟਰਪ੍ਰੇਟਰ-ਵਿਸ਼ੇਸ਼ ਲੋੜਾਂ ਦਿੱਤੀਆਂ ਗਈਆਂ ਹਨ। ਇਸ ਭਾਗ ਦੀਆਂ ਲੋੜਾਂ ਉਸ ਕ੍ਰਮ ਨੂੰ ਕਵਰ ਕਰਦੀਆਂ ਹਨ ਜਿਸ ਵਿੱਚ ਇਹ ਪ੍ਰੋਸੈਸਿੰਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਇਹ ਕਿੱਥੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਹਨਾਂ ਦਾ ਉਦੇਸ਼ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਵੀ ਹੈ ਕਿ ਜਦੋਂ ਵੀ ਡਾਟਾ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇ, ਇਹ ਆਪਣੀ ਮੂਲ ਸਥਿਤੀ ਵਿੱਚ ਰਹੇ ਅਤੇ ਏਨਕੋਡ ਕੀਤੇ ਜਾਂ ਐਸਕੇਪ ਕੀਤੇ ਰੂਪ (ਜਿਵੇਂ, HTML ਏਨਕੋਡਿੰਗ) ਵਿੱਚ ਸਟੋਰ ਨਾ ਕੀਤਾ ਜਾਵੇ, ਤਾਂ ਜੋ ਦੋਹਰੀ ਏਨਕੋਡਿੰਗ (double encoding) ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **1.1.1** | Verify that input is decoded or unescaped into a canonical form only once, it is only decoded when encoded data in that form is expected, and that this is done before processing the input further, for example it is not performed after input validation or sanitization. | 2 | +| **1.1.2** | Verify that the application performs output encoding and escaping either as a final step before being used by the interpreter for which it is intended or by the interpreter itself. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **1.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਇਨਪੁੱਟ ਨੂੰ ਕੈਨੋਨੀਕਲ ਰੂਪ (canonical form) ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਡੀਕੋਡ ਜਾਂ ਅਨਐਸਕੇਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਨੂੰ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਡੀਕੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਉਸ ਰੂਪ ਵਿੱਚ ਏਨਕੋਡ ਕੀਤੇ ਡਾਟੇ ਦੀ ਉਮੀਦ ਹੋਵੇ, ਅਤੇ ਇਹ ਇਨਪੁੱਟ ਦੀ ਅਗਲੀ ਪ੍ਰੋਸੈਸਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ ਇਹ ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ। | 2 | +| **1.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਆਊਟਪੁੱਟ ਏਨਕੋਡਿੰਗ ਅਤੇ ਐਸਕੇਪਿੰਗ ਜਾਂ ਤਾਂ ਉਸ ਇੰਟਰਪ੍ਰੇਟਰ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਅੰਤਮ ਕਦਮ ਵਜੋਂ ਕਰਦੀ ਹੈ ਜਿਸ ਲਈ ਇਹ ਨਿਰਧਾਰਿਤ ਹੈ, ਜਾਂ ਇਹ ਇੰਟਰਪ੍ਰੇਟਰ ਦੁਆਰਾ ਖ਼ੁਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। | 2 | + +## V1.2 Injection Prevention +## V1.2 ਇੰਜੈਕਸ਼ਨ ਰੋਕਥਾਮ + +Output encoding or escaping, performed close to or adjacent to a potentially dangerous context, is critical to the security of any application. Typically, output encoding and escaping are not persisted, but are instead used to render output safe for immediate use in the appropriate interpreter. Attempting to perform this too early may result in malformed content or render the encoding or escaping ineffective. + +ਆਊਟਪੁੱਟ ਏਨਕੋਡਿੰਗ ਜਾਂ ਐਸਕੇਪਿੰਗ, ਜੋ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਖ਼ਤਰਨਾਕ ਸੰਦਰਭ ਦੇ ਨੇੜੇ ਜਾਂ ਨਾਲ ਲੱਗਦੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਕਿਸੇ ਵੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਅਤਿ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਆਊਟਪੁੱਟ ਏਨਕੋਡਿੰਗ ਅਤੇ ਐਸਕੇਪਿੰਗ ਨੂੰ ਸਥਾਈ ਤੌਰ 'ਤੇ ਸੰਭਾਲਿਆ ਨਹੀਂ ਜਾਂਦਾ, ਸਗੋਂ ਇਹਨਾਂ ਦੀ ਵਰਤੋਂ ਢੁਕਵੇਂ ਇੰਟਰਪ੍ਰੇਟਰ ਵਿੱਚ ਤੁਰੰਤ ਵਰਤੋਂ ਲਈ ਆਊਟਪੁੱਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣ ਵਾਸਤੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਨੂੰ ਬਹੁਤ ਜਲਦੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਵਿਗੜੀ ਹੋਈ ਸਮੱਗਰੀ ਪੈਦਾ ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਏਨਕੋਡਿੰਗ ਜਾਂ ਐਸਕੇਪਿੰਗ ਬੇਅਸਰ ਹੋ ਸਕਦੀ ਹੈ। + +In many cases, software libraries include safe or safer functions that perform this automatically, although it is necessary to ensure that they are correct for the current context. + +ਕਈ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਸਾਫ਼ਟਵੇਅਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਜਾਂ ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਫੰਕਸ਼ਨ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਜੋ ਇਹ ਆਪਣੇ ਆਪ ਕਰਦੇ ਹਨ, ਹਾਲਾਂਕਿ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਉਹ ਮੌਜੂਦਾ ਸੰਦਰਭ ਲਈ ਸਹੀ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **1.2.1** | Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure. | 1 | +| **1.2.2** | Verify that when dynamically building URLs, untrusted data is encoded according to its context (e.g., URL encoding or base64url encoding for query or path parameters). Ensure that only safe URL protocols are permitted (e.g., disallow javascript: or data:). | 1 | +| **1.2.3** | Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure (to avoid JavaScript and JSON injection). | 1 | +| **1.2.4** | Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This is also relevant when writing stored procedures. | 1 | +| **1.2.5** | Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. | 1 | +| **1.2.6** | Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. | 2 | +| **1.2.7** | Verify that the application is protected against XPath injection attacks by using query parameterization or precompiled queries. | 2 | +| **1.2.8** | Verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) and an allowlist of commands is used to prevent LaTeX injection attacks. | 2 | +| **1.2.9** | Verify that the application escapes special characters in regular expressions (typically using a backslash) to prevent them from being misinterpreted as metacharacters. | 2 | +| **1.2.10** | Verify that the application is protected against CSV and Formula Injection. The application must follow the escaping rules defined in RFC 4180 sections 2.6 and 2.7 when exporting CSV content. Additionally, when exporting to CSV or other spreadsheet formats (such as XLS, XLSX, or ODF), special characters (including '=', '+', '-', '@', '\t' (tab), and '\0' (null character)) must be escaped with a single quote if they appear as the first character in a field value. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **1.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ HTTP ਜਵਾਬ, HTML ਦਸਤਾਵੇਜ਼, ਜਾਂ XML ਦਸਤਾਵੇਜ਼ ਲਈ ਆਊਟਪੁੱਟ ਏਨਕੋਡਿੰਗ ਲੋੜੀਂਦੇ ਸੰਦਰਭ ਲਈ ਢੁਕਵੀਂ ਹੈ, ਜਿਵੇਂ ਕਿ HTML ਐਲੀਮੈਂਟਾਂ, HTML ਐਟ੍ਰੀਬਿਊਟਾਂ, HTML ਟਿੱਪਣੀਆਂ, CSS, ਜਾਂ HTTP ਹੈਡਰ ਫ਼ੀਲਡਾਂ ਲਈ ਸੰਬੰਧਿਤ ਅੱਖਰਾਂ ਨੂੰ ਏਨਕੋਡ ਕਰਨਾ, ਤਾਂ ਜੋ ਸੁਨੇਹੇ ਜਾਂ ਦਸਤਾਵੇਜ਼ ਦੀ ਬਣਤਰ ਵਿੱਚ ਤਬਦੀਲੀ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ। | 1 | +| **1.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ URL ਬਣਾਉਂਦੇ ਸਮੇਂ, ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਡਾਟੇ ਨੂੰ ਉਸ ਦੇ ਸੰਦਰਭ ਅਨੁਸਾਰ ਏਨਕੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਜਿਵੇਂ, ਕਿਊਰੀ ਜਾਂ ਪਾਥ ਪੈਰਾਮੀਟਰਾਂ ਲਈ URL ਏਨਕੋਡਿੰਗ ਜਾਂ base64url ਏਨਕੋਡਿੰਗ)। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਿਰਫ਼ ਸੁਰੱਖਿਅਤ URL ਪ੍ਰੋਟੋਕਾਲਾਂ ਦੀ ਇਜਾਜ਼ਤ ਹੈ (ਜਿਵੇਂ, javascript: ਜਾਂ data: ਦੀ ਮਨਾਹੀ ਕਰੋ)। | 1 | +| **1.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ JavaScript ਸਮੱਗਰੀ (JSON ਸਮੇਤ) ਬਣਾਉਂਦੇ ਸਮੇਂ ਆਊਟਪੁੱਟ ਏਨਕੋਡਿੰਗ ਜਾਂ ਐਸਕੇਪਿੰਗ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਜੋ ਸੁਨੇਹੇ ਜਾਂ ਦਸਤਾਵੇਜ਼ ਦੀ ਬਣਤਰ ਵਿੱਚ ਤਬਦੀਲੀ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ (JavaScript ਅਤੇ JSON ਇੰਜੈਕਸ਼ਨ ਤੋਂ ਬਚਣ ਲਈ)। | 1 | +| **1.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਡਾਟਾ ਚੋਣ ਜਾਂ ਡਾਟਾਬੇਸ ਕਿਊਰੀਆਂ (ਜਿਵੇਂ, SQL, HQL, NoSQL, Cypher) ਪੈਰਾਮੀਟਰਾਈਜ਼ਡ ਕਿਊਰੀਆਂ, ORM, ਐਂਟਿਟੀ ਫ੍ਰੇਮਵਰਕ ਵਰਤਦੀਆਂ ਹਨ, ਜਾਂ ਕਿਸੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ SQL ਇੰਜੈਕਸ਼ਨ ਅਤੇ ਹੋਰ ਡਾਟਾਬੇਸ ਇੰਜੈਕਸ਼ਨ ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹਨ। ਇਹ ਸਟੋਰਡ ਪ੍ਰੋਸੀਜਰ (stored procedures) ਲਿਖਦੇ ਸਮੇਂ ਵੀ ਢੁਕਵਾਂ ਹੈ। | 1 | +| **1.2.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ OS ਕਮਾਂਡ ਇੰਜੈਕਸ਼ਨ ਤੋਂ ਬਚਾਅ ਕਰਦੀ ਹੈ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਕਾਲਾਂ ਪੈਰਾਮੀਟਰਾਈਜ਼ਡ OS ਕਿਊਰੀਆਂ ਵਰਤਦੀਆਂ ਹਨ ਜਾਂ ਸੰਦਰਭੀ ਕਮਾਂਡ ਲਾਈਨ ਆਊਟਪੁੱਟ ਏਨਕੋਡਿੰਗ ਵਰਤਦੀਆਂ ਹਨ। | 1 | +| **1.2.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ LDAP ਇੰਜੈਕਸ਼ਨ ਕਮਜ਼ੋਰੀਆਂ ਤੋਂ ਬਚਾਅ ਕਰਦੀ ਹੈ, ਜਾਂ LDAP ਇੰਜੈਕਸ਼ਨ ਨੂੰ ਰੋਕਣ ਲਈ ਖ਼ਾਸ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਲਾਗੂ ਕੀਤੇ ਗਏ ਹਨ। | 2 | +| **1.2.7** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕਿਊਰੀ ਪੈਰਾਮੀਟਰਾਈਜ਼ੇਸ਼ਨ ਜਾਂ ਪਹਿਲਾਂ ਤੋਂ ਕੰਪਾਈਲ ਕੀਤੀਆਂ ਕਿਊਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ XPath ਇੰਜੈਕਸ਼ਨ ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੈ। | 2 | +| **1.2.8** | ਤਸਦੀਕ ਕਰੋ ਕਿ LaTeX ਪ੍ਰੋਸੈਸਰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਕੌਨਫ਼ਿਗਰ ਕੀਤੇ ਗਏ ਹਨ (ਜਿਵੇਂ ਕਿ "--shell-escape" ਫ਼ਲੈਗ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨਾ) ਅਤੇ LaTeX ਇੰਜੈਕਸ਼ਨ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਕਮਾਂਡਾਂ ਦੀ allowlist ਵਰਤੀ ਜਾਂਦੀ ਹੈ। | 2 | +| **1.2.9** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਰੈਗੂਲਰ ਐਕਸਪ੍ਰੈਸ਼ਨਾਂ (regular expressions) ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਅੱਖਰਾਂ ਨੂੰ ਐਸਕੇਪ ਕਰਦੀ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ ਬੈਕਸਲੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਕੇ) ਤਾਂ ਜੋ ਉਹਨਾਂ ਨੂੰ ਮੈਟਾਕੈਰੇਕਟਰਾਂ (metacharacters) ਵਜੋਂ ਗ਼ਲਤ ਸਮਝੇ ਜਾਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕੇ। | 2 | +| **1.2.10** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ CSV ਅਤੇ Formula ਇੰਜੈਕਸ਼ਨ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੈ। CSV ਸਮੱਗਰੀ ਨਿਰਯਾਤ ਕਰਦੇ ਸਮੇਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ RFC 4180 ਦੇ ਭਾਗ 2.6 ਅਤੇ 2.7 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਐਸਕੇਪਿੰਗ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਲਾਜ਼ਮੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, CSV ਜਾਂ ਹੋਰ ਸਪ੍ਰੈਡਸ਼ੀਟ ਫ਼ਾਰਮੈਟਾਂ (ਜਿਵੇਂ ਕਿ XLS, XLSX, ਜਾਂ ODF) ਵਿੱਚ ਨਿਰਯਾਤ ਕਰਦੇ ਸਮੇਂ, ਵਿਸ਼ੇਸ਼ ਅੱਖਰਾਂ ('=', '+', '-', '@', '\t' (ਟੈਬ), ਅਤੇ '\0' (null ਅੱਖਰ) ਸਮੇਤ) ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਕੋਟ ਨਾਲ ਐਸਕੇਪ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ ਜੇ ਉਹ ਕਿਸੇ ਫ਼ੀਲਡ ਮੁੱਲ ਵਿੱਚ ਪਹਿਲੇ ਅੱਖਰ ਵਜੋਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। | 3 | + +Note: Using parameterized queries or escaping SQL is not always sufficient. Query parts such as table and column names (including "ORDER BY" column names) cannot be escaped. Including escaped user-supplied data in these fields results in failed queries or SQL injection. + +ਨੋਟ: ਪੈਰਾਮੀਟਰਾਈਜ਼ਡ ਕਿਊਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜਾਂ SQL ਨੂੰ ਐਸਕੇਪ ਕਰਨਾ ਹਮੇਸ਼ਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦਾ। ਕਿਊਰੀ ਦੇ ਹਿੱਸੇ ਜਿਵੇਂ ਕਿ ਟੇਬਲ ਅਤੇ ਕਾਲਮ ਦੇ ਨਾਂ ("ORDER BY" ਕਾਲਮ ਨਾਵਾਂ ਸਮੇਤ) ਐਸਕੇਪ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ। ਇਹਨਾਂ ਫ਼ੀਲਡਾਂ ਵਿੱਚ ਐਸਕੇਪ ਕੀਤੇ ਉਪਭੋਗਤਾ-ਦਿੱਤੇ ਡਾਟੇ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਨਾਲ ਕਿਊਰੀਆਂ ਅਸਫਲ ਹੁੰਦੀਆਂ ਹਨ ਜਾਂ SQL ਇੰਜੈਕਸ਼ਨ ਹੁੰਦਾ ਹੈ। + +## V1.3 Sanitization +## V1.3 ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ + +The ideal protection against using untrusted content in an unsafe context is to use context-specific encoding or escaping, which maintains the same semantic meaning of the unsafe content but renders it safe for use in that particular context, as discussed in more detail in the previous section. + +ਕਿਸੇ ਅਸੁਰੱਖਿਅਤ ਸੰਦਰਭ ਵਿੱਚ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਸਮੱਗਰੀ ਦੀ ਵਰਤੋਂ ਵਿਰੁੱਧ ਆਦਰਸ਼ ਬਚਾਅ ਸੰਦਰਭ-ਵਿਸ਼ੇਸ਼ ਏਨਕੋਡਿੰਗ ਜਾਂ ਐਸਕੇਪਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ, ਜੋ ਅਸੁਰੱਖਿਅਤ ਸਮੱਗਰੀ ਦਾ ਉਹੀ ਅਰਥਗਤ ਭਾਵ (semantic meaning) ਕਾਇਮ ਰੱਖਦੀ ਹੈ ਪਰ ਇਸ ਨੂੰ ਉਸ ਖ਼ਾਸ ਸੰਦਰਭ ਵਿੱਚ ਵਰਤੋਂ ਲਈ ਸੁਰੱਖਿਅਤ ਬਣਾ ਦਿੰਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਪਿਛਲੇ ਭਾਗ ਵਿੱਚ ਵਧੇਰੇ ਵਿਸਥਾਰ ਨਾਲ ਚਰਚਾ ਕੀਤੀ ਗਈ ਹੈ। + +Where this is not possible, sanitization becomes necessary, removing potentially dangerous characters or content. In some cases, this may change the semantic meaning of the input, but for security reasons, there may be no alternative. + +ਜਿੱਥੇ ਇਹ ਸੰਭਵ ਨਹੀਂ ਹੈ, ਉੱਥੇ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਜੋ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਖ਼ਤਰਨਾਕ ਅੱਖਰਾਂ ਜਾਂ ਸਮੱਗਰੀ ਨੂੰ ਹਟਾ ਦਿੰਦੀ ਹੈ। ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇਹ ਇਨਪੁੱਟ ਦੇ ਅਰਥਗਤ ਭਾਵ ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ, ਪਰ ਸੁਰੱਖਿਆ ਕਾਰਨਾਂ ਕਰਕੇ, ਸ਼ਾਇਦ ਕੋਈ ਬਦਲ ਨਾ ਹੋਵੇ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **1.3.1** | Verify that all untrusted HTML input from WYSIWYG editors or similar is sanitized using a well-known and secure HTML sanitization library or framework feature. | 1 | +| **1.3.2** | Verify that the application avoids the use of eval() or other dynamic code execution features such as Spring Expression Language (SpEL). Where there is no alternative, any user input being included must be sanitized before being executed. | 1 | +| **1.3.3** | Verify that data being passed to a potentially dangerous context is sanitized beforehand to enforce safety measures, such as only allowing characters which are safe for this context and trimming input which is too long. | 2 | +| **1.3.4** | Verify that user-supplied Scalable Vector Graphics (SVG) scriptable content is validated or sanitized to contain only tags and attributes (such as draw graphics) that are safe for the application, e.g., do not contain scripts and foreignObject. | 2 | +| **1.3.5** | Verify that the application sanitizes or disables user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar. | 2 | +| **1.3.6** | Verify that the application protects against Server-side Request Forgery (SSRF) attacks, by validating untrusted data against an allowlist of protocols, domains, paths and ports and sanitizing potentially dangerous characters before using the data to call another service. | 2 | +| **1.3.7** | Verify that the application protects against template injection attacks by not allowing templates to be built based on untrusted input. Where there is no alternative, any untrusted input being included dynamically during template creation must be sanitized or strictly validated. | 2 | +| **1.3.8** | Verify that the application appropriately sanitizes untrusted input before use in Java Naming and Directory Interface (JNDI) queries and that JNDI is configured securely to prevent JNDI injection attacks. | 2 | +| **1.3.9** | Verify that the application sanitizes content before it is sent to memcache to prevent injection attacks. | 2 | +| **1.3.10** | Verify that format strings which might resolve in an unexpected or malicious way when used are sanitized before being processed. | 2 | +| **1.3.11** | Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection. | 2 | +| **1.3.12** | Verify that regular expressions are free from elements causing exponential backtracking, and ensure untrusted input is sanitized to mitigate ReDoS or Runaway Regex attacks. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **1.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ WYSIWYG ਸੰਪਾਦਕਾਂ ਜਾਂ ਇਸ ਵਰਗੇ ਸਰੋਤਾਂ ਤੋਂ ਆਉਣ ਵਾਲੇ ਸਾਰੇ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ HTML ਇਨਪੁੱਟ ਨੂੰ ਇੱਕ ਪ੍ਰਸਿੱਧ ਅਤੇ ਸੁਰੱਖਿਅਤ HTML ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ ਲਾਇਬ੍ਰੇਰੀ ਜਾਂ ਫ੍ਰੇਮਵਰਕ ਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੈਨੀਟਾਈਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। | 1 | +| **1.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ eval() ਜਾਂ ਹੋਰ ਗਤੀਸ਼ੀਲ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਜਿਵੇਂ ਕਿ Spring Expression Language (SpEL), ਦੀ ਵਰਤੋਂ ਤੋਂ ਬਚਦੀ ਹੈ। ਜਿੱਥੇ ਕੋਈ ਬਦਲ ਨਹੀਂ ਹੈ, ਉੱਥੇ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾ ਰਹੇ ਕਿਸੇ ਵੀ ਉਪਭੋਗਤਾ ਇਨਪੁੱਟ ਨੂੰ ਐਗਜ਼ੀਕਿਊਟ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਸੈਨੀਟਾਈਜ਼ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। | 1 | +| **1.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਖ਼ਤਰਨਾਕ ਸੰਦਰਭ ਨੂੰ ਭੇਜੇ ਜਾ ਰਹੇ ਡਾਟੇ ਨੂੰ ਸੁਰੱਖਿਆ ਉਪਾਅ ਲਾਗੂ ਕਰਨ ਲਈ ਪਹਿਲਾਂ ਹੀ ਸੈਨੀਟਾਈਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਸਿਰਫ਼ ਉਹਨਾਂ ਅੱਖਰਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣਾ ਜੋ ਇਸ ਸੰਦਰਭ ਲਈ ਸੁਰੱਖਿਅਤ ਹਨ ਅਤੇ ਬਹੁਤ ਲੰਬੇ ਇਨਪੁੱਟ ਨੂੰ ਕੱਟ ਕੇ ਛੋਟਾ ਕਰਨਾ। | 2 | +| **1.3.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ-ਦਿੱਤੀ Scalable Vector Graphics (SVG) ਸਕ੍ਰਿਪਟ-ਯੋਗ ਸਮੱਗਰੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਜਾਂ ਸੈਨੀਟਾਈਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਇਸ ਵਿੱਚ ਸਿਰਫ਼ ਉਹ ਟੈਗ ਅਤੇ ਐਟ੍ਰੀਬਿਊਟ (ਜਿਵੇਂ ਕਿ ਗ੍ਰਾਫ਼ਿਕਸ ਬਣਾਉਣ ਵਾਲੇ) ਹੋਣ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਸੁਰੱਖਿਅਤ ਹਨ, ਜਿਵੇਂ, ਇਸ ਵਿੱਚ ਸਕ੍ਰਿਪਟਾਂ ਅਤੇ foreignObject ਸ਼ਾਮਲ ਨਾ ਹੋਣ। | 2 | +| **1.3.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਉਪਭੋਗਤਾ-ਦਿੱਤੀ ਸਕ੍ਰਿਪਟ-ਯੋਗ ਜਾਂ ਐਕਸਪ੍ਰੈਸ਼ਨ ਟੈਂਪਲੇਟ ਭਾਸ਼ਾ ਸਮੱਗਰੀ, ਜਿਵੇਂ ਕਿ Markdown, CSS ਜਾਂ XSL ਸਟਾਈਲਸ਼ੀਟਾਂ, BBCode, ਜਾਂ ਇਸ ਵਰਗੀ ਸਮੱਗਰੀ ਨੂੰ ਸੈਨੀਟਾਈਜ਼ ਜਾਂ ਅਯੋਗ ਕਰਦੀ ਹੈ। | 2 | +| **1.3.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ-ਪੱਖੀ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ (Server-side Request Forgery, SSRF) ਹਮਲਿਆਂ ਤੋਂ ਬਚਾਅ ਕਰਦੀ ਹੈ, ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਡਾਟੇ ਨੂੰ ਪ੍ਰੋਟੋਕਾਲਾਂ, ਡੋਮੇਨਾਂ, ਪਾਥਾਂ ਅਤੇ ਪੋਰਟਾਂ ਦੀ allowlist ਵਿਰੁੱਧ ਪ੍ਰਮਾਣਿਤ ਕਰਕੇ ਅਤੇ ਕਿਸੇ ਹੋਰ ਸੇਵਾ ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਡਾਟੇ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਖ਼ਤਰਨਾਕ ਅੱਖਰਾਂ ਨੂੰ ਸੈਨੀਟਾਈਜ਼ ਕਰਕੇ। | 2 | +| **1.3.7** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ ਦੇ ਆਧਾਰ 'ਤੇ ਟੈਂਪਲੇਟ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਨਾ ਦੇ ਕੇ ਟੈਂਪਲੇਟ ਇੰਜੈਕਸ਼ਨ ਹਮਲਿਆਂ ਤੋਂ ਬਚਾਅ ਕਰਦੀ ਹੈ। ਜਿੱਥੇ ਕੋਈ ਬਦਲ ਨਹੀਂ ਹੈ, ਉੱਥੇ ਟੈਂਪਲੇਟ ਬਣਾਉਣ ਦੌਰਾਨ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾ ਰਹੇ ਕਿਸੇ ਵੀ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ ਨੂੰ ਸੈਨੀਟਾਈਜ਼ ਜਾਂ ਸਖ਼ਤੀ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। | 2 | +| **1.3.8** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ Java Naming and Directory Interface (JNDI) ਕਿਊਰੀਆਂ ਵਿੱਚ ਵਰਤੋਂ ਤੋਂ ਪਹਿਲਾਂ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ ਨੂੰ ਢੁਕਵੇਂ ਢੰਗ ਨਾਲ ਸੈਨੀਟਾਈਜ਼ ਕਰਦੀ ਹੈ ਅਤੇ JNDI ਇੰਜੈਕਸ਼ਨ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ JNDI ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਕੌਨਫ਼ਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ। | 2 | +| **1.3.9** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਇੰਜੈਕਸ਼ਨ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਸਮੱਗਰੀ ਨੂੰ memcache ਵਿੱਚ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਸੈਨੀਟਾਈਜ਼ ਕਰਦੀ ਹੈ। | 2 | +| **1.3.10** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਫ਼ਾਰਮੈਟ ਸਟ੍ਰਿੰਗਾਂ (format strings), ਜੋ ਵਰਤੇ ਜਾਣ 'ਤੇ ਅਣਕਿਆਸੇ ਜਾਂ ਦੁਰਭਾਵਨਾਪੂਰਨ ਢੰਗ ਨਾਲ ਰਿਜ਼ੌਲਵ (resolve) ਹੋ ਸਕਦੀਆਂ ਹਨ, ਨੂੰ ਪ੍ਰੋਸੈਸ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਸੈਨੀਟਾਈਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। | 2 | +| **1.3.11** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ SMTP ਜਾਂ IMAP ਇੰਜੈਕਸ਼ਨ ਤੋਂ ਬਚਾਅ ਲਈ ਉਪਭੋਗਤਾ ਇਨਪੁੱਟ ਨੂੰ ਮੇਲ ਸਿਸਟਮਾਂ ਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਸੈਨੀਟਾਈਜ਼ ਕਰਦੀ ਹੈ। | 2 | +| **1.3.12** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਰੈਗੂਲਰ ਐਕਸਪ੍ਰੈਸ਼ਨ ਘਾਤਾਂਕੀ ਬੈਕਟ੍ਰੈਕਿੰਗ (exponential backtracking) ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਤੱਤਾਂ ਤੋਂ ਮੁਕਤ ਹਨ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ReDoS ਜਾਂ Runaway Regex ਹਮਲਿਆਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ ਨੂੰ ਸੈਨੀਟਾਈਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। | 3 | + +## V1.4 Memory, String, and Unmanaged Code +## V1.4 ਮੈਮੋਰੀ, ਸਟ੍ਰਿੰਗ, ਅਤੇ ਅਣਪ੍ਰਬੰਧਿਤ ਕੋਡ + +The following requirements address risks associated with unsafe memory use, which generally apply when the application uses a systems language or unmanaged code. + +ਹੇਠ ਲਿਖੀਆਂ ਲੋੜਾਂ ਅਸੁਰੱਖਿਅਤ ਮੈਮੋਰੀ ਵਰਤੋਂ ਨਾਲ ਜੁੜੇ ਖ਼ਤਰਿਆਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦੀਆਂ ਹਨ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਉਦੋਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਕਿਸੇ ਸਿਸਟਮ ਭਾਸ਼ਾ (systems language) ਜਾਂ ਅਣਪ੍ਰਬੰਧਿਤ ਕੋਡ (unmanaged code) ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। + +In some cases, it may be possible to achieve this by setting compiler flags that enable buffer overflow protections and warnings, including stack randomization and data execution prevention, and that break the build if unsafe pointer, memory, format string, integer, or string operations are found. + +ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇਹ ਅਜਿਹੇ ਕੰਪਾਈਲਰ ਫ਼ਲੈਗ ਸੈੱਟ ਕਰਕੇ ਹਾਸਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਬਫ਼ਰ ਓਵਰਫ਼ਲੋ (buffer overflow) ਸੁਰੱਖਿਆਵਾਂ ਅਤੇ ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਸਮਰੱਥ ਕਰਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਸਟੈਕ ਰੈਂਡਮਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਡਾਟਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਰੋਕਥਾਮ ਸ਼ਾਮਲ ਹਨ, ਅਤੇ ਜੋ ਅਸੁਰੱਖਿਅਤ ਪੁਆਇੰਟਰ, ਮੈਮੋਰੀ, ਫ਼ਾਰਮੈਟ ਸਟ੍ਰਿੰਗ, ਇੰਟੀਜਰ, ਜਾਂ ਸਟ੍ਰਿੰਗ ਕਾਰਵਾਈਆਂ ਮਿਲਣ 'ਤੇ ਬਿਲਡ ਨੂੰ ਤੋੜ ਦਿੰਦੇ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **1.4.1** | Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows. | 2 | +| **1.4.2** | Verify that sign, range, and input validation techniques are used to prevent integer overflows. | 2 | +| **1.4.3** | Verify that dynamically allocated memory and resources are released, and that references or pointers to freed memory are removed or set to null to prevent dangling pointers and use-after-free vulnerabilities. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **1.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸਟੈਕ, ਬਫ਼ਰ, ਜਾਂ ਹੀਪ ਓਵਰਫ਼ਲੋ ਦਾ ਪਤਾ ਲਗਾਉਣ ਜਾਂ ਰੋਕਣ ਲਈ ਮੈਮੋਰੀ-ਸੁਰੱਖਿਅਤ ਸਟ੍ਰਿੰਗ, ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਮੈਮੋਰੀ ਕਾਪੀ ਅਤੇ ਪੁਆਇੰਟਰ ਅੰਕਗਣਿਤ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। | 2 | +| **1.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਇੰਟੀਜਰ ਓਵਰਫ਼ਲੋ ਨੂੰ ਰੋਕਣ ਲਈ ਚਿੰਨ੍ਹ (sign), ਰੇਂਜ, ਅਤੇ ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ ਤਕਨੀਕਾਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। | 2 | +| **1.4.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਅਲਾਟ ਕੀਤੀ ਮੈਮੋਰੀ ਅਤੇ ਸਰੋਤ ਮੁਕਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਮੁਕਤ ਕੀਤੀ ਮੈਮੋਰੀ ਵੱਲ ਹਵਾਲੇ ਜਾਂ ਪੁਆਇੰਟਰ ਹਟਾ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ ਜਾਂ null 'ਤੇ ਸੈੱਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਜੋ ਲਟਕਦੇ ਪੁਆਇੰਟਰਾਂ (dangling pointers) ਅਤੇ use-after-free ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। | 2 | + +## V1.5 Safe Deserialization +## V1.5 ਸੁਰੱਖਿਅਤ ਡੀਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ + +The conversion of data from a stored or transmitted representation into actual application objects (deserialization) has historically been the cause of various code injection vulnerabilities. It is important to perform this process carefully and safely to avoid these types of issues. + +ਡਾਟੇ ਨੂੰ ਸਟੋਰ ਕੀਤੀ ਜਾਂ ਪ੍ਰਸਾਰਿਤ ਕੀਤੀ ਪੇਸ਼ਕਾਰੀ ਤੋਂ ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਆਬਜੈਕਟਾਂ ਵਿੱਚ ਬਦਲਣਾ (ਡੀਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ, deserialization) ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਕੋਡ ਇੰਜੈਕਸ਼ਨ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਕਾਰਨ ਰਿਹਾ ਹੈ। ਇਸ ਕਿਸਮ ਦੇ ਮੁੱਦਿਆਂ ਤੋਂ ਬਚਣ ਲਈ ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਧਿਆਨ ਨਾਲ ਅਤੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। + +In particular, certain methods of deserialization have been identified by programming language or framework documentation as insecure and cannot be made safe with untrusted data. For each mechanism in use, careful due diligence should be performed. + +ਖ਼ਾਸ ਤੌਰ 'ਤੇ, ਡੀਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਦੀਆਂ ਕੁਝ ਵਿਧੀਆਂ ਨੂੰ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਜਾਂ ਫ੍ਰੇਮਵਰਕ ਦਸਤਾਵੇਜ਼ਾਂ ਦੁਆਰਾ ਅਸੁਰੱਖਿਅਤ ਵਜੋਂ ਪਛਾਣਿਆ ਗਿਆ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਡਾਟੇ ਨਾਲ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਬਣਾਇਆ ਜਾ ਸਕਦਾ। ਵਰਤੋਂ ਵਿੱਚ ਹਰੇਕ ਪ੍ਰਣਾਲੀ ਲਈ, ਧਿਆਨਪੂਰਵਕ ਉਚਿਤ ਸਾਵਧਾਨੀ (due diligence) ਵਰਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **1.5.1** | Verify that the application configures XML parsers to use a restrictive configuration and that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks. | 1 | +| **1.5.2** | Verify that deserialization of untrusted data enforces safe input handling, such as using an allowlist of object types or restricting client-defined object types, to prevent deserialization attacks. Deserialization mechanisms that are explicitly defined as insecure must not be used with untrusted input. | 2 | +| **1.5.3** | Verify that different parsers used in the application for the same data type (e.g., JSON parsers, XML parsers, URL parsers), perform parsing in a consistent way and use the same character encoding mechanism to avoid issues such as JSON Interoperability vulnerabilities or different URI or file parsing behavior being exploited in Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **1.5.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ XML ਪਾਰਸਰਾਂ (parsers) ਨੂੰ ਇੱਕ ਪ੍ਰਤਿਬੰਧਿਤ ਸੰਰਚਨਾ ਵਰਤਣ ਲਈ ਕੌਨਫ਼ਿਗਰ ਕਰਦੀ ਹੈ ਅਤੇ XML eXternal Entity (XXE) ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਬਾਹਰੀ ਐਂਟਿਟੀਆਂ ਨੂੰ ਰਿਜ਼ੌਲਵ ਕਰਨ ਵਰਗੀਆਂ ਅਸੁਰੱਖਿਅਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਯੋਗ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। | 1 | +| **1.5.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਡਾਟੇ ਦੀ ਡੀਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਸੁਰੱਖਿਅਤ ਇਨਪੁੱਟ ਸੰਭਾਲ ਲਾਗੂ ਕਰਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਆਬਜੈਕਟ ਕਿਸਮਾਂ ਦੀ allowlist ਵਰਤਣਾ ਜਾਂ ਕਲਾਇੰਟ-ਪਰਿਭਾਸ਼ਿਤ ਆਬਜੈਕਟ ਕਿਸਮਾਂ ਨੂੰ ਪ੍ਰਤਿਬੰਧਿਤ ਕਰਨਾ, ਤਾਂ ਜੋ ਡੀਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। ਜਿਹੜੀਆਂ ਡੀਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਪ੍ਰਣਾਲੀਆਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਅਸੁਰੱਖਿਅਤ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ ਨਾਲ ਨਹੀਂ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ। | 2 | +| **1.5.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਇੱਕੋ ਡਾਟਾ ਕਿਸਮ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਵੱਖ-ਵੱਖ ਪਾਰਸਰ (ਜਿਵੇਂ, JSON ਪਾਰਸਰ, XML ਪਾਰਸਰ, URL ਪਾਰਸਰ) ਪਾਰਸਿੰਗ ਇਕਸਾਰ ਢੰਗ ਨਾਲ ਕਰਦੇ ਹਨ ਅਤੇ ਇੱਕੋ ਅੱਖਰ ਏਨਕੋਡਿੰਗ ਪ੍ਰਣਾਲੀ ਵਰਤਦੇ ਹਨ, ਤਾਂ ਜੋ JSON ਅੰਤਰ-ਕਾਰਜਸ਼ੀਲਤਾ (JSON Interoperability) ਕਮਜ਼ੋਰੀਆਂ ਵਰਗੇ ਮੁੱਦਿਆਂ ਤੋਂ, ਜਾਂ Remote File Inclusion (RFI) ਜਾਂ ਸਰਵਰ-ਪੱਖੀ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ (SSRF) ਹਮਲਿਆਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ URI ਜਾਂ ਫ਼ਾਈਲ ਪਾਰਸਿੰਗ ਵਿਹਾਰ ਦਾ ਸ਼ੋਸ਼ਣ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ। | 3 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [OWASP LDAP Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) +* [OWASP Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) +* [OWASP DOM Based Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html) +* [OWASP XML External Entity Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) +* [OWASP Web Security Testing Guide: Client-Side Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/11-Client-side_Testing) +* [OWASP Java Encoding Project](https://owasp.org/owasp-java-encoder/) +* [DOMPurify - Client-side HTML Sanitization Library](https://github.com/cure53/DOMPurify) +* [RFC4180 - Common Format and MIME Type for Comma-Separated Values (CSV) Files](https://datatracker.ietf.org/doc/html/rfc4180#section-2) + +For more information, specifically on deserialization or parsing issues, please see: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਖ਼ਾਸ ਕਰਕੇ ਡੀਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਜਾਂ ਪਾਰਸਿੰਗ ਮੁੱਦਿਆਂ ਬਾਰੇ, ਕਿਰਪਾ ਕਰਕੇ ਵੇਖੋ: + +* [OWASP Deserialization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) +* [An Exploration of JSON Interoperability Vulnerabilities](https://bishopfox.com/blog/json-interoperability-vulnerabilities) +* [Orange Tsai - A New Era of SSRF Exploiting URL Parser In Trending Programming Languages](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf) diff --git a/5.0/pa-IN/0x11-V2-Validation-and-Business-Logic.md b/5.0/pa-IN/0x11-V2-Validation-and-Business-Logic.md new file mode 100644 index 0000000000..52f160da03 --- /dev/null +++ b/5.0/pa-IN/0x11-V2-Validation-and-Business-Logic.md @@ -0,0 +1,138 @@ + + + + +# V2 Validation and Business Logic +# V2 ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਕਾਰੋਬਾਰੀ ਤਰਕ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +This chapter aims to ensure that a verified application meets the following high-level goals: + +ਇਸ ਅਧਿਆਇ ਦਾ ਉਦੇਸ਼ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਇੱਕ ਤਸਦੀਕ ਕੀਤੀ ਐਪਲੀਕੇਸ਼ਨ ਹੇਠ ਲਿਖੇ ਉੱਚ-ਪੱਧਰੀ ਟੀਚਿਆਂ ਨੂੰ ਪੂਰਾ ਕਰਦੀ ਹੈ: + +* Input received by the application matches business or functional expectations. +* The business logic flow is sequential, processed in order, and cannot be bypassed. +* Business logic includes limits and controls to detect and prevent automated attacks, such as continuous small funds transfers or adding a million friends one at a time. +* High-value business logic flows have considered abuse cases and malicious actors, and have protections against spoofing, tampering, information disclosure, and elevation of privilege attacks. + +* ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਇਨਪੁੱਟ ਕਾਰੋਬਾਰੀ ਜਾਂ ਕਾਰਜਾਤਮਕ ਉਮੀਦਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। +* ਕਾਰੋਬਾਰੀ ਤਰਕ (business logic) ਦਾ ਪ੍ਰਵਾਹ ਕ੍ਰਮਵਾਰ ਹੈ, ਤਰਤੀਬ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਬਾਈਪਾਸ (bypass) ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। +* ਕਾਰੋਬਾਰੀ ਤਰਕ ਵਿੱਚ ਸਵੈਚਾਲਿਤ ਹਮਲਿਆਂ (automated attacks) ਦਾ ਪਤਾ ਲਗਾਉਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਸੀਮਾਵਾਂ ਅਤੇ ਨਿਯੰਤਰਣ ਸ਼ਾਮਲ ਹਨ, ਜਿਵੇਂ ਕਿ ਲਗਾਤਾਰ ਛੋਟੇ ਫ਼ੰਡ ਤਬਾਦਲੇ ਜਾਂ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਦਸ ਲੱਖ ਦੋਸਤ ਜੋੜਨਾ। +* ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਕਾਰੋਬਾਰੀ ਤਰਕ ਪ੍ਰਵਾਹਾਂ ਵਿੱਚ ਦੁਰਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ (abuse cases) ਅਤੇ ਭੈੜੀ ਨੀਅਤ ਵਾਲੇ ਕਰਤਿਆਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਸਪੂਫ਼ਿੰਗ (spoofing), ਛੇੜਛਾੜ, ਜਾਣਕਾਰੀ ਦੇ ਖੁਲਾਸੇ, ਅਤੇ ਅਧਿਕਾਰ-ਵਾਧੇ (elevation of privilege) ਦੇ ਹਮਲਿਆਂ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆਵਾਂ ਮੌਜੂਦ ਹਨ। + +## V2.1 Validation and Business Logic Documentation +## V2.1 ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਕਾਰੋਬਾਰੀ ਤਰਕ ਦਸਤਾਵੇਜ਼ੀਕਰਨ + +Validation and business logic documentation should clearly define business logic limits, validation rules, and contextual consistency of combined data items, so it is clear what needs to be implemented in the application. + +ਪ੍ਰਮਾਣਿਕਤਾ (validation) ਅਤੇ ਕਾਰੋਬਾਰੀ ਤਰਕ ਦੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਨੂੰ ਕਾਰੋਬਾਰੀ ਤਰਕ ਦੀਆਂ ਸੀਮਾਵਾਂ, ਪ੍ਰਮਾਣਿਕਤਾ ਨਿਯਮਾਂ, ਅਤੇ ਸੰਯੁਕਤ ਡਾਟਾ ਇਕਾਈਆਂ ਦੀ ਸੰਦਰਭੀ ਇਕਸਾਰਤਾ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਜੋ ਇਹ ਸਪੱਸ਼ਟ ਹੋਵੇ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਕੀ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **2.1.1** | Verify that the application's documentation defines input validation rules for how to check the validity of data items against an expected structure. This could be common data formats such as credit card numbers, email addresses, telephone numbers, or it could be an internal data format. | 1 | +| **2.1.2** | Verify that the application's documentation defines how to validate the logical and contextual consistency of combined data items, such as checking that suburb and ZIP code match. | 2 | +| **2.1.3** | Verify that expectations for business logic limits and validations are documented, including both per-user and globally across the application. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **2.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਡਾਟਾ ਇਕਾਈਆਂ ਦੀ ਜਾਇਜ਼ਤਾ ਦੀ ਜਾਂਚ ਇੱਕ ਅਨੁਮਾਨਿਤ ਬਣਤਰ ਦੇ ਵਿਰੁੱਧ ਕਿਵੇਂ ਕੀਤੀ ਜਾਵੇ। ਇਹ ਆਮ ਡਾਟਾ ਫਾਰਮੈਟ ਹੋ ਸਕਦੇ ਹਨ ਜਿਵੇਂ ਕਿ ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਨੰਬਰ, ਈਮੇਲ ਪਤੇ, ਟੈਲੀਫ਼ੋਨ ਨੰਬਰ, ਜਾਂ ਇਹ ਕੋਈ ਅੰਦਰੂਨੀ ਡਾਟਾ ਫਾਰਮੈਟ ਹੋ ਸਕਦਾ ਹੈ। | 1 | +| **2.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਸੰਯੁਕਤ ਡਾਟਾ ਇਕਾਈਆਂ ਦੀ ਤਾਰਕਿਕ ਅਤੇ ਸੰਦਰਭੀ ਇਕਸਾਰਤਾ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਇਹ ਜਾਂਚ ਕਰਨਾ ਕਿ ਉਪਨਗਰ ਅਤੇ ZIP ਕੋਡ ਮੇਲ ਖਾਂਦੇ ਹਨ। | 2 | +| **2.1.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਾਰੋਬਾਰੀ ਤਰਕ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾਵਾਂ ਲਈ ਉਮੀਦਾਂ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਵਿੱਚ ਦਰਜ ਹਨ, ਜਿਸ ਵਿੱਚ ਪ੍ਰਤੀ-ਉਪਭੋਗਤਾ ਅਤੇ ਪੂਰੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ, ਦੋਵੇਂ ਸ਼ਾਮਲ ਹਨ। | 2 | + +## V2.2 Input Validation +## V2.2 ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ + +Effective input validation controls enforce business or functional expectations around the type of data the application expects to receive. This ensures good data quality and reduces the attack surface. However, it does not remove or replace the need to use correct encoding, parameterization, or sanitization when using the data in another component or for presenting it for output. + +ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ ਨਿਯੰਤਰਣ ਉਸ ਡਾਟਾ ਦੀ ਕਿਸਮ ਬਾਰੇ ਕਾਰੋਬਾਰੀ ਜਾਂ ਕਾਰਜਾਤਮਕ ਉਮੀਦਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ ਜਿਸ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਉਮੀਦ ਰੱਖਦੀ ਹੈ। ਇਹ ਚੰਗੀ ਡਾਟਾ ਗੁਣਵੱਤਾ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਹਮਲਾ ਸਤ੍ਹਾ (attack surface) ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਕਿਸੇ ਹੋਰ ਹਿੱਸੇ ਵਿੱਚ ਡਾਟਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਜਾਂ ਇਸ ਨੂੰ ਆਉਟਪੁੱਟ ਲਈ ਪੇਸ਼ ਕਰਦੇ ਸਮੇਂ ਸਹੀ ਏਨਕੋਡਿੰਗ, ਪੈਰਾਮੀਟਰਾਈਜ਼ੇਸ਼ਨ, ਜਾਂ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਨੂੰ ਨਾ ਹਟਾਉਂਦਾ ਹੈ ਅਤੇ ਨਾ ਹੀ ਉਸ ਦੀ ਥਾਂ ਲੈਂਦਾ ਹੈ। + +In this context, "input" could come from a wide variety of sources, including HTML form fields, REST requests, URL parameters, HTTP header fields, cookies, files on disk, databases, and external APIs. + +ਇਸ ਸੰਦਰਭ ਵਿੱਚ, "ਇਨਪੁੱਟ" ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਸਰੋਤਾਂ ਤੋਂ ਆ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ HTML ਫਾਰਮ ਖੇਤਰ, REST ਬੇਨਤੀਆਂ, URL ਪੈਰਾਮੀਟਰ, HTTP ਹੈਡਰ ਖੇਤਰ, ਕੁਕੀਜ਼, ਡਿਸਕ 'ਤੇ ਫ਼ਾਈਲਾਂ, ਡਾਟਾਬੇਸ, ਅਤੇ ਬਾਹਰੀ API ਸ਼ਾਮਲ ਹਨ। + +A business logic control might check that a particular input is a number less than 100. A functional expectation might check that a number is below a certain threshold, as that number controls how many times a particular loop will take place, and a high number could lead to excessive processing and a potential denial of service condition. + +ਇੱਕ ਕਾਰੋਬਾਰੀ ਤਰਕ ਨਿਯੰਤਰਣ ਇਹ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕੋਈ ਖ਼ਾਸ ਇਨਪੁੱਟ 100 ਤੋਂ ਘੱਟ ਦੀ ਇੱਕ ਸੰਖਿਆ ਹੈ। ਇੱਕ ਕਾਰਜਾਤਮਕ ਉਮੀਦ ਇਹ ਜਾਂਚ ਕਰ ਸਕਦੀ ਹੈ ਕਿ ਕੋਈ ਸੰਖਿਆ ਇੱਕ ਨਿਸ਼ਚਿਤ ਹੱਦ ਤੋਂ ਹੇਠਾਂ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਸੰਖਿਆ ਇਹ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ ਕਿ ਕੋਈ ਖ਼ਾਸ ਲੂਪ ਕਿੰਨੀ ਵਾਰ ਚੱਲੇਗਾ, ਅਤੇ ਇੱਕ ਵੱਡੀ ਸੰਖਿਆ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਇੱਕ ਸੰਭਾਵੀ ਸੇਵਾ-ਇਨਕਾਰ (denial of service) ਦੀ ਹਾਲਤ ਵੱਲ ਲੈ ਜਾ ਸਕਦੀ ਹੈ। + +While schema validation is not explicitly mandated, it may be the most effective mechanism for full validation coverage of HTTP APIs or other interfaces that use JSON or XML. + +ਭਾਵੇਂ ਸਕੀਮਾ ਪ੍ਰਮਾਣਿਕਤਾ (schema validation) ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਲਾਜ਼ਮੀ ਨਹੀਂ ਕੀਤੀ ਗਈ, ਇਹ HTTP API ਜਾਂ JSON ਜਾਂ XML ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਹੋਰ ਇੰਟਰਫ਼ੇਸਾਂ ਦੀ ਪੂਰੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਵਰੇਜ ਲਈ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪ੍ਰਣਾਲੀ ਹੋ ਸਕਦੀ ਹੈ। + +Please note the following points on Schema Validation: + +ਕਿਰਪਾ ਕਰਕੇ ਸਕੀਮਾ ਪ੍ਰਮਾਣਿਕਤਾ ਬਾਰੇ ਹੇਠ ਲਿਖੇ ਨੁਕਤਿਆਂ ਵੱਲ ਧਿਆਨ ਦਿਓ: + +* The "published version" of the JSON Schema validation specification is considered production-ready, but not strictly speaking "stable." When using JSON Schema validation, ensure there are no gaps with the guidance in the requirements below. +* Any JSON Schema validation libraries in use should also be monitored and updated if necessary once the standard is formalized. +* DTD validation should not be used, and framework DTD evaluation should be disabled, to avoid issues with XXE attacks against DTDs. + +* JSON Schema ਪ੍ਰਮਾਣਿਕਤਾ ਨਿਰਧਾਰਨ ਦਾ "ਪ੍ਰਕਾਸ਼ਿਤ ਸੰਸਕਰਣ" ਉਤਪਾਦਨ-ਤਿਆਰ (production-ready) ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਸਖ਼ਤੀ ਨਾਲ ਕਹੀਏ ਤਾਂ "ਸਥਿਰ" ਨਹੀਂ। JSON Schema ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਲੋੜਾਂ ਵਿਚਲੇ ਮਾਰਗਦਰਸ਼ਨ ਨਾਲ ਕੋਈ ਪਾੜਾ ਨਾ ਹੋਵੇ। +* ਵਰਤੋਂ ਵਿੱਚ ਆਉਣ ਵਾਲੀਆਂ ਕਿਸੇ ਵੀ JSON Schema ਪ੍ਰਮਾਣਿਕਤਾ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਵੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਮਿਆਰ ਦੇ ਰਸਮੀ ਰੂਪ ਧਾਰਨ ਕਰਨ 'ਤੇ, ਜੇ ਲੋੜ ਹੋਵੇ, ਉਹਨਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। +* DTD ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ, ਅਤੇ DTD ਦੇ ਵਿਰੁੱਧ XXE ਹਮਲਿਆਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਣ ਲਈ ਫ੍ਰੇਮਵਰਕ ਦਾ DTD ਮੁਲਾਂਕਣ ਅਸਮਰੱਥ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **2.2.1** | Verify that input is validated to enforce business or functional expectations for that input. This should either use positive validation against an allow list of values, patterns, and ranges, or be based on comparing the input to an expected structure and logical limits according to predefined rules. For L1, this can focus on input which is used to make specific business or security decisions. For L2 and up, this should apply to all input. | 1 | +| **2.2.2** | Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability and should be encouraged, it must not be relied upon as a security control. | 1 | +| **2.2.3** | Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **2.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਇਨਪੁੱਟ ਨੂੰ ਉਸ ਇਨਪੁੱਟ ਲਈ ਕਾਰੋਬਾਰੀ ਜਾਂ ਕਾਰਜਾਤਮਕ ਉਮੀਦਾਂ ਲਾਗੂ ਕਰਨ ਲਈ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਜਾਂ ਤਾਂ ਮੁੱਲਾਂ, ਪੈਟਰਨਾਂ, ਅਤੇ ਰੇਂਜਾਂ ਦੀ ਇੱਕ allowlist ਦੇ ਵਿਰੁੱਧ ਸਕਾਰਾਤਮਕ ਪ੍ਰਮਾਣਿਕਤਾ ਵਰਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਜਾਂ ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਨਿਯਮਾਂ ਦੇ ਅਨੁਸਾਰ ਇਨਪੁੱਟ ਦੀ ਇੱਕ ਅਨੁਮਾਨਿਤ ਬਣਤਰ ਅਤੇ ਤਾਰਕਿਕ ਸੀਮਾਵਾਂ ਨਾਲ ਤੁਲਨਾ 'ਤੇ ਆਧਾਰਿਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। L1 ਲਈ, ਇਹ ਉਸ ਇਨਪੁੱਟ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਖ਼ਾਸ ਕਾਰੋਬਾਰੀ ਜਾਂ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲੇ ਲੈਣ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। L2 ਅਤੇ ਉੱਪਰ ਲਈ, ਇਹ ਸਾਰੇ ਇਨਪੁੱਟ 'ਤੇ ਲਾਗੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। | 1 | +| **2.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸੇਵਾ ਪਰਤ 'ਤੇ ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ ਲਾਗੂ ਕਰਨ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਭਾਵੇਂ ਕਲਾਇੰਟ-ਸਾਈਡ ਪ੍ਰਮਾਣਿਕਤਾ ਵਰਤੋਂਯੋਗਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੀ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਸ 'ਤੇ ਇੱਕ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਵਜੋਂ ਭਰੋਸਾ ਨਾ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। | 1 | +| **2.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਸੰਬੰਧਿਤ ਡਾਟਾ ਇਕਾਈਆਂ ਦੇ ਸੁਮੇਲ ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਨਿਯਮਾਂ ਦੇ ਅਨੁਸਾਰ ਵਾਜਬ ਹਨ। | 2 | + +## V2.3 Business Logic Security +## V2.3 ਕਾਰੋਬਾਰੀ ਤਰਕ ਸੁਰੱਖਿਆ + +This section considers key requirements to ensure that the application enforces business logic processes in the correct way and is not vulnerable to attacks that exploit the logic and flow of the application. + +ਇਹ ਭਾਗ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਮੁੱਖ ਲੋੜਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਦਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕਾਰੋਬਾਰੀ ਤਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕਰਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਹਮਲਿਆਂ ਲਈ ਕਮਜ਼ੋਰ ਨਹੀਂ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਤਰਕ ਅਤੇ ਪ੍ਰਵਾਹ ਦਾ ਸ਼ੋਸ਼ਣ ਕਰਦੇ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **2.3.1** | Verify that the application will only process business logic flows for the same user in the expected sequential step order and without skipping steps. | 1 | +| **2.3.2** | Verify that business logic limits are implemented per the application's documentation to avoid business logic flaws being exploited. | 2 | +| **2.3.3** | Verify that transactions are being used at the business logic level such that either a business logic operation succeeds in its entirety or it is rolled back to the previous correct state. | 2 | +| **2.3.4** | Verify that business logic level locking mechanisms are used to ensure that limited quantity resources (such as theater seats or delivery slots) cannot be double-booked by manipulating the application's logic. | 2 | +| **2.3.5** | Verify that high-value business logic flows require multi-user approval to prevent unauthorized or accidental actions. This could include but is not limited to large monetary transfers, contract approvals, access to classified information, or safety overrides in manufacturing. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **2.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕੋ ਉਪਭੋਗਤਾ ਲਈ ਕਾਰੋਬਾਰੀ ਤਰਕ ਪ੍ਰਵਾਹਾਂ ਨੂੰ ਸਿਰਫ਼ ਅਨੁਮਾਨਿਤ ਕ੍ਰਮਵਾਰ ਕਦਮ ਤਰਤੀਬ ਵਿੱਚ ਅਤੇ ਕਦਮ ਛੱਡੇ ਬਿਨਾਂ ਹੀ ਪ੍ਰਕਿਰਿਆ ਕਰੇਗੀ। | 1 | +| **2.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਾਰੋਬਾਰੀ ਤਰਕ ਦੀਆਂ ਖ਼ਾਮੀਆਂ ਦੇ ਸ਼ੋਸ਼ਣ ਤੋਂ ਬਚਣ ਲਈ ਕਾਰੋਬਾਰੀ ਤਰਕ ਦੀਆਂ ਸੀਮਾਵਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਦੇ ਅਨੁਸਾਰ ਲਾਗੂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। | 2 | +| **2.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਾਰੋਬਾਰੀ ਤਰਕ ਪੱਧਰ 'ਤੇ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ (transactions) ਦੀ ਵਰਤੋਂ ਇਸ ਤਰ੍ਹਾਂ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ ਕਿ ਜਾਂ ਤਾਂ ਇੱਕ ਕਾਰੋਬਾਰੀ ਤਰਕ ਕਾਰਜ ਆਪਣੀ ਸਮੁੱਚਤਾ ਵਿੱਚ ਸਫਲ ਹੁੰਦਾ ਹੈ ਜਾਂ ਇਸ ਨੂੰ ਪਿਛਲੀ ਸਹੀ ਸਥਿਤੀ 'ਤੇ ਵਾਪਸ ਮੋੜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। | 2 | +| **2.3.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਾਰੋਬਾਰੀ ਤਰਕ ਪੱਧਰ ਦੀਆਂ ਲਾਕਿੰਗ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਰਤੋਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਸੀਮਤ ਮਾਤਰਾ ਵਾਲੇ ਸਰੋਤਾਂ (ਜਿਵੇਂ ਕਿ ਥੀਏਟਰ ਦੀਆਂ ਸੀਟਾਂ ਜਾਂ ਡਿਲੀਵਰੀ ਸਲਾਟ) ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਤਰਕ ਨਾਲ ਹੇਰਾਫੇਰੀ ਕਰਕੇ ਦੋਹਰੀ-ਬੁਕਿੰਗ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ। | 2 | +| **2.3.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਕਾਰੋਬਾਰੀ ਤਰਕ ਪ੍ਰਵਾਹਾਂ ਲਈ ਅਣਅਧਿਕਾਰਤ ਜਾਂ ਗ਼ਲਤੀ ਨਾਲ ਹੋਣ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਬਹੁ-ਉਪਭੋਗਤਾ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਵੱਡੀ ਰਕਮ ਦੇ ਤਬਾਦਲੇ, ਇਕਰਾਰਨਾਮੇ ਦੀਆਂ ਮਨਜ਼ੂਰੀਆਂ, ਵਰਗੀਕ੍ਰਿਤ ਜਾਣਕਾਰੀ ਤੱਕ ਪਹੁੰਚ, ਜਾਂ ਨਿਰਮਾਣ ਵਿੱਚ ਸੁਰੱਖਿਆ ਓਵਰਰਾਈਡ (safety overrides) ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਇਹ ਇਹਨਾਂ ਤੱਕ ਸੀਮਤ ਨਹੀਂ ਹੈ। | 3 | + +## V2.4 Anti-automation +## V2.4 ਸਵੈਚਾਲਨ-ਵਿਰੋਧੀ + +This section includes anti-automation controls to ensure that human-like interactions are required and excessive automated requests are prevented. + +ਇਸ ਭਾਗ ਵਿੱਚ ਸਵੈਚਾਲਨ-ਵਿਰੋਧੀ (anti-automation) ਨਿਯੰਤਰਣ ਸ਼ਾਮਲ ਹਨ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਮਨੁੱਖ-ਵਰਗੀਆਂ ਆਪਸੀ ਕਿਰਿਆਵਾਂ ਲੋੜੀਂਦੀਆਂ ਹਨ ਅਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਵੈਚਾਲਿਤ ਬੇਨਤੀਆਂ ਨੂੰ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **2.4.1** | Verify that anti-automation controls are in place to protect against excessive calls to application functions that could lead to data exfiltration, garbage-data creation, quota exhaustion, rate-limit breaches, denial-of-service, or overuse of costly resources. | 2 | +| **2.4.2** | Verify that business logic flows require realistic human timing, preventing excessively rapid transaction submissions. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **2.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਅਜਿਹੀਆਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕਾਲਾਂ ਤੋਂ ਬਚਾਅ ਲਈ ਸਵੈਚਾਲਨ-ਵਿਰੋਧੀ ਨਿਯੰਤਰਣ ਮੌਜੂਦ ਹਨ ਜੋ ਡਾਟਾ ਨਿਕਾਸੀ (data exfiltration), ਕੂੜਾ-ਡਾਟਾ ਸਿਰਜਣਾ, ਕੋਟਾ ਖ਼ਤਮ ਹੋ ਜਾਣਾ (quota exhaustion), ਦਰ ਸੀਮਾ ਉਲੰਘਣਾਵਾਂ, ਸੇਵਾ-ਇਨਕਾਰ, ਜਾਂ ਮਹਿੰਗੇ ਸਰੋਤਾਂ ਦੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਰਤੋਂ ਵੱਲ ਲੈ ਜਾ ਸਕਦੀਆਂ ਹਨ। | 2 | +| **2.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਾਰੋਬਾਰੀ ਤਰਕ ਪ੍ਰਵਾਹਾਂ ਲਈ ਯਥਾਰਥਕ ਮਨੁੱਖੀ ਸਮੇਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜੋ ਬਹੁਤ ਜ਼ਿਆਦਾ ਤੇਜ਼ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਸਪੁਰਦਗੀਆਂ ਨੂੰ ਰੋਕਦੀ ਹੈ। | 3 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [OWASP Web Security Testing Guide: Input Validation Testing](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/README.html) +* [OWASP Web Security Testing Guide: Business Logic Testing](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/10-Business_Logic_Testing/README) +* Anti-automation can be achieved in many ways, including the use of the [OWASP Automated Threats to Web Applications](https://owasp.org/www-project-automated-threats-to-web-applications/) +* [OWASP Input Validation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) +* [JSON Schema](https://json-schema.org/specification.html) diff --git a/5.0/pa-IN/0x12-V3-Web-Frontend-Security.md b/5.0/pa-IN/0x12-V3-Web-Frontend-Security.md new file mode 100644 index 0000000000..7edd900725 --- /dev/null +++ b/5.0/pa-IN/0x12-V3-Web-Frontend-Security.md @@ -0,0 +1,188 @@ + + + + +# V3 Web Frontend Security +# V3 ਵੈੱਬ ਫਰੰਟਐਂਡ ਸੁਰੱਖਿਆ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +This chapter focuses on requirements designed to protect against attacks executed via a web frontend. These requirements do not apply to machine-to-machine solutions. + +ਇਹ ਅਧਿਆਇ ਉਹਨਾਂ ਲੋੜਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ ਜੋ ਵੈੱਬ ਫਰੰਟਐਂਡ (web frontend) ਰਾਹੀਂ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਹਮਲਿਆਂ ਤੋਂ ਬਚਾਅ ਲਈ ਤਿਆਰ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਇਹ ਲੋੜਾਂ ਮਸ਼ੀਨ-ਤੋਂ-ਮਸ਼ੀਨ ਹੱਲਾਂ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀਆਂ। + +## V3.1 Web Frontend Security Documentation +## V3.1 ਵੈੱਬ ਫਰੰਟਐਂਡ ਸੁਰੱਖਿਆ ਦਸਤਾਵੇਜ਼ੀਕਰਨ + +This section outlines the browser security features that should be specified in the application's documentation. + +ਇਹ ਭਾਗ ਉਹਨਾਂ ਬ੍ਰਾਊਜ਼ਰ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦਿੰਦਾ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਵਿੱਚ ਦਰਸਾਈਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.1.1** | Verify that application documentation states the expected security features that browsers using the application must support (such as HTTPS, HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), and other relevant HTTP security mechanisms). It must also define how the application must behave when some of these features are not available (such as warning the user or blocking access). | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **3.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਉਹਨਾਂ ਉਮੀਦ ਕੀਤੀਆਂ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਸਮਰਥਨ ਐਪਲੀਕੇਸ਼ਨ ਵਰਤਣ ਵਾਲੇ ਬ੍ਰਾਊਜ਼ਰਾਂ ਲਈ ਲਾਜ਼ਮੀ ਹੈ (ਜਿਵੇਂ ਕਿ HTTPS, HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), ਅਤੇ ਹੋਰ ਸੰਬੰਧਿਤ HTTP ਸੁਰੱਖਿਆ ਪ੍ਰਣਾਲੀਆਂ)। ਇਸ ਨੂੰ ਇਹ ਵੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ ਕਿ ਜਦੋਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਉਪਲਬਧ ਨਾ ਹੋਣ ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਿਵੇਂ ਵਿਹਾਰ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ (ਜਿਵੇਂ ਕਿ ਉਪਭੋਗਤਾ ਨੂੰ ਚੇਤਾਵਨੀ ਦੇਣਾ ਜਾਂ ਪਹੁੰਚ ਨੂੰ ਰੋਕਣਾ)। | 3 | + +## V3.2 Unintended Content Interpretation +## V3.2 ਅਣਇੱਛਤ ਸਮੱਗਰੀ ਵਿਆਖਿਆ + +Rendering content or functionality in an incorrect context can result in malicious content being executed or displayed. + +ਸਮੱਗਰੀ ਜਾਂ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਗ਼ਲਤ ਸੰਦਰਭ ਵਿੱਚ ਰੈਂਡਰ (render) ਕਰਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਖ਼ਤਰਨਾਕ ਸਮੱਗਰੀ ਚਲਾਈ ਜਾਂ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.2.1** | Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields (such as Sec-Fetch-\*) indicate it is the correct context, using the sandbox directive of the Content-Security-Policy header field or using the attachment disposition type in the Content-Disposition header field. | 1 | +| **3.2.2** | Verify that content intended to be displayed as text, rather than rendered as HTML, is handled using safe rendering functions (such as createTextNode or textContent) to prevent unintended execution of content such as HTML or JavaScript. | 1 | +| **3.2.3** | Verify that the application avoids DOM clobbering when using client-side JavaScript by employing explicit variable declarations, performing strict type checking, avoiding storing global variables on the document object, and implementing namespace isolation. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **3.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਬ੍ਰਾਊਜ਼ਰਾਂ ਨੂੰ HTTP ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ (responses) ਵਿਚਲੀ ਸਮੱਗਰੀ ਜਾਂ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਗ਼ਲਤ ਸੰਦਰਭ ਵਿੱਚ ਰੈਂਡਰ ਕਰਨ ਤੋਂ ਰੋਕਣ ਲਈ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਮੌਜੂਦ ਹਨ (ਜਿਵੇਂ ਕਿ, ਜਦੋਂ ਕਿਸੇ API, ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਅੱਪਲੋਡ ਕੀਤੀ ਫ਼ਾਈਲ ਜਾਂ ਹੋਰ ਸਰੋਤ ਦੀ ਸਿੱਧੀ ਬੇਨਤੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ)। ਸੰਭਵ ਨਿਯੰਤਰਣਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ: ਸਮੱਗਰੀ ਨੂੰ ਉਦੋਂ ਤੱਕ ਨਾ ਪਰੋਸਣਾ ਜਦੋਂ ਤੱਕ HTTP ਬੇਨਤੀ ਹੈੱਡਰ ਖੇਤਰ (ਜਿਵੇਂ ਕਿ Sec-Fetch-\*) ਇਹ ਸੰਕੇਤ ਨਾ ਦੇਣ ਕਿ ਇਹ ਸਹੀ ਸੰਦਰਭ ਹੈ, Content-Security-Policy ਹੈੱਡਰ ਖੇਤਰ ਦੇ sandbox ਨਿਰਦੇਸ਼ (directive) ਦੀ ਵਰਤੋਂ ਕਰਨਾ, ਜਾਂ Content-Disposition ਹੈੱਡਰ ਖੇਤਰ ਵਿੱਚ attachment ਡਿਸਪੋਜ਼ੀਸ਼ਨ ਕਿਸਮ ਦੀ ਵਰਤੋਂ ਕਰਨਾ। | 1 | +| **3.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜੋ ਸਮੱਗਰੀ HTML ਵਜੋਂ ਰੈਂਡਰ ਕੀਤੇ ਜਾਣ ਦੀ ਬਜਾਏ ਟੈਕਸਟ ਵਜੋਂ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤੇ ਜਾਣ ਲਈ ਹੈ, ਉਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੈਂਡਰਿੰਗ ਫੰਕਸ਼ਨਾਂ (ਜਿਵੇਂ ਕਿ createTextNode ਜਾਂ textContent) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜੋ HTML ਜਾਂ JavaScript ਵਰਗੀ ਸਮੱਗਰੀ ਨੂੰ ਅਣਇੱਛਤ ਤੌਰ 'ਤੇ ਚੱਲਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕੇ। | 1 | +| **3.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕਲਾਇੰਟ-ਸਾਈਡ JavaScript ਵਰਤਦੇ ਸਮੇਂ DOM clobbering ਤੋਂ ਬਚਦੀ ਹੈ, ਜਿਸ ਲਈ ਸਪੱਸ਼ਟ ਵੇਰੀਏਬਲ ਘੋਸ਼ਣਾਵਾਂ ਦੀ ਵਰਤੋਂ, ਸਖ਼ਤ ਕਿਸਮ ਜਾਂਚ (strict type checking), document ਆਬਜੈਕਟ 'ਤੇ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਸਟੋਰ ਕਰਨ ਤੋਂ ਬਚਣਾ, ਅਤੇ ਨੇਮਸਪੇਸ ਅਲਹਿਦਗੀ (namespace isolation) ਲਾਗੂ ਕਰਨਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। | 3 | + +## V3.3 Cookie Setup +## V3.3 ਕੁਕੀ ਸੈੱਟਅੱਪ + +This section outlines requirements for securely configuring sensitive cookies to provide a higher level of assurance that they were created by the application itself and to prevent their contents from leaking or being inappropriately modified. + +ਇਹ ਭਾਗ ਸੰਵੇਦਨਸ਼ੀਲ ਕੁਕੀਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਕੌਨਫ਼ਿਗਰ ਕਰਨ ਦੀਆਂ ਲੋੜਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਇਸ ਗੱਲ ਦਾ ਉੱਚ ਪੱਧਰ ਦਾ ਭਰੋਸਾ ਮਿਲੇ ਕਿ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਖ਼ੁਦ ਬਣਾਈਆਂ ਗਈਆਂ ਸਨ, ਅਤੇ ਉਹਨਾਂ ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਲੀਕ ਹੋਣ ਜਾਂ ਅਣਉਚਿਤ ਢੰਗ ਨਾਲ ਸੋਧੇ ਜਾਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕੇ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.3.1** | Verify that cookies have the 'Secure' attribute set, and if the '\__Host-' prefix is not used for the cookie name, the '__Secure-' prefix must be used for the cookie name. | 1 | +| **3.3.2** | Verify that each cookie's 'SameSite' attribute value is set according to the purpose of the cookie, to limit exposure to user interface redress attacks and browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF). | 2 | +| **3.3.3** | Verify that cookies have the '__Host-' prefix for the cookie name unless they are explicitly designed to be shared with other hosts. | 2 | +| **3.3.4** | Verify that if the value of a cookie is not meant to be accessible to client-side scripts (such as a session token), the cookie must have the 'HttpOnly' attribute set and the same value (e. g. session token) must only be transferred to the client via the 'Set-Cookie' header field. | 2 | +| **3.3.5** | Verify that when the application writes a cookie, the cookie name and value length combined are not over 4096 bytes. Overly large cookies will not be stored by the browser and therefore not sent with requests, preventing the user from using application functionality which relies on that cookie. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **3.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕੁਕੀਆਂ 'ਤੇ 'Secure' ਗੁਣ (attribute) ਸੈੱਟ ਹੈ, ਅਤੇ ਜੇ ਕੁਕੀ ਨਾਮ ਲਈ '\__Host-' ਅਗੇਤਰ ਨਹੀਂ ਵਰਤਿਆ ਜਾਂਦਾ, ਤਾਂ ਕੁਕੀ ਨਾਮ ਲਈ '__Secure-' ਅਗੇਤਰ ਵਰਤਿਆ ਜਾਣਾ ਲਾਜ਼ਮੀ ਹੈ। | 1 | +| **3.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਹਰੇਕ ਕੁਕੀ ਦੇ 'SameSite' ਗੁਣ ਦਾ ਮੁੱਲ ਕੁਕੀ ਦੇ ਉਦੇਸ਼ ਅਨੁਸਾਰ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਜੋ ਉਪਭੋਗਤਾ ਇੰਟਰਫ਼ੇਸ ਰੀਡਰੈੱਸ (user interface redress) ਹਮਲਿਆਂ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ-ਆਧਾਰਿਤ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ ਹਮਲਿਆਂ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਕਰਾਸ-ਸਾਈਟ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ (CSRF) ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਪ੍ਰਤੀ ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਸੀਮਤ ਕੀਤਾ ਜਾ ਸਕੇ। | 2 | +| **3.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕੁਕੀਆਂ ਦੇ ਨਾਮ ਲਈ '__Host-' ਅਗੇਤਰ ਹੈ, ਜਦੋਂ ਤੱਕ ਉਹਨਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਹੋਰ ਹੋਸਟਾਂ ਨਾਲ ਸਾਂਝਾ ਕੀਤੇ ਜਾਣ ਲਈ ਡਿਜ਼ਾਈਨ ਨਾ ਕੀਤਾ ਗਿਆ ਹੋਵੇ। | 2 | +| **3.3.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜੇ ਕਿਸੇ ਕੁਕੀ ਦਾ ਮੁੱਲ ਕਲਾਇੰਟ-ਸਾਈਡ ਸਕ੍ਰਿਪਟਾਂ ਲਈ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ (ਜਿਵੇਂ ਕਿ ਸੈਸ਼ਨ ਟੋਕਨ), ਤਾਂ ਕੁਕੀ 'ਤੇ 'HttpOnly' ਗੁਣ ਸੈੱਟ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ ਅਤੇ ਉਹੀ ਮੁੱਲ (ਜਿਵੇਂ ਕਿ ਸੈਸ਼ਨ ਟੋਕਨ) ਕੇਵਲ 'Set-Cookie' ਹੈੱਡਰ ਖੇਤਰ ਰਾਹੀਂ ਹੀ ਕਲਾਇੰਟ ਨੂੰ ਭੇਜਿਆ ਜਾਣਾ ਲਾਜ਼ਮੀ ਹੈ। | 2 | +| **3.3.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਕੋਈ ਕੁਕੀ ਲਿਖਦੀ ਹੈ, ਤਾਂ ਕੁਕੀ ਦੇ ਨਾਮ ਅਤੇ ਮੁੱਲ ਦੀ ਸਾਂਝੀ ਲੰਬਾਈ 4096 ਬਾਈਟ ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੁੰਦੀ। ਬਹੁਤ ਵੱਡੀਆਂ ਕੁਕੀਆਂ ਬ੍ਰਾਊਜ਼ਰ ਦੁਆਰਾ ਸਟੋਰ ਨਹੀਂ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ ਅਤੇ ਇਸ ਲਈ ਬੇਨਤੀਆਂ ਨਾਲ ਨਹੀਂ ਭੇਜੀਆਂ ਜਾਣਗੀਆਂ, ਜਿਸ ਨਾਲ ਉਪਭੋਗਤਾ ਉਸ ਕੁਕੀ 'ਤੇ ਨਿਰਭਰ ਐਪਲੀਕੇਸ਼ਨ ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕੇਗਾ। | 3 | + +## V3.4 Browser Security Mechanism Headers +## V3.4 ਬ੍ਰਾਊਜ਼ਰ ਸੁਰੱਖਿਆ ਪ੍ਰਣਾਲੀ ਹੈੱਡਰ + +This section describes which security headers should be set on HTTP responses to enable browser security features and restrictions when handling responses from the application. + +ਇਹ ਭਾਗ ਦੱਸਦਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਆਈਆਂ ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ ਨੂੰ ਸੰਭਾਲਦੇ ਸਮੇਂ ਬ੍ਰਾਊਜ਼ਰ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਪਾਬੰਦੀਆਂ ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਲਈ HTTP ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ 'ਤੇ ਕਿਹੜੇ ਸੁਰੱਖਿਆ ਹੈੱਡਰ ਸੈੱਟ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.4.1** | Verify that a Strict-Transport-Security header field is included on all responses to enforce an HTTP Strict Transport Security (HSTS) policy. A maximum age of at least 1 year must be defined, and for L2 and up, the policy must apply to all subdomains as well. | 1 | +| **3.4.2** | Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is a fixed value by the application, or if the Origin HTTP request header field value is used, it is validated against an allowlist of trusted origins. When 'Access-Control-Allow-Origin: *' needs to be used, verify that the response does not include any sensitive information. | 1 | +| **3.4.3** | Verify that HTTP responses include a Content-Security-Policy response header field which defines directives to ensure the browser only loads and executes trusted content or resources, in order to limit execution of malicious JavaScript. As a minimum, a global policy must be used which includes the directives object-src 'none' and base-uri 'none' and defines either an allowlist or uses nonces or hashes. For an L3 application, a per-response policy with nonces or hashes must be defined. | 2 | +| **3.4.4** | Verify that all HTTP responses contain an 'X-Content-Type-Options: nosniff' header field. This instructs browsers not to use content sniffing and MIME type guessing for the given response, and to require the response's Content-Type header field value to match the destination resource. For example, the response to a request for a style is only accepted if the response's Content-Type is 'text/css'. This also enables the use of the Cross-Origin Read Blocking (CORB) functionality by the browser. | 2 | +| **3.4.5** | Verify that the application sets a referrer policy to prevent leakage of technically sensitive data to third-party services via the 'Referer' HTTP request header field. This can be done using the Referrer-Policy HTTP response header field or via HTML element attributes. Sensitive data could include path and query data in the URL, and for internal non-public applications also the hostname. | 2 | +| **3.4.6** | Verify that the web application uses the frame-ancestors directive of the Content-Security-Policy header field for every HTTP response to ensure that it cannot be embedded by default and that embedding of specific resources is allowed only when necessary. Note that the X-Frame-Options header field, although supported by browsers, is obsolete and may not be relied upon. | 2 | +| **3.4.7** | Verify that the Content-Security-Policy header field specifies a location to report violations. | 3 | +| **3.4.8** | Verify that all HTTP responses that initiate a document rendering (such as responses with Content-Type text/html), include the Cross‑Origin‑Opener‑Policy header field with the same-origin directive or the same-origin-allow-popups directive as required. This prevents attacks that abuse shared access to Window objects, such as tabnabbing and frame counting. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **3.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ HTTP Strict Transport Security (HSTS) ਨੀਤੀ ਲਾਗੂ ਕਰਨ ਲਈ ਸਾਰੀਆਂ ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ 'ਤੇ Strict-Transport-Security ਹੈੱਡਰ ਖੇਤਰ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ। ਘੱਟੋ-ਘੱਟ 1 ਸਾਲ ਦੀ ਵੱਧ-ਤੋਂ-ਵੱਧ ਉਮਰ (maximum age) ਪਰਿਭਾਸ਼ਿਤ ਕਰਨੀ ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ L2 ਅਤੇ ਇਸ ਤੋਂ ਉੱਪਰ ਲਈ, ਇਹ ਨੀਤੀ ਸਾਰੇ ਸਬਡੋਮੇਨਾਂ 'ਤੇ ਵੀ ਲਾਗੂ ਹੋਣੀ ਲਾਜ਼ਮੀ ਹੈ। | 1 | +| **3.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin ਹੈੱਡਰ ਖੇਤਰ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਨਿਰਧਾਰਿਤ ਇੱਕ ਸਥਿਰ ਮੁੱਲ ਹੈ, ਜਾਂ ਜੇ Origin HTTP ਬੇਨਤੀ ਹੈੱਡਰ ਖੇਤਰ ਦਾ ਮੁੱਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਭਰੋਸੇਯੋਗ ਓਰਿਜਿਨਾਂ (origins) ਦੀ ਇੱਕ allowlist ਦੇ ਵਿਰੁੱਧ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ 'Access-Control-Allow-Origin: *' ਵਰਤਣ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਤਸਦੀਕ ਕਰੋ ਕਿ ਪ੍ਰਤੀਕਿਰਿਆ ਵਿੱਚ ਕੋਈ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ। | 1 | +| **3.4.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ HTTP ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ ਵਿੱਚ ਇੱਕ Content-Security-Policy ਪ੍ਰਤੀਕਿਰਿਆ ਹੈੱਡਰ ਖੇਤਰ ਸ਼ਾਮਲ ਹੈ ਜੋ ਅਜਿਹੇ ਨਿਰਦੇਸ਼ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਕੇਵਲ ਭਰੋਸੇਯੋਗ ਸਮੱਗਰੀ ਜਾਂ ਸਰੋਤ ਹੀ ਲੋਡ ਅਤੇ ਚਲਾਏ, ਤਾਂ ਜੋ ਖ਼ਤਰਨਾਕ JavaScript ਦੇ ਚੱਲਣ ਨੂੰ ਸੀਮਤ ਕੀਤਾ ਜਾ ਸਕੇ। ਘੱਟੋ-ਘੱਟ, ਇੱਕ ਗਲੋਬਲ ਨੀਤੀ ਵਰਤਣੀ ਲਾਜ਼ਮੀ ਹੈ ਜਿਸ ਵਿੱਚ object-src 'none' ਅਤੇ base-uri 'none' ਨਿਰਦੇਸ਼ ਸ਼ਾਮਲ ਹੋਣ ਅਤੇ ਜੋ ਜਾਂ ਤਾਂ ਇੱਕ allowlist ਪਰਿਭਾਸ਼ਿਤ ਕਰੇ ਜਾਂ ਨੌਂਸ (nonce) ਜਾਂ ਹੈਸ਼ ਵਰਤੇ। L3 ਐਪਲੀਕੇਸ਼ਨ ਲਈ, ਨੌਂਸ ਜਾਂ ਹੈਸ਼ ਵਾਲੀ ਪ੍ਰਤੀ-ਪ੍ਰਤੀਕਿਰਿਆ ਨੀਤੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨੀ ਲਾਜ਼ਮੀ ਹੈ। | 2 | +| **3.4.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੀਆਂ HTTP ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ ਵਿੱਚ 'X-Content-Type-Options: nosniff' ਹੈੱਡਰ ਖੇਤਰ ਸ਼ਾਮਲ ਹੈ। ਇਹ ਬ੍ਰਾਊਜ਼ਰਾਂ ਨੂੰ ਨਿਰਦੇਸ਼ ਦਿੰਦਾ ਹੈ ਕਿ ਉਹ ਦਿੱਤੀ ਗਈ ਪ੍ਰਤੀਕਿਰਿਆ ਲਈ ਸਮੱਗਰੀ ਸਨਿਫ਼ਿੰਗ (content sniffing) ਅਤੇ MIME ਕਿਸਮ ਦੇ ਅਨੁਮਾਨ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨ, ਅਤੇ ਇਹ ਲੋੜ ਰੱਖਣ ਕਿ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ Content-Type ਹੈੱਡਰ ਖੇਤਰ ਦਾ ਮੁੱਲ ਮੰਜ਼ਿਲ ਸਰੋਤ ਨਾਲ ਮੇਲ ਖਾਵੇ। ਉਦਾਹਰਨ ਲਈ, ਕਿਸੇ ਸਟਾਈਲ ਲਈ ਬੇਨਤੀ ਦੀ ਪ੍ਰਤੀਕਿਰਿਆ ਕੇਵਲ ਤਾਂ ਹੀ ਸਵੀਕਾਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜੇ ਪ੍ਰਤੀਕਿਰਿਆ ਦਾ Content-Type 'text/css' ਹੋਵੇ। ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਦੁਆਰਾ Cross-Origin Read Blocking (CORB) ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਵਰਤੋਂ ਨੂੰ ਵੀ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ। | 2 | +| **3.4.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ 'Referer' HTTP ਬੇਨਤੀ ਹੈੱਡਰ ਖੇਤਰ ਰਾਹੀਂ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਦੇ ਤੀਜੀ-ਧਿਰ ਸੇਵਾਵਾਂ ਨੂੰ ਲੀਕ ਹੋਣ ਤੋਂ ਰੋਕਣ ਲਈ ਇੱਕ ਰੈਫ਼ਰਰ ਨੀਤੀ (referrer policy) ਸੈੱਟ ਕਰਦੀ ਹੈ। ਇਹ Referrer-Policy HTTP ਪ੍ਰਤੀਕਿਰਿਆ ਹੈੱਡਰ ਖੇਤਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜਾਂ HTML ਐਲੀਮੈਂਟ ਗੁਣਾਂ ਰਾਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਵਿੱਚ URL ਵਿਚਲਾ ਪਾਥ ਅਤੇ ਕਿਊਰੀ ਡਾਟਾ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਅੰਦਰੂਨੀ ਗ਼ੈਰ-ਜਨਤਕ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਹੋਸਟਨੇਮ (hostname) ਵੀ। | 2 | +| **3.4.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਹਰੇਕ HTTP ਪ੍ਰਤੀਕਿਰਿਆ ਲਈ Content-Security-Policy ਹੈੱਡਰ ਖੇਤਰ ਦੇ frame-ancestors ਨਿਰਦੇਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਇਸ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਏਮਬੈੱਡ (embed) ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਅਤੇ ਖ਼ਾਸ ਸਰੋਤਾਂ ਦੀ ਏਮਬੈਡਿੰਗ ਦੀ ਇਜਾਜ਼ਤ ਕੇਵਲ ਲੋੜ ਪੈਣ 'ਤੇ ਹੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਧਿਆਨ ਦਿਓ ਕਿ X-Frame-Options ਹੈੱਡਰ ਖੇਤਰ, ਭਾਵੇਂ ਬ੍ਰਾਊਜ਼ਰਾਂ ਦੁਆਰਾ ਸਮਰਥਿਤ ਹੈ, ਅਪ੍ਰਚਲਿਤ (obsolete) ਹੈ ਅਤੇ ਇਸ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ। | 2 | +| **3.4.7** | ਤਸਦੀਕ ਕਰੋ ਕਿ Content-Security-Policy ਹੈੱਡਰ ਖੇਤਰ ਉਲੰਘਣਾਵਾਂ ਦੀ ਰਿਪੋਰਟ ਕਰਨ ਲਈ ਇੱਕ ਟਿਕਾਣਾ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ। | 3 | +| **3.4.8** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੀਆਂ HTTP ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ ਜੋ ਦਸਤਾਵੇਜ਼ ਰੈਂਡਰਿੰਗ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ (ਜਿਵੇਂ ਕਿ Content-Type text/html ਵਾਲੀਆਂ ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ), ਲੋੜ ਅਨੁਸਾਰ same-origin ਨਿਰਦੇਸ਼ ਜਾਂ same-origin-allow-popups ਨਿਰਦੇਸ਼ ਦੇ ਨਾਲ Cross‑Origin‑Opener‑Policy ਹੈੱਡਰ ਖੇਤਰ ਸ਼ਾਮਲ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਉਹਨਾਂ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ Window ਆਬਜੈਕਟਾਂ ਤੱਕ ਸਾਂਝੀ ਪਹੁੰਚ ਦੀ ਦੁਰਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ tabnabbing ਅਤੇ frame counting। | 3 | + +## V3.5 Browser Origin Separation +## V3.5 ਬ੍ਰਾਊਜ਼ਰ ਓਰਿਜਿਨ ਵੱਖਰੇਵਾਂ + +When accepting a request to sensitive functionality on the server side, the application needs to ensure the request is initiated by the application itself or by a trusted party and has not been forged by an attacker. + +ਸਰਵਰ ਵਾਲੇ ਪਾਸੇ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਜਸ਼ੀਲਤਾ ਲਈ ਕੋਈ ਬੇਨਤੀ ਸਵੀਕਾਰ ਕਰਦੇ ਸਮੇਂ, ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ ਬੇਨਤੀ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਖ਼ੁਦ ਜਾਂ ਕਿਸੇ ਭਰੋਸੇਯੋਗ ਧਿਰ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੀ ਗਈ ਹੈ ਅਤੇ ਕਿਸੇ ਹਮਲਾਵਰ ਦੁਆਰਾ ਜਾਅਲੀ ਨਹੀਂ ਬਣਾਈ ਗਈ। + +Sensitive functionality in this context could include accepting form posts for authenticated and non-authenticated users (such as an authentication request), state-changing operations, or resource-demanding functionality (such as data export). + +ਇਸ ਸੰਦਰਭ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਜਸ਼ੀਲਤਾ ਵਿੱਚ ਪ੍ਰਮਾਣੀਕ੍ਰਿਤ (authenticated) ਅਤੇ ਗ਼ੈਰ-ਪ੍ਰਮਾਣੀਕ੍ਰਿਤ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਫ਼ਾਰਮ ਪੋਸਟਾਂ ਸਵੀਕਾਰ ਕਰਨਾ (ਜਿਵੇਂ ਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਬੇਨਤੀ), ਸਥਿਤੀ-ਬਦਲਣ ਵਾਲੇ ਕਾਰਜ, ਜਾਂ ਸਰੋਤ-ਮੰਗ ਵਾਲੀ ਕਾਰਜਸ਼ੀਲਤਾ (ਜਿਵੇਂ ਕਿ ਡਾਟਾ ਨਿਰਯਾਤ) ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ। + +The key protections here are browser security policies like Same Origin Policy for JavaScript and also SameSite logic for cookies. Another common protection is the CORS preflight mechanism. This mechanism will be critical for endpoints designed to be called from a different origin, but it can also be a useful request forgery prevention mechanism for endpoints which are not designed to be called from a different origin. + +ਇੱਥੇ ਮੁੱਖ ਸੁਰੱਖਿਆਵਾਂ JavaScript ਲਈ Same Origin Policy ਅਤੇ ਕੁਕੀਆਂ ਲਈ SameSite ਤਰਕ ਵਰਗੀਆਂ ਬ੍ਰਾਊਜ਼ਰ ਸੁਰੱਖਿਆ ਨੀਤੀਆਂ ਹਨ। ਇੱਕ ਹੋਰ ਆਮ ਸੁਰੱਖਿਆ CORS ਪ੍ਰੀਫ਼ਲਾਈਟ (preflight) ਪ੍ਰਣਾਲੀ ਹੈ। ਇਹ ਪ੍ਰਣਾਲੀ ਉਹਨਾਂ ਅੰਤ-ਬਿੰਦੂਆਂ ਲਈ ਅਤਿ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇਗੀ ਜੋ ਕਿਸੇ ਵੱਖਰੇ ਓਰਿਜਿਨ ਤੋਂ ਕਾਲ ਕੀਤੇ ਜਾਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਗਏ ਹਨ, ਪਰ ਇਹ ਉਹਨਾਂ ਅੰਤ-ਬਿੰਦੂਆਂ ਲਈ ਵੀ ਇੱਕ ਲਾਭਦਾਇਕ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ ਰੋਕਥਾਮ ਪ੍ਰਣਾਲੀ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਕਿਸੇ ਵੱਖਰੇ ਓਰਿਜਿਨ ਤੋਂ ਕਾਲ ਕੀਤੇ ਜਾਣ ਲਈ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਕੀਤੇ ਗਏ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.5.1** | Verify that, if the application does not rely on the CORS preflight mechanism to prevent disallowed cross-origin requests to use sensitive functionality, these requests are validated to ensure they originate from the application itself. This may be done by using and validating anti-forgery tokens or requiring extra HTTP header fields that are not CORS-safelisted request-header fields. This is to defend against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF). | 1 | +| **3.5.2** | Verify that, if the application relies on the CORS preflight mechanism to prevent disallowed cross-origin use of sensitive functionality, it is not possible to call the functionality with a request which does not trigger a CORS-preflight request. This may require checking the values of the 'Origin' and 'Content-Type' request header fields or using an extra header field that is not a CORS-safelisted header-field. | 1 | +| **3.5.3** | Verify that HTTP requests to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH, or DELETE, and not methods defined by the HTTP specification as "safe" such as HEAD, OPTIONS, or GET. Alternatively, strict validation of the Sec-Fetch-* request header fields can be used to ensure that the request did not originate from an inappropriate cross-origin call, a navigation request, or a resource load (such as an image source) where this is not expected. | 1 | +| **3.5.4** | Verify that separate applications are hosted on different hostnames to leverage the restrictions provided by same-origin policy, including how documents or scripts loaded by one origin can interact with resources from another origin and hostname-based restrictions on cookies. | 2 | +| **3.5.5** | Verify that messages received by the postMessage interface are discarded if the origin of the message is not trusted, or if the syntax of the message is invalid. | 2 | +| **3.5.6** | Verify that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks. | 3 | +| **3.5.7** | Verify that data requiring authorization is not included in script resource responses, like JavaScript files, to prevent Cross-Site Script Inclusion (XSSI) attacks. | 3 | +| **3.5.8** | Verify that authenticated resources (such as images, videos, scripts, and other documents) can be loaded or embedded on behalf of the user only when intended. This can be accomplished by strict validation of the Sec-Fetch-* HTTP request header fields to ensure that the request did not originate from an inappropriate cross-origin call, or by setting a restrictive Cross-Origin-Resource-Policy HTTP response header field to instruct the browser to block returned content. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **3.5.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਜਸ਼ੀਲਤਾ ਵਰਤਣ ਵਾਲੀਆਂ ਅਣ-ਇਜਾਜ਼ਤਸ਼ੁਦਾ ਕਰਾਸ-ਓਰਿਜਿਨ ਬੇਨਤੀਆਂ ਨੂੰ ਰੋਕਣ ਲਈ CORS ਪ੍ਰੀਫ਼ਲਾਈਟ ਪ੍ਰਣਾਲੀ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦੀ, ਤਾਂ ਇਹਨਾਂ ਬੇਨਤੀਆਂ ਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਹੀ ਉਤਪੰਨ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਜਾਅਲਸਾਜ਼ੀ-ਰੋਕੂ ਟੋਕਨਾਂ ਨੂੰ ਵਰਤ ਕੇ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਕੇ ਜਾਂ ਅਜਿਹੇ ਵਾਧੂ HTTP ਹੈੱਡਰ ਖੇਤਰਾਂ ਦੀ ਲੋੜ ਰੱਖ ਕੇ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੋ CORS-safelisted ਬੇਨਤੀ-ਹੈੱਡਰ ਖੇਤਰ ਨਹੀਂ ਹਨ। ਇਹ ਬ੍ਰਾਊਜ਼ਰ-ਆਧਾਰਿਤ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ ਹਮਲਿਆਂ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਕਰਾਸ-ਸਾਈਟ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ (CSRF) ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਤੋਂ ਬਚਾਅ ਲਈ ਹੈ। | 1 | +| **3.5.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਅਣ-ਇਜਾਜ਼ਤਸ਼ੁਦਾ ਕਰਾਸ-ਓਰਿਜਿਨ ਵਰਤੋਂ ਨੂੰ ਰੋਕਣ ਲਈ CORS ਪ੍ਰੀਫ਼ਲਾਈਟ ਪ੍ਰਣਾਲੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਅਜਿਹੀ ਬੇਨਤੀ ਨਾਲ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਕਾਲ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਹੈ ਜੋ CORS-ਪ੍ਰੀਫ਼ਲਾਈਟ ਬੇਨਤੀ ਨੂੰ ਟ੍ਰਿਗਰ ਨਹੀਂ ਕਰਦੀ। ਇਸ ਲਈ 'Origin' ਅਤੇ 'Content-Type' ਬੇਨਤੀ ਹੈੱਡਰ ਖੇਤਰਾਂ ਦੇ ਮੁੱਲਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਜਾਂ ਅਜਿਹੇ ਵਾਧੂ ਹੈੱਡਰ ਖੇਤਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਜੋ CORS-safelisted ਹੈੱਡਰ-ਖੇਤਰ ਨਹੀਂ ਹੈ। | 1 | +| **3.5.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਜਸ਼ੀਲਤਾ ਲਈ HTTP ਬੇਨਤੀਆਂ ਢੁਕਵੇਂ HTTP ਮੈਥਡ (method) ਜਿਵੇਂ ਕਿ POST, PUT, PATCH, ਜਾਂ DELETE ਵਰਤਦੀਆਂ ਹਨ, ਨਾ ਕਿ HTTP ਨਿਰਧਾਰਨ ਦੁਆਰਾ "ਸੁਰੱਖਿਅਤ" ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਮੈਥਡ ਜਿਵੇਂ ਕਿ HEAD, OPTIONS, ਜਾਂ GET। ਵਿਕਲਪਕ ਤੌਰ 'ਤੇ, Sec-Fetch-* ਬੇਨਤੀ ਹੈੱਡਰ ਖੇਤਰਾਂ ਨੂੰ ਸਖ਼ਤੀ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰਕੇ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਕਿਸੇ ਅਣਉਚਿਤ ਕਰਾਸ-ਓਰਿਜਿਨ ਕਾਲ, ਨੈਵੀਗੇਸ਼ਨ ਬੇਨਤੀ, ਜਾਂ ਸਰੋਤ ਲੋਡ (ਜਿਵੇਂ ਕਿ ਚਿੱਤਰ ਸਰੋਤ) ਤੋਂ ਉਤਪੰਨ ਨਹੀਂ ਹੋਈ ਜਿੱਥੇ ਇਸ ਦੀ ਉਮੀਦ ਨਹੀਂ ਹੈ। | 1 | +| **3.5.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਵੱਖਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵੱਖ-ਵੱਖ ਹੋਸਟਨੇਮਾਂ 'ਤੇ ਹੋਸਟ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ ਤਾਂ ਜੋ same-origin policy ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਪਾਬੰਦੀਆਂ ਦਾ ਲਾਭ ਲਿਆ ਜਾ ਸਕੇ, ਜਿਸ ਵਿੱਚ ਇਹ ਸ਼ਾਮਲ ਹੈ ਕਿ ਇੱਕ ਓਰਿਜਿਨ ਦੁਆਰਾ ਲੋਡ ਕੀਤੇ ਦਸਤਾਵੇਜ਼ ਜਾਂ ਸਕ੍ਰਿਪਟਾਂ ਕਿਸੇ ਹੋਰ ਓਰਿਜਿਨ ਦੇ ਸਰੋਤਾਂ ਨਾਲ ਕਿਵੇਂ ਆਪਸੀ ਕਿਰਿਆ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਕੁਕੀਆਂ 'ਤੇ ਹੋਸਟਨੇਮ-ਆਧਾਰਿਤ ਪਾਬੰਦੀਆਂ। | 2 | +| **3.5.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ postMessage ਇੰਟਰਫ਼ੇਸ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੇ ਸੁਨੇਹੇ ਰੱਦ ਕਰ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ ਜੇ ਸੁਨੇਹੇ ਦਾ ਓਰਿਜਿਨ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੈ, ਜਾਂ ਜੇ ਸੁਨੇਹੇ ਦਾ ਸਿੰਟੈਕਸ ਅਵੈਧ ਹੈ। | 2 | +| **3.5.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ Cross-Site Script Inclusion (XSSI) ਹਮਲਿਆਂ ਤੋਂ ਬਚਣ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਕਿਤੇ ਵੀ JSONP ਕਾਰਜਸ਼ੀਲਤਾ ਸਮਰੱਥ ਨਹੀਂ ਹੈ। | 3 | +| **3.5.7** | ਤਸਦੀਕ ਕਰੋ ਕਿ Cross-Site Script Inclusion (XSSI) ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ, ਅਧਿਕਾਰੀਕਰਨ ਦੀ ਲੋੜ ਵਾਲਾ ਡਾਟਾ ਸਕ੍ਰਿਪਟ ਸਰੋਤ ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ, ਜਿਵੇਂ ਕਿ JavaScript ਫ਼ਾਈਲਾਂ, ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ। | 3 | +| **3.5.8** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪ੍ਰਮਾਣੀਕ੍ਰਿਤ ਸਰੋਤ (ਜਿਵੇਂ ਕਿ ਚਿੱਤਰ, ਵੀਡੀਓ, ਸਕ੍ਰਿਪਟਾਂ, ਅਤੇ ਹੋਰ ਦਸਤਾਵੇਜ਼) ਉਪਭੋਗਤਾ ਦੀ ਤਰਫ਼ੋਂ ਕੇਵਲ ਉਦੋਂ ਹੀ ਲੋਡ ਜਾਂ ਏਮਬੈੱਡ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਜਦੋਂ ਅਜਿਹਾ ਇਰਾਦਾ ਹੋਵੇ। ਇਹ Sec-Fetch-* HTTP ਬੇਨਤੀ ਹੈੱਡਰ ਖੇਤਰਾਂ ਨੂੰ ਸਖ਼ਤੀ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰਕੇ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਬੇਨਤੀ ਕਿਸੇ ਅਣਉਚਿਤ ਕਰਾਸ-ਓਰਿਜਿਨ ਕਾਲ ਤੋਂ ਉਤਪੰਨ ਨਹੀਂ ਹੋਈ, ਜਾਂ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਵਾਪਸ ਕੀਤੀ ਸਮੱਗਰੀ ਨੂੰ ਰੋਕਣ ਦਾ ਨਿਰਦੇਸ਼ ਦੇਣ ਲਈ ਇੱਕ ਪ੍ਰਤਿਬੰਧਕ Cross-Origin-Resource-Policy HTTP ਪ੍ਰਤੀਕਿਰਿਆ ਹੈੱਡਰ ਖੇਤਰ ਸੈੱਟ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। | 3 | + +## V3.6 External Resource Integrity +## V3.6 ਬਾਹਰੀ ਸਰੋਤ ਅਖੰਡਤਾ + +This section provides guidance for the safe hosting of content on third-party sites. + +ਇਹ ਭਾਗ ਤੀਜੀ-ਧਿਰ ਸਾਈਟਾਂ 'ਤੇ ਸਮੱਗਰੀ ਦੀ ਸੁਰੱਖਿਅਤ ਹੋਸਟਿੰਗ ਲਈ ਮਾਰਗਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.6.1** | Verify that client-side assets, such as JavaScript libraries, CSS, or web fonts, are only hosted externally (e.g., on a Content Delivery Network) if the resource is static and versioned and Subresource Integrity (SRI) is used to validate the integrity of the asset. If this is not possible, there should be a documented security decision to justify this for each resource. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **3.6.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਲਾਇੰਟ-ਸਾਈਡ ਸੰਪਤੀਆਂ (assets), ਜਿਵੇਂ ਕਿ JavaScript ਲਾਇਬ੍ਰੇਰੀਆਂ, CSS, ਜਾਂ ਵੈੱਬ ਫ਼ੌਂਟ, ਕੇਵਲ ਤਾਂ ਹੀ ਬਾਹਰੀ ਤੌਰ 'ਤੇ ਹੋਸਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ (ਜਿਵੇਂ ਕਿ, ਕਿਸੇ Content Delivery Network 'ਤੇ) ਜੇ ਸਰੋਤ ਸਥਿਰ ਅਤੇ ਸੰਸਕਰਣਬੱਧ ਹੈ ਅਤੇ ਸੰਪਤੀ ਦੀ ਅਖੰਡਤਾ (integrity) ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਲਈ Subresource Integrity (SRI) ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਜੇ ਇਹ ਸੰਭਵ ਨਹੀਂ ਹੈ, ਤਾਂ ਹਰੇਕ ਸਰੋਤ ਲਈ ਇਸ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਣ ਵਾਲਾ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। | 3 | + +## V3.7 Other Browser Security Considerations +## V3.7 ਹੋਰ ਬ੍ਰਾਊਜ਼ਰ ਸੁਰੱਖਿਆ ਵਿਚਾਰ + +This section includes various other security controls and modern browser security features required for client-side browser security. + +ਇਸ ਭਾਗ ਵਿੱਚ ਕਲਾਇੰਟ-ਸਾਈਡ ਬ੍ਰਾਊਜ਼ਰ ਸੁਰੱਖਿਆ ਲਈ ਲੋੜੀਂਦੇ ਵੱਖ-ਵੱਖ ਹੋਰ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਅਤੇ ਆਧੁਨਿਕ ਬ੍ਰਾਊਜ਼ਰ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ਾਮਲ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **3.7.1** | Verify that the application only uses client-side technologies which are still supported and considered secure. Examples of technologies which do not meet this requirement include NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets. | 2 | +| **3.7.2** | Verify that the application will only automatically redirect the user to a different hostname or domain (which is not controlled by the application) where the destination appears on an allowlist. | 2 | +| **3.7.3** | Verify that the application shows a notification when the user is being redirected to a URL outside of the application's control, with an option to cancel the navigation. | 3 | +| **3.7.4** | Verify that the application's top-level domain (e.g., site.tld) is added to the public preload list for HTTP Strict Transport Security (HSTS). This ensures that the use of TLS for the application is built directly into the main browsers, rather than relying only on the Strict-Transport-Security response header field. | 3 | +| **3.7.5** | Verify that the application behaves as documented (such as warning the user or blocking access) if the browser used to access the application does not support the expected security features. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **3.7.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕੇਵਲ ਉਹੀ ਕਲਾਇੰਟ-ਸਾਈਡ ਤਕਨਾਲੋਜੀਆਂ ਵਰਤਦੀ ਹੈ ਜੋ ਅਜੇ ਵੀ ਸਮਰਥਿਤ ਹਨ ਅਤੇ ਸੁਰੱਖਿਅਤ ਮੰਨੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਇਸ ਲੋੜ ਨੂੰ ਪੂਰਾ ਨਾ ਕਰਨ ਵਾਲੀਆਂ ਤਕਨਾਲੋਜੀਆਂ ਦੀਆਂ ਉਦਾਹਰਨਾਂ ਵਿੱਚ NSAPI ਪਲੱਗਇਨ, Flash, Shockwave, ActiveX, Silverlight, NACL, ਜਾਂ ਕਲਾਇੰਟ-ਸਾਈਡ Java ਐਪਲੈੱਟ ਸ਼ਾਮਲ ਹਨ। | 2 | +| **3.7.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਉਪਭੋਗਤਾ ਨੂੰ ਕਿਸੇ ਵੱਖਰੇ ਹੋਸਟਨੇਮ ਜਾਂ ਡੋਮੇਨ (ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਹੈ) ਵੱਲ ਕੇਵਲ ਉਦੋਂ ਹੀ ਸਵੈਚਾਲਿਤ ਤੌਰ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰੇਗੀ ਜਦੋਂ ਮੰਜ਼ਿਲ ਕਿਸੇ allowlist ਵਿੱਚ ਦਰਜ ਹੋਵੇ। | 2 | +| **3.7.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਦੋਂ ਉਪਭੋਗਤਾ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਿਯੰਤਰਣ ਤੋਂ ਬਾਹਰ ਕਿਸੇ URL ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੋਵੇ ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਸੂਚਨਾ ਦਿਖਾਉਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਨੈਵੀਗੇਸ਼ਨ ਰੱਦ ਕਰਨ ਦਾ ਵਿਕਲਪ ਹੁੰਦਾ ਹੈ। | 3 | +| **3.7.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਸਿਖਰ-ਪੱਧਰੀ ਡੋਮੇਨ (ਜਿਵੇਂ ਕਿ, site.tld) HTTP Strict Transport Security (HSTS) ਲਈ ਜਨਤਕ ਪ੍ਰੀਲੋਡ ਸੂਚੀ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਲਈ TLS ਦੀ ਵਰਤੋਂ ਕੇਵਲ Strict-Transport-Security ਪ੍ਰਤੀਕਿਰਿਆ ਹੈੱਡਰ ਖੇਤਰ 'ਤੇ ਨਿਰਭਰ ਰਹਿਣ ਦੀ ਬਜਾਏ ਸਿੱਧੇ ਮੁੱਖ ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ ਹੀ ਬਣਾਈ ਗਈ ਹੈ। | 3 | +| **3.7.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ ਵਰਤਿਆ ਗਿਆ ਬ੍ਰਾਊਜ਼ਰ ਉਮੀਦ ਕੀਤੀਆਂ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਅਨੁਸਾਰ ਵਿਹਾਰ ਕਰਦੀ ਹੈ (ਜਿਵੇਂ ਕਿ ਉਪਭੋਗਤਾ ਨੂੰ ਚੇਤਾਵਨੀ ਦੇਣਾ ਜਾਂ ਪਹੁੰਚ ਨੂੰ ਰੋਕਣਾ)। | 3 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [Set-Cookie __Host- prefix details](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes) +* [OWASP Content Security Policy Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) +* [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/) +* [OWASP Cross-Site Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) +* [HSTS Browser Preload List submission form](https://hstspreload.org/) +* [OWASP DOM Clobbering Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html) diff --git a/5.0/pa-IN/0x13-V4-API-and-Web-Service.md b/5.0/pa-IN/0x13-V4-API-and-Web-Service.md new file mode 100644 index 0000000000..a3a5206e80 --- /dev/null +++ b/5.0/pa-IN/0x13-V4-API-and-Web-Service.md @@ -0,0 +1,121 @@ + + + + +# V4 API and Web Service +# V4 API ਅਤੇ ਵੈੱਬ ਸੇਵਾ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +Several considerations apply specifically to applications that expose APIs for use by web browsers or other consumers (commonly using JSON, XML, or GraphQL). This chapter covers the relevant security configurations and mechanisms that should be applied. + +ਕਈ ਵਿਚਾਰ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ ਜੋ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰਾਂ ਜਾਂ ਹੋਰ ਖਪਤਕਾਰਾਂ (consumers) ਦੁਆਰਾ ਵਰਤੋਂ ਲਈ API ਉਜਾਗਰ ਕਰਦੀਆਂ ਹਨ (ਆਮ ਤੌਰ 'ਤੇ JSON, XML, ਜਾਂ GraphQL ਦੀ ਵਰਤੋਂ ਕਰਕੇ)। ਇਹ ਅਧਿਆਇ ਉਹਨਾਂ ਸੰਬੰਧਿਤ ਸੁਰੱਖਿਆ ਸੰਰਚਨਾਵਾਂ (configurations) ਅਤੇ ਪ੍ਰਣਾਲੀਆਂ (mechanisms) ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ ਜੋ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। + +Note that authentication, session management, and input validation concerns from other chapters also apply to APIs, so this chapter cannot be taken out of context or tested in isolation. + +ਧਿਆਨ ਦਿਓ ਕਿ ਹੋਰ ਅਧਿਆਵਾਂ ਦੇ ਪ੍ਰਮਾਣੀਕਰਨ, ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ, ਅਤੇ ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ ਸੰਬੰਧੀ ਸਰੋਕਾਰ ਵੀ API 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਇਸ ਅਧਿਆਇ ਨੂੰ ਸੰਦਰਭ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਲਿਆ ਜਾ ਸਕਦਾ ਜਾਂ ਇਕੱਲਿਆਂ ਟੈਸਟ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। + +## V4.1 Generic Web Service Security +## V4.1 ਆਮ ਵੈੱਬ ਸੇਵਾ ਸੁਰੱਖਿਆ + +This section addresses general web service security considerations and, consequently, basic web service hygiene practices. + +ਇਹ ਭਾਗ ਆਮ ਵੈੱਬ ਸੇਵਾ ਸੁਰੱਖਿਆ ਵਿਚਾਰਾਂ ਨੂੰ ਅਤੇ, ਨਤੀਜੇ ਵਜੋਂ, ਬੁਨਿਆਦੀ ਵੈੱਬ ਸੇਵਾ ਸਫ਼ਾਈ (hygiene) ਅਮਲਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **4.1.1** | Verify that every HTTP response with a message body contains a Content-Type header field that matches the actual content of the response, including the charset parameter to specify safe character encoding (e.g., UTF-8, ISO-8859-1) according to IANA Media Types, such as "text/", "/+xml" and "/xml". | 1 | +| **4.1.2** | Verify that only user-facing endpoints (intended for manual web-browser access) automatically redirect from HTTP to HTTPS, while other services or endpoints do not implement transparent redirects. This is to avoid a situation where a client is erroneously sending unencrypted HTTP requests, but since the requests are being automatically redirected to HTTPS, the leakage of sensitive data goes undiscovered. | 2 | +| **4.1.3** | Verify that any HTTP header field used by the application and set by an intermediary layer, such as a load balancer, a web proxy, or a backend-for-frontend service, cannot be overridden by the end-user. Example headers might include X-Real-IP, X-Forwarded-*, or X-User-ID. | 2 | +| **4.1.4** | Verify that only HTTP methods that are explicitly supported by the application or its API (including OPTIONS during preflight requests) can be used and that unused methods are blocked. | 3 | +| **4.1.5** | Verify that per-message digital signatures are used to provide additional assurance on top of transport protections for requests or transactions which are highly sensitive or which traverse a number of systems. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **4.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੁਨੇਹਾ ਬਾਡੀ (message body) ਵਾਲੇ ਹਰੇਕ HTTP ਜਵਾਬ ਵਿੱਚ ਇੱਕ Content-Type ਹੈੱਡਰ ਖੇਤਰ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਜੋ ਜਵਾਬ ਦੀ ਅਸਲ ਸਮੱਗਰੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ IANA Media Types ਦੇ ਅਨੁਸਾਰ, ਜਿਵੇਂ ਕਿ "text/", "/+xml" ਅਤੇ "/xml", ਸੁਰੱਖਿਅਤ ਅੱਖਰ ਏਨਕੋਡਿੰਗ (ਜਿਵੇਂ ਕਿ UTF-8, ISO-8859-1) ਨਿਰਧਾਰਿਤ ਕਰਨ ਲਈ charset ਪੈਰਾਮੀਟਰ ਵੀ ਸ਼ਾਮਲ ਹੈ। | 1 | +| **4.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਿਰਫ਼ ਉਪਭੋਗਤਾ-ਮੁਖੀ ਅੰਤ-ਬਿੰਦੂ (endpoints) (ਜੋ ਹੱਥੀਂ ਵੈੱਬ-ਬ੍ਰਾਊਜ਼ਰ ਪਹੁੰਚ ਲਈ ਬਣਾਏ ਗਏ ਹਨ) ਹੀ HTTP ਤੋਂ HTTPS ਵੱਲ ਆਪਣੇ-ਆਪ ਰੀਡਾਇਰੈਕਟ ਕਰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਹੋਰ ਸੇਵਾਵਾਂ ਜਾਂ ਅੰਤ-ਬਿੰਦੂ ਪਾਰਦਰਸ਼ੀ ਰੀਡਾਇਰੈਕਟ ਲਾਗੂ ਨਹੀਂ ਕਰਦੇ। ਇਹ ਅਜਿਹੀ ਸਥਿਤੀ ਤੋਂ ਬਚਣ ਲਈ ਹੈ ਜਿੱਥੇ ਕੋਈ ਕਲਾਇੰਟ ਗਲਤੀ ਨਾਲ ਏਨਕ੍ਰਿਪਟ ਨਾ ਕੀਤੀਆਂ HTTP ਬੇਨਤੀਆਂ ਭੇਜ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਕਿਉਂਕਿ ਬੇਨਤੀਆਂ ਆਪਣੇ-ਆਪ HTTPS ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਹੋ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਦੀ ਲੀਕੇਜ ਅਣਖੋਜੀ ਰਹਿ ਜਾਂਦੀ ਹੈ। | 2 | +| **4.1.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਅਤੇ ਕਿਸੇ ਵਿਚੋਲੀ ਪਰਤ, ਜਿਵੇਂ ਕਿ ਲੋਡ ਬੈਲੈਂਸਰ, ਵੈੱਬ ਪ੍ਰੌਕਸੀ, ਜਾਂ backend-for-frontend ਸੇਵਾ, ਦੁਆਰਾ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਕੋਈ ਵੀ HTTP ਹੈੱਡਰ ਖੇਤਰ ਅੰਤਮ-ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਓਵਰਰਾਈਡ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਉਦਾਹਰਨ ਹੈੱਡਰਾਂ ਵਿੱਚ X-Real-IP, X-Forwarded-*, ਜਾਂ X-User-ID ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ। | 2 | +| **4.1.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਿਰਫ਼ ਉਹੀ HTTP ਮੈਥਡ (methods) ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਇਸ ਦੇ API ਦੁਆਰਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸਮਰਥਿਤ ਹਨ (ਪ੍ਰੀਫ਼ਲਾਈਟ ਬੇਨਤੀਆਂ ਦੌਰਾਨ OPTIONS ਸਮੇਤ) ਅਤੇ ਅਣਵਰਤੇ ਮੈਥਡ ਬਲੌਕ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। | 3 | +| **4.1.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਹਨਾਂ ਬੇਨਤੀਆਂ ਜਾਂ ਲੈਣ-ਦੇਣਾਂ ਲਈ, ਜੋ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੰਵੇਦਨਸ਼ੀਲ ਹਨ ਜਾਂ ਜੋ ਕਈ ਸਿਸਟਮਾਂ ਵਿੱਚੋਂ ਲੰਘਦੀਆਂ ਹਨ, ਟ੍ਰਾਂਸਪੋਰਟ ਸੁਰੱਖਿਆਵਾਂ ਦੇ ਉੱਪਰ ਵਾਧੂ ਭਰੋਸਾ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਪ੍ਰਤੀ-ਸੁਨੇਹਾ ਡਿਜ਼ੀਟਲ ਦਸਤਖ਼ਤ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। | 3 | + +## V4.2 HTTP Message Structure Validation +## V4.2 HTTP ਸੁਨੇਹਾ ਢਾਂਚਾ ਪ੍ਰਮਾਣਿਕਤਾ + +This section explains how the structure and header fields of an HTTP message should be validated to prevent attacks such as request smuggling, response splitting, header injection, and denial of service via overly long HTTP messages. + +ਇਹ ਭਾਗ ਸਮਝਾਉਂਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਸਮਗਲਿੰਗ (request smuggling), ਜਵਾਬ ਵਿਭਾਜਨ (response splitting), ਹੈੱਡਰ ਇੰਜੈਕਸ਼ਨ (header injection), ਅਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੰਬੇ HTTP ਸੁਨੇਹਿਆਂ ਰਾਹੀਂ ਸੇਵਾ-ਇਨਕਾਰ (denial of service) ਵਰਗੇ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਕਿਸੇ HTTP ਸੁਨੇਹੇ (message) ਦੇ ਢਾਂਚੇ ਅਤੇ ਹੈੱਡਰ ਖੇਤਰਾਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। + +These requirements are relevant for general HTTP message processing and generation, but are especially important when converting HTTP messages between different HTTP versions. + +ਇਹ ਲੋੜਾਂ ਆਮ HTTP ਸੁਨੇਹੇ ਪ੍ਰੋਸੈਸ ਕਰਨ ਅਤੇ ਬਣਾਉਣ ਲਈ ਸੰਬੰਧਿਤ ਹਨ, ਪਰ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਉਦੋਂ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ HTTP ਸੁਨੇਹਿਆਂ ਨੂੰ ਵੱਖ-ਵੱਖ HTTP ਸੰਸਕਰਣਾਂ ਦੇ ਵਿਚਕਾਰ ਰੂਪਾਂਤਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **4.2.1** | Verify that all application components (including load balancers, firewalls, and application servers) determine boundaries of incoming HTTP messages using the appropriate mechanism for the HTTP version to prevent HTTP request smuggling. In HTTP/1.x, if a Transfer-Encoding header field is present, the Content-Length header must be ignored per RFC 2616. When using HTTP/2 or HTTP/3, if a Content-Length header field is present, the receiver must ensure that it is consistent with the length of the DATA frames. | 2 | +| **4.2.2** | Verify that when generating HTTP messages, the Content-Length header field does not conflict with the length of the content as determined by the framing of the HTTP protocol, in order to prevent request smuggling attacks. | 3 | +| **4.2.3** | Verify that the application does not send nor accept HTTP/2 or HTTP/3 messages with connection-specific header fields such as Transfer-Encoding to prevent response splitting and header injection attacks. | 3 | +| **4.2.4** | Verify that the application only accepts HTTP/2 and HTTP/3 requests where the header fields and values do not contain any CR (\r), LF (\n), or CRLF (\r\n) sequences, to prevent header injection attacks. | 3 | +| **4.2.5** | Verify that, if the application (backend or frontend) builds and sends requests, it uses validation, sanitization, or other mechanisms to avoid creating URIs (such as for API calls) or HTTP request header fields (such as Authorization or Cookie), which are too long to be accepted by the receiving component. This could cause a denial of service, such as when sending an overly long request (e.g., a long cookie header field), which results in the server always responding with an error status. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **4.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੇ ਐਪਲੀਕੇਸ਼ਨ ਘਟਕ (components) (ਲੋਡ ਬੈਲੈਂਸਰ, ਫ਼ਾਇਰਵਾਲ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਸਮੇਤ) HTTP ਬੇਨਤੀ ਸਮਗਲਿੰਗ ਨੂੰ ਰੋਕਣ ਲਈ HTTP ਸੰਸਕਰਣ ਲਈ ਢੁਕਵੀਂ ਪ੍ਰਣਾਲੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਉਣ ਵਾਲੇ HTTP ਸੁਨੇਹਿਆਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨਿਰਧਾਰਿਤ ਕਰਦੇ ਹਨ। HTTP/1.x ਵਿੱਚ, ਜੇ Transfer-Encoding ਹੈੱਡਰ ਖੇਤਰ ਮੌਜੂਦ ਹੈ, ਤਾਂ RFC 2616 ਦੇ ਅਨੁਸਾਰ Content-Length ਹੈੱਡਰ ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਅਣਡਿੱਠ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। HTTP/2 ਜਾਂ HTTP/3 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਜੇ Content-Length ਹੈੱਡਰ ਖੇਤਰ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ DATA ਫ਼੍ਰੇਮਾਂ ਦੀ ਲੰਬਾਈ ਨਾਲ ਇਕਸਾਰ ਹੈ। | 2 | +| **4.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ HTTP ਸੁਨੇਹੇ ਬਣਾਉਂਦੇ ਸਮੇਂ, ਬੇਨਤੀ ਸਮਗਲਿੰਗ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ, Content-Length ਹੈੱਡਰ ਖੇਤਰ HTTP ਪ੍ਰੋਟੋਕਾਲ ਦੀ ਫ਼੍ਰੇਮਿੰਗ ਦੁਆਰਾ ਨਿਰਧਾਰਿਤ ਸਮੱਗਰੀ ਦੀ ਲੰਬਾਈ ਨਾਲ ਟਕਰਾਉਂਦਾ ਨਹੀਂ ਹੈ। | 3 | +| **4.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਵਾਬ ਵਿਭਾਜਨ ਅਤੇ ਹੈੱਡਰ ਇੰਜੈਕਸ਼ਨ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਐਪਲੀਕੇਸ਼ਨ Transfer-Encoding ਵਰਗੇ ਕਨੈਕਸ਼ਨ-ਵਿਸ਼ੇਸ਼ ਹੈੱਡਰ ਖੇਤਰਾਂ ਵਾਲੇ HTTP/2 ਜਾਂ HTTP/3 ਸੁਨੇਹੇ ਨਾ ਤਾਂ ਭੇਜਦੀ ਹੈ ਅਤੇ ਨਾ ਹੀ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ। | 3 | +| **4.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸਿਰਫ਼ ਉਹੀ HTTP/2 ਅਤੇ HTTP/3 ਬੇਨਤੀਆਂ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦੇ ਹੈੱਡਰ ਖੇਤਰਾਂ ਅਤੇ ਮੁੱਲਾਂ ਵਿੱਚ ਕੋਈ CR (\r), LF (\n), ਜਾਂ CRLF (\r\n) ਲੜੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਤਾਂ ਜੋ ਹੈੱਡਰ ਇੰਜੈਕਸ਼ਨ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। | 3 | +| **4.2.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ ਐਪਲੀਕੇਸ਼ਨ (ਬੈਕਐਂਡ ਜਾਂ ਫਰੰਟਐਂਡ) ਬੇਨਤੀਆਂ ਬਣਾਉਂਦੀ ਅਤੇ ਭੇਜਦੀ ਹੈ, ਤਾਂ ਇਹ ਅਜਿਹੇ URI (ਜਿਵੇਂ ਕਿ API ਕਾਲਾਂ ਲਈ) ਜਾਂ HTTP ਬੇਨਤੀ ਹੈੱਡਰ ਖੇਤਰ (ਜਿਵੇਂ ਕਿ Authorization ਜਾਂ Cookie) ਬਣਾਉਣ ਤੋਂ ਬਚਣ ਲਈ, ਜੋ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਘਟਕ ਦੁਆਰਾ ਸਵੀਕਾਰ ਕੀਤੇ ਜਾਣ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੰਬੇ ਹੋਣ, ਪ੍ਰਮਾਣਿਕਤਾ, ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ, ਜਾਂ ਹੋਰ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਇਹ ਸੇਵਾ-ਇਨਕਾਰ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਜਦੋਂ ਕੋਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੰਬੀ ਬੇਨਤੀ (ਜਿਵੇਂ ਕਿ ਇੱਕ ਲੰਬਾ cookie ਹੈੱਡਰ ਖੇਤਰ) ਭੇਜੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਸਰਵਰ ਹਮੇਸ਼ਾ ਇੱਕ ਗਲਤੀ ਸਥਿਤੀ (error status) ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। | 3 | + +## V4.3 GraphQL +## V4.3 GraphQL (ਗ੍ਰਾਫ਼ਕਿਊਐੱਲ) + +GraphQL is becoming more common as a way of creating data-rich clients that are not tightly coupled to a variety of backend services. This section covers security considerations for GraphQL. + +GraphQL ਅਜਿਹੇ ਡਾਟਾ-ਭਰਪੂਰ ਕਲਾਇੰਟ ਬਣਾਉਣ ਦੇ ਇੱਕ ਢੰਗ ਵਜੋਂ ਵਧੇਰੇ ਆਮ ਹੁੰਦਾ ਜਾ ਰਿਹਾ ਹੈ ਜੋ ਵੱਖ-ਵੱਖ ਬੈਕਐਂਡ ਸੇਵਾਵਾਂ ਨਾਲ ਸਖ਼ਤੀ ਨਾਲ ਜੁੜੇ ਹੋਏ (tightly coupled) ਨਹੀਂ ਹੁੰਦੇ। ਇਹ ਭਾਗ GraphQL ਲਈ ਸੁਰੱਖਿਆ ਵਿਚਾਰਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **4.3.1** | Verify that a query allowlist, depth limiting, amount limiting, or query cost analysis is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries. | 2 | +| **4.3.2** | Verify that GraphQL introspection queries are disabled in the production environment unless the GraphQL API is meant to be used by other parties. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **4.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਮਹਿੰਗੀਆਂ, ਨੇਸਟਡ (nested) ਕਿਊਰੀਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਹੋਣ ਵਾਲੇ GraphQL ਜਾਂ ਡਾਟਾ ਪਰਤ ਐਕਸਪ੍ਰੈਸ਼ਨ ਸੇਵਾ-ਇਨਕਾਰ (Denial of Service, DoS) ਨੂੰ ਰੋਕਣ ਲਈ ਇੱਕ ਕਿਊਰੀ allowlist, ਡੂੰਘਾਈ ਸੀਮਾਬੰਦੀ, ਮਾਤਰਾ ਸੀਮਾਬੰਦੀ, ਜਾਂ ਕਿਊਰੀ ਲਾਗਤ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। | 2 | +| **4.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣ ਵਿੱਚ GraphQL introspection ਕਿਊਰੀਆਂ ਅਸਮਰੱਥ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਜਦੋਂ ਤੱਕ ਕਿ GraphQL API ਹੋਰ ਧਿਰਾਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਲਈ ਨਾ ਹੋਵੇ। | 2 | + +## V4.4 WebSocket +## V4.4 WebSocket (ਵੈੱਬਸਾਕਟ) + +WebSocket is a communications protocol that provides a simultaneous two-way communication channel over a single TCP connection. It was standardized by the IETF as RFC 6455 in 2011 and is distinct from HTTP, even though it is designed to work over HTTP ports 443 and 80. + +WebSocket ਇੱਕ ਸੰਚਾਰ ਪ੍ਰੋਟੋਕਾਲ ਹੈ ਜੋ ਇੱਕ ਸਿੰਗਲ TCP ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਇੱਕੋ ਸਮੇਂ ਦੋ-ਪਾਸੜ ਸੰਚਾਰ ਚੈਨਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਸ ਨੂੰ IETF ਦੁਆਰਾ 2011 ਵਿੱਚ RFC 6455 ਵਜੋਂ ਮਿਆਰੀਕ੍ਰਿਤ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਇਹ HTTP ਤੋਂ ਵੱਖਰਾ ਹੈ, ਭਾਵੇਂ ਇਹ HTTP ਪੋਰਟਾਂ 443 ਅਤੇ 80 ਉੱਤੇ ਕੰਮ ਕਰਨ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ। + +This section provides key security requirements to prevent attacks related to communication security and session management that specifically exploit this real-time communication channel. + +ਇਹ ਭਾਗ ਸੰਚਾਰ ਸੁਰੱਖਿਆ ਅਤੇ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਨਾਲ ਸੰਬੰਧਿਤ ਉਹਨਾਂ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਮੁੱਖ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਇਸ ਰੀਅਲ-ਟਾਈਮ ਸੰਚਾਰ ਚੈਨਲ ਦਾ ਸ਼ੋਸ਼ਣ (exploit) ਕਰਦੇ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **4.4.1** | Verify that WebSocket over TLS (WSS) is used for all WebSocket connections. | 1 | +| **4.4.2** | Verify that, during the initial HTTP WebSocket handshake, the Origin header field is checked against a list of origins allowed for the application. | 2 | +| **4.4.3** | Verify that, if the application's standard session management cannot be used, dedicated tokens are being used for this, which comply with the relevant Session Management security requirements. | 2 | +| **4.4.4** | Verify that dedicated WebSocket session management tokens are initially obtained or validated through the previously authenticated HTTPS session when transitioning an existing HTTPS session to a WebSocket channel. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **4.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੇ WebSocket ਕਨੈਕਸ਼ਨਾਂ ਲਈ WebSocket over TLS (WSS) ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। | 1 | +| **4.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਸ਼ੁਰੂਆਤੀ HTTP WebSocket ਹੈਂਡਸ਼ੇਕ ਦੌਰਾਨ, Origin ਹੈੱਡਰ ਖੇਤਰ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਇਜਾਜ਼ਤ ਪ੍ਰਾਪਤ ਓਰਿਜਿਨਾਂ (origins) ਦੀ ਸੂਚੀ ਦੇ ਵਿਰੁੱਧ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। | 2 | +| **4.4.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਮਿਆਰੀ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਨਹੀਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ, ਤਾਂ ਇਸ ਲਈ ਸਮਰਪਿਤ ਟੋਕਨ ਵਰਤੇ ਜਾ ਰਹੇ ਹਨ, ਜੋ ਸੰਬੰਧਿਤ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ। | 2 | +| **4.4.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਿਸੇ ਮੌਜੂਦਾ HTTPS ਸੈਸ਼ਨ ਨੂੰ WebSocket ਚੈਨਲ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦੇ ਸਮੇਂ, ਸਮਰਪਿਤ WebSocket ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਟੋਕਨ ਸ਼ੁਰੂ ਵਿੱਚ ਪਹਿਲਾਂ ਪ੍ਰਮਾਣੀਕਰਨ ਕੀਤੇ ਗਏ HTTPS ਸੈਸ਼ਨ ਰਾਹੀਂ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਂ ਪ੍ਰਮਾਣਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। | 2 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [OWASP REST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html) +* Resources on GraphQL Authorization from [graphql.org](https://graphql.org/learn/authorization/) and [Apollo](https://www.apollographql.com/docs/apollo-server/security/authentication/#authorization-methods). +* [OWASP Web Security Testing Guide: GraphQL Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL) +* [OWASP Web Security Testing Guide: Testing WebSockets](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/11-Client-side_Testing/10-Testing_WebSockets) diff --git a/5.0/pa-IN/0x14-V5-File-Handling.md b/5.0/pa-IN/0x14-V5-File-Handling.md new file mode 100644 index 0000000000..2e1852804a --- /dev/null +++ b/5.0/pa-IN/0x14-V5-File-Handling.md @@ -0,0 +1,102 @@ + + + + +# V5 File Handling +# V5 ਫ਼ਾਈਲ ਪ੍ਰਬੰਧਨ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +The use of files can present a variety of risks to the application, including denial of service, unauthorized access, and storage exhaustion. This chapter includes requirements to address these risks. + +ਫ਼ਾਈਲਾਂ ਦੀ ਵਰਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਖ਼ਤਰੇ ਪੇਸ਼ ਕਰ ਸਕਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਸੇਵਾ-ਇਨਕਾਰ (denial of service), ਅਣਅਧਿਕਾਰਤ ਪਹੁੰਚ, ਅਤੇ ਭੰਡਾਰਨ ਖ਼ਤਮ ਹੋ ਜਾਣਾ ਸ਼ਾਮਲ ਹਨ। ਇਸ ਅਧਿਆਇ ਵਿੱਚ ਇਹਨਾਂ ਖ਼ਤਰਿਆਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ। + +## V5.1 File Handling Documentation +## V5.1 ਫ਼ਾਈਲ ਪ੍ਰਬੰਧਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ + +This section includes a requirement to document the expected characteristics of files accepted by the application, as a necessary precondition for developing and verifying relevant security checks. + +ਇਸ ਭਾਗ ਵਿੱਚ ਇੱਕ ਲੋੜ ਸ਼ਾਮਲ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਸਵੀਕਾਰ ਕੀਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਫ਼ਾਈਲਾਂ ਦੀਆਂ ਅਨੁਮਾਨਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕੀਤਾ ਜਾਵੇ, ਜੋ ਸੰਬੰਧਿਤ ਸੁਰੱਖਿਆ ਜਾਂਚਾਂ ਨੂੰ ਵਿਕਸਤ ਅਤੇ ਤਸਦੀਕ ਕਰਨ ਲਈ ਇੱਕ ਜ਼ਰੂਰੀ ਪੂਰਵ-ਸ਼ਰਤ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **5.1.1** | Verify that the documentation defines the permitted file types, expected file extensions, and maximum size (including unpacked size) for each upload feature. Additionally, ensure that the documentation specifies how files are made safe for end-users to download and process, such as how the application behaves when a malicious file is detected. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **5.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਹਰ ਅਪਲੋਡ ਫ਼ੀਚਰ ਲਈ ਆਗਿਆ ਪ੍ਰਾਪਤ ਫ਼ਾਈਲ ਕਿਸਮਾਂ, ਅਨੁਮਾਨਿਤ ਫ਼ਾਈਲ ਐਕਸਟੈਂਸ਼ਨਾਂ, ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਆਕਾਰ (ਅਨਪੈਕ ਕੀਤੇ ਆਕਾਰ ਸਮੇਤ) ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਅੰਤਮ-ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ ਫ਼ਾਈਲਾਂ ਨੂੰ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਜਦੋਂ ਕੋਈ ਖ਼ਤਰਨਾਕ ਫ਼ਾਈਲ ਪਛਾਣੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ। | 2 | + +## V5.2 File Upload and Content +## V5.2 ਫ਼ਾਈਲ ਅਪਲੋਡ ਅਤੇ ਸਮੱਗਰੀ + +File upload functionality is a primary source of untrusted files. This section outlines the requirements for ensuring that the presence, volume, or content of these files cannot harm the application. + +ਫ਼ਾਈਲ ਅਪਲੋਡ ਕਾਰਜਸ਼ੀਲਤਾ ਅਣਭਰੋਸੇਯੋਗ ਫ਼ਾਈਲਾਂ ਦਾ ਮੁੱਖ ਸਰੋਤ ਹੈ। ਇਹ ਭਾਗ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਲੋੜਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦਿੰਦਾ ਹੈ ਕਿ ਇਹਨਾਂ ਫ਼ਾਈਲਾਂ ਦੀ ਮੌਜੂਦਗੀ, ਮਾਤਰਾ, ਜਾਂ ਸਮੱਗਰੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਨੁਕਸਾਨ ਨਾ ਪਹੁੰਚਾ ਸਕੇ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **5.2.1** | Verify that the application will only accept files of a size which it can process without causing a loss of performance or a denial of service attack. | 1 | +| **5.2.2** | Verify that when the application accepts a file, either on its own or within an archive such as a zip file, it checks if the file extension matches an expected file extension and validates that the contents correspond to the type represented by the extension. This includes, but is not limited to, checking the initial 'magic bytes', performing image re-writing, and using specialized libraries for file content validation. For L1, this can focus just on files which are used to make specific business or security decisions. For L2 and up, this must apply to all files being accepted. | 1 | +| **5.2.3** | Verify that the application checks compressed files (e.g., zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file. | 2 | +| **5.2.4** | Verify that a file size quota and maximum number of files per user are enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files. | 3 | +| **5.2.5** | Verify that the application does not allow uploading compressed files containing symlinks unless this is specifically required (in which case it will be necessary to enforce an allowlist of the files that can be symlinked to). | 3 | +| **5.2.6** | Verify that the application rejects uploaded images with a pixel size larger than the maximum allowed, to prevent pixel flood attacks. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **5.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸਿਰਫ਼ ਉਸ ਆਕਾਰ ਦੀਆਂ ਫ਼ਾਈਲਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰੇਗੀ ਜਿਸਨੂੰ ਉਹ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਨੁਕਸਾਨ ਜਾਂ ਸੇਵਾ-ਇਨਕਾਰ (denial of service) ਹਮਲੇ ਦਾ ਕਾਰਨ ਬਣੇ ਬਿਨਾਂ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦੀ ਹੈ। | 1 | +| **5.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਫ਼ਾਈਲ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ, ਭਾਵੇਂ ਆਪਣੇ ਆਪ ਜਾਂ ਕਿਸੇ ਆਰਕਾਈਵ ਜਿਵੇਂ ਕਿ ਜ਼ਿਪ ਫ਼ਾਈਲ ਦੇ ਅੰਦਰ, ਇਹ ਜਾਂਚ ਕਰਦੀ ਹੈ ਕਿ ਫ਼ਾਈਲ ਐਕਸਟੈਂਸ਼ਨ ਇੱਕ ਅਨੁਮਾਨਿਤ ਫ਼ਾਈਲ ਐਕਸਟੈਂਸ਼ਨ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਦੀ ਹੈ ਕਿ ਸਮੱਗਰੀ ਐਕਸਟੈਂਸ਼ਨ ਦੁਆਰਾ ਦਰਸਾਈ ਕਿਸਮ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਸ਼ੁਰੂਆਤੀ 'ਮੈਜਿਕ ਬਾਈਟਸ' ਦੀ ਜਾਂਚ ਕਰਨਾ, ਚਿੱਤਰ ਮੁੜ-ਲਿਖਾਈ ਕਰਨਾ, ਅਤੇ ਫ਼ਾਈਲ ਸਮੱਗਰੀ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਵਿਸ਼ੇਸ਼ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ, ਪਰ ਇਹਨਾਂ ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ। L1 ਲਈ, ਇਹ ਸਿਰਫ਼ ਉਹਨਾਂ ਫ਼ਾਈਲਾਂ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਖ਼ਾਸ ਕਾਰੋਬਾਰੀ ਜਾਂ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲੇ ਲੈਣ ਲਈ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। L2 ਅਤੇ ਉੱਪਰ ਲਈ, ਇਹ ਸਾਰੀਆਂ ਸਵੀਕਾਰ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਫ਼ਾਈਲਾਂ 'ਤੇ ਲਾਗੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। | 1 | +| **5.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸੰਕੁਚਿਤ ਫ਼ਾਈਲਾਂ (ਜਿਵੇਂ, zip, gz, docx, odt) ਦੀ ਫ਼ਾਈਲ ਨੂੰ ਡੀ-ਸੰਕੁਚਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਆਗਿਆ ਪ੍ਰਾਪਤ ਡੀ-ਸੰਕੁਚਿਤ ਆਕਾਰ ਅਤੇ ਫ਼ਾਈਲਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਗਿਣਤੀ ਦੇ ਵਿਰੁੱਧ ਜਾਂਚ ਕਰਦੀ ਹੈ। | 2 | +| **5.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪ੍ਰਤੀ ਉਪਭੋਗਤਾ ਇੱਕ ਫ਼ਾਈਲ ਆਕਾਰ ਕੋਟਾ ਅਤੇ ਫ਼ਾਈਲਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਗਿਣਤੀ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਜੋ ਇੱਕ ਇਕੱਲਾ ਉਪਭੋਗਤਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਫ਼ਾਈਲਾਂ, ਜਾਂ ਬਹੁਤ ਵੱਡੀਆਂ ਫ਼ਾਈਲਾਂ ਨਾਲ ਭੰਡਾਰਨ ਨੂੰ ਨਾ ਭਰ ਸਕੇ। | 3 | +| **5.2.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸਿਮਲਿੰਕ (symlinks) ਵਾਲੀਆਂ ਸੰਕੁਚਿਤ ਫ਼ਾਈਲਾਂ ਨੂੰ ਅਪਲੋਡ ਕਰਨ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੀ ਜਦੋਂ ਤੱਕ ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਜ਼ਰੂਰੀ ਨਾ ਹੋਵੇ (ਉਸ ਸੂਰਤ ਵਿੱਚ ਉਹਨਾਂ ਫ਼ਾਈਲਾਂ ਦੀ ਇੱਕ allowlist ਲਾਗੂ ਕਰਨੀ ਜ਼ਰੂਰੀ ਹੋਵੇਗੀ ਜਿਨ੍ਹਾਂ ਨਾਲ ਸਿਮਲਿੰਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ)। | 3 | +| **5.2.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਪਿਕਸਲ ਫ਼ਲੱਡ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਆਗਿਆ ਪ੍ਰਾਪਤ ਵੱਧ ਤੋਂ ਵੱਧ ਨਾਲੋਂ ਵੱਡੇ ਪਿਕਸਲ ਆਕਾਰ ਵਾਲੇ ਅਪਲੋਡ ਕੀਤੇ ਚਿੱਤਰਾਂ ਨੂੰ ਰੱਦ ਕਰਦੀ ਹੈ। | 3 | + +## V5.3 File Storage +## V5.3 ਫ਼ਾਈਲ ਭੰਡਾਰਨ + +This section includes requirements to prevent files from being inappropriately executed after upload, to detect dangerous content, and to avoid untrusted data being used to control where files are being stored. + +ਇਸ ਭਾਗ ਵਿੱਚ ਫ਼ਾਈਲਾਂ ਨੂੰ ਅਪਲੋਡ ਤੋਂ ਬਾਅਦ ਅਣਉਚਿਤ ਢੰਗ ਨਾਲ ਚਲਾਏ ਜਾਣ ਤੋਂ ਰੋਕਣ, ਖ਼ਤਰਨਾਕ ਸਮੱਗਰੀ ਦਾ ਪਤਾ ਲਗਾਉਣ, ਅਤੇ ਇਹ ਨਿਯੰਤਰਣ ਕਰਨ ਲਈ ਅਣਭਰੋਸੇਯੋਗ ਡਾਟਾ ਦੀ ਵਰਤੋਂ ਤੋਂ ਬਚਣ ਲਈ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ ਕਿ ਫ਼ਾਈਲਾਂ ਕਿੱਥੇ ਸੰਭਾਲੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **5.3.1** | Verify that files uploaded or generated by untrusted input and stored in a public folder, are not executed as server-side program code when accessed directly with an HTTP request. | 1 | +| **5.3.2** | Verify that when the application creates file paths for file operations, instead of user-submitted filenames, it uses internally generated or trusted data, or if user-submitted filenames or file metadata must be used, strict validation and sanitization must be applied. This is to protect against path traversal, local or remote file inclusion (LFI, RFI), and server-side request forgery (SSRF) attacks. | 1 | +| **5.3.3** | Verify that server-side file processing, such as file decompression, ignores user-provided path information to prevent vulnerabilities such as zip slip. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **5.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਅਣਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ ਦੁਆਰਾ ਅਪਲੋਡ ਕੀਤੀਆਂ ਜਾਂ ਪੈਦਾ ਕੀਤੀਆਂ ਅਤੇ ਜਨਤਕ ਫੋਲਡਰ ਵਿੱਚ ਸੰਭਾਲੀਆਂ ਫ਼ਾਈਲਾਂ, HTTP ਬੇਨਤੀ ਨਾਲ ਸਿੱਧੇ ਪਹੁੰਚਣ 'ਤੇ ਸਰਵਰ-ਪਾਸੇ ਪ੍ਰੋਗਰਾਮ ਕੋਡ ਵਜੋਂ ਨਹੀਂ ਚਲਾਈਆਂ ਜਾਂਦੀਆਂ। | 1 | +| **5.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਫ਼ਾਈਲ ਕਾਰਵਾਈਆਂ ਲਈ ਫ਼ਾਈਲ ਪਾਥ ਬਣਾਉਂਦੀ ਹੈ, ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਸੌਂਪੇ ਫ਼ਾਈਲ ਨਾਮਾਂ ਦੀ ਬਜਾਏ, ਇਹ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਪੈਦਾ ਕੀਤੇ ਜਾਂ ਭਰੋਸੇਯੋਗ ਡਾਟਾ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ, ਜਾਂ ਜੇ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਸੌਂਪੇ ਫ਼ਾਈਲ ਨਾਮ ਜਾਂ ਫ਼ਾਈਲ ਮੈਟਾਡਾਟਾ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਜ਼ਰੂਰੀ ਹੈ, ਤਾਂ ਸਖ਼ਤ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ ਲਾਗੂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਪਾਥ ਟਰੈਵਰਸਲ, ਲੋਕਲ ਜਾਂ ਰਿਮੋਟ ਫ਼ਾਈਲ ਇਨਕਲੂਜ਼ਨ (LFI, RFI), ਅਤੇ ਸਰਵਰ-ਸਾਈਡ ਰਿਕੁਐਸਟ ਫੋਰਜਰੀ (SSRF) ਹਮਲਿਆਂ ਤੋਂ ਬਚਾਅ ਲਈ ਹੈ। | 1 | +| **5.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਰਵਰ-ਪਾਸੇ ਫ਼ਾਈਲ ਪ੍ਰਕਿਰਿਆ, ਜਿਵੇਂ ਕਿ ਫ਼ਾਈਲ ਡੀ-ਸੰਕੁਚਨ, ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਪਾਥ ਜਾਣਕਾਰੀ ਨੂੰ ਅਣਡਿੱਠ ਕਰਦੀ ਹੈ ਤਾਂ ਜੋ zip slip ਵਰਗੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। | 3 | + +## V5.4 File Download +## V5.4 ਫ਼ਾਈਲ ਡਾਊਨਲੋਡ + +This section contains requirements to mitigate risks when serving files to be downloaded, including path traversal and injection attacks. This also includes making sure they don't contain dangerous content. + +ਇਸ ਭਾਗ ਵਿੱਚ ਡਾਊਨਲੋਡ ਕੀਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਫ਼ਾਈਲਾਂ ਦੀ ਸੇਵਾ ਕਰਦੇ ਸਮੇਂ ਖ਼ਤਰਿਆਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ, ਜਿਸ ਵਿੱਚ ਪਾਥ ਟਰੈਵਰਸਲ ਅਤੇ ਇੰਜੈਕਸ਼ਨ ਹਮਲੇ ਸ਼ਾਮਲ ਹਨ। ਇਸ ਵਿੱਚ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਵੀ ਸ਼ਾਮਲ ਹੈ ਕਿ ਉਹਨਾਂ ਵਿੱਚ ਖ਼ਤਰਨਾਕ ਸਮੱਗਰੀ ਨਾ ਹੋਵੇ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **5.4.1** | Verify that the application validates or ignores user-submitted filenames, including in a JSON, JSONP, or URL parameter and specifies a filename in the Content-Disposition header field in the response. | 2 | +| **5.4.2** | Verify that file names served (e.g., in HTTP response header fields or email attachments) are encoded or sanitized (e.g., following RFC 6266) to preserve document structure and prevent injection attacks. | 2 | +| **5.4.3** | Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent serving of known malicious content. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **5.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਸੌਂਪੇ ਫ਼ਾਈਲ ਨਾਮਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦੀ ਹੈ ਜਾਂ ਅਣਡਿੱਠ ਕਰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ JSON, JSONP, ਜਾਂ URL ਪੈਰਾਮੀਟਰ ਸ਼ਾਮਲ ਹਨ, ਅਤੇ ਜਵਾਬ ਵਿੱਚ Content-Disposition ਹੈਡਰ ਖੇਤਰ ਵਿੱਚ ਇੱਕ ਫ਼ਾਈਲ ਨਾਮ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ। | 2 | +| **5.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੇਵਾ ਕੀਤੇ ਫ਼ਾਈਲ ਨਾਮ (ਜਿਵੇਂ, HTTP ਜਵਾਬ ਹੈਡਰ ਖੇਤਰਾਂ ਜਾਂ ਈਮੇਲ ਅਟੈਚਮੈਂਟਾਂ ਵਿੱਚ) ਦਸਤਾਵੇਜ਼ ਢਾਂਚੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਅਤੇ ਇੰਜੈਕਸ਼ਨ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਏਨਕੋਡ ਜਾਂ ਸੈਨੀਟਾਈਜ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ (ਜਿਵੇਂ, RFC 6266 ਦੇ ਅਨੁਸਾਰ)। | 2 | +| **5.4.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਅਣਭਰੋਸੇਯੋਗ ਸਰੋਤਾਂ ਤੋਂ ਪ੍ਰਾਪਤ ਫ਼ਾਈਲਾਂ ਨੂੰ ਜਾਣੀ-ਪਛਾਣੀ ਖ਼ਤਰਨਾਕ ਸਮੱਗਰੀ ਦੀ ਸੇਵਾ ਨੂੰ ਰੋਕਣ ਲਈ ਐਂਟੀਵਾਇਰਸ ਸਕੈਨਰਾਂ ਦੁਆਰਾ ਸਕੈਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। | 2 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [OWASP File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) +* [Example of using symlinks for arbitrary file read](https://hackerone.com/reports/1439593) +* [Explanation of "Magic Bytes" from Wikipedia](https://en.wikipedia.org/wiki/List_of_file_signatures) diff --git a/5.0/pa-IN/0x15-V6-Authentication.md b/5.0/pa-IN/0x15-V6-Authentication.md new file mode 100644 index 0000000000..6610179f93 --- /dev/null +++ b/5.0/pa-IN/0x15-V6-Authentication.md @@ -0,0 +1,316 @@ + + + + +# V6 Authentication +# V6 ਪ੍ਰਮਾਣੀਕਰਨ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +Authentication is the process of establishing or confirming the authenticity of an individual or device. It involves verifying claims made by a person or about a device, ensuring resistance to impersonation, and preventing the recovery or interception of passwords. + +ਪ੍ਰਮਾਣੀਕਰਨ (Authentication) ਕਿਸੇ ਵਿਅਕਤੀ ਜਾਂ ਡਿਵਾਈਸ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਜਾਂ ਉਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਇਸ ਵਿੱਚ ਕਿਸੇ ਵਿਅਕਤੀ ਦੁਆਰਾ ਕੀਤੇ ਗਏ ਜਾਂ ਕਿਸੇ ਡਿਵਾਈਸ ਬਾਰੇ ਕੀਤੇ ਗਏ ਦਾਅਵਿਆਂ ਦੀ ਤਸਦੀਕ ਕਰਨਾ, ਪਛਾਣ-ਨਕਲ (impersonation) ਪ੍ਰਤੀ ਰੋਧਕਤਾ ਯਕੀਨੀ ਬਣਾਉਣਾ, ਅਤੇ ਪਾਸਵਰਡਾਂ ਦੀ ਰਿਕਵਰੀ ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਰਾਹ ਵਿੱਚ ਫੜੇ ਜਾਣ (interception) ਨੂੰ ਰੋਕਣਾ ਸ਼ਾਮਲ ਹੈ। + +[NIST SP 800-63](https://pages.nist.gov/800-63-3/) is a modern, evidence-based standard that is valuable for organizations worldwide, but is particularly relevant to US agencies and those interacting with US agencies. + +[NIST SP 800-63](https://pages.nist.gov/800-63-3/) ਇੱਕ ਆਧੁਨਿਕ, ਸਬੂਤ-ਆਧਾਰਿਤ ਮਿਆਰ ਹੈ ਜੋ ਦੁਨੀਆ ਭਰ ਦੀਆਂ ਸੰਸਥਾਵਾਂ ਲਈ ਕੀਮਤੀ ਹੈ, ਪਰ ਅਮਰੀਕੀ ਏਜੰਸੀਆਂ ਅਤੇ ਅਮਰੀਕੀ ਏਜੰਸੀਆਂ ਨਾਲ ਆਪਸੀ ਤਾਲਮੇਲ ਕਰਨ ਵਾਲਿਆਂ ਲਈ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਢੁਕਵਾਂ ਹੈ। + +While many of the requirements in this chapter are based on the second section of the standard (known as NIST SP 800-63B "Digital Identity Guidelines - Authentication and Lifecycle Management"), the chapter focuses on common threats and frequently exploited authentication weaknesses. It does not attempt to comprehensively cover every point in the standard. For cases where full NIST SP 800-63 compliance is necessary, please refer to NIST SP 800-63. + +ਭਾਵੇਂ ਇਸ ਅਧਿਆਇ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਲੋੜਾਂ ਮਿਆਰ ਦੇ ਦੂਜੇ ਭਾਗ (ਜਿਸ ਨੂੰ NIST SP 800-63B "Digital Identity Guidelines - Authentication and Lifecycle Management" ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ) 'ਤੇ ਆਧਾਰਿਤ ਹਨ, ਇਹ ਅਧਿਆਇ ਆਮ ਖ਼ਤਰਿਆਂ ਅਤੇ ਅਕਸਰ ਸ਼ੋਸ਼ਣ ਕੀਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਪ੍ਰਮਾਣੀਕਰਨ ਕਮਜ਼ੋਰੀਆਂ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ। ਇਹ ਮਿਆਰ ਦੇ ਹਰ ਨੁਕਤੇ ਨੂੰ ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਕਵਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ। ਜਿਨ੍ਹਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ NIST SP 800-63 ਦੀ ਪੂਰੀ ਪਾਲਣਾ ਜ਼ਰੂਰੀ ਹੈ, ਕਿਰਪਾ ਕਰਕੇ NIST SP 800-63 ਵੇਖੋ। + +Additionally, NIST SP 800-63 terminology may sometimes differ, and this chapter often uses more commonly understood terminology to improve clarity. + +ਇਸ ਤੋਂ ਇਲਾਵਾ, NIST SP 800-63 ਦੀ ਸ਼ਬਦਾਵਲੀ ਕਈ ਵਾਰ ਵੱਖਰੀ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਸਪੱਸ਼ਟਤਾ ਵਧਾਉਣ ਲਈ ਇਹ ਅਧਿਆਇ ਅਕਸਰ ਵਧੇਰੇ ਆਮ ਤੌਰ 'ਤੇ ਸਮਝੀ ਜਾਣ ਵਾਲੀ ਸ਼ਬਦਾਵਲੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। + +A common feature of more advanced applications is the ability to adapt authentication stages required based on various risk factors. This feature is covered in the "Authorization" chapter, since these mechanisms also need to be considered for authorization decisions. + +ਵਧੇਰੇ ਉੱਨਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਇੱਕ ਆਮ ਵਿਸ਼ੇਸ਼ਤਾ ਵੱਖ-ਵੱਖ ਜੋਖਮ ਕਾਰਕਾਂ (risk factors) ਦੇ ਆਧਾਰ 'ਤੇ ਲੋੜੀਂਦੇ ਪ੍ਰਮਾਣੀਕਰਨ ਪੜਾਵਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਦੀ ਯੋਗਤਾ ਹੈ। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ "ਅਧਿਕਾਰੀਕਰਨ" (Authorization) ਅਧਿਆਇ ਵਿੱਚ ਕਵਰ ਕੀਤੀ ਗਈ ਹੈ, ਕਿਉਂਕਿ ਇਹਨਾਂ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਅਧਿਕਾਰੀਕਰਨ ਫ਼ੈਸਲਿਆਂ ਲਈ ਵੀ ਵਿਚਾਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। + +## V6.1 Authentication Documentation +## V6.1 ਪ੍ਰਮਾਣੀਕਰਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ + +This section contains requirements detailing the authentication documentation that should be maintained for an application. This is crucial for implementing and assessing how the relevant authentication controls should be configured. + +ਇਸ ਭਾਗ ਵਿੱਚ ਉਹ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ ਜੋ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਬਣਾਈ ਰੱਖੇ ਜਾਣ ਵਾਲੇ ਪ੍ਰਮਾਣੀਕਰਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਦਾ ਵੇਰਵਾ ਦਿੰਦੀਆਂ ਹਨ। ਇਹ ਲਾਗੂ ਕਰਨ ਅਤੇ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਸੰਬੰਧਿਤ ਪ੍ਰਮਾਣੀਕਰਨ ਨਿਯੰਤਰਣਾਂ ਨੂੰ ਕਿਵੇਂ ਕੌਨਫ਼ਿਗਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.1.1** | Verify that application documentation defines how controls such as rate limiting, anti-automation, and adaptive response, are used to defend against attacks such as credential stuffing and password brute force. The documentation must make clear how these controls are configured and prevent malicious account lockout. | 1 | +| **6.1.2** | Verify that a list of context-specific words is documented in order to prevent their use in passwords. The list could include permutations of organization names, product names, system identifiers, project codenames, department or role names, and similar. | 2 | +| **6.1.3** | Verify that, if the application includes multiple authentication pathways, these are all documented together with the security controls and authentication strength which must be consistently enforced across them. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **6.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਦਰ ਸੀਮਾ (rate limiting), ਸਵੈਚਾਲਨ-ਵਿਰੋਧੀ (anti-automation), ਅਤੇ ਅਨੁਕੂਲਿਤ ਪ੍ਰਤੀਕਿਰਿਆ (adaptive response) ਵਰਗੇ ਨਿਯੰਤਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕ੍ਰੀਡੈਂਸ਼ੀਅਲ ਸਟਫ਼ਿੰਗ (credential stuffing) ਅਤੇ ਪਾਸਵਰਡ ਬਰੂਟ ਫੋਰਸ ਵਰਗੇ ਹਮਲਿਆਂ ਤੋਂ ਬਚਾਅ ਲਈ ਕਿਵੇਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਨਿਯੰਤਰਣ ਕਿਵੇਂ ਕੌਨਫ਼ਿਗਰ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਦੁਰਭਾਵਨਾਪੂਰਨ ਖਾਤਾ ਤਾਲਾਬੰਦੀ (account lockout) ਨੂੰ ਕਿਵੇਂ ਰੋਕਦੇ ਹਨ। | 1 | +| **6.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੰਦਰਭ-ਖ਼ਾਸ ਸ਼ਬਦਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਵਿੱਚ ਦਰਜ ਹੈ ਤਾਂ ਜੋ ਪਾਸਵਰਡਾਂ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। ਇਸ ਸੂਚੀ ਵਿੱਚ ਸੰਸਥਾ ਦੇ ਨਾਂ, ਉਤਪਾਦ ਦੇ ਨਾਂ, ਸਿਸਟਮ ਪਛਾਣਕਰਤਾ, ਪ੍ਰੋਜੈਕਟ ਕੋਡਨਾਂ, ਵਿਭਾਗ ਜਾਂ ਭੂਮਿਕਾ ਦੇ ਨਾਂ, ਅਤੇ ਇਸੇ ਤਰ੍ਹਾਂ ਦੇ ਹੋਰ ਸ਼ਬਦਾਂ ਦੇ ਕ੍ਰਮ-ਪਰਿਵਰਤਨ (permutations) ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ। | 2 | +| **6.1.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਕਈ ਪ੍ਰਮਾਣੀਕਰਨ ਮਾਰਗ ਸ਼ਾਮਲ ਹਨ, ਤਾਂ ਇਹ ਸਾਰੇ ਉਹਨਾਂ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣਾਂ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਤਾਕਤ ਦੇ ਨਾਲ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਵਿੱਚ ਦਰਜ ਹਨ ਜੋ ਇਹਨਾਂ ਸਾਰਿਆਂ ਵਿੱਚ ਇਕਸਾਰ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। | 2 | + +## V6.2 Password Security +## V6.2 ਪਾਸਵਰਡ ਸੁਰੱਖਿਆ + +Passwords, called "Memorized Secrets" by NIST SP 800-63, include passwords, passphrases, PINs, unlock patterns, and picking the correct kitten or another image element. They are generally considered "something you know" and are often used as a single-factor authentication mechanism. + +ਪਾਸਵਰਡ, ਜਿਨ੍ਹਾਂ ਨੂੰ NIST SP 800-63 ਦੁਆਰਾ "Memorized Secrets" (ਯਾਦ ਰੱਖੇ ਭੇਦ) ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਵਿੱਚ ਪਾਸਵਰਡ, ਪਾਸਫ਼੍ਰੇਜ਼, PIN, ਅਨਲੌਕ ਪੈਟਰਨ, ਅਤੇ ਸਹੀ ਬਿੱਲੀ ਦੇ ਬੱਚੇ ਜਾਂ ਕਿਸੇ ਹੋਰ ਚਿੱਤਰ ਤੱਤ ਨੂੰ ਚੁਣਨਾ ਸ਼ਾਮਲ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ "ਕੁਝ ਜੋ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਹ ਅਕਸਰ ਇੱਕ ਇੱਕ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ (single-factor authentication) ਪ੍ਰਣਾਲੀ ਵਜੋਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। + +As such, this section contains requirements for making sure that passwords are created and handled securely. Most of the requirements are L1 as they are most important at that level. From L2 onwards, multi-factor authentication mechanisms are required, where passwords may be one of those factors. + +ਇਸ ਲਈ, ਇਸ ਭਾਗ ਵਿੱਚ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ ਕਿ ਪਾਸਵਰਡ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਬਣਾਏ ਅਤੇ ਸੰਭਾਲੇ ਜਾਣ। ਜ਼ਿਆਦਾਤਰ ਲੋੜਾਂ L1 ਹਨ ਕਿਉਂਕਿ ਉਹ ਉਸ ਪੱਧਰ 'ਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹਨ। L2 ਤੋਂ ਅੱਗੇ, ਬਹੁ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ (multi-factor authentication) ਪ੍ਰਣਾਲੀਆਂ ਲੋੜੀਂਦੀਆਂ ਹਨ, ਜਿੱਥੇ ਪਾਸਵਰਡ ਉਹਨਾਂ ਕਾਰਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੋ ਸਕਦੇ ਹਨ। + +The requirements in this section mostly relate to [§ 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). + +ਇਸ ਭਾਗ ਦੀਆਂ ਲੋੜਾਂ ਜ਼ਿਆਦਾਤਰ [NIST ਦੇ ਮਾਰਗਦਰਸ਼ਨ](https://pages.nist.gov/800-63-3/sp800-63b.html) ਦੇ [§ 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.2.1** | Verify that user set passwords are at least 8 characters in length although a minimum of 15 characters is strongly recommended. | 1 | +| **6.2.2** | Verify that users can change their password. | 1 | +| **6.2.3** | Verify that password change functionality requires the user's current and new password. | 1 | +| **6.2.4** | Verify that passwords submitted during account registration or password change are checked against an available set of, at least, the top 3000 passwords which match the application's password policy, e.g. minimum length. | 1 | +| **6.2.5** | Verify that passwords of any composition can be used, without rules limiting the type of characters permitted. There must be no requirement for a minimum number of upper or lower case characters, numbers, or special characters. | 1 | +| **6.2.6** | Verify that password input fields use type=password to mask the entry. Applications may allow the user to temporarily view the entire masked password, or the last typed character of the password. | 1 | +| **6.2.7** | Verify that "paste" functionality, browser password helpers, and external password managers are permitted. | 1 | +| **6.2.8** | Verify that the application verifies the user's password exactly as received from the user, without any modifications such as truncation or case transformation. | 1 | +| **6.2.9** | Verify that passwords of at least 64 characters are permitted. | 2 | +| **6.2.10** | Verify that a user's password stays valid until it is discovered to be compromised or the user rotates it. The application must not require periodic credential rotation. | 2 | +| **6.2.11** | Verify that the documented list of context specific words is used to prevent easy to guess passwords being created. | 2 | +| **6.2.12** | Verify that passwords submitted during account registration or password changes are checked against a set of breached passwords. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **6.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਸੈੱਟ ਕੀਤੇ ਪਾਸਵਰਡ ਘੱਟੋ-ਘੱਟ 8 ਅੱਖਰ ਲੰਬੇ ਹਨ, ਹਾਲਾਂਕਿ ਘੱਟੋ-ਘੱਟ 15 ਅੱਖਰਾਂ ਦੀ ਜ਼ੋਰਦਾਰ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। | 1 | +| **6.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ ਆਪਣਾ ਪਾਸਵਰਡ ਬਦਲ ਸਕਦੇ ਹਨ। | 1 | +| **6.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪਾਸਵਰਡ ਬਦਲਣ ਦੀ ਕਾਰਜਸ਼ੀਲਤਾ ਲਈ ਉਪਭੋਗਤਾ ਦਾ ਮੌਜੂਦਾ ਅਤੇ ਨਵਾਂ ਪਾਸਵਰਡ ਲੋੜੀਂਦਾ ਹੈ। | 1 | +| **6.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਖਾਤਾ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਜਾਂ ਪਾਸਵਰਡ ਬਦਲਣ ਦੌਰਾਨ ਜਮ੍ਹਾਂ ਕੀਤੇ ਪਾਸਵਰਡਾਂ ਦੀ ਜਾਂਚ ਘੱਟੋ-ਘੱਟ ਉਹਨਾਂ ਸਿਖਰਲੇ 3000 ਪਾਸਵਰਡਾਂ ਦੇ ਉਪਲਬਧ ਸਮੂਹ ਦੇ ਵਿਰੁੱਧ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਪਾਸਵਰਡ ਨੀਤੀ, ਜਿਵੇਂ ਕਿ ਘੱਟੋ-ਘੱਟ ਲੰਬਾਈ, ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ। | 1 | +| **6.2.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਿਸੇ ਵੀ ਬਣਤਰ ਦੇ ਪਾਸਵਰਡ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਬਿਨਾਂ ਅਜਿਹੇ ਨਿਯਮਾਂ ਦੇ ਜੋ ਇਜਾਜ਼ਤ ਪ੍ਰਾਪਤ ਅੱਖਰਾਂ ਦੀ ਕਿਸਮ ਨੂੰ ਸੀਮਤ ਕਰਦੇ ਹੋਣ। ਵੱਡੇ ਜਾਂ ਛੋਟੇ ਅੱਖਰਾਂ, ਅੰਕਾਂ, ਜਾਂ ਵਿਸ਼ੇਸ਼ ਅੱਖਰਾਂ ਦੀ ਘੱਟੋ-ਘੱਟ ਗਿਣਤੀ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। | 1 | +| **6.2.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪਾਸਵਰਡ ਇਨਪੁੱਟ ਖੇਤਰ ਦਾਖ਼ਲੇ ਨੂੰ ਲੁਕਾਉਣ (mask) ਲਈ type=password ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਐਪਲੀਕੇਸ਼ਨਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਪੂਰੇ ਲੁਕਾਏ ਹੋਏ ਪਾਸਵਰਡ, ਜਾਂ ਪਾਸਵਰਡ ਦੇ ਆਖ਼ਰੀ ਟਾਈਪ ਕੀਤੇ ਅੱਖਰ, ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਵੇਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਸਕਦੀਆਂ ਹਨ। | 1 | +| **6.2.7** | ਤਸਦੀਕ ਕਰੋ ਕਿ "ਪੇਸਟ" ਕਾਰਜਸ਼ੀਲਤਾ, ਬ੍ਰਾਊਜ਼ਰ ਪਾਸਵਰਡ ਸਹਾਇਕਾਂ, ਅਤੇ ਬਾਹਰੀ ਪਾਸਵਰਡ ਪ੍ਰਬੰਧਕਾਂ ਦੀ ਇਜਾਜ਼ਤ ਹੈ। | 1 | +| **6.2.8** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਉਪਭੋਗਤਾ ਦੇ ਪਾਸਵਰਡ ਦੀ ਤਸਦੀਕ ਬਿਲਕੁਲ ਉਸੇ ਰੂਪ ਵਿੱਚ ਕਰਦੀ ਹੈ ਜਿਵੇਂ ਉਹ ਉਪਭੋਗਤਾ ਤੋਂ ਪ੍ਰਾਪਤ ਹੋਇਆ ਹੈ, ਬਿਨਾਂ ਕਿਸੇ ਸੋਧ ਦੇ ਜਿਵੇਂ ਕਿ ਕੱਟ-ਛਾਂਟ (truncation) ਜਾਂ ਵੱਡੇ-ਛੋਟੇ ਅੱਖਰਾਂ ਦਾ ਰੂਪਾਂਤਰਨ। | 1 | +| **6.2.9** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਘੱਟੋ-ਘੱਟ 64 ਅੱਖਰਾਂ ਦੇ ਪਾਸਵਰਡਾਂ ਦੀ ਇਜਾਜ਼ਤ ਹੈ। | 2 | +| **6.2.10** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ ਦਾ ਪਾਸਵਰਡ ਉਦੋਂ ਤੱਕ ਜਾਇਜ਼ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਇਹ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਇਸ ਦਾ ਸਮਝੌਤਾ ਹੋ ਗਿਆ ਹੈ (compromised) ਜਾਂ ਉਪਭੋਗਤਾ ਇਸ ਨੂੰ ਬਦਲ ਨਹੀਂ ਦਿੰਦਾ। ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਬਦਲਣ (credential rotation) ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਣੀ ਚਾਹੀਦੀ। | 2 | +| **6.2.11** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੰਦਰਭ-ਖ਼ਾਸ ਸ਼ਬਦਾਂ ਦੀ ਦਸਤਾਵੇਜ਼ੀ ਸੂਚੀ ਦੀ ਵਰਤੋਂ ਆਸਾਨੀ ਨਾਲ ਅਨੁਮਾਨ ਲਗਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਪਾਸਵਰਡਾਂ ਨੂੰ ਬਣਾਏ ਜਾਣ ਤੋਂ ਰੋਕਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। | 2 | +| **6.2.12** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਖਾਤਾ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਜਾਂ ਪਾਸਵਰਡ ਬਦਲਣ ਦੌਰਾਨ ਜਮ੍ਹਾਂ ਕੀਤੇ ਪਾਸਵਰਡਾਂ ਦੀ ਜਾਂਚ ਲੀਕ ਹੋਏ (breached) ਪਾਸਵਰਡਾਂ ਦੇ ਸਮੂਹ ਦੇ ਵਿਰੁੱਧ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। | 2 | + +## V6.3 General Authentication Security +## V6.3 ਆਮ ਪ੍ਰਮਾਣੀਕਰਨ ਸੁਰੱਖਿਆ + +This section contains general requirements for the security of authentication mechanisms as well as setting out the different expectations for levels. L2 applications must force the use of multi-factor authentication (MFA). L3 applications must use hardware-based authentication, performed in an attested and trusted execution environment (TEE). This could include device-bound passkeys, eIDAS Level of Assurance (LoA) High enforced authenticators, authenticators with NIST Authenticator Assurance Level 3 (AAL3) assurance, or an equivalent mechanism. + +ਇਸ ਭਾਗ ਵਿੱਚ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਆਮ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ ਅਤੇ ਨਾਲ ਹੀ ਪੱਧਰਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਉਮੀਦਾਂ ਵੀ ਨਿਰਧਾਰਿਤ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। L2 ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਬਹੁ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ (MFA) ਦੀ ਵਰਤੋਂ ਲਾਜ਼ਮੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। L3 ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਹਾਰਡਵੇਅਰ-ਆਧਾਰਿਤ ਪ੍ਰਮਾਣੀਕਰਨ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਇੱਕ ਤਸਦੀਕਸ਼ੁਦਾ (attested) ਅਤੇ ਭਰੋਸੇਯੋਗ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਵਾਤਾਵਰਣ (trusted execution environment, TEE) ਵਿੱਚ ਕੀਤਾ ਜਾਂਦਾ ਹੋਵੇ। ਇਸ ਵਿੱਚ ਡਿਵਾਈਸ-ਬੱਧ ਪਾਸਕੀਆਂ, eIDAS Level of Assurance (LoA) High ਲਾਗੂ ਕੀਤੇ ਪ੍ਰਮਾਣਕ (authenticators), NIST Authenticator Assurance Level 3 (AAL3) ਭਰੋਸੇ ਵਾਲੇ ਪ੍ਰਮਾਣਕ, ਜਾਂ ਕੋਈ ਬਰਾਬਰ ਦੀ ਪ੍ਰਣਾਲੀ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀ ਹੈ। + +While this is a relatively aggressive stance on MFA, it is critical to raise the bar around this to protect users, and any attempt to relax these requirements should be accompanied by a clear plan on how the risks around authentication will be mitigated, taking into account NIST's guidance and research on the topic. + +ਭਾਵੇਂ MFA ਬਾਰੇ ਇਹ ਮੁਕਾਬਲਤਨ ਸਖ਼ਤ ਰੁਖ਼ ਹੈ, ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਇਸ ਸੰਬੰਧੀ ਮਿਆਰ ਉੱਚਾ ਚੁੱਕਣਾ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਲੋੜਾਂ ਵਿੱਚ ਢਿੱਲ ਦੇਣ ਦੀ ਕਿਸੇ ਵੀ ਕੋਸ਼ਿਸ਼ ਦੇ ਨਾਲ ਇੱਕ ਸਪੱਸ਼ਟ ਯੋਜਨਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਸੰਬੰਧੀ ਜੋਖਮਾਂ ਨੂੰ ਕਿਵੇਂ ਘਟਾਇਆ ਜਾਵੇਗਾ, ਜਿਸ ਵਿੱਚ ਇਸ ਵਿਸ਼ੇ 'ਤੇ NIST ਦੇ ਮਾਰਗਦਰਸ਼ਨ ਅਤੇ ਖੋਜ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਜਾਵੇ। + +Note that at the time of release, NIST SP 800-63 considers email as [not acceptable](https://pages.nist.gov/800-63-FAQ/#q-b11) as an authentication mechanism ([archived copy](https://web.archive.org/web/20250330115328/https://pages.nist.gov/800-63-FAQ/#q-b11)). + +ਧਿਆਨ ਦਿਓ ਕਿ ਰਿਲੀਜ਼ ਦੇ ਸਮੇਂ, NIST SP 800-63 ਈਮੇਲ ਨੂੰ ਇੱਕ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀ ਵਜੋਂ [ਸਵੀਕਾਰਯੋਗ ਨਹੀਂ](https://pages.nist.gov/800-63-FAQ/#q-b11) ਮੰਨਦਾ ਹੈ ([ਪੁਰਾਲੇਖ ਕਾਪੀ](https://web.archive.org/web/20250330115328/https://pages.nist.gov/800-63-FAQ/#q-b11))। + +The requirements in this section relate to a variety of sections of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html), including: [§ 4.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html#421-permitted-authenticator-types), [§ 4.3.1](https://pages.nist.gov/800-63-3/sp800-63b.html#431-permitted-authenticator-types), [§ 5.2.2](https://pages.nist.gov/800-63-3/sp800-63b.html#522-rate-limiting-throttling), and [§ 6.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-612-post-enrollment-binding). + +ਇਸ ਭਾਗ ਦੀਆਂ ਲੋੜਾਂ [NIST ਦੇ ਮਾਰਗਦਰਸ਼ਨ](https://pages.nist.gov/800-63-3/sp800-63b.html) ਦੇ ਕਈ ਭਾਗਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: [§ 4.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html#421-permitted-authenticator-types), [§ 4.3.1](https://pages.nist.gov/800-63-3/sp800-63b.html#431-permitted-authenticator-types), [§ 5.2.2](https://pages.nist.gov/800-63-3/sp800-63b.html#522-rate-limiting-throttling), ਅਤੇ [§ 6.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-612-post-enrollment-binding)। + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.3.1** | Verify that controls to prevent attacks such as credential stuffing and password brute force are implemented according to the application's security documentation. | 1 | +| **6.3.2** | Verify that default user accounts (e.g., "root", "admin", or "sa") are not present in the application or are disabled. | 1 | +| **6.3.3** | Verify that either a multi-factor authentication mechanism or a combination of single-factor authentication mechanisms, must be used in order to access the application. For L3, one of the factors must be a hardware-based authentication mechanism which provides compromise and impersonation resistance against phishing attacks while verifying the intent to authenticate by requiring a user-initiated action (such as a button press on a FIDO hardware key or a mobile phone). Relaxing any of the considerations in this requirement requires a fully documented rationale and a comprehensive set of mitigating controls. | 2 | +| **6.3.4** | Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication strength are enforced consistently. | 2 | +| **6.3.5** | Verify that users are notified of suspicious authentication attempts (successful or unsuccessful). This may include authentication attempts from an unusual location or client, partially successful authentication (only one of multiple factors), an authentication attempt after a long period of inactivity or a successful authentication after several unsuccessful attempts. | 3 | +| **6.3.6** | Verify that email is not used as either a single-factor or multi-factor authentication mechanism. | 3 | +| **6.3.7** | Verify that users are notified after updates to authentication details, such as credential resets or modification of the username or email address. | 3 | +| **6.3.8** | Verify that valid users cannot be deduced from failed authentication challenges, such as by basing on error messages, HTTP response codes, or different response times. Registration and forgot password functionality must also have this protection. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **6.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕ੍ਰੀਡੈਂਸ਼ੀਅਲ ਸਟਫ਼ਿੰਗ ਅਤੇ ਪਾਸਵਰਡ ਬਰੂਟ ਫੋਰਸ ਵਰਗੇ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਨਿਯੰਤਰਣ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸੁਰੱਖਿਆ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਦੇ ਅਨੁਸਾਰ ਲਾਗੂ ਕੀਤੇ ਗਏ ਹਨ। | 1 | +| **6.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਡਿਫ਼ਾਲਟ ਉਪਭੋਗਤਾ ਖਾਤੇ (ਜਿਵੇਂ ਕਿ "root", "admin", ਜਾਂ "sa") ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹਨ ਜਾਂ ਅਯੋਗ ਕੀਤੇ ਗਏ ਹਨ। | 1 | +| **6.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ ਜਾਂ ਤਾਂ ਇੱਕ ਬਹੁ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀ ਜਾਂ ਇੱਕ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਸੁਮੇਲ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। L3 ਲਈ, ਕਾਰਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਾਰਡਵੇਅਰ-ਆਧਾਰਿਤ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਫ਼ਿਸ਼ਿੰਗ ਹਮਲਿਆਂ ਦੇ ਵਿਰੁੱਧ ਸਮਝੌਤਾ ਅਤੇ ਪਛਾਣ-ਨਕਲ ਪ੍ਰਤੀ ਰੋਧਕਤਾ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੀ ਕਾਰਵਾਈ (ਜਿਵੇਂ ਕਿ FIDO ਹਾਰਡਵੇਅਰ ਕੁੰਜੀ ਜਾਂ ਮੋਬਾਈਲ ਫ਼ੋਨ 'ਤੇ ਬਟਨ ਦਬਾਉਣਾ) ਦੀ ਲੋੜ ਰੱਖ ਕੇ ਪ੍ਰਮਾਣੀਕਰਨ ਦੇ ਇਰਾਦੇ ਦੀ ਤਸਦੀਕ ਕਰਦੀ ਹੈ। ਇਸ ਲੋੜ ਦੇ ਕਿਸੇ ਵੀ ਵਿਚਾਰ ਵਿੱਚ ਢਿੱਲ ਦੇਣ ਲਈ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦਸਤਾਵੇਜ਼ੀ ਤਰਕ ਅਤੇ ਘਟਾਉ ਨਿਯੰਤਰਣਾਂ ਦੇ ਇੱਕ ਵਿਆਪਕ ਸਮੂਹ ਦੀ ਲੋੜ ਹੈ। | 2 | +| **6.3.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਕਈ ਪ੍ਰਮਾਣੀਕਰਨ ਮਾਰਗ ਸ਼ਾਮਲ ਹਨ, ਤਾਂ ਕੋਈ ਵੀ ਗ਼ੈਰ-ਦਸਤਾਵੇਜ਼ੀ ਮਾਰਗ ਨਹੀਂ ਹੈ ਅਤੇ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਤਾਕਤ ਇਕਸਾਰ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। | 2 | +| **6.3.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸ਼ੱਕੀ ਪ੍ਰਮਾਣੀਕਰਨ ਕੋਸ਼ਿਸ਼ਾਂ (ਸਫਲ ਜਾਂ ਅਸਫਲ) ਬਾਰੇ ਸੂਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਕਿਸੇ ਅਸਧਾਰਨ ਟਿਕਾਣੇ ਜਾਂ ਕਲਾਇੰਟ ਤੋਂ ਪ੍ਰਮਾਣੀਕਰਨ ਕੋਸ਼ਿਸ਼ਾਂ, ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਸਫਲ ਪ੍ਰਮਾਣੀਕਰਨ (ਕਈ ਕਾਰਕਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ), ਲੰਬੇ ਸਮੇਂ ਦੀ ਨਿਸ਼ਕਿਰਿਆ ਤੋਂ ਬਾਅਦ ਪ੍ਰਮਾਣੀਕਰਨ ਕੋਸ਼ਿਸ਼ ਜਾਂ ਕਈ ਅਸਫਲ ਕੋਸ਼ਿਸ਼ਾਂ ਤੋਂ ਬਾਅਦ ਸਫਲ ਪ੍ਰਮਾਣੀਕਰਨ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ। | 3 | +| **6.3.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਈਮੇਲ ਨੂੰ ਨਾ ਤਾਂ ਇੱਕ-ਕਾਰਕ ਅਤੇ ਨਾ ਹੀ ਬਹੁ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। | 3 | +| **6.3.7** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਵੇਰਵਿਆਂ ਵਿੱਚ ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ, ਜਿਵੇਂ ਕਿ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਰੀਸੈੱਟ ਜਾਂ ਉਪਭੋਗਤਾ ਨਾਂ ਜਾਂ ਈਮੇਲ ਪਤੇ ਵਿੱਚ ਸੋਧ, ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸੂਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। | 3 | +| **6.3.8** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਅਸਫਲ ਪ੍ਰਮਾਣੀਕਰਨ ਚੁਣੌਤੀਆਂ ਤੋਂ ਜਾਇਜ਼ ਉਪਭੋਗਤਾਵਾਂ ਦਾ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਇਆ ਜਾ ਸਕਦਾ, ਜਿਵੇਂ ਕਿ ਗਲਤੀ ਸੁਨੇਹਿਆਂ, HTTP ਜਵਾਬ ਕੋਡਾਂ, ਜਾਂ ਵੱਖ-ਵੱਖ ਜਵਾਬ ਸਮਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ। ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਅਤੇ ਪਾਸਵਰਡ ਭੁੱਲ ਜਾਣ ਦੀ ਕਾਰਜਸ਼ੀਲਤਾ ਵਿੱਚ ਵੀ ਇਹ ਸੁਰੱਖਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। | 3 | + +## V6.4 Authentication Factor Lifecycle and Recovery +## V6.4 ਪ੍ਰਮਾਣੀਕਰਨ ਕਾਰਕ ਜੀਵਨ-ਚੱਕਰ ਅਤੇ ਰਿਕਵਰੀ + +Authentication factors may include passwords, soft tokens, hardware tokens, and biometric devices. Securely handling the lifecycle of these mechanisms is critical to the security of an application, and this section includes requirements related to this. + +ਪ੍ਰਮਾਣੀਕਰਨ ਕਾਰਕਾਂ ਵਿੱਚ ਪਾਸਵਰਡ, ਸਾਫ਼ਟ ਟੋਕਨ, ਹਾਰਡਵੇਅਰ ਟੋਕਨ, ਅਤੇ ਬਾਇਓਮੈਟ੍ਰਿਕ (biometric) ਡਿਵਾਈਸਾਂ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਇਹਨਾਂ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਜੀਵਨ-ਚੱਕਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣਾ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਅਤੇ ਇਸ ਭਾਗ ਵਿੱਚ ਇਸ ਨਾਲ ਸੰਬੰਧਿਤ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ। + +The requirements in this section mostly relate to [§ 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) or [§ 6.1.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#replacement) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). + +ਇਸ ਭਾਗ ਦੀਆਂ ਲੋੜਾਂ ਜ਼ਿਆਦਾਤਰ [NIST ਦੇ ਮਾਰਗਦਰਸ਼ਨ](https://pages.nist.gov/800-63-3/sp800-63b.html) ਦੇ [§ 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) ਜਾਂ [§ 6.1.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#replacement) ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.4.1** | Verify that system generated initial passwords or activation codes are securely randomly generated, follow the existing password policy, and expire after a short period of time or after they are initially used. These initial secrets must not be permitted to become the long term password. | 1 | +| **6.4.2** | Verify that password hints or knowledge-based authentication (so-called "secret questions") are not present. | 1 | +| **6.4.3** | Verify that a secure process for resetting a forgotten password is implemented, that does not bypass any enabled multi-factor authentication mechanisms. | 2 | +| **6.4.4** | Verify that if a multi-factor authentication factor is lost, evidence of identity proofing is performed at the same level as during enrollment. | 2 | +| **6.4.5** | Verify that renewal instructions for authentication mechanisms which expire are sent with enough time to be carried out before the old authentication mechanism expires, configuring automated reminders if necessary. | 3 | +| **6.4.6** | Verify that administrative users can initiate the password reset process for the user, but that this does not allow them to change or choose the user's password. This prevents a situation where they know the user's password. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **6.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਿਸਟਮ ਦੁਆਰਾ ਪੈਦਾ ਕੀਤੇ ਸ਼ੁਰੂਆਤੀ ਪਾਸਵਰਡ ਜਾਂ ਸਰਗਰਮੀ ਕੋਡ (activation codes) ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਬੇਤਰਤੀਬ ਤੌਰ 'ਤੇ ਪੈਦਾ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਮੌਜੂਦਾ ਪਾਸਵਰਡ ਨੀਤੀ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਬਾਅਦ ਜਾਂ ਪਹਿਲੀ ਵਾਰ ਵਰਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਮਿਆਦ ਪੁੱਗ ਜਾਂਦੇ ਹਨ। ਇਹਨਾਂ ਸ਼ੁਰੂਆਤੀ ਭੇਦਾਂ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਦਾ ਪਾਸਵਰਡ ਬਣਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। | 1 | +| **6.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪਾਸਵਰਡ ਸੰਕੇਤ (password hints) ਜਾਂ ਗਿਆਨ-ਆਧਾਰਿਤ ਪ੍ਰਮਾਣੀਕਰਨ (ਅਖੌਤੀ "ਗੁਪਤ ਸਵਾਲ") ਮੌਜੂਦ ਨਹੀਂ ਹਨ। | 1 | +| **6.4.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਭੁੱਲੇ ਹੋਏ ਪਾਸਵਰਡ ਨੂੰ ਰੀਸੈੱਟ ਕਰਨ ਲਈ ਇੱਕ ਸੁਰੱਖਿਅਤ ਪ੍ਰਕਿਰਿਆ ਲਾਗੂ ਕੀਤੀ ਗਈ ਹੈ, ਜੋ ਕਿਸੇ ਵੀ ਸਮਰੱਥ ਬਹੁ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀ ਨੂੰ ਬਾਈਪਾਸ ਨਹੀਂ ਕਰਦੀ। | 2 | +| **6.4.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜੇ ਕੋਈ ਬਹੁ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ ਕਾਰਕ ਗੁਆਚ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਪਛਾਣ ਸਬੂਤੀਕਰਨ (identity proofing) ਦਾ ਸਬੂਤ ਉਸੇ ਪੱਧਰ 'ਤੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਵੇਂ ਨਾਮਾਂਕਣ (enrollment) ਦੌਰਾਨ ਕੀਤਾ ਗਿਆ ਸੀ। | 2 | +| **6.4.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਮਿਆਦ ਪੁੱਗਣ ਵਾਲੀਆਂ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਨਵੀਨੀਕਰਨ ਹਦਾਇਤਾਂ ਇੰਨੇ ਸਮੇਂ ਨਾਲ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਕਿ ਪੁਰਾਣੀ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀ ਦੀ ਮਿਆਦ ਪੁੱਗਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ 'ਤੇ ਅਮਲ ਕੀਤਾ ਜਾ ਸਕੇ, ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸਵੈਚਾਲਿਤ ਯਾਦ-ਦਹਾਨੀਆਂ ਕੌਨਫ਼ਿਗਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। | 3 | +| **6.4.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪ੍ਰਸ਼ਾਸਕੀ ਉਪਭੋਗਤਾ ਉਪਭੋਗਤਾ ਲਈ ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਇਹ ਉਹਨਾਂ ਨੂੰ ਉਪਭੋਗਤਾ ਦਾ ਪਾਸਵਰਡ ਬਦਲਣ ਜਾਂ ਚੁਣਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੀ। ਇਹ ਅਜਿਹੀ ਸਥਿਤੀ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਉਹ ਉਪਭੋਗਤਾ ਦਾ ਪਾਸਵਰਡ ਜਾਣਦੇ ਹੋਣ। | 3 | + +## V6.5 General Multi-factor authentication requirements +## V6.5 ਆਮ ਬਹੁ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ ਲੋੜਾਂ + +This section provides general guidance that will be relevant to various different multi-factor authentication methods. + +ਇਹ ਭਾਗ ਆਮ ਮਾਰਗਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਵੱਖ-ਵੱਖ ਬਹੁ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ ਵਿਧੀਆਂ ਲਈ ਢੁਕਵਾਂ ਹੋਵੇਗਾ। + +The mechanisms include: + +ਇਹਨਾਂ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: + +* Lookup Secrets +* Time based One-time Passwords (TOTPs) +* Out-of-Band mechanisms + +* ਲੁੱਕਅੱਪ ਭੇਦ (Lookup Secrets) +* ਸਮਾਂ-ਆਧਾਰਿਤ ਇੱਕ-ਵਾਰੀ ਪਾਸਵਰਡ (Time based One-time Passwords, TOTP) +* ਆਊਟ-ਆਫ਼-ਬੈਂਡ (Out-of-Band) ਪ੍ਰਣਾਲੀਆਂ + +Lookup secrets are pre-generated lists of secret codes, similar to Transaction Authorization Numbers (TAN), social media recovery codes, or a grid containing a set of random values. This type of authentication mechanism is considered "something you have" because the codes are deliberately not memorable so will need to be stored somewhere. + +ਲੁੱਕਅੱਪ ਭੇਦ ਗੁਪਤ ਕੋਡਾਂ ਦੀਆਂ ਪਹਿਲਾਂ ਤੋਂ ਪੈਦਾ ਕੀਤੀਆਂ ਸੂਚੀਆਂ ਹਨ, ਜੋ ਲੈਣ-ਦੇਣ ਅਧਿਕਾਰੀਕਰਨ ਨੰਬਰਾਂ (Transaction Authorization Numbers, TAN), ਸੋਸ਼ਲ ਮੀਡੀਆ ਰਿਕਵਰੀ ਕੋਡਾਂ, ਜਾਂ ਬੇਤਰਤੀਬ ਮੁੱਲਾਂ ਦੇ ਸਮੂਹ ਵਾਲੇ ਗਰਿੱਡ ਵਰਗੀਆਂ ਹਨ। ਇਸ ਕਿਸਮ ਦੀ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀ ਨੂੰ "ਕੁਝ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਹੈ" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕੋਡ ਜਾਣ-ਬੁੱਝ ਕੇ ਯਾਦ ਰੱਖਣ ਯੋਗ ਨਹੀਂ ਹੁੰਦੇ, ਇਸ ਲਈ ਇਹਨਾਂ ਨੂੰ ਕਿਤੇ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ ਪਵੇਗੀ। + +Time based One-time Passwords (TOTPs) are physical or soft tokens that display a continually changing pseudo-random one-time challenge. This type of authentication mechanism is considered "something you have". Multi-factor TOTPs are similar to single-factor TOTPs, but require a valid PIN code, biometric unlocking, USB insertion or NFC pairing, or some additional value (such as transaction signing calculators) to be entered to create the final One-time Password (OTP). + +ਸਮਾਂ-ਆਧਾਰਿਤ ਇੱਕ-ਵਾਰੀ ਪਾਸਵਰਡ (TOTP) ਭੌਤਿਕ ਜਾਂ ਸਾਫ਼ਟ ਟੋਕਨ ਹਨ ਜੋ ਲਗਾਤਾਰ ਬਦਲਦੀ ਰਹਿਣ ਵਾਲੀ ਛਦਮ-ਬੇਤਰਤੀਬ (pseudo-random) ਇੱਕ-ਵਾਰੀ ਚੁਣੌਤੀ ਦਿਖਾਉਂਦੇ ਹਨ। ਇਸ ਕਿਸਮ ਦੀ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀ ਨੂੰ "ਕੁਝ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਹੈ" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਬਹੁ-ਕਾਰਕ TOTP ਇੱਕ-ਕਾਰਕ TOTP ਵਰਗੇ ਹੀ ਹਨ, ਪਰ ਅੰਤਿਮ ਇੱਕ-ਵਾਰੀ ਪਾਸਵਰਡ (OTP) ਬਣਾਉਣ ਲਈ ਇੱਕ ਜਾਇਜ਼ PIN ਕੋਡ, ਬਾਇਓਮੈਟ੍ਰਿਕ ਅਨਲੌਕਿੰਗ, USB ਲਗਾਉਣ ਜਾਂ NFC ਜੋੜੀ ਬਣਾਉਣ (pairing), ਜਾਂ ਕੋਈ ਵਾਧੂ ਮੁੱਲ (ਜਿਵੇਂ ਕਿ ਲੈਣ-ਦੇਣ ਦਸਤਖ਼ਤ ਕੈਲਕੁਲੇਟਰ) ਦਾਖ਼ਲ ਕੀਤੇ ਜਾਣ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ। + +Details on out-of-band mechanisms will be provided in the next section. + +ਆਊਟ-ਆਫ਼-ਬੈਂਡ ਪ੍ਰਣਾਲੀਆਂ ਬਾਰੇ ਵੇਰਵੇ ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਦਿੱਤੇ ਜਾਣਗੇ। + +The requirements in these sections mostly relate to [§ 5.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-512-look-up-secrets), [§ 5.1.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-513-out-of-band-devices), [§ 5.1.4.2](https://pages.nist.gov/800-63-3/sp800-63b.html#5142-single-factor-otp-verifiers), [§ 5.1.5.2](https://pages.nist.gov/800-63-3/sp800-63b.html#5152-multi-factor-otp-verifiers), [§ 5.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html#521-physical-authenticators), and [§ 5.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#523-use-of-biometrics) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). + +ਇਹਨਾਂ ਭਾਗਾਂ ਦੀਆਂ ਲੋੜਾਂ ਜ਼ਿਆਦਾਤਰ [NIST ਦੇ ਮਾਰਗਦਰਸ਼ਨ](https://pages.nist.gov/800-63-3/sp800-63b.html) ਦੇ [§ 5.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#-512-look-up-secrets), [§ 5.1.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-513-out-of-band-devices), [§ 5.1.4.2](https://pages.nist.gov/800-63-3/sp800-63b.html#5142-single-factor-otp-verifiers), [§ 5.1.5.2](https://pages.nist.gov/800-63-3/sp800-63b.html#5152-multi-factor-otp-verifiers), [§ 5.2.1](https://pages.nist.gov/800-63-3/sp800-63b.html#521-physical-authenticators), ਅਤੇ [§ 5.2.3](https://pages.nist.gov/800-63-3/sp800-63b.html#523-use-of-biometrics) ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.5.1** | Verify that lookup secrets, out-of-band authentication requests or codes, and time-based one-time passwords (TOTPs) are only successfully usable once. | 2 | +| **6.5.2** | Verify that, when being stored in the application's backend, lookup secrets with less than 112 bits of entropy (19 random alphanumeric characters or 34 random digits) are hashed with an approved password storage hashing algorithm that incorporates a 32-bit random salt. A standard hash function can be used if the secret has 112 bits of entropy or more. | 2 | +| **6.5.3** | Verify that lookup secrets, out-of-band authentication code, and time-based one-time password seeds, are generated using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) to avoid predictable values. | 2 | +| **6.5.4** | Verify that lookup secrets and out-of-band authentication codes have a minimum of 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient). | 2 | +| **6.5.5** | Verify that out-of-band authentication requests, codes, or tokens, as well as time-based one-time passwords (TOTPs) have a defined lifetime. Out of band requests must have a maximum lifetime of 10 minutes and for TOTP a maximum lifetime of 30 seconds. | 2 | +| **6.5.6** | Verify that any authentication factor (including physical devices) can be revoked in case of theft or other loss. | 3 | +| **6.5.7** | Verify that biometric authentication mechanisms are only used as secondary factors together with either something you have or something you know. | 3 | +| **6.5.8** | Verify that time-based one-time passwords (TOTPs) are checked based on a time source from a trusted service and not from an untrusted or client provided time. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **6.5.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਲੁੱਕਅੱਪ ਭੇਦ, ਆਊਟ-ਆਫ਼-ਬੈਂਡ ਪ੍ਰਮਾਣੀਕਰਨ ਬੇਨਤੀਆਂ ਜਾਂ ਕੋਡ, ਅਤੇ ਸਮਾਂ-ਆਧਾਰਿਤ ਇੱਕ-ਵਾਰੀ ਪਾਸਵਰਡ (TOTP) ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਹੀ ਸਫਲਤਾਪੂਰਵਕ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ। | 2 | +| **6.5.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਬੈਕਐਂਡ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਣ ਸਮੇਂ, 112 ਬਿੱਟ ਤੋਂ ਘੱਟ ਐਂਟਰੋਪੀ (entropy) ਵਾਲੇ ਲੁੱਕਅੱਪ ਭੇਦਾਂ (19 ਬੇਤਰਤੀਬ ਅੱਖਰ-ਅੰਕ ਜਾਂ 34 ਬੇਤਰਤੀਬ ਅੰਕ) ਨੂੰ ਇੱਕ ਪ੍ਰਵਾਨਿਤ ਪਾਸਵਰਡ ਸਟੋਰੇਜ ਹੈਸ਼ਿੰਗ ਐਲਗੋਰਿਦਮ ਨਾਲ ਹੈਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ 32-ਬਿੱਟ ਬੇਤਰਤੀਬ ਸਾਲਟ (salt) ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। ਜੇ ਭੇਦ ਵਿੱਚ 112 ਬਿੱਟ ਜਾਂ ਵੱਧ ਐਂਟਰੋਪੀ ਹੈ ਤਾਂ ਇੱਕ ਮਿਆਰੀ ਹੈਸ਼ ਫੰਕਸ਼ਨ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। | 2 | +| **6.5.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਲੁੱਕਅੱਪ ਭੇਦ, ਆਊਟ-ਆਫ਼-ਬੈਂਡ ਪ੍ਰਮਾਣੀਕਰਨ ਕੋਡ, ਅਤੇ ਸਮਾਂ-ਆਧਾਰਿਤ ਇੱਕ-ਵਾਰੀ ਪਾਸਵਰਡ ਸੀਡ (seeds), ਅਨੁਮਾਨਯੋਗ ਮੁੱਲਾਂ ਤੋਂ ਬਚਣ ਲਈ ਇੱਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਛਦਮ-ਬੇਤਰਤੀਬ ਨੰਬਰ ਜਨਰੇਟਰ (Cryptographically Secure Pseudorandom Number Generator, CSPRNG) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੈਦਾ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। | 2 | +| **6.5.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਲੁੱਕਅੱਪ ਭੇਦਾਂ ਅਤੇ ਆਊਟ-ਆਫ਼-ਬੈਂਡ ਪ੍ਰਮਾਣੀਕਰਨ ਕੋਡਾਂ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ 20 ਬਿੱਟ ਐਂਟਰੋਪੀ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ 4 ਬੇਤਰਤੀਬ ਅੱਖਰ-ਅੰਕ ਜਾਂ 6 ਬੇਤਰਤੀਬ ਅੰਕ ਕਾਫ਼ੀ ਹਨ)। | 2 | +| **6.5.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਆਊਟ-ਆਫ਼-ਬੈਂਡ ਪ੍ਰਮਾਣੀਕਰਨ ਬੇਨਤੀਆਂ, ਕੋਡਾਂ, ਜਾਂ ਟੋਕਨਾਂ, ਅਤੇ ਨਾਲ ਹੀ ਸਮਾਂ-ਆਧਾਰਿਤ ਇੱਕ-ਵਾਰੀ ਪਾਸਵਰਡਾਂ (TOTP) ਦਾ ਇੱਕ ਪਰਿਭਾਸ਼ਿਤ ਜੀਵਨਕਾਲ ਹੈ। ਆਊਟ-ਆਫ਼-ਬੈਂਡ ਬੇਨਤੀਆਂ ਦਾ ਵੱਧ ਤੋਂ ਵੱਧ ਜੀਵਨਕਾਲ 10 ਮਿੰਟ ਅਤੇ TOTP ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਜੀਵਨਕਾਲ 30 ਸਕਿੰਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। | 2 | +| **6.5.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਚੋਰੀ ਜਾਂ ਹੋਰ ਨੁਕਸਾਨ ਦੀ ਸੂਰਤ ਵਿੱਚ ਕਿਸੇ ਵੀ ਪ੍ਰਮਾਣੀਕਰਨ ਕਾਰਕ (ਭੌਤਿਕ ਡਿਵਾਈਸਾਂ ਸਮੇਤ) ਨੂੰ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। | 3 | +| **6.5.7** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਬਾਇਓਮੈਟ੍ਰਿਕ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀਆਂ ਸਿਰਫ਼ ਸੈਕੰਡਰੀ ਕਾਰਕਾਂ ਵਜੋਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਾਂ ਤਾਂ "ਕੁਝ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਹੈ" ਜਾਂ "ਕੁਝ ਜੋ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ" ਦੇ ਨਾਲ ਮਿਲ ਕੇ। | 3 | +| **6.5.8** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਮਾਂ-ਆਧਾਰਿਤ ਇੱਕ-ਵਾਰੀ ਪਾਸਵਰਡਾਂ (TOTP) ਦੀ ਜਾਂਚ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸੇਵਾ ਤੋਂ ਪ੍ਰਾਪਤ ਸਮਾਂ ਸਰੋਤ ਦੇ ਆਧਾਰ 'ਤੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਨਾ ਕਿ ਕਿਸੇ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਜਾਂ ਕਲਾਇੰਟ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਸਮੇਂ ਦੇ ਆਧਾਰ 'ਤੇ। | 3 | + +## V6.6 Out-of-Band authentication mechanisms +## V6.6 ਆਊਟ-ਆਫ਼-ਬੈਂਡ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀਆਂ + +This usually involves the authentication server communicating with a physical device over a secure secondary channel. For example, sending push notifications to mobile devices. This type of authentication mechanism is considered "something you have". + +ਇਸ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਸਰਵਰ ਦਾ ਇੱਕ ਸੁਰੱਖਿਅਤ ਸੈਕੰਡਰੀ ਚੈਨਲ ਰਾਹੀਂ ਕਿਸੇ ਭੌਤਿਕ ਡਿਵਾਈਸ ਨਾਲ ਸੰਚਾਰ ਕਰਨਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ ਨੂੰ ਪੁਸ਼ ਸੂਚਨਾਵਾਂ (push notifications) ਭੇਜਣਾ। ਇਸ ਕਿਸਮ ਦੀ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀ ਨੂੰ "ਕੁਝ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਹੈ" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। + +Unsafe out-of-band authentication mechanisms such as e-mail and VOIP are not permitted. PSTN and SMS authentication are currently considered to be ["restricted" authentication mechanisms](https://pages.nist.gov/800-63-FAQ/#q-b01) by NIST and should be deprecated in favor of Time based One-time Passwords (TOTPs), a cryptographic mechanism, or similar. NIST SP 800-63B [§ 5.1.3.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-5133-authentication-using-the-public-switched-telephone-network) recommends addressing the risks of device swap, SIM change, number porting, or other abnormal behavior, if telephone or SMS out-of-band authentication absolutely has to be supported. While this ASVS section does not mandate this as a requirement, not taking these precautions for a sensitive L2 app or an L3 app should be seen as a significant red flag. + +ਈਮੇਲ ਅਤੇ VOIP ਵਰਗੀਆਂ ਅਸੁਰੱਖਿਅਤ ਆਊਟ-ਆਫ਼-ਬੈਂਡ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ। PSTN ਅਤੇ SMS ਪ੍ਰਮਾਣੀਕਰਨ ਨੂੰ ਇਸ ਸਮੇਂ NIST ਦੁਆਰਾ ["ਪ੍ਰਤਿਬੰਧਿਤ" (restricted) ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀਆਂ](https://pages.nist.gov/800-63-FAQ/#q-b01) ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਸਮਾਂ-ਆਧਾਰਿਤ ਇੱਕ-ਵਾਰੀ ਪਾਸਵਰਡਾਂ (TOTP), ਕਿਸੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਪ੍ਰਣਾਲੀ, ਜਾਂ ਇਸੇ ਤਰ੍ਹਾਂ ਦੀ ਕਿਸੇ ਹੋਰ ਪ੍ਰਣਾਲੀ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹੋਏ ਅਪ੍ਰਚਲਿਤ (deprecate) ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। NIST SP 800-63B [§ 5.1.3.3](https://pages.nist.gov/800-63-3/sp800-63b.html#-5133-authentication-using-the-public-switched-telephone-network) ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹੈ ਕਿ, ਜੇ ਟੈਲੀਫ਼ੋਨ ਜਾਂ SMS ਆਊਟ-ਆਫ਼-ਬੈਂਡ ਪ੍ਰਮਾਣੀਕਰਨ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਬਿਲਕੁਲ ਲਾਜ਼ਮੀ ਹੀ ਹੋਵੇ, ਤਾਂ ਡਿਵਾਈਸ ਦੀ ਅਦਲਾ-ਬਦਲੀ, SIM ਬਦਲਣ, ਨੰਬਰ ਪੋਰਟਿੰਗ (number porting), ਜਾਂ ਹੋਰ ਅਸਧਾਰਨ ਵਿਹਾਰ ਦੇ ਜੋਖਮਾਂ ਨਾਲ ਨਜਿੱਠਿਆ ਜਾਵੇ। ਭਾਵੇਂ ASVS ਦਾ ਇਹ ਭਾਗ ਇਸ ਨੂੰ ਇੱਕ ਲੋੜ ਵਜੋਂ ਲਾਜ਼ਮੀ ਨਹੀਂ ਕਰਦਾ, ਕਿਸੇ ਸੰਵੇਦਨਸ਼ੀਲ L2 ਐਪ ਜਾਂ L3 ਐਪ ਲਈ ਇਹ ਸਾਵਧਾਨੀਆਂ ਨਾ ਵਰਤਣ ਨੂੰ ਇੱਕ ਗੰਭੀਰ ਚੇਤਾਵਨੀ ਸੰਕੇਤ (red flag) ਵਜੋਂ ਵੇਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। + +Note that NIST has also recently provided guidance which [discourages the use of push notifications](https://pages.nist.gov/800-63-4/sp800-63b/authenticators/#fig-3). While this ASVS section does not do so, it is important to be aware of the risks of "push bombing". + +ਧਿਆਨ ਦਿਓ ਕਿ NIST ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਅਜਿਹਾ ਮਾਰਗਦਰਸ਼ਨ ਵੀ ਪ੍ਰਦਾਨ ਕੀਤਾ ਹੈ ਜੋ [ਪੁਸ਼ ਸੂਚਨਾਵਾਂ ਦੀ ਵਰਤੋਂ ਨੂੰ ਨਿਰਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ](https://pages.nist.gov/800-63-4/sp800-63b/authenticators/#fig-3)। ਭਾਵੇਂ ASVS ਦਾ ਇਹ ਭਾਗ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦਾ, "ਪੁਸ਼ ਬੌਂਬਿੰਗ" (push bombing) ਦੇ ਜੋਖਮਾਂ ਤੋਂ ਜਾਣੂ ਹੋਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.6.1** | Verify that authentication mechanisms using the Public Switched Telephone Network (PSTN) to deliver One-time Passwords (OTPs) via phone or SMS are offered only when the phone number has previously been validated, alternate stronger methods (such as Time based One-time Passwords) are also offered, and the service provides information on their security risks to users. For L3 applications, phone and SMS must not be available as options. | 2 | +| **6.6.2** | Verify that out-of-band authentication requests, codes, or tokens are bound to the original authentication request for which they were generated and are not usable for a previous or subsequent one. | 2 | +| **6.6.3** | Verify that a code based out-of-band authentication mechanism is protected against brute force attacks by using rate limiting. Consider also using a code with at least 64 bits of entropy. | 2 | +| **6.6.4** | Verify that, where push notifications are used for multi-factor authentication, rate limiting is used to prevent push bombing attacks. Number matching may also mitigate this risk. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **6.6.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਫ਼ੋਨ ਜਾਂ SMS ਰਾਹੀਂ ਇੱਕ-ਵਾਰੀ ਪਾਸਵਰਡ (OTP) ਪਹੁੰਚਾਉਣ ਲਈ ਜਨਤਕ ਸਵਿੱਚਡ ਟੈਲੀਫ਼ੋਨ ਨੈੱਟਵਰਕ (Public Switched Telephone Network, PSTN) ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀਆਂ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਪੇਸ਼ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਜਦੋਂ ਫ਼ੋਨ ਨੰਬਰ ਨੂੰ ਪਹਿਲਾਂ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾ ਚੁੱਕਾ ਹੋਵੇ, ਬਦਲਵੀਆਂ ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਵਿਧੀਆਂ (ਜਿਵੇਂ ਕਿ ਸਮਾਂ-ਆਧਾਰਿਤ ਇੱਕ-ਵਾਰੀ ਪਾਸਵਰਡ) ਵੀ ਪੇਸ਼ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹੋਣ, ਅਤੇ ਸੇਵਾ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇਹਨਾਂ ਦੇ ਸੁਰੱਖਿਆ ਜੋਖਮਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੋਵੇ। L3 ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ, ਫ਼ੋਨ ਅਤੇ SMS ਵਿਕਲਪਾਂ ਵਜੋਂ ਉਪਲਬਧ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ। | 2 | +| **6.6.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਆਊਟ-ਆਫ਼-ਬੈਂਡ ਪ੍ਰਮਾਣੀਕਰਨ ਬੇਨਤੀਆਂ, ਕੋਡ, ਜਾਂ ਟੋਕਨ ਉਸ ਮੂਲ ਪ੍ਰਮਾਣੀਕਰਨ ਬੇਨਤੀ ਨਾਲ ਬੱਧ ਹਨ ਜਿਸ ਲਈ ਉਹ ਪੈਦਾ ਕੀਤੇ ਗਏ ਸਨ, ਅਤੇ ਕਿਸੇ ਪਿਛਲੀ ਜਾਂ ਅਗਲੀ ਬੇਨਤੀ ਲਈ ਵਰਤਣਯੋਗ ਨਹੀਂ ਹਨ। | 2 | +| **6.6.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕੋਡ-ਆਧਾਰਿਤ ਆਊਟ-ਆਫ਼-ਬੈਂਡ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀ ਦਰ ਸੀਮਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਰੂਟ ਫੋਰਸ ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੈ। ਘੱਟੋ-ਘੱਟ 64 ਬਿੱਟ ਐਂਟਰੋਪੀ ਵਾਲਾ ਕੋਡ ਵਰਤਣ 'ਤੇ ਵੀ ਵਿਚਾਰ ਕਰੋ। | 2 | +| **6.6.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜਿੱਥੇ ਬਹੁ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ ਪੁਸ਼ ਸੂਚਨਾਵਾਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਉੱਥੇ ਪੁਸ਼ ਬੌਂਬਿੰਗ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਦਰ ਸੀਮਾ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਨੰਬਰ ਮਿਲਾਨ (number matching) ਵੀ ਇਸ ਜੋਖਮ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ। | 3 | + +## V6.7 Cryptographic authentication mechanism +## V6.7 ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀ + +Cryptographic authentication mechanisms include smart cards or FIDO keys, where the user has to plug in or pair the cryptographic device to the computer to complete authentication. The authentication server will send a challenge nonce to the cryptographic device or software, and the device or software calculates a response based upon a securely stored cryptographic key. The requirements in this section provide implementation-specific guidance for these mechanisms, with guidance on cryptographic algorithms being covered in the "Cryptography" chapter. + +ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਸਮਾਰਟ ਕਾਰਡ ਜਾਂ FIDO ਕੁੰਜੀਆਂ ਸ਼ਾਮਲ ਹਨ, ਜਿੱਥੇ ਪ੍ਰਮਾਣੀਕਰਨ ਪੂਰਾ ਕਰਨ ਲਈ ਉਪਭੋਗਤਾ ਨੂੰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਡਿਵਾਈਸ ਨੂੰ ਕੰਪਿਊਟਰ ਨਾਲ ਲਗਾਉਣਾ ਜਾਂ ਜੋੜੀ ਬਣਾਉਣੀ (pair) ਪੈਂਦੀ ਹੈ। ਪ੍ਰਮਾਣੀਕਰਨ ਸਰਵਰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਡਿਵਾਈਸ ਜਾਂ ਸਾਫ਼ਟਵੇਅਰ ਨੂੰ ਇੱਕ ਚੁਣੌਤੀ ਨੌਂਸ (challenge nonce) ਭੇਜੇਗਾ, ਅਤੇ ਡਿਵਾਈਸ ਜਾਂ ਸਾਫ਼ਟਵੇਅਰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸਟੋਰ ਕੀਤੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਕੁੰਜੀ ਦੇ ਆਧਾਰ 'ਤੇ ਇੱਕ ਜਵਾਬ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ। ਇਸ ਭਾਗ ਦੀਆਂ ਲੋੜਾਂ ਇਹਨਾਂ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਲਾਗੂਕਰਨ-ਖ਼ਾਸ ਮਾਰਗਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ, ਜਦੋਂ ਕਿ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਐਲਗੋਰਿਦਮਾਂ ਬਾਰੇ ਮਾਰਗਦਰਸ਼ਨ "ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ" (Cryptography) ਅਧਿਆਇ ਵਿੱਚ ਕਵਰ ਕੀਤਾ ਗਿਆ ਹੈ। + +Where shared or secret keys are used for cryptographic authentication, these should be stored using the same mechanisms as other system secrets, as documented in the "Secret Management" section in the "Configuration" chapter. + +ਜਿੱਥੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ ਸਾਂਝੀਆਂ ਜਾਂ ਗੁਪਤ ਕੁੰਜੀਆਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਉੱਥੇ ਇਹਨਾਂ ਨੂੰ ਹੋਰ ਸਿਸਟਮ ਭੇਦਾਂ ਵਾਂਗ ਹੀ ਉਹਨਾਂ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਟੋਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ "ਸੰਰਚਨਾ" (Configuration) ਅਧਿਆਇ ਦੇ "ਭੇਦ ਪ੍ਰਬੰਧਨ" (Secret Management) ਭਾਗ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਵਿੱਚ ਦਰਜ ਹੈ। + +The requirements in this section mostly relate to [§ 5.1.7.2](https://pages.nist.gov/800-63-3/sp800-63b.html#sfcdv) of [NIST's Guidance](https://pages.nist.gov/800-63-3/sp800-63b.html). + +ਇਸ ਭਾਗ ਦੀਆਂ ਲੋੜਾਂ ਜ਼ਿਆਦਾਤਰ [NIST ਦੇ ਮਾਰਗਦਰਸ਼ਨ](https://pages.nist.gov/800-63-3/sp800-63b.html) ਦੇ [§ 5.1.7.2](https://pages.nist.gov/800-63-3/sp800-63b.html#sfcdv) ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.7.1** | Verify that the certificates used to verify cryptographic authentication assertions are stored in a way protects them from modification. | 3 | +| **6.7.2** | Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **6.7.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਪ੍ਰਮਾਣੀਕਰਨ ਅਸਰਸ਼ਨਾਂ (assertions) ਦੀ ਤਸਦੀਕ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਸਰਟੀਫ਼ਿਕੇਟ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਨੂੰ ਸੋਧ ਤੋਂ ਸੁਰੱਖਿਅਤ ਰੱਖਦਾ ਹੈ। | 3 | +| **6.7.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਚੁਣੌਤੀ ਨੌਂਸ ਘੱਟੋ-ਘੱਟ 64 ਬਿੱਟ ਲੰਬਾ ਹੈ, ਅਤੇ ਅੰਕੜਾ-ਵਿਗਿਆਨਕ ਤੌਰ 'ਤੇ ਵਿਲੱਖਣ ਹੈ ਜਾਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਡਿਵਾਈਸ ਦੇ ਪੂਰੇ ਜੀਵਨਕਾਲ ਦੌਰਾਨ ਵਿਲੱਖਣ ਹੈ। | 3 | + +## V6.8 Authentication with an Identity Provider +## V6.8 ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਨਾਲ ਪ੍ਰਮਾਣੀਕਰਨ + +Identity Providers (IdPs) provide federated identity for users. Users will often have more than one identity with multiple IdPs, such as an enterprise identity using Azure AD, Okta, Ping Identity, or Google, or consumer identity using Facebook, Twitter, Google, or WeChat, to name just a few common alternatives. This list is not an endorsement of these companies or services, but simply an encouragement for developers to consider the reality that many users have many established identities. Organizations should consider integrating with existing user identities, as per the risk profile of the IdP's strength of identity proofing. For example, it is unlikely a government organization would accept a social media identity as a login for sensitive systems, as it is easy to create fake or throwaway identities, whereas a mobile game company may well need to integrate with major social media platforms to grow their active player base. + +ਪਛਾਣ ਪ੍ਰਦਾਤਾ (Identity Providers, IdP) ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਸੰਘੀ ਪਛਾਣ (federated identity) ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਉਪਭੋਗਤਾਵਾਂ ਕੋਲ ਅਕਸਰ ਕਈ IdP ਨਾਲ ਇੱਕ ਤੋਂ ਵੱਧ ਪਛਾਣਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ Azure AD, Okta, Ping Identity, ਜਾਂ Google ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਇੱਕ ਸੰਸਥਾਗਤ (enterprise) ਪਛਾਣ, ਜਾਂ Facebook, Twitter, Google, ਜਾਂ WeChat ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਇੱਕ ਖਪਤਕਾਰ ਪਛਾਣ — ਕੁਝ ਕੁ ਆਮ ਬਦਲਾਂ ਦਾ ਨਾਂ ਲੈਣ ਲਈ। ਇਹ ਸੂਚੀ ਇਹਨਾਂ ਕੰਪਨੀਆਂ ਜਾਂ ਸੇਵਾਵਾਂ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਇਸ ਹਕੀਕਤ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਦਾ ਸਿਰਫ਼ ਇੱਕ ਉਤਸ਼ਾਹ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਕੋਲ ਬਹੁਤ ਸਾਰੀਆਂ ਸਥਾਪਿਤ ਪਛਾਣਾਂ ਹਨ। ਸੰਸਥਾਵਾਂ ਨੂੰ IdP ਦੀ ਪਛਾਣ ਸਬੂਤੀਕਰਨ ਦੀ ਤਾਕਤ ਦੇ ਜੋਖਮ ਪ੍ਰੋਫ਼ਾਈਲ ਦੇ ਅਨੁਸਾਰ, ਮੌਜੂਦਾ ਉਪਭੋਗਤਾ ਪਛਾਣਾਂ ਨਾਲ ਏਕੀਕਰਨ ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇਸ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੈ ਕਿ ਕੋਈ ਸਰਕਾਰੀ ਸੰਸਥਾ ਸੰਵੇਦਨਸ਼ੀਲ ਸਿਸਟਮਾਂ ਲਈ ਲੌਗਇਨ ਵਜੋਂ ਸੋਸ਼ਲ ਮੀਡੀਆ ਪਛਾਣ ਨੂੰ ਸਵੀਕਾਰ ਕਰੇਗੀ, ਕਿਉਂਕਿ ਜਾਅਲੀ ਜਾਂ ਅਸਥਾਈ (throwaway) ਪਛਾਣਾਂ ਬਣਾਉਣਾ ਆਸਾਨ ਹੈ, ਜਦੋਂ ਕਿ ਕਿਸੇ ਮੋਬਾਈਲ ਗੇਮ ਕੰਪਨੀ ਨੂੰ ਆਪਣੇ ਸਰਗਰਮ ਖਿਡਾਰੀ ਆਧਾਰ ਨੂੰ ਵਧਾਉਣ ਲਈ ਮੁੱਖ ਸੋਸ਼ਲ ਮੀਡੀਆ ਪਲੇਟਫ਼ਾਰਮਾਂ ਨਾਲ ਏਕੀਕਰਨ ਦੀ ਸੱਚਮੁੱਚ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। + +Secure use of external identity providers requires careful configuration and verification to prevent identity spoofing or forged assertions. This section provides requirements to address these risks. + +ਬਾਹਰੀ ਪਛਾਣ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਸੁਰੱਖਿਅਤ ਵਰਤੋਂ ਲਈ ਪਛਾਣ ਸਪੂਫ਼ਿੰਗ (identity spoofing) ਜਾਂ ਜਾਅਲੀ ਅਸਰਸ਼ਨਾਂ ਨੂੰ ਰੋਕਣ ਵਾਸਤੇ ਸਾਵਧਾਨ ਸੰਰਚਨਾ ਅਤੇ ਤਸਦੀਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਭਾਗ ਇਹਨਾਂ ਜੋਖਮਾਂ ਨਾਲ ਨਜਿੱਠਣ ਲਈ ਲੋੜਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **6.8.1** | Verify that, if the application supports multiple identity providers (IdPs), the user's identity cannot be spoofed via another supported identity provider (eg. by using the same user identifier). The standard mitigation would be for the application to register and identify the user using a combination of the IdP ID (serving as a namespace) and the user's ID in the IdP. | 2 | +| **6.8.2** | Verify that the presence and integrity of digital signatures on authentication assertions (for example on JWTs or SAML assertions) are always validated, rejecting any assertions that are unsigned or have invalid signatures. | 2 | +| **6.8.3** | Verify that SAML assertions are uniquely processed and used only once within the validity period to prevent replay attacks. | 2 | +| **6.8.4** | Verify that, if an application uses a separate Identity Provider (IdP) and expects specific authentication strength, methods, or recentness for specific functions, the application verifies this using the information returned by the IdP. For example, if OIDC is used, this might be achieved by validating ID Token claims such as 'acr', 'amr', and 'auth_time' (if present). If the IdP does not provide this information, the application must have a documented fallback approach that assumes that the minimum strength authentication mechanism was used (for example, single-factor authentication using username and password). | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **6.8.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਕਈ ਪਛਾਣ ਪ੍ਰਦਾਤਾਵਾਂ (IdP) ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਪਭੋਗਤਾ ਦੀ ਪਛਾਣ ਕਿਸੇ ਹੋਰ ਸਮਰਥਿਤ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਰਾਹੀਂ ਸਪੂਫ਼ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ (ਜਿਵੇਂ ਕਿ ਉਹੀ ਉਪਭੋਗਤਾ ਪਛਾਣਕਰਤਾ ਵਰਤ ਕੇ)। ਮਿਆਰੀ ਘਟਾਉ ਇਹ ਹੋਵੇਗਾ ਕਿ ਐਪਲੀਕੇਸ਼ਨ IdP ID (ਜੋ ਨੇਮਸਪੇਸ ਵਜੋਂ ਕੰਮ ਕਰਦੀ ਹੈ) ਅਤੇ IdP ਵਿੱਚ ਉਪਭੋਗਤਾ ਦੀ ID ਦੇ ਸੁਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਪਭੋਗਤਾ ਨੂੰ ਰਜਿਸਟਰ ਅਤੇ ਪਛਾਣ ਕਰੇ। | 2 | +| **6.8.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਅਸਰਸ਼ਨਾਂ (ਉਦਾਹਰਨ ਲਈ JWT ਜਾਂ SAML ਅਸਰਸ਼ਨਾਂ) 'ਤੇ ਡਿਜ਼ੀਟਲ ਦਸਤਖ਼ਤਾਂ ਦੀ ਮੌਜੂਦਗੀ ਅਤੇ ਅਖੰਡਤਾ (integrity) ਨੂੰ ਹਮੇਸ਼ਾ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਅਜਿਹੀ ਅਸਰਸ਼ਨ ਨੂੰ ਰੱਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਦਸਤਖ਼ਤ-ਰਹਿਤ ਹੈ ਜਾਂ ਜਿਸ ਦੇ ਦਸਤਖ਼ਤ ਜਾਇਜ਼ ਨਹੀਂ ਹਨ। | 2 | +| **6.8.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਰੀਪਲੇ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ SAML ਅਸਰਸ਼ਨਾਂ ਨੂੰ ਵਿਲੱਖਣ ਤੌਰ 'ਤੇ ਪ੍ਰੋਸੈੱਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਜਾਇਜ਼ਤਾ ਮਿਆਦ (validity period) ਦੇ ਅੰਦਰ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਹੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। | 2 | +| **6.8.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ ਕੋਈ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਵੱਖਰੇ ਪਛਾਣ ਪ੍ਰਦਾਤਾ (IdP) ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਅਤੇ ਖ਼ਾਸ ਫੰਕਸ਼ਨਾਂ ਲਈ ਖ਼ਾਸ ਪ੍ਰਮਾਣੀਕਰਨ ਤਾਕਤ, ਵਿਧੀਆਂ, ਜਾਂ ਤਾਜ਼ਗੀ (recentness) ਦੀ ਉਮੀਦ ਰੱਖਦੀ ਹੈ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ IdP ਦੁਆਰਾ ਵਾਪਸ ਭੇਜੀ ਗਈ ਜਾਣਕਾਰੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਦੀ ਤਸਦੀਕ ਕਰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇ OIDC ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ID Token ਦੇ ਦਾਅਵਿਆਂ (claims) ਜਿਵੇਂ ਕਿ 'acr', 'amr', ਅਤੇ 'auth_time' (ਜੇ ਮੌਜੂਦ ਹੋਣ) ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਕੇ ਹਾਸਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ IdP ਇਹ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਕੋਲ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਫ਼ਾਲਬੈਕ (fallback) ਪਹੁੰਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਇਹ ਮੰਨਦੀ ਹੈ ਕਿ ਘੱਟੋ-ਘੱਟ ਤਾਕਤ ਵਾਲੀ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਣਾਲੀ ਵਰਤੀ ਗਈ ਸੀ (ਉਦਾਹਰਨ ਲਈ, ਉਪਭੋਗਤਾ ਨਾਂ ਅਤੇ ਪਾਸਵਰਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ)। | 2 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [NIST SP 800-63 - Digital Identity Guidelines](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf) +* [NIST SP 800-63B - Authentication and Lifecycle Management](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf) +* [NIST SP 800-63 FAQ](https://pages.nist.gov/800-63-FAQ/) +* [OWASP Web Security Testing Guide: Testing for Authentication](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing) +* [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) +* [OWASP Forgot Password Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) +* [OWASP Choosing and Using Security Questions Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html) +* [CISA Guidance on "Number Matching"](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf) +* [Details on the FIDO Alliance](https://fidoalliance.org/) diff --git a/5.0/pa-IN/0x16-V7-Session-Management.md b/5.0/pa-IN/0x16-V7-Session-Management.md new file mode 100644 index 0000000000..8737c31300 --- /dev/null +++ b/5.0/pa-IN/0x16-V7-Session-Management.md @@ -0,0 +1,175 @@ + + + + +# V7 Session Management +# V7 ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +Session management mechanisms allow applications to correlate user and device interactions over time, even when using stateless communication protocols (such as HTTP). Modern applications may use multiple session tokens with distinct characteristics and purposes. A secure session management system is one that prevents attackers from obtaining, utilizing, or otherwise abusing a victim's session. Applications maintaining sessions must ensure that the following high-level session management requirements are met: + +ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸਮੇਂ ਦੇ ਨਾਲ ਉਪਭੋਗਤਾ ਅਤੇ ਡਿਵਾਈਸ ਦੀਆਂ ਅੰਤਰਕਿਰਿਆਵਾਂ ਨੂੰ ਆਪਸ ਵਿੱਚ ਜੋੜਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ, ਉਦੋਂ ਵੀ ਜਦੋਂ ਸਟੇਟਲੈੱਸ (stateless) ਸੰਚਾਰ ਪ੍ਰੋਟੋਕਾਲ (ਜਿਵੇਂ ਕਿ HTTP) ਵਰਤੇ ਜਾ ਰਹੇ ਹੋਣ। ਆਧੁਨਿਕ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵੱਖਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਉਦੇਸ਼ਾਂ ਵਾਲੇ ਕਈ ਸੈਸ਼ਨ ਟੋਕਨ ਵਰਤ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ ਸੁਰੱਖਿਅਤ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ ਉਹ ਹੈ ਜੋ ਹਮਲਾਵਰਾਂ ਨੂੰ ਪੀੜਤ ਦੇ ਸੈਸ਼ਨ ਨੂੰ ਹਾਸਲ ਕਰਨ, ਵਰਤਣ, ਜਾਂ ਕਿਸੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਇਸ ਦੀ ਦੁਰਵਰਤੋਂ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਸੈਸ਼ਨ ਕਾਇਮ ਰੱਖਣ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਹੇਠ ਲਿਖੀਆਂ ਉੱਚ-ਪੱਧਰੀ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਲੋੜਾਂ ਪੂਰੀਆਂ ਹੋਣ: + +* Sessions are unique to each individual and cannot be guessed or shared. +* Sessions are invalidated when no longer required and are timed out during periods of inactivity. + +* ਸੈਸ਼ਨ ਹਰੇਕ ਵਿਅਕਤੀ ਲਈ ਵਿਲੱਖਣ ਹੁੰਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦਾ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਸਾਂਝਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। +* ਜਦੋਂ ਸੈਸ਼ਨਾਂ ਦੀ ਹੋਰ ਲੋੜ ਨਾ ਰਹੇ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਅਵੈਧ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਗ਼ੈਰ-ਸਰਗਰਮੀ (inactivity) ਦੇ ਸਮੇਂ ਦੌਰਾਨ ਉਹਨਾਂ ਦੀ ਸਮਾਂ-ਸੀਮਾ ਪੁੱਗ ਜਾਂਦੀ ਹੈ। + +Many of the requirements in this chapter relate to selected [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-4/) controls, focusing on common threats and commonly exploited authentication weaknesses. + +ਇਸ ਅਧਿਆਇ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਲੋੜਾਂ ਚੁਣੇ ਹੋਏ [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-4/) ਨਿਯੰਤਰਣਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ, ਜੋ ਆਮ ਖ਼ਤਰਿਆਂ ਅਤੇ ਉਹਨਾਂ ਪ੍ਰਮਾਣੀਕਰਨ ਕਮਜ਼ੋਰੀਆਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ੋਸ਼ਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। + +Note that requirements for specific implementation details of certain session management mechanisms can be found elsewhere: + +ਧਿਆਨ ਦਿਓ ਕਿ ਕੁਝ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਖ਼ਾਸ ਲਾਗੂਕਰਨ ਵੇਰਵਿਆਂ ਲਈ ਲੋੜਾਂ ਹੋਰ ਥਾਂ ਮਿਲ ਸਕਦੀਆਂ ਹਨ: + +* HTTP Cookies are a common mechanism for securing session tokens. Specific security requirements for cookies can be found in the "Web Frontend Security" chapter. +* Self-contained tokens are frequently used as a way of maintaining sessions. Specific security requirements can be found in the "Self-contained Tokens" chapter. + +* HTTP ਕੁਕੀਆਂ ਸੈਸ਼ਨ ਟੋਕਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਇੱਕ ਆਮ ਪ੍ਰਣਾਲੀ ਹਨ। ਕੁਕੀਆਂ ਲਈ ਖ਼ਾਸ ਸੁਰੱਖਿਆ ਲੋੜਾਂ "ਵੈੱਬ ਫਰੰਟਐਂਡ ਸੁਰੱਖਿਆ" (Web Frontend Security) ਅਧਿਆਇ ਵਿੱਚ ਮਿਲ ਸਕਦੀਆਂ ਹਨ। +* ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨ (self-contained tokens) ਅਕਸਰ ਸੈਸ਼ਨ ਕਾਇਮ ਰੱਖਣ ਦੇ ਇੱਕ ਤਰੀਕੇ ਵਜੋਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਖ਼ਾਸ ਸੁਰੱਖਿਆ ਲੋੜਾਂ "ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨ" (Self-contained Tokens) ਅਧਿਆਇ ਵਿੱਚ ਮਿਲ ਸਕਦੀਆਂ ਹਨ। + +## V7.1 Session Management Documentation +## V7.1 ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ + +There is no single pattern that suits all applications. Therefore, it is not feasible to define universal boundaries and limits that suit all cases. A risk analysis with documented security decisions related to session handling must be conducted as a prerequisite to implementation and testing. This ensures that the session management system is tailored to the specific requirements of the application. + +ਕੋਈ ਇੱਕ ਅਜਿਹਾ ਪੈਟਰਨ ਨਹੀਂ ਹੈ ਜੋ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਢੁਕਵਾਂ ਹੋਵੇ। ਇਸ ਲਈ, ਅਜਿਹੀਆਂ ਸਰਵ-ਵਿਆਪਕ ਹੱਦਾਂ ਅਤੇ ਸੀਮਾਵਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਹੈ ਜੋ ਸਾਰੇ ਮਾਮਲਿਆਂ ਲਈ ਢੁਕਵੀਆਂ ਹੋਣ। ਲਾਗੂਕਰਨ ਅਤੇ ਟੈਸਟਿੰਗ ਦੀ ਪੂਰਵ-ਸ਼ਰਤ ਵਜੋਂ, ਸੈਸ਼ਨ ਸੰਭਾਲ ਨਾਲ ਸੰਬੰਧਿਤ ਦਸਤਾਵੇਜ਼ੀ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਿਆਂ ਸਮੇਤ ਇੱਕ ਜੋਖਮ ਵਿਸ਼ਲੇਸ਼ਣ (risk analysis) ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਖ਼ਾਸ ਲੋੜਾਂ ਦੇ ਅਨੁਸਾਰ ਢਾਲਿਆ ਗਿਆ ਹੈ। + +Regardless of whether a stateful or "stateless" session mechanism is chosen, the analysis must be complete and documented to demonstrate that the selected solution is capable of satisfying all relevant security requirements. Interaction with any Single Sign-on (SSO) mechanisms in use should also be considered. + +ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਕਿ ਸਟੇਟਫੁੱਲ (stateful) ਜਾਂ "ਸਟੇਟਲੈੱਸ" ਸੈਸ਼ਨ ਪ੍ਰਣਾਲੀ ਚੁਣੀ ਗਈ ਹੈ, ਵਿਸ਼ਲੇਸ਼ਣ ਦਾ ਪੂਰਾ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ ਤਾਂ ਜੋ ਇਹ ਦਰਸਾਇਆ ਜਾ ਸਕੇ ਕਿ ਚੁਣਿਆ ਹੋਇਆ ਹੱਲ ਸਾਰੀਆਂ ਸੰਬੰਧਿਤ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੇ ਸਮਰੱਥ ਹੈ। ਵਰਤੋਂ ਵਿੱਚ ਆ ਰਹੀਆਂ ਕਿਸੇ ਵੀ ਸਿੰਗਲ ਸਾਈਨ-ਆਨ (Single Sign-on, SSO) ਪ੍ਰਣਾਲੀਆਂ ਨਾਲ ਅੰਤਰਕਿਰਿਆ 'ਤੇ ਵੀ ਵਿਚਾਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **7.1.1** | Verify that the user's session inactivity timeout and absolute maximum session lifetime are documented, are appropriate in combination with other controls, and that the documentation includes justification for any deviations from NIST SP 800-63B re-authentication requirements. | 2 | +| **7.1.2** | Verify that the documentation defines how many concurrent (parallel) sessions are allowed for one account as well as the intended behaviors and actions to be taken when the maximum number of active sessions is reached. | 2 | +| **7.1.3** | Verify that all systems that create and manage user sessions as part of a federated identity management ecosystem (such as SSO systems) are documented along with controls to coordinate session lifetimes, termination, and any other conditions that require re-authentication. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **7.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ ਦੀ ਸੈਸ਼ਨ ਗ਼ੈਰ-ਸਰਗਰਮੀ ਸਮਾਂ-ਸੀਮਾ (inactivity timeout) ਅਤੇ ਪੂਰਨ ਵੱਧ ਤੋਂ ਵੱਧ ਸੈਸ਼ਨ ਜੀਵਨਕਾਲ (absolute maximum session lifetime) ਦਸਤਾਵੇਜ਼ੀ ਹਨ, ਹੋਰ ਨਿਯੰਤਰਣਾਂ ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਢੁਕਵੇਂ ਹਨ, ਅਤੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਵਿੱਚ NIST SP 800-63B ਮੁੜ-ਪ੍ਰਮਾਣੀਕਰਨ (re-authentication) ਲੋੜਾਂ ਤੋਂ ਕਿਸੇ ਵੀ ਵਿਚਲਨ ਲਈ ਤਰਕਸੰਗਤ ਕਾਰਨ ਸ਼ਾਮਲ ਹੈ। | 2 | +| **7.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਖਾਤੇ ਲਈ ਕਿੰਨੇ ਸਮਕਾਲੀ (ਸਮਾਨਾਂਤਰ) ਸੈਸ਼ਨਾਂ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ ਜਦੋਂ ਸਰਗਰਮ ਸੈਸ਼ਨਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਗਿਣਤੀ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੀ ਹੈ ਤਾਂ ਇਰਾਦਾ ਕੀਤੇ ਵਿਹਾਰ ਅਤੇ ਚੁੱਕੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਕੀ ਹਨ। | 2 | +| **7.1.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਹ ਸਾਰੇ ਸਿਸਟਮ ਜੋ ਸੰਘੀ (federated) ਪਛਾਣ ਪ੍ਰਬੰਧਨ ਈਕੋਸਿਸਟਮ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਉਪਭੋਗਤਾ ਸੈਸ਼ਨ ਬਣਾਉਂਦੇ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਦੇ ਹਨ (ਜਿਵੇਂ ਕਿ SSO ਸਿਸਟਮ), ਸੈਸ਼ਨ ਜੀਵਨਕਾਲਾਂ, ਸਮਾਪਤੀ, ਅਤੇ ਮੁੜ-ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਲੋੜ ਵਾਲੀਆਂ ਕਿਸੇ ਵੀ ਹੋਰ ਸ਼ਰਤਾਂ ਦਾ ਤਾਲਮੇਲ ਕਰਨ ਵਾਲੇ ਨਿਯੰਤਰਣਾਂ ਸਮੇਤ ਦਸਤਾਵੇਜ਼ੀ ਹਨ। | 2 | + +## V7.2 Fundamental Session Management Security +## V7.2 ਬੁਨਿਆਦੀ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਸੁਰੱਖਿਆ + +This section satisfies the essential requirements of secure sessions by verifying that session tokens are securely generated and validated. + +ਇਹ ਭਾਗ ਇਹ ਤਸਦੀਕ ਕਰਕੇ ਸੁਰੱਖਿਅਤ ਸੈਸ਼ਨਾਂ ਦੀਆਂ ਜ਼ਰੂਰੀ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ ਕਿ ਸੈਸ਼ਨ ਟੋਕਨ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਤਿਆਰ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **7.2.1** | Verify that the application performs all session token verification using a trusted, backend service. | 1 | +| **7.2.2** | Verify that the application uses either self-contained or reference tokens that are dynamically generated for session management, i.e. not using static API secrets and keys. | 1 | +| **7.2.3** | Verify that if reference tokens are used to represent user sessions, they are unique and generated using a cryptographically secure pseudo-random number generator (CSPRNG) and possess at least 128 bits of entropy. | 1 | +| **7.2.4** | Verify that the application generates a new session token on user authentication, including re-authentication, and terminates the current session token. | 1 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **7.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸਾਰੀ ਸੈਸ਼ਨ ਟੋਕਨ ਤਸਦੀਕ ਇੱਕ ਭਰੋਸੇਯੋਗ, ਬੈਕਐਂਡ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਰਦੀ ਹੈ। | 1 | +| **7.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਲਈ ਜਾਂ ਤਾਂ ਸਵੈ-ਨਿਰਭਰ ਜਾਂ ਹਵਾਲਾ ਟੋਕਨ (reference tokens) ਵਰਤਦੀ ਹੈ ਜੋ ਗਤੀਸ਼ੀਲ ਰੂਪ ਵਿੱਚ ਤਿਆਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਭਾਵ ਸਥਿਰ API ਸੀਕ੍ਰੇਟਾਂ ਅਤੇ ਕੁੰਜੀਆਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੀ। | 1 | +| **7.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜੇਕਰ ਉਪਭੋਗਤਾ ਸੈਸ਼ਨਾਂ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਹਵਾਲਾ ਟੋਕਨ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਉਹ ਵਿਲੱਖਣ ਹਨ ਅਤੇ ਇੱਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਸੂਡੋ-ਰੈਂਡਮ ਨੰਬਰ ਜਨਰੇਟਰ (CSPRNG) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ 128 ਬਿੱਟ ਐਂਟਰੋਪੀ (entropy) ਹੈ। | 1 | +| **7.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਉਪਭੋਗਤਾ ਪ੍ਰਮਾਣੀਕਰਨ 'ਤੇ, ਮੁੜ-ਪ੍ਰਮਾਣੀਕਰਨ ਸਮੇਤ, ਇੱਕ ਨਵਾਂ ਸੈਸ਼ਨ ਟੋਕਨ ਤਿਆਰ ਕਰਦੀ ਹੈ ਅਤੇ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਟੋਕਨ ਨੂੰ ਸਮਾਪਤ ਕਰਦੀ ਹੈ। | 1 | + +## V7.3 Session Timeout +## V7.3 ਸੈਸ਼ਨ ਸਮਾਂ-ਸੀਮਾ + +Session timeout mechanisms serve to minimize the window of opportunity for session hijacking and other forms of session abuse. Timeouts must satisfy documented security decisions. + +ਸੈਸ਼ਨ ਸਮਾਂ-ਸੀਮਾ ਪ੍ਰਣਾਲੀਆਂ ਸੈਸ਼ਨ ਹਾਈਜੈਕਿੰਗ (session hijacking) ਅਤੇ ਸੈਸ਼ਨ ਦੁਰਵਰਤੋਂ ਦੇ ਹੋਰ ਰੂਪਾਂ ਲਈ ਮੌਕੇ ਦੀ ਮਿਆਦ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰਨ ਦਾ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਸਮਾਂ-ਸੀਮਾਵਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ੀ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਪੂਰਾ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **7.3.1** | Verify that there is an inactivity timeout such that re-authentication is enforced according to risk analysis and documented security decisions. | 2 | +| **7.3.2** | Verify that there is an absolute maximum session lifetime such that re-authentication is enforced according to risk analysis and documented security decisions. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **7.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਇੱਕ ਗ਼ੈਰ-ਸਰਗਰਮੀ ਸਮਾਂ-ਸੀਮਾ ਮੌਜੂਦ ਹੈ ਜਿਸ ਨਾਲ ਜੋਖਮ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਿਆਂ ਦੇ ਅਨੁਸਾਰ ਮੁੜ-ਪ੍ਰਮਾਣੀਕਰਨ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। | 2 | +| **7.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਇੱਕ ਪੂਰਨ ਵੱਧ ਤੋਂ ਵੱਧ ਸੈਸ਼ਨ ਜੀਵਨਕਾਲ ਮੌਜੂਦ ਹੈ ਜਿਸ ਨਾਲ ਜੋਖਮ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਿਆਂ ਦੇ ਅਨੁਸਾਰ ਮੁੜ-ਪ੍ਰਮਾਣੀਕਰਨ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। | 2 | + +## V7.4 Session Termination +## V7.4 ਸੈਸ਼ਨ ਸਮਾਪਤੀ + +Session termination may be handled either by the application itself or by the SSO provider if the SSO provider is handling session management instead of the application. It may be necessary to decide whether the SSO provider is in scope when considering the requirements in this section as some may be controlled by the provider. + +ਸੈਸ਼ਨ ਸਮਾਪਤੀ ਜਾਂ ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਖ਼ੁਦ ਸੰਭਾਲੀ ਜਾ ਸਕਦੀ ਹੈ ਜਾਂ SSO ਪ੍ਰਦਾਤਾ ਦੁਆਰਾ, ਜੇਕਰ SSO ਪ੍ਰਦਾਤਾ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਬਜਾਏ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਸੰਭਾਲ ਰਿਹਾ ਹੈ। ਇਸ ਭਾਗ ਦੀਆਂ ਲੋੜਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਸਮੇਂ ਇਹ ਫ਼ੈਸਲਾ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੋ ਸਕਦਾ ਹੈ ਕਿ SSO ਪ੍ਰਦਾਤਾ ਘੇਰੇ ਵਿੱਚ ਹੈ ਜਾਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਕੁਝ ਲੋੜਾਂ ਪ੍ਰਦਾਤਾ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਹੋ ਸਕਦੀਆਂ ਹਨ। + +Session termination should result in requiring re-authentication and be effective across the application, federated login (if present), and any relying parties. + +ਸੈਸ਼ਨ ਸਮਾਪਤੀ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਮੁੜ-ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਲੋੜ ਪੈਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਇਹ ਐਪਲੀਕੇਸ਼ਨ, ਸੰਘੀ ਲੌਗਇਨ (ਜੇ ਮੌਜੂਦ ਹੋਵੇ), ਅਤੇ ਕਿਸੇ ਵੀ ਨਿਰਭਰ ਧਿਰਾਂ (relying parties) ਵਿੱਚ ਪ੍ਰਭਾਵੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। + +For stateful session mechanisms, termination typically involves invalidating the session on the backend. In the case of self-contained tokens, additional measures are required to revoke or block these tokens, as they may otherwise remain valid until expiration. + +ਸਟੇਟਫੁੱਲ ਸੈਸ਼ਨ ਪ੍ਰਣਾਲੀਆਂ ਲਈ, ਸਮਾਪਤੀ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਬੈਕਐਂਡ 'ਤੇ ਸੈਸ਼ਨ ਨੂੰ ਅਵੈਧ ਕਰਨਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਹਨਾਂ ਟੋਕਨਾਂ ਨੂੰ ਰੱਦ ਕਰਨ ਜਾਂ ਰੋਕਣ ਲਈ ਵਾਧੂ ਉਪਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਨਹੀਂ ਤਾਂ ਉਹ ਮਿਆਦ ਪੁੱਗਣ ਤੱਕ ਜਾਇਜ਼ ਰਹਿ ਸਕਦੇ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **7.4.1** | Verify that when session termination is triggered (such as logout or expiration), the application disallows any further use of the session. For reference tokens or stateful sessions, this means invalidating the session data at the application backend. Applications using self-contained tokens will need a solution such as maintaining a list of terminated tokens, disallowing tokens produced before a per-user date and time or rotating a per-user signing key. | 1 | +| **7.4.2** | Verify that the application terminates all active sessions when a user account is disabled or deleted (such as an employee leaving the company). | 1 | +| **7.4.3** | Verify that the application gives the option to terminate all other active sessions after a successful change or removal of any authentication factor (including password change via reset or recovery and, if present, an MFA settings update). | 2 | +| **7.4.4** | Verify that all pages that require authentication have easy and visible access to logout functionality. | 2 | +| **7.4.5** | Verify that application administrators are able to terminate active sessions for an individual user or for all users. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **7.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਦੋਂ ਸੈਸ਼ਨ ਸਮਾਪਤੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ (ਜਿਵੇਂ ਕਿ ਲੌਗਆਊਟ ਜਾਂ ਮਿਆਦ ਪੁੱਗਣਾ), ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਸੈਸ਼ਨ ਦੀ ਕਿਸੇ ਵੀ ਹੋਰ ਵਰਤੋਂ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੀ। ਹਵਾਲਾ ਟੋਕਨਾਂ ਜਾਂ ਸਟੇਟਫੁੱਲ ਸੈਸ਼ਨਾਂ ਲਈ, ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਐਪਲੀਕੇਸ਼ਨ ਬੈਕਐਂਡ 'ਤੇ ਸੈਸ਼ਨ ਡਾਟਾ ਨੂੰ ਅਵੈਧ ਕਰਨਾ। ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨ ਵਰਤਣ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਇੱਕ ਅਜਿਹੇ ਹੱਲ ਦੀ ਲੋੜ ਪਵੇਗੀ ਜਿਵੇਂ ਕਿ ਸਮਾਪਤ ਕੀਤੇ ਟੋਕਨਾਂ ਦੀ ਸੂਚੀ ਕਾਇਮ ਰੱਖਣਾ, ਪ੍ਰਤੀ-ਉਪਭੋਗਤਾ ਮਿਤੀ ਅਤੇ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਤਿਆਰ ਕੀਤੇ ਟੋਕਨਾਂ ਦੀ ਇਜਾਜ਼ਤ ਨਾ ਦੇਣਾ, ਜਾਂ ਪ੍ਰਤੀ-ਉਪਭੋਗਤਾ ਦਸਤਖ਼ਤ ਕੁੰਜੀ (signing key) ਨੂੰ ਰੋਟੇਟ ਕਰਨਾ। | 1 | +| **7.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਦੋਂ ਕੋਈ ਉਪਭੋਗਤਾ ਖਾਤਾ ਅਸਮਰੱਥ ਜਾਂ ਮਿਟਾਇਆ ਜਾਂਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ ਕਿਸੇ ਕਰਮਚਾਰੀ ਦਾ ਕੰਪਨੀ ਛੱਡਣਾ), ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਸਾਰੇ ਸਰਗਰਮ ਸੈਸ਼ਨਾਂ ਨੂੰ ਸਮਾਪਤ ਕਰਦੀ ਹੈ। | 1 | +| **7.4.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕਿਸੇ ਵੀ ਪ੍ਰਮਾਣੀਕਰਨ ਕਾਰਕ ਦੀ ਸਫਲ ਤਬਦੀਲੀ ਜਾਂ ਹਟਾਉਣ ਤੋਂ ਬਾਅਦ (ਰੀਸੈੱਟ ਜਾਂ ਮੁੜ-ਪ੍ਰਾਪਤੀ ਰਾਹੀਂ ਪਾਸਵਰਡ ਤਬਦੀਲੀ ਅਤੇ, ਜੇ ਮੌਜੂਦ ਹੋਵੇ, MFA ਸੈਟਿੰਗਾਂ ਦੇ ਅੱਪਡੇਟ ਸਮੇਤ) ਬਾਕੀ ਸਾਰੇ ਸਰਗਰਮ ਸੈਸ਼ਨਾਂ ਨੂੰ ਸਮਾਪਤ ਕਰਨ ਦਾ ਵਿਕਲਪ ਦਿੰਦੀ ਹੈ। | 2 | +| **7.4.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਲੋੜ ਵਾਲੇ ਸਾਰੇ ਪੰਨਿਆਂ 'ਤੇ ਲੌਗਆਊਟ ਕਾਰਜਸ਼ੀਲਤਾ ਤੱਕ ਆਸਾਨ ਅਤੇ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਪਹੁੰਚ ਹੈ। | 2 | +| **7.4.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਸ਼ਾਸਕ ਕਿਸੇ ਇੱਕ ਉਪਭੋਗਤਾ ਲਈ ਜਾਂ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਸਰਗਰਮ ਸੈਸ਼ਨਾਂ ਨੂੰ ਸਮਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਹਨ। | 2 | + +## V7.5 Defenses Against Session Abuse +## V7.5 ਸੈਸ਼ਨ ਦੁਰਵਰਤੋਂ ਵਿਰੁੱਧ ਬਚਾਅ + +This section provides requirements to mitigate the risk posed by active sessions that are either hijacked or abused through vectors that rely on the existence and capabilities of active user sessions. For example, using malicious content execution to force an authenticated victim browser to perform an action using the victim's session. + +ਇਹ ਭਾਗ ਉਹਨਾਂ ਸਰਗਰਮ ਸੈਸ਼ਨਾਂ ਦੁਆਰਾ ਪੈਦਾ ਕੀਤੇ ਜੋਖਮ ਨੂੰ ਘਟਾਉਣ ਲਈ ਲੋੜਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਜਾਂ ਤਾਂ ਹਾਈਜੈਕ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜਾਂ ਅਜਿਹੇ ਵੈਕਟਰਾਂ ਰਾਹੀਂ ਦੁਰਵਰਤੋਂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜੋ ਸਰਗਰਮ ਉਪਭੋਗਤਾ ਸੈਸ਼ਨਾਂ ਦੀ ਮੌਜੂਦਗੀ ਅਤੇ ਸਮਰੱਥਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਖ਼ਤਰਨਾਕ ਸਮੱਗਰੀ ਦੇ ਅਮਲ (malicious content execution) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਪ੍ਰਮਾਣੀਕਰਨ ਕੀਤੇ ਹੋਏ ਪੀੜਤ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਪੀੜਤ ਦੇ ਸੈਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੋਈ ਕਾਰਵਾਈ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਨਾ। + +Note that the level-specific guidance in the "Authentication" chapter should be taken into account when considering requirements in this section. + +ਧਿਆਨ ਦਿਓ ਕਿ ਇਸ ਭਾਗ ਦੀਆਂ ਲੋੜਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਸਮੇਂ "ਪ੍ਰਮਾਣੀਕਰਨ" (Authentication) ਅਧਿਆਇ ਵਿੱਚ ਦਿੱਤੇ ਪੱਧਰ-ਵਿਸ਼ੇਸ਼ ਮਾਰਗਦਰਸ਼ਨ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **7.5.1** | Verify that the application requires full re-authentication before allowing modifications to sensitive account attributes which may affect authentication such as email address, phone number, MFA configuration, or other information used in account recovery. | 2 | +| **7.5.2** | Verify that users are able to view and (having authenticated again with at least one factor) terminate any or all currently active sessions. | 2 | +| **7.5.3** | Verify that the application requires further authentication with at least one factor or secondary verification before performing highly sensitive transactions or operations. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **7.5.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਉਹਨਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਖਾਤਾ ਗੁਣਾਂ ਵਿੱਚ ਸੋਧਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰੇ ਮੁੜ-ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਮੰਗ ਕਰਦੀ ਹੈ ਜੋ ਪ੍ਰਮਾਣੀਕਰਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਈਮੇਲ ਪਤਾ, ਫ਼ੋਨ ਨੰਬਰ, MFA ਸੰਰਚਨਾ, ਜਾਂ ਖਾਤਾ ਮੁੜ-ਪ੍ਰਾਪਤੀ ਵਿੱਚ ਵਰਤੀ ਜਾਂਦੀ ਹੋਰ ਜਾਣਕਾਰੀ। | 2 | +| **7.5.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ ਮੌਜੂਦਾ ਸਮੇਂ ਸਰਗਰਮ ਕਿਸੇ ਵੀ ਜਾਂ ਸਾਰੇ ਸੈਸ਼ਨਾਂ ਨੂੰ ਵੇਖਣ ਅਤੇ (ਘੱਟੋ-ਘੱਟ ਇੱਕ ਕਾਰਕ ਨਾਲ ਦੁਬਾਰਾ ਪ੍ਰਮਾਣੀਕਰਨ ਕਰਨ ਤੋਂ ਬਾਅਦ) ਸਮਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਹਨ। | 2 | +| **7.5.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਬਹੁਤ ਸੰਵੇਦਨਸ਼ੀਲ ਲੈਣ-ਦੇਣ ਜਾਂ ਕਾਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਕਾਰਕ ਨਾਲ ਹੋਰ ਪ੍ਰਮਾਣੀਕਰਨ ਜਾਂ ਸੈਕੰਡਰੀ ਤਸਦੀਕ ਦੀ ਮੰਗ ਕਰਦੀ ਹੈ। | 3 | + +## V7.6 Federated Re-authentication +## V7.6 ਸੰਘੀ ਮੁੜ-ਪ੍ਰਮਾਣੀਕਰਨ + +This section relates to those writing Relying Party (RP) or Identity Provider (IdP) code. These requirements are derived from the [NIST SP 800-63C](https://pages.nist.gov/800-63-4/sp800-63c.html) for Federation & Assertions. + +ਇਹ ਭਾਗ ਉਹਨਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ ਜੋ ਨਿਰਭਰ ਧਿਰ (Relying Party, RP) ਜਾਂ ਪਛਾਣ ਪ੍ਰਦਾਤਾ (Identity Provider, IdP) ਕੋਡ ਲਿਖਦੇ ਹਨ। ਇਹ ਲੋੜਾਂ Federation & Assertions ਲਈ [NIST SP 800-63C](https://pages.nist.gov/800-63-4/sp800-63c.html) ਤੋਂ ਲਈਆਂ ਗਈਆਂ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **7.6.1** | Verify that session lifetime and termination between Relying Parties (RPs) and Identity Providers (IdPs) behave as documented, requiring re-authentication as necessary such as when the maximum time between IdP authentication events is reached. | 2 | +| **7.6.2** | Verify that creation of a session requires either the user's consent or an explicit action, preventing the creation of new application sessions without user interaction. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **7.6.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਨਿਰਭਰ ਧਿਰਾਂ (RPs) ਅਤੇ ਪਛਾਣ ਪ੍ਰਦਾਤਾਵਾਂ (IdPs) ਦੇ ਵਿਚਕਾਰ ਸੈਸ਼ਨ ਜੀਵਨਕਾਲ ਅਤੇ ਸਮਾਪਤੀ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਦੇ ਅਨੁਸਾਰ ਵਿਹਾਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਲੋੜ ਅਨੁਸਾਰ ਮੁੜ-ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਜਦੋਂ IdP ਪ੍ਰਮਾਣੀਕਰਨ ਘਟਨਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਵੱਧ ਤੋਂ ਵੱਧ ਸਮਾਂ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ। | 2 | +| **7.6.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੈਸ਼ਨ ਬਣਾਉਣ ਲਈ ਜਾਂ ਤਾਂ ਉਪਭੋਗਤਾ ਦੀ ਸਹਿਮਤੀ ਜਾਂ ਇੱਕ ਸਪੱਸ਼ਟ ਕਾਰਵਾਈ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਉਪਭੋਗਤਾ ਦੀ ਅੰਤਰਕਿਰਿਆ ਤੋਂ ਬਿਨਾਂ ਨਵੇਂ ਐਪਲੀਕੇਸ਼ਨ ਸੈਸ਼ਨ ਬਣਾਏ ਜਾਣ ਨੂੰ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ। | 2 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [OWASP Web Security Testing Guide: Session Management Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/06-Session_Management_Testing) +* [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) diff --git a/5.0/pa-IN/0x17-V8-Authorization.md b/5.0/pa-IN/0x17-V8-Authorization.md new file mode 100644 index 0000000000..b5072b8328 --- /dev/null +++ b/5.0/pa-IN/0x17-V8-Authorization.md @@ -0,0 +1,107 @@ + + + + +# V8 Authorization +# V8 ਅਧਿਕਾਰੀਕਰਨ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +Authorization ensures that access is granted only to permitted consumers (users, servers, and other clients). To enforce the Principle of Least Privilege (POLP), verified applications must meet the following high-level requirements: + +ਅਧਿਕਾਰੀਕਰਨ (Authorization) ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਪਹੁੰਚ ਸਿਰਫ਼ ਇਜਾਜ਼ਤ ਪ੍ਰਾਪਤ ਖਪਤਕਾਰਾਂ (ਉਪਭੋਗਤਾਵਾਂ, ਸਰਵਰਾਂ, ਅਤੇ ਹੋਰ ਕਲਾਇੰਟਾਂ) ਨੂੰ ਹੀ ਦਿੱਤੀ ਜਾਵੇ। ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ ਦਾ ਸਿਧਾਂਤ (Principle of Least Privilege, POLP) ਲਾਗੂ ਕਰਨ ਲਈ, ਤਸਦੀਕ ਕੀਤੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਹੇਠ ਲਿਖੀਆਂ ਉੱਚ-ਪੱਧਰੀ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: + +* Document authorization rules, including decision-making factors and environmental contexts. +* Consumers should have access only to resources permitted by their defined entitlements. + +* ਅਧਿਕਾਰੀਕਰਨ ਨਿਯਮਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਦਿਓ, ਜਿਸ ਵਿੱਚ ਫ਼ੈਸਲਾ ਲੈਣ ਵਾਲੇ ਕਾਰਕ ਅਤੇ ਵਾਤਾਵਰਣੀ ਸੰਦਰਭ ਸ਼ਾਮਲ ਹਨ। +* ਖਪਤਕਾਰਾਂ ਕੋਲ ਸਿਰਫ਼ ਉਹਨਾਂ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਉਹਨਾਂ ਦੇ ਪਰਿਭਾਸ਼ਿਤ ਹੱਕਾਂ (entitlements) ਦੁਆਰਾ ਇਜਾਜ਼ਤ ਪ੍ਰਾਪਤ ਹਨ। + +## V8.1 Authorization Documentation +## V8.1 ਅਧਿਕਾਰੀਕਰਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ + +Comprehensive authorization documentation is essential to ensure that security decisions are consistently applied, auditable, and aligned with organizational policies. This reduces the risk of unauthorized access by making security requirements clear and actionable for developers, administrators, and testers. + +ਵਿਆਪਕ ਅਧਿਕਾਰੀਕਰਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲੇ ਨਿਰੰਤਰ ਲਾਗੂ ਹੋਣ, ਆਡਿਟ ਕਰਨ ਯੋਗ ਹੋਣ, ਅਤੇ ਸੰਸਥਾਗਤ ਨੀਤੀਆਂ ਨਾਲ ਮੇਲ ਖਾਣ। ਇਹ ਵਿਕਾਸਕਾਰਾਂ, ਪ੍ਰਸ਼ਾਸਕਾਂ, ਅਤੇ ਟੈਸਟਰਾਂ ਲਈ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਅਤੇ ਕਾਰਜਯੋਗ ਬਣਾ ਕੇ ਅਣਅਧਿਕਾਰਤ ਪਹੁੰਚ ਦੇ ਖ਼ਤਰੇ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **8.1.1** | Verify that authorization documentation defines rules for restricting function-level and data-specific access based on consumer permissions and resource attributes. | 1 | +| **8.1.2** | Verify that authorization documentation defines rules for field-level access restrictions (both read and write) based on consumer permissions and resource attributes. Note that these rules might depend on other attribute values of the relevant data object, such as state or status. | 2 | +| **8.1.3** | Verify that the application's documentation defines the environmental and contextual attributes (including but not limited to, time of day, user location, IP address, or device) that are used in the application to make security decisions, including those pertaining to authentication and authorization. | 3 | +| **8.1.4** | Verify that authentication and authorization documentation defines how environmental and contextual factors are used in decision-making, in addition to function-level, data-specific, and field-level authorization. This should include the attributes evaluated, thresholds for risk, and actions taken (e.g., allow, challenge, deny, step-up authentication). | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **8.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਅਧਿਕਾਰੀਕਰਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਖਪਤਕਾਰ ਇਜਾਜ਼ਤਾਂ ਅਤੇ ਸਰੋਤ ਗੁਣਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਫੰਕਸ਼ਨ-ਪੱਧਰ ਅਤੇ ਡਾਟਾ-ਖ਼ਾਸ ਪਹੁੰਚ ਨੂੰ ਪ੍ਰਤਿਬੰਧਿਤ ਕਰਨ ਲਈ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। | 1 | +| **8.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਅਧਿਕਾਰੀਕਰਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਖਪਤਕਾਰ ਇਜਾਜ਼ਤਾਂ ਅਤੇ ਸਰੋਤ ਗੁਣਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਖੇਤਰ-ਪੱਧਰ ਪਹੁੰਚ ਪ੍ਰਤਿਬੰਧਾਂ (ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਦੋਵਾਂ) ਲਈ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਧਿਆਨ ਦਿਓ ਕਿ ਇਹ ਨਿਯਮ ਸੰਬੰਧਤ ਡਾਟਾ ਆਬਜੈਕਟ ਦੇ ਹੋਰ ਗੁਣ ਮੁੱਲਾਂ, ਜਿਵੇਂ ਕਿ ਸਥਿਤੀ ਜਾਂ ਅਵਸਥਾ, 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦੇ ਹਨ। | 2 | +| **8.1.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਉਹਨਾਂ ਵਾਤਾਵਰਣੀ ਅਤੇ ਸੰਦਰਭੀ ਗੁਣਾਂ (ਦਿਨ ਦਾ ਸਮਾਂ, ਉਪਭੋਗਤਾ ਟਿਕਾਣਾ, IP ਪਤਾ, ਜਾਂ ਡਿਵਾਈਸ ਸਮੇਤ ਪਰ ਇਹਨਾਂ ਤੱਕ ਸੀਮਤ ਨਹੀਂ) ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲੇ ਲੈਣ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਅਧਿਕਾਰੀਕਰਨ ਨਾਲ ਸੰਬੰਧਤ ਫ਼ੈਸਲੇ ਸ਼ਾਮਲ ਹਨ। | 3 | +| **8.1.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਅਧਿਕਾਰੀਕਰਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਫੰਕਸ਼ਨ-ਪੱਧਰ, ਡਾਟਾ-ਖ਼ਾਸ, ਅਤੇ ਖੇਤਰ-ਪੱਧਰ ਅਧਿਕਾਰੀਕਰਨ ਤੋਂ ਇਲਾਵਾ, ਫ਼ੈਸਲਾ ਲੈਣ ਵਿੱਚ ਵਾਤਾਵਰਣੀ ਅਤੇ ਸੰਦਰਭੀ ਕਾਰਕਾਂ ਨੂੰ ਕਿਵੇਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਮੁਲਾਂਕਣ ਕੀਤੇ ਗਏ ਗੁਣ, ਖ਼ਤਰੇ ਦੀਆਂ ਹੱਦਾਂ, ਅਤੇ ਚੁੱਕੀਆਂ ਗਈਆਂ ਕਾਰਵਾਈਆਂ (ਜਿਵੇਂ ਕਿ ਇਜਾਜ਼ਤ, ਚੁਣੌਤੀ, ਇਨਕਾਰ, ਸਟੈਪ-ਅੱਪ ਪ੍ਰਮਾਣੀਕਰਨ) ਸ਼ਾਮਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। | 3 | + +## V8.2 General Authorization Design +## V8.2 ਆਮ ਅਧਿਕਾਰੀਕਰਨ ਡਿਜ਼ਾਈਨ + +Implementing granular authorization controls at the function, data, and field levels ensures that consumers can access only what has been explicitly granted to them. + +ਫੰਕਸ਼ਨ, ਡਾਟਾ, ਅਤੇ ਖੇਤਰ ਪੱਧਰਾਂ 'ਤੇ ਬਾਰੀਕ ਅਧਿਕਾਰੀਕਰਨ ਨਿਯੰਤਰਣ ਲਾਗੂ ਕਰਨਾ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਖਪਤਕਾਰ ਸਿਰਫ਼ ਉਹੀ ਪਹੁੰਚ ਕਰ ਸਕਣ ਜੋ ਉਹਨਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਪ੍ਰਦਾਨ ਕੀਤੀ ਗਈ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **8.2.1** | Verify that the application ensures that function-level access is restricted to consumers with explicit permissions. | 1 | +| **8.2.2** | Verify that the application ensures that data-specific access is restricted to consumers with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA). | 1 | +| **8.2.3** | Verify that the application ensures that field-level access is restricted to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA). | 2 | +| **8.2.4** | Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions, as defined in the application's documentation. These controls must be applied when the consumer tries to start a new session and also during an existing session. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **8.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਫੰਕਸ਼ਨ-ਪੱਧਰ ਪਹੁੰਚ ਸਪੱਸ਼ਟ ਇਜਾਜ਼ਤਾਂ ਵਾਲੇ ਖਪਤਕਾਰਾਂ ਤੱਕ ਪ੍ਰਤਿਬੰਧਿਤ ਹੈ। | 1 | +| **8.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਅਸੁਰੱਖਿਅਤ ਸਿੱਧੇ ਆਬਜੈਕਟ ਹਵਾਲੇ (IDOR) ਅਤੇ ਟੁੱਟੇ ਆਬਜੈਕਟ ਪੱਧਰ ਅਧਿਕਾਰੀਕਰਨ (BOLA) ਨੂੰ ਘਟਾਉਣ ਲਈ ਡਾਟਾ-ਖ਼ਾਸ ਪਹੁੰਚ ਖ਼ਾਸ ਡਾਟਾ ਇਕਾਈਆਂ ਲਈ ਸਪੱਸ਼ਟ ਇਜਾਜ਼ਤਾਂ ਵਾਲੇ ਖਪਤਕਾਰਾਂ ਤੱਕ ਪ੍ਰਤਿਬੰਧਿਤ ਹੈ। | 1 | +| **8.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਟੁੱਟੇ ਆਬਜੈਕਟ ਵਿਸ਼ੇਸ਼ਤਾ ਪੱਧਰ ਅਧਿਕਾਰੀਕਰਨ (BOPLA) ਨੂੰ ਘਟਾਉਣ ਲਈ ਖੇਤਰ-ਪੱਧਰ ਪਹੁੰਚ ਖ਼ਾਸ ਖੇਤਰਾਂ ਲਈ ਸਪੱਸ਼ਟ ਇਜਾਜ਼ਤਾਂ ਵਾਲੇ ਖਪਤਕਾਰਾਂ ਤੱਕ ਪ੍ਰਤਿਬੰਧਿਤ ਹੈ। | 2 | +| **8.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਖਪਤਕਾਰ ਦੇ ਵਾਤਾਵਰਣੀ ਅਤੇ ਸੰਦਰਭੀ ਗੁਣਾਂ (ਜਿਵੇਂ ਕਿ ਦਿਨ ਦਾ ਸਮਾਂ, ਟਿਕਾਣਾ, IP ਪਤਾ, ਜਾਂ ਡਿਵਾਈਸ) 'ਤੇ ਆਧਾਰਿਤ ਅਨੁਕੂਲਿਤ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਅਧਿਕਾਰੀਕਰਨ ਫ਼ੈਸਲਿਆਂ ਲਈ ਲਾਗੂ ਕੀਤੇ ਗਏ ਹਨ, ਜਿਵੇਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਹੈ। ਇਹ ਨਿਯੰਤਰਣ ਉਦੋਂ ਲਾਗੂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜਦੋਂ ਖਪਤਕਾਰ ਨਵਾਂ ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਦੌਰਾਨ ਵੀ। | 3 | + +## V8.3 Operation Level Authorization +## V8.3 ਕਾਰਜ ਪੱਧਰ ਅਧਿਕਾਰੀਕਰਨ + +The immediate application of authorization changes in the appropriate tier of an application's architecture is crucial to preventing unauthorized actions, especially in dynamic environments. + +ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਰਕੀਟੈਕਚਰ ਦੇ ਢੁਕਵੇਂ ਪੱਧਰ ਵਿੱਚ ਅਧਿਕਾਰੀਕਰਨ ਤਬਦੀਲੀਆਂ ਨੂੰ ਤੁਰੰਤ ਲਾਗੂ ਕਰਨਾ ਅਣਅਧਿਕਾਰਤ ਕਾਰਵਾਈਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਖ਼ਾਸ ਕਰਕੇ ਗਤੀਸ਼ੀਲ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **8.3.1** | Verify that the application enforces authorization rules at a trusted service layer and doesn't rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript. | 1 | +| **8.3.2** | Verify that changes to values on which authorization decisions are made are applied immediately. Where changes cannot be applied immediately, (such as when relying on data in self-contained tokens), there must be mitigating controls to alert when a consumer performs an action when they are no longer authorized to do so and revert the change. Note that this alternative would not mitigate information leakage. | 3 | +| **8.3.3** | Verify that access to an object is based on the originating subject's (e.g. consumer's) permissions, not on the permissions of any intermediary or service acting on their behalf. For example, if a consumer calls a web service using a self-contained token for authentication, and the service then requests data from a different service, the second service will use the consumer's token, rather than a machine-to-machine token from the first service, to make permission decisions. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **8.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸੇਵਾ ਪਰਤ 'ਤੇ ਅਧਿਕਾਰੀਕਰਨ ਨਿਯਮ ਲਾਗੂ ਕਰਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨਿਯੰਤਰਣਾਂ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੀ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲਾ ਖਪਤਕਾਰ ਬਦਲ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਕਲਾਇੰਟ-ਸਾਈਡ JavaScript. | 1 | +| **8.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਿਨ੍ਹਾਂ ਮੁੱਲਾਂ 'ਤੇ ਅਧਿਕਾਰੀਕਰਨ ਫ਼ੈਸਲੇ ਲਏ ਜਾਂਦੇ ਹਨ ਉਹਨਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਤੁਰੰਤ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਜਿੱਥੇ ਤਬਦੀਲੀਆਂ ਤੁਰੰਤ ਲਾਗੂ ਨਹੀਂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ, (ਜਿਵੇਂ ਕਿ ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨਾਂ ਵਿੱਚ ਡਾਟੇ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਸਮੇਂ), ਉੱਥੇ ਘਟਾਉ ਨਿਯੰਤਰਣ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਸੁਚੇਤ ਕਰਨ ਕਿ ਜਦੋਂ ਕੋਈ ਖਪਤਕਾਰ ਅਜਿਹੀ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ ਜਿਸ ਲਈ ਉਹ ਹੁਣ ਅਧਿਕਾਰਿਤ ਨਹੀਂ ਹੈ ਅਤੇ ਤਬਦੀਲੀ ਨੂੰ ਉਲਟਾਉਣ। ਧਿਆਨ ਦਿਓ ਕਿ ਇਹ ਬਦਲ ਜਾਣਕਾਰੀ ਲੀਕੇਜ ਨੂੰ ਨਹੀਂ ਘਟਾਏਗਾ। | 3 | +| **8.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਿਸੇ ਆਬਜੈਕਟ ਤੱਕ ਪਹੁੰਚ ਮੂਲ ਵਿਸ਼ੇ (ਜਿਵੇਂ ਕਿ ਖਪਤਕਾਰ) ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੈ, ਨਾ ਕਿ ਉਹਨਾਂ ਦੀ ਤਰਫ਼ੋਂ ਕੰਮ ਕਰਨ ਵਾਲੀ ਕਿਸੇ ਵਿਚੋਲੀ ਜਾਂ ਸੇਵਾ ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ 'ਤੇ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਕੋਈ ਖਪਤਕਾਰ ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ ਇੱਕ ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਸੇ ਵੈੱਬ ਸੇਵਾ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਸੇਵਾ ਫਿਰ ਕਿਸੇ ਵੱਖਰੀ ਸੇਵਾ ਤੋਂ ਡਾਟਾ ਮੰਗਦੀ ਹੈ, ਤਾਂ ਦੂਜੀ ਸੇਵਾ ਇਜਾਜ਼ਤ ਫ਼ੈਸਲੇ ਲੈਣ ਲਈ ਪਹਿਲੀ ਸੇਵਾ ਦੇ ਮਸ਼ੀਨ-ਤੋਂ-ਮਸ਼ੀਨ ਟੋਕਨ ਦੀ ਬਜਾਏ ਖਪਤਕਾਰ ਦਾ ਟੋਕਨ ਵਰਤੇਗੀ। | 3 | + +## V8.4 Other Authorization Considerations +## V8.4 ਹੋਰ ਅਧਿਕਾਰੀਕਰਨ ਵਿਚਾਰ + +Additional considerations for authorization, particularly for administrative interfaces and multi-tenant environments, help prevent unauthorized access. + +ਅਧਿਕਾਰੀਕਰਨ ਲਈ ਵਾਧੂ ਵਿਚਾਰ, ਖ਼ਾਸ ਕਰਕੇ ਪ੍ਰਸ਼ਾਸਕੀ ਇੰਟਰਫ਼ੇਸਾਂ ਅਤੇ ਬਹੁ-ਕਿਰਾਏਦਾਰ (multi-tenant) ਵਾਤਾਵਰਣਾਂ ਲਈ, ਅਣਅਧਿਕਾਰਤ ਪਹੁੰਚ ਨੂੰ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **8.4.1** | Verify that multi-tenant applications use cross-tenant controls to ensure consumer operations will never affect tenants with which they do not have permissions to interact. | 2 | +| **8.4.2** | Verify that access to administrative interfaces incorporates multiple layers of security, including continuous consumer identity verification, device security posture assessment, and contextual risk analysis, ensuring that network location or trusted endpoints are not the sole factors for authorization even though they may reduce the likelihood of unauthorized access. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **8.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਬਹੁ-ਕਿਰਾਏਦਾਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅੰਤਰ-ਕਿਰਾਏਦਾਰ ਨਿਯੰਤਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਖਪਤਕਾਰ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਉਹਨਾਂ ਕਿਰਾਏਦਾਰਾਂ ਨੂੰ ਕਦੇ ਪ੍ਰਭਾਵਿਤ ਨਾ ਕਰਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਉਹਨਾਂ ਨੂੰ ਆਪਸੀ ਤਾਲਮੇਲ ਕਰਨ ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ ਨਹੀਂ ਹਨ। | 2 | +| **8.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪ੍ਰਸ਼ਾਸਕੀ ਇੰਟਰਫ਼ੇਸਾਂ ਤੱਕ ਪਹੁੰਚ ਸੁਰੱਖਿਆ ਦੀਆਂ ਕਈ ਪਰਤਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਨਿਰੰਤਰ ਖਪਤਕਾਰ ਪਛਾਣ ਤਸਦੀਕ, ਡਿਵਾਈਸ ਸੁਰੱਖਿਆ ਸਥਿਤੀ ਮੁਲਾਂਕਣ, ਅਤੇ ਸੰਦਰਭੀ ਜੋਖਮ ਵਿਸ਼ਲੇਸ਼ਣ ਸ਼ਾਮਲ ਹਨ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੀਆਂ ਹੋਈਆਂ ਕਿ ਨੈੱਟਵਰਕ ਟਿਕਾਣਾ ਜਾਂ ਭਰੋਸੇਯੋਗ ਅੰਤ-ਬਿੰਦੂ ਅਧਿਕਾਰੀਕਰਨ ਲਈ ਇਕੋ-ਇਕ ਕਾਰਕ ਨਹੀਂ ਹਨ, ਭਾਵੇਂ ਉਹ ਅਣਅਧਿਕਾਰਤ ਪਹੁੰਚ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਨ। | 3 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [OWASP Web Security Testing Guide: Authorization](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/05-Authorization_Testing) +* [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) diff --git a/5.0/pa-IN/0x18-V9-Self-contained-Tokens.md b/5.0/pa-IN/0x18-V9-Self-contained-Tokens.md new file mode 100644 index 0000000000..b28fd5795f --- /dev/null +++ b/5.0/pa-IN/0x18-V9-Self-contained-Tokens.md @@ -0,0 +1,72 @@ + + + + +# V9 Self-contained Tokens +# V9 ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨ (Self-contained Tokens) + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +The concept of a self-contained token is mentioned in the original RFC 6749 OAuth 2.0 from 2012. It refers to a token containing data or claims on which a receiving service will rely to make security decisions. This should be differentiated from a simple token containing only an identifier, which a receiving service uses to look up data locally. The most common examples of self-contained tokens are JSON Web Tokens (JWTs) and SAML assertions. + +ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨ (Self-contained Token) ਦਾ ਸੰਕਲਪ 2012 ਦੇ ਮੂਲ RFC 6749 OAuth 2.0 ਵਿੱਚ ਜ਼ਿਕਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਹ ਅਜਿਹੇ ਟੋਕਨ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਡਾਟਾ ਜਾਂ ਦਾਅਵੇ (claims) ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਉੱਤੇ ਪ੍ਰਾਪਤਕਰਤਾ ਸੇਵਾ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲੇ ਲੈਣ ਲਈ ਨਿਰਭਰ ਕਰੇਗੀ। ਇਸ ਨੂੰ ਉਸ ਸਾਧਾਰਨ ਟੋਕਨ ਤੋਂ ਵੱਖ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਪਛਾਣਕਰਤਾ (identifier) ਹੁੰਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਪ੍ਰਾਪਤਕਰਤਾ ਸੇਵਾ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਡਾਟਾ ਲੱਭਣ ਲਈ ਵਰਤਦੀ ਹੈ। ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨਾਂ ਦੀਆਂ ਸਭ ਤੋਂ ਆਮ ਉਦਾਹਰਣਾਂ JSON Web Tokens (JWTs) ਅਤੇ SAML assertions ਹਨ। + +The use of self-contained tokens has become very widespread, even outside of OAuth and OIDC. At the same time, the security of this mechanism relies on the ability to validate the integrity of the token and to ensure that the token is valid for a particular context. There are many pitfalls with this process, and this chapter provides specific details of the mechanisms that applications should have in place to prevent them. + +ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨਾਂ ਦੀ ਵਰਤੋਂ ਬਹੁਤ ਵਿਆਪਕ ਹੋ ਗਈ ਹੈ, OAuth ਅਤੇ OIDC ਤੋਂ ਬਾਹਰ ਵੀ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਇਸ ਵਿਧੀ ਦੀ ਸੁਰੱਖਿਆ ਟੋਕਨ ਦੀ ਅਖੰਡਤਾ (integrity) ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਯੋਗਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਟੋਕਨ ਕਿਸੇ ਖ਼ਾਸ ਸੰਦਰਭ (context) ਲਈ ਜਾਇਜ਼ ਹੈ। ਇਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਕਈ ਖ਼ਤਰੇ ਹਨ, ਅਤੇ ਇਹ ਅਧਿਆਇ ਉਹਨਾਂ ਵਿਧੀਆਂ ਦੇ ਖ਼ਾਸ ਵੇਰਵੇ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨਾਂ ਕੋਲ ਉਹਨਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। + +## V9.1 Token source and integrity +## V9.1 ਟੋਕਨ ਸਰੋਤ ਅਤੇ ਅਖੰਡਤਾ (Token source and integrity) + +This section includes requirements to ensure that the token has been produced by a trusted party and has not been tampered with. + +ਇਸ ਭਾਗ ਵਿੱਚ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ ਕਿ ਟੋਕਨ ਕਿਸੇ ਭਰੋਸੇਯੋਗ ਧਿਰ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਸ ਨਾਲ ਛੇੜਛਾੜ ਨਹੀਂ ਕੀਤੀ ਗਈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **9.1.1** | Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents. | 1 | +| **9.1.2** | Verify that only algorithms on an allowlist can be used to create and verify self-contained tokens, for a given context. The allowlist must include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and must not include the 'None' algorithm. If both symmetric and asymmetric must be supported, additional controls will be needed to prevent key confusion. | 1 | +| **9.1.3** | Verify that key material that is used to validate self-contained tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources. | 1 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **9.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨਾਂ ਨੂੰ ਟੋਕਨ ਦੀ ਸਮੱਗਰੀ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਛੇੜਛਾੜ ਤੋਂ ਬਚਾਉਣ ਲਈ ਉਹਨਾਂ ਦੇ ਡਿਜੀਟਲ ਦਸਤਖ਼ਤ (digital signature) ਜਾਂ MAC ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। | 1 | +| **9.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਿਸੇ ਦਿੱਤੇ ਸੰਦਰਭ ਲਈ, ਸਿਰਫ਼ allowlist ਉੱਤੇ ਮੌਜੂਦ algorithms ਹੀ ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨ ਬਣਾਉਣ ਅਤੇ ਤਸਦੀਕ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ। Allowlist ਵਿੱਚ ਪ੍ਰਵਾਨਿਤ algorithms ਸ਼ਾਮਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਜਾਂ ਤਾਂ ਸਿਰਫ਼ symmetric ਜਾਂ ਸਿਰਫ਼ asymmetric algorithms, ਅਤੇ ਇਸ ਵਿੱਚ 'None' algorithm ਸ਼ਾਮਲ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਜੇਕਰ symmetric ਅਤੇ asymmetric ਦੋਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ, ਤਾਂ key confusion ਨੂੰ ਰੋਕਣ ਲਈ ਵਾਧੂ ਨਿਯੰਤਰਣਾਂ ਦੀ ਲੋੜ ਪਵੇਗੀ। | 1 | +| **9.1.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਲਈ ਵਰਤੀ ਜਾਂਦੀ key material ਟੋਕਨ ਜਾਰੀਕਰਤਾ (token issuer) ਲਈ ਭਰੋਸੇਯੋਗ ਪਹਿਲਾਂ ਤੋਂ ਸੰਰਚਿਤ ਸਰੋਤਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਜੋ ਹਮਲਾਵਰਾਂ ਨੂੰ ਅਣਭਰੋਸੇਯੋਗ ਸਰੋਤ ਅਤੇ ਕੁੰਜੀਆਂ ਨਿਰਧਾਰਤ ਕਰਨ ਤੋਂ ਰੋਕਦੀ ਹੈ। JWTs ਅਤੇ ਹੋਰ JWS structures ਲਈ, 'jku', 'x5u', ਅਤੇ 'jwk' ਵਰਗੇ headers ਨੂੰ ਭਰੋਸੇਯੋਗ ਸਰੋਤਾਂ ਦੀ allowlist ਦੇ ਵਿਰੁੱਧ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। | 1 | + +## V9.2 Token content +## V9.2 ਟੋਕਨ ਸਮੱਗਰੀ (Token content) + +Before making security decisions based on the content of a self-contained token, it is necessary to validate that the token has been presented within its validity period and that it is intended for use by the receiving service and for the purpose for which it was presented. This helps avoid insecure cross-usage between different services or with different token types from the same issuer. + +ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨ ਦੀ ਸਮੱਗਰੀ ਦੇ ਆਧਾਰ 'ਤੇ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲੇ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਟੋਕਨ ਆਪਣੀ ਜਾਇਜ਼ਤਾ ਮਿਆਦ (validity period) ਦੇ ਅੰਦਰ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਹ ਪ੍ਰਾਪਤਕਰਤਾ ਸੇਵਾ ਦੁਆਰਾ ਵਰਤੋਂ ਲਈ ਅਤੇ ਉਸ ਉਦੇਸ਼ ਲਈ ਹੈ ਜਿਸ ਲਈ ਇਸ ਨੂੰ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਹ ਵੱਖ-ਵੱਖ ਸੇਵਾਵਾਂ ਵਿਚਕਾਰ ਜਾਂ ਉਸੇ ਜਾਰੀਕਰਤਾ ਤੋਂ ਵੱਖ-ਵੱਖ ਟੋਕਨ ਕਿਸਮਾਂ ਨਾਲ ਅਸੁਰੱਖਿਅਤ ਅੰਤਰ-ਵਰਤੋਂ (cross-usage) ਤੋਂ ਬਚਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। + +Specific requirements for OAuth and OIDC are covered in the dedicated chapter. + +OAuth ਅਤੇ OIDC ਲਈ ਖ਼ਾਸ ਲੋੜਾਂ ਸਮਰਪਿਤ ਅਧਿਆਇ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **9.2.1** | Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validity time span. For example, for JWTs, the claims 'nbf' and 'exp' must be verified. | 1 | +| **9.2.2** | Verify that the service receiving a token validates the token to be the correct type and is meant for the intended purpose before accepting the token's contents. For example, only access tokens can be accepted for authorization decisions and only ID Tokens can be used for proving user authentication. | 2 | +| **9.2.3** | Verify that the service only accepts tokens which are intended for use with that service (audience). For JWTs, this can be achieved by validating the 'aud' claim against an allowlist defined in the service. | 2 | +| **9.2.4** | Verify that, if a token issuer uses the same private key for issuing tokens to different audiences, the issued tokens contain an audience restriction that uniquely identifies the intended audiences. This will prevent a token from being reused with an unintended audience. If the audience identifier is dynamically provisioned, the token issuer must validate these audiences in order to make sure that they do not result in audience impersonation. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **9.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇਕਰ ਟੋਕਨ ਡਾਟਾ ਵਿੱਚ ਜਾਇਜ਼ਤਾ ਸਮਾਂ-ਸੀਮਾ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਟੋਕਨ ਅਤੇ ਉਸ ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਉਦੋਂ ਹੀ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੇਕਰ ਤਸਦੀਕ ਦਾ ਸਮਾਂ ਇਸ ਜਾਇਜ਼ਤਾ ਸਮਾਂ-ਸੀਮਾ ਦੇ ਅੰਦਰ ਹੈ। ਉਦਾਹਰਣ ਲਈ, JWTs ਲਈ, 'nbf' ਅਤੇ 'exp' claims ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। | 1 | +| **9.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਟੋਕਨ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਟੋਕਨ ਦੀ ਸਮੱਗਰੀ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟੋਕਨ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦੀ ਹੈ ਕਿ ਇਹ ਸਹੀ ਕਿਸਮ ਦਾ ਹੈ ਅਤੇ ਨਿਰਧਾਰਿਤ ਉਦੇਸ਼ ਲਈ ਹੈ। ਉਦਾਹਰਣ ਲਈ, ਅਧਿਕਾਰ (authorization) ਫ਼ੈਸਲਿਆਂ ਲਈ ਸਿਰਫ਼ access tokens ਸਵੀਕਾਰ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਅਤੇ ਉਪਭੋਗਤਾ ਪ੍ਰਮਾਣੀਕਰਨ ਸਾਬਤ ਕਰਨ ਲਈ ਸਿਰਫ਼ ID Tokens ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ। | 2 | +| **9.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੇਵਾ ਸਿਰਫ਼ ਉਹਨਾਂ ਟੋਕਨਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਜੋ ਉਸ ਸੇਵਾ ਨਾਲ ਵਰਤੋਂ ਲਈ ਹਨ (audience)। JWTs ਲਈ, ਇਹ ਸੇਵਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ allowlist ਦੇ ਵਿਰੁੱਧ 'aud' claim ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। | 2 | +| **9.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇਕਰ ਕੋਈ ਟੋਕਨ ਜਾਰੀਕਰਤਾ ਵੱਖ-ਵੱਖ audiences ਨੂੰ ਟੋਕਨ ਜਾਰੀ ਕਰਨ ਲਈ ਇੱਕੋ private key ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਜਾਰੀ ਕੀਤੇ ਟੋਕਨਾਂ ਵਿੱਚ audience ਪਾਬੰਦੀ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ ਜੋ ਨਿਰਧਾਰਿਤ audiences ਦੀ ਵਿਲੱਖਣ ਪਛਾਣ ਕਰਦੀ ਹੈ। ਇਹ ਟੋਕਨ ਨੂੰ ਕਿਸੇ ਅਣ-ਨਿਰਧਾਰਿਤ audience ਨਾਲ ਮੁੜ-ਵਰਤੋਂ ਤੋਂ ਰੋਕੇਗਾ। ਜੇਕਰ audience identifier ਨੂੰ ਗਤੀਸ਼ੀਲ ਰੂਪ ਵਿੱਚ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਟੋਕਨ ਜਾਰੀਕਰਤਾ ਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਇਹਨਾਂ audiences ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ ਕਿ ਉਹ audience impersonation ਦਾ ਨਤੀਜਾ ਨਹੀਂ ਬਣਦੀਆਂ। | 2 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [OWASP JSON Web Token Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html) + +* [OWASP JSON Web Token Cheat Sheet for Java Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) (ਪਰ ਉਪਯੋਗੀ ਆਮ ਮਾਰਗਦਰਸ਼ਨ ਮੌਜੂਦ ਹੈ) diff --git a/5.0/pa-IN/0x19-V10-OAuth-and-OIDC.md b/5.0/pa-IN/0x19-V10-OAuth-and-OIDC.md new file mode 100644 index 0000000000..5880b965c9 --- /dev/null +++ b/5.0/pa-IN/0x19-V10-OAuth-and-OIDC.md @@ -0,0 +1,311 @@ + + + + +# V10 OAuth and OIDC +# V10 OAuth ਅਤੇ OIDC + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +OAuth2 (referred to as OAuth in this chapter) is an industry-standard framework for delegated authorization. For example, using OAuth, a client application can obtain access to APIs (server resources) on a user's behalf, provided the user has authorized the client application to do so. + +OAuth2 (ਇਸ ਅਧਿਆਇ ਵਿੱਚ OAuth ਕਿਹਾ ਗਿਆ ਹੈ) ਸੌਂਪੇ ਗਏ ਅਧਿਕਾਰੀਕਰਨ (delegated authorization) ਲਈ ਇੱਕ ਉਦਯੋਗ-ਮਿਆਰੀ ਫ੍ਰੇਮਵਰਕ ਹੈ। ਉਦਾਹਰਨ ਲਈ, OAuth ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਇੱਕ client ਐਪਲੀਕੇਸ਼ਨ ਉਪਭੋਗਤਾ ਦੀ ਤਰਫ਼ੋਂ API (ਸਰਵਰ ਸਰੋਤਾਂ) ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀ ਹੈ, ਬਸ਼ਰਤੇ ਕਿ ਉਪਭੋਗਤਾ ਨੇ client ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਜਿਹਾ ਕਰਨ ਲਈ ਅਧਿਕਾਰਤ ਕੀਤਾ ਹੋਵੇ। + +By itself, OAuth is not designed for user authentication. The OpenID Connect (OIDC) framework extends OAuth by adding a user identity layer on top of OAuth. OIDC provides support for features including standardized user information, Single Sign-On (SSO), and session management. As OIDC is an extension of OAuth, the OAuth requirements in this chapter also apply to OIDC. + +ਆਪਣੇ ਆਪ ਵਿੱਚ, OAuth ਉਪਭੋਗਤਾ ਪ੍ਰਮਾਣੀਕਰਨ (authentication) ਲਈ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ। OpenID Connect (OIDC) ਫ੍ਰੇਮਵਰਕ OAuth ਦੇ ਉੱਪਰ ਇੱਕ ਉਪਭੋਗਤਾ ਪਛਾਣ ਪਰਤ ਜੋੜ ਕੇ OAuth ਦਾ ਵਿਸਤਾਰ ਕਰਦਾ ਹੈ। OIDC ਮਿਆਰੀਕ੍ਰਿਤ ਉਪਭੋਗਤਾ ਜਾਣਕਾਰੀ, ਸਿੰਗਲ ਸਾਈਨ-ਔਨ (Single Sign-On, SSO), ਅਤੇ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਸਮੇਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ ਸਮਰਥਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ OIDC OAuth ਦਾ ਇੱਕ ਵਿਸਤਾਰ ਹੈ, ਇਸ ਅਧਿਆਇ ਦੀਆਂ OAuth ਲੋੜਾਂ OIDC 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ। + +The following roles are defined in OAuth: + +OAuth ਵਿੱਚ ਹੇਠ ਲਿਖੀਆਂ ਭੂਮਿਕਾਵਾਂ ਪਰਿਭਾਸ਼ਿਤ ਹਨ: + +* The OAuth client is the application that attempts to obtain access to server resources (e.g., by calling an API using the issued access token). The OAuth client is often a server-side application. + * A confidential client is a client capable of maintaining the confidentiality of the credentials it uses to authenticate itself with the authorization server. + * A public client is not capable of maintaining the confidentiality of credentials for authenticating with the authorization server. Therefore, instead of authenticating itself (e.g., using 'client_id' and 'client_secret' parameters), it only identifies itself (using a 'client_id' parameter). +* The OAuth resource server (RS) is the server API exposing resources to OAuth clients. +* The OAuth authorization server (AS) is a server application that issues access tokens to OAuth clients. These access tokens allow OAuth clients to access RS resources, either on behalf of an end-user or on the OAuth client's own behalf. The AS is often a separate application, but (if appropriate) it may be integrated into a suitable RS. +* The resource owner (RO) is the end-user who authorizes OAuth clients to obtain limited access to resources hosted on the resource server on their behalf. The resource owner consents to this delegated authorization by interacting with the authorization server. + +* OAuth client ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਹੈ ਜੋ ਸਰਵਰ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ (ਜਿਵੇਂ, ਜਾਰੀ ਕੀਤੇ access token (ਪਹੁੰਚ ਟੋਕਨ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਸੇ API ਨੂੰ ਕਾਲ ਕਰਕੇ)। OAuth client ਅਕਸਰ ਇੱਕ ਸਰਵਰ-ਸਾਈਡ ਐਪਲੀਕੇਸ਼ਨ ਹੁੰਦੀ ਹੈ। + * ਇੱਕ confidential client (ਗੁਪਤ client) ਉਹ client ਹੈ ਜੋ ਉਹਨਾਂ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦੀ ਗੁਪਤਤਾ ਕਾਇਮ ਰੱਖਣ ਦੇ ਸਮਰੱਥ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਵਰਤੋਂ ਉਹ authorization server (ਅਧਿਕਾਰੀਕਰਨ ਸਰਵਰ) ਨਾਲ ਆਪਣਾ ਪ੍ਰਮਾਣੀਕਰਨ ਕਰਨ ਲਈ ਕਰਦਾ ਹੈ। + * ਇੱਕ public client (ਜਨਤਕ client) authorization server ਨਾਲ ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦੀ ਗੁਪਤਤਾ ਕਾਇਮ ਰੱਖਣ ਦੇ ਸਮਰੱਥ ਨਹੀਂ ਹੁੰਦਾ। ਇਸ ਲਈ, ਆਪਣਾ ਪ੍ਰਮਾਣੀਕਰਨ ਕਰਨ ਦੀ ਬਜਾਏ (ਜਿਵੇਂ, 'client_id' ਅਤੇ 'client_secret' ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ), ਇਹ ਸਿਰਫ਼ ਆਪਣੀ ਪਛਾਣ ਦੱਸਦਾ ਹੈ ('client_id' ਪੈਰਾਮੀਟਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ)। +* OAuth resource server (RS — ਸਰੋਤ ਸਰਵਰ) ਉਹ ਸਰਵਰ API ਹੈ ਜੋ OAuth clients ਨੂੰ ਸਰੋਤ ਉਜਾਗਰ ਕਰਦਾ ਹੈ। +* OAuth authorization server (AS — ਅਧਿਕਾਰੀਕਰਨ ਸਰਵਰ) ਇੱਕ ਸਰਵਰ ਐਪਲੀਕੇਸ਼ਨ ਹੈ ਜੋ OAuth clients ਨੂੰ access tokens ਜਾਰੀ ਕਰਦੀ ਹੈ। ਇਹ access tokens OAuth clients ਨੂੰ RS ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਜਾਂ ਤਾਂ ਕਿਸੇ ਅੰਤਮ-ਉਪਭੋਗਤਾ ਦੀ ਤਰਫ਼ੋਂ ਜਾਂ OAuth client ਦੀ ਆਪਣੀ ਤਰਫ਼ੋਂ। AS ਅਕਸਰ ਇੱਕ ਵੱਖਰੀ ਐਪਲੀਕੇਸ਼ਨ ਹੁੰਦਾ ਹੈ, ਪਰ (ਜੇ ਢੁਕਵਾਂ ਹੋਵੇ) ਇਸ ਨੂੰ ਕਿਸੇ ਢੁਕਵੇਂ RS ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। +* resource owner (RO — ਸਰੋਤ ਮਾਲਕ) ਉਹ ਅੰਤਮ-ਉਪਭੋਗਤਾ ਹੈ ਜੋ OAuth clients ਨੂੰ ਆਪਣੀ ਤਰਫ਼ੋਂ resource server 'ਤੇ ਹੋਸਟ ਕੀਤੇ ਸਰੋਤਾਂ ਤੱਕ ਸੀਮਤ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਅਧਿਕਾਰਤ ਕਰਦਾ ਹੈ। resource owner authorization server ਨਾਲ ਅੰਤਰਕਿਰਿਆ ਕਰਕੇ ਇਸ ਸੌਂਪੇ ਗਏ ਅਧਿਕਾਰੀਕਰਨ ਲਈ ਸਹਿਮਤੀ (consent) ਦਿੰਦਾ ਹੈ। + +The following roles are defined in OIDC: + +OIDC ਵਿੱਚ ਹੇਠ ਲਿਖੀਆਂ ਭੂਮਿਕਾਵਾਂ ਪਰਿਭਾਸ਼ਿਤ ਹਨ: + +* The relying party (RP) is the client application requesting end-user authentication through the OpenID Provider. It assumes the role of an OAuth client. +* The OpenID Provider (OP) is an OAuth AS that is capable of authenticating the end-user and provides OIDC claims to an RP. The OP may be the identity provider (IdP), but in federated scenarios, the OP and the identity provider (where the end-user authenticates) may be different server applications. + +* ਨਿਰਭਰ ਧਿਰ (relying party, RP) ਉਹ client ਐਪਲੀਕੇਸ਼ਨ ਹੈ ਜੋ OpenID Provider ਰਾਹੀਂ ਅੰਤਮ-ਉਪਭੋਗਤਾ ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਬੇਨਤੀ ਕਰਦੀ ਹੈ। ਇਹ ਇੱਕ OAuth client ਦੀ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦੀ ਹੈ। +* OpenID Provider (OP — OpenID ਪ੍ਰਦਾਤਾ) ਇੱਕ ਅਜਿਹਾ OAuth AS ਹੈ ਜੋ ਅੰਤਮ-ਉਪਭੋਗਤਾ ਦਾ ਪ੍ਰਮਾਣੀਕਰਨ ਕਰਨ ਦੇ ਸਮਰੱਥ ਹੈ ਅਤੇ ਕਿਸੇ RP ਨੂੰ OIDC ਦਾਅਵੇ (claims) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। OP ਪਛਾਣ ਪ੍ਰਦਾਤਾ (identity provider, IdP) ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਸੰਘੀ (federated) ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ, OP ਅਤੇ ਪਛਾਣ ਪ੍ਰਦਾਤਾ (ਜਿੱਥੇ ਅੰਤਮ-ਉਪਭੋਗਤਾ ਪ੍ਰਮਾਣੀਕਰਨ ਕਰਦਾ ਹੈ) ਵੱਖ-ਵੱਖ ਸਰਵਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। + +OAuth and OIDC were initially designed for third-party applications. Today, they are often used by first-party applications as well. However, when used in first-party scenarios, such as authentication and session management, the protocol adds some complexity, which may introduce new security challenges. + +OAuth ਅਤੇ OIDC ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਤੀਜੀ-ਧਿਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸੀ। ਅੱਜ, ਇਹ ਅਕਸਰ ਪਹਿਲੀ-ਧਿਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੁਆਰਾ ਵੀ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਜਦੋਂ ਪਹਿਲੀ-ਧਿਰ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ, ਤਾਂ ਪ੍ਰੋਟੋਕਾਲ ਕੁਝ ਜਟਿਲਤਾ ਜੋੜਦਾ ਹੈ, ਜੋ ਨਵੀਆਂ ਸੁਰੱਖਿਆ ਚੁਣੌਤੀਆਂ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ। + +OAuth and OIDC can be used for many types of applications, but the focus for ASVS and the requirements in this chapter is on web applications and APIs. + +OAuth ਅਤੇ OIDC ਕਈ ਕਿਸਮਾਂ ਦੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਪਰ ASVS ਅਤੇ ਇਸ ਅਧਿਆਇ ਦੀਆਂ ਲੋੜਾਂ ਦਾ ਕੇਂਦਰ-ਬਿੰਦੂ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ API ਹਨ। + +Since OAuth and OIDC can be considered logic on top of web technologies, general requirements from other chapters always apply, and this chapter cannot be taken out of context. + +ਕਿਉਂਕਿ OAuth ਅਤੇ OIDC ਨੂੰ ਵੈੱਬ ਤਕਨਾਲੋਜੀਆਂ ਦੇ ਉੱਪਰ ਤਰਕ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਦੂਜੇ ਅਧਿਆਵਾਂ ਦੀਆਂ ਆਮ ਲੋੜਾਂ ਹਮੇਸ਼ਾ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਇਸ ਅਧਿਆਇ ਨੂੰ ਸੰਦਰਭ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਲਿਆ ਜਾ ਸਕਦਾ। + +This chapter addresses best current practices for OAuth2 and OIDC aligned with specifications found at and . Even if RFCs are considered mature, they are updated frequently. Thus, it is important to align with the latest versions when applying the requirements in this chapter. See the references section for more details. + +ਇਹ ਅਧਿਆਇ OAuth2 ਅਤੇ OIDC ਲਈ ਸਭ ਤੋਂ ਚੰਗੇ ਮੌਜੂਦਾ ਅਮਲਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਅਤੇ 'ਤੇ ਮਿਲਣ ਵਾਲੀਆਂ ਸਪੈਸੀਫ਼ਿਕੇਸ਼ਨਾਂ (specifications) ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ। ਭਾਵੇਂ RFC ਨੂੰ ਪਰਿਪੱਕ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਉਹ ਅਕਸਰ ਅੱਪਡੇਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਇਸ ਲਈ, ਇਸ ਅਧਿਆਇ ਦੀਆਂ ਲੋੜਾਂ ਲਾਗੂ ਕਰਦੇ ਸਮੇਂ ਨਵੀਨਤਮ ਸੰਸਕਰਣਾਂ ਨਾਲ ਮੇਲ ਰੱਖਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਹੋਰ ਵੇਰਵਿਆਂ ਲਈ ਹਵਾਲੇ ਭਾਗ ਵੇਖੋ। + +Given the complexity of the area, it is vitally important for a secure OAuth or OIDC solution to use well-known industry-standard authorization servers and apply the recommended security configuration. + +ਇਸ ਖੇਤਰ ਦੀ ਜਟਿਲਤਾ ਨੂੰ ਦੇਖਦਿਆਂ, ਇੱਕ ਸੁਰੱਖਿਅਤ OAuth ਜਾਂ OIDC ਹੱਲ ਲਈ ਇਹ ਬੇਹੱਦ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਪ੍ਰਸਿੱਧ ਉਦਯੋਗ-ਮਿਆਰੀ authorization servers ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਵੇ ਅਤੇ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਸੁਰੱਖਿਆ ਸੰਰਚਨਾ ਲਾਗੂ ਕੀਤੀ ਜਾਵੇ। + +Terminology used in this chapter aligns with OAuth RFCs and OIDC specifications, but note that OIDC terminology is only used for OIDC-specific requirements; otherwise, OAuth terminology is used. + +ਇਸ ਅਧਿਆਇ ਵਿੱਚ ਵਰਤੀ ਗਈ ਸ਼ਬਦਾਵਲੀ OAuth RFC ਅਤੇ OIDC ਸਪੈਸੀਫ਼ਿਕੇਸ਼ਨਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਪਰ ਧਿਆਨ ਦਿਓ ਕਿ OIDC ਸ਼ਬਦਾਵਲੀ ਸਿਰਫ਼ OIDC-ਵਿਸ਼ੇਸ਼ ਲੋੜਾਂ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ; ਨਹੀਂ ਤਾਂ, OAuth ਸ਼ਬਦਾਵਲੀ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। + +In the context of OAuth and OIDC, the term "token" in this chapter refers to: + +OAuth ਅਤੇ OIDC ਦੇ ਸੰਦਰਭ ਵਿੱਚ, ਇਸ ਅਧਿਆਇ ਵਿੱਚ "ਟੋਕਨ" (token) ਸ਼ਬਦ ਦਾ ਮਤਲਬ ਹੈ: + +* Access tokens, which shall only be consumed by the RS and can either be reference tokens that are validated using introspection or self-contained tokens that are validated using some key material. +* Refresh tokens, which shall only be consumed by the authorization server that issued the token. +* OIDC ID Tokens, which shall only be consumed by the client that triggered the authorization flow. + +* Access tokens, ਜੋ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ RS ਦੁਆਰਾ ਹੀ ਖਪਤ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਜੋ ਜਾਂ ਤਾਂ ਹਵਾਲਾ ਟੋਕਨ (reference tokens) ਹੋ ਸਕਦੇ ਹਨ ਜੋ introspection ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਮਾਣਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜਾਂ ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨ (self-contained tokens) ਜੋ ਕਿਸੇ key material ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਮਾਣਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। +* Refresh tokens (ਨਵਿਆਉਣ ਟੋਕਨ), ਜੋ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਉਸ authorization server ਦੁਆਰਾ ਹੀ ਖਪਤ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ ਜਿਸ ਨੇ ਟੋਕਨ ਜਾਰੀ ਕੀਤਾ ਹੈ। +* OIDC ID Tokens (ਪਛਾਣ ਟੋਕਨ), ਜੋ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਉਸ client ਦੁਆਰਾ ਹੀ ਖਪਤ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ ਜਿਸ ਨੇ ਅਧਿਕਾਰੀਕਰਨ ਪ੍ਰਵਾਹ (authorization flow) ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ। + +The risk levels for some of the requirements in this chapter depend on whether the client is a confidential client or regarded as a public client. Since using strong client authentication mitigates many attack vectors, a few requirements might be relaxed when using a confidential client for L1 applications. + +ਇਸ ਅਧਿਆਇ ਦੀਆਂ ਕੁਝ ਲੋੜਾਂ ਲਈ ਜੋਖਮ ਪੱਧਰ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਕਿ client ਇੱਕ confidential client ਹੈ ਜਾਂ ਇਸ ਨੂੰ public client ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਕਿਉਂਕਿ ਮਜ਼ਬੂਤ client ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਵਰਤੋਂ ਕਈ ਹਮਲਾ ਵੈਕਟਰਾਂ (attack vectors) ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ, L1 ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ confidential client ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਕੁਝ ਲੋੜਾਂ ਢਿੱਲੀਆਂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। + +## V10.1 Generic OAuth and OIDC Security +## V10.1 ਆਮ OAuth ਅਤੇ OIDC ਸੁਰੱਖਿਆ + +This section covers generic architectural requirements that apply to all applications using OAuth or OIDC. + +ਇਹ ਭਾਗ ਉਹਨਾਂ ਆਮ ਆਰਕੀਟੈਕਚਰ-ਸੰਬੰਧੀ ਲੋੜਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਜੋ OAuth ਜਾਂ OIDC ਵਰਤਣ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.1.1** | Verify that tokens are only sent to components that strictly need them. For example, when using a backend-for-frontend pattern for browser-based JavaScript applications, access and refresh tokens shall only be accessible for the backend. | 2 | +| **10.1.2** | Verify that the client only accepts values from the authorization server (such as the authorization code or ID Token) if these values result from an authorization flow that was initiated by the same user agent session and transaction. This requires that client-generated secrets, such as the proof key for code exchange (PKCE) 'code_verifier', 'state' or OIDC 'nonce', are not guessable, are specific to the transaction, and are securely bound to both the client and the user agent session in which the transaction was started. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **10.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਟੋਕਨ ਸਿਰਫ਼ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਹੀ ਭੇਜੇ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹਨਾਂ ਦੀ ਸਖ਼ਤ ਲੋੜ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਬ੍ਰਾਊਜ਼ਰ-ਆਧਾਰਿਤ JavaScript ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ backend-for-frontend ਪੈਟਰਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, access ਅਤੇ refresh tokens ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਬੈਕਐਂਡ ਲਈ ਹੀ ਪਹੁੰਚਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। | 2 | +| **10.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ client authorization server ਤੋਂ ਮੁੱਲ (ਜਿਵੇਂ ਕਿ authorization code ਜਾਂ ID Token) ਸਿਰਫ਼ ਤਾਂ ਹੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਜੇ ਇਹ ਮੁੱਲ ਉਸੇ ਯੂਜ਼ਰ ਏਜੰਟ (user agent) ਸੈਸ਼ਨ ਅਤੇ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੇ ਅਧਿਕਾਰੀਕਰਨ ਪ੍ਰਵਾਹ ਦਾ ਨਤੀਜਾ ਹਨ। ਇਸ ਲਈ ਜ਼ਰੂਰੀ ਹੈ ਕਿ client ਦੁਆਰਾ ਪੈਦਾ ਕੀਤੇ ਭੇਦ, ਜਿਵੇਂ ਕਿ proof key for code exchange (PKCE) 'code_verifier', 'state' ਜਾਂ OIDC 'nonce', ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਯੋਗ ਨਾ ਹੋਣ, ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਲਈ ਵਿਸ਼ੇਸ਼ ਹੋਣ, ਅਤੇ client ਅਤੇ ਉਸ ਯੂਜ਼ਰ ਏਜੰਟ ਸੈਸ਼ਨ ਦੋਵਾਂ ਨਾਲ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਬੰਨ੍ਹੇ ਹੋਏ ਹੋਣ ਜਿਸ ਵਿੱਚ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕੀਤੀ ਗਈ ਸੀ। | 2 | + +## V10.2 OAuth Client +## V10.2 OAuth Client (ਓਅਥ ਕਲਾਇੰਟ) + +These requirements detail the responsibilities for OAuth client applications. The client can be, for example, a web server backend (often acting as a Backend For Frontend, BFF), a backend service integration, or a frontend Single Page Application (SPA, aka browser-based application). + +ਇਹ ਲੋੜਾਂ OAuth client ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦਾ ਵੇਰਵਾ ਦਿੰਦੀਆਂ ਹਨ। client, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਵੈੱਬ ਸਰਵਰ ਬੈਕਐਂਡ (ਜੋ ਅਕਸਰ Backend For Frontend, BFF ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ), ਇੱਕ ਬੈਕਐਂਡ ਸੇਵਾ ਏਕੀਕਰਨ, ਜਾਂ ਇੱਕ ਫਰੰਟਐਂਡ Single Page Application (SPA — ਇੱਕ-ਪੰਨਾ ਐਪਲੀਕੇਸ਼ਨ, ਜਿਸ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ-ਆਧਾਰਿਤ ਐਪਲੀਕੇਸ਼ਨ ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਹੋ ਸਕਦਾ ਹੈ। + +In general, backend clients are regarded as confidential clients and frontend clients are regarded as public clients. However, native applications running on the end-user device can be regarded as confidential when using OAuth dynamic client registration. + +ਆਮ ਤੌਰ 'ਤੇ, ਬੈਕਐਂਡ clients ਨੂੰ confidential clients ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਫਰੰਟਐਂਡ clients ਨੂੰ public clients ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਅੰਤਮ-ਉਪਭੋਗਤਾ ਦੀ ਡਿਵਾਈਸ 'ਤੇ ਚੱਲਣ ਵਾਲੀਆਂ ਨੇਟਿਵ (native) ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ OAuth ਗਤੀਸ਼ੀਲ client ਰਜਿਸਟ੍ਰੇਸ਼ਨ (dynamic client registration) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ confidential ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.2.1** | Verify that, if the code flow is used, the OAuth client has protection against browser-based request forgery attacks, commonly known as cross-site request forgery (CSRF), which trigger token requests, either by using proof key for code exchange (PKCE) functionality or checking the 'state' parameter that was sent in the authorization request. | 2 | +| **10.2.2** | Verify that, if the OAuth client can interact with more than one authorization server, it has a defense against mix-up attacks. For example, it could require that the authorization server return the 'iss' parameter value and validate it in the authorization response and the token response. | 2 | +| **10.2.3** | Verify that the OAuth client only requests the required scopes (or other authorization parameters) in requests to the authorization server. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **10.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ code flow ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ OAuth client ਕੋਲ ਬ੍ਰਾਊਜ਼ਰ-ਆਧਾਰਿਤ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ ਹਮਲਿਆਂ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਕਰਾਸ-ਸਾਈਟ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ (CSRF) ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਜੋ ਟੋਕਨ ਬੇਨਤੀਆਂ ਨੂੰ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ, ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਹੈ, ਜਾਂ ਤਾਂ proof key for code exchange (PKCE) ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜਾਂ ਅਧਿਕਾਰੀਕਰਨ ਬੇਨਤੀ ਵਿੱਚ ਭੇਜੇ ਗਏ 'state' ਪੈਰਾਮੀਟਰ ਦੀ ਜਾਂਚ ਕਰਕੇ। | 2 | +| **10.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ OAuth client ਇੱਕ ਤੋਂ ਵੱਧ authorization server ਨਾਲ ਅੰਤਰਕਿਰਿਆ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਸ ਕੋਲ mix-up ਹਮਲਿਆਂ (ਸਰਵਰਾਂ ਦੇ ਰਲ਼-ਗੱਡ ਹੋਣ ਵਾਲੇ ਹਮਲਿਆਂ) ਦੇ ਵਿਰੁੱਧ ਰੱਖਿਆ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇਹ ਮੰਗ ਕਰ ਸਕਦਾ ਹੈ ਕਿ authorization server 'iss' ਪੈਰਾਮੀਟਰ ਮੁੱਲ ਵਾਪਸ ਕਰੇ ਅਤੇ ਅਧਿਕਾਰੀਕਰਨ ਜਵਾਬ ਅਤੇ ਟੋਕਨ ਜਵਾਬ ਵਿੱਚ ਇਸ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰੇ। | 2 | +| **10.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ OAuth client authorization server ਨੂੰ ਬੇਨਤੀਆਂ ਵਿੱਚ ਸਿਰਫ਼ ਲੋੜੀਂਦੇ scopes (ਜਾਂ ਹੋਰ ਅਧਿਕਾਰੀਕਰਨ ਪੈਰਾਮੀਟਰਾਂ) ਦੀ ਹੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ। | 3 | + +## V10.3 OAuth Resource Server +## V10.3 OAuth Resource Server (ਓਅਥ ਸਰੋਤ ਸਰਵਰ) + +In the context of ASVS and this chapter, the resource server is an API. To provide secure access, the resource server must: + +ASVS ਅਤੇ ਇਸ ਅਧਿਆਇ ਦੇ ਸੰਦਰਭ ਵਿੱਚ, resource server ਇੱਕ API ਹੈ। ਸੁਰੱਖਿਅਤ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ, resource server ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ: + +* Validate the access token, according to the token format and relevant protocol specifications, e.g., JWT-validation or OAuth token introspection. +* If valid, enforce authorization decisions based on the information from the access token and permissions which have been granted. For example, the resource server needs to verify that the client (acting on behalf of RO) is authorized to access the requested resource. + +* access token ਨੂੰ ਟੋਕਨ ਫਾਰਮੈਟ ਅਤੇ ਸੰਬੰਧਤ ਪ੍ਰੋਟੋਕਾਲ ਸਪੈਸੀਫ਼ਿਕੇਸ਼ਨਾਂ ਦੇ ਅਨੁਸਾਰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਵੇਂ, JWT-ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ OAuth token introspection। +* ਜੇ ਜਾਇਜ਼ ਹੈ, ਤਾਂ access token ਦੀ ਜਾਣਕਾਰੀ ਅਤੇ ਦਿੱਤੀਆਂ ਗਈਆਂ ਇਜਾਜ਼ਤਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਅਧਿਕਾਰੀਕਰਨ ਫ਼ੈਸਲੇ ਲਾਗੂ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, resource server ਨੂੰ ਇਹ ਤਸਦੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਕਿ client (RO ਦੀ ਤਰਫ਼ੋਂ ਕੰਮ ਕਰਦਾ ਹੋਇਆ) ਬੇਨਤੀ ਕੀਤੇ ਸਰੋਤ ਤੱਕ ਪਹੁੰਚ ਲਈ ਅਧਿਕਾਰਤ ਹੈ। + +Therefore, the requirements listed here are OAuth or OIDC specific and should be performed after token validation and before performing authorization based on information from the token. + +ਇਸ ਲਈ, ਇੱਥੇ ਸੂਚੀਬੱਧ ਲੋੜਾਂ OAuth ਜਾਂ OIDC ਵਿਸ਼ੇਸ਼ ਹਨ ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਟੋਕਨ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਬਾਅਦ ਅਤੇ ਟੋਕਨ ਦੀ ਜਾਣਕਾਰੀ ਦੇ ਆਧਾਰ 'ਤੇ ਅਧਿਕਾਰੀਕਰਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰਾ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.3.1** | Verify that the resource server only accepts access tokens that are intended for use with that service (audience). The audience may be included in a structured access token (such as the 'aud' claim in JWT), or it can be checked using the token introspection endpoint. | 2 | +| **10.3.2** | Verify that the resource server enforces authorization decisions based on claims from the access token that define delegated authorization. If claims such as 'sub', 'scope', and 'authorization_details' are present, they must be part of the decision. | 2 | +| **10.3.3** | Verify that if an access control decision requires identifying a unique user from an access token (JWT or related token introspection response), the resource server identifies the user from claims that cannot be reassigned to other users. Typically, it means using a combination of 'iss' and 'sub' claims. | 2 | +| **10.3.4** | Verify that, if the resource server requires specific authentication strength, methods, or recentness, it verifies that the presented access token satisfies these constraints. For example, if present, using the OIDC 'acr', 'amr' and 'auth_time' claims respectively. | 2 | +| **10.3.5** | Verify that the resource server prevents the use of stolen access tokens or replay of access tokens (from unauthorized parties) by requiring sender-constrained access tokens, either Mutual TLS for OAuth 2 or OAuth 2 Demonstration of Proof of Possession (DPoP). | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **10.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ resource server ਸਿਰਫ਼ ਉਹਨਾਂ access tokens ਨੂੰ ਹੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਜੋ ਉਸ ਸੇਵਾ ਨਾਲ ਵਰਤੋਂ ਲਈ ਹਨ (audience)। audience ਨੂੰ ਇੱਕ ਸੰਰਚਿਤ access token ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ JWT ਵਿੱਚ 'aud' ਦਾਅਵਾ), ਜਾਂ ਇਸ ਦੀ ਜਾਂਚ token introspection ਅੰਤ-ਬਿੰਦੂ (endpoint) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। | 2 | +| **10.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ resource server access token ਦੇ ਉਹਨਾਂ ਦਾਅਵਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਅਧਿਕਾਰੀਕਰਨ ਫ਼ੈਸਲੇ ਲਾਗੂ ਕਰਦਾ ਹੈ ਜੋ ਸੌਂਪੇ ਗਏ ਅਧਿਕਾਰੀਕਰਨ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ। ਜੇ 'sub', 'scope', ਅਤੇ 'authorization_details' ਵਰਗੇ ਦਾਅਵੇ ਮੌਜੂਦ ਹਨ, ਤਾਂ ਉਹ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਫ਼ੈਸਲੇ ਦਾ ਹਿੱਸਾ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। | 2 | +| **10.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜੇ ਕਿਸੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਫ਼ੈਸਲੇ ਲਈ access token (JWT ਜਾਂ ਸੰਬੰਧਤ token introspection ਜਵਾਬ) ਤੋਂ ਇੱਕ ਵਿਲੱਖਣ ਉਪਭੋਗਤਾ ਦੀ ਪਛਾਣ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ resource server ਉਪਭੋਗਤਾ ਦੀ ਪਛਾਣ ਉਹਨਾਂ ਦਾਅਵਿਆਂ ਤੋਂ ਕਰਦਾ ਹੈ ਜੋ ਹੋਰ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਮੁੜ-ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ। ਆਮ ਤੌਰ 'ਤੇ, ਇਸ ਦਾ ਮਤਲਬ 'iss' ਅਤੇ 'sub' ਦਾਅਵਿਆਂ ਦੇ ਸੁਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ। | 2 | +| **10.3.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ resource server ਨੂੰ ਖ਼ਾਸ ਪ੍ਰਮਾਣੀਕਰਨ ਤਾਕਤ, ਵਿਧੀਆਂ, ਜਾਂ ਤਾਜ਼ਗੀ (recentness) ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਹ ਤਸਦੀਕ ਕਰਦਾ ਹੈ ਕਿ ਪੇਸ਼ ਕੀਤਾ access token ਇਹਨਾਂ ਪਾਬੰਦੀਆਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇ ਮੌਜੂਦ ਹੋਣ, ਤਾਂ ਕ੍ਰਮਵਾਰ OIDC 'acr', 'amr' ਅਤੇ 'auth_time' ਦਾਅਵਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ। | 2 | +| **10.3.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ resource server ਭੇਜਣਹਾਰ-ਬੰਨ੍ਹੇ (sender-constrained) access tokens ਦੀ ਮੰਗ ਕਰਕੇ ਚੋਰੀ ਕੀਤੇ access tokens ਦੀ ਵਰਤੋਂ ਜਾਂ (ਅਣਅਧਿਕਾਰਤ ਧਿਰਾਂ ਵੱਲੋਂ) access tokens ਦੇ ਰੀਪਲੇ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਜਾਂ ਤਾਂ Mutual TLS for OAuth 2 ਜਾਂ OAuth 2 Demonstration of Proof of Possession (DPoP) ਰਾਹੀਂ। | 3 | + +## V10.4 OAuth Authorization Server +## V10.4 OAuth Authorization Server (ਓਅਥ ਅਧਿਕਾਰੀਕਰਨ ਸਰਵਰ) + +These requirements detail the responsibilities for OAuth authorization servers, including OpenID Providers. + +ਇਹ ਲੋੜਾਂ OAuth authorization servers, OpenID Providers ਸਮੇਤ, ਦੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦਾ ਵੇਰਵਾ ਦਿੰਦੀਆਂ ਹਨ। + +For client authentication, the 'self_signed_tls_client_auth' method is allowed with the prerequisites required by [section 2.2](https://datatracker.ietf.org/doc/html/rfc8705#name-self-signed-certificate-mut) of [RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705). + +client ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ, 'self_signed_tls_client_auth' ਵਿਧੀ ਦੀ ਇਜਾਜ਼ਤ [RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705) ਦੇ [ਭਾਗ 2.2](https://datatracker.ietf.org/doc/html/rfc8705#name-self-signed-certificate-mut) ਦੁਆਰਾ ਲੋੜੀਂਦੀਆਂ ਪੂਰਵ-ਸ਼ਰਤਾਂ ਨਾਲ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.4.1** | Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison. | 1 | +| **10.4.2** | Verify that, if the authorization server returns the authorization code in the authorization response, it can be used only once for a token request. For the second valid request with an authorization code that has already been used to issue an access token, the authorization server must reject a token request and revoke any issued tokens related to the authorization code. | 1 | +| **10.4.3** | Verify that the authorization code is short-lived. The maximum lifetime can be up to 10 minutes for L1 and L2 applications and up to 1 minute for L3 applications. | 1 | +| **10.4.4** | Verify that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) must no longer be used. | 1 | +| **10.4.5** | Verify that the authorization server mitigates refresh token replay attacks for public clients, preferably using sender-constrained refresh tokens, i.e., Demonstrating Proof of Possession (DPoP) or Certificate-Bound Access Tokens using mutual TLS (mTLS). For L1 and L2 applications, refresh token rotation may be used. If refresh token rotation is used, the authorization server must invalidate the refresh token after usage, and revoke all refresh tokens for that authorization if an already used and invalidated refresh token is provided. | 1 | +| **10.4.6** | Verify that, if the code grant is used, the authorization server mitigates authorization code interception attacks by requiring proof key for code exchange (PKCE). For authorization requests, the authorization server must require a valid 'code_challenge' value and must not accept a 'code_challenge_method' value of 'plain'. For a token request, it must require validation of the 'code_verifier' parameter. | 2 | +| **10.4.7** | Verify that if the authorization server supports unauthenticated dynamic client registration, it mitigates the risk of malicious client applications. It must validate client metadata such as any registered URIs, ensure the user's consent, and warn the user before processing an authorization request with an untrusted client application. | 2 | +| **10.4.8** | Verify that refresh tokens have an absolute expiration, including if sliding refresh token expiration is applied. | 2 | +| **10.4.9** | Verify that refresh tokens and reference access tokens can be revoked by an authorized user using the authorization server user interface, to mitigate the risk of malicious clients or stolen tokens. | 2 | +| **10.4.10** | Verify that confidential client is authenticated for client-to-authorized server backchannel requests such as token requests, pushed authorization requests (PAR), and token revocation requests. | 2 | +| **10.4.11** | Verify that the authorization server configuration only assigns the required scopes to the OAuth client. | 2 | +| **10.4.12** | Verify that for a given client, the authorization server only allows the 'response_mode' value that this client needs to use. For example, by having the authorization server validate this value against the expected values or by using pushed authorization request (PAR) or JWT-secured Authorization Request (JAR). | 3 | +| **10.4.13** | Verify that grant type 'code' is always used together with pushed authorization requests (PAR). | 3 | +| **10.4.14** | Verify that the authorization server issues only sender-constrained (Proof-of-Possession) access tokens, either with certificate-bound access tokens using mutual TLS (mTLS) or DPoP-bound access tokens (Demonstration of Proof of Possession). | 3 | +| **10.4.15** | Verify that, for a server-side client (which is not executed on the end-user device), the authorization server ensures that the 'authorization_details' parameter value is from the client backend and that the user has not tampered with it. For example, by requiring the usage of pushed authorization request (PAR) or JWT-secured Authorization Request (JAR). | 3 | +| **10.4.16** | Verify that the client is confidential and the authorization server requires the use of strong client authentication methods (based on public-key cryptography and resistant to replay attacks), such as mutual TLS ('tls_client_auth', 'self_signed_tls_client_auth') or private key JWT ('private_key_jwt'). | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **10.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ authorization server ਪਹਿਲਾਂ ਤੋਂ ਰਜਿਸਟਰ ਕੀਤੇ URI ਦੀ client-ਵਿਸ਼ੇਸ਼ allowlist ਦੇ ਆਧਾਰ 'ਤੇ ਸਟੀਕ ਸਟ੍ਰਿੰਗ ਤੁਲਨਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ redirect URIs ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ। | 1 | +| **10.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ authorization server ਅਧਿਕਾਰੀਕਰਨ ਜਵਾਬ ਵਿੱਚ authorization code ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਟੋਕਨ ਬੇਨਤੀ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਹੀ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਜਿਹੇ authorization code ਨਾਲ ਦੂਜੀ ਜਾਇਜ਼ ਬੇਨਤੀ ਲਈ ਜੋ ਪਹਿਲਾਂ ਹੀ access token ਜਾਰੀ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾ ਚੁੱਕਾ ਹੈ, authorization server ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਟੋਕਨ ਬੇਨਤੀ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਸ authorization code ਨਾਲ ਸੰਬੰਧਤ ਕੋਈ ਵੀ ਜਾਰੀ ਕੀਤੇ ਟੋਕਨ ਰੱਦ (revoke) ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। | 1 | +| **10.4.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ authorization code ਛੋਟੀ ਮਿਆਦ ਵਾਲਾ (short-lived) ਹੈ। ਵੱਧ ਤੋਂ ਵੱਧ ਜੀਵਨਕਾਲ L1 ਅਤੇ L2 ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ 10 ਮਿੰਟ ਤੱਕ ਅਤੇ L3 ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ 1 ਮਿੰਟ ਤੱਕ ਹੋ ਸਕਦਾ ਹੈ। | 1 | +| **10.4.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਿਸੇ ਦਿੱਤੇ client ਲਈ, authorization server ਸਿਰਫ਼ ਉਹਨਾਂ grants (ਅਧਿਕਾਰੀਕਰਨ ਪ੍ਰਵਾਹ ਦੀਆਂ ਕਿਸਮਾਂ) ਦੀ ਵਰਤੋਂ ਦੀ ਹੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਇਸ client ਨੂੰ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਧਿਆਨ ਦਿਓ ਕਿ 'token' (Implicit flow) ਅਤੇ 'password' (Resource Owner Password Credentials flow) grants ਹੁਣ ਨਹੀਂ ਵਰਤੇ ਜਾਣੇ ਚਾਹੀਦੇ। | 1 | +| **10.4.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ authorization server public clients ਲਈ refresh token ਰੀਪਲੇ ਹਮਲਿਆਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਤਰਜੀਹੀ ਤੌਰ 'ਤੇ ਭੇਜਣਹਾਰ-ਬੰਨ੍ਹੇ refresh tokens ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਭਾਵ, Demonstrating Proof of Possession (DPoP) ਜਾਂ mutual TLS (mTLS) ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ Certificate-Bound Access Tokens। L1 ਅਤੇ L2 ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ, refresh token ਰੋਟੇਸ਼ਨ (rotation) ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਜੇ refresh token ਰੋਟੇਸ਼ਨ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ authorization server ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਵਰਤੋਂ ਤੋਂ ਬਾਅਦ refresh token ਨੂੰ ਅਵੈਧ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜੇ ਪਹਿਲਾਂ ਹੀ ਵਰਤਿਆ ਅਤੇ ਅਵੈਧ ਕੀਤਾ refresh token ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਉਸ ਅਧਿਕਾਰੀਕਰਨ ਲਈ ਸਾਰੇ refresh tokens ਰੱਦ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। | 1 | +| **10.4.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਜੇ code grant ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ authorization server proof key for code exchange (PKCE) ਦੀ ਮੰਗ ਕਰਕੇ authorization code ਇੰਟਰਸੈਪਸ਼ਨ (interception) ਹਮਲਿਆਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਅਧਿਕਾਰੀਕਰਨ ਬੇਨਤੀਆਂ ਲਈ, authorization server ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਇੱਕ ਜਾਇਜ਼ 'code_challenge' ਮੁੱਲ ਦੀ ਮੰਗ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ 'plain' ਦੇ 'code_challenge_method' ਮੁੱਲ ਨੂੰ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਟੋਕਨ ਬੇਨਤੀ ਲਈ, ਇਸ ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ 'code_verifier' ਪੈਰਾਮੀਟਰ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਮੰਗ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। | 2 | +| **10.4.7** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜੇ authorization server ਬਿਨਾਂ ਪ੍ਰਮਾਣੀਕਰਨ ਦੇ ਗਤੀਸ਼ੀਲ client ਰਜਿਸਟ੍ਰੇਸ਼ਨ (unauthenticated dynamic client registration) ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਖ਼ਤਰਨਾਕ client ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਜੋਖਮ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਇਸ ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ client ਮੈਟਾਡਾਟਾ, ਜਿਵੇਂ ਕਿ ਕੋਈ ਵੀ ਰਜਿਸਟਰ ਕੀਤੇ URI, ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਉਪਭੋਗਤਾ ਦੀ ਸਹਿਮਤੀ ਯਕੀਨੀ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਕਿਸੇ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ client ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਅਧਿਕਾਰੀਕਰਨ ਬੇਨਤੀ ਨੂੰ ਪ੍ਰੋਸੈੱਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਚੇਤਾਵਨੀ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ। | 2 | +| **10.4.8** | ਤਸਦੀਕ ਕਰੋ ਕਿ refresh tokens ਦੀ ਇੱਕ ਨਿਰਪੇਖ ਮਿਆਦ-ਸਮਾਪਤੀ (absolute expiration) ਹੈ, ਭਾਵੇਂ ਸਲਾਈਡਿੰਗ (sliding) refresh token ਮਿਆਦ-ਸਮਾਪਤੀ ਲਾਗੂ ਕੀਤੀ ਗਈ ਹੋਵੇ। | 2 | +| **10.4.9** | ਤਸਦੀਕ ਕਰੋ ਕਿ refresh tokens ਅਤੇ ਹਵਾਲਾ access tokens ਨੂੰ ਇੱਕ ਅਧਿਕਾਰਤ ਉਪਭੋਗਤਾ ਦੁਆਰਾ authorization server ਦੇ ਉਪਭੋਗਤਾ ਇੰਟਰਫ਼ੇਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਜੋ ਖ਼ਤਰਨਾਕ clients ਜਾਂ ਚੋਰੀ ਕੀਤੇ ਟੋਕਨਾਂ ਦੇ ਜੋਖਮ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕੇ। | 2 | +| **10.4.10** | ਤਸਦੀਕ ਕਰੋ ਕਿ confidential client ਦਾ client-ਤੋਂ-authorization server ਬੈਕ-ਚੈਨਲ (backchannel) ਬੇਨਤੀਆਂ, ਜਿਵੇਂ ਕਿ ਟੋਕਨ ਬੇਨਤੀਆਂ, pushed authorization requests (PAR), ਅਤੇ ਟੋਕਨ ਰੱਦ ਕਰਨ ਦੀਆਂ ਬੇਨਤੀਆਂ, ਲਈ ਪ੍ਰਮਾਣੀਕਰਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। | 2 | +| **10.4.11** | ਤਸਦੀਕ ਕਰੋ ਕਿ authorization server ਸੰਰਚਨਾ OAuth client ਨੂੰ ਸਿਰਫ਼ ਲੋੜੀਂਦੇ scopes ਹੀ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ। | 2 | +| **10.4.12** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਿਸੇ ਦਿੱਤੇ client ਲਈ, authorization server ਸਿਰਫ਼ ਉਸ 'response_mode' ਮੁੱਲ ਦੀ ਹੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿਸ ਦੀ ਇਸ client ਨੂੰ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਉਦਾਹਰਨ ਲਈ, authorization server ਦੁਆਰਾ ਇਸ ਮੁੱਲ ਨੂੰ ਉਮੀਦ ਕੀਤੇ ਮੁੱਲਾਂ ਦੇ ਵਿਰੁੱਧ ਪ੍ਰਮਾਣਿਤ ਕਰਵਾ ਕੇ ਜਾਂ pushed authorization request (PAR) ਜਾਂ JWT-secured Authorization Request (JAR) ਦੀ ਵਰਤੋਂ ਕਰਕੇ। | 3 | +| **10.4.13** | ਤਸਦੀਕ ਕਰੋ ਕਿ grant type 'code' ਹਮੇਸ਼ਾ pushed authorization requests (PAR) ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। | 3 | +| **10.4.14** | ਤਸਦੀਕ ਕਰੋ ਕਿ authorization server ਸਿਰਫ਼ ਭੇਜਣਹਾਰ-ਬੰਨ੍ਹੇ (Proof-of-Possession) access tokens ਹੀ ਜਾਰੀ ਕਰਦਾ ਹੈ, ਜਾਂ ਤਾਂ mutual TLS (mTLS) ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਸਰਟੀਫ਼ਿਕੇਟ-ਬੰਨ੍ਹੇ (certificate-bound) access tokens ਨਾਲ ਜਾਂ DPoP-ਬੰਨ੍ਹੇ access tokens (Demonstration of Proof of Possession) ਨਾਲ। | 3 | +| **10.4.15** | ਤਸਦੀਕ ਕਰੋ ਕਿ, ਇੱਕ ਸਰਵਰ-ਸਾਈਡ client (ਜੋ ਅੰਤਮ-ਉਪਭੋਗਤਾ ਦੀ ਡਿਵਾਈਸ 'ਤੇ ਨਹੀਂ ਚਲਾਇਆ ਜਾਂਦਾ) ਲਈ, authorization server ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ 'authorization_details' ਪੈਰਾਮੀਟਰ ਮੁੱਲ client ਬੈਕਐਂਡ ਤੋਂ ਹੈ ਅਤੇ ਉਪਭੋਗਤਾ ਨੇ ਇਸ ਨਾਲ ਛੇੜਛਾੜ ਨਹੀਂ ਕੀਤੀ। ਉਦਾਹਰਨ ਲਈ, pushed authorization request (PAR) ਜਾਂ JWT-secured Authorization Request (JAR) ਦੀ ਵਰਤੋਂ ਦੀ ਮੰਗ ਕਰਕੇ। | 3 | +| **10.4.16** | ਤਸਦੀਕ ਕਰੋ ਕਿ client confidential ਹੈ ਅਤੇ authorization server ਮਜ਼ਬੂਤ client ਪ੍ਰਮਾਣੀਕਰਨ ਵਿਧੀਆਂ (ਜਨਤਕ-ਕੁੰਜੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ 'ਤੇ ਆਧਾਰਿਤ ਅਤੇ ਰੀਪਲੇ ਹਮਲਿਆਂ ਪ੍ਰਤੀ ਰੋਧਕ) ਦੀ ਵਰਤੋਂ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ mutual TLS ('tls_client_auth', 'self_signed_tls_client_auth') ਜਾਂ private key JWT ('private_key_jwt')। | 3 | + +## V10.5 OIDC Client +## V10.5 OIDC Client (ਓ.ਆਈ.ਡੀ.ਸੀ. ਕਲਾਇੰਟ) + +As the OIDC relying party acts as an OAuth client, the requirements from the section "OAuth Client" apply as well. + +ਕਿਉਂਕਿ OIDC ਨਿਰਭਰ ਧਿਰ ਇੱਕ OAuth client ਵਜੋਂ ਕੰਮ ਕਰਦੀ ਹੈ, "OAuth Client" ਭਾਗ ਦੀਆਂ ਲੋੜਾਂ ਵੀ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ। + +Note that the "Authentication with an Identity Provider" section in the "Authentication" chapter also contains relevant general requirements. + +ਧਿਆਨ ਦਿਓ ਕਿ "ਪ੍ਰਮਾਣੀਕਰਨ" (Authentication) ਅਧਿਆਇ ਦੇ "ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਨਾਲ ਪ੍ਰਮਾਣੀਕਰਨ" (Authentication with an Identity Provider) ਭਾਗ ਵਿੱਚ ਵੀ ਸੰਬੰਧਤ ਆਮ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.5.1** | Verify that the client (as the relying party) mitigates ID Token replay attacks. For example, by ensuring that the 'nonce' claim in the ID Token matches the 'nonce' value sent in the authentication request to the OpenID Provider (in OAuth2 refereed to as the authorization request sent to the authorization server). | 2 | +| **10.5.2** | Verify that the client uniquely identifies the user from ID Token claims, usually the 'sub' claim, which cannot be reassigned to other users (for the scope of an identity provider). | 2 | +| **10.5.3** | Verify that the client rejects attempts by a malicious authorization server to impersonate another authorization server through authorization server metadata. The client must reject authorization server metadata if the issuer URL in the authorization server metadata does not exactly match the pre-configured issuer URL expected by the client. | 2 | +| **10.5.4** | Verify that the client validates that the ID Token is intended to be used for that client (audience) by checking that the 'aud' claim from the token is equal to the 'client_id' value for the client. | 2 | +| **10.5.5** | Verify that, when using OIDC back-channel logout, the relying party mitigates denial of service through forced logout and cross-JWT confusion in the logout flow. The client must verify that the logout token is correctly typed with a value of 'logout+jwt', contains the 'event' claim with the correct member name, and does not contain a 'nonce' claim. Note that it is also recommended to have a short expiration (e.g., 2 minutes). | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **10.5.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ client (ਨਿਰਭਰ ਧਿਰ ਵਜੋਂ) ID Token ਰੀਪਲੇ ਹਮਲਿਆਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇਹ ਯਕੀਨੀ ਬਣਾ ਕੇ ਕਿ ID Token ਵਿੱਚ 'nonce' ਦਾਅਵਾ OpenID Provider ਨੂੰ ਪ੍ਰਮਾਣੀਕਰਨ ਬੇਨਤੀ ਵਿੱਚ ਭੇਜੇ ਗਏ 'nonce' ਮੁੱਲ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ (OAuth2 ਵਿੱਚ ਇਸ ਨੂੰ authorization server ਨੂੰ ਭੇਜੀ ਗਈ ਅਧਿਕਾਰੀਕਰਨ ਬੇਨਤੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ)। | 2 | +| **10.5.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ client ID Token ਦਾਅਵਿਆਂ ਤੋਂ, ਆਮ ਤੌਰ 'ਤੇ 'sub' ਦਾਅਵੇ ਤੋਂ, ਉਪਭੋਗਤਾ ਦੀ ਵਿਲੱਖਣ ਤੌਰ 'ਤੇ ਪਛਾਣ ਕਰਦਾ ਹੈ, ਜਿਸ ਨੂੰ (ਕਿਸੇ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਦੇ ਘੇਰੇ ਵਿੱਚ) ਹੋਰ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਮੁੜ-ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। | 2 | +| **10.5.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ client ਕਿਸੇ ਖ਼ਤਰਨਾਕ authorization server ਦੁਆਰਾ authorization server ਮੈਟਾਡਾਟਾ ਰਾਹੀਂ ਕਿਸੇ ਹੋਰ authorization server ਦੀ ਪਛਾਣ-ਨਕਲ (impersonation) ਕਰਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਜੇ authorization server ਮੈਟਾਡਾਟਾ ਵਿੱਚ ਜਾਰੀਕਰਤਾ (issuer) URL client ਦੁਆਰਾ ਉਮੀਦ ਕੀਤੇ ਪਹਿਲਾਂ ਤੋਂ ਸੰਰਚਿਤ ਜਾਰੀਕਰਤਾ URL ਨਾਲ ਸਟੀਕ ਤੌਰ 'ਤੇ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਤਾਂ client ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ authorization server ਮੈਟਾਡਾਟਾ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। | 2 | +| **10.5.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ client ਇਹ ਜਾਂਚ ਕਰਕੇ ਕਿ ਟੋਕਨ ਦਾ 'aud' ਦਾਅਵਾ client ਦੇ 'client_id' ਮੁੱਲ ਦੇ ਬਰਾਬਰ ਹੈ, ਇਹ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ ਕਿ ID Token ਉਸ client (audience) ਲਈ ਵਰਤੇ ਜਾਣ ਲਈ ਹੈ। | 2 | +| **10.5.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ, OIDC ਬੈਕ-ਚੈਨਲ ਲੌਗਆਊਟ (back-channel logout) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਨਿਰਭਰ ਧਿਰ ਲੌਗਆਊਟ ਪ੍ਰਵਾਹ ਵਿੱਚ ਜ਼ਬਰਦਸਤੀ ਲੌਗਆਊਟ ਰਾਹੀਂ ਸੇਵਾ-ਇਨਕਾਰ ਅਤੇ ਕਰਾਸ-JWT ਉਲਝਣ (cross-JWT confusion) ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ। client ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਤਸਦੀਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ logout token 'logout+jwt' ਮੁੱਲ ਨਾਲ ਸਹੀ ਤਰ੍ਹਾਂ ਟਾਈਪ ਕੀਤਾ ਗਿਆ ਹੈ, ਸਹੀ ਮੈਂਬਰ ਨਾਮ ਨਾਲ 'event' ਦਾਅਵਾ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਅਤੇ 'nonce' ਦਾਅਵਾ ਸ਼ਾਮਲ ਨਹੀਂ ਕਰਦਾ। ਧਿਆਨ ਦਿਓ ਕਿ ਇੱਕ ਛੋਟੀ ਮਿਆਦ-ਸਮਾਪਤੀ (ਜਿਵੇਂ, 2 ਮਿੰਟ) ਰੱਖਣ ਦੀ ਵੀ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। | 2 | + +## V10.6 OpenID Provider +## V10.6 OpenID Provider (ਓਪਨਆਈਡੀ ਪ੍ਰਦਾਤਾ) + +As OpenID Providers act as OAuth authorization servers, the requirements from the section "OAuth Authorization Server" apply as well. + +ਕਿਉਂਕਿ OpenID Providers OAuth authorization servers ਵਜੋਂ ਕੰਮ ਕਰਦੇ ਹਨ, "OAuth Authorization Server" ਭਾਗ ਦੀਆਂ ਲੋੜਾਂ ਵੀ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ। + +Note that if using the ID Token flow (not the code flow), no access tokens are issued, and many of the requirements for OAuth AS are not applicable. + +ਧਿਆਨ ਦਿਓ ਕਿ ਜੇ ID Token flow (code flow ਨਹੀਂ) ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੋਈ access tokens ਜਾਰੀ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ, ਅਤੇ OAuth AS ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਲੋੜਾਂ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀਆਂ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.6.1** | Verify that the OpenID Provider only allows values 'code', 'ciba', 'id_token', or 'id_token code' for response mode. Note that 'code' is preferred over 'id_token code' (the OIDC Hybrid flow), and 'token' (any Implicit flow) must not be used. | 2 | +| **10.6.2** | Verify that the OpenID Provider mitigates denial of service through forced logout. By obtaining explicit confirmation from the end-user or, if present, validating parameters in the logout request (initiated by the relying party), such as the 'id_token_hint'. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **10.6.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ OpenID Provider response mode ਲਈ ਸਿਰਫ਼ 'code', 'ciba', 'id_token', ਜਾਂ 'id_token code' ਮੁੱਲਾਂ ਦੀ ਹੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਧਿਆਨ ਦਿਓ ਕਿ 'code' ਨੂੰ 'id_token code' (OIDC Hybrid flow) ਨਾਲੋਂ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ 'token' (ਕੋਈ ਵੀ Implicit flow) ਨਹੀਂ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ। | 2 | +| **10.6.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ OpenID Provider ਜ਼ਬਰਦਸਤੀ ਲੌਗਆਊਟ ਰਾਹੀਂ ਸੇਵਾ-ਇਨਕਾਰ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਅੰਤਮ-ਉਪਭੋਗਤਾ ਤੋਂ ਸਪੱਸ਼ਟ ਪੁਸ਼ਟੀ ਪ੍ਰਾਪਤ ਕਰਕੇ ਜਾਂ, ਜੇ ਮੌਜੂਦ ਹੋਣ, ਤਾਂ (ਨਿਰਭਰ ਧਿਰ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੀ) ਲੌਗਆਊਟ ਬੇਨਤੀ ਵਿੱਚ ਪੈਰਾਮੀਟਰਾਂ, ਜਿਵੇਂ ਕਿ 'id_token_hint', ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਕੇ। | 2 | + +## V10.7 Consent Management +## V10.7 ਸਹਿਮਤੀ ਪ੍ਰਬੰਧਨ + +These requirements cover the verification of the user's consent by the authorization server. Without proper user consent verification, a malicious actor may obtain permissions on the user's behalf through spoofing or social-engineering. + +ਇਹ ਲੋੜਾਂ authorization server ਦੁਆਰਾ ਉਪਭੋਗਤਾ ਦੀ ਸਹਿਮਤੀ ਦੀ ਤਸਦੀਕ ਨੂੰ ਕਵਰ ਕਰਦੀਆਂ ਹਨ। ਸਹੀ ਉਪਭੋਗਤਾ ਸਹਿਮਤੀ ਤਸਦੀਕ ਤੋਂ ਬਿਨਾਂ, ਕੋਈ ਖ਼ਤਰਨਾਕ ਕਰਤਾ (malicious actor) ਸਪੂਫ਼ਿੰਗ ਜਾਂ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਰਾਹੀਂ ਉਪਭੋਗਤਾ ਦੀ ਤਰਫ਼ੋਂ ਇਜਾਜ਼ਤਾਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **10.7.1** | Verify that the authorization server ensures that the user consents to each authorization request. If the identity of the client cannot be assured, the authorization server must always explicitly prompt the user for consent. | 2 | +| **10.7.2** | Verify that when the authorization server prompts for user consent, it presents sufficient and clear information about what is being consented to. When applicable, this should include the nature of the requested authorizations (typically based on scope, resource server, Rich Authorization Requests (RAR) authorization details), the identity of the authorized application, and the lifetime of these authorizations. | 2 | +| **10.7.3** | Verify that the user can review, modify, and revoke consents which the user has granted through the authorization server. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **10.7.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ authorization server ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਹਰੇਕ ਅਧਿਕਾਰੀਕਰਨ ਬੇਨਤੀ ਲਈ ਸਹਿਮਤੀ ਦਿੰਦਾ ਹੈ। ਜੇ client ਦੀ ਪਛਾਣ ਦਾ ਭਰੋਸਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਤਾਂ authorization server ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਹਮੇਸ਼ਾ ਉਪਭੋਗਤਾ ਤੋਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸਹਿਮਤੀ ਮੰਗਣੀ ਚਾਹੀਦੀ ਹੈ। | 2 | +| **10.7.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਦੋਂ authorization server ਉਪਭੋਗਤਾ ਸਹਿਮਤੀ ਮੰਗਦਾ ਹੈ, ਤਾਂ ਇਹ ਇਸ ਬਾਰੇ ਕਾਫ਼ੀ ਅਤੇ ਸਪੱਸ਼ਟ ਜਾਣਕਾਰੀ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਕਿ ਕਿਸ ਗੱਲ ਲਈ ਸਹਿਮਤੀ ਦਿੱਤੀ ਜਾ ਰਹੀ ਹੈ। ਜਿੱਥੇ ਲਾਗੂ ਹੋਵੇ, ਇਸ ਵਿੱਚ ਬੇਨਤੀ ਕੀਤੇ ਅਧਿਕਾਰੀਕਰਨਾਂ ਦਾ ਸੁਭਾਅ (ਆਮ ਤੌਰ 'ਤੇ scope, resource server, Rich Authorization Requests (RAR) authorization details 'ਤੇ ਆਧਾਰਿਤ), ਅਧਿਕਾਰਤ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਪਛਾਣ, ਅਤੇ ਇਹਨਾਂ ਅਧਿਕਾਰੀਕਰਨਾਂ ਦਾ ਜੀਵਨਕਾਲ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। | 2 | +| **10.7.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ ਉਹਨਾਂ ਸਹਿਮਤੀਆਂ ਦੀ ਸਮੀਖਿਆ ਕਰ ਸਕਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਸੋਧ ਸਕਦਾ ਹੈ, ਅਤੇ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਨੇ authorization server ਰਾਹੀਂ ਦਿੱਤੀਆਂ ਹਨ। | 2 | + +## References +## ਹਵਾਲੇ + +For more information on OAuth, please see: + +OAuth ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਕਿਰਪਾ ਕਰਕੇ ਵੇਖੋ: + +* [oauth.net](https://oauth.net/) +* [OWASP OAuth 2.0 Protocol Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) + +For OAuth-related requirements in ASVS following published and in draft status RFC-s are used: + +ASVS ਵਿੱਚ OAuth-ਸੰਬੰਧੀ ਲੋੜਾਂ ਲਈ ਹੇਠ ਲਿਖੇ ਪ੍ਰਕਾਸ਼ਿਤ ਅਤੇ ਡਰਾਫ਼ਟ ਸਥਿਤੀ ਵਾਲੇ RFC ਵਰਤੇ ਗਏ ਹਨ: + +* [RFC6749 The OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749) +* [RFC6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://datatracker.ietf.org/doc/html/rfc6750) +* [RFC6819 OAuth 2.0 Threat Model and Security Considerations](https://datatracker.ietf.org/doc/html/rfc6819) +* [RFC7636 Proof Key for Code Exchange by OAuth Public Clients](https://datatracker.ietf.org/doc/html/rfc7636) +* [RFC7591 OAuth 2.0 Dynamic Client Registration Protocol](https://datatracker.ietf.org/doc/html/rfc7591) +* [RFC8628 OAuth 2.0 Device Authorization Grant](https://datatracker.ietf.org/doc/html/rfc8628) +* [RFC8707 Resource Indicators for OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc8707) +* [RFC9068 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens](https://datatracker.ietf.org/doc/html/rfc9068) +* [RFC9126 OAuth 2.0 Pushed Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9126) +* [RFC9207 OAuth 2.0 Authorization Server Issuer Identification](https://datatracker.ietf.org/doc/html/rfc9207) +* [RFC9396 OAuth 2.0 Rich Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9396) +* [RFC9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)](https://datatracker.ietf.org/doc/html/rfc9449) +* [RFC9700 Best Current Practice for OAuth 2.0 Security](https://datatracker.ietf.org/doc/html/rfc9700) +* [draft OAuth 2.0 for Browser-Based Applications](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps) +* [draft The OAuth 2.1 Authorization Framework](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12) + +For more information on OpenID Connect, please see: + +OpenID Connect ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਕਿਰਪਾ ਕਰਕੇ ਵੇਖੋ: + +* [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) +* [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-security-profile-2_0-final.html) diff --git a/5.0/pa-IN/0x20-V11-Cryptography.md b/5.0/pa-IN/0x20-V11-Cryptography.md new file mode 100644 index 0000000000..b95bd483b5 --- /dev/null +++ b/5.0/pa-IN/0x20-V11-Cryptography.md @@ -0,0 +1,204 @@ + + + + +# V11 Cryptography +# V11 ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +The objective of this chapter is to define best practices for the general use of cryptography, as well as to instill a fundamental understanding of cryptographic principles and inspire a shift toward more resilient and modern approaches. It encourages the following: + +ਇਸ ਅਧਿਆਇ ਦਾ ਉਦੇਸ਼ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ (cryptography) ਦੀ ਆਮ ਵਰਤੋਂ ਲਈ ਸਭ ਤੋਂ ਚੰਗੇ ਅਮਲਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਹੈ, ਨਾਲ ਹੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਸਿਧਾਂਤਾਂ ਦੀ ਬੁਨਿਆਦੀ ਸਮਝ ਪੈਦਾ ਕਰਨਾ ਅਤੇ ਵਧੇਰੇ ਲਚਕੀਲੀਆਂ ਅਤੇ ਆਧੁਨਿਕ ਪਹੁੰਚਾਂ ਵੱਲ ਤਬਦੀਲੀ ਨੂੰ ਪ੍ਰੇਰਿਤ ਕਰਨਾ ਹੈ। ਇਹ ਹੇਠ ਲਿਖਿਆਂ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ: + +* Implementing robust cryptographic systems that fail securely, adapt to evolving threats, and are future-proof. +* Utilizing cryptographic mechanisms that are both secure and aligned with industry best practices. +* Maintaining a secure cryptographic key management system with appropriate access controls and auditing. +* Regularly evaluating the cryptographic landscape to assess new risks and adapt algorithms accordingly. +* Discovering and managing cryptographic use cases throughout the application's lifecycle to ensure that all cryptographic assets are accounted for and secured. + +* ਮਜ਼ਬੂਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਸਿਸਟਮ ਲਾਗੂ ਕਰਨਾ ਜੋ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਅਸਫਲ ਹੁੰਦੇ ਹਨ (fail securely), ਬਦਲਦੇ ਖ਼ਤਰਿਆਂ ਅਨੁਸਾਰ ਢਲਦੇ ਹਨ, ਅਤੇ ਭਵਿੱਖ-ਸੁਰੱਖਿਅਤ (future-proof) ਹਨ। +* ਅਜਿਹੀਆਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜੋ ਸੁਰੱਖਿਅਤ ਵੀ ਹਨ ਅਤੇ ਉਦਯੋਗ ਦੇ ਸਭ ਤੋਂ ਚੰਗੇ ਅਮਲਾਂ ਨਾਲ ਮੇਲ ਵੀ ਖਾਂਦੀਆਂ ਹਨ। +* ਢੁਕਵੇਂ ਪਹੁੰਚ ਨਿਯੰਤਰਣਾਂ ਅਤੇ ਆਡਿਟਿੰਗ ਦੇ ਨਾਲ ਇੱਕ ਸੁਰੱਖਿਅਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਕੁੰਜੀ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ ਬਣਾਈ ਰੱਖਣਾ। +* ਨਵੇਂ ਜੋਖਮਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਅਤੇ ਉਸ ਅਨੁਸਾਰ ਐਲਗੋਰਿਦਮਾਂ ਨੂੰ ਢਾਲਣ ਲਈ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਹਾਲਾਤ ਦਾ ਨਿਯਮਿਤ ਮੁਲਾਂਕਣ ਕਰਨਾ। +* ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਪੂਰੇ ਜੀਵਨ-ਚੱਕਰ ਦੌਰਾਨ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਦੀ ਖੋਜ ਅਤੇ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਤਾਂ ਜੋ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਸਾਰੀਆਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਸੰਪਤੀਆਂ ਦਾ ਲੇਖਾ-ਜੋਖਾ ਰੱਖਿਆ ਗਿਆ ਹੈ ਅਤੇ ਉਹ ਸੁਰੱਖਿਅਤ ਹਨ। + +In addition to outlining general principles and best practices, this document also provides more in-depth technical information about the requirements in Appendix C - Cryptography Standards. This includes algorithms and modes that are considered "approved" for the purposes of the requirements in this chapter. + +ਆਮ ਸਿਧਾਂਤਾਂ ਅਤੇ ਸਭ ਤੋਂ ਚੰਗੇ ਅਮਲਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦੇਣ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਦਸਤਾਵੇਜ਼ ਅੰਤਿਕਾ C — ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ ਮਿਆਰਾਂ ਵਿੱਚ ਲੋੜਾਂ ਬਾਰੇ ਵਧੇਰੇ ਡੂੰਘੀ ਤਕਨੀਕੀ ਜਾਣਕਾਰੀ ਵੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਉਹ ਐਲਗੋਰਿਦਮ ਅਤੇ ਮੋਡ ਸ਼ਾਮਲ ਹਨ ਜੋ ਇਸ ਅਧਿਆਇ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਮੰਤਵਾਂ ਲਈ "ਪ੍ਰਵਾਨਿਤ" (approved) ਮੰਨੇ ਜਾਂਦੇ ਹਨ। + +Requirements that use cryptography to solve a separate problem, such as secrets management or communications security, will be in different parts of the standard. + +ਉਹ ਲੋੜਾਂ ਜੋ ਕਿਸੇ ਵੱਖਰੀ ਸਮੱਸਿਆ, ਜਿਵੇਂ ਕਿ ਭੇਦ ਪ੍ਰਬੰਧਨ ਜਾਂ ਸੰਚਾਰ ਸੁਰੱਖਿਆ, ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ, ਮਿਆਰ ਦੇ ਵੱਖ-ਵੱਖ ਭਾਗਾਂ ਵਿੱਚ ਹੋਣਗੀਆਂ। + +## V11.1 Cryptographic Inventory and Documentation +## V11.1 ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਇਨਵੈਂਟਰੀ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ + +Applications need to be designed with strong cryptographic architecture to protect data assets according to their classification. Encrypting everything is wasteful; not encrypting anything is legally negligent. A balance must be struck, usually during architectural or high-level design, design sprints, or architectural spikes. Designing cryptography "on the fly" or retrofitting it will inevitably cost much more to implement securely than simply building it in from the start. + +ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਡਾਟਾ ਸੰਪਤੀਆਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਵਰਗੀਕਰਨ ਅਨੁਸਾਰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਲਈ ਮਜ਼ਬੂਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਆਰਕੀਟੈਕਚਰ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਜਾਣ ਦੀ ਲੋੜ ਹੈ। ਹਰ ਚੀਜ਼ ਨੂੰ ਏਨਕ੍ਰਿਪਟ ਕਰਨਾ ਫ਼ਜ਼ੂਲ ਹੈ; ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਏਨਕ੍ਰਿਪਟ ਨਾ ਕਰਨਾ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ ਲਾਪਰਵਾਹੀ ਹੈ। ਇੱਕ ਸੰਤੁਲਨ ਬਣਾਉਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਆਰਕੀਟੈਕਚਰਲ ਜਾਂ ਉੱਚ-ਪੱਧਰੀ ਡਿਜ਼ਾਈਨ, ਡਿਜ਼ਾਈਨ ਸਪ੍ਰਿੰਟਾਂ, ਜਾਂ ਆਰਕੀਟੈਕਚਰਲ ਸਪਾਈਕਾਂ (architectural spikes) ਦੌਰਾਨ। ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ ਨੂੰ "ਮੌਕੇ 'ਤੇ" ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਜਾਂ ਇਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਜੋੜਨਾ (retrofitting), ਇਸਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਬਣਾ ਕੇ ਰੱਖਣ ਦੇ ਮੁਕਾਬਲੇ, ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਨ ਲਈ ਅਟੱਲ ਤੌਰ 'ਤੇ ਕਿਤੇ ਵੱਧ ਮਹਿੰਗਾ ਪਵੇਗਾ। + +It is important to ensure that all cryptographic assets are regularly discovered, inventoried, and assessed. Please see the appendix for more information on how this can be done. + +ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਸਾਰੀਆਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਸੰਪਤੀਆਂ ਦੀ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਖੋਜ ਕੀਤੀ ਜਾਵੇ, ਉਹਨਾਂ ਨੂੰ ਇਨਵੈਂਟਰੀ (inventory) ਵਿੱਚ ਦਰਜ ਕੀਤਾ ਜਾਵੇ, ਅਤੇ ਉਹਨਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤਾ ਜਾਵੇ। ਇਹ ਕਿਵੇਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ ਕਿਰਪਾ ਕਰਕੇ ਅੰਤਿਕਾ ਵੇਖੋ। + +The need to future-proof cryptographic systems against the eventual rise of quantum computing is also critical. Post-Quantum Cryptography (PQC) refers to cryptographic algorithms designed to remain secure against attacks by quantum computers, which are expected to break widely used algorithms such as RSA and elliptic curve cryptography (ECC). + +ਕੁਆਂਟਮ ਕੰਪਿਊਟਿੰਗ (quantum computing) ਦੇ ਅੰਤਮ ਉਭਾਰ ਦੇ ਵਿਰੁੱਧ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਸਿਸਟਮਾਂ ਨੂੰ ਭਵਿੱਖ-ਸੁਰੱਖਿਅਤ ਬਣਾਉਣ ਦੀ ਲੋੜ ਵੀ ਅਤਿ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਪੋਸਟ-ਕੁਆਂਟਮ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ (Post-Quantum Cryptography, PQC) ਉਹਨਾਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਐਲਗੋਰਿਦਮਾਂ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਜੋ ਕੁਆਂਟਮ ਕੰਪਿਊਟਰਾਂ ਦੁਆਰਾ ਹਮਲਿਆਂ ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਅਤ ਰਹਿਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਗਏ ਹਨ; ਕੁਆਂਟਮ ਕੰਪਿਊਟਰਾਂ ਤੋਂ RSA ਅਤੇ ਅੰਡਾਕਾਰ ਵਕਰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ (elliptic curve cryptography, ECC) ਵਰਗੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਂਦੇ ਐਲਗੋਰਿਦਮਾਂ ਨੂੰ ਤੋੜਨ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। + +Please see the appendix for current guidance on vetted PQC primitives and standards. + +ਜਾਂਚੇ-ਪਰਖੇ PQC ਪ੍ਰਿਮਿਟਿਵਾਂ (primitives) ਅਤੇ ਮਿਆਰਾਂ ਬਾਰੇ ਮੌਜੂਦਾ ਮਾਰਗਦਰਸ਼ਨ ਲਈ ਕਿਰਪਾ ਕਰਕੇ ਅੰਤਿਕਾ ਵੇਖੋ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.1.1** | Verify that there is a documented policy for management of cryptographic keys and a cryptographic key lifecycle that follows a key management standard such as NIST SP 800-57. This should include ensuring that keys are not overshared (for example, with more than two entities for shared secrets and more than one entity for private keys). | 2 | +| **11.1.2** | Verify that a cryptographic inventory is performed, maintained, regularly updated, and includes all cryptographic keys, algorithms, and certificates used by the application. It must also document where keys can and cannot be used in the system, and the types of data that can and cannot be protected using the keys. | 2 | +| **11.1.3** | Verify that cryptographic discovery mechanisms are employed to identify all instances of cryptography in the system, including encryption, hashing, and signing operations. | 3 | +| **11.1.4** | Verify that a cryptographic inventory is maintained. This must include a documented plan that outlines the migration path to new cryptographic standards, such as post-quantum cryptography, in order to react to future threats. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **11.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਕੁੰਜੀਆਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਨੀਤੀ ਅਤੇ ਇੱਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਕੁੰਜੀ ਜੀਵਨ-ਚੱਕਰ ਮੌਜੂਦ ਹੈ ਜੋ NIST SP 800-57 ਵਰਗੇ ਕੁੰਜੀ ਪ੍ਰਬੰਧਨ ਮਿਆਰ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੁੰਜੀਆਂ ਲੋੜ ਤੋਂ ਵੱਧ ਸਾਂਝੀਆਂ ਨਾ ਕੀਤੀਆਂ ਜਾਣ (ਉਦਾਹਰਨ ਲਈ, ਸਾਂਝੇ ਭੇਦਾਂ ਲਈ ਦੋ ਤੋਂ ਵੱਧ ਇਕਾਈਆਂ ਨਾਲ ਅਤੇ ਨਿੱਜੀ ਕੁੰਜੀਆਂ ਲਈ ਇੱਕ ਤੋਂ ਵੱਧ ਇਕਾਈ ਨਾਲ)। | 2 | +| **11.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਇੱਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਇਨਵੈਂਟਰੀ ਤਿਆਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਬਣਾਈ ਰੱਖੀ ਜਾਂਦੀ ਹੈ, ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਅੱਪਡੇਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਸਾਰੀਆਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਕੁੰਜੀਆਂ, ਐਲਗੋਰਿਦਮ, ਅਤੇ ਸਰਟੀਫ਼ਿਕੇਟ ਸ਼ਾਮਲ ਹਨ। ਇਸ ਵਿੱਚ ਇਹ ਵੀ ਦਸਤਾਵੇਜ਼ ਕੀਤਾ ਜਾਣਾ ਲਾਜ਼ਮੀ ਹੈ ਕਿ ਸਿਸਟਮ ਵਿੱਚ ਕੁੰਜੀਆਂ ਕਿੱਥੇ ਵਰਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਕਿੱਥੇ ਨਹੀਂ, ਅਤੇ ਕੁੰਜੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਸ ਕਿਸਮ ਦੇ ਡਾਟੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਸ ਨੂੰ ਨਹੀਂ। | 2 | +| **11.1.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਿਸਟਮ ਵਿੱਚ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ ਦੀ ਵਰਤੋਂ ਦੀਆਂ ਸਾਰੀਆਂ ਮਿਸਾਲਾਂ (instances) ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਖੋਜ ਪ੍ਰਣਾਲੀਆਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸ ਵਿੱਚ ਏਨਕ੍ਰਿਪਸ਼ਨ, ਹੈਸ਼ਿੰਗ, ਅਤੇ ਦਸਤਖ਼ਤ ਕਰਨ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਸ਼ਾਮਲ ਹਨ। | 3 | +| **11.1.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਇੱਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਇਨਵੈਂਟਰੀ ਬਣਾਈ ਰੱਖੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਯੋਜਨਾ ਸ਼ਾਮਲ ਹੋਣੀ ਲਾਜ਼ਮੀ ਹੈ ਜੋ ਭਵਿੱਖ ਦੇ ਖ਼ਤਰਿਆਂ ਪ੍ਰਤੀ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਨ ਲਈ, ਨਵੇਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਮਿਆਰਾਂ, ਜਿਵੇਂ ਕਿ ਪੋਸਟ-ਕੁਆਂਟਮ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ, ਵੱਲ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮਾਰਗ ਦੀ ਰੂਪਰੇਖਾ ਦਿੰਦੀ ਹੈ। | 3 | + +## V11.2 Secure Cryptography Implementation +## V11.2 ਸੁਰੱਖਿਅਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ ਲਾਗੂਕਰਨ + +This section defines the requirements for the selection, implementation, and ongoing management of core cryptographic algorithms for an application. The objective is to ensure that only robust, industry-accepted cryptographic primitives are deployed, in alignment with current standards (e.g., NIST, ISO/IEC) and best practices. Organizations must ensure that each cryptographic component is selected based on peer-reviewed evidence and practical security testing. + +ਇਹ ਭਾਗ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਮੁੱਖ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਐਲਗੋਰਿਦਮਾਂ ਦੀ ਚੋਣ, ਲਾਗੂਕਰਨ, ਅਤੇ ਨਿਰੰਤਰ ਪ੍ਰਬੰਧਨ ਲਈ ਲੋੜਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਉਦੇਸ਼ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਮੌਜੂਦਾ ਮਿਆਰਾਂ (ਜਿਵੇਂ, NIST, ISO/IEC) ਅਤੇ ਸਭ ਤੋਂ ਚੰਗੇ ਅਮਲਾਂ ਦੇ ਅਨੁਸਾਰ, ਸਿਰਫ਼ ਮਜ਼ਬੂਤ, ਉਦਯੋਗ-ਪ੍ਰਵਾਨਿਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਪ੍ਰਿਮਿਟਿਵ ਹੀ ਤਾਇਨਾਤ ਕੀਤੇ ਜਾਣ। ਸੰਸਥਾਵਾਂ ਲਈ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਲਾਜ਼ਮੀ ਹੈ ਕਿ ਹਰੇਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਹਿੱਸੇ ਦੀ ਚੋਣ ਸਾਥੀ-ਸਮੀਖਿਅਤ (peer-reviewed) ਸਬੂਤਾਂ ਅਤੇ ਵਿਹਾਰਕ ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ ਦੇ ਆਧਾਰ 'ਤੇ ਕੀਤੀ ਜਾਵੇ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.2.1** | Verify that industry-validated implementations (including libraries and hardware-accelerated implementations) are used for cryptographic operations. | 2 | +| **11.2.2** | Verify that the application is designed with crypto agility such that random number, authenticated encryption, MAC, or hashing algorithms, key lengths, rounds, ciphers and modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This will allow for seamless upgrades to post-quantum cryptography (PQC), once high-assurance implementations of approved PQC schemes or standards are widely available. | 2 | +| **11.2.3** | Verify that all cryptographic primitives utilize a minimum of 128-bits of security based on the algorithm, key size, and configuration. For example, a 256-bit ECC key provides roughly 128 bits of security where RSA requires a 3072-bit key to achieve 128 bits of security. | 2 | +| **11.2.4** | Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information. | 3 | +| **11.2.5** | Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities, such as Padding Oracle attacks. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **11.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਕਾਰਵਾਈਆਂ ਲਈ ਉਦਯੋਗ-ਪ੍ਰਮਾਣਿਤ ਲਾਗੂਕਰਨ (ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਹਾਰਡਵੇਅਰ-ਤੇਜ਼ ਕੀਤੇ ਲਾਗੂਕਰਨਾਂ ਸਮੇਤ) ਵਰਤੇ ਜਾਂਦੇ ਹਨ। | 2 | +| **11.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕ੍ਰਿਪਟੋ ਚੁਸਤੀ (crypto agility) ਨਾਲ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਬੇਤਰਤੀਬ ਨੰਬਰ, ਪ੍ਰਮਾਣੀਕ੍ਰਿਤ ਏਨਕ੍ਰਿਪਸ਼ਨ (authenticated encryption), MAC, ਜਾਂ ਹੈਸ਼ਿੰਗ ਐਲਗੋਰਿਦਮ, ਕੁੰਜੀ ਲੰਬਾਈਆਂ, ਰਾਊਂਡ, ਸਾਈਫ਼ਰ ਅਤੇ ਮੋਡ ਨੂੰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਟੁੱਟਣ (cryptographic breaks) ਤੋਂ ਬਚਾਅ ਲਈ ਕਿਸੇ ਵੀ ਸਮੇਂ ਮੁੜ-ਸੰਰਚਿਤ, ਅੱਪਗ੍ਰੇਡ, ਜਾਂ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਕੁੰਜੀਆਂ ਅਤੇ ਪਾਸਵਰਡਾਂ ਨੂੰ ਬਦਲਣਾ ਅਤੇ ਡਾਟੇ ਨੂੰ ਮੁੜ-ਏਨਕ੍ਰਿਪਟ ਕਰਨਾ ਵੀ ਸੰਭਵ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਇਹ ਪੋਸਟ-ਕੁਆਂਟਮ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ (PQC) ਵੱਲ ਨਿਰਵਿਘਨ ਅੱਪਗ੍ਰੇਡਾਂ ਦੀ ਆਗਿਆ ਦੇਵੇਗਾ, ਜਦੋਂ ਪ੍ਰਵਾਨਿਤ PQC ਸਕੀਮਾਂ ਜਾਂ ਮਿਆਰਾਂ ਦੇ ਉੱਚ-ਭਰੋਸੇ ਵਾਲੇ ਲਾਗੂਕਰਨ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਹੋ ਜਾਣ। | 2 | +| **11.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਪ੍ਰਿਮਿਟਿਵ ਐਲਗੋਰਿਦਮ, ਕੁੰਜੀ ਆਕਾਰ, ਅਤੇ ਸੰਰਚਨਾ ਦੇ ਆਧਾਰ 'ਤੇ ਘੱਟੋ-ਘੱਟ 128-ਬਿੱਟ ਸੁਰੱਖਿਆ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ 256-ਬਿੱਟ ECC ਕੁੰਜੀ ਲਗਭਗ 128 ਬਿੱਟ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਜਦੋਂ ਕਿ RSA ਨੂੰ 128 ਬਿੱਟ ਸੁਰੱਖਿਆ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ 3072-ਬਿੱਟ ਕੁੰਜੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। | 2 | +| **11.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਾਣਕਾਰੀ ਲੀਕ ਹੋਣ ਤੋਂ ਬਚਣ ਲਈ, ਸਾਰੀਆਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਕਾਰਵਾਈਆਂ ਸਥਿਰ-ਸਮਾਂ (constant-time) ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਤੁਲਨਾਵਾਂ, ਗਣਨਾਵਾਂ, ਜਾਂ ਰਿਟਰਨਾਂ ਵਿੱਚ ਕੋਈ 'ਸ਼ਾਰਟ-ਸਰਕਟ' ਕਾਰਵਾਈਆਂ ਨਹੀਂ ਹਨ। | 3 | +| **11.2.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਮਾਡਿਊਲ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਅਸਫਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਗਲਤੀਆਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ ਜੋ ਕਮਜ਼ੋਰੀਆਂ, ਜਿਵੇਂ ਕਿ ਪੈਡਿੰਗ ਓਰੇਕਲ (Padding Oracle) ਹਮਲਿਆਂ, ਨੂੰ ਸਮਰੱਥ ਨਹੀਂ ਬਣਾਉਂਦਾ। | 3 | + +## V11.3 Encryption Algorithms +## V11.3 ਏਨਕ੍ਰਿਪਸ਼ਨ ਐਲਗੋਰਿਦਮ + +Authenticated encryption algorithms built on AES and CHACHA20 form the backbone of modern cryptographic practice. + +AES ਅਤੇ CHACHA20 'ਤੇ ਬਣੇ ਪ੍ਰਮਾਣੀਕ੍ਰਿਤ ਏਨਕ੍ਰਿਪਸ਼ਨ ਐਲਗੋਰਿਦਮ ਆਧੁਨਿਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਅਮਲ ਦੀ ਰੀੜ੍ਹ ਦੀ ਹੱਡੀ ਬਣਦੇ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.3.1** | Verify that insecure block modes (e.g., ECB) and weak padding schemes (e.g., PKCS#1 v1.5) are not used. | 1 | +| **11.3.2** | Verify that only approved ciphers and modes such as AES with GCM are used. | 1 | +| **11.3.3** | Verify that encrypted data is protected against unauthorized modification preferably by using an approved authenticated encryption method or by combining an approved encryption method with an approved MAC algorithm. | 2 | +| **11.3.4** | Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key and data-element pair. The method of generation must be appropriate for the algorithm being used. | 3 | +| **11.3.5** | Verify that any combination of an encryption algorithm and a MAC algorithm is operating in encrypt-then-MAC mode. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **11.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਅਸੁਰੱਖਿਅਤ ਬਲਾਕ ਮੋਡ (ਜਿਵੇਂ, ECB) ਅਤੇ ਕਮਜ਼ੋਰ ਪੈਡਿੰਗ ਸਕੀਮਾਂ (ਜਿਵੇਂ, PKCS#1 v1.5) ਨਹੀਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ। | 1 | +| **11.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਿਰਫ਼ ਪ੍ਰਵਾਨਿਤ ਸਾਈਫ਼ਰ ਅਤੇ ਮੋਡ, ਜਿਵੇਂ ਕਿ GCM ਦੇ ਨਾਲ AES, ਹੀ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। | 1 | +| **11.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਏਨਕ੍ਰਿਪਟ ਕੀਤਾ ਡਾਟਾ ਅਣਅਧਿਕਾਰਤ ਸੋਧ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੈ, ਤਰਜੀਹੀ ਤੌਰ 'ਤੇ ਇੱਕ ਪ੍ਰਵਾਨਿਤ ਪ੍ਰਮਾਣੀਕ੍ਰਿਤ ਏਨਕ੍ਰਿਪਸ਼ਨ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜਾਂ ਇੱਕ ਪ੍ਰਵਾਨਿਤ ਏਨਕ੍ਰਿਪਸ਼ਨ ਵਿਧੀ ਨੂੰ ਇੱਕ ਪ੍ਰਵਾਨਿਤ MAC ਐਲਗੋਰਿਦਮ ਨਾਲ ਜੋੜ ਕੇ। | 2 | +| **11.3.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਨੌਂਸ (nonce), ਸ਼ੁਰੂਆਤੀ ਵੈਕਟਰ (initialization vector, IV), ਅਤੇ ਹੋਰ ਇੱਕ-ਵਾਰੀ-ਵਰਤੋਂ ਵਾਲੇ ਨੰਬਰ ਇੱਕ ਤੋਂ ਵੱਧ ਏਨਕ੍ਰਿਪਸ਼ਨ ਕੁੰਜੀ ਅਤੇ ਡਾਟਾ-ਤੱਤ ਜੋੜੇ ਲਈ ਨਹੀਂ ਵਰਤੇ ਜਾਂਦੇ। ਉਤਪਾਦਨ ਦੀ ਵਿਧੀ ਵਰਤੇ ਜਾ ਰਹੇ ਐਲਗੋਰਿਦਮ ਲਈ ਢੁਕਵੀਂ ਹੋਣੀ ਲਾਜ਼ਮੀ ਹੈ। | 3 | +| **11.3.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਇੱਕ ਏਨਕ੍ਰਿਪਸ਼ਨ ਐਲਗੋਰਿਦਮ ਅਤੇ ਇੱਕ MAC ਐਲਗੋਰਿਦਮ ਦਾ ਕੋਈ ਵੀ ਸੁਮੇਲ encrypt-then-MAC ਮੋਡ ਵਿੱਚ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। | 3 | + +## V11.4 Hashing and Hash-based Functions +## V11.4 ਹੈਸ਼ਿੰਗ ਅਤੇ ਹੈਸ਼-ਆਧਾਰਿਤ ਫੰਕਸ਼ਨ + +Cryptographic hashes are used in a wide variety of cryptographic protocols, such as digital signatures, HMAC, key derivation functions (KDF), random bit generation, and password storage. The security of the cryptographic system is only as strong as the underlying hash functions used. This section outlines the requirements for using secure hash functions in cryptographic operations. + +ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਹੈਸ਼ (hash) ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਪ੍ਰੋਟੋਕਾਲਾਂ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਡਿਜ਼ੀਟਲ ਦਸਤਖ਼ਤ, HMAC, ਕੁੰਜੀ-ਵਿਉਤਪੱਤੀ ਫੰਕਸ਼ਨ (key derivation function, KDF), ਬੇਤਰਤੀਬ ਬਿੱਟ ਉਤਪਾਦਨ, ਅਤੇ ਪਾਸਵਰਡ ਸਟੋਰੇਜ। ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਸਿਸਟਮ ਦੀ ਸੁਰੱਖਿਆ ਸਿਰਫ਼ ਓਨੀ ਹੀ ਮਜ਼ਬੂਤ ਹੁੰਦੀ ਹੈ ਜਿੰਨੇ ਵਰਤੇ ਗਏ ਅੰਤਰੀਵ ਹੈਸ਼ ਫੰਕਸ਼ਨ। ਇਹ ਭਾਗ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਹੈਸ਼ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਲਈ ਲੋੜਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦਿੰਦਾ ਹੈ। + +For password storage, as well as the cryptography appendix, the [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#password-hashing-algorithms) will also provide useful context and guidance. + +ਪਾਸਵਰਡ ਸਟੋਰੇਜ ਲਈ, ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ ਅੰਤਿਕਾ ਦੇ ਨਾਲ-ਨਾਲ, [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#password-hashing-algorithms) ਵੀ ਉਪਯੋਗੀ ਸੰਦਰਭ ਅਤੇ ਮਾਰਗਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰੇਗੀ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.4.1** | Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. Disallowed hash functions, such as MD5, must not be used for any cryptographic purpose. | 1 | +| **11.4.2** | Verify that passwords are stored using an approved, computationally intensive, key derivation function (also known as a "password hashing function"), with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks sufficiently challenging for the required level of security. | 2 | +| **11.4.3** | Verify that hash functions used in digital signatures, as part of data authentication or data integrity are collision resistant and have appropriate bit-lengths. If collision resistance is required, the output length must be at least 256 bits. If only resistance to second pre-image attacks is required, the output length must be at least 128 bits. | 2 | +| **11.4.4** | Verify that the application uses approved key derivation functions with key stretching parameters when deriving secret keys from passwords. The parameters in use must balance security and performance to prevent brute-force attacks from compromising the resulting cryptographic key. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **11.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਆਮ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਲਈ, ਜਿਸ ਵਿੱਚ ਡਿਜ਼ੀਟਲ ਦਸਤਖ਼ਤ, HMAC, KDF, ਅਤੇ ਬੇਤਰਤੀਬ ਬਿੱਟ ਉਤਪਾਦਨ ਸ਼ਾਮਲ ਹਨ, ਸਿਰਫ਼ ਪ੍ਰਵਾਨਿਤ ਹੈਸ਼ ਫੰਕਸ਼ਨ ਹੀ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਮਨਾਹੀ ਵਾਲੇ ਹੈਸ਼ ਫੰਕਸ਼ਨ, ਜਿਵੇਂ ਕਿ MD5, ਕਿਸੇ ਵੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਮੰਤਵ ਲਈ ਨਹੀਂ ਵਰਤੇ ਜਾਣੇ ਚਾਹੀਦੇ। | 1 | +| **11.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪਾਸਵਰਡ ਇੱਕ ਪ੍ਰਵਾਨਿਤ, ਗਣਨਾਤਮਕ ਤੌਰ 'ਤੇ ਭਾਰੀ, ਕੁੰਜੀ-ਵਿਉਤਪੱਤੀ ਫੰਕਸ਼ਨ (ਜਿਸਨੂੰ "ਪਾਸਵਰਡ ਹੈਸ਼ਿੰਗ ਫੰਕਸ਼ਨ" ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਦੀਆਂ ਪੈਰਾਮੀਟਰ ਸੈਟਿੰਗਾਂ ਮੌਜੂਦਾ ਮਾਰਗਦਰਸ਼ਨ ਦੇ ਆਧਾਰ 'ਤੇ ਕੌਨਫ਼ਿਗਰ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਸੈਟਿੰਗਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸੰਤੁਲਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਸੁਰੱਖਿਆ ਦੇ ਲੋੜੀਂਦੇ ਪੱਧਰ ਲਈ ਬਰੂਟ ਫੋਰਸ ਹਮਲਿਆਂ ਨੂੰ ਕਾਫ਼ੀ ਚੁਣੌਤੀਪੂਰਨ ਬਣਾਇਆ ਜਾ ਸਕੇ। | 2 | +| **11.4.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਡਿਜ਼ੀਟਲ ਦਸਤਖ਼ਤਾਂ ਵਿੱਚ, ਡਾਟਾ ਪ੍ਰਮਾਣੀਕਰਨ ਜਾਂ ਡਾਟਾ ਅਖੰਡਤਾ (integrity) ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਵਰਤੇ ਜਾਂਦੇ ਹੈਸ਼ ਫੰਕਸ਼ਨ ਟੱਕਰ-ਰੋਧਕ (collision resistant) ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਬਿੱਟ-ਲੰਬਾਈਆਂ ਢੁਕਵੀਆਂ ਹਨ। ਜੇ ਟੱਕਰ ਰੋਧਕਤਾ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਆਉਟਪੁੱਟ ਲੰਬਾਈ ਘੱਟੋ-ਘੱਟ 256 ਬਿੱਟ ਹੋਣੀ ਲਾਜ਼ਮੀ ਹੈ। ਜੇ ਸਿਰਫ਼ ਦੂਜੇ ਪ੍ਰੀ-ਇਮੇਜ (second pre-image) ਹਮਲਿਆਂ ਪ੍ਰਤੀ ਰੋਧਕਤਾ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਆਉਟਪੁੱਟ ਲੰਬਾਈ ਘੱਟੋ-ਘੱਟ 128 ਬਿੱਟ ਹੋਣੀ ਲਾਜ਼ਮੀ ਹੈ। | 2 | +| **11.4.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਪਾਸਵਰਡਾਂ ਤੋਂ ਗੁਪਤ ਕੁੰਜੀਆਂ ਵਿਉਤਪੰਨ ਕਰਦੇ ਸਮੇਂ ਕੁੰਜੀ ਸਟ੍ਰੈਚਿੰਗ (key stretching) ਪੈਰਾਮੀਟਰਾਂ ਦੇ ਨਾਲ ਪ੍ਰਵਾਨਿਤ ਕੁੰਜੀ-ਵਿਉਤਪੱਤੀ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਵਰਤੋਂ ਵਿੱਚ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸੰਤੁਲਨ ਰੱਖਣਾ ਲਾਜ਼ਮੀ ਹੈ ਤਾਂ ਜੋ ਬਰੂਟ ਫੋਰਸ ਹਮਲਿਆਂ ਨੂੰ ਨਤੀਜੇ ਵਜੋਂ ਬਣੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਕੁੰਜੀ ਨਾਲ ਸਮਝੌਤਾ ਕਰਨ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕੇ। | 2 | + +## V11.5 Random Values +## V11.5 ਬੇਤਰਤੀਬ ਮੁੱਲ + +Cryptographically secure Pseudo-random Number Generation (CSPRNG) is incredibly difficult to get right. Generally, good sources of entropy within a system will be quickly depleted if over-used, but sources with less randomness can lead to predictable keys and secrets. + +ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਛਦਮ-ਬੇਤਰਤੀਬ ਨੰਬਰ ਉਤਪਾਦਨ (Cryptographically secure Pseudo-random Number Generation, CSPRNG) ਨੂੰ ਸਹੀ ਕਰਨਾ ਬੇਹੱਦ ਮੁਸ਼ਕਲ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਇੱਕ ਸਿਸਟਮ ਦੇ ਅੰਦਰ ਐਂਟਰੋਪੀ (entropy) ਦੇ ਚੰਗੇ ਸਰੋਤ ਲੋੜ ਤੋਂ ਵੱਧ ਵਰਤੇ ਜਾਣ 'ਤੇ ਜਲਦੀ ਖ਼ਤਮ ਹੋ ਜਾਣਗੇ, ਪਰ ਘੱਟ ਬੇਤਰਤੀਬੀ ਵਾਲੇ ਸਰੋਤ ਅਨੁਮਾਨਯੋਗ ਕੁੰਜੀਆਂ ਅਤੇ ਭੇਦਾਂ ਵੱਲ ਲੈ ਜਾ ਸਕਦੇ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.5.1** | Verify that all random numbers and strings which are intended to be non-guessable must be generated using a cryptographically secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy. Note that UUIDs do not respect this condition. | 2 | +| **11.5.2** | Verify that the random number generation mechanism in use is designed to work securely, even under heavy demand. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **11.5.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੇ ਬੇਤਰਤੀਬ ਨੰਬਰ ਅਤੇ ਸਟ੍ਰਿੰਗ ਜਿਨ੍ਹਾਂ ਦਾ ਅਨੁਮਾਨ ਨਾ ਲਗਾਇਆ ਜਾ ਸਕਣਾ ਉਦੇਸ਼ਿਤ ਹੈ, ਇੱਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਛਦਮ-ਬੇਤਰਤੀਬ ਨੰਬਰ ਜਨਰੇਟਰ (CSPRNG) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੈਦਾ ਕੀਤੇ ਜਾਣੇ ਲਾਜ਼ਮੀ ਹਨ ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ 128 ਬਿੱਟ ਐਂਟਰੋਪੀ ਹੋਣੀ ਲਾਜ਼ਮੀ ਹੈ। ਧਿਆਨ ਦਿਓ ਕਿ UUID ਇਸ ਸ਼ਰਤ ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰਦੇ। | 2 | +| **11.5.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਵਰਤੋਂ ਵਿੱਚ ਬੇਤਰਤੀਬ ਨੰਬਰ ਉਤਪਾਦਨ ਪ੍ਰਣਾਲੀ ਭਾਰੀ ਮੰਗ ਦੇ ਅਧੀਨ ਵੀ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤੀ ਗਈ ਹੈ। | 3 | + +## V11.6 Public Key Cryptography +## V11.6 ਜਨਤਕ ਕੁੰਜੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ + +Public Key Cryptography will be used where it is not possible or not desirable to share a secret key between multiple parties. + +ਜਨਤਕ ਕੁੰਜੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ (Public Key Cryptography) ਉੱਥੇ ਵਰਤੀ ਜਾਵੇਗੀ ਜਿੱਥੇ ਕਈ ਧਿਰਾਂ ਵਿਚਕਾਰ ਗੁਪਤ ਕੁੰਜੀ ਸਾਂਝੀ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਜਾਂ ਲੋੜੀਂਦਾ ਨਹੀਂ ਹੈ। + +As part of this, there exists a need for approved key exchange mechanisms, such as Diffie-Hellman and Elliptic Curve Diffie-Hellman (ECDH) to ensure that the cryptosystem remains secure against modern threats. The "Secure Communication" chapter provides requirements for TLS so the requirements in this section are intended for situations where Public Key Cryptography is being used in use cases other than TLS. + +ਇਸਦੇ ਹਿੱਸੇ ਵਜੋਂ, ਪ੍ਰਵਾਨਿਤ ਕੁੰਜੀ ਵਟਾਂਦਰਾ (key exchange) ਪ੍ਰਣਾਲੀਆਂ, ਜਿਵੇਂ ਕਿ Diffie-Hellman ਅਤੇ Elliptic Curve Diffie-Hellman (ECDH), ਦੀ ਲੋੜ ਮੌਜੂਦ ਹੈ ਤਾਂ ਜੋ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਕ੍ਰਿਪਟੋਸਿਸਟਮ ਆਧੁਨਿਕ ਖ਼ਤਰਿਆਂ ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਅਤ ਰਹੇ। "ਸੁਰੱਖਿਅਤ ਸੰਚਾਰ" (Secure Communication) ਅਧਿਆਇ TLS ਲਈ ਲੋੜਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਭਾਗ ਦੀਆਂ ਲੋੜਾਂ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਲਈ ਹਨ ਜਿੱਥੇ ਜਨਤਕ ਕੁੰਜੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ TLS ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਵਰਤੀ ਜਾ ਰਹੀ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.6.1** | Verify that only approved cryptographic algorithms and modes of operation are used for key generation and seeding, and digital signature generation and verification. Key generation algorithms must not generate insecure keys vulnerable to known attacks, for example, RSA keys which are vulnerable to Fermat factorization. | 2 | +| **11.6.2** | Verify that approved cryptographic algorithms are used for key exchange (such as Diffie-Hellman) with a focus on ensuring that key exchange mechanisms use secure parameters. This will prevent attacks on the key establishment process which could lead to adversary-in-the-middle attacks or cryptographic breaks. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **11.6.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕੁੰਜੀ ਉਤਪਾਦਨ ਅਤੇ ਸੀਡਿੰਗ (seeding), ਅਤੇ ਡਿਜ਼ੀਟਲ ਦਸਤਖ਼ਤ ਬਣਾਉਣ ਅਤੇ ਤਸਦੀਕ ਲਈ ਸਿਰਫ਼ ਪ੍ਰਵਾਨਿਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਐਲਗੋਰਿਦਮ ਅਤੇ ਸੰਚਾਲਨ ਮੋਡ (modes of operation) ਹੀ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਕੁੰਜੀ ਉਤਪਾਦਨ ਐਲਗੋਰਿਦਮਾਂ ਨੂੰ ਜਾਣੇ-ਪਛਾਣੇ ਹਮਲਿਆਂ ਪ੍ਰਤੀ ਕਮਜ਼ੋਰ ਅਸੁਰੱਖਿਅਤ ਕੁੰਜੀਆਂ ਨਹੀਂ ਪੈਦਾ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ, ਉਦਾਹਰਨ ਲਈ, RSA ਕੁੰਜੀਆਂ ਜੋ ਫ਼ਰਮਾ ਗੁਣਨਖੰਡੀਕਰਨ (Fermat factorization) ਪ੍ਰਤੀ ਕਮਜ਼ੋਰ ਹਨ। | 2 | +| **11.6.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕੁੰਜੀ ਵਟਾਂਦਰੇ ਲਈ ਪ੍ਰਵਾਨਿਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਐਲਗੋਰਿਦਮ (ਜਿਵੇਂ ਕਿ Diffie-Hellman) ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਗੱਲ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹੋਏ ਕਿ ਕੁੰਜੀ ਵਟਾਂਦਰਾ ਪ੍ਰਣਾਲੀਆਂ ਸੁਰੱਖਿਅਤ ਪੈਰਾਮੀਟਰ ਵਰਤਦੀਆਂ ਹਨ। ਇਹ ਕੁੰਜੀ ਸਥਾਪਨਾ (key establishment) ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕੇਗਾ ਜੋ ਵਿਚਕਾਰਲੇ-ਵਿਰੋਧੀ (adversary-in-the-middle) ਹਮਲਿਆਂ ਜਾਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਟੁੱਟਣ ਵੱਲ ਲੈ ਜਾ ਸਕਦੇ ਹਨ। | 3 | + +## V11.7 In-Use Data Cryptography +## V11.7 ਵਰਤੋਂ-ਅਧੀਨ ਡਾਟਾ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ + +Protecting data while it is being processed is paramount. Techniques such as full memory encryption, encryption of data in transit, and ensuring data is encrypted as quickly as possible after use is recommended. + +ਡਾਟੇ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕੀਤੇ ਜਾਣ ਦੌਰਾਨ ਸੁਰੱਖਿਅਤ ਰੱਖਣਾ ਸਰਵਉੱਚ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ। ਪੂਰੀ ਮੈਮੋਰੀ ਏਨਕ੍ਰਿਪਸ਼ਨ, ਪ੍ਰਸਾਰਣ ਦੌਰਾਨ ਡਾਟੇ (data in transit) ਦੀ ਏਨਕ੍ਰਿਪਸ਼ਨ, ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਵਰਗੀਆਂ ਤਕਨੀਕਾਂ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਵਰਤੋਂ ਤੋਂ ਬਾਅਦ ਡਾਟੇ ਨੂੰ ਜਿੰਨੀ ਜਲਦੀ ਸੰਭਵ ਹੋਵੇ ਏਨਕ੍ਰਿਪਟ ਕੀਤਾ ਜਾਵੇ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **11.7.1** | Verify that full memory encryption is in use that protects sensitive data while it is in use, preventing access by unauthorized users or processes. | 3 | +| **11.7.2** | Verify that data minimization ensures the minimal amount of data is exposed during processing, and ensure that data is encrypted immediately after use or as soon as feasible. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **11.7.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪੂਰੀ ਮੈਮੋਰੀ ਏਨਕ੍ਰਿਪਸ਼ਨ ਵਰਤੋਂ ਵਿੱਚ ਹੈ ਜੋ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਨੂੰ ਉਸਦੀ ਵਰਤੋਂ ਦੌਰਾਨ ਸੁਰੱਖਿਅਤ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਅਣਅਧਿਕਾਰਤ ਉਪਭੋਗਤਾਵਾਂ ਜਾਂ ਪ੍ਰੋਸੈਸਾਂ ਦੁਆਰਾ ਪਹੁੰਚ ਨੂੰ ਰੋਕਦੀ ਹੈ। | 3 | +| **11.7.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਡਾਟਾ ਨਿਊਨਤਮੀਕਰਨ (data minimization) ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਪ੍ਰੋਸੈਸਿੰਗ ਦੌਰਾਨ ਘੱਟੋ-ਘੱਟ ਮਾਤਰਾ ਵਿੱਚ ਡਾਟਾ ਉਜਾਗਰ ਹੋਵੇ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਡਾਟੇ ਨੂੰ ਵਰਤੋਂ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਜਾਂ ਜਿੰਨੀ ਜਲਦੀ ਸੰਭਵ ਹੋਵੇ ਏਨਕ੍ਰਿਪਟ ਕੀਤਾ ਜਾਵੇ। | 3 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [OWASP Web Security Testing Guide: Testing for Weak Cryptography](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography) +* [OWASP Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) +* [FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final) +* [NIST SP 800-57](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final) diff --git a/5.0/pa-IN/0x21-V12-Secure-Communication.md b/5.0/pa-IN/0x21-V12-Secure-Communication.md new file mode 100644 index 0000000000..5844ec7a4e --- /dev/null +++ b/5.0/pa-IN/0x21-V12-Secure-Communication.md @@ -0,0 +1,108 @@ + + + + +# V12 Secure Communication +# V12 ਸੁਰੱਖਿਅਤ ਸੰਚਾਰ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +This chapter includes requirements related to the specific mechanisms that should be in place to protect data in transit, both between an end-user client and a backend service, as well as between internal and backend services. + +ਇਸ ਅਧਿਆਇ ਵਿੱਚ ਉਹਨਾਂ ਖ਼ਾਸ ਪ੍ਰਣਾਲੀਆਂ ਨਾਲ ਸੰਬੰਧਿਤ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ ਜੋ ਡਾਟਾ ਨੂੰ ਪ੍ਰਸਾਰਣ ਦੌਰਾਨ (data in transit) ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਲਈ ਮੌਜੂਦ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ — ਇੱਕ ਅੰਤਮ-ਉਪਭੋਗਤਾ ਕਲਾਇੰਟ ਅਤੇ ਬੈਕਐਂਡ ਸੇਵਾ ਦੇ ਵਿਚਕਾਰ, ਨਾਲ ਹੀ ਅੰਦਰੂਨੀ ਅਤੇ ਬੈਕਐਂਡ ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਵੀ। + +The general concepts promoted by this chapter include: + +ਇਸ ਅਧਿਆਇ ਦੁਆਰਾ ਪ੍ਰਚਾਰਿਤ ਆਮ ਸੰਕਲਪਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: + +* Ensuring that communications are encrypted externally, and ideally internally as well. +* Configuring encryption mechanisms using the latest guidance, including preferred algorithms and ciphers. +* Using signed certificates to ensure that communications are not being intercepted by unauthorized parties. + +* ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ ਸੰਚਾਰ ਬਾਹਰੀ ਤੌਰ 'ਤੇ ਏਨਕ੍ਰਿਪਟ ਕੀਤੇ ਜਾਣ, ਅਤੇ ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਵੀ। +* ਨਵੀਨਤਮ ਮਾਰਗਦਰਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਏਨਕ੍ਰਿਪਸ਼ਨ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਕੌਨਫ਼ਿਗਰ ਕਰਨਾ, ਜਿਸ ਵਿੱਚ ਤਰਜੀਹੀ ਐਲਗੋਰਿਦਮ ਅਤੇ ਸਾਈਫ਼ਰ ਸ਼ਾਮਲ ਹਨ। +* ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਦਸਤਖ਼ਤ ਕੀਤੇ ਸਰਟੀਫ਼ਿਕੇਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਕਿ ਸੰਚਾਰ ਅਣਅਧਿਕਾਰਤ ਧਿਰਾਂ ਦੁਆਰਾ ਰੋਕੇ ਨਹੀਂ ਜਾ ਰਹੇ। + +In addition to outlining general principles and best practices, the ASVS also provides more in-depth technical information about cryptographic strength in Appendix C - Cryptography Standards. + +ਆਮ ਸਿਧਾਂਤਾਂ ਅਤੇ ਸਭ ਤੋਂ ਚੰਗੇ ਅਮਲਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦੇਣ ਤੋਂ ਇਲਾਵਾ, ASVS ਅੰਤਿਕਾ C — ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ ਮਿਆਰਾਂ ਵਿੱਚ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਤਾਕਤ ਬਾਰੇ ਵਧੇਰੇ ਡੂੰਘੀ ਤਕਨੀਕੀ ਜਾਣਕਾਰੀ ਵੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। + +## V12.1 General TLS Security Guidance +## V12.1 ਆਮ TLS ਸੁਰੱਖਿਆ ਮਾਰਗਦਰਸ਼ਨ + +This section provides initial guidance on how to secure TLS communications. Up-to-date tools should be used to review TLS configuration on an ongoing basis. + +ਇਹ ਭਾਗ TLS ਸੰਚਾਰਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਬਾਰੇ ਸ਼ੁਰੂਆਤੀ ਮਾਰਗਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। TLS ਕੌਨਫ਼ਿਗਰੇਸ਼ਨ ਦੀ ਨਿਰੰਤਰ ਆਧਾਰ 'ਤੇ ਸਮੀਖਿਆ ਕਰਨ ਲਈ ਅੱਪ-ਟੂ-ਡੇਟ ਟੂਲਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। + +While the use of wildcard TLS certificates is not inherently insecure, a compromise of a certificate that is deployed across all owned environments (e.g., production, staging, development, and test) may lead to a compromise of the security posture of the applications using it. Proper protection, management, and the use of separate TLS certificates in different environments should be employed if possible. + +ਭਾਵੇਂ ਵਾਈਲਡਕਾਰਡ TLS ਸਰਟੀਫ਼ਿਕੇਟਾਂ ਦੀ ਵਰਤੋਂ ਆਪਣੇ ਆਪ ਵਿੱਚ ਅਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੈ, ਉਹ ਸਰਟੀਫ਼ਿਕੇਟ ਜੋ ਸਾਰੇ ਮਲਕੀਅਤ ਵਾਲੇ ਵਾਤਾਵਰਣਾਂ (ਜਿਵੇਂ, ਪ੍ਰੋਡਕਸ਼ਨ, ਸਟੇਜਿੰਗ, ਡਿਵੈਲਪਮੈਂਟ, ਅਤੇ ਟੈਸਟ) ਵਿੱਚ ਤਾਇਨਾਤ ਹੈ, ਉਸ ਦੇ ਸਮਝੌਤੇ ਨਾਲ ਉਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਸੁਰੱਖਿਆ ਸਥਿਤੀ ਦਾ ਸਮਝੌਤਾ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਸੰਭਵ ਹੋਵੇ, ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਵੱਖਰੇ TLS ਸਰਟੀਫ਼ਿਕੇਟਾਂ ਦੀ ਸਹੀ ਸੁਰੱਖਿਆ, ਪ੍ਰਬੰਧਨ, ਅਤੇ ਵਰਤੋਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **12.1.1** | Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol must be the preferred option. | 1 | +| **12.1.2** | Verify that only recommended cipher suites are enabled, with the strongest cipher suites set as preferred. L3 applications must only support cipher suites which provide forward secrecy. | 2 | +| **12.1.3** | Verify that the application validates that mTLS client certificates are trusted before using the certificate identity for authentication or authorization. | 2 | +| **12.1.4** | Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured. | 3 | +| **12.1.5** | Verify that Encrypted Client Hello (ECH) is enabled in the application's TLS settings to prevent exposure of sensitive metadata, such as the Server Name Indication (SNI), during TLS handshake processes. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **12.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਿਰਫ਼ TLS ਪ੍ਰੋਟੋਕਾਲ ਦੇ ਨਵੀਨਤਮ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੇ ਸੰਸਕਰਣ ਸਮਰੱਥ ਹਨ, ਜਿਵੇਂ ਕਿ TLS 1.2 ਅਤੇ TLS 1.3। TLS ਪ੍ਰੋਟੋਕਾਲ ਦਾ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਤਰਜੀਹੀ ਵਿਕਲਪ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। | 1 | +| **12.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਿਰਫ਼ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੇ ਸਾਈਫ਼ਰ ਸੂਟ ਸਮਰੱਥ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਸਾਈਫ਼ਰ ਸੂਟਾਂ ਨੂੰ ਤਰਜੀਹੀ ਵਜੋਂ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ। L3 ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸਿਰਫ਼ ਉਹਨਾਂ ਸਾਈਫ਼ਰ ਸੂਟਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਅੱਗੇ ਦੀ ਗੁਪਤਤਾ (forward secrecy) ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। | 2 | +| **12.1.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ mTLS ਕਲਾਇੰਟ ਸਰਟੀਫ਼ਿਕੇਟਾਂ ਨੂੰ ਪ੍ਰਮਾਣੀਕਰਨ ਜਾਂ ਅਧਿਕਾਰੀਕਰਨ ਲਈ ਸਰਟੀਫ਼ਿਕੇਟ ਪਛਾਣ ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਮਾਣਿਤ ਕਰਦੀ ਹੈ ਕਿ ਉਹ ਭਰੋਸੇਯੋਗ ਹਨ। | 2 | +| **12.1.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਹੀ ਸਰਟੀਫ਼ਿਕੇਟ ਰੱਦ ਕਰਨ ਦੀ ਪ੍ਰਣਾਲੀ, ਜਿਵੇਂ ਕਿ Online Certificate Status Protocol (OCSP) Stapling, ਸਮਰੱਥ ਅਤੇ ਕੌਨਫ਼ਿਗਰ ਕੀਤੀ ਗਈ ਹੈ। | 3 | +| **12.1.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ Encrypted Client Hello (ECH) ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ TLS ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਸਮਰੱਥ ਹੈ ਤਾਂ ਜੋ TLS ਹੈਂਡਸ਼ੇਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੌਰਾਨ ਸੰਵੇਦਨਸ਼ੀਲ ਮੈਟਾਡਾਟਾ, ਜਿਵੇਂ ਕਿ Server Name Indication (SNI), ਦੇ ਖੁਲਾਸੇ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। | 3 | + +## V12.2 HTTPS Communication with External Facing Services +## V12.2 ਬਾਹਰ-ਮੁਖੀ ਸੇਵਾਵਾਂ ਨਾਲ HTTPS ਸੰਚਾਰ + +Ensure all HTTP traffic to external-facing services which the application exposes is sent encrypted, with publicly trusted certificates. + +ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਉਜਾਗਰ ਕੀਤੀਆਂ ਬਾਹਰ-ਮੁਖੀ ਸੇਵਾਵਾਂ ਨੂੰ ਜਾਣ ਵਾਲਾ ਸਾਰਾ HTTP ਟ੍ਰੈਫ਼ਿਕ ਜਨਤਕ ਤੌਰ 'ਤੇ ਭਰੋਸੇਯੋਗ ਸਰਟੀਫ਼ਿਕੇਟਾਂ ਨਾਲ ਏਨਕ੍ਰਿਪਟ ਕਰਕੇ ਭੇਜਿਆ ਜਾਵੇ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **12.2.1** | Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted communications. | 1 | +| **12.2.2** | Verify that external facing services use publicly trusted TLS certificates. | 1 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **12.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ TLS ਦੀ ਵਰਤੋਂ ਕਲਾਇੰਟ ਅਤੇ ਬਾਹਰ-ਮੁਖੀ, HTTP-ਆਧਾਰਿਤ ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਸਾਰੀ ਕਨੈਕਟੀਵਿਟੀ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਅਸੁਰੱਖਿਅਤ ਜਾਂ ਏਨਕ੍ਰਿਪਟ ਨਾ ਕੀਤੇ ਸੰਚਾਰਾਂ 'ਤੇ ਵਾਪਸ ਨਹੀਂ ਜਾਂਦੀ। | 1 | +| **12.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਬਾਹਰ-ਮੁਖੀ ਸੇਵਾਵਾਂ ਜਨਤਕ ਤੌਰ 'ਤੇ ਭਰੋਸੇਯੋਗ TLS ਸਰਟੀਫ਼ਿਕੇਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ। | 1 | + +## V12.3 General Service to Service Communication Security +## V12.3 ਆਮ ਸੇਵਾ-ਤੋਂ-ਸੇਵਾ ਸੰਚਾਰ ਸੁਰੱਖਿਆ + +Server communications (both internal and external) involve more than just HTTP. Connections to and from other systems must also be secure, ideally using TLS. + +ਸਰਵਰ ਸੰਚਾਰਾਂ (ਅੰਦਰੂਨੀ ਅਤੇ ਬਾਹਰੀ ਦੋਵੇਂ) ਵਿੱਚ HTTP ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਵੀ ਸ਼ਾਮਲ ਹੈ। ਹੋਰ ਸਿਸਟਮਾਂ ਨੂੰ ਅਤੇ ਉਹਨਾਂ ਤੋਂ ਸੰਪਰਕ ਵੀ ਸੁਰੱਖਿਅਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ TLS ਦੀ ਵਰਤੋਂ ਕਰਕੇ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **12.3.1** | Verify that an encrypted protocol such as TLS is used for all inbound and outbound connections to and from the application, including monitoring systems, management tools, remote access and SSH, middleware, databases, mainframes, partner systems, or external APIs. The server must not fall back to insecure or unencrypted protocols. | 2 | +| **12.3.2** | Verify that TLS clients validate certificates received before communicating with a TLS server. | 2 | +| **12.3.3** | Verify that TLS or another appropriate transport encryption mechanism used for all connectivity between internal, HTTP-based services within the application, and does not fall back to insecure or unencrypted communications. | 2 | +| **12.3.4** | Verify that TLS connections between internal services use trusted certificates. Where internally generated or self-signed certificates are used, the consuming service must be configured to only trust specific internal CAs and specific self-signed certificates. | 2 | +| **12.3.5** | Verify that services communicating internally within a system (intra-service communications) use strong authentication to ensure that each endpoint is verified. Strong authentication methods, such as TLS client authentication, must be employed to ensure identity, using public-key infrastructure and mechanisms that are resistant to replay attacks. For microservice architectures, consider using a service mesh to simplify certificate management and enhance security. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **12.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਇੱਕ ਏਨਕ੍ਰਿਪਟ ਕੀਤੇ ਪ੍ਰੋਟੋਕਾਲ ਜਿਵੇਂ ਕਿ TLS ਦੀ ਵਰਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਤੇ ਉਸ ਤੋਂ ਸਾਰੇ ਅੰਦਰ-ਆਉਣ ਵਾਲੇ ਅਤੇ ਬਾਹਰ-ਜਾਣ ਵਾਲੇ ਸੰਪਰਕਾਂ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਨਿਗਰਾਨੀ ਸਿਸਟਮ, ਪ੍ਰਬੰਧਨ ਟੂਲ, ਰਿਮੋਟ ਪਹੁੰਚ ਅਤੇ SSH, ਮਿਡਲਵੇਅਰ, ਡਾਟਾਬੇਸ, ਮੇਨਫ਼੍ਰੇਮ, ਭਾਈਵਾਲ ਸਿਸਟਮ, ਜਾਂ ਬਾਹਰੀ API ਸ਼ਾਮਲ ਹਨ। ਸਰਵਰ ਨੂੰ ਅਸੁਰੱਖਿਅਤ ਜਾਂ ਏਨਕ੍ਰਿਪਟ ਨਾ ਕੀਤੇ ਪ੍ਰੋਟੋਕਾਲਾਂ 'ਤੇ ਵਾਪਸ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ। | 2 | +| **12.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ TLS ਕਲਾਇੰਟ TLS ਸਰਵਰ ਨਾਲ ਸੰਚਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਾਪਤ ਕੀਤੇ ਸਰਟੀਫ਼ਿਕੇਟਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦੇ ਹਨ। | 2 | +| **12.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ TLS ਜਾਂ ਕੋਈ ਹੋਰ ਢੁਕਵੀਂ ਟ੍ਰਾਂਸਪੋਰਟ ਏਨਕ੍ਰਿਪਸ਼ਨ ਪ੍ਰਣਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ ਅੰਦਰੂਨੀ, HTTP-ਆਧਾਰਿਤ ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਸਾਰੀ ਕਨੈਕਟੀਵਿਟੀ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਅਸੁਰੱਖਿਅਤ ਜਾਂ ਏਨਕ੍ਰਿਪਟ ਨਾ ਕੀਤੇ ਸੰਚਾਰਾਂ 'ਤੇ ਵਾਪਸ ਨਹੀਂ ਜਾਂਦੀ। | 2 | +| **12.3.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਅੰਦਰੂਨੀ ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ TLS ਸੰਪਰਕ ਭਰੋਸੇਯੋਗ ਸਰਟੀਫ਼ਿਕੇਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਜਿੱਥੇ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਪੈਦਾ ਕੀਤੇ ਜਾਂ ਸਵੈ-ਦਸਤਖ਼ਤੀ ਸਰਟੀਫ਼ਿਕੇਟ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਉਪਭੋਗ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਨੂੰ ਸਿਰਫ਼ ਖ਼ਾਸ ਅੰਦਰੂਨੀ CA ਅਤੇ ਖ਼ਾਸ ਸਵੈ-ਦਸਤਖ਼ਤੀ ਸਰਟੀਫ਼ਿਕੇਟਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਲਈ ਕੌਨਫ਼ਿਗਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। | 2 | +| **12.3.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਇੱਕ ਸਿਸਟਮ ਦੇ ਅੰਦਰ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਸੰਚਾਰ ਕਰਨ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ (ਇੰਟਰਾ-ਸੇਵਾ ਸੰਚਾਰ) ਮਜ਼ਬੂਤ ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਹਰ ਅੰਤ-ਬਿੰਦੂ ਦੀ ਤਸਦੀਕ ਕੀਤੀ ਜਾਵੇ। ਪਛਾਣ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਮਜ਼ਬੂਤ ਪ੍ਰਮਾਣੀਕਰਨ ਵਿਧੀਆਂ, ਜਿਵੇਂ ਕਿ TLS ਕਲਾਇੰਟ ਪ੍ਰਮਾਣੀਕਰਨ, ਨੂੰ ਨਿਯੁਕਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਨਤਕ-ਕੁੰਜੀ ਬੁਨਿਆਦੀ ਢਾਂਚੇ (PKI) ਅਤੇ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜੋ ਰੀਪਲੇ ਹਮਲਿਆਂ ਪ੍ਰਤੀ ਰੋਧਕ ਹਨ। ਮਾਈਕਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਲਈ, ਸਰਟੀਫ਼ਿਕੇਟ ਪ੍ਰਬੰਧਨ ਨੂੰ ਸਰਲ ਬਣਾਉਣ ਅਤੇ ਸੁਰੱਖਿਆ ਵਧਾਉਣ ਲਈ ਸੇਵਾ ਮੈਸ਼ (service mesh) ਦੀ ਵਰਤੋਂ ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ। | 3 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [OWASP - Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) +* [Mozilla's Server Side TLS configuration guide](https://wiki.mozilla.org/Security/Server_Side_TLS) +* [Mozilla's tool to generate known good TLS configurations](https://ssl-config.mozilla.org/). +* [O-Saft - OWASP Project to validate TLS configuration](https://owasp.org/www-project-o-saft/) diff --git a/5.0/pa-IN/0x22-V13-Configuration.md b/5.0/pa-IN/0x22-V13-Configuration.md new file mode 100644 index 0000000000..76a3e48e21 --- /dev/null +++ b/5.0/pa-IN/0x22-V13-Configuration.md @@ -0,0 +1,132 @@ + + + + +# V13 Configuration +# V13 ਸੰਰਚਨਾ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +The application's default configuration must be secure for use on the Internet. + +ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਡਿਫ਼ਾਲਟ ਸੰਰਚਨਾ (configuration) ਇੰਟਰਨੈੱਟ 'ਤੇ ਵਰਤੋਂ ਲਈ ਸੁਰੱਖਿਅਤ ਹੋਣੀ ਲਾਜ਼ਮੀ ਹੈ। + +This chapter provides guidance on the various configurations necessary to achieve this, including those applied during development, build, and deployment. + +ਇਹ ਅਧਿਆਇ ਇਸ ਨੂੰ ਹਾਸਲ ਕਰਨ ਲਈ ਲੋੜੀਂਦੀਆਂ ਵੱਖ-ਵੱਖ ਸੰਰਚਨਾਵਾਂ ਬਾਰੇ ਮਾਰਗਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਵਿਕਾਸ, ਬਿਲਡ (build), ਅਤੇ ਤਾਇਨਾਤੀ (deployment) ਦੌਰਾਨ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਸੰਰਚਨਾਵਾਂ ਵੀ ਸ਼ਾਮਲ ਹਨ। + +Topics covered include preventing data leakage, securely managing communication between components, and protecting secrets. + +ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਵਿਸ਼ਿਆਂ ਵਿੱਚ ਡਾਟਾ ਲੀਕੇਜ ਨੂੰ ਰੋਕਣਾ, ਘਟਕਾਂ (components) ਦੇ ਵਿਚਕਾਰ ਸੰਚਾਰ ਦਾ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪ੍ਰਬੰਧਨ ਕਰਨਾ, ਅਤੇ ਭੇਦਾਂ (secrets) ਦੀ ਰੱਖਿਆ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ। + +## V13.1 Configuration Documentation +## V13.1 ਸੰਰਚਨਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ + +This section outlines documentation requirements for how the application communicates with internal and external services, as well as techniques to prevent loss of availability due to service inaccessibility. It also addresses documentation related to secrets. + +ਇਹ ਭਾਗ ਇਸ ਬਾਰੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਲੋੜਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦਿੰਦਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਅੰਦਰੂਨੀ ਅਤੇ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਨਾਲ ਕਿਵੇਂ ਸੰਚਾਰ ਕਰਦੀ ਹੈ, ਨਾਲ ਹੀ ਉਹਨਾਂ ਤਕਨੀਕਾਂ ਦੀ ਵੀ ਜੋ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਨਾ ਹੋ ਸਕਣ ਕਾਰਨ ਉਪਲਬਧਤਾ (availability) ਦੇ ਨੁਕਸਾਨ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ। ਇਹ ਭੇਦਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਨੂੰ ਵੀ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **13.1.1** | Verify that all communication needs for the application are documented. This must include external services which the application relies upon and cases where an end user might be able to provide an external location to which the application will then connect. | 2 | +| **13.1.2** | Verify that for each service the application uses, the documentation defines the maximum number of concurrent connections (e.g., connection pool limits) and how the application behaves when that limit is reached, including any fallback or recovery mechanisms, to prevent denial of service conditions. | 3 | +| **13.1.3** | Verify that the application documentation defines resource‑management strategies for every external system or service it uses (e.g., databases, file handles, threads, HTTP connections). This should include resource‑release procedures, timeout settings, failure handling, and where retry logic is implemented, specifying retry limits, delays, and back‑off algorithms. For synchronous HTTP request–response operations it should mandate short timeouts and either disable retries or strictly limit retries to prevent cascading delays and resource exhaustion. | 3 | +| **13.1.4** | Verify that the application's documentation defines the secrets that are critical for the security of the application and a schedule for rotating them, based on the organization's threat model and business requirements. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **13.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਸਾਰੀਆਂ ਸੰਚਾਰ ਲੋੜਾਂ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਵਿੱਚ ਦਰਜ ਹਨ। ਇਸ ਵਿੱਚ ਉਹ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਸ਼ਾਮਲ ਹੋਣੀਆਂ ਲਾਜ਼ਮੀ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਉਹ ਮਾਮਲੇ ਜਿੱਥੇ ਕੋਈ ਅੰਤਮ ਉਪਭੋਗਤਾ ਇੱਕ ਅਜਿਹਾ ਬਾਹਰੀ ਟਿਕਾਣਾ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਫਿਰ ਸੰਪਰਕ ਕਰੇਗੀ। | 2 | +| **13.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਵਰਤੀ ਜਾਂਦੀ ਹਰੇਕ ਸੇਵਾ ਲਈ, ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਸਮਕਾਲੀ ਸੰਪਰਕਾਂ (concurrent connections) ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਗਿਣਤੀ (ਜਿਵੇਂ, ਕਨੈਕਸ਼ਨ ਪੂਲ ਸੀਮਾਵਾਂ) ਅਤੇ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਸੀਮਾ ਪਹੁੰਚਣ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਕਿਵੇਂ ਵਿਹਾਰ ਕਰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਕੋਈ ਵੀ ਫ਼ਾਲਬੈਕ (fallback) ਜਾਂ ਰਿਕਵਰੀ ਪ੍ਰਣਾਲੀਆਂ ਸ਼ਾਮਲ ਹਨ, ਤਾਂ ਜੋ ਸੇਵਾ-ਇਨਕਾਰ (denial of service) ਸਥਿਤੀਆਂ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। | 3 | +| **13.1.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਇਸ ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ ਹਰੇਕ ਬਾਹਰੀ ਸਿਸਟਮ ਜਾਂ ਸੇਵਾ (ਜਿਵੇਂ, ਡਾਟਾਬੇਸ, ਫ਼ਾਈਲ ਹੈਂਡਲ, ਥ੍ਰੈੱਡ, HTTP ਸੰਪਰਕ) ਲਈ ਸਰੋਤ-ਪ੍ਰਬੰਧਨ ਰਣਨੀਤੀਆਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਸਰੋਤ-ਰਿਹਾਈ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਸਮਾਂ-ਸੀਮਾ (timeout) ਸੈਟਿੰਗਾਂ, ਅਸਫਲਤਾ ਸੰਭਾਲ, ਅਤੇ ਜਿੱਥੇ ਮੁੜ-ਕੋਸ਼ਿਸ਼ (retry) ਤਰਕ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ, ਉੱਥੇ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਸੀਮਾਵਾਂ, ਦੇਰੀਆਂ, ਅਤੇ ਬੈਕ-ਆਫ਼ (back-off) ਐਲਗੋਰਿਦਮਾਂ ਦਾ ਨਿਰਧਾਰਨ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਿੰਕ੍ਰੋਨਸ (synchronous) HTTP ਬੇਨਤੀ-ਜਵਾਬ ਕਾਰਜਾਂ ਲਈ ਇਸ ਨੂੰ ਛੋਟੀਆਂ ਸਮਾਂ-ਸੀਮਾਵਾਂ ਲਾਜ਼ਮੀ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਅਤੇ ਲੜੀਵਾਰ (cascading) ਦੇਰੀਆਂ ਅਤੇ ਸਰੋਤ ਖ਼ਤਮ ਹੋ ਜਾਣ ਨੂੰ ਰੋਕਣ ਲਈ ਜਾਂ ਤਾਂ ਮੁੜ-ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਅਸਮਰੱਥ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਮੁੜ-ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਸਖ਼ਤੀ ਨਾਲ ਸੀਮਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। | 3 | +| **13.1.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਉਹਨਾਂ ਭੇਦਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਅਤਿ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਅਤੇ ਸੰਸਥਾ ਦੇ ਖ਼ਤਰਾ ਮਾਡਲ (threat model) ਅਤੇ ਕਾਰੋਬਾਰੀ ਲੋੜਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਰੋਟੇਟ ਕਰਨ ਦੀ ਇੱਕ ਸਮਾਂ-ਸਾਰਣੀ ਵੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। | 3 | + +## V13.2 Backend Communication Configuration +## V13.2 ਬੈਕਐਂਡ ਸੰਚਾਰ ਸੰਰਚਨਾ + +Applications interact with multiple services, including APIs, databases, or other components. These may be considered internal to the application but not included in the application's standard access control mechanisms, or they may be entirely external. In either case, it is necessary to configure the application to interact securely with these components and, if required, protect that configuration. + +ਐਪਲੀਕੇਸ਼ਨਾਂ ਕਈ ਸੇਵਾਵਾਂ ਨਾਲ ਆਪਸੀ ਤਾਲਮੇਲ ਕਰਦੀਆਂ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ API, ਡਾਟਾਬੇਸ, ਜਾਂ ਹੋਰ ਘਟਕ ਸ਼ਾਮਲ ਹਨ। ਇਹਨਾਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰੂਨੀ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ ਪਰ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਮਿਆਰੀ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੇ, ਜਾਂ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਹਰੀ ਹੋ ਸਕਦੇ ਹਨ। ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇਹਨਾਂ ਘਟਕਾਂ ਨਾਲ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਆਪਸੀ ਤਾਲਮੇਲ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕਰਨਾ ਅਤੇ, ਜੇ ਲੋੜ ਹੋਵੇ, ਉਸ ਸੰਰਚਨਾ ਦੀ ਰੱਖਿਆ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। + +Note: The "Secure Communication" chapter provides guidance for encryption in transit. + +ਨੋਟ: "ਸੁਰੱਖਿਅਤ ਸੰਚਾਰ" (Secure Communication) ਅਧਿਆਇ ਪ੍ਰਸਾਰਣ ਦੌਰਾਨ ਏਨਕ੍ਰਿਪਸ਼ਨ (encryption in transit) ਲਈ ਮਾਰਗਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **13.2.1** | Verify that communications between backend application components that don't support the application's standard user session mechanism, including APIs, middleware, and data layers, are authenticated. Authentication must use individual service accounts, short-term tokens, or certificate-based authentication and not unchanging credentials such as passwords, API keys, or shared accounts with privileged access. | 2 | +| **13.2.2** | Verify that communications between backend application components, including local or operating system services, APIs, middleware, and data layers, are performed with accounts assigned the least necessary privileges. | 2 | +| **13.2.3** | Verify that if a credential has to be used for service authentication, the credential being used by the consumer is not a default credential (e.g., root/root or admin/admin). | 2 | +| **13.2.4** | Verify that an allowlist is used to define the external resources or systems with which the application is permitted to communicate (e.g., for outbound requests, data loads, or file access). This allowlist can be implemented at the application layer, web server, firewall, or a combination of different layers. | 2 | +| **13.2.5** | Verify that the web or application server is configured with an allowlist of resources or systems to which the server can send requests or load data or files from. | 2 | +| **13.2.6** | Verify that where the application connects to separate services, it follows the documented configuration for each connection, such as maximum parallel connections, behavior when maximum allowed connections is reached, connection timeouts, and retry strategies. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **13.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਹਨਾਂ ਬੈਕਐਂਡ ਐਪਲੀਕੇਸ਼ਨ ਘਟਕਾਂ ਦੇ ਵਿਚਕਾਰ ਸੰਚਾਰਾਂ ਦਾ ਪ੍ਰਮਾਣੀਕਰਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਮਿਆਰੀ ਉਪਭੋਗਤਾ ਸੈਸ਼ਨ ਪ੍ਰਣਾਲੀ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ API, ਮਿਡਲਵੇਅਰ, ਅਤੇ ਡਾਟਾ ਪਰਤਾਂ ਸ਼ਾਮਲ ਹਨ। ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ ਵਿਅਕਤੀਗਤ ਸੇਵਾ ਖਾਤਿਆਂ (service accounts), ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਟੋਕਨਾਂ, ਜਾਂ ਸਰਟੀਫ਼ਿਕੇਟ-ਆਧਾਰਿਤ ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ, ਨਾ ਕਿ ਨਾ ਬਦਲਣ ਵਾਲੇ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦੀ, ਜਿਵੇਂ ਕਿ ਪਾਸਵਰਡ, API ਕੁੰਜੀਆਂ, ਜਾਂ ਵਿਸ਼ੇਸ਼-ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਪਹੁੰਚ ਵਾਲੇ ਸਾਂਝੇ ਖਾਤੇ। | 2 | +| **13.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਬੈਕਐਂਡ ਐਪਲੀਕੇਸ਼ਨ ਘਟਕਾਂ ਦੇ ਵਿਚਕਾਰ ਸੰਚਾਰ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਸਥਾਨਕ ਜਾਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਸੇਵਾਵਾਂ, API, ਮਿਡਲਵੇਅਰ, ਅਤੇ ਡਾਟਾ ਪਰਤਾਂ ਸ਼ਾਮਲ ਹਨ, ਅਜਿਹੇ ਖਾਤਿਆਂ ਨਾਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਲੋੜੀਂਦੇ ਅਧਿਕਾਰ ਸੌਂਪੇ ਗਏ ਹਨ। | 2 | +| **13.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜੇ ਸੇਵਾ ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ ਕੋਈ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵਰਤਣਾ ਪਵੇ, ਤਾਂ ਖਪਤਕਾਰ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਇੱਕ ਡਿਫ਼ਾਲਟ ਪ੍ਰਮਾਣ-ਪੱਤਰ (default credential) ਨਹੀਂ ਹੈ (ਜਿਵੇਂ, root/root ਜਾਂ admin/admin)। | 2 | +| **13.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਹਨਾਂ ਬਾਹਰੀ ਸਰੋਤਾਂ ਜਾਂ ਸਿਸਟਮਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ ਇੱਕ allowlist ਵਰਤੀ ਜਾਂਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸੰਚਾਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ (ਜਿਵੇਂ, ਬਾਹਰ-ਜਾਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ, ਡਾਟਾ ਲੋਡ, ਜਾਂ ਫ਼ਾਈਲ ਪਹੁੰਚ ਲਈ)। ਇਹ allowlist ਐਪਲੀਕੇਸ਼ਨ ਪਰਤ, ਵੈੱਬ ਸਰਵਰ, ਫ਼ਾਇਰਵਾਲ, ਜਾਂ ਵੱਖ-ਵੱਖ ਪਰਤਾਂ ਦੇ ਸੁਮੇਲ 'ਤੇ ਲਾਗੂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। | 2 | +| **13.2.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਵੈੱਬ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਉਹਨਾਂ ਸਰੋਤਾਂ ਜਾਂ ਸਿਸਟਮਾਂ ਦੀ ਇੱਕ allowlist ਨਾਲ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਰਵਰ ਬੇਨਤੀਆਂ ਭੇਜ ਸਕਦਾ ਹੈ ਜਾਂ ਜਿਨ੍ਹਾਂ ਤੋਂ ਡਾਟਾ ਜਾਂ ਫ਼ਾਈਲਾਂ ਲੋਡ ਕਰ ਸਕਦਾ ਹੈ। | 2 | +| **13.2.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਿੱਥੇ ਐਪਲੀਕੇਸ਼ਨ ਵੱਖਰੀਆਂ ਸੇਵਾਵਾਂ ਨਾਲ ਸੰਪਰਕ ਕਰਦੀ ਹੈ, ਉੱਥੇ ਇਹ ਹਰੇਕ ਸੰਪਰਕ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਸੰਰਚਨਾ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਵੱਧ ਤੋਂ ਵੱਧ ਸਮਾਨਾਂਤਰ ਸੰਪਰਕ, ਵੱਧ ਤੋਂ ਵੱਧ ਇਜਾਜ਼ਤ-ਪ੍ਰਾਪਤ ਸੰਪਰਕਾਂ ਦੀ ਗਿਣਤੀ ਪਹੁੰਚਣ 'ਤੇ ਵਿਹਾਰ, ਸੰਪਰਕ ਸਮਾਂ-ਸੀਮਾਵਾਂ, ਅਤੇ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਰਣਨੀਤੀਆਂ। | 3 | + +## V13.3 Secret Management +## V13.3 ਭੇਦ ਪ੍ਰਬੰਧਨ + +Secret management is an essential configuration task to ensure the protection of data used in the application. Specific requirements for cryptography can be found in the "Cryptography" chapter, but this section focuses on the management and handling aspects of secrets. + +ਭੇਦ ਪ੍ਰਬੰਧਨ (secret management) ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਡਾਟੇ ਦੀ ਰੱਖਿਆ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਇੱਕ ਜ਼ਰੂਰੀ ਸੰਰਚਨਾ ਕਾਰਜ ਹੈ। ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ ਲਈ ਖ਼ਾਸ ਲੋੜਾਂ "ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ" (Cryptography) ਅਧਿਆਇ ਵਿੱਚ ਮਿਲ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਭਾਗ ਭੇਦਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਅਤੇ ਸੰਭਾਲ ਦੇ ਪਹਿਲੂਆਂ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **13.3.1** | Verify that a secrets management solution, such as a key vault, is used to securely create, store, control access to, and destroy backend secrets. These could include passwords, key material, integrations with databases and third-party systems, keys and seeds for time-based tokens, other internal secrets, and API keys. Secrets must not be included in application source code or included in build artifacts. For an L3 application, this must involve a hardware-backed solution such as an HSM. | 2 | +| **13.3.2** | Verify that access to secret assets adheres to the principle of least privilege. | 2 | +| **13.3.3** | Verify that all cryptographic operations are performed using an isolated security module (such as a vault or hardware security module) to securely manage and protect key material from exposure outside of the security module. | 3 | +| **13.3.4** | Verify that secrets are configured to expire and be rotated based on the application's documentation. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **13.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਬੈਕਐਂਡ ਭੇਦਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਬਣਾਉਣ, ਸਟੋਰ ਕਰਨ, ਉਹਨਾਂ ਤੱਕ ਪਹੁੰਚ ਨਿਯੰਤਰਿਤ ਕਰਨ, ਅਤੇ ਨਸ਼ਟ ਕਰਨ ਲਈ ਇੱਕ ਭੇਦ ਪ੍ਰਬੰਧਨ ਹੱਲ, ਜਿਵੇਂ ਕਿ ਕੁੰਜੀ ਵਾਲਟ (key vault), ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚ ਪਾਸਵਰਡ, key material, ਡਾਟਾਬੇਸਾਂ ਅਤੇ ਤੀਜੀ-ਧਿਰ ਸਿਸਟਮਾਂ ਨਾਲ ਏਕੀਕਰਨ, ਸਮਾਂ-ਆਧਾਰਿਤ ਟੋਕਨਾਂ ਲਈ ਕੁੰਜੀਆਂ ਅਤੇ ਸੀਡ, ਹੋਰ ਅੰਦਰੂਨੀ ਭੇਦ, ਅਤੇ API ਕੁੰਜੀਆਂ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਭੇਦਾਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਸਰੋਤ ਕੋਡ ਵਿੱਚ ਜਾਂ ਬਿਲਡ ਆਰਟੀਫ਼ੈਕਟਾਂ (build artifacts) ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ। L3 ਐਪਲੀਕੇਸ਼ਨ ਲਈ, ਇਸ ਵਿੱਚ ਇੱਕ ਹਾਰਡਵੇਅਰ-ਸਮਰਥਿਤ ਹੱਲ, ਜਿਵੇਂ ਕਿ HSM, ਸ਼ਾਮਲ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ। | 2 | +| **13.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਭੇਦ ਸੰਪਤੀਆਂ (secret assets) ਤੱਕ ਪਹੁੰਚ ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ ਦੇ ਸਿਧਾਂਤ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ। | 2 | +| **13.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੀਆਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਕਾਰਵਾਈਆਂ ਇੱਕ ਅਲੱਗ-ਥਲੱਗ ਸੁਰੱਖਿਆ ਮਾਡਿਊਲ (ਜਿਵੇਂ ਕਿ ਵਾਲਟ ਜਾਂ ਹਾਰਡਵੇਅਰ ਸੁਰੱਖਿਆ ਮਾਡਿਊਲ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਜੋ key material ਦਾ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪ੍ਰਬੰਧਨ ਕੀਤਾ ਜਾ ਸਕੇ ਅਤੇ ਇਸ ਨੂੰ ਸੁਰੱਖਿਆ ਮਾਡਿਊਲ ਤੋਂ ਬਾਹਰ ਉਜਾਗਰ ਹੋਣ ਤੋਂ ਬਚਾਇਆ ਜਾ ਸਕੇ। | 3 | +| **13.3.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਭੇਦਾਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਦੇ ਆਧਾਰ 'ਤੇ ਮਿਆਦ ਪੁੱਗਣ ਅਤੇ ਰੋਟੇਟ ਕੀਤੇ ਜਾਣ ਲਈ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। | 3 | + +## V13.4 Unintended Information Leakage +## V13.4 ਅਣਇੱਛਤ ਜਾਣਕਾਰੀ ਲੀਕੇਜ + +Production configurations should be hardened to avoid disclosing unnecessary data. Many of these issues are rarely rated as significant risks but are often chained with other vulnerabilities. If these issues are not present by default, it raises the bar for attacking an application. + +ਪ੍ਰੋਡਕਸ਼ਨ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਬੇਲੋੜੇ ਡਾਟੇ ਦੇ ਖੁਲਾਸੇ ਤੋਂ ਬਚਣ ਲਈ ਸਖ਼ਤ (hardened) ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਮੁੱਦਿਆਂ ਨੂੰ ਘੱਟ ਹੀ ਮਹੱਤਵਪੂਰਨ ਜੋਖਮਾਂ ਵਜੋਂ ਦਰਜਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਹ ਅਕਸਰ ਹੋਰ ਕਮਜ਼ੋਰੀਆਂ ਨਾਲ ਜੋੜ ਕੇ (chained) ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਜੇ ਇਹ ਮੁੱਦੇ ਡਿਫ਼ਾਲਟ ਤੌਰ 'ਤੇ ਮੌਜੂਦ ਨਾ ਹੋਣ, ਤਾਂ ਇਹ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਹਮਲਾ ਕਰਨ ਲਈ ਰੁਕਾਵਟ ਨੂੰ ਉੱਚਾ ਕਰ ਦਿੰਦਾ ਹੈ (raises the bar)। + +For example, hiding the version of server-side components does not eliminate the need to patch all components, and disabling folder listing does not remove the need to use authorization controls or keep files away from the public folder, but it raises the bar. + +ਉਦਾਹਰਨ ਲਈ, ਸਰਵਰ-ਪੱਖੀ ਘਟਕਾਂ ਦਾ ਸੰਸਕਰਣ ਲੁਕਾਉਣਾ ਸਾਰੇ ਘਟਕਾਂ ਨੂੰ ਪੈਚ ਕਰਨ ਦੀ ਲੋੜ ਨੂੰ ਖ਼ਤਮ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਫ਼ੋਲਡਰ ਸੂਚੀਕਰਨ (folder listing) ਨੂੰ ਅਸਮਰੱਥ ਕਰਨਾ ਅਧਿਕਾਰੀਕਰਨ ਨਿਯੰਤਰਣ ਵਰਤਣ ਜਾਂ ਫ਼ਾਈਲਾਂ ਨੂੰ ਜਨਤਕ ਫ਼ੋਲਡਰ ਤੋਂ ਦੂਰ ਰੱਖਣ ਦੀ ਲੋੜ ਨੂੰ ਨਹੀਂ ਹਟਾਉਂਦਾ, ਪਰ ਇਹ ਰੁਕਾਵਟ ਨੂੰ ਉੱਚਾ ਕਰਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **13.4.1** | Verify that the application is deployed either without any source control metadata, including the .git or .svn folders, or in a way that these folders are inaccessible both externally and to the application itself. | 1 | +| **13.4.2** | Verify that debug modes are disabled for all components in production environments to prevent exposure of debugging features and information leakage. | 2 | +| **13.4.3** | Verify that web servers do not expose directory listings to clients unless explicitly intended. | 2 | +| **13.4.4** | Verify that using the HTTP TRACE method is not supported in production environments, to avoid potential information leakage. | 2 | +| **13.4.5** | Verify that documentation (such as for internal APIs) and monitoring endpoints are not exposed unless explicitly intended. | 2 | +| **13.4.6** | Verify that the application does not expose detailed version information of backend components. | 3 | +| **13.4.7** | Verify that the web tier is configured to only serve files with specific file extensions to prevent unintentional information, configuration, and source code leakage. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **13.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਤਾਂ ਬਿਨਾਂ ਕਿਸੇ ਸਰੋਤ ਨਿਯੰਤਰਣ (source control) ਮੈਟਾਡਾਟੇ ਦੇ, ਜਿਸ ਵਿੱਚ .git ਜਾਂ .svn ਫ਼ੋਲਡਰ ਸ਼ਾਮਲ ਹਨ, ਤਾਇਨਾਤ ਕੀਤੀ ਗਈ ਹੈ, ਜਾਂ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕਿ ਇਹ ਫ਼ੋਲਡਰ ਬਾਹਰੀ ਤੌਰ 'ਤੇ ਅਤੇ ਖ਼ੁਦ ਐਪਲੀਕੇਸ਼ਨ ਲਈ, ਦੋਵਾਂ ਲਈ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹਨ। | 1 | +| **13.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਸਾਰੇ ਘਟਕਾਂ ਲਈ ਡੀਬੱਗ (debug) ਮੋਡ ਅਸਮਰੱਥ ਹਨ ਤਾਂ ਜੋ ਡੀਬੱਗਿੰਗ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਉਜਾਗਰ ਹੋਣ ਅਤੇ ਜਾਣਕਾਰੀ ਲੀਕੇਜ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। | 2 | +| **13.4.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਵੈੱਬ ਸਰਵਰ ਕਲਾਇੰਟਾਂ ਨੂੰ ਡਾਇਰੈਕਟਰੀ ਸੂਚੀਕਰਨ (directory listings) ਉਜਾਗਰ ਨਹੀਂ ਕਰਦੇ ਜਦੋਂ ਤੱਕ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਰਾਦਾ ਨਾ ਹੋਵੇ। | 2 | +| **13.4.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੰਭਾਵੀ ਜਾਣਕਾਰੀ ਲੀਕੇਜ ਤੋਂ ਬਚਣ ਲਈ, ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ HTTP TRACE ਮੈਥਡ ਦੀ ਵਰਤੋਂ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ। | 2 | +| **13.4.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਦਸਤਾਵੇਜ਼ (ਜਿਵੇਂ ਕਿ ਅੰਦਰੂਨੀ API ਲਈ) ਅਤੇ ਨਿਗਰਾਨੀ ਅੰਤ-ਬਿੰਦੂ ਉਜਾਗਰ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ ਜਦੋਂ ਤੱਕ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਰਾਦਾ ਨਾ ਹੋਵੇ। | 2 | +| **13.4.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਬੈਕਐਂਡ ਘਟਕਾਂ ਦੀ ਵਿਸਤ੍ਰਿਤ ਸੰਸਕਰਣ ਜਾਣਕਾਰੀ ਉਜਾਗਰ ਨਹੀਂ ਕਰਦੀ। | 3 | +| **13.4.7** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਵੈੱਬ ਟੀਅਰ (web tier) ਨੂੰ ਸਿਰਫ਼ ਖ਼ਾਸ ਫ਼ਾਈਲ ਐਕਸਟੈਂਸ਼ਨਾਂ ਵਾਲੀਆਂ ਫ਼ਾਈਲਾਂ ਹੀ ਪਰੋਸਣ ਲਈ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਤਾਂ ਜੋ ਅਣਇੱਛਤ ਜਾਣਕਾਰੀ, ਸੰਰਚਨਾ, ਅਤੇ ਸਰੋਤ ਕੋਡ ਲੀਕੇਜ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। | 3 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [OWASP Web Security Testing Guide: Configuration and Deployment Management Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing) diff --git a/5.0/pa-IN/0x23-V14-Data-Protection.md b/5.0/pa-IN/0x23-V14-Data-Protection.md new file mode 100644 index 0000000000..5a4207e464 --- /dev/null +++ b/5.0/pa-IN/0x23-V14-Data-Protection.md @@ -0,0 +1,108 @@ + + + + +# V14 Data Protection +# V14 ਡਾਟਾ ਸੁਰੱਖਿਆ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +Applications cannot account for all usage patterns and user behaviors, and should therefore implement controls to limit unauthorized access to sensitive data on client devices. + +ਐਪਲੀਕੇਸ਼ਨਾਂ ਸਾਰੇ ਵਰਤੋਂ ਦੇ ਢੰਗਾਂ ਅਤੇ ਉਪਭੋਗਤਾ ਵਿਵਹਾਰਾਂ ਦਾ ਹਿਸਾਬ ਨਹੀਂ ਰੱਖ ਸਕਦੀਆਂ, ਅਤੇ ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਕਲਾਇੰਟ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ (sensitive data) ਤੱਕ ਅਣਅਧਿਕਾਰਤ ਪਹੁੰਚ ਨੂੰ ਸੀਮਤ ਕਰਨ ਲਈ ਨਿਯੰਤਰਣ ਲਾਗੂ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। + +This chapter includes requirements related to defining what data needs to be protected, how it should be protected, and specific mechanisms to implement or pitfalls to avoid. + +ਇਸ ਅਧਿਆਇ ਵਿੱਚ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਨਾਲ ਸੰਬੰਧਿਤ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ ਕਿ ਕਿਹੜੇ ਡਾਟੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਉਸ ਨੂੰ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਲਾਗੂ ਕਰਨ ਲਈ ਖ਼ਾਸ ਪ੍ਰਣਾਲੀਆਂ ਜਾਂ ਬਚਣ ਯੋਗ ਆਮ ਗ਼ਲਤੀਆਂ (pitfalls) ਕਿਹੜੀਆਂ ਹਨ। + +Another consideration for data protection is bulk extraction, modification, or excessive usage. Each system's requirements are likely to be very different, so determining what is "abnormal" must consider the threat model and business risk. From an ASVS perspective, detecting these issues is handled in the "Security Logging and Error Handling" chapter, and setting limits is handled in the "Validation and Business Logic" chapter. + +ਡਾਟਾ ਸੁਰੱਖਿਆ ਲਈ ਇੱਕ ਹੋਰ ਵਿਚਾਰ ਥੋਕ ਵਿੱਚ ਡਾਟਾ ਕੱਢਣਾ (bulk extraction), ਸੋਧਣਾ, ਜਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਰਤੋਂ ਹੈ। ਹਰ ਸਿਸਟਮ ਦੀਆਂ ਲੋੜਾਂ ਬਹੁਤ ਵੱਖਰੀਆਂ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦੇ ਸਮੇਂ ਕਿ "ਅਸਧਾਰਨ" ਕੀ ਹੈ, ਖ਼ਤਰਾ ਮਾਡਲ (threat model) ਅਤੇ ਕਾਰੋਬਾਰੀ ਜੋਖਮ 'ਤੇ ਵਿਚਾਰ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। ASVS ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ, ਇਹਨਾਂ ਮੁੱਦਿਆਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ "ਸੁਰੱਖਿਆ ਲੌਗਿੰਗ ਅਤੇ ਗਲਤੀ ਪ੍ਰਬੰਧਨ" (Security Logging and Error Handling) ਅਧਿਆਇ ਵਿੱਚ ਸੰਭਾਲਿਆ ਗਿਆ ਹੈ, ਅਤੇ ਸੀਮਾਵਾਂ ਨਿਰਧਾਰਿਤ ਕਰਨਾ "ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਕਾਰੋਬਾਰੀ ਤਰਕ" (Validation and Business Logic) ਅਧਿਆਇ ਵਿੱਚ ਸੰਭਾਲਿਆ ਗਿਆ ਹੈ। + +## V14.1 Data Protection Documentation +## V14.1 ਡਾਟਾ ਸੁਰੱਖਿਆ ਦਸਤਾਵੇਜ਼ੀਕਰਨ + +A key prerequisite for being able to protect data is to categorize what data should be considered sensitive. There are likely to be several different levels of sensitivity, and for each level, the controls required to protect data at that level will be different. + +ਡਾਟੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰ ਸਕਣ ਦੀ ਇੱਕ ਮੁੱਖ ਪੂਰਵ-ਸ਼ਰਤ ਇਹ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਨਾ ਹੈ ਕਿ ਕਿਹੜੇ ਡਾਟੇ ਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸੰਵੇਦਨਸ਼ੀਲਤਾ ਦੇ ਕਈ ਵੱਖ-ਵੱਖ ਪੱਧਰ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ, ਅਤੇ ਹਰੇਕ ਪੱਧਰ ਲਈ, ਉਸ ਪੱਧਰ 'ਤੇ ਡਾਟੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਨਿਯੰਤਰਣ ਵੱਖਰੇ ਹੋਣਗੇ। + +There are various privacy regulations and laws that affect how applications must approach the storage, use, and transmission of sensitive personal information. This section no longer tries to duplicate these types of data protection or privacy legislation, but rather focuses on key technical considerations for protecting sensitive data. Please consult local laws and regulations, and consult a qualified privacy specialist or lawyer as required. + +ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਨਿੱਜਤਾ (privacy) ਨਿਯਮ ਅਤੇ ਕਾਨੂੰਨ ਹਨ ਜੋ ਇਸ ਗੱਲ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ ਕਿ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਨਿੱਜੀ ਜਾਣਕਾਰੀ ਦੇ ਭੰਡਾਰਨ, ਵਰਤੋਂ, ਅਤੇ ਪ੍ਰਸਾਰਣ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਇਹ ਭਾਗ ਹੁਣ ਇਸ ਕਿਸਮ ਦੇ ਡਾਟਾ ਸੁਰੱਖਿਆ ਜਾਂ ਨਿੱਜਤਾ ਕਾਨੂੰਨਾਂ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ, ਸਗੋਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਮੁੱਖ ਤਕਨੀਕੀ ਵਿਚਾਰਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ। ਕਿਰਪਾ ਕਰਕੇ ਸਥਾਨਕ ਕਾਨੂੰਨਾਂ ਅਤੇ ਨਿਯਮਾਂ ਨੂੰ ਵੇਖੋ, ਅਤੇ ਲੋੜ ਅਨੁਸਾਰ ਕਿਸੇ ਯੋਗ ਨਿੱਜਤਾ ਮਾਹਰ ਜਾਂ ਵਕੀਲ ਨਾਲ ਸਲਾਹ ਕਰੋ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **14.1.1** | Verify that all sensitive data created and processed by the application has been identified and classified into protection levels. This includes data that is only encoded and therefore easily decoded, such as Base64 strings or the plaintext payload inside a JWT. Protection levels need to take into account any data protection and privacy regulations and standards which the application is required to comply with. | 2 | +| **14.1.2** | Verify that all sensitive data protection levels have a documented set of protection requirements. This must include (but not be limited to) requirements related to general encryption, integrity verification, retention, how the data is to be logged, access controls around sensitive data in logs, database-level encryption, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **14.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਬਣਾਏ ਅਤੇ ਪ੍ਰੋਸੈਸ ਕੀਤੇ ਸਾਰੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਦੀ ਪਛਾਣ ਕੀਤੀ ਗਈ ਹੈ ਅਤੇ ਉਸ ਨੂੰ ਸੁਰੱਖਿਆ ਪੱਧਰਾਂ ਵਿੱਚ ਵਰਗੀਕ੍ਰਿਤ (ਡਾਟਾ ਵਰਗੀਕਰਨ, data classification) ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਵਿੱਚ ਉਹ ਡਾਟਾ ਸ਼ਾਮਲ ਹੈ ਜੋ ਸਿਰਫ਼ ਏਨਕੋਡ ਕੀਤਾ ਹੋਇਆ ਹੈ ਅਤੇ ਇਸ ਲਈ ਆਸਾਨੀ ਨਾਲ ਡੀਕੋਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ Base64 ਸਟ੍ਰਿੰਗ ਜਾਂ JWT ਦੇ ਅੰਦਰਲਾ ਸਾਦਾ-ਪਾਠ (plaintext) ਪੇਲੋਡ। ਸੁਰੱਖਿਆ ਪੱਧਰਾਂ ਵਿੱਚ ਉਹਨਾਂ ਸਾਰੇ ਡਾਟਾ ਸੁਰੱਖਿਆ ਅਤੇ ਨਿੱਜਤਾ ਨਿਯਮਾਂ ਅਤੇ ਮਿਆਰਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਲੋੜੀਂਦੀ ਹੈ। | 2 | +| **14.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਸੁਰੱਖਿਆ ਪੱਧਰਾਂ ਲਈ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਦਾ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਸੈੱਟ ਮੌਜੂਦ ਹੈ। ਇਸ ਵਿੱਚ ਆਮ ਏਨਕ੍ਰਿਪਸ਼ਨ (encryption), ਅਖੰਡਤਾ (integrity) ਤਸਦੀਕ, ਡਾਟਾ ਧਾਰਨ (data retention), ਡਾਟੇ ਨੂੰ ਕਿਵੇਂ ਲੌਗ ਕੀਤਾ ਜਾਣਾ ਹੈ, ਲੌਗਾਂ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ, ਡਾਟਾਬੇਸ-ਪੱਧਰ ਏਨਕ੍ਰਿਪਸ਼ਨ, ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਨਿੱਜਤਾ ਅਤੇ ਨਿੱਜਤਾ-ਵਧਾਊ ਤਕਨਾਲੋਜੀਆਂ (privacy-enhancing technologies), ਅਤੇ ਹੋਰ ਗੁਪਤਤਾ (confidentiality) ਲੋੜਾਂ ਨਾਲ ਸੰਬੰਧਿਤ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹੋਣੀਆਂ ਲਾਜ਼ਮੀ ਹਨ (ਪਰ ਇਹ ਇਹਨਾਂ ਤੱਕ ਸੀਮਤ ਨਹੀਂ)। | 2 | + +## V14.2 General Data Protection +## V14.2 ਆਮ ਡਾਟਾ ਸੁਰੱਖਿਆ + +This section contains various practical requirements related to the protection of data. Most are specific to particular issues such as unintended data leakage, but there is also a general requirement to implement protection controls based on the protection level required for each data item. + +ਇਸ ਭਾਗ ਵਿੱਚ ਡਾਟੇ ਦੀ ਸੁਰੱਖਿਆ ਨਾਲ ਸੰਬੰਧਿਤ ਕਈ ਵਿਹਾਰਕ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਖ਼ਾਸ ਮੁੱਦਿਆਂ, ਜਿਵੇਂ ਕਿ ਅਣਇੱਛਤ ਡਾਟਾ ਲੀਕੇਜ, ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ, ਪਰ ਹਰੇਕ ਡਾਟਾ ਇਕਾਈ ਲਈ ਲੋੜੀਂਦੇ ਸੁਰੱਖਿਆ ਪੱਧਰ ਦੇ ਆਧਾਰ 'ਤੇ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਲਾਗੂ ਕਰਨ ਦੀ ਇੱਕ ਆਮ ਲੋੜ ਵੀ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **14.2.1** | Verify that sensitive data is only sent to the server in the HTTP message body or header fields, and that the URL and query string do not contain sensitive information, such as an API key or session token. | 1 | +| **14.2.2** | Verify that the application prevents sensitive data from being cached in server components, such as load balancers and application caches, or ensures that the data is securely purged after use. | 2 | +| **14.2.3** | Verify that defined sensitive data is not sent to untrusted parties (e.g., user trackers) to prevent unwanted collection of data outside of the application's control. | 2 | +| **14.2.4** | Verify that controls around sensitive data related to encryption, integrity verification, retention, how the data is to be logged, access controls around sensitive data in logs, privacy and privacy-enhancing technologies, are implemented as defined in the documentation for the specific data's protection level. | 2 | +| **14.2.5** | Verify that caching mechanisms are configured to only cache responses which have the expected content type for that resource and do not contain sensitive, dynamic content. The web server should return a 404 or 302 response when a non-existent file is accessed rather than returning a different, valid file. This should prevent Web Cache Deception attacks. | 3 | +| **14.2.6** | Verify that the application only returns the minimum required sensitive data for the application's functionality. For example, only returning some of the digits of a credit card number and not the full number. If the complete data is required, it should be masked in the user interface unless the user specifically views it. | 3 | +| **14.2.7** | Verify that sensitive information is subject to data retention classification, ensuring that outdated or unnecessary data is deleted automatically, on a defined schedule, or as the situation requires. | 3 | +| **14.2.8** | Verify that sensitive information is removed from the metadata of user-submitted files unless storage is consented to by the user. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **14.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਸਰਵਰ ਨੂੰ ਸਿਰਫ਼ HTTP ਸੁਨੇਹਾ ਬਾਡੀ (message body) ਜਾਂ ਹੈੱਡਰ ਖੇਤਰਾਂ ਵਿੱਚ ਹੀ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ URL ਅਤੇ ਕਿਊਰੀ ਸਟ੍ਰਿੰਗ (query string) ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ, ਜਿਵੇਂ ਕਿ API ਕੁੰਜੀ ਜਾਂ ਸੈਸ਼ਨ ਟੋਕਨ, ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੀ। | 1 | +| **14.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਨੂੰ ਸਰਵਰ ਘਟਕਾਂ, ਜਿਵੇਂ ਕਿ ਲੋਡ ਬੈਲੈਂਸਰ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਕੈਸ਼ (cache), ਵਿੱਚ ਕੈਸ਼ ਹੋਣ ਤੋਂ ਰੋਕਦੀ ਹੈ, ਜਾਂ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਵਰਤੋਂ ਤੋਂ ਬਾਅਦ ਡਾਟੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਮਿਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। | 2 | +| **14.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪਰਿਭਾਸ਼ਿਤ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਧਿਰਾਂ (ਜਿਵੇਂ ਕਿ ਉਪਭੋਗਤਾ ਟ੍ਰੈਕਰ) ਨੂੰ ਨਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ, ਤਾਂ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਿਯੰਤਰਣ ਤੋਂ ਬਾਹਰ ਡਾਟੇ ਦੇ ਅਣਚਾਹੇ ਇਕੱਤਰੀਕਰਨ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। | 2 | +| **14.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਏਨਕ੍ਰਿਪਸ਼ਨ, ਅਖੰਡਤਾ ਤਸਦੀਕ, ਡਾਟਾ ਧਾਰਨ, ਡਾਟੇ ਨੂੰ ਕਿਵੇਂ ਲੌਗ ਕੀਤਾ ਜਾਣਾ ਹੈ, ਲੌਗਾਂ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ, ਨਿੱਜਤਾ ਅਤੇ ਨਿੱਜਤਾ-ਵਧਾਊ ਤਕਨਾਲੋਜੀਆਂ ਨਾਲ ਸੰਬੰਧਿਤ ਨਿਯੰਤਰਣ, ਉਸ ਖ਼ਾਸ ਡਾਟੇ ਦੇ ਸੁਰੱਖਿਆ ਪੱਧਰ ਲਈ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਅਨੁਸਾਰ ਲਾਗੂ ਕੀਤੇ ਗਏ ਹਨ। | 2 | +| **14.2.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕੈਸ਼ਿੰਗ ਪ੍ਰਣਾਲੀਆਂ ਸਿਰਫ਼ ਉਹਨਾਂ ਜਵਾਬਾਂ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਸਮੱਗਰੀ ਕਿਸਮ (content type) ਉਸ ਸਰੋਤ ਲਈ ਉਮੀਦ ਕੀਤੀ ਗਈ ਕਿਸਮ ਹੈ ਅਤੇ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ, ਗਤੀਸ਼ੀਲ ਸਮੱਗਰੀ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ। ਜਦੋਂ ਕਿਸੇ ਮੌਜੂਦ ਨਾ ਹੋਣ ਵਾਲੀ ਫ਼ਾਈਲ ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਵੈੱਬ ਸਰਵਰ ਨੂੰ ਕੋਈ ਵੱਖਰੀ, ਵੈਧ ਫ਼ਾਈਲ ਵਾਪਸ ਕਰਨ ਦੀ ਬਜਾਏ 404 ਜਾਂ 302 ਜਵਾਬ ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਨਾਲ Web Cache Deception ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। | 3 | +| **14.2.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਆਪਣੀ ਕਾਰਜਸ਼ੀਲਤਾ ਲਈ ਸਿਰਫ਼ ਘੱਟੋ-ਘੱਟ ਲੋੜੀਂਦਾ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਹੀ ਵਾਪਸ ਕਰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਨੰਬਰ ਦੇ ਸਿਰਫ਼ ਕੁਝ ਅੰਕ ਵਾਪਸ ਕਰਨਾ, ਨਾ ਕਿ ਪੂਰਾ ਨੰਬਰ। ਜੇ ਪੂਰੇ ਡਾਟੇ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਉਪਭੋਗਤਾ ਇੰਟਰਫ਼ੇਸ ਵਿੱਚ ਮਾਸਕ (mask) ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਉਪਭੋਗਤਾ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਇਸ ਨੂੰ ਨਾ ਵੇਖੇ। | 3 | +| **14.2.7** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਡਾਟਾ ਧਾਰਨ ਵਰਗੀਕਰਨ ਦੇ ਅਧੀਨ ਹੈ, ਜੋ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਪੁਰਾਣਾ ਜਾਂ ਬੇਲੋੜਾ ਡਾਟਾ ਆਪਣੇ ਆਪ, ਇੱਕ ਨਿਰਧਾਰਿਤ ਸਮਾਂ-ਸਾਰਣੀ 'ਤੇ, ਜਾਂ ਸਥਿਤੀ ਦੀ ਲੋੜ ਅਨੁਸਾਰ ਮਿਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। | 3 | +| **14.2.8** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਸੌਂਪੀਆਂ ਫ਼ਾਈਲਾਂ ਦੇ ਮੈਟਾਡਾਟਾ ਵਿੱਚੋਂ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਹਟਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਜਦੋਂ ਤੱਕ ਉਪਭੋਗਤਾ ਨੇ ਇਸ ਦੇ ਭੰਡਾਰਨ ਲਈ ਸਹਿਮਤੀ ਨਾ ਦਿੱਤੀ ਹੋਵੇ। | 3 | + +## V14.3 Client-side Data Protection +## V14.3 ਕਲਾਇੰਟ-ਸਾਈਡ ਡਾਟਾ ਸੁਰੱਖਿਆ + +This section contains requirements preventing data from leaking in specific ways at the client or user agent side of an application. + +ਇਸ ਭਾਗ ਵਿੱਚ ਉਹ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਕਲਾਇੰਟ ਜਾਂ ਯੂਜ਼ਰ ਏਜੰਟ (user agent) ਵਾਲੇ ਪਾਸੇ ਡਾਟੇ ਨੂੰ ਖ਼ਾਸ ਤਰੀਕਿਆਂ ਨਾਲ ਲੀਕ ਹੋਣ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **14.3.1** | Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. The 'Clear-Site-Data' HTTP response header field may be able to help with this but the client-side should also be able to clear up if the server connection is not available when the session is terminated. | 1 | +| **14.3.2** | Verify that the application sets sufficient anti-caching HTTP response header fields (i.e., Cache-Control: no-store) so that sensitive data is not cached in browsers. | 2 | +| **14.3.3** | Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data, with the exception of session tokens. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **14.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਲਾਇੰਟ ਜਾਂ ਸੈਸ਼ਨ ਦੇ ਸਮਾਪਤ ਹੋਣ ਤੋਂ ਬਾਅਦ ਪ੍ਰਮਾਣੀਕ੍ਰਿਤ (authenticated) ਡਾਟਾ ਕਲਾਇੰਟ ਭੰਡਾਰਨ, ਜਿਵੇਂ ਕਿ ਬ੍ਰਾਊਜ਼ਰ DOM, ਵਿੱਚੋਂ ਸਾਫ਼ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। 'Clear-Site-Data' HTTP ਜਵਾਬ ਹੈੱਡਰ ਖੇਤਰ ਇਸ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਸੈਸ਼ਨ ਸਮਾਪਤ ਹੋਣ ਸਮੇਂ ਸਰਵਰ ਕਨੈਕਸ਼ਨ ਉਪਲਬਧ ਨਾ ਹੋਵੇ ਤਾਂ ਕਲਾਇੰਟ-ਸਾਈਡ ਨੂੰ ਵੀ ਆਪਣੇ ਆਪ ਸਾਫ਼ ਕਰ ਸਕਣ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। | 1 | +| **14.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕਾਫ਼ੀ ਕੈਸ਼-ਰੋਕੂ (anti-caching) HTTP ਜਵਾਬ ਹੈੱਡਰ ਖੇਤਰ (ਭਾਵ, Cache-Control: no-store) ਸੈੱਟ ਕਰਦੀ ਹੈ ਤਾਂ ਜੋ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ ਕੈਸ਼ ਨਾ ਹੋਵੇ। | 2 | +| **14.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਭੰਡਾਰਨ (ਜਿਵੇਂ ਕਿ localStorage, sessionStorage, IndexedDB, ਜਾਂ ਕੁਕੀਆਂ) ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਡਾਟੇ ਵਿੱਚ, ਸੈਸ਼ਨ ਟੋਕਨਾਂ ਨੂੰ ਛੱਡ ਕੇ, ਕੋਈ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ। | 2 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [Consider using the Security Headers website to check security and anti-caching header fields](https://securityheaders.com/) +* [Documentation about anti-caching headers by Mozilla](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching) +* [OWASP Secure Headers project](https://owasp.org/www-project-secure-headers/) +* [OWASP Privacy Risks Project](https://owasp.org/www-project-top-10-privacy-risks/) +* [OWASP User Privacy Protection Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) +* [Australian Privacy Principle 11 - Security of personal information](https://www.oaic.gov.au/privacy/australian-privacy-principles/australian-privacy-principles-guidelines/chapter-11-app-11-security-of-personal-information) +* [European Union General Data Protection Regulation (GDPR) overview](https://www.edps.europa.eu/data-protection_en) +* [European Union Data Protection Supervisor - Internet Privacy Engineering Network](https://www.edps.europa.eu/data-protection/ipen-internet-privacy-engineering-network_en) +* [Information on the "Clear-Site-Data" header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data) +* [White paper on Web Cache Deception](https://www.blackhat.com/docs/us-17/wednesday/us-17-Gil-Web-Cache-Deception-Attack-wp.pdf) diff --git a/5.0/pa-IN/0x24-V15-Secure-Coding-and-Architecture.md b/5.0/pa-IN/0x24-V15-Secure-Coding-and-Architecture.md new file mode 100644 index 0000000000..53a032c8b0 --- /dev/null +++ b/5.0/pa-IN/0x24-V15-Secure-Coding-and-Architecture.md @@ -0,0 +1,147 @@ + + + + +# V15 Secure Coding and Architecture +# V15 ਸੁਰੱਖਿਅਤ ਕੋਡਿੰਗ ਅਤੇ ਆਰਕੀਟੈਕਚਰ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +Many ASVS requirements either relate to a particular area of security, such as authentication or authorization, or pertain to a particular type of application functionality, such as logging or file handling. + +ਕਈ ASVS ਲੋੜਾਂ ਜਾਂ ਤਾਂ ਸੁਰੱਖਿਆ ਦੇ ਕਿਸੇ ਖ਼ਾਸ ਖੇਤਰ ਨਾਲ ਸੰਬੰਧਿਤ ਹੁੰਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਜਾਂ ਅਧਿਕਾਰੀਕਰਨ, ਜਾਂ ਕਿਸੇ ਖ਼ਾਸ ਕਿਸਮ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਕਾਰਜਸ਼ੀਲਤਾ ਨਾਲ ਸੰਬੰਧਿਤ ਹੁੰਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਲੌਗਿੰਗ ਜਾਂ ਫ਼ਾਈਲ ਪ੍ਰਬੰਧਨ। + +This chapter provides general security requirements to consider when designing and developing applications. These requirements focus not only on clean architecture and code quality but also on specific architecture and coding practices necessary for application security. + +ਇਹ ਅਧਿਆਇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਅਤੇ ਵਿਕਸਿਤ ਕਰਦੇ ਸਮੇਂ ਵਿਚਾਰਨ ਲਈ ਆਮ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ ਲੋੜਾਂ ਨਾ ਸਿਰਫ਼ ਸਾਫ਼ ਆਰਕੀਟੈਕਚਰ (architecture) ਅਤੇ ਕੋਡ ਗੁਣਵੱਤਾ 'ਤੇ ਕੇਂਦਰਿਤ ਹਨ, ਸਗੋਂ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਲਈ ਜ਼ਰੂਰੀ ਖ਼ਾਸ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਕੋਡਿੰਗ ਅਮਲਾਂ 'ਤੇ ਵੀ ਕੇਂਦਰਿਤ ਹਨ। + +## V15.1 Secure Coding and Architecture Documentation +## V15.1 ਸੁਰੱਖਿਅਤ ਕੋਡਿੰਗ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਦਸਤਾਵੇਜ਼ੀਕਰਨ + +Many requirements for establishing a secure and defensible architecture depend on clear documentation of decisions made regarding the implementation of specific security controls and the components used within the application. + +ਇੱਕ ਸੁਰੱਖਿਅਤ ਅਤੇ ਰੱਖਿਆ-ਯੋਗ ਆਰਕੀਟੈਕਚਰ ਸਥਾਪਿਤ ਕਰਨ ਲਈ ਕਈ ਲੋੜਾਂ ਖ਼ਾਸ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣਾਂ ਦੇ ਲਾਗੂਕਰਨ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ ਵਰਤੇ ਗਏ ਘਟਕਾਂ (components) ਬਾਰੇ ਲਏ ਗਏ ਫ਼ੈਸਲਿਆਂ ਦੇ ਸਪੱਸ਼ਟ ਦਸਤਾਵੇਜ਼ੀਕਰਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ। + +This section outlines the documentation requirements, including identifying components considered to contain "dangerous functionality" or to be "risky components." + +ਇਹ ਭਾਗ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਲੋੜਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਹਨਾਂ ਘਟਕਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ "ਖ਼ਤਰਨਾਕ ਕਾਰਜਸ਼ੀਲਤਾ" (dangerous functionality) ਰੱਖਣ ਵਾਲੇ ਜਾਂ "ਜੋਖਮ ਭਰੇ ਘਟਕ" (risky components) ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। + +A component with "dangerous functionality" may be an internally developed or third-party component that performs operations such as deserialization of untrusted data, raw file or binary data parsing, dynamic code execution, or direct memory manipulation. Vulnerabilities in these types of operations pose a high risk of compromising the application and potentially exposing its underlying infrastructure. + +"ਖ਼ਤਰਨਾਕ ਕਾਰਜਸ਼ੀਲਤਾ" ਵਾਲਾ ਘਟਕ ਇੱਕ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਵਿਕਸਿਤ ਕੀਤਾ ਜਾਂ ਤੀਜੀ-ਧਿਰ ਘਟਕ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਅਜਿਹੀਆਂ ਕਾਰਵਾਈਆਂ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਡਾਟੇ ਦੀ ਡੀਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ (deserialization), ਕੱਚੀ ਫ਼ਾਈਲ ਜਾਂ ਬਾਈਨਰੀ ਡਾਟਾ ਪਾਰਸਿੰਗ (parsing), ਗਤੀਸ਼ੀਲ ਕੋਡ ਚਲਾਉਣਾ (dynamic code execution), ਜਾਂ ਸਿੱਧੀ ਮੈਮੋਰੀ ਹੇਰਾਫੇਰੀ। ਇਸ ਕਿਸਮ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਵਿਚਲੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਸਮਝੌਤਾ ਹੋਣ ਅਤੇ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਇਸ ਦੇ ਅੰਤਰੀਵ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਉਜਾਗਰ ਹੋਣ ਦਾ ਉੱਚ ਜੋਖਮ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। + +A "risky component" is a 3rd party library (i.e., not internally developed) with missing or poorly implemented security controls around its development processes or functionality. Examples include components that are poorly maintained, unsupported, at the end-of-life stage, or have a history of significant vulnerabilities. + +"ਜੋਖਮ ਭਰਿਆ ਘਟਕ" ਇੱਕ ਤੀਜੀ-ਧਿਰ ਲਾਇਬ੍ਰੇਰੀ (ਭਾਵ, ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਵਿਕਸਿਤ ਨਹੀਂ ਕੀਤੀ ਗਈ) ਹੈ ਜਿਸ ਦੀਆਂ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆਵਾਂ ਜਾਂ ਕਾਰਜਸ਼ੀਲਤਾ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਗ਼ਾਇਬ ਹਨ ਜਾਂ ਮਾੜੇ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤੇ ਗਏ ਹਨ। ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਉਹ ਘਟਕ ਸ਼ਾਮਲ ਹਨ ਜੋ ਮਾੜੇ ਢੰਗ ਨਾਲ ਸਾਂਭੇ ਜਾਂਦੇ ਹਨ, ਗ਼ੈਰ-ਸਮਰਥਿਤ ਹਨ, ਜੀਵਨ-ਅੰਤ (end-of-life) ਪੜਾਅ 'ਤੇ ਹਨ, ਜਾਂ ਜਿਨ੍ਹਾਂ ਦਾ ਮਹੱਤਵਪੂਰਨ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਇਤਿਹਾਸ ਹੈ। + +This section also emphasizes the importance of defining appropriate timeframes for addressing vulnerabilities in third-party components. + +ਇਹ ਭਾਗ ਤੀਜੀ-ਧਿਰ ਘਟਕਾਂ ਵਿਚਲੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਢੁਕਵੀਆਂ ਸਮਾਂ-ਮਿਆਦਾਂ (timeframes) ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਮਹੱਤਤਾ 'ਤੇ ਵੀ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **15.1.1** | Verify that application documentation defines risk based remediation time frames for 3rd party component versions with vulnerabilities and for updating libraries in general, to minimize the risk from these components. | 1 | +| **15.1.2** | Verify that an inventory catalog, such as software bill of materials (SBOM), is maintained of all third-party libraries in use, including verifying that components come from pre-defined, trusted, and continually maintained repositories. | 2 | +| **15.1.3** | Verify that the application documentation identifies functionality which is time-consuming or resource-demanding. This must include how to prevent a loss of availability due to overusing this functionality and how to avoid a situation where building a response takes longer than the consumer's timeout. Potential defenses may include asynchronous processing, using queues, and limiting parallel processes per user and per application. | 2 | +| **15.1.4** | Verify that application documentation highlights third-party libraries which are considered to be "risky components". | 3 | +| **15.1.5** | Verify that application documentation highlights parts of the application where "dangerous functionality" is being used. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **15.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਮਜ਼ੋਰੀਆਂ ਵਾਲੇ ਤੀਜੀ-ਧਿਰ ਘਟਕ ਸੰਸਕਰਣਾਂ ਲਈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਜੋਖਮ-ਆਧਾਰਿਤ ਸੁਧਾਰ (remediation) ਸਮਾਂ-ਮਿਆਦਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਇਹਨਾਂ ਘਟਕਾਂ ਤੋਂ ਜੋਖਮ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਕੀਤਾ ਜਾ ਸਕੇ। | 1 | +| **15.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਵਰਤੋਂ ਵਿੱਚ ਸਾਰੀਆਂ ਤੀਜੀ-ਧਿਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦਾ ਇੱਕ ਇਨਵੈਂਟਰੀ ਕੈਟਾਲਾਗ (inventory catalog), ਜਿਵੇਂ ਕਿ ਸਾਫ਼ਟਵੇਅਰ ਸਮੱਗਰੀ ਸੂਚੀ (software bill of materials, SBOM), ਬਣਾਈ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਹ ਤਸਦੀਕ ਕਰਨਾ ਵੀ ਸ਼ਾਮਲ ਹੈ ਕਿ ਘਟਕ ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ, ਭਰੋਸੇਯੋਗ, ਅਤੇ ਨਿਰੰਤਰ ਸਾਂਭੀਆਂ ਜਾਂਦੀਆਂ ਰਿਪੋਜ਼ਟਰੀਆਂ (repositories) ਤੋਂ ਆਉਂਦੇ ਹਨ। | 2 | +| **15.1.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਉਸ ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈਣ ਵਾਲੀ ਜਾਂ ਜ਼ਿਆਦਾ ਸਰੋਤ ਮੰਗਣ ਵਾਲੀ ਹੈ। ਇਸ ਵਿੱਚ ਇਹ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਸ ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਵਧੇਰੇ ਵਰਤੋਂ ਕਾਰਨ ਉਪਲਬਧਤਾ (availability) ਦੇ ਨੁਕਸਾਨ ਨੂੰ ਕਿਵੇਂ ਰੋਕਿਆ ਜਾਵੇ ਅਤੇ ਅਜਿਹੀ ਸਥਿਤੀ ਤੋਂ ਕਿਵੇਂ ਬਚਿਆ ਜਾਵੇ ਜਿੱਥੇ ਜਵਾਬ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਖਪਤਕਾਰ ਦੀ ਸਮਾਂ-ਸੀਮਾ (timeout) ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਸੰਭਾਵੀ ਰੱਖਿਆਵਾਂ ਵਿੱਚ ਅਸਿੰਕ੍ਰੋਨਸ (asynchronous) ਪ੍ਰੋਸੈਸਿੰਗ, ਕਤਾਰਾਂ (queues) ਦੀ ਵਰਤੋਂ, ਅਤੇ ਪ੍ਰਤੀ ਉਪਭੋਗਤਾ ਅਤੇ ਪ੍ਰਤੀ ਐਪਲੀਕੇਸ਼ਨ ਸਮਾਨਾਂਤਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸੀਮਤ ਕਰਨਾ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ। | 2 | +| **15.1.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਉਹਨਾਂ ਤੀਜੀ-ਧਿਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਉਭਾਰ ਕੇ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ "ਜੋਖਮ ਭਰੇ ਘਟਕ" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। | 3 | +| **15.1.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਉਭਾਰ ਕੇ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿੱਥੇ "ਖ਼ਤਰਨਾਕ ਕਾਰਜਸ਼ੀਲਤਾ" ਵਰਤੀ ਜਾ ਰਹੀ ਹੈ। | 3 | + +## V15.2 Security Architecture and Dependencies +## V15.2 ਸੁਰੱਖਿਆ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਨਿਰਭਰਤਾਵਾਂ + +This section includes requirements for handling risky, outdated, or insecure dependencies and components through dependency management. + +ਇਸ ਭਾਗ ਵਿੱਚ ਨਿਰਭਰਤਾ ਪ੍ਰਬੰਧਨ (dependency management) ਰਾਹੀਂ ਜੋਖਮ ਭਰੀਆਂ, ਪੁਰਾਣੀਆਂ, ਜਾਂ ਅਸੁਰੱਖਿਅਤ ਨਿਰਭਰਤਾਵਾਂ ਅਤੇ ਘਟਕਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਲੋੜਾਂ ਸ਼ਾਮਲ ਹਨ। + +It also includes using architectural-level techniques such as sandboxing, encapsulation, containerization, and network isolation to reduce the impact of using "dangerous operations" or "risky components" (as defined in the previous section) and prevent loss of availability due to overusing resource-demanding functionality. + +ਇਸ ਵਿੱਚ "ਖ਼ਤਰਨਾਕ ਕਾਰਵਾਈਆਂ" (dangerous operations) ਜਾਂ "ਜੋਖਮ ਭਰੇ ਘਟਕਾਂ" (ਜਿਵੇਂ ਕਿ ਪਿਛਲੇ ਭਾਗ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਹੈ) ਦੀ ਵਰਤੋਂ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾਉਣ ਅਤੇ ਜ਼ਿਆਦਾ ਸਰੋਤ ਮੰਗਣ ਵਾਲੀ ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਵਧੇਰੇ ਵਰਤੋਂ ਕਾਰਨ ਉਪਲਬਧਤਾ ਦੇ ਨੁਕਸਾਨ ਨੂੰ ਰੋਕਣ ਲਈ ਆਰਕੀਟੈਕਚਰ-ਪੱਧਰ ਦੀਆਂ ਤਕਨੀਕਾਂ, ਜਿਵੇਂ ਕਿ ਸੈਂਡਬਾਕਸਿੰਗ (sandboxing), ਇਨਕੈਪਸੂਲੇਸ਼ਨ (encapsulation), ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ (containerization), ਅਤੇ ਨੈੱਟਵਰਕ ਅਲਹਿਦਗੀ (network isolation), ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਵੀ ਸ਼ਾਮਲ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **15.2.1** | Verify that the application only contains components which have not breached the documented update and remediation time frames. | 1 | +| **15.2.2** | Verify that the application has implemented defenses against loss of availability due to functionality which is time-consuming or resource-demanding, based on the documented security decisions and strategies for this. | 2 | +| **15.2.3** | Verify that the production environment only includes functionality that is required for the application to function, and does not expose extraneous functionality such as test code, sample snippets, and development functionality. | 2 | +| **15.2.4** | Verify that third-party components and all of their transitive dependencies are included from the expected repository, whether internally owned or an external source, and that there is no risk of a dependency confusion attack. | 3 | +| **15.2.5** | Verify that the application implements additional protections around parts of the application which are documented as containing "dangerous functionality" or using third-party libraries considered to be "risky components". This could include techniques such as sandboxing, encapsulation, containerization or network level isolation to delay and deter attackers who compromise one part of an application from pivoting elsewhere in the application. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **15.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਸਿਰਫ਼ ਉਹ ਘਟਕ ਸ਼ਾਮਲ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ ਦਸਤਾਵੇਜ਼ੀ ਅੱਪਡੇਟ ਅਤੇ ਸੁਧਾਰ ਸਮਾਂ-ਮਿਆਦਾਂ ਦੀ ਉਲੰਘਣਾ ਨਹੀਂ ਕੀਤੀ ਹੈ। | 1 | +| **15.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਇਸ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਿਆਂ ਅਤੇ ਰਣਨੀਤੀਆਂ ਦੇ ਆਧਾਰ 'ਤੇ, ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈਣ ਵਾਲੀ ਜਾਂ ਜ਼ਿਆਦਾ ਸਰੋਤ ਮੰਗਣ ਵਾਲੀ ਕਾਰਜਸ਼ੀਲਤਾ ਕਾਰਨ ਉਪਲਬਧਤਾ ਦੇ ਨੁਕਸਾਨ ਵਿਰੁੱਧ ਰੱਖਿਆਵਾਂ ਲਾਗੂ ਕੀਤੀਆਂ ਹਨ। | 2 | +| **15.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸਿਰਫ਼ ਉਹ ਕਾਰਜਸ਼ੀਲਤਾ ਸ਼ਾਮਲ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਕੰਮ ਕਰਨ ਲਈ ਲੋੜੀਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਬੇਲੋੜੀ ਕਾਰਜਸ਼ੀਲਤਾ, ਜਿਵੇਂ ਕਿ ਟੈਸਟ ਕੋਡ, ਨਮੂਨਾ ਸਨਿੱਪਟ, ਅਤੇ ਵਿਕਾਸ ਕਾਰਜਸ਼ੀਲਤਾ, ਨੂੰ ਉਜਾਗਰ ਨਹੀਂ ਕਰਦਾ। | 2 | +| **15.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਤੀਜੀ-ਧਿਰ ਘਟਕ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਸਾਰੀਆਂ ਟ੍ਰਾਂਜ਼ਿਟਿਵ ਨਿਰਭਰਤਾਵਾਂ (transitive dependencies) ਉਮੀਦ ਕੀਤੀ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਭਾਵੇਂ ਉਹ ਅੰਦਰੂਨੀ ਮਲਕੀਅਤ ਵਾਲੀ ਹੋਵੇ ਜਾਂ ਕੋਈ ਬਾਹਰੀ ਸਰੋਤ, ਅਤੇ ਇਹ ਕਿ ਨਿਰਭਰਤਾ ਉਲਝਣ (dependency confusion) ਹਮਲੇ ਦਾ ਕੋਈ ਜੋਖਮ ਨਹੀਂ ਹੈ। | 3 | +| **15.2.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਆਪਣੇ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਵਾਧੂ ਸੁਰੱਖਿਆਵਾਂ ਲਾਗੂ ਕਰਦੀ ਹੈ ਜੋ "ਖ਼ਤਰਨਾਕ ਕਾਰਜਸ਼ੀਲਤਾ" ਰੱਖਣ ਵਾਲੇ ਜਾਂ "ਜੋਖਮ ਭਰੇ ਘਟਕ" ਮੰਨੀਆਂ ਜਾਂਦੀਆਂ ਤੀਜੀ-ਧਿਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਰਤਣ ਵਾਲੇ ਵਜੋਂ ਦਸਤਾਵੇਜ਼ੀ ਹਨ। ਇਸ ਵਿੱਚ ਸੈਂਡਬਾਕਸਿੰਗ, ਇਨਕੈਪਸੂਲੇਸ਼ਨ, ਕੰਟੇਨਰਾਈਜ਼ੇਸ਼ਨ ਜਾਂ ਨੈੱਟਵਰਕ-ਪੱਧਰ ਅਲਹਿਦਗੀ ਵਰਗੀਆਂ ਤਕਨੀਕਾਂ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਇੱਕ ਹਿੱਸੇ ਨਾਲ ਸਮਝੌਤਾ ਕਰਨ ਵਾਲੇ ਹਮਲਾਵਰਾਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਹੋਰ ਕਿਤੇ ਪਿਵਟ ਕਰਨ (pivoting) ਤੋਂ ਦੇਰੀ ਅਤੇ ਨਿਰਉਤਸ਼ਾਹਿਤ ਕੀਤਾ ਜਾ ਸਕੇ। | 3 | + +## V15.3 Defensive Coding +## V15.3 ਰੱਖਿਆਤਮਕ ਕੋਡਿੰਗ + +This section covers vulnerability types, including type juggling, prototype pollution, and others, which result from using insecure coding patterns in a particular language. Some may not be relevant to all languages, whereas others will have language-specific fixes or may relate to how a particular language or framework handles a feature such as HTTP parameters. It also considers the risk of not cryptographically validating application updates. + +ਇਹ ਭਾਗ ਕਮਜ਼ੋਰੀ ਕਿਸਮਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਟਾਈਪ ਜਗਲਿੰਗ (type juggling), ਪ੍ਰੋਟੋਟਾਈਪ ਪ੍ਰਦੂਸ਼ਣ (prototype pollution), ਅਤੇ ਹੋਰ ਸ਼ਾਮਲ ਹਨ, ਜੋ ਕਿਸੇ ਖ਼ਾਸ ਭਾਸ਼ਾ ਵਿੱਚ ਅਸੁਰੱਖਿਅਤ ਕੋਡਿੰਗ ਪੈਟਰਨ ਵਰਤਣ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ। ਕੁਝ ਸ਼ਾਇਦ ਸਾਰੀਆਂ ਭਾਸ਼ਾਵਾਂ ਲਈ ਢੁਕਵੀਆਂ ਨਾ ਹੋਣ, ਜਦੋਂ ਕਿ ਹੋਰਾਂ ਦੇ ਭਾਸ਼ਾ-ਵਿਸ਼ੇਸ਼ ਹੱਲ ਹੋਣਗੇ ਜਾਂ ਉਹ ਇਸ ਨਾਲ ਸੰਬੰਧਿਤ ਹੋ ਸਕਦੀਆਂ ਹਨ ਕਿ ਕੋਈ ਖ਼ਾਸ ਭਾਸ਼ਾ ਜਾਂ ਫ੍ਰੇਮਵਰਕ (framework) ਕਿਸੇ ਵਿਸ਼ੇਸ਼ਤਾ, ਜਿਵੇਂ ਕਿ HTTP ਪੈਰਾਮੀਟਰਾਂ, ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਹੈ। ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਅੱਪਡੇਟਾਂ ਨੂੰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਤੌਰ 'ਤੇ ਪ੍ਰਮਾਣਿਤ ਨਾ ਕਰਨ ਦੇ ਜੋਖਮ 'ਤੇ ਵੀ ਵਿਚਾਰ ਕਰਦਾ ਹੈ। + +It also considers the risks associated with using objects to represent data items and accepting and returning these via external APIs. In this case, the application must ensure that data fields that should not be writable are not modified by user input (mass assignment) and that the API is selective about what data fields get returned. Where field access depends on a user's permissions, this should be considered in the context of the field-level access control requirement in the Authorization chapter. + +ਇਹ ਡਾਟਾ ਇਕਾਈਆਂ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਆਬਜੈਕਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਬਾਹਰੀ API ਰਾਹੀਂ ਸਵੀਕਾਰ ਕਰਨ ਅਤੇ ਵਾਪਸ ਕਰਨ ਨਾਲ ਜੁੜੇ ਜੋਖਮਾਂ 'ਤੇ ਵੀ ਵਿਚਾਰ ਕਰਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਜਿਹੜੇ ਡਾਟਾ ਖੇਤਰ (fields) ਲਿਖਣਯੋਗ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ ਉਹ ਉਪਭੋਗਤਾ ਇਨਪੁੱਟ ਦੁਆਰਾ ਸੋਧੇ ਨਾ ਜਾਣ (ਮਾਸ ਅਸਾਈਨਮੈਂਟ, mass assignment) ਅਤੇ ਇਹ ਕਿ API ਇਸ ਬਾਰੇ ਚੋਣਵੀਂ ਹੈ ਕਿ ਕਿਹੜੇ ਡਾਟਾ ਖੇਤਰ ਵਾਪਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਜਿੱਥੇ ਖੇਤਰ ਪਹੁੰਚ ਉਪਭੋਗਤਾ ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਉੱਥੇ ਇਸ 'ਤੇ "ਅਧਿਕਾਰੀਕਰਨ" (Authorization) ਅਧਿਆਇ ਵਿਚਲੀ ਖੇਤਰ-ਪੱਧਰ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਲੋੜ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਵਿਚਾਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **15.3.1** | Verify that the application only returns the required subset of fields from a data object. For example, it should not return an entire data object, as some individual fields should not be accessible to users. | 1 | +| **15.3.2** | Verify that where the application backend makes calls to external URLs, it is configured to not follow redirects unless it is intended functionality. | 2 | +| **15.3.3** | Verify that the application has countermeasures to protect against mass assignment attacks by limiting allowed fields per controller and action, e.g., it is not possible to insert or update a field value when it was not intended to be part of that action. | 2 | +| **15.3.4** | Verify that all proxying and middleware components transfer the user's original IP address correctly using trusted data fields that cannot be manipulated by the end user, and the application and web server use this correct value for logging and security decisions such as rate limiting, taking into account that even the original IP address may not be reliable due to dynamic IPs, VPNs, or corporate firewalls. | 2 | +| **15.3.5** | Verify that the application explicitly ensures that variables are of the correct type and performs strict equality and comparator operations. This is to avoid type juggling or type confusion vulnerabilities caused by the application code making an assumption about a variable type. | 2 | +| **15.3.6** | Verify that JavaScript code is written in a way that prevents prototype pollution, for example, by using Set() or Map() instead of object literals. | 2 | +| **15.3.7** | Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (query string, body parameters, cookies, or header fields). | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **15.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕਿਸੇ ਡਾਟਾ ਆਬਜੈਕਟ ਤੋਂ ਸਿਰਫ਼ ਖੇਤਰਾਂ ਦਾ ਲੋੜੀਂਦਾ ਉਪ-ਸਮੂਹ ਹੀ ਵਾਪਸ ਕਰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇਸ ਨੂੰ ਪੂਰਾ ਡਾਟਾ ਆਬਜੈਕਟ ਵਾਪਸ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ, ਕਿਉਂਕਿ ਕੁਝ ਵਿਅਕਤੀਗਤ ਖੇਤਰ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ। | 1 | +| **15.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਿੱਥੇ ਐਪਲੀਕੇਸ਼ਨ ਬੈਕਐਂਡ ਬਾਹਰੀ URL ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਉੱਥੇ ਇਸ ਨੂੰ ਰੀਡਾਇਰੈਕਟਾਂ ਦਾ ਪਾਲਣ ਨਾ ਕਰਨ ਲਈ ਕੌਨਫ਼ਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਦੋਂ ਤੱਕ ਇਹ ਇੱਛਿਤ ਕਾਰਜਸ਼ੀਲਤਾ ਨਾ ਹੋਵੇ। | 2 | +| **15.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕੋਲ ਪ੍ਰਤੀ ਕੰਟਰੋਲਰ ਅਤੇ ਐਕਸ਼ਨ ਇਜਾਜ਼ਤ ਪ੍ਰਾਪਤ ਖੇਤਰਾਂ ਨੂੰ ਸੀਮਤ ਕਰਕੇ ਮਾਸ ਅਸਾਈਨਮੈਂਟ ਹਮਲਿਆਂ ਤੋਂ ਬਚਾਅ ਲਈ ਜਵਾਬੀ ਉਪਾਅ ਹਨ, ਜਿਵੇਂ ਕਿ, ਕਿਸੇ ਖੇਤਰ ਦੇ ਮੁੱਲ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਜਾਂ ਅੱਪਡੇਟ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਹੈ ਜਦੋਂ ਉਸ ਦਾ ਉਸ ਐਕਸ਼ਨ ਦਾ ਹਿੱਸਾ ਹੋਣਾ ਇੱਛਿਤ ਨਹੀਂ ਸੀ। | 2 | +| **15.3.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੇ ਪ੍ਰੌਕਸੀ ਅਤੇ ਮਿਡਲਵੇਅਰ ਘਟਕ ਉਪਭੋਗਤਾ ਦੇ ਅਸਲ IP ਪਤੇ ਨੂੰ ਅਜਿਹੇ ਭਰੋਸੇਯੋਗ ਡਾਟਾ ਖੇਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਹੀ ਢੰਗ ਨਾਲ ਅੱਗੇ ਭੇਜਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਅੰਤਮ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਹੇਰਾਫੇਰੀ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਵੈੱਬ ਸਰਵਰ ਇਸ ਸਹੀ ਮੁੱਲ ਦੀ ਵਰਤੋਂ ਲੌਗਿੰਗ ਅਤੇ ਸੁਰੱਖਿਆ ਫ਼ੈਸਲਿਆਂ, ਜਿਵੇਂ ਕਿ ਦਰ ਸੀਮਾ (rate limiting), ਲਈ ਕਰਦੇ ਹਨ, ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕਿ ਗਤੀਸ਼ੀਲ IP, VPN, ਜਾਂ ਕਾਰਪੋਰੇਟ ਫ਼ਾਇਰਵਾਲਾਂ ਕਾਰਨ ਅਸਲ IP ਪਤਾ ਵੀ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੋ ਸਕਦਾ। | 2 | +| **15.3.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਵੇਰੀਏਬਲ ਸਹੀ ਕਿਸਮ (type) ਦੇ ਹਨ ਅਤੇ ਸਖ਼ਤ ਸਮਾਨਤਾ (strict equality) ਅਤੇ ਤੁਲਨਾਕਾਰ (comparator) ਕਾਰਵਾਈਆਂ ਕਰਦੀ ਹੈ। ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਦੁਆਰਾ ਵੇਰੀਏਬਲ ਕਿਸਮ ਬਾਰੇ ਧਾਰਨਾ ਬਣਾਉਣ ਕਾਰਨ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਟਾਈਪ ਜਗਲਿੰਗ ਜਾਂ ਟਾਈਪ ਉਲਝਣ (type confusion) ਕਮਜ਼ੋਰੀਆਂ ਤੋਂ ਬਚਣ ਲਈ ਹੈ। | 2 | +| **15.3.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ JavaScript ਕੋਡ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖਿਆ ਗਿਆ ਹੈ ਜੋ ਪ੍ਰੋਟੋਟਾਈਪ ਪ੍ਰਦੂਸ਼ਣ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਆਬਜੈਕਟ ਲਿਟਰਲਾਂ (object literals) ਦੀ ਬਜਾਏ Set() ਜਾਂ Map() ਦੀ ਵਰਤੋਂ ਕਰਕੇ। | 2 | +| **15.3.7** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕੋਲ HTTP ਪੈਰਾਮੀਟਰ ਪ੍ਰਦੂਸ਼ਣ (HTTP parameter pollution) ਹਮਲਿਆਂ ਵਿਰੁੱਧ ਰੱਖਿਆਵਾਂ ਹਨ, ਖ਼ਾਸ ਕਰਕੇ ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਫ੍ਰੇਮਵਰਕ ਬੇਨਤੀ ਪੈਰਾਮੀਟਰਾਂ ਦੇ ਸਰੋਤ (ਕਿਊਰੀ ਸਟ੍ਰਿੰਗ, ਬਾਡੀ ਪੈਰਾਮੀਟਰ, ਕੁਕੀਆਂ, ਜਾਂ ਹੈੱਡਰ ਖੇਤਰ) ਬਾਰੇ ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਕਰਦਾ। | 2 | + +## V15.4 Safe Concurrency +## V15.4 ਸੁਰੱਖਿਅਤ ਸਮਕਾਲੀਨਤਾ + +Concurrency issues such as race conditions, time-of-check to time-of-use (TOCTOU) vulnerabilities, deadlocks, livelocks, thread starvation, and improper synchronization can lead to unpredictable behavior and security risks. This section includes various techniques and strategies to help mitigate these risks. + +ਸਮਕਾਲੀਨਤਾ (concurrency) ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ, ਜਿਵੇਂ ਕਿ ਰੇਸ ਕੰਡੀਸ਼ਨਾਂ (race conditions), ਜਾਂਚ-ਦੇ-ਸਮੇਂ ਤੋਂ ਵਰਤੋਂ-ਦੇ-ਸਮੇਂ (time-of-check to time-of-use, TOCTOU) ਕਮਜ਼ੋਰੀਆਂ, ਡੈੱਡਲਾਕ (deadlocks), ਲਾਈਵਲਾਕ (livelocks), ਥ੍ਰੈੱਡ ਸਟਾਰਵੇਸ਼ਨ (thread starvation), ਅਤੇ ਗ਼ਲਤ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ (synchronization), ਅਣਕਿਆਸੇ ਵਿਵਹਾਰ ਅਤੇ ਸੁਰੱਖਿਆ ਜੋਖਮਾਂ ਵੱਲ ਲੈ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਭਾਗ ਵਿੱਚ ਇਹਨਾਂ ਜੋਖਮਾਂ ਨੂੰ ਘਟਾਉਣ ਵਿੱਚ ਮਦਦ ਲਈ ਵੱਖ-ਵੱਖ ਤਕਨੀਕਾਂ ਅਤੇ ਰਣਨੀਤੀਆਂ ਸ਼ਾਮਲ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **15.4.1** | Verify that shared objects in multi-threaded code (such as caches, files, or in-memory objects accessed by multiple threads) are accessed safely by using thread-safe types and synchronization mechanisms like locks or semaphores to avoid race conditions and data corruption. | 3 | +| **15.4.2** | Verify that checks on a resource's state, such as its existence or permissions, and the actions that depend on them are performed as a single atomic operation to prevent time-of-check to time-of-use (TOCTOU) race conditions. For example, checking if a file exists before opening it, or verifying a user’s access before granting it. | 3 | +| **15.4.3** | Verify that locks are used consistently to avoid threads getting stuck, whether by waiting on each other or retrying endlessly, and that locking logic stays within the code responsible for managing the resource to ensure locks cannot be inadvertently or maliciously modified by external classes or code. | 3 | +| **15.4.4** | Verify that resource allocation policies prevent thread starvation by ensuring fair access to resources, such as by leveraging thread pools, allowing lower-priority threads to proceed within a reasonable timeframe. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **15.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਬਹੁ-ਥ੍ਰੈੱਡ ਕੋਡ ਵਿੱਚ ਸਾਂਝੇ ਆਬਜੈਕਟਾਂ (ਜਿਵੇਂ ਕਿ ਕੈਸ਼, ਫ਼ਾਈਲਾਂ, ਜਾਂ ਕਈ ਥ੍ਰੈੱਡਾਂ ਦੁਆਰਾ ਪਹੁੰਚ ਕੀਤੇ ਜਾਂਦੇ ਇਨ-ਮੈਮੋਰੀ ਆਬਜੈਕਟ) ਤੱਕ ਰੇਸ ਕੰਡੀਸ਼ਨਾਂ ਅਤੇ ਡਾਟਾ ਖ਼ਰਾਬ ਹੋਣ (data corruption) ਤੋਂ ਬਚਣ ਲਈ ਥ੍ਰੈੱਡ-ਸੁਰੱਖਿਅਤ ਕਿਸਮਾਂ ਅਤੇ ਲਾਕ ਜਾਂ ਸੇਮਾਫ਼ੋਰ ਵਰਗੀਆਂ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪਹੁੰਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। | 3 | +| **15.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਕਿਸੇ ਸਰੋਤ ਦੀ ਸਥਿਤੀ, ਜਿਵੇਂ ਕਿ ਉਸ ਦੀ ਹੋਂਦ ਜਾਂ ਇਜਾਜ਼ਤਾਂ, ਦੀਆਂ ਜਾਂਚਾਂ ਅਤੇ ਉਹਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਾਰਵਾਈਆਂ ਇੱਕੋ ਅਟੁੱਟ (atomic) ਕਾਰਵਾਈ ਵਜੋਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਜਾਂਚ-ਦੇ-ਸਮੇਂ ਤੋਂ ਵਰਤੋਂ-ਦੇ-ਸਮੇਂ (TOCTOU) ਰੇਸ ਕੰਡੀਸ਼ਨਾਂ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। ਉਦਾਹਰਨ ਲਈ, ਕਿਸੇ ਫ਼ਾਈਲ ਨੂੰ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਜਾਂਚਣਾ ਕਿ ਉਹ ਮੌਜੂਦ ਹੈ, ਜਾਂ ਉਪਭੋਗਤਾ ਦੀ ਪਹੁੰਚ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਦੀ ਤਸਦੀਕ ਕਰਨਾ। | 3 | +| **15.4.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਥ੍ਰੈੱਡਾਂ ਦੇ ਫਸ ਜਾਣ ਤੋਂ ਬਚਣ ਲਈ ਲਾਕਾਂ ਦੀ ਵਰਤੋਂ ਇਕਸਾਰ ਢੰਗ ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਭਾਵੇਂ ਉਹ ਇੱਕ-ਦੂਜੇ ਦੀ ਉਡੀਕ ਕਰਕੇ ਫਸਣ ਜਾਂ ਬੇਅੰਤ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਕਰਕੇ, ਅਤੇ ਇਹ ਕਿ ਲਾਕਿੰਗ ਤਰਕ ਸਰੋਤ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਕੋਡ ਦੇ ਅੰਦਰ ਹੀ ਰਹਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਲਾਕਾਂ ਨੂੰ ਬਾਹਰੀ ਕਲਾਸਾਂ ਜਾਂ ਕੋਡ ਦੁਆਰਾ ਅਣਜਾਣੇ ਵਿੱਚ ਜਾਂ ਦੁਰਭਾਵਨਾਪੂਰਨ ਢੰਗ ਨਾਲ ਸੋਧਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ। | 3 | +| **15.4.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਰੋਤ ਵੰਡ ਨੀਤੀਆਂ ਸਰੋਤਾਂ ਤੱਕ ਨਿਰਪੱਖ ਪਹੁੰਚ ਯਕੀਨੀ ਬਣਾ ਕੇ ਥ੍ਰੈੱਡ ਸਟਾਰਵੇਸ਼ਨ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਥ੍ਰੈੱਡ ਪੂਲਾਂ ਦਾ ਲਾਭ ਉਠਾ ਕੇ, ਜਿਸ ਨਾਲ ਘੱਟ-ਤਰਜੀਹ ਵਾਲੇ ਥ੍ਰੈੱਡ ਇੱਕ ਵਾਜਬ ਸਮਾਂ-ਮਿਆਦ ਦੇ ਅੰਦਰ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹਨ। | 3 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [OWASP Prototype Pollution Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html) +* [OWASP Mass Assignment Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html) +* [OWASP CycloneDX Bill of Materials Specification](https://owasp.org/www-project-cyclonedx/) +* [OWASP Web Security Testing Guide: Testing for HTTP Parameter Pollution](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution) diff --git a/5.0/pa-IN/0x25-V16-Security-Logging-and-Error-Handling.md b/5.0/pa-IN/0x25-V16-Security-Logging-and-Error-Handling.md new file mode 100644 index 0000000000..80ba410d70 --- /dev/null +++ b/5.0/pa-IN/0x25-V16-Security-Logging-and-Error-Handling.md @@ -0,0 +1,160 @@ + + + + +# V16 Security Logging and Error Handling +# V16 ਸੁਰੱਖਿਆ ਲੌਗਿੰਗ ਅਤੇ ਗਲਤੀ ਪ੍ਰਬੰਧਨ + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +Security logs are distinct from error or performance logs and are used to record security-relevant events such as authentication decisions, access control decisions, and attempts to bypass security controls, such as input validation or business logic validation. Their purpose is to support detection, response, and investigation by providing high-signal, structured data for analysis tools like SIEMs. + +ਸੁਰੱਖਿਆ ਲੌਗ (security logs) ਗਲਤੀ ਜਾਂ ਕਾਰਗੁਜ਼ਾਰੀ ਲੌਗਾਂ ਤੋਂ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਸੁਰੱਖਿਆ-ਸੰਬੰਧੀ ਘਟਨਾਵਾਂ ਨੂੰ ਦਰਜ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਫ਼ੈਸਲੇ, ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਫ਼ੈਸਲੇ, ਅਤੇ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣਾਂ, ਜਿਵੇਂ ਕਿ ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ ਕਾਰੋਬਾਰੀ ਤਰਕ ਪ੍ਰਮਾਣਿਕਤਾ, ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ। ਇਹਨਾਂ ਦਾ ਉਦੇਸ਼ SIEM ਵਰਗੇ ਵਿਸ਼ਲੇਸ਼ਣ ਟੂਲਾਂ ਲਈ ਉੱਚ-ਸੰਕੇਤ (high-signal), ਢਾਂਚਾਬੱਧ (structured) ਡਾਟਾ ਪ੍ਰਦਾਨ ਕਰਕੇ ਪਤਾ ਲਗਾਉਣ (detection), ਪ੍ਰਤੀਕਿਰਿਆ (response), ਅਤੇ ਤਫ਼ਤੀਸ਼ (investigation) ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਹੈ। + +Logs should not include sensitive personal data unless legally required, and any logged data must be protected as a high-value asset. Logging must not compromise privacy or system security. Applications must also fail securely, avoiding unnecessary disclosure or disruption. + +ਲੌਗਾਂ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਨਿੱਜੀ ਡਾਟਾ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਜਦੋਂ ਤੱਕ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ ਲੋੜੀਂਦਾ ਨਾ ਹੋਵੇ, ਅਤੇ ਕਿਸੇ ਵੀ ਲੌਗ ਕੀਤੇ ਡਾਟੇ ਨੂੰ ਇੱਕ ਉੱਚ-ਮੁੱਲ ਸੰਪਤੀ ਵਜੋਂ ਸੁਰੱਖਿਅਤ ਰੱਖਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਲੌਗਿੰਗ ਨੂੰ ਨਿੱਜਤਾ ਜਾਂ ਸਿਸਟਮ ਸੁਰੱਖਿਆ ਨਾਲ ਸਮਝੌਤਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਅਸਫਲ ਹੋਣਾ (fail securely) ਵੀ ਲਾਜ਼ਮੀ ਹੈ, ਬੇਲੋੜੇ ਖੁਲਾਸੇ ਜਾਂ ਵਿਘਨ ਤੋਂ ਬਚਦੇ ਹੋਏ। + +For detailed implementation guidance, refer to the OWASP Cheat Sheets in the references section. + +ਵਿਸਤ੍ਰਿਤ ਲਾਗੂਕਰਨ ਮਾਰਗਦਰਸ਼ਨ ਲਈ, ਹਵਾਲੇ ਭਾਗ ਵਿੱਚ ਦਿੱਤੀਆਂ OWASP Cheat Sheets ਵੇਖੋ। + +## V16.1 Security Logging Documentation +## V16.1 ਸੁਰੱਖਿਆ ਲੌਗਿੰਗ ਦਸਤਾਵੇਜ਼ੀਕਰਨ + +This section ensures a clear and complete inventory of logging across the application stack. This is essential for effective security monitoring, incident response, and compliance. + +ਇਹ ਭਾਗ ਐਪਲੀਕੇਸ਼ਨ ਸਟੈਕ ਭਰ ਵਿੱਚ ਲੌਗਿੰਗ ਦੀ ਇੱਕ ਸਪੱਸ਼ਟ ਅਤੇ ਸੰਪੂਰਨ ਇਨਵੈਂਟਰੀ (inventory) ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸੁਰੱਖਿਆ ਨਿਗਰਾਨੀ, ਘਟਨਾ ਪ੍ਰਤੀਕਿਰਿਆ (incident response), ਅਤੇ ਪਾਲਣਾ ਲਈ ਜ਼ਰੂਰੀ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **16.1.1** | Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log formats, where that logging is stored, how it is used, how access to it is controlled, and for how long logs are kept. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **16.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਇੱਕ ਇਨਵੈਂਟਰੀ ਮੌਜੂਦ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਤਕਨਾਲੋਜੀ ਸਟੈਕ ਦੀ ਹਰੇਕ ਪਰਤ 'ਤੇ ਕੀਤੀ ਜਾਂਦੀ ਲੌਗਿੰਗ, ਕਿਹੜੀਆਂ ਘਟਨਾਵਾਂ ਲੌਗ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ, ਲੌਗ ਫ਼ਾਰਮੈਟ, ਉਹ ਲੌਗਿੰਗ ਕਿੱਥੇ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਇਸ ਨੂੰ ਕਿਵੇਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਕਿਵੇਂ ਨਿਯੰਤਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਲੌਗ ਕਿੰਨੇ ਸਮੇਂ ਲਈ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਨੂੰ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਦਿੰਦੀ ਹੈ। | 2 | + +## V16.2 General Logging +## V16.2 ਆਮ ਲੌਗਿੰਗ + +This section provides requirements to ensure that security logs are consistently structured and contain the expected metadata. The goal is to make logs machine-readable and analyzable across distributed systems and tools. + +ਇਹ ਭਾਗ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਲੋੜਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਕਿ ਸੁਰੱਖਿਆ ਲੌਗ ਇਕਸਾਰ ਢੰਗ ਨਾਲ ਢਾਂਚਾਬੱਧ ਹੋਣ ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ ਉਮੀਦ ਕੀਤਾ ਮੈਟਾਡਾਟਾ ਸ਼ਾਮਲ ਹੋਵੇ। ਟੀਚਾ ਲੌਗਾਂ ਨੂੰ ਵੰਡੇ ਹੋਏ (distributed) ਸਿਸਟਮਾਂ ਅਤੇ ਟੂਲਾਂ ਭਰ ਵਿੱਚ ਮਸ਼ੀਨ-ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣਯੋਗ ਬਣਾਉਣਾ ਹੈ। + +Naturally, security events often involve sensitive data. If such data is logged without consideration, the logs themselves become classified and therefore subject to encryption requirements, stricter retention policies, and potential disclosure during audits. + +ਸੁਭਾਵਿਕ ਤੌਰ 'ਤੇ, ਸੁਰੱਖਿਆ ਘਟਨਾਵਾਂ ਵਿੱਚ ਅਕਸਰ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਅਜਿਹਾ ਡਾਟਾ ਬਿਨਾਂ ਸੋਚ-ਵਿਚਾਰ ਦੇ ਲੌਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਲੌਗ ਖ਼ੁਦ ਵਰਗੀਕ੍ਰਿਤ (classified) ਬਣ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇਸ ਲਈ ਏਨਕ੍ਰਿਪਸ਼ਨ ਲੋੜਾਂ, ਵਧੇਰੇ ਸਖ਼ਤ ਧਾਰਨ (retention) ਨੀਤੀਆਂ, ਅਤੇ ਆਡਿਟਾਂ ਦੌਰਾਨ ਸੰਭਾਵੀ ਖੁਲਾਸੇ ਦੇ ਅਧੀਨ ਹੋ ਜਾਂਦੇ ਹਨ। + +Therefore, it is critical to log only what is necessary and to treat log data with the same care as other sensitive assets. + +ਇਸ ਲਈ, ਸਿਰਫ਼ ਉਹੀ ਲੌਗ ਕਰਨਾ ਜੋ ਜ਼ਰੂਰੀ ਹੈ ਅਤੇ ਲੌਗ ਡਾਟੇ ਨਾਲ ਹੋਰ ਸੰਵੇਦਨਸ਼ੀਲ ਸੰਪਤੀਆਂ ਵਾਂਗ ਹੀ ਸਾਵਧਾਨੀ ਨਾਲ ਪੇਸ਼ ਆਉਣਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। + +The requirements below establish foundational requirements for logging metadata, synchronization, format, and control. + +ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਲੋੜਾਂ ਲੌਗਿੰਗ ਮੈਟਾਡਾਟਾ, ਸਮਕਾਲੀਕਰਨ (synchronization), ਫ਼ਾਰਮੈਟ, ਅਤੇ ਨਿਯੰਤਰਣ ਲਈ ਬੁਨਿਆਦੀ ਲੋੜਾਂ ਸਥਾਪਿਤ ਕਰਦੀਆਂ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **16.2.1** | Verify that each log entry includes necessary metadata (such as when, where, who, what) that would allow for a detailed investigation of the timeline when an event happens. | 2 | +| **16.2.2** | Verify that time sources for all logging components are synchronized, and that timestamps in security event metadata use UTC or include an explicit time zone offset. UTC is recommended to ensure consistency across distributed systems and to prevent confusion during daylight saving time transitions. | 2 | +| **16.2.3** | Verify that the application only stores or broadcasts logs to the files and services that are documented in the log inventory. | 2 | +| **16.2.4** | Verify that logs can be read and correlated by the log processor that is in use, preferably by using a common logging format. | 2 | +| **16.2.5** | Verify that when logging sensitive data, the application enforces logging based on the data's protection level. For example, it may not be allowed to log certain data, such as credentials or payment details. Other data, such as session tokens, may only be logged by being hashed or masked, either in full or partially. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **16.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਹਰੇਕ ਲੌਗ ਐਂਟਰੀ ਵਿੱਚ ਲੋੜੀਂਦਾ ਮੈਟਾਡਾਟਾ (ਜਿਵੇਂ ਕਿ ਕਦੋਂ, ਕਿੱਥੇ, ਕੌਣ, ਕੀ) ਸ਼ਾਮਲ ਹੈ ਜੋ ਕਿਸੇ ਘਟਨਾ ਦੇ ਵਾਪਰਨ 'ਤੇ ਸਮਾਂ-ਰੇਖਾ (timeline) ਦੀ ਵਿਸਤ੍ਰਿਤ ਤਫ਼ਤੀਸ਼ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ। | 2 | +| **16.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੇ ਲੌਗਿੰਗ ਹਿੱਸਿਆਂ ਲਈ ਸਮਾਂ ਸਰੋਤ (time sources) ਸਮਕਾਲੀ ਕੀਤੇ ਗਏ ਹਨ, ਅਤੇ ਸੁਰੱਖਿਆ ਘਟਨਾ ਮੈਟਾਡਾਟਾ ਵਿੱਚ ਟਾਈਮਸਟੈਂਪ UTC ਵਰਤਦੇ ਹਨ ਜਾਂ ਇੱਕ ਸਪੱਸ਼ਟ ਸਮਾਂ ਖੇਤਰ ਆਫ਼ਸੈੱਟ (time zone offset) ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ। ਵੰਡੇ ਹੋਏ ਸਿਸਟਮਾਂ ਭਰ ਵਿੱਚ ਇਕਸਾਰਤਾ ਯਕੀਨੀ ਬਣਾਉਣ ਅਤੇ ਡੇਲਾਈਟ ਸੇਵਿੰਗ ਟਾਈਮ ਤਬਦੀਲੀਆਂ ਦੌਰਾਨ ਉਲਝਣ ਰੋਕਣ ਲਈ UTC ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। | 2 | +| **16.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਲੌਗਾਂ ਨੂੰ ਸਿਰਫ਼ ਉਹਨਾਂ ਫ਼ਾਈਲਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਵਿੱਚ ਹੀ ਸਟੋਰ ਜਾਂ ਪ੍ਰਸਾਰਿਤ ਕਰਦੀ ਹੈ ਜੋ ਲੌਗ ਇਨਵੈਂਟਰੀ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ ਵਿੱਚ ਦਰਜ ਹਨ। | 2 | +| **16.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਲੌਗਾਂ ਨੂੰ ਵਰਤੋਂ ਵਿੱਚ ਆ ਰਹੇ ਲੌਗ ਪ੍ਰੋਸੈਸਰ ਦੁਆਰਾ ਪੜ੍ਹਿਆ ਅਤੇ ਸਹਿ-ਸੰਬੰਧਿਤ (correlated) ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤਰਜੀਹੀ ਤੌਰ 'ਤੇ ਇੱਕ ਸਾਂਝੇ ਲੌਗਿੰਗ ਫ਼ਾਰਮੈਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ। | 2 | +| **16.2.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਲੌਗ ਕਰਦੇ ਸਮੇਂ, ਐਪਲੀਕੇਸ਼ਨ ਡਾਟੇ ਦੇ ਸੁਰੱਖਿਆ ਪੱਧਰ ਦੇ ਆਧਾਰ 'ਤੇ ਲੌਗਿੰਗ ਲਾਗੂ ਕਰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਕੁਝ ਡਾਟਾ, ਜਿਵੇਂ ਕਿ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਜਾਂ ਭੁਗਤਾਨ ਵੇਰਵੇ, ਲੌਗ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਹੋਰ ਡਾਟਾ, ਜਿਵੇਂ ਕਿ ਸੈਸ਼ਨ ਟੋਕਨ, ਸਿਰਫ਼ ਹੈਸ਼ ਕੀਤੇ ਜਾਂ ਮਾਸਕ ਕੀਤੇ (masked) ਜਾਣ 'ਤੇ ਹੀ ਲੌਗ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਜਾਂ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ। | 2 | + +## V16.3 Security Events +## V16.3 ਸੁਰੱਖਿਆ ਘਟਨਾਵਾਂ + +This section defines requirements for logging security-relevant events within the application. Capturing these events is critical for detecting suspicious behavior, supporting investigations, and fulfilling compliance obligations. + +ਇਹ ਭਾਗ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ ਸੁਰੱਖਿਆ-ਸੰਬੰਧੀ ਘਟਨਾਵਾਂ ਨੂੰ ਲੌਗ ਕਰਨ ਲਈ ਲੋੜਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਘਟਨਾਵਾਂ ਨੂੰ ਦਰਜ ਕਰਨਾ ਸ਼ੱਕੀ ਵਿਹਾਰ ਦਾ ਪਤਾ ਲਗਾਉਣ, ਤਫ਼ਤੀਸ਼ਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨ, ਅਤੇ ਪਾਲਣਾ ਦੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਪੂਰੀਆਂ ਕਰਨ ਲਈ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। + +This section outlines the types of events that should be logged but does not attempt to provide exhaustive detail. Each application has unique risk factors and operational context. + +ਇਹ ਭਾਗ ਉਹਨਾਂ ਘਟਨਾਵਾਂ ਦੀਆਂ ਕਿਸਮਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦਿੰਦਾ ਹੈ ਜੋ ਲੌਗ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਪਰ ਸੰਪੂਰਨ ਵੇਰਵਾ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ। ਹਰੇਕ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਆਪਣੇ ਵਿਲੱਖਣ ਜੋਖਮ ਕਾਰਕ ਅਤੇ ਸੰਚਾਲਨ ਸੰਦਰਭ ਹੁੰਦੇ ਹਨ। + +Note that while ASVS includes logging of security events in scope, alerting and correlation (e.g., SIEM rules or monitoring infrastructure) are considered out of scope and are handled by operational and monitoring systems. + +ਧਿਆਨ ਦਿਓ ਕਿ ਭਾਵੇਂ ASVS ਸੁਰੱਖਿਆ ਘਟਨਾਵਾਂ ਦੀ ਲੌਗਿੰਗ ਨੂੰ ਘੇਰੇ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਚੇਤਾਵਨੀ ਦੇਣਾ (alerting) ਅਤੇ ਸਹਿ-ਸੰਬੰਧ (correlation) (ਜਿਵੇਂ, SIEM ਨਿਯਮ ਜਾਂ ਨਿਗਰਾਨੀ ਬੁਨਿਆਦੀ ਢਾਂਚਾ) ਘੇਰੇ ਤੋਂ ਬਾਹਰ ਮੰਨੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਸੰਚਾਲਨ ਅਤੇ ਨਿਗਰਾਨੀ ਸਿਸਟਮਾਂ ਦੁਆਰਾ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **16.3.1** | Verify that all authentication operations are logged, including successful and unsuccessful attempts. Additional metadata, such as the type of authentication or factors used, should also be collected. | 2 | +| **16.3.2** | Verify that failed authorization attempts are logged. For L3, this must include logging all authorization decisions, including logging when sensitive data is accessed (without logging the sensitive data itself). | 2 | +| **16.3.3** | Verify that the application logs the security events that are defined in the documentation and also logs attempts to bypass the security controls, such as input validation, business logic, and anti-automation. | 2 | +| **16.3.4** | Verify that the application logs unexpected errors and security control failures such as backend TLS failures. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **16.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੀਆਂ ਪ੍ਰਮਾਣੀਕਰਨ ਕਾਰਵਾਈਆਂ ਲੌਗ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸ ਵਿੱਚ ਸਫਲ ਅਤੇ ਅਸਫਲ ਕੋਸ਼ਿਸ਼ਾਂ ਸ਼ਾਮਲ ਹਨ। ਵਾਧੂ ਮੈਟਾਡਾਟਾ, ਜਿਵੇਂ ਕਿ ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਕਿਸਮ ਜਾਂ ਵਰਤੇ ਗਏ ਕਾਰਕ, ਵੀ ਇਕੱਠਾ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। | 2 | +| **16.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਅਸਫਲ ਅਧਿਕਾਰੀਕਰਨ ਕੋਸ਼ਿਸ਼ਾਂ ਲੌਗ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। L3 ਲਈ, ਇਸ ਵਿੱਚ ਸਾਰੇ ਅਧਿਕਾਰੀਕਰਨ ਫ਼ੈਸਲਿਆਂ ਦੀ ਲੌਗਿੰਗ ਸ਼ਾਮਲ ਹੋਣੀ ਲਾਜ਼ਮੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਹ ਲੌਗ ਕਰਨਾ ਵੀ ਸ਼ਾਮਲ ਹੈ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਤੱਕ ਕਦੋਂ ਪਹੁੰਚ ਕੀਤੀ ਗਈ (ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟੇ ਨੂੰ ਖ਼ੁਦ ਲੌਗ ਕੀਤੇ ਬਿਨਾਂ)। | 2 | +| **16.3.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਸੁਰੱਖਿਆ ਘਟਨਾਵਾਂ ਨੂੰ ਲੌਗ ਕਰਦੀ ਹੈ ਅਤੇ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣਾਂ, ਜਿਵੇਂ ਕਿ ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ, ਕਾਰੋਬਾਰੀ ਤਰਕ, ਅਤੇ ਸਵੈਚਾਲਨ-ਵਿਰੋਧੀ, ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਵੀ ਲੌਗ ਕਰਦੀ ਹੈ। | 2 | +| **16.3.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਅਣਕਿਆਸੀਆਂ ਗਲਤੀਆਂ ਅਤੇ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਅਸਫਲਤਾਵਾਂ, ਜਿਵੇਂ ਕਿ ਬੈਕਐਂਡ TLS ਅਸਫਲਤਾਵਾਂ, ਨੂੰ ਲੌਗ ਕਰਦੀ ਹੈ। | 2 | + +## V16.4 Log Protection +## V16.4 ਲੌਗ ਸੁਰੱਖਿਆ + +Logs are valuable forensic artifacts and must be protected. If logs can be easily modified or deleted, they lose their integrity and become unreliable for incident investigations or legal proceedings. Logs may expose internal application behavior or sensitive metadata, making them an attractive target for attackers. + +ਲੌਗ ਕੀਮਤੀ ਫ਼ੋਰੈਂਸਿਕ ਸਬੂਤ (forensic artifacts) ਹਨ ਅਤੇ ਇਹਨਾਂ ਦੀ ਸੁਰੱਖਿਆ ਲਾਜ਼ਮੀ ਹੈ। ਜੇਕਰ ਲੌਗਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸੋਧਿਆ ਜਾਂ ਮਿਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਹ ਆਪਣੀ ਅਖੰਡਤਾ ਗੁਆ ਦਿੰਦੇ ਹਨ ਅਤੇ ਘਟਨਾ ਤਫ਼ਤੀਸ਼ਾਂ ਜਾਂ ਕਾਨੂੰਨੀ ਕਾਰਵਾਈਆਂ ਲਈ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਰਹਿੰਦੇ। ਲੌਗ ਅੰਦਰੂਨੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿਹਾਰ ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਮੈਟਾਡਾਟਾ ਉਜਾਗਰ ਕਰ ਸਕਦੇ ਹਨ, ਜਿਸ ਕਾਰਨ ਉਹ ਹਮਲਾਵਰਾਂ ਲਈ ਇੱਕ ਆਕਰਸ਼ਕ ਨਿਸ਼ਾਨਾ ਬਣ ਜਾਂਦੇ ਹਨ। + +This section defines requirements to ensure that logs are protected from unauthorized access, tampering, and disclosure, and that they are safely transmitted and stored in secure, isolated systems. + +ਇਹ ਭਾਗ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਲੋੜਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਲੌਗ ਅਣਅਧਿਕਾਰਤ ਪਹੁੰਚ, ਛੇੜਛਾੜ, ਅਤੇ ਖੁਲਾਸੇ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੋਣ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਵੇ ਅਤੇ ਸੁਰੱਖਿਅਤ, ਅਲੱਗ-ਥਲੱਗ (isolated) ਸਿਸਟਮਾਂ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **16.4.1** | Verify that all logging components appropriately encode data to prevent log injection. | 2 | +| **16.4.2** | Verify that logs are protected from unauthorized access and cannot be modified. | 2 | +| **16.4.3** | Verify that logs are securely transmitted to a logically separate system for analysis, detection, alerting, and escalation. The aim is to ensure that if the application is breached, the logs are not compromised. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **16.4.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਾਰੇ ਲੌਗਿੰਗ ਹਿੱਸੇ ਲੌਗ ਇੰਜੈਕਸ਼ਨ ਨੂੰ ਰੋਕਣ ਲਈ ਡਾਟੇ ਨੂੰ ਢੁਕਵੇਂ ਢੰਗ ਨਾਲ ਏਨਕੋਡ ਕਰਦੇ ਹਨ। | 2 | +| **16.4.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਲੌਗ ਅਣਅਧਿਕਾਰਤ ਪਹੁੰਚ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹਨ ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਸੋਧਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ। | 2 | +| **16.4.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਲੌਗਾਂ ਨੂੰ ਵਿਸ਼ਲੇਸ਼ਣ, ਪਤਾ ਲਗਾਉਣ, ਚੇਤਾਵਨੀ ਦੇਣ, ਅਤੇ ਐਸਕੇਲੇਸ਼ਨ (escalation) ਲਈ ਇੱਕ ਲਾਜ਼ੀਕਲ ਤੌਰ 'ਤੇ ਵੱਖਰੇ (logically separate) ਸਿਸਟਮ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉਦੇਸ਼ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਸੰਨ੍ਹ ਲੱਗ ਜਾਵੇ (breached), ਤਾਂ ਲੌਗਾਂ ਦਾ ਸਮਝੌਤਾ ਨਾ ਹੋਵੇ। | 2 | + +## V16.5 Error Handling +## V16.5 ਗਲਤੀ ਪ੍ਰਬੰਧਨ + +This section defines requirements to ensure that applications fail gracefully and securely without disclosing sensitive internal details. + +ਇਹ ਭਾਗ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਲੋੜਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਅੰਦਰੂਨੀ ਵੇਰਵਿਆਂ ਦਾ ਖੁਲਾਸਾ ਕੀਤੇ ਬਿਨਾਂ ਸੁਚਾਰੂ ਅਤੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਅਸਫਲ ਹੋਣ (fail gracefully and securely)। + +| # | Description | Level | +| :---: | :--- | :---: | +| **16.5.1** | Verify that a generic message is returned to the consumer when an unexpected or security-sensitive error occurs, ensuring no exposure of sensitive internal system data such as stack traces, queries, secret keys, and tokens. | 2 | +| **16.5.2** | Verify that the application continues to operate securely when external resource access fails, for example, by using patterns such as circuit breakers or graceful degradation. | 2 | +| **16.5.3** | Verify that the application fails gracefully and securely, including when an exception occurs, preventing fail-open conditions such as processing a transaction despite errors resulting from validation logic. | 2 | +| **16.5.4** | Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. This is both to avoid losing error details that must go to log files and to ensure that an error does not take down the entire application process, leading to a loss of availability. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **16.5.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਦੋਂ ਕੋਈ ਅਣਕਿਆਸੀ ਜਾਂ ਸੁਰੱਖਿਆ-ਸੰਵੇਦਨਸ਼ੀਲ ਗਲਤੀ ਵਾਪਰਦੀ ਹੈ ਤਾਂ ਖਪਤਕਾਰ ਨੂੰ ਇੱਕ ਆਮ ਸੁਨੇਹਾ ਵਾਪਸ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋਏ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲ ਅੰਦਰੂਨੀ ਸਿਸਟਮ ਡਾਟਾ, ਜਿਵੇਂ ਕਿ ਸਟੈਕ ਟ੍ਰੇਸ, ਕਿਊਰੀਆਂ, ਗੁਪਤ ਕੁੰਜੀਆਂ, ਅਤੇ ਟੋਕਨ, ਉਜਾਗਰ ਨਾ ਹੋਵੇ। | 2 | +| **16.5.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਜਦੋਂ ਬਾਹਰੀ ਸਰੋਤ ਪਹੁੰਚ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਸਰਕਟ ਬ੍ਰੇਕਰ (circuit breaker) ਜਾਂ ਸੁਚਾਰੂ ਨਿਘਾਰ (graceful degradation) ਵਰਗੇ ਨਮੂਨਿਆਂ (patterns) ਦੀ ਵਰਤੋਂ ਕਰਕੇ। | 2 | +| **16.5.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸੁਚਾਰੂ ਅਤੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਅਸਫਲ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਅਪਵਾਦ (exception) ਵਾਪਰਨ 'ਤੇ ਵੀ ਸ਼ਾਮਲ ਹੈ, ਅਤੇ ਫ਼ੇਲ-ਓਪਨ (fail-open) ਸਥਿਤੀਆਂ ਨੂੰ ਰੋਕਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਪ੍ਰਮਾਣਿਕਤਾ ਤਰਕ ਤੋਂ ਪੈਦਾ ਹੋਈਆਂ ਗਲਤੀਆਂ ਦੇ ਬਾਵਜੂਦ ਕਿਸੇ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨਾ। | 2 | +| **16.5.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਇੱਕ "ਆਖ਼ਰੀ ਸਹਾਰਾ" (last resort) ਗਲਤੀ ਹੈਂਡਲਰ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਜੋ ਸਾਰੇ ਅਣ-ਸੰਭਾਲੇ (unhandled) ਅਪਵਾਦਾਂ ਨੂੰ ਫੜੇਗਾ। ਇਹ ਉਹਨਾਂ ਗਲਤੀ ਵੇਰਵਿਆਂ ਦੇ ਗੁਆਚਣ ਤੋਂ ਬਚਣ ਲਈ ਵੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਲੌਗ ਫ਼ਾਈਲਾਂ ਵਿੱਚ ਜਾਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਵੀ ਕਿ ਕੋਈ ਗਲਤੀ ਪੂਰੇ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਸੈਸ (process) ਨੂੰ ਬੰਦ ਨਾ ਕਰ ਦੇਵੇ, ਜਿਸ ਨਾਲ ਉਪਲਬਧਤਾ ਦਾ ਨੁਕਸਾਨ ਹੋਵੇ। | 3 | + +Note: Certain languages, (including Swift, Go, and through common design practice, many functional languages,) do not support exceptions or last-resort event handlers. In this case, architects and developers should use a pattern, language, or framework-friendly way to ensure that applications can securely handle exceptional, unexpected, or security-related events. + +ਨੋਟ: ਕੁਝ ਭਾਸ਼ਾਵਾਂ, (Swift, Go, ਅਤੇ ਆਮ ਡਿਜ਼ਾਈਨ ਅਮਲ ਰਾਹੀਂ, ਕਈ ਫੰਕਸ਼ਨਲ ਭਾਸ਼ਾਵਾਂ ਸਮੇਤ,) ਅਪਵਾਦਾਂ ਜਾਂ ਆਖ਼ਰੀ-ਸਹਾਰਾ ਘਟਨਾ ਹੈਂਡਲਰਾਂ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੀਆਂ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਆਰਕੀਟੈਕਟਾਂ ਅਤੇ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਇੱਕ ਨਮੂਨਾ-, ਭਾਸ਼ਾ-, ਜਾਂ ਫ੍ਰੇਮਵਰਕ-ਅਨੁਕੂਲ ਤਰੀਕਾ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਪਵਾਦੀ, ਅਣਕਿਆਸੀਆਂ, ਜਾਂ ਸੁਰੱਖਿਆ-ਸੰਬੰਧੀ ਘਟਨਾਵਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਭਾਲ ਸਕਣ। + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* [OWASP Web Security Testing Guide: Testing for Error Handling](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README) +* [OWASP Authentication Cheat Sheet section about error messages](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-and-error-messages) +* [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) +* [OWASP Application Logging Vocabulary Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html) diff --git a/5.0/pa-IN/0x26-V17-WebRTC.md b/5.0/pa-IN/0x26-V17-WebRTC.md new file mode 100644 index 0000000000..1d030abd83 --- /dev/null +++ b/5.0/pa-IN/0x26-V17-WebRTC.md @@ -0,0 +1,140 @@ + + + + +# V17 WebRTC +# V17 WebRTC (ਵੈੱਬਆਰਟੀਸੀ) + +## Control Objective +## ਨਿਯੰਤਰਣ ਉਦੇਸ਼ + +Web Real-Time Communication (WebRTC) enables real-time voice, video, and data exchange in modern applications. As adoption increases, securing WebRTC infrastructure becomes critical. This section provides security requirements for stakeholders who develop, host, or integrate WebRTC systems. + +Web Real-Time Communication (WebRTC) ਆਧੁਨਿਕ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਰੀਅਲ-ਟਾਈਮ ਆਵਾਜ਼, ਵੀਡੀਓ, ਅਤੇ ਡਾਟਾ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ। ਜਿਵੇਂ-ਜਿਵੇਂ ਇਸ ਨੂੰ ਅਪਣਾਉਣਾ ਵਧਦਾ ਹੈ, WebRTC ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਅਤਿ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਭਾਗ ਉਹਨਾਂ ਹਿੱਸੇਦਾਰਾਂ (stakeholders) ਲਈ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ WebRTC ਸਿਸਟਮਾਂ ਨੂੰ ਵਿਕਸਿਤ ਕਰਦੇ, ਹੋਸਟ ਕਰਦੇ, ਜਾਂ ਏਕੀਕ੍ਰਿਤ ਕਰਦੇ ਹਨ। + +The WebRTC market can be broadly categorized into three segments: + +WebRTC ਬਾਜ਼ਾਰ ਨੂੰ ਮੋਟੇ ਤੌਰ 'ਤੇ ਤਿੰਨ ਵਰਗਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ: + +1. Product Developers: Proprietary and open-source vendors that create and supply WebRTC products and solutions. Their focus is on developing robust and secure WebRTC technologies that can be used by others. + +2. Communication Platforms as a Service (CPaaS): Providers that offer APIs, SDKs, and the necessary infrastructure or platforms to enable WebRTC functionalities. CPaaS providers may use products from the first category or develop their own WebRTC software to offer these services. + +3. Service Providers: Organizations that leverage products from product developers or CPaaS providers, or develop their own WebRTC solutions. They create and implement applications for online conferencing, healthcare, e-learning, and other domains where real-time communication is crucial. + +1. ਉਤਪਾਦ ਵਿਕਾਸਕਾਰ (Product Developers): ਮਾਲਕੀ (proprietary) ਅਤੇ ਓਪਨ-ਸੋਰਸ ਵਿਕਰੇਤਾ ਜੋ WebRTC ਉਤਪਾਦ ਅਤੇ ਹੱਲ ਬਣਾਉਂਦੇ ਅਤੇ ਸਪਲਾਈ ਕਰਦੇ ਹਨ। ਉਹਨਾਂ ਦਾ ਧਿਆਨ ਮਜ਼ਬੂਤ ਅਤੇ ਸੁਰੱਖਿਅਤ WebRTC ਤਕਨਾਲੋਜੀਆਂ ਵਿਕਸਿਤ ਕਰਨ 'ਤੇ ਹੁੰਦਾ ਹੈ ਜੋ ਦੂਜਿਆਂ ਦੁਆਰਾ ਵਰਤੀਆਂ ਜਾ ਸਕਣ। + +2. ਸੇਵਾ ਵਜੋਂ ਸੰਚਾਰ ਪਲੇਟਫ਼ਾਰਮ (Communication Platforms as a Service, CPaaS): ਉਹ ਪ੍ਰਦਾਤਾ ਜੋ WebRTC ਕਾਰਜਸਮਰੱਥਾਵਾਂ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣ ਲਈ API, SDK, ਅਤੇ ਲੋੜੀਂਦਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਜਾਂ ਪਲੇਟਫ਼ਾਰਮ ਪੇਸ਼ ਕਰਦੇ ਹਨ। CPaaS ਪ੍ਰਦਾਤਾ ਇਹ ਸੇਵਾਵਾਂ ਪੇਸ਼ ਕਰਨ ਲਈ ਪਹਿਲੇ ਵਰਗ ਦੇ ਉਤਪਾਦ ਵਰਤ ਸਕਦੇ ਹਨ ਜਾਂ ਆਪਣਾ WebRTC ਸਾਫ਼ਟਵੇਅਰ ਵਿਕਸਿਤ ਕਰ ਸਕਦੇ ਹਨ। + +3. ਸੇਵਾ ਪ੍ਰਦਾਤਾ (Service Providers): ਉਹ ਸੰਸਥਾਵਾਂ ਜੋ ਉਤਪਾਦ ਵਿਕਾਸਕਾਰਾਂ ਜਾਂ CPaaS ਪ੍ਰਦਾਤਾਵਾਂ ਦੇ ਉਤਪਾਦਾਂ ਦਾ ਲਾਭ ਉਠਾਉਂਦੀਆਂ ਹਨ, ਜਾਂ ਆਪਣੇ WebRTC ਹੱਲ ਵਿਕਸਿਤ ਕਰਦੀਆਂ ਹਨ। ਉਹ ਔਨਲਾਈਨ ਕਾਨਫ਼ਰੰਸਿੰਗ, ਸਿਹਤ-ਸੰਭਾਲ, ਈ-ਲਰਨਿੰਗ, ਅਤੇ ਹੋਰ ਖੇਤਰਾਂ ਲਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਂਦੀਆਂ ਅਤੇ ਲਾਗੂ ਕਰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਰੀਅਲ-ਟਾਈਮ ਸੰਚਾਰ ਅਤਿ ਮਹੱਤਵਪੂਰਨ ਹੈ। + +The security requirements outlined here are primarily focused on Product Developers, CPaaS, and Service Providers who: + +ਇੱਥੇ ਦਿੱਤੀਆਂ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਮੁੱਖ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਉਤਪਾਦ ਵਿਕਾਸਕਾਰਾਂ, CPaaS, ਅਤੇ ਸੇਵਾ ਪ੍ਰਦਾਤਾਵਾਂ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹਨ ਜੋ: + +* Utilize open-source solutions to build their WebRTC applications. +* Use commercial WebRTC products as part of their infrastructure. +* Use internally developed WebRTC solutions or integrate various components into a cohesive service offering. + +* ਆਪਣੀਆਂ WebRTC ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਣ ਲਈ ਓਪਨ-ਸੋਰਸ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। +* ਆਪਣੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਵਪਾਰਕ WebRTC ਉਤਪਾਦਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। +* ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਵਿਕਸਿਤ WebRTC ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਜਾਂ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਨੂੰ ਇੱਕ ਇਕਜੁੱਟ ਸੇਵਾ ਪੇਸ਼ਕਸ਼ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕਰਦੇ ਹਨ। + +It is important to note that these security requirements do not apply to developers who exclusively use SDKs and APIs provided by CPaaS vendors. For such developers, the CPaaS providers are typically responsible for most of the underlying security concerns within their platforms, and a generic security standard like ASVS may not fully address their needs. + +ਇਹ ਨੋਟ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਇਹ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਉਹਨਾਂ ਵਿਕਾਸਕਾਰਾਂ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀਆਂ ਜੋ ਸਿਰਫ਼ CPaaS ਵਿਕਰੇਤਾਵਾਂ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ SDK ਅਤੇ API ਦੀ ਹੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਅਜਿਹੇ ਵਿਕਾਸਕਾਰਾਂ ਲਈ, CPaaS ਪ੍ਰਦਾਤਾ ਆਮ ਤੌਰ 'ਤੇ ਆਪਣੇ ਪਲੇਟਫ਼ਾਰਮਾਂ ਦੇ ਅੰਦਰ ਜ਼ਿਆਦਾਤਰ ਅੰਤਰੀਵ ਸੁਰੱਖਿਆ ਚਿੰਤਾਵਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ ASVS ਵਰਗਾ ਇੱਕ ਆਮ ਸੁਰੱਖਿਆ ਮਿਆਰ ਸ਼ਾਇਦ ਉਹਨਾਂ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੰਬੋਧਿਤ ਨਾ ਕਰੇ। + +## V17.1 TURN Server +## V17.1 TURN ਸਰਵਰ + +This section defines security requirements for systems that operate their own TURN (Traversal Using Relays around NAT) servers. TURN servers assist in relaying media in restrictive network environments but can pose risks if misconfigured. These controls focus on secure address filtering and protection against resource exhaustion. + +ਇਹ ਭਾਗ ਉਹਨਾਂ ਸਿਸਟਮਾਂ ਲਈ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਆਪਣੇ TURN (Traversal Using Relays around NAT) ਸਰਵਰ ਚਲਾਉਂਦੇ ਹਨ। TURN ਸਰਵਰ ਪਾਬੰਦੀਸ਼ੁਦਾ ਨੈੱਟਵਰਕ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਮੀਡੀਆ ਨੂੰ ਰੀਲੇਅ (relay) ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਦੇ ਹਨ ਪਰ ਗ਼ਲਤ ਸੰਰਚਨਾ ਹੋਣ 'ਤੇ ਜੋਖਮ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਨਿਯੰਤਰਣ ਸੁਰੱਖਿਅਤ ਪਤਾ ਫ਼ਿਲਟਰਿੰਗ ਅਤੇ ਸਰੋਤ ਖ਼ਤਮ ਹੋ ਜਾਣ (resource exhaustion) ਤੋਂ ਸੁਰੱਖਿਆ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹਨ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **17.1.1** | Verify that the Traversal Using Relays around NAT (TURN) service only allows access to IP addresses that are not reserved for special purposes (e.g., internal networks, broadcast, loopback). Note that this applies to both IPv4 and IPv6 addresses. | 2 | +| **17.1.2** | Verify that the Traversal Using Relays around NAT (TURN) service is not susceptible to resource exhaustion when legitimate users attempt to open a large number of ports on the TURN server. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **17.1.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ Traversal Using Relays around NAT (TURN) ਸੇਵਾ ਸਿਰਫ਼ ਉਹਨਾਂ IP ਪਤਿਆਂ ਤੱਕ ਪਹੁੰਚ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਜੋ ਵਿਸ਼ੇਸ਼ ਉਦੇਸ਼ਾਂ (ਜਿਵੇਂ ਕਿ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ, ਬ੍ਰੌਡਕਾਸਟ, ਲੂਪਬੈਕ) ਲਈ ਰਾਖਵੇਂ ਨਹੀਂ ਹਨ। ਧਿਆਨ ਦਿਓ ਕਿ ਇਹ IPv4 ਅਤੇ IPv6 ਦੋਵਾਂ ਪਤਿਆਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। | 2 | +| **17.1.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ Traversal Using Relays around NAT (TURN) ਸੇਵਾ ਉਦੋਂ ਸਰੋਤ ਖ਼ਤਮ ਹੋ ਜਾਣ ਦੀ ਸ਼ਿਕਾਰ ਨਹੀਂ ਹੁੰਦੀ ਜਦੋਂ ਜਾਇਜ਼ ਉਪਭੋਗਤਾ TURN ਸਰਵਰ 'ਤੇ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਪੋਰਟ ਖੋਲ੍ਹਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। | 3 | + +## V17.2 Media +## V17.2 ਮੀਡੀਆ + +These requirements only apply to systems that host their own WebRTC media servers, such as Selective Forwarding Units (SFUs), Multipoint Control Units (MCUs), recording servers, or gateway servers. Media servers handle and distribute media streams, making their security critical to protect communication between peers. Safeguarding media streams is paramount in WebRTC applications to prevent eavesdropping, tampering, and denial-of-service attacks that could compromise user privacy and communication quality. + +ਇਹ ਲੋੜਾਂ ਸਿਰਫ਼ ਉਹਨਾਂ ਸਿਸਟਮਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਆਪਣੇ WebRTC ਮੀਡੀਆ ਸਰਵਰ ਹੋਸਟ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ Selective Forwarding Units (SFU), Multipoint Control Units (MCU), ਰਿਕਾਰਡਿੰਗ ਸਰਵਰ, ਜਾਂ ਗੇਟਵੇ ਸਰਵਰ। ਮੀਡੀਆ ਸਰਵਰ ਮੀਡੀਆ ਸਟ੍ਰੀਮਾਂ (media streams) ਨੂੰ ਸੰਭਾਲਦੇ ਅਤੇ ਵੰਡਦੇ ਹਨ, ਜਿਸ ਕਰਕੇ ਪੀਅਰਾਂ (peers) ਦੇ ਵਿਚਕਾਰ ਸੰਚਾਰ ਦੀ ਰਾਖੀ ਲਈ ਉਹਨਾਂ ਦੀ ਸੁਰੱਖਿਆ ਅਤਿ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੀ ਹੈ। WebRTC ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਮੀਡੀਆ ਸਟ੍ਰੀਮਾਂ ਦੀ ਰਾਖੀ ਕਰਨਾ ਸਭ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ ਤਾਂ ਜੋ ਗੁਪਤ ਤੌਰ 'ਤੇ ਸੁਣਨ (eavesdropping), ਛੇੜਛਾੜ, ਅਤੇ ਸੇਵਾ-ਇਨਕਾਰ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ ਜੋ ਉਪਭੋਗਤਾ ਦੀ ਨਿੱਜਤਾ ਅਤੇ ਸੰਚਾਰ ਗੁਣਵੱਤਾ ਨਾਲ ਸਮਝੌਤਾ ਕਰ ਸਕਦੇ ਹਨ। + +In particular, it is necessary to implement protections against flood attacks such as rate limiting, validating timestamps, using synchronized clocks to match real-time intervals, and managing buffers to prevent overflow and maintain proper timing. If packets for a particular media session arrive too quickly, excess packets should be dropped. It is also important to protect the system from malformed packets by implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques. + +ਖ਼ਾਸ ਤੌਰ 'ਤੇ, ਹੜ੍ਹ (flood) ਹਮਲਿਆਂ ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆਵਾਂ ਲਾਗੂ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਦਰ ਸੀਮਾ (rate limiting), ਟਾਈਮਸਟੈਂਪਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ, ਰੀਅਲ-ਟਾਈਮ ਅੰਤਰਾਲਾਂ ਨਾਲ ਮੇਲ ਕਰਨ ਲਈ ਸਮਕਾਲੀ (synchronized) ਘੜੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ, ਅਤੇ ਓਵਰਫ਼ਲੋ ਨੂੰ ਰੋਕਣ ਅਤੇ ਸਹੀ ਸਮਾਂ-ਮੇਲ ਬਣਾਈ ਰੱਖਣ ਲਈ ਬਫ਼ਰਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ। ਜੇ ਕਿਸੇ ਖ਼ਾਸ ਮੀਡੀਆ ਸੈਸ਼ਨ ਲਈ ਪੈਕੇਟ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚਦੇ ਹਨ, ਤਾਂ ਵਾਧੂ ਪੈਕੇਟ ਰੱਦ ਕਰ ਦਿੱਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ (input validation) ਲਾਗੂ ਕਰਕੇ, ਇੰਟੀਜਰ ਓਵਰਫ਼ਲੋ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਭਾਲ ਕੇ, ਬਫ਼ਰ ਓਵਰਫ਼ਲੋ ਨੂੰ ਰੋਕ ਕੇ, ਅਤੇ ਹੋਰ ਮਜ਼ਬੂਤ ਗਲਤੀ ਪ੍ਰਬੰਧਨ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਿਸਟਮ ਨੂੰ ਵਿਗੜੇ ਹੋਏ (malformed) ਪੈਕੇਟਾਂ ਤੋਂ ਸੁਰੱਖਿਅਤ ਰੱਖਣਾ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। + +Systems that rely solely on peer-to-peer media communication between web browsers, without the involvement of intermediate media servers, are excluded from these specific media-related security requirements. + +ਉਹ ਸਿਸਟਮ ਜੋ ਵਿਚਕਾਰਲੇ ਮੀਡੀਆ ਸਰਵਰਾਂ ਦੀ ਸ਼ਮੂਲੀਅਤ ਤੋਂ ਬਿਨਾਂ, ਸਿਰਫ਼ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰਾਂ ਦੇ ਵਿਚਕਾਰ ਪੀਅਰ-ਤੋਂ-ਪੀਅਰ ਮੀਡੀਆ ਸੰਚਾਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਇਹਨਾਂ ਖ਼ਾਸ ਮੀਡੀਆ-ਸੰਬੰਧੀ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਤੋਂ ਬਾਹਰ ਰੱਖੇ ਗਏ ਹਨ। + +This section refers to the use of Datagram Transport Layer Security (DTLS) in the context of WebRTC. A requirement related to having a documented policy for the management of cryptographic keys can be found in the "Cryptography" chapter. Information on approved cryptographic methods can be found either in the Cryptography Appendix of the ASVS or in documents such as NIST SP 800‑52 Rev. 2 or BSI TR‑02102‑2 (Version 2025‑01). + +ਇਹ ਭਾਗ WebRTC ਦੇ ਸੰਦਰਭ ਵਿੱਚ Datagram Transport Layer Security (DTLS) ਦੀ ਵਰਤੋਂ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ। ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਕੁੰਜੀਆਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਨੀਤੀ ਰੱਖਣ ਨਾਲ ਸੰਬੰਧਿਤ ਇੱਕ ਲੋੜ "ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ" (Cryptography) ਅਧਿਆਇ ਵਿੱਚ ਮਿਲ ਸਕਦੀ ਹੈ। ਪ੍ਰਵਾਨਿਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਵਿਧੀਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਜਾਂ ਤਾਂ ASVS ਦੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ੀ ਅੰਤਿਕਾ ਵਿੱਚ ਜਾਂ NIST SP 800‑52 Rev. 2 ਜਾਂ BSI TR‑02102‑2 (Version 2025‑01) ਵਰਗੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਮਿਲ ਸਕਦੀ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **17.2.1** | Verify that the key for the Datagram Transport Layer Security (DTLS) certificate is managed and protected based on the documented policy for management of cryptographic keys. | 2 | +| **17.2.2** | Verify that the media server is configured to use and support approved Datagram Transport Layer Security (DTLS) cipher suites and a secure protection profile for the DTLS Extension for establishing keys for the Secure Real-time Transport Protocol (DTLS-SRTP). | 2 | +| **17.2.3** | Verify that Secure Real-time Transport Protocol (SRTP) authentication is checked at the media server to prevent Real-time Transport Protocol (RTP) injection attacks from leading to either a Denial of Service condition or audio or video media insertion into media streams. | 2 | +| **17.2.4** | Verify that the media server is able to continue processing incoming media traffic when encountering malformed Secure Real-time Transport Protocol (SRTP) packets. | 2 | +| **17.2.5** | Verify that the media server is able to continue processing incoming media traffic during a flood of Secure Real-time Transport Protocol (SRTP) packets from legitimate users. | 3 | +| **17.2.6** | Verify that the media server is not susceptible to the "ClientHello" Race Condition vulnerability in Datagram Transport Layer Security (DTLS) by checking if the media server is publicly known to be vulnerable or by performing the race condition test. | 3 | +| **17.2.7** | Verify that any audio or video recording mechanisms associated with the media server are able to continue processing incoming media traffic during a flood of Secure Real-time Transport Protocol (SRTP) packets from legitimate users. | 3 | +| **17.2.8** | Verify that the Datagram Transport Layer Security (DTLS) certificate is checked against the Session Description Protocol (SDP) fingerprint attribute, terminating the media stream if the check fails, to ensure the authenticity of the media stream. | 3 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **17.2.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ Datagram Transport Layer Security (DTLS) ਸਰਟੀਫ਼ਿਕੇਟ ਦੀ ਕੁੰਜੀ ਦਾ ਪ੍ਰਬੰਧਨ ਅਤੇ ਸੁਰੱਖਿਆ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਕੁੰਜੀਆਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਨੀਤੀ ਦੇ ਆਧਾਰ 'ਤੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। | 2 | +| **17.2.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਮੀਡੀਆ ਸਰਵਰ ਨੂੰ ਪ੍ਰਵਾਨਿਤ Datagram Transport Layer Security (DTLS) ਸਾਈਫ਼ਰ ਸੂਟਾਂ ਅਤੇ Secure Real-time Transport Protocol ਲਈ ਕੁੰਜੀਆਂ ਸਥਾਪਿਤ ਕਰਨ ਵਾਸਤੇ DTLS Extension (DTLS-SRTP) ਲਈ ਇੱਕ ਸੁਰੱਖਿਅਤ ਪ੍ਰੋਟੈਕਸ਼ਨ ਪ੍ਰੋਫ਼ਾਈਲ (protection profile) ਦੀ ਵਰਤੋਂ ਅਤੇ ਸਮਰਥਨ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। | 2 | +| **17.2.3** | ਤਸਦੀਕ ਕਰੋ ਕਿ Secure Real-time Transport Protocol (SRTP) ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਜਾਂਚ ਮੀਡੀਆ ਸਰਵਰ 'ਤੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਜੋ Real-time Transport Protocol (RTP) ਇੰਜੈਕਸ਼ਨ ਹਮਲਿਆਂ ਨੂੰ ਜਾਂ ਤਾਂ ਸੇਵਾ-ਇਨਕਾਰ ਸਥਿਤੀ ਜਾਂ ਮੀਡੀਆ ਸਟ੍ਰੀਮਾਂ ਵਿੱਚ ਆਡੀਓ ਜਾਂ ਵੀਡੀਓ ਮੀਡੀਆ ਪਾਏ ਜਾਣ ਵੱਲ ਲੈ ਜਾਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕੇ। | 2 | +| **17.2.4** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਮੀਡੀਆ ਸਰਵਰ ਵਿਗੜੇ ਹੋਏ Secure Real-time Transport Protocol (SRTP) ਪੈਕੇਟਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨ 'ਤੇ ਆਉਣ ਵਾਲੇ ਮੀਡੀਆ ਟ੍ਰੈਫ਼ਿਕ ਦੀ ਪ੍ਰਕਿਰਿਆ ਜਾਰੀ ਰੱਖਣ ਦੇ ਸਮਰੱਥ ਹੈ। | 2 | +| **17.2.5** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਮੀਡੀਆ ਸਰਵਰ ਜਾਇਜ਼ ਉਪਭੋਗਤਾਵਾਂ ਵੱਲੋਂ Secure Real-time Transport Protocol (SRTP) ਪੈਕੇਟਾਂ ਦੇ ਹੜ੍ਹ ਦੌਰਾਨ ਆਉਣ ਵਾਲੇ ਮੀਡੀਆ ਟ੍ਰੈਫ਼ਿਕ ਦੀ ਪ੍ਰਕਿਰਿਆ ਜਾਰੀ ਰੱਖਣ ਦੇ ਸਮਰੱਥ ਹੈ। | 3 | +| **17.2.6** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਮੀਡੀਆ ਸਰਵਰ Datagram Transport Layer Security (DTLS) ਵਿੱਚ "ClientHello" ਰੇਸ ਕੰਡੀਸ਼ਨ (race condition) ਕਮਜ਼ੋਰੀ ਦਾ ਸ਼ਿਕਾਰ ਨਹੀਂ ਹੈ, ਇਹ ਜਾਂਚ ਕੇ ਕਿ ਕੀ ਮੀਡੀਆ ਸਰਵਰ ਜਨਤਕ ਤੌਰ 'ਤੇ ਕਮਜ਼ੋਰ ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ ਜਾਂ ਰੇਸ ਕੰਡੀਸ਼ਨ ਟੈਸਟ ਕਰਕੇ। | 3 | +| **17.2.7** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਮੀਡੀਆ ਸਰਵਰ ਨਾਲ ਜੁੜੀਆਂ ਕੋਈ ਵੀ ਆਡੀਓ ਜਾਂ ਵੀਡੀਓ ਰਿਕਾਰਡਿੰਗ ਪ੍ਰਣਾਲੀਆਂ ਜਾਇਜ਼ ਉਪਭੋਗਤਾਵਾਂ ਵੱਲੋਂ Secure Real-time Transport Protocol (SRTP) ਪੈਕੇਟਾਂ ਦੇ ਹੜ੍ਹ ਦੌਰਾਨ ਆਉਣ ਵਾਲੇ ਮੀਡੀਆ ਟ੍ਰੈਫ਼ਿਕ ਦੀ ਪ੍ਰਕਿਰਿਆ ਜਾਰੀ ਰੱਖਣ ਦੇ ਸਮਰੱਥ ਹਨ। | 3 | +| **17.2.8** | ਤਸਦੀਕ ਕਰੋ ਕਿ Datagram Transport Layer Security (DTLS) ਸਰਟੀਫ਼ਿਕੇਟ ਦੀ ਜਾਂਚ Session Description Protocol (SDP) fingerprint ਗੁਣ ਦੇ ਵਿਰੁੱਧ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਜਾਂਚ ਅਸਫਲ ਹੋਣ 'ਤੇ ਮੀਡੀਆ ਸਟ੍ਰੀਮ ਨੂੰ ਖ਼ਤਮ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਮੀਡੀਆ ਸਟ੍ਰੀਮ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ (authenticity) ਯਕੀਨੀ ਬਣਾਈ ਜਾ ਸਕੇ। | 3 | + +## V17.3 Signaling +## V17.3 ਸਿਗਨਲਿੰਗ + +This section defines requirements for systems that operate their own WebRTC signaling servers. Signaling coordinates peer-to-peer communication and must be resilient against attacks that could disrupt session establishment or control. + +ਇਹ ਭਾਗ ਉਹਨਾਂ ਸਿਸਟਮਾਂ ਲਈ ਲੋੜਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਆਪਣੇ WebRTC ਸਿਗਨਲਿੰਗ (signaling) ਸਰਵਰ ਚਲਾਉਂਦੇ ਹਨ। ਸਿਗਨਲਿੰਗ ਪੀਅਰ-ਤੋਂ-ਪੀਅਰ ਸੰਚਾਰ ਦਾ ਤਾਲਮੇਲ ਕਰਦੀ ਹੈ ਅਤੇ ਇਸ ਦਾ ਉਹਨਾਂ ਹਮਲਿਆਂ ਦੇ ਵਿਰੁੱਧ ਲਚਕੀਲਾ (resilient) ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ ਜੋ ਸੈਸ਼ਨ ਸਥਾਪਨਾ ਜਾਂ ਨਿਯੰਤਰਣ ਵਿੱਚ ਵਿਘਨ ਪਾ ਸਕਦੇ ਹਨ। + +To ensure secure signaling, systems must handle malformed inputs gracefully and remain available under load. + +ਸੁਰੱਖਿਅਤ ਸਿਗਨਲਿੰਗ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ, ਸਿਸਟਮਾਂ ਲਈ ਵਿਗੜੇ ਹੋਏ ਇਨਪੁੱਟਾਂ ਨੂੰ ਸੁਚੱਜੇ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣਾ ਅਤੇ ਲੋਡ ਹੇਠ ਉਪਲਬਧ ਰਹਿਣਾ ਲਾਜ਼ਮੀ ਹੈ। + +| # | Description | Level | +| :---: | :--- | :---: | +| **17.3.1** | Verify that the signaling server is able to continue processing legitimate incoming signaling messages during a flood attack. This should be achieved by implementing rate limiting at the signaling level. | 2 | +| **17.3.2** | Verify that the signaling server is able to continue processing legitimate signaling messages when encountering malformed signaling message that could cause a denial of service condition. This could include implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques. | 2 | + +| # | ਵੇਰਵਾ | ਪੱਧਰ | +| :---: | :--- | :---: | +| **17.3.1** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਿਗਨਲਿੰਗ ਸਰਵਰ ਹੜ੍ਹ ਹਮਲੇ ਦੌਰਾਨ ਜਾਇਜ਼ ਆਉਣ ਵਾਲੇ ਸਿਗਨਲਿੰਗ ਸੁਨੇਹਿਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਜਾਰੀ ਰੱਖਣ ਦੇ ਸਮਰੱਥ ਹੈ। ਇਹ ਸਿਗਨਲਿੰਗ ਪੱਧਰ 'ਤੇ ਦਰ ਸੀਮਾ ਲਾਗੂ ਕਰਕੇ ਹਾਸਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। | 2 | +| **17.3.2** | ਤਸਦੀਕ ਕਰੋ ਕਿ ਸਿਗਨਲਿੰਗ ਸਰਵਰ ਅਜਿਹੇ ਵਿਗੜੇ ਹੋਏ ਸਿਗਨਲਿੰਗ ਸੁਨੇਹੇ ਦਾ ਸਾਹਮਣਾ ਕਰਨ 'ਤੇ, ਜੋ ਸੇਵਾ-ਇਨਕਾਰ ਸਥਿਤੀ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਇਜ਼ ਸਿਗਨਲਿੰਗ ਸੁਨੇਹਿਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਜਾਰੀ ਰੱਖਣ ਦੇ ਸਮਰੱਥ ਹੈ। ਇਸ ਵਿੱਚ ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ ਲਾਗੂ ਕਰਨਾ, ਇੰਟੀਜਰ ਓਵਰਫ਼ਲੋ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣਾ, ਬਫ਼ਰ ਓਵਰਫ਼ਲੋ ਨੂੰ ਰੋਕਣਾ, ਅਤੇ ਹੋਰ ਮਜ਼ਬੂਤ ਗਲਤੀ ਪ੍ਰਬੰਧਨ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ। | 2 | + +## References +## ਹਵਾਲੇ + +For more information, see also: + +ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਇਹ ਵੀ ਵੇਖੋ: + +* The WebRTC DTLS ClientHello DoS is best documented at [Enable Security's blog post aimed at security professionals](https://www.enablesecurity.com/blog/novel-dos-vulnerability-affecting-webrtc-media-servers/) and the associated [white paper aimed at WebRTC developers](https://www.enablesecurity.com/blog/webrtc-hello-race-conditions-paper/) +* [RFC 3550 - RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550) +* [RFC 3711 - The Secure Real-time Transport Protocol (SRTP)](https://datatracker.ietf.org/doc/html/rfc3711) +* [RFC 5764 - Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP))](https://datatracker.ietf.org/doc/html/rfc5764) +* [RFC 8825 - Overview: Real-Time Protocols for Browser-Based Applications](https://www.rfc-editor.org/info/rfc8825) +* [RFC 8826 - Security Considerations for WebRTC](https://www.rfc-editor.org/info/rfc8826) +* [RFC 8827 - WebRTC Security Architecture](https://www.rfc-editor.org/info/rfc8827) +* [DTLS-SRTP Protection Profiles](https://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml) diff --git a/5.0/pa-IN/CLAUDE.md b/5.0/pa-IN/CLAUDE.md new file mode 100644 index 0000000000..f5ee69e5d2 --- /dev/null +++ b/5.0/pa-IN/CLAUDE.md @@ -0,0 +1,159 @@ +# CLAUDE.md — OWASP ASVS Panjabi Translation Rules + +## Project + +OWASP ASVS 5.0 Panjabi (pa-IN) translation. Bilingual English/Gurmukhi format. +Repository: `GeeksikhSecurity/ASVS` branch `panjabi-translation-v5` + +> **Canonical rule set:** [`TRANSLATION-RULES.md`](TRANSLATION-RULES.md) is the +> authoritative source for all translation decisions (script, orthography, +> numerals, romanization, T/L/R/H terminology, Gurmat safety, bilingual +> structure). This file is the operational companion; if the two ever diverge, +> `TRANSLATION-RULES.md` wins. + +## Spelling + +Use **"Panjabi"** (not "Punjabi") per Sikhri.org and Panjab Digital Library standards. + +--- + +## Translation Dictionary Sources (MANDATORY) + +All Panjabi translations MUST cross-reference these scraped dictionary sources before using any term: + +1. **Guru Granth Sahib Dictionary** — https://gurugranthsahibdictionary.io/ + - Primary source for Gurmukhi vocabulary, word roots, and semantic context + - Scraped content available in project data files when present + +2. **Guru Granth Sahib Reference** — https://gurugranthsahib.io/info/english/guru-granth-sahib + - Contextual definitions and usage patterns rooted in Gurbani tradition + - Gurmukhi script institutionalized by Guru Angad Sahib + +3. **Punjabi University Patiala English-Punjabi Dictionary** (ISBN 81-7380-095-2) + - Secondary reference for technical/modern terms not found in Gurbani sources + - Use entries for authentication (ਪ੍ਰਮਾਣੀਕਰਨ, ਤਸਦੀਕ), authorization (ਅਧਿਕਾਰ), access (ਪਹੁੰਚ), etc. + +### Dictionary Lookup Order +1. Check gurugranthsahibdictionary.io first +2. Check gurugranthsahib.io for contextual usage +3. Fall back to Punjabi University Patiala dictionary for technical terms +4. If no match found, document as "open terminology question" in TRANSLATION-NOTES.md + +--- + +## Gurmat Language Constraints (MANDATORY) + +Adapted from the Gurmat-Centered Bilingual Prompt (Google Doc ID: 1G23l0TJ9594K0yYBUcp4quR4vsOcTUjVCTYWWmopx0Y). + +### NEVER USE — Prohibited Terminology +- ❌ Yoga terminology (chakras, kundalini, pranayama, third eye) +- ❌ Hindu deity names or mythology references +- ❌ Energy centers, auras, or metaphysical yoga concepts +- ❌ Sanskrit mantras or terms outside of Gurbani context +- ❌ Any term with yoga/Hindu connotation when a Gurmat or neutral Panjabi equivalent exists + +### ALWAYS PREFER — Gurmat-Aligned Vocabulary +- ✅ Terms rooted in Gurmukhi tradition and Sikh scholarly usage +- ✅ Vocabulary from Guru Granth Sahib Dictionary when applicable +- ✅ Prof. Sahib Singh's Darpan methodology for interpretive guidance +- ✅ Contemporary Panjabi that resonates with modern technical readers +- ✅ Bilingual format maintaining parallel meaning (English | ਪੰਜਾਬੀ) + +### Quality Check Before Every Commit +- [ ] Zero yoga/Hindu/Sanskrit influence outside Gurbani +- [ ] All terms cross-referenced against dictionary sources above +- [ ] Open terminology questions documented in TRANSLATION-NOTES.md +- [ ] Bilingual format maintained (English term | Gurmukhi term) +- [ ] T/L/R/H classification applied (Translated/Loan/Retained/Hybrid) + +--- + +## Translation Classification System (T/L/R/H) + +| Code | Type | Example | +|------|------|---------| +| **T** | Translated | Authentication → ਪ੍ਰਮਾਣੀਕਰਨ | +| **L** | Loan word | API → ਏ.ਪੀ.ਆਈ. | +| **R** | Retained | OWASP, SQL, XSS (kept as-is) | +| **H** | Hybrid | SQL Injection → SQL ਇੰਜੈਕਸ਼ਨ | + +--- + +## Numerals + +Use Western numerals in technical prose, including version numbers: 5.0 (not ੫.੦). See `TRANSLATION-RULES.md` §2. + +--- + +## Reverence Note + +Sri Guru Granth Sahib Ji is the eternal Guru and supreme guiding authority for Sikhs. It contains the divine utterances of six Gurus, three Sikhs, fifteen saints, and eleven court poets. Never refer to it as a "scripture" or "book." The Gurmukhi script was institutionalized by Guru Angad Sahib. + +--- + +## Blog Post Structure (SecurityLeader.ai) + +When creating blog posts about this translation project for SecurityLeader.ai: + +1. Italic hook question after H1 +2. Executive Summary blockquote +3. "Your Next Move" section with role-specific CTAs +4. Board talking points + author attribution (Gurvinder Singh, Principal Security Researcher) + +Publish workflow: Claude Code → `git push origin main` → Vercel auto-deploy + +--- + +## File Structure + +``` +5.0/pa-IN/ +├── CLAUDE.md ← This file (translation rules) +├── TRANSLATION-NOTES.md ← Open terminology questions +├── REVIEW-PLAN.md ← Community review process +├── GIT-CHEATSHEET.md ← Contributor git workflow +├── README.md ← Translation overview +├── 0x01-Frontispiece.md ← Phase A (complete) +├── 0x02-Preface.md ← Phase A (complete) +├── 0x03-Using-ASVS.md ← Phase B (March-April 2026) +├── 0x04-Assessment-and-Cert.md ← Phase B +├── V1-V4/ ← Phase B +├── V5-V14, V50-V52/ ← Phase C (May-July 2026) +└── Appendices/ ← Phase D (August 2026) +``` + +--- + +## Sentence-ending punctuation (MANDATORY) + +Panjabi (Gurmukhi-script) prose uses the **Indic danda `।` (U+0964)** as +sentence terminator — never the Western period `.`. The double-danda +`॥` (U+0965) is reserved for verse separation in Gurbani quotations and +should not be used in technical prose. + +### Rule + +- Every Panjabi sentence ends with `।` followed by a space or end-of-line +- Sentences that end with a parenthetical also use `।` after the closing + paren: `(ਜਿਵੇਂ, RFC 6266 ਦੇ ਅਨੁਸਾਰ)।` — not `(ਜਿਵੇਂ, RFC 6266 ਦੇ ਅਨੁਸਾਰ).` +- Bullet-list items and table cells follow the same rule when their content + is a Panjabi sentence + +### Exceptions (Western `.` retained) + +- ASCII digits and version numbers: `5.0`, `5.2.1`, `v5.0.0` +- URLs, file extensions, English abbreviations +- English text on lines that contain no Gurmukhi +- Decimal numbers and percentages + +### R4 codepoint allowlist + +The danda is in the Devanagari Unicode block (U+0900-U+097F) but Unicode +allocates it as shared Indic punctuation. The corpus-rigor R4 check +explicitly excludes U+0964 and U+0965 from the contamination test. Using +`।` does not violate Devanagari purity. + +### Applied corpus-wide + +Commit `bdda1806` (2026-06-02) applied this rule across 8 files, 127 +substitutions. New translations must honor this rule from creation. diff --git a/5.0/pa-IN/OPEN-QUESTIONS.md b/5.0/pa-IN/OPEN-QUESTIONS.md new file mode 100644 index 0000000000..f6598a86b3 --- /dev/null +++ b/5.0/pa-IN/OPEN-QUESTIONS.md @@ -0,0 +1,366 @@ +# Open Terminology Questions — Reviewer Adjudication + +This document collects terminology decisions made during the Panjabi (pa-IN) translation of OWASP ASVS 5.0 that the translator deferred for community review. Each entry shows the **current pick on the PR**, **alternatives considered**, and the **reasoning** that led to the current choice. + +**Reviewer ask:** For each entry, either confirm the current pick, or propose a substitution. Email feedback to [gurvinder@securityleader.ai](mailto:gurvinder@securityleader.ai) with subject *"ASVS Panjabi Review — Q"*, or comment inline on PR [#3254](https://github.com/OWASP/ASVS/pull/3254). + +**Author commitment:** The translator (GeeksikhSecurity) treats every entry below as **v0.1 — open for change**. The current pick is what's on disk; it is not the final answer. Final answer is the community-adjudicated form. + +--- + +## How to read this file + +| Field | Meaning | +|---|---| +| **EN term** | The English source term as it appears in OWASP ASVS 5.0 | +| **Current pick** | The Gurmukhi rendering committed on PR #3254 today | +| **Alternatives** | Other candidates considered with their tradeoffs | +| **Type** | T = Translated, L = Loan, R = Retained (acronym/proper noun), H = Hybrid | +| **Reasoning** | Why the current pick — and what could flip it | +| **Reviewer notes** | (Empty — reviewers fill this in via email or PR comment) | + +--- + +## Q1 — `multi-tenant` (V8 Authorization) + +| | | +|---|---| +| **EN term** | multi-tenant | +| **Current pick** | ਬਹੁ-ਕਿਰਾਏਦਾਰ (`bahu-kirāedār`) | +| **Type** | T | +| **Alternatives** | ਮਲਟੀ-ਟੇਨੈਂਟ (`malṭī-ṭenaiṅṭ`, L) — direct transliteration | +| **Reasoning** | `kirāedār` literally = "tenant" in standard Punjabi (Persian-origin, well-attested in real-estate and legal prose). The `bahu-` prefix = "many/multi". Honest native compound. The transliteration `ਮਲਟੀ-ਟੇਨੈਂਟ` would be unambiguous but reads as low-effort English-in-Gurmukhi-script | +| **Reviewer notes** | _to be filled_ | + +## Q2 — `IDOR / BOLA / BOPLA` acronyms (V8 Authorization) + +| | | +|---|---| +| **EN term** | IDOR, BOLA, BOPLA | +| **Current pick** | Latin retained in Panjabi tables — `IDOR`, `BOLA`, `BOPLA` | +| **Type** | R | +| **Alternatives** | (a) Add a Gurmukhi gloss in parens at first use, e.g., `IDOR (ਅਸੁਰੱਖਿਅਤ ਸਿੱਧਾ ਆਬਜੈਕਟ ਹਵਾਲਾ)`. (b) Provide a glossary appendix entry per acronym | +| **Reasoning** | Industry-standard security acronyms; expanding them inline disrupts table readability. The OWASP convention itself uses the acronyms unexpanded in normative requirements. Glossary expansion (option b) seems most appropriate but is currently absent from the pa-IN glossary | +| **Reviewer notes** | _to be filled_ | + +## Q3 — `entitlements` (V8 Authorization) + +| | | +|---|---| +| **EN term** | entitlements | +| **Current pick** | ਹੱਕ (`haqq`) | +| **Type** | T | +| **Alternatives** | ਅਧਿਕਾਰ (`adhikār`) | +| **Reasoning** | `ਅਧਿਕਾਰ` is the natural translation but **collides with ਅਧਿਕਾਰੀਕਰਨ (`adhikārīkaraṇ`)** — the locked term for "authorization" itself across the whole chapter. Using `ਅਧਿਕਾਰ` for "entitlements" inside an authorization chapter creates "ਅਧਿਕਾਰ ਅਧਿਕਾਰੀਕਰਨ ਪ੍ਰਣਾਲੀ" tautology. `ਹੱਕ` (Persian-origin, "right/claim") sidesteps the collision and reads naturally | +| **Reviewer notes** | _to be filled_ | + +## Q4 — `step-up authentication` (V8 Authorization) + +| | | +|---|---| +| **EN term** | step-up authentication | +| **Current pick** | ਸਟੈਪ-ਅੱਪ ਪ੍ਰਮਾਣੀਕਰਨ (`sṭaip-app pramāṇīkaraṇ`) | +| **Type** | H | +| **Alternatives** | ਉੱਚਾ-ਪੱਧਰ ਪ੍ਰਮਾਣੀਕਰਨ (`uchchā-paddhar pramāṇīkaraṇ`) — fully native, "higher-level authentication" | +| **Reasoning** | "Step-up" is a security-industry idiom (specific OAuth/MFA pattern); transliterating preserves recognizability for bilingual practitioners cross-referencing English documentation. The fully native form is more elegant but loses that retrievability | +| **Reviewer notes** | _to be filled_ | + +## Q5 — `posture` (V8 Authorization) — RESOLVED + +| | | +|---|---| +| **Status** | **RESOLVED 2026-06-01** — see commit `9e1e96b` | +| **EN term** | device security posture | +| **Initial pick** | ਮੁਦਰਾ (`mudrā`) | +| **Final pick** | **ਸਥਿਤੀ (`sthitī`)** | +| **Reasoning** | `mudrā` carries strong Hindu/Hatha-Yoga ritual connotations (ritual hand gesture in classical Indian iconography); flagged as Gurmat-policy violation per `5.0/pa-IN/CLAUDE.md`. Replaced with `sthitī` (state/situation/posture) — neutral, no Gurmat conflict, already used in this same chapter (8.1.2) for "data object state/status" | +| **Reviewer notes** | _resolved, no action needed_ | + +## Q6 — `Self-contained token` (V9 Self-contained Tokens) + +| | | +|---|---| +| **EN term** | Self-contained token | +| **Current pick** | ਸਵੈ-ਨਿਰਭਰ ਟੋਕਨ (`svai-nirbhar ṭokan`) | +| **Type** | H | +| **Alternatives** | ਸਵੈ-ਪੂਰਨ ਟੋਕਨ (`svai-pūran ṭokan`); ਸਵੈ-ਸੰਪੰਨ ਟੋਕਨ (`svai-sampann ṭokan`) | +| **Reasoning** | Neologism — no established Panjabi equivalent. `svai-nirbhar` = "self-reliant" emphasizes the JWT/JWS property of being verifiable without a state lookup. `svai-pūran` ("self-complete") and `svai-sampann` ("self-equipped") are both reasonable; `nirbhar` was chosen because it foregrounds the *operational independence* property reviewers and developers care about | +| **Reviewer notes** | _to be filled_ | + +## Q7 — `Audience` (JWT claim) (V9 Self-contained Tokens) + +| | | +|---|---| +| **EN term** | Audience (as in the JWT `aud` claim — "intended recipient service") | +| **Current pick** | English `audience` kept inline (R) | +| **Type** | R | +| **Alternatives** | ਸਰੋਤਾ (`sarotā`) — "listener" | +| **Reasoning** | `sarotā` literally means "one who listens/reads" — wrong semantics for JWT, where `audience` means *intended recipient service*, not a human. No Panjabi term carries the precise JWT `aud` semantics. Keeping English `audience` inline avoids a semantically misleading translation. A glossary entry could explain | +| **Reviewer notes** | _to be filled_ | + +## Q8 — `Stateless` (deferred from V9) + +| | | +|---|---| +| **EN term** | stateless | +| **Current pick** | (deferred — not used in 0x18; will appear in V11/V12/V16 chapters) | +| **Type** | _undecided_ | +| **Alternatives** | ਸਟੇਟਲੈੱਸ (`sṭeṭalais`, L) — direct loan; ਸਥਿਤੀ-ਰਹਿਤ (`sthitī-rahit`, T) — "state-less" native | +| **Reasoning** | Direct loan reads more naturally in developer-facing prose; native form is more elegant in prose-heavy sections. Decision deferred to first chapter that actually uses it | +| **Reviewer notes** | _to be filled — early signal welcome since this fires in multiple chapters_ | + +## Q9 — `Allowlist` (V9, V5 File Handling) + +| | | +|---|---| +| **EN term** | allowlist | +| **Current pick** | English `allowlist` kept inline (R) | +| **Type** | R | +| **Alternatives** | ਪ੍ਰਵਾਨ-ਸੂਚੀ (`pravān-sūchī`, T) — "approval list"; ਆਗਿਆ-ਸੂਚੀ (`āgiā-sūchī`, T) — "permission list" | +| **Reasoning** | Industry-standard term; the OWASP-recommended replacement for "whitelist". Both calques are plausible but introduce a fresh native term that readers cross-referencing English documentation may not recognize. Precedent now set in both 0x14 V5 and 0x18 V9 — change once means changing twice | +| **Reviewer notes** | _to be filled_ | + +## Q10 — `Key material` (V9 Self-contained Tokens) + +| | | +|---|---| +| **EN term** | key material | +| **Current pick** | English `key material` kept inline (R) | +| **Type** | R | +| **Alternatives** | ਕੁੰਜੀ-ਸਮੱਗਰੀ (`kuñjī-samagrī`, T) — "key material" literal calque | +| **Reasoning** | Precise cryptographic term; the calque is grammatically clean but loses retrievability for practitioners reading mixed EN+PA cryptography documentation. Could ship as English with a glossary entry | +| **Reviewer notes** | _to be filled_ | + +## Q11 — `LFI / RFI / SSRF / zip slip` acronyms (V5 File Handling) + +| | | +|---|---| +| **EN term** | LFI, RFI, SSRF, zip slip | +| **Current pick** | Latin retained in PA table | +| **Type** | R | +| **Alternatives** | Add Gurmukhi gloss on first use, e.g., `LFI (ਸਥਾਨਕ ਫ਼ਾਈਲ ਇਨਕਲੂਜ਼ਨ)` | +| **Reasoning** | Same logic as Q2 (IDOR/BOLA/BOPLA). Industry-standard acronyms; inline expansion would clutter requirement-table cells. Consistency: matches the Q2 decision pattern | +| **Reviewer notes** | _to be filled_ | + +## Q12 — Bilingual structure: dual-block vs code-switched (CORPUS-WIDE — highest priority) + +| | | +|---|---| +| **Decision** | Which bilingual structure should the whole corpus use? | +| **Status** | **OPEN — deferred to community review (highest-priority structural question)** | + +Two structures currently coexist in the committed chapters. This is the single most important thing for reviewers to weigh in on, because it affects every chapter going forward. + +**Pattern A — dual-block (English-first, full Panjabi mirror below)** + +Used in: `0x01`, `0x02`, `0x14`, `0x17`, `0x18`, `0x21` + +```markdown +## V5 File Handling +## V5 ਫ਼ਾਈਲ ਪ੍ਰਬੰਧਨ + +The use of files can present a variety of risks... + +ਫ਼ਾਈਲਾਂ ਦੀ ਵਰਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਖ਼ਤਰੇ... + +| # | Description | Level | ← English requirement table +| # | ਵੇਰਵਾ | ਪੱਧਰ | ← parallel Panjabi requirement table +``` + +- A non-English-reading Panjabi developer can read the Panjabi block end-to-end. +- The English block is preserved verbatim for cross-reference and technical precision. +- This is the structure the project's public rationale commits to: *"every section is bilingual. English first, Panjabi immediately below."* +- Cost: roughly doubles file length; more to maintain when upstream English changes. + +**Pattern B — code-switched single-block (Panjabi-primary, English terms inline)** + +Used in: `0x04`, `0x05` + +```markdown +# v4.x ਦੇ ਮੁਕਾਬਲੇ ਤਬਦੀਲੀਆਂ (Changes Compared to v4.x) + +Version 4.0.3 ਦੀਆਂ 286 requirements ਵਿੱਚੋਂ, ਸਿਰਫ਼ 11 ਬਿਨਾਂ ਤਬਦੀਲੀ ਦੇ ਰਹਿ ਗਈਆਂ ਹਨ... +``` + +- More compact; reads naturally for a bilingual developer comfortable with English technical terms. +- A Panjabi-only reader cannot read it cleanly (English nouns are load-bearing), and there is no separate English block to cross-reference. +- Diverges from the public rationale's stated promise. + +**Recommendation from the translator:** Pattern A, for consistency with the project's stated bilingual-readability goal. If the community agrees, `0x04` and `0x05` will be re-translated into Pattern A. If the community prefers Pattern B for intro/meta chapters (and Pattern A for normative requirement chapters), that mixed convention will be documented in `TRANSLATION-NOTES.md` and applied deliberately rather than by accident. + +**Reviewer ask:** State a preference — (a) Pattern A everywhere, (b) Pattern B everywhere, or (c) mixed-by-chapter-type with explicit rules. This decision is currently *unmade*; the two patterns in the corpus today are an artifact of different drafting passes, not a deliberate choice. + +| **Reviewer notes** | _to be filled_ | + +--- + +## Resolved questions + +| # | Question | Resolution | Commit | +|---|---|---|---| +| Q5 | `posture` ਮੁਦਰਾ → ਸਥਿਤੀ | Gurmat-policy violation; replaced with `sthitī` | `9e1e96b` | + +--- + +## Policy locks (for reference) + +These policies are **already locked** and not open for review: + +- **R21** — Standalone fraud term must be `ਠੱਗੀ` (`ṭhaggī`); the only allowed exception is the compound `ਰੋਮਾਂਸ ਫ਼ਰਾਡ` (romance fraud) — locked 2026-05-30 +- **R22** — Standard term for "community" is `ਭਾਈਚਾਰਾ` (`bhāʼīchārā`); `ਸੰਗਤ` reserved for named Sikh religious contexts — locked 2026-05-30 +- **R23** — Romanization is IAST canonical: `ṭ ḍ ṇ ā ī ū ṅ ñ chh ʼ` — locked 2026-05-30 +- **Gurmat constraints** (CLAUDE.md) — no yoga/Hindu/Sanskrit terms outside direct Gurbani quotation +- **Devanagari purity** — no letters in U+0900–U+0963 or U+0966–U+097F; the danda U+0964 and double-danda U+0965 are explicitly allowed as shared Indic punctuation + +If a reviewer wants to challenge a locked policy, please open a separate GitHub issue rather than commenting inline — the policy lock is corpus-wide, not a per-chapter decision. + +## Q13 — Corpus-wide term normalisations applied 2026-08-22 (confirm or reverse) + +Applied while publishing the August 2026 batch (0x03, V1, V2, V3, V4, V6, V7). Each is a single pick now used consistently; reviewers may reverse any of them corpus-wide. + +| EN term | Pick | Was | Type | Reasoning | +|---|---|---|---|---| +| risk (vs threat) | ਜੋਖਮ (risk) · ਖ਼ਤਰਾ (threat) | V6/V7/V8 used ਖ਼ਤਰਾ for both | T | A security standard must keep risk and threat distinct; 0x03 already used ਜੋਖਮ | +| session management | ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ | README: ਸੈਸ਼ਨ ਪ੍ਰਬੰਧ | T | Matches V5 ਫ਼ਾਈਲ ਪ੍ਰਬੰਧਨ; README row updated | +| authorization | ਅਧਿਕਾਰੀਕਰਨ | README: ਅਧਿਕਾਰ | T | Q3 decision; ਅਧਿਕਾਰ now free for "right/entitlement" | +| storage exhaustion (V5) | ਭੰਡਾਰਨ ਖ਼ਤਮ ਹੋ ਜਾਣਾ | ਭੰਡਾਰਨ ਥਕਾਵਟ | T | ਥਕਾਵਟ = tiredness, not depletion (fidelity fix) | +| stateless / stateful | ਸਟੇਟਲੈੱਸ / ਸਟੇਟਫੁੱਲ (glossed once) | Q8 open | L | First use in V7 decides per Q8; native ਸਥਿਤੀ-ਰਹਿਤ remains the alternative | +| entropy | ਐਂਟਰੋਪੀ | V7 had ਐਂਟਰੌਪੀ | L | Spelling normalised to V6 | +| must / must not | ਲਾਜ਼ਮੀ ਹੈ / ਨਹੀਂ … ਚਾਹੀਦਾ (hard prohibition) | several rows had softened to ਚਾਹੀਦਾ or "ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ" (cannot) | — | Modality must match the English; reviewers restored force in V1 1.5.2, V2 2.2.2, V3 3.4.6 | +| bypass | ਬਾਈਪਾਸ (bypass) | ਟਾਲਣਾ (= postpone) | L | Fidelity fix, V2 | +| resolve (DNS/entity/format string) | ਰਿਜ਼ੌਲਵ (resolve) | ਹੱਲ (= solve) | L | Fidelity fix, V1 | + +## Q14 — Retained-term-only headings (`## V4.3 GraphQL`, `## V4.4 WebSocket`) + +| | | +|---|---| +| **Current pick** | `## V4.3 GraphQL (ਗ੍ਰਾਫ਼ਕਿਊਐੱਲ)` — Latin term kept, Gurmukhi pronunciation in parentheses | +| **Alternatives** | (a) repeat the Latin heading unchanged for the Panjabi line; (b) append a Panjabi noun, e.g. `GraphQL ਸੁਰੱਖਿਆ` | +| **Reasoning** | Rule 4 says never transliterate R-terms, but the dual-block model needs a Panjabi heading line. Pronunciation-in-parens follows the README acronym column and keeps the term retrievable. Corpus-wide decision needed | + +## Q15 — New loan vs native picks in V1–V4 (batch) + +| EN term | Pick | Type | Alternative | +|---|---|---|---| +| escaping | ਐਸਕੇਪਿੰਗ | L | ਬਚਾਅ-ਚਿੰਨ੍ਹ ਲਗਾਉਣਾ (T, opaque) | +| interpreter | ਇੰਟਰਪ੍ਰੇਟਰ | L | ਵਿਆਖਿਆਕਾਰ (reads as human interpreter) | +| parameterized queries | ਪੈਰਾਮੀਟਰਾਈਜ਼ਡ ਕਿਊਰੀਆਂ | L | ਮਾਪਦੰਡੀ ਕਿਊਰੀਆਂ | +| canonical form | ਕੈਨੋਨੀਕਲ ਰੂਪ | L | ਮਿਆਰੀ ਰੂਪ (loses normalisation sense) | +| deserialization / parser | ਡੀਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ / ਪਾਰਸਰ | L | — | +| defense-in-depth | ਡੂੰਘਾਈ-ਵਿੱਚ-ਰੱਖਿਆ | T | ਬਹੁ-ਪਰਤੀ ਰੱਖਿਆ (arguably clearer) | +| weakness (vs vulnerability) | ਖ਼ਾਮੀ | T | ਕਮਜ਼ੋਰੀ is locked to vulnerability | +| untrusted | ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ | T | ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲਾ (V8 8.3.1, longer) | +| business logic | ਕਾਰੋਬਾਰੀ ਤਰਕ | T | ਵਪਾਰਕ ਤਰਕ | +| transaction (DB/atomic) | ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ | L | ਲੈਣ-ਦੇਣ (reads financial-only) | +| schema validation | ਸਕੀਮਾ ਪ੍ਰਮਾਣਿਕਤਾ | H | ਢਾਂਚਾ is locked to architecture | +| anti-automation | ਸਵੈਚਾਲਨ-ਵਿਰੋਧੀ | T | ਐਂਟੀ-ਆਟੋਮੇਸ਼ਨ | +| spoofing | ਸਪੂਫ਼ਿੰਗ | L | ਨਕਲ; ਭੇਸ-ਬਦਲੀ | +| origin / cross-origin (V3) | ਓਰਿਜਿਨ / ਕਰਾਸ-ਓਰਿਜਿਨ | L | ਮੂਲ (ambiguous with "by default"); V4 normalised to ਓਰਿਜਿਨਾਂ on 2026-08-22 | +| HTTP response | ਜਵਾਬ (0x03, V1, V4, V5, V6) / ਪ੍ਰਤੀਕਿਰਿਆ (V3 ×20) | T | **Inconsistent — corpus majority is ਜਵਾਬ; V3 left unchanged because the nouns differ in gender and a mechanical swap would break agreement. Needs a human pass on V3** | +| HTTP method | ਮੈਥਡ (method names Latin) | L | ਵਿਧੀ collides with generic "method/mechanism" | +| hostname | ਹੋਸਟਨੇਮ | L | ਹੋਸਟਨਾਮ (H) | +| nonce | ਨੌਂਸ | L | — | +| request smuggling / response splitting | ਬੇਨਤੀ ਸਮਗਲਿੰਗ / ਜਵਾਬ ਵਿਭਾਜਨ | H/T | retain Latin as attack names | +| introspection (GraphQL) | GraphQL introspection | R | ਆਤਮ-ਨਿਰੀਖਣ rejected (devotional connotation, Gurmat rule) | +| denial of service | ਸੇਵਾ-ਇਨਕਾਰ | T | V4 normalised on 2026-08-22 to the V2/V5 form | + +## Q16 — New picks in V6 / V7 (batch) + +| EN term | Pick | Type | Alternative | +|---|---|---|---| +| secret (noun) / Secret Management | ਭੇਦ / ਭੇਦ ਪ੍ਰਬੰਧਨ | T | ਗੁਪਤ (kept for adjectival "secret questions/keys") | +| assertion (SAML) | ਅਸਰਸ਼ਨ | L | ਕਥਨ; ਦਾਅਵਾ is reserved for JWT "claim" | +| push notification / push bombing | ਪੁਸ਼ ਸੂਚਨਾ / ਪੁਸ਼ ਬੌਂਬਿੰਗ | H/L | ਪੁਸ਼ ਨੋਟੀਫ਼ਿਕੇਸ਼ਨ / ਪੁਸ਼ ਬੰਬਾਰੀ | +| number matching | ਨੰਬਰ ਮਿਲਾਨ | T | ਨੰਬਰ ਮੈਚਿੰਗ | +| red flag | ਗੰਭੀਰ ਚੇਤਾਵਨੀ ਸੰਕੇਤ | T | ਲਾਲ ਝੰਡਾ (calque) | +| enterprise / throwaway identity | ਸੰਸਥਾਗਤ / ਅਸਥਾਈ ਪਛਾਣ | T | ਇੰਟਰਪ੍ਰਾਈਜ਼ / ਡਿਸਪੋਜ਼ੇਬਲ (L) | +| fallback | ਫ਼ਾਲਬੈਕ | L | ਬਦਲਵੀਂ ਪਹੁੰਚ | +| reference token | ਹਵਾਲਾ ਟੋਕਨ | T | ਰੈਫ਼ਰੈਂਸ ਟੋਕਨ | +| re-authentication | ਮੁੜ-ਪ੍ਰਮਾਣੀਕਰਨ | T | ਪੁਨਰ-ਪ੍ਰਮਾਣੀਕਰਨ | +| inactivity timeout / session lifetime | ਗ਼ੈਰ-ਸਰਗਰਮੀ ਸਮਾਂ-ਸੀਮਾ / ਸੈਸ਼ਨ ਜੀਵਨਕਾਲ | T | ਨਿਸ਼ਕਿਰਿਆ …; ਸੈਸ਼ਨ ਮਿਆਦ | +| federated / Relying Party | ਸੰਘੀ / ਨਿਰਭਰ ਧਿਰ | T | ਫ਼ੈਡਰੇਟਿਡ; ਭਰੋਸਾ ਕਰਨ ਵਾਲੀ ਧਿਰ | +| party | ਧਿਰ | T | V9 normalised from ਪੱਖ on 2026-08-22 | +| session hijacking | ਸੈਸ਼ਨ ਹਾਈਜੈਕਿੰਗ | L | ਸੈਸ਼ਨ ਅਗਵਾ | +| authenticity (V6 L13) | ਪ੍ਰਮਾਣਿਕਤਾ | T | collides with README "validation" = ਪ੍ਰਮਾਣਿਕਤਾ — glossary note | + +## Q17 — New picks in 0x03 What is the ASVS? (batch) + +| EN term | Pick | Type | Alternative | +|---|---|---|---| +| major / minor / patch release | ਮੇਜਰ / ਮਾਈਨਰ / ਪੈਚ ਰਿਲੀਜ਼ | L | ਮੁੱਖ / ਗੌਣ / ਪੈਚ (loses semver retrievability) | +| fork | ਫ਼ੋਰਕ | L | ਸ਼ਾਖਾ collides with git "branch" | +| architecture / architect | ਆਰਕੀਟੈਕਚਰ / ਆਰਕੀਟੈਕਟ | L | README says ਢਾਂਚਾ; chapters (V8/V12) use the loan — **glossary/corpus disagreement** | +| framework | ਫ੍ਰੇਮਵਰਕ | L | ਢਾਂਚਾ (already used for structure) | +| traceability / baseline | ਖੋਜਯੋਗਤਾ / ਆਧਾਰ-ਰੇਖਾ | T | ਟ੍ਰੇਸੇਬਿਲਟੀ / ਬੇਸਲਾਈਨ | +| breaking change | ਤੋੜਨ ਵਾਲੀ ਤਬਦੀਲੀ | T | ਬ੍ਰੇਕਿੰਗ ਚੇਂਜ | +| account enumeration | ਖਾਤਾ ਐਨੂਮਰੇਸ਼ਨ | H | ਖਾਤਾ ਸੂਚੀਕਰਨ | +| identifier | ਪਛਾਣਕਰਤਾ (corpus precedent) | T | ਪਛਾਣਕ (standard in Panjabi software localisation) | +| domain-specific | ਖੇਤਰ-ਵਿਸ਼ੇਸ਼ | T | ਡੋਮੇਨ-ਵਿਸ਼ੇਸ਼ reads as DNS domain | + +--- + +## Q18 — Introductory chapters retranslated to dual-block (0x04, 0x05) + `certification` pick + +| | | +|---|---| +| **What changed (2026-08-22)** | `0x04-Assessment_and_Certification.md` and `0x05-For-Users-Of-4.0.md` were Panjabi-only, code-switched drafts (English words such as *vendors, verifiers, software, compliance, requirements, scope, philosophy* left in Latin inside Panjabi sentences; ਪੁਸ਼ਟੀ for "verify"). Both were retranslated in full from the current upstream English in the dual-block format, QA-gated and independently reviewed. `0x01` gained the upstream Jim Manico acknowledgement sentence. | +| **certification / certify** | **ਸਰਟੀਫ਼ਿਕੇਸ਼ਨ** (L) — the first draft used ਪ੍ਰਮਾਣੀਕਰਨ, which is locked to *authentication*, so "OWASP does not certify vendors" read as "does not authenticate". Chapter title is now `ਮੁਲਾਂਕਣ ਅਤੇ ਸਰਟੀਫ਼ਿਕੇਸ਼ਨ`. Alternative: ਪ੍ਰਮਾਣ-ਪੱਤਰੀਕਰਨ (T, unattested). | +| **0x05 title** | `v4.x ਦੇ ਮੁਕਾਬਲੇ ਤਬਦੀਲੀਆਂ` (literal mirror of "Changes Compared to v4.x"); earlier wrapper pages said `v4.x ਤੋਂ ਤਬਦੀਲੀਆਂ`. | +| **New picks (0x04)** | trust mark→ਭਰੋਸਾ ਚਿੰਨ੍ਹ · assurance→ਭਰੋਸਾ · stance→ਰੁਖ਼ · vendor-neutral nonprofit→ਵਿਕਰੇਤਾ-ਨਿਰਪੱਖ ਗ਼ੈਰ-ਮੁਨਾਫ਼ਾ ਸੰਸਥਾ · prescriptive→ਨਿਰਦੇਸ਼ਾਤਮਕ · testing guide→ਟੈਸਟਿੰਗ ਮਾਰਗਦਰਸ਼ਿਕਾ · penetration testing→ਪੈਨੇਟ੍ਰੇਸ਼ਨ ਟੈਸਟਿੰਗ (L; spelling normalised corpus-wide) · by exception→ਅਪਵਾਦ ਦੇ ਆਧਾਰ 'ਤੇ · non-applicable→ਗ਼ੈਰ-ਲਾਗੂ · rationale→ਤਰਕ-ਆਧਾਰ · findings→ਖੋਜਾਂ · work papers→ਕਾਰਜ-ਪੱਤਰ · coverage→ਕਵਰੇਜ (L; ਘੇਰਾ is locked to scope) · black box→ਬਲੈਕ ਬਾਕਸ (L) · off-the-shelf→ਤਿਆਰ-ਬਰ-ਤਿਆਰ · discouraged→ਨਿਰਉਤਸ਼ਾਹਿਤ | +| **New picks (0x05)** | users of the standard→ਵਰਤੋਂਕਾਰ (application end-users stay ਉਪਭੋਗਤਾ) · philosophy→ਫ਼ਲਸਫ਼ਾ (ਦਰਸ਼ਨ rejected, devotional) · security goal→ਸੁਰੱਖਿਆ ਟੀਚਾ vs objective→ਸੁਰੱਖਿਆ ਉਦੇਸ਼ · prescriptiveness→ਨਿਰਦੇਸ਼ਾਤਮਕਤਾ · coupling→ਜੋੜ · fallacy→ਭੁਲੇਖਾ (ਭਰਮ rejected, maya overtone) · entry level→ਪ੍ਰਵੇਸ਼ ਪੱਧਰ · taxonomy→ਵਰਗੀਕਰਨ · access delegation→ਪਹੁੰਚ ਸੌਂਪਣ · single sign-on→ਸਿੰਗਲ ਸਾਈਨ-ਔਨ (L) · tick marks→ਟਿੱਕ ਚਿੰਨ੍ਹ · backwards compatibility→ਪਿਛਲੀ ਅਨੁਕੂਲਤਾ · legacy→ਪੁਰਾਣੇ (legacy) · relative→ਸਾਪੇਖਿਕ · Minimum/Standard/Advanced→"ਘੱਟੋ-ਘੱਟ"/"ਮਿਆਰੀ"/"ਉੱਨਤ" with English retained · standalone→ਸੁਤੰਤਰ · first-layer defense→ਪਹਿਲੀ-ਪਰਤ ਰੱਖਿਆ | +| **Reviewer notes** | _to be filled_ | + +--- + +## Q19 — August 2026 batch 3: V10, V11, V13–V17 (all security-requirement chapters now bilingual) + +**Status:** all 7 files translated, mechanically QA-gated, and independently fresh-context reviewed +(V10: 1 fidelity fix — removed an added definitional gloss not in the English; V14: 2 fixes — cross-reference +title mismatch + added content; V16: 1 fix — ਸੰਭਾਲ vs ਧਾਰਨ for "retention"; V17: 1 fix — dropped "either" in +a two-outcome clause; V11/V13/V15: 0 fixes, already fidelity-correct). + +### Corpus-wide normalisations applied in this batch +| Term | Was | Now | +|---|---|---| +| inventory (SBOM/asset) | ਵਸਤੂ-ਸੂਚੀ (V11) vs ਇਨਵੈਂਟਰੀ (V15, V16) | ਇਨਵੈਂਟਰੀ (L) — majority corpus usage | +| connection pool | ਸੰਪਰਕ ਪੂਲ (V13) vs ਕਨੈਕਸ਼ਨ (V4, V14, 0x05) | ਕਨੈਕਸ਼ਨ ਪੂਲ | +| retention | ਸੰਭਾਲ (V16, wrong — collides with "handling") vs ਧਾਰਨ (V14) | ਧਾਰਨ everywhere | +| error handling | ਗਲਤੀ ਸੰਭਾਲ (README, V17) vs ਗਲਤੀ ਪ੍ਰਬੰਧਨ (V14, V16) | ਗਲਤੀ ਪ੍ਰਬੰਧਨ everywhere; README row + romanisation fixed | +| encryption | ਇੰਕ੍ਰਿਪਸ਼ਨ (README) vs ਏਨਕ੍ਰਿਪਸ਼ਨ (corpus) | ਏਨਕ੍ਰਿਪਸ਼ਨ; README row + romanisation fixed | + +### New picks, still open / flagged for a corpus-wide decision +| Term | Pick(s) in use | Note | +|---|---|---| +| HTTP response | ਜਵਾਬ (majority) vs ਪ੍ਰਤੀਕਿਰਿਆ (V3) | unresolved since Q13 — needs a human pass on V3 (gender agreement) | +| configure (verb) | ਸੰਰਚਿਤ ਕਰਨਾ (V13) vs ਕੌਨਫ਼ਿਗਰ ਕਰਨਾ (V12) | pick one; ਸੰਰਚਨਾ is already the locked noun | +| connection (bare, not "pool") | ਸੰਪਰਕ (V12) vs ਕਨੈਕਸ਼ਨ (V4/V13/V14) | pick one | +| proxy | ਪ੍ਰੌਕਸੀ (majority, now incl. 0x03) vs ਪ੍ਰਾਕਸੀ | normalised to ਪ੍ਰੌਕਸੀ 2026-08-22 | +| rate limiting | ਦਰ ਸੀਮਾ (majority) vs ਦਰ-ਸੀਮਾ (hyphenated) | normalised to ਦਰ ਸੀਮਾ (no hyphen) 2026-08-22 | +| performance | ਪ੍ਰਦਰਸ਼ਨ (V5, V11) | alt ਕਾਰਗੁਜ਼ਾਰੀ considered, not adopted | +| compromise (security) | ਸਮਝੌਤਾ (V6, V12, V15) | primary dictionary sense is "agreement" — flagged by V15 reviewer, not changed pending Sangat input | +| documentation (process/heading noun) | ਦਸਤਾਵੇਜ਼ੀਕਰਨ (0x03, V3, V15) vs README's ਦਸਤਾਵੇਜ਼ (document) | not a conflict — different senses; README glossary should note the split | + +### Notable per-chapter picks (see individual translator reports for full lists) +- **V10 (OAuth/OIDC):** role/artifact names retained in Latin (Authorization Server, Resource Server, PKCE, DPoP, + PAR, RAR, JAR, JARM); Relying Party=ਨਿਰਭਰ ਧਿਰ, identity provider=ਪਛਾਣ ਪ੍ਰਦਾਤਾ, claim=ਦਾਅਵਾ, consent=ਸਹਿਮਤੀ. +- **V11 (Cryptography):** primitive=ਪ੍ਰਿਮਿਟਿਵ (L), KDF=ਕੁੰਜੀ-ਵਿਉਤਪੱਤੀ ਫੰਕਸ਼ਨ, IV=ਸ਼ੁਰੂਆਤੀ ਵੈਕਟਰ (IV), + collision resistant=ਟੱਕਰ-ਰੋਧਕ, constant-time=ਸਥਿਰ-ਸਮਾਂ, Padding Oracle/Fermat factorization retained as + named attacks (Q11/Q15 pattern). +- **V13 (Configuration):** service account=ਸੇਵਾ ਖਾਤਾ, vault=ਵਾਲਟ (L), hardened=ਸਖ਼ਤ ਕੀਤਾ, source control=ਸਰੋਤ + ਨਿਯੰਤਰਣ, build artifacts=ਬਿਲਡ ਆਰਟੀਫ਼ੈਕਟ (L). +- **V14 (Data Protection):** privacy-enhancing technologies=ਨਿੱਜਤਾ-ਵਧਾਊ ਤਕਨਾਲੋਜੀਆਂ, masked=ਮਾਸਕ ਕੀਤਾ (L), + Web Cache Deception retained as a named attack; client/browser storage=ਕਲਾਇੰਟ/ਬ੍ਰਾਊਜ਼ਰ ਭੰਡਾਰਨ (V6 uses + ਸਟੋਰੇਜ for password storage — different sense, not a conflict). +- **V15 (Secure Coding):** dependency/type confusion, TOCTOU=ਜਾਂਚ-ਦੇ-ਸਮੇਂ ਤੋਂ ਵਰਤੋਂ-ਦੇ-ਸਮੇਂ (TOCTOU), mass + assignment/type juggling/prototype pollution retained as named vulnerability classes. +- **V16 (Logging & Error Handling):** investigation=ਤਫ਼ਤੀਸ਼ (never ਜਾਂਚ, which is locked to "check"), + fail-open=ਫ਼ੇਲ-ਓਪਨ (L), circuit breaker=ਸਰਕਟ ਬ੍ਰੇਕਰ (L), correlation=ਸਹਿ-ਸੰਬੰਧ. +- **V17 (WebRTC):** flood (from legitimate users)=ਹੜ੍ਹ kept distinct from DoS=ਸੇਵਾ-ਇਨਕਾਰ (attack); TURN/SFU/MCU + expansions retained Latin; heading pattern `## V17.1 TURN ਸਰਵਰ` (mixed, since "Server" translates — differs + from the pure-retained-term Q14 pattern used for the chapter H1 itself). + +--- + +## Maintainer + +Gurvinder Singh, CISSP · CISA · GWAPT — [securityleader.ai](https://securityleader.ai) · [@GeeksikhSecurity](https://github.com/GeeksikhSecurity) diff --git a/5.0/pa-IN/README.md b/5.0/pa-IN/README.md new file mode 100644 index 0000000000..5eb26f16c2 --- /dev/null +++ b/5.0/pa-IN/README.md @@ -0,0 +1,180 @@ +# OWASP Application Security Verification Standard 5.0 - Panjabi + +## ਓਵਾਸਪ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਤਸਦੀਕ ਮਿਆਰ 5.0 + +[![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/4.0/88x31.png)](https://creativecommons.org/licenses/by-sa/4.0/) +[![Panjabi Translation](https://img.shields.io/badge/Translation-Panjabi-orange)](https://github.com/GeeksikhSecurity/ASVS) + +ਇਹ OWASP Application Security Verification Standard (ASVS) ਸੰਸਕਰਣ 5.0 ਦਾ ਅਧਿਕਾਰਤ ਪੰਜਾਬੀ ਅਨੁਵਾਦ ਹੈ। + +This is the official Panjabi translation of the OWASP Application Security Verification Standard (ASVS) version 5.0. + +## ਬਾਰੇ | About + +The OWASP ASVS ਇੱਕ ਸੁਰੱਖਿਆ ਮਿਆਰ ਹੈ ਜੋ ਸੁਰੱਖਿਅਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਡਿਜ਼ਾਈਨ, ਵਿਕਾਸ ਅਤੇ ਟੈਸਟਿੰਗ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। + +## ਅਨੁਵਾਦ ਟੀਮ | Translation Team + +- **ਮੁੱਖ ਅਨੁਵਾਦਕ | Lead Translator**: [GeeksikhSecurity](https://github.com/GeeksikhSecurity) +- **ਸਮੀਖਿਅਕ | Reviewers**: [ਯੋਗਦਾਨ ਲਈ ਖੁੱਲ੍ਹਾ | Open for contributions] + +## ਅਨੁਵਾਦ ਦੀ ਸਥਿਤੀ | Translation Status + +🚧 **ਕੰਮ ਜਾਰੀ ਹੈ | Work in Progress** + +ਵੇਰਵਿਆਂ ਲਈ [TRANSLATION-NOTES.md](TRANSLATION-NOTES.md) ਵੇਖੋ। | See [TRANSLATION-NOTES.md](TRANSLATION-NOTES.md) for details. + +## ਅਨੁਵਾਦ ਸੰਮੇਲਨ | Translation Conventions + +ਇਹ ਅਨੁਵਾਦ **ਦੋਭਾਸ਼ੀ (bilingual)** ਫਾਰਮੈਟ ਵਰਤਦਾ ਹੈ — ਹਰੇਕ ਅੰਗਰੇਜ਼ੀ ਪੈਰਾਗ੍ਰਾਫ਼ ਤੋਂ ਬਾਅਦ ਪੰਜਾਬੀ (ਗੁਰਮੁਖੀ) ਅਨੁਵਾਦ ਦਿੱਤਾ ਗਿਆ ਹੈ। + +This translation uses a **bilingual** format — each English paragraph is followed by its Panjabi (Gurmukhi) translation. + +### ਸ਼ਬਦ ਵਰਗੀਕਰਨ | Term Classification + +| ਕਿਸਮ (Type) | ਵਰਣਨ | Description | +|:---:|---|---| +| **T** | ਅਨੁਵਾਦ — ਪੰਜਾਬੀ ਸ਼ਬਦ ਮੌਜੂਦ ਹੈ | Translate — Panjabi word exists | +| **L** | ਲਿਪੀਅੰਤਰਣ — ਅੰਗਰੇਜ਼ੀ ਗੁਰਮੁਖੀ ਵਿੱਚ | Transliterate — English rendered in Gurmukhi | +| **R** | ਅੰਗਰੇਜ਼ੀ ਰੱਖੋ — ਯੂਨੀਵਰਸਲ ਐਕਰੋਨਿਮ | Retain English — Universal acronyms | +| **H** | ਮਿਸ਼ਰਤ — ਗੁਰਮੁਖੀ + ਅੰਗਰੇਜ਼ੀ | Hybrid — Gurmukhi + English | + +## ਸ਼ਬਦਾਵਲੀ | Glossary + +### ਮੁੱਖ ਸ਼ਬਦ | Core Terms + +| English | ਗੁਰਮੁਖੀ | Romanized / ਰੋਮਨ ਲਿਪੀ | ਕਿਸਮ | +|---------|---------|----------------------|:---:| +| Security | ਸੁਰੱਖਿਆ | surakkhiā | T | +| Verification | ਤਸਦੀਕ | tasdīk | T | +| Standard | ਮਿਆਰ | miār | T | +| Application | ਐਪਲੀਕੇਸ਼ਨ | aipalīkeshan | L | +| Requirement | ਲੋੜ | loṛ | T | +| Level | ਪੱਧਰ | paddhar | T | +| Control | ਨਿਯੰਤਰਣ | niyaṅtraṇ | T | +| Scope | ਘੇਰਾ | gherā | T | +| Objective | ਉਦੇਸ਼ | udesh | T | +| Documentation | ਦਸਤਾਵੇਜ਼ | dastāvez | T | + +### ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਪਛਾਣ | Authentication & Identity + +| English | ਗੁਰਮੁਖੀ | Romanized / ਰੋਮਨ ਲਿਪੀ | ਕਿਸਮ | +|---------|---------|----------------------|:---:| +| Authentication | ਪ੍ਰਮਾਣੀਕਰਨ | pramāṇīkaran | T | +| Authorization | ਅਧਿਕਾਰੀਕਰਨ | adhikārīkaraṇ | T | +| Identity | ਪਛਾਣ | pachāṇ | T | +| Credential | ਪ੍ਰਮਾਣ-ਪੱਤਰ | pramāṇ-pattar | T | +| Password | ਪਾਸਵਰਡ | pāsvarḍ | L | +| Multi-factor authentication | ਬਹੁ-ਕਾਰਕ ਪ੍ਰਮਾਣੀਕਰਨ | bahu-kārak pramāṇīkaran | T | +| Identity Provider (IdP) | ਪਛਾਣ ਪ੍ਰਦਾਤਾ | pachāṇ pradātā | T | +| One-time Password (OTP) | ਇੱਕ-ਵਾਰੀ ਪਾਸਵਰਡ | ikk-vārī pāsvarḍ | H | +| Passkey | ਪਾਸਕੀ | pāskī | L | +| Session | ਸੈਸ਼ਨ | saishan | L | +| Session Management | ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ | saishan prabanndh | H | +| Timeout | ਸਮਾਂ-ਸੀਮਾ | samāṅ-sīmā | T | +| Token | ਟੋਕਨ | ṭokan | L | + +### ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ | Cryptography + +| English | ਗੁਰਮੁਖੀ | Romanized / ਰੋਮਨ ਲਿਪੀ | ਕਿਸਮ | +|---------|---------|----------------------|:---:| +| Cryptography | ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ | kripṭogrāfī | L | +| Encryption | ਏਨਕ੍ਰਿਪਸ਼ਨ | enkripshan | L | +| Hash | ਹੈਸ਼ | haish | L | +| Digital Signature | ਡਿਜ਼ੀਟਲ ਦਸਤਖ਼ਤ | ḍizīṭal dastakhat | H | +| Key | ਕੁੰਜੀ | kunjī | T | +| Certificate | ਸਰਟੀਫਿਕੇਟ | sarṭīfikeṭ | L | +| Public Key Infrastructure (PKI) | ਜਨਤਕ ਕੁੰਜੀ ਢਾਂਚਾ | jantak kunjī ḍhāṅchā | T | +| Transport Layer Security (TLS) | ਟ੍ਰਾਂਸਪੋਰਟ ਲੇਅਰ ਸੁਰੱਖਿਆ | ṭrāṅsporṭ leyar surakkhiā | H | + +### ਹਮਲੇ ਅਤੇ ਕਮਜ਼ੋਰੀਆਂ | Attacks & Vulnerabilities + +| English | ਗੁਰਮੁਖੀ | Romanized / ਰੋਮਨ ਲਿਪੀ | ਕਿਸਮ | +|---------|---------|----------------------|:---:| +| Vulnerability | ਕਮਜ਼ੋਰੀ | kamzorī | T | +| Threat | ਖ਼ਤਰਾ | khatrā | T | +| Attack | ਹਮਲਾ | hamlā | T | +| Injection | ਇੰਜੈਕਸ਼ਨ | iṅjaikshan | L | +| SQL Injection (SQLi) | ਐੱਸ.ਕਿਊ.ਐੱਲ। ਇੰਜੈਕਸ਼ਨ | ais.kiū.ail. iṅjaikshan | L | +| Cross-Site Scripting (XSS) | ਕਰਾਸ-ਸਾਈਟ ਸਕ੍ਰਿਪਟਿੰਗ | karās-sāīṭ skripṭiṅg | L | +| Server-side Request Forgery (SSRF) | ਸਰਵਰ-ਪੱਖੀ ਬੇਨਤੀ ਜਾਅਲਸਾਜ਼ੀ | sarvar-pakkhī bentī jāalsāzī | H | +| Brute Force | ਬਰੂਟ ਫੋਰਸ | barūṭ fors | L | +| Malware | ਮਾਲਵੇਅਰ | mālveyar | L | +| Forgery | ਜਾਅਲਸਾਜ਼ੀ | jāalsāzī | T | +| Threat Modeling | ਖ਼ਤਰਾ ਮਾਡਲਿੰਗ | khatrā māḍliṅg | H | + +### ਡਾਟਾ ਸੁਰੱਖਿਆ | Data Protection + +| English | ਗੁਰਮੁਖੀ | Romanized / ਰੋਮਨ ਲਿਪੀ | ਕਿਸਮ | +|---------|---------|----------------------|:---:| +| Data Protection | ਡਾਟਾ ਸੁਰੱਖਿਆ | ḍāṭā surakkhiā | H | +| Privacy | ਨਿੱਜਤਾ | nijjatā | T | +| Confidentiality | ਗੁਪਤਤਾ | guptatā | T | +| Integrity | ਅਖੰਡਤਾ | akhaṇḍatā | T | +| Availability | ਉਪਲਬਧਤਾ | upalabdhatā | T | + +### ਵੈੱਬ ਅਤੇ ਏ.ਪੀ.ਆਈ। | Web & API + +| English | ਗੁਰਮੁਖੀ | Romanized / ਰੋਮਨ ਲਿਪੀ | ਕਿਸਮ | +|---------|---------|----------------------|:---:| +| Web Service | ਵੈੱਬ ਸੇਵਾ | vaib sevā | H | +| Web Frontend | ਵੈੱਬ ਫਰੰਟਐਂਡ | vaib fraṅṭaiṅḍ | L | +| Cookie | ਕੁਕੀ | kukī | L | +| Encoding | ਏਨਕੋਡਿੰਗ | enkoḍiṅg | L | +| Sanitization | ਸੈਨੀਟਾਈਜ਼ੇਸ਼ਨ | sainīṭāīzeshan | L | +| Validation | ਪ੍ਰਮਾਣਿਕਤਾ | pramāṇiktā | T | +| Input Validation | ਇਨਪੁੱਟ ਪ੍ਰਮਾਣਿਕਤਾ | inpuṭṭ pramāṇiktā | H | +| Allowlist | ਮਨਜ਼ੂਰੀ ਸੂਚੀ | manzūrī sūchī | T | +| File Handling | ਫਾਈਲ ਸੰਭਾਲ | fāīl saṅbhāl | H | + +### ਟੈਸਟਿੰਗ ਅਤੇ ਵਿਕਾਸ | Testing & Development + +| English | ਗੁਰਮੁਖੀ | Romanized / ਰੋਮਨ ਲਿਪੀ | ਕਿਸਮ | +|---------|---------|----------------------|:---:| +| SAST | ਸਥਿਰ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ | sathir aipalīkeshan surakkhiā ṭaisṭiṅg | H | +| DAST | ਗਤੀਸ਼ੀਲ ਐਪਲੀਕੇਸ਼ਨ ਸੁਰੱਖਿਆ ਟੈਸਟਿੰਗ | gatīshīl aipalīkeshan surakkhiā ṭaisṭiṅg | H | +| Verifier | ਤਸਦੀਕਕਰਤਾ | tasdīkkartā | T | +| Architecture | ਢਾਂਚਾ | ḍhāṅchā | T | +| Configuration | ਸੰਰਚਨਾ | saṅrachnā | T | +| Secure Coding | ਸੁਰੱਖਿਅਤ ਕੋਡਿੰਗ | surakhiat koḍiṅg | H | +| Error Handling | ਗਲਤੀ ਪ੍ਰਬੰਧਨ | galtī prabandhan | T | +| Logging | ਲੌਗਿੰਗ | laugiṅg | L | +| SDLC | ਸਾਫ਼ਟਵੇਅਰ ਵਿਕਾਸ ਜੀਵਨ-ਚੱਕਰ | sāfṭveyar vikās jīvan-chakkar | H | +| SBOM | ਸਾਫ਼ਟਵੇਅਰ ਸਮੱਗਰੀ ਸੂਚੀ | sāfṭveyar samaggrī sūchī | H | + +### ਐਕਰੋਨਿਮ (ਅੰਗਰੇਜ਼ੀ ਰੱਖੋ) | Acronyms (Retain English) + +| Acronym | Full Form | ਗੁਰਮੁਖੀ ਉਚਾਰਨ | +|---------|-----------|------------| +| OWASP | Open Worldwide Application Security Project | ਓਵਾਸਪ | +| ASVS | Application Security Verification Standard | ਏ.ਐਸ.ਵੀ.ਐਸ। | +| API | Application Programming Interface | ਏ.ਪੀ.ਆਈ। | +| HTTP / HTTPS | HyperText Transfer Protocol (Secure) | ਐੱਚ.ਟੀ.ਟੀ.ਪੀ.(ਐੱਸ.) | +| TLS | Transport Layer Security | ਟੀ.ਐੱਲ.ਐੱਸ। | +| JWT | JSON Web Token | ਜੇ.ਡਬਲਯੂ.ਟੀ। | +| OAuth | Open Authorization | ਓਅਥ | +| OIDC | OpenID Connect | ਓ.ਆਈ.ਡੀ.ਸੀ। | +| SAML | Security Assertion Markup Language | ਐੱਸ.ਏ.ਐੱਮ.ਐੱਲ। | +| MFA | Multi-factor Authentication | ਐੱਮ.ਐੱਫ਼.ਏ। | +| NIST | National Institute of Standards and Technology | ਐੱਨ.ਆਈ.ਐੱਸ.ਟੀ। | +| CWE | Common Weakness Enumeration | ਸੀ.ਡਬਲਯੂ.ਈ। | +| SIEM | Security Information and Event Management | ਐੱਸ.ਆਈ.ਈ.ਐੱਮ। | +| WebRTC | Web Real-Time Communication | ਵੈੱਬਆਰ.ਟੀ.ਸੀ। | + +> **ਪੂਰੀ ਸ਼ਬਦਾਵਲੀ** (152+ ਸ਼ਬਦ) ਲਈ ਵੇਖੋ: [OWASP ASVS Glossary (JSON)](https://github.com/GeeksikhSecurity/ASVS/blob/panjabi-translation-v5/5.0/pa-IN/asvs_glossary.json) + +## ਯੋਗਦਾਨ | Contributing + +ਅਸੀਂ ਪੰਜਾਬੀ ਬੋਲਣ ਵਾਲੇ ਸੁਰੱਖਿਆ ਪੇਸ਼ੇਵਰਾਂ ਦਾ ਸਵਾਗਤ ਕਰਦੇ ਹਾਂ। + +We welcome contributions from Panjabi-speaking security professionals. + +### ਸਮੀਖਿਆ ਕਿਵੇਂ ਕਰੀਏ | How to Review + +1. ਫ਼ਾਈਲਾਂ ਵਿੱਚ ਅੰਗਰੇਜ਼ੀ ਅਤੇ ਪੰਜਾਬੀ ਦੀ ਤੁਲਨਾ ਕਰੋ | Compare English and Panjabi in each file +2. ਗੁਰਮੁਖੀ ਸ਼ਬਦ-ਜੋੜ ਦੀ ਜਾਂਚ ਕਰੋ | Check Gurmukhi spelling +3. ਤਕਨੀਕੀ ਸ਼ੁੱਧਤਾ ਦੀ ਤਸਦੀਕ ਕਰੋ | Verify technical accuracy +4. GitHub issue ਜਾਂ PR comment ਰਾਹੀਂ ਫ਼ੀਡਬੈਕ ਦਿਓ | Provide feedback via GitHub issue or PR comment + +--- +*Translation maintained by [GeeksikhSecurity](https://github.com/GeeksikhSecurity)* diff --git a/5.0/pa-IN/REVIEW-PLAN.md b/5.0/pa-IN/REVIEW-PLAN.md new file mode 100644 index 0000000000..bb1daaf68e --- /dev/null +++ b/5.0/pa-IN/REVIEW-PLAN.md @@ -0,0 +1,227 @@ +# OWASP ASVS 5.0 — Bilingual Panjabi (pa-IN) Translation + +## Peer Review Plan for Security Researchers + +**PR:** [#3254](https://github.com/OWASP/ASVS/pull/3254) · **Branch:** `GeeksikhSecurity:panjabi-translation-v5` +**Lead Translator:** Gurvinder Singh ([@GeeksikhSecurity](https://github.com/GeeksikhSecurity)) +**Script:** Gurmukhi (ਗੁਰਮੁਖੀ) · **ISO Code:** pa-IN +**Spelling Convention:** "Panjabi" per Sikhri.org and Panjab Digital Library standards +**Co-Author:** Claude Opus 4.8 (AI-assisted translation with human oversight) + +> **For a focused, shareable reviewer briefing, see [`REVIEWER-NOTES.md`](./REVIEWER-NOTES.md).** That file is the recommended starting point for anyone you ask to review. This document is the longer-form plan and phase roadmap. + +--- + +## Current status (2026-06-02) + +**8 chapters Complete, 2 In Progress, 24 commits on the PR.** + +| Complete | In Progress | Pending | +|---|---|---| +| 0x01 Frontispiece | 0x03 What-is-the-ASVS | V1, V2, V3, V4, V7, V10, V11, V13, V14, V15, V16, V17 | +| 0x02 Preface | 0x15 V6 Authentication | Appendices A–E, 0x00 header | +| 0x04 Assessment & Certification | | | +| 0x05 For Users of 4.0 | | | +| 0x14 V5 File Handling | | | +| 0x17 V8 Authorization | | | +| 0x18 V9 Self-contained Tokens | | | +| 0x21 V12 Secure Communication | | | + +**Cadence:** 2–3 chapters/week, small-first sequencing. **Open decisions:** 12 in [`OPEN-QUESTIONS.md`](./OPEN-QUESTIONS.md) — Q12 (bilingual structure) is the highest-priority and is deferred to community review. + +--- + +## What's Been Completed (Phase A) + +The following files are committed and ready for review in commit [`aa38595`](https://github.com/OWASP/ASVS/pull/3254/commits/aa38595242a82d9cda4913176f26d22c72585377): + +| File | Description | Word Count | +|------|-------------|------------| +| `5.0/pa-IN/0x01-Frontispiece.md` | Bilingual frontispiece — copyright, project leads, contributors | ~400 | +| `5.0/pa-IN/0x02-Preface.md` | Bilingual preface — ASVS 5.0 principles, levels, scope | ~800 | +| `5.0/pa-IN/README.md` | Project README with 100+ term glossary (Gurmukhi + romanization) | ~2,500 | +| `5.0/pa-IN/TRANSLATION-NOTES.md` | QA checklist, phased progress, terminology decisions | ~1,000 | +| `GIT-CHEATSHEET.md` | PR workflow reference for contributors | ~300 | + +**Total across 27 planned files:** ~38,372 words (English source) + +--- + +## Translation Format + +Every section follows a consistent bilingual pattern for reviewer clarity: + +```markdown +## English Heading +## ਪੰਜਾਬੀ ਸਿਰਲੇਖ + +English paragraph text here. + +ਪੰਜਾਬੀ ਅਨੁਵਾਦ ਇੱਥੇ (with parenthetical English for key terms)। +``` + +Key conventions: +- English paragraph first, Panjabi translation immediately below +- Technical terms preserved in English with Gurmukhi transliteration on first use +- Western numerals in technical prose, including version numbers (e.g., 5.0, not ੫.੦) +- No Devanagari script — all Unicode validated as clean Gurmukhi + +--- + +## Glossary Classification System + +Each term in the README glossary is tagged with one of four categories: + +| Tag | Meaning | Example | +|-----|---------|---------| +| **T** | Translated | Authentication → ਪ੍ਰਮਾਣੀਕਰਨ | +| **L** | Loan word (transliterated) | API → ਏ.ਪੀ.ਆਈ। | +| **R** | Retained in English | OWASP, SQL, XSS | +| **H** | Hybrid (Panjabi + English) | SQL Injection → SQL ਇੰਜੈਕਸ਼ਨ | + +The glossary currently contains 100+ security terms organized by ASVS chapter domain. + +--- + +## What Reviewers Should Look For + +### 1. Translation Accuracy + +- Does the Panjabi text faithfully convey the security meaning of the English source? +- Are technical nuances preserved (e.g., "verify" vs. "validate" vs. "check")? +- Do the ASVS requirement IDs (e.g., v5.0.0-2.1.7) remain intact and unmodified? + +### 2. Terminology Consistency + +- Is the same Panjabi term used for the same English concept throughout? +- Does the T/L/R/H classification make sense for each term? +- Are there terms that should be translated differently for the Panjabi security audience? + +### 3. Gurmukhi Script Quality + +- No Devanagari characters mixed in (common error in Panjabi digital text) +- Proper use of Gurmukhi vowel signs (ਮਾਤਰਾ) and conjuncts +- Clean Unicode — no invisible control characters or zero-width joiners where not needed + +### 4. Readability for Panjabi-Speaking Developers + +- Would a developer in Punjab (India or Pakistan) understand this without constantly referring to the English? +- Is the sentence structure natural Panjabi, or does it read like a word-for-word transliteration? +- Are parenthetical English terms helpful or excessive? + +### 5. Structural & Markdown Integrity + +- Bilingual format is consistent (English first, Panjabi below) +- Markdown renders correctly (tables, links, headings, lists) +- Image paths use relative references (`../images/`) for portability + +--- + +## Remaining Phases (B–D) + +### Phase B — Core Chapters (Target: March–April 2026) + +| File | ASVS Chapter | Priority | +|------|-------------|----------| +| `0x03-Using-ASVS.md` | How to use the standard | High | +| `0x04-Assessment-and-Certification.md` | Assessment guidance | High | +| `0x10-V1-Architecture.md` | V1: Architecture & Threat Modeling | High | +| `0x11-V2-Authentication.md` | V2: Authentication | High | +| `0x12-V3-Session-Management.md` | V3: Session Management | High | +| `0x13-V4-Access-Control.md` | V4: Access Control | High | + +### Phase C — Security Requirement Chapters (Target: May–July 2026) + +| File | ASVS Chapter | +|------|-------------| +| `0x14-V5-Encoding-Sanitization.md` | V5: Encoding & Sanitization | +| `0x15-V6-Stored-Cryptography.md` | V6: Cryptography | +| `0x16-V7-Error-Logging.md` | V7: Error Handling & Logging | +| `0x17-V8-Data-Protection.md` | V8: Data Protection | +| `0x18-V9-Communication.md` | V9: Communication Security | +| `0x19-V10-Malicious-Code.md` | V10: Malicious Code | +| `0x20-V11-BusLogic.md` | V11: Business Logic | +| `0x21-V12-Files-Resources.md` | V12: Files & Resources | +| `0x22-V13-API-Web-Service.md` | V13: API & Web Service | +| `0x23-V14-Config.md` | V14: Configuration | +| `0x50-V50-WebFrontend.md` | V50: Web Frontend | +| `0x51-V51-OAuth-OIDC.md` | V51: OAuth & OIDC | +| `0x52-V52-SelfContained-Tokens.md` | V52: Self-Contained Tokens | + +### Phase D — Appendices & Final QA (Target: August 2026) + +- Appendices (A through E) +- Glossary finalization +- Full cross-reference validation +- PDF generation +- Community review period (4 weeks) + +--- + +## How to Contribute a Review + +### Quick Review (15 minutes) + +1. Open PR [#3254](https://github.com/OWASP/ASVS/pull/3254) +2. Click "Files changed" tab +3. Read through any `.md` file in `5.0/pa-IN/` +4. Leave inline comments on specific lines +5. Focus on: accuracy, natural phrasing, term choices + +### Detailed Review (1–2 hours) + +1. Fork the repo and checkout the `panjabi-translation-v5` branch +2. Review the glossary in `README.md` for term consistency +3. Cross-reference Panjabi text against the English source in `5.0/en/` +4. Check `TRANSLATION-NOTES.md` for any open terminology decisions +5. Submit a review with suggestions via GitHub PR review + +### Reviewer Qualifications (any one or more) + +- Panjabi speaker with security domain knowledge +- Security researcher who can validate English source accuracy +- Linguist with Gurmukhi expertise (script/grammar review) +- OWASP community member familiar with ASVS structure + +--- + +## Terminology Decision Log (Open Questions) + +These terms need community input — add your preference as a PR comment: + +| English Term | Current Panjabi | Alternative | Status | +|-------------|----------------|-------------|--------| +| Verification | ਤਸਦੀਕ | ਪੜਤਾਲ | Under review | +| Standard | ਮਿਆਰ | ਪੱਧਰ / ਕਸਵਟੀ | Accepted as ਮਿਆਰ | +| Requirement | ਲੋੜ | ਸ਼ਰਤ | Under review | +| Vulnerability | ਕਮਜ਼ੋਰੀ | ਕਮੀ | Under review | +| Threat Modeling | ਖ਼ਤਰਾ ਮਾਡਲਿੰਗ | ਖ਼ਤਰਾ ਨਮੂਨਾਕਰਨ | Under review | + +--- + +## Project Links + +| Resource | Link | +|----------|------| +| Pull Request | [OWASP/ASVS #3254](https://github.com/OWASP/ASVS/pull/3254) | +| Fork Repository | [GeeksikhSecurity/ASVS](https://github.com/GeeksikhSecurity/ASVS/tree/panjabi-translation-v5) | +| ASVS 5.0 English Source | [OWASP/ASVS/5.0/en](https://github.com/OWASP/ASVS/tree/master/5.0/en) | +| Related Issues | [#3252](https://github.com/OWASP/ASVS/issues/3252), [#3253](https://github.com/OWASP/ASVS/issues/3253) | +| Other ASVS Translations | [Spanish #3238](https://github.com/OWASP/ASVS/issues/3238), [Russian #3223](https://github.com/OWASP/ASVS/issues/3223), [Korean #3204](https://github.com/OWASP/ASVS/issues/3204) | +| OWASP Translation Guide | [CONTRIBUTING.md](https://github.com/OWASP/ASVS/blob/master/CONTRIBUTING.md) | + +--- + +## Contact + +- **GitHub:** [@GeeksikhSecurity](https://github.com/GeeksikhSecurity) +- **Platform:** [SecurityLeader.ai](https://securityleader.ai) +- **OWASP Slack:** Join `#asvs` channel + +> *"ਸੁਰੱਖਿਆ ਗਿਆਨ ਸਭ ਲਈ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ"* +> *Security knowledge should be accessible to all.* + +--- + +*Last updated: February 23, 2026* +*License: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)* diff --git a/5.0/pa-IN/REVIEWER-NOTES.md b/5.0/pa-IN/REVIEWER-NOTES.md new file mode 100644 index 0000000000..428ec20228 --- /dev/null +++ b/5.0/pa-IN/REVIEWER-NOTES.md @@ -0,0 +1,126 @@ +# Reviewer Notes — OWASP ASVS 5.0 Panjabi (pa-IN) Translation + +**Share this file with anyone you ask to review the translation.** It is a self-contained briefing: what's done, what to check, how to give feedback, and where the open decisions are. + +- **PR:** [OWASP/ASVS#3254](https://github.com/OWASP/ASVS/pull/3254) (Draft) +- **Branch:** `GeeksikhSecurity:panjabi-translation-v5` +- **Lead translator:** Gurvinder Singh, CISSP · CISA · GWAPT — [@GeeksikhSecurity](https://github.com/GeeksikhSecurity) · [securityleader.ai](https://securityleader.ai) +- **Method:** AI-assisted draft (v0.1) with human author review; community/sangat review is the certification gate — no AI output self-certifies above v0.1 +- **Last updated:** 2026-06-02 + +--- + +## You do not need to be both things + +Either qualification helps — you don't need both: + +- **Panjabi / Gurmukhi reader** — does it read naturally? Are the term choices right? Any script errors? +- **Security practitioner** — is the English meaning preserved? Could a translation choice mislead an implementer? + +A linguist with no security background and a security engineer with no Panjabi are *both* useful reviewers. + +--- + +## What's ready to review right now + +**Complete chapters (8)** — these should be defect-free; review for accuracy and naturalness: + +| File | Chapter | Shortest-to-start | +|---|---|---| +| `0x18-V9-Self-contained-Tokens.md` | JWT / token validation | ⭐ start here (small) | +| `0x04-Assessment_and_Certification.md` | assessment guidance | ⭐ start here (small) | +| `0x21-V12-Secure-Communication.md` | TLS / transport security | | +| `0x14-V5-File-Handling.md` | file upload/download | | +| `0x17-V8-Authorization.md` | access control / POLP | | +| `0x05-For-Users-Of-4.0.md` | changes from v4.x | | +| `0x01-Frontispiece.md` | title page / credits | | +| `0x02-Preface.md` | intro / principles / levels | | + +**In progress (2)** — headings + structure are bilingual, bodies still being translated; comment on terminology if you like, but expect English-heavy bodies: + +- `0x03-What-is-the-ASVS.md` +- `0x15-V6-Authentication.md` + +**Supporting:** `README.md`, `CLAUDE.md` (translation rules), `OPEN-QUESTIONS.md` (deferred decisions), `TRANSLATION-NOTES.md`, `REVIEW-PLAN.md`. + +--- + +## The single most important thing to weigh in on + +**`OPEN-QUESTIONS.md` → Q12: bilingual structure (dual-block vs code-switched).** The corpus currently has two different structures and the choice is genuinely *unmade*. Your preference here shapes every future chapter. See Q12 for the full comparison; the one-line ask is: Pattern A everywhere, Pattern B everywhere, or mixed-by-chapter-type? + +After Q12, the other 11 questions in `OPEN-QUESTIONS.md` are individual terminology calls (e.g., `multi-tenant`, `self-contained token`, `audience` claim) — lighter-weight, also welcome. + +--- + +## What to look for + +### 1. Translation accuracy +- Does the Panjabi faithfully convey the security *meaning*, not just the words? +- Are close-but-distinct verbs preserved — "verify" / "validate" / "check"? +- Requirement IDs (e.g., `8.2.2`, `12.1.3`) must stay **exactly** as in English. Flag any that drifted. + +### 2. Terminology consistency +- Same English concept → same Panjabi term across every chapter? +- The glossary lives on the public site: [securityleader.ai/blog/asvs-panjabi-review-glossary](https://securityleader.ai/blog/asvs-panjabi-review-glossary) (68 terms, with T/L/R/H classification). + +### 3. Gurmukhi script quality +- **No Devanagari** letters mixed in (a common digital-Panjabi error). Note: the sentence-end danda `।` (U+0964) is *correct* and intentional — not an error. +- Proper vowel signs (ਮਾਤਰਾ), addak, bindi/tippi, nukta. +- Clean Unicode — no stray zero-width joiners. + +### 4. Readability for a Panjabi-speaking developer +- Would a developer in Punjab understand this without constantly falling back to the English? +- Natural Panjabi sentence flow, or does it read like a word-for-word transliteration? +- Are the parenthetical English terms helpful, or excessive? + +### 5. Gurmat / cultural fit +- Per `CLAUDE.md`: no yoga/Hindu/Sanskrit-rooted vocabulary outside a direct Gurbani quotation. (Example already caught and fixed: "security posture" was `ਮੁਦਰਾ` — yoga-connoted — now `ਸਥਿਤੀ`.) +- If a term feels culturally off, say so even if it's technically accurate. + +--- + +## Policy locks (already decided — please don't re-litigate inline) + +These are corpus-wide and intentional. If you disagree with one, open a **separate GitHub issue** rather than commenting on individual lines (changing a lock means changing many chapters at once): + +| Lock | Rule | +|---|---| +| **Fraud term** | Standalone "scam/fraud" is always `ਠੱਗੀ`; the only allowed `ਫ਼ਰਾਡ` compound is `ਰੋਮਾਂਸ ਫ਼ਰਾਡ` | +| **Community** | `ਭਾਈਚਾਰਾ` for generic "community"; `ਸੰਗਤ` only in named Sikh religious contexts | +| **Romanization** | IAST canonical: `ṭ ḍ ṇ ā ī ū ṅ ñ chh ʼ` — not doubled-vowel English style (`ṭhaggī`, not `thaggee`) | +| **Sentence-end** | Indic danda `।` (U+0964), never the Western period `.`, for Panjabi prose | +| **Script** | No Devanagari letters (U+0900–U+0963, U+0966–U+097F); danda U+0964 and double-danda U+0965 are allowed shared punctuation | +| **Spelling** | "Panjabi" (not "Punjabi") per Sikhri.org / Panjab Digital Library | + +--- + +## How to send feedback + +**Easiest — email (no GitHub needed):** +- To **gurvinder@securityleader.ai** +- Subject: **"ASVS Panjabi Review"** (or **"ASVS Panjabi Review — Q12"** etc. for a specific open question) +- Even one term correction is valuable. Quote the file and line if you can. + +**GitHub PR review:** +1. Open [PR #3254](https://github.com/OWASP/ASVS/pull/3254), click **Files changed** +2. Read any `.md` in `5.0/pa-IN/` +3. Leave inline comments on specific lines +4. For the structural Q12 decision, leave a top-level PR comment + +**Public review pages (for sangat reviewers who don't use GitHub):** +- Reviewer hub: [securityleader.ai/blog/asvs-panjabi-review-hub](https://securityleader.ai/blog/asvs-panjabi-review-hub) +- Glossary (68 terms): [securityleader.ai/blog/asvs-panjabi-review-glossary](https://securityleader.ai/blog/asvs-panjabi-review-glossary) +- Why this translation exists: [securityleader.ai/blog/owasp-asvs-panjabi-translation](https://securityleader.ai/blog/owasp-asvs-panjabi-translation) + +--- + +## Quality assurance already run + +- **Mechanical scan (Opus 4.8, 2026-06-02):** 0 Devanagari leaks, 0 fraud-term violations, 0 Gurmat-prohibited terms, 0 Western-period sentence-ends, 0 romanization-style violations across all 13 files. +- **Known open item:** the Q12 structural inconsistency (deferred to this review) and 11 terminology questions in `OPEN-QUESTIONS.md`. + +This is a living document — corrections from review flow back into the chapters, and `OPEN-QUESTIONS.md` records every adjudicated decision. + +> *ਸੁਰੱਖਿਆ ਗਿਆਨ ਸਭ ਲਈ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।* +> *Security knowledge should be accessible to all.* diff --git a/5.0/pa-IN/TRANSLATION-NOTES.md b/5.0/pa-IN/TRANSLATION-NOTES.md new file mode 100644 index 0000000000..86e8d4a4fd --- /dev/null +++ b/5.0/pa-IN/TRANSLATION-NOTES.md @@ -0,0 +1,101 @@ +# Panjabi Translation Notes +# ਪੰਜਾਬੀ ਅਨੁਵਾਦ ਨੋਟਸ + +## Translation Started +- Date: September 16, 2025 +- Translator: GeeksikhSecurity (Gurvinder Singh) +- Version: ASVS 5.0.0 + +## Spelling Convention +Using "Panjabi" following Sikhri.org and Panjab Digital Library standards + +## Format Convention +- **Bilingual**: Every English paragraph is followed by its Panjabi (Gurmukhi) translation +- **Section headers**: English heading followed by Gurmukhi heading on next line +- **Tables**: Bilingual in same cell using `
` separator where applicable +- **First-occurrence rule**: Translated terms shown as "ਗੁਰਮੁਖੀ (English)" on first use +- **Acronyms**: Retained in English with Gurmukhi pronunciation guide on first use + +## Progress Tracking + +_Status as of 2026-08-22 (pm): 22 of 27 files bilingual (AI draft v0.1, mechanically QA-gated and fresh-context reviewed; Sangat review pending). All 17 security-requirement chapters (V1-V17) plus the introductory chapters are now bilingual. Remaining: Appendices A-E._ + +### Phase A — Foundation (~960 words) +- [x] 0x01-Frontispiece.md (282 words) +- [x] 0x02-Preface.md (399 words) +- [x] README.md (expanded glossary, ~100 terms) + +### Phase B — Context (~5,250 words) +- [x] 0x03-What-is-the-ASVS.md (3,264 words) +- [x] 0x04-Assessment_and_Certification.md (803 words) +- [x] 0x05-For-Users-Of-4.0.md (1,260 words) + +### Phase C — Core Security Chapters (~18,650 words) +- [x] 0x10-V1-Encoding-and-Sanitization.md (1,897 words) +- [x] 0x11-V2-Validation-and-Business-Logic.md (1,057 words) +- [x] 0x12-V3-Web-Frontend-Security.md (2,086 words) +- [x] 0x13-V4-API-and-Web-Service.md (1,059 words) +- [x] 0x14-V5-File-Handling.md (816 words) +- [x] 0x15-V6-Authentication.md (3,142 words) +- [x] 0x16-V7-Session-Management.md (1,343 words) +- [x] 0x17-V8-Authorization.md (843 words) +- [x] 0x18-V9-Self-contained-Tokens.md (678 words) +- [x] 0x19-V10-OAuth-and-OIDC.md (3,080 words) +- [x] 0x20-V11-Cryptography.md (1,785 words) +- [x] 0x21-V12-Secure-Communication.md (768 words) +- [x] 0x22-V13-Configuration.md (1,180 words) +- [x] 0x23-V14-Data-Protection.md (1,036 words) +- [x] 0x24-V15-Secure-Coding-and-Architecture.md (1,479 words) +- [x] 0x25-V16-Security-Logging-and-Error-Handling.md (1,211 words) +- [x] 0x26-V17-WebRTC.md (1,229 words) + +### Phase D — Appendices (~7,653 words) +- [ ] 0x90-Appendix-A_Glossary.md (2,757 words) +- [ ] 0x91-Appendix-B_References.md (222 words) +- [ ] 0x92-Appendix-C_Cryptography.md (2,988 words) +- [ ] 0x93-Appendix-D_Recommendations.md (717 words) +- [ ] 0x94-Appendix-E_Contributors.md (991 words) + +**Total: ~38,372 words across 27 files** + +## Terminology Decision Log + +Key decisions on how security terms are handled in this translation: + +| Decision | Term | Approach | Rationale | +|----------|------|----------|-----------| +| 1 | Security | ਸੁਰੱਖਿਆ (surakkhiā) — Translate | Well-established Panjabi word | +| 2 | Authentication | ਪ੍ਰਮਾਣੀਕਰਨ (pramāṇīkaran) — Translate | Standard academic Panjabi | +| 3 | SQL Injection | ਐੱਸ.ਕਿਊ.ਐੱਲ। ਇੰਜੈਕਸ਼ਨ — Transliterate | No Panjabi equivalent; technical term | +| 4 | OWASP | Retain English | Global brand; add ਓਵਾਸਪ pronunciation | +| 5 | Cross-Site Scripting | ਕਰਾਸ-ਸਾਈਟ ਸਕ੍ਰਿਪਟਿੰਗ — Transliterate | Technical term, XSS acronym retained | +| 6 | Vulnerability | ਕਮਜ਼ੋਰੀ (kamzorī) — Translate | Common Panjabi word for weakness | +| 7 | Token | ਟੋਕਨ (ṭokan) — Transliterate | Widely used in Panjabi tech context | +| 8 | "Panjabi" spelling | Use "Panjabi" not "Punjabi" | Per Sikhri.org, Panjab Digital Library | + +## QA Checklist + +For each translated file, verify: + +- [ ] **Gurmukhi rendering**: All characters within Unicode U+0A00-U+0A7F range +- [ ] **Glossary consistency**: Terms match glossary definitions throughout +- [ ] **Markdown integrity**: Tables, headers, links render correctly +- [ ] **Bilingual completeness**: Every English section has corresponding Gurmukhi +- [ ] **First-occurrence annotations**: Technical terms explained on first use +- [ ] **Proper nouns**: Names kept in English (not transliterated) +- [ ] **Requirement IDs**: Unchanged (e.g., **6.2.1** stays as-is) +- [ ] **Link validity**: All hyperlinks preserved from English source +- [ ] **Numerals**: Western digits in technical prose, incl. version numbers (5.0, not ੫.੦) + +## Translation Guidelines +- Maintain technical accuracy +- Use consistent terminology from glossary +- Keep English technical terms in parentheses when first introduced +- Follow Gurmukhi script conventions +- Preserve markdown formatting and links +- Glossary tool available at: `web-scrapers/gurbani_dictionary_scraper/asvs_translation_tool.py` + +## Platform Coordination +- Primary workflow: GitHub PR #3254 +- Glossary and term discussions: GitHub issues +- Future: Crowdin platform integration for community contributions diff --git a/5.0/pa-IN/TRANSLATION-RULES.md b/5.0/pa-IN/TRANSLATION-RULES.md new file mode 100644 index 0000000000..890dadb7ee --- /dev/null +++ b/5.0/pa-IN/TRANSLATION-RULES.md @@ -0,0 +1,97 @@ +# OWASP ASVS — Panjabi (pa-IN) Translation Rules + +**Status:** canonical · **Updated:** 2026-06-06 · **Lead:** Gurvinder Singh (@GeeksikhSecurity) +**Method:** AI-assisted draft (v0.1) → Sangat/community review is the certification gate. + +This is the authoritative rule set for the Panjabi translation. It consolidates the project +locks, the engine prompt contract, and lessons from real academic Panjabi usage (Punjabi +University, Patiala — Department of Music page + ACTDPL language-tech centre; see the PDL +project's `LESSONS-PUNJABI-UNIVERSITY.md`). All prior recommendations are **accepted** here. + +--- + +## 1. Script & encoding + +1. **Gurmukhi only** (U+0A00–U+0A7F). NEVER Devanagari letters; NEVER Latin transliteration + of the Panjabi body text. +2. **Unicode NFC**-normalise all Panjabi text (precomposed nukta — e.g. ੜ, not ਡ+਼). +3. Allowed shared punctuation: danda `।` (U+0964), double-danda `॥` (U+0965). +4. Proper use of mātrā (ਮਾਤਰਾ), addak (ੱ), tippi/bindi (ੰ/ਂ), nukta (਼). + +## 2. Orthography + +1. **Sentence-end = danda `।`** for full Panjabi sentences (prose). NEVER the Western period. + Do **not** add a danda to short UI labels, headings, or list fragments. +2. **Numerals = Western digits** (0–9) in technical prose — years, quantities, **and version + numbers** (write `5.0`, not `੫.੦`). *Accepted:* this matches how leading Panjabi + institutions write modern/technical text (Punjabi University pages use 1984, 2004…). + Gurmukhi numerals are reserved for traditional/decorative contexts only. +3. **Requirement IDs stay exactly as the source** (e.g. `9.1.1`, `v5.0.0-2.1.7`) — English + digits, never converted. +4. **The apostrophe-clitic `'ਤੇ` is ACCEPTABLE** Panjabi orthography (attested in real + academic text, e.g. `…ਡੀ)'ਤੇ`). It is **NOT** a translation error and must **not** be + flagged by lint. (Note: stripping it for *search-key normalisation* in PDL is a separate, + permitted concern.) +5. **Spelling:** "Panjabi" / "Panjab" (per Sikhri.org and Panjab Digital Library), not + "Punjabi" / "Punjab", in any English appearing in the translation. + +## 3. Romanization + +When romanizing a Panjabi term, use **IAST** diacritics (ṭ ḍ ṇ ā ī ū ṅ ñ, "chh", the ʼ for +addak) — never doubled-vowel English style (write `ṭhaggī`, not `thaggee`). + +## 4. Register & terminology (T/L/R/H) + +Match the register of **formal academic Panjabi**. Classify every term: + +| Tag | Use | Examples (attested in real academic Panjabi) | +|---|---|---| +| **T — Translated** (native/Sanskritic) for established concepts | ਪ੍ਰਮਾਣੀਕਰਨ (authentication), ਅਖੰਡਤਾ (integrity), ਸਿਧਾਂਤ (theory), ਅੰਤਰ-ਅਨੁਸ਼ਾਸਨੀ (inter-disciplinary) | +| **L — Loan** (transliterated) for modern/Western terms with no settled Panjabi word | ਟੋਕਨ (token), ਡਾਊਨਲੋਡ (download), ਕੋਰਸ (course), ਵਰਕਸ਼ਾਪ (workshop) | +| **R — Retained** in English/Latin — never translate or transliterate | OWASP, ASVS, CWE, SQL, XSS, CSRF, SSRF, API, URL, TLS, JWT, JWS, JWK, MAC, HMAC, OAuth, OIDC, SAML, JSON, PIN, OTP, **audience**, **key material**, allowlist/denylist, algorithm names/values (`'None'`, `RS256`), header/claim names (`alg`,`jku`,`x5u`,`jwk`,`aud`,`nbf`,`exp`,`iss`) | +| **H — Hybrid** (English head + Panjabi word) | SQL ਇੰਜੈਕਸ਼ਨ, GraphQL ਕਿਊਰੀ | + +**Glossary anchoring:** prefer terms attested in **Punjabi University lexicography** and the +project glossary; cite sources (APA) for contested choices. + +### Locked terminology decisions +- **Fraud/scam** → always **ਠੱਗੀ**. The only allowed `ਫ਼ਰਾਡ` compound is **ਰੋਮਾਂਸ ਫ਼ਰਾਡ**. +- **Community** → **ਭਾਈਚਾਰਾ** (generic); **ਸੰਗਤ** only in named Sikh religious contexts. +- **House glossary (pin these exact terms):** self-contained → ਸਵੈ-ਨਿਰਭਰ · integrity → + ਅਖੰਡਤਾ · validity period → ਜਾਇਜ਼ਤਾ ਮਿਆਦ · context → ਸੰਦਰਭ · issuer → ਜਾਰੀਕਰਤਾ · tampering → + ਛੇੜਛਾੜ · verify → ਤਸਦੀਕ ਕਰੋ · validate → ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ. Grow from review. + +### Verb precision +Preserve "verify" / "validate" / "check" as distinct — they are not interchangeable in a +security standard. ASVS requirements typically open "Verify that…" → **ਤਸਦੀਕ ਕਰੋ ਕਿ…**. + +### First-use gloss +On first use of a translated technical concept, give the Panjabi term followed by the English +in parentheses, e.g. **ਅਖੰਡਤਾ (integrity)**. Do not repeat the gloss every time. + +## 5. Gurmat / cultural safety + +1. No yoga/Hindu/Sanskrit-devotional vocabulary outside a direct Gurbani quotation. (E.g. + render "posture/state" as **ਸਥਿਤੀ** (sthitī), never **ਮੁਦਰਾ** (mudrā, yoga-connoted).) +2. Sacred/Gurbani material requires **Sangat sign-off**; no AI output self-certifies above v0.1. + +## 6. Bilingual structure + +1. **Dual-block:** English block, then the Panjabi translation block (consistent order + corpus-wide — this is the Q12 decision; real institutions are inconsistent, so a fixed + convention is an improvement). +2. **Heading model:** `Panjabi Heading (English)` or `English Heading ਪੰਜਾਬੀ ਸਿਰਲੇਖ`, applied + consistently. +3. Do not soften, omit, or add security obligations; translate the requirement as written. + +## 7. Process + +- AI-assisted draft (Opus 4.8 with the `asvs` prompt profile that encodes these rules) → + scored on the PDL translation bench → **Sangat/community review = certification gate**. +- Mechanical QA before review: 0 Devanagari leaks, 0 Western-period sentence-ends, 0 + Gurmat-prohibited terms, 0 fraud-term violations, retained-terms intact, NFC-clean. + +--- + +*These rules are enforced by the bench's `asvs` system-prompt profile and checked in review. +Changes are corpus-wide — propose via a GitHub issue, not inline.* diff --git a/GIT-CHEATSHEET.md b/GIT-CHEATSHEET.md new file mode 100644 index 0000000000..43af468e24 --- /dev/null +++ b/GIT-CHEATSHEET.md @@ -0,0 +1,62 @@ +# Git Workflow Cheat Sheet for ASVS Panjabi Translation +# ASVS ਪੰਜਾਬੀ ਅਨੁਵਾਦ ਲਈ Git ਵਰਕਫਲੋ ਚੀਟ ਸ਼ੀਟ + +## Daily Workflow (5 commands) + +### 1. Start of session — pull latest changes +```bash +cd "path/to/ASVS" +git checkout panjabi-translation-v5 +git pull origin panjabi-translation-v5 +``` + +### 2. Make your changes +Edit files in `5.0/pa-IN/` using any text editor. + +### 3. Check what changed +```bash +git status +git diff +``` + +### 4. Stage and commit +```bash +git add 5.0/pa-IN/ +git commit -m "trans(pa-IN): translate 0x02-Preface.md" +``` + +### 5. Push to GitHub +```bash +git push origin panjabi-translation-v5 +``` + +PR #3254 updates automatically when you push. + +--- + +## Commit Message Format +``` +trans(pa-IN): +``` + +Examples: +- `trans(pa-IN): translate 0x02-Preface.md` +- `trans(pa-IN): expand glossary to 100 terms` +- `trans(pa-IN): fix Gurmukhi spelling in Authentication chapter` + +## Useful Commands + +| What | Command | +|------|---------| +| See PR status | `gh pr view 3254` | +| See what's changed | `git status` | +| Undo last unstaged change | `git checkout -- ` | +| See commit history | `git log --oneline -10` | +| Sync with upstream OWASP | `git fetch upstream && git merge upstream/master` | + +## Branch Structure +``` +master (OWASP/ASVS upstream) + └── panjabi-translation-v5 (your PR branch) + └── 5.0/pa-IN/ (translation files) +```