Content Security Policies (CSP) for HTTP response headers protect your site

Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”

This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money

This article mainly introduces the problem that the SKD function on the H5 page fails to be loaded in IOS because the response headers of the content-security-policy (CSP) configured on the Nginx server are inconsistent between the test environment and the official environment

Project background

Our H5 page, whose domain name is https://*.pineapple.com, needs to be embedded in X app and Y app respectively. Both X app and Y app have corresponding ios end and Android end. H5 page needs to call the SDK provided by X app or Y App respectively to call app functions, such as sharing function

Problems encountered

H5 page is normal on android terminal of X App, but abnormal on ios terminal. Specifically, on ios models, other functions such as calling sharing by referring to SDK of X App fail, but normal on Android. However, the H5 page is normal on both android and ios terminals in Y App.

The specific cause of the problem

The content security policies of the test environment are inconsistent with those of the formal environment. The response headers of the server in the formal environment are more content-security-policy than those in the test environment. As a result, after the SDK is successfully loaded in the X app on the H5 page, the request to trigger the pseudo-protocol through iframe SRC is intercepted by CSP. This caused the sharing and other features to fail, so the problem was not exposed in the testing session.

Response headers for the original formal environment configuration:

Content-Security-Policy: script-src <https://*.baidu.com><https://*.pineapple.com> 'unsafe-inline' 'unsafe-eval'; frame-src <https://*.pineapple.com><http://*.pineapple.com> webcompt:; Report -uri <https:// An obsolete address >Copy the code

What is the Content of ws-security – Policy

A Content-security-policy defines which resources can be loaded by the page and specifies the scope of resources that control the browser to load iframes. The main purpose of CSP is to minimize and report XSS attacks.

The solution

Locate the CSP content, block the content and modify it, and add the CSP to the test environment to expose the problem in time, so as not to expose the problem in a hurry before launch.

Remove the frame-src and report-URI from the configuration, because the address in the report-URI is not maintained, so the frame-src setting is not correct

The response header is:

Content-Security-Policy: script-src <https://*.pineapple.com> 'unsafe-inline' 'unsafe-eval';
Copy the code

How is the problem located

It was really super difficult to locate the problem at the beginning, because there was no configured server when going through the proxy, so the proxy could be normally successful, just like the double slit interference experiment, whether the observation affected the results. In fact, you can consider the server is the cause

1. Guess whether the page loading SDK is invalid on ios models

I thought it was a three-terminal SDK loading failure, but the actual loading succeeded, but the request inside (native and H5 interaction request) was intercepted by CSP

2. If the proxy is configured, it is normal

This problem is caused by a return from the server. The nginx server is not configured with a proxy, so the proxy can be configured

3. The difference between a test environment and a formal environment

It was found that there was a CSP in the official environment server configuration, with the following tutorial for whistler configuration return header

How to debug CSP

3.1 Rules Configuration:

/<https://*.pineapple.com/> resHeaders://{cspHeader}
Copy the code

3.2 cspHeader Configuration:

content-security-policy: script-src  <https://*.pineapple.com/> 'unsafe-inline' 'unsafe-eval'
Copy the code

3.3 Configuring the Mobile Phone Proxy Enables you to modify the policy content to locate faults.

Analysis of the principles leading to the problem

After location investigation, frame-src configuration is caused by it. Then why frame-src configuration fails in ios, but it is normal in Android? This requires to refer to the interaction principle of Hybird APP native and native H5

1. Ios is a native H5 that creates an IFrame by calling JS Bridge, and then triggers scheme or other native methods by modifying the SRC of iframe to the pseudo protocol defined in advance.

2. Instead of changing the SRC method of iframe to trigger Scheme, Android can call windower.prompt (uri, “) to trigger Scheme or any other native interaction mode (note that native interaction mode is not compatible with ios and android versions).

To sum up, JS Bridge is the triggering of capture scheme for ios and Android system calling different methods respectively.

To verify the above principle, I searched the source code of bridge under X App and found that there is indeed a step to create an IFrame. But Y app source code is not a step to create iframe, is the use of native native interaction. We can roughly analyze why Y app works normally. After loading THE SDK of X App, the functions in it are invalid.

The last

Above is my embedded page encounter CSP set some pit, hope can be helpful to you ~ if can get a small praise as encouragement will be very grateful!! You can also exchange ideas in the comments section