├── .github
├── dependabot.yaml
├── issue_template
│ ├── guide.md
│ └── request.md
├── pull_request_template.md
└── workflows
│ ├── ci.yaml
│ └── housekeeping.yaml
├── .gitignore
├── .lycheeignore
├── 404.html
├── Gemfile
├── README.md
├── _config.yml
├── _data
├── draft-en.yaml
├── stable-en.yaml
└── stable-es.yaml
├── _includes
├── banner.html
├── breadcrumb.html
└── navigation.html
├── assets
├── docs
│ ├── OWASP_SCP_Quick_Reference_Guide_v21.doc
│ └── OWASP_SCP_Quick_Reference_Guide_v21.pdf
└── images
│ └── by-sa.svg
├── code_of_conduct.md
├── contributing.md
├── draft-en
├── 01-introduction
│ ├── 05-introduction.md
│ └── info.md
├── 02-checklist
│ ├── 05-checklist.md
│ ├── index.md
│ └── info.md
├── 03-appendices
│ ├── 03-overview.md
│ ├── 05-glossary.md
│ ├── 07-references.md
│ ├── index.md
│ └── info.md
├── index.md
├── info.md
├── title.pdf.yaml
└── title.yaml
├── index.md
├── info.md
├── leaders.md
├── license.txt
├── security.md
├── stable-en
├── 01-introduction
│ ├── 05-introduction.md
│ └── info.md
├── 02-checklist
│ ├── 05-checklist.md
│ ├── index.md
│ └── info.md
├── 03-appendices
│ ├── 03-overview.md
│ ├── 05-glossary.md
│ ├── 07-references.md
│ ├── index.md
│ └── info.md
├── index.md
├── info.md
├── title.pdf.yaml
└── title.yaml
├── stable-es
├── 01-introduction
│ ├── 05-introduction.md
│ └── info.md
├── 02-checklist
│ ├── 05-checklist.md
│ ├── index.md
│ └── info.md
├── 03-appendices
│ ├── 03-overview.md
│ ├── 05-glossary.md
│ ├── 07-references.md
│ ├── index.md
│ └── info.md
├── index.md
├── info.md
├── title.pdf.yaml
└── title.yaml
├── stable-fa
├── 01-introduction
│ ├── 05-introduction.md
│ └── info.md
├── 02-checklist
│ ├── 05-checklist.md
│ ├── index.md
│ └── info.md
├── 03-appendices
│ ├── 03-overview.md
│ ├── 05-glossary.md
│ ├── 07-references.md
│ ├── index.md
│ └── info.md
├── index.md
├── info.md
├── title.pdf.yaml
└── title.yaml
├── tab_archive.md
├── tab_contributors.md
└── tab_download.md
/.github/dependabot.yaml:
--------------------------------------------------------------------------------
1 | version: 2
2 | updates:
3 | - package-ecosystem: "github-actions"
4 | directory: ".github/workflows"
5 | schedule:
6 | interval: "monthly"
7 | # Disable version updates
8 | open-pull-requests-limit: 0
9 | ignore:
10 | # ignore all (non-security) patch updates
11 | - dependency-name: "*"
12 | update-types: ["version-update:semver-patch"]
13 |
--------------------------------------------------------------------------------
/.github/issue_template/guide.md:
--------------------------------------------------------------------------------
1 | ---
2 | name: Change request
3 | about: Contribute to the SCP guide
4 | title: 'Change the guide'
5 | labels: 'documentation'
6 | assignees: ''
7 |
8 | ---
9 |
10 | **Suggest a contribution to the guide**
11 |
12 |
13 | **Section / language**
14 |
15 |
--------------------------------------------------------------------------------
/.github/issue_template/request.md:
--------------------------------------------------------------------------------
1 | ---
2 | name: Change request
3 | about: Suggest a change to the project pages
4 | title: 'Change the project pages'
5 | labels: 'pages'
6 | assignees: ''
7 |
8 | ---
9 |
10 | **Describe what change you would like**
11 |
12 |
13 | **Context**
14 |
15 |
--------------------------------------------------------------------------------
/.github/pull_request_template.md:
--------------------------------------------------------------------------------
1 | **Summary**:
2 | Provide a summary for the reviewers of this pull request, stating the language and section will help as well.
3 | Please provide enough information so that others can review your pull request
4 |
5 | **Description for the changelog**:
6 | A short (one line) summary that describes the changes in this pull request for inclusion in the change log
7 |
8 | **Other info**:
9 | Thanks for submitting a pull request! Please make sure you follow our code_of_conduct.md
10 |
11 | If this closes an existing issue then add "closes #xxxx", where xxxx is the issue number
12 |
--------------------------------------------------------------------------------
/.github/workflows/ci.yaml:
--------------------------------------------------------------------------------
1 | name: CI pipeline
2 | on:
3 | push:
4 | branches:
5 | - main
6 | pull_request:
7 | branches:
8 | - main
9 | workflow_dispatch:
10 |
11 | # for security reasons the github actions are pinned to specific release versions
12 | jobs:
13 | link_checker:
14 | name: Link checker
15 | runs-on: ubuntu-22.04
16 | steps:
17 | - name: Checkout markdown
18 | uses: actions/checkout@v4.0.0
19 |
20 | - name: Link Checker
21 | uses: lycheeverse/lychee-action@v1.8.0
22 | with:
23 | # skip the archive file as it is full of broken links
24 | args: --verbose --no-progress --exclude-path './tab_archive.md' '**/*.md' '*.md'
25 | fail: true
26 | env:
27 | GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
28 |
29 | en_draft:
30 | name: Export epub and pdf (EN draft)
31 | runs-on: ubuntu-22.04
32 | needs: [link_checker]
33 | steps:
34 | - name: Checkout markdown
35 | uses: actions/checkout@v4.0.0
36 |
37 | - name: Combine markdown
38 | run: |
39 | tail --lines=+11 --quiet \
40 | draft-en/01-introduction/*.md \
41 | draft-en/02-checklist/*.md \
42 | draft-en/03-appendices/*.md > draft-en.markdown
43 | mkdir -p publish
44 |
45 | - name: Export to pdf
46 | uses: docker://pandoc/latex:3.1
47 | with:
48 | args: >-
49 | --output=publish/OWASP_SCP_Quick_Reference_Guide.draft.pdf
50 | draft-en/title.pdf.yaml
51 | draft-en.markdown
52 |
53 | - name: Export to epub
54 | uses: docker://pandoc/latex:3.1
55 | with:
56 | args: >-
57 | --output=publish/OWASP_SCP_Quick_Reference_Guide.draft.epub
58 | draft-en/title.yaml
59 | draft-en.markdown
60 |
61 | - name: Save pdfs and epubs
62 | uses: actions/upload-artifact@v3.1.2
63 | with:
64 | name: en-draft
65 | path: publish
66 |
67 | en_stable:
68 | name: Export epub and pdf (EN stable)
69 | runs-on: ubuntu-22.04
70 | needs: [link_checker]
71 | steps:
72 | - name: Checkout markdown
73 | uses: actions/checkout@v4.0.0
74 |
75 | - name: Combine markdown
76 | run: |
77 | tail --lines=+11 --quiet \
78 | stable-en/01-introduction/*.md \
79 | stable-en/02-checklist/*.md \
80 | stable-en/03-appendices/*.md > stable-en.markdown
81 | mkdir -p publish
82 |
83 | - name: Export to pdf
84 | uses: docker://pandoc/latex:3.1
85 | with:
86 | args: >-
87 | --output=publish/OWASP_SCP_Quick_Reference_Guide.en-US.pdf
88 | stable-en/title.pdf.yaml
89 | stable-en.markdown
90 |
91 | - name: Export to epub
92 | uses: docker://pandoc/latex:3.1
93 | with:
94 | args: >-
95 | --output=publish/OWASP_SCP_Quick_Reference_Guide.en-US.epub
96 | stable-en/title.yaml
97 | stable-en.markdown
98 |
99 | - name: Save pdfs and epubs
100 | uses: actions/upload-artifact@v3.1.2
101 | with:
102 | name: en-stable
103 | path: publish
104 |
105 | es_stable:
106 | name: Export epub and pdf (ES stable)
107 | runs-on: ubuntu-22.04
108 | needs: [link_checker]
109 | steps:
110 | - name: Checkout markdown
111 | uses: actions/checkout@v4.0.0
112 |
113 | - name: Combine markdown
114 | run: |
115 | tail --lines=+11 --quiet \
116 | stable-es/01-introduction/*.md \
117 | stable-es/02-checklist/*.md \
118 | stable-es/03-appendices/*.md > stable-es.markdown
119 | mkdir -p publish
120 |
121 | - name: Export to pdf
122 | uses: docker://pandoc/latex:3.1
123 | with:
124 | args: >-
125 | --output=publish/OWASP_SCP_Quick_Reference_Guide.es-UY.pdf
126 | stable-es/title.pdf.yaml
127 | stable-es.markdown
128 |
129 | - name: Export to epub
130 | uses: docker://pandoc/latex:3.1
131 | with:
132 | args: >-
133 | --output=publish/OWASP_SCP_Quick_Reference_Guide.es-UY.epub
134 | stable-es/title.yaml
135 | stable-es.markdown
136 |
137 | - name: Save pdfs and epubs
138 | uses: actions/upload-artifact@v3.1.2
139 | with:
140 | name: es-stable
141 | path: publish
--------------------------------------------------------------------------------
/.github/workflows/housekeeping.yaml:
--------------------------------------------------------------------------------
1 | name: Housekeeping
2 | on:
3 | # Run daily at 7:00
4 | schedule:
5 | - cron: '0 7 * * *'
6 | workflow_dispatch:
7 |
8 | # for security reasons the github actions are pinned to specific release versions
9 | jobs:
10 | chores:
11 | name: Tidy workflows
12 | runs-on: ubuntu-22.04
13 |
14 | steps:
15 | - name: Delete stale workflow runs
16 | uses: Mattraks/delete-workflow-runs@v2.0.4
17 | with:
18 | token: ${{ github.token }}
19 | repository: ${{ github.repository }}
20 | retain_days: 28
21 | keep_minimum_runs: 10
22 |
23 | - name: Delete unused workflows
24 | uses: otto-de/purge-deprecated-workflow-runs@v1.4.0
25 | with:
26 | token: ${{ github.token }}
27 |
28 | link_checker:
29 | name: Link checker
30 | runs-on: ubuntu-22.04
31 |
32 | steps:
33 | - name: Checkout markdown
34 | uses: actions/checkout@v4.0.0
35 |
36 | - name: Link Checker
37 | uses: lycheeverse/lychee-action@v1.8.0
38 | with:
39 | # skip the archive file as it is full of broken links
40 | args: --verbose --no-progress --exclude-path './tab_archive.md' '*.md' '**/*.md'
41 | fail: true
42 | env:
43 | GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
44 |
--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | # uses allow-list, so initially ignore everything
2 | *
3 |
4 | # allow github, workflows and templates
5 | !.github/
6 | !.github/workflows/
7 | !.github/workflows/*.yaml
8 | !.github/issue_template/
9 | !.github/issue_template/*.md
10 | !.gitignore
11 | !.lycheeignore
12 |
13 | # allow markdown and the assets
14 | !*.md
15 | !license.txt
16 | !assets/
17 | !assets/images/
18 | !assets/images/*.svg
19 | !assets/docs/
20 | !assets/docs/*.doc
21 | !assets/docs/*.pdf
22 |
23 | # allow the stable area
24 | !stable/
25 | !stable-en/
26 | !stable-en/title*.yaml
27 | !stable-en/.*.md
28 | !stable-en/01-introduction/
29 | !stable-en/01-introduction/*.md
30 | !stable-en/02-checklist/
31 | !stable-en/02-checklist/*.md
32 | !stable-en/03-appendices/
33 | !stable-en/03-appendices/*.md
34 | !stable-es/
35 | !stable-es/title*.yaml
36 | !stable-es/.*.md
37 | !stable-es/01-introduction/
38 | !stable-es/01-introduction/*.md
39 | !stable-es/02-checklist/
40 | !stable-es/02-checklist/*.md
41 | !stable-es/03-appendices/
42 | !stable-es/03-appendices/*.md
43 | !stable-fa/
44 | !stable-fa/title*.yaml
45 | !stable-fa/.*.md
46 | !stable-fa/01-introduction/
47 | !stable-fa/01-introduction/*.md
48 | !stable-fa/02-checklist/
49 | !stable-fa/02-checklist/*.md
50 | !stable-fa/03-appendices/
51 | !stable-fa/03-appendices/*.md
52 |
53 | # allow the draft area
54 | !draft-en/
55 | !draft-en/title*.yaml
56 | !draft-en/.*.md
57 | !draft-en/01-introduction/
58 | !draft-en/01-introduction/*.md
59 | !draft-en/02-checklist/
60 | !draft-en/02-checklist/*.md
61 | !draft-en/03-appendices/
62 | !draft-en/03-appendices/*.md
63 |
64 | # allow jekyll build files
65 | !404.html
66 | !Gemfile
67 | !_config.yml
68 | !_data/
69 | !_data/*.yaml
70 | !_includes/
71 | !_includes/*.html
72 |
73 |
--------------------------------------------------------------------------------
/.lycheeignore:
--------------------------------------------------------------------------------
1 | # ignore these falae positives from the link checker housekeeper
2 |
3 | # these are known broken links that we preserve in the archive
4 | www.owasp.org/images/6/64/SCP-QRG_Revisions_History.xls
5 | www.owasp.org/images/b/ba/Web_Application_Development_Dos_and_Donts.ppt
6 |
7 | # the jekyll scripts sometimes upset lychee:
8 | _includes/breadcrumb.html
9 | _includes/navigation.html
10 |
11 |
--------------------------------------------------------------------------------
/404.html:
--------------------------------------------------------------------------------
1 | ---
2 |
3 | title: 404 - Not Found
4 | layout: col-generic
5 |
6 | ---
7 |
8 |
9 |
10 |
WHOA THAT PAGE CANNOT BE FOUND
11 |
Try the SEARCH function in the main navigation to find something. If you are looking for chapter information, please see Chapters for the correct chapter. For information about OWASP projects see Projects . For common attacks, vulnerabilities, or information about other community-led contributions see Contributed Content .
12 |
13 |
14 |
If all else fails you can search our historical site .
15 |
2 | {% if page.url contains "/draft/" %}
3 |
4 | This content represents the latest contributions to the Secure Coding Practice Quick-reference Guide, and may frequently change
5 |
6 | {% endif %}
7 |
8 | {% if page.url contains "/stable/" or page.url contains site.stable_version %}
9 |
10 | You're viewing the current stable version of the Secure Coding Practice Quick-reference Guide project
11 |
12 | {% endif %}
13 |
2 |
Home
3 | {%- capture page_url_without_index_html -%}{{ page.url | remove: "/index.html" }}{%- endcapture -%}
4 | {%- assign split_url_parts = page_url_without_index_html | split: '/' -%}
5 | {%- capture forLoopMaxInt -%}{{ split_url_parts.size | minus:1 }}{%- endcapture -%}
6 | {%- for i in (1..forLoopMaxInt) -%}
7 | {%- capture current_breadcrumb_url -%}{{next_prepender}}/{{ split_url_parts[i] }}/index.html{%- endcapture -%}
8 | {%- capture current_breadcrumb_md_url -%}{{next_prepender}}/{{ split_url_parts[i] }}/{%- endcapture -%}
9 | {%- capture next_prepender -%}{{next_prepender}}/{{ split_url_parts[i] }}{%- endcapture -%}
10 | {%- for breadcrumb_page in site.pages -%}
11 | {%- if current_breadcrumb_url == breadcrumb_page.url or current_breadcrumb_md_url == breadcrumb_page.url -%}
12 | {%- capture breadcrumb_page_page_url_without_index_html -%}{{ breadcrumb_page.url | remove: "index.html" }}{%- endcapture -%}
13 | >
14 | {%- if i == 1 -%}
15 | {{split_url_parts[i] | capitalize }}
16 | {%- else -%}
17 | {{split_url_parts[i] | replace: "_", " "}}
18 | {%- endif -%}
19 |
20 | {%- endif -%}
21 | {%- endfor -%}
22 | {%- endfor -%}
23 |
19 |
45 |
46 |
48 | image/svg+xml
49 |
52 |
53 |
54 |
58 |
64 |
73 |
74 |
87 |
92 |
93 |
94 |
95 |
102 |
113 |
114 |
117 |
128 |
129 |
132 |
133 |
146 |
155 |
156 |
157 |
158 |
160 |
173 |
188 |
189 |
196 |
197 |
198 |
199 |
200 |
--------------------------------------------------------------------------------
/code_of_conduct.md:
--------------------------------------------------------------------------------
1 | # Contributor Covenant Code of Conduct
2 |
3 | ## Our Pledge
4 |
5 | We as members, contributors, and leaders pledge to make participation in our
6 | community a harassment-free experience for everyone, regardless of age, body
7 | size, visible or invisible disability, ethnicity, sex characteristics, gender
8 | identity and expression, level of experience, education, socio-economic status,
9 | nationality, personal appearance, race, caste, color, religion, or sexual identity
10 | and orientation.
11 |
12 | We pledge to act and interact in ways that contribute to an open, welcoming,
13 | diverse, inclusive, and healthy community.
14 |
15 | ## Our Standards
16 |
17 | Examples of behavior that contributes to a positive environment for our
18 | community include:
19 |
20 | * Demonstrating empathy and kindness toward other people
21 | * Being respectful of differing opinions, viewpoints, and experiences
22 | * Giving and gracefully accepting constructive feedback
23 | * Accepting responsibility and apologizing to those affected by our mistakes,
24 | and learning from the experience
25 | * Focusing on what is best not just for us as individuals, but for the
26 | overall community
27 |
28 | Examples of unacceptable behavior include:
29 |
30 | * The use of sexualized language or imagery, and sexual attention or
31 | advances of any kind
32 | * Trolling, insulting or derogatory comments, and personal or political attacks
33 | * Public or private harassment
34 | * Publishing others' private information, such as a physical or email
35 | address, without their explicit permission
36 | * Other conduct which could reasonably be considered inappropriate in a
37 | professional setting
38 |
39 | ## Enforcement Responsibilities
40 |
41 | Community leaders are responsible for clarifying and enforcing our standards of
42 | acceptable behavior and will take appropriate and fair corrective action in
43 | response to any behavior that they deem inappropriate, threatening, offensive,
44 | or harmful.
45 |
46 | Community leaders have the right and responsibility to remove, edit, or reject
47 | comments, commits, code, wiki edits, issues, and other contributions that are
48 | not aligned to this Code of Conduct, and will communicate reasons for moderation
49 | decisions when appropriate.
50 |
51 | ## Scope
52 |
53 | This Code of Conduct applies within all community spaces, and also applies when
54 | an individual is officially representing the community in public spaces.
55 | Examples of representing our community include using an official e-mail address,
56 | posting via an official social media account, or acting as an appointed
57 | representative at an online or offline event.
58 |
59 | ## Enforcement
60 |
61 | Instances of abusive, harassing, or otherwise unacceptable behavior may be
62 | reported to the community leaders responsible for enforcement by
63 | emailing [the project team](mailto:owasp.foundation@owasp.org) at the OWASP foundation.
64 | All complaints will be reviewed and investigated promptly and fairly.
65 |
66 | All community leaders are obligated to respect the privacy and security of the
67 | reporter of any incident.
68 |
69 | ## Enforcement Guidelines
70 |
71 | Community leaders will follow these Community Impact Guidelines in determining
72 | the consequences for any action they deem in violation of this Code of Conduct:
73 |
74 | ### 1. Correction
75 |
76 | **Community Impact**: Use of inappropriate language or other behavior deemed
77 | unprofessional or unwelcome in the community.
78 |
79 | **Consequence**: A private, written warning from community leaders, providing
80 | clarity around the nature of the violation and an explanation of why the
81 | behavior was inappropriate. A public apology may be requested.
82 |
83 | ### 2. Warning
84 |
85 | **Community Impact**: A violation through a single incident or series
86 | of actions.
87 |
88 | **Consequence**: A warning with consequences for continued behavior. No
89 | interaction with the people involved, including unsolicited interaction with
90 | those enforcing the Code of Conduct, for a specified period of time. This
91 | includes avoiding interactions in community spaces as well as external channels
92 | like social media. Violating these terms may lead to a temporary or
93 | permanent ban.
94 |
95 | ### 3. Temporary Ban
96 |
97 | **Community Impact**: A serious violation of community standards, including
98 | sustained inappropriate behavior.
99 |
100 | **Consequence**: A temporary ban from any sort of interaction or public
101 | communication with the community for a specified period of time. No public or
102 | private interaction with the people involved, including unsolicited interaction
103 | with those enforcing the Code of Conduct, is allowed during this period.
104 | Violating these terms may lead to a permanent ban.
105 |
106 | ### 4. Permanent Ban
107 |
108 | **Community Impact**: Demonstrating a pattern of violation of community
109 | standards, including sustained inappropriate behavior, harassment of an
110 | individual, or aggression toward or disparagement of classes of individuals.
111 |
112 | **Consequence**: A permanent ban from any sort of public interaction within
113 | the community.
114 |
115 | ## Attribution
116 |
117 | This Code of Conduct is adapted from the [Contributor Covenant][homepage],
118 | version 2.0, available from the [contributor covenant][cofc] site.
119 |
120 | Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder][diversity].
121 |
122 | See the [FAQ][faq] for answers to common questions about this code of conduct,
123 | and translations are available of this [contributor covenant][translate].
124 |
125 | [cofc]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html
126 | [diversity]: https://github.com/mozilla/diversity
127 | [faq]: https://www.contributor-covenant.org/faq
128 | [homepage]: https://www.contributor-covenant.org
129 | [translate]: https://www.contributor-covenant.org/translations
130 |
--------------------------------------------------------------------------------
/contributing.md:
--------------------------------------------------------------------------------
1 | # Contributing to OWASP Secure Coding Practices quick reference guide
2 | This is a community project, and we are always delighted to welcome new contributors!
3 |
4 | ## When contributing
5 | * see if there is [already an issue][issues] for what you want to do
6 | * follow our [Code of Conduct](code_of_conduct.md)
7 |
8 | ## Have a change request?
9 | If you have a suggestion then [raise an issue][new],
10 | and include as much information as you can so that we can fully understand your requirements.
11 |
12 | [issues]: https://github.com/OWASP/www-project-secure-coding-practices-quick-reference-guide/issues
13 | [new]: https://github.com/OWASP/www-project-secure-coding-practices-quick-reference-guide/issues/new/
14 |
15 |
--------------------------------------------------------------------------------
/draft-en/01-introduction/05-introduction.md:
--------------------------------------------------------------------------------
1 | ---
2 |
3 | layout: col-document
4 | title: Secure Coding Practices - Draft
5 | tags: SCP-QRG
6 |
7 | ---
8 |
9 | {% include breadcrumb.html %}
10 | # Introduction
11 |
12 | This technology agnostic document defines a set of general software
13 | security coding practices, in a checklist format, that can be integrated
14 | into the software development lifecycle. Implementation of these
15 | practices will mitigate most common software vulnerabilities.
16 |
17 | Generally, it is much less expensive to build secure software than to
18 | correct security issues after the software package has been completed,
19 | not to mention the costs that may be associated with a security breach.
20 |
21 | Securing critical software resources is more important than ever as the
22 | focus of attackers has steadily moved toward the application layer. A
23 | 2009 SANS study found that attacks against web applications
24 | constitute more than 60% of the total attack attempts observed on the
25 | Internet.
26 |
27 | When utilizing this guide, development teams should start by assessing
28 | the maturity of their secure software development lifecycle and the
29 | knowledge level of their development staff. Since this guide does not
30 | cover the details of how to implement each coding practice, developers
31 | will either need to have the prior knowledge or have sufficient
32 | resources available that provide the necessary guidance. This guide
33 | provides coding practices that can be translated into coding
34 | requirements without the need for the developer to have an in depth
35 | understanding of security vulnerabilities and exploits. However, other
36 | members of the development team should have the responsibility, adequate
37 | training, tools and resources to validate that the design and
38 | implementation of the entire system is secure.
39 |
40 | A glossary of important terms in this document is provided in appendix B.
41 |
42 | Guidance on implementing a secure software development framework is
43 | beyond the scope of this paper, however the following additional general
44 | practices and resources are recommended:
45 |
46 | - Clearly define roles and responsibilities
47 |
48 | - Provide development teams with adequate software security training
49 |
50 | - Implement a secure software development lifecycle
51 |
52 | - Establish secure coding standards
53 |
54 | - [OWASP Development Guide][guide] Project
55 |
56 | - Build a re-usable object library
57 |
58 | - [OWASP Enterprise Security API][esapi] (ESAPI) Project
59 |
60 | - Verify the effectiveness of security controls
61 |
62 | - [OWASP Application Security Verification Standard][asvs] (ASVS) Project
63 |
64 | - Establish secure outsourced development practices including defining
65 | security requirements and verification methodologies in both the
66 | request for proposal (RFP) and contract.
67 |
68 |
69 | [asvs]: https://owasp.org/www-project-application-security-verification-standard/
70 | [esapi]: https://owasp.org/www-project-enterprise-security-api/
71 | [guide]: https://owasp.org/www-project-developer-guide/
72 |
73 | \newpage
74 |
--------------------------------------------------------------------------------
/draft-en/01-introduction/info.md:
--------------------------------------------------------------------------------
1 | {% include navigation.html collection="draft-en" %}
2 |
--------------------------------------------------------------------------------
/draft-en/02-checklist/05-checklist.md:
--------------------------------------------------------------------------------
1 | ---
2 |
3 | layout: col-document
4 | title: Secure Coding Practices - Draft
5 | tags: SCP-QRG
6 |
7 | ---
8 |
9 | {% include breadcrumb.html %}
10 | # Secure Coding Practices Checklist
11 |
12 | ## Input validation
13 |
14 | - [ ] Conduct all input validation on a trusted system (server side not client side)
15 |
16 | - [ ] Identify all data sources and classify them into trusted and untrusted
17 |
18 | - [ ] Validate all data from untrusted sources (databases, file streams, etc)
19 |
20 | - [ ] Use a centralized input validation routine for the whole application
21 |
22 | - [ ] Specify character sets, such as UTF-8, for all input sources
23 |
24 | - [ ] Encode input to a common character set before validating
25 |
26 | - [ ] All validation failures should result in input rejection
27 |
28 | - [ ] If the system supports UTF-8 extended character sets and validate after UTF-8 decoding is completed
29 |
30 | - [ ] Validate all client provided data before processing
31 |
32 | - [ ] Verify that protocol header values in both requests and responses contain only ASCII characters
33 |
34 | - [ ] Validate data from redirects
35 |
36 | - [ ] Validate for expected data types using an \"allow\" list rather than a \"deny\" list
37 |
38 | - [ ] Validate data range
39 |
40 | - [ ] Validate data length
41 |
42 | - [ ] If any potentially hazardous input must be allowed then implement additional controls
43 |
44 | - [ ] If the standard validation routine cannot address some inputs then use extra discrete checks
45 |
46 | - [ ] Utilize canonicalization to address obfuscation attacks
47 |
48 | ## Output encoding
49 |
50 | - [ ] Conduct all output encoding on a trusted system (server side not client side)
51 |
52 | - [ ] Utilize a standard, tested routine for each type of outbound encoding
53 |
54 | - [ ] Specify character sets, such as UTF-8, for all outputs
55 |
56 | - [ ] Contextually output encode all data returned to the client from untrusted sources
57 |
58 | - [ ] Ensure the output encoding is safe for all target systems
59 |
60 | - [ ] Contextually sanitize all output of un-trusted data to queries for SQL, XML, and LDAP
61 |
62 | - [ ] Sanitize all output of untrusted data to operating system commands
63 |
64 | ## Authentication and password management
65 |
66 | - [ ] Require authentication for all pages and resources, except those
67 | specifically intended to be public
68 |
69 | - [ ] All authentication controls must be enforced on a trusted system
70 |
71 | - [ ] Establish and utilize standard, tested, authentication services whenever possible
72 |
73 | - [ ] Use a centralized implementation for all authentication controls,
74 | including libraries that call external authentication services
75 |
76 | - [ ] Segregate authentication logic from the resource being requested and
77 | use redirection to and from the centralized authentication control
78 |
79 | - [ ] All authentication controls should fail securely
80 |
81 | - [ ] All administrative and account management functions must be at least
82 | as secure as the primary authentication mechanism
83 |
84 | - [ ] If your application manages a credential store, use cryptographically strong one-way salted hashes
85 |
86 | - [ ] Password hashing must be implemented on a trusted system server side not client side)
87 |
88 | - [ ] Validate the authentication data only on completion of all data input
89 |
90 | - [ ] Authentication failure responses should not indicate which part of the authentication data was incorrect
91 |
92 | - [ ] Utilize authentication for connections to external systems that involve sensitive information or functions
93 |
94 | - [ ] Authentication credentials for accessing services external to the
95 | application should be stored in a secure store
96 |
97 | - [ ] Use only HTTP POST requests to transmit authentication credentials
98 |
99 | - [ ] Only send non-temporary passwords over an encrypted connection or as encrypted data
100 |
101 | - [ ] Enforce password complexity requirements established by policy or regulation
102 |
103 | - [ ] Enforce password length requirements established by policy or regulation
104 |
105 | - [ ] Password entry should be obscured on the user\'s screen
106 |
107 | - [ ] Enforce account disabling after an established number of invalid login attempts
108 |
109 | - [ ] Password reset and changing operations require the same level of
110 | controls as account creation and authentication
111 |
112 | - [ ] Password reset questions should support sufficiently random answers
113 |
114 | - [ ] If using email based resets, only send email to a pre-registered
115 | address with a temporary link/password
116 |
117 | - [ ] Temporary passwords and links should have a short expiration time
118 |
119 | - [ ] Enforce the changing of temporary passwords on the next use
120 |
121 | - [ ] Notify users when a password reset occurs
122 |
123 | - [ ] Prevent password re-use
124 |
125 | - [ ] Passwords should be at least one day old before they can be changed,
126 | to prevent attacks on password re-use
127 |
128 | - [ ] Enforce password changes based on requirements established in policy
129 | or regulation, with the time between resets administratively controlled
130 |
131 | - [ ] Disable \"remember me\" functionality for password fields
132 |
133 | - [ ] The last use (successful or unsuccessful) of a user account should
134 | be reported to the user at their next successful login
135 |
136 | - [ ] Implement monitoring to identify attacks against multiple user accounts, utilizing the same password
137 |
138 | - [ ] Change all vendor-supplied default passwords and user IDs or disable the associated accounts
139 |
140 | - [ ] Re-authenticate users prior to performing critical operations
141 |
142 | - [ ] Use Multi-Factor Authentication for highly sensitive or high value transactional accounts
143 |
144 | - [ ] If using third party code for authentication, inspect the code
145 | carefully to ensure it is not affected by any malicious code
146 |
147 | ## Session management
148 |
149 | - [ ] Use the server or framework's session management controls. The
150 | application should recognize only these session identifiers as
151 | valid
152 |
153 | - [ ] Session identifier creation must always be done on a trusted system (server side not client side)
154 |
155 | - [ ] Session management controls should use well vetted algorithms that
156 | ensure sufficiently random session identifiers
157 |
158 | - [ ] Set the domain and path for cookies containing authenticated session
159 | identifiers to an appropriately restricted value for the site
160 |
161 | - [ ] Logout functionality should fully terminate the associated session or connection
162 |
163 | - [ ] Logout functionality should be available from all pages protected by authorization
164 |
165 | - [ ] Establish a session inactivity timeout that is as short as possible,
166 | based on balancing risk and business functional requirements
167 |
168 | - [ ] Disallow persistent logins and enforce periodic session
169 | terminations, even when the session is active
170 |
171 | - [ ] If a session was established before login, close that session and
172 | establish a new session after a successful login
173 |
174 | - [ ] Generate a new session identifier on any re-authentication
175 |
176 | - [ ] Do not allow concurrent logins with the same user ID
177 |
178 | - [ ] Do not expose session identifiers in URLs, error messages or logs
179 |
180 | - [ ] Implement appropriate access controls to protect server side session data
181 | from unauthorized access from other users of the server
182 |
183 | - [ ] Generate a new session identifier and deactivate the old one periodically
184 |
185 | - [ ] Generate a new session identifier if the connection security changes
186 | from HTTP to HTTPS, as can occur during authentication
187 |
188 | - [ ] Consistently utilize HTTPS rather than switching between HTTP to HTTPS
189 |
190 | - [ ] Supplement standard session management for sensitive server-side
191 | operations, like account management, by utilizing per-session
192 | strong random tokens or parameters
193 |
194 | - [ ] Supplement standard session management for highly sensitive or
195 | critical operations by utilizing per-request, as opposed to
196 | per-session, strong random tokens or parameters
197 |
198 | - [ ] Set the \"secure\" attribute for cookies transmitted over an TLS connection
199 |
200 | - [ ] Set cookies with the HttpOnly attribute, unless you specifically
201 | require client-side scripts within your application to read or set
202 | a cookie\'s value
203 |
204 | ## Access control
205 |
206 | - [ ] Use only trusted system objects, e.g. server side session objects,
207 | for making access authorization decisions
208 |
209 | - [ ] Use a single site-wide component to check access authorization. This
210 | includes libraries that call external authorization services
211 |
212 | - [ ] Access controls should fail securely
213 |
214 | - [ ] Deny all access if the application cannot access its security
215 | configuration information
216 |
217 | - [ ] Enforce authorization controls on every request, including those made by server side scripts
218 |
219 | - [ ] Segregate privileged logic from other application code
220 |
221 | - [ ] Restrict access to files or other resources, including those outside
222 | the application\'s direct control, to only authorized users
223 |
224 | - [ ] Restrict access to protected URLs to only authorized users
225 |
226 | - [ ] Restrict access to protected functions to only authorized users
227 |
228 | - [ ] Restrict direct object references to only authorized users
229 |
230 | - [ ] Restrict access to services to only authorized users
231 |
232 | - [ ] Restrict access to application data to only authorized users
233 |
234 | - [ ] Restrict access to user and data attributes and policy information used by access controls
235 |
236 | - [ ] Restrict access security-relevant configuration information to only authorized users
237 |
238 | - [ ] Server side implementation and presentation layer representations of access control rules must match
239 |
240 | - [ ] If state data must be stored on the client, use encryption and integrity checking on the server side
241 | to detect state tampering
242 |
243 | - [ ] Enforce application logic flows to comply with business rules
244 |
245 | - [ ] Limit the number of transactions a single user or device can perform
246 | in a given period of time, low enough to deter automated attacks
247 | but above the actual business requirement
248 |
249 | - [ ] Use the \"referer\" header as a supplemental check only, it should
250 | never be the sole authorization check as it is can be spoofed
251 |
252 | - [ ] If long authenticated sessions are allowed, periodically re-validate
253 | a user's authorization to ensure that their privileges have not
254 | changed and if they have, log the user out and force them to
255 | re-authenticate
256 |
257 | - [ ] Implement account auditing and enforce the disabling of unused accounts
258 |
259 | - [ ] The application must support disabling of accounts
260 | and terminating sessions when authorization ceases
261 |
262 | - [ ] Service accounts or accounts supporting connections to or from
263 | external systems should have the least privilege possible
264 |
265 | - [ ] Create an Access Control Policy to document an application\'s
266 | business rules, data types and access authorization criteria
267 | and/or processes so that access can be properly provisioned and
268 | controlled. This includes identifying access requirements for both
269 | the data and system resources
270 |
271 | ## Cryptographic practices
272 |
273 | - [ ] All cryptographic functions used to protect secrets from the
274 | application user must be implemented on a trusted system
275 |
276 | - [ ] Protect secrets from unauthorized access
277 |
278 | - [ ] Cryptographic modules should fail securely
279 |
280 | - [ ] All random numbers, random file names, random GUIDs, and random
281 | strings should be generated using the cryptographic module's
282 | approved random number generator
283 |
284 | - [ ] Cryptographic modules used by the application should be compliant to
285 | FIPS 140-2 or an equivalent standard
286 |
287 | - [ ] Establish and utilize a policy and process for how cryptographic
288 | keys will be managed
289 |
290 | ## Error handling and logging
291 |
292 | - [ ] Do not disclose sensitive information in error responses, including
293 | system details, session identifiers or account information
294 |
295 | - [ ] Use error handlers that do not display debugging or stack trace information
296 |
297 | - [ ] Implement generic error messages and use custom error pages
298 |
299 | - [ ] The application should handle application errors and not rely on the server configuration
300 |
301 | - [ ] Properly free allocated memory when error conditions occur
302 |
303 | - [ ] Error handling logic associated with security controls should deny access by default
304 |
305 | - [ ] All logging controls should be implemented on a trusted system
306 |
307 | - [ ] Logging controls should support both success and failure of specified security events
308 |
309 | - [ ] Ensure logs contain important log event data
310 |
311 | - [ ] Ensure log entries that include un-trusted data will not execute as
312 | code in the intended log viewing interface or software
313 |
314 | - [ ] Restrict access to logs to only authorized individuals
315 |
316 | - [ ] Utilize a central routine for all logging operations
317 |
318 | - [ ] Do not store sensitive information in logs, including unnecessary
319 | system details, session identifiers or passwords
320 |
321 | - [ ] Ensure that a mechanism exists to conduct log analysis
322 |
323 | - [ ] Log all input validation failures
324 |
325 | - [ ] Log all authentication attempts, especially failures
326 |
327 | - [ ] Log all access control failures
328 |
329 | - [ ] Log all apparent tampering events, including unexpected changes to state data
330 |
331 | - [ ] Log attempts to connect with invalid or expired session tokens
332 |
333 | - [ ] Log all system exceptions
334 |
335 | - [ ] Log all administrative functions, including changes to the security configuration settings
336 |
337 | - [ ] Log all backend TLS connection failures
338 |
339 | - [ ] Log cryptographic module failures
340 |
341 | - [ ] Use a cryptographic hash function to validate log entry integrity
342 |
343 | ## Data protection
344 |
345 | - [ ] Implement least privilege, restrict users to only the functionality,
346 | data and system information that is required to perform their
347 | tasks
348 |
349 | - [ ] Protect all cached or temporary copies of sensitive data stored on
350 | the server from unauthorized access and purge those temporary
351 | working files a soon as they are no longer required.
352 |
353 | - [ ] Encrypt highly sensitive stored information, such as authentication
354 | verification data, even if on the server side
355 |
356 | - [ ] Protect server-side source-code from being downloaded by a user
357 |
358 | - [ ] Do not store passwords, connection strings or other sensitive
359 | information in clear text or in any non-cryptographically secure
360 | manner on the client side
361 |
362 | - [ ] Remove comments in user accessible production code that may reveal
363 | backend system or other sensitive information
364 |
365 | - [ ] Remove unnecessary application and system documentation as this can
366 | reveal useful information to attackers
367 |
368 | - [ ] Do not include sensitive information in HTTP GET request parameters
369 |
370 | - [ ] Disable auto complete features on forms expected to contain
371 | sensitive information, including authentication
372 |
373 | - [ ] Disable client side caching on pages containing sensitive information
374 |
375 | - [ ] The application should support the removal of sensitive data when
376 | that data is no longer required
377 |
378 | - [ ] Implement appropriate access controls for sensitive data stored on
379 | the server. This includes cached data, temporary files and data
380 | that should be accessible only by specific system users
381 |
382 | ## Communication security
383 |
384 | - [ ] Implement encryption for the transmission of all sensitive
385 | information. This should include TLS for protecting the connection
386 | and may be supplemented by discrete encryption of sensitive files
387 | or non-HTTP based connections
388 |
389 | - [ ] TLS certificates should be valid and have the correct domain name,
390 | not be expired, and be installed with intermediate certificates
391 | when required
392 |
393 | - [ ] Failed TLS connections should not fall back to an insecure connection
394 |
395 | - [ ] Utilize TLS connections for all content requiring authenticated access and for all other sensitive information
396 |
397 | - [ ] Utilize TLS for connections to external systems that involve sensitive information or functions
398 |
399 | - [ ] Utilize a single standard TLS implementation that is configured appropriately
400 |
401 | - [ ] Specify character encodings for all connections
402 |
403 | - [ ] Filter parameters containing sensitive information from the HTTP referer, when linking to external sites
404 |
405 | ## System configuration
406 |
407 | - [ ] Ensure servers, frameworks and system components are running the latest approved version
408 |
409 | - [ ] Ensure servers, frameworks and system components have all patches issued for the version in use
410 |
411 | - [ ] Turn off directory listings
412 |
413 | - [ ] Restrict the web server, process and service accounts to the least privileges possible
414 |
415 | - [ ] When exceptions occur, fail securely
416 |
417 | - [ ] Remove all unnecessary functionality and files
418 |
419 | - [ ] Remove test code or any functionality not intended for production, prior to deployment
420 |
421 | - [ ] Prevent disclosure of your directory structure in the robots.txt
422 | file by placing directories not intended for public indexing into
423 | an isolated parent directory
424 |
425 | - [ ] Define which HTTP methods, Get or Post, the application will support
426 | and whether it will be handled differently in different pages in
427 | the application
428 |
429 | - [ ] Disable unnecessary HTTP methods
430 |
431 | - [ ] If the web server handles different versions of HTTP ensure that they
432 | are configured in a similar manner and ensure any differences are understood
433 |
434 | - [ ] Remove unnecessary information from HTTP response headers related to
435 | the OS, web-server version and application frameworks
436 |
437 | - [ ] The security configuration store for the application should be able
438 | to be output in human readable form to support auditing
439 |
440 | - [ ] Implement an asset management system and register system components
441 | and software in it
442 |
443 | - [ ] Isolate development environments from the production network and
444 | provide access only to authorized development and test groups
445 |
446 | - [ ] Implement a software change control system to manage and record
447 | changes to the code both in development and production
448 |
449 | ## Database security
450 |
451 | - [ ] Use strongly typed parameterized queries
452 |
453 | - [ ] Utilize input validation and output encoding and be sure to address
454 | meta characters. If these fail, do not run the database command
455 |
456 | - [ ] Ensure that variables are strongly typed
457 |
458 | - [ ] The application should use the lowest possible level of privilege
459 | when accessing the database
460 |
461 | - [ ] Use secure credentials for database access
462 |
463 | - [ ] Connection strings should not be hard coded within the application.
464 | Connection strings should be stored in a separate configuration
465 | file on a trusted system and they should be encrypted.
466 |
467 | - [ ] Use stored procedures to abstract data access and allow for the
468 | removal of permissions to the base tables in the database
469 |
470 | - [ ] Close the connection as soon as possible
471 |
472 | - [ ] Remove or change all default database administrative passwords
473 |
474 | - [ ] Turn off all unnecessary database functionality
475 |
476 | - [ ] Remove unnecessary default vendor content (for example sample schemas)
477 |
478 | - [ ] Disable any default accounts that are not required to support business requirements
479 |
480 | - [ ] The application should connect to the database with different
481 | credentials for every trust distinction (for example user, read-only
482 | user, guest, administrators)
483 |
484 | ## File management
485 |
486 | - [ ] Do not pass user supplied data directly to any dynamic include function
487 |
488 | - [ ] Require authentication before allowing a file to be uploaded
489 |
490 | - [ ] Limit the type of files that can be uploaded to only those types
491 | that are needed for business purposes
492 |
493 | - [ ] Validate uploaded files are the expected type by checking file
494 | headers rather than by file extension
495 |
496 | - [ ] Do not save files in the same web context as the application
497 |
498 | - [ ] Prevent or restrict the uploading of any file that may be
499 | interpreted by the web server.
500 |
501 | - [ ] Turn off execution privileges on file upload directories
502 |
503 | - [ ] Implement safe uploading in UNIX by mounting the targeted file
504 | directory as a logical drive using the associated path or the
505 | chrooted environment
506 |
507 | - [ ] When referencing existing files, use an allow-list of allowed file names and types
508 |
509 | - [ ] Do not pass user supplied data into a dynamic redirect
510 |
511 | - [ ] Do not pass directory or file paths, use index values mapped to pre-defined list of paths
512 |
513 | - [ ] Never send the absolute file path to the client
514 |
515 | - [ ] Ensure application files and resources are read-only
516 |
517 | - [ ] Scan user uploaded files for viruses and malware
518 |
519 | ## Memory management
520 |
521 | - [ ] Utilize input and output controls for untrusted data
522 |
523 | - [ ] Check that the buffer is as large as specified
524 |
525 | - [ ] When using functions that accept a number of bytes ensure that NULL terminatation is handled correctly
526 |
527 | - [ ] Check buffer boundaries if calling the function in a loop and protect against overflow
528 |
529 | - [ ] Truncate all input strings to a reasonable length before passing them to other functions
530 |
531 | - [ ] Specifically close resources, don't rely on garbage collection
532 |
533 | - [ ] Use non-executable stacks when available
534 |
535 | - [ ] Avoid the use of known vulnerable functions
536 |
537 | - [ ] Properly free allocated memory upon the completion of functions and at all exit points
538 |
539 | - [ ] Overwrite any sensitive information stored in allocated memory at all exit points from the function
540 |
541 | ## General coding practices
542 |
543 | - [ ] Use tested and approved managed code rather than creating new unmanaged code for common tasks
544 |
545 | - [ ] Utilize task specific built-in APIs to conduct operating system
546 | tasks. Do not allow the application to issue commands directly to
547 | the Operating System, especially through the use of application
548 | initiated command shells
549 |
550 | - [ ] Use checksums or hashes to verify the integrity of interpreted code,
551 | libraries, executables, and configuration files
552 |
553 | - [ ] Utilize locking to prevent multiple simultaneous requests or use a
554 | synchronization mechanism to prevent race conditions
555 |
556 | - [ ] Protect shared variables and resources from inappropriate concurrent
557 | access
558 |
559 | - [ ] Explicitly initialize all your variables and other data stores,
560 | either during declaration or just before the first usage
561 |
562 | - [ ] In cases where the application must run with elevated privileges,
563 | raise privileges as late as possible, and drop them as soon as
564 | possible
565 |
566 | - [ ] Avoid calculation errors by understanding your programming language\'s underlying representation
567 |
568 | - [ ] Do not pass user supplied data to any dynamic execution function
569 |
570 | - [ ] Restrict users from generating new code or altering existing code
571 |
572 | - [ ] Review all secondary applications, third party code and libraries to
573 | determine business necessity and validate safe functionality
574 |
575 | - [ ] Implement safe updating using encrypted channels
576 |
577 | \newpage
578 |
--------------------------------------------------------------------------------
/draft-en/02-checklist/index.md:
--------------------------------------------------------------------------------
1 | ---
2 |
3 | layout: col-document
4 | title: Secure Coding Practices - Draft
5 | tags: SCPQRG
6 | document: OWASP Secure Coding Practices - Quick Reference Guide
7 |
8 | ---
9 |
10 | {% include breadcrumb.html %}
11 | # Secure Coding Practices Checklist
12 |
13 | 2.1 [Input validation](05-checklist.md#input-validation)
14 |
15 | 2.2 [Output encoding](05-checklist.md#output-encoding)
16 |
17 | 2.3 [Authentication and password management](05-checklist.md#authentication-and-password-management)
18 |
19 | 2.4 [Session management](05-checklist.md#session-management)
20 |
21 | 2.5 [Access control](05-checklist.md#access-control)
22 |
23 | 2.6 [Cryptographic practices](05-checklist.md#cryptographic-practices)
24 |
25 | 2.7 [Error handling and logging](05-checklist.md#error-handling-and-logging)
26 |
27 | 2.8 [Data protection](05-checklist.md#data-protection)
28 |
29 | 2.9 [Communication security](05-checklist.md#communication-security)
30 |
31 | 2.10 [System configuration](05-checklist.md#system-configuration)
32 |
33 | 2.11 [Database security](05-checklist.md#database-security)
34 |
35 | 2.12 [File management](05-checklist.md#file-management)
36 |
37 | 2.13 [Memory management](05-checklist.md#memory-management)
38 |
39 | 2.14 [General coding practices](05-checklist.md#general-coding-practices)
40 |
--------------------------------------------------------------------------------
/draft-en/02-checklist/info.md:
--------------------------------------------------------------------------------
1 | {% include navigation.html collection="draft-en" %}
2 |
--------------------------------------------------------------------------------
/draft-en/03-appendices/03-overview.md:
--------------------------------------------------------------------------------
1 | ---
2 |
3 | layout: col-document
4 | title: Secure Coding Practices - Draft
5 | tags: SCP-QRG
6 |
7 | ---
8 |
9 | {% include breadcrumb.html %}
10 | # Appendix A: Software Security and Risk Principles Overview
11 |
12 | Building secure software requires a basic understanding of security
13 | principles. While a comprehensive review of security principles is
14 | beyond the scope of this guide, a quick overview is provided.
15 |
16 | The goal of software security is to maintain the
17 | confidentiality, integrity, and availability of information resources in order to
18 | enable successful business operations.
19 | This goal is accomplished through the implementation of security controls.
20 | This guide focuses on the technical controls specific to
21 | mitigating the occurrence of common software vulnerabilities.
22 | While the primary focus is web applications and their supporting infrastructure,
23 | most of the guidance can be applied to any software deployment platform.
24 |
25 | It is helpful to understand what is meant by risk, in order to protect
26 | the business from unacceptable risks associated with its reliance on
27 | software. Risk is a combination of factors that threaten the success of
28 | the business. This can be described conceptually as follows: a threat
29 | agent interacts with a system, which may have a vulnerability that can be
30 | exploited in order to cause an impact. While
31 | this may seem like an abstract concept, think of it this way: a car
32 | burglar (threat agent) goes through a parking lot checking cars (the
33 | system) for unlocked doors (the vulnerability) and when they find one,
34 | they open the door (the exploit) and take whatever is inside (the
35 | impact). All of these factors play a role in secure software
36 | development.
37 |
38 | There is a fundamental difference between the approach taken by a
39 | development team and that taken by someone attacking an application. A
40 | development team typically approaches an application based on what it is
41 | intended to do. In other words, they are designing an application to
42 | perform specific tasks based on documented functional requirements and
43 | use cases. An attacker, on the other hand, is more interested in what an
44 | application can be made to do and operates on the principle that \"any
45 | action not specifically denied, is allowed\". To address this, some
46 | additional elements need to be integrated into the early stages of the
47 | software lifecycle. These new elements are [*security
48 | requirements*](#Security_Requirements) and [*abuse cases*](#Abuse_Case).
49 | This guide is designed to help with identifying high level security
50 | requirements and addressing many common abuse scenarios.
51 |
52 | It is important for web development teams to understand that client side
53 | controls like client based input validation, hidden fields and interface
54 | controls (e.g., pull downs and radio buttons), provide little if any
55 | security benefit. An attacker can use tools like client side web proxies
56 | (e.g. OWASP ZAP, Burp) or network packet capture tools (e.g.,
57 | WireShark) to analyze application traffic and submit custom built
58 | requests, bypassing the interface all together. Additionally, Flash,
59 | Java Applets and other client side objects can be decompiled and
60 | analyzed for flaws.
61 |
62 | Software security flaws can be introduced at any stage of the software
63 | development lifecycle, including:
64 |
65 | - Not identifying security requirements up front
66 |
67 | - Creating conceptual designs that have logic errors
68 |
69 | - Using poor coding practices that introduce technical vulnerabilities
70 |
71 | - Deploying the software improperly
72 |
73 | - Introducing flaws during maintenance or updating
74 |
75 | Furthermore, it is important to understand that software vulnerabilities
76 | can have a scope beyond the software itself. Depending on the nature of
77 | the software, the vulnerability and the supporting infrastructure, the
78 | impacts of a successful exploitation can include compromises to any or
79 | all of the following:
80 |
81 | - The software and its associated information
82 |
83 | - The operating systems of the associated servers
84 |
85 | - The backend database
86 |
87 | - Other applications in a shared environment
88 |
89 | - The user\'s system
90 |
91 | - Other software that the user interacts with
92 |
93 | \newpage
94 |
--------------------------------------------------------------------------------
/draft-en/03-appendices/05-glossary.md:
--------------------------------------------------------------------------------
1 | ---
2 |
3 | layout: col-document
4 | title: Secure Coding Practices - Draft
5 | tags: SCP-QRG
6 |
7 | ---
8 |
9 | {% include breadcrumb.html %}
10 | # Appendix B: Glossary
11 |
12 | **Abuse case:** Describes the intentional and
13 | unintentional misuses of the software. Abuse cases should challenge the
14 | assumptions of the system design.
15 |
16 | **Access control:** A set of controls that grant or deny a user, or
17 | other entity, access to a system resource. This is usually based on
18 | hierarchical roles and individual privileges within a role, but also
19 | includes system to system interactions.
20 |
21 | **Account disabling:** Account disabling after an established number of invalid
22 | login attempts (e.g., five attempts is common). The account must
23 | be disabled for a period of time sufficient to discourage brute
24 | force guessing of credentials, but not so long as to allow for a
25 | denial-of-service attack to be performed
26 |
27 | **Authentication:** A set of controls that are used to verify the
28 | identity of a user, or other entity, interacting with the software.
29 |
30 | Authentication failure responses should not indicate which part of
31 | the authentication data was incorrect. For example, instead of
32 | \"Invalid username\" or \"Invalid password\", just use \"Invalid
33 | username and/or password\" for both. Error responses must be truly
34 | identical in both display and source code
35 |
36 | **Availability:** A measure of a system\'s accessibility and usability.
37 |
38 | **Calculation errors:** Avoid calculation errors by understanding your programming
39 | language\'s underlying representation and how it interacts with
40 | numeric calculation. Pay close attention to byte size
41 | discrepancies, precision, signed/unsigned distinctions,
42 | truncation, conversion and casting between types, \"not-a-number\"
43 | calculations, and how your language handles numbers that are too
44 | large or too small for its underlying representation
45 |
46 | **Canonicalize:** To reduce various encodings
47 | and representations of data to a single simple form.
48 |
49 | **Communication security:** A set of controls that help ensure the
50 | software handles the sending and receiving of information in a secure
51 | manner.
52 |
53 | **Confidentiality:** To ensure that information is disclosed only to authorized parties.
54 |
55 | **Contextual output encoding:**
56 | Encoding output data based on how it will be utilized by the
57 | application. The specific methods vary depending on the way the output
58 | data is used. If the data is to be included in the response to the
59 | client, account for inclusion scenarios like: the body of an HTML
60 | document, an HTML attribute, within JavaScript, within a CSS or in a URL.
61 | You must also account for other use cases like SQL queries, XML and LDAP.
62 | Consider HTML entity encoding, but this may not work in all cases.
63 |
64 | **Cross Site Request Forgery (CSRF):**
65 | An external website or application forces a client to make an unintended
66 | request to another application that the client has an active session
67 | with. Applications are vulnerable when they use known, or predictable,
68 | URLs and parameters; and when the browser automatically transmits all
69 | required session information with each request to the vulnerable
70 | application.
71 |
72 | **Cryptographic practices:** A set of controls that ensure cryptographic
73 | operations within the application are handled securely.
74 |
75 | **Data protection:** A set of controls that help ensure the software
76 | handles the storing of information in a secure manner.
77 |
78 | **Database security:** A set of controls that ensure that software
79 | interacts with a database in a secure manner and that the database is
80 | configured securely.
81 |
82 | **Error handling and logging:** A set of practices that ensure the
83 | application handles errors safely and conducts proper event logging.
84 |
85 | **Exploit:** To take advantage of a vulnerability.
86 | Typically this is an intentional action designed to compromise the
87 | software\'s security controls by leveraging a vulnerability.
88 |
89 | **File management:** A set of controls that cover the interaction
90 | between the code and other system files.
91 |
92 | **General coding practices:** A set of controls that cover coding
93 | practices that do not fit easily into other categories.
94 |
95 | **Hazardous character:** Any character
96 | or encoded representation of a character that can effect the intended
97 | operation of the application or associated system by being interpreted
98 | to have a special meaning, outside the intended use of the character.
99 | These characters may be used to:
100 |
101 | * Altering the structure of existing code or statements
102 | * Inserting new unintended code
103 | * Altering paths
104 | * Causing unexpected outcomes from program functions or routines
105 | * Causing error conditions
106 | * Compromise downstream applications or systems
107 |
108 | If any potentially hazardous characters
109 | must be allowed as input, be sure that you implement additional
110 | controls like output encoding, secure task specific APIs and
111 | accounting for the utilization of that data throughout the
112 | application . Examples of common hazardous characters include:
113 | > \< \> \" \' % ( ) & + \\ \\\' \\\"
114 |
115 | * Check for new line characters (%0d, %0a, \\r, \\n)
116 | * Check for "dot-dot-slash\" (../ or ..\\) path alterations
117 | characters. In cases where UTF-8 extended character set
118 | encoding is supported, address alternate representation like:
119 | %c0%ae%c0%ae/
120 |
121 | **HTML eEntity encode:** The process of
122 | replacing certain ASCII characters with their HTML entity equivalents.
123 | For example, encoding would replace the less than character \"\<\" with
124 | the HTML equivalent \"<\". HTML entities are \'inert\' in most
125 | interpreters, especially browsers, which can mitigate certain client
126 | side attacks.
127 |
128 | **Impact:** A measure of the negative effect to the
129 | business that results from the occurrence of an undesired event; what
130 | would be the result of a vulnerability being exploited.
131 |
132 | **Input validation:** A set of controls that verify the properties of
133 | all input data matches what is expected by the application including
134 | types, lengths, ranges, acceptable character sets and does not include
135 | known hazardous characters.
136 |
137 | **Integrity:** The assurance that information is
138 | accurate, complete and valid, and has not been altered by an
139 | unauthorized action.
140 |
141 | **Log event data:** This should include the following:
142 |
143 | 1. Time stamp from a trusted system component
144 | 2. Severity rating for each event
145 | 3. Tagging of security relevant events, if they are mixed with other log entries
146 | 4. Identity of the account/user that caused the event
147 | 5. Source IP address associated with the request
148 | 6. Event outcome (success or failure)
149 | 7. Description of the event
150 |
151 | Implement monitoring to identify attacks against multiple user
152 | accounts, utilizing the same password. This attack pattern is used
153 | to bypass standard lockouts, when user IDs can be harvested or
154 | guessed.
155 |
156 | **Memory management:** A set of controls that address memory and buffer usage.
157 |
158 | **Mitigate:** Steps taken to reduce the severity of
159 | a vulnerability. These can include removing a vulnerability, making a
160 | vulnerability more difficult to exploit, or reducing the negative impact
161 | of a successful exploitation.
162 |
163 | **Multi-Factor Authentication (MFA):** An authentication process that requires
164 | the user to produce multiple distinct types of credentials.
165 | Typically this is based on something:
166 |
167 | * they have, for example a mobile/cell phone
168 | * something they know, for example a PIN
169 | * something they are, for example data from a biometric reader
170 |
171 | **Output encoding:** A set of controls addressing the use of encoding to
172 | ensure data output by the application is safe.
173 |
174 | **Parameterized queries / prepared statements:**
175 | Keeps the query and data separate through the use of
176 | placeholders. The query structure is defined with place holders, the SQL
177 | statement is sent to the database and prepared, and then the prepared
178 | statement is combined with the parameter values. The prevents the query
179 | from being altered, because the parameter values are combined with the
180 | compiled statement, not a SQL string.
181 |
182 | **Password complexity**: Password complexity requirements established by policy or
183 | regulation. Authentication credentials should be sufficient to
184 | withstand attacks that are typical of the threats in the deployed
185 | environment. (e.g., requiring the use of alphabetic as well as
186 | numeric and/or special characters).
187 |
188 | **Password length:** Password length requirements established by policy or
189 | regulation. Eight characters is commonly used, but 16 is better or
190 | consider the use of multi-word pass phrases
191 |
192 | **Persistent logins**: Disallow persistent logins and enforce periodic session
193 | terminations, even when the session is active. Especially for
194 | applications supporting rich network connections or connecting to
195 | critical systems. Termination times should support business
196 | requirements and the user should receive sufficient notification
197 | to mitigate negative impacts
198 |
199 | **Safe updates:** Method of updating the application from trusted sources.
200 | If the application utilizes automatic
201 | updates, then use cryptographic signatures for your code and
202 | ensure your download clients verify those signatures. Use
203 | encrypted channels to transfer the code from the host server
204 |
205 | **Sanitize data:** The process of making
206 | potentially harmful data safe through the use of data removal,
207 | replacement, encoding or escaping of the characters.
208 |
209 | **Security controls:** An action that
210 | mitigates a potential vulnerability and helps ensure that the software
211 | behaves only in the expected manner.
212 |
213 | **Security requirements:** A set of
214 | design and functional requirements that help ensure the software is
215 | built and deployed in a secure manner.
216 |
217 | **Sequential authentication:**
218 | When authentication data is requested on successive pages rather than
219 | being requested all at once on a single page.
220 |
221 | **Session management:** A set of controls that help ensure web
222 | applications handle HTTP sessions in a secure manner.
223 |
224 | Do not expose session identifiers in URLs, error messages or logs.
225 | Session identifiers should only be located in the HTTP cookie
226 | header. For example, do not pass session identifiers as GET
227 | parameters
228 |
229 | **State data:** When data or parameters are used,
230 | by the application or server, to emulate a persistent connection or
231 | track a client\'s status across a multi-request process or transaction.
232 |
233 | **System:** A generic term covering the operating
234 | systems, web server, application frameworks and related infrastructure.
235 |
236 | **System configuration:** A set of controls that help ensure the
237 | infrastructure components supporting the software are deployed securely.
238 |
239 | **Threat Agent:** Any entity which may have a
240 | negative impact on the system. This may be a malicious user who wants to
241 | compromise the system\'s security controls; however, it could also be an
242 | accidental misuse of the system or a more physical threat like fire or
243 | flood.
244 |
245 | **Trust boundaries:** Typically a trust
246 | boundary constitutes the components of the system under your direct
247 | control. All connections and data from systems outside of your direct
248 | control, including all clients and systems managed by other parties,
249 | should be consider untrusted and be validated at the boundary before
250 | allowing further system interaction.
251 |
252 | **Vulnerability:** A weakness that makes the system susceptible to attack or damage.
253 |
254 | \newpage
255 |
--------------------------------------------------------------------------------
/draft-en/03-appendices/07-references.md:
--------------------------------------------------------------------------------
1 | ---
2 |
3 | layout: col-document
4 | title: Secure Coding Practices - Draft
5 | tags: SCP-QRG
6 |
7 | ---
8 |
9 | {% include breadcrumb.html %}
10 | # Appendix C: External References
11 |
12 | ## Cited References
13 |
14 | - SANS CIS Controls version 8
15 |
16 | >
33 |
34 |
35 | ## Security Advisory Sites
36 |
37 | Useful resources to check for known vulnerabilities against supporting
38 | infrastructure and frameworks
39 |
40 | > Secunia Citrix Vulnerability List:
41 |
42 | -
43 |
44 | > Common Vulnerability Enumeration:
45 |
46 | -
34 |
35 |
36 | ## Security Advisory Sites
37 |
38 | Useful resources to check for known vulnerabilities against supporting
39 | infrastructure and frameworks
40 |
41 | > Secunia Citrix Vulnerability List:
42 |
43 | -
44 |
45 | > Common Vulnerability Enumeration:
46 |
47 | -
34 |
35 | ## Sitios de avisos sobre seguridad
36 |
37 | Fuentes útiles para verificar vulnerabilidades comunes sobre la
38 | infraestructura soporte y frameworks
39 |
40 | > Secunia Citrix Vulnerability List:
41 |
42 | -
43 |
44 | > Common Vulnerability Enumeration:
45 |
46 | -
34 |
35 |
36 | ## سایتهای مشاوره امنیتی
37 |
38 | منابع مفید برای بررسی آسیبپذیریهای شناخته شده در زیرساختها و فریمورکهای پشتیبان
39 |
40 | > Secunia Citrix Vulnerability List:
41 |
42 | -
43 |
44 | > Common Vulnerability Enumeration:
45 |
46 | - 