Insecure Web

Mauvis Ledford JavaScript, Web Security JavaScript, Web Security

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

At work, a client recently contacted us about some random ads that were popping up on their site -  interestingly enough through Adobe Acrobat. While I’m on a mac and didn’t experience the popups firsthand, I did pinpoint the problem to come from a hidden iframe located on the page (The client is a news organization and the iframes were being added to the bottom of each news article – so either they suffered an SQL injection or the attacker got into their platform somehow.) It turns out the code was doing something more malicious then just displaying ads. Read more…

Mauvis Ledford JavaScript, Web Security Adobe, JavaScript

In the previous post, Bryan showed you how to prevent a JSON payload to be rendered across domains by simply adding a string of text at the beginning of the payload that either 1) invalidates it (script tags are only allowed to pull in valid JavaScript before they do anything) or 2) creates an infinite loop so the rest of your script never executes.

More issues

While this is a good way to effectively protect an attacker from pulling information they’re not supposed to access, what about pushing information or executing commands via POST / *GET? In this case it doesn’t really matter if the attacker can access the HTTP response or not – the attackers request has already executed and the response (success or failure) is relatively unimportant. Any potential damage has already been done. Read more…

Mauvis Ledford Web Security JavaScript, 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