👉 Cross-domain column, covering only mainstream solutionsGithub address, with demo

👉 What is cross-domain

The current domain from which the request is made is different from the domain to which the resource to which the request points

Default HTTP port HTTPS Default port
80 443

Example: The domain that initiates the request is https://www.qixin.com

Requested resource domain:

  • https://www.qixin.com/user/claimed(the same domain)
  • https://www.qixin.com:443/user/claimed(the same domain)
  • Different ports:https://www.qixin.com:8000/user/claimed(cross domain)
  • Different agreements:http://www.qixin.com/user/claimed(cross domain)
  • IP address for domain name change:https://119.45.202.168/user/claimed(cross domain)
  • Subdomains differ:https://x.qixin.com/user/claimed(cross domain)
  • Different domain names:https://www.qixin001.com/user/claimed(cross domain)

Special scenes:

  • http://127.0.0.1:8000/user/claimed å’Œ http://localhost:8000/user/claimed(cross domain)
  • http://localhost:80/user/claimed å’Œ http://localhost/user/claimed(the same domain)
  • https://localhost:443/user/claimed å’Œ https://localhost/user/claimed(the same domain)

👉 Why the concept of cross-domain

Browser Same-origin Policy: Same-origin policy limits how a document or script loaded from one source interacts with a resource from another source, and is an important security mechanism for isolating potentially malicious files.

The purpose of the same-origin policy is to ensure the security of user information and prevent malicious websites from stealing data.

What makes a URL homologous: Two urls are homologous if they have the same protocol, port, and host. This scheme is also known as a “protocol/host/port tuple”, or simply a “tuple”.


👉 What are the hazards of not using the same origin policy

  • XSS/Cross Site Scripting

    The design philosophy that first forced browsers to adopt a distrust of Internet applications

    Is a script injection attack (similar to SQL injection) that allows an attacker to execute a malicious script in another user’s browser.

    Classification:

    • Non-persistent XSS attacks
      • Reflective XSS
        • Definition: After an attacker induces a user to access a URL with malicious code, the server receives and processes the data, and then sends the data with malicious code to the browser. The browser parses the data with XSS code and executes it as a script, finally completing the XSS attack.
        • Steps:
          1. The attack constructs a special URL that contains malicious code.
          2. The user is induced to open the URL with malicious code, and the server takes the malicious code from the URL as a parameter, and then returns the data with malicious code to the user.
          3. The user’s browser receives the response and parses it, and the malicious code mixed in is executed.
          4. Malicious code steals user sensitive data and sends it to the attacker, or impersonates the user to invoke the target website interface to perform the operations specified by the attacker.
        • Example: Movie search
          1. Open the home page, enter the search content “My sister”
          2. If there are no search results, the back end will return no movies related to “My Sister” if it does not process them
          3. Then the front end will display the movie directly on the page without my sister
          4. If the attacker changes the search to<script>alert("xss")</script>
          5. Front end direct popup window XSS
      • The DOM model XSS
        • Definition: XSS formed by modifying the DOM node of the page, and the removal and execution of malicious code are completed by the browser side, which belongs to the security vulnerability of the front end.
        • Steps:
          1. Attackers construct special urls that contain malicious code.
          2. The user is induced to open a URL with malicious code.
          3. The user’s browser receives the response, parses it and executes it. The front-end JavaScript pulls out the malicious code in the URL and executes it.
          4. Malicious code steals user data and sends it to the attacker’s website, or impersonates a user to invoke the target website interface to perform operations specified by the attacker.
        • For example, query the logistics information through the express number
          1. By accessinghttps://www.ceshi.com/index.html?number=YT40359134268305Gets the specific data for that number.
          2. To construct a website:https://www.ceshi.com/index.html?number=<script>alert("xss")</script>
          3. XSS attacks are caused by front-end engineers directly displaying values from urls.
    • Persistent XSS attacks
      • Type stored XSS
        • Definition: Stored XSS malicious code exists on the server, reflective XSS malicious code exists in the URL. In a stored XSS attack, malicious scripts are stored on the target server. When the browser requests the data, the script is passed back from the server and executed. It is one of the most dangerous types of cross-site scripting and is more subtle than either reflective XSS or DOM-type XSS because it does not need to be triggered manually by the user. Any Web program that allows users to store data is potentially vulnerable to storage XSS vulnerabilities. If a page is subjected to a storage XSS attack, all users accessing the page will be subjected to AN XSS attack.
        • Steps:
          1. The attacker submits the malicious code to the server of the target website.
          2. The target website server did not perform any verification to save the malicious code.
          3. Once the user opens the target website, the website server side takes out the data with malicious code and returns it to the user as normal data.
          4. The user’s browser receives the response and parses it, and the malicious code mixed in is executed.
          5. Malicious code steals user sensitive data and sends it to the attacker, or impersonates the user to invoke the target website interface to perform the operations specified by the attacker.
        • Example: a comment on a blog
          1. The attacker posted a comment under an article<script>alert('xss')</script>.
          2. Any user who enters the post loads a list of comments.
          3. Because the malicious code is executed by the browser, the XSS is popped directly.
          4. Of course, it can also be to execute a JS script, or steal user cookies.

    Solutions: escape, filter, content security policy (CSP) [external resource whitelist], etc

  • CSRF/XSRF/ cross-site Request forgery

    The attacker directs the victim to a third-party website, where the attacker sends cross-site requests to the attacked website. The registration certificate obtained by the victim from the attacked website is used to bypass the user authentication in the background and to impersonate a user to perform an operation on the attacked website.

    Attackers steal your identity and send malicious requests in your name. CSRF can do things like send emails and messages in your name, steal your account, and even buy goods and transfer virtual money. The problems include: personal privacy and property security.

    Process:

    1. Victim goes to site “A”, gets the login credentials Cookie.
    2. The attacker lured users to phishing site B.
    3. Site B sends A request to Site A, which by default carries site A’s Cookie.
    4. Site A took the user’s Cookie, thought it was using the request sent by the victim herself.
    5. Site A performs A series of operations (if virtual currency is involved) on behalf of the victim.
    6. The attack is complete, and the victim is impersonated without his knowledge.

    Classification:

    • CSRF of the GET type
      • For example:
        1. The user to access<img src="http://a.com/withdraw?amount=10000&for=hacker">
        2. After the victim visits the page containing the IMG, the browser automatically directs thehttp://a.comMake an HTTP request.http://a.comA cross-domain request containing the victim’s login information is received.
    • The CSRF type is POST
      • For example:
        1. This type of CSRF is typically utilized using an auto-submit form
        2. When you visit the page, the form is automatically submitted, equivalent to a simulated user completing a POST
          <form action="http://bank.example/withdraw" method=POST>
            <input type="hidden" name="account" value="xiaoming" />
            <input type="hidden" name="amount" value="10000" />
            <input type="hidden" name="for" value="hacker" />
          </form>
          <script> document.forms[0].submit(); </script> 
          Copy the code
    • CSRF for the link type
      • The user needs to click to trigger, not the first two open the page to attract the cool.

    Solution:

    • Automatic defense: Blocks access to an unknown foreign domain.
    • Active defense: Submit information that requires additional access to the domain.

👉 Cross-domain solution

  1. JSONP
  • The first solution (not the HTML standard)
  • Consists of callback functions and data
  • The client and server need to work together
  • The client introduces the request URL + callback function in the “SRC”, so that the data returned by the request server will be processed by the callback function, so that the cross-domain request is implemented. After receiving the request from the client, the server first obtains the function name to be called back by the client, generates the JavaScript code segment and returns it to the browser. The browser directly calls the callback function to complete the task after obtaining the returned result.
  • Specific cases can be viewedjsonp.html
  • Advantages: It is not restricted by the same-origin policy. Good compatibility;
  • Disadvantages: Only GET requests are supported. Other TYPES of HTTP requests are not supported
  1. CORS (Cross-Origin Resource Sharing)
  • New W3C standard.
  • Cross-source resource sharing is a mechanism based on HTTP headers. A new set of HTTP header fields allows browsers to make requests to CORS declared servers, addressing the limitation that Ajax can only be used from the same source.
  • New header parsing for HTTP:
    • Access-Control-Allow-Origin
      • Definition: which domains are allowed to access the resource by the server
      • Grammar:Access-Control-Allow-Origin: <origin> | *
    • Access-Control-Allow-Methods
      • Definition: Used to preinspect the response to a request, indicating which HTTP methods are allowed for the actual request
      • Grammar:Access-Control-Allow-Methods: <method>[, <method>]*
    • Access-Control-Allow-Headers
      • Definition: Used to preinspect the response to a request, specifying the header field allowed in the actual request
      • Grammar:Access-Control-Allow-Headers: <field-name>[, <field-name>]*
    • Access-Control-Max-Age
      • Definition: A response to a precheck request, specifying how long the precheck request can be cached
      • Grammar:Access-Control-Max-Age: <delta-seconds>
    • Access-control-allow-credentials (Optional, Boolean)
      • Definition: Whether to allow cookies to be sent. If true, the server explicitly allows cookies to be included in the request and sent to the server
      • Grammar:Access-Control-Allow-Credentials: true
      • Note: If set to true, you also need to bringwithCredentialsAnd,Access-Control-Allow-OriginYou must specify an explicit domain name that matches the requested web page
    • Origin
      • Definition: Indicates the source of the precheck request or the actual request. The Origin field is always sent regardless of whether it is a cross-domain request
      • Grammar:Origin: <origin>
    • Access-Control-Request-Method
      • Definition: This header field is used to precheck requests. It tells the server which HTTP method was used for the actual request
      • Grammar:Access-Control-Request-Method: <method>
    • Access-Control-Request-Headers
      • Definition: This header field is used to precheck requests. The function is to tell the server the header field carried by the actual request
      • Grammar:Access-Control-Request-Headers: <field-name>[, <field-name>]*
  • Preview the request
    • Definition: The browser asks the server if the domain name of the current web page is on the server’s license list, and what HTTP verbs and header fields are allowed. The browser makes a formal cross-domain request only if it receives a positive response, otherwise it reports an error.
    • Note: The precheck request uses the request method OPTIONS, indicating that the request is intended to be asked. In the header, the key field is Origin, which indicates the source from which the request came. Must containAccess-Control-Request-MethodandAccess-Control-Request-Headersfield
    • Trigger point: Browsers divide CORS requests into simple and complex requests, and only complex requests trigger precheck requests. Those that meet the following criteria are simple requests, and others are complex requests.
      • The request method is one of three
        • HEAD
        • GET
        • POST
      • HTTP header information does not exceed the following fields
        • Accept
        • Accept-Language
        • Content-Language
        • Last-Event-ID
        • Content-type: Specifies the content-type
          1. application/x-www-form-urlencoded
          2. multipart/form-data
          3. text/plain
  • Specific cases can be viewedcors.htmlWith some simple header configuration
  • Advantages: Support all types of HTTP requests. Error handling is easier
  • Disadvantages: Poor compatibility
  1. Nginx reverse proxy
  • Principle: A proxy path is configured to replace the actual access path. In this way, the browser considers that the resources accessed belong to the same protocol, domain name, and port. However, the actual access path is not the proxy path, but the actual access path is found through the proxy path.
  • The interface forwarding and response will be done by Nginx for you. You just need to configure your reverse proxy in the nginx.conf file to ensure that the proxy is correct.
  • For example, you can view the file in nginx-1.20.1nginx.conf å’Œ index.html
  1. Document. domain + iframe Cross-domain

  2. Location. hash + iframe Cross-domain

  3. Window. name + iframe Cross-domain

  4. PostMessage cross-domain

  5. The WebSocket protocol is cross-domain

Conclusion: The first three methods above are still typical cross-domain processing methods, and nGINX reverse proxy is recommended for projects with separated front and back ends.


Front-end development processes address cross-domain issues

  • Vue development

  • Principle: The principle of using the server to access the server without cross-domain problems
  • Request process: The request is first sent to the proxy (same-origin) server, and then the proxy (same-origin) server requests the external server

👉 Resources

Stop asking me cross-domain questions

Cross-site scripting attacks – XSS

Brief introduction to CSRF attack mode

Meituan Technology Salon: How to prevent CSRF attacks

Cross-source Resource Sharing (CORS)

Description of cross-domain resource sharing CORS

Agents are used in VUE development