CSRF 방어 사용 사례
사설 IP 주소를 통해 HTTP 기반 웹 UI를 지원하는 임베디드 장치가 있습니다.
HTTPS가 아닌 HTTP를 통해 CSRF 방어를 구현하는 것이 합리적입니까?
답변
HTTP 요청이 상태를 변경할 수있는 경우 CSRF 보호가 필요할 수 있습니다. 요청이 전송 계층에서 암호화되었는지 여부는 이것과 거의 또는 전혀 관련이 없습니다.
CSRF 보호가 없으면 피해자의 브라우저가 적절하게 승인되거나 인증이 부족하거나 손상된 경우 웹 사이트 또는 단일 리소스를 방문하도록 유도하는 공격자가 임베디드 장치에 요청을 보내고 제어 할 수 있습니다. 이는 HTTP 또는 HTTPS 사용 여부에 관계없이 발생합니다.
예, 이상적으로는 모든 것이 HTTPS를 통해 이루어집니다. 그러나 현재 대부분의 공급 업체에게 "가장 좋은"옵션은 자체 서명 된 인증서와 함께 임베디드 장치를 제공하는 것입니다.이 인증서는 처음 사용할 때 신뢰하고 수동 스니핑을 방지하는 것 외에는 많은 사람들의 일반 HTTP보다 낫지 않습니다. 시나리오. 종종 사용자는 여전히 인증서 경고를 받고이를 클릭합니다. 이 문제가 해결 될 때까지 임베디드 장치의 HTTPS 전망은 여전히 음울합니다.
(지금 삭제 된 편집 사항 해결) 실제로 XSS는 CSRF 완화를 우회합니다. 그러나 위협 모델은 처음에 장치에 접근해야하기 때문에 공격자가 CSRF 문제보다 임베디드 장치에서 XSS를 악용 할 가능성이 적기 때문에 여기에서 약간 다른 것처럼 보입니다.
CSRF 방어가 없으면 공격자는 모니터링 경고와 함께 이메일 (아마도 적절하게 타겟팅 된 스푸핑 주소)을 위조하여 중요한 문제가 있으므로 확인하라는 메시지를 표시 할 수 있습니다. 이메일 안에 http : // yourswitch / factory_reset에 대한 링크가있을 수 있습니다.
공격 벡터는 다를 수 있습니다.
해당 장치에 대해 기본 FQDN 또는 IP 주소 (예 : 유비쿼터스 192.168.1.1)를 사용하지 않는 한 이러한 특정 유형의 공격은 상당히 표적이됩니다. 공격자는 실제로 "흥미로운"작업을 수행하는 스위치에 대한 요청을 작성해야하며 (유용한 경로를 얻으려면 FQDN / IP 및 공급 업체 / 모델을 알아야 함) 너무 많이 발생하지 않는 방식으로이 링크를 보내야합니다. 당신의 눈썹 (인터넷에서 온 이메일은 이상 할 것입니다. 아마도 당신이 사용하는 무응답 모니터링 이메일을 위조 한 것일까 요?).
평소와 같이 위협 모델과 대책의 비용 대비 이점을 이해하는 것이 중요합니다.
예.
네트워크 스위치 또는 라우터의 경우 일반적인 공격은 장치 재구성 (예 : 내부 포트를 외부로 전달), 악의적 인 대상에게 제공하는 DNS 변경 등입니다. 이러한 작업 은 필요합니다. 그러나 변경되지 않은 기본 암호를 사용할 수도 있다는 점을 고려해야합니다.
(그리고 예, 이런 종류의 일은 야생에서 발생합니다)
개인 주소를 기반으로한다는 사실 http://192.168.1.1공격이 악의적 인 웹 페이지에 의해 이루어 지므로 보호 기능을 제공하지 않습니다 . 네트워크 내부 사용자의 브라우저를 통해 CSRF 보호가 부족하여 허용 된 악의적 인 요청을 보내면 스위치가 잘못 구성됩니다.
Mozilla Firefox는 14 년 동안 버그 354493이 열려있어 RFC-1918이 아닌 주소에서 RFC 1918 주소로의 공격을 피할 수 있었지만 지금까지는 구현되지 않았습니다.