Image Resizer - 安全性的最佳实践

Question

我们目前正在测试Image Resizer库，其中一个问题是，如果有人以编程方式向服务器发送数千个具有任意大小的图像大小调整请求，我们如何避免对网站的恶意攻击，从而使CPU / RAM过载由于巨大的缓存文件，服务器可能导致磁盘空间耗尽。

有没有办法将某些尺寸列入白名单？或者避免这种情况的最佳做法是什么？

谢谢！ 斯蒂芬

Answer 1

在对ImageResizer的（D）DOS攻击期间，CPU或RAM通常都不会过载。内存分配是连续的，这意味着除非剩余大约15-30％的可用RAM，否则无法处理图像。在默认管道下，只有2个核心用于图像处理，因此常规服务器也不会看到CPU饱和。

一般来说，攻击ASP.NET网站的方法比使用ImageResizer要好得多。任何数据库密集的页面都更可能是一个弱点，因为内存分配更小，更容易使服务器饱和。

启用autoClean =“true”可以减轻磁盘空间不足。

如果您是一个备受关注的网站，有许多坚定的不良信徒，您还可以考虑以下事项：

1. 使用请求签名 - 只接受服务器生成的网址。
2. 使用Presets plugin to white-list defined permitted command combinations。

这些都降低了开发灵活性并限制了响应式网页设计的选择，因此除非您过去曾遭到过实际攻击，否则我不会建议它们。

在实践中，（D）针对动态成像软件的DOS攻击在删除除了 - 暂时 - 未缓存的图像之外的任何内容时很少有用 - 即使在相同的应用程序池下运行也是如此。由于访问过的图像往往被缓存，实际效果相当可笑。