Wskazówki dotyczące bezpiecznego kodowania i najlepsze praktyki dla programistów

secure coding guidelines

Ten samouczek wyjaśnia Bezpieczne kodowanie, jak unikać luk w zabezpieczeniach oraz zawiera wskazówki dotyczące kodowania i listę kontrolną dotyczącą praktyk bezpiecznego kodowania:

Aby mieć wbudowane zabezpieczenia w oprogramowanie i wdrożyć wytyczne dotyczące bezpiecznego kodowania i najlepsze praktyki, cała organizacja wraz z zespołem wyznaczonym do pracy nad planowanym rozwojem aplikacji musi rozważyć pewne aspekty.

Tutaj omówimy te aspekty, które pomagają w tworzeniu bezpiecznego oprogramowania.

To takie proste, jeśli programista nie wie, co to znaczy „Bezpieczeństwo oprogramowania” i jak haker może zhakować swoje oprogramowanie, przejąć nad nim kontrolę i próbować wykorzystać, wtedy po prostu niemożliwe jest zakodowanie bezpiecznego oprogramowania. Dlatego programista musi najpierw zrozumieć znaczenie bezpiecznego kodowania.

Czego się nauczysz:

• Co to jest bezpieczne kodowanie?
  • Ograniczenie ryzyka
  • Przyczyny nieodpowiedniej implementacji zabezpieczeń
• Wytyczne dotyczące bezpiecznego kodowania
  • Wybór języka do bezpiecznego kodowania
  • Bezpieczne zasady i zalecenia dotyczące kodowania
  • Typowe błędy programowania, których należy unikać
• Lista kontrolna praktyk związanych z bezpiecznym kodem
  • Tabelaryczne podsumowanie listy kontrolnej bezpiecznego kodowania
• Wniosek
  • rekomendowane lektury

Co to jest bezpieczne kodowanie?

Bezpieczne kodowanie polega na projektowaniu i tworzeniu oprogramowania przez unikanie słabości które prowadzą do luk w zabezpieczeniach poprzez przestrzeganie określonych standardów bezpieczeństwa i najlepszych praktyk branżowych.

Pierwsze pytanie, które nasuwa się w głowie, brzmi: „Ile zabezpieczeń jest wymagane dla naszego oprogramowania” lub Kiedy możemy powiedzieć, że nasze oprogramowanie jest zabezpieczone? i Jakie są te standardy bezpieczeństwa ?

Oszustwa i zagrożenia bezpieczeństwa rosną z dnia na dzień i widzimy nowe odmiany i sposoby hakowania, nawet w tak zwanym najbardziej bezpiecznym oprogramowaniu.

Niedawno słyszeliśmy, że program Aaadhar firmy UIDAI został sfałszowany w celu uzyskania danych osobowych. Dlatego naprawdę trudno jest ustalić, ile zabezpieczeń jest wymagane dla oprogramowania i jakie są standardy bezpieczeństwa, chyba że zrozumiemy zagrożenia związane z oprogramowaniem i nie ustalimy ich priorytetów w oparciu o ryzyko dla firmy.

Zapewnienie 100% ochrony oprogramowania może być trudne, ale jeśli zespół programowy przeanalizuje plik Ryzyka i zabezpieczenia które są zaangażowane w swoje oprogramowanie, czyli potencjalne zagrożenia i jeśli zespół może zająć się ich minimalizacją, to z punktu widzenia bezpieczeństwa aplikacji byłoby dobrze.

Dlatego pierwszym zadaniem zespołu jest zidentyfikowanie i przeanalizowanie ryzyk i zabezpieczeń, które są związane z ich zastosowaniem, zrozumienie możliwych opcji łagodzenia i odpowiednie przyjęcie najlepszej opcji.

Tak więc, po zidentyfikowaniu dziesięciu największych luk w zabezpieczeniach klasyfikuje się prawie wszystkie ataki, z którymi program może się spotkać. Pomoże to w zrozumieniu zagrożeń i nadaniu priorytetu działaniom na rzecz bezpieczeństwa i rozwoju bardziej w kierunku zapobiegania niż łagodzenia skutków.

Na przykład. Chociaż planujemy opracować aplikację związaną z opieką zdrowotną, która obsługuje i przechowuje dane zdrowotne danej osoby oraz jej dane osobowe, największym zagrożeniem dla tej aplikacji jest kradzież danych dotyczących zdrowia.

darmowe oprogramowanie bazy danych dla systemu Windows 10

Ograniczenie ryzyka

Aby zmniejszyć ryzyko,

• Wdrożenie zabezpieczenia dostępu do danych przez nieautoryzowanego użytkownika wymaga odpowiedniego uwierzytelnienia i autoryzacji (implementacja polityki silnych haseł, 2-Factor Authentication).
• Należy zadbać o to, aby nie doszło do wycieku danych podczas przesyłania danych z jednego źródła do drugiego, poprzez wdrożenie zabezpieczonych kanałów (HTTPS) transmisji danych oraz szyfrowanie danych podczas przesyłania.
• Inną możliwością jest też fałszowanie lub kradzież danych w spoczynku. W związku z tym przechowywanie danych osobowych dotyczących zdrowia (przy użyciu szyfrowania) jest bardzo istotne.

Przed przejściem do „Standardu bezpiecznego kodowania” zawsze lepiej dla całego zespołu programowego jest mieć plik „Sesja dotycząca bezpieczeństwa” dyskutować i burzyć mózgów,

• Wymóg bezpieczeństwa dla ich konkretnego produktu.
• Możliwe korzyści, które haker miałby, gdyby włamał się do ich systemu.
• Możliwe sposoby i środki narażenia bezpieczeństwa ich stosowania.
• Wspólne praktyki bezpieczeństwa stosowane w podobnej branży i dziedzinie.
• Zrozumienie typowych problemów związanych z bezpieczeństwem odpowiednich programów.

Pomaga również zespołowi lepiej radzić sobie, jeśli może zrozumieć Źródła luk w zabezpieczeniach z którymi może się zmierzyć ich oprogramowanie oraz powody, dla których zostało ono zbudowane Słabe / niewystarczające Bezpieczeństwo .

Przyczyny nieodpowiedniej implementacji zabezpieczeń

Ogólnie rzecz biorąc, poniżej przedstawiono kilka powodów nieodpowiedniej implementacji zabezpieczeń w aplikacji.

• Priorytet jest nadawany wydaniu funkcjonalnemu niż aspektom bezpieczeństwa.
• Ignorancja lub brak świadomości na temat bezpieczeństwa oprogramowania i hakerów.
• Niewystarczająca jasność co do Programu lub samego Projektu oprogramowania.
• Złożoność programu.
• Za mało danych, informacje o systemie na żywo, w którym zostanie wdrożony.
• Brak uwzględnienia bezpieczeństwa w fazach SDLC.
• Niedostateczna znajomość i zrozumienie specyfiki języka używanego w oprogramowaniu.
• Niewystarczająca wiedza dla zespołu i programistów na temat wytycznych dotyczących kodowania zabezpieczeń.

Wiemy, że nie jest tak, że wszyscy programiści i testerzy są świadomi bezpieczeństwa aplikacji i mogą nie mieć dogłębnego zrozumienia luk w zabezpieczeniach i exploitów, szczególnie aplikacji, nad którą mieliby pracować. Na ogół będą zaznajomieni z, „Jak kodować funkcjonalnie” ale nie wszyscy wiedzą „Jak bezpiecznie kodować”.

Dlatego bardzo ważnym aspektem dla organizacji, aby przyjąć bezpieczne praktyki kodowania w swoim oprogramowaniu, jest pierwszy „Train People” . Dlatego szkolenie ich zespołu w zakresie aspektów bezpiecznego kodowania, najlepszych praktyk w zakresie kodowania bezpieczeństwa i prawidłowego korzystania z narzędzi jest bardzo ważne.

Najważniejszą zasadą projektowania bezpieczeństwa oprogramowania jest „Wdrażanie zabezpieczeń zgodnie z projektem i domyślnie” .

Wytyczne dotyczące bezpiecznego kodowania

Aby osiągnąć bezpieczeństwo, bardzo ważne jest posiadanie „Standard bezpiecznego kodowania” zidentyfikowane dla programu na samym początku tworzenia aplikacji, co pomaga zespołowi w dbaniu o bezpieczne ustawienia domyślne oprogramowania i pomaga chronić je przed atakami.

