Blog “Zakasane rękawy”

Podcast

Audycje » Programowanie na śniadanie » Odcinek #2 » Skrypt

PNŚ #2. Jak poprawić bezpieczeństwo strony jednym meta-tagiem - Content-Security-Policy

Otrzymaj powiadomienie o nowych odcinkach

To jest podcast "Programowanie na śniadanie". Słuchasz odcinka numer 2. Dziś opowiem o mechanizmie Content-Security-Policy, który pozwala programistom aplikacji webowych takim jak my, poprawić bezpieczeństwo strony przy pomocy praktycznie jednej linijki konfiguracji.

intro

Dla kogo jest ten odcinek?

Cześć! Z tej strony Paweł, bardzo się cieszę że zechciałeś lub zechciałaś zajrzeć do tego odcinka podcastu. Na samym starcie chcę przekazać Ci w skrócie o czym będzie, żeby pozwolić Ci ocenić czy warto poświęcić na niego najbliższe kilkanaście minut. Po tym wstępie będzie jingiel i przejdziemy do konkretów i mam nadzieję, że zechcesz zostać do samego końca ;)

W tej audycji opowiem o mechanizmie Content-Security-Policy, który jest związany z bezpieczeństwem aplikacji webowych i stron internetowych, czyli generalnie wszystkiego co tworzymy na przeglądarki internetowe. Jeśli więc interesuje Cię web development, a do tej pory nie spotkałeś albo nie spotkałaś się z tym mechanizmem, albo już nie pamiętasz dokładnie do czego służy, to zachęcam, żeby poświęcić kilka minut na przypomnienie sobie tego tematu.

Ten mechanizm to tak naprawdę jedna linijka konfigurująca bezpieczeństwo naszej aplikacji i ta konfiguracja może siedzieć jako zwykły meta-tag w sekcji <head> strony, albo być przesyłana przez serwer jako nagłówek HTTP.

Postaram się tu prowadzić narrację tak, żeby nie zgubić Twojej uwagi mimo że odcinek może wymagać trochę skupienia i przede wszystkim pokazać pewne problemy z platformą Web, które dziś mamy i które próbujemy rozwiązywać mechanizmami takimi jak właśnie Content-Security-Policy. Będzie też wniosek bardzo pragmatyczny, a mianowicie taki że w nowo stawianych projektach web warto odejść od domyślnego zachowania przeglądarki i określić taką politykę bezpieczeństwa aplikacji, co nałoży na nas trochę restrykcji przy programowaniu, ale w rezultacie pozwoli stworzyć bezpieczniejszą aplikację.

Żeby pokazać faktyczne korzyści dla bezpieczeństwa, w trakcie tego odcinka przedstawię m.in. trzy przykładowe klasy ataków, którym pozwala zapobiec Content-Security-Policy: atak Cross Site Scripting, Cross-Site Styling i Clickjacking i postaram się przystępnie wyjaśnić na czym polegają.

Mam nadzieję, że zachęciłem Cię do słuchania i zapraszam :)

jingiel

Wstęp: dlaczego pozostając przy opcji domyślnej NIE jesteśmy bezpieczni

Przyznam, że jako użytkownik do niedawna postrzegałem aplikacje w przeglądarkach jako wyjątkowo bezpieczne w porównaniu z tymi tradycyjnie instalowanymi na naszych maszynach. Programistyczna intuicja może nam wszystkim dawać takie wrażenie, bo w końcu używamy nowoczesnych przeglądarek, które działają w różnego rodzaju sandboxach, od jakiegoś czasu nie mają już Flasha ani Javy, a jedynie JavaScript który nie daje bezpośredniego dostępu do naszego dysku ani innych uprawnień które by pozwoliły przejąć kontrolę nad naszym laptopem czy innym urządzeniem.

Platforma webowa jest też w centrum uwagi dużych firm technologicznych takich jak Google czy Microsoft i na co dzień widać jak dawne niedogodności i problemy są łatane. My jako programiści piszący aplikacje, możemy dziś załatwić jedną linią kodu CSS lub JavaScript coś, co kilka lat temu wymagało dziesiątek albo setek linijek. Hacki, jakie kilka lat temu za czasów Internet Explorera 8 trzeba było wdrożyć, żeby zgodnie z modą dodać zaokrąglone rogi do przycisku wydają się niedorzeczne dzisiaj, kiedy walczy się raczej o osiągnięcie większej liczby klatek na sekundę w animacjach.

Przy całym tym postępie w świecie aplikacji internetowych zdarzają się jednak sytuacje, kiedy przypominamy sobie że pierwszy standard HTML został opublikowany daawno temu, w 1993 roku , i to dziedzictwo czasem do nas wraca w postaci różnorakich problemów. Możemy spojrzeć na platformę web jak na system, który działa produkcyjnie od ponad 25 lat. Ewoluując nie może sobie za bardzo pozwolić na zmiany, które nie byłyby kompatybilne wstecz, bo zepsułoby to masę istniejących stron i aplikacji.

Jednym z aspektów, które obrywają przez konieczność zachowania kompatybilności wstecz jest bezpieczeństwo. Przykładowo, w praktyce dopiero teraz na naszych oczach dokonuje się zmiana, w której protokół HTTP jest wypierany przez HTTPS. Ten brak szyfrowania, który do niedawna był typowy dla stron internetowych, to jeden z przykładów sytuacji, gdzie nie trzeba szczególnych zdolności hackerskich aby naruszyć prywatność użytkowników stron.

Bezpieczeństwo stron internetowych jest ważne przede wszystkim dlatego, że nasza przeglądarka pomimo tego że chroni nas dziś dość dobrze przed instalacją malware'u na maszynie na której działa, sama może stać się celem ataku innego rodzaju. Jako użytkownicy jesteśmy na ogół zalogowani w co najmniej kilku serwisach z których korzystamy i często dla wygody nie wylogowujemy się z nich tylko po prostu zamykamy zakładkę, pozostawiając sesję logowania aktywną. Jeśli odejdziemy od komputera i ktoś inny w tym czasie otworzy naszą przeglądarkę, to prawdopodobnie bez problemu wejdzie na naszego Twittera, LinkedIna, czy nasz program do zarządzania listą Todo i będzie mógł wykonać akcję w naszym imieniu.

W praktyce w naszym otoczeniu mamy raczej zaufane osoby i problemem nie jest taki lokalny atak bezpośrednio na nas, ale raczej na strony z których korzystamy. Patrząc z perspektywy web developera to mogą być ataki na strony które tworzymy i za których zabezpieczenie jesteśmy odpowiedzialni, dlatego warto przyjrzeć się niektórym z nich. W następnej części, która już za moment, opiszę krótko trzy rodzaje stosunkowo łatwych do zrozumienia i dość łatwych do wykonania ataków na strony czy aplikacje internetowe, a mianowicie:

  • Cross Site Scripting (XSS)
  • Cross-Site Styling, czyli atak na style strony które intuicyjnie mogą wydawać się zupełnie bezpieczną częścią strony
  • Clickjacking

Po tej nadchodzącej sekcji i przedstawieniu problemów przejdę natomiast do rozwiązań, czyli tego jak możemy zapobiec skutkom ataków definiując politykę bezpieczeństwa dla strony przez tytułowy mechanizm Content-Security-Policy.

jingiel

Przykładowe ataki klasy code-injection

Cross Site Scripting

Zacznę od przedstawienia tego czym jest podatność strony na Cross-Site-Scripting. Cross Site Scripting, często oznaczany akronimem XSS, to rodzaj łatwego do popełnienia błędu w aplikacji pisanej na przeglądarki. Ten błąd pozwala osobie o złych zamiarach na dodanie do naszej aplikacji internetowej dodatkowego kodu JavaScript, który wykona się u osoby odwiedzającej stronę w przeglądarce.

Ten błąd jest podobny w naturze do wielu innych błędów które można sklasyfikować jako code-injection, czyli błędów pozwalających na wstrzykiwanie kodu. Najogólniej ujmując błąd typu code-injection pojawia się, kiedy aplikacja wysyła jakieś niezaufane dane, czyli np. takie wprowadzone przez użytkownika, do interpretera. Chyba najpopularniejszym błędem tej klasy jest SQL Injection, ale w przypadku Cross-Site-Scripting interpreterem nie jest silnik bazy danych, ale silnik JavaScript w przeglądarce.

Błąd typu Cross Site Scripting możemy popełnić pisząc już swoją pierwszą aplikację typu "hello world". Przypuśćmy, że w tej prostej aplikacji pytamy użytkownika o imię, które może wpisać w polu tekstowym na stronie, a kiedy je poda i wciśnie przycisk to wyświetlamy tekst typu "Witaj, [imię]" przez JavaScriptową metodę document.write(). W tej sytuacji dajemy użytkownikowi możliwość nadużycia, bo jeśli zamiast swojego imienia wprowadzi tag <script> a w środku fragment kodu JavaScript, to ten kod zostanie dodany do strony i wykonany w przeglądarce tego użytkownika.

Przypuśćmy teraz, że jako programiści zrobimy podobny błąd pisząc system komentarzy np. w sklepie internetowym. Jeśli pozwolimy użytkownikom podczas dodawania komentarza w polu "imię" dokleić skrypt i zachowamy potem takiego stringa w bazie danych żeby go wyświetlać przy komentarzu, to ten może wykonać się u wszystkich użytkowników oglądających ten komentarz i to w kontekście ich sesji. A więc doklejony skrypt będzie miał dostęp do tych samych danych strony, co użytkownik, przypuszczalnie np. numeru karty kredytowej zapisanego w opcjach sklepu internetowego, i będzie mógł wysłać te dane na serwer atakującego.

Mechanizm Content-Security Policy może pomóc rozwiązać ten problem, bo pozwala nam poinstruować przeglądarkę, żeby nie wykonywała żadnego kodu JavaScript zagnieżdżonego w kodzie HTML. Dokument HTML jest typowo dynamicznie generowany w czasie wykonania programu przez aplikację i mocno narażony na błędy programisty. Jedną dyrektywą CSP możemy więc ustalić, że żadne skrypty zdefiniowane w blokach <script> ani w atrybutach elementów HTML takich jak onclick nie będą po prostu wykonywane przez przeglądarkę. W typowym przypadku zechcemy przy tym zachować możliwość wykonywania skryptów które są załączane jako pliki zewnętrzne, ale dla nich możemy również zdefiniować listę domen które są zaufane, na zasadzie whitelisty. Nałożenie takich restrykcji znacznie ogranicza w praktyce możliwość wykonania ataku Cross Site Scripting, bo kod z powodzeniem wstrzyknięty razem z legalnymi danymi w markup strony po prostu się nie wykona.

jingiel

Cross Site Styling

Przed chwilą opisałem na czym polega atak Cross Site Scripting i dlaczego w związku z nim dobrze jest zablokować wykonywanie w aplikacji webowej wszystkich skryptów zagnieżdżonych. Można sobie zadać pytanie, czy innego rodzaju zasoby takie jak np. style CSS lub zewnętrzne czcionki lub obiekty audio i video również powinny być blokowane i czy potencjalny atakujący jest w stanie w jakiś sposób skorzystać np. z wstrzyknięcia do kodu strony dodatkowych styli CSS.

W przypadku wstrzyknięcia na stronę złośliwych styli problemem jest to, że strona może zmienić swój wygląd w sposób który będzie mniej lub bardziej niebezpieczny dla użytkownika. CSS pozwala dziś transformować wygląd strony w bardzo dużym stopniu. Można sobie wyobrazić sytuację, gdzie np. link dodany w komentarzu przez użytkownika jest przez wstrzyknięte style przeniesiony wizualnie gdzieś na górę strony do głównego menu z nawigacją, i w ten sposób atakującemu uda się przekierować część naszych użytkowników na własną podrobioną witrynę. Poprzez CSS można też dodać tekst gdzieś na stronie, który może chociażby ośmieszyć serwis albo obrazić jakąś grupę odbiorców. Przy udanym ataku można też załączyć do strony jednopikselowy obrazek umieszczony w domenie atakującego. Wtedy przeglądarki użytkowników wchodzących na stronę będą wysyłać do tego złośliwego serwera żądanie, co pozwoli atakującemu poznać np. poziom ruchu na stronie i adresy IP wszystkich odwiedzających.

Ogólnie rzecz biorąc style pozwalają na złośliwości mniejszego kalibru niż opisywany wcześniej Cross Site Scripting. Natomiast jeśli stawiamy projekt od zera, to warto rozważyć zablokowanie wykonywania wszystkich styli znajdujących się wewnątrz tagu style na stronie i w atrybutach style tagów HTML i mieć ten potencjalny problem z głowy, pozwalając jedynie na ładowanie arkuszy styli z zewnętrznych plików. Unikanie styli w atrybutach było chyba zresztą od zawsze dobrą praktyką jeśli chodzi o utrzymanie separacji kodu, ułatwienie cache'owania, oraz ze względu na dużą tzw. specyficzność selektorów CSS definiowanych w atrybutach, z którą każdy kto miał do czynienia z CSS kiedyś walczył.

