This article describes various types of security attacks and mitigating them.

Clickjacking

performance

Clickjacking attacks allow malicious pages to click on “victimized sites” in the user’s name.

implementation

  1. After the user logs in to weibo,weibo.comthecookiesContains login information.
  2. A user visits a malicious page (perhaps clicking on an AD or otherwise);
  3. Malicious pages embedded in a transparent<iframe>, itssrcFrom theweibo.com;
  4. The page seduces the user to click on one<button>In fact, the user is clicking on the overlay from<iframe>The “like” button of weibo 👍;

defense

useSamesite cookiefeatures

Cookies with the SameSite feature are only sent to a web site if the web site is opened directly (not by iframe or other means). If the site has the Samesite feature in the cookie, it looks like this: set-cookie: authorization=secret; SameSite =Lax, this kind of cookie will not be sent when you open a Tweet in another website’s iframe, the tweet fails to log in, and the attack fails.

XSS(Cross-Site Scripts)

Cross-site scripting attacks: XSS because CSS is easily confused with style sheet abbreviations;

performance

The attacker injects malicious JS code into the website.

source

  1. The information generated from the user is not cleaned at the back end. It is directly spliced into HTML and returned to the client.
  2. From URL: front-end or back-end fromurl query,url hashConcatenate directly read parameters into HTML.

classification

XSS attacks fall into three categories: stored (also known as persistent), reflective (also known as non-persistent), and DOM-based.

  1. Stored XSS attack

    1. The attack code comes from user input, such as comments and message functions.
    2. Injected scripts are permanently stored on the target server. Then, when the browser sends a data request, the victim retrieves the malicious script from the server.

  2. Reflex XSS attack

    1. The attack code comes from the URL
    2. When a user opens a URL with malicious code, the server takes the malicious code out of the URL, splices it into HTML and returns it to the browser.

  3. DOM based XSS attack

    1. The attack code comes from the URL
    2. When a user opens a URL with malicious code, the front-end JavaScript picks up the malicious code in the URL and executes it.
    3. Obtaining and executing malicious code is completed by the browser, which is a security vulnerability of front-end JS code itself.

defense

  • Switch to pure front-end rendering, separating code from data;
  • Fully escape HTML;
  • Do not concatenate untrusted data into a string and pass it to JS execution;
  • useCSPSecurity policy;
  • useSamesite Cookies,HttpOnlyEven if it is injected with malicious code, the attacker cannot get itCookie;

CSRF(Cross-Site Request Forgery)

performance

  1. The user logs in to the bank’s websitebank.com.bank.comUnder thecookiesThe user login is storedtoken;
  2. Users visited malicious sitesevil.com.evil.comThe form is set up in the web page
  3. evil.comtobank.comA request was sent:bank.com?payfor=22000&to=xoyimi. Browsers carry it by defaultbank.comthecookies.
  4. bank.comUpon receipt of the request, the request is validated and identified as the victim’s credentials, mistaking it for a request sent by the victim himself.
  5. bank.comExecuted on behalf of the victimpayfor=22000&to=xoyimi.

way

Requests can be sent through image urls, hyperlinks, CORS, Form submissions, and everything else.

defense

  1. Verify the HTTPRefererandOriginRequest header;
  2. Customize attributes in HTTP headers and validate or use themCSRF-TokenTechnology (because third-party sites only send cookies, not custom headers);
  3. inCookieSet in thesameSite=[Lax|Strict], Chrome 51 and above can enable this feature;
  4. Instead of adding, deleting, or modifying a GET request,sameSite=LaxThe form GET request is sent by defaultCookie;

Tips: plan 1,2: prevent hackers from cooperating with XSS attacks to obtain same-origin script execution permission;

Here’s a look at SameSite Cookies

Chrome 80 defaults to SameSite=None. SameSite=Lax is enabled by default for Chrome 80 and later. Writing SameSite alone equals SameSite=Strict. It’s worth noting that Firefox and Safari don’t have SameSite=Lax on by default and still need to set it manually.

Cross-site request type The sample None Lax Strict
Page jump <a href="..." ></a> Send a Cookie Send a Cookie Don’t send
Page jump window.open() Send a Cookie Send a Cookie Don’t send
Page jump Change the location Send a Cookie Send a Cookie Don’t send
Page jump <form method="GET" action="..." > Send a Cookie Send a Cookie Don’t send
Page jump <form method="POST" action="..." > Send a Cookie Don’t send Don’t send
Preload (prejump) <link rel="prerender" href="..." /> Send a Cookie Send a Cookie Don’t send
In-page cross-site request <iframe src="..." > Send a Cookie Don’t send Don’t send
In-page cross-site request <img src="..." > Send a Cookie Don’t send Don’t send
In-page cross-site request ajax (withCredentials:true) Send a Cookie Don’t send Don’t send
In-page cross-site request fetch (credentials:include) Send a Cookie Don’t send Don’t send

It is worth noting that even though the Ajax/FETCH declaration carries credentials, cookies are not sent under SameSite=[Lax/Strict].

And CSRF wordy ~

All of these are cross-station situations.

Citation:

  1. Developers.google.com/search/blog…
  2. SameSite Updates (chromium.org)
  3. “SameSite” | Can I use… Support tables for HTML5, CSS3, etc