Sec-88
  • 🧑Whoami
  • 🕸️Web-AppSec
    • Features Abuse
      • 2FA
      • Ban Feature
      • CAPTCHA
      • Commenting
      • Contact us
      • File-Upload
      • Inviting Feature
      • Messaging Features
      • Money-Related Features
      • Newsletter
      • Profile - Settings
      • Registration
      • Reset Password
      • Review
      • Rich Editor/Text
      • Social Sharing
      • Billing-Shipping Address Management
      • Integrations - Webhooks
      • API Key Management
    • Reconnaissance
      • Attacking Organizations with big scopes
    • Subdomain Enumeration
    • Fingerprinting
    • Dorking
    • XSS-HTML Injection
    • Improper Authentication
      • JWT Security
    • OAUTH Misconfigurations
      • OAuth 2.0 Basics
      • OAUTH Misconfigurations
    • Auth0 Misconfigurations
    • Broken Access Control
      • Insecure Direct Object References (IDOR)
      • 403 Bypass
    • Broken Link Injection
    • Command Injection
    • CORS
    • CRLF
    • CSRF
    • Host Header Attacks
    • HTTP request smuggling
    • JSON Request Testing
    • LFI
      • LFI to RCE
    • No Rate Limit
    • Parameters Manual Testing
    • Open Redirect
    • Registration & Takeover Bugs
    • Remote Code Execution (RCE)
    • Session Fixation
    • SQL Injection
      • SQL To RCE
    • SSRF
    • SSTI
    • Subdomain Takeover
    • Web Caching Vulnerabilities
    • WebSockets
    • XXE
      • XXE to RCE
    • Cookie Based Attacks
    • CMS
      • AEM [Adobe CMS]
    • XSSI (Cross Site Script Inclusion)
    • NoSQL injection
    • Local VS Remote Session Fixation
    • Protection
      • Security Mechanisms for Websites
      • Cookie Flags
      • SameSite Cookie Restrictions
      • Same-origin policy (SOP)
      • CSP
    • Hacking IIS Applications
    • Dependency Confusion
    • Attacking Secondary Context
    • Hacking Web Sockets
    • IDN Homograph Attack
    • DNS Rebinding Attack
    • LLM Hacking Checklist
    • Bypass URL Filtration
    • Cross-Site Path Traversal (CSPT)
    • PostMessage Security
    • Prototype Pollution
      • Client-Side Prototype Pollution
      • Server-Side prototype pollution
    • Tools-Extensions-Bookmarks
    • WAF Bypassing Techniques
    • SSL/TLS Certificate Lifecycle
    • Serialization in .NET
    • Client-Side Attacks
      • JavaScript Analysis
    • Bug Bounty Platforms/Programs
  • ✉️API-Sec
    • GraphQL API Security Testing
      • The Basics
      • GraphQL Communication
      • Setting Up a Vulnerable GraphQL Server
      • GraphQL Hacking Tools
      • GraphQL Attack Surface
      • RECONNAISSANCE
      • GraphQL DOS
      • Information Disclosure
      • AUTHENTICATION AND AUTHORIZATION BYPASSES
      • Injection Vulnerabilities in GraphQL
      • REQUEST FORGERY AND HIJACKING
      • VULNERABILITIES, REPORTS AND EXPLOITS
      • GraphQL Hacking Checklist
    • API Recon
    • API Token Attacks
    • Broken Object Level Authorization (BOLA)
    • Broken Authentication
    • Evasive Maneuvers
    • Improper Assets Management
    • Mass Assignment Attacks
    • SSRF
    • Injection Vulnerabilities
    • Excessive Data Exposure
    • OWASP API TOP 10 MindMap
    • Scanning APIs with OWASP ZAP
  • 📱Android-AppSec
    • Setup Android App Pentesting environment on Arch
    • Setup Android App Pentesting environment on Mac M4
    • Setup Android Pentesting Environment on Debian Linux
    • Android App Fundamentals
      • Android Architecture
      • Android Security Model
      • Android App Components
        • Intents
        • Pending Intents
    • Android App Components Security Cheatsheet
    • Android App Pentesting Checklist
    • How To Get APK file for application
    • ADB Commands
    • APK structure
    • Android Permissions
    • Exported Activity Hacking
    • BroadcastReceiver Hacking
    • Content Provider Hacking
    • Signing the APK
    • Reverse Engineering APK
    • Deep Links Hacking
    • Drozer Cheat Sheet
    • SMALI
      • SMALI Cheat Sheet
      • Smali Code Patching Guide
    • Intent Redirection Vulnerability
    • Janus Vulnerability (CVE-2017-13156)
    • Task Hijacking
    • Hacking Labs
      • Injured Android
      • Hacking the VulnWebView Lab
      • Hacking InsecureBankv2 App
    • Frida Cheat Sheet
  • 📶Network-Sec
    • Networking Fundamentals
    • Open Ports Security Testing
    • Vulnerability Scanning
    • Client Side Attacks
    • Port Redirection and Tunneling
    • Password Attacks
    • Privilege Escalation [PrevEsc]
      • Linux Privilege Escalation
    • Buffer Overflow (BOF)
      • VulnServer
      • Sync Breez Enterprize
      • Crashed CTF
      • BOF for Linux
    • AV Evasion
    • Post Exploitation
      • File Transfer
      • Maintaining Access
      • Pivoting
      • Clean Up
    • Active Directory
      • Basic AD Pentesting
  • 💻Desktop AppSec
    • Thin Client vs. Thick Client
  • ☁️Cloud Sec
    • Salesforce Hacking
      • Basics
      • Salesforce SAAS Apps Hacking
    • Firebase
    • S3 Buckets Misconfigurations
  • 👨‍💻Programming
    • HTML
    • JavaScript (JS)
      • window.location object
    • Python
      • Python Tips
      • Set
        • SetMethods
    • JAVA
      • Java Essentials
      • Java Essentials Code Notes
      • Java OOP1
      • JAVA OOP Principles
        • Inheritance
        • Method Overriding
        • Abstract Class
        • Interface
        • polymorphism
        • Encapsulation
        • Composition
      • Java OOP Challenges
      • Exception Handling
    • Go
      • Go Syntax Tutorial in one file
      • Methods and Interfaces
      • Go Slices
      • Go Maps
      • Go Functions
      • Concurrency
      • Read Files
      • Write Files
      • Package
        • How to make personal Package
        • regexp Packages
        • Json
        • bufio
        • Time
      • Signals-Exit
      • Unit Testing
  • 🖥️Operating Systems
    • Linux
      • Linux Commands
      • Tools
      • Linux File System
      • Bash Scripting guide
      • tmux
      • Git
      • Install Go tools from private repositories using GitHub PAT
    • VPS
    • Burp Suite
  • ✍️Write-Ups
    • Hunting Methodology
    • API BAC leads to PII Data Disclosure
    • Misconfigured OATUH leads to Pre-Account Takeover
    • Automating Bug Bounty with GitHub Actions
    • From Recon to Reward: My Bug Bounty Methodology when Hunting on Public Bug Bounty Programs
    • Exploring Subdomains: From Enumeration to Takeover Victory
    • 0-Click Account Takeover via Insecure Password Reset Feature
    • How a Simple Click Can Lead to Account Takeover: An OAuth Insecure Implementation Vulnerability
    • The Power Of IDOR even if it is unpredictable IDs
    • Unlocking the Weak Spot: Exploiting Insecure Password Reset Tokens
    • AI Under Siege: Discovering and Exploiting Vulnerabilities
    • Inside the Classroom: How We Hacked Our Way Past Authorization on a Leading EdTech Platform
    • How We Secured Our Client’s Platform Against Interaction-Free Account Thefts
    • Unchecked Privileges: The Hidden Risk of Role Escalation in Collaborative Platforms
    • Decoding Server Behavior: The Key to Mass Account Takeover
    • Exploiting JSON-Based CSRF: The Hidden Threat in Profile Management
    • How We Turned a Medium XSS into a High Bounty by Bypassing HttpOnly Cookie
