Skip to content

Latest commit

 

History

21 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Session Replay Attack

Session replay is a security attack where an attacker captures valid authentication data, session tokens, or previously transmitted requests and re-transmits them later to impersonate a legitimate user or repeat authorized actions.

Session replay attacks are closely related to session hijacking. While session hijacking focuses on taking control of an active user session, session replay specifically involves the reuse of previously captured valid session information.

How Session Replay Works

  1. Capture Session Data: The attacker acquires valid session information.
  2. Analyze Captured Data: The attacker examines the captured information.
  3. Replay the Captured Session: The attacker sends the captured session data or request back to the application. If the token is still valid and the application does not detect any replay attempts, the server may accept the request as legitimate.
  4. Perform Unauthorized Actions: The attacker may perform various unauthorized actions

Session Replay Mitigation

To prevent Replay Mitigation attacks:

  • Use HTTPS/TLS : Encrypt all communication between clients and servers to prevent attackers from intercepting session tokens.
  • Secure Session Cookies:
    • Set-Cookie: sessionid=random_value; Secure; HttpOnly; SameSite=Lax
    • Secure ensures cookies are transmitted only over HTTPS.
    • HttpOnly prevents JavaScript from accessing cookies directly.
    • SameSite helps reduce cross-site request attacks, such as CSRF.
  • Implement Strong Session Management
    • Cryptographically secure session identifiers
    • Session expiration
    • Idle timeouts
    • Session invalidation after logout
    • Token rotation after authentication
  • Prevent Token Replay:
    • Using short-lived tokens
    • Including timestamps or expiration values
    • Employing unique request identifiers (nonces)
    • Rejecting duplicate requests
  • Require Strong Authentication (While MFA helps reduce account compromise, it does not prevent the replay of already stolen valid session tokens)
    • Multi-factor authentication (MFA)
    • Device verification
    • Risk-based authentication
  • Monitor Session Activity
    • Multiple locations using the same session
    • Unusual device changes
    • Impossible travel patterns
    • Repeated identical requests

Session Replay Example

Clone this current repo recursively

git clone --recurse-submodules https://github.com/qeeqbox/session-replay

Run the webapp using Python

python3 session-replay/vulnerable-web-app/webapp.py

Open the webapp in your browser 127.0.0.1:5142

Use the default credentials (username: admin and password: admin) to login

Open the Storage tab in the developer tools to examine the request cookies

Open the private tab (or change the browser profile), type the webapp address in your browser 127.0.0.1:5142, then, open the Storage tab in the developer tools and add the cookies there

Referch the page, you will by logged as admin using the cookies

Code

The application generates cookies insecurely using the gen_cookie() function. The cookies do not validate the request's origin and store values unencrypted.

    def gen_cookie(self, row, max_age):
        cookies = SimpleCookie(self.headers.get('Cookie'))
        if 'session_id' in cookies:
            session_id = cookies['session_id'].value
        else:
            session_id = "".join(str(randint(1, 9)) for _ in range(5))
        #end_time = datetime.now() + timedelta(days=1)
        SESSIONS[session_id] = {"username":row[1], "department": row[3],"access":row[4], "is_admin":row[5]}
        cookie1 = SimpleCookie()
        cookie1['session_id'] = session_id
        cookie1['session_id']['path'] = '/'
        cookie1['session_id']['max-age'] = max_age
        cookie2 = SimpleCookie()
        cookie2['is_admin'] = row[5]
        cookie2['is_admin']['path'] = '/'
        cookie2['is_admin']['max-age'] = max_age
        cookie3 = SimpleCookie()
        cookie3['access'] = row[4]
        cookie3['access']['path'] = '/'
        cookie3['access']['max-age'] = max_age
        cookie4 = SimpleCookie()
        cookie4['department'] = row[3]
        cookie4['department']['path'] = '/'
        cookie4['department']['max-age'] = max_age
        cookies = [('Set-Cookie', cookie1.output(header='', sep='')),('Set-Cookie', cookie2.output(header='', sep='')),('Set-Cookie', cookie3.output(header='', sep='')),('Set-Cookie', cookie4.output(header='', sep=''))]
        return cookies

Functions like admin_only() that handle generated cookies do not validate their origins, which means they may accept potentially unauthorized or tampered cookies.

    def admin_only(f):
        @wraps(f)
        def wrapper(self, *args, **kws):
            cookies = SimpleCookie(self.headers.get('Cookie'))
            if "is_admin" in cookies:
                if cookies['is_admin'].value == "1":
                    return f(self, *args, **kws)
            return b"Admin Privileges Needed"
        return wrapper

About

A threat actor may re-use a stolen or leaked session identifier to access the user's account

Topics

Resources

Code of conduct

Contributing

Stars

2 stars

Watchers

0 watching

Forks

Sponsor this project

Contributors