AJAX - brzytwa w rekach malpy?

"OK, let’s return to web application security 101. Web applications must NEVER trust the client (web browser). This is gospel whether the web page interfaces use JavaScript, Flash, ActiveX, Applets, AJAX or any other protocol or language. Every developer should be aware that basic HTTP proxies may alter anything about the HTTP request, even those generated by XHR. Great care should be taken to ensure that all security checks are performed on the server--no exceptions." - cytat ze świetnej pracy na temat rzekomego niebezpieczeństwa stosowania technologii AJAX, który znajduje się na ższych stronach . Nigdy nie ufaj klientowi - to stara zasada i odnosi nie nie tylko do klasycznego rozwiązania (przeglądarki internetowej), ale również i do innych form np. widgetów z Opery czy Yahoo.

Każda przeglądarka ma wbudowany mechanizm wspierający XMLHTTPRequest (XHR). Istotą aplikacji typu Web 2.0 jest pobieranie danych z różnych trzecich serwerów w ten sposób doprowadzając do słynnego "mesh-up" czyli misz-masz. Stwarza to określone zagrożenie dla odbiorcy aplikacji. Na szczęście XHR technologia nie zezwala bezpośrednio na tego rodzaju sztuczki. "XHR has security protections built-in, preventing a user’s browser on Website A from making connections to Website B." Ale są różne obejścia tego ograniczenia. Rozwiązanie polega na stworzenie serwera pośrednika w domenie internetowej tzw. proxy (najczęściej na serwerze internetowym witryny). Odwołanie do witryny B ma przez serwer proxy taka postać http://websiteA/proxy?url=http://websitesB/ - w ten sposób proxy przekazuje żądanie z witryny A do witryny B. Wten sposób można ominąć ograniczenia XHR i apliakcja nie przesyła cookies. Ale w ten sposób witryna A gości odwołania do witryny B. Bezpieczeństwo polega na monitorowaniu do jakich to URL chcą się odwołać strony witryny B. A więc na kontroli i samocenzurze. Odnośnie Cross-Site-Scripting (XSS) to rzeczywiście AJAX na to zezwala, ale stosując wyłącznie JavaScript możemy "osiagnąć" taki sam efekt bez uciekania się do nadmiernej komplikacji w AJAX. Autor (Jeremiah Grossman) zademonstrował to w słynnej prezentacji “Hacking Intranet Websites from the Outside” at BlackHat 2006. Z kolei inna prezentacja pt. “Cross-Site Scripting Worms and Viruses" pokazuje jak możne to osiagnąć poprzez JS.

Zasady bezpiecznej aplikacji internetowej to KROK 1 polegający na:

1. uwzględnienie aspektów bezpieczeństwa juz na etapie projektowania aplikacji
2. dogłębne sprawdzania danych podanych przez użytkownika
3. stosowanie tylko sprawdzonych bibliotek komponentów (dostępnych w branży), obojętne na jakiej licencji (closed lub open source), nie wymyslać na nowo koła (i powtarzać błędy innych) szczególnie przy kryptografii i zarządzaniu sesją.
4. bezpieczna koniguracja (separacja usług, zasada najmniejszych przywilejów, wyłączenie usług zbędnych oraz komunikatów o błędach)
5. Stałe poszukiwanie i naprawianie ewentualnych usterek. Stały pomiar i ocena podatności na atak (vulnerability assessment)

KROK 2 polega na nieustajacym monitorowaniu i walidacji rozwiązań.