2017-12-11 26 views
0

Windows 서버에서 작동하는 Kentico 10. 시간당 수십 번 이벤트 로그에 다음 오류가 표시됩니다. CSRF 쿠키가 없습니다.CSRF 쿠키 누락 - MS Office의 EventLog 오류 힌트

이 오류는 개발 환경이 아닌 프로덕션 서버에서만 발생하며 수동으로 직접 복제 할 수있는 방법을 찾지 못했습니다 (로그에 표시됨). 이로 인해 프로덕션 사이트로의 이상한 트래픽 유입과 관련이 있음을 알게되었습니다 (응용 프로그램 코드 자체의 문제와 반대 됨)

나열된 이벤트 URL이 항상 표시되기 때문에 문제를 찾기가 어렵습니다. 로 :

: /cmsmessages/error.aspx?aspxerrorpath=/cmspages/portaltemplate.aspx

내가 가진 유일한 단서는 사용자 에이전트의 모든 그들에 Microsoft Office 또는 ExchangeService 제품 이름의 형태를 가지고있다

  • MacOutlook/14.7.7.170905 (Intel Mac OS X 10.9.5)
  • Mac OS X/10.12.6 (16G1036); ExchangeWebServices/7.2 (268); accountsd/113 (113)
  • 마이크로 소프트 오피스/15.0 (윈도우 NT 10.0; Microsoft Excel에서 15.0.4989, 프로)
  • 마이크로 소프트 오피스/16.0 (윈도우 NT 10.0, 마이크로 소프트 워드 16.0.8625, 프로)

Office 응용 프로그램에서 페이지를로드하고 쿠키를 거부하는 것이 이상한 "보호 된보기"브라우저 일 수 있습니까? 이 오류를 수정하는 방법에 대한 의견이 있으십니까?

답변

1

이전에 본 적이 있습니다. 귀하의 도메인에서 무언가를 찾고있는 외부 소스입니다. 당신이보고있는 에이전트에 의해 나는 교환/이메일 관련 (아마 당신이 보내는 이메일을 여는 사람들일까요?)이라고 말하고 싶습니다.

누군가가 여기에 유사한 문제에 대해 설명합니다 : 이상적인 것은 아니지만, 당신은 <add key="CMSEnableCsrfProtection" value="false" /> 키 응용 프로그램 설정을 사용하여 CSRF을 해제 할 수 있습니다 https://devnet.kentico.com/questions/csrf-attack-detected-on-live-site-when-using-smart-search

.

+0

나는 Matt와 이것에 동의하며 나의 대답은 그가 올린 주제의 일부이다. 일부 메일 클라이언트가 POST 요청을 제기하고있는 것처럼 보입니다. 이것은 최근에 여러 번 나타난 것으로 이메일 클라이언트의 성격 인 것 같습니다. 그러나 이러한 사실은 거짓 긍정으로 무시할 수 있습니다. IIS 로그에서 요청 세부 사항을 확인하여 그 시간 동안 실제 요청을 확인하면 전자 메일에 나타나는 페이지를 지정할 수 있어야합니다. –

+0

두 분 덕분에!이 LivePreview와 관련된 가능성 : https://support.office.com/en-us/article/Add-a-link-to-an-email-using-Link-Preview-in-Outlook-com -or-Outlook-on-the-web-ebbfd8ce-d38e-40ef-bb8c-a5362e881163 대부분의 오류가 클라이언트 IP에서 비롯된 것이므로 많은 링크를 보내고 있다는 것을 알 수 있습니다. 이메일을 통한 사이트. –

+0

또는 https://support.office.com/en-us/article/Office-365-ATP-safe-links-dd6a1fef-ec4a-4cf4-a25a-bb591c5811e3#atpforemail 사용자가 링크를 클릭하면 POST를 통해 ATP에 의해 방향이 바뀜 –

0

로그되는 UA를 보면 이것은 Microsoft's EWS API과 관련이있는 것 같습니다. 이 요청이 귀하의 Kentico 웹 사이트를 공격 한 것은 다소 이상한 것처럼 보입니다. 귀하가 겪을 것으로 예상되지 않는 사실을 감안할 때.

Kentico의 CSRF 보호는 기본적으로 적절한 CSRF 토큰없이 POST 요청을 차단합니다. CSRF를 비활성화하면 사용자와 웹 사이트 및 위험이 높아질 수 있으므로 계속 사용하도록 설정하는 것이 좋습니다.

앞서 언급 한 것처럼 IIS 로그를 검사하여 이러한 요청에 대한 자세한 정보 (주로 실제 요청 URL)를 얻어야합니다. 여전히 이러한 요청의 출처를 파악할 수 없거나 예상하지 못하는 경우이를 차단하는 규칙을 설정하는 것이 좋습니다. 이것은 WAF 또는 IIS를 사용하여 수행 할 수 있습니다.