120. 버블의 Page 보안 설정 (중급): javascript 코드 보안, workflow 보안, Optimize Application, 서버측 redirection

이 섹션에서는 페이지, 요소(element) 및 workflow의 보안을 다룹니다.

 

(1) 페이지 보안의 의미

Client side 및 Server side 작업에 대한 글에서 살펴보았듯이 Bubble은 사용자 장치에서 직접 데이터를 다운로드하고 여러 프로세스를 완료합니다.

Client side & Server Side 보안 (중급) : 버블의 클라이언트 사이드와 서버 사이드 보안과 차이점 > 바로가기

• 근본적으로 사용자의 장치에 도달하는 모든 데이터는 더 이상 안전하지 않습니다.
• 사용자가 접근해야 하는 데이터만 보낸다면 이것은 보안상 취약점이 아닙니다. 그러나 이런 필수적인 데이터는 앱이 정상적으로 작동할 수 있는 최소한의 조건이기도 합니다.

일반적으로 Bubble 앱 또는 웹 개발을 처음 하는 경우 이것이 무엇을 의미하는지 명확히 이해할 수 없으므로 이 글에서는 의도한 것보다 더 많은 데이터를 사용자와 공유하지 않기 위해 취해야 할 예방 조치들을 살펴보겠습니다.

 

• 예를 들어 페이지를 은행으로 가정한다면 앱의 데이터베이스는 안전금고실이라고 생각합니다.
• 사용자가 은행(페이지)에 접속하더라도 개인정보는 안전금고(데이터베이스)에 안전하게 보관되어 있으며 모두 잠겨 있습니다. (Privacy rule에 의해 보관)
• 침입자가 보는 모든 것은 오직 은행의 대기장소일 뿐입니다.

 

(2) Bubble의 JavaScript/JSON 파일

사용자가 앱에서 페이지를 로드할 때마다 브라우저는 JavaScript 및 JSON 파일 모음을 다운로드합니다.

• 그중 일부는 모든 Bubble 앱에 공통된 "엔진"을 구성하는 반면, 다른 일부는 특정 앱과 현재 로드된 페이지에 맞춤화된 코드와 데이터를 포함합니다.
• 이는 당신의 앱과 페이지를 다른 Bubble 앱의 다른 페이지와 차별화 되게 만드는 것들입니다.

 

이러한 파일에는 앱이 Bubble 서버와 통신하며 데이터와 명령을 주고받을 수 있도록 하는 코드가 포함되어 있습니다.

이러한 파일은 사용자의 장치에 저장되며 기술에 정통한 사용자(개발자일 경우)는 다운로드한 파일을 열고 코드를 볼 수 있습니다.

• 이는 그 자체로 취약점은 아니지만 Bubble 개발자로서 해당 코드에 어떤 종류의 데이터를 배치하는지 염두에 두어야 함을 의미합니다.

 

코드가 없는 플랫폼인 Bubble은 앱에 대한 코드를 자동으로 생성하므로 페이지에 저장한 정보에 주의하지 않으면 의도치 않게 취약점이 발생할 수 있습니다.

 

1. Option Set (옵션 세트)

• 옵션 세트는 앱의 어디에서나 참조할 수 있는 정적(static) 데이터를 저장하는 유용한 방법입니다.
• 옵션 세트는 나머지 앱 코드와 함께 다운로드되며 암호가 해독되어 사용자 기기에 일반 텍스트로 저장됩니다. 따라서 민감한 데이터를 옵션 세트에 배치해서는 안 됩니다. 여기에는 세트 자체의 이름, 다양한 옵션과 속성, 세트에 저장된 데이터가 포함됩니다.

 

2. App Text (번역되는 문자열)

• Settings > Language에 있는 App Text 기능은 사용자가 다른 언어로 앱을 볼 수 있도록 Static(정적) 텍스트 문자열을 번역하는 유용한 방법입니다.
• Bubble은 현재 사용자의 언어와 관련된 문자열을 다운로드합니다. 이러한 문자열은 안전한 것으로 간주되어서는 안 됩니다. 어떤 언어로든 App Text에 민감한 정보를 저장하지 마세요

 

3. Elements (요소들) - 특히 Placeholder

