Skip to main content

​
Guide to the Security Test Report for Listing an App on the Marketplace

Test and complete the Security Test Report Result Template, convert it to PDF format, and submit it. For the final content of the report, refer to the Sample App Security Test Report Result (Sample).

​
Frequently Asked Questions

When taking screenshots, capture the entire interface of the tool (including the request content and the response content). Do not compress them and attach them directly to the report.
  1. Q: What information must the report provide? Must every test case be tested? A: All test cases specified in the report are mandatory security checkpoints. The report presents the typical risk types that need attention during security assessment. The ISV must, based on the requirements of the report and combined with its own business type, perform security tests on all applicable APIs. The report should reflect the testing process for the key APIs, but the actual testing scope is not limited to the API tests reflected in the report.
  2. Q: Our company does not have dedicated security personnel. Can we skip providing the security assessment report? A: No. The report provides recommended testing methods and tools for each test case, such as Burp Suite. Detailed usage guidelines for these tools can be found online. To ensure the security of the business after it goes live, security testing before launch is mandatory and essential.
  3. Q: Does each test case in the report have testing standard requirements? A: Test cases fall into two categories: data checks and security tests. Data checks are similar to port scanning and using middleware information. They do not involve data modification, but require you to record the actual system status and provide the necessary information. For checks performed using tools, you must provide screenshots, such as the Nmap scan results. For security test cases, follow the standards below:
    1. Have the system send a normal request. Use a tool to capture screenshots of the normal request and the server-side response, and also capture a screenshot of the information displayed on the business app page.
    2. Modify the network request information in the tool—for example, modify an ID. Capture screenshots of the modified network request and the server-side response in the tool, and also capture a screenshot of the result returned on the business app page.
    3. Attach both the tool screenshots and the business app screenshots to the report.
  4. Q: What should I do if a test case mentioned in the report does not exist in my business? A: In this case, provide the reason it is not applicable or the alternative technology used. For example, if there is no SMS module, note that the SMS feature is not used.
  5. Q: I have already implemented parameter tamper protection. What is the purpose of permission verification testing? A: Parameter tamper protection and permission verification target different scenarios. The former prevents data forgery and verifies data consistency. For some APIs, a legitimate user may attempt to access unauthorized data—for example, viewing information of another department. The submitted information is valid, but the operator is outside the authorized scope.
  6. Q: There are many testing steps. Can I skip the screenshots? A: The purpose of testing is to discover risks as early as possible and ensure the security of the business after it goes live. Screenshots are used to record the testing process. The DingTalk security team analyzes the screenshot information to help identify potential additional business risks, so the screenshots are essential.
  7. Q: What should I do if the testing performed before the business goes live is more extensive than what the report requires? A: If you tested scenarios not covered by the security report through other means, we recommend organizing the content into a document and attaching it as a new worksheet in the worksheet. The DingTalk security team will help analyze the report and assess the risks.
  8. Q: What is the purpose of the test screenshots? A: The purpose of the screenshots is to check whether the testing method is correct and whether the testing was performed as required.

​
Security Test Cases

​
Prepare Tools

Packet capture and modification tools: Port scanning tool:

​
Security Requirements

  1. You must configure and use the SSL protocol, and use HTTPS in both the code and the services you provide.
  2. Listed apps must use the DingTalk account system and use the APIs provided by the Open Platform to obtain user identity information. Building a custom login system is prohibited.
Note If you have a scenario where user files are stored, then to ensure data security and stability, do not store files on ECS servers. Use Object Storage Service (OSS) to store the data.

​
Security Test Results

​
NO.01 Externally Exposed Port Information of the EIP

Complete the table and attach a screenshot of the scan. Requirement: The EIP (Elastic IP) should only expose necessary service ports (such as ports 22, 80, 443, and 3389); the SLB should only expose web service ports (such as ports 80 and 443). If any special ports are exposed, describe the scenario.
Replace ”***” with the EIP. If there are multiple EIPs (Elastic IPs), provide the port exposure information for all of them. Port information for internal IPs does not need to be provided. Nmap command: nmap -sV -T4 -Pn -p1-65535 ip

