Firefox 보안 지침

목적

이 문서는 Firefox와 Thunderbird와 같이, 모든 클라이언트 애플리케이션에 일반적으로 적용되는 보안 지침을 간략하게 설명합니다.

안전한 코딩 원칙

애플리케이션이 아래 OWASP 보안 코딩 원칙을 따르는지 확인하십시오.

  1. 공격 노출 영역 최소화
  2. 보안 기본값 설정
  3. 최소 권한의 원칙
  4. 심층 방어의 원칙
  5. 안전한 실패
  6. 서비스를 믿지 마라
  7. 보안을 단순하게 유지하라
  8. 보안 문제를 올바르게 해결하라

입력 유효성 검사

  1. 애플리케이션이 사용자 입력을 받나요?

    1. 사용자 데이터를 받을 때 적정한 최댓값이 적용되는지 확인하기 위해 입력 위치를 샘플링하여 확인하세요.
    2. 애플리케이션이 허용된 문자 집합만 입력받는지 확인하기 위해 입력 위치를 샘플링하여 확인하세요.
    3. 거부 목록 대신 허용 목록을 사용하는지 확인하세요.

  2. 애플리케이션이 어떤 방식으로든 사용자의 입력을 화면에 표시하나요?

    1. 응답에서 사용자가 제공했던 콘텐츠가 올바르게 인코딩되었는지 확인하기 위해 입력과 출력 위치를 샘플링하여 확인하세요.

Chrome JS - 위험한 함수

다음 함수 중 사용하고 있는 것이 있나요?

그렇다면 함수가 안전한지 확인하고 더 나은 대안이 있는지 확인하세요.

이름 위험 수준 문제 해결 방법
eval 매우 높음 JavaScript 파서를 호출하기 때문에, 신뢰할 수 없는 입력과 함께 사용하면 위험합니다. 가능하다면 항상 eval을 사용하지 마세요.
setTimeout(string, time) 매우 높음 eval처럼 동작합니다. setTimeout(function, time, param1, param2, …)을 사용하세요.

C++ - 위험한 함수

다음 함수 중 사용하고 있는 것이 있나요?

그렇다면 함수가 안전한지 확인하고 더 나은 대안이 있는지 확인하세요.

이름 위험 수준 문제 해결 방법
gets 매우 높음 경계 검사 없음 gets를 사욜하지 마세요. 대신 fgets를 사용하세요.
strcpy 매우 높음 경계 검사 없음 strcpy는 소스 문자열이 상수이고, 대상이 이를 수용할 만큼 큰 경우에만 안전합니다. 그렇지 않으면 strncpy를 사용하세요.
sprintf 매우 높음 경계 검사 없음, 형식 문자열 공격 sprintf는 안전하게 사용하기 매우 어렵습니다. 대신 snprintf를 사용하세요.
scanf, sscanf 높음 경계 검사가 없을 수 있음, 형식 문자열 공격 모든 % 지시어가 해당 인수의 유형과 일치하는지 확인하세요. 경계 검사 없이 '%s' 지시문을 사용하지 마세요. x가 해당 인수의 버퍼 크기인 '%xs'를 사용하세요. 형식 문자열에 신뢰할 수 없고 검증되지 않은 데이터를 사용하지 마세요.
strcat 높음 경계 검사 없음 입력 크기가 잘 알려져 있지 않고, 고정되어 있지 않으면 strncat를 대신 사용하세요.
printf, fprintf, snprintf, vfprintf, vsprintf, syslog 높음 형식 문자열 공격 형식 문자열에 신뢰할 수 없고 검증되지 않은 데이터를 사용하지 마세요. 형식 문자열이 웹 콘텐츠나 사용자 입력의 영향을 받을 수 있는 경우, 이러한 함수를 호출하기 전에 % 지시문의 적절한 수와 유형을 확인하세요. 대상 크기 인수가 올바른지 확인하세요.
strncpy, fgets, strncat 낮음 null 종료가 없을 수 있음 항상 대상 버퍼를 null 통해 명시적으로 종료하세요. 크기 인수가 올바른지 확인하세요. null 문자를 추가할 공간을 대상 버퍼에 남겨두세요!

