I just found that a website of one Polish bank forces the users to open it in one browser tab only. You cannot for example check your transfer history while looking for an account number that you want to send money to. I cannot think of any good reasons for doing this except possible security reasons. Are there security advantages to limiting a site to only one site? If so, what are they?
Generally, no, it's not reasonable to force users to a single tab. There are no technical security reasons for making a website available to a single tab only. This is generally common just due to poor system design.
Forcing a single tab also means that when you log out, you won't leave your sensitive information plastered in twenty other tabs. This is poor reason though, as a site that is bothered about this can use localStorage or websocket to simultaneously clear all tabs when logging out from one tab.
The human factor of security is a marginal reason why some sites might deliberately restrict itself to a single tab. By forcing a single tab, you force people to focus on one thing at a time, and this makes you less likely to forget something. IMO, this is a poor reason, as the drawbacks outweighs the advantages.
This limitation is not caused by security measures, but simply by economical measures.
This behavior you observe can actually be found in a lot of internal corporate web applications, and you will find it linked a lot to Java J2EE Web Application Server (IBM WebSphere Application Server being the most widespread).
While relying on a light client (a general purpose web browser), such applications are often (poorly) designed the very same way a the ones which use a heavy client (software running from an executable file installed on your machine).
Websites are usually designed with a request - response model in mind. The designer decides which requests are allowed to the user and what the appropriate server's processing and answer should be. This conveniently allows you to open as many tabs as you like since each time your browser is just sending a request to the server.
But web applications as the one you are facing is designed with a state transition model in mind.
With a heavy client software, you are constrained to a very precise work-flow: when you click on an item you will be proposed some options and you will be forced to either choose one of them or click the Cancel button if it is available, you may not be able to open directly some window without passing through some other windows or menus first, some options may not be always accessible or enabled depending on your currently ongoing action, etc.
At any moment you are in some definite state, and depending on your action with the application controls you will switch from your current state to another one, and so on. Each possible state transition is well defined by the application designer.
Such web application just take this development model initially designed for heavy client applications, and apply it to web applications. Obviously this does not scale well since, by opening several tabs, you are confusing the application which is not able to determine what your current state is: are you consulting your account balance or entering a new bank transfer? Both is not acceptable, you can only be in one state at the time! And I do not even mention browser's specific features like the back button or bookmarking a specific page which are often not supported by such web applications.
This is not a security choice, just an economical one since it makes application programming easier, quicker, and thus cheaper.
Having worked with 8 banks that implemented this in one way or another I am convinced it is an important security feature. It being a tab is irrelevant, but restricting to one instance is very helpful at reducing many routes of attack.
If you allow more than one instance, then attackers can potentially attack from another machine during a valid session. If you only allow one, then most variants of this are removed.
The general way those banks implemented it was to check tokens/cookies and close off any sessions that exist as soon as a new session is negotiated, not carrying whether this was a new tab, browser or whatever.
There's a Swedish bank doing this. They pass a single use token on each request, so that no request can be done twice. This means that if someone manages to steal your session cookie, they cannot use it without anyone noticing.
It's a small addition in security (that might even be no addition these days, since SSL/TLS has gotten better) for a fairly big hit in user experience.
Other banks, such as Klarna, uses a single click payment solution for a huge boost in user experience, but with a much harder job of securing it.
Ultimately, the bank is responsible for doing this tradeoff, and limiting the user to a single tab might help somewhat, such as lowering the risk of leaking sensitive data if a user forgets to close all the tabs.
If it is a stateful app opening seperate tabs confuses the user because the data shown in one tab won't include any actions carried out since in another tab.
This isn't a security issue but a design choice common in web applications because it allows more complex operations without the added work to make it stateless.
Yes, although preventing the application from working in different tabs in incidental.
There's a class of web application vulnerabilities called "business logic flaws". These are particularly prevalent when there's a multi-step process to be followed. By giving a user a token, which is passed page to page, and is changed at each step ensures that users follow multi-step processes in the set order. This mitigates the risk of a developer assuming that because a certain page has been reached that all previous steps have been legitimately followed.
Because the token is passed from page to page in GET or POST parameters, opening another page in another tab causes the token to be changed, and therefore the token in the original tab will no longer be valid for navigation.
This method of passing a token around that can be validated in the session server-side also inherently protects against CSRF. Protecting the whole site using this method also ensures that nothing is missed because for each request the token validation is never skipped. This can also protect against a user double clicking e.g. a transfer money button, because the token will be only valid for the first request and will ensure any such actions are not accidentally submitted twice.
It does help. You might like to look at douglas crockford's suggestion of a safer internet through the use of a separate QT based rendering engine. It has some merits.
The merits are: the dom and sandbox nature of a webbrowser is abrogated by the use of a separate rendering engine for each page ( assuming i read that correctly ), and so there is no dom or sandbox with which to break out of, in the case of cookie theft, which can happen with multiple tabs.
Oh here is a link: http://www.infoq.com/news/2015/07/douglas-crockford-new-web-upgrad