Bezpieczeństwo systemu e-commerce, czyli jak bez ryzyka prowadzić biznes w internecie 978-83-246-5821-3 [PDF]

Zitiervorschau

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Autorzy: Leszek Kępa, Paweł Tomasik, Sebastian Dobrzyński Redaktor prowadzący: Barbara Gancarz-Wójcicka Projekt okładki: Jan Paluch Fotografia na okładce została wykorzystana za zgodą Shutterstock. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: [email protected] WWW: http://onepress.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://onepress.pl/user/opinie/bezsec_ebook Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. ISBN: 978-83-246-5821-3 Copyright © Helion 2012 Printed in Poland. • Poleć książkę na Facebook.com

• Księgarnia internetowa

• Kup w wersji papierowej

• Lubię to! » Nasza społeczność

• Oceń książkę

OPINIE O KSIĄŻCE Bardzo wartościowa publikacja, łącząca kwestie prawne oraz informatyczne, z naciskiem na aspekty praktyczne, pomocna przy projektowaniu rozwiązań na użytek małych i średnich przedsiębiorców. Napisana jest na tyle przystępnym językiem, że powinna być szczególnie atrakcyjna dla prawników działających w obszarze ochrony informacji, którzy chcą zyskać wiedzę potrzebną do projektowania umów na wykonanie oraz utrzymanie bezpiecznych systemów e-commerce. Polecam ją także informatykom zainteresowanym poszerzeniem wiedzy o uwarunkowania prawne zasad budowy oraz bezpiecznej eksploatacji tworzonych przez nich systemów informatycznych. To książka, która powinna przyczynić się do produkcji bezpieczniejszego i bardziej funkcjonalnego oprogramowania, a także do tworzenia dobrych umów w tym zakresie. dr Stefan Szyszko, polski i unijny ekspert w dziedzinie ochrony informacji, ze szczególnym uwzględnieniem ochrony danych osobowych w sektorze ubezpieczeniowym Książka doskonale wpisuje się w aktualne potrzeby rynkowe. Wiele osób zaczynających swoją aktywność w internecie poszukuje przewodnika, który poprowadzi je przez zawiłości technologii i nauczy omijać pułapki czyhające przy konstruowaniu systemu e-commerce. Informacje zawarte w tym opracowaniu mogą przydać się przedsiębiorcom zamierzającym wejść ze swoją ofertą w świat rozwiązań internetowych lub zmieniającym sposób świadczenia usług. Mogą przydać się też administratorom wdrażającym i eksploatującym systemy e-commerce oraz służyć jako przewodnik osobom zainteresowanym ochroną informacji w systemach e-biznesu. Materiał jest interesującą próbą zebrania w jednym dokumencie wiedzy na temat

bezpieczeństwa systemów biznesu internetowego, z uwzględnieniem wymagań stawianych najważniejszym ich elementom: rozwiązaniom informatycznym, usługodawcom oraz klientom. Maciej Kołodziej, administrator bezpieczeństwa informacji w spółce Nasza Klasa, specjalista informatyki śledczej Nareszcie mamy systematyczny przegląd najważniejszych zagadnień dotyczących bezpieczeństwa systemów e-commerce! Autorzy prowadzą nas od zagadnień polskiego prawa, poprzez kwestie związane z bezpieczeństwem ogólnym, aż po szczegółowe omówienie zasad zabezpieczania serwera WWW, bazy danych i kodu aplikacji. Nie tylko poznajemy metody wykorzystywane przez cyberprzestępców, ale także sposoby pozwalające się przed nimi bronić. Dostajemy przykłady konkretnych rozwiązań, a nawet gotowe kody do wykorzystania. Publikacja z pewnością przyczyni się do rozwoju kultury bezpieczeństwa informacyjnego. To bardzo ważna książka dla wszystkich zaangażowanych w biznes online, zarówno tych prowadzących sklepy internetowe, jak i przygotowujących dla nich aplikacje i rozwiązania informatyczne. Marcin Olszewik, Dyrektor zarządzający w Allianz Direct New Europe

SPIS TREŚCI

PRZEDMOWA

1.

2.

3.

4.

9

WSTĘP

15

Podstawowe informacje o e-commerce Czego chcą cyberprzestępcy? Podstawy bezpieczeństwa

18 21 24

PRAWO WOBEC E-COMMERCE

33

Jakie prawo dotyczy e-handlu? Regulamin serwisu Świadcząc usługi drogą elektroniczną Przetwarzanie danych osobowych Zawarcie umowy między stronami O czym należy informować Kodeks spółek handlowych Prawo wobec cyberprzestępców

34 37 54 57 60 65 72 72

BEZPIECZEŃSTWO OGÓLNE

77

Informacje o systemie Zapasowe kopie danych

78 82

BEZPIECZNY HOSTING

89

Hosting czy własny serwer? DirectAdmin

89 90

ZABEZPIECZENIA SERWERA WWW

97

Zabezpieczenia hosta Zabezpieczenia Apache

98 102

6

5.

6.

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Konfiguracja PHP Zabezpieczenie kodu PHP Przeglądanie logów Obsługa komunikatów 403, 404 etc. Zabezpieczanie plików konfiguracyjnych Tripwire Obrona przed atakami DoS — Fail2ban

108 116 117 118 119 120 122

BAZA DANYCH

125

Połączenie z bazą Szyfrowanie danych

128 130

BEZPIECZNA TRANSMISJA DANYCH

133

Dlaczego warto szyfrować? Szyfrowanie komunikacji webowej A jeśli nie ma szans na SSL? Komunikacja przez e-mail Administrowanie poprzez sieć Integralność danych podczas transmisji

7.

8.

9.

136 137 153 154 156 159

IDENTYFIKACJA STRON W BIZNESIE

165

Wiarygodny sprzedawca Zidentyfikowany użytkownik

166 168

KONTA I HASŁA

177

Data wprowadzenia danych Hasz zamiast hasła Provisioning — zakładanie konta Cookies Sesje w aplikacji Sprawdzanie, czy połączenie odbywa się „po SSL” Autoryzacja transakcji

177 179 184 185 189 195 196

ZABEZPIECZENIA KODU APLIKACJI

197

Specyfika języka Jak przesyłać dane — GET czy POST? Walidowanie danych przesyłanych do serwera Zabezpieczenia przed automatami

198 198 201 208

SPIS TREŚCI

SQL injection File inclusions Ataki XSS Ataki CSRF i XSRF HTTP_REFERER Badanie kodu PHP

10. KODOWANIE DANYCH

|

7

212 222 226 230 232 233

235

ZAKOŃCZENIE

239

O AUTORACH

240

8

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

PRZEDMOWA

Na rynku wydawniczym sporo jest polskiej literatury o e-commerce, ale brakowało nam książki na temat jego bezpieczeństwa. Owszem, są pojedyncze pozycje dotyczące zabezpieczania np. PHP czy MySQL, a także inne materiały, ale są to najczęściej tłumaczenia autorów zagranicznych nieuwzględniające specyfiki funkcjonowania na polskim rynku. Uznaliśmy, że potrzebna jest lektura obejmująca temat bezpieczeństwa całościowo, z uwzględnieniem także aspektów prawnych, których nie można pominąć. Gdy rozpoczynaliśmy prace, pierwotny tytuł książki brzmiał Bezpieczeństwo danych w e-commerce, jednak później uświadomiliśmy sobie, że chodzi nie tylko o dane, ale o cały system, który służy działalności firmy. System e-commerce i dane przetwarzane za jego pomocą stanowią dobro, które pozwala firmie osiągać wyznaczone cele i realizować swoją misję. Jego działanie, w tym jego bezpieczeństwo, postrzegane jest przez przedsiębiorcę jako całość. Na bezpieczeństwo systemu wpływa wiele czynników: obowiązujące prawo, poprawnie napisana aplikacja, jak również czynniki organizacyjne takie jak wykonywanie zapasowych kopii danych. Dlatego już w trakcie przygotowywania materiału zdecydowaliśmy się rozszerzyć zakres książki i jej tytuł nieznacznie zmienić. Wierzymy, że stało się to z korzyścią dla czytelnika. Problem z bezpieczeństwem systemów e-commerce ma wiele rozmaitych źródeł:

10

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

• dostawcy mają dostarczyć jak najtaniej jak najbardziej funkcjonalny system (bezpieczeństwo nie wnosi zauważalnych funkcjonalności biznesowych, a czasami nawet je ogranicza); • presja czasowa (im szybciej system zostanie dostarczony, tym szybciej będzie przynosił firmie zyski); • częste zmiany będące skutkiem konkurowania z innymi przedsiębiorcami (a każda zmiana niesie za sobą jakieś ryzyko); • skomplikowana materia bezpieczeństwa (nie każdy zna te zagadnienia); • mało znane i trudne do zrozumienia aspekty prawne (niewielu jest programistów czy analityków znających się na prawnych aspektach prowadzenia e-commerce). Tworzący aplikacje internetowe (programiści) skupiają się przede wszystkim na ich funkcjonalności i wydajności. Jest tak głównie dlatego, że właśnie z tego są rozliczani przez klientów. Zamawiający aplikację widzi, jak ona działa, jednak zabezpieczenia (lub raczej ich brak) dopiero wtedy są dla niego widoczne, gdy stanie się coś złego. Bywa też, że twórcy aplikacji nie zawsze są w pełni świadomi zagrożeń płynących z sieci Internet, gdyż potrzeba do tego sporej specjalistycznej wiedzy. Rzadko kiedy orientują się też w wymaganiach wynikających z obowiązującego prawa. Mało tego, informatyczne technologie przetwarzania informacji rozwinęły się tak szybko, że jeszcze nie wykształciła się w społeczeństwie „kultura bezpieczeństwa informacyjnego”. W efekcie powstają często systemy w dużej mierze podatne1 na ataki cyberprzestępców. Nie tylko twórcy i dostawcy aplikacji nie są nieraz świadomi bezpieczeństwa (a raczej niebezpieczeństwa). Strona biznesowa, 1

Podatny — z łatwością ulegający czemuś (ang. vulnerable).

PRZEDMOWA

|

11

a więc przedsiębiorca zamawiający system e-commerce, także nie zawsze wie, czego powinien oczekiwać i jakich zabezpieczeń wymagać. Pewnie słyszałeś już albo nawet sam mówiłeś: Ja się nie znam, proszę pana. Ja chcę system, który będzie pomagał mi robić biznes. Dlatego ta książka ma dwie główne kategorie odbiorców: zamawiających aplikacje i twórców aplikacji internetowych. Zamawiający określa, czego oczekuje od aplikacji, i z tej książki dowie się, jakie wymogi powinna ona spełniać. Dzięki jej lekturze będzie wiedzieć, jakie stawiać wymagania i jak kontrolować ich realizację. Twórcy aplikacji, mający za zadanie ją wytworzyć, dowiedzą się zaś, co, a nawet jak należy zrobić, aby system pozwalał zamawiającemu bezpiecznie prowadzić interes. Nawet jeśli klient nie określi danego wymogu, dostawcy powinno zależeć na jego uwzględnieniu, gdyż dostarczenie niebezpiecznej aplikacji może stawiać go w złym świetle i ukazywać jako mało wiarygodnego, niegodnego zaufania partnera w internetowym przedsięwzięciu. Zaprezentowany materiał skupia się głównie na mechanizmach prewencyjnych, czyli na możliwych sposobach zabezpieczania systemu. Nie od dzisiaj wiadomo, że lepiej zapobiegać, niż leczyć. Podanych przykładów zabezpieczeń nie należy jednak traktować jako gotowych recept — chodziło nam przede wszystkim o pokazanie, jakie są metody tworzenia aplikacji odpornej na rozmaite ataki, aby można było dość bezpiecznie prowadzić biznes. W książce wskazujemy także, jakie wymogi prawne stawiane są handlowi przez internet. Przedsiębiorca nie działa w próżni. Prowadząc biznes e-commerce, należy stosować się do obowiązujących przepisów, aby nie narażać się na rozmaite konsekwencje ich nieznajomości. Ignorantia iuris nocet — przed sądem nie można się tłumaczyć nieznajomością prawa. W chwili pisania tej książki najczęściej spotykaną platformą systemów e-commerce był tzw. LAMP — Linux-Apache-MySQL-

12

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

PHP2. Przygotowując materiał, skupiliśmy się na tych czterech technologicznych filarach bezpieczeństwa, ponieważ są one najczęściej używane w internetowych przedsięwzięciach biznesowych. Apache stanowi 64,67% serwerów WWW3, wyprzedzając znacznie IIS Microsoftu, który ma w rynku 15,66% udziału. Baza danych MySQL, należąca obecnie do imperium Oracle, posiada 25-procentowy udział w ogólnym rynku baz danych, także korporacyjnych, przy czym jeśli chodzi o aplikacje webowe, jest ona wykorzystywana najczęściej. Technologia kodowania PHP stosowana jest natomiast aż w 77% aplikacji webowych4. Tam gdzie to było możliwe, sygnalizowaliśmy zagadnienia dotyczące innych platform, wierzymy jednak, że w wielu przypadkach istotne jest samo podejście do zagadnienia (algorytm, proces, zasada). Czasami jest ono nawet ważniejsze niż wybór technologii. Po wyborze platformy technologicznej łatwo wydedukować, że książkę tę kierujemy głównie do małego i średniego przedsiębiorcy, tym bardziej że problemy bezpieczeństwa takich firm są zupełnie inne niż dużych przedsiębiorstw5. Książkę staraliśmy się napisać jak najbardziej przystępnym językiem. Zawiera ona materiał czysto techniczny (przykłady kodu 2

Instrukcja opisująca, jak zainstalować cały zestaw pod Ubuntu, znajduje się pod adresem http://www.howtoforge.com/installing-apache2with-php5-and-mysql-support-on-ubuntu-11.10-lamp.

3

Na podstawie analiz zaprezentowanych na http://news.netcraft.com/ archives/category/web-server-survey/.

4

http://w3techs.com/technologies/details/pl-php/all/all

5

W raporcie stwierdza się: large company problems are different than small company problems. Perhaps it’s because enterprises have the IT staff to address some of the low-hanging fruit (or, what is often more apropos, the fallen fruit rotting in the yard). Raporty dostępne są pod adresem http://www.verizonbusiness.com/Products/security/dbir/.

PRZEDMOWA

|

13

albo konfiguracji), prawny i organizacyjny. Jesteśmy przekonani, że — prócz zamawiających i twórców aplikacji — będzie to ciekawa lektura także dla osób zajmujących się zawodowo bezpieczeństwem informacji, a w pewnej części nawet dla prawników interesujących się zagadnieniami e-commerce. Bezpieczeństwo jest bardzo ważne niezależnie od sposobu prowadzenia biznesu i użytej technologii. Jesteśmy przekonani, że ta książka stanie się Twoim przewodnikiem po internetowym biznesie i pomoże Ci prowadzić działalność bezpieczniej. Życzymy udanej lektury i bezpiecznego e-biznesu! Autorzy: Leszek Kępa Paweł Tomasik Sebastian Dobrzyński

14

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

WSTĘP

Prowadząc każdy biznes — czy jest on tradycyjny, czy elektroniczny — należy dbać o bezpieczeństwo. To w zasadzie truizm, bo każdy przedsiębiorca troszczy się o bezpieczeństwo swojego biznesu na tyle, na ile może i potrafi, niezależnie od jego formy. Lepsze byłoby stwierdzenie, że powinien on zarządzać bezpieczeństwem. Aby to robić, potrzebna jest orientacja w tym, jakie są możliwe ataki i jak można im zapobiegać. Przed tradycyjnymi zagrożeniami bronimy się, bo je znamy. Wiedząc, że złodziej potrafi otworzyć prosty zamek kawałkiem drucika, montujemy lepsze zamki. Może wybić szybę — wstawiamy kraty. Wiedza o możliwościach i technikach przestępców połączona z wiedzą o tym, jak się chronić, pozwala na zarządzanie bezpieczeństwem. Natomiast zagrożenia informacji, szczególnie teraz, gdy do ich przetwarzania używa się komputerów, nie są tak powszechnie znane. Nie wychowaliśmy się jeszcze w kulturze „bezpieczeństwa informacyjnego”. Jest takie powiedzenie, że gdyby człowiek wiedział, że się przewróci, to by się położył. Jak nie wiesz, co Ci grozi, to nie wiesz, że coś trzeba zrobić, aby temu zapobiec. Specyfika e-handlu, jego względna nowość i związany z tym brak pełnej wiedzy o zagrożeniach oraz metodach i technikach obrony powodują, że jest on bardziej narażony na ataki. I to ataki kończące się sukcesem. Mało tego, skala e-biznesu jest zupełnie inna niż zwykłego przedsięwzięcia. Sklep tradycyjny jest dostępny

16

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

dla lokalnej społeczności, a w jego zasięgu jest co najwyżej kilkadziesiąt tysięcy osób. Sklep internetowy jest natomiast dostępny dla wszystkich użytkowników internetu na świecie1. Nawet jeśli ofertę kierujesz tylko do polskiego klienta, nie zmienia to faktu, że Twój sklep jest niczym galeria handlowa — otwarty i dostępny dla każdego internauty bez względu na to, z jakiego państwa pochodzi i gdzie się znajduje. O specyfice e-handlu świadczy też to, że „środowisko internetowe” nie ma zrozumienia (litości) dla właściciela zaatakowanego e-biznesu. Gdy tradycyjny sklep zostaje okradziony, można spotkać się z wyrazami współczucia, ale po włamaniu do serwisu internetowego jego administrator (właściciel) staje się jedynie przedmiotem drwin i pośmiewiskiem. Sztandarowym tego przykładem z ubiegłego roku jest seria włamań do serwisów Sony; dzisiaj już trudno się zorientować dokładnie do ilu2. Wykradziono wtedy dane dotyczące łącznie ok. 100 mln użytkowników, w tym dane wielu tysięcy kart kredytowych. Po komentarzach, jakie znajdziesz w internecie (nam nie wypada ich cytować), zorientujesz się, co internauci sądzą na temat tego zdarzenia. Prace nad książką kończyliśmy w bardzo ciekawym momencie, kiedy w wojnie związanej z ACTA3 padało wiele serwisów internetowych. Ich zabezpieczenia również wyśmiewano, szczególnie że w jednym z nich hasłem użytkownika admin było admin1.

1

Liczbę użytkowników internetu szacuje się na ponad dwa miliardy — dane z dn. 17 stycznia 2012 r.; http://www.internetworldstats.com/ stats.htm.

2

Wśród serwisów tych były Sony Online Entertainment (77 mln kont) oraz Sony PSN (25 mln kont).

3

http://www.infor.pl/prawo/artykuly/586946,acta_umowa_handlowa_ dot_zwalczania_obrotu_towarami_podrobionymi.html

WSTĘP

|

17

Złe informacje rozchodzą się w sieci bardzo szybko, i — co najgorsze — pozostają tam na bardzo długo. Usunięcie rozpowszechnionej w internecie informacji o firmie jest w zasadzie niemożliwe i będzie ona latami wpływać na Twoją reputację. Reputacja to wartość firmy dla otoczenia, w którym ona funkcjonuje. Jej istotą jest ocena niematerialnej wartości firmy. Zgodnie z potocznym tego słowa znaczeniem reputację można stracić, odzyskać, można mieć ją w środowisku dobrą lub złą, można o nią dbać, próbować ją naprawić, a także może ona zostać zszargana. Warren Buffet powiedział, że w 5 minut można stracić reputację budowaną przez 20 lat. Jeśli weźmiesz to pod uwagę, będziesz działał zupełnie inaczej. Odważnie stwierdzamy, że bezpieczeństwo jest jednym z narzędzi pozwalających zachować, a nawet wzmocnić pozycję konkurencyjną przedsiębiorstwa poprzez budowanie zaufania i reputacji przedsiębiorcy. Reputacja może mieć dla różnego rodzaju serwisów e-commerce różne znaczenie. Są serwisy, w przypadku których zaufanie do firmy jest wyjątkowo istotne; będą to takie działalności, w których klient powierza swoje informacje i dane osobowe o szczególnym znaczeniu (np. bankowość elektroniczna). Są też takie, w przypadku

18

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

których to zaufanie jest ważne, ale już nie tak bardzo (np. serwis internetowy do zamawiania pizzy). Bez wątpienia jednak reputacja i zaufanie do sklepu internetowego mają największe znaczenie ze wszystkich pozacenowych czynników wpływających na decyzje klientów dotyczące korzystania z e-commerce4. O bezpieczeństwo systemu e-commerce warto więc dbać, bo zaniedbania w tym obszarze będą wpływać silnie na całe przedsiębiorstwo, na reputację firmy, na jej wyniki finansowe i na jej zdolność konkurowania z innymi podmiotami na elektronicznym rynku.

PODSTAWOWE INFORMACJE O E-COMMERCE Zanim przejdziemy do części merytorycznej, w tym miejscu chcemy przedstawić najważniejsze zagadnienia dotyczące handlu elektronicznego, który z języka angielskiego nazywamy e-commerce. W branży zwykło się rozróżniać e-commerce i e-biznes5. Przykładowo blog firmowy nie jest e-handlem, ale jest na pewno e-biznesem, bo przenosi sferę informowania klientów do internetu. W tej książce pojęcia te będziemy traktować jako równoznaczne. W ramach handlu elektronicznego można dokonać trzech podziałów. Pierwszy dotyczy sposobu, w jaki zawierane są umowy online, czyli — jak się je w prawie określa — umowy na odległość. Mogą to być transakcje pośrednie — wtedy zawarcie umowy odbywa się przez internet, ale jej wykonanie następuje w „realu”; jest to np. wysłanie zakupionych online towarów (odzieży, sprzętu AGD, RTV) pocztą tradycyjną lub kurierem6. Transakcje bezpośrednie polegają na tym, że umowa jest zawierana poprzez 4

Badanie polskich sklepów internetowych i konsumentów. E-handel 2010, s. 16, Wrocław 2011, Dotcom River.

5

http://www.bednarek.eu/roznica-miedzy-e-commerce-i-e-biznesem/

6

http://www.web.gov.pl/e-uslugi/e-handel/87_107_e-handel.html

WSTĘP

|

19

internet i tą drogą zostaje całkowicie wykonana. Przykładem będzie umowa dostępu do serwisów informacyjnych albo handel e-bookami lub muzyką w postaci plików do ściągnięcia. Drugi podział stanowi rozróżnienie transakcji internetowych ze względu na to, kto z kim zawiera umowę. Transakcje dzieli się na: • B2B (ang. business to business), transakcje pomiędzy przedsiębiorcami (np. hurtowy zakup towarów); • B2C (ang. business to consumer), gdy przedsiębiorca sprzedaje towar osobom fizycznym; • C2C (ang. consumer to consumer), które mają miejsce, gdy obiema stronami umowy są konsumenci (np. w serwisie ogłoszeniowym). Wyróżnia się jeszcze inne zyskujące ostatnio na znaczeniu formy, np. A2C (ang. administration to consumer), gdy stronami transakcji są organy administracji państwowej lub publicznej i obywatel. Przykładami są liczne wdrażane projekty e-administracji takie jak elektroniczny sąd, deklaracje podatkowe składane przez internet czy ePUAP7. Jest to naszym zdaniem pewien rodzaj B2C, przy czym zamiast biznesu jedną ze stron jest administracja państwowa. Trzeci podział dotyczy platform, na których odbywa się handel elektroniczny. Ogólnie rzecz biorąc, termin e-commerce obejmuje wszystkie formy dokonywania transakcji drogą elektroniczną, a więc m.in.: a) zawieranie umów przez internet, b) zautomatyzowane transakcje zawierane drogą telefoniczną (systemy IVR8) czy np. przez sieć bankomatów,

7

ePUAP — Elektroniczna Platforma Usług Administracji Publicznej.

8

IVR — ang. Interactive Voice Response — automatyczne systemy telefoniczne znane z tekstu „jeśli chcesz wybrać X, naciśnij 1, jeśli chcesz wybrać Y, naciśnij 2” itp.

20

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

c) transakcje przeprowadzane drogą telewizyjną, np. VOD9. Najczęściej jednak e-commerce kojarzy się z transakcjami zawieranymi przez internet i na tym skupimy się w niniejszej książce. Będziemy go też na potrzeby tej książki określać mianem e-handlu. E-handel dzieli się na kategorie — przy okazji podajemy udział procentowy poszczególnych z nich10: a) aukcje (37%), b) e-sklepy (28%), c) ogłoszenia (8%), d) zakupy grupowe (7%).

9

VOD — ang. Video on Demand — wideo na żądanie, zamawianie audycji filmowych drogą elektroniczną i umożliwianie ich oglądania na odbiorniku.

10

http://interaktywnie.com/biznes/artykuly/raporty-interaktywnie-com/ raport-interaktywnie-com-e-commerce-i-ranking-e-sklepow-22115

WSTĘP

|

21

Warto odnotować, że sprzedaż internetowa to najszybciej rosnący segment handlu, głównie detalicznego. W Polsce sam e-commerce detaliczny to jedynie 2 – 3% obrotów, jednak jeśli handel przez internet będzie się nadal rozwijał w takim tempie, za kilka lat może stać się poważną konkurencją dla tradycyjnych sklepów. Przewiduje się, iż obroty polskich sklepów w internecie w 2012 roku wyniosą prawie 8 mld złotych.

CZEGO CHCĄ CYBERPRZESTĘPCY? Ostatnio dużo się mówi o hakerach. Znaczenie tego określenia było kiedyś pozytywne — była to osoba, najczęściej programista entuzjasta, przełamująca zabezpieczenia, ale nie w celu osiągnięcia korzyści, tylko po to, aby realizować swoją pasję. Wyłącznym efektem jej „pracy” było co najwyżej poinformowanie właściciela systemu (zresztą bezinteresowne) o niedoskonałościach zabezpieczeń („dziurach”). Termin cracker oznaczał natomiast prawdziwego włamywacza informatycznego przełamującego zabezpieczenia ze złymi intencjami. Obecnie, gdy mówi się haker, w rzeczywistości ma się na myśli dawnego crackera. Rozumiemy istniejącą między nimi różnicę, ale cyberprzestępcę będziemy czasami dla ułatwienia określać mianem hakera bez względu na to, jakie ma intencje. Tak się już utrwaliło, co zresztą znajduje swoje odzwierciedlenie nawet w encyklopedii PWN: Haker — sprawny programista, który korzysta z nieudokumentowanych lub nieznanych powszechnie cech programów (np. systemu operacyjnego) w celu włamania się do systemu komputerowego (gł. za pośrednictwem Internetu) — żeby udowodnić swoje umiejętności, komuś zaszkodzić (np. przez zablokowanie lub zmianę cudzych stron WWW) lub osiągnąć korzyści materialne (np. kradzież numerów kart kredytowych z serwera sklepu internetowego).

22

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Motywy hakowania serwisów e-commerce są przeróżne (rysunek W.1). Są to głównie: 1. rozrywka, zabawa; 2. nauka, ćwiczenie swoich umiejętności, podjęcie wyzwania; 3. dążenie do uzyskania korzyści (pieniądze, zatrudnienie); 4. zaszkodzenie firmie poprzez złośliwy atak; 5. tzw. haktywizm — forma protestu lub wyrażania poglądów politycznych.

Rysunek W.1. Powody hakowania witryn internetowych według serwisu Zone-H

Wydawałoby się, że cyberprzestępcy włamują się do serwisów internetowych głównie dla pieniędzy. Wcale tak nie jest. Motywem większości włamań jest po prostu... rozrywka. Z danych zaprezento-

WSTĘP

|

23

wanych na stronie Zone-H11 wynika, że ponad 58% zdarzeń ma taki charakter, zaś ok. 23% to podejmowanie wyzwania czy też ćwiczenie własnych umiejętności. Nawet jeśli cyberprzestępca hakuje tylko dla zabawy (ang. just for fun), to i tak ostatecznie rzadko kończy się to dobrze dla serwisu. Od strony systemu e-commerce nie ma po prostu możliwości odróżnienia „etycznego” hakera od crackera. Zresztą dla przedsiębiorcy niespecjalne znaczenie ma to, dlaczego cyberprzestępca zaatakował — ważniejsze jest to, jaki był tego skutek. W statystykach zaprezentowanych na rysunku W.1 nie pojawiła się kategoria włamań dla pieniędzy, ale coraz więcej włamań do serwisów stanowi swego rodzaju źródło dochodu dla cyberprzestępców. Można tylko przypuszczać, że niekoniecznie chwalą się oni takimi osiągnięciami. Jedno z rosyjskich powiedzeń mówi Тише едешь, дальше будешь12. Nie ujawniając się, można kraść długie lata, zanim administrator systemu się zorientuje13. Internetowemu włamywaczowi zazwyczaj jest wszystko jedno, do czyjego systemu się włamuje — ważne, aby osiągnął swój cel. Pojawiają się jednak coraz częściej ataki skierowane przeciwko konkretnej firmie14 mające na celu jej zaszkodzić, a niekiedy nawet wyeliminować ją z rynku. 11

http://zone-h.org/news/id/4737

12

Przysłowie rosyjskie „im mniej mówisz, tym więcej zyskasz (dalej zajedziesz)”. Тише oznacza także ostrożnie.

13

Przykłady kradzieży danych przez długie lata: http://www.csoonline. com/article/700193/nortel-executives-knew-of-data-breach-chose-todo-nothing (Nortel) oraz http://www.sfgate.com/cgi-bin/article.cgi?f= /c/a/2012/01/13/MN4Q1MO9JK.DTL&ao=all (jedna ze szkół amerykańskich).

14

Więcej o APT — Advanced Persistent Threat — http://www.schneier. com/blog/archives/2011/11/advanced_persis.html.

24

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Włamywacze rozmaicie korzystają ze swojego dorobku. Na rynku obserwuje się od pewnego czasu sytuacje, w których atakujący wykrywa podatność serwisu internetowego na określony atak, a później spotyka się z przedsiębiorcą i delikatnie „sugeruje” mu zatrudnienie go jako specjalisty od bezpieczeństwa albo oferuje wykonanie odpłatnie audytu zabezpieczeń. W przypadku odmowy grozi ujawnieniem zdobytych informacji. Hakerem dzisiaj może być niestety w zasadzie każdy. Wystarczy dostęp do internetu, wyszukiwarka, możliwość uruchamiania rozmaitych programów znalezionych w sieci i odrobina wiedzy informatycznej. Osoby działające w taki sposób określa się mianem script kiddies. O bezpieczeństwie i programowaniu wiedzą one zazwyczaj niewiele. W ich rękach niektóre narzędzia mogą stać się naprawdę groźne. Prawdziwych hakerów od script kiddies odróżnia m.in. to, że są oni dumni z tego, iż potrafią przeprowadzić atak z profesjonalizmem, nie zostawiając po sobie żadnych śladów, podczas gdy ci drudzy nie przejmują się jakością, ale są zainteresowani jak największą liczbą zhakowanych serwisów. Każdego dnia jakiś serwis jest atakowany. Na stronie http:// www.akamai.com/dv1 można zobaczyć, gdzie w danej chwili nasilenie ataków jest największe. Rysunek W.2 przedstawia częstotliwość ataków w czasie protestów przeciwko podpisaniu ACTA. Do grona cyberprzestępców mogą dołączyć także Twoi byli pracownicy, szczególnie jeśli rozstałeś się z nimi w złości. Zadanie może im ułatwiać znajomość Twojego systemu oraz jego mocnych i słabych stron.

