CSRF 보호를 위한 요청 방법 업데이트 및 콘텐츠 유형 필터링
CSRF(교차 사이트 요청 위조)는 자신도 모르게 당한 피해자를 대신하여 위조된 요청을 제출하는 웹 기반 공격입니다. 사용자가 현재 한 사이트에서 인증되고 속임에 넘어가 악의적인 명령을 제출하는 경우 공격자는 피해자의 자격 증명을 사용하여 상태 변경 요청을 수행할 수 있습니다.
자세한 내용은 다음 링크를 참조하십시오.
CSRF 공격에 대한 일반적인 방어는 동기화된 토큰을 사용하는 것입니다. 하지만 ThingWorx에서는 대체 접근 방식을 사용하며 그 대신 엄격한 콘텐츠 유형 필터를 통해 모든 요청을 라우팅합니다. 이 접근 방식은 동일하게 보안을 설정하며, 무상태 구현에 더 적합합니다.
요청 방법 업데이트
기본적으로 요청 매개 변수로는 요청 방법을 변경할 수 없습니다. 응용 프로그램이 이러한 방식으로 개발된 경우 다음을 수행할 수 있습니다.
• 요청 매개 변수를 통해 GET 메소드를 POST 메소드로 변경하는 코드를 제거합니다. 이 접근 방식이 가장 좋습니다.
 |
이 접근 방식은 권장되지 않습니다. 이렇게 하면 구현/응용 프로그램을 CSRF가 발생할 가능성에 노출시킨 것입니다.
요청 방법 전환 허용 옵션은 더 이상 사용되지 않으며 향후 ThingWorx 릴리즈에서 제거됩니다.
|
콘텐츠 유형 필터링
ContentTypeFilter는 모든 POST, PUT 및 DELETE 메소드에 대해 요청 머리글의 콘텐츠 유형이 application/json, application/xml 또는 text/xml인지 확인하기 위해 구현되었습니다. 요청이 다중 부품/양식 데이터인 경우 값이 TWX-XSRF-TOKEN-VALUE인 X-XSRF-TOKEN 머리글을 확인합니다. 이 다중 부품/양식 데이터에 대한 요청은 파일 업로드를 위한 것입니다.
• 파일 업로드를 수행하면 브라우저에서 FormData 객체가 구현되어야 합니다.
 |
FormData는 이전 브라우저(Internet Explorer 9 이하)에서 사용할 수 없으므로 이러한 브라우저에서는 ContentTypeFilter가 포함되면 파일 업로드가 작동하지 않습니다(엔티티 및 확장 가져오기 포함).
|
|
|
플랫폼 하위 시스템에서 Filter Content-Type 옵션을 끌 수 있지만, 이 옵션을 끄면 구현/응용 프로그램을 CSRF가 발생할 가능성에 노출시킨 것입니다.
Filter Content-Type 옵션은 더 이상 사용되지 않으며 향후 ThingWorx 릴리즈에서 제거됩니다.
|
CSRF 보호를 위한 최적의 방법
다음 지침을 통해 CSRF 보호를 유지하십시오.
• 새 응용 프로그램을 개발할 때 Composer에 작성된 모든 매쉬업을 보안 설정합니다. REST API를 통해 ThingWorx에 액세스하는 사용자 정의 UI를 사용하는 경우 방법 전환이 필요한 요청을 포함하지 마십시오.
• 새 Java 확장을 개발할 때 새 서비스가 모두 ThingWorx 서비스 주석 프레임워크를 통해 노출되는지 확인합니다. 이 프레임워크는 서비스 구현에 대한 모든 수신 요청을 식별, 매핑 및 라우팅합니다. ThingWorx 서비스 주석을 통해 생성 및 노출되는 모든 서비스는 CSRF에 대해 보호됩니다.
• 간혹 새 서비스가 ThingWorx 주석 프레임워크를 무시해야 하는 경우 서비스가 GET, POST, PUT 또는 DELETE 메소드에만 반응하도록 해야 합니다.
관련 링크