9:17
16/1/2019

Katalog na webserwerze zawierający poufne informacje został omyłkowo udostępniony publicznie i zindeksowany w Google — takich historii znamy sporo. Wbrew pozorom zdarzają się one nie tylko małym firmom bez zaplecza IT. Podobną wpadkę zaliczył także Freshmail.pl, bardzo dobrze znany dostawca usług z zakresu e-mail marketingu.

Głębokie ukrycie bazy danych

Ta historia zaczyna się w październiku 2018 roku. Jeden z naszych Czytelników (Mariusz) przyjrzał się stronie Freshmail.pl pracującej na WordPressie, bo zmusiła go do tego sytuacja zawodowa.

mój obecny pracodawca właśnie z [Freshmaila] migruje do konkurencji – tak właśnie trafiłem na powyższy błąd (weryfikując za i przeciw) oraz studiując dokładniej API (…) systemu.

Oto jeden z katalogów na który trafił Mariusz, a który był publicznie dostępny:

Po nitce do kłębka… i można było trafić na:

W którym to Mariusza najbardziej zainteresował katalog backups. Tam znajdował się interesujący plik SQL.

Znamy tę wtyczkę do “backupu” WordPressa. To pełna kopia bazy serwisu.

Natychmiastowe zgłoszenie i błyskawiczna odpowiedź

Mariusz postanowił zgłosić sprawę Freshmailowi. Oto co napisał w swoim zgłoszeniu:

Z powyższych plików można wyciągnąć kilka ciekawych informacji odnośnie struktury firmowej strony, adresy email itd. Myślę, że dla średnio ogarniętego script kiddie wystarczy aby trochę namieszać na Państwa stronie (wstrzyknąć niebezpieczny kod, złamać hasło administratora – baza z 5 lipca 2018 r. lub wykorzystać stronę do kampanii phishingowej – bazując na Państwa marce. Scenariuszy może być naprawdę sporo, mimo bezpośredniego połączenia z systemem freshmail). Nie upubliczniam tego znaleziska – google to już zrobiło za mnie;) Każdemu zdarzają się błędy – pierwsza dewiza nie szkodzić ;) Dlatego proszę o załatanie luki oraz informację gdy strona będzie już “bezpieczna”, a powyższy przypadek możliwy do opisania.

Mariusz miał rację. Plik z backupem bazy jest kompletną kopią tego, do czego dostęp ma WordPress. A Freshmailowa instancja WordPressa miała kilka formularzy, w których klienci mogli zostawiać swoje dane. Mariusz pokazał nam zrzuty, które zrobił na własny użytek i przyznał, że Freshmail szybko i profesjonalnie zareagował. Oto cytat z e-maila, jaki Mariusz otrzymał od CEO Freshmaila, Pawła Sali:

Jeszcze raz chciałem Panu podziękować za profesjonalne zgłoszenie naszej luki bezpieczeństwa. Podjęliśmy następujące kroki:
– Analiza dziennika logów serwera WWW
– Analiza wszystkich plików i danych przechowywanych w bazie danych w ramach bloga oraz strony firmowej
– Zabezpieczenie wszystkich plików zawierających wrażliwe danych poprzez usunięcie do nich dostępu
– Wprowadzenie dodatkowych reguł bezpieczeństwa w dostępie do plików serwera z poziomu firmy zapewniającej hosting
– Aktualizacja silnika bloga (WordPress) oraz używanych pluginów do najnowszych wersji narazie w środowisku deweloperskim, następnie w produkcyjnym
– Zmiana kluczy API używanych do integracji z pozostałymi serwisami (np. systemem FreshMail)
– Wyłączenie wszystkich nieużywanych kont użytkowników
– Wymuszenie zmiany haseł dla wszystkich pozostałych użytkowników
– Ograniczenie dostępu do panelu administratora strony internetowej do połączeń z adresów IP biura firmy FreshMail Sp. z o. o.
– Powiadomienie Prezesa Urzędu Ochrony Danych Osobowych zgodnie z art 33 RODO.

Dodatkowo przygotowujemy konkurs na audyt bezpieczeństwa strony Internetowej ze stron firm zajmujących się bezpieczeństwem oraz rozpatrujemy przeniesienie strony na inne, bardziej bezpieczne, środowisko. Jednocześnie pragnę poinformować o programie bug bounty, który posiadamy u nas w firmie. Chcielibyśmy się z Panem skontaktować w celu ustalenia szczegółów wysokości i formy wynagrodzenia.

