├── .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 | ![](../../../images/OWASP-logo.jpg){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 | ![](../../../images/OWASP-logo.jpg){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 | ![](../../../images/OWASP-logo.jpg){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 | ![](../../../images/OWASP-logo.jpg){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 | ![](../../../images/OWASP-logo.jpg){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 | ![](../../../images/OWASP-logo.jpg){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 | ![](../../../images/OWASP-logo.jpg){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 | ![](../../../images/OWASP-logo.jpg){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 | --------------------------------------------------------------------------------