재생 공격을 피하기에 HTTPS가 충분합니까?

10

모바일 앱을 위해 서버에 몇 가지 REST 메소드를 노출하고 있습니다.

사용자가 (모바일 앱에서) HTTP 메소드가 작성되는 방식을 알아 낸 다음 서버로 다시 보낼 수 없도록하고 싶습니다. 예 :

모바일 앱이 요청을 보냅니다
사용자는 프록시를 사용하여 네트워크에서 무슨 일이 일어나고 있는지 확인할 수 있습니다
사용자는 모바일에서 방금 보낸 요청을보고 저장합니다.
=> 이제 사용자가 해당 요청을 수동으로 전송할 수 없도록하고 싶습니다.

HTTPS를 통해 서버를 보호하기에 충분합니까?

api https

— 마틴 모이자 드
소스

7

서버가 rfc2246 섹션 F.2에 따라 TLS 프로토콜 만 허용하도록 구성된 경우 HTTPS는 서버가 재생 공격 (같은 메시지가 두 번 전송 됨)으로부터 보호하기에 충분할 수 있습니다 .

발신 데이터는 전송 전에 MAC로 보호됩니다. 메시지 재생 또는 수정 공격을 방지하기 위해 MAC 비밀, 시퀀스 번호 [...]

— 에미 리콜
소스

1

이 없습니다 더 이상 사실 경우 (안) TLS 1.3 0 RTT 티켓을 사용할 수 있습니다. 또한 문제의 범위 내에있는 것은 아니지만 웹 브라우저를 사용하는 경우 현재 TLS 버전에서도 재생 공격을 계속할 수 있습니다 .

— Alex Shpilkin

9

HTTPS는 단순히 전송되는 데이터가 암호화되어 클라이언트와 서버 만 데이터를 해독 할 수 있다는 것을 의미합니다 (MITM 공격 등에 대해서는 이야기하지 않는 이상적인 환경에서).

따라서 프로토콜의 어떤 것도 재생 공격의 발생을 막을 수 없습니다.

애플리케이션이 재생 공격에 취약하지 않도록하려면 일종의 재생 공격 방지 메커니즘 (만료 토큰 또는 프로세스가 완료된 후 무효화되는 토큰 등)을 구축해야합니다. 이 메커니즘은 일반 HTTP와 함께 사용할 수 있습니다.

— 오데드
소스

8

이 답변은 정 반대를 제안하는 것 같습니다. stackoverflow.com/questions/2769992/… 왜 차이가 있을까요?

— Brian Armstrong

1

@BrianArmstrong 문제는 HTTPS가 Emirikol의 답변에서 언급 한 것처럼 구현이 다르다는 것입니다. 일부 프로토콜은 재생 공격을 방지하지만 일부 프로토콜은 그렇지 않습니다. (키 교환을 수행하면 RSA 키 교환은 방지하지만 익명 키 교환은 방지하지 않습니다. ref : tools.ietf.org/html/draft-ietf-tls-ssl-version3-00#appendix-F ) 따라서 토큰 ( csrf와 같은)가 중요합니다 (참조 시나리오는 다음과 같습니다 : stackoverflow.com/a/2770135/4206925 )

— MewX