PODSTAWY BEZPIECZEŃSTWA Krystyna Długosz-Kurczabowa w poradni językowej PWN stwierdza, że bezpieczny to taki, który jest bez pieczy, a to dlatego, że tej pieczy nie potrzebuje, nie wymaga, jest zatem pewny, że mu nic

WSTĘP

|

25

Rysunek W.2. Częstotliwość ataków na świecie

nie grozi, jest spokojny15. Angielskie określenie oznaczające bezpieczeństwo — security — odpowiada łacińskiemu securas. Pochodzenie tego wyrazu jest identyczne jak jego polskiego odpowiednika — przedrostek se- oznacza bez, zaś cura to troska. Według słownika języka polskiego bezpieczeństwo to stan niezagrożenia, spokoju, pewności16. W przypadku e-handlu zwykle będziesz operował na informacjach, najczęściej w formie cyfrowej, dlatego warto w tym miejscu 15

http://poradnia.pwn.pl/lista.php?id=8106

16

Słownik języka polskiego, PWN wyd. IX, Warszawa 1994, t. I, s. 147.

26

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

przywołać definicję z normy PN-ISO/IEC 27001:2007117, w której za bezpieczeństwo informacji uważa się zachowanie poufności, integralności i dostępności informacji; dodatkowo mogą być brane pod uwagę inne własności takie jak autentyczność, rozliczalność, niezaprzeczalność i niezawodność. Zachowanie poufności oznacza, że możliwość zapoznania się z informacją mają tylko te osoby, które ją mieć powinny. Integralność (spójność) jest właściwością zapewniającą, że dane nie zostały uszkodzone, zmienione bądź zniszczone przez osobę nieupoważnioną. Dostępność oznacza, że system działa wtedy, kiedy oczekuje się, że będzie działał. Są to najważniejsze z tzw. atrybutów bezpieczeństwa informacji. Przykładowo: • utrata poufności to wyciek informacji o klientach i ich danych osobowych oraz informacji o zakupach; • naruszenie (utrata) integralności to nieuprawniona zmiana danych np. podmiana numeru konta, na jaki mają zostać przelane środki, zmiana kwoty albo wyczyszczenie logów w systemie po włamaniu; • brak dostępności to zablokowanie systemu e-commerce na pewien czas. Na zarządzanie bezpieczeństwem systemu e-commerce składać się może (i będzie) wiele zagadnień. Jedną z najważniejszych rzeczy, które chcielibyśmy tutaj podkreślić, jest jego procesowy charakter. Bezpieczeństwo to proces. Jeśli wdrożysz „bezpieczny” system e-commerce, to stan jego zabezpieczeń będziesz musiał stale monitorować. To zupełnie jak z samochodem: aby mieć pewność, że będzie sprawny, należy co jakiś czas skontrolować stan płynów i pojechać na okresowy przegląd techniczny (co w świecie informatyki ma swój odpowiednik — audyt bezpieczeństwa). 17

PN-ISO/IEC 27001:2007 — Technika informatyczna. Techniki bezpieczeństwa. Systemy zarządzania bezpieczeństwem informacji. Wymagania.

WSTĘP

|

27

Na bezpieczeństwo poszczególnych elementów e-commerce należy patrzeć przede wszystkim w świetle jego znaczenia dla biznesu. Nie powinno się bezkrytycznie stosować wymogów rozmaitych standardów, ale należy analizować oczekiwania przedsiębiorcy i jego „apetyt” na ryzyko. Dlatego w procesie zarządzania bezpieczeństwem zalecamy korzystanie z dwóch narzędzi, które przedstawimy poniżej. Jedno z nich to tzw. analiza wpływu na biznes pozwalająca ocenić, które procesy i zasoby informacyjne związane z e-handlem są krytyczne i mają największe znaczenie dla działalności. Drugie narzędzie to analiza ryzyka. Obu używasz na co dzień, nie zdając sobie sprawy z tego, że to robisz. Ze względu na ograniczoną objętość książki jedynie zasygnalizujemy te ważne zagadnienia, wierząc, że sam znajdziesz więcej informacji na ich temat w innych materiałach.

Analiza wpływu na biznes Analiza wpływu na biznes (BIA — ang. business impact analysis) to, upraszczając, ocena tego, jak przerwa w działaniu określonego procesu wpływa na Twoją działalność. Jest to kompleksowa analiza procesów zachodzących w firmie, która ujawnia tzw. procesy krytyczne i pokazuje na osi czasu, jakie będą konsekwencje ich przerwania (rysunek W.3). Polega ona na oszacowaniu, co się stanie, jeśli dany proces nie będzie funkcjonował np. godzinę, kilka godzin, dzień, dni, tygodnie. W większości przypadków niedużego e-handlu będzie to zależność liniowa. Przykładowo jeśli sklep online dziennie osiąga ze sprzedaży przychód 10 tys. zł, to przerwa tygodniowa oznacza, że nie wpłynie do kasy 70 tys. zł. Jeśli przedsiębiorca nie ma zapasowych środków finansowych na przetrwanie takiej przerwy, to może się okazać, że jest to dla niego sytuacja kryzysowa niosąca nawet ze sobą ryzyko bankructwa. Przerwanie procesu krytycznego może też mieć dodatkowy wymiar w postaci utraty reputacji, bo wielu klientów może się zrazić do niedziałającego sklepu internetowego i — tak jak w świecie rzeczywistym — zrobić zakupy gdzie indziej.

28

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Rysunek W.3. Wykres BIA

Bywa, że zależność ta ma charakter nieliniowy, np. niedostępność systemu (lub procesu) przez dzień to strata w wysokości 50 tys. zł, po dwóch dniach jest to już 200 tys. zł, po tygodniu zaś kilka milionów złotych. Sądzimy jednak, że takie rodzaje e-handlu zdarzają się niezbyt często. Czas, na jaki można przerwać proces biznesowy bez znaczącej szkody dla biznesu, specjaliści od zarządzania ciągłością działania określają terminem RTO (ang. recovery time objective). Dzięki BIA, chociażby w najprostszej postaci, przedsiębiorca wie, które procesy są w jego działalności najważniejsze. Idąc dalej, jest w stanie określić, co w nich bierze udział (jakie zasoby, w tym systemy informatyczne). Na tej podstawie jest później w stanie znaleźć równowagę pomiędzy tym, ile powinien inwestować w zabezpieczenia systemów, a potencjalną stratą. Na rysunku przedstawiono, w jaki sposób można ocenić, ile należy inwestować w zabezpieczenia. Linia ciągła reprezentuje straty poniesione na skutek przerwania procesu, natomiast przerywana obrazuje, ile wynoszą inwestycje w rozwiązania pozwalające unikać przerwy. Im krótsza przerwa jest dopuszczalna, tym większa inwestycja. Szary prostokąt to największa równowaga między potencjalną stratą a wydatkami na zabezpieczenia.

WSTĘP

|

29

Taka analiza stanowi wstęp do procesu tzw. zarządzania ciągłością działania (ang. BCM — business continuity management). Wynika z niej, czego potrzeba (jakich zasobów i danych), aby w razie problemów (sytuacji kryzysowej) „postawić” system gdzieś indziej, i jak się do tego przygotować. W książce tej będziemy pisać o zapasowych kopiach danych, które w takich sytuacjach są niczym dodatkowe kluczyki do samochodu — przydatne, gdy pierwsze zatrzaśniesz w bagażniku. Bez nich trudno mówić o przetrwaniu biznesu. Z BIA będzie też wynikać, jak często należy owe kopie wykonywać, dzięki określeniu, jak dużo danych można stracić w razie sytuacji kryzysowej. Jest to tzw. RPO (ang. recovery point objective), czyli wskaźnik określający, jakiej części danych może zabraknąć w takiej sytuacji (maksymalna tolerancja utraty danych)18.

Szacowanie ryzyka Termin analiza ryzyka brzmi bardzo specjalistycznie, w gruncie rzeczy posługujesz się nią jednak na co dzień, czasami nie zdając sobie z tego sprawy. Zastanów się na przykład, dlaczego kupujesz (bądź nie) ubezpieczenie autocasco dla swojego samochodu. Robisz to (albo i nie), bo szacujesz najpierw jego wartość, a później w odniesieniu do niej analizujesz zagrożenia i prawdopodobieństwo ich „zmaterializowania” się. Jeśli auto jest dużo warte i jest wiele zagrożeń (inni kierowcy, złodzieje, wandale, niebezpieczna okolica), to uznajesz, że jest wysokie prawdopodobieństwo, iż coś się stanie, np. samochód zostanie skradziony lub uszkodzony. Gdybyś miał tani, wieloletni samochód, to pomimo zagrożeń autocasco by Cię pewnie nie interesowało, gdyż potencjalna strata byłaby mała, a i ryzyko kradzieży byłoby znacznie mniejsze, bo nie każdy chce kraść coś mało wartościowego. 18

Parametrami RTO i RPO często posługują się informatycy w trakcie tworzenia strategii archiwizacji baz danych — http://technet.microsoft. com/pl-pl/library/kopie-zapasowe-sql-server.aspx.

30

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Na tym przykładzie z łatwością możemy wyjaśnić pojęcia, jakie pojawiają się w analizie ryzyka. Mamy tutaj zagrożenia (ang. threats) — są nimi złodzieje, wandale lub też uczestnicy ruchu drogowego, i mamy podatności (ang. vulnerabilities) — będą nimi parkowanie samochodu w miejscach publicznych, konstrukcja zamka w drzwiach czy też szyby, które można wybić. Ryzyko inherentne, które można by nazwać ryzykiem pierwotnym, to z kolei poziom zagrożenia występującego, gdy nie ma jeszcze żadnych dodatkowych zabezpieczeń. Żeby zmniejszyć prawdopodobieństwo (zminimalizować ryzyko) kradzieży samochodu, instaluje się alarm i rozmaite blokady, czyli stosuje się zabezpieczenia. Poziom ryzyka, które pozostaje po ich instalacji, nazywa się ryzykiem szczątkowym albo rezydualnym, chociaż najlepiej brzmiałoby ryzyko bieżące czy też pozostałe. Gdy możliwość, że stanie się coś niepożądanego, wciąż istnieje, ale jest na tyle niewielka, że można ją zaakceptować, to ryzyko jest dopuszczalne. Zwykło się mówić wtedy, że nie ma ryzyka, chociaż w istocie jest ono na bardzo niskim poziomie. Na ryzyko dopuszczalne używa się jeszcze określenia „akceptowalne”, ale może ono wprowadzać w błąd i mylić się z ryzykiem zaakceptowanym. Akceptacja ryzyka polega na tym, że nie jest bezpiecznie, ale ten stan rzeczy się akceptuje, godzi się na niego. Przykładowo kupując zakład lotto i płacąc za niego 3 zł, mówi się, że nic się nie ryzykuje. W istocie ryzykuje się zapłaconą kwotę, ale jest ona tak mała, że ryzyko jej straty w porównaniu do potencjalnej wygranej wydaje się wręcz zerowe. Jest to ryzyko akceptowalne. Gdy jednak chodzi o tysiąc zakładów za łączną kwotę 3 tys. zł, to widać już gołym okiem, że podejmowane jest ryzyko. Grający akceptuje je, bo „nie wygrywa ten, kto nie gra”, ale nie jest ono równoważne z ryzykiem akceptowalnym (dopuszczalnym), czyli dającym poczucie bezpieczeństwa, stanu, w którym nic się nie ryzykuje. Jest

WSTĘP

|

31

to już tzw. apetyt na ryzyko, a więc stan, w którym je podejmujesz, będąc go świadomym, choć nie czujesz się z tym komfortowo. Tutaj dochodzimy do innej definicji bezpieczeństwa. Zgodnie z nią jest to stan, w którym ryzyka są na poziomie dopuszczalnym. Warto podkreślić, że ryzyko jest nieodłącznym elementem nie tylko e-commerce, ale całego naszego życia. Na każdym kroku spotyka się zagrożenia, stosuje zabezpieczenia i ocenia się, czy istniejący stan rzeczy można zaakceptować. Analiza ryzyka jest narzędziem, które pozwala racjonalnie i świadomie inwestować w zabezpieczenia, a w sytuacji, gdy budżet na nie jest niewystarczający, określać, w jakiej kolejności należy się nimi zajmować. Na jej podstawie z podanych w dalszej części książki materiałów będziesz mógł wybierać to, co ma dla Ciebie i dla Twojego biznesu największe znaczenie. Dobrze też wiedzieć, że porównanie stanu ryzyka aktualnego (rezydualnego) z ryzykiem dopuszczalnym daje Ci miarę tego, ile brakuje Ci do stanu bezpieczeństwa, jakiego potrzebujesz, aby uznać, że biznes prowadzisz bezpiecznie — bez ryzyka.

32

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Rozdział 1.

PRAWO WOBEC E-COMMERCE

Zastanawiając się nad problemem bezpieczeństwa e-commerce, należy stwierdzić, że bezpieczeństwo systemu to nie tylko bezpieczna aplikacja — to w gruncie rzeczy możliwość bezpiecznego funkcjonowania całego biznesu. Nie mówimy przecież o bezpieczeństwie samych danych, ale o całości przedsięwzięcia, jakim jest handel przez internet. Przedsiębiorca prowadzący taką działalność podlega rozmaitym aktom prawnym, które regulują w jakiś sposób tę formę biznesu. W wielu miejscach czyha na niego wiele niespodzianek. Ba, chciałoby się rzec, że nawet pułapek! Przykładem mogą być łowcy nieprawidłowych zapisów w regulaminach sklepów internetowych, którzy (jeśli znajdą takie zapisy) żądają opłaty na drodze ugody, a w przeciwnym wypadku kierują sprawę do odpowiedniego sądu1. Prawo warto znać w tym zakresie, w jakim dotyczy ono Twojej działalności, gdyż ignorantia iuris nocet — nieznajomość prawa szkodzi. Przed sądem niewiele da tłumaczenie, że się czegoś nie wiedziało. Dlatego naszym zdaniem na bezpieczeństwo systemu e-commerce składa się także bezpieczeństwo prawne. Chcemy także podkreślić, że prawo nie tylko będzie stawiać wymagania. Będzie ono także chronić Ciebie i Twój 1

Więcej na ten temat na stronie http://interaktywnie.com/biznes/ artykuly/e-commerce/pozwy-za-regulaminy-beda-umorzone-e-sklepomsie-upieklo-21787.

34

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

biznes. Są przepisy, na podstawie których cyberprzestępca uzyskujący nieuprawniony dostęp do Twojego systemu może być karany. Możesz nawet nie mieć zabezpieczeń, a prawo i tak będzie Cię chronić. O tym także warto wiedzieć i w tym rozdziale przedstawimy choćby zarys tych przepisów. Zaczniemy od tego, co z prawa wydaje nam się najważniejsze w e-handlowaniu, czyli od regulaminu serwisu. Pokażemy krok po kroku, jak go przygotować i co powinien on zawierać. Następnie przejdziemy do pozostałych zagadnień prawnych, aby pokazać Ci, w jakim otoczeniu prawnym znajduje się system e-commerce.

JAKIE PRAWO DOTYCZY E-HANDLU? Akty prawne związane z handlem elektronicznym można ująć w następujące klasy zagadnień: • obrót elektroniczny (reguły handlowania przez internet); • prawa konsumentów (szczególne prawa w przypadku umów zawieranych drogą internetową); • przetwarzanie danych osobowych (w przypadku gdy użytkownikami e-commerce są osoby fizyczne); • przepisy chroniące system e-commerce i informacje w nim przetwarzane; • reguły handlu z zagranicą wskazujące, których państw przepisy należy stosować w danej sytuacji2 (chodzi o przypadek, gdy

2

Zob. w szczególności: Ustawa z dnia 4 lutego 2011 r. prawo prywatne międzynarodowe oraz Rozporządzenie Parlamentu Europejskiego i Rady (WE) nr 593/2008 z dnia 17 czerwca 2008 r. w sprawie prawa właściwego dla zobowiązań umownych (Rzym I). W artykule 28 powyższego rozporządzenia napisano: W przypadku handlu z konsumentami należy zapoznać się z przepisami unijnymi, w tym m.in. z nowym zestawem reguł

PRAWO WOBEC E-COMMERCE

|

35

kupującym jest np. obywatel innego państwa składający zamówienie za granicą); • przepisy ogólne3 i branżowe dotyczące prowadzenia działalności gospodarczej. Podejmując się tworzenia platformy e-commerce, powinieneś najpierw ustalić „architekturę” przepisów, tj. określić, które przepisy będą Ciebie (jako właściciela) dotyczyć oraz jakie wynikają z nich prawa i obowiązki. Należy rozważyć tutaj kwestie prawne głównie na trzech liniach: • Ty i Twoi dostawcy (np. hostingu, aplikacji); • Ty i Twoi usługobiorcy, klienci, użytkownicy systemu (np. obowiązki informacyjne); • inne, do których powinieneś się stosować, prowadząc biznes online (np. dotyczące obowiązków rejestracyjnych ciążących na przedsiębiorcach). W książce, ze względu na obszerność tematu, skupimy się głównie na stosunkach prawnych pomiędzy sklepem e-commerce a klientem zarówno w relacjach B2B, jak i B2C. Oto akty prawne mające największy wpływ na funkcjonowanie e-commerce, a więc także i na system jako taki: podstawowych dla umów zawieranych na odległość i poza lokalem przedsiębiorstwa w Unii Europejskiej wynikającym z Dyrektywy Parlamentu Europejskiego i Rady nr 2011/83/UE z dnia 25 października 2011 r. w sprawie praw konsumentów [...]. Kraje członkowskie mają czas do 13 czerwca 2013 r. na przyjęcie i opublikowanie w swoim porządku prawnym regulacji zgodnych z nową dyrektywą, a okres vacatio legis tych regulacji nie powinien przekroczyć terminu 13 czerwca 2014 r. 3

M.in. ustawa o swobodzie działalności gospodarczej oraz Kodeks spółek handlowych.

36

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

• ustawa o świadczeniu usług drogą elektroniczną (UŚUDE)4; • ustawa o ochronie danych osobowych (UODO), a także rozporządzenie w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (rozporządzenie); • ustawa o ochronie niektórych praw konsumentów oraz o odpowiedzialności za szkodę wyrządzoną przez produkt niebezpieczny (UPK); • ustawa o szczególnych warunkach sprzedaży konsumenckiej (USK): • Kodeks cywilny (k.c.); • ustawa o ochronie niektórych usług świadczonych drogą elektroniczną opartych lub polegających na dostępie warunkowym (UDW); • ustawa o ochronie baz danych (UBD); • ustawa o podpisie elektronicznym (UPE); • ustawa o świadczeniu usług na terytorium Rzeczypospolitej Polskiej. Dalej w tekście, aby nie powoływać się na pełne nazwy aktów prawa, będziemy posługiwać się skrótami, które podaliśmy przy nazwach ustaw. Sądzimy, że dzięki temu książka będzie bardziej czytelna.

4

Zwyczajowo, powołując się na przepisy prawa, podaje się dzienniki ustaw, w których zostały one opublikowane, a także daty uchwalenia ustaw. Mamy jednak na uwadze fakt, że odbiorcami książki nie są wyłącznie prawnicy, i rezygnujemy z powoływania się na nie. Książka opisuje stan prawny na dzień 5 lutego 2012 r.

PRAWO WOBEC E-COMMERCE

|

37

Zaczniemy od tego, co pod względem prawnym wydaje nam się najważniejsze w e-handlowaniu, czyli od regulaminu serwisu, i pokażemy krok po kroku, jak go przygotować.

REGULAMIN SERWISU Jedną z ustaw, która szczególnie dotyczy biznesu prowadzonego przez internet, jest UŚUDE. Wynika z niej m.in. obowiązek przygotowania regulaminu (art. 8): 1. Usługodawca: 1) określa regulamin świadczenia usług drogą elektroniczną, zwany dalej „regulaminem”, 2) nieodpłatnie udostępnia usługobiorcy regulamin przed zawarciem umowy o świadczenie takich usług, a także — na jego żądanie — w taki sposób, który umożliwia pozyskanie, odtwarzanie i utrwalanie treści regulaminu za pomocą systemu teleinformatycznego, którym posługuje się usługobiorca. Usługodawcą jest prowadzący system, a usługobiorcą, co wydaje się oczywiste, klient czy też raczej użytkownik systemu. Wracając do regulaminu, należy zauważyć, że ustawa nakazuje go sporządzić, ale jego brak nie prowadzi do powstania odpowiedzialności karnej. Brak przepisów karnych nie oznacza jednak, że nie ma wcale ryzyka prawnego dla właściciela systemu. Nieokreślenie regulaminu może prowadzić do powstania po stronie usługodawcy odpowiedzialności odszkodowawczej. W części poświęconej obowiązkom informacyjnym pokażemy, że użytkownikom e-commerce (w tym konsumentom) należy przekazywać wiele rozmaitych informacji, a za nierobienie tego grozi np. kara grzywny. Najlepszym sposobem ich przekazania jest zamieszczenie ich w regulaminie. Przygotowanie regulaminu daje korzyści

38

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

obu stronom — klient będzie wiedział, na jakich zasadach zawiera umowę5, przedsiębiorca zaś będzie mógł „wyłączyć” swoją odpowiedzialność w określonych zakresach. Jednym słowem, jest to narzędzie, które pozwala obu stronom umówić się co do tego, jak będzie świadczona usługa — dlatego regulamin mimo wszystko warto mieć. Regulamin jest obowiązkowy dla podmiotów — jak to określono w ustawie — świadczących usługi drogą elektroniczną6, a więc wtedy, gdy e-commerce ma formę bezpośrednią, tj. całość usługi łącznie z dostarczeniem zamówienia świadczona jest elektronicznie. Pojawia się jednak pytanie, czy regulamin muszą posiadać (chodzi nam o konieczność wynikającą z prawa) podmioty wykonujące transakcje pośrednie, czyli takie, w przypadku których tylko zawarcie umowy następuje za pośrednictwem sieci, ale jej wykonanie wymaga

5

Pamiętajmy, że zgodnie z art. 384 §1 k.c. regulamin należy traktować jako wzorzec umowy: Ustalony przez jedną ze stron wzorzec umowy, w szczególności ogólne warunki umów, wzór umowy, regulamin, wiąże drugą stronę, jeżeli został jej doręczony przed zawarciem umowy. Jeśli chodzi o regulamin (jako wzorzec), to zdaniem Pawła Litwińskiego jego postanowienia stanowią integralną część umowy o świadczenie usług drogą elektroniczną, pod warunkiem że zostaną prawidłowo inkorporowane do treści umowy, czyli prawidłowo do niej włączone (P. Litwiński w: Prawo internetu, red. P. Podrecki, Warszawa 2006, wydanie 2, s. 202).

6

Art. 2 pkt 4 UŚUDE definiuje świadczenie usługi drogą elektroniczną jako wykonanie usługi świadczonej bez jednoczesnej obecności stron (na odległość), poprzez przekaz danych na indywidualne żądanie usługobiorcy, przesyłanej i otrzymywanej za pomocą urządzeń do elektronicznego przetwarzania, włącznie z kompresją cyfrową, i przechowywania danych, która jest w całości nadawana, odbierana lub transmitowana za pomocą sieci telekomunikacyjnej.

PRAWO WOBEC E-COMMERCE

|

39

tradycyjnych sposobów dostawy (poczta, przesyłki kurierskie)7. Chodzi tutaj o znakomitą większość rynku e-commerce w postaci rozmaitych sklepów internetowych. Z jednej z decyzji UOKiK-u8 można wywnioskować, że w takim przypadku regulamin też jest obowiązkowy, gdyż poprzez internet dochodzi do zawarcia umowy, wskutek czego zastosowanie mają przepisy UŚUDE. Przy tworzeniu regulaminu należy pamiętać o obostrzeniu prawnym wynikającym z art. 8 ust. 2 UŚUDE, zgodnie z którym usługobiorca nie jest związany tymi postanowieniami regulaminu, które nie zostały mu nieodpłatnie udostępnione przez usługodawcę przed zawarciem umowy9. W praktyce oznacza to najczęściej, że jeśli nie udostępniliśmy użytkownikowi konkretnych zapisów regulaminu, to one go nie obowiązują. W związku z tym jeśli serwis nie będzie działał z powodu przerwy technicznej (np. spowodowanej aktualizacją systemu), usługobiorca zaś będzie (poprzez regulamin) poinformowany, że takie konserwacje mogą być przeprowadzane, to nie będzie on mógł twierdzić, że umowa w tym zakresie nie jest w stosunku do niego prawidłowo realizowana, bo nie ma dostępu do serwisu. Należy zauważyć że regulamin zgodnie z prawem należy udostępniać na żądanie w sposób, który umożliwia pozyskanie, odtwarzanie i utrwalanie treści. Naszym zdaniem najlepiej by było, aby regulamin był dostępny dla każdego (w tym także dla niezalo7

P. Podrecki, Prawo internetu, wydanie 2, Warszawa 2006, str. 49.

8

Decyzja nr RWR 11/2011 z dnia 17 czerwca 2011 r. — http://www. uokik.gov.pl/decyzje_prezesa_uokik3.php.

9

Taki sam skutek braku związania postanowieniami będzie występował w przypadku tych postanowień, które zgodnie z UŚUDE powinny były znaleźć się w regulaminie, a nie zostały do niego wpisane; zob. J. Gołaczyński, Ustawa o świadczeniu usług drogą elektroniczną. Komentarz, Warszawa 2009, s. 94.

40

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

gowanego użytkownika) w witrynie serwisu internetowego10, a nie tylko dla tych, którzy tego „zażądają”. Zresztą wydaje się to raczej powszechną praktyką. Regulamin zgodnie z art. 8 ust. 3 UŚUDE określa co najmniej: 1. rodzaje i zakres usług świadczonych drogą elektroniczną, 2. warunki świadczenia usług drogą elektroniczną, w tym: a) wymagania techniczne niezbędne do współpracy z systemem teleinformatycznym, którym posługuje się usługodawca, b) zakaz dostarczania przez usługobiorcę treści o charakterze bezprawnym, 3. warunki zawierania i rozwiązywania umów o świadczenie usług drogą elektroniczną, 4. tryb postępowania reklamacyjnego. Opracowując regulamin, należy wziąć pod uwagę zapisy prawa, które będą dotyczyć przedsiębiorcy prowadzącego e-commerce (wskażemy je dalej w książce) i jednocześnie sprawdzić, czy zapisy, 10

Zdania na temat tego, jak należy udostępniać regulamin, są podzielone. Obowiązek odpowiedniego udostępnienia regulaminu (jako tzw. wzorca umownego w postaci elektronicznej) wynika także z art. 384 §4 Kodeksu cywilnego. Według Xawerego Konarskiego decydujące znaczenie mają przepisy UŚUDE. W przepisach Kodeksu cywilnego chodzi w szczególności o udostępnienie wzorca w sposób zapewniający drugiej stronie realną możliwość łatwego zapoznania się z jego treścią (X. Konarski, Komentarz do ustawy o świadczeniu usług drogą elektroniczną, Warszawa 2004, s. 105). Swoje wątpliwości co do słuszności powyższej opinii wyraził Paweł Litwiński, z którego stanowiska można wnioskować, że aby regulamin obowiązywał usługobiorcę, nie wystarczy jedynie nieodpłatnie go udostępnić przed zawarciem umowy, ale należy spełnić postanowienia art. 384 §1 lub 2 Kodeksu cywilnego (zob. P. Litwiński w: Prawo internetu, red. P. Podrecki, Warszawa 2006, wydanie 2, s. 203).

PRAWO WOBEC E-COMMERCE

|

41

które mają znaleźć się w regulaminie, nie są tzw. niedozwolonymi postanowieniami umownymi11 lub klauzulami wpisanymi do rejestru UOKiK-u12. Niedozwolone zapisy w umowie Wspomnieliśmy, że należy uważać na niedozwolone postanowienia umowne określane także mianem klauzul abuzywnych13. Nie wolno ich wprowadzać do regulaminu, a naruszenie tej zasady może prowadzić do dotkliwych konsekwencji prawnych14, np. może skończyć się sprawą sądową o uznanie zapisów za niedozwolone i poniesieniem kosztów procesu lub — co gorsze — nałożeniem kar pieniężnych przez UOKiK15. Warto zauważyć, że niedozwolone postanowienia dotyczą praw konsumentów i nie mają zastosowania w przypadku umów między przedsiębiorstwami. W myśl art. 221 k.c. konsumentem jest osoba fizyczna dokonująca czynności prawnej niezwiązanej bezpośrednio z jej działalnością gospodarczą lub zawodową. Tę definicję warto zapamiętać, bo prawo w wielu miejscach przyznaje konsumentom różne przywileje.

11

Niedozwolone klauzule umowne określone są w art. 385¹ i dalszych Kodeksu cywilnego.

12

http://www.uokik.gov.pl/niedozwolone_klauzule.php

13

Abuzywny oznacza niedozwolony. Słowo to wykazuje podobieństwo do ang. abuse — wykorzystanie, nadużycie.

14

Wynikać one mogą z przepisów ustawy o ochronie konkurencji i konsumentów lub z Kodeksu postępowania cywilnego. Chodzi w tym przypadku o poniesienie przez przedsiębiorcę kosztów opublikowania wyroku w „Monitorze Sądowym i Gospodarczym” oraz ewentualnych kosztów zastępstwa procesowego wykonywanego przez radcę prawnego lub adwokata na rzecz konsumenta.

15

Zob. artykuł na stronie „Rzeczpospolitej” pt. Sprawdź rejestr, zanim złożysz pozew — http://www.rp.pl/artykul/67430.html.

42

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Stosowanie klauzul abuzywnych w obrocie z konsumentami zdaniem UOKiK-u staje się zakazane od momentu wpisania ich treści do rejestru urzędu16. Warto w tym miejscu przytoczyć pogląd wyrażony przez Kingę Flagę-Gieruszyńską w komentarzu do Kodeksu postępowania cywilnego, zgodnie z którym wyroki te zakazują stosowania wymienionych postanowień wzorca umowy konkretnemu podmiotowi. […] stwierdzenie abuzywności następuje w kontekście całego wzorca i w odniesieniu do stosunków prawnych, które reguluje17. Ze stwierdzenia autorki komentarza wynika, że te same zapisy w kontekście innego regulaminu nie muszą wcale zostać uznane za klauzule niedozwolone (chociaż mogą). Nie zmienia to jednak faktu, że jeśli w Twoim regulaminie znajdą się klauzule podobne do tych uznanych za niedozwolone, to może znaleźć się ktoś, kto zechce wytoczyć powództwo przeciwko Tobie18. Sprawdzenie, czy określony zapis regulaminu nie jest niedozwoloną klauzulą, jest bardzo czasochłonne, ponieważ w rejestrze znajduje się już ponad 2700 zapisów i ciągle ich przybywa. Nie dziwi nas więc, że są na rynku firmy, które biorą opłatę za przygotowanie regulaminu. Niedozwolone postanowienia umowne definiuje Kodeks cywilny w art. 3851: Postanowienia umowy zawieranej z konsumentem nie uzgodnione indywidualnie nie wiążą go, jeżeli kształtują jego prawa i obowiązki w sposób sprzeczny z dobrymi obyczajami, rażąco 16

