Jak dobrze interfejs użytkownika kakao i ogólne elementy struktury są chronione przed złośliwymi atakami?

Question

Do tej pory nie dbałem o ogólne względy bezpieczeństwa, ponieważ opracowywałem tylko promocyjne i bezkrytyczne aplikacje na iPhone'a.

Obecnie jednak pracuję nad aplikacją na Maca, która wymaga jeszcze więcej informacji na ten temat, ponieważ dotyczy wrażliwych informacji o użytkowniku.

Podczas gdy wiem, że muszę zadbać o ochronę danych w ich fizycznej formie (na dysku), na przykład przez ich zaszyfrowanie, zastanawiam się, jak bezpieczne jest to, gdy znajduje się w pamięci podczas normalnego użytkowania podanie.

Dlatego chciałbym wiedzieć:
Jak bezpieczny jest mój wniosek, o ile jest zbudowany wyłącznie na elementach ramowych takich jak NSTextField i danych Core?

Jak wrażliwe są elementy wejściowe Cocoa na złośliwe ataki? Jaki byłby najlepszy sposób ochrony zapisanych danych przechowywanych przy użyciu danych podstawowych?

Answer 1

Objective-C jest językiem dynamicznym, co oznacza, że ​​można zastąpić klasy i określone metody zajęć w czasie wykonywania. Na przykład w ten sposób wtyczka 1Password trafia do Safari, a Dropbox odnajduje ją w Finderze. Obecnie złośliwy atakujący może użyć interfejsu API mach_inject o niskim poziomie lub kilku innych metod o nieco wyższym poziomie, takich jak wtryskiwanie SIMBL lub OSAX, w celu załadowania kodu do aplikacji. Po załadowaniu kodu do aplikacji dynamiczna natura Objective-C umożliwia teoretycznie zastąpienie NSTextField podklasą wybranego intruza lub specyficznymi metodami w klasie, w tym słuchanie i przechowywanie danych wprowadzanych przez użytkownika. Bezpieczna wersja NSTextField, która jest przeznaczona dla haseł, może mieć pewne zabezpieczenia przed tym, chociaż nie znalazłem specjalnej dokumentacji o tym skutku. Security.framework i keychain API w ogóle chronią twoje dane w pamięci i nie są oparte na Objective-C, więc znacznie trudniej (choć może nadal jest to możliwe) ingerować w nie.

Answer 2

Aby dodać do mgorbach na odpowiedź powyżej (które jest bardzo dobra) Core danych może przechowywać dane w czterech formach:

1. SQLite3 bazy danych (najczęściej)
2. .plist plików (np XML)
3. Binary File
4. w pamięci (non-persistent przechowywanie)

ani .plist, Binary File, lub SQLite są bezpieczne. Pliki .plist można łatwo przeczytać. Plik binarny będzie trudniejszy, ale AFAIK nie używa żadnego szyfrowania, a każdy koder Objective-C powinien z łatwością wyodrębnić jego zawartość. SQLite też nie jest bezpieczne. Narzędzia takie jak SQLite Manager dla FireFox lub Base dla Mac'a sprawiają, że czytanie danych SQLite Core Data jest banalne.

Ponieważ metody przechowywania danych podstawowych nie są bezpieczne, najlepiej jest zaszyfrować dane przed ich przesłaniem na dysk.

Nie bierze pod uwagę żadnych ataków w pamięci. Oczywiście, aby odnieść sukces, system zazwyczaj musi być już w jakiś sposób zagrożony.

Jeśli użytkownik końcowy ma włączoną funkcję FileVault (szyfruje cały folder macierzysty), włącza bezpieczną pamięć wirtualną, włączoną zaporę i silne hasło, to jest w miarę bezpieczny przed wieloma atakami.