secure coding guidelines
Този урок обяснява защитеното кодиране, как да се избегнат уязвимости, свързани със сигурността, и предоставя насоки за кодиране и контролен списък за практики за сигурно кодиране:
За да има вградена сигурност в софтуера и да приложи насоки и най-добри практики за безопасно кодиране, цялата организация, заедно с екипа, идентифициран да работи по планираното разработване на приложения, трябва да вземе предвид някои аспекти.
Тук ще обсъдим онези аспекти, които помагат за разработването на защитен софтуер.
Това е толкова просто, колкото ако разработчикът не знае какво се разбира под „Сигурност за софтуера“ и как хакер може да хакне техния софтуер, да поеме контрола над него и да се опита да експлоатира, тогава е просто невъзможно да се кодира сигурен софтуер. И така, разработчикът първо трябва да разбере значението на защитеното кодиране.
Какво ще научите:
- Какво е сигурно кодиране?
- Насоки за безопасно кодиране
- Контролен списък за практики за защитен код
- Заключение
Какво е сигурно кодиране?
Сигурното кодиране е да се проектира и разработи софтуер от избягване на слабостите които водят до уязвимости, свързани със сигурността, като се придържат към посочените стандарти за сигурност и най-добрите отраслови практики.
Първият въпрос, който възниква в съзнанието на всеки, е ‘Колко сигурност се изисква за нашия софтуер’ или Кога можем да кажем, че нашият софтуер е защитен? и Какви са тези стандарти за сигурност ?
Измамите и заплахите за сигурността се увеличават от ден на ден и виждаме нови разновидности и начини за хакерство, дори в така наречения най-защитен софтуер.
Наскоро чухме, че програмата Aaadhar на UIDAI се подправя за лични данни. Следователно е наистина трудно да разберем колко голяма сигурност се изисква за софтуера и какви са стандартите за сигурност, освен ако не разберем заплахите, свързани със софтуера, и ги приоритизираме въз основа на рисковете за бизнеса.
Може да е трудно да се осигури 100% защита на софтуера, но ако екипът на програмата анализира Рискове и ценни книжа които участват в техния софтуер, т.е. потенциални заплахи и ако екипът може да се погрижи за смекчаване на тези рискове, би било добре от гледна точка на сигурността на приложението.
По този начин първата задача на екипа е да идентифицира и анализира рисковете и ценните книжа, които участват в тяхното приложение, и да разбере възможните варианти за смекчаване и да приеме най-добрия вариант съответно.
И така, веднъж идентифицирани десетте уязвимости класифицират почти всички атаки, с които една програма вероятно ще се сблъска. Това ще помогне за осмислянето на заплахите и ще даде приоритет на усилията за сигурност и развитие по-скоро към превенция, отколкото към смекчаване.
E.g. Въпреки че планираме да разработим приложение, свързано със здравеопазването, което обработва и съхранява здравните данни на индивида и личните му данни, най-големият риск за сигурността на приложението е да открадне личните здравни данни.
Намаляване на риска
За да смекчите риска,
- Внедряването на защита за достъп до данни от неоторизиран потребител трябва да се извършва с правилно удостоверяване и упълномощаване (прилагане на силна политика за пароли, удостоверяване с 2 фактора).
- Трябва да се внимава да няма изтичане на данни по време на предаване на данни от един източник на друг източник чрез прилагане на защитени канали (HTTPS) за предаване на данни и прилагане на криптиране на данни по време на транзит.
- Подправяне или кражба на данни в покой също е друга възможност. Следователно съхраняването на лични здравни данни (Използване на криптиране) е много важно.
Преди да преминете към „Стандарт за безопасно кодиране“, винаги е по-добре целият екип на програмата да има „Сесия за осведоменост относно сигурността“ и обсъждаме и обсъждаме,
- Изискването за сигурност за техния специфичен продукт.
- Възможни ползи, които хакерът би имал, като хакне тяхната система.
- Възможни начини и средства за компрометиране на сигурността на тяхното приложение.
- Следват общи практики за сигурност в подобна индустрия и домейн.
- Разбиране на типичните проблеми със сигурността на съответните им програми.
Също така помага на екипа да се справи по-добре, ако може да разбере Източници на уязвимостите че техният софтуер може да се изправи и причините, поради които е изграден софтуерът Лошо / неадекватно Сигурност .
Причини за неадекватно прилагане на сигурността
Като цяло, по-долу са дадени няколко причини за неадекватно прилагане на сигурността в приложението.
- Приоритет се дава на функционалното освобождаване, отколкото на аспектите на сигурността.
- Невежество или липса на информираност относно сигурността на софтуера и хакерите.
- Няма достатъчно яснота за програмата или за самия софтуерен дизайн.
- Сложността на програмата.
- Няма достатъчно данни, информация за активната система, където ще бъде внедрена.
- Без разглеждане на сигурността във фазите SDLC.
- Недостатъчно познаване и разбиране на спецификата на езика, използван в софтуера.
- Няма достатъчно познания за екипа и разработчиците относно насоките за кодиране на сигурността.
Знаем, че не всички разработчици и тестери са наясно със сигурността на дадено приложение и може да нямат задълбочено разбиране за уязвимостите и експлоитите на сигурността, особено за приложението, върху което ще работят. Като цяло те ще бъдат запознати с, ‘Как да кодирам функционално’ но не всички от тях знаят „Как да кодирам сигурно“.
Следователно много важният аспект за организацията да възприеме практиките за безопасно кодиране в своя софтуер е първо „Обучавай хора“ . И така, обучението на екипа им по аспекти на сигурното кодиране, най-добрите практики за кодиране на сигурността и правилното използване на инструментите е много важно.
Най-важният принцип на проектиране на софтуерната сигурност е да ‘Прилагане на сигурност по дизайн и по подразбиране’ .
Насоки за безопасно кодиране
За да се постигне сигурност, е много важно да имате „Стандарт за сигурно кодиране“ идентифицирани за програма в самото начало на разработването на приложението и това помага на екипа да се грижи за сигурните настройки по подразбиране за софтуера и да го предпази от атаките.
От съществено значение е да се гарантира, че целият екип е такъв Принудени да се придържат към този стандарт , независимо от кодиращия език и инструментите, които те използват в програмата.
По-долу са дадени няколко примера, които трябва да бъдат внедрени по подразбиране в дизайна на защитен код:
- Достъпът трябва да бъде ограничен само за удостоверени потребители и удостоверяването трябва да бъде приложено на всеки слой.
- Комуникационните канали трябва да бъдат криптирани, за да защитят маркерите за удостоверяване.
- Всички ключове, пароли и сертификати трябва да бъдат правилно съхранени и защитени.
- Трябва да се приложи шифроване на файлове, криптиране на база данни и криптиране на елементи от данни.
Избор на език за сигурно кодиране
Изборът на език за кодиране може да не зависи от защитеното кодиране. Няма нищо конкретно като защитен или незащитен език за кодиране за изграждане на защитен софтуер.
Точно как използваме език за програмиране, за да изградим софтуера и колко задълбочени познания има разработчикът за езика за кодиране при изпълнението на аспектите на сигурността.
Изяснено е обаче, че все пак Стандартите за сигурно кодиране са независими от избора на език, най-добрите практики за защитен код зависят от езика, зависят от платформата и от внедряването .
По този начин, за да има защитен код, е важно разработчикът да има задълбочени познания за езика, който се използва в програмата, така че най-добрите практики за сигурност да могат да бъдат внедрени лесно.
Пример:
- Вероятността от уязвимост на препълване на буфера се различава от език на език, но C, C ++ и Assembly се считат за най-податливи поради техните остарели възможности за управление на паметта. Няколко стандартни функции на lib C, като strcpy () и memcpy (), са уязвими за атаки с препълване на буфер. Неправилното използване на тези функции, чрез копиране на изходен буфер, който е твърде голям, за да се побере в целевия буфер, води до препълване на буфера.
- Често срещаният проблем в уеб-приложенията, базирани на Java, са възможните изтичания на ресурси, които могат да възникнат поради отворени системни ресурси, като връзки с файлове, сокети и бази данни.
Следващият аспект на сигурността е за инструменти, които да се използват в Приложната програма за оптимизиране на сигурността, като се използват инструменти като Интегрирана среда за развитие ще бъде най-полезно, тъй като те осигуряват много Сигнали на потребителите и обърнете внимание на тези предупреждения, за да се опитате да подобрите качеството на софтуера.
- Интегрирането на търговски библиотеки или библиотеки / плъгини с отворен код като Eclipse, Spring Tool Suite, RAD с IDE помага на разработчиците да напишат защитен код, като открива и идентифицира потенциално уязвим код и предоставя предупреждения за констатации, свързани с изпълнение на злонамерен файл, изтичане на информация и неправилно боравене с грешки.
Също така е важно да използвате Статични и динамични анализатори за подобряване на аспектите на сигурността на софтуера. Като цяло статичните анализатори са оптимизирани за специфични видове грешки, така че в крайна сметка намират голям брой фалшиви положителни резултати, докато идентифицират конкретни грешки. Понякога има възможности и те да пропуснат действителните грешки.
Следователно се препоръчва да се използва множество статични анализатори за по-добро покритие на различни видове грешки и за избягване на много фалшиви положителни резултати. Понякога също се препоръчва да се извърши ръчно тестване да се премахване на фалшиви положителни резултати .
Правила и препоръки за сигурно кодиране
Добре е Програмата да определи набор от „Правила и препоръки за сигурно кодиране“ на които изходният код може да бъде оценен за съответствие, така че тестерите да могат да изпълнят „Тестване за съответствие“ за всеки от тези стандарти за сигурно кодиране.
Следователно кодът за защита може да бъде удостоверен като Съответстващ или Несъответстващ, като се използват тези правила спрямо зададения бенчмарк.
Малко от правилата, споменати по-долу, могат да се използват за проверка за нарушения на сигурността:
- Файловете трябва да бъдат затворени, когато вече не са необходими.
- Винаги при преминаване на структура през граница, изтичането на информация трябва да се избягва.
- Обектите трябва да бъдат декларирани с подходяща продължителност на съхранение.
Така че, тестовите случаи за проверка на тези правила трябва да бъдат проектирани и проведени, за да се провери съответствието с съответствието. Също така е установено, че повечето от уязвимостите са причинени от типични често срещани програмни грешки.
Следователно разработчикът трябва да разбере ‘Несигурен метод на кодиране’ , докато те също така се учат на най-добрите практики за безопасно кодиране. Идеално е да се съберат най-често срещаните програмни грешки, които допринасят за уязвимостите в сигурността на тяхното приложение, за да могат да се погрижат за тях при кодиране.
Такива типични програмни грешки се допринасят главно от препълване на буфера, скриптове между сайтове и недостатъци на инжектиране.
Някои от типичните уязвимости при програмиране включват,
- SQL инжекция (неправилно неутрализиране на специални елементи, използвани в SQL команда).
- Целочислено препълване.
- Препълване на буфера (Буферно копиране без проверка на размера на входа).
- Неконтролиран низ за форматиране.
- Липсва удостоверяване и упълномощаване (Неправилно упълномощаване).
- Излагане на чувствителни данни.
- Неправилно обработване на грешки.
Някои от тези грешки могат да доведат до срив на системата, неочакван достъп до системата и контрол над софтуера, загубен от хакерите.
Често срещани грешки при програмирането, които трябва да се избягват
По-долу са изброени няколко често срещани грешки при програмиране, които трябва да се избягват:
- Неправилно неутрализиране на специални елементи, използвани в SQL команда (‘SQL Injection’).
- Буферно копиране, без да се проверява размерът на входа („Класическо препълване на буфера“).
- Липсва удостоверяване за критична функция.
- Липсващо или неправилно разрешение.
- Използване на твърдо кодирани пълномощия.
- Липсващо криптиране на чувствителни данни.
- Неограничено качване на файл с опасен тип.
- Разчитане на ненадеждни входове в решение за сигурност.
- Изпълнение с излишни привилегии.
- Подправяне на заявки между сайтове (CSRF).
- Изтегляне на код без проверка на почтеността.
- Неправилно изчисляване на размера на буфера.
- Неправилно ограничаване на прекомерните опити за удостоверяване.
- Пренасочване на URL към ненадежден сайт (‘Open Redirect’).
- Неконтролиран низ за форматиране.
- Използване на еднопосочен хеш без сол.
Контролен списък за практики за защитен код
И накрая, но не на последно място, след като разгледат всички горепосочени точки от аспектите на сигурната разработка на софтуер, разработчиците трябва да следват Създаден е контролен списък за практиките за защитен код за да се гарантира, че нещата няма да бъдат пропуснати. По-долу са дадени няколко, но не изчерпателен списък.
Проверка на входа:
как да направите списък
- Не се доверявайте на въвеждането, помислете за централизирано валидиране на входа
- Не разчитайте на проверка от страна на клиента.
- Внимавайте с проблемите с канонизацията.
- Ограничете, отхвърлете и дезинфекцирайте входа. Проверете за тип, дължина, формат и обхват.
Удостоверяване:
- Сайт на дяла от анонимна, идентифицирана и удостоверена зона.
- Използвайте силни пароли.
- Поддържа периоди на изтичане на паролата и деактивиране на акаунта.
- Не съхранявайте идентификационни данни (използвайте еднопосочни хешове със сол).
- Шифровайте комуникационните канали, за да защитите маркери за удостоверяване.
- Предавайте бисквитки за удостоверяване на формуляри само чрез HTTPS връзки.
Разрешение:
- Използвайте акаунти с най-малко привилегии.
- Помислете за подробност на оторизацията.
- Налагане на разделяне на привилегиите.
- Ограничете достъпа на потребителя до ресурси на системно ниво.
- Използвайте протокола OAuth 2.0 за удостоверяване и упълномощаване.
- Проверка на API за извършване.
- Допустими методи в белия списък.
- Защитете привилегированите действия и чувствителните колекции от ресурси.
- Защита срещу подправяне на ресурси между сайтове (CSRF).
Управление на сесията:
- Създайте идентификатор на сесия на сървъра.
- Прекратете сесията с излизане.
- Генерирайте нова сесия за повторно удостоверяване.
- Задайте атрибут ‘secure’ за бисквитки, предадени през TLS.
Криптография:
- Използвайте криптография, докато ‘Данни в движение, Данни в съхранение, Данни в движение, Целостта на съобщенията’.
- Не развивайте своя. Използвайте изпитани функции на платформата.
- Дръжте нешифрованите данни близо до алгоритъма.
- Използвайте правилния алгоритъм и размер на ключа.
- Избягвайте управлението на ключове (използвайте DPAPI).
- Циклирайте ключовете си периодично.
- Съхранявайте ключове на ограничено място.
Регистрация и одит:
- Идентифицирайте злонамерено поведение.
- Знайте как изглежда добрият трафик.
- Одит и регистрационна дейност през всички нива на приложения.
- Сигурен достъп до регистрационни файлове.
- Архивирайте и редовно анализирайте регистрационните файлове.
Изходно кодиране:
- Извършване на „Input Validation (XML, JSON….)“.
- Използвайте параметризирана заявка.
- Извършете „Проверка на схемата“.
- Извършете кодиране (XML, JSON ..).
- Изпратете заглавия на защитата.
Справка: ' Контролен списък на практиките за безопасно кодиране на OWASP (Накратко, SCP контролен списък) '
Таблично обобщение на контролния списък за сигурно кодиране
Таблицата по-долу обобщава ‘Неща, които трябва да запомните за защитен код’ на приложение.
# | Какво? |
---|---|
7 | За да се гарантира, че целият екип е принуден да се придържа към стандарта за безопасно кодиране. |
един | За да разберете ясно „Какво е защитен код“? |
две | За да разберете общите „Източници на уязвимостите“. |
3 | Да проведе „Екип за осведоменост за сигурността“. |
4 | Да идентифицира и анализира „Рискове и ценни книжа“, включени в приложението и методите за „смекчаване“. |
5 | Да се „обучи екипът“ за стандарти за безопасно кодиране, най-добри практики и насоки. |
6 | За дефиниране на „Стандарт за сигурно кодиране“ |
8 | Да използвате „Лесен за изпълнение език“ и да имате „задълбочени познания“ за него. |
9 | Да се използват инструменти IDE (Интегрирана среда за разработка) |
10 | Да се използват „статични и динамични анализатори“ и „множество статични анализатори“ за премахване на „фалшиви положителни резултати“ |
единадесет | За да извършите „Ръчно тестване“, където се изисква да се идентифицира грешката, пропускайте. |
12 | Да се определи набор от „Правила и препоръки за безопасно кодиране“ |
13 | Да се извърши „Тестване за съответствие“ за зададените правила. |
14. | За да разберете „Несигурен метод на кодиране“ и да съберете „Общи грешки при програмиране“. |
петнадесет | Да се спазва стриктно ‘SCP Checklist’ |
Заключение
Надяваме се, че този урок ще бъде вашето най-добро ръководство за осигуряване на софтуерна сигурност.
Насоките за кодиране за сигурно разработване на софтуер бяха изброени тук с прости думи с примери за лесното ви разбиране на концепцията.
Честито четене !!
Препоръчително четене
- Тестване на сигурността (Пълно ръководство)
- 30-те НАЙ-ДОБРИ компании за киберсигурност през 2021 г. (малки фирми до ниво предприятие)
- Основи на компютърното програмиране за начинаещи | Урок за кодиране
- Топ 15 най-добри безплатни редактори на кодове за перфектно кодиране
- Урок за тестване на SQL инжектиране (Пример и предотвратяване на атака на SQL инжектиране)
- Разработчиците не са добри изпитатели. Какво казваш?
- ISTQB Foundation Формат на изпита и насоки за решаване на документи
- Указания за тестване на сигурността на мобилните приложения