CN113596600A

CN113596600A - Security management method, device, equipment and storage medium for live broadcast embedded program

Info

Publication number: CN113596600A
Application number: CN202110888143.0A
Authority: CN
Inventors: 吴全贵
Original assignee: Guangzhou Fanxing Huyu IT Co Ltd
Current assignee: Guangzhou Fanxing Huyu IT Co Ltd
Priority date: 2021-08-03
Filing date: 2021-08-03
Publication date: 2021-11-02

Abstract

The application discloses a security management method, a security management device, security management equipment and a storage medium for live broadcast embedded programs, and belongs to the technical field of networks. In the embodiment of the application, safety management service is provided for the live broadcast embedded program embedded in the live broadcast application client, interactive content sent by the terminal through the live broadcast embedded program can be obtained based on the social interaction interface of the live broadcast embedded program, on the basis of obtaining the interactive content, risk control can be performed on the interactive content, and guarantee is provided for data safety in the using process of the live broadcast embedded program.

Description

Security management method, device, equipment and storage medium for live broadcast embedded program

Technical Field

The present application relates to the field of network technologies, and in particular, to a method, an apparatus, a device, and a storage medium for managing security of a live broadcast embedded program.

Background

With the development of network technology, live broadcasting becomes a popular content distribution mode. The anchor may start the live on the live application client. In the live broadcast process, the live broadcast platform can provide some live broadcast embedded programs, and the live broadcast embedded programs are downloaded and used by a live broadcast application client to activate the atmosphere of a live broadcast room. For example, the live embedded program may be a mini-game embedded program.

The live broadcast embedded program depends on a live broadcast application client, can be started in the live broadcast process, and then executes some operations and the like in the live broadcast embedded program.

The live application client can install the live embedded program in the live application client and start the live embedded program in the live application client. Data security issues may be involved in the use of live embedded programs.

Disclosure of Invention

The embodiment of the application provides a security management method, a security management device and a security management storage medium for a live broadcast embedded program, and data security in the using process of the live broadcast embedded program is improved. The technical scheme is as follows:

in one aspect, a method for security management of live embedded programs is provided, the method comprising:

receiving interactive content sent by a terminal through a live broadcast embedded program based on a social interaction interface of the live broadcast embedded program, wherein the live broadcast embedded program is embedded in a live broadcast application client;

performing risk detection on the interactive content;

and responding to the interactive content with risks, and sending first warning information to the terminal, wherein the first warning information is used for prompting the interactive content with risks.

In some embodiments, the risk detecting the interactive content includes:

sensitive word detection is carried out on the interactive content;

the sending of first warning information to the terminal in response to the interactive content being at risk comprises:

and responding to the interactive content including the sensitive words, and sending the first warning information to the terminal.

In some embodiments, the method further comprises:

receiving a multimedia resource uploading request sent by the terminal through the live broadcast embedded program, wherein the multimedia resource uploading request comprises a multimedia resource to be uploaded;

carrying out risk detection on the multimedia resource to be uploaded;

and in response to the multimedia resource being in risk, deleting the multimedia resource to be uploaded.

In some embodiments, the risk detection is performed on the multimedia resource to be uploaded; in response to the multimedia resource being at risk, deleting the multimedia resource to be uploaded, including:

storing the multimedia asset to a multimedia database;

carrying out risk detection on the multimedia resource to be uploaded;

in response to the multimedia asset being at risk, deleting the multimedia asset from the multimedia database.

In some embodiments, before the risk detection of the multimedia resource to be uploaded, the method further includes:

and sending a delay processing message to the terminal, wherein the delay processing message is used for informing the terminal of carrying out delay processing on the uploading of the multimedia resources.

In some embodiments, the method further comprises:

receiving target content sent by the terminal through the live broadcast embedded program, wherein the target content is obtained by the live broadcast embedded program from other servers;

carrying out risk detection on the target content;

and responding to the target content with risks, sending second alarm information or blocking the live broadcast embedded program.

In some embodiments, the method further comprises:

periodically receiving screenshots in the running process of the live broadcast embedded program;

carrying out risk detection on the screenshot;

and responding to the risk of the screenshot, and sending third warning information or forbidding the live broadcast embedded program.

In some embodiments, the method further comprises:

receiving a first program package of a live broadcast embedded program submitted by a developer terminal;

checking the first program package;

and responding to the program package passing the verification, and releasing the live broadcast embedded program in a live broadcast application client.

In some embodiments, said checking said first package comprises at least one of:

checking the program codes in the first program package;

and verifying the authority information of the developer terminal.

In some embodiments, the method further comprises:

replacing the target function in the first program package to obtain a second program package;

storing the first package of the live embedded program in response to the first package passing verification.

In some embodiments, the second package storing the live embedded program comprises:

encrypting the second program package to obtain a target encryption program package;

acquiring abstract information of the target encryption program package;

and storing the target encryption program package and the summary information of the live broadcast embedded program, wherein the summary information is used for carrying out security verification when any live broadcast application client side installs the live broadcast embedded program.

In some embodiments, the method further comprises:

receiving a data service request sent by the terminal through the live broadcast embedded program, wherein the data service request carries a data service interface;

verifying the data service interface in response to the data service request;

and responding to the verification of the data service interface, calling the data service interface, and executing the target operation corresponding to the data service interface.

In some embodiments, said verifying said data service interface comprises at least one of:

checking the interface number of the data service interface;

checking the flow limit of the data service interface;

verifying the authority information of the data service interface;

and checking an access key of the data service interface.

In some embodiments, the invoking the data service interface and executing the target operation corresponding to the data service interface includes:

calling the data service interface to obtain data to be transmitted;

encrypting the data to be transmitted;

and sending the encrypted data to the live broadcast application client.

In some embodiments, the method further comprises:

responding to a received network request sent by any terminal through the live broadcast embedded program, and matching a domain name requested by the network request with a domain name white list;

