위치:
B2C Commerce의 데이터 검증
사용자 입력 검증은 애플리케이션 보안의 기본입니다. 데이터 검증을 통해 해당 데이터가 애플리케이션에서 필요로 하는 데이터 종류가 확실한지 확인합니다. B2C Commerce는 일반적으로 잘못된 요청을 완전히 거부하고 사용자에게 오류를 반환합니다. 데이터 검증을 수행할 위치를 선택하되 클라이언트 측 검증과 서버 측 검증에 중점을 둡니다.
-
일반적으로 클라이언트 측 검증은 서버로 전송하기 전에 클라이언트 시스템에서 데이터를 확인하는 스크립팅 언어를 통해 구현됩니다. Salesforce B2C Commerce에서는 사용자의 브라우저에서 실행되는 JavaScript 코드를 작성해 양식 데이터를 검증합니다. 그러나 클라이언트 측 검증은 보안 제어로서 신뢰할 수 없습니다.
-
서버 측 유효성 검사를 구현하려면 비즈니스 흐름에 추가 단계를 작성합니다. 이 단계는 효과적인 보안 제어입니다. 일반적으로 개발자는 B2C Commerce API와 몇 가지 기본 온전성 검사를 사용하여 B2C Commerce 스크립트에서 서버 측 검증을 수행합니다.
클라이언트 측 검증을 사용하는 기본 데이터 온전성 검사는 스토어프런트 사용자에게 즉각적인 피드백을 줄 수 있습니다. 반면에 강력한 서버 측 검증을 사용하면 악의적인 요청을 저지할 수 있습니다.
요청이 전송된 후 데이터를 다시 검증합니다. 데이터가 잘못된 경우 B2C Commerce는 처리를 중단하고 오류 메시지를 통해 사용자에게 해당 사실을 알립니다. 결과적으로 클라이언트 측 검증은 실수로 잘못 입력한 데이터를 합법적인 사용자에게 보고하는 반면, 서버 측 검증은 악의적인 사용자가 서버로 직접 요청을 보내는 것을 중지합니다.
삽입 공격으로부터 보호
올바른 검증을 통해 삽입 공격으로부터 보호합니다. 출력 인코딩과 함께 사용하면 삽입 공격에 대응해 보다 강력한 방어 기능을 제공합니다. 몇 가지 고려 사항은 다음과 같습니다.
-
클라이언트 검증에서 민감한 내부 데이터 노출:
데이터를 검증할 때 클라이언트 측 검사에 너무 많은 내부 로직을 사용하지 마십시오. 이로 인해 예상되는 값이나 잠재적으로 유효한 데이터 목록이 클라이언트에 노출되어 확인될 위험이 있습니다. 이렇게 하면 취약성을 찾고 있는 악의적인 공격자를 포함하여 모든 클라이언트로 중요한 데이터가 전달될 수 있습니다.
-
잘못된 보안 감각으로 이어지는 부정확한 검증:
보안 검증에 너무 많이 의지하지 마십시오. 검증 단계는 여러 가지 보안 검사 단계로 진행되는 규모가 크고 심증적인 보안 제어의 일부일 뿐입니다. 이러한 방식은 철저한 검증이 어렵기 때문에 특히 정규 표현식에서는 일반적인 문제입니다.
다음과 같은 방법으로 사용자 입력의 유효성을 검사합니다.
| 사용자 입력 검증... | 설명 |
|---|---|
| 허용 목록 등재 | 허용 목록 등재는 가장 엄격한 검증 전략입니다. 승인 가능한 입력이 무엇인지 정의하고 나머지는 모두 거부합니다. 예를 들어 요일을 입력하는 경우 알려진 7개의 값만 허용됩니다. 입력 형식을 허용 목록에 등재할 수도 있습니다. 예를 들어 날짜와 사회 보장 번호에는 특정한 형식이 있습니다. |
| 차단 목록 등재 | 허용 목록에 등재될 수 있는 입력 형식이 너무 많은 경우 차단 목록 등재가 효과적인 옵션입니다. 차단 목록 등재를 사용하여 허용되지 않는 것으로 알려진 특정 입력 유형을 차단합니다. 잘못될 가능성이 있는 모든 입력을 식별할 수 없지만 차단 목록 등재를 구현할 때 다음 질문을 고려하십시오.
|
