Food for thought: safe browsing and blocking scripts

Still not a valid test. I'm using scriptkeeper, not scriptweeder and I still get a better result with it completely disabled which is necessary to run the test and that tells me that there's something not quite right if I have to enable javascript and bypass the scriptblocker in order to run the test.

 

Yup, for me security those addon provide is important as there's no full replacement. There're threats neither sandbox nor anti-exploit etc. can protect, including web application bugs like XSS, CSRF, etc. and theoretically logic flaw RCE exploit with in-mem peyload, or even kernel exploit.
XSS is the most common bug in websites and you can't know when you're attacked unlike most malware which usually leave some traces. Only if attacker directly abuse aquired session info then you may know sth wrong happend when e.g. looking your credit card details.
But it finally comes down to individual preference so this discussion won't reach full agreement.

At first, it will surely take quite a time, but after playing with it with 1 or more months actually you don't need many trial & errors, in most pages you can quickly adjust your control with just a few click.
Also knowledge about domains acquired through these experience was useful for me to make my Android and iOS ad-free.

 

Hello Yuki,

Have you ever found such an exploit in the wild? I haven't. When I search around for information, I get reports like this:

Severe XSS flaw affects fully patched Internet Explorer
http://securityaffairs.co/wordpress/33089/security/severe-xss-flaw-explorer.html
February 4, 2015

If I find a report of an exploit, it's always some situation I wouldn't encounter, thus, don't bother attempting to test, such as:

Twitter XSS vulnerability exploited in the wild
http://www.net-security.org/secworld.php?id=9830
Posted on 07 September 2010.

----
rich

 

Well, one prominent exploit which comes to my mind was the hacked Ubuntu forums in mid 2013 when 1.8 million user credentials were stolen. Yahoo email accounts were also attacked in 2013. eBay was affected in May 2014. And this site will reveal a couple of other examples. Not all of them were actually exploited. But the problem is that XSS vulnerabilities can be easily detected through several tools (like Metasploit) that scan websites for them. As this site mentions: "XSS flaws are very common in web applications since they require a great deal of developer discipline to avoid them." And it labels the likelihood of exploit as "High to Very High". According to this site "It has been estimated that approximately 65% of websites are vulnerable to an XSS attack in some form, a statistic which should scare you as much as it does me."

An already older report from 2007 says:

And according to OWASP, XSS belonged to the 10 top vulnerabilities in 2013.

Rich, I would take XSS seriously

 

I've looked at the topic a lot over the years. This quote you cited (similar have been made in the past) has puzzled me:

With such a high vulnerability rate, Why haven't there been more attacks in the wild?

----
rich

 

Does anyone know of any good script blockers that runs independent of the browser? I'm looking for a good product that specializes in script blocking. I want something that uses some intelligent method to block harmful scripts, and allow the harmless ones. I had a license for an exploit blocker years ago that blocked a lot of scripts, but AVG purchased it. I looked, and it has been integrated into the AVG suite. I don't want to use AVG so I guess I want be able to use it now. I'm using MBAE, but it does not block scripts unless an exploit is attempting to execute.

Edited 10/17 @ 10:22: I think the product I had years ago was called SocketShield. It may not have been an exploit blocker, but it is kind of what i'm looking for.

 

I think that was the whole point of this thread, there's is no way to know which scripts are bad, and often you will eventually allow blocked scripts to make stuff work. You could use a script-blocker that doesn't break sites, like Ghostery. If you're worried about exploits, use tools like MBAE and HMPA.

 

I already use Ghostery. I have been testing EMET, MBAE, and HMPA for a few months now. I have not made a final decision on which exploit blocker i'm going to use long term. Since I have had quite a few problems out of HMPA I will probably go with EMET, or MBAE. HMPA build 155 worked great on my system, but I had a bad application conflicts between HMPA & Online Armor with build 166. It has been up, and down with HMPA so far. I was hoping you guys were aware of some good products that I had not already tried.

 

If there where any other products, I'm sure they would have already been posted over here. I wouldn't worry about "script blocking" too much. Today, even most AV's are also trying to block exploits, but they are probably not using advanced techniques like HMPA, EMET and MBAE. To me, blocking of scripts is more about speed, privacy and extra control, although in theory it can sometimes also protect against certain exploits, especially when "malvertising" is involved.

 

That's the thing, I don't want to keep having to fine-tune stuff, that's why I think ScriptKeeper in "relaxed mode" + Ghostery is a better solution. NoScript and uMatrix don't offer this mode for obvious reasons, but it really does make a difference.

 

Script blocking utilities fall into 2 categories, extensions and filtering proxies. Extensions are by design dependent on the browser and only work with the ones they're designed for. Only the filtering proxies are truly independent of the browser. Here your choices are Proxomitron, Privoxy, etc. These are capable of filtering scripts to whatever criteria you specify in the filters. There are individual filters that remove Etags, remove or fake referrers, user agents, etc. They can block or give fake results to scripts that try to obtain identifiable information or attempt to fingerprint your system. They can kill beacons and transparent GIFs. They can remove hidden frames/iFrames or convert them to links. The filters can be written to perform most any function that you want. That said, there is no premade set of filters that will do all of this for you. You would have to assemble your own filterset to meet your own criteria.

 

If I was attacked, I doubt I notice it. Only XSS I encountered in real life are either harmless mischief or FP by Noscript (I confirmed they were FPs).
But when I said XSS is the most common bug in websites, I mean bug or vuln, not exploit, and ofc statistics tlu kindly posted was in my mind.