responding to the network request in response to the matching of the domain name with any domain name in the domain name white list;

and responding to the fact that the domain name is not matched with the domain name in the domain name white list, and sending prompt information to the terminal, wherein the prompt information is used for prompting that the domain name requested by the network request cannot be accessed.

In one aspect, a security management apparatus for live embedded programs is provided, the apparatus including:

the receiving module is used for receiving interactive contents sent by a terminal through a live broadcast embedded program based on a social interaction interface of the live broadcast embedded program, and the live broadcast embedded program is embedded in a live broadcast application client;

the detection module is used for carrying out risk detection on the interactive content;

and the sending module is used for responding to the interactive content with risks and sending first warning information to the terminal, wherein the first warning information is used for prompting the interactive content with risks.

In some embodiments, the detection module is configured to perform sensitive word detection on the interactive content;

the sending module is used for responding to the interactive content including the sensitive words and sending the first warning information to the terminal.

In some embodiments, the receiving module is further configured to receive a multimedia resource upload request sent by the terminal through the live embedded program, where the multimedia resource upload request includes a multimedia resource upload request that a multimedia resource to be uploaded originates from the live embedded program, and the multimedia resource upload request includes the multimedia resource to be uploaded;

the detection module is also used for carrying out risk detection on the multimedia resource to be uploaded;

the device further comprises:

and the deleting module is used for responding to the multimedia resource with risk and deleting the multimedia resource to be uploaded.

In some embodiments, the detection module and deletion module are to:

storing the multimedia asset to a multimedia database;

carrying out risk detection on the multimedia resource to be uploaded;

In some embodiments, the sending module is further configured to send a delay processing message to the terminal, where the delay processing message is used to inform that the delay processing is performed on the uploading of the multimedia resource.

In some embodiments, the receiving module is further configured to receive target content sent by the terminal through the live embedded program, where the target content is obtained by the live embedded program from another server;

the detection module is also used for carrying out risk detection on the target content;

and the sending module is also used for responding to the risk of the target content and sending second alarm information or forbidding the live broadcast embedded program.

In some embodiments, the receiving module is further configured to periodically receive screenshots during the running of the live embedded program;

the detection module is also used for carrying out risk detection on the screenshot;

and the sending module is also used for responding to the risk of the screenshot and sending third warning information or forbidding the live broadcast embedded program.

In some embodiments, the receiving module is further configured to receive a first package of live embedded programs submitted by a developer terminal;

the device further comprises:

the checking module is used for checking the first program package;

and the release module is used for responding to the first program package passing the verification and releasing the live broadcast embedded program in the live broadcast application client.

In some embodiments, the verification module is to perform at least one of:

checking the program codes in the first program package;

and verifying the authority information of the developer terminal.

In some embodiments, the apparatus further comprises:

the replacing module is used for replacing the target function in the first program package to obtain a second program package;

and the storage module is used for responding to the first program package passing verification and storing the first program package of the live broadcast embedded program.

In some embodiments, the storage module is to:

acquiring abstract information of the target encryption program package;

In some embodiments, the receiving module is further configured to receive a data service request sent by the terminal through the live broadcast embedded program, where the data service request carries a data service interface;

the detection module is also used for responding to the data service request and verifying the data service interface;

the device further comprises:

and the calling module is used for calling the data service interface in response to the data service interface passing the verification and executing the target operation corresponding to the data service interface.

In some embodiments, the detection module is to perform at least one of:

checking the interface number of the data service interface;

checking the flow limit of the data service interface;

verifying the authority information of the data service interface;

and checking an access key of the data service interface.

In some embodiments, the calling module is configured to call the data service interface to obtain data to be transmitted;

the sending module is also used for encrypting the data to be transmitted; and sending the encrypted data to the live broadcast application client.

In some embodiments, the apparatus further comprises:

the matching module is used for responding to a received network request sent by any terminal through the live broadcast embedded program and matching the domain name requested by the network request with a domain name white list;

the response module is used for responding to the network request in response to the matching of the domain name and any domain name in the domain name white list;

the sending module is further configured to send prompt information to the terminal in response to that the domain name is not matched with a domain name in the domain name white list, where the prompt information is used to prompt that the domain name requested by the network request cannot be accessed.

In one aspect, a server is provided, which includes one or more processors and one or more memories, where at least one computer program is stored in the one or more memories, and the at least one computer program is loaded and executed by the one or more processors to implement the above-mentioned security management method for live embedded programs.

In one aspect, a computer-readable storage medium is provided, in which at least one computer program is stored, and the at least one computer program is loaded and executed by a processor to implement the security management method of the live embedded program.

In one aspect, a computer program product or computer program is provided that includes one or more program codes stored in a computer-readable storage medium. One or more processors of the server read the one or more program codes from the computer-readable storage medium, and execute the one or more program codes, so that the security management method of the live embedded program is implemented.

In the embodiment of the application, safety management service is provided for the live broadcast embedded program embedded in the live broadcast application client, interactive content sent by the terminal through the live broadcast embedded program can be obtained based on the social interaction interface of the live broadcast embedded program, on the basis of obtaining the interactive content, risk control can be performed on the interactive content, and guarantee is provided for data safety in the using process of the live broadcast embedded program.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on the drawings without creative efforts.

Fig. 1 is a schematic structural diagram of a live broadcast system provided in an embodiment of the present application;

fig. 2 is a flowchart of a security management method for a live broadcast embedded program according to an embodiment of the present application;

fig. 3 is a flowchart of a security management method for a live broadcast embedded program according to an embodiment of the present application;

fig. 4 is a flowchart of checksum issuing of a live embedded program according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a terminal interface provided in an embodiment of the present application;

FIG. 6 is a flow chart of risk detection for interactive content according to an embodiment of the present application;

FIG. 7 is a flow chart of risk detection of third-party content according to an embodiment of the present disclosure;

