Page 2 of 2

Re: XSS examples not blocked by Noscript?

Posted: Sun Oct 23, 2011 5:26 am
by al_9x
Giorgio Maone wrote:Please check latest development build 2.1.8rc1
  1. this should have a toggle or context pref
  2. possibly exceptions
  3. it double logs
  4. logs when script domain is not whitelisted

Re: XSS examples not blocked by Noscript?

Posted: Sun Oct 23, 2011 11:07 am
by tlu
Giorgio Maone wrote:Please check latest development build 2.1.8rc1
Thanks again! Those examples are indeed successfully blocked! (Somehow I was pretty sure that you would come up with a solution - you're really incredible :D )

Re: XSS examples not blocked by Noscript?

Posted: Tue Oct 25, 2011 4:46 pm
by saywot
Giorgio Maone wrote:Please check latest development build 2.1.8rc1
Confirmed. After AMO caught up with the version ;-)

Re: XSS examples not blocked by Noscript?

Posted: Thu Oct 27, 2011 11:04 am
by Giorgio Maone
al_9x wrote:
  1. this should have a toggle or context pref
  2. possibly exceptions
  3. it double logs
Done/fixed in latest development build 2.1.8rc2
al_9x wrote:4. logs when script domain is not whitelisted
By design. You may want to know in advance if a site wants to engage in potentially hostile activities.

Re: XSS examples not blocked by Noscript?

Posted: Thu Oct 27, 2011 10:30 pm
by al_9x
Giorgio Maone wrote:
al_9x wrote:
  1. this should have a toggle or context pref
  2. possibly exceptions
  3. it double logs
Done/fixed in latest development build 2.1.8rc2
This may not be very important, but I noticed in at least couple of places (rapidFireCheck, checkInclusions) that you check the pref at the last minute having done all the preparatory work for the feature in question. In general, I think it's a good idea for a toggle pref to completely bypass the codepath of the functionality it disables, since that could be the reason for and the benefit of disabling it.

Re: XSS examples not blocked by Noscript?

Posted: Thu Oct 27, 2011 10:38 pm
by Giorgio Maone
al_9x wrote:I think it's a good idea for a toggle pref to completely bypass the codepath of the functionality it disables, since that could be the reason for and the benefit of disabling it.
It's an optimization for the common case, since preference access (through XPCOM) is relatively expensive and these features are very unlikely to be turned off (hence it makes little sense to observe & cache yet another pref value).