我们有一个用例，其中发送电子邮件的应用程序在电子邮件中找到特定字符串（“智能标签”）并将其替换为存储过程的结果。
因此，例如电子邮件可能Dear <ST:Name>在正文中，然后代码将识别此字符串，运行存储过程以查找作为参数传入客户端 ID 的客户端名称。
这些标签列表和需要运行的存储过程目前是硬编码的，因此每次需要添加新的“智能标签”时，都需要更改代码和部署。
我们的 BA 精通 SQL，希望能够手动添加新标签。
将过程和参数存储在数据库表中是不好的做法吗？这对这样的桌子来说是一个合适的设计吗？是否有必要存储参数类型？
智能标签
SmartTagId SmartTag StoredProcedure
智能标签参数
SmartTagParameterId SmartTagId ParameterName
表驱动配置，数据驱动编程，都不错。
需要注意的主要事情是 SQL 注入风险（或者在您的情况下，它被称为“标签注入”......）：人们可以使用电子邮件作为攻击媒介，通过插入一个精心设计的过程来获得提升的权限，该过程将是在更高的权限下运行。请注意，这不仅仅是关于 SQL 注入的通常注意事项，因为您已经接受了要执行的任意代码。这更像是一个沙盒问题。
典型的问题来自类型系统：参数有多种类型，但声明表有一个字符串类型。SQL_VARIANT可以帮忙。
另一个潜在的问题是声明和发现标签的语言。很快你会被要求识别<tag:foo>，但只是在之前<tag:bar>。一个完全成熟的上下文敏感解析器通常在第一次迭代后不久出现......如果您可以通过利用已经熟悉的东西来提供帮助（例如，想想 JQuery 如何使用 CSS 选择器语法），那将会很有帮助。HTMLAgilityPack或许可以帮助您（顺便说一句，这是一项非常适合 SQLCLR 的任务，不要尝试在 T-SQL 中构建精细的全状态解析器......）。
这不是坏习惯，你所做的一切都很好。只要只有您的管理员/BA 可以添加和更改参数以及更改配置，您就不必担心注入。如果用户可以添加和更改参数，您确实需要检查输入并将某些字符列入白名单。
您不仅要检查 sql 注入，还需要检查跨站点脚本和 dom 注入以及跨站点请求伪造。合并后的文本显示在用户计算机上，因此您在查看合并结果时必须保护他。
有趣的问题，将跟进，因为它与我的有关。一点也不坏。事实上，我们正在使用相同的方法。我正在尝试在我的 XSL 编辑器上实现类似的目标。我正在使用 XML 标记、存储过程和 VB.Net 逻辑的组合来进行替换。
我正在使用一个表与所有使用的 XML 标记（它们在应用程序的其他地方使用）和完成所有脏工作的存储过程的组合。一组 sp 从带有标签的文本转换为用户可读的文本。其他程序集从 XML 标记表创建 XML 树，以便用户可以从中选择来编辑他们的文本。
SQL 注入对我们来说不是问题，因为我们使用这些程序来创建电子邮件，而不是从外部来源解析它们。
关于对其中一个问题的评论，我们也直接从 SSMS 管理标签，没有管理窗口来管理它们，至少目前是这样。但是我们计划添加一个简单的管理窗口来管理标签，以便在部署应用程序后更容易添加/删除/修改它们。