Posts Tagged: javascript


21
Jan 15

Java Patch Plugs 19 Security Holes

Oracle this week released its quarterly patch update for Java, a widely-installed program that for most casual users has probably introduced more vulnerability than utility. If you have Java installed and require it for some application or Web site, it’s time to update it. If you’re not sure you have Java on your computer or are unsure why you still have it, read on for advice that could save you some security headaches down the road.

javamessOracle’s update brings Java 7 to Update 75 and Java 8 to Update 31, and fixes at least 19 security vulnerabilities in the program. Security vendor Qualys notes that 13 of those flaws are remotely exploitable, with a CVSS score of 10 (the most severe possible score).

Java 7 users should know that Oracle plans to start using the auto-update function built into the program to migrate those users to Java 8 this week.

According to a new report (PDF) from Cisco, online attacks that exploit Java vulnerabilities have decreased by 34 percent in the past year. Cisco reckons this is thanks to security improvements in the program, and to bad guys embracing new attack vectors — such Microsoft Silverlight flaws (if you’re a Netflix subscriber, you have Silverlight installed). Nevertheless, my message about Java will remain the same: Patch it, or pitch it. Continue reading →


25
May 11

Blocking JavaScript in the Browser

Most Web sites use JavaScript, a powerful scripting language that helps make sites interactive. Unfortunately, a huge percentage of Web-based attacks use JavaScript tricks to foist malicious software and exploits onto site visitors. To protect yourself, it is critically important to have an easy method of selecting which sites should be allowed to run JavaScript in the browser.

It is true that selectively allowing JavaScript on known, “safe” sites won’t block all malicious scripting attacks: Even legitimate sites sometimes end up running malicious code when scammers figure out ways to sneak tainted, bogus ads into the major online ad networks. But disallowing JavaScript by default and selectively enabling it for specific sites remains a much safer option than letting all sites run JavaScript unrestricted all the time.

Firefox has many extensions and add-ons that make surfing the Web a safer experience. One extension that I have found indispensable is NoScript. This extension lets the user decide which sites should be allowed to run JavaScript, including Flash Player content. Users can choose to allow specific exceptions either permanently or for a single browsing session.

The NoScript extension makes it easy to place or remove these restrictions on a site-by-site basis, but a novice user may need some practice to get the hang of doing this smoothly. For instance, it’s not uncommon when you’re shopping online to come across a site that won’t let you submit data without fully allowing JavaScript. Then, when you enable scripting so that you can submit your address and payment information, the page often will reload and clear all of the form data you’ve already supplied, forcing you to start over. Also, many sites host content from multiple third-party sites, and users who prefer to selectively enable scripts may find it challenging to discover which scripts need to be enabled for the site to work properly.

Chrome also includes similar script- and Flash blocking functionality that seems designed to minimize some of these challenges by providing fewer options. If you tell Chrome to block JavaScript on all sites by default, when you browse to a site that uses JavaScript, the upper right corner of the browser displays a box with a red “X” through it. If you click that and select “Always allow JavaScript on [site name]” it will permanently enable JavaScript for that site, but it doesn’t give you the option to block third-party JavaScript content on the site as Noscript does. In my testing, I had to manually refresh the page before Chrome allowed scripting on a site that I’d just whitelisted.

Continue reading →


6
Dec 10

What You Should Know About History Sniffing

Researchers have discovered that dozens of Web sites are using simple Javascript tricks to snoop into visitors’ Web browsing history. While these tricks are nothing new, they are in the news again, so it’s a good time to remind readers about ways to combat this sneaky behavior.

The news is based on a study released by University of California, San Diego researchers who found that a number of sites were “sniffing” the browsing history of visitors to record where they’d been.

This reconnaissance works because browsers display links to sites you’ve visited differently than ones you haven’t: By default, visited links are purple and unvisited links are blue. History-sniffing code running on a Web page simply checks to see if your browser displays links to specific URLs as purple or blue.

These are not new discoveries, but the fact that sites are using this technique to gather information from visitors seems to have caught many by surprise: A lawyer for two California residents said they filed suit against one of the sites named in the report — YouPorn — alleging that it violated consumer-protection laws by using the method.

