Source: http://prawo.vagla.pl/node/8154
Timestamp: 2020-08-08 11:44:47
Legal References Found: art. 268
 art. 267
 art. 267
 art. 267
 art. 267
 art. 267
 art. 267
 art. 267
 art. 267
 art. 267
 art. 267
 art. 267
 art. 267
 art. 267
 art. 267
 art. 267

Document Content:
Ciekawe i całkiem logiczne
Pn, 2008-10-06 10:51 by Olgierd
aczkolwiek jeszcze ciekawsze, że oskarżyciel nie skarżył wyroku. Czyżby jakieś zmiany w prokuraturze? ;-)
Ciekawe ale nieco inne
Pn, 2008-10-06 12:53 by Grzegorz Marczak (niezweryfikowany)
Przyznam, że ciekawa sprawa i chyba sprawiedliwy wyrok. Nie ze względu na formułki prawne, które zostały zastosowane, ale ze względów czysto ludzkich - człowiek poinformował kogoś o problemach z bezpieczeństwem, a w nagrodę został oskarżony.
Mój przypadek, chyba przyznasz, był nieco inny, kolega włamywacz Kminek.pl jako główny cel przyjął sobie skompromitowanie mojego bloga. Nie poinformował mnie wcześniej o problemie z bezpieczeństwem, zrobił wpis, który miał mnie ośmieszyć oraz zmienił hasło administratora serwisu.
Zrobił coś jeszcze, ale chyba nie jestem w stanie tego udowodnić.
Grzegorz, bardzo lubię
Pn, 2008-10-06 13:24 by Mateusz.M (niezweryfikowany)
Grzegorz, bardzo lubię Twojego bloga i często tam zaglądam. Myślę, że jeśli zdecydujesz się złożyć zawiadomienie o przestępstwie będziesz miał duże szanse na to, że sprawca zostanie ukarany, a to dlatego, że ingerował w dane znajdujące się na serwerze (np. zmienił hasło). Takie działanie określa art. 268 par. 2 KK. W mojej sytuacji takie działania nie miały miejsca - nic nie zostało zmienione czy uszkodzone. W Twoim przypadku mniej ważne będzie to, że doszło do włamania, a bardziej to, że nieuprawniona osoba zmieniła dane i utrudniła Tobie, osobie uprawnionej, dostęp do danych. Takie działanie zagrożone jest karą 3 lat pozbawienia wolności. We wpisie, którym zamieściłeś w swoim blogu pisałeś o 'włamaniu', natomiast informacja o zmianie danych była niejasna... Myślę, że masz bardzo małe szanse, że zostanie ukarany z art. 267 KK (~hacking), jednak 268 par. 2 KK jest bardzo realny. Życzę powodzenia - cokolwiek zdecydujesz z tym zrobić.
Pn, 2008-10-06 13:03 by np (niezweryfikowany)
Sercem opowiadam się za tym wyrokiem. Powinno się móc wytykać komukolwiek błędy, ale spójrzmy przed SQL Injection. A przed stoi "Formularz logowania", który jako taki jest przecież zabezpieczeniem. To zabezpieczenie miało wadę i zostało ominięte. Wpisując nazwę użytkownika "1=1", kolega hakier postanowił ominąć zabezpieczenie i zalogować się jako użytkownik o nazwie "1=1" którego to konta nie zakładał i na które nie znał hasła. System zaś zareagował błędnie na tak podaną nazwę użytkownika.
Przypomina to przypadek gdyby ktoś chciał testować moje drzwi w domu na okoliczność tego czy kupiony na bazarze "klucz uniwersalny" pasuje. Gdyby ten kolego wszedł wtedy do mojego domu, nie byłbym zadowolony, a sąd zapewne uznał by to za "ominięcie zabezpieczeń". Trochę dziwi że tego nie uznał ominięcia formularza logowania jako złamanie zabezpieczeń. Np. gdyby wpisanie w publicznie dostępny formularz wyszukiwania frazy "logowanie" i człowiek zostałby zalogowany to owszem nic nie omijał, po prostu znalazł błąd, ale wpisanie w formularz logowania "1=1" to nie jest przypadkowym znalezieniem błędu - to jest ominięcie zabezpieczenia.
Dlatego analogii do "świata realnego" nie można stosować
Pn, 2008-10-06 13:07 by VaGla
Dlatego analogii do "świata realnego" nie można stosować, a regulacja działań sferze czystej "logiki" czy "algorytmu" jest taka trudna. Co innego drzwi, co innego formularz logowania. Dotyczą tych spraw zupełnie inne przepisy i proszę o tym pamiętać.
Dodatkowo trzeba będzie znów analizować sytuację po nowelizacji przepisu art. 267. Być może mógłby się nim zająć Trybunał Konstytucyjny, gdy już zostanie przyjęty i podpisany przez Prezydenta (a może nawet wcześniej, jeśli Prezydent zdecyduje się taką nowelizację do TK przesłać przed podpisem).
Ok, analogie z rzeczywistością na bok
Pn, 2008-10-06 13:15 by np (niezweryfikowany)
Ok, analogie z rzeczywistością na bok.
Dlaczego "Formularz logowania" weryfikowany użytkownikiem i hasłem nie jest zabezpieczeniem?
Gdyby go nie było każdy mógłby oglądać wszystko - wtedy nie byłoby zabezpieczenia.
Skupiono się na SQL Injection, które jest tylko metodą ominięcia zabezpieczenia.
Analiza art. 267 KK w wielu
Pn, 2008-10-06 13:33 by Mateusz_M (niezweryfikowany)
Analiza art. 267 KK w wielu publikacjach mówi o tym, że zabezpieczenie musi być zabezpieczeniem realnym, sprawnym, utrudniającym dostęp do danych. Zwróć uwagę na to, że wpisując swój komentarz wykonałbyś już SQL Injection gdyby system, na którym oparty jest ten serwis nie był poprawnie napisany. Użyłeś znaków, które należą do składni języka SQL i mogłeś zaburzyć pracę aplikacji. W mojej sprawie biegły uznał, że wprowadzony ciąg znaków 'or 1=1 należy do zakresu znaków, które mogą być wpisane w pole formularza typu text. Uznał, że do aplikacji został wysłany prawidłowy ciąg znaków, natomiast aplikacja w nieprawidłowy sposób ciąg ten zinterpretowała. Uważam, że nowelizacja KK, w proponowanej formie, będzie błędem i przyniesie dużo więcej problemów.
Powiem jeszcze raz - nie
Pn, 2008-10-06 14:06 by np (niezweryfikowany)
Powiem jeszcze raz - nie chciałbym aby państwo produkowało jakieś kolejne artykuły które więcej napsują niż pomogą. Powinno się móc sprawdzić zabezpieczenia jeżeli się ma czyste intencje i dobrze się stało, że uczciwy człowiek nie został ukarany.
Tylko to całe prawo krzywe jest. Co to znaczy "sprawne"? W 100%? Wtedy nigdy nie będzie złamane i sprawa jest bezprzedmiotowa. "Realne i utrudniające"? Uważam że zwykły formularz logowania taki jest.
A co do tego że teraz pisząc "1=1" mogę wpłynąć na system - zgoda, ale to nie jest formularz który gdy wyślę to mogę potencjalnie zalogować się do systemu z uprawnieniami których normalnie nie posiadam. Bo nie oszukujmy się, wiedziałeś co może się stać po "1=1" podczas logowania, a co podczas tego submitu który za chwilę wykonam :)
Pamiętaj, że to co
Pn, 2008-10-06 14:44 by Mateusz.M
Pamiętaj, że to co zrobiłem to trywialny i jeden z najprostszych wariantów SQL Injection. Pisząc komentarz oczywiście trudno byłoby się zalogować ale gdyby istniała luka, to usunięcie bazy danych nie byłoby problemem. Czy choćby wywołanie błędu składni, co w efekcie wyświetliłoby błąd z informacjami o strukturze bazy danych (informacje nieprzeznaczone dla Ciebie). Podobnie sprawa wygląda z atakami XSS. Art 267 KK na pewno nie jest doskonały i po nowelizacji również nie będzie. Boję się tylko, że nowelizacja odniesie odwrotny skutek do zamierzonego. Zamiast wzmocnić szczelność art. i rozszerzyć horyzont karalnych działań, to da nieuczciwym osobom oręż do wyłudzania pieniędzy. Nie będę podawał przykładów ale nietrudno wyobrazić sobie sytuację, w której jakaś osoba spreparuje stronę, umożliwi 'omijanie zabezpieczeń' i skutecznie to wykorzysta...
Fakt - jest takie zagrożenie
Pn, 2008-10-06 15:08 by np (niezweryfikowany)
Fakt - jest takie zagrożenie. Są trole patentowe, sa trole domenowe, mogą się też pojawić trole "włamaniowe".
Pn, 2008-10-06 22:31 by artur.kmieciak@...
Formularz nie jest zabezpieczeniem. Chyba jest jasne dlaczego, prawda?
Hasło jest zabezpieczeniem.
W naszej sprawie nie miało miejsca złamanie hasła.
Nie doszło do przełamania zabezpieczeń.
Wt, 2008-10-07 08:50 by incognitus (niezweryfikowany)
dlatego, że użytkownik ma pełne prawo być durny i chcieć używać konta o nazwie '1=1 nawet, jeśli go nigdy nie zakładał
idąc takim tokiem rozumowania....
Wt, 2009-01-13 02:51 by slawek (niezweryfikowany)
Idąc takim tokiem rozumowania nic nie jest atakiem. Wszelkie łamanie zabepieczeń ogranicza się do znalezienia luki. Nie chcę powiedzieć, że wyrok sądu jest dla mnie dziwny ale chciałbym usłyszeć argumentacje tego sądu w sprawie tyczącej się wszechobecnych ataków typu DOS, czyli "blokady usług".
Tego typu ataki (choć raczej w myśl argumentacji wyroku atakami nie są), nie muszą się w ogóle opierać ani na szukaniu dziur w systemie, ani wprowadzaniu niczegokolwiek do sytemu.
W odniesieniu do strony internetowej atakiem takim więc jest sam request - rządanie adresu (tylko ten o jeden za dużo!).
Mamy więc sytuację, w której nikt nawet nie chce dostać się do danych. Chce sparaliżować ruch na stronie. I tyle.
Każdy użytkownik systemu linux lub podobnego może o ile ma zainstalowany (w pełni legalny software - apache benchmark) wywołać atak tego typu wpisując tylko jedną linijkę w okno terminalu przykład.
ab -kc 1000 -n 10000 http://www.dosowanyadres.pl/jakasstrona.php
przy zalozeniu, że ów użytkownik wydający taką komendę ma bardzo szybki dostęp do sieci (w miarę równy w stosunku do pasma na którym pracuje atakowany serwer) istnieje bardzo duże prawdopodobeństwo, że taki "test" na czas wykonywania go skutecznie zablokuje dostęp do strony www innym użytkownikom. Taki wandalizm nieco innego typu niż sql injection.
Ataki sql injection, cookie injection, xss injection, ddos i wszystkie podobne są najczęściej niczym innym niż przejawem jakiegoś "sieciowego wandalizmu", który moim zdaniem pomimo wszystko jednak powinien być tępiony.
Gdyby takich wyroków było więcej boję się myśleć o tym jak może wyglądać przyszłość wielu tysięcy stron dla których są gotowe tzw. exploity, co gorsza nie wymagające kompletnie żadnej wiedzy do użycia. Więc co by nam pozostało? Jak ktoś nam "zjedzie bloga", to my mu też? (o ile wiemy kto to)
Wt, 2009-01-13 10:36 by ksiewi
O ile się nie mylę sąd zdecydował, że w niniejszej sprawie nie doszło do przełamania zabezpieczeń, a nie że działanie oskarżonego nie jest w ogóle przedmiotem regulacji prawnych. Dla przykładu - jeżeli oskarżony wyrządził komuś szkodę, to nadal przecież może ponosić odpowiedzialność cywilną, czyż nie?
proszę lepiej tego nie próbować
Wt, 2009-01-13 12:22 by Maciej_Szmit
Pn, 2008-10-06 21:58 by artur kmieciak (niezweryfikowany)
Proszę czytać dokładnie treść przepisu art. 267 kk, a nie fantazjować co się Panu wydaje, na zasadzie wolnych skojarzeń.
To prawo karne gdzie wszystko MUSI być jasne i nie ma miejsca na dywagacje czy, coś jest ominięciem zabezpieczeń, a coś nim nie jest, chociażby z tego powodu, że przepis art. 267 w ogóle nie zajmuje się "omijaniem" tylko przełamywaniem elektronicznych, magnetycznych albo UWAGA! innych szczególnych zabezpieczeń.
Wpisanie ciągu znaków nie jest przełamaniem zabezpieczeń. Koniec. Kropka.
Pański przykład z wytrychem jest kompletnym nieporozumieniem ponieważ jego użycie jest właśnie przełamaniem zabezpieczeń, a opisane przez Pana czynności "pasowania" takiego klucza stanowią karalne czynności przygotowawcze. Do włamania. Nie do "omijania".
Dlatego zupełnie błędne jest pańskie przekonanie, że "Gdyby ten kolega wszedł wtedy do mojego domu, nie byłbym zadowolony, a sąd zapewne uznał by to za "ominięcie zabezpieczeń"."
Sąd nie uznałby tego za "omijanie" tylko włamanie właśnie. Poza tym sąd nie zajmuje się z pewnością czyimkolwiek zadowalaniem.
Nie jest natomiast włamaniem otwarcie drzwi z pozostawionym w zamku kluczem albo zaopatrzonych tylko w haczyk i skobel, który każdy może bez trudu usunąć.
To tyle jeśli chodzi o analogie ze światem materialnym.
MUSI być jasne?
Śr, 2008-10-08 10:16 by np (niezweryfikowany)
Z analogii do świata materialnego zdążyłem się wycofać już wcześniej, przyjmuję argumentację.
Nie zgodzę się natomiast ze stwierdzeniem że w prawie "wszystko MUSI być jasne" - nie jest i nie będzie.
Wystarczy przypomnieć sprawy analiz i eksperyz prawnych - w wielu sprawach doktorzy i profesorowie prawa wydają skrajnie różne opinie - nieraz było o tym głośno w mediach.
Każdy prawnik z którym się spotkałem nie mówi "jest tak i tak" a mówi "w mojej opinii", albo "w opinii sądu tego czy owego". W dodatku interpretacja sądu A bywa różna od interpretacji sądu B. A w ogóle dlaczego mówimy o "interpretacji" jeżeli wszystko jest jasne?
Nic nie jest jasne i raczej nie będzie gdyż większości polityków zaangażowanych w tworzenie prawa absolutnie na tym nie zależy.
(do mederatora: wiem, wiem, wpada w politykę a na vagla.pl tego ma nie być, dlatego dalej już wątku nie ciągnę).
Musi być jasne
Śr, 2008-10-08 11:39 by artur.kmieciak@...
aby kogokolwiek skazać - jak jest z tą zasadą w praktyce to ina sprawa.
Świat realny != Matrix
Pn, 2008-10-06 22:53 by Makdaam
Chciałbym tylko dodać do odpowiedzi VaGli, że najważniejszą różnicą między światem realnym, a realiami internetowymi są sztywne zasady. Głównie chodzi o nieprzenikanie przez siebie materii w stałym stanie skupienia oraz zachowanie lokalne zasad dynamiki Newtona (nic się samo nie teleportuje). Do tego dochodzi grawitacja i parę innych ciekawych zasad.
Co do SQL injection, w każdej książce o zabezpieczeniach, którą miałem w ręku, SQL injection jest nazywane błędem implementacyjnym. Na jakiej innej zasadzie użytkownik ma określić co jest dozwolone, a co nie jest dozwolone, jeżeli jedyną obowiązującą zasadą jest często "możesz robić to na co pozwoli Ci nasze oprogramowanie".
Na rozluźnienie komiks: XKCD 327
nie rownaj drzwi od
Pt, 2008-10-17 18:20 by incognitus (niezweryfikowany)
nie rownaj drzwi od mieszkania z dzialaniem majacym na celu poprawienia bezpieczenstwa polskiej sceny informatycznej. nie 1=1 tylko ' or 1=1/* albo cos w te desenie zalezy komu jak klawa lezy. oskarzony wpisal w polu loginu i hasla ten sam ciag znakow ja bym uznal go za niewinnego juz za samo to przeciez komentujac juz w loginie w polu hasla mozna wpisac cokolwiek. jeszce moze wspomne o tym ze wejsc maja nowe przepisy ktore zabronia uzyskania dostepu do informacji nie dla nas.wiec google indexuje wszystko nawet bledy admina, jesli admin sie nie postaral to mam zostac ukarany za to ze wyszukiwarka pokazala mi wyniki ktorych on nie chcial pokazac ale tez nie chcial/nie umial ich zabezpieczyc przed takim odczytem? prosta refleksja czy ja mam byc karcony za to ze ktos sklepal dziurawy kod strony?
Pn, 2008-10-06 13:37 by incognitus (niezweryfikowany)
"Co znajdziemy w uzasadnieniu wyroku Sądu Rejonowego w Głogowie? W pierwszej kolejności opis podjętych przez niego działań. Odwiedził on stronę internetową i stwierdził, że serwis zawiera błędy."
W cytowanym tekście sąd jest podmiotem, więc wygląda to tak, jakby sąd odwiedził stronę i znalazł błędy :)
"W pierwszej kolejności opis podjętych przez pana Mateusza działań."
A co z resztą wątków tej sprawy?
Pn, 2008-10-06 14:13 by jell (niezweryfikowany)
Oskarżony został zatrzymany bez podania mu zarzutów. Policjanci grozili mu pobiciem, a jego rodzicom grozili bronią, w trakcie przesłuchiwania.
Niesłusznie oskarżony został pozbawiony środków zarobkowych (mimo iż po ich zabezpieczeniu, poprzez skopiowanie danych - środki te mogły zostać zwrócone niemal natychmiast) na ponad rok (a być może i dłużej).
Domyślam się, że znużenie oskarżonego tą sprawą (a więc i chęć zapomnienia o tym wszystkim) sięgnęły już takiego poziomu, że najprawdopodobniej wspomniane poboczne wątki zostaną pozostawione bez dalszych działań.
Z ciekawości zapytam - co w ogóle można w takiej sytuacji zrobić? Chodzi mi o takie traktowanie przez policję (groźby pobicia, wymuszanie zeznań), jak i bezczelne traktowanie przez prokuraturę:
Ciekawsze i więcej wnoszące do sprawy wydają się kolejne pytania, w odpowiedzi na które biegły stwierdza, że na zabezpieczonych dyskach nie ma programów służących do przełamywania zabezpieczeń. Jednak najistotniejsze jest to, że biegły stwierdził, iż nie doszło do przełamania zabezpieczeń serwera, o co wytrwale oskarża mnie Pani Prokurator
jak i dalej
Wystąpiłem także do Prokuratury z żądaniem uzasadnienia postanowienia o przedstawieniu zarzutów, które zostało wydane jakiś czas po opinii biegłego. Zaskakujące wydaje się w nim stwierdzenie Pani Prokurator, iż przeprowadzone w toku postępowania czynności w tym przesłuchanie świadków jak również opinia biegłego pozwoliły na ustalenie, że „przełamałem elektroniczne zabezpieczenia serwera” (!!!) co całkowicie nie zgadza się z opinią biegłego, który jednoznacznie napisał, że do przełamania zabezpieczeń nie doszło!
Gratulacje i uciechy
Pn, 2008-10-06 14:43 by bla (niezweryfikowany)
Bardzo się cieszę z tego wyroku i gratuluję Mateuszowi, którego sprawę śledzę od początku, gdyż -- jest mi dość bliska. Wielokrotnie zdarzało mi się znajdować różne luki i informować o tym autorów; raz skończyło się to pracą, wielokrotnie podziękowaniami (nawet dostałem raz pocztą książkę!) i chyba tylko raz ktoś był definitywnie niezadowolony.;p
Sposób działania tamtej firmy, wywołane przez nią problemy były naprawdę nieproporcjonalne do sytuacji. Żal, że za sprawę zapłaci US, no ale cóż, w końcu to KK. Pewnie też Mateuszowi nie będą rekompensować nerwów, przepadku sprzętu na dość długi czas etc.
A ja bym chcial sie
Pn, 2008-10-06 22:20 by zxc (niezweryfikowany)
A ja bym chciał się dowiedzieć, co po tego typu wyrokach dzieje się z biegłym sądowym, który wystawia opinie o "wydobyciu poufnych informacji z bazy danych i zakłóceniu jej funkcjonowania"? czy ze spokojnym sumieniem podejmuje się kolejnego "dochodzenia" mającego na celu wyjaśnić czy zainstalowanie uTorrenta na komputerze świadczy, iż podejrzany stanowi forpocztę pirackiego światka, za co wypłacana jest mu co miesiąc pensja z moich podatków?
Zresztą o świetlaną przyszłość pani prokurator oskarżającej też chciałbym się czegoś więcej dowiedzieć :) w końcu w czasach braku ZSMP takie samorodne talenty w walce o świetlaną przyszłość mogą niejednym nas jeszcze zaskoczyć
pozdrawiam zdrowy rozsądek wysokiego sądu :)
Czym wobec tego jest przełamanie?
Pn, 2008-10-06 22:47 by przepla
W przeciwieństwie do większości wyrok SR w Głogowie jest dla mnie niezrozumiały. Zgadzam się z np, że w informatyce każde włamanie sprowadza się de facto do znalezienia luki. Skoro użycie SQL Injection w formularzu logowania nie jest przełamaniem zabezpieczeń ale obejściem zabezpieczeń to jaki charakter musi mieć działanie sprawcy aby jego zachowanie można by określić przełamaniem zabezpieczeń? Czy użycie znanego z Matrixa exploita ssh też będzie obejściem zabezpieczeń? W końcu oba przypadki różnią się tylko tym, że Matusz wysłał specjalnie spreparowane pole formularza, a Trinity specjalnie spreparowany pakiet ssh1.
Jaki rodzaj włamania będzie przełamaniem zabezpieczeń a nie ich obejściem?
I druga sprawa, moim zdaniem najgroźniejsza, jaka wypływa z omawianego wyroku:
By odpowiedzieć na [...] pytanie [czy wpisanie przez oskarżonego określonego ciągu znaków i zastosowanie SQL Injection jest przełamaniem zabezpieczenia programu w rozumieniu art. 267 § 1 K.k.] oskarżyciel publiczny [a potem Sąd] powołał biegłego sądowego ...
Sąd powołał biegłego do dokonania wykładni przepisu ustawy! Biegły nie ma prawa wypowiadać się co do tego, czy dane zachowanie wypełnia czy też nie znamiona przepisu ustawy, od tego jest tylko i wyłącznie sąd [1] [2] [3] Co więcej dobry biegły na tak zadane pytanie powinien odmówić odpowiedzi na pytanie. Inna rzecz, że dokonywanie przez biegłego oceny prawnej zdarzenia jest bardzo wygodne dla organu procesowego...
fn1. Opinia biegłego nie powinna zawierać sformułowań dotyczących winy oskarżonego lub oceny prawnej jego czynu, ponieważ uprawnienia w tym zakresie są wyłączną domeną sądu. (III KR 235/87) fn2. Subsumpcja prawna czynu w ogóle nie jest rzeczą biegłego, a organów procesowych. (II AKz 72/94) fn3. Stosowanie normy prawnej, wyrażającej w sposób uogólniony tzw. ustawowy stan faktyczny, do konkretnego zespołu zdarzeń czy zjawisk, albo właściwości, jest zawsze wynikiem procesu myślowego, dokonywanego przez sędziego, a nie przez biegłego. (I KZ 102/58)
Sąd nigdy nie prosił
Pn, 2008-10-06 23:01 by Mateusz.M
Sąd nigdy nie prosił biegłego o ocenianie stanu prawnego, jak również biegły w swojej opinii nigdy takich sformułowań nie stawiał. Być może cytowane zdanie może prowadzić do takich wniosków jednak zapewniam, że tak nie było. Pytania kierowane do biegłego były dość szczegółowe, techniczne i na pewno nie dotyczyły oceny stanu prawnego.
Jeśli chodzi o 'łamanie zabezpieczeń' to uważam, że np. wszelkiego typu taki brute-force byłyby takim działaniem.
Wt, 2008-10-07 00:10 by artur.kmieciak@...
"Zgadzam się z np, że w informatyce każde włamanie sprowadza się de facto do znalezienia luki."
No nie jestem pewien. Czy złamanie hasła dostępu do konta zawsze jest równoznaczne ze znalezieniem luki?
Rzecz do dyskusji dla specjalistów.
Ale skoro przy specjalistach jesteśmy - to sąd powołuje biegłych wszędzie tam, gdzie konieczne jest zasięgniecie wiadomości specjalnych.
Proszę mi wytłumaczyć w jaki to sposób sąd ma rozstrzygnąć, bez wiadomości specjalnych, czy doszło do przełamania zabezpieczeń skoro kwestia ta jest przedmiotem kontrowersji wśród samych informatyków, a czego najlepszym dowodem jest niniejsza dyskusja?
Jeśli pańskim zdaniem prowadzi to do "wykładni ustawy" dokonywanej przez biegłego, to proszę mieć pretensje do ustawodawcy, a nie do sądu, który próbuje ustalić podstawowe okoliczności składające się na stronę przedmiotową czynu.
Proszę łaskawie wykazać, że w tej sprawie doszło do przełamania zabezpieczeń - tak jak to utrzymywała w akcie oskarżenia prokuratura.
Skoro sąd Pańskim zdaniem bezpodstawnie dopuścił dowód z opinii biegłego to na jakich przesłankach opierała się prokuratura? Na przeczuciach autora aktu oskarżenia? A może na tym co powiedzieli jej przedstawiciele "pokrzywdzonej" firmy? Niezłe dowody. W sam raz na skazanie.
Proszę nie zapominać właściwej kolejności zdarzeń. To nie seminarium akademickie tylko realny proces karny z prawdziwym aktem oskarżenia. Na czym opierał się ten ostatni skoro nie jest, jak to Pan twierdzi, dopuszczalna opinia biegłego?
Kto komu ma tu cokolwiek udowadniać?
Prokuratura oskarżonemu, czy ten prokuraturze?
Swoją drogą to dość dziwne, że martwi Pana postępowanie sądu, a nie martwi Pana postępowanie prokuratury, która ciągnie człowieka do sądu nawet nie zadając sobie trudu ustalenia czy podstawowa, e l e m e n t a r n a przesłanka odpowiedzialności z art. 267 kk w ogóle została spełniona.
P.S. Exploit to kod - narzędzie, którego przeznaczeniem jest dokonywanie nadużyć.
To wytrych. W niniejszej sprawie oskarżony nie posługiwał się żadnym narzędziem programistycznym, czy jakimkolwiek innym.
Co do szczegółów tego co może być przełamaniem zabezpieczeń polecam prace prof. Adamskiego.
Wt, 2008-10-07 01:49 by przepla
Nie twierdzę, że Sąd miał nie powoływać biegłych. Twierdzę tylko, że rola biegłego w tej (i w każdej innej sprawie) powinna ograniczyć się do wyjaśnienia Sądowi przebiegu zdarzenia. Na podstawie zapisów w logach systemowych, skutków czynu i innych danych biegły powinien podać sądowi w jaki sposób przebiegało zdarzenie (mówiąc kolokwialnie opowiedzieć sądowi, że oskarżony wszedł na stronę internetową, w formularzu napisał 1=1 i nacisnął submit). Następnie biegły powinien wyjaśnić sądowi jakie skutki owo napisanie magicznego 1=1 miało. Nic ponadto.
Dlaczego nie krytykuję Prokuratury? Ano dlatego, że uważam, że słusznie skierowano akt oskarżenia. Na tyle na ile znany mi jest stan faktyczny w sprawie, podzielam pogląd prokuratora-referenta, że zachowanie oskarżonego wyczerpało znamiona przestępstwa określonego w art. 267 § 1 kk. Uważam, że rozważanie czy była luka w zabezpieczeniach czy nie wprowadza do przepisu tylnymi drzwiami zapis o tym, że zabezpieczenie ma być skuteczne. Tymczasem elektroniczne zabezpieczenie (jak zaklejona koperta także występująca w tym przepisie) oznacza tylko intencję dysponenta informacji, że nie chce aby dotarły do niej osoby postronne. To że zaklejona koperta jest nieskuteczna przed najprostszym atakiem "steam injection" nie powoduje, że sprawca zapoznawszy się przy pomocy tej metody z informacjami nie popełnia przestępstwa z art. 267 kk. Tak samo okoliczność, że baza danych nie była zabezpieczona przed najprostszym SQL Injection nie oznacza, że przełamanie tego zabezpieczenia nie wypełnia znamion przestępstwa.
Inaczej mówiąc, odmiennie niż Sąd Rejonowy, stoję na stanowisku, że do wyczerpania znamion czynu z art. 267 § 1 kk wystarczy ustalenie, że sprawca wiedząc, że intencją dysponenta informacji było ograniczenie do niej dostępu, niezależnie od tego jak mało skuteczne owo zabezpieczenie było, zabezpieczenie przełamał i z informacją zapoznał się.
Sąd niepotrzebnie analizując sprawę pod kątem tego, że SQL Injection był możliwy ze względu na błąd programisty pomieszał aparat pojęciowy nauki prawniczej z aparatem
pojęciowym nauki informatycznej w wyniku czego podjął błędną decyzję przyjmując, że nie nastąpiło przełamanie zabezpieczeń.
Moim zdaniem sprawa przełamanie zabezpieczenia następuje wtedy, kiedy sprawca dostaje się do danych rozpoczynając w miejscu przewidzianym przez dysponenta danymi (tu: formularz logowania), natomiast obejście zabezpieczenia ma miejsce wtedy sprawca w ogóle nie ma kontaktu z zabezpieczeniem (np. deep linking).
Zauważmy, że występujące w tym przepisie zamknięte pismo jest chronione w identyczny sposób -- otwarcie koperty -- czyn zabroniony, obejrzenie koperty pod światło -- czyn dozwolony.
Ryzykując zwrócenie mi uwagi, że mieszam świat wirtualny z rzeczywistym, Sąd Rejonowy niejako uzależnił przypisanie przestępstwa kradzieży z włamaniem (art.279 kk) od jakości zamka, przyjmując, że jeśli zamek jest tak słaby, że da się otworzyć wkładając palec do dziurki to nie ma włamania.
czy istotnie dozwolony?
Wt, 2008-10-07 02:02 by VaGla
Zastanawiam się nad tą argumentacją i przy takim podejściu teza:
obejrzenie koperty pod światło -- czyn dozwolony.
również wydaje się nieprawidłowa. Ponieważ - idąc tym tropem - doszło do zapoznania się z informacją dla sprawcy nieprzeznaczoną, przełamując "inne szczególne jej zabezpieczenie".
"niezależnie od tego jak
Wt, 2008-10-07 08:20 by artur.kmieciak@...
"niezależnie od tego jak mało skuteczne owo zabezpieczenie było, zabezpieczenie przełamał i z informacją zapoznał się."
Proszę zatem opisać na czym polegało w tej sprawie zabezpieczenie i na czym jego "przełamanie"?
W jaki sposób wyglądało działanie sprawcy czyli jak sprawca przełamał zabezpieczenie?
Drogi Panie - czy czyta Pan to, co sam pisze? Sąd stwierdził, że nie było żadnego zamka. Proszę zwrócić uwagę na tytuł komentowanego artykułu.
Śr, 2008-10-08 00:08 by przepla
Zabezpieczeniem był formularz wymagający podania poprawnego hasła.
Przełamaniem zabezpieczenia było umyślne wpisanie w pole formularza nieprzypadkowego ciągu znaków nie będących hasłem i naciśnięcie "submit" tak aby wyzyskując błąd w systemie zapoznać się z danymi co do których sprawca nie był uprawniony.
Nie mogę się oprzeć kolejnym analogiom (ale chyba się bez nich nie da, chociażby dlatego, że warto pomocniczo stosować orzecznictwo definiujące włamanie przy kradzieży z włamaniem)
1. Formularz to zamek;
2. hasło do formularza to klucz;
3. poprzez włożenie klucza do zamka otwieramy pomieszczenie, poprzez wpisanie hasła do formularza otwieramy dostęp do danych;
4. zamek możemy otworzyć także wytrychem; formularz możemy "otworzyć" SQL injection;
5. otworzenie zamka wytrychem to przełamanie zabezpieczeń drzwi=włamanie, użycie SQL injection to przełamanie zabezpieczeń formularza=włamanie.
Zastanawiam się czy nie jest przypadkiem tak, że w języku informatycznym "przełamanie" implikuje coś co stawia duży opór. Skoro opór stawiany był mały to zdaniem informatyka nie było przełamania a "obejście".
Śr, 2008-10-08 09:57 by artur.kmieciak@...
Vagla słusznie nas przywoływał do porządku z tymi analogiami i pański przykład jest najlepszym dowodem na to, że miał rację, a to dlatego,że pańskie zestawienia typu "hasło - klucz" jest całkowicie arbitralne.
Jeszcze raz podkreślam, że nie doszło ani do złamania hasła, ani jego odgadnięcia, ani sprawca nie znalazł się w jakikolwiek inny sposób w jego posiadaniu, a tylko w takim wypadku analogia z wytrychem byłaby zasadna. Przyjmijmy raz na zawsze, że sprawca nie zajmował się żadnym zamkiem.
Jeśliby Mateusz w jakikolwiek sposób złamał hasło (nawet metoda siłową, która technicznie nie jest "złamaniem"), którym przecież każdy z użytkowników powinien dysponować to byłaby inna historia ale ten nie podjął żadnych czynności w tym kierunku.
Zapytanie SQL nie jest żadnym ekwiwalentem hasła po prostu.
Mateusz sformułował zapytanie do bazy danych, a ta na skutek swojego błędu udzieliła mu błędnej odpowiedzi.
Równie arbitralne i nie znajdujące uzasadnienia w zasadach sztuki inżynieryjnej jest traktowanie przez Pana formularza jako zabezpieczenia. Nie zabezpieczanie jest jego przeznaczeniem, chyba że przyjmiemy za Panem, iż zabezpieczeniem jest wszystko, każde narzędzie, bez którego nie możemy uzyskać dostępu do danych (tak to Pan wcześniej przedstawił).
Tylko, że w takiej sytuacji narzędziem takim, bez którego (w naszym przypadku) nie było możliwe uzyskanie dostępu do bazy danych jest przeglądarka internetowa, a nawet (czemu nie?) - system operacyjny i można brnąć dalej, że i sam komputer bez włączenia którego sprawca nie uzyskałby dostępu do danych.
Absurd? Jak najbardziej - ale takie są niestety konsekwencje pańskich założeń.
Mało tego, samo życie napisało w tej kwestii dosyć absurdalny scenariusz. Kilka lat temu głośno było o sprawie "hakera", który to "wykradł" teledysk z serwera. Problem w tym, że ten niczego nie wykradł, ani niczego nie ominął, ani nie przełamał, tylko metodą prób i błędów, wpisując "ciągi znaków" czyli adresy url trafił na ów plik, NIEZABEZPIECZONY w żaden sposób na serwerze. Jemu też postawiono zarzut "hakingu", co wywołało powszechną konsternację.
A on nie zrobił nic innego jak wpisał ciąg znaków w określone miejsce - zupełnie jak Mateusz. Także nie zajmował się żadnym hasłem. Tak samo uzyskał dostęp do danych dla siebie nie przeznaczonych(bezsporne).
Skoro rolą formularza
Śr, 2008-10-08 17:32 by przepla
Skoro rolą formularza logowania nie jest zabezpieczenie to jaka wobec tego jest jego rola? W szczególności jaka jest rola tego formularza?
Skoro formularz logowania wygląda jak coś co zabezpiecza, zachowuje się tak, że zabezpiecza (przynajmniej przed niektórymi metodami dostępu) to służy do zabezpieczania. Tak przynajmniej sądzę.
Wydaje mi się, że Mateusz nie zadał zapytania SQL, tylko wpisał pewien ciąg znaków, który został zinterpretowany przez błędnie napisany program jako zapytanie SQL.
Ma Pan rację, całe moje rozumowanie opiera się tym, że uważam formularz logowania za "zamek"=zabezpieczenie. Przy przyjęciu, że tak nie jest nie ma o czym mówić. Nie było przestępstwa i nastąpiło obejście zabezpieczeń równoważne np. deep linking.
Wkraczamy na niższy poziom.
Śr, 2008-10-08 18:41 by Makdaam
Rolą formularza, a właściwie rolą przeglądarki interpretującej kod formularza jest przesłanie danych wprowadzonych przez użytkownika do zdalnego systemu, który w odpowiedzi prześle odpowiednie dane.
Mogę te same dane wysłać bez pomocy formularza czy przeglądarki (telnet prawo.vagla.pl 80). Rolą zabezpieczenia po stronie systemu zdalnego jest określenie na podstawie przesłanych przeze mnie danych czy jestem uprawniony do czegoś więcej niż dokumentu HTML zawierającego opis błędu 401.
Jeżeli wyślę dane zgodnie ze specyfikacją w formularzu (pola tekstowe, checkboxy itp.) i system na podstawie tych danych stwierdzi, że jestem uprawniony do np. otrzymania listy pracowników, to znaczy że jestem uprawniony do otrzymania listy pracowników albo system jest błędnie skonstruowany.
Śr, 2008-10-08 20:12 by artur.kmieciak@...
Otóż to, przeznaczeniem formularza jest przesyłanie danych a nie ich zabezpieczanie.
Jest to istotne rozróżnienie na gruncie art. 267 gdzie mowa jest o przełamywaniu zabezpieczeń: elektronicznych, magnetycznych czy Innych szczególnych zabezpieczeń. Ustawodawca nie bez przypadku tak właśnie sformułował przesłanki odpowiedzialności aby chodziło o narzędzia, których celem jest zabezpieczeniem, można w dużym uproszczeniu powiedzieć, że narzędziom hmmm "dedykowanym".
Sytuacja się zmieni po nowelizacji, gdzie penalizuje się uzyskanie nieuprawnionego dostępu do danych poprzez czynności polegające na "omijaniu" zabezpieczeń czyli cały zbiór dozwolonych w chwili obecnej czynności.
No i teraz będzie się działo.
Czy SQL Injection polega na "omijaniu" zabezpieczeń?
W takim razie gdzie jest
Śr, 2008-10-08 20:34 by przepla
W takim razie gdzie jest zabezpieczenie (w którym miejscu) w sytuacji dostępu do danych po wypełnieniu formularza z danymi autentykującymi?
Śr, 2008-10-08 21:05 by artur.kmieciak@...
No właśnie. Gdzie jest?
or 2=2
Wt, 2008-10-14 18:00 by or 1=1 (niezweryfikowany)
Zabezpieczenie jest w skryptach, które powinny sprawdzić, czy taki a taki user w bazie danych istnieje i jeśli tak, to czy hasło jakie on podał (a może odpowiednia funkcja skrótu?) się zgadza z tym, zapisanym w bazie danych.
--mt3o
ps. wpisałem w pole z tytułem postu i nazwą usera ciąg w pewnych warunkach mogący być częścią zapytania SQL. Próbuję omijać jakieś zabezpieczenia? No już nie żartujcie panowie :)
ps2. Znam kogoś, kto ma nick 7=8. To też może być część zapytania SQL i prowadzić do SQL Injection.
Śr, 2008-10-15 23:31 by Marcin Gryszkalis
Chyba jeszcze nikt w tym wątku nie wspomniał: http://xkcd.com/327/ :)
Śr, 2008-10-08 22:32 by Marcin Gryszkalis
Widzę, że powoli dochodzimy do coraz precyzyjniejszych definicji. Spróbowałbym to jeszcze bardziej skonkretyzować. Celowo od razu nie użyję słowa "zabezpieczenie" aby nie pozwolić na zbyt szybkie odrzucenie modelu.
Kontrola dostępu (ang. access control) - mechanizm umożliwiający zezwalanie (permit) albo blokowanie (deny) dostępu do zasobu. Klasycznie definiowana kontrola dostępu składa się z 3 elementów: autentykacja, autoryzacja i audyt.
Audyt w tym kontekście nas nie interesuje.
Autentykacja to potwierdzenie tożsamości użytkownika. Może opierać się na różnych mechanizmach: wiedzy (hasło, pin), posiadaniu (klucz, telefon, karta magnetyczna), "byciu" (cechy własne użytkownika - odcisk palca, DNA, źródłowy adres IP).
Autoryzacja to stwierdzenie czy danemu zidentyfikowanemu użytkownikowi można pozwolić na dostęp do zasobu, o który prosi.
Z powyższych definicji wynika, że autentykacja musi poprzedzać autoryzację (nie rozważamy autoryzacji nieznanego użytkownika, ewentualnie identyfikujemy go jako "anonimowego" i określamy jakie uprawnienia przysługują takiemu użytkownikowi).
Formularz HTML jest sposobem opisu danych, które muszą być przesłane do serwera aby wykonać autentykację.
Elementami wymaganymi do poprawnej autentykacji są w typowym przypadku nazwa użytkownika (login) i hasło. Przyjmujemy, że jesli użytkownik podał poprawny login i poprawne odpowiadające loginowi hasło to jest on użytkownikiem, do którego login jest przypisany (uznajemy, że wystarczająco potwierdził swoją tożsamość).
Mateusz wprowadzając ciąg '+OR+1=1 wymusił błędne zachowanie mechanizmu autentykującego, który zidentyfikował go jako przypadkowego użytkownika X (przypuszczalnie pierszego lub ostatniego - w sensie kolejności dodawania do bazy - aktywnego użytkownika). W konsekwencji mechanizm autoryzacji (działający poprawnie) pozwolił Mateuszowi wykonywać takie działania, do których miała prawo osoba X.
Oczywiście taki mechanizm autentykujący, który tak łatwo wprowadzić w błąd jest do kitu. Nie mogąc się oprzeć analogiom to tak jakby posadzić niedowidzącego, żeby na bramce przepustki oglądał. Jednakże właściciel (firma) posadziła strażnika (tyle, że strażnik się nie przyznał, że jest niedowidzący).
Dla porówanania deep-linking (przypadek Precious) - brak tu wogóle mechanizmu autentykacji (i w konsekwencji autoryzacji). Kropka.
Czy to wystarczająco precyzyjny opis sytuacji?
Tylko nie AUTENTYKACJA!
Cz, 2008-10-09 21:21 by kravietz
Słowo AUTHENTICATION to po polsku UWIERZYTELNIENIE. Patrz m.in. norma PN-I-02000.
Rozpowszechnienie tej odrażającej kalki językowej w dokumentacji technicznej produktów sieciowych dostępnych na polskim rynku nie usprawiedliwia jej stosowania :)
Co to znaczy wymusił?
Cz, 2008-10-09 21:52 by Mateusz.M
Co to znaczy wymusił? System autoryzacji otrzymał poprawne dane wejściowe, a to co zrobił z nimi później użytkownika nie powinno interesować. Ciąg znaków, o którym mówimy mieści się w zakresie dopuszczalnych znaków dla pól formularza typu text/password. Z tego wniosek, że formularz został poprawnie wykorzystany a programista przewidział możliwość otrzymania ciągów zbudowanych ze znaków mieszczących się we wspominanym zakresie. Mnie jako użytkownika nie obchodzi czy system autoryzacji przechowuje dane w bazie danych i do komunikacji z nią wykorzystuje SQL, czy może dane zapisane są w pliku. Użytkownik podaje login/hasło i oczekuje, że system go autoryzuje bądź nie. Jeśli system został błędnie skonstruowany, bez zachowania podstawowych zasad i norm, to jest to wyłącznie wina programistów. Nie mówiąc już o tym, że od dawna magic_quotes jest domyślnie włączone w PHP, a funkcja ta zabezpieczyłaby system przed podobnymi problemami. Jeśli programista, inżynier po studiach, ją wyłącza i samodzielnie nie stosuje funkcji filtrujących, to dlaczego za jego działania mieliby odpowiadać użytkownicy?
Niestety PHP jest językiem, który wiele wybacza, a aplikacje internetowe, nawet "renomowanych" firm są tragiczne pod względem bezpieczeństwa. W momencie gdy dojdzie do sytuacji w jakiej ja się znalazłem, szukany jest kozioł ofiarny, na którego można zwalić winę. Nazywa się go "hackerem", całe zajście "włamaniem" i po sprawie. Można zająć się sprzedawaniem i produkowaniem kolejnych bubli.
Pn, 2008-10-13 15:33 by incognitus (niezweryfikowany)
Cały czas czekamy na nazwę firmy, która Cię tak urządziła.
Co w kwestii unieważnienia umowy o zachowaniu tajemnicy z powodu wprowadzenia Cię w błąd?
Pytanie do Mateusza M.
Śr, 2008-10-15 09:24 by incognitus (niezweryfikowany)
Czy wiedziałeś co uzyskasz wpisując ten konkretny ciąg?
Jeśli wiedziałeś to celowo wykorzystałeś lukę w systemie - tak jakbyś wiedział, że okno na parterze jest otwarte i byś wszede przez nie do domu (nie będąc zaproszonym:) - nie jestem prawnikiem, ale to też jest chyba niedozwolone (naruszenie miru domowego czy coś w tym stylu, lub zupełnie coś innego), podem zabrał (np.) dowód osobisty z szafki,
Jeśli zaś nie wiedziałeś, to po stwierdzeniu, że usyzkałeś dostęp do danych nie dla ciebie przeznaczonych, trzeba było poprostu wyść (jeśli przez przypadek wchodzę do domu, do którego ie byłem zaproszony, to chyba niezwłocznie z niego wychodzę a nie szukam czegoś)
Chodzi mi o sam sposób poniformowania o dziurze - wyastarczyło napisać, że taka istnieje i tyle
Śr, 2008-10-08 09:59 by axis (niezweryfikowany)
analogie ... coz przedstawie swoja troszke bardziej z moralnego pktu widzenia:
W calym pionie w bloku pewna firma X wymienia dzwi.
Wszyscy dostaja takie samo kolorystycznie jak i stylistycznie wrecz kropka w kropke.
Po skonczonej pracy firma zgarnia kase za dobrze wykonana robote,zabiera sie z pionu, wszyscy sa zachwyceni swiezoscia designu i szybkoscia wykonania uslugi
W pewien sobotni wieczor lekko "zawiany" sasiad przez przypadek myli pietra i o zgrozo otwiera swoim kluczem cudze dzwi.
Rano biegnie do sasiada i mowi: te sasiad wczoraj wieczorem (...) zobacz jak nie wierzysz (...) wymien zamki bo cholera wie kto Ci tu moze wejsc, wyniesc wszystko a Policja moze "mimo usilnych prob niestety przestepcy nie zdolano ustalic"
a) Dziekujesz sasiadowi,wymieniasz zamki,dzwonisz do firmy i mieszasz ich z blotem domagajac sie zadoscuczynienia za narazenie na kradziez oraz informujesz o ich niekompetencji pozostalych sasiadow
b) Oskarzasz sasiada o wlamanie, olewasz firme, olewasz zmiane zamkow a pewnego razu profesjonalny zlodziej orientuje sie ze po wymianie dzwi w jego bloku moze wejsc do sasiadow oraz innych klientow tej firmy i czysci wszystkie mieszkania jak leci TIRami ;)
@kravietz w zupelnosci zgadzam sie z jego pogladami
@Mateuszowi i wladzom sadowniczym gratuluje wg mnie sprawiedliwego wyroku
Tyle, że (bo jak rozumiem
Śr, 2008-10-08 17:19 by przepla
Tyle, że (bo jak rozumiem próbuje Pan metaforycznie przyrównać pańską opowieść do omawianej sprawy sądowej) sąsiad wszedł przypadkiem (nieumyślnie), natomiast sprawca zrobił to umyślnie.
Clou mojego toku rozumowania
Pt, 2008-10-10 14:09 by axis (niezweryfikowany)
Clou mojego toku rozumowania było takie ze:
Trzeba piętnowac systemy bezpieczeństwa, których jedynym zabezpieczeniem jest stwierdzenie "za włamanie kara pozbawienia wolności na x lat" (bo panel logowania pozwalający na logowanie użytkownika nie będacego w bazie pracowników/klientów itp nie traktuje jako jakikolwiek system zabezpieczenia).
Użytkownicy muszą być świadomi, że osoba trudniąca się zdobywaniem informacji (szpiegostwo przemysłowe) raczej nic sobie z tego nie zrobi i może być na tyle dobra, że jej wykrycie może graniczyć z cudem.
Powinni wymagać OD OSOBY, KTÓRA PRZYGOTOWUJE dla nich dany serwis, zresztą za niemałe pieniądze, że serwis oprócz ładnego wykonania (wyglądu) zbyt łatwo się nie podda przy próbach włamań rzeczywistych crackerow, a ujawnione luki będą eliminowane w jak najszybszym czasie.
Co do osób, które jak dobry sąsiad powiedzą o tym właścicielowi a nie potencjalnemu złodziejowi... Cóż, zamiast być ciągane po sadach powinny być całowane po rękach.
od czego (nie)jest biegły
Śr, 2008-10-08 01:13 by Maciej_Szmit
Twierdzę tylko, że rola biegłego w tej (i w każdej innej sprawie) powinna ograniczyć się do wyjaśnienia Sądowi przebiegu zdarzenia.
Według orzeczenia SN z 11 lipca 1969 roku, zadaniem biegłego nie jest ustalanie stanu faktycznego sprawy, lecz naświetlenie i wyjaśnienie okoliczności sprawy z punktu widzenia posiadanych przez biegłego wiadomości specjalnych przy uwzględnieniu zebranego i przedstawionego biegłemu materiału sprawy.
Generalnie odnoszę wrażenie, że w praktyce rola biegłego jest, że tak powiem, elastyczna. W pracach prof. Marka są wręcz przykłady opinii gdzie kwalifikuje on uszkodzenie ciała jako lekkie albo ciężkie i tym samym spełniające hipotezę odpowiedniego artykułu KK czy KW (już nie pomnę). Z jednej strony ja bym analogicznej opinii pewnie nie napisał, z drugiej strony jeśli sąd zrezygnowałby z opinii biegłego to w odwołaniu łatwo zarzucić sądowi, że mówi o czymś na czym się nie zna, a poza tym przecież jeśli nawet sąd (skład orzekający) posiada wiadomości specjalne to i tak musi powołać biegłego. Skąd sąd może wiedzieć, czy złamanie kości o takiej-to-a-takiej łacińskiej nazwie to naruszenie ciężkie czy lekkie albo czy rozstrój zdrowia był na 7 dni czy na 14? Skąd sąd może wiedzieć czy dajmy na to atak o wdzięcznej nazwie "salami" to przełamanie czy ominięcie (z ksiazki prof. Adamskiego? Ależ On się powołuje na tłumaczenie nienajlepszej amerykańskiej pozycji sprzed dziesięciu lat, w czym lepszy jest amerykański popularyzator od polskiego biegłego)...
Śr, 2008-10-08 10:19 by artur.kmieciak@...
Generalnie odnoszę wrażenie, że w praktyce rola biegłego jest, że tak powiem, elastyczna.
Ależ oczywiście, co jest jasne dla każdego kto miał w ręku opinię z której wynikało, że obrażenia spowodowały naruszenie czynności narządu ciała na czas dłuższy niż 7 dni.
Niby jak to miałby ustalić sąd bez pomocy biegłego?
Jak w sprawie Mateusza sąd miałby ustalić czy doszło do przełamania zabezpieczeń?
Ma Pan absolutną rację, że jeśliby to zrobił sam, to taki wyrok zostałby uchylony z wielkim hukiem przez sąd wyższej instancji, na skutek zarzutu apelacji, co do tego, że nie ma specjalistycznej wiedzy aby takie kwestie samodzielnie rozstrzygać.
Traktuje ten wątek z biegłym jako wywołany sztucznie przez szczęśliwego posiadacza bazy danych orzeczeń sądowych typu LEX czy Temida, a którego umiejętności polegają, jak na razie, na opanowaniu techniki "copy" - "paste".
Traktuje ten wątek z
Śr, 2008-10-08 17:47 by przepla
Stanowisko swoje nie wyrażam po to, aby pochwalić się posiadaniem dostępu do bazy orzeczeń, ale po to, aby się czegoś dowiedzieć. Napisałem moje stanowisko co do biegłych i wskazałem orzecznictwo na jego poparcie. Uważam, że rola biegłych w praktyce procesu karnego jest za szeroka.
Jeśli wskazałem orzecznictwo wyrwane z kontekstu, to proszę powiedzieć, jeśli popełniłem inny błąd, proszę go wskazać -- nawet moje minimalnym umiejętnościom prawniczym przyda się trochę wiedzy.
Śr, 2008-10-08 21:22 by artur.kmieciak@...
Napisałem moje stanowisko co do biegłych i wskazałem orzecznictwo na jego poparcie. Uważam, że rola biegłych w praktyce procesu karnego jest za szeroka.
Pańskie prawo mieć swoje zdanie ale co innego mieć swoje zdanie, a co innego je odpowiednio uzasadnić.
Jedno to mieć swoje zdanie, co do roli biegłego w procesie, a drugie to twierdzić, że sąd w tej, konkretnej, sprawie popełnił błąd stawiając biegłemu pytanie o przełamanie zabezpieczeń. Inaczej nie mógłby ustalić sposobu działania sprawcy i wydać rozstrzygnięcia - bo dla ustalenia sposobu działania sprawcy są konieczne wiadomości specjalne, których to sąd nie posiada.
Naprawdę nie sprawdzałem czego dotyczą cytowane przez Pana orzeczenia ale nie zdziwiłbym się, gdyby zostały wydane w sprawach dotyczących wypadków samochodowych. W tych sprawach właśnie biegli najczęściej wkraczają na teren zastrzeżony dla sądów i pozwalają sobie wyręczać sąd dywagacjami na temat zawinienia, interpretacji przepisów itd. Dlatego trzeba odnosić się do tych orzeczeń z ostrożnością i pamiętać w jakich sprawach i na tle jakich okoliczności zostały wydane.
Jak Pan zresztą więcej ich sobie poczyta, to Pan się z pewnością zorientuje, że bywają ze sobą sprzeczne albo zawierają zwyczajne błędy logiczne.
Pan był natomiast bardzo kategoryczny w swoim osądzie i to w sytuacji, w której, moim zdaniem, nie miał Pan racji.
W wolnym czasie proszę poczytać w tym miejscu - u Vagli materiały dotyczące obowiązku rejestracji czasopism. Przednia zabawa. Zapewniam.
LEX czy Temida są wielce przydatne ale trochę nas wszystkich "demoralizują".
Wt, 2008-10-07 03:06 by Marcin Gryszkalis
Exploit to kod - narzędzie, którego przeznaczeniem jest dokonywanie nadużyć. To wytrych. W niniejszej sprawie oskarżony nie posługiwał się żadnym narzędziem programistycznym, czy jakimkolwiek innym.
Z całym szacunkiem ale to jest strasznie naciągane... takie rozstrzygnięcie jest niemożliwe - przecież użył przeglądarki.
Exploit to nie musi być kod, np. angielska wikipedia definiuje go tak "An exploit [...] is a piece of software, a chunk of data, or sequence of commands that take advantage of a bug". W naszym przypadku '+OR+1=1 to jest "chunk of data".
Zresztą weźmy pierwszy z brzegu exploit typu SQL Injection
http://www.milw0rm.com/exploits/6428 - niby mamy program w perlu czyli straszne narzędzie i wytrych - a z drugiej strony jak zajrzymy do środka to program po prostu konstruuje URLa i udaje, że jest przeglądarką
$vul = "/show.php?imageid=999+union+select+0,1,2,
Co więcej - z punktu widzenia serwera, jego logów i efektów nie ma żadnej różnicy czy użyjemy tego programu czy wpiszemy URL ręcznie.
To pokazuje chyba, że próba karania za tworzenie/posiadanie oprogramowania "mogącego posłużyć" jest kompletnie bez sensu...
Wt, 2008-10-07 08:24 by artur.kmieciak@...
"To pokazuje chyba, że próba karania za tworzenie/posiadanie oprogramowania "mogącego posłużyć" jest kompletnie bez sensu..."
Też tak sądzę. Przecież wiele standardowego oprogramowania służącego do diagnozowania sieci to takie oprogramowanie.
Co do samej sprawy to pytanie: czy wpisanie określonego ciągu znaków w przegladarkę jest przełamaniem zabezpieczeń.?
Wt, 2008-10-07 12:52 by Marcin Gryszkalis
czy wpisanie określonego ciągu znaków w przegladarkę jest przełamaniem zabezpieczeń?
Pytanie - co jest kluczowe w powyższym pytaniu:
- jeśli przeglądarka - to moim zdaniem nie da się rozstrzygnąć tego, sam mam w Firefoksie wiele pluginów, które mogą służyć do przełamania (lub obejścia) zabezpieczeń - obawiam się nawet, że nie jesteśmy w stanie zdefiniować czym owa przeglądarka jest w tej sytuacji.
- jeśli wpisanie - to gdzie, czy URL, czy formularz, czy może jeszcze pare innych?
- jeśli "ciągu znaków" - to czy dopuszczamy użycie pluginów przekodowujących na base64 czy url-encoding (co jest często przy takich próbach potrzebne)
Jakiś czas temu aby
Wt, 2008-10-07 13:06 by adammada
Jakiś czas temu aby skorzystać w Polsce z dobrodziejstw serwisu megaupload należało:
a) zainstalować jakiś ichni toolbar (kto by chciał jakieś spyware ryzykować)
b) zmienić ustawienia user_agent przeglądarki aby przedstawiała się jako posiadająca już ten toolbar.
Czy b) to było:
a) ominięcie zabezpieczeń
b) przełamanie zabezpieczeń
Wt, 2008-10-07 15:01 by artur.kmieciak@...
Sam Pan widzi ile wątpliwości.
A przecież, raz jeszcze podkreślam, że poruszamy się w płaszczyźnie prawa karnego, gdzie nie ma miejsca na wątpliwości.
"- jeśli przeglądarka - to moim zdaniem nie da się rozstrzygnąć tego, sam mam w Firefoksie wiele pluginów, które mogą służyć do przełamania (lub obejścia) zabezpieczeń".
Nie chodzi o pluginy ale i zapytanie do bazy danych.
Takie zapytanie: '+OR+1=1
Czy jest to czyn zabroniony? Proszę o prostą odpowiedź: tak lub nie. proszę w tym momencie nie powoływać się na inne przypadki, sytuacje, narzędzia czy zjawiska.
Czy tak sformułowane zapytanie SQL jest "przełamaniem zabezpieczeń", jeśli jest - to proszę wskazać jakie to zabezpieczenie i na czym polega jego przełamanie.
O ile można Pana prosić.
"- jeśli wpisanie - to gdzie, czy URL, czy formularz, czy może jeszcze pare innych?"
W cokolwiek. Czy jest takie miejsce "w przeglądarce", gdzie umieszczenie ciągu znaku: '+OR+1=1 jest czynem zabronionym?
"- jeśli "ciągu znaków" - to czy dopuszczamy użycie pluginów przekodowujących na base64 czy url-encoding"
Nie zajmujemy się takimi przypadkami - chodzi o ciąg znaków: '+OR+1=1
Prosta odpowiedź ;)
Wt, 2008-10-07 22:43 by Marcin Gryszkalis
Czy jest to czyn zabroniony? Proszę o prostą odpowiedź: tak lub nie.
A tak szerzej to chodzi mi o to, że jakby poruszamy się cały czas nie w tym miejscu co trzeba. Są dziury (np. w RealVNC 4), której exploit opiera się na wysłaniu 1 bajtu o wartości 1 (tylko w odpowiednim momencie). Nie jesteśmy w stanie rozstrzygać o przestępstwie tylko na podstawie treści wysyłanych danych czy na podstawie sposobu ich wysyłania.
VaGla prosi o nie robienie analogii ale wygląda, że nie potrafimy inaczej myśleć. Chodzi mi o to, że posiadanie noża nie jest zabronione, machanie ręką z nożem jest ok, ale próba zabójstwa - już nie.
Przecież sądy rozstrzygają teraz przypadki kiedy ktoś ugodził kogoś nożem i tłumaczy się, że niechcący i chciał tylko postraszyć a wogóle to działał w obronie koniecznej.
Nie jesteśmy też w stanie precyzyjnie rozróżnić obejścia od przełamania zabezpieczeń. Technologia jest tak skomplikowana, że od ręki możnaby podać kilkanaście przykładów na którymi 100 specialistów będzie się kłócić czy to są obejścia czy przełamania.
Żeby nie było niejasności - też zdarzało mi się robić takie "przypadkowe" audyty, na szczęście omineły mnie kłopoty takie jak miał Mateusz. Myślę, że przy obecnym stanie prawa to była dobra (i skueczna jak widać) linia obrony - natomiast prawo ma tutaj wady (a nowelizacja jeszcze większe). Dużo prościej byłoby uznać, że oskarżony przełamał/ominął zabezpieczenia ale jest niewinny biorąc pod uwagę intencje (choćby na podstawie korespondencji).
Jeśli diagnozujesz swoją
Śr, 2008-10-15 10:50 by incognitus (niezweryfikowany)
Jeśli diagnozujesz swoją sieć (jeśli jesteś jej administratorem) to jest wszystko w porządku, jeśli cudzą to juz mniej.
"chunk of data"
Wt, 2008-10-07 08:44 by artur.kmieciak@...
A czy +OR+1=1 to chunk of data?
A '+OR+1=
A '+OR+
Może '+O
W takim razie czy ' to chunk o f data?
jeśli tak to dlaczego nie 1?
@przepla "Tak samo
Wt, 2008-10-07 09:27 by Mateusz.M
"Tak samo okoliczność, że baza danych nie była zabezpieczona przed najprostszym SQL Injection nie oznacza, że przełamanie tego zabezpieczenia nie wypełnia znamion przestępstwa."
Nie widzi Pan sprzeczności w tym zdaniu? Skoro pisze Pan, że "baza danych nie była zabezpieczona" to dlaczego chwile później pisze Pan "przełamanie tego zabezpieczenia"? Dalszy Pana wywód opiera się na tym błędnym, sprzecznym zdaniu.
@Marcin Gryszkalis
Wiele języków programowania zawiera elementy języka naturalnego i wszystkie z nich wykorzystują znaki używane w języku naturalnym. Mec. Kmieciak trafił w powyższym komentarzu w istotę problemu tzw. exploitów. Analizując komentarz użytkownika przepla można tam zauważyć powtórzony dwa razy myślnik (--). Taka konstrukcja w SQL oznacza komentarz i jest bardzo często wykorzystywana w atakach SQL Injection. Proszę mi powiedzieć czy użytkownik ten usiłował popełnić przestępstwo i zapoznać się z nieprzeznaczoną dla niego informacją (np. wywołując błąd składni)? Czy Pan wpisując w swoim komentarzu cudzysłów usiłował popełnić przestępstwo?
Interpretacja art. 267 jaką proponuje przepla prowadzi do absurdu. Ten absurd jest niewidoczny w polskim prawie tylko dlatego, że spraw z art. 267 jest niewiele. Większość działań podejmowanych przez użytkowników w określonych warunkach (brak zabezpieczeń) prowadziłaby do stawiania zarzutów.
"Sąd został wprowadzony w błąd."
Jeśli oskarża mnie Pan o oszukiwanie Sądu to proszę się chociaż podpisać. Sąd podjął decyzję na podstawie opinii biegłych, zeznań świadków i interpretacji art. 267, którą popiera wiele autorytetów polskiego prawa. Proszę zapoznać się choćby ze stanowiskiem, wielokrotnie już wspominanego, prof. Adamskiego.
Uważam, że do momentu kiedy odpowiedzialność karna za tego typu działania będzie uzależniana od "łamania zabezpieczeń" czy sposobu w jaki weszło się w posiadanie danych, będą istniały niejasności. Może warto zastanowić się nad uzależnieniem odpowiedzialności od intencji "hackera" i skutków jego działań? Co innego usunięcie bazy danych, a co innego wysłanie maila z informacja o lukach do administratora bazy danych.
Wt, 2008-10-07 17:13 by przepla
Baza danych nie była zabezpieczona przed SQL Injection, ale była zabezpieczona w ogóle. Zabezpieczenie słabe to jednak zabezpieczenie i to miałem na myśli ujmując to, przyznaję, wadliwie.
Wt, 2008-10-07 18:01 by artur.kmieciak@...
Baza danych nie była zabezpieczona przed SQL Injection, ale była zabezpieczona w ogóle. Zabezpieczenie słabe to jednak zabezpieczenie
Więc pozwalam sobie zapytać po raz kolejny:
czym było zabezpieczenie?
i na czym polegało jego "przełamanie"?
Wt, 2008-10-07 12:19 by Marcin Gryszkalis
Kawałek, porcja danych, to przecież nie można powiedzieć, czy to ma być kilobajt, 10 bajtów czy jeden.
Zastanawiam się jak interpretuje się w "świecie rzeczywistym" coś takiego jak niebezpieczne narzędzie (tj. "odpowie za rozbój z użyciem niebezpiecznego narzędzia"). Co decyduje czy narzędzie jest niebezpieczne czy nie? Czy wielkość (siekiera), "potencjalne" niebezpieczestwo (brzytwa) czy może kontekst użycia (widelec wbity w szyję)?
Pn, 2008-10-06 22:56 by Incognito (niezweryfikowany)
Cieszę się, że sprawa dotarła do szczęśliwego końca. Śledzę jej przebieg od początku i muszę przyznać, że nie sądziłem, że ta firma pójdzie w tym kierunku - no cóż...
Czemu aplikacja miała błędy? Podejrzewam brak czasu przez co nikt nie testował systemu pod kątem bezpieczeństwa...
"Nie można przełamać czegoś, co nie istnieje" - bzdura.
Wt, 2008-10-07 02:06 by incognitus (niezweryfikowany)
SQL injection jest możliwy w ok. 80% serwisów świata. Jest to jedna z podstawowych metod, a istnieje ich wiele.
W praktyce niemal każde zabezpieczenie można "złamać" lub "obejść" co przez Was może być zinterpretowane jako "brak zabezpieczeń". KAŻDE włamanie polega na wyszukaniu luki w zabezpieczeniu.
Włamania mają miejsce tam, gdzie nie ma oporu. Serwis nie jest domem, w którym ktoś wyłamuje zamek w drzwiach. Raczej jest domem, z setkami tysięcy okien i drzwi, z których część może pozostać przez nieuwagę/niewiedzę zarządcy otwarta. Dlatego hack nie ma nic wspólnego z brute force, które można przyrównać do łamania zamka.
Sąd został wprowadzony w błąd.
Być może nie sąd
Wt, 2008-10-07 02:28 by VaGla
Być może nie sąd. Być może problem jest znacznie poważniejszy. Jeśli istotnie jest tak, że w sferze informatyki nie ma "skutecznych" zabezpieczeń, a dotarcie do informacji wymaga jedynie uwagi większej niż wykazał ktoś, kto chciałby informację "zabezpieczyć", to - wobec tego - prawo karne w obecnym kształcie i brzmieniu nie jest tu dobrym narzędziem (pamiętamy o zasadzie nullum crimen sine lege certa), by precyzyjnie wyznaczać granice dopuszczalności lub penalizacji pewnych - uwaga: kontrowersyjna teza - "naturalnych w społeczeństwie informacyjnym zachowań" (a tu pamiętamy o zasadzie nullum crimen sine lege stricta)?
Proszę się w tym serwisie powstrzymać od argumentacji typu "bzdura", itp.. Proszę o argumentację prawną. Ten serwis temu właśnie jest poświęcony, ja zaś jestem moderatorem dyskusji i czasem (często) z tego korzystam (a niektóre komentarze nie dlatego się nie pojawiają, że blokuje konkretną linię argumentacji, a raczej ze względu na formę jej przedstawienia i brak merytoryki w wypowiedzi komentującego).
programista - "zawód zaufania społecznego"?
Wt, 2008-10-07 10:55 by incognitus (niezweryfikowany)
Podobnie jak w wypadku architektów, lekarzy, prawników - informatyk powinien być traktowany jako zawód zaufania publicznego, a w związku z tym, osoba wykonująca ten zawód powinna być zobowiązana prawnie do przykładania najwyższej możliwej staranności do wykonywanej pracy. Lekarz nie da gwarancji wyleczenia, prawnik wybronienia. Informatyk w praktyce nie może dać pełnej gwarancji tego, że serwis internetowy i maszyna na którym się on znajduje, i całość infrastruktury będzie w 100% bezpieczna.
Projektowanie aplikacji (w tym webowych) to pewien proces. Ten proces kończy się fazą użytkowania, a więc nie ma punktu zakończenia "tworzenia", innego jak "śmierć programu", czy wyłączenie serwisu.
W takim znaczeniu, to co jest uważane za bezpieczne dziś - może okazać się niewystarczająco zabezpieczone jutro.
Postaram się podstosować pod Twoje uwagi Piotrze. Przepraszam za nieprawniczy język...
Wt, 2008-10-07 12:35 by Marcin Gryszkalis
W sensie ogólnym nierealne, bo programują dziesięcioletnie dzieci, a nastolatkowie umieszczają w internecie swoje serwisy i nikt im tego nie zabroni.
Po drugie próba wprowadzenia ograniczeń dostępu do zawodu (korporacje itd.) powoduje wzrost cen, czego chyba nie chcemy.
Po trzecie - gdzieś ostatnio było dużo na ten temat - Polska jest jednym z krajów o jawiększej liczbie zawodów o ograniczonym dostępie. A widać na przykładzie ochroniarzy, że wymóg licencjonowania nie podnosi jakości świadczonych usług ;)
Istnieją normy (w sensie PN) określające specjalne wymagania np. dla "informatyki medycznej" - to powinno w zupełności wystarczyć.
Wt, 2008-10-07 15:18 by artur.kmieciak@...
Jako zawód zaufania publicznego z pewnością nie.
Ale chodzi o odpowiedzialność programistów za wykonane przez nich produkty.
Chyba warto zacząć o tym mówić, bo sytuacja taka jak dotychczas, że nikt nie jest za nic odpowiedzialny, nie da się dłużej utrzymać.
Ktoś w firmie zapłacił spore pieniądze za system bazodanowy i miał prawo oczekiwać, że będzie on spełniał przynajmniej standardowe kryteria jakości. A sprzedano mu bubla, dane klientów nie były realnie zabezpieczone.
No właśnie - wiele piszemy o aplikacjach, bazach, serwisach, a nie piszemy o ich użytkownikach. Chyba mają prawo oczekiwać, że ich dane będą chronione i to chronione realnie a nie dostępne po wpisaniu kilku symboli do formularza?
Co to za tłumaczenie, że nie ma 100% zabezpieczeń, czy że 80% serwisów jest podatnych na SQL Injection? To znaczy, że 20% nie jest podatnych czyli jednak można.
Skoro nie ma absolutnie skutecznych zabezpieczeń to można darować sobie nawet te najbardziej elementarne? Dobre sobie.
Nie o wygodę panów Programistów w tym wszystkim chodzi ani o ich alibi ale umiejętności.
Wt, 2008-10-07 21:17 by Marcin Gryszkalis
Czy nie wystarczą zwykłe uregulowania KC, które mamy? Czy firma nie może wymóc w umowie na wykonawcy bezpieczeństwa popartego zewnętrznym audytem - albo nawet pójść dalej i zarządać gwarancji odporności na określone standardowe ataki (chociażby opierając się na wspomnianym już OWASP)? Nie zrobiła tego (być może z niewiedzy lub ze względu na koszty) - ma problem.
Bardzo trafna diagnoza - problem w tej chwili to niski poziom wiedzy (w zakresie bezpieczeństwa) programistów. Myślę, że szacując optymistycznie 5% studentów po studiach rozumie SQL injection na tyle, żeby wiedzieć jak się przed tym bronić a może ze 2% rozumie dobrze bardziej zaawansowane formy ataków (natomiast odwrotnie - 95% potrafi napisać formularz logowana w php+baza danych).
Wt, 2008-10-07 21:54 by artur.kmieciak@...
"Czy nie wystarczą zwykłe uregulowania KC, które mamy?"
Praktyka wskazuje, że są niewystarczające - jak myślę ze względu na problem z niadekwatnością języka prawniczego do zjawisk jakie wywołują nowoczesne technologie.
Ma Pan oczywiście racje pisząc o konieczności zawierania dobrych umów ale zamawiający zamawiając aplikację u profesjonalisty działa w zaufaniu do jego umiejętności - umiejętności inżyniera oprogramowania. Nie ma żadnych powodów, dla których należałoby tego ostatniego traktować ulgowo - inaczej niż inżyniera innych specjalności.
Ich wszystkich obowiązują pewne standardy i świętą rację ma Paweł Krawczyk pisząc, ze wcześniej czy później, jeśli programiści nie wypracują sami właściwych norm, to zrobi to za nich ktoś inny.
Jeszcze informatyka jest młodą dziedziną i korzysta z frycowego ale to się na pewno zmieni. Nikt przy zdrowych zmysłach nie kupiłby innego urządzenia takiej jakości i na takich warunkach na jakich sprzedaje się oprogramowanie (dla młodych, ambitnych prawników obecnych na tym portalu - pisząc "sprzedaje" mam także na myśli udzielanie licencji)
"Myślę, że szacując optymistycznie 5% studentów po studiach rozumie SQL injection na tyle, żeby wiedzieć jak się przed tym bronić a może ze 2% rozumie dobrze bardziej zaawansowane formy ataków (natomiast odwrotnie - 95% potrafi napisać formularz logowana w php+baza danych)."
I w tym tkwi istota problemu, o czym zresztą świadczy wiele głosów w tej dyskusji.
>"Myślę, że szacując
Wt, 2008-10-14 18:21 by mt3o (niezweryfikowany)
I w tym tkwi istota problemu, o czym zresztą świadczy wiele głosów w tej dyskusji
Jako informatyk muszę zaprotestować. Mam 21 lat, zanim poszedłem na studia, dobrze wiedziałem co to jest sql injection, do czego służy i jak to wykorzystać.
Braki w wiedzy (a podatność na sql inject wynika z braku wiedzy) to problem braku pogłębiania posiadanej wiedzy.
We wspomniamym PHP już wykorzystanie Zend Framework wraz z PDO uniemożliwia atak sql injection. W tutorialach do CMSa - Joomli opisane jest, jak się przed tym zabezpieczyć.
Podsumowując - niedopatrzenia w skryptach wynikają z braku wiedzy u informatyków pokroju 'syn sąsiadki' i z braku czasu, funduszy i wiedzy u programistów, którzy piszą takie strony za marne pieniądze i pod dużą presją czasu.
Myślę, że brak czasu, funduszy i wiedzy to główne przyczyny wpadki, jaką popełniła firma której formularz testował pan Mariusz.
Myślę też, że podobne były przyczyny wpadki Pekao z ich listą cv.
Wydaje się, że oprócz
Śr, 2008-10-15 11:07 by incognitus (niezweryfikowany)
Wydaje się, że oprócz braku pieniądzy i czasu jest sam stosunek do informatyki (informatyków), w wielu firmach inżynier informatyk jest traktowany jako "specjalista" od wszystkiego co ma jakikolwiek (choćby pośredni) związek z komputerem). Chodzi oto, że w wielu firmach osoba, która jest tak naprawdę specjalistą np. od sieci komputerowych, czy administracji serwerem, ma zlecane inne zadania (np. napisanie www, czy zrobienie bazy danych). Oczywiście większość informatyków jest w stanie sobie poradzić w jakiś sposób, ale nie posiada specjalistycznej/aktualnej wiedzy nt. denego problemu, dlatego to co zrobi działą dopóki nie ma jakiś problemów (np. SQL Injection, nie przewidział z braku elementarnego doświadczenia w w/w temacie)
Inna sprawa, że w firmach nieinformatycznych informatycy są uważaniu za największych nierobów, bo jeśli nie ma problemów to informatyk nie kontaktuje się z pracownikami - nikt jednak nie zdaje sobie sprawy ile trzeba włożyć w to czasu i pracy, aby działało bezawaryjnie.
jesteś elitą :)
Śr, 2008-10-15 23:29 by Marcin Gryszkalis
zanim poszedłem na studia, dobrze wiedziałem co to jest sql injection
To znaczy, że należysz do tych 5% (czy może nawet 2%) wspomnianych wyżej. To co mówię opieram na ładnych paru latach zajęć prowadzonych ze studentami na kilku uczelniach. Pewnie na najlepszych wydziałach typu mimuw te procenty rozkładają się inaczej - ale weź pod uwagę dziesiątki słabszych wydziałów - naprawdę nie uważam, żeby średnia była lepsza niż napisałem... niestety.
"W praktyce niemal każde
Wt, 2008-10-07 08:41 by artur.kmieciak@...
"W praktyce niemal każde zabezpieczenie można "złamać" lub "obejść"
To wielka różnica - złamać czy obejść. Proszę się odnieść do istoty sprawy - czy sprawca dokonał przełamania zabezpieczenia. I skoro Pan używa tak naprzemiennie tych terminów to spróbować wyjaśnić czy istnieje dla Pana różnica między "wykorzystaniem" luki a "przełamaniem" zabezpieczenia.
Przypominam to prawo karne, gdzie jak coś jest wątpliwe to nie może przedmiotem zarzutu.
"Raczej jest domem, z setkami tysięcy okien i drzwi, z których część może pozostać przez nieuwagę/niewiedzę zarządcy otwarta. Dlatego hack nie ma nic wspólnego z brute force, które można przyrównać do łamania zamka."
Sam Pan sobie odpowiedział na to pytanie. Skoro część z nich jest otwarta to nie ma zabezpieczenia i nie dochodzi do ich przełamania.
Proszę uważać ze zbyt pochopnym formułowaniem ocen. Jeśli już to proszę się podpisać.
P.S. Może mi Pan wyjaśnić co oznacza pojęcie "hack" i czy obejmuje ono wyłącznie czyny zabronione?
W danym przypadku uzyskanie
Wt, 2008-10-07 11:30 by kravietz
W danym przypadku uzyskanie dostępu do systemu było wynikiem wyłącznie niedbalstwa programisty.
Ataki SQL Injection na różne platformy aplikacji webowych są znane od dawna i opis jak do nich nie dopuścić są w każdym podręczniku programowania. Istnieją obszerne opracowania darmowe (OWASP). Jak ktoś o tym nie wie, to popełnia błąd nie stosując się do najlepszej praktyki inżynierskiej w danej branży.
Na dłuższą metę nie wydaje mi się właściwe umieszczanie niekompetentnych programistów pod kloszem przez przesuwanie winy z nich na osobę, która tą niekompetencję wskazała. Taka strategia może tylko doprowadzić do wzrostu poczucia bezkarności u producentów aplikacji, a w konsekwencji do wystawienia ich użytkowników na jeszcze większe zagrożenie.
W latach 90-tych mieliśmy dokładnie taką sytuację - producenci oprogramowania w sposób arogancki ignorowali doniesienia o błędach, zaprzeczali im lub próbowali atakować tych co je wskazali. To, że dzisiaj co miesiąc mamy zbiór łatek od MS i innych producentów to wyłącznie wynik konsekwentnej publikacji wszystkich doniesień o dziurach i bezlitosnego ich piętnowania (full disclosure).
Moje wątpliwości natury moralne w tym przypadku budzi jedynie fakt, że oskarżony zdaje się zażądał pieniędzy za zabezpieczenie serwera. Ale to zdaje się nie było przedmiotem oskarżenia.
Chciałbym tutaj też zwrócić uwagę autorom aplikacji webowych, że Bogu dzięki ten rynek - jako jeden z niewielu - nie jest jeszcze drobiazgowo uregulowany przez przepisy. Jak sami nie zadbacie o to by takie afery nie kończyły się w sądach to wam go w końcu uregulują. Przepisy dotyczące pisania aplikacji webowych napisze wam jedna z dużych firm mających chody w administracji i nie będziecie mieć szans w żadnym przetargu.
po pierwsze nie dom
Wt, 2008-10-07 09:05 by incognitus (niezweryfikowany)
po pierwsze - strona komputerowa firmy, to nie dom prywatny, po drugie użytkownik ma prawo wpisać co mu się podoba w pola, które są widoczne na stronie, a psim obowiązkiem softu jest zapobiec ich wykorzystaniu do uzyskania niepowołanego dostępu
jak koniecznie potrzebujesz waść analogii, to serwis z możliwością SQL injection PRZEZ WIDOCZNE POLA FORMULARZA, to jest jak budynek który developer oddał jako gotowy, ale jakimś trafem drzwi w nim mają powyrywane zamki a ponadto wiszą na jednym zawiasie
dodatkowo można domniemywać, widząc taki stan, że inne elementy wykonania są równie spaprane, rury kanalizacyjne położone po płaskim, nieszczelne instalacje, dziury w ścianach wypchane papierem, podłogi w biurach po których zsunie się stół a nie tylko piłka stoczy itd
ten co kupił i przyjął taki budynek (podkreślmy - firmowy, nie prywatny), nie dopełnił podstawowych obowiązków sprawdzenia stanu budynku i jeśli pozwie do sądu kogoś kto mu zwróci uwagę i zaproponuje odpłatną pomoc, to go każdy sąd wyśmieje
po przemyśleniu - gorzej - takiego budynku nie przyjmie urzędnik, może strony firmowe powinny być obowiązkowo testowane przez zewnętrznego eksperta na koszt firmy?
na marginesie - ja jako informatyk bardzo chciałbym wiedzieć co to za firma, żeby tam się nigdy nie zatrudnić (ale się pewnie nie dowiem)
Złamanie a obejście
Wt, 2008-10-07 09:24 by leftfish
Więc nie ma różnicy między wydobyciem zawartości, dajmy na to, etc/passwd, a SQL Injection?
Wt, 2008-10-07 11:18 by jell (niezweryfikowany)
SQL injection to metoda/narzędzie dostępu do danych. Może zostać użyta do nieuprawnionego wyciągnięcia danych, ale sama możliwość czymś złym nie jest. Nóż, jako narzędzie - może zostać użyty jako narzędzie zbrodni, ale sama możliwość nie czyni go nim.
Wydobycie zawartości /etc/passwd to juz konkretny przypadek wejścia w posiadanie danych - czasem uprawniony, czasem nieuprawniony...
Witam Czy po nowelizacji
Wt, 2008-10-07 08:21 by J (niezweryfikowany)
Czy po nowelizacji przepisów karalne stanie się uzyskanie dostępu do "members zone" danego serwisu za pomocą znalezionego w internecie nazwy użytkownika i hasła? Tj przez zalogowanie się jako login:haslo@strona/mmbr/? Dodam że to strona zagraniczna - ale jak rozumiem, ewentualne popełnione przestępstwo byłoby sądzone wg prawa polskiego? Czy także w tym przypadku - skoro loginy i hasła są publicznie dostępne - nie ma mowy o przełamaniu zabezpieczeń?
Takie sytuacje najczęściej
Wt, 2008-10-07 16:42 by LukasS
Takie sytuacje najczęściej zdarzają się przy stronach erotycznych, gdzie specyficzne grupy publikują paczki z loginami i hasłami do paysite'ów (a często się twierdzi, że może to być też akcja samego właściciela, w celu promocji strony i jej zawartości). Odpowiadając na pytanie, moim zdaniem nie ma mowy o przełamaniu zabezpieczeń bo uzyskujesz dane konta i nie jest powiedziane czy te konta (a dokładnie login i hasło) są skradzione czy założone przez osobę udostępniającą.
Wracając do tematu tego postu, pokuszę się jednak o analogię, która wg. mnie najlepiej przedstawia sytuację, którą rozpatrywał sąd.
System (dom/mieszkanie) do, którego dostał się oskarżony przez formularz (drzwi), poprzez wpisanie ciągu znaków (pukanie), które nie były zabronione (pukanie nie jest zabronione).
Jestem zadowolony z rozsądnego podejścia sądu do problemu i do zaistniałej sytuacji, odpowiedzialność powinna spaść na firmę, która stworzyła ten system i udzieliła licencji. Programista niestety musi posiadać duże doświadczenie lub wyobraźnię, żeby takich sytuacji uniknąć. A klient powinien podpisać odpowiednią umowę, która ma chronić go przed ewentualnymi błędami.
Analogie do fizycznego świata nie są dobre
Wt, 2008-10-07 17:11 by VaGla
Analogie do świata, w którym wpływa się na materię - chciałbym to jeszcze raz podkreślić - nie są dobre do oceny relacji w sferze o nieco wyższym pułapie abstrakcji, tj. w sferze wpływu na niematerialną wszak informacje. Dlatego jeszcze raz proszę o to, by nie stosować analogii tego typu w dyskusji o przełamywaniu lub omijaniu "logicznych", "algorytmicznych" zabezpieczeń. To pozwoli nam uniknąć potencjalnie ślepych uliczek rozumowania.
Takie analogie muszą być
Pn, 2008-10-13 07:07 by incognitus (niezweryfikowany)
Skoro ustawodawca używa słownictwa świata realnego, więcej militarnego, to takie odwołania są w pełni zasadne (wykładnia językowa). Gdyby w ustawie zamiast przełamanie użyto wyrazu jdurowanie (losowo wybrałem 6 literek na klawiaturze i dodałem partykułę) i wyjaśnił co to znaczy byłaby zupełnie inna sytuacja. Wówczas analogie nie byłyby ani dobre ani dostępne. W tym wypadku, poprzez użycie określonego słowa, został nadany pewien kontekst i od tego nie mm już ucieczki.
Tłumaczenie "drzwi były
Wt, 2008-10-07 11:34 by incognitus (niezweryfikowany)
Tłumaczenie "drzwi były otwarte, więc nie było włamania" nie przekonuje mnie. Ta droga myślenia doprowadzi nas do absurdu "skoro jest wytrych otwierający drzwi jak klucz, Ergo otwarcie ich wytrychem nie jest włamaniem."
Wt, 2008-10-07 18:13 by Makdaam
Drzwi nie były otwarte. Lepszą analogią byłoby "Użytkownik dostał się do mieszkania przez spojrzenie na budynek pod odpowiednim kątem.". Jeżeli ta analogia jest za mało absurdalna mogę wymyślić inne.
Śr, 2008-10-08 12:59 by kocio
No właśnie - można wejść do domu, ale co to znaczy "wejść" na stronę WWW?
To przecież polega nie na tym, że mnie teleportuje do wnętrza serwera. W rzeczywistości tylko otrzymuję od niego kopię jakichś danych, zapewne w odpowiedzi na wysłanie jakichś danych z komputera, który właśnie obsługuję, lub wręcz bez mojego działania (mogę otrzymać jakieś dane z tego serwera np. pocztą zamiast do przeglądarki).
Jak w tym kontekście odróżnić "przełamanie" od "ominięcia" czy "zwykłego dostępu" nie odwołując się do interpretacji, a w szczególności bez uwzględniania intencji, które oczywiście znacznie trudniej udowodnić?
"Tłumaczenie "drzwi były
Wt, 2008-10-07 12:08 by artur.kmieciak@...
więc nie było włamania" nie przekonuje mnie."
Nie ma zabezpieczenia - nie ma włamania.
Ta droga nie prowadzi do absurdu tylko dobrze oddaje istotę rzeczy.
""skoro jest wytrych otwierający drzwi jak klucz, Ergo otwarcie ich wytrychem nie jest włamaniem."
Wytrych jest par exellence narzędziem SŁUŻĄCYM do pokonywania zabezpieczeń. Jego użycie jest 100% włamaniem.
Podobnie jak klasycznego "łamaka" do samochodu, który mimo swojej nieskomplikowanej struktury (to kawałek metalu) jest także takim narzędziem.
Pańska analogia jest zupełnie nietrafna.
Panie Mecenasie, prosiłem...
Wt, 2008-10-07 12:17 by VaGla
Panie Mecenasie, prosiłem by nie używać wprowadzających w błąd analogi do życia w fizycznym świecie, ponieważ to zaciemnia istotne kłopotu związanego z regulacją karną sfery obiegu informacji.
Wt, 2008-10-07 13:30 by artur.kmieciak@...
No to też wykazuje jak takie analogie bywają zawodne.
Poprzez wskazywanie innych analogii. Też zwodniczych. Ale też o to chodziło aby wykazać jak są zwodnicze.
Poza tym bez odwoływania się do pojęć z tradycyjnego prawa karnego - jego teorii ani praktyki to się Drogi Piotrze nie da.
Choć trzeba być baaardzo ostrożnym.
Tu nie trzeba zadnych analogii...
Wt, 2009-12-29 19:42 by incognitus (niezweryfikowany)
Oskarzony mial "konto/haslo" - ktore z powodu bledu w projekcie strony posowalo do kazdego serwisu. Tyle.
Nie ma tutaj mowy o zadnym wytrychu (wytrychem bylo by uzycie narzedzia pozwalajacego na wlamanie sie do dobrze ZABEZPIECZONEGO serwisu) ani o ominieciu (bo oskarzony dostal sie w "zamierzony" sposob to jest z formularza na stronie).
Jesli zas na sile szukacie analogi oto ona:
MAM KLUCZ (tak klucz: ciag znakow " or 1 = 1" jest podzbiorem dozwolonego ciagu znakow - czyli sam jest dozwolonym ciagiem znakow) KTORY PASUJE DO WSZYSTKICH DRZWI (danego producenta)
Wina lezy po jego stronie - bo to jego zabezpieczenia sa wadliwe.
Zeby uzasadnionym bylo ukaranie hakera - na stronie logowania powinien zostac umieszczony tekst (i wymagane potwierdzenie zapoznania sie z nim) cytuje:
"Prosze podac nazwe uzytkownika i konta
z wylaczeniem 'or 1=1'".
Jesli za cos takiego zaczniemy wsadzac do wiezienia - to pozostanie tylko wyslanie maila polskim urzednikom - z przyciskiem "kliknij mnie" ktory udostepni klikajacemu jakies totalnie niepotrzebne jednakze zastrzezone informacje co bedzie podstawo do skazania go w analogicznym procesie...