Pytanie Jak zabezpieczyć serwis WWW REST w Java EE 6


Zrobiłem aplikację internetową przy użyciu środowiska Java EE 6 (przy użyciu implementacji referencyjnych) i chcę go udostępnić jako usługę sieci Web REST.

Chodzi o to, że chcę mieć możliwość pobierania danych z aplikacji internetowej do aplikacji na iOS, którą zrobiłem. Pytanie brzmi, w jaki sposób mam zabezpieczyć aplikację? Chcę tylko, aby moja aplikacja korzystała z usługi internetowej. Czy to możliwe i jak to zrobić? Muszę tylko wiedzieć, czego powinienem szukać i czytać, a nie prawdziwy kod.


16
2018-01-21 19:16


pochodzenie


dlaczego na Ziemi ktoś miałby głosować, żeby to zamknąć? - MK.
Chcesz wyjaśnić, co mówi dalej? - LuckyLuke


Odpowiedzi:


Niestety Twój webservice nigdy nie będzie całkowicie bezpieczny, ale oto kilka podstawowych rzeczy, które możesz zrobić:

  • Użyj SSL
  • Owinąć wszystko Twoje ładunki wychodzące (aplikacje) w POST upraszanie. Zapobiegnie to przypadkowemu węszeniu, aby się dowiedzieć w jaki sposób twoja usługa sieciowa działa (w celu inżynierii wstecznej protokołu).
  • Jakoś potwierdzić użytkowników aplikacji. Najlepiej będzie, jeśli będzie to dotyczyło OAUTH na przykład przy użyciu danych logowania Google, ale masz pomysł.

Teraz powiem, dlaczego tak jest przyzwyczajenie być całkowicie bezpiecznym:

  • Jeśli ktoś cię złapie aplikacja i inżynierowie odwrotni, wszystko, co właśnie zrobiłeś, jest poza oknem. Jedyną rzeczą, która wytrzyma, jest twoja użytkownik uprawomocnienie.
  • Osadzanie certyfikatu klienta (jak zauważyli inni) nic nie robi aby pomóc ci w tym scenariuszu. Jeśli po prostu odwrócę inżynierską aplikację, mam również certyfikat klienta.

Co mogą ty robisz?

  • Sprawdź poprawność kont w swoim backenderze i monitoruj je pod kątem nietypowego użycia.

Oczywiście to wszystko wychodzi przez okno, gdy ktoś przychodzi, odwraca inżynierów twoją aplikację, buduje inną, aby naśladować to, a ty (ogólnie) nie wiesz nic lepszego. Są to tylko punkty, o których należy pamiętać.

Edytować: Ponadto, jeśli nie było to już oczywiste, użyj POST (lub GET) wnioski o wszystko zapytania aplikacji (do twojego serwera). To, w połączeniu z SSL, powinno udaremnić twoich przypadkowych szpiegów.

Edycja2: Wygląda na to, że jestem w błędzie: POST istota jeszcze bezpieczny niż GET. To odpowiedź była całkiem przydatna w wskazaniu tego. Więc przypuszczam, że możesz użyć GET lub POST zamiennie tutaj.


8
2018-01-21 19:31



Rozumiem, nie muszę robić tego bezpiecznie jako bank :) Chcę tylko ograniczyć lub zatrzymać najbardziej obraźliwy sposób, w jaki ludzie mogą korzystać z API. - LuckyLuke
@Pjotr ​​Następnie tak, SSL i zawijanie wszystkich Twoich ładunków POST wnioski powinny robić to, czego potrzebujesz. Chciałem tylko wskazać, gdzie to jest mógłby poszło źle. - Marvin Pinto
jak POST jest w jakiś sposób bardziej bezpieczny niż GET? - MK.
Rozumiem, dziękuję :) Po to, aby upewnić się, że rozumiem cię poprawnie, prosisz o przesłanie wszystkich danych z mojej aplikacji za pomocą metody POST, prawda? (to masz na myśli przez ładunek?) - LuckyLuke
nie ma potrzeby zawijania wszystkich informacji wejściowych żądania POST podczas korzystania z SSL. SSL szyfruje pełną treść żądania, w tym ścieżkę i ciąg zapytania. - wangii


