Principles for Handling Tuya SRC Vulnerabilities and Security Testing Specifications
1. Basic Principles
1.Without authorization, no one is allowed to disclose vulnerability details to the outside (including but not limited to storing, transmitting, or discussing vulnerabilities/vulnerability details on third - party platforms), or use vulnerabilities to obtain illegal benefits. If you disclose vulnerability information or use vulnerabilities to obtain illegal benefits, we will not give rewards. The rewards that have been given have the right to be recovered, the platform account will be banned, and the right to further pursue legal responsibilities will be reserved for those who violate the regulations seriously. If you intend to discuss or disclose vulnerabilities to any third party after we fix the vulnerabilities, including but not limited to conference speeches and publishing technical papers, please contact sec@tuya.com in advance.
2.Tuya employees shall not participate or participate in the above - mentioned activities in any form. If it is found that Tuya employees participate in the activities described in this reward rule, we have the right not to give rewards, the rewards that have been given have the right to be recovered, and the platform account will be banned at the same time, and the right to further internal handling will be reserved.
3.Vulnerability rewards are determined according to the actual loss that vulnerabilities can cause. The losses caused by the same type of vulnerabilities in different systems may be completely different, so even for the same type of vulnerabilities, the vulnerability rewards may also be different.
2. Vulnerability Response Handling Process
After receiving the vulnerability report, Tuya will handle it according to the following process.
1.Vulnerability Reception: Monitor and analyze the received vulnerabilities in a timely manner.
2.Vulnerability Verification: Verify the vulnerability and confirm the exploitability and impact of the vulnerability.
3.Solution Development: Provide effective vulnerability repair solutions or risk mitigation measures.
4.Scope of Impact Confirmation: Investigate and confirm the scope of affected products.
5.Security Announcement Release: Evaluate and release security vulnerability announcements according to specific situations.
3. Security Testing Specifications
1.For injection vulnerabilities, it is only necessary to prove that data can be read. It is strictly prohibited to read data in the table. For injection types such as UPDATE, DELETE, and INSERT, automated tools are not allowed to be used for testing.
2.For unauthorized access vulnerabilities, when accessing without authorization, the number of real data that can be read does not exceed 5 groups, and batch reading is strictly prohibited.
3.In the case where accounts can be registered, only 2 of your own accounts are allowed to verify the vulnerability effect, and do not involve the accounts of normal users on the official website. For unauthorized modification, please use your own test account.
4.In the case where accounts cannot be registered, if you obtain the account of the system and verify it successfully, if further security testing is needed, please consult the administrator and conduct the test after obtaining consent.
5.For stored XSS vulnerabilities, the correct method is to insert test payloads that do not affect others. Pop - ups are strictly prohibited. It is recommended to use console.log and then verify through another of your accounts, providing screenshot proof. For blind XSS, only external domain information is allowed to be carried. For all XSS tests, the inserted data needs to be deleted after the test. If it cannot be deleted, please note the insertion point in the vulnerability report.
6.If you can execute shell or commands, it is recommended to upload a text proof, such as a pure text 1.php or 1.jsp to prove that the problem exists. It is forbidden to download and read any source code files and sensitive files on the server. Do not execute delete or write commands. If a webshell is uploaded, please write the file address and connection password of the webshell.
7.In the test of vulnerabilities such as unlimited sending of text messages or email bombs, the number of successful tests does not exceed 50. If users can perceive it, for example, they will send login reminder text messages to users, testing on other people's real mobile phone numbers is not allowed.
8.If it is necessary to test vulnerabilities with automatic transmission and diffusion capabilities (such as tests in the social scenario), only small accounts isolated from other accounts are allowed to be used for testing. Do not use accounts with social relationships to prevent worm diffusion.
9.It is forbidden to use scanners for the website background and private project.
10.Except with special approval, social engineering unrelated to vulnerabilities is strictly prohibited, and intranet penetration is strictly prohibited.
11.It is forbidden to conduct tests that may cause abnormal operation of the business, such as vulnerability tests that may cause denial of service such as IIS denial of service and DDoS attacks.
12.Please do not conduct vulnerability mining on unauthorized manufacturers, projects not assigned to you, and lists beyond the test scope. You can contact the administrator to confirm whether it belongs to the asset scope before mining. Otherwise, the unauthorized legal risk will be borne by the vulnerability miner himself.
13.The leakage of sensitive information poses a great risk to users, manufacturers, and reporters. It is forbidden to store and transmit sensitive data related to business, including but not limited to source code, operation data, and user information leaked by business servers and platforms such as GitHub. If there is an unknown download behavior, it needs to be explained and deleted in a timely manner.
14.It is forbidden to use vulnerability testing as an excuse to use security vulnerabilities to damage or infringe on users' interests, including but not limited to threatening or intimidating the SRC to disclose vulnerabilities or data. Please do not disclose any information learned during the vulnerability testing process under any circumstances. For third - party disclosures of vulnerability information, please contact the SRC to obtain authorization. The enterprise reserves the right to take further legal actions against violators.