🍩
HackBook.io
  • Pentesting Pocket Book for hackers and developers.
  • Reconnaissance
    • Internal Recon Basics
    • OSINT
      • Infrastructure
      • Recon-ng
      • Users
      • Google Dorks
    • Active Scanning
      • NMAP
        • NSE
          • reconnoitre
        • NMap Evasion
      • NC Scan
      • Finger Printing
    • Web Server OSINT
      • WhatWeb
      • Subdomains
      • Directory & File Enumeration
        • Enumeration
          • GoCutty
          • gobuster
          • Dirb
          • nikto
        • Fuzzing
        • Crawling
  • Web Application Hacking
    • Web 101
      • Clients
      • Servers
      • Encodings
    • Web Hacking Techniques
      • SOP
      • Open Redirect
      • File & Resource Attacks
        • Directory Traversal
          • Dir Traversal Fuzzer
        • LFI
        • RFI
        • Unrestricted File Uploads
      • XSS
        • DOM
        • Stored
        • Reflected
        • Blind
        • Self XSS
      • XXE
        • XXE Payloads
      • XPath
      • SSRF
      • CSRF
      • SQLi
        • SQL Basics
        • Securing SQL
        • Hacking SQL
          • sqlmap
          • In-Band
          • Error Based
          • Blind
      • Authorization
      • Session Hijacking
      • Command Injection
      • Insecure Deserialization
      • File Uploads
        • File Upload Mitigations
      • HPP
      • Click Jacking
        • Adobe SWF Investigator
      • HTTP Response Splitting
      • Flash 101
        • Flash Hacking
      • HTML5
        • WebSockets
        • CORS
          • iframe
          • Headers
    • Web Hacking Procedures
      • Captcha
      • Username Generation
      • Username Enumeration
      • Inhouse WebApps
      • SSL Cert Generation
      • CMS
        • WordPress
        • Joomla
      • Popular Exploits
        • Bludit CMS
        • ShellShock
        • WebDav
  • Weaponization
    • Buffer Overflows (BOF)
      • DSBOFG
        • Scripts
  • Initial Access
    • 😈Services
      • Finger
      • SNMP
      • LDAP
      • SMTP
      • NFS
      • RPC
        • RPCBind
      • RDP
      • SQL
        • NoSQL
      • POP3
      • Samba
      • SMB
      • SSH
      • Telnet
      • NetBios
      • VOIP/SIP
      • DNS
        • DNS Lookups
        • Zone Transfer
        • SubDomain Enums
        • dnsdumpster
    • 😈Shells
      • Powercat
      • Odd Shells
      • Troubleshoot
      • TTY/PTTY
  • Persistence
    • File Transfers
      • Py->Exe->Txt
      • Cross compile example
    • Backdoors
  • Privilege Escalation
    • Universal Escalation
    • Windows Escalation
      • Automated
      • Popular Exploits
        • ActiveXObject to Wscript RCE
        • Macros
        • Object Linking
    • Linux Escalation
      • Automated
    • Passwords
      • John
      • Medusa
      • Cewl
      • ncrack
      • Crunch
      • Hydra
      • MITM
      • Responder
        • SAM
          • pwdump and fgdump
          • Pass-the-hash
      • Crack the hash
      • NTLM
  • Network Discovery
    • Network Traffic
      • tcpdump
    • Internal Discovery
  • Collection and Staging
    • Collection
      • File types
  • Hacking Objectives
    • Non Kinetic War (Quick Guide)
  • Procedures
    • Bash Guide
    • Active Directory
    • Crypto 101
    • Forensics
  • Glossary
  • Hacking Frameworks
    • Metasploit
      • msfvenom
    • Dsnif
  • ThreatModeling
    • Threat Modeling Overview
  • Certifications
    • VMDR
      • Qualys Asset Management
      • Qualys Vulnerability Management
      • Qualys Threat Prioritization
      • Qualys Response (Patch Deployment)
    • OSCP Cheat Sheet
  • RF - Radio Frequency
    • Ham Technician
Powered by GitBook
On this page
  • Things to look for:
  • Redirect GET requests:
  • Examples of such vulnerabilities can look like:
  • Impact:
  • Prevention:

Was this helpful?

  1. Web Application Hacking
  2. Web Hacking Techniques

Open Redirect

The Open Redirect is a vulnerability that occurs when a developer does not verify that the redirect URL is one of its own or a trusted 3rd party. To a hacker, this means that they can silently navigate a user off of the page if there are no "interstitial redirect popups or warning splash pages. With this they can send innocent looking links or phish that look to be of a trusted domain (before the redirect).

Things to look for:

  • 2 GET requests generated by a single link or URL

  • URL params (url, u, r, redirect, next, link, ..)

  • Can you inject <meta> tags or edit them

  • Can you modify the DOM location property

Redirect GET requests:

Keep and eye out for 3XX response codes and for redirect params in proxy history. Then see if you are getting a second GET request being generated from the single URL or Link that you crawled (not invoked by a JS call). If so then this is a good candidate for an open redirect. Check to see if the second location is being referenced in the link/url and if so; can it be modified to leave the site? The best scenario would be a redirect where yo get redirected off the site and you do net get a pop up warning.

This same investigation and attack works with the <meta> refresh HTML tag and the DOM Location window property. All 3 of these can generate the 3XX redirects you can leverage.

Examples of such vulnerabilities can look like:

URL/Link based:

In this following case we have a link/URL based redirect where we can replace gmail.com with our attacker domain. If the server allows us to do this we have an Open Redirect vuln.

https://www.google.com/?redirect_to=https://www.gmail.com

Meta based:

The following is an example of what it can look like in an HTML <meta> tag. The same concept applies.

<meta http-equiv="refresh" content="0; url=https://www.google.com/">

Here, once the meta tag is rendered the browser starts a counter and in this case waits 0 seconds before then requesting the google.com link in the content parameter.

DOM based:

The window location DOM property can be controlled either through JS or by the site allowing us to specify our own location values as a feature. To leverage the JS option we typically will have to be leveraging a XSS vuln and chaining these together for impact. The following are examples of how those javascript calls could be made.

window.location = https://www.google.com
window.location.href = https://www.google.com
window.location.replace(https://www.google.com)

Impact:

Prevention:

When a redirect occurs, the server first determines where to send your browser and if the destination site is up. If it is, the site will typically return a 302 to the browser with the location to navigate to via a GET. Its this check that the application and server are doing that should also include a verification to ensure the redirect destination has not been tampered with or is a trusted location within your organizations spec.

Although typically 302's these redirects can also be 301, 303, 307, or 308's

PreviousSOPNextFile & Resource Attacks

Last updated 3 years ago

Was this helpful?

Get the user on to your own site where you have scripts waiting to do your dirty work. Once you are finished it would be best to send them back to the intended link location for the least amount of "oddity" in the end-user's eyes.

🙈
🙉