├── .github
├── FUNDING.yml
├── ISSUE_TEMPLATE
│ └── request.md
├── PULL_REQUEST_TEMPLATE.md
├── dependabot.yaml
└── workflows
│ ├── export.yaml
│ └── housekeeping.yaml
├── .gitignore
├── CODE_OF_CONDUCT.md
├── LICENSE.txt
├── README.md
├── SECURITY.md
├── draft
├── en
│ └── us
│ │ ├── 01-introduction
│ │ ├── 01-front.markdown
│ │ ├── 02-toc.markdown
│ │ ├── 04-copyright.markdown
│ │ └── 05-introduction.markdown
│ │ ├── 02-checklist
│ │ └── 05-checklist.markdown
│ │ ├── 03-appendices
│ │ ├── 03-overview.markdown
│ │ ├── 05-glossary.markdown
│ │ └── 07-references.markdown
│ │ ├── README.md
│ │ ├── title.pdf.yaml
│ │ └── title.yaml
└── es
│ └── uy
│ ├── 01-introduction
│ ├── 01-front.markdown
│ ├── 02-toc.markdown
│ ├── 03-credits.markdown
│ ├── 04-copyright.markdown
│ └── 05-introduction.markdown
│ ├── 02-checklist
│ └── 05-checklist.markdown
│ ├── 03-appendices
│ ├── 03-overview.markdown
│ ├── 05-glossary.markdown
│ └── 07-references.markdown
│ ├── README.md
│ ├── title.pdf.yaml
│ └── title.yaml
├── images
└── OWASP-logo.jpg
├── materials
├── Flyer_Secure_Coding_Practices_Quick_Reference_Guide_V2.pdf
├── SCP-QRG_Revisions_History.xls
├── Secure_Coding_Practices_Quick_Ref_5.ppt
└── Secure_Coding_Practices_Quick_Ref_6.ppt
└── v2
├── en
└── us
│ ├── 01-introduction
│ ├── 01-front.markdown
│ ├── 02-toc.markdown
│ ├── 04-copyright.markdown
│ └── 05-introduction.markdown
│ ├── 02-checklist
│ └── 05-checklist.markdown
│ ├── 03-appendices
│ ├── 03-overview.markdown
│ ├── 05-glossary.markdown
│ └── 07-references.markdown
│ ├── README.md
│ ├── title.pdf.yaml
│ └── title.yaml
├── es
└── uy
│ ├── 01-introduction
│ ├── 01-front.markdown
│ ├── 02-toc.markdown
│ ├── 03-credits.markdown
│ ├── 04-copyright.markdown
│ └── 05-introduction.markdown
│ ├── 02-checklist
│ └── 05-checklist.markdown
│ ├── 03-appendices
│ ├── 03-overview.markdown
│ ├── 05-glossary.markdown
│ └── 07-references.markdown
│ ├── README.md
│ ├── title.pdf.yaml
│ └── title.yaml
├── ko
└── kr
│ ├── 01-introduction
│ ├── 01-front.markdown
│ ├── 02-toc.markdown
│ ├── 04-copyright.markdown
│ └── 05-introduction.markdown
│ ├── 02-checklist
│ └── 05-checklist.markdown
│ ├── 03-appendices
│ ├── 03-overview.markdown
│ ├── 05-glossary.markdown
│ └── 07-references.markdown
│ ├── README.md
│ ├── title.pdf.yaml
│ └── title.yaml
├── pt
├── br
│ ├── 01-introduction
│ │ ├── 01-front.markdown
│ │ ├── 02-toc.markdown
│ │ ├── 03-credits.markdown
│ │ ├── 04-copyright.markdown
│ │ └── 05-introduction.markdown
│ ├── 02-checklist
│ │ └── 05-checklist.markdown
│ ├── 03-appendices
│ │ ├── 03-overview.markdown
│ │ ├── 05-glossary.markdown
│ │ ├── 07-references.markdown
│ │ └── 08-footnotes.markdown
│ ├── README.md
│ ├── title.pdf.yaml
│ └── title.yaml
└── pt
│ ├── 01-introduction
│ ├── 01-front.markdown
│ ├── 02-toc.markdown
│ ├── 03-credits.markdown
│ ├── 04-copyright.markdown
│ └── 05-introduction.markdown
│ ├── 02-checklist
│ └── 05-checklist.markdown
│ ├── 03-appendices
│ ├── 03-overview.markdown
│ ├── 05-glossary.markdown
│ ├── 07-references.markdown
│ └── 08-footnotes.markdown
│ ├── README.md
│ ├── title.pdf.yaml
│ └── title.yaml
└── zh
└── cn
├── 01-introduction
├── 01-front.markdown
├── 02-toc.markdown
├── 03-credits.markdown
├── 04-copyright.markdown
└── 05-introduction.markdown
├── 02-checklist
└── 05-checklist.markdown
├── 03-appendices
├── 03-overview.markdown
├── 05-glossary.markdown
└── 07-references.markdown
├── README.md
├── title.pdf.yaml
└── title.yaml
/.github/FUNDING.yml:
--------------------------------------------------------------------------------
1 | custom: https://owasp.org/donate/?reponame=www-project-secure-coding-practices-quick-reference-guide&title=OWASP+Secure+Coding+Practices+Quick+Reference+Guide
2 | github: OWASP
3 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE/request.md:
--------------------------------------------------------------------------------
1 | ---
2 | name: Change request
3 | about: Suggest a change for this project
4 | title: ''
5 | labels: 'enhancement'
6 | assignees: ''
7 |
8 | ---
9 |
10 | **Describe what change you would like**
11 |
12 |
13 | **Context**
14 | Language: (eg 'cn' or 'pt')
15 | Section: (eg '05-checklis')
16 |
17 |
18 |
--------------------------------------------------------------------------------
/.github/PULL_REQUEST_TEMPLATE.md:
--------------------------------------------------------------------------------
1 | **Summary**
2 |
6 |
7 | **Description for the changelog**
8 |
11 |
12 | **Other info**
13 |
19 |
20 |
--------------------------------------------------------------------------------
/.github/dependabot.yaml:
--------------------------------------------------------------------------------
1 | version: 2
2 | updates:
3 | - package-ecosystem: "github-actions"
4 | directory: ".github/workflows"
5 | schedule:
6 | interval: "daily"
7 | ignore:
8 | # ignore all (on-security) patch updates
9 | - dependency-name: "*"
10 | update-types: ["version-update:semver-patch"]
11 |
--------------------------------------------------------------------------------
/.github/workflows/export.yaml:
--------------------------------------------------------------------------------
1 | name: Export to pdf and epub
2 | on:
3 | push:
4 | branches:
5 | - '*'
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 | - uses: actions/checkout@v3.4.0
18 |
19 | - name: Link Checker
20 | uses: lycheeverse/lychee-action@v1.6.1
21 | with:
22 | fail: true
23 | env:
24 | GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
25 |
26 | en_us:
27 | name: en-us epub and pdf
28 | runs-on: ubuntu-22.04
29 | needs: [link_checker]
30 | steps:
31 | - name: Checkout markdown
32 | uses: actions/checkout@v3.4.0
33 |
34 | - name: Create paths
35 | run: mkdir -p publish
36 |
37 | - name: Export to pdf
38 | uses: docker://pandoc/latex:3.1
39 | with:
40 | args: >-
41 | --output=publish/OWASP_SCP_Quick_Reference_Guide.en-US.pdf
42 | draft/en/us/title.pdf.yaml
43 | draft/en/us/01-introduction/01-front.markdown
44 | draft/en/us/01-introduction/02-toc.markdown
45 | draft/en/us/01-introduction/04-copyright.markdown
46 | draft/en/us/01-introduction/05-introduction.markdown
47 | draft/en/us/02-checklist/05-checklist.markdown
48 | draft/en/us/03-appendices/03-overview.markdown
49 | draft/en/us/03-appendices/05-glossary.markdown
50 | draft/en/us/03-appendices/07-references.markdown
51 |
52 | - name: Export to epub
53 | uses: docker://pandoc/latex:3.1
54 | with:
55 | args: >-
56 | --output=publish/OWASP_SCP_Quick_Reference_Guide.en-US.epub
57 | draft/en/us/title.yaml
58 | draft/en/us/01-introduction/01-front.markdown
59 | draft/en/us/01-introduction/02-toc.markdown
60 | draft/en/us/01-introduction/04-copyright.markdown
61 | draft/en/us/01-introduction/05-introduction.markdown
62 | draft/en/us/02-checklist/05-checklist.markdown
63 | draft/en/us/03-appendices/03-overview.markdown
64 | draft/en/us/03-appendices/05-glossary.markdown
65 | draft/en/us/03-appendices/07-references.markdown
66 |
67 | - name: Save pdfs and epubs
68 | uses: actions/upload-artifact@master
69 | with:
70 | name: en-us
71 | path: publish
72 |
73 | es_uy:
74 | name: es-uy epub and pdf
75 | runs-on: ubuntu-22.04
76 | needs: [link_checker]
77 | steps:
78 | - name: Checkout markdown
79 | uses: actions/checkout@v3.4.0
80 |
81 | - name: Create paths
82 | run: mkdir -p publish
83 |
84 | - name: Export to pdf
85 | uses: docker://pandoc/latex:3.1
86 | with:
87 | args: >-
88 | --output=publish/OWASP_SCP_Quick_Reference_Guide.es-UY.pdf
89 | draft/es/uy/title.pdf.yaml
90 | draft/es/uy/01-introduction/01-front.markdown
91 | draft/es/uy/01-introduction/02-toc.markdown
92 | draft/es/uy/01-introduction/03-credits.markdown
93 | draft/es/uy/01-introduction/04-copyright.markdown
94 | draft/es/uy/01-introduction/05-introduction.markdown
95 | draft/es/uy/02-checklist/05-checklist.markdown
96 | draft/es/uy/03-appendices/03-overview.markdown
97 | draft/es/uy/03-appendices/05-glossary.markdown
98 | draft/es/uy/03-appendices/07-references.markdown
99 |
100 | - name: Export to epub
101 | uses: docker://pandoc/latex:3.1
102 | with:
103 | args: >-
104 | --output=publish/OWASP_SCP_Quick_Reference_Guide.es-UY.epub
105 | draft/es/uy/title.yaml
106 | draft/es/uy/01-introduction/01-front.markdown
107 | draft/es/uy/01-introduction/02-toc.markdown
108 | draft/es/uy/01-introduction/03-credits.markdown
109 | draft/es/uy/01-introduction/04-copyright.markdown
110 | draft/es/uy/01-introduction/05-introduction.markdown
111 | draft/es/uy/02-checklist/05-checklist.markdown
112 | draft/es/uy/03-appendices/03-overview.markdown
113 | draft/es/uy/03-appendices/05-glossary.markdown
114 | draft/es/uy/03-appendices/07-references.markdown
115 |
116 | - name: Save pdfs and epubs
117 | uses: actions/upload-artifact@master
118 | with:
119 | name: es-uy
120 | path: publish
121 |
--------------------------------------------------------------------------------
/.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 | housekeeping:
11 | name: housekeeping
12 | runs-on: ubuntu-22.04
13 |
14 | steps:
15 | - name: Delete stale workflow runs
16 | uses: Mattraks/delete-workflow-runs@v2.0.3
17 | with:
18 | token: ${{ github.token }}
19 | repository: ${{ github.repository }}
20 | retain_days: 60
21 | keep_minimum_runs: 3
22 |
23 |
24 | link_checker:
25 | name: link checker
26 | runs-on: ubuntu-22.04
27 | steps:
28 | - uses: actions/checkout@v3.4.0
29 |
30 | - name: Link Checker
31 | uses: lycheeverse/lychee-action@v1.6.1
32 | with:
33 | fail: true
34 | env:
35 | GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
36 |
--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | node_modules/
2 |
3 | # ignore markdown (unless it is markdown for pandoc)
4 | *.md
5 |
6 | # pandoc generated files
7 | *.docx
8 | *.docx#
9 | *.epub
10 | *.mobi
11 | *.pdf
12 |
13 | # # jekyll generated files
14 | _site
15 |
16 | # ignore Apple's desktop store files
17 | .DS_Store
18 | **/.DS_Store
19 | # ignore VS and Eclipse files
20 | .vscode/
21 | .settings/
22 | .jshint*
23 | .project
24 | # ignore IntelliJ IDEA files
25 | .idea/
26 |
27 | # keep the README files
28 | !README.md
29 |
30 | # keep the .github templates
31 | !.github/**/*
32 |
33 |
--------------------------------------------------------------------------------
/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
10 | identity 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, and learning from the experience
24 | * Focusing on what is best not just for us as individuals, but for the overall community
25 |
26 | Examples of unacceptable behavior include:
27 |
28 | * The use of sexualized language or imagery, and sexual attention or advances of any kind
29 | * Trolling, insulting or derogatory comments, and personal or political attacks
30 | * Public or private harassment
31 | * Publishing others' private information, such as a physical or email address, without their explicit permission
32 | * Other conduct which could reasonably be considered inappropriate in a professional setting
33 |
34 | ## Enforcement Responsibilities
35 |
36 | Community leaders are responsible for clarifying and enforcing our standards of
37 | acceptable behavior and will take appropriate and fair corrective action in
38 | response to any behavior that they deem inappropriate, threatening, offensive,
39 | or harmful.
40 |
41 | Community leaders have the right and responsibility to remove, edit, or reject
42 | comments, commits, code, wiki edits, issues, and other contributions that are
43 | not aligned to this Code of Conduct, and will communicate reasons for moderation
44 | decisions when appropriate.
45 |
46 | ## Scope
47 |
48 | This Code of Conduct applies within all community spaces, and also applies when
49 | an individual is officially representing the community in public spaces.
50 | Examples of representing our community include using an official e-mail address,
51 | posting via an official social media account, or acting as an appointed
52 | representative at an online or offline event.
53 |
54 | ## Enforcement
55 |
56 | Instances of abusive, harassing, or otherwise unacceptable behavior may be
57 | reported to the community leaders responsible for enforcement
58 | by [emailing](mailto:jon.gadsden@owasp.org) jon.gadsden@owasp.org.
59 | All complaints will be reviewed and investigated promptly and fairly.
60 |
61 | All community leaders are obligated to respect the privacy and security of the
62 | reporter of any incident.
63 |
64 | ## Enforcement Guidelines
65 |
66 | Community leaders will follow these Community Impact Guidelines in determining
67 | the consequences for any action they deem in violation of this Code of Conduct:
68 |
69 | ### 1. Correction
70 |
71 | **Community Impact**: Use of inappropriate language or other behavior deemed
72 | unprofessional or unwelcome in the community.
73 |
74 | **Consequence**: A private, written warning from community leaders, providing
75 | clarity around the nature of the violation and an explanation of why the
76 | behavior was inappropriate. A public apology may be requested.
77 |
78 | ### 2. Warning
79 |
80 | **Community Impact**: A violation through a single incident or series of
81 | actions.
82 |
83 | **Consequence**: A warning with consequences for continued behavior. No
84 | interaction with the people involved, including unsolicited interaction with
85 | those enforcing the Code of Conduct, for a specified period of time. This
86 | includes avoiding interactions in community spaces as well as external channels
87 | like social media. Violating these terms may lead to a temporary or permanent
88 | ban.
89 |
90 | ### 3. Temporary Ban
91 |
92 | **Community Impact**: A serious violation of community standards, including
93 | sustained inappropriate behavior.
94 |
95 | **Consequence**: A temporary ban from any sort of interaction or public
96 | communication with the community for a specified period of time. No public or
97 | private interaction with the people involved, including unsolicited interaction
98 | with those enforcing the Code of Conduct, is allowed during this period.
99 | Violating these terms may lead to a permanent ban.
100 |
101 | ### 4. Permanent Ban
102 |
103 | **Community Impact**: Demonstrating a pattern of violation of community
104 | standards, including sustained inappropriate behavior, harassment of an
105 | individual, or aggression toward or disparagement of classes of individuals.
106 |
107 | **Consequence**: A permanent ban from any sort of public interaction within the
108 | community.
109 |
110 | ## Attribution
111 |
112 | This Code of Conduct is adapted from the [Contributor Covenant][homepage],
113 | version 2.1, available at
114 | [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
115 |
116 | Community Impact Guidelines were inspired by
117 | [Mozilla's code of conduct enforcement ladder][Mozilla CoC].
118 |
119 | For answers to common questions about this code of conduct, see the FAQ at
120 | [https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
121 | [https://www.contributor-covenant.org/translations][translations].
122 |
123 | [homepage]: https://www.contributor-covenant.org
124 | [v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
125 | [Mozilla CoC]: https://github.com/mozilla/diversity
126 | [FAQ]: https://www.contributor-covenant.org/faq
127 | [translations]: https://www.contributor-covenant.org/translations
128 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | ## Archived
2 |
3 | *This repository is now archived*.
4 | You can still access the downloads but it is read only, the content having been moved to
5 | the [OWASP project pages](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide).
6 |
7 | The [latest stable Spanish language version](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/)
8 | is available on the OWASP project pages along with
9 | the [latest stable English language version](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-es/).
10 |
11 | There is also a [work in progress English language version](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/draft-en/),
12 | which have all been migrated to the [OWASP project pages](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide).
13 |
14 | ## Note that this repository is in the process of being migrated
15 | OWASP is moving to a 'web first' philosphy and moving away from downloads.
16 | We will still be providing PDF and ePub, but the emphasis will be on providing web page documents.
17 |
18 | Part of this migration will be the use of the [OWASP project page][owaspscpqrg]
19 | as the source of the document.
20 | Version 2.0 of [this repo][this] will become `stable` in the [OWASP project pages][owaspscpqrg]
21 | and work-in-progress will be under `draft` in the [OWASP project pages][owaspscpqrg].
22 |
23 | When the migration is complete [this repo][this] will be archived as Read Only.
24 |
25 | ### Welcome to the Secure Coding Practices Quick Reference Guide Project
26 |
27 | The OWASP Secure Coding Practices Quick Reference Guide is a technology agnostic
28 | set of general software security coding practices, in a comprehensive checklist
29 | format, that can be integrated into the development life-cycle.
30 |
31 | The focus is on secure coding requirements, rather than on vulnerabilities and
32 | exploits. It includes an introduction to Software Security principles and a
33 | glossary of key terms.
34 | It is designed to serve as a secure coding kick-start tool and easy reference,
35 | to help development teams quickly understand secure coding practices.
36 |
37 | Downloads for the [latest version][latest] are available for:
38 |
39 | - English (en-US)
40 | - español (es-UY)
41 | - 한국어 (ko-KO)
42 | - português (pt-BR & pt-PT)
43 | - 中文 (zh-CN)
44 |
45 | The guide is maintained by [OWASP][owasp],
46 | refer to the [project page][project] for further information.
47 |
48 | ### Sections of the Guide
49 |
50 | * Introduction
51 | * Secure Coding Practices Checklist
52 | * Software Security Principles Overview
53 | * Glossary of important terminology
54 | * Links to useful resources
55 |
56 | ### Other materials
57 | * [Project pamphlet][flyer]
58 | * [Project presentation][presentation]
59 | * [Slide deck][deck] - presented by Keith Turpin on OWASP AppSec USA 2010
60 | * [Feedback and revisions history][revisions]
61 |
62 | -----
63 |
64 | #### Feedback and Participation
65 |
66 | We hope you find the OWASP Secure Coding Practices Quick Reference Guide Project
67 | useful. Please contribute to this project by adding your comments, questions,
68 | and suggestions using the [change request][change] form.
69 | The Secure Coding Practices Guide is international,
70 | if you would like to provide additional translations
71 | then we can provide the directory framework to support this.
72 |
73 | The content has been migrated from the orginal `doc` format to markdown,
74 | following [pandoc's markdown format][pandoc-format].
75 | We welcome additions and corrections to the existing documents;
76 | create a [pull request][pull-request] and we will review and accept your changes.
77 |
78 | #### Related Projects
79 |
80 | * [Go programming language secure coding practices guide][owaspgoscp]
81 | * [OWASP developer guide][owaspdevguide]
82 |
83 | #### Editors
84 |
85 | * [Gerardo Canedo][gerardo] (español)
86 | * [Paulo Silva][paulo] (português)
87 | * [Jon Gadsden][jon] (English)
88 |
89 | #### Project leaders
90 |
91 | * [Keith Turpin][keith]
92 | * [Jon Gadsden][jon]
93 |
94 | [keith]: mailto:Keith.Turpin@owasp.org
95 | [jon]: mailto:jon.gadsden@owasp.org
96 | [gerardo]: mailto:gerardo.canedo@owasp.org
97 | [paulo]: mailto:paulo.silva@owasp.org
98 | [change]: https://github.com/OWASP/secure-coding-practices-quick-reference-guide/issues/new?assignees=&labels=enhancement&template=request.md&title=
99 | [deck]: https://github.com/OWASP/secure-coding-practices-quick-reference-guide/blob/main/materials/Secure_Coding_Practices_Quick_Ref_5.ppt
100 | [flyer]: https://github.com/OWASP/secure-coding-practices-quick-reference-guide/blob/main/materials/Flyer_Secure_Coding_Practices_Quick_Reference_Guide_V2.pdf
101 | [latest]: https://github.com/OWASP/secure-coding-practices-quick-reference-guide/releases/tag/v2.0.1
102 | [owasp]: https://owasp.org/
103 | [pandoc-format]: https://garrettgman.github.io/rmarkdown/authoring_pandoc_markdown.html#pandoc_markdown
104 | [presentation]: https://github.com/OWASP/secure-coding-practices-quick-reference-guide/blob/main/materials/Secure_Coding_Practices_Quick_Ref_6.ppt
105 | [project]: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/
106 | [pull-request]: https://github.com/OWASP/secure-coding-practices-quick-reference-guide/issues/new?assignees=&labels=enhancement&template=request.md&title=
107 | [revisions]: https://github.com/OWASP/secure-coding-practices-quick-reference-guide/blob/main/materials/SCP-QRG_Revisions_History.xls
108 | [owaspdevguide]: https://owasp.org/www-project-developer-guide/
109 | [owaspgoscp]: https://owasp.org/www-project-go-secure-coding-practices-guide/
110 | [owaspscpqrg]: https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/
111 | [this]: https://github.com/OWASP/secure-coding-practices-quick-reference-guide
112 |
113 |
--------------------------------------------------------------------------------
/SECURITY.md:
--------------------------------------------------------------------------------
1 | ## Security Policy
2 |
3 | This project is built on markdown which is used to create various binary files such as `.pdf` and `epub`.
4 | It is improbable but not impossible that a malicious actor could somehow embed malware in the markdown or subvert the document creation process.
5 | If you find anything suspicious in either the markdown or pipeline scripts then let us know ASAP and we will fix it as a priority.
6 |
7 | Ideally open a [security advisory][advisory] and this will be provided only to the project's admins in strict confidence.
8 |
9 | Alternatively send an encrypted email to [Jon Gadsden][mail] to start the secure disclosure process.
10 |
11 | [advisory]: https://github.com/OWASP/secure-coding-practices-quick-reference-guide/security/advisories/new
12 | [mail]: https://flowcrypt.com/me/jongadsden
13 |
--------------------------------------------------------------------------------
/draft/en/us/01-introduction/01-front.markdown:
--------------------------------------------------------------------------------
1 | {width="3.0in"}
2 |
3 | # OWASP Secure Coding Practices
4 |
5 | ## Quick Reference Guide
6 |
--------------------------------------------------------------------------------
/draft/en/us/01-introduction/02-toc.markdown:
--------------------------------------------------------------------------------
1 | ## Table of Contents
2 |
3 | 1. [Introduction](#introduction)
4 |
5 | 2. [Secure Coding Practices Checklist](#secure-coding-practices-checklist)
6 |
7 | 1. [Input validation](#input-validation)
8 |
9 | 2. [Output encoding](#output-encoding)
10 |
11 | 3. [Authentication and password management](#authentication-and-password-management)
12 |
13 | 4. [Session management](#session-management)
14 |
15 | 5. [Access control](#access-control)
16 |
17 | 6. [Cryptographic practices](#cryptographic-practices)
18 |
19 | 7. [Error handling and logging](#error-handling-and-logging)
20 |
21 | 8. [Data protection](#data-protection)
22 |
23 | 9. [Communication security](#communication-security)
24 |
25 | 10. [System configuration](#system-configuration)
26 |
27 | 11. [Database security](#database-security)
28 |
29 | 12. [File management](#file-management)
30 |
31 | 13. [Memory management](#memory-management)
32 |
33 | 14. [General coding practices](#general-coding-practices)
34 |
35 | [Appendix A: Software Security and Risk Principles Overview](#appendix-a-software-security-and-risk-principles-overview)
36 |
37 | [Appendix B: Glossary](#appendix-b-glossary)
38 |
39 | [Appendix C: External References](#appendix-c-external-references)
40 |
--------------------------------------------------------------------------------
/draft/en/us/01-introduction/04-copyright.markdown:
--------------------------------------------------------------------------------
1 | **Copyright and License**
2 |
3 | Copyright © 2010-2023 The OWASP Foundation.
4 |
5 | This document is released under the
6 | Creative Commons Attribution ShareAlike 4.0 International [(CC BY-SA 4.0)][CC-BY-SA-4.0] license.
7 | For any reuse or distribution, you must make clear to others the license terms of this work.
8 |
9 | [CC-BY-SA-4.0]: https://creativecommons.org/licenses/by-sa/4.0/deed.en_US
10 |
11 | \newpage
12 |
--------------------------------------------------------------------------------
/draft/en/us/01-introduction/05-introduction.markdown:
--------------------------------------------------------------------------------
1 | # Introduction
2 |
3 | This technology agnostic document defines a set of general software
4 | security coding practices, in a checklist format, that can be integrated
5 | into the software development lifecycle. Implementation of these
6 | practices will mitigate most common software vulnerabilities.
7 |
8 | Generally, it is much less expensive to build secure software than to
9 | correct security issues after the software package has been completed,
10 | not to mention the costs that may be associated with a security breach.
11 |
12 | Securing critical software resources is more important than ever as the
13 | focus of attackers has steadily moved toward the application layer. A
14 | 2009 SANS study found that attacks against web applications
15 | constitute more than 60% of the total attack attempts observed on the
16 | Internet.
17 |
18 | When utilizing this guide, development teams should start by assessing
19 | the maturity of their secure software development lifecycle and the
20 | knowledge level of their development staff. Since this guide does not
21 | cover the details of how to implement each coding practice, developers
22 | will either need to have the prior knowledge or have sufficient
23 | resources available that provide the necessary guidance. This guide
24 | provides coding practices that can be translated into coding
25 | requirements without the need for the developer to have an in depth
26 | understanding of security vulnerabilities and exploits. However, other
27 | members of the development team should have the responsibility, adequate
28 | training, tools and resources to validate that the design and
29 | implementation of the entire system is secure.
30 |
31 | A glossary of important terms in this document is provided in appendix B.
32 |
33 | Guidance on implementing a secure software development framework is
34 | beyond the scope of this paper, however the following additional general
35 | practices and resources are recommended:
36 |
37 | - Clearly define roles and responsibilities
38 |
39 | - Provide development teams with adequate software security training
40 |
41 | - Implement a secure software development lifecycle
42 |
43 | - Establish secure coding standards
44 |
45 | - [OWASP Development Guide][guide] Project
46 |
47 | - Build a re-usable object library
48 |
49 | - [OWASP Enterprise Security API][esapi] (ESAPI) Project
50 |
51 | - Verify the effectiveness of security controls
52 |
53 | - [OWASP Application Security Verification Standard][asvs] (ASVS) Project
54 |
55 | - Establish secure outsourced development practices including defining
56 | security requirements and verification methodologies in both the
57 | request for proposal (RFP) and contract.
58 |
59 |
60 | [asvs]: https://owasp.org/www-project-application-security-verification-standard/
61 | [esapi]: https://owasp.org/www-project-enterprise-security-api/
62 | [guide]: https://owasp.org/www-project-developer-guide/
63 |
64 | \newpage
65 |
--------------------------------------------------------------------------------
/draft/en/us/03-appendices/03-overview.markdown:
--------------------------------------------------------------------------------
1 | # Appendix A: Software Security and Risk Principles Overview
2 |
3 | Building secure software requires a basic understanding of security
4 | principles. While a comprehensive review of security principles is
5 | beyond the scope of this guide, a quick overview is provided.
6 |
7 | The goal of software security is to maintain the
8 | confidentiality, integrity, and availability of information resources in order to
9 | enable successful business operations.
10 | This goal is accomplished through the implementation of security controls.
11 | This guide focuses on the technical controls specific to
12 | mitigating the occurrence of common software vulnerabilities.
13 | While the primary focus is web applications and their supporting infrastructure,
14 | most of the guidance can be applied to any software deployment platform.
15 |
16 | It is helpful to understand what is meant by risk, in order to protect
17 | the business from unacceptable risks associated with its reliance on
18 | software. Risk is a combination of factors that threaten the success of
19 | the business. This can be described conceptually as follows: a threat
20 | agent interacts with a system, which may have a vulnerability that can be
21 | exploited in order to cause an impact. While
22 | this may seem like an abstract concept, think of it this way: a car
23 | burglar (threat agent) goes through a parking lot checking cars (the
24 | system) for unlocked doors (the vulnerability) and when they find one,
25 | they open the door (the exploit) and take whatever is inside (the
26 | impact). All of these factors play a role in secure software
27 | development.
28 |
29 | There is a fundamental difference between the approach taken by a
30 | development team and that taken by someone attacking an application. A
31 | development team typically approaches an application based on what it is
32 | intended to do. In other words, they are designing an application to
33 | perform specific tasks based on documented functional requirements and
34 | use cases. An attacker, on the other hand, is more interested in what an
35 | application can be made to do and operates on the principle that \"any
36 | action not specifically denied, is allowed\". To address this, some
37 | additional elements need to be integrated into the early stages of the
38 | software lifecycle. These new elements are [*security
39 | requirements*](#Security_Requirements) and [*abuse cases*](#Abuse_Case).
40 | This guide is designed to help with identifying high level security
41 | requirements and addressing many common abuse scenarios.
42 |
43 | It is important for web development teams to understand that client side
44 | controls like client based input validation, hidden fields and interface
45 | controls (e.g., pull downs and radio buttons), provide little if any
46 | security benefit. An attacker can use tools like client side web proxies
47 | (e.g. OWASP ZAP, Burp) or network packet capture tools (e.g.,
48 | WireShark) to analyze application traffic and submit custom built
49 | requests, bypassing the interface all together. Additionally, Flash,
50 | Java Applets and other client side objects can be decompiled and
51 | analyzed for flaws.
52 |
53 | Software security flaws can be introduced at any stage of the software
54 | development lifecycle, including:
55 |
56 | - Not identifying security requirements up front
57 |
58 | - Creating conceptual designs that have logic errors
59 |
60 | - Using poor coding practices that introduce technical vulnerabilities
61 |
62 | - Deploying the software improperly
63 |
64 | - Introducing flaws during maintenance or updating
65 |
66 | Furthermore, it is important to understand that software vulnerabilities
67 | can have a scope beyond the software itself. Depending on the nature of
68 | the software, the vulnerability and the supporting infrastructure, the
69 | impacts of a successful exploitation can include compromises to any or
70 | all of the following:
71 |
72 | - The software and its associated information
73 |
74 | - The operating systems of the associated servers
75 |
76 | - The backend database
77 |
78 | - Other applications in a shared environment
79 |
80 | - The user\'s system
81 |
82 | - Other software that the user interacts with
83 |
84 | \newpage
85 |
--------------------------------------------------------------------------------
/draft/en/us/03-appendices/05-glossary.markdown:
--------------------------------------------------------------------------------
1 | # Appendix B: Glossary
2 |
3 | **Abuse case:** Describes the intentional and
4 | unintentional misuses of the software. Abuse cases should challenge the
5 | assumptions of the system design.
6 |
7 | **Access control:** A set of controls that grant or deny a user, or
8 | other entity, access to a system resource. This is usually based on
9 | hierarchical roles and individual privileges within a role, but also
10 | includes system to system interactions.
11 |
12 | **Account disabling:** Account disabling after an established number of invalid
13 | login attempts (e.g., five attempts is common). The account must
14 | be disabled for a period of time sufficient to discourage brute
15 | force guessing of credentials, but not so long as to allow for a
16 | denial-of-service attack to be performed
17 |
18 | **Authentication:** A set of controls that are used to verify the
19 | identity of a user, or other entity, interacting with the software.
20 |
21 | Authentication failure responses should not indicate which part of
22 | the authentication data was incorrect. For example, instead of
23 | \"Invalid username\" or \"Invalid password\", just use \"Invalid
24 | username and/or password\" for both. Error responses must be truly
25 | identical in both display and source code
26 |
27 | **Availability:** A measure of a system\'s accessibility and usability.
28 |
29 | **Calculation errors:** Avoid calculation errors by understanding your programming
30 | language\'s underlying representation and how it interacts with
31 | numeric calculation. Pay close attention to byte size
32 | discrepancies, precision, signed/unsigned distinctions,
33 | truncation, conversion and casting between types, \"not-a-number\"
34 | calculations, and how your language handles numbers that are too
35 | large or too small for its underlying representation
36 |
37 | **Canonicalize:** To reduce various encodings
38 | and representations of data to a single simple form.
39 |
40 | **Communication security:** A set of controls that help ensure the
41 | software handles the sending and receiving of information in a secure
42 | manner.
43 |
44 | **Confidentiality:** To ensure that information is disclosed only to authorized parties.
45 |
46 | **Contextual output encoding:**
47 | Encoding output data based on how it will be utilized by the
48 | application. The specific methods vary depending on the way the output
49 | data is used. If the data is to be included in the response to the
50 | client, account for inclusion scenarios like: the body of an HTML
51 | document, an HTML attribute, within JavaScript, within a CSS or in a URL.
52 | You must also account for other use cases like SQL queries, XML and LDAP.
53 | Consider HTML entity encoding, but this may not work in all cases.
54 |
55 | **Cross Site Request Forgery (CSRF):**
56 | An external website or application forces a client to make an unintended
57 | request to another application that the client has an active session
58 | with. Applications are vulnerable when they use known, or predictable,
59 | URLs and parameters; and when the browser automatically transmits all
60 | required session information with each request to the vulnerable
61 | application.
62 |
63 | **Cryptographic practices:** A set of controls that ensure cryptographic
64 | operations within the application are handled securely.
65 |
66 | **Data protection:** A set of controls that help ensure the software
67 | handles the storing of information in a secure manner.
68 |
69 | **Database security:** A set of controls that ensure that software
70 | interacts with a database in a secure manner and that the database is
71 | configured securely.
72 |
73 | **Error handling and logging:** A set of practices that ensure the
74 | application handles errors safely and conducts proper event logging.
75 |
76 | **Exploit:** To take advantage of a vulnerability.
77 | Typically this is an intentional action designed to compromise the
78 | software\'s security controls by leveraging a vulnerability.
79 |
80 | **File management:** A set of controls that cover the interaction
81 | between the code and other system files.
82 |
83 | **General coding practices:** A set of controls that cover coding
84 | practices that do not fit easily into other categories.
85 |
86 | **Hazardous character:** Any character
87 | or encoded representation of a character that can effect the intended
88 | operation of the application or associated system by being interpreted
89 | to have a special meaning, outside the intended use of the character.
90 | These characters may be used to:
91 |
92 | * Altering the structure of existing code or statements
93 | * Inserting new unintended code
94 | * Altering paths
95 | * Causing unexpected outcomes from program functions or routines
96 | * Causing error conditions
97 | * Compromise downstream applications or systems
98 |
99 | If any potentially hazardous characters
100 | must be allowed as input, be sure that you implement additional
101 | controls like output encoding, secure task specific APIs and
102 | accounting for the utilization of that data throughout the
103 | application . Examples of common hazardous characters include:
104 | > \< \> \" \' % ( ) & + \\ \\\' \\\"
105 |
106 | * Check for new line characters (%0d, %0a, \\r, \\n)
107 | * Check for "dot-dot-slash\" (../ or ..\\) path alterations
108 | characters. In cases where UTF-8 extended character set
109 | encoding is supported, address alternate representation like:
110 | %c0%ae%c0%ae/
111 |
112 | **HTML eEntity encode:** The process of
113 | replacing certain ASCII characters with their HTML entity equivalents.
114 | For example, encoding would replace the less than character \"\<\" with
115 | the HTML equivalent \"<\". HTML entities are \'inert\' in most
116 | interpreters, especially browsers, which can mitigate certain client
117 | side attacks.
118 |
119 | **Impact:** A measure of the negative effect to the
120 | business that results from the occurrence of an undesired event; what
121 | would be the result of a vulnerability being exploited.
122 |
123 | **Input validation:** A set of controls that verify the properties of
124 | all input data matches what is expected by the application including
125 | types, lengths, ranges, acceptable character sets and does not include
126 | known hazardous characters.
127 |
128 | **Integrity:** The assurance that information is
129 | accurate, complete and valid, and has not been altered by an
130 | unauthorized action.
131 |
132 | **Log event data:** This should include the following:
133 |
134 | 1. Time stamp from a trusted system component
135 | 2. Severity rating for each event
136 | 3. Tagging of security relevant events, if they are mixed with other log entries
137 | 4. Identity of the account/user that caused the event
138 | 5. Source IP address associated with the request
139 | 6. Event outcome (success or failure)
140 | 7. Description of the event
141 |
142 | Implement monitoring to identify attacks against multiple user
143 | accounts, utilizing the same password. This attack pattern is used
144 | to bypass standard lockouts, when user IDs can be harvested or
145 | guessed.
146 |
147 | **Memory management:** A set of controls that address memory and buffer usage.
148 |
149 | **Mitigate:** Steps taken to reduce the severity of
150 | a vulnerability. These can include removing a vulnerability, making a
151 | vulnerability more difficult to exploit, or reducing the negative impact
152 | of a successful exploitation.
153 |
154 | **Multi-Factor Authentication (MFA):** An authentication process that requires
155 | the user to produce multiple distinct types of credentials.
156 | Typically this is based on something:
157 |
158 | * they have, for example a mobile/cell phone
159 | * something they know, for example a PIN
160 | * something they are, for example data from a biometric reader
161 |
162 | **Output encoding:** A set of controls addressing the use of encoding to
163 | ensure data output by the application is safe.
164 |
165 | **Parameterized queries / prepared statements:**
166 | Keeps the query and data separate through the use of
167 | placeholders. The query structure is defined with place holders, the SQL
168 | statement is sent to the database and prepared, and then the prepared
169 | statement is combined with the parameter values. The prevents the query
170 | from being altered, because the parameter values are combined with the
171 | compiled statement, not a SQL string.
172 |
173 | **Password complexity**: Password complexity requirements established by policy or
174 | regulation. Authentication credentials should be sufficient to
175 | withstand attacks that are typical of the threats in the deployed
176 | environment. (e.g., requiring the use of alphabetic as well as
177 | numeric and/or special characters).
178 |
179 | **Password length:** Password length requirements established by policy or
180 | regulation. Eight characters is commonly used, but 16 is better or
181 | consider the use of multi-word pass phrases
182 |
183 | **Persistent logins**: Disallow persistent logins and enforce periodic session
184 | terminations, even when the session is active. Especially for
185 | applications supporting rich network connections or connecting to
186 | critical systems. Termination times should support business
187 | requirements and the user should receive sufficient notification
188 | to mitigate negative impacts
189 |
190 | **Safe updates:** Method of updating the application from trusted sources.
191 | If the application utilizes automatic
192 | updates, then use cryptographic signatures for your code and
193 | ensure your download clients verify those signatures. Use
194 | encrypted channels to transfer the code from the host server
195 |
196 | **Sanitize data:** The process of making
197 | potentially harmful data safe through the use of data removal,
198 | replacement, encoding or escaping of the characters.
199 |
200 | **Security controls:** An action that
201 | mitigates a potential vulnerability and helps ensure that the software
202 | behaves only in the expected manner.
203 |
204 | **Security requirements:** A set of
205 | design and functional requirements that help ensure the software is
206 | built and deployed in a secure manner.
207 |
208 | **Sequential authentication:**
209 | When authentication data is requested on successive pages rather than
210 | being requested all at once on a single page.
211 |
212 | **Session management:** A set of controls that help ensure web
213 | applications handle HTTP sessions in a secure manner.
214 |
215 | Do not expose session identifiers in URLs, error messages or logs.
216 | Session identifiers should only be located in the HTTP cookie
217 | header. For example, do not pass session identifiers as GET
218 | parameters
219 |
220 | **State data:** When data or parameters are used,
221 | by the application or server, to emulate a persistent connection or
222 | track a client\'s status across a multi-request process or transaction.
223 |
224 | **System:** A generic term covering the operating
225 | systems, web server, application frameworks and related infrastructure.
226 |
227 | **System configuration:** A set of controls that help ensure the
228 | infrastructure components supporting the software are deployed securely.
229 |
230 | **Threat Agent:** Any entity which may have a
231 | negative impact on the system. This may be a malicious user who wants to
232 | compromise the system\'s security controls; however, it could also be an
233 | accidental misuse of the system or a more physical threat like fire or
234 | flood.
235 |
236 | **Trust boundaries:** Typically a trust
237 | boundary constitutes the components of the system under your direct
238 | control. All connections and data from systems outside of your direct
239 | control, including all clients and systems managed by other parties,
240 | should be consider untrusted and be validated at the boundary before
241 | allowing further system interaction.
242 |
243 | **Vulnerability:** A weakness that makes the system susceptible to attack or damage.
244 |
245 | \newpage
246 |
--------------------------------------------------------------------------------
/draft/en/us/03-appendices/07-references.markdown:
--------------------------------------------------------------------------------
1 | # Appendix C: External References
2 |
3 | ## Cited References
4 |
5 | - SANS CIS Controls version 8
6 |
7 | >
8 |
9 | - Web Application Security Consortium
10 |
11 | >
12 |
13 | - Common Weakness Enumeration (CWE)
14 |
15 | >
16 |
17 | - Department of Homeland Security: Build Security In Portal
18 |
19 | >
20 |
21 | - CERT Secure Coding
22 |
23 | >
24 |
25 | - MSDN Security Developer Center
26 |
27 | >
28 |
29 |
30 | ## Security Advisory Sites
31 |
32 | Useful resources to check for known vulnerabilities against supporting
33 | infrastructure and frameworks
34 |
35 | > Secunia Citrix Vulnerability List:
36 |
37 | -
38 |
39 | > Security Focus Vulnerability Search (archived):
40 |
41 | -
42 |
43 | > Common Vulnerability Enumeration:
44 |
45 | -
46 |
--------------------------------------------------------------------------------
/draft/en/us/README.md:
--------------------------------------------------------------------------------
1 | # English language (en-US) version
2 |
3 | We appreciate all kinds of [suggestions and corrections][issues] on this version
4 | of the Secure Coding Practices Quick Reference Guide
5 |
6 | During development manually create the PDF document from directory `en/us`:
7 |
8 | ```
9 | pandoc --output=OWASP_SCP_Quick_Reference_Guide.en-US.pdf title.pdf.yaml \
10 | 01-introduction/01-front.markdown \
11 | 01-introduction/02-toc.markdown \
12 | 01-introduction/04-copyright.markdown \
13 | 01-introduction/05-introduction.markdown \
14 | 02-checklist/05-checklist.markdown \
15 | 03-appendices/03-overview.markdown \
16 | 03-appendices/05-glossary.markdown \
17 | 03-appendices/07-references.markdown
18 | ```
19 |
20 | Similarly create the EBook:
21 |
22 | ```
23 | pandoc --output=OWASP_SCP_Quick_Reference_Guide.en-US.epub title.yaml \
24 | 01-introduction/01-front.markdown \
25 | 01-introduction/02-toc.markdown \
26 | 01-introduction/04-copyright.markdown \
27 | 01-introduction/05-introduction.markdown \
28 | 02-checklist/05-checklist.markdown \
29 | 03-appendices/03-overview.markdown \
30 | 03-appendices/05-glossary.markdown \
31 | 03-appendices/07-references.markdown
32 | ```
33 |
34 | There is a dependency on having a *tex installed that will provide pdflatex for the PDF output.
35 | For example with MacOS the command `brew install basictex` can be used.
36 |
37 | [issues]: https://github.com/OWASP/www-project-secure-coding-practices-quick-reference-guide/issues/new
38 |
--------------------------------------------------------------------------------
/draft/en/us/title.pdf.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: en-US
3 | author: Open Worldwide Application Security Project (OWASP)
4 | version: Draft
5 | date: February onwards 2023
6 | rights: Creative Commons Attribution ShareAlike 4.0 International (CC BY-SA 4.0)
7 | geometry: "left=3cm,right=2.5cm,top=2cm,bottom=2cm"
8 | header-includes: |
9 | \usepackage{fancyhdr}
10 | \pagestyle{fancy}
11 | \fancyhead{}
12 | \fancyhead[RE,RO]{February onwards 2023}
13 | \fancyfoot{}
14 | \fancyfoot[LE,LO]{Draft version}
15 | \fancyfoot[RE,RO]{\thepage}
16 | ...
17 |
--------------------------------------------------------------------------------
/draft/en/us/title.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: en-US
3 | title:
4 | - type: main
5 | text: Secure Coding Practices
6 | - type: subtitle
7 | text: Quick Reference Guide
8 | creator:
9 | - role: author
10 | text: Open Worldwide Application Security Project (OWASP)
11 | - role: editor
12 | text: Keith Turpin
13 | version: Draft
14 | date: February onwards 2023
15 | rights: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
16 | ...
17 |
--------------------------------------------------------------------------------
/draft/es/uy/01-introduction/01-front.markdown:
--------------------------------------------------------------------------------
1 | {width="3.0in"}
2 |
3 | # Prácticas de Codificación Segura OWASP
4 |
5 | ## Guía rápida de referencia
6 |
--------------------------------------------------------------------------------
/draft/es/uy/01-introduction/02-toc.markdown:
--------------------------------------------------------------------------------
1 | ## Índice
2 |
3 | 1. [Introducción](#introducción)
4 |
5 | 2. [Lista de Verificación de Prácticas de Codificación Segura](#lista-de-verificación-de-prácticas-de-codificación-segura)
6 |
7 | 1. [Validación de entradas](#validación-de-entradas)
8 |
9 | 2. [Codificación de salidas](#codificación-de-salidas)
10 |
11 | 3. [Gestión de autenticación y contraseñas](#gestión-de-autenticación-y-contraseñas)
12 |
13 | 4. [Gestión de sesiones](#gestión-de-sesiones)
14 |
15 | 5. [Control de acceso](#control-de-acceso)
16 |
17 | 6. [Prácticas critpográficas](#prácticas-critpográficas)
18 |
19 | 7. [Gestión de errores y registros (logs)](#gestión-de-errores-y-registros-logs)
20 |
21 | 8. [Protección de datos](#protección-de-datos)
22 |
23 | 9. [Seguridad en las comunicaciones](#seguridad-en-las-comunicaciones)
24 |
25 | 10. [Configuración de los sistemas](#configuración-de-los-sistemas)
26 |
27 | 11. [Seguridad de Base de Datos](#seguridad-de-base-de-datos)
28 |
29 | 12. [Gestión de archivos](#gestión-de-archivos)
30 |
31 | 13. [Gestión de memoria](#gestión-de-memoria)
32 |
33 | 14. [Practicas generales para la codificación](#practicas-generales-para-la-codificación)
34 |
35 | [Apéndice A: Visión General de la Seguridad en el Software y sus Principales Riesgos](#apéndice-a-visión-general-de-la-seguridad-en-el-software-y-sus-principales-riesgos)
36 |
37 | [Apéndice B: Glosario](#apéndice-b-glosario)
38 |
39 | [Apéndice C: Referencias externas](#apéndice-c-referencias-externas)
40 |
--------------------------------------------------------------------------------
/draft/es/uy/01-introduction/03-credits.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | **Sobre esta versión en español**
3 |
4 | Esta versión de la Guía de referencia rápida en español ha sido
5 | desarrollada como parte de las actividades del capítulo OWASP Uruguay
6 | para la comunidad de desarrolladores y seguridad informática de habla
7 | hispana.
8 |
9 | Participaron de esta traducción:
10 |
11 | * Canedo,Gerardo
12 |
13 |
--------------------------------------------------------------------------------
/draft/es/uy/01-introduction/04-copyright.markdown:
--------------------------------------------------------------------------------
1 | **Copyright y Licencia**
2 |
3 | Copyright © 2010-2023 The OWASP Foundation.
4 |
5 | Este documento se encuentra bajo la licencia
6 | Creative Commons Attribution Share Alike 4.0 International [(CC BY-SA 4.0)][CC-BY-SA-4.0].
7 | Para cualquier reutilización o distribución, debe de indicar claramente los términos de la licencia del presente trabajo.
8 |
9 | [CC-BY-SA-4.0]: https://creativecommons.org/licenses/by-sa/4.0/deed.es_ES
10 |
11 | \newpage
12 |
--------------------------------------------------------------------------------
/draft/es/uy/01-introduction/05-introduction.markdown:
--------------------------------------------------------------------------------
1 | # Introducción
2 |
3 | El presente documento define un conjunto de prácticas comunes de
4 | codificación de software, tecnológicamente agnósticas, en formato de
5 | lista de verificación con el fin de ser integrado al ciclo de
6 | desarrollo. La implementación de estas prácticas mitiga las
7 | vulnerabilidades más comunes del software.
8 |
9 | En términos generales, es mucho menos costoso construir software seguro
10 | que corregir problemas de seguridad cuando ha sido completado, sin
11 | mencionar los costos que pueden estar asociados a un brecha de seguridad.
12 |
13 | Asegurar recursos críticos de software se ha vuelto más importante que
14 | nunca debido a que el foco de los atacantes se ha desplazado hacia la
15 | capa de aplicación. Un estudio en 2009 de la SANS determinó que los
16 | ataques contra aplicaciones web constituyen más del 60% del total de
17 | intentos de ataque observados en la Internet.
18 |
19 | Utilizando la presente guía, el equipo de desarrollo debería comenzar
20 | evaluando el grado de madurez de su ciclo de desarrollo de software
21 | desde el punto de vista de la seguridad, así como el nivel de
22 | conocimiento de sus miembros. Dado que esta guía no cubre los detalles
23 | de implementación de las prácticas de codificación, los desarrolladores
24 | deben poseer previamente los conocimientos suficientes o bien tener
25 | disponibles recursos que los guíen. Esta guía provee prácticas de
26 | codificación que pueden ser traducidas en requerimientos de codificación sin
27 | la necesidad que el desarrollador posea un entendimiento profundo de
28 | vulnerabilidades de seguridad y exploits. Sin embargo, otros miembros
29 | del equipo de desarrollo deberían de poseer el entrenamiento adecuado,
30 | recursos y herramientas para ser responsables y validar que el diseño e
31 | implementación del sistema es seguro.
32 |
33 | En el apéndice B se presenta un glosario de los términos más importantes
34 | utilizados en este documento, incluyendo los cabezales de sección y las
35 | palabras resaltadas con *itálicas*.
36 |
37 | Se encuentra fuera del alcance de este documento la información
38 | detallada de cómo implementar un proceso de desarrollo de software
39 | seguro, sin embargo, se recomiendan las siguientes prácticas y recursos:
40 |
41 | - Definir claramente roles y responsabilidades.
42 |
43 | - Proveer al equipo de desarrollo capacitación suficiente en el área
44 | de seguridad del software.
45 |
46 | - Implementar un ciclo de desarrollo de software seguro.
47 |
48 | - Establecer estándares de codificación segura.
49 |
50 | - [OWASP Development Guide (inglés)][guide] Proyecto
51 |
52 | - Construir una biblioteca de objetos reutilizable.
53 |
54 | - [OWASP Enterprise Security API (inglés)][esapi] Proyecto ESAPI
55 |
56 | - Verificar la efectividad de los controles de seguridad.
57 |
58 | - [Estándar de Verificación de Seguridad en Aplicaciones de OWASP][asvs] Proyecto ASVS
59 |
60 | - Establecer prácticas de seguridad por fuera del ciclo de desarrollo,
61 | incluyendo requerimientos de seguridad y metodologías de
62 | verificación tanto en los request for proposal (RFP) como en los
63 | contratos.
64 |
65 | [asvs]: https://owasp.org/www-project-application-security-verification-standard/
66 | [esapi]: https://owasp.org/www-project-enterprise-security-api/
67 | [guide]: https://owasp.org/www-project-developer-guide/
68 |
69 | \newpage
70 |
--------------------------------------------------------------------------------
/draft/es/uy/03-appendices/03-overview.markdown:
--------------------------------------------------------------------------------
1 | # Apéndice A: Visión General de la Seguridad en el Software y sus Principales Riesgos
2 |
3 | La construcción de software seguro requiere una comprensión básica de
4 | los principios de seguridad. Si bien escapa al objetivo de esta guía una
5 | revisión exhaustiva de estos principios, se proporciona una visión general y
6 | rápida de los mismos.
7 |
8 | El objetivo de la seguridad en el software es el de mantener la
9 | confidencialidad, integridad y disponibilidad de los avtivos de información de
10 | modo de permitir el desarrollo exitoso de las operaciones del negocios. Este
11 | objetivo se consigue con la implementación de controles de seguridad.
12 | La presente guía pone foco en los controles técnicos específicos para
13 | mitigar la presencia de vulnerabilidades
14 | de ocurrencia frecuentes en el software. Si bien el foco principal está en
15 | las aplicaciones web y la infraestructura que las soporta, la mayoría de los
16 | lineamientos pueden aplicarse en cualquier plataforma de desarrollo de software.
17 |
18 | Es de gran utilidad comprender qué se entiende por un riesgo, con el fin
19 | de proteger al negocio de riesgos inaceptables derivados de su
20 | dependencia con el software. Un riesgo es una combinación de factores que
21 | amenazan el correcto funcionamiento del negocio.
22 | Puede ser definido conceptualmente como: un agente amenazante
23 | que interactúa con el sistema, que puede tener una
24 | vulnerabilidad a ser explotada de forma de generar un impacto.
25 | Si bien este puede resultar
26 | un concepto abstracto, se lo puede pensar de esta forma: un ladrón
27 | de autos (agente amenazante) recorre un estacionamiento verificando
28 | los vehículos (el sistema) en busca de una
29 | puerta sin trabar (la vulnerabilidad) y, cuando encuentra una, la abre
30 | (situación a ser explotada) y toma algo de dentro del mismo (el impacto).
31 | Todos estos factores juegan un rol en el desarrollo de software seguro.
32 |
33 | Existe una diferencia fundamental entre el enfoque que adopta un equipo
34 | de desarrollo y el que toma alguien que está atacando la aplicación. Un equipo
35 | de desarrollo adopta un enfoque basado en lo que tiene intenciones de realizar.
36 | En otras palabras, están diseñando una aplicación para que realice tareas
37 | específicas basándose en los requerimientos funcionales y casos de uso que han
38 | sido documentados. Un atacante, por otra parte, está más interesado en lo que
39 | puede llegar a hacerse con la aplicación en cuestión y opera bajo el principio
40 | de \"cualquier acción que no haya sido denegada de forma expresa, está permitida\".
41 | Para hacer frente a esto, se deben integrar algunos elementos adicionales en
42 | las etapas tempranas del ciclo de desarrollo de software. Estos nuevos elementos
43 | son los [*requerimientos de seguridad*](#Security_Requirements) y los
44 | [*casos de abuso*](#Abuse_Case). Esta guía fue creada para ayudar a identificar
45 | requerimientos de seguridad de alto nivel y hacer frente a muchos escenarios de
46 | abuso comunes.
47 |
48 | Es importante que los equipos de desarrollo web entiendan que los
49 | controles implementados en el cliente, tales como la validación de entrada de
50 | datos, campos ocultos y controles en la interfaz (por ejemplo: menús desplegables
51 | y botones de opción) brindan poco o nulo beneficio desde el punto de vista de
52 | la seguridad. Un atacante puede utilizar herramientas tales como proxies del
53 | lado del cliente (por ejemplo: OWASP ZAP o Burp) o herramientas de capturas de
54 | paquetes de red (como WireShark) para analizar el tráfico de la aplicación y
55 | enviar solitudes hechas a medida, sin siquiera pasar por la interfaz. Además,
56 | Applets de Java, programas Flash y otros objetos de ejecución del lado del
57 | cliente pueden ser descompilados y analizados en busca de fallas.
58 |
59 | Las fallas de seguridad en el software pueden introducirse en cualquiera
60 | de las etapas del ciclo de desarrollo del software, pudiendo:
61 |
62 | - No identificar requerimientos de seguridad desde el inicio.
63 |
64 | - Crear diseños conceptuales que contengan errores en la lógica.
65 |
66 | - Utilizar prácticas débiles de codificación que introduzcan vulnerabilidades
67 | técnicas.
68 |
69 | - Implantación del software de forma inapropiada.
70 |
71 | - Introducción de fallas durante el mantenimiento o actualización del producto.
72 |
73 | Es importante además entender que las vulnerabilidades del software
74 | pueden escapar los límites del software mismo. Dependiendo de la naturaleza del
75 | software, la vulnerabilidad y la infraestructura que le da soporte, el impacto
76 | del éxito en la explotación puede comprometer a una o todas las siguientes:
77 |
78 | - El software y su información asociada.
79 |
80 | - Los sistemas operativos de los servidores asociados.
81 |
82 | - La base de datos del backend.
83 |
84 | - Otras aplicaciones en el entorno compartido.
85 |
86 | - El sistema del usuario final.
87 |
88 | - Otro software con el que interactúe el usuario.
89 |
90 | \newpage
91 |
--------------------------------------------------------------------------------
/draft/es/uy/03-appendices/05-glossary.markdown:
--------------------------------------------------------------------------------
1 | # Apéndice B: Glosario
2 |
3 | **Agente de Amenaza:** Cualquier entidad que
4 | puede poseer un impacto negativo en el sistema. Puede ser desde un
5 | usuario malicioso que desea comprometer los controles de seguridad del
6 | sistema; sin embargo, también puede referirse al mal uso accidental del
7 | sistema o a una amenaza física como fuego o inundación.
8 |
9 | **Autenticación:** Conjunto de Controles utilizados para verificar la
10 | identidad de un usuario o entidad que interactúa con el software
11 |
12 | **Autenticación Multi-Factor:**
13 | Proceso de autenticación que le requiere al usuario producir múltiples y
14 | distintos tipos de credenciales. Típicamente son basados en:
15 |
16 | * algo que el usuario tiene, por ejemplo: una tarjeta inteligente
17 | * algo que conoce, por ejemplo: un pin
18 | * o algo que es, por ejemplo: datos provenientes de un lector biométrico
19 |
20 | **Autenticación secuencial:**
21 | Cuando los datos de autenticación son solicitados en páginas sucesivas e vez de
22 | ser solicitados todos de una sola vez en una única página.
23 |
24 | **Canonicalizar:**
25 | Convertir distintas codificaciones y representaciones de datos a una forma estándar predefinida.
26 |
27 | **Caracteres considerados peligrosos:**
28 | Cualquier carácter o representación codificada de un
29 | carácter que puede afectar la operación intencionada de la aplicación o
30 | sistema asociado por ser interpretado de una manera especial, fuera del
31 | uso intencionado del carácter. Estos caracteres pueden ser utilizados
32 | para:
33 |
34 | * Alterar la estructura de las sentencias o código existente
35 | * Insertar código inintencionado
36 | * Alterar caminos
37 | * Causar salidas inesperadas de rutinas o funciones
38 | * Causar condiciones de error
39 | * Obtener cualquiera de los efectos anteriores sobre el flujo de
40 | * aplicaciones o sistemas
41 |
42 | **Caso de Abuso:** Especificación de un tipo de
43 | interacción completa entre un sistema y uno o más actores, donde los
44 | resultados de la interacción son perjudiciales para el sistema, uno de
45 | los actores o uno de los interesados en el sistema
46 |
47 | **Codificación de Entidades HTML:**
48 | Proceso por el cual se reemplazan ciertos caracteres ASCII por
49 | sus entidades equivalentes en HTML. Por ejemplo: este proceso
50 | reemplazaría el carácter de menor \"\<\" con su equivalente en HTML
51 | \"<\". Las entidades HTML son \'inertes\' en la mayoría de los
52 | intérpretes, especialmente en los navegadores, pudiendo mitigar ciertos
53 | tipos de ataque en los clientes.
54 |
55 | **Codificación de Salida:** Conjunto de controles que apuntan al uso de
56 | una codificación para asegurar que los datos producidos por la
57 | aplicación son seguros.
58 |
59 | **Codificación de Salida Contextualizada:**
60 | Basar la codificación de salida en el uso que le dará
61 | la aplicación. El método específico varía dependiendo en la forma que
62 | será utilizado.
63 |
64 | **Confidencialidad:** Propiedad de la
65 | información por la que se garantiza que está accesible únicamente a
66 | entidades autorizadas.
67 |
68 | **Configuración del sistema:** Conjunto de controles que ayuda a
69 | asegurar que los componentes de infraestructura que brindan soporte al
70 | software fueron desplegados de manera segura.
71 |
72 | **Consultas parametrizadas (prepared statements):**
73 | Mantiene la consulta y los datos separados a través del
74 | uso de marcadores. La estructura de la consulta es definida utilizando
75 | marcadores, la consulta SQL es enviada a la base de datos y preparada,
76 | para luego ser combinada con los valores de los parámetros. Esto
77 | previene a las consultas de ser alteradas debido a que los valores de
78 | los parámetros son combinados con la consulta compilada y con el string
79 | de SQL.
80 |
81 | **Control de Acceso:** Un conjunto de controles que permiten o niegan el
82 | acceso a un recurso de un usuario o entidad dado.
83 |
84 | **Control de seguridad:** Acción que
85 | mitiga una vulnerabilidad potencial y ayuda a asegurar que el software
86 | se comporta únicamente de la forma esperada.
87 |
88 | **Datos de estado:** Cuando datos o parámetros
89 | son utilizados, ya sea por la aplicación o el servidor, emulando una
90 | conexión persiste o realizando el seguimiento del estado de un cliente a
91 | través de un proceso multi-pedido o transacción.
92 |
93 | **Datos del registro de log:**
94 | Debe incluir lo siguiente:
95 |
96 | 1. Time stamp obtenida de un componente confiable del sistema
97 | 2. Nivel de severidad para cada evento
98 | 3. Marcado de eventos relevantes a la seguridad, si se encuentran
99 | mezclados con otras entradas de la bitácora
100 | 4. Identidad de la cuenta/usuario que ha causado el evento
101 | 5. Dirección IP del origen asociado con el pedido
102 | 6. Resultado del evento (suceso o falla)
103 | 7. Descripción del evento
104 |
105 | **Disponibilidad:** Medida de Accesibilidad y Usabilidad del sistema.
106 |
107 | **Exploit:** Forma de tomar ventaja de una
108 | vulnerabilidad. Tipicamente se trata de una acción intencional diseñada
109 | para comprometer los controles de seguridad del software utilizando una
110 | vulnerabilidad.
111 |
112 | **Falsificación de petición en sitios cruzados (CSRF):**
113 | Una aplicación externa o sitio web fuerza a un cliente a
114 | realizar un pedido a otra aplicación en la que el cliente posee una
115 | sesión activa. Las Aplicaciones son vulnerables cuando utilizan
116 | parámetros o URLs predecibles o conocidas y cuando el navegador
117 | transmite automáticamente toda la información de sesión con cada pedido
118 | a la aplicación vulnerable. (Este ataque es discutido específicamente en
119 | este documento por ser extremadamente común y poco comprendido).
120 |
121 | **Frontera de Confianza:** Una frontera
122 | de confianza típicamente constituye los componentes del sistema bajo
123 | control directo. Todas las conexiones y datos prevenientes de sistemas
124 | fuera del control directo, incluyendo todos los clientes y sistemas
125 | gestionados por terceros, deben ser considerados no confiables y ser
126 | validados en la frontera, antes de permitir cualquier futura interacción
127 | con el sistema.
128 |
129 | **Gestión de Archivos:** Conjunto de controles que cubren la interacción
130 | entre el código y otro sistema de archivos.
131 |
132 | **Gestión de memoria:** Conjunto de controles de direccionamiento de
133 | memoria y uso de buffers.
134 |
135 | **Gestión de sesión:** Conjunto de controles que ayudan a asegurar que
136 | la aplicación web maneja las sesiones HTTP de forma segura.
137 |
138 | **Impacto:** Medida del efecto negativo en el
139 | negocio que resulta de la ocurrencia de un evento indeseado; pudiendo
140 | ser el resultado la explotación de una vulnerabilidad.
141 |
142 | **Integridad:** La seguridad de que la
143 | información es precisa, completa y válida, y no ha sido alterada por una
144 | acción no autorizada.
145 |
146 | **Manejo de Errores y Registro en bitácora:** Conjunto de prácticas que
147 | aseguran que las operaciones de manejo de errores y registro en bitácora
148 | se manejan correctamente.
149 |
150 | **Mitigar:** Pasos tomados para reducir la severidad
151 | de una vulnerabilidad. Estos pueden incluir remover una vulnerabilidad,
152 | hacer una vulnerabilidad más difícil de explotar, o reducir el impacto
153 | negativo de una explotación exitosa.
154 |
155 | **Prácticas Criptográficas:** Conjunto de controles que aseguran que las
156 | operaciones de criptografía dentro de la aplicación son manejadas de
157 | manera segura.
158 |
159 | **Prácticas de Codificación Generales:** Conjunto de controles que
160 | cubren las prácticas de codificación que no son parte otras categorías.
161 |
162 | **Protección de datos:** Conjunto de controles que ayudan a asegurar que
163 | el software maneja de forma segura el almacenamiento de la información.
164 |
165 | **Requerimiento de Seguridad:**
166 | Conjunto de requerimientos funcionales y de diseño que ayudan a asegurar
167 | que el software se construye y despliega de forma segura.
168 |
169 | **Sanitizar:** El proceso de hacer seguros datos
170 | potencialmente peligrosos a través de la utilización de remoción,
171 | reemplazo, codificación o \"escaping\" de los caracteres que lo
172 | componen.
173 |
174 | **Seguridad de Base de Datos:** Conjunto de controles que aseguran la
175 | interacción del software con la base de datos de una forma segura y que
176 | la base de datos se encuentra configurada de forma segura.
177 |
178 | **Seguridad de Comunicaciones:** Conjunto de controles que ayudan a
179 | asegurar que el software maneja de forma segura el envío y la recepción
180 | de datos.
181 |
182 | **Sistema:** Término genérico que cubre sistemas
183 | operativos, servidores web, frameworks de aplicaciones e infraestructura
184 | relacionada.
185 |
186 | **Validación de entrada:** Conjunto de controles que verifican que las
187 | propiedades de los datos ingresados coinciden con las esperadas por la
188 | aplicación, incluyendo tipos, largos, rangos, conjuntos de caracteres
189 | aceptados excluyendo caracteres peligrosos conocidos.
190 |
191 | **Vulnerabilidad:** Debilidad en un sistema que lo hace susceptible a ataque o daño.
192 |
193 | \newpage
194 |
--------------------------------------------------------------------------------
/draft/es/uy/03-appendices/07-references.markdown:
--------------------------------------------------------------------------------
1 | # Apéndice C: Referencias externas
2 |
3 | ## Referencia citada
4 |
5 | - SANS CIS Controls version 8
6 |
7 | >
8 |
9 | - Web Application Security Consortium
10 |
11 | >
12 |
13 | - Common Weakness Enumeration (CWE)
14 |
15 | >
16 |
17 | - Department of Homeland Security: Build Security In Portal
18 |
19 | >
20 |
21 | - CERT Secure Coding
22 |
23 | >
24 |
25 | - MSDN Security Developer Center
26 |
27 | >
28 |
29 | ## Sitios recomendados sobre Seguridad
30 |
31 | Fuentes útiles para verificar vulnerabilidades comunes sobre la
32 | infraestructura soporte y frameworks
33 |
34 | > Secunia Citrix Vulnerability List:
35 |
36 | -
37 |
38 | > Security Focus Vulnerability Search (archived):
39 |
40 | -
41 |
42 | > Common Vulnerability Enumeration:
43 |
44 | -
45 |
--------------------------------------------------------------------------------
/draft/es/uy/README.md:
--------------------------------------------------------------------------------
1 | # Traducción al español (es-UR)
2 |
3 | Agradecemos todo tipo de [sugerencias y correcciones][issues] sobre esta traducción
4 | de la Guía Rápida de Prácticas de Codificación Segura
5 |
6 | Para generar el PDF, posicionado en el directorio `es/uy`:
7 |
8 | ```
9 | pandoc --output=OWASP_SCP_Quick_Reference_Guide.es-UY.pdf title.pdf.yaml \
10 | 01-introduction/01-front.markdown \
11 | 01-introduction/02-toc.markdown \
12 | 01-introduction/03-credits.markdown \
13 | 01-introduction/04-copyright.markdown \
14 | 01-introduction/05-introduction.markdown \
15 | 02-checklist/05-checklist.markdown \
16 | 03-appendices/03-overview.markdown \
17 | 03-appendices/05-glossary.markdown \
18 | 03-appendices/07-references.markdown
19 | ```
20 |
21 | De forma similar, para generar el EBook:
22 |
23 | ```
24 | pandoc --output=OWASP_SCP_Quick_Reference_Guide.es-UY.epub title.yaml \
25 | 01-introduction/01-front.markdown \
26 | 01-introduction/02-toc.markdown \
27 | 01-introduction/03-credits.markdown \
28 | 01-introduction/04-copyright.markdown \
29 | 01-introduction/05-introduction.markdown \
30 | 02-checklist/05-checklist.markdown \
31 | 03-appendices/03-overview.markdown \
32 | 03-appendices/05-glossary.markdown \
33 | 03-appendices/07-references.markdown
34 | ```
35 |
36 | Es necesario poseer instalada una dependencia *tex para la correcta generación del formato PDF.
37 | Por ejemplo, en MacOS puede ser utilizado el comando `brew install basictex`.
38 |
39 | [issues]: https://github.com/OWASP/www-project-secure-coding-practices-quick-reference-guide/issues/new
40 |
--------------------------------------------------------------------------------
/draft/es/uy/title.pdf.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: es-UY
3 | author: Open Worldwide Application Security Project (OWASP)
4 | version: 2.0.1
5 | date: Febrero 2023
6 | rights: Creative Commons Attribution ShareAlike 4.0 International (CC BY-SA 4.0)
7 | geometry: "left=3cm,right=2.5cm,top=2cm,bottom=2cm"
8 | header-includes: |
9 | \usepackage{fancyhdr}
10 | \pagestyle{fancy}
11 | \fancyhead{}
12 | \fancyhead[RE,RO]{Febrero 2023}
13 | \fancyfoot{}
14 | \fancyfoot[LE,LO]{Versión 2.0.1}
15 | \fancyfoot[RE,RO]{\thepage}
16 | ...
17 |
--------------------------------------------------------------------------------
/draft/es/uy/title.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: es-UY
3 | title:
4 | - type: main
5 | text: Prácticas de codificación segura
6 | - type: subtitle
7 | text: Guía rápida de referencia
8 | creator:
9 | - role: author
10 | text: Open Worldwide Application Security Project (OWASP)
11 | - role: editor
12 | text: Keith Turpin
13 | - role: translator
14 | text: Gerardo Canedo
15 | version: 2.0.1
16 | date: Febrero 2023
17 | rights: Creative Commons Attribution ShareAlike 4.0 International (CC BY-SA 4.0)
18 | ...
19 |
--------------------------------------------------------------------------------
/images/OWASP-logo.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/OWASP/secure-coding-practices-quick-reference-guide/7f87f86a39168b5d7c509c03fe107d8da893b36b/images/OWASP-logo.jpg
--------------------------------------------------------------------------------
/materials/Flyer_Secure_Coding_Practices_Quick_Reference_Guide_V2.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/OWASP/secure-coding-practices-quick-reference-guide/7f87f86a39168b5d7c509c03fe107d8da893b36b/materials/Flyer_Secure_Coding_Practices_Quick_Reference_Guide_V2.pdf
--------------------------------------------------------------------------------
/materials/SCP-QRG_Revisions_History.xls:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/OWASP/secure-coding-practices-quick-reference-guide/7f87f86a39168b5d7c509c03fe107d8da893b36b/materials/SCP-QRG_Revisions_History.xls
--------------------------------------------------------------------------------
/materials/Secure_Coding_Practices_Quick_Ref_5.ppt:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/OWASP/secure-coding-practices-quick-reference-guide/7f87f86a39168b5d7c509c03fe107d8da893b36b/materials/Secure_Coding_Practices_Quick_Ref_5.ppt
--------------------------------------------------------------------------------
/materials/Secure_Coding_Practices_Quick_Ref_6.ppt:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/OWASP/secure-coding-practices-quick-reference-guide/7f87f86a39168b5d7c509c03fe107d8da893b36b/materials/Secure_Coding_Practices_Quick_Ref_6.ppt
--------------------------------------------------------------------------------
/v2/en/us/01-introduction/01-front.markdown:
--------------------------------------------------------------------------------
1 | {width="3.0in"}
2 |
3 | # OWASP Secure Coding Practices
4 |
5 | ## Quick Reference Guide
6 |
--------------------------------------------------------------------------------
/v2/en/us/01-introduction/02-toc.markdown:
--------------------------------------------------------------------------------
1 | # Table of Contents {#table-of-contents .TOC-Heading}
2 |
3 | [Introduction](#introduction)
4 |
5 | [Secure Coding Practices Checklist](#secure-coding-practices-checklist)
6 |
7 | [Input Validation](#input-validation)
8 |
9 | [Output Encoding](#output-encoding)
10 |
11 | [Authentication and Password Management](#authentication-and-password-management)
12 |
13 | [Session Management](#session-management)
14 |
15 | [Access Control](#access-control)
16 |
17 | [Cryptographic Practices](#cryptographic-practices)
18 |
19 | [Error Handling and Logging](#error-handling-and-logging)
20 |
21 | [Data Protection](#data-protection)
22 |
23 | [Communication Security](#communication-security)
24 |
25 | [System Configuration](#system-configuration)
26 |
27 | [Database Security](#database-security)
28 |
29 | [File Management](#file-management)
30 |
31 | [Memory Management](#memory-management)
32 |
33 | [General Coding Practices](#general-coding-practices)
34 |
35 | [Appendix A: Software Security and Risk Principles Overview](#software-security-and-risk-principles-overview)
36 |
37 | [Appendix B: Glossary](#glossary)
38 |
39 | [Appendix C: External References](#external-references)
40 |
--------------------------------------------------------------------------------
/v2/en/us/01-introduction/04-copyright.markdown:
--------------------------------------------------------------------------------
1 | **Copyright and License**
2 |
3 | Copyright © 2010-2023 The OWASP Foundation.
4 |
5 | This document is released under the
6 | Creative Commons Attribution ShareAlike 4.0 International [(CC BY-SA 4.0)][CC-BY-SA-4.0] license.
7 | For any reuse or distribution, you must make clear to others the license terms of this work.
8 |
9 | [CC-BY-SA-4.0]: https://creativecommons.org/licenses/by-sa/4.0/deed.en_US
10 |
--------------------------------------------------------------------------------
/v2/en/us/01-introduction/05-introduction.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Introduction {#introduction .list-paragraph}
3 |
4 | This technology agnostic document defines a set of general software
5 | security coding practices, in a checklist format, that can be integrated
6 | into the software development lifecycle. Implementation of these
7 | practices will mitigate most common software vulnerabilities.
8 |
9 | Generally, it is much less expensive to build secure software than to
10 | correct security issues after the software package has been completed,
11 | not to mention the costs that may be associated with a security breach.
12 |
13 | Securing critical software resources is more important than ever as the
14 | focus of attackers has steadily moved toward the application layer. A
15 | 2009 SANS study found that attacks against web applications
16 | constitute more than 60% of the total attack attempts observed on the
17 | Internet.
18 |
19 | When utilizing this guide, development teams should start by assessing
20 | the maturity of their secure software development lifecycle and the
21 | knowledge level of their development staff. Since this guide does not
22 | cover the details of how to implement each coding practice, developers
23 | will either need to have the prior knowledge or have sufficient
24 | resources available that provide the necessary guidance. This guide
25 | provides coding practices that can be translated into coding
26 | requirements without the need for the developer to have an in depth
27 | understanding of security vulnerabilities and exploits. However, other
28 | members of the development team should have the responsibility, adequate
29 | training, tools and resources to validate that the design and
30 | implementation of the entire system is secure.
31 |
32 | A glossary of important terms in this document, including section
33 | headings and words shown in *italics*, is provided in appendix B.
34 |
35 | Guidance on implementing a secure software development framework is
36 | beyond the scope of this paper, however the following additional general
37 | practices and resources are recommended:
38 |
39 | - Clearly define roles and responsibilities
40 |
41 | - Provide development teams with adequate software security training
42 |
43 | - Implement a secure software development lifecycle
44 |
45 | - Establish secure coding standards
46 |
47 | - [OWASP Development Guide][guide] Project
48 |
49 | - Build a re-usable object library
50 |
51 | - [OWASP Enterprise Security API][esapi] (ESAPI) Project
52 |
53 | - Verify the effectiveness of security controls
54 |
55 | - [OWASP Application Security Verification Standard][asvs] (ASVS) Project
56 |
57 | - Establish secure outsourced development practices including defining
58 | security requirements and verification methodologies in both the
59 | request for proposal (RFP) and contract.
60 |
61 |
62 | [asvs]: https://owasp.org/www-project-application-security-verification-standard/
63 | [esapi]: https://owasp.org/www-project-enterprise-security-api/
64 | [guide]: https://owasp.org/www-project-developer-guide/
65 |
--------------------------------------------------------------------------------
/v2/en/us/03-appendices/03-overview.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Appendix A: Software Security and Risk Principles Overview {#software-security-and-risk-principles-overview .list-paragraph}
3 |
4 | Building secure software requires a basic understanding of security
5 | principles. While a comprehensive review of security principles is
6 | beyond the scope of this guide, a quick overview is provided.
7 |
8 | The goal of software security is to maintain the
9 | *[confidentiality](#Confidentiality), [integrity](#Integrity)*, and
10 | [*availability*](#Availability) of information resources in order to
11 | enable successful business operations. This goal is accomplished through
12 | the implementation of [*security controls*](#Security_Controls). This
13 | guide focuses on the technical controls specific to
14 | [*mitigating*](#Mitigate) the occurrence of common software
15 | [*vulnerabilities*](#Vulnerability). While the primary focus is web
16 | applications and their supporting infrastructure, most of the guidance
17 | can be applied to any software deployment platform.
18 |
19 | It is helpful to understand what is meant by risk, in order to protect
20 | the business from unacceptable risks associated with its reliance on
21 | software. Risk is a combination of factors that threaten the success of
22 | the business. This can be described conceptually as follows: a [*threat
23 | agent*](#Threat_Agent) interacts with a [*system*](#System), which may
24 | have a *[vulnerability](#Vulnerability)* that can be
25 | [*exploited*](#Exploit) in order to cause an [*impact*](#Impact). While
26 | this may seem like an abstract concept, think of it this way: a car
27 | burglar (threat agent) goes through a parking lot checking cars (the
28 | system) for unlocked doors (the vulnerability) and when they find one,
29 | they open the door (the exploit) and take whatever is inside (the
30 | impact). All of these factors play a role in secure software
31 | development.
32 |
33 | There is a fundamental difference between the approach taken by a
34 | development team and that taken by someone attacking an application. A
35 | development team typically approaches an application based on what it is
36 | intended to do. In other words, they are designing an application to
37 | perform specific tasks based on documented functional requirements and
38 | use cases. An attacker, on the other hand, is more interested in what an
39 | application can be made to do and operates on the principle that \"any
40 | action not specifically denied, is allowed\". To address this, some
41 | additional elements need to be integrated into the early stages of the
42 | software lifecycle. These new elements are [*security
43 | requirements*](#Security_Requirements) and [*abuse cases*](#Abuse_Case).
44 | This guide is designed to help with identifying high level security
45 | requirements and addressing many common abuse scenarios.
46 |
47 | It is important for web development teams to understand that client side
48 | controls like client based input validation, hidden fields and interface
49 | controls (e.g., pull downs and radio buttons), provide little if any
50 | security benefit. An attacker can use tools like client side web proxies
51 | (e.g. OWASP ZAP, Burp) or network packet capture tools (e.g.,
52 | WireShark) to analyze application traffic and submit custom built
53 | requests, bypassing the interface all together. Additionally, Flash,
54 | Java Applets and other client side objects can be decompiled and
55 | analyzed for flaws.
56 |
57 | Software security flaws can be introduced at any stage of the software
58 | development lifecycle, including:
59 |
60 | - Not identifying security requirements up front
61 |
62 | - Creating conceptual designs that have logic errors
63 |
64 | - Using poor coding practices that introduce technical vulnerabilities
65 |
66 | - Deploying the software improperly
67 |
68 | - Introducing flaws during maintenance or updating
69 |
70 | Furthermore, it is important to understand that software vulnerabilities
71 | can have a scope beyond the software itself. Depending on the nature of
72 | the software, the vulnerability and the supporting infrastructure, the
73 | impacts of a successful exploitation can include compromises to any or
74 | all of the following:
75 |
76 | - The software and its associated information
77 |
78 | - The operating systems of the associated servers
79 |
80 | - The backend database
81 |
82 | - Other applications in a shared environment
83 |
84 | - The user\'s system
85 |
86 | - Other software that the user interacts with
87 |
--------------------------------------------------------------------------------
/v2/en/us/03-appendices/05-glossary.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Appendix B: Glossary {#glossary .list-paragraph}
3 |
4 | []{#Abuse_Case .anchor}**Abuse Case:** Describes the intentional and
5 | unintentional misuses of the software. Abuse cases should challenge the
6 | assumptions of the system design.
7 |
8 | **Access Control:** A set of controls that grant or deny a user, or
9 | other entity, access to a system resource. This is usually based on
10 | hierarchical roles and individual privileges within a role, but also
11 | includes system to system interactions.
12 |
13 | **Authentication:** A set of controls that are used to verify the
14 | identity of a user, or other entity, interacting with the software.
15 |
16 | []{#Availability .anchor}**Availability:** A measure of a system\'s
17 | accessibility and usability.
18 |
19 | []{#Canonicalize .anchor}**Canonicalize:** To reduce various encodings
20 | and representations of data to a single simple form.
21 |
22 | **Communication Security:** A set of controls that help ensure the
23 | software handles the sending and receiving of information in a secure
24 | manner.
25 |
26 | []{#Confidentiality .anchor}**Confidentiality:** To ensure that
27 | information is disclosed only to authorized parties.
28 |
29 | []{#Contextual_Output_Encoding .anchor}**Contextual Output Encoding:**
30 | Encoding output data based on how it will be utilized by the
31 | application. The specific methods vary depending on the way the output
32 | data is used. If the data is to be included in the response to the
33 | client, account for inclusion scenarios like: the body of an HTML
34 | document, an HTML attribute, within JavaScript, within a CSS or in a
35 | URL. You must also account for other use cases like SQL queries, XML and
36 | LDAP.
37 |
38 | []{#Cross_Site_Request_Forgery .anchor}**Cross Site Request Forgery:**
39 | An external website or application forces a client to make an unintended
40 | request to another application that the client has an active session
41 | with. Applications are vulnerable when they use known, or predictable,
42 | URLs and parameters; and when the browser automatically transmits all
43 | required session information with each request to the vulnerable
44 | application.
45 |
46 | This is one of the only attacks specifically discussed in
47 | this document and is only included because the associated vulnerability
48 | is very common and poorly understood.
49 |
50 | **Cryptographic Practices:** A set of controls that ensure cryptographic
51 | operations within the application are handled securely.
52 |
53 | **Data Protection:** A set of controls that help ensure the software
54 | handles the storing of information in a secure manner.
55 |
56 | **Database Security:** A set of controls that ensure that software
57 | interacts with a database in a secure manner and that the database is
58 | configured securely.
59 |
60 | **Error Handling and Logging:** A set of practices that ensure the
61 | application handles errors safely and conducts proper event logging.
62 |
63 | []{#Exploit .anchor}**Exploit:** To take advantage of a vulnerability.
64 | Typically this is an intentional action designed to compromise the
65 | software\'s security controls by leveraging a vulnerability.
66 |
67 | **File Management:** A set of controls that cover the interaction
68 | between the code and other system files.
69 |
70 | **General Coding Practices:** A set of controls that cover coding
71 | practices that do not fit easily into other categories.
72 |
73 | []{#Hazardous_Character .anchor}**Hazardous Character:** Any character
74 | or encoded representation of a character that can effect the intended
75 | operation of the application or associated system by being interpreted
76 | to have a special meaning, outside the intended use of the character.
77 | These characters may be used to:
78 |
79 | > • Altering the structure of existing code or statements
80 | >
81 | > • Inserting new unintended code
82 | >
83 | > • Altering paths
84 | >
85 | > • Causing unexpected outcomes from program functions or routines
86 | >
87 | > • Causing error conditions
88 | >
89 | > • Having any of the above effects on down stream applications or
90 | > systems
91 |
92 | []{#HTML_Entity_Encode .anchor}**HTML Entity Encode:** The process of
93 | replacing certain ASCII characters with their HTML entity equivalents.
94 | For example, encoding would replace the less than character \"\<\" with
95 | the HTML equivalent \"<\". HTML entities are \'inert\' in most
96 | interpreters, especially browsers, which can mitigate certain client
97 | side attacks.
98 |
99 | []{#Impact .anchor}**Impact:** A measure of the negative effect to the
100 | business that results from the occurrence of an undesired event; what
101 | would be the result of a vulnerability being exploited.
102 |
103 | **Input Validation:** A set of controls that verify the properties of
104 | all input data matches what is expected by the application including
105 | types, lengths, ranges, acceptable character sets and does not include
106 | known hazardous characters.
107 |
108 | []{#Integrity .anchor}**Integrity:** The assurance that information is
109 | accurate, complete and valid, and has not been altered by an
110 | unauthorized action.
111 |
112 | []{#Log_Event_Data .anchor}**Log Event Data:** This should include the
113 | following:
114 |
115 | > 1\. Time stamp from a trusted system component
116 | >
117 | > 2\. Severity rating for each event
118 | >
119 | > 3\. Tagging of security relevant events, if they are mixed with other
120 | > log entries
121 | >
122 | > 4\. Identity of the account/user that caused the event
123 | >
124 | > 5\. Source IP address associated with the request
125 | >
126 | > 6\. Event outcome (success or failure)
127 | >
128 | > 7\. Description of the event
129 |
130 | **Memory Management:** A set of controls that address memory and buffer
131 | usage.
132 |
133 | []{#Mitigate .anchor}**Mitigate:** Steps taken to reduce the severity of
134 | a vulnerability. These can include removing a vulnerability, making a
135 | vulnerability more difficult to exploit, or reducing the negative impact
136 | of a successful exploitation.
137 |
138 | []{#Multi_Factor_Authentication .anchor}**Multi-Factor Authentication:**
139 | An authentication process that requires the user to produce multiple
140 | distinct types of credentials. Typically this is based on something:
141 |
142 | - they have, eg a smartcard
143 | - something they know, eg a PIN
144 | - something they are, eg data from a biometric reader
145 |
146 | **Output Encoding:** A set of controls addressing the use of encoding to
147 | ensure data output by the application is safe.
148 |
149 | []{#Parameterized_Queries .anchor}**Parameterized Queries / Prepared
150 | Statements:** Keeps the query and data separate through the use of
151 | placeholders. The query structure is defined with place holders, the SQL
152 | statement is sent to the database and prepared, and then the prepared
153 | statement is combined with the parameter values. The prevents the query
154 | from being altered, because the parameter values are combined with the
155 | compiled statement, not a SQL string.
156 |
157 | []{#Sanitize_Data .anchor}**Sanitize Data:** The process of making
158 | potentially harmful data safe through the use of data removal,
159 | replacement, encoding or escaping of the characters.
160 |
161 | []{#Security_Controls .anchor}**Security Controls:** An action that
162 | mitigates a potential vulnerability and helps ensure that the software
163 | behaves only in the expected manner.
164 |
165 | []{#Security_Requirements .anchor}**Security Requirements:** A set of
166 | design and functional requirements that help ensure the software is
167 | built and deployed in a secure manner.
168 |
169 | []{#Sequential_Authentication .anchor}**Sequential Authentication:**
170 | When authentication data is requested on successive pages rather than
171 | being requested all at once on a single page.
172 |
173 | **Session Management:** A set of controls that help ensure web
174 | applications handle HTTP sessions in a secure manner.
175 |
176 | []{#State_Data .anchor}**State Data:** When data or parameters are used,
177 | by the application or server, to emulate a persistent connection or
178 | track a client\'s status across a multi-request process or transaction.
179 |
180 | []{#System .anchor}**System:** A generic term covering the operating
181 | systems, web server, application frameworks and related infrastructure.
182 |
183 | **System Configuration:** A set of controls that help ensure the
184 | infrastructure components supporting the software are deployed securely.
185 |
186 | []{#Threat_Agent .anchor}**Threat Agent:** Any entity which may have a
187 | negative impact on the system. This may be a malicious user who wants to
188 | compromise the system\'s security controls; however, it could also be an
189 | accidental misuse of the system or a more physical threat like fire or
190 | flood.
191 |
192 | []{#Trust_Boundaries .anchor}**Trust Boundaries:** Typically a trust
193 | boundary constitutes the components of the system under your direct
194 | control. All connections and data from systems outside of your direct
195 | control, including all clients and systems managed by other parties,
196 | should be consider untrusted and be validated at the boundary, before
197 | allowing further system interaction.
198 |
199 | []{#Vulnerability .anchor}**Vulnerability:** A weakness that makes the
200 | system susceptible to attack or damage.
201 |
--------------------------------------------------------------------------------
/v2/en/us/03-appendices/07-references.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Appendix C: External References {#external-references .list-paragraph}
3 |
4 | ## Cited References
5 |
6 | - SANS CIS Controls version 8
7 |
8 | >
9 |
10 | - Web Application Security Consortium
11 |
12 | >
13 |
14 | - Common Weakness Enumeration (CWE)
15 |
16 | >
17 |
18 | - Department of Homeland Security: Build Security In Portal
19 |
20 | >
21 |
22 | - CERT Secure Coding
23 |
24 | >
25 |
26 | - MSDN Security Developer Center
27 |
28 | >
29 |
30 |
31 | ## Security Advisory Sites
32 |
33 | Useful resources to check for known vulnerabilities against supporting
34 | infrastructure and frameworks
35 |
36 | > Secunia Citrix Vulnerability List:
37 |
38 | -
39 |
40 | > Security Focus Vulnerability Search (archived):
41 |
42 | -
43 |
44 | > Common Vulnerability Enumeration:
45 |
46 | -
47 |
--------------------------------------------------------------------------------
/v2/en/us/README.md:
--------------------------------------------------------------------------------
1 | # English language (en-US) version
2 |
3 | We appreciate all kinds of [suggestions and corrections][issues] on this version
4 | of the Secure Coding Practices Quick Reference Guide
5 |
6 | During development manually create the PDF document from directory `en/us`:
7 |
8 | ```
9 | pandoc -o OWASP_SCP_Quick_Reference_Guide.en-US.pdf title.pdf.yaml \
10 | 01-introduction/01-front.markdown \
11 | 01-introduction/02-toc.markdown \
12 | 01-introduction/04-copyright.markdown \
13 | 01-introduction/05-introduction.markdown \
14 | 02-checklist/05-checklist.markdown \
15 | 03-appendices/03-overview.markdown \
16 | 03-appendices/05-glossary.markdown \
17 | 03-appendices/07-references.markdown
18 | ```
19 |
20 | Similarly create the EBook:
21 |
22 | ```
23 | pandoc -o OWASP_SCP_Quick_Reference_Guide.en-US.epub title.yaml \
24 | 01-introduction/01-front.markdown \
25 | 01-introduction/02-toc.markdown \
26 | 01-introduction/04-copyright.markdown \
27 | 01-introduction/05-introduction.markdown \
28 | 02-checklist/05-checklist.markdown \
29 | 03-appendices/03-overview.markdown \
30 | 03-appendices/05-glossary.markdown \
31 | 03-appendices/07-references.markdown
32 | ```
33 |
34 | There is a dependency on having a *tex installed that will provide pdflatex for the PDF output.
35 | For example with MacOS the command `brew install basictex` can be used.
36 |
37 | [issues]: https://github.com/OWASP/www-project-secure-coding-practices-quick-reference-guide/issues/new
38 |
--------------------------------------------------------------------------------
/v2/en/us/title.pdf.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: en-US
3 | author: Open Worldwide Application Security Project (OWASP)
4 | version: 2.0.1
5 | date: December 2022
6 | rights: Creative Commons Attribution ShareAlike 4.0 International (CC BY-SA 4.0)
7 | geometry: "left=3cm,right=2.5cm,top=2cm,bottom=2cm"
8 | header-includes: |
9 | \usepackage{fancyhdr}
10 | \pagestyle{fancy}
11 | \fancyhead{}
12 | \fancyhead[RE,RO]{December 2022}
13 | \fancyfoot{}
14 | \fancyfoot[LE,LO]{Version 2.0.1}
15 | \fancyfoot[RE,RO]{\thepage}
16 | ...
17 |
--------------------------------------------------------------------------------
/v2/en/us/title.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: en-US
3 | title:
4 | - type: main
5 | text: Secure Coding Practices
6 | - type: subtitle
7 | text: Quick Reference Guide
8 | creator:
9 | - role: author
10 | text: Open Worldwide Application Security Project (OWASP)
11 | - role: editor
12 | text: Keith Turpin
13 | version: 2.0.1
14 | date: December 2022
15 | rights: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
16 | ...
17 |
--------------------------------------------------------------------------------
/v2/es/uy/01-introduction/01-front.markdown:
--------------------------------------------------------------------------------
1 | {width="3.0in"}
2 |
3 | # Prácticas de Codificación Segura OWASP
4 |
5 | ## Guía rápida de referencia
6 |
--------------------------------------------------------------------------------
/v2/es/uy/01-introduction/02-toc.markdown:
--------------------------------------------------------------------------------
1 | # Índice {#table-of-contents .TOC-Heading}
2 |
3 | [Introducción](#introduction)
4 |
5 | [Lista de Verificación de Prácticas de Codificación Segura](#secure-coding-practices-checklist)
6 |
7 | [Validación de entradas](#input-validation)
8 |
9 | [Codificación de salidas](#output-encoding)
10 |
11 | [Gestión de autenticación y contraseñas](#authentication-and-password-management)
12 |
13 | [Gestión de sesiones](#session-management)
14 |
15 | [Control de acceso](#access-control)
16 |
17 | [Prácticas critpográficas](#cryptographic-practices)
18 |
19 | [Gestión de errores y registros (logs)](#error-handling-and-logging)
20 |
21 | [Protección de datos](#data-protection)
22 |
23 | [Seguridad en las comunicaciones](#communication-security)
24 |
25 | [Configuración de los sistemas](#system-configuration)
26 |
27 | [Seguridad de Base de Datos](#database-security)
28 |
29 | [Gestión de Archivos](#file-management)
30 |
31 | [Gestión de Memoria](#memory-management)
32 |
33 | [Practicas Generales para la Codificación](#general-coding-practices)
34 |
35 | [Apéndice A: Visión General de la Seguridad en el Software y sus Principales Riesgos](#software-security-and-risk-principles-overview)
36 |
37 | [Apéndice B: Glosario](#glossary)
38 |
39 | [Apéndice C: Referencias externas](#external-references)
40 |
--------------------------------------------------------------------------------
/v2/es/uy/01-introduction/03-credits.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | **Sobre esta versión en español**
3 |
4 | Esta versión de la Guía de referencia rápida en español ha sido
5 | desarrollada como parte de las actividades del capítulo OWASP Uruguay
6 | para la comunidad de desarrolladores y seguridad informática de habla
7 | hispana.
8 |
9 | Participaron de esta traducción:
10 |
11 | * Canedo,Gerardo
12 |
13 |
--------------------------------------------------------------------------------
/v2/es/uy/01-introduction/04-copyright.markdown:
--------------------------------------------------------------------------------
1 | **Copyright y Licencia**
2 |
3 | Copyright © 2010-2023 The OWASP Foundation.
4 |
5 | Este documento se encuentra bajo la licencia
6 | Creative Commons Attribution Share Alike 4.0 International [(CC BY-SA 4.0)][CC-BY-SA-4.0].
7 | Para cualquier reutilización o distribución, debe de indicar claramente los términos de la licencia del presente trabajo.
8 |
9 | [CC-BY-SA-4.0]: https://creativecommons.org/licenses/by-sa/4.0/deed.es_ES
10 |
--------------------------------------------------------------------------------
/v2/es/uy/01-introduction/05-introduction.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Introducción {#introduction .list-paragraph}
3 |
4 | El presente documento define un conjunto de prácticas comunes de
5 | codificación de software, tecnológicamente agnósticas, en formato de
6 | lista de verificación con el fin de ser integrado al ciclo de
7 | desarrollo. La implementación de estas prácticas mitiga las
8 | vulnerabilidades más comunes del software.
9 |
10 | En términos generales, es mucho menos costoso construir software seguro
11 | que corregir problemas de seguridad cuando ha sido completado, sin
12 | mencionar los costos que pueden estar asociados a un brecha de seguridad.
13 |
14 | Asegurar recursos críticos de software se ha vuelto más importante que
15 | nunca debido a que el foco de los atacantes se ha desplazado hacia la
16 | capa de aplicación. Un estudio en 2009 de la SANS determinó que los
17 | ataques contra aplicaciones web constituyen más del 60% del total de
18 | intentos de ataque observados en la Internet.
19 |
20 | Utilizando la presente guía, el equipo de desarrollo debería comenzar
21 | evaluando el grado de madurez de su ciclo de desarrollo de software
22 | desde el punto de vista de la seguridad, así como el nivel de
23 | conocimiento de sus miembros. Dado que esta guía no cubre los detalles
24 | de implementación de las prácticas de codificación, los desarrolladores
25 | deben poseer previamente los conocimientos suficientes o bien tener
26 | disponibles recursos que los guíen. Esta guía provee prácticas de
27 | codificación que pueden ser traducidas en requerimientos de codificación sin
28 | la necesidad que el desarrollador posea un entendimiento profundo de
29 | vulnerabilidades de seguridad y exploits. Sin embargo, otros miembros
30 | del equipo de desarrollo deberían de poseer el entrenamiento adecuado,
31 | recursos y herramientas para ser responsables y validar que el diseño e
32 | implementación del sistema es seguro.
33 |
34 | En el apéndice B se presenta un glosario de los términos más importantes
35 | utilizados en este documento, incluyendo los cabezales de sección y las
36 | palabras resaltadas con *itálicas*.
37 |
38 | Se encuentra fuera del alcance de este documento la información
39 | detallada de cómo implementar un proceso de desarrollo de software
40 | seguro, sin embargo, se recomiendan las siguientes prácticas y recursos:
41 |
42 | - Definir claramente roles y responsabilidades.
43 |
44 | - Proveer al equipo de desarrollo capacitación suficiente en el área
45 | de seguridad del software.
46 |
47 | - Implementar un ciclo de desarrollo de software seguro.
48 |
49 | - Establecer estándares de codificación segura.
50 |
51 | - [OWASP Development Guide (inglés)][guide] Proyecto
52 |
53 | - Construir una biblioteca de objetos reutilizable.
54 |
55 | - [OWASP Enterprise Security API (inglés)][esapi] Proyecto ESAPI
56 |
57 | - Verificar la efectividad de los controles de seguridad.
58 |
59 | - [Estándar de Verificación de Seguridad en Aplicaciones de OWASP][asvs] Proyecto ASVS
60 |
61 | - Establecer prácticas de seguridad por fuera del ciclo de desarrollo,
62 | incluyendo requerimientos de seguridad y metodologías de
63 | verificación tanto en los request for proposal (RFP) como en los
64 | contratos.
65 |
66 | [asvs]: https://owasp.org/www-project-application-security-verification-standard/
67 | [esapi]: https://owasp.org/www-project-enterprise-security-api/
68 | [guide]: https://owasp.org/www-project-developer-guide/
69 |
--------------------------------------------------------------------------------
/v2/es/uy/03-appendices/03-overview.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Apéndice A: Visión General de la Seguridad en el Software y sus Principales Riesgos {#software-security-and-risk-principles-overview .list-paragraph}
3 |
4 | La construcción de software seguro requiere una comprensión básica de
5 | los principios de seguridad. Si bien escapa al objetivo de esta guía una
6 | revisión exhaustiva de estos, se proporciona una visión general de los mismos.
7 |
8 | La meta de la seguridad en el software es el de mantener la
9 | [*confidencialidad*](#Confidentiality), [*integridad*](#Integrity) y
10 | [*disponibilidad*](#Availability) de los activos de información de
11 | modo de permitir el desarrollo exitoso de las operaciones del negocios. Esta
12 | meta se consigue con la implementación de [*controles de seguridad*](#Security_Controls).
13 | La presente guía pone foco en los controles técnicos específicos para
14 | [*mitigar*](#Mitigate) la ocurrencia de [*vulnerabilidades*](#Vulnerability)
15 | frecuentes en el software. Si bien el foco principal está en
16 | las aplicaciones web y la infraestructura que las soporta, la mayoría de los
17 | lineamientos pueden aplicarse en cualquier plataforma de desarrollo de software.
18 |
19 | Es de gran utilidad comprender qué se entiende por riesgo, con el fin
20 | de proteger al negocio de riesgos inaceptables derivados de su
21 | dependencia con el software. Un riesgo es una combinación de factores que
22 | amenazan el correcto funcionamiento del negocio.
23 | Puede ser definido conceptualmente como: un [*agente amenazante*](#Threat_Agent)
24 | que interactúa con el [*sistema*](#System), que puede tener una
25 | [*vulnerabilidad*](#Vulnerability) a ser [*explotada*](#Exploit) de
26 | forma de generar un [*impacto*](#Impact). Si bien este puede resultar
27 | un concepto abstracto, se lo puede pensar de esta forma: un ladrón
28 | de autos (agente amenazante) recorre un estacionamiento verificando
29 | los vehículos (el sistema) en busca de una
30 | puerta sin trabar (la vulnerabilidad) y, cuando encuentra una, la abre
31 | (explotación) y toma algo de dentro del mismo (el impacto).
32 | Todos estos factores juegan un rol en el desarrollo de software seguro.
33 |
34 | Existe una diferencia fundamental entre el enfoque que adopta un equipo
35 | de desarrollo y el que toma alguien que está atacando la aplicación. Un equipo
36 | de desarrollo adopta un enfoque basado en lo que tiene intenciones que el sistema realice.
37 | En otras palabras, están diseñando una aplicación para que realice tareas
38 | específicas basándose en los requerimientos funcionales y casos de uso que han
39 | sido documentados. Un atacante, por otra parte, está más interesado en lo que
40 | puede llegar a hacerse con la aplicación en cuestión y opera bajo el principio
41 | de \"cualquier acción que no haya sido denegada de forma expresa, está permitida\".
42 | Para hacer frente a esto, se deben integrar algunos elementos adicionales en
43 | las etapas tempranas del ciclo de desarrollo de software. Estos nuevos elementos
44 | son los [*requerimientos de seguridad*](#Security_Requirements) y los
45 | [*casos de abuso*](#Abuse_Case). Esta guía fue creada para ayudar a identificar
46 | requerimientos de seguridad de alto nivel y hacer frente a muchos escenarios de
47 | abuso comunes.
48 |
49 | Es importante que los equipos de desarrollo web entiendan que los
50 | controles implementados en el cliente, tales como la validación de entrada de
51 | datos, campos ocultos y controles en la interfaz (por ejemplo: menús desplegables
52 | y botones de opción) brindan poco o nulo beneficio desde el punto de vista de
53 | la seguridad. Un atacante puede utilizar herramientas tales como proxies del
54 | lado del cliente (por ejemplo: OWASP ZAP o Burp) o herramientas de capturas de
55 | paquetes de red (como WireShark) para analizar el tráfico de la aplicación y
56 | enviar solitudes hechas a medida, sin siquiera pasar por la interfaz. Además,
57 | Applets de Java, programas Flash y otros objetos de ejecución del lado del
58 | cliente pueden ser descompilados y analizados en busca de fallas.
59 |
60 | Las fallas de seguridad en el software pueden introducirse en cualquiera
61 | de las etapas del ciclo de desarrollo del software, pudiendo:
62 |
63 | - No identificar requerimientos de seguridad desde el inicio.
64 |
65 | - Crear diseños conceptuales que contengan errores en la lógica.
66 |
67 | - Utilizar prácticas débiles de codificación que introduzcan vulnerabilidades
68 | técnicas.
69 |
70 | - Implantación del software de forma inapropiada.
71 |
72 | - Introducción de fallas durante el mantenimiento o actualización del producto.
73 |
74 | Es importante además entender que las vulnerabilidades del software
75 | pueden escapar los límites del software mismo. Dependiendo de la naturaleza del
76 | software, la vulnerabilidad y la infraestructura que le da soporte, el impacto
77 | del éxito en la explotación puede comprometer a una o todas las siguientes:
78 |
79 | - El software y su información asociada.
80 |
81 | - Los sistemas operativos de los servidores que le dan soporte.
82 |
83 | - La base de datos del backend.
84 |
85 | - Otras aplicaciones en el entorno compartido.
86 |
87 | - El sistema informático del usuario final.
88 |
89 | - Otro software con el que interactúe el usuario.
90 |
--------------------------------------------------------------------------------
/v2/es/uy/03-appendices/05-glossary.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | ## Apéndice B: Glosario {#glossary .list-paragraph}
3 |
4 | []{##Threat_Agenta .anchor}**Agente de Amenaza:** Cualquier entidad que
5 | puede poseer un impacto negativo en el sistema. Puede ser desde un
6 | usuario malicioso que desea comprometer los controles de seguridad del
7 | sistema; sin embargo, también puede referirse al mal uso accidental del
8 | sistema o a una amenaza física como fuego o inundación.
9 |
10 | **Autenticación:** Conjunto de Controles utilizados para verificar la
11 | identidad de un usuario o entidad que interactúa con el software.
12 |
13 | []{#Multi_Factor_Authentication .anchor}**Autenticación Multi-Factor:**
14 | Proceso de autenticación que le requiere al usuario producir múltiples y
15 | distintos tipos de credenciales. Típicamente son basados en:
16 |
17 | > • algo que el usuario tiene, por ejemplo: una tarjeta inteligente
18 | > • algo que conoce, por ejemplo: un pin
19 | > • o algo que es, por ejemplo: datos provenientes de un lector biométrico
20 |
21 | []{#Sequential_Authentication .anchor}**Autenticación secuencial:** Cuando
22 | los datos de autenticación son solicitados en páginas sucesivas en vez de
23 | ser solicitados todos de una sola vez en una única página.
24 |
25 | []{#Canonicalize .anchor}**Canonicalizar:** Reducir las distintas
26 | codificaciones y representaciones de datos a una única forma simple.
27 |
28 | []{#Hazardous_Character .anchor}**Caracteres considerados peligrosos:**
29 | Cualquier carácter o representación codificada que pueda afectar al
30 | funcionamiento de la aplicación o del sistema asociado al ser interpretado
31 | (comportamiento ajeno al uso previsto del carácter). Estos caracteres pueden
32 | utilizarse para:
33 |
34 | > • Alterar la estructura de las sentencias o código existente.
35 | >
36 | > • Insertar nuevo código no deseado. >
37 | > • Alterar rutas.
38 | >
39 | > • Causar salidas inesperadas de rutinas o funciones.
40 | >
41 | > • Causar condiciones de error.
42 | >
43 | > • Obtener cualquiera de los efectos anteriores sobre el flujo de aplicaciones
44 | > o sistemas
45 |
46 | []{#Abuse_Case .anchor}**Caso de Abuso:** Describe los usos indebidos
47 | intencionados o no del software. Los casos de abuso deben cuestionar los
48 | supuestos del diseño del sistema.
49 |
50 | []{#HTML_Entity_Encode .anchor}**Codificación de Entidades HTML:** Proceso de
51 | sustitución de determinados caracteres ASCII por sus equivalentes en
52 | entidades HTML. Por ejemplo, la codificación sustituiría el carácter menor
53 | \"\<\" por su equivalente en HTML \"<\". Las entidades HTML son \"inertes\" en la mayoría de los intérpretes, especialmente en navegadores, por lo que puede mitigar ciertos ataques del lado del cliente.
54 |
55 | **Codificación de Salida:** Conjunto de controles que apuntan al uso de una
56 | codificación para asegurar que los datos producidos por la aplicación son
57 | seguros.
58 |
59 | []{#Contextual_Output_Encoding .anchor} **Codificación de Salida Contextualizada:**
60 | Codificación de los datos de salida en función de cómo serán utilizados
61 | por la aplicación. Los métodos específicos varían en función de la forma en
62 | que se utilizan los datos de salida. Si los datos se van a incluir en la
63 | respuesta al cliente, tenga en cuenta escenarios de inclusión como: el
64 | cuerpo de un documento HTML, un atributo HTML, dentro de JavaScript, dentro
65 | de CSS o en una URL. También debe tener en cuenta otros casos de uso como
66 | consultas SQL, XML y LDAP.
67 |
68 | []{#Confidentiality .anchor}**Confidencialidad:** Propiedad de la información
69 | por la que se garantiza que está accesible únicamente a entidades
70 | autorizadas.
71 |
72 | **Configuración del sistema:** Conjunto de controles que ayuda a asegurar que
73 | los componentes de infraestructura que brindan soporte al software fueron
74 | desplegados de manera segura.
75 |
76 | []{#Parameterized_Queries .anchor}
77 | **Consultas parametrizadas (prepared statements):** Mantiene la consulta
78 | y los datos separados a través del uso de marcadores. La estructura de la
79 | consulta es definida utilizando marcadores, la consulta SQL es enviada a la
80 | base de datos y preparada, para luego ser combinada con los valores de los
81 | parámetros. Esto previene a las consultas de ser alteradas debido a que los
82 | valores de los parámetros son combinados con la consulta compilada, no con
83 | la cadena de caracteres que representa al SQL.
84 |
85 | **Control de Acceso:** Conjunto de controles que permiten o deniegan a un
86 | usuario, u otra entidad, el acceso a un recurso del sistema. Suele basarse
87 | en roles jerárquicos y privilegios individuales dentro de un rol, pero
88 | también incluye las interacciones entre sistemas.
89 |
90 | []{#Security_Controls .anchor} **Control de seguridad:** Acción que mitiga una
91 | vulnerabilidad potencial y ayuda a asegurar que el software se comporta
92 | únicamente de la forma esperada.
93 |
94 | []{#State_Data .anchor} **Datos de estado:** Cuando son utilizados datos o
95 | parámetros, ya sea por la aplicación o el servidor, emulando una conexión
96 | persiste o realizando el seguimiento del estado de un cliente a través de
97 | un proceso multi-pedido o transacción.
98 |
99 | []{#Log_Event_Data .anchor}**Datos de registros (log):** Debe incluir lo siguiente:
100 |
101 | > 1\. Fecha-Hora obtenida de un componente confiable del sistema.
102 | >
103 | > 2\. Nivel de severidad para cada evento
104 | >
105 | > 3\. Etiquetado de eventos relevantes a la seguridad, si se encuentran
106 | > mezclados con otras entradas de la bitácora.
107 | >
108 | > 4\. Identidad de la cuenta/usuario que ha causado el evento.
109 | >
110 | > 5\. Dirección IP del origen asociado con el pedido.
111 | >
112 | > 6\. Resultado del evento (éxito o falla).
113 | >
114 | > 7\. Descripción del evento.
115 |
116 | []{#Availability .anchor} **Disponibilidad:** Medida de Accesibilidad y
117 | Usabilidad del sistema.
118 |
119 | []{#Exploit .anchor} **Exploit:** Forma de tomar ventaja de una vulnerabilidad.
120 | Tipicamente se trata de una acción intencional diseñada para comprometer
121 | los controles de seguridad del software utilizando una vulnerabilidad.
122 |
123 | []{#Cross_Site_Request_Forgery .anchor}
124 | **Falsificación de petición en sitios cruzados (CSRF):** Una aplicación
125 | externa o sitio web fuerza a un cliente a realizar un pedido a otra
126 | aplicación en la que el cliente posee una sesión activa. Las Aplicaciones
127 | son vulnerables cuando utilizan parámetros o URLs predecibles o conocidas y
128 | cuando el navegador transmite automáticamente toda la información de sesión
129 | con cada pedido a la aplicación vulnerable. (Este ataque es discutido
130 | específicamente en este documento por ser extremadamente común y poco
131 | comprendido).
132 |
133 | []{#Trust_Boundaries .anchor} **Frontera de Confianza:** Una frontera de
134 | confianza típicamente constituye los componentes del sistema bajo control
135 | directo. Todas las conexiones y datos prevenientes de sistemas fuera del
136 | control directo, incluyendo todos los clientes y sistemas gestionados por
137 | terceros, deben ser considerados no confiables y los datos provenientes de
138 | éstos deben ser validados en la frontera, antes de permitir cualquier
139 | futura interacción con el sistema.
140 |
141 | **Gestión de Archivos:** Conjunto de controles que cubren la interacción
142 | entre el código y otro sistema de archivos.
143 |
144 | **Gestión de memoria:** Conjunto de controles que cubren el uso de buffers y el
145 | direccionamiento de memoria.
146 |
147 | **Gestión de sesión:** Conjunto de controles que ayudan a asegurar que la
148 | aplicación web maneja las sesiones HTTP de forma segura.
149 |
150 | []{#Impact .anchor}**Impacto:** Medida del efecto negativo en el negocio que
151 | resulta de la ocurrencia de un evento indeseado; pudiendo ser el resultado
152 | la explotación de una vulnerabilidad.
153 |
154 | []{#Integrity .anchor}**Integridad:** La garantía de que la información es
155 | precisa, completa y válida, y no ha sido alterada por una acción no
156 | autorizada.
157 |
158 | **Manejo de Errores y Registro en bitácora:** Conjunto de prácticas que
159 | aseguran que las operaciones de manejo de errores y registro de eventos se
160 | gestionan correctamente.
161 |
162 | []{#Mitigate .anchor}**Mitigar:** Pasos tomados para reducir la severidad de
163 | una vulnerabilidad. Estos pueden incluir remover una vulnerabilidad, hacer
164 | una vulnerabilidad más difícil de explotar, o reducir el impacto negativo
165 | de una explotación exitosa.
166 |
167 | **Prácticas Criptográficas:** Conjunto de controles que aseguran que las
168 | operaciones de criptografía dentro de la aplicación son manejadas de manera
169 | segura.
170 |
171 | **Prácticas de Codificación Generales:** Conjunto de controles que cubren las
172 | prácticas de codificación que no son parte otras categorías.
173 |
174 | **Protección de datos:** Conjunto de controles que asegurar que el software
175 | interactúa con la base de datos de forma segura, además de que la base de
176 | datos se encuentre configurada de forma segura.
177 |
178 | []{#Security_Requirements .anchor} **Requerimiento de Seguridad:** Conjunto de
179 | requerimientos funcionales y de diseño que ayudan a asegurar que el
180 | software se construye y despliega de forma segura.
181 |
182 | []{#Sanitize_Data .anchor} **Sanitizar:** El proceso de hacer seguros datos
183 | potencialmente peligrosos a través de la utilización de eliminación,
184 | reemplazo, codificación o \"escapeo\" de los caracteres que lo componen.
185 |
186 | **Seguridad de Base de Datos:** Conjunto de controles que aseguran la
187 | interacción del software con la base de datos de una forma segura y que la
188 | base de datos se encuentra configurada de forma segura.
189 |
190 | **Seguridad en las Comunicaciones:** Conjunto de controles que ayudan a
191 | asegurar que el software maneja de forma segura el envío y la recepción de
192 | datos.
193 |
194 | []{#System .anchor}**Sistema:** Término genérico que cubre sistemas operativos,
195 | servidores web, frameworks de aplicaciones y la infraestructura
196 | relacionada.
197 |
198 | **Validación de entrada:** Conjunto de controles que verifican que las
199 | propiedades de los datos ingresados coinciden con las esperadas por la
200 | aplicación, incluyendo tipos, largos, rangos, conjuntos de caracteres
201 | aceptados y no se incluyen caracteres peligrosos conocidos.
202 |
203 | []{#Vulnerabilidad .anchor}**Vulnerabilidad:** Debilidad en un sistema que lo
204 | hace susceptible a ataque o daño.
205 |
--------------------------------------------------------------------------------
/v2/es/uy/03-appendices/07-references.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Apéndice C: Referencias externas {#external-references .list-paragraph}
3 |
4 | ## Referencias citadas
5 |
6 | - SANS CIS Controls version 8
7 |
8 | >
9 |
10 | - Web Application Security Consortium
11 |
12 | >
13 |
14 | - Common Weakness Enumeration (CWE)
15 |
16 | >
17 |
18 | - Department of Homeland Security: Build Security In Portal
19 |
20 | >
21 |
22 | - CERT Secure Coding
23 |
24 | >
25 |
26 | - MSDN Security Developer Center
27 |
28 | >
29 |
30 | ## Sitios de avisos sobre seguridad
31 |
32 | Fuentes útiles para verificar vulnerabilidades comunes sobre la
33 | infraestructura soporte y frameworks
34 |
35 | > Secunia Citrix Vulnerability List:
36 |
37 | -
38 |
39 | > Security Focus Vulnerability Search (archived):
40 |
41 | -
42 |
43 | > Common Vulnerability Enumeration:
44 |
45 | -
46 |
--------------------------------------------------------------------------------
/v2/es/uy/README.md:
--------------------------------------------------------------------------------
1 | # Traducción al español (es-UR)
2 |
3 | Agradecemos todo tipo de [sugerencias y correcciones][issues] sobre esta traducción
4 | de la Guía Rápida de Prácticas de Codificación Segura
5 |
6 | Para generar el PDF, posicionado en el directorio `es/uy`:
7 |
8 | ```
9 | pandoc -o OWASP_SCP_Quick_Reference_Guide.es-UY.pdf title.pdf.yaml \
10 | 01-introduction/01-front.markdown \
11 | 01-introduction/02-toc.markdown \
12 | 01-introduction/03-credits.markdown \
13 | 01-introduction/04-copyright.markdown \
14 | 01-introduction/05-introduction.markdown \
15 | 02-checklist/05-checklist.markdown \
16 | 03-appendices/03-overview.markdown \
17 | 03-appendices/05-glossary.markdown \
18 | 03-appendices/07-references.markdown
19 | ```
20 |
21 | De forma similar, para generar el EBook:
22 |
23 | ```
24 | pandoc -o OWASP_SCP_Quick_Reference_Guide.es-UY.epub title.yaml \
25 | 01-introduction/01-front.markdown \
26 | 01-introduction/02-toc.markdown \
27 | 01-introduction/03-credits.markdown \
28 | 01-introduction/04-copyright.markdown \
29 | 01-introduction/05-introduction.markdown \
30 | 02-checklist/05-checklist.markdown \
31 | 03-appendices/03-overview.markdown \
32 | 03-appendices/05-glossary.markdown \
33 | 03-appendices/07-references.markdown
34 | ```
35 |
36 | Es necesario poseer instalada una dependencia *tex para la correcta generación del formato PDF.
37 | Por ejemplo, en MacOS puede ser utilizado el comando `brew install basictex`.
38 |
39 | [issues]: https://github.com/OWASP/www-project-secure-coding-practices-quick-reference-guide/issues/new
40 |
--------------------------------------------------------------------------------
/v2/es/uy/title.pdf.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: es-UY
3 | author: Open Worldwide Application Security Project (OWASP)
4 | version: 2.0.1
5 | date: Febrero 2023
6 | rights: Creative Commons Attribution ShareAlike 4.0 International (CC BY-SA 4.0)
7 | geometry: "left=3cm,right=2.5cm,top=2cm,bottom=2cm"
8 | header-includes: |
9 | \usepackage{fancyhdr}
10 | \pagestyle{fancy}
11 | \fancyhead{}
12 | \fancyhead[RE,RO]{Febrero 2023}
13 | \fancyfoot{}
14 | \fancyfoot[LE,LO]{Versión 2.0.1}
15 | \fancyfoot[RE,RO]{\thepage}
16 | ...
17 |
--------------------------------------------------------------------------------
/v2/es/uy/title.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: es-UY
3 | title:
4 | - type: main
5 | text: Prácticas de codificación segura
6 | - type: subtitle
7 | text: Guía rápida de referencia
8 | creator:
9 | - role: author
10 | text: Open Worldwide Application Security Project (OWASP)
11 | - role: editor
12 | text: Keith Turpin
13 | - role: translator
14 | text: Gerardo Canedo
15 | version: 2.0.1
16 | date: Febrero 2023
17 | rights: Creative Commons Attribution ShareAlike 4.0 International (CC BY-SA 4.0)
18 | ...
19 |
--------------------------------------------------------------------------------
/v2/ko/kr/01-introduction/01-front.markdown:
--------------------------------------------------------------------------------
1 | {width="3.0in"}
2 |
3 | OWASP 시큐어 코딩 규칙
4 |
5 | # 참고 가이드
6 |
7 | ## 저작권 및 라이센스
8 |
--------------------------------------------------------------------------------
/v2/ko/kr/01-introduction/02-toc.markdown:
--------------------------------------------------------------------------------
1 | # 목차 {#table-of-contents .TOC-Heading}
2 |
3 | [소개](#소개)
4 |
5 | [시큐어 코딩 규칙 체크리스트](#시큐어-코딩-규칙-체크리스트)
6 |
7 | [입력값 검증](#입력값-검증)
8 |
9 | [출력값 인코딩](#출력-값-인코딩)
10 |
11 | [인증과 패스워드 관리](#인증과-패스워드-관리)
12 |
13 | [세션 관리](#세션-관리)
14 |
15 | [접근 통제](#접근-통제)
16 |
17 | [암호 규칙](#암호-규칙)
18 |
19 | [에러 처리와 감사기록](#에러-처리와-감사기록)
20 |
21 | [데이터 보호](#데이터-보호)
22 |
23 | [통신 보안](#통신-보안)
24 |
25 | [시스템 설정](#시스템-설정)
26 |
27 | [데이터베이스 보안](#데이터베이스-보안)
28 |
29 | [파일 관리](#파일-관리)
30 |
31 | [메모리 관리](#메모리-관리)
32 |
33 | [일반 코딩 규칙](#일반-코딩-규칙)
34 |
35 | [부록 A: 소프트웨어 보안과 위험 원칙 개요](#소프트웨어-보안과-위험-원칙-개요)
36 |
37 | [부록 B: 용어집](#부록-b-용어집)
38 |
39 | [부록 C: 외부 참고 문헌](#부록-a-외부-참고-문헌)
40 |
--------------------------------------------------------------------------------
/v2/ko/kr/01-introduction/04-copyright.markdown:
--------------------------------------------------------------------------------
1 | Copyright © 2010-2023 The OWASP Foundation.
2 |
3 | 한글판 Copyright © 2011 The OWASP Korea Chapter.
4 |
5 | 이 문서는 Creative Commons Attribution Share Alike 4.0 International [(CC BY-SA 4.0)][CC-BY-SA-4.0] 라이센스에 따라 발표되었다.
6 | 재사용하거나 배포를 할때에는, 다른 사람들에게 이 문서의 라이센스 조건을 명확하게 해야 한다.
7 |
8 | - 번역 (2011 년 6 월): OWASP Korea 챕터
9 | - OWASP Korea 연락처: 최훈진 이사 (gmanhj@ahnlab.com)
10 |
11 | [CC-BY-SA-4.0]: https://creativecommons.org/licenses/by-sa/4.0/deed.ko
12 |
--------------------------------------------------------------------------------
/v2/ko/kr/01-introduction/05-introduction.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # 소개
3 |
4 | 본 기술 문서는 소프트웨어 개발 생명주기의 한 부분으로 통합하여 사용할
5 | 수 있는 일반적인 소프트웨어 시큐어 코딩 규칙을 체크리스트 형태로
6 | 정의하고 있다. 이 규칙을 적용한다면 가장 일반적인 소프트웨어 취약점을
7 | 완화시킬 수 있다.
8 |
9 | 보안 사고와 관련된 비용을 따지지 않더라도, 소프트웨어 패키지가 완성된
10 | 후 보안 문제를 수정하는 것보다 안전한 소프트웨어를 개발하는 것이
11 | 비용이 적게 든다.
12 |
13 | 공격자의 초점이 애플리케이션 계층으로 지속적으로 이동함에 따라 주요
14 | 소프트웨어 자원 보호는 그 이전보다 중요해졌다. 2009 년 SANS 연구결과 1
15 | 에 따르면 애플리케이션 계층에 대한 공격이 인터넷에서 발견되는 전체
16 | 공격 시도의 60% 이상을 차지하고 있다.
17 |
18 | 본 가이드를 활용할 때, 개발팀은 보유한 소프트웨어 개발 생명주기와
19 | 팀원의 지식 수준의 성숙도에 대한 평가부터 시작해야 한다. 본 가이드는
20 | 개별 코딩 규칙을 구현하는 상세한 내용이 없으므로, 사전 지식이나 필요한
21 | 조언을 얻을 수 있는 충분한 자원(조언자)이 개발자에게 필요하다. 본
22 | 가이드는 보안 취약점과 공격코드에 대해 깊게 알고 있는 개발자가 없어도
23 | 코딩 요구사항으로 사용할 수 있는 코딩 규칙을 제공한다. 하지만,
24 | 개발팀은 전체 시스템의 설계와 구현 안전성을 검증할 수 있는 책임감과
25 | 충분한 교육, 도구 그리고 자원을 가져야 한다.
26 |
27 | 이탤릭으로 표기한 본 문서, 장별 제목, 그리고 문장의 중요 단어 목록은
28 | 부록 B 에서 제공한다.
29 |
30 | 안전한 소프트웨어 개발 프레임워크 구현 가이드라인은 본 문서의 범위에
31 | 포함되지 않는다. 하지만, 추가적으로 필요한 일반적인 사례 문서와 참고
32 | 문헌은 다음과 같다:
33 |
34 | - 역할과 책임을 명화하게 정의
35 |
36 | - 개발팀에게 충분한 소프트웨어 보안 교육을 제공
37 |
38 | - 안전한 소프트웨어 개발 생명주기 준수
39 |
40 | - 시큐어 코딩 표준 확립
41 |
42 | - [OWASP Development Guide][guide] Project
43 |
44 | - 재사용 가능한 객체 라이브러리 제작
45 |
46 | - [OWASP Enterprise Security API][esapi] (ESAPI) Project
47 |
48 | - 보안 통제의 효과성 점검
49 |
50 | - [OWASP Application Security Verification Standard][asvs] (ASVS) Project
51 |
52 | - RFP(the Request for Proposal)와 계약서에 보안 요구사항과 검증
53 | 방법론을 정의한 보안 아웃소싱 개발 규칙을 확립
54 |
55 | [asvs]: https://owasp.org/www-project-application-security-verification-standard/
56 | [esapi]: https://owasp.org/www-project-enterprise-security-api/
57 | [guide]: http://www.owasp.org/index.php/Category:OWASP_Guide_Project
58 |
--------------------------------------------------------------------------------
/v2/ko/kr/03-appendices/03-overview.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # 부록 A: 소프트웨어 보안과 위험 원칙 개요 {#소프트웨어-보안과-위험-원칙-개요 .list-paragraph}
3 |
4 | 안전한 소프트웨어를 개발하려면 보안 원칙에 대한 기본적인 이해가
5 | 필요하다. 보안 원칙에 대한 상세한 설명은 본 가이드의 범위를
6 | 벗어나므로, 개괄적인 내용만을 제공한다.
7 |
8 | 소프트웨어 보안의 목표는 성공적으로 사업을 운영하기 위해 정보 자원의
9 | 비밀성 *,* 무결성, 그리고
10 | 가용성을 유지하는 것이다. 이 목표들은 보안 통제 기능을
11 | 구현하면서 달성할 수 있다. 본 가이드는 흔한 소프트웨어의
12 | 취약점을 [완화](#_bookmark9)시킬 수 있는
13 | 기술적 통제 항목에 중점을 둔다. 1 차적인 초점은 웹 애플리케이션과 웹
14 | 애플리케이션을 지원하는 인프라 스트럭처이지만, 가이드라인의 내용
15 | 대부분은 모든 소프트웨어 개발 플랫폼에 적용 가능하다.
16 |
17 | 소프트웨어의 안전성과 관련된 수용할 수 없는 위험으로부터 사업을
18 | 보호하려면, 위험의 의미를 이해할 필요가 있다. 위험은 비즈니스의 성공을
19 | 위협하는 요소들의 조합이다. 이는 개념적으로 다음과 같이 설명 가능하다:
20 | [위협 요소](#_bookmark14)는 [피해](#_bookmark7)를 주기위해
21 | [악용](#_bookmark4)할 수 있는 취약점을
22 | 가진 시스템과 상호작용한다. 이 것은 추상적인 개념
23 | 같지만, 다음과 같은 방향으로 생각해보자: 자동차 도둑(위협 요소)이
24 | 잠기지 않은 문(취약점)을 찾기 위해 주차장을 따라 자동차(시스템)을
25 | 확인하면서 간다. 그리고 도둑이 하나 발견한다면, 자동차 문을 열고(악용)
26 | 자동차 안에 무엇이 있든 가져간다(피해). 이러한 모든 요소들이 안전한
27 | 소프트웨어 개발에 영향을 준다.
28 |
29 | 개발팀의 접근방법과 애플리케이션 공격자의 접근방법은 기본적으로
30 | 차이점이 있다. 개발팀은 일반적으로 애플리케이션의 정상적인 의도에
31 | 초점을 맞춰 접근한다. 즉 문서화된 기능 요구사항과 사용자 사례에
32 | 기반하여 특정 기능을 수행하는 애플리케이션을 디자인한다. 이와 달리
33 | 공격자는 애플리케이션이 할 수 있는 것과 "구체적으로 거부되지 않은
34 | 행위는 허용된다"라는 원칙에 따라 동작하는 것에 더 많은 관심을 가지고
35 | 있다. 이 문제를 해결하려면, 소프트웨어 생명주기의 초기 단계에서부터
36 | 추가적인 요소가 포함되어야 한다. 추가적으로 필요한 요소란 바로 보안
37 | 요구사항과 [오용 사례](#_bookmark0)이다. 본
38 | 가이드는 높은 수준의 보안 요구사항을 정의하는 것과 가장 많이 오용하는
39 | 시나리오를 해결하는 데 도움이 된다.
40 |
41 | 웹 개발팀은 조금이라도 보안에 이점을 줄 수 있는 사용자 측의 입력값
42 | 검증, 숨겨진 필드와 인터페이스 통제(예: 풀다운 메뉴와 라디오 버튼)와
43 | 같은 사용자 측 통제를 이해하는 것이 중요하다. 공격자는 애플리케이션
44 | 트래픽을 분석하고 조작된 요청을 전송하거나 모든 인터페이스를 우회하기
45 | 위해 사용자 측 웹 프록시(예: OWASP WebScarab, Burp) 또는 네트워크 패킷
46 | 캡처 도구(예: WireShark)와 같은 도구를 사용할 수 있다. 추가적으로
47 | 플래쉬, 자바 애플릿, 그리고 다른 사용자 측 오브젝트는 취약점을 찾기
48 | 위해 디컴파일되고 분석될 수 있다.
49 |
50 | 소프트웨어 보안 취약점은 다음을 포함하는 소프트웨어 개발 생명주기의
51 | 어떤 단계에서도 발견될 수 있다:
52 |
53 | - 이전 보안 요구사항에 정의되지 않았을 때
54 | - 논리적 에러를 가지고 있도록 개념적으로 설계했을 때
55 | - 기술 취약점이 노출된 취약한 코딩 규칙을 사용했을 때
56 | - 소프트웨어를 부적절하게 배치했을 때
57 | - 관리 또는 업데이트 중 취약점이 발표될 때
58 |
59 | 더욱이, 소프트웨어 취약점은 소프트웨어 자체를 넘어서서 그 이상의
60 | 피해를 초래한다는 사실을 알아야 한다. 소프트웨어 및 취약점, 관련
61 | 인프라스트럭처의 성격에 따라서, 취약점 공격이 성공했을 때의 다음 중
62 | 하나 또는 모든 항목에 대해서 영향을 줄 수 있다:
63 |
64 | - 소프트웨어 및 관련된 정보
65 | - 관련 서버의 운영체제
66 | - 데이터베이스
67 | - 공유 환경에 있는 다른 애플리케이션
68 | - 사용자 시스템
69 | - 사용자와 상호작용하는 다른 소프트웨어
70 |
--------------------------------------------------------------------------------
/v2/ko/kr/03-appendices/05-glossary.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # 부록 B: 용어집 {#부록-b-용어집 .list-paragraph}
3 |
4 | []{#_bookmark0 .anchor}**오용 사례(Abuse Case):** 소프트웨어의 의도적
5 | 오용과 비의도적 오용을 말한다. 오용 케이스는 시스템 설계에서
6 | 가정(전제)에 대한 대한 위협요소이다.
7 |
8 | **접근 통제(Access Control):** 시스템 자원에 접근하려는 사용자 또는
9 | 자원에 대해 허용하고 거부하는 일련의 통제. 일반적으로 역할내 계층적인
10 | 역할과 개인의 권한, 그리고 시스템 상호간의 연관성을 기반으로 한다.
11 |
12 | **인증(Authentication):** 소프트웨어와 상호 작용하는 사용자 또는 다른
13 | 엔터티의 신원을 확인하는 일련의 통제
14 |
15 | **가용성(Availability):** 시스템의 접근성과 사용성의 척도
16 |
17 | []{#_bookmark1 .anchor}**정규화(Canonicalize):** 간단한 단일 형식을
18 | 이용해 다양한 인코딩과 데이터 표현을 축소하는 것
19 |
20 | **통신 보안(Communication Security):** 소프트웨어가 안전하게 정보를
21 | 송수신하도록 하는 일련의 통제 **비밀성(Confidentiality):** 정보가
22 | 권한이 있는 자에게만 공개되는 것을 보장하는 것
23 |
24 | []{#_bookmark2 .anchor}**상황에 맞는 출력 값 인코딩(Contextual Output
25 | Encoding):** 애플리케이션에서 어떻게 데이터를 활용할지를 고려하여
26 | 결과를 인코딩하는 것. 인코딩 방법은 사용된 결과 데이터의 사용 목적에
27 |
28 | 따라서 다양하다. 클라이언트 측의 응답에 데이터가 포함된다면, 다음을
29 | 포함하는 시나리오를 설명해야 한다: HTML 문서의 본문, HTML 속성,
30 | 자바스크립트, CSS, URL. 또한 SQL 쿼리, XML, LAP 와 같은 다른 경우에
31 | 대해서도 설명해야 한다.
32 |
33 | []{#_bookmark3 .anchor}**크로스 사이트 요청 위조(Cross Site Request
34 | Forgery):** 외부 웹사이트 또는 애플리케이션이 사용자에게 의도하지 않은
35 | 요청을 유효한 세션을 맺고 있는 다른 애플리케이션을 보내는 것이다.
36 |
37 | 애플리케이션은 이해가능하거나 예측 가능한 URL 과 파라메터를 사용할 때
38 | 취약하다. 또한 취약한 애플리케이션에 대해 브라우저가 모든 필요한 세션
39 | 정보를 자동적으로 한꺼번에 요청할 때 발생 가능하다. (관련 취약점이
40 | 매우 일반적이지만 사람들의 이해가 부족하기 때문에 공격유형으론
41 | 유일하게 본 문서에서 상세한 설명을 한다)
42 |
43 | **암호화 규칙(Cryptographic Practices):** 애플리케이션의 암호연산이
44 | 안전하게 처리됨을 보장하는 일련의 통제
45 |
46 | **데이터 보호(Data Protection):** 소프트웨어가 안전하게 정보를
47 | 저장하도록 처리하는 일련의 통제
48 |
49 | **데이터 베이스 보안(Database Security):** 소프트웨어가 데이터베이스와
50 | 안전한 방법으로 상호작용하고 데이터베이스가 안전하게 설정되었음을
51 | 보장하는 일련의 통제
52 |
53 | **에러 처리와 감사기록(Error Handling and Logging):** 애플리케이션이
54 | 에러를 안전하게 처리하고 적절하게 이벤트를 감사기록하는 것을 보장하는 일련의 규칙
55 |
56 | []{#_bookmark4 .anchor}**악용(Exploit):** 취약점을 이용해 권한 또는
57 | 정보를 취하는 행위. 일반적으로 취약점을 찾아내어 소프트웨어의 보안
58 | 통제를 취약하게 하는 의도적인 행위이다.
59 |
60 | **파일 관리(File Management):** 코드와 다른 파일 시스템 파일간의
61 | 상호작용을 다루는 일련의 통제.
62 |
63 | **일반 코딩 규칙(General Coding Practices):** 특정 카테고리에 속하기
64 | 힘든 코딩 규칙을 다루는 일련의 통제.
65 |
66 | []{#_bookmark5 .anchor}**위험 문자(Hazardous Character):**
67 | 애플리케이션에서 의도한 의미를 가지거나 관련 시스템에서 원래의 의미를
68 | 벗어나 특수한 의미로 해석되는 문자 또는 인코딩된 문자 표현. 이들
69 | 문자는 다음과 같은 결과를 초래할 수 있다:
70 |
71 | - 기존의 코드 또는 구문의 구조를 변경
72 | - 의도되지 않은 새로운 코드를 삽입
73 | - 경로 변경
74 | - 프로그램 함수 또는 루틴이 의도하지 않은 결과 산출
75 | - 에러 조건 발생
76 | - 하위 애플리케이션 또는 시스템에 앞선 결과를 초래
77 |
78 | []{#_bookmark6 .anchor}**HTML 개체 인코딩(HTML Entity Encode):** ASCII
79 | 문자를 동일한 의미의 HTML 엔터티로 변경하는 과정. 예를 들어, 인코딩은
80 | 문자 "\<"는 동일한 의미의 HTML "<"로 변경한다. HTML 엔터티는
81 |
82 | 대부분의 인터프리터(특히, 웹 브라우저)에서 특수한 의미를 가지지
83 | 않으며, 특정 사용자 측 공격을 완화할 수 있다.
84 |
85 | []{#_bookmark7 .anchor}**피해(Impact):** 의도하지 않은 사건의 발생으로
86 | 인해 비즈니스에 초래될 수 있는 부정적 영향의 정도; 취약점을
87 | 악용함으로써 발생할 수 있는 결과는 무엇인가?
88 |
89 | **입력값 검증(Input Validation):** 모든 입력 데이터 속성이
90 | 애플리케이션에서 의도한 자료형, 길이, 범위, 수용 가능한 문자셋과
91 | 일치하고 알려진 위험 문자가 포함되지 않았는지를 확인하는 통제
92 |
93 | **무결성(Integrity):** 정보의 정확성, 완벽성, 유효성, 그리고 권한이
94 | 없는 행위로 인해 변경되지 않았다는 것을 보장하는 것.
95 |
96 | []{#_bookmark8 .anchor}**로그 이벤트 데이터:** 로그 이벤트 데이터는
97 | 다음을 포함해야 한다:
98 |
99 | 1. 신뢰하는 시스템 컴포넌트의 타임 스탬프
100 | 2. 각 이벤트의 심각도
101 | 3. 다른 로그 엔트리와 섞여있는 경우 관련 이벤트에 대한 태깅
102 | 4. 해당 이벤트를 초래한 계정 또는 사용자의 신원(식별자)
103 | 5. 요청과 관련된 근원 IP 주소
104 | 6. 이벤트 결과(성공 또는 실패)
105 | 7. 이벤트에 대한 설명
106 |
107 | **메모리 관리(Memory Management):** 메모리와 버퍼 사용을 관리하는
108 | 일련의 통제.
109 |
110 | []{#_bookmark9 .anchor}**완화(Mitigate):** 취약점의 심각성을
111 | 감소시키기 위한 절차. 이는 취약점 제거, 취약점을 악용하기 어렵도록
112 | 조치, 공격이 성공했을 때의 부정적 피해 감소 등을 포함한다.
113 |
114 | []{#_bookmark10 .anchor}**다중 인증(Multi-Factor Authentication):**
115 | 사용자가 다수의 다양한 형태의 인증정보를 사용하는 인증 과정.
116 | 일반적으로 사용자가 소유한 것(예: 스마트카드), 사용자가 아는 것(예:
117 | 개인식별번호), 자신 그
118 |
119 | 자체(예: 생체정보)를 기반으로 한다.
120 |
121 | **출력 값 인코딩(Output Encoding):** 애플리케이션의 출력 데이터로 인한
122 | 위험을 제거하기 위해 인코딩을 사용하도록 하는 일련의 통제.
123 |
124 | []{#_bookmark11 .anchor}**매개변수 쿼리(Parameterized Queries
125 | (prepared statements)):** 플레이스홀더(placeholder)를 사용하여 쿼리와
126 | 데이터가 구별되도록 한다. 쿼리 구조는 플레이스홀더로 정의된 후 SQL
127 | 구문은
128 |
129 | 데이터베이스에 전송되어 준비된 후, prepared statmenet 가 파라메터와
130 | 결합한다. 이는 파라메터 값이 SQL 문자열이 아닌 컴파일된 쿼리와
131 | 결합하기 때문에 원래의 쿼리가 변경되는 것을 예방한다.
132 |
133 | **데이터 검열(Sanitize Data):** 데이터 제거, 변경, 인코딩, 문자제외를
134 | 통해 잠재적으로 위험한 데이터를 안전하게 변경하는 과정.
135 |
136 | **보안 통제(Security Controls):** 잠재적 취약점을 완화하고
137 | 소프트웨어가 의도한 대로 동작하도록 보장하는 행위.
138 |
139 | **보안 요구사항(Security Requirements):** 소프트웨어가 안전한 방법으로
140 | 개발되고 배치되도록 돕는 일련의 설계 및 기능 요구사항의 집합
141 |
142 | []{#_bookmark12 .anchor}**순차적 인증(Sequential Authentication):**
143 | 인증 데이터가 단일 페이지에서 한번에 처리되는 것이 아니라 인증 성공
144 | 페이지까지 순차적으로 요청하는 것
145 |
146 | **세션 관리(Session Management):** 웹 애플리케이션이 HTTP 세션을
147 | 안전하게 처리하도록 하는 일련의 통제
148 |
149 | []{#_bookmark13 .anchor}**상태 데이터(State Data):** 애플리케이션 또는
150 | 서버에서 사용하는 데이터 또는 파라메터로, 지속적인 접속을 유지하거나
151 | 다중 요청 과정 또는 거래를 추적하기 위해 사용한다.
152 |
153 | **시스템(System):** 운영체제, 웹 서버, 애플리케이션 프레임워크와 관련
154 | 인프라 스트럭처를 포괄하는 일반 용어
155 |
156 | **시스템 설정(System Configuration):** 소프트웨어의 인프라스트럭처
157 | 컴포넌트가 안전하게 배치될 수 있도록 돕는 일련의 통제
158 |
159 | []{#_bookmark14 .anchor}**위협 요소(Threat Agent):** 시스템에 부정적
160 | 영향을 미칠 수 있는 임의의 개체. 시스템의 보안 통제를 침해할려는
161 | 악의적인 사용자가 일반적 위협 요소이지만, 화재 또는 홍수 등과 같은
162 | 물리적 위협과
163 |
164 | 실수로 인한 시스템 오작동도 이에 포함된다.
165 |
166 | []{#_bookmark15 .anchor}**신뢰 범위(Trust Boundaries):** 일반적으로
167 | 신뢰 범위는 직접적인 통제가 가능한 시스템 컴포넌트로 구성된다.
168 | 직접적인 통제가 불가능한 외부 시스템(모든 사용자와 협력자가 운영하는
169 | 시스템을
170 |
171 | 포함)으로부터의 모든 접속과 데이터는 비신뢰 구간에 속하며, 내부로 유입
172 | 전(다른 시스팀과 상호 작용하기 전)에 검증해야 한다.
173 |
174 | **취약점(Vulnerability):** 시스템을 공격 또는 손상되기 쉽도록 하는
175 | 약점.
176 |
--------------------------------------------------------------------------------
/v2/ko/kr/03-appendices/07-references.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # 부록 C: 외부 참고 문헌 {#부록-a-외부-참고-문헌 .list-paragraph}
3 |
4 | ## 인용한 참고문헌
5 |
6 | - SANS 와 TippingPoint \" 탑 사이버 보안 위험 \" CIS Controls version 8
7 |
8 | >
9 |
10 | - 웹 애플리케이션 보안 컨소시엄
11 |
12 | >
13 |
14 | - Common Weakness Enumeration (CWE)
15 |
16 | >
17 |
18 | - 홈랜드 시큐리티의 소프트웨어 보증 프로그램 부서 안전한 포탈 구축하기
19 |
20 | >
21 |
22 | - CERT 시큐어 코딩
23 |
24 | >
25 |
26 | - MSDN 보안 개발 센터
27 |
28 | >
29 |
30 | - SQL 인젝션 참고 목록
31 |
32 | - Cross Site Scripting (XSS) 참고 목록
33 |
34 | ## 보안 권고 사이트
35 |
36 | 인프라스트럭처와 프레임워크를 위협하는 알려진 보안 취약점을 확인할 수
37 | 있는 유용한 자원
38 |
39 | > Secunia Citrix 취약점 목록 Vulnerability List:
40 |
41 | -
42 |
43 | > Security Focus 취약점 검색 Vulnerability Search (archived):
44 |
45 | -
46 |
47 | > 오픈 소스 취약점 데이터베이스 (OSVDB):
48 |
49 | > CVE(Common Vulnerability Enumeration):
50 |
51 | -
52 |
53 |
--------------------------------------------------------------------------------
/v2/ko/kr/README.md:
--------------------------------------------------------------------------------
1 | # Korean language (ko-KR) version
2 |
3 | We appreciate all kinds of [suggestions and corrections][issues] on this translation
4 | of the Secure Coding Practices Quick Reference Guide
5 |
6 | During development manually create the PDF document from directory `ko/kr`:
7 |
8 | ```
9 | pandoc -o OWASP_SCP_Quick_Reference_Guide.ko-KR.pdf \
10 | --pdf-engine=xelatex -r markdown title.pdf.yaml \
11 | 01-introduction/01-front.markdown \
12 | 01-introduction/02-toc.markdown \
13 | 01-introduction/04-copyright.markdown \
14 | 01-introduction/05-introduction.markdown \
15 | 02-checklist/05-checklist.markdown \
16 | 03-appendices/03-overview.markdown \
17 | 03-appendices/05-glossary.markdown \
18 | 03-appendices/07-references.markdown
19 | ```
20 |
21 | Similarly create the EBook:
22 |
23 | ```
24 | pandoc -o OWASP_SCP_Quick_Reference_Guide.ko-KR.epub \
25 | --pdf-engine=xelatex -r markdown title.yaml \
26 | 01-introduction/01-front.markdown \
27 | 01-introduction/02-toc.markdown \
28 | 01-introduction/04-copyright.markdown \
29 | 01-introduction/05-introduction.markdown \
30 | 02-checklist/05-checklist.markdown \
31 | 03-appendices/03-overview.markdown \
32 | 03-appendices/05-glossary.markdown \
33 | 03-appendices/07-references.markdown
34 | ```
35 |
36 | There is a dependency on having a *tex installed that will provide pdflatex for the PDF output.
37 | For example with MacOS the command `brew install basictex` can be used.
38 | Also make sure font 'Nanum Myeongjo' is installed when creating the PDF and eBook.
39 |
40 | [issues]: https://github.com/OWASP/www-project-secure-coding-practices-quick-reference-guide/issues/new
41 |
--------------------------------------------------------------------------------
/v2/ko/kr/title.pdf.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | language: ko-KR
3 | author: Open Worldwide Application Security Project (OWASP)
4 | version: 2.0.1
5 | date: 2022 년 12 월
6 | rights: Creative Commons Attribution ShareAlike 4.0 International (CC BY-SA 4.0)
7 | geometry: "left=3cm,right=2.5cm,top=2cm,bottom=2cm"
8 | mainfont: Nanum Myeongjo
9 | fontsize: 12pt
10 | header-includes: |
11 | \usepackage{fancyhdr}
12 | \pagestyle{fancy}
13 | \fancyhead{}
14 | \fancyfoot{}
15 | \fancyfoot[LE,LO]{v2.0.1}
16 | \fancyfoot[RE,RO]{\thepage}
17 | ...
18 |
--------------------------------------------------------------------------------
/v2/ko/kr/title.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: ko-KR
3 | title:
4 | - type: main
5 | text: OWASP 시큐어 코딩 규칙
6 | - type: subtitle
7 | text: 참고 가이드
8 | creator:
9 | - role: author
10 | text: Open Worldwide Application Security Project (OWASP)
11 | - role: editor
12 | text: Keith Turpin
13 | version: 2.0.1
14 | date: 2022 년 12 월
15 | rights: Creative Commons Attribution ShareAlike 4.0 International (CC BY-SA 4.0)
16 | geometry: "left=2.3cm,right=2cm,top=2cm,bottom=2.5cm"
17 | mainfont: Nanum Myeongjo
18 | fontsize: 12pt
19 | ...
20 |
--------------------------------------------------------------------------------
/v2/pt/br/01-introduction/01-front.markdown:
--------------------------------------------------------------------------------
1 | {width="3.0in"}
2 |
3 | # Melhores Práticas de Codificação Segura OWASP
4 |
5 | ## Guia de Referência Rápida
6 |
--------------------------------------------------------------------------------
/v2/pt/br/01-introduction/02-toc.markdown:
--------------------------------------------------------------------------------
1 | # Sumário {#table-of-contents .TOC-Heading}
2 |
3 | [Introdução](#introdução)
4 |
5 | [Lista de Verificação de Práticas de Programação Segura](#lista-de-verificação-de-práticas-de-programação-segura)
6 |
7 | [Validação dos Dados de Entrada](#validação-dos-dados-de-entrada)
8 |
9 | [Codificação de Dados de Saída](#codificação-de-dados-de-saída)
10 |
11 | [Autenticação e Gerenciamento de Credenciais](#autenticação-e-gerenciamento-de-credenciais)
12 |
13 | [Gerenciamento de Sessões](#gerenciamento-de-sessões)
14 |
15 | [Controle de Acessos](#controle-de-acessos)
16 |
17 | [Práticas de Criptografia](#práticas-de-criptografia)
18 |
19 | [Tratamento de Erros e Log](#tratamento-de-erros-e-log)
20 |
21 | [Proteção de Dados](#proteção-de-dados)
22 |
23 | [Segurança nas comunicações](#segurança-nas-comunicações)
24 |
25 | [Configuração do Sistema](#configuração-do-sistema)
26 |
27 | [Segurança em Banco de Dados](#segurança-em-banco-de-dados)
28 |
29 | [Gerenciamento de Arquivos](#gerenciamento-de-arquivos)
30 |
31 | [Gerenciamento de Memória](#gerenciamento-de-memória)
32 |
33 | [Práticas Gerais de Codificação](#práticas-gerais-de-codificação)
34 |
35 | [Apêndice A Princípios Gerais de Segurança em Aplicações e Riscos](#princípios-gerais-de-segurança-em-aplicações-e-riscos)
36 |
37 | [Apêndice B Glossário](#glossário)
38 |
39 | [Apêndice C Referências Externas](#referências-externas)
40 |
--------------------------------------------------------------------------------
/v2/pt/br/01-introduction/03-credits.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | **Notas da versão**
3 |
4 | Essa versão do OWASP *Secure Coding Practices* foi desenvolvida como
5 | parte integrante da atividade conjunta dos capítulos brasileiro e
6 | português da OWASP, em prol da comunidade de programadores e da
7 | segurança dos sistemas desenvolvidos nos países de língua portuguesa.
8 | Este documento é baseado na versão 2.0 de Novembro de 2010 e na revisão
9 | da primeira tradução, a versão 1.2, datada de Julho de 2011.
10 |
11 | Líder do projeto de tradução:
12 |
13 | - Tarcizio Vieira Neto --
14 | [tarcizio.vieira@owasp.org](mailto:tarcizio.vieira@owasp.org)
15 | -- Brasil
16 |
17 | Participaram desta tradução:
18 |
19 | - Leandro Resende Gomes --
20 | [leandrock@gmail.com](mailto:leandrock@gmail.com)
21 | -- Brasil
22 |
23 | - Sílvio Fernando Correia Vieira Filho --
24 | [silviofilhosf@gmail.com](mailto:silviofilhosf@gmail.com)
25 | -- Brasil
26 |
27 | - Paulo Alexandre Silva --
28 | [me@pauloasilva.com](mailto:me@pauloasilva.com)
29 | -- Portugal
30 |
31 | - Alexandre Pupo --
32 | [alexandrepupo@yahoo.com.br](mailto:alexandrepupo@yahoo.com.br)
33 | -- Brasil
34 |
35 | - Carlos Serrão --
36 | [carlos.serrao@owasp.org](mailto:carlos.serrao@owasp.org)
37 | -- Portugal
38 |
39 | - Rogério Vicente --
40 | [rogeriopvl@gmail.com](mailto:rogeriopvl@gmail.com)
41 | -- Portugal
42 |
43 | - Jorge Olimpia --
44 | [jorgeolimpia@gmail.com](mailto:jorgeolimpia@gmail.com)
45 | -- Brasil
46 |
47 | A tradução deste documento pretende ser fiel ao texto original, tendo
48 | sido introduzidos alguns detalhes explicativos que estão dispersos no
49 | texto, em alguns casos, na forma de notas de rodapé contendo o prefixo
50 | "NT:" (nota de tradução).
51 |
52 | Para saber mais sobre os eventos e atividades desenvolvidas pelo
53 | capítulo Brasil, acesse a página
54 | ([http://www.owasp.org/index.php/Brazil](http://www.owasp.org/index.php/Brazil))
55 | ou registre-se na lista de discussão OWASP-BR
56 | ([http://lists.owasp.org/mailman/listinfo/owasp-brazilian](http://lists.owasp.org/mailman/listinfo/owasp-brazilian)).
57 |
58 | Para saber mais sobre os eventos e atividades desenvolvidas pela
59 | delegação da OWASP em Portugal, acesse a página
60 | ([http://www.owasp.org/index.php/Portuguese](http://www.owasp.org/index.php/Portuguese))
61 | ou registre-se na lista de discussão OWASP- PT
62 | ([https://lists.owasp.org/mailman/listinfo/owasp-portuguese](https://lists.owasp.org/mailman/listinfo/owasp-portuguese)).
63 |
--------------------------------------------------------------------------------
/v2/pt/br/01-introduction/04-copyright.markdown:
--------------------------------------------------------------------------------
1 | **Copyright and License**
2 |
3 | Copyright © 2010-2023 The OWASP Foundation.
4 |
5 | O conteúdo deste documento é distribuído sob a licença
6 | Creative Commons Attribution-ShareAlike 4.0 International [(CC BY-SA 4.0)][CC-BY-SA-4.0].
7 | Para a utilização ou redistribuição, deve deixar claro os termos da licença deste trabalho.
8 |
9 | [CC-BY-SA-4.0]: https://creativecommons.org/licenses/by-sa/4.0/deed.pt_BR
10 |
--------------------------------------------------------------------------------
/v2/pt/br/01-introduction/05-introduction.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Introdução
3 |
4 | Este documento não se baseia apenas em questões tecnológicas e tem o
5 | propósito de definir um conjunto de boas práticas de segurança no
6 | desenvolvimento de aplicações. As recomendações serão apresentadas no
7 | formato de lista de verificações, que podem ser integradas ao ciclo de
8 | desenvolvimento das aplicações. A adoção destas práticas provavelmente
9 | reduzirá as vulnerabilidades mais comuns em aplicações Web.
10 |
11 | Geralmente, é mais barato construir software seguro do que corrigir
12 | problemas de segurança após a entrega do mesmo como um produto final ou
13 | pacote completo, sem falar nos custos que podem estar associados a uma
14 | falha de segurança.
15 |
16 | Proteger os recursos críticos das aplicações tem se tornado cada vez
17 | mais importante, pois o foco dos atacantes mudou para a camada de
18 | aplicação. Um estudo da SANS em 2009[^101] descobriu que os ataques
19 | contra aplicações Web constituem mais de 60% das tentativas de ataque
20 | observados na Internet.
21 |
22 | Ao utilizar este guia é recomendável que equipes de desenvolvimento
23 | avaliem a maturidade do ciclo de vida de desenvolvimento de software e o
24 | nível de conhecimento da equipe. Como este guia não entra em detalhes de
25 | como implantar cada prática de programação, os programadores precisam
26 | possuir conhecimento prévio ou devem ter disponíveis os recursos que
27 | forneçam o conhecimento necessário. Este guia apresenta práticas que
28 | podem ser traduzidas em requisitos de desenvolvimento sem a necessidade
29 | do programador possuir uma compreensão aprofundada das vulnerabilidades
30 | e *exploits* de segurança. No entanto, outros membros da equipe de
31 | desenvolvimento devem possuir responsabilidades, competências adequadas,
32 | ferramentas e recursos para validar se o projeto e a implementação
33 | atendem os requisitos de segurança.
34 |
35 | No apêndice B encontra-se um glossário dos termos importantes usados
36 | neste documento, incluindo o título das secções e palavras mostradas em
37 | *itálico*.
38 |
39 | Não faz parte do escopo deste guia fornecer orientações para implantar
40 | um *framework* de desenvolvimento seguro de software, mas as seguintes
41 | práticas gerais e referências são recomendadas:
42 |
43 | - Definir claramente os papéis e responsabilidades
44 |
45 | - Fornecer às equipes de desenvolvimento pessoal com formação adequada
46 | em segurança no desenvolvimento de aplicações
47 |
48 | - Implementar um ciclo de desenvolvimento de software seguro
49 |
50 | - Estabelecer padrões de programação segura
51 |
52 | - [OWASP Development Guide][guide] Project
53 |
54 | - Construir uma biblioteca reutilizável ou fazer uso de uma biblioteca
55 | de segurança[^101]
56 |
57 | - [OWASP Enterprise Security API][esapi] (ESAPI) Project
58 |
59 | - Verificar a efetividade dos controles de segurança
60 |
61 | - [OWASP Application Security Verification Standard][asvs] (ASVS) Project
62 |
63 | - Estabelecer práticas para garantir a segurança quando há
64 | terceirização no desenvolvimento, incluindo a definição dos
65 | requisitos de segurança e metodologias de verificação tanto para
66 | os requisitos das propostas, como para o contrato a ser firmado
67 | entre as partes
68 |
69 | [asvs]: https://owasp.org/www-project-application-security-verification-standard/
70 | [esapi]: https://owasp.org/www-project-enterprise-security-api/
71 | [guide]: http://www.owasp.org/index.php/Category:OWASP_Guide_Project
72 |
--------------------------------------------------------------------------------
/v2/pt/br/03-appendices/03-overview.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Apêndice A Princípios Gerais de Segurança em Aplicações e Riscos {#princípios-gerais-de-segurança-em-aplicações-e-riscos .list-paragraph}
3 |
4 | Construir software seguro exige o conhecimento básico dos princípios de
5 | segurança. Uma revisão abrangente dos princípios de segurança está fora
6 | do escopo desse guia, porém os conceitos de segurança serão abordados de
7 | forma superficial, mas abrangente.
8 |
9 | O objetivo da segurança em aplicações é manter a *confidencialidade*,
10 | *integridade* e *disponibilidade* dos recursos de informação a fim de
11 | permitir que as operações de negócios sejam bem sucedidas e esse
12 | objetivo é alcançado através da implementação de *controles de
13 | segurança*. Este guia concentra-se nos controles técnicos, específicos
14 | para *mitigar* as ocorrências das *vulnerabilidades* mais comuns no
15 | software e como o foco principal são as aplicações Web e a
16 | infraestrutura de apoio, boa parte desse documento pode ser usada para
17 | qualquer plataforma de desenvolvimento de software.
18 |
19 | Para proteger o negócio contra os riscos inaceitáveis, isto é,
20 | relacionados com a dependência e com a confiança depositada na
21 | aplicação, este guia ajuda a compreender o que podemos entender por
22 | risco. Deste modo, risco é a combinação de fatores que ameaçam o sucesso
23 | do negócio. Isto pode ser descrito conceitualmente da seguinte forma: um
24 | *agente de ameaça* interage com um *sistema*, no qual pode haver uma
25 | *vulnerabilidade* latente que quando *explorada* causa um *impacto*.
26 | Como isto pode parecer um conceito abstrato, pense do seguinte modo: um
27 | ladrão de carros (agente de ameaça) passa por um estacionamento
28 | verificando nos carros presentes (o sistema) a existência de portas
29 | destrancadas (a vulnerabilidade) e quando a encontra, abre a porta (a
30 | exploração) e leva para si o que está dentro do carro (o impacto). Todos
31 | esses fatores desempenham um papel no desenvolvimento de software
32 | seguro.
33 |
34 | Existe uma diferença fundamental entre a abordagem adotada por uma
35 | equipe de desenvolvimento e a abordagem que é adotada por alguém que
36 | está interessado em atacar uma aplicação. Uma equipe de desenvolvimento
37 | normalmente desenvolve uma aplicação com base naquilo que ela pretende
38 | fazer e isso significa criar uma aplicação para executar tarefas
39 | específicas, baseadas em requisitos funcionais e casos de uso
40 | documentados. Um atacante, por outro lado, está mais interessado no que
41 | a aplicação pode ser levada a fazer e parte do princípio que \"qualquer
42 | ação não expressamente proibida, é permitida\". Para resolver isso,
43 | alguns elementos adicionais precisam ser integrados nas fases iniciais
44 | do ciclo de vida do software e esses novos elementos são *requisitos de
45 | segurança* e *casos de abuso.* Este guia foi construído para ajudar a
46 | identificar os requisitos de segurança de alto nível e abordar vários
47 | cenários de ataques.
48 |
49 | É importante que as equipes de desenvolvimento de aplicações Web
50 | entendam que os mecanismos de controle do lado cliente, como validação
51 | de dados de entrada no cliente, campos ocultos e controles de interface
52 | (combo box, radio buttons), fornecem pouco ou nenhum benefício de
53 | segurança. Nesse caso, um atacante pode usar ferramentas como *proxies*
54 | do lado cliente, como o OWASP WebScarab, Burp ou ferramentas de captura
55 | de pacotes de rede, como o Wireshark, para analisar o tráfego da
56 | aplicação e enviar requisições manipuladas, burlando todas as
57 | interfaces. Além disso, o Flash, os Applets Java e demais objetos que
58 | trabalham no lado cliente podem ser alvo de engenharia reversa e
59 | analisados em busca de falhas.
60 |
61 | As falhas de segurança de software podem ser introduzidas em qualquer
62 | fase do ciclo de desenvolvimento, inclusive:
63 |
64 | - No início, ao não identificar as necessidades de segurança
65 |
66 | - Na criação de arquiteturas conceituais que possuam erros de lógica
67 |
68 | - No uso de más práticas de programação que introduzam
69 | vulnerabilidades técnicas
70 |
71 | - Na implementação do software de modo inapropriado
72 |
73 | - Na inserção de falhas durante a manutenção ou a atualização
74 |
75 | Além disso, é importante entender que as vulnerabilidades de software
76 | podem ter um escopo muito maior do que o do próprio software. Dependendo
77 | da natureza do software, da vulnerabilidade e da infraestrutura de
78 | apoio, o impacto de uma exploração bem sucedida pode comprometer
79 | qualquer um, ou mesmo todos os seguintes aspectos:
80 |
81 | - O software e sua informação associada
82 |
83 | - O sistema operacional dos servidores associados
84 |
85 | - A base de dados do *backend*
86 |
87 | - Outras aplicações em um ambiente compartilhado
88 |
89 | - O sistema do usuário
90 |
91 | - Outros softwares com os quais o usuário interage
92 |
--------------------------------------------------------------------------------
/v2/pt/br/03-appendices/05-glossary.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Apêndice B (Glossário) {#glossário .list-paragraph}
3 |
4 | **Agente de Ameaça:** Qualquer entidade que pode causar um impacto
5 | negativo em um sistema. Pode ser tanto um usuário mal-intencionado
6 | querendo comprometer os controles de segurança do sistema, quanto um
7 | desvio acidental do sistema ou uma ameaça física como incêndios ou
8 | inundações.
9 |
10 | **Autenticação:** É um conjunto de controles usados para verificar a
11 | identidade de um usuário, ou outra entidade que interage com o software.
12 |
13 | **Autenticação de Múltiplos Fatores:** É um processo de autenticação que
14 | requer vários tipos de credenciais do usuário. Normalmente é baseado em
15 | algo que ele possui (ex.: cartão inteligente), algo que ele sabe (uma
16 | ex.: senha), ou em algo que ele é (ex.: dados provenientes de um leitor
17 | biométrico).
18 |
19 | **Autenticação Sequencial:** Ocorre quando os dados de autenticação são
20 | solicitados em sucessivas páginas, ao invés de serem solicitados em uma
21 | única página.
22 |
23 | **Canonicalização:** É uma operação realizada para reduzir várias
24 | codificações e representações de dados em uma única forma simplificada.
25 |
26 | **Caracteres Maliciosos:** Quaisquer caracteres ou representações
27 | codificadas de caracteres que podem produzir efeitos indesejáveis sobre
28 | a operação normal de aplicações ou dos sistemas associados quando são
29 | interpretados, por terem significado especial. Estes caracteres podem
30 | ser usados para:
31 |
32 | - Modificar a estrutura de código ou de declarações
33 |
34 | - Inserir código indesejado
35 |
36 | - Modificar caminhos
37 |
38 | - Causar saídas inesperadas das funções ou rotinas dos programas
39 |
40 | - Causar condições de erro
41 |
42 | - Causar qualquer dos efeitos anteriores em aplicações subjacentes
43 |
44 | **Casos de Abuso:** Descrevem o mau uso, intencional ou não, do
45 | software. Os casos de abuso devem desafiar os pressupostos do projeto do
46 | sistema.
47 |
48 | **Codificação de Entidade HTML:** Processo de substituição de
49 | determinados caracteres ASCII pelas entidades HTML equivalentes. Por
50 | exemplo, a codificação poderia substituir o caractere "\<" pela entidade
51 | HTML equivalente \"<\". Essas entidades são "inertes" na maioria dos
52 | interpretadores -- especialmente navegadores -- e podem atenuar os
53 | ataques do lado cliente.
54 |
55 | **Codificação de Saída Baseada em Contexto:** É a codificação de dados
56 | da saída realizada usando como referência o modo como os dados serão
57 | utilizados pela aplicação. Se os dados da saída estiverem incluídos na
58 | resposta ao cliente, deve-se levar em consideração situações como: o
59 | corpo de um documento HTML, um atributo de HTML, codificação JavaScript,
60 | codificação dentro de um CSS ou de uma URL. Devem também ser levados em
61 | consideração outros casos como consultas SQL, XML e LDAP.
62 |
63 | **Codificação de Saída de Dados:** É um conjunto de controles que
64 | abordam o uso de codificação para
65 | garantir uma saída de dados segura gerada pela aplicação.
66 |
67 | **Confidencialidade:** É o ato de garantir que as informações são
68 | divulgadas apenas para as partes autorizadas.
69 |
70 | **Configuração do Sistema:** Conjunto de controles que ajudam a garantir
71 | que os componentes de infraestrutura de apoio ao software são
72 | implantados de forma segura.
73 |
74 | **Consultas Parametrizadas (prepared statements):** Mantém a consulta e
75 | os dados separados através do uso de espaços reservados. A estrutura de
76 | consulta é definida por caracteres especiais que representam os
77 | parâmetros a serem substituídos. A consulta parametrizada é enviada para
78 | o banco de dados, preparada para receber os parâmetros e, em seguida, é
79 | combinada com os valores dos mesmos. Isto impede que a consulta seja
80 | alterada porque os valores dos parâmetros são combinados com a
81 | declaração compilada e não concatenados diretamente na sequência de
82 | caracteres que compõem a consulta SQL.
83 |
84 | **Controle de Acesso**: É um conjunto de controles que libera ou nega o
85 | acesso a um recurso do sistema a um usuário ou outra entidade qualquer.
86 | Normalmente é baseado em regras hierárquicas e privilégios individuais
87 | associados a papéis, porém também inclui interações entre sistemas.
88 |
89 | **Controles de Segurança:** São ações que mitigam uma vulnerabilidade
90 | potencial e ajudam a garantir que o software se comporta conforme o
91 | esperado.
92 |
93 | **Cross Site Request Forgery (CSRF):** Ocorre quando uma aplicação ou
94 | site web externos força o navegador do cliente a realizar uma requisição
95 | involuntária para uma aplicação em que o cliente possua uma sessão
96 | ativa. As aplicações são vulneráveis ao CSRF quando usam URLs e
97 | parâmetros conhecidos ou previsíveis ou quando o navegador transmite
98 | todas as informações da sessão para a aplicação vulnerável de forma
99 | automática em cada solicitação. Esse é apenas um dos ataques discutidos
100 | nesse documento e só está incluído porque a vulnerabilidade associada é
101 | muito comum, porém mal compreendida.
102 |
103 | **Disponibilidade:** É a propriedade de estar acessível e utilizável
104 | quando demandado por uma entidade autorizada.
105 |
106 | **Estado dos Dados:** São dados ou parâmetros usados pela aplicação ou
107 | pelo servidor para emular uma conexão persistente ou controlar o estado
108 | (*status*) de um cliente através de um processo de múltiplas requisições
109 | ou transações.
110 |
111 | **Exploit:** É a ação de aproveitar-se da existência de uma
112 | vulnerabilidade. Normalmente é uma ação intencional e tem como objetivo
113 | comprometer os controles de segurança do software.
114 |
115 | **Gerência de Arquivo:** É um conjunto de controles que resguardam a
116 | interação entre o código da aplicação e os arquivos do sistema.
117 |
118 | > **Gerenciamento de Memória:** É um conjunto de controles que dizem
119 | > respeito ao uso de memória e do buffer.
120 |
121 | **Gerenciamento de Sessão:** É um conjunto de controles que tratam da
122 | manipulação de sessões HTTP de forma segura por aplicações Web.
123 |
124 | **Impacto:** É o efeito negativo perceptível para o negócio, resultante
125 | da ocorrência de um evento indesejável, que por sua vez é o resultado da
126 | exploração de vulnerabilidades.
127 |
128 | **Integridade:** É a garantia de que as informações são precisas,
129 | completas e válidas, e que não foram alteradas por uma ação não
130 | autorizada.
131 |
132 | **Limites de Confiança:** Normalmente, um limite de confiança é
133 | constituído pelos componentes do sistema sobre os quais se tem controle
134 | direto. Todas as conexões e dados do sistema fora desse controle direto
135 | -- incluindo todos os clientes e sistemas gerenciados por terceiros --
136 | devem ser considerados como não confiáveis e necessitam de validação na
137 | fronteira, antes de receberem permissões para realizarem interações com
138 | o sistema.
139 |
140 | **Mitigar:** São medidas tomadas para reduzir o grau de severidade de
141 | uma vulnerabilidade. Essas medidas incluem a remoção de uma
142 | vulnerabilidade, seja ao torná-la mais difícil de ser explorada ou ao
143 | reduzir o impacto negativo de uma exploração bem sucedida.
144 |
145 | **Práticas de Criptografia**: Conjunto de controles para garantir que as
146 | operações de criptografia dentro da aplicação sejam executadas de modo
147 | seguro.
148 |
149 | **Práticas Gerais de Codificação:** Conjunto de controles abrangendo
150 | práticas de codificação que não se encaixam facilmente em outras
151 | categorias.
152 |
153 | **Proteção dos Dados**: Conjunto de controles para ajudar a garantir que
154 | o software trata o armazenamento das informações de modo seguro.
155 |
156 | **Realizar Log dos Eventos:** Esta operação deve incluir os seguintes
157 | requisitos:
158 |
159 | 1. Utilizar um timestamp[^401] proveniente de um sistema
160 | confiável
161 |
162 | 2. Classificar a severidade para cada evento
163 |
164 | 3. Destacar eventos de segurança relevantes, caso eles sejam misturados
165 | com outros registros de log
166 |
167 | 4. Registrar o identificador da conta ou usuário que causou o evento
168 |
169 | 5. Registrar o endereço IP de origem que realizou a requisição
170 |
171 | 6. Registrar o resultado dos eventos (sucesso ou falha)
172 |
173 | 7. Registrar a descrição do evento
174 |
175 | **Requisitos de Segurança:** Conjunto de requisitos funcionais e de
176 | projeto para ajudar a garantir que o software seja construído e
177 | implantado de forma segura.
178 |
179 | **Segurança das Comunicações:** Conjunto de controles para ajudar a
180 | garantir o envio e o recebimento das informações de modo seguro.
181 |
182 | **Segurança de Banco de Dados:** Conjunto de controles para garantir que
183 | o software interaja com os bancos de dados de forma segura e que os
184 | bancos de dados estejam configurados de forma segura.
185 |
186 | **Sistema:** É um termo genérico que abrange sistemas operacionais,
187 | servidores web, frameworks de aplicações e infraestrutura relacionada.
188 |
189 | **Tratamento de Erros e Log:** Conjunto de práticas para garantir que a
190 | aplicação realize o tratamento dos erros de modo seguro e, também
191 | realize o registro de log dos eventos de modo apropriado.
192 |
193 | **Tratamento dos Dados:** É o processo de tornar seguros os dados
194 | potencialmente prejudiciais através do processo de remoção,
195 | substituição, codificação ou *escaping*[^402] dos
196 | caracteres.
197 |
198 | **Validação de Entrada de Dados:** Conjunto de controles para verificar
199 | se as propriedades de todas as entradas de dados correspondem ao que é
200 | esperado pela aplicação, como, por exemplo, tipo dos dados, tamanho,
201 | intervalos, conjunto de caracteres aceitáveis e ausência de caracteres
202 | maliciosos.
203 |
204 | **Vulnerabilidade:** É uma fragilidade que torna um sistema suscetível a
205 | um ataque ou a um dano.
206 |
--------------------------------------------------------------------------------
/v2/pt/br/03-appendices/07-references.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Apêndice C Referências Externas {#referências-externas .list-paragraph}
3 |
4 | ## Referência citada
5 |
6 | - SANS CIS Controls version 8
7 |
8 | >
9 |
10 | - Web Application Security Consortium
11 |
12 | >
13 |
14 | - Common Weakness Enumeration (CWE)
15 |
16 | >
17 |
18 | - Department of Homeland Security: Build Security In Portal
19 |
20 | >
21 |
22 | - CERT Secure Coding
23 |
24 | >
25 |
26 | - MSDN Security Developer Center
27 |
28 | >
29 |
30 | ## Sites de Avisos de Segurança
31 |
32 | Estes links podem ser úteis para verificar e garantir que a infraestrutura
33 | de apoio e os frameworks não possuem vulnerabilidades conhecidas:
34 |
35 | > Secunia Citrix Vulnerability List:
36 |
37 | -
38 |
39 | > Security Focus Vulnerability Search (archived):
40 |
41 | -
42 |
43 | > Common Vulnerability Enumeration:
44 |
45 | -
46 |
--------------------------------------------------------------------------------
/v2/pt/br/03-appendices/08-footnotes.markdown:
--------------------------------------------------------------------------------
1 | [^101]: NT: Complemento adicionado pelo tradutor
2 |
3 | [^301]: NT: [http://pt.wikipedia.org/wiki/Postback]
4 |
5 | [^302]: NT: [http://www.owasp.org/index.php/Double_Encoding]
6 |
7 | [^303]: NT: one-way salted hash é um algoritmo de hash gerado com o auxílio
8 | de valores aleatórios ou pré-definidos que compõem o parâmetro da função de geração da hash
9 | e dificulta o processo de quebra da hash através de ataques de dicionário.
10 | Mais informações sobre o assunto em: [http://en.wikipedia.org/wiki/Salt_(cryptography)]
11 |
12 | [^304]: NT: Complementação explicativa fornecida pelo tradutor.
13 |
14 | [^305]: NT: Robôs são programas de computador que percorrem automaticamente
15 | as páginas da Internet em busca de documentos, com o propósito de indexá-los,
16 | validá-los ou monitorar alterações de conteúdo. [http://pt.wikipedia.org/wiki/Robots.txt]
17 |
18 | [^306]: NT: O link abaixo mostra exemplos de como configurar o arquivo robots.txt.
19 | [http://www.mundoseo.com.br/seo-tecnico/robotstxt-configuracao-seu-site/]
20 |
21 | [^307]: NT: [SQL_Injection_Prevention_Cheat_Sheet](http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet)
22 |
23 | [^401]: NT: Conjunto de caracteres que representa, de forma não ambígua,
24 | o momento do registro da ocorrência de um evento em um sistema.
25 | Para mais informações, ver a RFC 3339 e a norma ISO 8601,
26 | Data elements and interchange formats –- Information interchange –-
27 | Representation of dates and times
28 |
29 | [^402]: NT: Nesse contexto é a representação de
30 | caracteres especiais por conjuntos específicos de caracteres. Como
31 | exemplo, tem-se a substituição do caractere "&" pela entidade HTML
32 | equivalente "&"
33 |
--------------------------------------------------------------------------------
/v2/pt/br/README.md:
--------------------------------------------------------------------------------
1 | # Portuguese (Brazil) language (pt-BR) version
2 |
3 | We appreciate all kinds of [suggestions and corrections][issues] on this translation
4 | of the Secure Coding Practices Quick Reference Guide
5 |
6 | During development manually create the PDF document from directory `pt/br`:
7 |
8 | ```
9 | pandoc -o OWASP_SCP_Quick_Reference_Guide.pt-BR.pdf \
10 | -r markdown+footnotes title.pdf.yaml \
11 | 01-introduction/01-front.markdown \
12 | 01-introduction/02-toc.markdown \
13 | 01-introduction/03-credits.markdown \
14 | 01-introduction/04-copyright.markdown \
15 | 01-introduction/05-introduction.markdown \
16 | 02-checklist/05-checklist.markdown \
17 | 03-appendices/03-overview.markdown \
18 | 03-appendices/05-glossary.markdown \
19 | 03-appendices/07-references.markdown \
20 | 03-appendices/08-footnotes.markdown
21 | ```
22 |
23 | Similarly create the EBook:
24 |
25 | ```
26 | pandoc -o OWASP_SCP_Quick_Reference_Guide.pt-BR.epub \
27 | -r markdown+footnotes title.yaml \
28 | 01-introduction/01-front.markdown \
29 | 01-introduction/02-toc.markdown \
30 | 01-introduction/03-credits.markdown \
31 | 01-introduction/04-copyright.markdown \
32 | 01-introduction/05-introduction.markdown \
33 | 02-checklist/05-checklist.markdown \
34 | 03-appendices/03-overview.markdown \
35 | 03-appendices/05-glossary.markdown \
36 | 03-appendices/07-references.markdown \
37 | 03-appendices/08-footnotes.markdown
38 | ```
39 |
40 | There is a dependency on having a *tex installed that will provide pdflatex for the PDF output.
41 | For example with MacOS the command `brew install basictex` can be used.
42 |
43 | [issues]: https://github.com/OWASP/www-project-secure-coding-practices-quick-reference-guide/issues/new
44 |
--------------------------------------------------------------------------------
/v2/pt/br/title.pdf.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | language: pt-BR
3 | author: Open Worldwide Application Security Project (OWASP)
4 | version: 2.0.1
5 | date: dezembro de 2022
6 | rights: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
7 | geometry: "left=3cm,right=2.5cm,top=2cm,bottom=2.5cm"
8 | header-includes: |
9 | \usepackage{fancyhdr}
10 | \pagestyle{fancy}
11 | \fancyhead{}
12 | \fancyhead[RE,RO]{Dezembro 2022}
13 | \fancyfoot{}
14 | \fancyfoot[LE,LO]{Versão 2.0.1}
15 | \fancyfoot[RE,RO]{\thepage}
16 | ...
17 |
--------------------------------------------------------------------------------
/v2/pt/br/title.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: pt-BR
3 | title:
4 | - type: main
5 | text: Melhores Práticas de Codificação Segura OWASP
6 | - type: subtitle
7 | text: Guia de Referência Rápida
8 | creator:
9 | - role: author
10 | text: Open Worldwide Application Security Project (OWASP)
11 | - role: editor
12 | text: Keith Turpin
13 | version: 2.0.1
14 | date: dezembro de 2022
15 | rights: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
16 | ...
17 |
--------------------------------------------------------------------------------
/v2/pt/pt/01-introduction/01-front.markdown:
--------------------------------------------------------------------------------
1 | {width="3.0in"}
2 |
3 | # Melhores Práticas de Codificação Segura OWASP
4 |
5 | ## Guia de Referência Rápida
6 |
--------------------------------------------------------------------------------
/v2/pt/pt/01-introduction/02-toc.markdown:
--------------------------------------------------------------------------------
1 | # Sumário {#table-of-contents .TOC-Heading}
2 |
3 | [Introdução](#introdução)
4 |
5 | [Lista de Verificação de Práticas de Programação Segura](#lista-de-verificação-de-práticas-de-programação-segura)
6 |
7 | [Validação dos Dados de Entrada](#validação-dos-dados-de-entrada)
8 |
9 | [Codificação de Dados de Saída](#codificação-de-dados-de-saída)
10 |
11 | [Autenticação e Gestão de Credenciais](#autenticação-e-gestão-de-credenciais)
12 |
13 | [Gestão de Sessões](#gestão-de-sessões)
14 |
15 | [Controlo de Acessos](#controlo-de-acessos)
16 |
17 | [Práticas de Criptografia](#práticas-de-criptografia)
18 |
19 | [Tratamento de Erros e Log](#tratamento-de-erros-e-log)
20 |
21 | [Proteção de Dados](#proteção-de-dados)
22 |
23 | [Segurança nas comunicações](#segurança-nas-comunicações)
24 |
25 | [Configuração do Sistema](#configuração-do-sistema)
26 |
27 | [Segurança em Base de Dados](#segurança-em-base-de-dados)
28 |
29 | [Gestão de Ficheiros](#gestão-de-ficheiros)
30 |
31 | [Gestão de Memória](#gestão-de-memória)
32 |
33 | [Práticas Gerais de Programação](#práticas-gerais-de-programação)
34 |
35 | [Apêndice A Princípios Gerais de Segurança em Aplicações e Riscos](#princípios-gerais-de-segurança-em-aplicações-e-riscos)
36 |
37 | [Apêndice B Glossário](#glossário)
38 |
39 | [Apêndice C Referências Externas](#referências-externas)
40 |
--------------------------------------------------------------------------------
/v2/pt/pt/01-introduction/03-credits.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | **Notas da versão**
3 |
4 | Esta versão do OWASP *Secure Coding Practices* foi desenvolvida como
5 | parte integrante da atividade conjunta dos capítulos brasileiro e
6 | português da OWASP, em prol da comunidade de programadores e da
7 | segurança dos sistemas desenvolvidos nos países de língua portuguesa.
8 | Este documento é baseado na versão
9 |
10 | 2.0 de Novembro de 2010 e na revisão da primeira tradução, versão 1.2,
11 | datada de Julho de 2011.
12 |
13 | Líder do projeto de tradução:
14 |
15 | - Tarcizio Vieira Neto --
16 | [tarcizio.vieira@owasp.org](mailto:tarcizio.vieira@owasp.org)
17 | -- Brasil
18 |
19 | Participaram desta tradução:
20 |
21 | - Leandro Resende Gomes --
22 | [leandrock@gmail.com](mailto:leandrock@gmail.com) --
23 | Brasil
24 |
25 | - Sílvio Fernando Correia Vieira Filho --
26 | [silviofilhosf@gmail.com](mailto:silviofilhosf@gmail.com)
27 | -- Brasil
28 |
29 | - Paulo Alexandre Silva --
30 | [me@pauloasilva.com](mailto:me@pauloasilva.com) --
31 | Portugal
32 |
33 | - Alexandre Pupo --
34 | [alexandrepupo@yahoo.com.br](mailto:alexandrepupo@yahoo.com.br)
35 | -- Brasil
36 |
37 | - Carlos Serrão --
38 | [carlos.serrao@owasp.org](mailto:carlos.serrao@owasp.org)
39 | -- Portugal
40 |
41 | - Rogério Vicente --
42 | [rogeriopvl@gmail.com](mailto:rogeriopvl@gmail.com)
43 | -- Portugal
44 |
45 | - Jorge Olimpia --
46 | [jorgeolimpia@gmail.com](mailto:jorgeolimpia@gmail.com)
47 | -- Brasil
48 |
49 | A tradução deste documento pretende-se fiel ao texto original, tendo
50 | sido introduzidos alguns detalhes explicativos que estão dispersos no
51 | texto, assumindo, nalguns casos, a forma de notas de rodapé contendo o
52 | prefixo "NT:" (nota de tradução).
53 |
54 | Para saber mais sobre os eventos e atividades desenvolvidas pelo
55 | capítulo Brasil, aceda à página
56 | ([http://www.owasp.org/index.php/Brazil])
57 | ou registe-se na lista de discussão OWASP-BR
58 | ([http://lists.owasp.org/mailman/listinfo/owasp-brazilian]).
59 |
60 | Para saber mais sobre os eventos e atividades desenvolvidas pela
61 | delegação da OWASP em Portugal, aceda à página
62 | ([http://www.owasp.org/index.php/Portuguese])
63 | ou registe-se na lista de discussão OWASP-PT
64 | ([https://lists.owasp.org/mailman/listinfo/owasp-portuguese]).
65 |
--------------------------------------------------------------------------------
/v2/pt/pt/01-introduction/04-copyright.markdown:
--------------------------------------------------------------------------------
1 | **Copyright and License**
2 |
3 | Copyright © 2010-2023 The OWASP Foundation.
4 |
5 | O conteúdo deste documento é distribuído ao abrigo da licença
6 | Creative Commons Attribution-ShareAlike 4.0 International [(CC BY-SA 4.0)][CC-BY-SA-4.0].
7 | Para a utilização ou redistribuição, deve deixar claro os termos da licença deste trabalho.
8 |
9 | [CC-BY-SA-4.0]: https://creativecommons.org/licenses/by-sa/4.0/deed.pt
10 |
--------------------------------------------------------------------------------
/v2/pt/pt/01-introduction/05-introduction.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Introdução
3 |
4 | Este documento não se baseia apenas em questões tecnológicas e tem o
5 | propósito de definir um conjunto de boas práticas de segurança no
6 | desenvolvimento de aplicações. As recomendações serão apresentadas no
7 | formato de lista de verificações, que podem ser integradas no ciclo de
8 | desenvolvimento das aplicações. A adoção destas práticas provavelmente
9 | reduzirá as vulnerabilidades mais comuns em aplicações Web.
10 |
11 | Geralmente é mais barato construir software seguro do que corrigir
12 | problemas de segurança após a entrega do mesmo como um produto final ou
13 | pacote completo, sem falar nos custos que podem estar associados a uma
14 | falha de segurança.
15 |
16 | Proteger os recursos críticos das aplicações tem-se tornado cada vez
17 | mais importante, pois o foco dos atacantes mudou para a camada de
18 | aplicação. Um estudo da SANS em 2009[^101] descobriu que os ataques
19 | contra aplicações Web constituem mais de 60% do total das tentativas de
20 | ataque observadas na Internet.
21 |
22 | Ao utilizar este guia é recomendável que as equipas de desenvolvimento
23 | avaliem a maturidade do ciclo de vida de desenvolvimento de software e o
24 | nível de conhecimento da equipa. Como este guia não entra em detalhes de
25 | como implantar cada prática de programação, os programadores precisam
26 | possuir conhecimento prévio ou devem ter disponíveis os recursos que
27 | forneçam o conhecimento necessário. Este guia apresenta práticas que
28 | podem ser traduzidas em requisitos de desenvolvimento sem a necessidade
29 | do programador possuir uma compreensão aprofundada das vulnerabilidades
30 | e *exploits* de segurança. No entanto, outros membros da equipa de
31 | desenvolvimento devem possuir responsabilidades, competências adequadas,
32 | ferramentas e recursos para validar se o projeto e a implementação
33 | respondem aos requisitos de segurança.
34 |
35 | No apêndice B encontra-se um glossário dos termos importantes usados
36 | neste documento, incluindo o título das secções e palavras mostradas em
37 | *itálico*.
38 |
39 | Não faz parte do âmbito deste guia fornecer orientações para implementar
40 | uma *framework* de desenvolvimento seguro de software, no entanto, as
41 | seguintes práticas gerais e referências são recomendadas:
42 |
43 | - Definir claramente os papéis e responsabilidades
44 |
45 | - Fornecer às equipas de desenvolvimento, pessoal com formação
46 | adequada em segurança no desenvolvimento de aplicações
47 |
48 | - Implementar um ciclo de desenvolvimento de software seguro
49 |
50 | - Estabelecer padrões de programação segura
51 |
52 | - [OWASP Development Guide][guide] Project
53 |
54 | - Construir uma biblioteca reutilizável ou fazer uso de uma biblioteca
55 | de segurança[^101]
56 |
57 | - [OWASP Enterprise Security API][esapi] (ESAPI) Project
58 |
59 | - Verificar a efetividade dos mecanismos de segurança
60 |
61 | - [OWASP Application Security Verification Standard][asvs] (ASVS) Project
62 |
63 | - Estabelecer práticas para garantir a segurança quando há
64 | subcontratação no desenvolvimento, incluindo a definição dos
65 | requisitos de segurança e metodologias de verificação tanto para
66 | os requisitos das propostas, como para o contrato a ser firmado
67 | entre as partes.
68 |
69 | [asvs]: https://owasp.org/www-project-application-security-verification-standard/
70 | [esapi]: https://owasp.org/www-project-enterprise-security-api/
71 | [guide]: http://www.owasp.org/index.php/Category:OWASP_Guide_Project
72 |
--------------------------------------------------------------------------------
/v2/pt/pt/03-appendices/03-overview.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Apêndice A Princípios Gerais de Segurança em Aplicações e Riscos {#princípios-gerais-de-segurança-em-aplicações-e-riscos .list-paragraph}
3 |
4 | Construir software seguro exige o conhecimento básico dos princípios de
5 | segurança. Uma revisão abrangente dos princípios de segurança está fora
6 | do âmbito deste guia, porém os conceitos de segurança serão abordados de
7 | forma superficial, mas abrangente.
8 |
9 | O objetivo da segurança em aplicações é manter a *confidencialidade*,
10 | *integridade* e *disponibilidade* dos recursos de informação a fim de
11 | permitir que as operações de negócios sejam bem sucedidas. Esse objetivo
12 | é alcançado através da implementação de *mecanismos de segurança*. Este
13 | guia concentra-se nos mecanismos técnicos, específicos para *mitigar* as
14 | ocorrências de *vulnerabilidades* mais comuns no software. Como o foco
15 | principal são as aplicações Web e sua infraestrutura de apoio, boa parte
16 | deste guia pode ser usada para qualquer plataforma de desenvolvimento de
17 | software.
18 |
19 | Para proteger o negócio contra os riscos inaceitáveis, isto é,
20 | relacionados com a dependência e com a confiança depositada na
21 | aplicação, este guia ajuda a compreender o que podemos entender por
22 | risco. Deste modo, risco é a combinação de fatores que ameaçam o sucesso
23 | do negócio. Isto pode ser descrito concetualmente da seguinte forma: um
24 | *agente de ameaça* interage com um *sistema*, no qual pode haver uma
25 | *vulnerabilidade* latente que quando *explorada* causa um *impacto*.
26 | Como isto pode parecer um conceito abstrato, pense do seguinte modo: um
27 | ladrão de carros (agente de ameaça) passa por um estacionamento
28 | verificando nos carros presentes (o sistema) a existência de portas
29 | destrancadas (a vulnerabilidade) e quando a encontra, abre a porta (a
30 | exploração) e leva para si o que está dentro do carro (o impacto). Todos
31 | esses fatores desempenham um papel no desenvolvimento de software
32 | seguro.
33 |
34 | Existe uma diferença fundamental entre a abordagem adotada por uma
35 | equipa de desenvolvimento e a abordagem que é adotada por alguém que
36 | está interessado em atacar uma aplicação. Uma equipa de desenvolvimento
37 | normalmente desenvolve uma aplicação com base naquilo que ela pretende
38 | fazer. Isso significa criar uma aplicação para executar tarefas
39 | específicas baseadas em requisitos funcionais e casos de uso
40 | documentados. Um atacante, por outro lado, está mais interessado no que
41 | a aplicação pode ser levada a fazer e parte do princípio que \"qualquer
42 | ação não expressamente proibida, é permitida\". Para resolver isso,
43 | alguns elementos adicionais precisam ser integrados nas fases iniciais
44 | do ciclo de vida do software. Esses novos elementos são *requisitos de
45 | segurança* e *casos de abuso.* Este guia foi construído para ajudar a
46 | identificar os requisitos de segurança de alto nível e abordar vários
47 | cenários de ataque.
48 |
49 | É importante que as equipas de desenvolvimento de aplicações Web
50 | entendam que os mecanismos de controlo do lado cliente, como validação
51 | de dados de entrada no cliente, campos ocultos e controlos de interface
52 | (combo box, radio buttons), fornecem pouco ou nenhum benefício de
53 | segurança. Nesse caso, um atacante pode usar ferramentas como *proxies*
54 | do lado do cliente, como o OWASP WebScarab, Burp ou ferramentas de
55 | captura de pacotes de rede, como o Wireshark, para analisar o tráfego da
56 | aplicação e enviar pedidos manipulados, burlando todas as interfaces.
57 | Além disso, o Flash, os Applets Java e demais objetos que trabalham no
58 | lado cliente podem ser alvo de engenharia reversa e analisados em busca
59 | de falhas.
60 |
61 | As falhas de segurança de software podem ser introduzidas em qualquer
62 | fase do ciclo de desenvolvimento, inclusive:
63 |
64 | - No início, ao não identificar as necessidades de segurança
65 |
66 | - Na criação de arquiteturas conceptuais que possuam erros de lógica
67 |
68 | - No uso de más práticas de programação que introduzam
69 | vulnerabilidades técnicas
70 |
71 | - Na implementação do software de modo inapropriado
72 |
73 | - Na inserção de falhas durante a manutenção ou a atualização
74 |
75 | Além disso, é importante entender que as vulnerabilidades de software
76 | podem ter um âmbito muito maior do que o do próprio software. Dependendo
77 | da natureza do software, da vulnerabilidade e da infraestrutura de
78 | apoio, o impacto de uma exploração bem sucedida pode comprometer
79 | qualquer um, ou mesmo todos os seguintes aspetos:
80 |
81 | - O software e sua informação associada
82 |
83 | - O sistema operativo dos servidores associados
84 |
85 | - A base de dados do *backend*
86 |
87 | - Outras aplicações num ambiente partilhado
88 |
89 | - O sistema do utilizador
90 |
91 | - Outros softwares com os quais o utilizador interage
92 |
--------------------------------------------------------------------------------
/v2/pt/pt/03-appendices/05-glossary.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Apêndice B Glossário {#glossário .list-paragraph}
3 |
4 | **Agente de Ameaça:** Qualquer entidade que pode causar um impacto
5 | negativo num sistema. Pode ser tanto um utilizador mal-intencionado
6 | querendo comprometer os controlos de segurança do sistema, quanto um
7 | desvio acidental do sistema ou uma ameaça física como incêndios ou
8 | inundações.
9 |
10 | **Autenticação:** É um conjunto de controlos usados para verificar a
11 | identidade de um utilizador, ou outra entidade que interage com o
12 | software.
13 |
14 | **Autenticação de Múltiplos Fatores:** É um processo de autenticação que
15 | requer vários tipos de credenciais do utilizador. Normalmente é baseado
16 | em algo que ele possui (ex.: cartão inteligente), algo que ele sabe (uma
17 | ex.: senha), ou em algo que ele é (ex.: dados provenientes de um leitor
18 | biométrico).
19 |
20 | **Autenticação Sequencial:** Ocorre quando os dados de autenticação são
21 | solicitados em sucessivas páginas, ao invés de serem solicitados numa
22 | única página.
23 |
24 | **Canonicalização:** É uma operação realizada para reduzir várias
25 | codificações e representações de dados numa única forma simplificada.
26 |
27 | **Caracteres Maliciosos:** Quaisquer caracteres ou representações
28 | codificadas de caracteres que podem produzir efeitos indesejáveis sobre
29 | a operação normal de aplicações ou dos sistemas associados quando são
30 | interpretados, por terem significado especial. Estes caracteres podem
31 | ser usados para:
32 |
33 | - Modificar a estrutura de código ou de declarações
34 |
35 | - Inserir código indesejado
36 |
37 | - Modificar caminhos
38 |
39 | - Causar saídas inesperadas das funções ou rotinas dos programas
40 |
41 | - Causar condições de erro
42 |
43 | - Causar qualquer dos efeitos anteriores em aplicações subjacentes
44 |
45 | **Casos de Abuso:** Descrevem o mau uso, intencional ou não, do
46 | software. Os casos de abuso devem desafiar os pressupostos do projeto do
47 | sistema.
48 |
49 | **Codificação de Entidade HTML:** Processo de substituição de
50 | determinados caracteres ASCII pelas entidades HTML equivalentes. Por
51 | exemplo, a codificação poderia substituir o caractere "\<" pela entidade
52 | HTML equivalente \"<\". Essas entidades são "inertes" na maioria dos
53 | interpretadores --especialmente navegadores-- e podem atenuar os ataques
54 | do lado do cliente.
55 |
56 | **Codificação de Saída Baseada em Contexto:** É a codificação de dados
57 | da saída realizada usando como referência o modo como os dados serão
58 | utilizados pela aplicação. Se os dados da saída estiverem incluídos na
59 | resposta ao cliente, deve-se levar em consideração situações como: o
60 | corpo de um documento HTML, um atributo de HTML, codificação JavaScript,
61 | codificação dentro de um CSS ou de uma URL. Devem também ser levados em
62 | consideração outros casos como consultas SQL, XML e LDAP.
63 |
64 | **Codificação de Saída de Dados:** É um conjunto de controlos que
65 | abordam o uso de codificação para
66 |
67 | garantir uma saída de dados segura gerada pela aplicação.
68 |
69 | **Confidencialidade:** É o ato de garantir que as informações são
70 | divulgadas apenas para as partes autorizadas.
71 |
72 | **Configuração do Sistema:** Conjunto de controlos que ajudam a garantir
73 | que os componentes de infraestrutura de apoio ao software são
74 | disponibilizados de forma segura.
75 |
76 | **Consultas Parametrizadas (prepared statements):** Mantém a consulta e
77 | os dados separados através do uso de espaços reservados. A estrutura de
78 | consulta é definida por caracteres especiais que representam os
79 | parâmetros a serem substituídos. A consulta parametrizada é enviada para
80 | a base de dados e preparada para receber os parâmetros e, em seguida, é
81 | combinada com os valores dos mesmos. Isto impede que a consulta seja
82 | alterada porque os valores dos parâmetros são combinados com a
83 | declaração compilada e não concatenados diretamente na sequência de
84 | caracteres que compõem a consulta SQL.
85 |
86 | **Controle de Acesso**: É um conjunto de controlos que liberta ou nega o
87 | acesso a um recurso do sistema a um utilizador ou outra entidade
88 | qualquer. Normalmente é baseado em regras hierárquicas e privilégios
89 | individuais associados a papéis, porém também inclui interações entre
90 | sistemas.
91 |
92 | **Controles de Segurança:** São ações que mitigam uma vulnerabilidade
93 | potencial e ajudam a garantir que o software se comporta conforme o
94 | esperado.
95 |
96 | **Cross Site Request Forgery (CSRF):** Ocorre quando uma aplicação ou
97 | site web externos forçam o navegador do cliente a realizar um pedido
98 | involuntário para uma aplicação em que o cliente possui uma sessão
99 | ativa. As aplicações são vulneráveis ao CSRF quando usam URLs e
100 | parâmetros conhecidos ou previsíveis ou quando o navegador transmite
101 | todas as informações da sessão para a aplicação vulnerável de forma
102 | automática em cada solicitação. Este é apenas um dos ataques discutidos
103 | neste documento e só está incluído porque a vulnerabilidade associada é
104 | muito comum, porém mal compreendida.
105 |
106 | **Disponibilidade:** É a propriedade de estar acessível e utilizável
107 | quando solicitado por uma entidade autorizada.
108 |
109 | **Estado dos Dados:** São dados ou parâmetros usados pela aplicação ou
110 | pelo servidor para emular uma ligação persistente ou controlar o estado
111 | (status) de um cliente através de um processo de múltiplas pedidos ou
112 | transações.
113 |
114 | **Exploit:** É a ação de aproveitar-se da existência de uma
115 | vulnerabilidade. Normalmente é uma ação intencional e tem como objetivo
116 | comprometer os controles de segurança do software.
117 |
118 | **Gestão de Ficheiros:** É um conjunto de controlos que resguardam a
119 | interação entre o código da aplicação e os ficheiros do sistema.
120 |
121 | **Gestão de Memória:** É um conjunto de controlos que dizem respeito ao
122 | uso de memória e do buffer.
123 |
124 | **Gestão de Sessão:** É um conjunto de controlos que tratam da
125 | manipulação de sessões HTTP de forma segura por aplicações Web.
126 |
127 | **Impacto:** É o efeito negativo percetível para o negócio, resultante
128 | da ocorrência de um evento indesejável, que por sua vez é o resultado da
129 | exploração de vulnerabilidades.
130 |
131 | **Integridade:** É a garantia de que as informações são precisas,
132 | completas e válidas, e que não foram alteradas por uma ação não
133 | autorizada.
134 |
135 | **Limites de Confiança:** Normalmente, um limite de confiança é
136 | constituído pelos componentes do sistema sobre os quais se tem controlo
137 | direto. Todas as ligações e dados do sistema fora deste controlo direto
138 | -- incluindo todos os clientes e sistemas geridos por terceiros -- devem
139 | ser considerados como não sendo de confiança e necessitam de validação
140 | na fronteira, antes de receberem permissões para realizarem interações
141 | com o sistema.
142 |
143 | **Mitigar:** São medidas tomadas para reduzir o grau de severidade de
144 | uma vulnerabilidade. Essas medidas incluem a remoção de uma
145 | vulnerabilidade, seja ao torná-la mais difícil de ser explorada, ou ao
146 | reduzir o impacto negativo de uma exploração bem sucedida.
147 |
148 | **Práticas de Criptografia**: Conjunto de controlos para garantir que as
149 | operações de criptografia dentro da aplicação são executadas de modo
150 | seguro.
151 |
152 | **Práticas Gerais de Programação:** Conjunto de controlos abrangendo
153 | práticas de codificação que não se encaixam facilmente noutras
154 | categorias.
155 |
156 | **Proteção dos Dados**: Conjunto de controlos para ajudar a garantir que
157 | o software trata o armazenamento das informações de modo seguro.
158 |
159 | **Realizar Log dos Eventos:** Esta operação deve incluir os seguintes
160 | requisitos:
161 |
162 | 1. Utilizar um timestamp[^401] proveniente de um sistema de
163 | confiança
164 |
165 | 2. Classificar a gravidade para cada evento
166 |
167 | 3. Destacar eventos de segurança relevantes, caso eles sejam misturados
168 | com outros registros de log
169 |
170 | 4. Registar o identificador da conta ou utilizador que causou o evento
171 |
172 | 5. Registar o endereço IP de origem que realizou o pedido
173 |
174 | 6. Registar o resultado dos eventos (sucesso ou falha)
175 |
176 | 7. Registar a descrição do evento
177 |
178 | **Requisitos de Segurança:** Conjunto de requisitos funcionais e de
179 | projeto para ajudar a garantir que o software é construído e
180 | disponibilizado de forma segura.
181 |
182 | **Segurança das Comunicações:** Conjunto de controlos para ajudar a
183 | garantir o envio e o recebimento das informações de modo seguro.
184 |
185 | **Segurança da Base de Dados:** Conjunto de controlos para garantir que
186 | o software interage com as bases de dados de forma segura e que as bases
187 | de dados estão configuradas de forma segura.
188 |
189 | **Sistema:** É um termo genérico que abrange sistemas operativos,
190 | servidores web, frameworks de aplicações e infraestrutura relacionada.
191 |
192 | **Tratamento de Erros e Log:** Conjunto de práticas para garantir que a
193 | aplicação realiza o tratamento dos erros de modo seguro e, também
194 | realiza o registo de log dos eventos de modo apropriado.
195 |
196 | **Tratamento dos Dados:** É o processo de tornar seguros os dados
197 | potencialmente prejudiciais através do processo de remoção,
198 | substituição, codificação ou *escaping*[^402] dos
199 | caracteres.
200 |
201 | **Validação de Entrada de Dados:** Conjunto de controlos para verificar
202 | se as propriedades de todas as entradas de dados correspondem ao que é
203 | esperado pela aplicação, como, por exemplo, tipo dos dados, tamanho,
204 | intervalos e conjunto de caracteres aceitáveis que não contenham
205 | caracteres maliciosos.
206 |
207 | **Vulnerabilidade:** É uma fragilidade que torna um sistema suscetível a
208 | um ataque ou a um dano.
209 |
--------------------------------------------------------------------------------
/v2/pt/pt/03-appendices/07-references.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # Apêndice C Referências Externas {#referências-externas .list-paragraph}
3 |
4 | ## Referência citada
5 |
6 | - SANS CIS Controls version 8
7 |
8 | >
9 |
10 | - Web Application Security Consortium
11 |
12 | >
13 |
14 | - Common Weakness Enumeration (CWE)
15 |
16 | >
17 |
18 | - Department of Homeland Security: Build Security In Portal
19 |
20 | >
21 |
22 | - CERT Secure Coding
23 |
24 | >
25 |
26 | - MSDN Security Developer Center
27 |
28 | >
29 |
30 | ## Sites de Avisos de Segurança
31 |
32 | Estes links podem ser úteis para verificar e garantir que a infraestrutura
33 | de apoio e os frameworks não possuem vulnerabilidades conhecidas:
34 |
35 | > Secunia Citrix Vulnerability List:
36 |
37 | -
38 |
39 | > Security Focus Vulnerability Search (archived):
40 |
41 | -
42 |
43 | > Common Vulnerability Enumeration:
44 |
45 | -
46 |
--------------------------------------------------------------------------------
/v2/pt/pt/03-appendices/08-footnotes.markdown:
--------------------------------------------------------------------------------
1 | [^101]: NT: Complemento adicionado pelo tradutor
2 |
3 | [^301]: NT: [http://pt.wikipedia.org/wiki/Postback]
4 |
5 | [^302]: NT: [http://www.owasp.org/index.php/Double_Encoding]
6 |
7 | [^303]: NT: *one-way salted hash* é um algoritmo de *hash* gerado com
8 | auxílio de valores aleatórios ou pré-definidos que compõem o parâmetro
9 | da função de geração da *hash* e dificulta o processo de quebra da
10 | *hash* através de ataques de dicionário. Mais sobre o assunto em:
11 | [http://en.wikipedia.org/wiki/Salt\_(cryptography)]
12 |
13 | [^304]: NT: Complementação explicativa fornecida pelo tradutor
14 |
15 | [^305]: NT: Robôs são programas de computador que
16 | percorrem automaticamente as páginas da Internet em busca de
17 | documentos, com o propósito de indexá-los, validá-los ou monitorar
18 | alterações de conteúdo. [http://pt.wikipedia.org/wiki/Robots.txt]
19 |
20 | [^306]: NT: o link abaixo mostra exemplos de como configurar o arquivo robots.txt.
21 | [http://www.mundoseo.com.br/seo-tecnico/robotstxt-configuracao-seu-site/]
22 |
23 | [^307]: NT: [SQL_Injection_Prevention_Cheat_Sheet](http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet)
24 |
25 | [^401]: NT: Conjunto de caracteres que representa,
26 | de forma não ambígua, o momento do registro da ocorrência de um evento
27 | num sistema. Para mais informações, ver a RFC 3339 e a norma ISO 8601,
28 | Data elements and interchange formats -- Information interchange --
29 | Representation of dates and times
30 |
31 | [^402]: NT: Nesse contexto é a representação de
32 | caracteres especiais por conjuntos específicos de caracteres. Como
33 | exemplo, tem-se a substituição do caractere "&" pela entidade HTML
34 | equivalente "&"
35 |
--------------------------------------------------------------------------------
/v2/pt/pt/README.md:
--------------------------------------------------------------------------------
1 | # Portuguese language (pt-PT) version
2 |
3 | We appreciate all kinds of [suggestions and corrections][issues] on this translation
4 | of the Secure Coding Practices Quick Reference Guide
5 |
6 | During development manually create the PDF document from directory `pt/pt`:
7 |
8 | ```
9 | pandoc -o OWASP_SCP_Quick_Reference_Guide.pt-PT.pdf \
10 | -r markdown+footnotes title.pdf.yaml \
11 | 01-introduction/01-front.markdown \
12 | 01-introduction/02-toc.markdown \
13 | 01-introduction/03-credits.markdown \
14 | 01-introduction/04-copyright.markdown \
15 | 01-introduction/05-introduction.markdown \
16 | 02-checklist/05-checklist.markdown \
17 | 03-appendices/03-overview.markdown \
18 | 03-appendices/05-glossary.markdown \
19 | 03-appendices/07-references.markdown \
20 | 03-appendices/08-footnotes.markdown
21 | ```
22 |
23 | Similarly create the EBook:
24 |
25 | ```
26 | pandoc -o OWASP_SCP_Quick_Reference_Guide.pt-PT.epub \
27 | -r markdown+footnotes title.yaml \
28 | 01-introduction/01-front.markdown \
29 | 01-introduction/02-toc.markdown \
30 | 01-introduction/03-credits.markdown \
31 | 01-introduction/04-copyright.markdown \
32 | 01-introduction/05-introduction.markdown \
33 | 02-checklist/05-checklist.markdown \
34 | 03-appendices/03-overview.markdown \
35 | 03-appendices/05-glossary.markdown \
36 | 03-appendices/07-references.markdown \
37 | 03-appendices/08-footnotes.markdown
38 | ```
39 |
40 | There is a dependency on having a *tex installed that will provide pdflatex for the PDF output.
41 | For example with MacOS the command `brew install basictex` can be used.
42 |
43 | [issues]: https://github.com/OWASP/www-project-secure-coding-practices-quick-reference-guide/issues/new
44 |
--------------------------------------------------------------------------------
/v2/pt/pt/title.pdf.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: pt-PT
3 | author: Open Worldwide Application Security Project (OWASP)
4 | version: 2.0.1
5 | date: dezembro de 2022
6 | rights: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
7 | geometry: "left=3cm,right=2.5cm,top=2cm,bottom=2.5cm"
8 | header-includes: |
9 | \usepackage{fancyhdr}
10 | \pagestyle{fancy}
11 | \fancyhead{}
12 | \fancyhead[RE,RO]{Dezembro 2022}
13 | \fancyfoot{}
14 | \fancyfoot[LE,LO]{Version 2.0.1}
15 | \fancyfoot[RE,RO]{\thepage}
16 | ...
17 |
--------------------------------------------------------------------------------
/v2/pt/pt/title.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: pt-PT
3 | title:
4 | - type: main
5 | text: Melhores Práticas de Programação Segura OWASP
6 | - type: subtitle
7 | text: Guia de Referência Rápida
8 | creator:
9 | - role: author
10 | text: Open Worldwide Application Security Project (OWASP)
11 | - role: editor
12 | text: Keith Turpin
13 | version: 2.0.1
14 | date: dezembro de 2022
15 | rights: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
16 | ...
17 |
--------------------------------------------------------------------------------
/v2/zh/cn/01-introduction/01-front.markdown:
--------------------------------------------------------------------------------
1 | {width="3.0in"}
2 |
3 | OWASP 安全编码规范快速参考指南
4 |
--------------------------------------------------------------------------------
/v2/zh/cn/01-introduction/02-toc.markdown:
--------------------------------------------------------------------------------
1 | # 目录 {#table-of-contents .TOC-Heading}
2 |
3 | [序言](#序言)
4 |
5 | [输入验证](#输入验证)
6 |
7 | [输出编码](#输出编码)
8 |
9 | [身份验证和密码管理](#身份验证和密码管理)
10 |
11 | [会话管理](#会话管理)
12 |
13 | [访问控制](#访问控制)
14 |
15 | [加密规范](#加密规范)
16 |
17 | [错误处理和日志](#错误处理和日志)
18 |
19 | [数据保护](#数据保护)
20 |
21 | [通讯安全](#通讯安全)
22 |
23 | [系统配置](#系统配置)
24 |
25 | [数据库安全](#数据库安全)
26 |
27 | [文件管理](#文件管理)
28 |
29 | [内存管理](#内存管理)
30 |
31 | [通用编码规范](#通用编码规范)
32 |
33 | [附录 A: 软件安全与风险原则概览](#软件安全与风险原则概览)
34 |
35 | [附录 B: 术语表](#术语表)
36 |
37 | [附录 C: 外部的参考资料](#外部的参考资料)
38 |
--------------------------------------------------------------------------------
/v2/zh/cn/01-introduction/03-credits.markdown:
--------------------------------------------------------------------------------
1 | # 中文版本团队成员
2 |
3 | 王颉 何勇亮 林恒辉
4 |
5 | (欢迎大家指正翻译错误。我们将在以后的版本中修正指出的错误。)
6 |
--------------------------------------------------------------------------------
/v2/zh/cn/01-introduction/04-copyright.markdown:
--------------------------------------------------------------------------------
1 | **版权与许可**
2 |
3 | 版权所有:2012-2022 年 OWASP基金会©
4 |
5 | 本文档基于 Creative Commons Attribution-ShareAlike 4.0 International [(CC BY-SA 4.0)][CC-BY-SA-4.0] license 发布。任何重用或发行,
6 | 都必须向他人明确该文档的许可条款。
7 |
8 | [CC-BY-SA-4.0]: https://creativecommons.org/licenses/by-sa/4.0/deed.zh_CN
9 |
--------------------------------------------------------------------------------
/v2/zh/cn/01-introduction/05-introduction.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # 序言
3 |
4 | 本项与技术无关的文档以清单列表的形式,定义了一套可以集成到软件开发生命周期中的通
5 | 用软件安全编码规范。采用这些规范将减少最为常见的软件漏洞。
6 |
7 | 一般来说,开发安全的软件要比在软件包完成以后再纠正安全问题的成本低很多,且还没涉
8 | 及到因为安全问题而造成的损失。
9 |
10 | 保护关键软件资源的安全性,比以往任何时候都更为重要,因为攻击者的重点已逐步转向了
11 | 应用层。2009 年 SANS 的一项研究表明,针对 Web 应用程序的攻击已占据了在互联网上
12 | 观察到攻击总数的 60%以上。
13 |
14 | 在使用本指南时,开发团队应该从评估他们的安全软件开发生命周期成熟度和开发人员知识
15 | 水平着手。由于本指南不涉及如何实现每个编码规范的具体细节,因此,开发人员需要了解
16 | 相关知识,或者有足够可用资源来提供必要的指导。通过本指南,开发人员可在无需深入了
17 | 解安全漏洞和攻击的情况下,将编码规范转换成编码要求。当然,开发团队的其他成员应该
18 | 有责任,通过提供适当的培训、工具和资源,以验证整个系统的设计和开发是安全的。
19 |
20 | 本文档中使用的重要术语,包括部分标题和文字,都以斜体字标注,并列举在附录 B 的术语
21 | 列表中。
22 |
23 | 关于安全软件开发框架的指南不属于本文讨论的范围。但是,我们推荐以下额外的常用规范
24 | 和资源:
25 |
26 | - 明确定义角色和职责。
27 |
28 | - 为开发团队提供足够的软件安全培训。
29 |
30 | - 采用一个安全软件开发生命周期。
31 |
32 | - 建立安全编码标准。
33 |
34 | - [OWASP 开发指南项目][guide]
35 |
36 | - 建立一个可重用的对象库文件。
37 |
38 | - [OWASP Enterprise Security API][esapi] (ESAPI) 项目
39 |
40 | - 验证安全控制的有效性。
41 |
42 | - [OWASP Application Security Verification Standard][asvs] (ASVS) 项目
43 |
44 | - 建立外包开发安全规范,包括在建议书(RFP)和合同中定义安全需求和验证方法。
45 |
46 | [asvs]: https://owasp.org/www-project-application-security-verification-standard/
47 | [esapi]: https://owasp.org/www-project-enterprise-security-api/
48 | [guide]: http://www.owasp.org/index.php/Category:OWASP_Guide_Project
49 |
--------------------------------------------------------------------------------
/v2/zh/cn/02-checklist/05-checklist.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # 安全编码规范检查列表
3 |
4 | ## 输入验证
5 |
6 | - [ ] 在可信系统(比如:服务器)上执行所有的数据验证。
7 | - [ ] 识别所有的数据源,并将其分为可信的和不可信的。验证所有来自不可信数据
8 | 源(比如:数据库,文件流,等)的数据。
9 | - [ ] 应当为应用程序应提供一个集中的输入验证规则。
10 | - [ ] 为所有输入明确恰当的字符集,比如:UTF-8。
11 | - [ ] 在输入验证前,将数据按照常用字符进行编码(规范化)。
12 | - [ ] 丢弃任何没有通过输入验证的数据。
13 | - [ ] 确定系统是否支持 UTF-8 扩展字符集,如果支持,在 UTF-8 解码完成以
14 | 后进行输入验证。
15 | - [ ] 在处理以前,验证所有来自客户端的数据,包括:所有参数、URL、HTTP
16 | 头信息(比如: cookie 名字和数据值)。确定包括了来自JavaScript、Flash
17 | 或其他嵌入代码的 post back 信息。
18 | - [ ] 验证在请求和响应的报头信息中只含有 ASCII 字符。
19 | - [ ] 核实来自重定向输入的数据(一个攻击者可能向重定向的目标直接提交恶意代
20 | 码,从而避开应用程序逻辑以及在重定向前执行的任何验证)。
21 | - [ ] 验证正确的数据类型。
22 | - [ ] 验证数据范围。
23 | - [ ] 验证数据长度。
24 | - [ ] 尽可能采用"白名单"形式,验证所有的输入。
25 | - [ ] 如果任何潜在的危险字符必须被作为输入,请确保您执行了额外的控制,
26 | 比如:输出编码、特定的安全 API、以及在应用程序中使用的原因。
27 | 部分常见的危险字符包括: \< \> \" \' % ( ) & + \\ \\\' \\\" 。
28 | - [ ] 如果您使用的标准验证规则无法验证下面的输入,那么它们需要被单独验证:
29 |
30 | - 验证空字节 (%00);
31 | - 验证换行符 (%0d, %0a, \\r, \\n);
32 | - 验证路径替代字符"点-点-斜杠"(../或 ..\\)。如果支持 UTF-8
33 | 扩展字符集编码,验证替代字符: %c0%ae%c0%ae/
34 | (使用规范化 验证双编码或其他类型的编码攻击)。
35 |
36 | ## 输出编码
37 |
38 | - [ ] 在可信系统(比如:服务器)上执行所有的编码。
39 | - [ ] 为每一种输出编码方法采用一个标准的、已通过测试的规则。
40 | - [ ] 通过语义输出编码方式,对所有返回到客户端的来自于应用程序信任边界之外
41 | 的数据进行编码。[HTML 实体编码](#_bookmark21)是一个例子,但不是在所有的情况下都可用。
42 | - [ ] 除非对目标编译器是安全的,否则请对所有字符进行编码。
43 | - [ ] 针对 SQL、XML 和 LDAP 查询,语义净化所有不可信数据的输出。
44 | - [ ] 对于操作系统命令,净化所有不可信数据输出。
45 |
46 | ## 身份验证和密码管理
47 |
48 | - [ ] 除了那些特定设为"公开"的内容以外,对所有的网页和资源要求身份验证。
49 | - [ ] 所有的身份验证过程必须在可信系统(比如:服务器)上执行。
50 | - [ ] 在任何可能的情况下,建立并使用标准的、已通过测试的身份验证服务。
51 | - [ ] 为所有身份验证控制使用一个集中实现的方法,其中包括利用库文件请求外
52 | 部身份验证服务。
53 | - [ ] 将身份验证逻辑从被请求的资源中隔离开,并使用重定向到或来自集中的身
54 | 份验证控制。
55 | - [ ] 所有的身份验证控制应当安全的处理未成功的身份验证。
56 | - [ ] 所有的管理和账户管理功能至少应当具有和主要身份验证机制一样的安全性。
57 | - [ ] 如果您的应用程序管理着凭证的存储,那么应当保证只保存了通过使用强加
58 | 密单向 salted 哈希算法得到的密码,并且只有应用程序具有对保存密码
59 | 和密钥的表/文件的写权限(如果可以避免的话,不要使用 MD5 算法)。
60 | - [ ] 密码哈希必须在可信系统(比如:服务器)上执行。
61 | - [ ] 只有当所有的数据输入以后,才进行身份验证数据的验证,特别是对[连续
62 | 身份验证](#_bookmark25)机制。
63 | - [ ] 身份验证的失败提示信息应当避免过于明确。比如:可以使用"用户名和/
64 | 或密码错误",而不要使用"用户名错误"或者"密码错误"。错误提示信息在显
65 | 示和源代码中应保持一致。
66 | - [ ] 为涉及敏感信息或功能的外部系统连接使用身份验证。
67 | - [ ] 用于访问应用程序以外服务的身份验证凭据信息应当加密,并存储在一个可
68 | 信系统(比如:服务器)中受到保护的地方。源代码不是一个安全的地方。
69 | - [ ] 只使用 HTTP Post 请求传输身份验证的凭据信息。
70 | - [ ] 非临时密码只在加密连接中发送或作为加密的数据(比如,一封加密的邮件)。
71 | 通过邮件重设临时密码可以是一个例外。
72 | - [ ] 通过政策或规则加强密码复杂度的要求(比如:要求使用字母、数字和/或
73 | 特殊符号)。身份验证的凭据信息应当足够复杂以对抗在其所部署环境中的各种威
74 | 胁攻击。
75 | - [ ] 通过政策和规则加强密码长度要求。常用的是 8 个字符长度,但是 16
76 | 个字符长度更好,或者考虑使用多单词密码短语。
77 | - [ ] 输入的密码应当在用户的屏幕上模糊显示(比如:在 Web 表单中使用
78 | "password"输入类型)。
79 | - [ ] 当连续多次登录失败后(比如:通常情况下是 5 次),应强制锁定账户。
80 | 账户锁定的时间必须足够长,以阻止暴力攻击猜测登录信息,但是不能长到允许执
81 | 行一次拒绝服务攻击。
82 | - [ ] 密码重设和更改操作需要类似于账户创建和身份验证的同样控制等级。
83 | - [ ] 密码重设问题应当支持尽可能随机的提问(比如:"最喜爱的书"是一个坏的
84 | 问题,因为《圣经》是最常见的答案)。
85 | - [ ] 如果使用基于邮件的重设,只将临时链接或密码发送到预先注册的邮件地址。
86 | - [ ] 临时密码和链接应当有一个短暂的有效期。
87 | - [ ] 当再次使用临时密码时,强制修改临时密码。
88 | - [ ] 当密码重新设置时,通知用户。
89 | - [ ] 阻止密码重复使用。
90 | - [ ] 密码在被更改前应当至少使用了一天,以阻止密码重用攻击。
91 | - [ ] 根据政策或规则的要求,强制定期更改密码。关键系统可能会要求更频繁的更
92 | 改。更改时间周期必须进行明确。
93 | - [ ] 为密码填写框禁用"记住密码"功能。
94 | - [ ] 用户账号的上一次使用信息(成功或失败)应当在下一次成功登录时向用户报告。
95 | - [ ] 执行监控以确定针对使用相同密码的多用户帐户攻击。当用户 ID 可以
96 | 被得到或被猜到时,该攻击模式用来绕开标准的锁死功能。
97 | - [ ] 更改所有厂商提供的默认用户 ID 和密码,或者禁用相关帐号。
98 | - [ ] 在执行关键操作以前,对用户再次进行身份验证。
99 | - [ ] 为高度敏感或重要的交易账户使用[多因子身份验证](#_bookmark23)机制。
100 | - [ ] 如果使用了第三方身份验证的代码,仔细检查代码以保证其不会受到任何恶
101 | 意代码的影响。
102 |
103 | ## 会话管理
104 |
105 | - [ ] 使用服务器或者框架的会话管理控制。应用程序应当只识别有效的会话标识符。
106 | - [ ] 会话标识符必须总是在一个可信系统(比如:服务器)上创建。
107 | - [ ] 会话管理控制应当使用通过审查的算法以保证足够的随机会话标识符。
108 | - [ ] 为包含已验证的会话标识符的 cookie 设置域和路径,以为站点设
109 | 置一个恰当的限制值。
110 | - [ ] 注销功能应当完全终止相关的会话或连接。
111 | - [ ] 注销功能应当可用于所有受身份验证保护的网页。
112 | - [ ] 在平衡的风险和业务功能需求的基础上,设置一个尽量短的会话超时时间。
113 | 通常情况下,应当不超过几个小时。
114 | - [ ] 禁止连续的登录并强制执行周期性的会话终止,即使是活动的会话。特别是
115 | 对于支持富网络连接或连接到关键系统的应用程序。终止时机应当可以根据业务需
116 | 求调整,并且用户应当收到足够的通知已减少带来的负面影响。
117 | - [ ] 如果一个会话在登录以前就建立,在成功登录以后,关闭该会话并创建一个
118 | 新的会话。
119 | - [ ] 在任何重新身份验证过程中建立一个新的会话标识符。
120 | - [ ] 不允许同一用户 ID 的并发登录。
121 | - [ ] 不要在 URL、错误信息或日志中暴露会话标识符。会话标识符应当只出
122 | 现在 HTTP cookie 头信息中。比如,不要将会话标识符以 GET 参数进行传递。
123 | - [ ] 通过在服务器上使用恰当的访问控制,保护服务器端会话数据免受来自服务
124 | 器其他用户的未授权访问。
125 | - [ ] 生成一个新的会话标识符并周期性地使旧会话标识符失效(这可以缓解那些
126 | 原标识符被获得的特定会话劫持情况)。
127 | - [ ] 在身份验证的时候,如果连接从 HTTP 变为 HTTPS,则生成一个新的会话标识符。
128 | 在应用程序中,推荐持续使用 HTTPS,而非在 HTTP 和 HTTPS
129 | 之间转换。
130 | - [ ] 为服务器端的操作执行标准的会话管理,比如,通过在每个会话中使用强随
131 | 机令牌或参数来管理账户。该方法可以用来防止[跨站点请求伪造](#跨站点请
132 | 求伪造一个外部网站或应用程序强迫一个客户端制作一个非意愿的请求到另一个有
133 | 活跃会话的客户端应用程序当它们使用已知的可预见的-url-和参数时并且当
134 | 浏览器对每个发往应用程序的请求自动传输所有需要的会话信息时应用程序是可被
135 | 攻击的)攻击。
136 | - [ ] 通过在每个请求或每个会话中使用强随机令牌或参数,为高度敏感或关键的
137 | 操作提供标准的会话管理。
138 | - [ ] 为在TLS 连接上传输的cookie 设置"安全"属性。
139 | - [ ] 将 cookie 设置为 HttpOnly 属性,除非在应用程序中
140 | 明确要求了客户端脚本程序读取或者设置 cookie 的值。
141 |
142 | ## 访问控制
143 |
144 | - [ ] 只使用可信系统对象(比如:服务器端会话对象)以做出访问授权的决定。
145 | - [ ] 使用一个单独的全站点部件以检查访问授权。这包括调用外部授权服务的库
146 | 文件。
147 | - [ ] 安全的处理访问控制失败的操作。
148 | - [ ] 如果应用程序无法访问其安全配置信息,则拒绝所有的访问。
149 | - [ ] 在每个请求中加强授权控制,包括:服务器端脚本产生的请求,
150 | "includes"和来自象 AJAX 和 FLASH 那样的富客户端技
151 | 术的请求。
152 | - [ ] 将有特权的逻辑从其他应用程序代码中隔离开。
153 | - [ ] 限制只有授权的用户才能访问文件或其他资源,包括那些应用程序外部的直
154 | 接控制。
155 | - [ ] 限制只有授权的用户才能访问受保护的 URL。
156 | - [ ] 限制只有授权的用户才能访问受保护的功能。
157 | - [ ] 限制只有授权的用户才能访问直接对象引用。
158 | - [ ] 限制只有授权的用户才能访问服务。
159 | - [ ] 限制只有授权的用户才能访问应用程序数据。
160 | - [ ] 限制通过使用访问控制来访问用户、数据属性和策略信息。
161 | - [ ] 限制只有授权的用户才能访问与安全相关的配置信息。
162 | - [ ] 服务器端执行的访问控制规则和表示层实施的访问控制规则必须匹配。
163 | - [ ] 如果[状态数据](#_bookmark26)必须存储在客户端,使用加密算法,
164 | 并在服务器端检查完整性以捕获状态的改变。
165 | - [ ] 强制应用程序逻辑流程遵照业务规则。
166 | - [ ] 限制单一用户或设备在一段时间内可以执行的事务数量。事务数量/时间应
167 | 当高于实际的业务需求,但也应该足够低以判定自动化攻击。
168 | - [ ] 仅使用"referer"头作为补偿性质的检查,它永远不能被单独用来
169 | 进行身份验证检查,因为它可以被伪造。
170 | - [ ] 如果长的身份验证会话被允许,周期性的重新验证用户的身份,以确保他们
171 | 的权限没有改变。如果发生改变,注销该用户,并强制他们重新执行身份验证。
172 | - [ ] 执行帐户审计并将没有使用的帐号强制失效(比如:在用户密码过期后
173 | 的 30 天以内)。
174 | - [ ] 应用程序必须支持帐户失效,并在帐户停止使用时终止会话(比如:角色、
175 | 职务状况、业务处理的改变,等等)。
176 | - [ ] 服务帐户,或连接到或来自外部系统的帐号,应当只有尽可能小的权限。
177 | - [ ] 建立一个"访问控制政策"以明确一个应用程序的业务规则、数据类型和身
178 | 份验证的标准或处理流程,确保访问可以被恰当的提供和控制。这包括了为数据和
179 | 系统资源确定访问需求。
180 |
181 | ## 加密规范
182 |
183 | - [ ] 所有用于保护来自应用程序用户秘密信息的加密功能都必须在一个可信系统
184 | (比如:服务器)上执行。
185 | - [ ] 保护主要秘密信息免受未授权的访问。
186 | - [ ] 安全的处理加密模块失败的操作。
187 | - [ ] 为防范对随机数据的猜测攻击,应当使用加密模块中已验证的随机数生成器
188 | 生成所有的随机数、随机文件名、随机 GUID 和随机字符串。
189 | - [ ] 应用程序使用的加密模块应当遵从 FIPS 140-2 或其他等同的
190 | 标准(请见:[STM Group](http://csrc.nist.gov/groups/STM/cmvp/validation.html))。
191 | - [ ] 建立并使用相关的政策和流程以实现加、解密的密钥管理。
192 |
193 | ## 错误处理和日志
194 |
195 | - [ ] 不要在错误响应中泄露敏感信息,包括:系统的详细信息、会话标识符或者
196 | 帐号信息。
197 | - [ ] 使用错误处理以避免显示调试或堆栈跟踪信息。
198 | - [ ] 使用通用的错误消息并使用定制的错误页面。
199 | - [ ] 应用程序应当处理应用程序错误,并且不依赖服务器配置。
200 | - [ ] 当错误条件发生时,适当的清空分配的内存。
201 | - [ ] 在默认情况下,应当拒绝访问与安全控制相关联的错误处理逻辑。
202 | - [ ] 所有的日志记录控制应当在可信系统(比如:服务器)上执行。
203 | - [ ] 日志记录控制应当支持记录特定安全事件的成功或者失败操作。
204 | - [ ] 确保日志记录包含了重要的[日志事件数据](#_bookmark22)。
205 | - [ ] 确保日志记录中包含的不可信数据,不会在查看界面或者软件时以代码的形
206 | 式被执行。
207 | - [ ] 限制只有授权的个人才能访问日志。
208 | - [ ] 为所有的日志记录采用一个主要的常规操作。
209 | - [ ] 不要在日志中保存敏感信息,包括:不必要的系统详细信息、会话标识符或
210 | 密码。
211 | - [ ] 确保一个执行日志查询分析机制的存在。
212 | - [ ] 记录所有失败的输入验证。
213 | - [ ] 记录所有的身份验证尝试,特别是失败的验证。
214 | - [ ] 记录所有失败的访问控制。
215 | - [ ] 记录明显的修改事件,包括对于状态数据非期待的修改。
216 | - [ ] 记录连接无效或者已过期的会话令牌尝试。
217 | - [ ] 记录所有的系统例外。
218 | - [ ] 记录所有的管理功能行为,包括对于安全配置设置的更改。
219 | - [ ] 记录所有失败的后端TLS 链接。
220 | - [ ] 记录加密模块的错误。
221 | - [ ] 使用加密哈希功能以验证日志记录的完整性。
222 |
223 | ## 数据保护
224 |
225 | - [ ] 授予最低权限,以限制用户只能访问为完成任务所需要的功能、数据和系统
226 | 信息。
227 | - [ ] 保护所有存放在服务器上缓存的或临时拷贝的敏感数据,以避免非授权的访问,
228 | 并在临时工作文件不再需要时被尽快清除。
229 | - [ ] 即使在服务器端,任然要加密存储的高度机密信息,比如,身份验证的验证
230 | 数据。总是使用已经被很好验证过的算法,更多指导信息请参见"加密规范"部分。
231 | - [ ] 保护服务器端的源代码不被用户下载。
232 | - [ ] 不要在客户端上以明文形式或其他非加密安全模式保存密码、连接字符串或
233 | 其他敏感信息。这包括嵌入在不安全的形式中: MS viewstate、 Adobe flash
234 | 或者已编译的代码。
235 | - [ ] 删除用户可访问产品中的注释,以防止泄露后台系统或者其他敏感信息。
236 | - [ ] 删除不需要的应用程序和系统文档,因为这些也可能向攻击者泄露有用的信息。
237 | - [ ] 不要在 HTTP GET 请求参数中包含敏感信息。
238 | - [ ] 禁止表单中的自动填充功能,因为表单中可能包含敏感信息,包括身份验证信息。
239 | - [ ] 禁止客户端缓存网页,因为可能包含敏感信息。"Cache-Control: no-store",
240 | 可以和 HTTP 报头控制"Pragma: no-cache"一起使用,
241 | 该控制不是非常有效,但是与 HTTP/1.0 向后兼容。
242 | - [ ] 应用程序应当支持,当数据不再需要的时候,删除敏感信息(比如:个人信
243 | 息或者特定财务数据)。
244 | - [ ] 为存储在服务器中的敏感信息提供恰当的访问控制。这包括缓存的数据、
245 | 临时文件以及只允许特定系统用户访问的数据。
246 |
247 | ## 通讯安全
248 |
249 | - [ ] 为所有敏感信息采用加密传输。其中应该包括使用 TLS 对连接的保护,
250 | 以及支持对敏感文件或非基于 HTTP 连接的不连续加密。
251 | - [ ] TLS 证书应当是有效的,有正确且未过期的域名,并且在需要时,
252 | 可以和中间证书一起安装。
253 | - [ ] 没有成功的TLS 连接不应当后退成为一个不安全的连接。
254 | - [ ] 为所有要求身份验证的访问内容和所有其他的敏感信息提供 TLS 连接。
255 | - [ ] 为包含敏感信息或功能、且连接到外部系统的连接使用 TLS。
256 | - [ ] 使用配置合理的单一标准 TLS 连接。
257 | - [ ] 为所有的连接明确字符编码。
258 | - [ ] 当链接到外部站点时,过滤来自 HTTP referer 中包含敏感信息的参数。
259 |
260 | ## 系统配置
261 |
262 | - [ ] 确保服务器、框架和系统部件采用了认可的最新版本。
263 | - [ ] 确保服务器、框架和系统部件安装了当前使用版本的所有补丁。
264 | - [ ] 关闭目录列表功能。
265 | - [ ] 将 Web 服务器、进程和服务的账户限制为尽可能低的权限。
266 | - [ ] 当例外发生时,安全的进行错误处理。
267 | - [ ] 移除所有不需要的功能和文件。
268 | - [ ] 在部署前,移除测试代码和产品不需要的功能。
269 | - [ ] 通过将不进行对外检索的路径目录放在一个隔离的父目录里,
270 | 以防止目录结构在 robots.txt 文档中暴露。然后,在 robots.txt
271 | 文档中"禁止"整个父目录,而不是对每个单独目录的"禁止"。
272 | - [ ] 明确应用程序采用哪种 HTTP 方法:GET 或 POST,
273 | 以及是否需要在应用程序不同网页中以不同的方式进行处理。
274 | - [ ] 禁用不需要的 HTTP 方法,比如WebDAV 扩展。如果需要使用
275 | 一个扩展的 HTTP 方法以支持文件处理,则使用一个好的经过验证的身份验证机制。
276 | - [ ] 如果 Web 服务器支持 HTTP1.0 和 1.1,确保以相似的
277 | 方式对它们进行配置,或者确保您理解了它们之间可能存在差异
278 | (比如:处理扩展的 HTTP 方法)。
279 | - [ ] 移除在 HTTP 相应报头中有关 OS、Web 服务版本和应用程序
280 | 框架的无关信息。
281 | - [ ] 应用程序存储的安全配置信息应当可以以可读的形式输出,以支持审计。
282 | - [ ] 使用一个资产管理系统,并将系统部件和软件注册在其中。
283 | - [ ] 将开发环境从生成网络隔离开,并只提供给授权的开发和测试团队访问。
284 | 开发环境往往没有实际生成环境那么安全,攻击者可以使用这些差别发现共有的弱
285 | 点或者是可被利用的漏洞。
286 | - [ ] 使用一个软件变更管理系统以管理和记录在开发和产品中代码的变更。
287 |
288 | ## 数据库安全
289 |
290 | - [ ] 使用强类型的[参数化查询方法](#_bookmark24)。
291 | - [ ] 使用输入验证和输出编码,并确保处理了元字符。如果失败,
292 | 则不执行数据库命令。
293 | - [ ] 确保变量是强类型的。
294 | - [ ] 当应用程序访问数据库时,应使用尽可能最低的权限。
295 | - [ ] 为数据库访问使用安全凭证。
296 | - [ ] 连接字符串不应当在应用程序中硬编码。连接字符串应当存储在一个可信服
297 | 务器的独立配置文件中,并且应当被加密。
298 | - [ ] 使用存储过程以实现抽象访问数据,并允许对数据库中表的删除权限。
299 | - [ ] 尽可能地快速关闭数据库连接。
300 | - [ ] 删除或者修改所有默认的数据库管理员密码。使用强密码、强短语,或者使
301 | 用多因子身份验证。
302 | - [ ] 关闭所有不必要的数据库功能(比如:不必要的存储过程或服务、应用程序包、
303 | 仅最小化安装需要的功能和选项(表面范围缩减))。
304 | - [ ] 删除厂商提供的不必要的默认信息(比如:数据库模式示例)。
305 | - [ ] 禁用任何不支持业务需求的默认帐户。
306 | - [ ] 应用程序应当以不同的凭证为每个信任的角色(比如:用户、只读用户、
307 | 访问用户、管理员)连接数据库。
308 |
309 | ## 文件管理
310 |
311 | - [ ] 不要把用户提交的数据直接传送给任何动态调用功能。
312 | - [ ] 在允许上传一个文档以前进行身份验证。
313 | - [ ] 只允许上传满足业务需要的相关文档类型。
314 | - [ ] 通过检查文件报头信息,验证上传文档是否是所期待的类型。只验证文件类
315 | 型扩展是不够的。
316 | - [ ] 不要把文件保存在与应用程序相同的 Web 环境中。文件应当保存在内
317 | 容服务器或者数据库中。
318 | - [ ] 防止或限制上传任意可能被 Web 服务器解析的文件。
319 | - [ ] 关闭在文件上传目录的运行权限。
320 | - [ ] 通过装上目标文件路径作为使用了相关路径或者已变更根目录环境的逻辑盘,
321 | 在 UNIX 中实现安全的文件上传服务。
322 | - [ ] 当引用已有文件时,使用一个白名单记录允许的文件名和类型。验证传递的
323 | 参数值,如果与预期的值不匹配,则拒绝使用,或者使用默认的硬编码文件值代替。
324 | - [ ] 不要将用户提交的数据传递到动态重定向中。如果必须允许使用,那么重定
325 | 向应当只接受通过验证的相对路径 URL。
326 | - [ ] 不要传递目录或文件路径,使用预先设置路径列表中的匹配索引值。
327 | - [ ] 绝对不要将绝对文件路径传递给客户。
328 | - [ ] 确保应用程序文件和资源是只读的。
329 | - [ ] 对用户上传的文件扫描进行病毒和恶意软件。
330 |
331 | ## 内存管理
332 |
333 | - [ ] 对不可信数据进行输入和输出控制。
334 | - [ ] 重复确认缓存空间的大小是否和指定的大小一样。
335 | - [ ] 当使用允许多字节拷贝的函数时,比如 strncpy(),如果目的缓
336 | 存容量和源缓存容量相等时,需要留意字符串没有 NULL 终止。
337 | - [ ] 如果在循环中调用函数时,检查缓存大小,以确保不会出现超出分配空间大
338 | 小的危险。
339 | - [ ] 在将输入字符串传递给拷贝和连接函数前,将所有输入的字符串缩短到合理
340 | 的长度。
341 | - [ ] 关闭资源时要特别注意,不要依赖垃圾回收机制(比如:连接对象、文档处
342 | 理,等)。
343 | - [ ] 在可能的情况下,使用不可执行的堆栈。
344 | - [ ] 避免使用已知有漏洞的函数(比如:printf,strcat,strcpy,等)。
345 | - [ ] 当方法结束时和在所有的退出节点时,正确地清空所分配的内存。
346 |
347 | ## 通用编码规范
348 |
349 | - [ ] 为常用的任务使用已测试且已认可的托管代码,而不创建新的非托管代码。
350 | - [ ] 使用特定任务的内置 API 以执行操作系统的任务。不允许应用程序直
351 | 接将代码发送给操作系统,特别是通过使用应用程序初始的命令shell。
352 | - [ ] 使用校验和或哈希值验证编译后的代码、库文件、可执行文件和配置文件的
353 | 完整性。
354 | - [ ] 使用死锁来防止多个同时发送的请求,或使用一个同步机制防止竞态条件。
355 | - [ ] 在同时发生不恰当的访问时,保护共享的变量和资源。
356 | - [ ] 在声明时或在第一次使用前,明确初始化您的所有变量和其他数据存储。
357 | - [ ] 当应用程序运行发生必须提升权限的情况时,尽量晚点提升权限,并且尽快
358 | 放弃所提升的权限。
359 | - [ ] 通过了解您使用的编程语言的底层表达式以及它们是如何进行数学计算,从
360 | 而避免计算错误。密切注意字节大小依赖、精确度、有无符合、截尾操作、转换、
361 | 字节之间的组合、 "not-a-number"计算、以及对于编程语言底层
362 | 表达式如何处理非常大或者非常小的数。
363 | - [ ] 不要将用户提供的数据传递给任何动态运行的功能。
364 | - [ ] 限制用户生成新代码或更改现有代码。
365 | - [ ] 审核所有从属的应用程序、第三方代码和库文件,以确定业务的需要,
366 | 并验证功能的安全性,因为它们可能产生新的漏洞。
367 | - [ ] 执行安全更新。如果应用程序采用自动更新,则为您的代码使用加密签名,
368 | 以确保的您的下载客户端验证这些签名。使用加密的信道传输来自主机服务器的代码。
369 |
--------------------------------------------------------------------------------
/v2/zh/cn/03-appendices/03-overview.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # 附录 A: 软件安全与风险原则概览 {#软件安全与风险原则概览 .list-paragraph}
3 |
4 | 开发安全的软件需要对安全原则有基本的了解。虽然对于安全原则的全面评估超出了本指南
5 | 的范围,但是我们还是提供了一个快速的概览。
6 |
7 | 软件安全的目标是要维护信息资源的保密性,完整性,和可用性,以确保业务的成功运作。
8 | 该目标通过实施安全控制来实现。本指南重点介绍具体的技术控制,以缓解常见软件漏洞的
9 | 发生。虽然主要的关注点是Web应用程序及其配套的基础设施,但是本指南的大部分内容
10 | 可应用于任意软件部署平台。
11 |
12 | 为了保护业务免受来自与软件相关的不能接受的风险,了解风险的意义是很有帮助的。风险
13 | 是一组威胁业务成功因素的集合。它可以被定义为:一个威胁代理与一个可能含有漏洞的系
14 | 统交互,该漏洞可被利用并造成影响。虽然这可能看起来象是一个抽象的概念,但可以这样
15 | 想象它:一个汽车盗窃犯(威胁代理)来到一个停车场(系统)寻找没有锁车门(漏洞)的
16 | 车,当找到一个时,他们打开门(利用)并拿走里面任何的东西(影响)。所有这些因素在
17 | 安全软件开发时都扮演了一个角色。
18 |
19 | 开发团队采用的方法和攻击者攻击应用程序所采用的方法之间有一个根本区别。开发团队通
20 | 常采用的方法是基于应用程序的目的行为。换句话说,开发团队根据功能需求文档和用例设
21 | 计一个应用程序以执行特定的任务。而另一方面,攻击者,基于"没有具体说明应拒绝的行为,
22 | 则被认为是可行的"原则,对于应用程序可以做什么更感兴趣。为了解决这个问题,一些额
23 | 外的元素需要被集成到软件生命周期的早期阶段。这些新元素是安全需求和滥用实例。本指
24 | 南旨在帮助明确高等级的安全需求,并解决许多常见的滥用情况。
25 |
26 | Web 开发团队应当明白,基于客户端的输入验证、隐藏字段和界面控件(例如,下拉键和单
27 | 选按钮)的客户端控制,所带来的安全性收益是有限的,这一点非常重要。攻击者可以使用
28 | 工具,比如:客户端的 Web 代理(例如,OWASP WebScarab,Burp)或网络数据包捕获
29 | 工具(例如,Wireshark),进行应用程序流量分析,提交定制的请求,并绕过所有的接口。
30 | 另外,Flash,Java Applet 和其它客户端对象可以被反编译并进行漏洞分析。
31 |
32 | 软件的安全漏洞可以在软件开发生命周期的任何阶段被引入,包括:
33 |
34 | - 最初没有明确的安全需求;
35 |
36 | - 创建有逻辑错误的概念设计;
37 |
38 | - 使用糟糕的编码规范,从而带来了技术漏洞;
39 |
40 | - 软件部署不当;
41 |
42 | - 在维护或者更新过程中引入缺陷。
43 |
44 | 此外,还有重要的一点需要明白,软件漏洞可以超出软件本身的范围。根据不同的软件、漏
45 | 洞和配套基础设施的性质,一次成功的攻击会影响下面任何或者所有的方面:
46 |
47 | - 软件和其相关的信息;
48 |
49 | - 相关服务器的操作系统;
50 |
51 | - 后端数据库;
52 |
53 | - 在共享环境中的其它应用程序;
54 |
55 | - 用户的系统;
56 |
57 | - 与用户交互的其它软件。
58 |
--------------------------------------------------------------------------------
/v2/zh/cn/03-appendices/05-glossary.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # 附录 B: 术语表 {#术语表 .list-paragraph}
3 |
4 | **滥用实例:**描述了对软件有意或无意的错误使用。滥用实例应当挑战系统设计的各种假设。
5 |
6 | **访问控制:**一组授予或拒绝用户或其他实体对系统资源访问的控制。这通常基于继承的角色
7 | 和在一个角色中的单独权限,但也包含系统与系统之间的交互。
8 |
9 | **身份验证:**一组验证正在与软件交互的用户或其他实体身份的控制
10 |
11 | **可用性:**一个系统可访问性和可用性的一种度量。
12 |
13 | **规范化:**将数据的各种编码方式和表式转换成为一种单一的简单形式。
14 |
15 | **通信安全:**一组帮助确保软件以一种安全的方式处理信息收发的控制。
16 |
17 | **保密性:**确保信息只公布给授权的当事人。
18 |
19 | **语义输出编码方式**:根据数据如何被应用程序使用,对输出进行编码。具体方法有所不同,
20 | 取决于输出数据的使用方式。如果数据被包含在返回客户端的响应中,请说明下面的情况:
21 | 在 JavaScript 中、在 CSS 中或在 URL 中的一个 HTML 文档的主体部分或一个 HTML 属性。
22 | 您还必须说明其它的用例,比如:SQL 查询、XML 和 LDAP。
23 |
24 | **跨站点请求伪造:**一个外部网站或应用程序强迫一个客户端制作一个非意愿的请求到另一个
25 | 有活跃会话的客户端应用程序。当它们使用已知的、可预见的 URL 和参数时,并且当
26 | 浏览器对每个发往应用程序的请求自动传输所有需要的会话信息时,应用程序是可被攻
27 | 击的。(该类攻击是本文中唯一包含并讨论的攻击,因为相关的漏洞非常常见的,但又
28 | 被知之甚少。)
29 |
30 | **密码规范:** 一组确保在应用程序中密码的操作被安全处理的控制。
31 |
32 | **数据保护:** 一组确保软件以一种安全的方式处理所保存的信息的控制。
33 |
34 | **数据库安全:**一组确保软件以一种安全的方式与数据库交互,并且数据库被安全配置的控制。
35 |
36 | **错误处理和日志记录:**一组确保应用程序安全的处理错误并执行正确的事件记录的实践。
37 |
38 | **利用:**使用一个漏洞。通常而言,这是一种有意的行为,旨在利用漏洞危及软件的安全控制。
39 |
40 | **文件管理:**一组涵盖代码和其它系统文件之间交互的控制。
41 |
42 | **通用编码规范:**一组涵盖不易分入其它组的编码实践。
43 |
44 | **危险字符:**任何字符或编码表示的字符,可以影响应用程序预期的操作,或者被解释为具有
45 | 特殊的意义、预期用途以外的字符。这些字符可用于:
46 |
47 | - 修改现有代码或语句的结构;
48 | - 插入新的非预期的代码;
49 | - 修改路径;
50 | - 程序功能或程序导致非预期的结果;
51 | - 导致错误的条件;
52 | - 下游应用程序或系统拥有上述任何效果。
53 |
54 | []{#_bookmark21 .anchor}**HTML 实体编码:** 用等价的 HTML 实体取代 ASCII 字
55 | 符的过程。比如:编码过程将用 HTML 等价 "<"取代小于号"\<"。HTML 实体在大多数的编
56 | 译器中是"无行动的",特别是在浏览器中,可以缓解某些客户端攻击。
57 |
58 | **影响:**当一个意外事件发生时,也就是一个漏洞被利用时,对业务负面影响的衡量。
59 |
60 | **输入验证:**一组验证所有输入数据的属性与应用程序所期待数据的类型、长度、范围、允许
61 | 的字符集所匹配,但不包含已知危险字符的控制。
62 |
63 | **完整性:** 保证信息是准确的、完整的和有效的,并且没有被一个未授权的行为所修改。
64 |
65 | []{#_bookmark22 .anchor}**日志事件数据:** 这应当包含以下信息:
66 |
67 | 1. 来自一个可信系统组件的时间戳;
68 | 2. 每个事件的严重程度;
69 | 3. 如果与其它日志事件混合在一起的话,标记与安全相关的事件;
70 | 4. 明确引发事件的帐户或用户身份;
71 | 5. 与请求相关的源 IP 地址;
72 | 6. 事件的结果(成功或失败);
73 | 7. 事件的描述。
74 |
75 | **内存管理:** 一组解决内存和缓存使用的控制。
76 |
77 | **缓解:**为减少一个漏洞的严重程度而采取的步骤。这些步骤可以包括:删除一个漏洞、使漏
78 | 洞更难被利用、减少漏洞被利用后带来的负面影响。
79 |
80 | []{#_bookmark23 .anchor}**多因子身份验证:**
81 | 一个要求用户处理多种不同种类凭据的身份验证过程。通常,该过程基于
82 | 用户拥有的信息(比如:智能卡)、他们知道的信息(比如:个人识别码)、或者他们自身
83 | 的信息(比如:来自生物方面的数据)。
84 |
85 | **输出编码:**
86 | 一组解决使用编码技术以确保应用程序输出的数据是安全的控制。
87 |
88 | []{#_bookmark24 .anchor}**参数化查询(预处理语句):**
89 | 通过使用占位符,保持查询语句和数据相分离。
90 | 查询语句结构由占位符定义,SQL 语句发送给数据库并做好准备,然后准备好的语句与参数
91 | 值相结合。这样就防止了查询被更改,因为参数值与已编译的语句相结合,
92 | 而不是 SQL 字符串。
93 |
94 | **净化数据:**通过使用删除数据、字符替代、编码或转义字符,将潜在的有害数据变得安全的
95 | 处理过程。
96 |
97 | **安全控制:**一个缓解潜在的漏洞,并有助于确保软件只以预期的模式进行工作的行为。
98 |
99 | **安全需求:**一组有助于确保软件以一种安全的模式建立并部署的设计和功能需求。
100 |
101 | []{#_bookmark25 .anchor}**连续身份验证:**
102 | 身份验证数据在连续的网页上被请求,而不是在一个单独的网页中一起被要求。
103 |
104 | **会话管理:**一组有助于确保 Web 应用程序以安全的模式处理 HTTP 会话的控制。
105 |
106 | []{#_bookmark26 .anchor}**状态数据:**
107 | 当应用程序或者服务器使用数据或参数模拟持续的连接,或跟踪跨多个请求的处
108 | 理或交易的客户端状态。
109 |
110 | **系统:** 一个涵括操作系统、Web
111 | 服务器、应用程序框架和相关基础设施的通用术语。
112 |
113 | **系统配置:**一组帮助确保基础设施部件支持软件安全部署的控制。
114 |
115 | **威胁代理:**任何可能对系统造成负面影响的实体。这可能是一个想危害系统安全控制的恶意
116 | 用户。但是,这也可能是一个意外的系统错误使用,或者是物理威胁,如火灾或水灾。
117 |
118 | **信任边界:**通常,一个信任边界由您直接控制的系统部件组成。来自您直接控制系统以外的
119 | 所有连接和数据,包括所有由其它各方管理的客户端和系统,在允许进一步的系统交互之前,
120 | 应当被认为是不可信的,并在边界被验证。
121 |
122 | **漏洞:**一个导致系统易受攻击或损坏的脆弱点。
123 |
--------------------------------------------------------------------------------
/v2/zh/cn/03-appendices/07-references.markdown:
--------------------------------------------------------------------------------
1 | \newpage
2 | # 附录 C: 外部的参考资料 {#外部的参考资料 .list-paragraph}
3 |
4 | ## 引用的参考资料
5 |
6 | - SANS CIS Controls version 8
7 |
8 | >
9 |
10 | - Web Application Security Consortium
11 |
12 | >
13 |
14 | - Common Weakness Enumeration (CWE)
15 |
16 | >
17 |
18 | - Department of Homeland Security: Build Security In Portal
19 |
20 | >
21 |
22 | - CERT Secure Coding
23 |
24 | >
25 |
26 | - MSDN Security Developer Center
27 |
28 | >
29 |
30 | ## 安全咨询网站:
31 |
32 | 检查已知威胁的有用资源,以支持基础设施和框架。
33 |
34 | > Secunia Citrix Vulnerability List:
35 |
36 | -
37 |
38 | > Security Focus Vulnerability Search (archived):
39 |
40 | -
41 |
42 | > Common Vulnerability Enumeration:
43 |
44 | -
45 |
--------------------------------------------------------------------------------
/v2/zh/cn/README.md:
--------------------------------------------------------------------------------
1 | # Chinese language (zh-CN) version
2 |
3 | We appreciate all kinds of [suggestions and corrections][issues] on this translation
4 | of the Secure Coding Practices Quick Reference Guide
5 |
6 | During development manually create the PDF document from directory `zh/cn`:
7 |
8 | ```
9 | pandoc -o OWASP_SCP_Quick_Reference_Guide.zh-CN.pdf \
10 | --pdf-engine=xelatex -r markdown title.pdf.yaml \
11 | 01-introduction/01-front.markdown \
12 | 01-introduction/02-toc.markdown \
13 | 01-introduction/03-credits.markdown \
14 | 01-introduction/04-copyright.markdown \
15 | 01-introduction/05-introduction.markdown \
16 | 02-checklist/05-checklist.markdown \
17 | 03-appendices/03-overview.markdown \
18 | 03-appendices/05-glossary.markdown \
19 | 03-appendices/07-references.markdown
20 | ```
21 |
22 | Similarly create the EBook:
23 |
24 | ```
25 | pandoc -o OWASP_SCP_Quick_Reference_Guide.zh-CN.epub \
26 | --pdf-engine=xelatex -r markdown title.yaml \
27 | 01-introduction/01-front.markdown \
28 | 01-introduction/02-toc.markdown \
29 | 01-introduction/03-credits.markdown \
30 | 01-introduction/04-copyright.markdown \
31 | 01-introduction/05-introduction.markdown \
32 | 02-checklist/05-checklist.markdown \
33 | 03-appendices/03-overview.markdown \
34 | 03-appendices/05-glossary.markdown \
35 | 03-appendices/07-references.markdown
36 | ```
37 |
38 | There is a dependency on having a *tex installed that will provide pdflatex for the PDF output.
39 | For example with MacOS the command `brew install basictex` can be used.
40 | Also make sure font 'Songti SC Light' is installed when creating the PDF and eBook.
41 |
42 | [issues]: https://github.com/OWASP/www-project-secure-coding-practices-quick-reference-guide/issues/new
43 |
--------------------------------------------------------------------------------
/v2/zh/cn/title.pdf.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | language: zh-CN
3 | author: Open Worldwide Application Security Project (OWASP)
4 | version: 中文版 2.0.1
5 | date: 2022 年 12 月
6 | rights: Creative Commons Attribution ShareAlike 4.0 International (CC BY-SA 4.0)
7 | geometry: "left=2.3cm,right=2cm,top=2cm,bottom=2.5cm"
8 | mainfont: Songti SC Light
9 | fontsize: 12pt
10 | header-includes: |
11 | \usepackage{fancyhdr}
12 | \pagestyle{fancy}
13 | \fancyhead{}
14 | \fancyfoot{}
15 | \fancyfoot[LE,LO]{v2.0.1}
16 | \fancyfoot[RE,RO]{\thepage}
17 | ...
18 |
--------------------------------------------------------------------------------
/v2/zh/cn/title.yaml:
--------------------------------------------------------------------------------
1 | ---
2 | lang: zh-CN
3 | title:
4 | - type: main
5 | text: OWASP 安全编码规范
6 | - type: subtitle
7 | text: 快速参考指南
8 | creator:
9 | - role: author
10 | text: Open Worldwide Application Security Project (OWASP)
11 | - role: editor
12 | text: Keith Turpin
13 | version: 中文版 2.0.1
14 | date: 2022 年 12 月
15 | rights: Creative Commons Attribution ShareAlike 4.0 International (CC BY-SA 4.0)
16 | geometry: "left=2.3cm,right=2cm,top=2cm,bottom=2.5cm"
17 | mainfont: Songti SC Light
18 | fontsize: 12pt
19 | ...
20 |
--------------------------------------------------------------------------------