보안 코딩이란 무엇입니까? 기술 및 코드 예제

이 기사의 주요 내용:

보안 코딩은 XSS 및 메모리 누수와 같은 취약성을 조기에 해결하여 소프트웨어 복원력을 높이고 위험을 줄입니다.
사전 예방적 관행은 비용이 많이 드는 릴리스 후 수정을 방지하고 사용자 신뢰를 조성하여 시간과 비용을 절약합니다.
모범 사례에는 입력 유효성 검사, 타사 코드 보안, 지속적인 검사를 위한 SAST와 같은 도구 활용이 포함됩니다.
OWASP, CERT 및 NIST의 표준은 개발자가 안전하고 신뢰할 수 있는 애플리케이션을 구축하는 데 도움이 됩니다.
Wiz Code는 실시간 스캔, 실행 가능한 피드백 및 SDLC를 보호하기 위한 지침을 통해 안전한 코딩을 지원합니다.

보안 코딩이란 무엇입니까?

보안 코딩은 개발 초기에 보안 모범 사례, 기술 및 도구를 적용하여 보안 취약성에 저항하는 소프트웨어를 개발하는 방법입니다. 보안 코딩은 사용자 경험에만 대해 생각하는 대신 소프트웨어 개발 수명 주기가 시작될 때부터 모든 기능을 보안 조치에 맞게 조정합니다.

예를 들어, 클라이언트의 모든 데이터를 삭제하지 않고 수락하는 응용 프로그램은 구현, 사용 및 유지 관리가 더 쉬울 수 있습니다. 그러나 공격자가 악성 코드를 주입할 수 있는 진입점을 엽니다.

The Secure Coding Best Practices [Cheat Sheet]

With curated insights and easy-to-follow code snippets, this 11-page cheat sheet simplifies complex security concepts, empowering every developer to build secure, reliable applications.

Download Cheat Sheet

보안 코딩이 중요한 이유는 무엇인가요?

보안 코딩은 소프트웨어의 DNA에 보안을 내장하여 SQL 주입, 버퍼 오버플로, 교차 사이트 스크립팅 등과 같은 취약성을 방지합니다. 이는 단순히 침해를 방지하는 것을 넘어 사용자 신뢰를 보호하고, 보안을 좌회전시키며, 데이터 보호법의 엄격한 표준을 충족하는 방법입니다.

그 대가는? 출시 후 불쾌한 놀라움이 줄어들고, 앱이 더 강력해지고, 사용자와 조직 모두에 대한 보호가 향상됩니다.

보안 소프트웨어 구축을 위한 7가지 보안 코딩 기술

안전한 소프트웨어 개발 프로세스는 취약성을 방지하고 애플리케이션을 안전하게 유지하는 데 도움이 되는 올바른 코딩 관행을 따르는 것으로 시작됩니다. 만약 너라면'더 심층적인 리소스를 찾고 있다면 OWASP 보안 코딩 요구 사항을 확인하십시오. 개발자 가이드.

그동안 보다 안전한 소프트웨어 시스템을 구축하기 위해 즉시 사용할 수 있는 몇 가지 주요 기술은 다음과 같습니다.

1. 최신 언어 및 도구 사용

많은 메모리 관련 보안 취약성은 수동 메모리 관리와 기본 제공 메모리 검사 없이 프로그래밍 언어에 영향을 미칩니다. 새 프로젝트를 시작할 때 실제로 C/C++가 필요한지 확인하고, 필요하다면 다음을 사용하십시오. 스마트 포인터 그리고 정적 코드 분석기 언어 결함의 영향을 최소화합니다.

시스템 프로그래밍 기능이 필요한 경우 다음과 같은 최신 언어와 같은 최신 언어가 필요합니다. 녹 해당 형식 시스템은 컴파일 타임에 메모리 사용을 확인하기 때문에 좋은 선택이 될 수 있습니다. 지그(Zig) 숨겨진 제어 흐름이나 메모리 할당이 없기 때문에 좋은 대안이 될 수도 있습니다.

시스템 프로그래밍 기능이 필요하지 않은 경우 Java 또는 C#과 같은 가비지 수집 언어를 사용하면 많은 메모리 문제로부터 보호할 수 있습니다.

2. 입력 및 출력 데이터의 유효성 검사 및 삭제Validate and sanitize input and output data

