Strona główna > Journal > Najlepsze języki programowania dla bezpieczeństwa aplikacji
Journal

Najlepsze języki programowania dla bezpieczeństwa aplikacji

Oceń artykuł:

Bezpieczeństwo aplikacji webowych, aplikacji mobilnych, ochrona przed cyberatakami najczęściej odnosi się do wszelkich rozwiązań, które mają zapewnić możliwie największą ochronę przed złośliwymi atakami.

Chodzi nie tylko od działania obronne, ale także związane z prewencją, stałą gotowością do odparcia ataku i przeciwdziałania jego szkodom.

Bezpieczeństwo aplikacji w najbardziej ogólnym sensie kojarzyć należy z regularnym badaniem struktury, sposobu działania aplikacji, wyszukiwaniem luk, błędów, niedociągnięć, które mogą podwyższyć ryzyko ataku i narazić nas na niepowołany dostęp do poufnych danych firmy i klientów.

Ale, czy myślenie od cyberatakach, hakerach, bezpieczeństwie aplikacji, lukach w zabezpieczeniach, bezpieczeństwie danych, szkodach, ryzykach oraz konsekwencjach należy kojarzyć tylko i wyłącznie z działającymi już aplikacjami?

Czy myślenie nad bezpieczeństwem aplikacji webowych, mobilnych nie powinno zacząć się już na etapie wyboru stosu technologicznego?

Jakie technologie mają podatności na cyberataki, a jakie są uważane za względnie bezpieczne lub po prostu bezpieczniejsze niż inne?

Jeśli jesteście zainteresowani bezpieczeństwem swoich aplikacji koniecznie przeczytajcie poniższy artykuł, w którym podejmujemy problem bezpieczeństwa języków programowania.

Zapraszamy do lektury!

Szukasz software house?

Myśląc o bezpieczeństwie aplikacji mobilnych - bezpieczny stos technologiczny

Wybór technologii, jakiej/jakich będziemy używać w danym projekcie nie jest zadaniem łatwym i wymaga czasami przemyślenia priorytetów (biznesowych oraz zorientowanych na użytkownika) oraz zgody na trudne kompromisy.

bezpieczeństwo aplikacji mobilnych

Konkretny zestaw technologii, narzędzi, rozwiązań zawsze jest - mniej lub bardziej - warunkowany konstelacją czynników związanych z kwestiami:

  • adekwatności, wydajności, użyteczności, perspektywiczności danej technologii
  • obiektywnej skuteczności zabezpieczeń
  • biznesowej opłacalności danej technologii i jej zabezpieczeń
  • budżetowego dopasowania technologii do projektu
  • ram czasowych projektu i czasochłonności danej technologii
  • ram organizacyjno-zasobowych (np. dostępności specjalistów pracujących w danej technologii)
  • oraz poziomu oczekiwanego i zapewnianego bezpieczeństwa aplikacji.

Każdy projekt to wybór. Bezpieczeństwo aplikacji webowych, mobilnych wymaga dokonania wielu trudnych i wcale nie oczywistych wyborów.

Kryteria wyboru można podzielić na czysto obiektywne (wynikające z racjonalnych, bezstronnych przesłanek) oraz subiektywne (wynikające z osobistych preferencji, doświadczeń, kompetencji zespołu programistycznego).

Konkretny stos technologiczny jest wynikiem tego, na co kładziemy szczególny nacisk.

Niestety, bezpieczeństwo aplikacji internetowych, czy dowolnego innego produktu cyfrowego, nie zawsze jest uwzględniane jako czynnik o znaczeniu kluczowym, strategicznym.

Częstokroć bezpieczeństwo przesłaniają kwestie:

  • możliwości zespołu developerskiego tworzącego aplikacje
  • aktualnych trendów technologicznych (np. związanych z wzrostem popularności lub pojawieniem się nowych technologii, w jakich tworzy się aplikacje)
  • stosunku jakości kodu do kosztu jego wytworzenia
  • dostępności specjalistów na danym rynku
  • akceptowalnego poziomu bezpieczeństwa, jaki ma być uzyskany w danym projekcie.

