:sparkles: PWA :sparkles:
Twarz autora bloga

Piotr Kowalski

Organizator WarsawJS Trener YouTuber

Chroń pliki konfiguracyjne projektu

Chciałem dać Ci dziś poradę, która jest wynikiem mojego wczorajszego rekonesansu tego bloga za pomocą najpopularniejszego narzędzia w dobie wszechogarniającego internetu tj. przeglądarki.

Baner reklamujący artykuł

Rekonesans

…czyli rozpoznanie. Po przeczytaniu pewnego artykułu o bezpieczeństwie, postanowiłem sprawdzić jak wygląda na tym tle moja najpopularniejsza aplikacja.

Testy

Rekonesans polega na zebraniu jak największej liczby informacji, które aplikacja (albo server) udostępnia. Dlatego bardzo ważne jest, aby wysyłać użytkownikom, czyli de facto światu zewnętrznemu jak najmniej informacji, co by nie informować wszystkich o podatnościach systemu informatycznego.

Definicja

Metoda określająca zbieranie danych na temat “celu” na podstawie udostępnianych informacji nazywa się banner grabbing.

Zadałem sobie pytanie: co ja udostępniam światu? czy nie za dużo?

Pierwsze testy wykazały, że popełniłem niesamowity błąd, do którego chcę Ci się przyznać, abyś to wykorzystał i nauczył się na moim błędzie.

Zagrożenie

W lutych napisałem, że projekt nie równa się aplikacji. Miałem rację. Nic się w tym aspekcie nie zmieniło, ale chyba dopiero do mnie coś dotarło…

Czy wrażliwe pliki projektu nie są "przypadkiem" widoczne w aplikacji udostępnionej na świat?

Jekyll i jego zasady

Jeśli używasz tego popularnego systemu do blogowania tak jak ja, to świetnie, tylko pamiętaj o wykluczeniu listy plików z budowania katalogu _site, który zostanie wystawiony na zewnątrz!

Wskazówka

Tutaj możesz poczytać o opcji exclude.

W konfiguracji, ista wykluczonych plików z budowania paczki zawierała tylko jedną pozycję - katalog node_modules/. A co z resztą?

Wyżej wymienione pliki (oraz inne) były udostępnione na zewnątrz, były dostępne dla internetu.

Na ten moment, opublikowane wrażliwe pliki już nie istnieją i zwracają kod HTTP 404.

Copy + paste

$ curl -I https://piecioshka.pl/webpack.config.js
HTTP/1.1 404 Not Found
Date: Wed, 03 May 2017 21:04:06 GMT

Niby nic strasznego, ale…

Tworząc projekt bloga, specjalnie nie chciałem upubliczniać jego kodu źródłowego z powodów bezpieczeństwa, tj. mam w tym projekcie pliki, które nie powinny być publicznie dostępne. Jakie to pliki? Nie ważne.

Sądziłem, że prywatne repo na GitHubie załatwia sprawę. Myliłem się.
Ważna jest również dystrybucja projektu z zamkniętymi źródłami.

Metoda głębokiego ukrycia

Istnieje pewna metoda, która niby zabezpiecza dostęp do Twoim plików, tj. metoda “głębokiego ukrycia”, czyli stworzenia skomplikowanej struktury katalogów, aby istniejące w nich pliki, nie były dostępne poprzez przypadkowe wpisanie adresu URL.

W moim przypadku technika ta, powinna nazywać się “płytkie ukrycie”, bo na samym wierzchu udostępniałem konfigurację aplikacji.

Co chronić?

Zamieszczam przykładową listę plików, które nie powinny ujrzeć świata dziennego w projekcie, którego źródła nie są otwarte:

  • .angular-cli.json
  • .babelrc
  • .gitignore
  • .gitattributes
  • .npmignore
  • .eslintignore
  • .travis.yml
  • .editorconfig
  • Gemfile
  • Gemfile.lock
  • app.json
  • nodemon.json
  • jasmine.json
  • bower.json
  • package.json
  • yarn.lock
  • tsconfig.json
  • tslint.json
  • typings.json
  • CHANGELOG.md
  • README.md
  • protractor.conf.js
  • karma.conf.js
  • webpack.config.js
  • wallaby.js

Oraz katalogów:

  • .git/ - udostępnienie tego katalogu równoznaczne jest z pokazaniem całych źródeł aplikacji
    • .git/index - aby sprawdzić, czy katalog .git faktycznie jest widoczny, weryfikacja, czy katalog istnieje, może skończyć niepowodzeniem, z powodu wyłączonego listowania katalogu.

    Na potrzeby testów sklonowałem projekt warsawjs-workshop-2-blog do głównego katalogu. Sprawdź, co się kryje pod tym URLem: piecioshka.pl/warsawjs-workshop-2-blog/.git/index

  • node_modules/ - zależności projektu
  • test/ - testy jednostkowe, integracyjne etc

Ze swojego doświadczenie dodam, że gdy “bundlujesz” pliki CSS i JavaScript do jednego (kilku?) master plików, to nie ma sensu udostępniać źródeł dla publiczności, dlatego warto np. dopisać do listy plików wykluczonych np. takie ścieżki:

  • assets/scripts/
  • assets/styles/