Nie tak dawno temu pisałem o podatności , która dotknęła Koa.js w 2018 roku. Byłem sfrustrowany, że musiałem uporać się z problemem z 2018 roku, kiedy data była 2022, a korzystałem z najnowszej wersji Koa. Minęły 4 lata. To długi czas. Na pewno problem już nie istnieje!? Było i nie było jednocześnie. To znaczy, że jednocześnie się myliłem i miałem rację. Oto aktualizacja poprzedniego postu, aby powiedzieć, jak:

• Niesłusznie oskarżyłem Sonatype i Dependency Track o to, że w konkretnych przypadkach nie operują informacjami o wersji
• Mogę mieć rację i jednocześnie się mylić co do luki w zabezpieczeniach

Indeks OSS zawiera informacje o wersji

Jeśli czytałeś mój poprzedni post, prawdopodobnie pamiętasz, że doszedłem do wniosku, że problem mnie nie dotyczy. Dobra wiadomość jest taka, że ​​miałem rację. Zła wiadomość jest taka, że ​​niesłusznie oskarżyłem Sonatype o brak numerów wersji w danych dostarczonych przez OSS Index do pracy z Dependency Track. Okazuje się, że mają informacje. Po prostu nie było to widoczne tam, gdzie spodziewałem się, że powinno być widoczne. Zobacz poniższy zrzut ekranu zrobiony 22.11.2022.

Jest całkiem prawdopodobne, że Dependency Track (DT) nie działa dokładnie z tym, co jest wyświetlane na powyższej stronie, ale nie chciało mi się sprawdzać, jak wyglądały dane pobierane przez DT z indeksu OSS. DT właśnie pokazał link do OSS Index, gdzie mogłem dowiedzieć się więcej. Kliknąłem i trafiłem na tę stronę.
Firma Sonatype zwróciła mi dzisiaj uwagę, że dostępne są numery wersji; Muszę szukać gdzie indziej. Rzeczywiście, jeśli zalogujesz się na swoje konto i wyszukasz Koa lub klikniesz przycisk „Zobacz szczegóły koa” na powyższym zrzucie ekranu, możesz go znaleźć. Zobacz zrzut ekranu poniżej.

Więc myliłem się. Sonatype ma informacje w bazie danych. Problem jest więc z warstwą prezentacji. Byłoby lepiej, gdyby wersje, których dotyczy problem, były wymienione na stronie, na której omawiana jest luka, abyśmy mogli zobaczyć i zweryfikować w razie potrzeby.

Niesłusznie oskarżyłem Sonatype OSS Index o brak informacji o wersji. Niesłusznie oskarżyłem także Dependency Track o gotowość do raportowania wyłącznie na podstawie nazwy zależności, jeśli informacje o wersji były niedostępne. (Nadal muszę się dowiedzieć, czy to drugie jest prawdziwe, czy fałszywe, nie sprawdzałem.)

Nie poddawaj się jeszcze! Bardziej ekscytujące kwestie do omówienia to rzeczywista luka w zabezpieczeniach i (miejmy nadzieję) nadchodzące zmiany w raporcie o lukach w OSS Index. Zacznijmy od podatności.

Skrypty między witrynami

Sonatype przypisał XSS Koa w oparciu o poniższy proces myślowy.

Koa to podmiot, który zapisuje adres URL do odpowiedzi HTML, a nie programista korzystający z Koa

Zdecydowanie rozsądne jest oczekiwanie, że programista sprawdzi poprawność podanego adresu URL, prawdopodobnie na podstawie listy dozwolonych, aby zapobiec otwartemu przekierowaniu, a nie Koa, ponieważ Koa nie miałby pojęcia, które adresy URL chcesz zezwolić, a nie. Jednak jako programista nie sądzę, żebym musiał się martwić o oczyszczanie XSS dla adresu URL, który przekazuję do metody redirect() .

Wydaje się, że Koa troszczy się o XSS w tym kontekście, ponieważ mają już tam kod, aby temu zapobiec, jednostka HTML kodująca adres URL podczas zapisywania go w kodzie HTML

Poniekąd się zgadzam. Nie zgadzam się z następującym np.

Nie sądzę, żebym musiał się martwić o wykonanie sanityzacji XSS dla adresu URL, który przekazuję do metody redirect()

