Sandbox apple что это

Что такое «sandboxd» и что он делает в моем Mac

Открыли «Мониторинг системы» и обнаружили непонятный процесс под названием «sanboxd»? Давайте вместе разбираться что это такое. «sandboxd» — это демон (от анг. daemon), процесс, который выполняет определенную задачу в фоновом режиме, как правило у всех daemon-процессов буква «d» в окончании. Если конкретнее, sandboxd отвечает за работу процесса «песочницы». Запустите терминал и введите команду «man sandboxd» (без кавычек) и вы получите описание процесса:

sandboxd performs services on behalf of the Sandbox kernel extension.

«App Sandbox is an access control technology provided in macOS, enforced at the kernel level. It is designed to contain damage to the system and the user’s data if an app becomes compromised.»

Приложение sandbox — это технология контроля доступа в MacOS, которая действует на уровне ядра системы. Она предназначена, уберечь систему и данные пользователя от повреждений, на случай если приложение будет скомпрометировано.

Приложения, которые работают из «песочницы» делают запрос на доступ к файлам и функциям системы, например, на доступ к веб-камере — этот процесс добавляет дополнительный уровень безопасности ОС. Использование «песочницы» является одним из самых основных требований к приложениям, которые распространяются через Mac App Store — это одна из причин по которой некоторого софта нет в Mac App Store. Процесс «sandboxd» не расходует много системных ресурсов.

И самое главное, не забудьте подписаться на наш канал в Telegram

Источник

Безопасность в процессе выполнения в iOS и iPadOS

Песочница

Все приложения сторонних разработчиков помещаются в песочницы, что ограничивает их доступ к файлам, хранящимся в других приложениях, и не позволяет вносить изменения в работу устройства. Песочницы были разработаны для того, чтобы не позволить приложениям собирать и изменять информацию, сохраняемую другими приложениями. Каждое приложение использует для своих файлов уникальную домашнюю папку, которая назначается случайным образом при установке приложения. Если приложению стороннего разработчика необходимо получить доступ к чужой информации, оно может сделать это только при помощи специальных служб iOS и iPadOS.

Системные файлы и ресурсы также отделены от приложений пользователей. Большинство системных файлов и ресурсов iOS и iPadOS, а также все приложения сторонних разработчиков работают с правами непривилегированного «мобильного» пользователя. Весь раздел операционной системы подключен только для чтения. Системное программное обеспечение не содержит ненужных инструментов, таких как службы удаленного входа, а API не позволяют приложениям расширять свои полномочия для изменения других приложений или самой iOS и iPadOS.

Использование прав

Для контроля доступа приложений сторонних разработчиков к информации пользователя и таким функциям, как iCloud и расширения, используется декларирование прав. Права — это пары ключ-значение, которые зарегистрированы в приложении и обеспечивают аутентификацию без привязки ко времени выполнения, аналогично идентификатору пользователя в UNIX. Поскольку права защищены цифровой подписью, их невозможно изменить. Системные приложения и демоны широко используют права для выполнения конкретных привилегированных операций — в противном случае для их выполнения требовалось бы использовать корневые процессы. Это значительно снижает вероятность передачи прав взломанным системным приложением или демоном.

Кроме того, приложения могут выполнять фоновую обработку только через системные API. Это защищает систему от снижения производительности или значительного сокращения времени работы от аккумулятора во время работы приложений.

Технология случайного расположения в адресном пространстве

Технология случайного расположения в адресном пространстве (ASLR) помогает защититься от атак, связанных с использованием повреждения памяти. Встроенные приложения используют ASLR, что помогает случайным образом перераспределять все регионы памяти при запуске. Случайное расположение в памяти адресов исполняемого кода, системных библиотек и связанных с ними системных компонентов снижает вероятность использования уязвимостей. Например, атака типа «возврат в библиотеку» пытается путем подмена вынудить устройство выполнить вредоносный код, манипулируя адресами стека и системных библиотек. Случайное размещение этих элементов повышает сложность проведения атаки, особенно при атаке на несколько устройств. Xcode, а также среда разработки iOS и iPadOS, автоматически включает поддержку ASLR в приложения сторонних разработчиков при их компиляции.

Функция Execute Never

Функция Execute Never (XN) архитектуры ARM в iOS и iPadOS помечает страницы памяти как неисполняемые, обеспечивая дополнительную защиту. Страницы памяти, помеченные как доступные для записи и исполняемые, могут использоваться только в жестко контролируемых условиях: ядро проверяет наличие права динамического подписания кода, которое предоставляется только Apple. Даже при его наличии можно выполнить только один вызов mmap для запроса исполняемой и доступной для записи страницы, которой присваивается случайный адрес. Safari использует эту функцию в своем компиляторе JavaScript JIT.

Источник

То, что нужно знать о проверке чека App Store (App Store receipt)

В StackOverflow по-прежнему появляется много вопросов о валидации App Store чеков, поэтому мы решили написать статью на эту тему в формате вопросов и ответов.

Что представляет собой App Store чек?

Это зашифрованный файл в формате PKCS#7, который содержит в себе информацию обо всех покупках в приложении. Находится в бандле приложения и его можно легко получить, вызвав: Bundle.main.appStoreReceiptURL .

Всегда ли есть этот файл?

Если приложение было скачано из App Store, то да, всегда. А если было установлено через Xcode или Testflight, то первоначально у приложения sandbox-чек отсутствует до первой покупки или восстановления чека.

Что значит «провалидировать чек»?

Это означает расшифровать файл, получить JSON дату и сверить совершенные пользователем покупки. Сделать это можно локально или отправив запрос в Apple.

В каких случаях разработчику требуется валидация чека?

Для валидации только что совершенной покупки.
Когда у многих был джейлбрейк это было актуально: существовали утилиты для подделки чека. Сейчас эта проблема перестала быть острой, потому что джейлбрейк стал редкостью.

При восстановлении покупок.
Если пользователь переустановил ваше приложение или запустил с другого устройства, вы должны предоставить ему доступ к функционалу, за который он уже заплатил. Расшифровав App Store чек, вы сможете выяснить, была ли приобретена встроенная покупка.

При покупке авто-возобновляемых подписок.
Для определения текущего статуса подписки и даты истечения.

Какие покупки можно восстановить при валидации?

Существует 4 вида встроенных покупок:

• расходуемые (consumable purchases),
• нерасходуемые (non-consumable purchases),
• невозобновляемые подписки (non-renewing subscriptions),
• авто-возобновляемые подписки (auto-renewable Subscriptions).
  Восстановить можно все, кроме расходуемых покупок. К ним можно отнести, например, монетки в вашем приложении – что-то, что можно купить сколько угодно раз. Вы должны сами сохранять текущее количество монеток у пользователя на своем сервере.

Какие способы валидации существуют?

• локальная валидация с использованием OpenSSL,
• валидация по запросу в Apple прямо с iOS устройства,
• валидация по запросу в Apple с использованием вашего сервера.

Какой способ валидации лучше?

Локальная валидация сложна и требует много времени и усилий на реализацию. А еще вы должны будете добавить OpenSSL библиотеку в ваш проект. В некоторых случаях придется обновлять чек.

Apple не рекомендует проверять чеки на самом iOS-устройстве. Это небезопасно: запрос можно перехватить с помощью man-in-the-middle атаки.

Лучше всего валидировать чеки на сервере. Тем более, что Apple время от времени добавляет туда новые поля, например, grace_period_expires_date и subscription_group_identifier . На своем сервере мы сможете быстро вносить изменения без обновления приложения. А еще предыдущие два метода валидации можно легко обмануть, просто поменяв системное время на iOS устройстве.

Для чего нужен Shared Secret?

Это специальная строка-ключ, которая необходима для расшифровки чеков с авто-возобновляемыми покупками. Apple использует Shared secret как параметр в HTTPS запросе к Apple.

Где взять Shared Secret?

Перейдите в App Store Connect, откройте приложение, перейдите во вкладку Функции, в разделе Встроенные покупки увидите кнопку Общий ключ для приложения. Сгенерируйте новый ключ, если его еще нет.

Пример кода для валидации чека

Это пример валидации чека на iOS. Не забудьте заменить значение YOUR_SHARED_SECRET на ваш shared secret.

Получив data , сконвертируйте его в Dictionary :

Пример расшифрованного App Store чека

Здесь можно посмотреть пример чека с двумя транзакциями в приложении с авто-возобновляемой подпиской.

В чем отличия между in_app и latest_receipt_info ?

latest_receipt_info содержит все транзакции, включая продления авто-возобновляемых покупок. Вам стоит использовать только этот массив.

in_app содержит транзакции нерасходуемых покупок и невозобновляемых подписок. Еще здесь дублируется первая транзакция вашей авто-возобновляемой подписки. Расходуемые покупки тоже появятся в массиве in_app , но потом исчезнут, когда разработчик завершит транзакцию.

Заключение

Мы в Apphud реализовали валидацию App Store чеков для приложений с авто-возобновляемыми подписками в удобном open-source SDK. А еще Apphud помогает отслеживать статус подписки, анализировать ключевые метрики, автоматически предлагать скидки отписавшимся пользователям и многое другое. Если при работе с подписками вы испытываете боль, попробуйте наше решение бесплатно.

Источник

Sandbox Testing

The sandbox environment is a great way to test offline implementation of Apple Pay for apps, websites, and point of sale systems. This document provides an overview of the sandbox environment, details on how to get started, and general support to test your Apple Pay transactions.

Sandbox

The Apple Pay sandbox environment allows merchants and developers to test their implementation of Apple Pay with test credit and debit cards. Currently the sandbox supports Apple Pay testing for:

• Australia
• Canada
• China mainland
• Hong Kong
• Taiwan
• France
• Ireland
• Italy

• Japan
• New Zealand
• Russia
• Singapore
• Spain
• United Kingdom
• United States

Note: It is also important to test Apple Pay in your production environment. Real cards must be used in the production environment. Test cards will not work.

Getting Started

You’ll need the following to test Apple Pay in the sandbox:

• iPhone 6 or later, iPad mini 3 or later, iPad Air 2, iPad Pro, or Apple Watch
• App Store Connect sandbox tester account
• Supported test credentials

Developer Account and Website

To successfully establish an Apple Pay session with Apple Pay servers, your Apple Developer account needs to be configured for Apple Pay. This includes registering a merchant ID, creating certificates, and verifying your website domain if you plan to implement Apple Pay for the web. Make sure to complete the steps below before testing your Apple Pay implementation with Apple Pay servers.
Learn more about configuring your environment

• Register a Merchant ID in your developer account.
• Create your Payment Processing Certificate or obtained a CSR from your PSP.
• Create your Merchant Identity Certificate (Apple Pay for web only).
• Register and verify a Merchant Domain (Apple Pay for web only).
• Verify that all webpages hosting an Apple Pay button are HTTPS and your web server supports TLS 1.2.

Create a Sandbox Tester Account

To create a sandbox tester account, follow these steps:

1. Sign in to App Store Connect.
2. On the homepage, click Users and Access.
3. Under Sandbox, click Testers.
4. Click “+” to set up your tester accounts.
5. Complete the tester information form and click Invite.
6. Sign out of your Apple ID on all testing devices and sign back in with your new sandbox tester account.

For more information on how to create a sandbox tester account, see App Store Connect Help: Create a sandbox tester account.

Important: If you mistakenly use a sandbox tester account to sign in to a production environment, like iTunes, on your test device instead of your test environment, the sandbox account becomes invalid and can’t be used again. If this happens, create a new sandbox tester account with a new email address.

Adding a Test Card Number

To get started, add a test card to Wallet:

1. Make sure to sign out of iCloud and sign into your test device with your sandbox tester account.
2. Go to Wallet and tap Add Credit or Debit Card.
3. Using your test credential, follow the steps to add a new card using manual entry.
4. After your card has been added, you may begin testing.

Note: To provision test cards on your device and use the sandbox, you will need to make sure that your device’s region is set to a country or region that supports Apple Pay.

Testing Apple Pay on Your Apps and Websites

With your iPhone, iPad, or Apple Watch, you can use the Apple Pay sandbox to pay within your app and website. The Apple Pay sandbox environment allows merchants and developers to test Apple Pay before or after implementation. Developers don’t have to use their personal production cards for testing. Merchants or your PSP can test whether they’re able to decrypt the transaction-specific payment load.

Note: Your sandbox test transaction will decline pre-fulfillment as the test key will not match your production key.

Test Cards for Apps and the Web

Test card numbers (FPAN, CVV, CVC, Expiration Date) from the payment networks are listed below and can be used on supported devices to test within the Apple Pay sandbox environment.

Note:

• FPAN and DPAN expiration dates do not need to match.
• American Express test cards can only support device regions that are set to the United States.

Test Cards for Apps and Websites in China Mainland

Test card details (FPAN, CVV, Expiry, OTP) for China UnionPay cards are listed below and can be used on supported devices to test your Apple Pay implementation.

Note:

• China UnionPay test cards can only support device regions that are set to China mainland.
• You will be prompted to enter a One Time Password (OTP) during provisioning. You should enter the value 123456.
• China UnionPay test debit cards do not require CVV or expiry date.
• China UnionPay test cards may require a PIN when making an Apple Pay test transaction. The PIN is 939393.
• In China mainland, Apple Pay for websites is available only on Safari on iOS devices that are compatible with Apple Pay and running iOS 11.2 or later.

Test Cards for Point of Sale Systems

Retailers can use the sandbox to do simple terminal offline tests to make sure Apple Pay transactions are working in their PoS terminals before they enable NFC functionality.

Test card numbers (FPAN, CVV, CVC, Expiration Date) from the payment networks are listed below so you can test within the Apple Pay sandbox environment.

Note: This does not replace Payment Network contactless certification. These FPANs can only be used for terminal offline beep tests using Apple Pay after completing Payment Network certification.

Network	FPANs	MagStripe Contactless	EMV Contactless
Amex	3499 562866 52212 Exp Date: 11/2022 CID: 1111	●
	3499 567268 99159 Exp Date: 11/2022 CID: 1111	●
Discover	6011 0009 9606 5037 Exp Date: 11/2022 CID: 111	●	●
	6011 0009 9631 8741 Exp Date: 11/2022 CID: 111	●	●
MasterCard	5204 2477 5000 1471 Exp Date: 11/2022 CVC: 111	●	●
	5204 2452 5000 1488 Exp Date: 11/2022 CVC: 111	●	●

Feedback and Questions

Have feedback? Send it to Apple Pay Support. Have additional questions? Join the conversation. Post questions and search for answers at Apple Developer Forums.

Design guidelines

Learn how to optimize the design and checkout experience for Apple Pay.

Payment service providers

Support Apple Pay quickly and reliably with an SDK or API from a payment service provider (PSP).

View payment service providers

Contact us

Have a question or request? We can help by phone or email.

Источник