2011-01-19 4 views
2

내 API (데스크톱 응용 프로그램) (기본적으로 난 그냥 요청에 http 대신 https를 사용하고 있습니다) SSL을 통해 기본 HTTP 인증을 사용하여 내 웹 응용 프로그램과 통신합니다. 내 API는 사용자가 잘못된 정보를 전송하지 않도록 만드는 로직을 구현했습니다,하지만 난이 문제는 누군가가 API를 무시하고 내 웹 응용 프로그램에 가입하기 때문에 자격 증명을 취득하는 것은 간단하다 (잠재적 후 잘못된 데이터에 컬 사용할 수 있다는 것입니다 비어 있는).보안 조언 : SSL 및 API 액세스

나는 다음과 같은 옵션에 대한 생각 :

  1. 웹 응용 프로그램에서 API의 논리를 중복 그래서 사용자는 곱슬 곱슬하거나 동일한 조건되게됩니다 다른 도구를 사용하여 시스템을 속이려고해도 .

  2. 는 단지 내 API 내 웹 응용 프로그램과 통신 할 수 있는지 확인하기 위해 추가 인증 검사를 구현합니다. (아마 SSL 클라이언트 인증서?).

  3. 암호화 데이터 (자료 64?)

나는 컬과 같은 도구를 사용하여 내 웹 응용 프로그램을 스푸핑 사용자에 대한 약간의 편집증거야 알고 있지만 나는 오히려 미안한 것보다 안전한 것입니다. 논리를 복제하는 것은 정말 고통스럽고 나는 그렇게하지 않을 것입니다. SSL 클라이언트 인증서에 대해 잘 모릅니다. 기본 HTTP 인증과 함께 사용할 수 있습니까? 그들은 내 요청을 처리하는 데 더 오래 걸릴 것입니까? 다른 옵션은 무엇입니까?

미리 감사드립니다.

+2

내 의견으로는 서버 측의 유효성 검사를 대체 할 수 없습니다. – sinelaw

+0

해답을 모두 주셔서 감사 드리며, 서버 측 유효성 검사를 실시하겠습니다. – David

답변

2

SSL은 중간자 (man-in-the-middle) 공격으로부터 사용자를 보호하지만 SSL의 클라이언트 측에서 시작된 공격으로부터는 사용자를 보호하지 않습니다. 클라이언트 API에 내장 된 클라이언트 인증서를 사용하면 클라이언트 측 API에서 데이터를 생성했음을 확인할 수는 있지만 클라이언트 측에서 암호화되기 직전에 데이터를 수동으로 수정했는지 여부를 파악하는 데 도움이되지 않습니다. 기술적으로 클라이언트쪽에있는 사용자는 클라이언트 쪽 API를 통해 디버깅하여 데이터를 수정할 수있는 방법을 항상 찾을 수 있습니다. 당신이 할 수있는 최선책은 클라이언트 측 API에 방해물을 두어 그것을 해독하기 어렵게 만드는 것입니다. 실제로 서버 측에서 유효성 검사가 진행됩니다.


유효성 검사 코드를 리팩터링하여 양측에서 사용할 수 있도록하십시오.

2

나는 그런 검증이 정확하게 당신이 (여러 클라이언트 유형을 지원)로 실행중인 문제의 종류를 피하기 위해 서버 측에서 일반적으로 더 나은 것을 sinelaw의 의견에 일반적으로 동의 할 것입니다. 즉, 논리를 움직일 수있는 위치에 있지 않을 수도 있습니다.이 경우 논리를 움직일 필요가 있습니다. 나에게

