我正在构建一个相对简单的程序来收集和排序用户输入的数据。我想使用通过 Web 浏览器运行的本地服务器，原因有两个：
编辑：澄清一下，我的意思是应用程序应该只能从本地网络访问，而不是从 Internet 访问。
当我一直在寻找有关该问题的信息时，我遇到过一两个评论，表明本地服务器有其自身的安全风险，但我不清楚这些风险的性质或严重程度。
（如果相关，我将使用 SWI-Prolog 来处理数据操作。我还计划为服务器使用SWI-Prolog HTTP 包，但如果结果证明是一个，我愿意重新考虑这个选择馊主意。）
我有两个问题：
我非常感谢任何和所有的帮助！
任何解决方案都存在安全风险。您可以使用经过多年验证的工具，总有一天会被黑客入侵（根据我自己的经验）。而且您可以为安全解决方案付出很多，而且永远不会被黑客入侵。因此，您需要始终将努力与影响进行比较。
基本上，您需要保护 4 个“门”： 1. 授权（密码拦截或不正当使用 cookie） 2. http 协议 3. 应用程序输入 4. 访问数据库的其他方式（不使用 http，例如，使用弱密码的 ssh 端口，占用您的计算机或硬盘等。在某些情况下，您需要正确加密卷）
1 和 4 不是特定于 Prolog 的，但 4 只是在本地服务器的情况下具有一些特定性的一个。
保护 http 协议级别意味着不允许可以控制您的 swi-prolog 服务器的请求。为此，我建议安装一些反向代理，如 nginx，它可以防止此级别的攻击，包括某些类型的 DoS。因此，浏览器将联系 nginx，如果它是正确的 http 请求，nginx 会将请求重定向到您的服务器。如果它具有类似的功能，您可以使用任何其他服务器而不是 nginx。
您需要在反向代理服务器中安装正确的 ssl 密钥并允许使用 ssl (https)。它不应该在您的 swi-prolog 服务器中。Https 会对所有信息进行加密，并通过 http 与 swi-prolog 进行通信。
考虑授权。有些方法很容易被破解。你需要研究这个主题，有很多信息。我认为这是最重要的部分。
应用程序输入问题——著名的例子是“sql 注入”。学习例子。所有好的 Web 框架都有“入口”程序来清除所有可能的注入。获取现有代码并用 prolog 重写它。此外，使用非常长的字符串、不同的字符集等测试所有输入字段。
可以看到，安全并不是那么容易，但是可以考虑到黑客攻击的影响，选择适当的努力。
另外，考虑可能的攻击者。如果有人对获取您的信息非常感兴趣，那么所有提到的方法都很好。但这可能是一种罕见的情况。大多数情况下，黑客只是扫描互联网并尝试将已知的黑客应用于所有找到的服务器。在这种情况下，您最好的朋友应该是 Honey-Pots 和 prolog 本身，因为黑客对 swi-prolog 内部结构感兴趣的可能性极低。（黑客需要研究好服务器代码才能找到门）。
所以我认为你会找到足够的方法来保护所有敏感数据。但是，请不要将密码与字典单词的组合和相同的密码用于一个目的，这是最重要的安全规则。出于同样的原因，您不应授予用户访问所有信息的权限，但应在应用程序级别设计上进行保护。
如果您的本地服务器可能被“黑客”窃取，则本地服务器的特定情况是良好的防火墙、正确的网络设置和硬盘分区的加密。
但是，如果您的意思是该应用程序只能从您的本地网络而不是从 Internet 访问，那么您需要的工作要少得多，主要是您需要检查您的路由器/防火墙设置和我列表中的第四扇门。
如果您的已知用户数量非常有限，您可以建议他们使用 VPN，而不是像“全局”访问那样保护您的服务器。
我要指出我的帖子是关于在 apache 中使用端口转发来访问 prolog 服务器的安全问题。
而且我确实知道在基于 SWI-Prolog http 框架的网站上成功进行了 prolog 注入 DOS 攻击。我不相信该网站的作者希望公开细节，但这种可能性肯定是真实的。显然，只有当站点评估图灵完整代码（或无法证明将终止的代码）时，这种攻击向量才有可能。
一个简单的安全预防措施是检查 Request 对象并拒绝来自除 localhost 之外的任何请求。
我要指出的是，pldoc 服务器默认情况下只在 localhost 上响应。——安妮·奥格本
我认为 SWI_Prolog http 包是一个很好的选择。Jan Wielemaker 在使其安全和可扩展方面付出了很多努力。
我不认为你需要担心 SQL 注入，当你拥有 Prolog 的力量时，依赖 SQL 确实会很奇怪......
当然，您需要妥善管理服务器中的 http 访问...就在今天早上，SWI-Prolog 邮件列表中有一篇有趣的帖子，关于这个主题：Anne Ogborn 分享她的经验...