The Everyplay Integration guide mentions that there's differing behavior between the development and production environment (https://developers.everyplay.com/doc/Everyplay-integration-design-guide#tip-3-enable-facecam-for-live-commentary). Is there a way to turn on the Production version while testing?
I'd like to see what my players will eventually see to make sure there are no last second bugs.
The mention of live facecam restrictions in the integration best practices document is just that, a best practice. There is no technical restriction to recording the FaceCam automatically every session, but our guidelines restrict this - the feature needs to be opt-in only!
Live Facecam can also be used as a tool for QA to allow testers to record the comments on the go, and therefore it may be useful to automatically record the forward-facing camera on each session, but this is not an option for AppStore distributed games. Therefore we make the distinction in the docs about the differences in integration in development vs. production, but as said, there is no technical difference here.
Related
I am working on an app. Say, it should be secure and safe for the end user, to the degree of a matter of life and death, in the most extreme case. In reality, it's not so hard but, let's assume it.
Thus, I want to make sure, that if serious bad guys get this iPhone and do their tricky work to disassemble it, jailbreak, whatever to get the data from the app, then they get as least clue as possible.
I want to build, test the app and its environment the safest way.
The questions are:
Are there official tools from Apple or other sources to test not
only the app itself but all the security stuff?
How much should I be worried about bad guys gaining access to the
filesystem? How can I prevent data revealing?
How reliable, e.g. backdoorless are existing encryption libraries?
For help with security testing an iOS app, I would recommend checking OWASP's Mobile Security Project. There are a lot of resources about common vulnerabilities in mobile applications, but also guidance on the steps to test a mobile application.
For your specific questions:
XCode has a built-in Analyze feature that looks for problems within the source code of your application. This is a form of static analysis. There are third-party tools that help with dynamic analysis, testing the running application. OWASP ZAP and Burp Suite are examples of tools in this category.
If a user has a jailbroken phone, they'll like have access to the whole filesystem. It's also not possible to protect completely against reverse engineering. This post from the Information Security community might be helpful in that regard. You can however limit the sensitive information you store on the device. Be careful about what information is stored in log files, cached files, plist files, basically anything stored on the device. If the information is very sensitive, it might be better to store it on the server rather than device, since you own the server and don't have direct control over a user's device.
I would consult the Developer's Guide to Encrypting and Hashing Data as well as the iOS Security Guide. I don't know about specific encryption libraries, but in general the most common problem is poor implementation of encryption libraries rather than problems with the libraries themselves. Also, generally using existing libraries is a better practice than trying to create your own.
I'd also consult the Information Security Community, they'll have more guidance on how to security test iOS applications.
I am planning to build an iOS app with react native and I am super excited to do so.
Unfortunately the deadline is quite short, so I am considering to use an approach like this, which hosts the app bundle in the cloud for the production build of the application.
This may be beneficial, as an api will be build for the app and I could simply change the code of the deployed app if the api behaves otherwise than previously assumed.
As this seems like a good idea on first thought and I am quite sure it is a good idea in terms of testing and continuous delivery I am not sure if this works out in production and if the application will be accapted by apple.
So my question is if such an application would be approved by apple and if this kind of structure provides any problems on the users devices.
Yes, this tends to be good idea. Usually, application stores a lot of data (authentication, user data and so on) on it's own servers.
I'm working on a web application and we are getting ready to launch it. Because it will hold sensitive data for users, I want this to be as secure as possible. Here is a list of what we are currently doing...
Running the app on Heroku (Ruby on Rails)
Site is encrypted with 256 SSL (with forced SSL turned on)
Cookies are encrypted and we pass the Firesheep test
Their password and everything in the database is one way encrypted.. so even if someone got access to the database it would be useless.
We do not store any keys or passwords openly in the source code but rather use Config Vars
Other than that what else should/could we be doing. We are considering McAfee's site scan but they quoted us $2,500 a year. I'm not sure it's worth it.
Does anyone have any suggestions at all?
Make sure to read the OWASP Top 10. Also $2,500 is a rip off, Sitewatch is free. You should also consider running a Web Application Firewall like mod_security, but keep in mind this will cause problems for testing tools like McAfee or Sitewatch. You should configure mod_security to allow specific ip addresses. Or test your application before enabling the WAF.
After ruling out the usual suspects (XSS, SQL injection, mass assignment, etc), client side is where most problems come from, and this is often overlooked. I don't know what your site is about, but things like telling your users that they shouldn't follow links on emails they did not explicitly request usually delivers highest bang-for-the-buck.
Best regards,
-- J. Fernandes
I'd recommend checking out the OWASP Top 10: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf
The OWASP Top Ten provides a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.
To verify your SSL configuration, you can try https://www.ssllabs.com/ssldb/index.html.
If you're curious about the sheer variety of attacks, check out Jeremiah Grossman's post titled Top Ten Web Hacking Techniques of 2010 and scroll down until you see "The Complete List".
If you want to fire off a few web app vulnerability scans tools to catch the low hanging fruit you can try:
skipfish: http://code.google.com/p/skipfish/ (free)
netsparker community: http://www.mavitunasecurity.com/communityedition/ (free)
look here for more https://security.stackexchange.com/questions/32/what-tools-are-available-to-assess-the-security-of-a-web-application/
If you're really concerned about security then adopting a secure development plan and working with someone trained in app security would obviously boost your confidence things are being done right.
Regarding development, you may like the ideas presented in Microsoft's simplified SDL:
"The Security Development Lifecycle (SDL) is a security assurance process that is focused on software development."
"The process outlined in this paper sets a minimum threshold for SDL compliance. That said, organizations aren’t uniform – development teams should apply the SDL in a way that is suitable to the human talent and resources available, but doesn’t compromise organizational security goals."
Also it is important to note automated vulnerability scan tools fail to identify most logical vulnerabilities so don't rely solely on automated tools. For example (taken from OWASP):
"Setting the quantity of a product on an e-commerce site as a negative number may result in funds being credited to the attacker. The countermeasure to this problem is to implement stronger data validation, as the application permits negative numbers to be entered in the quantity field of the shopping cart."
Human intelligence is key to spot logical issues.
Security is also all about maintenance. Assigning someone or a team the responsibility to astutely play continuous defense is important.
Note: Encrypting the passwords doesn't imply infallible security. Dictionary/password lists/brute force attacks work all the time to reveal weak passwords. A very common attack is to use SQL injection to dump the user table (with password hashes) then use a password cracker to discover legitimate user/password pairs.
You can find information about common Ruby on Rails application vulnerabilities and their countermeasures at the Zen Rails Security Checklist, including most of the OWASP Top 10 items.
We've got an Excel spreadsheet floating around right now (globally) at my company to capture various pieces of information about each countries technology usage. The problem is that it goes out, gets changes, but they're never obvious, and often conflicting - and then we have to smash them together. To me, the workbook is no more than a garbage in/garbage out type application waiting to be written.
In a company that has enough staff and knowledge to dedicate to Enterprise projects, for some reason, agile and language/frameworks such as Rails, Grails, etc. are frowned upon. That said, I can't help but think that this is almost a perfect fit for the need, given the scaffolding features for extremely simple implementations of capturing raw fields with only a couple lookups (i.e. a pre-defined category). I'm thinking this would be considered a very appropriate use of these frameworks.
Has anyone worked on these types of quick and dirty apps before in normally large-scale, heavy-handed enterprise environments with success? Any tips for communicating this need/appropriateness to non-technical management?
The only way to get this implemented in a rigid organization is to get this working and demo it -- without approval. It's very hard for management to say no to a finished project.
I work for a really big company & have written many utility apps based on Rails (as well as contributed to some larger Rails projects). That said, the biggest concern is not the quality of the app, but who's going to support/maintain it when you leave or get hit by the bus.
IMHO, The major fear that an enterprise organization has - especially if the application becomes more critical to it's core business - is how to support it. If it doesn't fit into it's neat little box of supported technologies, it's less likely to happen.
Corporations have been bitten by this many times in the past & are cautious when bringing in new technology.
So, if you can drum up more folks to learn Ruby/Rails in your group (or elsewhere in your company), you may be able to make a good case for it. Otherwise, sad to say, your probably better off implementing something on Sharepoint :-(.
If you already have a Java infrastructure, then creating a Grails app will require little to no additional IT ramp up to support and maintain. The support and maintenance cost and effort should be the same as for a Java application (i.e. Grails apps run on Tomcat, use the same JVM, use the same diagnostic/profiling tools, etc.).
In my experience, larger IT organizations have a harder time supporting Ruby when its not already in the toolchain because its a new language, new deployment environment, and requires a considerable amount of support and maintenance ramp up.
I would develop a minimal viable product, then make friends with someone in IT who can help you deploy it into a staging or production environment. Then get a few of the users to hop on board and test it like its a Beta product. After that, open it up to a larger audience.
So as others have said, forgiveness over permission, but be smart about the impact on the IT organization.
Many of you guys agree that the developers should not have write access to production servers (ie this question). In a such environment, who publishes a public-facing application/service/data? the testers?
We also have a small release team with special priviledges. They are out of the dev team, even though they are tecnical people.
A release is made of (if nok, any phase can be a stopper):
build a version
assemble a "what's new"
publish it internally for all sorts of tests, manual or automatic
access production databases to change run some scripts,
deploy the application in production,
make some minimal tests,
receive the customers complains
Most of the time, all the job is done by one person (another one is available as a backup).
The point of this is:
The same guy is less likely to make the same mistakes several times, he learns from mistakes.
This guy cannot shift the responsibility to someone else, so he really makes sure it will work.
This guy is not thinking about all the new exciting features that have been developped in that version, he doesn't even care. His focus is "what did they do this time that will break and get me in trouble :-(!". He is a counter-power actually, to the project managers that want theirs features delivered as soon as possible, and to the developpers that want all that fancy new code that is so cool!
At my company, we have a dedicated release engineering team that handles all deployments. Ideally, there is a disciplined process of review and testing that is followed, and the RE team can help ensure that actually happens.