下面是六大数据库攻击：
1.强力(或非强力)破解弱口令或默认的用户名及口令
2.特权提升
3.利用未用的和不需要的数据库服务和和功能中的漏洞
4.针对未打补丁的数据库漏洞
5.SQL注入
6.窃取备份(未加密)的磁带
下面分别分析一下：
1.对弱口令或默认用户名/口令的破解
以前的Oracle数据库有一个默认的用户名：Scott及默认的口令：tiger;而微软的SQL Server的系统管理员账户的默认口令是也是众所周知。
当然这些默认的登录对于黑客来说尤其方便，借此他们可以轻松地进入数据库。
Oracle和其它主要的数据库厂商在其新版本的产品中表现得聪明起来，它们不再让用户保持默认的和空的用户名及口令等。但这并不意味着,所有的组织都在较老的数据库中敞开着大门。
Forrester的Yuhanna说，“问题是企业拥有15000个数据库，而完全地保护其安全并不容易。有时企业只能保障关键数据库的安全，其它的就不太安全了。现在，较新的数据库强制使你在安装时改变系统管理员账户的默认口令。但较老的数据库版本可能存在着问题。”
但即使是唯一的、非默认的数据库口令也是不安全的。Sentrigo的 Markovich 说，“你总可以在客户那里找到弱口令和易于猜测的口令。通过强力破解或只试着用不同的组合就可以轻易地找到这种口令。”
口令破解工具有很多，并且通过Google搜索或sectools.org等站点就可以轻易地获得,这样就会连接到Cain 、 Abel或John theRipper等流行的工具。
保护自己免受口令攻击的最佳方法：避免使用默认口令，建立强健的口令管理程序并对口令经常改变。
2.特权提升
有几种内部人员攻击的方法可以导致恶意的用户占有超过其应该具有的系统特权。而且外部的攻击者有时通过破坏操作系统而获得更高级别的特权。应用安全公司的销售副总裁Ted Julian说，“这是一种常见的威胁因素。”
特权提升通常更多地与错误的配置有关：一个用户被错误地授与了超过其实际需要用来完成工作的、对数据库及其相关应用程序的访问和特权。
Forrester的Yuhanna说，“这是一个控制问题。有时一个企业并没有提供哪些人员需要访问何种资源的良好框架结构,而且通常情况下，数据库管理员并没有从业务上理解企业的数据。这是问题之一。”
而且，有时一个内部的攻击者(或者一个已经控制了受害人机器的外部的家伙)可以轻松地从一个应用程序跳转到数据库，即使他并没有这个数据库的相关凭证也可以如此。Yuhanna 说，“一个非特权用户可以试着连接到数据库，只要他可以访问一个系统，如CRM，他就可以用同样的口令通过检查，即使他没有获得此数据库的授权。有些控制并没有实现很好的集中化。”
Sentrigo的Markovich近来能够通过一个拥有少量特权的用户账户攻入一个客户的数据库。Markovich说，“他们要求我攻入其数据库。我找到了一个少量特权的用户口令，然后就进入了系统。然后我检查了他的特权，他拥有对数据库的只读性访问，因此一个少量特权的用户可以访问读取数据库内的任何表，包括信用卡信息、个人信息。因此，我说：‘我不需要攻入数据库。’”
专家们说，经验法则应当说是仅给用户所需要的数据库访问和权力，不要有更多的东西。
还有那些拥有合法访问的特权用户，他们头脑中可能并没有合法的操作。“你如何控制访问呢?这个领域也正在开始演化。”
3.利用未用的和不需要的数据库服务和功能中的漏洞
当然，一个外部的攻击者会寻找较弱的数据库口令，看其潜在的受害人是否在运行其Oracle数据库上运行监听程序(Listener)功能。监听程序可以搜索出到达Oracle数据库的网络连接，并可以转发此连接，这样一来就会将用户和数据库的链接暴露出来。
只需采用一些Google hacking攻击，一位攻击者就可以搜索并找到数据库服务上暴露的监听程序。Markovich 说，“许多客户并没有在监听程序上设置口令，因此，黑客就可以搜索字符串并找出Web上活动的监听程序。我刚才搜索了一下，发现有一些可引起人们注意的东西，如政府站点。这确实是一个大问题。”
其它的特性，如操作系统和数据库之间的钩子可以将数据库暴露给攻击者。这种钩子可以成为达到数据库的一个通信链接。Yuhanna说，“在你链接库和编写程序时…那将成为与数据库的界面，”你就是在将数据库暴露出去，并可能在无认证和无授权的情况下让黑客进入内部。
通常，数据库管理员并没有关闭不需要的服务。Julian 说，“他们只是任其开着。这种设计过时且管理跟不上，这是让其发挥实际作用的最简单方法。不需要的服务在基础结构中大摇大摆地存在，这会将你的漏洞暴露在外。”
关键是要保持数据库特性的精简，仅安装你必须使用的内容。别的东西一概不要。Markovich说，“任何特性都可被用来对付你，因此只安装你所需要的。如果你并没有部署一种特性，你就不需要以后为它打补丁。”
4.针对未打补丁的数据库漏洞
好消息是Oracle和其它的数据库厂商确实在为其漏洞打补丁。坏消息是单位不能跟得上这些补丁，因此它们总是处于企图利用某种机会的老谋深算的攻击者控制之下。
数据库厂商总是小心翼翼地避免披露其补丁程序所修正的漏洞细节，但单位仍以极大的人力和时间来苦苦挣扎，它会花费人力物力来测试和应用一个数据库补丁。例如，给程序打补丁要求对受补丁影响的所有应用程序都进行测试，这是项艰巨的任务。
Yuhanna 说，“最大问题是多数公司不能及时安装其程序补丁，一家公司告诉我，他们只能关闭其数据库一次，用六小时的时间打补丁，它们要冒着无法打补丁的风险，因为它们不能关闭其操作。”
Markovich说，在今天正在运行的多数Oracle数据库中，有至少10到20个已知的漏洞，黑客们可以用这些漏洞攻击进入。他说，“这些数据库并没有打补丁，如果一个黑客能够比较版本，并精确地找出漏洞在什么地方，那么，他就可以跟踪这个数据库。”
而且一些黑客站点将一些已知的数据库漏洞的利用脚本发布了出来，他说。即使跟得上补丁周期有极大困难，单位也应当打补丁。他说，例如，Oracle4月15日的补丁包含了数据库内部的17个问题。这些和其它的补丁都不应当掉以轻心。每一个问题都能够破坏你的数据库。
5.SQL注入
SQL注入式攻击并不是什么新事物了，不过近来在网站上仍十分猖狂。近来这种攻击又侵入了成千上万的有着鲜明立场的网站。
虽然受影响的网页和访问它的用户在这些攻击中典型情况下都受到了重视，但这确实是黑客们进入数据库的一个聪明方法。数据库安全专家们说，执行一个面向前端数据库Web应用程序的SQL注入攻击要比对数据库自身的攻击容易得多。直接针对数据库的SQL注入攻击很少见。
在字段可用于用户输入，通过SQL语句可以实现数据库的直接查询时，就会发生SQL攻击。也就是说攻击者需要提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据。
除客户端之外，Web应用程序是最脆弱的环节。有些情况下，如果攻击者得到一个要求输入用户名和口令的应用程序的屏幕，而且应用程序并不检查登录的内容的话，他所需要做的就是提供一个SQL语句或者数据库命令，并直接转向数据库。Yuhanna说，问题是身份验证和授权已经被移交给了应用程序服务器。
他说，“此时输入的并不是一个用户名，而是一个SQL命令。它被输入到一个数据包中，并且由应用程序服务器发送给数据库。这个数据库会读取欺诈性的SQL命令，而且它能够完全关闭整个数据库。”
他说，“这是开发者的一种可悲的开发方法。你必须关注用户正在输入的内容。不管你想执行什么，数据库都会执行。这是很令人惊慌的问题。SQL注入式攻击是一个很大的问题。”
Sentrigo 的Markovich说，从Web应用程序到数据库两个方面都可以实施SQL注入式攻击，而且可以从数据库内部实施。但有一些程序设计方法可有助于防止应用程序中的SQL注入攻击漏洞，如使用所谓的绑定变量(bind variable)或者使用参数进行查询等。
Markovich说,在Java等语言中,这就意味着在SQL语句中将问号用作占位符,并将“接收”值与这些占位符绑定。另外一种方法是避免显示某些数据库错误消息,目的是避免将可能敏感的信息透露给潜在的攻击者。
6.窃取(未加密的)备份磁带
如果备份磁带在运输或仓储过程中丢失，而这些磁带上的数据库数据又没有加密的话，一旦它落于罪恶之手，这时黑客根本不需要接触网络就可以实施破坏。
但这类攻击更可能发生在将介质销售给攻击者的一个内部人员身上。只要被窃取的或没有加密的磁带不是某种Informix或HP-UX 上的DB2等较老的版本，黑客们需要做的只是安装好磁带，然后他们就会获得数据库。
Julian说，“当然，如果不是一种受内部人员驱动的攻击，它就是非主要的。”他说，同样的原因，闪盘也是另外一种风险。
除了没有对备份介质上的数据进行加密等明显的预防措施，一些单位并没有一直将标签贴在其备份介质上。“人们备份了许多数据，但却疏于跟踪和记录。”Yuhanna说，“磁带容易遭受攻击，因为没有人会重视它，而且企业在多数时间并不对其加密。”