MongoDB
 sql >> Baza danych >  >> NoSQL >> MongoDB

W jaki sposób MongoDB unika bałaganu związanego z iniekcją SQL?

MongoDB unika potencjalnych problemów, nie analizując.

Każdy interfejs API, w dowolnym miejscu, który obejmuje kodowanie danych użytkownika w sformatowanym tekście, który jest analizowany, może powodować, że wywołujący i wywoływany nie zgadzają się co do tego, jak ten tekst powinien być analizowany. Te nieporozumienia mogą stanowić problemy z bezpieczeństwem, gdy dane są błędnie interpretowane jako metadane. Dzieje się tak niezależnie od tego, czy mówimy o ciągach formatu printf, w tym treści generowanej przez użytkownika w HTML, czy o generowaniu SQL.

Ponieważ MongoDB nie analizuje tekstu strukturalnego, aby dowiedzieć się, co zrobić, nie ma możliwości błędnego zinterpretowania danych wprowadzonych przez użytkownika jako instrukcji, a zatem nie ma możliwej luki w zabezpieczeniach.

Nawiasem mówiąc, rada dotycząca unikania interfejsów API, które wymagają parsowania, znajduje się w punkcie 5 w http://cr.yp.to/qmail/guarantee.html. Jeśli interesuje Cię pisanie bezpiecznego oprogramowania, warto zapoznać się również z pozostałymi 6 sugestiami.

Aktualizacja (2018):Pierwotna odpowiedź, jaką udzieliłem, pozostaje prawdziwa zgodnie z moją najlepszą wiedzą. Od momentu wysłania do MongoDB do tego, co jest odsyłane z powrotem, nie ma ataku SQL injection. Ataki wstrzykiwania, o których wiem, mają miejsce poza MongoDB i są w rzeczywistości problemami w sposobie, w jaki zewnętrzne języki i biblioteki konfigurują strukturę danych, która zostanie przekazana do MongoDB. Ponadto lokalizacja luki w zabezpieczeniach polega na tym, jak dane są analizowane na drodze do stania się strukturą danych. Dlatego pierwotna odpowiedź dokładnie opisuje, jak uniknąć ataków iniekcji i co naraża Cię na ich ryzyko.

Ale ta dokładność jest zimnym pocieszeniem dla programisty, który jest atakowany przez wstrzykiwanie defektów, które nie były oczywiste w jego własnym kodzie. Niewielu z nas rozróżnia narzędzie zewnętrzne i wszystkie warstwy między naszym kodem a tym narzędziem zewnętrznym. Faktem jest, że przewidywanie i zamykanie ataków iniekcji wymaga czujności z naszej strony. Z wszystkimi narzędziami. I tak pozostanie w najbliższej przyszłości.



  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Wskazówki dotyczące aktualizacji serwera Percona do MongoDB

  2. Poziomy braku bezpieczeństwa MongoDB i jak ich uniknąć

  3. Jak przetestować metodę, która łączy się z mongo, bez faktycznego łączenia się z mongo?

  4. Jak mogę sprawdzić, czy pole istnieje, czy nie w MongoDB?

  5. MongoDB Java Inserting Throws org.bson.codecs.configuration.CodecConfigurationException:Nie można znaleźć kodeka dla klasy io.github.ilkgunel.mongodb.Pojo