Bez dwóch zdań, reakcja jest poprawna. Hardening, reset kluczy i wymuszenie zmiany haseł użytkownikom. Miłym akcentem jest oferta wynagrodzenia zgłaszającego. Nie każdą firmę stać na taki gest! Brawo Freshmail!

Niestety, jak poinformował nas Mariusz, po tej wiadomości “kontakt z Freshmailem umarł“… Firma miała procesować jego zgłoszenie w ramach bug-bounty, ale przestała odpowiadać na próby kontaktu Mariusza, choć ten próbował uderzać i na adresy działów i do poszczególnych pracowników firmy.

Postanowiliśmy więc pomóc Mariuszowi w odnowieniu kontaktu, a przy okazji spytaliśmy Freshmail m.in. co było w pliku SQL znalezionym przez Mariusza.

Freshmail powiadomił UODO ale nie klientów

CEO Freshmaila, Paweł Sala, odpowiedział nam, że publicznie dostępnym backupie bazy znajdowało się…

… 1106 rekordów danych osobowych osób biorących udział w eventach organizowanych przez FreshMail – swego czasu rejestracja na eventy była robiona za pomocą platformy WordPress. Zakres danych to:
– imię, nazwisko,
– adres email,
– numer telefonu,
– stanowisko,
– nazwa firmy,
– adres IP.

Paweł Sala zapewnił nas, że wyciek został zgłoszony do UODO w terminie 72 godzin, natomiast nie poinformowano o wycieku osób, których dane wyciekły.

Czy to dobra decyzja?

Wielu z Was pewnie teraz odczuwa chęć krzyknięcia “Skandal! Hańba!” ;) Ale powoli… Pamiętajcie, że obowiązek informowania “ofiar” istnieje tylko wówczas, jeśli wyciek wiąże się z wysokim ryzykiem naruszenia praw i wolności. Tutaj, wedle Freshmaila taka sytuacja nie nastąpiła. I Paweł Sala sensownie tłumaczy to w ten sposób:

Po przeanalizowaniu zdarzenia określiliśmy poziom ryzyka na „średni” w związku z powyższym nie informowaliśmy osoby znajdujące się ww. backupie. Jedocześnie poprosiliśmy osobę która pobrała o skasowanie ww. pliku – wyjaśnił Paweł Sala.

Jesteśmy w stanie zaakceptować taką decyzję. Raz, że dane w wycieku to dane przede wszystkim różnych pracowników firm (firmowe e-maile i numery telefonów), więc są to informacje, które nierzadko są znane szerszemu kręgowi osób. Dwa, że wedle analizy Freshmaila, dostęp do pliku z bazą, choć był publiczny, to nie został wykorzystany przez nikogo poza Mariuszem. I jeszcze jednym adresem IP.

Luka w zabezpieczeniu strony została wykryta przez naszego klienta, który zgłosił na takie naruszenie jednocześnie informując redakcje serwisu niebezpiecznik.pl o takim fakcie. Odnotowaliśmy dwukrotne pobranie ww. pliku. Zakładamy, że pobranie zatem nastąpiło przez Was (redakcję Niebezpiecznika) oraz osobę zgłaszającą.

Interesujące założenie, choć wydaje nam się, że Freshmail nie ma 100% pewności, czy to byliśmy my. Nawet my takiej pewności nie mamy. Pytaliśmy co prawda w redakcji, czy ktokolwiek pobierał ten plik. Ale nikt się do tego nie przyznał. Nie znamy też adresu IP, który pojawił się w logu serwera — wtedy być może łatwiej byłoby nam potwierdzić, czy należy do nas.

Nawiasem mówiąc jest to drugi raz, gdy spotykamy się z oceną ryzyka bazującą na bardzo ryzykownym przekonaniu, że nie ma powodu do paniki, bo “nasze dane pobrał tylko Niebezpiecznik”. Nie jesteśmy pewni czy to właściwe podejście do sprawy. Nie dlatego, że coś niemoralnego z danymi uzyskiwanymi w ramach dziennikarskiego śledztwa robimy, ale dlatego, że to po prostu mógł być nie nasz adres IP. W większości spraw w ogóle żadnych danych nie pobieramy, bo wbrew temu co niektórym może się wydawać, nie zawsze trzeba pobierać jakiekolwiek dane z czyjegoś serwera, aby potwierdzić autentyczność wycieku lub dziur, którą zgłasza nam Czytelnik.

