This rule is a stub.
Noncompliant Code Example
This noncompliant code example shows an example where ...
Compliant Solution
In this compliant solution, ...
Risk Assessment
If nonserializable objects are stored as attributes in an HTTP session then ...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
MSC08-J | Low | Probable | High | P2 | L3 |
Automated Detection
TBD
Bibliography
[Fortify 2014] | Fortify Diagnostic |
HTTPSession J2EE Documentation [Note. This is a JavaEE 5 reference. I cannot find the corresponding API in Java 7.] |
1 Comment
David Svoboda
Digging into this further, the Fortify diagnostic occurs when the code does the following:
The catch is that
HttpSessionState
is not JavaEE. It is a specific class in Microsoft's ASP.NET.IOW code that triggers this checker is MS-specific, and not violating general JavaEE.
Still it sounds like a valid problem that we should diagnose. So what to do with this rule? Void it? Flesh it out in an ASP.NET-specific case?