Powered by GitBook
On this page
  • Session Fixation Local Vector
  • Steps to reproduce
  • Session fixation remote vector
  • Resources

Was this helpful?

Edit on GitHub
  1. Web-AppSec

Session Fixation

CWE-384: Session Fixation

PreviousRemote Code Execution (RCE)NextSQL Injection

Last updated 1 year ago

Was this helpful?

Session Fixation Local Vector

Steps to reproduce

  1. As the attacker go to [https://wallet.sandbox.romit.io](https://wallet.sandbox.romit.io/) (but do not login!) and check the cookies romit.sandbox.session and SANDBOX-XSRF-TOKEN, that are set. For example:

    SANDBOX-XSRF-TOKEN=AAG02cId-yyza3k8uhQR7JKuB-4YOmhizkjM; romit.sandbox.session=s%3AEHm0kA9uwWYHayOwdRQXbuZWEIRIliQZ.ndejz36ofa52c9ENnApLuaLkMnTYCot3IiY1qdTvz0w;
    1. Now simulate the victim by opening a second browser and setting those two cookies.

    2. As the victim, login in the second browser.

    3. As the attacker, go to https://wallet.sandbox.romit.io (using the first browser / same cookies as in step 1).

    4. You are now logged in to the victims account.

    Possible exploitation scenarios

    1. This can be exploited if there is another bug like HTTP Response Splitting on your website.

    2. But a far easier way is to exploit this on shared computers. For example in a library, as an attacker open https://wallet.sandbox.romit.io (but do not login!) and keep note of the cookies as above in step 1.

    3. Then simply go away and now when a victim will use the same computer and try to login, the attacker will have access to the victims account.

    Mitigation

    1. If you assign a new session when someone logs in, this flaw should be fixed.

  • Method 2

    1. open chrome and download edit this cookie ad-don

    2. now open and log in

    3. now goto edit this cookie addon and click export all cookies ...by clicking this we get the cookie copied in clipboard..

    4. logout from your account...

    5. if needed u can close and open your browser.

    6. now again go to but dont login..just simply go to edit this cookie addon and click import a cookie and paste the code which we previously exported.

    7. after pasting just refresh the page and thats done you are now logged into your account without login details...

    problems faced

    the problems face if the vulnerability exits are

    1. anyone can easily hijack victims or users session and get into his account

    2. cookie stealing is the best way the hacker can get into and account..it would not take more than 5min to steal someones cookie using php n all...

    3. even friends can fool the victim and get him hacked..

    Solution

    Manage session properly.this problem is mainly faced because the session doesn't get expired or doesn't get closed when logout is pressed.each time the user logins the cookie must hold a unique different session id to proceed..

    facebook,google,any many more sites overtook this site....

Session fixation remote vector

A session fixation attack is a type of web security vulnerability that occurs when an attacker sets or "fixates" the session identifier (usually a session cookie) of a victim user to a known value. The attacker typically does this before the victim logs into a web application. Once the victim logs in, the attacker can use the known session identifier to hijack the victim's session.

The "remote" aspect in "session fixation remote vector" refers to the fact that the attacker can perform this attack from a different location or device than the victim. In other words, the attacker doesn't need to be physically present on the victim's computer or network to carry out the attack.

Here's how a session fixation attack with a remote vector works:

  1. Attacker's Preparation: The attacker visits the target web application and receives a session identifier (usually in the form of a session cookie) from the server.

  2. Session Identifier Fixation: Instead of using the received session identifier for their own session, the attacker sends or provides this session identifier to the victim, often through social engineering, phishing, or by tricking the victim into clicking on a malicious link.

  3. Victim's Interaction: The victim, unaware of the attack, logs into the web application using the session identifier provided by the attacker.

  4. Attacker's Access: Since the attacker knows the session identifier, they can now access the victim's session, effectively hijacking it. This allows the attacker to perform actions on behalf of the victim, potentially compromising their account.

When a victim uses a known Session ID in a request to a vulnerable application, the attacker can use this vulnerability to make their own requests using the same Session ID – acting as if they were the rightful owner of the Session. This attack differs from Session Hijacking in that the attacker already has the Session ID and forces it on the victim, as opposed to the attacker finding the token through another vulnerability.

To protect against session fixation attacks, web applications should implement strong session management practices, including:

  • Session Regeneration: Change the session identifier when a user logs in, ensuring that any previously known session identifier becomes invalid.

  • Timeouts: Implement session timeouts to automatically log users out after a period of inactivity.

  • Secure Session Storage: Ensure that session identifiers are stored securely and are not exposed in URLs or easily accessible to attackers.

  • Random Session Identifiers: Use long and random session identifiers that are difficult for attackers to guess.

  • Secure Transmission: Ensure that session identifiers are transmitted securely over HTTPS to prevent eavesdropping.

  • Session IDs are not accepted as arguments in GET or POST requests.

  • Allow users to log out and expire previous sessions.

  • After logging in, update the Session ID.

There are several techniques to execute the attack; it depends on how the Web application deals with session tokens. Below are some of the most common techniques: • Session token in the URL argument: The Session ID is sent to the victim in a hyperlink and the victim accesses the site through the malicious URL. • Session token in a hidden form field: In this method, the victim must be tricked to authenticate in the target Web Server, using a login form developed for the attacker. The form could be hosted in the evil web server or directly in html formatted e-mail. • Session ID in a cookie

Resources

  • https://owasp.org/www-community/attacks/Session_fixation

  • https://zofixer.com/what-is-session-fixation-remote-attack-vector-vulnerability/#:~:text=Session%20Fixation%20is%20a%20sort,a%20previously%20known%20Session%20ID.

  • https://www.geeksforgeeks.org/session-fixation-attack/

  • https://hackerone.com/reports/806577

🕸️
https://www.reddapi.com/
https://www.reddapi.com/
https://www.reddapi.com/