위치:
B2C Commerce의 인증 및 승인 모범 사례
접근 제어의 취약점을 악용하는 것은 공격자의 핵심 기술입니다. 공격자로부터 보호하기 위해 계정 관리, 주문 관리 및 구매와 같은 비즈니스 기능에 대한 서버 측 접근 제어 검사를 시행합니다.
민감한 오브젝트에 대한 접근을 제어하려면 인증 및 승인을 사용합니다. 다음 오브젝트는 민감한 오브젝트에 대한 예시입니다.
- 주문
- 고객
- CustomerPaymentInstrument
- OrderPaymentInstrument
- 장바구니
B2C Commerce는 오브젝트 ID(UUID(Universally Unique Identifier), ID, 토큰)를 사용하여 Script API 오브젝트를 식별합니다. ID를 확인하려는 경우에는 민감한 오브젝트에 대한 읽기 또는 쓰기 접근을 부여하지 않아야 합니다. 요청을 처리하기 전에 스토어프런트에서 항상 추가 인증 및 승인을 수행합니다. 일부 스크립트 API는 보안 방법과 비보안 방법 모두를 제공합니다. 비보안 방법이 기존 사용 사례를 수용할 수 있어도, 보안 방법 사용을 적극 권장합니다.
예를 들어, OrderMgr 클래스에서는 getOrder 메서드에 대한 두 가지 서명을 제공합니다.
static getOrder(orderNumber : String)
static getOrder(orderNumber : String, orderToken : String)
두 번째 서명은 보안 방법입니다. 자세한 내용은 OrderMgr 클래스를 참조하십시오.
인증
카트리지 경로에서 SFRA(Storefront Reference Architecture)를 사용하는 경우 userLoggedIn 미들웨어 기능으로 인증된 사용자의 요청인지 확인할 수 있습니다. 이 미들웨어는 validateLoggedIn 함수를 표시하여 사용자가 함수를 호출하도록 인증되었는지 확인합니다. 또한 validateLoggedInAjax 함수를 표시하여 사용자가 AJAX 요청으로부터 인증을 받았는지 검증합니다.
var userLoggedIn = require('*/cartridge/scripts/middleware/userLoggedIn');
server.get(
'Show',
server.middleware.https,
userLoggedIn.validateLoggedIn,
consentTracking.consent,
function (req, res, next) {
var CustomerMgr = require('dw/customer/CustomerMgr');
var Resource = require('dw/web/Resource');
var URLUtils = require('dw/web/URLUtils');
이 코드 조각에는 노출된 비즈니스 함수에 대한 미들웨어 userLoggedIn이 포함되어 있습니다.
카트리지 경로에서 SiteGenesis를 사용하면 컨트롤러 함수를 내보낼 때 래핑하도록 보호 기능을 사용할 수 있습니다. 보호 모듈에 지정된 함수는 요청 필터처럼 동작합니다. 컨트롤러 기능에 대한 접근 수준을 여러 개 지정할 수 있습니다.
- HTTPS가 필요합니다.
- GET 또는 POST와 같은 특정 HTTP 메서드를 요구하거나 금지합니다.
- 현재 사용자가 로그인해야 합니다.
이 예는 HTTPS가 필요하고 사용자가 로그인한 프로필 편집 컨트롤러를 보여줍니다.
exports.EditProfile = guard.ensure(['get', 'https', 'loggedIn'], editProfile);
승인
스토어프런트 작업을 구현할 때 비즈니스 워크플로와 관련된 승인 검사를 사용합니다. 민감한 오브젝트에서 관리 작업을 수행할 때 해당 오브젝트에 대한 비밀 키를 사용하여 요청 사용자를 인증합니다. 예를 들어, 체크아웃에 성공한 후 비회원 구매자가 계정을 생성하고 B2C Commerce가 해당 비회원 구매자에게 주문을 재할당하는 경우 주문에 대한 비밀 키를 사용하여 사용자를 인증합니다. 이 접근 방식을 사용하면 요청 사용자가 오브젝트를 생성한 사용자인지에 대해 높은 신뢰도를 보장할 수 있습니다.
다음 섹션에는 등록된 구매자와 비회원 구매자에 대한 주문 오브젝트의 승인 검사 예시가 포함되어 있습니다.
등록된 구매자
등록된 구매자가 주문에 접근하려고 하면 스토어프런트에서 다음 정보를 확인합니다.
- 구매자가 인증되었습니다. 자세한 내용은 이 주제에서 앞서 설명한 인증 정보를 참조하십시오.
- 주문이 취소 가능한 상태입니다. 상태가 취소 가능한지 여부는 각 스토어프런트의 주문 관리 플로우에 따라 달라집니다. 지원되는 상태는 주문 클래스를 참조하십시오.
- 구매자가 취소할 주문을 소유합니다.
var orderCustomer = order.getCustomer();
var sessionCustomer = session.getCustomer();
If ( orderCustomer.ID === sessionCustomer.ID ) {
// The logged-in shopper is the owner of the order
// perform actions in accordance with the order management workflow
...
} else {
// A user attempts to access an order they don’t own
// Reject this request with an error message ( HTTP 401 unauthorized or a custom error page)
// Log an error message to track this occurrence
}
비회원 구매자
등록되지 않은 비회원 구매자에게 적용되는 강력한 인증 및 승인 스키마를 구현하는 작업은 등록된 구매자보다 더 어렵습니다. 위조의 위험을 줄이기 위해 사용 사례에 따라 다음 옵션을 고려하십시오.
- 비회원 구매자가 기존 주문을 변경하지 못하도록 차단합니다. 주문을 변경하려고 하면 계정을 생성하라는 메시지가 표시됩니다.
- 구매자가 주문 번호, 주문 토큰 및 주문에 포함된 다음과 같은 기타 데이터의 조합을 생성할 수 있는 경우에만 주문에 접근하도록 허용합니다.
- 이메일
- 성
- 우편번호
- 전화번호
- 비회원 구매자가 등록된 사용자가 소유한 주문에 접근하지 못하게 합니다.
- 허용되는 작업을 최소한으로 엄격히 제한합니다. 예:
- 주문에 저장된 개인 정보나 결제를 표시하지 않습니다.
- 배송 주소 변경과 같이 악의적인 사용자가 주문을 수정할 수 있는 변경을 허용하지 않습니다.
- 무차별 공격으로부터 보호하기 위해 봇/스크립트 보호 제어를 구현합니다. 예:
- 비율 제한
- 컴퓨터와 인간을 구분하기 위한 완전 자동화된 공개 튜링 테스트(CAPTCHA)
