2009-09-02 3 views
5

신뢰할 수없는 네트워크에서도 수정되지 않은 javascript 코드를 사용하고 있다는 것을 어떻게 알 수 있습니까? 내가 개인 정보를 다루는 웹 응용 프로그램을JavaScript 코드 서명

:

여기 내 상황에 대한 몇 가지 추가 정보를 원하시면입니다. 로그인 프로세스는 JavaScript로 password-authenticated key agreement을 구현 한 것입니다. 기본적으로 로그인하는 동안 클라이언트와 서버간에 공유 비밀 키가 설정됩니다. 사용자가 로그인하면 서버와의 모든 통신은 공유 키를 사용하여 암호화됩니다. 시스템은 ACTIVE man-in-the-middle 공격에 대해 안전해야합니다. 필자의 구현이 정확하고 사용자가 피싱 공격에 희생되지 않을 정도로 똑똑하다고 가정하면 시스템에 큰 구멍이 하나 남아 있습니다. 공격자가 내 응용 프로그램을 다운로드 할 때이를 변조하고 암호를 훔치는 코드를 삽입 할 수 있습니다 . 기본적으로 전체 시스템은 사용자가 자신의 컴퓨터에서 실행중인 코드를 신뢰할 수 있다는 사실에 의존합니다. 서명 된 애플릿과 비슷한 것을 원하지만 가능한 경우 순수한 javascript 솔루션을 선호합니다.

+1

와우, 이미 구현 했습니까? 바퀴를 다시 발명 할 길. –

+7

그것은 바퀴를 다시 발명하지 않고 바퀴를 다시 구현합니다. 어쩌면 당신은 눈치 채지 못했지만 거기에는 여러 종류의 바퀴가 있습니다. –

+0

지금까지의 답변에서 광범위하고 포괄적 인 의견을 통해 SSL을 판단하고 있습니다. –

답변

0

로그인 JS의 MD5 해시를 취하는 외부 Javascript 파일을 가질 수 있으며 서버에 Ajax 요청을 보내 그것이 올 바르고 최신인지 확인합니다. 공개 키/개인 키 또는 다른 방법을 사용하여 응답이 서버에서 왔는지 확인하려면 여기에서 기본 보안 또는 암호화 방법을 사용하십시오.

그러면 클라이언트 측 스크립트가 확인되었음을 사용자에게 확실하게 표시하고 로그인 스크립트를 계속 진행할 수 있습니다.

+0

나는 당신의 해결책을 이해하고 있는지 모르겠다. 그러나 나는 그것이 검증 스크립트에 대한 신뢰를 변화시킬 것이라고 생각한다. 이 시스템을 작성한 전적인 이유는 성능과 보안상의 이유로 SSL을 피하기 위해서입니다. –

+2

@ 토니 : TLS/SSL이 특정 문제를 해결하기위한 업계 표준 인 이유가 있습니다. 비교적 낮은 비용으로 매우 높은 보안을 제공합니다. 물론 SSL을 사용할 때 성능이 저하되지만 자체 Javascript 기반 솔루션의 롤업을 정당화하기에는 성능이 충분하지 않습니다. 어떤 Javascript 솔루션을 사용하든 DNS 스푸핑이 모든 것을 무너 뜨리는 것을 방지하기 위해 힘든 시간을 보게 될 것입니다. SSL을 사용하면 작동합니다. –

+0

업계 표준이 매우 안전하여 보안 문제가 너무 많으면 어떻게해야합니까? 이 경로를 가기 전에 대안을 매우 신중하게 연구했습니다. TLS가 내 사용자 지정 시스템보다 안전하더라도 응용 프로그램에 필요한 제어가 부족합니다. 그럼에도 불구하고 귀하의 조언에 감사드립니다. –

4

어쩌면 내가 당신의 문제를 오해하고있다. 그러나 나의 첫 번째 생각은 SSL을 사용하는 것이다. 그것은 당신이 당신이 생각하는 서버와 이야기하고, 누구도 컨텐츠 중간을 수정하지 않도록 설계되었습니다. 이 경우 SSL을 사용하기 때문에 네트워크를 신뢰할 필요조차 없습니다.

이 접근법에 대한 좋은 점은 기존 웹 응용 프로그램에 쉽게 놓을 수 있다는 것입니다. 대부분의 경우 기본적으로 SSL을 사용하도록 HTTP 서버를 구성하고 http:// 요청을 https://으로 변경합니다.

+3

DNS 스푸핑에 대해 한 가지 더 언급합니다. 이는 스팸 및 man-in-the-middle 공격에 대해 이야기 할 때 흔히 사용되기 때문입니다. 공격자가 DNS 응답을 스푸핑하고 사용자를 악의적 인 웹 서버로 향하게하더라도 악성 서버는 여전히 올바른 인증서가 필요합니다. 사용자가 올바른 인증서를 생성하지 못하면 사용자의 브라우저가 모든 종류의 적색 플래그를 표시합니다. –

+1

SSL에는 여러 가지 약점이 있습니다. 대부분 복잡하기 때문에 내 시스템이 내 응용 프로그램에서 ssl을 대체하도록 설계되었지만 (일반적으로 ssl을 대체하지는 않습니다). –

+2

많은 약점이 있습니까? 당신은 정교 할 수 있습니까? –

4

이것은 오래된 질문이지만 대답은이 정의를 수행하지 않는 것처럼 보입니다.

HTTPS는 : //는 무결성을 제공 없는 사실 확인도 부인 방지. 악성 주입 스크립트가 쉽게 암호를 잡아 또는 라이브러리를 변경할 수 있기 때문에

나는, JS에서 암호화하지 마십시오 http://www.matasano.com/articles/javascript-cryptography/

로 안내. SJCL은 깔끔하지만

불행하게도,이 데스크톱 응용 프로그램뿐만 크지 않다 보안 노골적으로 잘못된 인식 서비스가 제공됩니다 (자신의 견적을, 이상 인용) 완전히 코드를 방지하는 데 적합하지 않기 때문에 주입, 악성 서버 및 사이드 채널 공격

장기적인 문제는 자바 스크립트가 부족하다는 것입니다 :

  1. 균일하게 작업 const를
  2. 객체 깊이 CONST 및 reprototypable하지 할 수있는 능력.
  3. 코드 서명

    // codesign: cert:(hex fingerprint) signature:(hex MAC)

    인증서 표시는 CA 인증서에서와 유사한 관리 될 것입니다. MAC은 적절한 서명/검증 구조와 함께 사용됩니다.

  4. 암호화는 클립 보드에 물건

표준을 구현하는 모든에 다른 일을 자바 스크립트 엔진을한다 얻기 (물론 서명) 자바 스크립트 기본 플러그인을 가질 이유가 있습니다,하지만 해 드리겠습니다있는 IT가 종료 절대적으로 필요있어 큰 악성 코드.

+1

ECMAScript 6에는 이제 1 & 2가 있습니다. – Rick

+0

CSP와 SRI는 코드 삽입 위험을 크게 줄일 수 있습니다. WebCrypto는 거의 솔루션 4였습니다. 코드 서명은 서비스 작업자와 시뮬레이션 할 수 있습니다. 서명 된 스크립트를로드하는 로더 스크립트를 만든 다음 로더 스크립트가 악의적으로 수정 된 경우 사용자에게 경고하기 위해 "업데이트"이벤트를 사용합니다 (또는 규격 허용됨, 금지). –