Why do we not see much AJAX in secure applications like internet banking?_问答_开发者

Can someone list with references / evidences if possible, why we 开发者_高级运维don't see much AJAX in secure web applications like internet banking?

For instance - Internet banking has a list of tabs for Accounts, Payments, Tools, Reports. Normally you'd see these implemented as links to different pages. Why couldn't you just have one page and use AJAX to load the content of the different tabs? (eg. a JSF RichFaces tab control)

I'm assuming that bookmarking and handling the back button (or disabling it as is common for internet banking) for the different URLS will be handled in either scenario. So I'd like to hear other things, like how it could affect security, performance etc?

My team is about to start building a web based payment management system (think setting up payments, managing client account balances, reconciliation etc.). Its not going to be making the actual payments, but it will at some point integrate with a leading bank's internet banking system.

We're divided over using one page and using AJAX for everything else

using AJAX only where its really helping user experience.

Ajax can improve usability but adds complexity.

http://www.useit.com/alertbox/web-2.html

Banks need security.

http://www.which.co.uk/money/bank-accounts/reviews-ns/online-banking-security/compare-online-banking-security/

Complexity is the enemy of security.

https://www.schneier.com/blog/archives/2018/06/thomas_dullien_.html
http://www.educause.edu/Resources/SecurityStandardsComplexityIst/162968
http://portal.acm.org/citation.cfm?id=1218063.1217951

Therefore Ajax is the enemy of Banks ;)

I have a counterexample for you. I'd say mint.com fits into the same category as internet banking sites, and they make heavy use of Ajax. I'd also hazard a guess that their security is better than most banks, but I have no proof of that. The banks just "feel" like they're cobbled together by Highly Paid Consultants, rather than developers who know what they're doing. Mint is a fairly recent startup, and their site design still shows the control the developers have/had.

I'd say the biggest reason is that banks tend to be very technologically conservative/hidebound. It's not uncommon to find a banking site that recommends or even requires using IE6.

There are several possible reasons and several possible explanations (some good, some bad). It differs from bank to bank and from programmer to programmer why they use the systems they use. My bank actually has a flash-based online banking system as of a year ago, which with all of the security vulnerabilities turning up in Flash has had me really edgy.

Some things to take into consideration:

Most banks are very old. They've been around since the early 1900's, and some even earlier. It's rare to find a bank who just started up 5 years ago. These banks started out with pen and paper systems and so they are slowly inching into the digital age. This is in stark contrast to businesses who got their start on the internet like Facebook.
When you work at a bank, you want to hire the "best and brightest" programmers to keep your system efficient and secure. The problem is- the people who own banks usually don't know the different between MSWord and WordPad. For this reason, positions as programmers for banking software are usually offered to the candidate with the "most business experience". Or, in real world terms, the oldest. Face the facts- as you get older you stop keeping up wit modern trends like AJAX. I wouldn't be surprised if half of the bank's back-end was coded in Java
Banks want to keep things simple so that "it just works". Why do you think power goes out during storms but the water in the sink always works? The simplest systems are least likely to fail. If you increase the complexity, you increase the number of things that can go wrong. Even if it's a proven system that has never failed before, it's extra details and that's extra worry.
Although my bank really can't say anything here (since some computers don't have Flash and certain iDevices won't even allow it), many banks may say no to required javascript simply because not all browsers support it or it's possible to disable it. If Mrs. Piggsworth the 80-year-old librarian down the street wants to access her bank account from her 1992 Pentium I, she certainly won't be doing it on anything newer than Internet Explorer 3

Also, I'm not sure off-hand if AJAX and SSL play nicely. I'd like to look into that.

As far as speed/efficiency goes, you'll actually find if you started using it that AJAX is faster. You only load the necessary data rather than entire webpages and you can switch between frames without having to make HTTP requests. It can also make more a more intuitive interface when you incorporate click/drag functionality and sortable lists. The problem lies mainly with the increased complexity and the fear which that should bring to any system. The more pieces you have, the more pieces which can go wrong.

There are a few entities that are always about 10 years behind in technology: banks, insurance companies, and governments. For proof, check out the customer list for companies that do nothing but "modernization" (that is, converting companies from old COBOL systems to Java/.NET, etc), such as this one.

There are good reasons:

Change is harder in these institutions, mostly by design (fast change => errors => big problems)
Quality control is often much more involved, since screwing up even a rounding error can cause huge problems.
Unless there's an obvious monetary incentive, the status quo is usually "acceptable" enough to not warrant messing with.

...and there are bad reasons:

These are typically large institutions with large layers of approval and red tape
Fewer people actually care

Because the only problem with javascript is it has no security.

Picture this, I have loaded the funds transfer form into my browser. I give it some entries and the Javascript is so great it computes the total for me before I send it back.

Due to Javascript being a scripting language, and can be edited and returned to the server with/without user knowledge (or cross site issues), then there is zero trust of the information coming back.

When you want fancy widgets and 'stuff', now you are potentially serializing objects and using Eval() to get anything done (I am looking at you GWT).

Javascript has a nice security context and containment for the browser, but leaves the data and potentially the server very vulnerable.