DDOS防御专家-提供超强DDoS高防/CC防护/大流量清洗服务!
当前位置:主页 > WEB安全 > 正文

如何借助Burp和SQLMap Tamper利用二次注入

09-18 WEB安全

Web应用已经从简单的脚本逐渐发展成完整的页面应用程序,然而越复杂的Web应用就越容易出现不同类型的安全漏洞,其中的一种就是二次注入漏洞。攻击payload首先被Web服务器上的应用存储,随后又在关键操作中被使用,这便被称为二次注入漏洞。
我们知道,在任何地方都可能会出现二次注入漏洞。不仅仅是在同一应用中,使用了相同数据源的不同Web应用也可能会出现这一漏洞。因此,我们几乎没办法通过自动扫描来检测到它们。
本文将以某商城网站为例,尝试借助Burp Suite和SQLMap Tamper利用二次注入。
手工渗透方法
渗透能否成功,往往取决于我们对目标的理解程度。因此,我通常会像普通用户一样花一两天的时间在我的目标上,以理解其整个工作流程。在做每件事情和提交表单时,我会尝试遵循表单域的命名约定。
为主模块(例如发票、新闻、费用信息等,通常是在导航栏看到的内容)设置一个关键字。
假如说我们正在浏览“门票”模块,并且表单需要提供一个名称和电子邮件地址。
用户名:johnticket1
邮件:johnticket1@yopmail.com
这样有助于跟踪数据的来源,如果我们在渗透过程中(一个APP的渗透通常需要5-6天时间),看到johnticket1在其他地方出现,那么我们就知道了攻击的目标是哪个向量。
第一阶段:检测
在浏览目标时,我在Burp Suite的日志中看到了这样的请求和响应:
GET /wishlist/add/9 HTTP/1.1
 Host: targetwebapp
 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Language: en-US,en;q=0.5
 Referer:
 Cookie: XSRF-TOKEN=eyJpdiI6ImVmODhzTFRXV0wrdkRVV05MVTdyQ3c9PSIsInZhbHVlIjoiYWN1ZkkwRk1WMjZycTdDRjdSZFVuN3VKR3ZGQUpTWWZyYWNURmcyMzZtY1Zlc25vUDhvdk5xaFhHbXZidEUyalA2eUl4aDQzakhBQmNpWGtsN1lNXC9nPT0iLCJtYWMiOiIxZTAxOGU5YTVjZTY1NDdmNTFlNmMzZWRjNTM5M2Y3YTJiNTIyZjk0NThlZDgwYWExYjc1YjJmOWRiYWQyM2MxIn0%3D; session=eyJpdiI6ImdudzFVTGlNem1CYzlGUlY1aG1Xbnc9PSIsInZhbHVlIjoiMFZcL2ZHZTRDejlyUGlwbG5zNW5mNHpvYUZMdVFHUjVQVkpOZkI5M1UrazArMThDSzRiSURac0FmdTBpd0hXaFN5OVAxdytvMFhVNzhadzN1dU5NM013PT0iLCJtYWMiOiIyYWEzOWI5NWM4ZDBhNmQ1NzQ1NzA3ZjkwY2Q5NzI5NTc2MWU4NDk4YWY3OTkzMGM5ZmQ2YjBlYjFkMmNlZjIxIn0%3D
 X-Forwarded-For: 127.0.0.1
 True-Client-Ip: 127.0.0.1
 Connection: close
 Upgrade-Insecure-Requests: 1
  
 ----
  
 HTTP/1.1 302 Found
 Date: Tue, 01 Aug 2017 07:31:12 GMT
 Server: Apache/2.4.18 (Ubuntu)
 Cache-Control: no-cache, private
 Location:
 Set-Cookie: XSRF-TOKEN=eyJpdiI6IjlVXC9XSWtobkdHT0tlZDNhKzZtUW5nPT0iLCJ2YWx1ZSI6Ijg3enBCSHorT1pcLzBKVVVsWDJ4akdEV1lwT2N0bUpzdDNwbmphM3VmQndheDRJZDQ3SWJLYzJ6blFQNHppYytPQzVZNGcxWVdQVlVpWm1MVDFNRklXQT09IiwibWFjIjoiZWRmYjAwYjgzYWQ1NWQyMWM1ZWQ2NjRjMThlZmI3NjQ4ODVkNWE0YWEyZTBhYzRkMjRkOWQ2MmQ4OTA0NDg3YyJ9; expires=Tue, 01-Aug-2017 09:31:12 GMT; Max-Age=7200; path=/
 Set-Cookie: session=eyJpdiI6IkpMdzdJSEE3NndnUXI2NXh0enJYNXc9PSIsInZhbHVlIjoiMkNhek8wXC9FUHQ1bzhjbnMrbHpJWXBjTGhhQTFCM3kyQjI4bTFHRHZkKzZNK2NvSGtwQUZJcWxTeEFHREdEOFBiWVwvVFNyZTNEVlNyRTFlRGMrRlZKZz09IiwibWFjIjoiYTA2ZjlmZTVkYWM3MTc4ODE5Y2VmNmFkNTMzYjYyOTNmZjUxOGRkYjhkYzJmYThhYWM4OTNkNzg4MTliZjVkMSJ9; expires=Tue, 01-Aug-2017 09:31:12 GMT; Max-Age=7200; path=/; HttpOnly
 Content-Length: 324
 Connection: close
 Content-Type: text/html; charset=UTF-8
  
 
 
    
        
        
  
         Redirecting to
    
    
         Redirecting to
    
 
我正在向wishlist中添加一个产品。这一操作完成后,应用程序会重定向回主页。如果浏览另一个模块(/wishlist/),就可以看到这个产品的详细信息。
值得注意的是,我们在HTTP响应中看到了一个新的Set-Cookie参数。为了验证,我又尝试在wishlist中添加了几个不同的产品,结果每个请求都得到了新的Set-Cookie。
由此可知:在没有登录的前提下,应用程序能够跟踪我添加的产品;当我用不同的ID重复上述请求,我都会得到Set-Cookie。
现在,已经可以分析出,应用程序在我的cookie中存储了产品的ID值,并在将其发回我之前进行了加密。至此,我认为我的目标是一个Laravel的应用程序,原因在于其XSRF-TOKEN cookie名称和cookie加密都是Laravel框架默认的设定。
在这里,最重要的是要知道:我通过/wishlist/add/提交的任何内容,都会存储在我加密后的cookie里。如果我浏览/wishlist/路径,应用程序接下来的步骤是:
获取cookie;
解密cookie;
获取来自cookie数据的wishlist数组;
在查询中使用此数组;
显示所需产品的详细信息。
第二阶段:自动化工具问题
事实上,无论是Burp还是Netsparker都无法检测到这一SQL注入

版权保护: 本文由 DDOS防御专家 原创,转载请保留链接: http://sskjddosgb11.ddosgb.com//web/139.html

DDoS防御专家简介孤之剑
国内资深白帽子二十人组成员,前BAT资深网络安全工程师,知名网络安全站点板块大神,每年提交Google及微软漏洞,原sina微博负载插件开发者,现在整体防御复合攻击长期接受1-4.7T攻击,CC防护自主开发指纹识别系统,可以做到99.9999%的无敌防御。
  • 文章总数
  • 698415访问次数
  • 建站天数
  • 友情链接

    DDOS防御

    ddos防御

    cc防护

    web安全

    高防服务器

    高防cdn


    QQ客服

    400-0797-119

    X