Shulou(Shulou.com)06/01 Report--

1 Security risk Analysis of Mobile APP 1.1 Security threat Analysis

Security threats are divided into three different links, which are mainly divided into client threats, data transmission threats and server threats.

1.2 main risks faced

1.3 Android test mind map

1.4 decompilation tool

There are two decompilation methods, dex2jar and apktool, the two tools decompile the effect is not the same, dex2jar decompiled into java source code, apktool decompiled out of java assembly code.

Dex2jar is mainly used to convert classed.dex extracted from zip into jar package.

Jd-gui is mainly used to open Jar packages.

2 Local client Security 2.1 decompilation Protection 2.1.1 problem description

APP source code is a very important information resource for a company, and the protection of APP is particularly important. The decompilation of APP will cause the source code to be read by malicious people, as well as the logical design of APP.

ZD decompilation method

Generally speaking, when we want to decompile an apk, we just want to get three things: picture resources, XML resources, and code resources.

one。 Acquisition of picture resources

First of all, prepare an apk, here is a .apk suffix file, we first change the suffix to, zip, open the zip file in the res directory, we can get the pictures we need.

two。 XML resource acquisition

We can just open the zip file directory to see a lot of .xml files, this xml file can not be opened directly, when you try to open it is garbled or blank, then how do we get this xml resource, then we need to use a jar package, that is, axmlprinter2.jar, this thing you as long as Baidu, you can find. Then you put it in the same directory as the xml you extracted, and use the cmd command to find this directory.

My example here is to put the xml on the E disk. According to the situation, cd to the directory extracted by yourself, and then execute

Java-jar AXMLPrinter2.jar xxxxx.xml > xxxxx.txt

That's when you can get what's in xml.

three。 Code resource acquisition

This is the top priority, and this is what we mainly want to get. But there is a point. The only code that can be decompiled correctly is unencrypted or unconfused code. If we want to decompile some encrypted or confused code, we need other ways to solve it.

First of all, you need to prepare two things: dex2jar.rar and jd-gui.zip.

Dex2jar is mainly used to convert classed.dex extracted from zip into jar package.

Jd-gui is mainly used to open Jar packages.

Dex2jar usage:

After decompressing the dex2jar, put the classes.dex of the previous zip into the dex2jar directory

Note that it must be at the same level as dex2jar.bat.

Then use cmd,cd to the dex2jar directory and type the command line

Dex2jar.bat classes.dex

Then there will be an extra jar package in your directory.

There is an extra classes-dex2jar.jar file.

Then the jar package was opened with jd-gui, and finally the apk code was stripped out.

2.1.2 Detection method

Use decompilation tool to see if APP can be decompiled.

2.1.3 repair method

Encryption and obfuscation techniques are used to achieve decompilation protection.

The function of confusion technology is to make it more difficult for users to read the code after decompilation.

2.2 APP secondary packaging 2.2.1 description of secondary packaging

"Android APP secondary packaging" is a pirated regular Android APP, which is repackaged with malicious code after cracking. In terms of performance, user experience and appearance, it is exactly the same as a regular APP, but behind it is running terrible programs that unwittingly waste mobile phone power, traffic, malicious deductions, privacy peeping, and so on.

In the face of secondary packaging, many companies have their own preventive measures. Almost all the APP of well-known companies have done their own processing within the program to prevent their APP from being re-packaged. Once the package is re-run, the program automatically exits. Next, I'll explain in detail how to prevent APP from being repackaged.

In order to achieve the internal code to prevent APP from being re-packaged, we must first understand the machine recognition principle of APK. The only identification of APK depends on the package name and signature. Security software such as pea folder wash white, Mobile guard and other security software to identify APK copycat, they rely on the package name to determine the APK and then through the signature to determine whether it is a fake. So at startup, your own program can identify whether it has been re-packaged by obtaining the signature of APK itself and comparing it with the correct signature.

2.2.2 Anti-secondary packaging detection method

Use the secondary packaging tool for secondary packaging of APP to see whether the APP can be successfully packaged and run. If you can't run the program after repackaging, there are security measures to prevent secondary packaging.