검증되지 않은 사용자 데이터는 주입 결함의 주요 원인입니다. 그렇기 때문에 시스템에 들어오는 모든 데이터의 유효성을 검사하는 것이 매우 중요합니다. 위생은 사용성을 희생하지 않고 보안을 유지할 수 있는 또 다른 단계입니다. 사용자 입력이 유효하지 않은 경우 거부하는 대신 위생 기능은 문제가 있는 입력 부분(예: HTML 내부의 JavaScript)을 잘라내고 나머지 데이터를 사용합니다. 클라이언트-서버 환경에서 실행 중인 경우 서버에서 이 유효성 검사 및 정리가 수행되는지 확인합니다. 즉, 다음을 추가합니다. 검사기 및 소독제 사용자 데이터를 허용하는 모든 API 엔드포인트에. 또한 유효성을 검사하기 쉬운 데이터 형식을 선택하는 것을 의미할 수도 있습니다(예: 완전한 HTML 대신 간단한 Markdown 수락).

입력 데이터를 깨끗하게 유지하는 것이 항상 가능한 것은 아닙니다. 유효성 검사 라이브러리에도 버그가 있습니다. 사용자에게 유출되지 않도록 하려면 사용자 입력을 기반으로 하는 출력만 안전한 방식으로 표시해야 합니다(즉, HTML을 렌더링하지 않음).

3. 타사 코드 무결성 확인

서드파티 라이브러리와 프레임워크는 개발 속도를 높이기 위한 생명의 은인이지만, 끈이 붙어 있습니다—그것들은 여러분의 집에서 만들어지지 않았습니다. 빌드 프로세스에 대한 입력처럼 취급하십시오: 신중하게 검사되고 통제됩니다.

불쾌한 놀라움을 피하고 싶습니까? 종속성 고정 특정 버전 또는 해시 테스트되지 않은 업데이트가 프로덕션에 침투하는 것을 방지합니다. 이러한 라이브러리를 정기적으로 감사하고 업데이트하는 것은 매력적이지 않지만 오래된 코드가 아킬레스건이 되는 것을 피할 수 있는 유일한 방법입니다.

4. 엄격한 접근 제어 시행

액세스 제어는 코드 및 리소스를 보거나 수정할 수 있는 사용자를 제한하여 권한이 없는 사용자로부터 민감한 기능과 데이터를 보호합니다. 에 충실 최소 권한의 원칙: 사용자에게 업무 수행에 필요한 것만 제공하고, 그 이상도 그 이하도 아닙니다.

보안을 강화하려면 RBAC(역할 기반 액세스 제어) 및 MFA(다단계 인증)를 구현하는 것이 좋습니다. 이러한 조치는 공격 표면을 더욱 줄이고 권한이 없는 개인이 중요한 시스템이나 데이터에 액세스할 수 없도록 합니다.

5. 적절한 오류 처리 및 로깅 구현

아무도 공격자에게 로드맵을 건네주고 싶어하지 않지만, 과도하게 상세한 오류 메시지가 바로 그런 결과를 초래할 수 있습니다. 내부 세부 정보(예: 스택 추적 및 데이터베이스 오류)를 사용자가 손에 넣지 못하도록 합니다. 대신 팀의 눈에만 볼 수 있도록 안전하고 신중하게 기록하십시오.

좋은 로그는 무슨 일이 언제, 왜 일어났는지 등을 알려줍니다. 수상한 것이 있는지 모니터링하되 민감한 데이터를 기록하여 과도하게 사용하지 마십시오. 여기서 핵심은 균형이며, 노출하는 것이 아니라 문제를 해결하는 것입니다.

6. 코드 검토 자동화

수동 검토도 중요하지만 자동화가 필요합니다. 다음과 같은 자동화된 도구 정적 애플리케이션 보안 테스트(SAST) 그리고 Linter는 인간이 할 수 있는 것보다 더 빠르게 취약점과 코딩 오류를 표시합니다.

이러한 도구를 CI/CD 파이프라인에 연결하면 모든 코드 변경 사항이 병합되기 전에 한 번 반복됩니다. 즉각적인 피드백을 통해 개발자에게 최신 정보를 제공하고 보안 모범 사례가 최우선 과제로 유지되도록 합니다.

7. 코드 난독화 기법 적용

코드 난독화는 앱을 완벽하게 만들지는 않지만 공격자의 속도를 늦춥니다. 변수의 이름을 횡설수설하게 바꾸고, 문자열을 인코딩하고, 코드를 재구성하면 리버스 엔지니어링하거나 지적 재산을 훔치기가 더 어려워집니다.

위장을 추가하는 것으로 생각하십시오: 앱은 여전히 사용자를 위해 원활하게 실행되지만 악의적인 행위자는 침입하거나 그들이 보는 것을 이해하기가 훨씬 더 어렵다는 것을 알게 될 것입니다. 모든 장애물이 도움이 됩니다.