Wpis jest dokonywany na podstawie prawomocnego wyroku Sądu Ochrony Konkurencji i Konsumentów — http://www.uokik.gov.pl/ niedozwolone_klauzule.php.

17

K. Flaga-Gieruszyńska w: Kodeks postępowania cywilnego. Komentarz, 2011, wydanie 5, publikacja — art. 47943, komentarz w pkt 6.

18

Takie stanowisko wyraził SN w uchwale z dnia 7.10.2008 r., sygn. III CZP 89/08.

PRAWO WOBEC E-COMMERCE

|

43

naruszając jego interesy. Nie dotyczy to postanowień określających główne świadczenia stron, w tym cenę lub wynagrodzenie, jeżeli zostały sformułowane w sposób jednoznaczny. W art. 3853 k.c. został zawarty przykładowy katalog takich zapisów. Są nimi w szczególności zapisy, które: • wyłączają lub istotnie ograniczają odpowiedzialność względem konsumenta za niewykonanie lub nienależyte wykonanie zobowiązania; • wyłączają obowiązek zwrotu konsumentowi uiszczonej zapłaty za świadczenie niespełnione w całości lub w części, jeżeli konsument zrezygnuje z zawarcia umowy lub jej wykonania; • pozbawiają wyłącznie konsumenta uprawnienia do rozwiązania umowy, odstąpienia od niej lub jej wypowiedzenia; • przewidują obowiązek wykonania zobowiązania przez konsumenta mimo niewykonania lub nienależytego wykonania zobowiązania przez jego kontrahenta; • wyłączają jurysdykcję sądów polskich lub poddają sprawę pod rozstrzygnięcie sądu polubownego polskiego lub zagranicznego albo innego organu, a także narzucają rozpoznanie sprawy przez sąd, który wedle ustawy nie jest miejscowo właściwy. W przypadku wystąpienia niedozwolonego postanowienia umownego nie wiąże ono konsumenta, a w pozostałym zakresie umowa obowiązuje (art. 3851 § 2 k.c.). Sąd Ochrony Konkurencji i Konsumentów może uznać za niedozwoloną każdą klauzulę umowną spełniającą wymogi tzw. klauzuli generalnej z art. 3851 § 1 k.c. Chodzi o nieprecyzyjne ogólne zapisy, które zostawiają pole do (najczęściej różnych) interpretacji. Zatem jeśli takie nieprecyzyjne zapisy są w regulaminie, to są one ryzykowne.

44

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

W przypadku e-commerce klauzule generalne umożliwiają konstruowanie innych niedozwolonych klauzul, przykładowo takich, które narzucają konsumentowi rażąco niskie standardy zabezpieczeń informacji w systemie teleinformatycznym19. Od strony proceduralnej postępowanie w sprawach o uznanie postanowień wzorca umowy za niedozwolone zostało uregulowane w art. 47936 – 47945 k.p.c. Przeciwko temu, kto stosuje niedozwolone klauzule, może wytoczyć powództwo w zasadzie każdy, kto mógłby zawrzeć z nim umowę zawierającą takie postanowienia. Może zrobić to także organizacja społeczna, do której zadań statutowych należy ochrona interesów konsumentów, rzecznicy konsumentów oraz Prezes UOKiK-u (art. 47938 k.p.c.). Na szczególną uwagę zasługuje art. 47939 k.p.c.: Z żądaniem uznania postanowienia wzorca umowy za niedozwolone można wystąpić również wtedy, gdy pozwany zaniechał jego stosowania, jeżeli od tego zaniechania nie minęło sześć miesięcy. Oznacza to, że jeżeli nawet dany przedsiębiorca po wytoczeniu przeciw niemu powództwa wycofa z regulaminu wadliwe zapisy, to nic to nie da i nie będzie mieć wpływu na bieg postępowania sądowego (art. 47940 k.p.c.). Zachęcamy do zapoznania się z bardzo interesującym materiałem na powyższy temat, Nieuczciwe praktyki rynkowe. Przewodnik, przygotowanym przez Urząd Ochrony Konkurencji i Konsumentów20.

19

A. Stosio, Umowy zawierane przez Internet, Warszawa 2002, s. 268.

20 http://www.uokik.gov.pl/download.php?plik=11185

PRAWO WOBEC E-COMMERCE

|

45

Przykładowy regulamin Dobry regulamin powinien być uszyty na miarę i dostosowany do specyfiki prowadzonego biznesu e-commerce. Przykładowy regulamin może być skonstruowany według przedstawionych poniżej zaleceń. Żeby ułatwić jego przygotowanie, będziemy przytaczać niektóre z najciekawszych naszym zdaniem niedozwolonych klauzul umownych. Postanowienia ogólne W tej części podaje się najczęściej następujące informacje: • wymagane przepisami prawa informacje o podmiocie prowadzącym e-commerce (wynikające z tzw. obowiązków informacyjnych), w tym m.in. dane firmy; • dane kontaktowe oraz dni i godziny, w których można kontaktować się z przedsiębiorcą; • rodzaj i zakres prowadzonej działalności e-commerce (co stanowić będzie spełnienie wymogu z art. 8 ust. 3 pkt 1 UŚUDE); • kto może korzystać ze sklepu (np. konsument czy przedsiębiorca, a może jeden i drugi; osoby dorosłe czy także niepełnoletnie za zgodą przedstawiciela ustawowego); • informacje o prawach autorskich; • zakaz dostarczania przez usługobiorcę treści o charakterze bezprawnym (jako spełnienie wymogu z art. 8 ust. 3 pkt 2 lit. b) UŚUDE); • wymagania techniczne, jakie musi spełnić użytkownik, aby współpracować z systemem e-commerce (spełnienie wymogu z art. 8 ust. 3 pkt 2 a) UŚUDE).

46

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Definicje Ta część pozwoli wyjaśnić w jednym miejscu kluczowe pojęcia używane w regulaminie takie jak usługodawca (lub po prostu firma), użytkownik (lub np. klient), zamówienie, umowa i tak dalej. Warunki zawierania umowy Warunki zawierania umowy będą odnosić się wprost do wymogu z art. 8 ust. 3 pkt 3) UŚUDE. Możemy przykładowo zaliczyć do nich zapisy dotyczące: • warunków do spełnienia przez klienta (np. dokonanie wyboru towaru lub usługi, przekazanie w określony sposób danych niezbędnych do transakcji, np. poprzez formularz zamówienia, akceptacja niniejszego regulaminu itd.); • określenia chwili zawarcia umowy, w tym procedury składania zamówienia (np. z wykorzystaniem formularza zamówienia), a także określenia zasad dotyczących cen (brutto czy netto). Płatności Tu znajdą się postanowienia dotyczące sposobu i terminu płatności. W przypadku B2C należy pamiętać, że zgodnie z art. 11 ust. 1 UPK umowa nie może nakładać na konsumenta obowiązku zapłaty ceny lub wynagrodzenia przed otrzymaniem świadczenia. Zgodnie z literą prawa nie można więc przymuszać klienta do zapłaty z góry. Realizacja umowy W tej części znajdą się w szczególności zasady dotyczące dostawy, czyli określenie sposobu dostawy, odbioru oraz związanych z tym kosztów. W przypadku B2C przy konstruowaniu tych zapisów należy mieć na uwadze art. 12 ust. 1 UPK, zgodnie z którym jeżeli strony nie umówiły się inaczej, przedsiębiorca powinien wykonać umowę zawartą na odległość najpóźniej w terminie trzydziestu

PRAWO WOBEC E-COMMERCE

|

47

dni po złożeniu przez konsumenta oświadczenia woli o zawarciu umowy. Towar zatem powinien dotrzeć do klienta w ciągu 30 dni od złożenia zamówienia. Oto klauzule niedozwolone z rejestru UOKiK-u dotyczące tej części regulaminu: • Uszkodzenia powstałe w czasie dostawy i transportu będą rozpatrywane tylko, gdy usterka zostanie odkryta w obecności pracownika firmy kurierskiej. W takim przypadku niezbędne jest spisanie protokołu szkody w obecności pracownika firmy kurierskiej21. • Sklep nie ponosi odpowiedzialności za opóźnienia w dostawie zamówionych produktów wynikłe z przyczyn niezależnych od niego, w tym opóźnienia wynikłe z winy przewoźnika22. • Sklep nie odpowiada za terminowość dostarczania przesyłek przez firmy kurierskie23. Gwarancja i postępowanie reklamacyjne Określając tytułowe zapisy, spełnia się wymóg art. 8 ust. 3 pkt. 4) UŚUDE. W przepisach nie ma wskazówek dotyczących tego, jak powinno przebiegać postępowanie reklamacyjne. Wydaje się rozsądne określenie w tym miejscu w szczególności: • dnia, miejsca i sposobu złożenia reklamacji (pamiętać należy o tym, aby nie powodowało to nadmiernych trudności lub kosztów dla składającego — punkt ten jest szczególnie ważny w przypadku B2C, gdyż prowadzi do spełnienia obowiązków prawnych wynikających z art. 11 ust. 2 UPK);

21

Nr wpisu: 2519, data wpisu: 19.09.2011 r.

22

Nr wpisu: 2101, data wpisu: 06.12.2010 r.

23

Nr wpisu: 1895, data wpisu: 19.04.2010 r.

48

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

• elementów niezbędnych do prawidłowego jej złożenia, w tym danych identyfikujących osobę ją składającą; • przedmiotu reklamacji; • okoliczności uzasadniających reklamację; • czasu udzielenia odpowiedzi i formy, w jakiej ona nastąpi; • jakie klient ma prawa w przypadku uznania reklamacji; • zasad dotyczących odwołań klienta od odpowiedzi na reklamację. Poniżej przedstawiamy niektóre z klauzul z rejestru UOKiK-u. • Reklamacje dotyczące uszkodzeń mechanicznych lub braków powstałych podczas transportu będą rozpatrywane pod warunkiem przyjęcia tego typu reklamacji przez kuriera i sporządzenia przez niego protokołu reklamacyjnego24. • Reklamacje dotyczące uszkodzeń mechanicznych powstałych podczas transportu będą rozpatrywane tylko w momencie odbioru towaru w obecności dostawcy (kuriera lub pracownika Poczty Polskiej)25. • Koszt przesyłki reklamowanego towaru pokrywa kupujący26. Należy też wystrzegać się klauzul wyłączających odpowiedzialność sklepu e-commerce w przypadku wystąpienia nieścisłości w opisie towaru. Poniżej przedstawiamy przykładowe niedozwolone zapisy. • Mimo wszelkich starań sklep zastrzega sobie możliwość błędów w opisie produktów. Zdjęcia produktów są jedynie przykładowe27. 24

Nr wpisu: 1889, data wpisu: 19.04.2010r.

25

Nr wpisu: 2368, data wpisu: 16.06.2011 r.

26

Nr wpisu: 2760, data wpisu: 03.01.2012 r.

27

Nr wpisu: 1915, data wpisu: 27.04.2010 r.

PRAWO WOBEC E-COMMERCE

|

49

• Nie ponosimy jednak odpowiedzialności za błędne podanie parametrów i właściwości towaru lub nagłą ich zmianę przez jego producenta28. • Zdjęcia, kolor i opisy produktów mają wyłącznie charakter orientacyjny i nie mogą być podstawą do jakichkolwiek roszczeń i reklamacji29. Przy określaniu w regulaminie spraw związanych z ewentualnymi sporami i procedurą reklamacyjną należy pamiętać, że niezgodne z prawem jest stawianie usługobiorcy warunku, iż w celu dochodzenia roszczeń w postępowaniu sądowym musi on najpierw wyczerpać drogę postępowania reklamacyjnego30. Wydaje nam się, że ryzykowne jest „bronienie” w regulaminie zapisów dotyczących skuteczności złożenia reklamacji po odbiorze towaru na podstawie przepisu art. 545 § 231 w związku z art. 5351

28 Nr

wpisu: 2101, data wpisu: 06.12.2010 r.

29 Nr

wpisu: 2773, data wpisu: 03.01.2012 r.

30 Zob.

X. Konarski, op. cit., s. 106. Pogląd niepokrywający się całkowicie z przedstawionym prezentuje Jacek Gołaczyński w: Ustawa o świadczeniu usług drogą elektroniczną. Komentarz, Warszawa 2009, s. 96. Stwierdza on: Postępowanie reklamacyjne nie wyłącza możliwości dochodzenia roszczeń w postępowaniu cywilnym oraz za dopuszczalne brzmienie klauzuli uznaje jej postać następującą: Prawo do dochodzenia w postępowaniu sądowym roszczeń wynikających z niniejszej umowy przysługuje usługobiorcy po wyczerpaniu drogi postępowania reklamacyjnego.

31

W razie przesłania rzeczy sprzedanej do miejsca przeznaczenia za pośrednictwem przewoźnika kupujący zobowiązany jest zbadać przesyłkę. Jeżeli stwierdzi, że w czasie przewozu nastąpiło uszkodzenie rzeczy, zobowiązany jest dokonać wszelkich czynności niezbędnych do ustalenia odpowiedzialności przewoźnika.

50

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

k.c.32. Sądzimy, że najbezpieczniej będzie wpisać do regulaminu ogólne zalecenie sprawdzenia przez klienta stanu przesyłki w obecności przewoźnika bez określania negatywnych skutków prawnych dla konsumenta, jeśli nie zastosuje się on do tego zalecenia. Odstąpienie lub rozwiązanie umowy Razem z częścią dotyczącą warunków zawierania umów ta część regulaminu stanowić będzie spełnienie wymogu z art. 8 ust. 3 pkt 3) UŚUDE, a także z art. 9 ust. 1 pkt 6) UPK. W części tej znajdą się zasady dotyczące odstąpienia od umowy i zwrotu towarów. W przypadku B2C należy pamiętać o zapewnieniu zgodności treści regulaminu z wymienionymi poniżej przepisami UPK. • Konsument może odstąpić od umowy bez podania przyczyny, składając stosowne oświadczenie na piśmie w terminie 10 dni ustalonym w sposób podany w ustawie (art. 7 ust. 1 UPK). • Za skuteczne wypowiedzenie należy uznać już samo wysłanie oświadczenia (chociażby e-mailem) przed upływem ustalonego terminu (art. 7 ust. 1 UPK). • W przypadku niepoinformowania klienta o wskazanym terminie termin odstąpienia od umowy przedłuża się automatycznie do 3 miesięcy (art. 10 ust. 1 i 2 UPK). • Nie można uzależnić uznania odstąpienia od umowy od zapłaty przez konsumenta oznaczonej kwoty pieniężnej, tzw. odstępnego (art. 7 ust. 2 UPK). • W razie odstąpienia od umowy konsument jest zwolniony z wszelkich zobowiązań (art. 7 ust. 3 UPK).

32

Przepisy niniejszego działu stosuje się do sprzedaży konsumenckiej w takim zakresie, w jakim sprzedaż ta nie jest uregulowana odrębnymi przepisami.

PRAWO WOBEC E-COMMERCE

|

51

Ponadto nie powinno się określać w regulaminie jakichkolwiek kosztów manipulacyjnych. Zgodnie z decyzją Prezesa UOKiK-u33 rezygnacja z zakupionego w sklepie internetowym towaru w ustawowym terminie 10 dni nie upoważnia przedsiębiorcy [...] do pobierania jakichkolwiek opłat z tego tytułu ani też do zatrzymania sobie części należności uiszczonej przez konsumenta w wysokości odpowiadającej sumie kosztów wysyłki i innych, ustalonych przez siebie, opłat manipulacyjnych [...]. Nie jest to najlepsza wiadomość, bo wychodzi na to, że w przypadku odstąpienia konsumenta od umowy koszty wysyłki towaru ciążą na Tobie, a jeżeli konsument już je poniósł, należy mu je zwrócić. Na konsumencie ciążą jedynie koszty odesłania towaru do sklepu. W przypadku B2C, jeśli chodzi o zwrot towaru, zwracamy uwagę na art. 7 ust. 3 UPK dotyczący skutków odstąpienia od umowy, który stanowi, że: w razie odstąpienia od umowy umowa jest uważana za niezawartą, a konsument jest zwolniony z wszelkich zobowiązań. To co strony świadczyły, ulega zwrotowi w stanie niezmienionym, chyba że zmiana była konieczna w granicach zwykłego zarządu. Zwrot powinien nastąpić niezwłocznie, nie później niż w terminie czternastu dni. Jeżeli konsument dokonał jakichkolwiek przedpłat, należą się od nich odsetki ustawowe od daty dokonania przedpłaty. Poniżej przedstawiamy klauzule z rejestru UOKiK-u dotyczące powyższych kwestii.

33

Decyzja z dnia 17.06.2011 r. nr RWR 11/2011.

52

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

• Zwracany w tym trybie towar zostanie przyjęty tylko i wyłącznie wtedy, gdy będzie odesłany w oryginalnym, nieuszkodzonym opakowaniu34. • Nieodebranie przesyłki przez zamawiającego skutkuje rozwiązaniem umowy35. Wypowiedzenie umowy, której czas trwania nie jest oznaczony (określony), reguluje art. 8 ust. 3 UPK. Mówi on, że jeżeli czas trwania umowy nie jest oznaczony, każda ze stron może ją wypowiedzieć bez wskazania przyczyn z zachowaniem terminu miesięcznego, chyba że strony zastrzegły krótszy termin wypowiedzenia. Ochrona danych osobowych Naszym zdaniem regulamin nie jest najlepszym miejscem na zapisy dotyczące ochrony danych osobowych. Sądzimy, że powinien je zawierać odrębny dokument, tzw. polityka prywatności. W części regulaminu poświęconej danym osobowym powinny znaleźć się co najwyżej podstawowe informacje wynikające z art. 24 UODO i art. 20 UŚUDE, a w szczególności informacje dotyczące: • tego, kto jest tzw. administratorem danych osobowych (adres siedziby i pełna nazwa, a w przypadku gdy jest to osoba fizyczna — miejsce jej zamieszkania oraz imię i nazwisko); • celu zbierania danych; • prawa dostępu do treści swoich danych oraz ich poprawiania, a także dobrowolności albo obowiązku podania danych (w tym drugim przypadku należy również podać podstawę prawną tego obowiązku).

34

Nr wpisu: 2778, data wpisu: 03.01.2012 r.

35

Nr wpisu: 2535, data wpisu: 19.09.2011 r.

PRAWO WOBEC E-COMMERCE

|

53

Postanowienia końcowe. Ta część powinna wskazywać zasady dotyczące wprowadzania zmian w regulaminie, zasady rozstrzygania sporów, a także informować, jakie przepisy prawne obowiązują w zakresie nieobjętym regulaminem. Klient w przypadku nowych zapisów regulaminu powinien realizować swoje prawa w ramach tzw. praw nabytych, tj. według zasad obowiązujących w chwili zawarcia umowy, a jeśli ma być inaczej, powinien być poinformowany o nowych zasadach oraz prawie wypowiedzenia umowy. Przykładowo można określić, że zmiany w regulaminie wchodzą w życie z chwilą jego opublikowania na stronie internetowej sklepu, jednakże z zastrzeżeniem, że nie dotyczą zamówień złożonych przed datą ich ogłoszenia, lub z dodaniem, że nie dotyczą praw nabytych osób korzystających ze sklepu e-commerce. Przy określaniu terminu wypowiedzenia w przypadku obrotu B2C należy pamiętać o obostrzeniach prawnych wynikających z art. 8 ust. 3 UPK. Poniżej przedstawiamy wpisane do rejestru UOKiK-u niedozwolone klauzule dotyczące omawianych zagadnień. • Wszelkie zmiany wchodzą w życie z chwilą ich opublikowania (zamieszczenia) w sklepie internetowym, w związku z czym Klient jest zobowiązany do bieżącej weryfikacji jego postanowień36. • Zmienione zapisy Regulaminu są wiążące od momentu ich opublikowania w witrynie sklepu37. • Zastrzegamy sobie prawo do zmiany regulaminu38. • Wszelkie zmiany Regulaminu obowiązują od daty opublikowania ich na stronie39. 36

Nr wpisu: 2753, data wpisu: 28.12.2011 r.

37

Nr wpisu: 1783, data wpisu: 21.12.2009 r.

38 Nr 39

wpisu: 2758, data wpisu: 03.01.2012 r.

Nr wpisu: 2421, data wpisu: 05.07.2011 r.

54

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

W przypadku B2C klasycznym błędem powielanym w regulaminach jest zastrzeganie w nich, że spory będą rozpatrywane przez sąd właściwy dla siedziby przedsiębiorcy. Zamieszczamy poniżej przykłady takich klauzul wymienione w rejestrze UOKiK-u. • Sądem właściwym dla rozpatrywania sporów wynikłych z umowy sprzedaży jest Sąd właściwy dla siedziby Sklepu internetowego40. • W przypadku braku porozumienia, spory będą rozstrzygane przez Sąd właściwy dla siedziby usługodawcy41. Natomiast w przypadku wyłącznie B2B takie zastrzeżenia są zgodne z prawem — jak pamiętasz, klauzule niedozwolone dotyczą jedynie konsumentów. Gdy klientem może być zarówno konsument, jak i przedsiębiorca, można wpisać, że sądem właściwym do rozstrzygania wszelkich sporów jest sąd właściwy dla siedziby przedsiębiorcy (sklepu) z zastrzeżeniem, że nie dotyczy to sporów, w których stroną jest konsument, a następnie wskazać, jak w takiej sytuacji ustala się właściwy sąd. Rekomendujemy zapis mówiący, że w sprawach nieuregulowanych regulaminem mają zastosowanie przepisy Kodeksu cywilnego oraz innych ustaw. W tym miejscu można wskazać akty prawne takie jak UPK, UŚUDE czy UODO.

ŚWIADCZĄC USŁUGI DROGĄ ELEKTRONICZNĄ Najważniejszym aktem prawa dla prowadzącego e-commerce będzie UŚUDE. W myśl art. 2 pkt 6 jesteś usługodawcą, które to pojęcie oznacza osobę fizyczną, osobę prawną albo jednostkę organiza-

40 Nr 41

wpisu: 1879, data wpisu: 30.03.2010 r.

Nr wpisu: 590, data wpisu: 02.12.2005 r.

PRAWO WOBEC E-COMMERCE

|

55

cyjną nieposiadająca osobowości prawnej, która prowadząc, chociażby ubocznie, działalność zarobkową lub zawodową, świadczy usługi drogą elektroniczną. Określenie świadczenie usługi drogą elektroniczną zostało zdefiniowane w art. 2 pkt 4 UŚUDE i jest to: wykonanie usługi świadczonej bez jednoczesnej obecności stron (na odległość), poprzez przekaz danych na indywidualne żądanie usługobiorcy42, przesyłanej i otrzymywanej za pomocą urządzeń do elektronicznego przetwarzania, włącznie z kompresją cyfrową, i przechowywania danych, która jest w całości nadawana, odbierana lub transmitowana za pomocą sieci telekomunikacyjnej w rozumieniu ustawy z dnia 16 lipca 2004 r. — Prawo telekomunikacyjne. UŚUDE reguluje świadczenie usług we wszystkich modelach e-commerce, obejmując B2C, B2B, C2C i A2C. Tworząc aplikację e-commerce, należy uwzględnić zapisy z art. 7 UŚUDE: Usługodawca zapewnia działanie systemu teleinformatycznego, którym się posługuje umożliwiając nieodpłatnie usługobiorcy: 1. w razie, gdy wymaga tego właściwość usługi: a) korzystanie przez usługobiorcę z usługi świadczonej drogą elektroniczną, w sposób uniemożliwiający dostęp osób nieuprawnionych do treści przekazu składającego się na tę usługę, w szczególności przy wykorzystaniu technik kryptograficznych odpowiednich dla właściwości świadczonej usługi, b) jednoznaczną identyfikację stron usługi świadczonej drogą elektroniczną oraz potwierdzenie faktu złożenia oświadczeń 42

Według art. 2 pkt 7 UŚUDE usługobiorcą jest osoba fizyczna, osoba prawna albo jednostka organizacyjna nieposiadająca osobowości prawnej, która korzysta z usługi świadczonej drogą elektroniczną.

56

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

woli i ich treści, niezbędnych do zawarcia drogą elektroniczną umowy o świadczenie tej usługi, w szczególności przy wykorzystaniu bezpiecznego podpisu elektronicznego w rozumieniu ustawy z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U. Nr 130, poz. 1450), 2. zakończenie, w każdej chwili, korzystania z usługi świadczonej drogą elektroniczną. W tym miejscu zauważ, że prawo nakazuje stosować szyfrowanie (techniki kryptograficzne, np. SSL) oraz identyfikować obie strony usługi (Tobie nakazuje przedstawić się, a użytkownikowi — wylegitymować). Oto, jakie dodatkowe zapisy znajdziemy w tej samej ustawie: • Należy wskazać spośród danych, które ustawa pozwala przetwarzać usługodawcy (wskazanych w art. 18 i opisanych w kolejnej części książki), te, których podanie jest konieczne do świadczenia usługi drogą elektroniczną (art. 18 ust. 3). • Usługodawca nie może przetwarzać danych osobowych usługobiorcy po zakończeniu korzystania przez niego z usługi świadczonej drogą elektroniczną z zastrzeżeniem wyjątków podanych w ust. 2 art. 19 (np. niektóre dane można przetwarzać dłużej, gdy jest to niezbędne do rozliczenia usługi oraz dochodzenia roszczeń z tytułu płatności za korzystanie z niej). • Usługodawca (w przypadkach gdy usługa jest odpłatna) musi umożliwić usługobiorcy korzystanie z usługi lub uiszczanie opłat za nią w sposób anonimowy albo przy użyciu pseudonimu, o ile jest to technicznie możliwe (art. 22 ust. 2). • Należy uzyskać zgodę na przesyłanie informacji handlowej za pomocą środków komunikacji elektronicznej, w tym poczty elektronicznej.

PRAWO WOBEC E-COMMERCE

|

57

Usługodawca powinien umieć udokumentować uzyskanie zgody wymienionej w ostatnim punkcie np. do celów dowodowych. Wiadomo, że zgody takie nie będą zbierane na piśmie (z wyjątkiem sytuacji, gdy jest to wymagane przez prawo)43, więc aby miały one jakąś wartość i były wiarygodne, wraz z nimi należy w bazie danych odnotować datę i czas ich wyrażenia. Warto też zapisać informacje, które mogą być istotne, np. numer IP, szczegóły identyfikujące przeglądarkę internetową użytkownika (np. User-Agent) i inne dane, które mogą taką zgodę uwiarygodnić.

PRZETWARZANIE DANYCH OSOBOWYCH Prowadząc handel przez internet w modelach B2C i C2C, będziesz bez wątpienia przetwarzał dane osobowe osób fizycznych, a w związku z tym będziesz podlegał ustawie o ochronie danych osobowych (UODO). Będzie tak także w modelu B2B, o ile użytkownikami systemu będą osoby fizyczne prowadzące działalność gospodarczą44. W takiej sytuacji będziesz zobowiązany spełnić całe mnóstwo rozmaitych warunków. Jest to wcale niemała lista, której nie jesteśmy w stanie rozwinąć tutaj w pełni, dlatego zasygnalizujemy tylko niektóre zagadnienia. Zainteresowanych odsyłamy do książki jednego z autorów tej pozycji Leszka Kępy — Dane osobowe w firmie. Praktyczny poradnik przedsiębiorcy45. 43

Zgody na piśmie są niezbędne, gdy zbierane są dane określane mianem wrażliwych, sensytywnych. Kategorie danych wymienione są w ustawie o ochronie danych osobowych w art. 27.

44 Od

1 stycznia 2012 r. przepisy Ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych dotyczą informacji identyfikujących przedsiębiorców w obrocie gospodarczym — zob. informację zamieszczoną na stronie GIODO: http://www.giodo.gov.pl/560/id_art/4627/j/pl/.

45

Szerzej: L. Kępa, Dane osobowe w firmie. Praktyczny poradnik przedsiębiorcy, Difin, Warszawa 2012, s. 187 i nast.

58

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Przy przetwarzaniu danych osobowych w związku ze świadczeniem usług drogą elektroniczną pierwszeństwo będą miały przepisy UŚUDE, a tylko kwestie w niej nieuregulowane będą podlegały UODO (art. 16 ust. 1 UŚUDE). Szczególną uwagę należy zwrócić na zakres danych, które mogą być przetwarzane przez usługodawcę. Zgodnie z art. 18 ust 1 UŚUDE zalicza się do nich następujące informacje niezbędne do przeprowadzenia transakcji: 1. nazwisko i imiona usługobiorcy; 2. numer ewidencyjny PESEL lub — gdy ten nie został nadany — numer paszportu, dowodu osobistego lub innego dokumentu potwierdzającego tożsamość; 3. adres zameldowania na pobyt stały; 4. adres do korespondencji, jeżeli jest inny niż adres, o którym mowa w pkt 3; 5. dane służące do weryfikacji podpisu elektronicznego usługobiorcy; 6. adresy elektroniczne usługobiorcy. Możesz także przetwarzać: • inne dane niezbędne ze względu na właściwość świadczonej usługi lub sposób jej rozliczenia (art. 18 ust. 2 UŚUDE); • za zgodą usługobiorcy dane niezbędne dla celów reklamy, badania rynku oraz zachowań i preferencji usługobiorcy z przeznaczeniem wyników tych badań na potrzeby polepszenia jakości usług świadczonych przez usługodawcę (art. 18 ust. 4 w związku z art. 19 ust. 2 pkt 2 UŚUDE). Ustawa pozwala również przetwarzać tzw. dane eksploatacyjne, tj. takie, które charakteryzują sposób korzystania przez usługobiorcę z danej usługi (art. 18 ust. 5 UŚUDE). Ustawa zalicza do tych danych:

PRAWO WOBEC E-COMMERCE

|

59

• oznaczenie identyfikujące usługobiorcę (np. login); • oznaczenie identyfikujące zakończenie sieci telekomunikacyjnej lub system teleinformatyczny, z którego korzystał usługobiorca; • informację o rozpoczęciu, zakończeniu oraz zakresie każdorazowego korzystania z usługi świadczonej drogą elektroniczną; • informację o skorzystaniu przez usługobiorcę z usług świadczonych drogą elektroniczną. W istocie chodzi o „logowanie” aktywności użytkownika korzystającego z Twojego systemu, czyli zbieranie informacji o tym, kto, skąd, kiedy i z czego korzystał. Dalsze zapisy ustawy odnoszą się m.in. do reguł określających, do kiedy usługodawca może przetwarzać zebrane dane (art. 19 UŚUDE) i kiedy może odmówić świadczenia usługi (art. 22 UŚUDE). Usługodawca może w przypadku korzystania z usługi przez usługobiorcę w sposób niedozwolony (czyli niezgodny z regulaminem lub z obowiązującymi przepisami) przetwarzać jego dane osobowe w zakresie niezbędnym do ustalenia odpowiedzialności osoby za takie działania, pod warunkiem że utrwali dla celów dowodowych (czyli dla sądu) fakt uzyskania oraz treść wiadomości o niedozwolonym korzystaniu z usługi (art. 21 ust. 1 UŚUDE)46. Należy podkreślić, że w przypadku przetwarzania danych osobowych w systemie e-commerce UODO i rozporządzenie do niej definiują wiele obowiązków związanych z zabezpieczeniem tych danych takich jak:

46 Zasada

