javascript not being blocked

[OneUser]

I have seen window.location is not being blocked in some sites , the code is the next one:

noscript 2.3.7rc5

<select name="things" onchange="window.location =(document.forms.archiveform.archive_chrono[document.forms.archiveform.archive_chrono.selectedIndex].value);">
<option value="">select</option>
<option value="http://xxx/">4a 2012 </option>
<option value="http://xxx/"> 1 2012 </option>
<option value="http://xxx/">2 2012 </option>
<option value="http://xxx/">3 2012 </option>
</select>


Shoud not it be blocked?

This domain is blocked

[Tom T.]

What is the address(es), or URL(s), where this occurs?

[OneUser]

Code: Select all

http://www.example.com

firefox 11.00

Please edit the url when you catch it.

[Tom T.]

[url]http:/www.example.com[/url]
Please edit the url when you catch it.

Wrapping it in code tags serves the purpose -- or did you want it deleted for privacy? I can do that.
(You can also register as a user, then PM the URL to me/us.)

I think I understand the issue.
With script blocked at that site, you would like the "combo box", or informally, "dropdown window" to be blocked also. Is this correct?

i confirm that on both Fx 3.6.28 and Fx 11.0, the combo box "Archive" still functions, even when the script is blocked.

I don't think that NoScript is supposed to block combo boxes that are in the document itself, *and do not call to external sites*, but only to sub-pages within that same domain, such as

Code: Select all

www.example.com/april12
www.example.com/mar12
www.example.com/feb12

etc. They shouldn't pose a security risk, because they have no more privilege to run executable code than the root or parent site -- in this case, none.

(It's almost the same as if they were plain HTML links within the same site. The combo box takes up less space.)

However, I will ask Giorgio to confirm, or, if I am mistaken, to correct me and to reply to you, thanks.

[Giorgio Maone]

No script code is getting executed.
It's just NoScript trying to emulate the "correct" behavior whenever it can see URLs inside option elements, as part of the
NoScript Options|Advanced|Untrusted|Attempt to fix JavaScript links
feature.

[OneUser]

Hi,

Yes, it was for privacy.
I do hate the so abusive use of logins in the internet so when someone permits anonymous reports i am using them

About the issue, it is javascript, so i thougth it should be blocked. I will wait for your response.

Thanks

[OneUser]

Hi,

Ok, so i must disable it to ensure that piece of javascript is not being interpreted. I dont mind it that web does not work, i prefer not javascript at all being executed.

Thanks for your support.

[Giorgio Maone]

Ok, so i must disable it to ensure that piece of javascript is not being interpreted. I dont mind it that web does not work, i prefer not javascript at all being executed.

As I said, no JavaScript from the page gets interpreted / executed.
It's just NoScript opening the links when it guesses it's what the user would expect.

[Tom T.]

Yes, it was for privacy.
I do hate the so abusive use of logins in the internet so when someone permits anonymous reports i am using them

Our mission is to provide security. While I agree about logins in general, we are the last people on Earth who would misuse the *only* information required to create an account, which is: a valid e-mail address.

It can be a proxy or disposable address, so long as it is connected only to you. *NO* other personal information is required to create an account. Your email address will never be sold, rented, traded, etc.

I spend half my time at this forum deleting spams and banning spammers. Why would we give your address to spammers?
Accounts tied to a specific username and email provide accountability to ban spammers and other violators, that's all.
It's actually *more* private, because only registered users can send PMs -- again, to prevent PM-spam by just anyone.

It was less private the way you did it. The URL was posted for more than an hour before I edited it. It may not be so fast. Some posts, for various reasons, may not be answered for a few days.
************************************
As for the other issue, since it seems that Giorgio is not getting through to you, let me try an example of what I said before: the similar behavior of HTML links:

Welcome to Tom T.'s Web Site!

Hello, blah, blah, lorem ipsum.....

Tom T's Page 2
Tom T's Page 3
Tom T's Page 4
Tom T's Page 5

Would you regard those links as "javascript code"? Of course not.
If you click them, is that "javascript executing"? Of course not. It's just a link.

If instead, the site were:

Welcome to Tom T.'s Web Site!

Hello, blah, blah, lorem ipsum.....
(combo box)

Code: Select all

<select name="things" onchange="window.location =(document.forms.archiveform.archive_chrono[document.forms.archiveform.archive_chrono.selectedIndex].value);">
<option value="">select</option>
<option value="http://xxx/">Tom T's Page 2</option>
<option value="http://xxx/">Tom T's Page 3</option>
<option value="http://xxx/">Tom T's Page 4</option>
<option value="http://xxx/">Tom T's Page 5</option>
</select>

Would it be any different? As Giorgio said, when you click, you expect to be taken to that sub-page. To disable this would be sort of like writing a Greasemonkey script to remove the HTML links from the first example. *NO JS IS RUNNING*.

I understand that onchange=window.location is a scripty-type thing. In action, NoScript turns it into kind of a set of hyperlinks wrapped in a smaller GUI.
As Giorgio said, this is what the user expects, but NoScript is opening the link for you instead of allowing scripting to open it.

And there is no difference in the security risk in these sub-pages regardless of which way you get to them, by Exampe 1 or Example 2.
If you have script blocked at "Tom T.com", then the sub-pages also have script blocked.
There is no need to disable the "Fix JS links". You break pages while *not* improving your security.

I hope this helps.