URL

  1. 애플리케이션이 신뢰할 수 없는 데이터를 사용하여 URL을 구성하나요?

    • 이런 데이터는 사용하기 전에 불필요한 부분은 적절히 삭제하고, 인코딩하세요.
    • 사용하거나 저장하기 전에 이런 URL에서 얻은 데이터를 확인하세요.

  2. 애플리케이션이 리다이렉션을 따르나요?

    • 원본 요청 URI뿐만 아니라 리다이렉션에 대해서도 보안 검사가 수행되는지 확인하세요.

보안 제어

  1. 애플리케이션이 적절한 권한 검사를 구현하나요?

    • API가 사용 가능한 곳에서 사용 되는지 확인하세요. (예: shouldload, 등)
    • 애플리케이션이 안전하게 실패하는지 확인하세요.

원격 시스템 접근

  1. 애플리케이션이 원격 시스템에 접근하나요?
  • TLS를 사용하지 않을 타당한 이유가 없는 한 TLS를 사용하세요.
  • 사용자 동의 없이 사용자 정보가 전송되지 않도록 하세요.

정보 저장

  1. 파일 저장소

    1. 애플리케이션은 생성된 모든 파일이 허용된 경로에 있는지 확인해야 합니다.

    2. 파일 이름이 신뢰할 수 없는 데이터로 만들어지나요?

      • 데이터가 적절하게 인코딩되었는지 확인하세요.

    3. 파일이 허용 가능한 유형인지 확인하세요.

    4. 파일은 어느 정도의 크기 제한을 초과할 수 없습니다.

  2. 데이터베이스 저장소

    1. 데이터베이스로 전송된 신뢰할 수 없는 정보가 적절하게 삭제되었는지 확인하세요.
    2. 가능하다면 주입 공격을 방지하기 위해 타입 안전 매개변수화를 사용하세요.

  3. 민감한 정보

    1. 보안에 민감한 정보나 개인 정보가 적절하게 보호되는지 확인하세요(암호화 구획 참조).
    2. 자격 증명(비밀번호 등)은 특별히 주의를 기울여야 합니다. 이러한 유형의 정보로 작업할 때 무엇을 해야 할지 확실하지 않다면, 누군가에게 물어볼 가치가 충분히 있습니다.

  4. 로그

    1. 위의 규칙은 일반적인 애플리케이션 데이터뿐만 아니라 로그에도 적용된다는 점을 잊지 마세요.

암호화

  1. 애플리케이션이 암호화를 사용하나요?
  2. 사용된 알고리즘은 인정된 표준인가요?

서비스 거부

  1. 애플리케이션이 아래 항목에 대한 고갈을 보호하는지 확인하세요.

    1. 시스템 메모리
    2. 저장소

보안 경고

  1. 애플리케이션이 사용자에게 보안 경고를 표시하나요?

  2. 명확하게 이해할 수 있고 적절한 경고인가요?

  3. 신뢰할 수 없는 데이터가 사용자에게 보내지는 메시지의 의미를 바꿀 수 있나요?

    • 사용자 입력이 메시지의 의미를 변경할 수 있나요?
    • 사용자 입력이 시스템 메시지를 화면에서 강제로 표시되지 않도록 할 수 있나요?
    • 사용자 입력에 메시지의 의미를 변경할 수 있는 특수 문자가 포함될 수 있나요? (예: 쓰기를 오른쪽에서 왼쪽으로 재설정하는 유니코드 U+202E)

  4. 공격자가 대화 상자의 타이밍을 이용하여 사용자가 의도하지 않은 항목을 클릭하도록 속일 수 있습니까?

정보 공개

  1. 애플리케이션이 사용자를 위험에 빠뜨리게할 수 있는 정보를 공개하나요?
  2. 애플리케이션이 공개할 필요가 없는 정보를 공개하나요?
  3. 애플리케이션이 사용자를 놀라게 하거나 화나게 할 수 있는 내용을 공개하나요?

프런트엔드

  1. XUL과 HTML UI 요소를 생성하는 데 안전한 메커니즘이 사용되나요?

    • 예를 들어, innerHTML이나 이와 유사한 기능 대신 createTextNode를 사용하세요.

  2. 애플리케이션이 자체 docshell(탭, iframe)을 생성하나요?

    • docshell의 유형을 명시적으로 나타내는지 확인하세요. 예: iframe.setAttribute("type", "content")

참고서