Uczymy się powoli, czyli przyszłe okładki tygodnika w Sieci

Cz, 2013-04-04 20:09 by VaGla

Kiedy czytam doniesienia o możliwym pozwie za wydedukowanie gdzie na dostępnym w Sieci serwerze znajdują się przyszłe okładki tygodnika Wprost, to przypomina mi się materiał z 2002 roku, w którym relacjonowałem dość podobną sytuację z pewnym raportem: Granice wykorzystania linków. Wówczas spółka groziła Reutersowi, który omówił ten raport przed "oficjalną" jego publikacją. Oczywiście raport był opublikowany i wcześniej, tylko nie był linkowany. Teraz mamy historię Wprost i okładek kolejnych, przyszłych wydań. Minęło 11 lat od historii z raportem. Uczymy się wolno.

W tekście Bloger w niebezpieczeństwie Tomasz Machała, red. nacz. NaTemat, pisze, że Wprost chce wytoczyć działa prawne przeciwko blogerowi (cokolwiek znaczy słowo bloger). Na Twitterze miał on opublikować okładki przyszłych numerów tygodnika. Skąd wiedział, jak te okładki znaleźć? Tomasz Machała to przybliża:

Michał odkrył, że może zobaczyć okładkę najbliższego numeru Wprost i Do Rzeczy jeszcze przed publikacją w następujący sposób: wchodzi w weekend do serwisu eGazety.pl, wybiera Wprost, następnie otwiera okładkę w nowym oknie i dodaje +1 do nazwy obrazka. Czyli jeśli było 1751.jpg, następna okładka będzie 1752.jpg. Wydawca wgrywa tą okładkę na serwer wcześniej, nie ustawia hasła, więc każdy kto tak zrobił mógł zobaczyć kolejną okładkę.

No i myślę sobie, że to jest dokładnie taka sama sytuacja, jak w przypadku opisywanego 11 lat temu sporu między Reutersem a szwedzką spółką Intentia. Robimy może wciąż te same błędy, ponieważ materiałów dot. początku sporu Intentia - Reuters już nie można znaleźć w Sieci. Jednak nie jest tak, że z internetu nic nie ginie. Zostały już tylko omówienia. Poza moim, linkowanym we wstępie, są też np. takie:

Ja zaś koleżankom i kolegom z Tygodnika Wprost (gdzie kiedyś byłem odpowiedzialny za rozwój Wprost Online, ale to było w 2000 roku), dedykuję następujący materiał: "Nie można przełamać czegoś, co nie istnieje" - polski wyrok w sprawie SQL Injection.

Uczymy się powoli, ale - jest taka nadzieja - może chociaż się czegoś uczymy.

W sprawie okładek, by być uczciwym, trzeba dostrzec różnice między linkowaniem do opublikowanych w Sieci okładek a ich kopiowaniem i publikowaniem. Jeśli dochodziło do wykorzystania okładek bez zgody - to by zmieniało kwalifikację całej sytuacji. Nie chodziłoby pewnie o ochronę tajemnicy przedsiębiorstwa (nie została spełniona przesłanka ochrony informacji przez uprawnionego), ale ew. naruszenie praw autorskich (które chronią utwór wszak bez spełnienia jakichkolwiek formalności). Tylko czy spór o takie okładki może się Tygodnikowi Wprost do czegokolwiek przydać? Może i wydawnictwo wygrałoby przed sądem. Nie wiem. Ale niesmak ew. czytelników oraz publiczności w szerokim ujęciu by się pojawił. Może po prostu trzeba zmienić mechanizmy w tygodniku i iść dalej. Pogodzić się ze sposobem działania infrastruktury Sieci, np, zacząć stosować jakieś zabezpieczenia, jeśli istotnie muszą tam w wydawnictwie wrzucać do Sieci przyszłe okładki tygodnika.

Tak, wiem. Redakcje funkcjonują w oparciu o szacunek ryzyk prawnych. Na kolegiach redakcyjnych (tak było kiedyś we Wprost), albo zaraz obok nich, siedzi kilku prawników odpowiadających na pytania naczelnego, "czy możemy to puścić", a raczej: "co nam grozi, jak to puścimy?". I w związku z tym zastanawiam się głośno: jak się miałaby taka ewentualna wygrana wydawnictwa do warsztatu pracy dziennikarzy tego wydawnictwa? Czy Wprost opierałby się w swojej pracy już tylko na "oficjalnie" dostępnych informacjach? No bo dobrze by było, gdyby kierunkowskaz szedł drogą, którą sam wskazuje...

