Security classification of front and rear ends:

1. Front-end security: security problems occurring in browsers, single-page applications and Web pages, such as XSS attacks, are front-end security problems

2. Back-end security: security problems in back-end servers, applications and services, such as SQL injection vulnerabilities in the back-end

Front-end security attacks

1. XSS attack

2. CSRF attack

Click hijacking

4. Risks associated with iframe

5. Insecure third-party dependencies

XSS attacks

XSS is called Cross Site Scripting. Malicious attackers insert malicious script code into web pages. XSS occurs when unexpected script instructions appear and are executed during the rendering of HTML documents by the target website and the target user’s browser, thus achieving the purpose of malicious attacks on users.

According to attack sources, XSS attacks can be classified into reflection, storage and DOM attacks:

Reflective XSS: When a request is made, the XSS code appears in the URL and is submitted to the server as input. After the server parses and responds, the XSS code is returned to the browser along with the response content. Finally, the browser parses and executes the XSS code. This process is like a reflection, hence the name reflective XSS.

1. User A sends A maliciously constructed Web URL to user B.

2. User B clicks and views the URL.

3. User B obtains an HTML page with vulnerabilities and displays it in the local browser.

4. The vulnerability HTML page executes malicious JavaScript scripts to steal user B’s information and send it to user A, or tamper with user B’s data

Reflective XSS defense:

We can prevent this by using HTML escapes, preferably with mature escape libraries

Attackers steal your identity, in the name of your sending malicious request, the request for server is perfectly legal, but finished the attacker’s expectation of an operation, such as in the name of your email, send messages, to steal your account, add a system administrator, or even to buy goods, virtual currency transfer, etc. Web A is A website with CSRF vulnerability, Web B is A malicious website constructed by an attacker, and User C is A legitimate User of Web A

Stored XSS: The only difference between stored XSS and reflective XSS is that the submitted code is stored on the server side and the XSS code does not have to be submitted the next time the target page is requested, so that every user who visits a particular page can be attacked

1. User A creates an account on the web page, and the account information contains the XSS code.

2. User B visits the website to view the XSS code account details page.

3. The server returns to the account details page with XSS account information.

4. User B’s browser executes XSS code to steal user B’s information and send it to user A, or tamper with the data seen by user B.

Stored XSS attack defense:

1. The back-end needs to filter the submitted data.

2. The front end can also do some processing methods, such as script tags, replace special characters with HTML codes and so on.

Dom-based XSS: DOM XSS is a vulnerability based on DOM document object model. Through HTML DOM and js code implantation, DOM changes, resulting in XSS-DOM vulnerability. Therefore, DOM XSS may be reflective or stored

1. User B visits the website URL with XSS code parameters.

2. The browser downloads the JavaScript script of the website.

The script has a method that takes the XSS code parameters from the URL and renders them in the DOM with innerHtml.

4. Trigger XSS code, resulting in XSS attack and cookie data theft.

DOM TYPE XSS attack is actually the site’s front-end JavaScript code itself is not strict enough, the untrusted data as code execution.

DOM XSS defense:

Be careful when using.innerhtml,.outerhtml, and document.write(). Do not insert untrusted data as HTML. Instead, use.textContent,.setAttribute(), etc.

Be careful with.innerhtml,.outerhtml, and document.write(). Try to use.textContent,.setAttribute() instead of inserting untrusted data into the page as HTML.

Be careful with.innerhtml,.outerhtml, and document.write(). Don’t insert untrusted data into the page as HTML. Instead, use.textContent,.setAttribute(), etc.

4. Http Only cookies

5. Strictly check and filter the product input requirements

CSRF attacks

Attackers steal your identity, in the name of your sending malicious request, the request for server is perfectly legal, but finished the attacker’s expectation of an operation, such as in the name of your email, send messages, to steal your account, add a system administrator, or even to buy goods, virtual currency transfer, etc. Web A is A website with CSRF vulnerability, Web B is A malicious website constructed by an attacker, and User C is A legitimate User of Web A

CSRF attack Defense:

Verify the HTTP Referer field

2. Use token authentication

3. Display the authentication mode: add the verification code and password

4. Data modification operations strictly use POST requests instead of GET requests

Click hijacking attacks:

Clickjacking is a form of visual deception. The attacker uses a transparent, invisible IFrame to overlay a web page and then trick the user into doing something on the page, where the user unknowingly clicks on the transparent IFrame page. By adjusting the position of the iframe page, you can trick the user into hitting some functional buttons on the iframe page.

A simple example of clickjacking is when you click on an unknown link and automatically follow someone’s blog or subscribe to a video

Click hijack defense

X-frame-options HTTP response headers are used to tell the browser whether to allow a page to be displayed in < Frame >,

2. Use authentication code to authenticate users: Click hijacking vulnerability attacks by forging website interface. Website developers can identify users by authentication code and confirm that the user clicks the command before performing corresponding operations. The most effective method to identify users is authentication code authentication. For example, the widespread existence of the post authentication code on the website requires users to input the characters in the graphics, input the characteristics of some graphics and so on

3, Use FrameBusting code: Use JavaScript scripts to prevent malicious websites from loading web pages. If a page is detected to be loaded by an illegal page, the automatic jump function is performed. If JavaScript scripts are disabled in the user browser, the FrameBusting code will not run properly. Therefore, this type of code provides only partial assurance

Risks associated with iframe

Sometimes our front-end pages need to use third-party page components, usually in the form of iframe. Typical examples are using iframe to add third-party ads, weather reports, social sharing plug-ins, and so on to a page

Iframe itself is not under our control, so if the domain name in the iframe expires and is hijacked by malicious attackers, or a third party is hacked, the content of the IFrame is replaced, so as to take advantage of the security holes in the user’s browser to download and install Trojan horses, malicious ransomware, and so on, this can be a big problem

The iframe defense:

Iframe has a security property called sandbox, which allows you to restrict the behavior of an iframe by adding this keyword to the iframe element. Sandbox also provides a wealth of configuration parameters for fine-grained control. Some typical parameters are as follows:

Allow-forms: Allows iframe forms to be submitted

Allow-popups: allows new Windows or tabs to popup in an iframe (e.g. Windot.open (), showModalDialog(), target= “_blank”, etc.)

Allow-scripts: allows JavaScript to be executed in iframe

Allow-same-origin: allows the same origin policy to be enabled for web pages in iframe

If you simply add this property and leave its value empty, browsers will impose the most stringent restrictions on iframe ever

Insecure third party dependencies

Many third-party dependencies are used in the project. No matter how high the security of the application’s own code is, if these third-party codes have security vulnerabilities, the overall security of the application will still be severely challenged. JQuery has several known security vulnerabilities, and Node.js has some known security vulnerabilities

Third-party dependent package defense:

Manually checking the third-party code for Security problems is a tedious task, mainly because the application relies ona large number of these components. Manual checking is time-consuming. There are automated tools available, such as THE Node Security Platform (NSP), Snyk, sonarQubej, and so on

Vue’s handling of front-end security: VUE’s security measures

Of course, there are many other forms of attack, such as:

Possible risks of Https (forcing Https to degrade back to HTTP to continue man-in-the-middle attacks)

Local storage data leakage (try not to store any sensitive, confidential data in the front end)

CDN hijacking (attackers hijack the CDN or pollute the resources in the CDN)