Pytanie Django JSON Odseparowanie bezpieczeństwa


Czy są jakieś znane luki w zabezpieczeniach z deserializatorem JSON Django? Jeśli chodzi o protokoły deserializacji w Pythonie, ogólny concensus wydaje się być całkowicie niezabezpieczony, więc unikaj analizowania danych niezaufanych.

Rozważam jednak rozproszoną aplikację internetową, w której różne serwery wymieniają rekordy modeli, sformatowane jako JSON. Same rekordy nie zawierają poufnych danych, ale jestem zaniepokojony możliwością zhakowania serwera przez innego serwer poprzez wysłanie złośliwie sformatowanego JSON. czy to możliwe?

Zwykle widzę serializator JSON Django w środowiskach publicznych, więc mam nadzieję, że jest zahartowany na tego typu rzeczy, ale nie byłem w stanie znaleźć żadnej dokumentacji odnoszącej się do jakichkolwiek problemów bezpieczeństwa.


12
2018-03-07 15:02


pochodzenie


Czy umożliwiasz ochronę CSRF? To powinno znacznie przyczynić się do zapewnienia bezpieczeństwa. - Platinum Azure
Co to jest "złośliwie sformatowany json"? - Marcin
@Marcin, JSON sformatowany w celu wykorzystania luki w parserze, pozwalającej na wykonanie dowolnych instrukcji na serwerze. - Cerin
@Cerin Wiem, jakie jest złośliwe formatowanie. Proszę o wyjaśnienie lub przykład złośliwego sformatowanego JSON. - Marcin
@Marcin, przykro mi, że nie zrozumiałeś mojego pytania, ale nie musisz być niegrzeczny. - Cerin


Odpowiedzi:


Mam problem z wypracowaniem tego, co może być niebezpieczne (lub bezpieczne) na temat JSON.

JSON jest tekstowym formatem wymiany danych. Nie ma żadnych wbudowanych zabezpieczeń. Django ma kilka funkcji do serializowania i deserializacji zestawów zapytań do JSON. Ale te nie mogą być "złośliwe" lub "niepewne" - to tylko dane.

Niektóre protokoły serializacji, np. Wytrawianie, mogą potencjalnie być niebezpieczne, ponieważ mogą zawierać kod, więc mogą być deserializowane, aby uruchomić coś, co szkodzi systemowi. Serializowane modele nie mają tego problemu, ponieważ nie zawierają kodu.

Oczywiście, jeśli używasz JSON do (na przykład) przekazania listy identyfikatorów modelu, które mają zostać usunięte, istnieje możliwość, że złośliwy użytkownik włączy cały ładunek identyfikatorów, których nie chcesz usunąć. Ale znowu nie jest to wina JSON - od Ciebie zależy, czy logika biznesowa poprawnie określa, które elementy użytkownik może usunąć lub zmodyfikować.


3
2018-03-07 15:17



Ale jeśli dekoder jest wadliwy parzysty  dane  może być  złośliwy. - Ignacio Vazquez-Abrams
@Ignacio, Dokładnie. Wiele aplikacji, które tylko odczytują dane (np. Przeglądarki obrazów, odtwarzacze muzyki itp.), Okazjonalnie miało tego rodzaju lukę. Nie chcę automatycznie zakładać, że Django jest zwolniony. - Cerin


Domyślnie podczas używania simplejson, który jest domyślnym deserializerem używanym przez Django, typy obiektów, które mogą być konwertowane z JSON na obiekt Pythona, są ograniczone. Jedyny sposób, aby tak nie było, polega na tym, że wykonujesz jakieś specjalistyczne dekodowanie z wykorzystaniem opcjonalnych argumentów do loads() lub load() metody lub własne JSONDecoder obiekt.

Tak więc, dopóki używasz domyślnego dekodowania, jesteś całkiem bezpieczny. Ale jeśli naprawdę martwisz się, powinieneś sprawdzać załadowane dane JSON PRZED faktycznym zrobieniem czegoś.


3
2018-03-07 15:18



OK, jest to bardzo fajna, ogólna rada: "sprawdź poprawność załadowanego JSON" - z czym ją sprawdzam? Wyrażenia regularne? Sprawdź, czy rozmiar jest mniejszy niż X? Pickle jest niebezpieczny według projektu, ponieważ może wywoływać konstruktory dowolnych obiektów, a JSON jest dość pasywny. Historia jednak zna takie przypadki: kalzumeus.com/2013/01/31/... (było tak z powodu użycia zbyt ogólnego parsera: nie specyficznego dla JSON). Nie możemy całkowicie odpocząć bez bardzo ciężkiego fuzzingu takiego parsera. - Tomasz Gandor