Best Practices for Sensitive Sites

General discussion about the NoScript extension for Firefox
Post Reply
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Best Practices for Sensitive Sites

Post by Thrawn »

NoScript generally focuses on blocking untrusted or unwanted scripts (and other active content such as plugins). However, it can also help you to defend sites that you not only trust, but depend on, like banking and webmail. Here are some guidelines for securing your sensitive sites against tampering by third parties:
  1. If the secure portion of the site has its own URL, then bookmark the URL of the secure site and use it directly, instead of going through the home page. Not only will this be faster, but because you don't need the unencrypted site at all, you can afford to crank up NoScript's security (eg ABE; see below).
    .
  2. Whenever possible, you should use encrypted (https) connections for sensitive sites. To help with this, you can tell NoScript to force encryption on all connections to a site; on the Options-Advanced-HTTPS-Behavior tab, add an entry to Force the following sites to use secure (HTTPS) connections. For example, if you were dealing with the Wells Fargo bank:

    Code: Select all

    .online.wellsfargo.com
    Note the leading dot, which tells NoScript to include the domain and all subdomains. All requests going to the banking portion of Wells Fargo will now use the encrypted https protocol, instead of plain http.

    You should also force cookies to be sent only via secure channels, so that they can't be stolen 'on the wire'. To do this, on the Options-Advanced-HTTPS-Cookies tab, check Enable Automatic Secure Cookies Management. You don't need to list specific sites here; all are covered by default. In the very unlikely event that this setting breaks a site, you can add an exception for it (and complain to the site administrator about their insecure cookies!).

    As an extra precaution, if you really need to visit the unencrypted portion of the site, it's safest to log out of the encrypted site and restart your browser.
    .
  3. The most thorough defence is to add custom rules to the Application Boundary Enforcer module, on the Options-Advanced-ABE tab. You'll want to use the USER ruleset for this. Determining the right rules for a site can require some experimentation, but as an example, to protect Wells Fargo:

    Code: Select all

    # prevent CSRF on Wells Fargo
    Site .wellsfargo.com
    Accept from SELF
    Deny
    
    Again, note the leading dot. This rule tells ABE that wellsfargo.com, and all of its subdomains, should ignore any requests sent from any address except their own (same protocol, full domain, and port number). So, any requests sent to https://online.wellsfargo.com/send/money/ will be blocked unless they come from https://online.wellsfargo.com.

    You can also use ABE to ensure that the encrypted site cannot import any insecure resources (such as images or tracking scripts) from unencrypted sites:

    Code: Select all

    # prevent insecure resources on Wells Fargo
    Site ^http://.*
    Deny from .online.wellsfargo.com
    
    Note that these rules would prevent even www.wellsfargo.com from linking to the online banking portion of the site. This is where bookmarking the specific page comes in handy! If you still want to allow linking, you can do so, but bear in mind that every link has the potential to be abused, especially when it comes from an unencrypted site (which can be impersonated, especially on an insecure connection such as public WiFi). The code for this would be:

    Code: Select all

    # prevent CSRF on Wells Fargo, but allow links; less secure
    Site .wellsfargo.com
    Accept from SELF
    Anon GET from www.wellsfargo.com
    Deny
    
For more details about the awesome power of ABE, see its documentation page.

For extra security beyond NoScript, you can read through this thread.

Further suggestions are welcome in the comments.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Linux i686; rv:12.2) Gecko/20121102 PaleMoon/12.2
Hecuba's daughter
Senior Member
Posts: 93
Joined: Mon Oct 01, 2012 6:34 am

Re: Best Practices for Sensitive Sites

Post by Hecuba's daughter »

Thanks so much for this "dummies" guide.
Any non-coder should get these few rules down quick smart.
Thrawn wrote: As an extra precaution, if you really need to visit the unencrypted portion of the site, it's safest to log out of the encrypted site and restart your browser.
This precaution begs the question that in Fx, a user should make it a rule to always open a sensitive session in its own new Fx instance.
Don't know if that needs to be added to these great rules?
Mozilla/5.0 (Windows NT 5.1; rv:16.0.2) Gecko/20100101 Firefox/16.0.2 NoScript NoRedirect DownThemAll FlashGot
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Best Practices for Sensitive Sites

Post by Thrawn »

Hecuba's daughter wrote:Thanks so much for this "dummies" guide.
Any non-coder should get these few rules down quick smart.
Glad you like it :).
This precaution begs the question that in Fx, a user should make it a rule to always open a sensitive session in its own new Fx instance.
Don't know if that needs to be added to these great rules?
It's a good idea, but it's more general advice, rather than being specific to NoScript. Maybe worth mentioning in the linked thread, which has general security ideas. Thanks for bringing it up.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (Linux; U; Android 2.3.6; en-au; GT-S5830 Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
Post Reply