Jak MongoDB uniknie bałaganu SQL injection?
Czytałem moją wierną książkę O ' Reilly i natknąłem się na fragment o tym, jak Mongo, z natury, unika bagna błędów podobnych do SQL injection.
Chyba to Rozumiem. Jeśli do zapytań przekazywane są niezaanalizowane var-y, nie mogą one wyrwać się ze struktury zapytań zorientowanych na dokument za pomocąUNION, JOIN, zapytanie, komentarz itp.
Jak MongoDB unika bałaganu SQL injection? Czy to tylko z natury składnia tego zapytania?
5 answers
MongoDB unika potencjalnych problemów, nie analizując.
Dowolne API, gdziekolwiek, które wymaga kodowania danych użytkownika w sformatowanym tekście, który jest przetwarzany, może spowodować, że wywołujący i callee nie zgodzą się co do sposobu przetwarzania tego tekstu. Te nieporozumienia mogą być kwestiami bezpieczeństwa, gdy dane są błędnie interpretowane jako metadane. Jest to prawdą, niezależnie od tego, czy mówisz o ciągach formatów printf, w tym treści generowanych przez użytkowników w HTML, czy generowaniu SQL.
Ponieważ MongoDB nie analizuj tekst strukturalny, aby dowiedzieć się, co robić, nie ma możliwości błędnego zinterpretowania danych wejściowych użytkownika jako Instrukcji, a tym samym nie ma możliwej dziury w zabezpieczeniach.
Nawiasem mówiąc, Rada unikania API, które wymagają parsowania jest pozycja 5 w http://cr.yp.to/qmail/guarantee.html . Jeśli interesuje Cię pisanie bezpiecznego oprogramowania, warto również przyjrzeć się pozostałym 6 sugestiom.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-02-16 20:13:36
Aby podsumować dokumentację MongoDB
BSON
Jako program kliencki montuje zapytanie w MongoDB, buduje Obiekt BSON, nie ciąg znaków. Tak więc tradycyjne ataki SQL injection są żaden problem.
MongoDB nie jest jednak odporny na ataki iniekcji. Jak wspomniano w tej samej dokumentacji, ataki iniekcyjne są nadal możliwe, ponieważ operacje MongoDB umożliwiają bezpośrednie wykonywanie dowolnych wyrażeń JavaScript na serwerze. Dokumentacja wchodzi w to szczegółowo:
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-09-03 17:30:16
Z PHP mongoDB może stać się podatny na No-SQL injection:
Http://www.idontplaydarts.com/2010/07/mongodb-is-vulnerable-to-sql-injection-in-php-at-least/
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-03-06 01:06:43
Baza danych może nie analizować zawartości, ale istnieją inne obszary kodu, które są podatne na ataki.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-08-20 00:04:08
Aby chronić przed SQL injection, klienci mogą używać interfejsów API języka MongoDB. W ten sposób wszystkie dane wejściowe są proste-polecenia nie mogą być wstrzykiwane. Przykład Javy:
collection.find(Filters.eq("key", "input value"))
Wadą jest to, że nie można łatwo przetestować filtra. Nie możesz skopiować go do powłoki Mongo i przetestować. Szczególnie problematyczne przy większych, bardziej złożonych filtrach/zapytaniach.
Ale!!! istnieje również API, które nie używa interfejsu API filtra-umożliwiające analizę dowolnego filtra json. Przykład Javy poniżej:collection.find(BasicDBObject.parse("{key: "input value"}"));
To miłe, ponieważ możesz skopiować filtr bezpośrednio do powłoki MongoDB, aby go przetestować.
Ale!!! (ostatnie ale, obiecuję) to jest podatne na wstrzyknięcie NoSql. Przykład Javy, gdzie wartością wejściową jest{$gt: ""}.
collection.find(BasicDBObject.parse("{key: {$gt: ""}}"));
W tym ostatnim przykładzie wszystko jest zwracane, nawet jeśli chodziło nam tylko o konkretne rekordy.
Zobacz tutaj dokładniejsze wyjaśnienie dotyczące SQL injection podczas bezpośredniego korzystania z filtrów.
One last rzecz. Myślę, że jest sposób, aby użyć obu filtrów raw i nadal chronić przed SQL injection. Na przykład w Javie możemy użyć parametryzowanych zapytań Jongo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-09-15 06:13:12