# Detecting Open Redirection Attacks ## What is Open Redirection - occurs when website redirects user to different URL without proper validation or sanitization of target URL ## Open Redirection Types/Possible Vectors 1. URL-Based Open Redirection `www.example.com/vulnerable_redirect.php?url=maliciousurl.com` 2. JavaScript-Based Open Redirection 3. Meta refresh-based Open Redirection 1. when meta-refresh tag (HTML) is used 4. Header-based Open Redirection 1. when HTTP headers perform redirect 5. Parameter-Based Open Redirection 1. when parameter in URL or in a form submission is part of the redirect process Vulnerable Code: ![[Example+Vulnerable.png]] ## Impact of Open Redirection 1. Phishing attacks 2. Malware Distribution 3. Social Engineering 1. fraud payments, sensitive information 4. Reputation Damage 5. Legal and Regulatory Consequences ## Prevention Methods for Open Redirection - Validate and Sanitize Input - Use Whitelist Approach - Avoid Using user-controlled data in redirects - Implement proper authorization and authentication - implement secure coding practices - Educate users about potential risks - Stay informed about web security best practices Fixed Code: ![[Example+Fixed.png]] ## Detecting Open Redirect Attacks - ?next or ?url - Localhost - `[::] - `①②⑦.⓪.⓪.⓪ - CIDR - `http://127.0.0.0 - Decimal Bypass - `http://2130706433/ = http://127.0.0.1 - Hexadecimal Bypass - `http://0x7f000001/ = http://127.0.0.1 - Encoded Characters - `%2f = / ### Regex Use regex to automatically detect open redirect attacks `/^.*"GET.*\?.*=(https%3a%2f%2f[a-z0-9-]+%2e[a-z]{2,}).+?.*HTTP\/.*".*$/gm The above regex matches any log entry with an HTTP GET request, the query is x.com, and http is 1.0 or 1.1. Therefore, change or add regex options to match cases. # Detecting Directory Traversal Attacks Directory Traversal is an attack type that attackers leverage to access files and directories which are stored outside the web server's root directory. This is typically done via a manipulation of input, like "../" and can be used to gain access to sensitive data or execute arbitrary code on a web server. Very similar at first look to Local File Inclusion. The difference between them is the source of the input. Directory traversal involves in manipulating the input that is used to access files on a web server, whereas LFI involves in manipulating input that is used to include local files within a web application. LFI can use user input to include file from local file system into application. This can allow the attacker to execute arbitrary code on the server to access the sensitive data. ## Possible Vectors 1. User Input 1. URL, file path, form fields via ../ 2. Cookies, by manipulating value to access files outside intended directory 3. HTTP headers 1. Referrer or User-Agent 4. File Upload 5. Direct Requests 1. guess or brute-force path names 6. URL Manipulation 1. /../ to go up one directory level 7. Malicious Links Vulnerable Code ![[img3.png]] ## Impact Attackers can view, modify, and/or delete files they'd otherwise be unable to access. 1. Disclosure of sensitive data 2. Execution of arbitrary code 3. Denial of service 4. System compromise ## Prevention Methods - Input validation and sanitation - regex to check input for valid characters - limit input to known values and directories - access controls - limit access only to files and directories required to function - relative file paths - prevents attackers from using ../ to navigate up directories - whitelisting - only specific characters are allowed in file name parameter - secure coding practices - avoid user input directly in file path concatenation - use secure file upload mechanisms - avoid use of insecure functions like eval() and system() - web application firewalls - detect and block directory traversal attacks Fixed Code ![[img4.png]] ## Detecting Attacks - ../ aka %2e%2e%2f aka %252e%252e%252f - Regex to find: `/^.*"GET.*\?.*=(%2e%2e%2f).+?.*HTTP\/.*".*$/gm` - Unicode to bypass WAF - . = %c0%2e, %e0E40%ae, %c0ae - / = %c0%af, %e0%80%af, %c0%2f - \ = %c0%5c, %c0%80%5c - popular targets - Linux - /etc/issue - /etc/passwd - /etc/shadow - /etc/group - /etc/hosts - Windows - c:/boot.ini - c:/inetpub/logs/logfiles - c:/inetpub/wwwroot/global.asa - c:/inetpub/wwwroot/index.asp - c:/inetpub/wwwroot/web.config - c:/sysprep.inf The following is a basic regex that will also prevent false alarms ``` /^.*"GET.*\?.*=(.+?(?=%2e%2e%2fetc%2f)).+?.*HTTP\/.*".*$/gm ``` # Detecting Brute Force Attacks Guessing a password, token, or other unknown by systematically trying every possible combination until the correct one is found. Particularly effective against weak or poorly protected passwords, can also be very time-consuming and resource intensive, especially if BF countermeasures are in place ## Possible Vectors Web apps are particularly vulnerable as they are typically accessible over the internet and rely on user authentication to control access to sensitive data or functionality. Directory forcing is possible as well, effective against web apps that don't implement proper access controls or have poorly configured web servers Vulnerable Code ![[img1.png]] ## Impact of Brute Forcing 1. Denial of Service 2. Data Leakage 3. Account Takeover 4. Password Reuse 5. Legal and Reputational Consequences ## Prevention Methods - Implement CAPTCHA - Limit rate of login attempts - Use multi-factor authentication - Monitor login attempts - Use strong passwords and password policies WAFs - IP block potential bad actors - User behavior analysis ## Detecting Brute Forcing Attacks Patterns of suspicious activity - particular IP address - short/impossible timeframe requests - requests to non-existent pages Deploy IDS or IPS to analyze network traffic and detect bruteforce attacks Attack vectors include dictionary attacks or password spraying. Some actors may obfuscate attempts by using valid credentials/compromised account. (302 is successful login attempt) Cookie header can also include **PHPSESSID** and login value to track session and authentication status In NGINX - Log analysis tools - logstash, elasticsearch, kibana - regular expressions AFTER DETECTION - Fail2ban - IP Blocking REGEX for detecting repeated login attempts from same IP address in nginx logs specifically to the login page ``` /^(\S+) \S+ \S+ \[.*?\] "(POST|GET) \/login\.php.*?" (401|403) \d+ ".*?" ".*?"/gm ``` # Detecting XML External Entity Attacks XML is a markup language used for structuring and storing data that is both human and machine readable. Widely used for data exchange. Flexible and extensible, but usage has declined due to JSON XXE (XML External Entity) vulns are when an attacker injects malicious XML data into an application which uses an XML parser without proper validation. An external entity is a piece of XML that is defined outside of the XML document, but can be referenced and included within the document. Vulnerable Code ![[img1 1.png]] ## Possible Vectors 1. Form fields that accept XML input 2. XML files uploaded by users 3. APIs that accept XML requests 4. XML files used for configuration or other purposes libxml_disable_entity_loader() disables loading of external entities in PHP. Can also filter_var() to ensure XML input is properly formatted. ## Possible Impact 1. Information Disclosure 2. Server-side request forgery (SSRF) - making requests on behalf of the server 3. Denial of Service(DOS) 4. Remote Code Execution(RCE) ## Prevention Methods for XML External Entity - Disable external entities - set appropriate parser config - use secure XML parser that has external entity processing disabled by default - Input validation and sanitization - use secure parsers - use whitelist filtering - implement access controls - use secure coding practices ## Detecting XML External Entity Attacks Keywords - DOCTYPE - ELEMENT - ENTITY ``` ^(\S+) - (\S+) \[(.*?)\] "(\S+) (.*?)\?(?=.*?\b21DOCTYPE\b).*? HTTP\/\d\.\d" (\d+) (\d+) "(.*?)" "(.*?)" ``` ^ for !DOCTYPE in nginx logs Basic XXE Payload ![[img7.png]] Blind XXE Payload ![[img8.png]] XXE Payload with PHP Filter ![[img9.png]]