ta jest powiązana z regułami dotyczącymi wyłączenia odpowiedzialności usługodawcy z tytułu świadczenia usług drogą elektroniczną (rozdział 3. UŚUDE), przykładowo w sytuacji świadczenia usługi hostingu, gdy usługobiorca przechowuje dane o charakterze bezprawnym (art. 14 UŚUDE).

60

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

• zmiana hasła co 30 dni (dotyczy to operatorów systemu, a więc Twoich pracowników, a nie klientów), odpowiednie reguły hasła (np. 8 znaków, wielkie i małe litery, cyfry etc.); • stosowanie szyfrowania, jeśli dane osobowe są przesyłane przez internet, a także wtedy, gdy drogą tą przesyłane są dane do uwierzytelniania takie jak login i hasło; • stosowanie firewalla, programów antywirusowych; • wykonywanie zapasowych kopii danych. Projektując każdy system e-commerce, należy wziąć pod uwagę zapisy wspomnianych regulacji.

ZAWARCIE UMOWY MIĘDZY STRONAMI Prawo nie definiuje umowy zawieranej „przez internet”. W. Kilian wskazuje, że umowy elektroniczne są porozumieniami pomiędzy osobami fizycznymi lub prawnymi komunikującymi się ze sobą za pomocą środków technicznych (przez cyfrowe sieci komunikacyjne) w celu przeprowadzenia transakcji dotyczących dóbr niematerialnych (tzw. wykonywane online lub bezpośredni handel elektroniczny) lub stworzenia na drodze elektronicznej podstaw do wydania dóbr materialnych (tzw. wykonanie offline lub pośredni handel elektroniczny)47. P. Podrecki uznaje natomiast, że przez umowy zawierane w internecie można rozumieć ogół stosunków prawnych, których istotnym elementem jest wykorzystanie przez strony sieci Internet jako środka komunikowania i przekazywania oświadczeń w celu zawarcia umowy48. Zwykliśmy uważać, że zawarcie umowy wymaga papieru i składania podpisów,

47

W. Kilian, Umowy elektroniczne, w: Prawne i ekonomiczne aspekty komunikacji elektronicznej, red. J. Gołaczyński, Warszawa 2003.

48 P.

Podrecki w: Prawo Internetu, wydanie 2, Warszawa 2006, s. 45.

PRAWO WOBEC E-COMMERCE

|

61

wcale jednak tak być nie musi. Aby pokazać, czym jest umowa w przypadku e-commerce, zdefiniujemy pojęcie oferty tak, jak rozumiane jest ono w prawie. Art. 66 § 1 Kodeksu cywilnego określa, że oświadczenie drugiej stronie woli zawarcia umowy stanowi ofertę, jeżeli określa istotne postanowienia tej umowy. Oferta jest więc po prostu propozycją zawarcia umowy: widzę dany towar, podoba mi się, cena jest OK — kupuję. Poza tym może mieć tu zastosowanie art. 543 tegoż kodeksu, według którego już samo wystawienie rzeczy w miejscu sprzedaży na widok publiczny z oznaczeniem ceny uważa się za ofertę sprzedaży49. Gdy sprzedający też powie „OK”, dochodzi do zawarcia umowy, czyli do tzw. przyjęcia oferty. Oferta wiąże sprzedającego z chwilą złożenia zamówienia, czyli de facto powiedzenia „Kupuję!” przez nabywcę.

Tryb zawarcia umowy Kupowanie w sklepie tradycyjnym — wzięcie towaru z półki i zapłacenie za niego — stanowi zawarcie umowy. I podobnie jest w internecie, z tym że w literaturze prawniczej podzielone są opinie na temat tego, czy sklep, który sprzedaje przez internet, składa ofertę (art. 66 k.c.), czy też zaprasza do składania ofert (art. 71 k.c.). Różnica jest taka jak między produktami z cenami na półce sklepowej a ulotką reklamową. W pierwszym przypadku klient bierze towar i płaci za niego (przyjmuje ofertę), w drugim zaś klienta się zachęca do złożenia oferty: „Wybierz coś z ulotki i zadeklaruj, że to kupisz. Jeśli to mam (i zechcę), to ci to sprzedam”. Porównując skutki prawne tych sytuacji, w uproszczeniu można stwierdzić, że w przypadku przyjęcia pierwszego trybu zawarcia 49 Z

tego powodu, jeśli sprzedający w sklepie (jakimkolwiek) pomylił się i wystawił towar na półce z niższą ceną, to musi Ci go sprzedać w takiej właśnie cenie.

62

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

umowy prowadzą one do uznania, że sprzedawca z chwilą złożenia zamówienia przez klienta jest nim związany, natomiast przy przyjęciu za właściwy drugiego trybu uznajemy, że do zawarcia umowy dochodzi dopiero w momencie potwierdzenia przyjęcia przez sprzedawcę złożonego zamówienia. Zdaniem P. Podreckiego w praktyce zawierania transakcji w internecie największe znaczenie będzie miał ofertowy tryb zawarcia umowy50. W literaturze prezentowany jest także przeciwny pogląd, że prezentowanie towarów czy usług na stronach internetowych, nawet gdy podawane są istotne dla umowy dane (np. cena), nie ma charakteru oferty, lecz jest zaproszeniem do składania ofert. Przyjmowanie, że „zamawianie” w sklepie internetowym ma charakter zaproszenia do składania ofert, jest na rękę sklepom internetowym, gdyż w razie braku towaru wystarczy napisać do zamawiającego e-mail z informacją, że takiego towaru nie ma i że zamówienie nie zostało przyjęte. W przypadku pierwszego trybu zamówienie należałoby zrealizować zawsze niezależnie od tego, czy towar jest, czy go akurat nie ma. Oferta elektroniczna uważana jest za tzw. kwalifikowaną postać oferty51. Art. 661 k.c. definiuje ją następująco: § 1. Oferta złożona w postaci elektronicznej wiąże składającego, jeżeli druga strona niezwłocznie potwierdzi jej otrzymanie. § 2. Przedsiębiorca składający ofertę w postaci elektronicznej jest obowiązany przed zawarciem umowy poinformować drugą stronę w sposób jednoznaczny i zrozumiały o: 1) czynnościach technicznych składających się na procedurę zawarcia umowy;

50

P. Podrecki, op. cit., s. 26.

51

P. Podrecki, op. cit., s. 35.

PRAWO WOBEC E-COMMERCE

|

63

2) skutkach prawnych potwierdzenia przez drugą stronę otrzymania oferty; 3) zasadach i sposobach utrwalania, zabezpieczania i udostępniania przez przedsiębiorcę drugiej stronie treści zawieranej umowy; 4) metodach i środkach technicznych służących wykrywaniu i korygowaniu błędów we wprowadzanych danych, które jest obowiązany udostępnić drugiej stronie; 5) językach, w których umowa może być zawarta; 6) kodeksach etycznych, które stosuje, oraz o ich dostępności w postaci elektronicznej. § 3. Przepis § 2 stosuje się odpowiednio, jeżeli przedsiębiorca zaprasza drugą stronę do rozpoczęcia negocjacji, składania ofert albo do zawarcia umowy w inny sposób. § 4. Przepisy § 1 – 3 nie mają zastosowania do zawierania umów za pomocą poczty elektronicznej albo podobnych środków indywidualnego porozumiewania się na odległość. Nie stosuje się ich także w stosunkach między przedsiębiorcami, jeżeli strony tak postanowiły. Oferta składana elektronicznie obejmuje towary wyświetlane (prezentowane, oferowane) w witrynie internetowej sklepu. Przy uznaniu, że e-commerce to składanie ofert (a nie zaproszenie do ich składania), samo włożenie towaru do koszyka i jego zatwierdzenie należałoby traktować jako zawarcie umowy, bo jest to już jakaś forma potwierdzenia otrzymania oferty. Możliwe są również w internecie negocjacje (art. 72 k.c.), aukcje lub przetargi (art. 701 i nast. k.c.) stanowiące obszary, w których można stosować system e-commerce.

64

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Chwila i miejsce zawarcia umowy Art. 70 § 1 Kodeksu cywilnego podkreśla, że w razie wątpliwości umowę sprzedaży uznaje się za zawartą w chwili otrzymania przez sprzedającego zamówienia od klienta. Przepis art. 70 § 2 k.c. regulujący miejsce zawarcia umowy prowadzi do wniosku, że w przypadku e-commerce (przy założeniu, że oferta wynika wprost ze strony internetowej) będzie to miejsce zamieszkania lub siedziby sprzedawcy w chwili zawarcia umowy. Nie ma przy tym znaczenia, gdzie są zlokalizowane serwery, z których korzysta sprzedawca. Przy stosowaniu umów w obrocie B2C należy mieć na uwadze w szczególności przepisy k.c., UPK, UŚUDE i UODO. Wśród istotnych postanowień UPK można wskazać m.in.: • prawo odstąpienia przez konsumenta od umowy w terminie 10 dni od dnia wydania rzeczy, a gdy umowa dotyczy świadczenia usługi — od dnia jej zawarcia; • w przypadku powyższej sytuacji obowiązek zwrotu zakupionej rzeczy w terminie nie dłuższym niż 14 dni (art. 7 w związku z art. 10); • w przypadku umowy ciągłej lub okresowej zawartej na okres dłuższy niż rok po upływie tego terminu uważa się ją za zawartą na czas nieoznaczony (art. 8); • umowa nie może nakładać obowiązku zapłaty ceny lub wynagrodzenia przed otrzymaniem świadczenia (art. 11); • określenie 30-dniowego terminu wykonania umowy po złożeniu oświadczenia woli o jej zawarciu przez konsumenta, o ile strony nie umówiły się inaczej; należy przy tym pamiętać, że zakres zastosowania powyższych przepisów nie obejmuje sprzedaży z licytacji (art. 12).

PRAWO WOBEC E-COMMERCE

|

65

W obrocie B2B należy mieć na uwadze przepisy k.c., UŚUDE, UODO (w przypadku osób fizycznych prowadzących działalność gospodarczą)52 oraz UDW. W przypadku ofertowego trybu zawarcia umowy na szczególna uwagę zasługują następujące przepisy k.c.: • art. 661 (związanie ofertą elektroniczną); • art. 662 (odwołanie oferty); • art. 68 (zastrzeżenie zmiany lub uzupełnienia oferty); • art. 681 (przyjęcie oferty z zastrzeżeniami); • art. 682 (dorozumiane przyjęcie oferty); • art. 772 (związanie pismem potwierdzającym); • art. 3855 (konflikt formularzy).

O CZYM NALEŻY INFORMOWAĆ W przepisach prawnych funkcjonuje szereg tzw. obowiązków informacyjnych, do których powinien się stosować każdy przedsiębiorca. Poniżej przedstawimy obowiązki, jakie mają podmioty prowadzące biznes przez internet. W przypadku wymogów wynikających z UŚUDE (wobec usługobiorców) należy je spełniać równocześnie z obowiązkami wobec konsumentów przewidzianymi w UPK.

Ustawa o świadczeniu usług drogą elektroniczną W art. 5 UŚUDE zostały wskazane informacje, jakie powinien podać usługodawca prowadzący e-commerce. Są to m.in.:

52

Zob. wyrok NSA z dnia 15 marca 2010 r. I OSK 756/09; link do informacji na stronie GIODO: http://www.giodo.gov.pl/560/id_art/4474/j/pl.

66

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

• adresy elektroniczne53 (poczty elektronicznej i witryny); • imię i nazwisko, miejsce zamieszkania, adres (albo nazwa firmy oraz siedziba i adres); • informacja o zezwoleniu i organie zezwalającym, jeżeli świadczenie usługi wymaga właściwego zezwolenia. Ponadto art. 5 § 4 UŚUDE odsyła do spełnienia obowiązku wynikającego z art. 21 pkt 2 Ustawy z dnia 2 lipca 2002 r. o swobodzie działalności gospodarczej, zgodnie z którym przedsiębiorca oferujący towary lub usługi w sprzedaży bezpośredniej lub na odległość za pośrednictwem środków masowego przekazu, sieci teleinformatycznej lub druków bezadresowych, jest obowiązany do podania w ofercie również numeru NIP (o ile taki posiada). W myśl art. 5 ust. 5 UŚUDE, jeżeli usługodawcą jest osoba fizyczna, której prawo do wykonywania zawodu jest uzależnione od spełnienia określonych w odrębnych ustawach wymagań54, dochodzą jeszcze do przekazania informacje m.in. o tytule zawodowym, numerze w rejestrze publicznym, zasadach etyki zawodowej i tym podobne. Katalog informacji z art. 5 UŚUDE ma charakter minimalistyczny, a ich niepodanie stanowi wykroczenie (art. 23 UŚUDE).

Zapewnienie dostępu do aktualnej informacji Ustawodawca w art. 6 UŚUDE określił obowiązki zapewnienia usługobiorcy dostępu do aktualnej informacji o szczególnych zagrożeniach związanych z korzystaniem z usługi świadczonej drogą 53

Art. 2 ust 1 UŚUDE wyjaśnia pojęcie „adres elektroniczny” jako oznaczenie systemu teleinformatycznego umożliwiające porozumiewanie się za pomocą środków komunikacji elektronicznej, w szczególności poczty elektronicznej. W praktyce będzie to adres e-mail lub adres strony internetowej.

54

Przepis dotyczy m.in. adwokatów, radców prawnych, architektów, doradców podatkowych czy lekarzy.

PRAWO WOBEC E-COMMERCE

|

67

elektroniczną oraz o funkcji i celu oprogramowania lub danych niebędących składnikiem treści usługi, wprowadzonych przez usługodawcę do systemu teleinformatycznego, którym posługuje się usługobiorca. Informacje o zagrożeniach to w gruncie rzeczy porady dla klienta z zakresu bezpieczeństwa. „Treści” wprowadzane do systemu klienta to w przypadku e-commerce głównie cookies. W literaturze pojawia się pogląd, że do spełnienia powyższych obowiązków wystarczy zapewnienie dostępu do wymienionych informacji na żądanie usługobiorcy55 — usługodawca może poprzestać na zapewnieniu usługobiorcy możliwości zapoznania się z nimi przykładowo w witrynie serwisu56. Zgodnie z art. 20 ust. 1 UŚUDE, gdy usługodawca przetwarza dane osobowe usługobiorcy, powinien zapewnić mu dostęp do aktualnej informacji o: • możliwości korzystania z usługi świadczonej drogą elektroniczną anonimowo lub z wykorzystaniem pseudonimu; • środkach technicznych zapobiegających pozyskiwaniu i modyfikowaniu danych osobowych przesyłanych drogą elektroniczną przez osoby nieuprawnione (czyli po prostu informacji o tym, jak zabezpieczona jest transmisja danych); • podmiocie, któremu powierza przetwarzanie danych57, ich zakresie i zamierzonym terminie ich przekazania, jeżeli usługodawca

55

Por. J. Gołaczyński, Ustawa o świadczeniu usług drogą elektroniczną. Komentarz, Warszawa 2009, s. 82.

56

Por. X. Konarski, Komentarz do ustawy o świadczeniu usług drogą elektroniczną, Warszawa 2004, s. 96.

57

Punkt ten w części dotyczącej wskazania powołanego podmiotu (a często i podmiotów) może zostać spełniony przez wskazanie w regulaminie zbioru danych osobowych zarejestrowanego u Generalnego Inspektora

68

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

zawarł z tym podmiotem umowę o powierzenie do przetwarzania danych, o których mowa w art. 18 ust. 1, 2, 4 i 5 — czyli (upraszczając) danych o podmiotach, z którymi współpracuje. Jeśli posiadacz sklepu zarejestrował zbiór danych osobowych, a w większości przypadków B2C powinien to zrobić, to informacje o podmiotach, którym powierzono przetwarzanie tych danych, znajdą się w publicznym rejestrze zbiorów, który może każdy przeglądać58. Naszym zdaniem wystarczy wtedy w regulaminie podać „parametry” zgłoszonego zbioru takie jak jego nazwa i numer księgi, zamiast informować o podmiotach, z którymi się współpracuje.

Prawa konsumentów W obrocie detalicznym, zawierając umowy z konsumentami, należy przekazywać informacje wynikające z art. 9 ust. 1 UPK, m.in. takie jak: • dane rejestracyjne firmy, czyli imię i nazwisko (nazwę), adres zamieszkania (siedzibę) przedsiębiorcy oraz organ, który zarejestrował działalność gospodarczą przedsiębiorcy, i numer, pod którym została ona zarejestrowana; • istotne właściwości świadczenia i jego przedmiotu; • cena lub wynagrodzenie ze wskazaniem wszystkich ich składników; • zasady zapłaty ceny lub wynagrodzenia; • koszty oraz termin i sposób dostawy;

Ochrony Danych Osobowych. UODO wskazuje, kiedy taki obowiązek rejestracyjny powstaje. Oto link do wykazu zbiorów danych prowadzonych przez GIODO: http://egiodo.giodo.gov.pl/index.dhtml. 58

http://egiodo.giodo.gov.pl/index.dhtml

PRAWO WOBEC E-COMMERCE

|

69

• informacja o prawie odstąpienia od umowy w terminie dziesięciu dni ze wskazaniem wyjątków, o których mowa w art. 10 ust. 3 (np. gdy zamówienie było „na miarę”); • minimalny okres, na jaki ma zostać zawarta umowa o świadczenia (ciągłe lub okresowe)59; • miejsce i sposób składania reklamacji; • informacja o prawie wypowiedzenia umowy, której czas nie jest oznaczony (jest nieokreślony), udzielona poprzez wskazanie, iż w takiej sytuacji każda ze stron może tę umowę wypowiedzieć bez podania przyczyn z zachowaniem terminu miesięcznego, chyba że strony zastrzegły krótszy termin wypowiedzenia. Informacje te powinny być sformułowane w sposób zrozumiały i łatwy do odczytania. Najlepszym rozwiązaniem wydaje się przekazanie ich (wszystkich lub części) poprzez umieszczenie ich w regulaminie. Prawidłowe przekazanie powyższych informacji jest bardzo istotne ze względu na fakt, iż w przypadku ich braku termin 10 dni, w ciągu których konsument może odstąpić od umowy, zmienia się w 3 miesiące liczone od tzw. wydania rzeczy (w przypadku e-commerce wydaniem jest dostarczenie, czyli moment otrzymania towaru), a gdy umowa dotyczy świadczenia usługi — od dnia jej zawarcia. Jeżeli jednak po rozpoczęciu biegu tego terminu (tj. po wydaniu rzeczy albo zawarciu umowy) konsument otrzyma informacje wymienione w art. 9 ust. 1, termin ten ulega skróceniu do 10 dni liczonych od daty tego powiadomienia (art. 10 ust. 2 UŚUDE). 59

Świadczenie ciągłe ma miejsce w sytuacji, w której dłużnik jest zobowiązany do określonego zachowania przez określony czas, a ponadto nie może spełnić tego świadczenia jednorazowo. Świadczenie okresowe występuje wówczas, gdy dłużnik ma spełniać w ramach pojedynczego stosunku prawnego wiele świadczeń jednorazowych.

70

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Kodeks cywilny Zgodnie z art. 661 § 2 k.c. w sytuacji, gdy przedsiębiorca składa ofertę w postaci elektronicznej, czyli wystawia towary w witrynie e-commerce do sprzedaży, jest on zobowiązany przed zawarciem umowy poinformować drugą stronę w sposób jednoznaczny i zrozumiały o: 1. czynnościach technicznych składających się na procedurę zawarcia umowy; 2. skutkach prawnych potwierdzenia przez drugą stronę otrzymania oferty; 3. zasadach i sposobach utrwalania, zabezpieczania i udostępniania przez przedsiębiorcę drugiej stronie treści zawieranej umowy; 4. metodach i środkach technicznych służących wykrywaniu i korygowaniu błędów we wprowadzanych danych, które jest obowiązany udostępnić drugiej stronie; 5. językach, w których umowa może być zawarta; 6. kodeksach etycznych, które stosuje, oraz ich dostępności w postaci elektronicznej. Wymóg przekazania powyższych informacji zgodnie z § 3 tego artykułu stosuje się także, jeżeli przedsiębiorca zaprasza drugą stronę do składania ofert, rozpoczęcia negocjacji albo do zawarcia umowy w inny sposób. Podstawowe znaczenie dla zachowania tych wymagań mają przepisy UŚUDE60, przy czym warto zauważyć, że zakres obowiązków informacyjnych wynikających z tego artykułu jest szerszy niż ten z art. 9 UPK.

60 K.

Piasecki w: Kodeks cywilny. Księga pierwsza. Część ogólna. Komentarz, Kraków 2003, s. 20.

PRAWO WOBEC E-COMMERCE

|

71

Ustawa o ochronie danych osobowych Zbierając dane osobowe od osób fizycznych, należy spełnić tzw. obowiązek informacyjny. Wynika to z art. 24 ust. 1 UODO: W przypadku zbierania danych osobowych od osoby, której one dotyczą, administrator danych jest obowiązany poinformować tę osobę o: 1. adresie swojej siedziby i pełnej nazwie, a w przypadku gdy administratorem danych jest osoba fizyczna — o miejscu swojego zamieszkania oraz imieniu i nazwisku; 2. celu zbierania danych, a w szczególności o znanych mu w czasie udzielania informacji lub przewidywanych odbiorcach lub kategoriach odbiorców danych; 3. prawie dostępu do treści swoich danych oraz ich poprawiania; 4. dobrowolności albo obowiązku podania danych, a jeżeli taki obowiązek istnieje, o jego podstawie prawnej. Obowiązek informacyjny często spełnia się w ramach uzyskiwania zgody na przetwarzanie danych osobowych. Przykładowo wydawnictwo Helion robi to następująco (rysunek 1.1):

Rysunek 1.1. Zgoda na przetwarzanie danych i spełnienie obowiązku informacyjnego wynikającego z UODO w witrynie helion.pl

72

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Nieudzielenie powyższych informacji jest karane z art. 54 UODO, który określa, że kto administrując zbiorem danych, nie dopełnia obowiązku poinformowania osoby, której dane dotyczą, o jej prawach lub przekazania tej osobie informacji umożliwiających korzystanie z praw przyznanych jej w niniejszej ustawie, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do roku. Natomiast przekazanie fałszywych informacji np. co do celu gromadzenia danych lub danych administratora może być karane z art. 271 Kodeksu karnego (poświadczenie nieprawdy).

KODEKS SPÓŁEK HANDLOWYCH Warto jeszcze wspomnieć, że w przypadku spółki komandytowoakcyjnej, spółki z ograniczoną odpowiedzialnością i spółki akcyjnej ustawa z dnia 15 września 2000 r. — Kodeks spółek handlowych nakazuje, aby w ich pismach i składanych (także w formie elektronicznej) zamówieniach handlowych oraz w informacjach zamieszczonych na ich stronie internetowej znalazły się m.in. takie dane jak nazwa spółki61, jej siedziba i adres, oznaczenie sądu rejestrowego i numeru, pod którym spółka wpisana jest do rejestru (KRS), czy numer identyfikacji podatkowej (NIP)62.

PRAWO WOBEC CYBERPRZESTĘPCÓW Temat ten jest tak obszerny, że jedynie zasygnalizujemy tę problematykę, wyróżniając jeden przepis z Kodeksu karnego, w którym cały rozdział XXXIII jest poświęcony przestępstwom przeciwko ochronie informacji. Przepisów takich jest więcej, ale to temat na odrębną analizę. 61

W przypadku osób prawnych nazwa spółki w prawie określana jest jako „firma”, zatem jeśli napisano, że należy podać „firmę spółki”, to chodzi o jej nazwę.

62 Art.

127, 206, 374 k.s.h.

PRAWO WOBEC E-COMMERCE

|

73

Warto w tym miejscu podkreślić, że ustawa o ochronie danych osobowych także penalizuje63 kradzież danych, a właściwie ich nielegalne przetwarzanie, np. w sytuacji, gdy haker te dane wykradnie i będzie przechowywał na swoim komputerze. Jej art. 49 podkreśla, że kto przetwarza dane osobowe, a nie jest to tego uprawniony (a cyberprzestępca przecież nie jest), podlega nawet karze pozbawienia wolności do lat 364. Natomiast art. 267 § 1 Kodeksu karnego przewiduje kary już za sam dostęp do informacji, nawet jeśli nie zostanie ona użyta: Kto bez uprawnienia uzyskuje dostęp do informacji dla niego nieprzeznaczonej, otwierając zamknięte pismo, podłączając się do sieci telekomunikacyjnej lub przełamując albo omijając elektroniczne, magnetyczne, informatyczne lub inne szczególne jej zabezpieczenie, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do lat 2. Jest to przestępstwo tzw. hackingu. Zauważ, że chodzi o informacje, a nie o dane. Zapisy w tabeli bazy danych składają się z danych, ale stają się informacjami dopiero po uzyskaniu „kontekstu”. Przykładowo ciąg 11 cyfr jest danymi, ale uzyska status informacji, jeśli dopowiemy, że jest to numer PESEL. Informacje różnią się od danych tym, że niosą ze sobą jakiś komunikat, przekaz. Zatem przepis ten można by interpretować tak, że dopóki haker zebranych danych nie otworzy i nie zobaczy (tj. nie zapozna się z ich treścią), trudno mówić o uzyskaniu dostępu do informacji. Samo ściągnięcie pliku /etc/passwd nie powinno stanowić przestępstwa z tego artykułu, lecz jego otworzenie i analiza tak, bo następuje wtedy

63 Penalizować 64 O

— karać.

ile dane osobowe stanowią tzw. dane wrażliwe; w przeciwnym wypadku do lat 2.

74

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

dostęp do informacji. Nie ma tutaj znaczenia to, czy haker informację tę w jakikolwiek sposób wykorzysta, zniszczy, usunie, czy też ujawni innym osobom. W świecie rzeczywistym w przypadku kopiowania zapisu informacji przez ręczne przepisanie pisma sprawca (czy chce, czy nie chce) zapoznaje się z treścią, co w przypadku kopiowania danych cyfrowych nie zachodzi. Niemniej jednak jest to ważny przepis, który chroni Twój system e-commerce przed każdym włamywaczem niezależnie od tego, czy jest on hakerem, czy crackerem, o ile tylko przełamał zabezpieczenia. Niekiedy twierdzi się, że niektóre z ataków SQL injection nie stanowią przełamania zabezpieczeń — przykładowo gdy te ciągi wpisywane są w polu przeznaczonym na hasło. Wszak każdy jako hasło może wpisać dowolny ciąg znaków. Ale to nie ma znaczenia — nawet gdy nie ma żadnych zabezpieczeń, to § 2 wspomnianego wcześniej przepisu penalizuje już samo podłączenie się do systemu informatycznego bez uprawnienia: Tej samej karze podlega, kto bez uprawnienia uzyskuje dostęp do całości lub części systemu informatycznego. Zatem czy jest to SQL injection, czy inna forma ataku, czy haker zapozna się z informacją, czy nie — i tak może on ponieść odpowiedzialność karną. Stosowanie narzędzi takich jak Wireshark czy sqlmap też może być karane, o ile służyło do włamania (ataku). Wyliczenie sposobów przechwycenia informacji, do której znajomości sprawca nie jest upoważniony, nie ma charakteru numerus clausus (listy zamkniętej), bo w § 3 użyto zwrotu „inne urządzenia specjalne”. Tej samej karze podlega, kto w celu uzyskania informacji, do której nie jest uprawniony, zakłada lub posługuje się urządzeniem podsłuchowym, wizualnym albo innym urządzeniem lub oprogramowaniem.

PRAWO WOBEC E-COMMERCE

|

75

Przepisem tym karane jest już samo wywołanie stanu niebezpieczeństwa ujawnienia informacji powstałego poprzez założenie lub posługiwanie się wymienionym urządzeniem, czyli samo zagrożenie naruszenia cudzej tajemnicy. W tym przypadku mamy do czynienia z pojęciem tzw. sniffingu (podsłuchu). Ważną informacją jest ta, że ściganie przestępstw wymienionych w Kodeksie karnym następuje na wniosek pokrzywdzonego, czyli (ewentualnie) Twój. Tak więc, jak widzisz, prawo nie tylko od Ciebie wymaga, ale daje Ci też całkiem sporą ochronę.

76

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Rozdział 2.

BEZPIECZEŃSTWO OGÓLNE

Wspomnieliśmy już wcześniej, że zagadnienie bezpieczeństwa systemu e-commerce jest złożone. Składa się na nie: • bezpieczeństwo fizyczne serwerów, na których znajduje się aplikacja, serwer WWW, baza danych itd.; • zabezpieczenie systemów operacyjnych, w których są zainstalowane aplikacja, serwer WWW i baza danych; • takie bezpieczeństwo transmisji, aby danych w trakcie przesyłania nikt nie podsłuchał ani nie zmienił; • bezpieczeństwo serwera DNS i domeny — to, żeby nikt nie ukradł „nazwy internetowej” serwisu ani nie przekierował ruchu do innego, podrobionego systemu; • bezpieczeństwo aplikacji, a więc takie jej utworzenie, aby nie można było nią manipulować; • ciągłość działania, tj. takie zorganizowanie systemu i uzyskanie takiej jego odporności, aby nawet mimo ataku mógł on dalej funkcjonować lub wznowić aktywność; • bezpieczeństwo organizacyjne, czyli procesy związane z administrowaniem aplikacją, zarządzanie zmianami i wszystko to, co jest dookoła systemu, a ma na niego (znaczący) wpływ; • bezpieczeństwo prawne, a więc zarządzanie stanem zgodności z prawem.

78

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Tutaj chcemy przedstawić najogólniejsze zagadnienia związane z bezpieczeństwem systemu e-commerce.

INFORMACJE O SYSTEMIE Zapewne nieraz się zastanawiałeś, jak to się dzieje, że haker w końcu „dopada” określoną witrynę. Mogą być tego dwa główne powody. Pierwszy może być taki, że witryna jest słabo zabezpieczona i stanowi dla hakera łatwy łup — będzie on mógł jej zhakowanie wpisać do ewidencji swoich sukcesów. Drugi to celowy atak na właśnie ten, a nie inny serwis. Na pewno jednak nieodłącznym elementem każdego ataku jest rekonesans, czyli rozpoznanie. Odbywa się to zupełnie tak jak w „realu” — zanim złodziej przystąpi do działania, obserwuje i zbiera informacje. Każda informacja może być dla hakera przydatna, a szczególnie o: • systemie operacyjnym (rodzaj, wersja, uruchomione programy i usługi); • bazie danych (rodzaj i wersja); • kodzie aplikacji; • chronionych częściach aplikacji; • konfiguracji i zabezpieczeniach systemu. Znajomość wersji oprogramowania pozwala hakerowi znaleźć luki w zabezpieczeniach — przy odrobinie szczęścia może on trafić na wersję, w której nie zostały one załatane. Do wyszukania luk zabezpieczeń w określonej wersji oprogramowania haker może użyć np. bazy CVE1. Ty z niej korzystasz, aby wiedzieć, co jest dziurawe, i żeby to zaktualizować, a cyberprzestępcy używają jej, aby mieć informacje o tym, jakie systemy (i jakie ich wersje) „chorują”, są podatne na atak. 1

https://cve.mitre.org/

BEZPIECZEŃSTWO OGÓLNE

|

79