Wracając do rzeczy — nasz kontakt sprawił, że Mariusz znów jest zadowolony ze współpracy z Freshmailem i jak nam właśnie napisał,

Muszę przyznać, że działacie bardzo sprawnie :) Gratuluje. Sprawa ruszyła z kopyta. Będzie parę uśmiechów więcej na tym świecie. Dzięki i pozdrowienia dla całej redakcji.

Głębokie ukrycie to …płytki błąd

Katalogi niezabezpieczone przed publicznym dostępem to problem, który wraca jak bumerang. Często pisaliśmy o nich w naszych zestawieniach wpadek na uczelniach. Zdarza się to również sklepom (na co bardzo ciekawie reagują ich “administratorzy”), a nawet firmom obsługującym szpitale i przetwarzającym wrażliwe dane medyczne. Ciekawy był też przypadek ujawnienia folderu dostępnego przez FTP w systemu dla szkół.

Tych i wielu innych błędów można łatwo uniknąć.

Jak zabezpieczyć webaplikację przed wyciekami?

Wystarczy w odpowiedni sposób podejść do budowy swojej webaplikacji i regularnie ją testować. Łatwo powiedzieć, trudniej zrobić. Ale nie od razu oznacza to, że trzeba wynająć profesjonalnego zespołu pentesterów i wydać kilkadziesiąt tysięcy na gruntowną analizę zabezpieczeń.

W zabezpieczeniu webaplikacji całkiem nieźle radę dać mogą “wewnętrzni”, firmowi testerzy QA i programiści. Przy użyciu odpowiednich narzędzi i łatwych do wdrożenia w cykl rozwoju oprogramowania metodyk, które — zgodnie z zasadą Pareto — przekują 20% wysiłek pracowników w spełnienie 80% wymogów bezpieczeństwa.

0day na IE

O tych narzędziach, metodykach i innych quick-winach (oraz o tym jak uzyskać brakujące 20% security) opowiadamy na naszym bestsellerowym szkoleniu z Atakowania i Ochrony Webaplikacji. Niebawem odbędzie się ono w Warszawie (24-25 stycznia) i Krakowie (4-5 lutego). Na oba terminy zostało jeszcze tylko kilka wolnych miejsc, a zapisać się warto. To szkolenie realizujemy od 9 lat i jest naprawdę mocno dopieszczone.

Przez 2 dni dostaniecie od nas masę praktycznej wiedzy i porad z tematu bezpieczeństwa webaplikacji, które pozwolą skutecznie zabezpieczyć Waszą webaplikację przed atakami i wyciekami. Trochę się też spocicie, bo 80% szkolenia to warsztaty, gdzie na żywo hackujemy “dziurawy” sklep internetowy. Zresztą, sami poczytajcie opinie uczestników ostatnich edycji tego szkolenia one mówią same za siebie :)

Przeczytaj także:

35 komentarzy

