지난 몇 년 동안 클라이언트 측 (브라우저) 응용 프로그램의 추세가 실제로 시작되었습니다.
최신 프로젝트를 위해 시간과 함께 노력하고 클라이언트 측 응용 프로그램을 작성하기로 결정했습니다.
이 응용 프로그램의 일부는 사용자에게 트랜잭션 전자 메일 보내기 (예 : 가입 확인, 암호 재설정 전자 메일 등)입니다. 이메일을 보내기 위해 타사 API를 사용하고 있습니다.
일반적으로 서버에서 응용 프로그램을 실행합니다. 내 서버의 코드에서 타사 API를 호출합니다.
클라이언트 측 응용 프로그램을 실행하면 사용자의 브라우저에서이 작업을 수행해야합니다. 타사 API는이를 달성하는 데 필요한 JavaScript 파일을 제공합니다.
내가 볼 수있는 첫 번째 눈부신 문제는 API 키를 사용해야한다는 것입니다. 이것은 일반적으로 내 서버에 안전하게 저장되지만 이제는이 키를 클라이언트 브라우저에 제공해야합니다.
이 문제를 해결할 수 있다고 가정하면 다음 문제는 기술에 정통한 사용자가 브라우저에서 JavaScript 개발자 도구를로드하고 응용 프로그램에서 설정 한 규칙을 준수하는 대신 원하는대로 이메일 API를 사용하지 못하게하는 것입니다 .
내 일반적인 질문은 클라이언트 측 응용 프로그램의 악의적 사용을 어떻게 방지 할 수 있습니까?
답변
당신은 할 수없고, 더 많은 사람들이 이것을 이해하고 더 깊이 이해할수록 세상에 더 좋습니다.
사용자가 제어하는 장치에서 실행되는 코드는 제어 할 수 없습니다. 스마트 폰은 탈옥 될 수 있습니다. 셋톱 박스에 금이 갈 수 있습니다. 일반 브라우저는 JavaScript 코드에 대한 액세스를 차단하려고 시도조차하지 않습니다. 훔치거나 남용 할만한 가치가있는 경우, 서버 측에서 소중히 여기는 모든 것을 검증하지 않으면 결정된 공격자 가 이를 수행 할 수 있습니다.
난독 화는 거의 도움이되지 않습니다. 원격 금융에 관여하는 즉시 관심을 끄는 상대는 분류 된 광고와 같은 어셈블리 언어를 읽습니다. 키를 보호하는 장치가 추측해야하는 장치와 동일하기 때문에 암호화가 도움이되지 않습니다. 비슷한 이유로 작동하지 않는 다른 명백한 대책이 많이 있습니다.
불행히도 이것은 매우 불편한 진실입니다. 세상에는 원격 트러스트의 근본적인 고장을 극복 할 수 있다고 생각하는 소규모 및 빅 오퍼레이터들로 가득 차 있습니다. 코드가 우리가 가정 한 방식으로 실행될 것이라고 가정 할 수 있다면 너무 좋을 것이기 때문입니다 . 그리고 네, 모든 것을 훨씬 쉽게 만들어서 웃기지 않을 것입니다. 그러나 바라는 것이 그렇게되지는 않으며, 당신이 불쾌 함을 피할 수있는 하나의 스마트 쿠키가 당신과 당신의 고객을 태울 것이라는 희망에 반대하기를 바라고 있습니다. 따라서 인터넷은 적의 영토라는 생각을 가지고 추정치에 추가 된 비용을 포함 시키면 괜찮을 것입니다.
물론, 심층 방어와 같은 것이 있습니다. 자바 스크립트를 난독 처리한다고해서 결정된 공격자가 될 수는 없지만 덜 결정된 공격자가있을 수 있습니다. 자산이 보호 할만한 가치가 있지만 어떤 비용으로도 가치가 없다면, 이러한 조치 중 하나라도 시스템에 비즈니스 가치를 추가 할 수 있습니다. 완벽 할 수는 없습니다. 당신이하고있는 트레이드 오프를 충분히 알고 있다면, 그것은 합리적인 전략 일 수 있습니다.
답변
여기서 규칙은 다음과 같습니다.
사용자가 변조 한 경우 다른 사람에게 영향을 미치지 않는 모든 클라이언트 쪽 작업을 수행하십시오. 특히 그래픽 효과를 의미합니다.
서버 측에서 보안을 유지해야하는 모든 작업을 수행하고 클라이언트에서 UI 이벤트를 보내면됩니다 (예 : 클라이언트는 서버가 실제로 트랜잭션을 수행하는 동안 “사용자가”구매 버튼을 눌렀습니다 “라고 표시 함). 특히, 그것은 금융 거래를 의미합니다.
답변
이것은 완전히 클라이언트 측 응용 프로그램을 만드는 것이 적절 하지 않은 경우입니다.
응답 성을 향상시키기 위해 클라이언트 측 양식의 논리 및 기본 유효성 검사를 수행 할 수 있습니다 (누군가 요청을 속일 수도 있기 때문에 여전히 서버에서 다시 확인해야 함). 응답 성을 향상시키기 위해 JavaScript에서 HTTP 요청을 수행하여 JSON으로 데이터를 전달할 수 있습니다. 페이지 데코레이션 등을 다시 보내지 말고 트랜잭션 자체를 인증하고 승인해야하는 경우 여전히 서버에서 발생해야합니다.
답변
중간 단락은 문제의 핵심입니다.
클라이언트 측 앱을 실행한다는 것은 이제 사용자 브라우저에서 발생해야한다는 것을 의미합니다. 타사 API는이를 달성하는 데 필요한 js 파일을 제공합니다.
클라이언트 측 앱이 서버 측 작업을 할 수 없다는 것을 의미하는 이유는 무엇입니까? 클라이언트 측 프로그래밍을 향한 추진은 서버를 제거하는 것이 아니라 브라우저가 최종적으로 더 나은 사용자 인터페이스를 만들기 위해 지원하는 최신 기술을 활용하는 것입니다.
에 관해서는 .js받은 파일, 당신은이 브라우저위한 것입니다 확신? node.js 라이브러리 일 수 있습니까?
답변
여기서 물러서서 더 높은 수준의 모습을 보도록하겠습니다. 우리는 .. Eudora 또는 전망 (브라우저가 필요없는 클라이언트 측 앱)이 어떤 회사에도 재정적 손실을 초래 했습니까? 아니요. 누구나 POP / SMTP API에 쓰고 클라이언트가 될 수 있습니다. 그러나 서버 손실은 없습니다. 서버는 클라이언트 동작, 계산, 스토리지, 온도, 디스크 크기, 램 크기, 모니터 DPI, GPU, 클라이언트의 FPU yada yada를 제한하지 않았지만 응답 할 대상을 정확히 지정했습니다. 은행에 침입하는 데 빨리 또는 MS- 머니가 사용된다는 소식을 들어 본 적이 있습니까?
브라우저 (예 : 클라이언트 측) 앱은 동일한 아키텍처를 사용할 수 있습니다.
- API를 사용하여 서버를 빌드합니다 (BTW, 항상 GET POST HEAD의 파생물로 귀결됩니다).
- 서버에서 API가 각 호출마다 인증되고 신원 확인 된 클라이언트와 만 통신하는지 확인하십시오.
- 그런 다음 고객이 누구인지 상관하지 않습니다.
- 그리고 2014 년에 여행을 다녀온 테크노 포브 대대 할아버지의 손에있는 브라우저, 탈옥 기기, 구글 글래스, DOS 3.1 또는 새로운 넥서스인지 걱정하지 않아도됩니다. 지난 15 년 동안 우리의 삶에 침수 된 기술.
- 이제 다른 모든 것을 클라이언트 측으로 오프로드 할 수 있습니다.
비누 상자
@KilianFoth는 순진하고 무모한 사람들에게 중요한 인식 포인트를 제공합니다. 주로 헤드 라인을 항상 읽지 만 앱, 코드, 고용주, 고객, 자신의 은행 계좌에 대해서는 일어날 것이라고 생각하지 않는 사람들입니다. 시스템을 관리되지 않거나 통제되지 않은 노출에 노출시키는 앱을 허용하는 고용주 (특히 CTO)는 더욱 무모합니다. 그러나 나는 항상 “우리는 결코 배우지 않는”것에 의아해합니다.
SoapBoxEnd
요약하자면. 견고하고 엄격한 서버 측 API를 만듭니다. 클라이언트가 처리 할 수있는 모든 것을 기반으로 다른 모든 것을 클라이언트로 오프로드
답변
나는 당신이 정말로 할 수 없다고 주장합니다. 고객에게 데이터를 기꺼이 보내려면 데이터가 남용 될 것으로 예상해야하지만 가능합니다. API 키에 대한 귀하의 예는 요점을 설명하며 클라이언트 측 JS에는 포함시키지 않을 것이며 도난 당하고 악용 될 것입니다.
보안을 유지하려면 여전히 약간의 서버 코드가 필요합니다. 로그인 한 사용자와 관련된 데이터 만 검색하는 것만 큼 간단합니다. 이 인증을 모두 클라이언트 측에서 수행 할 수는 없습니다. 귀하는 이점을 활용할 수 있으며 데이터는 안전하지 않습니다.
JS 클라이언트 측 경험은 항상 서버 코드에 추가되는 것으로 간주합니다. 클라이언트에 대한 유효성 검사는 훌륭한 사용자 환경을 제공하지만 수신 서버의 POST 데이터도 확인하지 않으면 공격 할 수 있습니다. 클라이언트의 모든 것은 용의자로 간주되어야합니다.
답변
정말 간단합니다. 클라이언트 컴퓨터와 그 컴퓨터에서 실행되는 모든 소프트웨어가 영리한 악의적 인 해커를 완전히 제어하고 있다고 가정합니다.
즉, 서버에서 클라이언트로 보내는 모든 정보는 악의적 인 해커에게 알려 지므로 서버 나 비즈니스를 공격하는 데 사용될 수있는 정보를 클라이언트에게 보내지 않아야합니다.
또한 악의적 인 해커가 클라이언트에서 서버로 보낸 모든 항목을 생성 했으므로 서버 코드는 클라이언트가 보낼 수있는 어떤 것도 서버를 성공적으로 공격 할 수 없도록해야합니다.
물론 구현은 문제이지만 중요한 것은 정신적 태도입니다. 서버가 말하고 있다고 생각하는 “클라이언트”는 클라이언트가 아니라 적극적인 공격자입니다.
또한 사용자는 비즈니스 방법을 공격하려고 시도하지만 클라이언트 측 프로그래밍과는 아무런 관련이없는 영리한 관리자라고 가정해야합니다.