REST, Web 2.0 i SOA

Chociaż architektura SOA była pierwotnie powiązana z SOAP, WSDL i UDDI, wielu programistów preferowało wykorzystanie usług REST, które są bliższe schematowi współdziałania przeglądarki z ośrodkiem webowym. Do popularności stosowania tej metody przyczyniło się pojawienie Web 2.0, a w szczególności przejście do Rich Internet Applications (RIA), wykorzystujących usługi REST do wyciągania danych z serwerów webowych do przeglądarek. Technologia ta, która w Web 2.0 umożliwia włączanie skryptów JavaScript po stronie przeglądarki, przeważnie wywołuje REST Web services po stronie serwera. Na przykład witryna Flickr zawiera skrypty Java, uruchamiane w przeglądarce w celu wywołania serwerowych Web services do zmiany nazwy zdjęcia. W AJAX (Asynchronous JavaScript and XML), JavaScript po stronie klienta wywołuje na serwerze Web services, w celu pobrania danych XML lub JSON. Odbywa się to asynchronicznie, bez wymagania, aby użytkownik przeszedł w przeglądarce na nową stronę.

W świecie Web 2.0 na zapleczu funkcjonują Web services, które stają się kluczowym celem ataku. Taki atak na Web 2.0 jest czasami określany jako “zmasowany", ponieważ napastnik może próbować atakować aplikacje poprzez jej interfejs klienta lub może obejść ten interfejs i bezpośrednio zmierzać do Web services zaplecza.

Do tego miejsca nie widać różnic między Web 2.0 a tradycyjną aplikacją webową. Rodzi się więc pytanie: czy trzeba zabezpieczać to inaczej? W Web 2.0 używane są przeglądarki i serwery webowe, a także zaangażowany jest użytkownik. Kiedy dane są przesyłane między przeglądarką a serwerem, sensowne jest skanowanie danych pod kątem symptomów zdradzających próby podjęcia ataku, takiego jak SQL Injection czy CSS (Cross-Site Scripting). Również, gdy w sieci używany jest XML, sensowne jest skanowanie pod kątem ataków, takich jak XML DoS lub XPath Injection. Ponadto nadal mają tu zastosowanie dobre praktyki programistyczne - wzbogacone aplikacje na przeglądarce wymagają większej odpowiedzialności za bezpieczne kodowanie. Atak CSS jest możliwy, jeżeli napastnik jest w stanie zamieszczać skrypty JavaScript w danych wysyłanych do przeglądarki do interpretacji. Odkąd wiele rozwiązań Web 2.0 zależy od JavaScript przemieszczanych do klienta, pojawia się możliwość przeniknięcia złośliwego skryptu do klienta, konieczne jest więc jego wykrywanie i blokowanie.

Częściowo bezpłatne Web services i ryzyko nadużyć

Web services, określane mianem “Freemium", obejmują podstawowe usługi oferowane bezpłatnie, podczas gdy sprzedawane są zaawansowane lub specjalne mechanizmy, zazwyczaj w cenie “premium". Określenie “freemium" stanowi zbitkę słowną, oddającą połączenie dwóch aspektów modelu biznesowego: bezpłatny i płatny ekstra.

Dopuszczenie niektórych usług SOA do funkcjonowania w modelu freemium wydaje się kuszące, jako że stwarza możliwość łatwego przejścia do komercyjnego modelu opłat. Jednak praktyka jest bardziej złożona. Model ten zakłada pewną strukturę bezpieczeństwa SOA, która ma wykrywać nadużycia i wymuszać płatności za użytkowanie usług premium. W takiej strukturze użytkowanie Web services musi być uwierzytelniane, aby nadużywanie usługi przez niektórych użytkowników mogło być wykrywane, a użytkownicy wzywani do wniesienia opłaty premium. Zazwyczaj osiąga się to przez wykorzystanie tzw. developer tokens. Takie tokeny są zagnieżdżane w wywołaniach Web services wysyłanych do oferowanej usługi. Użytkownik może korzystać bezpłatnie z usługi wyszukiwania do określonego punktu, ale nie może (potajemnie) wyszukiwać np. warunków do eksploracji danych - wtedy wymagana jest opłata premium.

Gdy wdraża się model freemium dla usług SOA, organizacja ma możliwość wyboru: napisanie specjalistycznego kodu programowego lub wykorzystanie produktów, takich jak XML Gateway. Jego zaletą jest to, że zapewnia wykonywanie zmian w parametrach modelu bez konieczności zmiany bieżącego kodu. XML Gateway skanuje także pod kątem wcześniej wymienionych ataków, takich jak “wstrzykiwanie" kodów złośliwych.