캡슐화는 강력한 경계를 그리는 것입니다. 웹 브라우저에서는 사용자의 모바일 코드가 다른 모바일 코드에 의해 오용되지 않도록 하는 것을 의미합니다. 서버에서는 검증된 데이터와 검증되지 않은 데이터, 한 사용자의 데이터와 다른 사용자의 데이터, 데이터 사용자가 볼 수 있는 데이터와 볼 수 없는 데이터 간의 차별화를 의미할 수 있습니다.
script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. 이러한 8개의 지정자는 사이트가 해당 지정자에서 관여하는 기능에 접근할 수 있는 도메인을 지정하는 값으로 소스 목록을 사용합니다. 개발자는 전체 또는 일부 소스를 나타내기 위해 와일드카드인 *를 사용할 수도 있습니다. 'unsafe-inline' 및 'unsafe-eval'과 같은 추가 소스 목록 키워드를 사용하면 스크립트 실행을 보다 세밀하게 제어할 수 있지만 잠재적으로 유해합니다. 지정자를 반드시 사용해야 하는 것은 아닙니다. 브라우저는 목록에 나열되지 않은 지정자에 대해 모든 소스를 허용하기도 하고 선택적 default-src 지정자에서 값을 파생하기도 합니다. 또한, 이 헤더의 사양은 시간이 지남에 따라 발전해 왔습니다. Firefox 버전 23 이하 및 IE 버전 10 이하에서는 X-Content-Security-Policy로, Chrome 버전 25 이하에서는 X-Webkit-CSP로 구현되었습니다. 하지만 이제는 새 표준 이름인 Content Security Policy를 사용하므로 이러한 두 이름은 더 이상 사용되지 않습니다. 지정자의 수, 더 이상 사용되지 않는 2개의 대체 이름, 그리고 단일 헤더에서 여러 번 나타나는 동일한 헤더와 반복되는 지정자가 처리되는 방식을 감안하면 개발자가 이 헤더를 잘못 구성할 확률이 높습니다.default-src 지정자를 설정합니다.
<http auto-config="true">
...
<headers>
...
<content-security-policy policy-directives="default-src '*'" />
</headers>
</http>
script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. 이러한 8개의 지정자는 사이트가 해당 지정자에서 관여하는 기능에 접근할 수 있는 도메인을 지정하는 값으로 소스 목록을 사용합니다. 개발자는 전체 또는 일부 소스를 나타내기 위해 와일드카드인 *를 사용할 수도 있습니다. 'unsafe-inline' 및 'unsafe-eval'과 같은 추가 소스 목록 키워드를 사용하면 스크립트 실행을 보다 세밀하게 제어할 수 있지만 잠재적으로 유해합니다. 지정자를 반드시 사용해야 하는 것은 아닙니다. 브라우저는 목록에 나열되지 않은 지정자에 대해 모든 소스를 허용하기도 하고 선택적 default-src 지정자에서 값을 파생하기도 합니다. 또한, 이 헤더의 사양은 시간이 지남에 따라 발전해 왔습니다. Firefox 버전 23 이하 및 IE 버전 10 이하에서는 X-Content-Security-Policy로, Chrome 버전 25 이하에서는 X-Webkit-CSP로 구현되었습니다. 하지만 이제는 새 표준 이름인 Content Security Policy를 사용하므로 이러한 두 이름은 더 이상 사용되지 않습니다. 지정자의 수, 더 이상 사용되지 않는 2개의 대체 이름, 그리고 단일 헤더에서 여러 번 나타나는 동일한 헤더와 반복되는 지정자가 처리되는 방식을 감안하면 개발자가 이 헤더를 잘못 구성할 확률이 높습니다.*-src 지정자는 * 같이 지나치게 허용적인 정책으로 구성되어 왔습니다.django-csp 설정에서는 지나치게 허용적이며 안전하지 않은 default-src 지정자를 설정합니다.
...
MIDDLEWARE = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", '*')
...
Access-Control-Allow-Origin이라는 새 HTTP 헤더가 정의될 경우 JavaScript가 도메인 전체의 데이터에 액세스할 수 있습니다. 이 헤더가 있는 경우, 웹 서버는 cross-origin 요청을 사용하여 해당 도메인에 액세스할 수 있는 다른 도메인을 정의합니다. 그러나, 지나치게 허용적인 CORS 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 헤더 정의 시 주의해야 합니다.
Response.AppendHeader("Access-Control-Allow-Origin", "*");
*를 Access-Control-Allow-Origin 헤더의 값으로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 실행 중인 JavaScript에 접근할 수 있음을 나타냅니다.Access-Control-Allow-Origin이라는 새 HTTP 헤더가 정의될 경우 JavaScript가 도메인 전체의 데이터에 액세스할 수 있습니다. 이 헤더가 있는 경우, 웹 서버는 cross-origin 요청을 사용하여 해당 도메인에 액세스할 수 있는 다른 도메인을 정의합니다. 그러나, 지나치게 허용적인 CORS 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 헤더 정의 시 주의해야 합니다.
<websocket:handlers allowed-origins="*">
<websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>
*를 Access-Control-Allow-Origin 헤더의 값으로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 실행 중인 JavaScript에 접근할 수 있음을 나타냅니다.Access-Control-Allow-Origin이라는 새 HTTP 헤더가 정의될 경우 JavaScript가 도메인 전체의 데이터에 액세스할 수 있습니다. 이 헤더가 있는 경우, 웹 서버는 cross-origin 요청을 사용하여 해당 도메인에 액세스할 수 있는 다른 도메인을 정의합니다. 그러나, 지나치게 허용적인 CORS 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 헤더 정의 시 주의해야 합니다.
<?php
header('Access-Control-Allow-Origin: *');
?>
*를 Access-Control-Allow-Origin 헤더의 값으로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 실행 중인 JavaScript에 접근할 수 있음을 나타냅니다.Access-Control-Allow-Origin이라는 새 HTTP 헤더가 정의될 경우 JavaScript가 도메인 전체의 데이터에 액세스할 수 있습니다. 이 헤더가 있는 경우, 웹 서버는 cross-origin 요청을 사용하여 해당 도메인에 액세스할 수 있는 다른 도메인을 정의합니다. 그러나, 지나치게 허용적인 CORS 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 헤더 정의 시 주의해야 합니다.
response.addHeader("Access-Control-Allow-Origin", "*")
*를 Access-Control-Allow-Origin 헤더의 값으로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 실행 중인 JavaScript에 접근할 수 있음을 나타냅니다.Access-Control-Allow-Origin이라는 새 HTTP 헤더가 정의될 경우 JavaScript가 도메인 전체의 데이터에 액세스할 수 있습니다. 이 헤더가 있는 경우, 웹 서버는 cross-origin 요청을 사용하여 해당 도메인에 액세스할 수 있는 다른 도메인을 정의합니다. 그러나, 지나치게 허용적인 CORS 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 헤더 정의 시 주의해야 합니다.
play.filters.cors {
pathPrefixes = ["/some/path", ...]
allowedOrigins = ["*"]
allowedHttpMethods = ["GET", "POST"]
allowedHttpHeaders = ["Accept"]
preflightMaxAge = 3 days
}
*를 Access-Control-Allow-Origin 헤더의 값으로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 실행 중인 JavaScript에 액세스할 수 있음을 나타냅니다.Access-Control-Allow-Origin이라는 새 HTTP 헤더가 정의될 경우 JavaScript가 도메인 전체의 데이터에 액세스할 수 있습니다. 이 헤더가 있는 경우, 웹 서버는 cross-origin 요청을 사용하여 해당 도메인에 액세스할 수 있는 다른 도메인을 정의합니다. 그러나, 지나치게 허용적인 CORS 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 헤더 정의 시 주의해야 합니다.
Response.AddHeader "Access-Control-Allow-Origin", "*"
*를 Access-Control-Allow-Origin 헤더의 값으로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 실행 중인 JavaScript에 접근할 수 있음을 나타냅니다.
WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
webview.postWebMessage(message, Uri.parse("*"));
*를 사용하면 스크립트가 원본에 상관없이 창에 메시지를 전송 중이라는 의미입니다.
o.contentWindow.postMessage(message, '*');
*를 사용하면 스크립트가 원본에 상관없이 창에 메시지를 전송 중이라는 의미입니다.Unsafe-URL로 설정하면 응용 프로그램이 민감한 사이트 및 사용자 데이터(세션 토큰, 사용자 이름 및 암호 포함)를 타사 사이트에 노출시킬 수 있습니다.Referrer-Policy 헤더는 referrer 헤더와 관련된 브라우저 동작을 제어하기 위해 도입되었습니다. Unsafe-URL 옵션을 사용하면 모든 제한이 제거되고 모든 요청과 함께 referrer 헤더를 보낼 수 있습니다.
<http auto-config="true">
...
<headers>
...
<referrer-policy policy="unsafe-url"/>
</headers>
</http>
Content-Security-Policy-Report-Only 헤더는 웹 응용 프로그램 작성자 및 관리자가 보안 정책을 적용하지 않고 모니터링할 수 있는 기능을 제공합니다. 이 헤더는 일반적으로 사이트의 보안 정책을 실험 및/또는 개발할 때 사용됩니다. 정책이 유효하다고 판단되면 Content-Security-Policy 헤더 필드를 대신 사용하여 정책을 적용할 수 있습니다.Report-Only 모드에서 Content Security Policy를 설정합니다.
<http auto-config="true">
...
<headers>
...
<content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
</headers>
</http>
Content-Security-Policy-Report-Only 헤더는 웹 응용 프로그램 작성자 및 관리자가 보안 정책을 적용하지 않고 모니터링할 수 있는 기능을 제공합니다. 이 헤더는 일반적으로 사이트의 보안 정책을 실험 및/또는 개발할 때 사용됩니다. 정책이 유효하다고 판단되면 Content-Security-Policy 헤더를 대신 사용하여 정책을 적용할 수 있습니다.Report-Only 모드에서 Content Security Policy를 설정합니다.
response.content_security_policy_report_only = "*"
SLComposeServiceViewController isContentValid의 구현에 실패합니다.
#import <MobileCoreServices/MobileCoreServices.h>
@interface ShareViewController : SLComposeServiceViewController
...
@end
@interface ShareViewController ()
...
@end
@implementation ShareViewController
- (void)didSelectPost {
NSExtensionItem *item = self.extensionContext.inputItems.firstObject;
NSItemProvider *itemProvider = item.attachments.firstObject;
...
// Use the received items
...
[self.extensionContext completeRequestReturningItems:@[] completionHandler:nil];
}
...
@end
SLComposeServiceViewController isContentValid의 구현에 실패합니다.SLComposeServiceViewController isContentValid 콜백 메서드를 구현하지 못합니다.
import MobileCoreServices
class ShareViewController: SLComposeServiceViewController {
...
override func didSelectPost() {
let extensionItem = extensionContext?.inputItems.first as! NSExtensionItem
let itemProvider = extensionItem.attachments?.first as! NSItemProvider
...
// Use the received items
...
self.extensionContext?.completeRequestReturningItems([], completionHandler:nil)
}
...
}
webview가 귀하의 응용 프로그램과 통신하기 위해 URL을 사용할 때 수신 응용 프로그램은 발신자가 통신 가능한 응용 프로그램의 허용 목록과 일치하는지 확인해야 합니다. 수신 응용 프로그램은 UIApplicationDelegate application:openURL:options: 또는 UIApplicationDelegate application:openURL:sourceApplication:annotation: 대리자 메서드를 사용하여 호출 URL의 출처를 확인할 수 있습니다.UIApplicationDelegate application:openURL:options: 대리자 메서드 구현은 IPC 호출의 발신자 확인에 실패하고 호출 URL을 처리합니다.
- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<NSString *,id> *)options {
NSString *theQuery = [[url query] stringByRemovingPercentEncoding:NSUTF8StringEncoding];
NSArray *chunks = [theQuery componentsSeparatedByString:@"&"];
for (NSString* chunk in chunks) {
NSArray *keyval = [chunk componentsSeparatedByString:@"="]; NSString *key = [keyval objectAtIndex:0];
NSString *value = [keyval objectAtIndex:1];
// Do something with your key and value
}
return YES;
}
wewbview가 귀하의 응용 프로그램과 통신하기 위해 URL을 사용할 때 수신 응용 프로그램은 발신자가 통신 가능한 응용 프로그램의 허용 목록과 일치하는지 확인해야 합니다. 수신 응용 프로그램은 UIApplicationDelegate application:openURL:options: 또는 UIApplicationDelegate application:openURL:sourceApplication:annotation: 대리자 메서드를 사용하여 호출 URL의 출처를 확인할 수 있습니다.UIApplicationDelegate application:openURL:options: 대리자 메서드 구현은 IPC 호출의 발신자 확인에 실패하고 호출 URL을 처리합니다.
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
return processCall(url)
}
webview가 귀하의 응용 프로그램과 통신하기 위해 URL을 사용할 때 수신 응용 프로그램은 추가 작업을 계속하기 전에 호출 URL을 확인해야 합니다. 수신 응용 프로그램은 UIApplicationDelegate application:didFinishLaunchingWithOptions: 또는 UIApplicationDelegate application:willFinishLaunchingWithOptions: 대리자 메서드를 사용하여 호출 URL을 열고자 한다는 것을 확인할 수 있습니다.UIApplicationDelegate application:didFinishLaunchingWithOptions: 대리자 메서드 구현은 호출 URL의 확인에 실패하고 항상 신뢰할 수 없는 URL을 처리합니다.
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NS Dictionary *)launchOptions {
return YES;
}
webview가 귀하의 응용 프로그램과 통신하기 위해 URL을 사용할 때 수신 응용 프로그램은 추가 작업을 계속하기 전에 호출 URL을 확인해야 합니다. 수신 응용 프로그램은 UIApplicationDelegate application:didFinishLaunchingWithOptions: 또는 UIApplicationDelegate application:willFinishLaunchingWithOptions: 대리자 메서드를 사용하여 호출 URL을 열고자 한다는 것을 확인할 수 있습니다.UIApplicationDelegate application:didFinishLaunchingWithOptions: 대리자 메서드 구현은 호출 URL의 확인에 실패하고 항상 신뢰할 수 없는 URL을 처리합니다.
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
return true
}
allowBackup 속성을 true(기본값)로 설정하고 <application> 태그에서 backupAgent 속성을 정의하면 됩니다.Environment.getExternalStorageDirectory()는 Android 장치의 외부 저장소에 대한 참조를 반환합니다. private void WriteToFile(String what_to_write) {
try{
File root = Environment.getExternalStorageDirectory();
if(root.canWrite()) {
File dir = new File(root + "write_to_the_SDcard");
File datafile = new File(dir, number + ".extension");
FileWriter datawriter = new FileWriter(datafile);
BufferedWriter out = new BufferedWriter(datawriter);
out.write(what_to_write);
out.close();
}
}
}
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:kSecAttrAccessibleAlways:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:kSecAttrAccessibleAlwaysThisDeviceOnly:kSecAttrAccessibleWhenUnlocked:kSecAttrAccessibleWhenUnlockedThisDeviceOnly:ThisDeviceOnly가 포함되지 않은 액세스 가능성 수준은 iCloud로 백업되며 모든 장치로 복원할 수 있는 암호화되지 않은 백업을 사용 중이더라도 iTunes로 백업됩니다. 이 경우 저장된 데이터의 민감도 및 개인 정보 관련성에 따라 개인 정보 문제가 발생할 수 있습니다.
...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];
// Configure KeyChain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...
[dict setObject:(__bridge id)kSecAttrAccessibleWhenUnlocked forKey:(__bridge id) kSecAttrAccessible];
OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:kSecAttrAccessibleAlways:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:kSecAttrAccessibleAlwaysThisDeviceOnly:kSecAttrAccessibleWhenUnlocked:kSecAttrAccessibleWhenUnlockedThisDeviceOnly:ThisDeviceOnly가 포함되지 않은 액세스 가능성 수준은 iCloud로 백업되며 모든 장치로 복원할 수 있는 암호화되지 않은 백업을 사용 중이더라도 iTunes로 백업됩니다. 이 경우 저장된 데이터의 민감도 및 개인 정보 관련성에 따라 개인 정보 문제가 발생할 수 있습니다.
...
// Configure KeyChain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?
...
query[kSecAttrAccessible as String] = kSecAttrAccessibleWhenUnlocked
SecItemAdd(query as CFDictionary, nil)
...
protected void onCreate(Bundle savedInstanceState) {
...
try {
File httpCacheDir = new File(context.getExternalCacheDir(), "http");
long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
HttpResponseCache.install(httpCacheDir, httpCacheSize);
} catch (IOException e) {
Log.i(TAG, "HTTP response cache installation failed:" + e);
}
}
protected void onStop() {
...
HttpResponseCache cache = HttpResponseCache.getInstalled();
if (cache != null) {
cache.flush();
}
}
{app ID}/Library/Caches/com.mycompany.myapp/Cache.db* 파일에 저장합니다.{app ID}/Library/Caches/com.mycompany.myapp/Cache.db* 파일에 저장합니다.{app ID}/Library/Caches/com.mycompany.myapp/Cache.db* 파일에 저장합니다. URLCache 클래스의 diskCapacity 또는 memoryCapacity 속성을 0으로 설정하여 HTTP(S) 응답 캐시 시스템을 실제로 비활성화했다고 생각할 수 있습니다. 하지만 NSURLCache 설명서에는, 장치의 메모리 또는 디스크 공간이 부족한 경우에만 디스크 및 메모리 캐시가 구성된 크기로 잘린다고 명시되어 있습니다. 두 설정은 보안 제어의 용도가 아니라 시스템이 시스템 리소스를 확보하여 성능을 향상시키기 위한 용도입니다.{app ID}/Library/Caches/com.mycompany.myapp/Cache.db* 파일에 저장합니다. URLCache 클래스의 diskCapacity 또는 memoryCapacity 속성을 0으로 설정하여 HTTP(S) 응답 캐시 시스템을 실제로 비활성화했다고 생각할 수 있습니다. 하지만 NSURLCache 설명서에는, 장치의 메모리 또는 디스크 공간이 부족한 경우에만 디스크 및 메모리 캐시가 구성된 크기로 잘린다고 명시되어 있습니다. 두 설정은 보안 제어의 용도가 아니라 시스템이 시스템 리소스를 확보하여 성능을 향상시키기 위한 용도입니다.NSFileManager 인스턴스와 연결된 NSDictionary의 NSFileProtectionKey 키 값으로 할당되는 상수로 NSFileManager에 대해 정의됩니다. setAttributes:ofItemAtPath:error:, attributesOfItemAtPath:error:, createFileAtPath:contents:attributes: 등의 NSFileManager 함수를 사용하면 파일을 만들거나 파일의 데이터 보호 클래스를 수정할 수 있습니다. 또한 NSData 개체에 대해서도 해당하는 데이터 보호 상수가 NSDataWritingOptions로 정의되며, 이는 NSData 함수 writeToURL:options:error: 및 writeToFile:options:error:에 options 인수로 전달할 수 있습니다. NSFileManager 및 NSData에 지정되는 다양한 데이터 보호 클래스 상수의 정의는 다음과 같습니다.NSFileProtectionComplete, NSDataWritingFileProtectionComplete:NSFileProtectionCompleteUnlessOpen, NSDataWritingFileProtectionCompleteUnlessOpen:NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication:NSFileProtectionNone, NSDataWritingFileProtectionNone:NSFileProtectionCompleteUnlessOpen 또는 NSFileProtectionCompleteUntilFirstUserAuthentication으로 표시하면 사용자의 암호 및 장치의 UID에서 파생된 키를 사용하여 암호화할 수 있으며 특정 상황에서도 계속해서 데이터에 접근할 수 있습니다. NSFileProtectionCompleteUnlessOpen 또는 NSFileProtectionCompleteUntilFirstUserAuthentication을 이와 같이 사용하는 경우 신중하게 검토하여 NSFileProtectionComplete를 통한 추가 보호가 보증되는지를 확인해야 합니다.예제 2: 다음 예제에서는 지정된 데이터가 사용자가 장치를 켜고 암호를 처음 입력할 때까지만 보호됩니다(다음 재부팅 시까지).
...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSDictionary *protection = [NSDictionary dictionaryWithObject:NSFileProtectionCompleteUntilFirstUserAuthentication forKey:NSFileProtectionKey];
...
[[NSFileManager defaultManager] setAttributes:protection ofItemAtPath:filepath error:nil];
...
BOOL ok = [testToWrite writeToFile:filepath atomically:YES encoding:NSUnicodeStringEncoding error:&err];
...
...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSData *textData = [textToWrite dataUsingEncoding:NSUnicodeStingEncoding];
...
BOOL ok = [textData writeToFile:filepath options:NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication error:&err];
...
NSFileManager 인스턴스와 연결된 Dictionary의 NSFileProtectionKey 키 값으로 할당되는 상수로 NSFileManager에서 정의됩니다. setAttributes(_:ofItemAtPath:), attributesOfItemAtPath(_:), createFileAtPath(_:contents:attributes:) 등의 NSFileManager 함수를 사용하면 파일을 만들거나 파일의 데이터 보호 클래스를 수정할 수 있습니다. 또한 NSDataWritingOptions 열거의 NSData 개체에 대해서도 해당하는 데이터 보호 상수가 정의됩니다. 이 상수는 NSData 함수에 대한 options 인수로 전달할 수 있으며, 해당 함수는
writeToFile(_:options:)NSFileManager 및 NSData에 지정되는 다양한 데이터 보호 클래스 상수의 정의는 다음과 같습니다.NSFileProtectionComplete, NSDataWritingOptions.DataWritingFileProtectionComplete:NSFileProtectionCompleteUnlessOpen, NSDataWritingOptions.DataWritingFileProtectionCompleteUnlessOpen:NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingOptions.DataWritingFileProtectionCompleteUntilFirstUserAuthentication:NSFileProtectionNone, NSDataWritingOptions.DataWritingFileProtectionNone:NSFileProtectionCompleteUnlessOpen 또는 NSFileProtectionCompleteUntilFirstUserAuthentication으로 표시하면 사용자의 암호 및 장치의 UID에서 파생된 키를 사용하여 암호화할 수 있으며 특정 상황에서도 계속해서 데이터에 접근할 수 있습니다. NSFileProtectionCompleteUnlessOpen 또는 NSFileProtectionCompleteUntilFirstUserAuthentication을 이와 같이 사용하는 경우 신중하게 검토하여 NSFileProtectionComplete를 통한 추가 보호가 보증되는지를 확인해야 합니다.예제 2: 다음 예에서는 지정된 데이터가 사용자가 장치를 켜고 암호를 처음 입력할 때까지만 보호됩니다(다음 재부팅 시까지).
...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
let protection = [NSFileProtectionKey: NSFileProtectionCompleteUntilFirstUserAuthentication]
do {
try NSFileManager.defaultManager().setAttributes(protection, ofItemAtPath: filename)
} catch let error as NSError {
NSLog("Unable to change attributes: \(error.debugDescription)")
}
...
BOOL ok = textToWrite.writeToFile(filename, atomically:true)
...
...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
...
BOOL ok = textData.writeToFile(filepath, options: .DataWritingFileProtectionCompleteUntilFirstUserAuthentication);
...
kSecAttrAccessible 키에 대한 값으로 할당됩니다. 다양한 키 집합 액세스 가능성 상수에 대한 정의는 다음과 같습니다.kSecAttrAccessibleAfterFirstUnlock:kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:kSecAttrAccessibleAlways:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:kSecAttrAccessibleAlwaysThisDeviceOnly:kSecAttrAccessibleWhenUnlocked:kSecAttrAccessibleWhenUnlockedThisDeviceOnly:kSecAttrAccessibleAfterFirstUnlock으로 표시하면 사용자의 암호 및 장치의 UID에서 파생된 키를 사용하여 암호화할 수 있으며 특정 상황에서도 계속해서 데이터에 액세스할 수 있습니다. kSecAttrAccessibleAfterFirstUnlock의 사용을 신중하게 검토하여 추가 보호가 보증되는지 확인해야 합니다.
...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];
// Configure KeyChain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...
[dict setObject:(__bridge id)kSecAttrAccessibleAfterFirstUnlock forKey:(__bridge id) kSecAttrAccessible];
OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
kSecAttrAccessible 키에 대한 값으로 할당됩니다. 다양한 키 집합 액세스 가능성 상수에 대한 정의는 다음과 같습니다.kSecAttrAccessibleAfterFirstUnlock:kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:kSecAttrAccessibleAlways:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:kSecAttrAccessibleAlwaysThisDeviceOnly:kSecAttrAccessibleWhenUnlocked:kSecAttrAccessibleWhenUnlockedThisDeviceOnly:kSecAttrAccessibleAfterFirstUnlock으로 표시하면 사용자의 암호 및 장치의 UID에서 파생된 키를 사용하여 암호화할 수 있으며 특정 상황에서도 계속해서 데이터에 액세스할 수 있습니다. kSecAttrAccessibleAfterFirstUnlock의 사용을 신중하게 검토하여 추가 보호가 보증되는지 확인해야 합니다.
...
// Configure KeyChain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?
...
query[kSecAttrAccessible as String] = kSecAttrAccessibleAfterFirstUnlock
SecItemAdd(query as CFDictionary, nil)
...
NSFileManager 인스턴스와 연결된 NSDictionary의 NSFileProtectionKey 키 값으로 할당되는 상수로 NSFileManager에 대해 정의됩니다. setAttributes:ofItemAtPath:error:, attributesOfItemAtPath:error:, createFileAtPath:contents:attributes: 등의 NSFileManager 함수를 사용하면 파일을 만들거나 파일의 데이터 보호 클래스를 수정할 수 있습니다. 또한 NSData 개체에 대해서도 해당하는 데이터 보호 상수가 NSDataWritingOptions로 정의되며, 이는 NSData 함수 writeToURL:options:error: 및 writeToFile:options:error:에 options 인수로 전달할 수 있습니다. NSFileManager 및 NSData에 지정되는 다양한 데이터 보호 클래스 상수의 정의는 다음과 같습니다.NSFileProtectionComplete, NSDataWritingFileProtectionComplete:NSFileProtectionCompleteUnlessOpen, NSDataWritingFileProtectionCompleteUnlessOpen:NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication:NSFileProtectionNone, NSDataWritingFileProtectionNone:NSFileProtectionNone을 지정하면 장치의 UID만을 토대로 파생된 키를 사용하여 암호화됩니다. 이렇게 되면 암호로 잠겨 있는 경우나 부팅할 때를 비롯해 장치가 켜져 있을 때는 언제든지 이러한 파일에 접근할 수 있게 됩니다. NSFileProtectionNone을 이와 같이 사용하는 경우 신중하게 검토하여 더 엄격한 데이터 보호 클래스를 통한 추가 보호가 보증되는지를 확인해야 합니다.예제 2: 다음 예제에서는 지정된 데이터가 보호되지 않습니다(장치가 켜져 있을 때는 언제든지 접근 가능).
...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSDictionary *protection = [NSDictionary dictionaryWithObject:NSFileProtectionNone forKey:NSFileProtectionKey];
...
[[NSFileManager defaultManager] setAttributes:protection ofItemAtPath:filepath error:nil];
...
BOOL ok = [testToWrite writeToFile:filepath atomically:YES encoding:NSUnicodeStringEncoding error:&err];
...
...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSData *textData = [textToWrite dataUsingEncoding:NSUnicodeStingEncoding];
...
BOOL ok = [textData writeToFile:filepath options:NSDataWritingFileProtectionNone error:&err];
...
NSFileManager에서 NSFileManager 인스턴스와 연결된 Dictionary의 NSFileProtectionKey 키 값으로 할당되는 상수로 정의됩니다. setAttributes(_:ofItemAtPath:), attributesOfItemAtPath(_:), createFileAtPath(_:contents:attributes:) 등의 NSFileManager 함수를 사용하면 파일을 만들거나 파일의 데이터 보호 클래스를 수정할 수 있습니다. 또한 NSDataWritingOptions 열거의 NSData 개체에 대해서도 해당하는 데이터 보호 상수가 정의됩니다. 이 상수는 NSData 함수에 대한 options 인수로 전달할 수 있으며, 이러한 함수로는
writeToFile(_:options:)NSFileManager 및 NSData에 지정되는 다양한 데이터 보호 클래스 상수의 정의는 다음과 같습니다.NSFileProtectionComplete, NSDataWritingOptions.DataWritingFileProtectionComplete:NSFileProtectionCompleteUnlessOpen, NSDataWritingOptions.DataWritingFileProtectionCompleteUnlessOpen:NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingOptions.DataWritingFileProtectionCompleteUntilFirstUserAuthentication:NSFileProtectionNone, NSDataWritingOptions.DataWritingFileProtectionNone:NSFileProtectionNone을 지정하면 장치의 UID만을 토대로 파생된 키를 사용하여 암호화됩니다. 이렇게 되면 암호로 잠겨 있는 경우나 부팅할 때를 비롯해 장치가 켜져 있을 때는 언제든지 이러한 파일에 접근할 수 있게 됩니다. NSFileProtectionNone을 이와 같이 사용하는 경우 신중하게 검토하여 더 엄격한 데이터 보호 클래스를 통한 추가 보호가 보증되는지를 확인해야 합니다.예제 2: 다음 예에서는 지정된 데이터가 보호되지 않습니다(장치가 켜져 있을 때는 언제든지 접근 가능).
...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
let protection = [NSFileProtectionKey: NSFileProtectionNone]
do {
try NSFileManager.defaultManager().setAttributes(protection, ofItemAtPath: filename)
} catch let error as NSError {
NSLog("Unable to change attributes: \(error.debugDescription)")
}
...
BOOL ok = textToWrite.writeToFile(filename, atomically:true)
...
...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
...
BOOL ok = textData.writeToFile(filepath, options: .DataWritingFileProtectionNone);
...
kSecAttrAccessible 키에 대한 값으로 할당됩니다. 다양한 키 집합 액세스 가능성 상수에 대한 정의는 다음과 같습니다.kSecAttrAccessibleAfterFirstUnlock:kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:kSecAttrAccessibleAlways:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:kSecAttrAccessibleAlwaysThisDeviceOnly:kSecAttrAccessibleWhenUnlocked:kSecAttrAccessibleWhenUnlockedThisDeviceOnly:kSecAttrAccessibleAlways을 지정하면 장치의 UID만을 기반으로 하여 파생된 키를 사용하여 암호화됩니다. 이렇게 되면 암호로 잠겨 있는 경우나 부팅할 때를 비롯해 장치가 켜져 있을 때는 언제든지 이러한 파일에 접근할 수 있게 됩니다. kSecAttrAccessibleAlways의 사용을 신중하게 검토하여 더 엄격한 키 집합 액세스 가능성 수준으로 추가 보호가 보증되는지 확인해야 합니다.
...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];
// Configure KeyChain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...
[dict setObject:(__bridge id)kSecAttrAccessibleAlways forKey:(__bridge id) kSecAttrAccessible];
OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
kSecAttrAccessible 키에 대한 값으로 할당됩니다. 다양한 키 집합 액세스 가능성 상수에 대한 정의는 다음과 같습니다.kSecAttrAccessibleAfterFirstUnlock:kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:kSecAttrAccessibleAlways:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:kSecAttrAccessibleAlwaysThisDeviceOnly:kSecAttrAccessibleWhenUnlocked:kSecAttrAccessibleWhenUnlockedThisDeviceOnly:kSecAttrAccessibleAlways을 지정하면 장치의 UID만을 기반으로 하여 파생된 키를 사용하여 암호화됩니다. 이렇게 되면 암호로 잠겨 있는 경우나 부팅할 때를 비롯해 장치가 켜져 있을 때는 언제든지 이러한 파일에 접근할 수 있게 됩니다. kSecAttrAccessibleAlways의 사용을 신중하게 검토하여 더 엄격한 키 집합 액세스 가능성 수준으로 추가 보호가 보증되는지 확인해야 합니다.
...
// Configure KeyChain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?
...
query[kSecAttrAccessible as String] = kSecAttrAccessibleAlways
SecItemAdd(query as CFDictionary, nil)
...