58

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?

16
  • 2
    What if you create a second session in a new window, not tab?
    – user6090
    Commented Dec 28, 2015 at 14:53
  • 5
    @StackzOfZtuff: There is usaully a state ID (can be called page, screen, action, etc.) telling your current state in the web application work flow (and very often a single URL where the content is dynamically handled by an overdose of Ajax scripting). If you click on an option or submit a form not corresponding to your current state, such application may produce a bogus result, show an error page or send you right back to the home page. Commented Dec 28, 2015 at 18:20
  • 22
    The online grading/enrollment system at my university does the same thing, and it's super-annoying. I don't think it's done for any security reason so much as it is because the system is horribly designed. (The back button doesn't work either, among other things.)
    – Ajedi32
    Commented Dec 28, 2015 at 20:44
  • 3
    This reminds me of a utility company whose website prevents copy/paste. I suppose what they wanted was to discourage people from keeping their information in a notepad document on the desktop, but mostly it just caused me frustration in trying to use my password manager. Commented Dec 29, 2015 at 17:19
  • 18
    It vastly improves security by driving customers to other banks whose web design isn't brain damaged. Commented Dec 30, 2015 at 1:53

7 Answers 7

78

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.

13
  • 6
    They may not be security related, but there are reasons why a webapp does this by design.
    – JamesRyan
    Commented Dec 28, 2015 at 18:17
  • 5
    As lie said, its basically a poor system design. In a user experience perspective, that's a worse if people are forced to do something that doesn't even really help (eg attain security).
    – Arun Anson
    Commented Dec 29, 2015 at 3:44
  • 5
    Can this "force single tab" feature be considered a security theater? Commented Dec 29, 2015 at 11:51
  • 4
    @Mindwin: if "force single tab" is presented to be for security reasons, then yes, IMO, it is a security theatre.
    – Lie Ryan
    Commented Dec 29, 2015 at 11:54
  • 2
    I'm not exactly well versed on this, but is there a chance this has been done to reduce Cross-Site Request Forgeries?
    – Ramrod
    Commented Dec 29, 2015 at 23:03
47

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.

5
  • 16
    I'd contest that this makes application programming easier, at least today. Perhaps it did in the past back when these systems were designed, but today there are countless modern frameworks available to assist with building well-designed RESTful web applications. In fact, I suspect trying to build an app using an anti pattern like that today would be harder than building a stateless one.
    – Ajedi32
    Commented Dec 28, 2015 at 20:53
  • 7
    Designing like this would only be cheaper if you are reusing the design from an existing state heavy client application. In almost any other web native designs, stateless client is easier to build, faster, and scales better.
    – Lie Ryan
    Commented Dec 28, 2015 at 23:30
  • 3
    @Ajedi32: J2EE webapps are a completely different world than traditional web development. It accumulate abstraction layers, you provide a Java class you link with a path and your application does not even have access to the HTTP request which is abstracted by the application server. I suppose all this may imply a different approach in development. However, where I fully agree with you is that, in my opinion, most of the time using such J2EE webapp is a purely management decision (possibly not the wisest one) and not a technical choice at all since it often brings more issues than solutions. Commented Dec 29, 2015 at 10:27
  • 1
    @LieRyan: My answer to Ajedi32 also applies. Such choice may only be conceived in a corporate infrastructure were you have to deal with the existing. If you are already sending large amounts of money to IBM to support your WebSphere platform where the backend connection is already functional and supported (JMS queues, SAP integration, etc.), you may prefer to reuse it to implement your new web interface instead of starting from scratch, even if this means using more heavy and unpractical technologies instead of more modern and user-friendly ones. Commented Dec 29, 2015 at 10:38
  • 1
    +1 It makes programming easier for coders of a certain mindset rather than in general. Java coders with a non-web, controlled-client background will happily stuff large amounts of state in the Session without realising that they're breaking the navigational/usability conveniences the ‘stateless’ web provides naturally. It's not more secure (in fact I've seen it cause security holes by introducing ToC/ToU issues) but it fits this mindset better. It's on the retreat in general due to greater familiarity with the web, but you still see it in enterprise hellholes like banks.
    – bobince
    Commented Dec 31, 2015 at 11:54
14

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.

1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Dec 31, 2015 at 10:50
5

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.

3

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.

1
  • 6
    I'd argue that stateful requires more work, since you have to track state. Now if you wanna say that someone might try to operate on stale data (e.g. double spend money), your program has to check such things anyway to prevent malice. Covering bad design with a blanket won't make it good. Commented Dec 28, 2015 at 21:19
0

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.

-3

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

6
  • 1
    A tab inside a browser still shares cookie storage, history etc with all the other tabs or windows in the browser which enables attacks like CSRF. It does not help to restrict the usage to a single tab, but instead you would need to use a different browser or at least a different browser profile. Commented Dec 28, 2015 at 15:48
  • 7
    What does restricting current browsers to a single tab have to do with revising how the web works? Commented Dec 28, 2015 at 17:29
  • @SteffenUllrich Actually, using a sensitive website on private tabs only does increase security and privacy, I only use a fake facebook account on a private window, this ensures isolation between facebook and everything else I do on "normal" tabs
    – Freedo
    Commented Dec 30, 2015 at 1:37
  • @Freedo: There is no private tab only private mode. This mode is similar to a different browser profile in that it does not share any cookies etc with the original profile. But these are still shared between different tabs inside the private mode. Apart from that the question was about restricting to a single tab (inside the normal browser mode) and not restricting to using the private mode. Commented Dec 30, 2015 at 6:34
  • Strange i've always thought the cookies would still be presented from private windows. Yes, i tried it out, and so private mode only does not store history on the client side.
    – m2kin2
    Commented Dec 30, 2015 at 17:15

You must log in to answer this question.

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