Jeśli przekażesz prawidłowy, bezpieczny adres URL do metody przekierowania, którą podałeś (programista), nie musisz się martwić o XSS (oczywiście). Jeśli przekazujesz w całości lub częściowo dane dostarczone przez użytkownika, zawsze musisz się o to martwić, niezależnie od tego, czy jesteś programistą, czy specjalistą ds. bezpieczeństwa. Mimo to oczekiwanie, że Koa pomoże programiście, nie jest naciągane.

Pozwólcie, że podam doskonały przykład, który, mam nadzieję, pomoże zrozumieć, skąd pochodzę. W poniższym przykładzie przekazuję dane dostarczone przez użytkownika z powrotem do przeglądarki w treści odpowiedzi. Robię to bez sprawdzania poprawności, sanityzacji lub kodowania.

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.body = ctx.query.payload;
});

app.listen(4444);

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=<img%20src=x%20onerror=alert(1)> HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 28
< Date: Wed, 23 Nov 2022 10:59:17 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
<img src=x onerror=alert(1)>%

• Pomyśl o tym, co i jak przekazuję do przeglądarki w treści odpowiedzi
• Rozważ (i prawdopodobnie najlepiej kontrolować jawnie!) wartość nagłówka Content-Type dla odpowiedzi
• Wiedz, że Koa domyślnie automatycznie dostosowuje wartość nagłówka Content-Type na podstawie wartości przekazanej do ctx.body. (Spróbuj na przykład przekazać aaai zobacz, jak to się zmieni)

Biorąc pod uwagę powyższy ctx.bodyprzykład „XSS”, wygląda na to, że obwiniamy Koa za wdrożenie określonych środków zapobiegających katastrofie podczas korzystania z domeny ctx.redirect(). Cytując ponownie Sonatype:

Koa wydaje się troszczyć o XSS w tym kontekście, ponieważ mają już tam kod.

Czy to oznacza, że ​​gdyby Koa nie dbał o XSS w tym kontekście, podobnie jak nie dbał (i nie powinien) o to, jeśli chodzi o ctx.body, nikt nie zgłosiłby tego jako luki w zabezpieczeniach XSS? To całkiem zabawne. Zauważyłem pewne podobieństwa z moją wcześniejszą analizą Formidable udokumentowaną tutaj i tutaj .

Powiedziawszy wszystko, co powiedziałem do tej pory, zdarza się, że XSS tam jest… i nie w tym samym czasie. Jak to możliwe? Prosty! Jest, ale nie możesz go wykorzystać, chyba że:

1. Ofiara używa starej przeglądarki internetowej ORAZ
2. Deweloper zaimplementował otwarte przekierowanie za pomocą ctx.redirect()AND
3. Deweloper całkowicie ufa wszystkim danym dostarczonym przez użytkownika i przekazuje je dosłowniectx.redirect()

Strona raportu Sonatype mówiła, jak widać na dzisiejszym zrzucie ekranu, „Otwórz przekierowanie prowadzące do skryptów międzywitrynowych”. Mój poprzedni post zakwestionował część „otwórz przekierowanie”:

Przede wszystkim nie było otwartego przekierowania. Jest otwarty tylko wtedy, gdy go otworzysz, a różnica między dwoma PoC (oryginalnym i moim) wyraźnie to pokazuje.

Sonatype zgadza się również, że Koa nie ponosi odpowiedzialności za zapobieganie otwartym przekierowaniom. Ich zmartwieniem, moim zmartwieniem i głównym zmartwieniem wszystkich innych był XSS. Włączenie otwartego przekierowania było po prostu mylące. Jednocześnie nie było to technicznie nierozsądne, jak zobaczymy później. (Wpłynie to również na ocenę luk w zabezpieczeniach).

Jak wspomniano wcześniej, skuteczne wykorzystanie zachowania Koa wymaga otwartego przekierowania. Ale:

• Koa nie ponosi odpowiedzialności za zapobieganie otwartym przekierowaniom (zgodnie z wcześniejszymi ustaleniami)
• Koa nie uruchomi ctx.redirect()się bez zgody dewelopera
• Koa nie zmusza programistów do korzystania z przekierowań

Jest więc jeszcze jedna warstwa ochrony: przypadki użycia. Jakie jest prawdopodobieństwo, że programista nie chciałby mieć kontroli nad tym, gdzie przeglądarka jest przekierowywana? Bardzo mało prawdopodobne. Oznacza to, że najprawdopodobniej programiści będą przekazywać dane kontrolowane przez użytkownika do ctx.redirect()dołączonego do innego fragmentu łańcucha. Tak więc najprawdopodobniej wydarzy się coś podobnego do poniższych przykładów:

ctx.redirect(`http://website.example.org/search?q=${userInput}`);
ctx.redirect(`/search?topic=${userInput}`);

Ocena podatności

Muszą być spełnione trzy (3) warunki, aby błąd można było wykorzystać, jak omówiono na końcu poprzedniej sekcji.

• To, jaka wersja przeglądarki jest używana, zależy od użytkownika końcowego
• Użycie metody przekierowania i sposób jej wykorzystania zależy od programisty

Należy również podkreślić, że wektorem ataku jest użycie metody przekierowania w sposób niezabezpieczony. Do udanej eksploatacji wymagany jest wektor ataku. Koa nie zapewnia wektora ataku; deweloper robi.

Skorelujmy to z definicją „luki w oprogramowaniu” podaną przez NIST:

Część, którą chciałbym podkreślić, to „można wykorzystać”. Weź Koa jako bibliotekę oprogramowania. Czy możesz to wykorzystać bez uprzedniego stworzenia wymaganego wektora ataku? Nie. Tak więc z perspektywy biblioteki oprogramowania Koa nie przedstawiono wektora ataku; bez tego eksploatacja jest niemożliwa. Gdybyśmy interpretowali tę definicję ściśle (co ja robię), nie moglibyśmy nazwać zachowania Koa luką w zabezpieczeniach.
Spróbujmy obliczyć wynik CVSS bez wektora ataku:

Nie ma wyniku, jeśli nie ma wektora ataku. Powiedziałbym, że jest to zgodne z definicją luki w oprogramowaniu podaną przez NIST.
Poeksperymentujmy i stwórzmy wyimaginowany scenariusz, w którym istnieje wektor ataku.

Nadal istnieje kilka problemów, innych niż wyimaginowany wektor ataku. Złożoność ataku została ustawiona na Wysoka, ponieważ udana eksploatacja wymaga starej przeglądarki. Osoba atakująca musi przekonać ofiary do pobrania i zainstalowania starej przeglądarki.
W tym sensie wymagana jest interakcja użytkownika, mimo że podstawowe wskaźniki interakcji użytkownika tak naprawdę nie dotyczą tego. W tym scenariuszu to, czy wykorzystanie XSS wymaga interakcji użytkownika, zależy od tego, w jaki sposób aplikacja internetowa używa przekierowań, a nie od Koa. Warto również wspomnieć, że wstrzyknięty JavaScript nie działałby samodzielnie, ponieważ wymagał przede wszystkim interakcji użytkownika: kliknięcia łącza w odpowiedzi HTML.

Co więc możemy zrobić, aby wymusić ocenę podatności na to? Musimy coś wybrać. Myślenie życzeniowe, zakładając najgorsze, co wolisz. Jedno jest pewne, robisz obliczenia, których nie powinieneś robić w pierwszej kolejności, a wynik jest tak daleki od rzeczywistości, że nawet nie mogę znaleźć na to słów.

Następną ważną rzeczą są wskaźniki wpływu. Musisz wiedzieć, jaki wpływ ma aplikacja internetowa. Ale nie obliczamy oceny podatności aplikacji internetowej… Biorąc pod uwagę kontekst, ten XSS ma zerowy wpływ na Koa. Koa nie zajmuje się ani nie przetwarza samodzielnie informacji poufnych. Błąd nie ma wpływu na dostępność ani integralność. To pozostawia nam końcowy wynik 0,0, nawet po wymuszeniu wektora ataku w obliczeniach.

Pytanie brzmi: czy przedstawiamy fakty, czy fikcję?

Firma Sonatype zwróciła moją uwagę na oficjalne wytyczne dotyczące oceniania luk w bibliotekach oprogramowania , które zostały wydane w 2019 r. wraz z CVSSv3.1. Przyznam, że nie wiedziałem o tym, co jest zarówno dobre, jak i złe. Dobrze, bo zaowocowałoby to postem tyradowym, źle, bo może gdybym zobaczył to wcześniej, straciłbym całą nadzieję, zanim włożyłbym tyle wysiłku w wyjaśnienie, że to nie jest właściwy sposób. Co zatem mówią oficjalne wytyczne?

Oceniając wpływ luki w bibliotece… Analityk powinien ocenić rozsądnie najgorszy scenariusz implementacji. Jeśli to możliwe, informacje CVSS powinny wyszczególniać te założenia.