Zależy od tego, jak bezpiecznie chcesz to zrobić.

  • Jeśli tak naprawdę to nie obchodzi, po prostu umieść w aplikacji tajne słowo i dołącz wszystkie żądania.
  • Jeśli troszczysz się o coś więcej, zrób powyższe i wystawiaj usługę tylko przez https.
  • Jeśli chcesz, aby była bezpieczna, wystaw certyfikat klienta do aplikacji i wymagaj prawidłowy certyfikat klienta, który będzie obecny podczas uzyskiwania dostępu do usługi.

4
2018-01-21 19:20



Potrzebuję tylko podstawowych zabezpieczeń :) Więc mówisz, że mógłbym wysłać taki parametr: "MyMagicKey": "MagicNumber030349" z aplikacji na iOS i sprawdzić, czy pasuje on do mojej aplikacji internetowej? - LuckyLuke
Tak. Ale zapewnia to tylko bardzo podstawowy poziom bezpieczeństwa, ponieważ pobranie tych żądań jest trywialne. Jeśli używasz protokołu https, będzie to znacznie trudniejsze (ale wciąż bardzo możliwe, wymagające ponadprzeciętnych umiejętności), aby to zrozumieć. - MK.


moje sugestie to:

  1. użyj https zamiast http. dostępny jest bezpłatny certyfikat ssl, weź jeden i zainstaluj.
  2. użyj złożonej ścieżki, takiej jak 4324234AA_fdfsaf / jako główny punkt końcowy.

ze względu na naturę protokołu http, część ścieżki jest zaszyfrowane w żądaniu https. dlatego jest bardzo bezpieczny. istnieją sposoby odszyfrowania żądania za pomocą ataku man-in-the-middle, ale wymaga to pełnej kontroli nad urządzeniem klienckim, w tym zainstalowania nieistniejącego certyfikatu ssl. ale spędziłbym więcej czasu na mojej aplikacji, aby osiągnąć sukces.


1
2018-01-21 19:30



w https całe żądanie jest szyfrowane, a nie tylko adres URL. - MK.
nie, nazwa serwera i / lub adres IP nie jest. - wangii
um ... oczywiście tak, adres, z którym się łączysz, nie jest szyfrowany. - MK.
Działa to pod warunkiem, że plik binarny użytkownika końcowego jest bezpieczny przed inspekcją (czy tak?). Jeśli nie, ścieżka jest prawdopodobnie łatwiejsza do wyodrębnienia z tego końca niż próba odszyfrowania tls. Złożona ścieżka musi zostać złamana tylko jeden raz i wraca do posiadania niezabezpieczonego protokołu. - ccoakley
@ ccoakley dobry punkt. jednak nie mam na myśli używania adresu URL api.server / ios / register będzie to zbyt łatwe do odgadnięcia niż pokonanie tls, ani wyodrębnianie plików binarnych z iPhone'a. - wangii


Utwórz regułę na komputerze, na którym znajduje się Twoja usługa sieci Web, aby zezwalać aplikacji tylko na pewien port. W Amazon EC2, robi się to tworząc regułę w instancji Security Group.


0
2018-01-21 19:30





Wykorzystaliśmy RestEasy jako część zabezpieczenia naszych usług RESTful Web. Powinno tam być dużo przykładów, ale tutaj jest ten, który może zacząć.

http://howtodoinjava.com/2013/06/26/jax-rs-resteasy-basic-authentication-and-authorization-tutorial/

Możesz także użyć OAUTH:

http://oltu.apache.org/index.html


0
2017-08-14 20:54