Ważne jest, aby upewnić się, że cały zespół jest Zmuszony do przestrzegania tego standardu , niezależnie od języka kodowania i narzędzi, których używają w programie.

Poniżej podano kilka przykładów, które muszą być domyślnie zaimplementowane w projektowaniu bezpiecznego kodu:

• Dostęp powinien być ograniczony tylko do uwierzytelnionych użytkowników, a uwierzytelnianie należy wdrożyć na każdej warstwie.
• Kanały komunikacyjne muszą być szyfrowane, aby chronić tokeny uwierzytelniające.
• Wszystkie klucze, hasła i certyfikaty muszą być odpowiednio przechowywane i chronione.
• Należy wdrożyć szyfrowanie plików, szyfrowanie bazy danych i szyfrowanie elementów danych.

Wybór języka do bezpiecznego kodowania

Wybór języka do kodowania może nie zależeć od bezpiecznego kodowania. Nie ma nic szczególnego jako zabezpieczony lub niezabezpieczony język do kodowania w celu zbudowania zabezpieczonego oprogramowania.

Chodzi o to, w jaki sposób używamy języka programowania do tworzenia oprogramowania i jaką dogłębną wiedzę ma programista na temat języka kodowania w zakresie wdrażania aspektów bezpieczeństwa.

Jednak zostało to wyjaśnione Standardy bezpiecznego kodowania są niezależne od wyboru języka, najlepsze praktyki dotyczące bezpiecznego kodu są zależne od języka, platformy i implementacji .

Dlatego też, aby mieć bezpieczny kod, programista musi mieć dogłębną znajomość języka używanego w programie, aby można było łatwo wdrożyć najlepsze praktyki bezpieczeństwa.

Przykład:

wywiad z programistą bazy danych pytania i odpowiedzi pdf

• Prawdopodobieństwo przepełnienia bufora różni się w zależności od języka, ale C, C ++ i Assembly są uważane za najbardziej podatne ze względu na ich przestarzałe możliwości zarządzania pamięcią. Kilka standardowych funkcji C lib, takich jak strcpy () i memcpy (), jest podatnych na ataki polegające na przepełnieniu bufora. Nieprawidłowe użycie tych funkcji przez skopiowanie buforu źródłowego, który jest zbyt duży, aby zmieścić się w buforze docelowym, powoduje przepełnienie buforu.
• Typowym problemem w aplikacjach internetowych opartych na języku Java są możliwe wycieki zasobów, które mogą wystąpić z powodu otwartych zasobów systemowych, takich jak pliki, gniazda i połączenia z bazą danych.

Kolejny aspekt bezpieczeństwa dotyczy narzędzi do wykorzystania w Aplikacji w celu optymalizacji bezpieczeństwa przy użyciu narzędzi takich jak Zintegrowane środowiska programistyczne będą najbardziej korzystne, ponieważ dostarczają dużo Alerty użytkownikom i zwróć uwagę na te alerty, aby spróbować poprawić jakość oprogramowania.

• Integracja komercyjnych lub Open-source bibliotek / wtyczek, takich jak Eclipse, Spring Tool Suite, RAD z IDE, pomaga programistom pisać bezpieczny kod poprzez wykrywanie i identyfikowanie potencjalnie podatnego kodu oraz zapewnia alerty dotyczące ustaleń związanych z wykonywaniem złośliwego pliku, wyciekiem informacji i niewłaściwa obsługa błędów.

Konieczne jest również użycie rozszerzenia Analizatory statyczne i dynamiczne poprawić aspekty bezpieczeństwa oprogramowania. Ogólnie rzecz biorąc, analizatory statyczne są zoptymalizowane pod kątem określonych typów błędów, więc w końcu znajdują dużą liczbę fałszywych alarmów podczas identyfikowania określonych błędów. Czasami istnieje możliwość, że pomijają również rzeczywiste błędy.

Dlatego zaleca się stosowanie wiele analizatorów statycznych aby lepiej uwzględnić różne typy błędów i uniknąć wielu fałszywych alarmów. Czasami zaleca się również wykonanie testowanie ręczne do wyeliminować fałszywe alarmy .

Bezpieczne zasady i zalecenia dotyczące kodowania