​
NO.02 Database Information

Complete the table (database table and field structure information). If there are many tables and fields, fill in only the tables and fields related to user information. Requirement: Do not store users’ sensitive information (including but not limited to ID card numbers and bank card numbers). If you have special requirements, describe the usage scenario.

​
NO.03 Sensitive Information

Complete the table. Requirements:
  1. Relatively sensitive information (such as phone numbers and email addresses) that is returned or displayed must be masked.
  2. Server-side business logs are not allowed to print or store sensitive information.

​
NO.04 Privilege Escalation Vulnerability

Tool used: packet capture tool
  1. Vulnerability introduction:
By directly accessing a URL or modifying a URL parameter such as an ID, you can view information belonging to other people’s entries, and may even modify it.
  1. Root cause:
The user identity (user ID) is obtained from URL parameters or an unencrypted cookie and is used as the basis for data queries and function operations. Users can modify this parameter, resulting in horizontal or vertical privilege escalation.
  1. Fix plan:
Implement proper user identity verification. Verify whether the current user has permission to perform the operation. Obtain the user identity information from an encrypted cookie or session, rather than determining the current user identity by reading URL parameters.
  1. Testing method:
Test based on your own business scenario.
  • Horizontal privilege escalation: For example, consider a scenario for viewing order information: the order number for user A’s order is 1, and the order number for user B’s order is 2. User A accesses .com/my?orderid=1 to view their own order with order number 1. Use a packet capture tool to modify the API parameters in the request, changing orderid=1 in user A’s .com/my?orderid=1 request to orderid=2, and check whether you can obtain user B’s order information with order number 2. If you can view the information, a horizontal privilege escalation vulnerability exists. Similarly, in addition to the scenario of viewing information, add/delete/modify operation APIs are tested in the same way.
  • Vertical privilege escalation: For example, consider a scenario for modifying information: the order number for user A’s order is 1, but user A does not have permission to modify their own order information; admin B has permission to modify all order information. Admin B can view all orders by accessing the .com/my?orderid=all API. Have user A access .com/my?orderid=all, an API that should only be operable by an admin, and check whether they can obtain all order information. If they can, a vertical privilege escalation vulnerability exists. Similarly, viewing information and add/delete/modify operation API scenarios are tested in the same way.
  1. Test result:
Complete the table and attach a screenshot of the test. Requirement: All APIs must be tested and must not have any privilege escalation vulnerabilities, but the screenshots may show the test of only some APIs. Screenshot requirement: At least two screenshots are required, one showing user A’s normal request and one showing user A’s request with the modified URL parameter. The screenshots must show the requested URL and the returned content.

​
NO.05 Cross-Site Scripting (XSS) Vulnerability (Mini Programs May Skip This Test)

  1. Vulnerability introduction:
A malicious attacker inserts malicious HTML code into a web page. When a user browses the page, the HTML code embedded in the page is executed, achieving the special purpose of maliciously attacking the user.
  1. Root cause:
The cause of an XSS vulnerability is that the attacker’s input is not strictly controlled and is ultimately displayed to visiting users. The attacker uses clever methods to inject malicious command code into the web page, causing the user to load and execute the malicious web program crafted by the attacker. These malicious web programs are usually JavaScript, but can actually include Java, VBScript, ActiveX, Flash, or even plain HTML. After a successful attack, the attacker may obtain higher permissions (such as performing certain operations), personal web page content, sessions, cookies, and other content.
  1. Fix plan:
To defend against XSS, strictly filter the user’s input based on the actual situation. For example, in PHP, use the htmlspecialchars() function to HTML-escape the content entered by the user. Also, adding the httponly attribute to cookies can protect users’ cookies to some extent and reduce losses when XSS occurs.
  1. Testing method:
Test based on your own business scenario. For example, consider a scenario where user A submits form information. Have user A enter HTML code in the input field, such as " or <script>alert(123)</script>. When user A or the admin views the page displaying the submitted form content, check whether the inserted HTML code is executed—for example, whether a pop-up appears. If it is executed, a cross-site vulnerability exists.
  1. Test result
