我想知道如何保证网站上图像的安全。我们有一个需要登录的网站，然后用户可以查看数以千计的不同图像，所有这些图像均以其数据库中的 ID 命名。
即使您需要登录才能以正确的方式查看图像...没有什么可以阻止用户通过键入 /image-folder/11232.jpg 或某物。
这不是世界末日，但绝对不理想。我发现要阻止这个 Facebook，只需将图像命名为更复杂的名称+将它们存储在散列文件夹中即可。
Gmail 做了一件非常有趣的事情，它们的图像标签看起来像这样：
<img src=/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5>
我认为 src 属性必须包含对图像的引用??...gmail 如何解决这个问题？
目前这更多的是出于教育目的，因为我认为这个 Gmail 方案对于我们的实施来说可能有点过头了。
感谢您提前的反馈，
安德鲁
I was wondering how to keep images secure on my website. We have a site that requires login then then user can view thousands of different images all named after their ID in the database.
Even though you need to login to view the images the proper way...nothing is stopping a user from browsing through the images by typing <website-director>/image-folder/11232.jpg or something.
this is not the end of the world but definitely not ideal. I see that to stop this facebook just names the images something much more complicated + stores them in hashed folders.
Gmail does a very interesting thing, their image tags looks like this:
<img src=/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5>
I thought the src attribute has to contain a reference to an image??...how does gmail get around this?
This is more for educational purposes at this point, as I think this gmail scheme might be overkill for our implementation.
Thanks for your feedback in advance,
Andrew
发布评论
评论（3）
GMail 正在引用图像。它只是被动态拉取，可能基于
th=12d7d49120a940e5字符串。尝试浏览 http://mail。 google.com/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5
它不是服务器文件系统上其位置的直接路径，而是使用动态脚本（图像甚至可能在数据库中，谁知道呢）。
GMail is referencing an image. It's just being pulled dynamically, probably based off of that
th=12d7d49120a940e5string.Try browsing to http://mail.google.com/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5
Instead of it being a direct path to its location on the server's filesystem, it uses a dynamic script (the images may even be in a database, who knows).
除了从 Web 应用程序动态提供图像之外，还可以使用 Web 应用程序动态授权访问 Web 服务器将提供的静态资源 - 通常是将文件放在 Web 服务器有权访问的位置，但未映射到任何公共 URI，然后使用诸如 X-Sendfile（lighttpd、带有 mod_sendfile 的 Apache 等）、X-Accel-Redirect（nginx）之类的东西，
X-Reproxy-File(Perlbal) 等。或者使用 FastCGI，您可以将应用程序配置为 FastCGI“授权者”角色而不是内容提供者。其中任何一个都可以让您检查正在授权的图像和用户的会话，并做出您需要的任何决定，而无需在图像发送到客户端的整个过程中占用后端应用程序的进程。这并不普遍正确，但通常与后端应用程序的连接比与网络服务器的连接意味着保留更多的资源，因此尽快释放它们是明智之举。
Besides serving up an image dynamically from your webapp, it's also possible to use a webapp to dynamically authorize access to static resources that the webserver will serve -- commonly by putting the files somewhere that the webserver has access to, but not mapped to any public URI, and then using something like
X-Sendfile(lighttpd, Apache with mod_sendfile, others),X-Accel-Redirect(nginx),X-Reproxy-File(Perlbal), etc. etc. Or with FastCGI you can configure an application in a FastCGI "authorizer" role rather than a content provider.Any of these will let you check the image being authorized, and the user's session, and make whatever decision you need to, without tying up a proceses of your backend application for the entire time that the image is being sent to the client. It's not universally true, but usually a connection to the backend app represents a lot more resources being reserved than a connection to the webserver, so freeing them up ASAP is smart.
发出此 GET 请求后运行的代码：
将图像输出到浏览器。某些内容不必以
.jpg或.png或任何结尾来命名，浏览器才会将其视为图像。这就是验证码算法能够根据 id 中的值提供不同图像的方式。例如，此链接：http:// www.google.com/recaptcha/api/image?c=03AHJ_VusfT0XgPXYUae-4RQX2qJ98iyf_N-LjX3sAwm2tv1cxWGe8pkNqGghQKBbRjM9wQpI1lFM-gJnK0Q8G3Nirwkec-nY8Jqtl9rwEvVZ2EoPlwZ rmjkHT7SM32cCE8PLYXWMpEOZr5Uo6cIXz1mWFsz5Qad1iwA
提供此图像：
因此，答案实际上就是像 Facebook 那样混淆图像名称/链接，这样人们就无法轻易猜出它们。
The code that runs after this GET request is issued:
outputs an image to the browser. Something doesn't have to be named with a
.jpgor.pngor whatever ending to be considered an image by a browser. This is how captcha algorithms are able to serve up different images depending on a value in the id. For example, this link:http://www.google.com/recaptcha/api/image?c=03AHJ_VusfT0XgPXYUae-4RQX2qJ98iyf_N-LjX3sAwm2tv1cxWGe8pkNqGghQKBbRjM9wQpI1lFM-gJnK0Q8G3Nirwkec-nY8Jqtl9rwEvVZ2EoPlwZrmjkHT7SM32cCE8PLYXWMpEOZr5Uo6cIXz1mWFsz5Qad1iwA
Serves up this image:
So the answer really is to just obfuscate your image names/links a bit like Facebook does so that people can't easily guess them.