A recent PDF exploit has been running wild across the internet for the past few days. Not unlike many other Adobe Acrobat exploits, this one relies on the fact that Acrobat and Acrobat Reader ship with JavaScript enabled by default. Shame on you, Adobe.
What is interesting about this exploit is that you do not even need to open the PDF, simply viewing a file listing in Windows Explorer causes the exploit to execute. Thankfully, there is a simple fix – disable Adobe Acrobat’s JavaScript engine.
To disable JavaScript, Open Acrobat Reader and click on the Edit menu and select Preferences. In the Preferences window, select JavaScript from the left side and uncheck “Enable Acrobat JavaScript” Press OK and you’re done.
For those of you who are administrating a Windows domain network, it might be more difficult for you to do this on each and every PC. Instead, make your lives easier by using a Group Policy Object to push a registry change out to all your machines.
I have created a registry file that will disable JavaScript on Acrobat Reader. Since I don’t know which versions are installed on each of the machines in the domain, I played it safe by adding the reg keys for the 4 latest version of Acrobat Reader – 6.x, 7.x, 8.x and 9.x.
Download the registry file here
Bryan Migliorisi JavaScript Adobe, JavaScript
Poor, or non existent, password policies are leaving too many people open to attack. In fact, there are many companies and websites who continue to require weak and insecure passwords. Yes, they require them.
I know that my bank does this. So does American Express and ING Direct. Try to enter a password with special 
characters. They wont let you. Try to enter a password more than 8 characters. They don’t allow it. It is frightening, to say the least. My financial data – my money – is only secured by a combination of letters and numbers up to 8 characters long.
My typical password is at least 10 characters long and is always a combination of lower case, upper case, numbers, and at least 2 special characters. I have been forced in many cases to use a much simpler password.
Combine that with the fact that most people use easily guessable passwords, such as their Read more…
Bryan Migliorisi Passwords Passwords, web application security
Ajax requests suffer from the same Cross Site Request Forgery attack vectors as normal pages. Many developers assume that a given ajax request will only take place on their site, and therefor skip out on the security. Not true.
Google found out the hard way when security researcher Jeremiah Grossman uncovered a flaw in the way Gmail implemented its contact list ajax requests. When the browser loaded Gmail, it would make a request to Gmail and load a users contacts, among other things. Gmail returned the contacts as an array of JavaScript objects. Read more…
Bryan Migliorisi JavaScript, Web Security JavaScript, LinkedIn
HyperText Transfer Protocol, or HTTP, is the protocol of the web. It is what transports data from client to server and back. The HTTP specification defines several HTTP methods for transferring different types of data. Most of the methods defined are used for proxys and specialty applications. HTTP GET and POST are the two major methods in use on the web today. Read more…
Bryan Migliorisi Web Security
When writing a web application, many times developers will focus more on features and usability than anything else Security is often an afterthought. Usually, security is only a concern once a vulnerability has been not only discovered, but exploited. As developers, designers and software architects, we must ensure that the security of our application is rock solid straight from conception. This is often easier said than done. Read more…
Bryan Migliorisi Web Security introduction, web application security