W konfiguracji Content-Security-Policy możemy jedną dyrektywą zablokować wykonywanie styli zagnieżdżonych, oraz określić domeny internetowe z których ładowanie zewnętrznych arkuszy styli jest dozwolone. O tym czym jest dyrektywa powiem jeszcze za chwilę, ale najpierw jeszcze dwa słowa o innej potencjalnej luce bezpieczeństwa którą możemy zablokować na poziomie aplikacji, a mianowicie clickjackingu.

jingiel

Clickjacking

Clickjacking jest ciekawym rodzajem podstępu. Użytkownik na stronie widzi i klika w jakiś niewinnie wyglądający link, a przeglądarka zamiast tego wykonuje coś całkiem nieprzewidzianego, np. "lajkuje" z jego konta jakąś nieznaną mu stronę. Ten wariant sztuczki niektórzy nazywają nawet odrębnie "likejackingiem". Żeby działać na jakimś przykładzie, możemy rozpatrzeć właśnie ten scenariusz, bo przemawia do wyobraźni i faktycznie występuje w przyrodzie.

Podstęp wykorzystuje fakt, że HTML pozwala utworzyć na stronie poprzez tag iframe czyli inline frame, ramkę, i załadować w niej inną stronę. Stroną może być np. podstrona serwisu Facebook zawierająca przycisk "like" jakiegoś produktu czy posta. Ta strona w ramce iframe będzie przez przeglądarkę wczytana w kontekście użytkownika przeglądarki, tyle że nie w nowej zakładce, a właśnie w ramce wewnątrz strony. Problem pojawia się, kiedy ktoś sprawi, że ta ramka będzie przezroczysta i niewidoczna (np. stosując opacity "0" i wysoki z-index). Wtedy może ją ustawić tak, żeby skłonić użytkownika w kliknięcie przezroczystego przycisku "like" zupełnie nieświadomie że właśnie to zrobił.

Jako twórcy aplikacji webowych chcemy przede wszystkim zapobiec wstrzyknięciu kodu na stronę którą developujemy, aby chronić naszych użytkowników. Content-security policy pozwala na to poprzez zablokowanie ładowania na stronie ramek z innych domen niż te, których faktycznie potrzebujemy do działania i znacznie ograniczyć możliwość takiego ataku na użytkowników.

jingiel

Rozwiązanie/mitygacja: Content-Security-Policy

Tym sposobem dotarliśmy do sekcji, w której będę mógł trochę szerzej przedstawić rozwiązanie, a może raczej mitygację dla wspomnianych problemów i kilku im pokrewnych. Jeśli nasza strona pozwala na wstrzykiwanie kodu, to już w tym tkwi problem i w jej kodzie będziemy go docelowo chcieli rozwiązać, bo prawdopodobnie nieprawidłowo używamy frameworka i gdzieś poszliśmy za bardzo na skróty. Mechanizm Content-Security Policy pozwoli nam za to zablokować takie częściowo udane próby nadużyć i jeśli się takie pojawią, to wskaże nam gdzie nastąpiła próba ataku na użytkowników strony, przez mechanizm raportowania o którym jeszcze powiem.

Content-Security-Policy to standard, wspierany dziś w dużym stopniu przez wszystkie nowoczesne przeglądarki, pozwalający zdefiniować autorom stron jakie zasoby mogą być ładowane przez przeglądarkę, a jakie powinny zostać zablokowane. Z założenia ma ograniczyć możliwość wykonania ataków Cross Site Scripting, Clickjacking i innego rodzaju ataków code-injection skierowanych w przeglądarki. W tej chwili, na początku 2018 roku, dobrze wspierane w przeglądarkach są wersje 1 i 2 standardu, trwają prace nad wersją trzecią, ale to co mamy teraz zdecydowanie wystarcza już do rozwiązania wielu problemów.

Jako developerzy możemy zdefiniować politykę bezpieczeństwa strony na dwa sposoby:

  • Pierwszym z nich jest wysyłanie stringa gdzie deklarujemy nasze preferencje w nagłówku HTTP o nazwie Content-Security-Policy.
  • Drugą możliwością, wprowadzoną dla wygody w drugiej wersji standardu, jest przesyłanie tej wartości w meta-tagu strony. Ta forma może być w wielu sytuacjach wygodniejsza dla nas programistów i programistek, bo kiedy mamy tag będący częścią strony, to możemy go wersjonować razem z całym kodem np. w gicie, wiemy też że po wdrożeniu na inny serwer niż nasz lokalny na maszynie developerskiej, konfiguracja nadal trafi do przeglądarki użytkownika, niezależnie od tego czy serwer zostanie jakoś szczególnie skonfigurowany.

