App security issues
With the maturity of mobile operating systems are maturing and App development process, security issues App to get more and more attention, a lot of security issues while App is exposed, among Android staggering, such as App decompiled placement, App easily get caught, simulation App crawling data server, and so on. Now Android App developers to develop a time, want to achieve more than just functional, but to think about how to develop a secure application.
Spent two days reading the “Building secure Android App” a book, the book referred to in general terms about Android security aspects, most cases are encountered in the development of our everyday, maybe you noticed that some aspects Maybe some of you have not noticed aspect. According to some of these points mentioned in the book combined with the author in recent years the development of perception, then summarize some security on Android App experience.
Android App security experience
First clear that the so-called safety, is a relative concept, and there is no absolute security. For a App, if hackers have enough time and firm enough, he can break all the App, so we can do is let the App relatively more secure, or to increase the difficulty of the application is cracked. The following experience in alphabetical order:
- It is protected from the code level, such as the use obfuscator obfuscated code. Note that to select the appropriate level of confusion and confusion, and make sure to upload their own market before APK decompile it, check whether the code obfuscation play a role. Code obfuscation is only guaranteed APK decompile see is meaningless code, increase the difficulty of understanding, but it does not prevent the disassembled code more difficult to understand than good Smail decompile get the most. But Smail has its grammar, it can still be cracked.
- Use NDK, certain critical logic or rules, such as the core algorithm, encryption rules in C or C ++ to achieve, which can greatly increase the difficulty of code has been broken. But there is no absolute security, C or C ++ code can be decompiled though, but can be disassemble, hackers can still read binary files, met experts still powerless. Once we App encryption algorithms written in C or be broken, and also heard a master is how to break someone else’s algorithm library, one foot in mind, that’s another game.
- Of resources confusion, we generally due to resource naming rules and have a specific meaning, hackers often confused and a bad start because of a code, which changed from a resource file as a breakthrough. Principle resources confusingly similar with code obfuscation, is the original name to a meaningful meaningless names, such as home.xml become a.xml, originally home to see that this is related to the layout, and increased confusion after difficulty understanding.
- APK for reinforcement, in order to prevent decompilation. There are many third-party encryption tools, there are also free of charge. If you have the ability and energy to develop their own proposals, using third-party tools, at least I personally would not worry.
- Do App sensitive information stored in external memory, because the SD card is that everyone can access. App preferably present private directory, the most perfect practice is to never save any data on the client, it is stored in the cloud.
- Use communicating with the server as possible HTTPS, and do the real host authentication and certificate verification, to prevent the middleman attack, ensure data communications security, such things only makes sense if all the data in the cloud.
- Do not store or local database client SharedPreferences critical data stored in plain text, estimated that many applications of user names and passwords are stored in clear text in the client, be sure to encrypt the text talks about the keys to encrypted.
- Using an encryption algorithm that already exist, and not to write their own one already proven better than the unproven fly.
- All possible encryption using asymmetric encryption, encryption keys, it is best not stored locally, if stored locally, it must have possession of some hidden, or write C or C ++, but also to find only a matter of time.
- For inter-process communication, radio reception, interprocess implicit Intent call, be sure to pay attention to the permissions and security settings to prevent the disclosure of information or data.
- Using SQL parameterized queries, avoid SQL injection.
- App permissions required to minimize the demand, do not apply unnecessary privileges, because the more authority, App more secure. There is a very good program as a way to reduce the use of Intent to apply for permission, such as call, eliminating the need to apply for permission can Intent solely by calling the system dialing.
- When you use a third-party SDK, be sure to do the investigation, find out whether the SDK contain unsafe factors, such as its geographical location or App secretly collect user critical information in the background, and even do things other people can not see. Even if manufacturers provide SDK we can not believe, according to the domestic industry situation, you know. By a third-party SDK requires permission to preliminary judgment, if it requires a lot of functions unrelated to their expressed permission, then you have to look up. If the third library is open source, the source code must be read, if the non-open source, you can try to decompile third-party libraries, try searching for suspicious strings.
- Good safety verification, not only the client, but also at the same time do a good job in the service end of the two-pronged approach. As far as possible using the device ID, Device Mac address, device model, brand name and other information to assist the user password authentication.
- Be sure to check the service side of work to do, try to avoid additional exposure RESTful API, because the API unity rule is easy to implement in a post that other invasive.
- Upon request, the server needs to determine the number or type of request for access to a single IP interval and number of times, as frequently accessed data may be considered to be crawling and block the IP.
- The server should be agreed with the client requests validation rules, such as the use of a random number mechanism to prevent replay attacks on the server implementation.
- Android in the development process, learn to use Lint tool, be sure to pay attention to the security classification of warning.
If each of the above experience, then go into detail, is a big topic, the limited space did not elaborate on the reasons for this embodiment, welcome to discuss the message. Due to limited personal experience listed above is only temporary thought, must be an omission also welcome to share complementary strategies and programs for Android App security, the last hope we can develop a safe App.