Udostępnij za pośrednictwem

Zagadnienia dotyczące zabezpieczeń (Entity Framework)

  • Artykuł

W tym artykule opisano zagadnienia dotyczące zabezpieczeń specyficzne dla tworzenia, wdrażania i uruchamiania aplikacji platformy Entity Framework. Należy również postępować zgodnie z zaleceniami dotyczącymi tworzenia bezpiecznych aplikacji .NET Framework. Aby uzyskać więcej informacji, zobacz Omówienie zabezpieczeń.

Ogólne zagadnienia dotyczące zabezpieczeń

Poniższe zagadnienia dotyczące zabezpieczeń dotyczą wszystkich aplikacji korzystających z programu Entity Framework.

Używanie tylko zaufanych dostawców źródeł danych

Aby komunikować się ze źródłem danych, dostawca musi wykonać następujące czynności:

  • Odbierz parametry połączenia z programu Entity Framework.
  • Przetłumacz drzewo poleceń na natywny język zapytań źródła danych.
  • Zestawy i zwracają zestawy wyników.

Podczas operacji logowania informacje oparte na haśle użytkownika są przekazywane do serwera za pośrednictwem bibliotek sieciowych bazowego źródła danych. Złośliwy dostawca może ukraść poświadczenia użytkownika, wygenerować złośliwe zapytania lub manipulować zestawem wyników.

Szyfrowanie połączenia w celu ochrony poufnych danych

Program Entity Framework nie obsługuje bezpośrednio szyfrowania danych. Jeśli użytkownicy uzyskują dostęp do danych za pośrednictwem sieci publicznej, aplikacja powinna ustanowić zaszyfrowane połączenie ze źródłem danych w celu zwiększenia bezpieczeństwa. Aby uzyskać więcej informacji, zobacz dokumentację dotyczącą zabezpieczeń źródła danych.

Zabezpieczanie parametry połączenia

Ochrona dostępu do źródła danych jest jednym z najważniejszych celów podczas zabezpieczania aplikacji. Parametry połączenia przedstawia potencjalną lukę w zabezpieczeniach, jeśli nie jest ona zabezpieczona lub czy jest nieprawidłowo skonstruowana. Jeśli przechowujesz informacje o połączeniu w postaci zwykłego tekstu lub utrwalasz je w pamięci, ryzykujesz naruszenie całego systemu. Poniżej przedstawiono zalecane metody zabezpieczania parametry połączenia:

  • Użyj tożsamości zarządzanych dla zasobów platformy Azure podczas nawiązywania połączenia z usługą Azure SQL.

    Aby uzyskać więcej informacji, zobacz Tożsamości zarządzane dla zasobów platformy Azure.

  • Użyj uwierzytelniania systemu Windows z lokalnym źródłem danych programu SQL Server.

    Jeśli używasz uwierzytelniania systemu Windows do nawiązywania połączenia ze źródłem danych programu SQL Server, parametry połączenia nie zawiera informacji logowania i hasła.

  • Szyfruj sekcje plików konfiguracji przy użyciu konfiguracji chronionej.

    ASP.NET udostępnia funkcję o nazwie chronioną konfigurację, która umożliwia szyfrowanie poufnych informacji w pliku konfiguracji. Mimo że jest przeznaczony głównie do ASP.NET, można również użyć chronionej konfiguracji do szyfrowania sekcji plików konfiguracji w aplikacjach systemu Windows.

  • Przechowuj parametry połączenia w zabezpieczonych plikach konfiguracji.

    Nigdy nie należy osadzać parametry połączenia w kodzie źródłowym. Można przechowywać parametry połączenia w plikach konfiguracji, co eliminuje konieczność osadzania ich w kodzie aplikacji. Domyślnie Kreator modelu danych jednostki przechowuje parametry połączenia w pliku konfiguracji aplikacji. Należy zabezpieczyć ten plik, aby zapobiec nieautoryzowanemu dostępowi.

  • Używaj konstruktorów parametry połączenia podczas dynamicznego tworzenia połączeń.

    Jeśli musisz utworzyć parametry połączenia w czasie wykonywania, użyj EntityConnectionStringBuilder klasy . Ta klasa konstruktora ciągów pomaga zapobiegać atakom polegającym na wstrzyknięciu parametry połączenia przez weryfikowanie i ucieczkę nieprawidłowych informacji wejściowych. Użyj również odpowiedniej klasy konstruktora ciągów, aby skonstruować źródło danych parametry połączenia, które jest częścią parametry połączenia Entity Framework. Aby uzyskać informacje o konstruktorach parametry połączenia dla dostawców ADO.NET, zobacz Konstruktory parametrów połączenia.

Aby uzyskać więcej informacji, zobacz Ochrona informacji o połączeniu.

Nie uwidaczniaj elementu EntityConnection niezaufanym użytkownikom

Obiekt EntityConnection uwidacznia parametry połączenia bazowego połączenia. Użytkownik z dostępem EntityConnection do obiektu może również zmienić ConnectionState połączenie bazowe. Klasa EntityConnection nie jest bezpieczna wątkiem.

Nie przekazuj połączeń poza kontekstem zabezpieczeń

Po nawiązaniu połączenia nie można przekazać go poza kontekst zabezpieczeń. Na przykład jeden wątek z uprawnieniem do otwierania połączenia nie powinien przechowywać połączenia w lokalizacji globalnej. Jeśli połączenie jest dostępne w lokalizacji globalnej, inny złośliwy wątek może używać otwartego połączenia bez jawnego udzielenia mu tego uprawnienia.

Należy pamiętać, że informacje logowania i hasła mogą być widoczne w zrzucie pamięci

Gdy informacje o logowaniu i haśle źródła danych są dostarczane w parametry połączenia, te informacje są przechowywane w pamięci do momentu odzyskania zasobów przez odzyskiwanie pamięci. Uniemożliwia to określenie, kiedy ciąg hasła nie jest już w pamięci. Jeśli aplikacja ulegnie awarii, plik zrzutu pamięci może zawierać poufne informacje o zabezpieczeniach, a użytkownik z uruchomioną aplikacją i dowolnym użytkownikiem z dostępem administracyjnym do komputera może wyświetlić plik zrzutu pamięci. Użyj uwierzytelniania systemu Windows dla połączeń z programem Microsoft SQL Server.

Udzielanie użytkownikom tylko niezbędnych uprawnień w źródle danych

Administrator źródła danych powinien udzielić użytkownikom tylko niezbędnych uprawnień. Mimo że język Entity SQL nie obsługuje instrukcji DML, które modyfikują dane, takie jak INSERT, UPDATE lub DELETE, użytkownicy nadal mogą uzyskiwać dostęp do połączenia ze źródłem danych. Złośliwy użytkownik może użyć tego połączenia do wykonania instrukcji DML w języku natywnym źródła danych.

Uruchamianie aplikacji z minimalnymi uprawnieniami

Jeśli zezwolisz aplikacji zarządzanej na uruchamianie z uprawnieniami pełnego zaufania, program .NET Framework nie ogranicza dostępu aplikacji do komputera. Może to umożliwić lukę w zabezpieczeniach aplikacji w celu naruszenia bezpieczeństwa całego systemu. Aby używać zabezpieczeń dostępu kodu i innych mechanizmów zabezpieczeń w programie .NET Framework, należy uruchamiać aplikacje przy użyciu uprawnień częściowego zaufania i z minimalnym zestawem uprawnień wymaganych do umożliwienia działania aplikacji. Następujące uprawnienia dostępu do kodu są minimalnymi uprawnieniami, których potrzebuje aplikacja Entity Framework:

Aby uzyskać więcej informacji, zobacz Zabezpieczenia dostępu kodu i ADO.NET.

Nie instaluj niezaufanych aplikacji

Program Entity Framework nie wymusza żadnych uprawnień zabezpieczeń i wywoła kod obiektu danych dostarczony przez użytkownika w procesie niezależnie od tego, czy jest zaufany, czy nie. Upewnij się, że uwierzytelnianie i autoryzacja klienta jest wykonywane przez magazyn danych i aplikację.

Ograniczanie dostępu do wszystkich plików konfiguracji

Administrator musi ograniczyć dostęp do zapisu do wszystkich plików, które określają konfigurację aplikacji, w tym do plików enterprisesec.config, security.config, machine.conf i aplikacji> pliku <konfiguracji aplikacji.exe.config.

Niezmienna nazwa dostawcy jest modyfikowalna w pliku app.config. Aplikacja kliencka musi ponosić odpowiedzialność za dostęp do dostawcy bazowego za pośrednictwem standardowego modelu fabryki dostawcy przy użyciu silnej nazwy.

Ograniczanie uprawnień do plików modelu i mapowania

