Parse.com bezpieczeństwo API dotyczy

Question

To pytanie jest zwierciadłem a bug report I made on parse's help forum

Teraz wiem, że jeden na miejscu analizowania nie jest pytanie, ale raport, a ja nie chcę zostawić tu tylko zwierciadłem raport, ale po prostu sprawdź, czy moje obawy są uzasadnione, z ludźmi, którzy prawdopodobnie mają więcej doświadczenia ze mną.

Problem polega na tym, że wygląda na to, że analiza nie generuje podpisu HMAC we właściwy sposób.

• Pierwszy test: wziąłem proxy (proxy Charlesa), ustawiłem punkt przerwania na żądanie aktualizacji i zmieniłem pole pozostawiając podpis nietknięty. Wykonaj żądanie. Serwer akceptuje żądanie, a pola są odpowiednio do niego aktualizowane (nawet pole zmodyfikowane w punkcie przerwania oczywiście).
• Drugi test: zamiast modyfikowania żądania właśnie zmieniłem podpis, aby upewnić się, że serwer faktycznie testuje wartość podpisu, żądanie zostało odrzucone zgodnie z oczekiwaniami.
• Trzeci test: zamiast modyfikować tylko wartość istniejącego pola, dodaj nowe, nowe pole do żądania i wykonaj. Serwer akceptuje żądanie, aktualizuje pole, jeśli dodane pole nie istnieje, dodaje je do zaktualizowanego wiersza, w przeciwnym razie po prostu go aktualizuje.

Czy moje obawy są uzasadnione? Czy źle zrozumiałem specyfikację RFC OAuth w jakiejkolwiek części dotyczącej generowania sygnatur? Jak to możliwe, że pracownicy/użytkownicy Parse nigdy nie zauważają tak dużego błędu?

Proszę, wiem, że to pytanie może generować szeroką dyskusję, ale ponieważ znaczenie tego pytania (i nie tylko dla mnie, ale dla wszystkich użytkowników parsa) pozostawia czas dla kogoś poinformowanego, aby zostawił prawidłową odpowiedź.

EDIT:

