2013-04-05 14 views
10

Wiem, że to pytanie może być zbyt ogólne, ale w celu zawężenia pytania, oto krótki opis:Jakie są potencjalne zagrożenia podczas wywoływania usług WWW przy użyciu JQuery i jak ich uniknąć?

Mam zamiar zapomnieć o ASP.net UpdatePanel i przejść do korzystania z ajax przez JQuery. Obawiam się, że ze względu na prostą, opartą na kliencie naturę JavaScript (i w konsekwencji kod JQuery), każdy, kto szuka źródła mojej strony internetowej, może zdać sobie sprawę z tego, jaki jest adres URL usług internetowych, do których dzwonię, a także, co jest przekazywane do tych serwisów internetowych.

Podczas korzystania z dla tego typu operacji, jestem pewien, że wywoływanie usług sieciowych odbywa się po stronie serwera i nie mam żadnego problemu z informowaniem publicznie o problemach związanych z poufnymi usługami internetowymi, ale teraz, gdy jestem planuje używać Ajax przez JQuery, Martwi mnie to dużo.

Czy moje obawy są uzasadnione, a jeśli tak, to jakie są najlepsze rozwiązania w celu uniknięcia zagrożeń związanych z wywołaniem usługi przez Internet?

Wyjaśnienie: kiedy UpdatePanel mówiąc, to znaczy wykorzystując sieć techiques tym ASP.NET AJAX, kodu źródłowego oraz w oparciu o biblioteki DLL po stronie serwera do wykonywania operacji asynchronicznych po stronie serwera zamiast jQuery Ajax, który wymaga usług internetowych do intracting with server.

+0

Wyrażenie "wywoływanie usług sieciowych jest wykonywane po stronie serwera [z UpdatePanel]" wydaje się błędne, ponieważ UpdatePanel również włącza technologię po stronie klienta. Nie sądzę, że zagrożenia zmienią się po przejściu na jQuery. Twoje usługi internetowe nie powinny się zmieniać, jeśli są już bezpieczne. –

+0

Ważny fragment, który wymaga wyjaśnienia na temat twojego pytania, brzmi: "Jestem pewien, że wywoływanie usług sieciowych odbywa się po stronie serwera" - te * usługi internetowe *, czy są one automatycznie tworzone przez ASP.NET, czy są one * oddzielne * usługi internetowe specjalnie/osobno wywoływane od strony serwera? – Jesse

+0

Wyjaśnienie: mówiąc o UpdatePanel, mam na myśli wykorzystanie łańcucha technologii, w tym ASP.net AJAX, kodowanie i poleganie na serwerowych bibliotekach DLL do wykonywania asynchronicznych operacji po stronie serwera zamiast Ajaxu jQuery, który wymaga usług internetowych do intracting with server. – Farshid

Odpowiedz

6

Nie ma sposobu, aby w Internecie chronić swoje usługi internetowe przez cały czas, po prostu ukrywając adres URL. Nie jestem pewien, kiedy mówisz, że twój updatepanel wywołuje usługę sieciową z serwera, który nie bierze prawdziwej mocy AJAX.

Jednym ze sposobów zabezpieczenia swojej usługi sieciowej jest korzystanie z uwierzytelniania po stronie usługi sieciowej. Na przykład musisz wysłać klucz uwierzytelniający za każdym razem, gdy uzyskujesz dostęp do źródła, a to jest bardzo częste, masz tyle publicznych usług internetowych, które chronią go samodzielnie za pomocą klucza uwierzytelniającego, takiego jak implementacja OpenId. W przypadku, gdy nie chcesz zmienić logiki usługi internetowej, myślę, że sposób jQuery AJAX nie jest bezpieczną opcją.

Oto myśl, możesz mieć dwa poziomy usług internetowych, które będą dostępne dla wszystkich, których możesz użyć w jquery Z bieżącej usługi internetowej od strony serwera zadzwoń do innej bezpiecznej usługi WWW. Nawet teraz możesz skonfigurować swoje przychodzące żądanie dla określonego adresu IP urządzenia.

W tym przypadku inny niż własny serwer żadna instytucja nie może uzyskać dostępu do usługi internetowej bezpiecznie przechowywanej za zaporą. Jest to coś podobnego, co robimy podczas łączenia się z serwerem bazy danych z serwera aplikacji.

Daj mi znać, jeśli to pomoże.

5

Idę do wskazania problemów moja odpowiedź ma nadzieję rozwiązać:

  1. Zakładając udostępnić swoje usługi na maszynie inne niż serwer WWW, problem jest dać potencjalnemu napastnikowi nazwa/adres tych maszyn.

  2. Atakujący mogą pisać skrypty/boty, aby zeskrobać twoje dane.

  3. Atakujący mogą skupić się na twoich usługach internetowych i spróbować zhakować je/uzyskać dostęp do twojej sieci.

  4. Atakujący mogą próbować wykonać DoS/DDoS w swoich usługach internetowych.

Rozwiązaniem, z którego korzystałem w przeszłości, jest stworzenie serwera proxy o niskiej wadze, tak aby wszystkie połączenia AJAX wskazywały na bieżącą domenę. Następnie, gdy przychodzi połączenie, jest po prostu kierowane do odpowiedniej usługi internetowej, która jest hostowana wewnętrznie w sieci.

Tworzy jeden dodatkowy hop w sieci, ale ma również następujące korzyści:

  1. Ukrywa rzeczywiste IP komputera obsługującego swoje usługi.
  2. Możesz łatwo zablokować ten jeden serwer sieciowy i monitorować nietypową aktywność. Jeśli zauważysz skok aktywności, możesz potencjalnie zamknąć usługi WWW. (Jeśli korzystasz z innego komputera, będziesz musiał monitorować dwa pola. Nie jest to duży problem, ale łatwiejsze monitorowanie tylko jednego.)
  3. Możesz łatwo umieścić rozproszoną warstwę buforowania w proxy. Chroni to przed atakami typu load/denial of service (DoS) i oczywiście obsługuje zwykły ruch sieciowy.
  4. Możesz ukryć uwierzytelnianie na poziomie proxy. Publiczne połączenia nie zdradzą twojego schematu uwierzytelnienia. W przeciwnym razie osoba atakująca może zobaczyć, jakie tokeny, klucze, sekrety lub cokolwiek innego używasz. Wykonanie serwera proxy na serwerze sieciowym ukrywa te informacje. Dane będą nadal przepływać, ale znowu możesz je monitorować.

Prawdziwa korzyść, moim zdaniem, polega na zmniejszeniu powierzchni aplikacji, która zawęża to, co atakujący może zrobić.

2

Ponieważ odwołujesz się do ASP.Net, wiesz, że jego stan wyświetlania można łatwo odszyfrować. Nie ma odpornych na awarie sposobów ochrony kodu (nie mówiąc o wywołaniu adresów URL). Jeśli używasz usług internetowych z niektórymi parametrami, które mogą pozwolić na nieograniczone i niebezpieczne działania, lepiej zacznij korzystać z niektórych funkcji zarządzania użytkownikami/rolami/prawami.

Jeśli obawiasz się ataków typu "człowiek w środku", najlepiej jest użyć protokołu HTTPS.

Powiązane problemy