2.2.3 Anti-secondary packing repair method

Using the method of signature protection: obtain the signature of APK after secondary packaging and compare with the correct APK signature to determine whether the APK program has been re-packaged.

Suggestion: the client uses the subordinate certificate for signature instead of the certificate of the third-party developer for signature, in case the developer's internal supervision is abnormal and the certificate is abused.

2.3 component Export Security 2.3.1 description of the four components

Android mainly consists of four components, namely, activity component, service component, content provider component and broadcast receiver component.

Zero Activity component

An Activity is usually a separate screen (window).

(2) Activity communicate with each other through Intent.

(3) every Activity in the android application must be declared in the AndroidManifest.xml configuration file, otherwise the Activity will not be recognized or executed by the system.

Zero Service component

(1) service is used to complete user-specified operations in the background.

(2) developers need to declare all service in the application AndroidManifest.xml configuration file and use tags.

(3) Service usually runs in the background, and it generally does not need to interact with the user, so the Service component has no graphical user interface. The Service component needs to inherit the Service base class. Service components are usually used to provide background services for other components or to monitor the running status of other components.

Zero Content Provider component

(1) the android platform provides Content Provider to provide a specified dataset of one application to other applications. Other applications can obtain or store data from the content provider through the ContentResolver class.

(2) content providers are needed only if you need to share data among multiple applications. For example, address book data is used by multiple applications and must be stored in a content provider. Its advantage is to unify the way to access data.

(3) data sharing is realized by ContentProvider. ContentProvider is used to save and retrieve data and make it visible to all applications. This is the only way to share data between different applications because android does not provide a common storage area for all applications to access.

Dead broadcast receiver

(1) your application can use it to filter external events and only receive and respond to external events of interest (such as when a phone call comes in, or when a data network is available). The broadcast receiver has no user interface. However, they can launch an activity or serice to respond to the information they receive, or use NotificationManager to notify the user. Notifications can attract users' attention in many ways, such as flashing backlights, vibrating, playing sound, and so on. Generally speaking, you can put a persistent icon on the status bar so that the user can open it and get the message.

(2) there are two ways to register the broadcast receiver, namely, dynamic registration of the program and static registration in the AndroidManifest file.

(3) dynamic registration of broadcast receivers is characterized by the fact that when the Activity used for registration is turned off, the broadcast becomes invalid. Static registration does not need to worry about whether the broadcast receiver is turned off, as long as the device is turned on, the broadcast receiver is also open. That is, even if the app itself is not started, the broadcast of the app subscription will have an effect on it when triggered.

Summary of the four components

(1) Registration of 4 major components

The four basic components need to be registered before they can be used, and each Activity, service, and Content Provider need to be configured in the AndroidManifest file. Activity, services, and content providers that are not declared in the AndroidManifest file will not be visible to the system and therefore will not be available. The registration of the broadcast receiver broadcast receiver is divided into static registration (configured in the AndroidManifest file) and dynamically created by code and registered to the system by calling Context.registerReceiver (). It is important to note that broadcast receivers configured in the AndroidManifest file will be active as the system starts, triggering whenever a broadcast of interest is received (even if the program is not running).

(2) Activation of 4 major components

Activation of the content provider: when a request from ContentResolver is received, the content provider is activated. The other three components, activity, service, and broadcast receiver, are activated by an asynchronous message called intent.

2.3.2 component security check method 1. Set android:exported to true in the activity component in the AndroidManifest.xml file, indicating that this component can be called by external applications.

2. Set android:exported to false in the activity component in the AndroidManifest.xml file, which means that this component cannot be called by external applications. Only components of the same application or applications with the same user ID can

3. The android:exported property is not set in the activity component in the AndroidManifest.xml file, but if there is intent-filter, the default property of exported is true,true, which means that the component can be called by external applications.

4. If the android:exported property and intent-filter are not set in the activity component in the AndroidManifest.xml file, the default property of exported is false,false, which means that the component cannot be called by external applications. Only components of the same application or applications with the same user ID can

