Insuring that an application does not maintain a valid state on initialization or shutdown failure.
-
I am working on a MVC application and I am starting to work on a STIG finding. This finding is "Insuring that an application does not maintain a valid state on initialization, shutdown failure.". Basically, what this requires is that if the MVC application failures on startup or shutdown it must not allow for a hacker to read valid application data or information during the failure. I have spent hours looking at how this is prevented in an ASP MVC application and can't find anything. Does anyone know how this is handled in MVC?
-
I am working on a MVC application and I am starting to work on a STIG finding. This finding is "Insuring that an application does not maintain a valid state on initialization, shutdown failure.". Basically, what this requires is that if the MVC application failures on startup or shutdown it must not allow for a hacker to read valid application data or information during the failure. I have spent hours looking at how this is prevented in an ASP MVC application and can't find anything. Does anyone know how this is handled in MVC?
After talking to a couple of people the idea of Application_Error and Authentication logic was discussed but would this really prevent the STIG from being displayed. A great link for Application_Error is below but is this the real solution? Has anyone had experience with this? https://msdn.microsoft.com/en-us/library/bb397417.aspx
-
I am working on a MVC application and I am starting to work on a STIG finding. This finding is "Insuring that an application does not maintain a valid state on initialization, shutdown failure.". Basically, what this requires is that if the MVC application failures on startup or shutdown it must not allow for a hacker to read valid application data or information during the failure. I have spent hours looking at how this is prevented in an ASP MVC application and can't find anything. Does anyone know how this is handled in MVC?
Assuming Rule SRG-APP-000225 from the Application Security and Development Security Technical Implementation Guide (which is really an SRG, silly cybersec people), the current version dated 27APR2018 has a lot of example detail in it. https://iasecontent.disa.mil/stigs/zip/U\_ASD\_V4R6\_STIG.zip The general idea is that it should not be left "half-open" on failure, so something like a no-op sled cannot push an instruction into the application and bypass authentication. If you are running a basic CRUD app, then IIS will handle this stuff for you, providing you dispose of database connections which you're supposed to do anyway if you're using EF in the Repository/Unit of Work pattern. By and large, in an MVC.NET application all you can really do is make sure that any operational statics are cleared (or reset as part of an application restart/correction process) and that un-managed resources are properly disposed as part of the failure. You can wrap all of this into a failure handler that can attempt to self-correct and, failing that, fail closed. This all said, if an auditor declared it a finding then they should have given you some sort of finding detail. If you need detailed support or code review, I'm in the GAL.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli