Web Security: A Small Summary of Common Attacks and Defenses

Recently, I’ve been reading a classic book, “White Hat on Web Security” (Amway, Dao is very interesting to write), and then associated with some of the usual work in the Web security measures, decided to record, summarize.

XSS

What is XSS?

XSS (Cross Site Scripting), the full name of cross-site scripting attack, that is, a kind of vulnerability that allows malicious web users to implant code into website pages, is a kind of code injection. It is generally categorized into these types:

• Reflexive XSS: passive, non-persistent. Hackers usually need to trick users into clicking on a malicious link in order to achieve the attack. url can also be shortened by short URL services to hide itself.
• Stored/Persistent XSS: Active, persistent. Hackers usually write a web page containing malicious code in their website (e.g. a blog). All users who visit this page will execute this code in their browsers, and thus the hacker achieves the goal of the attack.
• DOM Bases XSS: XSS formed by modifying the DOM nodes of a page.

Defense measures

1. httponly

httpOnly is an attribute of the set-cookie field in the http return header. A cookie with the HttpOnly attribute set cannot be accessed using JavaScript via document.cookie, XMLHttpRequest, and Request APIs to protect against post-XSS cookie hostage attacks. Here is an example:

<?php
   header('set-cookie: USER=123;PW=123456;HttpOnly');
?>

The return header will be included:

Set-Cookie: USER=123;PW=123456;HttpOnly

1. Input checking

Format checking of input i.e. ‘XSS Filter’. php has some built-in filter functions htmlentities, htmlspecialchars, strip_tags etc…. However, these functions may not be able to filter the whole thing. In this case, you can check the parameters in the request by regular matching (similar to the practice of “whitelisting”). nodejs, there are a lot of open source implementations of checking formats on the web, such as better-validate.

1. Output checking For output in HTML, in PHP, you can use htmlentities or htmlspecialchars to convert all html tags or format special symbols (&, ‘, “, <, >); for output in JavaScript, perform JavaScript encoding (escape special characters using ‘ In addition to numeric letters, characters smaller than 127 are encoded using hexadecimal ‘\xHH’, and larger than that with unicode); for output in CSS, CSS encoding (similar to JavaScript encoding); for output in address, in js, you can use the encodeURI() function.

CSRF

What is CSRF?

CSRF (Cross Site Request Forgery). An example: An attacker tricks a user into visiting a page, and then performs an action on a third-party site as that user, such as deleting a blog post.

Difference between CSRF and XSS XSS: Users overly trust a website and let the website code execute, allowing malicious scripts to implant the code into the website pages (focusing on scripting) CSRF: the website overly trusts the user and lets fake requests from legitimate users execute certain functions of the website (focusing on forgery)

CSRF Advanced

1. Browser cookie policy:

Browser cookies are divided into two types: a session cookie, without a specified expiration, is stored in the memory space of the browser process, and will expire after the browser is closed; the other is a third-party cookie (local cookie), which is stored locally, and will expire only when the specified expiration time is reached. will expire only after the specified expire time. In tags such as <img>, <frame>, <script>, <link>, etc., session cookies are sent, while third-party cookies depend on browser policy. Some browsers disable the sending of third-party cookies by default, while others do not block them, which can be easily exploited by CSRF attackers. Browsers that won’t block them are: Firefox3, Opera, Google Chrome, Android, etc.

1. P3P Header side effects P3P Header (The Platform for Privacy Preferences) is a standard specified by W3C. If a website returns a HTTP header to a browser that contains the P3P Header, the browser is allowed to send third-party cookies, even if it prohibits sending third-party cookies in <frame>, <script>, etc. as described above for browsers such as Internet Explorer.

Defense measures

1. referer

The referer is a field in the http request header that tells the server which page the request came from. XSS can be prevented by determining the referer field.

$refererUrl = parse_url($_SERVER['HTTP_REFERER']);
$host = $refererUrl['host'];
if(!isset($_SERVER['HTTP_REFERER']) || $referurl['host'] !== 'www.example.com') {
   exit('非本站请求!');
}

However, the referer value is provided by the browser. Certain browsers, such as IE6, FireFox2, currently have vulnerabilities that can be exploited by hackers to tamper with the referer value. As you can see, this method is not foolproof. Moreover, the server doesn’t always get the referer, users can limit the referer sending, and the browser won’t send the referer in some cases (https to http). And, as we know, server-side scripts can easily forge the referer, so this method of prevention is obviously not enough. We can verify it with CAPTCHA, or we can use document.referer on the client side to determine more accurately the real origin of the page.

1. Adding a token to the request address and validating it. On the client side, for a get request, add the token as a parameter to the url, such as https://url?csrftoken=tokenvalue; for a post request, add <input type="hidden" name="csrftoken" value="tokenvalue"/>. On the server side, intercept the validation of this token and reject requests without a token or with an incorrect token. For example, the token can be generated after the user logs in and placed in the session, and each time a request is made, the token in the request is compared to the token in the session. Or use a cryptographic algorithm to generate the token, and then verify its legitimacy on the server side. However, this method requires adding a token to each request, which is troublesome and easy to expose. Hackers can get the token from the request (or through the referer) and then launch CSRF attacks. In order to avoid this, we need to add a judgment when adding the token: if it is linked to this site before adding the token.
2. in the http header custom attributes and validation This method also uses the token for authentication, the difference is that this method through the XMLHttpRequest class to put the token into the http header in the custom csrftoken attribute. This way, the address requested through XMLHttpRequest will not be recorded in the browser’s address bar, and you don’t have to worry about the token leaking through the referer to other websites. The limitation of this approach is that it is usually only used for Ajax methods.

let xhr = new XMLHttpRequest()
xhr.open('POST', 'https://example.com')
xhr.setRequestHeader('token', 'XXXXXXXXXX')
// 其他设置
xhr.send()

When customizing some header attributes for cross-domain requests, you may encounter “not allowed by Access-Control-Allow-Headers in preflight response”, you may need to set “Access-Control-Allow-Headers” on your server side. Headers” on your server.

1. Captcha

CAPTCHA forces the user to have to interact with the application and is usually a good deterrent to CSRF attacks. As written in php: the front-end page stores the randomly generated CAPTCHA in $_SESSION['authcode'], and the back-end compares $_SESSION['authcode'] and $_POST['authcode']. The limitation of this approach is that it aggravates the tediousness of user operations.

Reference

• White Hat Speaks on Web Security
• CSRF Attack Response