Administrator musi ograniczyć dostęp do zapisu do plików modelu i mapowania (.edmx, csdl, ssdl i msl) tylko do użytkowników, którzy modyfikują model lub mapowania. Program Entity Framework wymaga tylko dostępu do odczytu do tych plików w czasie wykonywania. Administrator powinien również ograniczyć dostęp do warstwy obiektów i wstępnie skompilowanych plików kodu źródłowego widoku generowanych przez narzędzia modelu danych jednostki.

Zagadnienia dotyczące zabezpieczeń zapytań

Podczas wykonywania zapytań dotyczących modelu koncepcyjnego mają zastosowanie następujące zagadnienia dotyczące zabezpieczeń. Te zagadnienia dotyczą zapytań Entity SQL przy użyciu klasy EntityClient i zapytań dotyczących obiektów przy użyciu metod LINQ, Entity SQL i konstruktora zapytań.

Zapobieganie atakom polegającym na wstrzyknięciu kodu SQL

Aplikacje często przyjmują dane wejściowe zewnętrzne (od użytkownika lub innego agenta zewnętrznego) i wykonują akcje na podstawie tych danych wejściowych. Wszelkie dane wejściowe bezpośrednio lub pośrednio pochodzące od użytkownika lub agenta zewnętrznego mogą mieć zawartość, która używa składni języka docelowego w celu wykonywania nieautoryzowanych akcji. Gdy język docelowy jest językiem ustrukturyzowanym (SQL), takim jak Transact-SQL, ta manipulacja jest nazywana atakiem polegającym na wstrzyknięciu kodu SQL. Złośliwy użytkownik może wstrzyknąć polecenia bezpośrednio do zapytania i usunąć tabelę bazy danych, spowodować odmowę usługi lub zmienić charakter wykonywanej operacji.

  • Ataki iniekcji jednostki SQL:

    Ataki iniekcyjne SQL mogą być wykonywane w usłudze Entity SQL przez podanie złośliwych danych wejściowych do wartości używanych w predykacie zapytania i w nazwach parametrów. Aby uniknąć ryzyka wstrzyknięcia kodu SQL, nigdy nie należy łączyć danych wejściowych użytkownika z tekstem polecenia Entity SQL.

    Zapytania Entity SQL akceptują parametry wszędzie tam, gdzie są akceptowane literały. Należy użyć zapytań sparametryzowanych zamiast wstrzykiwania literałów z agenta zewnętrznego bezpośrednio do zapytania. Należy również rozważyć użycie metod konstruktora zapytań do bezpiecznego konstruowania jednostki SQL.

  • Ataki iniekcji LINQ to Entities:

    Chociaż kompozycja zapytań jest możliwa w linQ to Entities, jest wykonywana za pośrednictwem interfejsu API modelu obiektów. W przeciwieństwie do zapytań Entity SQL zapytania LINQ to Entities nie komponują się przy użyciu manipulowania ciągami ani łączenia i nie są podatne na tradycyjne ataki polegających na wstrzyknięciu kodu SQL.

Zapobieganie bardzo dużym zestawom wyników

Bardzo duży zestaw wyników może spowodować zamknięcie systemu klienta, jeśli klient wykonuje operacje, które zużywają zasoby proporcjonalne do rozmiaru zestawu wyników. Nieoczekiwanie duże zestawy wyników mogą wystąpić w następujących warunkach:

  • W zapytaniach dotyczących dużej bazy danych, które nie zawierają odpowiednich warunków filtrowania.
  • W zapytaniach tworzących sprzężenia kartezjańskie na serwerze.
  • W zagnieżdżonych zapytaniach SQL jednostek.

Podczas akceptowania danych wejściowych użytkownika należy się upewnić, że dane wejściowe nie mogą spowodować, że zestawy wyników staną się większe niż to, co może obsłużyć system. Możesz również użyć Take metody w linQ to Entities lub operatora LIMIT w jednostce SQL, aby ograniczyć rozmiar zestawu wyników.

Unikaj zwracania wyników IQueryable podczas uwidaczniania metod potencjalnie niezaufanym obiektom wywołującym

Unikaj zwracania IQueryable<T> typów z metod, które są narażone na potencjalnie niezaufane wywołania z następujących powodów:

  • Użytkownik zapytania, który uwidacznia IQueryable<T> typ, może wywołać metody w wyniku, który uwidacznia bezpieczne dane lub zwiększyć rozmiar zestawu wyników. Rozważmy na przykład następujący podpis metody:

    public IQueryable<Customer> GetCustomer(int customerId)

    Użytkownik tego zapytania może wywołać .Include("Orders") zwrócone IQueryable<Customer> dane, aby pobrać dane, których zapytanie nie zamierza ujawniać. Można tego uniknąć, zmieniając zwracany typ metody na IEnumerable<T> i wywołując metodę (np .ToList(). ), która materializuje wyniki.

  • Ponieważ IQueryable<T> zapytania są wykonywane, gdy wyniki są iterowane, użytkownik zapytania, który uwidacznia IQueryable<T> typ, może przechwytywać wyjątki, które są zgłaszane. Wyjątki mogą zawierać informacje, które nie są przeznaczone dla konsumenta.

