API의 무단 사용을 피하는 방법은 무엇입니까?

파트너가 UI를 표시하고 API를 호출하기 위해 웹 사이트에 포함 할 스크립트 인 "위젯"을 디자인해야합니다.

기본적으로 API 호출에서 제공하는 일부 ID를 기반으로 이러한 사이트에 데이터를 표시합니다. 우리가 피하고 싶은 것은 API를 남용하고이를 사용하여 카탈로그 전체를 긁어내는 것입니다.

스크립트를 포함하는 각 파트너에게는 API를 호출 할 때 제공해야하는 공개 키가 제공됩니다. 스크립트를로드 할 때이 키를 추가하도록 요청하는 것이 좋습니다. 예 :

<script src="//initrode.com/widget/loader.js?key=xxxx"></script>

이렇게하면 스크립트 요청을 사용하여 키 / 소스 IP 쌍을 등록하고 키 / IP 쌍이 등록 된 항목과 일치하는 경우에만 후속 API 호출에 응답 할 수 있습니다 (수명이 제한되어 있고 하루 요청 수 제한).

난독 화를 통한 명백한 보안이기 때문에 좋은 아이디어인지 확실하지 않습니다 (스크립트를 다시로드하면 완전히 무시합니다). 그러나 액세스를 제한하는 다른 방법은 없습니다. 모든 사용자에게 고유 키를 제공 할 수 없으며 파트너에게만 제공 할 수 있습니다. 모든 코드를 누구나 사용할 수 있으므로 개인 키 시스템을 사용할 수 없습니다. 기본적으로 공개 API에 대한 액세스를 제한합니다. 즉, 정의상 모순입니다.

이 솔루션에 대해 어떻게 생각하고 이러한 제약 조건으로 무엇을 하시겠습니까?

여러 유형의 보호가 필요합니다.

먼저 , 사이트 A의 키가 사이트 B에서 사용되지 않도록해야합니다.

이론적으로 키가 도메인에 바인딩되어 있으면 referer헤더에 의존 할 수 없지만 클라이언트가 스크립트를 직접 임베드하기 때문에 클라이언트 측에 의지 할 수 있습니다document.location . 해당 위치 (또는 그 일부)를 서버로 직접 보내는 것은 신뢰할 수 없습니다. 그러나이를 사용하여 세션 키를 생성 할 수 있습니다.

1. 클라이언트 client_key가 API 라이브러리 요청에 포함합니다.
2. 서버는 API에 액세스 할 수있는 호스트를 결정합니다 (있는 경우).
3. 서버는 세션 키에 대해 "소금"을 선택하고 라이브러리 (또는 다른 사전 인증 교환의 일부)를 사용하여 클라이언트에게 보냅니다.
4. 클라이언트는를 session_key사용하여 계산합니다 hash(document.location.host + session_salt).
5. 클라이언트는 API 호출에 session_key+ client_key를 사용합니다 .
6. 서버 client_key는 세션에서 호스트 및 "소금"을 찾아 해시를 계산하고 제공된 것과 비교 하여 호출의 유효성을 검사합니다 client_key.

둘째 , API로 원하는 작업을 수행하기 위해 Hacker Hank가 디버그 콘솔을 열거 나 사이트 A에서 수정 된 클라이언트를 사용하지 못하게해야합니다.

그러나 해커 행크가 API를 남용하는 것을 완전히 막는 것은 불가능하지는 않지만 매우 어렵다는 점에 유의하십시오 . 그러나 더 어렵게 만들 수 있습니다. 내가 알고있는 행크를 방해하는 가장 합리적 방법은 속도 제한입니다.

• 요청 / 초 / 세션 수 및 요청 / 시간 / 세션 수를 제한하십시오. 활동의 스파이크는 합리적이지만 단일 클라이언트의 평균 이상의 트래픽은 유지 되지 않습니다 .
• 세션 수 / IP / 시간을 제한하십시오.
• 요청 수 / IP / 시간을 제한하십시오. 스파이크는 허용하지만 단일 IP에서 계속 많은 트래픽이 발생 하지는 않습니다 .

셋째 , 이미하고있는 것처럼 : 트래픽을 암호화하십시오. 물론, NSA는 그것을 볼 것입니다. 그러나 해커 행크는 가능성이 적습니다.

여기에서 자바 스크립트 파일을 보호 된 리소스로 만드는 것처럼 들립니다. 그리고 일종의 토큰 생성과 동시에 번들로 제공합니다. 그 흥미 롭군요.

내가 일하는 보안 담당자는 일반적으로 IP가 위장 가능하므로 IP 주소를 기각합니다. 그러나 SSL과 결합 된 IP 제한을 사용하는 경우 일반적으로 트릭을 수행합니다.

그러나 IP 주소를 "허용"해야합니다. 그렇지 않으면 모든 해커가 정문에 올 수 있습니다.

나는 회의적이지만 실제로는 당신의 계획이 잘 작동한다고 생각합니다. 1) .js 파일 및 후속 API 호출이 TLS (예 : SSL 또는 https)로 작성된 경우 및 2) IP가 화이트리스트에 추가됩니다. 그런 다음 대담한 진술을하고 PCI (신용 카드) 상호 작용에 대해서도 보안 검토를 통과했다고 생각합니다.

IMHO ... 그러나 신용 카드 (PCI) 또는 개인 / 개인 정보 (PII) 대신 회사 독점 정보를 보호하려는 경우 SSL이 없어도 그 정도에 따라 카탈로그 노출 위험이 있습니다.

SSL을 사용하면 전용 해커 가 카탈로그를 가져올 수 없습니다 . (SSL을 위반하지 않는 한 Amazon도 중단 할 수 있습니다). SSL이 없으면 전용 해커가 전화를 스니핑하고 IP를 스푸핑하고 카탈로그를 끌어낼 수 있습니다. 따라서 위험에 대한 판단이 필요합니다.

IP 화이트리스트를 없애는 방법을 생각하고 있습니다. 일반적으로 OAuth를 사용하지 않고 관리하기가 쉽지 않기 때문입니다. 나는 그것에 국수를 할 것이다.