Following His Step

나 : 메모리 덤프를 통해서 브라우저 단의 정보를 탈취해 가는 것을 막으려면 

어떤 보안조치를 해야할까?

ChatGPT : 메모리 덤프는 악성 코드가 실행 중인 프로세스의 메모리를 검색하여 중요 정보를 탈취하는 데 사용되는 기술입니다. 따라서 브라우저 단에서 메모리 덤프를 막으려면 다음과 같은 보안조치를 취할 수 있습니다.

취약점 패치: 브라우저 취약점을 해결하는 패치를 적용하여 메모리 덤프를 방지할 수 있습니다. 브라우저 공급 업체는 취약점을 신속하게 패치하고 최신 버전으로 업데이트하도록 권장됩니다.

보안 설정 강화: 브라우저 보안 설정을 강화하여 악성 코드가 실행되는 것을 방지할 수 있습니다. 이는 인터넷 보안 소프트웨어를 사용하여 공격을 탐지하고 차단하는 것과 같은 방법으로 이루어질 수 있습니다.

데이터 암호화: 브라우저에서 중요한 정보를 보호하기 위해 데이터 암호화를 구현할 수 있습니다. 이를 위해서는 SSL/TLS 프로토콜을 사용하여 데이터를 암호화하고 HTTPS를 사용하여 웹 사이트 연결을 보호해야 합니다.

메모리 보호: 브라우저는 메모리 보호 기술을 사용하여 실행 중인 코드가 다른 프로세스의 메모리를 읽거나 쓸 수 없도록 할 수 있습니다. 이를 위해서는 예를 들어 ASLR(Address Space Layout Randomization)과 같은 기술을 사용하여 메모리 주소를 무작위로 할당하고, 실행 파일에 대한 메모리 보호 기능을 활성화해야 합니다.

보안 인증서 검증: 브라우저는 SSL 인증서의 유효성을 검증하여 악성 인증서를 사용하는 웹 사이트에서의 연결을 방지할 수 있습니다. 이를 위해서는 인증서 검증 기능을 활성화해야 합니다.

보안 소프트웨어 설치: 인터넷 보안 소프트웨어를 설치하여 브라우저를 보호할 수 있습니다. 이러한 소프트웨어는 악성 코드를 탐지하고 차단하여 브라우저에서 발생하는 보안 위협을 줄일 수 있습니다.

이러한 보안조치를 적용하여 브라우저 단의 정보를 탈취하는 메모리 덤프를 방지할 수 있습니다. 그러나 보안은 끝이 없기 때문에, 완벽하다고 보장할 수는 없습니다.




나 : SSL 암호화 만으로는 메모리 덤프 될 때 탈취되는 정보를 지킬 수 없는 거 아니니?

ChatGPT : 맞습니다. SSL 암호화는 데이터를 안전하게 전송하는 데에 도움을 주지만, 메모리 덤프를 통해 브라우저에서 실행 중인 애플리케이션의 정보가 노출될 가능성이 있습니다. 이러한 공격은 SSL 암호화가 강력하게 적용되더라도 메모리 덤프를 통해 정보를 탈취할 수 있는 것으로 알려져 있습니다.

따라서 메모리 덤프를 방지하기 위해서는 SSL 암호화 외에도 다른 보안조치를 취해야 합니다. 먼저, 애플리케이션에서 중요한 정보를 저장하는 변수를 암호화하여 보호할 수 있습니다. 또한, 메모리 보호 기술을 사용하여 메모리 덤프를 차단하고, 인증서 검증, 보안 소프트웨어 설치 등 다양한 보안조치를 함께 적용하여 보안을 강화할 수 있습니다.

또한, 애플리케이션 내에서 중요한 정보를 최소한으로 유지하고, 처리가 완료되면 즉시 메모리에서 삭제하도록 구현함으로써 정보 노출을 최소화할 수도 있습니다. 이러한 방법들은 SSL 암호화 외에도 보안성을 향상시키고, 메모리 덤프에 대한 위협을 줄일 수 있는 방법입니다.

OWASP TOP 10 이 웹보안에서 왜 중요할까?

OWASP TOP 10은 웹 어플리케이션 보안 위협의 10가지 가장 일반적인 유형을 나열하고, 이를 방지하기 위한 대처 방안을 제공하는 프로젝트입니다. 이는 웹 어플리케이션 보안에서 매우 중요합니다.

첫째로, OWASP TOP 10은 개발자, 보안 전문가 및 비즈니스 리더 등 웹 어플리케이션 보안과 관련된 모든 이해관계자들에게 가장 중요한 보안 위협에 대한 인식과 이해를 제공합니다.

둘째로, OWASP TOP 10은 웹 어플리케이션 개발 및 보안 테스트에서 가장 일반적으로 발생하는 보안 위협을 식별할 수 있는 기준을 제공합니다. 이러한 기준을 사용하여 개발자와 보안 전문가는 보다 전문적이고 체계적인 보안 테스트를 수행할 수 있으며, 이를 통해 보안 위협을 방지하고 해결할 수 있습니다.

셋째로, OWASP TOP 10은 비즈니스 리더 및 의사 결정자들에게 웹 어플리케이션 보안을 강화하기 위한 가이드라인을 제공합니다. 이러한 가이드라인을 따르면 비즈니스는 웹 어플리케이션 보안을 향상시키는 데 필요한 자원 및 예산을 할당하고, 보안 위협을 방지하고 대응할 수 있는 전략을 수립할 수 있습니다.

따라서, OWASP TOP 10은 웹 어플리케이션 보안을 강화하고 보안 위협을 방지하는 데 매우 중요한 역할을 합니다.

OWASP TOP 10의 정의? 

OWASP TOP 10은 웹 어플리케이션 보안 위협의 10가지 가장 일반적인 유형을 나열하고, 이를 방지하기 위한 대처 방안을 제공하는 프로젝트입니다. OWASP는 Open Web Application Security Project의 약어로서, 웹 어플리케이션 보안에 대한 지식을 공유하고 보안 문제를 해결하기 위한 세계적인 비영리 단체입니다.

OWASP TOP 10은 전 세계적으로 가장 많이 인용되는 웹 어플리케이션 보안 위협 리스트 중 하나입니다. 이 프로젝트는 보안 전문가, 개발자, 비즈니스 리더 등 웹 어플리케이션 보안과 관련된 모든 이해관계자들에게 가장 중요한 보안 위협에 대한 인식과 이해를 제공하며, 개발자 및 보안 전문가가 웹 어플리케이션 보안을 향상시키기 위한 대처 방안을 제시합니다.

OWASP TOP 10은 다음과 같은 10가지 웹 어플리케이션 보안 위협을 포함합니다.

1.인증 및 세션 관리의 부적절한 구현
2.민감한 데이터 노출
3.취약한 대규모 업로드 기능
4.보안 설정 오류
5.악의적인 코드 삽입 (injection)
6.취약한 외부 자원 사용
7.인증되지 않은 접근 제어
8.취약한 데이터 보호
9.부적절한 로깅 및 모니터링
10.보안 결함 처리 부재

이러한 위협은 웹 어플리케이션 보안을 강화하고 보안 위협을 방지하는 데 매우 중요합니다.

OWASP TOP 10의 구체적인 사례는 뭐가 있을까? 

1. 인증 및 세션 관리의 부적절한 구현:
· 예를 들어, 웹사이트 로그인 시 사용자가 제출한 비밀번호를 안전하게 처리하지 않거나, 세션 관리를 제대로 수행하지 않아 인증이 필요하지 않은 페이지에 액세스할 수 있도록 하는 경우가 있습니다.

2. 민감한 데이터 노출:
· 예를 들어, 웹사이트에서 사용자의 개인정보나 결제 정보를 보호하지 않고 노출시키는 경우가 있습니다. 이는 악의적인 사용자가 이 정보를 탈취하여 부정한 목적으로 사용할 수 있습니다.

3. 취약한 대규모 업로드 기능:
· 예를 들어, 웹사이트에 파일 업로드 기능이 있는 경우, 사용자가 업로드하는 파일에 대한 검증 절차가 부족하면 악성 코드가 포함된 파일을 업로드할 수 있습니다.

4. 보안 설정 오류:
· 예를 들어, 웹사이트에서 보안 설정이 부적절하게 구성되어 있는 경우, 악성 코드가 삽입되거나 사용자가 액세스하지 않아야 할 기밀 정보가 노출될 수 있습니다.

5. 악의적인 코드 삽입 (injection):
· 예를 들어, SQL injection 공격을 통해 웹사이트 데이터베이스에 액세스하여 사용자 정보를 탈취하는 경우가 있습니다.

6. 취약한 외부 자원 사용:
· 예를 들어, 웹사이트에서 외부 API를 사용할 때, API의 보안 취약점으로 인해 사용자 정보가 유출되거나 웹사이트가 망가질 수 있습니다.

7. 인증되지 않은 접근 제어:
· 예를 들어, 사용자가 로그인하지 않아도 액세스할 수 있는 페이지가 있는 경우, 악의적인 사용자가 민감한 정보에 액세스할 수 있습니다.

8. 취약한 데이터 보호:
· 예를 들어, 웹사이트에서 저장하는 사용자 정보를 암호화하지 않은 경우, 악의적인 사용자가 이 정보를 탈취하여 부정한 목적으로 사용할 수 있습니다.

9. 부적절한 로깅 및 모니터링:
· 예를 들어, 웹사이트에서 로깅 및 모니터링이 부적절하게 설정되어 있으면, 보안 사고 발생 시 이를 탐지하지 못하거나 대처하지 못할 수 있습니다.

10. 보안 결함 처리 부재:
예를 들어, 웹사이트에서 보안 취약점이 발견되었을 때, 이를 적절하게 처리하지 않으면 악의적인 사용자가 취약점을 이용하여 웹사이트를 공격하거나 사용자 정보를 탈취할 수 있습니다. 이를 예방하기 위해 취약점을 신속하게 수정하고 보안 업데이트를 수행해야 합니다. 보안 결함 처리 부재는 다른 위협들의 발생 원인이 될 수 있으며, OWASP TOP 10에서 가장 중요한 위협 중 하나입니다.

다음 번에는 보다 구체적인 이야기로 OWASP TOP 10을 분석해보겠습니다.

TLS 암호화를 써도 메모리덤프 등으로 조회하면 다 노출이 되는 리스크가 있는걸까?

TLS는 데이터를 전송하는 동안 암호화를 제공하여 데이터를 안전하게 전송하는 프로토콜입니다. TLS를 사용하면 데이터가 암호화되므로 네트워크상에서 중간에 가로채어도 알아볼 수 없습니다. 그러나 TLS는 데이터가 메모리에 저장될 때는 암호화되지 않으며, 이 때 메모리 덤프가 있을 경우 데이터가 노출될 가능성이 있습니다.

메모리 덤프란 프로그램이 실행되는 동안 시스템 메모리에 저장된 내용을 파일로 저장하는 것입니다. 메모리 덤프를 수행하는 공격자가 있을 경우, TLS로 보호되는 데이터가 메모리에 저장될 때는 암호화되지 않으므로, 공격자가 해당 파일을 열어보면 데이터가 노출될 가능성이 있습니다.

그러나 이는 TLS 프로토콜 자체의 문제가 아니라 시스템 보안의 문제입니다. TLS를 사용할 경우, 데이터를 전송하는 동안에는 안전하게 암호화되므로 중간에서 데이터를 가로채더라도 알아볼 수 없습니다. 따라서 시스템 보안을 강화하여 메모리 덤프 등의 공격을 방어하는 것이 중요합니다. 예를 들어, 메모리 덤프를 방지하는 솔루션이나, 메모리 상에 저장된 데이터를 암호화하는 솔루션 등을 적용할 수 있습니다.

여기서 메모리덤프는 어떤 컴퓨터의 메모리를 이야기하는 걸까?

메모리 덤프(memory dump)는 컴퓨터의 물리적 메모리(RAM)에 저장된 내용을 파일로 덤프하는 것을 말합니다. 즉, 프로그램이나 운영체제 등이 메모리에 올린 데이터나 코드, 변수 등이 파일 형태로 저장되는 것입니다.

메모리 덤프는 보안 전문가나 해커 등이 시스템의 보안 취약점을 분석하거나, 디버깅을 위해 사용되기도 합니다. 하지만 악의적인 목적으로 사용될 경우, 메모리 덤프를 통해 시스템에서 중요한 정보를 탈취하는 등의 공격이 이루어질 수 있습니다. 따라서 시스템 보안을 강화하는 것이 중요합니다.

모바일에서 웹서비스로 https 로 통신되는 서비스를 이용하는 경우에, 메모리 덤프로 이용자의 데이터가 노출될 수 있을까?

모바일에서 웹 서비스로 HTTPS를 통해 통신하는 경우, 데이터는 암호화되어 전송되므로 중간에 가로채어도 데이터를 복호화하지 않으면 의미가 없습니다. 따라서 HTTPS를 사용하는 경우, 중간에 데이터를 가로채더라도 데이터가 노출될 가능성은 매우 적습니다.

그러나 메모리 덤프 공격을 받을 경우, 앱의 메모리에 저장된 데이터가 노출될 가능성이 있습니다. 메모리 덤프 공격은 모바일 앱에서도 가능하며, 메모리 덤프 파일을 수집한 공격자는 해당 파일을 분석하여 중요한 정보를 추출할 수 있습니다.

따라서 모바일 앱에서도 HTTPS를 사용하여 데이터를 암호화하고, 민감한 정보는 메모리에 저장하지 않는 것이 좋습니다. 또한, 모바일 앱에서는 안드로이드나 iOS와 같은 운영체제에서 제공하는 보안 기능을 이용하여 메모리 덤프 공격을 방어할 수 있습니다. 더불어, 적절한 취약점 분석과 보안 검토를 통해 앱 보안을 강화하는 것이 필요합니다.

웹서비스를 이용하는 모바일기기의 메모리덤프 공격을 하려면 어떤 권한을 획득해야 가능할가?

웹서비스를 이용하는 모바일 기기의 메모리 덤프 공격을 하기 위해서는 보통 해당 모바일 앱의 권한을 획득해야 합니다. 따라서, 공격자는 해당 앱의 취약점을 이용하여 권한 상승을 시도하거나, 앱을 해킹하여 권한을 획득해야 할 수 있습니다.

일반적으로 안드로이드 기기에서는 권한을 획득하기 위해서는 앱에게 권한을 요청하고, 사용자가 권한을 허용해야 합니다. 그러나, 모바일 앱에 취약점이 있을 경우, 공격자는 해당 취약점을 이용하여 권한을 상승시키는 방법을 시도할 수 있습니다.

또한, iOS 기기에서도 취약점을 이용하여 권한을 상승시키는 방법이 있을 수 있습니다. 예를 들어, iOS의 경우 앱 간 공유 컴포넌트를 이용하여 다른 앱의 권한을 이용할 수 있는 취약점이 발견된 적이 있습니다.

따라서, 모바일 앱 개발자는 모바일 앱 보안을 강화하는 것이 중요하며, 앱에 취약점이 있는지 주기적으로 검토하여 보안 취약점을 최소화하는 것이 필요합니다.

단말기를 획득하고, 
획득한 단말기의 권한(루팅, 탈옥)을 획득하고, 
메모리 덤프를 뜨게 되면,
취약점이 있는 앱서비스, 웹서비스 등을 사용했다면,
해당 유저의 중요 개인 정보들은 모두 노출이 되게 된다. 

다음번에는 웹취약점의 가장 기본, OWASP TOP 10에 대해서도 알아보겠습니다 ! :) 

As a provider of SaaS solutions in the form of web services, I often receive various security-related questions while addressing my clients' security issues. Through this process, I have gained experience in growing by finding ways to provide a safer service.

I would like to organize these experiences around questions and share them.

Does WebRTC require SSL (Secure Socket Layers) to be enabled for integration?

WebRTC is designed to be used only on HTTPS for security reasons. Therefore, WebRTC will not be activated in an HTTP environment without an SSL certificate.

For security, WebRTC uses SRTP (Secure Real-time Transport Protocol) by default and uses DTLS (Datagram Transport Layer Security) for data exchange. Since these security technologies cannot work without an SSL certificate, WebRTC cannot be used in an HTTP environment without an SSL certificate.

Therefore, to use WebRTC, you need to configure an HTTPS environment with an SSL certificate. To do this, you need to obtain an SSL certificate and apply the HTTPS protocol. You can use services such as Let's Encrypt, which provides free SSL certificates, to do this.

What are the differences between HTTPS, SSL, and TLS?

HTTPS is a secure protocol that secures the HTTP protocol, while SSL and TLS are protocols used in HTTPS.

SSL (Secure Sockets Layer) was initially developed by Netscape, while TLS (Transport Layer Security) was developed by IETF (Internet Engineering Task Force) as an improved version of SSL. Therefore, TLS can be considered as a successor to SSL.

SSL and TLS mainly use public-key encryption to protect data in network communications. In communication between clients and servers, SSL/TLS uses certificates to verify the identity of the other party and encrypts data to transmit it safely.

The differences between SSL and TLS include encryption methods, certificate formats, protocol versions, and others, but the basic principles are the same.

SSL has vulnerabilities and is currently not recommended for use, while TLS is constantly being upgraded. Currently, TLS 1.3 is the latest version.

I will cover deeper aspects in the next opportunity.

SaaS 솔루션을 웹서비스 형태로 제공해주다보니 다양한 보안 관련 질문들을 받게 됩니다. 
고객사의 보안 이슈를 응대하며 다양한 질문들을 접합니다.

그러면서 어떻게 하면 보다 안전한 서비스를 제공할 수 있을지, 

하나씩 성장해 가는 것을 경험해 왔습니다.

그러한 이야기들을 질문들을 중심으로 하나씩 정리해 가보려고 합니다.

webRTC 연동시에 SSL(Secure Socket Layers) 안쓰면 활성화가 안되나요?

오늘 받은 따끈따끈한 질문입니다.

WebRTC는 보안 상의 이유로 HTTPS에서만 사용 가능하도록 설계되어 있습니다. 따라서 SSL 인증서가 없는 HTTP 환경에서는 WebRTC가 활성화되지 않습니다.

WebRTC는 보안을 위해 기본적으로 SRTP (Secure Real-time Transport Protocol)를 사용하며, 데이터 교환에 DTLS (Datagram Transport Layer Security)를 사용합니다. 이러한 보안 기술은 SSL 인증서 없이는 작동할 수 없기 때문에, SSL 인증서가 없는 HTTP 환경에서는 WebRTC를 사용할 수 없습니다.

따라서, WebRTC를 사용하려면 SSL 인증서가 있는 HTTPS 환경을 구성해야 합니다. 이를 위해서는 SSL 인증서를 발급받아 HTTPS 프로토콜을 적용해야 합니다. 이를 위해 무료로 SSL 인증서를 발급받을 수 있는 Let's Encrypt 등의 서비스를 이용할 수 있습니다.

추가 관련 질문 (참고지식)

https SSL TLS 차이점은?

HTTPS는 HTTP 프로토콜을 보안한 프로토콜이며, SSL과 TLS는 HTTPS에서 사용되는 프로토콜입니다.

SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)은 모두 네트워크 통신에서 보안을 제공하기 위한 프로토콜입니다.

SSL은 처음에 넷스케이프에서 개발되었고, TLS는 SSL의 개선 버전으로, IETF(Internet Engineering Task Force)에서 개발되었습니다. 따라서 TLS는 SSL의 후속 버전이라고 할 수 있습니다.

SSL과 TLS는 주로 공개키 암호화 방식을 사용하여 데이터를 보호합니다. 클라이언트와 서버 사이의 통신에서 SSL/TLS는 인증서를 사용하여 상대방의 신원을 확인하고, 데이터를 암호화하여 안전하게 전송합니다.

차이점으로는 SSL과 TLS는 암호화 방식, 인증서 형식, 프로토콜 버전 등이 다르지만, 기본적인 원리는 동일합니다.

SSL은 취약점이 발견되어 현재는 사용이 권장되지 않으며,

TLS는 지속적으로 업그레이드가 이루어지고 있습니다. 현재 TLS 1.3이 가장 최신 버전입니다.

더 딥한 부분들은 다음 기회에 올려보겠습니다 :)