In a web-application the session time-out is not defined neither in the application nor in the application configuration. But the default time out is taken from the IIS. what is the security issue if the session time-out is default IIS server session value? Does issue vary from IIS to web sphere?
2
-
1i don't see any generic issue, but certain apps might benefit from longer or shorter timeouts.– dandavisCommented Jan 19, 2017 at 18:54
-
To note, your security tool is not telling you that there is an issue, just that it's something you should look at. If you've looked at it and the default value is fine, then it's fine.– Xiong ChiamiovCommented Jan 19, 2017 at 19:03
Add a comment
|
2 Answers
A pen test might interpret the presence of default timeout settings as an indication that you forget to set it.
Timeout should be set in a manner that is specific to the application. For example, if you handle credit cards, PCI-DSS requires a 15-minute idle timeout.
-
In the static analysis the issue is found. I believe it is the wrong way to take the default web server session time-out value. My question specifically is, What are the security issues/consequences if the session time-out is not defined application specific or in the application. Commented Jan 19, 2017 at 18:11
-
2
-
The link provided does not say any security issue about session time-out value taking from web-servers session time-out default value. Commented Jan 19, 2017 at 20:00
-
I stated the consequences: the timeout may be wrong. The link specifies the consequences of a wrong timeout. You may infer the aggregate consequences using the transitive property.– John WuCommented Jan 19, 2017 at 20:03
what is the security issue if the session time-out is default IIS server session value?
Say on a high security system, such as a bank, you might want to automatically log the user out if they leave their session open.
E.g. Bob leaves his computer logged into bank.example.com while he answers the door. It's his friend Alan so they go into the kitchen to make drinks and forgets he is logged in.
Bob's son, Chuck comes up to the laptop and can transfer himself a little extra pocket money.
Same applies to other environments, such as offices, although it could be argued that employees should lock their screens when leaving their desk.
My point is that it all depends on the risk appetite of your application. Many sites these days, such as Facebook and Google appear to leave you logged in for a long period. This does leave your system exposed to session compromises such as CSRF and XSS should such vulnerabilities exist on your system. That is, the attacker has a large window in which to execute their attack. Definitely for CSRF, although for XSS it depends on whether the instance of the attack works for a newly established session.
Large session timeouts can also cause additional server load, unless this is accounted for in the architecture (e.g. storing sessions in an external DB instead of within server memory).
Small timeouts may annoy your users and cause them to change their password to something very easy to type, although again they should be using password managers for their logins.
So in summary it depends on your application, how sensitive it is, its usage environments and your type of users.
answered Jan 21, 2017 at 16:41
