After some 996, carefully built website will soon be subordinate to the online, but before the official launch of the website, have you ever thought about whether your website is safe? Although your site uses a lot of lofty technology, but if the security of the site is insufficient, unable to protect the site’s data, or even become a parasitic hotbed of malicious programs, then the front of the pile up more good has become in vain.

SQL injection

Of all the security vulnerabilities, SQL injection is by far the most serious but also the most manageable. When the database executes the query sentence, it may occur if the parameters given by malicious users are directly concatenated to the query sentence.

For example, suppose the original query for login verification on a website looks like this:

strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');"
Copy the code

The malicious user enters the following parameters:

userName = "1' OR '1'='1";
passWord = "1' OR '1'='1";
Copy the code

Since the code directly concatenates the parameters with the query clause as a string, the SQL will look like this:

strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');" // strSQL ="SELECT * FROM users;"
Copy the code

In this way, the account password is invalid, and you can even get the entire database structure (SELECT * FROM sys.tables), modify it, and query the data, and the entire site is exposed.

The solution, however, is as simple as parameterizing queries to avoid concatenating parameters directly with query clauses, doing proper input checking, inserting escape characters, and strictly setting program permissions, to avoid SQL injection.

XSS

XSS (cross-site attack), also known as JavaScript injection, is one of the most frequent problems on modern websites. It refers to the insertion of other code into a website by a malicious user, usually when a website puts user input directly into the site’s content. For example, forum, message board and other websites that can input any text, malicious users may be subjected to XSS if they write a small section of

There are several common types of XSS: stored XSS that writes malicious code to a database and executes when the data is read out; Reflective XSS that brings user input directly back to the page; As well as DOM-based XSS that uses DOM features to execute malicious code in various fancy ways.

Storage and reflection are easy to understand, dom-based is very interesting; A Cheat Sheet on XSS Filter is organized by OSWAP. Most XSS methods are implemented by background-image attributes or callbacks to events on elements. SVG is particularly noteworthy, because SVG can write arbitrary HTML, but also can add onload event, if SVG as a common image processing, directly used as the content of the website, if the malicious users, the consequences are unimaginable. Be sure to filter out SVG when uploading images online!

The way to avoid XSS is as simple as converting the data in and out so that the malicious code is not executed but parsed into characters.

CSRF

CSRF (Cross-site request forgery) is an attack method using Cookie and Session authentication mechanism. As Session authentication is not the user himself, but the browser, as long as the DOM element of the web page can make cross-domain request to the authenticated website, it can impersonate the user and get sensitive information.

For example, the URL of a bank’s transfer API looks like this:

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
Copy the code

If a malicious user inserts a into a website:

<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">
Copy the code

This request is automatically made by when an unsuspecting user visits the attacker’s website. If the user’s login Session has not expired, the request is likely to be accepted by the bank and “transferred” without the user’s knowledge.

This type of attack can complement XSS, for example, if you embed in a forum site without XSS protection, its SRC attribute should be the API URL that gets sensitive information.

The solutions are as follows:

  • Referer check: The server side checks the value of the Referer in the request header, that is, the source of the request, if it is from an approved site, then the API functions properly.
  • CSRF Token: to both Cookie and request sent datacsrftokenAnd check whether the value is the same, if the source of the request is their own website verification will pass; On the other hand, because external websites cannot get cookies from other websites in their code, they cannot be carried in the requestcsrftoken.
  • SameSite Cookie: Add to CookieSameSiteProperty to ensure that cookies can only be used on your own site.

JSON hijacked

JSON hijacking is the use of the front and back of modern websites through API data exchange features, as long as you can obtain user rights, and call the API to obtain data, plus rewrite native JavaScript objects, you can steal sensitive information users.

Access to the same part of the CSRF, through the

Such as:

Object.prototype.__defineSetter__('user'.function(obj){
  for(var i in obj) {
    alert(i + '='+ obj[i]); }});Copy the code

When the returned data contains the user attribute, the values in user are all read because the Setter is overwritten with Object.prototype.__definesetter__.

Object.prototype.__definesetter__ can fix native objects. This was fixed in ES4, and JSON hijacking was abolished, but since ES6 proxies have been added. JSON hijacking is possible again:

<script>
<script>
  Object.setPrototypeOf(
    __proto__,
    new Proxy(__proto__, {
      has: function(target, name) {
        alert(
          name.replace(/./g.function(c) {
            c = c.charCodeAt(0)
            return String.fromCharCode(c >> 8, c & 0xff)}))}})</script>
<script charset="UTF-16BE" src="external-script-with-array-literal"></script>
Copy the code

It looks scary, so how do you solve it? In addition to the CSRF Token mentioned above, there is another interesting solution adopted by many large companies. That is, the API’s response content begins with for (;;). ; “, which takes advantage of the instant execution of JavaScript introduced by

conclusion

In addition to the four common vulnerabilities mentioned in this article, there are many other details a website needs to consider, such as not storing sensitive information such as passwords in plain code, restricting traffic to source IP to prevent DOS, and so on. So in the development of the website to maintain security awareness, as far as possible to do a good job of basic protection measures.