1. XSS (Cross Site Scripting) Cross-site Scripting attacks

1.1 definition:

XSS is a computer security vulnerability common in Web applications. Malicious attackers embed malicious scripts into Web pages. Most XSS vulnerabilities are caused by improper processing of user input, resulting in the execution of malicious scripts in the browser. Any place you enter submitted data is likely to have XSS.

1.2 Attack Principles

No need to do login authentication, inject scripts (JS, HTML code blocks) into your page through legitimate actions (such as entering in urls, entering in comment boxes),

1.2.1 Consequences of attacks

  • Stealing cookies
  • Breaking page structure
  • Insert ads
  • To carry a Trojan
  • Navigate to malicious sites, etc

1.3 Attack Mode:

Mode 1: reflex type

  1. When the request is made, the XSS code appears in the URL and is submitted to the server as input,
  2. The server parses the response, and the XSS code is sent back to the browser along with the response.
  3. Finally, the browser parses and executes the XSS code.

This process is like a reflection, so it’s called reflective XSS.

Mode 2: Storage type:

The difference between memory XSS and reflection XSS is that

  1. The submitted code is stored on the server side (database, memory, file system, etc.),
  2. You don’t have to submit the XSS code the next time you request the target page.

For example, a script written in the comment function is submitted and saved in the database, which will be executed every time the comment list is loaded, causing greater harm.

1.4 How to Defend [Key] :

Method 1: code

JavaScript encoding of untrusted data. encode

Method 2: XSS Filter

For the content submitted by users, only the length and content specified by us are accepted, and other content is filtered out

  • The form data specifies the type of the value: age must be int, name must be alphanumeric, and so on.
  • Filter or remove special HTML tags:< script >, < iframe >And so on.
  • Filter js event tags: onclick, onError, onfocus, etc.

Method three: correction

The presence of HTML entities is one of the main causes of XSS vulnerabilities, so we need to convert the entities into responsive entity numbers. For example, the < < sign should be <

2. Cross-site Request Forgery (CSRF

2.1 background

As we know, the vast majority of websites identify user identities through cookies (including those that use server-side Session, because Session IDS are mostly stored in cookies) and then grant authorization. Therefore, to forge the normal operation of the user, the best way is through XSS or link spoofing and other ways, so that the user in the local machine (that is, the browser with identity cookie) to initiate the user does not know the request.

2.2 Attack Mechanism

To complete a CSRF attack, two conditions must be met

  • Log in to trusted WEBSITE A and generate cookies locally
  • Visit B’s website without logging out of A

To put it simply: the user visits the dangerous website B in website A, and B requests to visit website A, and the browser visits A with cookies

The cookie guarantees that the user can be logged in, but site B can’t actually get the cookie.

2.2.1 Attack Consequences

You can transfer your money directly from the bank

 <img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
Copy the code

2.3 How to defend [!! Key!!] :

Method 1: Referer verification (least secure, but easiest)

According to the HTTP protocol, there is a field in the HTTP header called Referer that records the source address of the HTTP request. Only accept the request of this site, the server will respond; If not, intercept.

Advantages:

  • Simple and logical without changing existing code

Disadvantages:

  • Browsers implement referer differently, which is equivalent to relying on third parties to safeguard it
    • For some browsers, such as IE6 or FF2, there are already ways to tamper with the Referer value
  • Users can set up their own request without providing the referer, so the website will consider the absence of the referer value as a CSRF attack and reject the user’s access

Method 2: Token authentication

CSRF attacks are successful because hackers can completely fake user requests. You can add a randomly generated token as a parameter to the HTTP request and set up an interceptor on the server side to verify the token. If there is no token in the request or the token content is incorrect, The request is rejected as a possible CSRF attack.

Disadvantages:

Add tokens manually or iteratively for all requests

Method 3: Customize attributes in the HTTP header and validate

Token is also used, but in custom attributes

Advantages:

  • You can add this header attribute to all class requests at once
  • XmlHttpRequest requests addresses that are not logged to the address bar by the browser, and there is no need to worry about tokens being leaked to other sites through Rederer

Disadvantages:

  • XHR requests are typically used to asynchronously refresh partial pages of Ajax because they are not logged by the browser, so there is no forward or backward action
  • Refactoring costs are too high for legacy systems without CSRF protection

3. Differences between XSS and CSRF:

CSRF XSS
You need to log in to website A You don’t need to log in
Is to use the vulnerability of website A itself, to request the API of website A Inject JS code, and perform, tamper with the contents of Site A

Conclusion:

XSS and CSRF are two cross-site attacks, one through input scripts and the other through forged requests. In case of defense, CSRF can pass cross-domain authentication, that is, token. Because the token information cannot be forged by hackers, it can be defended. Referer can also be used. XSS basically filters the encoding to restrict the input