4

Tor comes bundled with NoScript. Correct me if I'm wrong but that's because client sided scripts can determine the originating IP address regardless of who the traffic is passed through. But NoScript seems over kill. There's plenty of legitimate and non-threatening uses for JavaScript and the like. I really hate this white-list notion, you could not trust a website but still want it to work.

Is there a way to only block parts of client side scripts that determine IP address or location (etc)? If not I'm kind of surprised, it would seem easy as all that would have to be done is take out calls to the scripting languages functions for getting IP info.

Alternatively are there any public white lists for NoScript?

kalina
  • 3,354
  • 5
  • 20
  • 36
Celeritas
  • 10,039
  • 22
  • 77
  • 144
  • "_I really hate this whitelist notion, you could not trust a website but still want it to work._" white-listing just means that you want to run JS, that's a very limited "trust" – curiousguy Jul 08 '12 at 09:52

3 Answers3

3

Actually, NoScript provides options for white listing and plugin behavior in the client preferences.

If you click on the NoScript icon in the browser toolbar, you should see a drop down menu link titled "options". Selecting that will open the NoScript preferences pane, and from there you can configure virtually all aspects of the NoScript behavior. In fact, NoScript even offers a tab called "WhiteList" with many common sites included in the default distribution, such as "google.com", "msn.com", etc. So, you should be able to achieve the desired result from within the plugin settings. My testing was done within FireFox (which is included in the TOR browser bundle), but the same features exist in the Chrome version of the plugin too.

With regard to a more relaxed version of NoScript, you could try Web of Trust. It operates like a community managed blacklist.

Now, on to the broader question. First, NoScript can block a lot more than JavaScript, and a lot of people use it as a whitelist to mitigate all the most common client-side threat vectors, including JavaScript, Flash, Silverlight, Java Applets, etc. From the perspective of anonymity, all of those tools could likely be used to aid in identifying you if the web site you're connecting to was specifically targeting TOR users. Also, JavaScript code can be obfuscated to make it more difficult to identify with a simple text-parsing program.

So, as a general security precaution, NoScript can add a lot of value. If the default settings are too paranoid for you, my suggestion would be to configure the NoScript white list preferences to allow JavaScript and possibly plugin content from trusted sources while privately browsing with TOR. This might take a bit of time to setup, but after you have your most common sites whitelisted it shouldn't be too much of a hassle to maintain. As noted by @Curiousguy below, you could further mitigate your risk of MITM attacks by only white listing HTTPS sites to take advantage of the PKI.

Mark
  • 1,320
  • 1
  • 11
  • 12
  • 3
    "_from trusted sources while privately browsing with TOR_" **be careful with "trusted sources", HTTP and Tor**: the exit node could not only see, but also **modify HTTP pages from "trusted sources"**. – curiousguy Jul 07 '12 at 18:27
  • +1 on your comment. Good point about HTTP. I'm not a TOR expert, but aren't exit nodes chosen randomly? If so, wouldn't this be difficult to achieve unless you were being specifically targeted by a Government? – Mark Jul 08 '12 at 01:39
  • The problem with exit nodes: there are much less exits than relays. And people might be tempted to run exit nodes just to see what kind of traffic Tor is used for. (But I don't think there is a way for an exit node operator to force you to use it.) – curiousguy Jul 08 '12 at 01:58
0

No, there is no easy way to block only those scripts that might reveal your IP address or location.

The problem is that it is very hard to look at a script and tell what it will do, e.g., whether it might violate your anonymity. There are many ways to obfuscate what the Javascript will do. And, many sites use tools to "minify" their Javascript that can cause them to look semi-obfuscated, so you can't just block all script that appears to be obfuscated.

So, continuing to use NoScript, as found in the Tor bundle, is probably the right pragmatic move.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 1
    How can JS reveal the IP address or location? – curiousguy Jul 08 '12 at 02:07
  • 1
    @curiousguy, 1. Script could initiate or trigger a network connection that is not proxied through Tor. For instance, if you turn on Tor for only a single site, Javascript could wait until you turn off Tor and then initiate a network connection. 2. If Java is enabled, the Javascript-to-Java bridge can be used to access your local net connection via something like `java.net.InetAddress.getLocalHost()` (might not work on modern browsers). 3. Javascript can also access and reveal other information that might identify you and compromise your anonymity. – D.W. Jul 08 '12 at 02:18
  • "_access your local net connection via something like java.net.InetAddress.getLocalHost()_" Isn't the result `127.0.0.1`? – curiousguy Jul 08 '12 at 06:29
  • @curiousguy, it many cases InetAddress.getLocalHost() will reveal the hostname, not "localhost". For example: "his2311.his.de/127.0.0.1" – Hendrik Brummermann Jul 08 '12 at 10:34
-1

Tor comes bundled with NoScript. Correct me if I'm wrong but that's because client sided scripts can determine the originating IP address regardless of who the traffic is passed through.

Short answer:

You are wrong.

Assuming no browser exploit, JS cannot determine your IP address. Every outgoing HTTP request made with JS will be proxied like other HTTP requests made by the browser.

Long answer:

NoScript is a very useful add-on for security and privacy; fine-grained on/off switch for JavaScript is just one of the many things it can do:

  • block embedded content: Java, Flash, Silverlight...
  • block most reflected XSS (but webmasters need to fix their sites, no matter what)
  • define global user defined, and site wide sets of rules for cross-site allowable GET and POST requests, with possible "anonymizing" of such requests (notably not sending HTTP cookies) "ABE"
  • prevents Internet website from linking to "local" IP addresses (localhost, RFC 1918...)
  • block dangerous user interaction with partial hidden cross-site embedded frames ("clickjacking" aka "UI redress attack")
  • enforce HTTPS-only on listed domains (not as flexible as the HTTP Everywhere plugin, but still useful)
  • other privacy issues like turn on/off the A PING feature

NoScript can be used:

  • to reduce the opportunity of attacks by remote content: a blocked JS script, or Java/Flash applet cannot try to exploit a security bug in your client
  • to isolate websites so that inappropriate interactions are blocked

Both are important for security.

False positives

NoScript can sometimes have false positives on sites with a framed interactive content, on XSS detection... at the end, the user gets to decide what to do. The user is always in control - but NoScript warning messages can be pretty difficult to understand for the non-technical user.

Plug-ins vs. proxy

Not all plug-ins honour the browser proxy settings, and some plug-ins have even be shown to sometimes but not always honour their own proxy settings. This is extremely dangerous as any outgoing request that is not proxied will reveal your own IP address you tried so hard to hide, and inconsistent behaviour WRT to proxy setting might give the illusion of safety.

In addition, a Java applet will happily reveal the local IP address of sockets, so it could be used to discovered your own private IP address which can be an identifying information (if you don't use a very common private IP address).

All proxies, not just Tor

These considerations does not just apply to Tor but also to any use of a proxy for anonymity.

A way to make proxies safer is to block all outgoing traffic to the Internet (except data sent to the proxy) at the firewall level. This will provide defence-in-depth against misbehaving clients.

But configuring a firewall (packet filter) can usually only be done by the administrator, it is a system wide feature (even if you only want to block locally created connexion from programs running with your user-id). So the firewall option will not be accessible for all users.

curiousguy
  • 5,028
  • 3
  • 25
  • 27