• 요소에 정적 데이터를 저장할 때마다 해당 데이터가 애플리케이션 코드의 일부가 된다고 가정해야 합니다. 예를 들어 Input 요소의 Placeholder에 텍스트를 넣어서 화면에 배치한다고 가정하면 해당 Placeholder의 텍스트는 앱 코드에 표시됩니다.
• 페이지 로드 시 숨겨진 정보라도 요소에 민감한 정보를 배치하지 마세요

 

4. 페이지 이름

Bubble은 페이지를 로드할 때마다 모든 페이지의 이름을 다운로드합니다.

• 즉, 사용자가 한 페이지만 로드하더라도 코드에는 여전히 다른 모든 페이지의 이름이 포함됩니다.
• 민감한 데이터가 포함된 페이지 이름을 지정하지 말고, 연결하지 않은 페이지가 안전하다고 가정하지 마세요. 사용자가 앱 코드를 보면 각 페이지의 이름을 식별할 수 있습니다.

보안에 매우 중요한 페이지의 이름을 일반적으로 사용되는 이름과 다른 페이지 이름으로 사용하는 것을 고려할 수도 있습니다.

• 예를 들어 admin 또는 login이라는 페이지는 개인정보와 밀접한 관련이 있는 페이지로 널리 사용되는 이름이라는 이유만으로 악의적 로봇의 침범 대상이 될 수 있습니다. 좀 더 흔하지 않은 이름을 사용하는 경우 표준 이름을 찾는 범죄에서 조금 더 피할 수 있는 조건이 될 수 있습니다.
• 이는 모호한 부분을 추가하는 거지만 완전한 독립형 앱의 보안 조치로 간주되어서는 안 된다고 생각하십시오

 

이런 조치는 반갑지 않은 방문자가 페이지를 찾는 것을 막지는 못하지만 약간 더 어렵게 만들 수 있습니다.

 

5. Workflow (워크플로우)

element와 마찬가지로 정적 데이터가 워크플로에 저장되면 Bubble 코드의 일부가 됩니다.

• 워크플로 결과가 처리될 때 일부 데이터가 사용자 장치로 전송되며, 이 정보는 해당 장치에서 접근할 수 있게 됩니다. 여기에는 워크플로 작동 중에 참조하는 element의 state 데이터가 포함됩니다. 이런 이유는 사용자의 반응에 대해서 element의 state 데이터를 클라이언트 장치에서 참조해야 되기 때문입니다.
• 또한 코드에는 워크플로의 작동 중 변경된 부분의 ID가 포함됩니다. 이러한 ID는 변경 사항이 브라우저에 즉시 표시되도록 하는 데 필요합니다.

일반적으로, 이러한 데이터 공유는 애플리케이션 기능의 일부이지만 서버와 클라이언트 간에 전달되는 정보는 보안상 주의해야 할 사항이기도 합니다.

 

6. 데이터 Type

모든 데이터 Type에 대한 다음 정보도 코드에 표시됩니다.

• 각 데이터 Type의 이름
• 모든 데이터 Type에 저장된 모든 필드의 이름
• Default data - 데이터 Type에 지정된 해당 필드의 기본값

데이터베이스에 저장되는 모든 데이터는 저장 중에 암호화됩니다.

 

7. API Connector Call (커넥터 호출)

API 커넥터를 사용하면 작업 및 데이터 소스로 사용할 다양한 호출을 설정할 수 있습니다.

 

앱 코드에는 다음 정보가 표시됩니다.

• 각 Call의 이름
• 비공개로 설정되지 않은 경우 각 Parameter(매개변수)의 key와 value
• [ ]를 사용하여 매개변수에 URL을 지정하지 않은 한 각 Call의 URL

 

8. 삭제된 데이터 필드, 데이터 Type, 옵션 Set 및 옵션 Set attributes

헤더에 지정된 항목 중 하나를 삭제하면 영구적으로 삭제되지는 않고 작업을 취소하려는 경우를 대비해 보관됩니다.

• Optimize Application 기능을 사용하면 삭제된 정보를 정리할 수 있습니다.

Optimize Application 기능에 액세스 하려면 Settings > General으로 이동하여 앱 최적화 버튼을 클릭하세요

Optimize Application

• Optimize Application 기능을 사용하면 삭제된 필드, 데이터 Type, 옵션 Set 및 attributes을 완전히 제거할 수 있습니다.

 

9. Conditions (조건식)

조건식은 사용하는 동적 표현식에 따라 클라이언트에서 직접 처리될 수도 있고 서버를 포함해야 할 수도 있습니다. 중요한 워크플로 이벤트나 작업에 조건식을 사용하는 경우 서버와 관련된 조건을 설정하는 것이 더 안전합니다. 그렇게 하면 사용자의 손이 닿지 않는 곳에서 처리가 수행됩니다.

• 조건식이 서버 측에서 처리되도록 하려면 데이터베이스 또는 사용자 인증과 관련된 모든 것을 포함할 수 있습니다.
• 예를 들어 현재 사용자가 로그인되어 있는지 여부 파악과 Do a search for:count > 0은 두 상황 모두 Bubble이 처리할 동작을 서버에서 처리하는 조건식입니다.

또한 조건식이 서버 측 작업에 배치되면 조건식과 작업이 모두 서버에서 처리됩니다.

• 서버에서 조건식을 처리할 수 없는 예외 경우도 있습니다. 예를 들어 요소 X가 표시되어야 하는 경우 클라리언트의 페이지에서 확인해야 하며 이로 인해 더 취약한 상태가 발생할 수 있습니다.

 

(3) Redirection (리디렉션)

사용자를 한 페이지에서 다른 페이지로 리디렉션 하는 방법은 두 가지가 있습니다.

 

1. Client side 리디렉션

• 사용자 브라우저에서 직접 발생합니다.
• 특정 조건이 충족되거나 이벤트 (예: 버튼 클릭)가 발생하고 Go to page  Action이 실행되면 사용자 브라우저에서 실행되는 스크립트가 현재 URL을 변경하여 브라우저가 새 페이지를 로드하게 합니다. 이는 서버와의 상호 작용 없이 발생합니다.

2. Server side 리디렉션

다른 페이지를 로드하도록 지시하는 브라우저의 요청에 서버가 응답할 때 발생합니다.

 

이 Action도 Go to page 하는 Action을 통해 수행되지만 다음 조건일 때만 수행됩니다.

• 페이지가 로드되기 전에 발생합니다.
• 아래 이벤트 중 하나가 리디렉션을 트리거합니다.
  • 사용자가 로그인되었습니다.
  • 사용자가 로그아웃되었습니다.
  • 페이지가 로드되었습니다.
• 워크플로에는 Action이 하나만 포함되어 있습니다.( Go to page Action )

 

서버 측 리디렉션은 클라이언트 측 리디렉션보다 더 안전합니다.

• 서버 측 리디렉션은 첫 번째 페이지의 데이터가 다운로드되기 전에 새 페이지로 리디렉션 되기 때문입니다.
• 반면에 클라이언트 측 리디렉션은 페이지가 로드된 후 브라우저에서 실행되는 JavaScript를 사용하여 리디렉션 됩니다.

모든 보안 페이지(예: 개인 프로필 수정 페이지)를 위한 서버 측 리디렉션을 보장해야 하지만 페이지의 모든 데이터와 workflow는 기본적으로 Privacy rule(개인 정보 보호 규칙) 및 Condition(조건식)에 따라 보호되어야 한다는 점을 명심하십시오

 

(4) 페이지 보안 요약

원칙적으로 사용자의 장치에 도달하는 모든 항목은 더 이상 암호화되지 않고 공개될 수 있으며 해당 장치에 일반 텍스트로 저장됩니다.

• 대부분의 사용자에게는 표시되지 않을 수 있지만 기술에 정통한 사용자(개발자)는 다운로드한 파일을 열고 네트워크를 통해 들어오고 나가는 데이터를 추적하여 해당 콘텐츠를 볼 수 있습니다.

이것이 페이지 보안이 중요시되는 이유입니다.

 

• 비공개인 모든 데이터 유형 및 필드에 대한 개인정보 보호 규칙을 설정하세요
• 요소, 이벤트, Action 또는 조건식에 개인 정보 및 API 키와 같은 민감한 데이터를 저장하지 마십시오
• 사용자가 접근할 수 없는 페이지에서 사용자를 안내하도록 서버 측 리디렉션을 설정하세요