Granice bezpieczeństwa w marketplace

Problem#

Marketplace ma jedną cechę, której nie ma zwykły sklep: w tym samym systemie pracują podmioty, które nie powinny widzieć nawzajem swoich danych, a jednocześnie nie są pracownikami operatora. Sprzedawca to użytkownik zewnętrzny z dostępem do panelu.

To zmienia charakter zagrożeń. Najpoważniejsze nie są atakami z zewnątrz, tylko zwykłym dostępem użytkownika do czegoś, co nie należy do niego.

Pięć granic, które faktycznie pękają#

Minimalna wersja#

• Właściciel danych wyprowadzany z sesji, nigdy z parametru przesłanego przez klienta.
• Filtr po właścicielu w warstwie dostępu do danych, nie w widoku.
• Weryfikacja podpisu każdego przychodzącego zdarzenia od dostawcy.
• Poświadczenia integracji trzymane osobno od reszty danych sprzedawcy.
• Pliki od użytkowników serwowane z innej domeny niż panel.

Czego nie budować teraz#

• Własnego systemu wykrywania nadużyć.
• Szczegółowych uprawnień per zasób i per akcja.
• Skanowania wgrywanych plików własnymi regułami.
• Rejestru dostępu do każdego rekordu.

Zaplanuj z góry#

Izolacja jako domyślne zachowanie#

Zapytanie o dane sprzedawcy ma domyślnie ograniczać się do jego danych, a pobranie cudzych ma wymagać jawnego działania. Odwrotny domyślny stan oznacza, że każdy nowy ekran jest okazją do wycieku.

Podpis zdarzenia weryfikowany przed czymkolwiek innym#

Punkt przyjmujący zdarzenia od dostawcy jest publiczny. Bez weryfikacji podpisu jest otwartym wejściem, przez które da się wywołać dowolną operację, którą ten punkt obsługuje.

Poświadczenia jako osobny byt#

Klucze do sklepów sprzedawców to najbardziej wrażliwe dane w systemie, bo dają dostęp do cudzego biznesu. Trzymane w tym samym miejscu co profil trafiają do każdego eksportu i każdego zrzutu diagnostycznego.

Wyzwalacze#

• pierwszy nowy widok pisany przez kogoś, kto nie znał reguły izolacji;
• pierwsza integracja z poświadczeniami sprzedawcy;
• pierwsza funkcja pozwalająca wgrać plik;
• pierwsza wiadomość między kupującym a sprzedawcą;
• drugi członek zespołu z dostępem do panelu.

Następny etap#

Po pierwszym wyzwalaczu: przeniesienie izolacji do warstwy niższej niż widok, jeśli jeszcze tam nie jest. Po trzecim: ograniczenie typów i rozmiarów plików oraz oddzielna domena serwowania. Po czwartym: podstawowa ochrona przed nadużyciem kanału wiadomości. Po piątym: role, najprostsze możliwe.

Częste błędy#

Co się sprawdza w praktyce#

Jedyną regułą, która w praktyce zapobiega wyciekom, jest wyprowadzanie właściciela danych z sesji i ograniczanie zapytań w warstwie dostępu. Wszystko, co zależy od pamiętania o filtrze przy pisaniu nowego ekranu, zawiedzie przy którymś z kolei ekranie.

Weryfikacja podpisu zdarzeń przychodzących jest drugą rzeczą, której nie da się dołożyć bezboleśnie później, bo do tego czasu punkt działa i ktoś już na nim polega.

Checklista#

• Właściciel danych pochodzi z sesji, nie z żądania.
• Izolacja jest wymuszona w warstwie dostępu do danych.
• Każde przychodzące zdarzenie ma weryfikowany podpis.
• Poświadczenia integracji są przechowywane osobno.
• Pliki od użytkowników są serwowane z innej domeny niż panel.