Windows 스토어 앱용 플랫폼을 개발하는 데 있어 주요 목표 중 하나는 고객이 신뢰할 수 있는 앱 경험을 제공하는 것이었습니다. 고객에게 앱이 기대한 대로 작동하고, 다른 앱과 연동되며, 깔끔하게 제거된다는 신뢰감을 주어야 합니다. Windows 스토어 등록부터 원활한 앱 설치 및 제거, 개발자의 위치 및 웹캠을 사용해도 좋다는 동의, 앱이 Windows 스토어 제출 기준을 만족하는지 테스트하기 위한 Windows 앱 인증 키트까지 다양한 수단을 통해 이러한 신뢰감을 줄 수 있습니다. 고객의 신뢰는 특정 기능, 프로세스 또는 품질에서 나오는 것이 아닙니다. 고객이 다양한 부분을 살펴보고 전체 프로세스를 신뢰할 수 있을 때 비로소 고객의 신뢰를 얻을 수 있습니다. 이에 대한 접근 방법은 안정적이고 신뢰할 수 있는 앱 개발블로그 글에서 자세히 설명했습니다.
오늘은 안전한 앱, 그리고 고객에게 앱에 대한 신뢰감을 주는 방법에 대해 구체적인 이야기를 나누겠습니다. 요즘에는 금융 정보부터 개인 사진까지 중요한 고객 데이터를 보관하는 앱이 상당히 많습니다. 어떤 고객들은 이러한 데이터를 생계 수단으로 이용하며 앱에서 이 데이터를 안전하게 보호할 것이라고 기대합니다. 최소한의 데이터만 저장하는 앱이라 할지라도 고객은 앱이 설계대로 작동하며 다른 앱과 충돌하지 않을 것으로 기대합니다.
시간이 지나도 고객에게 신뢰와 즐거움을 줄 수 있는 앱을 구축하려면 앱에 보안 모범 사례를 구현하는 것이 필수입니다. 다행히도 일반적인 보안 모범 사례는 구현이 간단하며 앱에 보안 기능을 추가하기가 어렵지 않습니다. 또한 앱 컨테이너와 앱 컨테이너의 데이터가 다른 앱으로부터 분리되도록 하는 고유한 앱 컨테이너에서 앱이 작동합니다. 앱 컨테이너는 데이터와 설정을 위한 여러분 자신의 스토어 같은 앱 전용 환경을 제공합니다.
Windows 8 및 Visual Studio 2012는 앱의 취약점을 최소화하고 일반적인 보안 문제를 완화하는 API, 컨트롤 및 도구 모음을 제공합니다. 어떤 플랫폼도 완벽할 수는 없겠지만 여러 요소를 조합하여 사용한다면 뛰어난 앱을 구축할 수 있으며 시간이 지날수록 플랫폼도 차츰 개선될 것입니다. 이 글에서는 고객에게 보다 안전한 경험을 제공할 수 있도록 앱 기능을 강화하는 다양한 팁과 모범 사례를 다룰 것입니다.
그럼 이제 시작해 보겠습니다.
팁 1 – Visual Studio를 사용하여 컴파일
우리는 Windows 8부터 개발자가 Visual Studio 2012를 사용하여 앱을 컴파일하기만 하면 되는 다양한 보안 모범 사례를 기본적으로 제공해 왔습니다. 이제부터 Visual Studio 2012를 사용하여 컴파일하면 일반 공격 (/GS, ASLR, DEP및 SeHOP)으로부터 앱을 보호하는 보안 기술이 앱 내의 네이티브 코드에 기본적으로 적용됩니다.
팁 2 – 앱 기능 최소화
각 앱은 다른 리소스 및 장치와 상호 작용하는 방식을 정의하는 기능을 선언할 수 있습니다. 앱이 필요한 최소의 권한만 갖고 실행되도록 앱에 필요한 기능을 최소로 정의하는 것이 중요합니다. 최소의 기능만 사용할 경우 앱이 취약점 공격에 덜 노출됩니다.
예를 들어 홈 또는 회사 네트워크 기능은앱이 P2P 게임 같은 로컬 네트워크의 컴퓨터에 액세스할 수 있도록 허용합니다. 이 기능은 로컬 서비스를 통한 시험판 테스트에도 유용하지만 불필요한 경우가 많고 카페나 공항의 무선 액세스 지점처럼 신뢰할 수 없는 로컬 네트워크를 통한 공격에 노출될 수 있습니다. 원격 서버 테스트를 위한 기능은 제거하도록 하십시오. 현실 세계의 조건을 복제하여 앱에 사용할 수 있는 추가적인 이점이 있습니다. 홈 또는 회사 네트워크기능을 사용하는 경우 앱을 제출하기 전에 이 기능을 제거해야만 스토어 인증을 받을 수 있습니다.
최소 기능만 사용한 앱 – 인터넷 액세스만 가능
엔터프라이즈 인증, 공유 사용자 인증서 및 문서 라이브러리 기능은 엔터프라이즈 액세스와 포함된 문서(예: 한 문서를 열려면 그 안에 있는 다른 문서를 열어야 함)를 위해 설계되었으며, 이 기능이 포함된 앱을 Windows 스토어에 제출하려면 회사 계정이 필요합니다. 대부분의 앱에는 이러한 기능이 필요 없지만 회사 리소스에 액세스해야 하는 기업 앱에는 필요합니다. 이러한 기능의 사용은 상당히 제한적이며, 사용하려면 추가적인 Windows 스토어 검토가 필요합니다.
팁 3 – 라이브러리 기능 대신 파일 선택기 사용
팁 2에 추가로 파일 기반 기능을 함께 제거하면 기능을 더욱 최소화할 수 있습니다. 앱이 몇 개 파일에만 액세스하면 되는 경우 파일 선택기를 사용하여 사용자가 파일을 선택하도록 합니다. 파일 선택기를 사용하면 앱 코드가 간단해지고 사용자는 추가적인 앱 기능 없이도 간편하게 필요한 파일에 액세스할 수 있습니다. 파일 선택기는 모든 앱에서 동일하기 때문에 사용자가 앱을 처음 사용하더라도 대화 상자에 금방 익숙해져서 필요한 파일을 선택한 후 신속하게 앱으로 돌아갈 수 있습니다.
사진 라이브러리를 보여 주는 파일 선택기
JavaScript의 경우
var picker = new Windows.Storage.Pickers.FileOpenPicker();
openPicker.viewMode = Windows.Storage.Pickers.PickerViewMode.thumbnail;
picker.fileTypeFilter.replaceAll([".png", ".jpg", ".jpeg"]);
picker.suggestedStartLocation =
Windows.Storage.Pickers.PickerLocationId.picturesLibrary;
C#의 경우
using Windows.Storage;
using Windows.Storage.Pickers;
FileOpenPicker openPicker = new FileOpenPicker();
openPicker.ViewMode = PickerViewMode.Thumbnail;
openPicker.SuggestedStartLocation = PickerLocationId.PicturesLibrary;
openPicker.FileTypeFilter.Add(".png");
openPicker.FileTypeFilter.Add(".jpg");
openPicker.FileTypeFilter.Add(".jpeg");
적절한 기능의 예를 들자면, 앱에서 사용자가 사진을 선택할 수 있도록 하는 경우 사진 라이브러리 기능 대신 파일 선택기를 사용해야 합니다. 음악 라이브러리의 콘텐츠를 재생하는 뮤직 플레이어처럼 라이브러리에 완전한 프로그래밍 방식 액세스가 필요한 앱의 경우 특정 기능을 사용하여 음악 라이브러리에 액세스하는 것이 합리적입니다. 앱에서 문서에 액세스해야 하는 경우 언제나 파일 선택기를 사용해야 합니다.
팁 4 – 원격 데이터는 믿지 말 것
JavaScript로 작성된 앱의 경우 신뢰할 수 없는 웹 콘텐츠를 확인하고 신중하게 처리하는 것이 매우 중요합니다. 앱과 함께 포함된 HTML 페이지는 일반적으로 앱의 로컬 컨텍스트에서 실행되기 때문에 Windows 런타임에 액세스가 가능합니다. iframe 내에 표시된 원격 페이지는 앱의 웹 컨텍스트에서 실행되며 Windows 런타임에 대한 액세스 권한이 없습니다. 앱 내에서 누가 Windows 런타임을 호출하는지 알아야 합니다. 알 수 없는 인터넷 사이트가 여러분의 앱을 제어하는 것을 바라는 분은 없겠죠? 이것은 좋은 생각이 아닙니다. API 입력이 여러분의 패키지에서 실행된 것임을 알 수 없는 경우에는 앱에서 eval(), setTimeout(), setInterval() 등의 스크립트를 실행하는 API를 호출할 수 없어야 합니다. 이러한 API를 사용해야 한다면 API가 스크립트를 평가할 수 있다는 것을 명심하고 데이터를 이러한 API로 전달할 때 스크립트가 정확하게 어떻게 구성되는지 알아야 합니다.
JSON 데이터로 작업할 경우 eval() 대신 JSON.parse를 사용해야 합니다. 훨씬 안전하고 앱이 스크립트 삽입에 노출될 위험도 없습니다.
JavaScript의 경우
var jsontext = '{"firstname":"Aaren","surname":"Ekelund"}';
var contact = JSON.parse(jsontext);
console.log(contact.surname + ", " + contact.firstname);
// Output: Ekelund, Aaren
마지막으로, innerText또는 toStaticHTML을 사용하여 앱 내에서 사용되는 알 수 없는 웹 콘텐츠를 삭제하고 실행 가능한 콘텐츠를 제거해야 합니다 이 삭제 프로세스는 앱 내에서 웹 콘텐츠를 표시하는 스크립트를 제거하거나 비활성화합니다.
JavaScript의 경우
div.innerHTML = window.toStaticHTML(data);
div.innerText = data;
이 기능은 신뢰할 수 없는 스크립트나 위험한 콘텐츠가 앱 내에서 실행되지 않게 합니다. 첫 번째 예는 스크립트를 제거하고 두 번째 예는 스크립트를 실행되지 않는 텍스트로 전환합니다. 대부분의 앱은 앱 내의 입력 필드와 XMLHttpRequest개체 같은 기존 API를 통해 원격 웹 콘텐츠에 액세스하겠지만 공유 참등의 기타 경로를 통해 웹 콘텐츠가 들어올 수도 있다는 사실을 기억해야 합니다.
팁 5 – 웹에서 WinRT에 액세스할 수 없도록 제한
기본적으로 Windows 8은 앱 패키지의 콘텐츠만 Windows 런타임(WinRT)에 액세스할 수 있도록 허용합니다. 앱에서 웹의 입력 또는 데이터를 허용할 경우 데이터가 앱의 WinRT API 사용을 제어할 수 없도록 해야 합니다. 고객은 앱이 예상대로 작동하기를 원하며 개발자가 이러한 기대를 져버리지 않을 것으로 생각합니다. 웹 사이트 작업을 하는 중이라면 샌드박스가 적용된 iframe내에 사이트를 표시해 보십시오. 스크립트, 양식 제출 및 기타 콘텐츠가 앱에서 실행되는 것을 방지할 수 있습니다.
앱에서 웹 콘텐츠를 실행할 경우 해당 콘텐츠는 앱의 설정 및 데이터 또는 앱이 액세스할 수 있는 파일에 액세스할 수 있습니다. JavaScript로 작성된 앱의 경우 이것이 특히 중요합니다. 스크립트를 즉각적으로 실행하는 것이 훨씬 간단하기 때문입니다. 예를 들어 JavaScript로 앱을 작성했는데 이 앱이 postMessage를 사용하여 데이터를 WinRT API 또는 패키지화된 코드로 전달하는 경우 데이터가 신뢰할 수 있는 출처에서 온 것인지 확인해야 합니다.
JavaScript의 경우
window.attachEvent('onmessage',function(e) {
if (e.origin == 'https://www.contoso.com/') {
…
}
});
JavaScript로 작성된 앱에 웹 콘텐츠를 추가하는 방법에 대한 자세한 내용은 웹 서비스의 콘텐츠 및 컨트롤 통합에 대한 앱 샘플을 참조하십시오.
팁 6 – 증거 확보: 앱 및 고객 인증
앱의 일부가 클라우드 서비스에 액세스할 수 있는 클라우드 기반 앱은 매우 강력하지만 오용을 방지할 수 있도록 클라우드 서비스 인증에 신중을 기해야 합니다. 사용자 입력을 허용하는 클라우드 서비스는 언제나 사용자와 앱을 전부 확인하고 인증해야 합니다. 신뢰할 수 있는 클라우드 서비스를 통해 앱과 사용자를 인증하면 합법적인 사용자가 적절한 앱을 통해 여러분의 서비스를 이용한다는 것을 알 수 있습니다. 사용자 ID를 알 수 있을 때 얻게 되는 또 다른 이점으로, 오용이 발생하더라도 간단하게 해당 사용자의 ID를 확인하여 그 사용자가 게시한 모든 콘텐츠를 제거할 수 있습니다.
GetAppReceiptAsync를 사용하여 앱을 인증하면 앱이 스토어에서 얻은 것이고 유효한 스토어 영수증이 있는지 확인할 수 있습니다. 백 엔드 서버가 있다면 아래 URL에 연결하여 영수증 서명의 공용 인증서를 확인하는 추가 인증이 가능합니다. 아래 URL에서 <CertificateId>는 영수증에 포함된 CertificateId입니다.
https://go.microsoft.com/fwlink/p/?LinkId=246509&cid=<CertificateId>
WinRT는 OAuth 스타일 인증에 사용되는 웹 인증 브로커, 암호 및 소량의 암호화된 값을 저장하는 데 사용되는 자격 증명 보관, 클라이언트 인증서 인증에 사용되는 공유 인증서 저장소등을 포함하여 클라이언트 앱에서 클라우드 서비스 사용자를 인증할 수 있는 여러 가지 편리한 방법을 제공합니다. 어떤 방법을 사용하든 인증 및 자격 증명을 처리하는 방식에 대해 고객에게 신뢰감을 줄 수 있는 좋은 방법입니다.
팁 7 – 파일, 프로토콜 및 가져온 데이터 검사
대부분의 앱은 파일을 생성 및 로드한 후, 프로토콜을 통해 정품 인증을 하거나 아니면 데이터를 가져올 수 있는 방법을 제공합니다. 위에서 설명한 원격 웹 콘텐츠와 마찬가지로, 이 데이터가 잘못되었거나 신뢰할 수 없는 출처에서 온 것일 수도 있기 때문에 신뢰하면 안 됩니다. 파일을 열고, 데이터를 가져오고, 공유 콘텐츠를 허용하는 앱은 이러한 작업을 수행하기 전에 콘텐츠를 검사해야 합니다.
유효성 검사는 입력 유형 및 앱이 콘텐츠를 실행하는 방식에 따라 달라지며 간단할 수도 있고 복잡할 수도 있습니다. 예를 들어 일반적으로 데이터베이스는 수신하는 모든 유효한 쿼리를 실행하며 악의적인 입력을 통해 데이터를 공개, 조작, 심지어 삭제할 수 있기 때문에 데이터베이스 쿼리에서 사용하는 입력을 검사하여 SQL 삽입 공격을 방지해야 합니다.
파일, 프로토콜, 가져온 데이터 및 공유 콘텐츠에 앱에서 실행되면 안 되는 신뢰할 수 없는 콘텐츠가 포함될 수 있습니다. 신뢰할 수 없는 입력의 가장 일반적인 형태는 파일과 프로토콜이지만 고객이 웹 브라우저에서 무엇이 될지 모르는 신뢰할 수 없는 콘텐츠를 가져올 수 있기 때문에 클립보드에도 주의해야 하고 공유 참에서 콘텐츠를 허용할 때에도 주의해야 합니다. 개인용 금융 앱처럼 매우 중요한 데이터가 저장되는 앱은 고객의 귀중한 정보에 대한 액세스 권한을 갖고 있기 때문에 신뢰할 수 없는 콘텐츠를 매우 신중하게 처리해야 합니다.
팁 8 – HTTPS 연결 사용
의심스러운 경우 암호화 HTTPS 연결을 사용하면 원격 서버에 대한 인증이 가능하고 man-in-the-middle 공격을 방지하는 데에도 매우 좋습니다. 홈 네트워크에서는 이러한 공격이 문제가 되지 않을 수도 있지만 아직은 전 세계적으로 표준 HTTP 연결이 안전하지 않은, 암호화되지 않는 무선 네트워크가 많이 있습니다.
표준 HTTPS 연결의 경우 원격 웹 사이트는 CA에서 제공한 인증서가 필요하며 HTTP 연결을 허용하도록 구성되어야 합니다. Windows 8부터는 앱에서 자체 서명한 인증서를 사용하여 백 엔드 서버를 안전하게 인증할 수 있는 SSL 연결을 활용할 수 있습니다. 즉, CA에서 제공한 인증서 없이 보안 HTTPS 연결을 사용할 수 있습니다. 비용 때문에 HTTPS를 꺼린다면 안전하지 못한 HTTP 연결을 통해 데이터를 전송하는 앱을 제공했다는 비난을 피할 수 없습니다.
자체 서명한 인증서를 사용하려면 Visual Studio 2012의 Manifest Designer를 통해 앱 또는 앱 매니페스트 XML에 인증서 선언 목록을 추가하면 됩니다. 또한 동일한 인증서를 사용하도록 백 엔드 서버를 구성해야 합니다. IIS의 경우 간단한 절차를 통해 웹 사이트를 만들고 구성할 수 있습니다. 그러면 앱이 자동으로 패키지화된 인증서를 사용하여 웹 서버에 대한 연결을 인증합니다.
마지막으로, JavaScript로 작성된 앱을 갖고 있다면 다음과 같은 <meta> 태그를 앱에 사용하여 HTTPS 연결을 요청할 수 있습니다.
<meta name="ms-https-connections-only" content="true"/>
신뢰 구축
여러분이 Windows 8에 큰 기대를 걸고 Window 스토어에 뛰어난 앱을 많이 제출하면 좋겠습니다. 이 글에서 살펴본 팁과 모범 사례는 고객에게 보다 안전한 경험을 제공하여 앱이 기대한 대로 작동한다는 신뢰감을 줄 수 있는 중요한 요소입니다. 힘들게 얻은 최고 점수부터 중요한 금융 데이터까지 고객 데이터를 보호하는 보안은 모든 앱의 필수 요소입니다.
Windows 8 및 Windows 스토어 앱은 수많은 노력이 집중된 앱 플랫폼을 통해 고객이 믿고 앱을 테스트 및 구입할 수 있도록 설계되었습니다. 여러분이 앱 플랫폼을 사용하여 사람들이 좋아할 만한 앱을 개발할 수 있을 것이라 확신합니다.
앱 보안에 대해 더욱 자세히 알고 싶은 분들은 Developing Secure Apps(보안 앱 개발)백서, Starter Kit for the Security Development Lifecycle(보안 개발 라이프사이클을 위한 Starter 키트)및 Security Development Center(보안 개발 센터)에서 최신 정보를 확인할 수 있습니다.
감사합니다!
-Windows 수석 프로그램 관리자, Scott Graham
-Windows 수석 프로그램 관리자, Crispin Cowan
-믿을 수 있는 컴퓨팅 소프트웨어 보안 책임 엔지니어, David Ross