Note: the drozer tool can be used to detect whether the component has export risk.

2.3.3 repair recommendations

(1) if the applied Service component does not need to be exported, or if the component is configured with an intent filter tag, it is recommended that the "android:exported" attribute of the component should be false.

(2) if the component must be provided to the external application, it is recommended to control the permission of the component.

2.4 Webview vulnerability 2.4.1 WebView arbitrary Code execution vulnerability 2.4.1.1 description there are three reasons for this vulnerability

AddJavascriptInterface () interface in WebView

WebView built-in exported searchBoxJavaBridge_ object

WebView built-in exported accessibility and accessibilityTraversalObject objects

A remote code execution vulnerability is caused by the @ addJavascriptInterface interface.

One of the ways JS calls Android is to do object mapping through the addJavascriptInterface interface. When JS gets the Android object, it can call all the methods in the Android object, including the system class (java.lang.Runtime class), and execute arbitrary code.

A remote code execution vulnerability is caused by the @ searchBoxJavaBridge_ interface.

Below Android 3.0, the Android system adds a JS mapping object to WebView through the Js interface of searchBoxJavaBridge_ by default: searchBoxJavaBridge_ object

This interface may be used to implement remote arbitrary code.

A remote code execution vulnerability is caused by the 0.accessibility and accessibilityTraversal interfaces.

The problem is similar to the above.

2.4.1.2 remote code execution vulnerabilities caused by the detection method, the interface of the zub addJavascriptInterface.

Check for object mapping through the addJavascriptInterface interface

A remote code execution vulnerability is caused by the @ searchBoxJavaBridge_ interface.

Check whether to add a JS mapping object to WebView through the Js interface of searchBoxJavaBridge_

A remote code execution vulnerability is caused by the 0.accessibility and accessibilityTraversal interfaces.

The problem is similar to the above.

2.4.1.3 Fix the vulnerability of remote code execution caused by the recommended addJavascriptInterface interface

B1. After Android version 4.2

Google specified in Android 4.2 that the called function be annotated with @ JavascriptInterface to avoid the vulnerability.

B2. Prior to Android version 4.2

Prior to Android 4.2, the vulnerability was fixed by intercepting prompt ().

A remote code execution vulnerability is caused by the @ searchBoxJavaBridge_ interface.

Delete searchBoxJavaBridge_ interface

/ / delete the interface by calling this method

RemoveJavascriptInterface ()

A remote code execution vulnerability is caused by the 0.accessibility and accessibilityTraversal interfaces.

Delete accessibility and accessibilityTraversal interfaces

2.4.2 description of password plaintext storage vulnerability 2.4.2.1

WebView enables password saving by default:

MWebView.setSavePassword (true)

When enabled, when the user enters the password, a prompt box will pop up: ask the user whether to save the password

If you choose "Yes", the password will be explicitly protected into / data/data/com.package.name/databases/webview.db, so there is a risk of password theft.

2.4.2.2 Detection method

Method 1, when the user enters the password, look at whether there is a pop-up prompt box and ask the user whether to save the password. If there is a query, it means that there is a loophole, otherwise it does not exist.

Method 2. Check whether the value of setSavePassword in the code is false.

2.4.2.3 repair recommendations

Turn off password save reminder

WebSettings.setSavePassword (false)

2.5data Security-Local sensitive Information Security 2.5.1 File permissions in the same directory as APP 2.5.1.1 problem description

Test whether the file permissions of the client APP directory are set correctly, and whether non-root accounts can read, write, and execute files in the APP directory.

2.5.1.2 Detection method

Use ls-l to view the file permissions of the app directory, and other group members are not allowed to read and write permissions. The Linux file permissions are the first for the owner of the file, the second for the other members of the owner's group, and the third for the other group members.

2.5.1.3 repair recommendations

Check the directory where App resides. Its permission must be that other group members are not allowed to read and write.

2.5.2 Security of SQLite database files 2.5.2.1 description

