Paweł Goleń, blog

Na początek krótkie wprowadzenie: “Nie można przełamać czegoś, co nie istnieje” – polski wyrok w sprawie SQL Injection. Sprawa jest stara i szczerze mówiąc to rozstrzygnięcie nie podoba mi się od chwili, gdy o nim usłyszałem. Nie chodzi mi tu o tę konkretną sprawę, ale właśnie o (...) nie można przełamać czegoś, co nie istnieje (...).

W zasadzie każda podatność istnieje dlatego, że jakieś zabezpieczenie nie zostało (prawidłowo) zaimplementowane. Skoro tak, to udany atak nie jest przełamaniem zabezpieczenia, lecz wykorzystaniem faktu, że zabezpieczenie przed konkretnym atakiem w danym systemie nie istnieje. Bo niby dlaczego brak zabezpieczenia przed SQLi w formatce logowania ma być traktowany inaczej, niż brak zabezpieczenia przed wykonaniem przelewu z cudzego konta? Kiedy coś jest już przełamaniem, a kiedy jeszcze nie?

Moim zdaniem w tej historii zabezpieczenie było. Był nim mechanizm uwierzytelnienia użytkownika. Na podstawie deklarowanej i potwierdzonej tożsamości system dopuszczał (autoryzował) użytkownika do korzystania z niego. Osoby uprawnione do dostępu do systemu posiadały w nim swoje konta, pozostałe – nie i (w założeniu) nie mogły uwierzytelnić się w systemie. W wyniku istnienia podatności możliwe było uwierzytelnienie się w systemie bez znajomości hasła. I teraz można się oddać rozważaniom językowym i prawnym (prawniczych) na temat znaczeń słowa przełamanie. Zresztą długi wywód na ten temat znajduje się w przywołanym wpisie.

Wspominam o tym, ponieważ w odpowiedziach na takie pytania prędzej czy później ta historia zostanie przywołana. Cóż, nasze prawo nie jest doskonałe a i jego interpretacje mogą być różne (prawo ma to też do siebie, że ulega czasem zmianom na co w komentarzu zwrócił uwagę Gynvael). Ciekawy wpis w tym temacie popełnił Gynvael, ciekawa jest również dyskusja pod nim.

By było jasne – uważam, że nie ma usprawiedliwienia dla programistów tworzących oprogramowanie pełne dziur. To, że zgodnie z przepisami prawa “atakowanie” takiej aplikacji jest karalne, nie oznacza, że dostawca/programista może nie przywiązywać odpowiedniej wagi do zabezpieczenia aplikacji przed takimi działaniami. Aplikacje muszą być tworzone z uwzględnieniem kwestii bezpieczeństwa, a sami programiści (i nie tylko oni) w tym temacie powinno być szkoleni. Z drugiej strony nie podoba mi się próba usprawiedliwienia z wykorzystaniem niedoskonałości przepisów osób, które, nazwijmy to, dokonują nadużycia funkcjonalności różnych serwisów internetowych lub wykorzystują brak (skutecznych) zabezpieczeń.

Dlaczego przeglądanie bazy danych serwisu w sposób inny niż ten, na jaki zgodę wyrazi jego administrator/operator ma być traktowane inaczej niż, przykładowo, przeglądanie szuflad z bielizną przez osobę sprzątającą wynajętą do umycia łazienki? Bo majtki są namacalne i mają (w sensie odzieży, majtki jako takie mają historię znacznie krótszą) jakieś 170 tysięcy lat historii, a informacja nie dość, że jest nienamacalna, to jeszcze te całe komputery, sieci i Internet to jakieś nowinki są...

A tak swoją drogą to co napisałem wyżej wcale nie zawsze jest prawdą. Przecież nie w każdej społeczności/kulturze poczucie własności, “terytorialności” czy prywatności jest takie samo. Wystarczy przywołać “drobne” różnice kulturowe dotyczące odległości między rozmówcami i przyzwolenia (lub jego braku) na kontakt fizyczny z rozmówcą (patrz np.[Wielkość dystansu indywidualnego](http://pl.wikipedia.org/wiki/Dystansosobisty#Wielko.C5.9B.C4.87dystansuindywidualnego))._

Oryginał tego wpisu dostępny jest pod adresem Czy słonia można zafortepianić?

Autor: Paweł Goleń