Programowi dobrze będzie zdefiniować zestaw plików „Zasady bezpiecznego kodowania i zalecenia” do którego można ocenić kod źródłowy pod kątem zgodności, aby testerzy mogli przeprowadzić „Testowanie zgodności” dla każdego z tych standardów bezpiecznego kodowania.

W związku z tym kod bezpieczeństwa może zostać certyfikowany jako zgodny lub niezgodny, stosując te zasady w odniesieniu do ustalonego poziomu odniesienia.

Kilka z poniższych zasad można wykorzystać do sprawdzenia naruszeń bezpieczeństwa:

• Pliki należy zamknąć, gdy nie są już potrzebne.
• Ilekroć przekraczamy granicę struktury, należy unikać wycieku informacji.
• Obiekty należy zadeklarować z odpowiednimi okresami przechowywania.

Dlatego przypadki testowe weryfikujące te zasady muszą być zaprojektowane i przeprowadzone w celu sprawdzenia zgodności. Stwierdzono również, że większość luk w zabezpieczeniach jest spowodowana typowymi typowymi błędami programistycznymi.

Dlatego Programista musi to zrozumieć „Niepewna metoda kodowania” , a jednocześnie uczą się najlepszych praktyk bezpiecznego kodowania. Idealnie jest zebrać najczęstsze błędy programistyczne, które przyczyniają się do luk w zabezpieczeniach ich aplikacji, aby można było się nimi zająć podczas kodowania.

Do takich typowych błędów programistycznych przyczyniają się głównie przepełnienia bufora, skrypty między witrynami i wady wstrzykiwania.

Niektóre z typowych luk w oprogramowaniu obejmują:

• SQL Injection (niewłaściwa neutralizacja elementów specjalnych używanych w poleceniu SQL).
• Całkowitą przepełnienie.
• Przepełnienie bufora (kopia bufora bez sprawdzania rozmiaru danych wejściowych).
• Niekontrolowany ciąg formatu.
• Brak uwierzytelnienia i autoryzacji (nieprawidłowa autoryzacja).
• Narażenie na wrażliwe dane.
• Niewłaściwa obsługa błędów.

Niektóre z tych błędów mogą prowadzić do awarii systemu, nieoczekiwanego dostępu do systemu i utraty kontroli nad oprogramowaniem przez hakerów.

Typowe błędy programowania, których należy unikać

Poniżej wymieniono kilka typowych błędów programowania, których należy unikać:

• Niewłaściwa neutralizacja elementów specjalnych używanych w poleceniu SQL („SQL Injection”).
• Kopiowanie bufora bez sprawdzania rozmiaru danych wejściowych („Klasyczne przepełnienie bufora”).
• Brak uwierzytelnienia funkcji krytycznej.
• Brak lub nieprawidłowa autoryzacja.
• Korzystanie z zakodowanych poświadczeń.
• Brak szyfrowania poufnych danych.
• Nieograniczone przesyłanie plików z niebezpiecznym typem.
• Poleganie na niezaufanych danych wejściowych w decyzji dotyczącej bezpieczeństwa.
• Wykonywanie z niepotrzebnymi uprawnieniami.
• Fałszerstwo żądań między lokacjami (CSRF).
• Pobieranie kodu bez sprawdzania integralności.
• Nieprawidłowe obliczenie rozmiaru bufora.
• Niewłaściwe ograniczenie nadmiernych prób uwierzytelnienia.
• Przekierowanie adresu URL do niezaufanej witryny („otwarte przekierowanie”).
• Niekontrolowany ciąg formatujący.
• Użycie skrótu jednokierunkowego bez soli.

Lista kontrolna praktyk związanych z bezpiecznym kodem

Wreszcie, po rozważeniu wszystkich powyższych punktów dotyczących bezpiecznego tworzenia oprogramowania, programiści muszą postępować zgodnie z Lista kontrolna ustalona dla praktyk związanych z bezpiecznym kodem aby upewnić się, że nic nie zostanie pominięte. Poniżej podano kilka, ale nie wyczerpujących list.

Walidacja danych wejściowych:

• Nie ufaj wejściom, rozważ scentralizowane sprawdzanie poprawności danych wejściowych.
• Nie polegaj na weryfikacji po stronie klienta.
• Uważaj na problemy z kanonizacją.
• Ograniczaj, odrzucaj i oczyszczaj dane wejściowe. Sprawdź poprawność typu, długości, formatu i zakresu.