Odpowiedź jest więc taka, że ​​ocena podatności na zagrożenia jest oparta na fikcji.

Ponadto, co to jest „ rozsądny najgorszy scenariusz wdrożenia”? Gdybyśmy przeanalizowali wiele projektów wykorzystujących Koa i stwierdzili, że większość programistów zaimplementowała otwarte przekierowania przy użyciu ctx.redirect()metody Koa, rozsądne może być założenie najgorszego. Zrobiłem szybkie wyszukiwanie kodu w projektach JavaScript ctx.redirect(na GitHub. Otrzymałem 16 827 wyników kodu. Wyszukując context.redirect(otrzymałem 15 751 kodów wyników. Oznaczałoby to 32 578 wyników kodu do przeanalizowania. Niektóre z nich będą używać Koa, niektóre Express, a niektóre mogą być czymś innym. (Oczywiście kontekst można nazwać dowolną nazwą, nie tylko ctxlub context, więc może być jeszcze więcej kodu do przejrzenia).

Pytanie brzmi: czy przekazywanie danych dostarczonych przez użytkownika bezmyślnie w celu przekierowania jest tak powszechne? Przyjąłem półautomatyczne podejście do analizy, pisząc mały skrypt, aby sprawdzić wszystkie projekty pasujące do kryteriów wyszukiwania. Niestety, nie mogłem przekroczyć pierwszych 1000 trafień, ponieważ GitHub odrzucił kolejne żądania:

{
    "message":"Only the first 1000 search results are available",
    "documentation_url":"https://docs.github.com/v3/search/"
}

Na podstawie tego, co widziałem i biorąc pod uwagę to, co zostało omówione w następnej sekcji („Stara przeglądarka internetowa”), nie sądzę, aby zakładanie najgorszego scenariusza byłoby rozsądne. Nie w tym konkretnym przypadku.

Oficjalne wytyczne mówią również, że:

Podczas oceniania luki w danej implementacji przy użyciu biblioteki, której dotyczy problem, należy ponownie obliczyć ocenę dla tej konkretnej implementacji.

Jest to rozsądne i do pewnego stopnia łagodzi aspekt science-fiction sytuacji. W ten sposób ten problem z Koa, z oceną podatności 9,8, w naszym przypadku wyniósł 0,0.

Dobrą rzeczą jest to, że Sonatype zgodził się, że ocena podatności 9,8 była nieuzasadniona i są gotowi ją obniżyć. Doceniam to i pewnie wielu innych też.

Ponadto firma Sonatype powiedziała mi, że kiedy dodali ten problem do swojego systemu, uznali, że najlepiej będzie, jeśli ich klienci dowiedzą się o tej potencjalnie nieoczekiwanej sytuacji. Powiedzieli: „lepiej było zaalarmować niż zignorować to, co widzieliśmy i potencjalnie mieć negatywny wynik”. I oczywiście mieli rację.

Nigdy nie kwestionowałem, czy kwestie bezpieczeństwa powinny być komunikowane, czy nie. Tak, kwestie bezpieczeństwa muszą być widoczne. Martwi mnie sposób komunikowania tych problemów:

• Czy właściwe jest nazywanie czegoś luką w zabezpieczeniach, czy raczej luką w zabezpieczeniach lub niebezpiecznym zachowaniem domyślnym i tak dalej?
• Czy przypisana ocena podatności jest rozsądna?
• Czy podano wystarczające szczegóły i kontekst?

Porozmawiajmy teraz trochę o starych przeglądarkach internetowych.

Stara przeglądarka internetowa

Bez dobrych ludzi z Sonatype nie pomyślałbym o starych przeglądarkach internetowych, prawdopodobnie nigdy więcej.

W przyszłości będę nadal nie brać pod uwagę starych przeglądarek. Przede wszystkim jest zbyt wiele rzeczy, o których należy pamiętać; Nie mogę się martwić o stare przeglądarki internetowe. Po drugie, ile lat ma ( nie klikaj w link, jeśli nie masz poczucia humoru! ) stara przeglądarka internetowa? Co tak naprawdę oznacza „stary”? Jeśli ktoś używa zaledwie ~ rocznej przeglądarki, jest całkiem prawdopodobne, że ma już znacznie większe problemy niż XSS.

Mimo to trochę pogrzebałem i znalazłem, że:

• Google Chrome 48.0.2564.109 (64-bit) z 2016 roku (!) nie wyświetlał nawet treści odpowiedzi. Ponieważ problem z Koa został znaleziony w 2018 roku, pomyślałem, że cofnięcie się do 2016 roku powinno wystarczyć, ale okazało się, że tak nie jest.
• Firefox 4.0 z 2011 roku wyświetlał treść odpowiedzi, ale wymagał od użytkowników kliknięcia łącza w celu wykonania ładunku JavaScript. (Oczywiście, że to link!)
• Firefox 52.0 z 2017 roku, rok przed zgłoszeniem problemu Koa XSS, nie wyświetlał już treści odpowiedzi z ładunkiem JavaScript. Firefox właśnie zgłosił błąd „Błąd uszkodzonej zawartości” z powodu „naruszenia protokołu sieciowego”.

Koa 0.0.1 został wydany w 2013 roku, więc było kilka lat, kiedy problem mógł zostać wykorzystany. W tej chwili byłoby prawdopodobnie akceptowalne oflagowanie tego problemu (nadal bez oceny 9,8) aż do Koa 2.5.0 w 2018 roku. Jednak po tym nic nie usprawiedliwia niczego powyżej 1,0.

Podczas kopania znalazłem coś ciekawego na Wikipedii . Pozwolę sobie zacytować:

Firefox 15 został wydany 28 sierpnia 2012 r.… Firefox 15 wprowadził ciche aktualizacje, automatyczną aktualizację, która zaktualizuje Firefoksa do najnowszej wersji bez powiadamiania użytkownika, [65] funkcję, którą mają przeglądarki internetowe Google Chrome i Internet Explorer 8 i nowsze już wdrożone

Tak więc wszystkie główne przeglądarki internetowe miały funkcję automatycznej aktualizacji przed wydaniem pierwszej wersji Koa, co oznacza, że ​​istnieje prawdopodobieństwo, że większość użytkowników korzystała z aktualnej przeglądarki internetowej. Zobaczmy stan w czasie „wielkiego wybuchu”: 2013 r.

• Firefox 15 : zwrócił komunikat o błędzie „Błąd uszkodzonej zawartości”, co oznacza, że ​​treść odpowiedzi nie została wyświetlona użytkownikowi.
• Chrome 24.0.1312 (WebKit 537.17) : nie wyświetlał żadnej treści odpowiedzi. Patrząc na kartę sieci w narzędziach programistycznych, prawie nic nie było widać, więc musiałem uruchomić Wireshark, aby sprawdzić, czy przeglądarka wykonała żądanie w pierwszej kolejności. W Wireshark było widać, że Chrome skontaktował się z moją usługą PoC i otrzymał odpowiedź z ładunkiem JavaScript. Nie renderował treści odpowiedzi. Nawet lepiej, nic się nie stało.
• Internet Explorer 11 (11.0.9600.19180) : Pobrał odpowiedź z mojej usługi PoC, którą zweryfikowałem za pomocą Wireshark. Nie pokazał użytkownikowi treści odpowiedzi. Powrócił z klasyczną, wbudowaną stroną błędu, która mówi: „Nie można wyświetlić tej strony”.

Po przeprowadzeniu powyższych badań wróćmy na chwilę do cytatu z Sonatype:

Wydaje się, że Koa troszczy się o XSS w tym kontekście, ponieważ mają już tam kod, aby temu zapobiec, jednostka HTML kodująca adres URL podczas zapisywania go w kodzie HTML

Chociaż to stwierdzenie jest poprawne, fakt, że żadna z głównych przeglądarek nie pozwalała na wykorzystanie do czasu wydania pierwszej wersji Koa, cytowane sugeruje coś interesującego, coś innego niż to, co zdanie chciałoby sugerować. Proszę zauważyć, że zaraz napiszę spekulacje, ponieważ nie mogę dokładnie wiedzieć, jak myśleli programiści Koa. Mogę sobie łatwo wyobrazić, że programiści przetestowali omawiane zachowanie przy użyciu aktualnej przeglądarki internetowej. Być może stwierdzili, że kodowanie HTML było odpowiednie, ponieważ niemożliwe było wykonanie wstrzykniętego kodu JavaScript z hrefwłaściwościaetykietka. Rodzi to poważne pytanie. Po spędzeniu ostatnich pięciu lat więcej po stronie tworzenia oprogramowania, dotyczy to również mnie: jako programista, jeśli mam zamiar stworzyć nową technologię internetową dla strony zaplecza, czy powinienem przejmować się starymi przeglądarkami internetowymi? A jeśli powinienem, jakie jest oficjalne zalecenie społeczności zajmującej się bezpieczeństwem dotyczące tego, jak daleko w czasie muszę rozważyć stare przeglądarki internetowe? Czy nie powinniśmy wziąć pod uwagę, że najlepszą praktyką w zakresie bezpieczeństwa dla użytkowników końcowych jest aktualizowanie ich przeglądarek, a funkcja automatycznej aktualizacji również ma w tym pomóc? Ponadto, jeśli oczekujemy, że programiści będą pamiętać i testować stare przeglądarki, czy nie możemy oczekiwać, że specjaliści ds. ”? Byłoby to po prostu sprawiedliwe.

Jedno jest pewne, od lat nie ma się czym martwić…

Nowoczesna przeglądarka

W mojej analizie, korzystając z przeglądarki internetowej, sprawdziłem treść odpowiedzi i stwierdziłem, że jest pusta. Nie sprawdzałem, czy odpowiedź przesłana drutem miała treść. Okazuje się, że tylko Google Chrome całkowicie zignorował treść odpowiedzi; dlatego się nie pokazał. To było dla mnie wystarczająco dobre. Rozsądnie, muszę dodać.

Od tego czasu przyglądałem się odpowiedziom mojej testowej usługi internetowej przy użyciu najnowszej wersji Koa. Poniżej widzimy, że treść odpowiedzi HTML zawierała wstrzyknięty kod JavaScript:

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=javascript:alert(1); HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: javascript:alert(1);
< Content-Type: text/html; charset=utf-8
< Content-Length: 71
< Date: Tue, 22 Nov 2022 17:55:12 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="javascript:alert(1);">javascript:alert(1);</a>.

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=%22><%2f HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: %22%3E%3C/
< Content-Type: text/html; charset=utf-8
< Content-Length: 61
< Date: Tue, 22 Nov 2022 22:18:49 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="&quot;&gt;&lt;/">&quot;&gt;&lt;/</a>.

Nadchodzące zmiany

Poniżej znajduje się lista aktualizacji, które firma Sonatype planuje wdrożyć w związku z tym problemem:

• Aktualizacja wiersza Podsumowanie/Tytuł w celu wyeliminowania nieporozumień (już miała miejsce)
• Zmniejszenie oceny podatności do 4,7 (już się stało)
• Wspomnij, że lukę można wykorzystać tylko wtedy, gdy użytkownik korzysta ze starszej przeglądarki

Dodatkowe zmiany, które chciałbym zobaczyć

Oprócz zmian wspomnianych w poprzedniej sekcji, kilka rzeczy można jeszcze ulepszyć. To są:

• Dalsze obniżenie oceny podatności, szczególnie w przypadku wersji Koa wydanych po 2018 roku.
• W tym numer wersji co najmniej głównych przeglądarek internetowych i daty ich wydania zawarte w raporcie w odniesieniu do „starszych przeglądarek”. Pomogłoby to znacznie każdemu, kto „ocenił lukę w danej implementacji przy użyciu biblioteki, której dotyczy problem”. Na przykład, gdybym zobaczył, że użytkownik musi korzystać z przeglądarki z 2011 roku, w ciągu sekundy oznaczyłbym problem jako „nie dotyczy” w SCA. To dużo zaoszczędzonego czasu.
• Wersje Koa, których dotyczy luka, mają być wymienione na stronie z luką .

Nawiasem mówiąc, Sonatype wspomniał również, że ma kilka fajnych testów w swojej ofercie komercyjnej, które na przykład przeprowadzają rzeczywiste kontrole na poziomie kodu, aby sprawdzić, czy zgłaszane luki miały wpływ na aplikację. Brzmi to schludnie, a biorąc pod uwagę science-fiction charakter sposobu, w jaki obliczane są oceny luk w bibliotekach, tego rodzaju kontrole są niezbędne, aby zmniejszyć obciążenie zespołów inżynierskich, zwłaszcza jeśli sytuacja będzie się utrzymywać w ten sposób.

Wniosek

To prawie wszystkie aktualizacje, które mam. Cieszę się, że skontaktowałem się z Sonatype, ponieważ są bardzo profesjonalni i przyjaźni. Praca z nimi nad tym była przyjemnością.

Jeśli chodzi o XSS w Koa: to coś, czym nikt z nas nie powinien się martwić od kilku lat.