Splot tych uwarunkowań wpływa na to, jaki poziom bezpieczeństwa (zarówno dla właścicieli biznesu, jak również użytkowników aplikacji) będzie wdrożony w danym oprogramowaniu.

Kwestie bezpieczeństwa aplikacji są także odsuwane w czasie, jako zadania o mniejszym priorytecie, mniejszej wadze biznesowej, zatem możliwe do wykonania w przyszłości.

W wielu wypadkach akceptowana jest sytuacja, w której aplikacja jest minimalnie bezpieczna, zamiast być domyślnie możliwie najbezpieczniejszą jaką się da.

Takiemu podejściu służy przekonanie, że większość z popularnych języków programowania oferuje mniej więcej podobny poziom, zakres bezpieczeństwa. Jest w podobny sposób „niezawodna i doskonała”.

Porównywanie różnych języków pod kątem ich bezpieczeństwa rodzi wiele kontrowersji (kryterialno-metodologicznych) oraz wiele emocji, wynikających najczęściej z osobistych doświadczeń i preferencji.

Oczywiście rozstrzyganie o wyższości jednych technologii nad innymi powinno być przeprowadzane na gruncie spójnych założeń, czytelnych metodologii, trafnych i zróżnicowanych kryteriów.

Wtedy dokonywanie takich porównań, ocen i tworzenie hierarchii daje obraz stosunkowo rzetelny, uczciwy i miarodajny.

Poglądowość i wymierne korzyści z porównań zawsze są mniej lub bardziej użyteczne.

W porównywaniu nie tylko chodzi przecież o tworzenie hierarchii, wyłanianie zwycięzców i naznaczanie przegranych.

Ważna kwestią jest wskazywanie mocnych, słabych cech danej technologii, uświadamianie jej potencjału i obszarów, które mogą - ale oczywiście nie muszą - być źródłem problemów z bezpieczeństwem.

W tworzeniu porównań chodzi również o poszukiwanie rozwiązań adekwatnych do samej problematyki bezpieczeństwa, która jest przecież bardzo złożona, wielowymiarowa, zależna od kontekstu, zmienna w czasie, zależna od przyjętych priorytetów.

Wreszcie w porównywaniu chodzi o świadomość, które elementy należy dopracowywać, mieć na szczególnej uwadze, które wymagają - mówiąc metaforycznie - specjalnej troski.

Bezpieczne aplikacje mobilne, czyli jak zmierzyć bezpieczeństwo języka programowania?

Problem na pewno nie jest ani oczywisty, ani prosty, ani także pozbawiony kontrowersji.

Niemniej jednak, co jakiś czas firmy zajmujące się bezpieczeństwem podejmują się tego wymagającego zadania i starają się odpowiedzieć na pytania:

  • jak bardzo dany język (a tym samym aplikacja mobilna w nim napisana) jest podatny na ataki?
  • jaki poziom bezpieczeństwa oferuje dany język?
  • jak dana technologia jest rozwijana pod kątem bezpieczeństwa?

Bardzo dobrym przykładem tego rodzaju praktyk jest baza danych luk w zabezpieczeniach WhiteSource (WhiteSource Vulnerability Database).

W bazie gromadzone są informacje o lukach w zabezpieczeniach technologii typu open source.

Obejmuje ona ponad 200 języków programowania i ponad trzy miliony komponentów.

Warto jednak pamiętać, że zmierzenie, jak dane języki programowania radzą sobie w kwestii bezpieczeństwa, zabezpieczeń, luk jest tak naprawdę próbą odpowiedzenia na pytania:

  • jakie rodzaje ataków mamy na myśli?
  • jakie cele ataków mamy na myśli?
  • jak długą odporność na ataki mamy na myśli?
  • jak częste ataki mamy na myśli?
  • jaki poziom ochrony mamy na myśli?
  • jaki sposób wykrywania zagrożeń mamy na myśli?
  • jaki moment rozwoju danego języka programowania mamy na myśli?

Czynnik czasu wydaje się w kwestii szacowania poziomu oferowanego bezpieczeństwa przez dany język programowania dość istotny.