PS.
I takie doniesienia właśnie sprawiają, że mniej ostatnio piszę w serwisie. Bo wiele z takich spraw i doniesień już było i powtarzane sytuacje nie mają często waloru nowości...

« Przyzwolenie na przejaskrawione opinie? Czekamy na udostępnienie treści wyroku SN | Skargi SLLGO dotyczące pryncypiów dostępu do informacji publicznej trafiły do Strasburga i do Trybunału Konstytucyjnego »

Mechanizmy zabezpieczeń

Pt, 2013-04-05 10:39 by Piotr R. (niezweryfikowany)

Najprostszym mechanizmem jest stosowanie hasła, którym może być sam URL - wystarczy by był on stosunkowo trudny do odgadnięcia.
Wystarczyłoby zamiast licznika zastosować pseudolosowy id.

To nie jest zabezpieczenie.

Pt, 2013-04-05 18:44 by Makdaam

Jeżeli dobrze zrozumiałem Pana wypowiedź, proponuje Pan aby jedynym utrudnieniem w dostępie do danych była znajomość URL?

Moim zdaniem, umieszczenie pliku na serwerze HTTP bez dodatkowych zabezpieczeń (np. HTTP Auth opisanego w RFC 2617) jest jednoznaczne z jego publikacją nawet gdy URL poza nazwą domenową zawierałby 200 zupełnie losowych znaków.

Czym się różni

Pt, 2013-04-05 20:19 by incognitus (niezweryfikowany)

Czym się różni przekazanie hasła poprzez mechanizm HTTP Auth, od przekazania hasła bezpośrednio w URLu? Technicznie - zapewne czym się różni. Użytkowo? Niczym.

Odpowiednie narzędzie do odpowiedniego celu

Pt, 2013-04-05 23:31 by Makdaam

Dochodzi jeszcze kwestia prawna. Wszystko umieszczone na serwerze bez zabezpieczeń jest nie do odróżnienia od rzeczy umieszczonych za tym pseudozabezpieczeniem. W związku z tym trudno byłoby wyciągać jakiekolwiek legalne konsekwencje wobec osoby, która pobierze dany dokument (znalazła gdzieś URL albo go odgadła).

Biorąc pod uwagę mechanizm historii odwiedzanych stron, to różni się on drastycznie poziomem zabezpieczenia od magazynu haseł. Różni się w sumie całym kontekstem jeżeli spojrzymy od strony zapewnienia bezpieczeństwa. Nie mamy mechanizmów do bezpiecznego przekazywania URLi, nie mamy mechanizmów do nieodwracalnego przechowywania URLi po stronie serwera. Wszystko to już jest rozwiązane w przypadku mechanizmów normalnego uwierzytelniania.

Zasadniczo należy korzystać z dostępnych narzędzi zgodnie z ich przeznaczeniem. Ich twórcy przez swoje doświadczenie oraz lata użytkowania spotkali się z tysiącami problemów, których nawet nie wymyślimy rozważając teoretycznie najczarniejsze scenariusze. Np. co jeżeli ktoś wyśle URL przez gmail? Bot googla może taki URL zaindeksować i dodać do wyników wyszukiwania.

Tak mi się skojarzyło...

So, 2013-04-06 13:29 by raj

Co do URL-a, to tak mi sie skojarzyło. Pomagałem kiedyś człowiekowi odpowiedzialnemu za zamówienia publiczne w instytucji zobligowanej do stosowania przepisów ustawy o zamówieniach publicznych, w założeniu sobie konta w Biuletynie Zamówień Publicznych - oficjalnym serwisie urzędowym, służacym do publikacji ogłoszeń o przetargach itp. Jakiż był mój szok, kiedy odkryłem, że login i hasło do tego serwisu przekazywane sa metoda GET i po zalogowaniu doklejane są do URL-a kazdej podstrony w tym serwisie, na która się wchodzi! Zgroza. Wystarczy, żeby nieświadomy niczego użytkownik takiego serwisu przesłał np. komuś mailem link do ogłoszenia, które własnie opublikował...

To było wiele lat temu, więc byc może już to zmienili, ale sam fakt że przez jakiś (i to dośc długi) czas tak było, jest szokujący.

HTTP AUTH też nie daje

So, 2013-04-06 01:44 by incognitus (niezweryfikowany)

HTTP AUTH też nie daje żadnych zabezpieczeń, bo dane logowania (hasło i nazwa uzytkownika) i tak lecą w tekstem jawnym (czyli są czytelne dla każdego po drodze). Dane te są obfuskowane kodowaniem base64. Jedyną różnicą między przekazaniem tego hasła w URL i za pomocą HTTP-Auth jest to że hasło zamiast lecieć w URL leci w nagłówku.

