Jakie mechanizmy bezpieczeństwa posiada Meteor? [Zamknięte]

92

Wszyscy wiemy, że Meteor oferuje sterownik miniMongo, który bezproblemowo umożliwia klientowi dostęp do trwałej warstwy (MongoDB).

Jeśli jakikolwiek klient może uzyskać dostęp do trwałego interfejsu API, w jaki sposób można zabezpieczyć swoją aplikację?

Jakie mechanizmy bezpieczeństwa zapewnia Meteor iw jakim kontekście należy ich używać?

Olivier Refalo
źródło
6
Podoba mi się, że jest to już omawiane, ale naprawdę powinni byli wspomnieć o tym w filmie. Myślę, że prawie każdy programista internetowy, który go ogląda, będzie miał to pytanie na myśli od 10 sekund do końca i po prostu czuje się zirytowany, że za tak niesamowity produkt WYGLĄDA całkowicie ignorując oczywisty problem z bezpieczeństwem.
Naatan
6
Meteor 0.5.0 dodał uwierzytelnianie użytkownika meteor.com/blog/2012/10/17/…
hipertracker
Możesz to nieco przeredagować, aby ponownie je otworzyć. Być może „Jakie środki bezpieczeństwa powinienem podjąć?” lub „Jakie opcje zabezpieczeń są dostępne?”
joeytwiddle
1
Oparte na opinii? Wat? Zakładam, że był to audyt wznowiony, ponieważ oczywiście nie jest oparty na opiniach.
bjb568
W pewnym sensie się zgadzam, orzeczenie oparte na opiniach jest wyrwane z kontekstu - odpowiedzi oparte są na prawdziwych faktach.
Olivier Refalo

Odpowiedzi:

64

Podczas tworzenia aplikacji za pomocą polecenia meteor aplikacja domyślnie zawiera następujące pakiety:

  • AUTOPUBLIKUJ
  • NIEPEWNY

Razem naśladują one efekt posiadania przez każdego klienta pełnego dostępu do odczytu / zapisu do bazy danych serwera. Są to przydatne narzędzia do prototypowania (tylko do celów programistycznych), ale zazwyczaj nie są odpowiednie do zastosowań produkcyjnych. Kiedy będziesz gotowy do wydania produkcyjnego, po prostu usuń te pakiety.

Aby dodać więcej, Meteor obsługuje pakiety Facebook / Twitter / i Much More do obsługi uwierzytelniania, a najfajniejszy jest pakiet Accounts-UI

Murali Ramakrishnan
źródło
2
Poprawne od meteoru 0.5
Olivier Refalo
5
Domyślnie niezabezpieczone. Yikes.
Judah Gabriel Himango
16
@JudahHimango jest niezabezpieczone tylko do celów testowych , a usunięcie tych dwóch pakietów, gdy jesteś gotowy do produkcji, jest tak proste, jak meteor remove autopublish insecure.
BenjaminRH
1
A co z metodami meteorytów? Klient może uzyskać do nich dostęp z konsoli nawet po niezabezpieczonej dezinstalacji, ponieważ są one uruchomione na serwerze. Jak można je zabezpieczyć?
Matanya
2
@Matanya, ale po użyciu i wykonaniu tych z konsoli, zgłosi access deniedbłąd. Sprawdź to.
ajduke
35

W dokumencie kolekcji mówi:

Obecnie klient ma pełne prawa do zapisu w kolekcji. Mogą wykonywać dowolne polecenia aktualizacji Mongo. Gdy zbudujemy uwierzytelnianie, będziesz mógł ograniczyć bezpośredni dostęp klienta do wstawiania, aktualizowania i usuwania. Rozważamy również walidatory i inne funkcje podobne do ORM.