일반 코드 소프트웨어 취약점

소프트웨어 개발자와 보안 연구원이 식별한 일반적인 보안 취약점을 살펴보겠습니다. 메모리 취약성과 같은 낮은 수준의 문제에서 주입 공격과 같은 높은 수준의 문제로 이동할 것입니다.

버퍼 오버플로

버퍼 오버플로로 인해 애플리케이션이 충돌하거나 공격자가 다른 버퍼에 데이터를 쓸 수 있습니다.

C/C++와 같은 시스템 프로그래밍 언어는 이 취약점에 취약합니다. 그들은 메모리 관리를 명시 적으로 허용하고 요구하지만 너무 늦을 때까지 메모리 액세스를 확인하지 않습니다. 정의 시간에 할당한 것보다 더 많은 데이터를 버퍼에 쓰는 경우 C는 버퍼의 끝에서 오는 모든 메모리 데이터를 재정의합니다.

C에서 버퍼 오버플로의 예 :

정수 b[5];
  나[5] = 999; 버퍼는 0에서 4까지만 이동합니다.

무료 사용 후 사용

free 후 사용은 힙에서 메모리를 확보하지만 이전 포인터를 계속 사용할 때 발생합니다.

다시 말하지만, 이 취약점은 메모리를 수동으로 관리해야 하는 C/C++와 같이 가비지 수집이 없는 언어에서 두드러집니다. 메모리에는 스택과 힙의 두 가지 유형이 있습니다. 이 언어는 컴파일 시간에 알 수 없는 동적 크기의 데이터를 보유할 수 없는 스택을 자동으로 관리합니다. 힙은 동적 데이터용이지만 수동으로 공간을 할당하고 확보해야 합니다. 해제는 운영 체제에 메모리가 더 이상 필요하지 않다고 알려주는 것을 의미하므로 나중에 포인터와 함께 사용하면 불법 액세스는 할당되지 않은 메모리 위치로 이동합니다.

C에서 무료 사용 예:

char* p = (char*)malloc (16);
      p = strdup("일부 텍스트!");
      무료(p);
      printf("%s", p); 해제된 메모리에 있는 내용을 인쇄합니다.

더블 프리

double free의 경우 이미 해제한 후 힙 메모리를 해제합니다.

Double free는 수동 메모리 관리 언어에서 발생하는 문제로, 특정 메모리 범위가 더 이상 필요하지 않다는 것을 운영 체제에 명시적으로 알려야 합니다. 이렇게 두 번 하면 use after free 문제와 유사한 충돌이 발생합니다. 이것은 일반적으로 어느 시점에서 해제되는 서로에 대한 포인터가 있는 여러 개체가 있을 때 발생합니다. Double free는 첫 번째 free 전에 참조된 포인터의 메모리를 손상시킬 수 있습니다.

C에서 더블 프리의 예 :

char* p = (char*)malloc (16);
      p = strdup("일부 텍스트!");
      무료(p);
      무료(p); 해제 된 메모리에있는 내용을 손상시킵니다.

안전하지 않은 deserialization

안전하지 않은 역직렬화는 충분한 검사 없이 외부 데이터 구조(예: JSON, XML 등)를 내부 데이터 구조(예: 객체, 배열 등)로 직접 변환하는 것을 포함합니다.

안전하지 않은 deserialization은 모든 종류의 응용 프로그램에서 일반적인 취약점입니다. 개발 중에 삭제되지 않은 데이터를 허용하는 것이 좋을 수 있지만 프로덕션 환경에서 수행되는 경우 사용자는 사전 통지 없이 악성 데이터를 몰래 넣을 수 있습니다.

JSON에서 안전하지 않은 역직렬화의 예:

{
  "이름": "본보기",
  "메일 주소": "email@example.com",
  "isAdmin (영문)": true // 서버에서 삭제해야 합니다.
}

메모리 누수

메모리 누수를 사용하면 애플리케이션이 무제한 메모리를 사용할 수 있습니다. 사용 가능한 메모리를 모두 사용하고 더 많은 메모리를 요청하면 응용 프로그램이 중단됩니다.

충분히 복잡한 모든 응용 프로그램이 이 취약점에 취약합니다. 가비지 수집 된 언어조차도 메모리 누수로부터 안전하지 않습니다. 가비지 수집 언어를 사용하면 가비지 수집기가 관리할 수 없는 데이터 구조를 구축할 수 있습니다.

주입 결함

