Shulou(Shulou.com)06/03 Report--

This article mainly explains "what are the front-end security coding specifications", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn "what are the front-end security coding specifications"!

1. Cross-site scripting attack (Cross Sites Script)

Cross-site scripting attack, Cross Site Script (referred to as CSS or). Refers to an attack by a hacker who tampers with a web page through "HTML injection" and inserts malicious scripts (mainly JavaScript scripts) to control the user's browser when browsing the web.

If you know what XSS is, you must want to know what harm it does and how to defend it.

Here's a list:

Hang up the horse

Steal user Cookie.

Fishing attack, advanced fishing skills.

Delete target articles, maliciously tamper with data, and frame them.

Hijack user Web behavior, and even further infiltrate the intranet.

Outbreak of the Web2.0 worm.

Worm horse attack, advertising, browsing volume, destroying online data

Other security issues

Common cross-site scripting attacks can also be divided into: reflective XSS, storage XSS, DOM Based XSS.

The following is a specific analysis of these three common types

1.1 reflective XSS-- can also be referred to as HTML injection

Reflective XSS, also known as "non-persistent XSS", simply "reflects" the data entered by the user to the browser, that is, hackers often need to induce the user to "click" a malicious link to succeed in the attack. By clicking on this malicious link, the attacker can successfully obtain the user's private data. Such as: "stealing user Cookie information", "destroying page structure", "redirecting to other websites", stealing intranet IP and so on.

So since reflective XSS can also be HTML injection, the key to its injection naturally starts with the front-end HTML page:

1. Users can interact with browser pages (enter search keywords, click buttons, click links, etc.), but these need to induce users to operate, which is easier said than done. two。 The data entered by the user will be spliced into a suitable html by the attacker to execute the malicious js script, which is like a "reflection".

1.2 Storage XSS

Storage XSS, also known as `persistent XSS`, differs from `reflective XSS` in that it "stores" the data entered by the user on the attacker's server and has strong "stability". For example: visit a blog article written by a hacker that contains malicious JavaScript code, and the hacker saves the malicious script to the server.

1.3 DOM based XSS

In effect, it is also a "reflective XSS", divided separately because it is formed by modifying the XSS formed by the "DOM node" of the page. For example, by modifying the binding method on the DOM node, the user inadvertently obtains the relevant information of the user by executing these methods through clicking, typing, and so on.

1.4 how to detect the presence of XSS

The general method is that the user can enter alert (123) in the place where the keyword input search is concerned, and then click to search. If the pop-up box shows 123, it means that there is a XSS loophole, which means that the front end does not filter the content entered by the user.

1.5 XSS attack mode

1.Cookie hijacking

By disguising some `pictures and buttons'to induce users to operate on them, the web page executes the attacker's malicious script, so that the attacker can obtain the Cookie information of the current user.

two。 Construct GET and POST requests

If an attacker wants to delete an article on a website, he first obtains the id of the current article, and then sends a `GET request `or `construct form` by using the script `insert Picture', or sends `XMLHTTPRequest` to send the `POST request `to delete the article

3.XSS fishing

The general understanding of the word 'fishing' originates from 'social engineering'. Hackers use the ideas of this discipline to trick users without authorization and knowledge, and get private information such as the other party's name, age, email account number, and even bank card password. For example: "A user operates a login box forged by a hacker on a website (which has been attacked). When the user enters the user name (here may be the ID number, etc.) and password in the login box, upload its information to the hacker's server (the user's information has been leaked from the site)."

4. Get the real IP address of the user

If the client has installed the Java environment (JRE), you can obtain the local IP address of the client by calling the API `Java Applet`.

1.6 XSS defenses

1.HttpOnly

How it works: the browser forbids the Javascript of the page from accessing cookie with the HttpOnly attribute. (the real solution is: cookie hijacking attack after XSS) has become a "standard" practice.

Solution: JavaEE adds HttpOnly to Cookie by: response.setHeader ("Set-Cookie", "cookiename=value; Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly")

two。 Input check (XSS Filter)

Principle: invalidate some attacks based on special characters. (common Web vulnerabilities such as XSS, SQLInjection, etc., require attackers to construct some special characters.) * the logic of input check must be implemented on the server, because the client check can also be easily bypassed by attackers. The existing common practice is to do the same check on both sides, and the client check can block most normal users who misoperate, thus saving server resources. Solution: check to see if it contains sensitive characters such as "JavaScript" and "". And the processing of special characters such as "& /'in the string.

3. Output check

Principle: in general, in addition to rich text output, use encoding or escape to defend against XSS attacks when variables are output to HTML pages: * Encoding for HTML code: HtmlEncode * PHP:htmlentities () and htmlspecialchars () two functions * Javascript:JavascriptEncode (special characters need to be escaped using ") At the same time, the output variable must be inside the quotation marks) * output in path (path) or search (parameter) of URL, using URLEncode

4. A stricter approach

All characters except numbers and letters are encoded in hexadecimal

two。 Cross-site request forgery (Cross Sites Request Forgery)

Cross-site request forgery refers to an attack that uses a user's identity to operate a user's account, that is, an attacker induces a user to visit a page and performs an operation in a third-party harmful site as that user, revealing the user's identity information. the attacker can then use the fake but real identity information to impersonate a user to a website to perform malicious operations.

However, an attacker can successfully forge a request only if he predicts all the parameters and parameter values of URL (of course, he can actually manipulate it in his own capacity in the secure site, and can still get the parameters); conversely, the attacker cannot successfully attack.

We can conclude that to complete a CSRF attack, two conditions must be met.

The user logs in to trusted website An and generates Cookie locally

Visit harmful website B without logging out of website A

2.1the principle of CSRF

CSRF attack is a way for attackers to manipulate user accounts using * * 'user identities' * *. For example, Giselle uses underwear to get the fingerprints of Brazilian bosses in the movie Fast and Furious 5, and finally successfully uses forged fingerprints to open the safe. CSRF is just the realization of this technique on the network.

2.2 ways to attack CSRF

1. Browser's Cookie policy

The strategies held by browsers are generally divided into two types: Session Cookie and temporary Cookie. Saved in the memory of the browser process, the browser becomes invalid when it is closed. Third-party Cookie, local Cookie. The server specified Expire Time when Set-Cookie. If the local Cookie expires, the site will require the user to log in again.

* in the process of browsing a website, Session Cookie is valid even if the browser opens the Tab page, so it is feasible to launch a CSRF attack.

Side effects of 2.P3P head

"P3P Header" is a privacy standard developed by the W3C, which is called "The Platform for Privacy Preference" (Privacy preference platform). If the HTTP header returned by the website to the browser contains the P3P header, to some extent, the browser will be allowed to send a third-party Cookie. Under IE, even tabs such as "" and ``will no longer block the sending of third-party Cookie. It is mainly used in pages that require cross-domain access, such as advertising.

3. GETdline post request

* there is a misunderstanding that most CSRF attacks are carried out through

Tags with src attributes, such as tags that can send GET requests only once, but not POST requests, thus giving rise to the wrong view that CSRF attacks can only be initiated by GET requests. To construct a POST request, you just need to construct an form form in an invisible iframe window, and then use JavaScript to automatically submit the form. Then the whole process of automatically submitting the form is invisible to the user.

2.3 Defense methods of CSRF

1. Verification code

Principle: in the process of CSRF attack, the user constructs the network request unknowingly. After adding the CAPTCHA, the user is forced to interact with the application * pros: concise and effective * disadvantages: the website cannot add CAPTCHA to all operations.

2.Referer Check

Principle: * use the Referer in the HTTP header to determine whether the request source is legal * the Referer header contains the address of the source page of the current request page. Generally speaking, the source page of Referer is the page that initiated the request, if the request is initiated in iframe Then the corresponding page URL is the src of iframe * advantages: easy to operate (only need to add an interceptor to all security-sensitive requests to check the value of Referer at the end) * disadvantages: the server can not always get Referer 1. For the sake of protecting the privacy of users, many restrict the sending of Referer. two。 For example, if you jump from HTTPS to HTTP, browsers will not send Referer for security reasons.

3. Use Anti CSRF Token

Principle: encrypt the parameters, or use some random numbers, so that the attacker cannot guess the parameter value, so that the requested URL cannot be constructed and the CSRF attack cannot be launched. Example (add token): * for example, the URL of a delete operation is: `http://host/path/delete?uesrname=abc&item=123` * keep the original parameter unchanged, add a parameter Token, and the token value is random and unpredictable * http://host/path/delete?username=abc&item=123&token=[random(seed)] * advantage: it is safer than checking the Referer method. And does not involve user privacy * disadvantage: encryption 1. The encrypted URL is very difficult to read and very unfriendly to users. The encrypted parameters change every time, making it impossible for the user to search the page. Ordinary parameters will also be encrypted or hashed, which will bring great trouble to the work of DBA, because data analysis often requires the plaintext of parameters token 1. It is difficult to add Token to all requests

Points to pay attention to

Token needs to be random enough and must use a sufficiently secure random number generation algorithm.

Token should be jointly owned by users and servers, and not known by third parties.

Token can be placed in the user's Session or browser's Cookie

Try to put Token in the form, change the sensitive operation from GET to POST, and submit it in the form of form form to avoid Token disclosure (such as a page: http://host/path/manage?username=abc&token=[random], where users need to submit the form or click the "Delete" button to complete the deletion operation. In this scenario, if the page contains a picture that the attacker can specify the address

The page address will be sent to the server of evil.com as the Refer of the HTTP request, resulting in Token disclosure)

2.4 XSRF

When there are both XSS and CSRF vulnerabilities in the website, XSS can simulate the client browser to perform any operation. Under the XSS attack, the attacker can completely request the page, read the token value in the page content, and then construct a legitimate request.

3. Click to hijack (ClickJacking)

Click hijacking is a visual deception. The attacker uses a transparent, invisible iframe to overwrite a web page, and then induces the user to operate on the web page, where the user will unknowingly click on the transparent iframe page. By repositioning the iframe page, you can induce the user to click right on some of the functional buttons on the iframe page.

For example, when visiting the A page, programmer Xiao Wang clicked on the blank area, but the browser accidentally opened the page of xx's new Lisboa Casino, so he opened the console on the A page and found a transparent iframe in the blank area. The iframe embedded the URL of a third-party web page.

3.1 Click hijacking Defense

The 1.X-Frame-Options HTTP response header is used to indicate to the browser whether a page can be displayed in `or`. The tag # has three optional values 1. DENY: the browser will refuse to load any frame pages on the current page (even pages with the same domain name are not allowed) 2. SAMEORIGIN: allow loading of frame pages But the address of the frame page can only be the page 3. ALLOW-FROM under the same origin domain name: you can load the frame page from the specified source (you can define the address of the frame page) 2. Prohibit the nesting of iframe if (window.top.location! = = window.loaction) {window.top.location = = window.self.location}

4. Other security issues

4.1Cross-domain problem handling uses the wildcard "*" when setting 'Access-Control-Allow-Origin'' on the server to allow cross-domain requests from any domain, which is extremely dangerous. 4.2 postMessage cross-window transmission information postMessage allows each window (including the current window, pop-up window, iframes, etc.) object to send text messages to other windows, thus achieving cross-window message delivery. And this feature is not limited by the same origin policy. If necessary, validate the Domain or even the URL in the accept window to prevent messages from illegal pages. It is actually a verification process of the same origin policy in the code. The acceptance window makes a security check on the information of the interface. 4.3The Web Storage Web Storage is divided into Session Storage and Local Storage. Although it is constrained by the same origin policy, it may also be the target of attack when sensitive information exists.

5. Summary

Careful user input information, input check (client and server check at the same time)

When variables are output to HTML pages, they should be encoded or escaped to prevent XSS attacks

Be sure to add the CAPTCHA when you should use it.

Try to add Token parameters to important requests, and note that Token should be random enough to use a sufficiently secure random number generation algorithm

At this point, I believe that you have a deeper understanding of "what front-end security coding specifications", you might as well come to the actual operation! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.