fig. 8 is a flowchart of risk detection of an uploaded multimedia resource according to an embodiment of the present application;

fig. 9 is a flowchart of an interface verification of a live broadcast embedded program according to an embodiment of the present application;

fig. 10 is a flowchart of an interface verification of a live broadcast embedded program according to an embodiment of the present application;

fig. 11 is a system framework diagram for providing a live embedded program according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of a live embedded program device according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of a server according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

The terms "first," "second," and the like in this application are used for distinguishing between similar items and items that have substantially the same function or similar functionality, and it should be understood that "first," "second," and "nth" do not have any logical or temporal dependency or limitation on the number or order of execution. It will be further understood that, although the following description uses the terms first, second, etc. to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, the first image is referred to as a second image, and similarly, the second image is referred to as a first image without departing from the scope of the various examples. The first image and the second image are both images, and in some cases, separate and distinct images.

The term "at least one" is used herein to mean one or more, and the term "plurality" is used herein to mean two or more, e.g., a plurality of packets means two or more packets.

It is to be understood that the terminology used in the description of the various examples herein is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. The term "and/or" is an associative relationship that describes an associated object, meaning that there are three relationships, e.g., A and/or B, meaning: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" in the present application generally indicates that the former and latter related objects are in an "or" relationship.

It should also be understood that, in the embodiments of the present application, the size of the serial number of each process does not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

It should also be understood that determining B from a does not mean determining B from a alone, but also from a and/or other information.

It will be further understood that the terms "Comprises," "Comprising," "inCludes" and/or "inCluding," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It is also understood that the term "if" may be interpreted to mean "when" ("where" or "upon") or "in response to a determination" or "in response to a detection". Similarly, the phrase "if it is determined." or "if [ a stated condition or event ] is detected" may be interpreted to mean "upon determining.. or" in response to determining. "or" upon detecting [ a stated condition or event ] or "in response to detecting [ a stated condition or event ]" depending on the context.

The following describes an embodiment of the present application.

Fig. 1 is a schematic structural diagram of a live broadcast system provided in an embodiment of the present application. As shown in fig. 1 (a), the live system includes a terminal 101, a background server 102 of a live application client, and a live embedded program platform 103. The terminal 101 is respectively connected with a background server 102 and a live embedded program platform 103 of a live application client through a network.

As shown in fig. 1 (b), the live system includes a terminal 101 and a background server 102 of a live application client. The terminal 101 is connected with a background server 102 of a live application client through a network. Wherein, a live embedded program platform 103 is installed on the background server 102 of the live application client. That is, the background server 102 of the live application client can provide live service in the live application client for the terminal 101, and can also provide related data service of a live embedded program in the live application client for the terminal 101 through the installed live embedded program platform.

The terminal 101 is at least one of a smart phone, a game console, a desktop computer, a tablet computer, an electronic book reader, an MP3(Moving Picture Experts Group Audio Layer III, motion Picture Experts compression standard Audio Layer 3) player, an MP4(Moving Picture Experts Group Audio Layer IV, motion Picture Experts compression standard Audio Layer 4) player, and a laptop. The terminal 101 is installed and operated with a live enabled application, which is, for example, a live application client.

The background server 102 and the live embedded program platform 103 of the live application client respectively comprise at least one of a server, a plurality of servers, a cloud computing platform and a virtualization center. The background server 102 of the live application client is used for providing a background service for the live application client. The live embedded program platform 103 is used for providing background services for live embedded programs depending on live application clients. Optionally, the background server 102 and the live embedded program platform 103 of the live application client undertake primary processing, and the terminal 101 undertakes secondary processing; or, the background server 102 and the live embedded program platform 103 of the live application client undertake the secondary processing work, and the terminal 101 undertakes the primary processing work; or, the background server 102 and the live embedded program platform 103 of the live application client or the terminal 101 respectively undertake processing work independently. Or, a distributed computing architecture is adopted between the background server 102 of the live application client and the live embedded program platform 103 and the terminal 101 for performing collaborative computing.

Optionally, the backend server 102 and the live embedded program platform 103 of the live application client respectively include at least one server 1021 and a database 1022, where the database 1022 is used to store data, and in this embodiment of the present application, a configuration file of a live service or a live embedded program is stored in the database 1022, and provides a data service for the at least one server 1021.

Those skilled in the art will appreciate that there may be more or fewer terminals 101 and servers 1021. For example, there is only one terminal 101 or one server 1021, or tens or hundreds of the terminals 101 and the servers 1021, or more, and the number of the terminals or the servers and the device types are not limited in the embodiments of the present application.

Fig. 2 is a flowchart of a live embedded program authorization method provided in an embodiment of the present application, and referring to fig. 2, the method includes the following steps.

201. The server receives interactive content sent by the terminal through the live broadcast embedded program based on a social interaction interface of the live broadcast embedded program, and the live broadcast embedded program is embedded in the live broadcast application client.

The live embedded program refers to a program depending on a live application client. The live embedded program is embedded in the live application client. The live broadcast embedded program can be provided in the live broadcast application client, and when the live broadcast application client runs, if the live broadcast embedded program in the live broadcast application client is started, the live broadcast embedded program can be started in the live broadcast application client, corresponding operation is executed in the live broadcast embedded program, and the like.

Optionally, the embedded program is an applet, the applet is a program that runs by relying on another application client, and the live embedded program is a live applet. Applets refer to applications that run in a container, and most refer to runnable front-end programs provided by third-party developers. Some released live broadcast applets can be provided in the live broadcast application client, the anchor can download and install the live broadcast applets, the live broadcast applets can be started in the live broadcast application client, and the live broadcast applets can be accessed under the condition that the live broadcast application client does not need to be quitted.