, 옵션은 다음과 같습니다

  • 클라이언트 측 인증서, 당신이 제안하는대로 - 당신은 기본적으로 클라이언트가 누가임을 인증 (또는 귀하의 경우 무엇을) 당신이 그것을 기대하고 있습니다 있다. 나는 이전에 이들과 함께 작업했으며 상호 인증 구성은 혼란 스러울 수 있습니다. 퍼포먼스에 대해 걱정하지 않으려합니다. 첫 번째 단계는 동작을 원하는대로 (정확함 우선) 생각합니다. 어쨌든, 일반적으로이 옵션은 가능하지만 웹 컨테이너에 따라 설치가 번거로울 수 있습니다. 서버 측에서 그 존재/값 확인 데스크톱 응용 프로그램에서

  • 사용자 정의 HTTP 헤더, 아니면 기존의 사용자 에이전트 헤더의 활용. 트래픽을 암호화하기 때문에 보내는 HTTP 헤더를 쉽게 볼 수 없어서 이름과 값을 원하는대로 설정할 수 있습니다. 서버 측에서 확인하면 요청을 보내는 클라이언트가 데스크톱 앱을 사용하고 있음을 확신 할 수 있습니다.

나는 개인적으로 맞춤 헤더 경로로 이동합니다. 그것은 100 % 완벽하지 않을 수 있습니다,하지만 당신은 위험이 가장을 완화하는 가장 간단한 일을 에 관심이 있다면, 그것은 최상의 경로로 저를 친다. HTTPS를 사용하지 않으면 훌륭한 옵션이 아닙니다. HTTPS를 사용한다고 가정하면 누군가는 스니퍼를 썼을 때 헤더를 볼 수 있기 때문에 좋은 방법은 아닙니다.

나는 당신이 몇 가지 혼란 스러울 수도 있다고 생각합니다. HTTPS는 암호화를 제공 할 것이지만 반드시 (클라이언트) 인증을 필요로하지는 않습니다. 그것들은 종종 서로 번들로 묶여 있지만 두 가지가 있습니다. 난 당신이 실제 사용자의 인증 (기본 인증 또는 뭐든간에)와 HTTPS를 사용하고 있다고 가정합니다.

+0

적어도 * some * 인증이 없으면 SSL을 사용할 필요가 없습니다. 그렇지 않으면 무작위 적으로 무언가에 보안 연결이되어 중간자 공격 (man-in-the-middle attack)에 취약합니다. 그렇기 때문에 SSL 프로토콜은 일반적으로 알려진 ident, 신뢰할 수있는 ident의 인증서 체인 또는 ident과 클라이언트가 요청한 호스트 이름 간의 일치를 제공하지만 서버가 클라이언트에 대한 ID를 증명해야합니다. 또는이 두 가지를 자연스럽게 결합한 것입니다. –

+1

동의하지만 클라이언트 인증에 대해 이야기하고 있음을 분명히 알았습니다. 문제의 핵심은 클라이언트 인증입니다. (그는 사용자 인증/암호를 통한 일반적인 클라이언트 인증을 의미하는 기본 인증을 말했습니다) – kvista

2

이어야합니다. 서버 측의 데이터 유효성을 검사해야합니다. 서버 쪽 유효성 검사가 실패하면 문제가 다시 발생합니다. 문제가 발생하지 않아도됩니다.하지만 그렇게하지 않으면 완전히 상처를 입을 수 있습니다. (이 방법에 대해 생각해 보라. 그것은 당신이 완전히 제어하는 ​​서버의 논리이다. 따라서 통신의 유효성에 대한 결정을 내리는 것이 서버의 논리이다.) 클라이언트 인증서를 사용하면 실제로 많은 것을 보호 할 수는 없다. 추가적으로 API 사용 권한이있는 사용자로부터 추가로 그 외의 경우, 클라이언트 인증서를 추출하기 위해 코드를 분해 할 수 있습니다 (클라이언트 코드를 읽을 수 있어야 사용 가능합니다). 추가 암호화를 추가하지 않을 것입니다. SSL 연결로 이미 제공되는 것보다 많은 안전을 추가하지 않으면 상황이 훨씬 어려워집니다 (더 많은 일이 잘못 될 수 있습니다). (암호화를 추가하면 HTTPS를 통해 전송 된 메시지가 신뢰할 수없는 프록시를 거쳐야하는 경우입니다.)

Base-64는 암호화되지 않습니다. 이것은 처리하기 쉬운 문자로 바이트를 인코딩하는 방법 일뿐입니다.