As has been broadly reported for months, Web analytics companies are starting to market products that directly take advantage of this hack.  Eric Peterson reported on an Israeli firm named Beencounter that openly sells a tool to Web  site developers to query whether site visitors had previously visited up to 50 specific URLs.

The Center for Democracy & Technology noted in March that another company called Tealium has been marketing a product taking advantage of this exploit for nearly two years.  “Tealium’s “Social Media” service runs daily searches of a customer’s name for news and blog postings mentioning the customers, and then runs a JavaScript application on the customer’s site to determine whether visitors had previously read any of those stories,” CDT wrote. “The service allows Tealium customers a unique insight into what sites visitors had previously read about the company that may have driven them to the company’s Web site.”

Continue reading →


24
May 10

Devious New Phishing Tactic Targets Tabs

Most Internet users know to watch for the telltale signs of a traditional phishing attack: An e-mail that asks you to click on a link and enter your e-mail or banking credentials at the resulting Web site. But a new phishing concept that exploits user inattention and trust in browser tabs is likely to fool even the most security-conscious Web surfers.

As Mozilla Firefox creative lead Aza Raskin describes it, the attack is as elegant as it is simple: A user has multiple tabs open, and surfs to a site that uses special javacript code to silently alter the contents of a tabbed page along with the information displayed on the tab itself, so that when the user switches back to that tab it appears to be the login page for a site the user normally visits.

Consider the following scenario: Bob has six or seven tabs open, and one of the sites he has open (but not the tab currently being viewed) contains a script that waits for a few minutes or hours, and then quietly changes both the content of the page and the icon and descriptor in the tab itself so that it appears to be the login page for Gmail.

In this attack, the phisher need not even change the Web address displayed in the browser’s navigation toolbar. Rather, this particular phishing attack takes advantage of user trust and inattention to detail, or what Raskin calls “the perceived immutability of tabs.” Then, as the user scans their many open tabs, the favicon and title act as a strong visual cue, and the user will most likely simply think they left a Gmail tab open.

“When they click back to the fake Gmail tab, they’ll see the standard Gmail login page, assume they’ve been logged out, and provide their credentials to log in,” Raskin explained. “After the user has enter they have entered their login information and sent it back your server, you redirect them to Gmail. Because they were never logged out in the first place, it will appear as if the login was successful.”

Raskin includes a proof-of-concept at his site, which is sort of creepy when you let it run. In fact, at least once while composing this blog post in Firefox I went to click on the tab that had my Gmail inbox open, only to discover I’d accidentally clicked on Raskin’s page, which had morphed into the fake Gmail site in the interim.

It’s important to keep in mind that this attack could be used against any site, not just Gmail. Also, Raskin includes a few suggestions about how this attack could be made far sneakier — such as taking advantage of CSS history attacks.

Of course, if you are browsing with the excellent “Noscript” add-on and this is a site you have not allowed to run javascript, the proof-of-concept won’t work until you allow javascript on the page. It did not work completely against the Safari browser on my Mac (no favicon), and the test page failed completely against Google Chrome. [Update: As several readers have correctly pointed out, this attack does in fact work against Chrome, although it doesn’t seem to change the favicon in Chrome tabs].

I’m left wondering what this new form of phishing will be called if it is ever adopted by the bad guys. Tabnabbing? Tabgrabbing? See if you can coin a better phrase in the comments below.

Update, May 25, 7:55 p.m. ET: Researcher Aviv Raff has posted an interesting proof-of-concept of his own that shows how this attack can work against Firefox even when users have the Noscript add-on installed and in full paranoid mode. Raff crafted his page, which is a mock up of this blog post, to morph into an image of the Gmail login page, and it will reload every 20 seconds but will only change to the sample phish page if you move to another tab with your mouse, or after 10 reloads (in case you moved with the keyboard). So it will change only after 3 minutes or so, unless you move to another tab with your mouse.

“I was trying to find a way to work around the javascript need for the [proof-of-concept],” Raff said in an instant message. “First I was able to do this without knowing if the user moved to a new tab. Now I can almost be sure of that.”

Update, May 27, 11:41 p.m. ET: For Firefox users with the Noscript plugin, there is an update to the program that can block these types of tabnabbing attacks.