Sometimes adding a semicolon with some junk thereafter will not change the way the web server interprets the URL. This is common in Tomcat. webserver/path/to/page and webserver/path;junk/to;.junk/page;.css will be treated the same. I guess this could be used as a way to change the extension of the URL and hence make some things cachable.
Some penetration tools used to perform automated assessments of vulnerable sites must be adding a lot of data to these caches. Particularly authenticated fuzzing or file/directory brute-force. Let's hope tool developers don't use known file names and locations, and customers always sanitise their test DB's. 8-(
IMO you are not mentioning the only real solution: serve your cacheable and personalized/non-cacheable content on different domains. Use a very simple CDN configuration for the latter that does not cache anything, or no CDN at all if your origin can handle that. Otherwise you are only one mistake away from some major egg on your face. It is way too easy to make a configuration error in the CDN, or have the origin send the wrong headers by mistake.
Nice talk
The moral is the same as Spectre: too much push on performance without caring about security
Sometimes adding a semicolon with some junk thereafter will not change the way the web server interprets the URL. This is common in Tomcat. webserver/path/to/page and webserver/path;junk/to;.junk/page;.css will be treated the same. I guess this could be used as a way to change the extension of the URL and hence make some things cachable.
Very clear explanation, respect to this guy!
Some penetration tools used to perform automated assessments of vulnerable sites must be adding a lot of data to these caches. Particularly authenticated fuzzing or file/directory brute-force. Let's hope tool developers don't use known file names and locations, and customers always sanitise their test DB's. 8-(
Applaud this man.
awesome!
Why are you guys putting it online 6 month later?
What do you mean?
Good talk!
IMO you are not mentioning the only real solution: serve your cacheable and personalized/non-cacheable content on different domains. Use a very simple CDN configuration for the latter that does not cache anything, or no CDN at all if your origin can handle that. Otherwise you are only one mistake away from some major egg on your face. It is way too easy to make a configuration error in the CDN, or have the origin send the wrong headers by mistake.
Using name Java wasn't good idea cause it's a litte bit confuse
Awesome talk.:)
Lang Isle
Haha I did this to cheat on my ochem online homework when I forgot to do it and it was about to be due. Still got a B tho
love this talk so badass
not as badass as your avatar! ;)...
ayoooo
i am late af
Ernst and fucken Young
Wait, this is a new thing?