<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>CWE-384 on ZAP</title>
    <link>/alerttags/cwe-384/</link>
    <description>Recent content in CWE-384 on ZAP</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <atom:link href="/alerttags/cwe-384/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Exposed Session ID</title>
      <link>/docs/alerts/40013-5/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/docs/alerts/40013-5/</guid>
      <description>&lt;p&gt;A session id is exposed in the URL. By sharing such a website URL (containing the session id), a naive user may be inadvertently granting access to their data, compromising its confidentiality, integrity, and availability. URLs containing the session identifier also appear in web browser bookmarks, web server log files, and proxy server log files.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Session Fixation</title>
      <link>/docs/alerts/40013-4/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/docs/alerts/40013-4/</guid>
      <description>&lt;p&gt;Session Fixation may be possible. If this issue occurs with a login URL (where the user authenticates themselves to the application), then the URL may be given by an attacker, along with a fixed session id, to a victim, in order to later assume the identity of the victim using the given session id. If the issue occurs with a non-login page, the URL and fixed session id may only be used by an attacker to track an unauthenticated user&amp;rsquo;s actions. If the vulnerability occurs on a cookie field or a form field (POST parameter) rather than on a URL (GET) parameter, then some other vulnerability may also be required in order to set the cookie field on the victim&amp;rsquo;s browser, to allow the vulnerability to be exploited.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Session Fixation</title>
      <link>/docs/alerts/40013-6/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/docs/alerts/40013-6/</guid>
      <description>&lt;p&gt;Session Fixation may be possible. If this issue occurs with a login URL (where the user authenticates themselves to the application), then the URL may be given by an attacker, along with a fixed session id, to a victim, in order to later assume the identity of the victim using the given session id. If the issue occurs with a non-login page, the URL and fixed session id may only be used by an attacker to track an unauthenticated user&amp;rsquo;s actions. If the vulnerability occurs on a cookie field or a form field (POST parameter) rather than on a URL (GET) parameter, then some other vulnerability may also be required in order to set the cookie field on the victim&amp;rsquo;s browser, to allow the vulnerability to be exploited.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Session ID Cookie Accessible to JavaScript</title>
      <link>/docs/alerts/40013-2/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/docs/alerts/40013-2/</guid>
      <description>&lt;p&gt;A Session Id cookie sent by the server (when the URL is modified by setting the named parameter field to NULL) may be accessed by JavaScript on the client. In conjunction with another vulnerability, this may allow the session to be hijacked.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Session ID Expiry Time/Max-Age is Excessive</title>
      <link>/docs/alerts/40013-3/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/docs/alerts/40013-3/</guid>
      <description>&lt;p&gt;A Session Id cookie sent by the server (when the URL is modified by setting the named parameter field to NULL) is set to be valid for an excessive period of time. This may be exploitable by an attacker if the user forgets to log out, if the logout functionality does not correctly destroy the session, or if the session id is compromised by some other means.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Session ID Transmitted Insecurely</title>
      <link>/docs/alerts/40013-1/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/docs/alerts/40013-1/</guid>
      <description>&lt;p&gt;A session id may be sent via an insecure mechanism. In the case of a cookie sent in the request, this occurs when HTTP, rather than HTTPS, is used. In the case of a cookie sent by the server in response (when the URL is modified by setting the named parameter field to NULL), the &amp;lsquo;secure&amp;rsquo; flag is not set, allowing the cookie to be sent later via HTTP rather than via HTTPS. This may allow a passive eavesdropper on the network path to gain full access to the victim&amp;rsquo;s session.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
