From 1a7b2115daca5602718f9b51c75d24226879d5cd Mon Sep 17 00:00:00 2001 From: Jon Gadsden Date: Wed, 15 Jan 2025 09:10:04 +0000 Subject: [PATCH] create release directory for JA translation --- .gitignore | 32 +- .wordlist-ja.txt | 519 ++++++++++++++++++ release-ja/01-front.md | 21 + release-ja/02-toc.md | 140 +++++ release-ja/03-introduction.md | 95 ++++ release-ja/04-foundations/00-toc.md | 47 ++ .../01-security-fundamentals.md | 203 +++++++ .../04-foundations/02-secure-development.md | 241 ++++++++ .../04-foundations/03-security-principles.md | 214 ++++++++ .../04-foundations/04-crypto-principles.md | 268 +++++++++ release-ja/04-foundations/05-top-ten.md | 234 ++++++++ release-ja/04-foundations/info.md | 1 + release-ja/04-foundations/toc.md | 60 ++ release-ja/05-requirements/00-toc.md | 56 ++ release-ja/05-requirements/01-requirements.md | 123 +++++ release-ja/05-requirements/02-risk.md | 110 ++++ release-ja/05-requirements/03-opencre.md | 127 +++++ release-ja/05-requirements/04-security-rat.md | 125 +++++ release-ja/05-requirements/05-asvs.md | 117 ++++ release-ja/05-requirements/06-mas.md | 101 ++++ release-ja/05-requirements/07-skf.md | 91 +++ release-ja/05-requirements/info.md | 1 + release-ja/05-requirements/toc.md | 62 +++ release-ja/06-design/00-toc.md | 81 +++ .../06-design/01-threat-modeling/00-toc.md | 45 ++ .../01-threat-modeling/01-threat-modeling.md | 294 ++++++++++ .../06-design/01-threat-modeling/02-pytm.md | 131 +++++ .../01-threat-modeling/03-threat-dragon.md | 99 ++++ .../01-threat-modeling/04-cornucopia.md | 160 ++++++ .../01-threat-modeling/05-linddun-go.md | 80 +++ .../01-threat-modeling/06-toolkit.md | 73 +++ .../06-design/01-threat-modeling/info.md | 1 + .../06-design/01-threat-modeling/toc.md | 58 ++ .../06-design/02-web-app-checklist/00-toc.md | 50 ++ .../01-define-security-requirements.md | 82 +++ .../02-frameworks-libraries.md | 106 ++++ .../03-secure-database-access.md | 66 +++ .../04-encode-escape-data.md | 63 +++ .../05-validate-inputs.md | 78 +++ .../06-digital-identity.md | 118 ++++ .../07-access-controls.md | 61 ++ .../02-web-app-checklist/08-protect-data.md | 68 +++ .../09-logging-monitoring.md | 64 +++ .../10-handle-errors-exceptions.md | 59 ++ .../06-design/02-web-app-checklist/info.md | 1 + .../06-design/02-web-app-checklist/toc.md | 63 +++ release-ja/06-design/03-mas-checklist.md | 88 +++ release-ja/06-design/info.md | 1 + release-ja/06-design/toc.md | 94 ++++ release-ja/07-implementation/00-toc.md | 62 +++ .../01-documentation/00-toc.md | 39 ++ .../01-documentation/01-proactive-controls.md | 121 ++++ .../01-documentation/02-go-scp.md | 76 +++ .../01-documentation/03-cheatsheets.md | 95 ++++ .../01-documentation/info.md | 1 + .../07-implementation/01-documentation/toc.md | 52 ++ .../02-dependencies/00-toc.md | 51 ++ .../02-dependencies/01-dependency-check.md | 97 ++++ .../02-dependencies/02-dependency-track.md | 77 +++ .../02-dependencies/03-cyclonedx.md | 103 ++++ .../07-implementation/02-dependencies/info.md | 1 + .../07-implementation/02-dependencies/toc.md | 64 +++ .../03-secure-libraries/00-toc.md | 39 ++ .../03-secure-libraries/01-esapi.md | 96 ++++ .../03-secure-libraries/02-csrf-guard.md | 60 ++ .../03-secure-libraries/03-secure-headers.md | 73 +++ .../03-secure-libraries/info.md | 1 + .../03-secure-libraries/toc.md | 52 ++ release-ja/07-implementation/04-maswe.md | 97 ++++ release-ja/07-implementation/info.md | 1 + release-ja/07-implementation/toc.md | 75 +++ release-ja/08-verification/00-toc.md | 67 +++ .../08-verification/01-guides/00-toc.md | 40 ++ .../08-verification/01-guides/01-wstg.md | 100 ++++ .../08-verification/01-guides/02-mastg.md | 95 ++++ .../08-verification/01-guides/03-asvs.md | 117 ++++ release-ja/08-verification/01-guides/info.md | 1 + release-ja/08-verification/01-guides/toc.md | 53 ++ release-ja/08-verification/02-tools/00-toc.md | 43 ++ .../08-verification/02-tools/01-dast.md | 72 +++ .../08-verification/02-tools/02-amass.md | 67 +++ .../08-verification/02-tools/03-owtf.md | 69 +++ .../08-verification/02-tools/04-nettacker.md | 82 +++ .../02-tools/05-secure-headers.md | 71 +++ release-ja/08-verification/02-tools/info.md | 1 + release-ja/08-verification/02-tools/toc.md | 56 ++ .../08-verification/03-frameworks/00-toc.md | 41 ++ .../03-frameworks/01-secure-codebox.md | 102 ++++ .../08-verification/03-frameworks/info.md | 1 + .../08-verification/03-frameworks/toc.md | 54 ++ .../04-vulnerability-management/00-toc.md | 37 ++ .../01-defectdojo.md | 90 +++ .../04-vulnerability-management/info.md | 1 + .../04-vulnerability-management/toc.md | 50 ++ release-ja/08-verification/info.md | 1 + release-ja/08-verification/toc.md | 80 +++ release-ja/09-training-education/00-toc.md | 61 ++ .../01-vulnerable-apps/00-toc.md | 53 ++ .../01-vulnerable-apps/01-juice-shop.md | 103 ++++ .../01-vulnerable-apps/02-webgoat.md | 132 +++++ .../01-vulnerable-apps/03-pygoat.md | 84 +++ .../04-security-shepherd.md | 69 +++ .../01-vulnerable-apps/info.md | 1 + .../01-vulnerable-apps/toc.md | 66 +++ .../02-secure-coding-dojo.md | 71 +++ release-ja/09-training-education/03-skf.md | 75 +++ .../09-training-education/04-samurai-wtf.md | 100 ++++ .../09-training-education/05-top-ten.md | 94 ++++ .../06-mobile-top-ten.md | 103 ++++ .../09-training-education/07-api-top-ten.md | 66 +++ .../09-training-education/08-wrongsecrets.md | 86 +++ .../09-snakes-ladders.md | 101 ++++ release-ja/09-training-education/info.md | 1 + release-ja/09-training-education/toc.md | 74 +++ release-ja/10-culture-process/00-toc.md | 47 ++ .../10-culture-process/01-security-culture.md | 97 ++++ .../02-security-champions/00-toc.md | 61 ++ .../01-security-champions-program.md | 99 ++++ .../02-security-champions-guide.md | 99 ++++ .../03-security-champions-playbook.md | 55 ++ .../02-security-champions/info.md | 1 + .../02-security-champions/toc.md | 74 +++ release-ja/10-culture-process/03-samm.md | 103 ++++ release-ja/10-culture-process/04-asvs.md | 113 ++++ release-ja/10-culture-process/05-mas.md | 79 +++ release-ja/10-culture-process/info.md | 1 + release-ja/10-culture-process/toc.md | 60 ++ release-ja/11-operations/00-toc.md | 49 ++ release-ja/11-operations/01-devsecops.md | 80 +++ release-ja/11-operations/02-coraza.md | 78 +++ release-ja/11-operations/03-modsecurity.md | 61 ++ release-ja/11-operations/04-crs.md | 78 +++ release-ja/11-operations/info.md | 1 + release-ja/11-operations/toc.md | 62 +++ release-ja/12-metrics/00-toc.md | 61 ++ release-ja/12-metrics/info.md | 1 + release-ja/12-metrics/toc.md | 76 +++ release-ja/13-security-gap-analysis/00-toc.md | 46 ++ .../01-guides/00-toc.md | 39 ++ .../01-guides/01-samm.md | 129 +++++ .../01-guides/02-asvs.md | 83 +++ .../01-guides/03-mas.md | 92 ++++ .../01-guides/info.md | 1 + .../13-security-gap-analysis/01-guides/toc.md | 52 ++ release-ja/13-security-gap-analysis/02-blt.md | 61 ++ release-ja/13-security-gap-analysis/info.md | 1 + release-ja/13-security-gap-analysis/toc.md | 59 ++ release-ja/14-appendices/00-toc.md | 36 ++ .../01-implementation-dos-donts/00-toc.md | 39 ++ .../01-container-security.md | 140 +++++ .../02-secure-coding.md | 342 ++++++++++++ .../03-cryptographic-practices.md | 74 +++ .../04-application-spoofing.md | 82 +++ .../05-content-security-policy.md | 161 ++++++ .../06-exception-error-handling.md | 109 ++++ .../07-file-management.md | 51 ++ .../08-memory-management.md | 35 ++ .../01-implementation-dos-donts/info.md | 1 + .../01-implementation-dos-donts/toc.md | 52 ++ .../02-verification-dos-donts/00-toc.md | 35 ++ .../01-secure-environment.md | 75 +++ .../02-system-hardening.md | 81 +++ .../03-open-source-software.md | 117 ++++ .../02-verification-dos-donts/info.md | 1 + .../02-verification-dos-donts/toc.md | 48 ++ release-ja/14-appendices/info.md | 1 + release-ja/14-appendices/toc.md | 49 ++ release-ja/info.md | 1 + release-ja/title.pdf.yaml | 17 + release-ja/title.yaml | 12 + release-ja/toc.md | 146 +++++ 171 files changed, 12824 insertions(+), 16 deletions(-) create mode 100644 .wordlist-ja.txt create mode 100644 release-ja/01-front.md create mode 100644 release-ja/02-toc.md create mode 100644 release-ja/03-introduction.md create mode 100644 release-ja/04-foundations/00-toc.md create mode 100644 release-ja/04-foundations/01-security-fundamentals.md create mode 100644 release-ja/04-foundations/02-secure-development.md create mode 100644 release-ja/04-foundations/03-security-principles.md create mode 100644 release-ja/04-foundations/04-crypto-principles.md create mode 100644 release-ja/04-foundations/05-top-ten.md create mode 100644 release-ja/04-foundations/info.md create mode 100644 release-ja/04-foundations/toc.md create mode 100644 release-ja/05-requirements/00-toc.md create mode 100644 release-ja/05-requirements/01-requirements.md create mode 100644 release-ja/05-requirements/02-risk.md create mode 100644 release-ja/05-requirements/03-opencre.md create mode 100644 release-ja/05-requirements/04-security-rat.md create mode 100644 release-ja/05-requirements/05-asvs.md create mode 100644 release-ja/05-requirements/06-mas.md create mode 100644 release-ja/05-requirements/07-skf.md create mode 100644 release-ja/05-requirements/info.md create mode 100644 release-ja/05-requirements/toc.md create mode 100644 release-ja/06-design/00-toc.md create mode 100644 release-ja/06-design/01-threat-modeling/00-toc.md create mode 100644 release-ja/06-design/01-threat-modeling/01-threat-modeling.md create mode 100644 release-ja/06-design/01-threat-modeling/02-pytm.md create mode 100644 release-ja/06-design/01-threat-modeling/03-threat-dragon.md create mode 100644 release-ja/06-design/01-threat-modeling/04-cornucopia.md create mode 100644 release-ja/06-design/01-threat-modeling/05-linddun-go.md create mode 100644 release-ja/06-design/01-threat-modeling/06-toolkit.md create mode 100644 release-ja/06-design/01-threat-modeling/info.md create mode 100644 release-ja/06-design/01-threat-modeling/toc.md create mode 100644 release-ja/06-design/02-web-app-checklist/00-toc.md create mode 100644 release-ja/06-design/02-web-app-checklist/01-define-security-requirements.md create mode 100644 release-ja/06-design/02-web-app-checklist/02-frameworks-libraries.md create mode 100644 release-ja/06-design/02-web-app-checklist/03-secure-database-access.md create mode 100644 release-ja/06-design/02-web-app-checklist/04-encode-escape-data.md create mode 100644 release-ja/06-design/02-web-app-checklist/05-validate-inputs.md create mode 100644 release-ja/06-design/02-web-app-checklist/06-digital-identity.md create mode 100644 release-ja/06-design/02-web-app-checklist/07-access-controls.md create mode 100644 release-ja/06-design/02-web-app-checklist/08-protect-data.md create mode 100644 release-ja/06-design/02-web-app-checklist/09-logging-monitoring.md create mode 100644 release-ja/06-design/02-web-app-checklist/10-handle-errors-exceptions.md create mode 100644 release-ja/06-design/02-web-app-checklist/info.md create mode 100644 release-ja/06-design/02-web-app-checklist/toc.md create mode 100644 release-ja/06-design/03-mas-checklist.md create mode 100644 release-ja/06-design/info.md create mode 100644 release-ja/06-design/toc.md create mode 100644 release-ja/07-implementation/00-toc.md create mode 100644 release-ja/07-implementation/01-documentation/00-toc.md create mode 100644 release-ja/07-implementation/01-documentation/01-proactive-controls.md create mode 100644 release-ja/07-implementation/01-documentation/02-go-scp.md create mode 100644 release-ja/07-implementation/01-documentation/03-cheatsheets.md create mode 100644 release-ja/07-implementation/01-documentation/info.md create mode 100644 release-ja/07-implementation/01-documentation/toc.md create mode 100644 release-ja/07-implementation/02-dependencies/00-toc.md create mode 100644 release-ja/07-implementation/02-dependencies/01-dependency-check.md create mode 100644 release-ja/07-implementation/02-dependencies/02-dependency-track.md create mode 100644 release-ja/07-implementation/02-dependencies/03-cyclonedx.md create mode 100644 release-ja/07-implementation/02-dependencies/info.md create mode 100644 release-ja/07-implementation/02-dependencies/toc.md create mode 100644 release-ja/07-implementation/03-secure-libraries/00-toc.md create mode 100644 release-ja/07-implementation/03-secure-libraries/01-esapi.md create mode 100644 release-ja/07-implementation/03-secure-libraries/02-csrf-guard.md create mode 100644 release-ja/07-implementation/03-secure-libraries/03-secure-headers.md create mode 100644 release-ja/07-implementation/03-secure-libraries/info.md create mode 100644 release-ja/07-implementation/03-secure-libraries/toc.md create mode 100644 release-ja/07-implementation/04-maswe.md create mode 100644 release-ja/07-implementation/info.md create mode 100644 release-ja/07-implementation/toc.md create mode 100644 release-ja/08-verification/00-toc.md create mode 100644 release-ja/08-verification/01-guides/00-toc.md create mode 100644 release-ja/08-verification/01-guides/01-wstg.md create mode 100644 release-ja/08-verification/01-guides/02-mastg.md create mode 100644 release-ja/08-verification/01-guides/03-asvs.md create mode 100644 release-ja/08-verification/01-guides/info.md create mode 100644 release-ja/08-verification/01-guides/toc.md create mode 100644 release-ja/08-verification/02-tools/00-toc.md create mode 100644 release-ja/08-verification/02-tools/01-dast.md create mode 100644 release-ja/08-verification/02-tools/02-amass.md create mode 100644 release-ja/08-verification/02-tools/03-owtf.md create mode 100644 release-ja/08-verification/02-tools/04-nettacker.md create mode 100644 release-ja/08-verification/02-tools/05-secure-headers.md create mode 100644 release-ja/08-verification/02-tools/info.md create mode 100644 release-ja/08-verification/02-tools/toc.md create mode 100644 release-ja/08-verification/03-frameworks/00-toc.md create mode 100644 release-ja/08-verification/03-frameworks/01-secure-codebox.md create mode 100644 release-ja/08-verification/03-frameworks/info.md create mode 100644 release-ja/08-verification/03-frameworks/toc.md create mode 100644 release-ja/08-verification/04-vulnerability-management/00-toc.md create mode 100644 release-ja/08-verification/04-vulnerability-management/01-defectdojo.md create mode 100644 release-ja/08-verification/04-vulnerability-management/info.md create mode 100644 release-ja/08-verification/04-vulnerability-management/toc.md create mode 100644 release-ja/08-verification/info.md create mode 100644 release-ja/08-verification/toc.md create mode 100644 release-ja/09-training-education/00-toc.md create mode 100644 release-ja/09-training-education/01-vulnerable-apps/00-toc.md create mode 100644 release-ja/09-training-education/01-vulnerable-apps/01-juice-shop.md create mode 100644 release-ja/09-training-education/01-vulnerable-apps/02-webgoat.md create mode 100644 release-ja/09-training-education/01-vulnerable-apps/03-pygoat.md create mode 100644 release-ja/09-training-education/01-vulnerable-apps/04-security-shepherd.md create mode 100644 release-ja/09-training-education/01-vulnerable-apps/info.md create mode 100644 release-ja/09-training-education/01-vulnerable-apps/toc.md create mode 100644 release-ja/09-training-education/02-secure-coding-dojo.md create mode 100644 release-ja/09-training-education/03-skf.md create mode 100644 release-ja/09-training-education/04-samurai-wtf.md create mode 100644 release-ja/09-training-education/05-top-ten.md create mode 100644 release-ja/09-training-education/06-mobile-top-ten.md create mode 100644 release-ja/09-training-education/07-api-top-ten.md create mode 100644 release-ja/09-training-education/08-wrongsecrets.md create mode 100644 release-ja/09-training-education/09-snakes-ladders.md create mode 100644 release-ja/09-training-education/info.md create mode 100644 release-ja/09-training-education/toc.md create mode 100644 release-ja/10-culture-process/00-toc.md create mode 100644 release-ja/10-culture-process/01-security-culture.md create mode 100644 release-ja/10-culture-process/02-security-champions/00-toc.md create mode 100644 release-ja/10-culture-process/02-security-champions/01-security-champions-program.md create mode 100644 release-ja/10-culture-process/02-security-champions/02-security-champions-guide.md create mode 100644 release-ja/10-culture-process/02-security-champions/03-security-champions-playbook.md create mode 100644 release-ja/10-culture-process/02-security-champions/info.md create mode 100644 release-ja/10-culture-process/02-security-champions/toc.md create mode 100644 release-ja/10-culture-process/03-samm.md create mode 100644 release-ja/10-culture-process/04-asvs.md create mode 100644 release-ja/10-culture-process/05-mas.md create mode 100644 release-ja/10-culture-process/info.md create mode 100644 release-ja/10-culture-process/toc.md create mode 100644 release-ja/11-operations/00-toc.md create mode 100644 release-ja/11-operations/01-devsecops.md create mode 100644 release-ja/11-operations/02-coraza.md create mode 100644 release-ja/11-operations/03-modsecurity.md create mode 100644 release-ja/11-operations/04-crs.md create mode 100644 release-ja/11-operations/info.md create mode 100644 release-ja/11-operations/toc.md create mode 100644 release-ja/12-metrics/00-toc.md create mode 100644 release-ja/12-metrics/info.md create mode 100644 release-ja/12-metrics/toc.md create mode 100644 release-ja/13-security-gap-analysis/00-toc.md create mode 100644 release-ja/13-security-gap-analysis/01-guides/00-toc.md create mode 100644 release-ja/13-security-gap-analysis/01-guides/01-samm.md create mode 100644 release-ja/13-security-gap-analysis/01-guides/02-asvs.md create mode 100644 release-ja/13-security-gap-analysis/01-guides/03-mas.md create mode 100644 release-ja/13-security-gap-analysis/01-guides/info.md create mode 100644 release-ja/13-security-gap-analysis/01-guides/toc.md create mode 100644 release-ja/13-security-gap-analysis/02-blt.md create mode 100644 release-ja/13-security-gap-analysis/info.md create mode 100644 release-ja/13-security-gap-analysis/toc.md create mode 100644 release-ja/14-appendices/00-toc.md create mode 100644 release-ja/14-appendices/01-implementation-dos-donts/00-toc.md create mode 100644 release-ja/14-appendices/01-implementation-dos-donts/01-container-security.md create mode 100644 release-ja/14-appendices/01-implementation-dos-donts/02-secure-coding.md create mode 100644 release-ja/14-appendices/01-implementation-dos-donts/03-cryptographic-practices.md create mode 100644 release-ja/14-appendices/01-implementation-dos-donts/04-application-spoofing.md create mode 100644 release-ja/14-appendices/01-implementation-dos-donts/05-content-security-policy.md create mode 100644 release-ja/14-appendices/01-implementation-dos-donts/06-exception-error-handling.md create mode 100644 release-ja/14-appendices/01-implementation-dos-donts/07-file-management.md create mode 100644 release-ja/14-appendices/01-implementation-dos-donts/08-memory-management.md create mode 100644 release-ja/14-appendices/01-implementation-dos-donts/info.md create mode 100644 release-ja/14-appendices/01-implementation-dos-donts/toc.md create mode 100644 release-ja/14-appendices/02-verification-dos-donts/00-toc.md create mode 100644 release-ja/14-appendices/02-verification-dos-donts/01-secure-environment.md create mode 100644 release-ja/14-appendices/02-verification-dos-donts/02-system-hardening.md create mode 100644 release-ja/14-appendices/02-verification-dos-donts/03-open-source-software.md create mode 100644 release-ja/14-appendices/02-verification-dos-donts/info.md create mode 100644 release-ja/14-appendices/02-verification-dos-donts/toc.md create mode 100644 release-ja/14-appendices/info.md create mode 100644 release-ja/14-appendices/toc.md create mode 100644 release-ja/info.md create mode 100644 release-ja/title.pdf.yaml create mode 100644 release-ja/title.yaml create mode 100644 release-ja/toc.md diff --git a/.gitignore b/.gitignore index ac1f76a6..7a5d8e52 100644 --- a/.gitignore +++ b/.gitignore @@ -39,22 +39,6 @@ !draft/1*/1*/ !draft/1*/1*/*.md -# draft portuguese version -!draft-pt/ -!draft-pt/title*.yaml -!draft-pt/0*/ -!draft-pt/0*/*.md -!draft-pt/0*/0*/ -!draft-pt/0*/0*/*.md -!draft-pt/0*/1*/ -!draft-pt/0*/1*/*.md -!draft-pt/1*/ -!draft-pt/1*/*.md -!draft-pt/1*/0*/ -!draft-pt/1*/0*/*.md -!draft-pt/1*/1*/ -!draft-pt/1*/1*/*.md - # release version !release/ !release/title*.yaml @@ -103,6 +87,22 @@ !release-es/1*/1*/ !release-es/1*/1*/*.md +# release japanese translation +!release-ja/ +!release-ja/title*.yaml +!release-ja/0*/ +!release-ja/0*/*.md +!release-ja/0*/0*/ +!release-ja/0*/0*/*.md +!release-ja/0*/1*/ +!release-ja/0*/1*/*.md +!release-ja/1*/ +!release-ja/1*/*.md +!release-ja/1*/0*/ +!release-ja/1*/0*/*.md +!release-ja/1*/1*/ +!release-ja/1*/1*/*.md + # pages markdown !*.md !assets/ diff --git a/.wordlist-ja.txt b/.wordlist-ja.txt new file mode 100644 index 00000000..d7e4d31e --- /dev/null +++ b/.wordlist-ja.txt @@ -0,0 +1,519 @@ +AES +APIT +APIs +APK +ARP +ASVS +AUTH +Adoptium +Analyser +Andra +Andreas +AngularJS +AppArmor +AppSec +AppSensor +Arithmatex +Atlassian +BOM +BOMs +BOV +BetterEm +Brømsø +CAPEC +CFB +CISO +CMS +CMSeeK +CPE +CRL +CRS +CSP +CSPRNG +CSRF +CSRFGuard +CSV +CTF +CVE +CVEs +CVSS +CWE +Canonicalisation +Cavalcanti +ChartMuseum +Cheatsheet +Cheatsheets +ClickJacking +Clickjacking +CodeQL +Coraza +Crackmes +Cryptographic +Customizable +CycloneDX +DAST +DCT +DES +DNS +DOM +DPO +DRM +DSS +DefectDojo +DevGuide +DevOps +DevSecOps +Diffie +DoS +DocX +DockerHub +Dojo +Don'ts +Dont's +DotNet +DrHEADer +Dracon +ECB +ENISA +ESAPI +Ecommerce +Elie +EscapeAll +Exploitability +FIPS +Flaxman +GCP +GDPR +GHSL +GRC +GRPC +Gasteratos +GitHub +Gitleaks +Gradle +GraphQL +Graphviz +HAPI +HAProxy +HBOM +HMAC +HSM +Haan +Happe +IAM +IAST +IDOR +IIS +IPC +InlineHilite +Istio +JA +JDK +JIRA +JSON +JSONP +JSP +JSR +JWA +JWKS +JWT +JWTs +Janca +JavaEE +JavaScript +Johan +Joomla +KDF +KMS +Katana +Keyczar +Kube +Kubeaudit +Kubernetes +Kulkarni +LDAP +LFD +LINDDUN +LINNDUN +LLM +LSMs +Laravel +Lezza +LifeCycle +Lifecycle +MACs +MASTG +MASVS +MASWE +MBOM +MITRE +MITRE's +MOBI +MSTG +MacOS +Macdonald +MagicLink +Matteo +Microservices +Misconfiguration +ModSecurity +Multifactor +NIST +NVD +Namespaces +Ncrack +Nettacker +Nginx +Nikto +Nmap +NoSQL +Node.js +NodeJS +NuGets +OAuth +OBOM +ODF +OFB +OOXML +OSHP +OSS +OTMP +OWASP +OWASP's +OWTF +Okta +Oliveira +OpenAPI +OpenCRE +OpenID +OpenJDK +PCI +PID +PIDs +PKI +PKIX +PRNG +PathConverter +PlantUML +Playbook +Porreca +ProgressBar +PyGoat +PyPi +PySpelling +PyYAML +Pythonic +README +RRA +RSA +RansomWare +Recx +Riccardo +Ruleset +SAFEcode +SAML +SAMM +SAMMwise +SAST +SBOM +SBOMs +SBT +SCA +SCP +SDLC +SDLCs +SECCOMP +SELinux +SIEM +SKF +SMS +SNYK +SPOA +SSDLC +SSL +SSLyze +SSO +SSP +SSRF +SVG +SaaSBOM +Saad +SamuraiWTF +SaneHeaders +Screenshooter +SecurityCAT +SecurityHeaders +SecurityRAT +Sehgal +Semgrep +Serverless +Shiro +Shostack +Shostack's +Shruti +Skipenes +SmartSymbols +Sonatype +Spyros +Starov +StripHTML +SuperFences +Sydseter +Symfony +TCP +TLS +TOCTOU +TPM +TPS +Tasklist +Tesauro +Threagile +Tink +ToC +Trivy +TrustWave +UEFI +UI +URDP +UTF +UUID +UnCrackable +Unvalidated +VDR +VM +VPN +VPNs +VWAD +Vandana +VerSprite +VerSprite's +Verma +VirtualBox +Volkman +VulnDB +WAF +WASM +WEBDav +WHATWG +WPScan +WSTG +Wayfinder +WebGoat +WebGoat's +WebHook +WebSQL +WebView +WebWolf +Whatweb +Wordlist +Wordpress +WrongSecrets +XML +XSS +XXE +YAML +ZH +aSemy +ai +algorithmically +angularjs +api +architected +asvs +backdoors +backend +backrefs +baselining +blt +br +bracex +bruteforcing +caddy +canonicalization +centric +cgroup +cgroups +cheatsheets +checksums +chrooted +ciphertext +clickjacking +codebox +codefences +config +coraza +crs +crypto +cryptographic +cryptographically +cryptosystems +csp +csrf +csrfguard +customizable +cyber +cybersecurity +cybersquatting +cyclonedx +dast +dataflow +dataflows +de +declutter +decrypt +decrypts +deduplication +defacto +defectdojo +deliverables +dependabot +deserialization +deserialize +deserializes +deserializing +dev +devsecops +devsite +doggo +dojo +donts +dracon +ePub +eXchange +edumco +encodings +endif +enum +esapi +executables +exfiltrate +exfiltration +facelessuser +faq +ffuf +filesystem +frontend +frontends +gamification +gamifies +gamify +github +gitlab +gmail +golang +hardcode +hostnames +hsecscan +html +http +https +iFrame +incrementing +integrations +intel +interoperate +io +iteratively +javascript +js +json +kali +kalikali +katana +kubernetes +lifecycle +lifecycles +linddun +linter +linters +linux +localhost +lxml +lychee +mastg +maswe +misconfiguration +mitigations +modsecurity +modularized +namespace +namespaces +nettacker +newpage +nightlies +nist +npm +opencre +oshp +owasp +owtf +pandoc +parameterization +parsers +pentesters +pentesting +permalink +personalization +plaintext +pre +programmatically +proscriptive +px +pygoat +pymdown +pyspelling +pytm +rebranding +referer +remediations +repo +roadmap +runtime +runtimes +samm +samuraiwtf +sanitization +sbates +scalability +scalable +schemas +scp +seclang +secureCodeBox +serializer +sexualized +skf +socio +soupsieve +stacktrace +subcommand +subcommands +subdirectories +subdirectory +synchronizer +templating +testbed +testssl +threatspec +toolchain +transactional +txt +typosquatting +unforgeable +unicode +unkeyed +unmanaged +untrusted +url +userland +waf +wcmatch +webapp +webgoat +weightage +writeups +wrongsecrets +wstg +wtf +www +xsaero diff --git a/release-ja/01-front.md b/release-ja/01-front.md new file mode 100644 index 00000000..61686962 --- /dev/null +++ b/release-ja/01-front.md @@ -0,0 +1,21 @@ +--- + +title: Front Page +layout: col-document +tags: OWASP Developer Guide +contributors: Shruti Kulkarni, Jon Gadsden, Johan Sydseter +document: OWASP Developer Guide +order: +permalink: + +--- + +{% include breadcrumb.html %} + +## ![Developer Guide](../assets/images/dg_logo.png) + +### OWASP Developer Guide + +#### A Guide to Building Secure Web Applications and Web Services + +### Release version 4.1.7 diff --git a/release-ja/02-toc.md b/release-ja/02-toc.md new file mode 100644 index 00000000..60c8be87 --- /dev/null +++ b/release-ja/02-toc.md @@ -0,0 +1,140 @@ +--- + +title: Table of Contents +layout: col-document +tags: OWASP Developer Guide +contributors: +document: OWASP Developer Guide +order: +permalink: + +--- + +{% include breadcrumb.html %} + +## Table of contents + +1 **[Introduction](#introduction)** + +2 **[Foundations](#foundations)** +2.1 [Security fundamentals](#security-fundamentals) +2.2 [Secure development and integration](#secure-development-and-integration) +2.3 [Principles of security](#principles-of-security) +2.4 [Principles of cryptography](#principles-of-cryptography) +2.5 [OWASP Top 10](#owasp-top-ten) + +3 **[Requirements](#requirements)** +3.1 [Requirements in practice](#requirements-in-practice) +3.2 [Risk profile](#risk-profile) +3.3 [OpenCRE](#opencre) +3.4 [SecurityRAT](#security-rat) +3.5 [ASVS requirements](#asvs-requirements) +3.6 [MAS requirements](#mas-requirements) +3.7 [SKF requirements](#skf-requirements) + +4 **[Design](#design)** +4.1 [Threat modeling](#threat-modeling) +4.1.1 [Threat modeling in practice](#threat-modeling-in-practice) +4.1.2 [pytm](#pytm) +4.1.3 [Threat Dragon](#threat-dragon) +4.1.4 [Cornucopia](#cornucopia) +4.1.5 [LINDDUN GO](#linddun-go) +4.1.6 [Threat Modeling toolkit](#threat-modeling-toolkit) +4.2 [Web application checklist](#web-application-checklist) +4.2.1 [Checklist: Define Security Requirements](#checklist-define-security-requirements) +4.2.2 [Checklist: Leverage Security Frameworks and Libraries](#checklist-leverage-security-frameworks-and-libraries) +4.2.3 [Checklist: Secure Database Access](#checklist-secure-database-access) +4.2.4 [Checklist: Encode and Escape Data](#checklist-encode-and-escape-data) +4.2.5 [Checklist: Validate All Inputs](#checklist-validate-all-inputs) +4.2.6 [Checklist: Implement Digital Identity](#checklist-implement-digital-identity) +4.2.7 [Checklist: Enforce Access Controls](#checklist-enforce-access-controls) +4.2.8 [Checklist: Protect Data Everywhere](#checklist-protect-data-everywhere) +4.2.9 [Checklist: Implement Security Logging and Monitoring](#checklist-implement-security-logging-and-monitoring) +4.2.10 [Checklist: Handle all Errors and Exceptions](#checklist-handle-all-errors-and-exceptions) +4.3 [MAS checklist](#mas-checklist) + +5 **[Implementation](#implementation)** +5.1 [Documentation](#documentation) +5.1.1 [Top 10 Proactive Controls](#top-proactive-controls) +5.1.2 [Go Secure Coding Practices](#go-secure-coding-practices) +5.1.3 [Cheatsheet Series](#cheatsheet-series) +5.2 [Dependencies](#dependencies) +5.2.1 [Dependency-Check](#dependency-check) +5.2.2 [Dependency-Track](#dependency-track) +5.2.3 [CycloneDX](#cyclonedx) +5.3 [Secure Libraries](#secure-libraries) +5.3.1 [ESAPI](#esapi) +5.3.2 [CSRFGuard](#csrfguard) +5.3.3 [OSHP](#oshp) +5.4 [MASWE](#maswe) + +6 **[Verification](#verification)** +6.1 [Guides](#verification-guides) +6.1.1 [WSTG](#wstg) +6.1.2 [MASTG](#mastg) +6.1.3 [ASVS](#asvs) +6.2 [Tools](#verification-tools) +6.2.1 [DAST tools](#dast-tools) +6.2.2 [Amass](#amass) +6.2.3 [OWTF](#owtf) +6.2.4 [Nettacker](#nettacker) +6.2.5 [OSHP verification](#oshp-verification) +6.3 [Frameworks](#verification-frameworks) +6.3.1 [secureCodeBox](#securecodebox) +6.4 [Vulnerability management](#verification-vulnerability-management) +6.4.1 [DefectDojo](#defectdojo) + +7 **[Training and Education](#training-and-education)** +7.1 [Vulnerable Applications](#vulnerable-applications) +7.1.1 [Juice Shop](#juice-shop) +7.1.2 [WebGoat](#webgoat) +7.1.3 [PyGoat](#pygoat) +7.1.4 [Security Shepherd](#security-shepherd) +7.2 [Secure Coding Dojo](#secure-coding-dojo) +7.3 [SKF education](#skf-education) +7.4 [SamuraiWTF](#samuraiwtf) +7.5 [OWASP Top 10 project](#owasp-top-ten-project) +7.6 [Mobile Top 10](#mobile-top-ten) +7.7 [API Top 10](#api-top-ten) +7.8 [WrongSecrets](#wrongsecrets) +7.9 [OWASP Snakes and Ladders](#owasp-snakes-and-ladders) + +8 **[Culture building and Process maturing](#culture-building-and-process-maturing)** +8.1 [Security Culture](#security-culture) +8.2 [Security Champions](#security-champions) +8.2.1 [Security champions program](#security-champions-program) +8.2.2 [Security Champions Guide](#security-champions-guide) +8.2.3 [Security Champions Playbook](#security-champions-playbook) +8.3 [SAMM](#samm) +8.4 [ASVS process](#asvs-process) +8.5 [MAS process](#mas-process) + +9 **[Operations](#operations)** +9.1 [DevSecOps Guideline](#devsecops-guideline) +9.2 [Coraza WAF](#coraza-waf) +9.3 [ModSecurity WAF](#modsecurity-waf) +9.4 [OWASP CRS](#owasp-crs) + +10 **[Metrics](#metrics)** + +11 **[Security gap analysis](#security-gap-analysis)** +11.1 [Guides](#security-gap-analysis-guides) +11.1.1 [SAMM gap analysis](#samm-gap-analysis) +11.1.2 [ASVS gap analysis](#asvs-gap-analysis) +11.1.3 [Mobile gap analysis](#mas-gap-analysis) +11.2 [BLT](#blt) + +12 **[Appendices](#appendices)** +12.1 [Implementation Do's and Don'ts](#implementation-dos-and-donts) +12.1.1 [Container security](#container-security) +12.1.2 [Secure coding](#secure-coding) +12.1.3 [Cryptographic practices](#cryptographic-practices) +12.1.4 [Application spoofing](#application-spoofing) +12.1.5 [Content Security Policy (CSP)](#content-security-policy) +12.1.6 [Exception and error handling](#exception-and-error-handling) +12.1.7 [File management](#file-management) +12.1.8 [Memory management](#memory-management) +12.2 [Verification Do's and Don'ts](#verification-dos-and-donts) +12.2.1 [Secure environment](#secure-environment) +12.2.2 [System hardening](#system-hardening) +12.2.3 [Open Source software](#open-source-software) diff --git a/release-ja/03-introduction.md b/release-ja/03-introduction.md new file mode 100644 index 00000000..7b1633e0 --- /dev/null +++ b/release-ja/03-introduction.md @@ -0,0 +1,95 @@ +--- + +title: Introduction +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 3000 +permalink: /release/introduction/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){: .image-right } + +### 1. Introduction + +Welcome to the OWASP Development Guide. + +The Open Worldwide Application Security Project ([OWASP][about]) is a nonprofit foundation +that works to improve the security of software. +It is an open community dedicated to enabling organizations to +conceive, develop, acquire, operate, and maintain applications that can be trusted. + +Along with the OWASP Top Ten, the Developer Guide is one of the original resources +published soon after the OWASP foundation was formed in 2001. +Version 1.0 of the Developer Guide was released in 2002 +and since then there have been various [releases][versions] culminating in version 2.0 in 2005. +Since then the guide has been revised extensively to bring it up to date. +The latest versions are 4.x because version 3.0 was never released. + +The purpose of this guide is to provide an introduction to security concepts +and a handy reference for application / system developers. +Generally it describes security practices using the advice given in the +OWASP Software Assurance Maturity Model ([SAMM][samm]) and describes the OWASP projects +referenced in the OWASP [Application Security Wayfinder][intstand] project. + +This guide does not seek to replicate the many excellent sources on specific security topics; +it rarely tries to go into detail on a subject and instead provides links for greater depth on these security topics. +Instead the content of the Developer Guide aims to be accessible, introducing practical security concepts +and providing enough detail to get developers started on various OWASP tools and documents. + +All of the OWASP projects and tools described in this guide are free to download and use. +All OWASP projects are open source; please do get involved if you are interested in improving application security. + +#### Audience + +Developers should use this OWASP Developer Guide to help write applications that are more secure. +The guide has been written by the security community to help software developers write solid, +safe and secure applications. +Most of the contributors to this guide are also software developers as well as security engineers, +and this helps to keep the focus developer centric. + +If you are in a hurry and want information on a specific subject then +try the [OpenCRE chat][opencrechat] LLM for immediate answers. + +#### What is the Developer Guide? + +You can think of this guide as a cross-reference source to the many tools and documents that OWASP provide for developers. + +Or you can regard the purpose of this guide as answering the question: +“I am a developer and I need a reference guide to navigate the numerous security tools +and security activities that I know I should be doing. + +Or think of it as a collection of articles that introduce developers to the wide domain of application security. + +Or you can regard this guide as a companion document to the OWASP [Integration Standards][intstand] project: +the Application Security Wayfinder maps out the many tools, +projects and documents within OWASP and the Developer Guide provides some 'wordy' context. + +[![AppSec Wayfinder](../../assets/images/owasp-wayfinder.png "OWASP Application Security Wayfinder")][intstand] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue03] or [edit on GitHub][edit03]. + +[about]: https://owasp.org/about/ +[edit03]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/03-introduction.md +[intstand]: https://owasp.org/www-project-integration-standards/ +[issue03]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2003-introduction +[opencrechat]: https://www.opencre.org/chatbot +[samm]: https://owaspsamm.org/about/ +[versions]: https://github.com/OWASP/DevGuide/wiki#old-versions diff --git a/release-ja/04-foundations/00-toc.md b/release-ja/04-foundations/00-toc.md new file mode 100644 index 00000000..aecb1513 --- /dev/null +++ b/release-ja/04-foundations/00-toc.md @@ -0,0 +1,47 @@ +--- + +title: Foundations +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){height=180px} + +## 2. Foundations + +There are various foundational concepts and terminology that are commonly used in software security. +Although many of these concepts are complex to implement and are based on heavy-duty theory, +the principles are often fairly straight forward and are accessible for every software engineer. + +A reasonable grasp of these foundational concepts allows development teams to understand and implement +software security for the application or system under development. +This Developer Guide can only give a brief overview of these concepts, +for in-depth knowledge refer to the many texts on security such as the [The Cyber Security Body Of Knowledge][cbok]. + +If changes are being introduced to the security culture of an organization +then make sure there is management buy-in and clear goals to achieve. +Without these then attempts to improve the security posture will probably fail - see the +[Security Culture][culturegoal] project for the importance of getting management, +security and development teams working together. + +Sections: + +2.1 [Security fundamentals](#security-fundamentals) +2.2 [Secure development and integration)](#secure-development-and-integration) +2.3 [Principles of security](#principles-of-security) +2.4 [Principles of cryptography](#principles-of-cryptography) +2.5 [OWASP Top 10](#owasp-top-ten) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0400]. + +[cbok]: https://www.cybok.org/ +[culturegoal]: https://owasp.org/www-project-security-culture/stable/3-Goal_Setting_and_Security_Team_Collaboration/ +[issue0400]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-foundations/00-toc diff --git a/release-ja/04-foundations/01-security-fundamentals.md b/release-ja/04-foundations/01-security-fundamentals.md new file mode 100644 index 00000000..c62fb958 --- /dev/null +++ b/release-ja/04-foundations/01-security-fundamentals.md @@ -0,0 +1,203 @@ +--- + +title: Security Fundamentals +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 4010 +permalink: /release/foundations/security_fundamentals/ + +--- + +{% include breadcrumb.html %} + + + +### 2.1 Security fundamentals + +The fundamental principles of application security rely on the security concepts referenced in this developer guide. +This section aims to provide an introduction to fundamental principles that any development team must be familiar with. + +#### Software Assurance Maturity Model + +![SAMM logo](../../../assets/images/logos/samm.png "OWASP SAMM"){: .image-right-small } + +The Software Assurance Maturity Model ([SAMM][samm]) provides context for the scope of software security +and the foundations of good security practice: + +* [Governance][sammg] +* [Design][sammd] +* [Implementation][sammi] +* [Verification][sammv] +* [Operations][sammo] + +The SAMM model describes these foundations of software security as Business Functions, +which are further divided into Business Practices. +The OWASP Software Assurance Maturity Model ([SAMM][samm]) is used throughout this Developer Guide; +most of the sections in the Developer Guide reference at least one of the Business Functions or Practices from SAMM. + +#### CIA triad + +Security is simply about controlling who can interact with your information, +what they can do with it, and when they can interact with it. +These characteristics of security can be described using the CIA triad. + +CIA stands for Confidentiality, Integrity and Availability, +and it is usually depicted as a triangle representing the strong bonds between its three tenets. +This triad is considered the pillars of application security, +often Confidentiality, Integrity or Availability are used as a properties of data or processes within a given system. +The CIA triad can be extended with the AAA triad: Authorization, Authentication and Auditing. + +#### Confidentiality + +Confidentiality is the protection of data against unauthorized disclosure; +it is about ensuring that only those with the correct authorization can access the data +and applies to both data at rest and to data in transit. +Confidentiality is also related to the broader concept of data privacy. + +#### Integrity + +Integrity is about protecting data against unauthorized modification, or assuring data trustworthiness. +The concept contains the notion of data integrity (data has not been changed accidentally or deliberately) +and the notion of source integrity (data came from or was changed by a legitimate source). + +#### Availability + +Availability is about ensuring the presence of information or resources. +This concept relies not just on the availability of the data itself, for example by using replication of data, +but also on the protection of the services that provide access to the data, for example by using load balancing. + +#### AAA triad + +The CIA triad is often extended with Authentication, Authorization and Auditing as these are closely linked to CIA concepts. +CIA has a strong dependency on Authentication and Authorization; +the confidentiality and integrity of sensitive data can not be assured without them. +Auditing is added as it can provide the mechanism to ensure proof of any interaction with the system. + +#### Authentication + +[Authentication][csauthn] is about confirming the identity of the entity that wants to interact with a secure system. +For example the entity could be an automated client or a human actor; +in either case authentication is required for a secure application. + +#### Authorization + +[Authorization][csauthz] is about specifying access rights to secure resources (data, services, files, applications, etc). +These rights describe the privileges or access levels related to the resources that are being secured. +Authorization is usually preceded by successful authentication. + +#### Auditing + +Auditing is about keeping track of implementation-level events, as well as domain-level events taking place in a system. +This helps to provide non-repudiation, which means that changes or actions on the protected system are undeniable. +Auditing can provide not only technical information about the running system, +but also proof that particular actions have been performed. +The typical questions that are answered by auditing are "Who did What, When and potentially How?" + +#### Vulnerabilities + +NIST defines a [vulnerability][nistvuln] as 'Weakness in an information system, system security procedures, +internal controls, or implementation that could be exploited or triggered by a threat source.' + +There are many weaknesses or bugs in every large application, but the term vulnerability is generally reserved +for those weaknesses or bugs where there is a risk that a threat actor could exploit it using a threat vector. + +Well known security vulnerabilities are : + +* [Clickjacking][csclick] +* [Credential Stuffing][cscreds] +* [Cross-site leaks][csxsleaks] +* [Denial of Service][csdos] (DoS) attacks +* DOM based [XSS attacks][csdom] including [DOM Clobbering][csdomclub] +* [IDOR][csidor] (Insecure Direct Object Reference) +* [Injection][csinjection] including [OS Command injection][csosinjection] and [XXE][csxxe] +* LDAP specific [injection attacks][csldap] +* [Prototype pollution][csproto] +* [SSRF][csssrf] attacks +* [SQL injection][cssql] and the use of [Query Parameterization][csquery] +* [Unvalidated redirects and forwards][csredirect] +* [XSS attacks][csxss] and [XSS Filter Evasion][csxssevade] + +#### HTTP and HTML + +Although not a security fundamental as such, web applications rely on HTTP communications and HTML. +Both application developers and security engineers should have a good understanding of HTTP +and the HTML language along with their various security controls. + +Most application development teams will be familiar with HTTP communications and the HTML standard, +but if necessary refer to the training from the [W3 Consortium][w3consortium] or the [W3 Schools][w3schools]. +The OWASP [Cheat Sheet Series][cheatsheets] provide web application developers with the information +needed to produce secure software : + +* The [HTML5 Security][cshtml5] cheat sheet describes a wide range of controls, + aligned with the current [HTML Living Standard][htmlliving] +* Refer to the [Securing Cascading Style Sheets][cscss] cheat sheet for CSS +* The HTTP headers need to be secure, see the [HTTP Security Response Headers][csheaders] cheat sheet +* Strongly consider [HTTP Strict Transport Security][csstrict] +* If the application has a file upload feature, follow the [File Upload][csfile] cheat sheet +* Ensure content security policy is in place with the [Content Security Policy][cscsp] cheat sheet +* Using JWTs for a Java application? Refer to the [JSON Web Token][csjwt] cheat sheet +* Storing or sending objects? Check out the [Deserialization][csserial] cheat sheet + +#### References + +* [WHATWG][whatwg] [HTML Living Standard][htmlliving] +* OWASP [Cheat Sheet Series][cheatsheets] +* OWASP [Software Assurance Maturity Model][samm] (SAMM) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0401] or [edit on GitHub][edit0401]. + +[cheatsheets]: https://cheatsheetseries.owasp.org/ +[csclick]: https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet +[cscreds]: https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet +[cscsp]: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet +[cscss]: https://cheatsheetseries.owasp.org/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet +[csdom]: https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet +[csdomclub]: https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet +[csdos]: https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet +[csidor]: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet +[csinjection]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet +[csosinjection]: https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet +[csldap]: https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet +[csproto]: https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet +[csauthn]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet +[csauthz]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet +[csfile]: https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet +[csheaders]: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet +[cshtml5]: https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet +[csjwt]: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet +[csredirect]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet +[csserial]: https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet +[cssql]: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet +[csquery]: https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet +[csssrf]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet +[csstrict]: https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet +[csxss]: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet +[csxsleaks]: https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet +[csxssevade]: https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet +[csxxe]: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet +[edit0401]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/04-foundations/01-security-fundamentals.md +[htmlliving]: https://html.spec.whatwg.org/multipage/ +[issue0401]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-foundations/01-security-fundamentals +[nistvuln]: https://csrc.nist.gov/glossary/term/vulnerability +[samm]: https://owaspsamm.org/about/ +[sammd]: https://owaspsamm.org/model/design/ +[sammg]: https://owaspsamm.org/model/governance/ +[sammi]: https://owaspsamm.org/model/implementation/ +[sammo]: https://owaspsamm.org/model/operations/ +[sammv]: https://owaspsamm.org/model/verification/ +[w3consortium]: https://www.w3.org/ +[w3schools]: https://www.w3schools.com/html/ +[whatwg]: https://whatwg.org/ diff --git a/release-ja/04-foundations/02-secure-development.md b/release-ja/04-foundations/02-secure-development.md new file mode 100644 index 00000000..a5f81c8f --- /dev/null +++ b/release-ja/04-foundations/02-secure-development.md @@ -0,0 +1,241 @@ +--- + +title: Secure Development and Integration +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 4020 +permalink: /release/foundations/secure_development/ + +--- + +{% include breadcrumb.html %} + + + +### 2.2 Secure development and integration + +Secure development is described in the OWASP Software Assurance Maturity Model [(SAMM)][samm] +[Design][sammd], [Implementation][sammi] and [Verification][sammv] business functions. +Also refer to the [Security Culture][culturewhy] for a good explanation +on why adding security into the software development lifecycle is important. + +#### Prelude + +The best introduction to practical secure software development is the +OWASP [Application Security Fragmentation][sdlc] article : + +_Or how I worried less and stood on the shoulders of giants._ - Spyros Gasteratos, Elie Saad + +Much of the material in this section is drawn from this OWASP [Integration Standards][intstand] project. + +#### Overview + +Almost all modern software is developed in an iterative manner passing through phase to phase, +such as identifying customer requirements, implementation and test. +These phases are revisited in a cyclic manner throughout the lifetime of the application. +A notional Software Development LifeCycle (SDLC) is shown below, in practice there may be more or less phases +according to the processes adopted by the organization. + +![SDLC Lifecycle](../../../assets/images/sdlc_diag.png "notional SDLC lifecycle"){: .image-right } + +With the increasing number and sophistication of exploits against almost every application or business system, +most companies have adopted a secure Software Development LifeCycle (SDLC). +The secure SDLC should never be a separate lifecycle from an existing software development lifecycle, +it must always be the same development lifecycle as before but with security actions built into each phase, +otherwise security actions may well be set aside by busy development teams. +Note that although the Secure SDLC could be written as 'SSDLC' it is almost always written as 'SDLC'. + +DevOps integrates and automates many of the SDLC phases and implements Continuous Integration (CI) +and Continuous Delivery/Deployment (CD) pipelines to provide much of the SDLC automation. + +DevOps and pipelines have been successfully exploited with serious large scale consequences +and so, in a similar manner to the SDLC, much of the DevOps actions have also had security built in to them. +Secure DevOps, or DevSecOps, builds security practices into the DevOps activities to guard against attack +and to provide the SDLC with automated security testing. + +Examples of how DevSecOps is 'building security in' is the provision of +Interactive, Static and Dynamic Application Security Testing (IAST, SAST & DAST) +and implementing supply chain security, and there are many other security activities that can be applied. +Refer to the [CI/CD Security Cheat Sheet][cscicd] for the latest DevSecOps security controls. + +#### Secure development lifecycle + +Referring to the OWASP [Application Security Wayfinder][intstand] development cycle +there are four iterative phases during application development: Requirements, Design, Implementation and Verification. +The other phases are done less iteratively in the development cycle but these form an equally important +part of the SDLC: Gap Analysis, Metrics, Operation and Training & Culture Building. + +All of these phases of the SDLC should have security activities built into them, +rather than done as separate activities. If security is built into these phases then the overhead becomes much less +and the resistance from the development teams decreases. The goal is for the secure SDLC to become as familiar +a process as before, with the development teams taking ownership of the security activities within each phase. + +There are many OWASP tools and resources to help build security into the SDLC. + +* **Requirements**: this phase determines the functional, non-functional and security requirements for the application. + Requirements should be revisited periodically and checked for completeness and validity, + and it is worth considering various OWASP tools to help with this; + * the [Application Security Verification Standard (ASVS)][asvs] provides developers + with a list of requirements for secure development, + * the [Mobile Application Security project][masproject] provides a security standard for mobile applications + and [SecurityRAT][srat] helps identify an initial set of security requirements. + +* **Design**: it is important to design security into the application - it is never too late to do this + but the earlier the better and easier to do. OWASP provides two tools, [Pythonic Threat Modeling][pytm] + and [Threat Dragon][tdtm], for threat modeling along with security gamification using [Cornucopia][cornucopia]. + +* **Implementation**: the OWASP [Top 10 Proactive Controls][proactive10] project states that they are + "the most important control and control categories that every architect and developer should absolutely, + 100% include in every project" and this is certainly good advice. Implementing these controls can provide + a high degree of confidence that the application or system will be reasonably secure. + OWASP provides two libraries that can be incorporated in web applications, + the [Enterprise Security API (ESAPI)][esapi-project] security control library + and [CSRFGuard][csrfguard] to mitigate the risk of [Cross-Site Request Forgery][cscsrf] (CSRF) attacks, + that help implement these proactive controls. In addition the OWASP [Cheat Sheet Series][csproject] + is a valuable source of information and advice on all aspects of applications security. + +* **Verification**: OWASP provides a relatively large number of projects that help with testing and verification. + This is the subject of a section in this Developer Guide, and the projects are listed at the end of this section. + +* **Training**: development teams continually need security training. + Although not part of the inner SDLC iterative loop training should still be factored into the project lifecycle. + OWASP provides many training environments and materials - see the list at the end of this section. + +* **Culture Building**: a good security culture within a business organization will help greatly in keeping + the applications and systems secure. There are many activities that all add up to create the + security culture, the OWASP [Security Culture][culture] project goes into more detail on these activities, + and a good Security Champion program within the business is foundational to a good security posture. + The OWASP [Security Champions Guide][champions] provides guidance and material to create security champions + within the development teams - ideally every team should have a security champion that has + a special interest in security and has received further training, enabling the team to build security in. + +* **Operations**: the OWASP [DevSecOps Guideline][devsecops] explains how to best implement a secure pipeline, + using best practices and automation tools to help 'shift-left' security issues. + Refer to the DevSecOps Guideline for more information on any of the topics within DevSecOps + and in particular sections on Operations. + +* **Supply chain**: attacks that leverage the supply chain can be devastating + and there have been several high profile of products being successfully exploited. + A Software Bill of Materials (SBOM) is the first step in avoiding these attacks and + it is well worth using the OWASP [CycloneDX][cyclone] full-stack Bill of Materials (BOM) standard + for [risk reduction in the supply chain][cschain]. + In addition the OWASP [Dependency-Track][deptrack] project is a Continuous SBOM Analysis Platform + which can help prevent these supply chain exploits by providing control of the SBOM. + +* **Third party dependencies**: keeping track of what third party libraries are included in the application, + and what vulnerabilities they have, is easily automated. Many public repositories such as [github][github] + and [gitlab][gitlab] offer this service along with some commercial vendors. + OWASP provides the [Dependency-Check][depcheck] Software Composition Analysis (SCA) tool + to track external libraries. + +* **Application security testing**: there are various types of security testing that can be automated on pull-request, + merge or nightlies - or indeed manually but they are most powerful when automated. Commonly there is + Static Application Security Testing (SAST), which analyzes the code without running it, + and Dynamic Application Security Testing (DAST), which applies input to the application while running it in a sandbox + or other isolated environments. + Interactive Application Security Testing (IAST) is designed to be run manually as well as being automated, + and provides instant feedback on the tests as they are run. + +#### Further reading from OWASP + +* [Cheat Sheet Series][csproject] +* [CI/CD Security Cheat Sheet][cscicd] +* [Cornucopia][cornucopia] +* [CycloneDX][cyclone] Bill of Materials (BOM) standard +* [DevSecOps Guideline][devsecops] +* [Security Champions Guide][champions] +* [Security Culture project][culture] +* [Top 10 Proactive Controls][proactive10] + +#### OWASP verification projects + +* [Application Security Verification Standard][asvs] (ASVS) +* [Amass project][amass] +* [Code Pulse][pulse] +* [Defect Dojo][defectdojo] +* [Mobile Application Security][masproject] (MAS) +* [Nettacker][net] +* [Offensive Web Testing Framework][owtf] (OWTF) +* [Web Security Testing Guide][wstg] (WSTG) + +#### OWASP training projects + +* [API Security Project][apisec] (API Top 10) +* [Juice Shop][juice] +* [Mobile Top 10][mobile10] +* [Security Shepherd][sec-shep] +* [Snakes And Ladders][snakes] +* [Top Ten Web Application security risks][top10] +* [WebGoat][webgoat] + +#### OWASP resources + +* [CSRFGuard library][csrfguard] +* [Dependency-Check Software Composition Analysis (SCA)][depcheck] +* [Dependency-Track Continuous SBOM Analysis Platform][deptrack] +* [Enterprise Security API][esapi-project] (ESAPI) +* [Integration Standards project Application Security Wayfinder][intstand] +* [Mobile Application Security][mas] (MAS) +* [Pythonic Threat Modeling][pytm] +* [Threat Dragon][tdtm] +* [SecurityRAT][srat] (Requirement Automation Tool) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0402] or [edit on GitHub][edit0402]. + +[amass]: https://owasp.org/www-project-amass/ +[apisec]: https://owasp.org/API-Security +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[champions]: https://owasp.org/www-project-security-champions-guidebook/ +[cscicd]: https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet +[cornucopia]: https://owasp.org/www-project-cornucopia/ +[cschain]: https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet +[cscsrf]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet +[csproject]: https://owasp.org/www-project-cheat-sheets/ +[csrfguard]: https://owasp.org/www-project-csrfguard/ +[culture]: https://owasp.org/www-project-security-culture/ +[culturewhy]: https://owasp.org/www-project-security-culture/stable/2-Why_Add_Security_In_Development_Teams/ +[cyclone]: https://owasp.org/www-project-cyclonedx/ +[depcheck]: https://owasp.org/www-project-dependency-check/ +[deptrack]: https://dependencytrack.org/ +[devsecops]: https://owasp.org/www-project-devsecops-guideline/ +[defectdojo]: https://www.defectdojo.org/ +[edit0402]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/04-foundations/02-secure-development.md +[esapi-project]: https://owasp.org/www-project-enterprise-security-api/ +[github]: https://github.com/ +[gitlab]: https://about.gitlab.com/ +[issue0402]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-foundations/02-secure-development +[juice]: https://owasp.org/www-project-juice-shop/ +[mas]: https://mas.owasp.org/ +[masproject]: https://owasp.org/www-project-mobile-app-security/ +[mobile10]: https://owasp.org/www-project-mobile-top-10/ +[net]: https://owasp.org/www-project-nettacker/ +[owtf]: https://owasp.org/www-project-owtf/ +[proactive10]: https://owasp.org/www-project-proactive-controls/ +[pulse]: https://owasp.org/www-project-code-pulse/ +[pytm]: https://owasp.org/www-project-pytm/ +[samm]: https://owaspsamm.org/about/ +[sammd]: https://owaspsamm.org/model/design/ +[sammi]: https://owaspsamm.org/model/implementation/ +[sammv]: https://owaspsamm.org/model/verification/ +[sdlc]: https://owasp.org/www-project-integration-standards/writeups/owasp_in_sdlc/ +[sec-shep]: https://owasp.org/www-project-security-shepherd/ +[snakes]: https://owasp.org/www-project-snakes-and-ladders/ +[srat]: https://owasp.org/www-project-securityrat/ +[tdtm]: https://owasp.org/www-project-threat-dragon/ +[top10]: https://owasp.org/Top10/ +[intstand]: https://owasp.org/www-project-integration-standards/ +[webgoat]: https://owasp.org/www-project-webgoat/ +[wstg]: https://owasp.org/www-project-web-security-testing-guide/ diff --git a/release-ja/04-foundations/03-security-principles.md b/release-ja/04-foundations/03-security-principles.md new file mode 100644 index 00000000..a9719d90 --- /dev/null +++ b/release-ja/04-foundations/03-security-principles.md @@ -0,0 +1,214 @@ +--- + +title: Principles of Security +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Johan Sydseter, Andreas Happe +document: OWASP Developer Guide +order: 4030 +permalink: /release/foundations/security_principles/ + +--- + +{% include breadcrumb.html %} + +### 2.3 Principles of security + +This section is a very brief introduction to some concepts used within the software security domain, +as these may not be familiar to many application developers. +The OWASP [Cheat Sheet Series][csproject] provides more in depth explanations for these security principles, +see the further reading at the end of this section. + +#### Overview + +There are various concepts and terms used in the security domain that are fundamental +to the understanding and discussion of application security. +Security architects and security engineers will be familiar with these terms and development teams +will also need this understanding to implement secure applications. + +#### Security by Design + +Security should not be an afterthought or add-on. When developing systems, you should begin with identifying relevant +security requirements and treat them as an integral part of the overall process and system design. Begin with +establishing and adopting relevant principles and policies as a foundation for your design, then build security +into your development life cycle. Keep also in mind that the system you are building also will be needing maintenance +and that system operators will need to securely manage and even shutdown and dispose of the system. Therefore, commit +to secure operations by developing secure "operational management"[^1] principles and practices. + +#### Security by Default + +Secure by default means that the default configuration settings are the most secure settings possible. This is not +necessarily the most user-friendly settings. Evaluate what the settings should be, based on both risk analysis and +usability tests. As a result, the precise meaning is up to you to decide. Nevertheless, configure the system to only +provide the least functionality and to specifically prohibit and/or restrict the use of all other functions, ports, +protocols, and/or services. Also configure the defaults to be as restrictive as possible, according to best practices, +without compromising the "Psychological acceptability" and "Usability and Manageability" of the system. + +#### No security guarantee + +One of the most important principles of software security is that no application or system is totally +100% guaranteed to be secure from all attacks. This may seem an unusually pessimistic starting point +but it is merely acknowledging the real world; given enough time and enough resources any system can be compromised. +The goal of software security is not '100% secure' but to make it hard enough and the rewards small enough +that malicious actors look elsewhere for systems to exploit. + +#### Defense in Depth + +Also known as layered defense, [defense in depth][did] is a security principle where defense against attack +is provided by multiple security controls. +The aim is that single points of complete compromise are eliminated or mitigated +by the incorporation of a series or multiple layers of security safeguards and risk-mitigation countermeasures. + +If one layer of defense turns out to be inadequate then, if diverse defensive strategies are in place, +another layer of defense may prevent a full breach and if that one is circumvented then +the next layer may block the exploit. + +#### Fail Safe + +This is a security principle that aims to maintain confidentiality, integrity and availability +when an error condition is detected. +These error conditions may be a result of an attack, or may be due to design or implementation failures, +in any case the system / applications should default to a secure state rather than an unsafe state. + +For example unless an entity is given explicit access to an object, +it should be denied access to that object by default. +This is often described as 'Fail Safe Defaults' or 'Secure by Default'. + +In the context of software security, the term 'fail secure' is commonly used interchangeably with fail safe, +which comes from physical security terminology. +Failing safe also helps software resiliency in that the system / application can rapidly recover +upon design or implementation flaws. + +#### Least Privilege + +A security principle in which a person or process is given only the minimum level of access rights (privileges) +that is necessary for that person or process to complete an assigned operation. +This right must be given only for a minimum amount of time that is necessary to complete the operation. + +This helps to limits the damage when a system is compromised by minimizing the ability of an attacker +to escalate privileges both laterally or vertically. +In order to apply this [principle of least privilege][elp] proper granularity +of privileges and permissions should be established. + +#### Compartmentalize + +The principle of least privilege works better if access rights are not an "all or nothing" access model. +Instead, compartmentalize the access to information on a "need-to-know" basis in order to perform certain tasks. +The compartmentalization principle helps in minimizing the impact of a security breach in case of a successful +breach attempt but must be used in moderation in order to prevent the system from becoming unmanageable. +Therefore, follow also the principle of "Economy of Mechanism". + +#### Separation of Duties + +Also known as [separation of privilege][sop], separation of duties is a security principle which requires that +the successful completion of a single task +is dependent upon two or more conditions that are insufficient, individually by themselves, for completing the task. + +There are many applications for this principle, +for example limiting the damage an aggrieved or malicious insider can do, or by limiting privilege escalation. + +#### Economy of Mechanism + +Also known as 'keep it simple', if there are multiple implementations then the simplest +and most easily understood implementation should be chosen. + +The likelihood of vulnerabilities increases with the complexity of the software architectural design and code, +and increases further if it is hard to follow or review the code. +The attack surface of the software is reduced by keeping the software design +and implementation details simple and understandable. + +#### Complete Mediation + +A security principle that ensures that authority is not circumvented in subsequent requests of an object by a subject, +by checking for authorization (rights and privileges) upon every request for the object. + +In other words, the access requests by a subject for an object are completely mediated every time, +so that all accesses to objects must be checked to ensure that they are allowed. + +#### Open Design + +The open design security principle states that the implementation details of the design +should be independent of the design itself, +allowing the design to remain open while the implementation can be kept secret. +This is in contrast to security by obscurity where the security of the software +is dependent upon the obscuring of the design itself. + +When software is architected using the open design concept, +the review of the design itself will not result in the compromise of the safeguards in the software. + +#### Least Common Mechanism + +The security principle of least common mechanisms disallows the sharing of mechanisms that are common +to more than one user or process if the users or processes are at different levels of privilege. +This is important when defending against privilege escalation. + +#### Psychological acceptability + +A security principle that aims at maximizing the usage and adoption of the security functionality in the software +by ensuring that the security functionality is easy to use and at the same time transparent to the user. +Ease of use and transparency are essential requirements for this security principle to be effective. + +Security controls should not make the resource significantly more difficult to access +than if the security control were not present. +If a security control provides too much friction for the users then they may look for ways +to defeat the control and “prop the doors open”. + +#### Usability and Manageability + +Is a principle related to psychological acceptability, but goes beyond just the perceived psychological +acceptability to also include the design, implementation and operation of security controls. +The configuration, administration and integration of security components should not be overly complex or +obscure. Therefore, always use open standards for portability and interoperability, use common language +in developing security requirements, design security to allow for regular adoption of new technology, +ensure a secure and logical upgrade process exist, automate security management activities and strive for +operational ease of use. + +#### Secure the Weakest Link + +This security principle states that the resiliency of your software against hacker attempts will depend heavily +on the protection of its weakest components, be it the code, service or an interface. Therefore, identifying the +weakest component and addressing the most serious risk first, until an acceptable level of risk is attained, is +considered good security practice. + +#### Leveraging Existing Components + +This is a security principle that focuses on ensuring that the attack surface is not increased +and no new vulnerabilities are introduced by promoting the reuse of existing +software components, code and functionality. + +Existing components are more likely to be tried and tested, and hence more secure, +and also should have security patches available. +In addition components developed within the open source community have the further benefit of 'many eyes' +and are therefore likely to be even more secure. + +#### References + +* OWASP Cheat Sheet series + * [Authentication Cheat Sheet][csauthn] + * [Authorization Cheat Sheet][csauthz] + * [Secure Product Design Cheat Sheet][spdcs] +* OWASP Top 10 Proactive Controls + * [C5: Secure by Default Configurations](https://top10proactive.owasp.org/the-top-10/c5-secure-by-default/) +* Other + * [Compartmentalization (information security)](https://en.wikipedia.org/wiki/Compartmentalization_(information_security)), +(Wikipedia) + * [Least Functionality](https://csf.tools/reference/nist-sp-800-53/r5/cm/cm-7/), (NIST) + * [Security by Design](https://pubs.opengroup.org/security/o-esa/#_Toc291061712), (Open Group) + * [Usability and Manageability](https://pubs.opengroup.org/security/o-esa/#_Toc291061714), (Open Group) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0403] or [edit on GitHub][edit0403]. + +[^1]: [Operational Management](https://owaspsamm.org/model/operations/operational-management/), (SAMM) + +[csauthn]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet +[csauthz]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet +[csproject]: https://owasp.org/www-project-cheat-sheets/ +[did]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html#2-the-principle-of-defense-in-depth +[issue0403]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-foundations/03-security-principles +[elp]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html#enforce-least-privileges +[edit0403]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/04-foundations/03-security-principles.md +[sop]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html#1-the-principle-of-least-privilege-and-separation-of-duties +[spdcs]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet diff --git a/release-ja/04-foundations/04-crypto-principles.md b/release-ja/04-foundations/04-crypto-principles.md new file mode 100644 index 00000000..e0c23ccd --- /dev/null +++ b/release-ja/04-foundations/04-crypto-principles.md @@ -0,0 +1,268 @@ +--- + +title: Principles of Cryptography +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 4040 +permalink: /release/foundations/crypto_principles/ + +--- + +{% include breadcrumb.html %} + +### 2.4 Principles of cryptography + +Cryptography is fundamental to the Confidentiality and Integrity of applications and systems. +The OWASP [Cheat Sheet][csproject] series describes the use of cryptography and some of these are +listed in the further reading at the end of this section. + +#### Overview + +This section provides a brief introduction to cryptography (often simply referred to as "crypto") and the terms used. +Cryptography is a large subject and can get very mathematical, +but fortunately for the majority of development teams a general understanding of the concepts is sufficient. +This general understanding, with the guidance of security architects, should allow implementation +of cryptography by the development team for the application or system. + +#### Uses of cryptography + +Although cryptography was initially restricted primarily to the military and the realm of academia, +cryptography has become ubiquitous in securing software applications. +Common every day uses of cryptography include mobile phones, passwords, SSL VPNs, smart cards, and DVDs. +Cryptography has permeated through everyday life, and is heavily used by many web applications. + +Cryptography is one of the more advanced topics of information security, +and one whose understanding requires the most schooling and experience. +It is difficult to get right because there are many approaches to encryption, +each with advantages and disadvantages that need to be thoroughly understood by solution architects. + +The proper and accurate implementation of cryptography is extremely critical to its efficacy. +A small mistake in configuration or coding will result in removing most of the protection +and rending the crypto implementation useless. + +A good understanding of crypto is required to be able to discern between solid products and snake oil. +The inherent complexity of crypto makes it easy to fall for fantastic claims from vendors about their product. +Typically, these are "a breakthrough in cryptography" or "unbreakable" or provide "military grade" security. +If a vendor says "trust us, we have had experts look at this," chances are they weren't experts! + +#### Confidentiality + +For the purposes of this section, confidentiality is defined as "no unauthorized disclosure of information". +Cryptography addresses this via encryption of either the data at rest or data in transit by +protecting the information from all who do not hold the decryption key. +Cryptographic hashes (secure, one way hashes) to prevent passwords from disclosure. + +#### Authentication + +[Authentication][csauthn] is the process of verifying a claim that a subject is who it says it is +via some provided corroborating evidence. +Cryptography is central to authentication: + +1. to protect the provided corroborating evidence (for example hashing of passwords for subsequent storage) +2. in authentication protocols often use cryptography to either directly authenticate entities + or to exchange credentials in a secure manner +3. to verify the identity one or both parties in exchanging messages, + for example identity verification within [Transport Layer Security][tls] (TLS) + +OpenID Connect is widely used as an identity layer on top of the OAuth 2.0 protocol, +see the [OAuth 2.0 Protocol][csoauth] Cheat Sheet. + +#### Integrity + +Integrity ensures that even authorized users have performed no accidental or malicious alternation of information. +Cryptography can be used to prevent tampering by means of Message Authentication Codes (MACs) or digital signatures. + +The term 'message authenticity' refers to ensuring the integrity of information, +often using symmetric encryption and shared keys, +but does not authenticate the sending party. + +The term 'authenticated encryption' also ensures the integrity of information, +and, if asymmetric encryption is used, can authenticate the sender. + +#### Non-repudiation + +Non-repudiation of sender ensures that someone sending a message should not be able to deny later that they have sent it. +Non-repudiation of receiver means that the receiver of a message should not be able to deny that they have received it. +Cryptography can be used to provide non-repudiation by providing unforgeable messages or replies to messages. + +Non-repudiation is useful for financial, e-commerce, and contractual exchanges. +It can be accomplished by having the sender or recipient digitally sign some unique transactional record. + +#### Attestation + +Attestation is the act of "bearing witness" or certifying something for a particular use or purpose. +Attestation is generally discussed in the context of a Trusted Platform Module (TPM), +Digital Rights Management (DRM), and UEFI Secure Boot. + +For example, Digital Rights Management is interested in attesting that your device +or system hasn't been compromised with some back-door to allow someone to illegally copy DRM-protected content. + +Cryptography can be used to provide a chain of evidence that everything is as it is expected to be, +to prove to a challenger that everything is in accordance with the challenger's expectations. +For example, remote attestation can be used to prove to a challenger that +you are indeed running the software that you claim that you are running. +Most often attestation is done by providing a chain of digital signatures starting with +a trusted (digitally signed) boot loader. + +#### Cryptographic hashes + +Cryptographic hashes, also known as message digests, are functions that map arbitrary length bit strings +to some fixed length bit string known as the 'hash value' or 'digest value'. +These hash functions are many-to-one mappings that are compression functions. + +Cryptographic hash functions are used to provide data integrity (i.e., to detect intentional data tampering), +to store passwords or pass phrases, and to provide digital signatures in a more efficient manner +than using asymmetric ciphers. +Cryptographic hash functions are also used to extend a relatively small bit of entropy +so that secure random number generators can be constructed. + +When used to provide data integrity, cryptographic functions provide two types of integrity: +keyed hashes, often called 'message authentication codes', and unkeyed hashes called 'message integrity codes'. + +#### Ciphers + +A cipher is an algorithm that performs encryption or decryption. +Modern ciphers can be categorized in a couple of different ways. +The most common distinctions between them are: + +* Whether they work on fixed size number of bits (block ciphers) or on a continuous stream of bits (stream ciphers) +* Whether the same key is used for both encryption and decryption (symmetric ciphers) + or separate keys for encryption and decryption (asymmetric ciphers) + +#### Symmetric Ciphers + +Symmetric ciphers encrypt and decrypt using the same key. +This implies that if one party encrypts data that a second party must decrypt, +those two parties must share a common key. + +Symmetric ciphers come in two main types: + +1. Block ciphers, which operate on a block of characters (typically 8 or 16 octets) at a time. + An example of a block cipher is AES +2. Stream ciphers, which operate on a single bit (or occasionally a single byte) at a time. + Examples of a stream ciphers are RC4 (aka, ARC4) and Salsa20 + +Note that all block ciphers can also operate in 'streaming mode' by selecting the appropriate cipher mode. + +#### Cipher Modes + +Block ciphers can function in different modes of operations known as "cipher modes". +This cipher mode algorithmically describes how a cipher operates to repeatedly +apply its encryption or decryption mechanism to a given cipher block. +Cipher modes are important because they have an enormous impact on both the confidentiality +and the message authenticity of the resulting ciphertext messages. + +Almost all cryptographic libraries support the four original DES cipher modes of ECB, CBC (Cipher Block Chaining) +OFB (Output Feedback), and CFB (Cipher Feedback). Many also support CTR (Counter) mode. + +#### Initialization vector + +A cryptographic initialization vector (IV) is a fixed size input to a block cipher's encryption / decryption primitive. +The IV is recommended (and in many cases, required) to be random or at least pseudo-random. + +#### Padding + +Except when they are operating in a streaming mode, block ciphers generally operate on fixed size blocks. +These block ciphers must also operate on messages of any size, +not just those that are an integral multiple of the cipher's block size, +and so the message can be padded to fit into the next fixed-size block. + +#### Asymmetric ciphers + +Asymmetric ciphers encrypt and decrypt with two different keys. +One key generally is designated as the private key and the other is designated as the public key. +Generally the public key is widely shared and the private key is kept secure. + +Asymmetric ciphers are several orders of magnitude slower than symmetric ciphers. +For this reason they are used frequently in hybrid cryptosystems, which combine asymmetric and symmetric ciphers. +In such hybrid cryptosystems, a random symmetric session key is generated +which is only used for the duration of the encrypted communication. +This random session key is then encrypted using an asymmetric cipher and the recipient's private key. +The plaintext data itself is encrypted with the session key. +Then the entire bundle (encrypted session key and encrypted message) is all sent together. +Both [TLS][tls] and S/MIME are common cryptosystems using hybrid cryptography. + +#### Digital signature + +Digital signatures are a cryptographically unique data string that is used to ensure data integrity +and prove the authenticity of some digital message, and that associates some input message with an originating entity. +A digital signature generation algorithm is a cryptographically strong algorithm that is used +to generate a digital signature. + +#### Key agreement protocol + +Key agreement protocols are protocols whereby N parties (usually two) can agree on a common key +without actually exchanging the key. +When designed and implemented properly, key agreement protocols prevent adversaries +from learning the key or forcing their own key choice on the participating parties. + +#### Application level encryption + +Application level encryption refers to encryption that is considered part of the application itself; +it implies nothing about where in the application code the encryption is actually done. + +#### Key derivation + +A key derivation function (KDF) is a deterministic algorithm to derive a key of a given size from some secret value. +If two parties use the same shared secret value and the same KDF, they should always derive exactly the same key. + +#### Key wrapping + +Key wrapping is a construction used with symmetric ciphers to protect cryptographic key material +by encrypting it in a special manner. +Key wrap algorithms are intended to protect keys while held in untrusted storage +or while transmitting keys over insecure communications networks. + +#### Key exchange algorithms + +Key exchange algorithms (also referred to as key establishment algorithms) are protocols +that are used to exchange secret cryptographic keys +between a sender and receiver in a manner that meets certain security constraints. +Key exchange algorithms attempt to address the problem of securely sharing a common secret key with two parties +over an insecure communication channel in a manner that no other party can gain access to a copy of the secret key. + +The most familiar key exchange algorithm is Diffie-Hellman Key Exchange. +There are also password authenticated key exchange algorithms. +RSA key exchange using PKI or webs-of-trust or trusted key servers are also commonly used. + +#### Key transport protocols + +Key Transport protocols are where one party generates the key and sends it securely to the recipient(s). + +#### Key agreement protocols + +Key Agreement protocols are protocols whereby N parties (usually two) can agree on a common key +with all parties contributing to the key value. +These protocols prevent adversaries from learning the key or forcing their own key choice on the participating parties. + +#### References + +* OWASP Cheat Sheet series + * [Authentication][csauthn] + * [Authorization][csauthz] + * [Cryptographic Storage][cscs] + * [Key Management][kmcs] + * [OAuth 2.0 Protocol][csoauth] + * [SAML Security][sscs] + * [Secure Product Design][spdcs] + * [User Privacy Protection][uppcs] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0404] or [edit on GitHub][edit0404]. + +[csauthn]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet +[csauthz]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet +[csoauth]: https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet +[csproject]: https://owasp.org/www-project-cheat-sheets/ +[cscs]: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet +[issue0404]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-foundations/04-crypto-principles +[kmcs]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet +[edit0404]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/04-foundations/04-crypto-principles.md +[sscs]: https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet +[spdcs]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet +[tls]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet +[uppcs]: https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet diff --git a/release-ja/04-foundations/05-top-ten.md b/release-ja/04-foundations/05-top-ten.md new file mode 100644 index 00000000..33714918 --- /dev/null +++ b/release-ja/04-foundations/05-top-ten.md @@ -0,0 +1,234 @@ +--- + +title: OWASP Top Ten +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 4050 +permalink: /release/foundations/owasp_top_ten/ + +--- + +{% include breadcrumb.html %} + + + +![Top 10 logo](../../../assets/images/logos/top10.png "OWASP Top 10"){: .image-right } + +### 2.5 OWASP Top Ten + +The OWASP Top Ten is a very well known list of web application security risks, +and is included by the OWASP Software Assurance Maturity Model [(SAMM)][samm] +in the Education & Guidance practice within the Governance business function. + +#### Overview + +The OWASP [Top 10 Web Application Security Risks][top10project] project is probably the most well known security concept +within the security community, achieving wide spread acceptance and fame soon after its release in 2003. +Often referred to as just the 'OWASP Top Ten', it is a list that identifies the most important threats +to web applications and seeks to rank them in importance and severity. + +The list has changed over time, with some threat types becoming more of a problem to web applications +and other threats becoming less of a risk as technologies change. +The [latest version][top10] was issued in 2021 and each category is summarized below. + +Note that there are various 'OWASP Top Ten' projects, for example the 'OWASP Top 10 for Large Language Model Applications', +so to avoid confusion the context should be noted when referring to these lists. + +#### A01:2021 Broken Access Control + +Access control involves the use of protection mechanisms that can be categorized as: + +* Authentication (proving the identity of an actor) +* Authorization (ensuring that a given actor can access a resource) +* Accountability (tracking of activities that were performed) + +Broken Access Control is where the product does not restrict, or incorrectly restricts, access to a resource +from an unauthorized or malicious actor. +When a security control fails or is not applied then attackers can compromise the security of the product +by gaining privileges, reading sensitive information, executing commands, evading detection, etc. + +Broken Access Control can take many forms, such as path traversal or elevation of privilege, +so refer to both the [Common Weakness Enumeration CWE-284][cwe284] and [A01 Broken Access Control][a01] +and also follow the various [OWASP Cheat Sheets][a01cs] related to access controls. + +#### A02:2021 Cryptographic Failures + +Referring to [OWASP Top 10 A02:2021][a02], sensitive data should be protected when at rest and in transit. +Cryptographic failures occur when the cryptographic security control is either broken or not applied, +and the data is exposed to unauthorized actors - malicious or not. + +It is important to protect data both at rest, when it is stored in an area of memory, +and also when it is in transit such as being transmitted across a communication channel or being transformed. +A good example of protecting data transformation is given by [A02 Cryptographic Failures][a02] +where sensitive data is properly encrypted in a database, but the export function automatically +decrypts the data leading to sensitive data exposure. + +Crypto failures can take many forms and may be subtle - a security control that looks secure may be easily broken. +Follow the crypto [OWASP Cheat Sheets][a02cs] to get the basic crypto controls in place +and consider putting a crypto audit in place. + +#### A03:2021 Injection + +A lack of input validation and sanitization can lead to injection exploits, +and this risk has been a constant feature of the OWASP Top Ten since the first version was published in 2003. +These vulnerabilities occur when hostile data is directly used within the application +and can result in malicious data being used to subvert the application; see [A03 Injection][a03] for further explanations. + +The security control is straight forward: all input from untrusted sources should be sanitized and validated. +See the [Injection Cheat Sheets][a03cs] for the various types of input and their controls. + +#### A04:2021 Insecure Design + +It is important that security is built into applications from the beginning and not applied as an afterthought. +The [A04 Insecure Design][a04] category recognizes this and advises that +the use of threat modeling, secure design patterns, and reference architectures +should be incorporated within the application design and architecture activities. + +In practice this involves establishing a secure development lifecycle that encourages +the identification of security requirements, the periodic use of threat modeling +and consideration of existing secure libraries and frameworks. +This category was introduced in the 2021 version and for now the supporting cheat sheets only cover [threat modeling][cstm]; +as this category becomes more established it is expected that more supporting information will become available. + +#### A05:2021 Security Misconfiguration + +Systems and large applications can be configurable, and this configuration is often used to secure the system/application. +If this configuration is misapplied then the application may no longer be secure, +and instead be vulnerable to well-known exploits. The [A05 Security Misconfiguration][a05] page contains +a common example of misconfiguration where default accounts and their passwords are still enabled and unchanged. +These passwords and accounts are usually well-known and provide an easy way for malicious actors to compromise applications. + +Both the [OWASP Top 10 A05:2021][a05] and the linked [OWASP Cheat Sheets][a05cs] provide strategies to establish +a concerted, repeatable application security configuration process to minimize misconfiguration. + +#### A06:2021 Vulnerable and Outdated Components + +Perhaps one of the easiest and most effective security activities +is keeping all the third party software dependencies up to date. +If a vulnerable dependency is identified by a malicious actor during the reconnaissance phase of an attack +then there are databases available, such as [Exploit Database][exploit], that will provide a description of any exploit. +These databases can also provide ready made scripts and techniques for attacking a given vulnerability, +making it easy for vulnerable third party software dependencies to be exploited . + +Risk [A06 Vulnerable and Outdated Components][a06] underlines the importance of this activity, +and recommends that fixes and upgrades to the underlying platform, frameworks, and dependencies +are based on a risk assessment and done in a 'timely fashion'. +Several tools can used to analyze dependencies and flag vulnerabilities, refer to the [Cheat Sheets][a06cs] for these. + +#### A07:2021 Identification and Authentication Failures + +Confirmation of the user's identity, authentication, and session management is critical +to protect the system or application against authentication related attacks. +Referring to risk [A07 Identification and Authentication Failures][a07], authorization can fail in several ways +that often involve other OWASP Top Ten risks: + +* broken access controls (A01) +* cryptographic failure (A02) +* default passwords (A05) +* out-dated libraries (A06) + +Refer to the [Cheat Sheets][a07cs] for the several good practices that are needed for secure authorization. +There are also third party suppliers of Identity and Access Management (IAM) that will provide this as a service, +consider the cost / benefit of using these (often commercial) suppliers. + +#### A08:2021 Software and Data Integrity Failures + +Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. +This is a wide ranging category that describes [supply chain attacks][cschain], +compromised auto-update and use of untrusted components for example. +[A07 Software and Data Integrity Failures][a08] was a new category introduced in 2021 +so there is little information available from the [Cheat Sheets][a08cs], +but this is sure to change for such an important threat. + +#### A09:2021 Security Logging and Monitoring Failures + +Logging and monitoring helps detect, escalate, and respond to active breaches; without it breaches will not be detected. +[A09 Security Logging and Monitoring Failures][a09] lists various logging and monitoring techniques that should be familiar, +but also others that may not be so common; +for example monitoring the DevOps supply chain may be just as important as monitoring the application or system. +The [Cheat Sheets][a09cs] provide guidance on sufficient logging and also provide for a common logging vocabulary. +The aim of this common vocabulary is to provide logging that uses a common set of terms, formats and key words; +and this allows for easier monitoring, analysis and alerting. + +#### A10:2021 Server-Side Request Forgery + +Referring to [A10 Server-Side Request Forgery (SSRF)][a10], these vulnerabilities can occur +whenever a web application is fetching a remote resource without validating the user-supplied URL. +These exploits allow an attacker to coerce the application to send a crafted request to an unexpected destination, +even when protected by a firewall, VPN, or another type of network access control list. +Fetching a URL has become a common scenario for modern web applications and as a result the incidence of SSRF is increasing, +especially for [cloud services][cscloud] and more complex application architectures. + +This is a new category introduced in 2021 with a single (for now) [Cheat Sheet][a10cs] that deals with SSRF. + +#### OWASP top tens + +There are various 'Top 10' projects created by OWASP that, depending on the context, +may also be referred to as 'OWASP Top 10'. Here is a list of the stable 'OWASP Top 10' projects: + +* [API Security Top 10][apisec] +* [Data Security Top 10][data10] +* [Low-Code/No-Code Top 10][lcnc10] +* [Mobile Top 10][mobile10] +* [Serverless Top 10][serverless10] +* [Top 10 CI/CD Security Risks][cicd10] +* [Top 10 for Large Language Model Applications][llm10] +* [Top 10 Privacy Risks][privacy10] +* [Top 10 Proactive Controls][proactive10] +* [Top 10 Web Application Security Risks][top10] + +Other OWASP Top 10s are 'incubator' projects, which are work in progress, so this list will change over time. + +---- + +The OWASP Developer Guide is a community effort; if you see something that needs changing +then [submit an issue][issue0405] or [edit on GitHub][edit0405]. + +[a01]: https://owasp.org/Top10/A01_2021-Broken_Access_Control/ +[a01cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a012021-broken-access-control +[a02]: https://owasp.org/Top10/A02_2021-Cryptographic_Failures/ +[a02cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a022021-cryptographic-failures +[a03]: https://owasp.org/Top10/A03_2021-Injection/ +[a03cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a032021-injection +[a04]: https://owasp.org/Top10/A04_2021-Insecure_Design/ +[a05]: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/ +[a05cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a052021-security-misconfiguration +[a06]: https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/ +[a06cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a062021-vulnerable-and-outdated-components +[a07]: https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/ +[a07cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a072021-identification-and-authentication-failures +[a08]: https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/ +[a08cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a082021-software-and-data-integrity-failures +[a09]: https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/ +[a09cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a092021-security-logging-and-monitoring-failures +[a10]: https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/ +[a10cs]: https://cheatsheetseries.owasp.org/IndexTopTen.html#a102021-server-side-request-forgery-ssrf +[apisec]: https://owasp.org/API-Security +[cicd10]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[cschain]: https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet +[cscloud]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet +[cstm]: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet +[cwe284]: https://cwe.mitre.org/data/definitions/284.html +[data10]: https://owasp.org/www-project-data-security-top-10/ +[exploit]: https://www.exploit-db.com/ +[issue0405]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-foundations/05-top-ten +[lcnc10]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[mobile10]: https://owasp.org/www-project-mobile-top-10/ +[edit0405]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/04-foundations/05-top-ten.md +[privacy10]: https://owasp.org/www-project-top-10-privacy-risks/ +[proactive10]: https://owasp.org/www-project-proactive-controls/ +[samm]: https://owaspsamm.org/about/ +[serverless10]: https://owasp.org/www-project-serverless-top-10/ +[top10project]: https://owasp.org/www-project-top-ten/ +[top10]: https://owasp.org/Top10/ +[llm10]: https://owasp.org/www-project-top-10-for-large-language-model-applications/ diff --git a/release-ja/04-foundations/info.md b/release-ja/04-foundations/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/04-foundations/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/04-foundations/toc.md b/release-ja/04-foundations/toc.md new file mode 100644 index 00000000..b3cd8b26 --- /dev/null +++ b/release-ja/04-foundations/toc.md @@ -0,0 +1,60 @@ +--- + +title: Foundations +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 4000 +permalink: /release/foundations/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){: .image-right } + +## 2. Foundations + +There are various foundational concepts and terminology that are commonly used in software security. +Although many of these concepts are complex to implement and are based on heavy-duty theory, +the principles are often fairly straight forward and are accessible for every software engineer. + +A reasonable grasp of these foundational concepts allows development teams to understand and implement +software security for the application or system under development. +This Developer Guide can only give a brief overview of these concepts, +for in-depth knowledge refer to the many texts on security such as the [The Cyber Security Body Of Knowledge][cbok]. + +If changes are being introduced to the security culture of an organization +then make sure there is management buy-in and clear goals to achieve. +Without these then attempts to improve the security posture will probably fail - see the +[Security Culture][culturegoal] project for the importance of getting management, +security and development teams working together. + +Sections: + +2.1 [Security fundamentals](01-security-fundamentals.md) +2.2 [Secure development and integration](02-secure-development.md) +2.3 [Principles of security](03-security-principles.md) +2.4 [Principles of cryptography](04-crypto-principles.md) +2.5 [OWASP Top 10](05-top-ten.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0400] or [edit on GitHub][edit0400]. + +[cbok]: https://www.cybok.org/ +[culturegoal]: https://owasp.org/www-project-security-culture/stable/3-Goal_Setting_and_Security_Team_Collaboration/ +[edit0400]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/04-foundations/toc.md +[issue0400]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-foundations/00-toc diff --git a/release-ja/05-requirements/00-toc.md b/release-ja/05-requirements/00-toc.md new file mode 100644 index 00000000..06153c59 --- /dev/null +++ b/release-ja/05-requirements/00-toc.md @@ -0,0 +1,56 @@ +--- + +title: Requirements +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: +permalink: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){height=180px} + +## 3. Requirements + +Security requirements are statements of +security functionality that ensure the different security properties of a software application are being satisfied. +Security requirements are derived from industry standards, applicable laws, and a history of past vulnerabilities. +Security requirements define new features or additions to existing features to solve a specific security problem +or eliminate potential vulnerabilities. + +Security requirements also provide a foundation of vetted security functionality for an application. +Instead of creating a custom approach to security for every application, +standard security requirements allow developers to reuse the definition of security controls and best practices; +those same vetted security requirements provide solutions for security issues that have occurred in the past. + +The importance of understanding key security requirements is described in the [Security Requirements][sammdsr] +practice that is part of the [Design][sammd] business function section within the OWASP [SAMM model][samm]. +Ideally structured software security requirements are available within with a security a requirements framework, +and these are utilized by both developer teams and product teams. +In addition suppliers to the organization must meet security requirements; +build security into supplier agreements in order to ensure compliance with organizational security requirements. + +In summary, security requirements exist to prevent the repeat of past security failures. + +Sections: + +3.1 [Requirements in practice](#requirements-in-practice) +3.2 [Risk profile](#risk-profile) +3.3 [OpenCRE](#opencre) +3.4 [SecurityRAT](#security-rat) +3.5 [ASVS requirements)](#asvs-requirements) +3.6 [MAS requirements](#mas-requirements) +3.7 [SKF requirements](#skf-requirements) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0500]. + +[issue0500]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2005-requirements/00-toc +[samm]: https://owaspsamm.org/about/ +[sammd]: https://owaspsamm.org/model/design/ +[sammdsr]: https://owaspsamm.org/model/design/security-requirements/ diff --git a/release-ja/05-requirements/01-requirements.md b/release-ja/05-requirements/01-requirements.md new file mode 100644 index 00000000..8035427e --- /dev/null +++ b/release-ja/05-requirements/01-requirements.md @@ -0,0 +1,123 @@ +--- + +title: Requirements in Practice +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: 5010 +permalink: /release/requirements/requirements_in_practice/ + +--- + +{% include breadcrumb.html %} + +### 3.1 Requirements in practice + +This section deals with Security Requirements, which is a security practice in the Design business function +section of the OWASP Software Assurance Maturity Model ([SAMM][samm]). +This security requirements practice has two activities, Software Requirements and Supplier Security, +with regulatory and statutory requirements being an important subset of both these activities. + +#### Overview + +Security requirements are part of every secure development process +and form the foundation for the application's security posture. +Requirements will certainly help with the prevention of many types of vulnerabilities. + +Requirements come from various sources, three common ones being: + +1. Software-related requirements which specify objectives and expectations + to protect the service and data at the core of the application +2. Requirements relative to supplier organizations that are part of the development context of the application +3. Regulatory and Statutory requirements + +Ideally security requirements are built in at the beginning of development, +but there is no wrong time to consider these security requirements and add new ones as necessary. + +#### Software requirements + +Defining security requirements can be daunting at times, +for example they may reference cryptographic techniques that can be misapplied, +but it is perfectly acceptable to state these requirements in everyday language. +For example a security requirement could be written as “Identify the user of the application at all times” +and this is certainly sufficient to require that authentication is included in the design. + +The SAMM [Security Requirements practice][sammdsr] lists maturity levels of software security requirements +that specify objectives and expectations. +Choose the level that is appropriate for the organization and the development team, +with the understanding that any of these levels are perfectly acceptable. + +The software security requirements maturity levels are: + +1. High-level application security objectives are mapped to functional requirements +2. Structured security requirements are available and utilized by developer teams +3. Build a requirements framework for product teams to utilize + +OWASP provides projects that can help in identifying security requirements +that will protect the service and data at the core of the application. +The [Application Security Verification Standard][asvs] provides a list of requirements for secure development, +and this can be used as a starting point for the security requirements. +The [Mobile Application Security][mas] provides a similar set of standard security requirements for mobile applications. + +Consider using [Abuse Cases][csabuse] to identify possible attacks and the controls required to mitigate them. +This can then feed into the software security requirements. + +#### Supplier security + +External suppliers involved in the development process need to be assessed for their security practices and compliance. +Depending on their level of involvement these suppliers can have a significant impact on the security of the application +so a set of security requirements will have to be negotiated with them. + +[SAMM][sammdsr] lists maturity levels for the security requirements +that will clarify the strengths and weaknesses of your suppliers. +Note that supplier security is distinct from security of third-party software and libraries, +and the use of third-party and open source software is discussed +in its own section on dependency checking and tracking. + +The supplier security requirements maturity levels are: + +1. Evaluate the supplier based on organizational security requirements +2. Build security into supplier agreements in order to ensure compliance with organizational requirements +3. Ensure proper security coverage for external suppliers by providing clear objectives + +#### Regulatory and statutory requirements + +Regulatory requirements can include security requirements which then must be taken into account. +Different industries are regulated are regulated to a lesser or greater extent, +and the only general advice is to be aware and follow the regulations. + +Various jurisdictions will have different statutory requirements that may result in security requirements. +Any applicable statutory security requirement should be added to the application security requirements. +Similarly to regulatory requirements, +the only general advice is to be familiar with and follow the appropriate statutory requirements. + +#### Periodic review + +The security requirements should be identified and recorded at the beginning of any new development +and also when new features are added to an existing application. +These security requirements should be periodically revisited and revised as necessary; +for example security standards are updated and new regulations come into force, +both of which may have a direct impact on the application. + +#### References + +* OWASP projects: + * [Software Assurance Maturity Model (SAMM)][samm] + * [Top Ten Proactive Controls][proactive10] + * [Application Security Verification Standard (ASVS)][asvs] + * [Mobile Application Security][mas] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0501] or [edit on GitHub][edit0501]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[csabuse]: https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet +[issue0501]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2005-requirements/01-requirements +[mas]: https://mas.owasp.org/ +[edit0501]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/05-requirements/01-requirements.md +[proactive10]: https://owasp.org/www-project-proactive-controls/ +[samm]: https://owaspsamm.org/about/ +[sammdsr]: https://owaspsamm.org/model/design/security-requirements/ diff --git a/release-ja/05-requirements/02-risk.md b/release-ja/05-requirements/02-risk.md new file mode 100644 index 00000000..ee169dd4 --- /dev/null +++ b/release-ja/05-requirements/02-risk.md @@ -0,0 +1,110 @@ +--- + +title: Risk Profile +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 5020 +permalink: /release/requirements/risk_profile/ + +--- + +{% include breadcrumb.html %} + +### 3.2 Risk profile + +This section discusses the Application Risk Profile, +an activity in the OWASP Software Assurance Maturity Model ([SAMM][samm]). +The risk profile activity is part of the Threat Assessment security practice in the Design business function. + +#### Overview + +Risk management is the identification, assessment, and prioritization of risks to the application or system. +The objective of risk management is to ensure that uncertainty does not deflect development activities +away from the business goals. + +Remediation is the strategy chosen in response to a risk to the business system, +and these risks are identified using various techniques such as threat modeling and security requirements analysis. + +Risk management can be split into two phases. First create a risk profile for the application +and then provide solutions (remediate) to those risks in a way that is best for the business; +risk management should always be business driven. + +#### Application risk profile + +The application risk profile is created to understand the likelihood and also the impact of an attack. +Over time various profiles could be created and these should be stored in a risk profile inventory, +and ideally the risk profiles should be revisited as part of the organization's secure development strategy. + +Quantifying risks is often difficult and there are many ways of approaching this; +refer to the reading list below for various strategies in creating a risk rating model. +The OWASP page on [Risk Rating Methodology][rrm] describes some steps in identifying risks and quantifying them: + +1. Identifying a risk +2. Factors for estimating likelihood +3. Factors for estimating impact +4. Determining severity of the risk +5. Deciding what to fix +6. Customizing the risk rating model + +The activities involved in creating a risk profile depend very much on the processes +and maturity level of the organization, which is beyond the level of this +Developer Guide, so refer to the further reading listed below for guidance and examples. + +#### Remediation + +Risks identified during threat assessment, for example through the risk profile or through threat modeling, +should have solutions or remedies applied. + +There are four common ways to handle risk, often given the acronym TAME: + +1. Transfer: the risk is considered serious but can be transferred to another party + +2. Acceptance: the business is aware of the risk but has decided that no action needs to be taken; + the level of risk is deemed acceptable + +3. Mitigation: the risk is considered serious enough to require implementation of security controls + to reduce the risk to an acceptable level + +4. Eliminate / Avoid: the risk can be avoided or removed completely, + often by removing the object with which the risk is associated + +Examples: + +1. Transfer: a common example of transferring risk is the use of third party insurance + in response to the risk of RansomWare. + Insurance premiums are paid but losses to the business are covered by the insurance + +2. Acceptance: sometimes a risk is low enough in priority, or the outcome bearable, that it is not worth mitigating, + an example might be where the version of software is revealed but this is acceptable (or even desirable) + +3. Mitigation: it is common to implement a security control to mitigate the impact of a risk, for example + input sanitization or output encoding may be used for information supplied by an untrusted source, + or the use of encrypted communication channels for transferring high risk information + +4. Eliminate: an example may be that an application implements legacy functionality that is no longer used, + if there is a risk of it being exploited then the risk can be eliminated by removing this legacy functionality + +#### References + +* [OWASP Risk Rating Methodology][rrm] +* [NIST 800-30 - Guide for Conducting Risk Assessments][nist] +* [Government of Canada - The Harmonized Threat and Risk Assessment Methodology][tra] +* Mozilla's [Risk Assessment Summary][rrs] and [Rapid Risk Assessment (RRA)][rra] +* [Common Vulnerability Scoring System (CVSS)][cvss] used for severity and risk ranking + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0502] or [edit on GitHub][edit0502]. + +[cvss]: https://www.first.org/cvss/ +[issue0502]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2005-requirements/02-risk +[nist]: https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final +[edit0502]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/05-requirements/02-risk.md +[rra]: https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html +[rrm]: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology +[rrs]: https://infosec.mozilla.org/guidelines/assessing_security_risk +[samm]: https://owaspsamm.org/about/ +[tra]: https://cyber.gc.ca/en/guidance/harmonized-tra-methodology-tra-1 diff --git a/release-ja/05-requirements/03-opencre.md b/release-ja/05-requirements/03-opencre.md new file mode 100644 index 00000000..fcf78b81 --- /dev/null +++ b/release-ja/05-requirements/03-opencre.md @@ -0,0 +1,127 @@ +--- + +title: OpenCRE +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 5030 +permalink: /release/requirements/opencre/ + +--- + +{% include breadcrumb.html %} + +![OpenCRE logo](../../../assets/images/logos/opencre.png "OWASP OpenCRE"){: height="180px" } + +### 3.3 OpenCRE + +The [Open Common Requirement Enumeration][opencre] (OpenCRE) is a catalog of security requirements: +enumerating security topics and providing links to various standards, cheat sheets and guides. + +The OWASP [Integration Standards][intstand] project includes both the OpenCRE and Security +and the Application Security Wayfinder, it is an OWASP documentation project with production status. + +#### What is the Integration Standards project? + +The [Integration Standards][intstand] project is at the center of the OWASP project community; +it provides guidance on how to navigate and use the many projects within OWASP. +It does this in two ways, first is the [Application Security Wayfinder][intstand] which provides a visual map +of the most important OWASP projects - as of August 2024 there are 345 [OWASP projects][projects] +so this is a really useful visualization. +The second is the Open Common Requirement Enumeration ([OpenCRE][opencre]) which provides a consolidated reference of +standards, cheat sheets, tools and other enumerations (such as [CWE][cwe]). + +The Integration Standards project has also produced OWASP [Application Security Fragmentation][sdlc] +write-up on OWASP and the secure Software Development LifeCycle (SDLC). +This provides an overview of tools and techniques used for most SDLCs. + +#### What is OpenCRE? + +[OpenCRE][opencre] is a catalog, or enumeration, of various standards and reference material, including: + +* [CAPEC][capecocre] +* [CWE][cweocre] +* [NIST Special Publications][nist] [800-53][nist53] and [800-63][nist63] +* OWASP [ASVS][asvs] +* OWASP [Top10][top10ocre] +* OWASP [Proactive Controls][proactiveocre] +* OWASP [Cheat Sheets][csocre] +* OWASP [WSTG][wstgocre] +* [ZAP][zapocre] + +The aim of this project is to 'Link all the things with OpenCRE' which will: + +* make it easier for engineers, security officers, testers and procurement to find relevant information +* make it easier for standards makers to create and maintain references + +#### Why use OpenCRE? + +OpenCRE: 'Everything organized' + +[OpenCRE][opencre] is a powerful tool that can provide developers with links to many resources, and is easy to use. +It provides a one-stop consolidated set of references on various security terms and domains, +and crucially these are automatically kept up to date. +The provides a handy security catalog that can be searched for various standards or security terms. + +As well as being useful for day to day security questions, +the OpenCRE can also be used as the reference section in documentation; +linking across to the OpenCRE rather than providing a list of references means the links are kept up to date automatically. + +#### How to use OpenCRE + +The [OpenCRE][opencre] catalog can be accessed in traditional ways such as using searches or linking across to it. +For example OpenCRE references to the Common Weakness Enumeration can be accessed using the [search facility][cweocre] +or by linking across directly to a [specific Open Common Requirement][cwe1002]. + +OpenCRE is also useful when providing references in documentation. +OpenCRE can be used for these references instead of listing various references to a security concept or requirement. +This will provide links to standards, cheat sheets, tools and other enumerations - +along with other sources that have been added over time - and all kept up to date. +So no more broken links or referring to out of date versions :) + +This is now the age of large language models, and OpenCRE has embraced this technology. +Immediate answers to security questions or searches can be provided by [OpenCRE Chat][opencrechat]. + +For example, in answer to the question "_what use is the OWASP Developer Guide?_" +OpenCRE Chat provides the agreeable answer: + +_"The OWASP Developer Guide provides a comprehensive overview of application security risks and how to mitigate them._ +_It covers topics such as input validation, output encoding, secure coding practices, and secure design principles._ +_The guide is a valuable resource for developers who want to create secure applications."_ + +#### References + +* OWASP [OpenCRE][opencre] +* [Spotlight on OpenCRE][spotlight28] +* OWASP [Application Security Fragmentation][sdlc] +* OWASP [Integration Standards][intstand] project +* [Understanding the Complete Chain of Application Security Using OpenCRE org][opencretalk] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0503] or [edit on GitHub][edit0503]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[capecocre]: https://opencre.org/search/CAPEC +[csocre]: https://opencre.org/search/OWASP%20Cheat%20Sheets +[cweocre]: https://opencre.org/search/CWE +[cwe]: https://cwe.mitre.org/ +[cwe1002]: https://www.opencre.org/node/standard/CWE/sectionid/1002 +[edit0503]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/05-requirements/03-opencre.md +[intstand]: https://owasp.org/www-project-integration-standards/ +[issue0503]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2005-requirements/03-opencre +[nist]: https://csrc.nist.gov/ +[nist53]: https://www.nist.gov/privacy-framework/nist-privacy-framework-and-cybersecurity-framework-nist-special-publication-800-53 +[nist63]: https://pages.nist.gov/800-63-3/ +[opencre]: https://www.opencre.org/ +[opencrechat]: https://www.opencre.org/chatbot +[opencretalk]: https://www.youtube.com/watch?v=VPOkT9quve0 +[proactiveocre]: https://www.opencre.org/search/Proactive%20Controls +[projects]: https://owasp.org/projects/ +[sdlc]: https://owasp.org/www-project-integration-standards/writeups/owasp_in_sdlc/ +[spotlight28]: https://www.youtube.com/watch?v=TwNroVARmB0&list=PLUKo5k_oSrfOTl27gUmk2o-NBKvkTGw0T +[top10ocre]: https://www.opencre.org/search/OWASP%20Top%2010 +[wstgocre]: https://opencre.org/search/WSTG +[zapocre]: https://opencre.org/search/ZAP diff --git a/release-ja/05-requirements/04-security-rat.md b/release-ja/05-requirements/04-security-rat.md new file mode 100644 index 00000000..74836798 --- /dev/null +++ b/release-ja/05-requirements/04-security-rat.md @@ -0,0 +1,125 @@ +--- + +title: SecurityRAT +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 5040 +permalink: /release/requirements/security_rat/ + +--- + +{% include breadcrumb.html %} + +### 3.4 SecurityRAT + +The [OWASP SecurityRAT][srat] (Requirement Automation Tool) is used to generate and manage security requirements +using information from the [OWASP ASVS][asvs] project. +It also provides an automated approach to requirements management +during development of frontend, server and mobile applications. + +At present it is an OWASP Incubator project but it is likely to be upgraded soon to Laboratory status. + +#### What is SecurityRAT? + +SecurityRAT is a companion tool for the [ASVS][asvs] set of requirements; +it can be used to generate an initial set of requirements from the ASVS +and then keep track of the status and updates for these requirements. +It comes with [documentation and instructions][sratdocs] on how to install and run SecurityRAT. + +To generate the initial list of requirements, SecurityRAT needs to be provided with three attributes defined by the ASVS: + +* Application Security Verification Standard chapter ID - for example 'V2 - Authentication' +* Application Security Verification Level - the compliance level, for example 'L2' +* Authentication - whether Single sign-on (SSO) authentication is used or not + +SecurityRAT then generates an initial list of recommended requirements. +This list can be stored in a SecurityRAT database which allows tracking and update of the set of requirements. +SecurityRAT also provides Atlassian JIRA integration for raising and tracking software issues. + +The OWASP Spotlight series provides an overview of what Security Rat can do and how to use it: +'Project 5 - [OWASP SecurityRAT][spotlight05]'. + +#### Why use it? + +At the time of writing the ASVS has more than 280 suggested requirements for secure software development. +This number of requirements takes time to sort through and determine whether +they are applicable to a given development project or not. + +The use of SecurityRAT to create a more manageable subset of the ASVS requirements is a direct benefit to both +security architects and the development team. +In addition SecurityRAT provides for the tracking and update of this set of requirements throughout the development cycle, +adding to the security of the application by helping to ensure security requirements are fulfilled. + +#### How to use SecurityRAT + +Install both Production and Development SecurityRAT applications by +downloading a release and installing on the Java Development Kit JDK11. +Alternatively download and run the [docker image][sratdocker] from DockerHub. +Configure SecurityRAT by referring to the [deployment documentation][sratdeploy]; this is not that straightforward +so to get started there is an [online demonstration][sratdemo] available. + +Logging in to the demonstration site, using the credentials from the [project page][srat], +you are presented with defining a set of requirements or importing an existing set. +Assuming that we want a new set of requirements, give the requirements artifact a name and then +either select specific ASVS sections/chapters from the list: + +* V1 - Architecture, Design and Threat Modeling +* V2 - Authentication +* V3 - Session Management +* V4 - Access Control +* V5 - * Validation, Sanitization and Encoding +* V6 - Stored Cryptography +* V7 - Error Handling and Logging +* V8 - Data Protection +* V9 - Communication +* V10 - Malicious Code +* V11 - Business Logic +* V12 - Files and Resources +* V13 - API and Web Service +* V14 - Configuration + +or leave blank to include all verification requirements. + +Select the level using the ASVS defined security compliance levels: + +* Level 1 is for low assurance levels and is completely penetration testable +* Level 2 is for applications that contain sensitive data and is the recommended level for most applications +* Level 3 is for the most critical applications + +Finally select whether SSO authentication is being used, and generate a list of requirements. +This requirements artifact is now stored in SecurityRAT ad can be retrieved in subsequent sessions. + +SecurityRAT then presents an administration screen which allows tracking and editing of the ASVS verification requirements. +Refer to the [OWASP Spotlight on SecurityRAT][spotlight05] for an explanation of how to integrate with Atlassian JIRA. + +#### What is SecurityCAT? + +[SecurityCAT][scat] (Compliance Automation Tool) is an extension for SecurityRAT meant for automatic testing of requirements. +There is not an actual implementation of SecurityCAT, +SecurityRAT provides an API that allows for a compliance tool to be created. +and so this may be a future development for SecurityRAT. + +#### References + +* OWASP [SecurityRAT][srat] +* OWASP [SecurityRAT documentation][sratdocs] +* OWASP [SecurityCAT][scat] +* OWASP [Application Security Verification Standard][asvs] (ASVS) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0504] or [edit on GitHub][edit0504]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[edit0504]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/05-requirements/04-security-rat.md +[issue0504]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2005-requirements/04-security-rat +[spotlight05]: https://youtu.be/HiaHXtzJ3DE +[scat]: https://securityrat.github.io/int_securitycat.html#securitycat +[srat]: https://owasp.org/www-project-securityrat/ +[sratdemo]: https://securityrat.org/ +[sratdeploy]: https://securityrat.github.io/depl_production.html +[sratdocker]: https://hub.docker.com/r/securityrat/securityrat +[sratdocs]: https://securityrat.github.io/ diff --git a/release-ja/05-requirements/05-asvs.md b/release-ja/05-requirements/05-asvs.md new file mode 100644 index 00000000..9d854fcb --- /dev/null +++ b/release-ja/05-requirements/05-asvs.md @@ -0,0 +1,117 @@ +--- + +title: ASVS requirements +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 5050 +permalink: /release/requirements/asvs/ + +--- + +{% include breadcrumb.html %} + +### 3.5 ASVS requirements + +The [Application Security Verification Standard][asvs] (ASVS) is a long established OWASP flagship project, +and is widely used to suggest security requirements as well as the core verification of web applications. + +It can be downloaded from the [OWASP project page][asvs] in various languages and formats: +PDF, Word, CSV, XML and JSON. Having said that, the recommended way to consume the ASVS is to access +the [github markdown][asvsmd] pages directly - this will ensure that the latest version is used. + +#### What is ASVS? + +The ASVS is an open standard that sets out the coverage and level of rigor expected when it comes to +performing web application security verification. +The standard also provides a basis for testing any technical security controls +that are relied on to protect against vulnerabilities in the application. + +The ASVS is split into various sections: + +* V1 [Architecture, Design and Threat Modeling][asvsV1] +* V2 [Authentication][asvsV2] +* V3 [Session Management][asvsV3] +* V4 [Access Control][asvsV4] +* V5 [Validation, Sanitization and Encoding][asvsV5] +* V6 [Stored Cryptography][asvsV6] +* V7 [Error Handling and Logging][asvsV7] +* V8 [Data Protection][asvsV8] +* V9 [Communication][asvsV9] +* V10 [Malicious Code][asvsV10] +* V11 [Business Logic][asvsV11] +* V12 [Files and Resources][asvsV12] +* V13 [API and Web Service][asvsV13] +* V14 [Configuration][asvsV14] + +The ASVS defines three [levels of security verification][asvsL123]: + +1. applications that only need low assurance levels; these applications are completely penetration testable +2. applications which contain sensitive data that require protection; the recommended level for most applications +3. the most critical applications that require the highest level of trust + +Most applications will aim for Level 2, with only those applications that perform high value transactions, +or contain sensitive medical data, aiming for the highest level of trust at level 3. + +#### Why use it? + +The ASVS is used by many organizations as a basis for the verification of their web applications. +It is well established, the earlier versions were written in 2008, and it has been continually supported since then. +The ASVS is comprehensive, for example version 4.0.3 has a list of 286 verification requirements, +and these verification requirements have been created and agreed to by a wide security community. + +For these reasons the ASVS is a good starting point for creating and updating security requirements for web applications. +The widespread use of this open standard means that development teams and suppliers +may already be familiar with the requirements, leading to easier adoption of the security requirements. + +#### How to use it + +The OWASP Spotlight series provides an overview of the ASVS and its uses: +'Project 19 - [OWASP Application Security Verification standard (ASVS)][spotlight19]'. + +The appropriate level of verification should be chosen from the ASVS levels: + +* Level 1: First steps, automated, or whole of portfolio view +* Level 2: Most applications +* Level 3: High value, high assurance, or high safety + +Tools such as [SecurityRAT][srat] can help create a more manageable subset of the ASVS security requirements, +allowing focus and decisions on whether each one is applicable to the web application or not. + +The OWASP Cheat Sheets have been indexed specifically for [each section of the ASVS][csasvs], +which can be used as documentation to help decide if a requirements category is to be included in the test scheme. + +#### References + +* OWASP [Application Security Verification Standard][asvs] (ASVS) +* OWASP [Cheat Sheets for ASVS][csasvs] +* OWASP [SecurityRAT][srat] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0505] or [edit on GitHub][edit0505]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[asvsL123]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x03-Using-ASVS.md#application-security-verification-levels +[asvsmd]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x00-Header.md +[asvsV1]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x10-V1-Architecture.md#v1-architecture-design-and-threat-modeling +[asvsV2]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x11-V2-Authentication.md#v2-authentication +[asvsV3]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x12-V3-Session-management.md#v3-session-management +[asvsV4]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x12-V4-Access-Control.md#v4-access-control +[asvsV5]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md#v5-validation-sanitization-and-encoding +[asvsV6]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x14-V6-Cryptography.md#v6-stored-cryptography +[asvsV7]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x15-V7-Error-Logging.md#v7-error-handling-and-logging +[asvsV8]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x16-V8-Data-Protection.md#v8-data-protection +[asvsV9]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x17-V9-Communications.md#control-objective +[asvsV10]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x18-V10-Malicious.md#v10-malicious-code +[asvsV11]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x19-V11-BusLogic.md#v11-business-logic +[asvsV12]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x20-V12-Files-Resources.md#v12-files-and-resources +[asvsV13]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x21-V13-API.md#v13-api-and-web-service +[asvsV14]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x22-V14-Config.md#v14-configuration +[csasvs]: https://cheatsheetseries.owasp.org/IndexASVS.html +[edit0505]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/05-requirements/05-asvs.md +[issue0505]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2005-requirements/05-asvs +[spotlight19]: https://youtu.be/3puIavsZfAk +[srat]: https://owasp.org/www-project-securityrat/ diff --git a/release-ja/05-requirements/06-mas.md b/release-ja/05-requirements/06-mas.md new file mode 100644 index 00000000..94244e49 --- /dev/null +++ b/release-ja/05-requirements/06-mas.md @@ -0,0 +1,101 @@ +--- + +title: MAS requirements +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 5060 +permalink: /release/requirements/mas/ + +--- + +{% include breadcrumb.html %} + + + +![MAS logo](../../../assets/images/logos/mas.png "OWASP MAS"){: .image-right } + +### 3.6 MAS requirements + +The OWASP [Mobile Application Security][masproject] (MAS) flagship project provides +industry standards for mobile application security. + +The MAS project covers the processes, techniques, and tools used for security testing mobile applications. +It provides a set of test cases that enables testers to deliver consistent and complete results. +The OWASP MAS project provides both the [Mobile Application Security Verification Standard][masvs] (MASVS) +for mobile applications and the [Mobile Application Security Testing Guide][mastg] (MASTG). + +#### What is MASVS? + +The [OWASP MASVS][mas] is used by mobile software architects and developers to develop secure mobile applications, +as well as security testers to ensure completeness and consistency of test results. +The MAS project has several uses; when it comes to defining requirements then +the MASVS contains a list of security controls for mobile applications. + +The security controls are split into several categories: + +* [MASVS-STORAGE](https://mas.owasp.org/MASVS/05-MASVS-STORAGE/) / [Cheat Sheets][masvs-storage] +* [MASVS-CRYPTO](https://mas.owasp.org/MASVS/06-MASVS-CRYPTO/) / [Cheat Sheets][masvs-crypto] +* [MASVS-AUTH](https://mas.owasp.org/MASVS/07-MASVS-AUTH/) / [Cheat Sheets][masvs-auth] +* [MASVS-NETWORK](https://mas.owasp.org/MASVS/08-MASVS-NETWORK/) / [Cheat Sheets][masvs-network] +* [MASVS-PLATFORM](https://mas.owasp.org/MASVS/09-MASVS-PLATFORM/) / [Cheat Sheets][masvs-platform] +* [MASVS-CODE](https://mas.owasp.org/MASVS/10-MASVS-CODE/) / [Cheat Sheets][masvs-code] +* [MASVS-RESILIENCE](https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/) / [Cheat Sheets][masvs-resilience] +* [MASVS-PRIVACY](https://mas.owasp.org/MASVS/12-MASVS-PRIVACY/) / [Cheat Sheets][masvs-privacy] + +The last category, MASVS-PRIVACY, is being reworked so is subject to change. + +#### Why use MASVS? + +The OWASP MASVS is the industry standard for [mobile application security][csmas] +and it is expected that any given set of security requirements will satisfy the MASVS. +When defining security requirements for mobile applications then each security control in the MASVS should be considered. + +#### How to use MASVS + +MASVS can be [accessed online][masvs] and the links followed for each security control. +In addition MASVS can be downloaded as a PDF which can, for example, be used for evidence or compliance purposes. +Inspect each control within MASVS and regard it as a potential security requirement. + +The OWASP Cheat Sheets have been indexed specifically for [each category of the MASVS][csmasvs], +which can be used as a guide to decide if the category should to be included in the test scheme. + +#### References + +* OWASP [Mobile Application Security][mas] (MAS) +* MAS [project][masproject] +* MAS [Checklist][masc] +* MAS [Verification Standard][masvs] (MASVS) +* OWASP [Mobile Application Security][csmas] cheat sheet + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0506] or [edit on GitHub][edit0506]. + +[csmas]: https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet +[csmasvs]: https://cheatsheetseries.owasp.org/IndexMASVS +[edit0506]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/05-requirements/06-mas.md +[issue0506]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2005-requirements/06-mas +[mas]: https://mas.owasp.org/ +[masc]: https://mas.owasp.org/checklists/ +[masproject]: https://owasp.org/www-project-mobile-app-security/ +[mastg]: https://mas.owasp.org/MASTG/ +[masvs]: https://mas.owasp.org/MASVS/ +[masvs-storage]: https://cheatsheetseries.owasp.org/IndexMASVS.html#masvs-storage +[masvs-crypto]: https://cheatsheetseries.owasp.org/IndexMASVS.html#masvs-crypto +[masvs-auth]: https://cheatsheetseries.owasp.org/IndexMASVS.html#masvs-auth +[masvs-network]: https://cheatsheetseries.owasp.org/IndexMASVS.html#masvs-network +[masvs-platform]: https://cheatsheetseries.owasp.org/IndexMASVS.html#masvs-platform +[masvs-code]: https://cheatsheetseries.owasp.org/IndexMASVS.html#masvs-code +[masvs-resilience]: https://cheatsheetseries.owasp.org/IndexMASVS.html#masvs-resilience +[masvs-privacy]: https://cheatsheetseries.owasp.org/IndexMASVS.html#masvs-privacy diff --git a/release-ja/05-requirements/07-skf.md b/release-ja/05-requirements/07-skf.md new file mode 100644 index 00000000..6a87213c --- /dev/null +++ b/release-ja/05-requirements/07-skf.md @@ -0,0 +1,91 @@ +--- + +title: SKF requirements +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 5070 +permalink: /release/requirements/skf/ + +--- + +{% include breadcrumb.html %} + +### 3.7 SKF requirements + +The [Security Knowledge Framework][skf] (SKF) is an expert system application that uses various open source projects +to support development teams and security architects in building secure applications. +The SKF builds on the OWASP [Application Security Verification Standard][asvs] (ASVS) +to help developers in both pre-development and post-development phases and create applications that are secure by design. + +Having been an OWASP flagship project for many years the SKF is now no longer within the OWASP organization; +and it will continue to be referenced in the OWASP Wayfinder and other OWASP projects +because it is a flagship project for any organization. + +#### What is the Security Knowledge Framework? + +The [SKF][skf] is a web application that is available from the [github repo][skfinstall]. +There is [a demo version][skfdemo] of SKF that is useful for exploring the multiple benefits of the SKF. +Note that SKF is in a process of migrating to a [new repository][skfrepo] so the download link may change. + +The SKF provides training and guidance for application security: + +* Requirements [organizer][skfreqs] +* Learning [courses][skfdemo]: + * Developing Secure Software (LFD121) + * Understanding the OWASP Top 10 Security Threats (SKF100) + * Secure Software Development: Implementation (LFD105x) +* Practice [labs][skflabs] +* Documentation on [installing and using][skfdocs] the SKF + +#### Why use the SKF for requirements? + +The SKF organizes security requirements into various categories that provides a good starting point for application security. + +* API and Web Service +* Access Control +* Architecture Design and Threat Modeling +* Authentication +* Business Logic +* Communication +* Configuration +* Data Protection +* Error Handling and Logging +* Files and Resources +* Malicious Code +* Session Management +* Stored Cryptography +* Validation Sanitization and Encoding + +#### How to use the SKF for requirements + +Visit the [requirements tool website][skfreqs] and select the relevant requirements from the various categories. +Export the selection to the format of your choice (Markdown, spreadsheet CSV or plain text) +and use this as a starting point for the application security requirements. + +The OWASP Spotlight series provides an overview of the SKF: 'Project 7 - [Security Knowledge Framework (SKF)][spotlight07]'. + +#### References + +* [Security Knowledge Framework][skf] (SKF) +* [SKF courses and labs][skfdemo] +* [SKF requirements][skfreqs] +* OWASP [Application Security Verification Standard][asvs] (ASVS) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0507] or [edit on GitHub][edit0507]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[edit0507]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/05-requirements/07-skf.md +[issue0507]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2005-requirements/07-skf +[skf]: https://www.securityknowledgeframework.org/ +[skfdemo]: https://secureby.design/ +[skfdocs]: https://skf.readme.io/docs/introduction +[skfinstall]: https://github.com/blabla1337/skf-flask/releases +[skflabs]: https://secureby.design/labs +[skfrepo]: https://github.com/Security-Knowledge-Framework +[skfreqs]: https://starfish-app-kd3eo.ondigitalocean.app/ +[spotlight07]: https://youtu.be/TFX_ZBy6lNY diff --git a/release-ja/05-requirements/info.md b/release-ja/05-requirements/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/05-requirements/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/05-requirements/toc.md b/release-ja/05-requirements/toc.md new file mode 100644 index 00000000..e9004a39 --- /dev/null +++ b/release-ja/05-requirements/toc.md @@ -0,0 +1,62 @@ +--- + +title: Requirements +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: 5000 +permalink: /release/requirements/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){: .image-right } + +## 3. Requirements + +Security requirements also provide a foundation of vetted security functionality for an application. +Instead of creating a custom approach to security for every application, +standard security requirements allow developers to reuse the definition of security controls and best practices; +those same vetted security requirements provide solutions for security issues that have occurred in the past. + +The importance of understanding key security requirements is described in the [Security Requirements][sammdsr] +practice that is part of the [Design][sammd] business function section within the OWASP [SAMM model][samm]. +Ideally structured software security requirements are available within with a security a requirements framework, +and these are utilized by both developer teams and product teams. +In addition suppliers to the organization must meet security requirements; +build security into supplier agreements in order to ensure compliance with organizational security requirements. + +In summary, security requirements exist to prevent the repeat of past security failures. + +Sections: + +3.1 [Requirements in practice](01-requirements.md) +3.2 [Risk profile](02-risk.md) +3.3 [OpenCRE](03-opencre.md) +3.4 [SecurityRAT](04-security-rat.md) +3.5 [ASVS requirements](05-asvs.md) +3.6 [MAS requirements](06-mas.md) +3.7 [SKF requirements](07-skf.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0500] or [edit on GitHub][edit0500]. + +[edit0500]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/05-requirements/toc.md +[issue0500]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2005-requirements/00-toc +[samm]: https://owaspsamm.org/about/ +[sammd]: https://owaspsamm.org/model/design/ +[sammdsr]: https://owaspsamm.org/model/design/security-requirements/ diff --git a/release-ja/06-design/00-toc.md b/release-ja/06-design/00-toc.md new file mode 100644 index 00000000..704921b0 --- /dev/null +++ b/release-ja/06-design/00-toc.md @@ -0,0 +1,81 @@ +--- + +title: Design +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){height=180px} + +## 4. Design + +Referring to the [Secure Product Design Cheat Sheet][spdcs], the purpose of secure architecture and design is to ensure +that all products meet or exceed the security requirements laid down by the organization, +focusing on the security linked to components and technologies used during the development of the application. + +Secure Architecture Design looks at the selection and composition of components that form the foundation of the solution. +Technology Management looks at the security of supporting technologies used during development, deployment and operations, +such as development stacks and tooling, deployment tooling, and operating systems and tooling. + +A secure design will help establish secure defaults, minimize the attack surface area +and fail securely to well-defined and understood defaults. +It will also consider and follow various principles, such as: + +* Least Privilege and Separation of Duties +* Defense-in-Depth +* Zero Trust +* Security in the Open + +A Secure Development Lifecycle (SDLC) helps to ensure that all security decisions made about the product being developed +are explicit choices and result in the correct level of security for the product design. +Various secure development lifecycles can be used and they generally include threat modeling in the design process. + +Checklists and Cheat Sheets are an important tool during the design process; +they provide an easy reference of knowledge and help avoid repeating design errors and mistakes. + +Software application [Design][sammd] is one of the major business functions described in +the [Software Assurance Maturity Model (SAMM)][samm], and includes security practices: + +* [Threat Assessment][sammdta] +* [Security Requirements][sammdsr] +* [Security Architecture][sammdsa] + +Sections: + +4.1 [Threat modeling](#threat-modeling) +4.1.1 [Threat modeling in practice](#threat-modeling-in-practice) +4.1.2 [pytm](#pytm) +4.1.3 [Threat Dragon](#threat-dragon) +4.1.4 [Cornucopia](#cornucopia) +4.1.5 [LINDDUN GO](#linddun-go) +4.1.6 [Threat Modeling toolkit](#threat-modeling-toolkit) +4.2 [Web application checklist](#web-application-checklist) +4.2.1 [Checklist: Define Security Requirements](#checklist-define-security-requirements) +4.2.2 [Checklist: Leverage Security Frameworks and Libraries](#checklist-leverage-security-frameworks-and-libraries) +4.2.3 [Checklist: Secure Database Access](#checklist-secure-database-access) +4.2.4 [Checklist: Encode and Escape Data](#checklist-encode-and-escape-data) +4.2.5 [Checklist: Validate All Inputs](#checklist-validate-all-inputs) +4.2.6 [Checklist: Implement Digital Identity](#checklist-implement-digital-identity) +4.2.7 [Checklist: Enforce Access Controls](#checklist-enforce-access-controls) +4.2.8 [Checklist: Protect Data Everywhere](#checklist-protect-data-everywhere) +4.2.9 [Checklist: Implement Security Logging and Monitoring](#checklist-implement-security-logging-and-monitoring) +4.2.10 [Checklist: Handle all Errors and Exceptions](#checklist-handle-all-errors-and-exceptions) +4.3 [MAS checklist](#mas-checklist) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0600]. + +[issue0600]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/00-toc +[samm]: https://owaspsamm.org/about/ +[sammd]: https://owaspsamm.org/model/design/ +[sammdsa]: https://owaspsamm.org/model/design/secure-architecture/ +[sammdsr]: https://owaspsamm.org/model/design/security-requirements/ +[sammdta]: https://owaspsamm.org/model/design/threat-assessment/ +[spdcs]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet diff --git a/release-ja/06-design/01-threat-modeling/00-toc.md b/release-ja/06-design/01-threat-modeling/00-toc.md new file mode 100644 index 00000000..e7df8e3a --- /dev/null +++ b/release-ja/06-design/01-threat-modeling/00-toc.md @@ -0,0 +1,45 @@ +--- + +title: Threat Modeling +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 4.1 Threat modeling + +Referring to the [Threat Modeling Cheat Sheet][cstm], +threat modeling is a structured approach to identifying and prioritizing potential threats to a system. +The threat modeling process includes determining the value that potential mitigations would have +in reducing or neutralizing these threats. + +Assessing potential threats during the design phase of your project can save significant resources +if during a later phase of the project refactoring is required to include risk mitigations. +The outcomes from the threat modeling activities generally include: + +* Documenting how data flows through a system to identify where the system might be attacked +* Identifying as many potential threats to the system as possible +* Suggesting security controls that may be put in place to reduce the likelihood or impact of a potential threat + +Sections: + +4.1.1 [Threat modeling in practice](#threat-modeling-in-practice) +4.1.2 [pytm](#pytm) +4.1.3 [Threat Dragon](#threat-dragon) +4.1.4 [Cornucopia](#cornucopia) +4.1.5 [LINDDUN GO](#linddun-go) +4.1.6 [Threat Modeling toolkit](#threat-modeling-toolkit) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0601]. + +[cstm]: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet +[issue0601]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/01-threat-modeling/00-toc diff --git a/release-ja/06-design/01-threat-modeling/01-threat-modeling.md b/release-ja/06-design/01-threat-modeling/01-threat-modeling.md new file mode 100644 index 00000000..c8c9c958 --- /dev/null +++ b/release-ja/06-design/01-threat-modeling/01-threat-modeling.md @@ -0,0 +1,294 @@ +--- + +title: Threat Modeling in Practice +layout: col-document +tags: OWASP Developer Guide +contributors: Adam Shostack, Jon Gadsden +document: OWASP Developer Guide +order: 6110 +permalink: /release/design/threat_modeling/practical_threat_modeling/ + +--- + +{% include breadcrumb.html %} + +### 4.1.1 Threat modeling in practice + +This section discusses Threat Modeling, an activity described in the OWASP Software Assurance Maturity Model ([SAMM][samm]). +Threat modeling is part of the [Threat Assessment][sammdta] security practice in the [Design][sammd] business function. + +Much of the material in this section is drawn from the OWASP [Threat Model project][tmproject], +and the philosophy of this section tries to follow the [Threat Modeling Manifesto][tmmanifesto]. + +![TMM logo](../../../../assets/images/logos/tmmanifesto.png "OWASP TM Manifesto"){: height="60px" } + +#### Overview + +Threat modeling activities try to discover what can go wrong with a system and determine what to do about it. +The deliverables from threat modeling take various forms including system models and diagrams, lists of threats, +mitigations or assumptions, meeting notes, and more. +This may be assembled into a single threat model document; a structured representation of all the information +that affects the security of an application. +A good overview of this activity is given in the [Security Culture][culturetm] project section on threat modeling. + +In essence, it is a view of the application and its environment through security glasses. + +Threat modeling is a process for capturing, organizing, and analyzing all of this information +and enables informed decision-making about application security risk. +In addition to producing a model, typical threat modeling efforts also produce a prioritized list +of _potential_ security vulnerabilities in the concept, requirements, design, or implementation. +Any potential vulnerabilities that have been identified from the model should then be remediated +using one of the common strategies: mitigate, eliminate, transfer or accept the threat of being exploited. + +There are many reasons for doing threat modeling but the most important one is that this activity is _useful_ , +it is probably the only stage in a development lifecycle where a team sits back and asks: 'What can go wrong?'. + +There are other reasons for threat modeling, for example standards compliance or analysis for disaster recovery, +but the main aim of threat modeling is to remedy (possible) vulnerabilities before the malicious actors can exploit them. + +#### What is threat modeling + +Threat modeling works to identify, communicate, and understand threats and mitigations +within the context of protecting something of value. + +Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, +distributed systems, things in the Internet of things, business processes, etc. +There are very few technical products which cannot be threat modeled; +more or less rewarding, depending on how much it communicates, or interacts, with the world. + +A threat model document is a record of the threat modeling process, and often includes: + +* a description / design / model of what you’re worried about +* a list of assumptions that can be checked or challenged in the future as the threat landscape changes +* potential threats to the system +* remediation / actions to be taken for each threat +* ways of validating the model and threats, and verification of success of actions taken + +The threat model should be in a form that can be easily revised and modified +during subsequent threat modeling discussions. + +#### Why do it + +Like all engineering activities, effort spent on threat modeling has to be justifiable. +Rarely any project or development has engineering effort that is going 'spare', +and the benefits of threat modeling have to outweigh the engineering cost of this activity. +Usually this is difficult to quantify; an easier way to approach it may be to ask +what are the costs of _not_ doing threat modeling? +These costs may consist of a lack of compliance, an increased risk of being exploited, harm to reputation and so on. + +The inclusion of threat modeling in the secure development activities can help: + +* Build a secure design +* Efficient investment of resources; appropriately prioritize security, development, and other tasks +* Bring Security and Development together to collaborate on a shared understanding, informing development of the system +* Identify threats and compliance requirements, and evaluate their risk +* Define and build required controls. +* Balance risks, controls, and usability +* Identify where building a control is unnecessary, based on acceptable risk +* Document threats and mitigation +* Ensure business requirements (or goals) are adequately protected in the face of + a malicious actor, accidents, or other causes of impact +* Identification of security test cases / security test scenarios to test the security requirements + +Threat modeling also provides a clear 'line of sight' across a project that can be used +to justify other security efforts. +The threat model allows security decisions to be made rationally, with all the information available, +so that security decisions can be properly supported. +The threat modeling process naturally produces an assurance argument that can be used to explain +and defend the security of an application. +An assurance argument starts with a few high level claims and then justifies them with either sub-claims or evidence. + +#### When to threat model + +There is no wrong time to do threat modeling; +the earlier it is done in the development lifecycle the more beneficial it is, +but it threat modeling is also useful at any time during application development. + +Threat modeling is best applied continuously throughout a software development project. +The process is essentially the same at different levels of abstraction, +although the information gets more and more granular throughout the development lifecycle. +Ideally, a high-level threat model should be defined in the concept or planning phase, +and then refined during the development phases. +As more details are added to the system new attack vectors are identified, +so the ongoing threat modeling process should examine, diagnose, and address these threats. + +Note that it is a natural part of refining a system for new threats to be exposed. +When you select a particular technology, such as Java for example, +you take on the responsibility to identify the new threats that are created by that choice. +Even implementation choices such as using regular expressions for validation +introduce potential new threats to deal with. + +Threat modeling: _the sooner the better, but never too late_ + +#### Questions to ask + +Often threat modeling is a conceptual activity rather than a rigorous process, +where development teams are brought together and asked to think up ways of subverting their system. +To provide some structure it is useful to start with Shostack's [Four Question Framework][4QFW]: + +**1 What are we working on**? + +As a starting point the scope of the Threat Model should be defined. +This will require an understanding of the application that is being built, +and some examples of inputs for the threat model could be: + +* Architecture diagrams +* Dataflow transitions +* Data classifications + +It is common to represent the answers to this question with one or more data flow diagrams +and often supplemental diagrams like message sequence diagrams. + +It is best to gather people from different roles with sufficient technical and risk awareness +so that they can agree on the framework to be used during the threat modeling exercise. + +**2 What can go wrong**? + +This is a research activity to find the main threats that apply to your application. +There are many ways to approach the question, including open discussion or using a structure to help think it through. +Techniques and methodologies to consider include CIA, [STRIDE][stride], [LINDDUN][linddun], +[cyber kill chains][chains], [PASTA][pasta], common attack patterns ([CAPEC][capec]) and others. + +There are resources available that will help with identifying threats and vulnerabilities. +OWASP provide a set of cards, [Cornucopia][corncards], that provide suggestions and explanations for general vulnerabilities. +The game [Elevation of Privileges][eop] threat modeling card game is an easy way to get started with threat modeling, +and there is the OWASP version of [Snakes and Ladders][snakes] that truly gamifies these activities. + +**3 What are we going to do about that**? + +In this phase turn the threat model findings into specific actions. +Consider the appropriate remediation for each threat identified: Transfer, Avoid, Mitigate or Eliminate. + +**4 Did we do a good enough job**? + +Finally, carry out a retrospective activity over the work identified to check +quality, feasibility, progress, or planning. + +The OWASP [Threat Modeling Playbook][tmpb] goes into these practicalities in more detail +and provides strategies for maintaining threat modeling within an organization. + +#### How to do it + +There is no one process for threat modeling. +How it is done in practice will vary according to the organization's culture, +according to what type of system / application is being modeled +and according to preferences of the development team itself. +The various techniques and concepts are discussed in the [Threat Modeling Cheat Sheet][cstm] +and can be summarized: + +1. Terminology: try to use standard terms such as actors, trust boundaries, etc as this will help convey these concepts +2. Scope: be clear what is being modeled and keep within this scope +3. Document: decide which tools and what outputs are required to satisfy compliance, for example +4. Decompose: break the system being modeled into manageable pieces +5. Trust: identify your trust boundaries, consider [network segmentation][ccsnet] +6. Agents: identify who the actors are (malicious or otherwise) and what they can do +7. Categorize: prioritize the threats taking into account probability, impact and any other factors +8. Remediation: be sure to decide what to do about any threats identified, the whole reason for threat modeling + +It is worth saying this again: there are many ways to do threat modeling, +all perfectly valid, so choose the right process that works for a specific team. + +#### Final advice + +Some final words on threat modeling. + +**Make it incremental**: + +Strongly consider using [incremental threat modeling][sammgata]. +It is almost certainly a bad idea trying to fully model an existing application or system; +it can be very time consuming modeling a whole system, +and by the time such a model was completed then it would probably be out of date. +Instead incrementally model new features or enhancements as and when they are being developed. + +Incremental threat modeling assumes that existing applications and features +have already been attacked over time and these real world vulnerabilities have been remediated. +It is the new features or new applications that pose a greater security risk; +if they are vulnerable then they will reduce the security of the existing application or system. +Concentrating on the new changes applies threat modeling effort at the place that it is needed most; +at the very least the changes should not make the security worse - and ideally the security should be better. + +**Tools are secondary**: + +It is good to standardize threat modeling tools across an organization, +but also allow teams to choose how they record their threat models. +If one team decides to use Threat Dragon, for example, and another wants to use a drawing board, +then that is usually fine. +The discussions had during the threat modeling process are more important than the tool used, +although you might ask the team using the drawing board how they implement change control for their models. + +**Brevity is paramount**: + +It is very easy to create a threat model that looks a lot like a system diagram, with many components and data flows. +This makes for a convincing diagram, but it is not a model specific to the threat of exploits. +Instead concentrate on the attack / threat surfaces and be robust in consolidating multiple system components +into one threat model component. +This will keep the number of components and dataflows manageable, and focuses the discussion on what matters most: +malicious actors (external or internal) trying to subvert your system. + +**Choose your methodology**: + +It is a good strategy to choose a threat categorization methodology for the whole organization +and then try and keep to it. +For example this could be [STRIDE][stride] or [LINDDUN][linddun], but if the CIA triad provides enough granularity +then that is also a perfectly good choice. + +#### Further reading + +* [Threat Modeling Manifesto][tmmanifesto] +* OWASP [Threat Model project][tmproject] +* OWASP [Threat Modeling Cheat Sheet][cstm] +* OWASP [Threat Modeling Playbook (OTMP)][tmpb] +* OWASP [Attack Surface Analysis Cheat Sheet][asacs] +* OWASP community pages on [Threat Modeling][TM] and the [Threat Modeling Process][TMP] +* [The Four Question Framework For Threat Modeling](https://youtu.be/Yt0PhyEdZXU) 60 second video +* Lockheed's [Cyber Kill Chain][chains] +* VerSprite's Process for Attack Simulation and Threat Analysis ([PASTA][pasta]) +* [Threat Modeling: Designing for Security][TMdesigning] +* [Threat Modeling: A Practical Guide for Development Teams][TMpractical] + +#### Resources + +* Shostack's [Four Question Framework][4QFW] +* OWASP [pytm][PYTM] Pythonic Threat Modeling tool +* OWASP [Threat Dragon][tdtm] threat modeling tool using dataflow diagrams +* [Threagile](https://threagile.io), an open source project that provides for Agile threat modeling +* Microsoft [Threat Modeling Tool][TMT], a widely used tool throughout the security community and free to download +* [threatspec](https://github.com/threatspec/threatspec), an open source tool based on comments inline with code +* MITRE's Common Attack Pattern Enumeration and Classification ([CAPEC][capec]) +* NIST [Common Vulnerability Scoring System Calculator][nist-cvss] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060101] or [edit on GitHub][edit060101]. + +[4QFW]: https://github.com/adamshostack/4QuestionFrame +[asacs]: https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet +[capec]: https://capec.mitre.org/ +[chains]: https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html +[corncards]: https://owasp.org/www-project-cornucopia/ +[ccsnet]: https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet +[cstm]: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet +[culturetm]: https://owasp.org/www-project-security-culture/stable/6-Threat_Modelling/ +[eop]: https://shostack.org/games/elevation-of-privilege +[edit060101]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/01-threat-modeling/01-threat-modeling.md +[issue060101]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/01-threat-modeling/01-threat-modeling +[linddun]: https://linddun.org/ +[nist-cvss]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[pasta]: https://versprite.com/blog/what-is-pasta-threat-modeling/ +[PYTM]: https://owasp.org/www-project-pytm/ +[samm]: https://owaspsamm.org/about/ +[sammd]: https://owaspsamm.org/model/design/ +[sammdta]: https://owaspsamm.org/model/design/threat-assessment/ +[sammgata]: https://owaspsamm.org/guidance/agile/#TA +[snakes]: https://owasp.org/www-project-snakes-and-ladders/ +[stride]: https://en.wikipedia.org/wiki/STRIDE_%28security%29 +[tdtm]: https://owasp.org/www-project-threat-dragon/ +[tmpb]: https://owasp.org/www-project-threat-modeling-playbook/ +[tmproject]: https://owasp.org/www-project-threat-model/ +[tmmanifesto]: https://www.threatmodelingmanifesto.org/ +[TM]: https://owasp.org/www-community/Threat_Modeling +[TMP]: https://owasp.org/www-community/Threat_Modeling_Process +[TMdesigning]: https://shostack.org/books/threat-modeling-book +[TMpractical]: https://threatmodeling.dev/ +[TMT]: https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool diff --git a/release-ja/06-design/01-threat-modeling/02-pytm.md b/release-ja/06-design/01-threat-modeling/02-pytm.md new file mode 100644 index 00000000..567a0899 --- /dev/null +++ b/release-ja/06-design/01-threat-modeling/02-pytm.md @@ -0,0 +1,131 @@ +--- + +title: Pythonic Threat Modeling +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 6120 +permalink: /release/design/threat_modeling/pytm/ + +--- + +{% include breadcrumb.html %} + + + +![pytm logo](../../../../assets/images/logos/pytm.png "OWASP pytm"){: .image-right } + +### 4.1.2 pytm + +The OWASP [pytm (Pythonic Threat Modeling)][pytmproject] project is a framework for threat modeling and its automation. +The goal of pytm is to shift threat modeling to the left, making threat modeling more automated and developer-centric. + +Pytm is an OWASP Lab Project with a community of contributors creating [regular releases][pytmreleases]. + +#### What is pytm? + +Pytm is a Java library that provides programmatic way of threat modeling; +the application model itself is defined as a python3 source file and follows Python program syntax. +Findings are included in the application model python program with threats defined as rows in an associated text file. +The threat file can be reused between projects and provides for accumulation of a knowledge base. + +Using pytm the model and threats can be programmatically output as a [dot][graphvizdot] data flow diagram +which is displayed using [Graphviz][graphviz], an open source graph visualization software utility. +Alternatively the model and threats can be output as a [PlantUML][plantuml] file which can then be displayed, +using Java and the PlantUML `.jar`, as a sequence diagram. + +If a report document is required then a pytm script can output the model, threats and findings as markdown. +Programs such as [pandoc][pandoc] can then take this markdown file +and provide the document in various formats such as PDF, ePub or html. + +The OWASP Spotlight series provides an overview of pytm: 'Project 6 - [OWASP pytm][spotlight06]'. + +#### Why use pytm? + +The pytm development team make the good point that traditional threat modeling often comes too late +in the development process, and sometimes may not happen at all. +In addition, creating manual / diagrammatic data flows and reports can be extremely time-consuming. +These are certainly valid observations, +and so pytm attempts to get threat modeling to 'shift-left' in the development lifecycle. + +Many traditional threat modeling tools such as OWASP Threat Dragon provide +a graphical way of creating diagrams and entering threats. +These applications store the models as text, for example JSON and YAML, but the main entry method is via the application. + +Pytm is different - the primary method of creating and updating the threat models is through code. +This source code completely defines the model along with its findings, threats and remediations. +Diagrams and reports are regarded as outputs of the model; not the inputs to the model. +This makes pytm a powerful tool for describing a system or application, and allows the model to be built up over time. + +This focus on the model as code and programmatic outputs makes Pytm particularly useful in automated environments, +helping the threat model to be built in to the design process from the start, +as well as in more traditional threat modeling sessions. + +#### How to use pytm + +The best description of how to use pytm is given in chapter 4 of the book +[Threat Modeling: a practical guide for development teams][TMchap4] +which is written by two of the main contributors to the pytm project. + +Pytm is code based within a program environment, rather than run as a single application, +so there are various components that have to be installed on the target machine to allow pytm to run. +At present it does not work on Windows, only Linux or MacOS, so if you need to run Windows then use a Linux VM +or follow the instructions to create a Docker container. + +The following tools and libraries need to be installed: + +* Python 3.x +* [Graphviz][graphvizdot] package +* Java, such as OpenJDK 10 or 11 +* the [PlantUML][plantumljar] executable JAR file +* and of course pytm itself: clone the [pytm project repo][pytmrepo] + +Once the environment is installed then navigate to the top directory of your local copy of the project. + +Follow [the example][pytmexample] given by the pytm project repo and run the suggested scripts +to output the data flow diagram, sequence diagram and report: + +```text +mkdir -p tm +./tm.py --report docs/basic_template.md | pandoc -f markdown -t html > tm/report.html +./tm.py --dfd | dot -Tpng -o tm/dfd.png +./tm.py --seq | java -Djava.awt.headless=true -jar $PLANTUML_PATH -tpng -pipe > tm/seq.png +``` + +#### References + +* OWASP [Pythonic Threat Modeling][pytmproject] (pytm) +* [Graphviz][graphviz] +* [pandoc][pandoc] +* [PlantUML][plantuml] +* [pytm][pytmrepo] repository +* [Spotlight][spotlight06] on pytm +* [Threat Modeling: a practical guide for development teams][TMchap4] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060102] or [edit on GitHub][edit060102]. + +[graphviz]: https://graphviz.org/ +[graphvizdot]: https://graphviz.org/download/ +[issue060102]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/01-threat-modeling/02-pytm +[pandoc]: https://pandoc.org/installing.html +[plantuml]: https://plantuml.com/ +[plantumljar]: https://plantuml.com/download +[edit060102]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/01-threat-modeling/02-pytm.md +[pytmrepo]: https://github.com/OWASP/pytm/ +[pytmproject]: https://owasp.org/www-project-pytm/ +[pytmexample]:https://github.com/OWASP/pytm/blob/master/tm.py +[pytmreleases]:https://github.com/OWASP/pytm/releases +[spotlight06]: https://youtu.be/oTqkPaEbTnE +[TMchap4]: https://www.oreilly.com/library/view/threat-modeling/9781492056546/ch04.html diff --git a/release-ja/06-design/01-threat-modeling/03-threat-dragon.md b/release-ja/06-design/01-threat-modeling/03-threat-dragon.md new file mode 100644 index 00000000..35c673d9 --- /dev/null +++ b/release-ja/06-design/01-threat-modeling/03-threat-dragon.md @@ -0,0 +1,99 @@ +--- + +title: Threat Dragon +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 6130 +permalink: /release/design/threat_modeling/threat_dragon/ + +--- + +{% include breadcrumb.html %} + + + +![Threat dragon logo](../../../../assets/images/logos/threat_dragon.png "OWASP Threat Dragon"){: .image-right } + +### 4.1.3 Threat Dragon + +The OWASP [Threat Dragon][tdtm] project provides a diagrammatic tool for threat modeling +applications, APIs and software systems. +It is an OWASP Lab Project with [several releases][tddownload] and is in active development. + +#### What is Threat Dragon? + +Threat Dragon is a tool that can help development teams with their threat modeling process. +It provides for creating and modifying data flow diagrams which provide the +context and direction for the threat modeling activities. +It also stores the details of threats identified during the threat modeling sessions, +and these are stored alongside the threat model diagram in a text-based file. +Threat Dragon can also output the threat model diagram and the associated threats as a PDF report. + +#### Why use it? + +Threat Dragon is a useful tool for small teams to create threat models quickly and easily. +Threat Dragon aims for: + +* Simplicity - you can install and start using Threat Dragon very quickly +* Flexibility - the diagramming and threat generation allows all types of threat to be described +* Accessibility - various different types of teams can all benefit from Threat Dragon ease of use + +It supports various methodologies and threat categorizations used during the threat modeling activities: + +* STRIDE +* LINDDUN +* PLOT4ai +* CIA +* DIE + +and it can be used by all sorts of development teams. + +#### How to use it + +The OWASP Spotlight series provides an overview of Threat Dragon and how to use it: +'Project 22 - [OWASP Threat Dragon][spotlight22]'. + +It is straightforward to start using Threat Dragon; the latest version is [available to use online][tddemo]: + +1. select 'Login to Local Session' +2. select 'Explore a Sample Threat Model' +3. select 'Version 2 Demo Model' +4. you are then presented with the threat model meta-data which can be edited +5. click on the diagram 'Main Request Data Flow' to display the data flow diagram +6. the diagram components can be inspected, and their associated threats are displayed +7. components can be added and deleted, along with editing their properties + +Threat Dragon is distributed as a cross platform desktop application as well a web application. +The [desktop application][tddownload] can be downloaded for Windows, Linux and MacOS. +The web application can be run using a [Docker container][tddocker] or from the [source code][tdcode]. + +An important feature of Threat Dragon is the PDF report output which can be used for documentation +and GRC compliance purposes; from the threat model meta-data window click on the Report button. + +#### References + +* OWASP [Threat Dragon][tdtm] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060103] or [edit on GitHub][edit060103]. + +[issue060103]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/01-threat-modeling/03-threat-dragon +[edit060103]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/01-threat-modeling/03-threat-dragon.md +[tddemo]: https://www.threatdragon.com/#/ +[tdcode]: https://github.com/OWASP/threat-dragon +[tddocker]: https://hub.docker.com/r/owasp/threat-dragon/tags +[tddownload]: https://github.com/OWASP/threat-dragon/releases +[tdtm]: https://owasp.org/www-project-threat-dragon/ +[spotlight22]: https://youtu.be/hUOAoc6QGJo diff --git a/release-ja/06-design/01-threat-modeling/04-cornucopia.md b/release-ja/06-design/01-threat-modeling/04-cornucopia.md new file mode 100644 index 00000000..8cfc75db --- /dev/null +++ b/release-ja/06-design/01-threat-modeling/04-cornucopia.md @@ -0,0 +1,160 @@ +--- + +title: Cornucopia +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 6140 +permalink: /release/design/threat_modeling/cornucopia/ + +--- + +{% include breadcrumb.html %} + + + +![Cornucopia logo](../../../../assets/images/logos/cornucopia.png "OWASP Cornucopia"){: .image-right } + +### 4.1.4 Cornucopia + +OWASP Cornucopia is a card game used to help derive application security requirements +during the software development life cycle. +[Cornucopia][cornucopia] is an OWASP Lab project, and can be [downloaded][cornucopia-cards] from its project page. + +#### What is Cornucopia? + +Cornucopia provides a [set of cards][cornucopia-cards] designed to gamify threat modeling activities, +helping agile development teams to identify weaknesses in applications and then record remediations or requirements. + +There are three versions of the Cornucopia deck of threat modeling cards: + +* Website App Edition +* Mobile App Edition +* Enterprise App Edition + +The decks come with several suits according to the application, and always contain an overall 'Cornucopia' suit. + +Cornucopia can be played in many different ways, there is no one way, +and there is a suggested [set of rules][cornucopia-play] to start the game off. +Cornucopia provides a [score sheet][cornucopia-score] to can help keep track of the game session and to record outcomes. + +#### Website App Edition + +Each card in the Website App deck describes a common error or anti-pattern that allows systems to be vulnerable to attack. +Vulnerabilities are arranged in domains as five suits with the additional Cornucopia suit ranging across these domains: + +* Data Validation and Encoding +* Authentication +* Session Management +* Authorization +* Cryptography +* Cornucopia + +To provide context the Cornucopia Website App cards reference other projects: + +* OWASP Application Security Verification Standard ([ASVS][asvs]) +* OWASP Secure Coding Practices ([SCP][scp-v21]]) quick reference guide +* OWASP [AppSensor][appsensor] +* MITRE's Common Attack Pattern Enumeration and Classification ([CAPEC][capec]) +* [SAFEcode][safecode] + +The SCP quick reference guide has now been incorporated as part of this [Developer Guide](../02-web-app-checklist/toc.md). + +#### Mobile App Edition + +Similarly to the website application deck, the mobile application deck has five domains/suits, +with Cornucopia cross domain: + +* Platform and Code +* Authentication and Authorization +* Network and Storage +* Resilience +* Cryptography +* Cornucopia + +For context the Cornucopia Mobile App cards reference these other projects: + +* OWASP Mobile Application Security Verification Standard ([MASVS][masvs]) +* OWASP Mobile Application Security Testing Guide ([MASTG][mastg]) +* MITRE's Common Attack Pattern Enumeration and Classification ([CAPEC][capec]) +* [SAFEcode][safecode] + +#### Ecommerce Website Edition + +This is the original Cornucopia deck and has the same domains/suits, including the Cornucopia cross domain suit, +as the Website App Edition. Some of the vulnerabilities are specific to Ecommerce, +but it references the same projects as the website edition. + +#### Why use it? + +Cornucopia is useful for both requirements analysis and threat modeling, +providing gamification of these activities within the development lifecycle. +It is targeted towards agile development teams and provides a different perspective to these tasks. + +The outcome of the game is to identify possible threats and propose remediations. + +#### How to use Cornucopia + +The OWASP Spotlight series provides an excellent overview of Cornucopia and how it can be used for gamification: +'Project 16 - [Cornucopia][spotlight16]'. + +Ideally Cornucopia is played in person using physical cards, +with the development team and security architects in the same room. +The application should already have been described by an architecture diagram or data flow diagram +so that the players have something to refer to during the game. + +The suggested order of play is: + +1. Pre-sort: the deck, some cards may not be relevant for the web application +2. Deal: the cards equally to the players +3. Play: the players take turns to select a card +4. Describe: the player describes the possible attack using the card played +5. Convince: the other players have to be convinced that the attack is valid +6. Score: award points for a successful attack +7. Follow suit: the next player has to select a card from the same suit +8. Winner: the player with the most points +9. Follow up: each valid threat should be recorded and acted upon + +Remember that the outcome of the game is to identify possible threats and propose remediations, +as well as having a good time. + +#### References + +* [AppSensor][appsensor] +* Application Security Verification Standard, [ASVS][asvs] +* Common Attack Pattern Enumeration and Classification, [CAPEC][capec] +* [Cornucopia][cornucopia] +* Mobile Application Security Verification Standard, [MASVS][masvs]) +* Mobile Application Security Testing Guide, [MASTG][mastg]) +* [Secure Coding Practices][scp-v21] quick reference guide +* [SAFEcode][safecode] +* [Spotlight][spotlight16] on Cornucopia + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060104] or [edit on GitHub][edit060104]. + +[appsensor]: https://owasp.org/www-project-appsensor/ +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[capec]: https://capec.mitre.org/ +[cornucopia]: https://owasp.org/www-project-cornucopia/ +[cornucopia-cards]: https://owasp.org/www-project-cornucopia#div-cards +[cornucopia-score]: https://owasp.org/www-project-cornucopia/assets/files/Cornucopia-scoresheet.pdf +[cornucopia-play]: https://owasp.org/www-project-cornucopia#div-play +[edit060104]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/01-threat-modeling/04-cornucopia.md +[issue060104]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2006-design/01-threat-modeling/04-cornucopia +[mastg]: https://mas.owasp.org/MASTG/ +[masvs]: https://mas.owasp.org/MASVS/ +[safecode]: https://safecode.org/ +[scp-v21]: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/assets/docs/OWASP_SCP_Quick_Reference_Guide_v21.pdf +[spotlight16]: https://youtu.be/NesxjEGX58s diff --git a/release-ja/06-design/01-threat-modeling/05-linddun-go.md b/release-ja/06-design/01-threat-modeling/05-linddun-go.md new file mode 100644 index 00000000..4e764345 --- /dev/null +++ b/release-ja/06-design/01-threat-modeling/05-linddun-go.md @@ -0,0 +1,80 @@ +--- + +title: LINDDUN GO +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 6150 +permalink: /release/design/threat_modeling/linddun_go/ + +--- + +{% include breadcrumb.html %} + +### 4.1.5 LINDDUN GO + +LINNDUN GO is a card game used to help derive privacy requirements during the software development life cycle. +The LINNDUN GO card set can be [downloaded][linddun-go-cards] as a PDF and then printed out. + +#### What is LINDDUN GO? + +[LINDDUN GO][linddun-go] helps identify potential privacy threats based on the key LINDDUN threats to privacy: + +* Linking +* Identifying +* Non-repudiation +* Detecting +* Data Disclosure +* Unawareness +* Non-compliance + +LINNDUN GO is similar to OWASP [Cornucopia][cornucopia] in that it takes the form of a set of cards that +can be used to gamify the process of identifying application privacy / security requirements. +The deck of 33 cards are arranged in suits that match each category of threats to privacy, +and there is a [set of rules][linddun-go-rules] to structure the game sessions. +Each LINDDUN GO card illustrates a single common privacy threat and suggested remediations. + +#### Why use it? + +[LINDDUN][linddun] is an approach to threat modeling from a privacy perspective. +It is a methodology that is useful to structure and guide the identification of threats to privacy, +and also helps with suggestions for the mitigation of any threats. + +[LINDDUN GO][linddun-go] gamifies this approach to privacy with a set of cards and rules +to guide the identification process for threats to the privacy provided by the application. +This is a change to other established processes and provides a different and useful perspective to the system. + +#### How to use LINDDUN GO + +The idea for a LINDDUN GO is that it is played in person by a diverse team with as varied a set of viewpoints as possible. +The advice from the LINDDUN GO 'getting started' instructions is that this team contains some or all of: + +* domain experts +* system architects +* developers +* the Data Protection Officer (DPO) +* legal experts +* the Chief Information Security Officer (CISO) +* privacy champions + +The application should have already been described by an architecture diagram or data flow diagram +so that the players have something to refer to during the game. +[Download][linddun-go-cards] and printout the deck of cards. + +Follow the [set of rules][linddun-go-rules] to structure the game session, record the outcome and act on it. +The outcome of the game is to identify possible privacy threats and propose remediations; +as well as having a good time of course. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060105] or [edit on GitHub][edit060105]. + +[cornucopia]: https://owasp.org/www-project-cornucopia/ +[edit060105]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/01-threat-modeling/05-linddun-go.md +[issue060105]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2006-design/01-threat-modeling/05-linddun-go +[linddun]: https://linddun.org/ +[linddun-go]: https://linddun.org/go/ +[linddun-go-cards]: https://downloads.linddun.org/linddun-go/default/latest/go.pdf +[linddun-go-rules]: https://linddun.org/go-getting-started/ diff --git a/release-ja/06-design/01-threat-modeling/06-toolkit.md b/release-ja/06-design/01-threat-modeling/06-toolkit.md new file mode 100644 index 00000000..dc98db86 --- /dev/null +++ b/release-ja/06-design/01-threat-modeling/06-toolkit.md @@ -0,0 +1,73 @@ +--- + +title: Threat Modeling Toolkit +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 6160 +permalink: /release/design/threat_modeling/toolkit/ + +--- + +{% include breadcrumb.html %} + +### 4.1.6 Threat Modeling toolkit + +There is no one technique or tool that fits every threat modeling process. +The process can be tactical or architectural, subjective or automated, attack tree or data flow diagram, +all are perfectly valid for different organizations, teams and situations. + +The OWASP [Threat Modeling toolkit][toolkit] presentation at OWASP AppSec California 2018 gives a good +overview of the range of concepts and techniques that can be regarded as threat modeling. + +#### Advice on Threat Modeling + +In addition to the Threat Modeling toolkit there are OWASP community pages on [Threat Modeling][TM] +and the OWASP [Threat Modeling Project][tmproject], +both of which provide context and overviews of threat modeling - in particular Shostack's [Four Question Framework][4QFW]. + +#### Threat Modeling step by step + +The [Threat Modeling Process][TMP] suggests steps that should be taken when threat modeling: + +1. Decompose the Application +2. Determine and Rank Threats +3. Determine Countermeasures and Mitigation + +and goes into detail on each concept : + +* External Dependencies +* Entry Points +* Exit Points +* Assets +* Trust Levels +* Threat Categorization +* Threat Analysis +* Ranking of Threats +* Remediation for threats / vulnerabilities + +The OWASP [Threat Modeling Playbook][tmpb] (OTMP) is an OWASP Incubator project that describes how to +create and nurture a good threat modeling culture within the organization itself. + +#### Cheat Sheets for Threat Modeling + +The OWASP series of Cheat Sheets is a primary source of advice and techniques on all things security, +with the OWASP [Threat Modeling Cheat Sheet][cstm] and OWASP [Attack Surface Analysis Cheat Sheet][asacs] +providing practical suggestions along with explanations of both the terminology and the concepts involved. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060106] or [edit on GitHub][edit060106]. + +[4QFW]: https://github.com/adamshostack/4QuestionFrame +[asacs]: https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet +[cstm]: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet +[issue060106]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2006-design/01-threat-modeling/06-toolkit +[edit060106]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/01-threat-modeling/06-toolkit.md +[toolkit]: https://www.youtube.com/watch?v=KGy_KCRUGd4 +[tmpb]: https://owasp.org/www-project-threat-modeling-playbook/ +[tmproject]: https://owasp.org/www-project-threat-model/ +[TM]: https://owasp.org/www-community/Threat_Modeling +[TMP]: https://owasp.org/www-community/Threat_Modeling_Process diff --git a/release-ja/06-design/01-threat-modeling/info.md b/release-ja/06-design/01-threat-modeling/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/06-design/01-threat-modeling/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/06-design/01-threat-modeling/toc.md b/release-ja/06-design/01-threat-modeling/toc.md new file mode 100644 index 00000000..b60b34f6 --- /dev/null +++ b/release-ja/06-design/01-threat-modeling/toc.md @@ -0,0 +1,58 @@ +--- + +title: Threat Modeling +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 6100 +permalink: /release/design/threat_modeling/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 4.1 Threat modeling + +Referring to the [Threat Modeling Cheat Sheet][cstm], +threat modeling is a structured approach to identifying and prioritizing potential threats to a system. +The threat modeling process includes determining the value that potential mitigations would have +in reducing or neutralizing these threats. + +Assessing potential threats during the design phase of your project can save significant resources +if during a later phase of the project refactoring is required to include risk mitigations. +The outcomes from the threat modeling activities generally include: + +* Documenting how data flows through a system to identify where the system might be attacked +* Identifying as many potential threats to the system as possible +* Suggesting security controls that may be put in place to reduce the likelihood or impact of a potential threat + +Sections: + +4.1.1 [Threat modeling in practice](01-threat-modeling.md) +4.1.2 [pytm](02-pytm.md) +4.1.3 [Threat Dragon](03-threat-dragon.md) +4.1.4 [Cornucopia](04-cornucopia.md) +4.1.5 [LINDDUN GO](05-linddun-go.md) +4.1.6 [Threat Modeling toolkit](06-toolkit.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0601] or [edit on GitHub][edit0601]. + +[edit0601]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/01-threat-modeling/toc.md +[issue0601]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/01-threat-modeling/00-toc +[cstm]: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet diff --git a/release-ja/06-design/02-web-app-checklist/00-toc.md b/release-ja/06-design/02-web-app-checklist/00-toc.md new file mode 100644 index 00000000..c7589569 --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/00-toc.md @@ -0,0 +1,50 @@ +--- + +title: Web Application Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 4.2 Web application checklist + +Checklists are a valuable resource for development teams. +They provide structure for establishing good practices and processes +and are also useful during code reviews and design activities. + +The checklists that follow are general lists that are categorized to follow the controls listed in the +[OWASP Top 10 Proactive Controls][proactive10] project. +These checklists provide suggestions that certainly should be tailored to +an individual project's requirements and environment; they are not meant to be followed in their entirety. + +Probably the best starting point for a checklist is given by the [Application Security Verification Standard (ASVS)][asvs]. +The ASVS can be used to provide a framework for an initial checklist, according to the security verification level, +and this initial ASVS checklist can then be expanded using the following checklist sections. + +Sections: + +4.2.1 [Checklist: Define Security Requirements](#checklist-define-security-requirements) +4.2.2 [Checklist: Leverage Security Frameworks and Libraries](#checklist-leverage-security-frameworks-and-libraries) +4.2.3 [Checklist: Secure Database Access](#checklist-secure-database-access) +4.2.4 [Checklist: Encode and Escape Data](#checklist-encode-and-escape-data) +4.2.5 [Checklist: Validate All Inputs](#checklist-validate-all-inputs) +4.2.6 [Checklist: Implement Digital Identity](#checklist-implement-digital-identity) +4.2.7 [Checklist: Enforce Access Controls](#checklist-enforce-access-controls) +4.2.8 [Checklist: Protect Data Everywhere](#checklist-protect-data-everywhere) +4.2.9 [Checklist: Implement Security Logging and Monitoring](#checklist-implement-security-logging-and-monitoring) +4.2.10 [Checklist: Handle all Errors and Exceptions](#checklist-handle-all-errors-and-exceptions) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0602]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[issue0602]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/00-toc +[proactive10]: https://owasp.org/www-project-proactive-controls/ diff --git a/release-ja/06-design/02-web-app-checklist/01-define-security-requirements.md b/release-ja/06-design/02-web-app-checklist/01-define-security-requirements.md new file mode 100644 index 00000000..a7b3f545 --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/01-define-security-requirements.md @@ -0,0 +1,82 @@ +--- + +title: Define Security Requirements Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: 6210 +permalink: /release/design/web_app_checklist/define_security_requirements/ + +--- + +{% include breadcrumb.html %} + +### 4.2.1 Checklist: Define Security Requirements + +A security requirement is a statement of security functionality that ensures software security is being satisfied. +Security requirements are derived from industry standards, applicable laws, and a history of past vulnerabilities. + +Refer to proactive control [C4: Address Security form the Start][control4] and its [cheatsheets][csproactive-c1] +for more context from the OWASP Top 10 Proactive Controls project, +and use the lists below as suggestions for a checklist that has been tailored for the individual project. + +#### 1. System configuration + +1. Restrict applications, processes and service accounts to the least privileges possible +1. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible +1. Remove all unnecessary functionality and files +1. Remove test code or any functionality not intended for production, prior to deployment +1. The security configuration store for the application should be available in human readable form to support auditing +1. Isolate development environments from production and provide access only to authorized development and test groups +1. Implement a software change control system to manage and record changes to the code both in development and production + +#### 2. Cryptographic practices + +1. Use peer reviewed and open solution cryptographic modules +1. All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system +1. Cryptographic modules must fail securely +1. Ensure all random elements such as numbers, file names, UUID and strings are generated + using the cryptographic module approved random number generator +1. Cryptographic modules used by the application are compliant to FIPS 140-2 or an equivalent standard +1. Establish and utilize a policy and process for how cryptographic keys will be managed +1. Ensure that any secret key is protected from unauthorized access +1. Store keys in a proper secrets vault as described below +1. Use independent keys when multiple keys are required +1. Build support for changing algorithms and keys when needed +1. Build application features to handle a key rotation + +#### 3. File management + +1. Do not pass user supplied data directly to any dynamic include function +1. Require authentication before allowing a file to be uploaded +1. Limit the type of files that can be uploaded to only those types that are needed for business purposes +1. Validate uploaded files are the expected type by checking file headers rather than by file extension +1. Do not save files in the same web context as the application +1. Prevent or restrict the uploading of any file that may be interpreted by the web server. +1. Turn off execution privileges on file upload directories +1. When referencing existing files, use an allow-list of allowed file names and types +1. Do not pass user supplied data into a dynamic redirect +1. Do not pass directory or file paths, use index values mapped to pre-defined list of paths +1. Never send the absolute file path to the client +1. Ensure application files and resources are read-only +1. Scan user uploaded files for viruses and malware + +#### References + +* OWASP [Application Security Verification Standard][asvs] (ASVS) +* OWASP [Mobile Application Security][mas] +* OWASP [Top 10 Proactive Controls][proactive10] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060201] or [edit on GitHub][edit060201]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[csproactive-c1]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c1-define-security-requirements +[control4]: https://top10proactive.owasp.org/the-top-10/c4-secure-architecture/ +[edit060201]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/01-define-security-requirements.md +[issue060201]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/01-define-security-requirements +[mas]: https://mas.owasp.org/ +[proactive10]: https://top10proactive.owasp.org/ diff --git a/release-ja/06-design/02-web-app-checklist/02-frameworks-libraries.md b/release-ja/06-design/02-web-app-checklist/02-frameworks-libraries.md new file mode 100644 index 00000000..7f2cf31a --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/02-frameworks-libraries.md @@ -0,0 +1,106 @@ +--- + +title: Leverage Security Frameworks and Libraries Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: 6220 +permalink: /release/design/web_app_checklist/frameworks_libraries/ + +--- + +{% include breadcrumb.html %} + +### 4.2.2 Checklist: Leverage Security Frameworks and Libraries + +Secure coding libraries and software frameworks with embedded security help software developers guard against +security-related design and implementation flaws. + +Refer to proactive control [C4: Address Security from the Start][control4] +and its [cheatsheets][csproactive-c2] for more context from the OWASP Top 10 Proactive Controls project. + +For technology specific checklists refer to the appropriate OWASP Cheat Sheets: + +* [AJAX_Security][csajax] +* [C-Based toolchain hardening][cscbased] +* [Django security][csdjango] +* [Django REST framework][csdjangorest] +* [Docker security][csdocker] +* [DotNet security][csdotnet] +* [GraphQL security][csgraphql] +* [Infrastructure as Code][csias] +* [Java security][csjava] +* [Javascript management][csjcavascript] +* [Kubernetes][cskube] +* [Laravel security][cslaravel] +* [Microservices security][csmicro] +* [NPM security best practices][csnpm] +* [Node.js security][csnode] +* [Node.js security for Docker][csnodedocker] +* [PHP configuration][csphp] +* [REST APIs][csrest] and [how to assess them][csrassess] +* [Ruby on Rails security][csruby] +* [Symfony framework][cssymfony] +* [Web Services][cswebservice] +* [XML security][csxml] + +and use them as the starting point for a checklist that is tailored for the technology used by the project. + +In addition consider the following extra checks for frameworks and libraries. + +#### 1. Security Frameworks and Libraries + +1. Ensure servers, frameworks and system components are running the latest approved versions and patches +1. Use libraries and frameworks from trusted sources that are actively maintained and widely used +1. Review all secondary applications and third party libraries to determine business necessity +1. Validate safe functionality for all secondary applications and third party libraries +1. Create and maintain an inventory catalog of all third party libraries using Software Composition Analysis (SCA) +1. Proactively keep all third party libraries and components up to date +1. Reduce the attack surface by encapsulating the library and expose only the required behavior into your software +1. Use tested and approved managed code rather than creating new unmanaged code for common tasks +1. Utilize task specific built-in APIs to conduct operating system tasks +1. Do not allow the application to issue commands directly to the Operating System +1. Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files +1. Restrict users from generating new code or altering existing code +1. Implement safe updates using encrypted channels + +#### References + +* OWASP [Dependency Check][dependency] +* OWASP [Top 10 Proactive Controls][proactive10] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060202] or [edit on GitHub][edit060202]. + +[csajax]: https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet +[cscbased]: https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet +[csdjango]: https://cheatsheetseries.owasp.org/cheatsheets/Django_Security_Cheat_Sheet +[csdjangorest]: https://cheatsheetseries.owasp.org/cheatsheets/Django_REST_Framework_Cheat_Sheet +[csdocker]: https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet +[csdotnet]: https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet +[csgraphql]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet +[csias]: https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet +[csjava]: https://cheatsheetseries.owasp.org/cheatsheets/Java_Security_Cheat_Sheet +[csjcavascript]: https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet +[cskube]: https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet +[cslaravel]: https://cheatsheetseries.owasp.org/cheatsheets/Laravel_Cheat_Sheet +[csmicro]: https://cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet +[csnpm]: https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet +[csnode]: https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet +[csnodedocker]: https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker_Cheat_Sheet +[csphp]: https://cheatsheetseries.owasp.org/cheatsheets/PHP_Configuration_Cheat_Sheet +[csrest]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet +[csrassess]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[csruby]: https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet +[cssymfony]: https://cheatsheetseries.owasp.org/cheatsheets/Symfony_Cheat_Sheet +[cswebservice]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet +[csxml]: https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet +[csproactive-c2]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c2-leverage-security-frameworks-and-libraries +[control4]: https://top10proactive.owasp.org/the-top-10/c4-secure-architecture/ +[dependency]: https://owasp.org/www-project-dependency-check/ +[edit060202]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/02-frameworks-libraries.md +[issue060202]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/02-frameworks-libraries +[proactive10]: https://top10proactive.owasp.org/ diff --git a/release-ja/06-design/02-web-app-checklist/03-secure-database-access.md b/release-ja/06-design/02-web-app-checklist/03-secure-database-access.md new file mode 100644 index 00000000..8f1f0fef --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/03-secure-database-access.md @@ -0,0 +1,66 @@ +--- + +title: Secure Database Access Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: 6230 +permalink: /release/design/web_app_checklist/secure_database_access/ + +--- + +{% include breadcrumb.html %} + +### 4.2.3 Checklist: Secure Database Access + +Ensure that access to all data stores is secure, including both relational databases and NoSQL databases. + +Refer to proactive control [C3: Validate all Input & Handle Exceptions][control3] and its [cheatsheets][csproactive-c3] +for more context from the OWASP Top 10 Proactive Controls project, +and use the list below as suggestions for a checklist that has been tailored for the individual project. + +#### 1. Secure queries + +1. Use Query Parameterization to prevent untrusted input being interpreted as part of a SQL command +1. Use strongly typed parameterized queries +1. Utilize input validation and output encoding and be sure to address meta characters +1. Do not run the database command if input validation fails +1. Ensure that variables are strongly typed +1. Connection strings should not be hard coded within the application +1. Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted + +#### 2. Secure configuration + +1. The application should use the lowest possible level of privilege when accessing the database +1. Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database +1. Close the database connection as soon as possible +1. Turn off all unnecessary database functionality +1. Remove unnecessary default vendor content, for example sample schemas +1. Disable any default accounts that are not required to support business requirements + +#### 3. Secure authentication + +1. Remove or change all default database administrative passwords +1. The application should connect to the database with different credentials for every trust distinction + (for example user, read-only user, guest, administrators) +1. Use secure credentials for database access + +#### References + +* OWASP [Cheat Sheet: Query Parameterization][csquery] +* OWASP [Cheat Sheet: Database Security][csdb] +* OWASP [Top 10 Proactive Controls][proactive10] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060203] or [edit on GitHub][edit060203]. + +[csproactive-c3]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c3-secure-database-access +[control3]: https://top10proactive.owasp.org/the-top-10/c3-validate-input-and-handle-exceptions/ +[csdb]: https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet +[csquery]: https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet +[edit060203]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/03-secure-database-access.md +[issue060203]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/03-secure-database-access +[proactive10]: https://top10proactive.owasp.org/ diff --git a/release-ja/06-design/02-web-app-checklist/04-encode-escape-data.md b/release-ja/06-design/02-web-app-checklist/04-encode-escape-data.md new file mode 100644 index 00000000..5ef4da8a --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/04-encode-escape-data.md @@ -0,0 +1,63 @@ +--- + +title: Encode and Escape Data Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: 6240 +permalink: /release/design/web_app_checklist/encode_escape_data/ + +--- + +{% include breadcrumb.html %} + +### 4.2.4 Checklist: Encode and Escape Data + +Encoding and escaping of output data are defensive techniques meant to stop injection attacks +on a target system or application which is receiving the output data. + +The target system may be another software component or it may be reflected back to the initial system, +such as operating system commands, +so encoding and escaping output data helps to provide defense in depth for the system as a whole. + +Refer to proactive control [C3: Validate all Input & Handle Exceptions][control3] and its [cheatsheets][csproactive-c4] +for more context from the OWASP Top 10 Proactive Controls project, +and use the list below as suggestions for a checklist that has been tailored for the individual project. + +#### 1. Character encoding and canonicalization + +1. Apply output encoding just before the content is passed to the target system +1. Conduct all output encoding on a trusted system +1. Utilize a standard, tested routine for each type of outbound encoding +1. Specify character sets, such as UTF-8, for all outputs +1. Apply canonicalization to convert unicode data into a standard form +1. Ensure the output encoding is safe for all target systems +1. In particular sanitize all output used for operating system commands + +#### 2. Contextual output encoding + +Contextual output encoding of data is based on how it will be utilized by the target. +The specific methods vary depending on the way the output data is used, such as HTML entity encoding. + +1. Contextually encode all data returned to the client from untrusted sources +1. Contextually encode all output of untrusted data to queries for SQL, XML, and LDAP + +#### References + +* OWASP [Cheat Sheet: Injection Prevention][ipcs] +* OWASP [Java Encoder Project][encoder] +* OWASP [Top 10 Proactive Controls][proactive10] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060204] or [edit on GitHub][edit060204]. + +[csproactive-c4]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c4-encode-and-escape-data +[control3]: https://top10proactive.owasp.org/the-top-10/c3-validate-input-and-handle-exceptions/ +[edit060204]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/04-encode-escape-data.md +[encoder]: https://www.owasp.org/index.php/OWASP_Java_Encoder_Project +[ipcs]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet +[issue060204]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/04-encode-escape-data +[proactive10]: https://top10proactive.owasp.org/ diff --git a/release-ja/06-design/02-web-app-checklist/05-validate-inputs.md b/release-ja/06-design/02-web-app-checklist/05-validate-inputs.md new file mode 100644 index 00000000..6302fa43 --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/05-validate-inputs.md @@ -0,0 +1,78 @@ +--- + +title: Validate All Inputs Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: 6250 +permalink: /release/design/web_app_checklist/validate_inputs/ + +--- + +{% include breadcrumb.html %} + +### 4.2.5 Checklist: Validate All Inputs + +Input validation is a collection of techniques that ensure only properly formatted data +may enter a software application or system component. + +It is vital that input validation is performed to provide the starting point for a secure application or system. +Without input validation the software application/system will continue to be vulnerable to new and varied attacks. + +Refer to proactive control [C3: Validate All Input & Handle Exceptions][control3] and its [cheatsheets][csproactive-c5] +for more context from the OWASP Top 10 Proactive Controls project, +and use the list below as suggestions for a checklist that has been tailored for the individual project. + +#### 1. Syntax and semantic validity + +1. Identify all data sources and classify them into trusted and untrusted +2. Validate all input data from untrusted sources such as client provided data +3. Encode input to a common character set before validating +4. Specify character sets, such as UTF-8, for all input sources +5. If the system supports UTF-8 extended character sets then validate after UTF-8 decoding is completed +6. Verify that protocol header values in both requests and responses contain only ASCII characters +7. Validate data from redirects +8. Validate data range and also data length +9. Utilize canonicalization to address obfuscation attacks +10. All validation failures should result in input rejection + +#### 2. Libraries and frameworks + +1. Conduct all input validation on a trusted system [^SCP1] +2. Use a centralized input validation library or framework for the whole application +3. If the standard validation routine cannot address some inputs then use extra discrete checks +4. If any potentially hazardous input _must_ be allowed then implement additional controls +5. Validate for expected data types using an allow-list rather than a deny-list + +#### 3. Validate serialized data + +1. Implement integrity checks or encryption of the serialized objects + to prevent hostile object creation or data tampering +2. Enforce strict type constraints during deserialization before object creation; + typically a definable set of classes is expected +3. Isolate features that deserialize so that they run in very low privilege environments such as temporary containers +4. Log security deserialization exceptions and failures +5. Restrict or monitor incoming and outgoing network connectivity from containers or servers that deserialize +6. Monitor deserialization, for example alerting if a user agent constantly deserializes + +#### References + +* OWASP [Cheat Sheet: Input Validation][ivcs] +* OWASP [Java HTML Sanitizer Project][sanitizer] +* OWASP [Top 10 Proactive Controls][proactive10] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060205] or [edit on GitHub][edit060205]. + +[^SCP1]: Secure Coding Practices checklist + +[csproactive-c5]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c5-validate-all-inputs +[control3]: https://top10proactive.owasp.org/the-top-10/c3-validate-input-and-handle-exceptions/ +[ivcs]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet +[edit060205]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/05-validate-inputs.md +[issue060205]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/05-validate-inputs +[proactive10]: https://top10proactive.owasp.org +[sanitizer]: https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer diff --git a/release-ja/06-design/02-web-app-checklist/06-digital-identity.md b/release-ja/06-design/02-web-app-checklist/06-digital-identity.md new file mode 100644 index 00000000..88fab3fa --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/06-digital-identity.md @@ -0,0 +1,118 @@ +--- + +title: Implement Digital Identity Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: 6260 +permalink: /release/design/web_app_checklist/digital_identity/ + +--- + +{% include breadcrumb.html %} + +### 4.2.6 Checklist: Implement Digital Identity + +[Authentication][csauthn] is the process of verifying that an individual or entity is who they claim to be. +Session management is a process by which a server maintains the state of the users authentication +so that the user may continue to use the system without re-authenticating. + +Refer to proactive control [C7: Implement Digital Identity][control7] and its [cheatsheets][csproactive-c6] +for more context from the OWASP Top 10 Proactive Controls project, +and use the list below as suggestions for a checklist that has been tailored for the individual project. + +#### 1. Authentication + +1. Design access control authentication thoroughly up-front +1. Force all requests to go through access control checks unless public +1. Do not hard code access controls that are role based +1. Log all access control events +1. Use [Multi-Factor Authentication][csmfa] (MFA) for sensitive or high value transactional accounts + +#### 2. Passwords + +1. Require authentication for all pages and resources, except those specifically intended to be public +1. All authentication controls must be enforced on a trusted system +1. Establish and utilize standard, tested, authentication services whenever possible +1. Use a centralized implementation for all authentication controls +1. Segregate authentication logic from the resource being requested and + use redirection to and from the centralized authentication control +1. All authentication controls should fail securely +1. Administrative and account management must be at least as secure as the primary authentication mechanism +1. If your application manages a credential store, use cryptographically strong one-way salted hashes +1. Password hashing must be implemented on a trusted system +1. Validate the authentication data only on completion of all data input +1. Authentication failure responses should not indicate which part of the authentication data was incorrect +1. Utilize authentication for connections to external systems that involve sensitive information or functions +1. Authentication credentials for accessing services external to the application should be stored in a secure store +1. Use only HTTP POST requests to transmit authentication credentials +1. Only send non-temporary passwords over an encrypted connection or as encrypted data +1. Enforce password complexity and length requirements established by policy or regulation +1. Enforce account disabling after an established number of invalid login attempts +1. Password reset and changing operations require the same level of controls as account creation and authentication +1. Password reset questions are deprecated, see [Choosing and Using Security Questions Cheat Sheet][csquestions] as to why +1. If using email based resets, only send email to a pre-registered address with a temporary link/password +1. Temporary passwords and links should have a short expiration time +1. Enforce the changing of temporary passwords on the next use +1. Notify users when a password reset occurs +1. Prevent password re-use +1. The last use (successful or unsuccessful) of a user account should be reported to the user + at their next successful login +1. Change all vendor-supplied default passwords and user IDs or disable the associated accounts +1. Re-authenticate users prior to performing critical operations +1. If using third party code for authentication inspect the code carefully + to ensure it is not affected by any malicious code + +#### 3. Cryptographic based authentication + +1. Use the server or framework's session management controls +1. Session identifier creation must always be done on a trusted system +1. Session management controls should use well vetted algorithms that ensure sufficiently random session identifiers +1. Set the domain and path for cookies containing authenticated session identifiers + to an appropriately restricted value for the site +1. Logout functionality should fully terminate the associated session or connection +1. Logout functionality should be available from all pages protected by authorization +1. Establish a session inactivity timeout that is as short as possible, + based on balancing risk and business functional requirements +1. Disallow persistent logins and enforce periodic session terminations, even when the session is active +1. If a session was established before login, close that session and establish a new session after a successful login +1. Generate a new session identifier on any re-authentication +1. Do not allow concurrent logins with the same user ID +1. Do not expose session identifiers in URLs, error messages or logs +1. Implement appropriate access controls to protect server side session data + from unauthorized access from other users of the server +1. Generate a new session identifier and deactivate the old one periodically +1. Generate a new session identifier if the connection security changes from HTTP to HTTPS, + as can occur during authentication +1. Set the `secure` attribute for cookies transmitted over an [TLS][tls] connection +1. Set cookies with the `HttpOnly` attribute, + unless you specifically require client-side scripts within your application to read or set a cookie value + +#### References + +* OWASP [Cheat Sheet: Authentication][csauthn] +* OWASP [Cheat Sheet: Choosing and Using Security Questions][csquestions] +* OWASP [Cheat Sheet: Forgot Password][csforgot] +* OWASP [Cheat Sheet: Multifactor Authentication][csmfa] +* OWASP [Cheat Sheet: Password Storage][cspass] +* OWASP [Cheat Sheet: Session Management][cssession] +* OWASP [Top 10 Proactive Controls][proactive10] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060206] or [edit on GitHub][edit060206]. + +[csproactive-c6]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c6-implement-digital-identity +[control7]: https://top10proactive.owasp.org/the-top-10/c7-secure-digital-identities/ +[csauthn]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet +[csmfa]: https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet +[cspass]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet +[csforgot]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet +[cssession]: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet +[csquestions]: https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet +[edit060206]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/06-digital-identity.md +[issue060206]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/06-digital-identity +[proactive10]: https://top10proactive.owasp.org +[tls]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet diff --git a/release-ja/06-design/02-web-app-checklist/07-access-controls.md b/release-ja/06-design/02-web-app-checklist/07-access-controls.md new file mode 100644 index 00000000..c858946e --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/07-access-controls.md @@ -0,0 +1,61 @@ +--- + +title: Enforce Access Controls Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: 6270 +permalink: /release/design/web_app_checklist/access_controls/ + +--- + +{% include breadcrumb.html %} + +### 4.2.7 Checklist: Enforce Access Controls + +Access Control or [Authorization][csauthz] is the process of granting or denying specific requests +from a user, program, or process. + +Refer to proactive control [C1: Implement Access Controls][control1] and its [cheatsheets][csproactive-c7] +for more context from the OWASP Top 10 Proactive Controls project, +and use the list below as suggestions for a checklist that has been tailored for the individual project. + +#### 1. Authorization + +1. Design access control / authorization thoroughly up-front +1. Force all requests to go through access control checks unless public +1. Deny by default; if a request is not specifically allowed then it is denied +1. Apply least privilege, providing the least access as is necessary +1. Log all authorization events + +#### 2. Access control + +1. Enforce authorization controls on every request +1. Use only trusted system objects for making access authorization decisions +1. Use a single site-wide component to check access authorization +1. Access controls should fail securely +1. Deny all access if the application cannot access its security configuration information +1. Segregate privileged logic from other application code +1. Limit the number of transactions a single user or device can perform in a given period of time, + low enough to deter automated attacks but above the actual business requirement +1. If long authenticated sessions are allowed, periodically re-validate a user's authorization +1. Implement account auditing and enforce the disabling of unused accounts +1. The application must support termination of sessions when authorization ceases + +#### References + +* OWASP [Cheat Sheet: Authorization][csauthz] +* OWASP [Top 10 Proactive Controls][proactive10] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060207] or [edit on GitHub][edit060207]. + +[csproactive-c7]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c7-enforce-access-controls +[control1]: https://top10proactive.owasp.org/the-top-10/c1-accesscontrol/ +[csauthz]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet +[edit060207]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/07-access-controls.md +[issue060207]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/07-access-controls +[proactive10]: https://top10proactive.owasp.org/ diff --git a/release-ja/06-design/02-web-app-checklist/08-protect-data.md b/release-ja/06-design/02-web-app-checklist/08-protect-data.md new file mode 100644 index 00000000..71714942 --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/08-protect-data.md @@ -0,0 +1,68 @@ +--- + +title: Protect Data Everywhere Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: 6280 +permalink: /release/design/web_app_checklist/protect_data/ + +--- + +{% include breadcrumb.html %} + +### 4.2.8 Checklist: Protect Data Everywhere + +Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets +require extra protection, particularly if that data falls under privacy laws (EU General Data Protection Regulation GDPR), +financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations. + +Refer to proactive control [C2: Use Cryptography the proper way][control2] and its [cheatsheets][csproactive-c8] +for more context from the OWASP Top 10 Proactive Controls project, +and use the list below as suggestions for a checklist that has been tailored for the individual project. + +#### 1. Data protection + +1. Classify data according to the level of sensitivity +1. Implement appropriate access controls for sensitive data +1. Encrypt data in transit +1. Ensure secure communication channels are properly configured +1. Avoid storing sensitive data when at all possible +1. Ensure sensitive data at rest is cryptographically protected to avoid unauthorized disclosure and modification +1. Purge sensitive data when that data is no longer required +1. Store application-level secrets in a secrets vault +1. Check that secrets are not stored in code, config files or environment variables +1. Implement least privilege, restricting access to functionality, data and system information +1. Protect all cached or temporary copies of sensitive data from unauthorized access +1. Purge those temporary copies of sensitive data as soon as they are no longer required + +#### 2. Memory management + +1. Explicitly initialize all variables and data stores +1. Check that any buffers are as large as specified +1. Check buffer boundaries if calling the function in a loop and protect against overflow +1. Specifically close resources, don't rely on garbage collection +1. Use non-executable stacks when available +1. Properly free allocated memory upon the completion of functions and at all exit points +1. Overwrite any sensitive information stored in allocated memory at all exit points from the function +1. Protect shared variables and resources from inappropriate concurrent access + +#### References + +* OWASP [Cheat Sheet: Cryptographic Storage][cscs] +* OWASP [Cheat Sheet: Secrets Management][cssm] +* OWASP [Top 10 Proactive Controls][proactive10] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060208] or [edit on GitHub][edit060208]. + +[csproactive-c8]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c8-protect-data-everywhere +[control2]: https://top10proactive.owasp.org/the-top-10/c2-crypto/ +[cscs]: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet +[cssm]: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet +[edit060208]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/08-protect-data.md +[issue060208]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/08-protect-data +[proactive10]: https://top10proactive.owasp.org/ diff --git a/release-ja/06-design/02-web-app-checklist/09-logging-monitoring.md b/release-ja/06-design/02-web-app-checklist/09-logging-monitoring.md new file mode 100644 index 00000000..6e20f7e5 --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/09-logging-monitoring.md @@ -0,0 +1,64 @@ +--- + +title: Implement Security Logging and Monitoring Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: 6290 +permalink: /release/design/web_app_checklist/security_logging_and_monitoring/ + +--- + +{% include breadcrumb.html %} + +### 4.2.9 Checklist: Implement Security Logging and Monitoring + +Logging is recording security information during the runtime operation of an application. +Monitoring is the live review of application and security logs using various forms of automation. + +Refer to proactive control [C9: Implement Security Logging and Monitoring][control9] +and its [cheatsheets][csproactive-c9] for more context from the OWASP Top 10 Proactive Controls project, +and use the list below as suggestions for a checklist that has been tailored for the individual project. + +#### 1. Security logging + +1. Log submitted data that is outside of an expected numeric range. +1. Log submitted data that involves changes to data that should not be modifiable +1. Log requests that violate server-side access control rules +1. Encode and validate any dangerous characters before logging to prevent log injection attacks +1. Do not log sensitive information +1. Logging controls should support both success and failure of specified security events +1. Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords +1. Use a cryptographic hash function to validate log entry integrity + +#### 2. Security logging design + +1. Protect log integrity +1. Ensure log entries that include untrusted data will not execute as code in the intended log viewing interface or software +1. Restrict access to logs to only authorized individuals +1. Utilize a central routine for all logging operations +1. Forward logs from distributed systems to a central, secure logging service +1. Follow a common logging format and approach within the system and across systems of an organization +1. Synchronize across nodes to ensure that timestamps are consistent +1. All logging controls should be implemented on a trusted system +1. Ensure that a mechanism exists to conduct log analysis + +#### References + +* OWASP [Cheat Sheet: Logging][cslogging] +* OWASP [Cheat Sheet: Application Logging Vocabulary][csvocabulary] +* OWASP [Top 10 Proactive Controls][proactive10] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060209] or [edit on GitHub][edit060209]. + +[csproactive-c9]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c9-implement-security-logging-and-monitoring +[control9]: https://top10proactive.owasp.org/the-top-10/c9-security-logging-and-monitoring/ +[cslogging]: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet +[csvocabulary]: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet +[edit060209]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/09-logging-monitoring.md +[issue060209]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/09-logging-monitoring +[proactive10]: https://top10proactive.owasp.org/ diff --git a/release-ja/06-design/02-web-app-checklist/10-handle-errors-exceptions.md b/release-ja/06-design/02-web-app-checklist/10-handle-errors-exceptions.md new file mode 100644 index 00000000..196adcec --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/10-handle-errors-exceptions.md @@ -0,0 +1,59 @@ +--- + +title: Handle all Errors and Exceptions Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden, Andreas Happe +document: OWASP Developer Guide +order: 6300 +permalink: /release/design/web_app_checklist/handle_errors_and_exceptions/ + +--- + +{% include breadcrumb.html %} + +### 4.2.10 Checklist: Handle all Errors and Exceptions + +Handling [exceptions and errors][cserror] correctly is critical to making your code reliable and secure. +Error and exception handling occurs in all areas of an application including critical business logic +as well as security features and framework code. + +Refer to proactive control [C3: Validate all Input & Handle Exceptions][control3] +and its [cheatsheets][csproactive-c10] for more context from the OWASP Top 10 Proactive Controls project, +and use the list below as suggestions for a checklist that has been tailored for the individual project. + +#### 1. Errors and exceptions + +1. Manage exceptions in a centralized manner to avoid duplicated try/catch blocks in the code +1. Ensure that all unexpected behavior is correctly handled inside the application +1. Ensure that error messages displayed to users do not leak critical data, + but are still verbose enough to enable the proper user response +1. Ensure that exceptions logs give enough information for support, QA, forensics or incident response teams +1. Carefully test and verify error handling code +1. Do not disclose sensitive information in error responses, for example + system details, session identifiers or account information +1. Use error handlers that do not display debugging or stack trace information +1. Implement generic error messages and use custom error pages +1. The application should handle application errors and not rely on the server configuration +1. Properly free allocated memory when error conditions occur +1. Error handling logic associated with security controls should deny access by default + +#### References + +* OWASP [Code Review Guide: Error Handling][review] +* OWASP [Improper Error Handling][handle] +* OWASP [Top 10 Proactive Controls][proactive10] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue060210] or [edit on GitHub][edit060210]. + +[cserror]: https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet +[csproactive-c10]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c10-handle-all-errors-and-exceptions +[control3]: https://top10proactive.owasp.org/the-top-10/c3-validate-input-and-handle-exceptions/ +[edit060210]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/10-handle-errors-exceptions.md +[handle]: https://owasp.org/www-community/Improper_Error_Handling +[issue060210]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/10-handle-errors-exceptions +[proactive10]: https://top10proactive.owasp.org/ +[review]: https://owasp.org/www-project-code-review-guide/ diff --git a/release-ja/06-design/02-web-app-checklist/info.md b/release-ja/06-design/02-web-app-checklist/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/06-design/02-web-app-checklist/toc.md b/release-ja/06-design/02-web-app-checklist/toc.md new file mode 100644 index 00000000..31ea873a --- /dev/null +++ b/release-ja/06-design/02-web-app-checklist/toc.md @@ -0,0 +1,63 @@ +--- + +title: Web Application Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 6200 +permalink: /release/design/web_app_checklist/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 4.2 Web application checklist + +Checklists are a valuable resource for development teams. +They provide structure for establishing good practices and processes +and are also useful during code reviews and design activities. + +The checklists that follow are general lists that are categorized to follow the controls listed in the +[OWASP Top 10 Proactive Controls][proactive10] project. +These checklists provide suggestions that certainly should be tailored to +an individual project's requirements and environment; they are not meant to be followed in their entirety. + +Probably the best starting point for a checklist is given by the [Application Security Verification Standard (ASVS)][asvs]. +The ASVS can be used to provide a framework for an initial checklist, according to the security verification level, +and this initial ASVS checklist can then be expanded using the following checklist sections. + +Sections: + +4.2.1 [Checklist: Define Security Requirements](01-define-security-requirements.md) +4.2.2 [Checklist: Leverage Security Frameworks and Libraries](02-frameworks-libraries.md) +4.2.3 [Checklist: Secure Database Access](03-secure-database-access.md) +4.2.4 [Checklist: Encode and Escape Data](04-encode-escape-data.md) +4.2.5 [Checklist: Validate All Inputs](05-validate-inputs.md) +4.2.6 [Checklist: Implement Digital Identity](06-digital-identity.md) +4.2.7 [Checklist: Enforce Access Controls](07-access-controls.md) +4.2.8 [Checklist: Protect Data Everywhere](08-protect-data.md) +4.2.9 [Checklist: Implement Security Logging and Monitoring](09-logging-monitoring.md) +4.2.10 [Checklist: Handle all Errors and Exceptions](10-handle-errors-exceptions.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0602] or [edit on GitHub][edit0602]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[edit0602]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/toc.md +[issue0602]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/02-web-app-checklist/00-toc +[proactive10]: https://owasp.org/www-project-proactive-controls/ diff --git a/release-ja/06-design/03-mas-checklist.md b/release-ja/06-design/03-mas-checklist.md new file mode 100644 index 00000000..55b1a273 --- /dev/null +++ b/release-ja/06-design/03-mas-checklist.md @@ -0,0 +1,88 @@ +--- + +title: MAS Checklist +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 6400 +permalink: /release/design/mas_checklist/ + +--- + +{% include breadcrumb.html %} + + + +![MAS checklist logo](../../../assets/images/logos/mas.png "OWASP MAS checklist"){: .image-right } + +### 4.3 MAS checklist + +The OWASP [Mobile Application Security][masproject] (MAS) flagship project provides +industry standards for mobile application security. + +The OWASP MAS project provides the [Mobile Application Security Verification Standard][masvs] (MASVS) +for mobile applications and a comprehensive [Mobile Application Security Testing Guide][mastg] (MASTG). + +The [Mobile Application Security Checklist][masc] contains links to the MASTG test cases for each MASVS control. + +#### What is MAS Checklist? + +The MAS Checklist provides a checklist that keeps track of the MASTG test cases for a given MASVS control. +This MAS Checklist is split out into categories that match the MASVS categories: + +* [MASVS-STORAGE](https://mas.owasp.org/checklists/MASVS-STORAGE/) sensitive data storage +* [MASVS-CRYPTO](https://mas.owasp.org/checklists/MASVS-CRYPTO/) cryptography best practices +* [MASVS-AUTH](https://mas.owasp.org/checklists/MASVS-AUTH/) authentication and authorization mechanisms +* [MASVS-NETWORK](https://mas.owasp.org/checklists/MASVS-NETWORK/) network communications +* [MASVS-PLATFORM](https://mas.owasp.org/checklists/MASVS-PLATFORM/) interactions with the mobile platform +* [MASVS-CODE](https://mas.owasp.org/checklists/MASVS-CODE/) platform and data entry points along with third-party software +* [MASVS-RESILIENCE](https://mas.owasp.org/checklists/MASVS-RESILIENCE/) integrity and running on a trusted platform +* [MASVS-PRIVACY](https://mas.owasp.org/checklists/MASVS-PRIVACY/) privacy of users, data and resources + +In addition to the web links there is a [downloadable spreadsheet][masxls]. + +#### Why use it? + +The OWASP MASVS is the industry standard for [mobile application security][csmas]. +If the MASTG is being applied to a mobile application then the MAS Checklist is a handy reference +that can also be used for compliance purposes. + +#### How to use it + +The [online version][masc] is useful to list the MASVS controls and which MASTG tests apply. +Follow the links to access the individual controls and tests. + +The [spreadsheet download][masxls] allows the status of each test to be recorded, +with a separate sheet for each MASVS category. +This record of test results can be used as evidence for compliance purposes. + +#### References + +* Mobile Application Security ([MAS][masproject]) project +* MAS [Checklist][masc] +* MAS Verification Standard ([MASVS][masvs]) +* MAS Testing Guide ([MASTG][mastg]) +* OWASP [Mobile Application Security][csmas] cheat sheet + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0603] or [edit on GitHub][edit0603]. + +[csmas]: https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet +[edit0603]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/03-mas-checklist.md +[issue0603]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/03-mas-checklist +[masproject]: https://owasp.org/www-project-mobile-app-security/ +[masxls]: https://github.com/OWASP/owasp-mastg/releases/latest/download/OWASP_MAS_Checklist.xlsx +[masc]: https://mas.owasp.org/checklists/ +[mastg]: https://mas.owasp.org/MASTG/ +[masvs]: https://mas.owasp.org/MASVS/ diff --git a/release-ja/06-design/info.md b/release-ja/06-design/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/06-design/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/06-design/toc.md b/release-ja/06-design/toc.md new file mode 100644 index 00000000..a92d0828 --- /dev/null +++ b/release-ja/06-design/toc.md @@ -0,0 +1,94 @@ +--- + +title: Design +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 6000 +permalink: /release/design/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){: .image-right } + +## 4. Design + +Referring to the [Secure Product Design Cheat Sheet][spdcs], the purpose of secure architecture and design is to ensure +that all products meet or exceed the security requirements laid down by the organization, +focusing on the security linked to components and technologies used during the development of the application. + +Secure Architecture Design looks at the selection and composition of components that form the foundation of the solution. +Technology Management looks at the security of supporting technologies used during development, deployment and operations, +such as development stacks and tooling, deployment tooling, and operating systems and tooling. + +A secure design will help establish secure defaults, minimize the attack surface area +and fail securely to well-defined and understood defaults. +It will also consider and follow various principles, such as: + +* Least Privilege and Separation of Duties +* Defense-in-Depth +* Zero Trust +* Security in the Open + +A Secure Development Lifecycle (SDLC) helps to ensure that all security decisions made about the product being developed +are explicit choices and result in the correct level of security for the product design. +Various secure development lifecycles can be used and they generally include threat modeling in the design process. + +Checklists and Cheat Sheets are an important tool during the design process; +they provide an easy reference of knowledge and help avoid repeating design errors and mistakes. + +Software application [Design][sammd] is one of the major business functions described in +the [Software Assurance Maturity Model (SAMM)][samm], and includes security practices: + +* [Threat Assessment][sammdta] +* [Security Requirements][sammdsr] +* [Security Architecture][sammdsa] + +Sections: + +4.1 [Threat modeling](01-threat-modeling/toc.md) +4.1.1 [Threat modeling in practice](01-threat-modeling/01-threat-modeling.md) +4.1.2 [pytm](01-threat-modeling/02-pytm.md) +4.1.3 [Threat Dragon](01-threat-modeling/03-threat-dragon.md) +4.1.4 [Cornucopia](01-threat-modeling/04-cornucopia.md) +4.1.5 [LINDDUN GO](01-threat-modeling/05-linddun-go.md) +4.1.6 [Threat Modeling toolkit](01-threat-modeling/06-toolkit.md) +4.2 [Web application checklist](02-web-app-checklist/toc.md) +4.2.1 [Checklist: Define Security Requirements](02-web-app-checklist/01-define-security-requirements.md) +4.2.2 [Checklist: Leverage Security Frameworks and Libraries](02-web-app-checklist/02-frameworks-libraries.md) +4.2.3 [Checklist: Secure Database Access](02-web-app-checklist/03-secure-database-access.md) +4.2.4 [Checklist: Encode and Escape Data](02-web-app-checklist/04-encode-escape-data.md) +4.2.5 [Checklist: Validate All Inputs](02-web-app-checklist/05-validate-inputs.md) +4.2.6 [Checklist: Implement Digital Identity](02-web-app-checklist/06-digital-identity.md) +4.2.7 [Checklist: Enforce Access Controls](02-web-app-checklist/07-access-controls.md) +4.2.8 [Checklist: Protect Data Everywhere](02-web-app-checklist/08-protect-data.md) +4.2.9 [Checklist: Implement Security Logging and Monitoring](02-web-app-checklist/09-logging-monitoring.md) +4.2.10 [Checklist: Handle all Errors and Exceptions](02-web-app-checklist/10-handle-errors-exceptions.md) +4.3 [MAS checklist](03-mas-checklist.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0600] or [edit on GitHub][edit0600]. + +[edit0600]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/toc.md +[issue0600]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2006-design/00-toc +[samm]: https://owaspsamm.org/about/ +[sammd]: https://owaspsamm.org/model/design/ +[sammdsr]: https://owaspsamm.org/model/design/security-requirements/ +[sammdsa]: https://owaspsamm.org/model/design/secure-architecture/ +[sammdta]: https://owaspsamm.org/model/design/threat-assessment/ +[spdcs]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet diff --git a/release-ja/07-implementation/00-toc.md b/release-ja/07-implementation/00-toc.md new file mode 100644 index 00000000..bc9cc044 --- /dev/null +++ b/release-ja/07-implementation/00-toc.md @@ -0,0 +1,62 @@ +--- + +title: Implementation +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){height=180px} + +## 5. Implementation + +The [Implementation][sammi] business function is described by the OWASP [Software Assurance Maturity Model][sammm] (SAMM). +Implementation is focused on the processes and activities related to how an organization +builds and deploys software components and its related defects. +Implementation activities have the most impact on the daily life of developers, +and an important goal of Implementation is to ship reliably working software with minimum defects. + +Implementation should include security practices such as : + +* Secure Build +* Secure Deployment +* Defect Management + +Implementation is where the application / system begins to take shape; source code is written and tests are created. +The implementation of the application follows a secure development lifecycle, with security built in from the start. + +The implementation will use a secure method of source code control and storage to fulfill the design security requirements. +The development team will be referring to documentation advising them of best practices, +they will be using secure libraries wherever possible in addition to checking and tracking external dependencies. + +Much of the skill of implementation comes from experience, and taking into account the Do's and Don'ts +of secure development is an important knowledge activity in itself. + +Sections: + +5.1 [Documentation](#documentation) +5.1.1 [Top 10 Proactive Controls](#top-proactive-controls) +5.1.2 [Go Secure Coding Practices](#go-secure-coding-practices) +5.1.3 [Cheatsheet Series](#cheatsheet-series) +5.2 [Dependencies](#dependencies) +5.2.1 [Dependency-Check](#dependency-check) +5.2.2 [Dependency-Track](#dependency-track) +5.2.3 [CycloneDX](#cyclonedx) +5.3 [Secure Libraries](#secure-libraries) +5.3.1 [ESAPI](#esapi) +5.3.2 [CSRFGuard](#csrfguard) +5.3.3 [OSHP](#oshp) +5.4 [MASWE](#maswe) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0700]. + +[issue0700]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2007-implementation/00-toc +[sammm]: https://owaspsamm.org/model/ +[sammi]: https://owaspsamm.org/model/implementation/ diff --git a/release-ja/07-implementation/01-documentation/00-toc.md b/release-ja/07-implementation/01-documentation/00-toc.md new file mode 100644 index 00000000..dee2b0f1 --- /dev/null +++ b/release-ja/07-implementation/01-documentation/00-toc.md @@ -0,0 +1,39 @@ +--- + +title: Implementation Documentation +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 5.1 Documentation + +Documentation is used here as part of the SAMM [Training and Awareness][sammgegta] activity, +which in turn is part of the SAMM [Education & Guidance][sammgeg] security practice +within the [Governance][sammg] business function. + +It is important that development teams have good documentation on security techniques, frameworks, tools and threats. +Documentation helps to promote security awareness for all teams involved in software development, +and provides guidance on building security into applications and systems. + +Sections: + +5.1.1 [Top 10 Proactive Controls](#top-proactive-controls) +5.1.2 [Go Secure Coding Practices](#go-secure-coding-practices) +5.1.3 [Cheatsheet Series](#cheatsheet-series) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0710]. + +[issue0710]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2007-implementation/01-documentation/00-toc +[sammg]: https://owaspsamm.org/model/governance/ +[sammgeg]: https://owaspsamm.org/model/governance/education-and-guidance/ +[sammgegta]: https://owaspsamm.org/model/governance/education-and-guidance/stream-a/ diff --git a/release-ja/07-implementation/01-documentation/01-proactive-controls.md b/release-ja/07-implementation/01-documentation/01-proactive-controls.md new file mode 100644 index 00000000..aad56912 --- /dev/null +++ b/release-ja/07-implementation/01-documentation/01-proactive-controls.md @@ -0,0 +1,121 @@ +--- + +title: Top 10 Proactive Controls +layout: col-document +tags: OWASP Developer Guide +contributors: Andreas Happe, Jon Gadsden +document: OWASP Developer Guide +order: 7110 +permalink: /release/implementation/documentation/proactive_controls/ + +--- + +{% include breadcrumb.html %} + +### 5.1.1 Top 10 Proactive Controls + +The OWASP [Top 10 Proactive Controls][proactive10] describes the most important controls and control categories +that security architects and development teams should consider in web application projects. + +#### What are the Top 10 Proactive Controls? + +The OWASP Top 10 Proactive Controls is a list of security techniques that should be considered for web applications. +They are ordered by order of importance, with control number 1 being the most important: + +* C1: [Implement Access Control][control1], ref [Cheat Sheets][csproactive-c1] +* C2: [Use Cryptography the proper way][control2], ref [Cheat Sheets][csproactive-c2] +* C3: [Validate all Input & Handle Exceptions][control3], ref [Cheat Sheets][csproactive-c3] +* C4: [Address Security from the Start][control4], ref [Cheat Sheets][csproactive-c4] +* C5: [Secure By Default Configurations][control5], ref [Cheat Sheets][csproactive-c5] +* C6: [Keep your Components Secure][control6], ref [Cheat Sheets][csproactive-c6] +* C7: [Implement Digital Identity][control7], ref [Cheat Sheets][csproactive-c7] +* C8: [Leverage Browser Security Features][control8], ref [Cheat Sheets][csproactive-c8] +* C9: [Implement Security Logging and Monitoring][control9], ref [Cheat Sheets][csproactive-c9] +* C10: [Stop Server Side Request Forgery][control10], ref [Cheat Sheets][csproactive-c10] + +#### Why use them? + +The Proactive Controls are a well established list of security controls, first published in 2014 +and revised in 2018, so considering these controls can be seen as best practice. +Following best practice is always encouraged: at the very least an organization should avoid the avoidable exploits. + +Putting these proactive controls in place can help remediate common security vulnerabilities, for example: + +* [Clickjacking][csclick] +* [Credential Stuffing][cscreds] +* [Cross-site leaks][csxsleaks] +* [Denial of Service][csdos] (DoS) attacks +* DOM based [XSS attacks][csdom] including [DOM Clobbering][csdomclub] +* [IDOR][csidor] (Insecure Direct Object Reference) +* [Injection][csinjection] including [OS Command injection][csosinjection] and [XXE][csxxe] +* LDAP specific [injection attacks][csldap] +* [Prototype pollution][csproto] +* [SSRF][csssrf] attacks +* [SQL injection][cssql] and the use of [Query Parameterization][csquery] +* [Unvalidated redirects and forwards][csredirect] +* [XSS attacks][csxss] and [XSS Filter Evasion][csxssevade] + +#### How to apply them + +The OWASP Spotlight series provides an overview of how to use this documentation project: +'Project 8 - [Proactive Controls][spotlight08]'. + +During development of a web application, consider using each security control +described in the sections of the Proactive Controls that are relevant to the application. + +The OWASP Cheat Sheets have been indexed specifically for [each Proactive Control][csproactive], +which can be used as additional information on implementing the control. + +#### References + +* OWASP [Proactive Controls project][proactive10] +* OWASP Cheat Sheet [Proactive Controls index][csproactive] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue070101] or [edit on GitHub][edit070101]. + +[csclick]: https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet +[cscreds]: https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet +[csdom]: https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet +[csdomclub]: https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet +[csdos]: https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet +[csidor]: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet +[csinjection]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet +[csosinjection]: https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet +[csldap]: https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet +[csproto]: https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet +[csproactive]: https://cheatsheetseries.owasp.org/IndexProactiveControls +[csproactive-c1]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c1-define-security-requirements +[csproactive-c2]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c2-leverage-security-frameworks-and-libraries +[csproactive-c3]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c3-secure-database-access +[csproactive-c4]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c4-encode-and-escape-data +[csproactive-c5]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c5-validate-all-inputs +[csproactive-c6]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c6-implement-digital-identity +[csproactive-c7]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c7-enforce-access-controls +[csproactive-c8]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c8-protect-data-everywhere +[csproactive-c9]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c9-implement-security-logging-and-monitoring +[csproactive-c10]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html#c10-handle-all-errors-and-exceptions +[csredirect]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet +[cssql]: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet +[csquery]: https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet +[csssrf]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet +[csxss]: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet +[csxsleaks]: https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet +[csxssevade]: https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet +[csxxe]: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet +[control1]: https://top10proactive.owasp.org/the-top-10/c1-accesscontrol/ +[control2]: https://top10proactive.owasp.org/the-top-10/c2-crypto/ +[control3]: https://top10proactive.owasp.org/the-top-10/c3-validate-input-and-handle-exceptions/ +[control4]: https://top10proactive.owasp.org/the-top-10/c4-secure-architecture/ +[control5]: https://top10proactive.owasp.org/the-top-10/c5-secure-by-default/ +[control6]: https://top10proactive.owasp.org/the-top-10/c6-use-secure-dependencies/ +[control7]: https://top10proactive.owasp.org/the-top-10/c7-secure-digital-identities/ +[control8]: https://top10proactive.owasp.org/the-top-10/c8-help-the-browser-defend-the-user/ +[control9]: https://top10proactive.owasp.org/the-top-10/c9-security-logging-and-monitoring/ +[control10]: https://top10proactive.owasp.org/the-top-10/c10-stop-server-side-request-forgery/ +[edit070101]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/01-documentation/01-proactive-controls.md +[issue070101]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2007-implementation/01-documentation/01-proactive-controls +[proactive10]: https://top10proactive.owasp.org/ +[spotlight08]: https://youtu.be/HRtYDCWOSc0 diff --git a/release-ja/07-implementation/01-documentation/02-go-scp.md b/release-ja/07-implementation/01-documentation/02-go-scp.md new file mode 100644 index 00000000..e2b6121a --- /dev/null +++ b/release-ja/07-implementation/01-documentation/02-go-scp.md @@ -0,0 +1,76 @@ +--- + +title: Go Secure Coding Practices +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7120 +permalink: /release/implementation/documentation/go_scp/ + +--- + +{% include breadcrumb.html %} + +### 5.1.2 Go Secure Coding Practices + +The OWASP Go Secure Coding Practices (Go-SCP) is a set of software secure coding practices for the Go programming language. + +The Go-SCP [documentation project][go-scp-project] is an OWASP Incubator Project +that has enough long term support to achieve Lab status soon. +The published document can be [downloaded in various formats][go-scp-download] from the github repo. + +#### What is Go-SCP? + +Go-SCP provides examples and recommendations to help developers avoid common mistakes and pitfalls, +including code examples in Go that provide practical guidance on implementing the recommendations. +Go-SCP covers the OWASP [Secure Coding Practices Quick Reference Guide][scp-qrf] topic-by-topic: + +* Input Validation +* Sanitization Output Encoding +* Authentication and Password Management +* Session Management +* Access Control +* Cryptographic Practices +* Error Handling and Logging +* Data Protection +* Communication Security +* System Configuration +* Database Security +* File Management +* Memory Management +* General Coding Practices + +The [Go Secure Coding Practices][go-scp-project] book is available in various formats: + +* PDF +* ePub +* DocX +* MOBI + +#### Why use Go-SCP? + +Development teams often need help and support in getting the security right for web applications, +and part of this help comes from secure coding guidelines and best practices. +Go-SCP provides this guidance for a wide range of secure coding topics as well as providing practical code examples +for each coding practice. + +#### How to use Go-SCP? + +The primary audience of the Go Secure Coding Practices Guide is developers, +particularly those with previous experience in other programming languages. + +Download the [Go-SCP document][go-scp-download] in one of the formats: PDF, ePub, DocX and MOBI. +Refer to the specific topic chapter and then use the example Go code snippets +for practical guidance on secure coding using Go. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue070102] or [edit on GitHub][edit070102]. + +[edit070102]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/01-documentation/02-go-scp.md +[go-scp-download]: https://github.com/OWASP/Go-SCP/tree/master/dist +[go-scp-project]: https://owasp.org/www-project-go-secure-coding-practices-guide/ +[issue070102]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2007-implementation/01-documentation/02-go-scp +[scp-qrf]: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/ diff --git a/release-ja/07-implementation/01-documentation/03-cheatsheets.md b/release-ja/07-implementation/01-documentation/03-cheatsheets.md new file mode 100644 index 00000000..e1bfa543 --- /dev/null +++ b/release-ja/07-implementation/01-documentation/03-cheatsheets.md @@ -0,0 +1,95 @@ +--- + +title: Cheat Sheet Series +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7130 +permalink: /release/implementation/documentation/cheatsheets/ + +--- + +{% include breadcrumb.html %} + + + +![Cheat sheets logo](../../../../assets/images/logos/cheatsheets.png "OWASP Cheat Sheets"){: .image-right } + +### 5.1.3 Cheat Sheet Series + +The [OWASP Cheat Sheet Series][cheatsheets] provide a concise collection of high value information +on a wide range of specific application security topics. +The cheat sheets have been created by a community of application security professionals +who have expertise in each specific topic. + +The Cheat Sheet Series [documentation project][csproject] is an OWASP Flagship Project +which is constantly being kept up to date. + +#### What are the Cheat Sheets? + +The OWASP Cheat Sheets are a common body of knowledge created by the software security community +for a wide audience that is not confined to the security community. + +The Cheat Sheets are a series of self contained articles written by the security community +on a specific subject within the security domain. +The range of topics covered by the cheat sheets is wide, almost from A to Z: +from AJAX Security to XS (Cross Site) vulnerabilities. +Each cheat sheet provides an introduction to the subject and provides enough information to understand the basic concept. +It will then go on to describe its subject in more detail, often supplying recommendations or best practices. + +#### Why use them? + +The OWASP Cheat Sheet Series provide developers and security engineers with most, and perhaps all, +of the information on security topics that they will need to do their job. +In addition the Cheat Sheets are regarded as authoritative: it is recommended to follow the advice in these Cheat Sheets. +If a web application does not follow the recommendations in a cheat sheet, for example, +then the implementation could be challenged during testing or review processes. + +#### How to use them + +The OWASP Spotlight series provides a good overview of using this documentation: +'Project 4 - [Cheat Sheet Series][spotlight04]'. + +There are many cheat sheets in the OWASP Cheat Sheet Series; +91 of them as of March 2024 and this number is set to increase. +The OWASP community recognizes that this may become overwhelming at first, and so has arranged them in various ways: + +* [Alphabetically][cheatsheet-alpha] +* Indexed to follow the [ASVS project][csasvs] or the [MASVS project][csmasvs] +* Arranged in sections of the [OWASP Top 10][cstop10] or the [OWASP Proactive Controls][csproactive] + +The cheat sheets are continually being updated and are always open to contributions from the security community. + +#### References + +* OWASP [Cheat Sheet Series][cheatsheets] +* OWASP Cheat Sheet [ASVS index][csasvs] +* OWASP Cheat Sheet [MASVS index][csmasvs] +* OWASP Cheat Sheet [Proactive Controls index][csproactive] +* OWASP Cheat Sheet [Top 10 index][cstop10] +* OWASP [Cheat Sheet project][csproject] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue070103] or [edit on GitHub][edit070103]. + +[csproject]: https://owasp.org/www-project-cheat-sheets/ +[cheatsheets]: https://cheatsheetseries.owasp.org/ +[cheatsheet-alpha]: https://cheatsheetseries.owasp.org/Glossary +[csasvs]: https://cheatsheetseries.owasp.org/IndexASVS +[csmasvs]: https://cheatsheetseries.owasp.org/IndexMASVS.html +[csproactive]: https://cheatsheetseries.owasp.org/IndexProactiveControls.html +[cstop10]: https://cheatsheetseries.owasp.org/IndexTopTen.html +[edit070103]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/01-documentation/03-cheatsheets.md +[issue070103]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2007-implementation/01-documentation/03-cheatsheets +[spotlight04]: https://youtu.be/S1cVYRDeiPQ diff --git a/release-ja/07-implementation/01-documentation/info.md b/release-ja/07-implementation/01-documentation/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/07-implementation/01-documentation/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/07-implementation/01-documentation/toc.md b/release-ja/07-implementation/01-documentation/toc.md new file mode 100644 index 00000000..5fefba9e --- /dev/null +++ b/release-ja/07-implementation/01-documentation/toc.md @@ -0,0 +1,52 @@ +--- + +title: Implementation Documentation +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7100 +permalink: /release/implementation/documentation/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 5.1 Documentation + +Documentation is used here as part of the SAMM [Training and Awareness][sammgegta] activity, +which in turn is part of the SAMM [Education & Guidance][sammgeg] security practice +within the [Governance][sammg] business function. + +It is important that development teams have good documentation on security techniques, frameworks, tools and threats. +Documentation helps to promote security awareness for all teams involved in software development, +and provides guidance on building security into applications and systems. + +Sections: + +5.1.1 [Top 10 Proactive Controls](01-proactive-controls.md) +5.1.2 [Go Secure Coding Practices](02-go-scp.md) +5.1.3 [Cheatsheet Series](03-cheatsheets.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0710] or [edit on GitHub][edit0710]. + +[edit0710]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/01-documentation/toc.md +[issue0710]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2007-implementation/01-documentation/00-toc +[sammg]: https://owaspsamm.org/model/governance/ +[sammgeg]: https://owaspsamm.org/model/governance/education-and-guidance/ +[sammgegta]: https://owaspsamm.org/model/governance/education-and-guidance/stream-a/ diff --git a/release-ja/07-implementation/02-dependencies/00-toc.md b/release-ja/07-implementation/02-dependencies/00-toc.md new file mode 100644 index 00000000..abb38094 --- /dev/null +++ b/release-ja/07-implementation/02-dependencies/00-toc.md @@ -0,0 +1,51 @@ +--- + +title: Implementation Dependencies +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 5.2 Dependencies + +Management of software dependencies is described by the SAMM [Software Dependencies][sammisbsd] activity, +which in turn is part of the SAMM [Secure Build][sammisb] security practice +within the [Implementation][sammi] business function. + +It is important to record all dependencies used throughout the application in a production environment. +This can be achieved by Software Composition Analysis (SCA) to identify the third party dependencies. + +A Software Bill of Materials (SBOM) provides a record of the dependencies within the system / application, +and provides information on each dependency so that it can be tracked : + +* Where it is used or referenced +* Version used +* License +* Source information and repository +* Support and maintenance status of the dependency + +Having an SBOM provides the ability to quickly find out which applications are affected by a specific +[Common Vulnerability and Exposure][cve] (CVE), or what CVEs are present in a particular application. + +Sections: + +5.2.1 [Dependency-Check](#dependency-check) +5.2.2 [Dependency-Track](#dependency-track) +5.2.3 [CycloneDX](#cyclonedx) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0720]. + +[cve]: https://cve.mitre.org/ +[issue0720]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2007-implementation/02-dependencies/00-toc +[sammi]: https://owaspsamm.org/model/implementation/ +[sammisb]: https://owaspsamm.org/model/implementation/secure-build/ +[sammisbsd]: https://owaspsamm.org/model/implementation/secure-build/stream-b/ diff --git a/release-ja/07-implementation/02-dependencies/01-dependency-check.md b/release-ja/07-implementation/02-dependencies/01-dependency-check.md new file mode 100644 index 00000000..e7f7cc2d --- /dev/null +++ b/release-ja/07-implementation/02-dependencies/01-dependency-check.md @@ -0,0 +1,97 @@ +--- + +title: Dependency-Check +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7210 +permalink: /release/implementation/dependencies/dependency_check/ + +--- + +{% include breadcrumb.html %} + +![DepCheck logo](../../../../assets/images/logos/depcheck.png "OWASP Dependency-Check"){: height="150px" } + +### 5.2.1 Dependency-Check + +OWASP [Dependency-Check][depcheck] is a tool that provides Software Composition Analysis (SCA) from the command line. +It identifies the third party libraries in a web application project +and checks if these libraries are vulnerable using the [NVD database][nist-db]. + +Dependency-Check is an OWASP Flagship project and can be downloaded from the [github releases][depcheck-download] area. +Dependency-Check was started in September 2012 and since then has been continuously supported with regular releases. + +#### What is Dependency-Check? + +Dependency-Check is a Software Composition Analysis (SCA) tool that attempts to detect +publicly disclosed vulnerabilities contained within a project’s dependencies. +It does this by determining if there is a [Common Platform Enumeration][cpe] (CPE) identifier for a given dependency. + +The core engine contains a series of analyzers that inspect the project dependencies +and identify the CPE for the given dependency. +If a CPE is identified then it is cross referenced to the [NIST CVE database][nist-db] +and any associated [Common Vulnerability and Exposure][cve] (CVE) entries are listed in the report. + +Dependency-Check's core analysis engine can be used as: + +* an Ant Task +* a Command Line Tool +* Gradle Plugin +* Jenkins Plugin +* Maven Plugin +* SBT Plugin + +#### Why use it? + +Checking for vulnerable components, '[A06 Vulnerable and Outdated Components][a06]', is in the OWASP Top Ten +and is one of the most straight-forward and effective security activities to implement. +The Dependency-Check tool provides checks for vulnerable components that can be run from the command line. + +This is useful for development teams; the ability to check for vulnerable application components from the command line +gives immediate feedback to the developer without having to wait for a pipeline to run. + +Dependency-Check also provides plugins to check for vulnerable components for [CI/CD pipelines][cscicd]. + +#### How to use it + +The OWASP Spotlight series provides an example of the risks involved in using out of date and vulnerable libraries, +and how to use Dependency-Check: 'Project 2 - [OWASP Dependency Check][spotlight02]'. + +Refer to the Dependency-Check [documentation][depcheck-docs] to get started running from the command line: + +* ensure Java is installed, for example from [Eclipse Adoptium][adoptium] +* download and unzip the latest Dependency-Check [release][depcheck-download] +* navigate to the Dependency-Check 'bin' directory and run, using threat Dragon as an example: + `./dependency-check.sh --project "Threat Dragon" --scan ~/github/threat-dragon` +* open the html output file and act on the findings + +The command line is useful for immediate debugging development. +Depending on what automation environment is in place a plugin can also be installed +into a pipeline which can then generate the SCA reports. + +#### References + +* OWASP [Dependency-Check][depcheck] project +* OWASP [Dependency-Check][depcheck-docs] documentation +* OWASP [CI/CD Security Cheat Sheet][cscicd] +* OWASP [Top 10][a06] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue070201] or [edit on GitHub][edit070201]. + +[a06]: https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/ +[adoptium]: https://adoptium.net/ +[cpe]: https://nvd.nist.gov/products/cpe +[cscicd]: https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet +[cve]: https://cve.mitre.org/ +[depcheck]: https://owasp.org/www-project-dependency-check/ +[depcheck-docs]: https://jeremylong.github.io/DependencyCheck/ +[depcheck-download]: https://github.com/jeremylong/DependencyCheck/releases +[edit070201]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/02-dependencies/01-dependency-check.md +[issue070201]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2007-implementation/02-dependencies/01-dependency-check +[nist-db]: https://nvd.nist.gov/ +[spotlight02]: https://youtu.be/YAXf3TaAYeA diff --git a/release-ja/07-implementation/02-dependencies/02-dependency-track.md b/release-ja/07-implementation/02-dependencies/02-dependency-track.md new file mode 100644 index 00000000..aa17b13e --- /dev/null +++ b/release-ja/07-implementation/02-dependencies/02-dependency-track.md @@ -0,0 +1,77 @@ +--- + +title: Dependency-Track +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7220 +permalink: /release/implementation/dependencies/dependency_track/ + +--- + +{% include breadcrumb.html %} + +### 5.2.2 Dependency-Track + +OWASP Dependency-Track is an intelligent platform for Component Analysis including Third Party Software. +It allows organizations to identify and reduce risk in the [software supply chain][cschain] +using its ability to analyze a Software Bill of Materials (SBOM). + +The [Dependency-Track][deptrack-project] is an OWASP Flagship project +and can be installed using a docker-compose file from the Dependency-Track [website][deptrack]. + +#### What is Dependency-Track? + +The [Dependency-Track][deptrack] tool provides an organization with a dashboard to analyze, oversee +and control the components for all of its projects. +It tracks component usage across every application in an organizations portfolio by analyzing exports +from multiple projects within the organization, via CycloneDX SBOMs and Vulnerability Exploitability Exchange. + +It provides full-stack support for all types of component, including hardware and services. +Dependency-Track identifies multiple forms of risk, including components with known vulnerabilities, +by integrating with multiple sources of vulnerability intelligence such as the +National Vulnerability Database (NVD), GitHub advisories and others. + +It has built-in repository support for various repository types, +and will provide risk and compliance for security, risk and operations. +See the [Documentation][deptrack-docs] for more information on the features provided by Dependency-Track. + +#### Why use it? + +By leveraging the capabilities of Software Bill of Materials (SBOM), Dependency-Track provides capabilities +that traditional Software Composition Analysis (SCA) solutions are unlikely to achieve. + +The Dependency-Track dashboard has the ability to analyze all software projects within an organization. +It integrates with numerous notification platforms, for example Slack and Microsoft Teams, and can feed results +to various vulnerability aggregator tools such as DefectDojo or Fortify. + +Dependency-Track is feature rich, it provides integrations and features that most organizations will need; +see the [Documentation Introduction][deptrack-docs] for a full list of these features. + +#### How to use it + +The OWASP Spotlight series provides an overview of tracking dependencies and inspecting SBOMs using Dependency-Track: +'Project 15 - [OWASP Dependency-Track][spotlight15]'. + +Follow the [getting started guide][deptrack-docs] to install the Dependency-Track tool, +using the recommended deployment of a Docker container. + +Although Dependency-Track will run with its default configuration +it should should be configured for the organization's specific needs. +The Dependency-Track configuration file is important for optimally running the tool +but this is outside the scope of the Developer Guide - see the Dependency-Track [documentation][deptrack-docs] +for a step by step guide to this configuration process. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue070202] or [edit on GitHub][edit070202]. + +[cschain]: https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet +[deptrack]: https://dependencytrack.org/ +[deptrack-docs]: https://docs.dependencytrack.org/ +[deptrack-project]: https://owasp.org/www-project-dependency-track/ +[edit070202]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/02-dependencies/02-dependency-track.md +[issue070202]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2007-implementation/02-dependencies/02-dependency-track +[spotlight15]: https://youtu.be/irnZuLq4MDM diff --git a/release-ja/07-implementation/02-dependencies/03-cyclonedx.md b/release-ja/07-implementation/02-dependencies/03-cyclonedx.md new file mode 100644 index 00000000..136968c7 --- /dev/null +++ b/release-ja/07-implementation/02-dependencies/03-cyclonedx.md @@ -0,0 +1,103 @@ +--- + +title: CycloneDX +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7230 +permalink: /release/implementation/dependencies/cyclonedx/ + +--- + +{% include breadcrumb.html %} + + + +### 5.2.3 CycloneDX + +![CycloneDX logo](../../../../assets/images/logos/cyclonedx.png "OWASP CycloneDX"){: .image-right } + +OWASP [CycloneDX][cyclonedx] is a full-stack Bill of Materials (BOM) standard +that provides advanced supply chain capabilities for cyber risk reduction. +This [project][cyclonedx-project] is one of the OWASP flagship projects. + +#### What is CycloneDX? + +CycloneDX is a widely used standard for various types of [Bills of Materials][cyclonedx-spec]. +It provides an organization's [supply chain][cschain] with software security risk reduction. +The specification supports: + +* [Software Bill of Materials][cyclonedx-sbom] (SBOM) +* [Software-as-a-Service Bill of Materials][cyclonedx-saasbom] (SaaSBOM) +* [Hardware Bill of Materials][cyclonedx-hbom] (HBOM) +* [Machine-learning Bill of Materials][cyclonedx-mlbom] (ML-BOM) +* [Manufacturing Bill of Materials][cyclonedx-mbom] (MBOM) +* [Operations Bill of Materials][cyclonedx-obom] (OBOM) +* [Bill of Vulnerabilities][cyclonedx-bov] (BOV) +* [Vulnerability Disclosure Reports][cyclonedx-vdr] (VDR) +* [Vulnerability Exploitability eXchange][cyclonedx-vex] (VEX) +* Common [Release Notes][cyclonedx-notes] format +* Syntax for [Bill of Materials linkage][cyclonedx-bomlink] (BOM-Link) + +The CycloneDX project provides standards in XML, JSON, and Protocol Buffers. +There is a large collection of official and community supported tools that consume and create CycloneDX BOMs +or interoperate with the CycloneDX standard. + +#### Why use it? + +CycloneDX is a very well established standard for SBOMs and various other types of BOM. +There is a huge ecosystem built around CycloneDX and it is used globally by many companies. +In addition SBOMs are mandatory for many industries and various governments - at some point every organization +will have to provide SBOMs for their customers and CycloneDX is an accepted standard for this. + +CycloneDX also provides standards for other types of BOMs that may be required in the supply chain +along with standards for release notes and [responsible disclosure][csdisclose]. +It is useful to use CycloneDX throughout the supply chain as it promotes interoperability between the various tools. + +#### How to use it + +The OWASP Spotlight series provides an overview of CycloneDX along with the a demonstration of using SBOMs: +'Project 21 - [OWASP CycloneDX][spotlight21]'. + +CycloneDX is an easy to understand standard that can be augmented to suit all parts of a supply chain, +and there are [many tools][cyclonedx-tools] (more than 220 as of February 2024) that interoperate with CycloneDX. + +The easiest way to use CycloneDX is to select tools from this list for any of the supported BOM types, +with both proprietary/commercial and open source tools included in the list. +A common example is for a customer to request that an SBOM is provided for a web application, +and [various tools][cyclonedx-tools] can be chosen that are able to export the SBOM in various formats. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue070203] or [edit on GitHub][edit070203]. + +[cschain]: https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet +[csdisclose]: https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet +[cyclonedx]: https://cyclonedx.org/ +[cyclonedx-bomlink]: https://cyclonedx.org/capabilities/bomlink/ +[cyclonedx-bov]: https://cyclonedx.org/capabilities/bov/ +[cyclonedx-hbom]: https://cyclonedx.org/capabilities/hbom/ +[cyclonedx-mbom]: https://cyclonedx.org/capabilities/mbom/ +[cyclonedx-mlbom]: https://cyclonedx.org/capabilities/mlbom/ +[cyclonedx-notes]: https://cyclonedx.org/capabilities/release-notes/ +[cyclonedx-obom]: https://cyclonedx.org/capabilities/obom/ +[cyclonedx-project]: https://owasp.org/www-project-cyclonedx/ +[cyclonedx-saasbom]: https://cyclonedx.org/capabilities/saasbom/ +[cyclonedx-sbom]: https://cyclonedx.org/capabilities/sbom/ +[cyclonedx-spec]: https://cyclonedx.org/specification/overview/ +[cyclonedx-tools]: https://cyclonedx.org/tool-center/ +[cyclonedx-vdr]: https://cyclonedx.org/capabilities/vdr/ +[cyclonedx-vex]: https://cyclonedx.org/capabilities/vex/ +[edit070203]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/02-dependencies/03-cyclonedx.md +[issue070203]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2007-implementation/02-dependencies/03-cyclonedx +[spotlight21]: https://youtu.be/qEG6cxwl8os diff --git a/release-ja/07-implementation/02-dependencies/info.md b/release-ja/07-implementation/02-dependencies/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/07-implementation/02-dependencies/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/07-implementation/02-dependencies/toc.md b/release-ja/07-implementation/02-dependencies/toc.md new file mode 100644 index 00000000..202a6a28 --- /dev/null +++ b/release-ja/07-implementation/02-dependencies/toc.md @@ -0,0 +1,64 @@ +--- + +title: Implementation Dependencies +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7200 +permalink: /release/implementation/dependencies/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 5.2 Dependencies + +Management of software dependencies is described by the SAMM [Software Dependencies][sammisbsd] activity, +which in turn is part of the SAMM [Secure Build][sammisb] security practice +within the [Implementation][sammi] business function. + +It is important to record all dependencies used throughout the application in a production environment. +This can be achieved by Software Composition Analysis (SCA) to identify the third party dependencies. + +A Software Bill of Materials (SBOM) provides a record of the dependencies within the system / application, +and provides information on each dependency so that it can be tracked : + +* Where it is used or referenced +* Version used +* License +* Source information and repository +* Support and maintenance status of the dependency + +Having an SBOM provides the ability to quickly find out which applications are affected by a specific +[Common Vulnerability and Exposure][cve] (CVE), or what CVEs are present in a particular application. + +Sections: + +5.2.1 [Dependency-Check](01-dependency-check.md) +5.2.2 [Dependency-Track](02-dependency-track.md) +5.2.3 [CycloneDX](03-cyclonedx.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0720] or [edit on GitHub][edit0702]. + +[cve]: https://cve.mitre.org/ +[edit0702]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/02-dependencies/toc.md +[issue0720]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2007-implementation/02-dependencies/00-toc +[sammi]: https://owaspsamm.org/model/implementation/ +[sammisb]: https://owaspsamm.org/model/implementation/secure-build/ +[sammisbsd]: https://owaspsamm.org/model/implementation/secure-build/stream-b/ diff --git a/release-ja/07-implementation/03-secure-libraries/00-toc.md b/release-ja/07-implementation/03-secure-libraries/00-toc.md new file mode 100644 index 00000000..11ae1c9c --- /dev/null +++ b/release-ja/07-implementation/03-secure-libraries/00-toc.md @@ -0,0 +1,39 @@ +--- + +title: Implementation Secure Libraries +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 5.3 Secure libraries + +The use of secure libraries is part of the technology management that helps to fulfill security requirements. +Standard libraries enable the adoption of common design patterns and security solutions, +and provide standardized technologies and frameworks that can be used throughout different applications. + +[Technology Management][sammdsatm] for the software applications is described by SAMM as an activity +within the SAMM [Security Architecture][sammdsa] security practice +which in turn is part of the [Design][sammd] business function. + +Sections: + +5.3.1 [ESAPI](#esapi) +5.3.2 [CSRFGuard](#csrfguard) +5.3.3 [OSHP](#oshp) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0703]. + +[issue0703]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2007-implementation/03-secure-libraries/00-toc +[sammd]: https://owaspsamm.org/model/design/ +[sammdsa]: https://owaspsamm.org/model/design/secure-architecture/ +[sammdsatm]: https://owaspsamm.org/model/design/secure-architecture/stream-b/ diff --git a/release-ja/07-implementation/03-secure-libraries/01-esapi.md b/release-ja/07-implementation/03-secure-libraries/01-esapi.md new file mode 100644 index 00000000..f83d001d --- /dev/null +++ b/release-ja/07-implementation/03-secure-libraries/01-esapi.md @@ -0,0 +1,96 @@ +--- + +title: ESAPI +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7310 +permalink: /release/implementation/secure_libraries/esapi/ + +--- + +{% include breadcrumb.html %} + + + +![ESAPI logo](../../../../assets/images/logos/esapi.png "OWASP ESAPI"){: .image-right } + +### 5.3.1 ESAPI + +The OWASP Enterprise Security API (ESAPI) [library][esapi-docs] is a security control library +for web applications written in Java. + +The [ESAPI library][esapi-project] is an OWASP Lab project that is under active development +for [Java security controls][esapi-java] with regular releases. + +#### What is the ESAPI library? + +The OWASP Enterprise Security API (ESAPI) [library][esapi-docs] provides a set of security control interfaces +which define types of parameters that are passed to the security controls. + +The ESAPI is an open source web application security control library +that makes it easier for Java programmers to write lower-risk applications. +The ESAPI Java library is designed to help programmers retrofit security into existing Java applications, +and the library also serves as a solid foundation for new development. + +#### Why use it? + +The use of the ESAPI Java library is not easy to justify, although its use should certainly be considered. +The engineering decisions a development team will need to make when using ESAPI are discussed in the +'[Should I use ESAPI?][esapi-question]' documentation. + +For new projects or for modifying an existing project then alternatives should be strongly considered: + +* Output encoding: OWASP [Java Encoder][java-encoder] project +* General HTML sanitization: OWASP [Java HTML Sanitizer][java-sanitizer] +* Validation: [JSR-303/JSR-349 Bean Validation][bean] +* Strong cryptography: Google [Tink][google-tink] or [Keyczar][google-keyczar] +* Authentication & authorization: [Apache Shiro][shiro], authentication using [Spring Security][spring] +* [CSRF][cscsrf] protection: OWASP [CSRFGuard][csrfguard] project + +Consideration could be given for using ESAPI if multiple security controls provided by this library are used in a project, +it then may be useful to use the monolithic ESAPI library rather than multiple disparate class libraries. + +#### How to use it + +If the engineering decision is to use the ESAPI library then it can be downloaded as a Java Archive (.jar) package file. +There is a reference implementation for each security control. + +#### References + +* [ESAPI for Java][esapi-java] +* ESAPI [documentation][esapi-docs] +* ESAPI [project][esapi-project] +* OWASP [Java Encoder][java-encoder] project +* OWASP [Java HTML Sanitizer][java-sanitizer] +* [Spring Security][spring] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue070301] or [edit on GitHub][edit070301]. + +[bean]: http://beanvalidation.org/ +[csrfguard]: https://owasp.org/www-project-csrfguard/ +[cscsrf]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet +[edit070301]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/03-secure-libraries/01-esapi.md +[esapi-docs]: https://www.javadoc.io/doc/org.owasp.esapi/esapi/latest/index.html +[esapi-java]: https://mvnrepository.com/artifact/org.owasp.esapi/esapi +[esapi-project]: https://owasp.org/www-project-enterprise-security-api/ +[esapi-question]: https://owasp.org/www-project-enterprise-security-api/#div-shouldiuseesapi +[google-keyczar]: https://github.com/google/keyczar +[google-tink]: https://github.com/google/tink +[issue070301]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2007-implementation/03-secure-libraries/01-esapi +[java-encoder]: https://owasp.org/www-project-java-encoder +[java-sanitizer]: https://owasp.org/www-project-java-html-sanitizer +[shiro]: https://shiro.apache.org/ +[spring]: https://docs.spring.io/spring-security/reference/features/index.html diff --git a/release-ja/07-implementation/03-secure-libraries/02-csrf-guard.md b/release-ja/07-implementation/03-secure-libraries/02-csrf-guard.md new file mode 100644 index 00000000..1fe5a313 --- /dev/null +++ b/release-ja/07-implementation/03-secure-libraries/02-csrf-guard.md @@ -0,0 +1,60 @@ +--- + +title: CSRFGuard +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7320 +permalink: /release/implementation/secure_libraries/csrfguard/ + +--- + +{% include breadcrumb.html %} + +### 5.3.2 CSRFGuard + +OWASP [CSRFGuard][csrfguard] is a security control that helps protect Java applications +against [Cross-Site Request Forgery][cscsrf] (CSRF) attacks. + +The CSRFGuard Builder/Breaker Tool project is an OWASP Production Project +and is being actively maintained by a pool of international volunteers. + +#### What is CSRFGuard? + +OWASP [CSRFGuard][csrfguard] is a library that implements a variant of the synchronizer token pattern to mitigate +the risk of Cross-Site Request Forgery (CSRF) attacks for Java applications. + +The OWASP CSRFGuard library is integrated through the use of a JavaEE Filter and exposes various automated +and manual ways to integrate per-session or pseudo-per-request tokens into HTML. +When a user interacts with this HTML, CSRF prevention tokens are submitted with the corresponding HTTP request. +CSRFGuard ensures the token is present and is valid for the current HTTP request. + +#### Why use it? + +The OWASP CSRFGuard library is widely used for Java applications, and will help mitigate against CSRF. + +#### How to use it + +Pre-compiled versions of the CSRFGuard library can be downloaded from +the [Maven Central repository][csrfguard-maven] or the [OSS Sonatype Nexus][csrfguard-nexus] repository. + +Follow the [instructions][csrfguard-build] to build CSRFGuard into the Java application using Maven. + +#### References + +* OWASP [CSRFGuard][csrfguard] +* OWASP [Cross-Site Request Forgery Prevention Cheat Sheet][cscsrf] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue070302] or [edit on GitHub][edit070302]. + +[csrfguard]: https://owasp.org/www-project-csrfguard/ +[csrfguard-build]: https://github.com/OWASP/www-project-csrfguard/blob/master/readme.md#using-with-maven +[csrfguard-nexus]: https://oss.sonatype.org/#nexus-search;gav~~csrfguard~~~ +[csrfguard-maven]: https://central.sonatype.com/search?q=csrfguard&smo=true +[cscsrf]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet +[edit070302]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/03-secure-libraries/02-csrf-guard.md +[issue070302]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2007-implementation/03-secure-libraries/02-csrf-guard diff --git a/release-ja/07-implementation/03-secure-libraries/03-secure-headers.md b/release-ja/07-implementation/03-secure-libraries/03-secure-headers.md new file mode 100644 index 00000000..7aa117b6 --- /dev/null +++ b/release-ja/07-implementation/03-secure-libraries/03-secure-headers.md @@ -0,0 +1,73 @@ +--- + +title: OWASP Secure Headers Project +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7330 +permalink: /release/implementation/secure_libraries/oshp/ + +--- + +{% include breadcrumb.html %} + + + +![Secure Headers logo](../../../../assets/images/logos/secure_headers.png "OWASP Secure Headers"){: .image-right } + +### 5.3.3 OSHP + +The OWASP Secure Headers Project ([OSHP][oshp]) provides information on HTTP response headers +to increase the security of a web application. + +The OSHP documentation project is an OWASP Lab Project and raises awareness of secure headers and their use. + +#### What is OSHP? + +The [OSHP project][oshp]) provides explanations for the HTTP response headers that an application can use +to increase the security of the application. +Once set the HTTP response headers can restrict modern browsers from running into easily preventable vulnerabilities. + +OSHP contains guidance and downloads on: + +* Response headers explanations and usage +* Links to individual browser support +* Guidance and best practices +* Technical resources in the form of tools and documents +* Code snippets to help working with HTTP security headers + +#### Why use it? + +The OSHP is a documentation project that explains the reasoning and usage of HTTP response headers. +It is the go-to document for guidance and best practices; +the information on HTTP response headers is the best advice, in one location, and is kept up to date. + +#### How to use it + +The OWASP Spotlight series provides an overview of this project and its uses: +'Project 24 - [OWASP Security Headers Project][spotlight24]'. + +OSHP provides links to development [libraries][oshp-libs] that provide for secure HTTP response headers +in a range of languages and frameworks: DotNet, Go, HAPI, Java, NodeJS, PHP, Python, Ruby, Rust. +The OSHP also lists [various tools][oshp-tools] useful for inspection, analysis and scanning of HTTP response headers. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue070303] or [edit on GitHub][edit070303]. + +[edit070303]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/03-secure-libraries/03-secure-headers.md +[issue070303]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2007-implementation/03-secure-libraries/03-secure-headers +[oshp]: https://owasp.org/www-project-secure-headers/ +[oshp-libs]: https://owasp.org/www-project-secure-headers/#development-libraries +[oshp-tools]: https://owasp.org/www-project-secure-headers/#analysis-tools +[spotlight24]: https://youtu.be/N4F3VWQYU9E diff --git a/release-ja/07-implementation/03-secure-libraries/info.md b/release-ja/07-implementation/03-secure-libraries/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/07-implementation/03-secure-libraries/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/07-implementation/03-secure-libraries/toc.md b/release-ja/07-implementation/03-secure-libraries/toc.md new file mode 100644 index 00000000..b57b5e75 --- /dev/null +++ b/release-ja/07-implementation/03-secure-libraries/toc.md @@ -0,0 +1,52 @@ +--- + +title: Implementation Secure Libraries +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7300 +permalink: /release/implementation/secure_libraries/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 5.3 Secure libraries + +The use of secure libraries is part of the technology management that helps to fulfill security requirements. +Standard libraries enable the adoption of common design patterns and security solutions, +and provide standardized technologies and frameworks that can be used throughout different applications. + +[Technology Management][sammdsatm] for the software applications is described by SAMM as an activity +within the SAMM [Security Architecture][sammdsa] security practice +which in turn is part of the [Design][sammd] business function. + +Sections: + +5.3.1 [ESAPI](01-esapi.md) +5.3.2 [CSRFGuard](02-csrf-guard.md) +5.3.3 [OSHP](03-secure-headers.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0703] or [edit on GitHub][edit0703]. + +[edit0703]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/03-secure-libraries/toc.md +[issue0703]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2007-implementation/03-secure-libraries/00-toc +[sammd]: https://owaspsamm.org/model/design/ +[sammdsa]: https://owaspsamm.org/model/design/secure-architecture/ +[sammdsatm]: https://owaspsamm.org/model/design/secure-architecture/stream-b/ diff --git a/release-ja/07-implementation/04-maswe.md b/release-ja/07-implementation/04-maswe.md new file mode 100644 index 00000000..9b60af16 --- /dev/null +++ b/release-ja/07-implementation/04-maswe.md @@ -0,0 +1,97 @@ +--- + +title: MAS Weakness Enumeration +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7400 +permalink: /release/implementation/maswe/ + +--- + +{% include breadcrumb.html %} + + + +![MAS checklist logo](../../../assets/images/logos/mas.png "OWASP MASWE"){: .image-right } + +### 5.4 MASWE + +The OWASP [Mobile Application Security][masproject] (MAS) flagship project provides +industry standards for mobile application security. + +The OWASP [MASWE][maswe] project is one of the tools provided by MAS, +and provides a list of weaknesses that have been found in various mobile applications. + +#### What is the MASWE? + +The MAS [Weakness Enumeration][maswe] lists weaknesses, and therefore potential vulnerabilities, +that have been found in various mobile applications over time. + +The MASWE is split out into weakness categories that correspond to the [MASVS][masvs] verification categories: + +* [MASVS-STORAGE](https://mas.owasp.org/MASWE/MASVS-STORAGE/MASWE-0001/) sensitive data storage +* [MASVS-CRYPTO](https://mas.owasp.org/MASWE/MASVS-CRYPTO/MASWE-0009/) cryptography best practices +* [MASVS-AUTH](https://mas.owasp.org/MASWE/MASVS-AUTH/MASWE-0028/) authentication and authorization mechanisms +* [MASVS-NETWORK](https://mas.owasp.org/MASWE/MASVS-NETWORK/MASWE-0047/) network communications +* [MASVS-PLATFORM](https://mas.owasp.org/MASWE/MASVS-PLATFORM/MASWE-0053/) interactions with the mobile platform +* [MASVS-CODE](https://mas.owasp.org/MASWE/MASVS-CODE/MASWE-0075/) platform and third-party software +* [MASVS-RESILIENCE](https://mas.owasp.org/MASWE/MASVS-RESILIENCE/MASWE-0089/) integrity and running on a trusted platform +* [MASVS-PRIVACY](https://mas.owasp.org/MASWE/MASVS-PRIVACY/MASWE-0108/) privacy of users, data and resources + +#### Why use it? + +Although the MASWE is a relatively new project from 2024, it already provides a common language +when discussing and categorizing weaknesses found in mobile applications. +It also provides a list of potential vulnerabilities that should be considered during the design lifecycle +and when creating or revising security requirements for mobile applications. + +The MASWE is a valuable list of what can go wrong with mobile applications along with the activities of malicious actors. + +#### How to use it + +The Common Weakness Enumeration ([CWE][cwe]), published by MITRE, can be used by security architects +so they are aware of what weaknesses and potential vulnerabilities that could be present in an application. +Development teams can use the CWE as a reference to these weaknesses and to help understanding of any mitigations. +These are just two examples of how the CWE is widely used. + +In a similar way the MASWE can be used in the development of mobile applications : + +* inform development teams of specific weaknesses +* identification of security requirements +* used as a training aid +* provide categorization of weaknesses + +This list is just a starting point; there are many uses for the MASWE. + +#### References + +* Mobile Application Security ([MAS][masproject]) project +* MAS Weakness Enumeration ([MASWE][maswe]) +* MITRE Common Weakness Enumeration ([CWE][cwe]) +* MAS Verification Standard ([MASVS][masvs]) +* MAS [Checklist][masc] +* MAS Testing Guide ([MASTG][mastg]) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0704] or [edit on GitHub][edit0704]. + +[cwe]: https://cwe.mitre.org/ +[edit0704]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/04-maswe.md +[issue0704]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2007-implementation/04-maswe +[masproject]: https://owasp.org/www-project-mobile-app-security/ +[masc]: https://mas.owasp.org/checklists/ +[mastg]: https://mas.owasp.org/MASTG/ +[maswe]: https://mas.owasp.org/MASWE/ +[masvs]: https://mas.owasp.org/MASVS/ diff --git a/release-ja/07-implementation/info.md b/release-ja/07-implementation/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/07-implementation/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/07-implementation/toc.md b/release-ja/07-implementation/toc.md new file mode 100644 index 00000000..8f598ca3 --- /dev/null +++ b/release-ja/07-implementation/toc.md @@ -0,0 +1,75 @@ +--- + +title: Implementation +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 7000 +permalink: /release/implementation/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){: .image-right } + +## 5. Implementation + +The [Implementation][sammi] business function is described by the OWASP [Software Assurance Maturity Model][sammm] (SAMM). +Implementation is focused on the processes and activities related to how an organization +builds and deploys software components and its related defects. +Implementation activities have the most impact on the daily life of developers, +and an important goal of Implementation is to ship reliably working software with minimum defects. + +Implementation should include security practices such as : + +* Secure Build +* Secure Deployment +* Defect Management + +Implementation is where the application / system begins to take shape; source code is written and tests are created. +The implementation of the application follows a secure development lifecycle, with security built in from the start. + +The implementation will use a secure method of source code control and storage to fulfill the design security requirements. +The development team will be referring to documentation advising them of best practices, +they will be using secure libraries wherever possible in addition to checking and tracking external dependencies. + +Much of the skill of implementation comes from experience, and taking into account the Do's and Don'ts +of secure development is an important knowledge activity in itself. + +Sections: + +5.1 [Documentation](01-documentation/toc.md) +5.1.1 [Top 10 Proactive Controls](01-documentation/01-proactive-controls.md) +5.1.2 [Go Secure Coding Practices](01-documentation/02-go-scp.md) +5.1.3 [Cheatsheet Series](01-documentation/03-cheatsheets.md) +5.2 [Dependencies](02-dependencies/toc.md) +5.2.1 [Dependency-Check](02-dependencies/01-dependency-check.md) +5.2.2 [Dependency-Track](02-dependencies/02-dependency-track.md) +5.2.3 [CycloneDX](02-dependencies/03-cyclonedx.md) +5.3 [Secure Libraries](03-secure-libraries/toc.md) +5.3.1 [ESAPI](03-secure-libraries/01-esapi.md) +5.3.2 [CSRFGuard](03-secure-libraries/02-csrf-guard.md) +5.3.3 [OSHP](03-secure-libraries/03-secure-headers.md) +5.4 [MASWE](04-maswe.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0700] or [edit on GitHub][edit0700]. + +[edit0700]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/07-implementation/toc.md +[issue0700]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2007-implementation/00-toc +[sammm]: https://owaspsamm.org/model/ +[sammi]: https://owaspsamm.org/model/implementation/ diff --git a/release-ja/08-verification/00-toc.md b/release-ja/08-verification/00-toc.md new file mode 100644 index 00000000..6bb60e55 --- /dev/null +++ b/release-ja/08-verification/00-toc.md @@ -0,0 +1,67 @@ +--- + +title: Verification +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){height=180px} + +## 6. Verification + +[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm]. + +Verification focuses on the processes and activities related to how an organization checks +and tests artifacts produced throughout software development. +This typically includes quality assurance work such as testing, and also includes other review and evaluation activities. + +Verification activities should include: + +* Architecture assessment, validation and mitigation +* Requirements-driven testing +* Security control verification and misuse/abuse testing +* Automated security testing and baselining +* Manual security testing and penetration testing + +These activities are supported by: + +* Security guides +* Test tools +* Test frameworks +* Vulnerability management +* Checklists + +Verification is an activity central to the secure software development lifecycle. +Refer to the [Security Culture][culturetest] project section for the various types of security testing. + +Sections: + +6.1 [Guides](#verification-guides) +6.1.1 [WSTG](#wstg) +6.1.2 [MASTG](#mastg) +6.1.3 [ASVS](#asvs) +6.2 [Tools](#verification-tools) +6.2.1 [DAST tools](#dast-tools) +6.2.2 [Amass](#amass) +6.2.3 [OWTF](#owtf) +6.2.4 [Nettacker](#nettacker) +6.2.5 [OSHP verification](#oshp-verification) +6.3 [Frameworks](#verification-frameworks) +6.3.1 [secureCodeBox](#securecodebox) +6.4 [Vulnerability management](#verification-vulnerability-management) +6.4.1 [DefectDojo](#defectdojo) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0800]. + +[culturetest]: https://owasp.org/www-project-security-culture/stable/7-Security_Testing/ +[issue0800]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2008-verification/00-toc +[samm]: https://owaspsamm.org/about/ +[sammv]: https://owaspsamm.org/model/verification/ diff --git a/release-ja/08-verification/01-guides/00-toc.md b/release-ja/08-verification/01-guides/00-toc.md new file mode 100644 index 00000000..0594fba8 --- /dev/null +++ b/release-ja/08-verification/01-guides/00-toc.md @@ -0,0 +1,40 @@ +--- + +title: Verification Guides +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 6.1 Verification guides + +[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm]. +The verification activities are wide ranging, and will include: + +* Testing of security controls +* Review of controls and security mechanisms +* Evaluation and assessment of the security architecture +* and others + +Given the breadth of techniques and knowledge required, guides are an important resource for verification activities. + +Sections: + +6.1.1 [WSTG](#wstg) +6.1.2 [MASTG](#mastg) +6.1.3 [ASVS](#asvs) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0810]. + +[issue0810]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2008-verification/01-guides/00-toc +[samm]: https://owaspsamm.org/about/ +[sammv]: https://owaspsamm.org/model/verification/ diff --git a/release-ja/08-verification/01-guides/01-wstg.md b/release-ja/08-verification/01-guides/01-wstg.md new file mode 100644 index 00000000..d57b9c59 --- /dev/null +++ b/release-ja/08-verification/01-guides/01-wstg.md @@ -0,0 +1,100 @@ +--- + +title: WSTG +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8110 +permalink: /release/verification/guides/wstg/ + +--- + +{% include breadcrumb.html %} + +### 6.1.1 WSTG + +The OWASP [Web Security Testing Guide][wstg] (WSTG) is a comprehensive guide to testing the security of +web applications and web services. + +The WSTG [documentation project][wstg] is an OWASP Flagship Project +and can be accessed as a [web based document][wstg-latest]. + +#### What is WSTG? + +The Web Security Testing Guide ([WSTG][wstg]) document is a comprehensive guide to testing the security +of web applications and web services. +The WSTG provides a framework of best practices commonly used by external penetration testers +and organizations conducting in-house testing. + +The WSTG document describes a suggested [web application test framework][wstg-framework] +and also provides general information on [how to test][wstg-howto] web applications with good testing practice. + +The tests are split out into domains: + +1. Configuration and Deployment Management +2. Identity Management +3. Authentication +4. Authorization +5. Session Management +6. Input Validation +7. Error Handling +8. Weak Cryptography +9. Business Logic +10. Client-side +11. API + +Each test in each domain has enough information to understand and run the test including: + +* Summary +* Test objectives +* How to test +* Suggested remediation +* Recommended tools and references + +The tests are identified with a unique reference number, +for example 'WSTG-APIT-01' refers to the first test in the 'API Testing' domain provided in the WSTG document. +These references are widely used and understood by the test and security communities. + +The WSTG also provides a suggested Web Security Testing Framework which can be tailored +for a particular organization's processes or can provide a generally accepted reference framework. + +#### Why use it? + +The WSTG document is widely used and has become the defacto standard on +what is required for comprehensive web application testing. +An organization's security testing process should consider the contents of the WSTG, or have equivalents, +which help the organization conform to general expectation of the security community. +The WSTG reference document can be adopted completely, partially or not at all; +according to an organization's needs and requirements. + +#### How to use it + +The OWASP Spotlight series provides an overview of how to use the WSTG: +'Project 1 - [Applying OWASP Testing Guide][spotlight01]'. + +The WSTG is accessed via the [online web document][wstg-latest]. +The section on principles and techniques of testing provides foundational knowledge, +along with advice on testing within typical Secure Development Lifecycle (SDLC) and penetration testing methodologies. + +The individual tests described in the various testing domains should be selected or discarded as necessary; +not every test will be relevant to every web application or organizational requirement, +and the tests should be tailored to provide at least the minimum test coverage while not expending too much test effort. + +#### References + +* OWASP [Web Security Testing Guide][wstg] (WSTG) project +* [WSTG downloads][wstg-latest] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue080101] or [edit on GitHub][edit080101]. + +[edit080101]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/01-guides/01-wstg.md +[issue080101]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2008-verification/01-guides/01-wstg +[spotlight01]: https://youtu.be/bxQPePVDbQk +[wstg]: https://owasp.org/www-project-web-security-testing-guide/ +[wstg-framework]: https://owasp.org/www-project-web-security-testing-guide/latest/3-The_OWASP_Testing_Framework/0-The_Web_Security_Testing_Framework +[wstg-howto]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/ +[wstg-latest]: https://owasp.org/www-project-web-security-testing-guide/stable/ diff --git a/release-ja/08-verification/01-guides/02-mastg.md b/release-ja/08-verification/01-guides/02-mastg.md new file mode 100644 index 00000000..740839f3 --- /dev/null +++ b/release-ja/08-verification/01-guides/02-mastg.md @@ -0,0 +1,95 @@ +--- + +title: MASTG +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8120 +permalink: /release/verification/guides/mastg/ + +--- + +{% include breadcrumb.html %} + + + +![MAS logo](../../../../assets/images/logos/mas.png "OWASP MAS"){: .image-right } + +### 6.1.2 MASTG + +The [MAS Verification Standard][masvs] (MASVS) explains the processes, techniques +and tools used for security testing a mobile application. + +The OWASP [MAS][mas] project provides the [Mobile Application Security Testing Guide][mastg] (MASTG) +which describes technical processes that can be used for verification of the mobile application controls . + +#### What is MASTG? + +The OWASP [Mobile Application Security Testing Guide][mastg] is a comprehensive manual +for mobile application security testing and reverse engineering. +It describes the technical processes used for verifying the controls listed in the OWASP MASVS. + +The MASTG provides several resources for testing the controls: + +* Sections detailing the concepts and theory behind testing of both Android and iOS platforms +* Lists of [tests][mastgtests] for each section of the [MASVS][masvs] +* Descriptions of [techniques][mastgtechs] for Android or iOS used during testing +* Lists of generic [tools][mastgtools] and also ones specific for Android or iOS +* Reference [applications][mastgapps] that can be used as training material + +#### Why use MASTG? + +The OWASP MASVS is the industry standard for [mobile application security][csmas], +and provides a list of security controls that are expected in a mobile application. +If the application does not implement these controls correctly then it could be vulnerable; +the MASTG tests that the application has the controls listed in the MASVS. + +#### How to use MASTG + +The OWASP Spotlight series provides an overview of using the MASTG: +'Project 13 - [OWASP Mobile Security Testing Guide (MSTG)][spotlight13]'. + +The MASTG project contains a large number of resources that can be used during verification +and testing of mobile applications; pick and choose the resources that are applicable to specific application. + +* Refer to the MASTG section on the concepts and theory to ensure good understanding of the testing process +* Select the [MASTG tests][mastgtests] that are applicable to the application and its platform OS +* Use the section on [MASTG techniques][mastgtechs] to run the selected tests correctly +* Become familiar with the range of [MASTG tools][mastgtools] available and select the ones that you need +* Use the [MAS Checklists][masc] to provide evidence of compliance + +#### References + +* OWASP [Mobile Application Security][masproject] (MAS) project +* OWASP [MAS Testing Guide][mastg] (MASTG) +* OWASP [MAS Checklists][masc] +* OWASP [MAS Verification Standard][masvs] (MASVS) +* OWASP [Mobile Application Security][csmas] cheat sheet + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue080102] or [edit on GitHub][edit080102]. + +[csmas]: https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet +[edit080102]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/01-guides/02-mastg.md +[issue080102]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2008-verification/01-guides/02-mastg +[mas]: https://mas.owasp.org/ +[masproject]: https://owasp.org/www-project-mobile-app-security/ +[masc]: https://mas.owasp.org/checklists/ +[mastg]: https://mas.owasp.org/MASTG/ +[mastgapps]: https://mas.owasp.org/MASTG/apps/ +[mastgtests]: https://mas.owasp.org/MASTG/tests/ +[mastgtechs]: https://mas.owasp.org/MASTG/techniques/ +[mastgtools]: https://mas.owasp.org/MASTG/tools/ +[masvs]: https://mas.owasp.org/MASVS/ +[spotlight13]: https://youtu.be/b07OQd5KSrs diff --git a/release-ja/08-verification/01-guides/03-asvs.md b/release-ja/08-verification/01-guides/03-asvs.md new file mode 100644 index 00000000..e58b693e --- /dev/null +++ b/release-ja/08-verification/01-guides/03-asvs.md @@ -0,0 +1,117 @@ +--- + +title: ASVS +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8130 +permalink: /release/verification/guides/asvs/ + +--- + +{% include breadcrumb.html %} + +### 6.1.3 ASVS + +The [Application Security Verification Standard][asvs] (ASVS) is a long established OWASP flagship project, +and is widely used as a guide during the verification of web applications. + +It can be downloaded from the [OWASP project page][asvs] in various languages and formats: +PDF, Word, CSV, XML and JSON. Having said that, the recommended way to consume the ASVS is to access +the [github markdown][asvsmd] pages directly - this will ensure that the latest version is used. + +#### What is ASVS? + +The ASVS is an open standard that sets out the coverage and 'level of rigor' expected when it comes to +performing web application security verification. +The standard also provides a basis for testing any technical security controls +that are relied on to protect against vulnerabilities in the application. + +The ASVS is split into various sections: + +* V1 [Architecture, Design and Threat Modeling][asvsV1] +* V2 [Authentication][asvsV2] +* V3 [Session Management][asvsV3] +* V4 [Access Control][asvsV4] +* V5 [Validation, Sanitization and Encoding][asvsV5] +* V6 [Stored Cryptography][asvsV6] +* V7 [Error Handling and Logging][asvsV7] +* V8 [Data Protection][asvsV8] +* V9 [Communication][asvsV9] +* V10 [Malicious Code][asvsV10] +* V11 [Business Logic][asvsV11] +* V12 [Files and Resources][asvsV12] +* V13 [API and Web Service][asvsV13] +* V14 [Configuration][asvsV14] + +The ASVS defines three [levels of security verification][asvsL123]: + +1. applications that only need low assurance levels; these applications are completely penetration testable +2. applications which contain sensitive data that require protection; the recommended level for most applications +3. the most critical applications that require the highest level of trust + +Most applications will aim for Level 2, with only those applications that perform high value transactions, +or contain sensitive medical data, aiming for the highest level of trust at level 3. + +#### Why use it? + +The ASVS is used by many organizations as a basis for the verification of their web applications. +It is well established, the earlier versions were written in 2008, and it has been continually supported since then. + +The ASVS is comprehensive, for example version 4.0.3 has a list of 286 verification requirements, +and these verification requirements have been created and agreed to by a wide security community. +Using the ASVS as a guide provides a firm basis for the verification process. + +#### How to use it + +The OWASP Spotlight series provides an overview of the ASVS and its uses: +'Project 19 - [OWASP Application Security Verification standard (ASVS)][spotlight19]'. + +The ASVS should be used as a guide for the verification process, with the appropriate level of verification chosen from: + +* Level 1: First steps, automated, or whole of portfolio view +* Level 2: Most applications +* Level 3: High value, high assurance, or high safety + +Use the ASVS as guidance rather than trying to implement every possible control. +Tools such as [SecurityRAT][srat] can help create a more manageable subset of the ASVS requirements. + +The ASVS guidance will help developers build security controls that will satisfy the application security requirements. + +The OWASP Cheat Sheets have been indexed specifically for [each section of the ASVS][csasvs], +which can be used as documentation to help decide if a requirements category is to be included in verification. + +#### References + +* OWASP [Application Security Verification Standard][asvs] (ASVS) +* OWASP [ASVS Index][csasvs] +* OWASP [SecurityRAT][srat] project + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue080103] or [edit on GitHub][edit080103]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[asvsL123]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x03-Using-ASVS.md#application-security-verification-levels +[asvsmd]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x00-Header.md +[asvsV1]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x10-V1-Architecture.md#v1-architecture-design-and-threat-modeling +[asvsV2]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x11-V2-Authentication.md#v2-authentication +[asvsV3]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x12-V3-Session-management.md#v3-session-management +[asvsV4]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x12-V4-Access-Control.md#v4-access-control +[asvsV5]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md#v5-validation-sanitization-and-encoding +[asvsV6]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x14-V6-Cryptography.md#v6-stored-cryptography +[asvsV7]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x15-V7-Error-Logging.md#v7-error-handling-and-logging +[asvsV8]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x16-V8-Data-Protection.md#v8-data-protection +[asvsV9]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x17-V9-Communications.md#control-objective +[asvsV10]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x18-V10-Malicious.md#v10-malicious-code +[asvsV11]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x19-V11-BusLogic.md#v11-business-logic +[asvsV12]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x20-V12-Files-Resources.md#v12-files-and-resources +[asvsV13]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x21-V13-API.md#v13-api-and-web-service +[asvsV14]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x22-V14-Config.md#v14-configuration +[csasvs]: https://cheatsheetseries.owasp.org/IndexASVS.html +[edit080103]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2008-verification/01-guides/05-asvs.md +[issue080103]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2008-verification/01-guides/03-asvs +[spotlight19]: https://youtu.be/3puIavsZfAk +[srat]: https://owasp.org/www-project-securityrat/ diff --git a/release-ja/08-verification/01-guides/info.md b/release-ja/08-verification/01-guides/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/08-verification/01-guides/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/08-verification/01-guides/toc.md b/release-ja/08-verification/01-guides/toc.md new file mode 100644 index 00000000..f7eaed87 --- /dev/null +++ b/release-ja/08-verification/01-guides/toc.md @@ -0,0 +1,53 @@ +--- + +title: Verification Guides +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8100 +permalink: /release/verification/guides/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 6.1 Verification guides + +[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm]. +The verification activities are wide ranging, and will include: + +* Testing of security controls +* Review of controls and security mechanisms +* Evaluation and assessment of the security architecture +* and others + +Given the breadth of techniques and knowledge required, guides are an important resource for verification activities. + +Sections: + +6.1.1 [WSTG](01-wstg.md) +6.1.2 [MASTG](02-mastg.md) +6.1.3 [ASVS](03-asvs.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0810] or [edit on GitHub][edit0810]. + +[edit0810]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/01-guides/toc.md +[issue0810]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2008-verification/01-guides/00-toc +[samm]: https://owaspsamm.org/about/ +[sammv]: https://owaspsamm.org/model/verification/ diff --git a/release-ja/08-verification/02-tools/00-toc.md b/release-ja/08-verification/02-tools/00-toc.md new file mode 100644 index 00000000..27779dda --- /dev/null +++ b/release-ja/08-verification/02-tools/00-toc.md @@ -0,0 +1,43 @@ +--- + +title: Verification Tools +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 6.2 Verification tools + +[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm]. + +The SAMM [Security Testing][sammvst] activity describes the use of both +automated security testing and manual expert security testing to discover security defects. +This security testing should be automated as part of the development, build and deployment processes; +and can be complemented with regular manual security penetration tests. + +Automated security testing tools are fast and scale well to numerous applications, +whereas manual security testing of high-risk components requires good knowledge of the application and its business logic. + +Sections: + +6.2.1 [DAST tools](#dast-tools) +6.2.2 [Amass](#amass) +6.2.3 [OWTF](#owtf) +6.2.4 [Nettacker](#nettacker) +6.2.5 [OSHP verification](#oshp-verification) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0820]. + +[issue0820]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2008-verification/02-tools/00-toc +[samm]: https://owaspsamm.org/about/ +[sammv]: https://owaspsamm.org/model/verification/ +[sammvst]: https://owaspsamm.org/model/verification/security-testing/ diff --git a/release-ja/08-verification/02-tools/01-dast.md b/release-ja/08-verification/02-tools/01-dast.md new file mode 100644 index 00000000..a03e8e48 --- /dev/null +++ b/release-ja/08-verification/02-tools/01-dast.md @@ -0,0 +1,72 @@ +--- + +title: DAST +layout: col-document +tags: OWASP Developer Guide +contributors: Johan Sydseter, Jon Gadsden +document: OWASP Developer Guide +order: 8210 +permalink: /release/verification/tools/dast/ + +--- + +{% include breadcrumb.html %} + + + +Dynamic application security testing (DAST) represents a non-functional testing process to identify security weaknesses and +vulnerabilities in applications. The testing process can be carried out manually or be automated. Manual assessment of an +application involves human intervention to identify security flaws which might slip from an automated tool. Usually +business logic errors, race condition checks, and certain zero-day vulnerabilities can only be identified using manual +assessments. + +### 6.2.1 DAST tools + +DAST tools are programs which communicates with a web application through the web front-end in order to identify potential +security vulnerabilities in the web application and architectural weaknesses. It performs a black-box test. Unlike static +application security testing tools, DAST tools do not have access to the source code and therefore detect vulnerabilities +by actually performing attacks. + +#### Different DAST tools + +The OWASP Community contains a [list of DAST tools][dast] that can be used to conduct DAST. +All of these tools have their own strengths and weaknesses. +If you are interested in the effectiveness of DAST tools, check out the [OWASP Benchmark][benchmark] project, +which attempts to scientifically measure the effectiveness of all types of +vulnerability detection tools, including DAST. + +#### Why use it? + +The big advantage of these types of tools are that they can scan year-round to be constantly searching for vulnerabilities. +With new vulnerabilities being discovered regularly this allows companies to find and patch vulnerabilities before they +can become exploited. + +#### Cons + +Because these tools does dynamic testing, it cannot cover 100% of the source code of the application and then, the +application itself. The penetration tester should look at the coverage of the web application or of its attack surface to +know if the tool was configured correctly or was able to understand the web application. + +#### References + +* [Dynamic application security testing][wikipedia] +* [Vulnerability Scanning Tools][dast] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue080201] or [edit on GitHub][edit080201]. + +[benchmark]: https://owasp.org/www-project-benchmark/ +[dast]: https://owasp.org/www-community/Vulnerability_Scanning_Tools +[edit080201]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/02-tools/01-dast.md +[issue080201]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2008-verification/02-tools/01-dast +[wikipedia]: https://en.wikipedia.org/wiki/Dynamic_application_security_testing diff --git a/release-ja/08-verification/02-tools/02-amass.md b/release-ja/08-verification/02-tools/02-amass.md new file mode 100644 index 00000000..7df12d49 --- /dev/null +++ b/release-ja/08-verification/02-tools/02-amass.md @@ -0,0 +1,67 @@ +--- + +title: Amass +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8220 +permalink: /release/verification/tools/amass/ + +--- + +{% include breadcrumb.html %} + +### 6.2.2 Amass + +The OWASP Amass is a tool that provides attack surface management for an organization's web sites and applications. +It used during penetration testing for network mapping of attack surfaces +and external asset discovery by integrating various existing security tools. + +The Amass [breaker/tool project][amass] is an OWASP Flagship Project and installers can be +downloaded from the project's github repository [release area][amass-download]. + +#### What is Amass? + +Amass is a command line tool that provides information on an organization's web sites, +using various open source information gathering tools and active reconnaissance techniques. + +It is run from the command line with [subcommands][amass-docs] : + +1. 'amass intel' collects intelligence on the target organization +2. 'amass enum' performs DNS enumeration and network mapping to populate the results database +3. 'amass db' + +Each command comes with a wide set of options that controls the tools used and the format of the findings. + +#### Why use it? + +Amass is an important tool for security test teams. Amass is included in the [Kali Linux][kali] distribution, +which is widely used by penetration testing teams, with Amass providing a straightforward way +of running a wide set of reconnaissance and enumeration tools. + +In addition Amass is an easily used tool that is available to both legitimate test teams and malicious actors. +It is very likely that any given organization has been scanned and enumerated by Amass at some point, +either maliciously or legitimately, +so it is important that the tool is run to determine what information a malicious actor can obtain. + +#### How to use it + +If [Kali Linux][kali] is being used then Amass comes ready installed, +otherwise a wide set of [installers][amass-install] is provided for other platforms. + +The extensive [Amass tutorial][amass-tutorial] provides the best way of learning to use Amass and its features. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue080202] or [edit on GitHub][edit080202]. + +[amass]: https://owasp.org/www-project-amass/ +[amass-docs]: https://github.com/owasp-amass/amass/blob/master/doc/user_guide.md +[amass-download]: https://github.com/owasp-amass/amass/releases +[amass-install]: https://github.com/owasp-amass/amass/blob/master/doc/install.md +[amass-tutorial]: https://github.com/owasp-amass/amass/blob/master/doc/tutorial.md +[edit080202]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/02-tools/02-amass.md +[issue080202]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2008-verification/02-tools/02-amass +[kali]: https://www.kali.org/ diff --git a/release-ja/08-verification/02-tools/03-owtf.md b/release-ja/08-verification/02-tools/03-owtf.md new file mode 100644 index 00000000..cdb587bd --- /dev/null +++ b/release-ja/08-verification/02-tools/03-owtf.md @@ -0,0 +1,69 @@ +--- + +title: OWTF +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8230 +permalink: /release/verification/tools/owtf/ + +--- + +{% include breadcrumb.html %} + + + +![OWTF logo](../../../../assets/images/logos/owtf.png "OWASP OWTF"){: .image-right } + +### 6.2.3 OWTF + +OWASP Offensive Web Testing Framework ([OWTF][owtf]) is a penetration test tool +that provides pen-testers with a framework for organizing and running security test suites. +It also helps align the pen-testing to various standards and security guides, +allowing the testing to be more creative and comprehensive. + +The OWTF defender/tool project is an OWASP Flagship Project +and can be downloaded from the project's github repository [release area][owtfdownload]. + +#### What is OWTF? + +The [OWTF][owtf]tool is a penetration test framework used to organize and run suites of security and pen-testing tools. +It is designed to be run on [Kali Linux][kali]; it can also be run on MacOS but with some modification of scripts and paths. + +OWTF is very much a penetration tester's tool; there is an expectation that the +user has a reasonable expertise and grasp of penetration testing environments and tools. +The [documentation][owtfdocs] on installing and running OWTF requires is not extensive, +and some in-depth knowledge on the target system is required to configure the tool. + +#### Why use it? + +[OWTF][owtf] is easily configurable and plugins can be created or new tests added using the configuration files. +It can be quickly installed on [Kali Linux][kali], a distribution of Ubuntu that is widely used by pen-testers, +and allows for a whole suite of tests to be directed against the target. + +#### How to use it + +The OWTF [documentation][owtfdocs] is relatively old, last updated in 2016, +and the [install][owtfinstall] instructions may need adapting to run on MacOS or Kali. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue080203] or [edit on GitHub][edit080203]. + +[edit080203]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/02-tools/03-owtf.md +[issue080203]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2008-verification/02-tools/03-owtf +[kali]: https://www.kali.org/ +[owtfinstall]: https://owtf.readthedocs.io/en/develop/installation/methods.html +[owtfdocs]: https://owtf.readthedocs.io/ +[owtfdownload]: https://github.com/owtf/owtf/releases +[owtf]: https://owasp.org/www-project-owtf/ diff --git a/release-ja/08-verification/02-tools/04-nettacker.md b/release-ja/08-verification/02-tools/04-nettacker.md new file mode 100644 index 00000000..2702ce8e --- /dev/null +++ b/release-ja/08-verification/02-tools/04-nettacker.md @@ -0,0 +1,82 @@ +--- + +title: Nettacker +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8240 +permalink: /release/verification/tools/nettacker/ + +--- + +{% include breadcrumb.html %} + + + +![Nettacker logo](../../../../assets/images/logos/nettacker.png "OWASP Nettacker"){: .image-right } + +### 6.2.4 Nettacker + +OWASP Nettacker is a command line utility for automated network and vulnerability scanning. +It can be used during penetration testing for both internal and external security assessments of networks. + +The Nettacker [breaker/tool project][nettacker-project] is an OWASP Incubator Project; +the latest version can be downloaded from the project's [github repository][nettacker-install]. + +#### What is Nettacker? + +[Nettacker][nettacker-project] is an automated penetration testing tool. +It is used to scan a network to discover nodes and servers on the network including subdomains. +Nettacker can then identify servers, services and port numbers in use. + +Nettacker is a modular python application that that can be extended with other scanning functions. +The many modules available are grouped into domains: + +* [Scan][nettacker-scan] modules for reconnaissance +* [Vulnerability][nettacker-vuln] modules that attempt specific exploits +* [Brute force][nettacker-brute] modules + +Nettacker runs on Windows, Linux and MacOS. + +#### Why use it? + +Nettacker is easy to use from the command line, making it easy to use in scripts, +and also comes with a web browser interface for easy navigation of the results. +This makes it a quick and reliable way to gain information from a network. + +Nettacker can be used both for auditing purposes and also for penetration testing. + +#### How to use it + +The OWASP Spotlight series provides an overview of attack surface management using Nettacker: +'Project 11 - [Nettacker][spotlight11]'. + +The documentation for Nettacker is provided in the repository wiki pages; +follow [these instructions][nettacker-install] to install it. + +Nettacker is a flexible and modular scanning tool that can be used in many ways and with many options. +The best way to start using it is by following the [introduction video][nettacker-intro] and then taking it from there. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue080204] or [edit on GitHub][edit080204]. + +[edit080204]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/02-tools/04-nettacker.md +[issue080204]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2008-verification/02-tools/04-nettacker +[nettacker-brute]: https://github.com/OWASP/Nettacker/wiki/Modules#brute-modules +[nettacker-install]: https://github.com/OWASP/Nettacker/wiki/Installation +[nettacker-intro]: https://github.com/OWASP/Nettacker/wiki#introduction +[nettacker-project]: https://owasp.org/www-project-nettacker/ +[nettacker-scan]: https://github.com/OWASP/Nettacker/wiki/Modules#scan-modules +[nettacker-vuln]: https://github.com/OWASP/Nettacker/wiki/Modules#vuln-modules +[spotlight11]: https://www.youtube.com/watch?v=OGv7OtG127A diff --git a/release-ja/08-verification/02-tools/05-secure-headers.md b/release-ja/08-verification/02-tools/05-secure-headers.md new file mode 100644 index 00000000..d4d384a8 --- /dev/null +++ b/release-ja/08-verification/02-tools/05-secure-headers.md @@ -0,0 +1,71 @@ +--- + +title: OSHP +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8250 +permalink: /release/verification/tools/oshp/ + +--- + +{% include breadcrumb.html %} + +### 6.2.5 OSHP verification + +The OWASP Secure Headers Project ([OSHP][oshp]) provides information on HTTP response headers +to increase the security of a web application. + +The OSHP documentation project is an OWASP Lab Project and raises awareness of secure headers and their use. + +#### What is OSHP? + +The [OSHP project][oshp]) provides explanations for the HTTP response headers that an application can use +to increase the security of the application. +Once set the HTTP response headers can restrict modern browsers from running into easily preventable vulnerabilities. + +OSHP contains guidance and downloads on: + +* Response headers explanations and usage +* Links to individual browser support +* Guidance and best practices +* Technical resources in the form of tools and documents +* Code snippets to help working with HTTP security headers + +#### Why use it? + +The OSHP is a documentation project that explains the reasoning and usage of HTTP response headers. +It is the go-to document for guidance and best practices; +the information on HTTP response headers is the best advice, in one location, and is kept up to date. + +#### How to use it + +The OWASP Spotlight series provides an overview of this project and its uses: +'Project 24 - [OWASP Security Headers Project][spotlight24]'. + +OSHP documents [various tools][oshp-tools] useful for inspection, analysis and scanning of HTTP response headers: + +* hsecscan +* humble +* SecurityHeaders.com +* Mozilla Observatory +* Recx Security Analyser +* testssl.sh +* DrHEADer +* csp-evaluator + +OSHP also provides links to development [libraries][oshp-libs] that provide for secure HTTP response headers +in a range of languages and frameworks. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue080205] or [edit on GitHub][edit080205]. + +[edit080205]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/02-tools/05-secure-headers.md +[issue080205]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2008-verification/02-tools/05-secure-headers +[oshp]: https://owasp.org/www-project-secure-headers/ +[oshp-libs]: https://owasp.org/www-project-secure-headers/#development-libraries +[oshp-tools]: https://owasp.org/www-project-secure-headers/#analysis-tools +[spotlight24]: https://youtu.be/N4F3VWQYU9E diff --git a/release-ja/08-verification/02-tools/info.md b/release-ja/08-verification/02-tools/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/08-verification/02-tools/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/08-verification/02-tools/toc.md b/release-ja/08-verification/02-tools/toc.md new file mode 100644 index 00000000..248a84d9 --- /dev/null +++ b/release-ja/08-verification/02-tools/toc.md @@ -0,0 +1,56 @@ +--- + +title: Verification Tools +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8200 +permalink: /release/verification/tools/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 6.2 Verification tools + +[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm]. + +The SAMM [Security Testing][sammvst] activity describes the use of both +automated security testing and manual expert security testing to discover security defects. +This security testing should be automated as part of the development, build and deployment processes; +and can be complemented with regular manual security penetration tests. + +Automated security testing tools are fast and scale well to numerous applications, +whereas manual security testing of high-risk components requires good knowledge of the application and its business logic. + +Sections: + +6.2.1 [DAST tools](01-dast.md) +6.2.2 [Amass](02-amass.md) +6.2.3 [OWTF](03-owtf.md) +6.2.4 [Nettacker](04-nettacker.md) +6.2.5 [OSHP verification](05-secure-headers.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0820] or [edit on GitHub][edit0820]. + +[edit0820]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/02-tools/toc.md +[issue0820]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2008-verification/02-tools/00-toc +[samm]: https://owaspsamm.org/about/ +[sammv]: https://owaspsamm.org/model/verification/ +[sammvst]: https://owaspsamm.org/model/verification/security-testing/ diff --git a/release-ja/08-verification/03-frameworks/00-toc.md b/release-ja/08-verification/03-frameworks/00-toc.md new file mode 100644 index 00000000..872b1f43 --- /dev/null +++ b/release-ja/08-verification/03-frameworks/00-toc.md @@ -0,0 +1,41 @@ +--- + +title: Verification Frameworks +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 6.3 Verification frameworks + +[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm] +and both [Security Testing][sammvst] and [Requirements-driven Testing][sammvrt] are an important part of verification. + +Verification testing can benefit from using frameworks to support continuous and automated security testing. +Use of a framework can provide: + +* automation of a security analysis pipeline +* flexibility to run a series of tools in a pipeline +* scalability for multiple security scanners +* control interfaces + +Sections: + +6.3.1 [secureCodeBox](#securecodebox) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0830]. + +[issue0830]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2008-verification/03-frameworks/00-toc +[samm]: https://owaspsamm.org/about/ +[sammv]: https://owaspsamm.org/model/verification/ +[sammvrt]: https://owaspsamm.org/model/verification/requirements-driven-testing/ +[sammvst]: https://owaspsamm.org/model/verification/security-testing/ diff --git a/release-ja/08-verification/03-frameworks/01-secure-codebox.md b/release-ja/08-verification/03-frameworks/01-secure-codebox.md new file mode 100644 index 00000000..9443ea8e --- /dev/null +++ b/release-ja/08-verification/03-frameworks/01-secure-codebox.md @@ -0,0 +1,102 @@ +--- + +title: secureCodeBox +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8310 +permalink: /release/verification/frameworks/secure_codebox/ + +--- + +{% include breadcrumb.html %} + +![SecureCodeBox logo](../../../../assets/images/logos/securecodebox.png "OWASP SecureCodeBox"){: height="180px" } + +#### 6.3.1 secureCodeBox + +OWASP [secureCodeBox][codebox] is a kubernetes based modularized toolchain +that provides continuous security scans of an organizations' projects and web applications. + +The secureCodeBox [builder/tool project][codebox-project] is an OWASP Lab Project +and is installed using the [Helm ChartMuseum][codebox-repo]. + +#### What is secureCodeBox? + +OWASP secureCodeBox combines existing security tools from the static analysis, dynamic analysis and network analysis domains. +It uses these tools to provide a comprehensive overview of threats and vulnerabilities +affecting an organization's network and applications. + +OWASP secureCodeBox orchestrates a range of security-testing tools in various domains: + +* Container analysis: + * Trivy container vulnerability scanner + * Trivy SBOM container dependency scanner + +* Content Management System analysis: + * CMSeeK detecting the Joomla CMS and its core vulnerabilities + * Typo3Scan detecting the Typo3 CMS and its installed extensions + * WPScan Wordpress vulnerability scanner + +* Kubernetes analysis: + * Kube Hunter vulnerability scanner + * Kubeaudit configuration Scanner + +* Network analysis: + * Amass subdomain enumeration scanner + * doggo DNS client + * Ncrack network authentication bruteforcing + * Nmap network discovery and security auditing + * Whatweb website identification + +* Repository analysis: + * Git Repo Scanner discover Git repositories + * Gitleaks find potential secrets in repositories + * Semgrep static code analysis + +* SSH/TLS configuration and policy scanning with SSH-audit and SSLyze + +* Web Application analysis: + * ffuf web server and web application elements and content discovery + * Nikto web server vulnerability scanner + * Nuclei template based vulnerability scanner. + * Screenshooter takes screenshots of websites + * ZAP Advanced web application & OpenAPI vulnerability scanner + +Other tools may be added over time. + +#### Why use it? + +OWASP secureCodeBox provides the power of leading open source security testing tools with a multi-scanner platform. +This provides the ability to run routine scans continuously and automatically +on an organization's network infrastructure and applications. + +OWASP secureCodeBox is fully scalable and can be separately configured for multiple teams, systems or clusters. + +#### How to use it + +OWASP secureCodeBox runs on [Kubernetes][kube] and uses [Helm][helm] to install using the [Helm ChartMuseum][codebox-repo]. +There is an excellent '[Starting your First Scans][codebox-start]' guide to getting started with secureCodeBox, +with the rest of the [documentation][codebox-docs] providing clear information on configuring and running secureCodeBox. + +#### References + +* OWASP [secureCodeBox][codebox] +* [Kubernetes][kube] container orchestration +* [Helm][helm] package manager for Kubernetes + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue080301] or [edit on GitHub][edit080301]. + +[codebox]: https://www.securecodebox.io/ +[codebox-project]: https://owasp.org/www-project-securecodebox/ +[codebox-repo]: https://charts.securecodebox.io +[codebox-start]: https://www.securecodebox.io/docs/getting-started/first-scans +[codebox-docs]: https://www.securecodebox.io/docs/getting-started/installation +[edit080301]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/03-frameworks/01-secure-codebox.md +[helm]: https://helm.sh/ +[issue080301]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2008-verification/03-frameworks/01-secure-codebox +[kube]: https://kubernetes.io/ diff --git a/release-ja/08-verification/03-frameworks/info.md b/release-ja/08-verification/03-frameworks/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/08-verification/03-frameworks/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/08-verification/03-frameworks/toc.md b/release-ja/08-verification/03-frameworks/toc.md new file mode 100644 index 00000000..0f9bacc6 --- /dev/null +++ b/release-ja/08-verification/03-frameworks/toc.md @@ -0,0 +1,54 @@ +--- + +title: Verification Frameworks +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8300 +permalink: /release/verification/frameworks/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 6.3 Verification frameworks + +[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm] +and both [Security Testing][sammvst] and [Requirements-driven Testing][sammvrt] are an important part of verification. + +Verification testing can benefit from using frameworks to support continuous and automated security testing. +Use of a framework can provide: + +* automation of a security analysis pipeline +* flexibility to run a series of tools in a pipeline +* scalability for multiple security scanners +* control interfaces + +Sections: + +6.3.1 [secureCodeBox](01-secure-codebox.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0830] or [edit on GitHub][edit0830]. + +[edit0830]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/03-frameworks/toc.md +[issue0830]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2008-verification/03-frameworks/00-toc +[samm]: https://owaspsamm.org/about/ +[sammv]: https://owaspsamm.org/model/verification/ +[sammvrt]: https://owaspsamm.org/model/verification/requirements-driven-testing/ +[sammvst]: https://owaspsamm.org/model/verification/security-testing/ diff --git a/release-ja/08-verification/04-vulnerability-management/00-toc.md b/release-ja/08-verification/04-vulnerability-management/00-toc.md new file mode 100644 index 00000000..795a7d89 --- /dev/null +++ b/release-ja/08-verification/04-vulnerability-management/00-toc.md @@ -0,0 +1,37 @@ +--- + +title: Verification Vulnerability Management +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 6.4 Verification vulnerability management + +[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm]. +Vulnerability management helps maintain the application security level after bug fixes, changes or during maintenance. + +The SAMM [Requirements-driven Testing][sammvrt] practice describes the outcomes for effective vulnerability management, +and why it is necessary to have these processes in place. +For example using security unit tests to provide regression testing +gives some degree of confidence that applications are not vulnerable to known exploits. + +Sections: + +6.4.1 [DefectDojo](#defectdojo) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0840]. + +[issue0840]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2008-verification/04-vulnerability-management/00-toc +[samm]: https://owaspsamm.org/about/ +[sammv]: https://owaspsamm.org/model/verification/ +[sammvrt]: https://owaspsamm.org/model/verification/requirements-driven-testing/ diff --git a/release-ja/08-verification/04-vulnerability-management/01-defectdojo.md b/release-ja/08-verification/04-vulnerability-management/01-defectdojo.md new file mode 100644 index 00000000..bc895abd --- /dev/null +++ b/release-ja/08-verification/04-vulnerability-management/01-defectdojo.md @@ -0,0 +1,90 @@ +--- + +title: DefectDojo +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8410 +permalink: /release/verification/vulnerability_management/defectdojo/ + +--- + +{% include breadcrumb.html %} + +![DefectDojo logo](../../../../assets/images/logos/defectdojo.png "OWASP DefectDojo"){: height="160px" } + +### 6.4.1 DefectDojo + +OWASP [DefectDojo][defectdojo] is a DevSecOps tool for vulnerability management. +It provides one platform to orchestrate end-to-end security testing, vulnerability tracking, +deduplication, remediation, and reporting. + +DefectDojo is an OWASP [Flagship project][defectdojo-project] and is well established; +the project was started in 2013 and has been in continuous development / release since then. + +#### What is DefectDojo? + +[DefectDojo][defectdojo] is an open source vulnerability management tool that streamlines the testing process +by integration of templating, report generation, metrics, and baseline self-service tools. + +DefectDojo streamlines the testing process through several ‘models’ that an admin can manipulate with Python code. +The core models include: + +* engagements +* tests +* findings + +DefectDojo has supplemental models that facilitate : + +* metrics +* authentication +* report generation +* tools + +A good introduction to DefectDojo is the [We Hack Purple discussion][purple] between Matt Tesauro and Tanya Janca. + +#### Why use it? + +DefectDojo integrates with many open-source and proprietary/commercial [tools][defectdojo-tools] from various domains: + +* Dynamic Application Security Testing (DAST) +* Static Application Security Testing (SAST) +* Software Composition Analysis (SCA) +* Software Bills of Materials (SBOMs) +* Scanning of infrastructure and APIs + +It also integrates with the [Threagile Threat Modeling][threagile] tool, +and with time more integrations with threat modeling tools will become available. + +#### How to use it + +Testing or installing DefectDojo is straight forward using the [installation instructions][defectdojo-install]; +the recommended way to run DefectDojo is using a container. + +To set up an instance of DefectDojo follow the [docker compose][defectdojo-docker] instructions along with +the associated scripts that handle the dependencies, configure the database, create users and so on. +Refer to the DefectDojo [documentation][defectdojo-docs] for further information on alternative deployments, +setting up, usage and integrations. + +#### References + +* OWASP [DefectDojo][defectdojo] +* [We Hack Purple discussion][purple] +* [Threagile][threagile] Threat Modeling + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue080401] or [edit on GitHub][edit080401]. + +[defectdojo]: https://www.defectdojo.com/ +[defectdojo-docs]: https://documentation.defectdojo.com/ +[defectdojo-docker]: https://github.com/DefectDojo/django-DefectDojo/blob/dev/readme-docs/DOCKER.md +[defectdojo-install]: https://docs.defectdojo.com/en/about_defectdojo/new_user_checklist/ +[defectdojo-project]: https://owasp.org/www-project-defectdojo/ +[defectdojo-tools]: https://www.defectdojo.com/integrations +[edit080401]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/04-vulnerability-management/01-defectdojo.md +[issue080401]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2008-verification/04-vulnerability-management/01-defectdojo +[purple]: https://www.youtube.com/watch?v=FMUrL3Jzmzg +[threagile]: https://threagile.io diff --git a/release-ja/08-verification/04-vulnerability-management/info.md b/release-ja/08-verification/04-vulnerability-management/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/08-verification/04-vulnerability-management/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/08-verification/04-vulnerability-management/toc.md b/release-ja/08-verification/04-vulnerability-management/toc.md new file mode 100644 index 00000000..8242a22f --- /dev/null +++ b/release-ja/08-verification/04-vulnerability-management/toc.md @@ -0,0 +1,50 @@ +--- + +title: Verification Vulnerability Management +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8400 +permalink: /release/verification/vulnerability_management/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 6.4 Verification vulnerability management + +[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm]. +Vulnerability management helps maintain the application security level after bug fixes, changes or during maintenance. + +The SAMM [Requirements-driven Testing][sammvrt] practice describes the outcomes for effective vulnerability management, +and why it is necessary to have these processes in place. +For example using security unit tests to provide regression testing +gives some degree of confidence that applications are not vulnerable to known exploits. + +Sections: + +6.4.1 [DefectDojo](01-defectdojo.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0840] or [edit on GitHub][edit0840]. + +[edit0840]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/04-vulnerability-management/toc.md +[issue0840]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2008-verification/04-vulnerability-management/00-toc +[samm]: https://owaspsamm.org/about/ +[sammv]: https://owaspsamm.org/model/verification/ +[sammvrt]: https://owaspsamm.org/model/verification/requirements-driven-testing/ diff --git a/release-ja/08-verification/info.md b/release-ja/08-verification/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/08-verification/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/08-verification/toc.md b/release-ja/08-verification/toc.md new file mode 100644 index 00000000..e0056131 --- /dev/null +++ b/release-ja/08-verification/toc.md @@ -0,0 +1,80 @@ +--- + +title: Verification +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 8000 +permalink: /release/verification/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){: .image-right } + +## 6. Verification + +[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm]. + +Verification focuses on the processes and activities related to how an organization checks +and tests artifacts produced throughout software development. +This typically includes quality assurance work such as testing, and also includes other review and evaluation activities. + +Verification activities should include: + +* Architecture assessment, validation and mitigation +* Requirements-driven testing +* Security control verification and misuse/abuse testing +* Automated security testing and baselining +* Manual security testing and penetration testing + +These activities are supported by: + +* Security guides +* Test tools +* Test frameworks +* Vulnerability management +* Checklists + +Verification is an activity central to the secure software development lifecycle. +Refer to the [Security Culture][culturetest] project section for the various types of security testing. + +Sections: + +6.1 [Guides](01-guides/toc.md) +6.1.1 [WSTG](01-guides/01-wstg.md) +6.1.2 [MASTG](01-guides/02-mastg.md) +6.1.3 [ASVS](01-guides/03-asvs.md) +6.2 [Tools](02-tools/toc.md) +6.2.1 [DAST tools](02-tools/01-dast.md) +6.2.2 [Amass](02-tools/02-amass.md) +6.2.3 [OWTF](02-tools/03-owtf.md) +6.2.4 [Nettacker](02-tools/04-nettacker.md) +6.2.5 [OSHP verification](02-tools/05-secure-headers.md) +6.3 [Frameworks](03-frameworks/toc.md) +6.3.1 [secureCodeBox](03-frameworks/01-secure-codebox.md) +6.4 [Vulnerability management](04-vulnerability-management/toc.md) +6.4.1 [DefectDojo](04-vulnerability-management/01-defectdojo.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0800] or [edit on GitHub][edit0800]. + +[culturetest]: https://owasp.org/www-project-security-culture/stable/7-Security_Testing/ +[edit0800]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/08-verification/toc.md +[issue0800]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2008-verification/00-toc +[samm]: https://owaspsamm.org/about/ +[sammv]: https://owaspsamm.org/model/verification/ diff --git a/release-ja/09-training-education/00-toc.md b/release-ja/09-training-education/00-toc.md new file mode 100644 index 00000000..e2107189 --- /dev/null +++ b/release-ja/09-training-education/00-toc.md @@ -0,0 +1,61 @@ +--- + +title: Training and Education +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){height=180px} + +## 7. Training and Education + +Training and Education activities are described by in the SAMM [Training and Awareness][sammgegta] section, +which in turn is part of the SAMM [Education & Guidance][sammgeg] security practice +within the [Governance][sammg] business function. + +The goal of security training and education is to increase the awareness of application security threats and risks +along with security best practices and secure software design principles. +The security awareness training should be customized for all roles currently involved in the management, +development, testing, or auditing of the applications and systems. +In addition a Learning Management System or equivalent should be in place to track +the employee training and certification processes. + +It is important to provide activities for development teams; +we are all human and our security knowledge can become stale without a plan for refreshing it. +The [Security Culture][cultureacts] project describes various activities that can help developers +keep up to date and motivated. + +OWASP provides various resources and environments that can help with this security training and education +ranging from vulnerable applications, training platforms and gamification. + +Sections: + +7.1 [Vulnerable Applications](#vulnerable-applications) +7.1.1 [Juice Shop](#juice-shop) +7.1.2 [WebGoat](#webgoat) +7.1.3 [PyGoat](#pygoat) +7.1.4 [Security Shepherd](#security-shepherd) +7.2 [Secure Coding Dojo](#secure-coding-dojo) +7.3 [SKF education](#skf-education) +7.4 [SamuraiWTF](#samuraiwtf) +7.5 [OWASP Top 10 project](#owasp-top-ten-project) +7.6 [Mobile Top 10](#mobile-top-ten) +7.7 [API Top 10](#api-top-ten) +7.8 [WrongSecrets](#wrongsecrets) +7.9 [OWASP Snakes and Ladders](#owasp-snakes-and-ladders) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0900]. + +[cultureacts]: https://owasp.org/www-project-security-culture/stable/5-Activities/ +[issue0900]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2009-training-education/00-toc +[sammg]: https://owaspsamm.org/model/governance/ +[sammgeg]: https://owaspsamm.org/model/governance/education-and-guidance/ +[sammgegta]: https://owaspsamm.org/model/governance/education-and-guidance/stream-a/ diff --git a/release-ja/09-training-education/01-vulnerable-apps/00-toc.md b/release-ja/09-training-education/01-vulnerable-apps/00-toc.md new file mode 100644 index 00000000..b1c20ee5 --- /dev/null +++ b/release-ja/09-training-education/01-vulnerable-apps/00-toc.md @@ -0,0 +1,53 @@ +--- + +title: Vulnerable Applications +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 7.1 Vulnerable Applications + +Vulnerable applications are useful for the Training and Education activities +described in the SAMM [Training and Awareness][sammgegta] section, +which in turn is part of the SAMM [Education & Guidance][sammgeg] security practice +within the [Governance][sammg] business function. + +The intentionally-vulnerable applications provide a safe environment where various vulnerable targets can be attacked. +This provides practice in using various penetration tools available to a tester, +without the risk of attack traffic triggering intrusion detection systems. +The OWASP [Vulnerable Web Applications Directory Project][vwad] (VWAD) provides a comprehensive list of +available intentionally-vulnerable web applications: + +* Vulnerable [mobile applications][vwad-mobile] +* [Offline][vwad-offline] vulnerable web applications +* [Containerized][vwad-containers] vulnerable web applications +* vulnerable web applications [available Online][vwad-online] + +Sections: + +7.1.1 [Juice Shop](#juice-shop) +7.1.2 [WebGoat](#webgoat) +7.1.3 [PyGoat](#pygoat) +7.1.4 [Security Shepherd](#security-shepherd) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0910]. + +[issue0910]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2009-training-education/01-vulnerable-apps/00-toc +[sammg]: https://owaspsamm.org/model/governance/ +[sammgeg]: https://owaspsamm.org/model/governance/education-and-guidance/ +[sammgegta]: https://owaspsamm.org/model/governance/education-and-guidance/stream-a/ +[vwad]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[vwad-containers]: https://owasp.org/www-project-vulnerable-web-applications-directory/#div-container +[vwad-mobile]: https://owasp.org/www-project-vulnerable-web-applications-directory/#div-mobile +[vwad-online]: https://owasp.org/www-project-vulnerable-web-applications-directory/#div-online +[vwad-offline]: https://owasp.org/www-project-vulnerable-web-applications-directory/#div-offline diff --git a/release-ja/09-training-education/01-vulnerable-apps/01-juice-shop.md b/release-ja/09-training-education/01-vulnerable-apps/01-juice-shop.md new file mode 100644 index 00000000..3aa7604f --- /dev/null +++ b/release-ja/09-training-education/01-vulnerable-apps/01-juice-shop.md @@ -0,0 +1,103 @@ +--- + +title: Juice Shop +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9110 +permalink: /release/training_education/vulnerable_applications/juice_shop/ + +--- + +{% include breadcrumb.html %} + + + +![Juice Shop logo](../../../../assets/images/logos/juiceshop.png "OWASP Juice Shop"){: .image-right } + +### 7.1.1 Juice Shop + +The OWASP flagship project [Juice Shop][juice] is a deliberately insecure web application. +Juice Shop encompasses vulnerabilities from the entire OWASP Top Ten +along with many other security flaws found in real-world applications. + +#### What is Juice Shop? + +Juice Shop is an Open Source web application that is free to download and use, and is intentionally insecure. +It is easy to get started with Juice Shop; it includes [Hacking Instructor scripts][juicetutorial] +with an optional tutorial mode to guide newcomers through several challenges +while explaining the underlying vulnerabilities. + +Juice Shop is easily installed using a [Docker image][juicedocker] +and runs on Windows/Mac/Linux as well as all major cloud providers. +There are various ways to run Juice Shop: + +* [From source](https://hub.docker.com/r/bkimminich/juice-shop#from-sources) +* [Packaged Distributions](https://hub.docker.com/r/bkimminich/juice-shop#packaged-distributions) +* [Docker Container](https://hub.docker.com/r/bkimminich/juice-shop#docker-container) +* [Vagrant](https://hub.docker.com/r/bkimminich/juice-shop#vagrant) +* [Amazon EC2 Instance](https://hub.docker.com/r/bkimminich/juice-shop#amazon-ec2-instance) +* [Azure Container Instance](https://hub.docker.com/r/bkimminich/juice-shop#azure-container-instance) +* [Google Compute Engine Instance](https://hub.docker.com/r/bkimminich/juice-shop#google-compute-engine-instance) + +Juice Shop is written in JavaScript using Node.js, Express and Angular. + +#### Why use it? + +Juice Shop has several uses: + +* As the basis for security training programs, with integration for other training systems via a [WebHook][webhook] +* As practice for pentesters and hackers, including many built in coding challenges +* To provide awareness demos, with customizable rebranding for specific corporations or customers +* Support for [Capture the Flag][juicectf] (CTF) events using flag codes +* As a guinea pig for security tools + +For example pentesting proxies or security scanners can use Juice Shop as a 'guinea pig' application +to check how well their tools cope with JavaScript-heavy application frontends and REST APIs. + +#### How to use it + +There is no 'one way' to use Juice Shop, and so a good starting point is the overview of Juice Shop +provided by the OWASP Spotlight series: 'Project 25 - [OWASP Juice Shop][spotlight25]'. + +Get started by [downloading][juicedocker] and installing the Docker image. +The Docker daemon will have to be running to do this; get the Docker Engine from the [download site][dockerinstall]. + +```text +docker pull bkimminich/juice-shop +docker run --rm -p 3000:3000 bkimminich/juice-shop +``` + +Using a browser access `http://localhost:3000/#/` and note that you are now interacting with a deliberately insecure +'online' shopping web application, so be suspicious of everything you see :) + +Once Juice Shop is running the next step is to follow the [Official Companion Guide][juiceguide] +that can be downloaded from the Juice Shop shop. +This guide provides overviews of each Juice Shop application vulnerability +and includes hints on how to spot and exploit them. +In the appendix there is a complete step-by-step solution to every challenge for when you are stuck or just curious. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue090101] or [edit on GitHub][edit090101]. + +[dockerinstall]: https://docs.docker.com/engine/install/ +[edit090101]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/01-vulnerable-apps/01-juice-shop.md +[issue090101]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2009-training-education/01-vulnerable-apps/01-juice-shop +[juice]: https://owasp.org/www-project-juice-shop/ +[juicectf]: https://owasp.org/www-project-juice-shop/#div-ctf +[juicedocker]: https://hub.docker.com/r/bkimminich/juice-shop +[juiceguide]: https://owasp.org/www-project-juice-shop/#div-ecosystem +[juicetutorial]: https://owasp.org/www-project-juice-shop/#div-learning +[webhook]: https://pwning.owasp-juice.shop/companion-guide/latest/part4/integration.html#_challenge_solution_webhook +[spotlight25]: https://youtu.be/--50rE76EeA diff --git a/release-ja/09-training-education/01-vulnerable-apps/02-webgoat.md b/release-ja/09-training-education/01-vulnerable-apps/02-webgoat.md new file mode 100644 index 00000000..30ea1171 --- /dev/null +++ b/release-ja/09-training-education/01-vulnerable-apps/02-webgoat.md @@ -0,0 +1,132 @@ +--- + +title: WebGoat and WebWolf +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9120 +permalink: /release/training_education/vulnerable_applications/webgoat/ + +--- + +{% include breadcrumb.html %} + + + +![WebGoat logo](../../../../assets/images/logos/webgoat.png "OWASP WebGoat"){: .image-right } + +### 7.1.2 WebGoat + +The OWASP [WebGoat][webgoat] project is a deliberately insecure web application that can be +used to attack common application vulnerabilities in a safe environment. +It can also be used to exercise application security tools to practice +scanning and identifying the various vulnerabilities built into WebGoat. + +WebGoat is a well established OWASP project and achieved Lab Project status many years ago. + +#### What is WebGoat? + +WebGoat is primarily a training aid to help development teams put into practice common attack patterns. +It provides an environment where a Java-based web application can be safely attacked +without traversing a network or upsetting a website owner. + +The environment is self contained using a container and this ensures attack traffic does not leak to other systems; +this traffic should look like a malicious attack to a corporate intrusion detection system and will certainly light it up. +The WebGoat container contains WebWolf, an attacker client, +which further ensures that attack traffic stays within the container. + +In addition there is another WebGoat container available that includes a Linux desktop with some attack tools pre-installed. + +#### Why use WebGoat? + +WebGoat is one of those tools that has many uses; certainly during training but also when presenting demonstrations, +testing out security tools and so on. +Whenever you need a deliberately vulnerable web application running in a self contained and safe environment then +WebGoat is one of the first to consider. + +Reasons to use WebGoat: + +* Practical learning how to exploit web applications +* Ready made target during talks and demonstration on penetration testing +* Evaluating dynamic application security testing (DAST) tools; they should identify the known vulnerabilities +* Practicing penetration testing skills +* and there will be more + +#### How to use WebGoat + +The easiest way to run WebGoat is to use the provided Docker images to run containers. +WebGoat can also be run as a standalone Java application using the downloaded [Java Archive file][goatreleases] +or from the [source itself][goatreleases]; +this requires various dependencies, whereas all dependencies are provided within the Docker images. + +Access to WebGoat is via the port 8080 on the running Docker container +and this will need to be mapped to a port on the local machine. +Note that mapping to port 80 can be blocked on corporate laptops so it is suggested to map the port to localhost 8080. + +1. The Docker daemon will have to be running to do this, get the Docker Engine from the [download site][dockerinstall]. +2. Download the WebGoat [docker image][goatdocker] using command `docker pull webgoat/webgoat` +3. Run the container with `docker run --name webgoat -it -p 127.0.0.1:8080:8080 -p 127.0.0.1:9090:9090 webgoat/webgoat` +4. Use a browser to navigate to `localhost:8080/WebGoat` - note that there is no page served on `localhost:8080/` +5. You are then prompted to login, so first thing to do is create a test account from this login page +6. The accounts are retained when the container is stopped, but removed if the container is deleted +7. Creating insecure username/password combinations, such as 'kalikali' with 'Kali1234', is allowed + +The browser should now be displaying the WebGoat lessons, such as 'Hijack a session' under 'Broken Access Control'. + +#### How to use WebWolf + +![WebWolf logo](../../../../assets/images/logos/webwolf.png "OWASP WebWolf"){: .image-right } + +WebWolf is provided alongside both the WebGoat docker images and the WebGoat JAR file. +WebWolf is accessed using port 9090 on the Docker container, +and this can usually be mapped to localhost port 9090 as in the example given above. + +Use a browser to navigate to `http://localhost:9090/WebWolf`, there is no page served on URL `localhost:9090`. +Login to WebWolf using one of the accounts created when accessing the WebGoat account management pages, +such as username 'kalikali' and password 'Kali1234'. All going well you will now have the WebWolf home page displayed. + +WebWolf provides: + +* File upload area +* Email test mailbox +* JWT tools +* Display of http requests + +#### Where to go from here? + +Try out the WebGoat desktop environment by running `docker run -p 127.0.0.1:3000:3000 webgoat/webgoat-desktop` +and navigating to `http://localhost:3000/`. + +* Try the WebGoat lessons, they will certainly inform and educate +* Exercise available attack tools against WebGoat +* Use WebGoat in demonstrations of your favorite attack chains +* Use WebGoat material in presentations on vulnerabilities + +There are various ways of configuring WebGoat, see the [github repo][goatgithub] for more details. + +#### References + +* OWASP [WebGoat][webgoat] and WebWolf +* [Docker][dockerinstall] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue090102] or [edit on GitHub][edit090102]. + +[goatdocker]: https://hub.docker.com/r/webgoat/webgoat +[goatgithub]: https://github.com/WebGoat/WebGoat +[goatreleases]: https://github.com/WebGoat/WebGoat/releases +[dockerinstall]: https://docs.docker.com/engine/install/ +[edit090102]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/01-vulnerable-apps/02-webgoat.md +[issue090102]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2009-training-education/01-vulnerable-apps/02-webgoat +[webgoat]: https://owasp.org/www-project-webgoat/ diff --git a/release-ja/09-training-education/01-vulnerable-apps/03-pygoat.md b/release-ja/09-training-education/01-vulnerable-apps/03-pygoat.md new file mode 100644 index 00000000..1f84cbeb --- /dev/null +++ b/release-ja/09-training-education/01-vulnerable-apps/03-pygoat.md @@ -0,0 +1,84 @@ +--- + +title: PyGoat +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9130 +permalink: /release/training_education/vulnerable_applications/pygoat/ + +--- + +{% include breadcrumb.html %} + +### 7.1.3 PyGoat + +The OWASP [PyGoat project][pygoat] is an intentionally insecure web application, +and is written in python using the Django framework. +PyGoat is used to practice attacking a python-based web application in an isolated and secure environment + +PyGoat is a relatively new OWASP project, its first commit was in May 2020, +and although it is presently an Incubator project it should soon gain Lab project status. + +#### What is PyGoat? + +The purpose of PyGoat is to give both developers and testers an isolated platform +for learning how to test applications and how to code securely. +It provides examples of traditional web application exploits that follow the OWASP Top Ten vulnerabilities, +as well as providing a vulnerable web application for further exploitation / testing. + +PyGoat also provides a view of the python source code to determine where the mistake was made that caused the vulnerability. +This allows you to make changes to the web application and test whether these changes have secured it. + +PyGoat can be installed from [source repository][pygoatrepo] via scripts or pip, from a [Docker hub][pygoathub] image, +or using a Docker image [built locally][pygoatdocker]. + +#### Why use it? + +PyGoat is an easy to use demonstration and learning platform that provides a secure way to try and attack web applications. +It is less fully featured than either Juice Shop or WebGoat, and this makes it a simple and direct learning experience. +PyGoat provides example labs for the complete OWASP Top Ten (both 2021 and 2017 versions) along with explanatory notes. + +PyGoat also provides a python / Django web application which complements Juice Shop's Node.js +and WebGoat's Java applications; it is important to learn how to attack all of these frameworks. + +So if you are looking for a direct and easy way to start attacking a vulnerable web application +then PyGoat is one of the first to consider. + +#### How to use it + +The easiest way to run PyGoat is by downloading the Docker image and running it as a Docker container. +The Docker daemon will have to be running to do this, so get the Docker Engine from the [download site][dockerinstall]. + +Follow the instructions from the [Docker hub project][pygoathub] page: + +```text +docker pull pygoat/pygoat +docker run --rm -p 8000:8000 pygoat/pygoat +``` + +The internal container port 8000 is mapped to external port 8000, so browse to `http://127.0.0.1:8000/login/`. + +A user account needs to be set up before the labs can be accessed. This account is local to the container; +it will be deleted if the Docker container is stopped or deleted. +It can be any test account such as username 'user' and password 'Kali1234'. +To set up a user account access the login page and click on the 'Here' text within 'Click Here to register' +(it is not entirely obvious at first) and then enter the new username and password. + +Once a user account has been set up then login to access the labs. +A handy feature of PyGoat is the inclusion of the 2021 version of the OWASP Top Ten as well as the 2017 version, +these are provided side by side and aid cross referencing to the latest OWASP Top Ten. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue090103] or [edit on GitHub][edit090103]. + +[dockerinstall]: https://docs.docker.com/engine/install/ +[edit090103]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/01-vulnerable-apps/03-pygoat.md +[issue090103]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2009-training-education/01-vulnerable-apps/03-pygoat +[pygoat]: https://owasp.org/www-project-pygoat/ +[pygoatdocker]: https://github.com/adeyosemanputra/pygoat/blob/master/README.md#from-docker-compose +[pygoathub]: https://hub.docker.com/r/pygoat/pygoat +[pygoatrepo]: https://github.com/adeyosemanputra/pygoat/blob/master/README.md#from-sources diff --git a/release-ja/09-training-education/01-vulnerable-apps/04-security-shepherd.md b/release-ja/09-training-education/01-vulnerable-apps/04-security-shepherd.md new file mode 100644 index 00000000..00caab6b --- /dev/null +++ b/release-ja/09-training-education/01-vulnerable-apps/04-security-shepherd.md @@ -0,0 +1,69 @@ +--- + +title: Security Shepherd +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9140 +permalink: /release/training_education/vulnerable_applications/security_shepherd/ + +--- + +{% include breadcrumb.html %} + +### 7.1.4 Security Shepherd + +OWASP Security Shepherd is a web and [mobile application security][csmas] training platform +that helps to foster and improve security awareness for development teams. + +The Security Shepherd [tool project][sec-shep] is an OWASP Flagship Project +and can be downloaded from the project's [github repository][sec-shep-repo]. + +#### What is Security Shepherd? + +Security Shepherd is a teaching tool that provides lessons and an environment +to learn how to attack both web and mobile applications. +This enables users to learn or to improve upon existing their manual penetration testing skills. + +Security Shepherd is run on a web server such as Apache Tomcat and this can be installed manually. +There is also a pre-built virtual machine available or a docker image can be composed to run as a container. + +#### Why use it? + +Security Shepherd can train inexperienced pen-testers to security expert level by sharpening their testing skill-set. +Pen-testing is often included as a required stage in a organization's secure software development lifecycle (SDLC). + +#### How to use it + +Security Shepherd can be run as a Docker container, as a Virtual Machine or manually on top of a web server. + +The Security Shepherd wiki has step by step installation instructions: + +* either [compose the Docker image][sec-shep-docker] and run the container +* or download the [virtual machine][sec-shep-vm] and run on a hypervisor such as [Virtual Box][vbox] +* or [install on a Tomcat][sec-shep-tomcat] web server +* or [install on windows][sec-shep-windows] using a Tomcat web server + +Once installed and logged in, the lessons and vulnerable applications are available to use. +Security Shepherd has modes which it can be used for different training goals: + +* CTF (Capture the Flag) Mode +* Open Floor Mode +* Tournament Mode + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue090104] or [edit on GitHub][edit090104]. + +[csmas]: https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet +[edit090104]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/01-vulnerable-apps/04-security-shepherd.md +[issue090104]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2009-training-education/01-vulnerable-apps/04-security-shepherd +[sec-shep]: https://owasp.org/www-project-security-shepherd/ +[sec-shep-docker]: https://github.com/OWASP/SecurityShepherd/wiki/Docker-Environment-Setup +[sec-shep-repo]: https://github.com/OWASP/SecurityShepherd +[sec-shep-tomcat]: https://github.com/OWASP/SecurityShepherd/wiki/Manual-Shepherd-Setup +[sec-shep-vm]: https://github.com/OWASP/SecurityShepherd/wiki/Using-the-Shepherd-VM +[sec-shep-windows]: https://github.com/OWASP/SecurityShepherd/wiki/Manual-Shepherd-Set-Up-(Windows) +[vbox]: https://www.virtualbox.org/wiki/Downloads diff --git a/release-ja/09-training-education/01-vulnerable-apps/info.md b/release-ja/09-training-education/01-vulnerable-apps/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/09-training-education/01-vulnerable-apps/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/09-training-education/01-vulnerable-apps/toc.md b/release-ja/09-training-education/01-vulnerable-apps/toc.md new file mode 100644 index 00000000..cac6b7ed --- /dev/null +++ b/release-ja/09-training-education/01-vulnerable-apps/toc.md @@ -0,0 +1,66 @@ +--- + +title: Vulnerable Applications +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9100 +permalink: /release/training_education/vulnerable_applications/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 7.1 Vulnerable Applications + +Vulnerable applications are useful for the Training and Education activities +described in the SAMM [Training and Awareness][sammgegta] section, +which in turn is part of the SAMM [Education & Guidance][sammgeg] security practice +within the [Governance][sammg] business function. + +The vulnerable applications provide a safe environment where various vulnerable targets can be attacked. +This provides practice in using various penetration tools available to a tester, +without the risk of attack traffic triggering intrusion detection systems. +The OWASP [Vulnerable Web Applications Directory Project][vwad] (VWAD) provides a comprehensive list of +available intentionally-vulnerable web applications: + +* Vulnerable [mobile applications][vwad-mobile] +* [Offline][vwad-offline] vulnerable web applications +* [Containerized][vwad-containers] vulnerable web applications +* vulnerable web applications [available Online][vwad-online] + +Sections: + +7.1.1 [Juice Shop](01-juice-shop.md) +7.1.2 [WebGoat](02-webgoat.md) +7.1.3 [PyGoat](03-pygoat.md) +7.1.4 [Security Shepherd](04-security-shepherd.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0910] or [edit on GitHub][edit0910]. + +[edit0910]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/01-vulnerable-apps/toc.md +[issue0910]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2009-training-education/01-vulnerable-apps/00-toc +[sammg]: https://owaspsamm.org/model/governance/ +[sammgeg]: https://owaspsamm.org/model/governance/education-and-guidance/ +[sammgegta]: https://owaspsamm.org/model/governance/education-and-guidance/stream-a/ +[vwad]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[vwad-containers]: https://owasp.org/www-project-vulnerable-web-applications-directory/#div-container +[vwad-mobile]: https://owasp.org/www-project-vulnerable-web-applications-directory/#div-mobile +[vwad-online]: https://owasp.org/www-project-vulnerable-web-applications-directory/#div-online +[vwad-offline]: https://owasp.org/www-project-vulnerable-web-applications-directory/#div-offline diff --git a/release-ja/09-training-education/02-secure-coding-dojo.md b/release-ja/09-training-education/02-secure-coding-dojo.md new file mode 100644 index 00000000..676d4552 --- /dev/null +++ b/release-ja/09-training-education/02-secure-coding-dojo.md @@ -0,0 +1,71 @@ +--- + +title: Secure Coding Dojo +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9200 +permalink: /release/training_education/secure_coding_dojo/ + +--- + +{% include breadcrumb.html %} + +### 7.2 Secure Coding Dojo + +The OWASP [Secure Coding Dojo][codedojo-project] is a platform for delivering +secure coding training to software development teams. +Secure Coding Dojo is an OWASP Lab project and has been continuously supported and developed since 2017. + +#### What is the Secure Coding Dojo? + +The aim of Secure Coding Dojo is to teach developers how to recognize security flaws during code reviews. + +The training platform has a set of training lessons and also blocks of code where the developer has to identify +which block of code is written in an insecure way. +A leader board is provided for the development teams to track their progress. + +Each lesson is built as an attack/defense pair. +The developers can observe the software weaknesses by conducting the attack +and after solving the challenge they learn about the associated software defenses. +The predefined lessons are based on the MITRE most dangerous software errors (also known as SANS 25) +so the focus is on software errors rather than attack techniques. + +The training platform can be customized to integrate with custom vulnerable websites and other CTF challenges. + +#### Why use it? + +Development teams are often required to have Secure Coding training, and this may be an annual compliance requirement. +The Secure Coding Dojo provides this compliant training in reviewing software +for security bugs in representative source code. + +#### How to use it + +The OWASP Spotlight series provides an overview of the developer training provided by the Secure Coding Dojo: +'Project 14 - [OWASP Secure Coding Dojo][spotlight14]'. + +There is a [demonstration site][codedojo] for Secure Coding Dojo which provides access to the +training modules, code blocks and a public leader board. +Note that the demonstration site does not provide the deliberately insecure web sites, such as the 'Insecure.Inc' Java site, +because this would encourage attack traffic across a public network. + +Ideally Secure Coding Dojo is deployed by the organization providing the training, rather than by using the demo site, +because development teams can then log in securely to the Dojo. +Deployment is [straight forward][codedojo-install], +consisting of cloning the repository and running `docker-compose` with environment variables. +This also allows deployment of the associated deliberately [insecure web site][codedojo-insecure] +to practice penetration testing. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0902] or [edit on GitHub][edit0902]. + +[codedojo]: https://securecodingdojo.owasp.org/ +[codedojo-insecure]: https://github.com/OWASP/SecureCodingDojo/wiki/Running-Insecure.Inc +[codedojo-install]: https://github.com/OWASP/SecureCodingDojo/wiki/Deploying-with-Docker +[codedojo-project]: https://owasp.org/www-project-secure-coding-dojo/ +[edit0902]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/02-secure-coding-dojo.md +[issue0902]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2009-training-education/02-secure-coding-dojo +[spotlight14]: https://youtu.be/7nVkDkL9cyE diff --git a/release-ja/09-training-education/03-skf.md b/release-ja/09-training-education/03-skf.md new file mode 100644 index 00000000..dce11d9f --- /dev/null +++ b/release-ja/09-training-education/03-skf.md @@ -0,0 +1,75 @@ +--- + +title: SKF education +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9210 +permalink: /release/training_education/skf_education/ + +--- + +{% include breadcrumb.html %} + +### 7.3 SKF education + +The [Security Knowledge Framework][skf] (SKF) is an expert system application that uses various open source projects +to support development teams and security architects in building secure applications. +The Security Knowledge Framework uses the OWASP [Application Security Verification Standard][asvs] (ASVS) with code examples +to help developers in pre-development and post-development phases and create applications that are secure by design. + +Having been an OWASP flagship project for many years the SKF is now no longer within the OWASP organization; +it will continue to be referenced in the OWASP Wayfinder and other OWASP projects +because it is certainly a flagship project for any organization. + +#### What is the Security Knowledge Framework? + +The [SKF][skf] is a web application that is available from the [github repo][skfinstall]. +There is [a demo version][skfdemo] of SKF that is useful for exploring the multiple benefits of the SKF. +Note that SKF is in a process of migrating to a [new repository][skfrepo] so the download link may change. + +The SKF provides training and guidance for application security: + +* Requirements [organizer][skfreqs] +* Learning [courses][skfdemo] +* Practice [labs][skflabs] +* Documentation on [installing and using][skfdocs] the SKF + +#### Why use the SKF? + +The SKF provides both [learning courses][skfdemo] and [practice labs][skflabs] +that are useful for development teams to practice secure coding skills. + +The following learning courses are available (as of December 2023): + +* Developing Secure Software (LFD121) +* Understanding the OWASP Top 10 Security Threats (SKF100) +* Secure Software Development: Implementation (LFD105x) + +and there are plans for more training courses. +All of these courses (LFD121, SKF100 and LFD105x) are provided by the [Linux Foundation][linuxtraining]. + +In addition to the training courses there are a wide range of practice labs (64 as of December 2023). + +#### How to use the SKF + +The easiest way to get started with the SKF training is to [try the online demo][skfdemo]. +This will provide access to the practice labs, the training courses and also to the requirements tool. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0903] or [edit on GitHub][edit0903]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[edit0903]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/03-skf.md +[issue0903]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2009-training-education/03-security-knowledge-framework +[linuxtraining]: https://training.linuxfoundation.org/full-catalog/ +[skf]: https://www.securityknowledgeframework.org/ +[skfdemo]: https://secureby.design/ +[skfdocs]: https://skf.readme.io/docs/introduction +[skfinstall]: https://github.com/blabla1337/skf-flask/releases +[skflabs]: https://secureby.design/labs +[skfrepo]: https://github.com/Security-Knowledge-Framework +[skfreqs]: https://starfish-app-kd3eo.ondigitalocean.app/ diff --git a/release-ja/09-training-education/04-samurai-wtf.md b/release-ja/09-training-education/04-samurai-wtf.md new file mode 100644 index 00000000..5e32e50d --- /dev/null +++ b/release-ja/09-training-education/04-samurai-wtf.md @@ -0,0 +1,100 @@ +--- + +title: SamuraiWTF +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9220 +permalink: /release/training_education/samuraiwtf/ + +--- + +{% include breadcrumb.html %} + + + +![SamuraiWTF logo](../../../assets/images/logos/samuraiwtf.png "OWASP DefectDojo"){: height="160px" } + +### 7.4 SamuraiWTF + +The OWASP [SamuraiWTF][samurai-wtf] (Web Training and Testing Framework) is a linux desktop distribution +that is intended for application security training. + +The SamuraiWTF [breaker/tool project][samuraiwtf-project] is an OWASP Laboratory Project +and the desktop can be downloaded as a pre-built virtual machine from the [website][samuraiwtf-download]. + +#### What is SamuraiWTF? + +[Samurai Web Training Framework][samurai-wtf] is similar in spirit to the widely used [Kali Linux][kali] distribution; +it is a distribution of an Ubuntu desktop that integrates many open-source tools used for penetration testing. + +SamuraiWTF is different to Kali in that it is meant as a training environment for attacking web applications +rather than as a more general and comprehensive pen-testers toolkit. +It was originally a web testing framework tool, but has been migrated to a training tool for penetration testing. +For this reason it integrates a different set of tools from Kali; +it focuses only on the tools used during a web penetration test. + +[Samurai-Dojo][samurai-dojo] is a set of vulnerable web applications +that can be used to exercise the SamuraiWTF testing framework. +In addition there is the [Katana][samurai-katana] which provides configuration to install specific tools and targets. +This allows instructors to set up a classroom lab, for example, that can be distributed to their students. + +#### Why use it? + +SamuraiWTF is easy to use and comes as a virtual machine, which makes it ideal in a teaching environment +or as an attack tool targeted specifically against web applications. +The teaching environment can be tailored for a particular set of lessons using the command line tool 'katana'. + +The applications provided by Samurai-Dojo provides a set of real world applications to attack; +these applications are contained within the Samurai Web Training Framework virtual machine. +This provides a teaching environment where none of the attack traffic will leak from the environment, +and so avoids triggering network intrusion detection systems. + +#### How to use it + +The OWASP Spotlight series provides an overview of training provided by SamuraiWTF: +'Project 26 - [OWASP SamuraiWTF][spotlight26]'. + +Getting started with SamuraiWTF is described in the [github README][samuraiwtf-download] : + +* either download the virtual machine for Oracle VirtualBox +* or download the Hyper-V for Windows +* or build an Amazon Workspace + +Run the Samurai Web Training Framework and login as the super-user 'samurai'. +From a command prompt run 'katana' to start configuring SamuraiWTF for your training purposes, for example 'katana list'. + +![SamuraiWTF logo](../../../assets/images/logos/samurai_wtf.png "OWASP SamuraiWTF"){: .image-right } + +#### References + +* OWASP [SamuraiWTF][samuraiwtf] main site +* [SamuraiWTF Dojo][samurai-dojo] +* [SamuraiWTF Katana][samurai-katana] +* [SamuraiWTF downloads][samuraiwtf-download] +* SamuraiWTF [OWASP project][samuraiwtf-project] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0904] or [edit on GitHub][edit0904]. + +[edit0904]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/04-samurai-wtf.md +[issue0904]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2009-training-education/04-samurai-wtf +[kali]: https://www.kali.org/ +[samuraiwtf]: https://www.samuraiwtf.org/ +[samurai-dojo]: https://owasp.org/www-project-samuraiwtf/#div-dojo +[samurai-katana]: https://owasp.org/www-project-samuraiwtf/#div-katana +[samurai-wtf]: https://www.samurai-wtf.org/ +[samuraiwtf-download]: https://github.com/SamuraiWTF/samuraiwtf/blob/main/README.md +[samuraiwtf-project]: https://owasp.org/www-project-samuraiwtf/ +[spotlight26]: https://youtu.be/PBWUlx_kJmI diff --git a/release-ja/09-training-education/05-top-ten.md b/release-ja/09-training-education/05-top-ten.md new file mode 100644 index 00000000..61fc2eb1 --- /dev/null +++ b/release-ja/09-training-education/05-top-ten.md @@ -0,0 +1,94 @@ +--- + +title: OWASP Top 10 +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9230 +permalink: /release/training_education/owasp_top_ten/ + +--- + +{% include breadcrumb.html %} + +### 7.5 OWASP Top Ten project + +The OWASP Top 10 is a standard awareness document for developers and web application security. +It represents a broad consensus about the most critical security risks to web applications. + +The OWASP Top Ten is a flagship documentation project and is one of the very first OWASP projects. + +#### What is the OWASP Top 10? + +The OWASP [Top 10 Web Application Security Risks][top10project] project is probably the most well known security concept +within the security community, achieving wide spread acceptance and fame soon after its release in 2003. +Often referred to as just the 'OWASP Top Ten', it is a list that identifies the most important threats +to web applications and seeks to rank them in importance and severity. + +The OWASP Top 10 is periodically revised to keep it up to date with the latest threat landscape. +The latest version was released in 2021 to mark twenty years of OWASP: + +* [A01:2021-Broken Access Control][a01] +* [A02:2021-Cryptographic Failures][a02] +* [A03:2021-Injection][a03] +* [A04:2021-Insecure Design][a04] +* [A05:2021-Security Misconfiguration][a05] +* [A06:2021-Vulnerable and Outdated Components][a06] +* [A07:2021-Identification and Authentication Failures][a07] +* [A08:2021-Software and Data Integrity Failures][a08] +* [A09:2021-Security Logging and Monitoring Failures][a09] +* [A10:2021-Server-Side Request Forgery][a10] + +The project itself is actively maintained by a project team. +The list is [based on data][top10data] collected from identified application vulnerabilities and from a variety of sources; +security vendors and consultancies, bug bounties, along with company/organizational contributions. +The data is normalized to allow for level comparison between 'Human assisted Tooling and Tooling assisted Humans'. + +#### How to use it + +The OWASP Top 10 has various uses that are foundational to application security: + +* as a training aid on the most common web application vulnerabilities +* as a starting point when testing web applications +* to raise awareness of vulnerabilities in applications in general +* as a set of demonstration topics + +There is not one way to use this documentation project; use it in any way that promotes application security. +The OWASP Spotlight series provides an overview of the Top Ten: 'Project 10 - [Top10][spotlight10]'. + +#### OWASP Top 10 versions + +The OWASP Top 10 Web Application Security Risks document was originally published in 2003, +making it one of (or even the most) longest lived OWASP project, +and since then has been in active and continuous development. +Listed below are the versions up to the latest in 2021, which was released to mark 20 years of OWASP. + +* Original [2003](https://github.com/OWASP/Top10/blob/master/archives/OWASPWebApplicationSecurityTopTen-Version1.pdf) +* Update [2004](https://github.com/OWASP/Top10/blob/master/archives/OWASP_Top_Ten_2004.pdf) +* Update [2007](https://owasp.org/www-pdf-archive//OWASP_Top_10_2007.pdf) +* Release [2010](https://github.com/OWASP/OWASP-Top-10/tree/master/2010) +* Release [2013](https://github.com/OWASP/Top10/tree/master/2013) +* Release [2017](https://github.com/OWASP/Top10/tree/master/2017) +* Latest version [2021](https://github.com/OWASP/Top10/tree/master/2021) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0905] or [edit on GitHub][edit0905]. + +[a01]: https://owasp.org/Top10/A01_2021-Broken_Access_Control/ +[a02]: https://owasp.org/Top10/A02_2021-Cryptographic_Failures/ +[a03]: https://owasp.org/Top10/A03_2021-Injection/ +[a04]: https://owasp.org/Top10/A04_2021-Insecure_Design/ +[a05]: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/ +[a06]: https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/ +[a07]: https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/ +[a08]: https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/ +[a09]: https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/ +[a10]: https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/ +[edit0905]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/05-top-ten.md +[issue0905]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2009-training-education/05-top-ten +[spotlight10]: https://youtu.be/RMkoIrpz8ug +[top10project]: https://owasp.org/www-project-top-ten/ +[top10data]: https://owasp.org/www-project-top-ten/#div-data_2020 diff --git a/release-ja/09-training-education/06-mobile-top-ten.md b/release-ja/09-training-education/06-mobile-top-ten.md new file mode 100644 index 00000000..98bac09e --- /dev/null +++ b/release-ja/09-training-education/06-mobile-top-ten.md @@ -0,0 +1,103 @@ +--- + +title: Mobile Top 10 +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9240 +permalink: /release/training_education/mobile_top_ten/ + +--- + +{% include breadcrumb.html %} + +### 7.6 Mobile Top 10 + +The OWASP [Mobile Top 10][mobile10] is a list of the most prevalent vulnerabilities found in mobile applications. +In addition to the list of risks it also includes a list of security controls used to counter these vulnerabilities. + +This documentation project is an OWASP Lab project, aimed at security builders and defenders. + +#### What is the Mobile Top 10? + +The Mobile Top 10 identifies and lists the [top ten vulnerabilities][mobile10-2023] found in mobile applications. +These risks of application vulnerabilities have been determined by the project team from various sources +including incident reports, vulnerability databases, and security assessments. +The list has been built using a data-based approach from unbiased sources, +an approach detailed in the [repository][mobile10repo] read-me. + +* M1: [Improper Credential Usage][m01] +* M2: [Inadequate Supply Chain Security][m02] +* M3: [Insecure Authentication/Authorization][m03] +* M4: [Insufficient Input/Output Validation][m04] +* M5: [Insecure Communication][m05] +* M6: [Inadequate Privacy Controls][m06] +* M7: [Insufficient Binary Protections][m07] +* M8: [Security Misconfiguration][m08] +* M9: [Insecure Data Storage][m09] +* M10: [Insufficient Cryptography][m10] + +The project also provides a comprehensive list of [security controls and techniques][mobile10controls] +that should be applied to mobile applications to provide a minimum level of security: + +1. Identify and protect sensitive data on the mobile device +2. Handle password credentials securely on the device +3. Ensure sensitive data is protected in transit +4. Implement user authentication,authorization and session management correctly +5. Keep the backend APIs (services) and the platform (server) secure +6. Secure data integration with third party services and applications +7. Pay specific attention to the collection and storage of consent for the collection and use of the user’s data +8. Implement controls to prevent unauthorized access to paid-for resources (wallet, SMS, phone calls etc) +9. Ensure secure distribution/provisioning of mobile applications +10. Carefully check any runtime interpretation of code for errors + +The list of mobile controls has been created and maintained by a collaboration of OWASP +and the [European Network and Information Security Agency][enisa] (ENISA) to build a joint set of controls. + +#### Why use it? + +It is important to have awareness of the types of attack mobile applications are exposed to, +and the types of vulnerabilities that may be present in any given mobile application. + +The Mobile Top 10 provides a starting point for this training and education, +and it should be noted that the risks to mobile applications do not stop at the Top 10; +this list is only the more important ones and in practice there are many more risks. + +In addition the Mobile Top 10 provides a list of controls that should be considered for mobile applications; +ideally at the requirements stage of the development cycle (the sooner the better) +but they can be applied at any time during development. + +#### Mobile Top 10 versions + +The Mobile Top 10 was [first released in 2014][mobile10-2014], [updated in 2016][mobile10-2016] +with the latest version [released in 2024][mobile10-2023]. + +The list of mobile application [controls][mobile10controls] were originally published in 2011 by [ENISA][enisa] +as the 'Smartphone Secure Development Guideline'. +This was then revised during 2016, released in February 2017, to inform the latest set of mobile application controls. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0906] or [edit on GitHub][edit0906]. + +[edit0906]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/06-mobile-top-ten.md +[enisa]: https://www.enisa.europa.eu/ +[issue0906]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2009-training-education/06-mobile-top-ten +[m01]: https://owasp.org/www-project-mobile-top-10/2023-risks/m1-improper-credential-usage.html +[m02]: https://owasp.org/www-project-mobile-top-10/2023-risks/m2-inadequate-supply-chain-security.html +[m03]: https://owasp.org/www-project-mobile-top-10/2023-risks/m3-insecure-authentication-authorization.html +[m04]: https://owasp.org/www-project-mobile-top-10/2023-risks/m4-insufficient-input-output-validation.html +[m05]: https://owasp.org/www-project-mobile-top-10/2023-risks/m5-insecure-communication.html +[m06]: https://owasp.org/www-project-mobile-top-10/2023-risks/m6-inadequate-privacy-controls.html +[m07]: https://owasp.org/www-project-mobile-top-10/2023-risks/m7-insufficient-binary-protection.html +[m08]: https://owasp.org/www-project-mobile-top-10/2023-risks/m8-security-misconfiguration.html +[m09]: https://owasp.org/www-project-mobile-top-10/2023-risks/m9-insecure-data-storage.html +[m10]: https://owasp.org/www-project-mobile-top-10/2023-risks/m10-insufficient-cryptography.html +[mobile10]: https://owasp.org/www-project-mobile-top-10/ +[mobile10-2014]: https://owasp.org/www-project-mobile-top-10/2014-risks/ +[mobile10-2016]: https://owasp.org/www-project-mobile-top-10/2016-risks/ +[mobile10-2023]: https://owasp.org/www-project-mobile-top-10/2023-risks/ +[mobile10controls]: https://owasp.org/www-project-mobile-top-10/#div-controls +[mobile10repo]: https://github.com/OWASP/www-project-mobile-top-10/blob/master/README.md diff --git a/release-ja/09-training-education/07-api-top-ten.md b/release-ja/09-training-education/07-api-top-ten.md new file mode 100644 index 00000000..2f39bfa4 --- /dev/null +++ b/release-ja/09-training-education/07-api-top-ten.md @@ -0,0 +1,66 @@ +--- + +title: API Top 10 +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9250 +permalink: /release/training_education/api_top_ten/ + +--- + +{% include breadcrumb.html %} + +### 7.7 API Top 10 + +The OWASP [API Security Project][apisec] (API Top 10) explains strategies and solutions to help the understanding +and mitigation of the unique vulnerabilities and security risks of Application Programming Interfaces (APIs). + +The [API Top 10][apisec-project] is an OWASP Laboratory Project +which is accessed as a [web based document][apisec-doc]. + +#### What is the API Top 10? + +The use of Application Programming Interfaces (APIs) comes with security risks. +Given that APIs are widely used in various types of applications, +the OWASP API Security Project created and maintains the Top 10 API Security Risks document +as well as a documentation portal for best practices when creating or assessing APIs. + +* [API1:2023][api01] - Broken Object Level Authorization +* [API2:2023][api02] - Broken Authentication +* [API3:2023][api03] - Broken Object Property Level Authorization +* [API4:2023][api04] - Unrestricted Resource Consumption +* [API5:2023][api05] - Broken Function Level Authorization +* [API6:2023][api06] - Unrestricted Access to Sensitive Business Flows +* [API7:2023][api07] - Server Side Request Forgery +* [API8:2023][api08] - Security Misconfiguration +* [API9:2023][api09] - Improper Inventory Management +* [API10:2023][api10] - Unsafe Consumption of APIs + +#### Why use it? + +Most software projects use APIs in some form or another. +Developers and security engineers should be encouraged to refer to the [API Security Top 10][apisec] +to assist them when acting as security builders, breakers, and defenders for an organization. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0907] or [edit on GitHub][edit0907]. + +[api01]: https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ +[api02]: https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/ +[api03]: https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/ +[api04]: https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/ +[api05]: https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/ +[api06]: https://owasp.org/API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/ +[api07]: https://owasp.org/API-Security/editions/2023/en/0xa7-server-side-request-forgery/ +[api08]: https://owasp.org/API-Security/editions/2023/en/0xa8-security-misconfiguration/ +[api09]: https://owasp.org/API-Security/editions/2023/en/0xa9-improper-inventory-management/ +[api10]: https://owasp.org/API-Security/editions/2023/en/0xaa-unsafe-consumption-of-apis/ +[apisec]: https://owasp.org/API-Security +[apisec-doc]: https://owasp.org/API-Security/editions/2023/en/0x00-header/ +[apisec-project]: https://owasp.org/www-project-api-security/ +[edit0907]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/07-api-top-ten.md +[issue0907]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2009-training-education/07-api-top-ten diff --git a/release-ja/09-training-education/08-wrongsecrets.md b/release-ja/09-training-education/08-wrongsecrets.md new file mode 100644 index 00000000..3c5ff4eb --- /dev/null +++ b/release-ja/09-training-education/08-wrongsecrets.md @@ -0,0 +1,86 @@ +--- +title: WrongSecrets +layout: col-document +tags: OWASP Developer Guide +contributors: Ben de Haan +document: OWASP Developer Guide +order: 9260 +permalink: /release/training_education/wrongsecrets/ +--- + +{% include breadcrumb.html %} + + + +![WrongSecrets logo](../../../assets/images/logos/wrongsecrets.png "OWASP WrongSecrets"){: .image-right } + +### 7.8 WrongSecrets + +OWASP [WrongSecrets][wrongsecrets-project] is a production status project +and provides challenges focused on secrets management using an intentionally vulnerable application and environment. +The project offers standalone and Capture-the-flag modes, with a demo on [Heroku][wsheroku]. + +#### What is WrongSecrets? + +[WrongSecrets][wrongsecrets] goals are to: + +* Educate on secret management and its pitfalls +* Help people reflect on their secrets management strategy +* Promote secrets management as an important facet of security + +The project provides challenges around secrets management across several layers: + +* A Spring Boot Java application +* Application configuration +* Docker +* Kubernetes +* Vault +* AWS, GCP, or Azure +* Binaries / Reverse engineering + +Scenarios vary in difficulty, and you can solve some of them just by using the browser on your mobile phone. +For others, you would need knowledge of [cloud security][cscloud] or reverse engineering tools and cryptography. + +#### Why use it? + +If you, your team or your organization want to learn about secrets management and potential pitfalls, +you can do so with WrongSecrets' challenges. + +Alternatively, you can use WrongSecrets as a secret detector testbed/benchmark. + +#### How to use it + +You can set WrongSecrets up in standalone or in capture the flag (CTF) mode on Docker, Kubernetes, AWS, GCP or Azure. + +Set-up guides for the standalone version are available in the [project README][readme]. + +For the CTF, the project also provides [set-up guides][ctf] and a [Helm chart][wrongsecrets-helm]. + +#### References + +* OWASP [WrongSecrets][wrongsecrets-project] +* [Secure_Cloud_Architecture][cscloud] cheat sheet +* [WrongSecrets demo][wsheroku] + +--- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0908] or [edit on GitHub][edit0908]. + +[cscloud]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet +[ctf]: https://github.com/OWASP/wrongsecrets/blob/master/ctf-instructions.md +[edit0908]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/08-wrongsecrets.md +[wsheroku]: https://wrongsecrets.herokuapp.com/ +[issue0908]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2009-training-education/08-wrongsecrets +[readme]: https://github.com/OWASP/wrongsecrets/blob/master/README.md +[wrongsecrets]: https://github.com/OWASP/wrongsecrets +[wrongsecrets-helm]: https://owasp.org/wrongsecrets-ctf-party/ +[wrongsecrets-project]: https://owasp.org/www-project-wrongsecrets/ diff --git a/release-ja/09-training-education/09-snakes-ladders.md b/release-ja/09-training-education/09-snakes-ladders.md new file mode 100644 index 00000000..3602fa26 --- /dev/null +++ b/release-ja/09-training-education/09-snakes-ladders.md @@ -0,0 +1,101 @@ +--- + +title: OWASP Snakes & Ladders +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9270 + +permalink: /release/training_education/snakes_and_ladders/ + +--- + +{% include breadcrumb.html %} + + + +![Snakes & Ladders logo](../../../assets/images/logos/snakes_ladders.png "OWASP Snakes & Ladders"){: .image-right } + +### 7.9 OWASP Snakes and Ladders + +OWASP [Snakes & Ladders][snakes] is an educational project based on the popular board game. +It uses gamification to promote awareness of application security controls and risks, +and in particular knowledge of other OWASP documents and tools. + +This documentation project is an OWASP Lab project, aimed at security builders and defenders. + +#### What is it? + +Yes, it really is the snakes & ladders game, but for web and [mobile application security][csmas]. +[It is played][snakeshowto] by two competing teams, possibly accompanied by beer and pretzels. + +In the board game for web applications, the virtuous behaviors (ladders) are secure coding practices +(using the OWASP [Proactive Controls][proactive10]) and the vices (snakes) +are application security risks from the [OWASP Top Ten][top102017] 2017 version. + +The web application version can be downloaded for various languages: + +* [German](https://github.com/OWASP/www-project-snakes-and-ladders/tree/master/assets/files/web/DE) (DE) +* [English](https://github.com/OWASP/www-project-snakes-and-ladders/tree/master/assets/files/web/EN) (EN) +* [Spanish](https://github.com/OWASP/www-project-snakes-and-ladders/tree/master/assets/files/web/ES) (ES) +* [French](https://github.com/OWASP/www-project-snakes-and-ladders/tree/master/assets/files/web/FR) (FR) +* [Japanese](https://github.com/OWASP/www-project-snakes-and-ladders/tree/master/assets/files/web/JA) (JA) +* [Turkish](https://github.com/OWASP/www-project-snakes-and-ladders/tree/master/assets/files/web/TR) (TR) +* [Chinese](https://github.com/OWASP/www-project-snakes-and-ladders/tree/master/assets/files/web/ZH) (ZH) + +The board game for mobile applications uses the mobile controls +detailed in the [OWASP Mobile Top 10][mobile10controls] as the virtuous behaviors. +The vices are the [Mobile Top 10 risks][mobile10-2014] from the 2014 version of the project. + +The mobile application version is available as a download in +[English](https://github.com/OWASP/www-project-snakes-and-ladders/tree/master/assets/files/mob/EN) +and [Japanese](https://github.com/OWASP/www-project-snakes-and-ladders/tree/master/assets/files/mob/JA) + +#### Why use it? + +This board game was created so that it could be used as an ice-breaker in application security training. +It also has wider appeal as learning materials for developers or simply as a promotional hand-out. + +To cover all of that, the Snakes & Ladders project team summarize it as: + +"OWASP Snakes and Ladders is meant to be used by software programmers, big and small" + +The game is quite lightweight; so it is meant to be just some fun with some learning attached, +and is not intended to have the same rigor or depth as the card game [Cornucopia][cornucopia]. + +When the project was first created there was a print run of the game on heavy duty paper. +These were available at conferences and meetings - they were also available to be purchased online +but this last option no longer seems to be available. + +#### References + +* OWASP [Snakes & Ladders][snakes +* OWASP [Proactive Controls][proactive10] +* OWASP [Top Ten][top102017] 2017 version +* OWASP [Mobile Top 10][mobile10controls] +* OWASP [Cornucopia][cornucopia]. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0909] or [edit on GitHub][edit0909]. + +[cornucopia]: https://owasp.org/www-project-cornucopia/ +[csmas]: https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet +[edit0909]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/09-snakes-ladders.md +[issue0909]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2009-training-education/09-snakes-ladders +[mobile10-2014]: https://owasp.org/www-project-mobile-top-10/2014-risks/ +[mobile10controls]: https://owasp.org/www-project-mobile-top-10/#div-controls +[proactive10]: https://owasp.org/www-project-proactive-controls/ +[snakes]: https://owasp.org/www-project-snakes-and-ladders/ +[snakeshowto]: https://owasp.org/www-project-snakes-and-ladders/#div-play +[top102017]: https://owasp.org/www-project-top-ten/2017/ diff --git a/release-ja/09-training-education/info.md b/release-ja/09-training-education/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/09-training-education/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/09-training-education/toc.md b/release-ja/09-training-education/toc.md new file mode 100644 index 00000000..a4ec0e34 --- /dev/null +++ b/release-ja/09-training-education/toc.md @@ -0,0 +1,74 @@ +--- + +title: Training and Education +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 9000 +permalink: /release/training_education/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){: .image-right } + +## 7. Training and Education + +Training and Education activities are described by in the SAMM [Training and Awareness][sammgegta] section, +which in turn is part of the SAMM [Education & Guidance][sammgeg] security practice +within the [Governance][sammg] business function. + +The goal of security training and education is to increase the awareness of application security threats and risks +along with security best practices and secure software design principles. +The security awareness training should be customized for all roles currently involved in the management, +development, testing, or auditing of the applications and systems. +In addition a Learning Management System or equivalent should be in place to track +the employee training and certification processes. + +It is important to provide activities for development teams; +we are all human and our security knowledge can become stale without a plan for refreshing it. +The [Security Culture][cultureacts] project describes various activities that can help developers +keep up to date and motivated. + +OWASP provides various resources and environments that can help with this security training and education +ranging from vulnerable applications, training platforms and gamification. + +Sections: + +7.1 [Vulnerable Applications](01-vulnerable-apps/toc.md) +7.1.1 [Juice Shop](01-vulnerable-apps/01-juice-shop.md) +7.1.2 [WebGoat](01-vulnerable-apps/02-webgoat.md) +7.1.3 [PyGoat](01-vulnerable-apps/03-pygoat.md) +7.1.4 [Security Shepherd](01-vulnerable-apps/04-security-shepherd.md) +7.2 [Secure Coding Dojo](02-secure-coding-dojo.md) +7.3 [SKF education](03-skf.md) +7.4 [SamuraiWTF](04-samurai-wtf.md) +7.5 [OWASP Top 10 project](05-top-ten.md) +7.6 [Mobile Top 10](06-mobile-top-ten.md) +7.7 [API Top 10](07-api-top-ten.md) +7.8 [WrongSecrets](08-wrongsecrets.md) +7.9 [OWASP Snakes and Ladders](09-snakes-ladders.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0900] or [edit on GitHub][edit0900]. + +[cultureacts]: https://owasp.org/www-project-security-culture/stable/5-Activities/ +[edit0900]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/09-training-education/toc.md +[issue0900]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2009-training-education/00-toc +[sammg]: https://owaspsamm.org/model/governance/ +[sammgeg]: https://owaspsamm.org/model/governance/education-and-guidance/ +[sammgegta]: https://owaspsamm.org/model/governance/education-and-guidance/stream-a/ diff --git a/release-ja/10-culture-process/00-toc.md b/release-ja/10-culture-process/00-toc.md new file mode 100644 index 00000000..118f3d7e --- /dev/null +++ b/release-ja/10-culture-process/00-toc.md @@ -0,0 +1,47 @@ +--- + +title: Culture Building and Process Maturing +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){height=180px} + +## 8. Culture building and Process maturing + +Culture building and Process maturing is described by the SAMM [Organization and Culture][sammgegoc] activity, +which in turn is part of the SAMM [Education & Guidance][sammgeg] security practice +within the [Governance][sammg] business function. + +The maturity of security processes and culture is wide ranging, with indicators of a mature process and culture including: + +* Security champions have been identified for each development team +* A program is in place to support the security champions +* Secure coding practices are in place to define standards and improve software development +* Developers and application security professionals across the organization are able to communicate and share best practice + +Sections: + +8.1 [Security Culture](#security-culture) +8.2 [Security Champions](#security-champions) +8.2.1 [Security champions program](#security-champions-program) +8.2.2 [Security Champions Guide](#security-champions-guide) +8.2.3 [Security Champions Playbook](#security-champions-playbook) +8.3 [SAMM](#samm) +8.4 [ASVS process](#asvs-process) +8.5 [MAS process](#mas-process) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue1000]. + +[issue1000]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2010-culture-process/00-toc +[sammg]: https://owaspsamm.org/model/governance/ +[sammgeg]: https://owaspsamm.org/model/governance/education-and-guidance/ +[sammgegoc]: https://owaspsamm.org/model/governance/education-and-guidance/stream-b/ diff --git a/release-ja/10-culture-process/01-security-culture.md b/release-ja/10-culture-process/01-security-culture.md new file mode 100644 index 00000000..58b0c37e --- /dev/null +++ b/release-ja/10-culture-process/01-security-culture.md @@ -0,0 +1,97 @@ +--- + +title: Security Culture +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 10010 +permalink: /release/culture_building_and_process_maturing/security_culture/ + +--- + +{% include breadcrumb.html %} + +### 8.1 Security Culture + +Most organizations have an application development lifecycle in place with security activities built into it, +this goes a long way to reducing the security issues present in applications and systems. +The OWASP [Security Culture project][culture] is a guide that considers security +at each stage of the application security development lifecycle, +with the aim of creating and nurturing secure development practices throughout the lifecycle. + +The Security Culture guide is an [OWASP incubator project][culturerepo] +and the latest stable version is available as a [web document][culturedoc]. + +#### What is the OWASP Security Culture project + +The OWASP [Security Culture project][culture] is a collection of explanations and practical advice +arranged under various topic headings. + +* [Why add security][culturewhy] in development teams +* [Setting maturity goals][culturegoal] +* [Security team collaboration][culturegoal] +* [Security champions][culturechamps] +* [Activities][cultureacts] +* [Threat modeling][culturetm] +* [Security testing][culturetest] +* [Security related metrics][culturemetrics] + +The OWASP Security Culture project is focused on establishing/persisting +a positive security posture within the application development lifecycle +and references other OWASP projects in a similar way to the OWASP Developer Guide. + +#### Encouraging a Security Culture + +The philosophy of a security culture is as important as the technical aspects; +the application development teams need to be onboard to adopt a good security posture. +The Security Culture project recognizes this and devotes a [section][culturewhy] to the importance +of building security into the development lifecycle. + +As well as onboard development teams there has to be buy-in from the higher management: +without this any security champion program is certain to fail and the security culture of the organization will suffer. +The Security Culture project provides information on [goals, metrics and maturity models][culturegoal] +that are a necessary prerequisite for management approval of security activities. +In addition the Security Culture project highlights the importance of security teams, +management and development teams all working together - all are necessary for a good security culture. + +Security Champions are an important way of encouraging security within an organization - an organization can have a +healthy security culture without security champions but it is a lot easier with a security champion program in place. +Selecting and nurturing [security champions][culturechamps] has to be tailored to the individual organization, +no security champion program will be the same as another one and close reference should be made to +the [Security Champions Playbook][scplaybook]. + +[Threat modeling][culturetm] is an activity that in itself is important within an organization, +and it also has the benefit of helping communication between the security teams and development teams. +[Security testing][culturetest] (such as [SAST][dsosast], [DAST][dsodast] and [IAST][dsoiast]) +is another area where close collaboration is required within the organization: +management, security, development and pipeline teams will all be involved. +This has the added benefit, as with threat modeling, of promoting a good security culture / awareness +within the organization - and can be a good indicator of where the security culture is succeeding. + +[Metrics][culturemetrics] are important for a healthy security culture to persist and grow with an organization. +Without metrics to show the benefits of the security culture then interest and buy-in from the various +teams involved will wane, leading to a decline in the culture and leading in turn to a poor security posture. +Metrics will provide the justification for investment and nurturing of a good security culture. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1001] or [edit on GitHub][edit1001]. + +[issue1001]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2010-culture-process/01-security-culture +[edit1001]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/10-culture-process/01-security-culture.md +[culture]: https://owasp.org/www-project-security-culture/ +[cultureacts]: https://owasp.org/www-project-security-culture/stable/5-Activities/ +[culturechamps]: https://owasp.org/www-project-security-culture/stable/4-Security_Champions/ +[culturedoc]: https://owasp.org/www-project-security-culture/stable/ +[culturegoal]: https://owasp.org/www-project-security-culture/stable/3-Goal_Setting_and_Security_Team_Collaboration/ +[culturemetrics]: https://owasp.org/www-project-security-culture/stable/8-Metrics/ +[culturerepo]: https://github.com/OWASP/www-project-security-culture +[culturetest]: https://owasp.org/www-project-security-culture/stable/7-Security_Testing/ +[culturetm]: https://owasp.org/www-project-security-culture/stable/6-Threat_Modelling/ +[culturewhy]: https://owasp.org/www-project-security-culture/stable/2-Why_Add_Security_In_Development_Teams/ +[dsodast]: https://owasp.org/www-project-devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing +[dsoiast]: https://owasp.org/www-project-devsecops-guideline/latest/02c-Interactive-Application-Security-Testing +[dsosast]: https://owasp.org/www-project-devsecops-guideline/latest/02a-Static-Application-Security-Testing +[scplaybook]: https://github.com/c0rdis/security-champions-playbook diff --git a/release-ja/10-culture-process/02-security-champions/00-toc.md b/release-ja/10-culture-process/02-security-champions/00-toc.md new file mode 100644 index 00000000..b7799745 --- /dev/null +++ b/release-ja/10-culture-process/02-security-champions/00-toc.md @@ -0,0 +1,61 @@ +--- + +title: Security Champions +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 8.2 Security Champions + +A 'Security Champion' is a member of a software development team who is +the liaison between Information Security and developers. +This helps to embed security into the development organization. + +Security Champions and the necessary supporting program are described in +the SAMM [Organization and Culture][sammgegtb] section, +which in turn is part of the SAMM [Education & Guidance][sammgeg] security practice +within the [Governance][sammg] business function. + +Depending on the development team the Security Champion may be a software developer, tester, product manager +or any role within the team; what matters most is an enthusiasm for software security and a willingness to learn. +Security Champions can assist with researching, verifying, +and prioritizing security and compliance related software defects within the application/product. + +Security Champions will usually be involved in risk/threat assessments and architectural reviews +and can often help identify opportunities to remediate security defects; +making the architecture of the application more resilient and reducing the attack threat surface. +Security Champions also participate in periodic briefings to increase awareness +and expertise in different security disciplines. + +The two goals of the Security Champion program are to increase effectiveness of application security and compliance +and to strengthen the relationship between development teams and Information Security teams. +The program should supply Security Champions with additional training +to help develop their role as a software security subject matter expert. +If possible the Security Champion should be provided with time for Information Security related activities, +and this may well have to be negotiated with the development management hierarchy. + +Importantly it should be recognized that Security Champions are often taking on an extra role +in addition to their existing one, and it is important that support is provided by the program for their well-being. + +Sections: + +8.2.1 [Security champions program](#security-champions-program) +8.2.2 [Security Champions Guide](#security-champions-guide) +8.2.3 [Security Champions Playbook](#security-champions-playbook) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue1020]. + +[issue1020]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2010-culture-process/02-security-champions/00-toc +[sammg]: https://owaspsamm.org/model/governance/ +[sammgeg]: https://owaspsamm.org/model/governance/education-and-guidance/ +[sammgegtb]: https://owaspsamm.org/model/governance/education-and-guidance/stream-b/ diff --git a/release-ja/10-culture-process/02-security-champions/01-security-champions-program.md b/release-ja/10-culture-process/02-security-champions/01-security-champions-program.md new file mode 100644 index 00000000..f9cf7464 --- /dev/null +++ b/release-ja/10-culture-process/02-security-champions/01-security-champions-program.md @@ -0,0 +1,99 @@ +--- + +title: Security Champions Program +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 10210 +permalink: /release/culture_building_and_process_maturing/security_champions/program/ + +--- + +{% include breadcrumb.html %} + +### 8.2.1 Security champions program + +A Security Champion program is a commonly used way of helping development teams successfully run a development lifecycle +that is secure, and this is achieved by selecting members of teams to become Security Champions. +The role of Security Champion is described by the OWASP Software Assurance Maturity Model [(SAMM)][sammgegoc] +Organization and Culture activities within the Governance business function of the Education & Guidance practice. + +#### Overview + +It can be hard to introduce a security mindset across development teams using the application security team alone; +security engineers do not scale well across teams of developers - there is simply not enough of them. +A good way to scale security and distribute security across development teams is by creating a security champion role +and providing a Security Champions program to encourage a community spirit within the organization. +This will help foster a positive security culture within the organization, +see the [Security Culture project][culturechamps] on how this can be done with security champions. + +Security champions are usually individuals within each development team that show special interest in application security. +The security champion provides a knowledgeable point of contact between the application security team and development, +and in addition they can ensure that the development lifecycle has security built in. +Often the security champion carries on with their original role within the development team, in addition to their new role, +and so a Security Champions program is important for providing support and training and avoiding burn-out. + +#### Security champion role + +Security champions are active members of a development team that act as the "voice" of security within their team. +Security champions also provide visibility of their team's security activities to the application security team, +and are seen as the first point of contact between developers and a central security team. + +There is no universally defined role for a security champion, but the [Security Culture project][culturechamps] +provides various suggestions: + +* Evangelize security: promoting security best practice in their team, + imparting security knowledge and helping to uplift security awareness in their team +* Contribute to security standards: provide input into organizational security standards and procedures +* Help run activities: promote activities such as Capture the Flag events or secure coding training +* Oversee threat modeling: threat modeling consists of a security review on a product in the design phase +* Oversee secure code reviews: raise issues of risk in the code base that arise from peer group code reviews +* Use security testing tools: provide support to their team for the use of security testing tools + +The security champion role requires a passion and interest in application security, +and so arbitrarily assigning this role is unlikely to work in practice. +A better strategy is to provide a security champions program, so that developers who are interested can come forward; +in effect they should self-select. + +#### Security champions program + +It can be tough being a security champion: usually they are still expected to do their 'day job' but in addition +they are expected to be knowledgeable on security matters and to take extra training. +Relying on good will and cheerful interest will only go so far, and a Security Champions program should be put in place +to identify, nurture, support and train the security champions. + +The OWASP [Security Champions Guide][scguide] identifies ten key principles for a successful Security Champions program: + +* Be passionate about security - identify the members of the teams that show interest in security +* Start with a clear vision for your program - be practical but ambitious, after if it works then it will work well +* Secure management support - as always, going it alone without management support is never going to work +* Nominate a dedicated captain - the program will take organization and maintaining, so find someone willing to do that +* Trust your champions - they are usually highly motivated when it comes to the security of their own applications +* Create a community - it can be lonely, so provide a support network +* Promote knowledge sharing - if the community is in place, then encourage discussions and meet-ups +* Reward responsibility - they are putting extra work, so appreciate them +* Invest in your champions - the knowledge gained through extra training will pay for itself many times over +* Anticipate personnel changes - the security champion may move on, be alert to this and plan for it + +A successful security champions program will increase the security of the applications / systems, allay developer's fears, +increase the effectiveness of the application security team and improve the security posture of the organization as a whole. + +#### References + +* [Security Champions Playbook][scplaybook] +* OWASP [Security Champions Guide][scguide] +* OWASP [Security Culture][culturedoc] project + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1021] or [edit on GitHub][edit1021]. + +[edit1021]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/10-culture-process/02-security-champions/01-security-champions-program.md +[issue1021]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2010-culture-process/02-security-champions/01-security-champions-program +[sammgegoc]: https://owaspsamm.org/model/governance/education-and-guidance/stream-b/ +[scguide]: https://owasp.org/www-project-security-champions-guidebook/ +[scplaybook]: https://github.com/c0rdis/security-champions-playbook +[culturechamps]: https://owasp.org/www-project-security-culture/stable/4-Security_Champions/ +[culturedoc]: https://owasp.org/www-project-security-culture/stable/ diff --git a/release-ja/10-culture-process/02-security-champions/02-security-champions-guide.md b/release-ja/10-culture-process/02-security-champions/02-security-champions-guide.md new file mode 100644 index 00000000..dcec924b --- /dev/null +++ b/release-ja/10-culture-process/02-security-champions/02-security-champions-guide.md @@ -0,0 +1,99 @@ +--- + +title: Security Champions Guide +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 10220 +permalink: /release/culture_building_and_process_maturing/security_champions/security_champions_guide/ + +--- + +{% include breadcrumb.html %} + + + +![Guide logo](../../../../assets/images/logos/secchampsguide.png "Security Champions Guide"){: .image-right } + +### 8.2.2 Security Champions Guide + +The OWASP [Security Champions Guide][scguide] is a guidebook that helps organizations build +a security champions program that can succeed over the long term. + +It is a relatively new [OWASP Incubator project][scguiderepo] and is available as a [web document][scguidedoc]. + +#### Overview + +Security Champions are an important part of an organization's security posture; they provide development teams +with subject matter experts in application security and can be the first point of contact for information security teams. +It is widely recognized that a program needs to be in place to actively support the security champions, +otherwise there is a risk of disillusionment or even burn-out; +to counter this risk a Security Champions Program will help identify and nurture security champions. + +The [Security Champions Guide][scguide] provides two resources that explain what a security champion program is +and how it can be put into practice: + +* The Security Champions Manifesto sets out a philosophy for a good security champions program +* The Security Champions Guide explains each point in the manifesto and illustrates it with practical advice + +The Security Champions Guide is not proscriptive, an individual organization should select freely from the suggestions +to create its own program - and perhaps revisit the guide as its security champions program matures over time. + +#### The Security Champions Manifesto + +The manifesto defines ten key principles for a successful security champions program: + +* Be passionate about security +* Start with a clear vision for your program +* Secure management support +* Nominate a dedicated captain +* Trust your champions +* Create a community +* Promote knowledge sharing +* Reward responsibility +* Invest in your champions +* Anticipate personnel changes + +This manifesto is a set of guiding principles that will certainly help with the creating the program +and can also improve an existing security champions program. + +#### The Security Champions Guide + +If the security champions program is in the process of being put in place +then consider each principle/section of the guide in turn and decide if it can be part of the program. +Each principle is generally applicable - as every program will be different in practice - so pick and choose +the elements the organization can adopt or leverage to create a customized program. + +Each principle is split into topics: the What, Why and How. +Some sections also contain checklists or templates that can be used to create or improve the program. +For example the section on investing in security champions explains what this entails: +'Invest in the personal growth and development of your Security Champions'. +It then goes on to describe why this is important (ensuring the health of the Security Champions community) +and then gives suggestions on what this means in practice: webinars, conferences, recognition etc. +The other sections are similarly helpful and provide a range of practical advice. + +The guide is also useful for an existing security champions program, providing advice on what can be further achieved. +It is worth noting that some security champions programs are initially successful but can then fail over time +for various reasons, perhaps through change of personnel or budgetary pressure. +The suggestions in the Security Champions Guide can be used as a justification for investing in the program further +and will help to sustain the existing program. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1022] or [edit on GitHub][edit1022]. + +[issue1022]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2010-culture-process/02-security-champions/02-security-champions-guide +[edit1022]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/10-culture-process/02-security-champions/02-security-champions-guide.md +[scguide]: https://owasp.org/www-project-security-champions-guidebook/ +[scguidedoc]: https://owasp.org/www-project-security-champions-guidebook/#div-principles +[scguiderepo]: https://github.com/OWASP/www-project-security-champions-guidebook diff --git a/release-ja/10-culture-process/02-security-champions/03-security-champions-playbook.md b/release-ja/10-culture-process/02-security-champions/03-security-champions-playbook.md new file mode 100644 index 00000000..ddd50c15 --- /dev/null +++ b/release-ja/10-culture-process/02-security-champions/03-security-champions-playbook.md @@ -0,0 +1,55 @@ +--- + +title: Security Champions Playbook +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 10230 +permalink: /release/culture_building_and_process_maturing/security_champions/security_champions_playbook/ + +--- + +{% include breadcrumb.html %} + +### 8.2.3 Security Champions Playbook + +The [Security Champions Playbook][sec-champs] is a project that describes the process of establishing +a Security Champions program within an organization. + +#### What are Security Champions? + +Security Champions are active members of a team that act as a core element of the security assurance process +within a product or service. +They are often are the initial point of contact within the team when it comes to security concerns and incidents. + +Some advantages of encouraging Security Champions within a team are : + +* Scaling security through multiple teams +* Engaging non-security engineers in security +* Establishing the security culture throughout an organization + +The Security Champion should be given extra training to carry out this role, +which is often in addition to their existing responsibilities. + +#### How to use the playbook + +Security Champions Playbook lists six steps which include general recommendations: + +1. [Identify teams](https://github.com/c0rdis/security-champions-playbook/blob/master/Security%20Playbook/1.%20Identify%20teams.md) +2. [Define the role](https://github.com/c0rdis/security-champions-playbook/blob/master/Security%20Playbook/2.%20Define%20the%20role.md) +3. [Nominate Champions](https://github.com/c0rdis/security-champions-playbook/blob/master/Security%20Playbook/3.%20Nominate%20Champions.md) +4. [Set up communication channels](https://github.com/c0rdis/security-champions-playbook/blob/master/Security%20Playbook/4.%20Set%20up%20communication%20channels.md) +5. [Build solid knowledge base](https://github.com/c0rdis/security-champions-playbook/blob/master/Security%20Playbook/5.%20Build%20solid%20knowledge%20base.md) +6. [Maintain interest](https://github.com/c0rdis/security-champions-playbook/blob/master/Security%20Playbook/6.%20Maintain%20interest.md) + +Use these recommendations to build up a Security Champions program that is tailored to the needs of the organization. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1023] or [edit on GitHub][edit1023]. + +[issue1023]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2010-culture-process/02-security-champions/03-security-champions-playbook +[edit1023]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/10-culture-process/02-security-champions/03-security-champions-playbook.md +[sec-champs]: https://github.com/c0rdis/security-champions-playbook diff --git a/release-ja/10-culture-process/02-security-champions/info.md b/release-ja/10-culture-process/02-security-champions/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/10-culture-process/02-security-champions/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/10-culture-process/02-security-champions/toc.md b/release-ja/10-culture-process/02-security-champions/toc.md new file mode 100644 index 00000000..860195df --- /dev/null +++ b/release-ja/10-culture-process/02-security-champions/toc.md @@ -0,0 +1,74 @@ +--- + +title: Security Champions +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 10200 +permalink: /release/culture_building_and_process_maturing/security_champions/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 8.2 Security Champions + +A 'Security Champion' is a member of a software development team who is +the liaison between Information Security and developers. +This helps to embed security into the development organization. + +Security Champions and the necessary supporting program are described in +the SAMM [Organization and Culture][sammgegtb] section, +which in turn is part of the SAMM [Education & Guidance][sammgeg] security practice +within the [Governance][sammg] business function. + +Depending on the development team the Security Champion may be a software developer, tester, product manager +or any role within the team; what matters most is an enthusiasm for software security and a willingness to learn. +Security Champions can assist with researching, verifying, +and prioritizing security and compliance related software defects within the application/product. + +Security Champions will usually be involved in risk/threat assessments and architectural reviews +and can often help identify opportunities to remediate security defects; +making the architecture of the application more resilient and reducing the attack threat surface. +Security Champions also participate in periodic briefings to increase awareness +and expertise in different security disciplines. + +The two goals of the Security Champion program are to increase effectiveness of application security and compliance +and to strengthen the relationship between development teams and Information Security teams. +The program should supply Security Champions with additional training +to help develop their role as a software security subject matter expert. +If possible the Security Champion should be provided with time for Information Security related activities, +and this may well have to be negotiated with the development management hierarchy. + +Importantly it should be recognized that Security Champions are often taking on an extra role +in addition to their existing one, and it is important that support is provided by the program for their well-being. + +Sections: + +8.2.1 [Security champions program](01-security-champions-program.md) +8.2.2 [Security Champions Guide](02-security-champions-guide.md) +8.2.3 [Security Champions Playbook](03-security-champions-playbook.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1020] or [edit on GitHub][edit1020]. + +[edit1020]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/10-culture-process/02-security-champions/toc.md +[issue1020]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2010-culture-process/02-security-champions/00-toc +[sammg]: https://owaspsamm.org/model/governance/ +[sammgeg]: https://owaspsamm.org/model/governance/education-and-guidance/ +[sammgegtb]: https://owaspsamm.org/model/governance/education-and-guidance/stream-b/ diff --git a/release-ja/10-culture-process/03-samm.md b/release-ja/10-culture-process/03-samm.md new file mode 100644 index 00000000..d509d9b0 --- /dev/null +++ b/release-ja/10-culture-process/03-samm.md @@ -0,0 +1,103 @@ +--- + +title: SAMM +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 10300 +permalink: /release/culture_building_and_process_maturing/samm/ + +--- + +{% include breadcrumb.html %} + + + +![SAMM logo](../../../assets/images/logos/samm.png "OWASP SAMM"){: .image-right-small } + +### 8.3 SAMM + +The [Software Assurance Maturity Model][samm] (SAMM) project provides an effective and measurable way for +an organization to analyze and improve their secure development lifecycle processes. +SAMM is one of the OWASP's flagship projects, and can be downloaded from the [SAMM project site][samm-project]. + +#### What is SAMM? + +SAMM can be regarded as the prime maturity model for software assurance. +SAMM provides an effective and measurable way for all types of organizations to analyze and improve +their software security posture. +SAMM supports the entire secure software development lifecycle and is technology and process agnostic. + +The SAMM model is hierarchical. At the highest level SAMM defines five business functions; +activities that software development must fulfill to some degree: + +* [Governance][sammg] +* [Design][sammd] +* [Implementation][sammi] +* [Verification][sammv] +* [Operations][sammo] + +Each business function in turn has three security practices, +which are areas of security-related activities that build assurance for the related business function. + +Security practices have activities, grouped in logical flows and divided into two streams (A and B). +Streams cover different aspects of a practice and have their own objectives, +aligning and linking the activities in the practice over the different maturity levels. + +For each security practice, SAMM defines three maturity levels which generalize to foundational, mature and advanced. +Each level has a successively more sophisticated objective with specific activities, and more strict success metrics. + +#### Why use it? + +The structure and setup of the SAMM model support: + +* assessment of the organization’s current software security posture +* definition of the organization’s targets +* definition of an implementation roadmap to get there +* prescriptive advice on how to implement particular activities + +These provide suggestions for improving processes and building security practices into the culture of the organization. + +#### How to use it + +The OWASP Spotlight series provides an overview of using the SAMM to guide development: +'Project 9 - [Software Assurance Maturity Model (SAMM)][spotlight09]'. + +The [SAMM Fundamentals Course][sammfun] provides training on the high level SAMM Business Functions +and provides guidance on each Security Practice. +The SAMM [assessment tools][samma] measure the quality of an organization's software assurance maturity process, +which can be used as feedback into the culture of the organization. + +#### References + +* OWASP [Software Assurance Maturity Model][samm] (SAMM) +* [SAMMY][sammy] management tool +* OWASP [SAMM project][samm-project] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1003] or [edit on GitHub][edit1003]. + +[edit1003]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/10-culture-process/03-samm.md +[issue1003]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2010-culture-process/03-samm +[samm]: https://owaspsamm.org/about/ +[samma]: https://owaspsamm.org/assessment/ +[sammd]: https://owaspsamm.org/model/design/ +[sammfun]: https://owaspsamm.thinkific.com/courses/samm +[sammg]: https://owaspsamm.org/model/governance/ +[sammi]: https://owaspsamm.org/model/implementation/ +[sammo]: https://owaspsamm.org/model/operations/ +[sammv]: https://owaspsamm.org/model/verification/ +[samm-project]: https://owasp.org/www-project-samm/ +[sammy]: https://sammy.codific.com/ +[spotlight09]: https://youtu.be/N0zcZnkH5Wg diff --git a/release-ja/10-culture-process/04-asvs.md b/release-ja/10-culture-process/04-asvs.md new file mode 100644 index 00000000..092678da --- /dev/null +++ b/release-ja/10-culture-process/04-asvs.md @@ -0,0 +1,113 @@ +--- + +title: ASVS process +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 10400 +permalink: /release/culture_building_and_process_maturing/asvs/ + +--- + +{% include breadcrumb.html %} + +### 8.4 ASVS process + +The [Application Security Verification Standard][asvs] (ASVS) is a long established OWASP flagship project, +and is widely used to build a culture of security as well as verification of web applications. + +It can be downloaded from the [OWASP project page][asvs] in various languages and formats: +PDF, Word, CSV, XML and JSON. Having said that, the recommended way to consume the ASVS is to access +the [github markdown][asvsmd] pages directly - this will ensure that the latest version is used. + +#### What is ASVS? + +The ASVS is an open standard that sets out the coverage and level of rigor expected when it comes to +performing web application security verification. +The standard also provides a basis for testing any technical security controls +that are relied on to protect against vulnerabilities in the application. + +The ASVS is split into various sections: + +* V1 [Architecture, Design and Threat Modeling][asvsV1] +* V2 [Authentication][asvsV2] +* V3 [Session Management][asvsV3] +* V4 [Access Control][asvsV4] +* V5 [Validation, Sanitization and Encoding][asvsV5] +* V6 [Stored Cryptography][asvsV6] +* V7 [Error Handling and Logging][asvsV7] +* V8 [Data Protection][asvsV8] +* V9 [Communication][asvsV9] +* V10 [Malicious Code][asvsV10] +* V11 [Business Logic][asvsV11] +* V12 [Files and Resources][asvsV12] +* V13 [API and Web Service][asvsV13] +* V14 [Configuration][asvsV14] + +The ASVS defines three [levels of security verification][asvsL123]: + +1. applications that only need low assurance levels; these applications are completely penetration testable +2. applications which contain sensitive data that require protection; the recommended level for most applications +3. the most critical applications that require the highest level of trust + +Most applications will aim for Level 2, with only those applications that perform high value transactions, +or contain sensitive medical data, aiming for the highest level of trust at level 3. + +#### Why use it? + +The ASVS is well established, the earlier versions were written in 2008, and it has been continually supported since then. +The ASVS is used to generate security requirements, guide the verification process +and also to identify gaps in the application security. + +The ASVS can also be used as a metric on how mature application security processes are; +it is a yardstick with which to assess the degree of trust that can be placed in the web application. +This helps provide a good security culture: the application developers and application owners can see how they are doing +and be confident in the maturity of their processes in comparison with other teams and organizations. + +#### How to use it + +The OWASP Spotlight series provides an overview of the ASVS and its uses: +'Project 19 - [OWASP Application Security Verification standard (ASVS)][spotlight19]'. + +The appropriate ASVS level should be chosen from: + +* Level 1: First steps, automated, or whole of portfolio view +* Level 2: Most applications +* Level 3: High value, high assurance, or high safety + +This is not a judgmental ranking, for example if an application needs only Level 1 protection then that is a valid choice. +Tools such as [SecurityRAT][srat] can then help create a subset of the ASVS security requirements for consideration. + +Application developer teams and application owners can then gain familiarity with the appropriate security +requirements and incorporate them into the process and culture of the organization. +To help navigate the ASVS, the OWASP Cheat Sheets have been indexed specifically +for [each section of the ASVS][csasvs] which can be used to explain and expand on each requirements category. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1004] or [edit on GitHub][edit1004]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[asvsL123]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x03-Using-ASVS.md#application-security-verification-levels +[asvsmd]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x00-Header.md +[asvsV1]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x10-V1-Architecture.md#v1-architecture-design-and-threat-modeling +[asvsV2]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x11-V2-Authentication.md#v2-authentication +[asvsV3]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x12-V3-Session-management.md#v3-session-management +[asvsV4]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x12-V4-Access-Control.md#v4-access-control +[asvsV5]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md#v5-validation-sanitization-and-encoding +[asvsV6]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x14-V6-Cryptography.md#v6-stored-cryptography +[asvsV7]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x15-V7-Error-Logging.md#v7-error-handling-and-logging +[asvsV8]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x16-V8-Data-Protection.md#v8-data-protection +[asvsV9]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x17-V9-Communications.md#control-objective +[asvsV10]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x18-V10-Malicious.md#v10-malicious-code +[asvsV11]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x19-V11-BusLogic.md#v11-business-logic +[asvsV12]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x20-V12-Files-Resources.md#v12-files-and-resources +[asvsV13]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x21-V13-API.md#v13-api-and-web-service +[asvsV14]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x22-V14-Config.md#v14-configuration +[csasvs]: https://cheatsheetseries.owasp.org/IndexASVS.html +[edit1004]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/10-culture-process/04-asvs.md +[issue1004]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2010-culture-process/04-asvs +[spotlight19]: https://youtu.be/3puIavsZfAk +[srat]: https://owasp.org/www-project-securityrat/ diff --git a/release-ja/10-culture-process/05-mas.md b/release-ja/10-culture-process/05-mas.md new file mode 100644 index 00000000..1bb95c0f --- /dev/null +++ b/release-ja/10-culture-process/05-mas.md @@ -0,0 +1,79 @@ +--- + +title: MAS +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 10500 +permalink: /release/culture_building_and_process_maturing/mas/ + +--- + +{% include breadcrumb.html %} + + + +![MAS logo](../../../assets/images/logos/mas.png "OWASP MAS"){: .image-right } + +### 8.5 MAS process + +The [MAS Verification Standard][masvs] (MASVS) explains the processes, techniques +and tools used for security testing a mobile application. + +The OWASP [MAS Crackmes][mascrack], also known as UnCrackable Apps, +is a collection of reverse engineering challenges for the OWASP [Mobile Application Security][masproject] (MAS). + +#### What is MAS Crackmes? + +OWASP [MAS Crackmes][mascrack] is a set of reverse engineering challenges for mobile applications. +These challenges are used as examples throughout the OWASP [Mobile Application Security Testing Guide][mastg] (MASTG) +and, of course, you can also solve them for fun. + +There are challenges for [Android][masandroid] and also a couple for [Apple iOS][masios]. + +#### Why use MAS Crackmes? + +Working through the challenges will improve understanding of [mobile application security][csmas] +and will also give an insight into the examples provided in the MASTG. + +#### How to try the challenges + +1. Select and download a challenge into your mobile application environment +2. Satisfy the individual challenge exercise +3. Have fun + +Each challenge has various solutions provided by the community; these can be used to compare with your solution. + +#### References + +* OWASP [Mobile Application Security][mas] (MAS) +* MAS [project][masproject] +* MAS [Crackmes][mascrack] UnCrackable Apps +* MAS [Testing Guide][mastg] (MASTG) +* MAS [Verification Standard][masvs] (MASVS) +* OWASP [Mobile Application Security][csmas] cheat sheet + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1005] or [edit on GitHub][edit1005]. + +[csmas]: https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet +[edit1005]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/10-culture-process/05-mas.md +[issue1005]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2010-culture-process/05-mas +[mas]: https://mas.owasp.org/ +[masproject]: https://owasp.org/www-project-mobile-app-security/ +[masandroid]: https://mas.owasp.org/crackmes/Android/ +[mascrack]: https://mas.owasp.org/crackmes/ +[masios]: https://mas.owasp.org/crackmes/iOS/ +[mastg]: https://mas.owasp.org/MASTG/ +[masvs]: https://mas.owasp.org/MASVS/ diff --git a/release-ja/10-culture-process/info.md b/release-ja/10-culture-process/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/10-culture-process/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/10-culture-process/toc.md b/release-ja/10-culture-process/toc.md new file mode 100644 index 00000000..163f5f71 --- /dev/null +++ b/release-ja/10-culture-process/toc.md @@ -0,0 +1,60 @@ +--- + +title: Culture Building and Process Maturing +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 10000 +permalink: /release/culture_building_and_process_maturing/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){: .image-right } + +## 8. Culture building and Process maturing + +Culture building and Process maturing is described by the SAMM [Organization and Culture][sammgegoc] activity, +which in turn is part of the SAMM [Education & Guidance][sammgeg] security practice +within the [Governance][sammg] business function. + +The maturity of security processes and culture is wide ranging, with indicators of a mature process and culture including: + +* Security champions have been identified for each development team +* A program is in place to support the security champions +* Secure coding practices are in place to define standards and improve software development +* Developers and application security professionals across the organization are able to communicate and share best practice + +Sections: + +8.1 [Security Culture](01-security-culture.md) +8.2 [Security Champions](02-security-champions/toc.md) +8.2.1 [Security champions program](02-security-champions/01-security-champions-program.md) +8.2.2 [Security Champions Guide](02-security-champions/02-security-champions-guide.md) +8.2.3 [Security Champions Playbook](02-security-champions/03-security-champions-playbook.md) +8.3 [SAMM](03-samm.md) +8.4 [ASVS process](04-asvs.md) +8.5 [MAS process](05-mas.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1000] or [edit on GitHub][edit1000]. + +[edit1000]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/10-culture-process/toc.md +[issue1000]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2010-culture-process/00-toc +[sammg]: https://owaspsamm.org/model/governance/ +[sammgeg]: https://owaspsamm.org/model/governance/education-and-guidance/ +[sammgegoc]: https://owaspsamm.org/model/governance/education-and-guidance/stream-b/ diff --git a/release-ja/11-operations/00-toc.md b/release-ja/11-operations/00-toc.md new file mode 100644 index 00000000..4d8daf73 --- /dev/null +++ b/release-ja/11-operations/00-toc.md @@ -0,0 +1,49 @@ +--- + +title: Operation +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){height=180px} + +## 9. Operations + +Operations are those activities necessary to ensure that confidentiality, integrity, and availability +are maintained throughout the operational lifetime of an application and its associated data. +The aim of Operations is to provide greater assurance that the organization is resilient +in the face of operational disruptions, and responsive to changes in the operational landscape. +This is described by the [Operations][sammo] business function in the OWASP [SAMM model][samm]. + +Operations generally cover the security practices: + +* [Incident Management][sammoim] of security breaches and incidents +* [Environment Management][sammoem] such as configuration hardening, patching and updating +* [Operational Management][sammoom] which includes data protection and system / legacy management + +OWASP projects provide the CRS that is used for both Coraza and ModSecurity web application firewalls, +which are widely used for data and system management. + +Sections: + +9.1 [DevSecOps Guideline](#devsecops-guideline) +9.2 [Coraza WAF](#coraza-waf) +9.3 [ModSecurity WAF](#modsecurity-waf) +9.4 [OWASP CRS](#owasp-crs) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue1100]. + +[issue1100]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2011-operations/00-toc +[samm]: https://owaspsamm.org/about/ +[sammo]: https://owaspsamm.org/model/operations/ +[sammoem]: https://owaspsamm.org/model/operations/environment-management/ +[sammoim]: https://owaspsamm.org/model/operations/incident-management +[sammoom]: https://owaspsamm.org/model/operations/operational-management/ diff --git a/release-ja/11-operations/01-devsecops.md b/release-ja/11-operations/01-devsecops.md new file mode 100644 index 00000000..a1abd9f4 --- /dev/null +++ b/release-ja/11-operations/01-devsecops.md @@ -0,0 +1,80 @@ +--- + +title: DevSecOps Guideline +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 11010 +permalink: /release/operations/devsecops_guideline/ + +--- + +{% include breadcrumb.html %} + +### 9.1 DevSecOps Guideline + +The OWASP [DevSecOps Guideline][devsecops] project explains how to best implement a secure pipeline, +using best practices and introducing automation tools to help 'shift-left' security issues. + +The DevSecOps Guideline is in active development as an OWASP Production documentation project +and can be accessed from the [web document][dsodoc] or [downloaded as a PDF][dsopdf]. + +#### What is the DevSecOps Guideline? + +The DevOps (combining software Development and release Operations) pipelines use automation to integrate +various established activities within the development and release processes into pipeline steps. +This enables the use of Continuous integration / Continuous Delivery/Deployment (CI/CD) within an organization. +DevSecOps (combining security with DevOps) seeks to add steps into the existing CI/CD pipelines to build security +into the development and release process. + +The [DevSecOps Guideline][devsecops] is a collection of advice and theory that explains how to embed security into DevOps. +It covers various foundational topics such as Threat Modeling pipelines, Secrets Management and Linting Code. +It then explains and illustrates various vulnerability scanning steps commonly used in [CI/CD pipelines][cscicd] : + +* Static Application Security Testing ([SAST][dsosast]) +* Dynamic Application Security Testing ([DAST][dsodast]) +* Interactive Application Security Testing ([IAST][dsoiast]) +* Software Composition Analysis ([SCA][dsosca]) +* [Infrastructure Vulnerability Scanning][dsocvs] +* [Container Vulnerability Scanning][dsoivs] + +The DevSecOps Guideline is a concise guide that provides the foundational knowledge to implement DevSecOps. + +#### How to use the DevSecOps Guideline + +The DevSecOps Guideline is document can be accessed from the [web document][dsodoc] or [downloaded as a PDF][dsopdf]. +It is concise enough that all the sections can be read within a short time, and it provides enough knowledge +to understand the concept behind DevSecOps and what activities are involved. + +It provides an [excellent overview][dsointro] of DevSecOps which shows how the steps of a typical CI/CD pipeline +fit together and what sort of tools can be applied in each step to secure the pipeline. +Many of the pages in the DevSecOps Guideline contain lists of tools that can be applied to the pipeline step. + +The DevSecOps Guideline document is in the process of [being expanded and updated][dsonew] which will build on the +existing 2023 version. + +#### References + +* OWASP [DevSecOps Guideline][devsecops] project +* OWASP [CI/CD Security Cheat Sheet][cscicd] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1101] or [edit on GitHub][edit1101]. + +[cscicd]: https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet +[devsecops]: https://owasp.org/www-project-devsecops-guideline/ +[dsocvs]: https://owasp.org/www-project-devsecops-guideline/latest/02f-Container-Vulnerability-Scanning +[dsodoc]: https://owasp.org/www-project-devsecops-guideline/latest/ +[dsodast]: https://owasp.org/www-project-devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing +[dsoiast]: https://owasp.org/www-project-devsecops-guideline/latest/02c-Interactive-Application-Security-Testing +[dsointro]: https://owasp.org/www-project-devsecops-guideline/latest/index +[dsoivs]: https://owasp.org/www-project-devsecops-guideline/latest/02e-Infrastructure-Vulnerability-Scanning +[dsonew]: https://github.com/OWASP/DevSecOpsGuideline/tree/master/current-version +[dsopdf]: https://github.com/OWASP/DevSecOpsGuideline/releases +[dsosast]: https://owasp.org/www-project-devsecops-guideline/latest/02a-Static-Application-Security-Testing +[dsosca]: https://owasp.org/www-project-devsecops-guideline/latest/02d-Software-Composition-Analysis +[edit1101]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/11-operations/01-devsecops.md +[issue1101]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2011-operations/01-devsecops diff --git a/release-ja/11-operations/02-coraza.md b/release-ja/11-operations/02-coraza.md new file mode 100644 index 00000000..57e1b06f --- /dev/null +++ b/release-ja/11-operations/02-coraza.md @@ -0,0 +1,78 @@ +--- + +title: Coraza WAF +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 11020 +permalink: /release/operations/coraza_waf/ + +--- + +{% include breadcrumb.html %} + +![Coraza logo](../../../assets/images/logos/coraza.png "OWASP Coraza"){: height="160px" } + +### 9.2 Coraza WAF + +The [OWASP Coraza][coraza-project] project provides a golang enterprise-grade Web Application Firewall framework +that supports the [ModSecurity][modsec] seclang language and is completely compatible with OWASP [CRS][crs]. +Coraza is in active development as an OWASP Production code project, +with the first stable version released in September 2021 and several releases since then. + +#### What is Coraza? + +The [Coraza][coraza] Web Application Firewall framework is used to enforce policies, +providing a first line of defense to stop attack on web applications and servers. +Coraza can be configured using the OWASP [CRS][crs] and also custom policies can be created. + +Coraza can be deployed: + +* as a library in an existing web server +* within an application server acting as a WAF +* as a reverse proxy +* using a docker container + +#### Why use Coraza? + +Web Application Firewalls are usually the first line of defense against HTTP attacks on web applications and servers. +The Coraza WAF is widely used for providing this security, especially for [cloud applications][cscloud], +along with the original OWASP [ModSecurity][modsec] WAF. + +#### How to use Coraza + +The best way to start is to create a Coraza WAF instance and then add rules to this WAF, +following the Coraza [Quick Start tutorial][coraza-tutorial]. + +There are multiple ways of running Coraza, and the one chosen will depend on an individual organization's deployment: + +* Coraza [SPOA connector][coraza-spoa] runs the Coraza WAF as a backing service for HAProxy +* Coraza [Caddy Module][coraza-caddy] provides Web Application Firewall capabilities for Caddy +* the Coraza [Proxy WASM][coraza-wasm] filter can be loaded directly from Envoy or used as an Istio plugin +* Coraza as a [C library][coraza-lib], used for applications written in C rather than golang + +#### References + +* OWASP [Coraza][coraza] +* OWASP [CRS][crs] +* OWASP [ModSecurity][modsec] +* [Secure Cloud Architecture][cscloud] cheat sheet + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1102] or [edit on GitHub][edit1102]. + +[coraza]: https://coraza.io/ +[coraza-caddy]: https://github.com/corazawaf/coraza-caddy +[coraza-lib]: https://github.com/corazawaf/libcoraza +[coraza-project]: https://owasp.org/www-project-coraza-web-application-firewall/ +[coraza-spoa]: https://coraza.io/connectors/coraza-spoa/ +[coraza-tutorial]: https://coraza.io/docs/tutorials/quick-start/ +[coraza-wasm]: https://github.com/corazawaf/coraza-proxy-wasm +[cscloud]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet +[edit1102]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/11-operations/02-coraza.md +[issue1102]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2011-operations/02-coraza +[crs]: https://coreruleset.org/ +[modsec]: https://owasp.org/www-project-modsecurity/ diff --git a/release-ja/11-operations/03-modsecurity.md b/release-ja/11-operations/03-modsecurity.md new file mode 100644 index 00000000..2000b7ee --- /dev/null +++ b/release-ja/11-operations/03-modsecurity.md @@ -0,0 +1,61 @@ +--- + +title: ModSecurity WAF +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 11030 +permalink: /release/operations/modsecurity_waf/ + +--- + +{% include breadcrumb.html %} + +### 9.3 ModSecurity WAF + +[ModSecurity][modsec] is an open source Web Application Firewall (WAF) widely deployed on web servers +that has been in continuous development and widespread use since 2002. + +In 2024 it became an OWASP Production project, supported by the existing leadership and contributors. + +#### What is ModSecurity? + +In January 2024 the [ModSecurity][modsec] Web Application Firewall project was [adopted by OWASP][modsec-press], +previously [TrustWave][trustwave] had been the custodian of this project. +ModSecurity itself has a long history as an open source project, the first release was in November 2002, +and is widely used as a web application firewall for [cloud applications][cscloud] and on-premises web servers. + +The ModSecurity WAF needs to be configured in operational deployments, +and this can be done using the OWASP [CRS][crs]. + +#### Why use ModSecurity? + +Web Application Firewalls are often the first line of defense against HTTP attacks on web applications and servers. +The ModSecurity WAF is widely used for this purpose along with the [Coraza WAF][coraza], also provided by OWASP. + +#### How to use ModSecurity + +ModSecurity is a Web Application Firewall, which scans the incoming and outgoing HTTP traffic to a web server. +The ModSecurity WAF is deployed as a proxy server in front of a web application, +or deployed within the web server itself, to provide protection against HTTP attacks. + +The rules applied to the HTTP traffic are provided as configuration to ModSecurity, +and these rules allow many different actions to be applied such as blocking traffic, redirecting requests, and many more. +See the documentation for [deploying and running][modsec-docs] ModSecurity, +along with the documentation on configuring ModSecurity with the [CRS][crs]. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1103] or [edit on GitHub][edit1103]. + +[coraza]: https://coraza.io/ +[crs]: https://coreruleset.org/ +[cscloud]: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet +[edit1103]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/11-operations/03-modsecurity.md +[issue1103]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2011-operations/03-modsecurity +[modsec]: https://owasp.org/www-project-modsecurity/ +[modsec-docs]: https://www.modsecurity.org/ +[modsec-press]: https://owasp.org/blog/2024/01/09/ModSecurity.html +[trustwave]: https://www.trustwave.com/ diff --git a/release-ja/11-operations/04-crs.md b/release-ja/11-operations/04-crs.md new file mode 100644 index 00000000..cc839a82 --- /dev/null +++ b/release-ja/11-operations/04-crs.md @@ -0,0 +1,78 @@ +--- + +title: OWASP CRS +layout: col-document +tags: OWASP Developer Guide +contributors: Matteo Pace, Jon Gadsden +document: OWASP Developer Guide +order: 11040 +permalink: /release/operations/crs/ + +--- + +{% include breadcrumb.html %} + + + +![CRS logo](../../../assets/images/logos/crs.png "OWASP CRS"){: .image-right } + +### 9.4 OWASP CRS + +The [OWASP CRS][crs-project] project, formerly known as Core Rule Set, is a set of generic attack detection rules +for use with [ModSecurity][modsec] compatible web application firewalls such as [OWASP Coraza][coraza]. +CRS is an OWASP [Flagship tool project][crs-project] and can be [downloaded][crs-download] +for either Apache or IIS/Nginx web servers. + +#### What is the CRS? + +The [CRS][crs] are attack detection rules for use with [ModSecurity][modsec], +[Coraza][coraza] and other ModSecurity compatible web application firewalls. +The CRS aims to protect web applications from a wide range of attacks with a minimum of false alerts. +The CRS provides protection against many common attack categories, including those in the OWASP Top Ten. + +#### Why use it? + +If an organization is using a Coraza, ModSecurity or compatible Web Application Firewall (WAF) +then it is very likely that the [CRS][crs] is already in use by this WAF. +The CRS provides the policy for the Coraza / Modsecurity engine so that traffic to a web application is inspected +for various attacks and malicious traffic is blocked. + +#### How to use it + +The use of the CRS assumes that a ModSecurity, Coraza or compatible WAF has been installed. +Refer to the [Coraza tutorial][coraza-tutorial] or the [ModSecurity][modsec-docs] on how to do this. + +To get started with CRS refer to the CRS [installation instructions][crs-download]. + +The OWASP Spotlight series provides an overview of how to use this CRS: +'Project 3 - [Core Rule Set (CRS) - 1st Line of Defense][spotlight03]'. + +#### References + +* OWASP [CRS][crs] +* OWASP [ModSecurity][modsec] +* OWASP [Coraza][coraza] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1104] or [edit on GitHub][edit1104]. + +[coraza]: https://coraza.io/ +[coraza-tutorial]: https://coraza.io/docs/tutorials/quick-start/ +[edit1104]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/11-operations/04-crs.md +[issue1104]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2011-operations/04-crs +[crs]: https://coreruleset.org/ +[crs-download]: https://coreruleset.org/docs/deployment/install/ +[crs-project]: https://owasp.org/www-project-modsecurity-core-rule-set/ +[modsec]: https://owasp.org/www-project-modsecurity/ +[modsec-docs]: https://www.modsecurity.org/ +[spotlight03]: https://youtu.be/88ZMKpiZbRI diff --git a/release-ja/11-operations/info.md b/release-ja/11-operations/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/11-operations/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/11-operations/toc.md b/release-ja/11-operations/toc.md new file mode 100644 index 00000000..10dbaa68 --- /dev/null +++ b/release-ja/11-operations/toc.md @@ -0,0 +1,62 @@ +--- + +title: Operation +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 11000 +permalink: /release/operations/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){: .image-right } + +## 9. Operations + +Operations are those activities necessary to ensure that confidentiality, integrity, and availability +are maintained throughout the operational lifetime of an application and its associated data. +The aim of Operations is to provide greater assurance that the organization is resilient +in the face of operational disruptions, and responsive to changes in the operational landscape. +This is described by the [Operations][sammo] business function in the OWASP [SAMM model][samm]. + +Operations generally cover the security practices: + +* [Incident Management][sammoim] of security breaches and incidents +* [Environment Management][sammoem] such as configuration hardening, patching and updating +* [Operational Management][sammoom] which includes data protection and system / legacy management + +OWASP projects provide the CRS that is used for both Coraza and ModSecurity web application firewalls, +which are widely used for data and system management. + +Sections: + +9.1 [DevSecOps Guideline](01-devsecops.md) +9.2 [Coraza WAF](02-coraza.md) +9.3 [ModSecurity WAF](03-modsecurity.md) +9.4 [OWASP CRS](04-crs.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1100] or [edit on GitHub][edit1100]. + +[edit1100]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/11-operations/toc.md +[issue1100]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2011-operations/00-toc +[samm]: https://owaspsamm.org/about/ +[sammo]: https://owaspsamm.org/model/operations/ +[sammoem]: https://owaspsamm.org/model/operations/environment-management/ +[sammoim]: https://owaspsamm.org/model/operations/incident-management +[sammoom]: https://owaspsamm.org/model/operations/operational-management/ diff --git a/release-ja/12-metrics/00-toc.md b/release-ja/12-metrics/00-toc.md new file mode 100644 index 00000000..f64e4ff9 --- /dev/null +++ b/release-ja/12-metrics/00-toc.md @@ -0,0 +1,61 @@ +--- + +title: Metrics +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){height=180px} + +## 10. Metrics + +Metrics are important in an organization for various reasons, and in software security they can be used to: + +* measure the effectiveness of security controls +* determine security posture +* provide justification for security programs +* and others + +At present the OWASP [Integration Standards project Application Wayfinder][intstand] project +does not identify any OWASP projects that gather or process metrics; this may change in the future. + +### Strategy and Metrics + +The software security program is foundational to the strategic planning an organizations security posture. +Metrics keep track of the security activities within the plan and provide the information for gap analysis. + +The [Software Assurance Maturity Model][samm] (SAMM) provides descriptions and definitions +for the [Strategy and Metrics][sammgsm] business practices within the [Governance][sammg] business function. +It provides two streams for achieving organizational maturity: + +* [Create and Promote][sammgsma] + which concerns the risks identified with the organization and what level of risk is acceptable +* [Measure and Improve][sammgsmb] which describes monitoring the security strategy through metrics + +The categories of metrics suggested by SAMM are : + +* Effort metrics: the effort spent on security +* Result metrics: the results of security efforts +* Environment metrics: the environment where security efforts take place + +There are other metrics, perhaps specific to an individual organization, that can also be collected and acted on. +The [Security Culture][culturemetrics] project provides various examples of metrics that can be considered. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue1200]. + +[culturemetrics]: https://owasp.org/www-project-security-culture/stable/8-Metrics/ +[issue1200]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2012-metrics/00-toc +[samm]: https://owaspsamm.org/about/ +[sammg]: https://owaspsamm.org/model/governance/ +[sammgsm]: https://owaspsamm.org/model/governance/strategy-and-metrics/ +[sammgsma]: https://owaspsamm.org/model/governance/strategy-and-metrics/stream-a/ +[sammgsmb]: https://owaspsamm.org/model/governance/strategy-and-metrics/stream-b/ +[intstand]: https://owasp.org/www-project-integration-standards/ diff --git a/release-ja/12-metrics/info.md b/release-ja/12-metrics/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/12-metrics/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/12-metrics/toc.md b/release-ja/12-metrics/toc.md new file mode 100644 index 00000000..c4b481c5 --- /dev/null +++ b/release-ja/12-metrics/toc.md @@ -0,0 +1,76 @@ +--- + +title: Metrics +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 12000 +permalink: /release/metrics/ + +--- + +{% include breadcrumb.html %} + + + +![Developer Guide](../../assets/images/dg_alt.png "OWASP Developer Guide"){: .image-right } + +## 10. Metrics + +Metrics are important in an organization for various reasons, and in software security they can be used to: + +* measure the effectiveness of security controls +* determine security posture +* provide justification for security programs +* and others + +At present the OWASP [Integration Standards project Application Wayfinder][intstand] project +does not identify any OWASP projects that gather or process metrics; this may change in the future. + +### Strategy and Metrics + +The software security program is foundational to the strategic planning an organizations security posture. +Metrics keep track of the security activities within the plan and provide the information for gap analysis. + +The [Software Assurance Maturity Model][samm] (SAMM) provides descriptions and definitions +for the [Strategy and Metrics][sammgsm] business practices within the [Governance][sammg] business function. +It provides two streams for achieving organizational maturity: + +* [Create and Promote][sammgsma] + which concerns the risks identified within an organization and what level of risk is acceptable +* [Measure and Improve][sammgsmb] which describes monitoring the security strategy through metrics + +The categories of metrics suggested by SAMM are : + +* Effort metrics: the effort spent on security +* Result metrics: the results of security efforts +* Environment metrics: the environment where security efforts take place + +There are other metrics, perhaps specific to an individual organization, that can also be collected and acted on. +The [Security Culture][culturemetrics] project provides various examples of metrics that can be considered. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1200] or [edit on GitHub][edit1200]. + +[culturemetrics]: https://owasp.org/www-project-security-culture/stable/8-Metrics/ +[edit1200]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/12-metrics/toc.md +[issue1200]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2012-metrics/00-toc +[samm]: https://owaspsamm.org/about/ +[sammg]: https://owaspsamm.org/model/governance/ +[sammgsm]: https://owaspsamm.org/model/governance/strategy-and-metrics/ +[sammgsma]: https://owaspsamm.org/model/governance/strategy-and-metrics/stream-a/ +[sammgsmb]: https://owaspsamm.org/model/governance/strategy-and-metrics/stream-b/ +[intstand]: https://owasp.org/www-project-integration-standards/ + +Sections: diff --git a/release-ja/13-security-gap-analysis/00-toc.md b/release-ja/13-security-gap-analysis/00-toc.md new file mode 100644 index 00000000..c4e6d151 --- /dev/null +++ b/release-ja/13-security-gap-analysis/00-toc.md @@ -0,0 +1,46 @@ +--- + +title: Security Gap Analysis +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){height=180px} + +## 11. Security gap analysis + +A security gap analysis is an activity where the information security posture of an organization is assessed +and any shortfalls or operation gaps are identified. +This activity can also be combined with a security gap evaluation where the existing controls and processes +are assessed for effectiveness and relevance. +Security gap analysis is required to gain or maintain certification to a management system standard +such as [ISO 27001][iso27001] 'Information security, cybersecurity and privacy protection'. + +The security gap analysis is often associated with Governance, Risk & Compliance activities, +where the compliance with a management system standard is periodically reviewed and updated. +Guides and tools are useful for these compliance activities and the OWASP projects [SAMM][samm], +[MASVS][masvs] and [ASVS][asvs] provide information and advice in meeting management system standards. + +Sections: + +11.1 [Guides](#security-gap-analysis-guides) +11.1.1 [SAMM gap analysis](#samm-gap-analysis) +11.1.2 [ASVS gap analysis](#asvs-gap-analysis) +11.1.3 [MAS gap analysis](#mas-gap-analysis) +11.2 [BLT](#blt) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue1300]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[iso27001]: https://www.iso.org/standard/82875.html +[issue1300]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2013-security-gap-analysis/00-toc +[masvs]: https://mas.owasp.org/MASVS/ +[samm]: https://owaspsamm.org/about/ diff --git a/release-ja/13-security-gap-analysis/01-guides/00-toc.md b/release-ja/13-security-gap-analysis/01-guides/00-toc.md new file mode 100644 index 00000000..e80728fb --- /dev/null +++ b/release-ja/13-security-gap-analysis/01-guides/00-toc.md @@ -0,0 +1,39 @@ +--- + +title: Guides for Security Gap Analysis +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 11.1 Security gap analysis guides + +Security gap analysis and security gap evaluation are central to Governance, Risk & Compliance activities +and are used to gain and maintain certification to a management system standard +such as [ISO 27001][iso27001] 'Information security, cybersecurity and privacy protection'. + +Guidance is important for these analysis and evaluation activities, with the OWASP projects [SAMM][samm], +[MASVS][masvs] and [ASVS][asvs] providing this information and advice. + +Sections: + +11.1.1 [SAMM gap analysis](#samm-gap-analysis) +11.1.2 [ASVS gap analysis](#asvs-gap-analysis) +11.1.3 [MAS gap analysis](#mas-gap-analysis) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue1301]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[iso27001]: https://www.iso.org/standard/82875.html +[issue1301]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2013-security-gap-analysis/01-guides/00-toc +[masvs]: https://mas.owasp.org/MASVS/ +[samm]: https://owaspsamm.org/about/ diff --git a/release-ja/13-security-gap-analysis/01-guides/01-samm.md b/release-ja/13-security-gap-analysis/01-guides/01-samm.md new file mode 100644 index 00000000..e4d53ac4 --- /dev/null +++ b/release-ja/13-security-gap-analysis/01-guides/01-samm.md @@ -0,0 +1,129 @@ +--- + +title: SAMM +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 13110 +permalink: /release/security_gap_analysis/guides/samm/ + +--- + +{% include breadcrumb.html %} + + + +![SAMM logo](../../../../assets/images/logos/samm.png "OWASP SAMM"){: .image-right-small } + +### 11.1.1 SAMM gap analysis + +The [Software Assurance Maturity Model][samm] (SAMM) project provides an effective and measurable way for +an organization to analyze their secure development lifecycle, and identify any gaps or improvements. +SAMM is one of the OWASP's flagship projects, and can be downloaded from the [SAMM project site][samm-project]. + +#### What is SAMM? + +SAMM is regarded as the prime maturity model for software assurance. +SAMM provides an effective and measurable way for all types of organizations to analyze and improve +their software security posture. +SAMM supports the complete secure software development lifecycle and is technology and process agnostic. + +The SAMM model is hierarchical. At the highest level SAMM defines five business functions; +activities that software development must fulfill to some degree: + +* [Governance][sammg] +* [Design][sammd] +* [Implementation][sammi] +* [Verification][sammv] +* [Operations][sammo] + +Each business function in turn has three security practices, +which are areas of security-related activities that build assurance for the related business function. + +Security practices have activities, grouped in logical flows and divided into two streams (A and B). +Streams cover different aspects of a practice and have their own objectives, +aligning and linking the activities in the practice over the different maturity levels. + +For each security practice, SAMM defines three maturity levels which generalize to foundational, mature and advanced. +Each level has a successively more sophisticated objective with specific activities, and more strict success metrics. + +#### Why use it? + +The structure and setup of the SAMM model support: + +* assessment of the organization’s current software security posture +* definition of the organization’s targets +* definition of an implementation roadmap to get there +* prescriptive advice on how to implement particular activities + +These give the security activities expected at each maturity level, and provide input to the gap analysis. + +#### How to use it + +The OWASP Spotlight series provides an overview of using the SAMM: +'Project 9 - [Software Assurance Maturity Model (SAMM)][spotlight09]'. + +Security gap analysis can benefit from an assessment which measures the quality of the software assurance maturity process. +The [SAMM Assessment][samma] tools include spreadsheets and online tools such as [SAMMwise][sammwise] and [SAMMY][sammy]. + +The SAMM model describes these fundamentals of software security, which it calls Business Functions. +Each of these five fundamentals are further split into three Business Practices: + +| Business Function | Business Practices | | | +| ----------------------- | ---------------------------------- | -------------------------------------- | ------ | +| [Governance][sammg] | [Strategy and Metrics][sammgsm] | [Policy and Compliance][sammgpc] | [Education and Guidance][sammgeg] | +| [Design][sammd] | [Threat Assessment][sammdta] | [Security Requirements][sammdsr] | [Secure Architecture][sammdsa] | +| [Implementation][sammi] | [Secure Build][sammisb] | [Secure Deployment][sammisd] | [Defect Management][sammidm] | +| [Verification][sammv] | [Architecture Assessment][sammvaa] | [Requirements-driven Testing][sammvrt] | [Security Testing][sammvst] | +| [Operations][sammo] | [Incident Management][sammoim] | [Environment Management][sammoem] | [Operational Management][sammoom] | + +Each Business Practice is further subdivided into two streams which provide different objectives for the same practice. + +#### References + +* OWASP [Software Assurance Maturity Model][samm] (SAMM) +* [SAMMY][sammy] management tool +* OWASP [SAMM project][samm-project] + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue130101] or [edit on GitHub][edit130101]. + +[edit130101]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/13-security-gap-analysis/01-guides/01-samm.md +[issue130101]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2013-security-gap-analysis/01-guides/01-samm +[samm]: https://owaspsamm.org/about/ +[samma]: https://owaspsamm.org/assessment/ +[sammd]: https://owaspsamm.org/model/design/ +[sammdsa]: https://owaspsamm.org/model/design/secure-architecture/ +[sammdsr]: https://owaspsamm.org/model/design/security-requirements/ +[sammdta]: https://owaspsamm.org/model/design/threat-assessment/ +[sammg]: https://owaspsamm.org/model/governance/ +[sammgeg]: https://owaspsamm.org/model/governance/education-and-guidance/ +[sammgpc]: https://owaspsamm.org/model/governance/policy-and-compliance/ +[sammgsm]: https://owaspsamm.org/model/governance/strategy-and-metrics/ +[sammi]: https://owaspsamm.org/model/implementation/ +[sammidm]: https://owaspsamm.org/model/implementation/defect-management/ +[sammisb]: https://owaspsamm.org/model/implementation/secure-build/ +[sammisd]: https://owaspsamm.org/model/implementation/secure-deployment/ +[sammo]: https://owaspsamm.org/model/operations/ +[sammoem]: https://owaspsamm.org/model/operations/environment-management/ +[sammoim]: https://owaspsamm.org/model/operations/incident-management +[sammoom]: https://owaspsamm.org/model/operations/operational-management/ +[sammv]: https://owaspsamm.org/model/verification/ +[sammvaa]: https://owaspsamm.org/model/verification/architecture-assessment/ +[sammvrt]: https://owaspsamm.org/model/verification/requirements-driven-testing/ +[sammvst]: https://owaspsamm.org/model/verification/security-testing/ +[samm-project]: https://owasp.org/www-project-samm/ +[sammwise]: https://github.com/owaspsamm/sammwise +[sammy]: https://sammy.codific.com/ +[spotlight09]: https://youtu.be/N0zcZnkH5Wg diff --git a/release-ja/13-security-gap-analysis/01-guides/02-asvs.md b/release-ja/13-security-gap-analysis/01-guides/02-asvs.md new file mode 100644 index 00000000..35e965c9 --- /dev/null +++ b/release-ja/13-security-gap-analysis/01-guides/02-asvs.md @@ -0,0 +1,83 @@ +--- + +title: ASVS gap analysis +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 13120 +permalink: /release/security_gap_analysis/guides/asvs_gap_analysis/ + +--- + +{% include breadcrumb.html %} + +### 11.1.2 ASVS gap analysis + +The [Application Security Verification Standard][asvs] (ASVS) is a long established OWASP flagship project, +and is widely used to identify gaps in security as well as the verification of web applications. + +It can be downloaded from the [OWASP project page][asvs] in various languages and formats: +PDF, Word, CSV, XML and JSON. Having said that, the recommended way to consume the ASVS is to access +the [github markdown][asvsmd] pages directly - this will ensure that the latest version is used. + +#### What is ASVS? + +The ASVS is an open standard that sets out the coverage and 'level of rigor' expected when it comes to +performing web application security verification. +For this reason it can be used to identify gaps in the security of web applications. + +The ASVS is split into various sections: + +* V1 [Architecture, Design and Threat Modeling][asvsV1] +* V2 [Authentication][asvsV2] +* V3 [Session Management][asvsV3] +* V4 [Access Control][asvsV4] +* V5 [Validation, Sanitization and Encoding][asvsV5] +* V6 [Stored Cryptography][asvsV6] +* V7 [Error Handling and Logging][asvsV7] +* V8 [Data Protection][asvsV8] +* V9 [Communication][asvsV9] +* V10 [Malicious Code][asvsV10] +* V11 [Business Logic][asvsV11] +* V12 [Files and Resources][asvsV12] +* V13 [API and Web Service][asvsV13] +* V14 [Configuration][asvsV14] + +#### How to use it + +The ASVS is a list of verification requirements that can be used to identify gaps in the security of web applications. +If the ASVS suggests using a control then that control should be considered for the application security, +it may be not applicable but at least the control should have been considered at some point in the development process. + +The OWASP Spotlight series provides an overview of the ASVS and its uses: +'Project 19 - [OWASP Application Security Verification standard (ASVS)][spotlight19]'. + +The OWASP Cheat Sheets have been indexed specifically for [each section of the ASVS][csasvs], +which can be used as documentation on controls for a given requirements category. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue130102] or [edit on GitHub][edit130102]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[asvsmd]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x00-Header.md +[asvsV1]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x10-V1-Architecture.md#v1-architecture-design-and-threat-modeling +[asvsV2]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x11-V2-Authentication.md#v2-authentication +[asvsV3]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x12-V3-Session-management.md#v3-session-management +[asvsV4]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x12-V4-Access-Control.md#v4-access-control +[asvsV5]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md#v5-validation-sanitization-and-encoding +[asvsV6]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x14-V6-Cryptography.md#v6-stored-cryptography +[asvsV7]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x15-V7-Error-Logging.md#v7-error-handling-and-logging +[asvsV8]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x16-V8-Data-Protection.md#v8-data-protection +[asvsV9]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x17-V9-Communications.md#control-objective +[asvsV10]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x18-V10-Malicious.md#v10-malicious-code +[asvsV11]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x19-V11-BusLogic.md#v11-business-logic +[asvsV12]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x20-V12-Files-Resources.md#v12-files-and-resources +[asvsV13]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x21-V13-API.md#v13-api-and-web-service +[asvsV14]: https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/en/0x22-V14-Config.md#v14-configuration +[csasvs]: https://cheatsheetseries.owasp.org/IndexASVS.html +[edit130102]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/13-security-gap-analysis/01-guides/02-asvs.md +[issue130102]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2013-security-gap-analysis/01-guides/02-asvs +[spotlight19]: https://youtu.be/3puIavsZfAk diff --git a/release-ja/13-security-gap-analysis/01-guides/03-mas.md b/release-ja/13-security-gap-analysis/01-guides/03-mas.md new file mode 100644 index 00000000..2741824e --- /dev/null +++ b/release-ja/13-security-gap-analysis/01-guides/03-mas.md @@ -0,0 +1,92 @@ +--- + +title: MAS +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 13130 +permalink: /release/security_gap_analysis/guides/mas/ + +--- + +{% include breadcrumb.html %} + + + +![MAS logo](../../../../assets/images/logos/mas.png "OWASP MAS"){: .image-right } + +### 11.1.3 MAS gap analysis + +The OWASP [Mobile Application Security][masproject] (MAS) flagship project provides +industry standards for mobile application security. + +The OWASP MAS project provides the [Mobile Application Security Verification Standard][masvs] (MASVS) +for mobile applications that can be used as a guide for security gap analysis. +The MAS project covers the processes, techniques, and tools used for security testing a mobile application, +as well as a set of test cases that enables testers to deliver consistent and complete results. + +#### What is MASVS? + +The OWASP MASVS is the industry standard for mobile app security. +It can be used by mobile software architects and developers seeking to develop secure mobile applications, +as well as security testers to ensure completeness and consistency of test results. + +The MAS project has several uses; when it comes to security gap analysis then +the MASVS contains a list of security controls for mobile applications that are expected to be present / implemented. + +The security controls are split into several categories: + +* [MASVS-STORAGE](https://mas.owasp.org/MASVS/05-MASVS-STORAGE/) +* [MASVS-CRYPTO](https://mas.owasp.org/MASVS/06-MASVS-CRYPTO/) +* [MASVS-AUTH](https://mas.owasp.org/MASVS/07-MASVS-AUTH/) +* [MASVS-NETWORK](https://mas.owasp.org/MASVS/08-MASVS-NETWORK/) +* [MASVS-PLATFORM](https://mas.owasp.org/MASVS/09-MASVS-PLATFORM/) +* [MASVS-CODE](https://mas.owasp.org/MASVS/10-MASVS-CODE/) +* [MASVS-RESILIENCE](https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/) +* [MASVS-PRIVACY](https://mas.owasp.org/MASVS/12-MASVS-PRIVACY/) + +#### Why use MASVS? + +The OWASP MASVS provides a list of industry-standard security controls for [secure mobile applications][csmas]. +If the application does not implement any of the controls then this could become a compliance issue, +given that MASVS is the industry standard for mobile applications, so any omissions need to be justified. + +#### How to use MASVS + +The MASVS provides a list of expected security controls for mobile applications, +and can be used to identify missing or inadequate controls during gap analysis. +These controls can then be tested using the [MAS Testing Guide][mastg]. + +The MASVS provides a starting point for a security gap evaluation for any existing controls as well as new ones. +The MASVS can be [accessed online][masvs] and links followed for each security controls; +the mobile application can then be inspected for compliance with the relevant controls. + +#### References + +* OWASP [Mobile Application Security][mas] (MAS) +* MAS [project][masproject] +* MAS [Testing Guide][mastg] (MASTG) +* MAS [Verification Standard][masvs] (MASVS) +* OWASP [Mobile Application Security][csmas] cheat sheet + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue130103] or [edit on GitHub][edit130103]. + +[csmas]: https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet +[edit130103]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/13-security-gap-analysis/01-guides/03-mas.md +[issue130103]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2013-security-gap-analysis/01-guides/03-mas +[mas]: https://mas.owasp.org/ +[masproject]: https://owasp.org/www-project-mobile-app-security/ +[mastg]: https://mas.owasp.org/MASTG/ +[masvs]: https://mas.owasp.org/MASVS/ diff --git a/release-ja/13-security-gap-analysis/01-guides/info.md b/release-ja/13-security-gap-analysis/01-guides/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/13-security-gap-analysis/01-guides/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/13-security-gap-analysis/01-guides/toc.md b/release-ja/13-security-gap-analysis/01-guides/toc.md new file mode 100644 index 00000000..f649a744 --- /dev/null +++ b/release-ja/13-security-gap-analysis/01-guides/toc.md @@ -0,0 +1,52 @@ +--- + +title: Guides for Security Gap Analysis +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 13100 +permalink: /release/security_gap_analysis/guides/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 11.1 Security gap analysis guides + +Security gap analysis and security gap evaluation are central to Governance, Risk & Compliance activities +and are used to gain and maintain certification to a management system standard +such as [ISO 27001][iso27001] 'Information security, cybersecurity and privacy protection'. + +Guidance is important for these analysis and evaluation activities, with the OWASP projects [SAMM][samm], +[MASVS][masvs] and [ASVS][asvs] providing this information and advice. + +Sections: + +11.1.1 [SAMM gap analysis](01-samm.md) +11.1.2 [ASVS gap analysis](02-asvs.md) +11.1.3 [MAS gap analysis](03-mas.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1301] or [edit on GitHub][edit1301]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[edit1301]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/13-security-gap-analysis/01-guides/toc.md +[iso27001]: https://www.iso.org/standard/82875.html +[issue1301]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2013-security-gap-analysis/01-guides/00-toc +[masvs]: https://mas.owasp.org/MASVS/ +[samm]: https://owaspsamm.org/about/ diff --git a/release-ja/13-security-gap-analysis/02-blt.md b/release-ja/13-security-gap-analysis/02-blt.md new file mode 100644 index 00000000..2b63d103 --- /dev/null +++ b/release-ja/13-security-gap-analysis/02-blt.md @@ -0,0 +1,61 @@ +--- + +title: Bug Logging Tool +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 13200 +permalink: /release/security_gap_analysis/blt/ + +--- + +{% include breadcrumb.html %} + +### 11.2 BLT + +The OWASP [Bug Logging Tool][blt] (BLT) is a community database of bugs found in an organization's web site or application. +BLT is an OWASP Production tool project and has its own [bug recording site][bltsite]. + +#### What is BLT? + +BLT is a bug recording and bounty tool that allows external users to register and advise +about bugs in an organization's web site or application. +It allows an organization to run a bug bounty program without having to go through a commercial provider. + +The [BLT core project][bltcore] provides a development server docker image that can be used for the +bug bounty program. +The [BLT-Flutter application][bltapp] provides an integrated method for reporters/users to report bugs. +The [BLT Extension][bltchrome] is a Chrome extension that helps BLT reporters/users +to take screenshots and add them to a BLT website. + +#### Why use it? + +Bug bounty programs are an important path for reporting security bugs to an organization. +These programs can be paid-for services provided by commercial companies, or they can be provided by +the company / organization itself; and this is where BLT can help. + +External reporters of bugs in web sites and applications are a valuable way of identifying security +related bugs and issues; it provides a diverse range of individuals to hunt for bugs. +BLT can provide the route for these security bugs to be responsibly disclosed to the organization. + +#### How to use it + +BLT has its own [bug recording site][bltsite] which can be used to disclose any type of bug in any web site. +Ideally this is not used for security related bugs because these bugs need [responsible disclosure][csdisclose]. +The organization should run its own [BLT core site][bltcore] to accept submission of security related bugs, +and encourage users/reporters to use the [BLT app][bltapp] and chrome [extension][bltchrome]. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1302] or [edit on GitHub][edit1302]. + +[blt]: https://owasp.org/www-project-bug-logging-tool/ +[bltchrome]: https://github.com/OWASP/BLT-Extension +[bltcore]: https://github.com/OWASP/BLT +[bltapp]: https://github.com/OWASP/BLT-Flutter +[bltsite]: https://blt.owasp.org/ +[csdisclose]: https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet +[edit1302]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/13-security-gap-analysis/02-blt.md +[issue1302]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=content&template=request.md&title=Update:%2013-security-gap-analysis/02-blt diff --git a/release-ja/13-security-gap-analysis/info.md b/release-ja/13-security-gap-analysis/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/13-security-gap-analysis/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/13-security-gap-analysis/toc.md b/release-ja/13-security-gap-analysis/toc.md new file mode 100644 index 00000000..96cad0f4 --- /dev/null +++ b/release-ja/13-security-gap-analysis/toc.md @@ -0,0 +1,59 @@ +--- + +title: Security Gap Analysis +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 13000 +permalink: /release/security_gap_analysis/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){: .image-right } + +## 11. Security gap analysis + +A security gap analysis is an activity where the information security posture of an organization is assessed +and any shortfalls or operation gaps are identified. +This activity can also be combined with a security gap evaluation where the existing controls and processes +are assessed for effectiveness and relevance. +Security gap analysis is required to gain or maintain certification to a management system standard +such as [ISO 27001][iso27001] 'Information security, cybersecurity and privacy protection'. + +The security gap analysis is often associated with Governance, Risk & Compliance activities, +where the compliance with a management system standard is periodically reviewed and updated. +Guides and tools are useful for these compliance activities and the OWASP projects [SAMM][samm], +[MASVS][masvs] and [ASVS][asvs] provide information and advice in meeting management system standards. + +Sections: + +11.1 [Guides](01-guides/toc.md) +11.1.1 [SAMM gap analysis](01-guides/01-samm.md) +11.1.2 [ASVS gap analysis](01-guides/02-asvs.md) +11.1.3 [MAS gap analysis](01-guides/03-mas.md) +11.2 [BLT](02-blt.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1300] or [edit on GitHub][edit1300]. + +[asvs]: https://owasp.org/www-project-application-security-verification-standard/ +[edit1300]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/13-security-gap-analysis/toc.md +[iso27001]: https://www.iso.org/standard/82875.html +[issue1300]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2013-security-gap-analysis/00-toc +[masvs]: https://mas.owasp.org/MASVS/ +[samm]: https://owaspsamm.org/about/ diff --git a/release-ja/14-appendices/00-toc.md b/release-ja/14-appendices/00-toc.md new file mode 100644 index 00000000..09c63a7a --- /dev/null +++ b/release-ja/14-appendices/00-toc.md @@ -0,0 +1,36 @@ +--- + +title: Appendices +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){height=180px} + +## 12. Appendices + +12.1 [Implementation Do's and Don'ts](#implementation-dos-and-donts) +12.1.1 [Container security](#container-security) +12.1.2 [Secure coding](#secure-coding) +12.1.3 [Cryptographic practices](#cryptographic-practices) +12.1.4 [Application spoofing](#application-spoofing) +12.1.5 [Content Security Policy (CSP)](#content-security-policy) +12.1.6 [Exception and error handling](#exception-and-error-handling) +12.1.7 [File management](#file-management) +12.1.8 [Memory management](#memory-management) +12.2 [Verification Do's and Don'ts](#verification-dos-and-donts) +12.2.1 [Secure environment](#secure-environment) +12.2.2 [System hardening](#system-hardening) +12.2.3 [Open Source software](#open-source-software) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue1400]. + +[issue1400]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2014-appendices/00-toc diff --git a/release-ja/14-appendices/01-implementation-dos-donts/00-toc.md b/release-ja/14-appendices/01-implementation-dos-donts/00-toc.md new file mode 100644 index 00000000..b846b8ae --- /dev/null +++ b/release-ja/14-appendices/01-implementation-dos-donts/00-toc.md @@ -0,0 +1,39 @@ +--- + +title: Implementation Do's and Don'ts +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 12.1 Implementation Do's and Don'ts + +Implementation demands technical knowledge, skill and experience. +There is no substitute for experience, but learning from past mistakes and the experience of others can go a long way. +This section of the Developer Guide is a collection of Do's and Don'ts, +some of which may be directly relevant to any given project and some of which will be less so. +It is worth considering all of these Do's and Don'ts and picking out the ones that will be of most use. + +Sections: + +12.1.1 [Container security](#container-security) +12.1.2 [Secure coding](#secure-coding) +12.1.3 [Cryptographic practices](#cryptographic-practices) +12.1.4 [Application spoofing](#application-spoofing) +12.1.5 [Content Security Policy (CSP)](#content-security-policy) +12.1.6 [Exception and error handling](#exception-and-error-handling) +12.1.7 [File management](#file-management) +12.1.8 [Memory management](#memory-management) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0740]. + +[issue0740]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2014-appendices/01-implementation-dos-donts/00-toc diff --git a/release-ja/14-appendices/01-implementation-dos-donts/01-container-security.md b/release-ja/14-appendices/01-implementation-dos-donts/01-container-security.md new file mode 100644 index 00000000..b7f04e21 --- /dev/null +++ b/release-ja/14-appendices/01-implementation-dos-donts/01-container-security.md @@ -0,0 +1,140 @@ +--- + +title: Container security +layout: col-document +tags: OWASP Developer Guide +contributors: Shruti Kulkarni +document: OWASP Developer Guide +order: 14110 +permalink: /release/appendices/implementation_dos_donts/container_security/ + +--- + +{% include breadcrumb.html %} + +### 12.1.1 Container security + +This is a collection of Do's and Don'ts when it comes to container security, gathered from practical experiences. +Some of these are language specific and others have more general applicability. + +Container image security, host security, client security, daemon security, runtime security: + +* Choose the right base image +* Include only the required packages in the image +* If using Docker images, use multi-stage builds +* Use layer caching and multi stage builds to: + * Separate build-time dependencies from runtime dependencies + * Remove special permissions from images + * `find / -perm /6000 -type f -exec ls -ld {} \;` + * RUN `find / -xdev -perm /6000 -type f -exec chmod a-s {} \; || true` +* Reduce overall image size by shipping only what your app needs to run, + see the [Docker documentation][docker] for more information +* Remove unused images with prune: `docker image prune [OPTIONS]` +* Do not embed any secrets, passwords, keys, credentials, etc in images +* Use a read-only file system +* Sign images with cryptographic keys and not with username/password combination +* Secure your code and its dependencies +* Test your images for vulnerabilities +* Monitor container runtimes +* Docker Content Trust (DCT) is enabled on Docker clients +* Check freshness security of images with the provided timestamp key that is associated with the registry. +* Create the timestamp key by Docker and store on the server +* Use tagging keys associated with a registry. + Such that a poisoned image from a different registry cannot be pushed into a registry. +* Use offline keys to sign the tagging keys. +* Offline keys are owned by the organization and secured in an out-of-band location. +* Scan images frequently for any vulnerabilities. Rebuilt all images to include patches + and instantiate new containers from them +* Remove `setuid` and `setgid` permissions from the images. +* Where applicable, use 'copy' instruction in place of 'add' instruction. +* Verify authenticity of packages before installing them into images +* Use namespaces and control groups for containers +* Use bridge interfaces for the host +* Authenticity of packages is verified before installing them into images +* Mount files on a separate partition to address any situation where the mount becomes full, + but the host still remains usable +* Mark registries as private and only use signed images. +* Pass commands through the authorization plugin to ensure that only authorized client connects to the daemon +* TLS authentication is configured to restrict access to the Docker daemon +* Namespaces are enabled to ensure that +* Leave control groups (cgroups) at default setting to ensure that tampering does not take place + with excessive resource consumption. +* Do not enable experimental features for Docker +* set docker.service file ownership to root:root. +* Set docker.service file permissions to either 644 or to a more restrictive value. +* Set docker.socket file ownership and group ownership to root. +* Set file permissions on the docker.socket file to 644 or more restrictively +* Set /etc/docker directory ownership and group ownership to root +* Set /etc/docker directory permissions to 755 or more restrictively +* Set ownership of registry certificate files (usually found under `/etc/docker/certs.d/` directory) + to individual ownership and is group owned by root. +* Set registry certificate files (usually found under `/etc/docker/certs.d/` directory) + permissions to 444 or more restrictively. +* Acquire and ship daemon logs to SIEM for monitoring +* Inter-container network connections are restricted and enabled on a requirement basis. + By default containers cannot capture packets that have other containers as destination +* Where hairpin NAT is enabled, userland proxy is disabled +* Docker daemon is run as a non-root user to mitigate lateral privilege escalation + due to any possible compromise of vulnerabilities. +* `No_new_priv` is set (but not to false) to ensure that containers cannot gain additional privileges + via `suid` or `sgid` +* Default SECCOMP profile is applied for access control. +* TLS CA certificate file on the image host (the file that is passed along with the `--tlscacert` parameter) + is individually owned and group owned by root +* TLS CA certificate file on the image host (the file that is passed along with the `--tlscacert` parameter) + has permissions of 444 or is set more restrictively +* Containers should run as a non-root user. +* Containers should have as small a footprint as possible, and should not contain unnecessary software packages + which could increase their attack surface +* Docker default bridge 'docker0' is not used to avoid ARP spoofing and MAC flooding attacks +* Either Dockers AppArmor policy is enabled or the Docker hosts AppArmor is enabled. +* SELinux policy is enabled on the Docker host. +* Linux kernel capabilities are restricted within containers +* privileged containers are not used +* sensitive host system directories are not mounted on containers +* `sshd` is not run within containers +* privileged ports are not mapped within containers (TCP/IP port numbers below 1024 are considered privileged ports) +* only needed ports are open on the container. +* the hosts network namespace is not shared. +* containers root filesystem is mounted as read only +* Do not use docker exec with the `--privileged` option. +* docker exec commands are not used with the user=root option +* cgroup usage is confirmed +* The `no_new_priv` option prevents LSMs like SELinux from allowing processes to acquire new privileges +* Docker socket is not mounted inside any containers to prevent processes running within the container + to execute Docker commands which would effectively allow for full control of the host. +* incoming container traffic is bound to a specific host interface +* hosts process namespace is not shared to ensure that processes are separated +* hosts IPC namespace is not shared to ensure that inter-process communications does not take place +* host devices are not directly exposed to containers +* hosts user namespaces are not shared to ensure isolation of containers +* CPU priority is set appropriately on containers +* memory usage for containers is limited. +* 'on-failure' container restart policy is set to '5' +* default `ulimit` is overwritten at runtime if needed +* container health is checked at runtime +* PIDs cgroup limit is used (limit is set as applicable) +* The Docker host is hardened to ensure that only Docker services are run on the host +* Secure configurations are applied to ensure that the containers do not gain access to the host via the Docker daemon +* Docker is updated with the latest patches such that vulnerabilities are not compromised +* The underlying host is managed to ensure that vulnerabilities are identified and mitigated with patches +* Docker server certificate file (the file that is passed along with the `--tlscert` parameter) + is individual owned and group owned by root. +* Docker server certificate file (the file that is passed along with the `--tlscert` parameter) + has permissions of 444 or more restrictive permissions. +* Docker server certificate key file (the file that is passed along with the `--tlskey` parameter) + is individually owned and group owned by root. +* Docker server certificate key file (the file that is passed along with the `--tlskey` parameter) has permissions of 400 +* Docker socket file is owned by root and group owned by docker. +* Docker socket file has permissions of 660 or are configured more restrictively +* ensure `daemon.json` file individual ownership and group ownership is correctly set to root, if it is in use +* if `daemon.json` file is present its file permissions are correctly set to 644 or more restrictively + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue140101] or [edit on GitHub][edit140101]. + +[docker]: https://docs.docker.com/get-started/09_image_best/ +[edit140101]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/01-implementation-dos-donts/01-container-security.md +[issue140101]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%20/14-appendices/01-implementation-dos-donts/01-container-security diff --git a/release-ja/14-appendices/01-implementation-dos-donts/02-secure-coding.md b/release-ja/14-appendices/01-implementation-dos-donts/02-secure-coding.md new file mode 100644 index 00000000..17064610 --- /dev/null +++ b/release-ja/14-appendices/01-implementation-dos-donts/02-secure-coding.md @@ -0,0 +1,342 @@ +--- + +title: Secure Coding +layout: col-document +tags: OWASP Developer Guide +contributors: Shruti Kulkarni +document: OWASP Developer Guide +order: 14120 +permalink: /release/appendices/implementation_dos_donts/secure_coding/ + +--- + +{% include breadcrumb.html %} + +### 12.1.2 Secure coding + +Here is a collection of Do's and Don'ts when it comes to secure coding, gathered from practical experiences. +Some of these are language specific and others have more general applicability. + +* Authentication + * User + * Require authentication for all pages and resources, except those specifically intended to be public + * Perform all authentication on server side. Send credentials only on encrypted channel (HTTPS) + * Use a centralized implementation for all authentication controls, including libraries that call external + authentication services. Use security vetted libraries for federation (Okta / PING / etc). + If using third party code for authentication, inspect the code carefully to ensure it is not affected + by any malicious code + * Segregate authentication logic from the resource being requested and use redirection to and from + the centralized authentication control + * Validate the authentication data only on completion of all data input, + especially for sequential authentication implementations + * Authentication failure responses should not indicate which part of the authentication data was incorrect. + For example, instead of "Invalid username" or "Invalid password", + just use "Invalid username and/or password" for both. + Error responses must be truly identical in both display and source code + * Utilize authentication for connections to external systems that involve sensitive information or functions + * Authentication credentials for accessing services external to the application should be encrypted + and stored in a protected location on a trusted system (e.g., Secrets Manager). + The source code is NOT a secure location. + * Do not store passwords in code or in configuration files. Use Secrets Manager to store passwords + * Use only HTTP POST requests to transmit authentication credentials + * Implement monitoring to identify attacks against multiple user accounts, utilizing the same password. + This attack pattern is used to bypass standard lockouts, when user IDs can be harvested or guessed + * Re-authenticate users prior to performing critical operations + * Use Multi-Factor Authentication for highly sensitive or high value transactional accounts + * If using third party code for authentication, inspect the code carefully + to ensure it is not affected by any malicious code + * Restrict the user if a pre-defined number of failed logon attempts exceed. + Restrict access to a limited number of attempts to prevent brute force attacks + * Partition the portal into restricted and public access areas + * Restrict authentication cookies to HTTPS connections + * If the application has any design to persist passwords in the database, hash and salt the password + before storing in database. Compare hashes to validate password + * Authenticate the user before authorizing access to hidden directories + * Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks + by using the same messages for all outcomes. + * Server + * When using SSL/TLS, ensure that the server identity is established by following a trust chain + to a known root certificate + * When using SSL/TLS, validate the host information of the server certificate. + * If weak client authentication is unavoidable, perform it only over a secure channel + * Do not rely upon IP numbers or DNS names in establishing identity. + * Ensure all internal and external connections (user and entity) go through an appropriate + and adequate form of authentication. Be assured that this control cannot be bypassed. + * For the account that runs the web server: + * Grant permissions to only those folders that the application needs to access + * Grant only those privileges that the account needs + * Disable HTTP TRACE. + It can help in bypassing WAF because of it inherent nature of TRACE response includes all headers on its route. + Please see - [Three Minutes with the HTTP TRACE Method][trace] - for further details + * Disable WEBDav feature unless it is required for business reasons. + If it is, perform a risk assessment for enabling the feature on your environment. + * Ensure that authentication credentials are sent on an encrypted channel + * Ensure development/debug backdoors are not present in production code. + * Password policy + * Provide a mechanism for self-reset and do not allow for third-party reset. + * If the application has any design to persist passwords in the database, hash and salt the password + before storing in database. Compare hashes to validate password. + * Rate limit bad password guesses to a fixed number(5) in a given time period (5-minute period) + * Provide a mechanism for users to check the quality of passwords when they set or change it. + * Only send non-temporary passwords over an encrypted connection or as encrypted data, + such as in an encrypted email. Temporary passwords associated with email resets may be an exception + * Enforce password complexity requirements established by policy or regulation. + Authentication credentials should be sufficient to withstand attacks that are typical + of the threats in the deployed environment. + (e.g., requiring the use of alphabetic as well as numeric and/or special characters) + * Enforce password length requirements established by policy or regulation. Eight characters is commonly used, + but 16 is better or consider the use of multi-word pass phrases + * Password entry should be obscured on the user's screen. (e.g., on web forms use the input type "password") + * Enforce account disabling after an established number of invalid login attempts (e.g., five attempts is common). + The account must be disabled for a period of time sufficient to discourage brute force guessing of credentials, + but not so long as to allow for a denial-of-service attack to be performed + * Password reset and changing operations require the same level of controls as account creation and authentication. + * Password reset questions should support sufficiently random answers. + (e.g., "favorite book" is a bad question because “The Bible” is a very common answer) + * If using email based resets, only send email to a pre-registered address with a temporary link/password + * Temporary passwords and links should have a short expiration time + * Enforce the changing of temporary passwords on the next use + * Notify users when a password reset occurs + * Prevent password re-use + * For high risk application (for example banking applications or any application the compromise of credentials + of which may lead to identity theft), passwords should be at least one day old before they can be changed, + to prevent attacks on password re-use + * Enforce password changes based on requirements established in policy or regulation. Critical systems + may require more frequent changes. The time between resets must be administratively controlled + * Disable "remember me" functionality for password fields + * Avoid sending authentication information through E-mail, particularly for existing users. +* Authorization + * Access control + * Build authorization on rules based access control. + Persist the rules as a matrix (for example as a list of strings which is passed as a parameter to a method + that is run when the user first access the page, based on which access is granted). + Most frameworks today, support this kind of matrix. + * Check if the user is authenticated before checking the access matrix. + If the user is not authenticated, direct the user to the login page. + Alternatively, use a single site-wide component to check access authorization. + This includes libraries that call external authorization services + * Ensure that the application has clearly defined the user types and the privileges for the users. + * Ensure there is a least privilege stance in operation. Add users to groups and assign privileges to groups + * Scan the code for development/debug backdoors before deploying the code to production. + * Re-Authenticate the user before authorizing the user to perform business critical activities + * Re-Authenticate the user before authorizing the user to admin section of the application + * Do not include authorization in the query string. Direct the user to the page via a hyperlink on a page. + Authenticate the user before granting access. For example if `admin.php` is the admin page for `www.example.com` + do not create a query string like `www.example.com/admin.php`. + Instead include a hyperlink to `admin.php` on a page and control authorization to the page + * Prevent forced browsing with role based access control matrix + * Ensure Lookup IDs are not accessible even when guessed and lookup IDs cannot be tampered with + * Enforce authorization controls on every request, including those made by server side scripts, + "includes" and requests from rich client-side technologies like AJAX and Flash + * Server side implementation and presentation layer representations of access control rules must match + * Implement access controls for POST, PUT and DELETE especially when building an API + * Use the "referer" header as a supplemental check only, it should never be the sole authorization check, + as it is can be spoofed + * Ensure it is not possible to access sensitive URLs without proper authorization. + Resources like images, videos should not be accessed directly by simply specifying the correct path + * Test all URLs on administrator pages to ensure that authorization requirements are met. + If verbs are sent cross domain, pin the OPTIONS request for non-GET verbs to the IP address of + subsequent requests. This will be a first step toward mitigating DNS Rebinding and TOCTOU attacks. + * Session management + * Creation of session: Use the server or framework’s session management controls. + The application should only recognize these session identifiers as valid + * Creation of session: Session identifier creation must always be done on a trusted system (e.g., The server) + * Creation of session: If a session was established before login, + close that session and establish a new session after a successful login + * Creation of session: Generate a new session identifier on any re-authentication + * Random number generation: Session management controls should use well vetted algorithms + that ensure sufficiently random session identifiers. + Rely on CSPRNG rather than PRNG for random number generation + * Domain and path: Set the domain and path for cookies containing authenticated session identifiers + to an appropriately restricted value for the site + * Logout: Logout functionality should fully terminate the associated session or connection + * Session timeout: Establish a session inactivity timeout that is as short as possible, + based on balancing risk and business functional requirements. + In most cases it should be no more than several hours + * Session ID: Do not expose session identifiers in URLs, error messages or logs. + Session identifiers should only be located in the HTTP cookie header. For example, + do not pass session identifiers as GET parameters + * Session ID: Supplement standard session management for sensitive server-side operations, like account management, + by utilizing per-session strong random tokens or parameters. + This method can be used to prevent Cross Site Request Forgery attacks + * JWT + * Reject tokens set with ‘none’ algorithm when a private key was used to issue them (`alg: ""none""`). + This is because an attacker may modify the token and hashing algorithm to indicate, through the ‘none’ keyword, + that the integrity of the token has already been verified, + fooling the server into accepting it as a valid token + * Use appropriate key length (e.g. 256 bit) to protect against brute force attacks. + This is because attackers may change the algorithm from ‘RS256’ to ‘HS256’ and use the public key to generate + a HMAC signature for the token, as server trusts the data inside the header of a JWT + and doesn’t validate the algorithm it used to issue a token. + The server will now treat this token as one generated with ‘HS256’ algorithm + and use its public key to decode and verify it + * Adjust the JWT token validation time depending on required security level (e.g. from few minutes up to an hour). + For extra security, consider using reference tokens if there’s a need to be able to revoke/invalidate them + * Use HTTPS/SSL to ensure JWTs are encrypted during client-server communication, + reducing the risk of the man-in-the-middle attack. This is because sensitive information may be revealed, + as all the information inside the JWT payload is stored in plain text + * Only use up-to-date and secure libraries and choose the right algorithm for requirements + * Verify all tokens before processing the payload data. Do not use unsigned tokens. + For the tokens generated and consumed by the portal, sign and verify tokens + * Always check that the `aud` field of the JWT matches the expected value, + usually the domain or the URL of your APIs. If possible, check the "sub" (client ID) - make sure that + this is a known client. This may not be feasible however in a public API situation + (e.g., we trust all clients authorized by Google). + * Validate the issuer's URL (`iss`) of the token. It must match your authorization server. + * If an authorization server provides X509 certificates as part of its JWT, + validate the public key using a regular PKIX mechanism + * Make sure that the keys are frequently refreshed/rotated by the authorization server. + * Make sure that the algorithms you use are sanctioned by JWA ([RFC7518][rfc7518]) + * There is no built in mechanism to revoke a token manually, before it expires. + One way to ensure that the token is force expired build a service that can be called on log out. + In the mentioned service, block the token. + * Restrict accepted algorithms to the ONE you want to use + * Restrict URLs of any JWKS/X509 certificates + * Use the strongest signing process you can afford the CPU time for + * Use asymmetric keys if the tokens are used across more than one server + * SAML +* Input data validation + * Identify input fields that form a SQL query. Check that these fields + are suitably validated for type, format, length, and range. + * To prevent SQL injection use bind variables in stored procedures and SQL statements. + Also referred as prepared statements / parameterization of SQL statements. + DO NOT concatenate strings that are an input to the database. + The key is to ensure that raw input from end users is not accepted without sanitization. + When converting data into a data structure (deserializing), perform explicit validation for all fields, + ensuring that the entire object is semantically valid. + Many technologies now come with data access layers that support input data validation. + These layers are usually in the form of a library or a package. Ensure to add + these libraries / dependencies / packages to the project file such that they are not missed out. + * Use a security vetted library for input data validation. Try not to use hard coded allow-list of characters. + Validate all data from a centralized function / routine. + In order to add a variable to a HTML context safely, use HTML entity encoding + for that variable as you add it to a web template. + * Validate HTTP headers. Dependencies that perform HTTP headers validation are available in technologies. + * Validate post backs from javascript. + * Validate data from http headers, input fields, hidden fields, drop down lists & other web components + * Validate data retrieved from database. This will help mitigate persistent XSS. + * Validate all redirects. Unvalidated redirects may lead to data / credential exfiltration. + Evaluate any URL encodings before trying to use the URL. + * Validate data received from redirects. The received data may be from untrusted source. + * If any potentially hazardous characters must be allowed as input, + be sure that you implement additional controls like output encoding, + secure task specific APIs and accounting for the utilization of that data throughout the application. + Examples of common hazardous characters include `< > " ' % ( ) & + \ \' \"` + * If your standard validation routine cannot address the following inputs, then they should be checked discretely + * Check for null bytes `%00` + * Check for new line characters `%0d, %0a, \r, \n` + * Check for “dot-dot-slash" `../` or `..\` path alterations characters. + In cases where UTF-8 extended character set encoding is supported, address alternate representation like: + `%c0%ae%c0%ae/` + (Utilize canonicalization to address double encoding or other forms of obfuscation attacks) + * Client-side storage (`localStorage`, `SessionStorage`, `IndexedDB`, WebSQL): + If you use client-side storage for persistence of any variables, + validate the date before consuming it in the application + * Reject all input data that has failed validation. + * If used, don’t involve user parameters in calculating the destination. This can usually be done. + If destination parameters can’t be avoided, ensure that the supplied value is valid, + and authorized for the user. + It is recommended that any such destination parameters be a mapping value, + rather than the actual URL or portion of the URL, + and that server side code translate this mapping to the target URL. + Applications can use ESAPI to override the `sendRedirect()` method + to make sure all redirect destinations are safe. +* Output data encoding + * If your code echos user input or URL parameters back to a Web page, validate input data as well as output data. + It will help you prevent persistent as well as reflective cross-site scripting. + Pay particular attention to areas of the application that permit users + to modify configuration or personalization settings. + Also pay attention to persistent free-form user input, + such as message boards, forums, discussions, and Web postings. + Encode javascript to prevent injection by escaping non-alphanumeric characters. + Use quotation marks like " or ' to surround your variables. + Quoting makes it difficult to change the context a variable operates in, which helps prevent XSS + * Conduct all encoding on a trusted system (e.g., The server) + Utilize a standard, tested routine for each type of outbound encoding + Contextually output encode all data returned to the client + that originated outside the application's trust boundary. + HTML entity encoding is one example, but does not work in all cases + Encode all characters unless they are known to be safe for the intended interpreter + Contextually sanitize all output of untrusted data to queries for SQL, XML, and LDAP + Sanitize all output of untrusted data to operating system commands + * Output encoding is not always perfect. It will not always prevent XSS. Some contexts are not secure. These include: + Callback functions + Where URLs are handled in code such as this CSS `{ background-url : “javascript:alert(test)”; }` + All JavaScript event handlers (`onclick()`, `onerror()`, `onmouseover()`). + Unsafe JavaScript functions like `eval()`, `setInterval()`, `setTimeout()` + Don't place variables into these contexts as even with output encoding, it will not prevent an XSS attack fully + * Do not rely on client-side validation. Perform validation on server side to prevent second order attacks. +* Canonicalisation + * Convert all input data to an accepted/decided format like UTF-8. This will help prevent spoofing of character +* Test all URLs with different parameter values. + Spider and check the site/product/application/portal for redirects. +* Connection with backend + Assign required permissions and privileges for accounts / roles + used by the application to connect to the database. + In the event of any compromise of the account / role, + the malicious actor would be able to do whatever the account /role has permissions for. +* Insecure direct object references +* Unvalidated redirects + Test all URLs with different parameter values to validate any redirects + If used, do not allow the URL as user input for the destination. + Where possible, have the user provide short name, ID or token which is mapped server-side to a full target URL. + This provides the protection against the URL tampering attack. + Be careful that this doesn't introduce an enumeration vulnerability where + a user could cycle through IDs to find all possible redirect targets + If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, + and is authorized for the user. + Sanitize input by creating a list of trusted URLs (lists of hosts or a regex). + This should be based on an allow-list approach, rather than a block list. + Force all redirects to first go through a page notifying users that they are going off of your site, + with the destination clearly displayed, and have them click a link to confirm. +* JSON + For JSON, verify that the Content-Type header is application/json and not text/html to prevent XSS + Do not use duplicate keys. Usage of duplicate keys may be processed differently by parsers. + For example last-key precedence versus first-key precedence. +* Generate fatal parse errors on duplicate keys. + Do not perform character truncation. Instead, replace invalid Unicode with placeholder characters + (e.g., unpaired surrogates should be displayed as the Unicode replacement character `U+FFFD`). + Truncating may break sanitization routines for multi-parser applications." +* Produce errors when handling integers or floating-point numbers that cannot be represented faithfully +* Do not use `eval()` with JSON. This opens up for JSON injection attacks. Use JSON.parse() instead + Data from an untrusted source is not sanitized by the server and written directly to a JSON stream. + This is referred to as server-side JSON injection. + Data from an untrusted source is not sanitized and parsed directly using the JavaScript `eval` function. + This is referred to as client-side JSON injection. + To prevent server-side JSON injections, sanitize all data before serializing it to JSON + Escape characters like ":", "\", "@", "'”", "%", "?", "--", ">", "<", "&" + +#### JSON Vulnerability Protection + +A JSON vulnerability allows third party website to turn your JSON resource URL into JSONP request under some conditions. +To counter this your server can prefix all JSON requests with following string `")]}',\n"`. +AngularJS will automatically strip the prefix before processing it as JSON. + +For example if your server needs to return: `['one','two']` +which is vulnerable to attack, your server can return: `)]}', ['one','two']` + +Refer to [JSON vulnerability protection](https://docs.angularjs.org/api/ng/service/$http#json-vulnerability-protection) +Always have the outside primitive be an object for JSON strings + +Exploitable: `[{""object"": ""inside an array""}]` + +Not exploitable: `{""object"": ""not inside an array""}` + +Also not exploitable: `{""result"": [{""object"": ""inside an array""}]}"` + +* Avoid manual build of JSON, use an existing framework +* Ensure calling function does not convert JSON into a javascript + and JSON returns its response as a non-array json object +* Wrap JSON in () to force the interpreter to think of it as JSON and not a code block +* When using node.js, on the server use a proper JSON serializer to encode user-supplied data properly + to prevent the execution of user-supplied input on the browser. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue140102] or [edit on GitHub][edit140102]. + +[edit140102]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/01-implementation-dos-donts/02-secure-coding.md +[issue140102]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%20/14-appendices/01-implementation-dos-donts/02-secure-coding +[rfc7518]: https://www.rfc-editor.org/rfc/rfc7518 +[trace]: https://www.blackhillsinfosec.com/three-minutes-with-the-http-trace-method/ diff --git a/release-ja/14-appendices/01-implementation-dos-donts/03-cryptographic-practices.md b/release-ja/14-appendices/01-implementation-dos-donts/03-cryptographic-practices.md new file mode 100644 index 00000000..8fde2396 --- /dev/null +++ b/release-ja/14-appendices/01-implementation-dos-donts/03-cryptographic-practices.md @@ -0,0 +1,74 @@ +--- + +title: Cryptographic Practices +layout: col-document +tags: OWASP Developer Guide +contributors: Shruti Kulkarni +document: OWASP Developer Guide +order: 14130 +permalink: /release/appendices/implementation_dos_donts/cryptographic_practices/ + +--- + +{% include breadcrumb.html %} + +### 12.1.3 Cryptographic practices + +Here is a collection of Do's and Don'ts when it comes to cryptographic practices, gathered from practical experiences. + +* The basis for usage of PKI is to address (using encryption and hashing) +* Confidentiality +* Integrity +* Authentication +* Non-repudiation +* Cryptography is used for the following: + * Data-at-rest protection using data encrypting keys and key encrypting keys. For which, +* Do not use custom cryptographic algorithms / deprecated algorithms +* Do not use passwords as cryptographic keys +* Do not hard-code cryptographic keys in the application +* Persist secret keys in a secure vault like HSM, KMS, Secrets Manager +* Manage encryption keys through the lifecycle, including key retirement/replacement + when someone who has access leaves the organization +* Rotate keys on a regular basis. However this depends on the key strength and the algorithm used. + If the key strength is low, the rotation period will be smaller +* Maintain a contingency plan to recover data in the event of an encrypted key being lost +* Ensure the code eliminates secrets from memory. +* Maintain a contingency plan that can recover data in the event of an encrypted key being lost +* Store keys away from the data +* Do not use IV twice for a fixed key +* Communication security +* Ensure no sensitive data is transmitted in the clear, internally or externally. +* Validate certificates properly against the hostnames/users for whom they are meant +* Failed TLS connections should not fall back to an insecure connection +* Do not use IV twice for a fixed key +* Cryptography in general +* All protocols and algorithms for authentication and secure communication + should be well vetted by the cryptographic community. +* Perform Message integrity checking by using a combined mode of operation, or a MAC based on a block cipher. +* Do not use key sizes less than 128 bits or cryptographic hash functions with output sizes less than 160 bits. +* Do not use custom cryptographic algorithms that have not been vetted by cryptography community +* Do not hardcode cryptographic keys in applications? +* Issue keys using a secure means. +* Maintain a key lifecycle for the organization (Creation, Storage, Distribution and installation, Use, + Rotation, Backup, Recovery, Revocation, Suspension, Destruction) +* Lock and unlock symmetric secret keys securely +* Maintain CRL (Certificate Revocation Lists) maintained on a real-time basis +* Validate certificates properly against the hostnames/users for whom they are meant +* Ensure the code eliminates secrets from memory +* Specific encryption, in addition to SSL +* Mask or remove keys from logs +* Use salted hashes when using MD5 or any such less secure algorithms +* Use known encryption algorithms, do not create your own as they will almost certainly be less secure +* Persist secret keys in a secure vault like HSM, KMS, Secrets Manager +* Do not use IV twice for a fixed key +* Ensure that cryptographic randomness is used where appropriate, + and that it has not been seeded in a predictable way or with low entropy. + Most modern APIs do not require the developer to seed the CSPRNG to get security. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue140103] or [edit on GitHub][edit140103]. + +[edit140103]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/01-implementation-dos-donts/03-cryptographic-practices.md +[issue140103]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%20/14-appendices/01-implementation-dos-donts/03-cryptographic-practices diff --git a/release-ja/14-appendices/01-implementation-dos-donts/04-application-spoofing.md b/release-ja/14-appendices/01-implementation-dos-donts/04-application-spoofing.md new file mode 100644 index 00000000..1dd745c2 --- /dev/null +++ b/release-ja/14-appendices/01-implementation-dos-donts/04-application-spoofing.md @@ -0,0 +1,82 @@ +--- + +title: Application Spoofing +layout: col-document +tags: OWASP Developer Guide +contributors: Shruti Kulkarni +document: OWASP Developer Guide +order: 14140 +permalink: /release/appendices/implementation_dos_donts/application_spoofing/ + +--- + +{% include breadcrumb.html %} + +### 12.1.4 Application Spoofing + +Here is a collection of Do's and Don'ts when it comes to application spoofing, gathered from practical experiences. +Some of these are language specific and others have more general applicability. + +What is application spoofing: + +* A threat actor including an application in a malicious iFrame +* A threat actor creating dependencies with similar names as legitimate ones (typo squatting) + +How can it be addressed: + +#### Application spoofing / clickjacking + +Set `X-FRAME-OPTIONS` header to `SAMEORIGIN` or `DENY`, depending on what the business requirement is +for rendering the web page. +This will help prevent a malicious actor including your application in an iFrame to capture credentials/exfiltrate data. +As a caveat, this will not work with Meta Tags. X-FRAME-OPTIONS must be applied as HTTP Response Header + +Use Content Security Policy: + +Common uses of CSP frame-ancestors: + +Content-Security-Policy: frame-ancestors 'none'; + +This prevents any domain from framing the content. This setting is recommended unless a specific need +has been identified for framing. + +Content-Security-Policy: frame-ancestors 'self'; + +This only allows the current site to frame the content. + +Content-Security-Policy: frame-ancestors 'self' `*.somesite.com https://myfriend.site.com;` + +This allows the current site, as well as any page on `somesite.com` (using any protocol), +and only the page `myfriend.site.com`, using HTTPS only on the default port (443). + +Use `SameSite` Cookies + +Use `httpOnly` cookies + +#### Domain squatting / typo squatting + +What is domain squatting (also known as cybersquatting): + +* A threat actor creating a malicious domain with the same spelling as a legitimate domain + but use different UTF characters (domain squatting) +* A threat actor registering, trafficking in, or using an Internet domain name, + with an intent to profit from the goodwill of a trademark belonging to someone else +* Though domain squatting impacts brand value directly, it has an impact from a security perspective +* It can result in the following kind of scenario: (also known as typosquatting) + Wherein the domain with U+00ED may be a malicious application trying to harvest credentials +* Typo squatting is achieved with supply chain manipulation. + +How can it be addressed: + +* Use threat intelligence to monitor lookalikes for your domain +* In the event a dispute needs to be raised, it can be done with [URDP][urdp] +* Verify packages in registries before using them + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue140104] or [edit on GitHub][edit140104]. + +[edit140104]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/01-implementation-dos-donts/04-application-spoofing.md +[issue140104]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%20/14-appendices/01-implementation-dos-donts/04-application-spoofing +[urdp]: https://www.icann.org/resources/pages/help/dndr/udrp-en diff --git a/release-ja/14-appendices/01-implementation-dos-donts/05-content-security-policy.md b/release-ja/14-appendices/01-implementation-dos-donts/05-content-security-policy.md new file mode 100644 index 00000000..d83b70b9 --- /dev/null +++ b/release-ja/14-appendices/01-implementation-dos-donts/05-content-security-policy.md @@ -0,0 +1,161 @@ +--- + +title: Content Security Policy +layout: col-document +tags: OWASP Developer Guide +contributors: Shruti Kulkarni +document: OWASP Developer Guide +order: 14150 +permalink: /release/appendices/implementation_dos_donts/content_security_policy/ + +--- + +{% include breadcrumb.html %} + +### 12.1.5 Content Security Policy + +Here is a collection of Do's and Don'ts when it comes to Content Security Policy, gathered from practical experiences. +Some of these are language specific and others have more general applicability. + +Content Security Policy (CSP) helps in allow-listing the sources that are allowed to be executed by clients. + +To this effect CSP helps in addressing vulnerabilities that are the target of scripts getting executed +from different domains (namely XSS, ClickJacking) + +1. The policy elements listed below is restrictive. + Third party libraries can be allow-listed as a part of `script-src`, `default-src`, `frame-src` + or `frame-ancestors`. + +2. I assume fonts / images / media / plugins are not loaded from any external sources. + +3. Do not use `\*\` as an attribute for any of the components of the policy. + +CSP considers two types of content: + +Passive content - resources which cannot directly interact with or modify other resources on a page: +images, fonts, audio, and video for example + +Active content - content which can in some way directly manipulate the resource with which a user is interacting. + +SCOPE + +The scope of this policy / procedure / whatever includes (but not limited to): + +- Applications that are displayed in browsers + - On desktops + - On laptops + - On mobile devices +- Mobile Applications + - iOS + - Android + +Policy for content security should be set in <> (insert the URL where the report for policy violations should be sent) +- sandbox (this is something to be tried out specifies an HTML sandbox policy + that the user agent applies to the protected resource) +- `plugin-types` <<>> (insert the list of plugins that the protected resource can invoke) +- `base-uri` (restricts the URLs that can be used to specify the document base URL, but I do not know how this is used) +- `child-src` 'self' + +An Example: + +```text + +``` + +For display on desktops and laptops: add `name="Content-Security-Policy"` value + +For display on other mobile devices that use HTML5: `meta http-equiv="Content-Security-Policy"` + +#### Mobile Application + +#### iOS + +iOS framework has capability to restrict connecting to sites that are not a part of the allow-list on the application, +which is the `NSExceptionDomains`. Use this setting to restrict the content that gets executed by the application + +```text +NSAppTransportSecurity : Dictionary { + NSAllowsArbitraryLoads : Boolean + NSAllowsArbitraryLoadsForMedia : Boolean + NSAllowsArbitraryLoadsInWebContent : Boolean + NSAllowsLocalNetworking : Boolean + NSExceptionDomains : Dictionary { + : Dictionary { + NSIncludesSubdomains : Boolean + NSExceptionAllowsInsecureHTTPLoads : Boolean + NSExceptionMinimumTLSVersion : String + NSExceptionRequiresForwardSecrecy : Boolean + NSRequiresCertificateTransparency : Boolean + } + } +} +``` + +#### Android + +Setting rules for Android application: + +- If your application doesn't directly use JavaScript within a WebView, do not call `setJavaScriptEnabled()` +- By default, WebView does not execute JavaScript, so cross-site-scripting is not possible +- Use `addJavaScriptInterface()` with particular care because it allows JavaScript to invoke operations + that are normally reserved for Android applications. If you use it, expose `addJavaScriptInterface()` + only to web pages from which all input is trustworthy +- Expose a`ddJavaScriptInterface()` only to JavaScript that is contained within your application APK +- When sharing data between two apps that you control or own, use signature-based permissions + +```text + + package="com.example.myapp"> + +``` + +- Disallow other apps from accessing Content Provider objects + +```text + + package="com.example.myapp"> + + + + + ... + + +``` + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue140105] or [edit on GitHub][edit140105]. + +[edit140105]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/01-implementation-dos-donts/05-content-security-policy.md +[issue140105]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%20/14-appendices/01-implementation-dos-donts/05-content-security-policy diff --git a/release-ja/14-appendices/01-implementation-dos-donts/06-exception-error-handling.md b/release-ja/14-appendices/01-implementation-dos-donts/06-exception-error-handling.md new file mode 100644 index 00000000..5f719b48 --- /dev/null +++ b/release-ja/14-appendices/01-implementation-dos-donts/06-exception-error-handling.md @@ -0,0 +1,109 @@ +--- + +title: Exception and Error Handling +layout: col-document +tags: OWASP Developer Guide +contributors: Shruti Kulkarni +document: OWASP Developer Guide +order: 14160 +permalink: /release/appendices/implementation_dos_donts/exception_error_handling/ + +--- + +{% include breadcrumb.html %} + +### 12.1.6 Exception and Error Handling + +Here is a collection of Do's and Don'ts when it comes to exception and error handling, gathered from practical experiences. +Some of these are language specific and others have more general applicability. + +* Ensure that all method/function calls that return a value have proper error handling and return value checking +* Ensure that exceptions and error conditions are properly handled +* Ensure that no system errors can be returned to the user +* Ensure that the application fails in a secure manner +* Ensure resources are released if an error occurs. +* Ensure that stack trace is not thrown to the user. +* Swallowing exceptions into an empty catch() block is not advised as an audit trail + of the cause of the exception would be incomplete +* Code that might throw exceptions should be in a try block and code that handles exceptions in a catch block +* If the language in question has a finally method, use it. The finally method is guaranteed to always be called +* The finally method can be used to release resources referenced by the method that threw the exception +* This is very important. An example would be if a method gained a database connection from a pool of connections, + and an exception occurred without finally, the connection object shall not be returned + to the pool for some time (until the timeout) +* This can lead to pool exhaustion. finally() is called even if no exception is thrown +* Handle errors and exception conditions in the code +* Do not expose sensitive information in user sessions +* When working with a multi-threaded or otherwise asynchronous environment, + ensure that proper locking APIs are used to lock before the if statement; + and unlock when it has finished. +* Types of errors: + * The result of business logic conditions not being met + * The result of the environment wherein the business logic resides fails + * The result of upstream or downstream systems upon which the application depends fail + * Technical hardware / physical failure +* Failures are never expected, but they do occur. + In the event of a failure, it is important not to leave the "doors" of the application open + and the keys to other "rooms" within the application sitting on the table. + In the course of a logical workflow, which is designed based upon requirements, + errors may occur which can be programmatically handled, + such as a connection pool not being available, or a downstream server not being contactable +* This is a very tricky guideline. + To fail securely, areas of failure should be examined during the course of the code review. + It should be examined if all resources should be released in the case of a failure + and during the thread of execution if there is any potential for resource leakage, + resources being memory, connection pools, file handles etc + Include a statement that defaults to safe failure +* The review of code should also include pinpointing areas where the user session should be terminated or invalidated. +Sometimes errors may occur which do not make any logical sense from a business logic perspective +or a technical standpoint; + e.g: ""A logged in user looking to access an account which is not registered to that user + and such data could not be inputted in the normal fashion.""" +* Examine the application for 'main()' executable functions and debug harnesses/backdoors + In their basic form, backdoors are user id / password combination with the required privileges, embedded in the code, + which can be used later on by the developer to get into the system without having to request for login credentials +* Search for commented out code, commented out test code, which may contain sensitive information +* Search for any calls to the underlying operating system or file open calls and examine the error possibilities + +#### Logging + +* Ensure that no sensitive information is logged in the event of an error +* Ensure the payload being logged is of a defined maximum length and that the logging mechanism enforces that length +* Ensure no sensitive data can be logged; E.g. cookies, HTTP GET method, authentication credentials +* Examine if the application will audit the actions being taken by the application on behalf of the client + (particularly data manipulation/Create, Read, Update, Delete (CRUD) operations) +* Ensure successful and unsuccessful authentication is logged +* Ensure application errors are logged +* Examine the application for debug logging with the view to logging of sensitive data +* Ensure change in sensitive configuration information is logged along with user who modified it. + Ensure access to secure storage areas including crypto keys are logged +* Credentials and sensitive user data should not be logged +* Does the code include poor logging practice of not declaring Logger object as static and final? +* Does the code allow entering invalidated user input to the log file? +* Capture following details for the events: + * User identification + * Type of event + * Date and time + * Success and failure indication + * Origination of event + * Identity or name of affected data, system component, resource, or service (for example, name and protocol) +* Log file access, privilege elevation, and failures of financial transactions +* Log all administrators actions. Log all actions taken after privileges are elevated - `runas` / `sudo` +* Log all input validation failures +* Log all authentication attempts, especially failures +* Log all access control failures +* Log all apparent tampering events, including unexpected changes to state data +* Log attempts to connect with invalid or expired session tokens +* Log all system exceptions +* Log all administrative functions, including changes to the security configuration settings +* Log all backend TLS connection failures +* Log cryptographic module failures +* Use a cryptographic hash function to validate log entry integrity + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue140106] or [edit on GitHub][edit140106]. + +[edit140106]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/01-implementation-dos-donts/06-exception-error-handling.md +[issue140106]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%20/14-appendices/01-implementation-dos-donts/06-exception-error-handling diff --git a/release-ja/14-appendices/01-implementation-dos-donts/07-file-management.md b/release-ja/14-appendices/01-implementation-dos-donts/07-file-management.md new file mode 100644 index 00000000..130db0bf --- /dev/null +++ b/release-ja/14-appendices/01-implementation-dos-donts/07-file-management.md @@ -0,0 +1,51 @@ +--- + +title: File Management +layout: col-document +tags: OWASP Developer Guide +contributors: Shruti Kulkarni +document: OWASP Developer Guide +order: 14170 +permalink: /release/appendices/implementation_dos_donts/file_management/ + +--- + +{% include breadcrumb.html %} + +### 12.1.7 File Management + +Here is a collection of Do's and Don'ts when it comes to file management, gathered from practical experiences. + +* Validate all filenames and directories before use, ensuring that there are no special characters + that might lead to accessing an unintended file +* Use safe directories for all file access except those initiated by the end user + e.g. document saving and restoring to a user-chosen location +* Use a sub-domain with one way trust for the downloaded files. + Such that any compromise of the sub-domain does not impact the main domain. + Do not save files in the same web context as the application. + Files should either go to the content server or in the database +* Have at least 64 bits of randomness in all temporary file names +* where applicable, require authentication before allowing a file to be uploaded +* Limit the type of files that can be uploaded to only those types that are needed for business purposes +* Validate uploaded files are the expected type by checking file headers +* Prevent or restrict the uploading of any file that may be interpreted by the web server +* Turn off execution privileges on file upload directories +* Implement safe uploading in UNIX by mounting the targeted file directory as a logical drive + using the associated path or the chrooted environment +* When referencing existing files, use an allow list of allowed file names and types. + Validate the value of the parameter being passed and if it does not match one of the expected values, + either reject it or use a hard coded default file value for the content instead +* Do not pass user supplied data into a dynamic redirect. + If this must be allowed, then the redirect should accept only validated, relative path URLs +* Do not pass directory or file paths, use index values mapped to pre-defined list of paths +* Never send the absolute file path to the client +* Ensure application files and resources are read-only +* Scan user uploaded files for viruses and malware + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue140107] or [edit on GitHub][edit140107]. + +[edit140107]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/01-implementation-dos-donts/07-file-management.md +[issue140107]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%20/14-appendices/01-implementation-dos-donts/07-file-management diff --git a/release-ja/14-appendices/01-implementation-dos-donts/08-memory-management.md b/release-ja/14-appendices/01-implementation-dos-donts/08-memory-management.md new file mode 100644 index 00000000..0953148a --- /dev/null +++ b/release-ja/14-appendices/01-implementation-dos-donts/08-memory-management.md @@ -0,0 +1,35 @@ +--- + +title: Memory Management +layout: col-document +tags: OWASP Developer Guide +contributors: Shruti Kulkarni +document: OWASP Developer Guide +order: 14180 +permalink: /release/appendices/implementation_dos_donts/memory_management/ + +--- + +{% include breadcrumb.html %} + +### 12.1.8 Memory Management + +Here is a collection of Do's and Don'ts when it comes to memory management, gathered from practical experiences. + +* Check that the buffer is as large as specified +* When using functions that accept a number of bytes to copy, such as `strncpy()`, + be aware that if the destination buffer size is equal to the source buffer size, + it may not NULL-terminate the string +* Check buffer boundaries if calling the function in a loop and make sure there is no danger + of writing past the allocated space +* Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions +* Specifically close resources, do not rely on garbage collection. (for example connection objects, file handles, etc.) +* Properly free allocated memory upon the completion of functions and at all exit points. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue140108] or [edit on GitHub][edit140108]. + +[edit140108]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/01-implementation-dos-donts/08-memory-management.md +[issue140108]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2014-appendices/01-implementation-dos-donts/08-memory-management diff --git a/release-ja/14-appendices/01-implementation-dos-donts/info.md b/release-ja/14-appendices/01-implementation-dos-donts/info.md new file mode 100644 index 00000000..16409f12 --- /dev/null +++ b/release-ja/14-appendices/01-implementation-dos-donts/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="draft" %} diff --git a/release-ja/14-appendices/01-implementation-dos-donts/toc.md b/release-ja/14-appendices/01-implementation-dos-donts/toc.md new file mode 100644 index 00000000..3105f18b --- /dev/null +++ b/release-ja/14-appendices/01-implementation-dos-donts/toc.md @@ -0,0 +1,52 @@ +--- + +title: Implementation Do's and Don'ts +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 14100 +permalink: /release/appendices/implementation_dos_donts/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +### 12.1 Implementation Do's and Don'ts + +Implementation demands technical knowledge, skill and experience. +There is no substitute for experience, but learning from past mistakes and the experience of others can go a long way. +This section of the Developer Guide is a collection of Do's and Don'ts, +some of which may be directly relevant to any given project and some of which will be less so. +It is worth considering all of these Do's and Don'ts and picking out the ones that will be of most use. + +Sections: + +12.1.1 [Container security](01-container-security.md) +12.1.2 [Secure coding](02-secure-coding.md) +12.1.3 [Cryptographic practices](03-cryptographic-practices.md) +12.1.4 [Application spoofing](04-application-spoofing.md) +12.1.5 [Content Security Policy (CPS)](05-content-security-policy.md) +12.1.6 [Exception and error handling](06-exception-error-handling.md) +12.1.7 [File management](07-file-management.md) +12.1.8 [Memory management](08-memory-management.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue0740] or [edit on GitHub][edit0740]. + +[edit0740]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/01-implementation-dos-donts/toc.md +[issue0740]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2014-appendices/01-implementation-dos-donts/00-toc diff --git a/release-ja/14-appendices/02-verification-dos-donts/00-toc.md b/release-ja/14-appendices/02-verification-dos-donts/00-toc.md new file mode 100644 index 00000000..648ec229 --- /dev/null +++ b/release-ja/14-appendices/02-verification-dos-donts/00-toc.md @@ -0,0 +1,35 @@ +--- + +title: Verification Do's and Don'ts +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){height=180px} + +### 12.2 Verification Do's and Don'ts + +[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm]. + +Verification takes skill and knowledge, so it is important to build on the existing experience +contained in these Do's and Dont's. + +Sections: + +12.2.1 [Secure environment](#secure-environment) +12.2.2 [System hardening](#system-hardening) +12.2.3 [Open Source software](#open-source-software) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue1402]. + +[issue1402]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2014-appendices/02-verification-dos-donts/00-toc +[samm]: https://owaspsamm.org/about/ +[sammv]: https://owaspsamm.org/model/verification/ diff --git a/release-ja/14-appendices/02-verification-dos-donts/01-secure-environment.md b/release-ja/14-appendices/02-verification-dos-donts/01-secure-environment.md new file mode 100644 index 00000000..c1bdafd1 --- /dev/null +++ b/release-ja/14-appendices/02-verification-dos-donts/01-secure-environment.md @@ -0,0 +1,75 @@ +--- + +title: Secure Environment +layout: col-document +tags: OWASP Developer Guide +contributors: Shruti Kulkarni +document: OWASP Developer Guide +order: 14210 +permalink: /release/appendices/verification_dos_donts/secure_environment/ + +--- + +{% include breadcrumb.html %} + +### 12.2.1 Secure environment + +Here is a collection of Do's and Don'ts when it comes to creating a secure environment, gathered from practical experiences. +Some of these are language specific and others have more general applicability. + +* The WEB-INF directory tree contains web application classes, pre-compiled JSP files, server side libraries, + session information, and files such as `web.xml` and `webapp.properties`. + So be sure the code base is identical to production. + Ensuring that we have a “secure code environment” is also an important part of + an application secure code inspection. + +* Use a “deny all” rule to deny access and then grant access on need basis. + +* In Apache HTTP server, ensure directories like WEB-INF and META-INF are protected. + If permissions for a directory and subdirectories are specified in `.htaccess` file, + ensure that it is protected using the “deny all” rule. + +* While using Struts framework, ensure that JSP files are not accessible directly + by denying access to `*.jsp` files in `web.xml`. + +* Maintain a clean environment. remove files that contain source code but are not used by the application. + +* Ensure production environment does not contain any source code / development tools + and that the production environment contains only compiled code / executables. + +* Remove test code / debug code (that might contain backdoors). + Commented code can also be removed as at times, it might contain sensitive data. Remove file metadata e.g., .git + +* Set “Deny All” in security constraints (for the roles being set up) + while setting up the application on the web server. + +* The listing of HTTP methods in security constraints works in a similar way to deny-listing. + Any verb not explicitly listed is allowed for execution. Hence use “Deny All” + and then allow the methods for the required roles. + This setting carries weightage while using “Anonymous User” role. + For example, in Java, remove all `` elements from `web.xml` files. + +* Configure web and application server to disallow HEAD requests entirely. + +* Comments on code and Meta tags pertaining to the IDE used or technology used to develop the application + should be removed. Some comments can divulge important information regarding bugs in code + or pointers to functionality. This is particularly important with server side code such as JSP and ASP files. + +* Search for any calls to the underlying operating system or file open calls and examine the error possibilities. + +* Remove unused dependencies, unnecessary features, components, files, and documentation. + +* Only obtain components from official sources over secure links. + Prefer signed packages to reduce the chance of including a modified, malicious component + +* Monitor for libraries and components that are unmaintained or do not create security patches for older versions. + If patching is not possible, consider deploying a virtual patch to monitor, detect, + or protect against the discovered issue. + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue140201] or [edit on GitHub][edit140201]. + +[edit140201]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/02-verification-dos-donts/01-secure-environment.md +[issue140201]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2014-appendices/02-verification-dos-donts/01-secure-environment diff --git a/release-ja/14-appendices/02-verification-dos-donts/02-system-hardening.md b/release-ja/14-appendices/02-verification-dos-donts/02-system-hardening.md new file mode 100644 index 00000000..10294c2a --- /dev/null +++ b/release-ja/14-appendices/02-verification-dos-donts/02-system-hardening.md @@ -0,0 +1,81 @@ +--- + +title: System Hardening +layout: col-document +tags: OWASP Developer Guide +contributors: Shruti Kulkarni +document: OWASP Developer Guide +order: 14220 +permalink: /release/appendices/verification_dos_donts/system_hardening/ + +--- + +{% include breadcrumb.html %} + +### 12.2.2 System hardening + +Here is a collection of Do's and Don'ts when it comes to system hardening, gathered from practical experiences. +Some of these are language specific and others have more general applicability. + +* The WEB-INF directory tree contains web application classes, pre-compiled files, server side libraries, + session information, and files such as `web.xml` and `webapp.properties`. Secure these files + +* In Apache HTTP server, ensure directories like WEB-INF and META-INF are protected. + If permissions for a directory and subdirectories are specified in `.htaccess` file, + ensure that it is protected using the “deny all” rule. + +* While using Struts framework, ensure that JSP files are not accessible directly + by denying access to `.jsp` files in `web.xml`. + +* Maintain a clean environment. Remove files that contain source code but are not used by the application. + Remove unused dependencies, unnecessary features, components, files, and documentation. + +* Ensure production environment does not contain any source code / development tools + and that the production environment contains only compiled code / executables. + +* Remove test code / debug code (that might contain backdoors). + Commented code can also be removed as at times it might contain sensitive data. + Remove file metadata (e.g. `.git`) + +* Set “Deny All” in security constraints (for the roles being set up) + while setting up the application on the web server. + +* The listing of HTTP methods in security constraints works in a similar way to deny-listing. + Any verb not explicitly listed is allowed for execution. + Hence use “Deny All” and then allow the methods for the required roles. + This setting is particularly important using “Anonymous User” role. + For example, in Java, remove all `` elements from `web.xml` files. + +* Prevent disclosure of your directory structure in the robots.txt file + by placing directories not intended for public indexing into an isolated parent directory. + Then ""Disallow"" that entire parent directory in the robots.txt file + rather than disallowing each individual directory + +* Configure web and application server to disallow HEAD requests entirely. + +* Comments on code and Meta tags pertaining to the IDE used or technology used to develop the application + should be removed. + +* Some comments can divulge important information regarding bugs in code or pointers to functionality. + This is particularly important with server side code such as JSP and ASP files. + +* Search for any calls to the underlying operating system or file open calls and examine the error possibilities. + +* Only obtain components from official sources over secure links. + Prefer signed packages to reduce the chance of including a modified, malicious component + +* Monitor for libraries and components that are unmaintained or do not create security patches for older versions. + If patching is not possible, consider deploying a virtual patch to monitor, detect, + or protect against the discovered issue. + +* Remove backup or old files that are not in use + +* Change/disable all default account passwords + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue140202] or [edit on GitHub][edit140202]. + +[edit140202]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/02-verification-dos-donts/02-system-hardening.md +[issue140202]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2014-appendices/02-verification-dos-donts/02-system-hardening diff --git a/release-ja/14-appendices/02-verification-dos-donts/03-open-source-software.md b/release-ja/14-appendices/02-verification-dos-donts/03-open-source-software.md new file mode 100644 index 00000000..74e2fdea --- /dev/null +++ b/release-ja/14-appendices/02-verification-dos-donts/03-open-source-software.md @@ -0,0 +1,117 @@ +--- + +title: Open Source Software +layout: col-document +tags: OWASP Developer Guide +contributors: Shruti Kulkarni +document: OWASP Developer Guide +order: 14230 +permalink: /release/appendices/verification_dos_donts/open_source_software/ + +--- + +{% include breadcrumb.html %} + +### 12.2.3 Open Source software + +Here is a collection of Do's and Don'ts when it comes to Open Source software, gathered from practical experiences. +Some of these are language specific and others have more general applicability. + +* Static Code Analysis (for licensing and dependencies) + * Consuming open source software has a heavy dependency on the license + under which the open source software is available. + * Following are some URLs to licensing details: + * `https://choosealicense.com/licenses/` + * `https://tldrlegal.com/` + * `https://creativecommons.org/licenses/by/4.0/` + +It is important for the organization to have a policy statement for consumption of open source software. +From a licensing perspective and the implication of using a open source software incorrectly, +maintain a procedure for approval of usage of selected open source software. +This could be in the form of a workflow or obtaining security approvals for the chosen open source software +We realize it could be challenging, but if feasible, maintain a list of approved open source software + +* Address vulnerabilities with: Binaries / pre-compiled code / packages + where source code sharing is not a part of the license (Examples executables / NuGets) + * Where possible use version pinning + * Where possible use integrity verification + * Check for vulnerabilities for the selected binaries in vulnerability disclosure databases like + * CVE database (`https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bouncy+castle`) + * VulnDB (`https://vuldb.com/?id.173918`) + * If within the budget of your organization, use an SCA tool to scan for vulnerabilities + * Always vet and perform due-diligence on third-party modules that you install + in order to confirm their health and credibility. + * Hold-off on upgrading immediately to new versions; allow new package versions some time to circulate + before trying them out. + * Before upgrading, make sure to review change log and release notes for the upgraded version. + * When installing packages make sure to add the --ignore-scripts suffix to disable the execution + of any scripts by third-party packages. + * Consider adding ignore-scripts to your `.npmrc` project file, or to your global npm configuration. + * If you use npm, run `npm outdated`, to see which packages are out of date + * Typosquatting is an attack that relies on mistakes made by users, such as typos. + With typosquatting, bad actors could publish malicious modules to the npm registry with names + that look much like existing popular modules.To address this vulnerability verify your packages + before consuming them + +* Address vulnerabilities with: where source code sharing is a part of the license + * GitHub CodeQL / third party tool + * If within the budget of your organization, use an SCA tool to scan for vulnerabilities + +* Security Testing: Binaries / pre-compiled code / packages + where source code sharing is not a part of the license (Examples executables / NuGets) + * Perform Dynamic application analysis + * Perform Pen testing + * Verify which tokens are created for your user or revoke tokens in cases of emergency; + use npm token list or npm token revoke respectively. + +* Security Testing: where source code sharing is a part of the license + * Perform Static code analysis + * Perform Dynamic application analysis + * Perform Pen testing. + +* Third Party Software and Libraries (hive off to OWASP Dependency Tracker) + * Address supply chain risk with: Binaries / pre-compiled code / packages + where source code sharing is not a part of the license (Examples executables / NuGets) + * Use signed binaries / packages + * Reference private feed in your code + * Use controlled scopes + * Lock files + * Avoid publishing secrets to the npm registry (secrets may end up leaking into source control + or even a published package on the public npm registry) + +* Address supply chain risk with: where source code sharing is a part of the license + * [GitHub]Check for dependency graph + * [GitHub]Dependabot alerts + * [GitHub]Commit and tag signatures + +* Monitor Dependencies: Binaries / pre-compiled code / packages + where source code sharing is not a part of the license (Examples executables / NuGets) + * Use dependency graphs + * Enable repeatable package restores using lock files + +* Monitor Dependencies: where source code sharing is a part of the license + * [GitHub]Check for dependency graph + * [GitHub] Secret scanning + +* Maintaining open source software/components: Binaries / pre-compiled code / packages + where source code sharing is not a part of the license + * Monitor for deprecated packages + * Use dependency graphs + * Lock files + * Monitor vulnerabilities with: + * Check for vulnerabilities for the selected binaries in vulnerability disclosure databases like + * CVE database (`https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bouncy+castle`) + * VulnDB (`https://vuldb.com/?id.173918`) + * If within the budget of your organization, use an SCA tool to scan for vulnerabilities + +* Copying source code off public domain (internet) + For example source code that is on a blog or in discussion forums like stacktrace or snippets of example on writeups + *******Don’t do it!!!******* + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue140203] or [edit on GitHub][edit140203]. + +[edit140203]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/02-verification-dos-donts/03-open-source-software.md +[issue140203]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2014-appendices/02-verification-dos-donts/03-open-source-software diff --git a/release-ja/14-appendices/02-verification-dos-donts/info.md b/release-ja/14-appendices/02-verification-dos-donts/info.md new file mode 100644 index 00000000..16409f12 --- /dev/null +++ b/release-ja/14-appendices/02-verification-dos-donts/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="draft" %} diff --git a/release-ja/14-appendices/02-verification-dos-donts/toc.md b/release-ja/14-appendices/02-verification-dos-donts/toc.md new file mode 100644 index 00000000..ecf9bb56 --- /dev/null +++ b/release-ja/14-appendices/02-verification-dos-donts/toc.md @@ -0,0 +1,48 @@ +--- + +title: Verification Do's and Don'ts +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 14200 +permalink: /release/appendices/verification_dos_donts/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){: .image-right } + +## 12.2 Verification Do's and Don'ts + +[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm]. + +Verification takes skill and experience, so it is important to build on the existing knowledge +contained in these Do's and Dont's. + +Sections: + +12.2.1 [Secure environment](01-secure-environment.md) +12.2.2 [System hardening](02-system-hardening.md) +12.2.3 [Open Source software](03-open-source-software.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1402] or [edit on GitHub][edit1402]. + +[edit1402]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/02-verification-dos-donts/toc.md +[issue1402]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2014-appendices/02-verification-dos-donts/00-toc +[samm]: https://owaspsamm.org/about/ +[sammv]: https://owaspsamm.org/model/verification/ diff --git a/release-ja/14-appendices/info.md b/release-ja/14-appendices/info.md new file mode 100644 index 00000000..16409f12 --- /dev/null +++ b/release-ja/14-appendices/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="draft" %} diff --git a/release-ja/14-appendices/toc.md b/release-ja/14-appendices/toc.md new file mode 100644 index 00000000..82559349 --- /dev/null +++ b/release-ja/14-appendices/toc.md @@ -0,0 +1,49 @@ +--- + +title: Appendices +layout: col-document +tags: OWASP Developer Guide +contributors: Jon Gadsden +document: OWASP Developer Guide +order: 14000 +permalink: /release/appendices/ + +--- + +{% include breadcrumb.html %} + + + +![Developer guide logo](../../assets/images/dg_logo.png "OWASP Developer Guide"){: .image-right } + +## 12. Appendices + +12.1 [Implementation Do's and Don'ts](01-implementation-dos-donts/toc.md) +12.1.1 [Container security](01-implementation-dos-donts/01-container-security.md) +12.1.2 [Secure coding](01-implementation-dos-donts/02-secure-coding.md) +12.1.3 [Cryptographic practices](01-implementation-dos-donts/03-cryptographic-practices.md) +12.1.4 [Application spoofing](01-implementation-dos-donts/04-application-spoofing.md) +12.1.5 [Content Security Policy (CSP)](01-implementation-dos-donts/05-content-security-policy.md) +12.1.6 [Exception and error handling](01-implementation-dos-donts/06-exception-error-handling.md) +12.1.7 [File management](01-implementation-dos-donts/07-file-management.md) +12.1.8 [Memory management](01-implementation-dos-donts/08-memory-management.md) +12.2 [Verification Do's and Don'ts](02-verification-dos-donts/toc.md) +12.2.1 [Secure environment](02-verification-dos-donts/01-secure-environment.md) +12.2.2 [System hardening](02-verification-dos-donts/02-system-hardening.md) +12.2.3 [Open Source software](02-verification-dos-donts/03-open-source-software.md) + +---- + +The OWASP Developer Guide is a community effort; if there is something that needs changing +then [submit an issue][issue1400] or [edit on GitHub][edit1400]. + +[edit1400]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/14-appendices/toc.md +[issue1400]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2014-appendices/00-toc diff --git a/release-ja/info.md b/release-ja/info.md new file mode 100644 index 00000000..70cd9b10 --- /dev/null +++ b/release-ja/info.md @@ -0,0 +1 @@ +{% include navigation.html collection="release" %} diff --git a/release-ja/title.pdf.yaml b/release-ja/title.pdf.yaml new file mode 100644 index 00000000..84bc50f0 --- /dev/null +++ b/release-ja/title.pdf.yaml @@ -0,0 +1,17 @@ +--- +lang: ja +title: Developer Guide +author: Open Worldwide Application Security Project (OWASP) +version: Japanese translation +date: February 2023 onwards +rights: Creative Commons Attribution ShareAlike 4.0 International (CC BY-SA 4.0) +geometry: "left=3cm,right=2.5cm,top=2cm,bottom=2cm" +header-includes: | + \usepackage{fancyhdr} + \pagestyle{fancy} + \fancyhead{} + \fancyhead[RE,RO]{February 2023 onwards} + \fancyfoot{} + \fancyfoot[LE,LO]{Draft version} + \fancyfoot[RE,RO]{\thepage} +... diff --git a/release-ja/title.yaml b/release-ja/title.yaml new file mode 100644 index 00000000..73aad49f --- /dev/null +++ b/release-ja/title.yaml @@ -0,0 +1,12 @@ +--- +lang: ja +title: +- type: main + text: Developer Guide +creator: +- role: author + text: Open Worldwide Application Security Project (OWASP) +version: Japanese translation +date: February 2023 onwards +rights: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) +... diff --git a/release-ja/toc.md b/release-ja/toc.md new file mode 100644 index 00000000..0b489cb9 --- /dev/null +++ b/release-ja/toc.md @@ -0,0 +1,146 @@ +--- + +title: Table of Contents +layout: col-document +tags: OWASP Developer Guide +contributors: +document: OWASP Developer Guide +order: 2000 +permalink: /release/ + +--- + +{% include breadcrumb.html %} + +![Developer guide logo](../assets/images/dg_logo.png "OWASP Developer Guide"){: height="180px" } + +### OWASP Developer Guide + +#### A Guide to Building Secure Web Applications and Web Services + +### Release version 4.1.7 + +1 **[Introduction](03-introduction.md)** + +2 **[Foundations](04-foundations/toc.md)** +2.1 [Security fundamentals](04-foundations/01-security-fundamentals.md) +2.2 [Secure development and integration](04-foundations/02-secure-development.md) +2.3 [Principles of security](04-foundations/03-security-principles.md) +2.4 [Principles of cryptography](04-foundations/04-crypto-principles.md) +2.5 [OWASP Top 10](04-foundations/05-top-ten.md) + +3 **[Requirements](05-requirements/toc.md)** +3.1 [Requirements in practice](05-requirements/01-requirements.md) +3.2 [Risk profile](05-requirements/02-risk.md) +3.3 [OpenCRE](05-requirements/03-opencre.md) +3.4 [SecurityRAT](05-requirements/04-security-rat.md) +3.5 [ASVS requirements](05-requirements/05-asvs.md) +3.6 [MAS requirements](05-requirements/06-mas.md) +3.7 [SKF requirements](05-requirements/07-skf.md) + +4 **[Design](06-design/toc.md)** +4.1 [Threat modeling](06-design/01-threat-modeling/toc.md) +4.1.1 [Threat modeling in practice](06-design/01-threat-modeling/01-threat-modeling.md) +4.1.2 [pytm](06-design/01-threat-modeling/02-pytm.md) +4.1.3 [Threat Dragon](06-design/01-threat-modeling/03-threat-dragon.md) +4.1.4 [Cornucopia](06-design/01-threat-modeling/04-cornucopia.md) +4.1.5 [LINDDUN GO](06-design/01-threat-modeling/05-linddun-go.md) +4.1.6 [Threat Modeling toolkit](06-design/01-threat-modeling/06-toolkit.md) +4.2 [Web application checklist](06-design/02-web-app-checklist/toc.md) +4.2.1 [Checklist: Define Security Requirements](06-design/02-web-app-checklist/01-define-security-requirements.md) +4.2.2 [Checklist: Leverage Security Frameworks and Libraries](06-design/02-web-app-checklist/02-frameworks-libraries.md) +4.2.3 [Checklist: Secure Database Access](06-design/02-web-app-checklist/03-secure-database-access.md) +4.2.4 [Checklist: Encode and Escape Data](06-design/02-web-app-checklist/04-encode-escape-data.md) +4.2.5 [Checklist: Validate All Inputs](06-design/02-web-app-checklist/05-validate-inputs.md) +4.2.6 [Checklist: Implement Digital Identity](06-design/02-web-app-checklist/06-digital-identity.md) +4.2.7 [Checklist: Enforce Access Controls](06-design/02-web-app-checklist/07-access-controls.md) +4.2.8 [Checklist: Protect Data Everywhere](06-design/02-web-app-checklist/08-protect-data.md) +4.2.9 [Checklist: Implement Security Logging and Monitoring](06-design/02-web-app-checklist/09-logging-monitoring.md) +4.2.10 [Checklist: Handle all Errors and Exceptions](06-design/02-web-app-checklist/10-handle-errors-exceptions.md) +4.3 [MAS checklist](06-design/03-mas-checklist.md) + +5 **[Implementation](07-implementation/toc.md)** +5.1 [Documentation](07-implementation/01-documentation/toc.md) +5.1.1 [Top 10 Proactive Controls](07-implementation/01-documentation/01-proactive-controls.md) +5.1.2 [Go Secure Coding Practices](07-implementation/01-documentation/02-go-scp.md) +5.1.3 [Cheatsheet Series](07-implementation/01-documentation/03-cheatsheets.md) +5.2 [Dependencies](07-implementation/02-dependencies/toc.md) +5.2.1 [Dependency-Check](07-implementation/02-dependencies/01-dependency-check.md) +5.2.2 [Dependency-Track](07-implementation/02-dependencies/02-dependency-track.md) +5.2.3 [CycloneDX](07-implementation/02-dependencies/03-cyclonedx.md) +5.3 [Secure Libraries](07-implementation/03-secure-libraries/toc.md) +5.3.1 [ESAPI](07-implementation/03-secure-libraries/01-esapi.md) +5.3.2 [CSRFGuard](07-implementation/03-secure-libraries/02-csrf-guard.md) +5.3.3 [OSHP](07-implementation/03-secure-libraries/03-secure-headers.md) +5.4 [MASWE](07-implementation/04-maswe.md) + +6 **[Verification](08-verification/toc.md)** +6.1 [Guides](08-verification/01-guides/toc.md) +6.1.1 [WSTG](08-verification/01-guides/01-wstg.md) +6.1.2 [MASTG](08-verification/01-guides/02-mastg.md) +6.1.3 [ASVS](08-verification/01-guides/03-asvs.md) +6.2 [Tools](08-verification/02-tools/toc.md) +6.2.1 [DAST tools](08-verification/02-tools/01-dast.md) +6.2.2 [Amass](08-verification/02-tools/02-amass.md) +6.2.3 [OWTF](08-verification/02-tools/03-owtf.md) +6.2.4 [Nettacker](08-verification/02-tools/04-nettacker.md) +6.2.5 [OSHP verification](08-verification/02-tools/05-secure-headers.md) +6.3 [Frameworks](08-verification/03-frameworks/toc.md) +6.3.1 [secureCodeBox](08-verification/03-frameworks/01-secure-codebox.md) +6.4 [Vulnerability management](08-verification/04-vulnerability-management/toc.md) +6.4.1 [DefectDojo](08-verification/04-vulnerability-management/01-defectdojo.md) + +7 **[Training and Education](09-training-education/toc.md)** +7.1 [Vulnerable Applications](09-training-education/01-vulnerable-apps/toc.md) +7.1.1 [Juice Shop](09-training-education/01-vulnerable-apps/01-juice-shop.md) +7.1.2 [WebGoat](09-training-education/01-vulnerable-apps/02-webgoat.md) +7.1.3 [PyGoat](09-training-education/01-vulnerable-apps/03-pygoat.md) +7.1.4 [Security Shepherd](09-training-education/01-vulnerable-apps/04-security-shepherd.md) +7.2 [Secure Coding Dojo](09-training-education/02-secure-coding-dojo.md) +7.3 [SKF education](09-training-education/03-skf.md) +7.4 [SamuraiWTF](09-training-education/04-samurai-wtf.md) +7.5 [OWASP Top 10 project](09-training-education/05-top-ten.md) +7.6 [Mobile Top 10](09-training-education/06-mobile-top-ten.md) +7.7 [API Top 10](09-training-education/07-api-top-ten.md) +7.8 [WrongSecrets](09-training-education/08-wrongsecrets.md) +7.9 [OWASP Snakes and Ladders](09-training-education/09-snakes-ladders.md) + +8 **[Culture building and Process maturing](10-culture-process/toc.md)** +8.1 [Security Culture](10-culture-process/01-security-culture.md) +8.2 [Security Champions](10-culture-process/02-security-champions/toc.md) +8.2.1 [Security champions program](10-culture-process/02-security-champions/01-security-champions-program.md) +8.2.2 [Security Champions Guide](10-culture-process/02-security-champions/02-security-champions-guide.md) +8.2.3 [Security Champions Playbook](10-culture-process/02-security-champions/03-security-champions-playbook.md) +8.3 [SAMM](10-culture-process/03-samm.md) +8.4 [ASVS process](10-culture-process/04-asvs.md) +8.5 [MAS process](10-culture-process/05-mas.md) + +9 **[Operations](11-operations/toc.md)** +9.1 [DevSecOps Guideline](11-operations/01-devsecops.md) +9.2 [Coraza WAF](11-operations/02-coraza.md) +9.3 [ModSecurity WAF](11-operations/03-modsecurity.md) +9.4 [OWASP CRS](11-operations/04-crs.md) + +10 **[Metrics](12-metrics/toc.md)** + +11 **[Security gap analysis](13-security-gap-analysis/01-guides/toc.md)** +11.1 [Guides](13-security-gap-analysis/01-guides/toc.md) +11.1.1 [SAMM gap analysis](13-security-gap-analysis/01-guides/01-samm.md) +11.1.2 [ASVS gap analysis](13-security-gap-analysis/01-guides/02-asvs.md) +11.1.3 [MAS gap analysis](13-security-gap-analysis/01-guides/03-mas.md) +11.2 [BLT](13-security-gap-analysis/02-blt.md) + +12 **[Appendices](14-appendices/toc.md)** +12.1 [Implementation Do's and Don'ts](14-appendices/01-implementation-dos-donts/toc.md) +12.1.1 [Container security](14-appendices/01-implementation-dos-donts/01-container-security.md) +12.1.2 [Secure coding](14-appendices/01-implementation-dos-donts/02-secure-coding.md) +12.1.3 [Cryptographic practices](14-appendices/01-implementation-dos-donts/03-cryptographic-practices.md) +12.1.4 [Application spoofing](14-appendices/01-implementation-dos-donts/04-application-spoofing.md) +12.1.5 [Content Security Policy (CSP)](14-appendices/01-implementation-dos-donts/05-content-security-policy.md) +12.1.6 [Exception and error handling](14-appendices/01-implementation-dos-donts/06-exception-error-handling.md) +12.1.7 [File management](14-appendices/01-implementation-dos-donts/07-file-management.md) +12.1.8 [Memory management](14-appendices/01-implementation-dos-donts/08-memory-management.md) +12.2 [Verification Do's and Don'ts](14-appendices/02-verification-dos-donts/toc.md) +12.2.1 [Secure environment](14-appendices/02-verification-dos-donts/01-secure-environment.md) +12.2.2 [System hardening](14-appendices/02-verification-dos-donts/02-system-hardening.md) +12.2.3 [Open Source software](14-appendices/02-verification-dos-donts/03-open-source-software.md)