I was assigned an app testing job by the product manager (in other words, why is the product manager assigning the job, am I not under the supervision of the chief technology officer), including Android and ios, a bit confusing, agreed web penetration testing and server As for terminal penetration testing, although it is confusing, but with my strong self-learning ability, with the following article, if a worker wants to do a good job, he must first sharpen his tools. Organize your thoughts first, and penetrate them so that you can go smoothly and not get confused.
Security Threat Analysis :
For app penetration testing, the source of threats is nothing more than three aspects:
In fact, the web side seems to be the same in these three aspects.
The main risks faced:
client:
- decompile
- debugging
- Encryption/signature cracking
- input record
- export components
- process injection
- ...
data transmission:
- information leakage
- transmission data tampering
- replay attack
Server:
- hard work
- ST2
- injection
- Cross Station
- ultra vires
- Upload Download
- weak password
APP security test content:
and server and business logic security
Security testing process:
Key Points of Mobile APP Security Testing
Key points of safety inspection:
Allowbackup Vulnerability
The allowBackup attribute value in the AndroidManifest.xml file is set to true. When the allowBackup flag is true, the user can back up the application data through adb backup, and all data stored in the application can be exported without root, resulting in serious leakage of user data.
Repair suggestion:
Set the parameter android:allowBackup attribute to false, and application data cannot be backed up.
WebView Vulnerability
There is a WebView vulnerability in the application, and there is no restriction on the method call of the registered JAVA class. As a result, the attacker can use the reflection mechanism to call any other unregistered JAVA class, and finally cause the javascript code to conduct arbitrary attacks on the device.
Repair suggestion:
Replace addjavascriptInterface by declaring a @JavascriptInterface on the Java remote method;
When using the bridge of js2java, it is necessary to verify each incoming parameter and block the attack code;
Note: Control relevant permissions or try not to use the bridge of js2java.
Clear text transmission of key data
During the login process, the application uses the http protocol to transmit the user name and password in clear text, and does not encrypt the user name and password. User names and user password data can be intercepted by monitoring network data, resulting in leakage of user information and bringing security risks to users.
Repair suggestion:
Sensitive information should be encrypted when transmitting it.
Any account registration
Use the mobile phone number 177******706 to register an APP and get the verification code 38091;
When confirming the submission, intercept the request and modify the registered mobile phone number to register any account. Here, it is modified to 1338*****678 (any mobile phone number);
Use 177******706 and 133******678 (any mobile phone number) to log in respectively, and you can log in through verification and see the final result.
Repair suggestion:
When confirming the submission at the end of the registration process, the server should verify whether the submitted account is the mobile phone number that issued the verification code.
The login interface can be hijacked by phishing
The application has the risk of phishing and hijacking. The application has no anti-phishing hijacking measures. By hijacking the login interface of the application, the user's account number and password can be obtained, which may lead to the leakage of user account information.
Repair suggestion:
The application program itself judges the program currently running in the system by obtaining the activity on the top of the stack. Once it finds that the application is switched (possibly hijacked), it will give the user a prompt to prevent the fraud of the phishing program.
Get the activity at the top of the stack (as shown in the figure below). When switching sensitive activities (login, transaction, etc.), judge whether it is still in the original program. If not, give the user a prompt through Toast.
Use HTML5 architecture or android+HTML5 mixed development to realize key pages such as login and payment, and reduce the risk of being hijacked.
Typical Security Vulnerabilities of Mobile Apps
In the penetration testing of mobile APP, the blogger summarized several common mobile APP security vulnerabilities, including graphic verification code logic backdoor, leakage of user sensitive information, and penetration of developers. App development engineers, you need to pay attention.
Graphical captcha logic backdoor
Case overview
Company A is a listed information technology company, and many domestic commercial banks are its customers. When analyzing the mobile banking products of Company A, it was found that there is a logical backdoor in the graphic verification code mechanism of the product that can be bypassed, and a large number of user accounts can be stolen by exploiting this flaw. We have reproduced this security problem in the mobile banking systems of at least two commercial banks due to code reuse by outsourced teams.
Consequences: Large-scale account brute force attack.
Generally speaking, most users are accustomed to setting the mobile banking password to six digits, and there is a high probability that the query password and transaction password are set to be the same. Attackers can look up the range of mobile phone numbers in the area as the login user name, use a six-digit password dictionary for brute force cracking, and hundreds of thousands of mobile bank account information are at their fingertips.
Leakage of sensitive user information
Case overview
Company B is also a listed technology company with financial customers all over the country. Customers using Company B's mobile banking solution include at least two national joint-stock commercial banks and a number of city commercial banks. When analyzing the security of Company B's mobile banking products, it was found that the debugging interface of the server was not closed, resulting in the leakage of a large amount of user sensitive information. This kind of problem is actually quite common, and it is often caused by negligence in the online process after the outsourcing development is completed. In fact, a more common example is the problem that the Android client outputs debugging information through logcat.
The debugging interface will output the detailed information of user transfers to the test.log file in the web directory . Attackers can directly access this log file through a browser, and every transfer transaction of the system is recorded in it, from which a large number of user account numbers, mobile phone numbers, card numbers, and transaction passwords can be obtained.
The developer is infiltrated
Case overview
A domestic vulnerability platform once exposed such a vulnerability: there is a txt file in the mobile banking ios client of a large bank, which stores the ip address, user name and password of an svn server. After the hacker decompresses the file and obtains the information, he can Connect directly to and checkout files on the server.
The content stored on the svn server includes all project documents of the bank's mobile banking system, complete Android and IOS client codes, and even digital certificates for client signatures.
This article is summarized and organized after studying other articles on the Internet for reference at work. The specific penetration tool tutorial will be updated next time.
Finally, a modest effort
Thanks to everyone who read my article carefully, although it is not a very valuable thing, if you can use it, you can take it away:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends . This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can help you too!
Information acquisition method:
