Zabezpieczenie Winforms

0

Witajcie, stworzylem aplikacje winforms, z dostepem do bazy postawionej na serwerze. Do tej bazy jest uzytkownik i haslo. Wszystko chodzi, ale mam watpliowosci co do bezpieczenstwa tzn w 2 sekcjach zywcem sa widoczne loginy i hasla :

  1. App.config
<connectionstrings> <add name="nazwa" connectionstring="baza;Initial Catalog=serwer;Persist Security Info=True;**User ID=uzytkownik;Password=haslo**;Encrypt=True;TrustServerCertificate=True" providername="System.Data.SqlClient" /> </connectionstrings>

Ten problem rozwiazalem tak :
http://www.dreamincode.net/forums/topic/236688-encryptingdecrypting-your-appconfig-or-webconfig/

  1. Properties ->Settings.settings -> Settings.Designer.cs

i tutaj mamy :

[global::System.Configuration.DefaultSettingValueAttribute("Data Source=serwer;Initial Catalog=nazwa_bazy;Persist Security Inf" +
"o=True;**User ID=uzytkownik;Password=haslo;**Encrypt=True;TrustServerCertificate=True" +
"")]

i nie mam pojecia jak moge to ukryc, zakodować, tak by skompilowaniu w bin\debug mamy program.exe i by hasla i loginy nie byly widoczne.
Bo tak mozna otworzyc to notatnikiem i odczytac dane, dostac sie do bazy

0

Zamiast trzymać normalne loginy/hasła w plikach mozesz po prsotu trzymać ich hashe;) Przyklad-> https://msdn.microsoft.com/en-us/library/aa545602%28v=cs.70%29.aspx

3

@FakeAccount - W tej sytuacji to niezbyt pomoże, bo

  1. hashem hasła sie nie zaloguje
  2. hash hasła jest bezpieczniejszy od plaintextu ale dalej można go złamać (zakładając słabe hasło)
  3. program musi się zalogować do bazy żeby robić swoje operacje - więc jeśli hashem hasła program się zaloguje w jakiś sposób, to dokładnie tego samego sposobu może użyć "zły" użytkownik i wychodzi ostatecznie na to samo.

@dobry.basket - słusznie masz wątpliwości, bo to rzeczywisty problem.

http://www.dreamincode.net/forums/topic/236688-encryptingdecrypting-your-appconfig-or-webconfig/

To żadne rozwiązanie (z punktu widzenia security), bo hasło do bazy dalej jest u użytkownika. Skoro program potrafi connection string z configa przeczytać, będzie to potrafił też zrobić abuser. Szyfrowanie web.configu to czyste security through obscurity.

Rozwiązania masz dwa:

  • zignorować problem, liczyć że nikt tego nie będzie sprawdzał (z tego założenia wychodzą dziesiątki tysięcy programistów, nawet tych robiących dość wrażliwe rzeczy) - oczywiście nie polecam ;)
  • zrobić dobrze: założyć że wszystko co może zrobić aplikacja, może też zrobić abuser. I skoncentrować się na ograniczeniu tych możliwości (co będzie wymagało zmian w kodzie niestety).

Czyli musisz stworzyć jakieś API po stronie serwera, które będzie przyjmowało requesty od użytkownika i wykonywało odpowiednie operacje - program nie będize miał bezpośredniego dostępu do bazy danych, i zamiast db.Execute("insert into users values y") będzie np. coś w rodzaju api.InsertUser(y);.
Gdzie tu zysk: możesz dzięki temu

  • (przede wszystkim) kontrolować co może zapisać/odczytać/zmienić użytkownik. Np. może dodać x do tabeli y, ale nie może usunać wszystkich danych z żadnej tabeli, ani zmienić danych innych użytkowników. Najlepiej oczywiście żeby każdy użytkownik aplikacji był autentykowany jakimś id i hasłem.
  • robić jakieś quoty, ograniczać ilość requestów/sekundę wykonywanych przez użytkownika etc
  • (poza bezpieczeństwem) robić statystyki/monitorować aktywność użytkowników i np. patrzeć które funkcje programu są najczęściej używane

Ewentualnie biedniejsza wersja poprzedniego - username i hasło użytkownika do bazy zostawić w konfigu i aplikacji, ale ograniczyć maksymalnie uprawnienia tego użytkownika. W najlepszej możliwej opcji użytkownik na którego loguje sie aplikacja winformsowa ma wyłącznie prawo do wołania przeznaczonych do niego procedur składowanych.

Obie te opcje wymagają trochę zmian w kodzie - magicznego rozwiązania "dopisz kilkanaście linijek kodu" niestety nie ma.

0

Dzięki za odpowiedź, zignorowanie problemu nie wchodzi w grę ;)

Ja mam mini aplikację, nawet żadnego logowania nie mam, ale właśnie w plain tekście są zapisane dane do bazy zdalnej - użytkownik i hasło. W tych dwóch sekcjach, o których mówiłem.

Myślałem nad warstwą pośrednią, czyli webservice. Użytkownik ma login i hasło swoje, które podaje i lecą do webservice i po autoryzacji przesyła odpowiednie dane. Tak, że dane użytkownika bazy ma tylko webservice. a użytkownik aplikacji desktopowej ma tylko hasło dostępowe do webservice'u, który pośredniczy w dostawie danych.

Czy polecicie jakiś artykuł na ten temat?

Thx za odzew.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.