jak zabezpieczyć funkcje dll przed użyciem poza moją aplikacją?

Question

Chcę ograniczyć korzystanie z innych aplikacji dll funkcje, które napisałem.

Np. Jeśli hav database.dll zawiera dwie funkcje.

public void InsertInToDatabse(); 
public void ClearDatabase(); 

Teraz, jeśli mój wniosek powołał InsertInToDatabse() i robi jakąś inną pracę, do tego czasu, jeśli jakaś inna aplikacja wywołuje ClearDatabase() poprzez odniesienie database.dll The databse byłoby Cler out.So jaki sposób Ograniczam połączenia do tych funkcji z aplikacji zewnętrznej?

Answer 1

Nie można powstrzymać ludzi od nazywając swoje funkcje, ale jesteś wolny, aby realizować swoje funkcje do ochrony przed takimi okolicznościami.

Na przykład można zablokować dostęp do bazy danych, aby wywołanie blokowało się do momentu zakończenia poprzedniego połączenia, lub można uzyskać flagę, która powoduje, że wywołanie Clear() jest natychmiast zwracane z kodem błędu lub wyjątkiem.

EDIT: I może nie zrozumiałeś pytanie. Jeśli NIGDY nie chcesz, aby kod strony trzeciej wywoływał twoje funkcje, użyj wewnętrznego (i/lub InternalsVisibleTo), jak sugeruje Marcus.

Answer 2

Jeśli dobrze pamiętam, słowo internal jest dokładnie tego typu sytuacjach.

Edit: Jak powiedział w komentarzach, jeśli class A jest w assembly B, następnie class C in assembly D nie będą mieli dostępu do A.

Ponadto, jak wskazano w innych odpowiedzi, można (i prawdopodobnie powinien) mieć jakąś formę uwierzytelniania w ClearDatabase().

Edit 2: To właśnie mnie olśniło, że to coś w rodzaju uprawnienia powinny być na poziomie bazy danych, co oznacza, że ​​jeśli Następujący użytkownik (z tymi uprawnieniami):

A: Insert, Update, Create 

próbował Drop Table , wtedy aplikacja rzuciłaby wyjątek (lub jakkolwiek poradziłbyś sobie z błędami), co oczywiście uniemożliwiłoby to zrobienie tego.

To nie znaczy, że nie należy ustawić ClearDatabase() jak internal, ale jeśli użytkownik (trzecia firm korzysta) posiada uprawnienia do Drop Table następnie s/byłby w stanie niezależnie.

Edit 3:

The problem is not how to secure your code, the problem is how to secure your database. 

– Huusom 

Answer 3

jeśli biblioteka dll jest klasa rzeczywisty plik konfiguracyjny będzie jedną z aplikacji klienckiej (web.config lub app.exe.config) i nie tylko autoryzowane aplikacje będą miały odpowiedni ciąg połączenia z nazwą użytkownika, hasłem, serwerem bazy danych i nazwą bazy danych.

Teraz, nawet jeśli nieautoryzowane aplikacje nie będą mogły nazywać Cię metodami biblioteki DLL w sposób, który ci się podoba, na wypadek, gdyby te złe aplikacje miały bezpośredni dostęp do bazy danych, znając ciąg połączenia, nadal mogą się zepsuć.

to znaczy, że tak długo, jak konfiguracja jest poza biblioteką dll, nie powinieneś się martwić, ponieważ tylko autoryzowane aplikacje będą uzyskiwać dostęp do odpowiedniej bazy danych.

jeśli to podejście nadal Cię nie satysfakcjonuje, powinieneś używać sprawdzania bezpieczeństwa, takiego jak CAS, które pozwala ci określić, która klasa lub zespół może wywoływać określoną metodę, więc nawet jeśli twoja biblioteka DLL zostanie przywołana przez inną aplikację, wygrała ' t działa. Pamiętaj, że w .NET 4 (ty określili go w pytaniu) cała warstwa zabezpieczeń został zmieniony i działa odmiennie od starszych wersji .NET Framework, sprawdź ten artykuł więcej szczegółów: http://msdn.microsoft.com/en-us/library/dd233103.aspx

Answer 4

można użyć wewnętrznego dostęp w sprawie metod, które chcesz chronić (zamiast publicznych), a następnie oznacz swoje projekty jako zestawy znajomych. Jest to ten sam sposób, w jaki zezwalasz jednostkom testowym na dostęp do metod wewnętrznych.

Oto opis od MSDN's Friend Assemblies article ...

tylko zespoły, które wyraźnie określają jako przyjaciele mogą uzyskać dostęp do przyjaciela (Visual Basic) lub wewnętrznych (C#) typy i członków. Na przykład, jeśli montaż B jest przyjacielem zespołu A-montażowej montażowej odniesienia C B, C nie ma dostępu do znajomego (Visual Basic) lub wewnętrznych (C#) typów w A.

Answer 5

Jak wspomniano mogłeś Marcus użyj słowa kluczowego internal. Następnie zastosuj bibliotekę InternalsVisibleToAttribute do biblioteki klas z nazwą zestawu aplikacji i kluczem publicznym, jeśli używasz silnych nazw zespołów.

MSDN link

Answer 6

Jeśli pytasz o bezpieczeństwo: Inną techniką byłoby zrobić przepustkę klienta za pomocą parametru, takich jak hasła lub zaszyfrowanego ciągu połączenia na przykład.

Jeśli pytasz o ograniczeniu poprzez buforowanie (Np. Metoda ta pozwala jedynie na miano raz na minutę) - a następnie spójrz na opcję [AspNetCacheProfile] dla usług lub Cache.Insert dla kodu aplikacji.