브라우저 확장 : API 호출 보안 방법

Question

MEAN 서버 (-> node.js)와 (GET 및 POST) 데이터를 교환해야하는 브라우저 확장 프로그램에서 작업하고 있습니다. 내 확장을 우회하여 악성 소프트웨어/서버/개인이 직접 데이터를 보내거나 요청함으로써 발생하는 DDoS 공격 및 유사한 위협을 피하기 위해 서버 측 API 경로를 보호하는 방법에 대해 궁금합니다.

내가 각 호출에 포함되어야하는 여러 토큰을 사용하려는 (HTTPS를 통해 연결의 GET/POST) : 눈에 보이지 않게 내 확장 및 흰색 내부에 하드 코딩되어

• 정적 확장 ID 해시 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

• 시간

• 해시 주어진 기간에 사용자/내선 당 요구의 양을 제한 : 예 EXT_ID 같이, 서버 측에 나열 그리고 자명 같이 (상기 확장 환경 내부에 입력 필드를 통하여 사용자에 의해 제공되고 국부적으로 저장된) 소금 사용자 인증서 : e3b0c44298fc1c149 [...] 암호 : da39a3ee5e6b4b0d3255bfe [...]

내가 바라고 이 분야의 숙련 된 전문가들이이 접근 방식을 승인하거나 향상 시키거나 합리적인 대안을 제시하기 위해 일부 입력 및 건설적인 비평을하고 있습니다.

Answer 1

목표는 잘못된 요청을 신속하게 삭제할 수있게하는 것입니다. 최고의 투자 수익은 캐싱과 점진적인 지연을 통해 얻을 수 있습니다.

즉, 할 수있는 일은 해시 또는 타임 스탬프와 결합 된 각 요청의 값을 암호화하는 것입니다. 즉, 클라이언트가하는 각 요청에는 제출 된 시간을 기반으로 한 고유 한 값이 있으므로 각 요청은 고유해야합니다. 이것은 또한 재생 공격을 막기 위해 사용자에게 약간의 추가 보안을 제공합니다. DDOS를 피하기 위해

Answer 2

는

API 레벨 제한 서비스 거부가 느린 (리소스 집약적 인) API를 이용 공격에 대한 도움을 공격한다. 이 경우 간단한 로그인 요구 사항과 사용자 별 속도 제한으로 충분해야합니다.

네트워크 연결, 커널 리소스 (TCP 연결)를 포화 시키거나 응용 프로그램의 네트워크 IO 부분 또는 TLS 계층 (공격 핸드 셰이크)을 공격하는 공격에는 유용하지 않습니다.

내 확장을 우회하여 악성 소프트웨어/서버/개인이 직접 데이터를 보내거나 요청할 때 발생합니다.

[...] 눈에 보이지 않게 내 확장 당신이이 plannning하는 것은 가능하지 않다 본질적으로

, 내부에 하드 코딩 된 ID 해시. 브라우저는 공개 프로토콜을 사용하며 디버깅 할 수 있습니다. 확장 기능이 전송하는 모든 것은 스크립트에 의해 복제 될 수 있습니다.

어떻게 든 확장 프로그램을 외부 소프트웨어로 복제 할 수 없도록 만들려고 노력하고 있습니다. 근본적으로 깨지지 않는 DRM을 고안하려고합니다.