Najważniejsze
Wybór profilu przeglądarki jest teraz konfigurowany dla każdego requestu. Podaj wybraną przeglądarkę i system operacyjny, a fingerprint oraz headers będą z nimi w pełni zgodne. W tym tygodniu Single nauczył się omijać dwa kolejne zabezpieczenia (SG-Captcha od SiteGround i wyzwanie Argon2 od eBay) bez uruchamiania przeglądarki (Browser). Widok Activity w Dashboardzie rejestruje teraz to, o co prosiłeś, a nie wewnętrzne procesy, które to obsłużyły.
Nowości
Wybór profilu przeglądarki dla każdego requestu
Do tej pory unblocker: true dobierał jedną sygnaturę (naszą aktualnie domyślną) i na tym koniec. Teraz możesz wskazać konkretną:
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
lub zażądaj pary przeglądarki i OS:
{ "url": "https://example.com", "unblocker": true, "browser": "Chrome", "os": "Windows 10" }
API odrzuca nieznane kombinacje po nazwie i podaje to, co JEST dostępne, więc literówka nie spowoduje po cichu wysłania sygnatury, o którą nigdy nie proszono.
Pełny katalog znajduje się pod GET /api/profiles. Jest publiczny (nie wymaga klucza), ponieważ jest to lista możliwości, a nie tajemnica. W chwili pisania tego tekstu dostępnych jest 79 gotowych profili dla Chrome, Firefox, Edge, Safari i Tor na systemy Windows, macOS, Android i iOS. Playground czyta z tej samej listy, więc rozwijane menu zawsze pokazuje dokładnie to, o co może poprosić Twój kod.
Dlaczego to ważne: jeśli Twój cel profiluje żądania na podstawie systemu operacyjnego lub Twój zespół przeprowadza testy A/B, który stos technologii przechodzi przez konkretną blokadę, to teraz możesz trzymać tę zmienną na stałym poziomie, podczas gdy wszystko inne się zmienia.
Single przechodzi przez SG-Captcha i dowód pracy eBay
Dwa zabezpieczenia, które wcześniej wymuszały przejście przez Browser, teraz przechodzą w trybie Single. eBay wysyła własne wyzwanie typu proof-of-work (łamigłówka Argon2), a SiteGround chroni część współdzielonego hostingu w sieci za pomocą SG-Captcha. Oba rozwiązują się bez renderowania, co oznacza, że odpowiedź wraca w postaci pojedynczego żądania HTTP i jest odpowiednio wyceniana.
Sygnał obrony w odpowiedziach również wzrósł. Odpowiedzi z Browser przenoszą teraz defenses: { present, cleared }, dzięki czemu możesz sprawdzić, który dostawca stał przed stroną i czy udało nam się przejść. Fakturowanie przebiega zgodnie z tą samą regułą: każdy dostawca, którego pokonamy, jest przypisywany, niezależnie od tego, jaka to była marka. Cloudflare było jedynym płatnym rozwiązaniem przed tym okresem. Akamai Bot Manager, SG-Captcha i wyzwanie eBay teraz znajdują się obok niego.
Widok aktywności przebudowany w Dashboardzie
Dwie kolumny na liście aktywności Dashboardu pokazywały coś niewłaściwego. Metoda HTTP zawsze odczytywała POST w każdym rzędzie (wszystkie nasze endpointy to POST, więc kolumna była stałą, która niczego nie mówiła). Natomiast adres IP klienta w wywołaniach Playground rejestrował, skąd wołał Playground, a nie osobę klikającą Run.
Oba problemy zostały naprawione. Kolumna z metodą odczytuje teraz czasownik, który wysłano w treści żądania. Adres IP klienta w rzędach Playground wskazuje teraz na adres IP przeglądarki zalogowanego użytkownika, przenoszony w podpisanym tokenie Playground, więc klient API nie może go sfałszować.
Reszta widoku została przebudowana przy okazji. Tabela mieści się na laptopie bez ukrywania kolumn, kolumna produktu składa się do linii żądania, a panel szczegółów zyskał zakładki, dzięki czemu żądanie, odpowiedź i podsumowanie obrony mają własne paski przewijania.
Rozliczenia: 3D Secure przy zmianie planu
Jeśli wydawca Twojej karty wymagał potwierdzenia 3DS w celu zmiany planu (nie tylko przy początkowej subskrypcji), ten krok nie uruchamiał się, a zmiana po cichu się cofała. Teraz działa. Jeśli próbowałeś zmienić plany w zeszłym miesiącu i wyglądało to tak, jakby nic się nie stało, to właśnie dlatego.
Pod Maską
Playground odmawia zbudowania nagłówka odpowiedzi z danych pobranej strony (kategoria błędów typu header-injection, którą wcześnie wyłapaliśmy). Endpoint rozliczeniowy na Dashboardzie przed udzieleniem odpowiedzi sprawdza, czy strona wywołująca posiada zasób, zamykając w ten sposób ścieżkę IDOR.
Sam pipeline wdrożeniowy przeszedł tydzień intensywnych poprawek po awarii z szóstego, która w połowie budowania zapełniła dysk hosta. Każdy serwis odmawia budowania bez wolnej przestrzeni dyskowej, wdrożenia serializują się zamiast wchodzić w race condition, gateway działa stabilnie, gdy backend jest niestabilny, a serwisy faktycznie kończą działanie po otrzymaniu SIGTERM, zamiast zawieszać się do czasu ich zabicia trzydzieści sekund później.
Przez długi czas to my decydowaliśmy za Ciebie o wyborze sygnatury przeglądarki. Wcale nie musi tak być.