I recently ran a Nessus scan on my network, and one of the issues that it revealed is a possible avenue for cookie injection (session fixation) through Javascript. The related Nessus issue can be found here:


Is the only solution to update the Apache server package? Or is there some configuration option I can change? Because we are currently locked in to a specific distribution and version of our OS and cannot update to a newer version of Apache.

I should add that I don't have very much experience dealing with security, and I was just tasked with patching issues found in the Nessus scan.

  • You can start by confirming that its not a false positive since "Nessus did not check if the session fixation attack is feasible." ! Commented Feb 4, 2020 at 16:29
  • @Soufiane_Tahiri How would I do that? Commented Feb 4, 2020 at 16:52
  • The easiest way is : 1 Authenticate yourself and keep note of the value of your session's cookie, 2 logout, 3 create by hand the session cookie and give it the previously noted value, if you're authenticated then you're probably vulnerable to session fixation . Commented Feb 5, 2020 at 10:00

2 Answers 2


While the official remediation recommendation from Nessus (as you like know) is to explore patching, it is likely a generic piece of advice. I would agree that there is merit in the suggestion by symcbean that the web server (Apache in your case) is potentially not the root cause, rather the code that it is serving.

There are some useful resources for identifying and employing counter measures against session fixation. The solution may require involving the development team if it is indeed the code at fault.

Lastly, consider framing the vulnerability with the assignee from a risk management perspective. The vulnerability was given a base score of 4.8/10 (Medium) severity on the Common Vulnerability Scoring System (v2). There is more to risk than the CVSS score, and further exploration is required in verifying. However, for some organizations, this falls within their risk tolerance threshold meaning they will accept the risk. In other words, they are willing to accept its impact. If it is not palatable to have code modified or rewritten, or to update the distro in order to patch the server, accepting the risk may be one consideration.

  • I'm on the development team, but the web pages were written years ago and aren't actively maintained. I've never touched them. I don't know what severity is considered "acceptable" because I was just told to patch all issues that showed up in the scan. I have limited web experience from years ago, but I never learned much about web security. The biggest issue is that I have no idea which of our pages, if any, would be susceptible to this form of exploit. Commented Feb 5, 2020 at 12:08
  • If the legacy code can not be easily fixed (and thus the vulnerability can not be easily patched) then you should simply tell them that, and go from there. You can give recommendations as to how to proceed; determine their risk tolerance, and offer to explore how to identify vulnerable pages in order to determine the amount of cost vs. benefit, which will factor into their decision. They may decide they want it fixed anyways, and you may have to figure out how to fix the legacy code. At this point I don't think you'll really be able to tell without passing on your findings. Commented Feb 5, 2020 at 16:39

I am not aware of anything in Apache providing session management - session state is managed elsewhere, in PHP, PERL, python....of course, if I really tried I could leverage mod_usertrack or mod_session to create a very bad and insecure session implementation....but that would be rather dumb. The session has no value without application logic to read and populate the data / make choices about how to respond in the content - and that needs one of the components I have already aluded to - which provide better ways of handling sessions.

If you don't know what is going on inside the server, then you probably should be taking the time to find out before trying to change its behaviour.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .