클라이언트 측 코딩 : 악의적 인 사용을 방지하는 방법?


60

지난 몇 년 동안 클라이언트 측 (브라우저) 응용 프로그램의 추세가 실제로 시작되었습니다.

최신 프로젝트를 위해 시간과 함께 노력하고 클라이언트 측 응용 프로그램을 작성하기로 결정했습니다.

이 응용 프로그램의 일부는 사용자에게 트랜잭션 전자 메일 보내기 (예 : 가입 확인, 암호 재설정 전자 메일 등)입니다. 이메일을 보내기 위해 타사 API를 사용하고 있습니다.

일반적으로 서버에서 응용 프로그램을 실행합니다. 내 서버의 코드에서 타사 API를 호출합니다.

클라이언트 측 응용 프로그램을 실행하면 사용자의 브라우저에서이 작업을 수행해야합니다. 타사 API는이를 달성하는 데 필요한 JavaScript 파일을 제공합니다.

내가 볼 수있는 첫 번째 눈부신 문제는 API 키를 사용해야한다는 것입니다. 이것은 일반적으로 내 서버에 안전하게 저장되지만 이제는이 키를 클라이언트 브라우저에 제공해야합니다.

이 문제를 해결할 수 있다고 가정하면 다음 문제는 기술에 정통한 사용자가 브라우저에서 JavaScript 개발자 도구를로드하고 응용 프로그램에서 설정 한 규칙을 준수하는 대신 원하는대로 이메일 API를 사용하지 못하게하는 것입니다 .

내 일반적인 질문은 클라이언트 측 응용 프로그램의 악의적 사용을 어떻게 방지 할 수 있습니까?


24
당신 이이 응용 프로그램을 가지고 있지 않은 이유는 당신의 자신의 서버와 통신하고 서버는 당신이 사용해야하는 외부 서비스로 요청을 전달합니까? (많은 이러한 서비스는 어쨌든 이런 방식으로 서비스를 사용하는 것을 금지 할 것입니다)
thorsten müller

11
이것이 API 키가 궁극적으로 무의미한 이유입니다. 서버는 명령을 보내는 앱을 신뢰하려고 시도해서는 안됩니다. 사용자 만 신뢰해야합니다.
Kevin Panko

42
나는 어떤 제정신 사람은 지금까지 "어떠한 경우 아래로"클라이언트 측 응용 프로그램을 "정의 보지 못한 적이 더 합리적인 인수보다 strawman 것 같아 - 서버와 통신". 분명히 서버 측에서 처리해야 할 것이 있지만 대부분의 작업은 문제없이 로컬에서 수행 할 수있어 응답 성과 확장 성을 크게 향상시킬 수 있습니다.
Voo

4
"브라우저 전용 앱"을 향한 추진력은 어디에 있습니까? 나는 당신이 묘사 한 것과 같은 것을 보지 못했고, 클라이언트 코드의 비밀을 미친 아이디어로, 심지어 내가 아는 가장 힘든 프런트 엔드조차도 그렇게하지 않을 것입니다.
Wheeyls

2
클라이언트 측의 보안 자원을 보호하려는 모든 시도는 불변의 보안 법칙을 위반하기 때문에 파산됩니다. # 2 / 3-소프트웨어가 적의 컴퓨터에서 실행되고 있다면 정의상 컴퓨터가 아니며 이미 잃어버린 것입니다. # 7 클라이언트에게 암호 해독 키를 제공해야하기 때문에 암호화로 리소스를 보호하려는 시도는 끝났습니다. # 10 어떤 기술도 위의 문제를 해결할 수 없습니다. blogs.technet.com/b/rhalbheer/archive/2011/06/16/…
Dan Neely

답변:


200

당신은 할 수없고, 더 많은 사람들이 이것을 이해하고 더 깊이 이해할수록 세상에 더 좋습니다.

사용자가 제어하는 ​​장치에서 실행되는 코드는 제어 할 수 없습니다. 스마트 폰은 탈옥 될 수 있습니다. 셋톱 박스에 금이 갈 수 있습니다. 일반 브라우저는 JavaScript 코드에 대한 액세스를 차단하려고 시도조차하지 않습니다. 훔치거나 남용 할만한 가치가있는 경우, 서버 측에서 소중히 여기는 모든 것을 검증하지 않으면 결정된 공격자 이를 수행 할 수 있습니다.

