Dlaczego nie widzimy wiele AJAX w bezpiecznych aplikacjach, takich jak bankowość internetowa?

Mam dla Ciebie kontrprzykład. Powiedziałbym mint.com pasuje do tej samej kategorii co witryny bankowości internetowej i intensywnie wykorzystują Ajax. Zaryzykowałbym również przypuszczenie, że ich bezpieczeństwo jest lepsze niż większość banków, ale nie mam na to dowodów. Banki po prostu "czują się" jakby były ułożone razem przez wysoko płatnych konsultantów, a nie deweloperów, którzy wiedzą, co robią. Mint to dość niedawny startup, a ich projekt witryny nadal pokazuje kontrolę deweloperów have/had.

Powiedziałbym, że największym powodem jest to, że banki wydają się być bardzo konserwatywne technologicznie / Ukryte. Nierzadko zdarza się znaleźć witrynę bankową, która zaleca lub nawet wymaga użycia IE6.

Istnieje kilka możliwych przyczyn i kilka możliwych wyjaśnień (niektóre dobre, niektóre złe). Różni się od banku do banku i od programisty do programisty, dlaczego używają systemów, których używają. Mój bank ma system bankowości internetowej oparty na technologii flash od roku, który z wszystkimi lukami w zabezpieczeniach pojawiającymi się we Flashu bardzo mnie zdenerwował.

Niektóre rzeczy do wzięcia pod uwagę:

• Większość banków jest bardzo stara. Są tu od początku. XX wieku, a niektóre jeszcze wcześniej. Rzadko można znaleźć bank, który założył się 5 lat temu. Banki te zaczynały od systemów pióra i papieru, więc powoli wkraczają w erę cyfrową. Jest to w przeciwieństwie do firm, które mają swój początek w Internecie, takich jak Facebook.

• Pracując w banku, chcesz zatrudnić "najlepszych i najzdolniejszych" programistów, aby Twój system był wydajny i bezpieczny. Problem w tym, że ludzie, którzy są właścicielami banków zazwyczaj nie znają różnych między MSWord i WordPad. Z tego powodu stanowiska programistów oprogramowania bankowego są zwykle oferowane kandydatowi z "największym doświadczeniem biznesowym". Albo, w prawdziwym świecie, najstarszy. Spójrz prawdzie w oczy - z wiekiem przestajesz nadążać za nowoczesnymi trendami, takimi jak AJAX. Nie zdziwiłbym się, gdyby połowa zaplecza banku była zakodowana w Javie

• Banki chcą, aby wszystko było proste, aby "to po prostu działało". Dlaczego uważasz, że moc gaśnie podczas burz, ale woda w zlew zawsze działa? Najprostsze systemy są najmniej prawdopodobne, aby zawieść. Jeśli zwiększysz złożoność, zwiększysz liczbę rzeczy, które mogą pójść źle. Nawet jeśli jest to sprawdzony system, który nigdy wcześniej nie zawiódł, to dodatkowe szczegóły i to dodatkowe zmartwienie.

• Chociaż mój bank naprawdę nie może nic powiedzieć (ponieważ niektóre komputery nie mają flasha, a niektóre iDevices nawet na to nie pozwalają), wiele banków może powiedzieć nie wymaganemu javascript po prostu dlatego, że nie wszystkie przeglądarki go obsługują lub można go wyłączyć. Jeśli Pani Piggsworth, 80-letnia bibliotekarka z ulicy, chce uzyskać dostęp do swojego konta bankowego z Pentium I z 1992 roku, na pewno nie będzie tego robić na niczym nowszym niż Internet Explorer 3

Poza tym, nie jestem pewien, czy AJAX i SSL grają ładnie. Chciałbym się temu przyjrzeć.

Jeśli chodzi o szybkość/wydajność, przekonasz się, że jeśli zaczniesz go używać, AJAX jest szybszy. Ładujesz Tylko niezbędne dane, a nie całe stron internetowych i można przełączać się między ramkami bez konieczności wysyłania żądań HTTP. Może również uczynić bardziej intuicyjny interfejs, gdy włączysz funkcję klikania/przeciągania i sortowalne listy. Problem polega głównie na zwiększonej złożoności i strachu, który powinien przynieść każdemu systemowi. Im więcej elementów masz, tym więcej elementów, które mogą pójść źle.

Istnieje kilka podmiotów, które są zawsze o 10 lat w tyle w technologii: banki, firmy ubezpieczeniowe i rządy. Aby uzyskać dowód, sprawdź listę klientów dla firm, które nie robią nic poza "modernizacją"(czyli konwersją firm ze starych systemów COBOL do Java/. NET itp.), takich jak Ten .

Są dobre powody:

Zmiany są trudniejsze w tych instytucjach, głównie ze względu na projekt (szybka zmiana = > błędy = > duże problemy)]}
1. kontrola jakości jest często znacznie bardziej zaangażowany, ponieważ spieprzenie nawet błędu zaokrąglenia może powodować ogromne problemy.
2. o ile nie maoczywistej zachęty pieniężnej, status quo jest zwykle "akceptowalne" na tyle, aby nie uzasadniać bałaganu.

...i są złe powody:

1. są to zazwyczaj duże instytucje z dużymi warstwami aprobaty i biurokracji
2. mniej ludzi faktycznie dba

Ponieważ jedynym problemem z javascript jest to, że nie ma zabezpieczeń.

Wyobraź sobie, że załadowałem formularz przelewu środków do przeglądarki. Daję mu kilka wpisów i Javascript jest tak wielki, że oblicza sumę dla mnie, zanim wyślę go z powrotem.

Ze względu na to, że Javascript jest językiem skryptowym, i może być edytowany i zwracany na serwer z / bez wiedzy użytkownika( lub cross site issues), wtedy nie ma zaufania do informacji powracających.

When you want fancy widgety i 'rzeczy', teraz potencjalnie serializujesz obiekty i używasz Eval (), aby cokolwiek zrobić(patrzę na Ciebie GWT).

Javascript ma ładny kontekst bezpieczeństwa i zabezpieczenia dla przeglądarki, ale pozostawia Dane i potencjalnie serwer bardzo podatny.