Same here. It's hard to encounter any kind of real working exploit despite I'm almost random internet user. I found even in test, it's still not easy as most exploit doesn't work properly e.g. redirect site dead, used application doesn't much, (ofc I use vunlerable setup on testing), etc.

But whole point is, IF you came across drive-by, you can have many layer/hurdle against it so script blocker is not necessary, but for XSS and some other threats including CSRF, click jacking, etc. Most ppl don't have many layer except browser built-in filter so script blocking plays major role. Actually if you know how XSS works, you can mitigate the risk even w/out script blocking, but I know most ppl, even some of those Wilders guys, don't know XSS well nor follow the practice to mitigate it.

Since I define security not as "protect your PC from infection" but as "protect your data from abuse", I say it's false sense of security if one piling up many layer against malware and RCE but take no measure against other threats. However, possibility we come across threats and cost-performance is another thing so I don't claim preventive measure for XSS is necessity, just like anti-exploit tool is not the necessity.

 

Actually, good AV do that, They analyze script and block suspicious one. If you think this is old classic signature, then it's not exactly right as those protection are much more generic and in some rare cases even detect unknown 0day exploit. Avast detects XSS as well.
Also some AV implement behavior-based anti-exploit and application lockdown feature. If you think MBAE was the first to employ them, it's not right. Maybe MBAE and HMPA are more efficient as they specializes exploit protection and also have many memory mitigation, but definitely not the first.

 

That is why I said it falls down to matter of prefs. As you know, that is better in usability but worse in security. It all depends how you feel about them, but I wanted to point out time & effort you spend to adjustment significantly decrease once you're accustomed.

 

Basically proxy approach is not just browser independent, but as noone suggested, it allows much more control for you. Almost everything can be done as long as it is html. I used it not only for script blocking, but many, many more purposes. Skip redirect, skip access control by website, remove unnecessary results from search, etc. etc.

BUT I do not recommend using filtering proxy for SSL/TLS connection unless you're aware of risk it brings. These proxies can't handle SSL/TLS as good as browsers, it means there's more risk of MITM. MITM is not only matter of public wifi, tho surely public wifi is major risk factor and significantly lower hurdle for MITM.

 

Proxomitron is getting better at it if you don't mind unofficial patches or hex editing. See this thread at Prxbx, starting at post #23. Myself, I don't put much value in HTTPS. IMO, SSL/TLS is not capable of securing the content against any adversary of consequence. Until we have a system that doesn't rely on certificates or "authorities", I consider it broken by design. Either way, HTTPS does not protect the user from tracking code, data mining, nosey scripts, fingerprinting, or malicious content. I consider it more important to filter the content.

 

Tried Privoxy and couldn't get it to run in LUA. Am aware of "run as" for apps that need admin rights. Also I
couldn't get it to work with Sandboxie. Probably because I have it set with many restrictions. Might work with
a new sandbox with less restrictions.
Version 3.0.5 beta introduced full Windows service functionality. On Windows only, the Privoxy
program has two new command line arguments to install and uninstall Privoxy as a service. This
might work to run Privoxy in LUA, but haven't tried it.

Haven't used Proxomitron for many years back when Firefox was my main browser. Do you know if Proxomitron
will run in a LUA and using Sandboxie version4 ?

 

I haven't tried Proxomitron in a limited user account. I have used it with Drop-My-Rights. It would run in "normal" or "constrained" mode. In constrained mode, it couldn't open a text editor to edit the configuration files. If you run Proxomitron in a sandbox, any configuration changes or permissions that you set would be lost when you delete the sandbox. You'd either have to save the changes manually or make an exception that allows Proxomitron to write to its own configuration file and the lists it uses. I haven't tried SandBoxie 4 versions but had no problems running it in the last version 3.

 

Doing some testing- Proxomitron does run in LUA. I need to work some settings out with Sandboxie 4 while
keeping it as secure as possible. Running Request Policy also. Checked the logging and nothing is showing up.
(http message log) Sandboxie has setting similar to Drop-My-Rights program if that is what your referring to.
Didn't add ssleay32.dll and libeay.dll yet.

 

Proximotrin runs in all my windows computers and all them use a LUA. The LISTS folder in the program folder needs to have its permissions set to read/write if you want to be able to update lists in a LUA. My LUAs are much stricter and more limited than the default LUAs.

 

The Request Policy log doesn't function like a conventional log file. It 's more like an activity viewer. Open the log window, then load a page. The log window will show the connection attempts as they are made.

Regarding the Open SSL libraries ssleay32.dll and libeay.dll, the current versions won't work unless you hex edit Proxomitron.exe as described in this post. Without the hex edit, you'll need the old versions from here. You'll also need updated certs.pem and proxcert.pem files from the prxbx forum.

 

My mistake. I was referring to Proxomitron log window. The window is now logging.

 

So I need to use my hex editor which I have not used since opening up index.dat files? If I use the old version instead do I need to update the .pem files. Need more clarity. Thanks.

 

Proxcert.pem is the certificate for Proxomitron that your browser will see. You'll need to import it into the browser certificate store. It expires yearly. You can either obtain a new one from the site or use the make proxcert utility to make your own. Certs.pem is the list of certificates Proxomitron will use with websites. It serves the same purpose as your browsers certificate store. There's a couple of versions available at prxbx. One is extracted from the Internet Explorer certificate store. The other I believe is from Mozilla.

 

There is a more current certs.pem available in this post at prxbx.