사용자 입력을 검증하지 않고 코드로 실행하는 것을 주입 결함이라고 합니다.

이 문제는 사용되는 프로그래밍 언어에 관계없이 모든 애플리케이션에 영향을 줄 수 있습니다. 애플리케이션을 주입 결함에 취약하게 만드는 한 가지 방법은 사용자가 사용자 지정 코드를 기능으로 추가하고 실행을 제대로 샌드박스하지 않도록 허용하는 것입니다. 공격자가 실행 가능한 메모리 위치에 코드를 쓸 수 있도록 하는 버퍼 오버플로는 애플리케이션이 주입 결함에 취약해질 수 있는 또 다른 방법입니다.

크로스 사이트 스크립팅(XSS)

크로스 사이트 스크립팅은 주입 결함의 웹 특정 버전입니다. 여기서 공격자는 HTML 마크업 내에 숨겨진 사용자 지정 JavaScript를 삽입합니다.

XSS는 모든 웹 사이트에서 발생할 수 있습니다. 마크업과 실행 가능한 코드는 웹에 긴밀하게 통합되어 있기 때문에 JavaScript를 HTML에 몰래 삽입하기 쉬우며, 이로 인해 민감한 데이터가 유출됩니다.

HTML 및 JavaScript의 XSS 예:

<-- 이렇게 하면 가져오기 요청이 전송됩니다. 
마우스가 위에 있을 때 <p> 요소-->
<p onmouseover="fetch('//example.com')">전 세계 여러분 안녕하세요!</p>

XML 외부 엔티티(XXE)

XML 외부 엔터티는 주입 결함의 또 다른 인스턴스입니다. XML을 사용하는 모든 응용 프로그램은 이 공격에 취약합니다. XML의 외부 엔터티 이면에 있는 아이디어는 기존 XML 파일을 재사용할 수 있도록 하는 것입니다. 그러나 공격자는 이 기능을 사용하여 개인 XML 파일에 대한 링크를 포함할 수 있으므로 업로드된 XML 파일을 통해 간접적으로 개인 데이터를 읽을 수 있습니다.

외부 XML 엔터티 삽입의 예:

<?xml 버전="1.0" 인코딩 ="ISO-8859-1 인증"?>
<! DOCTYPE A [  
  <! 요소 A ANY >
  <-- 이것은 xxe라는 새 엔티티를 정의합니다.
  개인 파일에서 -->
  <! 엔티티 XXE 시스템 "file:///etc/passwd" >
]>
<-- 여기서 엔티티는 표시되도록 렌더링됩니다. 
파일 내용 -->
<a>&xxe;</a>

안전하지 않은 직접 개체 참조(IDOR)

공용 API가 순차 ID를 가진 개체를 직접 참조할 수 있도록 허용하면 IDOR을 통해 공격자가 서버에 있는 모든 개체의 ID를 추측할 수 있습니다.

이 문제는 순차 ID가 개체를 참조하는 데 사용되는 모든 곳에서 발생할 수 있으며 권한 부여 없이 ID를 사용하여 공용 및 개인 개체를 참조할 때 특히 심각합니다.

예시 URL:

https://example.com/users/4539

https://example.com/users/4540

https://example.com/users/4541

디렉터리 순회(일명 경로 순회)

또 다른 주입 결함은 공격자가 파일 이름 입력을 통해 경로 또는 디렉터리 구조를 통과할 수 있는 경우입니다.

파일 이름 입력을 허용하는 모든 응용 프로그램이 이 취약점의 피해자가 될 수 있습니다. 디렉터리 순회는 사용자가 상대 경로를 통해 서로를 참조하는 여러 파일을 업로드할 때 발생할 수 있습니다. 공격자는 다음과 같은 파일 순회 경로를 사용할 수 있습니다. ".." 서버의 업로드 디렉토리에서 관리자 또는 다른 사용자의 파일이 있는 디렉토리로 이동합니다.

JavaScript에서 디렉터리 순회의 예Node.js:

이것은 개인 자바 스크립트 파일을로드합니다.
const 템플릿 = require(".. /.. /.. /서버/config/database")
  render(템플릿)

위즈 아카데미

Secure SDLC

더 알아보기

코드 보안 표준

보안 코딩 표준은 개발자가 보안 소프트웨어를 만들고 취약성을 최소화하기 위해 따르는 일련의 지침 및 모범 사례입니다. 공격자가 악용할 수 있는 일반적인 코딩 실수와 약점을 해결하여 보다 탄력적이고 저항력 있는 코드를 만드는 것을 목표로 합니다.

