Krotki link chroniony haslem to krotki URL, ktory prosi o haslo, zanim przes. kogokolwiek dalej. Otwierasz link, trafasz na mala strone posrednia zamiast na cel, wpisujesz haslo i dopiero wtedy uruchamia sie przekierowanie. Podaj bledne haslo i pozostaniesz na monicie. Cel nigdy nie jest ujawniany, dopoki sprawdzenie nie przejdzie.
To caly pomysl i warto byc co do tego precyzyjnym, bo nazwa zbyt wiele obiecuje. Bramka hasla to utrudnienie dostepu przed linkiem. To nie szyfrowanie strony za linkiem. To sa rozne gwarancje i mylenie ich jest tym, jak ludzie pozniej sa zaskoczeni. Ten artykul opisuje, do czego nadaje sie bramka, jakie przypadki uzycia naprawde pasuja, jak sprawdzenie dziala przy przekierowaniu, gdzie konczy sie bezpieczenstwo i z czym to laczyc, aby calosc sie trzymala.
Do czego sluzy krotki link chroniony haslem#
Uzyteczne przypadki maja wspolny ksztalt: udostepniasz link przez kanal, ktory nie jest pod Twoja pelna kontrola, i chcesz, aby do wejscia potrzebna byla druga rzecz poza URL.
Wrazliwy dokument to oczywisty przyklad. Wysylasz projekt umowy, model finansowy lub wewnetrzna prezentacje komus spoza firmy. E-maile sa przekazywane dalej. PDF-y sa przesylane. Krotki link, ktory moze otworzyc kazdy z URL, jest tak prywatny, jak najmniej ostrozna osoba, ktora go kiedykolwiek posiadala. Dodaj haslo, a przypadkowe przekazanie nie oznacza automatycznego dostepu.
Dostawy dla klientow to ten sam wzorzec z doliczona datalim. Agencja przekazuje partia zasobow, edycje wideo, raport kampanijny. Klient powinien je osiagnac, cala ksiazka adresowa klienta - nie. Chroniony URL trzyma dostarczone materialy za wspolnym sekretem, ktory ustawiasz przy tworzeniu linku.
Prywatne kampanie i tresci gated dopelniaja liste. Strona docelowa przed premiera, ktorej chcesz pokazac malej grupie. Oferta wczesnego dostepu dla listy oczekujacych. Zasob tylko dla czlonkow, gdzie odbiorcy maja juz haslo z innego miejsca. W kazdym przypadku link podrozuje przez e-mail lub czat, a haslo rozroznia "zostalo mi to przekazane" od "natknelem sie na to przypadkowo."
Co nie pasuje: cokolwiek naprawde tajnego, cokolwiek regulowanego, cokolwiek, gdzie wyciek to zdarzenie raportowalne. Dla tych przypadkow wspolne haslo linku jest zbyt prymitywne. Chcesz uwierzytelniania per osoba na samym celu, co jest inna kontrola, do ktorej wroce.
Jak dziala bramka hasla przy przekierowaniu#
Oto czesc mechaniczna, bo kolejnosc operacji decyduje o tym, czy bramka ma sens.
Normalny krotki link to przekierowanie. Krawedz wyszukuje slug, znajduje cel i pisze 302 do przegladarki odwiedzajacego. Szybkie, bezstanowe, bez pytan. Krotki link chroniony haslem wstawia jeden krok przed przekierowaniem: krawedz widzi, ze link ma ustawione haslo, wiec zamiast przekierowac, zwraca wyzwanie. Odwiedzajacy otrzymuje strone posrednia z prosba o haslo. Podaje je. Podana wartosc jest sprawdzana wzgledem przechowywanego hasza. Jesli pasuje, przekierowanie nastepuje. Jesli nie - pozostaje na monicie, a docelowy URL nigdy nie jest wysylany do jego przegladarki.
Dwa szczegoly maja znaczenie dla tego, czy to cos warte.
Po pierwsze, haslo jest haszowane, nigdy nie jest przechowywane w postaci zwyklego tekstu. Przechowywany sekret linku powinien byc hashem jednokierunkowym, tak aby odczyt bazy danych nie oddal atakujacemu wszystkich hasel linkow w systemie. Argon2id to aktualne zalecenie dla haszowania hasel i to jest to, czego Elido uzywa do hasel linkow, z weryfikacja wykonywana w procesie przy uzyciu porownania w stalym czasie, tak aby samo sprawdzenie nie wycieka informacji przez timing. API dla linku nigdy nie zwraca haszu; zwraca wartosc logiczna mowiaca, czy haslo jest ustawione. Odwiedzajacy trafiajacy na chroniony link otrzymuje 401 z flagą password_required i tokenem wyzwania i musi przeslac prawidlowe haslo w kolejnym zadaniu, zanim nastapi przekierowanie. Mechanika przechowywania jest opisana na liscie kontrolnej bezpieczenstwa skracacza URL, w sekcji o ochronie haslem per link.
Po drugie, sprawdzenie nastepuje przed ujawnieniem celu. Brzmi to oczywiscie, ale zaskakujaca liczba "prywatnych" schematow linkow ujawnia cel w kodzie po stronie klienta lub w lancuchu przekierowan, ktory zdeterminowany odwiedzajacy moze odczytac z sieci. Sedno wykonywania sprawdzenia przy przekierowaniu, po stronie serwera, polega na tym, ze docelowy URL pozostaje na serwerze, az haslo bedzie prawidlowe. Jesli widziałes bramke zaimplementowana jako JavaScript pobierajacy prawdziwy URL, a nastepnie przekierowujacy, widziałes bramke, przez ktora kazdy z narzędziami deweloperskimi przegladarki moze przejsc. Ewaluacja po stronie serwera to roznica - to samo rozumowanie, ktore sprawia, ze inteligentne linki trasuja na krawedzi, a nie w shim JS na stronie docelowej.
Limity bezpieczenstwa, powiedziane wprost#
To sekcja, ktora ludzie pomijaja, a potem zaluja, wiec jest w srodku, gdzie trudno ja przeoczyc.
Bramka hasla chroni krotki link. Nie chroni celu. Jesli cel to publiczny URL, do ktorego kazdy moze dotrzec wpisujac go bezposrednio, to haslo zatrzymuje jedynie osoby majace krotki link, nie tych, ktory moga odgadnac lub przypadkowo znalezc sie na stronie podlezajacej. Bramka podnosi poprzecze dla typowego przypadku udostepniania, gdy wszystko, co ktos ma, to krotki URL. Nic nie robi dla celu, ktory jest juz ujawniony.
Wiec zasada jest prosta: cel rowniez powinien miec kontrole dostepu. Dokument za krotkim linkiem chronionym haslem powinien rowniez znajdowac sie w miejscu, ktore sprawdza, kim jestes, a nie tylko w miejscu, ktore ma dluga, niemozliwa do odgadniecia sciezke. OWASP Authentication Cheat Sheet i towarzyszace wskazowki dotyczace kontroli dostepu to odwolania: uwierzytelnianie dowodzi, kim jest ktos, kontrola dostepu decyduje, do czego moze dotrzec, a wspolne haslo linku to slaba forma pierwszego, ktora nie mowi nic o drugim. Uzyj go jako warstwy wygody, a nie jako jedynej bariery miedzy atakujacym a regulowanymi danymi.
Kilka bardziej uczciwych ograniczen.
Wspolne haslo jest wspolne. Kazdy, kto je ma, ma ta sama tozsamosc dla bramki. Nie ma sladu per osobe o tym, kto otworzyl link, nie ma sposobu odwolania dostepu jednej osoby bez zmiany hasla dla wszystkich. Jesli musisz wiedziec, ze to Danuta konkretnie otworzyła dostarczone materialy, wspolne haslo linku Ci tego nie powie.
Link powinien byc obslugiwany przez HTTPS, zawsze. Haslo przes. przez zwykly HTTP jest haslem wyslanym otwartym tekstem do kazdego na sciezce sieciowej. Szyfrowanie transportu to minimum, nie funkcja; przeglad HTTPS Mozilli wyjasnia dlaczego. Elido domyslnie obsluguje przekierowania przez HTTPS, lacznie z domenami niestandardowymi, ale zasada obowiazuje wszezie, gdzie ustawiasz bramke.
A haslo nie zastepuje wygasania. Link, ktory pozostaje aktywny wiecznie, to zobowiazanie niezaleznie od tego, czy ma haslo, bo sekret powoli wycieka w miare wklejania go w coraz wiecej miejsc. Polacz bramke z czasem zycia.
Z czym to laczyc#
Bramka hasla to jedna kontrola. Dziala najlepiej w polaczeniu z innymi, ktore pokrywaja to, czego nie moze.
Wygasanie i limity maksymalnych klikniec ograniczaja link w czasie i uzyciu. Ustaw expires_at, aby dostawa dla klienta wygasla po zakonczeniu wspolpracy, oraz limit maksymalnych klikniec, aby link do jednorazowego pobierania dezaktywowal sie po jednokrotnym otwarciu. Oba sa egzekwowane przy przekierowaniu, zanim zostanie zarejestrowane jakiekolwiek zdarzenie klikniecia, co oznacza, ze proba blednego hasla dla juz wygaslego linku nigdy nie dociera do bramki. Kompromisy dotyczace czasu zycia sa omawiane w artykule wygasanie linkow i linki samozniszczajace.
Limity IP lub geograficzne zawezaja to, kto w ogole moze probowac bramki. Jesli dostawa dla klienta jest otwierana tylko z jednego biura, ograniczenie linku do tego zakresu oznacza, ze wyciekle haslo plus wyciekly link i tak nie dziala skadkolwiek indziej. Kontrole na poziomie regionu sa opisane w artykule krotkie linki z geolockowaniem, a lacza sie z haslem, nie zastepujac go.
Dla zespolow wlasciwa odpowiedz zazwyczaj to wcale nie wspolne haslo. To SSO. Gdy osoby, ktore powinny miec dostep do linku, to pracownicy w Twoim dostawcy tozsamosci, zabezpiecz cel przez SCIM i SSO, tak aby dostep podazal za katalogiem: ktos opuszcza firme, jego dostep znika, bez potrzeby rotacji hasla. Wspolne haslo linku jest dla ad-hoc zewnetrznego udostepniania; dostep zarzadzany przez katalog jest dla wszystkiego, gdzie potrzebujesz odwolywania per osoba. Przewodnik konfiguracji SCIM i SSO przeprowadza przez konfiguracje, a strona rozwiazan dla przedsiebiorstw opisuje, gdzie to pasuje.
Ogolna zasada to obrona warstwami. Zadna z tych kontroli nie jest silna sama w sobie. Haslo zatrzymuje przypadkowy dostep, wygasanie ogranicza okno, HTTPS chroni siec, kontrola dostepu do celu chroni tresc, a SSO obsluguje przypadek zespolowy. Stosuj te, ktore sa potrzebne w Twojej sytuacji.
Jak to zrobic w praktyce#
Jesli chcesz zabezpieczyc link, ksztalt pracy jest taki sam niezaleznie od narzedzia.
Ustaw haslo podczas tworzenia lub edytowania linku. Ustawienia linku powinny pozwolic Ci dolacz haslo; gdy jest ustawione, link przestaje byc zwyklym przekierowaniem i zaczyna zwracac wyzwanie. Wybierz haslo, ktore nie jest trywidialnie do odgadniecia i nie jest ponownie uzyte z innego miejsca, bo wspolny sekret, ktory odblokowuje rowniez Twoj e-mail, to zly wspolny sekret.
Udostepnij link i haslo oddzielnymi kanalami. To nawyk o najwyzszej wartosci. Wyslij krotki link w e-mailu lub dokumencie, a haslo przez wiadomosc czat, oddzielny e-mail lub krotka rozmowe. Jesli oboje podrozuja razem w tej samej wiadomosci, jedna przechwycona wiadomosc oddaje wszystko, a bramka nic Ci nie dala. Rozdzielenie ich oznacza, ze atakujacy potrzebuje dwoch kanalow, a nie jednego.
Jednoczesnie ustaw wygasanie. Zdecyduj z gory, jak dlugo link powinien zyc i czy powinien sie deaktywowac po znznej liczbie otwarc, i ustaw to przy tworzeniu, zamiast obiecywac sobie, ze posprzatasz pozniej. Nie posprzatasz.
Zweryfikuj, czy cel ma wlasna kontrole dostepu, jesli tresc jest wrazliwa. Bramka spenia swoje zadanie dla przypadku udostepniania. Jesli podstawowy dokument musi rowniez odpierac kogos, kto odgaduje URL, ta ochrona musi byc na celu, nie na krotkim linku. Dla pelniejszego omowienia, jak te elementy pasuja do modelu zagrozen, czy skracacze URL sa bezpieczne opisuje szerszy obraz, a strona zaufania opisuje postepowanie Elido.
To uczciwa wersja krotkich linkow chronionych haslem. Sa uzytecznym, niskonaklodowym sposobem na to, aby wspolny URL nie byl otwarty dla kazdego, kto go przypadkowo otrzyma. Nie sa skarbcem. Uzywane jako jedna warstwa w stosie, z wygasaniem i prawidlowo zabezpieczonym celem, robia dokladnie to, co powinny. Uzywane jako jedyna rzecz stojaca miedzy atakujacym a czyms waznym, zawodza. Ustaw bramke, podziel kanaly, ogranicz czas zycia i zablokuj cel, a masz przeplyw udostepniania, ktory sie utrzymuje.
Jesli chcesz zobaczyc, ktore kontrole sa na ktorym planie, strona cenowa je wymienia, a funkcja domen niestandardowych opisuje obsluge chronionych linkow we wlasnej markowej domenie przez HTTPS. Konfiguracja jest opisana w artykule jak skonfigurowac markowe krotkie linki.