https://www.freecodecamp.org/news/technical-dive-into-owasp/ 

보안 측면에서 치료 및 예방이 필요한 많은 취약점이 있지만 일부는 다른 취약점보다 더 많은 주의를 기울여야 합니다. 

의심의 여지없이 이러한 보안 문제를 해결하는 데 도움이 되는 최상의 가이드는 Open Web Application Security Project입니다.

OWASP는 개발자와 관리자에게 가장 일반적인 웹 보안 문제에 대한 인식을 높이기 위한 간단한 프로젝트로 시작했습니다. 

그리고 오늘날에는 응용 프로그램 보안의 표준이 되었습니다.

이 기사에서는 OWASP 프로젝트에 나열된 일부 취약점과 이를 완화하는 방법에 대한보다 심층적인 기술 개요를 제공합니다. 

이러한 유형의 공격을 보다 잘 이해하고 방지하고 웹 응용 프로그램 보안을 개선하기 위해 나쁜 코드-좋은 코드 예제를 나란히 할 것입니다.

Injection 

이 유형의 취약점은 프로그램이 공격자가 신뢰할 수 없거나 악의적인 입력 데이터를 제공 할 수 있는 경우에 발생합니다. 

이로 인해 인터프리터는 설계되지 않은 명령을 실행하여 일반적으로 액세스 할 수 없거나 일부 보안 구현을 우회해야 하는 데이터를 표시합니다.

주입 취약점의 가장 흔한 원인은 소프트웨어가 사용자 입력을 필터링, 검증 또는 위생 처리하지 못했기 때문에 발생합니다.

주입 공격이 발생할 수 있는 두 가지 "잘못된 코드 구현"을 살펴 보겠습니다.

잘못된 코드 예 1 : 

이메일을 수신하는 로그인 경로가 있고 어떤 이유로 든 이미 해시 된 비밀번호를 수신한다고 가정 해 보겠습니다.

잘못된 코드 예 1

사용자의 이메일 주소 (예 : myemail@email.com)를 알고 있으면 다음 JSON 객체를 전송하여 이 로그인 시스템을 쉽게 우회할 수 있으며, 이로 인해 NoSQL 주입이 생성됩니다.

{
        "email": "myemail@email.com",
        "password": { "$ne": "" }
}

이 객체는 MongoDb에게“myemail@email.com”이라는 이메일과 빈 문자열과 다른 비밀번호를 가진 사용자를 찾도록 지시합니다.

이 예제는 약간의 정보를 얻을 수 있지만 다음 코드를 살펴보고 문제를 발견 할 수 있는지 스스로 생각해보십시오.

잘못된 코드 예 2 : 

이 예제에서는 인터페이스에 백엔드에 다음 코드가 있는 등록 양식이 있습니다.

나쁜 예 2

가입보기

이 코드를 어떻게 이용할 수 있습니까? 매우 간단합니다.이 예에서 사용자 스키마가 다음과 같다고 가정 해 보겠습니다.

export const UserSchema = new mongoose.Schema({
    email: {
        type: String,
        required: true,
        unique: true
    },
    password: {
        type: String,
        required: true
    },
    admin: {
        type: Boolean,
        default: false
    },
    accountConfirmed: {
        type: Boolean,
        default: false
    },
}, 
);

이제 Postman 또는 선호하는 다른 도구와 함께 다음 POST 요청을 보내십시오.

{
    "email": "my-email",
    "password": "123321",
    "admin": "true",
    "accountConfirmed": "true"
}

이제 이 웹 사이트에 간단한 사용자가 아닌 확인 된 관리자 계정으로 성공적으로 등록했습니다.

여기서 문제는 단순히 우리가 단순히 사용한다면 :

{ ...req.body }

그런 다음 객체 본문 내부의 모든 속성을 사용하여 새 사용자 객체를 생성하므로 원하는 것을 주입 할 수 있습니다.

Refactoring 

이러한 종류의 공격을 방지하기 위해 두 예제에서 코드를 리팩터링 해 보겠습니다.

첫 번째 예에서는 이메일과 비밀번호 모두에 대해 예상되는 유형을 확인할 수 있습니다. 우리의 경우 두 필드 모두에서 문자열을 기다리고 있습니다.

동일한 매개 변수를 다시 제공하면 :

{
	"email": "myemail@email.com",
	"password": { "$ne": "" }
}

400 잘못된 요청 응답을 받습니다. 우리는 더 나아가서 전자 메일이 단순한 문자열이 아니라 실제로 전자 메일인지 확인할 수 있지만 지금은 범위를 벗어납니다.

두 번째 방법으로는 원치 않는 속성을 제거하여 "화이트리스트"서버 측 입력 유효성 검사를 사용할 수 있습니다.

이 예제는 NoSQL 주입에 대한 것이지만 이 기술은 SQL 주입에 대해서도 확장 될 수 있습니다.

알려진 취약점이 있는 구성 요소 사용 

위에서 우리는 실수로 인해 보안 표준이 제대로 구현되지 않은 것을 보았습니다. 그러나 문제는 우리가 작성한 코드가 아니라 프로젝트에서 사용하는 오픈 소스 코드에서 발생하는 상황이 있습니다.

공격자는 이러한 구성 요소의 취약성을 악용하여 악성 코드를 실행하거나 프로그램이 원치 않는 방식으로 동작하도록 할 수 있습니다.