Języki programowania - w szczególności udostępniane, rozwijane na licencji open source - potrafią się bardzo zmieniać pod tym względem.

Czego specjaliści z WhiteSource mają oczywiście świadomość.

Jak zauważa Ayala Goldstein, w artykule pt. „Is One Programming Language More Secure Than The Rest?”, większość popularnych języków programowania (np. C, PHP, Java, JavaScript, Python) na przestrzeni ostatniej dekady przeżywała wzloty i upadki.

Choć poziom bezpieczeństwa ulegał - czasami nawet znacznym zmianom - to według Goldstein wyraźnie zarysował się także trend wzrastania świadomości luk bezpieczeństwa.

Świadomość rosła wraz ze wzrostem popularności, za którą poszło także o wiele większe zaangażowanie zasobów.

Aktywne działania społeczności pozwoliły doskonalić języki pod kątem bezpieczeństwa.

W ramach działań doskonalenia, poprawiania, łatania luk danej technologii utworzono także listę typowych słabości oprogramowania (CWE - Common Weakness Enumeration).

Społeczności skupione wokół różnych języków programowania wykazały się dużą inicjatywą oraz świadomością rosnących problemów.

Wykazały się także dużą determinacją w przeciwdziałaniu problemom z bezpieczeństwem.

Co to jest CWE - Common Weakness Enumeration?

Porównywanie języków bez odwołania się do wskaźników, które dawałyby podstawę do oceny nie ma większego sensu.

Co to jest CWE

CWE bywa opisywany, definiowany jako miernik narzędzi bezpieczeństwa, podstawa identyfikacji słabości oraz zbiór rekomendacji naprawczych i działań zapobiegawczych.

Jak czytamy w opisie listy CWE w wersji 4.6 (CWE List Version 4.6), lista jest dziełem społeczności, mającym na celu stworzenie konkretnych, zwięzłych definicji dla każdego wspólnego typu słabości.

Common Weakness Enumeration to wady, błędy - obejmujące sprzęt, kod - które, jeśli nie zostaną usunięte mogą być przyczyną bądź środkiem do przeprowadzenia ataku.

Od 2006 roku CWE stawia przed sobą przede wszystkim cel edukacyjny, diagnostyczny oraz normalizujący.

Działania podejmowane w ramach inicjatywy CWE są skupione na:

  • opisie błędów
  • diagnozie oprogramowania i sprzętu
  • standaryzacji rozwiązań naprawczych i diagnostycznych
  • profilaktyce oraz tworzeniu rozwiązań naprawczych chroniących użytkowników.

Główną zaletą CWE jest systematyzacja problemów, dążenie do wyczerpującego i konkretnego ich opisu, standaryzacja narzędzi diagnostycznych, porównawczych, określających jakość.

cwe - bezpieczeństwo aplikacji

Jakie zatem są najbardziej bezpieczne języki programowania? Przyjrzyjmy się raportowi, który wnosi ciekawą perspektywę do wyjaśniania tego problemu.

Najbezpieczniejsze języki programowania - Raport WhiteSource

W raporcie pt. „What Are Themost Secure Programming Languages?” przygotowanym przez WhiteSource wyselekcjonowano 7 najpopularniejszych języków programowania spośród ponad 200 i poddano analizie zmiany, jakie w nich zaszły w ostatniej dekadzie.

bezpieczeństwo aplikacji - języki programowania

Podstawowe pytania badawcze sformułowano tak:

  • Jakie języki programowania są najbardziej bezpieczne?
  • Które typy luk w zabezpieczeniach są najbardziej powszechne?

Co się okazało?

Otóż, większość popularnych języków programowania współdzieli podobne problemy.

Są nimi:

  • Cross-Site-Scripting (XSS) - CWE-79
  • Input Validation - CWE-20
  • Information Leak / Disclosure - CWE-200
  • Path Traversal - CWE-22
  • Permissions, Privileges, and Access Control - CWE-264.

Choć dzięki rozwojowi narzędzi diagnostycznych wzrosła liczba wykrywanych luk w zabezpieczeniach, to jednocześnie zgodnie z wynikami badania WhiteSource liczba luk o wysokim poziomie istotności, luk krytycznych zmalała.

