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.
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.editorconfigGemfileGemfile.lockapp.jsonnodemon.jsonjasmine.jsonbower.jsonpackage.jsonyarn.locktsconfig.jsontslint.jsontypings.jsonCHANGELOG.mdREADME.mdprotractor.conf.jskarma.conf.jswebpack.config.jswallaby.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.gitfaktycznie 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 projektutest/- 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/