网络方面的英文文献.docx

上传人:b****9 文档编号:25137482 上传时间:2023-06-05 格式:DOCX 页数:20 大小:83.86KB
下载 相关 举报
网络方面的英文文献.docx_第1页
第1页 / 共20页
网络方面的英文文献.docx_第2页
第2页 / 共20页
网络方面的英文文献.docx_第3页
第3页 / 共20页
网络方面的英文文献.docx_第4页
第4页 / 共20页
网络方面的英文文献.docx_第5页
第5页 / 共20页
点击查看更多>>
下载资源
资源描述

网络方面的英文文献.docx

《网络方面的英文文献.docx》由会员分享,可在线阅读,更多相关《网络方面的英文文献.docx(20页珍藏版)》请在冰豆网上搜索。

网络方面的英文文献.docx

网络方面的英文文献

网络方面的英文文献

在IEEE通信学会的主题专家的方向在IEEEICC这全文论文同行评审的出版2009程序

 

敏感数据要求:

做网站询问是否正确?

克雷格A.树和Minaxi古普塔

计算机科学系

印第安纳大学

{cshue,minaxi}@cs.indiana.edu

摘要:

为了确保敏感的Web内容的安全性,一个组织必须使用TLS以确保这样做正确。

然而,很少有人知道如何使TLS实际使用在网站上。

在这项工作中,我们进行大规模的网络范围内的测量,以确定如果网站需要使用TLS的时候,当他们这样做,确保他们使用它正确。

我们发现,其中TLS几十万页要么不使用要么使用不当,将会使敏感数据处于危险之中。

引言

该网站提供了电子商务前所未有的机遇。

此类交易的安全性是一般

通过使用传输层安全提供

性(TLS)协议[1],在标准跟踪安全的后继

套接字层(SSL)协议。

TLS允许客户端验证

他们访问和服务器的真实性保证

在客户端之间的通信的保密性和

服务器安全。

虽然以前的工作分析TLS证书和

该协议本身,很少的工作重点在其网站上使用。

本文由愿望所驱使,了解TLS是怎么

在今天的网络上被使用的。

Web内容的很大一部分

是公开可用的,并且不要求保密性。

很多情况下,如阅读新闻的文章或使用搜索

发动机,TLS保护的好处不超过

性能开销与该协议有关。

其他情况下,敏感信息被发送并应

通过TLS进行保护。

然而,仅仅使用TLS不

够了;它仍然必须正确使用。

调查TLS

使用在网络上,我们提出两个主要问题:

是否有

在网络上的网站,不使用TLS时,他们应注意什么?

做到这一点使用TLS这样做正确的网站?

动力

对于第一个问题是敏感信息可能

通过窃听者很容易被截获,除非使用TLS。

第二个问题是通过观察,TLS动机

保护必须从Web服务器发送一个表格前

到客户端。

否则,将含有一个表格页可以

被攻击者改变,允许敏感截取

数据。

几大机构,包括,

,或,建立了TLS

客户端后,保护已下载的网页,但在此之前

提交表单数据。

这种做法,被称为安全的岗位,是

通常由具有高体积的组织

用户流量从未签署到页面上的表单。

特别常见的,当窗体出现在主

一个网站的页面。

这些组织使用安全后,以避免

与TLS的nonauthenticating相关的性能开销

客户端。

不幸的是,这种做法提供了anopening攻击者假冒网站和推出

一个中间人攻击的Web客户端。

为了研究这些安全性差的做法的程度,我们

实现了一个网络爬虫和检查HTML表单

430万网页。

我们做了几个关键的观察

从这样的分析。

首先,网页31-36%不使用

TLS在所有的时候,他们应该。

为了解决这个问题,我们

已经实现了浏览器扩展,警告用户约

进入网页上做的核潜艇和信用卡号码

除了不使用TLS来识别领域的询问敏感

数据。

这导致更少的,但更精确的警告。

手动评估分机的有效性,我们

没有发现假阳性和两种可能的假阴性。

其次,我们发现不安全的网页,有形式,1.65%的-

4.49%有被通过HTTPS提交的至少一种形式中,

导致安全交漏洞。

如果剥削,不安全

入口点可能会导致欺诈,可能与显著

财务影响的用户和脆弱的部位。

我们提出了一个浏览器扩展,试图验证这些

使用TLS提交敏感数据的切入点和

如果这样的验证失败发出警告。

本文的其余部分的结构如下。

在第二节,

我们讨论我们的数据收集和方法。

在第三节,

我们研究的网站,不提供TLS保护敏感

数据并提出了一些预防措施,用户可以利用。

在第

第四,我们分析认为滥用TLS和建议clientbased网站

策略来解决这个问题。

我们回顾相关

在第五节工作,并得出结论:

在第六节。

 

II。

数据收集和方法

为了获得对TLS使用的见解,我们进行了大规模的,

Internet范围的Web爬行。

我们把我们的抓取成四

数据集,其被选择来捕获不同类型的

网页:

热门的网页,这些访问的机器上我们

网络,并且这些随机选择的。

在第一数据集,我们把它称为DMOZ

广度的数据集,我们获得了从一个网址列表

DMOZ开放目录项目[2]。

DMOZ的项目包括

形成一个目录查找用户提交的链接的

数据,而不是使用一个检索的方法。

数据集,

收集在2008年2月13日,载9165163链接。

这些,4025911联系是独一无二的。

大多数这些链接使用

HTTP,HTTPS不,这意味着他们没有使用TLS。

的2312链接使用TLS。

我们消除这些TLS保护

因为在这些任何形式进一步考虑链接

网页将牢固地被默认发送。

在courseof几个星期,我们能够以检索总共3213764

从DMOZ链接的网页。

这广度为基础的抓取是

肤浅的;它只检查直接链接的页面

DMOZ。

虽然这种策略让我们的抓取工具来检查

从大量的域的页面,它会无法捕捉

形式的二级页面。

对于其余的数据集,我们进行了更详细的

爬行。

对于每个这些数据集,我们得到一个URL

一个首页,下载的网页和链接的任何页面

从该页面是一样的DNS域的内

原来的页面。

这个更详细的爬行限制的广度

域,而发现的形式被直接从挂钩

主页。

某些URL可能存在于多个数据

集。

由于其独特的爬行方法,我们允许

DMOZ宽度数据集与剩余的三个重叠

没有试图消除?

?

重叠。

所述第二数据集(DMOZ深度)再次使用从链接

在DMOZ开放目录项目。

然而,而thanconduct一个完整的扫描,我们随机选择了16,500独特的

链接来执行我们的抓取。

这使我们能够直接比较

浅表抓取诗句详细的爬网的策略

寻找形式。

我们获得78726Web从这个抓取网页。

在我们的第三个数据集(Alexa的),我们分析了流行的Web

站点。

我们使用的Alexa网络信息服务[3],这

居互联网上最流行的Web站点,获取

1,000最流行的网站在每个16顶级类别,

以及前500个最流行的网站的整体。

有些网站

存在于多个类别;在删除重复,

我们发现15,341独特的网站。

我们使用的每个站点

来自Alexa的获得首发的Web爬行网页。

爬行导致344,868的网页。

在最后的数据集(DNS),我们针对实际用户

行为。

要创建这个数据集,我们捕捉到所有的DNS

对于为期一周的发行我们部门的网络上查询

期。

我们使用包含在A(地址)的主机名

记录查询为基础的Web爬行的URL。

数据中包含164,145唯一的主机名。

从这个爬行,

我们获得642,013的网页。

对于每一个数据集,我们分析每个网页的HTML代码

我们下载。

我们使用的形式HTML标记来识别

请求数据。

对于每一个表格,我们提取的地址

服务的形式,所述形式的目的地,以及页面

因为每个相关联的输入域。

从这些数据,我们可以

表征数据的类型被发送,以及是否

从用户请求的数据将被安全地传送。

我们研究了430万网页。

并非所有weexamined所含形式的网页。

然而,许多页containedmultiple形式,如表Ⅰ所示。

例如,在DMOZ

广度数据集,我们发现,一共有692869(21.55%)

页包含总共1710819形式。

使用动作

在每个表单标签属性,我们推测,如果正在使用TLS

通过寻找HTTPS的存在。

否则,我们推断

该形式传输不安全。

在每一个数据集,过

95%与形式的网页只包含HTTP(不安全)

形式。

数量相对较少,1.65%-4.49%,包含

只能通过HTTPS提交表单。

我们注意到,热门的网页,

那些在Alexa的数据集,具有页更高百分比

表单和一些每页表格较高。

热门的网页有形式的使用远远低利率。

总的来说,

我们的数据包含3,333,646(96.69%),不安全的形式和

113,994(3.31%),安全形式。

在接下来的两节中,我们

分别检查不安全和安全的方式。

III。

在敏感数据请求TLS

我们试图回答第一个问题是:

是否有网站

在网络上未使用TLS时,他们应注意什么?

我们

分析所有的333万的形式传输不安全

朝着这个目标努力。

表征数据的传输的类型

通过下表,我们推测使用的name属性

在每个表格输入标记,以及类型属性

HTML标记的被使用。

例如,在HTML

下面的代码示例中,第三行包含一个输入标签

同的类型属性“密码”,这很可能是

考虑到Web用户敏感。

我们注意到,3线

5,“用户名”和“密码:

”只是为标签

最终用户知道哪些数据在该领域进入;技术

原因,这些目前尚未包括在我们的启发。

method="post">

Username:

name="user">

Password:

name="pass">

value="Login">

我们采用了两个简单的启发式分类材料

敏感。

首先,我们检查是否有输入HTML

场均型“密码”。

其他启发式是

检查任何形式的相关标签的name属性

以此来推断它们的用法。

例如,输入与字段

“用户”作为名称属性可以推断放置

“用户名”,一个数据,我们认为敏感。

与领域

“查询”或“搜索”作为名称的属性更likelyto参与网络搜索;我们不认为这

数据是敏感的。

我们开发的模式相匹配的值

与name属性的表单字段来确定相关的

数据请求。

我们进行分类,涉及到用户的数据

身份证或户口敏感。

因此,我们认为

用户名,密码,账号,地址,(信贷)

信用卡号码,电子邮件地址,真实姓名,城市和电话

号码是敏感的数据。

一些这方面的信息

被认为是比其他数据更敏感。

例如,

信用卡信息是可能比一个更敏感

电子邮件地址。

然而,电子邮件地址被绑定到用户的

身份和可用于跟踪目的。

有些人可能

考虑自己的家乡城市是敏感数据,而其他人可能

不是。

在这种分析中,我们专注于几件敏感

数据,以确定请求的数目为数据,而

不是创建一套详尽的敏感数据。

在表二中,我们列出要求敏感数据的类别

通过不安全的形式。

每个输入字段进行分类

完全通过一系列的规则。

例如,一个场

与“密码”的类型属性分类只

一个“密码字段,”不管在任何其他比赛中

name属性。

然而,一个页面可以有多个类别

敏感的表单字段,在这种情况下,它是根据每个计数的

类型。

总体而言,我们发现,与网页31.39%-36.00%

不安全的形式包含至少一个敏感的领域。

具体来说,

我们发现,超过24万的网页包含不安全

有输入标签为“密码”的形式类型

属性。

每个密码字段导致Web浏览器

模糊输入到字段中的文本,以防止他人

看到进入用户的屏幕上的数据。

显然,在Web

网站认为这个数据是有点敏感,但不

它提供了切实的保障。

对领域的类别,其余

在表二所列,我们寻找的名称模式

输入标签的属性来推断请求的数据的类型。

例如,“账户”和“会计学”都子的

我们归类为要求“账户”的信息。

一般推断请求人的电子邮件地址,其中

超过215,000页申请过这份资料。

正如一位可能

预计,数据是极端敏感,例如帐户和

卡号码,被看作较不频繁,出现在低于

1100页。

虽然有些类别可能交换在这些地方

数据集,它们通常这样做与周边的类别。

我们

没有注意到普及之间的任何辨别相关

和敏感信息的类型要求。

A.浏览器扩展,以帮助用户避免发送敏感

通过不安全的表单数据

而Web服务器可能会要求用户提交敏感

通过不安全形式的数据,Web浏览器可以提醒自己

用户对这样的风险。

在一定程度上,这样的

保护已经存在于很多流行的Web浏览器:

他们

警告用户时,他们通过发送任何形式的数据

不安全的媒介。

这些警告不幸的是,电源

由该事实,他们是不加区别稀释。

例如,

被要求承认每个Web的不安全

搜索完成将是一个烦恼大多数用户同时鼓励用户总是忽略这样的

警告。

我们的解决方案是使用更细粒度的警告。

消除过于宽泛的警告,用户可能会更容易

小心,保持警告。

我们实施和发布

延伸到执行的MozillaFirefoxWeb浏览器

由用户和数据完成了表格启发式

他们entered1。

扩展检查每个表单域

确定是否敏感数据正在传送。

如果是这样,则

扩展显示警告最终用户。

例如,

如果表单使用与“密码”输入标签的类型,

扩展将创建如果形式有针对性的警报信息

正在提交不使用TLS保护。

在警报中,

扩展描述了敏感信息被输入

鼓励用户考虑他们是什么样的信息

提交。

正如我们的方法可以找到敏感数据,

该扩展还搜索模式匹配的敏感数据

在名称属性的值在每个输入标签

HTML文档。

我们使用敏感的数据的相同的模式

在上一节中所描述。

我们的浏览器扩展超越检查HTML

文档找到敏感的领域。

同时检查用户的

输入,以确定什么类型的信息被输入。

我们已经实现了两个启发式这样的:

一个检测

美国社会安全号码(核潜艇)和一个

检测信用卡号码。

如果用户输入一个9位数

号分离成三个数字,两个数字的序列,

然后四位数字,我们标志号作为SSN,并宣布

它敏感。

如果用户输入一个15-16位的数字(后

删除任何空格),我们提供的号码卢恩

算法[4],计划用作信贷校验

卡号。

如果算法指示的数目可以是一个

有效的信用卡号码,我们标志的数据敏感。

如果任

启发式标志的敏感数据,我们发出警告,如果TLS不

在使用中。

这两个例子说明浏览器如何扩展

可以利用这两个要求的形式,以及对数据

由用户提供的数据,以制定有效的启发式

检测敏感数据。

为了评估我们实施的有效性,我们手动检查不包含在我们的数据到网页

表征它们是否包含形式请求敏感

数据和我们的启发式识别他们是否会标志

它们作为这样与否。

要做到这一点,我们随机选择了43网站

来自不包括在我们以前的Alexa的服务页面

数据集用于生成试探。

总的来说,这些

网页包含我们手工检查100表格。

从本次检查中,我们发现其中要求22的形式

敏感的数据,所有这些是由试探法中检测到的

我们的实现。

另外的2形式请求的位置

这可能被视为敏感信息。

既不

这些是由启发式检测;然而,加入的术语

“位置”作为启发式关键字会造成

它们被检测到。

在任何情况下,做了启发式显示

数据是敏感的,当它不是。

我们的启发式识别敏感数据的基础上,

观察发现,网站通常使用某些惯例

和关键词在他们的形式命名的字段。

虽然我们的

试验表明,利用这些公约效果很好

实践中,网站确定为不被标记,同时,要求

其客户敏感数据是不安全的可以打败他们。

有时会发生没有敌对意图也是如此。

例如,我们的启发式目前利用英语

语言寻找输入字段请求敏感数据;

然而,其他languages?

?

may使用由theWeb部位,造成

我们的启发式错过某些字段。

使用ourheuristics等因素并不那么容易得逞。

使用“密码”作为

键入输入字段进行了标准化HTML;复制

密码字段的模糊功能是不可能

发生意外。

然而,对抗性的网站仍然可以使用

富媒体效仿这种行为而不被发现。

IV。

不正确TLS使用情况表格

我们试图回答了第二个问题:

你的网站

即使用TLS这样做正确?

许多网站形式

他们的主要页面。

这些网页有时交付

不使用TLS,以避免支付的性能开销

TLS连接建立的情况下,用户不

登录。

相反,他们只使用TLS的实际提交

形式,这种做法称为安全岗位。

不幸的是,由

没有认证原表单页面,的内容

页可以被攻击者改变之前被输送到

用户。

因此,攻击者可以改变窗体的目的地或

嵌入客户端脚本,将泄漏敏感数据。

这可以

导致身份盗用,具有为消费者显著费用

和机构。

浏览器通常指示何时一个页面是

通过展示一个“锁定”图标,或使用颜色高亮安全。

然而,安全下后,没有这些指标

目前,因为表单页面不在TLS.Any时间传送的页面是通过HTTP传递,并包含

通过HTTPS传输的一种形式,安全的岗位是一个问题。

我们的数据包含了很多这样的实例。

不安全的网页

这有多种形式,1.65%-4.49%至少有一种形式是

通过HTTPS提交。

但是,安全的职位是唯一

有问题的,当敏感数据被通过传输

的形式。

因此,我们研究的问题往往是如何安全ISAN后,当敏感数据被传输。

我们使用

同样的启发式识别敏感数据在第三节。

在表Ⅲ中,我们显示了各种类型的请求的数据

形式与安全的岗位问题。

密码为主,如

他们确实有不安全的形式。

然而,与不安全的形式,

其中,用户名是第三个最流行的领域,用户名

在安全的形式后,在大多数的第二个最流行的现场

的数据集。

帐户号码和信用卡号码是

仍然没有请求那样频繁,在大多数的其他数据类型

数据集。

然而,在热门网站,账号分别为

比电话号码或推断密码要求更多。

与其他领域,我们注意到,在没有相当大的差异

数据的类型请求。

A.浏览器扩展克服不正确使用TLS

一种方法,以避免安全岗位的陷阱是验证

包含前HTTPS形式的原始HTTP网页

通过表单提交的任何数据。

此验证会

验证Web服务器,并确保原始页

没有被修改。

一旦验证完成后,使用TLS

的形式将确保数据的保密性。

要通过HTTPS连接验证原HTTP页面,

我们实施的扩展,MozillaFirefox浏览器

Web浏览器。

在我们的实现,之前提交的任何

形式的数据,在客户端建立与TLS连接

服务器提供的网页,获取服务器的证书和

认证服务器。

扩展然后请求的登录信息

通过TLS连接的页面;如果用于HTML代码

原来的登录页面所提供的代码完全匹配

未受保护的页面,延长提交填妥的表格

到服务器。

否则,该分机警告用户该

页面无法验证,并解释所涉及的风险。

这种方法具有不需要修改的优点

Web服务器上的,并且是相当轻重量实施

上的客户端。

评估的方法,我们研究32230

网站,在我们的Web爬行使用安全的岗位。

我们获得

使用未受保护的HTTP连接,然后在每一页

尝试下载使用同一页的TLS保护的

HTTPS连接。

约71%的Web服务器没有

一个HTTPS服务器上运行,从而导致失败的做法。

网的其余29%中,页面匹配8%的时间

和不匹配的时间92%。

从手动inspectionof不匹配的位点的一个子集,许多似乎是

警告这些不安全网站的风险用户。

最后,网站经营者负责请求

以安全的方式的敏感数据。

有些网站推卸的

责任,经常无意的。

在这些情况下,自动

网络爬行,象我们执行的种类,可以采用,以提醒

他们的不安全行为的网站经营者。

其他人可能

继续无视自己的责任,由于业绩

与安全相关的管理费用

网站的做法。

在过去,组织已经使用“名称

而耻“活动,以实现变革。

例如,该

StopBadware的项目[10]征集和发布的报告

为了鼓励软件生产商不良软件

改变自己的做法。

可用于位点A类似的模型

不为他们的用户提供适当的保护措施。

这些

组织更有可能采用适当的安全

当替代方法是在客户信任的降低。

参考

[1]T。

的Dierks和ERescorla,“传输层安全性(TLS)协议,”

IETFRFC4346,2006年4月。

[2]DMOZ,“开放目录项目”http:

//www.dmoz.org/。

[3]A,公司,“Alexa网络信息服务(AWIS),”2008年,HTTP:

//

[4]HP卢恩,“计算机验证号”,美国专利2950048,

1960年8月。

[5]D.Wagner和B.施奈尔“的SSL3.0协议的分析,”在

USENIX研讨会电子商务,1996年。

[6]Netcraft的,“安全服务器调查,”2006年,

SSL-调查/。

[7]T.C。

浏览器的论坛,“准则发放和管理

扩展验证证书,“2007年,http:

//cabforum.org/

EV证书Guidelines.pdf。

[8]C·杰克逊,D·西蒙,谭D.和A.巴特,“延长的评估

在可用的安全验证和子母画面钓鱼攻击,“

(USEC),2007年。

[9]S.谢克特,R.Dhamija,A.Ozment,和我菲舍尔,“皇帝的

新的安全指标:

网站认证的评估和

在IEEE研讨会作用的效果打可用性研究,“

安全和隐私,2007年。

[10]伯克曼中心互联网与社会“StopBadware的,”HTTP:

//WWW。

stopbadware.org/。

 

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 初中教育 > 科学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1