Bezpieczeństwo programowania w JavaScript

JavaScript jest od lat jednym z najpopularniejszych języków programowania. Zgodnie z różnymi szacunkami jest on używany do tworzenia ponad 90% stron internetowych.

Bezpieczeństwo programowania w JavaScript

JavaScript, będąc językiem bardzo wszechstronnym, jest siłą rzeczy używany przez programistów full-stack, front-end i backend.

A to wprost przekłada się na jego ocenę pod kątem bezpieczeństwa. Na szczególną uwagę zasługuje również JavaScript w świetle rozwoju serverless i cloud computing.

Przy tak dużej popularności oraz ilości tworzonych w tym języku produktów cyfrowych, frameworków, bibliotek nie jest zaskoczeniem, że ilość luk w zabezpieczeniach w ciągu ostatnich dziesięciu lat stale rosła, narażąjąc użytkowników.

bezpieczeństwo javascript, js

Zgodnie z wynikami raportu WhiteSource w JavaScript najczęściej pojawiały się luki typu:

  • Cryptographic Issues - CWE-310
  • Path Traversal - CWE-20
  • Cross-Site Scripting (XSS) - CWE-79.

Bezpieczeństwo programowania w Pythonie

Zyskujący na popularności z każdym rokiem Python jest językiem wysokopoziomowym, zorientowanym obiektowo, którego główną zaletą jest uproszczenie procesu programowania.

Bezpieczeństwo programowania w Pythonie

Ponadto, Python jest doceniany za czytelność, przejrzystość kodu oraz łatwą składnię.

Python bardzo często jest wykorzystywany do wykrywania złośliwego oprogramowania, wykonywania testów penetracyjnych.

Choć Python zyskuje na popularności, to jednak - w przeciwieństwie do JavaScript - nie zanotował tak dużego wzrostu luk w zabezpieczeniach.

Zgodnie z wynikami raportu WhiteSource w Pythonie najczęściej pojawiały się luki typu:

  • Input Validation - CWE-20
  • Permissions, Privileges, and Access Control - CWE-264
  • Cross-Site Scripting (XSS) - CWE-79.

Ciekawym wnioskiem płynącym z raportu przygotowanego przez WhiteSource jest na pewno obserwacja, że na sam obraz sytuacji w dużym stopniu wpływają zmiany w samych metodologiach, definicjach, które są obserwowane w Common Weakness Enumeration.

Ponadto, niektóre typy słabości nabierają na sile lub słabną w danym czasie i trudno jest zatem mówić o jakimś stałym poziomie.

Wiąże się to ze wzrostem świadomości tych problemów, aktywnością społeczności, która ma na celu przeciwdziałanie im.

bezpieczeństwo aplikacji python

Konkludując, warto mieć świadomość dużej umowności kategorii typu - najlepsze języki programowania dla bezpieczeństwa aplikacji, użytkowników - ich względności oraz zależności od przyjętych kryteriów, czasu, metodologii i rangi wskaźników.

