Witam,
ostatnio interesuję się tematem Adobe Air (html+javascript). Wszystko jest ładnie i pięknie do momentu dystrybucji plików - okazuje się że po instalacji wszystkie pliki js są dostępne dla użytkownika i edytowalne. Nie ma problemu z podmienieniem zapytania SELECT itp. trochę mnie to zaniepokoiło.
Czy w takim razie można w Adobe Air faktycznie pisać aplikacje biznesowe które wymagają np. logowania skoro wszystko zwykły średnio-zaawansowany użytkownik internetu może sobie "poprzerabiać"? Spotkał się ktoś z was z podobnym tematem??

Hmm, uważam że szukasz rozwiązania nie tu, gdzie trzeba. Handshaking, wymiana kluczy, na tym opieraj zabezpieczenia, ale pod żadnym pozorem nie na jakichkolwiek danych, które posiada użytkownik i dla każdego są takie same.

Jasne, mogę wymienić klucze itp. ale chciałem aby po autoryzacji, użytkownik nie musiał łączyć się już z internetem tylko pracować lokalnie. Problem w tym, że jeśli status autoryzacji będzie przetrzymywany z zmiennej JS która jest dostępna w kodzie to każdy kto się odrobinę zna będzie mógł zaingerować w tą zmienną.

Tak się nigdy nie robi.

Przetrzymuje się klucz sesji i przy każdej akcji go sprawdza.


No tak, ale skoro jest logowanie online, to przed updatem danych na serwer powinieneś go ponownie autoryzować, chociażby trzymanym kluczem.

Wszystko zależy od tego, jak aplikacja ma działać.

wiem, że nie powinno się statusu logowania przetrzymywać w zmiennej - tyle tylko że nie znalazłem jeszcze dobrego rozwiązania, dlatego piszę ten post
w skrócie - aplikacja ma być w 99% desktopowa, autoryzacja z serwerem ma zostać wykonana tylko 1 przy pierwszym logowaniu (sprawdzenie, czy dana firma posiada aktualną subskrypcję [abonament]). Później wszystkie dane są zapisywane/odczytywane lokalnie, ale kiedy firma nie ma subskrypcji aplikacja nie powinna na nic pozwolić.

No to mów, że chodzi o mechanizm licencji.

http://stackoverflow.com/questions/454940/...-adobe-air-apps
http://www.sharify.it/how-it-works

Ale raczej kiepskie szanse na to...

Każda aplikacja desktopowa jest do złamania, nawet te kompilowane. Zatem dając klientowi źródła (a tak jest w przypadku aplikacji air) trzeba się z tym liczyć, że może zechcieć je sobie podejrzeć.

Teraz, jeśli cała aplikacja, wraz z bazą jest u klienta, to nie ma co się martwić zapytaniami, bo i tak ma dostęp do całej bazy. Zabezpieczenie przed tym, żeby aplikacja się nie uruchomiła jest też tylko dla "dobrych ludzi", bo jeśli klient zechce to usunie fragmenty kodu odpowiedzialne za autoryzację i będzie używał nielegalnie.

Wiadomo, że każdą aplikację można złamać. Chodzi tylko o to, aby nie dawać rozwiązań do łamania 'na tacy'.


No właśnie dlatego zastanawiam się czy jest możliwe aby jednak nie mógł obejść autoryzacji (przynajmniej 'laik'). Tylko coraz bardziej w to wątpię.
Zastanawiam się jednak nad obfuscatorem dla javascriptu... zawsze to 'coś'

po dłuższym zastanowieniu doszedłem do wniosku, że po autoryzacji mógłbym przekazywać (z serwera autoryzującego) obiekt JSON'a do aplikacji z funkcjami do obsługi systemu. Adobe Air nie posiada czegoś takiego jak firebug, więc podgląd danych zwracany przez serwer będzie utrudniony (oczywiście nie niemożliwy). Chyba jest to najbezpieczniejsze rozwiązanie (na jakie wpadłem). Chyba że ktoś ma inny pomysł...

Wszystko co zrobisz może jedynie utrudnić trochę zapędy 'łamacza'. Jeśli ktoś będzie zdeterminowany to i tak sobie poradzi. Możesz zaszyfrować źródła i przy uruchomieniu pobierać klucz z własnego serwera, przy jego pomocy odszyfrowywać źródła i je uruchamiać. Ale jak ktoś zechce to sobie uruchomi sniffera i te hasełko sobie odczyta, zapisze i sam sobie te źródła odkoduje.

Zaciemnianie kodu nie uchroni Cię przed nieautoryzowanym korzystaniem, jedynie utrudni dotarcie do źródeł i ich wykorzystanie gdzieś indziej.

Posiada. Narzędzie to nazywa się AIR Introspector - http://blog.wilgucki.pl/2009/10/adobe-air-...ascript_24.html

A co do tematu. Nie da się tak zabezpieczyć aplikacji. Najszybszym i najtańszym rozwiązaniem byłoby wprowadzenie sumy kontrolnej obliczanej na podstawie zawartości plików. Suma ta byłaby również zapisana na serwerze. Jeśli ktoś będzie kombinował w plikach, to podczas łączenia się z serwerem wyjdzie, że sumy kontrolne się różnią.