Jeśli podczas wczytywania strony przeglądarka napotka taki nagłówek lub meta-tag, to zastosuje politykę do wszystkich zasobów z którymi spotka się podczas dalszego przetwarzania strony.

Nagłówek HTTP, który definiujemy opisuje oczekiwane od przeglądarki zachowanie przy pomocy dyrektyw i ich wartości.

Dyrektywa określa rodzaj zasobów, np. dyrektywa o nazwie script-src wskazuje na ustawienia dotyczące przetwarzania JavaScript. Wartość dyrektywy to lista źródeł, z których mogą był ładowane zasoby tego typu. Cały nagłówek Content-Security-Policy zawiera więc zestaw par "klucz-kolekcja wartości", które są złączone tworząc formę jednego długiego stringa. To w jaki sposób to już detal, wystarczy popatrzeć na przykłady i jest dość jasne jak takiego stringa skleić.

Przykładowo dla wspomnianego klucza script-src możemy zezwolić na ładowanie skryptów zewnętrznych z tej domeny z której pochodzi strona plus, powiedzmy, z domeny disqus.com jeśli korzystamy z systemu komentarzy Disqus, plus np. google-analytics.com. Jeśli w wartościach wypiszemy takie trzy domeny, to jedynie skrypty z tych domen będą wykonane przez przeglądarkę. Nie będą natomiast domyślnie wykonane skrypty z tagów script ani te w atrybutach takich jak onclick albo onmouseover, te musielibyśmy jawnie włączyć dodając do listy zaufanych źródeł specjalne wartości które reprezentują te formy kodu.

Dyrektyw jest obecnie, czyli w drugiej wersji standardu zaledwie kilkanaście i odpowiadają różnego rodzaju zasobom które możemy chcieć kontrolować. Przejdę przez większość z nich, ale nie po to żeby je ktoś próbował zapamiętywać bo to nie ma tu sensu, tylko żeby pokazać nad czym mniej-więcej mamy kontrolę dzięki Content-Security-Policy.

Nadrzędną dyrektywą jest default-src, która jest używana w przypadku kiedy nie zdefiniujemy którejkolwiek z pozostałych, czyli pozwala nam zdefiniować wartośc domyślną. Generalnie dobrze ustawić jej jakąś restrykcyjną wartość, np. zezwalającą jedynie na ładowanie zasobów z tej samej domeny i jedynie na treści z zewnętrznych plików.

Dyrektywy, które pozwalają w bardziej granularny sposób kontrolować konkretne rodzaje zasobów to m.in

  • wspomniany wcześniej script-src dotyczący skryptów,
  • style-src dotyczący styli CSS,
  • object-src określający dozwolone źródła dla obiektów takich jak Flash, czy przeglądarkowa Java, czyli załączanych przez tagi object, applet i embed. Generalnie jeśli nie używamy tego typu staroci w przeglądarce to najlepiej nie zezwalać przeglądarce na ładowanie tego typu obiektów w ramach naszej strony,
  • img-src określa dozwolone źródła obrazków,
  • media-src dotyczy zasobów audio i video. Np. ten podcast na moim blogu jest embedowany jako plik audio i podlega tym regułom,
  • frame-ancestors pozwala generalnie ograniczyć źródła dla ramek takich jak iframe i zmniejszyć szansę na udany clickjacking,
  • form-action ogranicza lokalizacje, do których przeglądarka może nas przekierować po submicie formularza,
  • font-src dotyczy oczywiście czcionek.
  • Nazwy dyrektyw dotyczące żądań wysyłanych z poziomu JavaScriptu i przekierowań inicjowanych przez kod JavaScript trochę się zmieniały pomiędzy wersjami standardu, ale generalnie wszędzie powinna być wspierana dyrektywa connect-src pozwalająca je zdefiniować.

Wymieniłem tu kilka dyrektyw, które są do siebie podobne i dotyczą różnych kategorii zasobów które przeglądarka może blokować lub nie. Na uwagę zasługują jeszcze w szczególności dwie nieco inne dyrektywy CSP.

Pierwsza z nich to upgrade-insecure-requests, która instruuje przeglądarkę żeby wszelkie napotkane odwołania do zasobów po HTTP zamieniała na żądania HTTPS. W złożonych aplikacjach taka zmiana po stronie kodu całej aplikacji może być bardzo trudna i ta dyrektywa może pozwolić na łagodną migrację takich stron na HTTPS.

