Niszowy framework a ochrona przed atakami

0

Czy niszowy framework i język jest w stanie bardziej ochronić naszą stronę przed atakami? Tworze hobbystycznie blog napisany w Ruby, frameworku Hanami, a frontend to CoffeeScript. Większość osób potrafi pisać w PHP lub JS, wiec niszowe technologie pomogą zmniejszyć ataki i użeranie się z takimi osobami?

6

Podatność na ataki nie zależy od popularności frameworka, tylko od luk bezpieczeństwa. Niszowy framework niebędący forkiem innego popularnego, będzie w większości pzypadków odporny na ataki wykorzystujące cechy jakiegoś popularnego frameworka, Natomiast nie będzie odporny na ataki wykorzystujące niefrasobliwość i błędy w konfiguracji serwera. Frontend nie ma nic do tego, bo atak może polegać na generowaniu żądań poza przeglądarką i frontendem. W takim przypadku również technologia, w której jest backend też nie ma nic do tego, bo istotna jest podatność na odpowiednio spreparowane żądania, a nie to, czy backend jest w PHP, Ruby on Rails, .NET itp.

Z drugiej strony, możliwa jest sytuacja, że mało znany framework nie jest dobrze przetestowany i prędzej czy później zostaną ujawnione luki bezpieczeństwa.

Tak więc, nie ma związku między popularnością technologii a podatnością aplikacji na ataki.

0

Dobrze mi wytłumaczyłeś, coś w tym jest co piszesz. Zawsze mnie zastanawiało to co nakładka na JavaScript typu TypeScript lub CoffeScript doda do większej ochrony strony, jak i tak pod spodem jest czysty JS, który widzi przeglądarka i atakujący. Wiem natomiast, że Node i Deno po stronie serwera, to już inna sprawa. Widzę, że Ruby w startupach już zmieniają na inne technologie typu: Elixir i Pheonix oraz Crystal z frameworkami Kemal i Amber. W sumie wyszła już wersja V1 Crystal i planują dodać do niego wielowątkowość, żeby był bardziej konkurencją dla Go.

1

Zmieniają technologie (sam zmieniłem z Ruby na Elixira/Erlanga), ale nie z powodu "bezpieczeństwa" a z powodu wydajności (zarówno samego środowiska jak i developerów). Co do samych rozwiązań, to np. Phoenix bazuje na Cowboyu jako serwerze HTTP, który jest stosunkowo długo na rynku, więc jest dość intensywnie "przetestowany" (IIRC pierwsza przykładowa implementacja HTTP/2 była na Cowboyu), a sam framework poza Phoenix.Token nie za bardzo zawiera miejsca, gdzie błędy wewnątrz frameworka mogłyby wystąpić. Już prędzej programista zrobi jakąś głupotę (jak np. String.to_atom(string_provided_by_user)) niż framework będzie zawierał jakieś znaczące błędy.

0

Cała ta maszyna, kompilator Erlang to przecież bardzo stara technologia, czemu jest taki wyjątkowy? Na przykład porównując go do Rust, Go, Nim, Zig, Idris, D, Swift, Crystal. Wszystkie te języki co wymieniłem są tak samo szybkie i wydajne.

2
reactos napisał(a):

Na przykład porównując go do Rust, Go, Nim, Zig, Idris, D, Swift, Crystal. Wszystkie te języki co wymieniłem są tak samo szybkie i wydajne.

Nie, nie są. Rust jest o wiele szybszy i wydajniejszy niż Go. O reszcie się nie wypowiem bo nie znam

6

@reactos:

EDIT ten post nie ma mówić, że Erlang jest lepszy od innych języków, tylko wyjaśnić, że porównanie jakiego użyłeś jest bezsensowne, bo każdy język ma swoją niszę.

Na przykład porównując go do Rust, Go, Nim, Zig, Idris, D, Swift, Crystal. Wszystkie te języki co wymieniłem są tak samo szybkie i wydajne.

Nie, w większości języki, które wymieniłeś, będą bardziej wydajne niż BEAM. Ale to nie wydajność jest główną zaletą Erlanga. Porównywanie Erlanga i np. Rusta pod względem wydajności jest jak mówienie, że Bugatti jest szybsze od BiełAZ 75710 - technicznie masz rację, ale zupełnie pominąłeś istotę tych pojazdów.

Cała ta maszyna, kompilator Erlang to przecież bardzo stara technologia, czemu jest taki wyjątkowy?

Teraz małe wyjaśnienie - mówimy tutaj o "standardowej" maszynie wirtualnej Erlanga (BEAM - Bjorn ErlAng Machine), kompilator jest tutaj czymś zupełnie innym, bo "oficjalny" kompilator Erlanga jest napisany w Erlangu, ale to nie oznacza, że nie może być napisany w czymś innym (jest np. Gleam, który jest napisany w Ruscie i wypluwa pliki binarne BEAM).

Wyjątkowość Erlanga polega na tym, że ten język powstał w celu rozwiązania jednego, bardzo konkretnego problemu - napisania oprogramowania dla centralek telefonicznych AXD-N (był to moment kiedy różne sieci jak telefonia czy raczkujący internet zaczynały być obsługiwane przez te same urządzenia). Tylko tyle i aż tyle, bo ten problem wymagał paru istotnych cech, których nie oferował żaden ówcześnie istniejący język (i mało który obecnie istniejący to oferuje):

  • Soft-realtime - połączenia telefoniczne powinny być realizowane tak szybko jak tylko możliwe, zwłoka jest mocno niewskazana
  • Zrównoleglenie przetwarzania - jedna centralka powinna być w stanie obsłużyć jak najwięcej jednoczesnych połączeń
  • Izolacja błędów - błąd w kodzie nie powinien spowodować, że cała maszyna padnie, a tylko jak najmniejsza, wyizolowana jej część
  • Szybkość developmentu - z racji tego, że wtedy była duża presja czasu z dostarczeniem produktu, bo kto pierwszy ten lepszy, to wymagane było, by programista mógł pracować jak najszybciej, bez dodatkowych kompilacji
  • System powinien sam się leczyć w miarę możliwości

Te założenia spowodowały, że Erlang ma cechy jakie ma:

  • Każdy proces Erlanga jest niezależny od reszty procesów i wszystkie błędy wewnątrz jednego procesu dotyczą tylko i wyłącznie tego procesu
  • Paradygmat funkcyjny pozwala łatwiej opisywać i śledzić stan oraz skupiać się tylko na "happy path" poprzez pattern matching
  • Procesy komunikują się poprzez wysyłanie wiadomości w całkowitej izolacji (wszystkie dane w wiadomościach są kopiowane do innego procesu)

Te cechy z kolei pozwoliły na uzyskanie "rozproszenia" niejako "przy okazji" - racji, że procesy Erlanga żyją w całkowitej izolacji, oraz komunikują się przez kopiowanie danych, to nie ma znaczenia na jakiej fizycznej maszynie znajduje się proces, jeśli mamy jego identyfikator, to możemy wysłać do niego wiadomość, a następnie maszyna wirtualna zajmie się tym by ta wiadomość "dotarła".

Jest to jeden z niewielu języków (i chyba jedyny mi znany), który jest "stosunkowo popularny" i powstał jako praca doktorska.

Więc założenia oraz cele wszystkich języków, które wymieniłeś i Erlanga, są zupełnie różne, więc porównywanie ich, zwłaszcza używając tak marnej metryki jak "wydajność", jest bez sensu.

1 użytkowników online, w tym zalogowanych: 0, gości: 1