What are the potential front-end security issues?
- Cross-site Scripting (XSS): A code injection method called XSS to distinguish it from CSS. It is often seen in network forums in the early stage. The reason is that websites do not have strict restrictions on user input, so that attackers can upload scripts to posts and let others browse to pages with malicious scripts. The injection methods are very simple, including but not limited to JavaScript/VBScript/CSS/Flash
- Iframe abuse: The content in iframe is provided by third parties. By default, they are not under our control. They can run JavaScirpt scripts, Flash plug-ins, pop-up dialog boxes, and so on in iframe, which may damage the front-end user experience
- Cross-site Request Forgeries (CSRF) : An attacker forces an authentication user to update his/her personal information or setting information unexpectedly by setting a trap. CSRF is a passive attack
- Malicious third party library: Whether it is back-end server application or front-end application development, most of the time we are using the development framework and a variety of class libraries for rapid development, once the third-party library is implanted malicious code is easy to cause security problems, such as event-stream malicious code events, November 21,2018, A user named FallingSnow posted a query about the embedded malicious code in event-Stream on Github Issuse, indicating that the Event-Stream contained malicious code intended to steal users’ digital wallets
So the end point is XSS
What are the categories of XSS?
According to the attack sources, XSS attacks can be classified into storage, reflection and DOM attacks.
- Store: The location where malicious code is stored.
- Insertion point: Who gets the malicious code and inserts it into the web page.
Type stored XSS
Storage XSS attack steps:
The attacker submits malicious code to the database of the target website. When the user opens the target website, the website server takes the malicious code out of the database, splices it into HTML and returns it to the browser. When the user’s browser receives the response, it parses it and executes the malicious code mixed in. Malicious code steals user data and sends it to the attacker’s website, or impersonates the user’s behavior and calls the target website interface to perform the operations specified by the attacker. This kind of attack is common in website functions with user-saved data, such as forum posts, product reviews, and user messages.
Reflective XSS
Attack steps of reflective XSS:
The attacker constructs a special URL that contains malicious code. When a user opens a URL with malicious code, the web server takes the malicious code out of the URL, splices it into HTML and returns it to the browser. When the user’s browser receives the response, it parses it and executes the malicious code mixed in. Malicious code steals user data and sends it to the attacker’s website, or impersonates the user’s behavior and calls the target website interface to perform the operations specified by the attacker. The difference between reflective XSS and stored XSS is that the stored XSS malicious code is stored in the database, while reflective XSS malicious code is stored in the URL.
Reflective XSS vulnerabilities are common in functions that pass parameters through urls, such as website search, jump, etc.
Because users need to take the initiative to open malicious URL to take effect, attackers often combine a variety of means to induce users to click.
Reflective XSS can also be triggered by the contents of a POST, but the trigger condition is more stringent (the form submission page needs to be constructed and the user is directed to click), so it is very rare.
The DOM model XSS
DOM XSS attack steps:
The attacker constructs a special URL that contains malicious code. The user opens a URL with malicious code. When the user’s browser receives the response, it parses it and executes it. The front-end JavaScript picks up the malicious code in the URL and executes it. Malicious code steals user data and sends it to the attacker’s website, or impersonates the user’s behavior and calls the target website interface to perform the operations specified by the attacker. DOM XSS differs from the previous two types of XSS: DOM XSS attacks, in which malicious code is extracted and executed by the browser side, are security vulnerabilities of the front-end JavaScript itself, while the other two types of XSS are security vulnerabilities of the server side.
How can XSS be prevented?
XSS attacks have two main elements:
The attacker submits malicious code. The browser executes malicious code. For the first factor: can we filter out the malicious code that users enter during the process?
The input filter
As the user submits, the input is filtered by the front end and then submitted to the back end. Is this feasible?
The answer is no. Once the attacker bypasses the front-end filtering and constructs the request directly, the malicious code can be submitted.
Change the filtering timing: the back end filters the input before writing it to the database, then returns the “safe” content to the front end. Is this feasible?
For example, a normal user enters 5 < 7, which is escaped to 5 < 7 before writing to the database.
The problem is: during the commit phase, we’re not sure where the content is going to be exported.
“Not sure where to output” has two meanings:
The user’s input may be provided to both the front end and the client, but once escapeHTML() is passed, the client’s output becomes garbled (5 < 7). In the front end, different locations require different coding. When 5 & lt;
Of course, input filtering is necessary for explicit input types such as numbers, urls, phone numbers, email addresses, and so on
Since input filtering is not entirely reliable, we protect against XSS by preventing browsers from executing malicious code. This section falls into two categories:
Preventing injection in HTML prevents malicious code from being executed when JavaScript is executed
Protects against stored and reflective XSS attacks
Both stored and reflective XSS are inserted into the response HTML after the server takes out the malicious code, where the attacker’s deliberate “data” is embedded in the “code” and executed by the browser.
There are two common approaches to prevent these vulnerabilities:
Change to pure front-end rendering, separating code from data. Fully escape HTML.
Pure front-end rendering
Pure front-end rendering process:
The browser first loads a static HTML that does not contain any business-related data. The browser then executes the JavaScript in the HTML. JavaScript loads the business data through Ajax and calls the DOM API to update it to the page. In a pure front-end rendering, we explicitly tell the browser whether to set a text (.innertext), an attribute (.setAttribute), a style (.style), etc. Browsers can’t easily be tricked into executing unexpected code. However, pure front-end rendering also needs to avoid DOM-type XSS vulnerabilities (such as onload events and javascript: XXX in href, see section “Preventing DOM-type XSS attacks” below). In many internal and management systems, pure front-end rendering is perfectly appropriate. However, for pages with high performance requirements or SEO requirements, we still face the problem of concatenated HTML.
Escaped HTML
If concatenating HTML is necessary, you need to use a suitable escape library to adequately escape the insertion points of the HTML template. Common template engines such as dot.js, EJs, FreeMarker, etc., usually have only one rule for HTML escaping, which is to escape & < > “‘ /. This does provide some XSS protection, but it’s not perfect: | XSS vulnerabilities | escape if there is a simple protection | | – | – | | HTML tags text content | | | | have HTML attribute value | | CSS inline style no | | | inline JavaScript no | | | inline JSON no | | | jump links | | free so XSS should be improved For protection, we need to use more sophisticated escape strategies.