In late 2022, a security vulnerability was identified in the popular Appalti & Contratti 9.12.2 application platform. Registered as CVE-2022-44788, this flaw exposes users to session fixation attacks due to improper handling of session cookies during authentication. This article breaks down what this exposure means, using clear examples, code snippets, and links to original advisories so you can stay informed and protected.

What is Session Fixation?

Session fixation is a web attack where an attacker tricks a user into authenticating with a session identifier (like a cookie) that the attacker already knows. If the application doesn't change (or “rotate”) the session ID after the user logs in, the attacker can use the fixed session ID to hijack the user’s account.

In short, the user logs in successfully, but keeps using the old session ID. This lets any attacker who knows that value before login step in and impersonate the victim.

The Vulnerability in Appalti & Contratti 9.12.2

Issue:
When a user visits the login page of Appalti & Contratti 9.12.2, the server issues a session cookie (like JSESSIONID). If the user logs in, that exact same session cookie is *not* updated or replaced upon authentication. This makes it possible for session fixation to occur.

Why is this bad?
Because an attacker could trick a user into logging in with a known session identifier, and then take over the user’s session post-login.

Walkthrough: Exploiting CVE-2022-44788

Let’s see how this would play out in a real-world attack scenario.

1. Attacker Prepares a Session

The attacker initiates a request to the application and receives a JSESSIONID from the server.

GET /login HTTP/1.1
Host: victim-app.example.com

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=ABC123DEF456

2. Attacker Sends Victim the Fixed Session

The attacker sends a phishing link or crafts a form that forces the victim’s browser to use the attacker’s session ID (e.g., via a URL like https://victim-app.example.com/login;jsessionid=ABC123DEF456).

3. Victim Logs In Using the Fixed Session

The victim visits the attacker’s link and logs in. Because of the vulnerability, the application does not issue a new JSESSIONID after successful login.

Since the session ID hasn’t changed, the attacker can now access the application as the victim

GET /dashboard HTTP/1.1
Host: victim-app.example.com
Cookie: JSESSIONID=ABC123DEF456

Example Code: Checking for This Vulnerability

If you have access to application code (like a Java web application), ensure a new session is created upon login by calling:

// In your login servlet/controller after successful authentication
request.getSession().invalidate(); // kill old session
request.getSession(true); // create new session, sends new JSESSIONID

If you fail to invalidate and create a new session after login, you’re vulnerable to session fixation.

Always change the session ID after successful login.

2. Check your authentication logic to ensure new sessions are created, and old ones are invalidated post-auth.

Sample code

// Java-based fix example
if (userAuthenticated) {
    HttpSession oldSession = request.getSession(false);
    if (oldSession != null) {
        oldSession.invalidate();
    }
    HttpSession newSession = request.getSession(true);
    // continue with authenticated session work
}

Original References

- NIST CVE Detail – CVE-2022-44788
- OWASP: Session Fixation Attack

Conclusion

While session fixation is a simple attack, it can have major consequences if unchecked. CVE-2022-44788 in Appalti & Contratti 9.12.2 demonstrates the importance of updating session IDs after login. If you run this platform, apply patches, and review your authentication flow now.

*Stay safe – don’t let attackers fixate on your sessions!*


Exclusive to this article: Detailed and simple breakdown for anyone wanting to understand CVE-2022-44788 without security jargon.

Timeline

Published on: 11/21/2022 23:15:00 UTC
Last modified on: 11/23/2022 16:03:00 UTC