Dodaj komentarz
  1. Najlepiej wywalic autoindex module z apache .

    • Najlepiej zmienić webserwer na lżejszy (pod względem zasobów procka), na przykład nginx albo lighttpd :)
      Coraz częściej mam wrażenie, że ludzie stawiają tę krowę (apache) tylko dlatego, że dużo na ten temat poradników, a lepsze alternatywy przecież też mają dokumentację ;)

    • @Lukasz032 z tym ze nie kazdy jest nolife i nie robi wszystkiego dla idei a sa miejsca w ktorym jest wymagany Apache chociazby ze wzgledu na htaccess a zasobow jest duzo wiec nie ma znaczenia optymalizacja.

    • Optymalizacja ma jednak znaczenie, jeżeli spojrzymy na stronę z punktu widzenia wzrostu liczby użytkowników ponad normę (nawet jednorazowy pik może namieszać) czy ewentualnego DDoSa. Jeżeli serwer szybciej skończy obsługiwać jednego usera, szybciej zajmie się następnym, co przy liczbach połączeń rzędu setek na sekundę jest jednak kluczowe.

      PS. Z tego co kojarzę .htaccess może być obsługiwany przez alternatywne serwery ;)

    • Moje ulubione usprawiedliwienie braku wiedzy, umiejętności – po prostu, kompetencji – “nie każdy jest nolife”. To, może, swoje life powiąże z zawodowym skręcaniem długopisów (bez urazy dla skręcających) – tam potrzeby samodokształcania się są znacząco mniejsze.

    • Kto powiedział, że serwer stał na Apache ;) Mylne wnioski wysuwasz waćpanie. Serwer stał i pewnie nadal jest na nginx. Znając życie to był główny powód wpadki – brak odpowiedniej konfiguracji nginx.conf. Oczywiście drugą kwestią są backupy dostępne z poziomu serwera webowego – co nie powinno mieć miejsca. Nie potrzeba do tego żadnej wtyczki – kilka linijek kodu + cron załatwia sprawę dla całego serwera – zwłaszcza na VPSie.
      Jak widać zmiana serwera na wydajniejszy niesie ze sobą inne zagrożenia, które trzeba brać pod uwagę / być ich świadomym. Wydajność nie może wpływać na zmniejszenie bezpieczeństwa. Poza tym połączenie Apache + nginx jako proxy dla większości ludzi sprawdzi się idealnie. Nie zawsze jest możliwość wdrożenia samego nginx. Zresztą wydajność danej aplikacji zależy od wielu czynników – temat rzeka.

    • Damn ile was z tu elektrody przywiało

  2. Szkolne błędy, jak na stronce jakiegoś typowego klikacza hołdującego zasadzie “wincyj ftyczkuf” i niech się dzieje wola nieba.

  3. Dostęp do katalogów to pierwsza rzecz jaką sprawdzam, gdy trafię na nową stronę opartą na WP. Czasem można znaleźć ciekawe rzeczy ;) Udało mi się w ten sposób włamać na stronę pewnej bardzo znanej pisarki oraz poznałem listę członków jednego z najbardziej eksluzywnych klubów. Szkoda tylko, że nikt jeszcze mi nie podziękował. Nie dziwię się, że niektórzy wolę sprzedać informacje.

    • Sam napisałeś, że się włamałeś, na to jest paragraf, a nie nagroda.
      Zapewne chodziło Ci o inne słowo ;-)

  4. Tak drobna uwaga. Pokazywanie screenów kodu jest kompletnie nieprzydatne osobom nie(do)widzącym.

    Istnieje wiele lepszych sposobów, z na czele.

  5. “bardzo dobrze znany dostawca usług z zakresu e-mail marketingu” – tłumacząc to na język polski: znaczy się spam rozsyłają.

  6. “W zabezpieczeniu web-aplikacji całkiem nieźle radę dać mogą “wewnętrzni”, firmowi testerzy QA i programiści” – ha, pozdrawia was programista & administratora & informatyk zakładowy w jednym do obsługi ponad 120 osób i kilkunastu aplikacji za 2,5k netto :)

    • Jesli ktos sie daje dymac w IT za 2500 netto to niezbyt dobrze to o nim swiadczy..

    • Witam…

      Nie przejmuj się komentem @Troos na temat “dymania za 2,5k netto”! Nie każdy jest leszczem na garnuszku starszych i do tego singlem oraz freel(an/e)serem! Wielu takim pismakom, w łepetynie się nie mieści, że są sytuacje w życiu, gdzie nie ma możliwości zmiany miejsca zamieszkania, a w efekcie miejsca pracy! Udowadnia to jedynie, że tego typu wypowiedzi są autorstwa osobników, którzy nigdy SAMODZIELNIE nie prowadzili starań o miejsce zatrudnienia w obszarach gdzie jest niski odsetek wolnych miejsc pracy za wysokie wynagrodzenie! A legendy o wysokich zarobkach, to wszyscy na forach internetowych znają! Podsumowaniem takich legend jest motto jednego z prezesów firmy programistycznej: “Każdego profesjonalnego programistę można zastąpić skończoną ilością studentów”!

  7. @Józef

    Mylisz sie, przez Freshmaila, ExpertSender czy inne GetResponce idą głównie maile transakcyjne, z numerem twojej przesyłki, kuponem rabatowym, newsletterem ze sklepu itp

    • A jaki to problem postawić to samo na webserwerze i wołać z phpa czy innego języka prościutkie mail()?

    • Chociazby dlatego zeby sciagnac z siebie ciezar odpowiedzialnosci jeszcze za dodatkowa usluge jaka jest serwer poczty.. nie patrzysz na to pod katem biznesowym tylko pod geekowskie klepanie serwerka w domu ;) i jeszcze fajnie jakby te maile do kogos docieraly – np posiadaly DKIM.

    • @Lukasz032 – tylko ze jak zrobisz to w sposób jaki opisujesz (z uzyciem phpowej mail() ) to istotnie nie wpłynie to jakoś specjalnie na bezpieczeństwo. Szczególnie przy tym jak większość firm realizuje te praktyki.

      IMHO znacznie lepszym rozwiązaniem jest oddzielenie warstwy aplikacji (php i pochodne) od warstwy pocztowo-usługowej => porządnie skonfigurowany daemon poczty wraz z odpowiednio zbudowanym routingiem poczty obowiązkową weryfikacją potencjalnego nadawcy (i jego praw ), dobrze skrojonym routingiem poczty, stale rozwijanych zabezpieczeń antyspamowych (np. spamassin + wtyczki ) oraz dobrze zrealizowanymi SPFami .
      Zgadzam się tu z Tobą – że nadal jest to rozwiązanie całkowicie możliwe do osiągnięcia w ramach działań średniej wielkości firmy w naszym Kraju.

    • Nie zapominajcie o jednej ważnej kwestii, której nie da się tak łatwo osiągnąć przy własnej konfiguracji serwera pocztowego – możliwość dodania naszego adresu IP lub całej klasy do list RBL (np. w przypadku dużej wysyłki potraktowanej jako SPAM – pomijam powody). Takie firmy mają sporą pulę IP oraz serwerów u różnych usługodawców. Dbają o ich dziewiczą “czystość”. Adresy IP przydzielane są dynamiczne. Cała infrastruktura jest trochę bardziej złożona ;)
      Najczęściej IP jest współdzielone dla kilku użytkowników / kampanii. Istnieje jednak możliwość wykupienia własnej puli adresów IP do wysyłki własnych mailingów – w bardziej rozbudowanych rozwiązaniach. Mail() nie jest najlepszym sposobem na mailing – chyba, że nie liczy się dla ciebie ;) efektywność kampanii w tym Open rate (OR) oraz CTR (Click-through rate). DKIM, DMARC, SPF to jest standard w takich rozwiązaniach.
      Oczywiście nie mówię, że się nie da tego zrobić we własnym zakresie. Jest to jednak nieopłacalne dla małej firmy (wdrożenie, utrzymanie, rozwój). Cały dzisiejszy mailing to głównie marketing automation – zazwyczaj w pakiecie z usługami takich firm.

    • Prawda jest taka, że jak się admin sam tego nie nakonfiguruje aż mu zadziała, to się po prostu tego nie nauczy ;)

    • Czyli Mariusz potwierdza co napisałem: na zlecenie rozsyłają spam. Jest to zresztą w ofercie ich usług na ich stronie, więc nie ma co zaprzeczać.

  8. Dokładnie, szkolne błędy… Raczej nie przystoi to takiej firmie jak freshmail, która chce uchodzić za poważne marketingowe narzędzie a nie producenta spamu.

  9. Tak z prawnego punktu widzenia, to jeżeli w tym backupie były tylko dane pracowników firm (np. służbowe adresy mailowe, służbowe komórki itp.) to RODO nie ma tu nic do tego, bo to rozporządzenie dotyczy danych osób prywatnych przetwarzanych przez wszelkiego rodzaju firmy (bez względu na formę prawną działalności)… gdy relacja jest typu B2B to zastosowanie mają inne zasady ;)

  10. Szkolenia niebezpiecznika są rewelacyjne, jednak nigdy nie zrozumiem dlaczego tylko 2 dni. Byłem na kilku i materiału jest na minimum 3-5. Jedno z najlepszych, na jakich byłem, analiza malware, zasługuje na 5. Jeszcze nikt mnie tak nie rozwalił wiedzą jak prowadzący :) Wręcz czułem się upokorzony.

  11. Hmm….
    [cytat] Wracając do rzeczy — nasz kontakt sprawił, że Mariusz znów jest zadowolony ze współpracy z Freshmailem i jak nam właśnie napisał,
    [cytat wewn Mariusza]
    Muszę przyznać, że działacie bardzo sprawnie :) Gratuluje. Sprawa ruszyła z kopyta. Będzie parę uśmiechów więcej na tym świecie. Dzięki i pozdrowienia dla całej redakcji.
    [/cytat wewn MAriusza]
    [/cytat]
    Czyli jak rozumiem – “Mariusz znów jest zadowolony ze sposobu w jaki …dyscyplinujemy /wpływamy na partnerów z którymi współpracuje ” Co dalej nie bardzo świadczy o samych partnerach :/

    Anway – Good Job Niebezpiecznik !

  12. @Niebezpiecznik
    “Głębokie ukrycie to …płytki błąd

    Katalogi niezabezpieczone przed publicznym dostępem to problem, który wraca jak bumerang.”
    O, w rzeczy samej. ;)
    Już słynny socjotechnik i przy okazji hacker Kevin Mitnick podsumowuje:
    “W czasach prohibicji istniały nielegalne kluby nocne, gdzie strumieniami lał się gin. Klient mógł wejść do środka, pojawiając się u drzwi
    i pukając. Po kilku chwilach w drzwiach otwierało się małe okienko
    i ukazywała się w nim groźna facjata wykidajły. Jeżeli gość był wtajemniczony, wymawiał imię któregoś ze stałych klientów („Przysłał
    mnie tu Joe” mogło czasami wystarczyć). Wówczas bramkarz otwierał
    drzwi i wpuszczał go do środka.
    Prawdziwy problem polegał na znajomości lokalizacji meliny.
    Drzwi były nieoznakowane, a właściciele niespecjalnie palili się do
    wieszania neonów informujących o tym, jak tam trafić. W większości
    przypadków wystarczyło po prostu pojawić się w odpowiednim miejscu,
    aby otwarto przed nami drzwi. Niestety, ten sam rodzaj zabezpieczeń
    jest często stosowany w świecie biznesu, który cofa się tym samym do
    czasów prohibicji.”
    Co ciekawe – te dwa ustępy pochodzą z książki “The art of Deception Controlling the Human Element of Security ” wydanej w 2002 roku [tłum. polskie 2003-2011 II ed.] …
    Już wtedy autor ubolewał nad popularnością czegoś – co teraz moglibyśmy śmiało przyrównać do “płytkiego ukrycia ” z tytułu akapitu autora tegoż artykułu .
    Róznice są kosmetyczne.

  13. Dobrze skonfigurowany fail2ban plus kilka linii kodu do generowania losowych urli i można sobie głęboko i bezpiecznie ukrywać. Wszystko zależy od konfiguracji serwera i chciejstwa administratora.

  14. Freshmail napisał, że zrobił “Wymuszenie zmiany haseł dla wszystkich pozostałych użytkowników”. Nie do końca dla wszystkich- u mnie np nie wymusili zmiany hasła. Chyba że chodzi tutaj o “wszystkich, których dane wyciekły” :)

    • Michał – a jesteś użytkownikiem ich strony formowej? Jak rozumiem zmiana haseł dotyczyła strony w wordpresie a anie aplikacji do maili.

  15. Zakładasz, że sam serwer (jego konfiguracja, oraz konfiguracje wszystkich dodatków i użytych technologii) nie posiadają żadnych “słabszych punktów” i możliwości wydostania się na “główny nurt” oraz szukania rekursywnego …

    Aż przypomina mi się słynny (w 2004/5) roku numer z listami płac i pracowników z dostępem do serwera orka.sejm.gov.pl … tam tez byli wszyscy przekonani że “tego się nie da zrobić”

  16. Zawiadomienie osób których dane osobowe zostały naruszone nie jest wymagane zgodnie z art 34 ust 3 gdy:

    a) administrator wdrożył odpowiednie techniczne i organizacyjne środki ochrony i środki te zostały zastosowane do danych osobowych, których dotyczy naruszenie, w szczególności środki takie jak szyfrowanie, uniemożliwiające odczyt osobom nieuprawnionym do dostępu do tych danych osobowych;

    b) administrator zastosował następnie środki eliminujące prawdopodobieństwo wysokiego ryzyka naruszenia praw lub wolności osoby, której dane dotyczą, o którym mowa w ust. 1 (artykułu 34);

    c) wymagałoby ono niewspółmiernie dużego wysiłku. W takim przypadku wydany zostaje publiczny komunikat lub zastosowany zostaje podobny środek, za pomocą którego osoby, których dane dotyczą, zostają poinformowane w równie skuteczny sposób.

    Oczywiście jest kwestia udowodnienia, że pkt a i b miał tu miejsce w ramach aspektu rozliczalności.

    Pozdrawiam

  17. Mnie interesuje tylko jaką karę zapłacą.

  18. Czy Pana Mariusz mógłby potwierdzić że otrzymał obiecaną nagrodę?

    • Potwierdzam – są na to dowody ;)
      Nagroda została rozdysponowana zgodnie z moimi sugestiami / ustaleniami.

Odpowiadasz na komentarz Szczęsny

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: