my question starts from this article here. I followed it along, but this passage:
Security Considerations
Since these files will potentially contain secure information, such as
API_KEY, I’d recommend not checking them into version control and
instead using a secure file storage system like 1Password to contain
copies of Development.xcconfig, Staging.xcconfig and
Production.xcconfig.
makes me wonder what writer is talking about. Configs file are needed be in the app to work, I don't think I could put them aside. if someone could help I need to understand
how to handle those files in safety
how should use this config files, should I put them different (id present) endpoint based on environment? could I put there different things such images names, default values for variables etch?
I also wonder how this could be handled, putting them in some 1Password storage.
If you feel unsafe by checking in those files (why would you? Anyone who accesses the source code needs to somehow access some API using some key), you could
Handle this by .gitignore
Create a softlink from your repositiory to some outside "safe" area in your file system, protected by file system access rights
Handle those secrets by means of the keychain / secure enclave, see here
Anyhow, the biggest / only security risk I see is if you plan to publish your repository and dont't want your secrets to go public. In that case, you would replace those API keys by some text like "[enter your api key here]", which could easily be done by some awk/sed scripting.
Related
I would like to specify different default ACL levels for two different folders in the same Google Cloud storage bucket. Is this even possible, or is there perhaps some workaround available?
It seems to be possible retroactively specify different ACL levels for different folders using the gsutil acl command, whereas it is only possible to use the gsutil defacl command on the entire bucket. Correct?
Some potential workarounds I've been brainstorming, but not found any support for yet:
Set each files specific ACL from the client-side (iOS/Android) when it is first uploaded.
Have a Cloud Function listen for new file uploads and then modify it's ACL accordingly.
Again, I have not found any clues in the official documentation towards implementing any of the above solutions, so any pointers would be greatly appreciated. Thanks in advance!
Right now, ACLs can only be applied to individual objects, and IAM policies can only be applied to entire buckets or individual objects.
Your two proposed solutions are both reasonable but both have drawbacks. The first solution would be best, but only if you trust the iOS user to set good permissions. The client could potentially set different permissions. That's not necessarily a problem, since presumably the client already has the data and, if they were malicious, could already share it anywhere it wanted to, but it's something to be aware of.
The second solution is also fine, but there's a very small window of time wherein the object's ACLs would be incorrect. That may also not be a problem for you.
One nice variation might be to have users upload the objects to a "staging" bucket, and then have a Cloud Function respond to that upload by moving the object to its production location with the correct ACL, then delete the staged version.
This question already has an answer here:
Sharing data in between apps in IOS
(1 answer)
Closed 7 years ago.
I've been doing research on how to share data between applications securely. I'd like to get some info on the correct way to handle this before I do a deep dive on implementation using the wrong method. Just cause you can do something does not necessarily mean you should.
User Case: I am working on a suite of language learning apps that have a shared audio file base of several hundred audio files and json files containing important data corresponding to a language. I'd prefer to allow the user to not have to re-download the language bundle when they use another app in our suite.
1. App Extensions - Document Provider Non-UI Variant
According to the documentation:
The File Provider extension grants access to files outside the host app’s sandbox with the open and move actions. This extension (sometimes shortened here to file provider) also allows the host app to download files without presenting a document picker view controller. This feature lets the host app access previously opened documents using secure URL bookmarks, even if those files are no longer stored on the device.
On the surface this seems like a really solid solution. My main concern stems from the last couple lines where it state that the application can download the files no longer stored on the device. I want the files to be stored locally on the device to prevent constant downloading. If the Document Provider does store the files locally and allow the various applications in the group to access the files, then I think this could work.
2. Shared Keychain Access
Allows you to securely store data to a shared keychain that other applications that are part of a suite of applications can access. All applications that share keychain access must use the same app ID prefix. For an example of shared keychain access in action.
I've looked a little into the documentation of this one, and I think this might be the best fit. My major concern with this solution is whether or not there is a size limit to the data uploaded and if mp3/ogg/json file types are allowed. Most the examples/uses I have found with this solution point to sharing strings and small data, I am not sure if it will handle large data like json or audio files.
I also found this repo that apparently makes dealing with Keychain easier:
3. Custom Pasteboards
The custom pasteboard is best for the purpose of semi-privately sharing custom data between two applications. Custom pasteboards are identified using unique names. They can persist data beyond the application that creates them, allowing a pasteboard to hold onto data after the application is terminated or even after rebooting the device.
When writing or reading data to and from a pasteboard, you must specify a pasteboard type. Pasteboard types typically use a uniform type identifier (UTI) to identify the type of data going into and being retrieved from the pasteboard. See Apple’s UIPasteboard Class Reference documentation for additional information.
Above documentation pulled from this post
My main concern with this solution is that perhaps it is a bit of a hack. Logically a pasteboard seems like something that temporarily holds data and allows sharing between apps, whereas the solution I am looking for needs to be more of a permanent solution.
I'd appreciate any info on best practices towards sharing these types of files between apps. I assume there are plenty of other solutions I've omitted here, so if there is a better alternative I'd love some info on it. If it happens one of the listed solutions I have placed here is a good way to solve this problem I'd love to have some more info on your experience with working with them and if my concerns with them are valid, or nothing to worry about.
Thx in advance. As always, well written answers get up-votes ;)
I believe the best approach would be to enable data sharing by setting up an app group. This is Apple's recommended solution for sharing data between applications and extensions, and I believe for sharing data between apps in general.
See the section "Sharing Data with Your Containing App"
Also see "Adding an App to an App Group":
It is generally recommended not to store credentials in a repository. The question is, where should they be stored then, so all developers have access to the same configuration?
The question is subjective - different practices may be applied. For me, the approach that worked best is utilisation of some form of "Single Sign-On" where possible and provision of personal logins to every system to developers. This also has an advantage of being able to find out who was responsible for a destructive action (which sometimes happens).
You can also take the approach as described here: store the credentials in the SCM, but in encrypted form. This will allow to maintain versioning, yet not allow access "for everyone". I'd say, best option is to combine these two approaches (and store only developer-environment "service" credentials - encrypted - in the SCM)
I stored the config files in a private S3 bucket and manage access via IAM. The configuration updates and revisions are handled by a small script using the AWS gem. That way anybody with sufficient privileges can access them, and we also can issue access credentials for each developer separately.
I am working on an open source project that needs to authorize to a service using oAuth 1.0a. To do this the client app needs to obtain a "key" and a "secret" that is used as part of the authorization handshake.
Question: Is it safe to check these tokens into my SCM? If not, how should I handle this?
Update: The keys I'm referring to here are application specific and the service they are for is copy
It really depends on how secret the keys are.
If they're tied to a user account like for AWS, then I would say to absolutely not include them in the SCM. In that case, the app should check the environment variables to load a key file from the user's directory.
If they're more designed to be per app, then it would reasonable to include the key in the source tree.
Now, if you're developing a library. It would reasonable to include your key in the source tree under the tests but not to include it the binary distributions.
One thing I will suggest, is that you put the key under different copyright terms than the rest of the library. That way, if someone forks your code, you can force them to get their own key.
I'm looking at some (PHP) Frameworks, and I just noticed this in the Laravel documentation:
Like most web-development frameworks, Laravel is designed to protect your application code, bundles, and local storage by placing only files that are necessarily public in the web server's DocumentRoot. This prevents some types of server misconfiguration from making your code (including database passwords and other configuration data) accessible through the web server. It's best to be safe.
I'm familiar with CodeIgniter and CakePHP, as far as I know, these two frameworks don't do this. Should you really split it up and place your core logic outside of the webroot? In my experience, most clients use shared hosting and are not able to change their VirtualHost settings.
What kind of misconfiguration could you possibly do that would output your passwords? When developing, should you really do this?
Yes, keeping only those files which should be publicly accessible in DocumentRoot is a best practice for web application security. Consider:
Every file which is private would need a rule configured with the web server to explicitly block it.
Anyone adding files to the project needs to consider web server security settings. Simply keeping the files in separate directories makes it obvious what's public. And developers don't need to change security configurations.
Separating executable code and static files is a good practice anyway.
Not blocking access to PHP scripts can cause unintended consequences. For example, you may have a script to update some DB records when run manually at the command line, so someone simply guessing a script name can run it over the internet.
Monitoring for and cleaning malicious code written to the public directory is much easier if the real application logic is elsewhere. See Wordpress breakins for an example.
CakePHP supports this - see deployment:
CakePHP applications should have the document root set to the
application’s app/webroot. This makes the application and
configuration files inaccessible through a URL.