Zasób zabezpieczony IMO jest od momentu gdy:

* Mamy transmisję za pomocą HTTPS.
* Mamy hasło. I rzeczywiście przy szyfrowanej transmisji możemy się pokusić o użycie: HTTP-Auth,

TLS to podstawa

So, 2013-04-06 19:49 by Makdaam

Wysyłanie jakichkolwiek wrażliwych informacji bez szyfrowania jest według mnie nie do pomyślenia. Zakładałem, że cały czas piszemy o https.

HTTP AUTH opisane w RFC

Pn, 2013-04-08 08:39 by incognitus (niezweryfikowany)

HTTP AUTH opisane w RFC 2617, to dwie metody uwierzytelniania za pomocą hasła, pierwsza z nich (BASIC) to w uproszczeniu przekazanie hasła zakodowanego w base64 (czyli w zasadzie jawnym tekstem), ale jest też druga (DIGEST) w którym przesyłany jest MD5 hasła z solą (tak trochę w uproszczeniu to przedstawiając) i o ile jest ona poprawnie zaimplementowana, to jest stosunkowo bezpieczna.

HTTP bez TLS, a bezpieczeństwo.

Wt, 2013-04-09 14:24 by Makdaam

Obecnie szukanie kolizji MD5 (nawet posolonych) to nie jest wielki problem (liczony bardziej w dniach, a nie w latach).

Bez TLSa nie ma mowy o bezpiecznym HTTP, można też obejść uwierzytelnianie np. wstrzykując przekierowanie na stronę logującą próby uwierzytelnienia w trybie BASIC.

Podsumowując są zdefiniowane w standardach mechanizmy uwierzytelniania, można z nich dowolnie wybierać. Wymyślanie swoich własnych IMO mija się kompletnie z celem.

Niezbyt głębokie ukrycie

Pn, 2013-04-22 19:49 by pskosinski (niezweryfikowany)

W dobrze napisanej aplikacji webowej wszystkie zapytania od serwera HTTP powinny być przekazywane do aplikacji. W przypadku Wprost aplikacja powinna po prostu sprawdzać czy dana okładka może zostać już wyświetlona i jeżeli tak to wysłać plik JPG do klienta, w przeciwnym wypadku zwrócić błąd 404/403. Nie trzeba tu żadnych losowych znaków ani tym bardziej uwierzytelniania.

Moim skromnym zdaniem wina leży tylko i wyłącznie po stronie Wprost czy też tego kto stworzył dla nich stronę internetową. Jest to kolejny przykład jak bardzo ktoś nie chce wziąć na siebie odpowiedzialności za zastosowanie "głębokiego ukrycia", które ciężko nazwać jakimkolwiek zabezpieczeniem, a w tym przypadku ciężko nawet nazwać je "głębokim".

Piotr VaGla Waglowski

Piotr VaGla Waglowski - prawnik, publicysta i webmaster, autor serwisu VaGla.pl Prawo i Internet. Ukończył Aplikację Legislacyjną prowadzoną przez Rządowe Centrum Legislacji. Radca ministra w Departamencie Oceny Ryzyka Regulacyjnego a następnie w Departamencie Doskonalenia Regulacji Gospodarczych Ministerstwa Rozwoju. Felietonista miesięcznika "IT w Administracji" (wcześniej również felietonista miesięcznika "Gazeta Bankowa" i tygodnika "Wprost"). Uczestniczył w pracach Obywatelskiego Forum Legislacji, działającego przy Fundacji im. Stefana Batorego w ramach programu Odpowiedzialne Państwo. W 1995 założył pierwszą w internecie listę dyskusyjną na temat prawa w języku polskim, Członek Założyciel Internet Society Poland, pełnił funkcję Członka Zarządu ISOC Polska i Członka Rady Polskiej Izby Informatyki i Telekomunikacji. Był również członkiem Rady ds Cyfryzacji przy Ministrze Cyfryzacji i członkiem Rady Informatyzacji przy MSWiA, członkiem Zespołu ds. otwartych danych i zasobów przy Komitecie Rady Ministrów do spraw Cyfryzacji oraz Doradcą społecznym Prezesa Urzędu Komunikacji Elektronicznej ds. funkcjonowania rynku mediów w szczególności w zakresie neutralności sieci. W latach 2009-2014 Zastępca Przewodniczącego Rady Fundacji Nowoczesna Polska, w tym czasie był również Członkiem Rady Programowej Fundacji Panoptykon. Więcej >>