I'm sure that by now, a lot of people have seen the announcement of this security problem.
My understanding is that currently the only way to protect against it is to deny any requests for PDFs where the request string takes that particular form? Is that correct? Or will the browser not even submit anything beyond the # sign in the request for the PDF?
And if it is correct.... has anyone tried to cook up a recipe that we can all dump in our .htaccess files to get this fixed up?
I talked to him on aim and his solution was to disable the accessing of pdf files all together.
He believed that his server was at risk by pdf files being available. I corrected him, and told him that it is only a client-side attack, and no damage could be done to his server. However, he still believes that he should prevent access to the files for some reason.
To me, the big deal is that I don't want it to be used to steal sessions from our web apps, and thereby reveal private data or compromise accounts.
ub3r we discussed why i am still preventing access to .pdf files lastnight.
As i said, the fix that i've come up with was a temp solution untill Adobe rectifies the issue and rolls out a patch, which should be easy enough, considering basically all they have to do is drop all after the # they use to inject the url, or in other words filter it. However we will see.
As ub3r stated originally i mis-understood the advisory, as i read it very late at night the previous day (3:30am). However after our talk last night, i re-read the advisory and yes, it's not really too bad to the server itself, but as avocado mentioned, it can be used to possibly steal cookies and other credentials or cause harm to a end users computer system. I know i do not want my server to be responsible for providing a file which can be used in a url to inject another user. Call me paranoid, but that is what makes me good at my job which pays the bills .