Zagadnienia dotyczące zabezpieczeń jednostek

Poniższe zagadnienia dotyczące zabezpieczeń mają zastosowanie podczas generowania typów jednostek i pracy z nimi.

Nie udostępniaj obiektuContext w domenach aplikacji

Udostępnianie elementu z więcej niż jedną domeną ObjectContext aplikacji może uwidaczniać informacje w parametry połączenia. Zamiast tego należy przenieść serializowane obiekty lub grafy obiektów do innego domeny aplikacji, a następnie dołączyć te obiekty do ObjectContext obiektu w tej domenie aplikacji. Aby uzyskać więcej informacji, zobacz Serializowanie obiektów.

Zapobieganie naruszeniom bezpieczeństwa typu

W przypadku naruszenia bezpieczeństwa typu program Entity Framework nie może zagwarantować integralności danych w obiektach. Naruszenia bezpieczeństwa typu mogą wystąpić, jeśli zezwalasz niezaufanym aplikacjom na uruchamianie z zabezpieczeniami dostępu do kodu o pełnym zaufaniu.

Obsługa wyjątków

Metody dostępu i właściwości ObjectContext bloku try-catch. Przechwytywanie wyjątków uniemożliwia nieobsługiwanym wyjątkom uwidacznianie wpisów w ObjectStateManager informacjach o modelu lub (takich jak nazwy tabel) użytkownikom aplikacji.

Zagadnienia dotyczące zabezpieczeń aplikacji ASP.NET

Podczas pracy ze ścieżkami w aplikacjach ASP.NET należy wziąć pod uwagę następujące kwestie.

Sprawdzanie, czy host przeprowadza kontrole ścieżek

|DataDirectory| Gdy jest używany ciąg podstawienia (ujęty w symbole potoku), ADO.NET sprawdza, czy rozpoznana ścieżka jest obsługiwana. Na przykład ".." nie jest dozwolony za DataDirectory. To samo sprawdzenie rozpoznawania operatora głównego aplikacji sieci Web (~) jest wykonywane przez proces hostujący ASP.NET. Usługi IIS wykonują tę kontrolę; jednak hosty inne niż usługi IIS mogą nie sprawdzić, czy rozpoznana ścieżka jest obsługiwana. Należy znać zachowanie hosta, na którym wdrażasz aplikację platformy Entity Framework.

Nie zakładaj założeń dotyczących rozpoznanych nazw ścieżek

Mimo że wartości, do których operator główny (~) i DataDirectory ciąg podstawienia są rozpoznawane, powinny pozostać stałe w czasie wykonywania aplikacji, program Entity Framework nie ogranicza hosta do modyfikowania tych wartości.

Weryfikowanie długości ścieżki przed wdrożeniem

Przed wdrożeniem aplikacji platformy Entity Framework należy upewnić się, że wartości operatora głównego (~) i DataDirectory ciągu podstawienia nie przekraczają limitów długości ścieżki w systemie operacyjnym. ADO.NET dostawcy danych nie zapewniają, że długość ścieżki mieści się w prawidłowych limitach.

Zagadnienia dotyczące zabezpieczeń dotyczące metadanych ADO.NET

Poniższe zagadnienia dotyczące zabezpieczeń mają zastosowanie podczas generowania i pracy z plikami modelu i mapowania.

Nie ujawniaj poufnych informacji za pośrednictwem rejestrowania

ADO.NET składniki usługi metadanych nie rejestrują żadnych informacji prywatnych. Jeśli nie można zwrócić wyników z powodu ograniczeń dostępu, systemy zarządzania bazami danych i systemy plików powinny zwracać zero wyników zamiast zgłaszać wyjątek, który może zawierać poufne informacje.

Nie akceptuj obiektów MetadataWorkspace z niezaufanych źródeł

Aplikacje nie powinny akceptować wystąpień MetadataWorkspace klasy z niezaufanych źródeł. Zamiast tego należy jawnie skonstruować i wypełnić obszar roboczy z takiego źródła.

Zobacz też