heygrc
ISO 27001 A.8.28 w kodzie

Bezpieczne programowanie, w kodzie.

ISO 27001:2022 A.8.28 (bezpieczne programowanie) dotyczy stosowania zasad bezpiecznego programowania, aby oprogramowanie nie było dostarczane z lukami, na których polega atakujący: wstrzykiwanie, niebezpieczne przetwarzanie danych wejściowych i wyjściowych, niebezpieczne domyślne ustawienia. Spośród wszystkich kontroli z załącznika A jest to ta, która najbardziej bezpośrednio dotyczy kodu, co czyni pull request naturalnym miejscem do jej egzekwowania.

How it shows up in a diff

The shapes the same control failure takes.

A.8.28 jest osłabiany, gdy zmiana wprowadza znany niebezpieczny wzorzec lub usuwa zabezpieczenie przed nim. Powtarzające się wzorce:

  • Zapytanie zbudowane przez konkatenację łańcuchów

    Dane wejściowe użytkownika są interpolowane bezpośrednio do łańcucha SQL, powłoki lub zapytania zamiast być przekazywane jako parametr, co otwiera drogę do ataku wstrzyknięcia.

  • Wyjściowe dane renderowane bez escapowania

    Dane kontrolowane przez użytkownika są zapisywane w HTML, szablonie lub odpowiedzi bez escapowania, co otwiera drogę do ataku cross-site scripting.

  • Wyłączona statyczna analiza lub sprawdzanie bezpieczeństwa

    Reguła analizy statycznej lub narzędzie do sprawdzania bezpieczeństwa jest wyciszane (np. ignorowane w linii kodu lub wyłączona reguła), aby zmiana przeszła, zamiast naprawić to, co zostało zasygnalizowane.

  • Deserializacja nieufnych danych wejściowych

    Dane spoza granicy zaufania są deserializowane do obiektów lub oceniane, co jest klasycznym wzorcem zdalnego wykonania kodu.

  • Usunięta walidacja

    Walidacja lub sanityzacja danych wejściowych, która chroniła daną ścieżkę, została usunięta podczas refaktoryzacji, przez co nieprawidłowe lub złośliwe dane docierają teraz do logiki za nią.

Worked example

Zapytanie złożone z danych wejściowych użytkownika.

Dodawana jest funkcja wyszukiwania. Najszybszym sposobem na filtrowanie według wprowadzonego terminu jest wstawienie go bezpośrednio do łańcucha SQL. Działa to dla normalnych danych wejściowych, ale jest to luka wstrzyknięcia SQL: odpowiednio spreparowany termin może odczytać lub zmienić dane, do których nie powinien mieć dostępu.

search/query.ts+1 -1
- const rows = await db.query("SELECT * FROM items WHERE name = $1", [term])+ const rows = await db.query(`SELECT * FROM items WHERE name = '${term}'`)return rows
heygrcISO 27001:2022 A.8.28

Interpolacja terminu wyszukiwania do łańcucha SQL stanowi lukę wstrzyknięcia SQL: spreparowany termin może wydostać się z łańcucha i zostać wykonany jako logika zapytania. A.8.28 (bezpieczne programowanie) wymaga unikania właśnie tej klasy luk. Wróć do zapytania parametryzowanego, które traktuje dane wejściowe jako dane, a nie jako kod.

What an auditor does with this

Bezpieczne programowanie jest sprawdzane na poziomie praktyki i kodu.

Auditor szuka dowodów, że bezpieczne programowanie jest częścią procesu: przeglądy kodu, analiza statyczna, skanowanie zależności oraz że znalezione problemy są rozwiązywane. Zmiana, która wprowadza lukę wstrzyknięcia lub wyłącza sprawdzanie bezpieczeństwa, jest konkretnym dowodem na niepowodzenie tego procesu, a jest widoczna w diffie. Złapanie jej podczas przeglądu to zarówno naprawa, jak i dowód, że praktyka działa.

What this is, and is not

Przegląd, a nie pełny zestaw SAST.

heygrc sygnalizuje zmiany dotyczące A.8.28 i cytuje kontrolę, aby naprawa nastąpiła w pull request. Nie jest to zamiennik dla statycznej analizy ani testów bezpieczeństwa; to warstwa świadoma frameworku, która wiąże lukę w bezpiecznym programowaniu z kontrolą, którą narusza.