Ograniczanie widoczności pliku SWF

Mam sytuację, w której mój główny plik SWF ładuje wiele zewnętrznych plików SWF. Jednak te zewnętrzne pliki SWF znajdują się w publicznym folderze serwera WWW.Ograniczanie widoczności pliku SWF

Czy można ograniczyć widoczność SWF tylko do mojego głównego pliku SWF (takiego, który ładuje zewnętrzne pliki SWF). W obecnym stanie każdy użytkownik, który wie, gdzie szukać, może po prostu wpisać adres URL i przejść do plików SWF, nie wspominając o botach, które nie podążają za plikiem robots.txt.

Powód jest bardzo prosty. Użytkownicy otrzymują nazwę użytkownika/hasło, aby zalogować się do głównej aplikacji Flash, a główna aplikacja Flash z kolei ładuje pliki SWF i TYLKO wtedy są one dostępne dla użytkownika. Ponadto, w zależności od tego, kto jest zalogowanym użytkownikiem, niektóre pliki SWF są ograniczone i nie są ładowane.

Dzięki za pomoc!

Źródło

2010-03-07 helloworlder

Nie jestem zaznajomiony z Flash, więc nie wiem, jakie są możliwości tego Flasha, ale można to rozwiązać, wykonując logowanie w języku po stronie serwera, takim jak PHP lub ASP. Logowanie tworzy sesję, a ważna sesja będzie warunkiem dostarczenia kolejnych plików. –

Dzięki Pekka. Rozwijałem ten pomysł, ale jestem prawie pewien, że Flash może ładować zasoby zewnętrzne (w tym pliki SWF), żądając adresu URL (pliki SWF nie mogą być dostarczane * na * to). Jeśli true, Flash nigdy nie będzie w stanie osiągnąć PFM, jeśli są one w jakikolwiek sposób chronione. – helloworlder

Po prostu kolejna myśl. Czy nie można zapobiec umieszczaniu katalogu w katalogu przez modyfikację .htacess? Nie można go wyświetlić, ale nadal możesz otwierać pliki, jeśli znasz dokładną nazwę. Być może jest możliwe, aby nazwa była niemożliwa * do uzyskania przez dodanie skrótu do końca nazwy pliku. * praktycznie niemożliwe – helloworlder

Zależy od tego, jak flash jest uwierzytelniany. Flash musi uwierzytelnić się za pomocą aplikacji po stronie serwera z bazą danych. Aplikacja po stronie serwera może następnie użyć bazy danych do wykonywania kontroli dostępu dla poszczególnych plików.

Wszystko files powinny być śledzone przez tabeli, zawiera kolumny, takie jak lokalne path do pliku, jak również user_group a może user_id. Sesja uwierzytelniona powinna śledzić numer user_id po zalogowaniu się przy użyciu nazwy użytkownika i hasła.

Pajacyki ataku używają pliku robots.txt przeciwko tobie, jeśli umieścisz te ścieżki plików w pliku robots.txt, lepiej będzie, jeśli zapiszesz je i przekażesz je atakującemu.

Bardzo łatwo jest dekompilować aplikacje flashowe i modyfikować je. Nie polegaj na systemach bezpieczeństwa "po stronie klienta", są one bardzo łatwe do ominięcia. Osoba atakująca może również odtwarzać i modyfikować żądania HTTP za pomocą danych o manipulacji.Potrzebujesz serwera, aby poinformować klienta o dostępnych plikach.

Źródło

2010-03-07 17:59:38 rook

Cześć, dziękuję za odpowiedź! Myślałem o użyciu takiej metody, ale problem polega na tym, że jeśli zewnętrzne pliki SWF znajdują się w chronionym katalogu, tj. Nie są publicznie widoczne, Flash nie będzie mógł ich załadować, prawda? Myślę, że głównym problemem jest to, że nie można przekazywać obiektów SWF do aplikacji Flash. Tylko aplikacja Flash może ładować obiekty SWF, odwołując się do rzeczywistego adresu URL. Więc może to nie jest możliwe? :-( – helloworlder

Cóż, jeśli nie jest to możliwe, będę musiał dojść do jakiegoś kompromisu. Problem praw autorskich dotyczący plików SWF jest nieco skomplikowany, ale taki jest charakter wymagań biznesowych: Jeśli jest to kompromis w zakresie bezpieczeństwa, to mam aby wyjaśnić to mojemu klientowi, może być inny sposób, aby przejść do innej strony, ale może mogę zamienić go w aplikację komputerową AIR, a użytkownicy zalogują się do aplikacji internetowej i zobaczą pliki "należących do" plików SWF do pobrania. Pobierają te pliki SWF z serwera na komputer, aby aplikacja AIR mogła uzyskać dostęp do tych plików. – helloworlder

zależności od sposobu bezpiecznego chcesz być, mogę myśleć o kilka opcji:

Skrypt po stronie serwera, aby kontrolować dostarczanie swoim sub-PFM (jak Pekka zasugerował powyżej).
Jeśli chcesz zrobić wszystko po stronie klienta, można umieścić test warunkowa w każdej sub-swf, więc będą grać tylko od wewnątrz głównego SWF:

Coś if(this.parent.toString() != "mainSwf") { stop();} (w Pseudokod).

To nie jest niezawodny, ponieważ ktoś mógłby łatwo stworzyć własnego rodzica o nazwie "mainSwf", ale odstraszałoby to zwykłe przeglądanie pod-plików SWF. Przynajmniej dopóki ktoś ich nie zlikwiduje ...

Można nieco utrudnić działanie, ustawiając właściwość w głównym swf, na przykład var myKey:String="362574036704ry3f0y3432607", a następnie użyj warunku, aby przetestować: if(this.parent.myKey != "362574036704ry3f0y3432607") { stop();}.

Parapet nie jest strasznie bezpieczny. Mam nadzieję że to pomoże.

EDIT:

Istnieje również podobne pytanie here, które mogłyby mieć użytecznych odpowiedzi.

Źródło

2010-03-07 16:12:49

-1 Nie możesz zaproponować luki w SO, szczególnie jeśli znasz jej podatność na atak. Dekompilowanie pamięci flash lub odtwarzanie żądań GET za pomocą danych o nieuprawnionej manipulacji może ominąć system zabezpieczeń po stronie klienta. – rook

@ The Rook: Hehe, na pewno przeczytam FAQ jeszcze ostrożniej następnym razem! Ale daj mi znać, jak myślisz, że GEN Sniffing złamie tę metodę. I tak, czasami rozwiązanie po stronie serwera nie jest możliwe z innych powodów ... zgadnijmy, że żyjemy w niedoskonałym świecie. :) –

Odpowiedz

Powiązane problemy