Drugą z ciekawych dyrektyw jest report-uri, które prawdopodobnie w trzeciej wersji standardu zostanie przemianowane na report-to. Ta dyrektywa pozwala nam poprosić przeglądarkę o to, żeby w przypadku naruszenia polityki Content-Security-Policy wysłała informację o tym zdarzeniu pod wskazany adres URL.

Informacja o naruszeniu jest wysyłana jako JSON-owa struktura zawierającą precyzyjną informacje na temat tego jaki zasób został zablokowany, które miejsce w kodzie strony próbowało się do niego odwołać, która konkretnie dyrektywa została naruszona i tym podobne rzeczy. Mechanizmu można go użyć nie tylko po to, żeby odnotowywać próby ataku na stronę, ale też żeby szybko wykryć sytuacje gdzie jako developerzy nałożyliśmy zbyt mocne ograniczenia, albo zapomnieliśmy dodać jakąś domenę na białą listę.

Co lepsze, możemy również poprosić przeglądarkę o samo raportowanie naruszeń, bez blokowania zasobów. Pozwala to w pewnym sensie przetestować nasze Content-Security-Policy bezpośrednio na produkcji w ten sposób, że przez jakiś czas jedynie zbieramy dane i obserwujemy co się dzieje, i dopiero na tej podstawie po 2 tygodniach albo miesiącu rzeczywiście włączamy blokowanie. Realizuje się to przez zmianę nagłówka HTTP albo odpowiadającego mu klucza meta-tagu z Content-Security-Policy na Content-Security-Policy-Report-Only. Ta prosta zmiana powoduje zmianę działania z wymuszania polityki bezpieczeństwa na ów tryb obserwacji, w którym jedynie zbieramy raporty o naruszeniach dyrektyw.

jingiel

Gdzie znaleźć więcej informacji

W tym miejscu chętnie wszedłbym jeszcze głębiej w szczegóły, ale podcast już teraz wydaje się trochę długi i nie wiem czy komukolwiek się go przesłuchać podczas jednego dojazdu do pracy ;) Zakończę więc na tym ogólnym obrazie i pozostawiam chętnym temat do zgłębienia. To jak zawsze najłatwiej zrobić biorąc jakiś swój weekendowy projekt i dodając do niego odpowiedni meta tag. W notatkach do tego odcinka zamieszczam link do kursu na Pluralsight o nazwie Defeating Cross-site Scripting with Content Security Policy . Tam w 2.5 h temat jest przerobiony od deski do deski i jeśli ktoś potrzebuje szczegółów albo chce wizualnie zapoznać się z tym wszystkim o czym mówiłem, to kurs jest naprawdę bardzo przystępny.

Ten odcinek podcastu "Programowanie na śniadanie" jest pierwszym ściśle technicznym odcinkiem i każdy feedback na jego temat od Ciebie będzie dla mnie cenny. Jeśli jesteś w stanie doradzić mi jak to nagranie mogłem zrobić lepiej, to odezwij się na facebooku albo napisz komentarz na blogu lub maila i daj mi o tym znać. Jestem ciekawy tego czy treść dla Ciebie jako programisty była interesująca i ma szanse wnieść coś do Twojej pracy, czy może chętniej posłuchałbyś albo posłuchałabyś o czymś innym? Pytam szczególnie dlatego, że podcasty jakie znam to w przytłaczającej większości luźne rozmowy i sam takich często słucham. Tu natomiast sprawdzam, czy w formie audio można również dostarczyć trochę ściślejszej technicznej wiedzy i jestem ciekaw czy w Twoim odczuciu jest ona przyswajalna w podobnym stopniu jak ta z książek czy kursów video, czy jednak w formie audio łatwiej się zgubić.

Ten odcinek kończy również mój etap przygotowań do premiery podcastu i wraz z jego publikacją uruchomiłem listę mailingową oraz stronę na facebooku, gdzie będę informował o nowych odcinkach. Mocno zachęcam oczywiście do zapisania się, nie będzie spamu bo teraz jest mi już trudno znaleźć czas na odpisanie na maile które do mnie przychodzą, a co dopiero na rozsyłanie własnych ;) Na listę mailingowa możesz zapisać się na moim blogu zakasanerekawy.taurit.pl w zakładce Podcast.

Dziękuję Ci za to, że zostałeś lub zostałaś aż do tego miejsca. Życzę udanego dnia, bo przypuszczam że podcastów tego typu słuchasz tak jak ja z rana i być może dzień pracy dopiero przed Tobą. Także do usłyszenia w kolejnym odcinku!

outro