mirror of
https://github.com/foomo/foomo-docs.git
synced 2025-10-16 12:35:40 +00:00
Compare commits
4 Commits
0b25097e50
...
43f97e1d6d
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
43f97e1d6d | ||
|
|
4743205297 | ||
|
|
d33edde539 | ||
|
|
e5f34949a3 |
@ -28,6 +28,8 @@ This document distills the macOS security model and recommended hardening practi
|
|||||||
- [Baseline for All Corporate Macs](#baseline-for-all-corporate-macs)
|
- [Baseline for All Corporate Macs](#baseline-for-all-corporate-macs)
|
||||||
- [Additional Hardening for Admins and Developers](#additional-hardening-for-admins-and-developers)
|
- [Additional Hardening for Admins and Developers](#additional-hardening-for-admins-and-developers)
|
||||||
- [High-Risk or Data-Critical Roles](#high-risk-or-data-critical-roles)
|
- [High-Risk or Data-Critical Roles](#high-risk-or-data-critical-roles)
|
||||||
|
- [Third-Party Security Tools](#third-party-security-tools)
|
||||||
|
- [Commercial Security Tools](#commercial-security-tools)
|
||||||
- [Operational Playbooks](#operational-playbooks-condensed)
|
- [Operational Playbooks](#operational-playbooks-condensed)
|
||||||
- [Implementation Notes](#implementation-notes-mdm-first)
|
- [Implementation Notes](#implementation-notes-mdm-first)
|
||||||
- [Quick Reference Checklists](#quick-reference-checklists)
|
- [Quick Reference Checklists](#quick-reference-checklists)
|
||||||
@ -39,7 +41,7 @@ This document distills the macOS security model and recommended hardening practi
|
|||||||
- Preserve user privacy while enabling essential productivity, IT support, and security observability.
|
- Preserve user privacy while enabling essential productivity, IT support, and security observability.
|
||||||
- Prefer native, built-in macOS security controls. Use a Mobile Device Management (MDM) solution to enforce a secure-by-default posture that is centrally managed and auditable.
|
- Prefer native, built-in macOS security controls. Use a Mobile Device Management (MDM) solution to enforce a secure-by-default posture that is centrally managed and auditable.
|
||||||
|
|
||||||
## Apple Platform Foundations (what macOS gives you)
|
## Apple Platform Foundations
|
||||||
|
|
||||||
- Hardware Root of Trust and [Secure Boot](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_Boot): The system validates that only legitimate, Apple-signed code runs at startup, preventing boot-level malware from taking hold.
|
- Hardware Root of Trust and [Secure Boot](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_Boot): The system validates that only legitimate, Apple-signed code runs at startup, preventing boot-level malware from taking hold.
|
||||||
- [Secure Enclave](https://en.wikipedia.org/wiki/Apple_Silicon#Security_and_privacy) (SEP) and keybags: A dedicated hardware security processor that handles cryptographic operations for sensitive data like FileVault keys, Keychain items, and Touch ID, isolating them from the main OS.
|
- [Secure Enclave](https://en.wikipedia.org/wiki/Apple_Silicon#Security_and_privacy) (SEP) and keybags: A dedicated hardware security processor that handles cryptographic operations for sensitive data like FileVault keys, Keychain items, and Touch ID, isolating them from the main OS.
|
||||||
@ -51,19 +53,19 @@ This document distills the macOS security model and recommended hardening practi
|
|||||||
```
|
```
|
||||||
- [Gatekeeper](https://en.wikipedia.org/wiki/Gatekeeper_(macOS)) and [Notarization](https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution): Before a downloaded app runs for the first time, Gatekeeper verifies that it’s from an identified developer and has been notarized by Apple—an automated check for malicious content.
|
- [Gatekeeper](https://en.wikipedia.org/wiki/Gatekeeper_(macOS)) and [Notarization](https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution): Before a downloaded app runs for the first time, Gatekeeper verifies that it’s from an identified developer and has been notarized by Apple—an automated check for malicious content.
|
||||||
- [App Sandbox](https://developer.apple.com/documentation/security/app_sandbox) and entitlements: Applications from the App Store are sandboxed, meaning they are restricted in their access to system resources and user data. They must declare required permissions (entitlements), limiting the potential damage if compromised.
|
- [App Sandbox](https://developer.apple.com/documentation/security/app_sandbox) and entitlements: Applications from the App Store are sandboxed, meaning they are restricted in their access to system resources and user data. They must declare required permissions (entitlements), limiting the potential damage if compromised.
|
||||||
- [Transparency, Consent, and Control](https://en.wikipedia.org/wiki/Transparency,_Consent,_and_Control) (TCC): The system prompts the user for explicit permission before an app can access sensitive data or services, such as the camera, microphone, location, contacts, or screen recording.
|
- [Transparency, Consent, and Control](https://support.apple.com/en-gb/guide/security/secddd1d86a6/web) (TCC): The system prompts the user for explicit permission before an app can access sensitive data or services, such as the camera, microphone, location, contacts, or screen recording.
|
||||||
- [XProtect](https://en.wikipedia.org/wiki/XProtect) and Apple malware removal: macOS includes built-in, signature-based antivirus capabilities that silently check for and block/remove known malware in the background. Apple pushes updates to it automatically.
|
- [XProtect](https://support.apple.com/en-gb/guide/security/sec469d47bd8/web) and Apple malware removal: macOS includes built-in, signature-based antivirus capabilities that silently check for and block/remove known malware in the background. Apple pushes updates to it automatically.
|
||||||
- Full‑disk encryption ([FileVault](https://en.wikipedia.org/wiki/FileVault)): Provides strong, hardware-accelerated AES-XTS 256-bit encryption for the entire startup disk, protecting all data at rest. If a device is lost or stolen, the data is unreadable without the user's password or a secure recovery key.
|
- Full‑disk encryption ([FileVault](https://en.wikipedia.org/wiki/FileVault)): Provides strong, hardware-accelerated AES-XTS 256-bit encryption for the entire startup disk, protecting all data at rest. If a device is lost or stolen, the data is unreadable without the user's password or a secure recovery key.
|
||||||
|
|
||||||
## Opinionated Baseline (what we enforce)
|
## Opinionated Baseline
|
||||||
|
|
||||||
Harden in layers: identity, device state, data protections, network posture, app controls, and telemetry. Use MDM to apply and verify settings at scale.
|
Harden in layers: identity, device state, data protections, network posture, app controls, and telemetry. Use MDM to apply and verify settings at scale.
|
||||||
|
|
||||||
### Baseline for All Corporate Macs
|
### Baseline for All Corporate Macs
|
||||||
|
|
||||||
- Identity and Enrollment
|
- Identity and Enrollment
|
||||||
- [ ] Device enrolled in [MDM](https://en.wikipedia.org/wiki/Mobile_device_management) via Automated Device Enrollment ([ABM](https://www.apple.com/business/it/)/[ASM](https://www.apple.com/education/schools/)) with supervision. This non-removable management profile ensures devices are corporate-owned and configured securely from their very first boot (zero-touch deployment).
|
- [ ] Device enrolled in [MDM](https://en.wikipedia.org/wiki/Mobile_device_management) via Automated Device Enrollment ([Apple Business Manager (ABM)](https://www.apple.com/business/it/)/[Apple School Manager (ASM)](https://www.apple.com/education/schools/)) with supervision. This non-removable management profile ensures devices are corporate-owned and configured securely from their very first boot (zero-touch deployment).
|
||||||
- [ ] Enforce compliant posture to access corporate resources (SSO, MFA, device compliance). For example, access to cloud apps can require that the device is managed, has FileVault enabled, and is running a recent OS version.
|
- [ ] Enforce compliant posture to access corporate resources (Single Sign-On (SSO), Multi-Factor Authentication (MFA), device compliance). For example, access to cloud apps can require that the device is managed, has FileVault enabled, and is running a recent OS version.
|
||||||
|
|
||||||
- Disk and Data Protection
|
- Disk and Data Protection
|
||||||
- [ ] Enable [FileVault](https://en.wikipedia.org/wiki/FileVault) (FV2) on all Macs; escrow recovery key to MDM/key escrow service. This ensures data at rest is encrypted. Escrowing the key allows IT to perform data recovery if a user forgets their password.
|
- [ ] Enable [FileVault](https://en.wikipedia.org/wiki/FileVault) (FV2) on all Macs; escrow recovery key to MDM/key escrow service. This ensures data at rest is encrypted. Escrowing the key allows IT to perform data recovery if a user forgets their password.
|
||||||
@ -77,7 +79,7 @@ Harden in layers: identity, device state, data protections, network posture, app
|
|||||||
- [ ] Encrypt [Time Machine](https://support.apple.com/en-us/HT201250) backups; restrict to approved destinations only, such as a designated, encrypted network share, to prevent data leakage via backups.
|
- [ ] Encrypt [Time Machine](https://support.apple.com/en-us/HT201250) backups; restrict to approved destinations only, such as a designated, encrypted network share, to prevent data leakage via backups.
|
||||||
|
|
||||||
- Software Update and Patching
|
- Software Update and Patching
|
||||||
- [ ] Enable automatic OS updates, app updates, background updates, and Rapid Security Responses. Timely patching is one of the most effective security measures.
|
- [ ] Enable automatic OS updates, app updates, background updates, and Rapid Security Responses (RSR). Timely patching is one of the most effective security measures. Rapid Security Responses are a new type of software release for macOS, iOS and iPadOS. They deliver important security improvements between software updates – for example, improvements to the Safari web browser, the WebKit framework stack, or other critical system libraries. They may also be used to mitigate some security issues more quickly, such as issues that might have been exploited or reported to exist “in the wild.”
|
||||||
```bash
|
```bash
|
||||||
# Manually check for available software updates
|
# Manually check for available software updates
|
||||||
softwareupdate -l
|
softwareupdate -l
|
||||||
@ -85,7 +87,7 @@ Harden in layers: identity, device state, data protections, network posture, app
|
|||||||
- [ ] Define maximum deferral windows and install deadlines via MDM. For example, allow users to defer a critical update for 3 days, after which installation is forced. This balances convenience with security.
|
- [ ] Define maximum deferral windows and install deadlines via MDM. For example, allow users to defer a critical update for 3 days, after which installation is forced. This balances convenience with security.
|
||||||
|
|
||||||
- Account Model
|
- Account Model
|
||||||
- [ ] Users operate as Standard accounts; use JIT elevation or a separate, dormant Admin account. This enforces the principle of least privilege. Administrative tasks should require temporary, auditable privilege elevation.
|
- [ ] Users operate as Standard accounts; use Just-In-Time (JIT) elevation or a separate, dormant Admin account. This enforces the principle of least privilege. Administrative tasks should require temporary, auditable privilege elevation.
|
||||||
- [ ] Block local account creation outside IT workflows; disable Guest account. This prevents users from creating unauthorized accounts to bypass controls. The Guest account provides an unmanaged access vector and should be disabled.
|
- [ ] Block local account creation outside IT workflows; disable Guest account. This prevents users from creating unauthorized accounts to bypass controls. The Guest account provides an unmanaged access vector and should be disabled.
|
||||||
```bash
|
```bash
|
||||||
# Disable the guest account from the command line
|
# Disable the guest account from the command line
|
||||||
@ -117,7 +119,7 @@ Harden in layers: identity, device state, data protections, network posture, app
|
|||||||
# Expected output: assessments enabled
|
# Expected output: assessments enabled
|
||||||
```
|
```
|
||||||
- [ ] Block legacy kernel extensions; prefer [System Extensions](https://developer.apple.com/documentation/systemextensions); approve only vetted Team IDs. Legacy kernel extensions (kexts) are being phased out. Modern System Extensions run in a more restricted userspace environment.
|
- [ ] Block legacy kernel extensions; prefer [System Extensions](https://developer.apple.com/documentation/systemextensions); approve only vetted Team IDs. Legacy kernel extensions (kexts) are being phased out. Modern System Extensions run in a more restricted userspace environment.
|
||||||
- [ ] PPPC/TCC: grant Full Disk Access, Accessibility, Screen Recording only to required tools (e.g., EDR). Manage Privacy Preferences Policy Control (PPPC) centrally to grant powerful permissions sparingly and only to vetted security or IT support tools.
|
- [ ] Privacy Preferences Policy Control (PPPC)/TCC: grant Full Disk Access, Accessibility, Screen Recording only to required tools (e.g., Endpoint Detection and Response (EDR)). Manage Privacy Preferences Policy Control (PPPC) centrally to grant powerful permissions sparingly and only to vetted security or IT support tools.
|
||||||
- [ ] Application allow/deny lists managed by MDM for sensitive roles. For high-risk roles, an allow-list that only permits approved applications to run provides a very strong defense against untrusted code.
|
- [ ] Application allow/deny lists managed by MDM for sensitive roles. For high-risk roles, an allow-list that only permits approved applications to run provides a very strong defense against untrusted code.
|
||||||
|
|
||||||
- Browser and Content Protections
|
- Browser and Content Protections
|
||||||
@ -129,7 +131,7 @@ Harden in layers: identity, device state, data protections, network posture, app
|
|||||||
- [ ] Limit analytics/diagnostics sharing to minimum necessary; disable ad personalization.
|
- [ ] Limit analytics/diagnostics sharing to minimum necessary; disable ad personalization.
|
||||||
|
|
||||||
- Telemetry, Detection, and Response
|
- Telemetry, Detection, and Response
|
||||||
- [ ] Deploy managed EDR/XDR (endpoint detection/response) using Apple’s [Endpoint Security](https://developer.apple.com/documentation/endpointsecurity) framework; verify coverage. An EDR agent is crucial for detecting and responding to advanced threats that bypass preventative controls.
|
- [ ] Deploy managed Endpoint Detection and Response (EDR)/Extended Detection and Response (XDR) using Apple’s [Endpoint Security](https://developer.apple.com/documentation/endpointsecurity) framework; verify coverage. An EDR agent is crucial for detecting and responding to advanced threats that bypass preventative controls.
|
||||||
- [ ] Enable unified logging collection for security‑relevant events; forward to a [SIEM](https://en.wikipedia.org/wiki/Security_information_and_event_management). Centralize macOS logs in a SIEM to enable threat hunting, incident investigation, and compliance monitoring.
|
- [ ] Enable unified logging collection for security‑relevant events; forward to a [SIEM](https://en.wikipedia.org/wiki/Security_information_and_event_management). Centralize macOS logs in a SIEM to enable threat hunting, incident investigation, and compliance monitoring.
|
||||||
```bash
|
```bash
|
||||||
# Example: stream logs in real-time to view security-related events
|
# Example: stream logs in real-time to view security-related events
|
||||||
@ -156,7 +158,30 @@ Harden in layers: identity, device state, data protections, network posture, app
|
|||||||
- [ ] Screen recording disabled except for approved collaboration tools.
|
- [ ] Screen recording disabled except for approved collaboration tools.
|
||||||
- [ ] Camera/microphone disabled unless explicitly needed.
|
- [ ] Camera/microphone disabled unless explicitly needed.
|
||||||
|
|
||||||
## Operational Playbooks (condensed)
|
## Third-Party Security Tools
|
||||||
|
|
||||||
|
While macOS provides a strong security foundation, a layered defense is always best. The following free, open-source tools from [Objective-See](https://objective-see.org/tools.html) provide excellent visibility into system internals and can help detect advanced threats. All tools are open-source and available on [GitHub](https://github.com/objective-see).
|
||||||
|
|
||||||
|
- **LuLu**: A free, open-source firewall to monitor and block outgoing network connections.
|
||||||
|
- **Do Not Disturb**: Detects and alerts on physical access ("evil maid") attacks.
|
||||||
|
- **KnockKnock**: Uncovers persistently installed software to generically reveal malware.
|
||||||
|
- **TaskExplorer**: Visually explores all running processes, their signature status, loaded libraries, open files, and network connections.
|
||||||
|
- **ReiKey**: Scans for and detects persistent keyboard "event taps" that could be used to intercept keystrokes.
|
||||||
|
- **Netiquette**: A network monitor to inspect all sockets and connections.
|
||||||
|
- **BlockBlock**: Monitors persistence locations and alerts on any new persistent component.
|
||||||
|
- **RansomWhere?**: Generically stops ransomware by monitoring the file-system for the creation of encrypted files by suspicious processes.
|
||||||
|
- **OverSight**: Monitors a Mac's microphone and webcam, alerting when they are activated.
|
||||||
|
- **KextViewr**: Displays all loaded kernel extensions and their signing status.
|
||||||
|
- **Dylib Hijack Scanner**: Scans for applications susceptible to or already hijacked via dylib hijacking.
|
||||||
|
- **What's Your Sign**: A Finder extension to display code-signing information for any file.
|
||||||
|
|
||||||
|
## Commercial Security Tools
|
||||||
|
|
||||||
|
For on-demand scanning and removal of malware, adware, and potentially unwanted programs (PUPs), the following tool is highly recommended.
|
||||||
|
|
||||||
|
- **[Malwarebytes for Mac](https://www.malwarebytes.com)**: Provides a free, reputable on-demand scanner that can detect and remove threats that may be missed by built-in macOS protections. While it offers a premium real-time protection service, the free scanner is an excellent tool for periodic system health checks or for remediating an existing infection.
|
||||||
|
|
||||||
|
## Operational Playbooks
|
||||||
|
|
||||||
- Lost or Stolen Mac
|
- Lost or Stolen Mac
|
||||||
- [ ] Immediately mark device lost in MDM; enable Activation Lock and Lost Mode; attempt remote lock/wipe
|
- [ ] Immediately mark device lost in MDM; enable Activation Lock and Lost Mode; attempt remote lock/wipe
|
||||||
@ -173,7 +198,7 @@ Harden in layers: identity, device state, data protections, network posture, app
|
|||||||
- Offboarding
|
- Offboarding
|
||||||
- [ ] Disable accounts/tokens; revoke device compliance; remote wipe or reassign after backup/escrow.
|
- [ ] Disable accounts/tokens; revoke device compliance; remote wipe or reassign after backup/escrow.
|
||||||
|
|
||||||
## Implementation Notes (MDM-first)
|
## Implementation Notes
|
||||||
|
|
||||||
- Use Automated Device Enrollment and supervision to lock down Setup Assistant and require MDM profiles at first boot. This prevents users from bypassing enrollment.
|
- Use Automated Device Enrollment and supervision to lock down Setup Assistant and require MDM profiles at first boot. This prevents users from bypassing enrollment.
|
||||||
- Enforce FileVault with personal recovery key escrow and, if policy requires, an institutional key held in a secure [HSM](https://en.wikipedia.org/wiki/Hardware_security_module)-backed secret manager.
|
- Enforce FileVault with personal recovery key escrow and, if policy requires, an institutional key held in a secure [HSM](https://en.wikipedia.org/wiki/Hardware_security_module)-backed secret manager.
|
||||||
@ -183,26 +208,26 @@ Harden in layers: identity, device state, data protections, network posture, app
|
|||||||
|
|
||||||
## Quick Reference Checklists
|
## Quick Reference Checklists
|
||||||
|
|
||||||
### Minimum Baseline (must-have)
|
### Minimum Baseline
|
||||||
|
|
||||||
- [ ] MDM enrollment and supervision
|
- [ ] MDM enrollment and supervision
|
||||||
- [ ] FileVault enabled with escrowed recovery key
|
- [ ] FileVault enabled with escrowed recovery key
|
||||||
- [ ] Automatic OS/app/RSR updates
|
- [ ] Automatic OS/app/Rapid Security Response (RSR) updates
|
||||||
- [ ] Standard user accounts; no auto-login; Guest disabled
|
- [ ] Standard user accounts; no auto-login; Guest disabled
|
||||||
- [ ] Firewall + Stealth Mode enabled; sharing services off
|
- [ ] Firewall + Stealth Mode enabled; sharing services off
|
||||||
- [ ] Gatekeeper/Notarization enforced; no legacy kexts
|
- [ ] Gatekeeper/Notarization enforced; no legacy kexts
|
||||||
- [ ] EDR deployed and reporting; logs forwarded
|
- [ ] EDR deployed and reporting; logs forwarded
|
||||||
|
|
||||||
### Nice-to-Have (should-have)
|
### Advanced Defense
|
||||||
|
|
||||||
- [ ] DNS/content filtering for phishing/malware
|
- [ ] DNS/content filtering for phishing/malware
|
||||||
- [ ] Encrypted Time Machine backups to approved targets
|
- [ ] Encrypted Time Machine backups to approved targets
|
||||||
- [ ] PPPC minimized; periodic review of Full Disk Access
|
- [ ] Keep Privacy Preferences Policy Control (PPPC) grants to a minimum
|
||||||
- [ ] Browser hardening via managed policies
|
- [ ] Browser hardening via managed policies
|
||||||
|
|
||||||
### Team-Specific (as-needed)
|
### Team-Specific
|
||||||
|
|
||||||
- [ ] Developer entitlements and tools managed; signed artifacts; SBOMs
|
- [ ] Developer entitlements and tools managed; signed artifacts; Software Bill of Materials (SBOMs)
|
||||||
- [ ] High-risk roles: removable media controls, stricter TCC, per-app VPN
|
- [ ] High-risk roles: removable media controls, stricter TCC, per-app VPN
|
||||||
|
|
||||||
## References
|
## References
|
||||||
|
|||||||
@ -58,7 +58,7 @@ A structured methodology ensures comprehensive and repeatable testing. This proc
|
|||||||
7. **Reporting**: A critical deliverable. The report should detail findings, assign risk ratings (e.g., using CVSS), explain the business impact, and provide clear, step-by-step instructions for reproduction and remediation.
|
7. **Reporting**: A critical deliverable. The report should detail findings, assign risk ratings (e.g., using CVSS), explain the business impact, and provide clear, step-by-step instructions for reproduction and remediation.
|
||||||
8. **Remediation Validation**: After the client has implemented fixes, the tester re-tests the specific vulnerabilities to verify that the mitigations are effective. This closes the feedback loop and confirms risk reduction.
|
8. **Remediation Validation**: After the client has implemented fixes, the tester re-tests the specific vulnerabilities to verify that the mitigations are effective. This closes the feedback loop and confirms risk reduction.
|
||||||
|
|
||||||
## Web application testing (OWASP WSTG‑aligned)
|
## Web application testing
|
||||||
|
|
||||||
This section aligns with the OWASP Web Security Testing Guide, covering common vulnerability categories.
|
This section aligns with the OWASP Web Security Testing Guide, covering common vulnerability categories.
|
||||||
|
|
||||||
|
|||||||
@ -67,7 +67,7 @@ Integrating security into every phase of the Software Development Lifecycle (SDL
|
|||||||
- **Release & Config**: Use Infrastructure as Code (IaC) to manage and version your infrastructure. Fetch secrets at runtime from a secure vault (e.g., HashiCorp Vault, AWS Secrets Manager). Deploy applications with least-privilege service accounts and roles.
|
- **Release & Config**: Use Infrastructure as Code (IaC) to manage and version your infrastructure. Fetch secrets at runtime from a secure vault (e.g., HashiCorp Vault, AWS Secrets Manager). Deploy applications with least-privilege service accounts and roles.
|
||||||
- **Operate**: Monitor application and infrastructure logs for security events. Use a WAF with rate limiting to protect against automated attacks. Have runbooks and playbooks ready for incident response.
|
- **Operate**: Monitor application and infrastructure logs for security events. Use a WAF with rate limiting to protect against automated attacks. Have runbooks and playbooks ready for incident response.
|
||||||
|
|
||||||
## Quick Engineering Checklist (build-time)
|
## Quick Engineering Checklist
|
||||||
|
|
||||||
A quick-reference list for engineers during development.
|
A quick-reference list for engineers during development.
|
||||||
|
|
||||||
@ -107,7 +107,7 @@ Securing the environment where your application runs.
|
|||||||
|
|
||||||
## Area-by-Area Best Practices
|
## Area-by-Area Best Practices
|
||||||
|
|
||||||
### Authentication ([WSTG-ATHN](https://owasp.org/www-project-web-security-testing-guide/))
|
### Authentication
|
||||||
- **Centralize identity**: Use a dedicated, well-tested identity provider or library. Implement multi-factor authentication (MFA). Ensure password reset and account recovery flows are secure (e.g., using time-limited tokens sent to a verified email or phone).
|
- **Centralize identity**: Use a dedicated, well-tested identity provider or library. Implement multi-factor authentication (MFA). Ensure password reset and account recovery flows are secure (e.g., using time-limited tokens sent to a verified email or phone).
|
||||||
- **Password storage**: Store password hashes using a memory-hard algorithm like [Argon2id](https://www.rfc-editor.org/rfc/rfc9106) (preferred) or bcrypt.
|
- **Password storage**: Store password hashes using a memory-hard algorithm like [Argon2id](https://www.rfc-editor.org/rfc/rfc9106) (preferred) or bcrypt.
|
||||||
```go
|
```go
|
||||||
@ -117,7 +117,7 @@ Securing the environment where your application runs.
|
|||||||
- **Throttling**: Throttle login attempts by IP address and username to slow down brute-force attacks. Implement account lockouts after a certain number of failed attempts.
|
- **Throttling**: Throttle login attempts by IP address and username to slow down brute-force attacks. Implement account lockouts after a certain number of failed attempts.
|
||||||
- **Re-authentication**: Require users to re-enter their password before performing sensitive actions like changing their email address or deleting their account.
|
- **Re-authentication**: Require users to re-enter their password before performing sensitive actions like changing their email address or deleting their account.
|
||||||
|
|
||||||
### Session Management ([WSTG-SESS](https://owasp.org/www-project-web-security-testing-guide/))
|
### Session Management
|
||||||
- **Session tokens**: Use high-entropy, randomly generated session IDs. Store them on the server-side (e.g., in a database or Redis cache). Avoid long-lived stateless tokens (like JWTs) for sessions unless you have a robust revocation strategy.
|
- **Session tokens**: Use high-entropy, randomly generated session IDs. Store them on the server-side (e.g., in a database or Redis cache). Avoid long-lived stateless tokens (like JWTs) for sessions unless you have a robust revocation strategy.
|
||||||
- **Cookie flags**:
|
- **Cookie flags**:
|
||||||
- `HttpOnly`: Prevents JavaScript from accessing the cookie, mitigating XSS.
|
- `HttpOnly`: Prevents JavaScript from accessing the cookie, mitigating XSS.
|
||||||
@ -125,7 +125,7 @@ Securing the environment where your application runs.
|
|||||||
- `SameSite=Lax` or `Strict`: A primary defense against CSRF. `Lax` is a good default.
|
- `SameSite=Lax` or `Strict`: A primary defense against CSRF. `Lax` is a good default.
|
||||||
- **Lifecycle**: Invalidate session tokens on the server-side immediately upon logout or a password change. Consider expiring idle sessions after a reasonable period (e.g., 15-30 minutes for sensitive applications).
|
- **Lifecycle**: Invalidate session tokens on the server-side immediately upon logout or a password change. Consider expiring idle sessions after a reasonable period (e.g., 15-30 minutes for sensitive applications).
|
||||||
|
|
||||||
### Authorization & Access Control ([WSTG-ATHZ](https://owasp.org/www-project-web-security-testing-guide/), IDOR)
|
### Authorization & Access Control
|
||||||
- **Server-side enforcement**: Authorization checks *must* be performed on the server. Never rely on hiding UI elements on the client, as an attacker can always craft their own requests.
|
- **Server-side enforcement**: Authorization checks *must* be performed on the server. Never rely on hiding UI elements on the client, as an attacker can always craft their own requests.
|
||||||
- **Object-level checks (IDOR)**: Insecure Direct Object References (IDOR) are a common and severe vulnerability. On every request that accesses a resource by an ID, verify that the current user is authorized to access that specific resource.
|
- **Object-level checks (IDOR)**: Insecure Direct Object References (IDOR) are a common and severe vulnerability. On every request that accesses a resource by an ID, verify that the current user is authorized to access that specific resource.
|
||||||
```go
|
```go
|
||||||
@ -151,7 +151,7 @@ Securing the environment where your application runs.
|
|||||||
- **Function-level checks**: Verify that the user's role permits them to perform the requested action (e.g., a `viewer` cannot `edit`).
|
- **Function-level checks**: Verify that the user's role permits them to perform the requested action (e.g., a `viewer` cannot `edit`).
|
||||||
- **Multi-tenant isolation**: In multi-tenant systems, ensure all database queries are strictly scoped to the current tenant ID to prevent data leakage between tenants.
|
- **Multi-tenant isolation**: In multi-tenant systems, ensure all database queries are strictly scoped to the current tenant ID to prevent data leakage between tenants.
|
||||||
|
|
||||||
### Input Validation & Output Encoding ([WSTG-INPV](https://owasp.org/www-project-web-security-testing-guide/), XSS)
|
### Input Validation & Output Encoding
|
||||||
- **Input validation**: Validate all incoming data on the server. Use an allowlist approach (i.e., accept only known-good values) and enforce strict types, formats, and length limits.
|
- **Input validation**: Validate all incoming data on the server. Use an allowlist approach (i.e., accept only known-good values) and enforce strict types, formats, and length limits.
|
||||||
- **Output encoding**: Encode all data before it is rendered in a template to prevent Cross-Site Scripting (XSS). Rely on the automatic contextual encoding provided by modern templating frameworks.
|
- **Output encoding**: Encode all data before it is rendered in a template to prevent Cross-Site Scripting (XSS). Rely on the automatic contextual encoding provided by modern templating frameworks.
|
||||||
```html
|
```html
|
||||||
@ -164,7 +164,7 @@ Securing the environment where your application runs.
|
|||||||
```
|
```
|
||||||
- **Untrusted HTML**: If you must render user-supplied HTML, sanitize it with a robust library like DOMPurify. Never use `innerHTML` or similar functions with unsanitized data.
|
- **Untrusted HTML**: If you must render user-supplied HTML, sanitize it with a robust library like DOMPurify. Never use `innerHTML` or similar functions with unsanitized data.
|
||||||
|
|
||||||
### Injection: SQL/NoSQL/Command/Template/LDAP ([WSTG-INPV](https://owasp.org/www-project-web-security-testing-guide/), [WSTG-INJ](https://owasp.org/www-project-web-security-testing-guide/))
|
### Injection: SQL/NoSQL/Command/Template/LDAP
|
||||||
- **Parameterized queries**: The single most effective defense against SQL injection is to use parameterized queries (also called prepared statements). Never build queries by concatenating strings.
|
- **Parameterized queries**: The single most effective defense against SQL injection is to use parameterized queries (also called prepared statements). Never build queries by concatenating strings.
|
||||||
```go
|
```go
|
||||||
// Vulnerable to SQL Injection
|
// Vulnerable to SQL Injection
|
||||||
@ -177,16 +177,16 @@ Securing the environment where your application runs.
|
|||||||
- **Command injection**: Avoid calling shell commands with user input. If you must, use functions that handle argument escaping properly and avoid parsing the command as a single string.
|
- **Command injection**: Avoid calling shell commands with user input. If you must, use functions that handle argument escaping properly and avoid parsing the command as a single string.
|
||||||
- **ORM/DB Libraries**: Use Object-Relational Mapping (ORM) libraries or database drivers that provide safe, parameterized APIs by default.
|
- **ORM/DB Libraries**: Use Object-Relational Mapping (ORM) libraries or database drivers that provide safe, parameterized APIs by default.
|
||||||
|
|
||||||
### Cross-Site Request Forgery ([WSTG-CRS](https://owasp.org/www-project-web-security-testing-guide/))
|
### Cross-Site Request Forgery
|
||||||
- **Synchronizer tokens**: The most robust defense is the synchronizer token pattern. A unique, unpredictable token is embedded in each form, and the server validates this token upon submission.
|
- **Synchronizer tokens**: The most robust defense is the synchronizer token pattern. A unique, unpredictable token is embedded in each form, and the server validates this token upon submission.
|
||||||
- **SameSite cookies**: Use `SameSite=Strict` or `SameSite=Lax` on your session cookies. This is a powerful defense that instructs the browser not to send cookies on cross-origin requests. It should be used in addition to synchronizer tokens for defense-in-depth.
|
- **SameSite cookies**: Use `SameSite=Strict` or `SameSite=Lax` on your session cookies. This is a powerful defense that instructs the browser not to send cookies on cross-origin requests. It should be used in addition to synchronizer tokens for defense-in-depth.
|
||||||
- **Check HTTP method**: Always ensure that state-changing actions are performed only via `POST`, `PUT`, `PATCH`, or `DELETE` requests, never `GET`.
|
- **Check HTTP method**: Always ensure that state-changing actions are performed only via `POST`, `PUT`, `PATCH`, or `DELETE` requests, never `GET`.
|
||||||
|
|
||||||
### Deserialization and Data Parsing ([WSTG-DV](https://owasp.org/www-project-web-security-testing-guide/), XXE)
|
### Deserialization and Data Parsing
|
||||||
- **Avoid unsafe deserialization**: In languages like Java, C#, and PHP, deserializing untrusted data can lead to remote code execution. Avoid generic deserialization of objects. Use simple data formats like JSON and parse them into strongly-typed objects.
|
- **Avoid unsafe deserialization**: In languages like Java, C#, and PHP, deserializing untrusted data can lead to remote code execution. Avoid generic deserialization of objects. Use simple data formats like JSON and parse them into strongly-typed objects.
|
||||||
- **XML External Entities (XXE)**: If you must parse XML, configure your parser to disable resolution of external entities (XXE) and DTDs to prevent information disclosure and SSRF.
|
- **XML External Entities (XXE)**: If you must parse XML, configure your parser to disable resolution of external entities (XXE) and DTDs to prevent information disclosure and SSRF.
|
||||||
|
|
||||||
### File Uploads & Downloads ([WSTG-BUSL](https://owasp.org/www-project-web-security-testing-guide/))
|
### File Uploads & Downloads
|
||||||
- **Upload validation**:
|
- **Upload validation**:
|
||||||
- Validate the file type on the server using its content (magic bytes), not just the `Content-Type` header or file extension.
|
- Validate the file type on the server using its content (magic bytes), not just the `Content-Type` header or file extension.
|
||||||
- Enforce strict size limits.
|
- Enforce strict size limits.
|
||||||
@ -196,7 +196,7 @@ Securing the environment where your application runs.
|
|||||||
- Assign a new, randomized filename to the stored file to prevent path traversal or execution attacks.
|
- Assign a new, randomized filename to the stored file to prevent path traversal or execution attacks.
|
||||||
- **Downloads**: For file downloads, set the `Content-Disposition: attachment; filename="user-facing-name.ext"` header to prevent the browser from rendering the file inline, which can lead to XSS.
|
- **Downloads**: For file downloads, set the `Content-Disposition: attachment; filename="user-facing-name.ext"` header to prevent the browser from rendering the file inline, which can lead to XSS.
|
||||||
|
|
||||||
### SSRF and Server-Side Fetches ([WSTG-SSR](https://owasp.org/www-project-web-security-testing-guide/))
|
### SSRF and Server-Side Fetches
|
||||||
- **Server-Side Request Forgery (SSRF)**: Occurs when an attacker can trick the server into making a request to an arbitrary destination.
|
- **Server-Side Request Forgery (SSRF)**: Occurs when an attacker can trick the server into making a request to an arbitrary destination.
|
||||||
```go
|
```go
|
||||||
// Vulnerable: fetches any URL provided by the user
|
// Vulnerable: fetches any URL provided by the user
|
||||||
@ -207,32 +207,32 @@ Securing the environment where your application runs.
|
|||||||
- **Allowlist**: Maintain a strict allowlist of permitted domains, IPs, and ports the server can connect to. Deny by default.
|
- **Allowlist**: Maintain a strict allowlist of permitted domains, IPs, and ports the server can connect to. Deny by default.
|
||||||
- **Block internal networks**: Explicitly block requests to private IP ranges (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) and cloud metadata endpoints (e.g., `169.254.169.254`).
|
- **Block internal networks**: Explicitly block requests to private IP ranges (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) and cloud metadata endpoints (e.g., `169.254.169.254`).
|
||||||
|
|
||||||
### Path Traversal & Resource Access ([WSTG-ATHZ](https://owasp.org/www-project-web-security-testing-guide/), [WSTG-ATHN](https://owasp.org/www-project-web-security-testing-guide/))
|
### Path Traversal & Resource Access
|
||||||
- **Path normalization**: If accessing files based on user input, normalize the path to resolve sequences like `../` and ensure it is still within the intended directory.
|
- **Path normalization**: If accessing files based on user input, normalize the path to resolve sequences like `../` and ensure it is still within the intended directory.
|
||||||
- *Example Attack*: `?filename=../../../etc/passwd`
|
- *Example Attack*: `?filename=../../../etc/passwd`
|
||||||
|
|
||||||
### Error Handling, Logging, and Privacy ([WSTG-INFO](https://owasp.org/www-project-web-security-testing-guide/), [WSTG-CONF](https://owasp.org/www-project-web-security-testing-guide/))
|
### Error Handling, Logging, and Privacy
|
||||||
- **Generic errors**: Show generic, non-technical error messages to the user.
|
- **Generic errors**: Show generic, non-technical error messages to the user.
|
||||||
- **Bad**: `FATAL: connection to database "prod_db" failed: password authentication failed for user "webapp"`
|
- **Bad**: `FATAL: connection to database "prod_db" failed: password authentication failed for user "webapp"`
|
||||||
- **Good**: `An unexpected error occurred. Please try again. (Error ID: 9f4e1a2b)`
|
- **Good**: `An unexpected error occurred. Please try again. (Error ID: 9f4e1a2b)`
|
||||||
- **Structured logging**: Log security-relevant events in a structured format like JSON. Redact all sensitive data (passwords, PII, API keys) from logs.
|
- **Structured logging**: Log security-relevant events in a structured format like JSON. Redact all sensitive data (passwords, PII, API keys) from logs.
|
||||||
|
|
||||||
### Cryptography & Data Protection ([WSTG-CRYP](https://owasp.org/www-project-web-security-testing-guide/))
|
### Cryptography & Data Protection
|
||||||
- **Use standard libraries**: Use well-vetted, standard cryptographic libraries for your language. Do not invent your own crypto.
|
- **Use standard libraries**: Use well-vetted, standard cryptographic libraries for your language. Do not invent your own crypto.
|
||||||
- **Modern algorithms**: Use modern, authenticated encryption (AEAD) ciphers like AES-256-GCM or ChaCha20-Poly1305.
|
- **Modern algorithms**: Use modern, authenticated encryption (AEAD) ciphers like AES-256-GCM or ChaCha20-Poly1305.
|
||||||
- **Key management**: Encrypt sensitive data both in transit (TLS) and at rest (database/disk encryption). Use a dedicated Key Management Service (KMS) or Hardware Security Module (HSM) to manage encryption keys.
|
- **Key management**: Encrypt sensitive data both in transit (TLS) and at rest (database/disk encryption). Use a dedicated Key Management Service (KMS) or Hardware Security Module (HSM) to manage encryption keys.
|
||||||
|
|
||||||
### Browser and Platform Security ([WSTG-CLNT](https://owasp.org/www-project-web-security-testing-guide/))
|
### Browser and Platform Security
|
||||||
- **Content Security Policy (CSP)**: A strong CSP is a critical defense against XSS. Start with a strict policy and use nonces or `strict-dynamic` for scripts.
|
- **Content Security Policy (CSP)**: A strong CSP is a critical defense against XSS. Start with a strict policy and use nonces or `strict-dynamic` for scripts.
|
||||||
- **Clickjacking defense**: Use the `Content-Security-Policy: frame-ancestors 'self'` header (or the older `X-Frame-Options: SAMEORIGIN`) to prevent your site from being embedded in an iframe on a malicious site.
|
- **Clickjacking defense**: Use the `Content-Security-Policy: frame-ancestors 'self'` header (or the older `X-Frame-Options: SAMEORIGIN`) to prevent your site from being embedded in an iframe on a malicious site.
|
||||||
- **Subresource Integrity (SRI)**: When loading scripts or styles from a third-party CDN, use SRI to ensure the file has not been tampered with.
|
- **Subresource Integrity (SRI)**: When loading scripts or styles from a third-party CDN, use SRI to ensure the file has not been tampered with.
|
||||||
`<script src="https://example.com/library.js" integrity="sha384-..." crossorigin="anonymous"></script>`
|
`<script src="https://example.com/library.js" integrity="sha384-..." crossorigin="anonymous"></script>`
|
||||||
|
|
||||||
### CORS ([WSTG-CONF](https://owasp.org/www-project-web-security-testing-guide/))
|
### CORS
|
||||||
- **Explicit allowlist**: Your server should respond with an `Access-Control-Allow-Origin` header that specifies the exact origin(s) allowed.
|
- **Explicit allowlist**: Your server should respond with an `Access-Control-Allow-Origin` header that specifies the exact origin(s) allowed.
|
||||||
- **Credentials**: If you must set `Access-Control-Allow-Credentials: true`, the `Access-Control-Allow-Origin` header *cannot* be a wildcard (`*`). It must be an explicit origin.
|
- **Credentials**: If you must set `Access-Control-Allow-Credentials: true`, the `Access-Control-Allow-Origin` header *cannot* be a wildcard (`*`). It must be an explicit origin.
|
||||||
|
|
||||||
### API (REST/GraphQL) Specifics ([WSTG-API](https://owasp.org/www-project-web-security-testing-guide/))
|
### API (REST/GraphQL) Specifics
|
||||||
- **Schema validation**: Strictly validate all incoming requests against a defined schema. Reject any requests with unknown or malformed parameters.
|
- **Schema validation**: Strictly validate all incoming requests against a defined schema. Reject any requests with unknown or malformed parameters.
|
||||||
- **Resource limiting**: Implement pagination on all endpoints that return lists of data. Limit the size and complexity of API requests to prevent denial-of-service.
|
- **Resource limiting**: Implement pagination on all endpoints that return lists of data. Limit the size and complexity of API requests to prevent denial-of-service.
|
||||||
- **GraphQL security**:
|
- **GraphQL security**:
|
||||||
@ -240,7 +240,7 @@ Securing the environment where your application runs.
|
|||||||
- **Disable introspection**: Turn off GraphQL introspection in production environments to avoid leaking schema information.
|
- **Disable introspection**: Turn off GraphQL introspection in production environments to avoid leaking schema information.
|
||||||
- **Authorization**: Implement authorization checks at the resolver level for each field.
|
- **Authorization**: Implement authorization checks at the resolver level for each field.
|
||||||
|
|
||||||
### Secrets and Supply Chain ([WSTG-CONF](https://owasp.org/www-project-web-security-testing-guide/))
|
### Secrets and Supply Chain
|
||||||
- **Central secret store**: Use a vault for all secrets. Your CI/CD pipeline, infrastructure, and applications should all fetch secrets from this central store at runtime.
|
- **Central secret store**: Use a vault for all secrets. Your CI/CD pipeline, infrastructure, and applications should all fetch secrets from this central store at runtime.
|
||||||
- **Supply chain**:
|
- **Supply chain**:
|
||||||
- **Signed builds**: Sign your build artifacts to ensure their integrity.
|
- **Signed builds**: Sign your build artifacts to ensure their integrity.
|
||||||
@ -256,7 +256,7 @@ Securing the environment where your application runs.
|
|||||||
- **Read-only rootfs**: Configure the container's root filesystem to be read-only where possible.
|
- **Read-only rootfs**: Configure the container's root filesystem to be read-only where possible.
|
||||||
- **Network policies**: Use Kubernetes network policies or cloud security groups to restrict traffic between services (east-west) and from the internet (north-south).
|
- **Network policies**: Use Kubernetes network policies or cloud security groups to restrict traffic between services (east-west) and from the internet (north-south).
|
||||||
|
|
||||||
## Pre-Release Test Checklist (mapping to WSTG)
|
## Pre-Release Test Checklist
|
||||||
|
|
||||||
- **Recon & Info**: review exposed endpoints, metadata, headers (WSTG-INFO)
|
- **Recon & Info**: review exposed endpoints, metadata, headers (WSTG-INFO)
|
||||||
- **Authn/Authz**: test login flows, MFA, password reset, IDOR, function-level authz (WSTG-ATHN/ATHZ)
|
- **Authn/Authz**: test login flows, MFA, password reset, IDOR, function-level authz (WSTG-ATHN/ATHZ)
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user