Poświadczenie:

• Podziel witrynę na obszary anonimowe, zidentyfikowane i uwierzytelnione.
• Używaj silnych haseł.
• Obsługa okresów ważności haseł i wyłączania kont.
• Nie przechowuj poświadczeń (używaj jednokierunkowych skrótów z solą).
• Szyfruj kanały komunikacyjne, aby chronić tokeny uwierzytelniające.
• Przekazywanie plików cookie uwierzytelniania formularzy tylko przez połączenia HTTPS.

Upoważnienie:

• Używaj najmniej uprzywilejowanych kont.
• Rozważ szczegółowość autoryzacji.
• Egzekwuj rozdzielenie przywilejów.
• Ogranicz dostęp użytkowników do zasobów na poziomie systemu.
• Użyj protokołu OAuth 2.0 do uwierzytelniania i autoryzacji.
• Walidacja Carryout API.
• Dopuszczalne metody białej listy.
• Chroń akcje uprzywilejowane i wrażliwe kolekcje zasobów.
• Ochrona przed fałszowaniem zasobów między lokacjami (CSRF).

Zarządzanie sesjami:

• Utwórz identyfikator sesji na serwerze.
• Zakończ sesję za pomocą Logoff.
• Wygeneruj nową sesję po ponownym uwierzytelnieniu.
• Ustaw atrybut „bezpieczny” dla plików cookie przesyłanych przez TLS.

Kryptografia:

• Używaj kryptografii podczas „przesyłania danych, przechowywania danych, danych w ruchu, integralności wiadomości”.
• Nie rozwijaj własnego. Korzystaj ze sprawdzonych funkcji platformy.
• Przechowuj niezaszyfrowane dane blisko algorytmu.
• Użyj odpowiedniego algorytmu i rozmiaru klucza.
• Unikaj zarządzania kluczami (użyj DPAPI).
• Cyklicznie używaj kluczy.
• Przechowuj klucze w ograniczonej lokalizacji.

Rejestrowanie i audyt:

• Zidentyfikuj złośliwe zachowanie.
• Dowiedz się, jak wygląda dobry ruch.
• Przeprowadź inspekcję i rejestruj aktywność we wszystkich warstwach aplikacji.
• Bezpieczny dostęp do plików dziennika.
• Twórz kopie zapasowe i regularnie analizuj pliki dziennika.

Kodowanie wyjściowe:

• Carryout „Input Validation (XML, JSON….).
• Użyj sparametryzowanego zapytania.
• Przeprowadź „walidację schematu”.
• Przeprowadź kodowanie (XML, JSON ..).
• Wyślij nagłówki bezpieczeństwa.

Odniesienie: ' Lista kontrolna praktyk bezpiecznego kodowania OWASP (W skrócie, lista kontrolna SCP) '

Tabelaryczne podsumowanie listy kontrolnej bezpiecznego kodowania

Poniższa tabela zawiera podsumowanie „Rzeczy do zapamiętania dla bezpiecznego kodu” wniosku.

co to jest sterta w java

Wniosek

Mamy nadzieję, że ten samouczek będzie najlepszym przewodnikiem po zapewnieniu bezpieczeństwa oprogramowania.

Wytyczne dotyczące kodowania dla bezpiecznego tworzenia oprogramowania zostały tutaj wymienione w prostych słowach z przykładami ułatwiającymi zrozumienie koncepcji.

Miłego czytania !!

rekomendowane lektury

• Testowanie bezpieczeństwa (kompletny przewodnik)
• 30 NAJLEPSZYCH firm zajmujących się cyberbezpieczeństwem w 2021 r. (Małe i korporacyjne firmy)
• Podstawy programowania komputerowego dla początkujących | Samouczek kodowania
• 15 najlepszych darmowych edytorów kodu zapewniających doskonałe wrażenia z kodowania
• Kurs testowania SQL Injection (przykład i zapobieganie atakowi SQL Injection Attack)
• Programiści nie są dobrymi testerami. Co mówisz?
• Format egzaminu ISTQB Foundation i wytyczne dotyczące rozwiązywania prac
• Wytyczne dotyczące testowania bezpieczeństwa aplikacji mobilnych