The applet is used to provide live related functionality, such as a game applet that enriches the live content. As another example, a wishlist applet for improving the interaction between a host and a viewer. Also for example, a social interaction applet that is capable of chatting with other live application clients.

The social interaction interface is provided by the server and is used for providing services for social interaction in a live embedded program in a live application client. Specifically, the user can edit the interactive content on the terminal, and the terminal confirms the transmission based on the live broadcast embedded program in the live broadcast application client. The terminal can send the interactive content to the social interaction interface of the server, and then the server receives the interactive content. The server can detect the interactive content subsequently and forward the interactive content to the terminal where other users that the user wants to interact.

Optionally, the server may be the live embedded program platform, that is, the live application client may send the interactive content to the live embedded program platform to request the service related to the live embedded program provided by the live embedded program platform.

202. And the server carries out risk detection on the interactive content.

After receiving the interactive content, the server can perform risk detection on the interactive content to detect whether the interactive content has risks, so that the interactive content during the use period of the live broadcast embedded program is ensured to have safety.

The risk detection refers to detecting whether the content has a security threat or whether the content has the content prohibited from being transmitted. For example, the live embedded program is a multi-chat applet, and a user can start the multi-chat applet in a live application client and edit and send chat messages in the multi-chat applet. The chat message is the interactive content. The server may receive the chat message, and detect whether there is a risk in the chat message, such as whether a sensitive word is included.

203. And the server responds to the interactive content with the risk and sends first warning information to the terminal, wherein the first warning information is used for prompting the interactive content to have the risk.

After the risk detection, if the interactive content has a risk, the server may send a first warning message to the terminal to prompt that the interactive content sent by the terminal has the risk.

For example, taking the interactive content as a chat message as an example, when a sensitive word exists in the chat message, the server may send first warning information to the terminal, and the terminal may display the first warning information (for example, a popup is displayed in a chat interface, and the popup content is that a sensitive word exists in the chat message sent by you is detected). For example, the first alert information may be displayed in a page of the live embedded program.

Fig. 3 is a flowchart of a method for managing security of a live embedded program according to an embodiment of the present application, and referring to fig. 3, the method includes the following steps.

301. The server receives a first program package of a live embedded program submitted by a developer terminal.

In the embodiment of the application, the server opens the creating, publishing and managing services of the live broadcast embedded program to any developer terminal. The developer terminal is the terminal where the developer is located. Therefore, the user can register the account number of the developer on the live broadcast embedded program platform, namely, the live broadcast embedded program can be established on the live broadcast embedded program platform, and the live broadcast embedded program established by the user can be put on the shelf through the live broadcast embedded program platform, so that the service is provided for the live broadcast application client.

The developer terminal may submit the first package of the live embedded program to the server, and the server may receive the first package of the live embedded program. The server can check the first program package submitted by the developer terminal subsequently, and the first program package can be issued after the check is passed, so that the standardization and the data security of the issued first program package of the live broadcast embedded program can be ensured while the development right of the live broadcast embedded program is issued to any developer through the unified check of the server.

Specifically, a user can write program codes of live embedded programs on a developer terminal, package the program codes to obtain a first program package, and then submit the first program package to a server. Whereby the server is able to receive the first package.

In some embodiments, the server may provide the developer tool and the interface information of the live embedded program for the developer terminal, so that the developer terminal writes the program code of the live embedded program through the developer tool, and the written program code can correctly call the interface in the server to realize the corresponding interface function.

In some embodiments, the server may provide a uniform technology stack for development of the live broadcast embedded program, so that the developer terminal performs development of the live broadcast embedded program using the uniform technology stack to obtain the live broadcast embedded program with multi-terminal multiplexing. That is, a developer terminal develops a set of program codes of a live embedded program, and can use a small program loading container provided by an open platform at a WEB end, an android end and an iOS end, so that a function of multi-end use of a set of codes is realized.

302. The server checks the first program package.

After the server receives the first program package, the first program package can be checked to ensure that the live broadcast application client can normally use the live broadcast embedded program after the live broadcast embedded program is released to the live broadcast application client.

During the verification, the server may verify the first package in at least one of the following two ways.

And the first mode is to check the program code in the first program package.

By checking the program codes in the first program package, the program codes in the first program package of the live broadcast embedded program can be ensured to run normally or accord with function specifications provided by a server and the like.

In some embodiments, the program code of the first package may include a domain name requested by the network, and when the program code is checked, the domain name requested by the network in the program code may also be matched with a domain name white list. The domain name white list includes domain names that can be normally accessed. And matching the domain name of the network request with a domain name white list, and determining whether the network request of the live broadcast embedded program can normally access the corresponding domain name to acquire data.

It will be appreciated that if the domain name of the network request matches a domain name in the domain name whitelist, then the program code can be determined to be error-free. If the domain name of the network request is not matched with the domain name in the domain name white list, the domain name of the network request in the program code can be determined to be wrong, and then the developer terminal needs to further correct the domain name.

And secondly, verifying the authority information of the developer terminal.

In the second mode, whether the developer terminal has the authority of releasing the live embedded program is checked, so that malicious accounts are prevented from releasing malicious embedded programs in the server, and the safety of the live embedded program provided by the server is ensured.

In some embodiments, there is another possibility: the first package checks for a failure. If the verification fails, the server may send a verification failure notification to the developer terminal to notify the developer that the first package currently submitted fails to be verified.

Optionally, the server may further send a reason for failing to check to the developer terminal, so that the developer knows the problem of the current first package, and the check is passed after the developer is quickly corrected.

303. And the server responds to the first program package passing the verification and publishes the live broadcast embedded program in the live broadcast application client.

After the server checks the first program package, whether the live broadcast embedded program is issued can be determined according to a check result.

In some embodiments, if the first package is verified, the live embedded program may be published to the live application client, and a subsequent live application client may install or use the live embedded program in the live application client.

