Nie taki prywatny tryb InPrivate

[KopalniaWiedzy.pl 357]

Ashish Singh, który specjalizuje się w bezpieczeństwie systemów komputerowych, poinformował, że w przeglądarce Edge występuje błąd, który powoduje, iż tryb InPrivate nie jest tak anonimowy, jak być powinien. Okazało się, że dane z odwiedzanych witryn są zapisywane na dysku twardym i można je przejrzeć odczytując plik WebCache. Informacje o odwiedzonych witrynach są zapisywane w tej samej tabeli "Containter_n", w której zapisywane są dane z jawnych sesji surfowania po internecie. Wystarczy przeanalizować tę tabelę, by poznać całą historię odwiedzanych witryn.

Edge to nie jedyna przeglądarka, w której wystąpiły tego typu problemy. W 2010 roku naukowcy z Uniwersytetu Stanforda przeprowadzili różne ataki na Firefoksa, Chrome'a, Safari i Internet Explorera, w czasie których poznali historię, nawet tę z trybów prywatnych. Jak mówi informatyk śledczy Lesley Carhart, to wspólny problem. Tryby prywatne zawsze pozostawiają na dyskach twardych łatwe do odzyskania ślady. To mechanizmy prywatności, a nie zabezpieczenia przed atakami - mówi Carhart. Edge ma jednak poważniejszy problem, gdyż dane z WebCache można odczytać znacznie łatwiej i nie trzeba do tego dużego doświadczenia.
Microsoft potwierdził występowanie błędu i obiecał szybkie jego naprawienie.

« powrót do artykułu

[Jajcenty 314]

 

 

w przeglądarce Edge występuje błąd

 

Edge to nieporozumienie. Wczesna beta wypuszczona z fanfarami a ciężar testowania przerzucony na użytkowników. Powrót do najgorszych tradycji MSa.

[radsun 1]

Ponoć nawet można zrobić zrzut ekranu albo zdjęcie telefonem i przed tym nie chroni! 

[Gość Astro]

 

 

Ashish Singh, który specjalizuje się w bezpieczeństwie systemów komputerowych […] Okazało się, że dane z odwiedzanych witryn są zapisywane na dysku twardym i można je przejrzeć odczytując plik WebCache. […] Edge ma jednak poważniejszy problem, gdyż dane z WebCache można odczytać znacznie łatwiej i nie trzeba do tego dużego doświadczenia.

 

Zastanawiam się czasem, czy naprawdę trzeba angażować naukowców i śledczych by wykazać, że przeciętnie debil klepie kod (o zgrozo!, bez nadzoru nieco inteligentniejszej małpy)…

[pogo 102]

Tak.

Chodzi o namierzenie konkretnych błędów i nie powiedzenie, że jakieś są. Oczywiście to powinien wyłapać dział QA producenta, ale nie oszukujmy się, oni też geniuszami zwykle nie są. No i jeszcze jest kwestia dostępnego czasu.

 

Nie istnieje skończony zbiór testerów, który jest w stanie w skończonym czasie znaleźć wszystkie bugi w danym programie.

[darekp 80]

przeciętnie debil klepie kod (o zgrozo!, bez nadzoru nieco inteligentniejszej małpy

 

Mi się wydaje (z perspektywy "przeciętnego klepacza kodu"), że to właśnie ta "inteligentniejsza małpa nad nim" wydała mu takie polecenie. Niedawno miałem przerobić kod pewnej usługi. Przy okazji okazało się, że ta usługa wykonuje dość dziwną walidację danych. Na wejściu dostawała listę kodów walut (EUR, USD, PLN itd.), dla których miała wykonać pewne operacje bazodanowe (inserty) oraz drugą listę kodów wykluczonych, na których nie powinna wykonywać operacji - nawet jeśli znalazły się na pierwszej liście. Przy czym usługa sprawdzała waluty z drugiej listy, jeżeli pojawiała się waluta nieprawidłowa (nieistniejącego kraju), to rzucała błąd. A pierwszej listy nie sprawdzała. Na moje wyczucie powinno być odwrotnie - ma sens sprawdzanie, czy na pierwszej liście są nieistniejące waluty, żeby nie pisać głupot do bazy danych, a jeśli na liście wykluczeń jest jakaś nieistniejąca waluta no to cóż, nic złego się nie stanie, nie powinno być takiej na pierwszej liście. Zadzwoniłem do człowieka (analityka/projektanta czy kogoś tam), który jest nad programistami w hierarchii, wytłumaczyłem o co chodzi, zrozumiał i dał mi wyraźne polecenie, żeby niczego nie zmieniać w sposobie działania. Oczywiście można dyskutować, czy moja interpretacja jest właściwa. Ale widać, że ten przeciętny klepacz niespecjalnie ma możliwość wykazania się własną "kreatywnością".

Edytowane 30 stycznia 2016 przez darekp

[Jajcenty 314]

 

 

wytłumaczyłem o co chodzi, zrozumiał i dał mi wyraźne polecenie, żeby niczego nie zmieniać w sposobie działania.

Obstawiam, że nie chciał tracić czasu. Zmiana specyfikacji i upewnienie się  co do wpływu zmiany na resztę usług to dla analityka kupa roboty papierkowej. Przygotowanie scenariusza testów, wykonanie testów, potwierdzenie oczekiwanych rezultatów. Masz szczęście, że nie zepchnął tej roboty na Ciebie w ramach lekcji życia w oceanie ITIL.

[darekp 80]

Obstawiam, że nie chciał tracić czasu.

Pewnie tak. Zresztą ja też nie miałbym czasu na te scenariusze i testy. Ale to pokazuje, w jaki sposób różne błędy mogą powstawać. Bo to rzeczywiście wygląda na b. złą specyfikację:

1) Jeśli usługa dostaje parametry "wstaw do bazy danych kurs dolara rurytańskiego" to posłusznie wstawia, pomimo, że taka waluta nie istnieje.

2) Jeśli dostaje parametry "wstaw kursy euro, korony czeskiej i dolara rurytańskiego oprócz dolara rurytańskiego", to rzuca błąd "nie ma takiej waluty - dolar rurytański".

3) Jeśli dostaje parametry "wstaw kursy euro i korony czeskiej oprócz dolara rurytańskiego", to nadal rzuca błąd "nie ma takiej waluty - dolar rurytański", pomimo, że nikt nie kazał jej wstawiać.

 

Co najmniej jeden z tych przypadków nie pasuje do reszty.

 

Wiele takich błędów (o ile to rzeczywiście błąd) jest w stanie wykryć jedynie programista, bo pracuje b. niskim poziomie ogólności. Analityk widzi bardziej "z lotu ptaka", nie dostrzega wielu szczegółów. Jeśli analityk będzie za często bezrefleksyjnie powtarzał "rób tak jak zaprojektowałem", albo programista będzie niedostatecznie czuły, to wiadomo czym to się skończy.

Edytowane 30 stycznia 2016 przez darekp

[Gurth 2]

https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-many-microsoft-employees-does-it-take-to-change-a-lightbulb/