Wiedza o rodzaju bazy danych pozwala z kolei dostosować ataki polegające na wstrzykiwaniu kodu SQL — już sama ta informacja jest istotna, bo niektóre ataki są specyficzne dla rodzaju bazy danych, np. działają w przypadku PostgreSQL, ale nie z MySQL. Nawet rodzaj języka, w którym napisano aplikację, ma znaczenie. Sprawdźmy, jak może wyglądać atak cyberprzestępcy, który dla zabawy chce spróbować swoich sił w hackingu. Pierwsze, co może on zrobić, to wpisanie w wyszukiwarce ciągu sql dorks. Oto przykładowe ciągi tego typu: allinurl:showimg.php?id= allinurl:view.php?id= allinurl:website.php?id= allinurl:hosting_info.php?id= allinurl:gallery.php?id=

Haker kopiuje i wkleja jeden z nich do wyszukiwarki, a następnie otwiera strony będące wynikami wyszukiwania i przeprowadza rekonesans. Najłatwiej jest zacząć od sprawdzenia, czy dany ciąg (określany mianem SQL dorka) zadziała. Przykładowo http://www. witryna.com/gallery.php?id=1 zawiera SQL dork gallery.php?id=. Wystarczy w pasku adresowym na końcu dodać znak apostrofu i w wyniku otrzymujemy: Fatal error: Uncaught exception 'Exception' with message 'SQL Query failed: SELECT image,title,location,description,height,width from tblSCAImages WHERE id=83\\\'You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\\\'' at line 1' in /home/sca/wwwlib/gallery_lib.php:16 Stack trace: #0 /home/sca/www/gallery.php(21): sca_gallery_get_image_meta('83\'') #1 {main} thrown in /home/sca/wwwlib/gallery_lib.php on line 16

Mamy tu informacje o błędach i już coś wiemy o witrynie — wiemy, że jest to MySQL, a także o nazwach tabel i ich kolumn, o funkcjach PHP, a nawet o systemie plików. To się przyda. Sprawdźmy, jak witryna internetowa zareaguje na wpisanie błędnego

80

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

adresu strony http://www.witryna.com/coscokolwiek. Tu też otrzymujemy komunikat: Not Found The requested URL /coscokolwiek was not found on this server. Apache/2.2.3 (CentOS) Server at www.allspeedperformance.com Port 80

Znamy już wersję serwera Apache. Zobaczmy jeszcze, jakie części witryny są chronione. Wpiszmy http://www.witryna.com/ robots.txt. Otrzymamy: User-agent: * Disallow: /checkout/

To tylko przykład tego, jak można zacząć. Dalej można „grzebać” w cookies, użyć programu sqlmap, ręcznie wstrzykiwać kod… Możliwości jest wiele. To pokazuje, że ujawnianie zbyt wielu informacji może działać na szkodę systemu, bo pozwala przeprowadzić rekonesans. Dla hakera może być przydatna w zasadzie każda informacja, zadbaj więc o to, aby nie wypuszczać na zewnątrz komunikatów o błędach wraz z ich detalami oraz informacjami o wersji oprogramowania. Pozwala to hakerowi odnaleźć słabe punkty danej wersji.

Jak wprowadzić hakera w błąd Uważamy, że skoro podstawą ataków jest rekonesans, to może warto atakującego wyprowadzić w pole. Gdy widać wyraźnie, że coś jest porządnie chronione, to pewnie jest warte tego, aby to ukraść. Można to wykorzystać do stworzenia pułapki na cyberprzestępcę. Będzie on długo łamał zabezpieczenia, aby w efekcie uzyskać dostęp do nic nie wartych informacji lub uruchomić alarm informujący, że dzieje się coś złego. Takie rozwiązanie nazywa się z angielskiego honeypot. Taką pułapkę można przykładowo zastawić, korzystając z pliku robots.txt, który służy do zezwalania na indeksowanie lub

BEZPIECZEŃSTWO OGÓLNE

|

81

do wykluczania z indeksowania tych części witryny, na których przeszukiwanie nie chcemy pozwolić tzw. robotom (np. botowi indeksującemu strony dla Google). Plik ten znajduje się w roocie (katalogu głównym) witryny, np. http://ecommerce/robots.txt. Można go użyć do zmylenia przeciwnika, wpisując w nim fałszywe odniesienia, a następnie monitorować te fałszywie podstawione punkty. User-agent: * Crawl-delay: 10 Disallow: /strona_administracyjna/ Disallow: /admin_password.txt

Inną możliwością „wkręcania” atakującego jest wprowadzanie go w błąd co do wykorzystanego oprogramowania. Przykładowo po zmianie rozszerzenia i nagłówków kod PHP może udawać inny kod:

Należy wtedy jeszcze pamiętać, aby korzystając z session_name(), ustawić nazwę sesji na przykład na SessionID, ponieważ domyślne PHPSESSID od razu wskazuje na PHP.

Rewrite Parametry kategorii, subkategorii i rozmaitych podstron występujące w adresie URL można z łatwością ukryć, korzystając z mod_rewrite2. Jeśli Twój system prezentuje adres w postaci http://strona/news. php?kategoria=10&rodzaj=4, to można to zmienić, zapisując przykładowo w .htaccess3 na serwerze następujący ciąg: 2

3

Coraz częściej pojawiają się opinie, że moduł ten umiarkowanie wpływa na bezpieczeństwo, dlatego trzeba mieć zainstalowaną aktualną wersję i stosować go ostrożnie. Nazwa pliku .htaccess zaczyna się od kropki. Obecność kropki na początku nazwy pliku (lub folderu) oznacza, że jest to plik (folder) ukryty.

82

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

RewriteEngine On RewriteRule ^([a-z0-9-_]+),([a-z0-9-_]+),([a-z0-9-_]+).html$ $1.php?kategoria=$2&rodzaj=$3 [L,NC,NS]

Zmienne $ z cyfrą odpowiadają poszczególnym nawiasom regułki, natomiast ^ rozpoczyna, a $ kończy wyrażenie regularne. Jeszcze ciekawszy wydaje się zapis RewriteRule ^artykul/([0-9]+)_(.*)\.html$ articles.php?id=$1

W tym przykładzie /artykul/24_wielka_wojna i /artykul/24_protesty_ ´acta zostaną zamienione na /articles.php?id=24 (odniesienie $2 jest ignorowane). Jak widzisz, jeśli dobrze wykorzystasz ten moduł, to ciągi sql-dork nie będą w serwisie widoczne.

ZAPASOWE KOPIE DANYCH Znamy osoby, które pisząc pracę magisterską, nie wykonały zapasowej kopii danych. Po stracie plików (półrocznej pracy) musiały napisać ją w ciągu miesiąca. W takich przypadkach zwykliśmy żartować, że ludzie dzielą się na tych, którzy robią kopie zapasowe, i na tych, którzy będą je robić. Bezpowrotna utrata danych jest jedną z najgorszych rzeczy, jakie się mogą przedsiębiorcy przydarzyć — może to prowadzić nawet do bankructwa. Skradzione komputery można kupić, a danych niestety nie. W tej materii świadomość nie jest jednak zbyt wysoka, a sam temat kopii zapasowych (zwanych backupami) staje się ważny dopiero wtedy, gdy coś się wydarzy. Tak samo jest w przypadku systemów e-commerce, szczególnie tych małych i średnich. Tymczasem ciągły i poprawny proces wykonywania kopii zapasowych oraz testowania, czy da się z nich odtworzyć dane konieczne do prowadzenia biznesu, pozwala zminimalizować ryzyko ich bezpowrotnej utraty. Wiedzą to bez wątpienia ci, którzy interesują się zagadnieniami zachowania ciągłości działania (tzw. BCM4). 4

BCM — ang. business continuity management.

BEZPIECZEŃSTWO OGÓLNE

|

83

W jakiej sytuacji kopia danych może się przydać? Chyba najlepiej odpowiedzieć, że w każdej: • awaria urządzeń (najczęściej ulegają jej nośniki danych — dyski twarde); • błąd ludzki, czyli utrata danych w wyniku niecelowego działania pracownika (coś się niechcący usunęło); • sabotaż — utrata danych w wyniku celowego szkodliwego działania na przykład niezadowolonego pracownika; • działanie wirusów (oprogramowania złośliwego), których celem może być usunięcie bądź zaszyfrowanie danych, aby uniemożliwić do nich dostęp; • atak hakerów, czyli celowe usunięcie, zmodyfikowanie czy zniszczenie danych. • kradzież sprzętu i utrata nośników danych; • zdarzenie losowe — uszkodzenie sprzętu w wyniku przepięcia, zalania itp. Jedno z praw Murphy’ego mówi, że jeśli coś może pójść źle, to z pewnością pójdzie źle, więc nie ma co liczyć, że nic się nie zdarzy. Na pewno się zdarzy — to tylko kwestia czasu.

Co należy backupować? Przede wszystkim wykonuje się kopie zapasowe danych biznesowych. Będą to bazy danych, pliki i katalogi serwisu e-commerce. W przypadku hostingu zajmuje się tym hostingodawca, ale jeśli serwery są w całości pod Twoim władaniem, to zadanie to spada na Ciebie (rysunek 2.1). Jeśli zarządzasz całym systemem, niezbędny będzie backup konfiguracji aplikacji, bazy danych, systemów operacyjnych czy też urządzeń sieciowych.

84

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Rysunek 2.1. Hosting — możliwość wykonania samodzielnie backupu z poziomu panelu hostingowego (DirectAdmin)

To, jak często należy wykonywać zapasową kopię danych biznesowych, zależy od systemu i jego specyfiki. Trzeba odpowiedzieć sobie na pytanie o to, z jakiego okresu dane mogą zostać utracone. Jeśli serwis jest mało aktywny, to zapasowa kopia danych wykonywana raz na tydzień też może być dobra, jednak w przypadku aktywnych systemów na pewno powinna ona być tworzona codziennie. Pamiętaj, że serwisy pracujące w klastrze to nie backup; nie stanowi go też np. disk mirroring. Dane dotyczące konfiguracji można backupować nieco rzadziej, ale należy to robić przed każdą zmianą i po niej.

BEZPIECZEŃSTWO OGÓLNE

|

85

Jeśli chodzi o hosting, to większość hostingodawców — jeśli nie wszyscy — tworzy zapasowe kopie danych i udostępnia je użytkownikowi (rysunek 2.2).

Rysunek 2.2. Backup danych dostępny w usłudze hostingu

W większości przypadków dostępny jest także backup na żądanie. Przydaje się on na przykład przed dokonaniem w serwisie istotnych zmian, które są na tyle ryzykowne, że lepiej zapewnić sobie kopię. Operacją taką jest choćby aktualizacja systemu czy zmiana struktury bazy danych. System informatyczny to nie człowiek — większości operacji nie powinno się wykonywać na „żywym organizmie”. Kopia zapasowa może być niewiele warta, jeżeli okaże się, że została nieprawidłowo wykonana, dlatego okresowo należy sprawdzać, czy w kopii zapisane są potrzebne dane i czy da się je odtworzyć. Za bardzo ważne uważamy to, aby backup był przechowywany także poza siedzibą firmy, nawet w domu, jeśli zostaną zapewnione odpowiednie warunki. Dzięki temu w przypadku dużej awarii będzie

86

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

możliwe szybkie odtworzenie systemu na przykład na innym sprzęcie i (lub) w innej lokalizacji. Kopia zapasowa danych zawiera wszystko to, co jest w oryginalnym środowisku e-commerce, więc mogłaby być cenną zdobyczą dla konkurencji. W związku z tym backup powinien być chroniony na poziomie nie niższym niż sam system e-commerce. Dostęp do niego powinny mieć tylko wybrane osoby. Dobrze by było, aby dane na nośnikach były szyfrowane, szczególnie jeżeli mają być one przechowywane w domu. Zapewnienie tego jest akurat proste, bo cały backup można zabezpieczyć hasłem: ~# gpg -c backup.tar #zaszyfrowanie ~# gpg backup.tar.gpg #odszyfrowanie

Nawiasem mówiąc, polecenie gpg domyślnie kompresuje dane przed szyfrowaniem. Wystarczające jest też spakowanie danych do pliku ZIP i zabezpieczenie go hasłem. Dzięki temu jest małe ryzyko, że dane, za pomocą których można by utworzyć „duplikat firmy”, wpadną w niepowołane ręce. Warto też zauważyć, że do zabezpieczania plików można użyć pakietu openssl. Przykładem są następujące polecenia do szyfrowania i (później) odszyfrowywania danych: ~# openssl aes-128-cbc -salt -in plik.tar -out plik.tar.aes enter aes-128-cbc encryption password: Verifying - enter aes-128-cbc encryption password: ~# openssl aes-128-cbc -d -salt -in plik.tar.aes -out plik.tar

Można też zrobić to nieco inaczej — „starować” katalog, spakować do pliku ZIP, później zaszyfrować: ~# tar -zcf - caly_katalog | openssl aes-128-cbc -salt -out caly_katalog.tar.gz.aes

a w końcu odszyfrować: ~# openssl aes-128-cbc -d -salt -in caly_katalog.tar.gz.aes | tar -xz -f -

BEZPIECZEŃSTWO OGÓLNE

|

87

Nie zalecamy używania opcji -k "hasło" po wyrażeniu aes-128-cbc — wtedy co prawda unikamy interaktywnego pytania o hasło, ale prowadzi to do zapisania go na przykład w pliku .history5. Można też użyć aes-256-cbc zamiast aes-128-cbc, jeśli jest potrzebne silniejsze szyfrowanie, ale naszym zdaniem rzadko kiedy jest to konieczne. Mówiliśmy o backupie wszystkich danych, ale może się też zdarzyć, że pracując na pojedynczych plikach (np. kodzie PHP), będziesz w trakcie ich modyfikacji tworzył podręczne kopie zapasowe. Chodzi nam o żywy organizm, tj. działający system e-commerce. Przykładowo edytując plik dbconnect.inc, możesz zrobić kopię tego pliku i zapisać ją jako dbconnect.inc.old. Jest to bardzo niebezpieczne, gdyż może się okazać, że o ile pliki *.inc serwer może blokować przy użyciu dyrektywy , to może tego nie robić dla plików *.old czy *.backup. Wtedy atakujący będzie mógł je odczytać przez przeglądarkę, wpisując na przykład adres http://ecommerce/ dbconnect.inc.old. Powinieneś więc dodać do konfiguracji webserwera odpowiednią dyrektywę i konsekwentnie trzymać się nazewnictwa takich „backupów” tymczasowych (podręcznych).

Backup haseł Hasło można zapomnieć, więc je też warto w pewien sposób backupować, czyli zapisywać. Najlepiej użyć to tego oprogramowania — nie zalecamy przechowywania haseł w postaci jawnej w notesach, na „żółtych karteczkach” etc. Korzyści związane z ich zapisywaniem z użyciem elektronicznego sejfu są dość duże — możesz tworzyć unikalne, złożone hasła dla każdego serwisu i nie przejmować się tym, że je zapomnisz. Elektroniczny sejf to po prostu zaszyfrowany plik z hasłami; pisaliśmy już wcześniej o programie KeePass. Musisz mieć jego backup! Najlepiej mieć ich kilka 5

W pliku .history przechowywana jest historia wszystkich poleceń wydawanych w oknie terminalu.

88

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

i w różnych miejscach — wtedy prawdopodobieństwo jednoczesnej utraty ich wszystkich jest niewielkie. Piszemy o tym, bo przy tworzeniu hasła na przykład do połączenia z bazą systemu e-commerce niekiedy brakuje nam fantazji. KeePass „wymyśli” hasło za Ciebie (rysunek 2.3), a ponieważ jednocześnie je zachowa, nie będziesz musiał przejmować się tym, jakie ono jest, i będziesz mógł pozwolić sobie na to, by było hardcore’owe — długie i wręcz niemożliwe do zapamiętania. Zalecamy, aby tworzyć z użyciem tego programu przede wszystkim hasła administracyjne (a najlepiej wszystkie).

Rysunek 2.3. Generowanie haseł przy użyciu programu KeePass

Na koniec warto jeszcze wspomnieć o tym, że plik z hasłami powinien być zabezpieczony porządnym hasłem i przechowywany poza serwerem, na którym znajduje się Twoja aplikacja.

Rozdział 3.

BEZPIECZNY HOSTING

HOSTING CZY WŁASNY SERWER? Przewidując tworzenie serwisu e-commerce, staniesz bez wątpienia przed dylematem, czy postawić (zainstalować) własny serwer, czy skorzystać z usług firmy hostingowej. Każde z tych rozwiązań ma swoje wady i zalety. Zaletą własnego serwera jest to, że masz pełną swobodę w jego konfiguracji. Możesz zrobić wszystko. I to jednocześnie jest wadą, bo musisz sam zadbać o wszystkie zabezpieczenia, a jest to całkiem spora praca wymagająca dużej wiedzy. Chodzi nie tylko o zabezpieczenia przed włamaniem, ale chociażby o to, aby przewidywany serwis był dostępny, nie miał przerw w działaniu (sam wiesz, jak klienci tego nie lubią) oraz był regularnie serwisowany. Mamy tu na myśli m.in. wysoką dostępność (HA1 sprzętowe i programowe) oraz load balancing2. Kupując hosting, takie rzeczy masz już zagwarantowane, tyle tylko, że nie masz pełnej władzy nad serwerem. Możesz manipulować jedynie tymi ustawieniami, które hostingodawca Ci udostępni. Własne serwery są spotykane rzadziej i stosowane są głównie na potrzeby dużych aplikacji lub tam, gdzie niezbędna jest niezależność

1

HA — ang. high availability — wysoka dostępność.

2

Load balancing (równoważenie obciążenia) — dystrybuowanie ruchu lub obciążenia między kilka serwerów lub urządzeń.

90

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

wynikająca ze specyficznych potrzeb. Większość małych i średnich serwisów e-commerce korzysta najczęściej z hostingu, gdyż jest to opcja najwygodniejsza, a niekiedy nawet najtańsza. W tym rozdziale zasygnalizujemy niektóre ważne aspekty konfiguracji mające znaczący wpływ na bezpieczeństwo danych podczas korzystania z hostingu.

DIRECTADMIN W przypadku wykupionego hostingu istnieje kilka ważnych zagadnień związanych z zarządzaniem nim, bazami danych i domeną. Zapewne otrzymasz jeden lub kilka tzw. paneli administracyjnych do administrowania hostingiem. Dostęp do każdego z nich uzyskiwany jest przez podanie nazwy konta i hasła i za bardzo ważne uważamy, aby hasła te szczególnie chronić, np. nie zapisywać ich w przeglądarce, nie wpisywać na cudzych komputerach, a już na pewno nie robić tego w kafejkach internetowych. Hasło do każdego z paneli powinno się różnić od innych. Jeśli dostęp do tych usług (paneli) nie będzie dobrze chroniony, to bezpieczeństwo całej aplikacji e-commerce będzie poważnie zagrożone. Najlepiej będzie „zaprzyjaźnić się” z programem KeePass3, który stanowi elektroniczny sejf na hasła (rysunek 3.1). Dodatkowo należy wziąć pod uwagę sposób, w jaki wgrywa się pliki na serwer. Bardzo często używa się do tego protokół FTP, który przesyła dane otwartym tekstem (ang. plain text), przez co można je podsłuchać. Niesie to też ze sobą ryzyko podsłuchania hasła, a w dalszej kolejności możliwość na przykład podmiany plików systemu. Najlepiej, jeśli jest to możliwe, korzystać z szyfrowanych protokołów, a jeśli takiej możliwości nie ma, pliki należy wgrywać poprzez panel administracyjny (np. DirectAdmin — rysunek 3.2), który najczęściej korzysta z szyfrowanego kanału

3

www.keepass.org

BEZPIECZNY HOSTING

|

91

Rysunek 3.1. KeePassX — wersja KeePass dla systemów Linux

Rysunek 3.2. Menedżer plików dostępny w panelu hostingowym

komunikacji (SSL). Panel hostingowy pozwala na wykonanie większości zadań związanych z zarządzaniem plikami, a w szczególności na ich wgrywanie (uploadowanie). Jeśli skorzystanie z niego

92

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

nie jest możliwe, to w ostateczności można użyć FTP, a po wgraniu plików dostęp tą drogą wyłączyć.

Ochrona domeny internetowej Ochrona domeny jest pośrednim elementem systemu e-commerce, ale jej bezpieczeństwo ma ogromny wpływ na jego funkcjonowanie, a raczej na jego dostępność dla klientów. Domena internetowa to element adresu DNS (ang. domain name system) wykorzystywanego do nazywania urządzeń (komputerów) w Internecie. Dla przykładu wp.pl lub onet.pl to domeny. Podobnie jest z adresem e-mail — np. [email protected] to adres konta leszek.kepa w domenie gmail.com. Domenowy system nazw powstał z tego samego powodu co książka adresowa w telefonie. Jak wiemy, w sieci Internet komputery rozpoznają siebie po numerach IP, ale ponieważ łatwiej zapamiętać nazwę niż ciąg cyfr, to stosuje się nazwy domenowe. Podobnie łatwiej jest znaleźć w telefonie kontakt, wpisując imię czy nazwisko zamiast numeru osoby. Gdyby nie było DNS-u i domen, to zamiast nazwy w przeglądarce internetowej wpisywalibyśmy numer IP, a więc przykładowo mielibyśmy http://193.41.230.73 zamiast http://www.mbank.com.pl. Warto zauważyć, że nie można zostać właścicielem domeny — można ją tylko wynająć, wydzierżawić. Jest się jej abonentem i dopóki ma się do niej prawo i płaci się za jej „wynajem”, można jej używać. I tu także widać podobieństwo do numeru telefonu. Można go mieć, ale jeśli się z niego zrezygnuje, może otrzymać go ktoś inny. Domeny tworzą hierarchię (rysunek 3.3). Są domeny najwyższego poziomu (np. .com, .pl), następnie domeny niższego poziomu (.waw.pl, .com.pl), a dalej poddomeny, które można już „kupować” (dzierżawić). Struktura drzewiasta domen będzie miała znaczenie w dalszej części książki, gdy będzie mowa o certyfikatach SSL, szczególnie o tzw. wildcardach.

BEZPIECZNY HOSTING

|

93

Rysunek 3.3. Hierarchia domen

Domena narażona jest przede wszystkim na kradzież („przepisanie” jej na kogoś innego — nieuprawnioną zmianę abonenta) i zmianę delegacji serwera nazw obsługującego domenę. Jeśli chodzi o kradzież, to oczywiście nie powoduje ona utraty domeny na długo, bo można ją odzyskać. Zawsze może to jednak spowodować wiele problemów, a przede wszystkim niedostępność systemu w internecie, bo jest się pozbawionym prawa do posługiwania się domeną. System co prawda będzie działał, ale nie będzie można się do niego dostać. To tak jak z aparatem telefonicznym: on działa, ale nie można dodzwonić się na podany numer. Bez domeny cały system e-commerce jest w zasadzie prawie niczym. Ryzyko przejęcia domeny wydaje się całkiem spore. Do zmiany jej abonenta wystarczy najczęściej wysłanie pisma do podmiotu, który rejestruje domenę (tzw. registrara lub rejestratora). Akceptowane

94

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

są nawet zgłoszenia przesyłane faksem, a przecież pieczątkę i podpis można dość łatwo podrobić, np. zeskanować z innego dokumentu. Delegacja domeny jest to wskazanie (za pomocą rekordu NS) serwera nazw, który powinien daną domenę obsługiwać. Serwery nazw można zmieniać poprzez panel administracyjny (rysunek 3.4). Z tego też powodu bardzo ważne są hasła dostępu do panelu, który służy do zarządzania domeną.

Rysunek 3.4. Przykładowy panel umożliwiający edycję serwerów nazw powiązanych z domeną

Zmiana delegacji domeny jest bardzo niebezpieczna, bo, jak już wspomnieliśmy, w internecie posługujemy się nazwami. Jeśli nazwa www.ecommerce.pl zamiast na numer IP 172.11.20.30 będzie wskazywać na inny numer IP (inny komputer w internecie), to tam też będą kierowani użytkownicy systemu (zupełnie nieświadomi tego, co się dzieje). To tak jak przekierowanie numeru telefonu: jesteś przekonany, że dzwonisz do urzędu skarbowego, podczas gdy telefon odbiera ktoś inny. W biznesie internetowym przejęcie domeny lub nieuprawniona jej zmiana może być

BEZPIECZNY HOSTING

|

95

bardziej opłakana w skutkach niż włamanie do systemu. Podkreślamy to, bo często się o tym zapomina. Jeśli aplikacja webowa ma szczególne znaczenie, a firma ma znaną i rozpoznawalną markę, to warto zastanowić się nad poszukaniem usługi typu VID4 (ang. very important domain), która polega m.in. na tym, że registrar dokonuje zmian, uprzednio porządnie identyfikując tego, kto o te zmiany wnioskuje.

4

http://www.nask.pl/files/p/Very_Important_Domains.pdf

96

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Rozdział 4.

ZABEZPIECZENIA SERWERA WWW

Jeżeli nie zdecydowałeś się na hosting, to zapewne miałeś powody ku temu, aby we własnym zakresie zarządzać całością infrastruktury, w której będzie funkcjonowała Twoja aplikacja e-commerce. To zadanie niełatwe i kosztowniejsze niż hosting, ale na pewno bardziej elastyczne i dające się dostosować do nietypowych potrzeb. Zacznijmy od webserwera. Najbardziej popularny jest Apache i naturalnym jest, że skupimy się na nim, bo jest bardzo prawdopodobne, że z niego korzystasz. W tak niedużej publikacji nie jesteśmy w stanie opisać wszelkich możliwych sposobów zabezpieczeń — powstałaby wtedy kilkusetstronicowa biblia. Jest to szerokie zagadnienie, a poza tym każdy system jest nieco inny. Wystarczy wspomnieć, że sam Apache występuje w wielu wersjach. Wszystkie porady z tej książki należy najpierw sprawdzić w środowisku testowym (ogólnie jest dobrą praktyką, aby eksperymentów nie przeprowadzać na systemie produkcyjnym) i nie należy ich stosować bezkrytycznie. Bardziej chodzi nam o pokazanie możliwości zabezpieczania systemu e-commerce, niż o podanie konkretnych i kompletnych przykładów — uwaga ta tyczy się całej książki. Na bezpieczeństwo aplikacji internetowej (będziemy ją też określać mianem webaplikacji) bezpośrednio wpływa bezpieczeństwo serwera WWW (webserwera), a na nie wiele innych czynników takich jak:

98

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

• bezpieczeństwo fizyczne serwera; • zabezpieczenie hosta, czyli m.in. systemu operacyjnego, na którym webserwer został „postawiony”; • konfiguracja samego webserwera, jego modułów i interpreterów języka (PHP); • zarządzanie podatnościami („słabościami”). Są to naczynia połączone i nie można mówić o bezpieczeństwie aplikacji webowej, jeśli nie weźmie się pod uwagę wszystkich tych elementów.

ZABEZPIECZENIA HOSTA Z przekonaniem twierdzimy, że bezpieczeństwo webserwera w dużym stopniu zależy od tego, jak zostanie skonfigurowane jego środowisko — czyli m.in. system operacyjny i jego poszczególne elementy (także te dodatkowe) — a także od tego, jak się dba o to, aby pozostał on w tym środowisku bezpieczny (przeglądy techniczne).

Hardening, czyli hartowanie hosta Zabezpieczanie maszyny (hosta), na której działa webserwer, należy zacząć od tzw. hardeningu. Najczęściej wykonuje się go na systemie operacyjnym i zainstalowanych w nim programach. Hardening to wzmacnianie odporności systemu na ataki (hartowanie). W ramach hartowania serwera zmienia się wszystkie domyślne hasła i ustawienia, blokuje niepotrzebne konta, instaluje poprawki zabezpieczeń, usuwa zbędne oprogramowanie i wyłącza nieużywane usługi oraz moduły. Zamyka się także wszystkie niepotrzebnie otwarte porty i włącza pomocnicze systemy bezpieczeństwa takie jak firewall. Na serwerze powinno działać tylko to, co niezbędne. Można powiedzieć, że hardening to swego rodzaju tuning bezpieczeństwa.

ZABEZPIECZENIA SERWERA WWW

|

99

Sam wiesz, że jak coś jest do wszystkiego, to jest do niczego, dlatego najlepiej, aby webserwer nie służył do innych celów niż prowadzenie e-commerce. Na pewno nie powinien on służyć jako firmowy serwer plików czy serwer wydruków. Oczywiście analizę tego, co będzie niezbędne i najbezpieczniejsze w konkretnym zastosowaniu, powinien przeprowadzić wdrażający rozwiązanie. Bardzo pomocne w hardeningu mogą się okazać gotowe poradniki — polecane jako tzw. najlepsze praktyki (ang. best practices) — organizacji zajmujących się bezpieczeństwem takich jak NSA1, NIST2 czy CIS3. Znajdziesz tam informacje o tym, jak krok po kroku zahartować nie tylko system operacyjny, ale na przykład bazę danych.

Firewall (a raczej DMZ) Mówiąc o hardeningu, nie sposób pominąć firewalla. W tym charakterze można wykorzystać natywny linuksowy program iptables4. To bardzo ważny element systemu zabezpieczeń — z jednej strony pozwala odizolować webserwer od zbędnych połączeń z internetu, a z drugiej izoluje go od sieci lokalnej. Serwer należy umieścić w tzw. strefie zdemilitaryzowanej (DMZ — ang. demilitarized zone, niekiedy określana mianem perimeter network). Jest ona swego rodzaju „przedpokojem” sieci komputerowej. Wyobraźmy sobie ochronę budynku, która wpuszcza wszystkich uprawnionych, w tym także gości, a dalej jeszcze jedną ochronę wpuszczającą tylko osoby zatrudnione. DMZ jest jakby strefą dla gości. Taką strefą zdemilitaryzowaną jest w świecie rzeczywistym na przykład biuro obsługi

1

http://www.nsa.gov/ia/mitigation_guidance/security_configuration_ guides/index.shtml

2

http://web.nvd.nist.gov/view/ncp/repository

3

http://www.cisecurity.org/resources-publications/

4

Iptables tutorial — http://www.faqs.org/docs/iptables/.

100

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

klienta. Tam gdzie się klienta obsługuje, nie ma wszystkich możliwych usług, natomiast po dalszej części biura (sieci lokalnej) nie może się on poruszać. W strefie DMZ znajdują się te usługi, które muszą być widoczne dla gości, czyli w internecie. Są to webserwer, serwer z bazami danych (z których korzysta e-commerce), system e-mail oraz DNS. Konfigurując webserwer dostępny z sieci internet, warto się kierować standardową zasadą co nie jest dozwolone, jest zabronione i blokować wszystko, zezwalając jedynie na to, co konieczne. Przykładowo webserwer powinien akceptować połączenia „ze świata” tylko na porty 80 (http) i 443 (https). Ponadto, jeżeli jest potrzeba zarządzania serwerem z zewnątrz, należy akceptować połączenia na port związany z SSH, ale powinno się to odbywać z dodatkowymi ograniczeniami (akceptacja połączeń tylko z określonych IP, uwierzytelnionych certyfikatem lub korzystających z dodatkowych usług uwierzytelniania takich jak DuoSecurity)5. Jeśli chodzi o połączenia inicjowane ze strony serwera, zablokuj wszystko — webserwer rzadko kiedy będzie sam nawiązywał połączenia z innymi hostami w internecie. Wyjątkiem mogą być sytuacje, gdy Twój system ściąga treści z innych witryn.