난독 화는 거의 도움이되지 않습니다. 원격 금융에 관여하는 즉시 관심을 끄는 상대는 분류 된 광고와 같은 어셈블리 언어를 읽습니다. 키를 보호하는 장치가 추측해야하는 장치와 동일하기 때문에 암호화가 도움이되지 않습니다. 비슷한 이유로 작동하지 않는 다른 명백한 대책이 많이 있습니다.

불행히도 이것은 매우 불편한 진실입니다. 세상에는 원격 트러스트의 근본적인 고장을 극복 할 수 있다고 생각하는 소규모 및 빅 오퍼레이터들로 가득 차 있습니다. 코드가 우리가 가정 한 방식으로 실행될 것이라고 가정 할 수 있다면 너무 좋을 것이기 때문입니다 . 그리고 네, 모든 것을 훨씬 쉽게 만들어서 웃기지 않을 것입니다. 그러나 바라는 것이 그렇게되지는 않으며, 당신이 불쾌 함을 피할 수있는 하나의 스마트 쿠키가 당신과 당신의 고객을 태울 것이라는 희망에 반대하기를 바라고 있습니다. 따라서 인터넷은 적의 영토라는 생각을 가지고 추정치에 추가 된 비용을 포함 시키면 괜찮을 것입니다.

물론, 심층 방어와 같은 것이 있습니다. 자바 스크립트를 난독 처리한다고해서 결정된 공격자가 될 수는 없지만 덜 결정된 공격자가있을 수 있습니다. 자산이 보호 할만한 가치가 있지만 어떤 비용으로도 가치가 없다면, 이러한 조치 중 하나라도 시스템에 비즈니스 가치를 추가 할 수 있습니다. 완벽 할 수는 없습니다. 당신이하고있는 트레이드 오프를 충분히 알고 있다면, 그것은 합리적인 전략 일 수 있습니다.


6
그러나 이것을 원근법으로 설명하자면, 이것은 모든 소프트웨어, 운영 체제 또는 트랜잭션 슈트에 해당됩니다. 결국에는 매우 훌륭한 코드 난독 화 장치가 있으며 소프트웨어 해킹에 대한 즉각적인 재정적 인센티브가 없다면 막대를 충분히 높일 수 있습니다!
팔코

5
요즘 기업들은 처리하기 전에 (예 : 광고 차단기를 통해) 콘텐츠를 해킹하는 사람들에 대한 법적 조치를 위협하고 있습니다. 그것은 단지 기술적 인 행동이 얼마나 불가능한지를 보여줄뿐입니다 .
Kilian Foth

62
처음 두 문장에 대해 자세히 설명하면 미묘한 사람들은 종종 클라이언트 측 브라우저 앱의 포인트가 무거운 리프팅을 오프로드하는 것입니다. 서버는 여전히 이메일 전송 또는 데이터 액세스와 같은 신뢰할 수있는 작업을 담당합니다. 그러나 클라이언트가 해당 데이터에서 그래프를 렌더링하게하면 보안 모델을 변경하지 않고도 CPU 시간과 비용을 절약 할 수 있습니다.
ssube

11
@Gaz_Edge 여기서 문제는 클라이언트 측 앱이 본질적으로 안전하지 않다는 점이 아니라는 점 에 유의해야합니다 . 문제는 공개하고 싶지 않은 정보로 클라이언트를 신뢰해야하는 방식으로 이러한 클라이언트 측 앱을 작성하는 것입니다. 대부분의 처리가 서버에서 발생하는 응용 프로그램과 마찬가지로 클라이언트가 많은 응용 프로그램을 작성할 수 있습니다. (자세한 내용은 jhocking의 답변 참조 )
Ajedi32

7
@ Ajedi32 클라이언트 측 앱 안전하지 않습니다. 클라이언트 측에서 수행 한 논리가 서버 측에서 확인되지 않으면 보안 앱을 설계 할 수 없습니다. 이 시점에서 클라이언트 측 로직은 UI 기능 또는 기본 점검을 오프로드하는 방법이되지만 모든 것은 항상 서버에서 점검해야합니다 !! .