pomber
źródło
1
Zobacz także ten wątek na Quorze z odpowiedzią jednego z programistów Meteor: quora.com/Meteor-web-framework/Whats-cool-about-Meteor/answer/…
dentarg
1
@jonathanKingston link jest uszkodzony, czy mógłbyś go zaktualizować?
Carlos Barcelona,
@CarlosBarcelona Domena wygasła, a artykuł był przed aktualizacjami zabezpieczeń w Meteor. Myślę, że można uczciwie powiedzieć, że był on nieaktualny; więc usunąłem ten komentarz, aby zaoszczędzić ludziom czas. Dzięki
jonathanKingston
5

Jeśli mówisz o ograniczeniu klientowi korzystania z nieautoryzowanego interfejsu API wstawiania / aktualizowania / usuwania, jest to możliwe.

Zobacz ich aplikację do zrobienia na https://github.com/meteor/meteor/tree/171816005fa2e263ba54d08d596e5b94dea47b0d/examples/todos

Ponadto dodali teraz wbudowany moduł AUTH, który umożliwia logowanie i rejestrację. Więc jest bezpieczny. Jeśli zajmujesz się XSS, Valiations, nagłówkami klientów itp.

ale każdego dnia możesz przekonwertować aplikację meteor na w pełni działającą aplikację nodejs, wdrażając ją w węźle. Więc jeśli wiesz, jak zabezpieczyć aplikację nodejs, powinieneś być w stanie zabezpieczyć meteor.

Hitesh Joshi
źródło
1
Jest to całkowicie prawdziwe od września 2012 r.
Olivier Refalo
2

Od wersji 0.6.4, w trybie programowania, bloki is_client i is_server nadal trafiają do systemu klienta. Nie mogę powiedzieć, czy są one oddzielone po wyłączeniu trybu programowania.

Jeśli jednak tak nie jest, haker może uzyskać wgląd w system, przeglądając bloki kodu if (Meteor.is_server). Szczególnie mnie to niepokoi, zwłaszcza że zauważyłem, że nadal nie mogę posegregować Kolekcji na osobne pliki na kliencie i serwerze.

Aktualizacja

Cóż, chodzi o to, aby nie umieszczać kodu związanego z bezpieczeństwem w bloku is_server w katalogu innym niż serwer (tj. - upewnij się, że jest w czymś pod / server.

Chciałem sprawdzić, czy zwariowałem na punkcie niemożności rozdzielenia kolekcji klienta i serwera w katalogach klienta i serwera. W rzeczywistości nie ma z tym problemu.

Oto mój test. To prosty przykład modelu publikowania / subskrypcji, który wydaje się działać dobrze. http://goo.gl/E1c56

DrM
źródło
1
Rozwiązaniem byłoby zapisanie kodu w serwerze / folderze - w ten sposób nie zostanie on przesłany do klienta.
Olivier Refalo
DrM, zobacz docs.meteor.com/#structuringyourapp - wrażliwy kod nie musi być dostarczany klientowi
emgee
Spróbuj czegoś prostego; utwórz kolekcję w pliku na serwerze, a następnie utwórz tę samą kolekcję w pliku klienta i powiedz mi, co się stanie. Następnie utwórz plik główny z deklaracją kolekcji, a następnie po prostu odwołaj się do tego w pliku katalogu serwera i klienta i powiedz mi, co się stanie. Jeśli nie możesz utworzyć kolekcji, tak jak ja nie mogłem, jak możesz odwołać się do niej niezależnie? W końcu musisz odwołać się do kolekcji, aby istniała w tym samym dostępnym pliku klienta i używać is_server i is_client. Mam nadzieję, że się mylę, ale jeszcze nie dowiedziałem się, jak i dlaczego.
DrM,
Hmm, dziwne, testy wydają się być w porządku, zaktualizuję odpowiedź
DrM
Link to repozytorium do prostego kodu, ale wydaje się działać dobrze, nie jestem pewien, jakie dziwne błędy występowały w przeszłości ani jak mogę je odtworzyć.
DrM,