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

  1. Digging into this further, the Fortify diagnostic occurs when the code does the following:

    Storing a non-serializable object as an HttpSessionState attribute can damage application reliability.

    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?