2016-11-12 7 views
0

these instructions에 따라 서버를 REST 인증을 활성화하도록 구성했습니다. 그러나 작동하려면 정상적인 텍스트 (내용 유형 text/html 또는 xml)로 자격 증명을 제출해야하며 지침에 따라 application/x-www-form-urlencoded이 아니어야합니다. 후자 형식으로 보내면 자격 증명이 손실됩니다.CAS REST 인증 API는 text/*를 허용하지만 application/* 콘텐츠 유형은 허용하지 않습니다.

로그인 자격 증명을 일반 텍스트로 보내는 것이 불편합니다. 이것은 CAS의 버그이며 어떻게 수정 될 수 있습니까? 나는 텍스트 콘텐츠 유형 대 응용 프로그램으로 로그인 자격 증명을 보내는 것이 안전하지 않다고 가정합니다. 후자 (나는 가정)가 보낸 내용을 해시 (또는 어떻게 든 그 밖의 다른 방법으로 난독 화)하는 것처럼 말입니다.

또한 maven overlaythis solution을 구현하여 콘텐츠 유형에 관계없이 자격 증명이 손실되는 CAS의 버그를 수정해야한다고 언급해야합니다. 그 후 텍스트 기반 콘텐츠 유형 만 작동하고 CAS는 인증을받습니다 (프로그래밍 방식의 처리 용이성을 위해 XML/JSON 또는 일반 텍스트가 아닌 HTML을 반환하는 것을 성가 시게하지만).

관련이 :REST API endpoint /v1/tickets appears to lose credential request parameters

답변

1

콘텐츠 유형은 요청 데이터의 기밀성에 영향을주지 않습니다. 기밀성 만 고려되는 경우 요청시 application/x-www-form-urlencoded으로 보내기는 text/html 또는 text/xml보다 안전하지 않으며 안전하지 않습니다. 요청에 포함 된 것을 사용하는 데 추가적인 보안 값은 없습니다. 원시 요청 소스 (MitM 공격자)에 대한 액세스 권한을 가진 사용자는 요청 내용을 어느 쪽이든 볼 수 있습니다. HTTPS는 노드 간 네트워크에서 MitM 공격자와 관련하여 효과적으로이 위험을 완화하지만 SSL이 종단되는 종단점 (원본 및 대상 컴퓨터와 SSL을 종결하는 모든 노드 (예 : 신뢰할 수있는 루트가있는 회사 프록시) 클라이언트의 인증서 - 상당히 일반적인 설정). 가능한 보안 대신 application/x-www-form-urlencoded의, 다른 질문에 my answer를 참조하십시오 text/plain을 사용하여 이익을에 관해서는

. 즉, text/plain을 사용하면 CSRF 공격을 예방할 수 있습니다.