Common attack

Cookie holding

HTTP is a stateless protocol that introduces cookies and sessions to maintain and track user status. Cookies contain the user credentials of the browser client and are relatively small. Sessions are maintained on the server and are used to maintain relatively large user information. You can think of cookies as passwords, and sessions as safes. Because HTTP is transmitted in clear text, cookies can be easily stolen. If stolen, someone can impersonate your identity, open your safe, get your information, and use your money, which is very dangerous.

The relationship between Cookie and Session can be seen in this article: A Brief Introduction to the relationship between Session and Cookie

1. The harm

Steal cookie information, impersonate the identity of others, steal information.

2. The defense

  • tocookieaddHttpOnlyProperty, which can only be set inhttpPass in the request, in the script,document.cookieCould not get thiscookieValue, which defends against XSS attacks, but still leaks against network interception.
  • incookieTo add verification information that is related to the current user’s external environment, for exampleip,user agentAnd so oncookieWhen hijacked, the verification value is changed on the server. Therefore, users are required to log in again to avoid this problemcookieHijacking.
  • cookieIn thesession idThe regular replacement, letsession idAt the same time, the operation is transparent to users, which ensures the consistency of service experience.

XSS cross-site scripting attacks

An attacker inserts HTML or script tags into a Web page maliciously. When the user browses the page, the malicious code will be executed to achieve the purpose of attack. XSS leverages the user’s trust in a given site.

Type 1.

  • Reflective (non-persistent) : The attacker makes the attack link in advance and needs to trick the user to click the link to trigger the XSS code. The so-called reflective XSS is to reflect the JS script entered by the malicious user to the browser for execution.

  • Stored (persistent) : The attacker’s data is stored on the server, and the attack will always exist with the attack data. Whenever the user visits the page, the code execution will be triggered.

  • DOM: Vulnerability based on the document Object model.

The most classic stored XSS vulnerability is the message board, when user A leaves A JS code , the back end is directly stored in the database without filtering, when normal users browse to his message, this JS code will be executed, can be used to steal cookies.

Harm 2.

  • Steal web browsingcookieValue,cookieAchieve no password login, steal user information.
  • Hijack access to achieve malicious jump.
  • Cooperate with CSRF attack to complete malicious request.

3. Defense methods

  • Label filtering, for example<script>,<img>,<a>Labels etc.
  • Encoding, pair of characters< 、>,&," 、' 、+,/And so on.
  • cookieGuard against theft,cookieSet tohttp-only.jsThe script will not be able to readcookieInformation.
  • Pure front-end rendering, clearinnerText,setAttribute,styleTo separate code from data.
  • Avoid untrusted data concatenated into strings passed to theseAPI, such asDOMInline event listeners in,location,onclick,onload,onmouseover, etc.<a>Of the labelhrefProperties,JavaScripttheeval(),setTimeout(),setInterval()Etc., can run strings as code.

CSRF cross-site request forgery

As the name implies, it is an attack method that allows users to complete unintended operations with their own identities by forging connection requests without their knowledge. CSRF takes advantage of a web site’s trust in the browser.

Principle 1.

  1. The userCBrowse and log in to trusted websitesATo producecookie
  2. The userCNot exiting the siteA, in the same browser dangerous access to the siteB
  3. Web siteBThe page contains some offensive code that will issue a visitAThe request of
  4. The browser receives the request and carries it without the user’s knowledgecookieVisit the web siteA
  5. AIf you don’t know who sent the request, the browser will pick up the usercookie, soAIt will be processed according to the user’s permissionBRequest made. That would accomplish the purpose of the attack.

2. The defense

  • Verification code: Add verification code to sensitive operations to force users to interact with the site
  • usePOSTRequest, avoid usingGET, reduce the risk of attack,postThe requesting attacker needs to construct oneformA form can initiate a requestgetRequest (imgthesrc.aOf the labelhrefAnd so on) are a bit more sophisticated, relatively risk-reducing, but not deterring.
  • checkHTTPIn therefererField, which recordsHTTPThe source address of the request
  • Add to the request headertokenValidation fields, which the browser does not automatically carryTokenTo request, andTokenCan carry a coded piece ofjwtFor authentication, do thisCSRFWhen only passedcookie, does not identify the user, and the site rejects the attack request.
  • inhttpTo customize the attributes and validate.

Click on the hostage

  • ClickJacking

When you visit a website, use CSS to hide the page that the attacker actually wants you to click on, and then display something at the back of the page to induce you to click on it, which will do something without the user knowing it. This is ClickJacking.

  • The iframe cover

Third party websites embed a website through iframe, and set the IFrame to be transparent and invisible, and overlay it on other camouflaged DOM. The camouflaged clickable DOM (button, etc.) is the same as the actual clickable DOM of the embedded website. When the user clicks the camouflaged DOM, You actually click on the DOM of the webpage embedded in the IFrame to trigger the request action.

defense

  • Javascript disables embedding: When a page is not embedded with iframe, top and window are equal; When a page is embedded, top and window are not equal; You can add the following judgments on the page of this website:

    <script>
    if(top.location ! =window.location) {
        // If no, iframe is used. You can perform related operations
    }
</script>
Copy the code

    This is not a panacea, however, because the sandbox property in the iframe tag can disable scripts for embedded pages:

    <iframe sandbox='allow-forms' src='... '></iframe>Copy the code

  • Setting the HTTP response header x-frame-options is by far the most reliable method. X-frame-options is an HTTP header proposed by Microsoft to defend against clickjacking attacks using nested iframe.

DENY // SAMEORIGIN is prohibited // Only allow-from within the same domain name is allowed // Specify the address that can be embeddedCopy the code
  • Some auxiliary means, such as adding captcha, raise users’ awareness of precautions