rebuild
All checks were successful
Build Quartz Notes / build (push) Successful in 34s

This commit is contained in:
2026-06-02 16:17:27 +01:00
parent 5c2c50ee53
commit 7c077a0678
17 changed files with 37664 additions and 62 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 270 KiB

View File

@@ -0,0 +1,33 @@
# Definition:
- Cross Site Scripting (XSS) is a type of security vulnerability typically found in web applications. It allows attackers to inject malicious scripts into content from otherwise trusted websites.
# Types of XSS:
## 1\. Stored XSS / Persistent XSS / Type 2 XSS:
The malicious script is permanently stored on the target server, such as in a database, message forum, visitor log, comment field, etc. When a user requests the stored information, the malicious script is served as part of the web page.
Example: An attacker posts a comment containing a malicious script on a blog. When other users view the comment, the script executes in their browsers, potentially stealing their cookies or performing other malicious actions.
## 2\. Reflected XSS / Non-Persistent XSS / Type 1 XSS:
The malicious script is reflected off a web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected XSS is delivered to victims via another route, such as in an email or a third-party web site.
Example: An attacker crafts a URL that includes a malicious script. When a user clicks on the link, the script is reflected off the server and executed in the user's browser.
## 3\. DOM-based XSS:
The vulnerability exists in the client-side code rather than the server-side code. The malicious script is executed as a result of modifying the DOM (Document Object Model) environment in the victim's browser, which causes the client-side code to execute in an unintended manner.
Example: An attacker manipulates the URL of a web page to include a malicious script. When the page processes the URL, it executes the script in the user's browser.
# Prevention:
- Input Validation: Ensure that all user input is properly validated and sanitized before being processed or stored. This includes using whitelisting techniques to allow only expected input.
- Output Encoding: Encode output to ensure that any potentially malicious scripts are rendered harmless when displayed in the browser. This can be done using functions that convert special characters to their corresponding HTML entities.
- Content Security Policy (CSP): Implement a Content Security Policy to restrict the sources from which scripts can be loaded and executed. This can help mitigate the impact of XSS attacks.
- Use Security Libraries: Utilize security libraries and frameworks that provide built-in protection against XSS vulnerabilities.

View File

@@ -0,0 +1,18 @@
This stands for Open Web Application Security Project.
It is a non profit foundation which publishes the OWASP top 10, which is a standard document that identifies the most critical security risks to web applications.
Current edition: **OWASP Top 10:2025**
The 2025 list ranks risks as follows:
- **A01:2025 Broken Access Control**: Remains the #1 risk, covering unauthorized access and privilege escalation; includes [[Server-Side Request Forgery (SSRF)]]. 
- **A02:2025 Security Misconfiguration**: Moved up to #2, highlighting insecure defaults, exposed services, and inconsistent controls. 
- **A03:2025 Software Supply Chain Failures**: A new, expanded category (from "Vulnerable and Outdated Components") covering dependencies, CI/CD systems, and distribution infrastructure. 
- **A04:2025 Cryptographic Failures**: Covers insecure encryption, weak key management, and data exposure. 
- **A05:2025 Injection**: Includes SQL, OS, and template injection flaws. 
- **A06:2025 Insecure Design**: Focuses on architectural weaknesses and lack of threat modeling. 
- **A07:2025 Authentication Failures**: Covers weak login flows, session handling, and password policies. 
- **A08:2025 Software or Data Integrity Failures**: Addresses tampering with code, data, or CI/CD pipelines. 
- **A09:2025 Security Logging & Alerting Failures**: Highlights gaps in monitoring that allow attacks to go undetected. 
- **A10:2025 Mishandling of Exceptional Conditions**: A new category focusing on unsafe error handling and system resilience during failures.

View File

@@ -0,0 +1,17 @@
This is a critical web security vulnerability where an attacker manipulates a server into making unauthorised HTTP requests to internal or external resources on the attacker's behalf.
## How SSRF Attacks Work
In a typical SSRF attack, the attacker manipulates input fields (such as URL parameters, form fields, or HTTP headers) that the server uses to initiate a request. Because the request originates from the trusted server itself, it often bypasses firewalls, VPNs, and network segmentation that would block direct external access. 
### Common Attack Vectors
- **Cloud Metadata Services:** Attackers often target cloud provider metadata endpoints (e.g., `http://169.254.169.254/` in AWS) to steal temporary credentials and configuration data. 
- **Internal Services:** Requests can be directed to internal administrative dashboards, databases with HTTP interfaces (like MongoDB or Redis), or other backend services lacking authentication. 
- **Local File System:** By using the `file://` protocol, attackers may attempt to read sensitive files on the server (e.g., `/etc/passwd`). 
- **Port Scanning:** SSRF can be used to scan internal networks for open ports and running services by observing response times or error messages.
![[Pasted image 20260602161410.png]]