69

여기서 규칙은 다음과 같습니다.

사용자가 변조 한 경우 다른 사람에게 영향을 미치지 않는 모든 클라이언트 쪽 작업을 수행하십시오. 특히 그래픽 효과를 의미합니다.

서버 측에서 보안을 유지해야하는 모든 작업을 수행하고 클라이언트에서 UI 이벤트를 보내면됩니다 (예 : 클라이언트는 서버가 실제로 트랜잭션을 수행하는 동안 "사용자가"구매 버튼을 눌렀습니다 "라고 표시 함). 특히, 그것은 금융 거래를 의미합니다.


28

이것은 완전히 클라이언트 측 응용 프로그램을 만드는 것이 적절 하지 않은 경우입니다.

응답 성을 향상시키기 위해 클라이언트 측 양식의 논리 및 기본 유효성 검사를 수행 할 수 있습니다 (누군가 요청을 속일 수도 있기 때문에 여전히 서버에서 다시 확인해야 함). 응답 성을 향상시키기 위해 JavaScript에서 HTTP 요청을 수행하여 JSON으로 데이터를 전달할 수 있습니다. 페이지 데코레이션 등을 다시 보내지 말고 트랜잭션 자체를 인증하고 승인해야하는 경우 여전히 서버에서 발생해야합니다.


11
참고 : 클라이언트 쪽 양식의 유효성을 검사하는 것이 좋지만 서버 쪽도 확인하는 것을 잊지 마십시오! 클라이언트 코드를 브라우저로 보내면 코드가 중지됩니다! 다시 보내는 모든 단일 비트의 유효성을 검사해야합니다!
Josef

17

중간 단락은 문제의 핵심입니다.

클라이언트 측 앱을 실행한다는 것은 이제 사용자 브라우저에서 발생해야한다는 것을 의미합니다. 타사 API는이를 달성하는 데 필요한 js 파일을 제공합니다.

클라이언트 측 앱이 서버 측 작업을 할 수 없다는 것을 의미하는 이유는 무엇입니까? 클라이언트 측 프로그래밍을 향한 추진은 서버를 제거하는 것이 아니라 브라우저가 최종적으로 더 나은 사용자 인터페이스를 만들기 위해 지원하는 최신 기술을 활용하는 것입니다.

에 관해서는 .js받은 파일, 당신은이 브라우저위한 것입니다 확신? node.js 라이브러리 일 수 있습니까?


4
JS 파일이 NodeJS 서버를위한 것이라는 좋은 제안에 +1
Machinarius

11

여기서 물러서서 더 높은 수준의 모습을 보도록하겠습니다. 우리는 .. Eudora 또는 전망 (브라우저가 필요없는 클라이언트 측 앱)이 어떤 회사에도 재정적 손실을 초래 했습니까? 아니요. 누구나 POP / SMTP API에 쓰고 클라이언트가 될 수 있습니다. 그러나 서버 손실은 없습니다. 서버는 클라이언트 동작, 계산, 스토리지, 온도, 디스크 크기, 램 크기, 모니터 DPI, GPU, 클라이언트의 FPU yada yada를 제한하지 않았지만 응답 할 대상을 정확히 지정했습니다. 은행에 침입하는 데 빨리 또는 MS- 머니가 사용된다는 소식을 들어 본 적이 있습니까?

브라우저 (예 : 클라이언트 측) 앱은 동일한 아키텍처를 사용할 수 있습니다.

  1. API를 사용하여 서버를 빌드합니다 (BTW, 항상 GET POST HEAD의 파생물로 귀결됩니다).
  2. 서버에서 API가 각 호출마다 인증되고 신원 확인 된 클라이언트와 만 통신하는지 확인하십시오.
  3. 그런 다음 고객이 누구인지 상관하지 않습니다.
  4. 그리고 2014 년에 여행을 다녀온 테크노 포브 대대 할아버지의 손에있는 브라우저, 탈옥 기기, 구글 글래스, DOS 3.1 또는 새로운 넥서스인지 걱정하지 않아도됩니다. 지난 15 년 동안 우리의 삶에 침수 된 기술.
  5. 이제 다른 모든 것을 클라이언트 측으로 오프로드 할 수 있습니다.

비누 상자

@KilianFoth는 순진하고 무모한 사람들에게 중요한 인식 포인트를 제공합니다. 주로 헤드 라인을 항상 읽지 만 앱, 코드, 고용주, ​​고객, 자신의 은행 계좌에 대해서는 일어날 것이라고 생각하지 않는 사람들입니다. 시스템을 관리되지 않거나 통제되지 않은 노출에 노출시키는 앱을 허용하는 고용주 (특히 CTO)는 더욱 무모합니다. 그러나 나는 항상 "우리는 결코 배우지 않는"것에 의아해합니다.

SoapBoxEnd

요약하자면. 견고하고 엄격한 서버 측 API를 만듭니다. 클라이언트가 처리 할 수있는 모든 것을 기반으로 다른 모든 것을 클라이언트로 오프로드


6

나는 당신이 정말로 할 수 없다고 주장합니다. 고객에게 데이터를 기꺼이 보내려면 데이터가 남용 될 것으로 예상해야하지만 가능합니다. API 키에 대한 귀하의 예는 요점을 설명하며 클라이언트 측 JS에는 포함시키지 않을 것이며 도난 당하고 악용 될 것입니다.

보안을 유지하려면 여전히 약간의 서버 코드가 필요합니다. 로그인 한 사용자와 관련된 데이터 만 검색하는 것만 큼 간단합니다. 이 인증을 모두 클라이언트 측에서 수행 할 수는 없습니다. 귀하는 이점을 활용할 수 있으며 데이터는 안전하지 않습니다.

JS 클라이언트 측 경험은 항상 서버 코드에 추가되는 것으로 간주합니다. 클라이언트에 대한 유효성 검사는 훌륭한 사용자 환경을 제공하지만 수신 서버의 POST 데이터도 확인하지 않으면 공격 할 수 있습니다. 클라이언트의 모든 것은 용의자로 간주되어야합니다.


4

정말 간단합니다. 클라이언트 컴퓨터와 그 컴퓨터에서 실행되는 모든 소프트웨어가 영리한 악의적 인 해커를 완전히 제어하고 있다고 가정합니다.

즉, 서버에서 클라이언트로 보내는 모든 정보는 악의적 인 해커에게 알려 지므로 서버 나 비즈니스를 공격하는 데 사용될 수있는 정보를 클라이언트에게 보내지 않아야합니다.

또한 악의적 인 해커가 클라이언트에서 서버로 보낸 모든 항목을 생성 했으므로 서버 코드는 클라이언트가 보낼 수있는 어떤 것도 서버를 성공적으로 공격 할 수 없도록해야합니다.

물론 구현은 문제이지만 중요한 것은 정신적 태도입니다. 서버가 말하고 있다고 생각하는 "클라이언트"는 클라이언트가 아니라 적극적인 공격자입니다.

또한 사용자는 비즈니스 방법을 공격하려고 시도하지만 클라이언트 측 프로그래밍과는 아무런 관련이없는 영리한 관리자라고 가정해야합니다.


0

내 생각에 클라이언트 측 응용 프로그램은 대부분 UI에 관한 것입니다. 예를 들어 모든 UI 시스템이 클라이언트로 한 번 전송 된 다음 클라이언트는 원하는대로 작업을 수행합니다.

일반적으로 서버에서 응용 프로그램을 실행합니다. 내 서버의 코드에서 타사 API를 호출합니다.

클라이언트 측 응용 프로그램을 실행하면 사용자의 브라우저에서이 작업을 수행해야합니다. 타사 API는이를 달성하는 데 필요한 JavaScript 파일을 제공합니다.

API 키가 있으면 클라이언트 측에서 작동하지 않습니다. 클라이언트 측에서 API 키를 제공하면 누구나 해당 키에 액세스하여 자신의 목적으로 사용할 수 있습니다. 클라이언트가 필요할 때 저장하고 서버 측에서 사용한 다음 Ajax / WebSockets를 사용하여 결과를 보내십시오.

은행에서 다음과 같이 말한 것과 같습니다. "클라이언트가 직접 요청할 수 있고 더 이상 서버를 방해하지 않도록 주 데이터베이스 클라이언트 측의 비밀번호를 입력하겠습니다."

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.