Complete the table and attach a screenshot of the test. Requirement: All pages that have input content must be tested and must not have any cross-site vulnerabilities, but the screenshots may show the test of only some APIs. Screenshot requirement: At least one screenshot is required, showing the page whose content had HTML code inserted. The screenshot must show that the HTML code in the content is executed.

​
NO.06 SQL Injection Vulnerability

  1. Root cause:
A SQL injection attack can be described as an attack that injects SQL syntax into user-controllable parameters, breaking the original SQL structure and achieving results unintended by the developer. Its cause can be attributed to the combination of the following two factors:
  • When handling the interaction between the application and the database, the developer uses string concatenation to construct SQL statements.
  • The user-controllable parameters are not sufficiently filtered before their content is concatenated into the SQL statement.
  1. Fix plan:
Use precompiled SQL statements. Concatenating SQL statements is strictly prohibited. For example, use MyBatis for Java and SQLAlchemy for Python. If you use Ibatis, replace var with #var# If you use MyBatis, replace ${var} with #{var}
  1. Test result:
Complete the table and attach a screenshot of the test. Screenshot requirement: Take a screenshot of the key code related to executing SQL statements, so that it can be seen that SQL statement concatenation is not used.

​
NO.07 Cross-Site Request Forgery (CSRF) Vulnerability

Tool used: packet capture tool
  1. Root cause:
The attacker forges requests that appear to come from a trusted user, achieving the purpose of adding, deleting, or tampering with website content. When the user clicks a malicious link crafted by the attacker, the corresponding operation is “executed” on their behalf. For example, a bank’s transfer function (transferring 100 to BOB’s account) is implemented as follows: GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1 When the attacker lures the user into clicking the link below, if the user’s login credential for the bank website has not yet expired, then the user transfers 100,000 to MARIA without knowing it: http://bank.com/transfer.do?acct=MARIA&amount=100000 Simple identity verification can only guarantee that the request is sent from a certain user’s browser, but cannot guarantee that the request itself was sent voluntarily by the user.
  1. Fix plan (choose one):
  1. Testing method:
For example, the request to modify information is:
Use a packet capture tool to change Referer: ***.com/my in the modification request to other content, and send the request again.
If the modification operation is executed successfully, a cross-site request forgery vulnerability exists. Similarly, if a random token is used, change the token value; if the modification operation is executed successfully, a vulnerability exists. All add/delete/modify operation APIs must be tested.
  1. Test result
Complete the table and attach a screenshot of the test. Requirement: All APIs must be tested and must not have any cross-site request forgery vulnerabilities, but the screenshots may show the test of only some APIs. Screenshot requirement: At least two screenshots are required, one showing a request with a normal Referer or token and one showing a request with a modified Referer or token. The screenshots must show the request content and the returned content.

​
NO.08 Privacy Security

Complete the table and describe the usage scenarios for the obtained permissions and data. Requirements: For self-collected data: Go to the App Development > Basic Information > Manage Permissions page, click User Information Usage Statement, and fill in the collected user information and its usage scenario description. DingTalk detects this automatically; simply completing the form is sufficient. See the figure below: After completing the form, fill in the description of the scenario in which the private data is needed in the sample report.

​
Using Burp Suite and Importing the Certificate

​
Set the Proxy

Set the proxy as shown in the figure below. The port can be customized. On PC: Set the proxy listening address and port for Burp Suite. By default, it listens on port 8080 of 127.0.0.1. You can add or modify the listening address or port based on your actual testing needs. On mobile, using iOS as an example: Enter the proxy address and port for Burp Suite. Wi-Fi > HTTP Proxy > Configure Proxy

​
Import the Certificate

On the mobile device, access the proxy address http://ip:port in a browser to download and import the certificate. Tips: On iOS, there are two places where you need to set trust.
  1. Settings > General > About > Certificate Trust Settings
  2. Settings > General > Profiles & Device Management

​
Intercept and Modify Packets

  1. Intercept the packet and send it to the Repeater window.
  2. Modify the packet in the Repeater window and replay it.
  3. In the left window, modify the request packet content directly, then send the request by clicking the Go button; you can view the returned content in the right window.