In some embodiments, in addition to checking the first package, the server may modify the first package to obtain a standard-compliant package, so as to store the standard-compliant package. When the subsequent live broadcast application client needs to install the live broadcast embedded program, the program package meeting the standard can be sent to the terminal where the live broadcast application client is located for installation.

Specifically, the server may replace the target function in the first package to obtain a second package, and then store the second package of the live embedded program in response to the first package passing the verification.

The objective function may be set by a relevant technician as required, which is not limited in the embodiment of the present application. For example, the objective function may be some key enzyme function or risk function, such as: eval Function, new Function, etc.

In some embodiments, after the function replacement is performed and the second package to be finally saved is obtained, the second package may be stored in an encrypted manner to prevent the second package from being tampered. Specifically, the server may encrypt the second program package to obtain a target encrypted program package, then obtain digest information of the target encrypted program package, and finally store the target encrypted program package and the digest information of the live broadcast embedded program, where the digest information is used for performing security verification when any live broadcast application client installs the live broadcast embedded program.

In some embodiments, the summary information may be extracted by the SHA1 algorithm, or may be extracted by other methods, which is not limited in this application.

The second program package is the final tag package of the live broadcast embedded program. The encrypted storage can prevent the program codes in the encrypted storage from being leaked or tampered. And by acquiring the summary information, when the live broadcast embedded program is installed in the subsequent live broadcast application client, the summary information and the target encryption program package can be sent to the terminal where the live broadcast application client is located, so that after the target encryption program package is downloaded by the terminal where the live broadcast application client is located, whether the target encryption program package is tampered or not can be determined based on the summary information, and the content verification of the target encryption program package can be realized.

The target encryption program package can comprise html files, js files, configuration files and the like, and the files can be encrypted through AES, so that the content of the program package can be guaranteed not to be easily tampered.

In some embodiments, in the storage process, the server may store the data in a cloud database, so as to implement cloud storage.

For example, in one specific example, as shown in FIG. 4, a developer may submit a development kit (i.e., a submitted package), and the server may then verify the package, which may be verified by a verifier in addition to the automatic verification of the server. In the verification process, the key functions in the package can be replaced, then the live broadcast embedded program is issued, and for the second program package passing the verification, encryption and signature (namely, abstract information extraction) can be performed on the second program package, and then the second program package is uploaded to the cloud storage. The server may store the package information.

A published live embedded program may be provided in the live application client for selection by a user. Specifically, a user can click a live broadcast embedded program display control in a live broadcast application client, the live broadcast embedded program platform can provide a live broadcast embedded program display interface for a terminal where the user is located, and a published live broadcast embedded program is displayed in the live broadcast embedded program display interface. If the user wants to download the live embedded program, the user can select the live embedded program to perform downloading operation.

For example, an applet mall may be provided in the live application client, with published applets provided in the applet mall. For example, if a user clicks on an applet mall control in a live application client, the live application client may display an applet mall interface as shown in fig. 5, in which the published applet is displayed. Each applet is associated with a download control displayed in an area, and the download control is displayed as "+ add", that is, the applet is added (installed/downloaded) in the live application client.

It should be noted that the above steps 301 to 303 are optional steps, and the above contents describe the process of submitting, verifying and issuing the package of the live embedded program. The following describes the data security management during the use of the live embedded program.

304. The server receives interactive content sent by the terminal through the live broadcast embedded program based on a social interaction interface of the live broadcast embedded program, and the live broadcast embedded program is embedded in the live broadcast application client.

The server is provided with a plurality of functional interfaces of the live broadcast embedded program, and the functional interfaces are used for being called by the live broadcast embedded program to acquire corresponding service data. A social interaction interface is a functional interface. The social interaction interface is used for being called in the live broadcast embedded program to interact information with other users.

The live broadcast embedded program is a social interaction embedded program, the live broadcast embedded program can be started in a live broadcast application client, interactive contents can be edited and sent in the live broadcast embedded program, then a terminal where the live broadcast application client is located can obtain the interactive contents through the live broadcast embedded program, and the interactive contents are sent to a social interaction interface provided for the live broadcast embedded program by the server. The server may then receive the interactive content based on the social interaction interface.

305. And the server carries out risk detection on the interactive content.

After receiving the interactive content, the server may perform risk detection on the interactive content to determine whether the interactive content is at risk.

In some embodiments, in the risk detection, sensitive word detection may be performed on the interactive content, that is, whether sensitive words are included in the interactive content is detected.

Specifically, when sensitive word detection is performed, the interactive content may be matched with the candidate sensitive words, and if any candidate sensitive word is hit by the interactive content, the interactive content may be considered to include the sensitive word, that is, the interactive content has a risk. If the interactive content misses any candidate sensitive word, the interactive content may be considered to not include the sensitive word, i.e., there is no risk for the interactive content.

The example of detecting the sensitive word of the interactive content is only used as an example for explanation, in some embodiments, other detections may be performed on the interactive content, for example, detecting whether a link exists in the interactive content, and the like.

306. And the server responds to the interactive content with the risk and sends first warning information to the terminal, wherein the first warning information is used for prompting the interactive content to have the risk.

After the server carries out risk detection on the interactive content, if the interactive content has risks, the server can send first warning information to the terminal to inform that the current interactive content has risks.

In some embodiments, the server may further process the interactive content with risk to send the processed interactive content to the terminal, and a destination terminal of the interactive content, where the destination terminal is a terminal where the user wants to send the interactive content to.

In the above embodiment in which the risk detection is sensitive word detection, in step 306, the server may send first warning information to the terminal in response to that the interactive content includes a sensitive word.

In a specific possible embodiment, the server may filter the sensitive words in the interactive content, and send the filtered interactive content to the terminal and the destination terminal of the interactive content.

