GN⁺: API의 HTTP를 HTTPS로 리디렉션하지 마세요

• TL;DR : API 호출을 HTTP에서 HTTPS로 리디렉션하는 대신 실패를 표시할 것. HTTP를 완전 비활성화 하거나 명확한 HTTP 오류 응답을 반환하고 비암호화 연결로 전송된 API키를 취소할 것. 안타깝게도 현재 많은 유명 API 제공업체는 그렇게 하지 않음.

배경

• 웹 브라우저가 HTTP URL로 접속할 때, 서비스는 종종 해당 요청을 HTTPS 페이지로 리디렉션함.
• 초기 HTTP 트래픽은 암호화되지 않아, 네트워크 중간자(MITM) 공격에 취약함.
• HSTS(HTTP Strict Transport Security)와 같은 기술이 도입되어 보안이 강화됨.

간단한 오타의 위험성

• 작업 중 제3자 API와의 통합 과정에서 API 기본 URL을 https:// 대신 http:// 로 잘못 입력함.
• Node.js의 fetch가 조용히 HTTPS로 리디렉션을 따름.
• API 키가 평문으로 전송되어 보안 위험이 발생할 수 있었음.
• 코드 리뷰 중 오류를 발견하여 문제를 해결함.

빠른 실패 원칙

• API가 HTTP 요청을 HTTPS로 리디렉션하면 오타를 쉽게 놓칠 수 있음.
• 빠른 실패 원칙을 따르는 것이 좋음: 암호화되지 않은 API 호출은 명확하게 실패해야 함.
• API 서버의 HTTP 인터페이스를 비활성화하거나, HTTP 요청에 대해 오류 메시지를 반환하는 것이 좋음.

다른 API의 사례

• 여러 유명 API가 HTTP 요청에 대해 403 오류 메시지를 반환하거나 HTTP 인터페이스를 비활성화함.
• 그러나 일부 API는 여전히 HTTP에서 HTTPS로 리디렉션함.

모범 사례의 필요성

• 사용자 지향 애플리케이션에서는 HTTP에서 HTTPS로 리디렉션이 일반적임.
• API의 경우, HTTP에서 HTTPS로 리디렉션하는 것이 오히려 해로울 수 있음.
• OWASP와 같은 보안 프로젝트에서 API에 대한 명확한 지침이 필요함.

결론

• API는 HTTP에서 HTTPS로 리디렉션하는 대신, 암호화되지 않은 요청을 명확하게 실패하게 해야 함.
• API 키가 암호화되지 않은 연결을 통해 전송되면 즉시 취소해야 함.
• API 보안 모범 사례를 업데이트하여 명확한 지침을 제공할 필요가 있음.

GN⁺의 의견

• 보안 강화 필요성: API 보안은 매우 중요하며, HTTP에서 HTTPS로의 리디렉션은 보안 취약점을 초래할 수 있음.
• 빠른 실패 원칙: 개발 초기 단계에서 오류를 발견하고 수정할 수 있도록 빠른 실패 원칙을 따르는 것이 중요함.
• 모범 사례 업데이트: OWASP와 같은 보안 프로젝트에서 API 보안에 대한 명확한 지침을 제공해야 함.
• 자동화된 키 취소: 암호화되지 않은 연결을 통해 전송된 API 키는 자동으로 취소되어야 함.
• 다른 API의 사례 참고: 다른 API의 보안 사례를 참고하여 자신의 API 보안을 강화할 필요가 있음.

[wkang586]

법령으로 규제해야 할 영역인 것 같네요.
일단, 메모... API 에서 https 리다이렉션 금지

[koxel]

기술적으로는 맞는 내용이지만
대부분 기업 클라이언트들은 보안사항으로 http 접근시 무조건 https로 리디렉션을 보내도록 지침이 되어있습니다.
또한 자기들 사이트 이용하는 고객들에게 오류화면을 보이는 것 자체를 꺼리는 지라 자체 서비스를 하는 곳이 아니면 납품하는 입장에선 먼나라 이야기 랄까요..

[thxgeeknews]

작업 중 제3자 API와의 통합 과정에서 API 기본 URL을 "http://";; 대신 "https://"로 잘못 입력함.
http <-> https 가 바뀐 것 같네요.

[xguru]

헉 AI가 이런 실수를 ㅎㅎ 수정해두었습니다.

[neo]

Hacker News 의견

• OpenAI API가 HTTP 요청에 대해 403 에러를 반환하도록 업데이트되었음.
• Stack Exchange API는 HTTP로 전송된 API 키를 취소하고 에러 메시지를 반환하는 방식이 좋음.
• HTTP에서 HTTPS로 리디렉션 설정을 자동으로 하지 않도록 주의해야 함.
• cURL의 기본 설정이 자동 리디렉션을 하지 않는 것이 의도적이며 좋은 기본값임.
• HTTP 접근을 차단하고 HTTPS만 제공하는 것이 중요함.
• "Provider B"가 MITM 공격이 프로그램 범위 밖이라고 응답한 것이 놀라움.
• HTTP 스니핑이 MITM 공격의 일종인지에 대한 의문이 있음.
• HTTPS와 SVCB DNS 레코드가 시간이 지나면서 전통적인 HTTP 서버 리디렉션을 대체할 수 있기를 바람.
• API 제공자들이 과거의 HTTP 접근 로그를 확인하고, 평문 HTTP 사용이 얼마나 널리 퍼져 있는지 점검해야 함.
• 많은 API가 자동 HTTPS 리디렉션을 기본 규칙으로 설정하는 웹 애플리케이션 방화벽 뒤에 호스팅되어 있음.
• API가 HTTP에서 HTTPS로 자동 리디렉션하지 않아야 하며, 클라이언트 라이브러리도 기본적으로 리디렉션을 따르지 않아야 함.
• HTTP에서 HTTPS로 리디렉션을 설정하는 것이 장기적으로 트래픽을 줄이는 데 도움이 됨.
• 인프라에서 URL 오타로 인한 문제를 빠르게 해결하려고 리디렉션을 설정하는 경우가 많음.