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说，“磁带容易遭受攻击，因为没有人会重视它，而且企业在多数时间并不对其加密。”
