Page 1 of 1

Best Practices for Sensitive Sites

Posted: Mon Nov 05, 2012 12:03 pm
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.

Re: Best Practices for Sensitive Sites

Posted: Tue Nov 13, 2012 6:22 am
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?

Re: Best Practices for Sensitive Sites

Posted: Tue Nov 13, 2012 6:36 am
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.