Część,
Stworzyłem prostą aplikację na node.js, express, ktora wykorzystuje Busboya do przyjmowania plików z uploadera z zabezpieczeniem file-type. Pliki trafiają do folderu poza kodem aplikacji. Jest też mongoDB która przechowuje kilka zupełnie niewrażliwych danych z requestów. Pliki jak i db planuję czyścić raz dziennie.
Aplikacja służy do przekazania plików oraz pakietu wybranych w formularzu parametrow do silnika weryfikacji plików pod kątem druku (preflighta) zainstalowanego na serwerze oraz prezentacji jego wyników po stronie Klienta.
Chciałbym aby to narzędzie było ogólnodostępne bez konieczności logowania i nie chciałbym robić z tego Fort Knox, ale nie chciałbym też aby dostęp do niej był furtką do ataku na inne zasoby na serwerze ani żeby była podatna na złośliwy kod.
Czy moglibyście doradzić jakie rozwiązania wdrożyć ?

- Rejestracja:ponad 8 lat
- Ostatnio:12 miesięcy
- Postów:35
- Rejestracja:prawie 7 lat
- Ostatnio:około miesiąc
- Postów:3561
Na marginesie JS, w króym mam bladą orientację, zabezpieczenie PRZED CZYM ?
Ma być upload only bez downloadu, bo nie rozumiem ?

- Rejestracja:ponad 8 lat
- Ostatnio:12 miesięcy
- Postów:35
Download też jest, plików wynikowych. Przed czym? Przed złośliwym kodem? Nie wiem, to pierwsza moja apka
- Rejestracja:prawie 7 lat
- Ostatnio:około miesiąc
- Postów:3561
Zdefiniowanie głównych zagrożeń jest głównym elementem profilaktyk, tak ogólnie.
Co do tak otwartego pytania: dokładne i na każdym kroku developowanie zgodnie z kanonami sztuki, zasadami użycia języka / frameworku.
Nie istnieje coś takiego jak "najpierw zrobić a potem zabezpieczyć"

- Rejestracja:ponad 18 lat
- Ostatnio:około miesiąc
- Lokalizacja:Rzeszów
Ciężko cokolwiek powiedzieć w temacie. W teorii możesz przyjąć dowolny plik i zapisać go na dysku i nic się nie stanie. Jeżeli serwer go nie przetwarza lub go potem nie uruchomi (a domyślnie plik nie będzie miał praw do wykonywania na Linuksie) to nie ma się czego bać. Problem jest, gdy przyjmiesz wirusa (a ten może być nawet w pliku, który wg typu uznasz za bezpieczny), a potem ktoś go pobierze i uruchomi na komputerze "klienckim". Ale to już poza aplikacją i serwerem.
Jeżeli masz konkretne wymagania to pewnie sam je zrealizujesz, to może wrzuć jakiś kod, będziemy chociaż mogli wskazać oczywiste i potencjalne problemy z nim.
Mi się wydaje, że chyba warto by było zabezpieczyć system przed hurtowym wrzucaniem śmieci w nieograniczoej ilości - w pierwszym poście OP napisał, że ma być ogólnodostępne i bez logowania. Czyli każdy z 8 miliardów ludzi plus 3532 miliony botów mogą wrzucać tam cokolwiek. I to jest pierwsza rzecz, jakiej bym się przejrzał. Co do wirusów czy szkodliwego kodu - póki nie wiemy w jaki sposób te pliki będą przetwarzane to ciężko coś wymyśleć. Można połączyć upload z jakimś antywirem - czy clamav, czy coś komercyjnego (wiem, że f-secure i Kaspersky mają wersję skanujące serwery).

- Rejestracja:ponad 8 lat
- Ostatnio:12 miesięcy
- Postów:35
Ok, chyba powoli się coś klaruje. Największym zagrożeniem bedą chyba potencjalne wirusy w uploadowanych plikach gdyż każdy plik będzie przetwarzany przez pdfToolbox (wspomniany silnik do weryfikacji). Mogę skanować pliki przed wywołaniem komendy uruchamiającej weryfikacje. Mam wolne licencje Bitdefender Endpoint Security nada się?
Co do ruchu to raczej nie spodziewam się 8 miliardów ludzi ale boty mogą już być klopotem, myślę że można to załatwić jakąś prostą capchą lub coś podobnego, grunt by nie było zbyt upierdliwe, polecicie coś do node'a?

- Rejestracja:ponad 18 lat
- Ostatnio:około miesiąc
- Lokalizacja:Rzeszów
Na boty dobre jest cloudflare, jeżeli nie chcesz całej strony za tym chować to mają też swoją captchę, co chyba nie wymaga innych ich usług. W każdym razie zapakowanie całej strony w cloudflare nie powinno wymagać zmian u Ciebie, a jest skuteczne.
Możesz też zrobić customową bieda captchę - inputy radio, 3 obrazki i stały tekst "zabezpieczenie przed robotami, zaznacz psa". Takie zabezpieczenie odfiltruje większość botów, zostaną tylko te "targetowane" na Twoją stronę. A jeżeli będziesz miał ataki targetowane to i tak zacznie się poważne kombinowanie, na które teraz szkoda czasu, bo nie przewidzisz z czym będziesz miał do czynienia.
plik będzie przetwarzany przez pdfToolbox
Przetwarzanie uznaję za ryzykowne. Były niedawno dziury w imagick czy czymś, gdzie z obrazka PNG można było zrobić remote code execution. Rozpakowywanie ZIPów wymaga super dużej uwagi, bo ten standard pozwala na wiele rzeczy, których nikt by się nie spodziewał. PDFy też brzmią ryzykowanie.
Więc osobiście bym wystawił do tego drugi serwer/kontener Dockera, który "nic nie może", nie ma dostępu do sieci (poza przyjmowaniem requestów z sieci lokalnej).
Za to ty możesz jego odpytać przez HTTP. Więc Twój serwis główny wysyła temu serwisowi do pdfów plik do przetworzenia i ew. wszystkie dane, jakie są potrzebne do tego procesu (żeby serwis do pdfów nie miał dostępu do bazy danych czy coś), serwis pdf odpowiada id taska (chyba, że to szybka robota to może odpowiedzieć od razu wynikiem), potem serwis główny odpytuje cyklicznie serwis pdfów o wynik, aż go dostanie.
W ten sposób jeżeli w pdfToolbox
będzie dziura i ktoś ją wykorzysta i będzie w stanie uruchomić dowolne polecenie wewnątrz serwisu do pdfów to... nic nie zrobi. Bo nawet jak odczyta jakieś dane, to nie będzie w stanie ich przesłać dalej. Jedyne co będzie w stanie to wywalić maszynę/kontener. W sumie Docker ma tu przewagę, bo nie utrzyma stanu zepsucia, wystarczy restart kontenera i wszystko jest jak było.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.
Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.
Pliki trafiają do folderu poza kodem aplikacji
- ktoś tu przechodzi z PHP na JS? ;)