“This is my fourth day of participating in the First Challenge 2022. For more details: First Challenge 2022.”
As a platform, control and security are very necessary. This is something that developers need to guard against, but if the platform can solve it, everyone will be happy.
What exactly does dual threading solve
Let’s give applauds to the two-threaded design of the applet team, and we can also review the underlying framework of the applet for dual-threading.
The hidden trouble of the H5
Remember that Web technology is very open and flexible, and developers can manipulate the DOM with JavaScript scripts at will, which brings the following problems:
Feel free to jump to the web and change anything on the interface
Developers can use JavaScript scripts to jump from page to page, or change anything on the interface. Of course, malicious attackers can also take advantage of this convenience.
Get page data
Applets also provide a component that can display sensitive data.
can display information including a user’s nickname, avatar, gender, location, and so on (without user authorization). If developers can manipulate the DOM, that means they can access sensitive user information at will.
Common front-end vulnerabilities
The common security vulnerabilities of developers are XSS and CSRF in the front end. XSS achieves a specific purpose by injecting JavaScript scripts, while CSRF uses cookies. XSS is filtered in dual-threaded designs, and CSRF will be covered later.
Controls that are difficult to achieve
To solve control and security problems, applets need to be disabled:
- Dangerous HTML tags or related attributes, such as the A tag of the outbound URL
- Dangerous apis, such as apis for operating interfaces, and apis for running scripts dynamically
The flexibility of JavaScript and the richness of browser interfaces can make it easy to leave out dangerous interfaces if one is to be disabled one by one. And the browser kernel is constantly being updated, and perhaps the next version will add an interface that could create vulnerabilities in the system.
The logical layer of security
How to solve these problems once and for all? Here’s a hint:
Yes, the sandbox environment. By providing a pure JavaScript interpretive execution environment with no browser-specific interfaces, you don’t have to worry about DOM manipulation, jumps, etc. In iOS is the built-in JavaScriptCore framework, in android is the JsCore environment (the old version is provided by Tencent x5 kernel, the new version is provided by v8).
Let’s review what a small program’s dual threads look like:
If the client system has a JavaScript interpretation engine, a separate thread can be created to execute JavaScript, and only code related to the business logic of the applet can be executed in this environment. The tasks related to interface rendering are left to the WebView thread, which controls which interfaces to render through the logical layer code.
Put the developer’s JS logic code into a separate thread to run, because it is not in the Webview thread, so this environment does not have any Webview interface, natural developers can not operate DOM directly, also can not dynamically change the interface or grab page data.
At the same time, small programs do not support dynamic loading scripts, XSS vulnerabilities are naturally seamless.
Audit mechanism control
Audit mechanism, the story to tell from the public.
The rapid development of WebView
With the emergence and prosperity of the public account, the frequency of WebView is getting higher and higher. Many enterprises, small businesses and outsourcing companies have started to make H5 pages, and various H5 activity pages, small shopping malls, small tests and small games are flying everywhere.
When WebView in wechat gradually becomes an important entry point of mobile Web, wechat has JS API.
At the beginning of 2015, wechat released a set of web development kit, which opened dozens of apis such as shooting, recording, voice recognition, TWO-DIMENSIONAL code, map, payment, sharing, card coupons, known as JS-SDK.
At this point, web developers can use wechat’s native capabilities to accomplish things that were previously impossible or difficult to do.
Difficult to control JSSDK
As more and more people use WebView and JSSDK, there are more and more people who do bad things on wechat. Some people make fake red envelopes, some induce sharing, and some fake official activities. They will use JSSDK’s sharing ability to share in various groups or moments in disguise.
Because JSSDK grants API permissions based on domain names, operators seal a domain name, they immediately use another domain name and continue to do bad, the cost of registering a new domain name is very low.
Review mechanism for small programs
In order to ensure the quality of the mini-program and comply with the relevant specifications, the release of the mini-program needs to be reviewed. The approved mini program can only be released to the public, and in the case of problems, the mini program will be removed from the shelf.
In addition, each wechat applet needs to set a communication domain name in advance, and the applet can only communicate with the designated domain name and network, including ordinary HTTPS request, upload files, download files and WebSocket communication, see frame – network. These communications domain names must also be required through the filing.
At the same time, applets must use HTTPS to initiate network requests. During the request, the system verifies the HTTPS certificate used by the server domain name. If the verification fails, the request cannot be initiated.
All these restrictions and management modes further protect user data and privacy security.
Secure login mechanism
Every front-end developer in this room is aware of the CSRF security vulnerability.
Danger of cookies
A cross-site request attack (CSRF), simply put, is a technique by which an attacker tricks a user’s browser into accessing a previously authenticated web site and performing operations (such as emailing, sending messages, or even property operations such as transferring money or buying goods). Because the browser has been authenticated, the site being visited will act as if it were a genuine user action.
This exploits a flaw in user authentication on the Web: simple authentication can only guarantee that a request is sent from a user’s browser, but not that the request itself is voluntarily made by the user. The common culprit is the browser’s cookie login state.
In addition to checking the Referer field for prevention, a more effective way is to use tokens. Applets do the same thing.
Applets login
Small programs can easily obtain the user identification provided by wechat through the login ability provided by wechat official, and quickly establish the user system within small programs. Refer to the official sequence chart:
Call wx.login() in the applet and get a code as the user’s login credentials (valid for five minutes). In the developer server background, developers can use code in exchange for openID and session_key information (code can only be used once).
Reliable code
Suppose you now have an interface and ask test.com/getUserInfo… After obtaining the personal information of wechat user ID 1 on our business side, hackers can traverse all ids to remove all personal information data of the whole business side, which will bring great security risks to the business.
Since the code expires in 5 minutes, if a hacker wanted to impersonate a user, he would have to run out all the ID’s within 5 minutes and then go to the developer server to get the real user’s identity. The code will expire immediately after a successful exchange of information, even if the certificate code generation time has not expired. Obviously, a hacker can pay a lot of money to get access to a user’s information, and the developer server can detect frequent login requests from an IP within five minutes and reject them.
AppSecret that needs to be protected
The developer background will get the wechat login certificate code generated by the preceding wx.login(), and then you can take this code to the wechat server to exchange the wechat user identity. In order to ensure that the person who takes the code to exchange for identity information is the corresponding small program developer, the request to the wechat server should bring AppId and AppSecret at the same time.
AppId and AppSecret are important information for wechat to identify developers. AppId is public information and disclosure of AppId will not bring security risks. However, AppSecret is the privacy of developers and should not be disclosed.
reference
- Small Program Development Guide
conclusion
As an open platform, small programs provide wechat support and experience support for developers to use at the same time, but also for users and developers to do a lot of security. Some might say it’s at the expense of developer openness, but I think it’s a platform with soul.