大多数系统管理员都知道黑客对他们管理的 SQL 数据库执行 DROP 或 DELETE 等破坏性命令的风险。有没有办法完全禁止执行这些命令，可能是通过配置 MySQL / MS SQL / PostgreSQL，或者如果它们是开源的，则修改源代码，删除那些危险的特性。
Once you have your webapp online,
would someone with honorable intentions
ever need to DROP a table?!
这可能是“主要”数据库安全的圣杯解决方案，而不是四处奔走试图阻止这些完全不必要的命令。当然，在开发或可维护期间，它们可以重新启用，然后在不需要时关闭。
SQL Server 2005 中的 DDL 触发器可以禁止删除或修改表。
如果您将与数据库的交互限制为存储过程，则不必担心这一点。应用程序帐户只能运行存储过程 - 因此将没有 sql 注入权限。
如果您不能这样做，那么您可以删除删除权限并执行任何类型的 DDL。那总比没有好。但是，如果有人想用 Nulls 更新您的所有数据，他们可以。
如果您有有价值的数据，您将拥有一个保持最新的备份，或者您会发现自己失业/生意不佳。
您不需要修改数据库代码，因为它已经存在。只是人们不使用它。大多数网络应用程序最多需要插入、选择、更新、删除和创建的能力。许多安装过程确实会引导您完成使用特权用户以最低权限创建所需帐户和数据库的过程。IIRC mediawiki 在这方面做得很好。
但是，我无法计算我发现的网络应用程序的数量，其中网络应用程序数据库用户对其数据库具有完全权限，或者对整个数据库安装具有最差权限。此外，某些应用程序的构建方式需要太多权限。或者不要将内部特权和非特权帐户用于管理功能。
听起来您可能想检查数据库防火墙。GreenSQL 是一个开源的： http: //www.greensql.net/
干杯
是的，当我的数据库投入生产时，我可能需要删除我创建的临时表。
如果您真的很偏执，您可能应该让您的开发人员使用视图和存储过程，以便通常可以访问表的帐户实际上无法直接操作，而是必须通过视图/过程访问它们。
至少使用 mysql，您不必赋予帐户创建和删除表的能力。花点时间看看权限系统，然后正确地限制您的帐户。
您可以以性能为代价使用的另一种选择是通过Mysql 代理运行所有访问，并使用偏执过滤器阻止您不喜欢的所有内容。
这与文件访问没有什么不同。用户帐户应具有完成该工作所需的绝对最低权限。诸如 drop 之类的权限应该只授予管理员级别的帐户，除非它是绝对不可避免的，在这种情况下可能应该审查应用程序设计。经常需要删除，但应仅限于那些需要删除的表。
如果在授予权限时使用谨慎和常识，则不需要修改代码。完全删除具有潜在危险的命令很可能会导致数据库系统无法维护。
我们所做的是将每个人都添加到 db_denydatawriter 角色（仅限 SQLServer），这会删除任何插入、更新和删除权限。
然后，我们通过存储过程控制我们的网络用户对数据库的所有访问。如果您不授予他们创建自己的存储过程的权限，并且如果您不允许他们在存储过程中执行任意 SQL，那么您将被很好地锁定。
这超出了不能删除表的范围，但如果您没有在任何地方使用存储过程，那么您可能会面临转换代码的一场大战。