2013-04-19 15 views
5

To zabrzmi jak głupie pytanie, ale ja tylko zastanawiam się, czy gdzieś nigdzie mnie nie brakuje.Najlepszy sposób na zapewnienie, że zalogowani użytkownicy widzą tylko ich dane

Scenariusz polega na tym, że mam aplikację internetową wykorzystującą Simple Memebership, w której użytkownicy mogą się zarejestrować, aby z niej skorzystać (np. Program fakturowania).

Powinny one jednak móc tylko wyświetlać/aktualizować/usuwać informacje, które same dodają do bazy danych/aplikacji internetowej.

Jaki jest najlepszy sposób, aby zapewnić użytkownikowi dostęp tylko do ich informacji?

Czy dodać pole Nazwa użytkownika na każdym stole, na przykład:

public class Invoice 
{ 
    public int InvoiceId { get; set; } 
    public int CustId { get; set; } 
    public string UserName { get; set; } 
} 

public class Item 
{ 
    public int ItemId { get; set; } 
    public int InvoiceId { get; set; } 
    public string UserName { get; set; } 
} 

... a potem w dowolnym kontrolerze, który uzyskuje dostęp do danych, wystarczy dodać czek na nazwie użytkownika w każdym zapytaniu, np:

var Inv = db.Invoices.Where(x => x.UserName = User.Identity.Name); 
var Itm = db.Items.Where(y => y.UserName = User.Identity.Name); 

to właśnie używam obecnie, ale zastanawiałem się, czy to jest najlepszych praktyk? Lub jeśli jest prostszy sposób teraz jesteśmy na MVC4?

Czy to najlepiej użyć nazwa_użytkownika lub userid z UserProfile stole, albo to ma znaczenie?

Aktualizacja dodać klarowność po komentarzach

Więc 10 użytkowników zarejestrowało - a wszystko stworzył własne faktury. Nie chcę, aby ktokolwiek widział faktury innych użytkowników.

Dzięki za radę.

Mark

+0

Ja nie musi to być zrobione na poziomie kodu, ale raczej na poziomie bazy danych. Jeśli użytkownik publikuje coś, najlepszym sposobem jest powiązanie tego wpisu z użytkownikiem. Jeśli użytkownik przegląda witrynę, zapytanie powinno pobrać wszystkie informacje związane z tym użytkownikiem, więc nie musisz zajmować się tym w kodzie. – Terry

+0

Jak możesz to zrobić w dowolnym miejscu poza kodem? Baza danych nie wiedziałaby, kim jest użytkownik (przepraszam, jeśli przegapiłem twój punkt widzenia). dziękuję – Mark

+0

W pewnym momencie aplikacji, musisz odzyskać informacje, które użytkownik może zobaczyć. W tym momencie już wiesz, kim jest użytkownik, ponieważ się loguje, więc powinieneś mieć przynajmniej identyfikator użytkownika. Teraz, gdy pobierzesz informacje, użyj tego identyfikatora użytkownika, aby wykonać zapytanie i uzyskać informacje powiązane z właściwym użytkownikiem. – Terry

Odpowiedz

2

Jeśli założyć db relacji poprawnie, powinieneś być w stanie odwołać np faktury użytkownika tak:

var invoices = dbContext.Users.first(u=>u.id == idParam).Invoices; 

Można sprawdzić czy faktura należy do użytkownika poprzez testowanie

if(dbContext.Invoices.Any(i=>i.invoiceID))//invoice exists? 
{ 
    //Invoice belongs to user? 
    bool invoiceBelongsToUser = dbContext.Users.first(u=>u.id == idParam) 
    .Invoices.Any(i=>i.invoiceID == invoiceIDParam); 
} 
0

Można dodać filtr AuthorizeAttribute do pliku global.asax chronić każdą metodę działania każdego kontrolera.

a kontroler bez konieczności uzyskania zezwolenia:

[AllowAnonymous] 
public ActionResult LogOn() 

securing-your-asp-net-mvc-3-application

+0

Witam - przepraszam, jeśli chcę "wyjaśnić - co zrobić, jeśli dwóch użytkowników lub dwustu użytkowników tworzy własne faktury - moje pytanie brzmi: jak najlepiej je powstrzymać, sprawdzając faktury wystawione przez inne osoby. Dziękuję Ci. – Mark

3

Czego zrobiłby to:

  1. uniknąć przechodzenia w jakiejkolwiek formie identyfikatora użytkownika/poświadczeń w poście/ciąg zapytania, przytrzymaj go w bezpiecznym miejscu, np. zaszyfrowane w pliku cookie, i zawsze używaj tego podczas budowania zapytań

  2. Jeśli w trakcie edycji zostały przekazane identyfikatory ID do programu, upewnij się, że wartości nie zostały zmienione, jeśli wypiszesz identyfikator w ukrytym polu, upewnij się, że jest taki sam po powrocie, ponieważ zgasł (bezpośredni atak referencyjny nazywa się)

  3. jeśli twoja aplikacja żąda edycji, takiej jak klient/edycja/4, zawsze upewnij się, że identyfikator 4 należy do tego użytkownika przed wyświetleniem go.

Niektóre dobry odczyt tutaj na 10 największych luk: https://www.owasp.org/index.php/Top_10_2010-Main

+0

"Zaszyfrowane w pliku cookie" nadal nie jest bezpiecznym miejscem. –

+0

Witam - używam ASP.Net/MVC4 - i tokena przeciw oszustwom i autoryzuję atrybuty itp. - więc miałbym nadzieję, że przechowuje to, co jest potrzebne do utrzymania szczegółów "zalogowanego użytkownika" w jego strukturze i nie wyeksponowania go do klienta. Czy byłbym w błędzie? – Mark

+0

Wszystkie żetony przeciwdziałające fałszerstwom zapobiegają atakom xss, nadal musisz chronić przed dra – Slicksim

Powiązane problemy