다음은 따라야 할 일반적인 보안 코드 표준입니다.

1. OWASP 보안 코딩 관행:

OWASP SCP(Secure Coding Practices)는 입력 유효성 검사, 인증, 세션 관리, 암호화 및 오류 처리와 같은 소프트웨어 보안을 개선하기 위한 주요 영역에 중점을 둔 Open Web Application Security Project의 지침입니다. 더 안전한 코드를 위한 로드맵입니다. 최종 배포에 대한 첫 번째 커밋.

2. CERT 보안 코딩 표준:

CERT SCS(Secure Coding Standards)는 개발자가 보안 코드를 작성하고 취약성을 방지하는 데 도움이 되도록 Carnegie Mellon University의 SEI(Software Engineering Institute)에서 개발한 일련의 지침 및 권장 사항입니다. 중점 분야:

언어별 지침:C, C++, Java, Android 및 Perl에 대한 권장 사항을 제공하여 해당 언어의 일반적인 취약점을 해결합니다.
방어 프로그래밍:악용을 방지하기 위해 오류를 예측하고 적절하게 처리하는 것을 강조합니다.
메모리 관리:특히 C 및 C++와 같은 언어에서 버퍼 오버플로 및 메모리 누수를 방지하는 데 중점을 둡니다.

3. NIST 보안 코딩 지침:

NIST 보안 코딩 지침(NIST Special Publication 800-218이라고도 함)은 입력 유효성 검사, 인증, 암호화 및 오류 처리와 같은 중요한 영역에 중점을 두고 주입 공격, 세션 하이재킹 및 메모리 문제가 소프트웨어에서 발생하지 않도록 명확한 조언을 제공합니다. 정부에서 지원하는 승인 도장을 원하는 경우 코드 보안 관행, 이것은 당신의 이동입니다.

4. ISO/IEC 27001:

ISO/IEC 27001은 국제 정보 보안 표준입니다. 그 동안'특별히 보안 코딩 표준은 아니지만 포괄적인 보안 관리 접근 방식의 일부로 보안 코딩 관행에 대한 요구 사항을 포함합니다. 부록 A, Control 8.28: Secure Coding Practices는 특히 보안 코딩에 중점을 두고 조직이 다음을 수행해야 하는 방법을 강조합니다.

사내 개발 및 타사 코드를 위한 안전한 코딩 프로세스를 개발합니다.
진화하는 위협과 취약성에 대한 정보를 받아보세요.
강력한 보안 코딩 원칙을 구현하여 이러한 문제를 해결합니다.

Wiz로 안전한 소프트웨어 개발 수명 주기 보장

보안 코딩은 데이터 형식 및 프로그래밍 언어 선택부터 입력 및 출력 계획, 구현에 이르기까지 소프트웨어 개발의 모든 측면에 영향을 미치는 관행입니다.

우리'소개하게 되어 기쁩니다. 위즈 코드, 개발자와 보안 팀이 전체 소프트웨어 개발 수명 주기 동안 강력한 보안 코딩 관행을 구현하고 유지할 수 있도록 설계된 최신 혁신입니다!

Wiz Code는 개발의 모든 단계를 포괄하도록 클라우드 보안 플랫폼을 확장하여 보안 코딩 이니셔티브를 지원하는 강력한 기능을 제공합니다.

통합 코드 스캐닝: IDE 및 코드 리포지토리에서 취약성, 구성 오류 및 규정 준수 문제를 직접 감지하여 프로덕션에 도달하기 전에 잠재적인 문제를 파악합니다.
실시간 보안 피드백: 코딩할 때 즉각적인 보안 인사이트를 얻을 수 있으므로 개발자가 문제를 즉시 해결하고 이동 중에도 안전한 코딩 방법을 배울 수 있습니다.
클라우드-코드 추적성: 프로덕션 환경에서 발견된 위험을 해당 위험을 도입한 특정 코드 및 팀으로 역추적하여 신속한 근본 원인 분석 및 수정을 용이하게 합니다.
코드 내 수정 지침: 개발 환경 내에서 바로 보안 문제를 해결하기 위한 실행 가능한 컨텍스트 인식 권장 사항을 받습니다.
포괄적인 언어 지원: 다양한 프로그래밍 언어 및 프레임워크에서 안전한 코딩 모범 사례를 활용할 수 있습니다.

Secure your SDLC from start to finish

See why Wiz is one of the few cloud security platforms that security and devops teams both love to use.

데모 신청하기

보안 코딩이란 무엇입니까? 개요 및 모범 사례Overview and Best Practices

Main Takeaways from Secure Coding: