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.
| Prerequisites: | Basic computer literacy. |
|---|---|
| Objective: | To understand the most common threats to web application security and what you can do to reduce the risk of your site being hacked. |
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 homepages. 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. The more formal definition of 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, the configuration of the web server, your policies for creating and renewing passwords, and the client-side code. While all that sounds very ominous, the good news is that if you're using a server-side web framework, it will almost certainly enable "by default" robust and well-thought-out defense mechanisms against a number of the more common attacks. Other attacks can be mitigated through your web server configuration, for example by enabling HTTPS. Finally, there are publicly available vulnerability scanner tools that can help you find out if you've made any obvious mistakes.
The rest of this article gives you more details about a few common threats and some of the simple steps you can take to protect your site.
注意： This is an introductory topic, designed to help you start thinking about website security, but it is not exhaustive.
This section lists just a few of the most common website threats and how they are mitigated. As you read, note how threats are most successful when the web application either trusts, or is not paranoid enough about the data coming from the browser.
XSS is a term used to describe a class of attacks that allow an attacker to inject client-side scripts 透过 the website into the browsers of other users. Because the injected code comes to the browser from the site, the code is trusted and can do things like send the user's site authorization cookie to the attacker. When the attacker has the cookie, they can log into a site as though they were the user and do anything the user can, such as access their credit card details, see contact details, or change passwords.
注意： XSS vulnerabilities have been historically more common than any other type of security threat.
The XSS vulnerabilities are divided into reflected and persistent , based on how the site returns the injected scripts to a browser.
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 earlier, 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.
While the data from
POST
or
GET
requests is the most common source of XSS vulnerabilities, any data from the browser is potentially vulnerable, such as cookie data rendered by the browser, or user files that are uploaded and displayed.
The best defense against XSS vulnerabilities is to remove or disable any markup that can potentially contain instructions to run the code. For HTML this includes elements, such as
<script>
,
<object>
,
<embed>
，和
<link>
.
The process of modifying user data so that it can't be used to run scripts or otherwise affect the execution of server code is known as input sanitization. Many web frameworks automatically sanitize user input from HTML forms by default.
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.
SQL injection types include Error-based SQL injection, SQL injection based on boolean errors, and Time-based SQL injection.
This vulnerability is present if user input that is passed to an underlying SQL statement can change the meaning of the statement. For example, the following code 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 specifies a real name, the statement will work as intended. However, a malicious user could completely change the behavior of this SQL statement to the new statement in the following example, by specifying the text in bold for the
userName
.
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';
The modified statement creates a valid SQL statement that deletes the
users
table and selects all data from the
userinfo
table (which reveals the information of every user). This works because the first part of the injected text (
a';
) completes the original statement.
To avoid this sort of attack, you must 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.
注意： The SQL statement treats the ' character as the beginning and end of a string literal. By putting a backslash in front of this character ( \' ), we escape the symbol, and tell SQL to instead treat it as a character (just a part of the string).
In the following statement, we escape the ' character. The SQL will now interpret the name as the whole string in bold (which is 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 the character escaping for you. Django, for example, ensures that any user-data passed to querysets (model queries) is escaped.
注意： This section draws heavily on the information in Wikipedia here .
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 of money. 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 associated with the site (adding associated site cookies to requests is normal browser behavior). 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.
注意： The trick here is that John doesn't need to have access to the user's cookies (or access credentials). The browser of the user stores this information and automatically includes it in all requests to the associated server.
One way to prevent this type of attack is for the server to require that
POST
requests include 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:
<iframe>
controlled by the attacker. Clickjacking could also 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 defense, your site can prevent itself from being embedded in an iframe in another site by setting the appropriate HTTP headers.
../../
). The solution is to sanitize input before using it.
For a comprehensive listing of website security threats see Category: Web security exploits (Wikipedia) and Category: Attack (Open Web Application Security Project).
Almost all of the security exploits in the previous sections are successful when the web application trusts data from the browser. Whatever else you do to improve the security of your website, you should sanitize all user-originating data before it is displayed in the browser, used in SQL queries, or passed to an operating system or file system call.
警告：
The single most important lesson you can learn about website security is to
never trust data from the browser
. This includes, but is not limited to data in URL parameters of
GET
requests,
POST
requests, HTTP headers and cookies, and user-uploaded files. Always check and sanitize all incoming data. Always assume the worst.
A number of other concrete steps you can take are:
POST
requests data and header information are not easily available to attackers.
Web frameworks can help mitigate many of the more common vulnerabilities.
This article has explained the concept of web security and some of the more common threats against which your website should attempt to protect. Most importantly, you should understand that a web application cannot trust any data from the web browser. All user data should be sanitized before it is displayed, or used in SQL queries and file system calls.
With this article, you've come to the end of this module , covering your first steps in server-side website programming. We hope you've enjoyed learning these fundamental concepts, and you're now ready to select a Web Framework and start programming.
最后修改： , 由 MDN 贡献者