jestem kopanie wewnątrz Parse iOS SDK, aby dowiedzieć się, dlaczego tak się rzeczywiście dzieje. Po kilku badaniach i małej inżynierii odwrotnej ich statycznej biblioteki odkryłem, że używają zmodyfikowanego (prawdopodobnie zmodyfikowali nazwy metod poprzedzających je biblioteką "PF") o nazwie OAuthCore. Po tym, jak to odkryłem, mam potwierdzenie, patrząc na starą wersję SDK z otwartym kodem źródłowym (znaleziono wyszukiwanie w google dla zmodyfikowanych nazw bibliotek). Teraz biblioteka wykonuje swoją pracę i działa zgodnie z oczekiwaniami, pozostawiając wystarczająco dużo RFC. Problem polega na tym, że oczywiście OAuth nie obejmuje całego żądania HTTP, ale tylko jego część. Czego się spodziewałem i jak powinno wyglądać IMHO, to to, że kiedy wysyłasz prośbę o aktualizację pola (lub dokonujesz zakupu? Logujesz się? Wysyłaj wrażliwe dane?), "Brudne" pola powinny być wysyłane jako parametry żądania, , więc że zostaną uwzględnione w procesie podpisu/weryfikacji przeprowadzonym przez protokół OAuth. Zamiast tego wprowadzane są żądania aktualizacji (wykonane konkretnie przez wywołanie żądania POST skierowane do https://api.parse.com/2/update), ustawiając treść żądania POST na ciąg json reprezentujący aktualną aktualizację. Szczerze mówiąc było to jasne nawet przed tym wszystkim, ponieważ patrząc na prośbę, powinienem był zorientować się, że tekst json został wysłany jako surowa treść żądania, a nie forma x-www-urlencoded body (w ten sposób parametry zapytania są zakodowane i & -konkomendowane w treści żądania).

Chociaż jest to teraz "poprawne" zachowanie, mam wrażenie, że nie jest tak, jak powinno być w środowisku produkcyjnym używanym przez tysiące ludzi. Teraz zrobię to, próbując go załatać, nie łamiąc funkcjonalności, jeśli uda mi się to zrobić, udostępnię tę poprawkę.

Nadal mam nadzieję na otrzymanie odpowiedzi bezpośrednio od Parse.

EDIT 2: Parse zamknął moje pytanie jako nie-pytanie, ale raport o błędzie. Brak komentarzy na temat głównych wad bezpieczeństwa, które wynikają z ich implementacji.

Poniżej kopii zgłoszonych błędów

byłem zabawy z Parse iOS SDK i znalazłem poważny błąd że poważnie zagrożenie bezpieczeństwa z aplikacji opracowanych przy użyciu parse jako backend.

Przykro mi, ale nie używam narzędzia do zgłaszania błędów, ale nie mam konta na Facebooku i nie jestem do tego skłonny.

Przesłanka: Interfejsy API parse wydają się być zgodne z protokołem OAuth 1.0a (RFC 5849). Odpowiednia część specyfikacji RFC, która dotyczy tego błędu, znajduje się pod numerem strona 18, podpis.

W OAuth, zgodnie z wyżej wymienionym dokumencie RFC, każdy wniosek powinien mieć nagłówek uwierzytelniania w składzie jak:

OAuth realm="Example", 
oauth_consumer_key="0685bd9184jfhq22", 
oauth_token="ad180jjd733klru7", 
oauth_signature_method="HMAC-SHA1", 
oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D", 
oauth_timestamp="137131200", 
oauth_nonce="4572616e48616d6d65724c61686176", 
oauth_version="1.0" 

Zapewni to nie tylko, że wniosek jest uprawniony, ale nawet prośba integralność od HMAC podpis wymusi to. W związku z tym fakt, że podpis powinien być obliczony przy użyciu znormalizowanego ciągu znaków utworzonego przez parametry żądania i podpisanego z , klient podzielił się z tajnym kluczem współdzielonym tokenu (zob. Sekcja 3.4.2, strona 25 specyfikacji RFC). W ten sposób szkodliwy użytkownik nie powinien EVER móc modyfikować żądania zanim dotrze do serwera. Serwer powinien sprawdzić sygnaturę pod kątem całego żądania , odrzucając go, jeśli nie.

Niestety dość, że Parse wydaje się nie do końca zgodny z powyższym. Korzystając z prostego proxy, mogę całkowicie zmodyfikować żądania, zmienić wartość parametru na żądanie , zmienić wartość parametru na żądanie , DODAĆ POLA I WARTOŚĆ, KTÓRA NIE ZOSTAŁA ZAWARTA W ŻĄDANIU W OGÓLE.

Teraz bardzo łatwo wyobrazić sobie wady, do których to wszystko może doprowadzić . W szczególności myślę twórcom aplikacji mobilnych, że umożliwiają zakupy w aplikacji w aplikacji, dzięki czemu parsowanie jest bezpieczne, ponieważ ich użytkownicy nie będą w stanie "oszukiwać", a tym samym tracić dochód i unieważniać starań, które poczynili dla swojej aplikacji.

Teraz, gdy udało mi się przetestować go na innych SDK, jestem całkiem pewny ten sam błąd jest powtarzalny tam też, a nawet gorzej, że problem jest że serwer nie sprawdza podpis na wszystko.

Oczekiwanie na odpowiedź od pracownika Parse o tym błędzie.

Pozdrawiam, Antonio

Answer 1

Jest imponująca, które zostały wykopane w ramy, aby sprawdzić problemy z bezpieczeństwem. Nie jestem ekspertem od oautha. Ale chcę tylko skomentować twoje obawy dotyczące zakupu w aplikacji.Nie trzeba martwić się o zakup w aplikacji, ponieważ jest on w całości obsługiwany przez App Store. Każdy zakup będzie obsługiwany przez aplikację StoreKit.framework na iOS. Parse nie ma nic wspólnego z zakupem w aplikacji. Jeśli chcesz sprawdzić, czy dana osoba coś kupiła, potrzebujesz tylko funkcji przywiezionych przez StoreKit.framework, a nie Parse.