diff --git a/.wordlist.txt b/.wordlist.txt index db59587..beb50bf 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -5,6 +5,7 @@ Adriaan AES Andreas APIs +AppSec Aref ASVS Baillon @@ -37,6 +38,13 @@ Datz de decrypt Der +deserialization +deserialize +deserializes +DevOps +DevOpsSec +DevSecOps +DevSlop docx DOM Dracea @@ -55,6 +63,7 @@ Goldschmidt Grandval Graziani Grossman +HackerCombat Happe Hashicorp Heyes @@ -64,8 +73,11 @@ Hiroshi Hsiang HSTS Hsu +httpOnly HTTPS IaC +IDOR +ISC Ishaq Ivashchenko Jasmin @@ -73,6 +85,7 @@ JEA JIT Joubert JSON +JSR JWS JWT JWTs @@ -94,9 +107,11 @@ Nagai NIST nonces OKADA +oneconsult's OpenSAMM Osama OTP +owasp OWASP Pagel PassKeys @@ -110,6 +125,7 @@ Riotaro RNG SameSite SAMM +Sanitization SAST SBOM SBOMs @@ -128,6 +144,8 @@ SSRF SSRFMap SSTI Taras +TechBeacon +Teil Temmar Terraform Terrascan @@ -137,10 +155,13 @@ ThreeHoolagins ThunderSon Timo TLS +Transformative Trivy TruffleHog UCDavies UI +untrusted +Validator venv Vries Watanabe diff --git a/docs/final-word.md b/docs/final-word.md index 4f3648a..674ace0 100644 --- a/docs/final-word.md +++ b/docs/final-word.md @@ -6,5 +6,5 @@ Good next steps to help build an application security program include: 1. To understand some of the risks in web application security please review the [OWASP Top Ten](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) . 2. A secure development program should include a *comprehensive list of security requirements* . - Use [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) to identify potential security threats, derive security requirements, and tailor security controls to prevent those. Use standards such as the [OWASP (Web) ASVS](https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project) and the [OWASP (Mobile) MASVS](https://github.com/OWASP/owasp-masvs) which provides a catalog of available security requirements along wiht the relevant verification criteria. + Use [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) to identify potential security threats, derive security requirements, and tailor security controls to prevent those. Use standards such as the [OWASP (Web) ASVS](https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project) and the [OWASP (Mobile) MASVS](https://github.com/OWASP/owasp-masvs) which provides a catalog of available security requirements along with the relevant verification criteria. 3. To understand the core building blocks of a secure software program from a more macro point of view please review the [OWASP OpenSAMM project](https://www.owasp.org/index.php/OWASP_SAMM_Project). diff --git a/docs/the-top-10/c4-secure-architecture.md b/docs/the-top-10/c4-secure-architecture.md index ee7aa2c..c7ba3fc 100644 --- a/docs/the-top-10/c4-secure-architecture.md +++ b/docs/the-top-10/c4-secure-architecture.md @@ -2,7 +2,7 @@ ## Description -When designing a new application, creating a secure architecture prevents vulnerabilties before they even become part of the application. This prevents costly repairs and repudiation problems. +When designing a new application, creating a secure architecture prevents vulnerabilities before they even become part of the application. This prevents costly repairs and repudiation problems. There are design principles that lead to secure architectures: @@ -14,7 +14,7 @@ There are design principles that lead to secure architectures: ## Threats -- If the application is only protected by security-by-obscurity, an attacker that reverse-engineers the application has full permissions as soon the obfuscation is cleared-up. In addtion, an attacker is able to monitor network traffic: while the obfuscation might be performed on the code-level, the operations on the network level can easily be analyzed. +- If the application is only protected by security-by-obscurity, an attacker that reverse-engineers the application has full permissions as soon the obfuscation is cleared-up. In addition, an attacker is able to monitor network traffic: while the obfuscation might be performed on the code-level, the operations on the network level can easily be analyzed. - A web-application with a complex authorization scheme is deployed. A new software developer is tasked with extending one of the components. Due to the complexity, they misconfigure the authorization scheme and an attacker is able to exploit IDOR. - A web-application with a complex authorization scheme is deployed. A new software developer adds a new plugin to the system. The system makes it hard to do the right thing, and all security configuration must be manually added to the plugin, by-default no security measures are taken. The new developer is not configuring anything thus the new plugin introduces an IDOR into the system. - A web-application has many components, all of which are exposed to the public internet. The resulting attack surface is massive. For example, a database management tool (e.g., `phpmyadmin`) is deployed. After a 0day was found in `mysqladmin`, the whole database was extracted. During normal use, nobody uses `phpmyadmin`.