이것이 당신의 손에서 벗어난 것처럼 보이지만 그렇지 않습니다. 이런 종류의 문제를 방지하기 위해 취할 수 있는 조치가 있습니다.

예를 들어 클라이언트 측과 서버 측의 구성 요소 버전에 대한 지속적인 인벤토리를 수행하고 사용하지 않는 종속성 및 / 또는 기능을 제거 할 수 있습니다.

구성 요소의 취약점에 대해 WhiteSource에서 유지 관리하는 이 오픈 소스 데이터베이스와 같은 소스를 모니터링 할 수 있습니다.

화이트 소스 대시 보드

구성 요소가 안전한지 확인하려면 취약성 데이터베이스를 정기적으로 확인하고 즉시 보안 패치를 적용해야 합니다. 이를 통해 보호를 유지할 수 있습니다.

깨진 인증 

이 취약점은 웹 앱이 인증 / 세션 관리 기술을 제대로 구현하지 못할 때 발생합니다. 공격자에게 액세스 권한이 없어야 하는 계정에 대한 액세스 권한을 부여하기 때문입니다.

이 보안 문제는 무차별 대입 공격의 형태와 세션 ID / 토큰이 쉽게 도난 당할 수 있는 형태로 노출 될 때 가장 널리 퍼져 있습니다.

잘못된 코드 예 1 : 

이전 코드 스니펫의 예를 들어 보겠습니다. 지정된 이메일과 비밀번호를 가진 사용자를 찾을 수 없을 때 401 (권한 없음) 응답을 보내도록 약간 조정했습니다.

이것이 리팩토링 된 코드 임에도 불구하고 여전히 Broken Auth에 취약합니다. 여기에 잘못된 비밀번호를 사용하면 401 응답이 표시됩니다. 그러나 암호가 약하면 추측 할 때까지 무차별 대입 할 수 있습니다.

Refactoring 

경로의 속도 제한을 사용하여 무차별 대입 공격을 방지 할 수 있습니다. 이제 사용자는 3 번의 인증 기회를 갖게 되며, 이후 15 분 동안이 라우트에서 더 이상 요청을 보낼 수 없게 됩니다 (응답이 429 개로 너무 많음).

이 주제에 대한 다음 유형의 취약점은 특히 JSON 웹 토큰 관리가 불량한 것과 관련이 있습니다.

잘못된 코드 예 2 : 

다음 예제는 로그인 시스템에서 매우 자주 발견됩니다.

대부분의 경우 JWT를 사용하는 로그인 시스템이 이런 방식으로 구현됩니다. 사용자가 올바른 자격 증명을 보내면 ID 또는 다른 고유 값을 사용하여 토큰이 생성됩니다. 그런 다음 토큰은 응용 프로그램 내부에 저장되는 프런트 엔드로 전송됩니다. 또는 지속적인 인증이 필요한 경우 쿠키 또는 로컬 저장소에 저장됩니다.

이 접근 방식의 문제점은 이제 보안해야 하는 토큰에 프론트 엔드 코드를 통해 액세스 할 수 있어 취약하다는 것입니다. 프론트 엔드 JavaScript에 삽입 된 악성 코드는 쿠키 또는 로컬 스토리지에 액세스하여 이 토큰을 훔칠 수 있습니다.

Refactoring 

이 문제는 다음 구현에서 극복 할 수 있습니다.

이번에는 토큰도 쿠키에 저장되지만 백엔드 코드에서 httpOnly 속성을 사용하여 저장됩니다. 이는 프론트 엔드에서 실행되는 코드에서 액세스 할 수 없음을 의미합니다.

보다 안전하게 하기 위해, 서명 된 속성과 함께 토큰이 저장되므로 쿠키는 비밀 키로 서명됩니다.

https를 통해 쿠키를 강제로 전송하는 보안 플래그로 http 프로토콜을 더 차단하고 차단할 수 있습니다.

민감한 데이터 노출 

이름에서 알 수 있듯이 웹 응용 프로그램이 중요한 데이터를 충분히 보호하지 못하면 이 취약점이 발생합니다.

GDPR과 같은 최근의 법적 변경은 중요한 데이터가 노출되지 않도록 해야 하지만 상당 부분의 웹 응용 프로그램이 이러한 요구 사항을 충족하지 못합니다.

일반적으로 HTTP, SMTP 및 FTP를 사용하여 데이터를 일반 텍스트로 전송하거나 약한 / 오래된 암호화 알고리즘을 사용하는 경우에 발생합니다.

가능한 시나리오는 다음과 같습니다.

웹 사이트는 모든 페이지에 TLS를 사용하거나 적용하지 않습니다. 공격자는 네트워크 트래픽을 모니터링하고 HTTPS에서 HTTP 로의 연결을 다운 그레이드하고 요청을 가로 채며 전송 된 정보를 훔칩니다. 심지어 사용자의 세션 쿠키를 도용하여 사용자의 개인 데이터에 액세스하거나 수정하기도 합니다.

다른 시나리오는 다음과 같습니다.

암호는 데이터베이스 내부에 무염 또는 단순하고 약한 해시로 저장됩니다. 파일 업로드 결함 또는 기타 공격으로 공격자가 비밀번호 데이터베이스를 검색 할 수 있습니다. 

그 후, 모든 해시는 미리 계산 된 값의 레인보우 테이블로 노출 될 수 있으므로 공격자에게 사용자의 실제 일반 비밀번호를 제공합니다.