For example, in a specific example, as shown in fig. 6, taking a live broadcast embedded program as an applet as an example, a user starts the applet in a live broadcast APP and sends chat information in the applet, a terminal where the user is located may submit the chat information to a server, a wind control module in the server may perform wind control filtering on the chat information, and based on this judgment of a risk level, when it is determined that the chat information is not passed, the server may send a sensitive word prompt to the terminal where the user is located. If so, the server may push the message to a socket, which will put it in a message queue to be published as an interactive message. sockets are endpoints that communicate bi-directionally between application processes on different hosts in a network.

In some embodiments, the server may provide other security management services in addition to the above-described programmatic management of interactive content. Next, through steps 307 to 309, a security management method for a multimedia resource uploading service is provided, where steps 307 to 309 are optional steps, and the embodiment of the present application is not specifically limited to whether the server has the security management service for the multimedia resource uploading service.

307. And the server receives a multimedia resource uploading request sent by the terminal through the live broadcast embedded program, wherein the multimedia resource uploading request comprises the multimedia resource to be uploaded.

In using a live embedded program, it may be desirable to upload a multimedia asset via the live embedded program and then use the multimedia asset in the live embedded program. Therefore, a user can upload the multimedia resource on the terminal, the terminal detects the multimedia resource uploading operation and can send a multimedia resource uploading request to the server, and the server receives the multimedia resource uploading request.

The multimedia resource may be a picture, a video, an audio, and the like, and the resource type of the multimedia resource is not limited in the embodiment of the present application.

308. And the server carries out risk detection on the multimedia resource to be uploaded.

In the embodiment of the application, the multimedia resources provided by the server are supported in the live broadcast embedded program, and the third-party multimedia resources are prohibited from being displayed in the live broadcast embedded program. The terminal needs to upload the multimedia resources to the server, the server checks the multimedia resources, and the multimedia resources are stored after the multimedia resources pass the check and serve as the multimedia resources provided by the server.

For the multimedia resource uploaded by any terminal, the server can carry out risk detection on the multimedia resource, and when the multimedia resource is determined to have no risk, the multimedia resource is stored for subsequent calling.

The risk detection process may select a corresponding risk detection mode according to a resource type of the multimedia resource. For example, the multimedia resource is a picture, the content of the picture can be identified, and whether the identified content of the picture has the content prohibited from being displayed is determined. For another example, the multimedia resource is audio, the signal of the audio may be compared with the candidate signal, and when it is determined that the signal of the audio is similar to the candidate signal, it is determined that the signal of the audio has a signal that is prohibited from being played, that is, there is a risk.

309. And the server responds to the multimedia resource with risk, and deletes the multimedia resource to be uploaded.

After the server carries out risk detection on the multimedia resource, if the multimedia resource has risks, the server can delete the multimedia resource, namely, the multimedia resource is not uploaded. If there is no risk of the multimedia resource, the server may store this in a database.

In some embodiments, the database may be a cloud storage database, i.e., the server may upload the multimedia resource to cloud storage.

In some embodiments, in the

above steps

308 and 309, the server may store the multimedia resource in a multimedia database, perform risk detection on the multimedia resource to be uploaded, then delete the multimedia resource from the multimedia database in response to the multimedia resource having a risk, and ensure a timely response to the multimedia resource uploading request by uploading first and then deleting according to a result of the risk detection, so as to delay the processing. Of course, the server may also respond that there is no risk of the multimedia asset and no deletion step is required.

In some embodiments, before the step 308, the server may send a delay processing message to the terminal before performing risk detection on the multimedia resource to be uploaded, where the delay processing message is used to inform that the delay processing is performed on the uploading of the multimedia resource. Therefore, the terminal is responded in time, the uploading step is prompted to be delayed, the user can not wait for processing all the time, and the phenomenon that the processing time is long and the user waits for too long time is avoided.

In some embodiments, the live embedded program is published to the server by a developer terminal, and the live embedded program provides a part of data services by other servers. The server may perform risk control on the content returned by other servers based on the request.

Specifically, the server may receive target content sent by the terminal through the live embedded program, where the target content is obtained by the live embedded program from another server and then the server performs risk detection on the target content, and sends second warning information or blocks the live embedded program in response to a risk of the target content.

In some embodiments, the target content is sent by the live embedding program when the sampling rate is hit. The sampling rate refers to a rate at which contents requested by other servers are sampled. That is, the server does not need to acquire all the contents acquired by the other servers and perform risk detection, but performs sampling according to the sampling rate and performs risk detection on the sampled contents.

For example, as shown in fig. 7, taking a live embedded program as an applet as an example, a user starts the applet in a live APP on a PC, the applet may request a server to obtain a sampling rate after starting, and the server may return the sampling rate to the applet. When the subsequent applet needs to call a third-party content interface (an interface of another server), the server can return the requested content for forwarding the request called by the interface. The applet may determine whether a sample rate is hit, and if so, the applet may report the requested content to the server. The server can forward the reported content to the wind control module, the wind control module can carry out risk detection (judgment of risk level) on the reported content, then the server judges whether the reported content is at risk or not, and when the reported content is at risk, the server can prompt an alarm and inform an alarm person to block the applet. The server may issue the banned message to the applet on the user side, thereby closing the applet.

In some embodiments, the live embedded program may also periodically send a screenshot of the live embedded program during the use process to the server, and the server periodically performs risk control on the use of the live embedded program, that is, the server can perform polling on the use process of the live embedded program. Specifically, the server periodically receives the screenshot in the running process of the live broadcast embedded program, then carries out risk detection on the screenshot, responds to the screenshot with risks, and sends third warning information or blocks the live broadcast embedded program.

For example, in a specific example, as shown in fig. 8, a user starts an applet in a live APP, and the applet obtains whether to perform polling. When the inspection is needed, the server side judges whether the inspection is needed according to inspection rules, when the inspection is needed, the small program is informed to generate uploaded picture information, and the server side stores the uploaded picture information into the cloud storage after obtaining the uploaded picture information. The server can also store the uploaded picture information, then sends a delay message to the applet, triggers the wind control check, then the applet can upload the picture (screenshot) to the cloud storage after receiving the delay message, and informs the server that the uploading is completed, the server can acquire the uploaded picture information and informs the wind control module to judge the risk level, and when there is a risk, the server can give an alarm and does not need to give an alarm if there is no risk.

In some embodiments, when the live embedded program calls a service interface, the server may also provide an interface security scheme.

Specifically, the server may receive a data service request sent by the terminal through the live embedded program, where the data service request carries the data service interface. Then the server can respond to the data service request, verify the data service interface, respond to the data service interface verification passing, call the data service interface, and execute the target operation corresponding to the data service interface. Through interface verification, data leakage caused by malicious request for accessing the interface can be avoided, and the safety of data service is ensured.

In some embodiments, the server may perform the verification in at least one of the following verification methods when verifying the data service interface.

And the first checking mode is to check the interface number of the data service interface.

When the interface number is checked, whether the data service interface number is consistent with the interface number carried in the data service request or not can be determined, and if so, the check can be determined to be passed. If not, a check may be determined to fail.

And a second checking mode, checking the flow limit of the data service interface.

The interface corresponding to each data service may be provided with a flow limit, so as to avoid that a large number of data service requests call one interface, which causes a load exceeding the interface, and causes data service collapse, abnormality and the like. Therefore, when the interface is verified, whether the call flow of the current interface reaches the flow limit quantity or not can be determined, and if the call flow of the current interface does not reach the flow limit quantity, the verification can be determined to be passed. If the call traffic for the current interface has reached the traffic limit amount, it may be determined that the check has not passed.

And a third verification mode, verifying the authority information of the data service interface.

Some interfaces may be provided with a call authority, and when these interfaces are called, it may be determined whether the terminal has the authority to call the interface. The process of verifying the interface's authorization information may also be referred to as an authentication process. If the terminal has the right to call the interface, it can be determined that the check passes. If the terminal does not have the authority to invoke the interface, it may be determined that the verification fails.

And a fourth verification mode is used for verifying the access key of the data service interface.

Some interfaces may be provided with access keys, and when the interfaces are called, it may be determined whether the access key carried by the data service request is consistent with the access key corresponding to the interface, and if so, it may be determined that the check is passed. If not, a check may be determined to fail.

The verification of the access key of the interface can be understood as interface signature verification, and the server can perform SHA256 signature on the parameters of the request interface so as to prevent illegal requests from entering the server.

The above description describes the case that the package check passes, and the interface check may also include other manners, for example, verifying a timestamp field of the interface, so that the request has a certain validity period, and the request will fail after being used for a period of time, thereby preventing the client from making repeated requests after catching the request.

For example, as shown in fig. 9, for the mobile terminal, the package signature verification method is unified, the request is verified, and the transmitted content is encrypted. As shown in fig. 10, for the PC side, due to the implementation of Javascript, there is a certain risk of leakage and being cracked, so that the signature verification algorithm is prevented from being cracked, and the login state, the authority and the current limit are verified.

In some embodiments, through the above verification, the server may normally provide data services after the interface verification passes. For the data acquired from the interface, the server can encrypt and transmit the data to call the data service interface to obtain the data to be transmitted, and then encrypt and transmit the data to be transmitted to the terminal.

The encryption processing mode may be set by a relevant technician as required, which is not limited in the embodiment of the present application. For example, the data to be transmitted by the interface can be encrypted and transmitted in the AES/CBC mode, so as to prevent the plaintext of the request parameter from being obtained by packet capture through software.

In some embodiments, in the above steps, the data service request, the request for installing the live broadcast embedded program, the multimedia resource upload request, and the like are all network requests, and for a network request sent by the terminal through the live broadcast embedded program, the server may check a domain name of the network request, and respond to the network request when the check is passed. If the verification fails, the server may not need to provide network services. Through the domain name verification of the network request, the legality of the network request can be verified, and data leakage caused by malicious request calling of data in the server is avoided.

Specifically, the server may, in response to receiving a network request sent by any live application client, match a domain name requested by the network request with a domain name white list, and then respond to the network request in response to matching the domain name with any domain name in the domain name white list. Or the server responds to that the domain name is not matched with the domain name in the domain name white list, and sends prompt information to the live broadcast application client, wherein the prompt information is used for prompting that the domain name requested by the network request cannot be accessed.

In a specific example, as shown in fig. 11, a front end (applet) may send a network request to a back end during an applet running process, where the back end includes a configuration background, an applet security module, and an applet service module, the applet is a third-party applet, and the third-party applet further corresponds to a third-party applet server. After the applet sends a network request to the backend, the applet security module at the backend can provide interface authentication, incoming content encryption, interface current limiting and other security management services for the applet, and if the applet server at the third party is involved, the applet can provide the security management services for the data services provided by the applet server at the third party.

Fig. 12 is a schematic structural diagram of a security management apparatus for live broadcast embedded programs according to an embodiment of the present application, and as shown in fig. 12, the security management apparatus includes:

the device also includes:

In some embodiments, the detection module and the deletion module are to:

storing the multimedia resource to a multimedia database;

carrying out risk detection on the multimedia resource to be uploaded;

in response to the multimedia asset being at risk, the multimedia asset is deleted from the multimedia database.

the sending module is further used for responding to the risk of the target content, sending second warning information or carrying out prohibition on the live broadcast embedded program.

the sending module is further used for responding to the risk of the screenshot, sending third warning information or blocking the live broadcast embedded program.

In some embodiments, the receiving module is further configured to receive a first package of live embedded programs submitted by the developer terminal;

the device also includes:

the checking module is used for checking the first program package;

In some embodiments, the verification module is to perform at least one of:

checking the program code in the first program package;

and verifying the authority information of the developer terminal.

In some embodiments, the apparatus further comprises:

and the storage module is used for responding to the first program package passing the verification and storing the first program package of the live broadcast embedded program.

In some embodiments, the storage module is to:

acquiring abstract information of the target encryption program package;

and storing the target encryption program package of the live broadcast embedded program and the summary information, wherein the summary information is used for carrying out security verification when any live broadcast application client side installs the live broadcast embedded program.

In some embodiments, the receiving module is further configured to receive a data service request sent by the terminal through the live embedded program, where the data service request carries a data service interface;

the device also includes:

In some embodiments, the detection module is to perform at least one of:

checking the interface number of the data service interface;

checking the flow limit of the data service interface;

checking the authority information of the data service interface;

the access key of the data service interface is verified.

the sending module is also used for encrypting the data to be transmitted; and sending the encrypted data to the live application client.

In some embodiments, the apparatus further comprises:

the response module is used for responding to the matching of the domain name and any domain name in the domain name white list and responding to the network request;

the sending module is further configured to send, in response to that the domain name is not matched with a domain name in the domain name white list, prompt information to the terminal, where the prompt information is used to prompt that the domain name requested by the network request cannot be accessed.

Fig. 13 is a schematic structural diagram of a server 1300 according to an embodiment of the present invention, where the server 1300 may generate a relatively large difference due to different configurations or performances, and includes one or more processors (CPUs) 1301 and one or more memories 1302, where the memory 1302 stores at least one computer program, and the at least one computer program is the computer program supporting various functions of the live embedded program platform. The at least one computer program is loaded by the processor 1301 and executes a security management method that enables implementation of the live embedded program described above. The server also includes other components for implementing the functions of the device, for example, the server also has components such as a wired or wireless network interface and an input/output interface, so as to perform input/output. The embodiments of the present application are not described herein in detail. The server may be a terminal or a server, which is not limited in this embodiment of the present application.

In an exemplary embodiment, a computer-readable storage medium, such as a memory including at least one computer program, the at least one computer program being the computer program supporting the various functions of the live embedded program platform described above, is also provided. The at least one computer program is loaded by a processor of the server and executes a security management method that enables implementation of the live embedded program. For example, the computer readable storage medium is a Read-Only Memory (ROM), a Random Access Memory (RAM), a Compact Disc Read-Only Memory (CD-ROM), a magnetic tape, a floppy disk, an optical data storage device, and the like.

In an exemplary embodiment, a computer program product or a computer program is also provided, which comprises one or more program codes, which are stored in a computer-readable storage medium. The one or more processors of the server read the one or more program codes from the computer-readable storage medium, the at least one program code being the program code described above that supports the various functionalities of the live embedded program platform. The at least one program code is loaded by a processor of the server and executes a security management method that enables implementation of the live embedded program.

In some embodiments, the computer program according to the embodiments of the present application may be deployed to be executed on one server or on a plurality of servers located at one site, or may be executed on a plurality of servers distributed at a plurality of sites and interconnected by a communication network, and the plurality of servers distributed at the plurality of sites and interconnected by the communication network may constitute a block chain system.

Those skilled in the art will understand that all or part of the steps for implementing the above embodiments are implemented by hardware, and also implemented by a program for instructing relevant hardware, where the program is stored in a computer-readable storage medium, and the storage medium mentioned above is a read-only memory, a magnetic disk or an optical disk, etc.

The above description is intended only to be an alternative embodiment of the present application, and not to limit the present application, and any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A security management method of a live broadcast embedded program is applied to a server, and comprises the following steps:

performing risk detection on the interactive content;

2. The method of claim 1, wherein the risk detecting the interactive content comprises:

sensitive word detection is carried out on the interactive content;

3. The method of claim 1, further comprising:

carrying out risk detection on the multimedia resource to be uploaded;

4. The method according to claim 3, wherein the risk detection is performed on the multimedia resource to be uploaded; in response to the multimedia resource being at risk, deleting the multimedia resource to be uploaded, including:

storing the multimedia asset to a multimedia database;

carrying out risk detection on the multimedia resource to be uploaded;

5. The method of claim 4, wherein before the risk detection of the multimedia resource to be uploaded, the method further comprises:

6. The method of claim 1, further comprising:

carrying out risk detection on the target content;

7. The method of claim 1, further comprising:

carrying out risk detection on the screenshot;

8. The method of claim 1, further comprising:

checking the first program package;

and responding to the first program package passing the verification, and releasing the live broadcast embedded program in a live broadcast application client.

9. The method of claim 8, wherein the verifying the first package comprises at least one of:

checking the program codes in the first program package;

and verifying the authority information of the developer terminal.

10. The method of claim 8, further comprising:

11. The method of claim 10, wherein the storing the second package of live embedded programs comprises:

acquiring abstract information of the target encryption program package;

12. The method of claim 1, further comprising:

verifying the data service interface in response to the data service request;

13. The method of claim 12, wherein the verifying the data service interface comprises at least one of:

checking the interface number of the data service interface;

checking the flow limit of the data service interface;

verifying the authority information of the data service interface;

and checking an access key of the data service interface.

14. The method of claim 12, wherein the invoking the data service interface to perform the target operation corresponding to the data service interface comprises:

calling the data service interface to obtain data to be transmitted;

encrypting the data to be transmitted;

and sending the encrypted data to the live broadcast application client.

15. The method according to any one of claims 1-14, further comprising:

16. A security management apparatus for live embedded programs, the apparatus comprising:

17. A server, comprising one or more processors and one or more memories, wherein at least one computer program is stored in the one or more memories, and wherein the at least one computer program is loaded and executed by the one or more processors to implement a method of security management of a live embedded program as claimed in any one of claim 1 to claim 15.

18. A computer-readable storage medium, having stored thereon at least one computer program which is loaded and executed by a processor to implement a method of security management of a live embedded program as claimed in any one of claims 1 to 15.