From d6429ff1d136eef931f11e8dfb6b2d113344e159 Mon Sep 17 00:00:00 2001 From: khalidwalamri Date: Tue, 8 Sep 2026 08:42:11 +0300 Subject: [PATCH 1/2] Initial translation to arabic --- 5.0/ar/0x00-Header.yaml | 16 + 5.0/ar/0x01-Frontispiece.md | 46 +++ 5.0/ar/0x02-Preface.md | 29 ++ 5.0/ar/0x03-What-is-the-ASVS.md | 195 +++++++++++ 5.0/ar/0x04-Assessment_and_Certification.md | 47 +++ 5.0/ar/0x05-For-Users-Of-4.0.md | 90 +++++ 5.0/ar/0x10-V1-Encoding-and-Sanitization.md | 103 ++++++ .../0x11-V2-Validation-and-Business-Logic.md | 73 ++++ 5.0/ar/0x12-V3-Web-Frontend-Security.md | 100 ++++++ 5.0/ar/0x13-V4-API-and-Web-Service.md | 64 ++++ 5.0/ar/0x14-V5-File-Handling.md | 54 +++ 5.0/ar/0x15-V6-Authentication.md | 166 ++++++++++ 5.0/ar/0x16-V7-Session-Management.md | 91 +++++ 5.0/ar/0x17-V8-Authorization.md | 56 ++++ 5.0/ar/0x18-V9-Self-contained-Tokens.md | 36 ++ 5.0/ar/0x19-V10-OAuth-and-OIDC.md | 169 ++++++++++ 5.0/ar/0x20-V11-Cryptography.md | 107 ++++++ 5.0/ar/0x21-V12-Secure-Communication.md | 57 ++++ 5.0/ar/0x22-V13-Configuration.md | 68 ++++ 5.0/ar/0x23-V14-Data-Protection.md | 60 ++++ ...0x24-V15-Secure-Coding-and-Architecture.md | 77 +++++ ...V16-Security-Logging-and-Error-Handling.md | 84 +++++ 5.0/ar/0x26-V17-WebRTC.md | 75 +++++ 5.0/ar/0x90-Appendix-A_Glossary.md | 89 +++++ 5.0/ar/0x91-Appendix-B_References.md | 43 +++ 5.0/ar/0x92-Appendix-C_Cryptography.md | 311 ++++++++++++++++++ 5.0/ar/0x93-Appendix-D_Recommendations.md | 49 +++ 5.0/ar/0x94-Appendix-E_Contributors.md | 71 ++++ 28 files changed, 2426 insertions(+) create mode 100644 5.0/ar/0x00-Header.yaml create mode 100644 5.0/ar/0x01-Frontispiece.md create mode 100644 5.0/ar/0x02-Preface.md create mode 100644 5.0/ar/0x03-What-is-the-ASVS.md create mode 100644 5.0/ar/0x04-Assessment_and_Certification.md create mode 100644 5.0/ar/0x05-For-Users-Of-4.0.md create mode 100644 5.0/ar/0x10-V1-Encoding-and-Sanitization.md create mode 100644 5.0/ar/0x11-V2-Validation-and-Business-Logic.md create mode 100644 5.0/ar/0x12-V3-Web-Frontend-Security.md create mode 100644 5.0/ar/0x13-V4-API-and-Web-Service.md create mode 100644 5.0/ar/0x14-V5-File-Handling.md create mode 100644 5.0/ar/0x15-V6-Authentication.md create mode 100644 5.0/ar/0x16-V7-Session-Management.md create mode 100644 5.0/ar/0x17-V8-Authorization.md create mode 100644 5.0/ar/0x18-V9-Self-contained-Tokens.md create mode 100644 5.0/ar/0x19-V10-OAuth-and-OIDC.md create mode 100644 5.0/ar/0x20-V11-Cryptography.md create mode 100644 5.0/ar/0x21-V12-Secure-Communication.md create mode 100644 5.0/ar/0x22-V13-Configuration.md create mode 100644 5.0/ar/0x23-V14-Data-Protection.md create mode 100644 5.0/ar/0x24-V15-Secure-Coding-and-Architecture.md create mode 100644 5.0/ar/0x25-V16-Security-Logging-and-Error-Handling.md create mode 100644 5.0/ar/0x26-V17-WebRTC.md create mode 100644 5.0/ar/0x90-Appendix-A_Glossary.md create mode 100644 5.0/ar/0x91-Appendix-B_References.md create mode 100644 5.0/ar/0x92-Appendix-C_Cryptography.md create mode 100644 5.0/ar/0x93-Appendix-D_Recommendations.md create mode 100644 5.0/ar/0x94-Appendix-E_Contributors.md diff --git a/5.0/ar/0x00-Header.yaml b/5.0/ar/0x00-Header.yaml new file mode 100644 index 0000000000..00325b4adf --- /dev/null +++ b/5.0/ar/0x00-Header.yaml @@ -0,0 +1,16 @@ +--- + title: "Application Security Verification Standard" + subtitle: "Version 5.0.0" + date: May 2025 + titlepage: true + titlepage-rule-height: 0 + titlepage-logo: "images/owasp_logo_1c_notext.png" + table-use-row-colors: true + toc: true + toc-own-page: true + geometry: "left=2cm,right=2cm,top=3cm,bottom=3cm" + lang: ar + dir: rtl + mainfont: "Amiri" + sansfont: "Amiri" +--- diff --git a/5.0/ar/0x01-Frontispiece.md b/5.0/ar/0x01-Frontispiece.md new file mode 100644 index 0000000000..a06a6d514e --- /dev/null +++ b/5.0/ar/0x01-Frontispiece.md @@ -0,0 +1,46 @@ +# البداية + +## عن المعيار + +معيار التحقق من أمان التطبيقات هو قائمة بمتطلبات أمان التطبيقات التي يمكن للمعماريين والمطوّرين والمختبرين ومتخصصي الأمان ومورّدي الأدوات والمستهلكين استخدامها لتحديد التطبيقات الآمنة وبنائها واختبارها والتحقق منها. + +## حقوق النشر والترخيص + +الإصدار 5.0.0، مايو 2025 + +![license](../images/license.png) + +حقوق النشر © 2008-2025 مؤسسة OWASP. + +يُنشر هذا المستند بموجب [ترخيص المشاع الإبداعي: النسبة إلى المُصنَّف - الترخيص بالمثل 4.0 دولي](https://creativecommons.org/licenses/by-sa/4.0/). + +عند أي إعادة استخدام أو توزيع، يجب أن توضّح للآخرين شروط ترخيص هذا العمل بجلاء. + +## قادة المشروع + +| | | +|---------------------- |----------------- | +| Elar Lang | Josh C Grossman | +| Jim Manico | Daniel Cuthbert | + +## مجموعة العمل + +| | | | | +|---------------- |------------------ |------------------- |----------------- | +| Tobias Ahnoff | Ralph Andalis | Ryan Armstrong | Gabriel Corona | +| Meghan Jacquot | Shanni Prutchi | Iman Sharafaldin | Eden Yardeni | + +## مساهمون رئيسيون آخرون + +| | | +|-------------------|-------------------| +| Sjoerd Langkemper | Isaac Lewis | +| Mark Carney | Sandro Gauci | + +## مساهمون ومراجعون آخرون + +لقد أدرجنا قائمة بالمساهمين الآخرين في الملحق هـ. + +إذا كان هناك إسهام غائب عن قائمة الإسهامات للإصدار 5.x، فيُرجى تسجيل تذكرة على GitHub ليُعترف به في تحديثات 5.x المستقبلية. + +يبني معيار التحقق من أمان التطبيقات على عمل من شاركوا في إصدارات ASVS من 1.0 (2008) حتى 4.0 (2019). وقد كُتب في الأصل كثير من البنية والعديد من بنود التحقق التي لا تزال موجودة في ASVS اليوم على أيدي Andrew van der Stock وMike Boberski وJeff Williams وDave Wichers، إلى جانب عدد كبير من المساهمين الآخرين. شكرًا لكل من ساهم في الماضي. وللحصول على قائمة شاملة بالمساهمين السابقين، يُرجى الرجوع إلى كل إصدار سابق. diff --git a/5.0/ar/0x02-Preface.md b/5.0/ar/0x02-Preface.md new file mode 100644 index 0000000000..66a17d54a0 --- /dev/null +++ b/5.0/ar/0x02-Preface.md @@ -0,0 +1,29 @@ +# تمهيد + +أهلًا بك في الإصدار 5.0 من معيار التحقق من أمان التطبيقات (ASVS). + +## مقدمة + +أُطلق ASVS في الأصل عام 2008 من خلال تعاون مجتمعي عالمي، وهو يحدّد مجموعة شاملة من متطلبات الأمان لتصميم تطبيقات وخدمات الويب الحديثة وتطويرها واختبارها. + +بعد إصدار ASVS 4.0 عام 2019 وتحديثه الطفيف (الإصدار 4.0.3) عام 2021، يمثّل الإصدار 5.0 محطة مهمة—حُدِّث ليجسّد أحدث التطورات في أمان البرمجيات. + +ASVS 5.0 هو نتاج إسهامات واسعة من قادة المشروع وأعضاء مجموعة العمل ومجتمع OWASP الأوسع لتحديث هذا المعيار المهم وتحسينه. + +## المبادئ التي يستند إليها الإصدار 5.0 + +طُوِّرت هذه المراجعة الرئيسية مع مراعاة عدة مبادئ أساسية: + +* نطاق وتركيز مُحسَّنان: صُمِّم هذا الإصدار من المعيار ليتوافق بشكل أكثر مباشرة مع الركائز الأساسية في اسمه: التطبيق، والأمان، والتحقق، والمعيار. وقد أُعيدت كتابة المتطلبات للتأكيد على منع العيوب الأمنية بدلًا من إلزام تنفيذات تقنية محدّدة. والمقصود أن تكون نصوص المتطلبات شارحة لنفسها، موضّحةً سبب وجودها. + +* دعم القرارات الأمنية الموثّقة: يقدّم ASVS 5.0 متطلبات لتوثيق القرارات الأمنية الرئيسية. وهذا يعزّز إمكانية التتبّع ويدعم التنفيذات الحسّاسة للسياق، ما يتيح للمؤسسات تكييف وضعها الأمني وفق احتياجاتها ومخاطرها المحدّدة. + +* مستويات محدَّثة: مع أن ASVS يحتفظ بنموذجه ثلاثي الطبقات، فقد تطوّرت تعريفات المستويات لتسهيل تبنّي ASVS. صُمِّم المستوى 1 كخطوة أولى لتبنّي ASVS، موفّرًا الطبقة الأولى من الدفاع. ويمثّل المستوى 2 نظرة شاملة لممارسات الأمان القياسية، أما المستوى 3 فيتناول المتطلبات المتقدّمة عالية التوكيد. + +* محتوى مُعاد هيكلته وموسّع: يشتمل ASVS 5.0 على نحو 350 متطلبًا موزّعة على 17 فصلًا. وقد أُعيد تنظيم الفصول لتحقيق الوضوح وسهولة الاستخدام. ويُتاح تخطيط ثنائي الاتجاه بين الإصدارين 4.0 و5.0 لتيسير الانتقال. + +## نظرة إلى الأمام + +كما أن تأمين التطبيق لا ينتهي حقًا، فكذلك ASVS. ومع أن الإصدار 5.0 إصدار رئيسي، فإن التطوير مستمر. ويتيح هذا الإصدار للمجتمع الأوسع الاستفادة من التحسينات والإضافات التي تراكمت، لكنه يرسي كذلك الأساس لتحسينات مستقبلية. وقد يشمل ذلك جهودًا يقودها المجتمع لإنشاء إرشادات للتنفيذ والتحقق مبنية على مجموعة المتطلبات الأساسية. + +صُمِّم ASVS 5.0 ليكون أساسًا موثوقًا لتطوير البرمجيات الآمنة. والمجتمع مدعو إلى تبنّي هذا المعيار والإسهام فيه والبناء عليه للنهوض جماعيًا بحالة أمان التطبيقات. diff --git a/5.0/ar/0x03-What-is-the-ASVS.md b/5.0/ar/0x03-What-is-the-ASVS.md new file mode 100644 index 0000000000..925ecb33b6 --- /dev/null +++ b/5.0/ar/0x03-What-is-the-ASVS.md @@ -0,0 +1,195 @@ +# What is the 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. + +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. + +## Scope of the 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. + +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. + +### 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. + +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. + +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. + +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. + +### 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. + +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. + +### 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. + +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. + +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. + +### 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. + +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. + +### 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. + +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. + +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. + +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. + +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. + +Each ASVS level indicates the security requirements that are required to achieve from that level, with the higher remaining level requirements as recommendations. + +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. + +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. + +The types of requirements in each level could be characterized as follows. + +### Level 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. + +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. + +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. + +### Level 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. + +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 + +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. + +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. + +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. + +## How to use the ASVS + +### The structure of the 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. + +The aim of the chapter and section division is to simplify choosing or filtering out chapters and sections based on the 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. + +### 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. + +* 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). + +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. + +### Flexibility with the 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. + +Additionally, organizations are strongly encouraged to create an organization- or domain-specific fork that adjusts requirements based on the specific characteristics and risk levels of their applications. However, it is important to maintain traceability so that passing requirement 4.1.1 means the same across all versions. + +Ideally, each organization should create its own tailored ASVS, omitting irrelevant sections (e.g., GraphQL, WebSockets, SOAP, if unused). An organization-specific ASVS version or supplement is also a good place to provide organization-specific implementation guidance, detailing libraries or resources to use when complying with requirements. + +### How to Reference ASVS Requirements + +Each requirement has an identifier in the format `.
.`, where each element is a number. For example, `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: + +> 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. + +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-`.) + +Note: The `v` preceding the version number in the format should always be 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. + +ASVS requirement lists are made available in CSV, JSON, and other formats which may be useful for reference or programmatic use. + +### Forking the 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. + +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. + +## Use cases for the 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. + +### 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 archiecture, 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. + +### 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, prganizations 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. + +### 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. + +### 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. + +### 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. + +## Applying ASVS in Practice + +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. diff --git a/5.0/ar/0x04-Assessment_and_Certification.md b/5.0/ar/0x04-Assessment_and_Certification.md new file mode 100644 index 0000000000..d4af46ff78 --- /dev/null +++ b/5.0/ar/0x04-Assessment_and_Certification.md @@ -0,0 +1,47 @@ +# التقييم وإصدار الشهادات + +## موقف OWASP من شهادات ASVS وعلامات الثقة + +إن OWASP، كمؤسسة غير ربحية محايدة تجاه المورّدين، لا تمنح شهادات لأي مورّدين أو مدقّقين أو برمجيات. وأي توكيد أو علامة ثقة أو شهادة تدّعي الامتثال لـ ASVS ليست معتمدة رسميًا من OWASP، ولذلك ينبغي للمؤسسات أن تتوخى الحذر من ادعاءات الأطراف الثالثة بالحصول على شهادة ASVS. + +ويمكن للمؤسسات أن تقدّم خدمات توكيد، بشرط ألا تدّعي حصولها على شهادة رسمية من OWASP. + +## كيفية التحقق من الامتثال لـ ASVS + +إن ASVS ليس إلزاميًا بشكل متعمّد بخصوص الطريقة الدقيقة للتحقق من الامتثال على مستوى دليل اختبار. ومع ذلك، من المهم إبراز بعض النقاط الرئيسية. + +### إعداد تقارير التحقق + +تُبلِّغ تقارير اختبار الاختراق التقليدية عن المشكلات "على سبيل الاستثناء"، فتسرد حالات الفشل فقط. أما تقرير شهادة ASVS فينبغي أن يشتمل على النطاق، وملخّص لجميع المتطلبات التي فُحصت، والمتطلبات التي رُصدت فيها استثناءات، وإرشادات لمعالجة المشكلات. وقد تكون بعض المتطلبات غير منطبقة (مثل إدارة الجلسات في واجهات برمجة التطبيقات عديمة الحالة)، ويجب الإشارة إلى ذلك في التقرير. + +### نطاق التحقق + +لن تنفّذ المؤسسة التي تطوّر تطبيقًا جميع المتطلبات عادةً، إذ قد يكون بعضها غير ذي صلة أو أقل أهمية بحسب وظائف التطبيق. وينبغي للمدقّق أن يوضّح نطاق التحقق، بما في ذلك المستوى الذي تسعى المؤسسة إلى تحقيقه والمتطلبات التي أُدرجت. وينبغي أن يكون ذلك من منظور ما أُدرج بدلًا من ما لم يُدرج. كما ينبغي له أن يقدّم رأيًا في مبرّرات استثناء المتطلبات التي لم تُنفَّذ. + +وهذا ينبغي أن يمكّن مستهلك تقرير التحقق من فهم سياق التحقق واتخاذ قرار مستنير بشأن مستوى الثقة الذي يمكن أن يوليه للتطبيق. + +ويمكن للمؤسسات المانحة للشهادات أن تختار طرائق اختبارها، لكن ينبغي لها الإفصاح عنها في التقرير، ومن المستحسن أن تكون قابلة للتكرار. وقد تُستخدم طرائق مختلفة، مثل اختبارات الاختراق اليدوية أو تحليل الشيفرة المصدرية، للتحقق من جوانب مثل التحقق من صحة المدخلات، وذلك بحسب التطبيق والمتطلبات. + +### آليات التحقق + +هناك عدد من التقنيات المختلفة التي قد تكون لازمة للتحقق من متطلبات ASVS المحدّدة. وإلى جانب اختبار الاختراق (باستخدام بيانات اعتماد صحيحة للحصول على تغطية كاملة للتطبيق)، قد يتطلّب التحقق من متطلبات ASVS الوصول إلى الوثائق والشيفرة المصدرية والتكوين والأشخاص المشاركين في عملية التطوير. وخصوصًا للتحقق من متطلبات المستويين 2 و3. ومن الممارسات المتّبعة تقديم أدلة قوية على النتائج مع توثيق مفصّل، قد يشمل أوراق العمل ولقطات الشاشة والنصوص البرمجية وسجلات الاختبار. ولا يكفي مجرّد تشغيل أداة مؤتمتة دون اختبار شامل للحصول على الشهادة، إذ يجب اختبار كل متطلب على نحو قابل للتحقق. + +إن استخدام الأتمتة للتحقق من متطلبات ASVS موضوع يثير الاهتمام باستمرار. ولذلك من المهم توضيح بعض النقاط المتعلقة بالاختبار المؤتمت واختبار الصندوق الأسود. + +#### دور أدوات اختبار الأمان المؤتمتة + +عندما تُنفَّذ أدوات اختبار الأمان المؤتمتة، مثل أدوات الاختبار الديناميكي والساكن لأمان التطبيقات (DAST وSAST)، تنفيذًا صحيحًا في خط بناء البرمجيات، فقد تتمكّن من تحديد بعض المشكلات الأمنية التي لا ينبغي أن توجد أبدًا. لكنها من دون تكوين وضبط دقيقين لن توفّر التغطية المطلوبة، وسيمنع مستوى الضجيج تحديد المشكلات الأمنية الحقيقية والتخفيف منها. + +ومع أن ذلك قد يوفّر تغطية لبعض المتطلبات التقنية الأبسط والأكثر مباشرة، مثل تلك المتعلقة بترميز المخرجات أو التنقية، فمن الأهمية البالغة ملاحظة أن هذه الأدوات ستكون عاجزة تمامًا عن التحقق من كثير من متطلبات ASVS الأكثر تعقيدًا أو تلك المتعلقة بمنطق العمل والتحكم في الوصول. + +وبالنسبة إلى المتطلبات الأقل مباشرة، من المرجّح أنه لا يزال بالإمكان الاستفادة من الأتمتة، لكن سيتعيّن كتابة عمليات تحقق خاصة بالتطبيق لتحقيق ذلك. وقد تكون هذه مشابهة لاختبارات الوحدة والتكامل التي ربما تستخدمها المؤسسة بالفعل. ولذلك قد يكون من الممكن استخدام هذه البنية التحتية القائمة لأتمتة الاختبارات في كتابة اختبارات ASVS هذه. ومع أن القيام بذلك سيتطلّب استثمارًا قصير الأجل، فإن الفوائد طويلة الأجل للقدرة على التحقق المستمر من متطلبات ASVS هذه ستكون كبيرة. + +وخلاصة القول، القابلية للاختبار باستخدام الأتمتة لا تساوي تشغيل أداة جاهزة. + +#### دور اختبار الاختراق + +مع أن المستوى 1 في الإصدار 4.0 كان مُهيّأً لإجراء اختبار "الصندوق الأسود" (دون وثائق ودون شيفرة مصدرية)، فقد كان المعيار واضحًا حتى في ذلك الحين في أن هذا ليس نشاط توكيد فعّالًا وينبغي الإثناء عنه بفعالية. + +إن الاختبار دون الوصول إلى المعلومات الإضافية اللازمة آلية غير كفؤة وغير فعّالة للتحقق الأمني، إذ يفوّت إمكانية مراجعة الشيفرة المصدرية وتحديد التهديدات والضوابط المفقودة وإجراء اختبار أكثر شمولًا بكثير في إطار زمني أقصر. + +ويُشجَّع بقوة على إجراء اختبار اختراق مبني على الوثائق أو الشيفرة المصدرية (هجين)، يتيح وصولًا كاملًا إلى مطوّري التطبيق ووثائق التطبيق، بدلًا من اختبارات الاختراق التقليدية. وسيكون ذلك ضروريًا بالتأكيد للتحقق من كثير من متطلبات ASVS. diff --git a/5.0/ar/0x05-For-Users-Of-4.0.md b/5.0/ar/0x05-For-Users-Of-4.0.md new file mode 100644 index 0000000000..736f8a1c1f --- /dev/null +++ b/5.0/ar/0x05-For-Users-Of-4.0.md @@ -0,0 +1,90 @@ +# التغييرات مقارنةً بالإصدار 4.x + +## مقدمة + +قد يجد المستخدمون المعتادون على الإصدار 4.x من المعيار أنه من المفيد مراجعة التغييرات الرئيسية المُدخلة في الإصدار 5.0، بما فيها التحديثات في المحتوى والنطاق والفلسفة الأساسية. + +ومن بين 286 متطلبًا في الإصدار 4.0.3، بقي 11 متطلبًا فقط دون تغيير، في حين خضع 15 متطلبًا لتعديلات نحوية طفيفة دون تغيير معناها. وإجمالًا، لم يعد 109 متطلبات (38%) متطلبات منفصلة في الإصدار 5.0، إذ حُذف 50 منها ببساطة، وأُزيل 28 كمكرّرات، ودُمج 31 في متطلبات أخرى. أما الباقي فقد نُقّح بصورة ما. وحتى المتطلبات التي لم تُعدَّل جوهريًا لها معرّفات مختلفة بسبب إعادة الترتيب أو إعادة الهيكلة. + +ولتيسير تبنّي الإصدار 5.0، تُوفَّر مستندات تخطيط لمساعدة المستخدمين على تتبّع كيفية تقابل متطلبات الإصدار 4.x مع متطلبات الإصدار 5.0. وهذه التخطيطات غير مرتبطة بترقيم الإصدارات وقد تُحدَّث أو تُوضَّح حسب الحاجة. + +## فلسفة المتطلبات + +### النطاق والتركيز + +اشتمل الإصدار 4.x على متطلبات لم تتوافق مع النطاق المقصود للمعيار؛ وقد أُزيلت هذه المتطلبات. كما استُثنيت المتطلبات التي لم تستوف معايير النطاق للإصدار 5.0 أو التي لم تكن قابلة للتحقق. + +### التأكيد على الأهداف الأمنية بدلًا من الآليات + +في الإصدار 4.x، ركّز كثير من المتطلبات على آليات معيّنة بدلًا من الأهداف الأمنية الأساسية. وفي الإصدار 5.0، تتمحور المتطلبات حول الأهداف الأمنية، مع الإشارة إلى آليات بعينها فقط عندما تكون الحل العملي الوحيد، أو تقديمها كأمثلة أو إرشادات تكميلية. + +ويقرّ هذا المنهج بأنه قد توجد طرائق متعددة لتحقيق هدف أمني معيّن، ويتجنّب الإلزام غير الضروري الذي قد يحدّ من مرونة المؤسسات. + +وإضافةً إلى ذلك، دُمجت المتطلبات التي تتناول الشأن الأمني نفسه حيث كان ذلك ملائمًا. + +### القرارات الأمنية الموثّقة + +مع أن مفهوم القرارات الأمنية الموثّقة قد يبدو جديدًا في الإصدار 5.0، فهو تطوّر لمتطلبات سابقة متعلقة بتطبيق السياسات ونمذجة التهديدات في الإصدار 4.0. فقد كانت بعض المتطلبات سابقًا تقتضي ضمنيًا إجراء تحليل لتوجيه تنفيذ ضوابط الأمان، مثل تحديد اتصالات الشبكة المسموح بها. + +وللتأكد من توافر المعلومات اللازمة للتنفيذ والتحقق، صارت هذه التوقعات مُعرَّفة صراحةً كمتطلبات توثيق، ما يجعلها واضحة وقابلة للتنفيذ وقابلة للتحقق. + +## التغييرات الهيكلية والفصول الجديدة + +تقدّم عدة فصول في الإصدار 5.0 محتوى جديدًا كليًا: + +* OAuth وOIDC – نظرًا للتبنّي الواسع لهذين البروتوكولين لتفويض الوصول والدخول الموحّد، أُضيفت متطلبات مخصّصة لتناول السيناريوهات المتنوعة التي قد يواجهها المطوّرون. وقد يتطوّر هذا المجال في النهاية إلى معيار قائم بذاته، على نحو شبيه بمعالجة متطلبات الأجهزة المحمولة وإنترنت الأشياء في الإصدارات السابقة. +* WebRTC – مع تزايد شعبية هذه التقنية، تُتناول الآن اعتباراتها وتحدياتها الأمنية الفريدة في قسم مخصّص. + +وقد بُذلت جهود كذلك للتأكد من أن الفصول والأقسام منظّمة حول مجموعات متسقة من المتطلبات المترابطة. + +وقد أدّت إعادة الهيكلة هذه إلى إنشاء فصول إضافية: + +* الرموز المميزة المكتفية بذاتها – كانت مصنّفة سابقًا تحت إدارة الجلسات، وصارت الرموز المميزة المكتفية بذاتها تُعدّ الآن آلية متمايزة وعنصرًا أساسيًا للاتصال عديم الحالة (كما في OAuth وOIDC). ونظرًا لتبعاتها الأمنية الفريدة، تُتناول في فصل مخصّص، مع إدخال بعض المتطلبات الجديدة في الإصدار 5.x. +* أمان واجهة الويب الأمامية – مع تزايد تعقيد التطبيقات القائمة على المتصفح وصعود المعماريات القائمة على واجهات برمجة التطبيقات فقط، فُصلت متطلبات أمان الواجهة الأمامية في فصل خاص بها. +* البرمجة الآمنة والمعمارية – جُمعت هنا المتطلبات الجديدة التي تتناول ممارسات أمنية عامة لم تكن تندرج في الفصول القائمة. + +وقد أُجريت تغييرات تنظيمية أخرى في الإصدار 5.0 لتوضيح المقصد. على سبيل المثال، نُقلت متطلبات التحقق من صحة المدخلات إلى جانب منطق العمل، بما يجسّد دورها في إنفاذ قواعد العمل، بدلًا من تصنيفها مع التنقية والترميز. + +وقد أُزيل فصل V1 المعمارية السابق. فقد احتوى قسمه الأول على متطلبات كانت خارج النطاق، في حين أُعيد توزيع الأقسام اللاحقة على الفصول المعنية، مع إزالة تكرار المتطلبات وتوضيحها حسب الضرورة. + +## إزالة التخطيطات المباشرة إلى المعايير الأخرى + +أُزيلت التخطيطات المباشرة إلى المعايير الأخرى من المتن الرئيسي للمعيار. والهدف إعداد تخطيط مع مشروع تعداد المتطلبات المشتركة (CRE) الخاص بـ OWASP، والذي سيربط بدوره ASVS بمجموعة من مشاريع OWASP والمعايير الخارجية. + +ولم تعد التخطيطات المباشرة إلى CWE وNIST مُصانة، على النحو الموضّح أدناه. + +### تقليل الارتباط بإرشادات الهوية الرقمية من NIST + +لطالما شكّلت [إرشادات الهوية الرقمية (SP 800-63)](https://pages.nist.gov/800-63-3/) الصادرة عن NIST مرجعًا لضوابط المصادقة والتخويل. وفي الإصدار 4.x، كانت فصول معيّنة متوافقة على نحو وثيق مع بنية NIST ومصطلحاتها. + +ومع أن هذه الإرشادات تبقى مرجعًا مهمًا، فقد أدّى التوافق الصارم إلى تحديات، منها مصطلحات أقل شيوعًا في التعارف، وتكرار متطلبات متشابهة، وتخطيطات غير كاملة. ويبتعد الإصدار 5.0 عن هذا المنهج لتحسين الوضوح والصلة. + +### الابتعاد عن تعداد نقاط الضعف الشائعة (CWE) + +يوفّر [تعداد نقاط الضعف الشائعة (CWE)](https://cwe.mitre.org/) تصنيفًا مفيدًا لنقاط ضعف أمان البرمجيات. لكن تحديات مثل مُدخلات CWE التي هي فئات فقط، وصعوبات تخطيط المتطلبات إلى CWE واحد، ووجود تخطيطات غير دقيقة في الإصدار 4.x، أدّت إلى قرار إيقاف التخطيطات المباشرة إلى CWE في الإصدار 5.0. + +## إعادة النظر في تعريفات المستويات + +وصف الإصدار 4.x المستويات بأنها المستوى 1 ("الأدنى") والمستوى 2 ("القياسي") والمستوى 3 ("المتقدّم")، مع ما يفهم منه أن جميع التطبيقات التي تتعامل مع بيانات حساسة ينبغي أن تستوفي المستوى 2 على الأقل. + +ويعالج الإصدار 5.0 عدة مشكلات في هذا المنهج، وهي موصوفة في الفقرات التالية. + +ومن الناحية العملية، في حين استخدم الإصدار 4.x علامات الاختيار كمؤشرات للمستويات، يستخدم الإصدار 5.x رقمًا بسيطًا في جميع صيغ المعيار، بما فيها markdown وPDF وDOCX وCSV وJSON وXML. وللتوافق مع الإصدارات السابقة، تُولَّد كذلك إصدارات قديمة من مخرجات CSV وJSON وXML التي لا تزال تستخدم علامات الاختيار. + +### مستوى دخول أسهل + +أشارت التعليقات إلى أن العدد الكبير من متطلبات المستوى 1 (نحو 120)، مقترنًا بتصنيفه كالمستوى "الأدنى" الذي لا يكفي لمعظم التطبيقات، قد أثنى عن التبنّي. ويهدف الإصدار 5.0 إلى تخفيض هذا الحاجز بتعريف المستوى 1 أساسًا حول متطلبات الدفاع في الطبقة الأولى، ما ينتج عنه متطلبات أوضح وأقل عددًا في ذلك المستوى. ولبيان ذلك عدديًا، كان في الإصدار 4.0.3 عدد 128 متطلبًا للمستوى 1 من أصل 278 متطلبًا، أي ما يمثّل 46%. وفي الإصدار 5.0.0 هناك 70 متطلبًا للمستوى 1 من أصل 345 متطلبًا، أي ما يمثّل 20%. + +### مغالطة القابلية للاختبار + +كان أحد العوامل الرئيسية في انتقاء الضوابط للمستوى 1 في الإصدار 4.x ملاءمتها للتقييم عن طريق اختبار الاختراق الخارجي بمنهج "الصندوق الأسود". لكن هذا المنهج لم يتوافق تمامًا مع مقصد المستوى 1 كالمجموعة الأدنى من ضوابط الأمان. فقد رأى بعض المستخدمين أن المستوى 1 غير كافٍ لتأمين التطبيقات، في حين وجده آخرون صعب الاختبار للغاية. + +والتعويل على القابلية للاختبار كمعيار أمر نسبي ومُضلِّل أحيانًا. فكون المتطلب قابلًا للاختبار لا يضمن إمكانية اختباره بطريقة مؤتمتة أو مباشرة. وعلاوة على ذلك، ليست المتطلبات الأسهل اختبارًا هي دائمًا تلك ذات الأثر الأمني الأكبر أو الأبسط تنفيذًا. + +ولذلك، في الإصدار 5.0، اتُّخذت قرارات المستويات أساسًا على أساس تقليل المخاطر، مع مراعاة الجهد اللازم للتنفيذ كذلك. + +### ليس الأمر متعلقًا بالمخاطر وحدها + +لقد ثبت أن استخدام مستويات إلزامية مبنية على المخاطر تفرض مستوى معيّنًا لتطبيقات بعينها مفرط الصلابة. فمن الناحية العملية، يعتمد ترتيب أولويات ضوابط الأمان وتنفيذها على عوامل متعددة، منها تقليل المخاطر والجهد اللازم للتنفيذ على حد سواء. + +ولذلك تُشجَّع المؤسسات على تحقيق المستوى الذي تشعر أنه ينبغي لها تحقيقه بناءً على نضجها والرسالة التي تريد إيصالها إلى مستخدميها. diff --git a/5.0/ar/0x10-V1-Encoding-and-Sanitization.md b/5.0/ar/0x10-V1-Encoding-and-Sanitization.md new file mode 100644 index 0000000000..574a03ebed --- /dev/null +++ b/5.0/ar/0x10-V1-Encoding-and-Sanitization.md @@ -0,0 +1,103 @@ +# V1 الترميز والتنقية + +## الهدف من ضوابط الأمان + +يتناول هذا الفصل أكثر نقاط ضعف أمان تطبيقات الويب شيوعًا فيما يتصل بالمعالجة غير الآمنة للبيانات غير الموثوقة. ويمكن أن تؤدي نقاط الضعف هذه إلى ثغرات تقنية متنوعة، تُفسَّر فيها البيانات غير الموثوقة وفق قواعد صياغة المُفسِّر المعني. + +وبالنسبة إلى تطبيقات الويب الحديثة، من الأفضل دائمًا استخدام واجهات برمجة تطبيقات أكثر أمانًا، مثل الاستعلامات المُمعَّمة أو الإفلات التلقائي أو أُطر القوالب. وبخلاف ذلك، يصبح الترميز أو الإفلات أو التنقية المُنفَّذة بعناية على المخرجات أمرًا بالغ الأهمية لأمان التطبيق. + +ويعمل التحقق من صحة المدخلات كآلية دفاع في العمق للحماية من المحتوى غير المتوقع أو الخطير. لكن، بما أن غرضه الأساسي هو ضمان تطابق المحتوى الوارد مع التوقعات الوظيفية والتجارية، فإن المتطلبات المتعلقة بذلك يمكن العثور عليها في فصل "التحقق من الصحة ومنطق العمل". + +## V1.1 معمارية الترميز والتنقية + +في الأقسام أدناه، تُقدَّم متطلبات خاصة بالصياغة أو بالمُفسِّر لمعالجة المحتوى غير الآمن بأمان لتجنّب الثغرات الأمنية. وتتناول متطلبات هذا القسم الترتيب الذي ينبغي أن تحدث به هذه المعالجة والموضع الذي ينبغي أن تحدث فيه. وتهدف كذلك إلى ضمان أن البيانات، عند تخزينها، تبقى في حالتها الأصلية ولا تُخزَّن في صورة مُرمَّزة أو مُفلَتة (مثل ترميز HTML)، وذلك لمنع مشكلات الترميز المزدوج. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **1.1.1** | تحقق من أن المدخلات تُفكّ ترميزها أو يُلغى إفلاتها إلى صورة قياسية مرة واحدة فقط، ومن أنها لا تُفكّ إلا عندما تكون البيانات المُرمَّزة بهذه الصورة متوقعة، ومن أن ذلك يحدث قبل معالجة المدخلات أكثر، أي أنه لا يُنفَّذ بعد التحقق من صحة المدخلات أو تنقيتها. | 2 | +| **1.1.2** | تحقق من أن التطبيق ينفّذ ترميز المخرجات وإفلاتها إما كخطوة أخيرة قبل استخدامها بواسطة المُفسِّر المقصود لها أو بواسطة المُفسِّر نفسه. | 2 | + +## V1.2 منع الحقن + +إن ترميز المخرجات أو إفلاتها، المُنفَّذ قريبًا من سياق خطير محتمل أو ملاصقًا له، بالغ الأهمية لأمان أي تطبيق. وعادةً لا يُحفَظ ترميز المخرجات وإفلاتها، بل يُستخدمان لجعل المخرجات آمنة للاستخدام الفوري في المُفسِّر الملائم. وقد تؤدي محاولة تنفيذ ذلك مبكرًا جدًا إلى محتوى مشوّه أو إلى جعل الترميز أو الإفلات غير فعّال. + +وفي حالات كثيرة، تتضمّن مكتبات البرمجيات دوالّ آمنة أو أكثر أمانًا تنفّذ ذلك تلقائيًا، وإن كان من الضروري التأكد من صحتها للسياق الراهن. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **1.2.1** | تحقق من أن ترميز المخرجات لاستجابة HTTP أو مستند HTML أو مستند XML ملائم للسياق المطلوب، مثل ترميز المحارف المعنية لعناصر 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 وغيره من هجمات حقن قواعد البيانات. وهذا ذو صلة كذلك عند كتابة الإجراءات المخزَّنة. | 1 | +| **1.2.5** | تحقق من أن التطبيق يحمي من حقن أوامر نظام التشغيل ومن أن استدعاءات نظام التشغيل تستخدم استعلامات مُمعَّمة لنظام التشغيل أو تستخدم ترميزًا سياقيًا لمخرجات سطر الأوامر. | 1 | +| **1.2.6** | تحقق من أن التطبيق يحمي من ثغرات حقن LDAP، أو من أن ضوابط أمنية محدّدة لمنع حقن LDAP قد نُفِّذت. | 2 | +| **1.2.7** | تحقق من أن التطبيق محمي من هجمات حقن XPath باستخدام تمعيم الاستعلامات أو الاستعلامات المُصرَّفة مسبقًا. | 2 | +| **1.2.8** | تحقق من أن معالجات LaTeX مُهيّأة بأمان (مثل عدم استخدام العَلَم "--shell-escape") ومن استخدام قائمة سماح بالأوامر لمنع هجمات حقن LaTeX. | 2 | +| **1.2.9** | تحقق من أن التطبيق يُفلت المحارف الخاصة في التعبيرات النمطية (عادةً باستخدام شرطة مائلة عكسية) لمنع تفسيرها خطأً كمحارف وصفية. | 2 | +| **1.2.10** | تحقق من أن التطبيق محمي من حقن CSV والصيغ. ويجب أن يتّبع التطبيق قواعد الإفلات المحدّدة في RFC 4180 القسمين 2.6 و2.7 عند تصدير محتوى CSV. وإضافةً إلى ذلك، عند التصدير إلى CSV أو غيره من صيغ جداول البيانات (مثل XLS أو XLSX أو ODF)، يجب إفلات المحارف الخاصة (بما فيها '=' و'+' و'-' و'@' و'\t' (مسافة جدولة) و'\0' (محرف فارغ)) بعلامة اقتباس مفردة إذا ظهرت كأول محرف في قيمة حقل. | 3 | + +ملاحظة: استخدام الاستعلامات المُمعَّمة أو إفلات SQL ليس كافيًا دائمًا. فأجزاء الاستعلام مثل أسماء الجداول والأعمدة (بما فيها أسماء أعمدة "ORDER BY") لا يمكن إفلاتها. وإدراج بيانات مُفلَتة مقدَّمة من المستخدم في هذه الحقول يؤدي إلى استعلامات فاشلة أو إلى حقن SQL. + +## V1.3 التنقية + +الحماية المثالية من استخدام محتوى غير موثوق في سياق غير آمن هي استخدام ترميز أو إفلات خاص بالسياق، يحافظ على المعنى الدلالي نفسه للمحتوى غير الآمن لكنه يجعله آمنًا للاستخدام في ذلك السياق بعينه، على النحو المبيّن بتفصيل أكبر في القسم السابق. + +وحيث لا يكون ذلك ممكنًا، تصبح التنقية ضرورية، بإزالة المحارف أو المحتوى الخطير المحتمل. وقد يغيّر ذلك في بعض الحالات المعنى الدلالي للمُدخل، لكن لأسباب أمنية قد لا يكون هناك بديل. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **1.3.1** | تحقق من أن جميع مدخلات HTML غير الموثوقة الواردة من محرّرات "ما تراه هو ما تحصل عليه" أو ما شابهها تُنقّى باستخدام مكتبة تنقية HTML معروفة وآمنة أو ميزة في إطار العمل. | 1 | +| **1.3.2** | تحقق من أن التطبيق يتجنّب استخدام eval() أو غيره من ميزات تنفيذ الشيفرة الديناميكية مثل لغة تعبيرات Spring (SpEL). وحيث لا يوجد بديل، يجب تنقية أي مدخلات مستخدم تُضمَّن قبل تنفيذها. | 1 | +| **1.3.3** | تحقق من أن البيانات المُمرَّرة إلى سياق خطير محتمل تُنقّى مسبقًا لإنفاذ تدابير السلامة، مثل السماح بالمحارف الآمنة لهذا السياق فقط وتقليم المدخلات المفرطة الطول. | 2 | +| **1.3.4** | تحقق من أن محتوى الرسوميات المتجهية القابلة للتحجيم (SVG) القابل للبرمجة والمقدَّم من المستخدم يُتحقَّق من صحته أو يُنقّى بحيث لا يحتوي إلا على الوسوم والسمات (مثل رسم الرسوميات) الآمنة للتطبيق، أي مثلًا لا يحتوي على نصوص برمجية أو foreignObject. | 2 | +| **1.3.5** | تحقق من أن التطبيق يُنقّي أو يعطّل المحتوى القابل للبرمجة أو محتوى لغات قوالب التعبيرات المقدَّم من المستخدم، مثل Markdown أو أوراق أنماط CSS أو XSL أو BBCode أو ما شابهها. | 2 | +| **1.3.6** | تحقق من أن التطبيق يحمي من هجمات تزوير الطلب من جانب الخادم (SSRF)، وذلك بالتحقق من البيانات غير الموثوقة مقابل قائمة سماح بالبروتوكولات والنطاقات والمسارات والمنافذ، وتنقية المحارف الخطيرة المحتملة قبل استخدام البيانات لاستدعاء خدمة أخرى. | 2 | +| **1.3.7** | تحقق من أن التطبيق يحمي من هجمات حقن القوالب بعدم السماح ببناء القوالب على أساس مدخلات غير موثوقة. وحيث لا يوجد بديل، يجب تنقية أي مدخلات غير موثوقة تُضمَّن ديناميكيًا أثناء إنشاء القالب أو التحقق منها بصرامة. | 2 | +| **1.3.8** | تحقق من أن التطبيق يُنقّي المدخلات غير الموثوقة على النحو الملائم قبل استخدامها في استعلامات واجهة التسمية والدليل في Java (JNDI)، ومن أن JNDI مُهيّأة بأمان لمنع هجمات حقن JNDI. | 2 | +| **1.3.9** | تحقق من أن التطبيق يُنقّي المحتوى قبل إرساله إلى memcache لمنع هجمات الحقن. | 2 | +| **1.3.10** | تحقق من أن سلاسل التنسيق التي قد تُحلّ بطريقة غير متوقعة أو خبيثة عند استخدامها تُنقّى قبل معالجتها. | 2 | +| **1.3.11** | تحقق من أن التطبيق يُنقّي مدخلات المستخدم قبل تمريرها إلى أنظمة البريد للحماية من حقن SMTP أو IMAP. | 2 | +| **1.3.12** | تحقق من أن التعبيرات النمطية خالية من العناصر المسبّبة للتراجع الأُسّي، وتأكّد من تنقية المدخلات غير الموثوقة للتخفيف من هجمات ReDoS أو التعبيرات النمطية الشاردة. | 3 | + +## V1.4 الذاكرة والسلاسل والشيفرة غير المُدارة + +تتناول المتطلبات التالية المخاطر المرتبطة بالاستخدام غير الآمن للذاكرة، وهي تنطبق عمومًا عندما يستخدم التطبيق لغة أنظمة أو شيفرة غير مُدارة. + +وقد يكون من الممكن في بعض الحالات تحقيق ذلك بضبط أعلام المُصرِّف التي تُمكّن الحماية من فيضان المخزن المؤقت والتحذيرات، بما في ذلك عشوائية المكدّس ومنع تنفيذ البيانات، والتي تُفشل عملية البناء إذا وُجدت عمليات غير آمنة على المؤشرات أو الذاكرة أو سلاسل التنسيق أو الأعداد الصحيحة أو السلاسل. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **1.4.1** | تحقق من أن التطبيق يستخدم سلاسل آمنة للذاكرة ونسخًا أكثر أمانًا للذاكرة وحسابًا للمؤشرات لكشف فيضانات المكدّس أو المخزن المؤقت أو الكومة أو منعها. | 2 | +| **1.4.2** | تحقق من استخدام تقنيات التحقق من الإشارة والنطاق والمدخلات لمنع فيضان الأعداد الصحيحة. | 2 | +| **1.4.3** | تحقق من تحرير الذاكرة والموارد المخصّصة ديناميكيًا، ومن إزالة المراجع أو المؤشرات إلى الذاكرة المُحرَّرة أو تعيينها إلى null لمنع المؤشرات المعلّقة وثغرات الاستخدام بعد التحرير. | 2 | + +## V1.5 فك التسلسل الآمن + +إن تحويل البيانات من صورة مخزَّنة أو منقولة إلى كائنات تطبيق فعلية (فك التسلسل) كان تاريخيًا سببًا لثغرات حقن شيفرة متنوعة. ومن المهم تنفيذ هذه العملية بعناية وأمان لتجنّب هذه الأنواع من المشكلات. + +وعلى وجه الخصوص، حُدّدت طرائق معيّنة لفك التسلسل في وثائق لغات البرمجة أو أُطر العمل بأنها غير آمنة ولا يمكن جعلها آمنة مع البيانات غير الموثوقة. ولكل آلية قيد الاستخدام، ينبغي إجراء تحرٍّ دقيق. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **1.5.1** | تحقق من أن التطبيق يهيّئ مُحلِّلات XML لاستخدام تكوين تقييدي ومن أن الميزات غير الآمنة، مثل حلّ الكيانات الخارجية، معطّلة لمنع هجمات كيان XML الخارجي (XXE). | 1 | +| **1.5.2** | تحقق من أن فك تسلسل البيانات غير الموثوقة يُنفِذ معالجة آمنة للمدخلات، مثل استخدام قائمة سماح بأنواع الكائنات أو تقييد أنواع الكائنات التي يحدّدها العميل، وذلك لمنع هجمات فك التسلسل. ويجب ألا تُستخدم آليات فك التسلسل المُعرَّفة صراحةً بأنها غير آمنة مع مدخلات غير موثوقة. | 2 | +| **1.5.3** | تحقق من أن المُحلِّلات المختلفة المستخدمة في التطبيق لنوع البيانات نفسه (مثل مُحلِّلات JSON ومُحلِّلات XML ومُحلِّلات URL) تُنفِّذ التحليل بطريقة متسقة وتستخدم آلية ترميز المحارف نفسها، وذلك لتجنّب مشكلات مثل ثغرات قابلية التشغيل المتبادل في JSON أو استغلال اختلاف سلوك تحليل معرّفات الموارد أو الملفات في هجمات تضمين الملفات البعيدة (RFI) أو تزوير الطلب من جانب الخادم (SSRF). | 3 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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) + +ولمزيد من المعلومات، وتحديدًا عن مشكلات فك التسلسل أو التحليل، يُرجى الاطلاع على: + +* [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/ar/0x11-V2-Validation-and-Business-Logic.md b/5.0/ar/0x11-V2-Validation-and-Business-Logic.md new file mode 100644 index 0000000000..611d653a76 --- /dev/null +++ b/5.0/ar/0x11-V2-Validation-and-Business-Logic.md @@ -0,0 +1,73 @@ +# V2 التحقق من الصحة ومنطق العمل + +## الهدف من ضوابط الأمان + +يهدف هذا الفصل إلى ضمان أن التطبيق المتحقَّق منه يحقّق الأهداف الرفيعة المستوى التالية: + +* أن تتوافق المدخلات التي يستقبلها التطبيق مع التوقعات التجارية أو الوظيفية. +* أن يكون سير منطق العمل تسلسليًا، ويُعالَج بالترتيب، ولا يمكن تجاوزه. +* أن يشتمل منطق العمل على حدود وضوابط لكشف الهجمات المؤتمتة ومنعها، مثل التحويلات المالية الصغيرة المتواصلة أو إضافة مليون صديق واحدًا تلو الآخر. +* أن تكون مسارات منطق العمل عالية القيمة قد راعت حالات إساءة الاستخدام والجهات الخبيثة، وأن تتوافر لها حماية من هجمات التنكّر والتلاعب وكشف المعلومات وتصعيد الصلاحيات. + +## V2.1 توثيق التحقق من الصحة ومنطق العمل + +ينبغي أن يحدّد توثيق التحقق من الصحة ومنطق العمل بوضوح حدود منطق العمل وقواعد التحقق من الصحة والاتساق السياقي لعناصر البيانات المجتمعة، بحيث يكون واضحًا ما يلزم تنفيذه في التطبيق. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **2.1.1** | تحقق من أن وثائق التطبيق تحدّد قواعد التحقق من صحة المدخلات لبيان كيفية فحص صلاحية عناصر البيانات مقابل بنية متوقعة. وقد تكون هذه صيغ بيانات شائعة مثل أرقام بطاقات الائتمان أو عناوين البريد الإلكتروني أو أرقام الهاتف، أو قد تكون صيغة بيانات داخلية. | 1 | +| **2.1.2** | تحقق من أن وثائق التطبيق تحدّد كيفية التحقق من الاتساق المنطقي والسياقي لعناصر البيانات المجتمعة، مثل فحص تطابق الحي والرمز البريدي. | 2 | +| **2.1.3** | تحقق من أن التوقعات الخاصة بحدود منطق العمل وعمليات التحقق من الصحة موثّقة، بما يشمل المستوى الخاص بكل مستخدم والمستوى العام على نطاق التطبيق. | 2 | + +## V2.2 التحقق من صحة المدخلات + +تُنفِذ ضوابط التحقق الفعّالة من صحة المدخلات التوقعات التجارية أو الوظيفية بشأن نوع البيانات التي يتوقع التطبيق استقبالها. وهذا يضمن جودة البيانات ويقلّل سطح الهجوم. لكنه لا يزيل الحاجة إلى استخدام الترميز أو التمعيم أو التنقية الصحيحة عند استخدام البيانات في مكوّن آخر أو عند عرضها كمخرجات، ولا يحلّ محلها. + +وفي هذا السياق، قد تأتي "المدخلات" من مصادر متنوعة كثيرة، منها حقول نماذج HTML وطلبات REST ومعاملات URL وحقول ترويسة HTTP وملفات تعريف الارتباط والملفات على القرص وقواعد البيانات وواجهات برمجة التطبيقات الخارجية. + +قد يفحص ضابط لمنطق العمل أن مُدخلًا معيّنًا هو رقم أقل من 100. وقد يفحص توقّع وظيفي أن رقمًا ما دون حد معيّن، لأن ذلك الرقم يتحكم في عدد مرات تنفيذ حلقة معيّنة، وقد يؤدي رقم كبير إلى معالجة مفرطة واحتمال حدوث حالة حجب خدمة. + +ومع أن التحقق من الصحة عبر المخطّط ليس إلزاميًا صراحةً، فقد يكون الآلية الأكثر فعالية لتغطية التحقق الكامل لواجهات برمجة تطبيقات HTTP أو غيرها من الواجهات التي تستخدم JSON أو XML. + +يُرجى ملاحظة النقاط التالية بشأن التحقق من الصحة عبر المخطّط: + +* يُعدّ "الإصدار المنشور" من مواصفة التحقق من الصحة عبر مخطّط JSON جاهزًا للإنتاج، لكنه ليس "مستقرًا" بالمعنى الدقيق. وعند استخدام التحقق عبر مخطّط JSON، تأكّد من عدم وجود فجوات مقارنةً بالإرشادات الواردة في المتطلبات أدناه. +* ينبغي كذلك مراقبة أي مكتبات للتحقق من الصحة عبر مخطّط JSON قيد الاستخدام وتحديثها إذا لزم الأمر بعد إقرار المعيار رسميًا. +* لا ينبغي استخدام التحقق عبر DTD، وينبغي تعطيل تقييم DTD في أُطر العمل، لتجنّب المشكلات المتعلقة بهجمات XXE على DTD. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **2.2.1** | تحقق من أن المدخلات يتم التحقق من صحتها لإنفاذ التوقعات التجارية أو الوظيفية الخاصة بها. وينبغي أن يستخدم ذلك إما تحققًا إيجابيًا مقابل قائمة سماح بالقيم والأنماط والنطاقات، أو أن يستند إلى مقارنة المُدخل ببنية متوقعة وحدود منطقية وفق قواعد محدّدة مسبقًا. وبالنسبة إلى المستوى 1، يمكن أن يركّز ذلك على المدخلات المستخدمة في اتخاذ قرارات تجارية أو أمنية محدّدة. أما للمستوى 2 وما فوق، فينبغي أن ينطبق على جميع المدخلات. | 1 | +| **2.2.2** | تحقق من أن التطبيق مصمّم لإنفاذ التحقق من صحة المدخلات في طبقة خدمة موثوقة. ومع أن التحقق من جانب العميل يحسّن قابلية الاستخدام وينبغي تشجيعه، فيجب ألا يُعتمد عليه كضابط أمني. | 1 | +| **2.2.3** | تحقق من أن التطبيق يضمن أن تكون تركيبات عناصر البيانات المترابطة معقولة وفق القواعد المحدّدة مسبقًا. | 2 | + +## V2.3 أمان منطق العمل + +يتناول هذا القسم المتطلبات الرئيسية للتأكد من أن التطبيق يُنفِذ عمليات منطق العمل على النحو الصحيح وأنه غير معرّض للهجمات التي تستغل منطق التطبيق وسير عمله. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **2.3.1** | تحقق من أن التطبيق لن يعالج مسارات منطق العمل للمستخدم نفسه إلا بترتيب الخطوات التسلسلي المتوقع ودون تخطّي خطوات. | 1 | +| **2.3.2** | تحقق من أن حدود منطق العمل مُنفَّذة وفق وثائق التطبيق لتجنّب استغلال عيوب منطق العمل. | 2 | +| **2.3.3** | تحقق من استخدام المعاملات على مستوى منطق العمل بحيث تنجح عملية منطق العمل بكاملها أو تُرجَع إلى الحالة الصحيحة السابقة. | 2 | +| **2.3.4** | تحقق من استخدام آليات القفل على مستوى منطق العمل للتأكد من أن الموارد محدودة الكمية (مثل مقاعد المسرح أو فترات التوصيل) لا يمكن حجزها مرتين عن طريق التلاعب بمنطق التطبيق. | 2 | +| **2.3.5** | تحقق من أن مسارات منطق العمل عالية القيمة تتطلّب موافقة متعددة المستخدمين لمنع الإجراءات غير المصرَّح بها أو العارضة. وقد يشمل ذلك، على سبيل المثال لا الحصر، التحويلات المالية الكبيرة أو الموافقات على العقود أو الوصول إلى المعلومات المصنّفة أو تجاوزات السلامة في التصنيع. | 3 | + +## V2.4 مكافحة الأتمتة + +يشتمل هذا القسم على ضوابط لمكافحة الأتمتة للتأكد من اشتراط تفاعلات شبيهة بالبشرية ومنع الطلبات المؤتمتة المفرطة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **2.4.1** | تحقق من وجود ضوابط لمكافحة الأتمتة للحماية من الاستدعاءات المفرطة لوظائف التطبيق التي قد تؤدي إلى تسريب البيانات أو إنشاء بيانات غير مفيدة أو استنفاد الحصص أو تجاوز حدود المعدّل أو حجب الخدمة أو الاستخدام المفرط للموارد المكلفة. | 2 | +| **2.4.2** | تحقق من أن مسارات منطق العمل تتطلّب توقيتًا بشريًا واقعيًا، بما يمنع تقديم المعاملات بسرعة مفرطة. | 3 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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) +* يمكن تحقيق مكافحة الأتمتة بطرائق كثيرة، منها استخدام [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/ar/0x12-V3-Web-Frontend-Security.md b/5.0/ar/0x12-V3-Web-Frontend-Security.md new file mode 100644 index 0000000000..4933e19240 --- /dev/null +++ b/5.0/ar/0x12-V3-Web-Frontend-Security.md @@ -0,0 +1,100 @@ +# V3 أمان واجهة الويب الأمامية + +## الهدف من ضوابط الأمان + +تركّز هذه الفئة على المتطلبات المصمّمة للحماية من الهجمات التي تُنفَّذ عبر واجهة ويب أمامية. ولا تنطبق هذه المتطلبات على الحلول من آلة إلى آلة. + +## V3.1 توثيق أمان واجهة الويب الأمامية + +يبيّن هذا القسم ميزات أمان المتصفح التي ينبغي تحديدها في وثائق التطبيق. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **3.1.1** | تحقق من أن وثائق التطبيق تنص على ميزات الأمان المتوقعة التي يجب أن تدعمها المتصفحات المستخدمة للتطبيق (مثل HTTPS وأمان النقل الصارم عبر HTTP (HSTS) وسياسة أمان المحتوى (CSP) وغيرها من آليات أمان HTTP المعنية). ويجب أن تحدّد كذلك كيف يجب أن يتصرّف التطبيق عندما تكون بعض هذه الميزات غير متاحة (مثل تحذير المستخدم أو حجب الوصول). | 3 | + +## V3.2 التفسير غير المقصود للمحتوى + +يمكن أن يؤدي عرض المحتوى أو الوظائف في سياق غير صحيح إلى تنفيذ محتوى ضار أو عرضه. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **3.2.1** | تحقق من وجود ضوابط أمنية لمنع المتصفحات من عرض المحتوى أو الوظائف في استجابات HTTP في سياق غير صحيح (مثلًا عند طلب واجهة برمجة تطبيقات أو ملف حمّله المستخدم أو مورد آخر مباشرةً). وقد تشمل الضوابط الممكنة: عدم تقديم المحتوى إلا إذا أشارت حقول ترويسة طلب HTTP (مثل Sec-Fetch-\*) إلى أنه السياق الصحيح، أو استخدام توجيه sandbox في حقل ترويسة Content-Security-Policy، أو استخدام نوع الترتيب attachment في حقل ترويسة Content-Disposition. | 1 | +| **3.2.2** | تحقق من أن المحتوى المقصود عرضه كنص، بدلًا من عرضه كـ HTML، يُعالَج باستخدام دوالّ عرض آمنة (مثل createTextNode أو textContent) لمنع التنفيذ غير المقصود لمحتوى مثل HTML أو JavaScript. | 1 | +| **3.2.3** | تحقق من أن التطبيق يتجنّب إغراق DOM عند استخدام JavaScript من جانب العميل، وذلك باستخدام تصريحات صريحة للمتغيرات وإجراء فحص صارم للأنواع وتجنّب تخزين المتغيرات العامة على كائن document وتنفيذ عزل لمساحات الأسماء. | 3 | + +## V3.3 إعداد ملفات تعريف الارتباط + +يبيّن هذا القسم متطلبات التهيئة الآمنة لملفات تعريف الارتباط الحساسة لتوفير مستوى أعلى من التوكيد بأنها أُنشئت بواسطة التطبيق نفسه، ولمنع تسريب محتوياتها أو تعديلها على نحو غير ملائم. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **3.3.1** | تحقق من أن ملفات تعريف الارتباط لها السمة 'Secure' مضبوطة، وإذا لم تُستخدم البادئة '\__Host-' لاسم ملف تعريف الارتباط، فيجب استخدام البادئة '__Secure-' لاسمه. | 1 | +| **3.3.2** | تحقق من أن قيمة السمة 'SameSite' لكل ملف تعريف ارتباط مضبوطة وفق الغرض منه، للحد من التعرّض لهجمات إعادة تلبيس واجهة المستخدم وهجمات تزوير الطلبات القائمة على المتصفح، المعروفة عمومًا بتزوير الطلبات عبر المواقع (CSRF). | 2 | +| **3.3.3** | تحقق من أن ملفات تعريف الارتباط تحمل البادئة '__Host-' في اسمها، إلا إذا كانت مصمّمة صراحةً لمشاركتها مع مضيفين آخرين. | 2 | +| **3.3.4** | تحقق من أنه، إذا لم يكن المقصود أن تكون قيمة ملف تعريف الارتباط متاحة للنصوص البرمجية من جانب العميل (مثل رمز الجلسة)، فيجب أن تكون السمة 'HttpOnly' مضبوطة لملف تعريف الارتباط، ويجب ألا تُنقل القيمة نفسها (مثل رمز الجلسة) إلى العميل إلا عبر حقل ترويسة 'Set-Cookie'. | 2 | +| **3.3.5** | تحقق من أن التطبيق، عند كتابته ملف تعريف ارتباط، لا يتجاوز مجموع طول اسمه وقيمته 4096 بايت. فملفات تعريف الارتباط المفرطة الحجم لن يخزّنها المتصفح ومن ثم لن تُرسل مع الطلبات، ما يمنع المستخدم من استخدام وظائف التطبيق التي تعتمد على ذلك الملف. | 3 | + +## V3.4 ترويسات آليات أمان المتصفح + +يوضّح هذا القسم ترويسات الأمان التي ينبغي ضبطها على استجابات HTTP لتمكين ميزات أمان المتصفح وقيوده عند التعامل مع استجابات التطبيق. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **3.4.1** | تحقق من إدراج حقل ترويسة Strict-Transport-Security في جميع الاستجابات لإنفاذ سياسة أمان النقل الصارم عبر HTTP (HSTS). ويجب تحديد عمر أقصى لا يقل عن سنة واحدة، وللمستوى 2 وما فوق يجب أن تنطبق السياسة على جميع النطاقات الفرعية كذلك. | 1 | +| **3.4.2** | تحقق من أن حقل ترويسة Access-Control-Allow-Origin الخاص بمشاركة الموارد عبر الأصول (CORS) قيمة ثابتة يحدّدها التطبيق، أو أنه، في حال استخدام قيمة حقل ترويسة طلب HTTP المسمّى Origin، يُتحقَّق منها مقابل قائمة سماح بالأصول الموثوقة. وعندما يلزم استخدام 'Access-Control-Allow-Origin: *'، تحقق من أن الاستجابة لا تشتمل على أي معلومات حساسة. | 1 | +| **3.4.3** | تحقق من أن استجابات HTTP تشتمل على حقل ترويسة استجابة Content-Security-Policy يحدّد توجيهات تضمن ألا يحمّل المتصفح وينفّذ إلا المحتوى أو الموارد الموثوقة، وذلك للحد من تنفيذ JavaScript الضارة. وكحد أدنى، يجب استخدام سياسة عامة تشتمل على التوجيهين object-src 'none' وbase-uri 'none' وتحدّد إما قائمة سماح أو تستخدم قيمًا عشوائية لمرة واحدة أو تلبيدات. وبالنسبة إلى تطبيق من المستوى 3، يجب تحديد سياسة لكل استجابة تستخدم قيمًا عشوائية لمرة واحدة أو تلبيدات. | 2 | +| **3.4.4** | تحقق من أن جميع استجابات HTTP تحتوي على حقل ترويسة 'X-Content-Type-Options: nosniff'. وهذا يوجّه المتصفحات إلى عدم استخدام استشعار المحتوى وتخمين نوع MIME للاستجابة المعنية، وإلى اشتراط تطابق قيمة حقل ترويسة Content-Type للاستجابة مع المورد المقصود. على سبيل المثال، لا تُقبل الاستجابة لطلب نمط إلا إذا كان Content-Type للاستجابة هو 'text/css'. وهذا يُمكّن كذلك استخدام وظيفة حجب القراءة عبر الأصول (CORB) في المتصفح. | 2 | +| **3.4.5** | تحقق من أن التطبيق يضبط سياسة للمُحيل لمنع تسريب البيانات الحساسة تقنيًا إلى خدمات الأطراف الثالثة عبر حقل ترويسة طلب HTTP المسمّى 'Referer'. ويمكن تحقيق ذلك باستخدام حقل ترويسة استجابة HTTP المسمّى Referrer-Policy أو عبر سمات عناصر HTML. وقد تشمل البيانات الحساسة بيانات المسار والاستعلام في عنوان URL، وكذلك اسم المضيف في التطبيقات الداخلية غير العامة. | 2 | +| **3.4.6** | تحقق من أن تطبيق الويب يستخدم توجيه frame-ancestors في حقل ترويسة Content-Security-Policy لكل استجابة HTTP لضمان عدم إمكانية تضمينه افتراضيًا، وأن تضمين موارد معيّنة مسموح به عند الضرورة فقط. ولاحظ أن حقل ترويسة X-Frame-Options، وإن كانت المتصفحات تدعمه، صار متقادمًا ولا يجوز التعويل عليه. | 2 | +| **3.4.7** | تحقق من أن حقل ترويسة Content-Security-Policy يحدّد موقعًا للإبلاغ عن الانتهاكات. | 3 | +| **3.4.8** | تحقق من أن جميع استجابات HTTP التي تستهل عرض مستند (مثل الاستجابات ذات Content-Type من نوع text/html) تشتمل على حقل ترويسة Cross-Origin-Opener-Policy مع توجيه same-origin أو توجيه same-origin-allow-popups حسب المطلوب. وهذا يمنع الهجمات التي تسيء استغلال الوصول المشترك إلى كائنات Window، مثل انتحال علامات التبويب وعدّ الإطارات. | 3 | + +## V3.5 فصل الأصول في المتصفح + +عند قبول طلب لوظيفة حساسة من جانب الخادم، يحتاج التطبيق إلى التأكد من أن الطلب قد استهلّه التطبيق نفسه أو طرف موثوق وأنه لم يُزوَّر بواسطة مهاجم. + +وقد تشمل الوظائف الحساسة في هذا السياق قبول إرسال النماذج للمستخدمين المصادَق عليهم وغير المصادَق عليهم (مثل طلب مصادقة)، أو العمليات المغيّرة للحالة، أو الوظائف المطلوبة للموارد بكثافة (مثل تصدير البيانات). + +وأهم الحماية هنا هي سياسات أمان المتصفح مثل سياسة الأصل الواحد الخاصة بـ JavaScript وكذلك منطق SameSite الخاص بملفات تعريف الارتباط. وهناك حماية شائعة أخرى هي آلية CORS التمهيدية. وستكون هذه الآلية بالغة الأهمية لنقاط النهاية المصمّمة لاستدعائها من أصل مختلف، لكنها قد تكون كذلك آلية مفيدة لمنع تزوير الطلبات لنقاط النهاية غير المصمّمة لاستدعائها من أصل مختلف. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **3.5.1** | تحقق من أنه، إذا كان التطبيق لا يعوّل على آلية CORS التمهيدية لمنع الطلبات غير المسموح بها عبر الأصول من استخدام وظائف حساسة، فإن هذه الطلبات يُتحقَّق منها للتأكد من أنها صادرة عن التطبيق نفسه. ويمكن تحقيق ذلك باستخدام رموز الحماية من التزوير والتحقق منها، أو باشتراط حقول ترويسة HTTP إضافية ليست من حقول ترويسة الطلب المدرجة في قائمة CORS الآمنة. والغرض من ذلك الدفاع عن هجمات تزوير الطلبات القائمة على المتصفح، المعروفة عمومًا بتزوير الطلبات عبر المواقع (CSRF). | 1 | +| **3.5.2** | تحقق من أنه، إذا كان التطبيق يعوّل على آلية CORS التمهيدية لمنع الاستخدام غير المسموح به للوظائف الحساسة عبر الأصول، فلا يمكن استدعاء الوظيفة بطلب لا يُشغّل طلبًا تمهيديًا لـ CORS. وقد يقتضي ذلك فحص قيمتي حقلي ترويسة الطلب 'Origin' و'Content-Type' أو استخدام حقل ترويسة إضافي ليس من حقول الترويسة المدرجة في قائمة CORS الآمنة. | 1 | +| **3.5.3** | تحقق من أن طلبات HTTP الموجّهة إلى الوظائف الحساسة تستخدم طرائق HTTP ملائمة مثل POST أو PUT أو PATCH أو DELETE، وليس الطرائق التي تعرّفها مواصفة HTTP بأنها "آمنة" مثل HEAD أو OPTIONS أو GET. وبدلًا من ذلك، يمكن استخدام تحقق صارم من حقول ترويسة الطلب Sec-Fetch-* للتأكد من أن الطلب لم يصدر عن استدعاء غير ملائم عبر الأصول أو عن طلب تنقّل أو تحميل مورد (مثل مصدر صورة) حيث لا يكون ذلك متوقعًا. | 1 | +| **3.5.4** | تحقق من أن التطبيقات المنفصلة مستضافة على أسماء مضيفين مختلفة للاستفادة من القيود التي توفّرها سياسة الأصل الواحد، بما في ذلك كيفية تفاعل المستندات أو النصوص البرمجية التي يحمّلها أصل ما مع موارد من أصل آخر، والقيود المبنية على اسم المضيف الخاصة بملفات تعريف الارتباط. | 2 | +| **3.5.5** | تحقق من أن الرسائل التي تستقبلها واجهة postMessage تُهمَل إذا كان أصل الرسالة غير موثوق، أو إذا كانت صياغة الرسالة غير صحيحة. | 2 | +| **3.5.6** | تحقق من أن وظيفة JSONP غير مُمكَّنة في أي مكان في التطبيق، وذلك لتجنّب هجمات تضمين النصوص البرمجية عبر المواقع (XSSI). | 3 | +| **3.5.7** | تحقق من أن البيانات التي تتطلّب تخويلًا غير مدرجة في استجابات موارد النصوص البرمجية، مثل ملفات JavaScript، وذلك لمنع هجمات تضمين النصوص البرمجية عبر المواقع (XSSI). | 3 | +| **3.5.8** | تحقق من أن الموارد المصادَق عليها (مثل الصور ومقاطع الفيديو والنصوص البرمجية والمستندات الأخرى) لا يمكن تحميلها أو تضمينها بالنيابة عن المستخدم إلا عند القصد. ويمكن تحقيق ذلك بتحقق صارم من حقول ترويسة طلب HTTP المسمّاة Sec-Fetch-* للتأكد من أن الطلب لم يصدر عن استدعاء غير ملائم عبر الأصول، أو بضبط حقل ترويسة استجابة HTTP المسمّى Cross-Origin-Resource-Policy ضبطًا تقييديًا لتوجيه المتصفح إلى حجب المحتوى المُعاد. | 3 | + +## V3.6 سلامة الموارد الخارجية + +يوفّر هذا القسم إرشادات للاستضافة الآمنة للمحتوى على مواقع الأطراف الثالثة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **3.6.1** | تحقق من أن أصول جانب العميل، مثل مكتبات JavaScript أو CSS أو خطوط الويب، لا تُستضاف خارجيًا (مثلًا على شبكة توصيل محتوى) إلا إذا كان المورد ساكنًا ومُصدَّرًا بإصدار، واستُخدمت سلامة الموارد الفرعية (SRI) للتحقق من سلامة الأصل. وإذا لم يكن ذلك ممكنًا، فينبغي أن يكون هناك قرار أمني موثّق لتبرير ذلك لكل مورد. | 3 | + +## V3.7 اعتبارات أخرى لأمان المتصفح + +يشتمل هذا القسم على ضوابط أمنية أخرى متنوعة وميزات أمان المتصفحات الحديثة اللازمة لأمان المتصفح من جانب العميل. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **3.7.1** | تحقق من أن التطبيق لا يستخدم إلا تقنيات جانب العميل التي لا تزال مدعومة وتُعدّ آمنة. ومن أمثلة التقنيات التي لا تستوفي هذا المتطلب إضافات NSAPI وFlash وShockwave وActiveX وSilverlight وNACL أو تطبيقات Java الصغيرة من جانب العميل. | 2 | +| **3.7.2** | تحقق من أن التطبيق لن يعيد توجيه المستخدم تلقائيًا إلى اسم مضيف أو نطاق مختلف (لا يتحكم فيه التطبيق) إلا إذا كانت الجهة المقصودة مدرجة في قائمة سماح. | 2 | +| **3.7.3** | تحقق من أن التطبيق يعرض إشعارًا عند إعادة توجيه المستخدم إلى عنوان URL خارج نطاق سيطرة التطبيق، مع خيار إلغاء التنقّل. | 3 | +| **3.7.4** | تحقق من إضافة النطاق الأعلى للتطبيق (مثل site.tld) إلى قائمة التحميل المسبق العامة الخاصة بأمان النقل الصارم عبر HTTP (HSTS). وهذا يضمن أن استخدام TLS للتطبيق مدمج مباشرةً في المتصفحات الرئيسية، بدلًا من التعويل على حقل ترويسة استجابة Strict-Transport-Security فقط. | 3 | +| **3.7.5** | تحقق من أن التطبيق يتصرّف على النحو الموثّق (مثل تحذير المستخدم أو حجب الوصول) إذا كان المتصفح المستخدم للوصول إلى التطبيق لا يدعم ميزات الأمان المتوقعة. | 3 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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/ar/0x13-V4-API-and-Web-Service.md b/5.0/ar/0x13-V4-API-and-Web-Service.md new file mode 100644 index 0000000000..889e6f2d3b --- /dev/null +++ b/5.0/ar/0x13-V4-API-and-Web-Service.md @@ -0,0 +1,64 @@ +# V4 واجهات برمجة التطبيقات وخدمات الويب + +## الهدف من ضوابط الأمان + +تنطبق عدة اعتبارات بشكل خاص على التطبيقات التي تعرض واجهات برمجة التطبيقات (APIs) لاستخدامها من قِبل متصفحات الويب أو غيرها من المستهلكين (باستخدام JSON أو XML أو GraphQL في الغالب). يغطي هذا الفصل التكوينات والآليات الأمنية ذات الصلة التي ينبغي تطبيقها. + +لاحظ أن الاعتبارات المتعلقة بالمصادقة وإدارة الجلسات والتحقق من صحة المدخلات الواردة في فصول أخرى تنطبق كذلك على واجهات برمجة التطبيقات، ولذلك لا يمكن أخذ هذا الفصل خارج سياقه أو اختباره بمعزل عن غيره. + +## V4.1 الأمان العام لخدمات الويب + +يتناول هذا القسم الاعتبارات الأمنية العامة لخدمات الويب، وبالتالي الممارسات الأساسية للسلامة الأمنية في خدمات الويب. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **4.1.1** | تحقق من أن كل استجابة HTTP تحتوي على متن رسالة تشتمل على حقل ترويسة Content-Type يطابق المحتوى الفعلي للاستجابة، بما في ذلك معامل charset لتحديد ترميز محارف آمن (مثل UTF-8 أو ISO-8859-1) وفقًا لأنواع الوسائط المعتمدة من IANA، مثل "text/" و"/+xml" و"/xml". | 1 | +| **4.1.2** | تحقق من أن نقاط النهاية الموجهة للمستخدم فقط (المخصصة للوصول اليدوي عبر متصفح الويب) هي التي تعيد التوجيه تلقائيًا من HTTP إلى HTTPS، بينما لا تنفّذ الخدمات أو نقاط النهاية الأخرى إعادة توجيه شفافة. والغرض من ذلك تجنب الحالة التي يرسل فيها العميل طلبات HTTP غير مشفّرة عن طريق الخطأ، ولكن نظرًا لإعادة توجيه هذه الطلبات تلقائيًا إلى HTTPS، يبقى تسريب البيانات الحساسة غير مكتشف. | 2 | +| **4.1.3** | تحقق من أن أي حقل ترويسة HTTP يستخدمه التطبيق ويُضبط بواسطة طبقة وسيطة، مثل موازن الحمل أو وكيل الويب أو خدمة الواجهة الخلفية للواجهة الأمامية، لا يمكن للمستخدم النهائي تجاوزه. ومن أمثلة الترويسات X-Real-IP أو X-Forwarded-* أو X-User-ID. | 2 | +| **4.1.4** | تحقق من أنه لا يمكن استخدام سوى طرائق HTTP المدعومة صراحةً من قِبل التطبيق أو واجهة برمجة التطبيقات الخاصة به (بما في ذلك OPTIONS أثناء الطلبات التمهيدية)، وأن الطرائق غير المستخدمة محجوبة. | 3 | +| **4.1.5** | تحقق من استخدام التوقيعات الرقمية لكل رسالة لتوفير ضمان إضافي فوق حماية طبقة النقل للطلبات أو المعاملات البالغة الحساسية أو التي تمر عبر عدد من الأنظمة. | 3 | + +## V4.2 التحقق من بنية رسائل HTTP + +يوضح هذا القسم كيف ينبغي التحقق من بنية رسالة HTTP وحقول ترويستها لمنع هجمات مثل تهريب الطلبات وتقسيم الاستجابة وحقن الترويسات وحجب الخدمة عن طريق رسائل HTTP المفرطة الطول. + +هذه المتطلبات ذات صلة بمعالجة رسائل HTTP وتوليدها بشكل عام، لكنها مهمة على وجه الخصوص عند تحويل رسائل HTTP بين إصدارات HTTP المختلفة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **4.2.1** | تحقق من أن جميع مكوّنات التطبيق (بما في ذلك موازنات الحمل والجدران النارية وخوادم التطبيقات) تحدّد حدود رسائل HTTP الواردة باستخدام الآلية المناسبة لإصدار HTTP لمنع تهريب طلبات HTTP. في HTTP/1.x، إذا كان حقل الترويسة Transfer-Encoding موجودًا، فيجب تجاهل ترويسة Content-Length وفقًا لـ RFC 2616. وعند استخدام HTTP/2 أو HTTP/3، إذا كان حقل الترويسة Content-Length موجودًا، فيجب على المستقبِل التأكد من توافقه مع طول أُطر DATA. | 2 | +| **4.2.2** | تحقق من أن حقل الترويسة Content-Length، عند توليد رسائل HTTP، لا يتعارض مع طول المحتوى كما تحدده أُطر بروتوكول HTTP، وذلك لمنع هجمات تهريب الطلبات. | 3 | +| **4.2.3** | تحقق من أن التطبيق لا يرسل ولا يقبل رسائل HTTP/2 أو HTTP/3 التي تحتوي على حقول ترويسة خاصة بالاتصال مثل Transfer-Encoding، وذلك لمنع هجمات تقسيم الاستجابة وحقن الترويسات. | 3 | +| **4.2.4** | تحقق من أن التطبيق لا يقبل سوى طلبات HTTP/2 وHTTP/3 التي لا تحتوي حقول ترويستها وقيمها على أي متتاليات CR (\r) أو LF (\n) أو CRLF (\r\n)، وذلك لمنع هجمات حقن الترويسات. | 3 | +| **4.2.5** | تحقق من أن التطبيق، إذا كان يبني الطلبات ويرسلها (في الواجهة الخلفية أو الأمامية)، يستخدم التحقق من الصحة أو التنقية أو آليات أخرى لتجنب إنشاء معرّفات موارد موحّدة (URIs) (مثل تلك الخاصة باستدعاءات واجهة برمجة التطبيقات) أو حقول ترويسة طلب HTTP (مثل Authorization أو Cookie) تكون أطول من أن يقبلها المكوّن المستقبِل. وقد يؤدي ذلك إلى حجب الخدمة، كما يحدث عند إرسال طلب مفرط الطول (مثل حقل ترويسة cookie طويل)، ما ينتج عنه رد الخادم دائمًا بحالة خطأ. | 3 | + +## V4.3 GraphQL + +أصبح GraphQL أكثر شيوعًا كوسيلة لإنشاء عملاء غنيين بالبيانات وغير مرتبطين ارتباطًا وثيقًا بمجموعة متنوعة من خدمات الواجهة الخلفية. يغطي هذا القسم الاعتبارات الأمنية الخاصة بـ GraphQL. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **4.3.1** | تحقق من استخدام قائمة سماح للاستعلامات أو تحديد العمق أو تحديد الكمية أو تحليل تكلفة الاستعلام لمنع حجب الخدمة (DoS) في GraphQL أو في تعبيرات طبقة البيانات نتيجة الاستعلامات المتداخلة والمكلفة. | 2 | +| **4.3.2** | تحقق من تعطيل استعلامات الاستبطان (introspection) في GraphQL في بيئة الإنتاج، إلا إذا كان الغرض من واجهة برمجة تطبيقات GraphQL أن تستخدمها أطراف أخرى. | 2 | + +## V4.4 WebSocket + +WebSocket هو بروتوكول اتصالات يوفّر قناة اتصال ثنائية الاتجاه متزامنة عبر اتصال TCP واحد. وقد وضعته IETF كمعيار في RFC 6455 عام 2011، وهو مختلف عن HTTP، على الرغم من أنه مصمّم للعمل عبر منفذي HTTP رقم 443 و80. + +يوفّر هذا القسم متطلبات أمنية أساسية لمنع الهجمات المتعلقة بأمان الاتصال وإدارة الجلسات التي تستغل تحديدًا قناة الاتصال الفوري هذه. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **4.4.1** | تحقق من استخدام WebSocket عبر TLS (WSS) في جميع اتصالات WebSocket. | 1 | +| **4.4.2** | تحقق من أن حقل الترويسة Origin، أثناء مصافحة WebSocket الأولية عبر HTTP، يُفحص مقابل قائمة بالأصول المسموح بها للتطبيق. | 2 | +| **4.4.3** | تحقق من أنه، في حال عدم إمكانية استخدام إدارة الجلسات القياسية الخاصة بالتطبيق، تُستخدم رموز مميزة مخصّصة لهذا الغرض، تمتثل لمتطلبات أمان إدارة الجلسات ذات الصلة. | 2 | +| **4.4.4** | تحقق من أن الرموز المميزة المخصّصة لإدارة جلسات WebSocket يتم الحصول عليها أو التحقق منها مبدئيًا من خلال جلسة HTTPS المصادَق عليها مسبقًا عند تحويل جلسة HTTPS قائمة إلى قناة WebSocket. | 2 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [OWASP REST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html) +* موارد عن التخويل في GraphQL من [graphql.org](https://graphql.org/learn/authorization/) و[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/ar/0x14-V5-File-Handling.md b/5.0/ar/0x14-V5-File-Handling.md new file mode 100644 index 0000000000..a83b933a7d --- /dev/null +++ b/5.0/ar/0x14-V5-File-Handling.md @@ -0,0 +1,54 @@ +# V5 التعامل مع الملفات + +## الهدف من ضوابط الأمان + +يمكن أن يمثّل استخدام الملفات مخاطر متنوعة للتطبيق، منها حجب الخدمة والوصول غير المصرَّح به واستنفاد مساحة التخزين. ويشتمل هذا الفصل على متطلبات لمعالجة هذه المخاطر. + +## V5.1 توثيق التعامل مع الملفات + +يشتمل هذا القسم على متطلب لتوثيق الخصائص المتوقعة للملفات التي يقبلها التطبيق، كشرط مسبق ضروري لتطوير الفحوص الأمنية ذات الصلة والتحقق منها. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **5.1.1** | تحقق من أن الوثائق تحدّد أنواع الملفات المسموح بها وامتدادات الملفات المتوقعة والحجم الأقصى (بما في ذلك الحجم بعد فك الحزم) لكل ميزة تحميل. وإضافةً إلى ذلك، تأكّد من أن الوثائق تحدّد كيف تُجعل الملفات آمنة للمستخدمين النهائيين لتنزيلها ومعالجتها، مثل كيفية تصرّف التطبيق عند اكتشاف ملف ضار. | 2 | + +## V5.2 تحميل الملفات ومحتواها + +تُعدّ وظيفة تحميل الملفات مصدرًا رئيسيًا للملفات غير الموثوقة. ويبيّن هذا القسم المتطلبات اللازمة للتأكد من أن وجود هذه الملفات أو حجمها أو محتواها لا يمكن أن يضرّ بالتطبيق. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **5.2.1** | تحقق من أن التطبيق لن يقبل سوى الملفات ذات الحجم الذي يمكنه معالجته دون التسبب في فقدان الأداء أو هجوم حجب الخدمة. | 1 | +| **5.2.2** | تحقق من أن التطبيق، عند قبوله ملفًا، سواء بمفرده أو داخل أرشيف مثل ملف zip، يفحص ما إذا كان امتداد الملف يطابق امتدادًا متوقعًا ويتحقق من أن المحتويات تتوافق مع النوع الذي يمثّله الامتداد. ويشمل ذلك، على سبيل المثال لا الحصر، فحص "البايتات السحرية" الأولية، وإجراء إعادة كتابة للصور، واستخدام مكتبات متخصّصة للتحقق من محتوى الملفات. وبالنسبة إلى المستوى 1، يمكن أن يركّز ذلك على الملفات المستخدمة في اتخاذ قرارات تجارية أو أمنية محدّدة فقط. أما للمستوى 2 وما فوق، فيجب أن ينطبق على جميع الملفات المقبولة. | 1 | +| **5.2.3** | تحقق من أن التطبيق يفحص الملفات المضغوطة (مثل zip وgz وdocx وodt) مقابل الحجم الأقصى المسموح به بعد فك الضغط ومقابل العدد الأقصى للملفات قبل فك ضغط الملف. | 2 | +| **5.2.4** | تحقق من إنفاذ حصة لحجم الملفات وعدد أقصى للملفات لكل مستخدم للتأكد من أن مستخدمًا واحدًا لا يمكنه إشغال مساحة التخزين بعدد كبير جدًا من الملفات أو بملفات كبيرة الحجم بشكل مفرط. | 3 | +| **5.2.5** | تحقق من أن التطبيق لا يسمح بتحميل ملفات مضغوطة تحتوي على روابط رمزية إلا إذا كان ذلك مطلوبًا تحديدًا (وفي هذه الحالة سيكون من الضروري إنفاذ قائمة سماح بالملفات التي يمكن الربط الرمزي إليها). | 3 | +| **5.2.6** | تحقق من أن التطبيق يرفض الصور المحمَّلة التي يتجاوز حجمها بالبكسل الحد الأقصى المسموح به، وذلك لمنع هجمات إغراق البكسل. | 3 | + +## V5.3 تخزين الملفات + +يشتمل هذا القسم على متطلبات لمنع تنفيذ الملفات على نحو غير ملائم بعد تحميلها، ولكشف المحتوى الخطير، ولتجنّب استخدام بيانات غير موثوقة في التحكم بمكان تخزين الملفات. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **5.3.1** | تحقق من أن الملفات المحمَّلة أو المُولَّدة بمدخلات غير موثوقة والمخزَّنة في مجلد عام لا تُنفَّذ كشيفرة برنامج من جانب الخادم عند الوصول إليها مباشرةً بطلب HTTP. | 1 | +| **5.3.2** | تحقق من أن التطبيق، عند إنشائه مسارات ملفات لعمليات الملفات، يستخدم بيانات مُولَّدة داخليًا أو موثوقة بدلًا من أسماء الملفات المقدَّمة من المستخدم، أو إذا كان لا بد من استخدام أسماء الملفات أو بياناتها الوصفية المقدَّمة من المستخدم، فيجب تطبيق تحقق صارم وتنقية. والغرض من ذلك الحماية من هجمات اجتياز المسار وتضمين الملفات المحلية أو البعيدة (LFI وRFI) وتزوير الطلب من جانب الخادم (SSRF). | 1 | +| **5.3.3** | تحقق من أن معالجة الملفات من جانب الخادم، مثل فك ضغط الملفات، تتجاهل معلومات المسار المقدَّمة من المستخدم لمنع ثغرات مثل zip slip. | 3 | + +## V5.4 تنزيل الملفات + +يحتوي هذا القسم على متطلبات للتخفيف من المخاطر عند تقديم الملفات للتنزيل، بما في ذلك اجتياز المسار وهجمات الحقن. ويشمل ذلك أيضًا التأكد من أنها لا تحتوي على محتوى خطير. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **5.4.1** | تحقق من أن التطبيق يتحقق من أسماء الملفات المقدَّمة من المستخدم أو يتجاهلها، بما في ذلك الواردة في JSON أو JSONP أو معامل URL، وأنه يحدّد اسم ملف في حقل ترويسة Content-Disposition في الاستجابة. | 2 | +| **5.4.2** | تحقق من أن أسماء الملفات المقدَّمة (مثلًا في حقول ترويسة استجابة HTTP أو مرفقات البريد الإلكتروني) مُرمَّزة أو مُنقّاة (مثلًا وفقًا لـ RFC 6266) للحفاظ على بنية المستند ومنع هجمات الحقن. | 2 | +| **5.4.3** | تحقق من أن الملفات التي تُجلب من مصادر غير موثوقة تُفحص بواسطة برامج مكافحة الفيروسات لمنع تقديم محتوى ضار معروف. | 2 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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/ar/0x15-V6-Authentication.md b/5.0/ar/0x15-V6-Authentication.md new file mode 100644 index 0000000000..d9fa0025ad --- /dev/null +++ b/5.0/ar/0x15-V6-Authentication.md @@ -0,0 +1,166 @@ +# V6 Authentication + +## 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. + +[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. + +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. + +Additionally, NIST SP 800-63 terminology may sometimes differ, and this chapter often uses more commonly understood terminology to improve clarity. + +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. + +## V6.1 Authentication Documentation + +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 | + +## V6.2 Password Security + +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. + +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. + +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). + +| # | 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 | + +## V6.3 General Authentication Security + +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. + +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. + +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)). + +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). + +| # | 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 | + +## V6.4 Authentication Factor Lifecycle and Recovery + +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. + +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). + +| # | 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 | + +## V6.5 General Multi-factor authentication requirements + +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 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. + +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). + +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). + +| # | 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 | + +## V6.6 Out-of-Band authentication mechanisms + +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". + +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. + +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". + +| # | 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 | + +## V6.7 Cryptographic authentication mechanism + +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. + +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. + +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). + +| # | 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 | + +## V6.8 Authentication with an Identity Provider + +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. + +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. + +| # | 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 | + +## 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/ar/0x16-V7-Session-Management.md b/5.0/ar/0x16-V7-Session-Management.md new file mode 100644 index 0000000000..d47e25c8d5 --- /dev/null +++ b/5.0/ar/0x16-V7-Session-Management.md @@ -0,0 +1,91 @@ +# V7 إدارة الجلسات + +## الهدف من ضوابط الأمان + +تتيح آليات إدارة الجلسات للتطبيقات ربط تفاعلات المستخدم والجهاز على مدار الزمن، حتى عند استخدام بروتوكولات اتصال عديمة الحالة (مثل HTTP). وقد تستخدم التطبيقات الحديثة رموز جلسة متعددة بخصائص وأغراض متمايزة. ونظام إدارة الجلسات الآمن هو الذي يمنع المهاجمين من الحصول على جلسة الضحية أو استخدامها أو إساءة استغلالها بأي صورة أخرى. ويجب على التطبيقات التي تحتفظ بجلسات أن تضمن استيفاء متطلبات إدارة الجلسات الرفيعة المستوى التالية: + +* أن تكون الجلسات فريدة لكل فرد ولا يمكن تخمينها أو مشاركتها. +* أن تُبطل الجلسات عندما لا تعد لازمة وأن تنتهي مهلتها في فترات عدم النشاط. + +ويتعلق كثير من المتطلبات في هذا الفصل بضوابط مختارة من [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-4/)، مع التركيز على التهديدات الشائعة ونقاط ضعف المصادقة الشائعة الاستغلال. + +ولاحظ أن متطلبات تفاصيل التنفيذ المحدّدة لبعض آليات إدارة الجلسات يمكن العثور عليها في مواضع أخرى: + +* تُعدّ ملفات تعريف ارتباط HTTP آلية شائعة لتأمين رموز الجلسة. ويمكن العثور على المتطلبات الأمنية المحدّدة لملفات تعريف الارتباط في فصل "أمان واجهة الويب الأمامية". +* تُستخدم الرموز المميزة المكتفية بذاتها كثيرًا كوسيلة للحفاظ على الجلسات. ويمكن العثور على المتطلبات الأمنية المحدّدة في فصل "الرموز المميزة المكتفية بذاتها". + +## V7.1 توثيق إدارة الجلسات + +لا يوجد نمط واحد يناسب جميع التطبيقات. ولذلك ليس من الممكن تحديد حدود وقيود عامة تناسب جميع الحالات. ويجب إجراء تحليل للمخاطر مع قرارات أمنية موثّقة متعلقة بالتعامل مع الجلسات كشرط مسبق للتنفيذ والاختبار. وهذا يضمن أن نظام إدارة الجلسات مُصمَّم وفق المتطلبات المحدّدة للتطبيق. + +وبصرف النظر عن اختيار آلية جلسة ذات حالة أو "عديمة الحالة"، يجب أن يكون التحليل كاملًا وموثّقًا لإثبات أن الحل المختار قادر على تلبية جميع المتطلبات الأمنية ذات الصلة. وينبغي كذلك مراعاة التفاعل مع أي آليات للدخول الموحّد (SSO) قيد الاستخدام. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **7.1.1** | تحقق من أن مهلة عدم نشاط جلسة المستخدم والعمر الأقصى المطلق للجلسة موثّقان، وملائمان بالاقتران مع ضوابط أخرى، ومن أن الوثائق تشتمل على تبرير لأي انحرافات عن متطلبات إعادة المصادقة في NIST SP 800-63B. | 2 | +| **7.1.2** | تحقق من أن الوثائق تحدّد عدد الجلسات المتزامنة (المتوازية) المسموح بها لحساب واحد، وكذلك التصرّفات والإجراءات المقصودة التي ستُتّخذ عند بلوغ العدد الأقصى للجلسات النشطة. | 2 | +| **7.1.3** | تحقق من توثيق جميع الأنظمة التي تنشئ جلسات المستخدمين وتديرها كجزء من منظومة إدارة هوية اتحادية (مثل أنظمة الدخول الموحّد)، إلى جانب الضوابط اللازمة لتنسيق أعمار الجلسات وإنهائها وأي شروط أخرى تقتضي إعادة المصادقة. | 2 | + +## V7.2 الأمان الأساسي لإدارة الجلسات + +يلبّي هذا القسم المتطلبات الجوهرية للجلسات الآمنة بالتحقق من أن رموز الجلسة تُولَّد ويُتحقَّق منها بأمان. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **7.2.1** | تحقق من أن التطبيق ينفّذ جميع عمليات التحقق من رموز الجلسة باستخدام خدمة موثوقة في الواجهة الخلفية. | 1 | +| **7.2.2** | تحقق من أن التطبيق يستخدم رموزًا مكتفية بذاتها أو رموزًا مرجعية تُولَّد ديناميكيًا لإدارة الجلسات، أي أنه لا يستخدم أسرارًا ومفاتيح ثابتة لواجهات برمجة التطبيقات. | 1 | +| **7.2.3** | تحقق من أنه، إذا استُخدمت الرموز المرجعية لتمثيل جلسات المستخدمين، فإنها فريدة ومُولَّدة باستخدام مولّد أعداد شبه عشوائية آمن تشفيريًا (CSPRNG) وتمتلك 128 بتًا على الأقل من العشوائية. | 1 | +| **7.2.4** | تحقق من أن التطبيق يولّد رمز جلسة جديدًا عند مصادقة المستخدم، بما في ذلك إعادة المصادقة، وينهي رمز الجلسة الحالي. | 1 | + +## V7.3 مهلة الجلسة + +تخدم آليات مهلة الجلسة غرض تقليص نافذة الفرصة لاختطاف الجلسة وغيره من أشكال إساءة استغلال الجلسة. ويجب أن تلبّي المهل القرارات الأمنية الموثّقة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **7.3.1** | تحقق من وجود مهلة لعدم النشاط بحيث تُنفَذ إعادة المصادقة وفق تحليل المخاطر والقرارات الأمنية الموثّقة. | 2 | +| **7.3.2** | تحقق من وجود عمر أقصى مطلق للجلسة بحيث تُنفَذ إعادة المصادقة وفق تحليل المخاطر والقرارات الأمنية الموثّقة. | 2 | + +## V7.4 إنهاء الجلسة + +قد يتولى إنهاء الجلسة التطبيق نفسه أو مزوّد الدخول الموحّد إذا كان المزوّد هو من يتولى إدارة الجلسات بدلًا من التطبيق. وقد يكون من الضروري تحديد ما إذا كان مزوّد الدخول الموحّد داخلًا في النطاق عند النظر في متطلبات هذا القسم، إذ قد يتحكّم المزوّد في بعضها. + +وينبغي أن يؤدي إنهاء الجلسة إلى اشتراط إعادة المصادقة وأن يكون نافذًا على امتداد التطبيق وتسجيل الدخول الاتحادي (إن وُجد) وأي أطراف معوِّلة. + +وبالنسبة إلى آليات الجلسات ذات الحالة، يتضمّن الإنهاء عادةً إبطال الجلسة في الواجهة الخلفية. أما في حالة الرموز المميزة المكتفية بذاتها، فيلزم اتخاذ تدابير إضافية لإبطال هذه الرموز أو حجبها، إذ قد تبقى صالحة حتى انتهاء صلاحيتها. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **7.4.1** | تحقق من أن التطبيق، عند تشغيل إنهاء الجلسة (مثل تسجيل الخروج أو انتهاء الصلاحية)، يمنع أي استخدام إضافي للجلسة. وبالنسبة إلى الرموز المرجعية أو الجلسات ذات الحالة، يعني ذلك إبطال بيانات الجلسة في الواجهة الخلفية للتطبيق. أما التطبيقات التي تستخدم رموزًا مكتفية بذاتها فستحتاج إلى حل مثل الاحتفاظ بقائمة بالرموز المنتهية، أو منع الرموز المُنتَجة قبل تاريخ ووقت محدّدين لكل مستخدم، أو تدوير مفتاح توقيع خاص بكل مستخدم. | 1 | +| **7.4.2** | تحقق من أن التطبيق ينهي جميع الجلسات النشطة عند تعطيل حساب مستخدم أو حذفه (مثل مغادرة موظف للشركة). | 1 | +| **7.4.3** | تحقق من أن التطبيق يمنح خيار إنهاء جميع الجلسات النشطة الأخرى بعد نجاح تغيير أي عامل مصادقة أو إزالته (بما في ذلك تغيير كلمة المرور عن طريق إعادة التعيين أو الاستعادة، وتحديث إعدادات المصادقة متعددة العوامل إن وُجدت). | 2 | +| **7.4.4** | تحقق من أن جميع الصفحات التي تتطلّب مصادقة تتيح وصولًا سهلًا وظاهرًا إلى وظيفة تسجيل الخروج. | 2 | +| **7.4.5** | تحقق من أن مسؤولي التطبيق قادرون على إنهاء الجلسات النشطة لمستخدم فردي أو لجميع المستخدمين. | 2 | + +## V7.5 الدفاعات ضد إساءة استغلال الجلسة + +يوفّر هذا القسم متطلبات للتخفيف من المخاطر التي تمثّلها الجلسات النشطة التي تُختطَف أو يُساء استغلالها عبر متجهات تعتمد على وجود جلسات المستخدمين النشطة وقدراتها. على سبيل المثال، استخدام تنفيذ محتوى ضار لإجبار متصفح ضحية مصادَق عليه على تنفيذ إجراء باستخدام جلسة الضحية. + +ولاحظ أنه ينبغي مراعاة الإرشادات الخاصة بالمستويات في فصل "المصادقة" عند النظر في متطلبات هذا القسم. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **7.5.1** | تحقق من أن التطبيق يتطلّب إعادة مصادقة كاملة قبل السماح بتعديل سمات الحساب الحساسة التي قد تؤثّر في المصادقة، مثل عنوان البريد الإلكتروني أو رقم الهاتف أو تكوين المصادقة متعددة العوامل أو غيرها من المعلومات المستخدمة في استعادة الحساب. | 2 | +| **7.5.2** | تحقق من أن المستخدمين قادرون على عرض أي من الجلسات النشطة حاليًا أو جميعها وإنهائها (بعد إعادة المصادقة بعامل واحد على الأقل). | 2 | +| **7.5.3** | تحقق من أن التطبيق يتطلّب مصادقة إضافية بعامل واحد على الأقل أو تحققًا ثانويًا قبل تنفيذ المعاملات أو العمليات البالغة الحساسية. | 3 | + +## V7.6 إعادة المصادقة الاتحادية + +يتعلق هذا القسم بمن يكتبون شيفرة الطرف المعوِّل (RP) أو مزوّد الهوية (IdP). وهذه المتطلبات مستقاة من [NIST SP 800-63C](https://pages.nist.gov/800-63-4/sp800-63c.html) الخاص بالاتحاد والتأكيدات. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **7.6.1** | تحقق من أن عمر الجلسة وإنهاءها بين الأطراف المعوِّلة (RPs) ومزوّدي الهوية (IdPs) يسلكان على النحو الموثّق، مع اشتراط إعادة المصادقة عند الضرورة، مثل بلوغ الحد الأقصى للمدة بين أحداث المصادقة لدى مزوّد الهوية. | 2 | +| **7.6.2** | تحقق من أن إنشاء الجلسة يتطلّب إما موافقة المستخدم أو إجراءً صريحًا، بما يمنع إنشاء جلسات تطبيق جديدة دون تفاعل المستخدم. | 2 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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/ar/0x17-V8-Authorization.md b/5.0/ar/0x17-V8-Authorization.md new file mode 100644 index 0000000000..d504092c31 --- /dev/null +++ b/5.0/ar/0x17-V8-Authorization.md @@ -0,0 +1,56 @@ +# V8 التخويل + +## الهدف من ضوابط الأمان + +يضمن التخويل أن الوصول لا يُمنح إلا للمستهلكين المسموح لهم (المستخدمون والخوادم والعملاء الآخرون). ولإنفاذ مبدأ الحد الأدنى من الصلاحيات (POLP)، يجب أن تستوفي التطبيقات المتحقَّق منها المتطلبات الرفيعة المستوى التالية: + +* توثيق قواعد التخويل، بما في ذلك عوامل اتخاذ القرار والسياقات البيئية. +* ينبغي أن يكون للمستهلكين وصول إلى الموارد التي تسمح بها استحقاقاتهم المحدّدة فقط. + +## V8.1 توثيق التخويل + +إن التوثيق الشامل للتخويل ضروري للتأكد من أن القرارات الأمنية تُطبَّق باتساق وقابلة للتدقيق ومتوافقة مع سياسات المؤسسة. وهذا يقلّل خطر الوصول غير المصرَّح به بجعل متطلبات الأمان واضحة وقابلة للتنفيذ للمطوّرين والمسؤولين والمختبرين. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **8.1.1** | تحقق من أن توثيق التخويل يحدّد قواعد لتقييد الوصول على مستوى الوظائف والوصول الخاص بالبيانات بناءً على صلاحيات المستهلك وسمات الموارد. | 1 | +| **8.1.2** | تحقق من أن توثيق التخويل يحدّد قواعد لتقييد الوصول على مستوى الحقول (للقراءة والكتابة على حد سواء) بناءً على صلاحيات المستهلك وسمات الموارد. ولاحظ أن هذه القواعد قد تعتمد على قيم سمات أخرى لكائن البيانات المعني، مثل الحالة أو الوضع. | 2 | +| **8.1.3** | تحقق من أن وثائق التطبيق تحدّد السمات البيئية والسياقية (بما في ذلك، على سبيل المثال لا الحصر، وقت اليوم أو موقع المستخدم أو عنوان IP أو الجهاز) المستخدمة في التطبيق لاتخاذ القرارات الأمنية، بما فيها القرارات المتعلقة بالمصادقة والتخويل. | 3 | +| **8.1.4** | تحقق من أن وثائق المصادقة والتخويل تحدّد كيفية استخدام العوامل البيئية والسياقية في اتخاذ القرار، إضافةً إلى التخويل على مستوى الوظائف والبيانات والحقول. وينبغي أن يشمل ذلك السمات التي تُقيَّم وحدود المخاطر والإجراءات المتّخذة (مثل السماح أو التحدي أو المنع أو المصادقة المعزّزة). | 3 | + +## V8.2 التصميم العام للتخويل + +إن تنفيذ ضوابط تخويل دقيقة على مستويات الوظائف والبيانات والحقول يضمن أن المستهلكين لا يمكنهم الوصول إلا إلى ما مُنح لهم صراحةً. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **8.2.1** | تحقق من أن التطبيق يضمن أن الوصول على مستوى الوظائف مقصور على المستهلكين ذوي الصلاحيات الصريحة. | 1 | +| **8.2.2** | تحقق من أن التطبيق يضمن أن الوصول الخاص بالبيانات مقصور على المستهلكين ذوي الصلاحيات الصريحة لعناصر بيانات محدّدة، وذلك للتخفيف من الإشارة المباشرة غير الآمنة إلى الكائنات (IDOR) والتخويل المعطوب على مستوى الكائن (BOLA). | 1 | +| **8.2.3** | تحقق من أن التطبيق يضمن أن الوصول على مستوى الحقول مقصور على المستهلكين ذوي الصلاحيات الصريحة لحقول محدّدة، وذلك للتخفيف من التخويل المعطوب على مستوى خصائص الكائن (BOPLA). | 2 | +| **8.2.4** | تحقق من تنفيذ ضوابط أمنية تكيّفية مبنية على السمات البيئية والسياقية للمستهلك (مثل وقت اليوم أو الموقع أو عنوان IP أو الجهاز) لقرارات المصادقة والتخويل، على النحو المحدّد في وثائق التطبيق. ويجب تطبيق هذه الضوابط عندما يحاول المستهلك بدء جلسة جديدة وكذلك أثناء جلسة قائمة. | 3 | + +## V8.3 التخويل على مستوى العمليات + +إن التطبيق الفوري لتغييرات التخويل في الطبقة المناسبة من معمارية التطبيق أمر بالغ الأهمية لمنع الإجراءات غير المصرَّح بها، وخصوصًا في البيئات الديناميكية. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **8.3.1** | تحقق من أن التطبيق يُنفِذ قواعد التخويل في طبقة خدمة موثوقة ولا يعتمد على ضوابط يمكن لمستهلك غير موثوق التلاعب بها، مثل JavaScript من جانب العميل. | 1 | +| **8.3.2** | تحقق من أن التغييرات في القيم التي تُتخذ على أساسها قرارات التخويل تُطبَّق فورًا. وحيث لا يمكن تطبيق التغييرات فورًا (مثل حالة الاعتماد على بيانات في رموز مميزة مكتفية بذاتها)، يجب أن توجد ضوابط مخفِّفة للتنبيه عندما ينفّذ المستهلك إجراءً لم يعد مصرَّحًا له بتنفيذه، ولإرجاع التغيير. ولاحظ أن هذا البديل لن يخفّف من تسريب المعلومات. | 3 | +| **8.3.3** | تحقق من أن الوصول إلى كائن يستند إلى صلاحيات الذات الأصلية (مثل المستهلك)، وليس إلى صلاحيات أي وسيط أو خدمة تعمل بالنيابة عنه. على سبيل المثال، إذا استدعى مستهلك خدمة ويب باستخدام رمز مميز مكتفٍ بذاته للمصادقة، ثم طلبت الخدمة بيانات من خدمة أخرى، فستستخدم الخدمة الثانية رمز المستهلك، وليس رمزًا من آلة إلى آلة من الخدمة الأولى، لاتخاذ قرارات الصلاحيات. | 3 | + +## V8.4 اعتبارات أخرى للتخويل + +تساعد الاعتبارات الإضافية للتخويل، وخصوصًا لواجهات الإدارة والبيئات متعددة المستأجرين، على منع الوصول غير المصرَّح به. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **8.4.1** | تحقق من أن التطبيقات متعددة المستأجرين تستخدم ضوابط عبر المستأجرين للتأكد من أن عمليات المستهلك لن تؤثر أبدًا في مستأجرين لا يمتلك صلاحيات التفاعل معهم. | 2 | +| **8.4.2** | تحقق من أن الوصول إلى واجهات الإدارة يشتمل على طبقات أمان متعددة، بما في ذلك التحقق المستمر من هوية المستهلك وتقييم الوضع الأمني للجهاز وتحليل المخاطر السياقي، بما يضمن ألا يكون موقع الشبكة أو نقاط النهاية الموثوقة العوامل الوحيدة للتخويل، وإن كانت قد تقلّل احتمال الوصول غير المصرَّح به. | 3 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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/ar/0x18-V9-Self-contained-Tokens.md b/5.0/ar/0x18-V9-Self-contained-Tokens.md new file mode 100644 index 0000000000..a983db5811 --- /dev/null +++ b/5.0/ar/0x18-V9-Self-contained-Tokens.md @@ -0,0 +1,36 @@ +# V9 الرموز المميزة المكتفية بذاتها + +## الهدف من ضوابط الأمان + +ورد مفهوم الرمز المميز المكتفي بذاته في الأصل في RFC 6749 الخاص بـ OAuth 2.0 لعام 2012. وهو يشير إلى رمز مميز يحتوي على بيانات أو مطالبات تعوّل عليها خدمة مستقبِلة لاتخاذ قرارات أمنية. وينبغي تمييز ذلك عن رمز مميز بسيط يحتوي على معرّف فقط، تستخدمه الخدمة المستقبِلة للبحث عن البيانات محليًا. وأشهر أمثلة الرموز المميزة المكتفية بذاتها هي رموز JSON Web Tokens (JWTs) وتأكيدات SAML. + +أصبح استخدام الرموز المميزة المكتفية بذاتها واسع الانتشار جدًا، حتى خارج نطاق OAuth وOIDC. وفي الوقت نفسه، يعتمد أمان هذه الآلية على القدرة على التحقق من سلامة الرمز والتأكد من أنه صالح لسياق معيّن. وهناك مزالق كثيرة في هذه العملية، ويوفّر هذا الفصل تفاصيل محدّدة عن الآليات التي ينبغي أن تتوافر في التطبيقات لمنعها. + +## V9.1 مصدر الرمز المميز وسلامته + +يشتمل هذا القسم على متطلبات للتأكد من أن الرمز المميز قد أنتجه طرف موثوق وأنه لم يُتلاعب به. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **9.1.1** | تحقق من أن الرموز المميزة المكتفية بذاتها يتم التحقق منها باستخدام توقيعها الرقمي أو رمز مصادقة الرسالة (MAC) للحماية من التلاعب قبل قبول محتوياتها. | 1 | +| **9.1.2** | تحقق من أن الخوارزميات المدرجة في قائمة سماح هي وحدها التي يمكن استخدامها لإنشاء الرموز المميزة المكتفية بذاتها والتحقق منها، في سياق معيّن. ويجب أن تتضمّن قائمة السماح الخوارزميات المسموح بها، ومن الأفضل أن تكون خوارزميات متناظرة فقط أو غير متناظرة فقط، ويجب ألا تتضمّن الخوارزمية 'None'. وإذا كان يجب دعم النوعين المتناظر وغير المتناظر، فستكون هناك حاجة إلى ضوابط إضافية لمنع الالتباس في المفاتيح. | 1 | +| **9.1.3** | تحقق من أن مادة المفاتيح المستخدمة للتحقق من الرموز المميزة المكتفية بذاتها تأتي من مصادر موثوقة مُهيّأة مسبقًا لجهة إصدار الرمز، ما يمنع المهاجمين من تحديد مصادر ومفاتيح غير موثوقة. وبالنسبة إلى رموز JWT وغيرها من بِنى JWS، يجب التحقق من ترويسات مثل 'jku' و'x5u' و'jwk' مقابل قائمة سماح بالمصادر الموثوقة. | 1 | + +## V9.2 محتوى الرمز المميز + +قبل اتخاذ قرارات أمنية بناءً على محتوى رمز مميز مكتفٍ بذاته، من الضروري التحقق من أن الرمز قد قُدّم خلال مدة صلاحيته وأنه مخصّص للاستخدام من قِبل الخدمة المستقبِلة وللغرض الذي قُدّم من أجله. وهذا يساعد على تجنّب الاستخدام المتقاطع غير الآمن بين خدمات مختلفة أو مع أنواع رموز مختلفة من الجهة المُصدِرة نفسها. + +أما المتطلبات الخاصة بـ OAuth وOIDC فهي مشمولة في الفصل المخصّص لها. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **9.2.1** | تحقق من أنه، في حال وجود مدة صلاحية في بيانات الرمز المميز، لا يُقبل الرمز ومحتواه إلا إذا كان وقت التحقق واقعًا داخل مدة الصلاحية هذه. على سبيل المثال، بالنسبة إلى رموز JWT، يجب التحقق من المطالبتين 'nbf' و'exp'. | 1 | +| **9.2.2** | تحقق من أن الخدمة التي تستقبل رمزًا مميزًا تتحقق من أنه من النوع الصحيح وأنه مخصّص للغرض المقصود قبل قبول محتوياته. على سبيل المثال، لا يمكن قبول سوى رموز الوصول لقرارات التخويل، ولا يمكن استخدام سوى رموز الهوية (ID Tokens) لإثبات مصادقة المستخدم. | 2 | +| **9.2.3** | تحقق من أن الخدمة لا تقبل سوى الرموز المميزة المخصّصة للاستخدام معها (الجهة المستهدفة). وبالنسبة إلى رموز JWT، يمكن تحقيق ذلك بالتحقق من مطالبة 'aud' مقابل قائمة سماح محدّدة في الخدمة. | 2 | +| **9.2.4** | تحقق من أنه، إذا كانت جهة إصدار الرموز تستخدم المفتاح الخاص نفسه لإصدار رموز لجهات مستهدفة مختلفة، فإن الرموز الصادرة تحتوي على قيد للجهة المستهدفة يعرّف الجهات المقصودة تعريفًا فريدًا. وهذا سيمنع إعادة استخدام الرمز مع جهة مستهدفة غير مقصودة. وإذا كان معرّف الجهة المستهدفة يُمنح ديناميكيًا، فيجب على جهة إصدار الرموز التحقق من هذه الجهات للتأكد من أنها لا تؤدي إلى انتحال هوية الجهة المستهدفة. | 2 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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/ar/0x19-V10-OAuth-and-OIDC.md b/5.0/ar/0x19-V10-OAuth-and-OIDC.md new file mode 100644 index 0000000000..e726216b4b --- /dev/null +++ b/5.0/ar/0x19-V10-OAuth-and-OIDC.md @@ -0,0 +1,169 @@ +# V10 OAuth and 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. + +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. + +The following roles are defined in 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. + +The following roles are defined in 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. + +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 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. + +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. + +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. + +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. + +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. + +In the context of OAuth and OIDC, the term "token" in this chapter refers to: + +* 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. + +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. + +## V10.1 Generic OAuth and OIDC Security + +This section covers generic architectural requirements that apply to all applications using OAuth or 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 | + +## 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). + +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. + +| # | 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 | + +## 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: + +* 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. + +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. + +| # | 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 | + +## V10.4 OAuth Authorization Server + +These requirements detail the responsibilities for OAuth authorization servers, including 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). + +| # | 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 | + +## V10.5 OIDC Client + +As the OIDC relying party acts as an OAuth client, the requirements from the section "OAuth Client" apply as well. + +Note that the "Authentication with an Identity Provider" section in the "Authentication" chapter also contains relevant general requirements. + +| # | 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 | + +## V10.6 OpenID Provider + +As OpenID Providers act as OAuth authorization servers, the requirements from the section "OAuth Authorization Server" apply as well. + +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. + +| # | 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 | + +## V10.7 Consent Management + +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. + +| # | 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 | + +## References + +For more information on OAuth, please see: + +* [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: + +* [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 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/ar/0x20-V11-Cryptography.md b/5.0/ar/0x20-V11-Cryptography.md new file mode 100644 index 0000000000..c3ef1374bc --- /dev/null +++ b/5.0/ar/0x20-V11-Cryptography.md @@ -0,0 +1,107 @@ +# V11 التشفير + +## الهدف من ضوابط الأمان + +الهدف من هذا الفصل تحديد الممارسات الفضلى للاستخدام العام للتشفير، وكذلك إرساء فهم أساسي لمبادئ التشفير والتحفيز على التحوّل إلى مناهج أكثر صمودًا وحداثة. وهو يشجّع على ما يلي: + +* تنفيذ أنظمة تشفير متينة تفشل بأمان وتتكيّف مع التهديدات المتطوّرة وتصمد للمستقبل. +* الاستفادة من آليات تشفير آمنة ومتوافقة مع الممارسات الفضلى في الصناعة. +* الحفاظ على نظام آمن لإدارة مفاتيح التشفير مع ضوابط وصول وتدقيق ملائمة. +* التقييم المنتظم لمشهد التشفير لتقدير المخاطر الجديدة وتكييف الخوارزميات وفقًا لذلك. +* استكشاف حالات استخدام التشفير وإدارتها على امتداد دورة حياة التطبيق للتأكد من أن جميع الأصول التشفيرية محسوبة ومؤمَّنة. + +وإضافةً إلى بيان المبادئ العامة والممارسات الفضلى، يوفّر هذا المستند كذلك معلومات تقنية أكثر تعمّقًا عن المتطلبات في الملحق ج - معايير التشفير. ويشمل ذلك الخوارزميات والأنماط التي تُعدّ "معتمدة" لأغراض المتطلبات الواردة في هذا الفصل. + +أما المتطلبات التي تستخدم التشفير لحل مشكلة منفصلة، مثل إدارة الأسرار أو أمان الاتصالات، فستكون في أجزاء أخرى من المعيار. + +## V11.1 جرد التشفير وتوثيقه + +يلزم تصميم التطبيقات بمعمارية تشفير قوية لحماية أصول البيانات وفق تصنيفها. فتشفير كل شيء مضيعة، وعدم تشفير أي شيء إهمال من الناحية القانونية. ويجب إيجاد توازن، عادةً أثناء التصميم المعماري أو الرفيع المستوى أو دورات التصميم أو الاستقصاءات المعمارية. وتصميم التشفير "على عجل" أو إضافته لاحقًا سيكلّف حتمًا أكثر بكثير لتنفيذه بأمان من مجرّد بنائه من البداية. + +ومن المهم التأكد من استكشاف جميع الأصول التشفيرية وجردها وتقييمها بانتظام. يُرجى الاطلاع على الملحق لمزيد من المعلومات عن كيفية تحقيق ذلك. + +والحاجة إلى تحصين أنظمة التشفير للمستقبل ضد الصعود المرتقب للحوسبة الكمومية بالغة الأهمية كذلك. ويشير التشفير ما بعد الكمومي (PQC) إلى خوارزميات تشفير مصمّمة لتبقى آمنة أمام هجمات الحواسيب الكمومية، التي يُتوقع أن تكسر خوارزميات واسعة الاستخدام مثل RSA وتشفير المنحنيات الإهليلجية (ECC). + +يُرجى الاطلاع على الملحق للإرشادات الراهنة عن أوليات ومعايير PQC المدروسة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **11.1.1** | تحقق من وجود سياسة موثّقة لإدارة مفاتيح التشفير ودورة حياة لمفاتيح التشفير تتّبع معيارًا لإدارة المفاتيح مثل NIST SP 800-57. وينبغي أن يشمل ذلك التأكد من عدم الإفراط في مشاركة المفاتيح (مثلًا مع أكثر من كيانين للأسرار المشتركة وأكثر من كيان واحد للمفاتيح الخاصة). | 2 | +| **11.1.2** | تحقق من أن جرد التشفير يُنفَّذ ويُصان ويُحدَّث بانتظام ويشمل جميع مفاتيح التشفير والخوارزميات والشهادات التي يستخدمها التطبيق. ويجب أن يوثّق كذلك المواضع التي يمكن وتلك التي لا يمكن استخدام المفاتيح فيها في النظام، وأنواع البيانات التي يمكن وتلك التي لا يمكن حمايتها باستخدام هذه المفاتيح. | 2 | +| **11.1.3** | تحقق من استخدام آليات استكشاف التشفير لتحديد جميع مواضع التشفير في النظام، بما فيها عمليات التشفير والتلبيد والتوقيع. | 3 | +| **11.1.4** | تحقق من الاحتفاظ بجرد للتشفير. ويجب أن يشمل ذلك خطة موثّقة تبيّن مسار الانتقال إلى معايير تشفير جديدة، مثل التشفير ما بعد الكمومي، وذلك للتفاعل مع التهديدات المستقبلية. | 3 | + +## V11.2 التنفيذ الآمن للتشفير + +يحدّد هذا القسم متطلبات اختيار خوارزميات التشفير الأساسية للتطبيق وتنفيذها وإدارتها المستمرة. والهدف التأكد من عدم نشر إلا أوليات تشفيرية متينة ومقبولة في الصناعة، بما يتوافق مع المعايير الراهنة (مثل NIST وISO/IEC) والممارسات الفضلى. ويجب على المؤسسات التأكد من اختيار كل مكوّن تشفيري بناءً على أدلة خضعت لمراجعة الأنداد واختبار أمني عملي. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **11.2.1** | تحقق من استخدام تنفيذات مُصادَق عليها في الصناعة (بما فيها المكتبات والتنفيذات المعزّزة بالعتاد) للعمليات التشفيرية. | 2 | +| **11.2.2** | تحقق من أن التطبيق مصمّم بمرونة تشفيرية بحيث يمكن إعادة تهيئة أو ترقية أو استبدال خوارزميات الأعداد العشوائية أو التشفير المصادَق عليه أو MAC أو التلبيد، وأطوال المفاتيح والدورات ومجموعات التشفير والأنماط، في أي وقت، وذلك للحماية من الانكسارات التشفيرية. وبالمثل، يجب أن يكون من الممكن استبدال المفاتيح وكلمات المرور وإعادة تشفير البيانات. وهذا سيتيح ترقيات سلسة إلى التشفير ما بعد الكمومي (PQC)، بمجرّد توافر تنفيذات عالية التوكيد لمخططات أو معايير PQC المعتمدة على نطاق واسع. | 2 | +| **11.2.3** | تحقق من أن جميع الأوليات التشفيرية تستخدم 128 بتًا على الأقل من الأمان بناءً على الخوارزمية وحجم المفتاح والتكوين. على سبيل المثال، يوفّر مفتاح ECC بطول 256 بتًا نحو 128 بتًا من الأمان، في حين يتطلّب RSA مفتاحًا بطول 3072 بتًا لتحقيق 128 بتًا من الأمان. | 2 | +| **11.2.4** | تحقق من أن جميع العمليات التشفيرية ثابتة الزمن، دون عمليات "قصر الدائرة" في المقارنات أو الحسابات أو القيم المُعادة، وذلك لتجنّب تسريب المعلومات. | 3 | +| **11.2.5** | تحقق من أن جميع وحدات التشفير تفشل بأمان، ومن أن الأخطاء تُعالَج بطريقة لا تُمكّن الثغرات، مثل هجمات كاهن الحشو. | 3 | + +## V11.3 خوارزميات التشفير + +تشكّل خوارزميات التشفير المصادَق عليها المبنية على AES وCHACHA20 العمود الفقري للممارسة التشفيرية الحديثة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **11.3.1** | تحقق من عدم استخدام أنماط الكتل غير الآمنة (مثل ECB) ومخططات الحشو الضعيفة (مثل PKCS#1 v1.5). | 1 | +| **11.3.2** | تحقق من عدم استخدام إلا مجموعات التشفير والأنماط المعتمدة مثل AES مع GCM. | 1 | +| **11.3.3** | تحقق من أن البيانات المشفّرة محمية من التعديل غير المصرَّح به، ويُفضَّل باستخدام طريقة تشفير مصادَق عليها معتمدة أو بالجمع بين طريقة تشفير معتمدة وخوارزمية MAC معتمدة. | 2 | +| **11.3.4** | تحقق من أن القيم العشوائية لمرة واحدة ومتجهات التهيئة وغيرها من الأعداد ذات الاستخدام الواحد لا تُستخدم لأكثر من زوج واحد من مفتاح التشفير وعنصر البيانات. ويجب أن تكون طريقة التوليد ملائمة للخوارزمية المستخدمة. | 3 | +| **11.3.5** | تحقق من أن أي تركيبة من خوارزمية تشفير وخوارزمية MAC تعمل بنمط التشفير ثم MAC. | 3 | + +## V11.4 التلبيد والدوالّ المبنية على التلبيد + +تُستخدم التلبيدات التشفيرية في مجموعة واسعة من بروتوكولات التشفير، مثل التوقيعات الرقمية وHMAC ودوالّ اشتقاق المفاتيح (KDF) وتوليد البتات العشوائية وتخزين كلمات المرور. وأمان النظام التشفيري لا يفوق قوة دوالّ التلبيد الأساسية المستخدمة. ويبيّن هذا القسم متطلبات استخدام دوالّ تلبيد آمنة في العمليات التشفيرية. + +وبالنسبة إلى تخزين كلمات المرور، وكذلك ملحق التشفير، ستوفّر [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#password-hashing-algorithms) سياقًا وإرشادات مفيدة كذلك. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **11.4.1** | تحقق من عدم استخدام إلا دوالّ التلبيد المعتمدة لحالات الاستخدام التشفيري العامة، بما فيها التوقيعات الرقمية وHMAC وKDF وتوليد البتات العشوائية. ويجب ألا تُستخدم دوالّ التلبيد الممنوعة، مثل MD5، لأي غرض تشفيري. | 1 | +| **11.4.2** | تحقق من أن كلمات المرور تُخزَّن باستخدام دالة اشتقاق مفاتيح معتمدة ومكثّفة حسابيًا (تُعرف كذلك بـ"دالة تلبيد كلمات المرور")، مع ضبط المعاملات بناءً على الإرشادات الراهنة. وينبغي أن توازن الإعدادات بين الأمان والأداء لجعل هجمات القوة الغاشمة صعبة بما يكفي لمستوى الأمان المطلوب. | 2 | +| **11.4.3** | تحقق من أن دوالّ التلبيد المستخدمة في التوقيعات الرقمية، كجزء من مصادقة البيانات أو سلامتها، مقاومة للتصادم وذات أطوال بتات ملائمة. وإذا كانت مقاومة التصادم مطلوبة، فيجب أن يكون طول المخرَج 256 بتًا على الأقل. وإذا كانت المقاومة لهجمات الصورة الأولية الثانية فقط مطلوبة، فيجب أن يكون طول المخرَج 128 بتًا على الأقل. | 2 | +| **11.4.4** | تحقق من أن التطبيق يستخدم دوالّ اشتقاق مفاتيح معتمدة مع معاملات لتمديد المفاتيح عند اشتقاق مفاتيح سرّية من كلمات المرور. ويجب أن توازن المعاملات المستخدمة بين الأمان والأداء لمنع هجمات القوة الغاشمة من اختراق المفتاح التشفيري الناتج. | 2 | + +## V11.5 القيم العشوائية + +إن توليد الأعداد شبه العشوائية الآمن تشفيريًا (CSPRNG) بالغ الصعوبة في إتقانه. وعمومًا، ستُستنفد مصادر العشوائية الجيدة في نظام ما سريعًا إذا أُفرط في استخدامها، لكن المصادر الأقل عشوائية قد تؤدي إلى مفاتيح وأسرار قابلة للتوقع. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **11.5.1** | تحقق من أن جميع الأعداد والسلاسل العشوائية المقصود أن تكون غير قابلة للتخمين يجب أن تُولَّد باستخدام مولّد أعداد شبه عشوائية آمن تشفيريًا (CSPRNG) وأن تمتلك 128 بتًا على الأقل من العشوائية. ولاحظ أن المعرّفات الفريدة عالميًا (UUIDs) لا تحقّق هذا الشرط. | 2 | +| **11.5.2** | تحقق من أن آلية توليد الأعداد العشوائية المستخدمة مصمّمة للعمل بأمان، حتى تحت الطلب الكثيف. | 3 | + +## V11.6 تشفير المفتاح العام + +سيُستخدم تشفير المفتاح العام حيث لا يكون من الممكن أو من المرغوب مشاركة مفتاح سرّي بين أطراف متعددة. + +وكجزء من ذلك، توجد حاجة إلى آليات معتمدة لتبادل المفاتيح، مثل ديفي-هيلمان وديفي-هيلمان بالمنحنيات الإهليلجية (ECDH)، لضمان بقاء النظام التشفيري آمنًا أمام التهديدات الحديثة. ويوفّر فصل "الاتصال الآمن" متطلبات TLS، ولذلك فإن المتطلبات في هذا القسم موجّهة إلى الحالات التي يُستخدم فيها تشفير المفتاح العام في حالات استخدام غير TLS. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **11.6.1** | تحقق من عدم استخدام إلا خوارزميات التشفير وأنماط التشغيل المعتمدة لتوليد المفاتيح وبذرها، ولتوليد التوقيعات الرقمية والتحقق منها. ويجب ألا تولّد خوارزميات توليد المفاتيح مفاتيح غير آمنة معرّضة لهجمات معروفة، مثل مفاتيح RSA المعرّضة لتحليل فيرما إلى عوامل. | 2 | +| **11.6.2** | تحقق من استخدام خوارزميات تشفير معتمدة لتبادل المفاتيح (مثل ديفي-هيلمان) مع التركيز على التأكد من أن آليات تبادل المفاتيح تستخدم معاملات آمنة. وهذا سيمنع الهجمات على عملية إرساء المفاتيح التي قد تؤدي إلى هجمات الخصم في المنتصف أو إلى انكسارات تشفيرية. | 3 | + +## V11.7 تشفير البيانات قيد الاستخدام + +إن حماية البيانات أثناء معالجتها أمر بالغ الأهمية. ويُوصى بتقنيات مثل التشفير الكامل للذاكرة وتشفير البيانات أثناء النقل والتأكد من تشفير البيانات في أسرع وقت ممكن بعد الاستخدام. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **11.7.1** | تحقق من استخدام التشفير الكامل للذاكرة الذي يحمي البيانات الحساسة أثناء استخدامها، بما يمنع وصول المستخدمين أو العمليات غير المصرَّح لهم. | 3 | +| **11.7.2** | تحقق من أن تدنية البيانات تضمن كشف أقل قدر من البيانات أثناء المعالجة، وتأكّد من تشفير البيانات فور استخدامها أو في أقرب وقت ممكن. | 3 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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/ar/0x21-V12-Secure-Communication.md b/5.0/ar/0x21-V12-Secure-Communication.md new file mode 100644 index 0000000000..90d1e20a2a --- /dev/null +++ b/5.0/ar/0x21-V12-Secure-Communication.md @@ -0,0 +1,57 @@ +# V12 الاتصال الآمن + +## الهدف من ضوابط الأمان + +يشتمل هذا الفصل على متطلبات متعلقة بالآليات المحدّدة التي ينبغي أن تتوافر لحماية البيانات أثناء النقل، سواء بين عميل المستخدم النهائي وخدمة في الواجهة الخلفية، أو بين الخدمات الداخلية وخدمات الواجهة الخلفية. + +وتشمل المفاهيم العامة التي يعزّزها هذا الفصل ما يلي: + +* التأكد من أن الاتصالات مشفّرة خارجيًا، ومن الأفضل داخليًا أيضًا. +* تكوين آليات التشفير باستخدام أحدث الإرشادات، بما في ذلك الخوارزميات ومجموعات التشفير المفضّلة. +* التأكد من أن الاتصالات لا تُعترض من قِبل أطراف غير مصرَّح لها، وذلك باستخدام شهادات موقّعة. + +وإضافةً إلى بيان المبادئ العامة والممارسات الفضلى، يوفّر ASVS كذلك معلومات تقنية أكثر تعمّقًا عن القوة التشفيرية في الملحق ج - معايير التشفير. + +## V12.1 إرشادات عامة لأمان TLS + +يوفّر هذا القسم إرشادات أولية عن كيفية تأمين اتصالات TLS. وينبغي استخدام أدوات محدّثة لمراجعة تكوين TLS على نحو مستمر. + +ومع أن استخدام شهادات TLS بأحرف البدل ليس غير آمن في جوهره، فإن اختراق شهادة منشورة في جميع البيئات المملوكة (مثل الإنتاج والتهيئة والتطوير والاختبار) قد يؤدي إلى اختراق الوضع الأمني للتطبيقات التي تستخدمها. وينبغي، إن أمكن، توفير حماية وإدارة سليمتين واستخدام شهادات TLS منفصلة في البيئات المختلفة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **12.1.1** | تحقق من أن الإصدارات الأحدث الموصى بها من بروتوكول TLS هي وحدها المُمكَّنة، مثل TLS 1.2 وTLS 1.3. ويجب أن يكون أحدث إصدار من بروتوكول TLS هو الخيار المفضّل. | 1 | +| **12.1.2** | تحقق من أن مجموعات التشفير الموصى بها هي وحدها المُمكَّنة، مع تعيين أقوى مجموعات التشفير كمفضّلة. ويجب ألا تدعم تطبيقات المستوى 3 سوى مجموعات التشفير التي توفّر السرّية التامة للتوجيه. | 2 | +| **12.1.3** | تحقق من أن التطبيق يتحقق من أن شهادات عميل mTLS موثوقة قبل استخدام هوية الشهادة للمصادقة أو التخويل. | 2 | +| **12.1.4** | تحقق من أن إبطال الشهادات على النحو السليم، مثل تدبيس بروتوكول حالة الشهادة عبر الإنترنت (OCSP Stapling)، مُمكَّن ومُهيّأ. | 3 | +| **12.1.5** | تحقق من أن ميزة Encrypted Client Hello (ECH) مُمكَّنة في إعدادات TLS للتطبيق لمنع كشف البيانات الوصفية الحساسة، مثل إشارة اسم الخادم (SNI)، أثناء عمليات مصافحة TLS. | 3 | + +## V12.2 اتصالات HTTPS مع الخدمات الموجّهة إلى الخارج + +تأكّد من أن جميع حِزَم HTTP المتجهة إلى الخدمات الموجّهة إلى الخارج التي يعرضها التطبيق تُرسل مشفّرة، بشهادات موثوقة عمومًا. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **12.2.1** | تحقق من استخدام TLS في جميع الاتصالات بين العميل والخدمات الموجّهة إلى الخارج القائمة على HTTP، ومن أنه لا يرتد إلى اتصالات غير آمنة أو غير مشفّرة. | 1 | +| **12.2.2** | تحقق من أن الخدمات الموجّهة إلى الخارج تستخدم شهادات TLS موثوقة عمومًا. | 1 | + +## V12.3 الأمان العام للاتصال بين الخدمات + +تتضمّن اتصالات الخادم (الداخلية والخارجية على حد سواء) أكثر من مجرّد HTTP. ويجب أن تكون الاتصالات من الأنظمة الأخرى وإليها آمنة كذلك، ومن الأفضل باستخدام TLS. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **12.3.1** | تحقق من استخدام بروتوكول مشفّر مثل TLS في جميع الاتصالات الواردة والصادرة من التطبيق وإليه، بما في ذلك أنظمة المراقبة وأدوات الإدارة والوصول عن بُعد وSSH والبرمجيات الوسيطة وقواعد البيانات والحواسيب المركزية وأنظمة الشركاء أو واجهات برمجة التطبيقات الخارجية. ويجب ألا يرتد الخادم إلى بروتوكولات غير آمنة أو غير مشفّرة. | 2 | +| **12.3.2** | تحقق من أن عملاء TLS يتحققون من الشهادات المستلمة قبل التواصل مع خادم TLS. | 2 | +| **12.3.3** | تحقق من استخدام TLS أو آلية تشفير نقل مناسبة أخرى في جميع الاتصالات بين الخدمات الداخلية القائمة على HTTP داخل التطبيق، ومن أنه لا يرتد إلى اتصالات غير آمنة أو غير مشفّرة. | 2 | +| **12.3.4** | تحقق من أن اتصالات TLS بين الخدمات الداخلية تستخدم شهادات موثوقة. وحيث تُستخدم شهادات مُولَّدة داخليًا أو موقّعة ذاتيًا، يجب تهيئة الخدمة المستهلكة لتثق فقط بسلطات إصدار شهادات داخلية محدّدة وبشهادات موقّعة ذاتيًا محدّدة. | 2 | +| **12.3.5** | تحقق من أن الخدمات التي تتواصل داخليًا في نظام ما (الاتصالات بين الخدمات) تستخدم مصادقة قوية للتأكد من التحقق من كل نقطة نهاية. ويجب استخدام طرائق مصادقة قوية، مثل مصادقة العميل في TLS، لضمان الهوية، باستخدام البنية التحتية للمفتاح العام وآليات مقاومة لهجمات إعادة الإرسال. وبالنسبة إلى معماريات الخدمات المصغّرة، ينبغي النظر في استخدام شبكة خدمات لتبسيط إدارة الشهادات وتعزيز الأمان. | 3 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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/ar/0x22-V13-Configuration.md b/5.0/ar/0x22-V13-Configuration.md new file mode 100644 index 0000000000..b00f1ecde9 --- /dev/null +++ b/5.0/ar/0x22-V13-Configuration.md @@ -0,0 +1,68 @@ +# V13 التكوين + +## الهدف من ضوابط الأمان + +يجب أن يكون التكوين الافتراضي للتطبيق آمنًا للاستخدام على الإنترنت. + +ويوفّر هذا الفصل إرشادات عن التكوينات المتنوعة اللازمة لتحقيق ذلك، بما فيها التكوينات المطبَّقة أثناء التطوير والبناء والنشر. + +وتشمل المواضيع المتناولة منع تسريب البيانات، وإدارة الاتصال بين المكوّنات بأمان، وحماية الأسرار. + +## V13.1 توثيق التكوين + +يبيّن هذا القسم متطلبات التوثيق الخاصة بكيفية اتصال التطبيق بالخدمات الداخلية والخارجية، وكذلك التقنيات اللازمة لمنع فقدان التوافر بسبب تعذّر الوصول إلى الخدمات. ويتناول كذلك التوثيق المتعلق بالأسرار. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **13.1.1** | تحقق من أن جميع احتياجات الاتصال الخاصة بالتطبيق موثّقة. ويجب أن يشمل ذلك الخدمات الخارجية التي يعتمد عليها التطبيق والحالات التي قد يتمكّن فيها المستخدم النهائي من تقديم موقع خارجي يتصل به التطبيق بعد ذلك. | 2 | +| **13.1.2** | تحقق من أن الوثائق تحدّد، لكل خدمة يستخدمها التطبيق، العدد الأقصى للاتصالات المتزامنة (مثل حدود مجمّع الاتصالات) وكيفية تصرّف التطبيق عند بلوغ ذلك الحد، بما في ذلك أي آليات احتياطية أو للاستعادة، وذلك لمنع حالات حجب الخدمة. | 3 | +| **13.1.3** | تحقق من أن وثائق التطبيق تحدّد استراتيجيات إدارة الموارد لكل نظام أو خدمة خارجية يستخدمها (مثل قواعد البيانات ومقابض الملفات والخيوط واتصالات HTTP). وينبغي أن يشمل ذلك إجراءات تحرير الموارد وإعدادات المهل ومعالجة الأعطال، وحيث يُنفَّذ منطق إعادة المحاولة، تحديد حدود إعادة المحاولة والتأخيرات وخوارزميات التراجع. وبالنسبة إلى عمليات طلب واستجابة HTTP المتزامنة، ينبغي أن تُلزم بمهل قصيرة وأن تعطّل إعادة المحاولة أو تقيّدها بصرامة لمنع التأخيرات المتتالية واستنفاد الموارد. | 3 | +| **13.1.4** | تحقق من أن وثائق التطبيق تحدّد الأسرار الحرجة لأمان التطبيق وجدولًا لتدويرها، بناءً على نموذج التهديد الخاص بالمؤسسة ومتطلبات العمل. | 3 | + +## V13.2 تكوين اتصالات الواجهة الخلفية + +تتفاعل التطبيقات مع خدمات متعددة، منها واجهات برمجة التطبيقات وقواعد البيانات أو مكوّنات أخرى. وقد تُعدّ هذه داخلية بالنسبة إلى التطبيق لكنها غير مشمولة في آليات التحكم في الوصول القياسية للتطبيق، أو قد تكون خارجية تمامًا. وفي كلتا الحالتين، من الضروري تهيئة التطبيق للتفاعل مع هذه المكوّنات بأمان، وحماية ذلك التكوين إذا لزم الأمر. + +ملاحظة: يوفّر فصل "الاتصال الآمن" إرشادات عن التشفير أثناء النقل. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **13.2.1** | تحقق من أن الاتصالات بين مكوّنات التطبيق في الواجهة الخلفية التي لا تدعم آلية جلسة المستخدم القياسية للتطبيق، بما فيها واجهات برمجة التطبيقات والبرمجيات الوسيطة وطبقات البيانات، مُصادَق عليها. ويجب أن تستخدم المصادقة حسابات خدمة فردية أو رموزًا قصيرة الأجل أو مصادقة قائمة على الشهادات، وليس بيانات اعتماد ثابتة مثل كلمات المرور أو مفاتيح واجهات برمجة التطبيقات أو الحسابات المشتركة ذات الوصول المتميّز. | 2 | +| **13.2.2** | تحقق من أن الاتصالات بين مكوّنات التطبيق في الواجهة الخلفية، بما فيها الخدمات المحلية أو خدمات نظام التشغيل وواجهات برمجة التطبيقات والبرمجيات الوسيطة وطبقات البيانات، تُنفَّذ بحسابات مُنحت أقل الصلاحيات اللازمة. | 2 | +| **13.2.3** | تحقق من أنه، إذا كان لا بد من استخدام بيانات اعتماد لمصادقة الخدمة، فإن بيانات الاعتماد التي يستخدمها المستهلك ليست بيانات اعتماد افتراضية (مثل root/root أو admin/admin). | 2 | +| **13.2.4** | تحقق من استخدام قائمة سماح لتحديد الموارد أو الأنظمة الخارجية التي يُسمح للتطبيق بالاتصال بها (مثلًا للطلبات الصادرة أو تحميل البيانات أو الوصول إلى الملفات). ويمكن تنفيذ قائمة السماح هذه في طبقة التطبيق أو خادم الويب أو الجدار الناري أو في مجموعة من الطبقات المختلفة. | 2 | +| **13.2.5** | تحقق من أن خادم الويب أو التطبيق مُهيّأ بقائمة سماح بالموارد أو الأنظمة التي يمكن للخادم إرسال طلبات إليها أو تحميل بيانات أو ملفات منها. | 2 | +| **13.2.6** | تحقق من أن التطبيق، حيث يتصل بخدمات منفصلة، يتّبع التكوين الموثّق لكل اتصال، مثل العدد الأقصى للاتصالات المتوازية والتصرّف عند بلوغ العدد الأقصى المسموح به من الاتصالات ومهل الاتصال واستراتيجيات إعادة المحاولة. | 3 | + +## V13.3 إدارة الأسرار + +إن إدارة الأسرار مهمة تكوين أساسية لضمان حماية البيانات المستخدمة في التطبيق. وتوجد المتطلبات الخاصة بالتشفير في فصل "التشفير"، لكن هذا القسم يركّز على جوانب إدارة الأسرار والتعامل معها. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **13.3.1** | تحقق من استخدام حل لإدارة الأسرار، مثل خزنة مفاتيح، لإنشاء أسرار الواجهة الخلفية وتخزينها والتحكم في الوصول إليها وتدميرها بأمان. وقد تشمل هذه كلمات المرور ومادة المفاتيح والتكاملات مع قواعد البيانات وأنظمة الأطراف الثالثة والمفاتيح والبذور الخاصة بالرموز المعتمدة على الوقت وغيرها من الأسرار الداخلية ومفاتيح واجهات برمجة التطبيقات. ويجب ألا تُدرج الأسرار في الشيفرة المصدرية للتطبيق أو في مخرجات البناء. وبالنسبة إلى تطبيق من المستوى 3، يجب أن يتضمّن ذلك حلًّا مدعومًا بالعتاد مثل وحدة أمان العتاد (HSM). | 2 | +| **13.3.2** | تحقق من أن الوصول إلى أصول الأسرار يتقيّد بمبدأ الحد الأدنى من الصلاحيات. | 2 | +| **13.3.3** | تحقق من أن جميع العمليات التشفيرية تُنفَّذ باستخدام وحدة أمان معزولة (مثل خزنة أو وحدة أمان عتادية) لإدارة مادة المفاتيح وحمايتها بأمان من التعرّض خارج وحدة الأمان. | 3 | +| **13.3.4** | تحقق من أن الأسرار مُهيّأة لانتهاء الصلاحية والتدوير بناءً على وثائق التطبيق. | 3 | + +## V13.4 تسريب المعلومات غير المقصود + +ينبغي تحصين تكوينات الإنتاج لتجنّب كشف بيانات غير ضرورية. وكثير من هذه المشكلات يُصنَّف نادرًا كمخاطر جسيمة، لكنها تُسلسَل غالبًا مع ثغرات أخرى. وإذا لم تكن هذه المشكلات موجودة افتراضيًا، فإن ذلك يرفع مستوى الصعوبة أمام مهاجمة التطبيق. + +على سبيل المثال، إخفاء إصدار مكوّنات جانب الخادم لا يلغي الحاجة إلى ترقيع جميع المكوّنات، وتعطيل سرد المجلدات لا يزيل الحاجة إلى استخدام ضوابط التخويل أو إبعاد الملفات عن المجلد العام، لكنه يرفع مستوى الصعوبة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **13.4.1** | تحقق من أن التطبيق يُنشر إما دون أي بيانات وصفية لإدارة الإصدارات، بما فيها مجلدا .git أو .svn، أو بطريقة تجعل هذين المجلدين غير قابلين للوصول خارجيًا ومن التطبيق نفسه. | 1 | +| **13.4.2** | تحقق من تعطيل أوضاع التنقيح لجميع المكوّنات في بيئات الإنتاج لمنع كشف ميزات التنقيح وتسريب المعلومات. | 2 | +| **13.4.3** | تحقق من أن خوادم الويب لا تكشف سرد الأدلة للعملاء إلا إذا كان ذلك مقصودًا صراحةً. | 2 | +| **13.4.4** | تحقق من أن استخدام طريقة HTTP TRACE غير مدعوم في بيئات الإنتاج، لتجنّب احتمال تسريب المعلومات. | 2 | +| **13.4.5** | تحقق من أن الوثائق (مثل وثائق واجهات برمجة التطبيقات الداخلية) ونقاط نهاية المراقبة غير مكشوفة إلا إذا كان ذلك مقصودًا صراحةً. | 2 | +| **13.4.6** | تحقق من أن التطبيق لا يكشف معلومات إصدار مفصّلة عن مكوّنات الواجهة الخلفية. | 3 | +| **13.4.7** | تحقق من أن طبقة الويب مُهيّأة لتقديم الملفات ذات امتدادات محدّدة فقط، وذلك لمنع التسريب غير المقصود للمعلومات والتكوين والشيفرة المصدرية. | 3 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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/ar/0x23-V14-Data-Protection.md b/5.0/ar/0x23-V14-Data-Protection.md new file mode 100644 index 0000000000..6b1b4c3dec --- /dev/null +++ b/5.0/ar/0x23-V14-Data-Protection.md @@ -0,0 +1,60 @@ +# V14 حماية البيانات + +## الهدف من ضوابط الأمان + +لا يمكن للتطبيقات أن تحسب لجميع أنماط الاستخدام وسلوكيات المستخدمين، ولذلك ينبغي لها تنفيذ ضوابط للحد من الوصول غير المصرَّح به إلى البيانات الحساسة على أجهزة العملاء. + +ويشتمل هذا الفصل على متطلبات متعلقة بتحديد البيانات التي تحتاج إلى حماية، وكيفية حمايتها، والآليات المحدّدة التي ينبغي تنفيذها أو المزالق التي ينبغي تجنّبها. + +ومن الاعتبارات الأخرى لحماية البيانات الاستخراج بالجملة أو التعديل أو الاستخدام المفرط. ومن المرجّح أن تكون متطلبات كل نظام مختلفة جدًا، ولذلك يجب أن يراعي تحديد ما هو "غير طبيعي" نموذج التهديد ومخاطر العمل. ومن منظور ASVS، يُعالَج كشف هذه المشكلات في فصل "تسجيل الأحداث الأمنية ومعالجة الأخطاء"، ويُعالَج وضع الحدود في فصل "التحقق من الصحة ومنطق العمل". + +## V14.1 توثيق حماية البيانات + +من الشروط المسبقة الرئيسية للقدرة على حماية البيانات تصنيف البيانات التي ينبغي اعتبارها حساسة. ومن المرجّح أن تكون هناك عدة مستويات مختلفة من الحساسية، وستكون الضوابط اللازمة لحماية البيانات في كل مستوى مختلفة. + +وهناك لوائح وقوانين خصوصية متنوعة تؤثّر في كيفية تعامل التطبيقات مع تخزين المعلومات الشخصية الحساسة واستخدامها ونقلها. ولم يعد هذا القسم يحاول تكرار هذه الأنواع من تشريعات حماية البيانات أو الخصوصية، بل يركّز على الاعتبارات التقنية الرئيسية لحماية البيانات الحساسة. يُرجى الرجوع إلى القوانين واللوائح المحلية، واستشارة متخصّص خصوصية مؤهّل أو محام عند الحاجة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **14.1.1** | تحقق من أن جميع البيانات الحساسة التي ينشئها التطبيق ويعالجها قد حُدّدت وصُنّفت في مستويات حماية. ويشمل ذلك البيانات المُرمَّزة فقط والتي يسهل بالتالي فك ترميزها، مثل سلاسل Base64 أو الحمولة بنص واضح داخل رمز JWT. ويلزم أن تراعي مستويات الحماية أي لوائح ومعايير لحماية البيانات والخصوصية يُطلب من التطبيق الامتثال لها. | 2 | +| **14.1.2** | تحقق من أن لجميع مستويات حماية البيانات الحساسة مجموعة موثّقة من متطلبات الحماية. ويجب أن يشمل ذلك (على سبيل المثال لا الحصر) المتطلبات المتعلقة بالتشفير العام والتحقق من السلامة والاستبقاء وكيفية تسجيل البيانات وضوابط الوصول إلى البيانات الحساسة في السجلات والتشفير على مستوى قاعدة البيانات والخصوصية والتقنيات المعزّزة للخصوصية التي ستُستخدم، وغيرها من متطلبات السرية. | 2 | + +## V14.2 الحماية العامة للبيانات + +يحتوي هذا القسم على متطلبات عملية متنوعة متعلقة بحماية البيانات. ومعظمها خاص بمسائل معيّنة مثل تسريب البيانات غير المقصود، لكن هناك كذلك متطلبًا عامًا لتنفيذ ضوابط الحماية بناءً على مستوى الحماية المطلوب لكل عنصر بيانات. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **14.2.1** | تحقق من أن البيانات الحساسة لا تُرسل إلى الخادم إلا في متن رسالة HTTP أو في حقول ترويستها، ومن أن عنوان URL وسلسلة الاستعلام لا يحتويان على معلومات حساسة، مثل مفتاح واجهة برمجة تطبيقات أو رمز جلسة. | 1 | +| **14.2.2** | تحقق من أن التطبيق يمنع تخزين البيانات الحساسة مؤقتًا في مكوّنات الخادم، مثل موازنات الحمل وذاكرات التخزين المؤقت للتطبيق، أو يضمن إزالة البيانات بأمان بعد الاستخدام. | 2 | +| **14.2.3** | تحقق من أن البيانات الحساسة المحدّدة لا تُرسل إلى أطراف غير موثوقة (مثل أدوات تتبّع المستخدمين) لمنع الجمع غير المرغوب فيه للبيانات خارج نطاق سيطرة التطبيق. | 2 | +| **14.2.4** | تحقق من أن الضوابط المتعلقة بالبيانات الحساسة بشأن التشفير والتحقق من السلامة والاستبقاء وكيفية تسجيل البيانات وضوابط الوصول إلى البيانات الحساسة في السجلات والخصوصية والتقنيات المعزّزة للخصوصية، مُنفَّذة على النحو المحدّد في الوثائق الخاصة بمستوى حماية البيانات المعنية. | 2 | +| **14.2.5** | تحقق من أن آليات التخزين المؤقت مُهيّأة لتخزين الاستجابات التي تحمل نوع المحتوى المتوقع لذلك المورد فقط ولا تحتوي على محتوى حساس أو ديناميكي. وينبغي أن يعيد خادم الويب استجابة 404 أو 302 عند الوصول إلى ملف غير موجود بدلًا من إعادة ملف آخر صالح. وهذا ينبغي أن يمنع هجمات خداع ذاكرة التخزين المؤقت للويب. | 3 | +| **14.2.6** | تحقق من أن التطبيق لا يعيد سوى الحد الأدنى المطلوب من البيانات الحساسة اللازم لوظائف التطبيق. على سبيل المثال، إعادة بعض أرقام بطاقة الائتمان فقط وليس الرقم الكامل. وإذا كانت البيانات الكاملة مطلوبة، فينبغي إخفاؤها في واجهة المستخدم إلا إذا اطّلع عليها المستخدم تحديدًا. | 3 | +| **14.2.7** | تحقق من أن المعلومات الحساسة تخضع لتصنيف استبقاء البيانات، بما يضمن حذف البيانات القديمة أو غير الضرورية تلقائيًا، وفق جدول محدّد، أو حسب ما يقتضيه الوضع. | 3 | +| **14.2.8** | تحقق من إزالة المعلومات الحساسة من البيانات الوصفية للملفات المقدَّمة من المستخدم إلا إذا وافق المستخدم على تخزينها. | 3 | + +## V14.3 حماية البيانات من جانب العميل + +يحتوي هذا القسم على متطلبات لمنع تسريب البيانات بطرائق معيّنة في جانب العميل أو وكيل المستخدم في التطبيق. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **14.3.1** | تحقق من أن البيانات المصادَق عليها تُمحى من تخزين العميل، مثل DOM في المتصفح، بعد إنهاء العميل أو الجلسة. وقد يساعد حقل ترويسة استجابة HTTP المسمّى 'Clear-Site-Data' في ذلك، لكن ينبغي أن يكون جانب العميل قادرًا كذلك على التنظيف إذا لم يكن الاتصال بالخادم متاحًا عند إنهاء الجلسة. | 1 | +| **14.3.2** | تحقق من أن التطبيق يضبط حقول ترويسة استجابة HTTP كافية لمكافحة التخزين المؤقت (أي Cache-Control: no-store) بحيث لا تُخزَّن البيانات الحساسة مؤقتًا في المتصفحات. | 2 | +| **14.3.3** | تحقق من أن البيانات المخزَّنة في تخزين المتصفح (مثل localStorage وsessionStorage وIndexedDB أو ملفات تعريف الارتباط) لا تحتوي على بيانات حساسة، باستثناء رموز الجلسة. | 2 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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/ar/0x24-V15-Secure-Coding-and-Architecture.md b/5.0/ar/0x24-V15-Secure-Coding-and-Architecture.md new file mode 100644 index 0000000000..caa0c074cd --- /dev/null +++ b/5.0/ar/0x24-V15-Secure-Coding-and-Architecture.md @@ -0,0 +1,77 @@ +# V15 البرمجة الآمنة والمعمارية + +## الهدف من ضوابط الأمان + +يتعلق كثير من متطلبات ASVS إما بمجال معيّن من الأمان، مثل المصادقة أو التخويل، أو بنوع معيّن من وظائف التطبيق، مثل تسجيل الأحداث أو التعامل مع الملفات. + +ويوفّر هذا الفصل متطلبات أمنية عامة ينبغي مراعاتها عند تصميم التطبيقات وتطويرها. ولا تركّز هذه المتطلبات على نقاء المعمارية وجودة الشيفرة فحسب، بل كذلك على ممارسات معمارية وبرمجية محدّدة لازمة لأمان التطبيقات. + +## V15.1 توثيق البرمجة الآمنة والمعمارية + +يعتمد كثير من متطلبات إرساء معمارية آمنة وقابلة للدفاع على توثيق واضح للقرارات المتّخذة بشأن تنفيذ ضوابط أمنية معيّنة والمكوّنات المستخدمة داخل التطبيق. + +ويبيّن هذا القسم متطلبات التوثيق، بما فيها تحديد المكوّنات التي تُعدّ محتوية على "وظائف خطيرة" أو تُعدّ "مكوّنات محفوفة بالمخاطر". + +وقد يكون المكوّن ذو "الوظائف الخطيرة" مكوّنًا مطوّرًا داخليًا أو من طرف ثالث ينفّذ عمليات مثل فك تسلسل بيانات غير موثوقة أو تحليل ملفات أو بيانات ثنائية خام أو تنفيذ شيفرة ديناميكية أو التلاعب المباشر بالذاكرة. وتمثّل الثغرات في هذه الأنواع من العمليات خطرًا مرتفعًا لاختراق التطبيق واحتمال كشف بنيته التحتية الأساسية. + +أما "المكوّن المحفوف بالمخاطر" فهو مكتبة من طرف ثالث (أي غير مطوّرة داخليًا) تفتقر إلى ضوابط أمنية أو تنفّذها تنفيذًا سيئًا فيما يخص عمليات تطويرها أو وظائفها. ومن الأمثلة المكوّنات التي تُصان صيانة سيئة أو غير المدعومة أو التي في مرحلة نهاية العمر أو التي لها تاريخ من الثغرات الجسيمة. + +ويؤكّد هذا القسم كذلك أهمية تحديد أُطر زمنية ملائمة لمعالجة الثغرات في مكوّنات الأطراف الثالثة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **15.1.1** | تحقق من أن وثائق التطبيق تحدّد أُطرًا زمنية للمعالجة مبنية على المخاطر لإصدارات مكوّنات الأطراف الثالثة التي تحتوي على ثغرات، ولتحديث المكتبات بشكل عام، وذلك لتقليل المخاطر الناشئة عن هذه المكوّنات. | 1 | +| **15.1.2** | تحقق من الاحتفاظ بفهرس جرد، مثل قائمة مكوّنات البرمجيات (SBOM)، لجميع مكتبات الأطراف الثالثة المستخدمة، بما في ذلك التحقق من أن المكوّنات تأتي من مستودعات محدّدة مسبقًا وموثوقة وتُصان على نحو مستمر. | 2 | +| **15.1.3** | تحقق من أن وثائق التطبيق تحدّد الوظائف المستهلِكة للوقت أو المطلوبة للموارد بكثافة. ويجب أن يشمل ذلك كيفية منع فقدان التوافر بسبب الاستخدام المفرط لهذه الوظائف وكيفية تجنّب وضع يستغرق فيه بناء الاستجابة وقتًا أطول من مهلة المستهلك. وقد تشمل الدفاعات المحتملة المعالجة غير المتزامنة واستخدام قوائم الانتظار وتحديد العمليات المتوازية لكل مستخدم ولكل تطبيق. | 2 | +| **15.1.4** | تحقق من أن وثائق التطبيق تُبرز مكتبات الأطراف الثالثة التي تُعدّ "مكوّنات محفوفة بالمخاطر". | 3 | +| **15.1.5** | تحقق من أن وثائق التطبيق تُبرز أجزاء التطبيق التي تُستخدم فيها "وظائف خطيرة". | 3 | + +## V15.2 معمارية الأمان والتبعيات + +يشتمل هذا القسم على متطلبات للتعامل مع التبعيات والمكوّنات المحفوفة بالمخاطر أو القديمة أو غير الآمنة من خلال إدارة التبعيات. + +ويشمل كذلك استخدام تقنيات على مستوى المعمارية مثل العزل في صندوق رملي والتغليف والاحتواء في حاويات وعزل الشبكة، لتقليل أثر استخدام "العمليات الخطيرة" أو "المكوّنات المحفوفة بالمخاطر" (كما هي محدّدة في القسم السابق) ولمنع فقدان التوافر بسبب الاستخدام المفرط للوظائف المطلوبة للموارد بكثافة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **15.2.1** | تحقق من أن التطبيق لا يحتوي إلا على مكوّنات لم تتجاوز الأُطر الزمنية الموثّقة للتحديث والمعالجة. | 1 | +| **15.2.2** | تحقق من أن التطبيق قد نفّذ دفاعات ضد فقدان التوافر بسبب الوظائف المستهلِكة للوقت أو المطلوبة للموارد بكثافة، بناءً على القرارات والاستراتيجيات الأمنية الموثّقة لذلك. | 2 | +| **15.2.3** | تحقق من أن بيئة الإنتاج لا تشتمل إلا على الوظائف اللازمة لعمل التطبيق، ولا تكشف وظائف زائدة مثل شيفرة الاختبار والمقتطفات النموذجية ووظائف التطوير. | 2 | +| **15.2.4** | تحقق من أن مكوّنات الأطراف الثالثة وجميع تبعياتها المتعدّية تُضمّ من المستودع المتوقع، سواء كان مملوكًا داخليًا أو مصدرًا خارجيًا، ومن عدم وجود خطر هجوم التباس التبعيات. | 3 | +| **15.2.5** | تحقق من أن التطبيق ينفّذ حماية إضافية حول أجزاء التطبيق الموثّق أنها تحتوي على "وظائف خطيرة" أو تستخدم مكتبات أطراف ثالثة تُعدّ "مكوّنات محفوفة بالمخاطر". وقد يشمل ذلك تقنيات مثل العزل في صندوق رملي أو التغليف أو الاحتواء في حاويات أو العزل على مستوى الشبكة، لتأخير المهاجمين الذين يخترقون جزءًا من التطبيق وردعهم عن الانتقال إلى أماكن أخرى فيه. | 3 | + +## V15.3 البرمجة الدفاعية + +يتناول هذا القسم أنواع الثغرات، بما فيها تلاعب الأنواع وتلويث النموذج الأولي وغيرها، الناتجة عن استخدام أنماط برمجة غير آمنة في لغة معيّنة. وقد لا يكون بعضها ذا صلة بجميع اللغات، بينما سيكون لبعضها الآخر إصلاحات خاصة باللغة أو قد يتعلق بكيفية تعامل لغة أو إطار عمل معيّن مع ميزة مثل معاملات HTTP. ويراعي كذلك خطر عدم التحقق تشفيريًا من تحديثات التطبيق. + +ويراعي كذلك المخاطر المرتبطة باستخدام الكائنات لتمثيل عناصر البيانات وقبولها وإعادتها عبر واجهات برمجة التطبيقات الخارجية. وفي هذه الحالة، يجب أن يضمن التطبيق ألا تُعدَّل حقول البيانات التي لا ينبغي أن تكون قابلة للكتابة بواسطة مدخلات المستخدم (الإسناد الجماعي) وأن تكون واجهة برمجة التطبيقات انتقائية بشأن حقول البيانات التي تُعاد. وحيث يعتمد الوصول إلى الحقول على صلاحيات المستخدم، ينبغي مراعاة ذلك في سياق متطلب التحكم في الوصول على مستوى الحقول في فصل التخويل. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **15.3.1** | تحقق من أن التطبيق لا يعيد إلا المجموعة الفرعية المطلوبة من الحقول من كائن بيانات. على سبيل المثال، ينبغي ألا يعيد كائن بيانات كاملًا، إذ لا ينبغي أن تكون بعض الحقول الفردية متاحة للمستخدمين. | 1 | +| **15.3.2** | تحقق من أن الواجهة الخلفية للتطبيق، حيث تجري استدعاءات إلى عناوين URL خارجية، مُهيّأة لعدم اتّباع عمليات إعادة التوجيه إلا إذا كانت وظيفة مقصودة. | 2 | +| **15.3.3** | تحقق من أن التطبيق يمتلك تدابير مضادة للحماية من هجمات الإسناد الجماعي عن طريق تحديد الحقول المسموح بها لكل متحكّم وإجراء، أي أنه لا يمكن إدراج قيمة حقل أو تحديثها إذا لم يكن مقصودًا أن تكون جزءًا من ذلك الإجراء. | 2 | +| **15.3.4** | تحقق من أن جميع مكوّنات الوكالة والبرمجيات الوسيطة تنقل عنوان IP الأصلي للمستخدم على نحو صحيح باستخدام حقول بيانات موثوقة لا يمكن للمستخدم النهائي التلاعب بها، ومن أن التطبيق وخادم الويب يستخدمان هذه القيمة الصحيحة لتسجيل الأحداث والقرارات الأمنية مثل تحديد المعدّل، مع مراعاة أن عنوان IP الأصلي نفسه قد لا يكون موثوقًا بسبب عناوين IP الديناميكية أو الشبكات الخاصة الافتراضية أو الجدران النارية للشركات. | 2 | +| **15.3.5** | تحقق من أن التطبيق يضمن صراحةً أن المتغيرات من النوع الصحيح وينفّذ عمليات مساواة ومقارنة صارمة. والغرض من ذلك تجنّب ثغرات تلاعب الأنواع أو التباسها الناتجة عن افتراض شيفرة التطبيق نوعًا لمتغيّر ما. | 2 | +| **15.3.6** | تحقق من أن شيفرة JavaScript مكتوبة بطريقة تمنع تلويث النموذج الأولي، وذلك مثلًا باستخدام Set() أو Map() بدلًا من الكائنات الحرفية. | 2 | +| **15.3.7** | تحقق من أن التطبيق يمتلك دفاعات ضد هجمات تلويث معاملات HTTP، وخصوصًا إذا كان إطار عمل التطبيق لا يميّز بين مصادر معاملات الطلب (سلسلة الاستعلام أو معاملات المتن أو ملفات تعريف الارتباط أو حقول الترويسة). | 2 | + +## V15.4 التزامن الآمن + +يمكن أن تؤدي مشكلات التزامن، مثل حالات التسابق وثغرات من وقت الفحص إلى وقت الاستخدام (TOCTOU) والجمود والجمود الحيوي وتجويع الخيوط والمزامنة غير السليمة، إلى سلوك غير متوقع ومخاطر أمنية. ويشتمل هذا القسم على تقنيات واستراتيجيات متنوعة للمساعدة في التخفيف من هذه المخاطر. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **15.4.1** | تحقق من أن الكائنات المشتركة في الشيفرة متعددة الخيوط (مثل ذاكرات التخزين المؤقت أو الملفات أو الكائنات في الذاكرة التي تصل إليها خيوط متعددة) يُوصل إليها بأمان باستخدام أنواع آمنة للخيوط وآليات مزامنة مثل الأقفال أو الإشارات، وذلك لتجنّب حالات التسابق وتلف البيانات. | 3 | +| **15.4.2** | تحقق من أن الفحوص على حالة مورد ما، مثل وجوده أو صلاحياته، والإجراءات التي تعتمد عليها تُنفَّذ كعملية ذرّية واحدة لمنع حالات تسابق من وقت الفحص إلى وقت الاستخدام (TOCTOU). على سبيل المثال، فحص وجود ملف قبل فتحه، أو التحقق من وصول مستخدم قبل منحه. | 3 | +| **15.4.3** | تحقق من استخدام الأقفال باتساق لتجنّب تعلّق الخيوط، سواء بانتظار بعضها بعضًا أو بإعادة المحاولة إلى ما لا نهاية، ومن أن منطق القفل يبقى داخل الشيفرة المسؤولة عن إدارة المورد لضمان عدم إمكانية تعديل الأقفال عن غير قصد أو بشكل خبيث بواسطة أصناف أو شيفرات خارجية. | 3 | +| **15.4.4** | تحقق من أن سياسات تخصيص الموارد تمنع تجويع الخيوط بضمان وصول عادل إلى الموارد، وذلك مثلًا بالاستفادة من مجمّعات الخيوط، بما يتيح للخيوط ذات الأولوية الأدنى المضي قدمًا في إطار زمني معقول. | 3 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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/ar/0x25-V16-Security-Logging-and-Error-Handling.md b/5.0/ar/0x25-V16-Security-Logging-and-Error-Handling.md new file mode 100644 index 0000000000..e50091ecc5 --- /dev/null +++ b/5.0/ar/0x25-V16-Security-Logging-and-Error-Handling.md @@ -0,0 +1,84 @@ +# V16 تسجيل الأحداث الأمنية ومعالجة الأخطاء + +## الهدف من ضوابط الأمان + +تختلف سجلات الأمان عن سجلات الأخطاء أو الأداء، وتُستخدم لتدوين الأحداث ذات الصلة بالأمان مثل قرارات المصادقة وقرارات التحكم في الوصول ومحاولات تجاوز ضوابط الأمان، مثل التحقق من صحة المدخلات أو التحقق من منطق العمل. والغرض منها دعم الكشف والاستجابة والتحقيق من خلال توفير بيانات منظّمة عالية الإشارة لأدوات التحليل مثل أنظمة SIEM. + +ولا ينبغي أن تشتمل السجلات على بيانات شخصية حساسة إلا إذا كان ذلك مطلوبًا قانونًا، ويجب حماية أي بيانات مسجَّلة كأصل عالي القيمة. ويجب ألا يمسّ تسجيل الأحداث بالخصوصية أو بأمان النظام. ويجب كذلك أن تفشل التطبيقات بأمان، متجنّبةً الكشف أو التعطيل غير الضروريين. + +وللحصول على إرشادات تنفيذ مفصّلة، راجع أوراق OWASP المرجعية في قسم المراجع. + +## V16.1 توثيق تسجيل الأحداث الأمنية + +يضمن هذا القسم وجود جرد واضح وكامل لتسجيل الأحداث على امتداد حزمة التطبيق. وهذا ضروري للمراقبة الأمنية الفعّالة والاستجابة للحوادث والامتثال. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **16.1.1** | تحقق من وجود جرد يوثّق تسجيل الأحداث المُنفَّذ في كل طبقة من حزمة تقنيات التطبيق، وما الأحداث التي تُسجَّل، وصيغ السجلات، وأين تُخزَّن، وكيف تُستخدم، وكيف يُتحكَّم في الوصول إليها، ومدة الاحتفاظ بها. | 2 | + +## V16.2 تسجيل الأحداث العام + +يوفّر هذا القسم متطلبات للتأكد من أن سجلات الأمان منظّمة باتساق وتحتوي على البيانات الوصفية المتوقعة. والهدف جعل السجلات قابلة للقراءة آليًا وللتحليل على امتداد الأنظمة والأدوات الموزّعة. + +وبطبيعة الحال، تتضمّن الأحداث الأمنية غالبًا بيانات حساسة. وإذا سُجّلت هذه البيانات دون مراعاة، تصبح السجلات نفسها مصنّفة ومن ثم خاضعة لمتطلبات التشفير وسياسات استبقاء أكثر صرامة واحتمال الكشف عنها أثناء عمليات التدقيق. + +ولذلك من الأهمية البالغة تسجيل ما هو ضروري فقط والتعامل مع بيانات السجلات بالعناية نفسها التي تُولى للأصول الحساسة الأخرى. + +وتُرسي المتطلبات أدناه متطلبات أساسية لبيانات السجلات الوصفية والمزامنة والصيغة والتحكم. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **16.2.1** | تحقق من أن كل مدخلة في السجل تشتمل على البيانات الوصفية اللازمة (مثل متى وأين ومن وماذا) التي تتيح إجراء تحقيق مفصّل في التسلسل الزمني عند وقوع حدث. | 2 | +| **16.2.2** | تحقق من أن مصادر الوقت لجميع مكوّنات تسجيل الأحداث متزامنة، ومن أن الطوابع الزمنية في البيانات الوصفية للأحداث الأمنية تستخدم التوقيت العالمي المنسّق (UTC) أو تشتمل على فرق منطقة زمنية صريح. ويُوصى باستخدام UTC لضمان الاتساق على امتداد الأنظمة الموزّعة ولمنع الالتباس أثناء التحوّلات إلى التوقيت الصيفي. | 2 | +| **16.2.3** | تحقق من أن التطبيق لا يخزّن السجلات أو يبثّها إلا إلى الملفات والخدمات الموثّقة في جرد السجلات. | 2 | +| **16.2.4** | تحقق من أن السجلات قابلة للقراءة والربط بواسطة معالج السجلات المستخدم، ويُفضَّل باستخدام صيغة تسجيل شائعة. | 2 | +| **16.2.5** | تحقق من أن التطبيق، عند تسجيل بيانات حساسة، يُنفِذ التسجيل بناءً على مستوى حماية البيانات. على سبيل المثال، قد لا يُسمح بتسجيل بيانات معيّنة، مثل بيانات الاعتماد أو تفاصيل الدفع. وقد لا تُسجَّل بيانات أخرى، مثل رموز الجلسة، إلا بعد تلبيدها أو إخفائها، كليًا أو جزئيًا. | 2 | + +## V16.3 الأحداث الأمنية + +يحدّد هذا القسم متطلبات تسجيل الأحداث ذات الصلة بالأمان داخل التطبيق. والتقاط هذه الأحداث بالغ الأهمية لكشف السلوك المشبوه ودعم التحقيقات والوفاء بالتزامات الامتثال. + +ويبيّن هذا القسم أنواع الأحداث التي ينبغي تسجيلها لكنه لا يحاول تقديم تفاصيل شاملة. فلكل تطبيق عوامل مخاطر وسياق تشغيلي فريدان. + +ولاحظ أنه مع أن ASVS يدرج تسجيل الأحداث الأمنية في نطاقه، فإن التنبيه والربط (مثل قواعد SIEM أو بنية المراقبة التحتية) يُعدّان خارج النطاق ويتولاهما نظامَا التشغيل والمراقبة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **16.3.1** | تحقق من تسجيل جميع عمليات المصادقة، بما فيها المحاولات الناجحة وغير الناجحة. وينبغي كذلك جمع بيانات وصفية إضافية، مثل نوع المصادقة أو العوامل المستخدمة. | 2 | +| **16.3.2** | تحقق من تسجيل محاولات التخويل الفاشلة. وبالنسبة إلى المستوى 3، يجب أن يشمل ذلك تسجيل جميع قرارات التخويل، بما فيها التسجيل عند الوصول إلى بيانات حساسة (دون تسجيل البيانات الحساسة نفسها). | 2 | +| **16.3.3** | تحقق من أن التطبيق يسجّل الأحداث الأمنية المحدّدة في الوثائق ويسجّل كذلك محاولات تجاوز ضوابط الأمان، مثل التحقق من صحة المدخلات ومنطق العمل ومكافحة الأتمتة. | 2 | +| **16.3.4** | تحقق من أن التطبيق يسجّل الأخطاء غير المتوقعة وأعطال ضوابط الأمان مثل أعطال TLS في الواجهة الخلفية. | 2 | + +## V16.4 حماية السجلات + +السجلات آثار جنائية قيّمة ويجب حمايتها. فإذا كان من السهل تعديل السجلات أو حذفها، فإنها تفقد سلامتها وتصبح غير موثوقة للتحقيق في الحوادث أو للإجراءات القانونية. وقد تكشف السجلات السلوك الداخلي للتطبيق أو بيانات وصفية حساسة، ما يجعلها هدفًا جاذبًا للمهاجمين. + +ويحدّد هذا القسم متطلبات للتأكد من حماية السجلات من الوصول غير المصرَّح به والتلاعب والكشف، ومن أنها تُنقل وتُخزَّن بأمان في أنظمة آمنة ومعزولة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **16.4.1** | تحقق من أن جميع مكوّنات تسجيل الأحداث تُرمّز البيانات على النحو الملائم لمنع حقن السجلات. | 2 | +| **16.4.2** | تحقق من أن السجلات محمية من الوصول غير المصرَّح به ولا يمكن تعديلها. | 2 | +| **16.4.3** | تحقق من أن السجلات تُنقل بأمان إلى نظام منفصل منطقيًا للتحليل والكشف والتنبيه والتصعيد. والهدف التأكد من أنه في حال اختراق التطبيق، لا تُختَرق السجلات. | 2 | + +## V16.5 معالجة الأخطاء + +يحدّد هذا القسم متطلبات للتأكد من أن التطبيقات تفشل بسلاسة وأمان دون كشف تفاصيل داخلية حساسة. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **16.5.1** | تحقق من إعادة رسالة عامة إلى المستهلك عند وقوع خطأ غير متوقع أو حسّاس أمنيًا، بما يضمن عدم كشف بيانات داخلية حساسة للنظام مثل تتبّعات المكدّس والاستعلامات والمفاتيح السرّية والرموز المميزة. | 2 | +| **16.5.2** | تحقق من أن التطبيق يستمر في العمل بأمان عند فشل الوصول إلى مورد خارجي، وذلك مثلًا باستخدام أنماط مثل قواطع الدائرة أو التدهور السلس. | 2 | +| **16.5.3** | تحقق من أن التطبيق يفشل بسلاسة وأمان، بما في ذلك عند وقوع استثناء، بما يمنع حالات الفشل المفتوح مثل معالجة معاملة رغم الأخطاء الناتجة عن منطق التحقق من الصحة. | 2 | +| **16.5.4** | تحقق من تعريف معالج أخطاء "كملاذ أخير" يلتقط جميع الاستثناءات غير المعالجة. والغرض من ذلك تجنّب فقدان تفاصيل الأخطاء التي يجب أن تذهب إلى ملفات السجلات، وكذلك ضمان ألا يُسقط خطأ ما عملية التطبيق بأكملها، ما يؤدي إلى فقدان التوافر. | 3 | + +ملاحظة: هناك لغات معيّنة (منها Swift وGo، وبحكم الممارسة التصميمية الشائعة، كثير من اللغات الوظيفية) لا تدعم الاستثناءات أو معالجات الأحداث كملاذ أخير. وفي هذه الحالة، ينبغي للمعماريين والمطوّرين استخدام نمط أو لغة أو طريقة ملائمة لإطار العمل لضمان قدرة التطبيقات على معالجة الأحداث الاستثنائية أو غير المتوقعة أو المتصلة بالأمان بأمان. + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* [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/ar/0x26-V17-WebRTC.md b/5.0/ar/0x26-V17-WebRTC.md new file mode 100644 index 0000000000..ad897dfb10 --- /dev/null +++ b/5.0/ar/0x26-V17-WebRTC.md @@ -0,0 +1,75 @@ +# V17 WebRTC + +## الهدف من ضوابط الأمان + +تتيح اتصالات الويب في الوقت الحقيقي (WebRTC) تبادل الصوت والفيديو والبيانات في الوقت الحقيقي في التطبيقات الحديثة. ومع تزايد التبنّي، يصبح تأمين بنية WebRTC التحتية أمرًا بالغ الأهمية. ويوفّر هذا القسم متطلبات أمنية لأصحاب المصلحة الذين يطوّرون أنظمة WebRTC أو يستضيفونها أو يدمجونها. + +ويمكن تصنيف سوق WebRTC عمومًا في ثلاثة قطاعات: + +1. مطوّرو المنتجات: المورّدون المالكون ومورّدو المصادر المفتوحة الذين ينشئون منتجات وحلول WebRTC ويوفّرونها. وتركيزهم على تطوير تقنيات WebRTC متينة وآمنة يمكن للآخرين استخدامها. + +2. منصات الاتصالات كخدمة (CPaaS): المزوّدون الذين يوفّرون واجهات برمجة التطبيقات وحِزَم تطوير البرمجيات والبنية التحتية أو المنصات اللازمة لتمكين وظائف WebRTC. وقد يستخدم مزوّدو CPaaS منتجات من الفئة الأولى أو يطوّرون برمجيات WebRTC خاصة بهم لتقديم هذه الخدمات. + +3. مزوّدو الخدمات: المؤسسات التي تستفيد من منتجات مطوّري المنتجات أو مزوّدي CPaaS، أو تطوّر حلول WebRTC خاصة بها. وهي تنشئ وتنفّذ تطبيقات للمؤتمرات عبر الإنترنت والرعاية الصحية والتعلّم الإلكتروني وغيرها من المجالات التي يكون فيها الاتصال في الوقت الحقيقي بالغ الأهمية. + +والمتطلبات الأمنية المبيّنة هنا موجّهة أساسًا إلى مطوّري المنتجات ومزوّدي CPaaS ومزوّدي الخدمات الذين: + +* يستفيدون من حلول المصادر المفتوحة لبناء تطبيقات WebRTC الخاصة بهم. +* يستخدمون منتجات WebRTC التجارية كجزء من بنيتهم التحتية. +* يستخدمون حلول WebRTC المطوّرة داخليًا أو يدمجون مكوّنات متنوعة في عرض خدمة متكامل. + +ومن المهم ملاحظة أن هذه المتطلبات الأمنية لا تنطبق على المطوّرين الذين يستخدمون حصريًا حِزَم تطوير البرمجيات وواجهات برمجة التطبيقات التي يوفّرها مورّدو CPaaS. فبالنسبة إلى هؤلاء المطوّرين، يكون مزوّدو CPaaS مسؤولين عادةً عن معظم الاعتبارات الأمنية الأساسية داخل منصاتهم، وقد لا يلبّي معيار أمني عام مثل ASVS احتياجاتهم بالكامل. + +## V17.1 خادم TURN + +يحدّد هذا القسم متطلبات أمنية للأنظمة التي تشغّل خوادم TURN (الاجتياز باستخدام المُرحِّلات حول NAT) الخاصة بها. وتساعد خوادم TURN في ترحيل الوسائط في بيئات الشبكات المقيّدة، لكنها قد تمثّل مخاطر إذا هُيّئت على نحو خاطئ. وتركّز هذه الضوابط على التصفية الآمنة للعناوين والحماية من استنفاد الموارد. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **17.1.1** | تحقق من أن خدمة الاجتياز باستخدام المُرحِّلات حول NAT (TURN) لا تسمح بالوصول إلا إلى عناوين IP غير المحجوزة لأغراض خاصة (مثل الشبكات الداخلية والبث والاسترجاع المحلي). ولاحظ أن هذا ينطبق على عناوين IPv4 وIPv6 على حد سواء. | 2 | +| **17.1.2** | تحقق من أن خدمة الاجتياز باستخدام المُرحِّلات حول NAT (TURN) غير معرّضة لاستنفاد الموارد عندما يحاول مستخدمون شرعيون فتح عدد كبير من المنافذ على خادم TURN. | 3 | + +## V17.2 الوسائط + +لا تنطبق هذه المتطلبات إلا على الأنظمة التي تستضيف خوادم وسائط WebRTC الخاصة بها، مثل وحدات التوجيه الانتقائي (SFUs) ووحدات التحكم متعددة النقاط (MCUs) وخوادم التسجيل أو خوادم البوابات. وتتعامل خوادم الوسائط مع تدفقات الوسائط وتوزّعها، ما يجعل أمانها بالغ الأهمية لحماية الاتصال بين الأنداد. وحماية تدفقات الوسائط أمر بالغ الأهمية في تطبيقات WebRTC لمنع التنصّت والتلاعب وهجمات حجب الخدمة التي قد تمسّ بخصوصية المستخدم وجودة الاتصال. + +وعلى وجه الخصوص، من الضروري تنفيذ حماية من هجمات الإغراق، مثل تحديد المعدّل والتحقق من الطوابع الزمنية واستخدام ساعات متزامنة لمطابقة الفواصل الزمنية في الوقت الحقيقي وإدارة المخازن المؤقتة لمنع الفيضان والحفاظ على التوقيت السليم. وإذا وصلت رزم جلسة وسائط معيّنة بسرعة مفرطة، فينبغي إسقاط الرزم الزائدة. ومن المهم كذلك حماية النظام من الرزم المشوّهة عن طريق تنفيذ التحقق من صحة المدخلات ومعالجة فيضان الأعداد الصحيحة بأمان ومنع فيضان المخازن المؤقتة واستخدام تقنيات أخرى متينة لمعالجة الأخطاء. + +أما الأنظمة التي تعتمد كليًا على اتصال الوسائط ندًّا لندّ بين متصفحات الويب، دون مشاركة خوادم وسائط وسيطة، فهي مستثناة من هذه المتطلبات الأمنية المحدّدة المتعلقة بالوسائط. + +ويشير هذا القسم إلى استخدام أمان طبقة النقل لرزم البيانات (DTLS) في سياق WebRTC. ويمكن العثور على متطلب متعلق بوجود سياسة موثّقة لإدارة مفاتيح التشفير في فصل "التشفير". ويمكن العثور على معلومات عن طرائق التشفير المعتمدة إما في ملحق التشفير في ASVS أو في وثائق مثل NIST SP 800-52 Rev. 2 أو BSI TR-02102-2 (الإصدار 2025-01). + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **17.2.1** | تحقق من أن مفتاح شهادة أمان طبقة النقل لرزم البيانات (DTLS) يُدار ويُحمى بناءً على السياسة الموثّقة لإدارة مفاتيح التشفير. | 2 | +| **17.2.2** | تحقق من أن خادم الوسائط مُهيّأ لاستخدام ودعم مجموعات تشفير معتمدة لأمان طبقة النقل لرزم البيانات (DTLS) وملف حماية آمن لامتداد DTLS الخاص بإنشاء مفاتيح لبروتوكول النقل الآمن في الوقت الحقيقي (DTLS-SRTP). | 2 | +| **17.2.3** | تحقق من فحص مصادقة بروتوكول النقل الآمن في الوقت الحقيقي (SRTP) في خادم الوسائط لمنع هجمات حقن بروتوكول النقل في الوقت الحقيقي (RTP) من أن تؤدي إلى حالة حجب خدمة أو إلى إدخال وسائط صوتية أو مرئية في تدفقات الوسائط. | 2 | +| **17.2.4** | تحقق من أن خادم الوسائط قادر على مواصلة معالجة حِزَم الوسائط الواردة عند مواجهة رزم مشوّهة من بروتوكول النقل الآمن في الوقت الحقيقي (SRTP). | 2 | +| **17.2.5** | تحقق من أن خادم الوسائط قادر على مواصلة معالجة حِزَم الوسائط الواردة أثناء إغراق برزم بروتوكول النقل الآمن في الوقت الحقيقي (SRTP) من مستخدمين شرعيين. | 3 | +| **17.2.6** | تحقق من أن خادم الوسائط غير معرّض لثغرة حالة التسابق في "ClientHello" في أمان طبقة النقل لرزم البيانات (DTLS)، وذلك بفحص ما إذا كان خادم الوسائط معروفًا علنًا بأنه معرّض لها أو بإجراء اختبار حالة التسابق. | 3 | +| **17.2.7** | تحقق من أن أي آليات لتسجيل الصوت أو الفيديو مرتبطة بخادم الوسائط قادرة على مواصلة معالجة حِزَم الوسائط الواردة أثناء إغراق برزم بروتوكول النقل الآمن في الوقت الحقيقي (SRTP) من مستخدمين شرعيين. | 3 | +| **17.2.8** | تحقق من فحص شهادة أمان طبقة النقل لرزم البيانات (DTLS) مقابل سمة البصمة في بروتوكول وصف الجلسة (SDP)، وإنهاء تدفق الوسائط في حال فشل الفحص، وذلك لضمان أصالة تدفق الوسائط. | 3 | + +## V17.3 الإشارات + +يحدّد هذا القسم متطلبات للأنظمة التي تشغّل خوادم الإشارات الخاصة بها في WebRTC. وتنسّق الإشارات الاتصال ندًّا لندّ ويجب أن تكون صامدة أمام الهجمات التي قد تعطّل إنشاء الجلسة أو التحكم فيها. + +ولضمان إشارات آمنة، يجب أن تتعامل الأنظمة مع المدخلات المشوّهة بسلاسة وأن تبقى متاحة تحت الحمل. + +| # | الوصف | المستوى | +| :---: | :--- | :---: | +| **17.3.1** | تحقق من أن خادم الإشارات قادر على مواصلة معالجة رسائل الإشارات الواردة الشرعية أثناء هجوم إغراق. وينبغي تحقيق ذلك بتنفيذ تحديد للمعدّل على مستوى الإشارات. | 2 | +| **17.3.2** | تحقق من أن خادم الإشارات قادر على مواصلة معالجة رسائل الإشارات الشرعية عند مواجهة رسالة إشارات مشوّهة قد تسبّب حالة حجب خدمة. وقد يشمل ذلك تنفيذ التحقق من صحة المدخلات ومعالجة فيضان الأعداد الصحيحة بأمان ومنع فيضان المخازن المؤقتة واستخدام تقنيات أخرى متينة لمعالجة الأخطاء. | 2 | + +## المراجع + +لمزيد من المعلومات، انظر أيضًا: + +* أفضل توثيق لهجوم حجب الخدمة عبر ClientHello في DTLS الخاص بـ WebRTC موجود في [Enable Security's blog post aimed at security professionals](https://www.enablesecurity.com/blog/novel-dos-vulnerability-affecting-webrtc-media-servers/) وفي [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/ar/0x90-Appendix-A_Glossary.md b/5.0/ar/0x90-Appendix-A_Glossary.md new file mode 100644 index 0000000000..099421646d --- /dev/null +++ b/5.0/ar/0x90-Appendix-A_Glossary.md @@ -0,0 +1,89 @@ +# الملحق أ: قائمة المصطلحات + +* **Absolute Maximum Session Lifetime** (العمر الأقصى المطلق للجلسة) – يُشار إليه أيضًا باسم "Overall Timeout" في NIST، وهو أقصى مدة زمنية يمكن أن تبقى فيها الجلسة نشطة بعد المصادقة بغض النظر عن تفاعل المستخدم. وهو أحد مكوّنات انتهاء صلاحية الجلسة. +* **Allowlist** (قائمة السماح) – قائمة بالبيانات أو العمليات المسموح بها، على سبيل المثال قائمة بالمحارف المسموح بها لإجراء التحقق من صحة المدخلات. +* **Anti-forgery token** (رمز الحماية من التزوير) – آلية يتم فيها تمرير رمز مميز واحد أو أكثر في الطلب ويتحقق منها خادم التطبيق للتأكد من أن الطلب قد ورد من نقطة نهاية متوقعة. +* **Application Security** (أمان التطبيق) – يركّز الأمان على مستوى التطبيق على تحليل المكوّنات التي تشكّل طبقة التطبيق في النموذج المرجعي لربط الأنظمة المفتوحة (OSI Model)، بدلًا من التركيز على نظام التشغيل الأساسي أو الشبكات المتصلة مثلًا. +* **Application Security Verification** (التحقق من أمان التطبيق) – التقييم الفني لتطبيق ما مقابل معيار OWASP ASVS. +* **Application Security Verification Report** (تقرير التحقق من أمان التطبيق) – تقرير يوثّق النتائج الإجمالية والتحليل الداعم الذي ينتجه المدقّق لتطبيق معيّن. +* **Authentication** (المصادقة) – التحقق من الهوية المُدّعاة لمستخدم التطبيق. +* **Automated Verification** (التحقق المؤتمت) – استخدام أدوات مؤتمتة (إما أدوات التحليل الديناميكي أو أدوات التحليل الساكن أو كلتيهما) تستخدم تواقيع الثغرات للعثور على المشكلات. +* **Black box testing** (اختبار الصندوق الأسود) – طريقة لاختبار البرمجيات تفحص وظائف التطبيق دون النظر في هياكله أو آليات عمله الداخلية. +* **Common Weakness Enumeration** (CWE، تعداد نقاط الضعف الشائعة) – قائمة مطوّرة من قِبل المجتمع لنقاط ضعف أمان البرمجيات الشائعة. وهي بمثابة لغة مشتركة، ومقياس لأدوات أمان البرمجيات، وخط أساس لجهود تحديد نقاط الضعف والتخفيف منها والوقاية منها. +* **Component** (المكوّن) – وحدة برمجية قائمة بذاتها، مع ما يرتبط بها من واجهات القرص والشبكة، تتواصل مع المكوّنات الأخرى. +* **Credential Service Provider** (CSP، مزوّد خدمة بيانات الاعتماد) – يُسمّى أيضًا مزوّد الهوية (IdP). مصدر لبيانات المستخدمين يمكن أن تستخدمه تطبيقات أخرى كمصدر للمصادقة. +* **Cross-Site Script Inclusion** (XSSI، تضمين النصوص البرمجية عبر المواقع) - نوع من هجمات البرمجة النصية عبر المواقع (XSS) يجلب فيه تطبيق الويب شيفرة ضارة من مورد خارجي ويضمّنها كجزء من محتواه. +* **Cross-Site Scripting** (XSS، البرمجة النصية عبر المواقع) – ثغرة أمنية توجد عادةً في تطبيقات الويب وتسمح بحقن نصوص برمجية تُنفّذ من جانب العميل في المحتوى. +* **Cryptographic module** (وحدة التشفير) – العتاد أو البرمجيات أو البرمجيات الثابتة التي تنفّذ خوارزميات التشفير أو تُنشئ مفاتيح التشفير. +* **Cryptographically secure pseudo-random number generator** (CSPRNG، مولّد أعداد شبه عشوائية آمن تشفيريًا) - مولّد أعداد شبه عشوائية يتمتع بخصائص تجعله مناسبًا للاستخدام في التشفير، ويُشار إليه أيضًا باسم مولّد الأعداد العشوائية التشفيري (CRNG). +* **Datagram Transport Layer Security** (DTLS، أمان طبقة النقل لرزم البيانات) – بروتوكول تشفيري يوفّر أمان الاتصال عبر اتصال شبكي. يستند إلى بروتوكول TLS لكنه مكيّف لحماية البروتوكولات الموجّهة للرزم (عادةً عبر UDP). معرّف في RFC 9147 لإصدار DTLS 1.3. +* **Datagram Transport Layer Security Extension to Establish Keys for the Secure Real-time Transport Protocol** (DTLS-SRTP) – آلية لاستخدام مصافحة DTLS لإنشاء مادة المفاتيح لجلسة SRTP. معرّفة في RFC 5764. +* **Design Verification** (التحقق من التصميم) – التقييم الفني لمعمارية أمان التطبيق. +* **Dynamic Application Security Testing** (DAST، الاختبار الديناميكي لأمان التطبيقات) – تقنيات مصمّمة لكشف الظروف التي تدل على وجود ثغرة أمنية في التطبيق أثناء تشغيله. +* **Dynamic Verification** (التحقق الديناميكي) – استخدام أدوات مؤتمتة تستخدم تواقيع الثغرات للعثور على المشكلات أثناء تنفيذ التطبيق. +* **Fast IDentity Online** (FIDO، الهوية السريعة عبر الإنترنت) – مجموعة من معايير المصادقة تتيح استخدام طرائق مصادقة متنوعة، منها القياسات الحيوية ووحدات النظام الأساسي الموثوق (TPMs) ورموز أمان USB وغيرها. +* **Hardware Security Module** (HSM، وحدة أمان العتاد) – مكوّن عتادي يخزّن مفاتيح التشفير وغيرها من الأسرار بطريقة محمية. +* **Hibernate Query Language** (HQL) – لغة استعلام تشبه في شكلها لغة SQL وتستخدمها مكتبة Hibernate ORM. +* **HTTP Strict Transport Security** (HSTS) – سياسة توجّه المتصفح إلى الاتصال بالنطاق الذي يعيد الترويسة عبر TLS فقط وعند تقديم شهادة صالحة. وتُنشَّط باستخدام حقل ترويسة الاستجابة Strict-Transport-Security. +* **HyperText Transfer Protocol** (HTTP، بروتوكول نقل النص التشعبي) – بروتوكول تطبيقي لأنظمة المعلومات التشعبية الموزّعة والتعاونية. وهو أساس تبادل البيانات في شبكة الويب العالمية. +* **HyperText Transfer Protocol over SSL/TLS** (HTTPS) – طريقة لتأمين اتصالات HTTP عن طريق تشفيرها باستخدام أمان طبقة النقل (TLS). +* **Identity Provider** (IdP، مزوّد الهوية) – يُسمّى أيضًا مزوّد خدمة بيانات الاعتماد (CSP) في مراجع NIST. كيان يوفّر مصدرًا للمصادقة لتطبيقات أخرى. +* **Inactivity Timeout** (مهلة عدم النشاط) – المدة الزمنية التي يمكن أن تبقى فيها الجلسة نشطة في غياب تفاعل المستخدم مع التطبيق. وهو أحد مكوّنات انتهاء صلاحية الجلسة. +* **Input Validation** (التحقق من صحة المدخلات) – توحيد مدخلات المستخدم غير الموثوقة إلى صورتها القياسية والتحقق من صحتها. +* **JSON Web Token** (JWT) – يحدّد RFC 7519 معيارًا لكائن بيانات JSON يتكوّن من قسم ترويسة يوضّح كيفية التحقق من الكائن، وقسم متن يحتوي على مجموعة من المطالبات، وقسم توقيع يحتوي على توقيع رقمي يمكن استخدامه للتحقق من محتويات قسم المتن. وهو نوع من الرموز المميزة المكتفية بذاتها. +* **Local File Inclusion** (LFI، تضمين الملفات المحلية) - هجوم يستغل إجراءات تضمين الملفات المعرّضة للخطر في التطبيق، ما يؤدي إلى تضمين ملفات محلية موجودة بالفعل على الخادم. +* **Malicious Code** (الشيفرة الضارة) – شيفرة تُدخل في التطبيق أثناء تطويره دون علم مالك التطبيق، وتتحايل على سياسة الأمان المقصودة للتطبيق. وهي ليست كالبرمجيات الخبيثة مثل الفيروس أو الدودة! +* **Malware** (البرمجيات الخبيثة) – شيفرة قابلة للتنفيذ تُدخل في التطبيق أثناء وقت التشغيل دون علم مستخدم التطبيق أو مسؤوله. +* **Message authentication code** (MAC، رمز مصادقة الرسالة) - مجموع تحقق تشفيري على البيانات، يُحسب بواسطة خوارزمية توليد MAC، ويُستخدم لتوفير ضمان لسلامة البيانات وأصالتها. +* **Multi-factor authentication** (MFA، المصادقة متعددة العوامل) – مصادقة تتضمّن عاملين أو أكثر من العوامل الفردية. +* **Mutual TLS** (mTLS، أمان طبقة النقل المتبادل) – انظر TLS client authentication. +* **Object-relational Mapping** (ORM، التعيين الكياني العلائقي) – نظام يُستخدم للسماح بالإشارة إلى قاعدة بيانات علائقية أو جدولية والاستعلام عنها داخل برنامج تطبيقي باستخدام نموذج كائني متوافق مع التطبيق. +* **One-time Password** (OTP، كلمة المرور لمرة واحدة) – كلمة مرور تُولَّد بشكل فريد لاستخدامها في مناسبة واحدة. +* **Open Worldwide Application Security Project** (OWASP، المشروع العالمي المفتوح لأمان التطبيقات) – المشروع العالمي المفتوح لأمان التطبيقات (OWASP) هو مجتمع عالمي حر ومفتوح يركّز على تحسين أمان برمجيات التطبيقات. ومهمتنا هي جعل أمان التطبيقات "مرئيًا"، بحيث يستطيع الأفراد والمؤسسات اتخاذ قرارات مستنيرة بشأن مخاطر أمان التطبيقات. انظر: [https://www.owasp.org/](https://www.owasp.org/). +* **Password-Based Key Derivation Function 2** (PBKDF2، دالة اشتقاق المفاتيح المعتمدة على كلمة المرور 2) – خوارزمية خاصة أحادية الاتجاه تُستخدم لإنشاء مفتاح تشفيري قوي من نص مُدخل (مثل كلمة مرور) وقيمة ملح عشوائية إضافية، ويمكن استخدامها بالتالي لزيادة صعوبة كسر كلمة المرور دون اتصال إذا خُزّنت القيمة الناتجة بدلًا من كلمة المرور الأصلية. +* **Public Key Infrastructure** (PKI، البنية التحتية للمفتاح العام) – ترتيب يربط المفاتيح العامة بهويات الكيانات المقابلة لها. ويُنشأ هذا الربط من خلال عملية تسجيل وإصدار للشهادات لدى سلطة إصدار الشهادات (CA) وبواسطتها. +* **Public Switched Telephone Network** (PSTN، شبكة الهاتف العمومية المبدّلة) – شبكة الهاتف التقليدية التي تشمل كلًّا من هواتف الخطوط الثابتة والهواتف المحمولة. +* **Real-time Transport Protocol** (RTP) و**Real-time Transport Control Protocol** (RTCP) – بروتوكولان يُستخدمان معًا لنقل تدفقات الوسائط المتعددة. تستخدمهما حزمة WebRTC. معرّفان في RFC 3550. +* **Reference Token** (الرمز المميز المرجعي) – نوع من الرموز المميزة يعمل كمؤشّر أو معرّف لحالة أو بيانات وصفية مخزّنة على الخادم، ويُشار إليه أحيانًا بالرموز العشوائية أو الرموز المعتمة. وبخلاف الرموز المكتفية بذاتها، التي تضمّن بعض بياناتها ذات الصلة داخل الرمز نفسه، لا تحتوي الرموز المرجعية على أي معلومات ذاتية، بل تعتمد على الخادم للحصول على السياق. ويكون الرمز المرجعي معرّف جلسة أو يحتوي عليه. +* **Relying Party** (RP، الطرف المعوِّل) – عمومًا تطبيق يعوّل على مستخدم قد صادق لدى مزوّد مصادقة منفصل. ويعتمد التطبيق على نوع من الرموز المميزة أو مجموعة من التأكيدات الموقّعة التي يوفّرها مزوّد المصادقة ليثق بأن المستخدم هو من يدّعي أنه هو. +* **Remote File Inclusion** (RFI، تضمين الملفات البعيدة) - هجوم يستغل إجراءات التضمين المعرّضة للخطر في التطبيق، ما ينتج عنه تضمين ملفات بعيدة. +* **Scalable Vector Graphics** (SVG، الرسوميات المتجهية القابلة للتحجيم) – لغة توصيف قائمة على XML لوصف الرسوميات المتجهية ثنائية الأبعاد. +* **Secure Real-time Transport Protocol** (SRTP) و**Secure Real-time Transport Control Protocol** (SRTCP) – ملف تعريفي لبروتوكولي RTP وRTCP يوفّر دعمًا لتشفير الرسائل والمصادقة وحماية السلامة. معرّف في RFC 3711. +* **Security Architecture** (معمارية الأمان) – تجريد لتصميم التطبيق يحدّد ويصف موضع ضوابط الأمان وكيفية استخدامها، ويحدّد ويصف كذلك موضع بيانات المستخدم والتطبيق وحساسيتها. +* **Security Assertion Markup Language** (SAML) – معيار مفتوح لمصادقة الدخول الموحّد يستند إلى تمرير تأكيدات موقّعة (كائنات XML عادةً) بين مزوّد الهوية والطرف المعوِّل. +* **Security Configuration** (تكوين الأمان) – تكوين وقت التشغيل للتطبيق الذي يؤثّر في كيفية استخدام ضوابط الأمان. +* **Security Control** (ضابط الأمان) – دالة أو مكوّن يجري فحصًا أمنيًا (مثل فحص التخويل) أو يؤدي عند استدعائه إلى أثر أمني (مثل توليد سجل تدقيق). +* **Security information and event management** (SIEM، إدارة معلومات الأمان والأحداث) - نظام لكشف التهديدات والامتثال وإدارة حوادث الأمان من خلال جمع وتحليل البيانات المتعلقة بالأمان من مصادر مختلفة داخل البنية التحتية لتقنية المعلومات في المؤسسة. +* **Self-Contained Token** (الرمز المميز المكتفي بذاته) – رمز مميز يضمّن سمة واحدة أو أكثر لا تعتمد على حالة مخزّنة في الخادم أو على تخزين خارجي آخر. وتضمن هذه الرموز أصالة سماتها المضمّنة وسلامتها، ما يتيح تبادلًا آمنًا و"عديم الحالة" للمعلومات بين الأنظمة. وتُؤمَّن الرموز المكتفية بذاتها عمومًا باستخدام تقنيات تشفيرية، مثل التوقيعات الرقمية أو رموز مصادقة الرسائل (MACs)، لضمان أصالة بياناتها وسلامتها، وفي بعض الحالات سريتها. ومن الأمثلة الشائعة تأكيدات SAML وJWTs. +* **Server-side Request Forgery** (SSRF، تزوير الطلب من جانب الخادم) – هجوم يسيء استخدام وظيفة على الخادم لقراءة موارد داخلية أو تحديثها. يقدّم المهاجم عنوان URL أو يعدّله، لتقرأه الشيفرة العاملة على الخادم أو ترسل إليه بيانات. +* **Session Description Protocol** (SDP، بروتوكول وصف الجلسة) – صيغة رسائل لإعداد جلسة وسائط متعددة (تُستخدم في WebRTC مثلًا). معرّف في RFC 4566. +* **Session Identifier** أو **Session ID** (معرّف الجلسة) – مفتاح يعرّف جلسة ذات حالة مخزّنة في الواجهة الخلفية. ويُنقل إلى العميل ومنه إما كـ"رمز مرجعي" أو داخله. +* **Session Token** (الرمز المميز للجلسة) – عبارة جامعة تُستخدم في هذا المعيار للإشارة إلى الرمز المميز أو القيمة المستخدمة في آليات الجلسات عديمة الحالة (التي تستخدم رمزًا مكتفيًا بذاته) أو آليات الجلسات ذات الحالة (التي تستخدم رمزًا مرجعيًا). +* **Session Traversal Utilities for NAT** (STUN) – بروتوكول يُستخدم للمساعدة في اجتياز NAT من أجل إنشاء اتصالات ندٍّ لندّ. معرّف في RFC 3489. +* **Single-factor authenticator** (مُصادِق أحادي العامل) – آلية للتحقق من أن المستخدم مُصادَق عليه. وينبغي أن تكون إما شيئًا تعرفه (أسرار محفوظة، كلمات مرور، عبارات مرور، أرقام تعريف شخصية)، أو شيئًا أنت عليه (القياسات الحيوية، بصمة الإصبع، مسح الوجه)، أو شيئًا تملكه (رموز OTP، جهاز تشفيري مثل البطاقة الذكية). +* **Single Sign-on Authentication** (SSO، مصادقة الدخول الموحّد) – يحدث هذا عندما يدخل المستخدم إلى تطبيق واحد فيُسجَّل دخوله تلقائيًا إلى تطبيقات أخرى دون الحاجة إلى إعادة المصادقة. على سبيل المثال، عند الدخول إلى Google، يُسجَّل دخول المستخدم تلقائيًا إلى خدمات Google الأخرى مثل YouTube وGoogle Docs وGmail. +* **Software bill of materials** (SBOM، قائمة مكوّنات البرمجيات) - قائمة منظّمة وشاملة بجميع المكوّنات والوحدات والمكتبات وأُطر العمل وغيرها من الموارد اللازمة لبناء تطبيق برمجي أو تجميعه. +* **Software Composition Analysis** (SCA، تحليل تركيب البرمجيات) – مجموعة من التقنيات المصمّمة لتحليل تركيب التطبيق وتبعياته ومكتباته وحُزَمه بحثًا عن ثغرات أمنية في إصدارات مكوّنات معيّنة قيد الاستخدام. ولا ينبغي الخلط بينه وبين تحليل الشيفرة المصدرية الذي يُشار إليه الآن عادةً باسم SAST. +* **Software development lifecycle** (SDLC، دورة حياة تطوير البرمجيات) – العملية التدريجية التي يُطوَّر بها البرنامج من المتطلبات الأولية إلى النشر والصيانة. +* **SQL Injection** (SQLi، حقن SQL) – تقنية حقن شيفرة تُستخدم لمهاجمة التطبيقات المعتمدة على البيانات، حيث تُدرج عبارات SQL ضارة في نقطة إدخال. +* **Stateful Session Mechanism** (آلية الجلسة ذات الحالة) – في آلية الجلسة ذات الحالة، يحتفظ التطبيق بحالة الجلسة في الواجهة الخلفية، وهي تقابل عادةً رمزًا مميزًا للجلسة يُولَّد باستخدام مولّد أعداد شبه عشوائية آمن تشفيريًا (CSPRNG)، ويُصدر للمستخدم النهائي. +* **Stateless Session Mechanism** (آلية الجلسة عديمة الحالة) – تستخدم آلية الجلسة عديمة الحالة رمزًا مميزًا مكتفيًا بذاته يُمرَّر إلى العملاء، ويحتوي على معلومات الجلسة التي لا تُخزَّن بالضرورة داخل الخدمة التي تستقبل الرمز وتتحقق منه. وفي الواقع، ستحتاج الخدمة إلى الوصول إلى بعض معلومات الجلسة (مثل قائمة إبطال JWT) لتكون قادرة على إنفاذ ضوابط الأمان المطلوبة. +* **Static application security testing** (SAST، الاختبار الساكن لأمان التطبيقات) – مجموعة من التقنيات المصمّمة لتحليل الشيفرة المصدرية للتطبيق ورمزه البايتي وملفاته الثنائية بحثًا عن ظروف في الكتابة والتصميم تدل على وجود ثغرات أمنية. وتحلّل حلول SAST التطبيق من "الداخل إلى الخارج" وهو في حالة عدم تشغيل. +* **Threat Modeling** (نمذجة التهديدات) – تقنية تتمثّل في تطوير معماريات أمنية متزايدة الدقة لتحديد عناصر التهديد ومناطق الأمان وضوابط الأمان والأصول التقنية والتجارية المهمة. +* **Time-of-check to time-of-use** (TOCTOU، من وقت الفحص إلى وقت الاستخدام) – حالة يفحص فيها التطبيق حالة مورد قبل استخدامه، لكن حالة المورد يمكن أن تتغيّر بين الفحص والاستخدام. وقد يُبطل ذلك نتائج الفحص ويؤدي إلى وضع ينفّذ فيه التطبيق إجراءات غير صحيحة بسبب عدم تطابق الحالة. +* **Time based One-time Passwords** (TOTPs، كلمات المرور لمرة واحدة المعتمدة على الوقت) - طريقة لتوليد كلمة مرور لمرة واحدة يكون فيها الوقت الحالي جزءًا من الخوارزمية المستخدمة لتوليد كلمة المرور. +* **TLS client authentication** (مصادقة العميل في TLS)، ويُسمّى أيضًا **Mutual TLS** (mTLS) – في اتصال TLS القياسي، يمكن للعميل استخدام الشهادة التي يوفّرها الخادم للتحقق من هوية الخادم. وعند استخدام مصادقة العميل في TLS، يستخدم العميل أيضًا مفتاحه الخاص وشهادته للسماح للخادم بالتحقق من هوية العميل كذلك. +* **Transport Layer Security** (TLS، أمان طبقة النقل) – بروتوكولات تشفيرية توفّر أمان الاتصال عبر اتصال شبكي. +* **Traversal Using Relays around NAT** (TURN) – امتداد لبروتوكول STUN يستخدم خادم TURN كمُرحِّل عندما لا يمكن إنشاء اتصالات ندٍّ لندّ مباشرة. معرّف في RFC 8656. +* **Trusted execution environment** (TEE، بيئة التنفيذ الموثوقة) - بيئة معالجة معزولة يمكن فيها تنفيذ التطبيقات بأمان بصرف النظر عن بقية النظام. +* **Trusted Platform Module** (TPM، وحدة النظام الأساسي الموثوق) – نوع من وحدات أمان العتاد (HSM) يكون عادةً مرفقًا بمكوّن عتادي أكبر مثل اللوحة الأم، ويعمل كـ"جذر الثقة" لذلك النظام. +* **Trusted Service Layer** (طبقة الخدمة الموثوقة) – أي نقطة إنفاذ موثوقة للضوابط، مثل خدمة مصغّرة، أو واجهة برمجة تطبيقات بلا خادم، أو جانب الخادم، أو واجهة برمجة تطبيقات موثوقة على جهاز عميل يمتلك إقلاعًا آمنًا، أو واجهات برمجة تطبيقات لشركاء أو خارجية، وما إلى ذلك. والموثوقية تعني عدم وجود قلق من أن يتمكّن مستخدم غير موثوق من تجاوز الطبقة أو الضوابط المنفَّذة فيها أو تخطّيها. +* **Uniform Resource Identifier** (URI، معرّف الموارد الموحّد)- سلسلة محارف فريدة تعرّف موردًا، مثل صفحة ويب أو عنوان بريد أو أماكن. +* **Uniform Resource Locator** (URL، محدّد موقع الموارد الموحّد) – سلسلة تحدّد موقع مورد على الإنترنت. +* **Universally Unique Identifier** (UUID، المعرّف الفريد عالميًا) – رقم مرجعي فريد يُستخدم كمعرّف في البرمجيات. +* **Verifier** (المدقّق) – الشخص أو الفريق الذي يراجع تطبيقًا مقابل متطلبات OWASP ASVS. +* **Web Real-Time Communication** (WebRTC، اتصالات الويب في الوقت الحقيقي) – حزمة بروتوكولات وواجهة برمجة تطبيقات ويب مرتبطة بها تُستخدم لنقل تدفقات الوسائط المتعددة في تطبيقات الويب، عادةً في سياق المؤتمرات المرئية. تستند إلى SRTP وSRTCP وDTLS وSDP وSTUN/TURN. +* **WebSocket over TLS** (WSS) – ممارسة تأمين اتصالات WebSocket عن طريق تشغيل WebSocket فوق بروتوكول TLS. +* **What You See Is What You Get** (WYSIWYG، ما تراه هو ما تحصل عليه) – نوع من محرّرات المحتوى الغني يُظهر كيف سيبدو المحتوى فعليًا عند عرضه بدلًا من إظهار الشيفرة المستخدمة للتحكّم في العرض. +* **X.509 Certificate** (شهادة X.509) – شهادة X.509 هي شهادة رقمية تستخدم معيار البنية التحتية للمفتاح العام (PKI) الدولي X.509 المعتمد على نطاق واسع للتحقق من أن مفتاحًا عامًا ينتمي إلى هوية المستخدم أو الحاسوب أو الخدمة الواردة في الشهادة. +* **XML eXternal Entity** (XXE، كيان XML الخارجي) – نوع من كيانات XML يمكنه الوصول إلى محتوى محلي أو بعيد عبر معرّف نظام معلن. وقد يؤدي ذلك إلى هجمات حقن مختلفة. diff --git a/5.0/ar/0x91-Appendix-B_References.md b/5.0/ar/0x91-Appendix-B_References.md new file mode 100644 index 0000000000..cddb7a4597 --- /dev/null +++ b/5.0/ar/0x91-Appendix-B_References.md @@ -0,0 +1,43 @@ +# الملحق ب: المراجع + +من المرجّح أن تكون مشاريع OWASP التالية مفيدة لمستخدمي هذا المعيار ومتبنّيه: + +## مشاريع OWASP الأساسية + +1. OWASP Top 10 Project: [https://owasp.org/www-project-top-ten/](https://owasp.org/www-project-top-ten/) +2. OWASP Web Security Testing Guide: [https://owasp.org/www-project-web-security-testing-guide/](https://owasp.org/www-project-web-security-testing-guide/) +3. OWASP Proactive Controls: [https://owasp.org/www-project-proactive-controls/](https://owasp.org/www-project-proactive-controls/) +4. OWASP Software Assurance Maturity Model (SAMM): [https://owasp.org/www-project-samm/](https://owasp.org/www-project-samm/) +5. OWASP Secure Headers Project: [https://owasp.org/www-project-secure-headers/](https://owasp.org/www-project-secure-headers/) + +## مشروع OWASP Cheat Sheet Series + +[هذا المشروع](https://owasp.org/www-project-cheat-sheets/) يضم عدة أوراق مرجعية ذات صلة بمواضيع مختلفة في ASVS. + +وهناك تخطيط إلى ASVS يمكن الاطلاع عليه هنا: [https://cheatsheetseries.owasp.org/IndexASVS.html](https://cheatsheetseries.owasp.org/IndexASVS.html) + +## المشاريع المتعلقة بأمان الأجهزة المحمولة + +1. OWASP Mobile Security Project: [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) +2. OWASP Mobile Top 10 Risks: [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) +3. OWASP Mobile Security Testing Guide and Mobile Application Security Verification Standard: [https://owasp.org/www-project-mobile-security-testing-guide/](https://owasp.org/www-project-mobile-security-testing-guide/) + +## مشاريع OWASP المتعلقة بإنترنت الأشياء + +1. OWASP Internet of Things Project: [https://owasp.org/www-project-internet-of-things/](https://owasp.org/www-project-internet-of-things/) + +## مشاريع OWASP الخاصة بالحوسبة بلا خادم + +1. OWASP Serverless Project: [https://owasp.org/www-project-serverless-top-10/](https://owasp.org/www-project-serverless-top-10/) + +## أخرى + +وبالمثل، من المرجّح أن تكون المواقع التالية مفيدة لمستخدمي هذا المعيار ومتبنّيه + +1. SecLists Github: [https://github.com/danielmiessler/SecLists](https://github.com/danielmiessler/SecLists) +2. MITRE Common Weakness Enumeration: [https://cwe.mitre.org/](https://cwe.mitre.org/) +3. PCI Security Standards Council: [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/) +4. PCI Data Security Standard (DSS) v3.2.1 Requirements and Security Assessment Procedures: [https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf) +5. PCI Software Security Framework - Secure Software Requirements and Assessment Procedures: [https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf](https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf) +6. PCI Secure Software Lifecycle (Secure SLC) Requirements and Assessment Procedures: [https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf](https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf) +7. OWASP ASVS 4.0 Testing Guide [https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide](https://github.com/BlazingWind/OWASP-ASVS-4.0-testing-guide) diff --git a/5.0/ar/0x92-Appendix-C_Cryptography.md b/5.0/ar/0x92-Appendix-C_Cryptography.md new file mode 100644 index 0000000000..93f5cebec4 --- /dev/null +++ b/5.0/ar/0x92-Appendix-C_Cryptography.md @@ -0,0 +1,311 @@ +# Appendix C: Cryptography Standards + +The "Cryptography" chapter goes beyond simply defining best practices. It aims to enhance understanding of cryptography principles and encourage the adoption of more resilient, modern security methods. This appendix provides detailed technical information regarding each requirement, complementing the overarching standards outlined in the "Cryptography" chapter. + +This appendix defines the level of approval for different cryptographic mechanisms: + +* Approved (A) mechanisms can be used in applications. +* Legacy mechanisms (L) should not be used in applications but might still be used for compatibility with existing legacy applications or code onyly. While the usage of such these mechanisms is currently not considered to be a vulnerability in itself, they should be replaced by more secure and future-proof mechanisms as soon as possible. +* Disallowed mechanisms (D) must not be used because they are currently considered broken or do not provide sufficient security. + +This list may be overridden in the context of a given application for various reasons including: + +* new evolutions in the field of cryptography; +* compliance with regulation. + +## Cryptographic Inventory and Documentation + +This section provides additional information +for V11.1 Cryptographic Inventory and Documentation. + +It is important to ensure that all cryptographic assets, such as algorithms, keys, and certificates, are regularly discovered, inventoried, and assessed. For Level 3, this should include the use of static and dynamic scanning to discover the use of cryptography in an application. Tools such as SAST and DAST may help with this but it is possible that dedicated tools would be needed to get more comprehensive coverage. Freeware examples of tools include: + +* [CryptoMon - Network Cryptography Monitor - using eBPF, written in python](https://github.com/Santandersecurityresearch/CryptoMon) +* [Cryptobom Forge Tool: Generating Comprehensive CBOMs from CodeQL Outputs](https://github.com/Santandersecurityresearch/cryptobom-forge) + +## Equivalent Strengths of Cryptographic Parameters + +The relative security strengths for various cryptographic systems are in this table (from [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), p.71): + +| Security Strength | Symmetric Key Algorithms | Finite Field | Integer Factorisation | Elliptic Curve | +|--|--|--|--|--| +| <= 80 | 2TDEA | L = 1024
N = 160 | k = 1024 | f = 160-223 | +| 112 | 3TDEA | L = 2048
N = 224 | k = 2048 | f = 224-255 | +| 128 | AES-128 | L = 3072
N = 256 | k = 3072 | f = 256-383 | +| 192 | AES-192 | L = 7680
N = 384 | k = 7680 | f = 384-511 | +| 256 | AES-256 | L = 15360
N = 512 | k = 15360 | f = 512+ | + +Example of applications: + +* Finite Field Cryptography: DSA, FFDH, MQV +* Integer Factorisation Cryptography: RSA +* Elliptic Curve Cryptography: ECDSA, EdDSA, ECDH, MQV + +Note: that this section assumes that no quantum computer exists; if such a computer would exist, the estimates for the last 3 columns would be no longer valid. + +## Random Values + +This section provides additional information +for V11.5 Random Values. + +| Name | Version/Reference | Notes | Status | +|:---|:----|:----|:-:| +| `/dev/random` | Linux 4.8+ [(Oct 2016)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=818e607b57c94ade9824dad63a96c2ea6b21baf3), also found in iOS, Android, and other Linux-based POSIX operating systems. Based on [RFC7539](https://datatracker.ietf.org/doc/html/rfc7539) | Utilizing ChaCha20 stream. Found in iOS [`SecRandomCopyBytes`](https://developer.apple.com/documentation/security/secrandomcopybytes(_:_:_:)?language=objc) and Android [`Secure Random`](https://developer.android.com/reference/java/security/SecureRandom) with the correct settings provided to each. | A | +| `/dev/urandom` | Linux kernel's special file for providing random data | Provides high-quality, entropy sources from hardware randomness | A | +| `AES-CTR-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | As used in common implementations, such as [Windows CNG API `BCryptGenRandom`](https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom) set by [`BCRYPT_RNG_ALGORITHM`](https://learn.microsoft.com/en-us/windows/win32/seccng/cng-algorithm-identifiers). | A | +| `HMAC-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | | A | +| `Hash-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | | A | +| `getentropy()` | [OpenBSD](https://man.openbsd.org/getentropy.2), available in [Linux glibc 2.25+](https://man7.org/linux/man-pages/man3/getentropy.3.html) and [macOS 10.12+](https://support.apple.com/en-gb/guide/security/seca0c73a75b/web) | Provides secure random bytes directly from the kernel's entropy source with a straightforward and minimal API. It’s more modern and avoids pitfalls associated with older APIs. | A | + +The underlying hash function used with HMAC-DRBG or Hash-DRBG must be approved for this usage. + +## Cipher Algorithms + +This section provides additional information +for V11.3 Encryption Algorithms. + +Approved cipher algorithms are listed in order of preference. + +| Symmetric Key Algorithms | Reference | Status | +| ------ | ------ |:-:| +| AES-256 | [FIPS 197](https://csrc.nist.gov/pubs/fips/197/final) | A | +| Salsa20 | [Salsa 20 specification](https://cr.yp.to/snuffle/spec.pdf) | A | +| XChaCha20 | [XChaCha20 Draft](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-xchacha-03) | A | +| XSalsa20 | [Extending the Salsa20 nonce](https://cr.yp.to/snuffle/xsalsa-20110204.pdf) | A | +| ChaCha20 | [RFC 8439](https://www.rfc-editor.org/info/rfc8439) | A | +| AES-192 | [FIPS 197](https://csrc.nist.gov/pubs/fips/197/final) | A | +| AES-128 | [FIPS 197](https://csrc.nist.gov/pubs/fips/197/final) | L | +| 2TDEA | | D | +| TDEA (3DES/3DEA) | | D | +| IDEA | | D | +| RC4 | | D | +| Blowfish| | D | +| ARC4 | | D | +| DES | | D | + +### AES Cipher Modes + +Block ciphers, such as AES, can be used with different modes of operations. Many modes of operations, such as Electronic codebook (ECB), are insecure and must not be used. The Galois/Counter Mode (GCM) and Counter with cipher block chaining message authentication code (CCM) modes of operations provide authenticated encryption and should be used in modern applications. + +Approved modes are listed in order of preference. + +| Mode | Authenticated | Reference | Status | Restriction | +|--|--|--|:-:|--| +| GCM | Yes | [NIST SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final) | A | | +| CCM | Yes | [NIST SP 800-38C](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final) | A | | +| CBC | No | [NIST SP 800-38A](https://csrc.nist.gov/pubs/sp/800/38/a/final) | L | | +| CCM-8 | Yes | | D | | +| ECB | No | | D | | +| CFB | No | | D | | +| OFB | No | | D | | +| CTR | No | | D | | + +Notes: + +* All encrypted messages must be authenticated. For ANY use of CBC mode there MUST be an associated hashing MAC algorithm to validate the message. In general, this MUST be applied in the Encrypt-Then-Hash method (but TLS 1.2 uses Hash-Then-Encrypt instead). If this cannot be guaranteed, then CBC MUST NOT be used. The only application where encryption without a MAC algorithm is allowed is disk encryption. +* If CBC is used, it shall be guaranteed that the verification of the padding is performed in constant time. +* When using CCM-8, the MAC tag only has 64 bits of security. This does not conform to requirement 6.2.9 which requires at least 128 bits of security. +* Disk encryption is considered out of scope for the ASVS. Therefore this appendix does not list any approved method for disk encryption. For this usage, encryption without authentication is usually accepted and the XTS, XEX and LRW modes are typically used. + +### Key Wrapping + +Cryptographic key wrap (and corresponding key unwrap) is a method of protecting an existing key by encapsulating (i.e., wrapping) it by employing an additional encryption mechanism so that the original key is not obviously exposed, e.g., during a transfer. This additional key used to protect the original key is referred to as the wrap key. + +This operation may be performed when it is desirable to protect keys in places deemed untrustworthy, or to send sensitive keys over untrusted networks or within applications. +However, serious consideration should be given to understanding the nature (e.g., the identity and the purpose) of the original key prior to committing to a wrap/unwrap procedure as this may have repercussions for both source and target systems/applications in terms of security and especially compliance which may include audit trails of a key's function (e.g., signing) as well as appropriate key storage. + +Specifically, AES-256 MUST be used for key wrapping, following [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) and considering forward-looking provisions against the quantum threat. Cipher modes using AES are the following, in order of preference: + +| Key Wrapping | Reference | Status | +|--|--|:-:| +| KW | [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) | A | +| KWP | [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) | A | + +AES-192 and AES-128 MAY be used if the use case demands it, but its motivation MUST be documented in the entity's cryptography inventory. + +### Authenticated Encryption + +With the exception of disk encryption, encrypted data must be protected against unauthorized modification using some form of authenticated encryption (AE) scheme, usually using an authenticated encryption with associated data (AEAD) scheme. + +The application should preferably use an approved AEAD scheme. It might alternatively combine an approved cipher scheme and an approved MAC algorithm with a Encrypt-then-MAC construct. + +MAC-then-encrypt is still allowed for compatibility with legacy applications. It is used in TLS v1.2 with old ciphers suites. + +| AEAD mechanism | Reference | Status | +|---|---------|:-:| +|AES-GCM | [SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final) | A | +|AES-CCM | [SP 800-38C](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final) | A | +|ChaCha-Poly1305 | [RFC 7539](https://datatracker.ietf.org/doc/html/rfc7539) | A | +|AEGIS-256 | [AEGIS: A Fast Authenticated Encryption Algorithm (v1.1)](https://competitions.cr.yp.to/round3/aegisv11.pdf) | A | +|AEGIS-128 | [AEGIS: A Fast Authenticated Encryption Algorithm (v1.1)](https://competitions.cr.yp.to/round3/aegisv11.pdf) | A | +|AEGIS-128L| [AEGIS: A Fast Authenticated Encryption Algorithm (v1.1)](https://competitions.cr.yp.to/round3/aegisv11.pdf) | A | +|Encrypt-then-MAC | | A | +|MAC-then-encrypt | | L | + +## Hash Functions + +This section provides additional information +for V11.4 Hashing and Hash-based Functions. + +### Hash Functions for General Use Cases + +The following table lists hash functions approved in general cryptographic use cases such as digital signatures: + +* Approved hash functions provide strong collision resistance and are suitable for high-security applications. +* Some of these algorithms offer strong resistance to attacks when used with proper cryptographic key management, and so are additionally approved for HMAC, KDF, and RBG functions. +* Hash function with less than 254 bit of output have insufficient collision resistancea and must not be used for digital signature or other applications requiring collision resistance. For other usages, they might be used for compatibility and verification ONLY with legacy systems but must not be used in new designs. + +| Hash function | Reference | Status | Restrictions | +| ------ | ----------- |:-:| ---------- | +| SHA3-512 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | | +| SHA-512 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | | +| SHA3-384 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | | +| SHA-384 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | | +| SHA3-256 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | | +| SHA-512/256 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | | +| SHA-256 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | | +| SHAKE256 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | | +| BLAKE2s | [BLAKE2: simpler, smaller, fast as MD5](https://eprint.iacr.org/2013/322) | A | | +| BLAKE2b | [BLAKE2: simpler, smaller, fast as MD5](https://eprint.iacr.org/2013/322) | A | | +| BLAKE3 | [BLAKE3 one function, fast everywhere](https://github.com/BLAKE3-team/BLAKE3-specs/raw/master/blake3.pdf) | A | | +| SHA-224 | [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | L | Not suitable for HMAC, KDF, RBG, digital signatures | +| SHA-512/224 | [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | L | Not suitable for HMAC, KDF, RBG, digital signatures | +| SHA3-224 | [FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | L | Not suitable for HMAC, KDF, RBG, digital signatures | +| SHA-1 | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) | L | Not suitable for HMAC, KDF, RBG, digital signatures | +| CRC (any length) | | D | | +| MD4 | [RFC 1320](https://www.rfc-editor.org/info/rfc1320) | D | | +| MD5 | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | | + +### Hash Functions for Password Storage + +For secure password hashing, dedicated hash functions must be used. These slow-hashing algorithms mitigate brute-force and dictionary attacks by increasing the computational difficulty of password cracking. + +| KDF | Reference | Required Parameters | Status | +| ---------- | --------- | ------------ |:-:| +| argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | t = 1: m ≥ 47104 (46 MiB), p = 1 | A | +| | | t = 2: m ≥ 19456 (19 MiB), p = 1 | A | +| | | t ≥ 3: m ≥ 12288 (12 MiB), p = 1 | A | +| scrypt | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | p = 1: N ≥ 2^17 (128 MiB), r = 8 | A | +| | | p = 2: N ≥ 2^16 (64 MiB), r = 8 | A | +| | | p ≥ 3: N ≥ 2^15 (32 MiB), r = 8 | A | +| bcrypt | [A Future-Adaptable Password Scheme](https://www.researchgate.net/publication/2519476_A_Future-Adaptable_Password_Scheme) | cost ≥ 10 | A | +| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 210,000 | A | +| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 600,000 | A | +| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 1,300,000 | L | + +Approved password-based key derivations functions can be used for password storage. + +## Key Derivation Functions (KDFs) + +### General Key Derivation Functions + +| KDF | Reference | Status | +| ---------------- | -------- |:-:| +| HKDF | [RFC 5869](https://www.rfc-editor.org/info/rfc5869) | A | +| TLS 1.2 PRF | [RFC 5248](https://www.rfc-editor.org/info/rfc5248) | L | +| MD5-based KDFs | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | +| SHA-1-based KDFs | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) | D | + +### Password-based Key Derivation Functions + +| KDF | Reference | Required Parameters | Status | +| ---------- | --------- | ------------ |:-:| +| argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | t = 1: m ≥ 47104 (46 MiB), p = 1 | A | +| | | t = 2: m ≥ 19456 (19 MiB), p = 1 | A | +| scrypt | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | p = 1: N ≥ 2^17 (128 MiB), r = 8 | A | +| | | p = 2: N ≥ 2^16 (64 MiB), r = 8 | A | +| | | p ≥ 3: N ≥ 2^15 (32 MiB), r = 8 | A | +| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 210,000 | A | +| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 600,000 | A | +| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 1,300,000 | L | + +## Key Exchange Mechanisms + +This section provides additional information +for V11.6 Public Key Cryptography. + +### KEX Schemes + +A security strength of 112 bits or above MUST be ensured for all Key Exchange schemes, and their implementation MUST follow the parameter choices in the following table. + +| Scheme | Domain Parameters | Forward Secrecy |Status | +|--|--|--|:-:| +| Finite Field Diffie-Hellman (FFDH) | L >= 3072 & N >= 256 | Yes | A | +| Elliptic Curve Diffie-Hellman (ECDH) | f >= 256-383 | Yes | A | +| Encrypted key transport with RSA-PKCS#1 v1.5 | | No | D | + +Where the following parameters are: + +* k is the key size for RSA keys. +* L is the size of the public key and N is the size of the private key for finite field cryptography. +* f is the range of key sizes for ECC. + +Any new implementation MUST NOT use any scheme that is NOT compliant with [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final) & [B](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final) and [NIST SP 800-77](https://csrc.nist.gov/pubs/sp/800/77/r1/final). Specifically, IKEv1 MUST NOT be used in production. + +### Diffie-Hellman groups + +The following groups are approved for implementations of Diffie-Hellman key exchange. Security strengths are documented in [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final), Appendix D, and [NIST SP 800-57 Part 1 Rev.5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final). + +| Group | Status | +|------------------|:------:| +| P-224, secp224r1 | A | +| P-256, secp256r1 | A | +| P-384, secp384r1 | A | +| P-521, secp521r1 | A | +| K-233, sect233k1 | A | +| K-283, sect283k1 | A | +| K-409, sect409k1 | A | +| K-571, sect571k1 | A | +| B-233, sect233r1 | A | +| B-283, sect283r1 | A | +| B-409, sect409r1 | A | +| B-571, sect571r1 | A | +| Curve448 | A | +| Curve25519 | A | +| MODP-2048 | A | +| MODP-3072 | A | +| MODP-4096 | A | +| MODP-6144 | A | +| MODP-8192 | A | +| ffdhe2048 | A | +| ffdhe3072 | A | +| ffdhe4096 | A | +| ffdhe6144 | A | +| ffdhe8192 | A | + +## Message Authentication Codes (MAC) + +Message Authentication Codes (MACs) are cryptographic constructs used to verify the integrity and authenticity of a message. A MAC takes a message and a secret key as inputs and produces a fixed-size tag (the MAC value). MACs are widely used in secure communication protocols (e.g., TLS/SSL) to ensure that messages exchanged between parties are authentic and intact. + +| MAC Algorithm | Reference | Status | +| ---------- | --------------- |:-:| +| HMAC-SHA-256 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A | +| HMAC-SHA-384 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A | +| HMAC-SHA-512 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A | +| KMAC128 | [NIST SP 800-185](https://csrc.nist.gov/pubs/sp/800/185/final) | A | +| KMAC256 | [NIST SP 800-185](https://csrc.nist.gov/pubs/sp/800/185/final) | A | +| BLAKE3 (keyed_hash mode) | [BLAKE3 one function, fast everywhere](https://github.com/BLAKE3-team/BLAKE3-specs/raw/master/blake3.pdf) | A | +| AES-CMAC | [RFC 4493](https://datatracker.ietf.org/doc/html/rfc4493) & [NIST SP 800-38B](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf) | A | +| AES-GMAC | [NIST SP 800-38D](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf) | A | +| Poly1305-AES | [The Poly1305-AES message-authentication code](https://cr.yp.to/mac/poly1305-20050329.pdf) | A | +| HMAC-SHA-1 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | L | +| HMAC-MD5 | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | + +## Digital Signatures + +Signature schemes MUST use approved key sizes and parameters per [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final). + +| Signature Algorithm | Reference | Status | +| ------------------------------ | --------------------------------------------- | :-: | +| EdDSA (Ed25519, Ed448) | [RFC 8032](https://www.rfc-editor.org/info/rfc8032) | A | +| XEdDSA (Curve25519, Curve448) | [XEdDSA](https://signal.org/docs/specifications/xeddsa/) | A | +| ECDSA (P-256, P-384, P-521) | [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-5/final) | A | +| RSA-RSSA-PSS | [RFC 8017](https://www.rfc-editor.org/info/rfc8017) | A | +| RSA-SSA-PKCS#1 v1.5 | [RFC 8017](https://www.rfc-editor.org/info/rfc8017) | D | +| DSA (any key size) | [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-4/final) | D | + +## Post-Quantum Encryption Standards + +PQC implementations must be in line with [FIPS-203](https://csrc.nist.gov/pubs/fips/203/ipd)/[204](https://csrc.nist.gov/pubs/fips/204/ipd)/[205](https://csrc.nist.gov/pubs/fips/205/ipd) as there is minimal hardened code nor implementation reference yet. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards + +The proposed [mlkem768x25519](https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/03/) post-quantum hybrid TLS key agreement method is supported by major browsers such as [Firefox release 132](https://www.mozilla.org/en-US/firefox/132.0/releasenotes/) and [Chrome release 131](https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html). It may be used in cryptographic testing environments or when available within industry- or government-approved libraries. diff --git a/5.0/ar/0x93-Appendix-D_Recommendations.md b/5.0/ar/0x93-Appendix-D_Recommendations.md new file mode 100644 index 0000000000..29d8c85102 --- /dev/null +++ b/5.0/ar/0x93-Appendix-D_Recommendations.md @@ -0,0 +1,49 @@ +# الملحق د: التوصيات + +## مقدمة + +أثناء إعداد الإصدار 5.0 من معيار التحقق من أمان التطبيقات (ASVS)، اتضح أن هناك عددًا من البنود القائمة والمقترحة حديثًا التي لا ينبغي إدراجها كمتطلبات في الإصدار 5.0. وقد يكون ذلك لأنها لم تكن داخل نطاق ASVS وفق تعريف الإصدار 5.0، أو بدلًا من ذلك لأنه رُئي أنها، وإن كانت فكرة جيدة، لا يمكن جعلها إلزامية. + +ولعدم الرغبة في فقدان كل هذه البنود تمامًا، فقد ضُمّ بعضها في هذا الملحق. + +## آليات موصى بها وداخلة في النطاق + +البنود التالية داخلة في نطاق ASVS. ولا ينبغي جعلها إلزامية، لكن يُوصى بقوة بالنظر فيها كجزء من تطبيق آمن. + +* ينبغي توفير مقياس لقوة كلمة المرور لمساعدة المستخدمين على تعيين كلمة مرور أقوى. +* أنشئ ملف security.txt متاحًا للعموم في الجذر أو في مجلد .well-known الخاص بالتطبيق، يحدّد بوضوح رابطًا أو عنوان بريد إلكتروني ليتصل الناس بالمالكين بشأن المشكلات الأمنية. +* ينبغي إنفاذ التحقق من صحة المدخلات من جانب العميل إضافةً إلى التحقق في طبقة خدمة موثوقة، إذ يوفّر ذلك فرصة جيدة لاكتشاف تجاوز أحدهم للضوابط من جانب العميل في محاولة لمهاجمة التطبيق. +* امنع ظهور الصفحات الحسّاسة والتي يمكن الوصول إليها عن غير قصد في محركات البحث باستخدام ملف robots.txt أو ترويسة الاستجابة X-Robots-Tag أو وسم robots في html. +* عند استخدام GraphQL، نفّذ منطق التخويل في طبقة منطق العمل بدلًا من طبقة GraphQL أو المُحلِّل، لتجنّب الحاجة إلى معالجة التخويل في كل واجهة منفصلة. + +المراجع: + +* [More information on security.txt including a link to the RFC](https://securitytxt.org/) + +## مبادئ أمان البرمجيات + +كانت البنود التالية موجودة سابقًا في ASVS لكنها ليست متطلبات في الحقيقة. بل هي مبادئ ينبغي مراعاتها عند تنفيذ ضوابط الأمان، والتي يؤدي اتباعها إلى ضوابط أكثر متانة. وتشمل ما يلي: + +* ينبغي أن تكون ضوابط الأمان مركزية وبسيطة (اقتصاد التصميم) وآمنة على نحو قابل للتحقق وقابلة لإعادة الاستخدام. وهذا ينبغي أن يمنع الضوابط المكرّرة أو المفقودة أو غير الفعّالة. +* استخدم، حيثما أمكن، تنفيذات ضوابط أمان مكتوبة مسبقًا ومدروسة جيدًا بدلًا من الاعتماد على تنفيذ الضوابط من الصفر. +* من الأفضل استخدام آلية واحدة للتحكم في الوصول للوصول إلى البيانات والموارد المحمية. وينبغي أن تمرّ جميع الطلبات عبر هذه الآلية الواحدة لتجنّب النسخ واللصق أو المسارات البديلة غير الآمنة. +* يُعدّ التحكم في الوصول المبني على السمات أو الميزات نمطًا موصى به، تتحقق فيه الشيفرة من تخويل المستخدم لميزة أو عنصر بيانات بدلًا من التحقق من دوره فقط. ومع ذلك ينبغي أن تُخصَّص الصلاحيات باستخدام الأدوار. + +## عمليات أمان البرمجيات + +هناك عدد من العمليات الأمنية التي أُزيلت من ASVS 5.0 لكنها لا تزال فكرة جيدة. وقد يكون مشروع OWASP SAMM مصدرًا جيدًا لمعرفة كيفية تنفيذ هذه العمليات بفعالية. وتشمل البنود التي كانت موجودة سابقًا في ASVS ما يلي: + +* تحقق من استخدام دورة حياة آمنة لتطوير البرمجيات تعالج الأمان في جميع مراحل التطوير. +* تحقق من استخدام نمذجة التهديدات لكل تغيير في التصميم أو تخطيط لدورة عمل، لتحديد التهديدات والتخطيط للتدابير المضادة وتيسير الاستجابات الملائمة للمخاطر وتوجيه اختبار الأمان. +* تحقق من أن جميع قصص المستخدم والميزات تتضمّن قيودًا أمنية وظيفية، مثل "كمستخدم، ينبغي أن أكون قادرًا على عرض ملفي الشخصي وتحريره. وينبغي ألا أكون قادرًا على عرض ملف أي شخص آخر أو تحريره" +* تحقق من توافر قائمة تحقق للبرمجة الآمنة أو متطلبات أمنية أو دليل أو سياسة لجميع المطوّرين والمختبرين. +* تحقق من وجود عملية مستمرة للتأكد من أن الشيفرة المصدرية للتطبيق خالية من الأبواب الخلفية والشيفرة الضارة (مثل هجمات السلامي والقنابل المنطقية والقنابل الزمنية) والميزات غير الموثّقة أو المخفية (مثل بيض الفصح وأدوات التنقيح غير الآمنة). والامتثال لهذا القسم غير ممكن دون وصول كامل إلى الشيفرة المصدرية، بما في ذلك مكتبات الأطراف الثالثة، ولذلك فهو على الأرجح مناسب فقط للتطبيقات التي تتطلّب أعلى مستويات الأمان. +* تحقق من وجود آليات لكشف انحراف التكوين في البيئات المنشورة والاستجابة له. وقد يشمل ذلك استخدام بنية تحتية غير قابلة للتغيير أو إعادة نشر مؤتمتة من خط أساس آمن أو أدوات لكشف الانحراف تقارن الحالة الراهنة بالتكوينات المعتمدة. +* تحقق من إجراء تحصين التكوين على جميع منتجات ومكتبات وأُطر وخدمات الأطراف الثالثة وفقًا لتوصيات كل منها. + +المراجع: + +* [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) +* [OWASP Threat modeling](https://owasp.org/www-community/Application_Threat_Modeling) +* [OWASP Software Assurance Maturity Model Project](https://owasp.org/www-project-samm/) +* [Microsoft SDL](https://www.microsoft.com/en-us/securityengineering/sdl/) diff --git a/5.0/ar/0x94-Appendix-E_Contributors.md b/5.0/ar/0x94-Appendix-E_Contributors.md new file mode 100644 index 0000000000..79866b2357 --- /dev/null +++ b/5.0/ar/0x94-Appendix-E_Contributors.md @@ -0,0 +1,71 @@ +# الملحق هـ - المساهمون + +نعرب عن امتناننا لإسهامات الأشخاص التالية أسماؤهم، الذين علّقوا أو فتحوا طلبات دمج منذ إصدار ASVS 4.0.0. + +وإذا كنت على علم بأي أخطاء أو كنت ترغب في ظهور اسمك بصورة مختلفة، فيُرجى إخبارنا. + +| | | | | +|---|---|---|---| +| Johan Sydseter ([sydseter](https://github.com/sydseter)) | luis servin ([lfservin](https://github.com/lfservin)) | Oleksii Dovydkov ([oleksiidov](https://github.com/oleksiidov)) | IZUKA Masahiro ([maizuka](https://github.com/maizuka)) | +| James Sulinski ([jsulinski](https://github.com/jsulinski)) | Eli Saad ([ThunderSon](https://github.com/ThunderSon)) | [kkshitish9](https://github.com/kkshitish9) | Andrew van der Stock ([vanderaj](https://github.com/vanderaj)) | +| Rick M ([kingthorin](https://github.com/kingthorin)) | Bankde Eakasit ([Bankde](https://github.com/Bankde)) | Michael Gargiullo ([mgargiullo](https://github.com/mgargiullo)) | Raphael Dunant ([Racater](https://github.com/Racater)) | +| Cesar Kohl ([cesarkohl](https://github.com/cesarkohl)) | [inaz0](https://github.com/inaz0) | Joerg Bruenner ([JoergBruenner](https://github.com/JoergBruenner)) | David Deatherage ([securitydave](https://github.com/securitydave)) | +| John Carroll ([yosignals](https://github.com/yosignals)) | Jim Fenton ([jimfenton](https://github.com/jimfenton)) | Matteo Pace ([M4tteoP](https://github.com/M4tteoP)) | Sebastien gioria ([SPoint42](https://github.com/SPoint42)) | +| Steven van der Baan ([vdbaan](https://github.com/vdbaan)) | Jeremy Bonghwan Choi ([jeremychoi](https://github.com/jeremychoi)) | [craig-shony](https://github.com/craig-shony) | Riccardo Sirigu ([ricsirigu](https://github.com/ricsirigu)) | +| Tomasz Wrobel ([tw2as](https://github.com/tw2as)) | Alena Dubeshko ([belalena](https://github.com/belalena)) | Rafael Green ([RafaelGreen1](https://github.com/RafaelGreen1)) | [mjang-cobalt](https://github.com/mjang-cobalt) | +| [clallier94](https://github.com/clallier94) | Kevin W. Wall ([kwwall](https://github.com/kwwall)) | Jordan Sherman ([jsherm-fwdsec](https://github.com/jsherm-fwdsec) / [deleterepo](https://github.com/deleterepo)) | Ingo Rauner ([ingo-rauner](https://github.com/ingo-rauner)) | +| Dirk Wetter ([drwetter](https://github.com/drwetter)) | Moshe Zioni ([moshe-apiiro](https://github.com/moshe-apiiro)) | Patrick Dwyer ([coderpatros](https://github.com/coderpatros)) | David Clarke ([davidclarke-au](https://github.com/davidclarke-au)) | +| Takaharu Ogasa ([takaharuogasa](https://github.com/takaharuogasa)) | Arkadii Yakovets ([arkid15r](https://github.com/arkid15r)) | Motoyasu Saburi ([motoyasu-saburi](https://github.com/motoyasu-saburi)) | [leirn](https://github.com/leirn) | +| [wet-certitude](https://github.com/wet-certitude) | [timhemel](https://github.com/timhemel) | RL Thornton ([thornshadow99](https://github.com/thornshadow99)) | Thomas Bandt ([aspnetde](https://github.com/aspnetde)) | +| Roel Storms ([roelstorms](https://github.com/roelstorms)) | Jeroen Willemsen ([commjoen](https://github.com/commjoen)) | [anonymous-31](https://github.com/anonymous-31) | Kamran Saifullah ([deFr0ggy](https://github.com/deFr0ggy)) | +| Steve Springett ([stevespringett](https://github.com/stevespringett)) | Spyros ([northdpole](https://github.com/northdpole)) | Hans Herrera ([hansphp](https://github.com/hansphp)) | [Marx314](https://github.com/Marx314) | +| [CarlosAllendes](https://github.com/CarlosAllendes) | Yonah Russ ([yruss972](https://github.com/yruss972)) | Sander Maijers ([sanmai-NL](https://github.com/sanmai-NL)) | Luboš Bretschneider ([bretik](https://github.com/bretik)) | +| Eva Sarafianou ([esarafianou](https://github.com/esarafianou)) | [ataseren](https://github.com/ataseren) | Steve Thomas ([Sc00bz](https://github.com/Sc00bz)) | Dominique RIGHETTO ([righettod](https://github.com/righettod)) | +| Steven van der Baan ([svdb-ncc](https://github.com/svdb-ncc)) | Michael Vacarella ([Aif4thah](https://github.com/Aif4thah)) | Tonimir Kisasondi ([tkisason](https://github.com/tkisason)) | Stefan Streichsbier ([streichsbaer](https://github.com/streichsbaer)) | +| [hi-unc1e](https://github.com/hi-unc1e) | sb3k ([starbuck3000](https://github.com/starbuck3000)) | [mario-platt](https://github.com/mario-platt) | Devdatta Akhawe ([devd](https://github.com/devd)) | +| Michael Gissing ([scolytus](https://github.com/scolytus)) | Jet Anderson ([thatsjet](https://github.com/thatsjet)) | Dave Wichers ([davewichers](https://github.com/davewichers)) | Jonny Schnittger ([JonnySchnittger](https://github.com/JonnySchnittger)) | +| Silvia Väli ([silviavali](https://github.com/silviavali)) | [jackgates73](https://github.com/jackgates73) | [1songb1rd](https://github.com/1songb1rd) | Timur - ([timurozkul](https://github.com/timurozkul)) | +| Gareth Heyes ([hackvertor](https://github.com/hackvertor)) | [appills](https://github.com/appills) | [suvikaartinen](https://github.com/suvikaartinen) | chaals ([chaals](https://github.com/chaals)) | +| DanielPharos ([AtlasHackert](https://github.com/AtlasHackert)) | will Farrell ([willfarrell](https://github.com/willfarrell)) | Alina Vasiljeva ([avasiljeva](https://github.com/avasiljeva)) | Paul McCann ([ismisepaul](https://github.com/ismisepaul)) | +| Sage ([SajjadPourali](https://github.com/SajjadPourali)) | [rbsec](https://github.com/rbsec) | Benedikt Bauer ([mastacheata](https://github.com/mastacheata)) | James Jardine ([jamesjardine](https://github.com/jamesjardine)) | +| Mark Burnett ([m8urnett](https://github.com/m8urnett)) | [dschwarz91](https://github.com/dschwarz91) | Cyber-AppSec ([Cyber-AppSec](https://github.com/Cyber-AppSec)) | [Tib3rius](https://github.com/Tib3rius) | +| BitnessWise ([bitnesswise](https://github.com/bitnesswise)) | damienbod ([damienbod](https://github.com/damienbod)) | Jared Meit ([jmeit-fwdsec](https://github.com/jmeit-fwdsec)) | Stefan Seelmann ([sseelmann](https://github.com/sseelmann)) | +| Brendan O'Connor ([ussjoin](https://github.com/ussjoin)) | Andrei Titov ([andrettv](https://github.com/andrettv)) | Hans-Petter Fjeld ([atluxity](https://github.com/atluxity)) | [markehack](https://github.com/markehack) | +| Neil Madden ([NeilMadden](https://github.com/NeilMadden)) | Michael Geramb ([mgeramb](https://github.com/mgeramb)) | Osama Elnaggar ([ossie-git](https://github.com/ossie-git)) | [mackowski](https://github.com/mackowski) | +| Ravi Balla ([raviballa](https://github.com/raviballa)) | Hazana ([hazanasec](https://github.com/hazanasec)) | David Means ([dmeans82](https://github.com/dmeans82)) | Alexander Stein ([tohch4](https://github.com/tohch4)) | +| BaeSenseii ([baesenseii](https://github.com/baesenseii)) | Vincent De Schutter ([VincentDS](https://github.com/VincentDS)) | S Bani ([sbani](https://github.com/sbani)) | Mitsuaki Akiyama ([mak1yama](https://github.com/mak1yama)) | +| Christopher Loessl ([hashier](https://github.com/hashier)) | [victorxm](https://github.com/victorxm) | Michal Rada ([michalradacz](https://github.com/michalradacz)) | Veeresh Devireddy ([drveresh](https://github.com/drveresh)) | +| [MaknaSEO](https://github.com/MaknaSEO) | [darkzero2022](https://github.com/darkzero2022) | Liam ([LiamDobbelaere](https://github.com/LiamDobbelaere)) | Frank Denis ([jedisct1](https://github.com/jedisct1)) | +| Otto Sulin ([ottosulin](https://github.com/ottosulin)) | [carllaw6885](https://github.com/carllaw6885) | Anders Johan Holmefjord ([aholmis](https://github.com/aholmis)) | Richard Fritsch ([rfricz](https://github.com/rfricz)) | +| [mesutgungor](https://github.com/mesutgungor) | Scott Helme ([ScottHelme](https://github.com/ScottHelme)) | Carlo Reggiani ([carloreggiani](https://github.com/carloreggiani)) | Suyash Srivastava ([suyash5053](https://github.com/suyash5053)) | +| Mark Potter ([markonweb](https://github.com/markonweb)) | Arjan Lamers ([alamers](https://github.com/alamers)) | Gøran Breivik ([gobrtg](https://github.com/gobrtg)) | [flo-blg](https://github.com/flo-blg) | +| Guillaume Déflache ([guillaume-d](https://github.com/guillaume-d)) | Toufik Airane ([toufik-airane](https://github.com/toufik-airane)) | Keith Hoodlet ([securingdev](https://github.com/securingdev)) | Sinner ([SoftwareSinner](https://github.com/SoftwareSinner)) | +| [iloving](https://github.com/iloving) | Jeroen Beckers ([TheDauntless](https://github.com/TheDauntless)) | Joubin Jabbari ([joubin](https://github.com/joubin)) | yu fujioka ([fujiokayu](https://github.com/fujiokayu)) | +| execjosh ([execjosh](https://github.com/execjosh)) | Alicja Kario ([tomato42](https://github.com/tomato42)) | Sidney Ribeiro ([srjsoftware](https://github.com/srjsoftware)) | Gabriel Marquet ([Gby56](https://github.com/Gby56)) | +| Drew Schulz ([drschulz](https://github.com/drschulz)) | [bedirhan](https://github.com/bedirhan) | [muralito](https://github.com/muralito) | Ronnie Flathers ([ropnop](https://github.com/ropnop)) | +| Philippe De Ryck ([philippederyck](https://github.com/philippederyck)) | Malte ([mal33](https://github.com/mal33)) | [MazeOfThoughts](https://github.com/MazeOfThoughts) | Andreas Falk ([andifalk](https://github.com/andifalk)) | +| Javi ([javixeneize](https://github.com/javixeneize)) | Daniel Hahn ([averell23](https://github.com/averell23)) | [borislav-c](https://github.com/borislav-c) | Robin Wood ([digininja](https://github.com/digininja)) | +| [miro2ns](https://github.com/miro2ns) | Jan Dockx ([jandockx](https://github.com/jandockx)) | [vipinsaini434](https://github.com/vipinsaini434) | [priyanshukumar397](https://github.com/priyanshukumar397) | +| Nat Sakimura ([sakimura](https://github.com/sakimura)) | Benjamin Häublein ([BenjaminHae](https://github.com/BenjaminHae)) | [unknown-user-from](https://github.com/unknown-user-from) | Ali Ramazan TAŞDELEN ([alitasdln](https://github.com/alitasdln)) | +| Pedro Escaleira ([oEscal](https://github.com/oEscal)) | Josh ([josh-hemphill](https://github.com/josh-hemphill)) | Tim Würtele ([SECtim](https://github.com/SECtim)) | AviD ([avidouglen](https://github.com/avidouglen)) | +| SheHacksPurple ([shehackspurple](https://github.com/shehackspurple)) | [fcerullo-cycubix](https://github.com/fcerullo-cycubix) | Hector Eryx Paredes Camacho ([heryxpc](https://github.com/heryxpc)) | Irene Michlin ([irene221b](https://github.com/irene221b)) | +| Jonah Y-M ([TG-Techie](https://github.com/TG-Techie)) | Dhiraj Bahroos ([bahroos](https://github.com/bahroos)) | Jef Meijvis ([jefmeijvis](https://github.com/jefmeijvis)) | [IzmaDoesItbeta](https://github.com/IzmaDoesItbeta) | +| Abdessamad TEMMAR ([TmmmmmR](https://github.com/TmmmmmR)) | [sectroyer](https://github.com/sectroyer) | Soh Satoh ([sohsatoh](https://github.com/sohsatoh)) | [regoravalaz](https://github.com/regoravalaz) | +| james-t ([james-bitherder](https://github.com/james-bitherder)) | Aram Hovsepyan ([aramhovsepyan](https://github.com/aramhovsepyan)) | [JaimeGomezGarciaSan](https://github.com/JaimeGomezGarciaSan) | [ValdiGit01](https://github.com/ValdiGit01) | +| iwatachan ([ishowta](https://github.com/ishowta)) | Vinod Anandan ([VinodAnandan](https://github.com/VinodAnandan)) | Kevin Kien ([KevinKien](https://github.com/KevinKien)) | [paul-williamson-swoop](https://github.com/paul-williamson-swoop) | +| [endergzr](https://github.com/endergzr) | Radhwan Alshamamri ([Rado0z](https://github.com/Rado0z)) | Grant Ongers ([rewtd](https://github.com/rewtd)) | Cure53 ([cure53](https://github.com/cure53)) | +| [AliR2Linux](https://github.com/AliR2Linux) | Ads Dawson ([GangGreenTemperTatum](https://github.com/GangGreenTemperTatum)) | William Reyor ([BillReyor](https://github.com/BillReyor)) | gabe ([gcrow](https://github.com/gcrow)) | +| [mascotter](https://github.com/mascotter) | [luissaiz](https://github.com/luissaiz) | Suren Manukyan ([vx-sec](https://github.com/vx-sec)) | Piotr Gliźniewicz ([pglizniewicz](https://github.com/pglizniewicz)) | +| Tadeusz Wachowski ([tadeuszwachowski](https://github.com/tadeuszwachowski)) | Nasir aka Nate ([andesec](https://github.com/andesec)) | [settantasette](https://github.com/settantasette) | Lars Haulin ([LarsH](https://github.com/LarsH)) | +| Terence Eden ([edent](https://github.com/edent)) | [JasmineScholz](https://github.com/JasmineScholz) | Arun Sivadasan ([teavanist](https://github.com/teavanist)) | Yusuf GÜR ([yusuffgur](https://github.com/yusuffgur)) | +| Troy Marshall ([troymarshall](https://github.com/troymarshall)) | Tanner Prynn ([tprynn](https://github.com/tprynn)) | Nick K. ([nickific](https://github.com/nickific)) | [raoul361](https://github.com/raoul361) | +| Azeem Ilyas ([TheAxZim](https://github.com/TheAxZim)) | Evo Stamatov ([avioli](https://github.com/avioli)) | Tim Potter ([timpotter87](https://github.com/timpotter87)) | Gavin Ray ([GavinRay97](https://github.com/GavinRay97)) | +| monis ([demideus](https://github.com/demideus)) | Marcin Hoppe ([MarcinHoppe](https://github.com/MarcinHoppe)) | Grambulf ([ramshazar](https://github.com/ramshazar)) | Jordan Pike ([computersarebad](https://github.com/computersarebad)) | +| Jason Rogers ([jason-invision](https://github.com/jason-invision)) | Ben Hall ([benbhall](https://github.com/benbhall)) | JamesPoppyCock ([jamesly123](https://github.com/jamesly123)) | WhiteHackLabs ([whitehacklabs](https://github.com/whitehacklabs)) | +| Alex Gaynor ([alex](https://github.com/alex)) | Filip van Laenen ([filipvanlaenen](https://github.com/filipvanlaenen)) | [jeurgen](https://github.com/jeurgen) | [GraoMelo](https://github.com/GraoMelo) | +| Andreas Kurtz ([ay-kay](https://github.com/ay-kay)) | Tom Tervoort ([TomTervoort](https://github.com/TomTervoort)) | old man ([deveras](https://github.com/deveras)) | Marco Schnüriger ([marcortw](https://github.com/marcortw)) | +| [stiiin](https://github.com/stiiin) | infoseclearn ([teaminfoseclearn](https://github.com/teaminfoseclearn)) | [hljupkij](https://github.com/hljupkij) | Noe ([nmarher](https://github.com/nmarher)) | +| Lyz ([lyz-code](https://github.com/lyz-code)) | Martin Riedel ([mrtnrdl](https://github.com/mrtnrdl)) | KIM Jaesuck ([tcaesvk](https://github.com/tcaesvk)) | Barbara Schachner ([bschach](https://github.com/bschach)) | +| René Reuter ([AresSec](https://github.com/AresSec)) | [carhackpils](https://github.com/carhackpils) | Tyler ([tyler2cr](https://github.com/tyler2cr)) | Hugo ([hasousa](https://github.com/hasousa)) | +| Wouter Bloeyaert ([Someniak](https://github.com/Someniak)) | Mark de Rijk ([markderijkinfosec](https://github.com/markderijkinfosec)) | Ramin ([picohub](https://github.com/picohub)) | Philip D. Turner ([philipdturner](https://github.com/philipdturner)) | +| Will Chatham ([willc](https://github.com/willc)) | | | | From 9e02659a5b4fc1eb84c764b5021b6c480e40cfe1 Mon Sep 17 00:00:00 2001 From: khalidwalamri Date: Tue, 8 Sep 2026 11:10:31 +0300 Subject: [PATCH 2/2] Fix alignment and some content errors --- 5.0/ar/0x00-Header.yaml | 12 +- 5.0/ar/0x01-Frontispiece.md | 2 +- 5.0/ar/0x02-Preface.md | 16 +- 5.0/ar/0x03-What-is-the-ASVS.md | 200 ++++++++-------- 5.0/ar/0x04-Assessment_and_Certification.md | 20 +- 5.0/ar/0x05-For-Users-Of-4.0.md | 2 +- 5.0/ar/0x15-V6-Authentication.md | 198 ++++++++-------- 5.0/ar/0x19-V10-OAuth-and-OIDC.md | 194 +++++++-------- 5.0/ar/0x21-V12-Secure-Communication.md | 2 +- 5.0/ar/0x23-V14-Data-Protection.md | 2 +- ...0x24-V15-Secure-Coding-and-Architecture.md | 2 +- ...V16-Security-Logging-and-Error-Handling.md | 2 +- 5.0/ar/0x26-V17-WebRTC.md | 4 +- 5.0/ar/0x90-Appendix-A_Glossary.md | 4 +- 5.0/ar/0x91-Appendix-B_References.md | 6 +- 5.0/ar/0x92-Appendix-C_Cryptography.md | 222 +++++++++--------- 5.0/ar/0x93-Appendix-D_Recommendations.md | 8 +- 5.0/ar/0x94-Appendix-E_Contributors.md | 2 +- 18 files changed, 452 insertions(+), 446 deletions(-) diff --git a/5.0/ar/0x00-Header.yaml b/5.0/ar/0x00-Header.yaml index 00325b4adf..9a0b784331 100644 --- a/5.0/ar/0x00-Header.yaml +++ b/5.0/ar/0x00-Header.yaml @@ -1,7 +1,7 @@ --- - title: "Application Security Verification Standard" - subtitle: "Version 5.0.0" - date: May 2025 + title: "معيار التحقق من أمان التطبيقات" + subtitle: "الإصدار 5.0.0" + date: "مايو 2025" titlepage: true titlepage-rule-height: 0 titlepage-logo: "images/owasp_logo_1c_notext.png" @@ -13,4 +13,10 @@ dir: rtl mainfont: "Amiri" sansfont: "Amiri" + mainfontoptions: + - Script=Arabic + - Language=Arabic + sansfontoptions: + - Script=Arabic + - Language=Arabic --- diff --git a/5.0/ar/0x01-Frontispiece.md b/5.0/ar/0x01-Frontispiece.md index a06a6d514e..44b0bc19aa 100644 --- a/5.0/ar/0x01-Frontispiece.md +++ b/5.0/ar/0x01-Frontispiece.md @@ -43,4 +43,4 @@ إذا كان هناك إسهام غائب عن قائمة الإسهامات للإصدار 5.x، فيُرجى تسجيل تذكرة على GitHub ليُعترف به في تحديثات 5.x المستقبلية. -يبني معيار التحقق من أمان التطبيقات على عمل من شاركوا في إصدارات ASVS من 1.0 (2008) حتى 4.0 (2019). وقد كُتب في الأصل كثير من البنية والعديد من بنود التحقق التي لا تزال موجودة في ASVS اليوم على أيدي Andrew van der Stock وMike Boberski وJeff Williams وDave Wichers، إلى جانب عدد كبير من المساهمين الآخرين. شكرًا لكل من ساهم في الماضي. وللحصول على قائمة شاملة بالمساهمين السابقين، يُرجى الرجوع إلى كل إصدار سابق. +يبني معيار التحقق من أمان التطبيقات على عمل من شاركوا في إصدارات معيار التحقق من أمان التطبيقات من 1.0 (2008) حتى 4.0 (2019). وقد كُتب في الأصل كثير من البنية والعديد من بنود التحقق التي لا تزال موجودة في معيار التحقق من أمان التطبيقات اليوم على أيدي Andrew van der Stock وMike Boberski وJeff Williams وDave Wichers، إلى جانب عدد كبير من المساهمين الآخرين. شكرًا لكل من ساهم في الماضي. وللحصول على قائمة شاملة بالمساهمين السابقين، يُرجى الرجوع إلى كل إصدار سابق. diff --git a/5.0/ar/0x02-Preface.md b/5.0/ar/0x02-Preface.md index 66a17d54a0..11ecde6c3d 100644 --- a/5.0/ar/0x02-Preface.md +++ b/5.0/ar/0x02-Preface.md @@ -4,11 +4,11 @@ ## مقدمة -أُطلق ASVS في الأصل عام 2008 من خلال تعاون مجتمعي عالمي، وهو يحدّد مجموعة شاملة من متطلبات الأمان لتصميم تطبيقات وخدمات الويب الحديثة وتطويرها واختبارها. +أُطلق معيار التحقق من أمان التطبيقات في الأصل عام 2008 من خلال تعاون مجتمعي عالمي، وهو يحدّد مجموعة شاملة من متطلبات الأمان لتصميم تطبيقات وخدمات الويب الحديثة وتطويرها واختبارها. -بعد إصدار ASVS 4.0 عام 2019 وتحديثه الطفيف (الإصدار 4.0.3) عام 2021، يمثّل الإصدار 5.0 محطة مهمة—حُدِّث ليجسّد أحدث التطورات في أمان البرمجيات. +بعد إصدار معيار التحقق من أمان التطبيقات 4.0 عام 2019 وتحديثه الطفيف (الإصدار 4.0.3) عام 2021، يمثّل الإصدار 5.0 محطة مهمة—حُدِّث ليجسّد أحدث التطورات في أمان البرمجيات. -ASVS 5.0 هو نتاج إسهامات واسعة من قادة المشروع وأعضاء مجموعة العمل ومجتمع OWASP الأوسع لتحديث هذا المعيار المهم وتحسينه. +معيار التحقق من أمان التطبيقات 5.0 هو نتاج إسهامات واسعة من قادة المشروع وأعضاء مجموعة العمل ومجتمع OWASP الأوسع لتحديث هذا المعيار المهم وتحسينه. ## المبادئ التي يستند إليها الإصدار 5.0 @@ -16,14 +16,14 @@ ASVS 5.0 هو نتاج إسهامات واسعة من قادة المشروع و * نطاق وتركيز مُحسَّنان: صُمِّم هذا الإصدار من المعيار ليتوافق بشكل أكثر مباشرة مع الركائز الأساسية في اسمه: التطبيق، والأمان، والتحقق، والمعيار. وقد أُعيدت كتابة المتطلبات للتأكيد على منع العيوب الأمنية بدلًا من إلزام تنفيذات تقنية محدّدة. والمقصود أن تكون نصوص المتطلبات شارحة لنفسها، موضّحةً سبب وجودها. -* دعم القرارات الأمنية الموثّقة: يقدّم ASVS 5.0 متطلبات لتوثيق القرارات الأمنية الرئيسية. وهذا يعزّز إمكانية التتبّع ويدعم التنفيذات الحسّاسة للسياق، ما يتيح للمؤسسات تكييف وضعها الأمني وفق احتياجاتها ومخاطرها المحدّدة. +* دعم القرارات الأمنية الموثّقة: يقدّم معيار التحقق من أمان التطبيقات 5.0 متطلبات لتوثيق القرارات الأمنية الرئيسية. وهذا يعزّز إمكانية التتبّع ويدعم التنفيذات الحسّاسة للسياق، ما يتيح للمؤسسات تكييف وضعها الأمني وفق احتياجاتها ومخاطرها المحدّدة. -* مستويات محدَّثة: مع أن ASVS يحتفظ بنموذجه ثلاثي الطبقات، فقد تطوّرت تعريفات المستويات لتسهيل تبنّي ASVS. صُمِّم المستوى 1 كخطوة أولى لتبنّي ASVS، موفّرًا الطبقة الأولى من الدفاع. ويمثّل المستوى 2 نظرة شاملة لممارسات الأمان القياسية، أما المستوى 3 فيتناول المتطلبات المتقدّمة عالية التوكيد. +* مستويات محدَّثة: مع أن معيار التحقق من أمان التطبيقات يحتفظ بنموذجه ثلاثي الطبقات، فقد تطوّرت تعريفات المستويات لتسهيل تبنّي معيار التحقق من أمان التطبيقات. صُمِّم المستوى 1 كخطوة أولى لتبنّي معيار التحقق من أمان التطبيقات، موفّرًا الطبقة الأولى من الدفاع. ويمثّل المستوى 2 نظرة شاملة لممارسات الأمان القياسية، أما المستوى 3 فيتناول المتطلبات المتقدّمة عالية التوكيد. -* محتوى مُعاد هيكلته وموسّع: يشتمل ASVS 5.0 على نحو 350 متطلبًا موزّعة على 17 فصلًا. وقد أُعيد تنظيم الفصول لتحقيق الوضوح وسهولة الاستخدام. ويُتاح تخطيط ثنائي الاتجاه بين الإصدارين 4.0 و5.0 لتيسير الانتقال. +* محتوى مُعاد هيكلته وموسّع: يشتمل معيار التحقق من أمان التطبيقات 5.0 على نحو 350 متطلبًا موزّعة على 17 فصلًا. وقد أُعيد تنظيم الفصول لتحقيق الوضوح وسهولة الاستخدام. ويُتاح تخطيط ثنائي الاتجاه بين الإصدارين 4.0 و5.0 لتيسير الانتقال. ## نظرة إلى الأمام -كما أن تأمين التطبيق لا ينتهي حقًا، فكذلك ASVS. ومع أن الإصدار 5.0 إصدار رئيسي، فإن التطوير مستمر. ويتيح هذا الإصدار للمجتمع الأوسع الاستفادة من التحسينات والإضافات التي تراكمت، لكنه يرسي كذلك الأساس لتحسينات مستقبلية. وقد يشمل ذلك جهودًا يقودها المجتمع لإنشاء إرشادات للتنفيذ والتحقق مبنية على مجموعة المتطلبات الأساسية. +كما أن تأمين التطبيق لا ينتهي حقًا، فكذلك معيار التحقق من أمان التطبيقات. ومع أن الإصدار 5.0 إصدار رئيسي، فإن التطوير مستمر. ويتيح هذا الإصدار للمجتمع الأوسع الاستفادة من التحسينات والإضافات التي تراكمت، لكنه يرسي كذلك الأساس لتحسينات مستقبلية. وقد يشمل ذلك جهودًا يقودها المجتمع لإنشاء إرشادات للتنفيذ والتحقق مبنية على مجموعة المتطلبات الأساسية. -صُمِّم ASVS 5.0 ليكون أساسًا موثوقًا لتطوير البرمجيات الآمنة. والمجتمع مدعو إلى تبنّي هذا المعيار والإسهام فيه والبناء عليه للنهوض جماعيًا بحالة أمان التطبيقات. +صُمِّم معيار التحقق من أمان التطبيقات 5.0 ليكون أساسًا موثوقًا لتطوير البرمجيات الآمنة. والمجتمع مدعو إلى تبنّي هذا المعيار والإسهام فيه والبناء عليه للنهوض جماعيًا بحالة أمان التطبيقات. diff --git a/5.0/ar/0x03-What-is-the-ASVS.md b/5.0/ar/0x03-What-is-the-ASVS.md index 925ecb33b6..bb160f51d5 100644 --- a/5.0/ar/0x03-What-is-the-ASVS.md +++ b/5.0/ar/0x03-What-is-the-ASVS.md @@ -1,195 +1,195 @@ -# What is the 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. +يحدّد معيار التحقق من أمان التطبيقات (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. +ويبيّن هذا الفصل الجوانب الجوهرية لاستخدام معيار التحقق من أمان التطبيقات، بما فيها نطاقه وبنية مستوياته القائمة على الأولوية وحالات الاستخدام الرئيسية للمعيار. -## Scope of the 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. +يتحدّد نطاق معيار التحقق من أمان التطبيقات باسمه: التطبيق والأمان والتحقق والمعيار. فهو يرسي أي المتطلبات مُدرجة وأيها مستثناة، مع الهدف الشامل لتحديد المبادئ الأمنية التي يجب تحقيقها. ويراعي النطاق كذلك متطلبات التوثيق، التي تشكّل الأساس لمتطلبات التنفيذ. -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. +ولا وجود لشيء يُسمّى نطاقًا بالنسبة إلى المهاجمين. ولذلك ينبغي تقييم متطلبات معيار التحقق من أمان التطبيقات إلى جانب الإرشادات المتعلقة بجوانب أخرى من دورة حياة التطبيق، بما فيها عمليات التكامل والتسليم المستمرين (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. +يُعرّف معيار التحقق من أمان التطبيقات "التطبيق" بأنه المنتج البرمجي قيد التطوير، الذي يجب دمج ضوابط الأمان فيه. ولا يفرض معيار التحقق من أمان التطبيقات أنشطة دورة حياة التطوير ولا يحدّد كيفية بناء التطبيق عبر خط 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 أو تعدّلها أو تتحقق منها، مثل جدران حماية تطبيقات الويب (WAFs) أو موازنات الحمل أو الوكلاء، جزءًا من التطبيق لتلك الأغراض بعينها، إذ تعتمد بعض ضوابط الأمان عليها مباشرةً أو يمكن تنفيذها من خلالها. وينبغي مراعاة هذه المكوّنات في المتطلبات المتعلقة بالاستجابات المخزَّنة مؤقتًا أو تحديد المعدّل أو تقييد الاتصالات الواردة والصادرة بناءً على المصدر والمقصد. -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. +وفي المقابل، يستثني معيار التحقق من أمان التطبيقات عمومًا المتطلبات التي ليست ذات صلة مباشرة بالتطبيق أو التي يكون تكوينها خارج مسؤولية التطبيق. على سبيل المثال، تُدار مشكلات نظام أسماء النطاقات (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. +وبالمثل، مع أن التطبيق مسؤول عن كيفية استهلاكه للمدخلات وإنتاجه للمخرجات، فإذا تفاعلت عملية خارجية مع التطبيق أو بياناته، فإنها تُعدّ خارج نطاق معيار التحقق من أمان التطبيقات. فعلى سبيل المثال، يكون النسخ الاحتياطي للتطبيق أو لبياناته عادةً مسؤولية عملية خارجية ولا يتحكّم فيه التطبيق أو مطوّروه. -### 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. +يجب أن يكون لكل متطلب أثر ملموس على الأمان. ويجب أن يؤدي غياب المتطلب إلى تطبيق أقل أمانًا، ويجب أن يقلّل تنفيذ المتطلب إما احتمال وقوع خطر أمني أو أثره. -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. +يجب أن يكون المتطلب قابلًا للتحقق، ويجب أن يؤدي التحقق إلى قرار "فشل" أو "نجاح". -### 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. +صُمِّم معيار التحقق من أمان التطبيقات ليكون مجموعة من المتطلبات الأمنية التي يجب تنفيذها للامتثال للمعيار. ويعني ذلك أن المتطلبات تقتصر على تحديد الهدف الأمني الذي ينبغي تحقيقه. ويمكن بناء المعلومات الأخرى ذات الصلة فوق معيار التحقق من أمان التطبيقات أو ربطها به عبر التخطيطات. -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 مشاريع كثيرة، ويتجنّب معيار التحقق من أمان التطبيقات متعمّدًا التداخل مع محتوى المشاريع الأخرى. فعلى سبيل المثال، قد يكون لدى المطوّرين سؤال: "كيف أنفّذ متطلبًا معيّنًا في تقنيتي أو بيئتي بعينها"، وهذا ينبغي أن يغطّيه مشروع 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. +ومع أن معيار التحقق من أمان التطبيقات ليس موجّهًا لاستخدام خبراء الأمان وحدهم، فإنه يتوقع من القارئ أن يمتلك معرفة تقنية لفهم المحتوى أو القدرة على البحث في مفاهيم بعينها. -### 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. +تُستخدم كلمة متطلب في معيار التحقق من أمان التطبيقات على وجه التحديد لأنها تصف ما يجب تحقيقه لاستيفائه. ولا يحتوي معيار التحقق من أمان التطبيقات إلا على متطلبات (يجب) ولا يحتوي على توصيات (ينبغي) كشرط رئيسي. -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. +والمقصود من متطلبات معيار التحقق من أمان التطبيقات تناول مبادئ أمنية محدّدة دون أن تكون شديدة الخصوصية بالتنفيذ أو التقنية، وأن تكون في الوقت نفسه شارحة لنفسها فيما يخص سبب وجودها. ويعني ذلك كذلك أن المتطلبات ليست مبنية حول طريقة تحقق أو تنفيذ بعينها. -### 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. +وإضافةً إلى ذلك، سيكون التنفيذ في بعض المتطلبات معقّدًا وخاصًا جدًا باحتياجات التطبيق. ومن الأمثلة الشائعة الصلاحيات والتحقق من صحة المدخلات والضوابط الحمائية حول مستويات مختلفة من البيانات الحساسة. -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. +وهناك محرّكان رئيسيان لإدراج هذه المتطلبات. المحرّك الأول أن المتطلب الأمني كثيرًا ما يتضمّن إنفاذ قواعد، مثل أنواع الملفات المسموح بتحميلها، وضوابط العمل التي ينبغي إنفاذها، والمحارف المسموح بها في حقل معيّن. وستختلف هذه القواعد في كل تطبيق، ولذلك لا يستطيع معيار التحقق من أمان التطبيقات أن يحدّد إلزاميًا ما ينبغي أن تكون عليه، ولن تفيد ورقة مرجعية أو استجابة أكثر تفصيلًا في هذه الحالة. وبالمثل، فمن دون توثيق هذه القرارات، لن يكون من الممكن إجراء تحقق من المتطلبات التي تنفّذها. -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. +والمحرّك الثاني أنه من المهم، في متطلبات معيّنة، منح جهة تطوير التطبيق مرونة بشأن كيفية تناول تحديات أمنية بعينها. فعلى سبيل المثال، كانت قواعد مهلة الجلسة في إصدارات معيار التحقق من أمان التطبيقات السابقة إلزامية جدًا. ومن الناحية العملية، لدى تطبيقات كثيرة، وخصوصًا الموجّهة إلى المستهلكين، قواعد أكثر تسامحًا بكثير وتفضّل تنفيذ ضوابط تخفيف أخرى بدلًا من ذلك. ولذلك تتيح متطلبات التوثيق مرونة صريحة في هذا الشأن. -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. +إن تزويد المطوّرين بمواصفات وتصاميم للميزات والوظائف الجديدة جزء معتاد من تطوير البرمجيات. وبالمثل، يُتوقع من المطوّرين استخدام مكوّنات وآليات واجهة مستخدم مشتركة بدلًا من مجرّد اتخاذ قراراتهم الخاصة كل مرة. ولذلك لا ينبغي أن يُنظر إلى توسيع ذلك ليشمل الأمان كأمر مفاجئ أو مثير للجدل. -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. +يحدّد معيار التحقق من أمان التطبيقات ثلاثة مستويات للتحقق الأمني، يتزايد كل مستوى منها في العمق والتعقيد. والهدف العام أن تبدأ المؤسسات بالمستوى الأول لتناول أهم الاعتبارات الأمنية، ثم تنتقل إلى المستويات الأعلى وفق احتياجات المؤسسة والتطبيق. وقد تُعرض المستويات في المستند وفي نصوص المتطلبات بالصور 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. +ويشير كل مستوى في معيار التحقق من أمان التطبيقات إلى المتطلبات الأمنية اللازم تحقيقها من ذلك المستوى، مع اعتبار متطلبات المستويات الأعلى المتبقية توصيات. -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. +ويراعي تقليل المخاطر مدى تقليل المتطلب لمستوى الخطر الأمني في التطبيق، مع مراعاة عوامل الأثر الكلاسيكية للسرية والسلامة والتوافر، وكذلك النظر في ما إذا كان هذا طبقة دفاع أولية أو يُعدّ دفاعًا في العمق. -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. +يحتوي هذا المستوى على الحد الأدنى من المتطلبات التي ينبغي مراعاتها عند تأمين تطبيق، ويمثّل نقطة انطلاق بالغة الأهمية. ويحتوي هذا المستوى على نحو 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، إذ تصبح متطلبات المصادقة متعددة العوامل ذات صلة من المستويات الأعلى. -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. +ينبغي أن تسعى معظم التطبيقات إلى تحقيق هذا المستوى من الأمان. فنحو 50% من متطلبات معيار التحقق من أمان التطبيقات هي من المستوى 2، ما يعني أن التطبيق يحتاج إلى تنفيذ نحو 70% من متطلبات معيار التحقق من أمان التطبيقات (جميع متطلبات المستويين 1 و2) للامتثال للمستوى 2. -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. +المقصود من المستويات القائمة على الأولوية أن توفّر انعكاسًا لنضج أمان التطبيقات في المؤسسة وفي التطبيق. وبدلًا من أن ينص معيار التحقق من أمان التطبيقات إلزاميًا على المستوى الذي ينبغي أن يكون التطبيق عليه، ينبغي للمؤسسة أن تحلّل مخاطرها وتقرّر المستوى الذي تعتقد أنه ينبغي أن تكون عليه، بحسب حساسية التطبيق، وبالطبع، توقعات مستخدمي التطبيق. -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 +## كيفية استخدام معيار التحقق من أمان التطبيقات -### The structure of the 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. +يتكوّن معيار التحقق من أمان التطبيقات من نحو 350 متطلبًا إجمالًا مقسّمة على 17 فصلًا، كل منها مقسّم كذلك إلى أقسام. -The aim of the chapter and section division is to simplify choosing or filtering out chapters and sections based on the 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. +والهدف من تقسيم الفصول والأقسام تبسيط اختيار الفصول والأقسام أو تصفيتها بناءً على ما هو ذو صلة بالتطبيق. فعلى سبيل المثال، بالنسبة إلى واجهة برمجة تطبيقات من آلة إلى آلة، لن تكون المتطلبات في الفصل 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. +تتبع إصدارات معيار التحقق من أمان التطبيقات النمط "رئيسي.ثانوي.ترقيعي"، وتوفّر الأرقام معلومات عمّا تغيّر في الإصدار. ففي الإصدار الرئيسي يتغيّر الرقم الأول، وفي الإصدار الثانوي يتغيّر الرقم الثاني، وفي الإصدار الترقيعي يتغيّر الرقم الثالث. -* 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. +وينطبق ما سبق تحديدًا على المتطلبات في معيار التحقق من أمان التطبيقات. أما التغييرات في النص المحيط وغيره من المحتوى مثل الملاحق فلن تُعدّ تغييرًا قاطعًا للتوافق. -### Flexibility with the 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. +توفّر عدة نقاط من الموصوفة أعلاه، مثل متطلبات التوثيق وآلية المستويات، القدرة على استخدام معيار التحقق من أمان التطبيقات بطريقة أكثر مرونة وأكثر خصوصية بالمؤسسة. -Additionally, organizations are strongly encouraged to create an organization- or domain-specific fork that adjusts requirements based on the specific characteristics and risk levels of their applications. However, it is important to maintain traceability so that passing requirement 4.1.1 means the same across all versions. +وإضافةً إلى ذلك، تُشجَّع المؤسسات بقوة على إنشاء نسخة متفرّعة خاصة بالمؤسسة أو بالمجال تعدّل المتطلبات بناءً على الخصائص ومستويات المخاطر المحدّدة لتطبيقاتها. لكن من المهم الحفاظ على إمكانية التتبّع بحيث يعني استيفاء المتطلب 4.1.1 الشيء نفسه في جميع الإصدارات. -Ideally, each organization should create its own tailored ASVS, omitting irrelevant sections (e.g., GraphQL, WebSockets, SOAP, if unused). An organization-specific ASVS version or supplement is also a good place to provide organization-specific implementation guidance, detailing libraries or resources to use when complying with requirements. +ومن الأفضل أن تنشئ كل مؤسسة نسخة معيار التحقق من أمان التطبيقات مُصمَّمة لها، مع حذف الأقسام غير ذات الصلة (مثل GraphQL وWebSockets وSOAP إذا لم تكن مستخدمة). كما أن نسخة معيار التحقق من أمان التطبيقات الخاصة بالمؤسسة أو ملحقها موضع جيد كذلك لتقديم إرشادات تنفيذ خاصة بالمؤسسة، تبيّن المكتبات أو الموارد التي ينبغي استخدامها عند الامتثال للمتطلبات. -### How to Reference ASVS Requirements +### كيفية الإشارة إلى متطلبات معيار التحقق من أمان التطبيقات -Each requirement has an identifier in the format `.
.`, where each element is a number. For example, `1.11.3`. +لكل متطلب معرّف بالصيغة `.
.`، حيث كل عنصر رقم. على سبيل المثال، `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.#.#` هي من فصل 'الترميز والتنقية'. +* تقابل قيمة `
` القسم داخل ذلك الفصل الذي يظهر فيه المتطلب، فعلى سبيل المثال: جميع المتطلبات `1.2.#` هي في قسم 'منع الحقن' من فصل 'الترميز والتنقية'. +* تحدّد قيمة `` المتطلب بعينه داخل الفصل والقسم، فعلى سبيل المثال `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. +> تحقق من أن التطبيق يحمي من حقن أوامر نظام التشغيل ومن أن استدعاءات نظام التشغيل تستخدم استعلامات مُمعَّمة لنظام التشغيل أو تستخدم ترميزًا سياقيًا لمخرجات سطر الأوامر. -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-.
.`، حيث 'الإصدار' هو وسم إصدار معيار التحقق من أمان التطبيقات. على سبيل المثال: يُفهم من `v5.0.0-1.2.5` أنه يعني تحديدًا المتطلب الخامس في قسم 'منع الحقن' من فصل 'الترميز والتنقية' من الإصدار 5.0.0. (ويمكن تلخيص ذلك بالصورة `v-`.) -Note: The `v` preceding the version number in the format should always be lowercase. +ملاحظة: ينبغي أن يكون الحرف `v` السابق لرقم الإصدار في هذه الصيغة بحرف صغير دائمًا. -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. +وتُتاح قوائم متطلبات معيار التحقق من أمان التطبيقات بصيغ CSV وJSON وغيرها، وقد تكون مفيدة للرجوع إليها أو للاستخدام البرمجي. -### Forking the 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. +يمكن للمؤسسات أن تستفيد من تبنّي معيار التحقق من أمان التطبيقات باختيار أحد المستويات الثلاثة أو بإنشاء نسخة متفرّعة خاصة بالمجال تعدّل المتطلبات بحسب مستوى مخاطر التطبيق. وهذا النوع من التفريع مُشجَّع، بشرط أن يحافظ على إمكانية التتبّع بحيث يعني استيفاء المتطلب 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. +ومن الأفضل أن تنشئ كل مؤسسة نسخة معيار التحقق من أمان التطبيقات مُصمَّمة لها، مع حذف الأقسام غير ذات الصلة (مثل GraphQL وWebsockets وSOAP إذا لم تكن مستخدمة). وينبغي أن يبدأ التفريع بالمستوى 1 من معيار التحقق من أمان التطبيقات كخط أساس، ثم التقدّم إلى المستويين 2 أو 3 بناءً على مخاطر التطبيق. -## Use cases for the 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. +يمكن استخدام معيار التحقق من أمان التطبيقات لتقييم أمان تطبيق، وهذا مستقصى بعمق أكبر في الفصل التالي. لكن هناك عدة استخدامات محتملة أخرى لمعيار التحقق من أمان التطبيقات (أو لنسخة متفرّعة منه) قد حُدّدت. -### 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 archiecture, 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. +من الاستخدامات الأكثر شيوعًا لمعيار التحقق من أمان التطبيقات استخدامه كمورد لمعماريي الأمان. فالموارد المتاحة عن كيفية بناء معمارية تطبيق آمنة محدودة، وخصوصًا مع التطبيقات الحديثة. ويمكن استخدام معيار التحقق من أمان التطبيقات لسدّ هذه الفجوات بتمكين معماريي الأمان من اختيار ضوابط أفضل للمشكلات الشائعة، مثل أنماط حماية البيانات واستراتيجيات التحقق من صحة المدخلات. وستكون متطلبات المعمارية والتوثيق مفيدة لذلك على وجه الخصوص. -### 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, prganizations 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. +يمكن استخدام معيار التحقق من أمان التطبيقات كأساس لإعداد مرجع للبرمجة الآمنة أثناء تطوير التطبيقات، بما يساعد المطوّرين على التأكد من أنهم يضعون الأمان في اعتبارهم عند بناء البرمجيات. ومع أن معيار التحقق من أمان التطبيقات يمكن أن يكون الأساس، فينبغي للمؤسسات إعداد إرشاداتها الخاصة التي تكون واضحة وموحّدة، ومن الأفضل أن تُعدّ بناءً على توجيه من مهندسي الأمان أو معماريي الأمان. وكامتداد لذلك، تُشجَّع المؤسسات، حيثما أمكن، على إعداد آليات ومكتبات أمنية معتمدة يمكن الإشارة إليها في الإرشادات واستخدامها من قِبل المطوّرين. -### 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. +صُمِّم معيار التحقق من أمان التطبيقات ليكون قابلًا للاختبار بدرجة عالية. وستكون بعض عمليات التحقق تقنية، في حين قد تتطلّب متطلبات أخرى (مثل متطلبات المعمارية والتوثيق) مراجعة للوثائق أو للمعمارية. وببناء اختبارات وحدة وتكامل تختبر وتُشوّش حالات إساءة استخدام محدّدة وذات صلة بالمتطلبات القابلة للتحقق بوسائل تقنية، ينبغي أن يكون أسهل التحقق من أن هذه الضوابط تعمل على نحو صحيح في كل عملية بناء. فعلى سبيل المثال، يمكن صياغة اختبارات إضافية لمجموعة اختبارات متحكّم تسجيل الدخول، لاختبار معامل اسم المستخدم بحثًا عن أسماء المستخدمين الافتراضية الشائعة وتعداد الحسابات والقوة الغاشمة وحقن LDAP وSQL والبرمجة النصية عبر المواقع. وبالمثل، ينبغي أن يشمل اختبار معامل كلمة المرور كلمات المرور الشائعة وطول كلمة المرور وحقن البايت الفارغ وإزالة المعامل والبرمجة النصية عبر المواقع وغير ذلك. -### 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. +يمكن استخدام معيار التحقق من أمان التطبيقات كذلك لتحديد خصائص البرمجيات الآمنة. فكثير من دورات "البرمجة الآمنة" هي مجرّد دورات في الاختراق الأخلاقي مع مسحة خفيفة من نصائح البرمجة. وقد لا يساعد ذلك بالضرورة المطوّرين على كتابة شيفرة أكثر أمانًا. وبدلًا من ذلك، يمكن لدورات التطوير الآمن أن تستخدم معيار التحقق من أمان التطبيقات مع تركيز قوي على الآليات الإيجابية الموجودة فيه، بدلًا من التركيز على الأشياء السلبية العشرة الأولى التي لا ينبغي فعلها. كما أن بنية معيار التحقق من أمان التطبيقات توفّر بنية منطقية للتنقّل بين المواضيع المختلفة عند تأمين تطبيق. -### 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. +يُعدّ معيار التحقق من أمان التطبيقات إطارًا ممتازًا للمساعدة في شراء البرمجيات الآمنة أو شراء خدمات تطوير مخصّصة. فيمكن للمشتري ببساطة أن يضع متطلبًا بأن البرمجية التي يرغب في شرائها يجب أن تكون مطوّرة بمستوى معيار التحقق من أمان التطبيقات س، وأن يطلب من البائع إثبات أن البرمجية تستوفي مستوى معيار التحقق من أمان التطبيقات س. -## Applying ASVS in Practice +## تطبيق معيار التحقق من أمان التطبيقات عمليًا -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. +وتُشجَّع المؤسسات بقوة على النظر بعمق في خصائص مخاطرها الفريدة بناءً على طبيعة عملها، وأن تحدّد بناءً على تلك المخاطر ومتطلبات العمل مستوى معيار التحقق من أمان التطبيقات الملائم. diff --git a/5.0/ar/0x04-Assessment_and_Certification.md b/5.0/ar/0x04-Assessment_and_Certification.md index d4af46ff78..f36d0c4e13 100644 --- a/5.0/ar/0x04-Assessment_and_Certification.md +++ b/5.0/ar/0x04-Assessment_and_Certification.md @@ -1,18 +1,18 @@ # التقييم وإصدار الشهادات -## موقف OWASP من شهادات ASVS وعلامات الثقة +## موقف OWASP من شهادات معيار التحقق من أمان التطبيقات وعلامات الثقة -إن OWASP، كمؤسسة غير ربحية محايدة تجاه المورّدين، لا تمنح شهادات لأي مورّدين أو مدقّقين أو برمجيات. وأي توكيد أو علامة ثقة أو شهادة تدّعي الامتثال لـ ASVS ليست معتمدة رسميًا من OWASP، ولذلك ينبغي للمؤسسات أن تتوخى الحذر من ادعاءات الأطراف الثالثة بالحصول على شهادة ASVS. +إن OWASP، كمؤسسة غير ربحية محايدة تجاه المورّدين، لا تمنح شهادات لأي مورّدين أو مدقّقين أو برمجيات. وأي توكيد أو علامة ثقة أو شهادة تدّعي الامتثال لمعيار التحقق من أمان التطبيقات ليست معتمدة رسميًا من OWASP، ولذلك ينبغي للمؤسسات أن تتوخى الحذر من ادعاءات الأطراف الثالثة بالحصول على شهادة معيار التحقق من أمان التطبيقات. ويمكن للمؤسسات أن تقدّم خدمات توكيد، بشرط ألا تدّعي حصولها على شهادة رسمية من OWASP. -## كيفية التحقق من الامتثال لـ ASVS +## كيفية التحقق من الامتثال لمعيار التحقق من أمان التطبيقات -إن ASVS ليس إلزاميًا بشكل متعمّد بخصوص الطريقة الدقيقة للتحقق من الامتثال على مستوى دليل اختبار. ومع ذلك، من المهم إبراز بعض النقاط الرئيسية. +إن معيار التحقق من أمان التطبيقات ليس إلزاميًا بشكل متعمّد بخصوص الطريقة الدقيقة للتحقق من الامتثال على مستوى دليل اختبار. ومع ذلك، من المهم إبراز بعض النقاط الرئيسية. ### إعداد تقارير التحقق -تُبلِّغ تقارير اختبار الاختراق التقليدية عن المشكلات "على سبيل الاستثناء"، فتسرد حالات الفشل فقط. أما تقرير شهادة ASVS فينبغي أن يشتمل على النطاق، وملخّص لجميع المتطلبات التي فُحصت، والمتطلبات التي رُصدت فيها استثناءات، وإرشادات لمعالجة المشكلات. وقد تكون بعض المتطلبات غير منطبقة (مثل إدارة الجلسات في واجهات برمجة التطبيقات عديمة الحالة)، ويجب الإشارة إلى ذلك في التقرير. +تُبلِّغ تقارير اختبار الاختراق التقليدية عن المشكلات "على سبيل الاستثناء"، فتسرد حالات الفشل فقط. أما تقرير شهادة معيار التحقق من أمان التطبيقات فينبغي أن يشتمل على النطاق، وملخّص لجميع المتطلبات التي فُحصت، والمتطلبات التي رُصدت فيها استثناءات، وإرشادات لمعالجة المشكلات. وقد تكون بعض المتطلبات غير منطبقة (مثل إدارة الجلسات في واجهات برمجة التطبيقات عديمة الحالة)، ويجب الإشارة إلى ذلك في التقرير. ### نطاق التحقق @@ -24,17 +24,17 @@ ### آليات التحقق -هناك عدد من التقنيات المختلفة التي قد تكون لازمة للتحقق من متطلبات ASVS المحدّدة. وإلى جانب اختبار الاختراق (باستخدام بيانات اعتماد صحيحة للحصول على تغطية كاملة للتطبيق)، قد يتطلّب التحقق من متطلبات ASVS الوصول إلى الوثائق والشيفرة المصدرية والتكوين والأشخاص المشاركين في عملية التطوير. وخصوصًا للتحقق من متطلبات المستويين 2 و3. ومن الممارسات المتّبعة تقديم أدلة قوية على النتائج مع توثيق مفصّل، قد يشمل أوراق العمل ولقطات الشاشة والنصوص البرمجية وسجلات الاختبار. ولا يكفي مجرّد تشغيل أداة مؤتمتة دون اختبار شامل للحصول على الشهادة، إذ يجب اختبار كل متطلب على نحو قابل للتحقق. +هناك عدد من التقنيات المختلفة التي قد تكون لازمة للتحقق من متطلبات معيار التحقق من أمان التطبيقات المحدّدة. وإلى جانب اختبار الاختراق (باستخدام بيانات اعتماد صحيحة للحصول على تغطية كاملة للتطبيق)، قد يتطلّب التحقق من متطلبات معيار التحقق من أمان التطبيقات الوصول إلى الوثائق والشيفرة المصدرية والتكوين والأشخاص المشاركين في عملية التطوير. وخصوصًا للتحقق من متطلبات المستويين 2 و3. ومن الممارسات المتّبعة تقديم أدلة قوية على النتائج مع توثيق مفصّل، قد يشمل أوراق العمل ولقطات الشاشة والنصوص البرمجية وسجلات الاختبار. ولا يكفي مجرّد تشغيل أداة مؤتمتة دون اختبار شامل للحصول على الشهادة، إذ يجب اختبار كل متطلب على نحو قابل للتحقق. -إن استخدام الأتمتة للتحقق من متطلبات ASVS موضوع يثير الاهتمام باستمرار. ولذلك من المهم توضيح بعض النقاط المتعلقة بالاختبار المؤتمت واختبار الصندوق الأسود. +إن استخدام الأتمتة للتحقق من متطلبات معيار التحقق من أمان التطبيقات موضوع يثير الاهتمام باستمرار. ولذلك من المهم توضيح بعض النقاط المتعلقة بالاختبار المؤتمت واختبار الصندوق الأسود. #### دور أدوات اختبار الأمان المؤتمتة عندما تُنفَّذ أدوات اختبار الأمان المؤتمتة، مثل أدوات الاختبار الديناميكي والساكن لأمان التطبيقات (DAST وSAST)، تنفيذًا صحيحًا في خط بناء البرمجيات، فقد تتمكّن من تحديد بعض المشكلات الأمنية التي لا ينبغي أن توجد أبدًا. لكنها من دون تكوين وضبط دقيقين لن توفّر التغطية المطلوبة، وسيمنع مستوى الضجيج تحديد المشكلات الأمنية الحقيقية والتخفيف منها. -ومع أن ذلك قد يوفّر تغطية لبعض المتطلبات التقنية الأبسط والأكثر مباشرة، مثل تلك المتعلقة بترميز المخرجات أو التنقية، فمن الأهمية البالغة ملاحظة أن هذه الأدوات ستكون عاجزة تمامًا عن التحقق من كثير من متطلبات ASVS الأكثر تعقيدًا أو تلك المتعلقة بمنطق العمل والتحكم في الوصول. +ومع أن ذلك قد يوفّر تغطية لبعض المتطلبات التقنية الأبسط والأكثر مباشرة، مثل تلك المتعلقة بترميز المخرجات أو التنقية، فمن الأهمية البالغة ملاحظة أن هذه الأدوات ستكون عاجزة تمامًا عن التحقق من كثير من متطلبات معيار التحقق من أمان التطبيقات الأكثر تعقيدًا أو تلك المتعلقة بمنطق العمل والتحكم في الوصول. -وبالنسبة إلى المتطلبات الأقل مباشرة، من المرجّح أنه لا يزال بالإمكان الاستفادة من الأتمتة، لكن سيتعيّن كتابة عمليات تحقق خاصة بالتطبيق لتحقيق ذلك. وقد تكون هذه مشابهة لاختبارات الوحدة والتكامل التي ربما تستخدمها المؤسسة بالفعل. ولذلك قد يكون من الممكن استخدام هذه البنية التحتية القائمة لأتمتة الاختبارات في كتابة اختبارات ASVS هذه. ومع أن القيام بذلك سيتطلّب استثمارًا قصير الأجل، فإن الفوائد طويلة الأجل للقدرة على التحقق المستمر من متطلبات ASVS هذه ستكون كبيرة. +وبالنسبة إلى المتطلبات الأقل مباشرة، من المرجّح أنه لا يزال بالإمكان الاستفادة من الأتمتة، لكن سيتعيّن كتابة عمليات تحقق خاصة بالتطبيق لتحقيق ذلك. وقد تكون هذه مشابهة لاختبارات الوحدة والتكامل التي ربما تستخدمها المؤسسة بالفعل. ولذلك قد يكون من الممكن استخدام هذه البنية التحتية القائمة لأتمتة الاختبارات في كتابة اختبارات معيار التحقق من أمان التطبيقات هذه. ومع أن القيام بذلك سيتطلّب استثمارًا قصير الأجل، فإن الفوائد طويلة الأجل للقدرة على التحقق المستمر من متطلبات معيار التحقق من أمان التطبيقات هذه ستكون كبيرة. وخلاصة القول، القابلية للاختبار باستخدام الأتمتة لا تساوي تشغيل أداة جاهزة. @@ -44,4 +44,4 @@ إن الاختبار دون الوصول إلى المعلومات الإضافية اللازمة آلية غير كفؤة وغير فعّالة للتحقق الأمني، إذ يفوّت إمكانية مراجعة الشيفرة المصدرية وتحديد التهديدات والضوابط المفقودة وإجراء اختبار أكثر شمولًا بكثير في إطار زمني أقصر. -ويُشجَّع بقوة على إجراء اختبار اختراق مبني على الوثائق أو الشيفرة المصدرية (هجين)، يتيح وصولًا كاملًا إلى مطوّري التطبيق ووثائق التطبيق، بدلًا من اختبارات الاختراق التقليدية. وسيكون ذلك ضروريًا بالتأكيد للتحقق من كثير من متطلبات ASVS. +ويُشجَّع بقوة على إجراء اختبار اختراق مبني على الوثائق أو الشيفرة المصدرية (هجين)، يتيح وصولًا كاملًا إلى مطوّري التطبيق ووثائق التطبيق، بدلًا من اختبارات الاختراق التقليدية. وسيكون ذلك ضروريًا بالتأكيد للتحقق من كثير من متطلبات معيار التحقق من أمان التطبيقات. diff --git a/5.0/ar/0x05-For-Users-Of-4.0.md b/5.0/ar/0x05-For-Users-Of-4.0.md index 736f8a1c1f..5dac810404 100644 --- a/5.0/ar/0x05-For-Users-Of-4.0.md +++ b/5.0/ar/0x05-For-Users-Of-4.0.md @@ -49,7 +49,7 @@ ## إزالة التخطيطات المباشرة إلى المعايير الأخرى -أُزيلت التخطيطات المباشرة إلى المعايير الأخرى من المتن الرئيسي للمعيار. والهدف إعداد تخطيط مع مشروع تعداد المتطلبات المشتركة (CRE) الخاص بـ OWASP، والذي سيربط بدوره ASVS بمجموعة من مشاريع OWASP والمعايير الخارجية. +أُزيلت التخطيطات المباشرة إلى المعايير الأخرى من المتن الرئيسي للمعيار. والهدف إعداد تخطيط مع مشروع تعداد المتطلبات المشتركة (CRE) الخاص بـ OWASP، والذي سيربط بدوره معيار التحقق من أمان التطبيقات بمجموعة من مشاريع OWASP والمعايير الخارجية. ولم تعد التخطيطات المباشرة إلى CWE وNIST مُصانة، على النحو الموضّح أدناه. diff --git a/5.0/ar/0x15-V6-Authentication.md b/5.0/ar/0x15-V6-Authentication.md index d9fa0025ad..745954e380 100644 --- a/5.0/ar/0x15-V6-Authentication.md +++ b/5.0/ar/0x15-V6-Authentication.md @@ -1,159 +1,159 @@ -# 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. +المصادقة هي عملية إرساء أو تأكيد أصالة فرد أو جهاز. وهي تتضمّن التحقق من المطالبات التي يقدّمها شخص أو التي تُقدَّم عن جهاز، وضمان المقاومة لانتحال الهوية، ومنع استعادة كلمات المرور أو اعتراضها. -[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 "إرشادات الهوية الرقمية - المصادقة وإدارة دورة الحياة")، فإن الفصل يركّز على التهديدات الشائعة ونقاط ضعف المصادقة الشائعة الاستغلال. وهو لا يحاول تغطية كل نقطة في المعيار تغطيةً شاملة. وللحالات التي يكون فيها الامتثال الكامل لـ 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. +ومن السمات الشائعة في التطبيقات الأكثر تقدّمًا القدرة على تكييف مراحل المصادقة المطلوبة بناءً على عوامل مخاطر متنوعة. وهذه السمة مشمولة في فصل "التخويل"، إذ يلزم مراعاة هذه الآليات في قرارات التخويل كذلك. -## 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** | تحقق من أن وثائق التطبيق تحدّد كيفية استخدام ضوابط مثل تحديد المعدّل ومكافحة الأتمتة والاستجابة التكيّفية للدفاع عن هجمات مثل حشو بيانات الاعتماد والقوة الغاشمة على كلمات المرور. ويجب أن توضّح الوثائق كيفية تهيئة هذه الضوابط ومنع الإغلاق الخبيث للحسابات. | 1 | +| **6.1.2** | تحقق من توثيق قائمة بالكلمات الخاصة بالسياق لمنع استخدامها في كلمات المرور. وقد تشتمل القائمة على تصاريف أسماء المؤسسة وأسماء المنتجات ومعرّفات الأنظمة والأسماء الرمزية للمشاريع وأسماء الأقسام أو الأدوار وما شابهها. | 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 "الأسرار المحفوظة"، تشمل كلمات المرور وعبارات المرور وأرقام التعريف الشخصية وأنماط إلغاء القفل واختيار الهُريرة الصحيحة أو عنصر صورة آخر. وتُعدّ عمومًا "شيئًا تعرفه" وتُستخدم غالبًا كآلية مصادقة أحادية العامل. -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. +ولذلك يحتوي هذا القسم على متطلبات للتأكد من إنشاء كلمات المرور والتعامل معها بأمان. ومعظم المتطلبات من المستوى 1 لأنها أكثر أهمية في ذلك المستوى. ومن المستوى 2 وما بعده، تكون آليات المصادقة متعددة العوامل مطلوبة، وقد تكون كلمات المرور أحد تلك العوامل. -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). +وتتعلق المتطلبات في هذا القسم في معظمها بـ [§ 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver) من [إرشادات NIST](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | 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** | تحقق من أن حقول إدخال كلمة المرور تستخدم type=password لإخفاء الإدخال. وقد تسمح التطبيقات للمستخدم بعرض كلمة المرور المخفية بالكامل مؤقتًا، أو آخر محرف مكتوب منها. | 1 | +| **6.2.7** | تحقق من السماح بوظيفة "اللصق" ومساعدات كلمات المرور في المتصفح ومديري كلمات المرور الخارجيين. | 1 | +| **6.2.8** | تحقق من أن التطبيق يتحقق من كلمة مرور المستخدم كما استُلمت منه بالضبط، دون أي تعديلات مثل الاقتطاع أو تحويل حالة الأحرف. | 1 | +| **6.2.9** | تحقق من السماح بكلمات مرور لا يقل طولها عن 64 محرفًا. | 2 | +| **6.2.10** | تحقق من أن كلمة مرور المستخدم تبقى صالحة حتى يُكتشف أنها مخترقة أو يبدّلها المستخدم. ويجب ألا يشترط التطبيق تدويرًا دوريًا لبيانات الاعتماد. | 2 | +| **6.2.11** | تحقق من استخدام القائمة الموثّقة للكلمات الخاصة بالسياق لمنع إنشاء كلمات مرور سهلة التخمين. | 2 | +| **6.2.12** | تحقق من أن كلمات المرور المُقدَّمة أثناء تسجيل الحساب أو تغييرها تُفحص مقابل مجموعة من كلمات المرور المسرّبة. | 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. +يحتوي هذا القسم على متطلبات عامة لأمان آليات المصادقة، وكذلك على بيان التوقعات المختلفة للمستويات. فيجب على تطبيقات المستوى 2 أن تُلزم باستخدام المصادقة متعددة العوامل (MFA). ويجب على تطبيقات المستوى 3 أن تستخدم مصادقة قائمة على العتاد، تُنفَّذ في بيئة تنفيذ موثوقة ومُصدَّقة (TEE). وقد يشمل ذلك مفاتيح المرور المرتبطة بالجهاز، أو مُصادِقات مُنفَذة بمستوى توكيد عالٍ وفق eIDAS (LoA High)، أو مُصادِقات بمستوى توكيد المُصادِق الثالث وفق NIST (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. +ومع أن هذا موقف صارم نسبيًا بشأن المصادقة متعددة العوامل، فمن الأهمية البالغة رفع مستوى الصعوبة في هذا الشأن لحماية المستخدمين، وينبغي أن تكون أي محاولة لتخفيف هذه المتطلبات مصحوبة بخطة واضحة عن كيفية التخفيف من المخاطر المتعلقة بالمصادقة، مع مراعاة إرشادات 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** | تحقق من أنه يجب استخدام إما آلية مصادقة متعددة العوامل أو تركيبة من آليات المصادقة أحادية العامل للوصول إلى التطبيق. وبالنسبة إلى المستوى 3، يجب أن يكون أحد العوامل آلية مصادقة قائمة على العتاد توفّر مقاومة للاختراق وانتحال الهوية أمام هجمات التصيّد، مع التحقق من نية المصادقة باشتراط إجراء يبدأه المستخدم (مثل الضغط على زر في مفتاح 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. +قد تشمل عوامل المصادقة كلمات المرور والرموز البرمجية والرموز العتادية وأجهزة القياسات الحيوية. والتعامل الآمن مع دورة حياة هذه الآليات بالغ الأهمية لأمان التطبيق، ويشتمل هذا القسم على متطلبات متعلقة بذلك. -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). +وتتعلق المتطلبات في هذا القسم في معظمها بـ [§ 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) من [إرشادات NIST](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | 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** | تحقق من أن كلمات المرور الأولية أو رموز التنشيط التي يولّدها النظام تُولَّد عشوائيًا بأمان، وتتّبع سياسة كلمات المرور القائمة، وتنتهي صلاحيتها بعد فترة قصيرة أو بعد استخدامها أول مرة. ويجب ألا يُسمح لهذه الأسرار الأولية بأن تصبح كلمة المرور طويلة الأجل. | 1 | +| **6.4.2** | تحقق من عدم وجود تلميحات لكلمات المرور أو مصادقة قائمة على المعرفة (ما يُسمّى "الأسئلة السرّية"). | 1 | +| **6.4.3** | تحقق من تنفيذ عملية آمنة لإعادة تعيين كلمة مرور منسيّة، لا تتجاوز أي آليات مصادقة متعددة العوامل مُمكَّنة. | 2 | +| **6.4.4** | تحقق من أنه، في حال فقدان أحد عوامل المصادقة متعددة العوامل، يُجرى إثبات للهوية بالمستوى نفسه المتّبع أثناء التسجيل. | 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 +* أسرار البحث +* كلمات المرور لمرة واحدة المعتمدة على الوقت (TOTPs) +* الآليات خارج النطاق -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. +أسرار البحث هي قوائم مُولَّدة مسبقًا من الرموز السرّية، شبيهة بأرقام تخويل المعاملات (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). +وكلمات المرور لمرة واحدة المعتمدة على الوقت (TOTPs) هي رموز فيزيائية أو برمجية تعرض تحديًا شبه عشوائي لمرة واحدة يتغيّر باستمرار. ويُعدّ هذا النوع من آليات المصادقة "شيئًا تملكه". وكلمات المرور لمرة واحدة متعددة العوامل شبيهة بأحادية العامل، لكنها تتطلّب إدخال رقم تعريف شخصي صحيح أو إلغاء قفل بالقياسات الحيوية أو إدخال USB أو إقران NFC أو قيمة إضافية (مثل حاسبات توقيع المعاملات) لإنشاء كلمة المرور لمرة واحدة النهائية (OTP). -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). +وتتعلق المتطلبات في هذه الأقسام في معظمها بـ [§ 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) من [إرشادات NIST](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | 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** | تحقق من أن أسرار البحث وطلبات أو رموز المصادقة خارج النطاق وكلمات المرور لمرة واحدة المعتمدة على الوقت (TOTPs) لا يمكن استخدامها بنجاح إلا مرة واحدة. | 2 | +| **6.5.2** | تحقق من أن أسرار البحث التي تقل عشوائيتها عن 112 بتًا (19 محرفًا أبجديًا رقميًا عشوائيًا أو 34 رقمًا عشوائيًا)، عند تخزينها في الواجهة الخلفية للتطبيق، تُلبَّد بخوارزمية تلبيد معتمدة لتخزين كلمات المرور تشتمل على ملح عشوائي بطول 32 بتًا. ويمكن استخدام دالة تلبيد قياسية إذا كانت عشوائية السر 112 بتًا أو أكثر. | 2 | +| **6.5.3** | تحقق من أن أسرار البحث ورموز المصادقة خارج النطاق وبذور كلمات المرور لمرة واحدة المعتمدة على الوقت تُولَّد باستخدام مولّد أعداد شبه عشوائية آمن تشفيريًا (CSPRNG) لتجنّب القيم القابلة للتوقع. | 2 | +| **6.5.4** | تحقق من أن أسرار البحث ورموز المصادقة خارج النطاق تمتلك 20 بتًا على الأقل من العشوائية (وعادةً يكفي 4 محارف أبجدية رقمية عشوائية أو 6 أرقام عشوائية). | 2 | +| **6.5.5** | تحقق من أن طلبات أو رموز أو رموز المصادقة خارج النطاق المميزة، وكذلك كلمات المرور لمرة واحدة المعتمدة على الوقت (TOTPs)، لها عمر محدّد. ويجب أن يكون للطلبات خارج النطاق عمر أقصى قدره 10 دقائق، ولكلمات المرور لمرة واحدة المعتمدة على الوقت عمر أقصى قدره 30 ثانية. | 2 | +| **6.5.6** | تحقق من إمكانية إبطال أي عامل مصادقة (بما فيها الأجهزة الفيزيائية) في حال السرقة أو أي فقدان آخر. | 3 | +| **6.5.7** | تحقق من أن آليات المصادقة بالقياسات الحيوية لا تُستخدم إلا كعوامل ثانوية إلى جانب إما شيء تملكه أو شيء تعرفه. | 3 | +| **6.5.8** | تحقق من أن كلمات المرور لمرة واحدة المعتمدة على الوقت (TOTPs) تُفحص بناءً على مصدر وقت من خدمة موثوقة وليس من وقت غير موثوق أو مقدَّم من العميل. | 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". +يتضمّن ذلك عادةً تواصل خادم المصادقة مع جهاز فيزيائي عبر قناة ثانوية آمنة. على سبيل المثال، إرسال إشعارات دفع إلى الأجهزة المحمولة. ويُعدّ هذا النوع من آليات المصادقة "شيئًا تملكه". -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). وتُعدّ المصادقة عبر شبكة الهاتف العمومية المبدّلة والرسائل القصيرة حاليًا [آليات مصادقة "مقيّدة"](https://pages.nist.gov/800-63-FAQ/#q-b01) لدى NIST وينبغي إيقافها لصالح كلمات المرور لمرة واحدة المعتمدة على الوقت (TOTPs) أو آلية تشفيرية أو ما شابه. ويوصي 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) بمعالجة مخاطر تبديل الجهاز أو تغيير بطاقة SIM أو نقل الرقم أو أي سلوك شاذ آخر، إذا كان لا بد من دعم المصادقة خارج النطاق عبر الهاتف أو الرسائل القصيرة. ومع أن هذا القسم من معيار التحقق من أمان التطبيقات لا يُلزم بذلك كمتطلب، فإن عدم اتخاذ هذه الاحتياطات في تطبيق حساس من المستوى 2 أو في تطبيق من المستوى 3 ينبغي أن يُنظر إليه كعلامة تحذير كبيرة. -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). ومع أن هذا القسم من معيار التحقق من أمان التطبيقات لا يفعل ذلك، فمن المهم الوعي بمخاطر "إغراق إشعارات الدفع". -| # | 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** | تحقق من أن آليات المصادقة التي تستخدم شبكة الهاتف العمومية المبدّلة (PSTN) لتسليم كلمات المرور لمرة واحدة (OTPs) عبر الهاتف أو الرسائل القصيرة لا تُقدَّم إلا إذا كان رقم الهاتف قد تم التحقق منه مسبقًا، وتُقدَّم كذلك طرائق بديلة أقوى (مثل كلمات المرور لمرة واحدة المعتمدة على الوقت)، وتوفّر الخدمة معلومات للمستخدمين عن مخاطرها الأمنية. وبالنسبة إلى تطبيقات المستوى 3، يجب ألا يكون الهاتف والرسائل القصيرة متاحين كخيارين. | 2 | +| **6.6.2** | تحقق من أن طلبات أو رموز المصادقة خارج النطاق أو الرموز المميزة مرتبطة بطلب المصادقة الأصلي الذي وُلّدت من أجله وأنها غير قابلة للاستخدام في طلب سابق أو لاحق. | 2 | +| **6.6.3** | تحقق من أن آلية المصادقة خارج النطاق القائمة على رمز محمية من هجمات القوة الغاشمة باستخدام تحديد المعدّل. وينبغي كذلك النظر في استخدام رمز بعشوائية لا تقل عن 64 بتًا. | 2 | +| **6.6.4** | تحقق من أنه، حيث تُستخدم إشعارات الدفع للمصادقة متعددة العوامل، يُستخدم تحديد المعدّل لمنع هجمات إغراق إشعارات الدفع. وقد يخفّف مطابقة الأرقام من هذا الخطر كذلك. | 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، حيث يتعيّن على المستخدم إدخال الجهاز التشفيري أو إقرانه بالحاسوب لإتمام المصادقة. ويرسل خادم المصادقة قيمة عشوائية للتحدي إلى الجهاز أو البرمجية التشفيرية، فيحسب الجهاز أو البرمجية استجابة بناءً على مفتاح تشفيري مخزَّن بأمان. وتوفّر المتطلبات في هذا القسم إرشادات خاصة بالتنفيذ لهذه الآليات، أما الإرشادات المتعلقة بخوارزميات التشفير فهي مشمولة في فصل "التشفير". -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. +وحيث تُستخدم مفاتيح مشتركة أو سرّية للمصادقة التشفيرية، ينبغي تخزينها باستخدام الآليات نفسها المستخدمة لأسرار النظام الأخرى، على النحو الموثّق في قسم "إدارة الأسرار" في فصل "التكوين". -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). +وتتعلق المتطلبات في هذا القسم في معظمها بـ [§ 5.1.7.2](https://pages.nist.gov/800-63-3/sp800-63b.html#sfcdv) من [إرشادات NIST](https://pages.nist.gov/800-63-3/sp800-63b.html). -| # | 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** | تحقق من أن الشهادات المستخدمة للتحقق من تأكيدات المصادقة التشفيرية مخزَّنة بطريقة تحميها من التعديل. | 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. +يوفّر مزوّدو الهوية (IdPs) هوية اتحادية للمستخدمين. وكثيرًا ما يكون للمستخدمين أكثر من هوية لدى مزوّدي هوية متعددين، مثل هوية مؤسسية باستخدام Azure AD أو Okta أو Ping Identity أو Google، أو هوية استهلاكية باستخدام Facebook أو Twitter أو Google أو WeChat، على سبيل الذكر لبعض البدائل الشائعة. وهذه القائمة ليست تزكية لهذه الشركات أو الخدمات، بل مجرّد تشجيع للمطوّرين على مراعاة واقع أن كثيرًا من المستخدمين لديهم هويات مُرسَّخة كثيرة. وينبغي للمؤسسات النظر في التكامل مع هويات المستخدمين القائمة، وفق ملف مخاطر قوة إثبات الهوية لدى مزوّد الهوية. فعلى سبيل المثال، من غير المرجّح أن تقبل مؤسسة حكومية هوية من وسائل التواصل الاجتماعي كوسيلة دخول إلى أنظمة حساسة، إذ يسهل إنشاء هويات مزيّفة أو للاستخدام مرة واحدة، في حين قد تحتاج شركة ألعاب محمولة فعلًا إلى التكامل مع منصات التواصل الاجتماعي الكبرى لتنمية قاعدة لاعبيها النشطين. -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. +ويقتضي الاستخدام الآمن لمزوّدي الهوية الخارجيين تهيئة وتحققًا دقيقين لمنع انتحال الهوية أو تزوير التأكيدات. ويوفّر هذا القسم متطلبات لمعالجة هذه المخاطر. -| # | 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** | تحقق من أنه، إذا كان التطبيق يدعم مزوّدي هوية متعددين (IdPs)، فلا يمكن انتحال هوية المستخدم عبر مزوّد هوية مدعوم آخر (مثلًا باستخدام معرّف المستخدم نفسه). والتخفيف القياسي أن يسجّل التطبيق المستخدم ويعرّفه باستخدام تركيبة من معرّف مزوّد الهوية (بوصفه مساحة أسماء) ومعرّف المستخدم لدى ذلك المزوّد. | 2 | +| **6.8.2** | تحقق من أن وجود التوقيعات الرقمية على تأكيدات المصادقة وسلامتها (مثلًا على رموز JWT أو تأكيدات SAML) يُتحقَّق منهما دائمًا، مع رفض أي تأكيدات غير موقّعة أو ذات توقيعات غير صحيحة. | 2 | +| **6.8.3** | تحقق من أن تأكيدات SAML تُعالَج على نحو فريد وتُستخدم مرة واحدة فقط خلال مدة الصلاحية لمنع هجمات إعادة الإرسال. | 2 | +| **6.8.4** | تحقق من أنه، إذا كان التطبيق يستخدم مزوّد هوية منفصلًا (IdP) ويتوقع قوة أو طرائق أو حداثة مصادقة معيّنة لوظائف بعينها، فإن التطبيق يتحقق من ذلك باستخدام المعلومات التي يعيدها مزوّد الهوية. فعلى سبيل المثال، إذا استُخدم OIDC، فقد يتحقق ذلك بالتحقق من مطالبات رمز الهوية مثل 'acr' و'amr' و'auth_time' (إن وُجدت). وإذا لم يوفّر مزوّد الهوية هذه المعلومات، فيجب أن يكون للتطبيق منهج احتياطي موثّق يفترض أن آلية المصادقة الأدنى قوة قد استُخدمت (مثلًا مصادقة أحادية العامل باستخدام اسم المستخدم وكلمة المرور). | 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) diff --git a/5.0/ar/0x19-V10-OAuth-and-OIDC.md b/5.0/ar/0x19-V10-OAuth-and-OIDC.md index e726216b4b..6177b21e84 100644 --- a/5.0/ar/0x19-V10-OAuth-and-OIDC.md +++ b/5.0/ar/0x19-V10-OAuth-and-OIDC.md @@ -1,151 +1,151 @@ -# 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 في هذا الفصل) إطار عمل معياري في الصناعة للتخويل المفوَّض. فعلى سبيل المثال، يمكن لتطبيق عميل، باستخدام OAuth، أن يحصل على وصول إلى واجهات برمجة التطبيقات (موارد الخادم) بالنيابة عن مستخدم، بشرط أن يكون المستخدم قد خوّل تطبيق العميل بذلك. -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 بحد ذاته مصمّمًا لمصادقة المستخدمين. ويوسّع إطار عمل OpenID Connect (OIDC) نطاق OAuth بإضافة طبقة هوية للمستخدم فوقه. ويوفّر OIDC دعمًا لميزات منها معلومات المستخدم الموحّدة والدخول الموحّد (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 هو التطبيق الذي يحاول الحصول على وصول إلى موارد الخادم (مثلًا باستدعاء واجهة برمجة تطبيقات باستخدام رمز الوصول الصادر). وعميل OAuth كثيرًا ما يكون تطبيقًا من جانب الخادم. + * العميل السرّي هو عميل قادر على الحفاظ على سرّية بيانات الاعتماد التي يستخدمها للمصادقة على نفسه لدى خادم التخويل. + * العميل العام غير قادر على الحفاظ على سرّية بيانات الاعتماد اللازمة للمصادقة لدى خادم التخويل. ولذلك، فبدلًا من المصادقة على نفسه (مثلًا باستخدام المعاملين 'client_id' و'client_secret')، فإنه يعرّف نفسه فقط (باستخدام المعامل 'client_id'). +* خادم موارد OAuth (RS) هو واجهة برمجة تطبيقات الخادم التي تعرض الموارد لعملاء OAuth. +* خادم تخويل OAuth (AS) هو تطبيق خادم يُصدر رموز الوصول لعملاء OAuth. وتتيح رموز الوصول هذه لعملاء OAuth الوصول إلى موارد خادم الموارد، إما بالنيابة عن مستخدم نهائي أو بالنيابة عن عميل OAuth نفسه. وكثيرًا ما يكون خادم التخويل تطبيقًا منفصلًا، لكنه قد يكون (إذا كان ذلك ملائمًا) مدمجًا في خادم موارد مناسب. +* مالك الموارد (RO) هو المستخدم النهائي الذي يخوّل عملاء OAuth للحصول على وصول محدود إلى الموارد المستضافة على خادم الموارد بالنيابة عنه. ويوافق مالك الموارد على هذا التخويل المفوَّض بالتفاعل مع خادم التخويل. -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. +* الطرف المعوِّل (RP) هو تطبيق العميل الذي يطلب مصادقة المستخدم النهائي عبر مزوّد OpenID. وهو يتولى دور عميل OAuth. +* مزوّد OpenID (OP) هو خادم تخويل OAuth قادر على مصادقة المستخدم النهائي ويوفّر مطالبات OIDC للطرف المعوِّل. وقد يكون مزوّد OpenID هو مزوّد الهوية (IdP)، لكن في السيناريوهات الاتحادية قد يكون مزوّد OpenID ومزوّد الهوية (الذي يصادق المستخدم النهائي لديه) تطبيقَي خادم مختلفين. -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 في أنواع كثيرة من التطبيقات، لكن تركيز معيار التحقق من أمان التطبيقات والمتطلبات في هذا الفصل على تطبيقات الويب وواجهات برمجة التطبيقات. -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 بما يتوافق مع المواصفات الموجودة في و. وحتى إن كانت وثائق 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 أن يستخدم خوادم تخويل معيارية معروفة في الصناعة وأن يطبّق التكوين الأمني الموصى به. -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. +والمصطلحات المستخدمة في هذا الفصل متوافقة مع وثائق RFC الخاصة بـ OAuth ومواصفات OIDC، لكن لاحظ أن مصطلحات OIDC لا تُستخدم إلا في المتطلبات الخاصة بـ OIDC؛ وفيما عدا ذلك تُستخدم مصطلحات OAuth. -In the context of OAuth and OIDC, the term "token" in this chapter refers to: +وفي سياق OAuth وOIDC، يشير مصطلح "الرمز المميز" في هذا الفصل إلى: -* 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. +* رموز الوصول، التي لا يجوز أن يستهلكها إلا خادم الموارد، ويمكن أن تكون إما رموزًا مرجعية يُتحقَّق منها بالاستبطان أو رموزًا مكتفية بذاتها يُتحقَّق منها باستخدام مادة مفاتيح ما. +* رموز التحديث، التي لا يجوز أن يستهلكها إلا خادم التخويل الذي أصدر الرمز. +* رموز الهوية في OIDC، التي لا يجوز أن يستهلكها إلا العميل الذي استهلّ مسار التخويل. -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. +وتعتمد مستويات المخاطر لبعض المتطلبات في هذا الفصل على ما إذا كان العميل عميلًا سرّيًا أو يُعدّ عميلًا عامًا. وبما أن استخدام مصادقة قوية للعميل يخفّف من متجهات هجوم كثيرة، فقد تُخفَّف بعض المتطلبات عند استخدام عميل سرّي في تطبيقات المستوى 1. -## 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 القائمة على المتصفح، لا يجوز أن تكون رموز الوصول والتحديث متاحة إلا للواجهة الخلفية. | 2 | +| **10.1.2** | تحقق من أن العميل لا يقبل القيم الواردة من خادم التخويل (مثل رمز التخويل أو رمز الهوية) إلا إذا كانت هذه القيم ناتجة عن مسار تخويل استهلّته جلسة وكيل المستخدم والمعاملة نفسها. ويقتضي ذلك أن تكون الأسرار التي يولّدها العميل، مثل 'code_verifier' الخاص بمفتاح إثبات تبادل الرمز (PKCE) أو 'state' أو 'nonce' في OIDC، غير قابلة للتخمين وخاصة بالمعاملة ومرتبطة بأمان بكل من العميل وجلسة وكيل المستخدم التي بدأت فيها المعاملة. | 2 | -## V10.2 OAuth Client +## V10.2 عميل OAuth -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. وقد يكون العميل، على سبيل المثال، واجهة خلفية لخادم ويب (تعمل غالبًا كواجهة خلفية للواجهة الأمامية، BFF)، أو تكاملًا لخدمة في الواجهة الخلفية، أو تطبيق صفحة واحدة في الواجهة الأمامية (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. +وعمومًا، تُعدّ عملاء الواجهة الخلفية عملاء سرّيين وتُعدّ عملاء الواجهة الأمامية عملاء عامين. لكن التطبيقات الأصيلة التي تعمل على جهاز المستخدم النهائي يمكن أن تُعدّ سرّية عند استخدام التسجيل الديناميكي للعملاء في OAuth. -| # | 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** | تحقق من أن عميل OAuth، في حال استخدام مسار الرمز، يمتلك حماية من هجمات تزوير الطلبات القائمة على المتصفح، المعروفة عمومًا بتزوير الطلبات عبر المواقع (CSRF)، التي تُشغّل طلبات الرموز، وذلك إما باستخدام وظيفة مفتاح إثبات تبادل الرمز (PKCE) أو بفحص المعامل 'state' الذي أُرسل في طلب التخويل. | 2 | +| **10.2.2** | تحقق من أن عميل OAuth، إذا كان يمكنه التفاعل مع أكثر من خادم تخويل، يمتلك دفاعًا عن هجمات الخلط. فعلى سبيل المثال، قد يشترط أن يعيد خادم التخويل قيمة المعامل 'iss' وأن يتحقق منها في استجابة التخويل واستجابة الرمز. | 2 | +| **10.2.3** | تحقق من أن عميل OAuth لا يطلب سوى النطاقات المطلوبة (أو معاملات التخويل الأخرى) في الطلبات الموجّهة إلى خادم التخويل. | 3 | -## V10.3 OAuth Resource Server +## V10.3 خادم موارد OAuth -In the context of ASVS and this chapter, the resource server is an API. To provide secure access, the resource server must: +في سياق معيار التحقق من أمان التطبيقات وهذا الفصل، يكون خادم الموارد واجهة برمجة تطبيقات. ولتوفير وصول آمن، يجب على خادم الموارد أن: -* 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. +* يتحقق من رمز الوصول، وفق صيغة الرمز ومواصفات البروتوكول المعنية، مثل التحقق من JWT أو استبطان رموز OAuth. +* يُنفِذ، إذا كان الرمز صحيحًا، قرارات التخويل بناءً على المعلومات المستقاة من رمز الوصول والصلاحيات التي مُنحت. فعلى سبيل المثال، يلزم خادم الموارد أن يتحقق من أن العميل (العامل بالنيابة عن مالك الموارد) مخوَّل بالوصول إلى المورد المطلوب. -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** | تحقق من أن خادم الموارد لا يقبل سوى رموز الوصول المخصّصة للاستخدام مع تلك الخدمة (الجهة المستهدفة). وقد تكون الجهة المستهدفة مُدرجة في رمز وصول مُهيكل (مثل مطالبة 'aud' في JWT)، أو يمكن فحصها باستخدام نقطة نهاية استبطان الرموز. | 2 | +| **10.3.2** | تحقق من أن خادم الموارد يُنفِذ قرارات التخويل بناءً على المطالبات المستقاة من رمز الوصول التي تحدّد التخويل المفوَّض. وإذا كانت مطالبات مثل 'sub' و'scope' و'authorization_details' موجودة، فيجب أن تكون جزءًا من القرار. | 2 | +| **10.3.3** | تحقق من أنه، إذا كان قرار التحكم في الوصول يقتضي تحديد مستخدم فريد من رمز وصول (JWT أو استجابة استبطان الرمز المتصلة به)، فإن خادم الموارد يحدّد المستخدم من مطالبات لا يمكن إعادة تخصيصها لمستخدمين آخرين. ويعني ذلك عادةً استخدام تركيبة من مطالبتي 'iss' و'sub'. | 2 | +| **10.3.4** | تحقق من أن خادم الموارد، إذا كان يشترط قوة أو طرائق أو حداثة مصادقة معيّنة، يتحقق من أن رمز الوصول المُقدَّم يستوفي هذه القيود. فعلى سبيل المثال، باستخدام مطالبات OIDC 'acr' و'amr' و'auth_time' على التوالي، إن وُجدت. | 2 | +| **10.3.5** | تحقق من أن خادم الموارد يمنع استخدام رموز الوصول المسروقة أو إعادة إرسال رموز الوصول (من أطراف غير مصرَّح لها) باشتراط رموز وصول مقيَّدة بالمُرسِل، إما باستخدام TLS المتبادل لـ OAuth 2 أو إثبات الحيازة (DPoP) في OAuth 2. | 3 | -## V10.4 OAuth Authorization Server +## V10.4 خادم تخويل OAuth -These requirements detail the responsibilities for OAuth authorization servers, including OpenID Providers. +تبيّن هذه المتطلبات مسؤوليات خوادم تخويل OAuth، بما فيها مزوّدو OpenID. -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). +وبالنسبة إلى مصادقة العميل، يُسمح بطريقة 'self_signed_tls_client_auth' بالشروط المسبقة التي يقتضيها [القسم 2.2](https://datatracker.ietf.org/doc/html/rfc8705#name-self-signed-certificate-mut) من [RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705). -| # | 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 | - -## V10.5 OIDC Client - -As the OIDC relying party acts as an OAuth client, the requirements from the section "OAuth Client" apply as well. - -Note that the "Authentication with an Identity Provider" section in the "Authentication" chapter also contains relevant general requirements. - -| # | Description | Level | +| **10.4.1** | تحقق من أن خادم التخويل يتحقق من معرّفات إعادة التوجيه بناءً على قائمة سماح خاصة بالعميل تتضمّن معرّفات مسجّلة مسبقًا، باستخدام مقارنة نصية دقيقة. | 1 | +| **10.4.2** | تحقق من أنه، إذا أعاد خادم التخويل رمز التخويل في استجابة التخويل، فلا يمكن استخدامه إلا مرة واحدة لطلب رمز. وعند ورود طلب صحيح ثانٍ برمز تخويل استُخدم بالفعل لإصدار رمز وصول، يجب على خادم التخويل رفض طلب الرمز وإبطال أي رموز صادرة متصلة برمز التخويل. | 1 | +| **10.4.3** | تحقق من أن رمز التخويل قصير الأجل. ويمكن أن يبلغ العمر الأقصى 10 دقائق لتطبيقات المستويين 1 و2 ودقيقة واحدة لتطبيقات المستوى 3. | 1 | +| **10.4.4** | تحقق من أن خادم التخويل، لعميل معيّن، لا يسمح إلا باستخدام المنح التي يحتاج هذا العميل إلى استخدامها. ولاحظ أن المنحتين 'token' (المسار الضمني) و'password' (مسار بيانات اعتماد كلمة مرور مالك الموارد) يجب ألا تُستخدما بعد الآن. | 1 | +| **10.4.5** | تحقق من أن خادم التخويل يخفّف من هجمات إعادة إرسال رموز التحديث للعملاء العامين، ويُفضَّل باستخدام رموز تحديث مقيَّدة بالمُرسِل، أي إثبات الحيازة (DPoP) أو رموز وصول مرتبطة بالشهادات باستخدام TLS المتبادل (mTLS). وبالنسبة إلى تطبيقات المستويين 1 و2، يمكن استخدام تدوير رموز التحديث. وإذا استُخدم تدوير رموز التحديث، فيجب على خادم التخويل إبطال رمز التحديث بعد استخدامه، وإبطال جميع رموز التحديث لذلك التخويل إذا قُدّم رمز تحديث مستخدم ومُبطَل بالفعل. | 1 | +| **10.4.6** | تحقق من أن خادم التخويل، في حال استخدام منحة الرمز، يخفّف من هجمات اعتراض رمز التخويل باشتراط مفتاح إثبات تبادل الرمز (PKCE). وبالنسبة إلى طلبات التخويل، يجب على خادم التخويل اشتراط قيمة 'code_challenge' صحيحة ويجب ألا يقبل قيمة 'plain' للمعامل 'code_challenge_method'. وبالنسبة إلى طلب الرمز، يجب أن يشترط التحقق من المعامل 'code_verifier'. | 2 | +| **10.4.7** | تحقق من أن خادم التخويل، إذا كان يدعم التسجيل الديناميكي غير المصادَق عليه للعملاء، يخفّف من خطر تطبيقات العملاء الخبيثة. ويجب أن يتحقق من بيانات العميل الوصفية مثل أي معرّفات مسجّلة، وأن يضمن موافقة المستخدم، وأن يحذّر المستخدم قبل معالجة طلب تخويل بتطبيق عميل غير موثوق. | 2 | +| **10.4.8** | تحقق من أن لرموز التحديث انتهاء صلاحية مطلقًا، بما في ذلك في حال تطبيق انتهاء صلاحية متزحلق لرموز التحديث. | 2 | +| **10.4.9** | تحقق من أن رموز التحديث ورموز الوصول المرجعية يمكن إبطالها بواسطة مستخدم مخوَّل عبر واجهة مستخدم خادم التخويل، وذلك للتخفيف من خطر العملاء الخبيثة أو الرموز المسروقة. | 2 | +| **10.4.10** | تحقق من أن العميل السرّي مُصادَق عليه في طلبات القناة الخلفية من العميل إلى الخادم المخوَّل، مثل طلبات الرموز وطلبات التخويل المدفوعة (PAR) وطلبات إبطال الرموز. | 2 | +| **10.4.11** | تحقق من أن تكوين خادم التخويل لا يخصّص لعميل OAuth إلا النطاقات المطلوبة. | 2 | +| **10.4.12** | تحقق من أن خادم التخويل، لعميل معيّن، لا يسمح إلا بقيمة 'response_mode' التي يحتاج هذا العميل إلى استخدامها. وذلك مثلًا بأن يتحقق خادم التخويل من هذه القيمة مقابل القيم المتوقعة أو باستخدام طلب التخويل المدفوع (PAR) أو طلب التخويل المؤمَّن بـ JWT (JAR). | 3 | +| **10.4.13** | تحقق من أن نوع المنحة 'code' يُستخدم دائمًا مع طلبات التخويل المدفوعة (PAR). | 3 | +| **10.4.14** | تحقق من أن خادم التخويل لا يُصدر إلا رموز وصول مقيَّدة بالمُرسِل (إثبات الحيازة)، إما رموز وصول مرتبطة بالشهادات باستخدام TLS المتبادل (mTLS) أو رموز وصول مرتبطة بـ DPoP (إثبات الحيازة). | 3 | +| **10.4.15** | تحقق من أن خادم التخويل، بالنسبة إلى عميل من جانب الخادم (لا يُنفَّذ على جهاز المستخدم النهائي)، يضمن أن قيمة المعامل 'authorization_details' واردة من واجهة العميل الخلفية وأن المستخدم لم يتلاعب بها. وذلك مثلًا باشتراط استخدام طلب التخويل المدفوع (PAR) أو طلب التخويل المؤمَّن بـ JWT (JAR). | 3 | +| **10.4.16** | تحقق من أن العميل سرّي وأن خادم التخويل يشترط استخدام طرائق مصادقة قوية للعميل (مبنية على تشفير المفتاح العام ومقاومة لهجمات إعادة الإرسال)، مثل TLS المتبادل ('tls_client_auth' و'self_signed_tls_client_auth') أو JWT بالمفتاح الخاص ('private_key_jwt'). | 3 | + +## V10.5 عميل OIDC + +بما أن الطرف المعوِّل في OIDC يعمل كعميل OAuth، فإن المتطلبات الواردة في قسم "عميل OAuth" تنطبق كذلك. + +ولاحظ أن قسم "المصادقة عبر مزوّد هوية" في فصل "المصادقة" يحتوي كذلك على متطلبات عامة ذات صلة. + +| # | الوصف | المستوى | | :---: | :--- | :---: | -| **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** | تحقق من أن العميل (بوصفه الطرف المعوِّل) يخفّف من هجمات إعادة إرسال رمز الهوية. وذلك مثلًا بالتأكد من أن مطالبة 'nonce' في رمز الهوية تطابق قيمة 'nonce' المُرسلة في طلب المصادقة إلى مزوّد OpenID (المشار إليه في OAuth2 بطلب التخويل المُرسل إلى خادم التخويل). | 2 | +| **10.5.2** | تحقق من أن العميل يحدّد المستخدم على نحو فريد من مطالبات رمز الهوية، وعادةً مطالبة 'sub'، التي لا يمكن إعادة تخصيصها لمستخدمين آخرين (في نطاق مزوّد هوية واحد). | 2 | +| **10.5.3** | تحقق من أن العميل يرفض محاولات خادم تخويل خبيث لانتحال هوية خادم تخويل آخر عبر البيانات الوصفية لخادم التخويل. ويجب على العميل رفض البيانات الوصفية لخادم التخويل إذا لم يطابق عنوان URL الخاص بالجهة المُصدِرة في تلك البيانات، مطابقةً دقيقة، عنوان URL المُهيّأ مسبقًا والمتوقع من قِبل العميل. | 2 | +| **10.5.4** | تحقق من أن العميل يتحقق من أن رمز الهوية مخصّص للاستخدام من قِبل ذلك العميل (الجهة المستهدفة)، وذلك بفحص أن مطالبة 'aud' في الرمز مساوية لقيمة 'client_id' الخاصة بالعميل. | 2 | +| **10.5.5** | تحقق من أن الطرف المعوِّل، عند استخدام تسجيل الخروج عبر القناة الخلفية في OIDC، يخفّف من حجب الخدمة عن طريق تسجيل الخروج القسري ومن الالتباس بين رموز JWT في مسار تسجيل الخروج. ويجب على العميل التحقق من أن رمز تسجيل الخروج مُصنَّف على نحو صحيح بالقيمة 'logout+jwt'، وأنه يحتوي على مطالبة 'event' باسم العضو الصحيح، وأنه لا يحتوي على مطالبة 'nonce'. ولاحظ أنه يُوصى كذلك بأن يكون له انتهاء صلاحية قصير (مثلًا دقيقتان). | 2 | -## V10.6 OpenID Provider +## V10.6 مزوّد OpenID -As OpenID Providers act as OAuth authorization servers, the requirements from the section "OAuth Authorization Server" apply as well. +بما أن مزوّدي OpenID يعملون كخوادم تخويل OAuth، فإن المتطلبات الواردة في قسم "خادم تخويل OAuth" تنطبق كذلك. -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. +ولاحظ أنه في حال استخدام مسار رمز الهوية (وليس مسار الرمز)، لا تُصدر رموز وصول، وكثير من متطلبات خادم تخويل OAuth تكون غير منطبقة. -| # | 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 لا يسمح إلا بالقيم 'code' أو 'ciba' أو 'id_token' أو 'id_token code' لنمط الاستجابة. ولاحظ أن 'code' مفضّلة على 'id_token code' (المسار الهجين في OIDC)، وأن 'token' (أي مسار ضمني) يجب ألا تُستخدم. | 2 | +| **10.6.2** | تحقق من أن مزوّد OpenID يخفّف من حجب الخدمة عن طريق تسجيل الخروج القسري. وذلك بالحصول على تأكيد صريح من المستخدم النهائي أو، إن وُجدت، بالتحقق من المعاملات في طلب تسجيل الخروج (الذي يستهلّه الطرف المعوِّل)، مثل '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. +تتناول هذه المتطلبات التحقق من موافقة المستخدم بواسطة خادم التخويل. فمن دون تحقق سليم من موافقة المستخدم، قد يحصل فاعل خبيث على صلاحيات بالنيابة عن المستخدم عن طريق الانتحال أو الهندسة الاجتماعية. -| # | 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** | تحقق من أن خادم التخويل يضمن موافقة المستخدم على كل طلب تخويل. وإذا لم يكن من الممكن ضمان هوية العميل، فيجب على خادم التخويل أن يطلب موافقة المستخدم صراحةً دائمًا. | 2 | +| **10.7.2** | تحقق من أن خادم التخويل، عند طلبه موافقة المستخدم، يعرض معلومات كافية وواضحة عمّا تجري الموافقة عليه. وينبغي أن يشمل ذلك، حيث ينطبق، طبيعة التخويلات المطلوبة (عادةً بناءً على النطاق وخادم الموارد وتفاصيل التخويل في طلبات التخويل الغنية (RAR))، وهوية التطبيق المخوَّل، وعمر هذه التخويلات. | 2 | +| **10.7.3** | تحقق من أن المستخدم يمكنه مراجعة الموافقات التي منحها عبر خادم التخويل وتعديلها وإبطالها. | 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: +وبالنسبة إلى المتطلبات المتعلقة بـ 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) @@ -163,7 +163,7 @@ For OAuth-related requirements in ASVS following published and in draft status R * [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/ar/0x21-V12-Secure-Communication.md b/5.0/ar/0x21-V12-Secure-Communication.md index 90d1e20a2a..23d9cb81c6 100644 --- a/5.0/ar/0x21-V12-Secure-Communication.md +++ b/5.0/ar/0x21-V12-Secure-Communication.md @@ -10,7 +10,7 @@ * تكوين آليات التشفير باستخدام أحدث الإرشادات، بما في ذلك الخوارزميات ومجموعات التشفير المفضّلة. * التأكد من أن الاتصالات لا تُعترض من قِبل أطراف غير مصرَّح لها، وذلك باستخدام شهادات موقّعة. -وإضافةً إلى بيان المبادئ العامة والممارسات الفضلى، يوفّر ASVS كذلك معلومات تقنية أكثر تعمّقًا عن القوة التشفيرية في الملحق ج - معايير التشفير. +وإضافةً إلى بيان المبادئ العامة والممارسات الفضلى، يوفّر معيار التحقق من أمان التطبيقات كذلك معلومات تقنية أكثر تعمّقًا عن القوة التشفيرية في الملحق ج - معايير التشفير. ## V12.1 إرشادات عامة لأمان TLS diff --git a/5.0/ar/0x23-V14-Data-Protection.md b/5.0/ar/0x23-V14-Data-Protection.md index 6b1b4c3dec..bd90b32a65 100644 --- a/5.0/ar/0x23-V14-Data-Protection.md +++ b/5.0/ar/0x23-V14-Data-Protection.md @@ -6,7 +6,7 @@ ويشتمل هذا الفصل على متطلبات متعلقة بتحديد البيانات التي تحتاج إلى حماية، وكيفية حمايتها، والآليات المحدّدة التي ينبغي تنفيذها أو المزالق التي ينبغي تجنّبها. -ومن الاعتبارات الأخرى لحماية البيانات الاستخراج بالجملة أو التعديل أو الاستخدام المفرط. ومن المرجّح أن تكون متطلبات كل نظام مختلفة جدًا، ولذلك يجب أن يراعي تحديد ما هو "غير طبيعي" نموذج التهديد ومخاطر العمل. ومن منظور ASVS، يُعالَج كشف هذه المشكلات في فصل "تسجيل الأحداث الأمنية ومعالجة الأخطاء"، ويُعالَج وضع الحدود في فصل "التحقق من الصحة ومنطق العمل". +ومن الاعتبارات الأخرى لحماية البيانات الاستخراج بالجملة أو التعديل أو الاستخدام المفرط. ومن المرجّح أن تكون متطلبات كل نظام مختلفة جدًا، ولذلك يجب أن يراعي تحديد ما هو "غير طبيعي" نموذج التهديد ومخاطر العمل. ومن منظور معيار التحقق من أمان التطبيقات، يُعالَج كشف هذه المشكلات في فصل "تسجيل الأحداث الأمنية ومعالجة الأخطاء"، ويُعالَج وضع الحدود في فصل "التحقق من الصحة ومنطق العمل". ## V14.1 توثيق حماية البيانات diff --git a/5.0/ar/0x24-V15-Secure-Coding-and-Architecture.md b/5.0/ar/0x24-V15-Secure-Coding-and-Architecture.md index caa0c074cd..4fb4ca0f6e 100644 --- a/5.0/ar/0x24-V15-Secure-Coding-and-Architecture.md +++ b/5.0/ar/0x24-V15-Secure-Coding-and-Architecture.md @@ -2,7 +2,7 @@ ## الهدف من ضوابط الأمان -يتعلق كثير من متطلبات ASVS إما بمجال معيّن من الأمان، مثل المصادقة أو التخويل، أو بنوع معيّن من وظائف التطبيق، مثل تسجيل الأحداث أو التعامل مع الملفات. +يتعلق كثير من متطلبات معيار التحقق من أمان التطبيقات إما بمجال معيّن من الأمان، مثل المصادقة أو التخويل، أو بنوع معيّن من وظائف التطبيق، مثل تسجيل الأحداث أو التعامل مع الملفات. ويوفّر هذا الفصل متطلبات أمنية عامة ينبغي مراعاتها عند تصميم التطبيقات وتطويرها. ولا تركّز هذه المتطلبات على نقاء المعمارية وجودة الشيفرة فحسب، بل كذلك على ممارسات معمارية وبرمجية محدّدة لازمة لأمان التطبيقات. diff --git a/5.0/ar/0x25-V16-Security-Logging-and-Error-Handling.md b/5.0/ar/0x25-V16-Security-Logging-and-Error-Handling.md index e50091ecc5..454f3d39f9 100644 --- a/5.0/ar/0x25-V16-Security-Logging-and-Error-Handling.md +++ b/5.0/ar/0x25-V16-Security-Logging-and-Error-Handling.md @@ -40,7 +40,7 @@ ويبيّن هذا القسم أنواع الأحداث التي ينبغي تسجيلها لكنه لا يحاول تقديم تفاصيل شاملة. فلكل تطبيق عوامل مخاطر وسياق تشغيلي فريدان. -ولاحظ أنه مع أن ASVS يدرج تسجيل الأحداث الأمنية في نطاقه، فإن التنبيه والربط (مثل قواعد SIEM أو بنية المراقبة التحتية) يُعدّان خارج النطاق ويتولاهما نظامَا التشغيل والمراقبة. +ولاحظ أنه مع أن معيار التحقق من أمان التطبيقات يدرج تسجيل الأحداث الأمنية في نطاقه، فإن التنبيه والربط (مثل قواعد SIEM أو بنية المراقبة التحتية) يُعدّان خارج النطاق ويتولاهما نظامَا التشغيل والمراقبة. | # | الوصف | المستوى | | :---: | :--- | :---: | diff --git a/5.0/ar/0x26-V17-WebRTC.md b/5.0/ar/0x26-V17-WebRTC.md index ad897dfb10..175a49669d 100644 --- a/5.0/ar/0x26-V17-WebRTC.md +++ b/5.0/ar/0x26-V17-WebRTC.md @@ -18,7 +18,7 @@ * يستخدمون منتجات WebRTC التجارية كجزء من بنيتهم التحتية. * يستخدمون حلول WebRTC المطوّرة داخليًا أو يدمجون مكوّنات متنوعة في عرض خدمة متكامل. -ومن المهم ملاحظة أن هذه المتطلبات الأمنية لا تنطبق على المطوّرين الذين يستخدمون حصريًا حِزَم تطوير البرمجيات وواجهات برمجة التطبيقات التي يوفّرها مورّدو CPaaS. فبالنسبة إلى هؤلاء المطوّرين، يكون مزوّدو CPaaS مسؤولين عادةً عن معظم الاعتبارات الأمنية الأساسية داخل منصاتهم، وقد لا يلبّي معيار أمني عام مثل ASVS احتياجاتهم بالكامل. +ومن المهم ملاحظة أن هذه المتطلبات الأمنية لا تنطبق على المطوّرين الذين يستخدمون حصريًا حِزَم تطوير البرمجيات وواجهات برمجة التطبيقات التي يوفّرها مورّدو CPaaS. فبالنسبة إلى هؤلاء المطوّرين، يكون مزوّدو CPaaS مسؤولين عادةً عن معظم الاعتبارات الأمنية الأساسية داخل منصاتهم، وقد لا يلبّي معيار أمني عام مثل معيار التحقق من أمان التطبيقات احتياجاتهم بالكامل. ## V17.1 خادم TURN @@ -37,7 +37,7 @@ أما الأنظمة التي تعتمد كليًا على اتصال الوسائط ندًّا لندّ بين متصفحات الويب، دون مشاركة خوادم وسائط وسيطة، فهي مستثناة من هذه المتطلبات الأمنية المحدّدة المتعلقة بالوسائط. -ويشير هذا القسم إلى استخدام أمان طبقة النقل لرزم البيانات (DTLS) في سياق WebRTC. ويمكن العثور على متطلب متعلق بوجود سياسة موثّقة لإدارة مفاتيح التشفير في فصل "التشفير". ويمكن العثور على معلومات عن طرائق التشفير المعتمدة إما في ملحق التشفير في ASVS أو في وثائق مثل NIST SP 800-52 Rev. 2 أو BSI TR-02102-2 (الإصدار 2025-01). +ويشير هذا القسم إلى استخدام أمان طبقة النقل لرزم البيانات (DTLS) في سياق WebRTC. ويمكن العثور على متطلب متعلق بوجود سياسة موثّقة لإدارة مفاتيح التشفير في فصل "التشفير". ويمكن العثور على معلومات عن طرائق التشفير المعتمدة إما في ملحق التشفير في معيار التحقق من أمان التطبيقات أو في وثائق مثل NIST SP 800-52 Rev. 2 أو BSI TR-02102-2 (الإصدار 2025-01). | # | الوصف | المستوى | | :---: | :--- | :---: | diff --git a/5.0/ar/0x90-Appendix-A_Glossary.md b/5.0/ar/0x90-Appendix-A_Glossary.md index 099421646d..90e55ae4ff 100644 --- a/5.0/ar/0x90-Appendix-A_Glossary.md +++ b/5.0/ar/0x90-Appendix-A_Glossary.md @@ -4,7 +4,7 @@ * **Allowlist** (قائمة السماح) – قائمة بالبيانات أو العمليات المسموح بها، على سبيل المثال قائمة بالمحارف المسموح بها لإجراء التحقق من صحة المدخلات. * **Anti-forgery token** (رمز الحماية من التزوير) – آلية يتم فيها تمرير رمز مميز واحد أو أكثر في الطلب ويتحقق منها خادم التطبيق للتأكد من أن الطلب قد ورد من نقطة نهاية متوقعة. * **Application Security** (أمان التطبيق) – يركّز الأمان على مستوى التطبيق على تحليل المكوّنات التي تشكّل طبقة التطبيق في النموذج المرجعي لربط الأنظمة المفتوحة (OSI Model)، بدلًا من التركيز على نظام التشغيل الأساسي أو الشبكات المتصلة مثلًا. -* **Application Security Verification** (التحقق من أمان التطبيق) – التقييم الفني لتطبيق ما مقابل معيار OWASP ASVS. +* **Application Security Verification** (التحقق من أمان التطبيق) – التقييم الفني لتطبيق ما مقابل معيار معيار OWASP للتحقق من أمان التطبيقات. * **Application Security Verification Report** (تقرير التحقق من أمان التطبيق) – تقرير يوثّق النتائج الإجمالية والتحليل الداعم الذي ينتجه المدقّق لتطبيق معيّن. * **Authentication** (المصادقة) – التحقق من الهوية المُدّعاة لمستخدم التطبيق. * **Automated Verification** (التحقق المؤتمت) – استخدام أدوات مؤتمتة (إما أدوات التحليل الديناميكي أو أدوات التحليل الساكن أو كلتيهما) تستخدم تواقيع الثغرات للعثور على المشكلات. @@ -81,7 +81,7 @@ * **Uniform Resource Identifier** (URI، معرّف الموارد الموحّد)- سلسلة محارف فريدة تعرّف موردًا، مثل صفحة ويب أو عنوان بريد أو أماكن. * **Uniform Resource Locator** (URL، محدّد موقع الموارد الموحّد) – سلسلة تحدّد موقع مورد على الإنترنت. * **Universally Unique Identifier** (UUID، المعرّف الفريد عالميًا) – رقم مرجعي فريد يُستخدم كمعرّف في البرمجيات. -* **Verifier** (المدقّق) – الشخص أو الفريق الذي يراجع تطبيقًا مقابل متطلبات OWASP ASVS. +* **Verifier** (المدقّق) – الشخص أو الفريق الذي يراجع تطبيقًا مقابل متطلبات معيار OWASP للتحقق من أمان التطبيقات. * **Web Real-Time Communication** (WebRTC، اتصالات الويب في الوقت الحقيقي) – حزمة بروتوكولات وواجهة برمجة تطبيقات ويب مرتبطة بها تُستخدم لنقل تدفقات الوسائط المتعددة في تطبيقات الويب، عادةً في سياق المؤتمرات المرئية. تستند إلى SRTP وSRTCP وDTLS وSDP وSTUN/TURN. * **WebSocket over TLS** (WSS) – ممارسة تأمين اتصالات WebSocket عن طريق تشغيل WebSocket فوق بروتوكول TLS. * **What You See Is What You Get** (WYSIWYG، ما تراه هو ما تحصل عليه) – نوع من محرّرات المحتوى الغني يُظهر كيف سيبدو المحتوى فعليًا عند عرضه بدلًا من إظهار الشيفرة المستخدمة للتحكّم في العرض. diff --git a/5.0/ar/0x91-Appendix-B_References.md b/5.0/ar/0x91-Appendix-B_References.md index cddb7a4597..ccde6c6cc4 100644 --- a/5.0/ar/0x91-Appendix-B_References.md +++ b/5.0/ar/0x91-Appendix-B_References.md @@ -10,11 +10,11 @@ 4. OWASP Software Assurance Maturity Model (SAMM): [https://owasp.org/www-project-samm/](https://owasp.org/www-project-samm/) 5. OWASP Secure Headers Project: [https://owasp.org/www-project-secure-headers/](https://owasp.org/www-project-secure-headers/) -## مشروع OWASP Cheat Sheet Series +## مشروع سلسلة الأوراق المرجعية من OWASP -[هذا المشروع](https://owasp.org/www-project-cheat-sheets/) يضم عدة أوراق مرجعية ذات صلة بمواضيع مختلفة في ASVS. +[هذا المشروع](https://owasp.org/www-project-cheat-sheets/) يضم عدة أوراق مرجعية ذات صلة بمواضيع مختلفة في معيار التحقق من أمان التطبيقات. -وهناك تخطيط إلى ASVS يمكن الاطلاع عليه هنا: [https://cheatsheetseries.owasp.org/IndexASVS.html](https://cheatsheetseries.owasp.org/IndexASVS.html) +وهناك تخطيط إلى معيار التحقق من أمان التطبيقات يمكن الاطلاع عليه هنا: [https://cheatsheetseries.owasp.org/IndexASVS.html](https://cheatsheetseries.owasp.org/IndexASVS.html) ## المشاريع المتعلقة بأمان الأجهزة المحمولة diff --git a/5.0/ar/0x92-Appendix-C_Cryptography.md b/5.0/ar/0x92-Appendix-C_Cryptography.md index 93f5cebec4..be5bb249fc 100644 --- a/5.0/ar/0x92-Appendix-C_Cryptography.md +++ b/5.0/ar/0x92-Appendix-C_Cryptography.md @@ -1,33 +1,33 @@ -# Appendix C: Cryptography Standards +# الملحق ج: معايير التشفير -The "Cryptography" chapter goes beyond simply defining best practices. It aims to enhance understanding of cryptography principles and encourage the adoption of more resilient, modern security methods. This appendix provides detailed technical information regarding each requirement, complementing the overarching standards outlined in the "Cryptography" chapter. +يتجاوز فصل "التشفير" مجرّد تحديد الممارسات الفضلى. فهو يهدف إلى تعزيز فهم مبادئ التشفير والتشجيع على تبنّي طرائق أمنية أكثر صمودًا وحداثة. ويوفّر هذا الملحق معلومات تقنية مفصّلة عن كل متطلب، مكمّلًا المعايير الشاملة المبيّنة في فصل "التشفير". -This appendix defines the level of approval for different cryptographic mechanisms: +يحدّد هذا الملحق مستوى الاعتماد لآليات التشفير المختلفة: -* Approved (A) mechanisms can be used in applications. -* Legacy mechanisms (L) should not be used in applications but might still be used for compatibility with existing legacy applications or code onyly. While the usage of such these mechanisms is currently not considered to be a vulnerability in itself, they should be replaced by more secure and future-proof mechanisms as soon as possible. -* Disallowed mechanisms (D) must not be used because they are currently considered broken or do not provide sufficient security. +* الآليات المعتمدة (A) يمكن استخدامها في التطبيقات. +* الآليات القديمة (L) لا ينبغي استخدامها في التطبيقات لكن قد تبقى مستخدمة للتوافق مع التطبيقات أو الشيفرات القديمة القائمة فقط. ومع أن استخدام هذه الآليات لا يُعدّ حاليًا ثغرة في حد ذاته، فينبغي استبدالها بآليات أكثر أمانًا وأصمد للمستقبل في أسرع وقت ممكن. +* الآليات الممنوعة (D) يجب ألا تُستخدم لأنها تُعدّ حاليًا مكسورة أو لا توفّر أمانًا كافيًا. -This list may be overridden in the context of a given application for various reasons including: +وقد تُتجاوز هذه القائمة في سياق تطبيق معيّن لأسباب متنوعة منها: -* new evolutions in the field of cryptography; -* compliance with regulation. +* التطورات الجديدة في مجال التشفير؛ +* الامتثال للتنظيمات. -## Cryptographic Inventory and Documentation +## جرد التشفير وتوثيقه -This section provides additional information -for V11.1 Cryptographic Inventory and Documentation. +يوفّر هذا القسم معلومات إضافية +عن V11.1 جرد التشفير وتوثيقه. -It is important to ensure that all cryptographic assets, such as algorithms, keys, and certificates, are regularly discovered, inventoried, and assessed. For Level 3, this should include the use of static and dynamic scanning to discover the use of cryptography in an application. Tools such as SAST and DAST may help with this but it is possible that dedicated tools would be needed to get more comprehensive coverage. Freeware examples of tools include: +من المهم التأكد من أن جميع الأصول التشفيرية، مثل الخوارزميات والمفاتيح والشهادات، تُستكشف وتُجرد وتُقيَّم بانتظام. وبالنسبة إلى المستوى 3، ينبغي أن يشمل ذلك استخدام الفحص الساكن والديناميكي لاستكشاف استخدام التشفير في التطبيق. وقد تساعد أدوات مثل SAST وDAST في ذلك، لكن من المحتمل أن تكون هناك حاجة إلى أدوات مخصّصة للحصول على تغطية أشمل. ومن أمثلة الأدوات المجانية: * [CryptoMon - Network Cryptography Monitor - using eBPF, written in python](https://github.com/Santandersecurityresearch/CryptoMon) * [Cryptobom Forge Tool: Generating Comprehensive CBOMs from CodeQL Outputs](https://github.com/Santandersecurityresearch/cryptobom-forge) -## Equivalent Strengths of Cryptographic Parameters +## القوى المكافئة لمعاملات التشفير -The relative security strengths for various cryptographic systems are in this table (from [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), p.71): +ترد القوى الأمنية النسبية لأنظمة تشفير متنوعة في هذا الجدول (من [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final)، ص. 71): -| Security Strength | Symmetric Key Algorithms | Finite Field | Integer Factorisation | Elliptic Curve | +| القوة الأمنية | خوارزميات المفتاح المتناظر | الحقل المنتهي | تحليل الأعداد الصحيحة إلى عوامل | المنحنى الإهليلجي | |--|--|--|--|--| | <= 80 | 2TDEA | L = 1024
N = 160 | k = 1024 | f = 160-223 | | 112 | 3TDEA | L = 2048
N = 224 | k = 2048 | f = 224-255 | @@ -35,20 +35,20 @@ The relative security strengths for various cryptographic systems are in this ta | 192 | AES-192 | L = 7680
N = 384 | k = 7680 | f = 384-511 | | 256 | AES-256 | L = 15360
N = 512 | k = 15360 | f = 512+ | -Example of applications: +أمثلة على التطبيقات: -* Finite Field Cryptography: DSA, FFDH, MQV -* Integer Factorisation Cryptography: RSA -* Elliptic Curve Cryptography: ECDSA, EdDSA, ECDH, MQV +* تشفير الحقل المنتهي: DSA وFFDH وMQV +* تشفير تحليل الأعداد الصحيحة إلى عوامل: RSA +* تشفير المنحنيات الإهليلجية: ECDSA وEdDSA وECDH وMQV -Note: that this section assumes that no quantum computer exists; if such a computer would exist, the estimates for the last 3 columns would be no longer valid. +ملاحظة: يفترض هذا القسم عدم وجود حاسوب كمومي؛ فإذا وُجد مثل هذا الحاسوب، فلن تبقى التقديرات في الأعمدة الثلاثة الأخيرة صالحة. -## Random Values +## القيم العشوائية -This section provides additional information -for V11.5 Random Values. +يوفّر هذا القسم معلومات إضافية +عن V11.5 القيم العشوائية. -| Name | Version/Reference | Notes | Status | +| الاسم | الإصدار/المرجع | ملاحظات | الحالة | |:---|:----|:----|:-:| | `/dev/random` | Linux 4.8+ [(Oct 2016)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=818e607b57c94ade9824dad63a96c2ea6b21baf3), also found in iOS, Android, and other Linux-based POSIX operating systems. Based on [RFC7539](https://datatracker.ietf.org/doc/html/rfc7539) | Utilizing ChaCha20 stream. Found in iOS [`SecRandomCopyBytes`](https://developer.apple.com/documentation/security/secrandomcopybytes(_:_:_:)?language=objc) and Android [`Secure Random`](https://developer.android.com/reference/java/security/SecureRandom) with the correct settings provided to each. | A | | `/dev/urandom` | Linux kernel's special file for providing random data | Provides high-quality, entropy sources from hardware randomness | A | @@ -57,16 +57,16 @@ for V11.5 Random Values. | `Hash-DRBG` | [NIST SP800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) | | A | | `getentropy()` | [OpenBSD](https://man.openbsd.org/getentropy.2), available in [Linux glibc 2.25+](https://man7.org/linux/man-pages/man3/getentropy.3.html) and [macOS 10.12+](https://support.apple.com/en-gb/guide/security/seca0c73a75b/web) | Provides secure random bytes directly from the kernel's entropy source with a straightforward and minimal API. It’s more modern and avoids pitfalls associated with older APIs. | A | -The underlying hash function used with HMAC-DRBG or Hash-DRBG must be approved for this usage. +يجب أن تكون دالة التلبيد الأساسية المستخدمة مع HMAC-DRBG أو Hash-DRBG معتمدة لهذا الاستخدام. -## Cipher Algorithms +## خوارزميات التشفير -This section provides additional information -for V11.3 Encryption Algorithms. +يوفّر هذا القسم معلومات إضافية +عن V11.3 خوارزميات التشفير. -Approved cipher algorithms are listed in order of preference. +خوارزميات التشفير المعتمدة مدرجة بترتيب التفضيل. -| Symmetric Key Algorithms | Reference | Status | +| خوارزميات المفتاح المتناظر | المرجع | الحالة | | ------ | ------ |:-:| | AES-256 | [FIPS 197](https://csrc.nist.gov/pubs/fips/197/final) | A | | Salsa20 | [Salsa 20 specification](https://cr.yp.to/snuffle/spec.pdf) | A | @@ -83,13 +83,13 @@ Approved cipher algorithms are listed in order of preference. | ARC4 | | D | | DES | | D | -### AES Cipher Modes +### أنماط تشفير AES -Block ciphers, such as AES, can be used with different modes of operations. Many modes of operations, such as Electronic codebook (ECB), are insecure and must not be used. The Galois/Counter Mode (GCM) and Counter with cipher block chaining message authentication code (CCM) modes of operations provide authenticated encryption and should be used in modern applications. +يمكن استخدام تشفيرات الكتل، مثل AES، مع أنماط تشغيل مختلفة. وكثير من أنماط التشغيل، مثل كتاب الشيفرة الإلكتروني (ECB)، غير آمن ويجب ألا يُستخدم. أما نمط جالوا/العدّاد (GCM) ونمط العدّاد مع رمز مصادقة رسالة تسلسل كتل التشفير (CCM) فيوفّران تشفيرًا مصادَقًا عليه وينبغي استخدامهما في التطبيقات الحديثة. -Approved modes are listed in order of preference. +الأنماط المعتمدة مدرجة بترتيب التفضيل. -| Mode | Authenticated | Reference | Status | Restriction | +| النمط | مصادَق عليه | المرجع | الحالة | القيد | |--|--|--|:-:|--| | GCM | Yes | [NIST SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final) | A | | | CCM | Yes | [NIST SP 800-38C](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final) | A | | @@ -100,38 +100,38 @@ Approved modes are listed in order of preference. | OFB | No | | D | | | CTR | No | | D | | -Notes: +ملاحظات: -* All encrypted messages must be authenticated. For ANY use of CBC mode there MUST be an associated hashing MAC algorithm to validate the message. In general, this MUST be applied in the Encrypt-Then-Hash method (but TLS 1.2 uses Hash-Then-Encrypt instead). If this cannot be guaranteed, then CBC MUST NOT be used. The only application where encryption without a MAC algorithm is allowed is disk encryption. -* If CBC is used, it shall be guaranteed that the verification of the padding is performed in constant time. -* When using CCM-8, the MAC tag only has 64 bits of security. This does not conform to requirement 6.2.9 which requires at least 128 bits of security. -* Disk encryption is considered out of scope for the ASVS. Therefore this appendix does not list any approved method for disk encryption. For this usage, encryption without authentication is usually accepted and the XTS, XEX and LRW modes are typically used. +* يجب أن تكون جميع الرسائل المشفّرة مصادَقًا عليها. ولأي استخدام لنمط CBC يجب أن تكون هناك خوارزمية MAC تلبيدية مرتبطة به للتحقق من الرسالة. وعمومًا، يجب تطبيق ذلك بطريقة التشفير ثم التلبيد (لكن TLS 1.2 يستخدم التلبيد ثم التشفير بدلًا من ذلك). وإذا لم يكن من الممكن ضمان ذلك، فيجب ألا يُستخدم CBC. والتطبيق الوحيد الذي يُسمح فيه بالتشفير دون خوارزمية MAC هو تشفير الأقراص. +* في حال استخدام CBC، يجب ضمان أن التحقق من الحشو يُنفَّذ في زمن ثابت. +* عند استخدام CCM-8، لا تمتلك وسيمة MAC سوى 64 بتًا من الأمان. وهذا لا يتوافق مع المتطلب 6.2.9 الذي يقتضي 128 بتًا من الأمان على الأقل. +* يُعدّ تشفير الأقراص خارج نطاق معيار التحقق من أمان التطبيقات. ولذلك لا يُدرج هذا الملحق أي طريقة معتمدة لتشفير الأقراص. ولهذا الاستخدام، يُقبل عادةً التشفير دون مصادقة وتُستخدم عادةً الأنماط XTS وXEX وLRW. -### Key Wrapping +### تغليف المفاتيح -Cryptographic key wrap (and corresponding key unwrap) is a method of protecting an existing key by encapsulating (i.e., wrapping) it by employing an additional encryption mechanism so that the original key is not obviously exposed, e.g., during a transfer. This additional key used to protect the original key is referred to as the wrap key. +تغليف المفاتيح التشفيري (وما يقابله من فك التغليف) طريقة لحماية مفتاح قائم بتغليفه (أي تطويقه) باستخدام آلية تشفير إضافية بحيث لا يكون المفتاح الأصلي مكشوفًا بجلاء، مثلًا أثناء النقل. ويُشار إلى هذا المفتاح الإضافي المستخدم لحماية المفتاح الأصلي بمفتاح التغليف. -This operation may be performed when it is desirable to protect keys in places deemed untrustworthy, or to send sensitive keys over untrusted networks or within applications. -However, serious consideration should be given to understanding the nature (e.g., the identity and the purpose) of the original key prior to committing to a wrap/unwrap procedure as this may have repercussions for both source and target systems/applications in terms of security and especially compliance which may include audit trails of a key's function (e.g., signing) as well as appropriate key storage. +وقد تُنفَّذ هذه العملية عندما يكون من المرغوب حماية المفاتيح في أماكن تُعدّ غير موثوقة، أو إرسال مفاتيح حساسة عبر شبكات غير موثوقة أو داخل التطبيقات. +لكن ينبغي إيلاء اعتبار جدّي لفهم طبيعة المفتاح الأصلي (مثل هويته والغرض منه) قبل الإقدام على إجراء تغليف/فك تغليف، إذ قد تكون لذلك تبعات على الأنظمة أو التطبيقات المصدر والهدف على حد سواء من حيث الأمان، وخصوصًا الامتثال، الذي قد يشمل مسارات تدقيق لوظيفة المفتاح (مثل التوقيع) وكذلك التخزين الملائم للمفاتيح. -Specifically, AES-256 MUST be used for key wrapping, following [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) and considering forward-looking provisions against the quantum threat. Cipher modes using AES are the following, in order of preference: +وعلى وجه التحديد، يجب استخدام AES-256 لتغليف المفاتيح، وفقًا لـ [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) ومع مراعاة الأحكام الاستشرافية ضد التهديد الكمومي. وأنماط التشفير التي تستخدم AES هي التالية، بترتيب التفضيل: -| Key Wrapping | Reference | Status | +| تغليف المفاتيح | المرجع | الحالة | |--|--|:-:| | KW | [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) | A | | KWP | [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) | A | -AES-192 and AES-128 MAY be used if the use case demands it, but its motivation MUST be documented in the entity's cryptography inventory. +ويمكن استخدام AES-192 وAES-128 إذا اقتضت حالة الاستخدام ذلك، لكن يجب توثيق مبرّر ذلك في جرد التشفير الخاص بالجهة. -### Authenticated Encryption +### التشفير المصادَق عليه -With the exception of disk encryption, encrypted data must be protected against unauthorized modification using some form of authenticated encryption (AE) scheme, usually using an authenticated encryption with associated data (AEAD) scheme. +باستثناء تشفير الأقراص، يجب حماية البيانات المشفّرة من التعديل غير المصرَّح به باستخدام صورة ما من مخططات التشفير المصادَق عليه (AE)، وعادةً باستخدام مخطط التشفير المصادَق عليه مع البيانات المرتبطة (AEAD). -The application should preferably use an approved AEAD scheme. It might alternatively combine an approved cipher scheme and an approved MAC algorithm with a Encrypt-then-MAC construct. +وينبغي للتطبيق أن يستخدم مخطط AEAD معتمدًا تفضيلًا. وقد يجمع بدلًا من ذلك بين مخطط تشفير معتمد وخوارزمية MAC معتمدة ببنية التشفير ثم MAC. -MAC-then-encrypt is still allowed for compatibility with legacy applications. It is used in TLS v1.2 with old ciphers suites. +ولا يزال التلبيد ثم التشفير مسموحًا به للتوافق مع التطبيقات القديمة. وهو مستخدم في TLS v1.2 مع مجموعات التشفير القديمة. -| AEAD mechanism | Reference | Status | +| آلية AEAD | المرجع | الحالة | |---|---------|:-:| |AES-GCM | [SP 800-38D](https://csrc.nist.gov/pubs/sp/800/38/d/final) | A | |AES-CCM | [SP 800-38C](https://csrc.nist.gov/pubs/sp/800/38/c/upd1/final) | A | @@ -142,20 +142,20 @@ MAC-then-encrypt is still allowed for compatibility with legacy applications. It |Encrypt-then-MAC | | A | |MAC-then-encrypt | | L | -## Hash Functions +## دوالّ التلبيد -This section provides additional information -for V11.4 Hashing and Hash-based Functions. +يوفّر هذا القسم معلومات إضافية +عن V11.4 التلبيد والدوالّ المبنية على التلبيد. -### Hash Functions for General Use Cases +### دوالّ التلبيد لحالات الاستخدام العامة -The following table lists hash functions approved in general cryptographic use cases such as digital signatures: +يسرد الجدول التالي دوالّ التلبيد المعتمدة في حالات الاستخدام التشفيري العامة مثل التوقيعات الرقمية: -* Approved hash functions provide strong collision resistance and are suitable for high-security applications. -* Some of these algorithms offer strong resistance to attacks when used with proper cryptographic key management, and so are additionally approved for HMAC, KDF, and RBG functions. -* Hash function with less than 254 bit of output have insufficient collision resistancea and must not be used for digital signature or other applications requiring collision resistance. For other usages, they might be used for compatibility and verification ONLY with legacy systems but must not be used in new designs. +* توفّر دوالّ التلبيد المعتمدة مقاومة قوية للتصادم وهي ملائمة للتطبيقات عالية الأمان. +* توفّر بعض هذه الخوارزميات مقاومة قوية للهجمات عند استخدامها مع إدارة سليمة لمفاتيح التشفير، ولذلك فهي معتمدة إضافةً إلى ذلك لدوالّ HMAC وKDF وRBG. +* دوالّ التلبيد التي يقل طول مخرَجها عن 254 بتًا لا تمتلك مقاومة كافية للتصادم ويجب ألا تُستخدم للتوقيع الرقمي أو غيره من التطبيقات التي تقتضي مقاومة التصادم. أما للاستخدامات الأخرى، فقد تُستخدم للتوافق والتحقق مع الأنظمة القديمة فقط، لكن يجب ألا تُستخدم في التصاميم الجديدة. -| Hash function | Reference | Status | Restrictions | +| دالة التلبيد | المرجع | الحالة | القيود | | ------ | ----------- |:-:| ---------- | | SHA3-512 |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | A | | | SHA-512 |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | A | | @@ -176,77 +176,77 @@ The following table lists hash functions approved in general cryptographic use c | MD4 | [RFC 1320](https://www.rfc-editor.org/info/rfc1320) | D | | | MD5 | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | | -### Hash Functions for Password Storage +### دوالّ التلبيد لتخزين كلمات المرور -For secure password hashing, dedicated hash functions must be used. These slow-hashing algorithms mitigate brute-force and dictionary attacks by increasing the computational difficulty of password cracking. +لتلبيد كلمات المرور بأمان، يجب استخدام دوالّ تلبيد مخصّصة. وتخفّف خوارزميات التلبيد البطيء هذه من هجمات القوة الغاشمة وهجمات القواميس بزيادة الصعوبة الحسابية لكسر كلمات المرور. -| KDF | Reference | Required Parameters | Status | +| KDF | المرجع | المعاملات المطلوبة | الحالة | | ---------- | --------- | ------------ |:-:| -| argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | t = 1: m ≥ 47104 (46 MiB), p = 1 | A | -| | | t = 2: m ≥ 19456 (19 MiB), p = 1 | A | -| | | t ≥ 3: m ≥ 12288 (12 MiB), p = 1 | A | -| scrypt | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | p = 1: N ≥ 2^17 (128 MiB), r = 8 | A | -| | | p = 2: N ≥ 2^16 (64 MiB), r = 8 | A | -| | | p ≥ 3: N ≥ 2^15 (32 MiB), r = 8 | A | -| bcrypt | [A Future-Adaptable Password Scheme](https://www.researchgate.net/publication/2519476_A_Future-Adaptable_Password_Scheme) | cost ≥ 10 | A | -| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 210,000 | A | -| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 600,000 | A | -| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 1,300,000 | L | +| argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | t = 1: m >= 47104 (46 MiB), p = 1 | A | +| | | t = 2: m >= 19456 (19 MiB), p = 1 | A | +| | | t >= 3: m >= 12288 (12 MiB), p = 1 | A | +| scrypt | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | p = 1: N >= 2^17 (128 MiB), r = 8 | A | +| | | p = 2: N >= 2^16 (64 MiB), r = 8 | A | +| | | p >= 3: N >= 2^15 (32 MiB), r = 8 | A | +| bcrypt | [A Future-Adaptable Password Scheme](https://www.researchgate.net/publication/2519476_A_Future-Adaptable_Password_Scheme) | cost >= 10 | A | +| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations >= 210,000 | A | +| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations >= 600,000 | A | +| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations >= 1,300,000 | L | -Approved password-based key derivations functions can be used for password storage. +ويمكن استخدام دوالّ اشتقاق المفاتيح المعتمدة القائمة على كلمات المرور لتخزين كلمات المرور. -## Key Derivation Functions (KDFs) +## دوالّ اشتقاق المفاتيح (KDFs) -### General Key Derivation Functions +### دوالّ اشتقاق المفاتيح العامة -| KDF | Reference | Status | +| KDF | المرجع | الحالة | | ---------------- | -------- |:-:| | HKDF | [RFC 5869](https://www.rfc-editor.org/info/rfc5869) | A | | TLS 1.2 PRF | [RFC 5248](https://www.rfc-editor.org/info/rfc5248) | L | | MD5-based KDFs | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | | SHA-1-based KDFs | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) | D | -### Password-based Key Derivation Functions +### دوالّ اشتقاق المفاتيح القائمة على كلمات المرور -| KDF | Reference | Required Parameters | Status | +| KDF | المرجع | المعاملات المطلوبة | الحالة | | ---------- | --------- | ------------ |:-:| -| argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | t = 1: m ≥ 47104 (46 MiB), p = 1 | A | -| | | t = 2: m ≥ 19456 (19 MiB), p = 1 | A | -| scrypt | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | p = 1: N ≥ 2^17 (128 MiB), r = 8 | A | -| | | p = 2: N ≥ 2^16 (64 MiB), r = 8 | A | -| | | p ≥ 3: N ≥ 2^15 (32 MiB), r = 8 | A | -| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 210,000 | A | -| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 600,000 | A | -| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations ≥ 1,300,000 | L | +| argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | t = 1: m >= 47104 (46 MiB), p = 1 | A | +| | | t = 2: m >= 19456 (19 MiB), p = 1 | A | +| scrypt | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | p = 1: N >= 2^17 (128 MiB), r = 8 | A | +| | | p = 2: N >= 2^16 (64 MiB), r = 8 | A | +| | | p >= 3: N >= 2^15 (32 MiB), r = 8 | A | +| PBKDF2-HMAC-SHA-512 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations >= 210,000 | A | +| PBKDF2-HMAC-SHA-256 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations >= 600,000 | A | +| PBKDF2-HMAC-SHA-1 | [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final), [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | iterations >= 1,300,000 | L | -## Key Exchange Mechanisms +## آليات تبادل المفاتيح -This section provides additional information -for V11.6 Public Key Cryptography. +يوفّر هذا القسم معلومات إضافية +عن V11.6 تشفير المفتاح العام. -### KEX Schemes +### مخططات تبادل المفاتيح -A security strength of 112 bits or above MUST be ensured for all Key Exchange schemes, and their implementation MUST follow the parameter choices in the following table. +يجب ضمان قوة أمنية قدرها 112 بتًا أو أكثر لجميع مخططات تبادل المفاتيح، ويجب أن يتّبع تنفيذها اختيارات المعاملات الواردة في الجدول التالي. -| Scheme | Domain Parameters | Forward Secrecy |Status | +| المخطط | معاملات المجال | السرّية التامة للتوجيه |الحالة | |--|--|--|:-:| | Finite Field Diffie-Hellman (FFDH) | L >= 3072 & N >= 256 | Yes | A | | Elliptic Curve Diffie-Hellman (ECDH) | f >= 256-383 | Yes | A | | Encrypted key transport with RSA-PKCS#1 v1.5 | | No | D | -Where the following parameters are: +حيث المعاملات التالية هي: -* k is the key size for RSA keys. -* L is the size of the public key and N is the size of the private key for finite field cryptography. -* f is the range of key sizes for ECC. +* k هو حجم المفتاح لمفاتيح RSA. +* L هو حجم المفتاح العام وN هو حجم المفتاح الخاص لتشفير الحقل المنتهي. +* f هو نطاق أحجام المفاتيح لتشفير المنحنيات الإهليلجية (ECC). -Any new implementation MUST NOT use any scheme that is NOT compliant with [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final) & [B](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final) and [NIST SP 800-77](https://csrc.nist.gov/pubs/sp/800/77/r1/final). Specifically, IKEv1 MUST NOT be used in production. +ويجب ألا يستخدم أي تنفيذ جديد أي مخطط غير متوافق مع [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final) و[B](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final) و[NIST SP 800-77](https://csrc.nist.gov/pubs/sp/800/77/r1/final). وعلى وجه التحديد، يجب ألا يُستخدم IKEv1 في الإنتاج. -### Diffie-Hellman groups +### مجموعات ديفي-هيلمان -The following groups are approved for implementations of Diffie-Hellman key exchange. Security strengths are documented in [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final), Appendix D, and [NIST SP 800-57 Part 1 Rev.5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final). +المجموعات التالية معتمدة لتنفيذات تبادل المفاتيح بطريقة ديفي-هيلمان. والقوى الأمنية موثّقة في [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final)، الملحق د، وفي [NIST SP 800-57 Part 1 Rev.5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final). -| Group | Status | +| المجموعة | الحالة | |------------------|:------:| | P-224, secp224r1 | A | | P-256, secp256r1 | A | @@ -273,11 +273,11 @@ The following groups are approved for implementations of Diffie-Hellman key exch | ffdhe6144 | A | | ffdhe8192 | A | -## Message Authentication Codes (MAC) +## رموز مصادقة الرسائل (MAC) -Message Authentication Codes (MACs) are cryptographic constructs used to verify the integrity and authenticity of a message. A MAC takes a message and a secret key as inputs and produces a fixed-size tag (the MAC value). MACs are widely used in secure communication protocols (e.g., TLS/SSL) to ensure that messages exchanged between parties are authentic and intact. +رموز مصادقة الرسائل (MACs) بِنى تشفيرية تُستخدم للتحقق من سلامة الرسالة وأصالتها. ويأخذ رمز MAC رسالة ومفتاحًا سرّيًا كمدخلات وينتج وسيمة ثابتة الحجم (قيمة MAC). وتُستخدم رموز MAC على نطاق واسع في بروتوكولات الاتصال الآمن (مثل TLS/SSL) لضمان أن الرسائل المتبادلة بين الأطراف أصيلة وسليمة. -| MAC Algorithm | Reference | Status | +| خوارزمية MAC | المرجع | الحالة | | ---------- | --------------- |:-:| | HMAC-SHA-256 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A | | HMAC-SHA-384 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | A | @@ -291,11 +291,11 @@ Message Authentication Codes (MACs) are cryptographic constructs used to verify | HMAC-SHA-1 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | L | | HMAC-MD5 | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) | D | -## Digital Signatures +## التوقيعات الرقمية -Signature schemes MUST use approved key sizes and parameters per [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final). +يجب أن تستخدم مخططات التوقيع أحجام مفاتيح ومعاملات معتمدة وفق [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final). -| Signature Algorithm | Reference | Status | +| خوارزمية التوقيع | المرجع | الحالة | | ------------------------------ | --------------------------------------------- | :-: | | EdDSA (Ed25519, Ed448) | [RFC 8032](https://www.rfc-editor.org/info/rfc8032) | A | | XEdDSA (Curve25519, Curve448) | [XEdDSA](https://signal.org/docs/specifications/xeddsa/) | A | @@ -304,8 +304,8 @@ Signature schemes MUST use approved key sizes and parameters per [NIST SP 800-57 | RSA-SSA-PKCS#1 v1.5 | [RFC 8017](https://www.rfc-editor.org/info/rfc8017) | D | | DSA (any key size) | [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-4/final) | D | -## Post-Quantum Encryption Standards +## معايير التشفير ما بعد الكمومي -PQC implementations must be in line with [FIPS-203](https://csrc.nist.gov/pubs/fips/203/ipd)/[204](https://csrc.nist.gov/pubs/fips/204/ipd)/[205](https://csrc.nist.gov/pubs/fips/205/ipd) as there is minimal hardened code nor implementation reference yet. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards +يجب أن تكون تنفيذات التشفير ما بعد الكمومي متوافقة مع [FIPS-203](https://csrc.nist.gov/pubs/fips/203/ipd)/[204](https://csrc.nist.gov/pubs/fips/204/ipd)/[205](https://csrc.nist.gov/pubs/fips/205/ipd) إذ لا يوجد بعد سوى قدر ضئيل من الشيفرات المحصّنة أو المراجع التنفيذية. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards -The proposed [mlkem768x25519](https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/03/) post-quantum hybrid TLS key agreement method is supported by major browsers such as [Firefox release 132](https://www.mozilla.org/en-US/firefox/132.0/releasenotes/) and [Chrome release 131](https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html). It may be used in cryptographic testing environments or when available within industry- or government-approved libraries. +طريقة اتفاق المفاتيح الهجينة ما بعد الكمومية المقترحة [mlkem768x25519](https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/03/) لـ TLS مدعومة من متصفحات رئيسية مثل [Firefox release 132](https://www.mozilla.org/en-US/firefox/132.0/releasenotes/) و[Chrome release 131](https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html). ويمكن استخدامها في بيئات الاختبار التشفيري أو عند توافرها في مكتبات معتمدة صناعيًا أو حكوميًا. diff --git a/5.0/ar/0x93-Appendix-D_Recommendations.md b/5.0/ar/0x93-Appendix-D_Recommendations.md index 29d8c85102..1abdd02fc8 100644 --- a/5.0/ar/0x93-Appendix-D_Recommendations.md +++ b/5.0/ar/0x93-Appendix-D_Recommendations.md @@ -2,13 +2,13 @@ ## مقدمة -أثناء إعداد الإصدار 5.0 من معيار التحقق من أمان التطبيقات (ASVS)، اتضح أن هناك عددًا من البنود القائمة والمقترحة حديثًا التي لا ينبغي إدراجها كمتطلبات في الإصدار 5.0. وقد يكون ذلك لأنها لم تكن داخل نطاق ASVS وفق تعريف الإصدار 5.0، أو بدلًا من ذلك لأنه رُئي أنها، وإن كانت فكرة جيدة، لا يمكن جعلها إلزامية. +أثناء إعداد الإصدار 5.0 من معيار التحقق من أمان التطبيقات (ASVS)، اتضح أن هناك عددًا من البنود القائمة والمقترحة حديثًا التي لا ينبغي إدراجها كمتطلبات في الإصدار 5.0. وقد يكون ذلك لأنها لم تكن داخل نطاق معيار التحقق من أمان التطبيقات وفق تعريف الإصدار 5.0، أو بدلًا من ذلك لأنه رُئي أنها، وإن كانت فكرة جيدة، لا يمكن جعلها إلزامية. ولعدم الرغبة في فقدان كل هذه البنود تمامًا، فقد ضُمّ بعضها في هذا الملحق. ## آليات موصى بها وداخلة في النطاق -البنود التالية داخلة في نطاق ASVS. ولا ينبغي جعلها إلزامية، لكن يُوصى بقوة بالنظر فيها كجزء من تطبيق آمن. +البنود التالية داخلة في نطاق معيار التحقق من أمان التطبيقات. ولا ينبغي جعلها إلزامية، لكن يُوصى بقوة بالنظر فيها كجزء من تطبيق آمن. * ينبغي توفير مقياس لقوة كلمة المرور لمساعدة المستخدمين على تعيين كلمة مرور أقوى. * أنشئ ملف security.txt متاحًا للعموم في الجذر أو في مجلد .well-known الخاص بالتطبيق، يحدّد بوضوح رابطًا أو عنوان بريد إلكتروني ليتصل الناس بالمالكين بشأن المشكلات الأمنية. @@ -22,7 +22,7 @@ ## مبادئ أمان البرمجيات -كانت البنود التالية موجودة سابقًا في ASVS لكنها ليست متطلبات في الحقيقة. بل هي مبادئ ينبغي مراعاتها عند تنفيذ ضوابط الأمان، والتي يؤدي اتباعها إلى ضوابط أكثر متانة. وتشمل ما يلي: +كانت البنود التالية موجودة سابقًا في معيار التحقق من أمان التطبيقات لكنها ليست متطلبات في الحقيقة. بل هي مبادئ ينبغي مراعاتها عند تنفيذ ضوابط الأمان، والتي يؤدي اتباعها إلى ضوابط أكثر متانة. وتشمل ما يلي: * ينبغي أن تكون ضوابط الأمان مركزية وبسيطة (اقتصاد التصميم) وآمنة على نحو قابل للتحقق وقابلة لإعادة الاستخدام. وهذا ينبغي أن يمنع الضوابط المكرّرة أو المفقودة أو غير الفعّالة. * استخدم، حيثما أمكن، تنفيذات ضوابط أمان مكتوبة مسبقًا ومدروسة جيدًا بدلًا من الاعتماد على تنفيذ الضوابط من الصفر. @@ -31,7 +31,7 @@ ## عمليات أمان البرمجيات -هناك عدد من العمليات الأمنية التي أُزيلت من ASVS 5.0 لكنها لا تزال فكرة جيدة. وقد يكون مشروع OWASP SAMM مصدرًا جيدًا لمعرفة كيفية تنفيذ هذه العمليات بفعالية. وتشمل البنود التي كانت موجودة سابقًا في ASVS ما يلي: +هناك عدد من العمليات الأمنية التي أُزيلت من معيار التحقق من أمان التطبيقات 5.0 لكنها لا تزال فكرة جيدة. وقد يكون مشروع OWASP SAMM مصدرًا جيدًا لمعرفة كيفية تنفيذ هذه العمليات بفعالية. وتشمل البنود التي كانت موجودة سابقًا في معيار التحقق من أمان التطبيقات ما يلي: * تحقق من استخدام دورة حياة آمنة لتطوير البرمجيات تعالج الأمان في جميع مراحل التطوير. * تحقق من استخدام نمذجة التهديدات لكل تغيير في التصميم أو تخطيط لدورة عمل، لتحديد التهديدات والتخطيط للتدابير المضادة وتيسير الاستجابات الملائمة للمخاطر وتوجيه اختبار الأمان. diff --git a/5.0/ar/0x94-Appendix-E_Contributors.md b/5.0/ar/0x94-Appendix-E_Contributors.md index 79866b2357..e77eb82702 100644 --- a/5.0/ar/0x94-Appendix-E_Contributors.md +++ b/5.0/ar/0x94-Appendix-E_Contributors.md @@ -1,6 +1,6 @@ # الملحق هـ - المساهمون -نعرب عن امتناننا لإسهامات الأشخاص التالية أسماؤهم، الذين علّقوا أو فتحوا طلبات دمج منذ إصدار ASVS 4.0.0. +نعرب عن امتناننا لإسهامات الأشخاص التالية أسماؤهم، الذين علّقوا أو فتحوا طلبات دمج منذ إصدار معيار التحقق من أمان التطبيقات 4.0.0. وإذا كنت على علم بأي أخطاء أو كنت ترغب في ظهور اسمك بصورة مختلفة، فيُرجى إخبارنا.