Najlepsze i najważniejsze języki programowania chroniące aplikacje. Podsumowanie

  1. Pojęcia takie jak na przykład, bezpieczeństwo aplikacji webowych, zazwyczaj odnoszą się do wszelkich działań, rozwiązań, technologii, procesów, które mają zapewnić możliwie najwyższą ochronę przed złośliwymi atakami.
  2. Bezpieczeństwo aplikacji www zależne jest od regularnego badania jej struktury, sposobu działania.
  3. Bezpieczeństwo aplikacji internetowych zapewnia przede wszystkim wyszukiwanie oraz łatanie luk.
  4. W połączeniu z poszukiwaniem błędów i niedociągnięć stanowi zestaw podstawowych działań zwiększających protekcję aplikacji mobilnej.
  5. Luki, błędy w aplikacjach, kontach użytkowników znacząco podwyższają ryzyko ataku, który może skutkować dostępem do poufnych danych firmy i klientów osób trzecich.
  6. Wybór technologii, rozwiązań, narzędzi, sposobów zabezpieczania aplikacji, urządzeń mobilnych, użytkownika, klienta, właściciela biznesu jest zawsze uwarunkowany bardzo różnymi i licznymi czynnikami.
  7. Do najważniejszych czynników wpływających na bezpieczeństwo aplikacji mobilnych (np. data protection) należy między innymi: wydajność, użyteczność, perspektywiczność danej technologii, jej biznesowa opłacalność, budżetowe dopasowanie technologii do projektu oraz poziomu oczekiwanego bezpieczeństwa aplikacji.
  8. Bezpieczeństwo aplikacji mobilnych często nie jest traktowane jako czynnik o znaczeniu strategicznym.
  9. Bardzo często nad bezpieczeństwem aplikacji przedkładane są kwestie takie jak: aktualne trendy technologiczne, stosunek jakości kodu do kosztu jego wytworzenia, dostępność specjalistów na danym rynku, akceptowalny poziom bezpieczeństwa, jaki ma być uzyskany w danym projekcie.
  10. Zestawianie, porównywanie języków programowania pod kątem ich bezpieczeństwa jest bardzo kontrowersyjne pod kątem kryterialno-metodologicznym. Aplikacje i ich ochrona to problem złożony i zmienny w czasie.
  11. Porównanie języków programowania pod kątem ich bezpieczeństwa jest zawsze próbą odpowiedzi na pytania: jak bardzo dany język jest podatny na ataki, jaki poziom bezpieczeństwa oferuje dany język, jakie rodzaje ataków mamy na myśli, jak długą odporność na ataki mamy na myśli, jak częste ataki mamy na myśli, jaki sposób wykrywania zagrożeń mamy na myśli, jaki moment rozwoju danego języka programowania mamy na myśli?
  12. Większość popularnych języków programowania w ostatnich dziesięciu latach latach oferowała zmienny poziom bezpieczeństwa.
  13. Inicjatywą mającą na celu zwiększenie poziomu, zakresu bezpieczeństwa aplikacji mobilnych jest stale aktualizowana i rozwijana lista typowych słabości oprogramowania (CWE - Common Weakness Enumeration).
  14. Common Weakness Enumeration to wady, błędy sprzętu, kodu, które, jeśli nie zostaną usunięte mogą być powodem ataków złośliwym oprogramowaniem, narażającym aplikacje, użytkowników, właścicieli na wiele szkód.
  15. CWE bywa opisywany, definiowany jako miernik narzędzi bezpieczeństwa, podstawa identyfikacji słabości oraz zbiór rekomendacji naprawczych i działań zapobiegawczych.
  16. W ostatnich latach wzrosła liczba wykrywanych luk w zabezpieczeniach oraz zmalała liczba luk o wysokim poziomie istotności.
  17. W JavaScript najczęściej pojawiały się luki typu Cryptographic Issues – CWE-310, Path Traversal – CWE-20, Cross-Site Scripting (XSS) - CWE-79.
  18. W Pythonie najczęściej pojawiały się luki typu Input Validation – CWE-20, Permissions, Privileges, and Access Control – CWE-264, Cross-Site Scripting (XSS) – CWE-79.
  19. Określenie aktualnego poziomu bezpieczeństwa aplikacji mobilnych, wskazanie korpusu rozwiązań chroniących aplikacje, ich zabezpieczenie jest w dużym stopniu uwarunkowany przyjętymi metodologiami oraz definicjami.
  20. Warto mieć świadomość, że niektóre typy słabości nabierają na sile lub słabną w danym czasie i nie można mówić o stałość ich występowania.
  21. Kategorie typu – najlepsze języki programowania dla bezpieczeństwa aplikacji, technologie chroniące aplikacje – adresowane do użytkowników smartfonów, właścicieli bieznesów są wysoce umowne, nieprecyzyjne, pozbawione mocnych podstaw kryterialno-metodologicznych.
Oceń artykuł:
Journal / Redaktor
Autor: Radek
UX Writer i badacz z wykształcenia + doświadczenia. Zbiera wiedzę The Story i dzieli się nią na Journalu.

Jesteś zainteresowany współpracą z nami? Zajrzyj do Portfolio