Czy zwracanie linku do pliku jest bezpieczne |
Czy zwracanie linku do pliku jest bezpieczne |
23.10.2018, 19:12:13
Post
#1
|
|
Grupa: Zarejestrowani Postów: 2 707 Pomógł: 290 Dołączył: 16.12.2008 Skąd: Śląsk Ostrzeżenie: (0%) |
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. Ten post edytował markonix 23.10.2018, 19:13:26 -------------------- |
|
|
23.10.2018, 22:37:09
Post
#2
|
|
Grupa: Moderatorzy Postów: 2 921 Pomógł: 269 Dołączył: 11.08.2005 Skąd: 127.0.0.1 |
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. -------------------- I would love to change the world, but they won't give me the source code.
My software never has bugs. It just develops random features. |
|
|
24.10.2018, 10:26:48
Post
#3
|
|
Grupa: Zarejestrowani Postów: 2 707 Pomógł: 290 Dołączył: 16.12.2008 Skąd: Śląsk Ostrzeżenie: (0%) |
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. -------------------- |
|
|
24.10.2018, 11:42:21
Post
#4
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%) |
Możesz użyć https://hashids.org/php/ i ustalić jakąś sól, fajnie działa i jest bardziej eleganckie niż md5
|
|
|
24.10.2018, 13:04:27
Post
#5
|
|
Grupa: Zarejestrowani Postów: 2 707 Pomógł: 290 Dołączył: 16.12.2008 Skąd: Śląsk Ostrzeżenie: (0%) |
Korzystam do robienia ładniejszych linków i żeby ukryć inkrementowanie ale chyba to nie do końca na temat albo przynajmniej nie do końca rozumiem jak to zabezpiecza assetsy i różni się od md5 (poza zmienną długością stringa).
Ten post edytował markonix 24.10.2018, 13:04:39 -------------------- |
|
|
24.10.2018, 13:30:22
Post
#6
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%) |
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. |
|
|
24.10.2018, 14:24:50
Post
#7
|
|
Grupa: Zarejestrowani Postów: 2 707 Pomógł: 290 Dołączył: 16.12.2008 Skąd: Śląsk Ostrzeżenie: (0%) |
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. -------------------- |
|
|
24.10.2018, 19:51:58
Post
#8
|
|
Grupa: Zarejestrowani Postów: 1 590 Pomógł: 185 Dołączył: 19.04.2006 Skąd: Gdańsk Ostrzeżenie: (0%) |
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ń.
|
|
|
24.10.2018, 23:16:48
Post
#9
|
|
Grupa: Zarejestrowani Postów: 2 707 Pomógł: 290 Dołączył: 16.12.2008 Skąd: Śląsk Ostrzeżenie: (0%) |
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. -------------------- |
|
|
27.10.2018, 11:51:46
Post
#10
|
|
Grupa: Zarejestrowani Postów: 1 590 Pomógł: 185 Dołączył: 19.04.2006 Skąd: Gdańsk Ostrzeżenie: (0%) |
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. |
|
|
30.10.2018, 01:13:13
Post
#11
|
|
Grupa: Zarejestrowani Postów: 2 707 Pomógł: 290 Dołączył: 16.12.2008 Skąd: Śląsk Ostrzeżenie: (0%) |
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. -------------------- |
|
|
Wersja Lo-Fi | Aktualny czas: 19.04.2024 - 20:47 |