SQLite, a lightweight database, is an ACID-compliant relational database management system. Is an open source, efficient, embeddable and program-driven database.

As we all know, the Android system has a built-in SQLite database and provides a complete set of API for adding, deleting, modifying and querying the database. Database storage is a storage method that we often use. I believe most friends are already familiar with how to use it. In Android, we can use native SQL statements to operate on the data, or we can use the CRUD method provided by Android API to operate on the database. The two methods have their own characteristics, and it is up to personal preference to choose which one to use.

However, there is a problem with using SQLite to store data. Because most Android phones are Root, and Root phones can go to the / data/data//databases directory, where you can see all the data stored in the database. If it is general data, but when it comes to some account passwords, or chat content, our program will face serious security vulnerabilities.

2.5.2.2 Detection method

After root, check the database file under / data/data//databases to see if it contains sensitive information.

2.5.2.3 repair recommendations

Encrypted storage of important information

2.5.3 Logcat log 2.5.3.1 description

Detect whether the Logcat log corresponding to the client will print some sensitive information about the user or server.

2.5.3.2 Detection method

Connect to your phone through usb, and then use adb logcat-v time > d:\ xx to get logcat information.

Or use the DDMS tool to view logcat information.

2.5.3.3 repair recommendations

Debug information switches with sensitive information must be turned off.

For Android developers, to solve the problem of sensitive information is to encrypt and store important data, and log logs do not print sensitive information. Remember not to store sensitive information such as account passwords in local plaintext. If you must store sensitive information, you must encrypt and store important information.

2.5.4 sensitive data is stored in plaintext in Sdcard2.5.4.1 description

Android provides several options for persisting application data, one of which is external storage (/ sdcard, / mnt/sdcard). External storage includes miniature or standard-sized SD cards inside the device, Android device memory cards mounted to the PC, and the Android/obb directory.

In previous versions of Android4.1, files stored externally were world-readable (which can be read by any user) and world-writable (which can be written by any user). From Android4.1 to Android4.3, when an app wants to write to any file stored externally, it simply declares WRITE_EXTERNAL_STORAGE permissions in the AndroidManifest file. However, starting from Android4.4, creating groups and file patterns based on directory structure are introduced, which makes an app in external storage have read and write access to files only under a directory named by its own package name. Non-system-level app is only allowed to operate under the Android/data// directory. Therefore, the file read and write permissions of each app are independent and cannot access each other.

Due to the inadequate access restrictions described above, files written to external storage may be at risk of being modified and read by different app on the same device (previous versions of Android4.4).

2.5.4.2 Detection method

Check to see if there is any code to write to the external storage device.

2.5.4.3 repair recommendations

Encrypt the contents of the file before saving it to external storage.

2.6 Keyboard Security risk 2.6.1 Keyboard hijacking Test 2.6.1.1 description

The input boxes in Android applications use the system soft keyboard by default. After the phone is installed, × × can record the password of the application by replacing the system soft keyboard.

2.6.1.2 Detection method

By observing whether app will pop up the custom soft keyboard where you enter the password.

2.6.1.3 repair recommendations

It is recommended that the client develop a custom soft keyboard instead of using a system software disk to prevent keyboard hijacking.

2.6.2 Security Test of soft Keyboard 2.6.2.1 description

Test whether the client uses a randomly arranged password soft keyboard.

2.6.2.2 Detection method

Observe with your eyes whether the custom soft keyboard that pops up randomly changes the layout.

2.6.2.3 repair recommendations

It is recommended that the client randomize the custom soft keyboard and initialize it randomly every time the input box is clicked.

2.7 screen video test 2.7.1 description

Test whether the password of the user's password input box can be captured through continuous screenshots.

2.7.2 Detection method

Whether the password of the user's password input box can be captured through continuous screenshots.

2.7.3 repair recommendations

It is recommended that the client write resistance logic for third parties or system screenshots, such as blocking functions related to screenshots or overwriting screenshots with pure black × × film objects when the client is at the top of the process stack.

2.8 Interface hijacking Protection 2.8.1 description of Interface hijacking

