Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Czy zwracanie linku do pliku jest bezpieczne
Forum PHP.pl > Forum > PHP
markonix
Czy widzicie jakieś zagrożenia aby np. API zwracało bezpośredni url do pliku na dysku.
Mówię o plikach niepublicznych np. pochodzących z uploadu.

https://example.pl/upload/type/2ds8k79ikt00gapule6h.docx

Czyli zabezpieczeniem jest sama randomizacja - skoro ktoś poznał link miał do pliku dostęp, więc równie dobrze mógł do pobrać i dystrybuować poza moim portalem.
Wiem, że można zrobić metodę do pobierania za pomocą np. id pliku, z pełną autoryzacją itp. ale na serwerze jest nginx i fajnie by serwować pliki bez użycia aplikacji tylko czy niesie to jakieś zagrożenia.
Np. sprawdziłem jak FB to robi na grupie tajnej i np.
https://lookaside.fbsbx.com/file/Instrukcja...kP8JOknG6q_Fiwg
To link, który jakiś czas działał każdemu, nawet niezalogowanym. Po jakimś czasie przestał działać. Czyli autoryzacja na ich serwerze z statycznymi zasobami jest wydzielona od autoryzacji typowo aplikacyjnej.
batman
Wszystko zależy od tego jak bardzo chcesz utrudnić życie osobom, które nie mają uprawnień do pobrania pliku. Tak naprawdę masz dwie możliwości - "losowy" link oraz stare, dobre logowanie.

W pierwszym przypadku ktoś może udostępnić link i nic z tym nie zrobisz. Co więcej, jeśli "losowy" adres można dopasować do jakiegoś wzorca, stworzenie crawlera wyciągającego wszystkie pliki to tylko kwestia czasu.

Logowanie do konta będzie wymagało jakiejś interakcji z serwerem. Na podstawie id/klucza/hasha/czegokolwiek będziesz mógł zidentyfikować plik, a następnie przepuścić go przez logowanie.

Co do Twojego przykładu z Facebookiem w tle. Na szybkiego jestem w stanie podać kilka możliwych scenariuszy:
- po pewnym czasie plik został usunięty (cron/kolejki/cokolwiek). Serwer wykrywa request do nieistniejącego pliku i przekierowuje do "skryptu" serwującego pliki. Skrypt wymaga logowania.
- plik po uploadzie automatycznie trafił do cache'u z ustawionym lifetime. Link udostępniony użytkownikowi wskazuje na cache. Po wygaśnięciu cache'u request jest przekierowany do skryptu z logowaniem
- serwer z plikami statycznymi korzysta z microservice, która weryfikuje użytkownika.
markonix
No właśnie crawlera bym się obawiał - jest to jeden folder, a wzorzec.. No korzystam np. z wbudowanego uploadera Laravelowego, a on opiera się o sumę md5 czyli o stałej długości string i zmienne rozszerzenie.
Tylko, że nie udostępniając linka i tak nie zabezpieczam się przed tym całkowicie - jeżeli ktoś pozna ścieżkę i foldery to i tak crawlera może uruchomić na tym url więc musiałbym już obowiązkowo przesunąć foldery poza public.
Pyton_000
Możesz użyć https://hashids.org/php/ i ustalić jakąś sól, fajnie działa i jest bardziej eleganckie niż md5 wink.gif
markonix
Korzystam do robienia ładniejszych linków i żeby ukryć inkrementowanie ale chyba to nie do końca na temat wink.gif albo przynajmniej nie do końca rozumiem jak to zabezpiecza assetsy i różni się od md5 (poza zmienną długością stringa).
Pyton_000
Zakładając że masz link http://domain.com/assets/image.jpg

robisz w nginx robisz route i jako entry point wstawiasz skrypt sprawdzający użytkownika czy ma dostęp. Dodatkowo możesz nałożyć na pliki cache http dzięki czemu przez pewien czas ty jako właściciel masz dostęp do zasobu bo został skeszowany w przeglądarce, a inni nie mają dostępu bo skrypt wywali 404 na zasobie.
markonix
No jak już to mam:
https://domain.com/assets/2ds8k79ikt00gapule6h.jpg
i właśnie w Twoim podejściu jedna rzecz jest troszkę słaba, gdyby to były faktycznie obrazy, powiedzmy jakaś mega duża galeria to każdy request po obrazek odpalał mi cały system, cache spoko ale dopiero przy odświeżeniu strony ale to już mało pocieszające.
Pilsener
Cytat
Czy widzicie jakieś zagrożenia
- wiele, ale moim zdaniem taka dyskusja nie ma większego sensu, po prostu nigdy nie należy udostępniać bezpośrednio przez http plików, które pochodzą od użytkownika.
Cytat
każdy request po obrazek odpalał mi cały system, cache spoko ale dopiero przy odświeżeniu strony ale to już mało pocieszające.
- bezpieczeństwo jest zawsze ważniejsze od wydajności, nikt nie każe używać całej aplikacji do pobrania pliku, ba - nikt nawet nie każe używać PHP! Robi się serwis w tym celu wyspecjalizowany, jest też wiele gotowych rozwiązań.
markonix
Cytat(Pilsener @ 24.10.2018, 20:51:58 ) *
jest też wiele gotowych rozwiązań.

Jakiego typu to rozwiązania? Na jakim poziomie?

Mój warsztat to Laravel i nginx, masz coś konkretnego?

Zerknąłem z ciekawości na zdjęcia na FB, które są prywatne.

https://scontent-waw1-1.xx.fbcdn.net/[...].jpg?_nc_ht=scontent-waw1-1.xx&oh=f76a96587a0b65929e91b39e8d4be535&oe=5C89626E

Manipulacja linkiem zwraca Bad URL timestamp lub Bad URL hash. Link jest dostępny, mogę go przekazać innej osobie (inny browser, inne IP) i działa.
Jestem ciekaw jak długo.
Pilsener
Cytat
Jakiego typu to rozwiązania? Na jakim poziomie?


Najróżniejszym, sam sobie wybierasz, co chcesz używać, w zasadzie nie interesuje Ciebie technologia tylko wymagania sprzętowe, konfiguracja, dokumentacja itp.
Pierwszy z brzegu przykład:
https://github.com/chrisiaut/pictshare

Cytat
Zerknąłem z ciekawości na zdjęcia na FB, które są prywatne.

Widocznie fb uznał, że koszt umieszczenia tych zdjęć za firewallem jest zbyt duży. Zabezpieczenie musi być adekwatne do zawartości. Poza tym jest też SEO i cele biznesowe, wg których kontent musi być udostępniony w miarę możliwości jak najbardziej - dlatego pewnie zważając za i przeciw tak to zostało zrobione.
markonix
Cytat(Pilsener @ 27.10.2018, 12:51:46 ) *
Najróżniejszym, sam sobie wybierasz, co chcesz używać, w zasadzie nie interesuje Ciebie technologia tylko wymagania sprzętowe, konfiguracja, dokumentacja itp.
Pierwszy z brzegu przykład:
https://github.com/chrisiaut/pictshare

Szczerze.. To nie widzę aby to narzędzie służyło w jakikolwiek sposób do zabezpieczenia plików (a ja o takowych cały czas piszę, nie o zdjęciach).
To tylko service to obsługi uploadu, downloadu i obróbki graficznej w locie. Zwraca krótki hash, który nadal jest podatny na atak słownikowy.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2024 Invision Power Services, Inc.