2012-04-16 3 views
0

내가 웹 서비스에 대한 API를 읽고 있어요, 모든 방법을 명확하게하기 위해https가 더 안전합니까?

https://example.com/api/APIVER/METHOD?apikey=APIKEY&user=USERNAME&password=PASSWORD 

에 HTTP 요청을 보내는 것을 포함, API 키와 사용자 암호를 모두는 URL을 통해 일반 텍스트로 전송됩니다. 그러나 "일반 텍스트로되어 있거나 URL이 어떻게 든 다르기 때문에"모든 HTTPS 트래픽이 암호화되어 있기 때문에 "확인해도됩니까?

보안되지 않은 경우 API 유지 관리자가 수행해야하는 최소한의 변경 사항은 무엇입니까?

+0

이 API의 용도는 무엇입니까? 서버 간 호출입니까? 아니면 브라우저에서이 전화를 걸려고하십니까? 브라우저에서이 작업을 수행하는 경우 안전하지는 않지만 서버 대 서버가 정상입니다. –

+0

브라우저 용은 아니지만 클라이언트 측 응용 프로그램 (모바일 장치, 데스크톱 클라이언트 등)에서 사용할 수 있습니다. –

+0

그러면 안전하지 않습니다. 누구든지 앱을 다운로드하고 네트워크 연결을 모니터링하며 사용자 이름/비밀번호를 추출 할 수 있습니다. 클라이언트 측 앱에서 호출 된 API는 사용자가 사용자 비밀번호로 인증하는 경우에만 보안을 설정할 수 있습니다. –

답변

1

예, HTTPS를 사용하면이 보안이 강화됩니다.

0

HTTPS는 각 요청에서 URL을 인코딩하므로 네트워크 스니핑이 걱정된다면 괜찮습니다. HTTPS는 nonce 값도 추가하므로 회신 공격에 노출되지 않습니다.

인프라에 따라 사용자 장치에서 신뢰할 수있는 위조 된 SSL 인증서를 삽입하고 해당 인증서를 사용하는 프록시를 통해 요청을 라우팅하는 것이 가능할 수 있습니다. 그러나 이렇게하려면 클라이언트 컴퓨터에 대한 관리/루트 액세스 권한이 있어야만 이러한 인증서를 신뢰할 수 있으며 (일반적으로 신뢰할 수있는 CA의 침해를 막음) 관리자 액세스가 필요한 경우 모든 베팅은 해제됩니다.

여전히 좋은 생각은 아니지만 개발자가 HTTPS 용으로 구성하는 것을 잊어 버리는 것이 걱정됩니다. API 키가 있으므로 암호를 가져 와서 APIKEY를 소금으로 사용하면 어떨까요? 이제 API 호출에 대해 salt는 암호와 동일하지만 사용자 이름과 비밀번호를 사용하여 해당 자격 증명이있는 다른 곳 (예 : API가 실행중인 웹 사이트)에 로그인 할 수 없다는 것을 의미합니다 (사용자가 당연히 거기에서.)

철사에 전혀 가지 않는 공유 비밀을 사용하고 소금으로 사용하는 것이 더 낫다.

+0

MitM 공격에 대해 걱정했기 때문에 잘 듣습니다. HTTPS를 잊어 버린 개발자에 대한 우려는 유효합니다. 그 호출이 여전히 작동한다는 것을 발견했기 때문입니다. 나머지 세 번째 단락 뒤에있는 생각을 추측합니다. 내 APIKEY를 비밀로 유지하고 암호를 해독 할 수 있다면 로컬로 저장할 수 있습니다. API가 바뀐 암호 만 허용하도록 변경하면이 기능이 도움이됩니까? –

+0

소금에 절인 비밀번호 만 허용하도록 API를 변경했습니다. 그리고 분명히 웹 서버에서 HTTP를 비활성화하십시오. – blowdart

1

HTTPS를 사용하면이 보안이 강화됩니다.

또한 GET 쿼리 문자열 대신 POST 매개 변수 (예 : HTTP BODY)로 중요한 매개 변수를 보내야합니다. 일반적으로 웹 서버 로그 (서버 쪽)는 쿼리 문자열을 일반 텍스트로 기록하므로 시스템 관리자는 쿼리 문자열을 볼 수 없어야합니다.

+0

POST 매개 변수가 작동하는 것처럼 보입니다. API가 변경되지 않는 한, 내 고객을 위해 그 점을 고수 할 것입니다. –

관련 문제