44 ms·

Might I ask what vulnerabilities exist for SSI, and why you describe SSI as a "poor way to setup a static large-file caching endpoint"? I haven't used SSI befo

Might I ask what vulnerabilities exist for SSI, and why you describe SSI as a "poor way to setup a static large-file caching endpoint"? I haven't used SSI before, but after researching various technologies, it looks like a solution for my own caching use-case, and I am planning on implementing it. I realize that it's a rather old technology, but as long as there's nothing wrong with it, I think it could work for me. Is there something wrong with it? The only thing that I have seen is that the "exec" command is dangerous, but NGINX doesn't seem to implement it.

sergiosgc 13y ago
If you are now sampling this kind of technology, have a look at ESI (edge side includes), and have a look at varnish cache. You'll be pleasantly surprised.
saurik 13y ago
I did not describe "SSI" as a "poor way to setup a static large-file caching endpoint"; that description was for the way they setup "devimages." to overlap with the content for "www.". Let's imagine that the code in question was not SSI, but instead PHP. You might have this running behind a copy of Apache and mod_php. Your website includes both code and images. This website runs like this, but maybe the way you configured Apache is too slow to handle downloading all the images: these large-file static assets need to be handled by a different system. So, you install a copy of nginx and point it at the same folder. You give this copy of nginx a new hostname, such as "devimages.example.com" as opposed to the Apache "www.example.com". Problem solved, right? No. Now if you go to http://devimages.example.com/index.php http://devimages.example.com/index.php you get access to the source code to the website (which is generally considered a big security failure). That seems to be what's happening here: the "devimages." hostname is configured to bypass the SSI parser, and you are getting to see how the page is composited. This could be a problem. However, it also might not be a problem: it largely depends, which is why I was just idly speculating; it certainly feels wrong, though. As for SSI? I was serious: I love SSI, all my stuff uses it.

sergiosgc 13y ago

If you are now sampling this kind of technology, have a look at ESI (edge side includes), and have a look at varnish cache. You'll be pleasantly surprised.

saurik 13y ago

I did not describe "SSI" as a "poor way to setup a static large-file caching endpoint"; that description was for the way they setup "devimages." to overlap with the content for "www.". Let's imagine that the code in question was not SSI, but instead PHP. You might have this running behind a copy of Apache and mod_php. Your website includes both code and images. This website runs like this, but maybe the way you configured Apache is too slow to handle downloading all the images: these large-file static assets need to be handled by a different system. So, you install a copy of nginx and point it at the same folder. You give this copy of nginx a new hostname, such as "devimages.example.com" as opposed to the Apache "www.example.com". Problem solved, right? No. Now if you go to http://devimages.example.com/index.php http://devimages.example.com/index.php you get access to the source code to the website (which is generally considered a big security failure). That seems to be what's happening here: the "devimages." hostname is configured to bypass the SSI parser, and you are getting to see how the page is composited. This could be a problem. However, it also might not be a problem: it largely depends, which is why I was just idly speculating; it certainly feels wrong, though. As for SSI? I was serious: I love SSI, all my stuff uses it.