Activity hijacking means that when a window component is started, it is detected by a malicious application. If the window interface is a × × × object preset by a malicious program, the malicious application will launch its own fake interface to cover the original interface, and the user enters login information without noticing it, and the malicious program returns the acquired data to the server.

It is important to understand that when Android launches an Activity, it is designed to add a flag bit FLAG_ACTIVITY_NEW_TASK to the Activity so that it can be placed at the top of the stack and immediately presented to the user. But there is a flaw in such a design. What if this Activity is a camouflage Activity for account theft? This phenomenon has been proved to be achievable in XcodeGhost events.

In Android systems, programs can enumerate currently running processes without declaring other permissions, so you can write a program to start a background service that constantly scans the currently running processes and starts a camouflaged Activity when it is found that the target process is started. If the Activity is the login interface, you can get the user's account password from it, as shown in the following figure:

2.8.2 ways to prevent interface hijacking

As a mobile application developer, the easiest way to prevent APP from being hijacked by the interface is to check whether the front-end Activity application is itself or a system application in the onPause method of key Activity such as login window. If it is detected that it is not yourself, an alarm pops up or exits.

2.8.3 cases of interface hijacking

There is a risk of phishing hijacking in the app. The application does not do anti-phishing hijacking measures, through the hijacking application login interface, you can obtain the user's account number and password, which may lead to the disclosure of user account information.

2.8.4 suggestions for rectification and reform

The application itself determines the program currently running by the system by getting the activity at the top of the stack, and once it finds that the application is switched (which may be hijacked), it gives the user a hint to prevent the fraud of the phishing program.

Get the activity at the top of the stack (shown below). When it comes to sensitive activity (login, transaction, etc.) switching, determine whether it is still in the original program, and if not, give the user a hint through Toast.

Use HTML5 architecture or android+HTML5 mixed development to achieve login, payment and other key pages to reduce the risk of hijacking.

2.9 Local denial of service 2.9.1 vulnerability description

The Android system provides components such as Activity, Service and Broadcast Receiver, and provides Intent mechanism to assist the interaction and communication between applications. Intent is responsible for describing the action, action involving data and additional data of an operation in the application. According to the description of the Intent, the Android system is responsible for finding the corresponding component, passing the Intent to the calling component, and completing the component call [1]. The local denial of service vulnerability in Android applications is due to the fact that the program does not catch exceptions or malformed data obtained by Intent.getXXXExtra (). As a result, xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Scope of local denial of service vulnerabilities: all versions of Android system

2.9.2 vulnerability detection method

Scanning can be performed using the Android scanning tool.

2.9.3 repair recommendations

Recommendations for fixing local denial of service vulnerabilities:

1) set unnecessary exported components to not export

For security reasons, unnecessary components should be exported to prevent denial of service, especially for security applications such as antivirus, security protection, lock screen anti-theft, and so on. In the AndroidMenifest.xml file, set the "android:exported" property of the corresponding component to "false", as shown in the following example:

2) intent catches exceptions when processing data

It is recommended that you make the following judgments when dealing with data obtained through Intent.getXXXExtra (), and catch all exceptions by try catch to prevent a denial of service vulnerability in the application:

1) null pointer exception

2) Type conversion exception

3) array out-of-bounds access exception

4) the class does not define an exception

5) other exceptions

2.10 description of data backup allowBackup2.10.1 vulnerability

Android API Level 8 and above Android systems provide backup and recovery of application data. The switch for this function is determined by the allowBackup attribute value in the AndroidManifest.xml file in the application, whose default value is True. When the allowBackup flag is true, users can backup and restore the application data through adb backup and adb restore, which may bring some security risks.

Android attribute allowBackup security risk stems from the fact that adb backup allows anyone who can turn on the USB debug switch to copy application data from the Android phone to the peripheral, once the application data is backed up, all application data can be read by the user; adb restore allows the user to specify a recovered data source (that is, the backed up application data) to restore the creation of application data. Therefore, when an application data is backed up, the user can install the same application on other Android mobile phones or simulators, and by restoring the backed up application data to the device, opening the application on the device can restore to the state of the backed up application.

Especially for address book applications, once the application supports backup and recovery functions, × × can use adb backup and adb restore to restore the newly installed same application to view chat records and other information; for payment financial applications, × × can use this to make malicious payments, steal deposits, etc. Therefore, for the sake of security, developers must set the allowBackup flag value to false to turn off the backup and recovery function of the application, so as to avoid information leakage and property damage.

1. If the allowBackup attribute value is not set in the AndroidManifest.xml file, and its default value is true, the application can back up the data of the entire application through the adb command

Contents of AndroidManifest.xml file:

2. If the allowBackup attribute value is set to false in the AndroidManifest.xml file, that is, android:allowBackup= "false", then the Android application cannot backup and restore the data of the whole application through the adb command.

Contents of AndroidManifest.xml file:

2.10.2 Detection method

Check whether there is allowBackup in the AndroidManifest.xml file, if not, the allowBackup attribute value, the default allowBackup value is True, then the default is that you can back up application data, which is a security risk; if the allowBackup attribute value is false, you cannot back up application data.

2.10.3 repair method

Set the allowBackup property value in the AndroidManifest.xml file to false.

2.11 Debug debugging 2.11.1 description

Be sure to turn off the debug property before you are ready to release the application, that is, set the android:debuggable= "false" in AndroidMainifest.xml. False means to turn off debug debugging, and true means to turn on debug debugging, but sometimes you forget to turn it off. When Debug debugging is enabled, there is a risk that the application will be debugged.

2.11.2 Detection method

It is best to test before release, using the aapt tool:

Aapt list-v-a myfile.apk

This command will print all the details related to apk and find "android:debuggable", whose values are as follows:

0x0: debuggable false

0xffffffff: debugabble true

For example, in my test, the message on this line is:

A: android ebuggable (0x0101000f) = (type 0x12) 0x0

This means that my Release Build has turned off debuggable!

2.11.3 suggestions for repair

Shut down debuggable.

Android:debuggable=false

3 communication process security 3.1 communication confidentiality 3.1.1 using HTTPS communication 3.1.1.1 description

Verify whether the communication between the client and the server uses https encrypted channel, and using https protocol to communicate can prevent the risk of information eavesdropping during transmission.

3.1.1.2 Detection method

Grab the communication information through packet grabbing tools (such as burpsuite, fiddler) to see if the communication is encrypted.

3.1.1.3 repair recommendations

Use https for encrypted communications.

3.1.2 SSL hijacking * *-- Certificate verification 3.1.2.1 description

At present, although many Android APP use https communication mode, it is only a simple call, and the validity of the SSL certificate is not verified. Https communication only encrypts the communication channel, which can prevent the risk of monitoring data, but can not prevent the man in the middle. Through the man in the middle intercept agent, the data using https communication can be fully exposed, so that the person can use the man in the middle to intercept the agent to hijack. This loophole makes https virtually useless and can easily access the plaintext communication information of mobile phone users.

Certificate verification is to prevent the middleman from hijacking, which is divided into strong verification and weak verification. Strong verification means that the certificate of the server is pre-embedded at the means end, and the certificate is obtained when the mobile phone communicates with the server, and compared with the server certificate embedded locally by the mobile phone. If it is inconsistent, it is considered to have been hijacked by the middleman. Automatically disconnect the communication with the server. Weak verification is to verify whether the domain name of the certificate is consistent with the domain name accessed by the phone, certificate authority and other information on the mobile phone.

Strong check flow chart:

Weak check flow chart:

Scheme comparison

Scheme

Advantages

Shortcoming

Strong parity: server certificate lock

The security is the highest. To implement × ×, you must get the corresponding server private key certificate.

APP has great impact when changing certificates.

Weak check: root certificate locking + domain name verification

Replacement of server certificate will not be affected

Security is related to CA institutions and domain name verification mechanisms.

3.1.2.2 Detection method

Check whether the mobile program is running properly by grabbing the packet. If you grab the package by proxy, the APP of the mobile phone will be forced to exit automatically, indicating that the mobile APP has done certificate verification.

3.1.2.3 rectification method

Use strong check or weak check method.

3.2 access Control 3.2.1 description

Test whether the URL accessed by the client can only be accessed by the mobile client. Whether you can bypass login restrictions to directly access pages that can only be accessed after login, and whether you can bypass verification for pages that require secondary authentication (such as privacy verification).

3.2.2 Detection method

Use the package interception tool to obtain the url, and you can open the url with a browser.

3.2.3 repair recommendations

It is recommended that the server carry on the corresponding access control, and the corresponding page can only be accessed through the mobile client. At the same time, the page access control is carried out to prevent illegal access to the page directly bypassing the login.

4 Server Security 4.1 Security Policy Settings 4.1.1 password complexity Policy 4.1.1.1 description

Test whether the client program checks the password entered by the user and forbids the user to set a weak password

4.1.1.2 Detection method

When you change the user name and password, you can set 111111 similar to a weak password

4.1.1.3 repair recommendations

It is recommended to write a security policy on the server to detect password complexity and apply it to scenarios where password changes are required, such as account registration and password modification, so as to prevent people from making violent guesses by traversing accounts with weak keys.

4.1.2 Authentication failure lockout policy 4.1.2.1 description

Test whether the client limits the number of login attempts. Prevent the use of exhaustive methods to violently crack user passwords

4.1.2.2 Detection method

Incorrect password login request multiple times (there is no problem if there is no problem more than 10 times, usually 3 times)

4.1.2.3 repair recommendations

It is recommended to write the logic of the account locking policy on the server side, and lock the account when you enter the password incorrectly several times a day to prevent people from guessing the password violently.

4.1.3 single sign-on restriction Policy 4.1.3.1 description

Test whether you can log in to the same account on both devices at the same time.

4.1.3.2 Detection method

Test whether you can log in to the same account on both devices at the same time.

4.1.3.3 repair recommendations

It is suggested that the corresponding logic code should be written for account login restrictions on the server, and only one device can log in to a certain account at a time by means of Session or database flag bits.

4.1.4 session timeout policy 4.1.4.1 description

Test whether the client will time out the session and require re-login after it has no action for a certain period of time. Whether the timeout setting is reasonable.

4.1.4.2 Detection

The client has no operation within a certain period of time (20 minutes is enough), whether the session time-out login

4.1.4.3 recommendation

It is recommended that you write the logic of session security settings on the client side, automatically log out of the login state or close the client when there is no operation for 10 or 20 minutes.

4.1.5 Interface switching protection 4.1.5.1 description

Check whether the client program can respond appropriately when switching to the background or other applications (such as clearing the form or exiting the session) to prevent the disclosure of user sensitive information

4.1.5.2 Detection method

The application switches to the background but the program does not finish running, and then returns to the application whether there is authentication, gesture password or login password.

4.1.5.3 repair recommendations

It is recommended that the client add the logic of response and prompt the user to confirm whether it is his or her own operation during the process switching operation.

4.1.6 UI sensitive information security 4.1.6.1 description

Check the various functions of the client to see if there is a problem of sensitive information disclosure.

4.1.6.2 Detection method

For example, when logging in, the password is entered incorrectly, and will APP prompt the password to enter incorrectly?

4.1.6.3 repair recommendations

It is recommended that errors in user name or password prompt "wrong user name or password". If the client also wants to ensure the friendliness of customer use at the same time, it can prompt for information such as the number of errors and password security policy in the login interface through warm prompts, so as to prevent users from incorrectly entering passwords many times, which leads to account locking.

4.1.7 Security exit 4.1.7.1 description

Verify whether the client communicates with the server when the user logs out to ensure the timeliness of the logout

4.1.7.2 Detection method

The client checks to see if session is available when the user logs out

4.1.7.3 repair recommendations

Ensure that the client and server exit synchronously, and the server-side purge session when APP exits

4.1.8 password modification verification 4.1.8.1 description

Verify the security of the client when making password changes

4.1.8.2 Detection method

Whether there is original password authentication

4.1.8.3 repair recommendations

It is recommended that when changing the password, the client and server systems should add the logic of input and verification of the original password to prevent Cookie from logging in to modify the password.

4.1.9 gesture password 4.1.9.1 gesture password modification and cancellation 4.1.9.1.1 description

Detect whether the client verifies the previously set gesture password when canceling the gesture password, and detects whether there are other logical problems that lead to the cancellation of the gesture password

4.1.9.1.2 Detection method

Detect whether the client verifies the previously set gesture password when canceling the gesture password, and detects whether there are other logical problems that lead to the cancellation of the gesture password

4.1.9.1.3 repair recommendations

There should be no other logic that causes the gesture password to be cancelled, and the client should verify the previously set gesture password when canceling the gesture password

4.1.9.2 gesture password local information preservation 4.1.9.2.1 description

Detect whether the client will record some relevant information locally, such as plaintext or encrypted gesture password, after entering the gesture password.

4.1.9.2.2 Detection method

Find the storage file to see if it is encrypted

4.1.9.2.3 repair recommendations

It should be encrypted.

4.1.9.3 gesture password locking policy 4.1.9.3.1 description

Test whether the client has a security policy in which gesture passwords are incorrectly entered multiple times and locked. Prevent the use of exhaustive methods to violently crack user passwords. Because the storage capacity of gesture passwords is very small, only 9! = 362880 different gestures. If there is no locking policy in the gesture password, you can easily get the result of the gesture password. The gesture password is usually saved as a two-dimensional array of a [2] [2], which is a 3x3 array. During the data interaction between the client and the server, the numbers in this two-dimensional array are usually converted into an one-dimensional form similar to the mobile phone numeric keypad b [8], and then a series of processing is carried out to send it.

4.1.9.3.2 Detection method

Try to enter gesture password errors many times, such as 3 or 5 times in a row, to see if the account will be locked.

4.1.9.3.3 repair method

The gesture password policy recommends that you enter 3 or 5 times in a row to lock.

4.2 any account registration 4.2.1 description

Any account can be registered, resulting in the risk of non-real-name registration, malicious registrants can register a large number of accounts. A large number of accounts can be used for malicious operations such as wool.

4.2.2 Detection method

Register an APP with the mobile phone number 139 / 139 / 1234 and obtain the verification code 060503. When confirming the submission, you can intercept the request and modify the registered mobile phone number, then you can register any account. Here, you can change it to 136 mobile phone number / 5678 (any mobile phone number). Then you can log in using the 136 mobile phone number (any mobile phone number), and you can log in through verification.

4.2.3 repair recommendations

When the final confirmation is submitted during the registration process, the server should verify whether the submitted account is the mobile number from which the CAPTCHA is issued.

4.3 SMS playback × × 4.3.1 description

Detect whether there is a security problem of packet playback × × in the application. Whether it will cause a bombardment of text messages to client users.

4.3.2 Detection method

Grab the package with burpsuite, and then replay it.

4.3.3 repair recommendations

Token and mobile phone number together, replay can not cause a bombardment of text messages, in addition, each mobile number can only send text messages per day, for example, 10 times. Each ip can only be sent three times per minute.

4.4 SMS verification code 4.4.1 description

SMS CAPTCHA is an effective means to prevent brute force cracking, but if it is not used effectively, it will not be able to play the effect of anti-brute force cracking.

4.4.2 testing method

Check whether the SMS CAPTCHA can be reused many times. General CAPTCHA is used once and is invalid.

Check the validity period of the SMS verification code. Generally, the verification code is valid within 5 minutes.

4.4.3 repair recommendations

Set the SMS verification code to be invalid once, and each SMS verification code is valid within 5 minutes.

4.5 Business logic vulnerabilities

There are mainly some ultra vires loopholes here.

4.6 other vulnerabilities on the server side

This is similar to webside vulnerabilities, such as SQL injection, XSS, arbitrary file upload vulnerabilities, and so on.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.