Aktualizacje bezpieczeństwa Aby utrzymać dobry poziom bezpieczeństwa serwera, trzeba łatać dziury w oprogramowaniu. Warto w tym celu śledzić serwisy publikujące informacje o jego podatnościach (np. CVE6, VUPEN7 czy też CERT8) i dokonywać niezbędnych aktualizacji.

5

http://www.duosecurity.com/

6

http://cve.mitre.org/cve/

7

http://www.vupen.com/english/

8

http://www.cert.gov.pl

ZABEZPIECZENIA SERWERA WWW

|

101

Bardzo ciekawą opcją są nienadzorowane aktualizacje zabezpieczeń wykonywane za pomocą mechanizmu unattended-upgrades, który w sposób automatyczny i bez ingerencji administratora potrafi instalować poprawki. Mechanizm jest bardzo ciekawy i warto znać i tę możliwość, choć jesteśmy raczej negatywnie nastawieni do instalowania poprawek zabezpieczeń bez ich uprzedniego przetestowania. Sposób instalacji i konfiguracji tego narzędzia został przedstawiony na przykładzie Ubuntu na stronie https://help.ubuntu. com/community/AutomaticSecurityUpdates.

Wydajność Wydajność bardzo często będzie się kłócić z bezpieczeństwem. Sprawdzając rozmaite aplikacje do testowania wydajności webserwera, możesz użyć programu ab — być może podobne opcje zabezpieczeń będą mieć na nią różny wpływ. Parametr n tego programu oznacza liczbę żądań, a k odpowiada liczbie żądań równolegle wysłanych (ang. concurrency). ab -n 100 -c20 http://helion.pl/index.asp This is ApacheBench, Version 2.3 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking helion.pl (be patient).....done Server Software: Server Hostname: Server Port:

Apache helion.pl 80

Document Path: Document Length:

/index.asp 3252 bytes

Concurrency Level: Time taken for tests: Complete requests: Failed requests: Write errors: Non-2xx responses: Total transferred:

20 5.974 seconds 100 0 0 100 352115 bytes

102

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

HTML transferred: Requests per second: Time per request: Time per request: requests) Transfer rate:

325200 bytes 16.74 [#/sec] (mean) 1194.759 [ms] (mean) 59.738 [ms] (mean, across all concurrent 57.56 [Kbytes/sec] received

Connection Times (ms) min mean[+/-sd] median Connect: 160 605 853.9 300 Processing: 270 445 135.9 399 Waiting: 239 431 136.8 386 Total: 490 1050 899.0 662

max 3310 675 662 3894

Percentage of the requests served within a certain time (ms) 50% 662 66% 1081 75% 1134 80% 1157 90% 1182 95% 3827 98% 3877 99% 3894 100% 3894 (longest request)

ZABEZPIECZENIA APACHE Poniżej zaprezentujemy kilka najważniejszych ustawień, na jakie należy zwrócić uwagę podczas konfiguracji serwera Apache (głównie httpd.conf lub apache2.conf — zależnie od wersji). Przedstawimy kilka naszym zdaniem najbardziej przydatnych dodatkowych modułów mogących nam pomóc w zabezpieczeniu naszej aplikacji. Na koniec zaprezentujemy informacje dotyczące tego, jak odizolować Apache od systemu operacyjnego.

Konfiguracja serwera Informacja o tym, jaki serwer jest wykorzystywany do serwowania aplikacji, może ułatwiać odkrycie jego podatności, a w konsekwencji umożliwiać atak. Dlatego należy wyłączyć „podpisywanie się” serwera przy użyciu dyrektywy ServerSignature Off. Dzięki temu ustawieniu ograniczymy rozgłaszanie szczegółowych informacji

ZABEZPIECZENIA SERWERA WWW

|

103

o serwerze m.in. podczas generowania wewnętrznych stron błędów oraz listowania katalogów FTP. Dodatkowo należy ustawić dyrektywę ServerTokens na Prod (dostępne opcje: Full, OS, Minor, Minimal, Major, Prod) — wówczas webserwer będzie wysyłał informację jedynie o swoim „gatunku”, np. Server: Apache. Gdyby opcja ta była ustawiona na Full (lub niewyspecyfikowana), byłoby to: Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.29. Jak widać, z komunikatu tego można się całkiem sporo dowiedzieć nie tylko o serwerze, ale nawet o systemie operacyjnym, wersji PHP i modułach. Dla hakera jest to podstawowe zadanie — zebrać jak najwięcej informacji o atakowanym systemie. Znając jego wersję, poszukuje on znanych podatności, które otworzą mu furtkę do Twoich danych. Za pomocą dyrektyw Directory należy globalnie zablokować możliwość przeglądania katalogów w taki sposób jak na rysunku 4.1.

Order Deny,Allow Deny from all AllowOverride None

Rysunek 4.1. Przykład niewyłączonej sygnatury serwera oraz możliwości przeglądania katalogów

9

https://httpd.apache.org/docs/2.2/mod/core.html#servertokens

104

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Należy także (przy użyciu dyrektyw Directory) zablokować dostęp do określonych rodzajów plików, np. *.inc (pliki typu include, które są używane w skryptach, mogą zawierać np. dane niezbędne do połączenia z bazą danych).

Order allow,deny

Polecamy również upewnić się, że w standardowej konfiguracji została umieszczona poniższa dyrektywa blokująca klientom (użytkownikom witryny) dostęp do wszystkich plików typu .htaccess i .htpasswd, które są bardzo ważne, bo określają prawa dostępu do zawartości danego folderu lub strony internetowej (aplikacji). Na tej zasadzie możesz blokować dostęp do plików zawierających kod inicjalizujący połączenie z bazą danych (np. connection.php).

Order allow,deny Deny from all Satisfy all

Twój system najczęściej będzie miał też stronę do administrowania dostępną na przykład pod adresem https://strona/admin/. Dobrze jest wejście na nią chronić dodatkowo (podkreślamy — dodatkowo) uwierzytelnianiem dokonywanym przez Apache.

AuthType Basic AuthName "Tylko do zarzadzania" AuthUserFile /config/users AuthUserGroup /config/users require valid-user

Szczegółowy opis wszystkich dyrektyw znajdziesz na stronie dokumentacji serwera Apache http://httpd.apache.org/docs/2.0/ mod/core.html#files.

ZABEZPIECZENIA SERWERA WWW

|

105

Webserwer powinien pracować w systemie co najmniej na uprawnieniach użytkownika nobody (nieuprzywilejowanego) lub z uprawnieniami maksymalnie ograniczonymi. Rekomendowanym rozwiązaniem jest utworzenie w systemie konta użytkownika przeznaczonego tylko i wyłącznie dla procesów Apache. Aby sprawdzić, na jakim koncie użytkownika działa Apache, wystarczy wydać polecenie: # ps –ef | grep apache

Jeżeli zdecydujesz się na utworzenie nowego użytkownika, to powinien on być wskazany (USER, GROUP) w pliku konfiguracyjnym serwera. Bardzo szczególnym miejscem jest katalog cgi-bin, w którym znajdują się skrypty CGI (ang. common gateway interface). CGI służy jako brama do uruchamiania programów, które pozwalają na komunikację serwera WWW z innymi programami na serwerze. Szczególnego znaczenia w przypadku skryptów CGI nabierają uprawnienia dostępu, zarówno do samych skryptów, jak i do katalogu, w którym się one znajdują. Skrypty i katalog cgi-bin nie powinny mieć ustawionych praw do zapisu dla wszystkich, ponieważ pozwalałoby to osobom nieuprawnionym na modyfikację skryptów. Uprawnienia katalogu i skryptów powinny przyjmować wartość 755.

Dodatkowe mody dla Apache mod_evasive W przypadku ataków DoS (and. denial of service) Apache szybko może „paść”, przetwarzając setki czy tysiące zbędnych żądań (requestów). Interesującym rozwiązaniem problemu jest moduł mod_evasive monitorujący liczbę przychodzących połączeń i blokujący najbardziej natarczywych klientów. Działa to tak, że po otrzymaniu żądania mod_evasive:

106

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

• Sprawdza, czy adres, z którego przychodzi żądanie, nie znajduje się na czarnej liście (jeśli tak, odrzuca go z kodem błędu 403). • Wykonuje hasz z URI10 i IP, sprawdza częstotliwość jego występowania i w ten sposób znajduje potencjalne ataki na konkretny URI. • Wykonuje hasz z IP i odrzuca ataki na całą witrynę ze zmiennym URI. • Jeśli żądanie przejdzie powyższe testy bez blokady, przepuszcza je, zwiększa odpowiednie liczniki i zapisuje hasze, zapamiętując w ten sposób aktywność klienta. Z ustawieniami tego modułu należy szczególnie uważać, bo nie każdy podejrzany ruch jest anomalią. Dobrze jest przetestować jego działanie, zanim trafi on na „produkcję”. Warto wspomnieć, że moduł ten pozwala na wykonywanie poleceń zewnętrznych, na przykład zmodyfikowanie konfiguracji firewalla — wydaje się, że lepiej nieznośnych blokować na firewallu niż przez Apache. mod_security Firewall jest niezbędny, aby przepuszczać tylko oczekiwany ruch sieciowy, jednak nie uchroni Cię przed atakami realizowanymi za pośrednictwem HTTP, które przy użyciu spreparowanego złośliwego zapytania usuwają, zmieniają lub wykradają dane na przykład z bazy danych. W ich przypadku konieczne jest sprawdzanie każdego zapytania. Z pomocą przychodzi nam narzędzie-moduł mod_security11, które pełni w pewnym sensie rolę firewalla aplikacyjnego. Do pewnego stopnia chroni ono przed typowymi atakami typu SQL injection, path traversal czy też XSS. Jednak ono samo 10

Ang. uniform resource identifier. Różnica między URL a URI jest bardzo subtelna, więc w dużym uproszczeniu możesz traktować je jako to samo.

11

http://www.modsecurity.org/ — strona projektu ModSecurity.

ZABEZPIECZENIA SERWERA WWW

|

107

na niewiele nam się zda. Aby moduł mod_security działał efektywnie, wymaga zaimplementowania reguł, na podstawie których będzie odrzucał podejrzane zapytania. Bardzo dobrym i przy tym bezkosztowym rozwiązaniem będzie skorzystanie z wyników pracy projektu ModSecurity Core Rule Set Project12, który udostępnia przygotowane do zaimplementowania reguły. Sposób ich instalacji i konfiguracji został doskonale opisany na stronie projektu. Godne uwagi są również reguły z serwisu GotRoot13. Należy pamiętać, że moduł ten nie powinien wyręczać programisty w bezpiecznym zakodowaniu aplikacji — powinien być on raczej traktowany jako kolejna, dodatkowa warstwa zabezpieczeń.

Chrootowanie — Apache na uwięzi Godnym uwagi sposobem na zwiększenie bezpieczeństwa webserwera będzie tzw. chrootowanie Apache. Mechanizm ten polega na ograniczeniu procesom Apache dostępu do systemu plików poprzez wydzielenie nowej dedykowanej struktury plików, w ramach której będzie działał Twój webserwer (czegoś na kształt „piaskownicy”). Taka konfiguracja utrudni penetrację atakowanego systemu, a jeżeli już nawet włamanie dojdzie do skutku, to atakujący uzyska dostęp jedynie do plików samego Apache. Istnieją dwa sposoby na wykonanie chrootowania: a) ręczne przygotowanie dedykowanego środowiska (manuale w tym zakresie są dostępne w internecie, jest to jednak dość żmudne zajęcie), b) zautomatyzowane wykonanie go za pomocą modułu mod_ ´security.

12

https://www.owasp.org/index.php/Category:OWASP_ModSecurity_ Core_Rule_Set_Project

13

http://www.gotroot.com/mod_security+rules

108

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Ze względu na łatwość jego implementacji naturalnie polecamy mod_security. Korzystając z funkcjonalności moda, zasadniczo potrzebujemy jednego dodatkowego wpisu w konfiguracji webserwera: SecChrootDir /chroot/apache

Więcej informacji na temat tej funkcjonalności mod_security można znaleźć pod adresem http://www.modsecurity.org/ documentation/apache-internal-chroot.html.

KONFIGURACJA PHP Długo się zastanawialiśmy, czy o konfiguracji interpretera kodu PHP pisać w części poświęconej bezpieczeństwu aplikacji, czy też tutaj, gdzie piszemy o konfiguracji serwera. Uznaliśmy, że konfiguracja ta jest bardziej związana z serwerem niż z samą aplikacją. Lista ustawień konfiguracyjnych (dyrektyw) PHP zawiera kilkaset pozycji. W tej części książki przedstawimy wraz ze sposobem ich ustawienia te dyrektywy, które mogą mieć największy wpływ na bezpieczeństwo aplikacji, a dzięki którym trochę ograniczysz ryzyko. Warto też zaznaczyć, że kilka dodatkowych dyrektyw PHP będzie jeszcze omawianych w ramach opisu bezpieczeństwa samej aplikacji. Jeśli chcesz sprawdzić aktualną konfigurację PHP, możesz użyć następującej funkcji:

Jak widzisz, prezentuje ona w wyniku całe mnóstwo informacji. Z tego też powodu warto dbać, aby nikt niepożądany nie mógł jej uruchomić z poziomu interfejsu przeglądarki. Ustawieniami PHP można sterować na kilka sposobów zależnie od potrzeb i architektury rozwiązania. Jeżeli jesteś właścicielem

ZABEZPIECZENIA SERWERA WWW

|

109

webserwera, to większości ustawień dokonasz w pliku php.ini. Jeżeli korzystasz z hostingu, to będziesz miał do dyspozycji jedynie część ustawień PHP, które będziesz mógł zmieniać w pliku .htaccess za pomocą następującej składni14: php_flag [nazwa dyrektywy] [ustawienie on/off]

Istnieją jednak pewne ograniczenia co do sposobu konfiguracji danych grup dyrektyw. Przykładowo za pomocą pliku .htaccess będziesz mógł ustawić tylko te dyrektywy, które należą do grupy PHP_INI_ALL oraz PHP_INI_PERDIR. Tabela 4.1 przedstawia zasady konfiguracji dla poszczególnych grup. Tabela 4.1. Wykaz grup dyrektyw i zasad ich użycia Grupa dyrektyw

Zasady użycia

PHP_INI_USER

skrypty użytkownika (np. ini_set())

PHP_INI_PERDIR

php.ini, .htaccess lub httpd.conf/apache2.conf

PHP_INI_SYSTEM

php.ini lub httpd.conf/apache2.conf

PHP_INI_ALL

dowolny sposób konfiguracji

php.ini only

tylko poprzez plik php.ini

Z pełną listą dyrektyw oraz zasad ich użycia możesz się zapoznać na stronie projektu PHP15. Standardową konfigurację php.ini z dystrybucji PHP proponujemy przejrzeć i ewentualnie ograniczyć, zwracając uwagę co najmniej na dyrektywy przedstawione w dalszej części rozdziału. Stosuj zasadę, że lepiej wyłączyć zbyt

14

Niekiedy także dla hostingobiorcy dostępny jest jego własny plik php.ini, w którym w pewnym zakresie może on manipulować dyrektywami.

15

http://us2.php.net/manual/en/ini.list.php

110

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

wiele i selektywnie włączać tylko to, co jest potrzebne, i tylko tam, gdzie jest to potrzebne (rysunek 4.2).

Rysunek 4.2. Panel DirectAdmin może także pozwalać na zmianę ustawień PHP (hosting). Na rysunku widać przykładowe domyślne ustawienia

ZABEZPIECZENIA SERWERA WWW

|

111

Zmienne globalne Do wersji 4.2 PHP rejestrował wszystkie zmienne niebędące zmiennymi lokalnymi jako globalne niezależnie od tego, czy były one tworzone poprzez metody GET lub POST protokołu HTTP, sesje, środowisko, czy też serwer. To niosło ze sobą wiele niebezpieczeństw — wystarczy wspomnieć o wprowadzeniu błędnej wartości dowolnej zmiennej globalnej przez URL (metoda GET). Jeśli jednocześnie taka wartość nie była odpowiednio filtrowana, to przy odrobinie szczęścia (dla włamywacza) czy też pecha (dla Ciebie) mogła nieźle namieszać. Za rejestrację wszystkich zmiennych jako globalnych odpowiada dyrektywa register_globals, obecnie domyślnie ustawiana na wartość off. Gdyby jednak przypisać tej dyrektywie wartość on, po restarcie serwera znów można by używać wszystkich zmiennych dostępnych bezpośrednio w zasięgu globalnym. Najlepszym sposobem zabezpieczenia się przez zgubnymi wpływami tej dyrektywy jest zapomnienie o niej i stosowanie tablic superglobalnych. Tabela 4.2 zawiera ich listę. Dodatkowo warto skorzystać z dyrektywy open_basedir, wskazując konkretny katalog, z którego pliki skrypt PHP będzie mógł jedynie otwierać. Dyrektywa może wyglądać następująco: open_ basedir = /dir/incl/ — konieczne jest zakończenie wskazywania lokalizacji ukośnikiem, aby ograniczyć dostęp tylko do określonego katalogu. Jest to swego rodzaju chrootowanie, tyle że PHP — podobne do tego, które miało miejsce dla Apache.

Komunikaty o błędach Komunikaty o błędach ujawniają wiele interesujących informacji. Zbieranie takich danych jest jedną z podstawowych czynności, jakie podejmuje haker na etapie rozpoznania. Warto więc blokować wyświetlanie informacji, które pozwalają na skuteczny rekonesans. Przykładowy komunikat błędu ujawnia strukturę folderów:

112

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Tabela 4.2. Wykaz tablic superglobalnych Tablica

Opis zmiennych

$GLOBALS

Dostępne w zasięgu globalnym skryptu.

$_SERVER

Utworzone przez serwer i związane ze środowiskiem uruchomieniowym skryptu.

$_GET

Utworzone za pomocą metody GET protokołu HTTP.

$_POST

Utworzone za pomocą metody POST protokołu HTTP.

$_COOKIE

Utworzone przez mechanizm ciasteczek.

$_FILES

Utworzone podczas przesyłania plików na serwer (uploadu).

$_ENV

Dostarczone do skryptu przez środowisko serwera.

$_REQUEST

Dostarczone do skryptu przez mechanizmy wejścia (miks $_GET, $_POST i niekiedy $_COOKIES).

$_SESSION

Zarejestrowane jako zmienne sesji.

Warning: fopen(LeszekKepa.doc) [function.fopen]: failed to open stream: No such file or directory in /var/www/public_html/zyciorys/pokaz_cv.php on line 72

expose_php Dobrą praktyką jest nie ujawniać informacji o wykorzystywanych wersjach oprogramowania czy też błędach przez nie zgłaszanych. Podobnie jak w przypadku webserwera, tak i przy konfiguracji samego PHP zalecamy ustawienie kilku ważniejszych dyrektyw, na przykład: expose_php = Off

Takie ustawienie zabezpieczy Cię przed ujawnianiem przez PHP informacji o samym sobie (m.in. o wersji) w nagłówkach HTTP przesyłanych do klienta w odpowiedzi na każde zapytanie wysyłane do serwera.

ZABEZPIECZENIA SERWERA WWW

|

113

display_startup_errors Wyświetlanie błędów podczas uruchamiania PHP jest przydatne tylko do celów tzw. debuggingu. W produkcyjnym systemie powinno ono być wyłączone: display_startup_errors = Off

display_errors Wyłączenie tego parametru: display_errors = Off

spowoduje, że błędy i ostrzeżenia PHP nie będą wyświetlane. Jest to szczególnie ważne, gdyż mogą one ujawniać bardzo wartościowe dla atakującego informacje, np. ścieżki czy też zapytania SQL. log_errors, errors_log Błędy i ich szczegóły nie powinny być pokazywane użytkownikowi systemu, ale jak najbardziej powinien być o nich informowany administrator. Włączenie dyrektywy log_errors oraz wskazanie ścieżki w dyrektywie error spowoduje, że komunikaty o błędach będą zapisywane we wskazanym pliku: log_errors = On error_log = /var/log/php.log

Wysyłanie i otwieranie plików na serwerze Jeżeli nie ma takiej potrzeby, to dobrze jest wyłączyć możliwość wysyłania na serwer plików z wykorzystaniem protokołu HTTP, gdyż z tym wiąże się sporo zagrożeń: file_upload = off

Warto też wyłączyć możliwość ściągania danych ze „zdalnych” lokalizacji takich jak FTP czy inna witryna: allow_url_fopen = 'off'

114

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Jeśli jednak z założenia Twój system ma przetwarzać zawartość innych zewnętrznych witryn, to lepiej tej opcji nie zmieniać.

Magic quotes Istnieje co najmniej kilka dyrektyw związanych z mechanizmem magic quotes, który miał być sposobem na poprawę bezpieczeństwa PHP. Niestety rozwiązanie nie sprawdziło się pod względem bezpieczeństwa, a także sprawiało dużo problemów i dlatego zdecydowano się nie rozwijać tego projektu. Tym samym nie zalecamy korzystania z tej — przynajmniej w założeniach — bardzo ciekawej metody zabezpieczania, chociaż w kilku miejscach o niej wspominamy.

Hardening PHP — Suhosin Z pełnym przekonaniem stawiamy tezę, że nie ma bezpieczeństwa bez hardeningu, który powraca jak bumerang przy konfigurowaniu każdego kolejnego elementu systemu e-commerce. Tym razem będziemy hardeningować PHP i jak się okaże, nie będzie to takie trudne, gdyż w pewnym zakresie możemy skorzystać z gotowego narzędzia, jakim jest Suhosin. Zostało ono zaprojektowane, aby chronić serwery i użytkowników zarówno przed już znanymi, jak i przed nowymi lukami w aplikacjach napisanych w PHP oraz w samym rdzeniu PHP. Suhosin jest zaawansowanym rozwiązaniem, które już przy podstawowej konfiguracji pomoże zapewnić choć minimum bezpieczeństwa. Składa się ono z dwóch części: pierwsza z nich to Suhosin patch stanowiący zbiór poprawek PHP chroniących m.in. przed przepełnieniem buforów, a druga to Suhosin Extension posiadający szereg zaawansowanych funkcji16, które pozwalają „dobezpieczyć” naszą aplikację.

16

http://www.hardened-php.net/suhosin/a_feature_list.html

ZABEZPIECZENIA SERWERA WWW

|

115

Po poprawnej instalacji i ponownym uruchomieniu webserwera, wydając polecenie php -v, powinniśmy ujrzeć następującą informację: # php -v PHP 5.3.5-1ubuntu7.3 with Suhosin-Patch (cli) (built: Oct 13 2011 21:56:07) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

Konfiguracja Suhosin odbywa się za pomocą pliku php.ini, choć pewnie rzadko będzie trzeba się do niej odwoływać, gdyż — jak twierdzą twórcy programu — for most users the Suhosin will work out of the box without any change to the default configuration needed17. Tym niemniej opcje konfiguracji zostały szczegółowo opisane na stronie „The Hardened-PHP Project”. Jedną z opcji, która bardzo się przydaje, jest tryb symulacji. Suhosin, mimo standardowej konfiguracji, wprowadza wiele nowych ograniczeń dla aplikacji PHP, co może powodować problemy z poprawnym jej działaniem, dlatego warto korzystać z opcji suhosin.simulation, która pozwala na podstawie zapisywanych zdarzeń poobserwować, co jest blokowane. Po pewnym czasie już z większą pewnością możemy uruchomić narzędzie „na produkcji”. Warto podkreślić, że jest to tylko dodatkowy mechanizm zabezpieczający, i tak trzeba go postrzegać. Suhosin ma pomóc, ale nie rozwiąże wszystkich problemów związanych z bezpieczeństwem systemu e-commerce.

17

http://www.hardened-php.net/suhosin/configuration.html

116

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

ZABEZPIECZENIE KODU PHP Zwykły użytkownik, mamy tu na myśli użytkownika systemu, nie ma możliwości odczytania kodu PHP. Kod można odczytać jedynie od strony serwera. Użytkownik odczyta go tylko w przypadku, gdy: 1. tworzone są pliki *.old lub *.backup z plików PHP — chyba że w konfiguracji zablokowano możliwość ich „serwowania”; 2. zhakuje serwis i będzie mógł „drukować” zawartość PHP do kodu HTML; 3. dostanie się do panelu zarządzania hostingiem, systemu CMS etc.; 4. zrobi to pośrednio z komunikatów błędów; 5. dostanie się do serwera inną drogą. Ogólnie security by obscurity, czyli mówiąc pół żartem pół serio, tzw. głębokie ukrycie, jest najsłabszą formą zabezpieczeń, ale nie można powiedzieć, że nic nie wnosi do bezpieczeństwa. Jeśli chodzi o kod PHP, to możesz zastosować rozszerzenia plików, które będą nieco wprowadzać przeciwnika w błąd: # Niech kod PHP wygląda jak inny kod AddType application/x-httpd-php .ccp .c .pl .boo .foo .197p .htm

To może nieznacznie utrudnić rozpoznanie, bo po URL-u takim jak http://strona/loguj.c albo http://strona/news.boo trudno na pierwszy rzut oka ocenić, w jakim kodzie stworzony jest system. Z możliwości tej korzystaj ostrożnie, np. parsowanie plików *.htm przez PHP ma sens tylko wtedy, gdy nie używasz wcale statycznego kodu. Inną możliwością jest skompilowanie kodu PHP do postaci kodu binarnego (pliki wykonywalne). Problem może wtedy stanowić rozwijanie i modyfikacja kodu (bo po każdej zmianie trzeba go kompilować), ale biorąc pod uwagę to, że nie powinno się wprowadzać

ZABEZPIECZENIA SERWERA WWW

|

117

zmian w kodzie systemu produkcyjnego (najpierw należy go przetestować), może być to całkiem niezły pomysł. Tu do wyboru jest parę rozwiązań takich jak Zend, Ioncube, Nu-Coder czy SourceCop. Niestety w większości są to rozwiązania płatne. Polecamy też lekturę przewodnika PHP Security Guide 1.0 wydanego przez PHP Security Consortium18. Warto także wziąć pod uwagę narzędzie ze strony http://phpsec.org/projects/phpsecinfo/.

PRZEGLĄDANIE LOGÓW W Apache są dwa ważne pliki, do których będą trafiać informacje o zdarzeniach. Dane o żądaniach przetwarzanych przez serwer trafiają do pliku access.log, a dane o błędach serwera do pliku error.log. Ścieżkę do pierwszego z nich kontroluje dyrektywa CustomLog, a do drugiego — ErrorLog. Równie ważne jest ustawienie dyrektywy LogLevel, która steruje poziomem zapisywanych zdarzeń — może ona przyjmować wartości: debug, info, notice, warn, error, crit, alert oraz emerg. Przykładowo w przypadku pierwszej wartości w logu będą zapisywane w zasadzie wszystkie zdarzenia (co jest przydatne przede wszystkim na etapie rozwoju systemu), a ostatnia z nich zapisuje tylko krytyczne błędy serwera. Jeśli masz swój parser logów, to format ich zapisu możesz dopasować przy użyciu dyrektywy LogFormat. Fragment pliku error.log [Mon Jan 23 19:19:22 2012] exist: /var/www/announce [Mon Jan 23 19:20:11 2012] [Mon Jan 23 19:21:17 2012] `jan dot kowalski dot mail

18

[error] [client 127.0.0.1] File does not [notice] caught SIGTERM, shutting down [warn] RSA server certificate CommonName (CN) dot pl' does NOT match server name!?

http://phpsec.org/projects/

118

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Fragment pliku access.log 127.0.0.1 - - [24/Jan/2012:08:39:02 +0100] "GET /nie ma HTTP/1.1" 404 494 "-" "Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1" 127.0.0.1 - - [24/Jan/2012:08:39:06 +0100] "GET /jest HTTP/1.1" 404 493 "-" "Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1" 127.0.0.1 - - [24/Jan/2012:08:39:12 +0100] "GET /login.php HTTP/1.1" 200 446 "-" "Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1"

Konfigurując logowanie zdarzeń, nie można zapominać o wszelkich modułach czy też rozszerzeniach dodatkowo zabezpieczających serwer. Ważne jest, aby skonfigurować również zapisywanie zdarzeń dla takich modułów jak mod_security czy też Suhosin. Aby logi miały wartość, muszą być wiarygodne. Jednym z elementów zapewnienia wiarygodności jest precyzyjne podanie czasu zajścia zdarzenia, dlatego warto zadbać o to, aby czas systemowy na serwerze był synchronizowany automatycznie na przykład za pomocą protokołu NTP. Podkreślamy, że jeżeli dzieje się coś złego, na przykład podejmowane są próby ataku, to na pewno zacznie się coś pojawiać w logach.

OBSŁUGA KOMUNIKATÓW 403, 404 ETC. Na błędy webserwer reaguje komunikatami. Zapewne niejednokrotnie spotkałeś się ze słynną stroną 404 (rysunek 4.3). Takich kodów jest kilkanaście19 i dzielą się one na grupy, m.in. na kody powodzenia oraz kody błędów. Pierwsza z tych grup nie jest wprost widoczna dla użytkownika serwisu, ale druga już jak najbardziej. Jako administrator serwera Apache możesz zdecydować, jak ma wyglądać komunikat lub jaką akcję ma podjąć serwer w przypadku wystąpienia określonego błędu. Zazwyczaj należy wyświetlić

19

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

ZABEZPIECZENIA SERWERA WWW

|

119

Rysunek 4.3. Przykładowy zmieniony komunikat błędu 404

użytkownikowi „przyjazny” komunikat informujący o błędzie (nieujawniający zbyt wielu informacji o samym serwerze). Można też przekierować go na inną stronę. Za sposób obsługi błędów odpowiada dyrektywa ErrorDocument, a jej wykorzystanie może być następujące: ErrorDocument ErrorDocument ErrorDocument ErrorDocument

403 401 404 500

http://mojastrona.pl "Nie masz dostępu do tej strony." /komunikaty/nie_znaleziono.php "/cgi-bin/obsluga_bledow.pl"

Naszym zdaniem niekoniecznie trzeba użytkownikom wyświetlać numer błędu. Można nawet wprowadzać swego rodzaju security by obscurity, prezentując jeden rodzaj komunikatu niezależnie od jego rzeczywistego kodu (statusu).

ZABEZPIECZANIE PLIKÓW KONFIGURACYJNYCH Dobrą praktyką jest też dodatkowe zabezpieczenie plików przed możliwością ich modyfikacji. Co prawda nie jest to zabezpieczenie doskonałe, bo zdobycie uprawnień użytkownika root pozwala je

120

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

wyłączyć, tak samo jak zostało ono włączone, jednak w wielu przypadkach uzyskania nieautoryzowanego dostępu uchroni nas to przed ingerencją choćby w konfigurację. Narzędziem, z którego możesz skorzystać, jest program chattr20 z przełącznikiem i, który uniemożliwia wszystkim użytkownikom systemu wykonywanie operacji na pliku (modyfikacja, usunięcie, zmiana nazwy, tworzenie dowiązań). Opcja ta może być ustawiana lub zdejmowana przez użytkownika root. Założenie blokady następuje poprzez użycie przełącznika +i, natomiast jej zdjęcie dzięki -i. Jako że jest to część poświęcona konfiguracji serwera Apache i PHP, możesz dla przykładu zablokować główne pliki konfiguracyjne: chattr +i /etc/apache2/apache2.conf chattr +i /etc/php5/apache2/php.ini

Oczywiście chattr możesz wykorzystać dla każdego pliku, który nie musi być modyfikowany.

TRIPWIRE Kontynuując temat zabezpieczania plików konfiguracyjnych, nie można nie wspomnieć o takim narzędziu jak pakiet Tripwire21. Jego działanie polega na odwzorowaniu systemu plików i przypisaniu do nich cyfrowych sygnatur, których później można użyć do wykrycia, czy nie zostały podmienione jakieś ważne pliki. Nie jest to zapobieganie atakom, a raczej narzędzie do wykrywania zmian. Co to daje? Załóżmy, że haker włamał się do serwera. Normalnie należałoby zainstalować go zupełnie od nowa (reinstalacja) i odtworzyć dane z godnego zaufania backupu, gdyż nie można mieć pewności, co haker zrobił, jakie wgrał pliki i jakie pliki zmienił. Mając Tripwire, posiadasz indeks zmian i zajmujesz się odtwarzaniem 20 http://pl.wikipedia.org/wiki/Chattr 21

http://www.tripwire.com/

ZABEZPIECZENIA SERWERA WWW

|

121

lub naprawianiem tylko tego, co zostało zmienione. Jednym słowem, gdy zostanie wykryte włamanie, możesz zaoszczędzić czas, nie mówiąc już o tym, że w ogóle możesz wykryć nieautoryzowane zmiany. Po instalacji pakiet Tripwire należy zainicjalizować. Na podstawie danych z plików konfiguracyjnych zapisze on sobie snapshot (zrzut) informacji o systemie plików; następne uruchomienia odbywają się w trybie porównywania go z bazą inicjalizacyjną. #!/bin/sh HOST_NAME=`uname -n` if [ ! -e /var/lib/tripwire/${HOST_NAME}.twd ]; then echo "Error: Tripwire database for ${HOST_NAME} not found" echo "Run "/etc/tripwire/twinstall.sh" and/or "tripwire --init"" else test -f /etc/tripwire/tw.cfg && /usr/sbin/tripwire --check fi

Konfiguracji pakietu dokonuje się w pliku /etc/tripwire/twpol. txt. Po jego skonfigurowaniu należy ten plik załadować: # twadmin -m P /etc/tripwire/twpol.txt

a następnie utworzyć nową bazę danych zawierającą obecny status plików. Później pozostaje tylko dokonywać co jakiś czas sprawdzenia integralności systemu plików przy użyciu polecenia: tripwire -m c

Sam plik konfiguracyjny należy usunąć — zapobiega to poznaniu konfiguracji przez hakera. Ciekawą i godną polecenia opcją jest informowanie o zmianach w systemie plików e-mailem. Dzięki temu po pierwsze wiesz, że Tripwire działa, a po drugie na bieżąco śledzisz zmiany. ( rulename = "Ważne pliki", severity = $(SIG_HI), emailto = [email protected]; [email protected] )

122

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Zanim uruchomisz opcję powiadomień, możesz sprawdzić, czy to działa: /usr/sbin/tripwire --test --email [email protected]

Monitoringiem możesz także objąć — poza plikami systemowymi — katalog z plikami aplikacji (np. PHP), co pozwoli Ci śledzić zmiany w kodzie Twojej witryny.

OBRONA PRZED ATAKAMI DOS — FAIL2BAN Fail2ban jest uważany za jedno z podstawowych narzędzi dostępnych w internecie służących do zabezpieczania serwerów webowych opartych na Linuksie przed atakami typu DoS (ang. denial of service). Program wychwytuje z logów „złe” działania i „banuje” (blokuje) ruch z danego IP na określony czas lub na stałe. Szczególnie skutecznie zapobiega to skanowaniu serwera przez boty sieciowe, które używając losowych loginów, próbują znaleźć jego słabe punkty. Ze względu na szybkość działania boty te mogą być dość uciążliwe, ponieważ zmuszają serwer do przetwarzania swoich fałszywych loginów. Zwiększa to obciążenie systemu, dlatego znacznie lepszą alternatywą jest blokowanie takiego hosta. Instalacja Fail2ban polega na ściągnięciu paczki odpowiedniej dla danej dystrybucji Linuksa ze strony projektu www.fail2ban. org, a konfiguracja ogranicza się do edycji dwóch plików konfiguracyjnych, tj. /etc/fail2ban/jail.conf oraz /etc/fail2ban/fail2ban.conf. W pierwszym z plików w sekcji [DEFAULT] znajdują się ustawienia globalne takie jak nieblokowanie konkretnych IP, czas blokady czy liczba prób powodująca blokadę: [DEFAULT] ignoreip = 127.0.0.1/8 bantime = 600 maxretry = 3 # Destination email address used solely for the interpolations in # jail.{conf,local} configuration files. destemail = root@localhost

ZABEZPIECZENIA SERWERA WWW

|

123

Następnie ustawiamy sposób banowania nieproszonych gości w sekcjach [ACTIONS] i [JAILS], gdzie wskazuje się usługi objęte monitorowaniem. W domyślnie zainstalowanym pliku są różne „jaile” — nas najbardziej będą interesować te poświęcone webserwerowi, tj. [apache], [apache-noscript], [apache-overflows]22. Co ciekawe, globalne wartości można nadpisać właśnie w jailach. Można na przykład na godzinę blokować próby dla Apache, ale na jeden dzień dla SSH. Warto stosować Fail2ban również do ochrony innych usług. Przykładowy jail wygląda następująco: [apache] # sekcja jest aktywna enabled = true port = http,https # filtr z /etc/fail2ban/filter.d/apache-auth.conf filter = apache-auth # scieżka do monitorowanego logu logpath = /var/log/apache*/*error.log # ile razy musi wystapic okreslone w filtrze zdarzenie maxretry = 6

Plik /etc/fail2ban/filter.d/apache-auth.conf zawiera szczegóły filtrowania: # Option: failregex # Notes.: regex to match the password failure messages in the logfile. The # host must be matched by a group named "host". The tag "" can # be used for standard IP/hostname matching and is only an alias for # (?:::f{4,6}:)?(?P[\w\-.^_]+) # Values: TEXT # failregex = [[]client []] user .* authentication failure [[]client []] user .* not found [[]client []] user .* password mismatch

22

Dużo przykładów konfiguracji można znaleźć na stronie http://www. fail2ban.org/wiki/index.php/Fail2ban:Community_Portal#Apache.

124

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Drugi z plików konfiguracyjnych — fail2ban.conf — służy do ustawiania poziomu zapisywanych w logu zdarzeń oraz ścieżki logu. [Definition] # Option: loglevel 1 = ERROR 2 = WARN 3 = INFO 4 = DEBUG loglevel = 3 logtarget = /var/log/fail2ban.log socket = /var/run/fail2ban/fail2ban.sock

Aby sprawdzić, jakie adresy zostały zbanowane, należy wydać polecenie iptables -L. W poniższym przykładzie w części Chain fail2ban-ssh (1 references) widoczny jest host zbanowany za to, że próbował atakować SSH. # iptables -L Chain INPUT (policy ACCEPT) target prot opt source fail2ban-ssh tcp -- anywhere dports ssh

destination anywhere

Chain FORWARD (policy ACCEPT) target prot opt source

destination

Chain OUTPUT (policy ACCEPT) target prot opt source

destination

Chain fail2ban-ssh (1 references) target prot opt source DROP all -- pawel-U31Jg.local RETURN all -- anywhere

destination anywhere anywhere

multiport

Dla małych i średnich systemów e-commerce Fail2ban jest całkiem dobry, gdyż nie obciąża zbytnio systemu. Na mocno obciążonym serwerze, gdzie generowane są ogromne ilości logów dziennie, może być jednak konieczne inne rozwiązanie.

Rozdział 5.

BAZA DANYCH

Dane aplikacji e-commerce przechowywane są głównie w bazach danych. Dzisiaj trudno sobie wyobrazić system e-commerce, który by pracował na plikach płaskich (zwykłych plikach). Owszem, jest to możliwe, ale nie jest to rozwiązanie wydajne, nie mówiąc o tym, że jest ono mało bezpieczne. Teoretycznie baza danych powinna być postawiona na oddzielnym serwerze, jednak naszym zdaniem będzie to zależało od rodzaju biznesu, jaki będziesz prowadził. Jeśli, upraszczając, masz jeden serwis i jedną bazę danych, to zarówno baza, jak i pozostałe składowe systemu mogą znajdować się na jednym serwerze. W każdym jednak przypadku warto serwer bazy danych zhardeningować, czyli wzmocnić jego bezpieczeństwo. Tutaj odniesiemy się do serwera bazy danych MySQL1, bo jest on najczęściej używany. Po jego zainstalowaniu należy wykonać kilka bardzo ważnych czynności. Ataki przy użyciu narzędzi typu sqlmap2 są możliwe właśnie dlatego, że standardowe (tzw. defaultowe) ustawienia serwerów baz danych nie zawsze są zmieniane. Przede wszystkim należy usunąć konta anonimowe i bazę testową. Są one tworzone automatycznie podczas instalacji bazy danych.

1

http://www.symantec.com/connect/articles/securing-mysql-step-step

2

http://sqlmap.sourceforge.net/

126

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

SELECT * FROM mysql.user WHERE user =""; DROP USER ""; DROP DATABASE test;

Zalecamy zmienić też nazwę konta root na inną, nierzucającą się w oczy. Mówi się, że to porada dla paranoików, ale każdy, kto zna nazwę konta administratora, wie, od czego zacząć. Niekiedy taktyki „zaciemniania” bardzo pomagają. RENAME USER root TO rutuzer

Warto także zadbać o odpowiednie ustawienia w pliku konfiguracyjnym my.cnf. W sekcji [mysqld] można wskazać numer IP, na jakim baza ma nasłuchiwać. Jeśli znajduje się ona na tym samym serwerze co webserwer, należy wskazać adres 127.0.0.1; jeśli ma być dostępna z zewnątrz, należy wskazać adres publiczny interfejsu; jeśli jest kilka IP — wskazuje się 0.0.0.0 (jest to zresztą wartość domyślna). W przypadku gdy baza jest na tym samym serwerze co aplikacja, to może warto komunikować się z nią przez gniazdko (socket) mysql.sock, wyłączając nasłuchiwanie na porcie 3306 (opcja skip-networking). bind-address=127.0.0.1

Cyberprzestępcy bardzo często listują bazy danych. Przy użyciu dyrektywy skip-show-database można zabronić wykorzystywania komendy SHOW DATABASES. Można też rozważyć zablokowanie ładowania plików przez potencjalnie niebezpieczne polecenia SQL takie jak poniższe. SELECT load_file("/etc/passwd")

W tym celu należy dopisać do konfiguracji set-variable=localinfile=0. Jeśli chcesz to zrobić bardzo szybko, to możesz urucho-

mić skrypt mysql_secure_installation, który parę z tych czynności wykona za Ciebie. Niezależnie od tego sprawdź, czy nowe ustawienia rzeczywiście działają — testowanie to podstawa.

BAZA DANYCH

|

127

Warto jeszcze zapamiętać, że nie należy pozwalać na tworzenie linków symbolicznych do tabel (opcja –skip-symbolic-links) oraz nie należy nadawać przywilejów PROCESS, SUPER, FILE itd. zwykłym użytkownikom. Jeśli nie masz zaufania do DNS-u, to lepiej też używać adresów IP zamiast nazw domenowych w tabelach uprawnień (przykładowo 172.11.20.79). W bazie danych najbardziej wrażliwą tabelą jest mysql.users. Nie każdy powinien mieć do niej dostęp. To, że aplikacja e-commerce nie powinna pracować na koncie roota (administratora bazy danych), jest raczej oczywiste. Dobrze też wiedzieć, że zachowanie niektórych funkcji MySQL zależeć będzie od tego, jak pewne opcje zostały ustawione w pliku php.ini. Tu warto zwrócić uwagę m.in. na: • mysql.allow_persistent i mysql.max_persistent (stałe, „twarde”

połączenia z bazą danych); • mysql.trace_mode (odpowiadającą za wyświetlanie błędów SQL);

• mysql.default_user oraz mysql_default_password i mysql.safe_mode. Ze względu na ograniczoną objętość książki nie jesteśmy w stanie opisać każdej z nich, a jedynie sygnalizujemy ich obecność.

Eksport i import danych Bardzo prawdopodobne jest, że korzystając z hostingu, będziesz używał phpMyAdmin. Jest to narzędzie umożliwiające zarządzanie bazą danych przez przeglądarkę internetową. Pozwala ono m.in. na wyeksportowanie zawartości całej bazy danych do pliku. Możesz to zrobić w różnych celach. Po pierwsze, jest to pewna forma zapasowej kopii danych tworzonej np. przed ich większymi zmianami. Może to też być pewna forma okresowego backupu bazy danych niezależnego od backupów wykonywanych przez dostawcę hostingu. Pamiętaj, że plik z wyeksportowanymi danymi nie jest w żaden sposób chroniony

128

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

— powinieneś zadbać o jego zabezpieczenie, np. zaszyfrować go, korzystając z programu gpg (przykłady już podawaliśmy). Oto eksport bazy danych z linii poleceń (tzw. z palca): # mysqldump -u uzytkownik -phaslo_uzytkownika baz_danych > backup_bazy_`date +%d%m%Y_%H%M`.sql

Takie polecenie możesz włączyć do zadań crona3. Żeby można było później odtworzyć bazę (ang. restore), potrzebny jest wykonany wcześniej backup i ewentualnie log binarny (ang. binary log). Robi się to po prostu tak: # mysql < backup_bazy_25012012_1140.sql # mysqlbinlog hostname-bin.000001 | mysql

POŁĄCZENIE Z BAZĄ Konfiguracja połączenia systemu e-commerce z bazą danych może znajdować się na przykład w pliku polacz.php.

Kiedyś zetknęliśmy się z serwisem składającym się z kilkuset plików, a ciąg inicjujący połączenie z bazą danych znajdował się w każdym z nich. Wystarczyłoby, aby administrator wykonał nieostrożnie kopię pliku z rozszerzeniem, które serwer WWW „prze-

3

Cron — specjalny program w systemie Linux, którego zadaniem jest uruchamianie innych programów cyklicznie lub o określonej porze.

BAZA DANYCH

|

129

puszcza” (np. *.bkp), aby hasło do połączenia z bazą zostało ujawnione. Dlatego też każde połączenie z bazą danych powinno następować poprzez załączanie głównego pliku inicjującego połączenie z nią — może się to odbywać przy użyciu polecenia require() lub include().

Plik powinien być odpowiednio zabezpieczony, a więc należy dodać do *.htaccess ciąg

order allow,deny deny from all

Dobrze jest też zmienić uprawnienia do pliku, tak abyś mógł go odczytać tylko Ty i webserwer (uprawnienia 400 lub 440). Bardzo ciekawe „zabezpieczenie” połączenia z bazą zaprezentowano w manualu PHP Security Guide 1.04. Należy wpisać do httpd.conf zmienne serwera: SetEnv LAMPDU "uzytkownik" # nazwa uzytkownika SetEnv LAMPUP "jego_haslo" # haslo uzytkownika

Następnie, po restarcie, w kodzie aplikacji można używać zmiennych $_SERVER['DB_USER'] i $_SERVER['DB_PASS']. W ten sposób w żadnym ze skryptów nie będą zapisane dane do logowania. Ryzyko, że te informacje zostaną ujawnione (np. przez nieostrożne użycie phpinfo() lub print_r($_SERVER)), jest jednak duże. Dużo bezpieczniejsze może być rozdystrybuowanie części hasła pomiędzy zmienne serwera i skrypt PHP. W zmiennych środowiskowych można umieścić kawałek hasła: SetEnv LAMPUP "pierwsza_czesc_hasla"

4

http://phpsec.org/projects/

130

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Wtedy w skrypcie polacz.php po niewielkiej zmianie hasło użytkownika bazodanowego będzie wyglądało następująco: $mysql_pass = $_SERVER['LAMPUP'] . "druga_czesc_hasla";

W efekcie całego hasła nie będzie ani w pliku z kodem PHP, ani w zmiennych środowiskowych, a z bazą będzie można się połączyć, zestawiając oba jego kawałki. To rozwiązanie wydaje nam się wyjątkowo godne polecenia.

SZYFROWANIE DANYCH Bardzo często pojawia się pytanie, w jakiej formie przechowywać dane w bazie. Na pewno hasła należy przechowywać w postaci zaszyfrowanej. Napisaliśmy „zaszyfrowanej”, ale będziesz najprawdopodobniej używał haszy, tj. jednokierunkowych funkcji skrótu. To nie jest szyfrowanie — jest to pewna zaawansowana forma sumy kontrolnej. Więcej informacji na ten temat zamieszczono w rozdziale poświęconym bezpieczeństwu aplikacji. Szyfrowanie informacji przechowywanych w bazie danych stanowi niestety podły kompromis między wydajnością a bezpieczeństwem. Tak zresztą jest w ogóle z zabezpieczeniami: zazwyczaj wprowadzają one jakieś utrudnienia i aby system był funkcjonalny, często szuka się złotego środka. Zanim przystąpi się do szyfrowania, warto zastanowić się, jakie dane należy zaszyfrować. Gdyby szyfrowano wszystkie informacje w bazie, to wydajnością nie różniłaby się ona od płaskich plików tekstowych z danymi. Na pewno najmniejsza jest korzyść z szyfrowania danych liczbowych, bo wtedy traci się wszystko to, co stanowi zaletę baz danych. Może na przykład nie być możliwe wykonanie w bazie operacji SELECT TOP n FROM, gdyż musiałaby to zrobić aplikacja, która najpierw odszyfrowałaby wszystkie dane, a później wybrała n największych wartości. Bezpieczniej jest więc szyfrować najwrażliwsze dane tekstowe.

BAZA DANYCH

|

131

Zaszyfrowany ciąg z przykładu ma wartość DBX+B6PZTTk/PHWn4MM ´2S5Mnaxf8X68vjIkY7bWyRWs=, ale po zmianie wartości soli5 na inną

(np. ciut_soli) wynik też się zmieni: NP0IlMmLQNw+IlpB+kvvP7aRQTF ´tpKKfNrJmCf0k2J0=. Zauważyłeś zapewne, że wykorzystane zostało kodowanie Base64 (to się rzuca w oczy choćby przez to, że na końcu wygenerowanego ciągu jest znak równości).

Przechowywanie danych Warto rozważyć, czy wszystkie dane od początku funkcjonowania systemu trzeba przechowywać w jednej bazie danych. Po roku być może nie jest to problem, ale po wielu latach może się okazać, że

5

Sól (ang. salt) — dane dodawane podczas wyliczania wyniku funkcji skrótu. Sól ma charakter podobny do wektora inicjalizującego, z tym że nie jest wartością losową.

132

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

wydajność bazy (a więc i całego systemu) spadła znacząco. Jeśli spojrzeć na to z punktu widzenia bezpieczeństwa, jest jeszcze jeden aspekt. Jeśli ktoś się włamie do systemu, uzyska dostęp do wszystkich danych, także tych historycznych. Można więc rozważyć wykorzystanie dwóch baz i dane z jednej po pewnym czasie przenosić do drugiej, niedostępnej dla systemu e-commerce. Wiele gromadzonych informacji po pewnym czasie staje się bezużytecznych. Warto te dane także usuwać, uprzednio archiwizując je na jakimś nośniku.

Operacje na „żywej” bazie danych System e-commerce musi być dostępny ciągle i musi w odpowiednim czasie reagować na działania użytkowników. Jeśli musisz wykonać duże operacje na bazie danych, które będą go znacząco obciążać, podziel je na mniejsze. Inaczej duże zapytanie zablokuje Twoje tabele i aplikacja może stać się niedostępna. Apache uruchamia wiele równoległych wątków, dlatego też będzie bardziej wydajny, jeśli wykonanie skryptów nie będzie trwało dłużej niż kilkanaście sekund. Duże zadania z łatwością podzielisz w skrypcie6: while (1) { mysql_query("DELETE FROM logi_aplikacji WHERE log_date /etc/ssl/CA/serial" touch /etc/ssl/CA/index.txt

Następnie modyfikuje się w pliku konfiguracyjnym openssl.cnf w sekcji CA_default następujące wpisy: dir database certificate serial private_key

= = = = =

/etc/ssl/ $dir/CA/index.txt $dir/certs/cacert.pem $dir/CA/serial $dir/private/cakey.pem

# katalog bazowy # plik indeksu # certyfikat CA # bieżący numer seryjny # klucz prywatny

W dalszej kolejności należy wygenerować certyfikat dla głównego urzędu certyfikacji, tzw. root CA: openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650

Później wygenerowane pliki przenosimy w odpowiednie miejsca. Można to zrobić od razu, ale tak jest przejrzyściej dla Czytelnika. mv cakey.pem /etc/ssl/private/ mv cacert.pem /etc/ssl/certs/

I w zasadzie mamy CA. Możemy nim sygnować inne certyfikaty — wystarczy podać plik CSR, dokładnie tak, jak to pokazaliśmy w jednym ze wcześniejszych przykładów.

BEZPIECZNA TRANSMISJA DANYCH

|

153

A JEŚLI NIE MA SZANS NA SSL? Jeśli nie ma możliwości zastosowania do uwierzytelnienia (podczas podawania loginu i hasła) szyfrowanej transmisji danych, to należy ponieść ryzyko i liczyć się z możliwością podsłuchania takich danych albo szukać innych możliwości. Jedną z nich jest maskowanie hasła polegające na tym, że zamiast całego hasła podaje się tylko jego niektóre wylosowane części, np. pierwszy, trzeci i szósty znak (rysunek 6.8). Jeśli w ramach transmisji hasło zostanie przejęte przez hakera (podsłuchane), to przynajmniej nie całe. Maskowanie hasła działa najlepiej w parze z blokowaniem konta po kilku nieudanych próbach. Takie rozwiązanie stosuje się często w systemach IVR, gdyż linia telefoniczna może zostać podsłuchana dość łatwo, a szyfrowania nie można powszechnie zaimplementować. Niestety nie jest to zbyt wygodne dla użytkowników — łatwiej pamięta się i wpisuje całe hasło niż niektóre jego znaki. Lepsze jednak takie rozwiązanie niż żadne, chociaż naszym zdaniem nie przyczynia się ono znacznie do zwiększenia bezpieczeństwa14.

Rysunek 6.8. Maskowanie hasła

14

Należy pamiętać, że maskowanie zmniejsza ryzyko przejęcia hasła, ale nie zabezpiecza w żaden sposób transmisji danych.

154

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

KOMUNIKACJA PRZEZ E-MAIL W systemie e-commerce nieodzowne jest wysyłanie e-maili do jego użytkowników. Mogą to być przykładowo odpowiedzi na rejestrację (np. zawierające link do kliknięcia w celu potwierdzenia założenia konta) czy też automatycznie wysyłane e-maile z potwierdzeniami transakcji czy płatności. Zabezpieczenie komunikacji e-mailowej jest niestety bardzo kłopotliwe. Aby można było szyfrować wiadomości do klientów, po obu stronach muszą istnieć mechanizmy obsługujące szyfrowanie, np. jakiś program instalowany dodatkowo (np. PGP, GPG) albo aplikacja pocztowa, która obsługuje określony standard (np. S/MIME w Microsoft Outlook). Konieczność posiadania odpowiednich programów to nie wszystko — dochodzi do tego dodatkowy problem, jakim jest wymiana kluczy szyfrujących. Przesyłanie danych poufnych pocztą elektroniczną należy ograniczyć do niezbędnego minimum. Chciałoby się powiedzieć, że należy je zupełnie wyeliminować, ale tak się raczej nie da. Tutaj istotną rolę odgrywa analiza ryzyka. Projektując system, powinieneś przeanalizować, co się stanie, gdy określona wysłana z systemu e-commerce wiadomość wpadnie w niepowołane ręce (zostanie przechwycona w trakcie jej transmisji albo nawet zmieniona). W przypadku wysyłania poufnych danych do klienta przy użyciu poczty elektronicznej całkiem dobrym (i funkcjonalnym) rozwiązaniem wydaje się przesłanie ich w załączniku w postaci zabezpieczonego pliku PDF. Klient może ustalać wcześniej hasło do załączników w serwisie e-commerce. Nie może to być jednak to samo hasło, którego używa do logowania — hasła do systemu nie powinny być przechowywane w formie jawnej, podczas gdy hasło do zabezpieczania PDF-ów będzie musiało być przechowywane w taki sposób15. Dla PHP dostępne są darmowe biblioteki i klasy PHP

15

Wynika to z tego, że w takim przypadku nie da się zastosować hasza.

BEZPIECZNA TRANSMISJA DANYCH

|

155

do tworzenia plików PDF zabezpieczonych hasłem — przykładem są klasy FPDF16. Korzystając ze skryptu17, którego autorem jest Klemen Vodopivec, można w systemie e-commerce zaimplementować takie rozwiązanie — w wyniku jego zastosowania zostanie wygenerowany plik PDF, do którego otwarcia będzie wymagane hasło. Kod po niewielkiej modyfikacji można wykorzystać do załączenia pliku do e-maila:

Metoda SetProtection() pozwala na dodawanie uprawnień. Przykładowo SetProtection(array('print')) utworzy plik PDF, który można będzie drukować, ale nie będzie możliwe kopiowanie jego zawartości. Dobrze jest o tym pamiętać. Przesyłanie haseł pocztą elektroniczną Hasła w zasadzie nie powinno się przesyłać e-mailem w żadnym wypadku. Wyjątkiem jest sytuacja, gdy przesyłane hasło jest jednym z kilku składników logowania (tzn. gdy nic się nie da z nim zrobić, jeśli się nie posiada jeszcze czegoś, np. tokena albo innej informacji). Jeśli użytkownik zapomni hasło i zechce je odzyskać, to należy przesłać mu na przykład link do jego zresetowania albo link do strony, na której będzie mógł ustawić nowe hasło, podając odpowiedzi na wcześniej zdefiniowane „sekretne pytania”. Na pewno nie

16

http://www.fpdf.org/

17

http://www.fpdf.org/en/script/script37.php

156

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

zaleca się przesyłania użytkownikowi zapomnianego hasła za pomocą e-maila (o czym napiszemy dalej). W przypadku przesyłania linku (odnośnika) do resetowania hasła jego ważność powinna być ograniczona, np. wynosić jeden dzień. Zapamiętaj, że jeśli system przysyła Ci hasło, które miałeś poprzednio, to prawie na pewno przechowuje je w niezakodowanej formie, co nie jest zbyt dobrym i bezpiecznym rozwiązaniem.

ADMINISTROWANIE POPRZEZ SIEĆ Specyfika każdego systemu internetowego jest taka, że od czasu do czasu trzeba „podłączyć się” do serwera, np. by podmienić (zaktualizować) pliki aplikacji czy też aby nim zarządzać (zmienić jego konfigurację etc.). Jeśli chodzi o aspekty administrowania serwerem, to jesteśmy przekonani, że administratorzy posiadają obecnie odpowiednią wiedzę, i trudno nam uwierzyć, by ktokolwiek używał dzisiaj do zarządzania serwerem dostępnym publicznie na przykład protokołu Telnet — znakomita większość administratorów (chciałoby się powiedzieć, że wszyscy) używa do tego celu SSH (ang. secure shell)18. Dlatego też skupimy się na tych zagadnieniach, które, jak wynika z naszego doświadczenia, sprawiają najwięcej problemów związanych z bezpieczeństwem, a więc przede wszystkim na kopiowaniu plików z serwera systemu e-commerce i do niego.

FTP Najpopularniejszym sposobem przesyłania plików na serwer jest FTP. Użytkownicy lubią z niego korzystać, a ponadto jest wiele klientów FTP takich jak FileZilla, CuteFTP, SmartFTP, które ułatwiają wymianę plików. Platformy hostingowe (gdy hosting jest w modelu

18

W przypadku hostingu shell nie zawsze będzie dostępny dla hostingobiorcy.

BEZPIECZNA TRANSMISJA DANYCH

|

157

shared hosting) nie zawsze udostępniają powłokę (ang. shell), więc czasami nie pozostaje nic innego, jak korzystać z FTP. FTP nie jest bezpieczny, gdyż przesyła dane w formie jawnej. Co więcej, login i hasło używane do logowania także są przesyłane jawnym tekstem. Oznacza to, że można je podsłuchać, co pokazane zostało na rysunku 6.9.

Rysunek 6.9. Przykład odczytania (podsłuchania) hasła do FTP w programie Wireshark

Używanie FTP proponujemy ograniczyć do przypadków absolutnej konieczności, na przykład gdy korzystamy z hostingu i hostingodawca nie udostępnia innego sposobu dostępu do serwera lub daje możliwość wgrania plików przez przeglądarkę, a trzeba ich wgrać bardzo wiele (wtedy robienie tego za pośrednictwem przeglądarki jest bardzo niewygodne). Co zrobić, gdy trzeba skorzystać z FTP? Przynajmniej do minimum ograniczyć ryzyko. Można przykładowo ustawić tzw. białą listę hostów (ang. whitelist), z których można łączyć się z FTP — większość administracyjnych paneli hostingowych oferuje takie ustawienia. Dobrze jest włączać tę listę tylko na czas wykonywania prac, a później ją czyścić. W niektórych przypadkach lista działa odwrotnie — kiedy nie ma na niej żadnego numeru IP, to można łączyć się z każdego. Wówczas można

158

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

usunąć wszystkie numery IP, a pozostawić tylko jeden z puli numerów niepublicznych, np. 10.0.0.1, dzięki czemu FTP będzie jakby wyłączany (rysunek 6.10).

Rysunek 6.10. Biała lista IP dla połączeń FTP

Jeśli system e-commerce znajduje się w całości na Twoich serwerach, można skorzystać z innych rozwiązań. To właśnie jest różnica między hostingiem a własnym serwerem, który daje znacznie większe możliwości panowania nad swoim systemem.

Szyfrowane kanały — SFTP i FTPS Do bezpiecznego kopiowania plików można użyć protokołu FTPS lub SFTP. Pierwszy to FTP over SSL — rozszerzenie FTP oferujące obsługę szyfrowanych protokołów transmisji danych. To rozwiązanie

BEZPIECZNA TRANSMISJA DANYCH

|

159

rozbudowane i dość trudne w implementacji. Łatwiej chyba będzie skorzystać z częściej używanego SFTP (ang. SSH file transfer protocol) czy też z Secure FTP (tunelowanego przez SSH ruchu FTP). Do administrowania serwerem e-commerce opartym na platformie Unix bądź Linux najprościej użyć ssh, po stronie serwera powinien zaś być zainstalowany openssh-server. Na pewno w żadnym wypadku nie powinno się używać programu telnet, nawet w sieci wewnętrznej. Poniżej pokazano podłączanie się przez SSH do zdalnego hosta w charakterze użytkownika e-commerce. ~$ ssh [email protected] [email protected]'s password: ecommerce@OpenWrt:~$

A oto przykład tego, jak skopiować plik httpd.conf z serwera 192.168.1.1 z katalogu /etc/apache na komputer, z którego się łączysz z katalogiem domowym użytkownika e-commerce: ~$ scp [email protected]:/etc/apache/httpd.conf /home/ecommerce

Oczywiście dostępne są też nakładki graficzne, ponieważ wiele osób preferuje taką formę. Przykładowo bardzo popularny jest program WinSCP19, który do złudzenia przypomina aplikację Total Commander20 (rysunek 6.11).

INTEGRALNOŚĆ DANYCH PODCZAS TRANSMISJI W szyfrowaniu chodzi przede wszystkim o to, aby informacji nie odczytał ten, kto do tego nie jest upoważniony. Czasami poufność, tj. zachowanie danych w tajemnicy, nie jest aż tak bardzo ważna,

19

http://winscp.net/eng/index.php

20 http://www.ghisler.com/

160

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Rysunek 6.11. Interfejs programu WinSCP

ale istotne jest, aby nie zostały one po drodze zmienione lub podmienione. W tym celu stosuje się rozmaite narzędzia. Najłatwiejsza do zaimplementowania jest tzw. suma kontrolna (ang. checksum) w najprostszej postaci występująca jako cyfra kontrolna. Stosuje się ją na co dzień w numerze PESEL czy numerze rachunku bankowego. Przykładowo w numerze PESEL 94112058585 ostatnia cyfra jest właśnie cyfrą kontrolną. Algorytm jej wyliczania jest całkiem prosty i został przedstawiony na obrazku poniżej. Suma kontrolna chroni przed literówkami czy innymi pomyłkami. Jeśli rozważymy numer 94112058485, to wyliczona cyfra kontrolna 4 nie będzie się w jego przypadku zgadzać z ostatnią cyfrą (rysunek 6.12). Dzięki temu wiadomo, że nastąpiła pomyłka podczas wpisywania numeru. Podajemy ten przykład nie bez powodu. Jeśli będziesz do jakichś celów gromadził numery PESEL, to warto weryfikować ich poprawność, tj. sprawdzać, czy są złożone z 11 znaków, czy wszystkie z nich są cyframi oraz czy cyfra kontrolna zgadza się z wyliczoną. Co więcej, jeśli użytkownik będzie podawał datę urodzenia i płeć, to — ponieważ w numerze PESEL takie informacje są „zaszyte” —

BEZPIECZNA TRANSMISJA DANYCH

|

161

Rysunek 6.12. Weryfikacja cyfry kontrolnej w numerze PESEL

możesz zweryfikować także je. Naszym zdaniem, jeśli formularz rejestracyjny będzie zawierał takie procedury walidacji, to może on zastąpić technikę CAPTCHA. Pamiętaj, że sam numer PESEL uważa się za dane osobowe21 i że nie można go przesyłać bez zastosowania szyfrowania. W praktyce stosuje się bardziej zaawansowane metody wyliczania sumy kontrolnej. Służą do tego jednokierunkowe funkcje skrótu, czyli tzw. hasze. Są one trochę podobne do odcisku palca — dla różnych danych wynik takiej funkcji jest różny, a dla takich samych zawsze taki sam. Najczęściej stosuje się MD5 i SHA-25622 (SHA — ang. secure hash algorithm). Hasz można wyliczyć z ciągu danych, a nawet z pliku. Weźmy przykładowo obraz ISO płyty DVD z oprogramowaniem ściągnięty z internetu. Na stro21

Generalny Inspektor Ochrony Danych Osobowych (GIODO) w odpowiedziach na pytania pisze, że w rozumieniu ustawy o ochronie danych osobowych już sam numer PESEL stanowi dane osobowe — http://www. giodo.gov.pl/317/id_art/2912/j/pl/.

22

Funkcji skrótu jest znacznie więcej. Są to oprócz MD5 i SHA-256 m.in. SHA w różnych wersjach (SHA-0, SHA-1, SHA-284, SHA-512), RIPE-MD, HAVAL czy ElGamal. W zastosowaniach związanych z e-commerce najbardziej użyteczne będą jednak te dwie: MD5 i SHA-256.

162

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

nie, na której dostępny jest plik do ściągnięcia, prezentowana jest jego suma kontrolna. Pozwala ona między innymi sprawdzić, czy plik został ściągnięty w całości. Jeśli ściągasz go z innej witryny albo masz go z innych źródeł, to wyliczając i porównując sumy kontrolne, możesz sprawdzić, czy jest to oryginał (rysunek 6.13).

Rysunek 6.13. Na stronie dostawcy podana jest suma kontrolna MD5 dla oprogramowania

Po ściągnięciu naszego przykładowego pliku „policzyliśmy” sumę kontrolną: ~$ md5sum BT5R1-GNOME-64.iso 9217bd4ca62f183f8f932c5008021162

BT5R1-GNOME-64.iso

Widać, że nie zgadzała się ona z podaną na stronie internetowej, a więc albo obraz nie był kompletny, albo ktoś go zmodyfikował. I rzeczywiście, po dokładnym sprawdzeniu okazało się, że plik nie został ściągnięty w całości. Gdyby został bez takiego sprawdzenia nagrany na płytę, możliwe, że nie zadziałałby. Po ponownym ściągnięciu tego pliku suma kontrolna już się zgodziła: ~$ md5sum BT5R1-GNOME-64.iso 13b6bc940a34274675278fd14506a5d2

BT5R1-GNOME-64.iso

BEZPIECZNA TRANSMISJA DANYCH

|

163

Jako kolejną ciekawostkę warto podać fakt, że OpenSSL także potrafi wyliczać sumy kontrolne. Ten pakiet jest niczym szwajcarski scyzoryk. ~$ openssl md5 BT5R1-GNOME-64.iso MD5(BT5R1-GNOME-64.iso)= 13b6bc940a34274675278fd14506a5d2

Zamiast algorytmu MD5 można wykorzystać SHA-256. Działanie tej funkcji jest w zasadzie identyczne — różnica tkwi w algorytmie i w długości sumy. $ sha256sum BT5R1-GNOME-64.iso ff44312259423e3882ec789440a54029a8162efb7ee9773b646f275ad857a1b6 GNOME-64.iso

BT5R1-

Zapewne zastanawiasz się, jakie zastosowania będą miały hasze w przypadku e-commerce. Znajdzie się ich bardzo wiele. Najważniejsze z nich to przechowywanie haseł użytkowników w formie wyniku funkcji skrótu z hasła tekstowego, natomiast jeśli chodzi o komunikację, będzie to udostępnianie plików na stronie. Dzięki udostępnieniu wyniku funkcji skrótu dla programu odbiorca będzie miał pewność, że ściągnął go poprawnie (albo że nikt go po drodze nie „zatruł” fałszywymi danymi), tak jak to zaprezentowaliśmy w powyższym przykładzie. Do tematu haszy wrócimy jeszcze przy okazji omawiania kont i haseł użytkowników systemu.

164

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Rozdział 7.

IDENTYFIKACJA STRON W BIZNESIE

W systemie e-commerce istnieją dwie strony transakcji: świadczący usługę (sprzedawca, provider) oraz jej odbiorca (kupujący). Warto prawidłowo je identyfikować i ustalić ich tożsamość z wielu powodów. Dla kupującego jest to ważne, bo chce on być pewien tożsamości sprzedającego. Prawo także wymaga, aby właściciel systemu e-commerce odpowiednio o sobie informował, o czym pisaliśmy w części poświęconej aspektom prawnym. Dla Ciebie jako dostawcy identyfikacja drugiej strony transakcji również jest bardzo ważna, i to z wielu powodów. Zasadniczym jest uzyskanie pewności w obrocie gospodarczym, zmniejszenie ryzyka. Przykładowo jeśli ktoś złoży zamówienie, podając fałszywe dane, a Ty je zrealizujesz, to poniesiesz związane z tym koszty pakowania, wysłania towaru i powrotu przesyłki. W niektórych przypadkach będziesz zobligowany, by znać tożsamość klienta, np. trudno wyobrazić sobie prowadzenie bankowości online anonimowo. Wiedza o użytkowniku przyda się także w innych celach, np. marketingowych. Wszystko oczywiście zależy od rodzaju biznesu i od analizy ryzyka — Ty sam musisz ocenić, jak dużą pewność potrzebujesz mieć w obrocie gospodarczym.

166

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

WIARYGODNY SPRZEDAWCA Klient powinien mieć możliwość zidentyfikowania Ciebie jako przedsiębiorcy — podmiotu świadczącego usługi drogą elektroniczną. Jest to zasada, która ma swoje odzwierciedlenie w tzw. obowiązkach informacyjnych, o czym pisaliśmy już w rozdziale poświęconym prawu w e-commerce. Prawidłowe zidentyfikowanie sprzedawcy jest istotne dla kupującego. Jeśli podmiot prowadzący e-commerce poda fałszywe dane, a kupujący ich nie zweryfikuje, to urząd skarbowy może uznać, że nie ma on prawa na przykład odliczyć podatku VAT widniejącego na wystawionej przez ten podmiot fakturze1. Prowadzącego witrynę może dodatkowo identyfikować certyfikat SSL, o ile został on wydany przez zaufaną stronę trzecią (np. Thawte, VeriSign), gdyż instytucje te, wydając certyfikaty, sprawdzają (dokładniej lub mniej dokładnie) tożsamość wnioskujących. Certyfikat wystawiony sobie samodzielnie (tzw. self-signed) nie spełnia tej funkcji, bo taki certyfikat może sobie wygenerować każdy. Przykładowy certyfikat podpisany przez zaufaną stronę trzecią ujawnia informacje o witrynie i o podmiocie (rysunek 7.1). Sprytniejsi użytkownicy systemu mogą jeszcze odszukać informacje o tym, jaki podmiot jest abonentem domeny, w bazie WHOIS2, w której zapisane są informacje o abonentach domen. Oczywiście można to zrobić tylko wtedy, gdy domena jest firmowa, tzn. nie jest zarejestrowana na osobę prywatną. Dane osób prywatnych rejestrujących domeny nie są widoczne we WHOIS (są ukrywane). Przykładowo w bazie tej można zobaczyć, kto jest właścicielem domeny mbank.com.pl, ale już w przypadku domeny zarejestrowanej na osobę prywatną dowiesz się niewiele:

1

Zobacz na przykład http://m.onet.pl/biznes/4933914,detal.html.

2

http://dns.pl/cgi-bin/whois.pl

IDENTYFIKACJA STRON W BIZNESIE

|

167

Rysunek 7.1. Dane firmy w certyfikacie SSL NAZWA DOMENY: mbank.com.pl typ abonenta: organizacja [...] utworzona: 2000.09.05 13:00:00 ostatnia modyfikacja: 2004.12.03 08:31:42 koniec okresu rozliczeniowego: 2012.09.04 14:00:00 opcja: brak ABONENT: firma: BRE BANK S.A. Ulica: UL. SENATORSKA 18 miasto: 00-950 WARSZAWA lokalizacja: PL telefon: +48.22829000 ostatnia modyfikacja: 2005.04.22

Można więc powiedzieć, że klient w najlepszym przypadku ma aż trzy możliwości sprawdzenia tożsamości sprzedawcy. Warto zadbać o wiarygodne informowanie o sobie, bo buduje to zaufanie do Ciebie jako podmiotu e-handlu i składa się na Twoją reputację.

168

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

ZIDENTYFIKOWANY UŻYTKOWNIK W przypadku e-commerce pod pojęciem identyfikowania użytkownika będą kryć się dwa zagadnienia: • potwierdzenie intencji użytkownika, • zidentyfikowanie podmiotu — osoby fizycznej bądź prawnej — jako strony transakcji.

Potwierdzanie intencji Potwierdzenie intencji użytkownika będzie miało miejsce wtedy, gdy niekoniecznie będziesz chciał mieć pewność, kim jest użytkownik, ale ważne będzie dla Ciebie to, czy ma on określoną intencję. Załóżmy, że użytkownik chce się zapisać na newsletter, który jest częścią Twojego biznesu. Jeśli poda swój adres e-mail, wyrazi intencję jego otrzymywania. Ale przecież może on podać dowolny adres, także cudzy, zapisując na newsletter osobę, która być może sobie tego nie życzy. Aby potwierdzić intencje, wysyłasz więc na wskazany adres e-mail z prośbą o potwierdzenie, którego można dokonać, klikając np. na załączony link. W niektórych przypadkach Ustawa o świadczeniu usług drogą elektroniczną daje prawo do wymagania od usługobiorcy tzw. danych niezbędnych do świadczenia usługi (art. 18, ust. 3). Należy jednak przy tym pamiętać także o ograniczeniu tego prawa w przypadku, gdy usługa jest odpłatna — wówczas usługodawca ma obowiązek umożliwić korzystanie z niej lub uiszczenie za nią opłaty w sposób anonimowy albo przy użyciu pseudonimu. Nie zmienia to faktu, że podanie danych przez usługobiorcę może okazać się niezbędne, gdy wynika to z innych ustaw, choćby ze względów rozliczeniowych i podatkowych (np. podanie ich na potrzeby wystawienia faktury). Tak samo jak w przypadku newslettera postępuje się w przypadku rejestracji w systemie e-commerce, jeśli chce się mieć pewność, że

IDENTYFIKACJA STRON W BIZNESIE

|

169

zarejestrowała się w nim ta osoba, która miała taką intencję. W formularzu utwórz obowiązkowe pole na adres e-mail (rysunek 7.2).

Rysunek 7.2. Formularz rejestracyjny

Po wypełnieniu formularza niech system automatycznie wyśle na podany adres e-mail z prośbą o jego zatwierdzenie (żeby aktywować konto, kliknij na link): Jan, please validate your email address Welcome to CouchSurfing, Jan! To activate your account, please validate your email by clicking this link, or pasting the address into your internet browser: http://www.couchsurfing.org/register/validate_email/85839c86aa0b656c098f1 dae6ec08eac If you have any problems, contact us for help. The CouchSurfing Team

Są też przypadki, kiedy klient życzy sobie dokonać zakupu bez rejestrowania się. Prawdziwość podanych przez niego danych nie będzie Cię martwić, jeśli zapłaci on z góry — skoro wniósł opłatę, to w jego interesie jest, aby podać prawdziwe dane do dostawy (rysunek 7.3).

170

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Rysunek 7.3. Zakupy bez rejestracji w Allegro

Potwierdzanie tożsamości podmiotu Niekiedy jednak jest dla Ciebie ważne, aby zweryfikować tożsamość użytkownika i mieć pewność, że jest on rzeczywiście osobą, za którą się podaje. Przykładami systemów e-commerce, w których weryfikowana jest tożsamość posiadacza konta, są serwisy bankowości elektronicznej, platforma aukcyjna Allegro czy ePUAP. W wielu serwisach pozwala się na założenie konta, a dopiero potwierdzenie tożsamości pozwala ustalić status konta jako wiarygodnego. Bardzo dobrym tego przykładem jest wspomniany wcześniej serwis CouchSurfing. Zwykłe konto można w nim założyć, wypełniając formularz na stronie i potwierdzając intencję e-mailem (co jednocześnie potwierdza, że jest się we władaniu skrzynki pocztowej), ale aby użytkownik mógł uzyskać status wiarygodnego, musi udowodnić, że podane imię, nazwisko oraz adres są prawdziwe.

IDENTYFIKACJA STRON W BIZNESIE

|

171

Dane te weryfikuje się następująco. Najpierw należy dokonać wpłaty kartą płatniczą wystawioną na imię i nazwisko posiadacza konta (w ten sposób uzyskuje się pewność co do imienia i nazwiska). W odpowiedzi zostaje na jego adres wysłana kartka pocztowa — przykładowa poniżej na rysunku 7.4.

Rysunek 7.4. Kod weryfikacyjny wysłany kartką pocztową przez CouchSurfing

Po otrzymaniu kartki należy przepisać podany na niej kod weryfikacyjny. W ten sposób prowadzący serwis zyskują pewność, że adres pocztowy, na jaki została wysłana kartka, jest prawdziwy. Inną formą weryfikacji tożsamości użytkownika systemu jest wydawanie identyfikatora konta i hasła po sprawdzeniu tożsamości podczas bezpośredniego kontaktu (np. w oddziale banku) — tak jest w sporej części systemów e-commerce o charakterze B2B.

172

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Uwierzytelnianie użytkownika W systemach informatycznych należy rozróżniać, a co za tym idzie rozpoznawać użytkowników. Należy zwrócić uwagę, że identyfikacja w systemie to nie to samo co identyfikacja „w realu” — jedno z drugim ma dość luźny związek. Przykładowo w świecie rzeczywistym tożsamości użytkownika systemu nie będziesz weryfikował (tj. nie musisz mieć pewności, że to konkretny Jan Kowalski; może on podać jako imię i nazwisko Miś Uszatek), ale chcesz identyfikować go w systemie po to, aby wiedzieć, jakie akcje Miś Uszatek w nim podejmuje (nazywa się to rozliczalnością). Każdy, kto dostaje się do systemu, deklaruje swoją tożsamość (nawet fikcyjną), podając identyfikator, a następnie ją potwierdza, tj. uwierzytelnia (np. swoim hasłem). Dzięki temu, że w systemie użytkownicy są zidentyfikowani, można monitorować ich poczynania, uzyskuje się rozliczalność (wiemy, co kto zrobił), a w związku z tym można stosować na przykład cross-selling i up-selling (proponowanie produktów dopasowanych do klienta). Przede wszystkim powiedzmy sobie o tym, za pomocą czego użytkownik systemu może się uwierzytelniać. Może to być: • coś, co wie (login, hasło, plik cookies); • coś, co ma (token, certyfikat); • coś, czym jest, lub to, jaki jest (biometria). Są to tzw. faktory — czynniki uwierzytelniające. Biometria jest w systemach e-commerce w zasadzie niespotykana, natomiast pozostałe dwa (a szczególnie ten pierwszy) są szeroko rozpowszechnione. Stosowanie identyfikatora użytkownika, tzw. loginu, oraz hasła to najbardziej popularna i najłatwiejsza w implementacji metoda uwierzytelniania. Jeśli system jest wyjątkowo istotny i dostęp do niego należy szczególnie chronić, stosuje się tzw. two-factor authentication,

IDENTYFIKACJA STRON W BIZNESIE

|

173

czyli uwierzytelnianie dwuskładnikowe. Inaczej mówiąc, jest to potwierdzenie deklarowanej tożsamości na dwa sposoby. Można się z nim spotkać na przykład przy zdalnym dostępie do systemów firmowych, a na co dzień jest stosowane w bankowości elektronicznej, przy czym tam drugi czynnik uwierzytelniający stosowany jest do autoryzacji (potwierdzenia uprawnienia do wykonania operacji, transakcji). Tutaj należałoby jeszcze wyjaśnić, czym się różni uwierzytelnienie i autoryzacja. Uwierzytelnienie to potwierdzenie cyfrowej tożsamości (nawet jeżeli jest ona fikcyjna). Podobnie jest w świecie rzeczywistym. Wyobraźmy sobie, że ktoś przychodzi na kontrolę do firmy. Przedstawia się, mówiąc Nazywam się Jan Kowalski (identyfikuje się), i potwierdza ten fakt, okazując na przykład dowód osobisty (uwierzytelnia się). Autoryzacja jest zaś potwierdzeniem uprawnienia do wykonania określonej czynności, operacji — Ja jestem Jan Kowalski. Proszę, oto dowód. A oto dodatkowy dokument potwierdzający moje uprawnienia do kontroli. Do banku logujesz się najczęściej, podając identyfikator i hasło (coś, co wiesz), transakcje są natomiast autoryzowane hasłami jednorazowymi (OTP — ang. one time password), którymi są hasła SMS lub hasła z listy haseł jednorazowych (coś, co masz).

Certyfikaty cyfrowe w systemie e-commerce W przypadku systemu e-commerce o charakterze B2B (używanego między firmami; np. w handlu hurtowym albo w przypadku innej ścisłej współpracy) warto rozważyć uwierzytelnianie klientów za pomocą certyfikatów X.509. Uwierzytelnianie (sprawdzanie tożsamości) może się wówczas odbywać wyłącznie przy użyciu certyfikatów, jak również można je traktować jako drugi czynnik uwierzytelniający. Obsługa certyfikatów w PHP możliwa jest poprzez zmienne serwera Apache. Dzięki nim można „wyciągnąć” wszystkie informacje z podanego certyfikatu:

174

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

Rysunek 7.5. Uwierzytelnianie użytkownika za pomocą certyfikatu zainstalowanego na jego komputerze foreach ($_SERVER as $klucz=>$klucz_wartosc) { print $klucz. " = " .$klucz_wartosc. "
"; }

W wyniku realizacji tego kodu zostaną wyświetlone wszystkie zmienne serwera. Tutaj zaprezentujemy tylko te, które tyczą się SSL i certyfikatu klienta: HTTPS = on SSL_TLS_SNI = ecommerce SSL_SERVER_S_DN_C = PL SSL_SERVER_S_DN_ST = Some-State SSL_SERVER_S_DN_O = Wlasne centrum CA SSL_SERVER_S_DN_OU = Ecommerce i tym podobne SSL_SERVER_S_DN_CN = ecommerce SSL_SERVER_S_DN_Email = [email protected] SSL_SERVER_I_DN_C = PL

IDENTYFIKACJA STRON W BIZNESIE

|

175

SSL_SERVER_I_DN_ST = Some-State SSL_SERVER_I_DN_L = Warszawa SSL_SERVER_I_DN_O = Wlasne centrum CA SSL_SERVER_I_DN_OU = Ecommerce CA SSL_SERVER_I_DN_Email = [email protected] SSL_VERSION_INTERFACE = mod_ssl/2.2.20 SSL_VERSION_LIBRARY = OpenSSL/1.0.0e SSL_PROTOCOL = TLSv1 SSL_SECURE_RENEG = true SSL_COMPRESS_METHOD = NULL SSL_CIPHER = DHE-RSA-CAMELLIA256-SHA SSL_CIPHER_EXPORT = false SSL_CIPHER_USEKEYSIZE = 256 SSL_CIPHER_ALGKEYSIZE = 256 SSL_CLIENT_VERIFY = NONE SSL_SERVER_M_VERSION = 3 SSL_SERVER_M_SERIAL = 01 SSL_SERVER_V_START = Jan 4 21:36:11 2012 GMT SSL_SERVER_V_END = Jan 3 21:36:11 2013 GMT SSL_SERVER_S_DN = /C=PL/ST=Some-State/O=Wlasne centrum CA/OU=Ecommerce i tym podobne/CN=ecommerce/[email protected] SSL_SERVER_I_DN = /C=PL/ST=Some-State/L=Warszawa/O=Wlasne centrum CA/OU=Ecommerce CA/[email protected] SSL_SERVER_A_KEY = rsaEncryption SSL_SERVER_A_SIG = sha1WithRSAEncryption

Można wyobrazić sobie serwis, do którego użytkownik loguje się za pomocą certyfikatu, a gdy go nie posiada, przy użyciu innych środków, np. identyfikatora i hasła. Aby było to możliwe, dyrektywa SSLVerifyClient powinna mieć wartość optional zamiast require. Poniższy kod sprawdza, czy klient został zweryfikowany poprzez certyfikat — jeśli tak, przenosi go na stronę /secure/index.php, a jeśli nie, zostaje on przekierowany na /unsecure/index.php3.

Można też sobie wyobrazić, że strona widoczna po zalogowaniu się bez uwierzytelnienia się certyfikatem zawiera pewną liczbę modułów, ale niektóre moduły będą widoczne (dostępne), tylko jeśli wcześniej użytkownik uwierzytelnił się przy użyciu certyfikatu. To rozwiązanie można wykorzystać na wiele różnych sposobów, trzeba jednak przyznać, że pomimo wielu potencjalnych korzyści rzadko jest ono stosowane. W dużych firmach często w systemach B2B stosuje się dwa faktory, przy czym drugim jest zwykle token albo jednorazowe hasło SMS. Są to jednak rozwiązania dość kosztowne. Certyfikat opisywany w tym podrozdziale, jeśli zostanie zastosowany jako drugi czynnik, jest rozwiązaniem znacznie tańszym — z jednej strony mamy faktor coś, co wiesz (identyfikator i hasło), a z drugiej dodatkowy czynnik, czyli coś, co masz (certyfikat klienta).

Rozdział 8.

KONTA I HASŁA

W poprzednim rozdziale pisaliśmy o tym, kiedy i w jakim zakresie należy identyfikować użytkownika systemu e-commerce. W ramach zarządzania kontami użytkowników powinniśmy pamiętać o niektórych wymogach narzucanych przez obowiązujące prawo i dobrych praktykach takich jak nieprzechowywanie haseł użytkowników w postaci jawnej (możliwej do odczytania). Raz uwierzytelnionego (zalogowanego) użytkownika będą później uwierzytelniać sesje, które niekiedy są zapamiętywane w specjalnych plikach (tzw. ciasteczkach). To dzięki nim serwisy internetowe mogą pamiętać odwiedzających, czasami nawet przez tygodnie, dlatego w tym rozdziale poruszymy zagadnienia związane z zarządzaniem sesjami.

DATA WPROWADZENIA DANYCH Jeśli chodzi o konta i hasła, to prawo niewiele nakazuje bezpośrednio poza tym, że strony dokonujące transakcji muszą być zidentyfikowane, o czym zapewne pamiętasz po lekturze rozdziału poświęconego aspektom prawnym. Dość ciekawe wymagania wynikają z rozporządzenia do ustawy o ochronie danych osobowych. Mówi ono, że (§7): • Dla każdej osoby, której dane osobowe są przetwarzane w systemie informatycznym — z wyjątkiem systemów służących do przetwarzania danych osobowych ograniczonych wyłącznie do edycji tekstu w celu udostępnienia go na piśmie — system ten zapewnia odnotowanie:

178

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

a) daty pierwszego wprowadzenia danych do systemu; b) identyfikatora użytkownika wprowadzającego dane osobowe do systemu, chyba że dostęp do systemu informatycznego i przetwarzanych w nim danych posiada wyłącznie jedna osoba; c) źródła danych w przypadku zbierania danych nie od osoby, której one dotyczą; [...] • Odnotowanie informacji, o których mowa w ust. 1 pkt 1 i 2, następuje automatycznie po zatwierdzeniu przez użytkownika operacji wprowadzenia danych. Mało tego — zgodnie z rozporządzeniem dla każdej osoby, której dane są przetwarzane w systemie, musi być możliwe sporządzenie i wydrukowanie raportu zawierającego rozmaite dane. Zatem na etapie projektowania systemu musisz zadbać o to, aby w tabelach z informacjami o jego użytkownikach znalazły się informacje, które pozwolą na przygotowanie takiego raportu. Jego funkcje może pełnić część serwisu O mnie, gdzie użytkownik będzie mógł zobaczyć, jakie jego dane osobowe są przetwarzane. W tabeli informacji o użytkownikach warto umieścić dodatkową kolumnę zawierającą informację o tym, kiedy pierwszy raz wpisano dane osobowe. Można to zrobić automatycznie poprzez aplikację, wpisując przy dodawaniu nowego użytkownika uzyskane wartości przy użyciu funkcji NOW(): INSERT INTO konta_użytkowników (data_wprowadzenia) VALUES NOW()

Można też użyć tzw. triggera bazodanowego: DELIMITER // CREATE TRIGGER dane_osobowe BEFORE INSERT ON konta_użytkowników FOR EACH ROW BEGIN

KONTA I HASŁA

|

179

SET NEW.data_wprowadzenia = NOW(); END // DELIMITER ;

W efekcie każde wstawienie rekordu z danymi („insert”) spowoduje odłożenie w tabeli informacji o tym, kiedy dane użytkownika wpisano po raz pierwszy (kiedy się on zarejestrował). Informacje o źródle danych — podobnie jak informacje o identyfikatorze — można pominąć, jeśli konta w systemie będą zakładać (rejestrować) sami jego użytkownicy. Oczywiście przykład ten nie uwzględnia update’ów (aktualizacji danych), ale nie o to chodzi w ustawie — nie nakazuje ona archiwizowania informacji o tym, kiedy dane aktualizowano, tylko o pierwszym ich wprowadzeniu do systemu informatycznego. Z dwóch podanych wyżej sposobów trigger jest o tyle wygodniejszy, że można za jego pomocą śledzić więcej zdarzeń, a także audytować zmiany. Przykładowo jeśli użytkownik zmodyfikuje swoje dane, to zanim nowe zostaną zapisane, stare może automatycznie zapisać w innej tabeli (i w ten sposób przechowywać historię zmian). Korzystając np. z triggera BEFORE UPDATE, można używać prefiksów OLD i NEW — OLD.kiedy to dane przed aktualizacją, a NEW.kiedy po. Wyzwalacze mogą być wyzwalane przed lub po zdarzeniu (BEFORE, AFTER), natomiast zdarzenia, na jakie mogą reagować, to INSERT, UPDATE i DELETE.

HASZ ZAMIAST HASŁA Już kilka razy podkreślaliśmy, że haseł nie należy przechowywać w systemie. Ale jak to? Przecież użytkownicy będą się logować, podając hasła. Da się jednak zrobić tak, aby nie były one przechowywane w czystej formie (określanej mianem plain text), a mimo to uwierzytelniać użytkowników za ich pomocą. Jeśli haker uzyska dostęp do haseł w wyniku włamania do systemu, będzie mógł je

180

|

BEZPIECZEŃSTWO SYSTEMU E-COMMERCE

wykorzystać, np. logując się z wykorzystaniem danych określonych osób (może to robić przez długi czas, a Ty będziesz miał przez to niezły bałagan). Użytkownicy często mają jednakowe hasła do wielu usług i może się okazać, że hasło, które pochodzi od Ciebie, nadaje się także do ich poczty elektronicznej, gadu-gadu, profilu na Facebooku etc. W takim przypadku nie możesz mieć pewności, że w razie wycieku haseł ktoś Cię nie pozwie do sądu i nie będzie żądał odszkodowania za skutki włamania do jego poczty. Ze względu na bezpieczeństwo i z potrzeby budowania zaufania użytkowników hasła należy więc przechowywać w systemie w formie niejawnej. W tym celu używa się tzw. haszy. Hasz jest określeniem tzw. jednokierunkowej funkcji skrótu, którą można porównać w pewnym sensie do jednokierunkowego szyfrowania polegającego na tym, że da się szyfrować, ale nie można odszyfrowywać. Jest ona bardzo przydatna na przykład przy sprawdzaniu integralności danych, o czym już pisaliśmy w rozdziale poświęconym bezpieczeństwu transmisji. Hasz w systemie operacyjnym można wyliczyć, korzystając z narzędzia OpenSSL lub gotowych programów. Oto przykład: ~$ echo -n "HasloUsera1#" | md5sum 11ce913cf75c591de0df2e33044018f7 ~$ echo -n "HasloUsera1#" | openssl sha1 cef58808dbda91a742fd1c5c030cde37ecdbe1bd

Jak widzisz, w przypadku tego samego algorytmu i takich samych danych wynik funkcji mieszającej będzie zawsze taki sam. Jeśli dane się zmienią (choćby trochę), wynik będzie zupełnie inny. W PHP hasz z tekstu można utworzyć przy użyciu funkcji hash(), z pliku zaś, korzystając z hash_file():

Tworząc konto użytkownika, zamiast zapisać w bazie danych jego hasło, zapisujesz wyliczony z niego hasz. Podczas logowania wyliczony z podanego hasła hasz porównujesz z tym zapisanym w bazie — jeśli są zgodne (takie same), użytkownik jest uwierzytelniany, gdyż podał prawidłowe hasło. Przykładowe logowanie może wyglądać następująco: