码迷,mamicode.com
首页 > Web开发 > 详细

总结Web应用中基于浏览器的安全漏洞

时间:2015-04-02 18:21:08      阅读:146      评论:0      收藏:0      [点我收藏+]

标签:

‍1.浏览器缓存

每次打开一个网站,网页的内容会缓存到用户的机器中。如果这些内容在其他网页中需要重新加载,浏览器加载的是缓存,而不是再次下载内容。如果一些Web应用商店以及显示用户敏感信息(比如地址,信用卡信息,用户名)这些信息也是会记录到缓存中的,因此可以通过检测浏览器缓存检索到这些信息的。

在IE浏览器中这些信息存储在:

C:\Users\<user_name>\AppData\Local\Microsoft\Windows\Temporary Internet Files

在Firefox浏览器:

C:\Users\<user_name>\AppData\Local\Mozilla\Firefox\Profiles\<profile-id>\Cache 或者在地址栏输入about:cache

在Chrome浏览器中的地址栏输入chrome://cache,其存储在

C:\Users\<user_name>\AppData\Local\Google\Chrome\User Data\Default\Cache

验证

我们在Mozilla Firefox 浏览器下实验,访问几个网页过后然后退出网站。在地址栏输入about:cache.这就可以显示在浏览器中的缓存信息了,通过缓存列表以及其中的内容选择你感兴趣的内容。

下面的截图就显示了用户仪表盘,在用户仪表盘中可能含有高危敏感信息,比如地址,电话号码,信用卡信息,E-mail等等。

 

技术分享

打开一个特定的缓存条目,在用户仪表盘中我们可以看到地址,电话号码,订单历史等等

技术分享

‍小贴士

这个问题可以通过在响应头中设置合适的缓存控制属性解决。

主要有以下两种缓存属性:

Cache-control: no-cache

no-cache属性表示,浏览器不使用特定的请求-响应缓存信息。浏览器存储缓存信息,而不是从缓存中读取内容,每一次都会向服务器发送请求。换句话来说,缓存只是保留在浏览器中,对于攻击者或者恶意用来来说就十分容易的读取到相关信息。

Cache-control: no-store

no-store属性表示,请求-响应不会被缓存或者存储到浏览器中。

使用HTML meta标签

你还可以使用meta标签实现对缓存的控制,设置如下:

<meta http-equiv=”Cache-Control” content=”no-cache” />
<meta http-equiv=”Cache-Control” content=”no-store” />

如果在HTTP响应头中手动添加cache-control头,并且设置 no-cache。如下图所示,浏览器依旧会对页面进行缓存

技术分享

如果访问浏览器缓存,那么我们就可以在用户仪表盘中缓存页面中找到它。使用离线模式打开会显示详细的细节,如下图:

技术分享

如果cache-control头设置为no-store, no-cache。我们在用户仪表盘中就找不到了。

技术分享

技术分享

因此,开发者需要分析网页的内容以及调整适当的cache-control属性。

2. 浏览器内存中的密码

大多数的站点以及服务器使用hash或者Encrypt方式进行加密,但这种方式不适用于保存在浏览器内存中的密码。GET请求以及POST请求在浏览器内存中几乎就是透明的,攻击者可通过类似WinHex的工具查看到这些敏感信息。

验证

访问站点,输入有效的凭证,如下截图。

 

技术分享

下面的截图显示了用户名以及密码传递给服务器

技术分享

从网站中退出,但请不要关闭浏览器,然后打开类似WinHex的工具,定位到正确的路径。

首先打开内存

然后选择浏览器(本列中我们使用的FireFox),选择所有内存

技术分享

技术分享

在数据中搜索用户名,我们可以获取完整的登录请求信息。

技术分享

从这里开始,攻击者就可以盗取用户登录凭证。

小贴士

这个问题出现在浏览器/本地机器上,使用SSL并不会降低危险性。用户并不能阻止浏览器记录密码或者其他一些敏感信息,这个问题的解决方法便是使用哈希加密。

下面是加盐哈希的工作流程:

存储在数据库中的MD5哈希密码。当一个用户请求登录页面时,服务器随机生成一个数,这个数就被称为salt(盐)然后返回给用户的页面。一个Javascript脚本出现在用户机器上,对用户输入的密码进行MD5计算。接着加盐后再计算哈希值,这个哈希值会发送到服务器,服务器从数据库中选择密码的哈希值结合盐值并计算MD5值。如果这个值匹配,用户就成功登录。

每一次的盐值都不尽相同,因此攻击者就算从浏览器中内存中获取到了哈希值,这个哈希值也是没用的。

另一个实现方法,使用一个Javascript脚本实现当用户退出过后就强行关闭浏览器,这么做浏览器的内存就会被重置。

3. 返回刷新攻击

浏览器的返回功能,大家都熟悉。通过前进后退这个功能,我们可以显示最近浏览的页面。此外,浏览器也会留意到像用户名,密码,银行卡账号等变量。这是因为通过POST方式传送给服务器的同时对页面进行了抓取。如果用户登录网站,执行一些操作过后退出了,攻击者在同一台机器上进行登录,他是可以在浏览器窗口中看到注销页面的,然后他一直按后退按钮,直到显示成功登录那个页面,然后单击刷新按钮,浏览器自动重新提交请求的所有信息。

验证

登录到网页并进入修改密码的页面,输入当前密码,以及修改后的密码点击提交。

更改密码的一系列请求和响应,请看下面的截图

请求

技术分享

响应

技术分享

密码更改成功

技术分享

浏览网页,然后注销,注销过后离开机器前没有关闭浏览器。如果攻击者能进行物理访问这台机器,只需简单的单击后退按钮的下拉菜单,只需要找到更改密码后的页面就行了。

技术分享

当点击进入一个特殊的页面,浏览器会显示已经过期的警示页面。

技术分享

此刻,攻击者就可以使用浏览器代理工具,比如Burp并配置浏览器通过代理发送请求。

在错误页面中单击刷新按钮,浏览器会弹出一个提示窗口

技术分享

使用配置好的代理工具,攻击者可以看到发送给服务器的请求,并且可以截取到用户的密码

技术分享

变种攻击

网站成功登录过后使用重定向,登录页面含有验证码。如果用户使用正确的用户名及密码但是验证码错误,那么网站会返回到登录页面,并提示用户错误信息。

在这种情况下,攻击者同样可以使用后退和刷新功能盗取用户名密码。即使验证码错误,攻击者也能够获取像用户名以及密码这些敏感信息。

验证

访问网站的登录页面,输入正确的用户名和错误的密码

技术分享

对用户名以及密码验证过后,服务器响应“200 OK”和错误描述“用户名/密码错误”

技术分享

技术分享

单击后退按钮,访问以前能够正确登入的页面。

技术分享

浏览器警告说,凭证过期了,同时要求用户重新发送数据到服务器。

在浏览器和服务器之间配置代理,对传输到服务器的数据进行拦截,然后点击发送按钮

技术分享

用户的账号密码可以通过明文显示给我们

技术分享

问题分析

在这个例子中,修改密码的页面为“changepass.aspx” 后面出现的页面是“changepass1.aspx”。“changepass1.aspx”页面是在提供当前密码以及新密码过后再出现的。所以,浏览器记录了发送到“changepass1.aspx”的请求。我们来理一理整个顺序。

用户访问“changepass.aspx”页面。

用户输入当前密码,新的密码,最后确认新的密码。

密码以及提交请求发送到“changepass1.aspx”

用户在“changepass1.aspx”页面进行身份验证

技术分享

当攻击者打开“changepass1.aspx”页面,请求就会发送到“changepass1.aspx”。这个请求里就包含了当前密码,新的密码以及确认的密码。

4. 自动保存

当用户提交账号以及密码之后,浏览器会提示是否记住密码。如果用户单击“记住密码”,浏览器会存储密码,在下一次访问该站点时就会自动填写相关内容。这个功能确实是方便了用户,用户不需要记住过多的密码,但是如果用户是在公用机器上使用这个功能,那么后果又是怎样?攻击者可以十分轻松的找到账号密码。

即使密码经过加密,或者是有一个主密码来保护(通过一个密码来访问存储的密码)。攻击者可以通过访问这个站点来检索存储在浏览器中的密码,攻击者只需要键入用户名,浏览器就会自动填充密码字段,只需要运行类似Burp的工具拦截浏览器请求就可以获取密码。

这里,输入用户名和密码之后,浏览器弹出提示我们是否保存密码

 

技术分享

如果用户确认保存密码之后,密码就会存储到浏览器中。在FireFox中你可以通过点击工具→选项→安全→保存的密码

技术分享

技术分享

现在假设浏览器中保存的密码有一个主密码来管理,只有通过密码验证之后才能看到上面截图中的信息

技术分享

在这个例子中,攻击者需要一个中间代理工具来拦截传送到服务器的请求。

到站点中,双击用户名字段的表框,它就会显示存储的用户名列表。点击其中一个用户名,在密码字段浏览器就会自动填写了,从拦截请求中可以十分容易的找到账号以及密码信息。

技术分享

小贴士

在目前绝大多数浏览器产品的最新版本中,这个自动保存功能依旧存在。在这个特容易撞库的年代,密码多了确实不好记,这个就看大家自己的取舍了。

5. 浏览器历史记录

当用户提交数据的时候,不是GET请求就是POST请求。GET请求的话是可以通过观察URL本身发现端倪的,然而POST请求存在于请求的主体,以下两张截图就显示了GET请求以及POST请求的用户数据。

所以的GET请求都可以通过浏览器的历史记录以及缓存进行访问,即使注销并关闭浏览器,这些数据也是可以通过历史记录查看的。

GET request:

技术分享

POST request:

技术分享

验证

用户在填写了用户名和密码之后,点击登入按钮,这里会提交一个GET请求

技术分享

使用Burp拦截请求,截图如下

技术分享

所以,攻击者可以通过历史记录获取信息

技术分享

同样的,如果站点通过GET方式发送敏感信息,攻击者也是可以通过浏览器历史查看到的。

技术分享

小贴士

让不使用GET方式发送敏感信息,成为我们不说的秘密!

总结Web应用中基于浏览器的安全漏洞

标签:

原文地址:http://www.cnblogs.com/zoucaitou/p/4387602.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!